Payment device and electronic payment program
By enabling terminals to use both online and offline tokens based on performance, the system enhances the likelihood of online payments, improving user convenience and system efficiency.
Patent Information
- Application Number
- JP2024162470
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2024-09-19
- Publication Date
- 2025-11-27
- Estimated Expiration
- 2044-09-19
AI Technical Summary
Conventional electronic payment systems face challenges where terminal devices, despite having sufficient performance, fail to obtain online tokens within specified times, leading to a higher likelihood of offline payments instead of online payments.
The system includes a terminal device and payment device that can acquire and display code images based on both online and offline tokens, determined by a terminal reference value based on the device's performance, ensuring online payments are prioritized when possible.
This approach increases the likelihood of successful online electronic payments by adapting to device performance, enhancing user convenience and payment system efficiency.
Smart Images

Figure 0007777201000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a payment device and an electronic payment program. [Background technology]
[0002] A technology related 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 or the like. For example, Patent Document 1 discloses a technology related to electronic payment in which, when the terminal device and the payment device can communicate with each other, a code image is displayed on the terminal device based on an online token supplied from the payment device, and the store terminal that reads the displayed code image transmits information based on the code image to the payment device, thereby performing payment processing on the payment device. The electronic payment disclosed in Patent Document 1 is characterized in that, when the terminal device cannot obtain an online token from the payment device within a specified time, a code image is displayed on the terminal device based on an offline token stored in the terminal device, and the store terminal that reads the displayed code image transmits information based on the code image to the payment device, thereby performing payment processing on the payment device. [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 conventional technology, for example, even if the terminal device and the payment device can communicate and the terminal device can display a code image based on the online token, there are cases where the terminal device cannot obtain the online token within the specified time due to low performance. In this case, even though the terminal device's performance would have been high enough to perform electronic payment using the online token (hereinafter sometimes referred to as "online electronic payment"), electronic payment using an offline token (hereinafter sometimes referred to as "offline electronic payment") is actually performed.
[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 can increase the likelihood of online electronic payments being made compared to conventional technologies. [Means for solving the problem]
[0006] In order to solve the above problems, the electronic payment program of the present invention is characterized in that it causes a processor of a terminal capable of communicating with a payment device to function as an acquisition unit that acquires two types of tokens from the payment device: an online token used in electronic payments performed when the payment device and the terminal can communicate, and an offline token used in electronic payments performed when communication between the payment device and the terminal is difficult; and a display control unit that displays on a display device a code image based on one of the two types of tokens, which is determined according to a terminal reference value based on the performance of the terminal.
[0007] In addition, the payment device of the present invention is a payment device capable of communicating with a terminal, and includes a reception unit that receives terminal information related to the performance of the terminal from the terminal, and a supply unit that supplies to the terminal two types of tokens: an online token used in electronic payments performed when the terminal and the payment device can communicate, and an offline token used in electronic payments performed when communication between the terminal and the payment device is difficult, and reference value information indicating a terminal reference value determined based on the terminal information, and the terminal displays a code image based on one of the two types of tokens supplied from the supply unit, which is determined according to the terminal reference value indicated by the reference value information supplied from the supply unit, on a display device of the terminal. [Effects of the Invention]
[0008] The present invention increases the likelihood of online electronic payments being made compared to conventional techniques. [Brief explanation of the drawings]
[0009] [Figure 1] 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. [Figure 2] FIG. 2 is a block diagram showing an example of the configuration of a terminal device 1[q]. [Figure 3] FIG. 2 is a block diagram showing an example of the configuration of the payment device 3. [Figure 4] 1 is a sequence chart showing an example of the operation of the electronic payment system Sys. [Figure 5] 1 is a sequence chart showing an example of the operation of the electronic payment system Sys. [Figure 6] FIG. 10 is an explanatory diagram illustrating an example of token response information DSW[q]. [Figure 7] FIG. 10 is an explanatory diagram illustrating an example of token response information DSW[q]. [Figure 8] FIG. 10 is a schematic diagram showing an example of an online code image display screen G1. [Figure 9]FIG. 10 is a schematic diagram showing an example of a payment method selection screen GS. [Figure 10] 1 is a sequence chart showing an example of the operation of the electronic payment system Sys. [Figure 11] FIG. 10 is a schematic diagram showing an example of an offline code image display screen G2. [Figure 12] 1 is a sequence chart showing an example of the operation of the electronic payment system Sys. [Figure 13] 1 is a sequence chart showing an example of the operation of the electronic payment system Sys. [Figure 14] FIG. 10 is a schematic diagram showing an example of the data configuration of a payment code CC[q]. [Figure 15] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 16] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 17] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 18] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 19] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 20] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 21] FIG. 10 is a schematic diagram showing an example of an offline payment explanation screen G3. [Figure 22] 10 is a flowchart showing an example of the operation of the payment device 3. [Figure 23] 10 is a flowchart showing an example of the operation of the payment device 3. [Figure 24] 10 is a flowchart showing an example of the operation of the payment device 3. [Figure 25] 10 is a flowchart showing an example of the operation of the payment device 3. [Figure 26] 10 is a flowchart showing an example of the operation of the payment device 3. [Figure 27]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 28] 1 is a sequence chart showing an example of the operation of the electronic payment system Sys. [Figure 29] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 30] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 31] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 32] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 33] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 34] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 35] 10 is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 36] 10 is a sequence chart showing an example of the operation of the electronic payment system Sys according to the first modification of the present invention. [Figure 37] 10 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. [Figure 38] 10 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. [Figure 39] 10 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 INVENTION
[0010] Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings. In each figure, the dimensions and scales of each part are appropriately different from the actual ones. Further, the embodiments described below are preferred specific examples of the present invention, and thus various technically preferable limitations are imposed. However, the scope of the present invention is not limited to these embodiments unless there is a description specifically limiting the present invention in the following description.
[0011] <A. First Embodiment> Hereinafter, the first embodiment of the present invention will be described.
[0012] <A.1. Overview of Electronic Payment System Sys> The overview of the electronic payment system Sys will be described while referring to FIGS. 1 to 3.
[0013] FIG. 1 is a block diagram showing an example of the configuration of the electronic payment system Sys.
[0014] As shown in FIG. 1, the electronic payment system Sys includes a payment device 3, a store device 5 that can communicate with the payment device 3 via a network NW, and one or more terminal devices 1 that can communicate with the payment device 3 via the network NW, and provides services related to electronic payment to the user U of the terminal device 1.
[0015] In the present embodiment, as an example, it is assumed that the electronic payment system Sys includes a plurality of terminal devices 1. Specifically, in the present embodiment, it is assumed that the electronic payment system Sys includes Q terminal devices 1. 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 who uses the terminal device 1[q] is referred to as user U[q].
[0016] The terminal device 1[q] (an example of a "terminal") is, for example, a mobile terminal such as a smartphone or 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 in-store device 5 is installed, the user U[q] of the terminal device 1[q] can pay for the service by electronic payment by using the payment app running on the terminal device 1[q] to display on the terminal device 1[q] a code image GG based on the token KK acquired from the payment device 3.
[0017] Hereinafter, the code image GG displayed on the terminal device 1[q] will be referred to as the code image GG[q]. The code image GG[q] is, for example, a barcode or a two-dimensional code. In this embodiment, as an example, it is assumed that the code image GG[q] is a barcode. Also, below, the token KK supplied from the payment device 3 to the terminal device 1[q] will be referred to as the token KK[q].
[0018] In this embodiment, it is assumed that the store where the in-store device 5 is installed is a physical store existing in real space, i.e., 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 for the goods or services by electronic payment.
[0019] The in-store device 5 is, for example, a point-of-sale (POS) cash register. When a user U[q] of a terminal device 1[q] pays for a service provided by a store by electronic payment, the in-store device 5 reads a code image GG[q] displayed on the terminal device 1[q]. Next, the in-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 provides the generated payment information DP[q] to the payment device 3. Here, the store payment information includes, for example, store identification information for uniquely identifying the store that provided the service to the user U[q], the payment amount to be paid by the user U[q] as payment for the service provided to the user U[q], and the payment date and time, which is the date and time when the payment is made.
[0020] The payment device 3 executes payment processing based on the payment information DP[q] when it receives payment information DP[q] from the in-store device 5. Here, the payment processing is a process for confirming payment from the user U[q] of the terminal device 1[q] to the store as 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.
[0021] In this embodiment, as an example, it is assumed that the payment device 3 manages the usage fee for the terminal device 1[q] by the user U[q]. Here, the usage fee for the terminal device 1[q] includes, for example, the purchase price of the terminal device 1[q] and communication fees incurred when the terminal device 1[q] communicates. In this embodiment, the payment device 3 debits the usage fee for the terminal device 1[q] from the bank account of the user U[q] registered in advance with the payment device 3, for example, on the payment date of each month. Note that, hereinafter, the usage fee for 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 a user U[q] that can be used at a 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 that the user U[q] can use electronic money equivalent to the amount charged by charging the electronic money in advance. However, the present invention is not limited to this aspect. The electronic money managed by the payment device 3 may also be so-called postpaid electronic money that can be used up to 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] can be made using the credit card for user U[q] issued by the credit card company.
[0022] 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] pays the store by adding the telephone bill to the usage fee of the terminal device 1[q]. Also, the prepaid balance payment is a payment method in which the user U[q] pays 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] pays the store using the credit card of the user U[q].
[0023] Furthermore, in this embodiment, as described above, the settlement 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].
[0024] Below, we will explain an example of the operation of the electronic payment system Sys (hereinafter sometimes referred to as "online electronic payment") when the terminal device 1[q] and the payment device 3 are capable of communicating and the electronic payment system Sys of this embodiment provides electronic payment services to the user U[q] of the terminal device 1[q]. First, when a user U[q] of terminal device 1[q] receives a service at a store where in-store device 5 is installed and pays for the service through online electronic payment, user U[q] operates terminal device 1[q] to launch a payment app on terminal device 1[q]. Next, when the payment app is launched, terminal device 1[q] requests a token KK[q] from the payment device 3. Next, in response to the request from terminal device 1[q], payment device 3 provides the token KK[q] to terminal device 1[q]. Next, terminal device 1[q] generates a payment code CC[q] based on the token KK[q] provided by 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.
[0025] In the above-described online electronic payment, the payment device 3 issues a token KK[q] in response to a request from the terminal device 1[q]. Therefore, online electronic payment can be performed only when the terminal device 1[q] and the payment device 3 can communicate with each other, and cannot be performed when communication between the terminal device 1[q] and the payment device 3 is difficult. Therefore, when communication between the terminal device 1[q] and the payment device 3 is difficult, the electronic payment system Sys according to this embodiment performs payment processing using payment information DP[q] generated based on the token KK[q] stored in the terminal device 1[q].
[0026] Below, we will explain an example of the operation of the electronic payment system Sys (hereinafter sometimes referred to as "offline electronic payment") when communication between the terminal device 1[q] and the payment device 3 is difficult and the electronic payment system Sys of this embodiment provides electronic payment services to the user U[q] of the terminal device 1[q]. 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 through offline electronic payment, the user U[q] operates the terminal device 1[q] to launch a payment app on the terminal device 1[q]. Next, when the payment app is launched, 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 provides 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] provided by the store device 5, thereby finalizing the payment from the user U[q] to the store.
[0027] As described above, the electronic payment system Sys of this embodiment can perform two types of electronic payments: online electronic payment when the terminal device 1[q] and the payment device 3 can communicate, and offline electronic payment when communication between the terminal device 1[q] and the payment device 3 is difficult. Therefore, compared to a system in which only online electronic payment is possible, it can improve convenience for the user U[q] of the terminal device 1[q].
[0028] 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] may 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] may be referred to as the offline token KY[q]. In addition, in the following, in online electronic payments, the payment code CC[q] generated by terminal device 1[q] from online token KX[q] may be referred to as online payment code CX[q], and in offline electronic payments, the payment code CC[q] generated by terminal device 1[q] from offline token KY[q] may be referred to as offline payment code CY[q]. 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 the 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 the offline code image GY[q]. In the following, the payment process executed by the payment device 3 in online electronic payment may be referred to as online payment process, and the payment process executed by the payment device 3 in offline electronic payment may be referred to as offline payment process.
[0029] FIG. 2 is a block diagram showing an example of the configuration of the terminal device 1[q].
[0030] 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.
[0031] 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 RAM (Random Access Memory) that functions as a work area for the control device 11, and a non-volatile memory such as an EEPROM (Electrically Erasable Programmable Read-Only Memory) that stores various information, and stores user identification information DID[q], acquired offline token information KYY[q], offline blockage information DHY, a business operator identification token KZ, token response information DSW[q], setting information DS, and an electronic payment program PG-T.
[0032] 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.
[0033] 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 offline tokens KY[q] M times from the payment device 3 during the period from when the payment app was first launched (initial launch) on 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 times from the payment device 3, out of the M offline tokens KY[q] acquired by the terminal device 1[q] from the payment device 3, is referred to as offline token KY[q][m]. Here, the variable m is a natural number that satisfies "1≦m≦M".
[0034] In this embodiment, it is assumed that the acquired offline token information KYY[q] includes M records that correspond one-to-one to the M offline tokens KY[q][1] to KY[q][M] that the terminal device 1[q] acquired from the payment device 3. Of the M records included in the acquired offline token information KYY[q], the m-th record includes the offline token KY[q][m], offline token validity period information DTY[q][m], and an encryption key KS[q][m].
[0035] Here, the offline token validity period information DTY[q][m] indicates the period during which the offline token KY[q][m] can be used in offline electronic payments, i.e., the 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 that starts from the time the offline token KY[q][m] is generated and ends when the offline token validity period TSY has elapsed since the time the offline token KY[q][m] was generated. 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.
[0036] The encryption key KS[q][m] is information used to generate the offline payment code CY[q] in offline electronic payment.
[0037] As described above, 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] that the terminal device 1[q] has acquired 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 offline token KY[q][M] that was acquired last among the M offline tokens KY[q][1] to KY[q][M] that the terminal device 1[q] has acquired 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 of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] has arrived) from among the M offline tokens KY[q][1] to KY[q][M] acquired from the payment apparatus 3. Specifically, if the end of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] included in the acquired offline token information KYY[q] stored in the storage device 12 is earlier than the current time (i.e., the offline token has expired), the terminal device 1[q] may delete from the acquired offline token information KYY[q] 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]). In this case, the acquired offline token information KYY[q] will include only offline tokens KY[q] that are within their expiration dates. 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] from 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] In addition, in this embodiment, it is assumed as an example that the acquired offline token information KYY[q] includes M pieces of offline token validity period information DTY[q][1] to DTY[q][M] and M encryption keys KS[q][1] to KS[q][M]. However, the present invention is not limited to this aspect. The acquired offline token information KYY[q] only needs to include at least the offline token validity period information DTY[q][M] corresponding to the offline token KY[q][M] that was 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] that was 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 TY[q][m] indicated by the offline token validity period information DTY[q][m] has arrived) from among the M encryption keys KS[q][1] to KS[q][M] acquired from the payment apparatus 3. Specifically, if 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 acquired offline token information KYY[q] stored in the storage device 12 is a time in the past (i.e., if 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 acquired offline token information KYY[q]. In this case, the acquired offline token information KYY[q] includes only the encryption key KS[q] corresponding to the offline token KY[q] that is within the expiration date. Furthermore, for example, the terminal device 1[q] may delete the encryption keys KS[q][1] to KS[q][M-1] other than the most recently acquired encryption key KS[q][M] from 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 acquired offline token information KYY[q] will include only the latest encryption key KS[q][M].
[0039] 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.
[0040] The business identification token KZ includes business identification information DKZ that identifies the payment business that manages the payment device 3.
[0041] The token response information DSW[q] (an example of "reference value information") indicates an online token response waiting time TSWX[q] and an offline token response waiting time TSWY[q].
[0042] The online token response waiting time TSWX[q] (an example of a "terminal reference value") is the time length of the online token response waiting period TWX[q]. In this embodiment, the online token response waiting period TWX[q] (an example of a "specified period") is a waiting period for the terminal device 1[q] from when the terminal device 1[q] requests the payment apparatus 3 for the online token KX[q] until the online token KX[q] is provided to the terminal device 1[q]. However, the present invention is not limited to this aspect. The online token response waiting period TWX[q] may also be a waiting period for the terminal device 1[q] from when the payment app is launched in the terminal device 1[q] until the online token KX[q] is provided to the terminal device 1[q]. In this embodiment, the terminal device 1[q] waits for the online token KX[q] to be provided from the payment apparatus 3 during the online token response waiting period TWX[q]. Then, when the online token response waiting period TWX[q] ends, the terminal device 1[q] stops waiting for the supply of the online token KX[q] from the payment device 3. Here, in this embodiment, it is assumed that the online token response waiting period TSWX[q] is determined based on the performance of the terminal device 1[q].
[0043] The offline token response waiting time TSWY[q] is the time length of the offline token response waiting period TWY[q]. The offline token response waiting period TWY[q] is a waiting period for the terminal device 1[q] from when the terminal device 1[q] requests the offline token KY[q] from the payment apparatus 3 until the offline token KY[q] is provided to the terminal device 1[q]. However, the present invention is not limited to this aspect. The offline token response waiting period TWY[q] may also be a waiting period for the terminal device 1[q] from when the payment app is launched on the terminal device 1[q] until the offline token KY[q] is provided to the terminal device 1[q]. In this embodiment, the terminal device 1[q] waits for the supply of the offline token KY[q] from the payment apparatus 3 during the offline token response waiting period TWY[q]. Then, the terminal device 1[q] stops waiting for the supply of the offline token KY[q] from the payment apparatus 3 when the offline token response waiting period TWY[q] ends. In this embodiment, it is assumed that the offline token response waiting time TSWY[q] is determined based on the performance of the terminal device 1[q].
[0044] The setting information DS includes online token validity information DSX, offline token validity information DSY, and update time information DSC.
[0045] The online token validity information DSX indicates the length of time (hereinafter referred to as the "online token validity time TSX") during which the online token KX[q] can be used for online electronic payments (hereinafter referred to as the "online token validity time 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 longer than the online token response waiting time TSWX[q]. Furthermore, in this embodiment, the online token validity period TX[q] is a period that starts from the time of generation of the online token KX[q] and ends when 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 length of time of the offline token validity period TY[q][m] during which the offline token KY[q][m] can be used for offline electronic payments. 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 the update cycle of the terminal time value AG based on the terminal time TG, which is the current time managed by 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." Also, in this embodiment, as an example, it is assumed that the terminal time value AG is a value representing the terminal time TG in the order of "minutes." For example, in this embodiment, if the terminal time TG is "18:25:37," the terminal time value AG may be "1825," which is obtained by deleting "37 seconds" from the terminal time TG. However, the present invention is not limited to this aspect. The update unit time TC may be shorter than the offline token validity time TSY. Also, 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 or in place of some 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 transmitting unit 111 is an example of a "transmitting unit", and transmits an online token request requesting an online token KX[q] to the payment apparatus 3 during an online token response waiting period TWX[q]. Furthermore, the information transmitting unit 111 transmits an offline token request requesting an offline token KY[q] to the payment apparatus 3 during an offline token response waiting period TWY[q]. Furthermore, the information transmitting unit 111 transmits terminal information DTM[q], which will be described later, to the payment apparatus 3. Furthermore, the information transmitting unit 111 transmits to the payment apparatus 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. Note that, hereinafter, 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 blocking information DHX, offline blocking information DHY, token response information DSW[q], operator identification token KZ, and setting information DS 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 payments, the display control unit 114 causes the display device 13 to display an online code image GX[q] based on the online payment code CX[q] generated by the code generation unit 113. In offline electronic payments, the display control unit 114 causes the display device 13 to display an offline code image GY[q] based on the offline payment code CY[q] generated by the code generation unit 113.
[0053] The display device 13 is hardware for displaying various types of 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]. The input device 14 may be, for example, a keyboard, a mouse, a microphone, a switch, a button, a sensor, or a combination of these devices. The display device 13 and the input device 14 may be configured as an integrated unit. In this case, the display device 13 and the input device 14 may be, for example, a touch panel.
[0055] The communication device 15 is hardware for communicating with an external device located outside the terminal device 1[q] via the network NW. In this embodiment, the information sending unit 111 sends various information to the payment device 3 via the communication device 15. The information acquiring 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. As shown in FIG.
[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 work 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, per-terminal token response information DW, payment management information DKP, setting information DS, and a control program PG-S.
[0059] The user management information DU has Q records that correspond one-to-one to 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 indicating 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 usage charge for 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 apparatus 3. In this embodiment, it is assumed that the payment apparatus 3 grants points to the user U[q], and the user U[q] can use electronic money in an amount equivalent to the granted points. The user payment information DSH[q] is information indicating 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 that correspond one-to-one to one or more offline tokens KY issued by the payment apparatus 3. Each record of the offline token issuance information DKY includes an offline token KY[q] issued by the payment apparatus 3, an encryption key KS[q] issued by the payment apparatus 3 in correspondence with the offline token KY[q], user identification information DID[q] of a user U[q] corresponding to the terminal apparatus 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 held by 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, if 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 in the past than the current time (in other words, if the validity period 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] (in other words, 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] (in other words, the expired encryption key KS[q][m]). Furthermore, the payment apparatus 3 may delete, in the offline token issuance information DKY, from among the M records corresponding to the M offline tokens KY[q][1] to KY[q][M] issued to correspond to user U[q], records other than the record corresponding to the latest offline token KY[q][M]. In other words, the payment apparatus 3 may delete, in the offline token issuance information DKY, from among the M offline tokens KY[q][1] to KY[q][M] issued to correspond to user U[q], offline token KY[q] other than the last issued offline token KY[q][M]. Furthermore, the payment apparatus 3 may delete, in the offline token issuance information DKY, from among the M encryption keys KS[q][1] to KS[q][M] issued to correspond to user U[q], encryption key KS[q] other than the last issued encryption key KS[q][M].
[0063] The per-terminal token response information DW includes Q pieces of token response information DSW[1] to DSW[Q] that correspond one-to-one to the Q terminal devices 1[1] to 1[Q] provided in the electronic payment system Sys. As described above, the token response information DSW[q] issued corresponding to the terminal device 1[q] indicates an online token response waiting time TSWX[q] that specifies the time length of the online token response waiting period TWX[q], and an offline token response waiting time TSWY[q] that specifies the time length of the offline token response waiting period TWY[q].
[0064] 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 contains payment information DP[q] corresponding to each electronic payment.
[0065] The control device 31 is configured to include a processor. The processor provided in the control device 31 is configured to include, for example, one or more CPUs. However, the processor provided in the control device 31 may be configured to include hardware such as a GPU, DSP, ASIC, PLD, FPGA, etc. in addition to the one or more CPUs, or in place of some or all of the one or more CPUs. The processor provided in the control device 31 executes a control program PG-S stored in the storage device 32 and operates 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.
[0066] The information supply unit 311 is an example of a "supply unit" and supplies the online token KX[q], online blocking information DHX, offline token KY[q], offline blocking information DHY, token response information DSW[q], operator identification token KZ, and setting information DS to the terminal device 1[q] in response to a request from the terminal device 1[q].
[0067] The information reception unit 312 is an example of a "reception unit", and receives terminal information DTM[q], an online token request, an online congestion information request, an offline token request, and an offline congestion information request from the terminal device 1[q]. Further, the information reception unit 312 receives settlement information DP[q] from the store device 5.
[0068] The settlement processing unit 313 is an example of a "settlement unit", and executes settlement processing based on the settlement information DP[q]. Specifically, in online electronic settlement, the settlement processing unit 313 executes online settlement processing based on the settlement information DP[q], and in offline electronic settlement, executes offline settlement processing based on the settlement information DP[q].
[0069] 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 information to the terminal device 1[q] via the communication device 35. Further, the information reception unit 312 acquires various information from the terminal device 1[q] and the store device 5 via the communication device 35.
[0070] <A.2. Operation of the Electronic Settlement System Sys> Hereinafter, the outline of the operation of the electronic settlement system Sys will be described while referring to FIGS. 4 to 13.
[0071] <A.2.1. Operation of the Electronic Settlement System Sys in Online Electronic Settlement> FIGS. 4 and 5 are sequence charts showing an example of the operation of the electronic settlement system Sys when the electronic settlement system Sys executes online electronic settlement.
[0072] As shown in Figure 4, 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 control device 11 of the terminal device 1[q] launches a payment app by executing the electronic payment program PG-T based on the operation of the user U[q] (S11).
[0073] Next, the control device 11 of the terminal device 1[q] determines whether the communication state of the terminal device 1[q] is online (S12). Specifically, the control device 11 may determine whether the communication state of the terminal device 1[q] is online, for example, using a communication state monitoring function of the terminal device 1[q] provided by the operating system of the terminal device 1[q]. Here, "the communication state of the terminal device 1[q] is online" may mean, for example, that the terminal device 1[q] is able to communicate with an external device outside the terminal device 1[q], or that when the terminal device 1[q] performs wireless communication, the radio wave intensity of the wireless communication is equal to or greater than a predetermined intensity. Note that the sequence charts shown in FIGS. 4 and 5 assume that the communication state of the terminal device 1[q] is online.
[0074] Next, if the process in step S11 is the first launch of the payment app on the terminal device 1[q], the electronic payment system Sys executes the following processes of steps S13 to S17. Note that if the process in step S11 is the second or subsequent launch of the payment app on the terminal device 1[q], the electronic payment system Sys skips the following processes of steps S13 to S17 and proceeds to step S21 shown in FIG.
[0075] Next, the information transmission unit 111 of the terminal device 1[q] transmits the terminal information DTM[q] to the payment device 3 (S13). Here, the terminal information DTM[q] is information about the performance of the terminal device 1[q]. In this embodiment, as an example, it is assumed that the terminal information DTM[q] indicates the memory capacity α of the terminal device 1[q]. Here, the memory capacity α is the capacity of a volatile memory such as a RAM in the storage device 12 of the terminal device 1[q].
[0076] Next, the control device 31 of the settlement device 3 supplies token response information DSW[q] to the terminal device 1[q] in response to the terminal information DTM[q] supplied from the terminal device 1[q] in step S13 (S14). Specifically, in step S14, the information receiving unit 312 of the payment device 3 acquires terminal information DTM[q] provided from the terminal device 1[q]. Next, the control device 31 of the payment device 3 generates token response information DSW[q] based on the terminal information DTM[q]. Then, the information providing unit 311 of the payment device 3 provides the generated token response information DSW[q] to the terminal device 1[q].
[0077] FIG. 6 is an explanatory diagram illustrating an example of the relationship between the terminal information DTM[q] acquired by the control device 31 in step S13 and the token response information DSW[q] supplied by the control device 31 in step S14.
[0078] 6, in this embodiment, in step S14, the control device 31 determines the online token response waiting time TSWX[q] to be a value TKX1 if the memory capacity α indicated by the terminal information DTM[q] is equal to or greater than a threshold value α0, and determines the online token response waiting time TSWX[q] to be a value TKX2 greater than the value TKX1 if the memory capacity α indicated by the terminal information DTM[q] is less than the threshold value α0. In this embodiment, as an example, it is assumed that the value TKX1 is "5 seconds" and the value TKX2 is "10 seconds."
[0079] Furthermore, in this embodiment, in step S14, if the memory capacity α indicated by the terminal information DTM[q] is equal to or greater than the threshold value α0, the control device 31 determines the offline token response waiting time TSWY[q] to be a value TKY1, and if the memory capacity α indicated by the terminal information DTM[q] is less than the threshold value α0, the control device 31 determines the offline token response waiting time TSWY[q] to be a value TKY2 greater than the value TKY1. Note that this embodiment assumes a case where the value TKY1 is smaller than the value TKX1, and the value TKY2 is smaller than the value TKX2. Specifically, this embodiment assumes, as an example, a case where the value TKY1 is "3 seconds" and the value TKY2 is "6 seconds."
[0080] In this embodiment, as an example, it is assumed that the terminal information DTM[q] indicates the memory capacity α of the terminal device 1[q], but the present invention is not limited to this aspect. The terminal information DTM[q] may indicate something other than the memory capacity α as long as it is information related to the performance of the terminal device 1[q]. For example, the terminal information DTM[q] may be information indicating the model name of the terminal device 1[q], information indicating the model number of the terminal device 1[q], or information indicating the type of processor that the terminal device 1[q] has.
[0081] FIG. 7 is an explanatory diagram illustrating another example of the relationship between the terminal information DTM[q] acquired by the control device 31 in step S13 and the token response information DSW[q] supplied by the control device 31 in step S14.
[0082] 7, it is assumed that the terminal information DTM[q] indicates the memory capacity α of the storage device 12 of the terminal device 1[q] as well as the processing speed β of the control device 11 of the terminal device 1[q]. Here, the processing speed β is the processing speed of a processor such as a CPU provided in the control device 11 of the terminal device 1[q].
[0083] In the example shown in FIG. 7, when the memory capacity α indicated by the terminal information DTM[q] is equal to or greater than the threshold α0 and the processing speed β indicated by the terminal information DTM[q] is equal to or greater than the threshold β0, the control device 31 determines the online token response waiting time TSWX[q] to be a value TKX11, and when the memory capacity α indicated by the terminal information DTM[q] is equal to or greater than the threshold α0 and the processing speed β indicated by the terminal information DTM[q] is less than the threshold β0, the control device 31 determines the online token response waiting time TSWX[q] to be a value T When the memory capacity α indicated by the terminal information DTM[q] is less than the threshold α0 and the processing speed β indicated by the terminal information DTM[q] is equal to or greater than the threshold β0, the online token response waiting time TSWX[q] is determined to be TKX21. When the memory capacity α indicated by the terminal information DTM[q] is less than the threshold α0 and the processing speed β indicated by the terminal information DTM[q] is less than the threshold β0, the online token response waiting time TSWX[q] is determined to be TKX22. Here, the value TKX12 is greater than the value TKX11, the value TKX21 is greater than the value TKX11, and the value TKX22 is greater than the value TKX21. Specifically, in the example shown in FIG. 7, it is assumed that the value TKX11 is "5 seconds", the value TKX12 is "8 seconds", the value TKX21 is "10 seconds", and the value TKX22 is "15 seconds".
[0084] In the example shown in FIG. 7 , when the memory capacity α indicated by the terminal information DTM[q] is equal to or greater than the threshold α0 and the processing speed β indicated by the terminal information DTM[q] is equal to or greater than the threshold β0, the control device 31 determines the offline token response waiting time TSWY[q] to be TKY11, and when the memory capacity α indicated by the terminal information DTM[q] is equal to or greater than the threshold α0 and the processing speed β indicated by the terminal information DTM[q] is less than the threshold β0, the control device 31 determines the offline token response waiting time TSWY[q] to be The offline token response waiting time TSWY[q] is determined to be the value TKY12, and when the memory capacity α indicated by the terminal information DTM[q] is less than the threshold value α0 and the processing speed β indicated by the terminal information DTM[q] is equal to or greater than the threshold value β0, the offline token response waiting time TSWY[q] is determined to be the value TKY21, and when the memory capacity α indicated by the terminal information DTM[q] is less than the threshold value α0 and the processing speed β indicated by the terminal information DTM[q] is less than the threshold value β0, the offline token response waiting time TSWY[q] is determined to be the value TKY22. Here, the value TKY12 is greater than the value TKY11, the value TKY21 is greater than the value TKY11, and the value TKY22 is greater than the value TKY21. 7, it is assumed that the value TKY11 is smaller than the value TKX11, the value TKY12 is smaller than the value TKX12, the value TKY21 is smaller than the value TKX21, and the value TKY22 is smaller than the value TKX22. Specifically, it is assumed that the value TKY11 is "3 seconds," the value TKY12 is "5 seconds," the value TKY21 is "6 seconds," and the value TKY22 is "9 seconds."
[0085] Returning to the explanation in Figure 4. 4, the information providing unit 311 of the payment device 3 provides a business operator identification token KZ to the terminal device 1[q] in response to the terminal information DTM[q] provided from the terminal device 1[q] in step S13 (S15). Specifically, in step S15, the control device 31 first generates a business operator identification token KZ based on the business operator identification information DKZ stored in the storage device 32. Then, the information providing unit 311 of the control device 31 provides the generated business operator identification token KZ to the terminal device 1[q]. Furthermore, the information supply unit 311 of the payment device 3 supplies setting information DS to the terminal device 1[q] in response to the terminal information DTM[q] supplied from the terminal device 1[q] in step S13 (S16). Specifically, in step S16, 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].
[0086] In the present embodiment, as an example, in steps S14 to S16, the payment device 3 transmits the token response information DSW[q] to the terminal device 1[q], then transmits the carrier identification token KZ, and then transmits the setting information DS. However, the present invention is not limited to this example. The order in which the token response information DSW[q], carrier identification token KZ, and setting information DS are transmitted from the payment device 3 to the terminal device 1[q] is arbitrary. For example, the payment device 3 may transmit the token response information DSW[q], carrier identification token KZ, and setting information DS to the terminal device 1[q] simultaneously (for example, in the same message).
[0087] Next, the information acquisition unit 112 of the terminal device 1[q] acquires the token response information DSW[q] supplied from the payment device 3 in step S14, the operator identification token KZ supplied from the payment device 3 in step S15, and the setting information DS supplied from the payment device 3 in step S16, and stores the acquired token response information DSW[q], operator identification token KZ, and setting information DS in the memory device 12 (S17).
[0088] As described above, if the launch of the payment app in step S11 is the first launch of the payment app on terminal device 1[q], the processes of steps S13 to S17 shown in Fig. 4 are executed. On the other hand, if the launch of the payment app in step S11 is the second or subsequent launch of the payment app on terminal device 1[q], the processes of steps S13 to S17 shown in Fig. 4 are omitted.
[0089] 5, the information sending unit 111 of the terminal device 1[q] sends an online blockage information request to the payment device 3 (S21). Here, the online blockage information request is a message requesting online blockage information DHX.
[0090] 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].
[0091] 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].
[0092] 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].
[0093] In the present embodiment, as an example, the 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 form. 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).
[0094] 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.
[0095] 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 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].
[0096] 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].
[0097] Then, the control device 31 of the payment device 3 supplies the terminal device 1[q] with an offline token KY[q] and an encryption key KS[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 an offline token KY[q] and an 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].
[0098] 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 form. 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. Furthermore, 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).
[0099] Next, the information acquisition unit 112 of the terminal device 1[q] acquires the offline token KY[q] and the encryption key KS[q] supplied 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). Note that since the acquisition of the offline token KY[q] in step S35 is the Mth acquisition (latest acquisition), the information acquisition unit 112 adds the 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 acquired offline token information KYY[q] as the encryption key KS[q][M]. In addition, in the present embodiment, as an example, it is assumed that the information acquisition unit 112 stores the offline blockage information DHY acquired in step S32 in the storage device 12. In addition, if the storage device 12 already stores offline blockage information DHY, the information acquisition unit 112 overwrites the offline blockage information DHY already stored in the storage device 12 with the offline blockage information DHY newly acquired in step S32.
[0100] Furthermore, the code generation unit 113 of the terminal device 1[q] determines whether the execution function of the online payment process in the payment device 3 is in a blocked state based on the online blockage information DHX acquired by the information acquisition unit 112 in step S22 (S41). Note that the sequence charts shown in FIGS. 4 and 5 assume that the execution function of the online payment process in the payment device 3 is not in a blocked state, that is, that the payment device 3 is able to execute the online payment process. Hereinafter, the state in which the execution function of the online payment process in the payment device 3 is in a blocked state may be referred to as an "online blocked state."
[0101] 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].
[0102] Thereafter, the display control unit 114 of the terminal device 1[q] generates display information for displaying an 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 an online code image display screen G1 including the online code image GX[q].
[0103] FIG. 8 is a schematic diagram showing an example of the online code image display screen G1.
[0104] As shown in FIG. 8, 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.
[0105] As described above, the online code image GX[q] is a barcode representing the online payment code CX[q]. However, the present invention is not limited to this. The online code image GX[q] may be, for example, a two-dimensional code representing the online payment code CX[q].
[0106] The point use selection button B1 is a button for selecting whether or not to use points granted to the user U[q] in online electronic payment. Although not shown in Figures 4 and 5, 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 from the terminal device 1[q] to the payment device 3.
[0107] The payment method display area A1 displays the payment method of user U[q] when user U[q] uses electronic payment in the electronic payment system Sys. Specifically, the display control unit 114 displays the payment method of user U[q] in the payment method display area A1 based on the user payment information DSH[q]. Note that, although not shown in Figures 4 and 5, this embodiment assumes, as an example, a case in which the payment device 3 supplies the user payment information DSH[q] to terminal device 1[q] in response to a request from terminal device 1[q]. The payment method of user U[q] displayed in the payment method display area A1 can be changed on the payment method selection screen GS, which will be described below.
[0108] FIG. 9 is a schematic diagram showing an example of the payment method selection screen GS.
[0109] 9, the payment method selection screen GS has three radio buttons RB, including a radio button RB1 for selecting combined telephone bill payment as the payment method for electronic payment, a radio button RB2 for selecting prepaid balance payment as the payment method for electronic payment, and a radio button RB3 for selecting credit card payment as the payment method for electronic payment, a decision button BS1 for determining the payment method for 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 selecting any one of the three radio buttons RB on the payment method selection screen GS and then pressing the decision button BS1, the user U[q] can select the payment method corresponding to the selected radio button RB as the payment method for user U[q] in the electronic payment system Sys.
[0110] Returning to the explanation of Figure 5. As shown in FIG. 5, the in-store device 5 performs 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] using a barcode reader or the like provided in the in-store device 5 (S44). The store device 5 then generates store payment information (store identification information, payment amount, payment date and time) based on the service content provided to user U[q] by the store where the store device 5 is installed, and generates payment information DP[q] (S61) that includes the generated store payment information and the payment code CC[q] (online payment code CX[q]) indicated by the code image GG[q] (online code image GX[q]) read in step S44. Then, the in-store device 5 transmits the payment information DP[q] generated in step S61 to the payment device 3 (S62).
[0111] 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 charts shown in FIGS. 4 and 5, 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).
[0112] <A.2.2. Operation of the Electronic Payment System Sys in Offline Electronic Payment> FIG. 10 is a sequence chart showing an example of the operation of the electronic payment system Sys when the electronic payment system Sys performs offline electronic payment. In FIG. 10, it is assumed that the electronic payment system Sys cannot perform online electronic payment due to the communication state of the terminal device 1[q] being in an offline state.
[0113] As shown in FIG. 10, when the user U[q] of the terminal device 1[q] receives a service at a store where the store device 5 is installed and pays the price of the service by electronic payment, the 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). In the sequence chart shown in FIG. 10, it is assumed that the start of the settlement application in step S11 is the second or subsequent start of the settlement application in the terminal device 1[q].
[0114] Next, the control device 11 of the terminal device 1[q] determines whether the communication state of the terminal device 1[q] is online (S12). As described above, the sequence chart shown in Fig. 10 assumes that the result of the determination in step S12 is negative, that is, the communication state of the terminal device 1[q] is offline.
[0115] If the result of the determination in step S12 is negative, the code generation unit 113 of the terminal device 1[q] determines whether the execution function of offline payment processing 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. 10 assumes that the execution function of offline payment processing in the payment device 3 is not in a blocked state, that is, that the payment device 3 is able to execute offline payment processing. Hereinafter, the state in which the execution function of offline payment processing in the payment device 3 is in a blocked state may be referred to as an "offline blocked state."
[0116] 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].
[0117] 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].
[0118] FIG. 11 is a schematic diagram showing an example of the offline code image display screen G2.
[0119] As shown in FIG. 11, 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.
[0120] As described above, the offline code image GY[q] is a barcode for representing the offline payment code CY[q]. In this 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 given to the user U[q] in offline electronic payment.
[0121] Returning to the explanation of FIG. As shown in FIG. 10, the store device 5 performs a process of reading the code image GG[q] (offline code image GY[q]) included in the screen (offline code image display screen G2) displayed on the display device 13 of the terminal device 1[q] (S55). The store device 5 then generates store payment information based on the service content provided to the user U[q] by the store where the 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).
[0122] Next, the payment processing unit 313 of the payment device 3 confirms 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] supplied from the in-store device 5 (S63). Note that the sequence chart shown in Fig. 10 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).
[0123] Fig. 12 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. 12, it is assumed that the electronic payment system Sys cannot execute online electronic payment because the terminal device 1[q] failed to acquire the online token KX[q] from the payment device 3.
[0124] As shown in Fig. 12, 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 processes of steps S11 and S12 described above are executed. Note that the sequence chart shown in Fig. 12 assumes that the launch of the payment app in step S11 is the second or subsequent launch of the payment app on the terminal device 1[q]. The sequence chart shown in Fig. 12 also assumes that the result of the determination in step S12 is positive, i.e., the communication status of the terminal device 1[q] is online.
[0125] Next, the information sending unit 111 of the terminal device 1[q] sends an online blockage information request to the payment device 3 (S21). However, the sequence chart shown in Fig. 12 assumes a case where there is no response from the payment device 3 to the online blockage information request. Furthermore, the information transmitting unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S23).
[0126] Then, the information transmission unit 111 of the terminal device 1[q] determines whether the online token response waiting period TWX[q] has ended (S29). Then, if there is no response from the payment apparatus 3 to the online token request during the online token response waiting period TWX[q], the information acquisition unit 112 of the terminal device 1[q] considers that the terminal device 1[q] has failed to acquire the online token KX[q] from the payment apparatus 3. Note that the sequence chart shown in FIG. 12 assumes a case where there is no response from the payment apparatus 3 to the online token request during the online token response waiting period TWX[q]. That is, as described above, the sequence chart shown in FIG. 12 assumes a case where the terminal device 1[q] has failed to acquire the online token KX[q] from the payment apparatus 3.
[0127] Furthermore, 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. 12 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).
[0128] Then, the information transmission unit 111 of the terminal device 1[q] determines whether the offline token response waiting period TWY[q] has ended (S39). Then, if there is no response from the payment device 3 to the offline token request during the offline token response waiting period TWY[q], the information acquisition unit 112 of the terminal device 1[q] determines that the terminal device 1[q] has failed to acquire the offline token KY[q] from the payment device 3. Note that the sequence chart shown in Fig. 12 assumes a case where there is no response from the payment device 3 to the offline token request during the offline token response waiting period TWY[q].
[0129] 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. 12 assumes that the payment device 3 is not in an offline blocked state, that is, that the payment device 3 is able to execute offline payment processing.
[0130] Thereafter, the electronic payment system Sys performs the processes of steps S52 to S55 and steps S61 to S65 to perform offline electronic payment.
[0131] Fig. 13 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. Note that Fig. 13 assumes that the electronic payment system Sys cannot execute online electronic payment because the payment device 3 is in an online blocked state.
[0132] As shown in FIG. 13, 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 through electronic payment, the process executes the above-described steps S11 and S12, steps S21 to S24, and steps S31 to S35. The sequence chart shown in FIG. 13 assumes that the activation of the payment app in step S11 is the second or subsequent activation of the payment app on the terminal device 1[q]. The sequence chart shown in FIG. 13 also assumes that the result of the determination in step S12 is positive, i.e., that the communication status of the terminal device 1[q] is online. The sequence chart shown in FIG. 13 also assumes that online blockage information DHX, online token KX[q], offline blockage information DHY, and offline token KY[q] are supplied from the payment device 3, as shown in steps S31 to S34. Thereafter, the code generation unit 113 of the terminal device 1[q] determines whether or not the payment device 3 is in an online blocked state based on the online blockage information DHX acquired by the information acquisition unit 112 in step S22 (S41). Note that the sequence chart shown in Fig. 13 assumes, as described above, that the payment device 3 is in an online blocked state, that is, that the payment device 3 is unable to execute online payment processing. If the result of the determination in step S41 is negative, i.e., if the payment device 3 is in an online blocked state, the code generation unit 113 of the terminal device 1[q] determines whether or not the payment device 3 is in an offline blocked state based on the offline blocked information DHY stored in the storage device 12 (S51). Note that the sequence chart shown in Fig. 13 assumes that the payment device 3 is not in an offline blocked state, i.e., that the payment device 3 is able to execute offline payment processing.
[0133] Thereafter, the electronic payment system Sys performs the processes of steps S52 to S55 and steps S61 to S65 (steps S55 and after are not shown), thereby performing offline electronic payment.
[0134] <Summary of the Operation of the Electronic Payment System Sys> As described above, in this embodiment, when the communication state of the terminal device 1[q] is offline, when the terminal device 1[q] fails to obtain the online token KX[q] from the payment device 3, and when the payment device 3 is in an online closed state, etc., when online electronic payment is difficult, the electronic payment system Sys performs offline electronic payment. Therefore, for example, compared with a mode in which the electronic payment system can only perform online electronic payment, 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 of difficulty in paying the price of the service by electronic payment can be reduced. Thereby, according to this embodiment, it is possible to reduce the decrease in convenience regarding the settlement of the user U[q] who has received a service at the store where the store device 5 is installed.
[0135] Also, in this embodiment, at the timing when the payment application is started (see step S11) in the terminal device 1[q] and electronic payment is executed, in addition to obtaining the online token KX[q] from the payment device 3 (see step S24), the terminal device 1[q] obtains the offline token KY[q] (see step S34). That is, in this embodiment, the terminal device 1[q] obtains 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, for example, compared with a mode in which the terminal device 1[q] obtains 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, it is possible to reduce the number of processes other than electronic payment in the terminal device 1[q]. Thereby, according to this embodiment, compared with a mode in which the terminal device 1[q] obtains the offline token KY[q] from the payment device 3 at a timing unrelated to the timing when electronic payment is performed, it is possible to reduce the complexity of schedule adjustment of the processes in the terminal device 1[q].
[0136] Furthermore, in this embodiment, when electronic payment is made, the terminal device 1[q] stores the offline token KY[q] acquired from the payment device 3 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 perform.
[0137] Furthermore, in this embodiment, the terminal device 1[q] displays the online code image GX[q] on the display device 13 only when the online blockage information DHX indicates that the payment device 3 is not in an online blockage state, and displays the offline code image GY[q] on the display device 13 only when the offline blockage information DHY indicates that the payment device 3 is not in an offline blockage state. That is, according to this embodiment, when it is difficult to perform 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 perform 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, the effort required by the user U[q] to display the code image GG[q] can be reduced compared to, for example, an embodiment in which the code image GG[q] is displayed without considering the blockage information DH.
[0138] Furthermore, in this embodiment, the length of the online token response waiting period TWX[q] during which the terminal device 1[q] waits for the supply of the online token KX[q] from the payment device 3, i.e., the online token response waiting time TSWX[q], is determined based on the performance of the terminal device 1[q]. That is, in this embodiment, the online token response waiting time TSWX[q] is adjusted according to the performance of the terminal device 1[q]. Therefore, according to this embodiment, compared to an embodiment in which the length of the online token response waiting period TWX[q] is fixed, even when the terminal device 1[q] has low performance, the terminal device 1[q] is more likely to be able to acquire the online token KX[q]. That is, according to this embodiment, compared to an embodiment in which the length of the online token response waiting period TWX[q] is fixed, the terminal device 1[q] is more likely to be able to execute an online electronic payment that displays the online code image GX[q] on the terminal device 1[q].
[0139] In the present embodiment, the payment device 3 supplies the setting information DS to the terminal device 1[q] when the payment app is first launched on the terminal device 1[q]. However, the present invention is not limited to this. For example, when the setting information DS is changed, the payment 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 payment app launch notification (not shown) indicating that the payment app has been launched on the terminal device 1[q] is supplied from the terminal device 1[q] to the payment device 3, the payment device 3 may supply the changed setting information DS to the terminal device 1[q] in response to the payment app launch notification. Furthermore, when a payment app launch notification is supplied from the terminal device 1[q] to the payment device 3, the payment device 3 may supply the setting information DS to the terminal device 1[q] regardless of whether the setting information DS has been changed.
[0140] Furthermore, in the present embodiment, an example has been given in which the payment device 3 provides the terminal device 1[q] with a carrier identification token KZ when the payment app is first launched on the terminal device 1[q]. However, the present invention is not limited to this example. For example, if the carrier identification information DKZ is changed, the payment device 3 may provide the terminal device 1[q] with a carrier identification token KZ indicating the changed carrier identification information DKZ. Specifically, if the carrier identification information DKZ is changed and the terminal device 1[q] provides the payment device 3 with a payment app launch notification, the payment device 3 may provide the terminal device 1[q] with a carrier identification token KZ based on the changed carrier identification information DKZ in response to the payment app launch notification. In this case, the terminal device 1[q] acquires the carrier identification token KZ less frequently than the online token KX[q]. In this case, the terminal device 1[q] acquires the carrier identification token KZ less frequently than the offline token KY[q]. In addition, for example, when a payment app launch notification is supplied from terminal device 1[q] to payment device 3, payment device 3 may supply a business operator identification token KZ to terminal device 1[q] regardless of whether the business operator identification information DKZ has changed.
[0141] In addition, in this embodiment, an example is given of a mode in which when the settlement application is first started in the terminal device 1[q], the token response information DSW[q] is supplied from the settlement device 3 to the terminal device 1[q]. However, the present invention is not limited to such a mode. For example, when the token response information DSW[q] is changed, the settlement device 3 may supply the changed token response information DSW[q] to the terminal device 1[q]. Specifically, when the token response information DSW[q] is changed and a settlement application start notification is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply the changed token response information DSW[q] to the terminal device 1[q] as a response to the settlement application start notification. Further, for example, when a settlement application start notification is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply the token response information DSW[q] to the terminal device 1[q] regardless of whether the token response information DSW[q] has been changed.
[0142] <A.3. Outline of the settlement code CC[q]> Hereinafter, while referring to FIG. , the outline of the settlement code CC[q] (online settlement code CX[q] and offline settlement code CY[q]) will be described.
[0143] FIG. is a diagram showing an example of the data configuration of the online settlement code CX[q] and the offline settlement code CY[q].
[0144] As shown in FIG. , 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. 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. [[ID=The operator 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 (0 to 9). However, the code value VZ may be 1-digit data composed of a single alphanumeric character (a single digit or a single alphabet).
[0146] 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 (0 to 9). However, the code value VX may be 1-digit data composed of a single alphanumeric character (a single digit or a single alphabet).
[0147] 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 (0 to 9). However, the code value VY may be 1-digit data composed of a single alphanumeric character (a single digit or a single alphabet).
[0148] 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 also be one-digit data consisting of one alphanumeric character (one digit number or one alphabet).
[0149] The allocation value VJ is one-digit data consisting of a single-digit number (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.
[0150] The code type value VV is one-digit data consisting of a single 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 payment code CC[q] is set in the code type value VV. Specifically, if 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], such as "1," is set in the code type value VV. Hereinafter, a value indicating that the payment code CC[q] is the online payment code CX[q] is referred to as the "online code value." Furthermore, if 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], such as "2," is set in the code type value VV. Hereinafter, a value indicating that the payment code CC[q] is the offline payment code CY[q] is referred to as the "offline code value."
[0151] The following describes the process by which the code generation unit 113 generates a payment code CC[q] (hereinafter referred to as the "code generation process"). Note that, hereinafter, the process by the code generation unit 113 to generate an online payment code CX[q] is referred to as the "online code generation process." Also, hereinafter, the process by the code generation unit 113 to generate an offline payment code CY[q] is referred to as the "offline code generation process."
[0152] In the online code generation process, the code generation unit 113 sets an online code value (for example, "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 allocation value VJ, and the code type value VV.
[0153] 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 the offline payment code CY[q] by arranging in a predetermined order the business identification token KZ stored in the storage device 12, the offline token KY[q] acquired by the information acquisition unit 112 from the payment device 3, the time encryption code TT[q] generated by the code generation unit 113, the allocation value VJ, and the code type value VV. In 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].
[0154] 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 identification token KZ, the offline token KY[q], the updated time encryption code TT[q], the allocation value VJ, and the code type value VV in a predetermined order.
[0155] Hereinafter, among the time encryption codes TT[q], 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, hereinafter, 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".
[0156] Thus, in this embodiment, the offline settlement code CY[q] includes, in addition to the offline token KY[q] that is updated every offline token valid time TSY (for example, one week), a time encryption code TT[q] that is updated every update unit time TC (for example, one minute), which is a time shorter than the offline token valid time TSY. That is, in this embodiment, the offline settlement code CY[q] is updated every update unit time TC, which is the update period of the time encryption code TT[q]. Therefore, according to this embodiment, compared with the mode in which the offline settlement code CY[q] is configured without including the time encryption code TT[q], the security risk associated with the leakage of the offline settlement code CY[q] can be reduced.
[0157] 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.
[0158] <A.4. Operation of Terminal Device 1[q]> Hereinafter, referring to FIGS. 15 to 21, an overview of the operation of the terminal device 1[q] when electronic settlement is executed will be described.
[0159] 15 to 20 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. The flowcharts shown in Fig. 15 to 20 start when the payment application is launched on the terminal device 1[q].
[0160] As shown in FIG. 15, when a payment app is launched on terminal device 1[q], the control device 11 of terminal device 1[q] determines whether the launch of the payment app is the first launch of the payment app on terminal device 1[q] (S001). If the result of the determination in step S001 is negative, that is, if the activation of the payment application in the terminal device 1[q] is the second or subsequent activation, the control device 11 of the terminal device 1[q] proceeds to step S101.
[0161] If the result of the determination in step S001 is positive, i.e., if the launch of the payment app on the terminal device 1[q] is the first launch, the control device 11 of the terminal device 1[q] determines whether the communication state of the terminal device 1[q] is online (S003) and waits until the communication state of the terminal device 1[q] becomes online (S003: Y). The processing of step S003 corresponds to the processing of step S12 described above. Note that, if the terminal device 1[q] maintains the offline state (S003: N) for a predetermined time or more in step S003, the display control unit 114 of the terminal device 1[q] may, for example, display an error screen on the display device 13.
[0162] If the result of the judgment in step S003 is positive, that is, if the communication status of the terminal device 1[q] is online, the control device 11 of the terminal device 1[q] identifies the memory capacity α of the terminal device 1[q] and generates terminal information DTM[q] indicating the identified memory capacity α (S005). Next, the information transmitting unit 111 of the terminal device 1[q] transmits the terminal information DTM[q] generated in step S005 to the settlement device 3 (S007). The process of step S007 corresponds to the process of step S13 described above. Next, the control device 11 of the terminal device 1[q] determines whether or not there is a response from the payment device 3 (S009), and waits until there is a response from the payment device 3 (S009: Y). Note that, in step S009, if there is no response from the payment device 3 (S009: N) continues for a predetermined time or longer, the display control unit 114 of the terminal device 1[q] may, for example, display an error screen on the display device 13.
[0163] If the result of the judgment in step S009 is positive, that is, if there is a response from the payment device 3, the information acquisition unit 112 of the terminal device 1[q] acquires the token response information DSW[q] supplied from the payment device 3 (S011). If the result of the determination in step S009 is positive, the information acquisition unit 112 of the terminal device 1[q] acquires the business identification token KZ supplied from the payment device 3 (S013). If the result of the determination in step S009 is positive, the information acquisition unit 112 of the terminal device 1[q] acquires the setting information DS supplied from the settlement device 3 (S015). Then, the information acquisition unit 112 of the terminal device 1[q] stores the token response information DSW[q] acquired in step S111, the carrier identification token KZ acquired in step S113, and the setting information DS acquired in step S115 in the storage device 12 (S017), and proceeds to step S103. Note that the processing in step S017 corresponds to the processing in step S17 described above.
[0164] 16, the control device 11 of the terminal device 1[q] determines whether the communication state of the terminal device 1[q] is online (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.
[0165] 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 sending unit 111 of the terminal device 1[q] sends 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.
[0166] 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 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).
[0167] 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.
[0168] Then, if the communication device 15 receives the online token KX[q] sent from the payment device 3 in 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) and proceeds to step S117.
[0169] On the other hand, if there is no response to the online token request from the payment apparatus 3 (S111: N), the information acquisition unit 112 of the terminal device 1[q] determines whether the online token response waiting period TWX[q] has ended (S115). If the result of the judgment in step S115 is negative, i.e., if the online token response waiting period TWX[q] has not ended, the information acquisition unit 112 returns the processing to step S109, thereby causing the information transmission unit 111 to repeat the transmission of the online token request. If the result of the determination in step S115 is positive, that is, if the online token response waiting period TWX[q] has ended, the information acquisition unit 112 advances the process to step S117.
[0170] 17, the information transmitting unit 111 of the terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S117). The process of step S117 corresponds to the process of step S31 described above.
[0171] Then, if there is no response to the offline blockage information request from the payment device 3 (S119: N), the control device 11 of the terminal device 1[q] proceeds to step S123. On the other hand, if the communication device 15 receives offline blockage information DHY transmitted from the payment device 3 as a response to the offline blockage information request (S119: Y), the information acquisition unit 112 of the terminal device 1[q] acquires the offline blockage information DHY (S121).
[0172] Furthermore, the information transmitting unit 111 of the terminal device 1[q] transmits an offline token request to the payment device 3 (S123). The process of step S123 corresponds to the process of step S33 described above.
[0173] Then, when the communication device 15 receives the offline token KY[q] and the encryption key KS[q] transmitted from the payment apparatus 3 as a response to the offline token request (S125: 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 (S127), and proceeds to step S131. Specifically, in step S127, the information acquisition unit 112 acquires the offline token KY[q] and the encryption key KS[q] provided from the payment apparatus 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 acquired offline token information KYY[q] as the latest encryption key KS[q][M]. The processing of step S127 corresponds to the processing of step S35 described above.
[0174] On the other hand, if there is no response to the offline token request from the payment apparatus 3 (S125: N), the information acquisition unit 112 of the terminal device 1[q] determines whether the offline token response waiting period TWY[q] has ended (S129). If the result of the judgment in step S129 is negative, that is, if the offline token response waiting period TWY[q] has not ended, the information acquisition unit 112 returns the processing to step S123, thereby causing the information transmission unit 111 to repeat the transmission of the offline token request. If the result of the determination in step S129 is positive, that is, if the offline token response waiting period TWY[q] has ended, the information acquisition unit 112 advances the process to step S131.
[0175] 18, 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). Specifically, in step S131, the code generation unit 113 determines 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 processing of step S131 corresponds to the processing of step S41 described above.
[0176] If the result of the judgment in step S131 is negative, that is, 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 blockage 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.
[0177] 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 online code generation processing to generate the online payment code CX[q] (S135). The processing in step S135 corresponds to the processing in step S42 described above.
[0178] 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). The processing of step S137 corresponds to the processing of step S43 described above.
[0179] 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 according to the flowcharts shown in FIGS.
[0180] If the result of the determination in step S139 is negative, that is, if the termination operation has not been performed, the code generation unit 113 of the terminal device 1[q] determines whether 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.
[0181] In this embodiment, it is assumed that an opportunity to update an online code image is deemed to have occurred when 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 validity time TSX (five 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 while the online code image display screen G1 including the online code image GX[q] is displayed on the display device 13.
[0182] 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 processing 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 an 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 (S143).
[0183] Then, 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.
[0184] On the other hand, if there is no response from the payment device 3 to the online token request in step S143 (S145: N), the information acquisition unit 112 of the terminal device 1[q] determines whether the online token response waiting period TWX[q] has ended (S149). If the result of the judgment in step S149 is negative, i.e., if the online token response waiting period TWX[q] has not ended, the information acquisition unit 112 returns the processing to step S143, thereby causing the information transmission unit 111 to repeat the transmission of the online token request. If the result of the determination in step S149 is positive, that is, if the online token response waiting period TWX[q] has ended, the information acquisition unit 112 advances the process to step S151.
[0185] 19, 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 offline blocked information DHY in step S121, and whether the offline blocked information DHY indicates that the payment device 3 is not in an offline blocked state. The processing of step S151 corresponds to the processing of step S51 described above.
[0186] If the result of the judgment in step S151 is negative, that is, if the information acquisition unit 112 has not acquired the offline blockage information DHY in step S121, or if the offline blockage information DHY indicates that the payment device 3 is in an offline blockage state, the control device 11 of the terminal device 1[q] proceeds to step S171.
[0187] 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 blockage 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 determines whether one or more offline tokens KY[q][1] to KY[q][M] are stored in the storage device 12 and whether the offline token validity period TY[q][M] corresponding to the latest offline token KY[q][M] stored in the storage device 12 is a period that includes the current time. If the result of the determination is positive, the code generation unit 113 acquires the latest offline token KY[q][M] from the storage device 12. The processing of step S153 corresponds to the processing of step S52 described above.
[0188] 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.
[0189] 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 processing of step S155 may be omitted.
[0190] FIG. 21 is a schematic diagram showing an example of the offline payment explanation screen G3.
[0191] As shown in FIG. 21, the offline payment explanation screen G3 includes an offline payment explanation display area A3, an explanation screen omission button CB3, and an offline payment confirmation button B3.
[0192] The offline payment explanation display area A3 is an area where text explaining offline electronic payment to user U[q] is displayed. The explanation screen omission button CB3 is a button for accepting an operation from the user U[q] to omit 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 offline electronic payment.
[0193] Returning to the explanation of FIG. 19, 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 offline code generation processing 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 processing of step S157 corresponds to the processing of step S53 described above.
[0194] 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). The process of step S159 corresponds to the process of step S54 described above.
[0195] 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 according to the flowcharts shown in FIGS.
[0196] If the result of the determination in step S161 is negative, that is, if the termination operation has not been performed, the code generation unit 113 of the terminal device 1[q] determines whether or not an 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.
[0197] In this embodiment, it is assumed that the opportunity to update the offline code image is deemed to have arrived when at least one of two update conditions J2, the offline code image display condition J22 and the offline code image operation condition J23, is met. 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. Furthermore, the offline code image operation condition J23 is a condition that a pull-down operation is performed while the offline code image display screen G2 including the offline code image GY[q] is displayed on the display device 13.
[0198] 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] proceeds to step S101 and again executes the series of processes related to the flowcharts shown in Figures 15 to 20.
[0199] 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 displaying the offline code image GY[q] on the display device 13.
[0200] If the result of the judgment in step S165 is positive, i.e., if the terminal time value AG is 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).
[0201] 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 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.
[0202] As shown in Figure 20, when the offline code generation process is difficult, such as when the terminal device 1[q] is in an offline blocked state (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 execution of online electronic payment is waiting (S171).
[0203] Then, the information transmission unit 111 of the terminal device 1[q] determines whether or not 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.
[0204] When the terminal device 1[q] and the payment device 3 are 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, if 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 and resends the online token request. On the other hand, if the communication device 15 receives the online token KX[q] sent 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).
[0205] Next, the code generation unit 113 of the terminal device 1[q] executes online code generation processing using the online token KX[q] acquired in step S179, and generates an online payment code CX[q] (S181).
[0206] Then, the display control unit 114 of the terminal device 1[q] uses the online payment code CX[q] generated in step S181 to generate display information for displaying an 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 (S183).
[0207] 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 according to the flowcharts shown in FIGS.
[0208] 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).
[0209] If the result of the judgment 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 processing to step S183 and continues displaying the online code image GX[q] on the display device 13. If the result of the determination in step S187 is positive, that is, if the opportunity to update the online code image has arrived, the information sending unit 111 of the terminal device 1[q] sends an online token request to the payment device 3 (S189).
[0210] Then, if there is no response to the online token request in step S189 from the payment apparatus 3 (S191: N), the control device 11 of the terminal device 1[q] proceeds to step S171. On the other hand, if the communication device 15 receives the online token KX[q] transmitted from the payment apparatus 3 in 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 proceeds to step S181, thereby generating an online payment code CX[q] based on the online token KX[q] acquired in step S193.
[0211] Thus, according to this embodiment, offline electronic payment is performed when online electronic payment is difficult, such as when the online access 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 can only perform online electronic payment, when a user U[q] of the terminal device 1[q] receives a service at a store where the in-store device 5 is installed, it is possible to reduce the possibility that the user U[q] of the terminal device 1[q] will have difficulty paying for the service by electronic payment.
[0212] 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.
[0213] Also, according to the present embodiment, in the case of an offline closed 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 [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.
[0214] <A.5. Operation of Settlement Device 3> Hereinafter, referring to FIGS. 22 to 25, an outline of the operation of the settlement device [3] when electronic settlement is executed will be described. <A.5.1. Token Response Information Supply Process>
[0215] FIG. 22 is a flowchart showing an example of the operation of the settlement device 3 when the token response information supply process is executed. Here, the token response information supply process is a process of supplying various information such as token response information DSW[q] from the settlement device 3 to the terminal device 1[q] corresponding to the terminal information DTM[q] from the terminal device 1[q] when electronic settlement is executed in the electronic settlement system Sys.
[0216] As shown in FIG. 22, when terminal information DTM[q] is transmitted from terminal device 1[q], information receiving unit 312 of payment apparatus 3 receives the terminal information DTM[q] (S401).
[0217] Next, the control device 31 of the settlement device 3 determines the online token response waiting time TSWX[q] based on the terminal information DTM[q] (S403). Furthermore, the control device 31 of the settlement device 3 determines the offline token response waiting time TSWY[q] based on the terminal information DTM[q] (S405). Then, the control device 31 of the payment device 3 generates token response information DSW[q] indicating the online token response waiting time TSWX[q] determined in step S403 and the offline token response waiting time TSWY[q] determined in step S405 (S407).
[0218] Next, the control device 31 of the settlement device 3 adds the token response information DSW[q] generated in step S407 to the token response information DW for each terminal, thereby updating the token response information DW for each terminal (S409). Furthermore, the information supply unit 311 of the settlement apparatus 3 supplies the token response information DSW[q] generated in step S407 to the terminal apparatus 1[q] (S411). Furthermore, the information supply unit 311 of the settlement device 3 supplies the business identification token KZ generated based on the business identification information DKZ stored in the storage device 32 to the terminal device 1[q] (S413). Furthermore, the information supply unit 311 of the settlement apparatus 3 supplies the setting information DS stored in the storage device 32 to the terminal apparatus 1[q] (S415), and ends the token response information supply process.
[0219] 23 is a flowchart showing an example of the operation of the payment device 3 when the online token generation process is executed in the payment device 3. Here, the online token generation process is a process of generating an online token KX[q] in response to an online token request from the terminal device 1[q] when electronic payment is executed in the electronic payment system Sys.
[0220] As shown in FIG. 23, 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).
[0221] 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 time when the online token KX[q] is generated and ending from the time when the online token KX[q] is generated, the time when the online token validity period TSX (for example, 5 minutes) has elapsed.
[0222] 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.
[0223] 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.
[0224] 24 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.
[0225] As shown in FIG. 24, when an offline token request is transmitted from the terminal device 1[q], the information receiving unit 312 of the settlement apparatus 3 receives the offline token request (S321).
[0226] 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 time when the offline token KY[q] is generated and ending from the time when the offline token KY[q] is generated, the time when the offline token validity period TSY (for example, one week) has elapsed. Furthermore, the control device 31 of the settlement device 3 generates an encryption key KS[q] (S327).
[0227] 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] decided in step S325, and the encryption key KS[q] generated in step S327.
[0228] 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.
[0229] 25 and 26 are flowcharts showing an example of the operation of the payment device 3 when payment-related processing is executed in the payment device 3. Here, the payment-related processing includes processing for confirming the validity of the token KK[q] in the payment device 3 and payment processing executed by the payment device 3. When payment information DP[q] is supplied from the in-store device 5, the payment device 3 starts the payment-related processing.
[0230] As shown in FIG. 25, 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).
[0231] 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].
[0232] If the result of the determination in step S345 is negative, that is, if the payment code CC[q] included in the payment information DP[q] is the offline payment code CY[q], the payment processing unit 313 of the payment device 3 proceeds to step S361. If the result of the judgment in step S345 is positive, that is, if the payment code CC[q] included in the payment information DP[q] is the online payment code CX[q], the payment processing unit 313 of the payment device 3 extracts the online token KX[q] from the online payment code CX[q] included in the payment information DP[q] accepted in step S341 (S347).
[0233] Next, the settlement processing unit 313 of the settlement apparatus 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 apparatus 3 proceeds to step S357.
[0234] If the result of the judgment in step S349 is positive, that is, 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 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 by referring to the online token payout information DKX (S351). If the result of the judgment in step S351 is negative, that is, if the online token validity period TX[q] corresponding to the online token KX[q] extracted in step S347 does not include the current time, the payment processing unit 313 of the payment device 3 proceeds to step S357.
[0235] If the result of the judgment in step S351 is positive, that is, if the online token validity period TX[q] corresponding to the online token KX[q] extracted in step S347 includes the current time, the 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.
[0236] On the other hand, if the result of the judgment in step S349 is negative, or 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.
[0237] As shown in Figure 26, if the result of the judgment in step S345 is negative, that is, if the payment code CC[q] included in the payment information DP[q] is the offline payment code CY[q], the payment processing unit 313 of the payment device 3 extracts the offline token KY[q] from the offline payment code CY[q] included in the payment information DP[q] accepted in step S341 (S361).
[0238] Next, the settlement processing unit 313 of the settlement 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 settlement processing unit 313 of the settlement apparatus 3 advances the process to step S381.
[0239] If the result of the judgment in step S363 is positive, that is, 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 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 by referring to the offline token issuance information DKY (S365). If the result of the judgment in step S365 is negative, that is, if the offline token validity period TY[q] corresponding to the offline token KY[q] extracted in step S361 does not include the current time, the payment processing unit 313 of the payment device 3 proceeds to step S381.
[0240] 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 before the time when the payment information DP[q] was accepted in step S341 (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 prohibited period") (S367). If the result of the judgment in step S367 is positive, that is, 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.
[0241] If the result of the judgment in step S367 is negative, that is, 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).
[0242] Furthermore, 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).
[0243] Next, the payment processing unit 313 of the payment apparatus 3 encrypts the server time value AM, the future time value AMf, and the past time value AMp using the encryption key KS[q] identified in step S371 (S373).
[0244] Here, the server time value AM is a value based on the server time TM, which is the current time managed by the payment apparatus 3, and is a value that is updated periodically at 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, if the server time TM is "18:25:37," the server time value AM may be "1825," which is obtained 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 have the same value as the terminal time value AG. However, in reality, there may be a slight difference between the server time TM and the terminal time TG. In this case, the server time value AM and the terminal time value AG may have different values. Furthermore, 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 "18:26:37," a time that is one minute in the future than the server time TM, with "37 seconds" deleted. 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 "18:24:37," a time that is one minute in the past than the server time TM, with "37 seconds" deleted.
[0245] In the following, the value obtained by encrypting the server time value AM with the encryption key KS[q] will be referred to as the server time encryption code CM (an example of a "first time code"), the value obtained by encrypting the future time value AMf with the encryption key KS[q] will be referred to as the future time encryption code CMf (an example of a "second time code"), and the value obtained by encrypting the past time value AMp with the encryption key KS[q] will be referred to as the past time encryption code CMp (an example of 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 using the encryption key KS[q]; a future time encryption code CMf obtained by encrypting the future time value AMf using the encryption key KS[q]; and a past time encryption code CMp obtained by encrypting the past time value AMp using the encryption key KS[q].
[0246] 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).
[0247] If the result of the judgment in step S375 is positive, that is, if the time encryption code CMM generated in step S373 matches the time encryption code TT[q] extracted in step S369, the 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 billing 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.
[0248] On the other hand, if the result of the judgment in step S363 is negative, if the result of the judgment in step S365 is negative, if the result of the judgment in step S367 is positive, or if 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.
[0249] As described above, in this embodiment, the payment device 3 can perform two types of payment processing: online payment processing and offline payment processing. Therefore, compared to, for example, an embodiment in which the payment device 3 can perform only online payment processing, the convenience of the user U[q] who uses electronic payment can be improved.
[0250] Furthermore, in this embodiment, if two or more pieces of payment information DP[q] including the same offline token KY[q] are supplied during a same-token prohibition period having a time length twice the update unit time TC, the payment device 3 restricts offline payment processing based on the payment information DP[q] supplied the second time onwards. Therefore, according to this embodiment, it is possible to restrict fraudulent payments using the offline token KY[q], thereby reducing security risks in the event that the offline token KY[q] is leaked, for example.
[0251] In addition, in this embodiment, the settlement device 3 verifies the validity of the time encryption code TT[q] included in the offline settlement code CY[q] using the future time value AMf and the past time value AMp in addition to the server time value AM in settlement-related processing. 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 settlement-related processing, compared with the mode of verifying the validity of the time encryption code TT[q] based only on the server time value AM, the possibility that the user U[q] can use electronic settlement can be improved, and the convenience of the user U[q] using electronic settlement can be improved.
[0252] <B. Second Embodiment> Hereinafter, the second embodiment of the present invention will be described while referring to FIGS. 27 to 35. In each of the embodiments illustrated below, for elements whose operations and functions are the same as those in the first embodiment, the reference numerals used in the description of the first embodiment are reused, and the detailed description of each is appropriately omitted.
[0253] The electronic settlement system Sys according to the second embodiment has the same configuration as the electronic settlement system Sys according to the first embodiment. In the electronic settlement system Sys according to the first embodiment, when performing online electronic settlement, in the terminal device 1[q], after obtaining the offline token KY[q], generation of the online settlement code CX[q] and display of the online code image GX[q] were performed. However, in the electronic settlement system Sys according to the second embodiment, when performing online electronic settlement, in the terminal device 1[q], generation of the online settlement code CX[q] and display of the online code image GX[q] are executed with higher priority than obtaining the offline token KY[q].
[0254] FIGS. 27 and 28 are sequence charts showing an example of the operation of the electronic settlement system Sys when the electronic settlement system Sys according to the second embodiment executes online electronic settlement.
[0255] As described above, in the sequence chart of online electronic payment according to the first embodiment shown in Figures 4 and 5, in the electronic payment system Sys, after the processing of steps S21 to S24 relating to the acquisition of online token KX[q] by terminal device 1[q] and the processing of steps S31 to S35 relating to the acquisition of offline token KY[q] by terminal device 1[q], the processing of steps S41 to S43 relating to the display of online code image GX[q] by terminal device 1[q] is executed. In contrast, the sequence chart of online electronic payment according to the second embodiment shown in Figures 27 and 28 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 online token KX[q] by terminal device 1[q] and the processing of steps S41 to S43 relating to the display of online code image GX[q] by terminal device 1[q], the processing of steps S31 to S35 relating to the acquisition of offline token KY[q] by terminal device 1[q] is executed.
[0256] That is, in the second embodiment, displaying the online code image GX[q] takes priority over obtaining 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 obtaining the offline token KY[q], and online electronic payment can be performed quickly.
[0257] 29 to 35 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 Figs. 29 to 35 start when the payment application is launched on the terminal device 1[q]. Note that the flowcharts shown in Figs. 29 to 35 differ from the flowcharts according to the first embodiment shown in Figs. 15 to 20 in that the processes of steps S117 to S129 are not present and that the processes of steps S201 to S233 are present.
[0258] As shown in FIG. 29, when the payment application is started up in the terminal device 1[q], the control device 11 of the terminal device 1[q] executes the processes of steps S001 to S017 described above. Specifically, the control device 11 of the terminal device 1[q] determines whether the activation of the payment app is the first activation of the payment app in the terminal device 1[q] (S001). If the result of the determination in step S001 is negative, that is, the control device 11 of the terminal device 1[q] proceeds to step S101. If the result of the determination in step S001 is positive, the control device 11 of the terminal device 1[q] waits until the communication status of the terminal device 1[q] becomes online (S003:Y), generates terminal information DTM[q] indicating the memory capacity α of the terminal device 1[q] (S005), and transmits the generated terminal information DTM[q] to the payment device 3 (S007). Next, when there is a response from the payment device 3 (S009: Y), the control device 11 of the terminal device 1[q] acquires the token response information DSW[q] supplied from the payment device 3 (S011), acquires the business identification token KZ supplied from the payment device 3 (S013), and acquires the setting information DS supplied from the payment device 3 (S015). Then, the control device 11 of the terminal device 1[q] stores the token response information DSW[q] acquired in step S111, the business identification token KZ acquired in step S113, and the setting information DS acquired in step S115 in the storage device 12 (S017), and proceeds to step S103.
[0259] As shown in FIG. 30, when the payment application is started up in the terminal device 1[q], the control device 11 of the terminal device 1[q] executes the processes of steps S101 to S115 described above. Specifically, the control device 11 of the terminal device 1[q] first determines whether the communication state of the terminal device 1[q] is online (S101). If the result of the determination in step S101 is negative, the control device 11 of the terminal device 1[q] proceeds to step S151. If the result of the determination in step S101 is positive, the information transmission unit 111 of the terminal device 1[q] transmits an online blockage information request to the payment device 3 (S103). Then, if 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). Furthermore, the information transmission unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S109). Then, if 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) and proceeds to step S131. On the other hand, if the online token KX[q] is not received (S111: N), the information acquisition unit 112 of the terminal device 1[q] determines whether the online token response waiting period TWX[q] has ended (S115). If the result of the determination in step S115 is negative, the information acquisition unit 112 returns the process to step S109, thereby causing the information transmission unit 111 to repeat transmission of the online token request. If the result of the determination in step S115 is positive, the information acquisition unit 112 proceeds to step S131.
[0260] 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] proceeds to step S221. Even if the result of the determination in step S131 is positive, if the information acquisition unit 112 has not acquired the online token KX[q] in step S113 (S133:N), the control device 11 of the terminal device 1[q] proceeds to step S221.
[0261] As shown in FIG. 31, the control device 11 of the terminal device 1[q] executes the processes of steps S135 to S139 described above. Specifically, if the result of the determination in step S131 is positive and the information acquisition unit 112 acquires the online token KX[q] in step S113 (S133: Y), the code generation unit 113 of the terminal device 1[q] generates 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 an online code image GX[q] (S137). Next, the control device 11 of the terminal device 1[q] determines whether a termination operation has been performed (S139).
[0262] As shown in FIG. 32, 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 S213. Specifically, the information transmitting 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, if 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] proceeds to the process of step S207. On the other hand, if the communication device 15 receives offline blockage information DHY transmitted from the payment device 3 as a response to the offline blockage information request (S203: Y), the information acquiring unit 112 of the terminal device 1[q] acquires the offline blockage information DHY (S205). Furthermore, the information transmitting 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 the communication device 15 receives the offline token KY[q] and the encryption key KS[q] transmitted from the payment apparatus 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 the series of processes related to the flowcharts shown in Figures 29 to 35. On the other hand, when there is no response to the offline token request from the payment apparatus 3 (S209: N), the information acquisition unit 112 of the terminal device 1[q] determines whether the offline token response waiting period TWY[q] has ended (S213). If the result of the determination in step S213 is negative, the information acquisition unit 112 returns the process to step S207, thereby repeating the transmission of the offline token request by the information transmission unit 111. If the result of the determination in step S213 is positive, the control device 11 of the terminal device 1[q] ends the series of processes related to the flowcharts shown in Figs. 29 to 35.
[0263] As shown in FIG. 31, 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 S149 described above. Specifically, the code generation unit 113 of the terminal device 1[q] determines whether an opportunity to update the online code image has arrived (S141). If the result of the determination in step S141 is negative, the control device 11 returns the process to step S137 and continues displaying the online code image GX[q] on the display device 13. If the result of the determination in step S141 is positive, the information transmission unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S143). Then, if the communication device 15 receives the online token KX[q] transmitted 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 the process in step S135, and generates an online payment code CX[q] in step S135 based on the online token KX[q] acquired in step S147. On the other hand, if there is no response to the online token request in step S143 from the payment device 3 (S145: N), the information acquisition unit 112 of the terminal device 1[q] determines whether the online token response waiting period TWX[q] has ended (S149). If the result of the determination in step S149 is negative, the information acquisition unit 112 returns the process to step S143, thereby causing the information transmission unit 111 to repeat the transmission of the online token request. If the result of the determination in step S149 is positive, the control device 11 of the terminal device 1[q] proceeds to step S151.
[0264] As shown in FIG. 33, 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 S233. Specifically, the information transmitting unit 111 of the terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S221). Then, if 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] proceeds to step S227. On the other hand, if the communication device 15 receives offline blockage information DHY transmitted from the payment device 3 as a response to the offline blockage information request (S223: Y), the information acquiring unit 112 of the terminal device 1[q] acquires the offline blockage information DHY (S225). Furthermore, the information transmitting unit 111 of the terminal device 1[q] transmits an offline token request to the payment device 3 (S227). Then, when the communication device 15 receives the offline token KY[q] and the encryption key KS[q] transmitted from the payment apparatus 3 as a 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), and the process proceeds to step S151. On the other hand, when there is no response to the offline token request in step S227 from the payment apparatus 3 (S229: N), the information acquisition unit 112 of the terminal device 1[q] determines whether the offline token response waiting period TWY[q] has ended (S233). If the result of the determination in step S233 is negative, the information acquisition unit 112 returns the process to step S227, thereby causing the information transmission unit 111 to repeat transmission of the offline token request. If the result of the determination in step S233 is positive, the control device 11 of the terminal device 1[q] proceeds to step S151.
[0265] Then, the control device 11 of the terminal device 1[q] executes the processes of steps S151 to S155 described above if the result of the judgment in step S101 is negative, if the result of the judgment in step S149 is positive, if the processing in step S231 is executed, or if the result of the judgment in step S233 is positive. Specifically, 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). If the result of the determination in step S151 is negative, the control device 11 of the terminal device 1[q] proceeds to step S171. If the result of the determination in step S151 is positive, the code generation unit 113 of the terminal device 1[q] determines whether the latest offline token KY[q][M] stored in the storage device 12 is valid (S153). If the result of the determination in step S153 is negative, the control device 11 of the terminal device 1[q] proceeds to step S171. If the result of the determination in step S153 is positive, the display control unit 114 of the terminal device 1[q] causes the display device 13 to display an offline payment explanation screen G3 (S155), and proceeds to step S157.
[0266] As shown in FIG. 34, the control device 11 of the terminal device 1[q] executes the processes of steps S157 to S169. Specifically, the code generation unit 113 of the terminal device 1[q] generates an offline payment code CY[q] based on the offline token KY[q][M] stored in the storage device 12 (S157). The process 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] determines whether an end operation has been performed (S161). If the result of the determination in step S161 is positive, the control device 11 of the terminal device 1[q] terminates a series of processes related to the flowcharts shown in FIGS. 29 to 35. If the result of the determination in step S161 is negative, the code generation unit 113 of the terminal device 1[q] determines whether an opportunity to update the offline code image has arrived (S163). If the determination result in step S163 is positive, the control device 11 of the terminal device 1[q] proceeds to step S101 and executes again the series of processes according to the flowcharts shown in Figures 29 to 35. If the determination result in step S163 is negative, the code generation unit 113 of the terminal device 1[q] determines whether or not an opportunity to update the time encryption code TT[q] due to the update of the terminal time value AG has arrived (S165). If the determination result in step S165 is negative, the control device 11 of the terminal device 1[q] returns the process to step S159 and continues displaying the offline code image GY[q] on the display device 13. If the determination result 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.
[0267] As shown in FIG. 35, 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] causes the display device 13 to display the online code image GX[q] based on the generated online payment code CX[q] (S183). Next, the control device 11 of the terminal device 1[q] determines whether or not a termination operation has been performed (S185). If the result of the determination in step S185 is positive, the control device 11 of the terminal device 1[q] terminates the series of processes related to the flowcharts shown in FIGS. 29 to 35. If the result of the determination in step S185 is negative, the code generation unit 113 of the terminal device 1[q] determines whether or not an opportunity to update the online code image has arrived (S187). If the result of the determination in step S187 is negative, the control device 11 returns the process to step S183 and continues displaying the online code image GX[q] on the display device 13. If the result of the determination in step S187 is positive, the information transmission unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S189). Then, if there is no response from the settlement apparatus 3 to the online token request in step S189 (S191: N), the control apparatus 11 of the terminal apparatus 1[q] advances the process to step S171.On the other hand, when the information acquisition unit 112 of the terminal device 1[q] receives the online token KX[q] transmitted from the payment device 3 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.
[0268] 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 S115) 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 S213). Therefore, according to the second embodiment, compared with the mode of displaying the online code image GX[q] after the acquisition of the offline token KY[q], the time until the online code image GX[q] is displayed is shortened, and rapid execution of online electronic payment becomes possible.
[0269] <C. Variation 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 variation examples exemplified below, for elements whose actions and functions are equivalent to those in the embodiments, the reference numerals referred to in the above description are reused, and detailed descriptions of each are appropriately omitted.
[0270] <C.1. Variation 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.
[0271] FIG. 36 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.
[0272] As shown in FIG. 36, in the sequence chart of the online electronic payment according to this modification, in the electronic payment system Sys, after the processes of steps S31 to S34 related to the acquisition of the offline token KY[q] by the terminal device 1[q], the processes of steps S21 to S24 related to the acquisition of the online token KX[q] by the terminal device 1[q] are executed. This is different from the sequence chart of the online electronic payment according to the first embodiment shown in FIGS. 4 and 5.
[0273] 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 a communication failure or the like, the possibility that it is even difficult to perform offline electronic payment can be reduced.
[0274] <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.
[0275] FIG. 37 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.
[0276] As shown in Figure 37, the sequence chart for online electronic payment in this modified example differs from the sequence chart for online electronic payment in the first embodiment shown in Figure 4 in that in the electronic payment system Sys, the processing of steps S71 to S74 is executed instead of the processing of steps S21 to S24 and steps S31 to S34.
[0277] 37, in this modification, the control device 11 of the terminal device 1[q] executes the process of step S12 (or executes the process of step S17 if the payment app is launched for the first time on the terminal device 1[q]), and then transmits a blockage information request to the payment device 3 (S71). Here, the blockage information request is a message 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 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).
[0278] 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], offline token KY[q], and 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). Thereafter, the electronic payment system Sys executes the processes of step S35, steps S41 to S44, and steps S61 to S65.
[0279] According to this modification example, at the timing of performing the electronic payment, the offline token KY[q] is acquired from the payment device 3 and stored in the storage device 12. Therefore, according to the present embodiment, when it is difficult to perform online electronic payment due to communication failure or the like, it is possible to reduce the possibility that even offline electronic payment becomes difficult to execute.
[0280] <C.3. Modification Example 3> In the above-described first embodiment, second embodiment, modification example 1, and modification example 2, when the payment application is first started in the terminal device 1[q], the payment device 3 supplies the token response information DSW[q], the operator identification token KZ, and the setting information DS to the terminal device 1[q]. However, the present invention is not limited to such a mode. For example, when the payment application is started for the second time or later in the terminal device 1[q], the payment device 3 may supply the token response information DSW[q], the operator identification token KZ, and the setting information DS to the terminal device 1[q]. Further, for example, when the payment application is started for the second time or later in the terminal device 1[q], and any one of the token response information DSW[q], the operator identification token KZ, and the setting information DS is changed, the payment device 3 may supply the changed information to the terminal device 1[q].
[0281] FIG. 38 is a sequence chart showing an example of the operation of the electronic payment system Sys according to the modification example 3 when performing online electronic payment and when the payment application is started for the second time or later in the terminal device 1[q]. In this modification example as well, when the electronic payment system Sys performs online electronic payment and the payment application is started for the first time in the terminal device 1[q], it is assumed that the sequence charts of the online electronic payment shown in FIGS. 4 and 5 described above are executed.
[0282] As shown in Figure 38, the sequence chart for online electronic payment in this modified example differs from the sequence chart for online electronic payment in the first embodiment shown in Figures 4 and 5 in that in the electronic payment system Sys, the processing of step S81 is executed instead of the processing of step S13, and the processing of steps S21, S23, S31, and S33 is omitted.
[0283] 38, in this modification, the control device 11 of the terminal device 1[q] executes the process of step S12 and then transmits a payment app startup notification to the payment device 3 (S81). Here, the payment app startup notification is, as described above, a notification that the payment app has been started up in the terminal device 1[q]. Then, in response to the payment application launch notification supplied from the terminal device 1[q] in step S81, the control device 31 of the payment device 3 supplies token response information DSW[q] to the terminal device 1[q] (S14), supplies an operator identification token KZ (S16), supplies setting information DS (S14), supplies online blocking information DHX (S22), supplies online token KX[q] (S24), supplies offline blocking information DHY (S32), and supplies offline token KY[q] and encryption key KS[q] (S34). Thereafter, the electronic payment system Sys executes the processes of step S17, step S35, steps S41 to S44, and steps S61 to S65.
[0284] According to this modification, when the payment app is launched in the terminal device 1[q], various information including token response information DSW[q], online token KX[q], and offline token KY[q] is supplied from the payment device 3 to the terminal device 1[q] in response to a payment app launch notification sent from the terminal device 1[q] to the payment device 3. Therefore, according to this modification, it is possible to simplify the control in the terminal device 1[q] compared to, for example, an embodiment in which the terminal device 1[q] sends a plurality of request messages corresponding to a plurality of pieces of information to the payment device 3.
[0285] <C.4. Variant Example 4> In the above-described first embodiment, second embodiment, and variant examples 1 to 3, the mode in which the online token valid time TSX, the offline token valid time TSY, and the update unit time TC are notified from the payment device 3 as the setting information DS has been exemplified and described. However, the present invention is not limited to such a mode. Part or all of 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].
[0286] <C.5. Variant Example 5> In the above-described first embodiment, second embodiment, and variant examples 1 to 4, the case where the congestion information DH is information indicating whether the payment device 3 can execute the payment process has been exemplified and described. However, the present invention is not limited to such a mode. The congestion information DH may be information indicating whether the payment device 3 can execute the payment process for each payment method.
[0287] Specifically, in this modification, the online blockage information DHX includes online combined payment blockage information DHX1 indicating whether online payment processing by telephone bill combined payment is executable, online balance payment blockage information DHX2 indicating whether online payment processing by prepaid balance payment is executable, and online card payment blockage information DHX3 indicating whether online payment processing by credit card payment is executable. Here, the online combined payment blockage information DHX1 may be information indicating whether the functions of the payment device 3 for executing online payment processing by telephone bill combined payment are operating without being blocked. Furthermore, the online balance payment blockage information DHX2 may be information indicating whether the functions of the payment device 3 for executing online payment processing by prepaid balance payment are operating without being blocked. Furthermore, the online card payment blockage information DHX3 may be information indicating whether the functions of the payment device 3 for executing online payment processing by credit card payment are operating without being blocked. Note that, hereinafter, 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 this modification, the offline blockage information DHY includes offline combined payment blockage information DHY1 indicating whether offline payment processing using telephone bill combined payment is possible, offline balance payment blockage information DHY2 indicating whether offline payment processing using prepaid balance payment is possible, and offline card payment blockage information DHY3 indicating whether offline payment processing using credit card payment is possible. Here, the offline combined payment blockage information DHY1 may be information indicating whether the functions of the payment device 3 for executing offline payment processing using telephone bill combined payment are operating without being blocked. Furthermore, the offline balance payment blockage information DHY2 may be information indicating whether the functions of the payment device 3 for executing offline payment processing using prepaid balance payment are operating without being blocked. Furthermore, the offline card payment blockage information DHY3 may be information indicating whether the functions of the payment device 3 for executing offline payment processing using credit card payment are operating without being blocked. Note that, hereinafter, 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.
[0288] In this modified example, in response to a request for online blockage information from terminal device 1[q], payment device 3 may supply terminal device 1[q] with the individual online blockage information DHX0 corresponding to the payment method selected by user U[q] of terminal device 1[q], out of the three individual online blockage information DHX0 contained in the online blockage information DHX. Furthermore, in this modification, in response to a request for offline blockage information from the terminal device 1[q], 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], out of the three individual offline blockage information DHY0 included in the offline blockage information DHY. Furthermore, in this modification, in response to a request for offline blockage information from the terminal device 1[q], 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.
[0289] Furthermore, in the above-described first and second embodiments and modifications 1 to 4, an example has been described in which the payment device 3 supplies to the terminal device 1[q] 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 example. For example, the payment device 3 may supply to the terminal device 1[q] 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].
[0290] Specifically, in this modification, in response to an offline token request from terminal device 1[q], the payment apparatus 3 supplies to terminal device 1[q] a combined payment offline token KY1[q], which is an offline token KY[q] corresponding to combined telephone bill payment, a balance payment offline token KY2[q], which is an offline token KY[q] corresponding to prepaid balance payment, and a card payment offline token KY3[q], which is an offline token KY[q] corresponding to credit card payment. Note that, hereinafter, the combined payment offline token KY1[q], the balance payment offline token KY2[q], and the card payment offline token KY3[q] may be collectively referred to as individual offline token KY0[q]. In other words, in this modification, in response to an offline token request from terminal device 1[q], the payment apparatus 3 supplies to terminal device 1[q] three individual offline tokens KY0[q], which correspond one-to-one to the three payment methods selectable by user U[q] of terminal device 1[q].
[0291] In this modification, the code generation unit 113 of the terminal device 1[q] generates an offline payment code CY[q] based on an individual offline token KY0[q] corresponding to the payment method selected by the user U[q] of the terminal device 1[q]. Specifically, in this modification, the code generation unit 113 of the terminal device 1[q] generates the 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 for telephone charges, generates the 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 the 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.
[0292] In addition, in this modified example, the display control unit 114 of the terminal device 1[q] determines whether or not to display on the display device 13 an offline code image GY[q] based on the 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, if the payment method selected by user U[q] of terminal device 1[q] is combined telephone bill payment, it is determined based on the offline combined payment blocking information DHY1 whether or not to display the offline code image GY[q] based on the offline token KY1[q] for combined payment; if the payment method selected by user U[q] of terminal device 1[q] is prepaid balance payment, it is determined based on the offline balance payment blocking information DHY2 whether or not to display the offline code image GY[q] based on the offline token KY2[q] for balance payment; and if the payment method selected by user U[q] of terminal device 1[q] is credit card payment, it is determined based on the offline card payment blocking information DHY3 whether or not to display the offline code image GY[q] based on the offline token KY3[q] for card payment.
[0293] In this modification 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 can be selected by the user U[q] of the terminal device 1[q]. Further, in this modification example, the settlement device 3 may supply, to the terminal device 1[q], one online token KX[q] corresponding to one payment method selected by the user U[q] of the terminal device 1[q] from among the three online tokens KX[q] that correspond 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].
[0294] As described above, according to this modification example, the presence or absence of the display 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]. Therefore, compared with a mode that does not consider the payment method, it is possible to reduce the labor of the user U[q] and improve the convenience of the user U[q].
[0295] <C.6. Modification Example 6> In the above-described first embodiment, second embodiment, and modification examples 1 to 5, the case where the blockage information DH is supplied from the settlement device 3 has been illustrated and described. However, 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 also be possible.
[0296] FIG. 39 is a sequence chart showing an example of the operation of the electronic settlement system Sys when the electronic settlement system Sys according to Modification Example 6 performs online electronic settlement.
[0297] As shown in FIG. 39, in the sequence chart of the online electronic settlement according to this modification example, in the electronic settlement system Sys, the processes of steps S21, S22, S31, S32, and S41 related to the exchange of the blockage information DH do not exist, which is different from the sequence chart of the online electronic settlement according to the first embodiment shown in FIGS. 4 and 5.
[0298] According to this modification example, since the processes of supplying the online block information DHX from the settlement device 3 to the terminal device 1[q] and 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].
[0299] <C.7. Modification Example 7> In the above-described first embodiment, second embodiment, and modification examples 1 to 6, the mode of determining the online token response waiting time TSWX[q] and the offline token response waiting time TSWY[q] indicated by the token response information DSW[q] in the settlement device 3 has been exemplified and described. However, the present invention is not limited to such a mode. One or both of the online token response waiting time TSWX[q] and the offline token response waiting time TSWY[q] may be determined by the terminal device 1[q] based on the terminal information DTM[q] indicating the performance of the terminal device 1[q].
[0300] ? <C.8. Modification Example 8> In the above-described first embodiment, second embodiment, and modification examples 1 to 7, the mode in which the offline token response waiting time TSWY[q] varies according to whether the memory capacity α of the terminal device 1[q] is equal to or greater than the threshold value α0 has been exemplified and described. However, the present invention is not limited to such a mode. The offline token response waiting time TSWY[q] may be a fixed time length regardless of the memory capacity α of the terminal device 1[q]. Even in this case, it is preferable that the online token response waiting time TSWX[q] varies according to whether the memory capacity α of the terminal device 1[q] is equal to or greater than the threshold value α0.
[0301] <D. Supplementary Note> Aspects related to the above-described embodiments and modifications are described below. Note that, to facilitate understanding of each aspect, the following description will be given with reference to the drawings, but it is not intended that the present invention be limited to the illustrated aspects.
[0302] <Appendix 1> The electronic payment program PG-T according to Appendix 1 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 two types of tokens KK[q], namely, an online token KX[q] used in electronic payments executed when the payment device 3 and the terminal device 1[q] are capable of communicating, and an offline token KY[q] used in electronic payments executed when communication between the payment device 3 and the terminal device 1[q] is difficult, and a display control unit 114 that causes the display device 13 to display a code image GG[q] based on one of the two types of tokens KK[q], which is determined according to the online token response waiting time TSWX[q] based on the memory capacity α of the terminal device 1[q]. In addition, in Supplementary Note 1, the memory capacity α of the terminal device 1[q] is an example of the "terminal performance".
[0303] According to Supplementary Note 1, of the two types of tokens KK[q], the online token KX[q] and the offline token KY[q], the token KK[q] used to display the code image GG[q] is determined according to the online token response waiting time TSWX[q] based on the memory capacity α of the terminal device 1[q]. That is, according to Supplementary Note 1, it is possible to determine the online token response waiting time TSWX[q] so that the online token KX[q] is easily selected as the token KK[q] used to display the code image GG[q] even in a terminal device 1[q] with a small memory capacity α. Therefore, according to Supplementary Note 1, it is possible to increase the possibility of online electronic payment being performed even in a terminal device 1[q] with a small memory capacity α, compared to, for example, an embodiment in which the token KK[q] used to display the code image GG[q] is determined without taking into account the memory capacity α of the terminal device 1[q].
[0304] The electronic payment program PG-T according to Supplementary Note 1 includes a processor of a terminal device 1[q] that can communicate with the payment device 3, an information acquisition unit 112 that acquires from the payment device 3 two types of tokens KK[q], namely, an online token KX[q] used in electronic payments executed when the payment device 3 and the terminal device 1[q] can communicate with each other, and an offline token KY[q] used in electronic payments executed when the payment device 3 and the terminal device 1[q] cannot communicate with each other, and an information acquisition unit 112 that acquires from the payment device 3 two types of tokens KK[q], namely, an online token KX[q] used in electronic payments executed when the payment device 3 and the terminal device 1[q] can communicate with each other, and an offline token KY[q] used in electronic payments executed when the payment device 3 and the terminal device 1[q] cannot communicate with each other. The payment device 3 may function as a display control unit 114 that causes the display device 13 to display a code image GG[q] based on one of the tokens KK[q], which is determined in accordance with an online token response waiting time TSWX[q] based on the memory capacity α of the terminal device 1[q], and the payment device 3 determines the online token response waiting time TSWX[q] based on the memory capacity α of the terminal device 1[q], and the information acquisition unit 112 acquires token response information DSW[q] indicating the online token response waiting time TSWX[q] from the payment device 3.
[0305] <Appendix 2> The electronic payment program PG-T according to Appendix 2 is the electronic payment program PG-T described in Appendix 1, characterized in that the processor of the terminal device 1[q] further functions as an information sending unit 111 that sends terminal information DTM[q] regarding the memory capacity α of the terminal device 1[q] to the payment device 3, the payment device 3 determines an online token response waiting time TSWX[q] based on the terminal information DTM[q], and the information acquisition unit 112 acquires token response information DSW[q] indicating the online token response waiting time TSWX[q] from the payment device 3.
[0306] According to Supplementary Note 2, the online token response waiting time TSWX[q], which is the criterion for selecting the token KK[q] to be used to display the code image GG[q], is determined by the terminal device 1[q] based on the memory capacity α of the terminal device 1[q]. Therefore, Supplementary Note 2 allows the administrator of the payment device 3 to flexibly set the online token response waiting time TSWX[q].
[0307] <Appendix 3> The electronic payment program PG-T according to Appendix 3 is the electronic payment program PG-T according to Appendix 1 or Appendix 2, characterized in that, when the information acquisition unit 112 acquires an offline token KY[q], it stores the offline token KY[q] in the storage device 12, and when the information acquisition unit 112 acquires an online token KX[q] during an online token response waiting period TWX[q] determined according to the online token response waiting time TSWX[q], it displays an online code image GX[q] based on the online token KX[q] on the display device 13, and when the information acquisition unit 112 is unable to acquire the online token KX[q] during the online token response waiting period TWX[q], it displays an offline code image GY[q] based on the offline token KY[q] stored in the storage device 12 on the display device 13.
[0308] According to Supplementary Note 3, the online token response waiting period TWX[q] for acquiring the online token KX[q] is determined based on the memory capacity α of the terminal device 1[q]. As a result, according to Supplementary Note 3, it is possible to increase the possibility that the terminal device 1[q] will acquire the online token KX[q], compared to when the online token response waiting period TWX[q] is a fixed time length, for example.
[0309] <Appendix 4> The electronic payment program PG-T according to Appendix 4 is the electronic payment program PG-T according to Appendix 3, characterized in that the online token response waiting period TWX[q] when the memory capacity α of the terminal device 1[q] is less than the threshold value α0 is longer than the online token response waiting period TWX[q] when the memory capacity α of the terminal device 1[q] is equal to or greater than the threshold value α0.
[0310] According to Supplementary Note 4, when the memory capacity α of the terminal device 1[q] is small, the time length of the online token response waiting period TWX[q] for acquiring the online token KX[q] is set longer than when the memory capacity α of the terminal device 1[q] is large. As a result, according to Supplementary Note 4, it is possible to increase the possibility of acquiring the online token KX[q] even in the terminal device 1[q] with a small memory capacity α, compared to when the online token response waiting period TWX[q] is a fixed time length.
[0311] <Appendix 5> The electronic payment program PG-T according to Appendix 5 is the electronic payment program PG-T described in Appendix 3 or Appendix 4, characterized in that when an offline code image GY[q] based on the offline token KY[q] is displayed on the display device 13, and when the information acquisition unit 112 acquires the online token KX[q] after the online token response waiting period TWX[q] has elapsed, the display control unit 114 causes the display device 13 to display an online code image GX[q] based on the online token KX[q].
[0312] According to Supplementary Note 5, even after the online token response waiting period TWX[q] has ended and an offline code image GY[q] using the offline token KY[q] is being displayed on the display device 13, it is possible to transition to displaying an online code image GX[q] using the online token KX[q]. As a result, according to Supplementary Note 5, it is possible to increase the possibility that online electronic payment using the online token KX[q] will be performed, compared to, for example, a mode in which it is not possible to transition to displaying an online code image GX[q] using the online token KX[q].
[0313] <Appendix 6> The electronic payment program PG-T according to Supplementary Note 6 is the electronic payment program PG-T described in Supplementary Note 1 to Supplementary Note 5, wherein the information acquisition unit 112, when acquiring an offline token KY[q], stores the offline token KY[q] in the storage device 12, and an offline token validity period TY[q] is set for the offline token KY[q]; the display control unit 114, when acquiring an online token KX[q] during an online token response waiting period TWX[q] determined according to an online token response waiting time TSWX[q], displays an online code image GX[q] based on the online token KX[q] on the display device 13; and, when the information acquisition unit 112 is unable to acquire the online token KX[q] during the online token response waiting period TWX[q] and an offline token KY[q] within the offline token validity period TY[q] is stored in the storage device 12, displays an offline code image GY[q] based on the offline token KY[q] stored in the storage device 12 on the display device 13.
[0314] According to Supplementary Note 6, the online token response waiting period TWX[q] for acquiring the online token KX[q] is determined based on the memory capacity α of the terminal device 1[q]. As a result, according to Supplementary Note 6, it is possible to increase the possibility that the terminal device 1[q] will acquire the online token KX[q], compared to when the online token response waiting period TWX[q] is a fixed time length, for example. Furthermore, according to Appendix 6, the offline token KY[q] has an offline token validity period TY[q] set, which reduces the risk of fraudulent use of the offline token KY[q] in the event of leakage of the offline token KY[q], and makes it possible to increase the security of offline electronic payments.
[0315] <Appendix 7> The electronic payment program PG-T according to Appendix 7 is the electronic payment program PG-T described in Appendix 6, characterized in that, when the information acquisition unit 112 is unable to acquire the online token KX[q] during the online token response waiting period TWX[q] and the offline token KY[q] within the offline token validity period TY[q] is not stored in the storage device 12, the display control unit 114 waits until the information acquisition unit 112 acquires the online token KX[q] after the online token response waiting period TWX[q] has elapsed, and when the information acquisition unit 112 acquires the online token KX[q] after the online token response waiting period TWX[q] has elapsed, the display device 13 is caused to display an online code image GX[q] based on the online token KX[q].
[0316] According to Appendix 7, when it is difficult to execute offline electronic payment using the offline token KY[q], the information acquisition unit 112 waits until it acquires the online token KX[q], thereby increasing the possibility that online electronic payment using the online token KX[q] will be executed.
[0317] <Appendix 8> The electronic payment program PG-T according to Appendix 8 is the electronic payment program PG-T described in Appendix 1 to Appendix 7, and is characterized in that it causes the processor of the terminal device 1[q] to function as an information sending unit 111 that sends an online token request requesting an online token KX[q] to the payment device 3, and the information sending unit 111 repeatedly sends the online token request to the payment device 3 during the online token response waiting period TWX[q] determined according to the online token response waiting time TSWX[q], until the information acquisition unit 112 acquires the online token KX[q] from the payment device 3.
[0318] According to Supplementary Note 8, the token KK[q] used to display the code image GG[q] is determined according to the online token response waiting time TSWX[q] based on the memory capacity α of the terminal device 1[q]. That is, according to Supplementary Note 8, it is possible to determine the online token response waiting time TSWX[q] so that the online token KX[q] is easily selected as the token KK[q] used to display the code image GG[q] even in a terminal device 1[q] with a small memory capacity α. Therefore, according to Supplementary Note 8, it is possible to increase the possibility that online electronic payment will be performed even in a terminal device 1[q] with a small memory capacity α, compared to, for example, an embodiment in which the token KK[q] used to display the code image GG[q] is determined without taking into account the memory capacity α of the terminal device 1[q].
[0319] The electronic payment program PG-T according to Supplementary Note 8 is the electronic payment program PG-T according to Supplementary Note 1 to Supplementary Note 7, and causes the processor of the terminal device 1[q] to function as an information sending unit 111 that sends an online token request requesting an online token KX[q] to the payment device 3, the information acquiring unit 112, when acquiring an offline token KY[q], stores the offline token KY[q] in the storage device 12, an offline token validity period TY[q] is set for the offline token KY[q], and the display control unit 114, when acquiring the online token KX[q], displays an online code image GX[q] based on the online token KX[q] on the display device during the online token response waiting period TWX[q] determined according to the online token response waiting time TSWX[q]. 13, and when the information acquisition unit 112 is unable to acquire the online token KX[q] during the online token response waiting period TWX[q] and the offline token KY[q] within the offline token validity period TY[q] is not stored in the storage device 12, the information transmission unit 111 repeatedly transmits an online token request to the payment device 3 after the online token response waiting period TWX[q] has elapsed until the information acquisition unit 112 acquires the online token KX[q] from the payment device 3, and when the information acquisition unit 112 acquires the online token KX[q] from the payment device 3 after the online token response waiting period TWX[q] has elapsed, the display control unit 114 displays an online code image GX[q] based on the online token KX[q] on the display device 13.
[0320] <Appendix 9> The settlement device 3 according to Supplementary Note 9 is a settlement device 3 capable of communicating with the terminal device 1[q], and includes an information reception unit 312 that receives terminal information DTM[q] related to the memory capacity α of the terminal device 1[q] from the terminal device 1[q], an online token KX[q] used in an electronic settlement executed when the terminal device 1[q] and the settlement device 3 can communicate, an offline token KY[q] used in an electronic settlement executed when communication between the terminal device 1[q] and the settlement device 3 is difficult, two types of tokens KK[q], and a token response information DSW[q] indicating an online token response waiting time TSWX[q] determined based on the terminal information DTM[q]. The information supply unit 311 supplies the above to the terminal device 1[q]. The terminal device 1[q] causes the display device 13 to display a code image GG[q] based on one of the two types of tokens KK[q] supplied from the information supply unit 311, which is determined according to the online token response waiting time TSWX[q] indicated by the token response information DSW[q] supplied from the information supply unit 311. This is the gist of the invention.
[0321] According to Supplementary Note 9, among the two types of tokens KK[q], namely the online token KX[q] and the offline token KY[q], the token KK[q] used for displaying the code image GG[q] is determined according to the online token response waiting time TSWX[q] based on the memory capacity α of the terminal device 1[q]. Therefore, according to Supplementary Note 9, for example, compared with a mode in which the token KK[q] used for displaying the code image GG[q] is determined without considering the memory capacity α of the terminal device 1[q], the possibility of executing online electronic settlement can be increased even in a terminal device 1[q] with a small memory capacity α.
[0322] <E. Others> (1) In the above-described embodiment (including variations, 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.
[0323] (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.
[0324] (3) In the above-described embodiment, input and output information may be stored in a specific location (for example, a memory) or may be managed using a management table. Input and output information may be overwritten, updated, or added to. Output information may be deleted. Input information may be transmitted to another device.
[0325] (4) In the above-described embodiment, the determination may be made by a value (0 or 1) represented using one bit, by a Boolean value (true or false), or by a comparison of numerical values (e.g., comparison with a predetermined value).
[0326] (5) The order of the process procedures, sequences, flowcharts, etc. illustrated in the above-described embodiments may be rearranged unless inconsistent. 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.
[0327] (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 for realizing each functional block is not particularly limited. That is, each functional block may be realized using a single device that is physically or logically coupled, or may be realized using two or more physically or logically separated devices that are directly or indirectly connected (for example, by wire, wirelessly, etc.) and these multiple devices. A functional block may also be realized by combining software with the single device or the multiple devices.
[0328] (7) The programs exemplified in the above-described embodiments should be broadly construed 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.
[0329] Software, instructions, information, etc. may also be transmitted or received over a transmission medium. For example, if software is transmitted from a website, server, or other remote source using wired technologies (such as coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL)), and / or wireless technologies (such as infrared, microwave), then these wired and / or wireless technologies are included within the definition of transmission media.
[0330] (8) In each of the foregoing embodiments, the terms "system" and "network" are used interchangeably.
[0331] (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.
[0332] (10) In the above-described embodiments, the terminal device 1[q] may be a mobile station (MS). Those skilled in the art may also refer to a mobile station as a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or some other appropriate term. In this disclosure, the terms "mobile station," "user terminal," "user equipment (UE)," "terminal," etc. may be used interchangeably.
[0333] (11) In the above-described embodiments, the terms "connected," "coupled," or any variations 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 as "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 optical (both visible and invisible) range, as some non-limiting and non-exhaustive examples.
[0334] (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."
[0335] (13) As used in this disclosure, the terms "determining" and "determining" may encompass a wide variety of actions. "Determining" and "determining" may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiring (e.g., searching in a table, database, or other data structure), ascertaining, and the like. "Determining" and "determining" may also include receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, accessing (e.g., accessing data in memory), and the like. Furthermore, "judgment" and "decision" can include regarding resolving, selecting, choosing, establishing, comparing, etc. as having been "judged" or "decided." In other words, "judgment" and "decision" can include regarding some action as having been "judged" or "decided." Furthermore, "judgment (decision)" can be interpreted as "assuming," "expecting," "considering," etc.
[0336] (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" as used in this disclosure is not intended to be an exclusive or.
[0337] (15) In this disclosure, where articles are added by translation, such as a, an, and the in English, this disclosure may include that the nouns following these articles are plural.
[0338] (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."
[0339] (17) Each aspect / embodiment described in this disclosure may be used alone, in combination, or switched depending on the implementation. Notification of predetermined information (e.g., notification that "X is true") is not limited to explicit notification, but may be implicit (e.g., not notifying the predetermined information).
[0340] 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 herein. The present disclosure can be implemented in 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 intended to be illustrative and does not have any limiting meaning on the present disclosure. [Explanation of symbols]
[0341] 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. A processor of a terminal capable of communicating with the payment device, a transmitter that transmits to the payment device requests for two types of tokens: an online token used in electronic payment when the payment device and the terminal can communicate with each other, and an offline token used in electronic payment when the payment device and the terminal cannot communicate with each other; an acquisition unit that acquires the two types of tokens provided from the payment device in response to the request for the two types of tokens by the transmission unit, and, when acquiring the offline token, stores the offline token in a storage device of the terminal; a determination unit that determines whether the acquisition unit has acquired the online token within a specified period of time that has a time length according to the performance of the terminal and that starts from a time point when the transmission unit requests the online token; If the determination result of the determination unit is positive, a code image showing a code including the online token is displayed on a display device; a display control unit that displays, on the display device, a code image showing a code including the offline token stored in the storage device when the determination result of the determination unit is negative; and make it work, The specified period determined based on the performance of the terminal when the performance of the terminal is less than a specific threshold is longer than the specified period determined based on the performance of the terminal when the performance of the terminal is equal to or greater than a specific threshold. An electronic payment program comprising:
2. the transmitting unit transmits terminal information relating to the performance of the terminal to the payment device; the settlement device determines a terminal reference value related to the length of the specified period based on the terminal information; the acquisition unit acquires reference value information indicating the terminal reference value from the payment device.
2. The electronic payment program according to claim 1.
3. The display control unit When a code image showing a code including the offline token is displayed on the display device, and the determination unit determines that the acquisition unit has acquired the online token after the specified period has elapsed, the code image showing the code including the online token is displayed on the display device.
2. The electronic payment program according to claim 1.
4. When the acquisition unit acquires the offline token, the acquisition unit stores the offline token in a storage device of the terminal; The offline token has a validity period set thereto, The display control unit If the determination result of the determination unit is positive, a code image showing a code including the online token is displayed on the display device; If the determination result of the determination unit is negative and an offline token within the validity period is stored in the storage device, a code image showing a code including the offline token within the validity period is displayed on the display device.
2. The electronic payment program according to claim 1.
5. The display control unit If the determination result of the determination unit is negative and the offline token within the validity period is not stored in the storage device, the determination unit waits until the determination unit determines that the acquisition unit has acquired the online token after the specified period has elapsed, When the determination unit determines that the acquisition unit has acquired the online token after the specified period has elapsed, the determination unit causes the display device to display a code image showing a code including the online token.
5. The electronic payment program according to claim 4.
6. The transmission unit Sending an online token request to the payment device requesting the online token; the determination unit repeatedly transmits the online token request to the payment device during the specified period until the acquisition unit determines that the online token will be acquired from the payment device.
2. The electronic payment program according to claim 1.
Citation Information
Patent Citations
Program, information processing method, and terminal
JP2021021991A
Settlement server, settlement method, and program
JP2024074368A
Payment server, payment control method, and program
JP7391263B1