Store terminal, terminal, transaction management system, transaction management method, and transaction management program

Abstract

To provide a mechanism that suppresses the transmission of radio waves when products are purchased at service stations.SOLUTION: A user terminal according to one aspect of the present disclosure includes at least one processor. The at least one processor generates a two-dimensional code containing setting information to be used for purchasing a product at a service station, and displays the two-dimensional code for purchasing the product at the service station.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] One aspect of the present disclosure relates to a user terminal, a store terminal, a transaction management system, a transaction management method, and a transaction management program. [Background technology]

[0002] There are known mechanisms for supporting the purchase of products at service stations that sell energy sources. For example, Patent Document 1 discloses a technology in which information required for a transaction is registered in advance in an IC tag, and payment for a refueling service is made by reading the IC tag. [Prior art documents] [Patent documents]

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

[0004] The technology described in Patent Document 1 uses wireless communication to read IC tags. In service stations that handle flammable and hazardous materials, it is desirable to suppress the transmission of radio waves. [Means for solving the problem]

[0005] A user terminal according to an aspect of the present disclosure includes at least one processor that generates a two-dimensional code including setting information used for purchasing a product at a service station, and displays the two-dimensional code for purchasing the product at the service station.

[0006] A store terminal according to one aspect of the present disclosure is disposed in a service station and includes at least one processor that reads a two-dimensional code displayed on a user terminal, acquires setting information used for purchasing a product at the service station, and executes a process related to the purchase based on the setting information.

[0007] A transaction management system according to one aspect of the present disclosure includes a user terminal and a store terminal of a service station. The user terminal generates a two-dimensional code including setting information used to purchase a product at the service station and displays the two-dimensional code for purchasing the product at the service station. The store terminal acquires the setting information by reading the two-dimensional code displayed on the user terminal and executes a process related to the purchase based on the setting information.

[0008] According to an aspect of the present disclosure, there is provided a transaction management method executed by a user terminal having at least one processor, the transaction management method including the steps of generating a two-dimensional code including setting information used for purchasing a product at a service station, and displaying the two-dimensional code for purchasing the product at the service station.

[0009] A transaction management program according to one aspect of the present disclosure causes a computer to execute steps of generating a two-dimensional code including setting information used for purchasing goods at a service station, and displaying the two-dimensional code for purchasing goods at the service station.

[0010] In this aspect, the setting information used to purchase the product at the service station is displayed as a two-dimensional code. Since the reading of the two-dimensional code does not require radio waves, it is possible to suppress the transmission of radio waves when purchasing the product at the service station. Effect of the Invention

[0011] According to one aspect of the present disclosure, it is possible to provide a mechanism for suppressing the transmission of radio waves when purchasing a product at a service station. [Brief description of the drawings]

[0012] [Figure 1] A diagram showing an example of an overall configuration including a transaction management system according to an embodiment. [Diagram 2] A diagram showing an example of the functional configuration of a transaction management system according to an embodiment. [Diagram 3] A diagram showing the general hardware configuration of a computer used in a transaction management system according to an embodiment. [Figure 4] FIG. 13 illustrates an example of a setting screen. [Diagram 5] A sequence diagram showing an example of a one-time token inquiry process by a transaction management system according to an embodiment. [Figure 6] A sequence diagram showing an example of transaction processing by a transaction management system according to an embodiment. [Figure 7] A sequence diagram showing an example of closing processing by a transaction management system according to an embodiment. [Figure 8] A sequence diagram showing an example of closing processing by a transaction management system according to an embodiment. [Figure 9] A sequence diagram showing another example of transaction processing by the transaction management system of the embodiment. [Figure 10] A sequence diagram showing another example of transaction processing by the transaction management system of the embodiment. [Figure 11] A sequence diagram showing another example of transaction processing by the transaction management system of the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In the description of the drawings, the same or equivalent elements are designated by the same reference numerals, and duplicated descriptions will be omitted.

[0014] [System Overview] The transaction management system according to the embodiment is a computer system that manages transactions of goods at a service station. A service station refers to a store that sells energy sources. An energy source refers to a resource used to operate a power source, and is provided, for example, to operate a mobile object such as an automobile. Examples of service stations include gas stations, hydrogen stations, and charging stations. Hereinafter, a service station is also simply referred to as a "store." A product refers to any tangible or intangible object that is traded for a fee or free of charge, and is a concept that includes the provision of services. A "transaction of goods" refers to the exchange of goods between two parties. Examples of transactions include buying and selling, lending and borrowing, and exchange. The payment means involved in the transaction are not limited. For example, the payment means may be cash, or a deferred payment means such as a credit card, a debit card, or electronic money. A deferred payment means refers to a payment method in which a customer purchases a product and then deposits the money into a store. More specifically, the transaction management system according to the embodiment manages the buying and selling of goods using a deferred payment card. A deferred payment card refers to a card used for deferred payment, which is a payment method in which a customer pays for a product after purchasing it. An example of a deferred payment card is a credit card, but the type of deferred payment card is not limited to this. There is no limit to the method of realizing a deferred payment card, and for example, the deferred payment card may be provided to a customer as a tangible card like a general credit card, or as a virtual card represented by electronic data. A customer is someone who purchases a product. A customer can be referred to as a consumer or a user.

[0015] In this disclosure, the phrase "transmitting" data or information from a first computer to a second computer refers to the transmission for ultimate delivery of the data or information to the second computer. Note that this phrase is intended to include the case where another computer or communication device relays the data or information in the transmission.

[0016] [System configuration] An overview of the mechanism of the transaction management system 1 will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of an overall configuration including the transaction management system 1.

[0017] In this embodiment, the customer 90 owns a user terminal 91. The user terminal 91 is a computer used by the customer 90. The type and configuration of the user terminal 91 are not limited. For example, the user terminal 91 may be a mobile terminal such as a smartphone, a tablet terminal, or a wearable terminal (e.g., a smart watch). The user terminal 91 may be a component of the transaction management system 1, or may be a component not included in the transaction management system 1.

[0018] The user terminal 91 accepts input of setting information used for purchasing a product by operation of the customer 90. The setting information includes at least one of a one-time token used for verifying the customer 90, customer identification information which is an identifier for uniquely identifying the customer 90, product information which indicates the product, and payment-related information used for payment. The one-time token is electronic data for verifying (authenticating) whether the customer 90 who purchases the product is the customer himself / herself. The one-time token is generated, for example, for each purchase of a product, and is used for verification only once. For example, the one-time token is generated by the application server 70. The payment-related information indicates at least one of a coupon and a point card. The coupon is electronic data used for discounting the product. For example, the coupon includes information such as information for identifying the product to be discounted, the discount amount, the upper limit of use, and the expiration date. The point card is a card for managing points given to the customer 90 in response to a transaction (specifically, a purchase) of a product. The customer 90 can accumulate the points and use the points as at least a part of the purchase price of the product. The user terminal 91 generates a two-dimensional code including the setting information. A two-dimensional code is a visible code that is expressed to have information in both the horizontal and vertical directions.

[0019] The user terminal 91 displays a two-dimensional code for purchasing a product at a store. For example, a customer 90 visits a store with the user terminal 91 when purchasing a product. The customer 90 operates the user terminal 91 to display a two-dimensional code, and holds the surface on which the two-dimensional code is displayed over the two-dimensional code reader 19. The two-dimensional code reader 19 is a device capable of reading information in a two-dimensional code. The two-dimensional code reader 19 is connected to the store terminal 10. The two-dimensional code reader 19 transmits setting information read from the two-dimensional code to the store terminal 10. In response to this operation, various processes related to the purchase of the product are executed in the store terminal 10.

[0020] The store terminal 10 is a computer located in a store that handles products. The store terminal 10 executes processing related to the purchase of products. In one example, the processing related to the purchase of products may include the selection or setting of the product to be purchased, or may include payment processing. The configuration of the store terminal 10 is not limited. For example, the store terminal 10 may be a general cash register, may have a POS (point of sale) function, or may be another type of device with a cash register function or a POS function. Although only one store terminal 10 is shown in FIG. 1, the transaction management system 1 can naturally manage transactions at multiple store terminals 10 in multiple stores. Each store terminal 10 may be a component of the transaction management system 1, or may be a component not included in the transaction management system 1.

[0021] The transaction management system 1 includes a transaction management server 20, which is a computer that manages individual transactions, and an application server 70 that generates one-time tokens. The transaction management server 20 can be communicatively connected to at least one store terminal 10. The transaction management server 20 can also be communicatively connected to the application server 70, a database 30 that stores various information used in individual transactions, and a payment management server 40 of a card company that manages payments. The application server 70 can also be communicatively connected to at least one user terminal 91. The store terminal 10 can also be communicatively connected to a first sales management server 50 and a second sales management server 60 that collectively manage transactions at one or more stores. For example, the first sales management server 50 and the second sales management server 60 execute a closing process to finalize transactions (sales). The first sales management server 50 and the second sales management server 60 may be components of the transaction management system 1, or may be components not included in the transaction management system 1.

[0022] The configuration and type of the communication network used for communication between the computers are not limited and may be designed according to any policy. For example, the communication network may be constructed by the Internet, an intranet, or a combination of these. Also, the communication network may be constructed by a wired network, a wireless network, or a combination of these.

[0023] With reference to FIG. 1, an example of the flow of processing in one transaction, i.e., one purchase procedure, will be described. The user terminal 91 requests a one-time token inquiry by sending customer identification information to the application server 70 (step S11). In response to the request, the application server 70 generates a one-time token and sends the generated one-time token and customer identification information to the transaction management server 20 (step S12). The transaction management server 20 stores the correspondence between the one-time token and the customer identification information in the database 30. The application server 70 sends a response including the generated one-time token to the user terminal 91 (step S13). A customer 90 who wishes to purchase a product at a store operates the user terminal 91 to input setting information. The customer 90 may input the setting information in advance before entering the store, or may input the setting information at the store. The setting information includes, for example, the one-time token and product information. The user terminal 91 generates a two-dimensional code including the setting information.

[0024] In response to the customer 90 displaying the two-dimensional code on the user terminal 91 and holding the user terminal 91 over the two-dimensional code reader 19, the two-dimensional code reader 19 starts reading the two-dimensional code. The two-dimensional code reader 19 transmits the setting information read from the two-dimensional code to the store terminal 10. The store terminal 10 transmits the setting information to the transaction management server 20 (step S21). The transaction management server 20 reads out the official card number of the post-payment card and the tokenized card number of the post-payment card from the database 30 based on the customer identification information associated with the one-time token indicated by the setting information. In addition, the transaction management server 20 transmits the official card number to the settlement management server 40 to request a credit inquiry (credit inquiry) from the settlement management server 40 (step S22). In response to the request, the settlement management server 40 executes a credit inquiry and transmits the result (credit result) to the transaction management server 20 (step S23). The transaction management server 20 transmits a response including the credit result and the tokenized card number of the deferred payment card to the store terminal 10 (step S14). If the credit result indicates approval of the transaction, the customer 90 can purchase goods with the deferred payment card at the store.

[0025] In this embodiment, the transaction management system 1 uses two types of card numbers, a formal card number and a tokenized card number, as identifiers that uniquely identify a postpaid card. The formal card number is a number that is set by a card company when issuing a postpaid card. The formal card number is notified to the customer 90 when the postpaid card is issued, and therefore the customer 90 can know his / her formal card number. On the other hand, the tokenized card number is a card number obtained by replacing at least a part of the formal card number with another character string by tokenization. Tokenization refers to a process of replacing an original character string with another character string that has no mathematical relationship with the original character string. Tokenization can be realized, for example, by generating the other character string using a random number. The original character string (the character string before replacement) and the other character string (the character string after replacement) are associated one-to-one. Since there is no mathematical relationship between these two character strings, the original character string cannot be identified from the other character string by mathematical processing. In order to obtain the original character string, it is necessary to know the one-to-one correspondence. Tokenization differs from encryption in that there is no mathematical relationship between data before and after replacement. Since encryption is a process of converting original data into encrypted data using an encryption algorithm and an encryption key, there is a mathematical relationship between the original data and the encrypted data due to the encryption algorithm and the encryption key.

[0026] The flow of the closing process will be explained with reference to Figure 1. The example in Figure 1 shows two types of closing processes corresponding to the existence of two types of sales management servers, a first sales management server 50 and a second sales management server 60. The store terminal 10 is connected to one of the first sales management server 50 and the second sales management server 60 for communication.

[0027] The first sales management server 50 is used in the first closing process. In this case, the store terminal 10 transmits transaction information indicating one or more transactions to the first sales management server 50 (step S31). The transaction information includes individual tokenized card numbers corresponding to each transaction, but does not include individual official card numbers corresponding to each transaction. The first sales management server 50 transmits one or more tokenized card numbers to the transaction management server 20 (step S32). The transaction management server 20 refers to the database 30 and reads out the corresponding official card numbers for each of the tokenized card numbers. Then, the transaction management server 20 transmits one or more official card numbers to the first sales management server 50 (step S33). The first sales management server 50 transmits settlement information corresponding to the transaction information received from the store terminal 10 to the settlement management server 40. (step S34). The settlement information includes individual official card numbers corresponding to each transaction. After that, the card company executes the settlement by the deferred payment card.

[0028] The second sales management server 60 is used in the second closing process. In this case, the store terminal 10 transmits transaction information indicating one or more transactions to the second sales management server 60 (step S41). The transaction information includes individual tokenized card numbers corresponding to each transaction, but does not include individual official card numbers corresponding to each transaction. The second sales management server 60 transmits payment information corresponding to the transaction information to the transaction management server 20 (step S42). The transaction management server 20 refers to the database 30 and reads out the corresponding official card number for each tokenized card number. Then, the transaction management server 20 replaces one or more tokenized card numbers in the payment information with one or more official card numbers, and transmits the processed payment information to the payment management server 40 (step S43). After that, the card company executes the payment by the deferred payment card.

[0029] There is no limitation on the products to which the transaction management system 1 is applied. For example, the transaction management system 1 may be constructed for trading energy sources (e.g., gasoline, diesel, hydrogen, electricity, etc.), other products, or services (e.g., refueling services for gasoline-powered vehicles, charging services for electric vehicles, car washes, etc.) at a service station. That is, the product may be fuel oil, hydrogen, etc., and the store may be a gas station or a hydrogen station. In this case, the store terminal 10 may be a refueling machine or a hydrogen dispenser equipped with a cash register function or a POS function.

[0030] Functional elements related to the transaction management system 1 will be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of the functional configuration of the transaction management system 1.

[0031] The user terminal 91 includes a display unit 92 and a generation unit 93 as functional elements. The display unit 92 is a functional element that displays a setting screen for setting in advance setting information used for purchasing products at a service station. The display unit 92 accepts input of the setting information. The generation unit 93 is a functional element that generates a two-dimensional code including the setting information set on the setting screen. The generation unit 93 may generate a two-dimensional code including a part or all of the setting information.

[0032] The store terminal 10 includes, as functional elements, a setting information acquisition unit 11 and a purchase processing unit 12. The setting information acquisition unit 11 is a functional element that acquires various information sent from the user terminal 91. The purchase processing unit 12 is a functional element that executes processing related to product transactions (specifically, purchases).

[0033] The transaction management server 20 comprises, as functional elements, a credit request unit 21, a data acquisition unit 22, and a payment information processing unit 23. The credit request unit 21 is a functional element that executes processing related to confirmation of credit for deferred payment means. The data acquisition unit 22 is a functional element that accesses the database 30 to acquire various information. The payment information processing unit 23 is a functional element that relays the transfer of payment information from the second sales management server 60 to the payment management server 40.

[0034] The database 30 is a device that stores various information used in individual transactions. For example, the database 30 may store data related to product information, coupon information, and point card information for each customer 90. The database 30 may also store card data related to deferred payment cards. The database 30 may be a component of the transaction management system 1, or may be a component not included in the transaction management system 1. The database 30 in this embodiment is a device separate from the transaction management server 20, but may be a component of the transaction management server 20.

[0035] Each record of the card data includes customer identification information, and a set of the official card number (card information) of the postpaid card and the tokenized card number. That is, this card data associates the customer identification information, the official card number, and the tokenized card number. The card data is generated based on the credit card information provided by the customer 90 and stored in the database 30. Each record of the card data may be encrypted to improve security. The details of the procedure for registering the card data are not limited, and the flow of the procedure may be determined arbitrarily. In any case, when the card data is generated and stored, the official card number of the postpaid card is tokenized to generate the tokenized card number. In this embodiment, it is assumed that the card data corresponding to the customer identification information is stored in the database 30 (hereinafter, referred to as "setting of the postpaid card").

[0036] The payment management server 40 comprises, as functional elements, a credit inquiry unit 41 and a payment unit 42. The credit inquiry unit 41 is a functional element that executes credit inquiries for individual transactions (payments). The payment unit 42 is a functional element that executes processes related to payments.

[0037] The first sales management server 50 has, as functional elements, a detoken unit 51 and a transaction / payment management unit 52. The detoken unit 51 is a functional element that acquires an official card number from the transaction management server 20. The transaction / payment management unit 52 is a functional element that acquires transaction information from the store terminal 10 and transmits the payment information to the payment management server 40.

[0038] The second sales management server 60 includes a transaction / settlement management unit 61 as a functional element. The transaction / settlement management unit 61 is a functional element that acquires transaction information from the store terminal 10 and transmits the settlement information to the transaction management server 20.

[0039] The application server 70 includes, as a functional element, a token generating unit 71. The token generating unit 71 is a functional element that acquires customer identification information from the user terminal 91 and generates a one-time token.

[0040] FIG. 3 is a diagram showing a general hardware configuration of a computer 100 that can function as a server or terminal related to the transaction management system 1. For example, the computer 100 includes a processor 101, a main memory unit 102, an auxiliary memory unit 103, a communication control unit 104, an input device 105, and an output device 106. The processor 101 executes an operating system and an application program. The main memory unit 102 is composed of, for example, a ROM and a RAM. The auxiliary memory unit 103 is composed of, for example, a hard disk or a flash memory, and generally stores a larger amount of data than the main memory unit 102. The auxiliary memory unit 103 stores a program 110 for causing at least one computer to function as a server or a terminal. The communication control unit 104 is composed of, for example, a network card or a wireless communication module. The input device 105 is composed of, for example, a keyboard, a mouse, a touch panel, etc. The output device 106 is composed of, for example, a monitor and a speaker.

[0041] Each functional element of each device is realized by loading program 110 onto processor 101 or main memory 102 and executing the program. Program 110 includes code for realizing each functional element of the corresponding server or terminal. Processor 101 operates communication control unit 104, input device 105, or output device 106 in accordance with program 110, and reads and writes data in main memory 102 or auxiliary memory 103. Each functional element of the corresponding server or terminal is realized by this processing. Data or database required for processing may be stored in main memory 102 or auxiliary memory 103.

[0042] Each server may be composed of one or more computers. When multiple computers are used, these computers are connected to each other via a communication network to logically configure one server.

[0043] The program 110 may correspond to a transaction management program. The program 110 may be provided by being fixedly recorded on a tangible recording medium such as a CD-ROM, a DVD-ROM, or a semiconductor memory. Alternatively, the program 110 may be provided via a communication network as a data signal superimposed on a carrier wave.

[0044] 4 is a diagram showing an example of a setting screen. The setting screen is a screen for setting setting information. The setting screen may be provided to the user terminal 91 as, for example, one screen of an installed application or one screen of a Web application. The user terminal 91 displays the setting screen and accepts input of setting information from the customer 90. The setting screen includes ID setting 911, product setting 912, and payment-related setting 913.

[0045] The user terminal 91 requests a one-time token inquiry from the application server 70 before or while the setting screen is displayed, and acquires the one-time token. For example, the one-time token inquiry may be executed by background processing before the setting screen is displayed. The user terminal 91 may acquire the one-time token automatically, or may acquire the one-time token triggered by an operation of the customer 90. The user terminal 91 may or may not display the one-time token on the setting screen. The one-time token is used only once to verify whether the customer 90 is the real person. The one-time token may be set to have a usable expiration date.

[0046] ID setting 911 is a screen element for setting customer identification information. For example, transaction management system 1 may issue customer identification information to customer 90 registered as a user, and transmit the customer identification information to user terminal 91. User terminal 91 may automatically set the customer identification information in ID setting 911.

[0047] Product setting 912 is a screen element for setting product information. The product information may be a default value for a product that the customer 90 normally or frequently purchases. The product information includes, for example, the type of fuel and the amount of fuel to be filled. Examples of the type of fuel include high-octane gasoline, regular gasoline, and diesel. Examples of the amount of fuel to be filled include quantity (e.g., 3L to 100L) or amount (e.g., 300 yen to 14,999 yen). By combining the type of fuel and the amount of fuel to be filled, the product information is set as, for example, "high-octane gasoline 30L."

[0048] The payment related settings 913 are screen elements for setting payment related information. For example, the payment related settings 913 include a coupon setting 913a for setting a coupon, and a point card setting 913b for setting a point card. The coupon setting 913a may accept the selection of a coupon that has been delivered to the user terminal 91 in advance. The coupon may be delivered to the user terminal 91 from, for example, the transaction management system 1, or may be delivered to the user terminal 91 from another server or the like. The point card setting 913b may accept, for example, the input of a point card number that uniquely identifies a point card. The payment related settings 913 in this embodiment can set the coupon setting 913a and the point card setting 913b individually, but any constraint may be imposed on the settings. For example, a constraint that requires the setting of a postpaid card may be imposed on the input to the point card setting 913b.

[0049] At least one of the one-time token, customer identification information, product information, and payment-related information is set on the setting screen. For example, the customer 90 inputs setting information by operating at least one of the ID setting 911, product setting 912, and payment-related setting 913. The one-time token is automatically acquired using the customer identification information. There are various combination patterns of setting information corresponding to the presence or absence of each of the ID setting 911, product setting 912, and payment-related setting 913. The user terminal 91 processes at least one of the one-time token, customer identification information, product information, and payment-related information set on the setting screen as setting information, and generates a two-dimensional code 914 including the setting information.

[0050] The user terminal 91 may generate the two-dimensional code 914 each time the setting information is updated. For example, the user terminal 91 may generate the two-dimensional code 914 when the user terminal 91 acquires a one-time token. Alternatively, the user terminal 91 may display a confirmation screen or the like for confirming the setting information, and generate the two-dimensional code 914 when the customer performs a confirmation operation. The two-dimensional code 914 may be displayed on the setting screen, or may be displayed on another screen. The user terminal 91 may transmit a part or all of the setting information to the transaction management server 20 via the application server 70. The transaction management server 20 may store the setting information in the database 30. The user terminal 91 may generate the two-dimensional code 914 including a part or all of the setting information. In one example, when a part of the setting information (e.g., customer identification information) is stored in the database 30, the user terminal 91 may generate the two-dimensional code 914 that does not include the customer identification information. When the two-dimensional code 914 does not include a part of the setting information, the setting information may be treated as a pattern in which the part is not set. When a postpaid card is set up (the database 30 stores card data), the user terminal 91 may or may not display the official card number on the setting screen. Even when a postpaid card is set up, the user terminal 91 generates a two-dimensional code 914 that does not include the official card number.

[0051] [System Operation] With reference to Figures 5 to 8, the operation of the transaction management system 1 will be described, as well as the transaction management method according to this embodiment. Figures 5 to 8 are all sequence diagrams showing an example of the operation of the transaction management system 1. More specifically, Figure 5 shows the inquiry process for a one-time token, Figure 6 shows the process for one transaction (one purchase procedure), and Figures 7 and 8 are diagrams showing an example of closing processing. Figures 5 to 8 also show the correspondence with the steps shown in Figure 1.

[0052] First, the process related to the one-time token will be described as process flow S1 with reference to Fig. 5. In step S101, the user terminal 91 requests a one-time token inquiry by transmitting customer identification information to the application server 70. In one example, the user terminal 91 requests a one-time token inquiry before or while a setting screen such as that shown in Fig. 4 is displayed.

[0053] In step S102, the token generating unit 71 of the application server 70 generates a one-time token in response to the one-time token inquiry request. A one-time token is generated for each one-time token inquiry.

[0054] In step S103, the application server 70 sends a notification including the generated one-time token and the customer identification information to the transaction management server 20. The transaction management server 20 receives the notification.

[0055] In step S104, the transaction management server 20 stores the correspondence between the one-time token and the customer identification information in the database 30. This enables the transaction management server 20 to derive the customer identification information based on the one-time token.

[0056] In step S105, the application server 70 transmits a response including the generated one-time token to the user terminal 91. The user terminal 91 receives the response and thereby acquires the one-time token.

[0057] Next, the processing in one transaction will be described as processing flow S2 with reference to Fig. 6. In step S201, the display unit 92 of the user terminal 91 displays a setting screen for setting in advance setting information used for purchasing a product at a service station. For example, the display unit 92 displays a setting screen as shown in Fig. 4 and accepts input of setting information from the customer 90. The processing flow S1 shown in Fig. 5 may be executed before the processing of step S201 or may be executed during the processing of step S201.

[0058] In step S202, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 including the setting information set on the setting screen. The setting information includes at least one of a one-time token, customer identification information, product information, and payment-related information. For example, the generation unit 93 generates a two-dimensional code 914 including a one-time token, product information, and payment-related information, but not including customer identification information. In this example, the setting information corresponds to a pattern in which a one-time token, product information, and payment-related information are set, and customer identification information is not set.

[0059] In step S203, the user terminal 91 displays the two-dimensional code 914 for purchasing a product in a store. For example, the customer 90 operates the user terminal 91 to display the two-dimensional code 914, and holds the surface on which the two-dimensional code 914 is displayed over the two-dimensional code reader 19.

[0060] In step S204, the two-dimensional code reader 19 reads the two-dimensional code 914. For example, in response to the customer 90 holding the user terminal 91 over the two-dimensional code reader 19, the two-dimensional code reader 19 starts reading the two-dimensional code 914 displayed on the user terminal 91.

[0061] In step S205, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The two-dimensional code reader 19 reads the two-dimensional code 914 displayed on the user terminal 91 and transmits the read information to the store terminal 10. As a result, the store terminal 10 acquires the setting information. The store terminal 10 holds the acquired setting information.

[0062] In step S206, the purchase processing unit 12 of the store terminal 10 transmits a credit inquiry to the transaction management server 20. The credit inquiry is a data signal for checking the credit status of the post-payment card. The credit inquiry includes, for example, the current date and time, a store ID that is an identifier for uniquely identifying the store where the store terminal 10 is located, a one-time token, and a provisional purchase amount. The provisional purchase amount is a purchase amount that is provisionally set in order to execute a credit inquiry for the post-payment card, and is not the purchase amount of the product. An extremely low amount is set as the provisional purchase amount. For example, the minimum value that can occur in a transaction (for example, 1 yen in Japanese yen) may be set as the provisional purchase amount. The transaction management server 20 receives the credit inquiry.

[0063] In step S207, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to acquire customer identification information corresponding to the one-time token indicated by the credit inquiry, and further acquires card data corresponding to the customer identification information. Since the customer identification information can be derived from the one-time token, the transaction management server 20 can determine that the customer 90 has had the two-dimensional code reader 19 read the two-dimensional code 914. In other words, the transaction management server 20 can verify whether the customer 90 who purchases the product is the actual customer. Through this process, the data acquisition unit 22 acquires two types of card numbers corresponding to the customer identification information, i.e., the official card number and the tokenized card number.

[0064] In step S208, the credit request unit 21 of the transaction management server 20 sends a credit inquiry request to the payment management server 40. The credit inquiry request is a data signal for causing the payment management server 40 to execute a credit inquiry for the postpaid card corresponding to the customer identification information. The credit inquiry request includes the current date and time, the official card number obtained from the database 30, and the provisional purchase amount indicated in the credit inquiry. The payment management server 40 receives the credit inquiry request.

[0065] In step S209, the credit inquiry unit 41 of the payment management server 40 performs a credit inquiry on the post-payment card corresponding to the official card number indicated in the credit inquiry request, and transmits the result to the transaction management server 20 as a credit result. The credit inquiry unit 41 determines whether the post-payment card can be used in a transaction at the store by referring to data indicating the status, credit limit, etc. of the post-payment card. Since the provisional purchase amount is an extremely low amount (for example, the minimum amount that can occur in a transaction), the credit inquiry unit 41 approves the use of the post-payment card unless there are special circumstances such as the post-payment card being suspended or the credit limit having already been exceeded. The credit inquiry unit 41 transmits the result of the credit inquiry to the transaction management server 20 as a credit result. The transaction management server 20 receives the credit result.

[0066] In step S210, the credit request unit 21 of the transaction management server 20 sends a response to the store terminal 10. The response is a data signal indicating an answer to the credit inquiry. The response includes the credit result and the tokenized card number. The store terminal 10 receives the response. This response does not include the official card number. In other words, the credit request unit 21 sends the tokenized card number to the store terminal 10 without sending the official card number to the store terminal 10. Because the store terminal 10 does not obtain the official card number, the store clerk does not recognize the official card number of the post-paid card of the customer 90 in the transaction.

[0067] In step S211, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of the product. The purchase processing unit 12 executes the settings based on the product information acquired from the user terminal 91. The specific method of setting related to the purchase of the product is not limited. For example, if the product is fuel oil such as gasoline or diesel, the product information may indicate default values ​​related to refueling (for example, the type of fuel and the amount of refueling) that are set in advance. The store terminal 10 displays the product information (default values) on a monitor and asks the customer 90 whether or not to purchase the product according to the information. The customer 90 can operate the store terminal 10 to determine the details of the product to be purchased. For example, the customer 90 can operate a refueling machine, which is an example of the store terminal 10, to select refueling based on the default value, or request refueling after changing the type of fuel or the amount of refueling from the default value. As described above, the type of product is not limited in any way, and correspondingly, the content of the product information is not limited in any way.

[0068] In step S212, the purchase processing unit 12 of the store terminal 10 executes a purchase process (payment process) to finalize the transaction. The purchase processing unit 12 executes payment by the deferred payment card only when the credit result indicates that the deferred payment card can be used. If a floor limit is set for purchases using deferred payment cards, the purchase processing unit 12 accepts only transactions up to a predetermined upper limit. The floor limit is a certain standard amount that requires a credit inquiry. If the purchase amount exceeds the floor limit, approval from the card company is requested. If the purchase amount is equal to or less than the floor limit, no credit inquiry is made. For example, if the floor limit is 15,000 yen, the purchase processing unit 12 accepts purchases and payments by the deferred payment card only if the purchase amount is equal to or less than 15,000 yen. At this point, a credit inquiry using an extremely low amount (for example, the minimum amount possible for a transaction) has been completed, so payment subject to the floor limit is possible. For example, if the store terminal 10 is a fuel dispenser at a gas station, the fuel dispenser controls fuel dispensing so that the purchase amount does not exceed a floor limit.

[0069] If there is an available coupon, the purchase processing unit 12 may display the coupon on the monitor and inquire of the customer 90 whether or not to use at least a portion of the coupon to purchase the product. The purchase processing unit 12 may calculate a discounted amount from the purchase amount based on the selection of the customer 90 and the purchase amount. When the customer 90 uses a coupon to make a purchase, the purchase processing unit 12 may accept the transaction if the purchase amount is equal to or less than the sum of the floor limit and the discount amount.

[0070] If there is a point balance on the point card, the purchase processing unit 12 may display the point balance on the monitor and inquire of the customer 90 whether or not to use at least a portion of the points to purchase an item. The purchase processing unit 12 may add or subtract points from the point card based on the customer 90's selection and the purchase amount. If the customer 90 uses points to make a purchase, the purchase processing unit 12 may accept the transaction if the purchase amount is equal to or less than the sum of the floor limit and the used points.

[0071] When the purchase process is completed, the purchase processing unit 12 issues a receipt, generates a record of transaction information indicating one transaction, and stores the record in a specified storage unit. One record of transaction information indicates, for example, the transaction date and time, the store ID, the tokenized card number, and product information. The product information indicates, for example, the name, unit price, quantity, and purchase amount (= unit price x quantity) for each of one or more products.

[0072] In process flow S2, the store terminal 10 receives the response including the tokenized card number and executes the payment for the product based on the response. That is, the store terminal 10 executes the payment for the product without obtaining the official card number.

[0073] At each store terminal 10, the process flow S2 is executed for each transaction (payment), and thus transaction information is accumulated at each store terminal 10. The accumulated transaction information is transmitted to the first sales management server 50 or the second sales management server 60 by a closing process.

[0074] Next, the closing process via the first sales management server 50 will be described as process flow S3 with reference to Fig. 7. This closing process is generally a daily process, but the execution timing of process flow S2 is not limited to this and may be executed at any timing.

[0075] In step S301, the purchase processing unit 12 of the store terminal 10 transmits transaction information indicating one or more transactions (more specifically, one or more transactions that have occurred since the previous closing process) to the first sales management server 50. The first sales management server 50 receives the transaction information.

[0076] In step S302, the de-token unit 51 of the first sales management server 50 sends a de-token request to the transaction management server 20. The de-token request is a data signal for obtaining the official card number of the post-payment card, and includes one or more tokenized card numbers indicated in the transaction information. The transaction management server 20 receives the de-token request.

[0077] In step S303, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to acquire one or more official card numbers corresponding to the one or more tokenized card numbers indicated in the de-token request. Since the official card numbers and the tokenized card numbers have a one-to-one correspondence, the data acquisition unit 22 can obtain the official card number for each of the one or more tokenized card numbers.

[0078] In step S304, the data acquisition unit 22 transmits a de-token response to the first sales management server 50. The de-token response is a data signal indicating a response to the de-token request, and includes one or more pairs of a formal card number and a tokenized card number. The first sales management server 50 receives the de-token response.

[0079] In step S305, the transaction / settlement management unit 52 of the first sales management server 50 transmits the settlement information corresponding to the transaction information to the settlement management server 40. Specifically, the transaction / settlement management unit 52 generates the settlement information by replacing each of one or more tokenized card numbers indicated in the transaction information with a proper card number. This replacement is called detokenization. The transaction / settlement management unit 52 transmits the settlement information to the settlement management server 40. The settlement management server 40 receives the settlement information, and the settlement unit 42 executes the settlement based on the settlement information. The transmission of the settlement information by the first sales management server 50 (step S305) may or may not correspond to the transmission of the transaction information by the store terminal 10 (step S301). For example, both the transmission of the transaction information and the transmission of the settlement information may be daily processes. Alternatively, the transmission of the transaction information may be daily processes, and the transmission of the settlement information may be monthly processes or bimonthly processes.

[0080] Next, the closing process via the second sales management server 60 will be described as process flow S4 with reference to Fig. 8. As with process flow S3, this closing process may be a daily process or may be executed at any other timing.

[0081] In step S401, the purchase processing unit 12 of the store terminal 10 transmits transaction information indicating one or more transactions (more specifically, one or more transactions that have occurred since the previous closing process) to the second sales management server 60. The second sales management server 60 receives the transaction information.

[0082] In step S402, the transaction / settlement management unit 61 of the second sales management server 60 transmits the transaction information as payment information to the transaction management server 20. Unlike the first sales management server 50, the second sales management server 60 (transaction / settlement management unit 61) does not execute detokenization. The transaction management server 20 receives the payment information. The transmission of the payment information by the second sales management server 60 (step S402) may or may not correspond to the transmission of the transaction information by the store terminal 10 (step S401). For example, both the transmission of the transaction information and the transmission of the payment information may be processed daily. Alternatively, the transmission of the transaction information may be processed daily, and the transmission of the payment information may be processed monthly or bimonthly.

[0083] In step S403, the data acquisition unit 22 and the payment information processing unit 23 of the transaction management server 20 cooperate to replace the tokenized card number in the payment information with a legitimate card number. The data acquisition unit 22 accesses the database 30 to acquire one or more legitimate card numbers corresponding to the one or more tokenized card numbers indicated in the payment information. The payment information processing unit 23 replaces each of the one or more tokenized card numbers indicated in the payment information with a legitimate card number. That is, the payment information processing unit 23 performs de-tokenization.

[0084] In step S404, the payment information processing unit 23 transmits the processed payment information to the payment management server 40. The payment management server 40 receives the payment information, and the payment unit 42 executes the payment based on the payment information.

[0085] FIG. 9 is a sequence diagram showing another example of transaction processing by the transaction management system 1 according to the embodiment. With reference to FIG. 9, the processing for one transaction will be described as process flow S5, focusing mainly on the differences from process flow S2. Process flow S5 is based on the premise that database 30 stores product information corresponding to customer identification information. FIG. 9 shows an example in which the store terminal 10 queries the transaction management server 20 for product information.

[0086] In step S501, the display unit 92 of the user terminal 91 displays a setting screen. The process of step S501 is similar to the process of step S201. The process flow S1 shown in Fig. 5 may be executed before the process of step S501 or during the process of step S501.

[0087] In step S502, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 including the setting information set on the setting screen. For example, the generation unit 93 generates a two-dimensional code 914 including a one-time token and payment related information, but not including customer identification information and product information. In this example, the setting information corresponds to a pattern in which a one-time token and payment related information are set, but customer identification information and product information are not set.

[0088] In step S503, the user terminal 91 displays the two-dimensional code 914 for purchasing a product in a store. The process of step S503 is similar to the process of step S203.

[0089] In step S504, the two-dimensional code reader 19 reads the two-dimensional code 914. The process in step S504 is similar to the process in step S204.

[0090] In step S505, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The process of step S505 is similar to the process of step S205.

[0091] In step S506, the purchase processing unit 12 of the store terminal 10 transmits a credit inquiry and an inquiry about product information to the transaction management server 20. The inquiry about product information is a data signal for requesting acquisition of product information. The inquiry about product information may be part of the credit inquiry or may be a separate data signal.

[0092] In step S507, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to acquire customer identification information corresponding to the one-time token indicated by the credit inquiry, and further acquires product information and card data corresponding to the customer identification information.

[0093] In step S508, the credit request unit 21 of the transaction management server 20 transmits a credit inquiry request to the settlement management server 40. The process of step S508 is similar to the process of step S208.

[0094] In step S509, the credit inquiry unit 41 of the payment management server 40 executes a credit inquiry for the post-payment card corresponding to the official card number indicated by the credit inquiry request, and transmits the result as a credit result to the transaction management server 20. The process of step S509 is similar to that of step S209.

[0095] In step S510, the credit request unit 21 of the transaction management server 20 sends a response to the store terminal 10. The response includes the credit result, the product information, and the tokenized card number. The store terminal 10 receives the response.

[0096] In step S511, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of a product. The purchase processing unit 12 executes the settings based on the product information acquired from the transaction management server 20. The process of step S511 is similar to the process of step S211, except that the route of acquiring the product information is different.

[0097] In step S512, the purchase processing unit 12 of the store terminal 10 executes a purchase process (payment process) for finalizing the transaction. The process of step S512 is similar to the process of step S212.

[0098] After execution of process flow S5, process flow S3 shown in FIG. 7 or process flow S4 shown in FIG. 8 may be executed.

[0099] Figure 10 is a sequence diagram showing another example of transaction processing by the transaction management system 1 according to the embodiment. With reference to Figure 10, the processing for one transaction will be described as process flow S6, focusing mainly on the differences from process flow S2. In process flow S6, process flow S1 shown in Figure 5 is not executed. Figure 10 shows an example in which the customer 90 does not set up a deferred payment card (an example in which the database 30 does not store card data).

[0100] In step S601, the display unit 92 of the user terminal 91 displays a setting screen. The process of step S601 is similar to the process of step S201.

[0101] In step S602, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 including the setting information set on the setting screen. For example, the generation unit 93 generates a two-dimensional code 914 including product information and not including a one-time token, customer identification information, and payment-related information. In this example, the setting information corresponds to a pattern in which product information is set and a one-time token, customer identification information, and payment-related information are not set.

[0102] In step S603, the user terminal 91 displays the two-dimensional code 914 for purchasing a product in a store. The process of step S603 is similar to the process of step S203.

[0103] In step S604, the two-dimensional code reader 19 reads the two-dimensional code 914. The process in step S604 is similar to the process in step S204.

[0104] In step S605, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The process of step S605 is similar to the process of step S205.

[0105] In step S606, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of the product. The process of step S606 is similar to the process of step S211.

[0106] In step S607, the purchase processing unit 12 of the store terminal 10 executes a purchase process (payment process) to finalize the transaction. The purchase processing unit 12 may accept a selection of a payment method from the customer 90. For example, the purchase processing unit 12 may accept payment by cash, deferred payment, or advance payment (e.g., a prepaid card).

[0107] FIG. 11 is a sequence diagram showing another example of transaction processing by the transaction management system 1 according to the embodiment. With reference to FIG. 11, the processing for one transaction will be referred to as process flow S7, and the differences from process flow S2 will be mainly described. In process flow S7, it is assumed that the database 30 stores product information corresponding to the customer identification information. Furthermore, in process flow S7, process flow S1 shown in FIG. 5 is not executed. FIG. 11 shows an example in which the customer 90 has not set up a deferred payment card (the database 30 does not store the card data) and the store terminal 10 queries the transaction management server 20 for product information.

[0108] In step S701, the display unit 92 of the user terminal 91 displays a setting screen. The process of step S701 is similar to the process of step S201.

[0109] In step S702, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 including the setting information set on the setting screen. For example, the generation unit 93 generates a two-dimensional code 914 including customer identification information and not including a one-time token, product information, or payment-related information. In this example, the setting information corresponds to a pattern in which customer identification information is set and a one-time token, product information, or payment-related information is not set.

[0110] In step S703, the user terminal 91 displays the two-dimensional code 914 for purchasing a product in a store. The process of step S703 is similar to the process of step S203.

[0111] In step S704, the two-dimensional code reader 19 reads the two-dimensional code 914. The process in step S704 is similar to the process in step S204.

[0112] In step S705, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The process of step S705 is similar to the process of step S205.

[0113] In step S706, the purchase processing unit 12 of the store terminal 10 sends a product information inquiry to the transaction management server 20. The product information inquiry includes customer identification information. The transaction management server 20 receives the product information inquiry.

[0114] In step S707, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to acquire product information corresponding to the customer identification information indicated by the product information inquiry.

[0115] In step S708, the credit request unit 21 of the transaction management server 20 sends a response to the store terminal 10. The response includes the product information. The store terminal 10 receives the response.

[0116] In step S709, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of the product. The process of step S709 is similar to the process of step S511.

[0117] In step S710, the purchase processing unit 12 of the store terminal 10 executes a purchase process (payment process) for finalizing the transaction. The process in step S710 is similar to the process in step S607.

[0118] [effect] As described above, a user terminal according to one aspect of the present disclosure includes at least one processor that generates a two-dimensional code including setting information used for purchasing a product at a service station, and displays the two-dimensional code for purchasing the product at the service station.

[0119] A store terminal according to one aspect of the present disclosure is disposed in a service station and includes at least one processor that reads a two-dimensional code displayed on a user terminal, acquires setting information used for purchasing a product at the service station, and executes a process related to the purchase based on the setting information.

[0120] A transaction management system according to one aspect of the present disclosure includes a user terminal and a store terminal of a service station. The user terminal generates a two-dimensional code including setting information used to purchase a product at the service station and displays the two-dimensional code for purchasing the product at the service station. The store terminal acquires the setting information by reading the two-dimensional code displayed on the user terminal and executes a process related to the purchase based on the setting information.

[0121] According to an aspect of the present disclosure, there is provided a transaction management method executed by a user terminal having at least one processor, the transaction management method including the steps of generating a two-dimensional code including setting information used for purchasing a product at a service station, and displaying the two-dimensional code for purchasing the product at the service station.

[0122] A transaction management program according to one aspect of the present disclosure causes a computer to execute steps of generating a two-dimensional code including setting information used for purchasing goods at a service station, and displaying the two-dimensional code for purchasing goods at the service station.

[0123] In this aspect, the setting information used to purchase the product at the service station is displayed as a two-dimensional code. Since the reading of the two-dimensional code does not require radio waves, it is possible to suppress the transmission of radio waves when purchasing the product at the service station.

[0124] In a user terminal according to another aspect, at least one processor displays a setting screen for setting the setting information in advance and generates a two-dimensional code including the setting information set on the setting screen. In this case, since the setting information can be set outside the service station, a flexible mechanism for purchasing products at the service station can be provided.

[0125] In the user terminal according to another aspect, at least one processor may obtain a one-time token used for verifying a customer at a service station and generate a two-dimensional code including the one-time token. In this case, the security of the product transaction is improved because the customer who purchases the product is verified as being the customer.

[0126] In the store terminal according to another aspect, the setting information may include product information indicating a product. At least one processor may execute a process related to a purchase based on the product information. In this case, the designation of product information at the store is simplified or unnecessary, improving the convenience of product transactions.

[0127] In a store terminal according to another aspect, the setting information may include customer identification information that uniquely identifies a customer at the service station. At least one processor may obtain product information indicating a product from a transaction management server based on the customer identification information, and execute a process related to a purchase based on the product information. In this case, the pre-set product information is managed by the transaction management server, and the store terminal executes a process related to a purchase based on the product information. This simplifies or eliminates the need to specify product information at the store, improving the convenience of product transactions.

[0128] [Variations] The present disclosure has been described in detail above based on the embodiments. However, the present disclosure is not limited to the above embodiments. The present disclosure can be modified in various ways without departing from the spirit and scope of the present disclosure.

[0129] In the embodiment, it has been described that the user terminal 91 displays the setting screen and accepts the input of the setting information, but the setting information may be copied from a different medium to the user terminal 91. For example, the customer 90 may own an NFC tag (hereinafter referred to as an "another tag") separate from the user terminal 91. The other tag may store the setting information desired by the customer 90 in advance. The database 30 may store the correspondence between the identifier of the other tag and the setting information. In addition, the transaction management system 1 may provide the user terminal 91 with a transfer screen for copying the setting information. For example, the customer 90 may input the identifier of the other tag that the customer 90 owns into the transfer screen. The transaction management system 1 may read out the setting information corresponding to the input identifier of the other tag from the database 30 and transmit the setting information to the user terminal 91. The user terminal 91 may store the received setting information in a memory area. In this manner, the setting information may be copied from the other tag to the user terminal 91. Alternatively, a copying device (e.g., a reader / writer) may be installed in the store to read the setting information from the separate tag and write the setting information to the user terminal 91. The setting information may be copied from the separate tag to the user terminal 91 by operating the copying device.

[0130] In the embodiment, it has been described that the user terminal 91 displays a setting screen and accepts input of product information, but the product information may be stored (registered) in advance by the application server 70. For example, the user terminal 91 may transmit an inquiry about product information to the application server 70 together with a request for a one-time token inquiry. The application server 70 may transmit the product information to the user terminal 91 together with a response to the request for a one-time token inquiry. The user terminal 91 may generate a two-dimensional code including the one-time token and product information acquired from the application server 70.

[0131] In another modified example, the point card information may be managed by an external server that manages points (hereinafter referred to as a "point management server"). The store terminal 10 may transmit the point card number acquired by reading the two-dimensional code to the external point management server. The point management server may determine whether the point card number is valid, identify the point balance corresponding to the point card number, and transmit the point balance to the store terminal 10. If the point card number is valid, the customer 90 may acquire points corresponding to the purchase of the product, or use at least a portion of the point balance as at least a portion of the purchase price. Also, the transaction management server 20 may transmit the point card number to an external point management server and acquire the point balance.

[0132] In this disclosure, the expression "at least one processor executes a first process, executes a second process, ... executes an nth process" or a corresponding expression indicates a concept including a case where the executing entity (i.e., the processor) of n processes from the first process to the nth process changes midway. In other words, this expression indicates a concept including both a case where all n processes are executed by the same processor and a case where the processor changes among the n processes according to an arbitrary policy.

[0133] The processing procedure of the method executed by at least one processor is not limited to the example in the embodiment. For example, some of the steps (processing) described above may be omitted, or each step may be executed in a different order. In addition, any two or more of the steps described above may be combined, or some of the steps may be modified or deleted. Alternatively, other steps may be executed in addition to each of the steps described above. [Explanation of symbols]

[0134] 1...transaction management system, 10...store terminal, 11...setting information acquisition unit, 12...purchase processing unit, 19...two-dimensional code reader, 20...transaction management server, 21...credit request unit, 22...data acquisition unit, 23...payment information processing unit, 30...database, 40...payment management server, 41...credit inquiry unit, 42...payment unit, 50...first sales management server, 51...detoken unit, 52...transaction / payment management unit, 60...second sales management server, 61...transaction / payment management unit, 70...application server, 71...token generation unit, 90...customer, 91...user terminal, 92...display unit, 93...generation unit, 911...ID setting, 912...product setting, 913...payment-related settings, 914...two-dimensional code.

Claims

1. At least one processor; the at least one processor: generating a two-dimensional code including setting information used for purchasing a product at a service station; displaying the two-dimensional code for purchasing the product at the service station; User terminal.

2. the at least one processor: displaying a setting screen for setting the setting information in advance; generating the two-dimensional code including the setting information set on the setting screen; 2. A user terminal according to claim 1.

3. the at least one processor: obtaining a one-time token for use in verifying a customer at said service station; generating the two-dimensional code including the one-time token; 3. A user terminal according to claim 1 or 2.

4. A store terminal disposed at a service station, At least one processor; the at least one processor: By reading a two-dimensional code displayed on a user terminal, setting information used for purchasing a product at the service station is obtained; Executing a process related to the purchase based on the setting information. Store terminal.

5. The setting information includes product information indicating the product, The at least one processor executes a process related to the purchase based on the product information. The store terminal according to claim 4.

6. the setting information includes customer identification information that uniquely identifies a customer at the service station; the at least one processor: acquiring product information indicating the product from a transaction management server based on the customer identification information; Executing a process related to the purchase based on the product information. The store terminal according to claim 4.

7. A transaction management system including a user terminal and a store terminal of a service station, The user terminal, generating a two-dimensional code including setting information used for purchasing a product at a service station; Displaying the two-dimensional code for purchasing the product at the service station; The store terminal, The setting information is acquired by reading the two-dimensional code displayed on the user terminal; Executing a process related to the purchase based on the setting information. Transaction management system.

8. 1. A method for managing transactions executed by a user terminal having at least one processor, comprising: generating a two-dimensional code including setting information used for purchasing a product at a service station; displaying the two-dimensional code for purchasing the product at the service station; A transaction management method including:

9. generating a two-dimensional code including setting information used for purchasing a product at a service station; displaying the two-dimensional code for purchasing the product at the service station; A transaction management program that causes a computer to execute the above.

Images