Payment support system and store application software

Abstract

It supports both electronic payments via payment apps and electronic payments via payment web APIs. [Solution] A payment support system 10 includes a store terminal 20 and a management server 40. The store terminal 20 implements a store app 38, a payment app 61, and a browser 62. The store app 38 includes a main module 50 (including a UI), a first-type module 51, and a second-type module 52. The main module 50 accepts the purchaser's selection of an electronic payment method. If an electronic payment method using the payment app 61 is selected, the main module 50 launches the first-type module 51. If an electronic payment method using a payment web API is selected, the main module 50 launches the second-type module 52. The first-type module 51 launches the payment app 61 and passes settlement information to the second-type module 52. The second-type module 52 passes the settlement information via the browser 62 to a second-type payment server 82 that provides the payment web API.

Description

[Technical Field]

[0001] The present invention relates to a payment support system that supports electronic payments, and to store application software used in the payment support system. [Background technology]

[0002] When users purchase goods from commercial businesses, they pay using their mobile devices, credit cards, or IC cards. Mobile devices include smartphones, smartwatches, and tablets.

[0003] A user enters into a contract with a payment service provider and registers personal information required for electronic payments on a mobile device. Alternatively, a credit card or IC card is issued with an IC chip that stores the personal information. The personal information may include a user ID, bank account number, or electronic account number. Meanwhile, a commercial business enters into a contract with a payment service provider, and a payment app provided by the payment service provider is installed on a store terminal with a POS (Point of Sales) function.

[0004] When a user purchases a product, the payment app acquires the user's personal information through near-field wireless communication with the mobile device, credit card, or IC card. Alternatively, the payment app acquires the user's personal information by capturing a two-dimensional code (typically a QR code (registered trademark)) displayed on the mobile device with a camera. The payment app then transmits the personal information and settlement information, including the price, to a payment server via the Internet. The payment server then completes the payment based on the settlement information and personal information, and notifies the store terminal that the payment has been completed.

[0005] Currently, there are multiple payment service providers and multiple payment apps. Generally, commercial businesses enter into contracts with multiple payment service providers and install multiple payment apps on their store terminals.

[0006] Patent Document 1 discloses a tablet terminal (the above-mentioned store terminal) that implements a POS app and multiple payment apps. The POS app accepts the user's selection of an electronic payment method and launches the payment app corresponding to the electronic payment method selected by the user. When the POS app launches the payment app, it passes settlement information to the payment app. The payment app transmits the settlement information to a payment server via the Internet. The POS app allows the payment app to obtain the settlement information without any effort on the part of the user. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] WO2015 / 151510 publication Summary of the Invention [Problem to be solved by the invention]

[0008] Meanwhile, electronic payment methods such as One QR, which use a "payment web API (Application Programming Interface)" provided by a payment server, are becoming popular as they offer lower implementation costs than payment apps. This payment web API is implemented by a program that is sent from the payment server to the store terminal and runs on the store terminal's browser.

[0009] For example, the program may operate a communications module via a browser and OS, communicating with a mobile device to acquire personal information. Alternatively, the program may launch a camera application and a code reader application via the browser and OS, capturing a two-dimensional code (hereinafter referred to as "code") displayed on the mobile device to acquire personal information. The program is discarded when the browser is closed. In other words, unlike payment apps, payment web APIs are not programs implemented by store terminals, and therefore operate in a fundamentally different way from payment apps.

[0010] As described above, the POS app disclosed in Patent Document 1 can manage the launch of multiple payment apps, but because it does not "launch" a payment web API, the POS app cannot manage both a payment app and a payment web API. In other words, the POS app cannot handle both electronic payments provided by a payment app and electronic payments provided by a payment web API.

[0011] The present invention has been made against this background, and its purpose is to provide a payment support system that can handle both electronic payments provided by a payment app and electronic payments provided by a payment web API, and store application software to be used in the payment support system. [Means for solving the problem]

[0012] (1) A payment support system according to the present invention includes a store terminal installed in a store and having a display, an input interface, a first communication interface, a terminal computer, and a terminal memory; and a management server having a second communication interface, a server controller, and a server memory and capable of communicating with the store terminal via the Internet. The terminal memory stores store application software executed by the terminal computer, payment business application software, and a browser. The store application software includes a main module including a user interface, a first-type module for launching the payment business application software, and a second-type module for a payment web API. The main module causes the terminal computer to perform the following processes: acquiring payment information; accepting a selection of a payment method via the input interface; and selecting a corresponding module, either the first-type module or the second-type module, that corresponds to the payment method and passing the payment information to the selected corresponding module. The first type module selected as the corresponding module launches the payment business application software and causes the terminal computer to execute a process of passing the settlement information to the launched payment business application software. The second type module selected as the corresponding module launches the browser and causes the terminal computer to execute a process of passing a communication address stored in the terminal memory to the launched browser, a process of acquiring from the browser first data acquired by the browser from a payment server indicated by the communication address, a process of generating settlement information based on the acquired first data and the settlement information, and a process of transmitting the payment information to the payment server via the browser.

[0013] If the payment method selected by the purchaser of a product or other item is a payment method using payment business application software, the main module selects a Type 1 module. The selected Type 1 module launches the payment business application software and passes settlement information to the payment business application software. The payment business application software sends the received settlement information to the payment server. The payment server makes the payment based on the received settlement information. On the other hand, if the payment method selected by the purchaser is a payment method using a payment web API, the main module launches a Type 2 module. The launched Type 2 module launches a browser and passes the communication address of the payment server to the browser. The browser uses the communication address to communicate with the payment server, obtain the first data, and pass it to the Type 2 module. The Type 2 module generates payment information based on the first data and settlement information, and sends the generated payment information to the payment server via the browser. The payment server makes the payment based on the received payment information. In this way, the store application software can transmit settlement information to the first-class payment server and the second-class payment server without requiring any operation from the purchaser. Therefore, the payment support system according to the present invention allows the purchaser to easily make electronic payments, whether the electronic payment method selected by the purchaser is a method using payment business application software or a method using a payment web API.

[0014] (2) The terminal memory may store a plurality of types of the payment business application software. The store application software has a plurality of the first-type modules. Each first-type module corresponds to a single payment business application software.

[0015] The store application software has multiple types of Type 1 modules, and each Type 1 module corresponds to one payment business operator application software. Therefore, even if multiple payment business operator application software is installed in the store terminal, settlement information can be appropriately sent to the payment server regardless of the type of electronic payment selected by the purchaser and regardless of the purchaser's operation.

[0016] (3) The Type 1 module may cause the terminal computer to execute a process of acquiring payment completion information through the payment business application software. The Type 2 module may cause the terminal computer to execute a process of acquiring payment completion information through the browser. The main module may cause the terminal computer to execute a process of acquiring the payment completion information from the Type 1 module and the Type 2 module, a process of generating payment completion notification screen data based on the acquired payment completion information, and a process of displaying a payment completion notification screen indicated by the generated payment completion notification screen data on the display.

[0017] The main module generates payment completion notification screen data based on the payment completion information obtained from the Type 1 module and Type 2 module, and displays the payment completion notification screen on the display, so that the same payment completion notification screen can be displayed on the display regardless of the electronic payment method selected by the purchaser.

[0018] (4) The server memory may store a management database. The management database associates a business operator ID, a payment method, and module IDs indicating the first-type module and the second-type module. The main module causes the terminal computer to execute a process of transmitting a request including the business operator ID to the management server via the first communication interface and the Internet. The server controller executes a process of returning a response including the received business operator ID and the module ID associated in the management database to the store terminal via the second communication interface and the Internet. The main module causes the terminal computer to execute an activation process of activating the first-type module and the second-type module indicated by the received module ID. The activation process is a process of storing the module IDs of the first-type module and the second-type module to be made available in the terminal memory as registration IDs.

[0019] The management database associates business IDs, payment methods, and module IDs. Business IDs are identification information that identify the business that introduces the payment support system. Payment methods are payment methods provided by the payment business. Module IDs are identification information that identify the Type 1 and Type 2 modules that correspond to the payment methods. The main module executes an activation process that makes the Type 1 and Type 2 modules that correspond to the payment methods that the business that introduces the payment support system has contracted and can use as usable modules. In other words, the management server can configure usable modules for each business (profit-making business). As a result, system management becomes easier.

[0020] (5) The main module may cause the terminal computer to execute a process of inputting an activation instruction to the Type 1 module and the Type 2 module indicated by the registration ID. Upon receiving the activation instruction, the Type 1 module causes the terminal computer to launch the corresponding payment business application software and to transfer predetermined first setting information. Upon receiving the activation instruction, the Type 2 module causes the terminal computer to launch the browser and transfer a communication address stored in the terminal memory to the launched browser, acquire second data acquired from a payment server indicated by the communication address through the browser, generate setting registration information based on the acquired second data and predetermined second setting information, and transmit the setting registration information to the payment server through the browser.

[0021] The first type of module enables electronic payments using payment business application software, and the second type of module enables electronic payments using payment web APIs. In this way, the automatic activation of the payment business application software and payment web APIs makes it easy for businesses to introduce payment support systems.

[0022] (6) The main module may cause the terminal computer to execute a process of transmitting a request including the registration ID and the business ID to the management server via the first communication interface and the Internet. The server controller executes a determination process of determining whether a correspondence between the first-type module and the second-type module indicated by the received registration ID and the received business ID matches a correspondence between the first-type module and the second-type module and the business ID registered in the management database, and a reply process of returning a response including the determination result of the determination process to the store terminal via the second communication interface and the Internet. Upon receiving the determination result indicating no match, the main module causes the terminal computer to re-execute the activation process.

[0023] If a business that has introduced the payment support system enters into a contract with a new payment service provider or terminates a contract with a payment service provider, and the available payment methods change, the determination process will determine that there is no match, and the activation process will be re-executed. In other words, the available payment methods will be changed automatically. This reduces the effort required for the business that introduces the payment support system and the business that operates the payment support system.

[0024] (7) The store application software according to the present invention is implemented in a store terminal. The store terminal is installed in a store and includes a display, an input interface, a first communication interface, a terminal computer, and a terminal memory. The terminal memory stores payment business application software and a browser. The store application software according to the present invention includes a main module including a user interface, a first-type module for launching the payment business application software, and a second-type module for a payment web API. The main module causes the terminal computer to execute the following processes: acquiring payment information; accepting input of a payment method via the input interface; and selecting a corresponding module, either the first-type module or the second-type module, corresponding to the payment method and passing the payment information to the selected corresponding module. The first-type module, which is the corresponding module, launches the payment business application software and causes the terminal computer to execute the following processes: passing the payment information to the launched payment business application software. The second type module, which is the corresponding module, causes the terminal computer to execute the following processes: launching the browser and passing the communication address stored in the terminal memory to the launched browser; acquiring, through the browser, first data acquired from the payment server indicated by the communication address; generating payment information based on the acquired first data and the settlement information; and transmitting the payment information to the payment server through the browser.

[0025] If the payment method selected by the purchaser of a product or other item is a payment method using payment business application software, the main module selects a Type 1 module. The selected Type 1 module launches the payment business application software and passes settlement information to the payment business application software. The payment business application software sends the received settlement information to the payment server. The payment server makes the payment based on the received settlement information. On the other hand, if the payment method selected by the purchaser is a payment method using a payment web API, the main module launches a Type 2 module. The launched Type 2 module launches a browser and passes the communication address of the payment server to the browser. The browser uses the communication address to communicate with the payment server, obtain the first data, and pass it to the Type 2 module. The Type 2 module generates payment information based on the first data and settlement information, and sends the generated payment information to the payment server via the browser. The payment server makes the payment based on the received payment information. In this way, the store application software can send settlement information to the first-class payment server and the second-class payment server without relying on the purchaser's operation. Therefore, the store application software according to the present invention allows the purchaser to easily make electronic payments, whether the electronic payment method selected by the purchaser is a method using payment business application software or a method using a payment web API. [Effects of the Invention]

[0026] The payment support system and store application software of the present invention enable purchasers to easily make electronic payments, regardless of whether the electronic payment method selected by the purchaser is a method using payment business application software or a method using a payment web API. [Brief explanation of the drawings]

[0027] [Figure 1] FIG. 1 is a functional block diagram of a payment support system 10. [Figure 2] FIG. 2 is a diagram showing the management database. [Figure 3] FIG. 3A is a diagram showing a correspondence table, and FIG. 3B is a diagram showing a registration table. [Figure 4] FIG. 4 is a flowchart of the registration process executed by the store terminal 20 and the management server 40 at startup. [Figure 5] FIG. 5 is a flowchart of the validation process executed by the store terminal 20. [Figure 6] FIG. 6 is a flowchart of electronic payment using the payment application 61. [Figure 7] Figure 7 is a flowchart of electronic payment using the payment web API. [Figure 8] FIG. 8 is a flowchart of electronic payment using payment application 61 and purchaser terminal 70. [Figure 9] FIG. 9 is a flowchart of electronic payment using the payment web API and the purchaser terminal 70. [Figure 10] FIG. 10(A) is a diagram showing a payment method selection screen, and FIG. 10(B) is a diagram showing an instruction screen. [Figure 11] FIG. 11 shows the payment completion screen. DETAILED DESCRIPTION OF THE INVENTION

[0028] A preferred embodiment of the present invention will be described below with reference to the drawings as appropriate. Note that this embodiment is merely one aspect of the payment support system according to the present invention, and it goes without saying that the implementation may be changed without departing from the spirit of the present invention. Furthermore, the execution order of the processes (steps) in the flowcharts shown in Figures 4 to 9 is merely an example, and the execution order of each process may be changed as appropriate, other processes may be added, or some processes may be omitted, without departing from the spirit of the present invention.

[0029] Figure 1 is a functional block diagram of payment support system 10 according to the present invention. Figure 2 is a diagram showing the management database stored in server memory 43 of management server 40. Figure 3(A) is a diagram showing the correspondence table stored in server memory 43, and Figure 3(B) is a diagram showing the registration table stored in terminal memory 32 of store terminal 20.

[0030] [Outline of Payment Support System 10]

[0031] The payment support system 10 shown in FIG. 1 is a system that spans commercial businesses, purchasers, service providers, and payment service providers.

[0032] A commercial business is a business that sells goods and the like. The sale of goods and the like includes the sale of goods and the provision of commercial services. Commercial services include laundry services for clothes and vehicle rental services. Commercial businesses include, for example, supermarkets, dry cleaners, and car rental shops. Commercial businesses receive support services related to electronic payments through payment support system 10. Two commercial businesses, first commercial business 11 and second commercial business 12, are shown in Figure 1. The number of commercial businesses may be one, or three or more.

[0033] A commercial business has one or more stores. The stores are not virtual stores that exist on the Internet 19, but actual stores that purchasers visit. A store terminal 20 is installed in the commercial business's store. The store terminal 20 accepts electronic payments from purchasers.

[0034] A purchaser is a person who purchases goods or the like at a store of a commercial business and pays the price (money) to the commercial business by electronic payment or cash.

[0035] A payment service provider is a business that accepts electronic payments from purchasers. Electronic payments are a payment method that does not use cash. Examples of electronic payments include a payment method in which the purchaser transfers the payment from their bank account to the bank account of a commercial business, a payment method in which a payment service provider (credit card company) contracted by the purchaser transfers the payment to the commercial business on the purchaser's behalf, and a payment method in which the purchaser purchases electronic money and then transfers the payment to the commercial business from that electronic money. An electronic payment method that uses the purchaser's bank account is known as "direct debit," an electronic payment method that uses a credit card company is known as "credit card payment," and an electronic payment method that uses electronic money is known as "IC card payment," such as "Suica (registered trademark)," "ICOCA (registered trademark)," and "WAON (registered trademark)."

[0036] There are multiple payment providers. There are also multiple payment methods, such as "bank accounts," "credit," and "electronic money." In the following explanation, the combination of a payment provider and a payment method will be referred to as an "electronic payment method." In other words, even if the payment is made with the same "electronic money," the electronic payment method will be different if the payment provider is different. Also, even if the electronic payment is made by the same payment provider, the electronic payment methods will be different between "credit" and "electronic money."

[0037] A commercial business enters into a contract with one or more of the payment service providers and makes one or more electronic payment instruments available to the purchaser. Meanwhile, a purchaser also enters into a contract with one or more of the payment service providers and makes one or more electronic payment instruments available to the purchaser. The purchaser pays the price electronically using the electronic payment instrument with which the purchaser has entered into a contract and with which the commercial business has entered into a contract.

[0038] A service provider is a business that operates payment support system 10 and provides services to support electronic payments to commercial businesses.

[0039] A feature of payment support system 10 according to this embodiment is that store application software 38 (hereinafter, "store app 38") is implemented in store terminal 20. Specifically, a feature of payment support system 10 according to this embodiment is that store app 38 executes configurations and processes that are compatible with various payment apps 61 and payment web APIs.

[0040] [Configuration of payment support system 10]

[0041] Payment support system 10 includes multiple store terminals 20 and management server 40. Although FIG. 1 shows purchaser terminal 70 held by a purchaser of a product or the like, and first-class payment server 81 and second-class payment server 82 operated by a payment service provider, purchaser terminal 70, first-class payment server 81, and second-class payment server 82 are not included in payment support system 10.

[0042] [Store terminal 20]

[0043] A store terminal 20 is installed in each store operated by a commercial business operator. One store terminal 20 is installed in one store. Multiple store terminals 20 may be installed in one store. As an example of multiple store terminals 20, multiple first store terminals 21 and multiple second store terminals 22 are shown in FIG. 1. The first store terminal 21 is installed in each store operated by a first commercial business operator 11. The second store terminal 22 is installed in each store operated by a second commercial business operator 12.

[0044] The store terminal 20 is a fixed or portable computer such as a personal computer or a tablet. The store terminal 20 may be a so-called POS device. The store terminal 20 is operated in the store by purchasers and store employees. The store terminal 20 is operated by employees of the service provider during initial setup and maintenance.

[0045] The store terminal 20 includes a terminal controller 30, a touch panel 33, a first communication interface 34, a camera 35, and a scanning device 36. The touch panel 33, the first communication interface 34, the camera 35, and the scanning device 36 correspond to the "input interface" described in the claims.

[0046] The terminal controller 30 includes a CPU 31, which is a central processing unit, and a terminal memory 32. The CPU 31 corresponds to the "terminal computer" described in the claims.

[0047] Terminal memory 32 stores OS 37, store app 38, multiple payment application software 61 (hereinafter referred to as "payment app 61"), and browser 62. Payment app 61 corresponds to "payment business application software" recited in the claims.

[0048] The OS 37 is an operating system that provides various APIs (Application Programming Interfaces) for controlling the display of images on the touch panel 33, the reception of input from the touch panel 33, and communication.

[0049] The browser 62 is software that provides the function of accessing web servers and websites, such as Google Chrome (registered trademark), Firefox (registered trademark), Microsoft Edge (registered trademark), Safari (registered trademark), or Smooz (registered trademark).

[0050] The payment application 61 is an application provided by a payment service provider. One or more payment applications 61 are installed in the store terminal 20.

[0051] For example, an employee of the service provider installs all currently released payment apps 61, along with the store app 38, into the store terminal 20. The employee may install only the payment apps 61 that the service provider handles into the store terminal 20. This installation may involve downloading from a website to the store terminal 20 or inputting from a portable storage medium such as a USB (registered trademark) memory.

[0052] One payment app 61 is an app for making payments using one electronic payment method. One payment app 61 may be an app for making payments using multiple electronic payment methods. For example, one payment app 61 is used for two types of electronic payments: electronic payment of "debit from a bank account" provided by one payment service provider, and electronic payment of "payment by electronic money." One payment app 61 may also be used for two types of electronic payments: electronic payment provided by one payment service provider and electronic payment provided by another payment service provider.

[0053] The payment application 61 has data necessary for communication with the first type payment server 81, such as its own application ID and the communication address of the first type payment server 81.

[0054] The store app 38 is application software provided by a service provider to a commercial business. For example, an employee of the service provider operates the store terminal 20 to install the store app 38 into the store terminal 20. This installation may involve downloading from a website to the store terminal 20 or inputting from a portable storage medium such as a USB memory (registered trademark).

[0055] The store application 38 includes a main module 50, a plurality of first-type modules 51, a plurality of second-type modules 52, and registration information.

[0056] The main module 50 includes a UI (User Interface). The UI is a program that causes the CPU 31 to execute processes such as displaying an input screen on the touch panel 33 to accept input operations from purchasers, store employees, service provider employees, etc., and acquiring input information.

[0057] The main module 50 starts predetermined first-type modules 51, second-type modules 52, and a browser 62 directly or via the OS 37. In other words, the main module 50 is a higher-level application of the first-type modules 51 and the second-type modules 52.

[0058] The type 1 module 51 is a program that activates the payment application 61. One type 1 module 51 is provided for one payment application 61. The store application 38 has all type 1 modules 51 that correspond to the payment applications 61 installed in the store terminal 20.

[0059] The second-type module 52 is a module that corresponds to an electronic payment method that uses a payment web API. One second-type module 52 is provided for one payment web API. In other words, the store app 38 has multiple second-type modules 52 that correspond to all currently released payment web APIs. The store app 38 may only have multiple second-type modules 52 that correspond to the payment web APIs handled by the service provider.

[0060] The registration information includes a business ID, which is identification information for individually identifying a commercial business, a terminal ID for individually identifying a store terminal 20, and the registration table shown in FIG. 3(B).

[0061] The registration table is a table that associates payment method numbers, information about payment application 61, information about first-type module 51 and second-type module 52, registration URLs, and payment URLs.

[0062] The payment method number is identification information that uniquely identifies an electronic payment method. One payment method number corresponds to one electronic payment method.

[0063] The information related to the payment app 61 includes the app ID, version information, contract flag, and activation flag. The app ID is identification information that individually identifies multiple payment apps 61. The version information is information that indicates the version of the payment app 61. The contract flag is either "1" or "0." A contract flag of "1" indicates that the payment service provider that provides the electronic payment means indicated by the corresponding payment service provider number has concluded a contract with the commercial business. A validation flag of "0" indicates that the payment service provider and the commercial business have not concluded a contract. The activation flag is either "1" or "0." An activation flag of "1" indicates that the "activation process" for registering the store terminal 20 with the payment service provider's first-class payment server 81 and second-class payment server 82 has already been executed. An execution flag of "0" indicates that the "activation process" has not yet been executed. The initial value of the activation flag is "1" for electronic payment means that do not require the "activation process," and "0" for electronic payment means that do require the "activation process." In other words, the payment processing system 10 can be used with both payment servers that require validation processing and payment servers that do not require validation processing.

[0064] The information related to the first type module 51 and the second type module 52 is a module ID and version information. The module ID is identification information that individually identifies the first type module 51 and the second type module 52. The version information is information that indicates the versions of the first type module 51 and the second type module 52.

[0065] In the registration table, there is a one-to-one correspondence between the payment application 61 and the type 1 module 51. One type 1 module 51 activates one payment application 61.

[0066] The registration URL is used in the activation process (see FIG. 5) to register the store terminal 20 with the second-class payment server 82 used for electronic payment means using the payment web API. The registration URL includes the global IP address and path of the second-class payment server 82. The second-class payment server 82 returns data indicated by the path to the store terminal 20 accessed using the registration URL.

[0067] The payment URL includes the global IP address and path of the second-type payment server 82. The second-type payment server 82 returns the data indicated by the path to the store terminal 20 accessed using the payment URL. The path of the payment URL and the path of the registration URL are different. In other words, the store app 38 can obtain different data by changing the URL used to access the second-type payment server 82.

[0068] The registration URL and the payment URL are associated with one type-2 module 52. One type-2 module 52 accesses one type-2 payment server 82 via the browser 62 using one registration URL and one payment URL.

[0069] The registration table is registered and updated in accordance with instructions from the management server 40 in the confirmation process shown in Fig. 4. Details will be described later.

[0070] Although not shown in FIG. 1, the terminal memory 32 further stores various programs, such as application software for controlling the camera 35, application software for controlling the scanning device 36, and application software for reading codes.

[0071] 1, the terminal memory 32 stores information necessary for communication with the management server 40, such as the communication address of the management server 40. The terminal memory 32 stores a terminal ID, which is identification information that individually identifies each store terminal 20. The terminal ID may be a private IP address assigned to the store terminal 20.

[0072] The touch panel 33 has a display and a transparent film-like touch sensor overlaid on the display. The touch panel 33 displays a screen indicated by screen data input from the terminal controller 30. The touch panel 33 also inputs position data indicating the position on the display touched by a purchaser, store employee, etc. to the terminal controller 30. Based on the position data, the terminal controller 30 identifies the touched (selected) icon from among multiple icons displayed on the touch panel 33. The touch panel 33 corresponds to the "display" recited in the claims.

[0073] The first communication interface 34 is connected to a gateway device (not shown) such as a router. The store terminal 20 is connected to the Internet 19 via the first communication interface 34 and the gateway device. The store terminal 20 communicates with a first-type payment server 81 and a second-type payment server 82 via the Internet 19.

[0074] The first communication interface 34 includes a near field communication interface such as NFC (Near Field Communication). The store terminal 20 communicates with the purchaser terminal 70 via the first communication interface 34 and acquires personal information required for electronic payment.

[0075] The camera 35 is a so-called digital camera having multiple image sensors such as CCDs. The camera 35 captures an image and generates captured image data. For example, a purchaser displays a code on the touch panel 74 of the purchaser terminal 70 that can read personal information required for electronic payment. The personal information required for electronic payment includes, for example, a user ID, which is identification information used by the payment service provider to individually identify the contractor (purchaser), the contractor's name, and an authentication code such as a PIN. The purchaser points the touch panel 74 of the purchaser terminal 70 toward the lens of the camera 35 of the store terminal 20. The terminal controller 30 captures an image of the code displayed on the touch panel 74 of the purchaser terminal 70. The terminal controller 30 acquires the personal information from the code image data generated by capturing the image.

[0076] The camera 35 may also be used to acquire payment information. For example, an employee at a dry cleaner's or rental car store prints out a code that includes the amount to be paid by the purchaser, the name of the product or service, etc. After receiving the code from the employee, the purchaser goes to the location where the store terminal 20 is installed and operates the store terminal 20 to have the camera 35 capture an image of the received code. The terminal controller 30 of the store terminal 20 acquires payment information from the captured image data of the code.

[0077] The scanning device is a device that reads two-dimensional codes, such as a barcode reader. The terminal controller 30 of the store terminal 20 acquires payment information from the two-dimensional code read by the scanning device .

[0078] 1, the store terminal 20 is connected by wire or wirelessly to a POS device that handles cash and a printer that prints receipts and invoices. The store terminal 20 may be a POS device equipped with the printer.

[0079] [Administration Server 40]

[0080] The management server 40 is a so-called web server that publishes a communication address on the Internet 19. The management server 40 may be a single server, or may be a so-called cloud server consisting of multiple servers. The management server 40 may be a server owned by a service provider, or may be a so-called rental server that the service provider has the right to use.

[0081] The management server 40 includes a server controller 41 and a second communication interface 44. The second communication interface 44 is connected to the Internet 19 via a gateway device (not shown).

[0082] The server controller 41 includes a CPU 42 which is a central processing unit, and a server memory 43 .

[0083] The server memory 43 stores an OS 45, a server program 46, and a database. The OS 45 is an operating system.

[0084] The server program 46 is a program developed by the service provider and installed in the management server 40. The server program 46 is used to manage a plurality of store terminals 20.

[0085] The database includes a management database (see FIG. 2) and a correspondence table (see FIG. 3(A)). The management database and the correspondence table correspond to the "management database" set forth in the claims.

[0086] As shown in Figure 2, the management database has multiple columns named "Business ID," "Business Name," "Store ID," "Store Name," "Terminal ID," "Contract Payment Method," and "Agent Payment Method."

[0087] The business ID is registered in the field of the column named “Business ID.” The business ID is identification information that individually identifies a commercial business.

[0088] The names of commercial businesses are registered in the field of the column labeled "Business Name." In the example shown in Figure 2, "Yamada Rent-a-Car," "Tanaka Craning," and "Super Suzuki" are registered.

[0089] The store ID is registered in the field of the column named "Store ID." The store ID is identification information that identifies each store owned by a commercial business. The store name is registered in the field of the column named "Store Name."

[0090] The terminal ID is registered in a field in a column named “Terminal ID.” The terminal ID is identification information that individually identifies the store terminal 20.

[0091] Each record (row) in the management database is individually identified by the business ID, store ID, and terminal ID.

[0092] The column named "Contract Payment Method" has multiple sub-columns. Payment method numbers are assigned to the sub-columns. The payment method numbers are "A01," "A02," "A03," etc. Each of these multiple sub-columns has two further sub-columns. One of the two sub-columns is named "Contract Flag," and the other is named "Activation Flag."

[0093] The contract flag is registered in the field of the subcolumn named "Contract Flag". The contract flag is a value of "0" or "1". A contract flag of "0" indicates that the commercial business has not concluded a contract with the payment service provider that provides the electronic payment method indicated by "A01" etc. A contract flag of "1" indicates that the commercial business has concluded a contract with the payment service provider.

[0094] The activation flag is registered in the field of the subcolumn named "Activation Flag." The activation flag is a value of "0" or "1." An activation flag of "1" indicates that the electronic payment means indicated by "A01" or the like is activated and electronic payments can be made using that electronic payment means. An activation flag of "0" indicates that the electronic payment means is not activated and electronic payments cannot be made using that electronic payment means. In the example shown in Figure 2, "Tanaka Dry Cleaning" has entered into a contract with a payment service provider that provides the electronic payment means indicated by "A01," but that payment means has not yet been activated, indicating that electronic payments cannot be made using that payment means. In addition, "Tanaka Dry Cleaning" has entered into a contract with a payment service provider that provides the electronic payment means indicated by "A03," and that payment means is activated, indicating that electronic payments can be made using that payment means.

[0095] The column named "Substitute Payment Method" has multiple sub-columns. Payment method numbers are assigned to the sub-columns. The payment method numbers are "A01," "A02," "A03," etc. Each of these multiple sub-columns has two further sub-columns. One of the two sub-columns is named "Contract Flag," and the other is named "Activation Flag."

[0096] The contract flag is registered in the field of the subcolumn named "Contract Flag." The contract flag can be either "0" or "1." A contract flag of "0" indicates that the service provider has not concluded a contract with a commercial business to make electronic payments on behalf of the commercial business using electronic payment instruments indicated by "A01," "A02," "A03," etc. A contract flag of "1" indicates that the service provider has concluded a contract with the commercial business to make electronic payments on behalf of the commercial business using electronic payment instruments indicated by "A01," "A02," "A03," etc. In other words, a commercial business can use electronic payments using an electronic payment instrument by concluding a contract with the service provider, even if the commercial business does not have a contract with the payment service provider for that electronic payment instrument.

[0097] The activation flag is registered in the field of the sub-column named "Activation Flag." The activation flag has a value of "0" or "1."

[0098] In this way, a contract flag indicating whether or not there is a contract for each electronic payment method at each store of the commercial business and each store terminal 20, and an activation flag indicating whether or not it is available for use are registered in the management database.

[0099] In the example shown in Figure 2, a contract flag of "1" is registered in association with "A01" in the "contract payment means" for each record identified by the business ID "ABC01," a contract flag of "0" is registered in association with "A02" and "A03," a contract flag of "0" is registered in association with "agent payment means" for "A01" and "A03," and a second contract flag of "1" is registered in association with "A02." In other words, it is registered in the management database that the commercial business indicated by the business name "Yamada Rent-A-Car" can make payments using the electronic payment means indicated by "A01" and "A02," but cannot make payments using the electronic payment means indicated by "A03."

[0100] The contract flag and activation flag are registered for each commercial business, each store, and each store terminal 20. In other words, usable electronic payment methods can be registered for each commercial business, each store, and each store terminal 20. In other words, usable electronic payment methods can be registered in the management database for each store and each store terminal 20. However, the contract flag may also be registered for each commercial business, or for each commercial business and store.

[0101] Information is registered in the management database by the service provider. When the service provider concludes a contract with a new commercial business, it creates a new record in the management database and registers the commercial business's name and business ID in the management database. The service provider obtains information about the commercial business's store and store terminal 20, as well as information about the contracted payment business, from the commercial business, and based on the obtained information, registers the store ID, store name, terminal ID, and the contract flag and activation flag of the contracted payment method in the management database. In addition, the service provider concludes a contract with the commercial business regarding an electronic payment method and registers the contract flag and activation flag of the agent payment method in the management database.

[0102] The correspondence table shown in FIG. 3(A) is a table that associates information related to payment method numbers, payment service providers, payment applications, and modules.

[0103] The correspondence table has multiple columns labeled "payment method number," "payment provider," "payment application," and "module."

[0104] The payment method number is registered in the field of the column named "Payment Method Number." Payment method numbers are "A01," "A02," "A03," etc.

[0105] The field of the column named "Payment Provider" further includes two sub-columns. One of the two sub-columns is named "Payment Provider Name" and the other is named "Payment Provider ID." The name of the payment provider is registered in the field of the sub-column named "Payment Provider Name." The payment provider ID is registered in the field of the sub-column named "Payment Provider ID." The payment provider ID is identification information that individually identifies a payment provider.

[0106] The column named "Payment App" further includes two sub-columns. One of the two sub-columns is named "App ID," and the other is named "Version Information." The app ID is registered in a field of the sub-column named "App ID." The app ID is identification information that individually identifies each payment app 61, such as "T01" or "T02." Version information is registered in a field of the sub-column named "Version Information." The version information indicates the version of the payment app 61.

[0107] The column named "Module" has two sub-columns. One of the two sub-columns is named "Module ID" and the other is named "Version Information." The module ID is registered in the field of the sub-column named "Module ID." The module ID is identification information that individually identifies each module, such as "R01" or "R02." The version information is registered in the field of the sub-column named "Version Information." The version information indicates the versions of the first type module 51 and the second type module 52.

[0108] The purchaser terminal 70 shown in FIG. 1 is a communication terminal that can be carried by the purchaser, such as a smartphone, a smartwatch, or a tablet.

[0109] The purchaser terminal 70 comprises a terminal controller 71, a touch panel 74, a communication interface 75, and a camera 76. The terminal controller 71 has a CPU 72, which is a central processing unit, and a memory 73. The memory 73 stores an OS, a payment application, and personal information. The personal information includes user ID, name, account number, and other information required for electronic payment. The touch panel 74 has a display and a transparent membrane-like touch sensor overlaid on the display. The communication interface 75 includes a communication module that connects to the Internet 19 via, for example, a mobile communication network, and another communication module that connects to the Internet 19 via an access point and a LAN.

[0110] The first-class payment server 81 is a web server operated by a payment service provider that provides the payment app 61. Although not shown in FIG. 1, there are multiple first-class payment servers 81. The second-class payment server 82 is a web server that provides a payment web API to the accessed store terminal 20 to perform electronic payment. Although not shown in FIG. 1, there are multiple second-class payment servers 82.

[0111] [Operation of payment support system 10]

[0112] 1 will be described below. The process that the store app 38 of the store terminal 20 causes the CPU 31 to execute, and the process that the server program 46 of the management server 40 causes the CPU 42 to execute will be described below. The process that the store app 38 causes the CPU 31 to execute will also be the process executed by the store app 38, the CPU 31, the terminal controller 30, and the store terminal 20. The process that the server program 46 causes the CPU 42 to execute will also be the process executed by the server program 46, the CPU 42, the server controller 41, and the management server 40.

[0113] [Registration process]

[0114] 4 is a flowchart of a registration process that the store application 38 and the server program 46 of the management server 40 cause the CPUs 31 and 42 to execute when the store terminal 20 is started. FIG. 5 is a flowchart of an activation process that the store application 38 causes the CPU 31 to execute.

[0115] An employee working at a store of a commercial business or an employee of a service provider operates the store terminal 20 and inputs a start-up instruction to start the store app 38 into the store terminal 20 (S11). The started store app 38 determines whether the above registration information is stored in the terminal memory 32 (see FIG. 1) (S12). That is, in step S12, it is determined whether the store app 38 has already been initialized.

[0116] If the store app 38 determines that the registration information is not stored in the terminal memory 32 (see FIG. 1) (S12: No), it displays an initial setting screen on the touch panel 33 (see FIG. 1) (S13). The initial setting screen includes text boxes for receiving input of notification information including the business name, business ID, and terminal ID. An employee of the service provider inputs the notification information on the initial setting screen (S14). The store app 38 generates an HTTP request including the notification information and a setting request (S15). The setting request is, for example, a command. The store app 38 transmits the generated HTTP request to the management server 40 via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S16). The processing of step S16 corresponds to "a processing of transmitting a request including the business ID to the management server via the first communication interface and the Internet" as recited in the claims.

[0117] The management server 40 receives an HTTP request including the notification information and a setting request via the second communication interface 44 (see FIG. 1) (S16). The server program 46 of the management server 40 identifies a record in the management database (see FIG. 2) that has a provider ID, provider name, and terminal ID that match the provider ID, provider name, and terminal ID included in the notification information. The server program 46 associates the information registered in the identified record with the names assigned to each column and reads it out from the management database as read information (S17). The server program 46 also identifies a record in the correspondence table (see FIG. 3(A)) that has a payment method number that matches the payment method number associated with the activation flag of "1" in the identified record. The server program 46 reads out information such as the app ID and module ID registered in the identified record as read information, associating it with the names assigned to each column. The server program 46 generates an HTTP response including the read information (S18). The server program 46 returns the HTTP response to the store terminal 20 via the second communication interface 44 and the Internet 19 (see FIG. 1) as a response to the HTTP request received in step S16 (S19). The processing of step S19 corresponds to "processing of returning a response including the received business ID and the module ID associated in the management database to the store terminal via the second communication interface and the Internet" as recited in the claims.

[0118] The store terminal 20 receives the HTTP response including the read information via the first communication interface 34 (see FIG. 1) (S19). The store application 38 of the store terminal 20 stores the read information in the terminal memory 32 (see FIG. 1) (S20). That is, the store application 38 registers the read information returned by the management server 40 in a registration table (see FIG. 3(B)).

[0119] Next, the store application 38 executes an activation process (S21). The activation process is a process for registering the store terminal 20 with the first-type payment server 81 and the second-type payment server 82, and enabling electronic payment.

[0120] As shown in FIG. 5, in the activation process, the main module 50 of the store app 38 acquires the business ID, terminal ID, communication address, app ID, module ID, authentication information, etc. registered in the registration table (see FIG. 3(B)) in the terminal memory 32 (see FIG. 1) (S41).

[0121] The application ID is the application ID of the payment application 61 associated with the contract flag of "1." The module ID is the module ID of the first type module 51 associated in the registration table with the payment application 61 associated with the contract flag of "1."

[0122] The communication address is the communication address of the first type payment server 81 specified by the payment application 61 associated with the contract flag of "1". The communication address is included in the payment application 61. The communication address may be stored in the terminal memory 32 (see FIG. 1) separately from the payment application 61.

[0123] The authentication information is a password, a PIN, or the like, and is entered into the store terminal 20 by, for example, an employee of the service provider. Note that obtaining the business ID, terminal ID, communication address, authentication information, and the like means obtaining a path indicating the storage area in which these are stored.

[0124] The main body module 50 passes a first activation request including a path indicating the provider ID, terminal ID, communication address, authentication information, etc. to the type 1 module 51 indicated by the module ID acquired in step S41 (S42). For example, if the type 1 module 51 is a function, the main body module 50 calls the function indicated by the module ID and passes the above path as an argument to the called function. If the type 1 module 51 is a class, the main body module 50 inputs the above path into the class indicated by the module ID to generate an instance. If the type 1 module 51 is an independent program separate from the main body module 50, the main body module 50 inputs a command including its own program ID, which is the source of the module, the program ID (module ID) of the type 1 module 51, which is the destination of the module, and the above path, to the OS 37 (see FIG. 1). The OS 37 starts the type 1 module 51 indicated by the module ID in accordance with the command and passes the above path to the started type 1 module 51. The process of step S42 corresponds to the "process of inputting an activation instruction to the first type module and the second type module" described in the claims. The program ID of each application software or module is registered in the library of OS 37 at the time of installation (setup).

[0125] Upon receiving the first activation request, the first-type module 51 launches the corresponding payment application 61 and passes a path indicating the provider ID, terminal ID, communication address, authentication information, etc., and the second activation request to the launched payment application 61 (S43). Specifically, the first-type module 51 inputs a command to the OS 37 (see FIG. 1) including its own program ID, which is the launch source, the program ID (application ID) of the payment application 61, which is the launch destination, and the path. In accordance with the input command, the OS 37 launches the payment application 61 indicated by the application ID and passes the path to the launched payment application 61. The processing of step S43 corresponds to "a processing of launching the corresponding payment business application software and passing predetermined first setting information" as recited in the claims. The provider ID, terminal ID, and authentication information correspond to "predetermined first setting information" as recited in the claims.

[0126] The activated payment application 61 sends an HTTP request including a third activation request to the first type payment server 81 determined by the communication address indicated by the passed path via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S44). The third activation request is a command including, for example, the business operator ID, the terminal ID, and authentication information.

[0127] The first-class payment server 81 receives the HTTP request including the third activation request (S44). The controller (not shown) of the first-class payment server 81 executes a registration process to store the business operator ID and terminal ID included in the received third activation request in memory (S45). When the controller of the first-class payment server 81 receives a request for electronic payment, it performs the electronic payment based on the fact that the request has the same business operator ID and terminal ID as the registered business operator ID and terminal ID. In other words, by registering the business operator ID and terminal ID in the first-class payment server 81, the payment app 61 becomes available for use in the store terminal 20. In this way, the payment app 61 is activated.

[0128] The controller of the first type settlement server 81 returns an HTTP response including a registration completion notification to the shop terminal 20 as a response to the HTTP request received in step S44 (S46).

[0129] The store terminal 20 receives the returned HTTP response through the first communication interface 34 (see FIG. 1) (S46). The payment application 61 of the store terminal 20 passes a path indicating the area where the registration completion notice included in the received HTTP response is stored to the first-type module 51 through the OS 37 (see FIG. 1) (S47). The first-type module 51 passes the path to the main module 50 (S48). For example, the main module 50 obtains the path as a return value of the argument passed to the above-mentioned function of the first-type module 51. Based on receiving the registration completion notice indicated by the path, the main module 50 changes the value of the activation flag registered in the registration table from "0" to "1" (S49). The module ID of the first-type module 51 associated with the activation flag of "1" corresponds to the "registration ID" described in the claims.

[0130] Main body module 50 executes the processes from step S41 to step S49 for all payment applications 61 associated with a contract flag of "1" and associated with an activation flag of "0".

[0131] Since the store application 38 has a plurality of first-type modules 51 corresponding to each payment application 61, each payment application 61 can be appropriately validated.

[0132] Furthermore, the main module 50 acquires the provider ID, terminal ID, registration URL, module ID, authentication information, etc. stored in the terminal memory 32 (see FIG. 1) (S51). Specifically, the main module 50 acquires a path indicating a storage area in which the provider ID, terminal ID, registration URL, module ID, authentication information, etc. are stored.

[0133] The main body module 50 passes a fourth activation request including the path to the second type module 52 indicated by the module ID acquired in step S51 (S52). The process of step S52 is executed in the same manner as the process of step S42. The process of step S52 corresponds to "the process of inputting an activation instruction to the first type module and the second type module" recited in the claims.

[0134] The second-type module 52, which has received the fourth activation request, starts the browser 62 through the OS 37 (see FIG. 1 ) and passes a fifth activation request including the registration URL to the started browser 62 (S53). Specifically, the second-type module 52 inputs a command to the OS 37 including its own program ID, which is the program source from which the module 52 is started, the program ID of the browser 62, which is the destination of the start, and a path indicating the registration URL. The OS 37 starts the browser 62 in accordance with the input command and passes the path to the started browser 62. The processing of step S53 corresponds to "a processing of starting the browser and passing the communication address stored in the terminal memory to the started browser" as recited in the claims. The registration URL corresponds to "a communication address" as recited in the claims.

[0135] The browser 62 transmits an HTTP request indicating a data request to the second type settlement server 82 indicated by the registration URL via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S54).

[0136] The second type payment server 82 returns an HTTP response including the second data to the store terminal 20 via the Internet 19 (see FIG. 1) as a response to the HTTP request received in step S54 (S55). The second data includes JavaScript and HTML data. The JavaScript is a program executed by the browser 62. The JavaScript has format data for accepting input of registration information and a UL (Upload) communication address. The format data has input fields associated with each piece of registration information, such as a business ID and a terminal ID. The UL communication address has the global IP address and path of the second type payment server 82. However, the UL communication address may have the global IP address of an UP server other than the second type payment server 82. In this case, the second type payment server 82 downloads data from the UP server at any timing.

[0137] The store terminal 20 (browser 62) receives the HTTP response returned by the second type payment server 82 via the first communication interface 34 (see FIG. 1) (S55) and stores it in the terminal memory 32 (see FIG. 1) (S56). In accordance with the fifth activation request received in step S53, the browser 62 passes a path indicating the second data included in the received HTTP response to the second type module 52 via the OS 37 (see FIG. 1) (S57).

[0138] The second type module 52 acquires a path indicating the second data from the browser 62 via the OS 37 (see FIG. 1) (S57). The processing of step S57 corresponds to "processing in which the browser acquires, via the browser, the second data acquired from the payment server indicated by the communication address" as recited in the claims.

[0139] The second type module 52 generates UL data based on the received JavaScript and the registration information, such as the operator ID and terminal ID, acquired in step S51 (S58). For example, the second type module 52 generates UL data by inputting the operator ID and terminal ID into an input field of the JavaScript format data. The processing of step S58 corresponds to "processing for generating setting registration information based on the acquired second data and predetermined second setting information" as recited in the claims. The registration information, such as the operator ID and terminal ID, acquired in step S51 corresponds to "predetermined second setting information" as recited in the claims. The UL data corresponds to "setting registration information" as recited in the claims.

[0140] The second type module 52 passes the generated UL data and UL communication address to the browser 62 via the OS 37 (see FIG. 1) (S59). Specifically, the second type module 52 inputs a command to the OS 37, including its own program ID as the launch source and the program ID of the browser 62 as the launch destination, the UL data, and a path indicating the UP communication address. In accordance with the input command, the OS 37 passes the UL data and the path indicating the UP communication address to the launched browser 62.

[0141] Because there is a one-to-one correspondence between the second-type modules 52 and the second-type payment servers 82, the store app 38 can generate UL data that can be provided to the second-type payment server 82, regardless of the format of the data provided by the second-type payment server 82. In other words, by having multiple first-type modules 51 and multiple second-type modules 52, the store app 38 can use any electronic payment means, including electronic payment means provided by various payment apps 61 and electronic payment means provided by various payment web APIs.

[0142] The browser 62 transmits an HTTP request including the UL data to the second type payment server 82 indicated by the UP communication address via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S60). The processing of steps S59 and S60 corresponds to "processing of transmitting the setting registration information to the payment server via the browser" recited in the claims.

[0143] In the present embodiment, an example has been described in which the store application 38 receives the UP communication address from the second type payment server 82. However, the UP communication address may be stored in advance in the terminal memory 32 (see FIG. 1).

[0144] The second type payment server 82 receives the HTTP request including the UL data (S60). The second type payment server 82 registers the business operator ID and terminal ID included in the UL data in a predetermined management database as the terminal making the electronic payment request (S61). The second type payment server 82 returns an HTTP response including a registration completion notification to the store terminal 20 via the Internet 19 (see FIG. 1) as a response to the HTTP request received in step S60 (S62).

[0145] The store terminal 20 (browser 62) receives the HTTP response sent back by the second-type payment server 82 via the first communication interface 34 (see FIG. 1) (S62). The browser 62 passes the path in which the registration completion notification is stored to the second-type module 52 via the OS 37 (see FIG. 1) (S63). The second-type module 52 passes the path to the main module 50 (S64).

[0146] For example, the main body module 50 obtains the path as a return value of an argument passed to the above function, which is the second type module 52. The main body module 50 may receive the path from the second type module 52 via the OS 37 (see FIG. 1). Upon receiving the registration completion notification indicated by the path, the main body module 50 changes the value of the activation flag registered in the registration table from "0" to "1" (S65). The module ID of the second type module 52 associated with the activation flag of "1" corresponds to the "registration ID" set forth in the claims.

[0147] The main body module 50 executes the processes from step S51 to step S65 for all second type modules 52 that are associated with a contract flag of "1" and an activation flag of "0".

[0148] As shown in FIG. 4, when the main module 50 of the store app 38 determines in step S12 that registration information exists (S12: Yes), it reads out the registration information stored in the terminal memory 32 (see FIG. 1) (S22). The main module 50 generates an HTTP request including the read registration information and a registration confirmation request (S23). The registration confirmation request is, for example, a command. The main module 50 transmits the HTTP request including the registration information and the registration confirmation information to the management server 40 via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S24). The processing of step S24 corresponds to "a processing of transmitting a request including the registration ID and the business ID to the management server via the first communication interface and the Internet" as recited in the claims. The module ID included in the registration information and associated with an activation flag of "1" corresponds to the "registration ID" as recited in the claims.

[0149] The management server 40 receives an HTTP request including the registration information and a registration confirmation request via the second communication interface 44 (see FIG. 1) (S24). The server program 46 of the management server 40 identifies a record in the management database that has an operator ID that is the same as the operator ID that is the received registration information (S25). The server program 46 reads out the information registered in the identified record as setting information (S25). The server program 46 determines whether the read setting information matches the registration information received in step S24 (S26). For example, if a commercial business enters into a contract with a new payment service provider, the registration information registered in the store terminal 20 will no longer match the setting information registered in the management database of the management server 40. The processing of step S26 corresponds to the "determination processing" set forth in the claims.

[0150] If the server program 46 determines that there is a match (S26: Yes), it generates an HTTP response including a match flag of "0" (S27). If the server program 46 determines that there is no match (S26: No), it generates an HTTP response including a match flag of "1" and the read setting information (S28). The server program 46 returns the generated HTTP response to the store terminal 20 via the second communication interface 44 (see FIG. 1) and the Internet 19 (see FIG. 1) as a response to the HTTP request received in step S24 (S29). The processing of step S29 corresponds to the "reply processing" recited in the claims. The match flag and the setting information recited in the claims correspond to the "determination result" recited in the claims.

[0151] The store terminal 20 receives the HTTP response returned by the management server 40 via the first communication interface 34 (see FIG. 1) (S29). The store app 38 of the store terminal 20 determines whether the value of the match flag included in the received HTTP response is “0” or “1” (S30). If the server program 46 determines that the value of the match flag is “1” (S30: “1”), it stores the setting information included in the HTTP response as registration information in the terminal memory 32 (see FIG. 1) (S31). In addition, the server program 46 executes the validation process of step S21. If the server program 46 determines that the value of the match flag is “0” (S30: “0”), it skips the processes of steps S31 and S21 and ends the registration process (END). The validation process of step S21, which is executed when it is determined that there is no match in step S30, corresponds to “causing the terminal computer to re-execute the validation process based on the reception of the determination result indicating there is no match” as set forth in the claims.

[0152] [Electronic payment processing]

[0153] Fig. 6 is a flowchart showing the processing executed by the store application 38 and the first type payment server 81 when electronic payment is made by the payment application 61 provided by the first type payment server 81. Fig. 10(A) is a diagram showing a payment method selection screen displayed on the store terminal 20, and Fig. 10(B) is a diagram showing an instruction screen displayed on the store terminal 20. Fig. 11 is a diagram showing a payment completion screen.

[0154] Referring to FIG. 6, electronic payment through the first type module 51 and the payment application 61 will be described.

[0155] A purchaser purchases a product offered by a commercial business in a store. The purchaser may also receive a commercial service offered by the commercial business. The store terminal 20 acquires payment information and stores it in the terminal memory 32 (see FIG. 1) (S71). The payment information includes the name of the product or service and the price. For example, the store terminal 20 acquires payment information from a barcode read by the scanning device 36 (see FIG. 1). The store terminal 20 may also acquire payment information from image data generated by the camera 35 (see FIG. 1) by capturing an image of a code indicating the payment information. The store terminal 20 may also wirelessly communicate with a communication terminal carried by a store employee and acquire payment information from the communication terminal. The processing in step S71 corresponds to the "process of acquiring payment information" set forth in the claims.

[0156] The main module 50 of the store app 38 determines whether or not the payment information has been acquired (S72). The main module 50 waits until the payment information has been acquired (S72: No). If the main module 50 determines that the payment information has been acquired (S72: Yes), it displays a payment details confirmation screen (not shown) on the touch panel 33 (see FIG. 1) (S73).

[0157] The payment details confirmation screen includes, for example, the product name or service name, unit price, date and time, store name, total amount (price), and an "OK" icon. The purchaser selects the "OK" icon on the payment details confirmation screen (S74).

[0158] Upon receiving the selection of the "OK" icon by the purchaser (S74), the main module 50 of the store application 38 displays a payment method selection screen on the touch panel 33 (see FIG. 1) (S75).

[0159] As shown in Figure 10(A), the payment method selection screen has a "Cash" icon 91, an "Electronic Payment Method A" icon 92, an "Electronic Payment Method B" icon 93, an "Electronic Payment Method C" icon 94, an "Electronic Payment Method D" icon 95, an "Electronic Payment Method E" icon 96, an "Electronic Payment Method F" icon 97, and an "Electronic Payment Method G" icon 98. The electronic payment methods displayed on the payment method selection screen are those indicated by the payment method numbers associated with the contract flag and activation flag of "1" in the registration table (see Figure 3(B)). In other words, the electronic payment methods displayed on the payment method selection screen are only those that have been contracted with a commercial business and have already been activated and are available for use.

[0160] The purchaser selects the icon that indicates the electronic payment method provided by the payment service provider with which the purchaser has a contract, for example, from among ``Electronic Payment Method A'' icon 92, ``Electronic Payment Method B'' icon 93, ``Electronic Payment Method C'' icon 94, ``Electronic Payment Method D'' icon 95, ``Electronic Payment Method E'' icon 96, ``Electronic Payment Method F'' icon 97, and ``Electronic Payment Method G'' icon 98.

[0161] As shown in FIG. 6, the main module 50 of the store app 38 accepts the selection of the icon (S76). The following describes the case where the purchaser selects an icon other than the "cash" icon 91 that indicates electronic payment using the payment app 61. If the purchaser selects the "cash" icon 91, the main module 50 accepts payment by cash. The case where the purchaser selects the icon that indicates electronic payment using a payment web API will be described later. The processing of step S76 corresponds to the "processing of accepting selection of payment method" set forth in the claims.

[0162] The main module 50 acquires the module ID of the first-type module 51 associated with the electronic payment method (payment method number) indicated by the icon selected by the purchaser from the registration table (see FIG. 3(B)) (S77). The main module 50 activates the first-type module 51 indicated by the acquired module ID and passes the business operator ID and terminal ID stored in the terminal memory 32 (see FIG. 1) and the settlement information acquired in step S71 (S78). For example, the main module 50 calls a function (first-type module 51) indicated by the acquired module ID and passes the business operator ID, terminal ID, and path indicating the settlement information to the function as arguments. The processing of step S78 corresponds to the "module selection processing" recited in the claims. The activated first-type module 51 corresponds to the "corresponding module" recited in the claims.

[0163] The launched type 1 module 51 generates a launch instruction including a business operator ID, a terminal ID, and settlement information (S79). The launch instruction is, for example, a command including a path indicating the business operator ID, the terminal ID, the settlement information, and the application ID. The type 1 module 51 inputs the launch instruction to the OS 37 (see FIG. 1), launches the payment application 61 indicated by the application ID via the OS 37, and passes the business operator ID, the terminal ID, and the path indicating the settlement information (S80). The processing of step S80 corresponds to "processing for passing the settlement information to the launched payment business operator application software" as recited in the claims.

[0164] The payment application 61 generates an HTTP request including a first payment request having a business operator ID, a terminal ID, and settlement information (S81). The first payment request is, for example, a command. The payment application 61 sends the generated HTTP request to the first-class payment server 81 via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S82).

[0165] The first-class payment server 81 receives an HTTP request including a first payment request having a business operator ID, a terminal ID, and settlement information (S82). The first-class payment server 81 stores the received business operator ID, terminal ID, and settlement information in memory (not shown) along with a payment request number (S83). The first-class payment server 81 also generates reply data based on the received first payment request (S84). The reply data includes JavaScript and HTML data. The JavaScript includes format data for accepting input of the purchaser's (payer's) personal information. The format data has input fields for entering a user name, which is the name of the contractor who has concluded the electronic payment, a user ID, which is identification information, and a password, as well as the above-mentioned payment request number. The HTML data is screen data for displaying an instruction screen (see FIG. 10(B)).

[0166] The first type settlement server 81 returns an HTTP response including the reply data to the shop terminal 20 via the Internet 19 (see FIG. 1) as a response to the HTTP request received in step S82 (S85).

[0167] The store terminal 20 (payment application 61) receives the HTTP response including the reply data via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S85). The payment application 61 displays an instruction screen indicated by the HTML data included in the reply data on the touch panel 33 (see FIG. 1) (S86).

[0168] FIG. 10(B) shows the instruction screen. The instruction screen has at least one of the following strings: "Near Field Communication: Hold the Terminal," "Point the Payment QR Code to the Camera," "Point the Credit Card," and "Point the IC Card." The string that appears on the instruction screen depends on the electronic payment method selected by the purchaser. For example, if the electronic payment method selected by the purchaser is mobile payment using NFC, the instruction screen has the string "Near Field Communication: Hold the Terminal." If the electronic payment method selected by the purchaser is so-called QR code payment, the instruction screen has the string "Point the Payment QR Code to the Camera." If the electronic payment method selected by the purchaser is electronic payment using a credit card with an IC chip, the instruction screen has the string "Point the Credit Card." If the electronic payment method selected by the purchaser is electronic payment using an IC card such as "Suica," the instruction screen has the string "Point the IC Card."

[0169] The purchaser follows the instructions on the instruction screen and holds the purchaser terminal 70 over the store terminal 20. Following the instructions on the instruction screen, the purchaser displays the payment code on the purchaser terminal 70 and causes the camera 35 (see FIG. 1) of the store terminal 20 to capture an image of the code. Following the instructions on the instruction screen, the purchaser holds their credit card over the store terminal 20. Following the instructions on the instruction screen, the purchaser holds their IC card over the store terminal 20.

[0170] As shown in FIG. 6, the payment application 61 of the store terminal 20 acquires personal information necessary for electronic payment (S87). For example, the payment application 61 requests the OS 37 (see FIG. 1) to perform near-field communication with the purchaser terminal 70 via the first communication interface 34 (see FIG. 1). The OS 37 performs near-field communication with the purchaser terminal 70 to acquire the purchaser's personal information necessary for electronic payment and stores it in the terminal memory 32 (see FIG. 1). The OS 37 returns a path indicating the personal information to the payment application 61 in response to the request. Alternatively, the payment application 61 requests the OS 37 to capture an image of the payment code using the camera 35 (see FIG. 1). The OS 37 launches a code reading application (not shown). The launched code reading application launches a camera application via the OS 37. The launched camera application drives the camera 35 to capture an image of the payment code. Code image data generated by the image capture is stored in the terminal memory 32. A path indicating the code image data is passed to the code reading application via the camera application. The code reading application reads the purchaser's personal information from the passed code image data and stores it in the terminal memory 32. The OS37 returns the path indicating the personal information to the payment application 61 as a response to the request. The payment application 61 may request the OS37 to perform near-field wireless communication with a credit card via the first communication interface 34. The OS37 performs near-field wireless communication with the credit card to obtain the purchaser's personal information required for electronic payment and stores it in the terminal memory 32. The OS37 returns the path indicating the personal information to the payment application 61 as a response to the request.

[0171] The payment application 61 generates a second payment request including the acquired personal information (S87). The second payment request is, for example, a command including format data into which the personal information has been input. The format data is included in the reply data received in step S85. The payment application 61 sends an HTTP request including the second payment request to the first type payment server 81 via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S88).

[0172] The first-class payment server 81 receives the HTTP request including the second payment request (S88). The first-class payment server 81 executes the payment process in accordance with the received second payment request (S89). Specifically, the first-class payment server 81 executes the payment process based on the business operator ID, terminal ID, and settlement information stored in memory (not shown) in association with the payment request number in step S83, and the payment request number and personal information contained in the input format data received in step S88. For example, in the case of a bank account withdrawal, the first-class payment server 81 withdraws the payment from the purchaser's bank account and transfers the payment to the account of the commercial business. Alternatively, in the case of a credit card payment, the first-class payment server 81 transfers the payment to the account of the commercial business on behalf of the purchaser. Alternatively, in the case of electronic money, the first-class payment server 81 transfers the payment to the account of the commercial business using electronic money held by the purchaser.

[0173] Based on the completion of electronic payment (S89), the first type payment server 81 returns an HTTP response including payment completion information to the store terminal 20 via the Internet 19 (see Figure 1) in response to the HTTP request received in step S88 (S90).

[0174] The payment application 61 of the store terminal 20 receives an HTTP response including payment completion information via the first communication interface 34 (see FIG. 1) (S90). The payment application 61 stores the payment completion information in the terminal memory 32 (see FIG. 1) (S91) and passes a path indicating the payment completion information to the type 1 module 51 via the OS 37 (see FIG. 1) (S92). Specifically, the OS 37 passes the path passed from the payment application 61 to the type 1 module 51 that launched it.

[0175] The first type module 51 acquires a path indicating the payment completion information from the payment application 61 via the OS 37 (see FIG. 1) (S92). The processing of step S92 corresponds to the "process of acquiring the payment completion information via the payment business application software" described in the claims.

[0176] The first type module 51 passes the received path to the main module 50 (S93). For example, the first type module 51, which is a function, passes a path indicating payment completion information to the main module 50 as a return value for the settlement information or the like passed as an argument.

[0177] The main module 50 acquires a path indicating the payment completion information from the first type module 51 (S93). The processing of step S93 corresponds to "processing of acquiring the payment completion information from the first type module and the second type module" recited in the claims.

[0178] The main module 50 generates payment completion notification screen data based on the acquired payment completion information (S94). The main module 50 inputs the payment completion notification screen data to the touch panel 33 (see FIG. 1) and causes the touch panel 33 to display a payment completion notification screen indicated by the payment completion notification screen data (S95). The processing of step S94 corresponds to the "processing of generating payment completion notification screen data" recited in the claims. The processing of step S95 corresponds to the "processing of displaying a payment completion notification screen on the display" recited in the claims.

[0179] FIG. 11(A) shows the payment completion notification screen. The payment completion notification screen displays the text "Tanaka Cleaning," indicating the name of the commercial business; the text "Konohana Ward Store," indicating the store name; the text "Sunday, June 1, 2025, 1:05 PM," indicating the purchase date and time; and the text "5,300 yen," indicating the total payment amount. The payment completion notification screen also displays the text "Item Name: Suit Dry Cleaning" and "Item Name: Shirt Dry Cleaning," indicating the commercial service name, and the text "Amount: 680 yen" and "Amount: 480 yen," indicating the unit price. The payment completion notification screen also displays the letter "A," indicating the electronic payment method used for the electronic payment. The payment completion notification screen also displays a "Receipt" icon 101 and a "Receipt" icon 102. The purchaser selects either the "Receipt" icon 101 or the "Receipt" icon 102.

[0180] 6, the main module 50 causes the printer to print a receipt or invoice corresponding to the icon selected by the purchaser on the payment completion notification screen (S96). The main module 50 repeatedly executes the processes from step S71 onwards until an instruction to end the transaction is input (S97: No), and ends the process (End) based on the input of an instruction to end the transaction (S97: Yes).

[0181] FIG. 7 shows a flowchart of the process executed by the store application 38 and the browser 62 when the purchaser selects an electronic payment method using the browser 62 and a payment web API.

[0182] As shown in Figure 7, the main module 50 of the store terminal 20 executes the processes from step S71 to step S76. In step S76, the purchaser selects an electronic payment method using the payment web API. The main module 50 obtains the module ID corresponding to the electronic payment method (payment method number) selected by the purchaser and the path indicating the payment URL from the registration table (see Figure 3(B)) (S77).

[0183] The main module 50 starts the second type module 52 indicated by the acquired module ID and passes the business operator ID, terminal ID, settlement information, and path indicating the payment URL (S101). For example, the main module 50 calls a function that is the second type module 52 and passes the business operator ID, terminal ID, and payment URL as arguments to the function (second type module 52). The started second type module 52 corresponds to the "corresponding module" described in the claims.

[0184] The second type module 52 starts the browser 62 via the OS 37 (see FIG. 1) and passes the payment URL to the browser 62 (S102). Specifically, the second type module 52 inputs a command to the OS 37 including its own program ID as the program source and the program ID of the browser 62 as the destination, and the payment URL. The OS 37 starts the browser 62 and passes the payment URL to the browser 62. The processing of step S102 corresponds to "processing of starting the browser and passing the communication address stored in the terminal memory to the started browser" as defined in the claims. The payment URL corresponds to "communication address" as defined in the claims.

[0185] The started browser 62 sends an HTTP request to the second type payment server 82 indicated by the payment URL via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S103).

[0186] Upon receiving the HTTP request (S103), the second-type payment server 82 returns an HTTP response including first data having HTML data and JavaScript to the store terminal 20 (S104). The JavaScript includes format data and a first communication address for UL. The format data has input fields for inputting the business ID, terminal ID, product name or commercial service name, unit price, and fee.

[0187] The store terminal 20 (browser 62) receives the HTTP response sent back by the second-type payment server 82 via the first communication interface 34 (see FIG. 1) (S104). The browser 62 stores the received first data in the terminal memory 32 (see FIG. 1) and passes a path indicating the first data to the second-type module 52 via the OS 37 (see FIG. 1) (S105). Specifically, the OS 37 passes the path passed from the launched browser 62 to the launching second-type module 52.

[0188] The second type module 52 acquires the first data from the browser 62 via the OS 37 (see FIG. 1) (S105). The process of step S105 corresponds to "processing of acquiring the first data from the browser" recited in the claims.

[0189] The second-type module 52 inputs the business operator ID, terminal ID, and settlement information acquired in step S101 into the format data contained in the JavaScript of the first data, and generates data to be provided to the second-type payment server 82 (S106). The process of step S106 corresponds to the "process of generating payment information" recited in the claims. The provided data corresponds to the "payment information" recited in the claims.

[0190] The second type module 52 passes the provided data and the first communication address for UL to the browser 62 via the OS 37 (see FIG. 1) (S107). Specifically, the second type module 52 inputs a command including its own program ID as the launch source and the program ID of the browser 62 as the launch destination, the provided data, and the first communication address for UL to the OS 37. The OS 37 launches the browser 62 and passes the provided data and the first communication address for UL to the browser 62.

[0191] The browser 62 transmits an HTTP request including the provided data to the second type payment server 82 indicated by the first communication address for UL via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S108). The processing of steps S107 and S108 corresponds to "processing of transmitting the payment information to the payment server via the browser" recited in the claims.

[0192] The second-type payment server 82 receives the HTTP request including the provided data (S108). A controller (not shown) of the second-type payment server 82 assigns a payment request number to the business operator ID, terminal ID, and settlement information included in the received provided data, and stores them in memory (not shown) (S109). In addition, the second-type payment server 82 returns an HTTP response including first reply data to the store terminal 20 in response to the HTTP request received in step S108 (S110). The first reply data includes HTML data and JavaScript. The JavaScript includes a UL communication address and format data. The format data includes an input field for accepting input of personal information required for electronic payment, and a payment request number.

[0193] The store terminal 20 receives the HTTP response including the first reply data via the first communication interface 34 (see FIG. 1) (S110). The browser 62 of the store terminal 20 displays an instruction screen indicated by the HTML data contained in the received first reply data on the touch panel 33 (see FIG. 1) (S111). The instruction screen is the same as the instruction screen shown in FIG. 10(B).

[0194] The purchaser follows the instructions on the instruction screen and holds the purchaser terminal 70, credit card, or IC card over the store terminal 20. The purchaser may display the payment code on the purchaser terminal 70 and have it captured by the camera 35 (see FIG. 1) of the store terminal 20.

[0195] The browser 62 of the store terminal 20 acquires personal information necessary for electronic payment (S112). The process of step S112 is performed in the same manner as the process of step S87. The browser 62 generates UL data based on the acquired personal information and the format data in accordance with the JavaScript contained in the received first reply data (S112). The browser 62 sends an HTTP request including the UP data to the second-type payment server 82 indicated by the communication address contained in the JavaScript via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) in accordance with the JavaScript (S113). In this way, the JavaScript that causes the second-type payment server 82 to activate the camera 35 (see FIG. 1), the camera app, the first communication interface 34, etc. through the browser 62 to generate UL data and upload the UL data to the second-type payment server 82 corresponds to the "payment web API" recited in the claims.

[0196] The second type payment server 82 receives the HTTP request including the UL data (S113). A controller (not shown) of the second type payment server 82 executes payment processing based on the business operator ID, terminal ID, settlement information, and payment request number stored in memory in step S109, and the personal information and payment request number included in the UL data received in step S113 (S114). After executing the payment processing (S114), the controller of the second type payment server 82 returns an HTTP response including payment completion information to the store terminal 20 as a response to the HTTP request received in step S113 (S115).

[0197] The store terminal 20 receives the HTTP response including the payment completion information through the first communication interface 34 (see FIG. 1) (S115). The browser 62 of the store terminal 20 stores the payment completion information in the terminal memory 32 (see FIG. 1) and passes a path indicating the payment completion information to the second-type module 52 through the OS 37 (see FIG. 1) (S116). Specifically, the OS 37 receives the path from the launched browser 62 and passes the path to the launched second-type module 52. The processing of step S116 corresponds to "processing to acquire payment completion information through the browser" recited in the claims.

[0198] The second type module 52 acquires a path indicating the payment completion information from the browser 62 via the OS 37 (see FIG. 1) (S116). The process of step S116 corresponds to the "process of acquiring the payment completion information through the browser" recited in the claims.

[0199] The second type module 52 passes the received path to the main module 50 (S117). For example, the main module 50 receives the path as a return value for an argument passed to the second type module 52, which is a function.

[0200] The main module 50 acquires a path indicating the payment completion information from the second type module 52 (S117). The process of step S117 corresponds to "processing of acquiring the payment completion information from the first module and the second type module" recited in the claims.

[0201] Having received the pass, the main module 50 generates payment completion notification screen data based on the payment completion information (S117). The main module 50 inputs the payment completion notification screen data into the touch panel 33 (see FIG. 1) and displays a payment completion notification screen on the touch panel 33 (S118). The processing of steps S117 and S118 is executed in the same manner as the processing of steps S94 and S95. Thereafter, the main module 50 executes the processing of steps S96 and S97 above and ends the processing (END).

[0202] FIG. 8 is a flowchart showing the process when personal information is sent from the purchaser terminal 70 to the first type settlement server 81 and electronic settlement is carried out.

[0203] As shown in FIG. 8, the main module 50 of the store app 38 executes the processes from step S71 to step S78. The process of step S78 launches the first-type module 51. The first-type module 51 launched in FIG. 8 is a module corresponding to the electronic payment method selected by the purchaser, and differs from the first-type module 51 launched in FIG. 6. Specifically, the first-type module 51 launched in FIG. 6 is a module in which the electronic payment method selected by the purchaser transmits the personal information to the first-type payment server 81 via the store terminal 20, while the first-type module 51 launched in FIG. 8 is a module in which the electronic payment method selected by the purchaser transmits the personal information from the purchaser terminal 70 to the first-type payment server 81.

[0204] The first-type module 51 started by the processing of step S78 generates a start instruction including a business operator ID, a terminal ID, and payment information (S111). The start instruction is, for example, a command including a path indicating the business operator ID, the terminal ID, the payment information, and the application ID. The first-type module 51 inputs the start instruction to the OS 37 (see FIG. 1), starts the payment application 61 indicated by the application ID via the OS 37, and passes the path indicating the business operator ID, the terminal ID, and the payment information (S112).

[0205] The payment application 61 generates an HTTP request including the business operator ID, the terminal ID, the settlement information, and a code request (S113). The code request is, for example, a command. The payment application 61 sends the generated HTTP request to the first type payment server 81 via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S114).

[0206] The first-class payment server 81 receives the HTTP request including the business operator ID, terminal ID, settlement information, and code request (S114). A controller (not shown) of the first-class payment server 81 assigns a payment request number to the received business operator ID, terminal ID, and settlement information, and stores them in memory (S115). The controller of the first-class payment server 81 generates code data from which the payment request number and its own communication address can be read (S116). The controller of the first-class payment server 81 returns an HTTP response including the code data to the store terminal 20 via the Internet 19 (see FIG. 1) as a response to the HTTP request received in step S114 (S117).

[0207] The store terminal 20 receives the HTTP response including the code data via the first communication interface 34 (see FIG. 1) (S117). The payment application 61 of the store terminal 20 causes the (QR) code image indicated by the received code data to be displayed on the touch panel 33 (see FIG. 1) via the OS 37 (see FIG. 1) (S118). Along with the code image, a message saying "Please capture the QR code with your camera" is also displayed on the touch panel 33.

[0208] The purchaser launches a user payment app (not shown) that corresponds to the electronic payment method selected in step S76 and is installed on the purchaser terminal 70 owned by the purchaser (S119). The purchaser operates the purchaser terminal 70 according to the instructions of the launched user payment app, causing the camera 76 (see FIG. 1) of the purchaser terminal 70 to capture an image of the code. The user payment app reads the payment request number and communication address from the captured image data of the code (S120). The user payment app transmits an HTTP request including the payment request number, personal information, and payment request to the first-class payment server 81 indicated by the communication address acquired in step S120 via the communication interface 75 (see FIG. 1) and the Internet 19 (see FIG. 1) (S121). The personal information is associated with the user payment app and pre-stored in the memory 73 (see FIG. 1) of the purchaser terminal 70. The payment request is, for example, a command.

[0209] The first-class payment server 81 receives the HTTP request including the payment request number, personal information, and payment request (S121). The controller (not shown) of the first-class payment server 81 performs settlement processing based on the business operator ID and settlement information associated with the received payment request number and the received personal information (S122). The controller of the first-class payment server 81 returns an HTTP response including payment completion information to the purchaser terminal 70 as a response to the HTTP request received in step S121 (S123).

[0210] Meanwhile, after executing the process of step S118, the payment application 61 of the store terminal 20 periodically transmits an HTTP request including an inquiry request to the first type payment server 81 via the first communication interface 34 (see FIG. 1) and the Internet 19 (see FIG. 1) (S124). The inquiry request is, for example, a command.

[0211] The first type payment server 81 periodically receives an HTTP request including an inquiry request (S124). Although not shown in FIG. 8, a controller (not shown) of the first type payment server 81 replies to the store terminal 20 with an HTTP response including information indicating that the payment process has not been completed, in response to an inquiry request received before the execution of the payment process (S122). The controller of the first type payment server 81 replies to the store terminal 20 with an HTTP response including payment completion information, in response to the HTTP request received in step S124, in response to an inquiry request received after the execution of the payment process (S122) (S125).

[0212] The store terminal 20 receives the HTTP response including the payment completion information via the first communication interface 34 (see FIG. 1) (S125). The payment application 61 of the store terminal 20 stores the payment completion information in the terminal memory 32 (see FIG. 1) and passes a path indicating the payment completion information to the first type module 51 via the OS 37 (see FIG. 1) (S126). The process of step S126 is the same as the process of step S92 (see FIG. 6).

[0213] The first type module 51 passes the received path to the main body module 50 (S127). The process of step S127 is the same as the process of step S93.

[0214] Upon receiving the path, the main body module 50 executes the processes of steps S94, S95, S96, and S97.

[0215] FIG. 9 is a flowchart showing the process when personal information is sent from the purchaser terminal 70 to the second type settlement server 82 and electronic settlement is carried out.

[0216] As shown in Figure 9, the main module 50 of the store app 38 executes the processes from step S71 to step S77 and step S101. The process of step S101 launches the second-type module 52. The second-type module 52 launched in Figure 9 is a module corresponding to the electronic payment method selected by the purchaser, and differs from the second-type module 52 launched in Figure 7. Specifically, the second-type module 52 launched in Figure 7 is a module in which the electronic payment method selected by the purchaser transmits the personal information to the second-type payment server 82 via the store terminal 20, while the second-type module 52 launched in Figure 9 is a module in which the electronic payment method selected by the purchaser transmits the personal information from the purchaser terminal 70 to the second-type payment server 82.

[0217] The second type module 52 and the second type payment server 82 started by the process of step S101 execute the processes of steps S102 to S108. The processes of steps S102 to S108 are the same as the processes of steps S102 to S108 described in FIG.

[0218] Upon receiving the HTTP request including the provided data, the second type payment server 82 executes the processes of steps S115 to S117. The processes of steps S115 to S117 are the same as the processes of steps S115 to S117 described in FIG.

[0219] The browser 62 of the store terminal 20 that has received the HTTP response including the code data displays the code on the touch panel 33 (see FIG. 1) (S118).

[0220] The purchaser launches a code reading application (not shown) implemented in the purchaser terminal 70 (S131). The launched code reading application launches the camera 76 (see FIG. 1) via the OS (not shown). The purchaser uses the launched camera 76 to capture an image of the code displayed on the touch panel 33 (see FIG. 1) of the store terminal 20. The code image data generated by the image capture is passed to the code reading application via the OS. The code reading application reads a communication address and a payment request number from the code image data (S132). The purchaser operates the purchaser terminal 70 to launch a browser (not shown) (S133) and passes the communication address to the browser. The browser transmits an HTTP request including the payment request number, personal information, and a payment request to the second-class payment server 82 indicated by the communication address via the communication interface 75 (see FIG. 1) and the Internet 19 (see FIG. 1) (S134). The payment request is, for example, a command.

[0221] The second-type payment server 82 receives the HTTP request including the payment request number, personal information, and payment request (S134). The controller (not shown) of the second-type payment server 82 executes payment processing based on the received payment request number and personal information, and the business operator ID and settlement information to which the payment request number was assigned in step S115 (S135). The processing of step S134 is the same as the processing of step S121 (see FIG. 8). Thereafter, the controller of the second-type payment server 82 returns an HTTP response including payment completion information to the purchaser terminal 70 as a response to the HTTP request received in step S134 (S123).

[0222] Furthermore, the second type module 52 of the shop terminal 20 issues an inquiry instruction to the browser 62 via the OS 37 (see FIG. 1) (S136). The inquiry instruction is an instruction to periodically send an HTTP request including an inquiry request to the second type payment server 82. Having received the inquiry instruction, the browser 62 and the second type payment server 82 execute the processes from steps S124 to S126 and step S93. The processes from steps S124 to S126 are the same as the processes from steps S124 to S126 described in FIG. 8 and step S93 described in FIG. 6.

[0223] Upon receiving the pass indicating the payment completion information, the second type module 52 and the main body module 50 execute the processes from steps S93 to S97. The processes from steps S93 to S97 are the same as the processes from steps S93 to S97 described in FIG.

[0224] [Effects of the embodiment]

[0225] (1) When the electronic payment method selected by the purchaser is a payment method using the payment application 61 The main body module 50 starts up the first type module 51. The started up first type module 51 starts up the payment application 61 and passes settlement information to the payment application 61. The payment application 61 transmits the received settlement information to the first type payment server 81. The first type payment server 81 performs payment based on the received settlement information.

[0226] (2) If the electronic payment method selected by the purchaser is a payment method using a payment web API. The main module 50 starts the second type module 52. The started second type module 52 starts the browser 62 and passes the payment URL of the second type payment server 82 to the browser 62. The browser 62 uses the payment URL to communicate with the second type payment server 82, obtains JavaScript having format data, and passes it to the second type module 52. The second type module 52 generates provided data based on the JavaScript and settlement information, and transmits the generated provided data to the second type payment server 82 via the browser 62. The second type payment server 82 performs payment based on the received provided data.

[0227] In this way, the store app 38 can send settlement information to the first-type payment server 81 and the second-type payment server 82 without relying on the purchaser's operation. Therefore, the payment support system 10 allows the purchaser to easily make an electronic payment, whether the electronic payment method selected by the purchaser is a method using the payment app 61 or a method using a payment web API.

[0228] The store app 38 has multiple types of first-type modules 51, and each first-type module 51 corresponds to one payment app 61. Therefore, regardless of differences in specifications between the multiple payment apps 61, the store app 38 can appropriately launch each of the multiple payment apps 61 and send settlement information to the first-type payment server 81 without relying on the purchaser's operation.

[0229] The main module 50 generates payment completion notification screen data based on the payment completion information obtained from the first type module 51 and the second type module 52, and displays the payment completion notification screen on the touch panel 33, so that the same payment completion notification screen can be displayed on the touch panel 33 regardless of the electronic payment method selected by the purchaser.

[0230] Main module 50 executes a registration process (S20, S31 in FIG. 4) to register Type 1 modules 51 and Type 2 modules 52 that correspond to the electronic payment methods that commercial businesses that introduce payment assistance system 10 have contracted with and can use as available modules. In other words, management server 40 can set available modules for each commercial business. As a result, system management becomes easier.

[0231] Type 1 module 51 enables electronic payments using payment application 61 (see FIG. 5), and type 2 module 52 enables electronic payments using a payment web API (see FIG. 5). In this way, automatic activation of payment application 61 and payment web API makes it easy for commercial businesses to introduce payment support system 10.

[0232] If a commercial business that has introduced payment support system 10 changes its available payment methods by signing or terminating a contract with a new payment service provider, the determination process in step S30 determines that the available payment methods do not match, and the activation process is re-executed (S30: "1" and S21). In other words, the available payment methods are automatically changed. This reduces the effort required for the commercial business that introduces payment support system 10 and the service provider that operates payment support system 10.

[0233] [Variations]

[0234] In the embodiment, an example has been described in which all currently released payment apps 61, all first-type modules 51 developed corresponding to the payment apps 61, and all second-type modules 52 developed corresponding to all currently released payment web APIs are stored in the terminal memory 32 of the store terminal 20, and the first-type modules 51 and second-type modules 52 corresponding to the payment apps 61 and payment web APIs provided by a payment service provider with which the commercial business has concluded a contract are activated. However, only the first-type modules 51 and second-type modules 52 corresponding to the payment apps 61 and payment web APIs provided by a payment service provider with which the commercial business has concluded a contract may be installed in the store terminal 20 in an executable manner. In this case, the main module 50 of the store app 38 downloads the payment apps 61, the first-type modules 51, and the second-type modules 52 from, for example, the management server 40 or a website operated by the payment service provider.

[0235] In the embodiment, an example was described in which a determination of "mismatch" is made in step S26 (see FIG. 4 ) when a commercial business enters into or terminates a contract with a payment service provider, resulting in a change in the type of electronic payment available. In step S26, in addition to determining whether the app ID and module ID match, the management server 40 may also determine whether the versions of the payment app 61 and the Type 1 and Type 2 modules 51 and 52 match. For example, if the versions of the payment app 61, Type 1 module 51, and Type 2 module 52 installed in the store terminal 20 are not the latest versions, the management server 40 returns an HTTP response to the store terminal 20 in step S29, including the latest versions of the payment app 61, Type 1 module 51, and Type 2 module 52. The main module 50 of the store app 38 updates the payment app 61, Type 1 module 51, and Type 2 module 52 using the received latest versions of the payment app 61, Type 1 module 51, and Type 2 module 52.

[0236] In the embodiment, an example has been described in which the store terminal 20 acquires personal information from the purchaser terminal 70. However, the store terminal 20 may also acquire personal information from a credit card or IC card held by the purchaser. The credit card or IC card has an IC chip capable of near-field wireless communication. The store terminal 20 may also directly accept input of personal information by the purchaser through an input interface such as the touch panel 33. In this way, the store terminal 20 may acquire personal information by any method and from any source. [Explanation of symbols]

[0237] 10. Payment support system 11. First profit-making business operator 12. Second commercial enterprise 19. Internet 20. Store terminal 31 CPU 32. Device memory 33 Touch panel (display) 34 First communication interface 35···Camera 36. Scanning device 37···OS 38. Store application software 40 Management Server 41 Server Controller 42 CPU 43 Server Memory 44 Second communication interface 45···OS 46 Server program 50 Main module 51...Type 1 module 52...Second-class module 61 Payment application software 62...Browser 70···Purchaser terminal 71 Terminal Controller 72 CPU 73. Memory 74···Touch panel 75 Communication Interface 76···Camera 81...Type 1 payment server 82...Second-class payment server

Claims

1. a store terminal installed in a store and having a display, an input interface, a first communication interface, a terminal computer, and a terminal memory; a management server having a second communication interface, a server controller, and a server memory, and capable of communicating with the store terminal via the Internet; A payment support system comprising: the terminal memory stores store application software, payment business application software, and a browser executed by the terminal computer; The above store application software is a main body module including a user interface; a first type module for starting the payment business application software; a second type module for a payment web API; The main body module is A process of obtaining settlement information; A process of accepting a selection of a payment method through the input interface; a module selection process for selecting a corresponding module, which is the first type module or the second type module, corresponding to the payment means, and transferring the settlement information to the selected corresponding module; The first type module selected as the corresponding module is launching the payment business application software and having the terminal computer execute a process of passing the settlement information to the launched payment business application software; The second type module selected as the corresponding module is a process of launching the browser and passing the communication address stored in the terminal memory to the launched browser; a process of acquiring, from the browser, first data acquired by the browser from the payment server indicated by the communication address; generating payment information based on the acquired first data and the settlement information; and transmitting the payment information to the payment server via the browser.

2. the terminal memory stores a plurality of types of payment business application software; the store application software has a plurality of the first type modules, 2. The payment support system according to claim 1, wherein one of said first type modules corresponds to one of said payment business application software.

3. The first type module is causing the terminal computer to execute a process of acquiring payment completion information through the payment business application software; The second type module is causing the terminal computer to execute a process for acquiring payment completion information through the browser; The main body module is A process of acquiring the payment completion information from the first type module and the second type module; A process of generating payment completion notification screen data based on the acquired payment completion information; 3. The payment support system according to claim 1, further comprising: causing the terminal computer to execute a process of displaying a payment completion notification screen indicated by the generated payment completion notification screen data on the display.

4. the server memory stores a management database; In the management database, a business operator ID, a payment method, and a module ID indicating the first type module and the second type module are associated with each other, The main body module is causing the terminal computer to execute a process of transmitting a request including the business ID to the management server via the first communication interface and the Internet; The server controller is executes a process of returning a response including the received business ID and the module ID associated in the management database to the store terminal via the second communication interface and the Internet; The main body module is causing the terminal computer to execute an activation process for activating the first type module and the second type module indicated by the received module ID; The above activation process is 3. The payment support system according to claim 1, further comprising a process for storing the module IDs of the first type module and the second type module that are to be made available as registration IDs in the terminal memory.

5. The main body module is causing the terminal computer to execute a process of inputting an activation instruction to the first type module and the second type module indicated by the registration ID; The first type module, upon receiving the activation instruction, activates the corresponding payment business application software and causes the terminal computer to execute a process of transferring predetermined first setting information; The second type module is a process of starting the browser based on the reception of the activation instruction and passing the communication address stored in the terminal memory to the started browser; A process in which the browser acquires, via the browser, second data acquired from the payment server indicated by the communication address; generating setting registration information based on the acquired second data and predetermined second setting information; 5. The payment support system according to claim 4, wherein the terminal computer is caused to execute a process of transmitting the setting registration information to the payment server through the browser.

6. The main body module is causing the terminal computer to execute a process of transmitting a request including the registration ID and the business ID to the management server via the first communication interface and the Internet; The server controller is a determination process of determining whether or not a correspondence relationship between the first type module and the second type module indicated by the received registration ID and the received provider ID matches a correspondence relationship between the first type module and the second type module and the provider ID registered in the management database; a reply process of returning a response including a determination result in the determination process to the store terminal via the second communication interface and the Internet; The main body module is 5. The payment support system according to claim 4, wherein the terminal computer is caused to re-execute the validation process upon receiving the determination result indicating a mismatch.

7. Store application software installed in a store terminal, The store terminal is installed in a store and has a display, an input interface, a first communication interface, a terminal computer, and a terminal memory; The terminal memory stores payment business application software and a browser, a main body module including a user interface; a first type module for starting the payment business application software; a second type module for a payment web API; The main body module is A process of obtaining settlement information; A process of accepting input of a payment method through the input interface; a module selection process for selecting a corresponding module, which is the first type module or the second type module, corresponding to the payment means, and transferring the settlement information to the selected corresponding module; The first type module, which is the corresponding module, launching the payment business application software and having the terminal computer execute a process of passing the settlement information to the launched payment business application software; The second type module, which is the corresponding module, a process of launching the browser and passing the communication address stored in the terminal memory to the launched browser; A process in which the browser acquires, via the browser, first data acquired from the payment server indicated by the communication address; generating payment information based on the acquired first data and the settlement information; and transmitting the payment information to the payment server via the browser.

Images