Transaction processing system, terminal device, information processing program, store system, and transaction support device

Abstract

To prevent a customer from taking out a product that the customer tries to register as a purchased product but could not be registered correctly without being settled.SOLUTION: A transaction processing system of an embodiment includes registration means, settlement means, acquisition means, and control means. The registration means registers a product specified by an operation on a terminal as a product to be purchased by a customer using the terminal. The settlement means performs settlement processing for causing the customer to settle a price of the product registered by the registration means. The acquisition means acquires, when there is a product that could not be registered as a purchase to be purchased by the registration means, data specified by the operation on the terminal. The control means allows, when the data acquired by the acquisition means is predetermined release data, the settlement means to start the settlement processing.SELECTED DRAWING: Figure 17

Description

[Technical field]

[0001] The present invention relates to a transaction processing system, a transaction support device, an information processing program, and a transaction processing method. [Background technology]

[0002] A transaction processing system that registers details of a transaction in response to a customer's operation of a terminal device is considered to be, for example, a cart POS system or a smartphone POS system. In such a system, if a payment method such as credit card payment or barcode payment is used, the payment process can be completed in response to the customer's operation on the terminal device. Also, if a self-service accounting machine that processes the payment in response to the customer's operation is used, the payment process can be completed in response to the customer's operation on the accounting machine. If the payment can be completed in this way, it is possible to complete the transaction without the involvement of a store clerk.

[0003] However, for newly released products or products sold for a limited time, there may be a delay in registering the product in the product database, and products that are not registered in the product database may end up on store shelves. Also, products may have a barcode other than the barcode showing the product code, and customers may have their terminal device read a barcode that does not show the product code. In these cases, the product cannot be registered as a purchased product, but customers may think that they have registered it. In such a situation, if payment were to be made without the involvement of a store clerk, the customer would be able to take away the unpaid items. In view of these circumstances, it has been desirable to prevent products that a customer has attempted to register as a purchased item but was unable to register correctly from being taken away without being paid for. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2019-144797 A Summary of the Invention [Problem to be solved by the invention]

[0005] To provide a transaction processing system, a transaction support device, an information processing program, and a transaction processing method that can prevent products that a customer has attempted to register as a purchased item but failed to register correctly from being taken away without being paid for. [Means for solving the problem]

[0006] The transaction processing system of the embodiment includes a registration means, a payment means, an acquisition means, and a control means. The registration means registers a product specified by an operation on the terminal as a product to be purchased by a customer using the terminal. The payment means performs a payment process to have the customer pay for the product registered by the registration means. The acquisition means acquires data specified by an operation on the terminal when there is a product that could not be registered as a product to be purchased by the registration means. The control means allows the payment means to start the payment process when the data acquired by the acquisition means is predetermined release data. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system according to an embodiment. [Diagram 2] 2 is a block diagram showing a main circuit configuration of the store server in FIG. 1; [Diagram 3] 2 is a block diagram showing a main circuit configuration of the virtual POS server in FIG. 1; [Figure 4] FIG. 2 is a block diagram showing a main circuit configuration of the mobile controller in FIG. [Diagram 5] 5 is a schematic diagram showing the main data structure of a data record contained in the transaction management database shown in FIG. 4. [Figure 6] FIG. 5 is a schematic diagram showing the main data structure of a data record contained in the registration database shown in FIG. 4. [Figure 7] FIG. 2 is a block diagram showing a main circuit configuration of the communication server in FIG. [Figure 8] 2 is a block diagram showing a main circuit configuration of the user terminal in FIG. 1; [Figure 9] 9 is a flowchart of information processing by the processor shown in FIG. 8 . [Figure 10] 9 is a flowchart of information processing by the processor shown in FIG. 8 . [Figure 11] 9 is a flowchart of information processing by the processor shown in FIG. 8 . [Figure 12] 9 is a flowchart of information processing by the processor shown in FIG. 8 . [Figure 13] 9 is a flowchart of information processing by the processor shown in FIG. 8 . [Figure 14] 5 is a flowchart of information processing by the processor shown in FIG. 4. [Figure 15] 5 is a flowchart of information processing by the processor shown in FIG. 4. [Figure 16] 5 is a flowchart of information processing by the processor shown in FIG. 4. [Figure 17] 5 is a flowchart of information processing by the processor shown in FIG. 4. [Figure 18] FIG. 13 is a diagram showing an example of a list screen. [Figure 19] FIG. 13 is a diagram showing an example of a registration screen. [Figure 20] FIG. 13 is a diagram showing an example of a list screen. [Figure 21] FIG. 13 is a diagram showing an example of a list screen. [Figure 22] FIG. 13 is a diagram showing an example of a guidance screen. [Figure 23] FIG. 13 is a diagram showing an example of a confirmation screen. [Figure 24] FIG. 13 is a diagram showing an example of a release screen. [Diagram 25] FIG. 13 is a diagram showing an example of a warning screen. [Figure 26] FIG. 13 is a diagram showing an example of a checkout screen. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] An embodiment of a transaction processing system will be described below with reference to the drawings. The transaction processing system in this embodiment processes transactions of goods in a store that sells multiple goods to visiting customers, including goods that require confirmation by a store clerk before being sold due to reasons such as age restrictions for purchasers (hereinafter referred to as "goods requiring confirmation").

[0009] FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system according to this embodiment. The transaction processing system is configured so that a plurality of store systems 100, relay servers 200, and user terminals 300 can communicate with each other via a communication network 400. FIG. 1 shows two store systems 100. These store systems 100 are installed in two different stores, Store A and Store B, which use the transaction processing system. There may be three or more stores that use the transaction processing system, with a store system 100 installed in each store. In the following, when it is necessary to distinguish between the store systems 100 installed in each store, the store system 100 installed in Store A will be referred to as store system 100A, and the store system 100 installed in Store B will be referred to as store system 100B. The business operator who operates store A may be the same as or different from the business operator who operates store B. When the transaction system is used in other stores, the business operator who operates the other stores may be the same as or different from the business operator who operates store A or store B.

[0010] The relay server 200 relays data communication between the user terminal 300 and the store system 100. The relay server 200 provides a data communication relay function as a cloud service via a communication network 400, for example. The user terminal 300 is an information communication terminal that functions as a user interface for customers who use the transaction system to shop at a store. The user terminal 300 has a function of wireless communication with the store system 100 and a function of wireless communication with the communication network 400. As the user terminal 300, a communication terminal with a data communication function such as a smartphone or a tablet terminal can be used. The user terminal 300 may be owned by the customer or may be loaned to the customer at the store. The communication network 400 may be, for example, the Internet, a virtual private network (VPN), a local area network (LAN), a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. Typically, the communication network 400 is a mobile communication network and the Internet or a VPN.

[0011] The general configuration of each store system 100 is the same. That is, the store system 100 is configured so that the store server 1, virtual POS server 2, mobile controller 3, communication server 4, payment machine 5, and access point 6 can communicate with each other via an in-store communication network 7. However, the store server 1, virtual POS server 2, mobile controller 3, communication server 4, payment machine 5, access point 6, and in-store communication network 7 only need to have the same functions for implementing the operations described below, and do not need to be completely identical. Some store systems 100 may also be equipped with devices not shown in FIG. 1.

[0012] The store server 1 comprehensively manages a plurality of transactions that are the subject of transaction processing realized as described below by the store system 100. The store server 1 has, for example, the same functions as an existing POS server. The virtual POS server 2 performs information processing for registering purchased items for each transaction and settling the price of the purchased items in response to an external request. In other words, the virtual POS server 2 virtually realizes the functions of an existing POS terminal. The information processing performed by the virtual POS server 2 is customized to accommodate differences in the management policies of each store. In other words, for example, the information processing performed by the store server 1 provided in the store system 100A may partially differ from the information processing performed by the store server 1 provided in the store system 100B.

[0013] The mobile controller 3 assists the virtual POS server 2 in performing the above-mentioned information processing using the user terminal 300 as a user interface device. The mobile controller 3 is an example of a transaction assisting device. The communication server 4 performs communication processing for the store server 1, the virtual POS server 2, the mobile controller 3, and the payment machine 5 to exchange data with the relay server 200 and the like via the communication network 400.

[0014] The accounting machine 5 calculates the price of the purchased item for each transaction managed by the virtual POS server 2, and performs processing to have the customer pay the price. The payment methods that the accounting machine 5 can use for the above-mentioned payment may be all or any part of well-known payment methods, such as cash payment, credit card payment, electronic money payment, point payment, code payment (also called mobile payment or smartphone payment, etc.). The accounting machine 5 may be operated by either a store clerk or a customer. For example, the accounting machine 5 may be a self-service accounting machine used in an existing semi-self-service POS system. The accounting machine 5 may have a function of performing information processing to register the item as a purchased item. In this case, for example, the accounting machine 5 may be a face-to-face POS terminal used in an existing POS system or a self-service POS terminal used in an existing self-service POS system.

[0015] The access point 6 performs communication processing to enable the user terminal 300 to access the in-store communication network 7 via wireless communication. For example, a well-known communication device that performs wireless communication according to the IEEE802.11 standard can be used as the access point 6. The access point 6 is installed in the store so that the user terminal 300 can perform wireless communication from anywhere in the sales floor of the store. Depending on the size of the store, multiple access points 6 may be installed in one store system 100. The in-store communication network 7 may be the Internet, VPN, LAN, a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. Typically, however, the in-store communication network 7 is a LAN.

[0016] In a store where the store system 100 is installed, a two-dimensional code TC1 for check-in is posted near the entrance, and a two-dimensional code TC2 for check-out is posted near the exit. The two-dimensional code TC1 represents check-in data for check-in. The two-dimensional code TC2 represents check-out data for check-out. The check-in data and check-out data differ from store to store. For this reason, when it is necessary to distinguish between the two-dimensional codes TC1 and TC2 for store A and the two-dimensional codes TC1 and TC2 for store B, the codes for store A are represented as two-dimensional codes TC1A and TC2A, and the codes for store B are represented as two-dimensional codes TC1B and TC2B.

[0017] The check-in data may represent, for example, the following information: (1) The operation version of the store system 100. For example, the check-in data represented by the two-dimensional code TC1A represents the operation version of the store system 100A. The check-in data represented by the two-dimensional code TC1B represents the operation version of the store system 100B. (2) A business code for identifying a business operator that operates the store in which the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TC1A represents the business code assigned to the business operator that operates store A. The check-in data represented by the two-dimensional code TC1B represents the business code assigned to the business operator that operates store B. (3) A store code for identifying the store in which the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TC1A represents the store code assigned to store A. The check-in data represented by the two-dimensional code TC1B represents the store code assigned to store B. The store code may be capable of identifying all individual stores that use the transaction processing system, or may be capable of identifying each of multiple stores operated by the same business operator.

[0018] (4) The name of the business operator that operates the store in which the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TC1A represents the name of the business operator that operates store A. The check-in data represented by the two-dimensional code TC1B represents the name of the business operator that operates store B. (5) The name of the store in which the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TC1A represents the name of store A. The check-in data represented by the two-dimensional code TC1B represents the name of store B. (6) A flag for distinguishing between the two-dimensional code TC1 and the two-dimensional code TC2. The flag in the check-in data indicates that the data is check-in data. The state is, for example, "1." The flag is common to all two-dimensional codes TC1.

[0019] (7) IP address of the communication server 4. For example, the check-in data represented by the two-dimensional code TC1A represents the IP address of the communication server 4 included in the store system 100A. The check-in data represented by the two-dimensional code TC1B represents the IP address of the communication server 4 included in the store system 100B. (8) Domain name of the relay server 200. The domain name is common to all two-dimensional codes TC1. However, multiple relay servers 200 with different domain names may be used for each store. In this case, the check-in data represented by the two-dimensional code TC1 represents the domain name of the relay server 200 used in the corresponding store. (9) Address of the electronic receipt server. The electronic receipt server is not included in the transaction processing system shown in FIG. 1 and provides an electronic receipt service via the communication network 400. For example, the check-in data represented by the two-dimensional code TC1A represents an address for accessing, via the communication network 400, an electronic receipt server providing an electronic receipt service used by a business operating store A. The check-in data represented by the two-dimensional code TC1B represents an address for accessing, via the communication network 400, an electronic receipt server providing an electronic receipt service used by a business operating store B. The address may be common to all two-dimensional codes TC1, or any one of multiple addresses may be represented for each two-dimensional code TC1.

[0020] (10) A flag indicating whether the user terminal 300 should use wireless communication with the access point 6 or wireless communication with the communication network 400 to exchange data with the store system 100. For example, in store A, if wireless communication with the access point 6 is used to exchange data between the store system 100A and the user terminal 300, the flag is set to, for example, "1." For example, in store B, if wireless communication with the communication network 400 is used to exchange data between the store system 100B and the user terminal 300, the flag is set to, for example, "0." (11) SSID (service set identifier) ​​for identifying the access point 6. For example, the check-in data represented by the two-dimensional code TC1A represents the SSID for identifying the access point 6 included in the store system 100A. The check-in data represented by the two-dimensional code TC1B represents the SSID for the access point 6 included in the store system 100B. (12) Password for accessing the access point 6. For example, the check-in data represented by the two-dimensional code TC1A represents the password set for the access point 6 included in the store system 100A. The check-in data represented by the two-dimensional code TC1B represents the password set for the access point 6 included in the store system 100B.

[0021] (13) Identification number of the security method used by the access point 6. For example, the identification number is assigned as "1" for the WPA2-PSK method, "2" for the WPA-PSK method, and "3" for the WEP method. For example, if the access point 6 included in the store system 100A uses the WPA2-PSK method as its security method, the check-in data represented by the two-dimensional code TC1A indicates "1" as the identification number. For example, if the access point 6 included in the store system 100B uses the WPA-PSK method as its security method, the check-in data represented by the two-dimensional code TC1B indicates "2" as the identification number. (14) A flag for identifying whether to treat a failure in connection between the user terminal 300 and the relay server 200 as an error or to continue operation without treating it as an error. For example, in store A, if the user terminal 300 is set to treat a failure in connection between the user terminal 300 and the relay server 200 as an error, the check-in data represented by the two-dimensional code TC1A indicates, for example, "1" as the flag. Also, in store B, if the user terminal 300 is set to continue operation even if the user terminal 300 fails to connect to the relay server 200, the check-in data represented by the two-dimensional code TC1B indicates, for example, "0" as the flag.

[0022] (15) Identification number of the transmission mode related to the status of the user terminal 300. The transmission modes include, for example, a first mode, a second mode, and a third mode. For example, the identification number of the transmission mode is assigned as "1" for the first mode, "2" for the second mode, and "3" for the third mode. In the first mode, the status of the user terminal 300 is transmitted to the relay server 200. In the second mode, the status of the user terminal 300 is transmitted to the store system 100. In the second mode, the status of the user terminal 300 is not transmitted. For example, in store A, if the first mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1A represents "1" as the identification number. Also, in store B, if the second mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1B represents "2" as the identification number.

[0023] (16) Identification number of the transmission mode related to the log file that accumulates the log data of the user terminal 300. The transmission modes include, for example, the first mode, the second mode, the third mode, and the fourth mode. For example, the identification number of the transmission mode is assigned as "1" for the first mode, "2" for the second mode, "3" for the third mode, and "4" for the fourth mode. In the first mode, the log file is transmitted only to the relay server 200. In the second mode, the log file is transmitted only to the store system 100. In the third mode, the log file is transmitted to both the store system 100 and the relay server 200. In the fourth mode, the log file is not transmitted. For example, in store A, if the first mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1A represents "1" as the identification number. Also, in store B, if the second mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1B represents "2" as the identification number.

[0024] (17) The host name or IP address used when transmitting the log file to the relay server 200 via the communication network 400 by FTP (file transfer protocol). (18) The user name used when transmitting the log file to the relay server 200 via the communication network 400 by FTP. (19) A password used when transmitting the log file to the relay server 200 via the communication network 400 by FTP. (20) The path name of the log file to be transmitted by FTP to the relay server 200 via the communication network 400.

[0025] (21) A flag for identifying whether or not to delete the check digit of a UPC (universal product code), which is a type of product code. For example, if store A operates in a manner that does not delete the check digit, then the check-in data represented by the two-dimensional code TC1A will indicate, for example, a "1" as the flag. For example, if store B operates in a manner that deletes the check digit, then the check-in data represented by the two-dimensional code TC1B will indicate, for example, a "0" as the flag. (22) The time until the camera screen automatically transitions on the user terminal 300. The check-in data represented by the two-dimensional code TC1A represents the time, which is a time that has been preset for store A. The check-in data represented by the two-dimensional code TC1B represents the time, which is a time that has been preset for store B. (23) Timeout time when the user terminal 300 communicates with the store system 100 via the access point 6. The check-in data represented by the two-dimensional code TC1A represents the time that has been preset for store A. The check-in data represented by the two-dimensional code TC1B represents the time that has been preset for store B.

[0026] (24) The number of retries allowed when communication between the user terminal 300 and the store system 100 via the access point 6 times out. The check-in data represented by the two-dimensional code TC1A represents the number of retries that has been preset for store A. The check-in data represented by the two-dimensional code TC1B represents the time that has been preset for store B. (25) Timeout time when the user terminal 300 communicates with the store system 100 via the relay server 200. The check-in data represented by the two-dimensional code TC1A represents the time that has been preset for store A. The check-in data represented by the two-dimensional code TC1B represents the time that has been preset for store B. (26) The number of retries allowed when communication between the user terminal 300 and the store system 100 via the relay server 200 times out. The check-in data represented by the two-dimensional code TC1A represents the number of retries set in advance for store A. The check-in data represented by the two-dimensional code TC1B represents the time period set in advance for store B.

[0027] (27) Authentication data used in the authentication process to authenticate the declaration of confirmation completion for a transaction involving an item that requires confirmation by a store clerk. The check-in data represented by the two-dimensional code TC1A represents authentication data that has been preset for store A. The check-in data represented by the two-dimensional code TC1B represents authentication data that has been preset for store B. It is preferable that the authentication data be determined differently for each store, but the same authentication data may be set for different stores. (28) Data for identifying the operation mode of the store system 100. For example, if the store system 100A is set to a normal mode in which the transaction processing system is normally operated, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the relevant data. Also, if the store system 100B is set to a demo mode in which the transaction processing system is demo operated, the check-in data represented by the two-dimensional code TC1B represents, for example, "2" as the relevant data. (29) Data for identifying the mode of data transfer to the payment machine 5. For example, if the store system 100A is set to a mode in which data transfer is requested from the payment machine 5 to the mobile controller 3, the check-in data represented by the two-dimensional code TC1A represents the relevant data, for example, "1." Also, if the store system 100B is set to a mode in which data is transferred from the mobile controller 3 to the payment machine 5 without a request from the payment machine 5, the check-in data represented by the two-dimensional code TC1B represents the relevant data, for example, "2."

[0028] (30) A flag indicating whether or not payment is permitted using the code payment method via operation on the user terminal 300. For example, if the code payment is permitted in store A, the check-in data represented by the two-dimensional code TC1A indicates, for example, a "1" as the flag. Also, for example, if the code payment is not permitted in store B, the check-in data represented by the two-dimensional code TC1B indicates, for example, a "0" as the flag. (31) A flag for identifying whether or not a product for which an age restriction for the purchaser is set (hereinafter referred to as an age-restricted product) is permitted to be registered on the user terminal 300. For example, if store A permits the registration of an age-restricted product on the user terminal 300, the check-in data represented by the two-dimensional code TC1A will indicate, for example, a "1" as the flag. Also, for example, if store B does not permit the code payment, the check-in data represented by the two-dimensional code TC1B will indicate, for example, a "0" as the flag. (32) Data for identifying the input mode of the member code of a point member. For example, if the store system 100A is set to a mode in which the member code is manually entered, the check-in data represented by the two-dimensional code TC1A will indicate, for example, "1" as the relevant data. Also, for example, if the store system 100B is set to a mode in which the member code is entered by reading a barcode, the check-in data represented by the two-dimensional code TC1B will indicate, for example, "2" as the relevant data.

[0029] (33) A flag for identifying whether confirmation by a store clerk is required when entering a member code when the mode for manually entering the member code of a point member is set. For example, if such confirmation is required at store A, the check-in data represented by the two-dimensional code TC1A will show, for example, a "1" as the flag. Also, for example, if such confirmation is not required at store B, the check-in data represented by the two-dimensional code TC1B will show, for example, a "0" as the flag. (34) A threshold for checking the remaining battery level of the user terminal 300 at check-in. The threshold is set for each store or business. For example, if the business operating store A sets the threshold as "20%, " the check-in data represented by the two-dimensional code TC1A will indicate the threshold value as, for example, "20". Also, if store B sets the threshold value as "25%, " the check-in data represented by the two-dimensional code TC1B will indicate the threshold value as, for example, "25". The above are examples of information represented by check-in data. However, the check-in data may not include some of the various pieces of information shown above. Also, the check-in data may represent information other than the various pieces of information shown above.

[0030] FIG. 2 is a block diagram showing the main circuit configuration of the store server 1. As shown in FIG. The store server 1 includes a processor 11, a main memory 12, an auxiliary storage unit 13, a communication interface 14, and a transmission path 15. The processor 11, the main memory 12, the auxiliary storage unit 13, and the communication interface 14 are capable of communicating with each other via the transmission path 15. The processor 11, the main memory 12, and the auxiliary storage unit 13 are connected by the transmission path 15 to configure a computer for controlling the store server 1.

[0031] The processor 11 corresponds to the central part of the computer. The processor 11 executes information processing for realizing various functions of the store server 1 according to information processing programs such as an operating system and application programs. The processor 11 is, for example, a CPU (central processing unit).

[0032] The main memory 12 corresponds to the main storage portion of the computer. The main memory 12 includes a nonvolatile memory area and a volatile memory area. The main memory 12 stores the information processing program in the nonvolatile memory area. The main memory 12 may store data required for the processor 11 to execute information processing in a nonvolatile or volatile memory area. The main memory 12 uses the volatile memory area as a work area where data is appropriately rewritten by the processor 11. The nonvolatile memory area is, for example, a ROM (read only memory). The volatile memory area is, for example, a RAM (random access memory).

[0033] The auxiliary storage unit 13 corresponds to the auxiliary storage portion of the computer. As the auxiliary storage unit 13, for example, a storage unit using a well-known storage device such as an EEPROM (electric erasable programmable read-only memory), a HDD (hard disk drive), or an SSD (solid state drive) can be used. The auxiliary storage unit 13 stores data used by the processor 11 in performing various processes, or data created by the processes in the processor 11. The auxiliary storage unit 13 may also store the above-mentioned information processing program.

[0034] The communication interface 14 performs data communication in accordance with a predetermined communication protocol with each unit connected to the in-store communication network 7. As the communication interface 14, for example, a well-known communication device for a LAN can be applied. The transmission path 15 includes an address bus, a data bus, and control signal lines, and transmits data and control signals between the connected components.

[0035] The auxiliary storage unit 13 stores a store management application AP11, which is one of the information processing programs. The store management application AP11 is an application program, and describes information processing for realizing the functions of the store server 1. The store management application AP11 may be a separate application created for each store or for each store operating company in accordance with the store operating policy. For example, if the sales data management methods of store A and store B are different, the store management application AP11 used in the store system 100A describes information processing for managing sales data adapted to the sales data management method of store A, and the store management application AP11 used in the store system 100B describes information processing for managing sales data adapted to the sales data management method of store B.

[0036] A part of the storage area of ​​the auxiliary storage unit 13 is used as a database group DB11. The database group DB11 includes a plurality of databases for managing various types of information. One of the databases included in the database group DB11 is a product database for managing products sold in a store. The product database is a collection of data records associated with the products to be managed. The data records in the product database include data on the associated products, such as product codes, prices, and product names. The product codes are identification codes determined to identify products for each SKU (stock keeping unit), and for example, JAN (Japanese article number) codes are used. The product names are names determined to make it easy for humans to distinguish between products. The price is the amount of money paid for the sale of the product.

[0037] One of the databases included in the database group DB11 is a user database for managing users of the store. The user database is a collection of data records associated with customers registered as users. The data records of the user database include data on the associated customers, such as a user code and attribute information for identifying the user. The user code is a unique identification code assigned to each customer to identify the user individually. The attribute information may include name, gender, age, address, telephone number, etc. The data records of the user database may also include payment information declared by the user. The payment information may be a credit number or a code payment ID (identifier). In addition, when multiple payment methods are selectable, the payment information may also include a payment method code for identifying the payment method. In addition, in the case of a store that provides a point service, the payment information may also include a point service ID and the number of points held.

[0038] In addition, the database group DB11 may include various databases managed by a POS server in an existing POS system. Note that the type of databases included in the database group DB11, or the type of data and the structure in which these databases are included, may be determined for each store.

[0039] FIG. 3 is a block diagram showing the main circuit configuration of the virtual POS server 2. As shown in FIG. The virtual POS server 2 includes a processor 21, a main memory 22, an auxiliary storage unit 23, a communication interface 24, and a transmission path 25. The processor 21, the main memory 22, the auxiliary storage unit 23, and the communication interface 24 are capable of communicating with each other via the transmission path 25. The processor 21, the main memory 22, and the auxiliary storage unit 23 are connected by the transmission path 25 to configure a computer for controlling the virtual POS server 2. The functions of the processor 21, the main memory 22, the auxiliary storage unit 23, the communication interface 24, and the transmission path 25 are generally equivalent to those of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 24, and the transmission path 25, and therefore will not be described here.

[0040] However, the auxiliary storage unit 23 stores a virtual POS application AP21 instead of the store management application AP11. The virtual POS application AP21 is an application program, and describes information processing for realizing the functions of the virtual POS server 2. The virtual POS application AP21 may be a separate application created for each store or for each business operator that operates the store, in accordance with the store management policy. For example, if store A provides a discount service that is not provided in store B, the virtual POS application AP21 used in the store system 100A describes information processing for realizing the discount service, and the virtual POS application AP21 used in the store system 100B does not describe information processing for realizing the discount service.

[0041] Furthermore, a portion of the memory area of ​​the auxiliary memory unit 23 is used as a transaction database DB21 in place of the database group DB11. The transaction database DB21 is a collection of data records associated with transactions with customers who are shopping around the store. The data records of the transaction database DB21 include a transaction code and product data related to products that have been registered as purchased products. The transaction code is a unique identification code set for each transaction to identify each transaction. The product data indicates the product code, product name, price, quantity, etc. The structure of the transaction database DB21 may be determined individually to suit the store management policy of each store or each business operator that operates the store.

[0042] FIG. 4 is a block diagram showing the main circuit configuration of the mobile controller 3. The mobile controller 3 includes a processor 31, a main memory 32, an auxiliary storage unit 33, a communication interface 34, and a transmission path 35. The processor 31, the main memory 32, the auxiliary storage unit 33, and the communication interface 34 are capable of communicating with each other via the transmission path 35. The processor 31, the main memory 32, and the auxiliary storage unit 33 are connected by the transmission path 35 to configure a computer for controlling the mobile controller 3. Note that the functions of the processor 31, the main memory 32, the auxiliary storage unit 33, the communication interface 34, and the transmission path 35 are generally similar to those of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 14, and the transmission path 15, and therefore a description thereof will be omitted.

[0043] However, the auxiliary storage unit 33 stores a registration support application AP31 instead of the store management application AP11. The registration support application AP31 is an application program in which information processing (described below) for supporting the registration of purchased items is described. The registration support application AP31 is common to each store system 100. However, various settings for information processing based on the registration support application AP31 may be customized for each store system 100.

[0044] Furthermore, part of the storage area of ​​the auxiliary storage unit 23 is used as a transaction management database DB31 and a registration database DB32 in place of the database group DB11. The structures of the transaction management database DB31 and the registration database DB32 are common to each store system 100.

[0045] FIG. 5 is a schematic diagram showing the main data structure of a data record DR1 contained in the transaction management database DB31. The transaction management database DB31 is a collection of data records DR1 associated with the user terminals 300 used by customers in the store. Therefore, when there is one customer in the store, the transaction management database DB31 contains one data record DR1. When there are no customers in the store, the transaction management database DB31 does not contain a data record DR1. And the data record DR1 contains fields F11, F12, F13, and F14.

[0046] In the field F11, a terminal code for identifying the associated user terminal 300 from other user terminals 300 is set. For example, a unique identification code set for each communication terminal to identify each communication terminal used as the user terminal 300 can be used as the terminal code. Alternatively, for example, an identification code set for a smartphone POS application described later when the smartphone POS application is installed in the user terminal 300 can be used as the terminal code. In the field F12, a membership code for identifying a customer using the associated user terminal 300 from other customers is set. In the field F13, a transaction code for a transaction performed using the associated user terminal 300 is set. In the field F14, a confirmation flag is set to identify whether or not a confirmation-required product is included in the products registered as purchased products using the associated user terminal 300. In this embodiment, the confirmation flag indicates that a confirmation-required product is included when it is "1". The data record DR1 may include another field in which data other than the fields F11 to F15 is set. In other words, the confirmation-required flag indicates whether or not confirmation by a store clerk is required.

[0047] FIG. 6 is a schematic diagram showing the main data structure of a data record DR2 contained in the registration database DB32. The registration database DB32 is a collection of data records DR2 associated with transactions with customers shopping around the store. The data records DR2 include fields F21, F22. The data record DR1 may also include fields F23, F24, ...

[0048] A transaction code of the associated transaction is set in field F21. This transaction code is the same as the transaction code set in field F12 of data record DR1 associated with the user terminal 300 used in the associated transaction. A registration data regarding the attempted product registration for the associated transaction is set in field F22. The registration data will be described later.

[0049] The data record DR2 includes fields F23 and onwards when an attempt is made to register two or more purchased items for an associated transaction. The same registration data as in field F12 is set in fields F23 and onwards.

[0050] FIG. 7 is a block diagram showing the main circuit configuration of the communication server 4. As shown in FIG. The communication server 4 includes a processor 41, a main memory 42, an auxiliary storage unit 43, a communication interface 44, a communication unit 45, and a transmission path 46. The processor 41, the main memory 42, the auxiliary storage unit 43, the communication interface 44, and the communication unit 45 are capable of communicating with each other via the transmission path 46. The processor 41, the main memory 42, and the auxiliary storage unit 43 are connected by the transmission path 46 to configure a computer for controlling the communication server 4. The functions of the processor 41, the main memory 42, the auxiliary storage unit 43, the communication interface 44, and the transmission path 46 are generally equivalent to those of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 14, and the transmission path 15, and therefore will not be described here. The communication unit 45 performs communication processing for data communication via the communication network 400. As the communication unit 45, for example, a well-known Internet connection device can be applied.

[0051] The auxiliary storage unit 43 stores a communication processing application AP41 in place of the store management application AP11. The communication processing application AP41 is an application program in which information processing is described for communicating with the relay server 200 via the communication network 400 to enable data exchange between the mobile controller 3 and the user terminal 300. The communication processing application AP41 is common to each store system 100. However, various settings for information processing based on the communication processing application AP41 may be customized for each store system 100.

[0052] FIG. 8 is a block diagram showing the main circuit configuration of the user terminal 300. As shown in FIG. The user terminal 300 includes a processor 301, a main memory 302, an auxiliary storage unit 303, a touch panel 304, a camera 305, a wireless communication unit 306, a mobile communication unit 307, and a transmission path 308. The processor 301, the main memory 302, the auxiliary storage unit 303, the touch panel 304, the camera 305, and the mobile communication unit 307 are capable of communicating with each other via the transmission path 308. The processor 301, the main memory 302, and the auxiliary storage unit 303 are connected via the transmission path 308 to configure a computer for controlling the user terminal 300. The functions of the processor 301, the main memory 302, the auxiliary storage unit 303, and the transmission path 308 are generally the same as those of the processor 11, the main memory 12, the auxiliary storage unit 13, and the transmission path 15, and therefore will not be described here.

[0053] The touch panel 304 functions as an input device and a display device for the user terminal 300 . The camera 305 includes an optical system and an image sensor, and generates image data representing an image within a field of view formed by the optical system using the image sensor.

[0054] The wireless communication unit 306 transmits and receives data to and from the access point 6 through wireless communication in accordance with a wireless communication protocol. As the wireless communication unit 306, for example, a well-known communication device conforming to the IEEE802.11 standard can be used. The mobile communication unit 307 is an interface for data communication via the communication network 400. As the mobile communication unit 307, for example, a well-known communication device for performing data communication via a mobile communication network can be used.

[0055] The auxiliary storage unit 303 stores a smartphone POS app AP301, which is one of the information processing programs. The smartphone POS app AP301 is an application program that describes information processing, which will be described later, for making the user terminal 300 function as a user interface for the store system 100. The smartphone POS app AP301 is used in common by multiple user terminals 300.

[0056] Now, for example, a general-purpose server device can be used as the hardware of the store server 1, the virtual POS server 2, or the mobile controller 3. The transfer of the store server 1, the virtual POS server 2, or the mobile controller 3 is generally performed in a state where the store management application AP11, the virtual POS application AP21, or the registration support application AP31 are stored in the auxiliary storage unit 13, 23, or 33, respectively, and the database group DB11, the transaction database DB21, or the transaction management database DB31 and the registration database DB32 are not stored. However, the hardware in a state where the store management application AP11, the virtual POS application AP21, or the registration support application AP31 are not stored in the auxiliary storage unit 13, 23, or 33, or in a state where a different version of the same application program is stored in the auxiliary storage unit 13, 23, or 33, and the store management application AP11, the virtual POS application AP21, or the registration support application AP31 may be transferred separately. Then, the store management application AP11, the virtual POS application AP21, or the registration support application AP31 may be written in the auxiliary storage unit 13, 23, or 33 in response to an operation by an arbitrary worker, thereby forming the store server 1, the virtual POS server 2, or the mobile controller 3. The store management application AP11, the virtual POS application AP21, or the registration support application AP31 may be transferred by recording it in a removable recording medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network. The transaction database DB21, or the transaction management database DB31 and the registration database DB32 are formed in the auxiliary storage unit 13, 23, or 33 by the processor 11, 21, or 31 executing information processing based on the store management application AP11, the virtual POS application AP21, or the registration support application AP31. At least a part of the databases included in the store management application AP11 and the database group DB11 may be stored in the main memory 12. At least a part of the virtual POS application AP21 and the transaction database DB21 may be stored in the main memory 22. At least a portion of the registration assistance application AP31, the transaction management database DB31, and the registration database DB32 may be stored in the main memory 32.

[0057] Next, the operation of the transaction processing system configured as described above will be described. Note that the contents of the various processes described below are merely examples, and it is possible to change the order of some of the processes, omit some of the processes, or add other processes as appropriate. For example, in the following description, in order to easily explain the characteristic operations of this embodiment, the description of some of the processes is omitted. For example, when some kind of error occurs, a process may be performed to deal with the error, but the description of some of such processes is omitted. The services provided to customers through the operation of the transaction processing system described below are referred to as smartphone POS services.

[0058] To use the smartphone POS service, the user terminal 300 exchanges data with the store system 100. The state of a flag included in the check-in data determines whether to use wireless communication with the access point 6 or wireless communication with the communication network 400 for this communication. However, in the following, for the sake of simplicity, a case will be described in which only wireless communication with the access point 6 is used. In addition, the state of a flag included in the check-in data determines whether to use a mode in which the payment machine 5 requests the mobile controller 3 to transfer data to the virtual POS server 2 to have the payment machine 5 perform a transaction, or a mode in which the mobile controller 3 transfers data to the payment machine 5 without a request from the payment machine 5. However, in the following, for the sake of simplicity, the mode in which the payment machine 5 requests the mobile controller 3 to transfer data is used as a fixed mode.

[0059] To use the smartphone POS service, a customer installs the smartphone POS app AP301 on a smartphone or the like that he or she owns, making it available as a user terminal 300. Alternatively, the customer borrows the user terminal 300 configured by installing the smartphone POS app AP301 on a tablet terminal or the like from a store. The customer then enters any store in which a store system 100 is installed, carrying the user terminal 300 with information processing based on the smartphone POS app AP301 activated.

[0060] In the user terminal 300, the processor 301 executes information processing as shown in FIGS. 9, 10, 11, 12, and 13 based on the smartphone POS application AP301. First, as ACT101 shown in Fig. 9, the processor 301 displays a main menu screen on the touch panel 304. The main menu screen is a screen for receiving a specification of one of several processes to be performed based on the smartphone POS application AP301. On the main menu screen, a plurality of GUI elements are arranged, including a GUI (graphical user interface) element for specifying the start of shopping. The GUI elements are, for example, soft keys.

[0061] In ACT 102, the processor 301 checks whether or not the start of shopping has been designated. If the processor 301 cannot confirm the designation, it determines NO and proceeds to ACT 103. In ACT 103, the processor 301 checks whether or not a designation other than the start of shopping has been made. If the processor 301 cannot confirm the designation, it determines NO and returns to ACT 102. Thus, the processor 301 waits for some designation on the main menu screen in ACT102 and ACT103. If a designation other than the start of shopping is made, the processor 301 judges YES in ACT103 and proceeds to the designated process. Note that a description of the process of the processor 301 in this case will be omitted.

[0062] When a customer enters a store and begins shopping, the customer performs a predetermined operation on the main menu screen to specify the start of shopping. When an operation for specifying the start of shopping is detected, for example, on the touch panel 304, the processor 301 judges YES in ACT102 and proceeds to ACT104. As ACT104, the processor 301 displays a scan screen for check-in on the touch panel 304. The scan screen for check-in is a screen that prompts the customer to read the two-dimensional code TC1 for check-in. The processor 301, for example, starts the camera 305, and generates the scan screen by superimposing on an image obtained by the camera 305 a text message that prompts the customer to read the two-dimensional code TC1 and a line that indicates the position where the two-dimensional code TC should be held.

[0063] When the scan screen is displayed on the touch panel 304, the customer points the camera 305 at the two-dimensional code TC1 posted near the store entrance so that the two-dimensional code TC1 appears on the scan screen. In ACT105, the processor 301 waits for the two-dimensional code to be read. At this time, the processor 301 repeatedly analyzes the image obtained by the camera 305 and attempts to read the two-dimensional code. The reading of the two-dimensional code may be performed as a process based on the smartphone POS app AP301, or may be performed as a process based on another application program for reading the two-dimensional code. Then, if the two-dimensional code is read, the processor 301 judges YES and proceeds to ACT106.

[0064] In ACT 106, the processor 301 checks whether the data represented by the read two-dimensional code is check-in data. If the data is not check-in data, the processor 301 determines NO and returns to ACT 105. At this time, the processor 301 may display on the touch panel 304 a screen notifying the customer that an incorrect two-dimensional code has been read.

[0065] If the processor 301 confirms that the data represented by the read two-dimensional code is check-in data, it judges YES in ACT106 and proceeds to ACT107. The processor 301 as ACT 107 stores the read check-in data in the main memory 302 or the auxiliary storage unit 303 .

[0066] As ACT108, the processor 301 requests the mobile controller 3 to check in. Specifically, the processor 301 establishes wireless communication between the wireless communication unit 306 and the access point 6 based on the data represented in the check-in data. For example, if a customer points the camera 305 at the two-dimensional code TC1A in the store A, the processor 301 establishes wireless communication with the access point 6 provided in the store system 100A based on the check-in data represented by the two-dimensional code TC1A. The processor 301 then transmits request data for requesting check-in to the mobile controller 3 via wireless communication with the access point 6. When wireless communication with the access point 6 provided in the store system 100A is established as described above, the request data is transmitted to the mobile controller 3 provided in the store system 100A via the access point 6 and the in-store communication network 7 provided in the store system 100A. The processor 301 includes identification data for identifying that the request is a check-in request and a terminal code in the request data for requesting check-in. If the customer is a registered user of the smartphone POS service and has a membership code, the processor 301 also includes the membership code in the request data. The membership code is stored, for example, in the auxiliary storage unit 303 of the user terminal 300. The processor 301 may also include other data, such as data for authenticating the customer, in the request data. Various requests from the user terminal 300 to the mobile controller 3 described below are realized, as described above, by sending request data including identification data for identifying the reason for the request from the user terminal 300 to the mobile controller 3 via the access point 6 and the in-store communication network 7.

[0067] When request data for requesting check-in is received via the communication interface 34, the processor 31 in the mobile controller 3 starts processing information related to a transaction with a customer who is checking in.

[0068] 14, 15, 16 and 17 are flowcharts of information processing by the processor 31. The processor 31 starts the information processing each time request data for requesting check-in is received by the communication interface 34. If information processing started based on another request is already being executed, the processor 31 starts new information processing in parallel with the other information processing. In other words, the processor 31 may execute multiple information processing in parallel, each of which is targeted at multiple user terminals 300. In the following, when the term "user terminal 300" is simply used, it refers to the user terminal 300 that is the target of information processing by the processor 31.

[0069] As ACT201 in FIG. 14, the processor 31 performs a check-in process. For example, the processor 31 requests the virtual POS server 2 to start a transaction and receives a notification of a transaction code. The processor 31 then adds a new data record DR1 in which the terminal code included in the request data is set in field F11 to the transaction management database DB31. If the request data includes a membership code, the processor 31 sets the membership code in field F12 of the new data record DR1. The processor 31 sets the notified transaction code in field F13 of the new data record DR1. The processor 31 also sets "0" as a confirmation required flag in field F14 of the new data record DR1. This starts management of the transaction performed using the user terminal 300 that requested the check-in.

[0070] When the processor 21 in the virtual POS server 2 receives a request from the mobile controller 3 to start a transaction, the processor 21 determines a transaction code according to a predetermined rule and starts a registration process of the purchased product in association with the transaction code. The processor 21 also notifies the mobile controller 3 of the determined transaction code.

[0071] In ACT202, the processor 31 checks whether or not the check-in process has been completed normally. If the check-in process could not be completed normally due to some abnormality, the processor 31 judges the result as NO and proceeds to ACT203. As ACT203, the processor 31 notifies the user terminal 300 of the error. For example, the processor 31 transmits notification data for notifying the error to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes identification data for identifying that the notification is an error notification in the notification data. The processor 31 may include an error code indicating the cause of the error in the notification data. In addition, various notifications from the mobile controller 3 to the user terminal 300 described below are realized, as described above, by sending notification data including identification data for identifying the reason for the notification from the mobile controller 3 to the user terminal 300 via the in-store communication network 7 and the access point 6.

[0072] On the other hand, if the check-in process is completed normally, the processor 31 judges YES in ACT202 and proceeds to ACT204. As ACT204, the processor 31 notifies the user terminal 300 of check-in completion. For example, the processor 31 transmits notification data for notifying the user terminal 300 of check-in completion via the in-store communication network 7 and the access point 6. The processor 31 includes identification data for identifying that the notification is a check-in completion notification in the notification data.

[0073] After the processor 301 in the user terminal 300 requests check-in in ACT 108 in FIG. In ACT109, the processor 301 checks whether or not the check-in completion has been notified. If the processor 301 cannot confirm the check-in completion, the processor 301 judges "NO" and proceeds to ACT110. In ACT110, the processor 301 checks whether or not a check-in error has been notified. If the processor 301 cannot confirm the notification, it determines NO and returns to ACT109. Thus, the processor 301 waits for a notification of check-in completion or an error in ACT109 and ACT110. If the notification data for the error notification described above is received by the wireless communication unit 306, the processor 301 determines YES in ACT110 and proceeds to ACT111.

[0074] In ACT111, the processor 301 displays an error screen on the touch panel 304. The error screen is a screen that is defined as a screen that notifies a guest that check-in is not possible. If an instruction to cancel the display of the error screen is given, for example, by operating a GUI element displayed on the error screen, the processor 301 returns to ACT101.

[0075] On the other hand, if the notification data for notifying the completion of check-in is received by the wireless communication unit 306, the processor 301 judges YES in ACT 109 and proceeds to ACT 112 in FIG. As ACT 112, the processor 301 displays a list screen on the touch panel 304. The list screen is a screen that displays a list of registered purchased products.

[0076] FIG. 18 is a diagram showing an example of the list screen SC1. List screen SC1 includes display areas AR11, AR12 and buttons BU11, BU12, and BU13. Display area AR11 shows the total number of purchased items and the total price of the purchased items. Display area AR12 shows a list of purchased items. Button BU11 is a soft key that allows the customer to declare that he / she wants to cancel all purchased items and stop shopping. Button BU12 is a soft key that allows the customer to declare that he / she wants to start scanning items to be registered as purchased items. Button BU13 is a soft key that allows the customer to declare that he / she wants to start checkout.

[0077] 18 shows the list screen SC1 in a state where no purchased products have been registered yet. Therefore, the total number and total amount are both shown as "0" in the display area AR11, and nothing is shown in the display area AR12.

[0078] In ACT113 in Fig. 10, the processor 301 checks whether or not the start of scanning of the product has been designated. If the processor 301 cannot confirm the designation, it determines NO and proceeds to ACT114. In ACT114, the processor 301 checks whether or not a change in the quantity has been specified. If the processor 301 cannot confirm the specification, it determines NO and proceeds to ACT115. In ACT 115, the processor 301 checks whether or not a shopping cancellation has been specified. If the processor 301 cannot confirm the specified cancellation, it determines NO and proceeds to ACT 116. In ACT 116, the processor 301 checks whether or not the start of a transaction has been designated. If the processor 301 cannot confirm that a transaction has been started, it determines that the result is NO and returns to ACT 113. Thus, in ACT113 to ACT116, the processor 301 waits for any one of the following to be specified: start of scan, quantity, stop, or start of accounting.

[0079] If the customer wishes to register the product as a purchased product, the customer designates the start of scanning by a predetermined operation such as touching a button BU12 on the list screen SC1. In response to this, the processor 301 determines YES in ACT113 and proceeds to ACT117. As ACT 117, the processor 301 displays a registration screen on the touch panel 304. The registration screen is a screen that prompts the customer to read a barcode that represents the product code of the product to be registered as a purchased product.

[0080] FIG. 19 is a diagram showing an example of the registration screen SC2. The registration screen SC2 includes a display area AR21, a message ME21, and a button BU21. The display area AR21 displays an image captured by the camera 305. The message ME21 is a text message that prompts the customer to read the barcode of the product. The button BU21 is a soft key that allows the customer to declare that he or she wishes to stop scanning the product code.

[0081] The processor 301, for example, activates the camera 305, which then overlays an image obtained by the camera 305 with a line indicating the range of the display area AR21, and an image showing the message ME21 and the button BU21, to generate the registration screen SC2.

[0082] In ACT118 in Fig. 10, the processor 301 checks whether the barcode has been read. At this time, the processor 301 analyzes the image obtained by the camera 305 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS app AP301, or may be performed as a process based on another application program for reading barcodes. Then, if the barcode cannot be read, the processor 301 judges NO and proceeds to ACT119. In ACT 119, the processor 301 checks whether or not the suspension of scanning has been specified. If the processor 301 cannot confirm the specified suspension, it determines "NO" and returns to ACT 118. Thus, in ACT118 and ACT119, the processor 301 waits for the barcode to be read or for a command to stop scanning to be issued. If the customer wishes to return to the list screen without performing the current scan, the customer designates the cancellation of the scan by a predetermined operation such as touching the button BU21. In response to this, the processor 301 judges YES in ACT119 and returns to ACT112.

[0083] When the registration screen is displayed on the touch panel 304, the customer aims the camera 305 at the product to be registered as a purchased product so that the barcode displayed on the product is reflected in the display area AR21. In response to this, the processor 301 judges YES in ACT118 and proceeds to ACT120. As ACT 120, the processor 301 requests registration from the mobile controller 3. The request data transmitted by the processor 301 here includes data represented by the read barcode (hereinafter referred to as barcode data).

[0084] After notifying the user that check-in is complete in ACT204 in FIG. 14, the processor 31 in the mobile controller 3 proceeds to ACT205. In ACT205, the processor 31 checks whether or not a registration has been requested. If the processor 31 cannot confirm the request, it determines NO and proceeds to ACT206.

[0085] In ACT206, the processor 301 checks whether or not a quantity change has been requested. If the processor 301 cannot confirm the request, it determines NO and proceeds to ACT207. In ACT207, the processor 31 checks whether a request to delete a purchased item has been made. If the processor 31 cannot confirm the request, it determines that the result is NO, and proceeds to ACT208. In ACT208, the processor 31 checks whether or not a request to cancel the purchased item has been made. If the processor 31 cannot confirm the request, it determines that the result is NO, and proceeds to ACT209. In ACT209, the processor 31 checks whether or not a payment request has been made. If the processor 31 cannot confirm the request, it determines that the payment request has been made as NO, and returns to ACT205. Thus, the processor 31 waits for any of the following requests in ACT205 to ACT209: registration, quantity change, deletion, cancellation, or payment. If registration is requested from the user terminal 300 as described above, the processor 31 judges YES in ACT205 and proceeds to ACT210 in FIG.

[0086] As ACT 210, the processor 31 transfers a registration request together with a notification of the transaction code of the transaction being processed to the virtual POS server 2. At this time, the processor 31 may transfer the request data sent from the user terminal 300 to the virtual POS server 2 as is, or may transmit the request data after being converted by some processing to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the barcode data included in the request data sent from the user terminal 300.

[0087] In the virtual POS server 2, the processor 21 assumes that the barcode data included in the request data sent from the mobile controller 3 has been read by a barcode scanner provided in the existing POS terminal, and attempts to register the purchased item by the same process as the existing POS terminal. However, for some reason, the item code represented by the barcode data may not be registered in the item database. Also, a barcode other than the one representing the item code may be displayed on the item. In these cases, the processor 21 cannot register the purchased item and issues an error. In this way, the processor 21 registers the purchased item based on the reading of the barcode representing the item code registered in the item database. In this way, the processor 21 executes information processing based on the virtual POS application AP21, and the computer with the processor 21 as the central part functions as a registration means. The processor 21 manages the purchased items using the transaction database DB21.

[0088] The processor 21 transmits result data indicating the results of such processing to the mobile controller 3. If the registration of the purchased item was performed correctly, the processor 21 includes in the result data identification data for identifying that the notification is a valid registration, and the product code, product name, and price of the registered product. If the processor 21 determines that there is an error, the processor 21 includes in the result data identification data for identifying that the notification is an error, and the barcode data sent in the registration request.

[0089] After transferring the registration request in ACT210, the processor 31 in the mobile controller 3 proceeds to ACT211. The processor 31, as ACT 211, acquires the result data transmitted from the virtual POS server as described above. The processor 31 stores the acquired result data in the main memory 32 or the auxiliary storage unit 33.

[0090] In ACT 212, the processor 31 updates the registration database DB 32 based on the result data. The registration database DB 32 is updated, for example, as follows.

[0091] First case: This is a notification of a valid registration, and the data record DR2 associated with the transaction being processed does not contain any registration data containing the notified product code. In this case, processor 31 adds a new field next to the last field already existing in data record DR2 associated with the transaction being processed, and adds new registration data to that field. Processor 31 includes in the new registration data the notified product code, an error flag set to "0" indicating no error, the notified product name and price, the quantity set to "1", and a cancellation flag set to "0" indicating no cancellation. Thus, the registration data added in this case has the structure shown in the upper right corner of Figure 6.

[0092] Second case: This is a notification of a valid registration, and the data record DR2 associated with the transaction being processed contains registration data including the notified product code, but the cancellation flag for that registration data is set to "1", indicating that it has been cancelled. In this case, processor 31 proceeds in the same manner as in the first case above.

[0093] Third case: This is a notification of a valid registration, and the data record DR2 associated with the transaction being processed contains registration data including the notified product code, and the cancellation flag for that registration data is set to "0". In this case, the processor 31 rewrites the value of the quantity included in the registration data that includes the notified product code and has the cancellation flag set to "0" to a value that is one larger.

[0094] Fourth case: It is an error notification. In this case, processor 31 adds a new field next to the last field already existing in data record DR2 associated with the transaction being processed, and adds new registration data to that field. Processor 31 includes in the new registration data the notified barcode data and an error flag set to "1" indicating an error. Thus, the registration data added in this case has the structure shown in the lower right of Figure 6.

[0095] By updating the registration database DB32 by the processor 31 in this manner, the registration database DB32 not only shows a list of purchased items already registered in the virtual POS server 2, but also records barcode reading errors. The processor 31 may store the barcode data sent in the registration request in the main memory 32 or the auxiliary storage unit 33, and in the above case 4, may include this stored barcode data in the registration data. In this case, the processor 21 in the virtual POS server 2 may not include the barcode data in the result data. The processor 31 may also extract a product code from the stored barcode data, and perform the processes in the first to third cases based on this product code. The processor 31 may also obtain the product name and price from the store server 1, etc., based on the product code.

[0096] In ACT213, the processor 31 checks whether the current registration was performed properly. If the result data indicates an error, for example, the processor 31 determines NO and proceeds to ACT214. In ACT214, the processor 31 rewrites the confirmation required flag set in field F14 to "1" for the data record DR1 with which the transaction being processed is associated in the transaction management database DB31. The processor 31 may write "1" regardless of the state before the rewrite, or may leave it as it is if the state before the rewrite is "1". For example, if the result data indicates a valid registration, the processor 31 determines YES in ACT213 and proceeds to ACT215. In ACT215, the processor 31 checks whether the confirmation required flag set in the field F14 of the data record DR1 with which the transaction to be processed is associated in the transaction management database DB31 is "1". If the confirmation required flag is not "1", the processor 31 judges the result as NO and proceeds to ACT216.

[0097] In ACT216, the processor 31 checks whether the currently registered purchased item is a confirmation-required item. If the item is not a confirmation-required item, the processor 31 judges NO and proceeds to ACT217. Note that the processor 31 also proceeds to ACT217 if the confirmation-required flag is rewritten to "1" in ACT214, or if the confirmation-required flag is set to "1" and the processor 31 judges YES in ACT215.

[0098] In ACT217, the processor 31 instructs the user terminal 300 to display a list screen. For example, the processor 31 transmits instruction data including identification data for identifying that the instruction is to display a list screen to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity included in the data record DR2 with which the transaction to be processed is associated in the registration database DB32. If the current registration is an error, the processor 31 also includes error data indicating that fact in the instruction data. Then, the processor 31 returns to the standby state of ACT205 to ACT209 in FIG. 14. Various instructions from the mobile controller 3 to the user terminal 300 described below are realized by sending instruction data including identification data for identifying the reason for the instruction from the mobile controller 3 to the user terminal 300 via the in-store communication network 7 and the access point 6, as described above.

[0099] On the other hand, if the processor 31 determines YES in ACT216 because the product is a product that requires confirmation, the processor 31 proceeds to ACT218. In other words, if the officially registered product is a product that requires confirmation and the confirmation flag is "0", the processor 31 proceeds to ACT218. In ACT218, the processor 31 rewrites the confirmation required flag set in the field F14 of the data record DR1 with which the transaction to be processed is associated in the transaction management database DB31 to "1".

[0100] In ACT218, the processor 31 instructs the user terminal 300 to display a guidance screen. The processor 31 includes in the instruction data for instructing the display of the guidance screen the product code, product name, price, and quantity contained in the data record DR2 to which the transaction to be processed is associated in the registration database DB32. Then, the processor 31 returns to the standby state of ACT205 to ACT209 in FIG.

[0101] After the processor 301 in the user terminal 300 requests registration in ACT 120 in FIG. 10, the process proceeds to ACT 121 in FIG. In ACT 121, the processor 301 checks whether or not a command to display a guidance screen has been issued. If the command has not been issued, the processor 301 determines that the command has been issued and proceeds to ACT 122. In ACT 122, the processor 301 checks whether or not a command to display the list screen has been issued. If the command has not been issued, the processor 301 determines that the command has been issued and returns to ACT 121.

[0102] Thus, the processor 301 waits for an instruction to display a guidance screen or a list screen in ACT 121 and ACT 122. Then, when the processor 301 receives an instruction to display the list screen from the mobile controller 3 as described above, the processor 301 determines YES in ACT 122, returns to ACT 112 in Fig. 10, and causes the list screen SC1 to be displayed again on the touch panel 304. At this time, the processor 301 sets the list screen SC1 to a screen showing the product name, price, and quantity of the purchased product included in the instruction data.

[0103] FIG. 20 is a diagram showing an example of the list screen SC1 in a state where purchased products have already been registered. The list screen SC1 shown in FIG. 20 is an example of a case where one product with the product name "AAA" and a price of 120 yen, two products with the product name "BBB" and a price of 98 yen, and one product with the product name "CCC" and a price of 1,024 yen have been registered as purchased products. None of these products are products that require confirmation. In the list screen SC1 shown in FIG. 20, the display area AR12 shows the product name, price, and quantity of these registered products. The display area AR11 shows the total number "4" and the total amount "1,340". The area surrounded by a dashed line to the left of the product name shows an area for displaying an icon. The dashed line showing this area is not actually shown on the list screen SC1.

[0104] FIG. 21 is a diagram showing an example of the list screen SC1 in a state where purchased products have already been registered. The list screen SC1 shown in FIG. 21 is an example in which the following items have been registered as purchased: one item with the product name "AAA" and a price of 120 yen, two items with the product name "BBB" and a price of 98 yen, one item with the product name "CCC" and a price of 1,024 yen, and one item with the product name "DDD" and a price of 380 yen. The item with the product name "DDD" is a product that requires confirmation. In the list screen SC1 shown in FIG. 21, the display area AR12 displays the product name, price, and quantity of these registered products. The display area AR11 also displays "5" as the total number and "1,720" as the total amount. Next to the product name "DDD", an icon IC11 is displayed indicating that the product has an age restriction for purchasers.

[0105] On the other hand, if the processor 301 receives an instruction from the mobile controller 3 to display a guidance screen as described above, the processor 301 judges YES in ACT 121 in FIG. 11 and proceeds to ACT 123. In ACT 123, the processor 301 displays a guidance screen on the touch panel 304. The guidance screen is a screen for informing a customer that confirmation by a store clerk is required at the time of payment.

[0106] FIG. 22 is a diagram showing an example of the guidance screen SC3. Guidance screen SC3 is a screen that displays list screen SC1 with window WI31 superimposed thereon. Window WI31 includes message ME31 and button BU31. Message ME31 is a text message indicating that confirmation by a store clerk is required at the time of payment. Button BU31 is a soft key that allows the customer to declare that they have confirmed the guidance on guidance screen SC3. Processor 301 generates list screen SC1 that displays the product name, price, and quantity of the purchased product included in the instruction data, and generates guidance screen SC3 by superimposing window WI31 on it.

[0107] When the customer confirms the guidance on the guidance screen SC3, the customer declares that he / she has confirmed the information by a predetermined operation such as touching a button BU31 on the guidance screen SC3. In response to this, the processor 301 returns from ACT123 in Fig. 11 to ACT112 in Fig. 10, and causes the list screen SC1 to be displayed again on the touch panel 304. Note that the processor 301 may return from ACT123 to ACT112 when the elapsed time while the guidance screen SC3 is displayed reaches a predetermined time.

[0108] When a customer touches an area on the list screen SC1 that shows the quantity, the processor 301 displays a list box for specifying the quantity overlaid on the list screen SC1. When this list box is operated, the processor 301 receives this as a specification of the quantity. In this case, the processor 301 judges YES in ACT114 in FIG. 10 and proceeds to ACT124 in FIG. 11.

[0109] In ACT124, the processor 301 checks whether the designated number is 0. If the designated number is not 0, the processor 301 determines NO and proceeds to ACT125. As ACT125, the processor 301 requests the mobile controller 3 to change the quantity. The request data transmitted by the processor 301 here includes specific data for identifying the product whose quantity is specified and the specified number. The specific data may be a product code, or may be data that can identify the purchased product only on the mobile controller 3, such as a number for identifying each purchased product in a list of purchased products. If a product code is used as the specific code, the processor 31 includes the product code for each purchased product in the instruction data for instructing the display of a list screen or the instruction data for instructing the display of a guidance screen.

[0110] If a quantity change is requested from the user terminal 300 as described above, the processor 31 in the mobile controller 3 judges YES in ACT 206 in FIG. 14, and proceeds to ACT 220 in FIG. As ACT220, the processor 31 transfers a quantity change request to the virtual POS server 2, along with a notification of the transaction code of the transaction being processed. At this time, the processor 31 may transfer the request data sent from the user terminal 300 directly to the virtual POS server 2, or may send the request data to the virtual POS server 2 after conversion through some kind of processing. However, the processor 31 notifies the virtual POS server 2 of the quantity included in the request data sent from the user terminal 300. Furthermore, if the specific data included in the request data is not a product code, the processor 31 replaces the specific data with the product code.

[0111] The processor 21 in the virtual POS server 2 assumes that the quantity included in the request data sent from the mobile controller 3 is input by an input device provided in the existing POS terminal, and changes the quantity of the purchased item by the same process as the existing POS terminal. The processor 21 transmits result data indicating the item code of the item whose quantity has been changed and the changed quantity to the mobile controller 3.

[0112] After transferring the quantity change request in ACT220, the processor 31 in the mobile controller 3 proceeds to ACT221. The processor 31 as ACT 221 acquires the result data transmitted from the virtual POS server 2 as described above. The processor 31 stores the acquired result data in the main memory 32 or the auxiliary storage unit 33.

[0113] In ACT222, the processor 31 updates the registration database DB32 based on the result data. That is, the processor 31 finds the registration data including the notified product code from the data record DR2 associated with the transaction being processed. The processor 31 then rewrites the quantity included in the corresponding registration data to the quantity included in the result data.

[0114] The processor 31 may store the specific data and the number of items sent in the quantity change request data in the main memory 32 or the auxiliary storage unit 33, and upon receiving result data indicating that the update is complete, rewrite the number of items in the registered data related to the product specified by the stored specific data to the stored number. In this case, the processor 21 in the virtual POS server 2 does not need to include the product code and the number of items in the result data.

[0115] In ACT223, the processor 31 instructs the user terminal 300 to display a list screen. For example, the processor 31 transmits instruction data including identification data for identifying that the instruction is to display a list screen to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity included in the registration data whose cancellation flag is "0" among the registration data included in the data record DR2 updated as described above. The processor 31 then returns to the standby state of ACT205 to ACT209 in FIG. 14.

[0116] Now, if the designated number is 0, the processor 301 in the user terminal 300 judges YES in ACT124 of FIG. 11 and proceeds to ACT126. As ACT 126, the processor 301 displays a delete screen on the touch panel 304. The delete screen is a screen that notifies the customer that the product for which the quantity has been specified to be set to 0 will be deleted from the purchased products. The delete screen includes a delete button for specifying the deletion, and a back button for specifying returning to the state before the quantity change was specified without changing the quantity.

[0117] In ACT 127, the processor 301 checks whether or not deletion has been specified. If the processor 301 cannot confirm the specification, it determines NO and proceeds to ACT 128. In ACT 128, the processor 301 checks whether or not a return has been specified. If the processor 301 cannot confirm the specified return, it determines NO and returns to ACT 127. Thus, the processor 301 waits for a deletion or return to be specified as ACT127 and ACT128.

[0118] If the customer wishes to cancel the deletion and return to the state before the change in quantity was specified, the customer specifies "back" by a predetermined operation such as touching the back button on the deletion screen. In response to this, the processor 301 judges YES in ACT128, returns to ACT112 in Fig. 10, and causes the list screen SC1 to be displayed again on the touch panel 304. In this case, since the registration state of the purchased product is not changed, the processor 301 causes the touch panel 304 to display again the list screen SC1 in the same state as that displayed before the deletion screen was displayed.

[0119] If the customer is sure that the content should be deleted, he or she designates the deletion by a predetermined operation such as touching the delete button on the delete screen. In response to this, the processor 301 judges YES in ACT127 and proceeds to ACT129. In ACT 129, the processor 301 requests the mobile controller 3 to delete the product. The request data transmitted by the processor 301 includes specification data for specifying the product designated for deletion.

[0120] If a deletion request is received from the user terminal 300 as described above, the processor 31 in the mobile controller 3 judges YES in ACT 207 in FIG. 14, and proceeds to ACT 224 in FIG. As ACT224, the processor 31 transfers a deletion request together with a notification of the transaction code of the transaction being processed to the virtual POS server 2. At this time, the processor 31 may transfer the request data sent from the user terminal 300 to the virtual POS server 2 as is, or may transmit the request data after being converted by some processing to the virtual POS server 2. However, if the specific data included in the request data is not a product code, the processor 31 replaces the specific data with the product code.

[0121] In the virtual POS server 2, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a deletion instruction inputted by an input device provided in the existing POS terminal, and removes the target product from the purchased products by the same process as the existing POS terminal. The processor 21 transmits result data indicating the product codes of the products removed from the purchased products to the mobile controller 3.

[0122] After transferring the deletion request in ACT224, the processor 31 in the mobile controller 3 proceeds to ACT225. The processor 31, as ACT 225, acquires the result data transmitted from the virtual POS server as described above. The processor 31 stores the acquired result data in the main memory 32 or the auxiliary storage unit 33.

[0123] In ACT226, the processor 31 updates the registration database DB32 based on the result data. That is, the processor 31 finds the registration data including the notified product code from the data record DR2 associated with the transaction being processed. The processor 31 then changes the cancellation flag included in the corresponding registration data to "1."

[0124] The processor 31 may store the specific data sent in the deletion request data in the main memory 32 or the auxiliary storage unit 33, and upon receiving result data indicating that the deletion is complete, change the cancellation flag of the registered data related to the product specified by the stored specific data. In this case, the processor 21 in the virtual POS server 2 does not need to include the product code in the result data.

[0125] In ACT 227, the processor 301 checks whether the deleted product is a product that requires confirmation. If the deleted product is a product that requires confirmation, the processor 301 judges that the result is YES and proceeds to ACT 228. In ACT 228, the processor 301 checks whether or not there are other items requiring confirmation among the purchased items in the transaction being processed. If there are no such items, the processor 301 determines NO and proceeds to ACT 229. In other words, the processor 301 proceeds to ACT 229 if the purchased items do not include any items requiring confirmation due to the current item deletion.

[0126] In ACT 229, the processor 301 changes the confirmation required flag set in the field F14 of the data record DR1 with which the transaction being processed is associated in the transaction management database DB31 to "0." In ACT230, the processor 31 instructs the user terminal 300 to display a list screen. For example, the processor 31 transmits instruction data including identification data for identifying that the instruction is to display a list screen to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity included in the registration data whose cancellation flag is "0" among the registration data included in the data record DR2 updated as described above. The processor 31 then returns to the standby state of ACT205 to ACT209 in FIG. 14. If the processor 31 determines NO in ACT227 because the deleted product is not a product that requires confirmation, or if the processor 31 determines YES in ACT228 because there is another product that requires confirmation, the processor 31 skips ACT229 and ACT230 and returns to the standby state of ACT205 to ACT209 in FIG. 14.

[0127] Now, after the processor 301 in the user terminal 300 requests a quantity change in ACT125, or after requesting a deletion in ACT129, the processor 301 proceeds to ACT130. In ACT130, the processor 301 waits for an instruction to display the list screen. If an instruction to display the list screen is given from the mobile controller 3 in response to a request to change the quantity or a request to delete, the processor 301 judges YES and returns to ACT112 in FIG. 10, where the processor 301 causes the touch panel 304 to display the list screen SC1 again. At this time, the processor 301 sets the list screen SC1 to a screen showing the product name, price, and quantity of the purchased product included in the instruction data. In this case, since the registration state of the purchased product is changed, the processor 301 causes the touch panel 304 to display the list screen SC1 showing a purchased product different from the one displayed when the quantity change or deletion was specified.

[0128] If the customer wishes to cancel all the purchased items already registered and to stop shopping, the customer designates the cancellation by a predetermined operation such as touching a button BU11 on the list screen SC1. In response to this, the processor 301 judges YES in ACT115 and proceeds to ACT131 in FIG. As ACT131, the processor 301 displays a cancel screen on the touch panel 304. The cancel screen is a screen that notifies the customer that all of the purchased items that have already been registered will be canceled. The cancel screen includes an execute button for specifying execution of the cancel, and a back button for specifying returning to the state before the quantity change was specified without changing the quantity.

[0129] In ACT 132, the processor 301 checks whether or not cancel execution has been specified. If the processor 301 cannot confirm the specification, it determines NO and proceeds to ACT 133. In ACT 133, the processor 301 checks whether or not a return has been specified. If the processor 301 cannot confirm the specified return, it determines NO and returns to ACT 132. Thus, the processor 301 waits for cancellation or return to be specified as ACT 132 and ACT 133 .

[0130] If the customer wishes to continue shopping, the customer specifies "Back" by a predetermined operation such as touching a back button on the cancellation screen. In response to this, the processor 301 judges YES in ACT133, returns to ACT112 in Fig. 10, and causes the list screen SC1 to be displayed again on the touch panel 304. In this case, since the registration status of the purchased item is not changed, the processor 301 causes the touch panel 304 to display again the list screen SC1 in the same state as that displayed before the cancellation screen was displayed.

[0131] If the customer wishes to cancel the purchase, he or she designates cancellation execution by a predetermined operation such as touching an execution button on the cancellation screen. In response to this, the processor 301 judges YES in ACT132 and proceeds to ACT134. As ACT 134 , the processor 301 requests the mobile controller 3 to cancel.

[0132] If a cancellation request is received from the user terminal 300 as described above, the processor 31 in the mobile controller 3 judges YES in ACT 208 in FIG. 14, and proceeds to ACT 231 in FIG. The processor 31 as ACT 231 transfers a request for cancellation together with a notification of the transaction code of the transaction being processed to the virtual POS server 2. At this time, the processor 31 may transfer the request data sent from the user terminal 300 to the virtual POS server 2 as is, or may transmit the request data converted by some processing to the virtual POS server 2.

[0133] In the virtual POS server 2, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a cancellation instruction inputted by an input device provided in the existing POS terminal, and removes all registered products associated with the notified transaction code from the purchased products by processing similar to that of the existing POS terminal. The processor 21 transmits result data indicating that the cancellation has been completed to the mobile controller 3.

[0134] After the processor 31 in the mobile controller 3 transfers the deletion request in ACT231, the processor 31 proceeds to ACT232. The processor 31 as the ACT 232 acquires the result data transmitted from the virtual POS server as described above. The processor 31 stores the acquired result data in the main memory 32 or the auxiliary storage unit 33.

[0135] In ACT233, the processor 31 updates the registration database DB32 based on the result data described above. That is, the processor 31 changes the cancellation flags that are set to "0" to "1" for all of the registration data included in the data record DR2 associated with the transaction being processed.

[0136] In ACT234, the processor 301 changes the confirmation required flag set in the field F14 of the data record DR1 with which the transaction being processed is associated in the transaction management database DB31 to "0." In ACT235, the processor 31 notifies the user terminal 300 of the cancellation. Then, the processor 31 thereafter returns to the standby state of ACT205 to ACT209 in FIG.

[0137] Now, after the processor 301 in the user terminal 300 requests cancellation in ACT134, the process proceeds to ACT135. In ACT135, the processor 301 waits for a cancellation notification from the mobile controller 3. Then, the processor 301 determines YES if a cancellation notification is received as described above, and returns to ACT101 in FIG.

[0138] When the customer has finished registering all the products he or she wishes to purchase as purchased products, the customer proceeds to payment. At this time, the customer specifies the start of the transaction by a predetermined operation such as touching button BU13 on the list screen SC1. In response to this, the processor 301 judges YES in ACT116 in FIG. 10 and proceeds to ACT136. As ACT 136 , the processor 301 requests accounting from the mobile controller 3 .

[0139] If a payment request is received from the user terminal 300 as described above, the processor 31 in the mobile controller 3 judges YES in ACT 209 in FIG. 14, and proceeds to ACT 236 in FIG. In ACT236, the processor 31 checks whether the confirmation required flag set in field F14 of the data record DR1 associated in the transaction management database DB31 with the transaction being processed is "1". If the confirmation required flag is "1", the processor 31 judges YES and proceeds to ACT237. In other words, the processor 31 proceeds to ACT237 if the purchased items include a confirmation required item or if there is an item that has not been registered correctly. In the following, the state in which the confirmation required flag is "1" is referred to as a confirmation required state. In ACT 237, the processor 31 instructs the user terminal 300 to display a confirmation screen.

[0140] After the processor 301 in the user terminal 300 requests payment in ACT 136 in FIG. In ACT 137, the processor 301 checks whether or not a command to display a confirmation screen has been issued. If the command has not been issued, the processor 301 judges the result to be NO and proceeds to ACT 138. In ACT 138, the processor 301 checks whether or not an instruction to display the accounting screen has been issued. If the instruction has not been issued, the processor 301 judges the result to be NO and returns to ACT 137. Thus, the processor 301 waits for an instruction to display a confirmation screen or a checkout screen in ACT 137 and ACT 138. Then, if an instruction to display a confirmation screen is received from the mobile controller 3 as described above, the processor 301 judges YES in ACT 137 and proceeds to ACT 139 in FIG. The processor 301 displays a confirmation screen in ACT 139. The confirmation screen is a screen for urging the customer to contact a store clerk to confirm the confirmation-required product.

[0141] FIG. 23 is a diagram showing an example of the confirmation screen SC4. The confirmation screen SC4 is a screen in which a window WI41 is superimposed on the list screen SC1 that was displayed immediately before. The window WI41 includes a message ME41 and buttons BU41 and BU42. The message ME41 is a text message indicating that confirmation by a store clerk is required. The button BU41 is a soft key that allows the customer to specify that confirmation by a store clerk should be received. The button BU42 is a soft key that allows the customer to specify that return to product registration.

[0142] If the customer decides to have the store clerk confirm the transaction, the customer designates the confirmation by a predetermined operation such as touching button BU41. If the customer decides to cancel the transaction and return to product registration, the customer designates the return by a predetermined operation such as touching button BU42.

[0143] The processor 301 checks whether confirmation has been specified in ACT140 of Fig. 12. If the processor 301 cannot confirm the specification, it determines NO and proceeds to ACT141. In ACT141, the processor 301 checks whether or not a return has been specified. If the processor 301 cannot confirm the specified return, it determines NO and returns to ACT140. Thus, the processor 301 waits for confirmation or return to be specified in ACT140 and ACT141. If confirmation is specified as described above, the processor 301 determines YES in ACT140 and proceeds to ACT142.

[0144] As ACT 142, the processor 301 displays a release screen on the touch panel 304. The release screen is a screen for making the user terminal 300 read a barcode for releasing the confirmation required state.

[0145] FIG. 24 is a diagram showing an example of the release screen SC5. The release screen SC5 includes a display area AR51, a message ME51, and a button BU51. The display area AR51 displays an image captured by the camera 305. The message ME51 is a text message that prompts the store clerk to read a barcode for releasing the confirmation-required state. The button BU51 is a soft key that allows the customer or the store clerk to declare that scanning of the release barcode is to be stopped. The processor 301, for example, activates the camera 305, which then superimposes an image obtained by the camera 305 with a line indicating the range of the display area AR51, a message ME51, and an image indicating the button BU51, to generate the release screen SC5.

[0146] The customer asks the store clerk for confirmation. For example, if the purchased items include a product that needs to be confirmed, the store clerk confirms that the sale of the product that needs to be confirmed is permitted. In addition, for example, the store clerk checks the products held by the customer and confirms that no unregistered products are included. If all of these conditions are met, the store clerk determines that the payment is permitted and holds the release barcode over the camera 305 so that the release barcode is reflected in the display area AR51. For this operation, the store clerk carries a card or the like on which the release barcode is printed. Alternatively, the store clerk displays the release barcode on the screen of an information terminal carried by the store clerk. Preferably, a different release barcode is used for each store or business. However, it is permitted that the same release barcode is used at different stores or different businesses. In addition, by changing the regular release barcode, for example, every day, it is possible to prevent fraud in the case where the release barcode is obtained by a customer for some reason.

[0147] If the sales clerk confirms that the sale of the confirmation-required product is not permitted or that the customer has an unregistered product, the sales clerk designates a return to product registration by a predetermined operation such as touching button BU51. Alternatively, if the customer decides to return to product registration without asking the sales clerk for confirmation, the customer designates a return to product registration by a predetermined operation such as touching button BU51. Subsequent actions regarding the confirmation-required product or unregistered product may be taken by the customer or a store clerk as appropriate. For example, the customer operates the user terminal 300 to cancel the confirmation-required product from the list of purchased products. For example, the customer performs a procedure to make the confirmation-required product available for purchase. For example, the customer performs an operation on the user terminal 300 to register the unregistered product as a purchased product by reading a barcode representing the product code of the unregistered product. For example, the store clerk performs an operation to register the unregistered product as a purchased product by using a special operation for store clerks on the user terminal 300 or an operation on a terminal for store clerks. For example, the store clerk collects the unregistered product. In this case, if necessary, the store clerk takes action to register the product code of the product in the product database.

[0148] In ACT143, the processor 301 checks whether the barcode has been read. At this time, the processor 301 analyzes the image obtained by the camera 305 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS app AP301, or may be performed as a process based on another application program for reading barcodes. If the barcode cannot be read, the processor 301 determines NO and proceeds to ACT144. In ACT 144, the processor 301 checks whether or not a return has been specified. If the processor 301 cannot confirm the specified return, it determines NO and returns to ACT 143. Thus, in ACT143 and ACT144, the processor 301 waits for the bar code to be read or for a return to be specified.

[0149] If return is specified as described above, the processor 301 judges YES in ACT144 and proceeds to ACT145. Note that if return is specified as described above while the confirmation screen SC4 is being displayed on the touch panel 304, the processor 301 judges YES in ACT141 and proceeds to ACT145. In ACT145, the processor 301 requests the mobile controller 3 to return to product registration. Then, the processor 301 returns to ACT112 in FIG.

[0150] After the processor 31 in the mobile controller 3 issues an instruction to display the confirmation screen in ACT 237 in FIG. In ACT 238, the processor 31 checks whether or not a release has been requested. If the request cannot be confirmed, the processor 31 judges the result as NO and proceeds to ACT 239. In ACT 239, the processor 31 checks whether a return has been requested. If the request cannot be confirmed, the processor 31 determines NO and returns to ACT 238. Thus, the processor 31 waits for a request for release or return in ACT238 and ACT239. Then, if a request to return to product registration is received from the user terminal 300 as described above, the processor 31 judges YES in ACT239 and returns to the standby state of ACT205 to ACT209 in FIG. That is, both the mobile controller 3 and the user terminal 300 return to a state in which product registration is performed.

[0151] On the other hand, in the user terminal 300, if a barcode appears in the image captured by the camera 305, the processor 301 determines YES in ACT143 in FIG. 12 and proceeds to ACT146. As ACT 146 , the processor 301 stores the barcode data represented by the read barcode in the main memory 302 or the auxiliary storage unit 303 .

[0152] In ACT147, the processor 301 requests the mobile controller 3 to release the confirmation-required state. The request data transmitted by the processor 301 includes the barcode data stored above. The request data transmitted by the processor 301 also includes the authentication data included in the check-in data stored in ACT107 in FIG. 9.

[0153] When a release request is made from the user terminal 300 to the mobile controller 3 in this manner, the processor 31 in the mobile controller 3 judges YES in ACT238 in FIG. 17, and proceeds to ACT240. As ACT240, the processor 31 performs authentication processing. For example, the processor 31 extracts barcode data and authentication data from the request data and stores them in the main memory 32 or the auxiliary storage unit 33. In this way, the processor 31 executes information processing based on the smartphone POS app AP31, and the computer with the processor 31 as the central part functions as an acquisition means. Then, the processor 31 performs processing to confirm whether the read barcode is a genuine barcode for unlocking based on the barcode data and authentication data acquired in this way. This authentication processing can be performed, for example, by any of the following methods.

[0154] (1) If the barcode data and the authentication data match, processor 31 determines that a genuine barcode for release has been read. (2) Processor 31 processes the barcode data using a predetermined algorithm, and if the resulting data matches the authentication data, it determines that a genuine barcode for release has been read. (3) Processor 31 processes the authentication data using a predetermined algorithm, and if the resulting data matches the barcode data, it determines that a genuine barcode for release has been read. (4) Processor 31 processes the barcode data with a first predetermined algorithm, processes the authentication data with a second predetermined algorithm, and if the two resulting data match each other, determines that a genuine unlock barcode has been read. Any other process can be applied to confirm that the barcode data and the authentication data have a predetermined relationship. If the processor can confirm that the barcode data and the authentication data have a predetermined relationship, it can determine that the regular barcode for release has been read.

[0155] In ACT241, the processor 31 checks whether the authentication has been successful. If the authentication has failed, the processor 31 determines that the result is NO, and proceeds to ACT242. In ACT242, the processor 31 instructs the user terminal 300 to display a warning screen. Then, the processor 31 thereafter returns to the standby state in ACT238 and ACT239.

[0156] After the processor 301 in the user terminal 300 requests release in ACT147 in FIG. In ACT 148, the processor 301 checks whether or not a command to display a warning screen has been issued. If the command has not been issued, the processor 301 determines that the command has been issued and proceeds to ACT 149. In ACT 149, the processor 301 checks whether or not an instruction to display the accounting screen has been issued. If the instruction has not been issued, the processor 301 determines that the answer is NO and returns to ACT 148. Thus, the processor 301 waits for an instruction to display a warning screen or a billing screen in ACT 148 and ACT 149. If an instruction to display a warning screen is received from the mobile controller 3 as described above, the processor 301 determines YES in ACT 148 and proceeds to ACT 150.

[0157] As ACT150, the processor 301 displays a warning screen on the touch panel 304. The warning screen is a screen for warning the store clerk that the release barcode that the store clerk has read is incorrect.

[0158] FIG. 25 is a diagram showing an example of the warning screen SC6. The warning screen SC6 is a screen in which a window WI61 is superimposed on the previously displayed release screen SC5. The window WI61 includes a message ME61 and a button BU61. The message ME61 is a text message indicating that the read barcode is incorrect. The button BU61 is a soft key that allows the store clerk to declare that he or she has confirmed the notification on the warning screen SC6. The processor 301 returns to ACT142 when an instruction to cancel the display of the warning screen SC6 is given by a predetermined operation such as touching a button BU61 displayed on the warning screen SC6.

[0159] 17, if the authentication is successful, the processor 31 in the mobile controller 3 determines YES in ACT241 and proceeds to ACT243. If the confirmation required flag is "0", the processor 31 determines NO in ACT236 and proceeds to ACT243. As ACT243, the processor 31 instructs the user terminal 300 to display an accounting screen. After this, the processor 31 starts the process described below to settle the price of the product registered as a purchased product by the virtual POS server 2 or the accounting machine 5. That is, the processor 31 allows the start of the payment process if the acquired barcode data is release data that has a predetermined relationship with the authentication data. Thus, the computer with the processor 31 as its central part functions as a control means by the processor 31 executing information processing based on the smartphone POS app AP31.

[0160] If the processor 31 determines NO in ACT236 and proceeds to ACT243, ACT237 is passed, and therefore the user terminal 300 is not instructed to display a confirmation screen. Therefore, when the processor 31 instructs the display of the accounting screen in ACT243, the processor 301 in the user terminal 300 is in a standby state for ACT137 and ACT138 in Fig. 10. Therefore, the processor 301 determines YES in ACT138 in response to the instruction to display the accounting screen, and proceeds to ACT151 in Fig. 13.

[0161] Furthermore, if the processor 31 determines YES in ACT241 and proceeds to ACT243, when the processor 31 instructs the display of the accounting screen in ACT243, the processor 301 in the user terminal 300 is in a standby state for ACT148 and ACT149 in Fig. 12. Therefore, the processor 301 determines YES in ACT149 in response to the instruction to display the accounting screen, and proceeds to ACT151 in Fig. 13. As ACT 151, the processor 301 displays an accounting screen on the touch panel 304. The accounting screen is a screen that allows the customer to select whether to use the user terminal 300 or the accounting machine 5 to perform the operation for payment.

[0162] FIG. 26 is a diagram showing an example of the accounting screen SC7. The payment screen SC7 includes a display area AR71, a message ME71, and buttons BU71 and BU72. The display area AR71 shows the total number of purchased items and the total price of the purchased items. The message ME71 is a text message that prompts the customer to specify whether the operation for settling the price will be performed on the user terminal 300 or the payment machine 5. The button BU71 is a soft key that allows the customer to specify the user terminal 300. The button BU72 is a soft key that allows the customer to specify the payment machine 5.

[0163] When the customer wishes to perform the operation for payment on user terminal 300, the customer designates user terminal 300 by a predetermined operation such as touching button BU71. When the customer wishes to perform the operation for payment on payment machine 5, the customer designates payment machine 5 by a predetermined operation such as touching button BU72.

[0164] In ACT152, the processor 301 checks whether or not the user terminal 300 has been designated. If the processor 301 cannot confirm that the user terminal 300 has been designated, the processor 301 judges the result as NO and proceeds to ACT153. In ACT153, the processor 301 checks whether or not the payment machine 5 has been designated. If the processor 301 cannot confirm that the payment machine 5 has been designated, it determines that the answer is NO and returns to ACT152. Thus, in ACT152 and ACT153, the processor 301 waits for the user terminal 300 or the payment machine 5 to be designated. If the user terminal 300 is designated as described above, the processor 301 judges YES in ACT152 and proceeds to ACT154.

[0165] As ACT154, the processor 301 requests payment from the mobile controller 3. The processor 301 includes payment data, such as a credit number or a user code for an online payment service, necessary for payment in the request data for requesting payment.

[0166] Furthermore, if the payment machine 5 is specified as described above, the processor 301 judges YES in ACT153 and proceeds to ACT155. As ACT155, the processor 301 displays a transaction barcode screen on the touch panel 304. The transaction barcode screen is a screen that displays a transaction barcode that represents data required for the transaction machine 5 to obtain data related to the details of the transaction from the virtual POS server 2. Although detailed processing is not shown in the figure, the processor 301 obtains the transaction barcode from the virtual POS server 2 via the mobile controller 3 and displays the transaction barcode on the transaction barcode screen.

[0167] The customer has the scanner of a payment machine 5 that is not being used by another customer read the payment barcode. In response, the payment machine 5 obtains data on the details of the transaction from the virtual POS server 2 according to the data represented by the payment barcode, and executes processing to settle the payment amount calculated based on this data. When the payment is complete, the payment machine 5 notifies the virtual POS server 2 to that effect. When the processor 21 in the virtual POS server 2 is notified of the completion of payment by the payment machine 5, it notifies the mobile controller 3 of the completion of payment. Note that the completion of payment at the payment machine 5 may also be notified directly from the payment machine 5 to the mobile controller 3. Thus, the payment machine 5 is an example of a payment means.

[0168] After instructing the display of the accounting screen in ACT243 in FIG. 17, the processor 31 in the mobile controller 3 proceeds to ACT244. In ACT244, the processor 31 checks whether or not a payment has been requested. If the request cannot be confirmed, the processor 31 judges the result as NO and proceeds to ACT245. In ACT245, the processor 31 checks whether or not the completion of the settlement has been notified. If the notification has not been confirmed, the processor 31 judges the result as NO and returns to ACT244. Thus, the processor 31 waits for a payment request or a payment completion notification in ACT244 and ACT245. Then, if a payment is requested from the user terminal 300 as described above, the processor 31 judges YES in ACT244 and proceeds to ACT246.

[0169] As ACT246, the processor 31 transfers a payment request together with a notification of the transaction code of the transaction being processed to the virtual POS server 2. At this time, the processor 31 may transfer the request data sent from the user terminal 300 to the virtual POS server 2 as is, or may transmit the request data after being converted by some processing to the virtual POS server 2.

[0170] In the virtual POS server 2, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a payment instruction inputted by an input device provided in the existing POS terminal, calculates the amount of the transaction identified by the notified transaction code by the same process as the existing POS terminal, and performs processing to settle the amount based on the payment data. The process for settlement includes, for example, a payment request to a settlement server (not shown). The processor 21 then transmits result data indicating that the settlement has been completed to the mobile controller 3. Thus, the processor 21 executes information processing based on the virtual POS application AP21, and the computer with the processor 21 as its central part functions as a settlement means.

[0171] After the processor 31 in the mobile controller 3 transfers the payment request in ACT246, the processor 31 proceeds to ACT247. In ACT247, the processor 31 waits for a notification of the completion of the payment from the virtual POS server 2. Then, if the result data indicating that the payment has been completed and sent by the virtual POS server 2 as described above is received by the communication interface 34, the processor 31 judges the result as YES and proceeds to ACT248. Also, if the processor 31 is notified of the completion of the payment at the accounting machine 5 as described above, the processor 31 judges the result as YES in ACT245 and proceeds to ACT248. In ACT 248, the processor 31 notifies the user terminal 300 that the payment has been completed.

[0172] After the processor 301 in the user terminal 300 requests payment from the mobile controller 3 in ACT154 of ACT14, or after displaying the accounting barcode screen in ACT155, the processor 301 proceeds to ACT156. In ACT 156, the processor 301 waits for a notification of the completion of the payment. If the processor 301 receives a notification of the completion of the payment from the mobile controller 3 as described above, the processor 301 determines that the result is YES and proceeds to ACT 157. In ACT 157, the processor 301 displays a completion screen on the touch panel 304. The completion screen is a screen for notifying the customer that the payment has been completed.

[0173] When the customer confirms the completion screen, the customer declares that he / she has confirmed the completion by a predetermined operation such as touching a button displayed on the completion screen. In response to this, the processor 301 proceeds to ACT 158. The processor 301 may also proceed to ACT 158 when the elapsed time while the completion screen is displayed reaches a predetermined time.

[0174] As ACT158, the processor 301 displays a scan screen for checkout on the touch panel 304. The scan screen for checkout is a screen for reading the two-dimensional code TC2 for checkout. The processor 301, for example, starts the camera 305, and generates the scan screen by superimposing on an image obtained by the camera 305 a text message urging the customer to read the two-dimensional code TC2 and a line indicating the position where the two-dimensional code TC2 should be held up.

[0175] When the checkout scan screen appears on the touch panel 304, the customer points the camera 305 at the two-dimensional code TC2 posted near the store exit so that the two-dimensional code TC2 appears on the scan screen.

[0176] In ACT159, the processor 301 waits for the two-dimensional code to be read. At this time, the processor 301 repeatedly analyzes the image obtained by the camera 305 and attempts to read the two-dimensional code. The reading of the two-dimensional code may be performed as a process based on the smartphone POS app AP301, or may be performed as a process based on another application program for reading the two-dimensional code. Then, if the two-dimensional code is read, the processor 301 judges YES and proceeds to ACT160.

[0177] In ACT 160, the processor 301 checks whether the data represented by the read two-dimensional code is check-out data. If the data is not check-out data, the processor 301 determines NO and returns to ACT 159. At this time, the processor 301 may display on the touch panel 304 a screen notifying the customer that an incorrect two-dimensional code has been read.

[0178] If the processor 301 confirms that the data represented by the read two-dimensional code is check-out data, it judges YES in ACT160 and proceeds to ACT161. In ACT 161, the processor 301 requests the mobile controller 3 to check out.

[0179] After notifying the completion of the payment in ACT248 in FIG. 17, the processor 31 in the mobile controller 3 proceeds to ACT249. In ACT249, the processor 31 waits for a check-out request. If a check-out request is received from the user terminal 300 as described above, the processor 31 determines YES and proceeds to ACT250.

[0180] As ACT250, the processor 31 executes a checkout process. The checkout process is a process for clearing data stored in the main memory 32 and the auxiliary storage unit 33 for managing the transaction that was the subject of the process. The virtual POS server 2 may end the process related to the transaction in response to the completion of the settlement, or may end the process related to the transaction in response to an instruction from the mobile controller 3. In the latter case, the processor 31 issues the above instruction to the virtual POS server 2 in the checkout process. In addition, a history database showing the history of user operations including erroneous barcode scanning may be managed by the store server 1, the virtual POS server 2, the mobile controller 3, or another server not shown. In this case, the processor 31 performs a process for updating the history database in the checkout process so as to reflect the history of operations related to the current transaction. In ACT251, the processor 31 notifies the user terminal 300 of the completion of check-out. Then, the processor 31 ends the information processing shown in FIGS.

[0181] After the processor 301 in the user terminal 300 requests check-out in ACT161 in FIG. In ACT 162, the processor 301 waits for a notification of check-out completion. If the processor 301 receives a notification of check-out completion from the mobile controller 3 as described above, the processor 301 determines YES and proceeds to ACT 163. In ACT163, the processor 301 clears various data temporarily used in relation to this shopping, such as the check-in data saved in ACT107 in Fig. 9. Then, the processor 301 returns to ACT101 in Fig. 9.

[0182] As described above, according to the transaction processing system of this embodiment, the user terminal 300 does not proceed to the process for the transaction in the confirmation required state. In other words, if there is a product that the customer tried to register as a purchased product but was not registered correctly, the process for the transaction does not proceed. This makes it possible to prevent such products from being taken out without being paid for.

[0183] Then, when the user terminal 300 reads the authentic barcode for release, it proceeds to the process for the transaction, subject to authentication by the mobile controller 3. In this way, the confirmation by the store clerk can be completed by the user terminal 300, and the transaction can be completed without using a cashier counter staffed by a store clerk.

[0184] Furthermore, according to the transaction processing system of this embodiment, to release the confirmation-required state, the store clerk only needs to have the user terminal 300 read the release barcode, so the task does not impose a large burden on the store clerk.

[0185] According to the transaction processing system of this embodiment, the store clerk only needs to operate the user terminal 300 to cancel the confirmation-required state. Therefore, the customer can call out to a store clerk patrolling the store and request cancellation of the confirmation-required state, or go to a service counter or the like and request cancellation of the confirmation-required state from a store clerk stationed there. In other words, by giving a cancellation barcode to multiple store clerks in different locations, it is possible to increase the flexibility of canceling the confirmation-required state. However, which store clerk is given the cancellation barcode depends on the circumstances of each store or business. In other words, depending on which store clerk is given the cancellation barcode, it is also possible to change the form of cancellation allowed according to the circumstances of the store or business.

[0186] Furthermore, according to the transaction processing system of this embodiment, the authentication process is performed based on the request data included in the check-in data, making it easy to use different unlock barcodes for each store or business.

[0187] This embodiment can be modified in various ways as follows. The data for canceling the confirmation-required state may be obtained in any other manner, such as by obtaining data specified by a manual input operation, or by obtaining data electronically recorded on a recording medium via close-proximity wireless communication.

[0188] The authentication data may be stored in any storage device provided in the store system 100. For example, the authentication data may be stored in the main memory 32 or the auxiliary storage unit 33 in the mobile controller 3.

[0189] A store clerk may check the transaction at the accounting machine, and the transaction may proceed to the accounting machine without the store clerk checking the transaction at the user terminal.

[0190] If the regular cancellation barcode is read at any time before the customer finishes registering the product, the confirmation required flag may be set to "0" and the confirmation required status may be cancelled. In this way, if the customer spots a store clerk while looking around the store, they can ask the store clerk to cancel the confirmation required status. In this case, however, if the customer registers a confirmation required product as a purchased product after the confirmation required status has been cancelled, the confirmation required flag will be set to "1" and the product will enter a confirmation required status, and the product will need to be cancelled again.

[0191] The confirmation-required state may be set only when there is a product that could not be registered as a purchased product.

[0192] The functions of the virtual POS server 2 and the mobile controller 3 may be realized by one server.

[0193] The user terminal 300 may be a so-called cart terminal attached to a shopping cart provided in a store. In other words, the transaction processing system may be realized as a cart POS system. Alternatively, the user terminal 300 may be a mixture of a terminal carried by a user and a terminal attached to a shopping cart.

[0194] Each function realized by the processors 11, 21, 31, 41, and 301 through information processing can be realized in part or in whole by hardware that executes information processing not based on a program, such as a logic circuit, etc. Also, each of the above functions can be realized by combining the above hardware, such as the logic circuit, with software control.

[0195] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

[0196] 1...store server, 2...virtual POS server, 3...mobile controller, 4...communication server, 5...accounting machine, 6...access point, 7...in-store communication network, 11,21,31,41,301...processor, 12,22,32,42,302...main memory, 13,23,33,43,303...auxiliary storage unit, 14,24,34,44,...communication interface, 15,25,35,46,308...transmission path, 45...communication unit, 304...touch panel, 305...camera, 306...wireless communication unit, 307...mobile communication unit, 100 (100A, 100B)...store system, 200...relay server, 300...user terminal, 400...communication network.

Claims

1. A transaction processing system comprising: a store system that manages product transactions within a store; and a terminal that is capable of communicating with the store system, is capable of being moved with a customer, and is operated by the customer, The terminal includes: a registration request means for requesting the store system to register a product to be registered as a purchase target; a payment request means for requesting the store system to make a payment; An acquisition means for acquiring the release data by reading information held by a store clerk; a notification means for notifying the store system of the release data acquired by the acquisition means; Equipped with The store system includes: a setting means for setting a confirmation-required state regarding the registration of a product as a purchase target in response to a request by the registration request means; a release means for releasing the confirmation-required state when the release data notified by the notification means is regular release data for release; a payment means for performing a payment process to have the customer pay for the product registered as a purchase target in response to a request from the payment request means if the product is not in the confirmation-required state; A transaction processing system comprising:

2. The acquisition means acquires the release data before the request is made by the payment request means.

2. The transaction processing system of claim 1.

3. A terminal device used as the terminal in a transaction processing system including a store system that manages product transactions within a store and a terminal that is capable of communicating with the store system, is movable with a customer, and is operated by the customer, comprising: a registration request means for requesting the store system to register a product to be registered as a purchase target; a payment request means for requesting the store system to make a payment; An acquisition means for acquiring the release data by reading information held by a store clerk; a notification means for notifying the store system of the release data acquired by the acquisition means; A terminal device equipped with the above.

4. The acquisition means acquires the release data before a request is made by the payment request means. The terminal device according to claim 3.

5. A terminal device capable of communicating with a store system, comprising: a setting means for setting a confirmation-required state for a product to be registered as a purchase target; a release means for releasing the confirmation-required state when release data is genuine release data for release; and a payment means for carrying out a payment process to have a customer pay for the product registered as a purchase target if the product is not in the confirmation-required state, the terminal device being movable with a customer and being operated by the customer, a registration request means for requesting the store system to register a product to be registered as a purchase target; a payment request means for requesting the store system to make a payment; An acquisition means for acquiring the release data by reading information held by a store clerk; a notification means for notifying the store system of the release data in response to the acquisition of the release data by the acquisition means; A terminal device comprising:

6. The acquisition means acquires the release data before the request is made by the payment request means. The terminal device according to claim 5.

7. A computer capable of communicating with a store system, the computer comprising: a setting means for setting a confirmation-required state for a product to be registered as a purchase target; a release means for releasing the confirmation-required state when release data is genuine release data for release; and a payment means for performing a payment process to have a customer pay for the product registered as a purchase target if the product is not in the confirmation-required state, the computer being movable with a customer and equipped on a terminal device operated by the customer, a registration request means for requesting the store system to register a product to be registered as a purchase target; a payment request means for requesting the store system to make a payment; An acquisition means for acquiring the release data by reading information held by a store clerk; a notification means for notifying the store system of the release data in response to the acquisition of the release data by the acquisition means; An information processing program that enables the system to function as such.

8. A store system that is mobile with a customer and capable of communicating with a terminal operated by the customer, and that manages product transactions within a store, comprising: a setting means for setting a confirmation-required state for the registration of a product as a purchase target in response to a registration request from a terminal for the product to be registered as a purchase target; a release means for releasing the confirmation-required state when the release data acquired by reading the information held by the store clerk at the terminal and notified from the terminal is regular release data for release; a payment means for performing a payment process to have the customer pay for the product registered as a purchase target in response to a payment request from the terminal if the confirmation-required state is not present; A store system equipped with the above.

9. Used in a transaction processing system having a setting means which is movable with a customer and which sets a confirmation-required state for the registration of a product as a purchase target in response to a request for registration of the product as a purchase target from a terminal operated by the customer, a release means for releasing the confirmation-required state when the release data acquired by reading the information held by the store clerk at the terminal and notified from the terminal is regular release data for release; a payment means for performing a payment process to have the customer pay for the product registered as a purchase target in response to a payment request from the terminal if the confirmation-required state is not present; A transaction support device equipped with the above.

Images