Payment server, payment control method, and program

Abstract

To more flexibly achieve electronic settlement.SOLUTION: Generating, by an application program for providing an electronic settlement service of a terminal of a user to the user based on an offline code generated by clocked time and a secret key, when communication between the terminal of the user and a settlement server is in a difficult state; A settlement server comprising: an acquisition unit that acquires an offline code from a terminal device of a store that has read an offline code image displayed on a display unit of the terminal device; and a processing unit that generates an offline code for each combination of any one of a plurality of generated offline codes and a secret key associated with identification information of a user specified from the offline code, and determines that an offline authentication condition related to the offline code image is satisfied when any of the generated offline codes matches the acquired offline code, and proceeds with electronic settlement.SELECTED DRAWING: Figure 8

Description

Technical Field

[0001] The present invention relates to a settlement server, a settlement control method, and a program.

Background Art

[0002] Electronic settlement in a mode where a settlement app operating on a terminal device such as a smartphone displays a code image and information is read from the code image by a store-side device has become widespread (Patent Document 1). In this mode of electronic settlement, a one-time code issued by the settlement server in association with the user's account is used as the original information to be displayed in the code image. By using the one-time code, there is no need to incorporate personal information or the like into the code image, thus realizing an improvement in security.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the above-described mode of electronic settlement, when an electronic settlement is to be performed, a request for a one-time code is sent from the settlement app to the settlement server, and a one-time code is issued in response thereto. Therefore, in the conventional technology, in a situation where communication between the terminal device and the settlement server is difficult at the time of electronic settlement, there is a case where an effective one-time code cannot be obtained, resulting in the impossibility of electronic settlement.

[0005] The present invention has been made in consideration of such circumstances, and one of its objects is to provide a settlement server, a settlement control method, and a program that can realize more flexible electronic settlement.

Means for Solving the Problems

[0006] One aspect of the present invention is a payment server comprising: an acquisition unit that, when communication between the user's terminal device and the payment server is difficult, generates an offline code based on the time being measured and a secret key, and acquires the offline code from a store's terminal device that reads the offline code image displayed on the display unit of the terminal device; and a processing unit that generates an offline code for each combination of the time being measured, a time based on the time being measured, and a secret key associated with the user's identification information identified from the offline code, and determines that the offline authentication conditions related to the offline code image have been met when any of the generated offline codes match the acquired offline code, thereby proceeding with the electronic payment. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to provide a payment server, a payment control method, and a program that enable more flexible implementation of electronic payments. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows an example of a configuration for implementing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment (online payment). [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payments (online payments). [Figure 4] This is a configuration diagram of the payment server 100 according to the first embodiment. [Figure 5] This figure shows an example of the contents of user information 172. [Figure 6] This figure shows an example of the contents of merchant / store information 176. [Figure 7]This figure shows an example of the top screen IM1 of the payment app 20. [Figure 8] This is a sequence diagram illustrating the processing flow for offline payments. [Figure 9] This flowchart shows an example of the processing flow related to screen control by the payment application 20. [Figure 10] This figure shows an example of the standby screen IM2. [Figure 11] This figure shows an example of a half-seat IM3. [Figure 12] This figure shows an example of the detailed explanation screen IMe. [Figure 13] This figure shows an example of the first offline mode screen IM4 where the first offline code image is displayed. [Figure 14] This figure shows an example of the second offline mode screen IM5 where the second offline code image is displayed. [Figure 15] This figure shows an example of the payment method selection screen IM6. [Modes for carrying out the invention]

[0009] The following describes embodiments of the payment server, payment control method, and program of the present invention, with reference to the drawings. The application program and the payment server work together to provide an electronic payment service. In the following description, the application program will be referred to as a payment app. The electronic payment service is a service that supports payment for the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for e-commerce. A virtual store may include one provided by an entity different from the operator of the electronic payment service. In that case, when settling a purchase at the virtual store, the system is controlled to transition to the interface screen of the electronic payment service. In the electronic payment service, a store is treated as belonging to, for example, a merchant (brand), and processing such as payment when a purchase is made at the store is mainly carried out between the user and the merchant. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] Figure 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is implemented with a payment server 100 at its core. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, and one or more second store terminal devices 70 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, and provider equipment.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, the configurations for realizing these functions are respectively referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, the settlement application 20 is executed by a processor such as a CPU, and it operates to provide an electronic payment service to the user in cooperation with the payment server 100. The settlement application 20 is installed in the user terminal device 10 from, for example, an application store, and controls a camera, a communication device, a touch panel, etc.

[0012] The first store terminal device 50 is installed in a store, for example. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. Note that the store code image 60 may be displayed by a display placed in the store (which may be a display of a terminal device such as a smartphone).

[0013] The second store terminal device 70 is used by the operator of the franchise store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. In the second store terminal device 70, the interface 72 for franchise stores operates. The interface 72 for franchise stores may be an application for franchise stores or a browser. The interface 72 for franchise stores accepts settings of coupons, etc. by the operator of the franchise store and transmits them to the settlement server 100. The second store terminal device 70 which is a smartphone has functions such as displaying a code image corresponding to the store code image or reading the code image displayed by the user terminal device 10 by executing the application for franchise stores.

[0014] The settlement server 100 realizes electronic settlement based on the settlement information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device, a POS gateway, a franchise store server, etc. In that case, the settlement information is transmitted from the POS device to the settlement server 100 via various devices. In the following description, without particularly distinguishing this, it is assumed that the settlement information is transmitted from the first store terminal device 50.

[0015] FIG. 2 and FIG. 3 are sequence diagrams illustrating a rough flow of electronic settlement (online settlement). There may be two patterns, pattern 1 and pattern 2, in electronic settlement.

[0016] In the case of Pattern 1 shown in Figure 2 (hereinafter referred to as User Scan), the user terminal device 10, with the payment application 20 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 contains information about the store URL (Uniform Resource Locator). This store URL is an electronic payment service domain to which information that can identify the store has been added, and is associated with the merchant ID and store ID, etc., at the payment server 100 (described later). The payment application 20 sends the first payment information, including the store URL and account ID, to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen where the merchant name and store name are displayed (S5). The user terminal device 10 then generates second payment information, including at least the payment amount, and sends it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 60 is displayed on a display placed in the store, the store code image 60 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0017] In the case of Pattern 2 shown in Figure 3 (hereinafter referred to as Store Scan), when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (S11). The payment server 100 (payment content provision unit 120, described later) generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image (online code image) such as a QR code or barcode generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the first store terminal device 50 (presents it), and the first store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). The first store terminal device 50 generates payment information including a one-time code, payment amount, merchant ID, store ID, etc., and transmits it to the payment server 100 (S16). The payment amount information has been obtained in advance by barcode reading or manual input. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs the electronic payment (S17). The payment server 100 then sends a payment completion notification to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19). Simultaneously, information notifying the first store terminal device 50 of the payment completion is also transmitted.

[0018] Furthermore, electronic payments may be made using only one of the above patterns. Also, the "account ID" explained in Figure 2 may be other information that can be used as user identification information (for example, a phone number).

[0019] [Payment Server] Figure 4 is a configuration diagram of a payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content provision unit 120, a payment processing unit 130, an information management unit 140, and a storage unit 170. Components other than the communication unit 110 and the storage unit 170 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), or GPU (Graphics Processing Unit), or by the cooperation of software and hardware. The program may be stored in advance in a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored in a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed in the storage device when the storage medium is mounted on a drive device.

[0020] The storage unit 170 can be an HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also be a NAS (Network Attached Storage) device that can be accessed by the payment server 100 via the network. The storage unit 170 stores information such as user information 172, payment content information 174, and merchant / store information 176.

[0021] The communication unit 110 is a communication interface for connecting to a network NW. The communication unit 110 is, for example, a network interface card.

[0022] The payment content provision unit 120, for example, has the functionality of a web server and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The payment content provision unit 120 reads the necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 receives various inputs from the user while the content is being played by the payment application 20 and transmits the aforementioned payment information and other data to the payment server 100.

[0023] The payment processing unit 130 performs payment processing based on payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.

[0024] Figure 5 shows an example of the contents of User Information 172. User Information 172 is an example of user registration information. User Information 172 includes, for example, user URL, account ID, phone number, password, as well as email address, user ID, name, address, date of birth, registration date, charge balance, deferred payment settings, deferred payment limit, deferred payment usage amount, deferred payment available amount, payment method settings, bank account, credit card number, issued one-time code, user identification token for offline payment described later, secret key (for charge balance), secret key (for deferred payment), offline payment limit, charge history information, and payment history information.

[0025] The user URL is used for transferring funds between users. When registering for the electronic payment service, registration of a phone number and password is mandatory. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can optionally set (or not set). Similarly, the email address, name, address, and date of birth are also information that the user can optionally set (or not set). The registration date is the date the user registered for the electronic payment service (the date the account was created). Hereafter, the user instance (electronic payment account) associated with this information will be referred to as an account.

[0026] The charge balance is information indicating the balance of electronic money that has been set up by the user by sending money to their account in advance. Methods of sending money include sending from an ATM (Automatic Teller Machine) of a designated provider (bank) and sending from a registered bank account. The deferred payment setting is information indicating whether or not the settings for enabling deferred payment electronic payments have been completed, and is set to either "Completed" or "Not Completed". The payment method setting is setting information indicating whether the user will make an electronic payment using the charge balance or a deferred payment at that time. The bank account and credit card number are information (account number and card number) of a bank account or credit card number that can be used to deposit money into the electronic payment service. The charge history information is a history of when the user has sent money to the electronic payment service in advance to increase the charge balance. The payment history information shows the details of the payment made by the user (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.) for each payment.

[0027] Figure 6 shows an example of the contents of the merchant / store information 176. The merchant / store information 176 includes, for example, a first table 176A in which merchant IDs and store IDs are associated with store URLs, a second table 176B in which merchant names and sales figures (as described above) are associated with merchant IDs, and a third table 176C in which store IDs are associated with store IDs. In addition to this information, the merchant / store information 176 may also include information such as the merchant or store category, store location, and payment patterns.

[0028] The Information Management Unit 140 manages user information 172 and affiliated store / store information 176 based on information obtained from the user terminal device 10 and the second store terminal device 70. The Information Management Unit 140 performs operations such as adding, editing, and deleting new records for user information 172 and affiliated store / store information 176.

[0029] [Electronic payment] When the payment processing unit 130 obtains payment information from the user terminal device 10 or the first store terminal device 50, it refers to the user information 172 to obtain the user's "payment method setting". For users whose "payment method setting" is set to "charge balance", the payment processing unit 130 performs electronic payment as follows: For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance, which is managed in association with the user ID, and increasing the value of the merchant's sales proceeds item. For example, the value of the merchant's sales proceeds item is not used as electronic money itself, but rather the amount corresponding to the value of the sales proceeds item is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service.

[0030] The payment processing unit 130 performs electronic payment as follows for users whose "settings information" is set to "post-payment". Post-payment is set up separately from "credit payment" which is made in cooperation with a credit card company, which is a separate entity from the electronic payment service operator. The electronic payment service operator acts as the grantor and allows electronic payment that does not depend on the charge balance within the post-payment limit. In order to use the post-payment service, it may be required to obtain a credit card provided by the electronic payment service operator. The amount used with post-payment is settled in a lump sum for the month on the payment date of the following month, for example, by withdrawal from a bank account. In this case, the payment processing unit 130 performs a provisional settlement by adding the settlement amount to the amount used with post-payment and subtracting the same amount from the available post-payment limit. When the closing date arrives, it processes the payment for the current month to be withdrawn on the payment date of the following month as described above, or requests the credit card company operator to perform the said process. If the settlement amount exceeds the available post-payment limit at the time of provisional settlement, an error notification is sent back to the payment app 20.

[0031] [Switching between charge balance and deferred payment (when making online payments)] Figure 7 shows an example of the top screen IM1 of the payment application 20. The illustrated state assumes that communication between the payment application 20 and the payment server 100 is not difficult, representing a first state (online payment enabled). In the first state, a valid one-time code is provided to the payment application 20 from the payment server 100. "Valid" means that it is a code issued in response to the most recent request for one-time code issuance. The top screen IM1 displays a code image CD. The code image CD includes, for example, a barcode and a QR code. Along with the code image CD, text indicating whether to perform electronic payment using the charge balance or electronic payment via deferred payment (in the figure, "Pay with balance") is displayed. This text is drawn by the payment application 20 based on information updated by the payment application 20 each time the toggle switch SW is operated. The top screen IM1 also includes an operation area CA containing the toggle switch SW and a transition button TB1. Note that "switch" and "button" refer to a GUI (Graphical User Interface) implemented in cooperation with a touch panel. The toggle switch SW accepts the operation of switching between electronic payment using the charged balance and electronic payment using deferred payment. By default, the toggle switch SW is set to electronic payment using the charged balance, and each time it is operated by the user, the setting switches between electronic payment using the charged balance and electronic payment using deferred payment. In the diagram, it is displayed as "Balance Payment," which means that it is set to electronic payment using the charged balance. The operation area CA has buttons that instruct the main operations of electronic payment, such as a button to instruct scanning (starting user scanning) and a button to instruct charging. When the transition button TB1 is operated, it transitions to a payment screen that displays the code image used for electronic payment and the available amount.

[0032] [Offline payment] The following describes electronic payment (offline payment) in a second state where a valid one-time code cannot be obtained due to difficulties in communication between the payment application 20 and the payment server 100. The offline payment in this embodiment can be performed at the store where the store scan described above took place.

[0033] The payment application 20 decides whether to perform an online or offline payment depending on whether communication with the payment server 100 is in a normal first state or in a difficult second state. For example, the payment application 20 determines that it is in the second state if the response to the one-time code issuance request fails to arrive within a predetermined time n or more times (n is an integer greater than or equal to 1). If the payment application 20 determines that communication with the payment server 100 is in the second state, it generates an offline code using the time and secret key measured by the user terminal device 10, generates an offline code image based on the offline code, and displays the offline code image on the display unit of the user terminal device 10. In other words, the payment application 20 generates an offline code image based on the offline code it generates itself, without using a one-time code.

[0034] The secret key is obtained from the payment server 100 to the payment application 20 less frequently than the one-time code. For example, a running payment application 20 obtains the secret key about once a week. In this acquisition process, a request for secret key issuance may be sent from the payment application 20 to the payment server 100, or the payment server 100 may voluntarily provide the secret key to the payment application 20.

[0035] The payment application 20 may generate an offline code using a user identification token in addition to the time and secret key. The user identification token may be permanently assigned to the user, or it may be sent from the payment server 100 along with the secret key issuance request. An example of an offline key is one that includes either or both of the secret key and the user identification token.

[0036] For example, payment application 20 generates an offline code based on data obtained by inputting a secret key and time into a predetermined function, and data obtained by combining this with a user identification token. This method is merely an example, and payment application 20 may generate an offline code using any decryptable method based on some or all of the secret key, time, and user identification token.

[0037] Furthermore, the payment application 20 may, at predetermined intervals (for example, each time a secret key issuance request is made), instruct the user terminal device 10 to synchronize the time it keeps with the time it keeps with the payment server 100. In this case, the payment application 20 may perform the process of synchronizing with the time of a radio-controlled clock or the like approximately simultaneously with the payment server 100.

[0038] When the offline code image is read by the first store terminal device 50 and payment information is obtained, including at least a portion of the read information and the payment amount (if the payment application 20 has generated information based on the offline code image using the time), the payment processing unit 130 of the payment server 100 proceeds with the electronic payment based on the payment information if the offline authentication conditions are met. In other words, it proceeds with the offline payment. "At least a portion of the read information" means "at least a portion of the offline code," and will be simply referred to as the offline code below. The offline authentication conditions relate to the offline code image generated by the payment application 20 based on the offline code. For example, the offline authentication conditions include that the time read from the offline code image (hereinafter referred to as the application time) is within a predetermined range compared to the time measured by the payment server 100 (hereinafter referred to as the server time). The offline authentication conditions may also include that the offline key (either or both of the secret key and the user identification token) has been provided to the payment application 20 and is stored in the storage unit 170. The time handled in offline payment is measured in minutes, for example, but is not limited to this. When the payment processing unit 130 obtains payment information, it identifies a secret key from the user identification token contained in the offline code included in the payment information, and uses the identified secret key and the current time measured by the payment server 100 to generate an offline code in the same manner as the payment application 20. If the offline code obtained from the first store terminal device 50 matches the code it has generated, it determines that the offline code is valid. For example, in case there is a time difference between the user terminal device 10 and the payment server 100, the payment processing unit 130 generates multiple codes within a predetermined range of the current time measured by the payment server 100 plus or minus a predetermined time (e.g., 1 minute), and if any of these codes match the offline code obtained from the store terminal device, it determines that the offline authentication conditions are met, i.e., that the payment information is valid.

[0039] The payment processing unit 130 may set a lower upper limit on the payment amount for a single electronic payment compared to online payments (when the payment information includes information obtained from an offline code image) when performing offline payments. The payment processing unit 130 may set the upper limit on the payment amount for offline payments to a fixed amount lower than that for online payments (as shown in the example in Figure 5, it is set to 5,000 yen), or it may dynamically determine it based on the user's payment history, etc. In the latter case, the payment processing unit 130 determines the upper limit based on the frequency of past electronic payments by the user, the amount of each payment, the trend of the categories of payments, etc. When performing an offline payment, if payment information for a payment amount exceeding the upper limit is obtained from the payment application 20, the payment processing unit 130 sends an error message to the first store terminal device 50, and after communication with the user terminal device 10 is restored, it also sends an error message to the user terminal device 10.

[0040] Figure 8 is a sequence diagram illustrating the processing flow for offline payment. First, at a time unrelated to electronic payment, the payment application 20 sends a request for the issuance of an offline key to the payment server 100 (S21). The payment server 100 generates an offline key (S22) and sends it to the payment application 20 (S23). The payment application 20 stores the received offline key in the memory of the user terminal device 10.

[0041] At a different time, if a user launches the payment app 20 or performs a payment operation using the payment app 20 at a store where a store scan is being performed, the payment app 20 sends a request to the payment server 100 to issue a one-time code (S31). If the event of not receiving a response to the request to issue a one-time code within a predetermined time occurs n or more times, the payment app 20 generates an offline code and displays an offline code image generated based on the offline code (S32). The user holds the display surface of the user terminal device 10 over the first store terminal device 50 (presents it), and the first store terminal device 50 decodes the code image using its optical reading function and obtains the offline key, etc. (S33).

[0042] The first store terminal device 50 then generates payment information including the offline key, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S33). Based on the received information, the payment server 100 identifies the user corresponding to the user identification token and determines whether the offline authentication conditions are met as described above (S34). If the offline authentication conditions are met, it proceeds with the electronic payment (S35). In this case, information notifying the completion of the payment is also sent exclusively to the first store terminal device 50.

[0043] This process enables electronic payments even when communication between the payment app 20 and the payment server 100 is difficult, such as when the store performing the store scan is located in an area with a weak signal, thus making electronic payments more flexible. Furthermore, even in offline payments, by proceeding with electronic payments without including user identification information such as account IDs in the offline code, the degree of protection of users' personal information can be maintained.

[0044] Furthermore, generating an offline code image using both the time and the offline key, and then performing an offline payment, increases the likelihood of a legitimate payment. If only the offline key is used to generate the offline code image and perform an offline payment, it becomes impossible to know when the offline code image was generated, thus reducing the legitimacy of the payment. Also, if only the time is used to generate the offline code image and perform an offline payment, anyone could generate the offline code image if the offline code image generation logic were exposed. By using both to generate the offline code image, the timing of the offline code image generation can be determined, and the inclusion of the offline key in the offline code image guarantees that it is based on information issued by the payment server 100. As a result, the likelihood of a legitimate payment can be increased.

[0045] Furthermore, by setting a lower limit for offline payments than for online payments, it is possible to achieve more secure electronic payments.

[0046] The following describes screen control by the payment application 20. Figure 9 is a flowchart showing an example of the processing flow related to screen control by the payment application 20. The processing in this flowchart is initiated in various situations where communication with the payment server 100 occurs.

[0047] First, the payment app 20 determines whether or not it has received a notification from the payment server 100 (S100). A notification is, for example, a one-time password sent in response to the one-time password issuance request mentioned above. If a notification has been received from the payment server 100, the payment app 20 displays the online mode screen (for example, as shown in Figure 7) and continues normal operation (S102).

[0048] If no notification is received from the payment server 100, the payment application 20 displays a waiting screen IM2 on the user terminal device 10 indicating that it is difficult to read information from the payment server 100 (S104). Figure 10 shows an example of the waiting screen IM2. No valid code image is displayed on the waiting screen IM2, and text TX1 indicating the connection status with the payment server 100 is displayed to the user.

[0049] Next, the payment application 20 determines whether or not it has been confirmed to be in the second state (S106). As mentioned above, the condition for being in the second state to be confirmed is "when n or more instances occur in which a notification such as a response to a one-time code issuance request is not received within a predetermined time." If the second state has not been confirmed, the process returns to S100.

[0050] Once the second state is determined, the payment application 20 determines whether a valid offline key (secret key and user identification token) has been acquired and stored in the memory of the user terminal device 10 (S108). A valid offline key is, for example, an offline key whose elapsed time since acquisition does not exceed the upper limit time (a time approximately the same as the offline key issuance cycle).

[0051] If a valid offline key is not obtained, the payment app 20 displays an error screen on the user terminal device 10 (S110). The error screen includes text explaining that there is difficulty connecting to the internet, etc.

[0052] If a valid offline key is obtained, the payment application 20 determines whether the counter value k is equal to or greater than the threshold Th (S112). The counter value k is, for example, set to zero when the payment application 20 is installed on the user terminal device 10, and incremented by 1 each time the acceptance operation determined in S116 is performed. In other words, the determination process in S112 determines whether the acceptance operation has been performed a predetermined number of times (= threshold Th) or more. The threshold Th is, for example, a value of about 1 to 3.

[0053] If the counter value k is less than the threshold Th, the payment application 20 displays a half-sheet, as illustrated in Figure 11, on the user terminal device 10 (S114). Figure 11 shows an example of a half-sheet IM3. The half-sheet IM3 is displayed in a smaller size than the screens that display online code images, such as the top screen IM1. The half-sheet IM3 is an example of an "interface screen". The half-sheet IM3 displays text TX2 that explains offline payment. The half-sheet IM3 also includes a first operation unit B1 that instructs the user to transition to a detailed explanation screen regarding payment in offline mode, and a second operation unit B2 that instructs the user to accept payment in offline mode. Figure 12 shows an example of a detailed explanation screen IMe. The detailed explanation screen IMe displays text TXe that explains offline payment. The detailed explanation screen IMe also includes a first operation unit Be1 that instructs the user to transition to a help page regarding payment in offline mode, and a second operation unit Be2 that instructs the user to return to the half-sheet IM3. The help page is updated periodically by the payment server 100, and the payment application 20 downloads the help page at any time when communication between the user terminal device 10 and the payment server 100 is functioning normally, and stores it in the memory of the user terminal device 10 (caching it). This allows the user to access a help page containing detailed information about offline payments, even when communication with the payment server 100 is difficult. The help page, like the half-sheet IM3, may be displayed at a smaller size than the screens displaying online code images such as the top screen IM1.

[0054] The payment application 20 determines whether an operation has been performed on the second operation unit B2 in the half-sheet IM3, that is, whether an operation has been performed to accept payment in offline mode (S116).

[0055] If an operation to accept payment in offline mode is performed, the payment application 20 displays the offline mode screen on the user terminal device 10 (S118). Also, if it is determined in S112 that the counter value k is greater than or equal to the threshold Th, the payment application 20 also displays the offline mode screen on the user terminal device 10 (S118). The offline mode screen is a screen that displays an offline code image. Thus, the conditions for transitioning to the offline mode screen include, for example, that a valid offline key has been obtained from the payment server 100, and basically include that an operation to accept has been performed, but if the operation to accept has been performed more than a predetermined number of times, the condition that an operation to accept has been performed is excluded.

[0056] By performing this process, users can be smoothly guided to offline payment using offline code images.

[0057] The following describes the offline mode screen. The offline mode screen includes a first offline mode screen that displays a first offline code image that enables offline payment using the first payment method, and a second offline mode screen that displays a second offline code image that enables offline payment using the second payment method. These two screens may be switchable between by the user. In other words, in offline payments provided by the electronic payment system, the first and second payment methods may be selectively implemented. For example, similar to online payments, the first payment method may be an electronic payment method using a charged balance, and the second payment method may be an electronic payment method with deferred payment. The first and second payment methods may be different methods, such as a payment method using a debit card function, point payment, or credit card payment.

[0058] In this case, the payment application 20 acquires a first offline key for generating a first offline code image and a second offline key for generating a second offline code image at a lower frequency than the one-time code. Each of the first and second offline keys contains the same information as the aforementioned offline key, and is further endowed with identification information indicating whether it is the first or second offline key. The payment application 20 generates the first offline code using the first offline key, and based on that, generates the first offline code image and displays it on the user terminal device 10. The payment application 20 also generates the second offline code using the second offline key, and based on that, generates the second offline code image and displays it on the user terminal device 10. The user identification tokens included in the first and second offline keys may be the same or different (they are the same in Figure 5).

[0059] Figure 13 shows an example of the first offline mode screen IM4 where the first offline code image is displayed, and Figure 14 shows an example of the second offline mode screen IM5 where the second offline code image is displayed. The first offline mode screen IM4 displays the first code image CD#1. The first offline mode screen IM4 is equipped with a third operation unit B3 that displays the current payment method and instructs the user to transition to the payment method selection screen IM6. The first offline mode screen IM4 is also equipped with a reload button B5. When the reload button B5 is operated, a communication request is sent to the payment server 100, and the processing of the flowchart in Figure 9 is started. On the other hand, the second offline mode screen IM5 displays the second code image CD#2. The second offline mode screen IM5 is equipped with a fourth operation unit B4 that displays the current payment method and instructs the user to transition to the payment method selection screen IM6. The second offline mode screen IM5 is also equipped with a reload button B5.

[0060] Figure 15 shows an example of the payment method selection screen IM6. The payment method selection screen IM6 is configured with operation sections B6 to B8, which list the payment methods that can be selected. When operation section B6 is operated, the screen transitions to the first offline mode screen IM4, and when operation section B7 is operated, the screen transitions to the second offline mode screen IM5. The processing when operation section B8 is selected may be determined arbitrarily.

[0061] The payment application 20 may inherit the payment method settings for online payments as the initial settings for offline payments. For example, the payment application 20 may decide whether the first screen displayed when an offline payment is decided to be the first offline mode screen IM4 or the second offline mode screen IM5, in accordance with the settings for online payments. In this case, the payment application 20 stores the payment method settings for online payments in the memory of the user terminal device 10.

[0062] If the payment information obtained in offline payment includes information obtained from the first offline code screen, i.e., the first offline key, the payment server 100 proceeds with the electronic payment using the first payment method, and if it includes information obtained from the second offline code screen, i.e., the second offline key, the payment server 100 proceeds with the electronic payment using the second payment method.

[0063] By performing this process, it is possible to broaden the range of choices for users and improve convenience in offline payments using offline code images.

[0064] Furthermore, the processes described above as offline processes may also be executed in the first state. In other words, the processes described as offline processes may be executed at all times, regardless of the communication status between the user terminal device 10 and the payment server 100.

[0065] Although embodiments for carrying out the present invention have been described above using examples, the present invention is not limited in any way to these embodiments, and various modifications and substitutions can be made without departing from the spirit of the present invention. [Explanation of Symbols]

[0066] 10. User terminal device 20 Payment Apps 100 Payment Servers 120 Payment Content Provision Department 130 Payment Processing Unit 140 Information Management Department

Claims

1. When communication between the user's terminal device and the payment server is difficult, an acquisition unit obtains the offline code from a store's terminal device that reads the offline code image displayed on the display unit of the terminal device, based on an offline code generated by the application program for providing the user's electronic payment service to the user using the time being measured and a secret key. An offline code is generated for each combination of the time being measured, the time based on the aforementioned time, and the secret key associated with the user's identification information identified from the offline code. If any of the multiple offline codes generated matches the acquired offline code, the processing unit determines that the offline authentication conditions associated with the offline code image have been met and proceeds with the electronic payment. A payment server equipped with the following features.

2. The time based on the aforementioned time is within a predetermined range of plus or minus the time being measured. The payment server according to claim 1.

3. The time intervals used to generate the offline code are one-minute intervals. The payment server described in claim 1.

4. The acquisition unit generates an offline code based on the application program using the time being measured, the secret key, and the user identification token for identifying the user, and acquires the offline code from the store's terminal device that reads the offline code image displayed on the terminal device's display unit. The processing unit identifies the user identification token from the offline code and identifies the secret key associated with the user identification token in the storage unit. The payment server according to claim 1.

5. If communication between the user's terminal device and the payment server is functioning normally, the payment server reads the online code image generated using the one-time code provided by the payment server and obtains the one-time code from the store's terminal device. The processing unit proceeds with the electronic payment based on the one-time code. The payment server according to claim 1.

6. The secret key is provided to the user's terminal device at a lower frequency than the one-time code. The payment server according to claim 5.

7. At a predetermined timing, the time measured by the terminal device and the time measured by the payment server are synchronized. The payment server according to claim 1.

8. Computers If communication between the user's terminal device and the payment server is difficult, the application program for providing the user's electronic payment service on the user's terminal device generates an offline code based on the time being measured and the secret key, and obtains the offline code from the store's terminal device that reads the offline code image displayed on the terminal device's display unit. An offline code is generated for each combination of the time being measured, the time based on the aforementioned time, and the secret key associated with the user's identification information identified from the offline code. If any of the generated offline codes matches the acquired offline code, it is determined that the offline authentication conditions associated with the offline code image have been met, and the electronic payment is processed. Payment control method.

9. On the computer, If communication between the user's terminal device and the payment server is difficult, the application program for providing the user's electronic payment service on the user's terminal device generates an offline code based on the time being measured and a secret key, and the store's terminal device reads the offline code image displayed on the terminal device's display and retrieves the offline code. A process for generating an offline code for each combination of the time being measured, the time based on the said time, and the secret key associated with the user's identification information identified from the offline code, If any of the generated offline codes matches the acquired offline code, the system determines that the offline authentication conditions associated with the offline code image have been met and proceeds with the electronic payment. A program to execute.

Images