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] Embodiments of the present invention relate to a transaction processing system, terminal an apparatus, an information processing program store system and a transaction support equipment .

Background Art

[0002] A transaction processing system that registers the details of a transaction in response to an operation of a terminal device by a customer is considered, for example, as 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 according to the customer's operation on the terminal device. Also, if a self-type cash register that performs payment processing according to the customer's operation is used, the payment process can be completed according to the customer's operation on the cash register. And if the payment can be completed in this way, it is possible to complete the transaction without the involvement of the store clerk.

[0003] By the way, regarding newly launched products or products sold for a limited period, etc., registration in the product database may be delayed, and products not registered in the product database may be displayed in the store. Also, there may be a case where a barcode different from the barcode representing the product code is displayed on the product, and it is conceivable that the customer may read a barcode that does not represent the product code on the terminal device. In these cases, although the corresponding product cannot be registered as a purchased product, the customer may mistakenly think that it has been registered. And in such a situation, if payment can be made without the involvement of the store clerk, products that have not been paid for will be taken out by the customer. Due to such circumstances, it has been desired to prevent products that the customer tried to register as purchased products but could not be correctly registered from being taken out without being paid for.

Prior Art Documents

Patent Documents

[0004] [Patent Document 1] Japanese Patent Publication No. 2019-144797 [Overview of the project] [Problems that the invention aims to solve]

[0005] The problem that this invention aims to solve is a transaction processing system that can prevent products that a customer attempted to register as purchased items but could not register correctly from being taken out without being paid for. terminal Devices, information processing programs store system and transactions support equipment The objective is to provide. [Means for solving the problem]

[0006] The transaction processing system of the embodiment is The system comprises a store system for managing transactions of goods within the store, and a terminal that can communicate with the store system, is mobile with the customer, and is operated by the customer, the terminal being: Registration request means, payment request means, means of acquisition and notification Equipped with means The store system includes setting means, deactivation means and payment means. Register. request The means , purchase Eligible Trying to register as merchandise of Registration Request the store system To do. Payment request The means are, Request payment from the store system. The means of acquisition is, The lock can be deactivated by reading the information held by the store employee. Retrieve the data. The notification means notifies the store system of the release data obtained by the acquisition means. The setting means sets a status requiring confirmation regarding the registration of the product as a purchase item in response to a request by the registration request means. Release The means are, notification by means notification done Cancellation data Official unlocking If it is deactivation data, Remove the "requires confirmation" status. do. The payment method, in response to a request from the payment request method, will process the payment for the registered items to be purchased, unless the item is in a state requiring verification. [Brief explanation of the drawing]

[0007] [Figure 1] A block diagram showing the schematic configuration of a transaction processing system according to one embodiment. [Figure 2] A block diagram showing the main circuit configuration of the store server in Figure 1. [Figure 3]Block diagram showing the main circuit configuration of the virtual POS server in FIG. 1. [Figure 4] Block diagram showing the main circuit configuration of the mobile controller in FIG. 1. [Figure 5] Schematic diagram showing the main data structure of the data records included in the transaction management database shown in FIG. 4. [Figure 6] Schematic diagram showing the main data structure of the data records included in the registration database shown in FIG. 4. [Figure 7] Block diagram showing the main circuit configuration of the communication server in FIG. 1. [Figure 8] Block diagram showing the main circuit configuration of the user terminal in FIG. 1. [Figure 9] Flowchart of information processing by the processor shown in FIG. 8. [Figure 10] Flowchart of information processing by the processor shown in FIG. 8. [Figure 11] Flowchart of information processing by the processor shown in FIG. 8. [Figure 12] Flowchart of information processing by the processor shown in FIG. 8. [Figure 13] Flowchart of information processing by the processor shown in FIG. 8. [Figure 14] Flowchart of information processing by the processor shown in FIG. 4. [Figure 15] Flowchart of information processing by the processor shown in FIG. 4. [Figure 16] Flowchart of information processing by the processor shown in FIG. 4. [Figure 17] Flowchart of information processing by the processor shown in FIG. 4. [Figure 18] Figure showing an example of a list screen. [Figure 19] Figure showing an example of a registration screen. [Figure 20] Figure showing an example of a list screen. [Figure 21] Figure showing an example of a list screen. [Figure 22] Figure showing an example of a guidance screen. [Figure 23] A diagram showing an example of a confirmation screen. [Figure 24] A diagram showing an example of the unlock screen. [Figure 25] An example of a warning screen is shown in the diagram. [Figure 26] A diagram showing an example of an accounting screen. [Modes for carrying out the invention]

[0008] The following describes one embodiment of the transaction processing system with reference to drawings. The transaction processing system in this embodiment processes transactions for goods sold to customers in a store that sells multiple products, including products that require verification by a store employee before sale due to circumstances such as age restrictions for purchasers (hereinafter referred to as "products requiring verification").

[0009] Figure 1 is a block diagram showing the schematic configuration of the transaction processing system according to this embodiment. The transaction processing system is configured to enable communication between multiple store systems 100, relay servers 200, and user terminals 300 via a communication network 400. Figure 1 shows two store systems 100. These store systems 100 are installed in two different stores, A and B, which use the transaction processing system. There may be three or more stores that use the transaction processing system, and a store system 100 will be 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 operator of store A may be the same as, or different from, the operator of store B. Similarly, if the transaction system is used at other stores, the operator of those stores may be the same as, or different from, the operator of 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 data communication relay functionality, for example, as a cloud service via the communication network 400. The user terminal 300 is an information and communication terminal that functions as a user interface for customers making purchases using the transaction system at a store. The user terminal 300 has the function of wirelessly communicating with the store system 100 and the function of wirelessly communicating with the communication network 400. As the user terminal 300, a communication terminal equipped with data communication capabilities, such as a smartphone or tablet, can be used. The user terminal 300 may be owned by the customer or may be lent to the customer by the store. The communication network 400 can be, for example, the internet, VPN (virtual private network), LAN (local area network), public communication network, mobile communication network, etc., either individually or in appropriate combinations. Typically, the communication network 400 utilizes a mobile communication network and the internet or VPN.

[0011] The general configuration of each store system 100 is the same. Specifically, the store system 100 is configured so that a store server 1, a virtual POS server 2, a mobile controller 3, a communication server 4, a cashier 5, and an 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, cashier 5, access point 6, and in-store communication network 7 do not need to be completely identical, as long as they have the same functions to realize the operations described later. In addition, some store systems 100 may have devices not shown in Figure 1.

[0012] Store server 1 comprehensively manages multiple transactions that are subject to transaction processing implemented by store system 100 as described below. Store server 1 has functions similar to those of an existing POS server, for example. The virtual POS server 2 processes information for each transaction, such as registering purchased items and settling payments for those items, in response to external requests. In other words, the virtual POS server 2 virtually implements the functions of an existing POS terminal. The information processing performed by the virtual POS server 2 is customized to adapt to the differences in operating policies of each store. That is, for example, the information processing performed by store server 1 in store system 100A may differ in some respects from the information processing performed by store server 1 in 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 support device. The communication server 4 performs communication processing to enable the store server 1, virtual POS server 2, mobile controller 3, and accounting machine 5 to exchange data with the relay server 200 and other devices via the communication network 400.

[0014] The accounting machine 5 calculates the price for each purchased item managed by the virtual POS server 2 and processes the payment to the customer. The payment methods that the accounting machine 5 can use for the above payment may be all or any part of well-known payment methods, such as cash payment, credit card payment, electronic money payment, point payment, and code payment (also referred to as mobile payment or smartphone payment, etc.). The accounting machine 5 may be operated by either a store employee 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 also have a function to process information for registering items as purchased items. In this case, the accounting machine 5 may be, for example, 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] Access point 6 performs communication processing to enable user terminals 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 IEEE 802.11 standard can be used as access point 6. Access point 6 is installed within the store so that user terminals 300 can communicate wirelessly from anywhere in the store's sales floor. Depending on the size of the store, multiple access points 6 may be deployed in a single store system 100. The in-store communication network 7 can be the Internet, VPN, LAN, public communication network, mobile communication network, etc., either individually or in appropriate combinations. However, typically, the in-store communication network 7 is a LAN.

[0016] In stores equipped with the store system 100, a 2D code TC1 for check-in is displayed near the entrance, and a 2D code TC2 for check-out is displayed near the exit. 2D code TC1 represents check-in data. 2D code TC2 represents check-out data. Check-in and check-out data differ for each store. Therefore, if it is necessary to distinguish between 2D codes TC1 and TC2 for store A and 2D codes TC1 and TC2 for store B, the codes for store A are represented as 2D codes TC1A and TC2A, and the codes for store B are represented as 2D codes TC1B and TC2B.

[0017] Check-in data represents information such as the following: (1) The operating version of the store system 100. For example, the check-in data represented by the 2D code TC1A represents the operating version of store system 100A. The check-in data represented by the 2D code TC1B represents the operating version of store system 100B. (2) A business code for identifying the business operator that operates the store where the store system 100 is installed. For example, the check-in data represented by the 2D code TC1A represents the business code assigned to the business operator that operates store A. The check-in data represented by the 2D code TC1B represents the business code assigned to the business operator that operates store B. (3) A store code for identifying the store where the store system 100 is installed. For example, the check-in data represented by the 2D code TC1A represents the store code assigned to store A. The check-in data represented by the 2D code TC1B represents the store code assigned to store B. The store code may be able to identify each individual store that uses the transaction processing system, or it may be able to identify each individual store of multiple stores operated by the same business operator.

[0018] (4) The name of the operator that runs the store where the store system 100 is installed. For example, the check-in data represented by the 2D code TC1A represents the name of the operator that runs store A. The check-in data represented by the 2D code TC1B represents the name of the operator that runs store B. (5) The name of the store where the store system 100 is installed. For example, the check-in data represented by the 2D code TC1A represents the name of store A. The check-in data represented by the 2D code TC1B represents the name of store B. (6) A flag used to distinguish between 2D code TC1 and 2D code TC2. In check-in data, this flag is considered to be a state indicating that it is check-in data. This state is, for example, "1". This flag is common to all 2D code TC1.

[0019] (7) The IP address of the communication server 4. For example, the check-in data represented by the 2D code TC1A represents the IP address of the communication server 4 included in the store system 100A. The check-in data represented by the 2D code TC1B represents the IP address of the communication server 4 included in the store system 100B. (8) The domain name of the relay server 200. This domain name is common to all 2D 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 2D code TC1 will represent the domain name of the relay server 200 used by the corresponding store. (9) Address of the electronic receipt server. The electronic receipt server is not included in the transaction processing system shown in Figure 1 and provides electronic receipt services via the communication network 400. For example, the check-in data represented by the 2D code TC1A represents the address for accessing the electronic receipt server that provides electronic receipt services used by the business operator operating store A, via the communication network 400. The check-in data represented by the 2D code TC1B represents the address for accessing the electronic receipt server that provides electronic receipt services used by the business operator operating store B, via the communication network 400. This address may be common to all 2D codes TC1, or one of multiple addresses may be represented for each 2D code TC1.

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

[0021] (13) The identification number of the security method used by access point 6. For example, the identification number is assigned as follows: "1" for WPA2-PSK, "2" for WPA-PSK, and "3" for WEP. For example, if access point 6 included in store system 100A uses the WPA2-PSK security method, the check-in data represented by the 2D code TC1A will have the identification number "1". Also, for example, if access point 6 included in store system 100B uses the WPA-PSK security method, the check-in data represented by the 2D code TC1B will have the identification number "2". (14) A flag for identifying whether to report an error when the user terminal 300 fails to connect to the relay server 200, or to continue operation without reporting an error. For example, in store A, if the setting is to report an error when the user terminal 300 fails to connect to the relay server 200, the check-in data represented by the 2D code TC1A will represent, for example, "1" as the flag. Also, for example, in store B, if the setting is to continue operation even if the user terminal 300 fails to connect to the relay server 200, the check-in data represented by the 2D code TC1B will represent, for example, "0" as the flag.

[0022] (15) Identification number of the transmission mode relating 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 "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 2D code TC1A will have the identification number "1". Also, for example, in store B, if the second mode is applied as the transmission mode, the check-in data represented by the 2D code TC1B will have the identification number "2".

[0023] (16) Identification number of the transmission mode for the log file storing log data from the user terminal 300. There are, for example, a first mode, a second mode, a third mode, and a fourth mode. For example, the identification number for the transmission mode is "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 sent only to the relay server 200. In the second mode, the log file is sent only to the store system 100. In the third mode, the log file is sent to both the store system 100 and the relay server 200. In the fourth mode, the log file is not sent. For example, if the first mode is applied as the transmission mode in store A, the check-in data represented by the 2D code TC1A will have the identification number "1". Also, for example, if the second mode is applied as the transmission mode in store B, the check-in data represented by the 2D code TC1B will have the identification number "2".

[0024] (17) The hostname or IP address used when sending log files to the relay server 200 via FTP (file transfer protocol) over the communication network 400. (18) The username used when sending log files to the relay server 200 via FTP over the communication network 400. (19) The password used when sending log files to the relay server 200 via FTP over the communication network 400. (20) The path name of the log file to be sent via FTP to the relay server 200 through the communication network 400.

[0025] (21) A flag to identify whether or not to remove the check digit of a UPC (universal product code), which is a type of product code. For example, in store A, if the check digit is not removed, the check-in data represented by the 2D code TC1A will represent "1" as the flag. Also, for example, in store B, if the check digit is removed, the check-in data represented by the 2D code TC1B will represent "0" as the flag. (22) The time until the camera screen is automatically switched on the user terminal 300. The check-in data represented by the 2D code TC1A represents the time that has been set in advance for store A. The check-in data represented by the 2D code TC1B represents the time that has been set in advance for store B. (23) The timeout period when the user terminal 300 communicates with the store system 100 via the access point 6. The check-in data represented by the 2D code TC1A represents the time set in advance for store A. The check-in data represented by the 2D code TC1B represents the time set in advance for store B.

[0026] (24) The number of retries allowed if 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 2D code TC1A represents this number, and is a number predetermined for store A. The check-in data represented by the 2D code TC1B represents this time, and is a number predetermined for store B. (25) The timeout period when the user terminal 300 communicates with the store system 100 via the relay server 200. The check-in data represented by the 2D code TC1A represents the time set in advance for store A. The check-in data represented by the 2D code TC1B represents the time set in advance for store B. (26) The number of retries allowed if 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 2D code TC1A represents this number, and is a number predetermined for store A. The check-in data represented by the 2D code TC1B represents this time, and is a number predetermined for store B.

[0027] (27) Authentication data used in the authentication process to authenticate the declaration of completion of verification for transactions involving products that require verification by a store employee. The check-in data represented by the 2D code TC1A represents the authentication data pre-set for store A. The check-in data represented by the 2D code TC1B represents the authentication data pre-set for store B. It is preferable that the authentication data be different for each store, but it is also acceptable for the same authentication data to be set for different stores. (28) Data for identifying the operating mode of the store system 100. For example, if store system 100A is set to normal mode, which is the normal operation mode for the transaction processing system, the check-in data represented by the 2D code TC1A will be, for example, "1". Also, for example, if store system 100B is set to demo mode, which is the demo operation mode for the transaction processing system, the check-in data represented by the 2D code TC1B will be, for example, "2". (29) Data for identifying the mode of data transfer to the accounting machine 5. For example, if the store system 100A is set to a mode in which it requests data transfer from the accounting machine 5 to the mobile controller 3, the check-in data represented by the two-dimensional code TC1A will be, for example, "1". Also, for example, if the store system 100B is set to a mode in which it transfers data from the mobile controller 3 to the accounting machine 5 without a request from the accounting machine 5, the check-in data represented by the two-dimensional code TC1B will be, for example, "2".

[0028] (30) A flag indicating whether or not to allow payment by code payment method via operation on the user terminal 300. For example, if store A allows the code payment, the check-in data represented by the 2D code TC1A will represent this flag as, for example, "1". Also, for example, if store B does not allow the code payment, the check-in data represented by the 2D code TC1B will represent this flag as, for example, "0". (31) A flag for identifying whether or not registration of products with age restrictions for purchasers (hereinafter referred to as "age-restricted products") is permitted on the user terminal 300. For example, if registration of age-restricted products is permitted on the user terminal 300 at store A, the check-in data represented by the 2D code TC1A will represent, for example, "1" as the flag. Also, for example, if the code payment is not permitted at store B, the check-in data represented by the 2D code TC1B will represent, for example, "0" as the flag. (32) Data for identifying the input mode of the member code of a points member. For example, if the store system 100A is set to a mode in which the member code is entered manually, the check-in data represented by the 2D code TC1A will be, for example, "1". 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 2D code TC1B will be, for example, "2".

[0029] (33) A flag to identify whether or not verification by a store employee is required when entering a points member's membership code, when the mode for manually entering the membership code is set. For example, if such verification is required at store A, the check-in data represented by the 2D code TC1A will represent "1" as this flag. Also, for example, if such verification is not required at store B, the check-in data represented by the 2D code TC1B will represent "0" as this flag. (34) A threshold for checking the battery level of the user terminal 300 at check-in. This threshold is set for each store or business operator. For example, if the business operator operating store A sets the threshold at "20%", the check-in data represented by the 2D code TC1A will represent, for example, "20" as the threshold. Also, for example, if store B sets the threshold at "25%", the check-in data represented by the 2D code TC1B will represent, for example, "25" as the threshold. The above are examples of the information that check-in data represents. However, check-in data does not necessarily have to include some of the information described above. Also, check-in data may represent information other than the information described above.

[0030] Figure 2 is a block diagram showing the main circuit configuration of store server 1. The store server 1 includes a processor 11, main memory 12, auxiliary storage unit 13, communication interface 14, and transmission line 15. The processor 11, main memory 12, auxiliary storage unit 13, and communication interface 14 are able to communicate with each other via the transmission line 15. The connection of the processor 11, main memory 12, and auxiliary storage unit 13 via the transmission line 15 constitutes a computer for controlling the store server 1.

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

[0032] Main memory 12 corresponds to the main memory portion of the computer described above. Main memory 12 includes a non-volatile memory area and a volatile memory area. In the non-volatile memory area, main memory 12 stores the above-mentioned information processing program. Main memory 12 may also store data necessary for the processor 11 to perform information processing in either a non-volatile or volatile memory area. Main memory 12 uses the volatile memory area as a work area where data is rewritten as needed by the processor 11. The non-volatile memory area is, for example, ROM (read-only memory). The volatile memory area is, for example, RAM (random access memory).

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

[0034] The communication interface 14 communicates data with each part connected to the in-store communication network 7 according to a predetermined communication protocol. For example, a well-known communication device for LANs can be used as the communication interface 14. The transmission line 15 includes an address bus, a data bus, and control signal lines, and transmits data and control signals exchanged between the connected parts.

[0035] The auxiliary storage unit 13 stores the store management application AP11, which is one of the information processing programs. The store management application AP11 is an application program that describes the information processing necessary to realize the functions of the store server 1. The store management application AP11 may be separate and created to suit the store management policies of each store or each business operator that operates the store. For example, if the sales data management methods differ between store A and store B, the store management application AP11 used in store system 100A will describe the information processing for sales data management that is adapted to the sales data management method at store A, and the store management application AP11 used in store system 100B will describe the information processing for sales data management that is adapted to the sales data management method at store B.

[0036] A portion of the storage area of ​​the auxiliary storage unit 13 is used as the database group DB11. The database group DB11 includes multiple databases for various types of information management. One of the databases included in the database group DB11 is the product database for managing products sold in stores. 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 about the associated product, such as the product code, price, and product name. The product code is an identification code defined to identify products by SKU (stock keeping unit), and for example, the JAN (Japanese article number) code is used. The product name is a name defined to make it easy for humans to distinguish products. The price is the amount of money paid for the sale of the product.

[0037] One of the databases included in the DB11 database group is the user database, which is used to manage store users. The user database is a collection of data records associated with customers who have been registered as users. The data records in the user database include data about the associated customer, such as the user code and attribute information to identify the user. The user code is a unique identification code assigned to each customer to identify them individually. Attribute information may include name, gender, age, address, telephone number, etc. The data records in the user database may also include payment information declared by the user. Payment information may include credit card numbers or code payment IDs (identifiers). If multiple payment methods are available, the payment information may also include a payment method code to identify the payment method. In the case of stores that provide a points service, the payment information may also include the points service ID and the number of points held.

[0038] In addition, the database group DB11 may include various databases, such as those managed by the POS server in existing POS systems. The specific databases included in the database group DB11, and the data and structure of those databases, may be determined on a store-by-store basis.

[0039] Figure 3 is a block diagram showing the main circuit configuration of the virtual POS server 2. The virtual POS server 2 includes a processor 21, main memory 22, auxiliary storage unit 23, communication interface 24, and transmission path 25. The processor 21, main memory 22, auxiliary storage unit 23, and communication interface 24 are capable of communicating with each other via the transmission path 25. The connection of the processor 21, main memory 22, and auxiliary storage unit 23 via the transmission path 25 constitutes a computer for controlling the virtual POS server 2. The general functions of the processor 21, main memory 22, auxiliary storage unit 23, communication interface 24, and transmission path 25 are equivalent to those of the processor 11, main memory 12, auxiliary storage unit 13, communication interface 14, and transmission path 15, so their explanation is omitted.

[0040] However, the auxiliary storage unit 23 stores the virtual POS application AP21 instead of the store management application AP11. The virtual POS application AP21 is an application program that describes the information processing necessary to realize the functions of the virtual POS server 2. The virtual POS application AP21 may be separate and created to suit the store operation policies of each store or each business operator that operates the store. For example, if store A offers a discount service that is not offered at store B, the virtual POS application AP21 used in store system 100A will describe the information processing necessary to realize that discount service, while the virtual POS application AP21 used in store system 100B will not describe the information processing necessary to realize that discount service.

[0041] Furthermore, a portion of the storage area of ​​the auxiliary storage unit 23 is used as the transaction database DB21 instead of the database group DB11. The transaction database DB21 is a collection of data records associated with transactions with customers shopping in the store. The data records in the transaction database DB21 include a transaction code and product data about products registered as purchased items. The transaction code is a unique identification code set for each transaction to identify each individual transaction. The product data represents the product code, product name, price, and quantity, etc. The structure of the transaction database DB21 may be determined individually to suit the store operation policies of each store or each business operator operating the store.

[0042] Figure 4 is a block diagram showing the main circuit configuration of the mobile controller 3. The mobile controller 3 includes a processor 31, main memory 32, auxiliary storage unit 33, communication interface 34, and transmission path 35. The processor 31, main memory 32, auxiliary storage unit 33, and communication interface 34 are capable of communicating via the transmission path 35. The connection of the processor 31, main memory 32, and auxiliary storage unit 33 via the transmission path 35 constitutes a computer for controlling the mobile controller 3. The general functions of the processor 31, main memory 32, auxiliary storage unit 33, communication interface 34, and transmission path 35 are equivalent to those of the processor 11, main memory 12, auxiliary storage unit 13, communication interface 14, and transmission path 15, so their explanation is omitted.

[0043] However, the auxiliary storage unit 33 stores the registration support application AP31 instead of the store management application AP11. The registration support application AP31 is an application program that describes the information processing described later to support the registration of purchased products. The registration support application AP31 is common to all store systems 100. However, various settings for information processing based on the registration support application AP31 may be customized for each store system 100.

[0044] Furthermore, a portion of the storage area of ​​the auxiliary storage unit 23 is used as the transaction management database DB31 and the registration database DB32 instead of the database group DB11. The structure of these transaction management database DB31 and registration database DB32 is common to each store system 100.

[0045] Figure 5 is a schematic diagram showing the main data structure of data record DR1 included in the transaction management database DB31. The transaction management database DB31 is a collection of data records DR1 associated with 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 any data records DR1. The data record DR1 contains fields F11, F12, F13, and F14.

[0046] Field F11 is set with a terminal code to distinguish the associated user terminal 300 from other user terminals 300. As the terminal code, for example, a unique identification code set for each communication terminal to identify each communication terminal used as a user terminal 300 can be used. Alternatively, as the terminal code, for example, an identification code set for the smartphone POS application when the smartphone POS application described later is installed on the user terminal 300 can be used. Field F12 is set with a membership code to distinguish the customer using the associated user terminal 300 from other customers. Field F13 is set with a transaction code for transactions conducted using the associated user terminal 300. Field F14 is set with a confirmation flag to identify whether or not the products registered as purchased products using the associated user terminal 300 include products that require confirmation. In this embodiment, a confirmation flag of "1" indicates that products requiring confirmation are included. Note that data record DR1 may include other fields to which different data from fields F11 to F15 is set. In other words, the confirmation flag indicates whether or not confirmation by a store employee is required.

[0047] Figure 6 is a schematic diagram showing the main data structure of data record DR2 included in the registration database DB32. The registration database DB32 is a collection of data records DR2 associated with transactions with customers shopping in the store. Each data record DR2 contains fields F21 and F22. Data records DR1 may also contain fields F23, F24, ...

[0048] Field F21 is set with the transaction code of the associated transaction. 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. Field F22 is set with registration data related to the attempted product registration for the associated transaction. The registration data will be described later.

[0049] Data record DR2 includes fields F23 and beyond if there is an attempt to register two or more purchased items for the associated transaction. These fields, F23 and beyond, are then populated with registration data similar to that for field F12.

[0050] Figure 7 is a block diagram showing the main circuit configuration of the communication server 4. The communication server 4 includes a processor 41, main memory 42, auxiliary storage unit 43, communication interface 44, communication unit 45, and transmission line 46. The processor 41, main memory 42, auxiliary storage unit 43, communication interface 44, and communication unit 45 are capable of communicating via the transmission line 46. The connection of the processor 41, main memory 42, and auxiliary storage unit 43 via the transmission line 46 constitutes a computer for controlling the communication server 4. The general functions of the processor 41, main memory 42, auxiliary storage unit 43, communication interface 44, and transmission line 46 are equivalent to those of the processor 11, main memory 12, auxiliary storage unit 13, communication interface 14, and transmission line 15, so their explanation is omitted. The communication unit 45 performs communication processing for data communication via the communication network 400. For example, a well-known internet connection device can be used as the communication unit 45.

[0051] The auxiliary storage unit 43 stores the communication processing application AP41 instead of the store management application AP11. The communication processing application AP41 is an application program that describes information processing for communicating with the relay server 200 via the communication network 400 in order 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] Figure 8 is a block diagram showing the main circuit configuration of the user terminal 300. The user terminal 300 includes a processor 301, main memory 302, auxiliary storage unit 303, touch panel 304, camera 305, wireless communication unit 306, mobile communication unit 307, and transmission line 308, etc. The processor 301 and the main memory 302, auxiliary storage unit 303, touch panel 304, camera 305, and mobile communication unit 307 are able to communicate with each other via the transmission line 308. The processor 301, main memory 302, and auxiliary storage unit 303 are connected by the transmission line 308, thereby forming a computer for controlling the user terminal 300. The general functions of the processor 301, main memory 302, auxiliary storage unit 303, and transmission line 308 are the same as those of the processor 11, main memory 12, auxiliary storage unit 13, and transmission line 15, so their explanation is omitted.

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

[0054] The wireless communication unit 306 exchanges data with the access point 6 via wireless communication in accordance with a wireless communication protocol. For example, a well-known communication device compliant with the IEEE 802.11 standard can be used as the wireless communication unit 306. The mobile communication unit 307 is an interface for data communication via the communication network 400. For example, a well-known communication device for performing data communication via a mobile communication network can be used as the mobile communication unit 307.

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

[0056] Now, as hardware for the store server 1, virtual POS server 2, or mobile controller 3, for example, a general-purpose server device can be used. Generally, the transfer of the store server 1, virtual POS server 2, or mobile controller 3 is carried out with the store management application AP11, virtual POS application AP21, or registration support application AP31 stored in the auxiliary storage units 13, 23, or 33, respectively, but without the database group DB11, transaction database DB21, or transaction management database DB31 and registration database DB32. However, the hardware in which the store management application AP11, virtual POS application AP21, or registration support application AP31 is not stored in the auxiliary storage units 13, 23, or 33, or in which a different version of the same type of application program is stored in the auxiliary storage units 13, 23, or 33, may be transferred along with the store management application AP11, virtual POS application AP21, or registration support application AP31 individually. Furthermore, a store server 1, a virtual POS server 2, or a mobile controller 3 may be configured by writing a store management application AP11, a virtual POS application AP21, or a registration support application AP31 to an auxiliary storage unit 13, 23, or 33 in response to an operation by any operator. The transfer of the store management application AP11, the virtual POS application AP21, or the registration support application AP31 can be performed by recording it on a removable recording medium such as a magnetic disk, magneto-optical disk, optical disk, or semiconductor memory, or by communication over a network. The transaction database DB21, or the transaction management database DB31 and registration database DB32, are configured within 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 portion of the store management application AP11 and the databases included in the database group DB11 may be stored in the main memory 12. At least a portion 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 support application AP31, the transaction management database DB31, and the registration database DB32 may be stored in main memory 32.

[0057] Next, the operation of the transaction processing system configured as described above will be explained. Note that the content of the various processes described below is merely an example, and it is possible to change the order of some processes, omit some processes, or add other processes as appropriate. For example, in the following explanation, some processes have been omitted in order to clearly illustrate the characteristic operation of this embodiment. For example, if an error occurs, processing to deal with that error may be performed, but some of such processing has been omitted from the description. The service provided to customers through the operation of the transaction processing system described below will be referred to as the smartphone POS service.

[0058] To use the smartphone POS service, the user terminal 300 exchanges data with the store system 100. Whether to use wireless communication with access point 6 or wireless communication with the communication network 400 for this communication is determined by the state of a flag included in the check-in data. However, for the sake of simplicity, the following explanation will focus on the case where only wireless communication with access point 6 is used. Furthermore, whether to use a mode in which the accounting machine 5 requests data transfer from the virtual POS server 2 to the accounting machine 5 for accounting is determined by the state of a flag included in the check-in data. This mode involves either the accounting machine 5 requesting data transfer from the mobile controller 3, or the mobile controller 3 transferring data to the accounting machine 5 without a request from the accounting machine 5. However, for the sake of simplicity, the following explanation will assume that the mode in which the accounting machine 5 requests data transfer from the mobile controller 3 is always used.

[0059] To use the smartphone POS service, customers must install the smartphone POS app AP301 on their own smartphone or other device and make it available as a user terminal 300. Alternatively, customers can borrow a user terminal 300 from a store, which is configured with the smartphone POS app AP301 installed on a tablet or other device. The customer then enters one of the stores where the store system 100 is installed, with the user terminal 300, which has the information processing based on the smartphone POS app AP301 activated.

[0060] Now, in the user terminal 300, the processor 301 performs information processing based on the smartphone POS application AP301, as shown in Figures 9, 10, 11, 12, and 13. First, as shown in Figure 9, the processor 301, designated as ACT101, displays the main menu screen on the touch panel 304. The main menu screen is used to select one of several processes to be performed based on the smartphone POS application AP301. The main menu screen contains multiple GUI (graphical user interface) elements, including a GUI element for specifying the start of shopping. The GUI elements are, for example, soft keys.

[0061] As ACT102, processor 301 checks whether the start of shopping has been specified. If processor 301 cannot confirm the specification, it determines NO and proceeds to ACT103. As ACT103, processor 301 checks whether any specification other than starting a purchase has been made. If processor 301 cannot find any such specification, it determines NO and returns to ACT102. Thus, processor 301 waits for some specification to be made on the main menu screen as ACT102 and ACT103. If a specification other than starting shopping is made, processor 301 determines YES in ACT103 and proceeds to the specified process. The explanation of the processor 301's processing in this case is omitted.

[0062] When a customer enters a store and begins shopping, they perform a predetermined operation on the main menu screen to specify that they want to start shopping. When the processor 301 detects, for example, an operation to specify the start of shopping via the touch panel 304, it determines YES in ACT102 and proceeds to ACT104. As ACT104, the processor 301 displays a check-in scan screen on the touch panel 304. The check-in scan screen prompts the customer to scan the check-in 2D code TC1. For example, the processor 301 activates the camera 305 and generates the scan screen by overlaying a text message prompting the customer to scan the 2D code TC1 and a line indicating the position where the 2D code TC should be held over the image obtained by the camera 305.

[0063] When the scan screen appears on the touch panel 304, the customer points the camera 305 towards the 2D code TC1, which is displayed near the entrance of the store, so that it is visible on the scan screen. As ACT105, the processor 301 waits for the 2D code to be read. At this time, the processor 301 repeatedly analyzes the image obtained by the camera 305 and attempts to read the 2D code. This reading of the 2D code may be performed as processing based on the smartphone POS application AP301, or as processing based on a separate application program for reading 2D codes. If the 2D code is read, the processor 301 determines YES and proceeds to ACT106.

[0064] As ACT106, processor 301 checks whether the data represented by the scanned 2D code is check-in data. If it is not check-in data, processor 301 determines NO and returns to ACT105. At this point, processor 301 may display a screen on touch panel 304 informing the customer that an incorrect 2D code has been scanned.

[0065] If processor 301 confirms that the data represented by the read 2D code is check-in data, it determines YES in ACT106 and proceeds to ACT107. As ACT107, processor 301 saves the read check-in data to main memory 302 or auxiliary storage unit 303.

[0066] As ACT108, processor 301 requests a check-in from mobile controller 3. Specifically, processor 301 establishes wireless communication between wireless communication unit 306 and access point 6 based on the data represented in the check-in data. For example, if a customer points camera 305 at 2D code TC1A in store A, processor 301 establishes wireless communication with access point 6 located in store system 100A based on the check-in data represented by 2D code TC1A. Then, processor 301 transmits request data to mobile controller 3 via wireless communication with access point 6 to request a check-in. As described above, if wireless communication with access point 6 located in store system 100A is established, the request data is transmitted to mobile controller 3 located in store system 100A via access point 6 and in-store communication network 7 located in store system 100A. Processor 301 includes identification data to identify that it is a check-in request and a terminal code in the request data for requesting a 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 in the request data, such as data for authenticating the customer. Furthermore, the various requests from the user terminal 300 to the mobile controller 3, as described below, are realized by sending request data containing 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, similar to the above.

[0067] In the mobile controller 3, when request data for requesting check-in is received by the communication interface 34, the processor 31 begins processing information related to the transaction with the customer attempting to check in.

[0068] Figures 14, 15, 16, and 17 are flowcharts of information processing by processor 31. The processor 31 starts processing information whenever it receives request data for a check-in via the communication interface 34. If it is already executing information processing initiated based on another request, it starts the new information processing in parallel. In other words, the processor 31 may execute multiple information processing operations in parallel for multiple user terminals 300, each targeting a different user terminal 300. Hereafter, when simply referred to as "user terminal 300," it refers to the user terminal 300 that is the target of information processing by the processor 31.

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

[0070] In the virtual POS server 2, when the mobile controller 3 requests the start of a transaction, the processor 21 determines a transaction code according to predetermined rules and starts the process of registering the purchased items associated with that transaction code. The processor 21 also notifies the mobile controller 3 of the determined transaction code.

[0071] As ACT202, processor 31 checks whether the check-in process was completed successfully. If processor 31 was unable to complete the check-in process successfully due to some abnormality, it determines NO and proceeds to ACT203. As ACT203, the processor 31 notifies the user terminal 300 of the error. For example, the processor 31 sends notification data for the error notification to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes identification data in the notification data to identify that it is an error notification. The processor 31 may also include an error code in the notification data that indicates the cause of the error. Furthermore, the various notifications from the mobile controller 3 to the user terminal 300, as described below, are implemented in the same way as above by sending notification data containing 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 access point 6.

[0072] On the other hand, if processor 31 has successfully completed the check-in process, it determines YES in ACT202 and proceeds to ACT204. As ACT204, processor 31 notifies user terminal 300 that check-in is complete. For example, processor 31 sends notification data for check-in completion to user terminal 300 via the in-store communication network 7 and access point 6. Processor 31 includes identification data in the notification data to identify that it is a check-in completion notification.

[0073] In the user terminal 300, after requesting a check-in at ACT108 in Figure 9, the processor 301 proceeds to ACT109. As ACT109, processor 301 checks whether or not a notification of check-in completion has been received. If processor 301 cannot confirm the notification, it determines NO and proceeds to ACT110. As ACT110, processor 301 checks whether or not a check-in error has been reported. If processor 301 cannot confirm the report, it determines NO and returns to ACT109. Thus, the processor 301 waits for notification of check-in completion or error as ACT109 and ACT110. If the notification data for the aforementioned error notification is received by the wireless communication unit 306, the processor 301 determines YES at ACT110 and proceeds to ACT111.

[0074] As ACT111, processor 301 displays an error screen on touch panel 304. The error screen is a screen designated to inform the customer that they cannot check in. If the error screen is cleared, for example by manipulating a GUI element displayed on the error screen, processor 301 returns to ACT101.

[0075] On the other hand, if the notification data for the aforementioned check-in completion notification is received by the wireless communication unit 306, the processor 301 determines YES in ACT109 and proceeds to ACT112 in Figure 10. As ACT112, processor 301 displays a list screen on touch panel 304. The list screen shows a list of registered purchased items.

[0076] Figure 18 shows an example of the list screen SC1. The list screen SC1 includes display areas AR11 and 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 for the customer to declare that they want to cancel all purchased items and stop shopping. Button BU12 is a soft key for the customer to declare that they want to start scanning the items to be registered as purchased items. Button BU13 is a soft key for the customer to declare that they want to start the checkout process.

[0077] Figure 18 shows the SC1 list screen in a state where no purchased items have been registered yet. Therefore, display area AR11 shows "0" for both the total and total amount, and display area AR12 shows nothing.

[0078] In Figure 10, as ACT113, processor 301 checks whether or not the start of product scanning has been specified. If processor 301 does not find the specified action, it determines NO and proceeds to ACT114. As ACT114, processor 301 checks whether a change in quantity has been specified. If processor 301 does not find the specified change, it determines NO and proceeds to ACT115. As ACT115, processor 301 checks whether or not the shopping order has been canceled. If processor 301 does not find any such designation, it determines NO and proceeds to ACT116. As ACT116, processor 301 checks whether the commencement of accounting has been specified. If processor 301 cannot confirm the specified setting, it determines NO and returns to ACT113. Thus, processor 301 waits for one of the following to be specified as ACT113~ACT116: scan start, quantity, stop, or accounting start.

[0079] If a customer wishes to register an item as a purchased item, they specify the start of scanning by performing a predetermined operation, such as touching button BU12 on the list screen SC1. In response, processor 301 determines YES in ACT113 and proceeds to ACT117. As ACT117, processor 301 displays the registration screen on touch panel 304. The registration screen prompts the customer to scan the barcode representing the product code of the product to be registered as a purchased item.

[0080] Figure 19 shows 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 the image obtained by the camera 305. Message ME21 is a text message prompting the customer to scan the product's barcode. Button BU21 is a soft key for the customer to declare that they want to cancel scanning the product code.

[0081] For example, the processor 301 activates the camera 305, and overlays the image obtained from the camera 305 with lines representing the range of the display area AR21, and images representing the message ME21 and button BU21 to generate the registration screen SC2.

[0082] In Figure 10, as ACT118, the processor 301 checks whether the barcode has been read. At this time, the processor 301 analyzes the image obtained from the camera 305 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS application AP301, or as a process based on a separate application program for barcode reading. If the barcode cannot be read, the processor 301 determines NO and proceeds to ACT119. As ACT119, processor 301 checks whether or not the scan has been aborted. If processor 301 does not find any such indication, it determines NO and returns to ACT118. Thus, processor 301, as ACT118 and ACT119, waits to see if the barcode can be read or if a scan cancellation is specified. If the customer wishes to return to the list screen without performing this scan, they specify to cancel the scan by performing a predetermined operation, such as touching button BU21. In response, processor 301 determines YES in ACT119 and returns to ACT112.

[0083] When the registration screen appears on the touch panel 304, the customer points the camera 305 at the product so that the barcode displayed on the product they wish to register as a purchased item is captured in the display area AR21. In response, the processor 301 determines YES in ACT118 and proceeds to ACT120. As ACT120, the processor 301 requests registration from the mobile controller 3. The request data that the processor 301 sends here includes the data represented by the read barcode (hereinafter referred to as barcode data).

[0084] Now, in the mobile controller 3, after the processor 31 notifies the user that check-in is complete in ACT204 in Figure 14, it proceeds to ACT205. As ACT205, processor 31 checks whether registration has been requested. If processor 31 does not find the request, it determines NO and proceeds to ACT206.

[0085] As ACT206, processor 301 checks whether a quantity change has been requested. If processor 31 does not find such a request, it determines NO and proceeds to ACT207. As ACT207, processor 31 checks whether a request has been made to delete a purchased item. If processor 31 does not find such a request, it determines NO and proceeds to ACT208. As ACT208, processor 31 checks whether a cancellation of the purchased item has been requested. If processor 31 does not find such a request, it determines NO and proceeds to ACT209. As ACT209, processor 31 checks whether an accounting request has been made. If processor 31 does not find such a request, it determines NO and returns to ACT205. Thus, the processor 31 waits for a request to be made for one of the following actions: registration, quantity change, deletion, cancellation, or accounting, as ACT205 to ACT209. If the user terminal 300 requests registration as described above, the processor 31 determines YES in ACT205 and proceeds to ACT210 in Figure 15.

[0086] As ACT210, processor 31 forwards the registration request to virtual POS server 2, along with notification of the transaction code of the transaction being processed. At this time, processor 31 may forward the request data sent from user terminal 300 to virtual POS server 2 as is, or it may send the request data to virtual POS server 2 after some kind of processing and conversion. However, processor 31 notifies virtual POS server 2 of the barcode data included in the request data sent from 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 was read by a barcode scanner installed in an existing POS terminal, and attempts to register the purchased product using the same processing as an existing POS terminal. However, for some reason, the product code represented by the barcode data may not be registered in the product database. Also, products may have a barcode displayed that is different from the one representing the product code. In these cases, the processor 21 fails to register the purchased product and generates an error. In this way, the processor 21 registers the purchased product based on the reading of the barcode representing the product code registered in the product database. Thus, by executing information processing based on the virtual POS application AP21, the computer with the processor 21 as its central component functions as a registration means. The processor 21 manages the purchased product using the transaction database DB21.

[0088] The processor 21 transmits result data representing the result of such processing to the mobile controller 3. If the registration of the purchased product is successful, the processor 21 includes identification data to identify that it is a notification of legitimate registration, along with the product code, product name, and price of the registered product, in the result data. If an error occurs, the processor 21 includes identification data to identify that it is a notification of error, along with the barcode data sent in the registration request, in the result data.

[0089] In the mobile controller 3, the processor 31 forwards the registration request via ACT210, and then proceeds to ACT211. As ACT211, processor 31 acquires the result data transmitted from the virtual POS server as described above. Processor 31 stores the acquired result data in main memory 32 or auxiliary storage unit 33.

[0090] As ACT212, processor 31 updates the registration database DB32 based on the above result data. This update of the registration database DB32 is performed, for example, as follows:

[0091] Case 1: This is a notification of regular registration, and the data record DR2 associated with the transaction being processed does not contain registration data that includes the notified product code. In this case, processor 31 adds a new field after the last existing field 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" to indicate that it is not an error, the notified product name and price, a quantity set to "1", and a cancellation flag set to "0" to indicate that it has not been canceled. Thus, the registration data added in this case has the structure shown in the upper right of Figure 6.

[0092] The second case: It is a notification of regular registration, and the data record DR2 associated with the transaction being processed contains registration data that includes the notified product code, but the cancellation flag for that registration data is set to "1", indicating that it has been canceled. In this case, the processor 31 processes the data in the same manner as in the first case described above.

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

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

[0095] As a result of being updated by the processor 31, the registration database DB32 now represents a list of purchased items already registered on the virtual POS server 2, and also records any barcode reading errors. The processor 31 stores the barcode data sent in the registration request in the main memory 32 or auxiliary storage unit 33, and the above Case 4 In this case, the stored barcode data may be included in the registration data. In this case, the processor 21 in the virtual POS server 2 does not need to include the barcode data in the result data. The processor 31 may also extract the product code from the stored barcode data and process the first to third cases based on this product code. The product name and price may also be obtained by the processor 31 from the store server 1 or the like based on the product code.

[0096] As ACT213, processor 31 checks whether the registration was performed correctly. Then, if the result data indicates an error, processor 31 determines NO and proceeds to ACT214. As ACT214, processor 31 overwrites the "Confirmation Required" flag set in field F14 of data record DR1, which is associated with the transaction being processed in the transaction management database DB31, to "1". Processor 31 may write "1" regardless of the state before the overwrite, or it may leave it as is if the state before the overwrite was "1". If the result data indicates a valid registration, for example, the processor 31 determines YES in ACT213 and proceeds to ACT215. As ACT215, processor 31 checks whether the confirmation flag set in field F14 of data record DR1, which is associated with the transaction being processed in the transaction management database DB31, is set to "1". If the confirmation flag is not set to "1", processor 31 determines NO and proceeds to ACT216.

[0097] As ACT216, processor 31 checks whether the purchased item registered this time is an item requiring verification. If it is not an item requiring verification, processor 31 determines NO and proceeds to ACT217. Processor 31 also proceeds to ACT217 if the verification flag was changed to "1" in ACT214, or if it determined YES in ACT215 because the verification flag was already "1".

[0098] As ACT217, processor 31 instructs user terminal 300 to display the list screen. For example, processor 31 sends instruction data, which includes identification data to identify that it is an instruction to display the list screen, to user terminal 300 via the in-store communication network 7 and access point 6. Processor 31 includes the product code, product name, price, and quantity included in the data record DR2 associated with the transaction being processed in the registration database DB32 in the instruction data. Also, if the current registration is considered an error, processor 31 includes error data indicating that fact in the instruction data. After this, processor 31 returns to the waiting state of ACT205~ACT209 in Figure 14. Furthermore, the various instructions from the mobile controller 3 to the user terminal 300 described below are implemented in the same way as above, by sending instruction data containing 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 access point 6.

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

[0100] As ACT218, processor 31 instructs user terminal 300 to display a guidance screen. The instruction data used by processor 31 to instruct the display of the guidance screen includes the product code, product name, price, and quantity contained in data record DR2 associated with the transaction being processed in registration database DB32. After this, processor 31 returns to the standby state of ACT205~ACT209 in Figure 14.

[0101] After the processor 301 requests registration at ACT120 in Figure 10 at the user terminal 300, it proceeds to ACT121 in Figure 11. As ACT121, processor 301 checks whether or not the instruction to display the guidance screen has been received. If processor 301 does not receive the instruction, it determines NO and proceeds to ACT122. As ACT122, processor 301 checks whether or not the instruction to display the list screen has been received. If processor 301 does not receive the instruction, it determines NO and returns to ACT121.

[0102] Thus, the processor 301 waits for instructions to display the guidance screen or the list screen as ACT121 and ACT122. Then, as described above, if the mobile controller 3 instructs the processor 301 to display the list screen, it determines YES in ACT122, returns to ACT112 in Figure 10, and displays the list screen SC1 on the touch panel 304 again. At this time, the processor 301 sets the list screen SC1 to a screen that shows the product name, price, and quantity of the purchased products included in the instruction data.

[0103] Figure 20 shows an example of the list screen SC1 when purchased items have been registered. The list screen SC1 shown in Figure 20 is an example where 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, and one item with the product name "CCC" and a price of 1,024 yen have been registered as purchased items. None of these items are items that require confirmation. In the list screen SC1 shown in Figure 20, display area AR12 shows the product name, price, and quantity of these registered items. Display area AR11 shows "4" as the total number and "1,340" as the total amount. Note that the area enclosed by the dashed line to the left of the product name is the area for displaying icons. The dashed line representing this area is not actually displayed on the list screen SC1.

[0104] Figure 21 shows an example of the list screen SC1 when purchased items have been registered. The list screen SC1 shown in Figure 21 is an example where the following items have been registered as purchased items: 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 an item that requires confirmation. In the list screen SC1 shown in Figure 21, display area AR12 shows the product name, price, and quantity of these registered items. Display area AR11 shows "5" as the total number and "1,720" as the total amount. Next to the item with the product name "DDD", there is an icon IC11 indicating that it is an item with an age restriction for purchasers.

[0105] On the other hand, if the mobile controller 3 instructs the processor 301 to display the guidance screen as described above, it determines YES at ACT121 in Figure 11 and proceeds to ACT123. As ACT123, processor 301 displays a guidance screen on touch panel 304. The guidance screen informs the customer that verification by a store employee is required at checkout.

[0106] Figure 22 shows an example of the guidance screen SC3. The guidance screen SC3 is a screen displayed by overlaying window WI31 on the list screen SC1. Window WI31 includes message ME31 and button BU31. Message ME31 is a text message indicating that confirmation by a store employee is required at checkout. Button BU31 is a soft key for the customer to declare that they have confirmed the information on the guidance screen SC3. The processor 301 generates the list screen SC1, which displays the product names, prices, and quantities of the purchased items included in the instruction data, and then generates the guidance screen SC3 by overlaying window WI31 on it.

[0107] Once the customer has confirmed the information on the guidance screen SC3, they declare that they have confirmed it by performing a predetermined operation, such as touching button BU31 on the guidance screen SC3. In response, the processor 301 returns from ACT123 in Figure 11 to ACT112 in Figure 10 and displays the list screen SC1 on the touch panel 304 again. The processor 301 may also return from ACT123 to ACT112 if the elapsed time while the guidance screen SC3 is displayed reaches a predetermined time.

[0108] When a customer touches the area representing the quantity on the list screen SC1, the processor 301 displays a list box for specifying the quantity overlaid on the list screen SC1. When this list box is manipulated, the processor 301 receives this as a quantity specification. In this case, the processor 301 determines YES at ACT114 in Figure 10 and proceeds to ACT124 in Figure 11.

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

[0110] If the mobile controller 3 receives a request from the user terminal 300 to change the quantity as described above, the processor 31 determines YES at ACT206 in Figure 14 and proceeds to ACT220 in Figure 15. As ACT220, processor 31 forwards the quantity change request to virtual POS server 2, along with notification of the transaction code of the transaction being processed. At this time, processor 31 may forward the request data sent from user terminal 300 to virtual POS server 2 as is, or it may send the request data to virtual POS server 2 after some kind of processing has been converted. However, processor 31 notifies virtual POS server 2 of the quantity included in the request data sent from user terminal 300. Furthermore, if a specific data included in the request data is not a product code, processor 31 replaces that specific data with a product code.

[0111] In the virtual POS server 2, the processor 21 assumes that the quantity included in the request data sent from the mobile controller 3 was entered using an input device on an existing POS terminal, and modifies the quantity of the purchased items using the same processing as the existing POS terminal. The processor 21 then sends result data to the mobile controller 3, which represents the product code of the item whose quantity has been changed and the changed quantity.

[0112] In the mobile controller 3, the processor 31 forwards the quantity change request via ACT220, and then proceeds to ACT221. As ACT221, processor 31 acquires the result data transmitted from virtual POS server 2 as described above. Processor 31 stores the acquired result data in main memory 32 or auxiliary storage unit 33.

[0113] As ACT222, processor 31 updates the registration database DB32 based on the above result data. Specifically, processor 31 finds the registration data containing the notified product code from the data record DR2 associated with the transaction being processed. Then, processor 31 overwrites the number of items in the corresponding registration data with the number of items in the result data.

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

[0115] As ACT223, processor 31 instructs user terminal 300 to display the list screen. For example, processor 31 sends instruction data, which includes identification data to identify that it is an instruction to display the list screen, to user terminal 300 via the in-store communication network 7 and access point 6. Processor 31 includes the product code, product name, price, and quantity included in the registered data in the updated data record DR2, specifically the registered data with a cancellation flag of "0", in the instruction data. After this, processor 31 returns to the standby state of ACT205~ACT209 in Figure 14.

[0116] Now, if the specified number is 0, the processor 301 at the user terminal 300 determines YES in ACT124 in Figure 11 and proceeds to ACT126. As ACT126, processor 301 displays a delete screen on touch panel 304. The delete screen informs the customer that the item specified to have a quantity of 0 will be removed from the purchased items. The delete screen includes a delete button to specify deletion and a return button to return to the state before specifying the quantity change without changing the quantity.

[0117] As ACT127, processor 301 checks whether deletion has been specified. If processor 301 cannot confirm the specification, it determines NO and proceeds to ACT128. As ACT128, processor 301 checks whether a return statement has been specified. If processor 301 cannot find the specified return statement, it determines NO and returns to ACT127. Thus, processor 301 waits for 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 specifying the quantity change, they specify the return by performing a predetermined operation, such as touching the return button on the delete screen. In response, the processor 301 determines YES in ACT128, returns to ACT112 in Figure 10, and displays the list screen SC1 on the touch panel 304 again. In this case, the registration status of the purchased items is not changed, so the processor 301 displays the list screen SC1 on the touch panel 304 again in the same state as it was displayed before the delete screen was displayed.

[0119] If the customer is certain that they want to delete the item, they specify deletion by performing a predetermined operation, such as touching the delete button on the delete screen. In response, processor 301 determines YES in ACT127 and proceeds to ACT129. As ACT129, processor 301 requests deletion from mobile controller 3. The request data sent by processor 301 here includes specific data to identify the product designated for deletion.

[0120] If the mobile controller 3 receives a request from the user terminal 300 to delete the data, as described above, the processor 31 determines YES at ACT207 in Figure 14 and proceeds to ACT224 in Figure 16. As ACT224, processor 31 forwards the deletion request to virtual POS server 2, along with notification of the transaction code of the transaction being processed. At this time, processor 31 may forward the request data sent from user terminal 300 to virtual POS server 2 as is, or it may send the request data to virtual POS server 2 after some kind of processing has been converted. However, if a specific data included in the request data is not a product code, processor 31 replaces that specific data with a product code.

[0121] In the virtual POS server 2, the processor 21 treats the request data sent from the mobile controller 3 as a delete instruction entered via an input device on an existing POS terminal, and removes the target product from the purchased items using the same processing as an existing POS terminal. The processor 21 then sends result data representing the product code of the product removed from the purchased items to the mobile controller 3.

[0122] In the mobile controller 3, the processor 31 forwards the deletion request in ACT224, and then proceeds to ACT225. As ACT225, processor 31 acquires the result data transmitted from the virtual POS server as described above. Processor 31 stores the acquired result data in main memory 32 or auxiliary storage unit 33.

[0123] As ACT226, processor 31 updates the registration database DB32 based on the above result data. Specifically, processor 31 finds the registration data containing the notified product code from the data record DR2 associated with the transaction being processed. Then, processor 31 changes the cancellation flag 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 auxiliary storage unit 33, and upon receiving result data indicating that the deletion is complete, change the cancellation flag for the registration data relating to the product identified 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] As ACT227, processor 301 checks whether the deleted item is an item requiring verification. If it is an item requiring verification, processor 301 determines it is YES and proceeds to ACT228. As ACT228, processor 301 checks whether there are any other items requiring verification in the purchased items of the transaction being processed. If there are no such items, processor 301 determines NO and proceeds to ACT229. In other words, if the purchase items no longer contain any items requiring verification after the item deletion, processor 301 proceeds to ACT229.

[0126] As ACT229, processor 301 changes the "requires confirmation" flag set in field F14 of data record DR1, which is associated with the transaction being processed in the transaction management database DB31, to "0". As ACT230, processor 31 instructs user terminal 300 to display the list screen. For example, processor 31 sends instruction data, which includes identification data to identify that it is an instruction to display the list screen, to user terminal 300 via the in-store communication network 7 and access point 6. Processor 31 includes the product code, product name, price, and quantity included in the registered data in the updated data record DR2, where the cancellation flag is "0", in the instruction data. After this, processor 31 returns to the standby state of ACT205~ACT209 in Figure 14. If processor 31 determines NO in ACT227 because the deleted product is not a product requiring confirmation, or if it determines YES in ACT228 because there is another product requiring confirmation, it skips ACT229 and ACT230 and returns to the standby state of ACT205~ACT209 in Figure 14.

[0127] Now, at the user terminal 300, after the processor 301 requests a quantity change in ACT125, or a deletion in ACT129, it proceeds to ACT130. As ACT130, the processor 301 waits for an instruction to display the list screen. Then, in response to a request to change the quantity or to delete an item, if the mobile controller 3 instructs the display of the list screen as described above, the processor 301 determines YES and returns to ACT112 in Figure 10, and displays the list screen SC1 on the touch panel 304 again. At this time, the processor 301 sets the list screen SC1 to show the product name, price, and quantity of the purchased items included in the instruction data. In this case, since the registration status of the purchased items has changed, the processor 301 will display a list screen SC1 on the touch panel 304 that shows a different state of purchased items than the one displayed when the quantity change or deletion was specified.

[0128] If a customer wishes to cancel all previously registered purchases and abandon their shopping, they specify the cancellation by performing a predetermined operation, such as touching button BU11 on the list screen SC1. In response, processor 301 determines YES in ACT115 and proceeds to ACT131 in Figure 11. As ACT131, processor 301 displays a cancellation screen on touch panel 304. The cancellation screen informs the customer that all previously registered purchased items will be canceled. The cancellation screen includes an execute button to specify that the cancellation be performed, and a return button to specify that the user should return to the state before specifying the quantity change without changing the quantity.

[0129] As ACT132, processor 301 checks whether a cancellation operation has been specified. If processor 301 cannot confirm the specification, it determines NO and proceeds to ACT133. As ACT133, processor 301 checks whether a return statement has been specified. If processor 301 cannot find the specified return statement, it determines NO and returns to ACT132. Thus, processor 301 waits for ACT132 and ACT133 to be specified as either cancel execution or return.

[0130] If the customer wishes to continue shopping, they specify a return by performing a predetermined operation, such as touching the return button on the cancellation screen. In response, the processor 301 determines YES in ACT133, returns to ACT112 in Figure 10, and displays the list screen SC1 on the touch panel 304 again. In this case, the registration status of the purchased items is not changed, so the processor 301 displays the list screen SC1 on the touch panel 304 again in the same state as it was displayed before the cancellation screen was displayed.

[0131] If a customer wishes to cancel their purchase, they specify that they want to cancel by performing a predetermined action, such as touching the execute button on the cancellation screen. In response, processor 301 determines YES in ACT132 and proceeds to ACT134. As ACT134, the processor 301 requests cancellation from the mobile controller 3.

[0132] If the mobile controller 3 receives a cancellation request from the user terminal 300 as described above, the processor 31 determines YES at ACT208 in Figure 14 and proceeds to ACT231 in Figure 16. As ACT231, processor 31 forwards the cancellation request to virtual POS server 2, along with notification of the transaction code of the transaction being processed. At this time, processor 31 may forward the request data sent from user terminal 300 to virtual POS server 2 as is, or it may send the request data to virtual POS server 2 after some kind of processing has been converted.

[0133] In the virtual POS server 2, the processor 21 treats the request data sent from the mobile controller 3 as a cancellation instruction entered via an input device on an existing POS terminal, and, using the same processing as an existing POS terminal, removes all registered products associated with the notified transaction code from the list of purchased items. The processor 21 then sends result data indicating that the cancellation is complete to the mobile controller 3.

[0134] In the mobile controller 3, after the processor 31 forwards the deletion request in ACT231, it proceeds to ACT232. As ACT232, processor 31 acquires the result data transmitted from the virtual POS server as described above. Processor 31 stores the acquired result data in main memory 32 or auxiliary storage unit 33.

[0135] As ACT233, processor 31 updates the registration database DB32 based on the above result data. Specifically, processor 31 changes the cancellation flag, which is set to "0", to "1" for all registration data included in data record DR2 associated with the transaction being processed.

[0136] As ACT234, processor 301 changes the "requires confirmation" flag set in field F14 of data record DR1, which is associated with the transaction being processed in the transaction management database DB31, to "0". As ACT235, processor 31 notifies user terminal 300 of the cancellation. After this, processor 31 returns to the standby state of ACT205~ACT209 in Figure 14.

[0137] Now, at the user terminal 300, the processor 301 requests cancellation in ACT134, and then proceeds to ACT135. As ACT135, processor 301 waits for a cancellation notification from mobile controller 3. Then, as described above, if a cancellation notification is received, processor 301 determines it is YES and returns to ACT101 in Figure 9.

[0138] Once the customer has registered all the items they wish to purchase, they proceed to checkout. At this point, the customer initiates checkout by performing a predetermined operation, such as touching button BU13 on the list screen SC1. In response, processor 301 determines YES at ACT116 in Figure 10 and proceeds to ACT136. As ACT136, processor 301 requests accounting from mobile controller 3.

[0139] If the mobile controller 3 receives a request for payment from the user terminal 300 as described above, the processor 31 determines YES at ACT209 in Figure 14 and proceeds to ACT236 in Figure 17. As ACT236, processor 31 checks whether the "Confirmation Required" flag set in field F14 of data record DR1 associated with the transaction being processed in the transaction management database DB31 is "1". If the "Confirmation Required" flag is "1", it determines YES and proceeds to ACT237. In other words, processor 31 proceeds to ACT237 if the purchased goods include items requiring confirmation or if there are items that have not been registered correctly. In the following, this state where the "Confirmation Required" flag is "1" will be referred to as the "Confirmation Required" state. As ACT237, the processor 31 instructs the user terminal 300 to display a confirmation screen.

[0140] Now, at the user terminal 300, the processor 301 requests payment in ACT136 in Figure 10, and then proceeds to ACT137. As ACT137, processor 301 checks whether or not the instruction to display the confirmation screen has been received. If processor 301 cannot confirm the instruction, it determines NO and proceeds to ACT138. As ACT138, processor 301 checks whether or not the instruction to display the accounting screen has been received. If processor 301 cannot confirm the instruction, it determines NO and returns to ACT137. Thus, the processor 301 waits for instructions to display the confirmation screen or the accounting screen as ACT137 and ACT138. Then, as described above, if the mobile controller 3 instructs the processor 301 to display the confirmation screen, it determines YES in ACT137 and proceeds to ACT139 in Figure 12. As ACT139, processor 301 displays a confirmation screen. The confirmation screen is designed to prompt the customer to contact a store employee to confirm the items requiring confirmation.

[0141] Figure 23 shows an example of the confirmation screen SC4. The confirmation screen SC4 is a screen that overlays window WI41 onto the list screen SC1 that was displayed immediately before. Window WI41 contains message ME41 and buttons BU41 and BU42. Message ME41 is a text message indicating that confirmation by a store employee is required. Button BU41 is a soft key for the customer to specify that they want to receive confirmation from a store employee. Button BU42 is a soft key for the customer to specify that they want to return to product registration.

[0142] If a customer decides to have their purchases checked by a store employee, they specify this by performing a predetermined action, such as touching button BU41. If a customer decides to cancel the transaction and return to registering their items, they specify this by performing a predetermined action, such as touching button BU42.

[0143] In Figure 12, processor 301, as ACT140, checks whether a confirmation has been specified. If the corresponding confirmation cannot be found, processor 301 determines NO and proceeds to ACT141. As ACT141, processor 301 checks whether a return statement has been specified. If the processor 301 does not find the specified return statement, it determines NO and returns to ACT140. Thus, processor 301 waits for confirmation or a return to be specified as ACT140 and ACT141. If confirmation is specified as described above, processor 301 determines YES in ACT140 and proceeds to ACT142.

[0144] As ACT142, the processor 301 displays a release screen on the touch panel 304. The release screen is a screen that allows the user terminal 300 to read a barcode to release the "requires confirmation" status.

[0145] Figure 24 shows an example of the release screen SC5. The unlock screen SC5 includes a display area AR51, a message ME51, and a button BU51. The display area AR51 displays the image obtained by the camera 305. Message ME51 is a text message prompting the store clerk to scan the unlock barcode, which is in a "confirmation required" state. Button BU51 is a soft key for the customer or store clerk to declare that they want to stop scanning the unlock barcode. For example, the processor 301 activates the camera 305, and overlays the image obtained from the camera 305 with lines representing the range of the display area AR51, and images representing the message ME51 and the button BU51 to generate the release screen SC5.

[0146] The customer asks the store clerk to verify the purchase. The clerk, for example, verifies that if the purchased items include items requiring verification, the sale of those items is permitted. The clerk also verifies the items the customer is carrying and confirms that there are no unregistered items. If all of these conditions are met, the clerk determines that the payment is permitted and holds the unlock barcode up to the camera 305 so that the unlock barcode is visible in the display area AR51. The clerk should carry a card or similar item with the unlock barcode printed on it for this purpose. Alternatively, the clerk can display the unlock barcode on the screen of their information terminal. Preferably, the unlock barcode is different for each store or business. However, it is permissible for the same unlock barcode to be used in different stores or by different businesses. Furthermore, by changing the legitimate unlock barcode, for example, daily, it is possible to prevent fraud if the unlock barcode is obtained by a customer for any reason.

[0147] If the store clerk confirms that the sale of an item requiring verification is not permitted, or that the customer is possessing an unregistered item, they will indicate a return to product registration by performing a predetermined operation, such as touching button BU51. Alternatively, if the customer decides to return to product registration without requesting verification from the store clerk, they will indicate a return to product registration by performing a predetermined operation, such as touching button BU51. Further actions regarding items requiring verification or unregistered items may be taken as appropriate by the customer or store clerk. For example, the customer may operate the user terminal 300 to remove the item requiring verification from their purchase. For example, the customer may perform the procedure to make the item requiring verification available for purchase. For example, the customer may use the user terminal 300 to register the unregistered item as a purchased item by reading the barcode representing the item's product code. For example, a store clerk may use a special operation for store clerks on the user terminal 300, or an operation on a store clerk's terminal, to register the unregistered item as a purchased item. For example, the store clerk may collect the unregistered item. In this case, if necessary, the store clerk may take measures to register the item's product code in the product database.

[0148] As ACT143, the processor 301 checks whether the barcode has been read. At this time, the processor 301 analyzes the image obtained from the camera 305 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS application AP301, or as a process based on a separate application program for barcode reading. If the barcode cannot be read, the processor 301 determines NO and proceeds to ACT144. As ACT144, processor 301 checks whether a return statement has been specified. If the specified statement is not found, processor 301 determines NO and returns to ACT143. Thus, processor 301, as ACT143 and ACT144, waits to see if a barcode can be read or if a return value is specified.

[0149] If a return is specified as described above, processor 301 determines YES in ACT144 and proceeds to ACT145. Furthermore, if the confirmation screen SC4 is displayed on the touch panel 304, and a return is specified as described above, processor 301 determines YES in ACT141 and proceeds to ACT145. As ACT145, processor 301 requests mobile controller 3 to return to product registration. Then processor 301 returns to ACT112 in Figure 10.

[0150] Now, in the mobile controller 3, the processor 31 instructs the display of the confirmation screen at ACT237 in Figure 17, and then proceeds to ACT238. As ACT238, processor 31 checks whether a release has been requested. If processor 31 does not find such a request, it determines NO and proceeds to ACT239. As ACT239, processor 31 checks whether a return request has been made. If processor 31 cannot confirm the request, it determines NO and returns to ACT238. Thus, processor 31 waits for a request to cancel or return as ACT238 and ACT239. Then, as described above, if the user terminal 300 requests a return to product registration, processor 31 determines YES in ACT239 and returns to the waiting state of ACT205~ACT209 in Figure 14. In other words, both the mobile controller 3 and the user terminal 300 return to the state where product registration is performed.

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

[0152] As ACT147, processor 301 requests mobile controller 3 to release the confirmation required state. The request data that processor 301 sends here includes the saved barcode data mentioned above. The request data that processor 301 sends here also includes the authentication data contained in the check-in data saved in ACT107 in Figure 9.

[0153] When a release request is made from the user terminal 300 to the mobile controller 3, the processor 31 in the mobile controller 3 determines YES at ACT238 in Figure 17 and proceeds to ACT240. As ACT240, processor 31 performs authentication processing. For example, processor 31 extracts barcode data and authentication data from request data and saves them to main memory 32 or auxiliary storage unit 33. AP301 The processor 31 performs information processing based on this, and the computer with the processor 31 as its central component functions as an acquisition means. The processor 31 then performs a process to verify whether the read barcode is a legitimate barcode for deactivation based on the barcode data and authentication data thus acquired. This authentication process can be performed, for example, by one of the following methods.

[0154] (1) The processor 31 determines that a legitimate barcode for deactivation has been read when the barcode data and the authentication data match. (2) The processor 31 processes the barcode data using a predetermined algorithm and determines that a legitimate barcode for deactivation has been read if the resulting data matches the authentication data. (3) The processor 31 processes the authentication data using a predetermined algorithm and determines that a legitimate barcode for deactivation has been read if the resulting data matches the barcode data. (4) The processor 31 processes the barcode data using a predetermined first algorithm and the authentication data using a predetermined second algorithm. If the two resulting data match, it determines that a legitimate barcode for deactivation has been read. In addition, any process can be applied to confirm that the barcode data and authentication data have a predetermined relationship. The processor then determines that a legitimate barcode for deactivation has been read when it has confirmed that the barcode data and authentication data have a predetermined relationship.

[0155] As ACT241, processor 31 checks whether authentication was successful or not. If authentication fails, processor 31 determines NO and proceeds to ACT242. As ACT242, processor 31 instructs user terminal 300 to display a warning screen. After this, processor 31 returns to the standby state for ACT238 and ACT239.

[0156] After the processor 301 requests release at ACT147 in Figure 12 at the user terminal 300, it proceeds to ACT148. As ACT148, processor 301 checks whether or not the warning screen has been instructed to be displayed. If processor 301 does not find the instruction, it determines NO and proceeds to ACT149. As ACT149, processor 301 checks whether or not the instruction to display the accounting screen has been received. If processor 301 does not receive the instruction, it determines NO and returns to ACT148. Thus, the processor 301 waits for instructions to display a warning screen or an accounting screen as ACT148 and ACT149. Then, as described above, if the mobile controller 3 instructs the processor 301 to display a warning screen, it determines YES in ACT148 and proceeds to ACT150.

[0157] As ACT150, processor 301 displays a warning screen on touch panel 304. The warning screen is designed to alert the store clerk that the barcode they scanned for unlocking is incorrect.

[0158] Figure 25 shows an example of the warning screen SC6. The warning screen SC6 is a screen that overlays window WI61 onto the previously displayed deactivation screen SC5. Window WI61 contains message ME61 and button BU61. Message ME61 is a text message indicating that the scanned barcode is incorrect. Button BU61 is a soft key used by store staff to confirm that they have seen the notification on warning screen SC6. If the processor 301 is instructed to dismiss the warning screen SC6 by a predetermined operation, such as touching the button BU61 shown on the warning screen SC6, it returns to ACT142.

[0159] In the mobile controller 3, if the authentication process in ACT240 in Figure 17 is successful, the processor 31 determines YES in ACT241 and proceeds to ACT243. However, if the verification flag is "0", the processor 31 determines NO in ACT236 and proceeds to ACT243. As ACT243, processor 31 instructs user terminal 300 to display the accounting screen. After this, processor 31 initiates the process described below to settle the payment for the goods registered as purchased items by the virtual POS server 2 or the accounting machine 5. In other words, processor 31 allows the start of the payment process if the acquired barcode data is deactivation data, which has a predetermined relationship with the authentication data. Thus, the smartphone POS app... AP301 By having the processor 31 perform information processing based on this, the computer with the processor 31 as its central component functions as a control means.

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

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

[0162] Figure 26 shows an example of the accounting screen SC7. The accounting 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. Message ME71 is a text message prompting the customer to specify whether to perform the payment operation on the user terminal 300 or the accounting machine 5. Button BU71 is a soft key for the customer to specify the user terminal 300. Button BU72 is a soft key for the customer to specify the accounting machine 5.

[0163] If a customer wishes to perform the payment operation using user terminal 300, they select user terminal 300 by performing a predetermined operation such as touching button BU71. Alternatively, if a customer wishes to perform the payment operation using accounting machine 5, they select accounting machine 5 by performing a predetermined operation such as touching button BU72.

[0164] As ACT152, processor 301 checks whether user terminal 300 has been specified. If the specification cannot be confirmed, processor 301 determines NO and proceeds to ACT153. As ACT153, processor 301 checks whether accounting machine 5 has been specified. If the specification cannot be confirmed, processor 301 determines NO and returns to ACT152. Thus, the processor 301 waits for either the user terminal 300 or the accounting machine 5 to be specified as ACT152 and ACT153. If the user terminal 300 is specified as described above, the processor 301 determines YES in ACT152 and proceeds to ACT154.

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

[0166] Furthermore, if the accounting machine 5 is specified as described above, the processor 301 determines YES in ACT153 and proceeds to ACT155. As ACT155, processor 301 displays the accounting barcode screen on touch panel 304. The accounting barcode screen displays an accounting barcode that represents the data necessary for the accounting machine 5 to obtain transaction details from the virtual POS server 2. Although detailed diagrams of the process are omitted, processor 301 obtains the accounting barcode from the virtual POS server 2 via mobile controller 3 and displays the accounting barcode on the accounting barcode screen.

[0167] The customer has the scanner on the accounting machine 5, which is not being used by another customer, read the accounting barcode. In response, the accounting machine 5 retrieves data about the transaction from the virtual POS server 2 according to the data represented by the accounting barcode, and performs processing to settle the payment amount calculated based on this data. Once the payment is complete, the accounting machine 5 notifies the virtual POS server 2 of this fact. When the processor 21 on the virtual POS server 2 receives notification of payment completion from the accounting machine 5, it notifies the mobile controller 3 of the payment completion. Alternatively, the payment completion from the accounting machine 5 may be notified directly from the accounting machine 5 to the mobile controller 3. Thus, the accounting machine 5 is one example of a payment method.

[0168] After the processor 31 instructs the mobile controller 3 to display the accounting screen at ACT243 in Figure 17, it proceeds to ACT244. As ACT244, processor 31 checks whether a payment has been requested. If processor 31 cannot confirm the request, it determines NO and proceeds to ACT245. As ACT245, processor 31 checks whether or not a payment completion notification has been received. If processor 31 cannot confirm the notification, it determines NO and returns to ACT244. Thus, the processor 31 waits for a payment request or payment completion notification as ACT244 and ACT245. If a payment is requested from the user terminal 300 as described above, the processor 31 determines YES in ACT244 and proceeds to ACT246.

[0169] As ACT246, processor 31 forwards the settlement request to virtual POS server 2, along with notification of the transaction code of the transaction being processed. At this time, processor 31 may forward the request data sent from user terminal 300 to virtual POS server 2 as is, or it may send the request data to virtual POS server 2 after some kind of processing has been converted.

[0170] In the virtual POS server 2, the processor 21 treats the request data sent from the mobile controller 3 as a payment instruction entered via an input device on an existing POS terminal. Using the same processing as an existing POS terminal, it calculates the price for the transaction identified by the notified transaction code and performs processing to settle the payment based on the payment data. This settlement process includes, for example, a payment request to a payment server (not shown). The processor 21 then sends result data indicating that the payment has been completed to the mobile controller 3. Thus, by having the processor 21 perform information processing based on the virtual POS application AP21, the computer with the processor 21 as its central component functions as a payment means.

[0171] In the mobile controller 3, after the processor 31 transfers the payment request in ACT246, it proceeds to ACT247. As ACT247, processor 31 waits for notification of payment completion from virtual POS server 2. Then, if processor 31 receives the result data indicating payment completion sent by virtual POS server 2 as described above via communication interface 34, it determines YES and proceeds to ACT248. Also, as described above, if processor 31 is notified of payment completion at accounting machine 5, it determines YES in ACT245 and proceeds to ACT248. As ACT248, processor 31 notifies user terminal 300 that payment is complete.

[0172] At the user terminal 300, the processor 301 requests payment from the mobile controller 3 in ACT154 of ACT14, or after displaying the payment barcode screen in ACT155, proceeds to ACT156. As ACT156, processor 301 waits for notification of payment completion. Then, as described above, if processor 301 receives notification of payment completion from mobile controller 3, it determines YES and proceeds to ACT157. As ACT157, processor 301 displays a completion screen on touch panel 304. The completion screen is a screen that informs the customer that the payment has been completed.

[0173] Once the customer has confirmed the completion screen, they declare that they have confirmed it by performing a predetermined operation, such as touching a button displayed on the completion screen. In response, the processor 301 proceeds to ACT158. The processor 301 may also proceed to ACT158 if the elapsed time while the completion screen is displayed reaches a predetermined time.

[0174] As ACT158, processor 301 displays a scan screen for checkout on touch panel 304. The scan screen for checkout is for reading the 2D code TC2 for checkout. For example, processor 301 activates camera 305 and generates the scan screen by overlaying a text message prompting the customer to read the 2D code TC2 and a line indicating the position where the 2D code TC2 should be held over the image obtained by camera 305.

[0175] When the customer sees the scan screen for checkout on the touch panel 304, they point the camera 305 towards the 2D code TC2, which is displayed near the exit of the store, so that it is visible on the scan screen.

[0176] As ACT159, processor 301 waits for the 2D code to be read. At this time, processor 301 repeatedly analyzes the image obtained by camera 305 and attempts to read the 2D code. This reading of the 2D code may be performed as processing based on the smartphone POS application AP301, or as processing based on a separate application program for reading 2D codes. If processor 301 has successfully read the 2D code, it determines YES and proceeds to ACT160.

[0177] As ACT160, processor 301 checks whether the data represented by the scanned 2D code is checkout data. If it is not checkout data, processor 301 determines NO and returns to ACT159. At this point, processor 301 may display a screen on touch panel 304 informing the customer that an incorrect 2D code has been scanned.

[0178] If processor 301 confirms that the data represented by the read 2D code is checkout data, it determines YES in ACT160 and proceeds to ACT161. As ACT161, processor 301 requests checkout from mobile controller 3.

[0179] In the mobile controller 3, after the processor 31 notifies the completion of payment in ACT248 in Figure 17, it proceeds to ACT249. As ACT249, processor 31 waits for a checkout request. Then, if a checkout request is received from the user terminal 300 as described above, processor 31 determines it is YES and proceeds to ACT250.

[0180] As ACT250, processor 31 executes the checkout process. The checkout process involves clearing data stored in main memory 32 and auxiliary storage unit 33 for managing the transaction being processed. The virtual POS server 2 may terminate processing related to the transaction once the payment is complete, or it may terminate processing related to the transaction in response to instructions from the mobile controller 3. In the latter case, processor 31 issues the above instructions to virtual POS server 2 during the checkout process. In addition, a history database representing the history of user operations, including incorrect barcode scans, may be managed by the store server 1, virtual POS server 2, mobile controller 3, or another server not shown. In this case, processor 31 performs processing during the checkout process to update the history database to reflect the history of operations related to the current transaction. As ACT251, processor 31 notifies user terminal 300 that checkout is complete. Then processor 31 terminates the information processing shown in Figures 14 to 17.

[0181] At the user terminal 300, the processor 301 requests checkout in ACT161 in Figure 13, and then proceeds to ACT162. As ACT162, processor 301 waits for notification that checkout is complete. Then, as described above, if processor 301 receives notification of checkout completion from mobile controller 3, it determines YES and proceeds to ACT163. As ACT163, processor 301 clears various data temporarily used for the current purchase, such as the check-in data saved in ACT107 in Figure 9. After this, processor 301 returns to ACT101 in Figure 9.

[0182] As described above, according to the transaction processing system of this embodiment, the user terminal 300 does not proceed to the accounting process if the status is in a state requiring confirmation. In other words, if there are items that the customer attempted to register as purchased items but were unable to register correctly, the accounting process will not proceed. This prevents such items from being taken out without being paid for.

[0183] Then, once the user terminal 300 has read the legitimate barcode for unlocking, it proceeds to the payment process under authentication by the mobile controller 3. In this way, the verification by the store staff can be completed at the user terminal 300, and payment can be completed without using a checkout counter staffed by a store employee.

[0184] Furthermore, according to the transaction processing system of this embodiment, in order to release the status requiring confirmation, the store clerk only needs to have the user terminal 300 read the release barcode, so this task does not place a significant burden on the store clerk.

[0185] Furthermore, according to the transaction processing system of this embodiment, in order to release the "requires verification" status, the store clerk only needs to perform an operation on the user terminal 300. Therefore, the customer can either stop a store clerk patrolling the store and request that the "requires verification" status be released, or go to a service counter or other location and request that a store clerk stationed there release the status. In other words, by providing multiple store clerks in different areas with barcodes for releasing the status, it is possible to increase the flexibility of releasing the "requires verification" status. However, which store clerks are given the barcodes for releasing the status will depend on the circumstances of each store or business. In other words, by deciding which store clerks are given the barcodes for releasing the status, it is possible to change the form of release that is permitted according to the circumstances of the store or business.

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

[0187] This embodiment can be modified in various ways as follows: The data required to clear the "requires verification" status may be obtained by manually inputting the specified data, or by any other method, such as obtaining data electronically recorded on a recording medium via proximity wireless communication.

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

[0189] You may have a store employee verify the transaction when using the self-checkout machine, but allow the user to proceed with payment via the machine without prior verification by a store employee at their terminal.

[0190] If the valid deactivation barcode is scanned at any time before the customer finishes registering the product, the "Confirmation Required" flag may be set to "0" to deactivate the "Confirmation Required" status. In this way, if the customer sees a store employee while browsing the store, they can request that employee deactivate the "Confirmation Required" status. However, in this case, if the customer registers a product requiring confirmation as a purchased item after the "Confirmation Required" status has been deactivated, the "Confirmation Required" flag will be set to "1" and the product will re-enter the "Confirmation Required" status, requiring deactivation again.

[0191] It is acceptable to mark only items that could not be registered as purchased items as requiring confirmation.

[0192] The functions of the virtual POS server 2 and the mobile controller 3 may be implemented on a single server.

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

[0194] Each of the functions realized by processors 11, 21, 31, 41, and 301 through information processing can also be partially or entirely realized by hardware that performs non-program-based information processing, such as logic circuits. Furthermore, each of the above functions can also be realized by combining the above-mentioned hardware, such as logic circuits, with software control.

[0195] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. The invention described in the original claims of this application is listed below. [Note 1] A registration means for registering products specified by operations on the terminal as products available for purchase by the customer using the terminal, A payment means that processes a payment to allow the customer to pay for the goods registered by the registration means, If there are products that could not be registered as purchase targets by the registration means, an acquisition means for acquiring data specified by an operation on the terminal, A transaction processing system comprising: a control means that allows the settlement means to initiate the settlement process when the data acquired by the acquisition means is predetermined release data. [Note 2] The transaction processing system according to Note 1, wherein the control means determines that the data acquired by the acquisition means is the release data when the data acquired by the acquisition means and the authentication data are in a predetermined relationship. [Note 3] The transaction processing system described in Note 2, wherein the control means uses authentication data obtained via the terminal when the customer enters the store. [Note 4] The acquisition means is a transaction processing system according to any one of Notes 1 to 3, which acquires barcode data represented by a barcode read by the terminal as the data. [Note 5] Used in a transaction processing system comprising: a registration means for registering products specified by operation on a terminal as products to be purchased by a customer using the terminal; and a settlement means for processing a settlement to allow the customer to pay for the products registered by the registration means. If there are products that could not be registered as purchase targets by the registration means, an acquisition means for acquiring data specified by an operation on the terminal, A transaction support device comprising: a control means that allows the settlement means to initiate the settlement process when the data acquired by the acquisition means is predetermined release data. [Note 6] A computer provided in a transaction support device used in a transaction processing system that includes a registration means for registering products specified by operation on a terminal as products to be purchased by a customer using the terminal, and a settlement means for processing settlement operations to allow the customer to pay for the products registered by the registration means, If there are products that could not be registered as purchase targets by the registration means, an acquisition means for acquiring data specified by an operation on the terminal, An information processing program to function as a control means that allows the settlement means to initiate the settlement process when the data acquired by the acquisition means is predetermined release data. [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 for managing transactions of goods within a store; and a terminal that can communicate with the store system, is movable with the customer, and is operated by the customer, The aforementioned terminal is A registration request means that requests the store system to register the product to be registered as an item to be purchased, A payment request means for requesting payment from the store system, A means of obtaining unlock data by reading information held by the store clerk, In response to the acquisition of release data by the acquisition means, a notification means for notifying the store system of the release data, It is equipped with, The aforementioned store system is A setting means for setting a status requiring confirmation regarding the registration of products as items to be purchased in response to a request by the aforementioned registration request means, If the release data notified by the notification means is legitimate release data for release, the release means releases the status requiring confirmation, A payment means that, in response to a request by the payment request means, if the customer is not in the state requiring confirmation, performs a payment process to allow the customer to pay for the goods registered as items to be purchased. A transaction processing system equipped with the following features.

2. The acquisition means acquires the release data before the request by the payment request means is made. The transaction processing system according to claim 1.

3. A transaction processing system comprising a store system for managing transactions of goods within a store, and a terminal that is communicable with the store system, is movable with the customer, and is operated by the customer, wherein the terminal device used as the terminal is A registration request means that requests the store system to register the product to be registered as an item to be purchased, A payment request means for requesting payment from the store system, A means of obtaining unlock data by reading information held by the store clerk, In response to the acquisition of release data by the acquisition means, a notification means for notifying the store system of the release data, A terminal device equipped with the following.

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

5. A terminal device that can communicate with a store system and is movable with the customer and operated by the customer, comprising: setting means for setting a status requiring confirmation with respect to the registration of a product to be registered as a purchase item; release means for releasing the status requiring confirmation when the release data is legitimate release data for release; and payment means for performing a payment process to allow the customer to pay for the product already registered as a purchase item if the status requiring confirmation is not present, the terminal device being movable with the customer and operated by the customer, A registration request means that requests the store system to register the product to be registered as an item to be purchased, A payment request means for requesting payment from the store system, An acquisition means for obtaining the aforementioned unlock data by reading information held by the store clerk, In response to the acquisition of the release data by the acquisition means, a notification means for notifying the store system of the release data, A terminal device equipped with the following.

6. The acquisition means acquires the release data before the payment request means makes a request. The terminal device according to claim 5.

7. A computer provided in a terminal device that is communicable to a store system and is movable with the customer and operated by the customer, comprising: setting means for setting a status requiring confirmation regarding the registration of a product to be registered as a purchase item; release means for releasing the status requiring confirmation when the release data is legitimate release data for release; and if the status requiring confirmation is not present, release means for processing a payment to allow the customer to pay for the product already registered as a purchase item. A registration request means that requests the store system to register the product to be registered as an item to be purchased, A payment request means for requesting payment from the store system, An acquisition means for obtaining the aforementioned unlock data by reading information held by the store clerk, In response to the acquisition of the release data by the acquisition means, a notification means for notifying the store system of the release data, An information processing program that enables a function to work.

8. A store system that is mobile with the customer and can communicate with a terminal operated by the customer, and which manages transactions of goods within the store, A setting means for setting a status requiring confirmation regarding the registration of a product to be purchased in response to a registration request from a terminal for the product to be registered as a purchase item, A release means that, when the release data obtained by reading the information held by the store clerk at the terminal and notified from the terminal is legitimate release data for release, releases the status requiring confirmation. A payment means that, in response to a payment request from the terminal, if the status does not require verification, processes a payment to allow the customer to pay for the registered product to be purchased. A store system equipped with the following features.

9. Used in a transaction processing system that is movable with the customer and includes setting means for setting a status requiring confirmation regarding the registration of a product to be purchased in response to a registration request for a product to be registered as a purchase item from a terminal operated by the customer, A release means that, when the release data obtained by reading the information held by the store clerk at the terminal and notified from the terminal is legitimate release data for release, releases the status requiring confirmation. A payment means that, in response to a payment request from the terminal, if the status does not require verification, processes a payment to allow the customer to pay for the registered product to be purchased. A trading support device equipped with the following features.

Images