Information communication terminal, information processing program, and transaction processing system

Abstract

To complete a transaction in which a commodity requiring confirmation by a store clerk is included in commodities to be purchased without using a checkout corner where the store clerk is arranged.SOLUTION: A transaction processing system of the embodiment comprises registration means, payment means, acquisition means, and control means. The registration means registers a commodity specified by an operation on a terminal as a commodity to be purchased by a customer using the terminal. The payment means performs payment processing for allowing the customer to make payment for the commodity registered by the registration means. The acquisition means acquires data specified by the operation on the terminal if the commodities to be paid in the payment processing by the payment means include commodities that require confirmation by a store clerk at the time of sale. The control means allows the payment means to start the payment processing if the data acquired by the acquisition means is predetermined release data.SELECTED DRAWING: Figure 17

Description

[Technical Field]

[0001] An embodiment of the present invention comprises: Information and communication terminal , information processing programs and transaction processing system Regarding. [Background technology]

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

[0003] However, some products may require confirmation by a store clerk due to age restrictions, etc. In conventional transaction processing systems, a cashier's counter staffed by a store clerk is also provided, and transactions involving products that require confirmation by a store clerk are handled at the cashier's counter. Given these circumstances, it has been desirable to be able to complete transactions in which the items being purchased include items that require confirmation by a store clerk without having to use a cashier's counter where a store clerk is stationed. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-144797 Summary of the Invention [Problem to be solved by the invention]

[0005] The problem to be solved by the present invention is that even when the items to be purchased include items that require confirmation by a store clerk, the transaction can be completed without using a cashier's counter where a store clerk is stationed. Information and communication terminal , information processing programs and transaction processing system The purpose is to provide [Means for solving the problem]

[0006] The information communication terminal of the embodiment includes a designation receiving means, a first display means, 、 Second display means , a transmitting means, and a third display means The instruction receiving means receives an instruction to start a checkout for the products registered by a customer for purchase. The first display means displays a first screen on the display device to prompt the customer to contact a store clerk if the purchase includes products that require confirmation by a store clerk. After the first display means displays the first screen, the second display means displays a second screen on the display device to prompt the customer to select whether to use the customer's own terminal or a cash register to pay for the products to be purchased. The transmitting means transmits request data for requesting payment in response to the second screen specifying that the operation be performed on the terminal. The third display means displays on the display device a third screen showing a transaction barcode for causing the transaction machine to obtain data regarding the content of the transaction in response to the second screen specifying that the operation be performed on the payment machine. [Brief explanation of the drawings]

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

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

[0009] FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system according to this embodiment. The transaction processing system is configured so that a plurality of store systems 100, relay servers 200, and user terminals 300 can communicate with each other via a communication network 400. FIG. 1 shows two store systems 100. These store systems 100 are installed in two different stores, Store A and Store B, which use the transaction processing system. There may be three or more stores that use the transaction processing system, with a store system 100 installed in each store. In the following, when it is necessary to distinguish between the store systems 100 installed in each store, the store system 100 installed in Store A will be referred to as store system 100A, and the store system 100 installed in Store B will be referred to as store system 100B. The business operator of store A may be the same as or different from the business operator of store B. When the transaction system is used in other stores, the business operator of those stores may be the same as or different from the business 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 a data communication relay function as a cloud service via the communication network 400, for example. The user terminal 300 is an information communication terminal that functions as a user interface for customers who use the transaction system to shop at a store. The user terminal 300 has a function for wireless communication with the store system 100 and a function for wireless communication with the communication network 400. The user terminal 300 can be a communication terminal with a data communication function, such as a smartphone or tablet terminal. The user terminal 300 may be owned by the customer or may be loaned to the customer by the store. The communication network 400 may be, for example, the Internet, a virtual private network (VPN), a local area network (LAN), a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. Typically, the communication network 400 is a combination of a mobile communication network and the Internet or a VPN.

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

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

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

[0014] The payment machine 5 calculates the price for each purchased item managed by the virtual POS server 2 and processes the payment for the item to be made by the customer. The payment methods that the payment machine 5 can use for the payment may include all or any of the well-known payment methods, such as cash payment, credit card payment, electronic money payment, points payment, and code payment (also known as mobile payment or smartphone payment). The payment machine 5 may be operated by either a store clerk or a customer. The payment machine 5 may be, for example, a self-service payment machine used in an existing semi-self-service POS system. The payment machine 5 may also have a function for processing information to register the item as a purchased item. In this case, the payment 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] The access point 6 performs communication processing to enable the user terminal 300 to access the in-store communication network 7 via wireless communication. The access point 6 may be, for example, a well-known communication device that performs wireless communication according to the IEEE802.11 standard. The access point 6 is installed within the store so that the user terminal 300 can communicate wirelessly from anywhere on the sales floor of the store. Depending on the size of the store, multiple access points 6 may be installed in one store system 100. The in-store communication network 7 may be the Internet, VPN, LAN, public communication network, mobile communication network, or the like, either alone or in appropriate combination, but typically the in-store communication network 7 is a LAN.

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

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

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

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

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

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

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

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

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

[0025] (21) A flag for identifying whether or not to delete the check digit of a UPC (universal product code), which is a type of product code. For example, if store A operates without deleting the check digit, the check-in data represented by the two-dimensional code TC1A will indicate, for example, a "1" as the flag. For example, if store B operates with the check digit deleted, the check-in data represented by the two-dimensional code TC1B will indicate, for example, a "0" as the flag. (22) The time until the camera screen automatically transitions on the user terminal 300. The check-in data represented by the two-dimensional code TC1A represents the time set in advance for store A. The check-in data represented by the two-dimensional code TC1B represents the time set in advance for store B. (23) 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 two-dimensional code TC1A represents the time set in advance for store A. The check-in data represented by the two-dimensional code TC1B represents the time set in advance for store B.

[0026] (24) The number of retries allowed when communication between the user terminal 300 and the store system 100 via the access point 6 times out. The check-in data represented by the two-dimensional code TC1A represents the number of retries set in advance for store A. The check-in data represented by the two-dimensional code TC1B represents the time period set in advance for store B. (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 two-dimensional code TC1A represents the time set in advance for store A. The check-in data represented by the two-dimensional code TC1B represents the time set in advance for store B. (26) The number of retries allowed when communication between the user terminal 300 and the store system 100 via the relay server 200 times out. The check-in data represented by the two-dimensional code TC1A represents the number of retries set in advance for store A. The check-in data represented by the two-dimensional code TC1B represents the time period set in advance for store B.

[0027] (27) Authentication data used in the authentication process to authenticate the declaration of confirmation completion for a transaction involving an item that requires confirmation by a store clerk. The check-in data represented by the two-dimensional code TC1A represents authentication data that has been preset for store A. The check-in data represented by the two-dimensional code TC1B represents authentication data that has been preset for store B. It is preferable that the authentication data be set differently for each store, but the same authentication data may 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 operates the transaction processing system normally, the check-in data represented by two-dimensional code TC1A will indicate, for example, "1." If store system 100B is set to demo mode, which operates the transaction processing system demo-mode, the check-in data represented by two-dimensional code TC1B will indicate, for example, "2." (29) Data for identifying the mode of data transfer to the payment machine 5. For example, if the store system 100A is set to a mode in which the payment machine 5 requests data transfer from the mobile controller 3, the check-in data represented by the two-dimensional code TC1A will represent the relevant data, for example, "1." Also, if the store system 100B is set to a mode in which data is transferred from the mobile controller 3 to the payment machine 5 without a request from the payment machine 5, the check-in data represented by the two-dimensional code TC1B will represent the relevant data, for example, "2."

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

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

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

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

[0032] The main memory 12 corresponds to the main storage portion of the computer. The main memory 12 includes a nonvolatile memory area and a volatile memory area. The main memory 12 stores the information processing program in the nonvolatile memory area. The main memory 12 may store data required for the processor 11 to execute information processing in either the nonvolatile or volatile memory area. The main memory 12 uses the volatile memory area as a work area where data is rewritten by the processor 11 as appropriate. The nonvolatile 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. As the auxiliary storage unit 13, a storage unit using a well-known storage device such as an EEPROM (electric erasable programmable read-only memory), an HDD (hard disc drive), or an SSD (solid state drive) can be used. The auxiliary storage unit 13 stores data used by the processor 11 when performing various processes, or data created by the processes in the processor 11. The auxiliary storage unit 13 may also store the information processing program.

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

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

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

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

[0038] In addition, the group of databases DB11 may include various databases such as those managed by a POS server in an existing POS system. Note that the types of databases that the group of databases DB11 includes, or the types of data and structures that these databases contain, may be determined for each store.

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

[0040] However, the auxiliary storage unit 23 stores a virtual POS application AP21 instead of the store management application AP11. The virtual POS application AP21 is an application program that describes the information processing required to realize the functions of the virtual POS server 2. A separate virtual POS application AP21 may be created for each store or for each business operator that operates the store, based on the store management policy. 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 required to realize the discount service, while the virtual POS application AP21 used in store system 100B will not describe the information processing required to realize the discount service.

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

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

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

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

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

[0046] Field F11 contains a terminal code for distinguishing the associated user terminal 300 from other user terminals 300. The terminal code may be, for example, a unique identification code assigned to each communication terminal used as the user terminal 300 to identify each individual communication terminal. Alternatively, the terminal code may be, for example, an identification code assigned to a smartphone POS app (described later) when the smartphone POS app is installed on the user terminal 300. Field F12 contains a membership code for distinguishing the customer using the associated user terminal 300 from other customers. Field F13 contains a transaction code for a transaction performed using the associated user terminal 300. Field F14 contains a confirmation flag for identifying whether or not the items registered as purchased using the associated user terminal 300 include items requiring confirmation. In this embodiment, a value of "1" indicates that a confirmation-required item is included. Note that data record DR1 may also contain other fields in which data other than fields F11 to F15 is set. In other words, the confirmation flag indicates whether or not confirmation by a store clerk is required.

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

[0048] Field F21 contains 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 contains registration data regarding the attempted product registration for the associated transaction. The registration data will be described later.

[0049] Data record DR2 includes fields F23 and subsequent fields when an attempt is made to register two or more purchase items for the associated transaction. Fields F23 and subsequent fields are set with the same registration data as field F12.

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

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

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

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

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

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

[0056] Now, for example, a general-purpose server device can be used as the hardware of the store server 1, the virtual POS server 2, or the mobile controller 3. The store server 1, the virtual POS server 2, or the mobile controller 3 is generally transferred in a state in which the store management application AP11, the virtual POS application AP21, or the registration support application AP31 is stored in the auxiliary storage unit 13, 23, or 33, respectively, but the database group DB11, the transaction database DB21, or the transaction management database DB31 and the registration database DB32 are not stored. However, the hardware in a state in which the store management application AP11, the virtual POS application AP21, or the registration support application AP31 is not stored in the auxiliary storage unit 13, 23, or 33, or in a state in which a different version of an application program of the same type is stored in the auxiliary storage unit 13, 23, or 33, and the store management application AP11, the virtual POS application AP21, or the registration support application AP31 may be transferred separately. The store server 1, virtual POS server 2, or mobile controller 3 may be configured by writing the store management app AP11, virtual POS app AP21, or registration support app AP31 to the auxiliary storage unit 13, 23, or 33 in response to an operator's operation. The store management app AP11, virtual POS app AP21, or registration support app AP31 may be transferred by recording it on a removable storage medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network. The transaction database DB21, or the transaction management database DB31 and registration database DB32, may be configured in the auxiliary storage unit 13, 23, or 33 by the processor 11, 21, or 31 executing information processing based on the store management app AP11, virtual POS app AP21, or registration support app AP31. At least a portion of the store management app 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 app AP21 and the transaction database DB21 may be stored in the main memory 22. At least a part of the registration assistance application AP31, the transaction management database DB31, and the registration database DB32 may be stored in the main memory 32.

[0057] Next, the operation of the transaction processing system configured as described above will be described. Note that the contents of the various processes described below are merely examples, and it is possible to change the order of some of the processes, omit some of the processes, or add other processes as appropriate. For example, in the following description, in order to clearly explain the characteristic operations of this embodiment, explanation of some of the processes will be omitted. For example, if some kind of error occurs, processing may be performed to deal with the error, but a description of some of such processing will be omitted. The service provided to customers through the operation of the transaction processing system described below is 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 the 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 simplicity of explanation, the following will describe the case where only wireless communication with the access point 6 is used. Furthermore, to perform a transaction at the payment machine 5, whether to use a mode in which the virtual POS server 2 requests data transfer from the payment machine 5 to the mobile controller 3, or a mode in which data is transferred from the mobile controller 3 to the payment machine 5 without a request from the payment machine 5, is determined by the state of a flag included in the check-in data. However, for simplicity of explanation, the following will be described assuming that the mode in which data transfer from the payment machine 5 to the mobile controller 3 is always used.

[0059] To use the smartphone POS service, a customer installs the registration support app AP31 on their own smartphone or other device, making it available as a user terminal 300. Alternatively, the customer may borrow a user terminal 300 from a store, configured with the registration support app AP31 installed on a tablet or other device. The customer then enters any store that has a store system 100, carrying the user terminal 300 with information processing based on the registration support app AP31 running.

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

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

[0062] When a customer enters a store and starts shopping, the customer performs a predetermined operation on the main menu screen to specify the start of shopping. When an operation to specify the start of shopping is detected, for example, on the touch panel 304, the processor 301 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 is a screen that prompts the customer to read the check-in two-dimensional code TC1. The processor 301, for example, activates the camera 305, and generates the scan screen by superimposing on an image obtained by the camera 305 a text message that prompts the customer to read the two-dimensional code TC1 and a line that indicates the position where the two-dimensional code TC should be held over it.

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

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

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

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

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

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

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

[0070] In the virtual POS server 2, when the start of a transaction is requested by the mobile controller 3, the processor 21 determines a transaction code according to predetermined rules and starts the registration process of the purchased product in association with the transaction code. The processor 21 also notifies the mobile controller 3 of the determined transaction code.

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

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

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

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

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

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

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

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

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

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

[0081] For example, the processor 301 activates the camera 305, and generates the registration screen SC2 by superimposing on the image obtained by the camera 305 a line indicating the range of the display area AR21, and an image showing the message ME21 and the button BU21.

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

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

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

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

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

[0087] In the virtual POS server 2, the processor 21 assumes that the barcode data included in the request data sent from the mobile controller 3 was read by a barcode scanner installed in an existing POS terminal and attempts to register the purchased item using the same process as an existing POS terminal. However, the item may display a barcode other than the one representing the product code used by the virtual POS server 2, and therefore the barcode data included in the request data may not represent the product code used by the virtual POS server 2. In such cases, the processor 21 is unable to register the purchased item and issues an error. In this way, the processor 21 registers the purchased item based on the legitimate barcode reading. Thus, by the processor 21 executing information processing based on the virtual POS application AP21, the computer with the processor 21 as its central part functions as registration means. The processor 21 also manages purchased items using a transaction database DB21.

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

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

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

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

[0092] Case 2: This is a notification of a 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, processor 31 performs the same process as in case 1 above.

[0093] Case 3: 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 set to "0." In this case, the processor 31 rewrites the value of the quantity included in the registration data that includes the notified product code and has a cancellation flag of "0" to a value that is one step larger.

[0094] Case 4: It is an error notification. In this case, processor 31 adds a new field next to the last field already present in data record DR2 associated with the transaction being processed, and adds new registration data to that field. Processor 31 includes the notified barcode data and an error flag set to "1" indicating 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] By updating the registration database DB32 by the processor 31 in this way, the registration database DB32 not only shows a list of purchased products registered in the virtual POS server 2, but also records barcode reading errors. The processor 31 may store the barcode data sent in the registration request in the main memory 32 or the auxiliary storage unit 33, and in the above-mentioned case 4, may include this stored barcode data in the registration data. In this case, the processor 21 in the virtual POS server 2 may not include the barcode data in the result data. The processor 31 may also extract a product code from the stored barcode data and perform the processes in cases 1 to 3 based on this product code. The processor 31 may also obtain the product name and price from the store server 1 or the like based on the product code.

[0096] In ACT 213, the processor 31 checks whether the current registration was performed properly. If the registration was proper, the processor 31 determines YES and proceeds to ACT 214. In ACT214, processor 31 checks whether the confirmation required flag set in field F14 of data record DR1, which is associated with the transaction to be processed in transaction management database DB31, is set to "1." If the confirmation required flag is not set to "1," processor 31 determines the answer as NO and proceeds to ACT215.

[0097] In ACT 215, the processor 31 checks whether the currently registered purchased product is a product requiring confirmation. If the product is not a product requiring confirmation, the processor 31 determines NO and proceeds to ACT 216. The processor 31 also proceeds to ACT 216 if the current registration is determined to be an error and the result is NO in ACT 213, or if the confirmation-required flag is set to "1" and the result is YES in ACT 214.

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

[0099] On the other hand, if the processor 31 determines YES in ACT 215 because the product is a product requiring confirmation, the processor 31 proceeds to ACT 217. In other words, if the officially registered product is a product requiring confirmation and the confirmation flag is "0", the processor 31 proceeds to ACT 217. In ACT217, the processor 31 rewrites the confirmation flag set in field F14 to "1" for the data record DR1 with which the transaction to be processed is associated in the transaction management database DB31.

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

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

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

[0103] FIG. 20 is a diagram showing an example of the list screen SC1 in a state where purchased products have already been registered. The list screen SC1 shown in FIG. 20 shows an example in which the following items have been registered for purchase: 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. None of these items require confirmation. On the list screen SC1 shown in FIG. 20, the display area AR12 shows the product name, price, and quantity of these registered items. The display area AR11 also shows the total number of "4" and the total amount of "1,340." The area surrounded by a dashed line to the left of the product name is an area for displaying an icon. The dashed line representing this area is not actually displayed on the list screen SC1.

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

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

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

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

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

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

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

[0111] 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 input using an input device provided on the existing POS terminal, and changes the quantity of the purchased item using the same process as the existing POS terminal. The processor 21 sends result data indicating the product code of the product whose quantity has been changed and the changed quantity to the mobile controller 3.

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

[0113] In ACT221, processor 31 updates registration database DB32 based on the result data. That is, processor 31 finds registration data containing the notified product code from data record DR2 associated with the transaction being processed. Then, processor 31 rewrites the quantity contained in the corresponding registration data with the quantity contained 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 the auxiliary storage unit 33, and upon receiving result data indicating that the update is complete, rewrite the quantity of registered data related to the product specified by the stored specific data to the stored quantity. 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] In ACT222, the processor 31 instructs the user terminal 300 to display a list screen. For example, the processor 31 transmits instruction data including identification data for identifying that the instruction is to display a list screen to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity contained in the registration data whose cancellation flag is "0" among the registration data contained in the data record DR2 updated as described above. The processor 31 then returns to the standby state of ACT205 to ACT209 in FIG. 14.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0138] Once the customer has registered all of the products they wish to purchase as purchase items, they proceed to payment. At this time, the customer specifies the start of the transaction by a predetermined operation, such as touching button BU13 on the list screen SC1. In response, the processor 301 determines YES in ACT116 in FIG. 10 and proceeds to ACT136. In ACT 136, the processor 301 requests accounting from the mobile controller 3.

[0139] If a payment request is received from the user terminal 300 as described above, the processor 31 in the mobile controller 3 determines YES in ACT 209 in FIG. 14 and proceeds to ACT 235 in FIG. In ACT235, processor 31 checks whether the confirmation required flag set in field F14 of data record DR1 associated with the transaction being processed in transaction management database DB31 is "1." That is, processor 31 checks whether the purchased items include a confirmation required item. If the confirmation required flag is "1," that is, if the purchased items include a confirmation required item, the result is YES, and the process proceeds to ACT236. Note that hereinafter, a state in which the purchased items include a confirmation required item and the store clerk has not yet confirmed that the sale of the confirmation required item is permitted will be referred to as a confirmation required state. In ACT 236, the processor 31 instructs the user terminal 300 to display a confirmation screen.

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

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

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

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

[0144] As ACT142, the processor 301 displays a release screen on the touch panel 304. The release screen is a screen that allows the store clerk, who has confirmed that the sale of the confirmation-required product is permitted, to read a barcode with the user terminal 300 to release the confirmation-waiting state.

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

[0146] The customer asks a store clerk for confirmation. The clerk confirms whether the sale of the verification-required product is permitted, and if permitted, holds the release barcode over camera 305 so that it appears in display area AR51. For this procedure, the clerk carries a card or the like with the release barcode printed on it. Alternatively, the clerk displays the release barcode on the screen of an information terminal he or she carries. Preferably, a different release barcode is used for each store or business. However, it is permissible for the same release barcode to be used at different stores or different businesses. Furthermore, by changing the official release barcode, for example, every day, it is possible to prevent fraud in the event that a customer obtains the release barcode for some reason.

[0147] If the store clerk confirms that the sale of the confirmation-required product is not permitted, the store clerk designates a return to product registration by a predetermined operation such as touching button BU51. Alternatively, if the customer decides to return to product registration without asking the store clerk for confirmation, the customer designates a return to product registration by a predetermined operation such as touching button BU51.

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

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

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

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

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

[0153] When the user terminal 300 requests the mobile controller 3 to release the connection in this manner, the processor 31 in the mobile controller 3 determines YES in ACT237 in FIG. 17 and proceeds to ACT239. As ACT239, the processor 31 performs authentication processing. For example, the processor 31 extracts barcode data and authentication data from the request data and stores them in the main memory 32 or the auxiliary storage unit 33. By the processor 31 executing information processing based on the registration assistance application AP31 in this way, the computer with the processor 31 as its central part functions as an acquisition means. Then, the processor 31 performs processing to confirm whether the read barcode is a legitimate barcode for unlocking based on the barcode data and authentication data acquired in this way. This authentication processing can be performed, for example, by any of the following methods.

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

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

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

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

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

[0159] 17, if the authentication is successful, the processor 31 in the mobile controller 3 determines YES in ACT 240 and proceeds to ACT 242. If the confirmation required flag is "0", the processor 31 determines NO in ACT 235 and proceeds to ACT 242. In ACT242, the processor 31 instructs the user terminal 300 to display an accounting screen. After this, the processor 31 starts the process described below to settle the price of the product registered as a purchased product by the virtual POS server 2 or the accounting machine 5. That is, the processor 31 allows the start of the settlement process if the acquired barcode data is release data, which is data that has a predetermined relationship with the authentication data. In this way, the processor 31 executes information processing based on the registration assistance application AP31, and the computer with the processor 31 as its central part functions as control means.

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

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

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

[0163] If the customer wishes to perform the operation for settling the price at user terminal 300, the customer specifies user terminal 300 by performing a predetermined operation such as touching button BU71. If the customer wishes to perform the operation for settling the price at payment machine 5, the customer specifies payment machine 5 by performing a predetermined operation such as touching button BU72.

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

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

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

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

[0168] After the processor 31 in the mobile controller 3 issues an instruction to display the checkout screen in ACT242 in FIG. 17, the processor 31 proceeds to ACT243. In ACT243, the processor 31 checks whether or not a payment request has been made. If the processor 31 cannot confirm the request, it determines "NO" and proceeds to ACT244. In ACT244, the processor 31 checks whether or not the completion of the settlement has been notified. If the request cannot be confirmed, the processor 31 determines NO and returns to ACT243. Thus, the processor 31 waits for a payment request or a payment completion notification in ACT 243 and ACT 244. Then, if a payment request is received from the user terminal 300 as described above, the processor 31 determines YES in ACT 243 and proceeds to ACT 245.

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

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

[0171] After the processor 31 in the mobile controller 3 transfers the payment request in ACT245, the processor 31 proceeds to ACT246. In ACT246, the processor 31 waits for notification of payment completion from the mobile controller 3. Then, if the result data indicating that payment has been completed and sent by the mobile controller 3 as described above is received by the communication interface 34, the processor 31 determines the answer as YES and proceeds to ACT247. Furthermore, if the processor 31 is notified of payment completion at the payment device 5 as described above, the processor 31 determines the answer as YES in ACT244 and proceeds to ACT247. In ACT247, the processor 31 notifies the user terminal 300 that the payment has been completed.

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

[0173] 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 to this, the processor 301 proceeds to ACT 158. The processor 301 may also proceed to ACT 158 if the elapsed time while the completion screen is displayed reaches a predetermined time.

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

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

[0176] In ACT159, the processor 301 waits for the two-dimensional code to be read. At this time, the processor 301 repeatedly analyzes the image obtained by the camera 305 and attempts to read the two-dimensional code. This reading of the two-dimensional code may be performed as a process based on the smartphone POS app AP301, or may be performed as a process based on a separate application program for reading two-dimensional codes. If the two-dimensional code has been read, the processor 301 determines YES and proceeds to ACT160.

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

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

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

[0180] In ACT 249, the processor 31 executes checkout processing. The checkout processing includes clearing data stored in the main memory 32 and the auxiliary storage unit 33 for managing the transaction that was being processed. The virtual POS server 2 may terminate processing related to the transaction in response to the completion of the payment, or may terminate processing related to the transaction in response to an instruction from the mobile controller 3. In the latter case, the processor 31 issues the above instruction to the virtual POS server 2 during checkout processing. Also, a history database showing the history of user operations, including erroneous barcode scanning, may be managed by the store server 1, the virtual POS server 2, the mobile controller 3, or another server (not shown). In this case, the processor 31 performs processing during checkout processing to update the history database to reflect the operation history related to the current transaction. In ACT250, the processor 31 notifies the user terminal 300 of the completion of check-out. Then, the processor 31 ends the information processing shown in FIGS.

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

[0182] As described above, according to the transaction processing system of this embodiment, the user terminal 300 does not proceed to the transaction processing if the user terminal 300 is in a confirmation-required state. Then, if the user terminal 300 reads a legitimate barcode for release, it proceeds to the transaction processing after authentication by the mobile controller 3. In this way, the confirmation by the store clerk can be completed at the user terminal 300, and the transaction can be completed without using a checkout counter staffed by a store clerk.

[0183] Furthermore, according to the transaction processing system of this embodiment, to cancel the confirmation-required state, the store clerk only needs to have the user terminal 300 read the cancellation barcode, so the work involved does not impose a heavy burden on the store clerk.

[0184] Furthermore, according to the transaction processing system of this embodiment, a store clerk can cancel the confirmation-required state simply by operating the user terminal 300. Therefore, a customer can stop a store clerk patrolling the store and request cancellation of the confirmation-required state, or can go to a service counter or other location and request cancellation of the confirmation-required state from a store clerk stationed there. In other words, by providing cancellation barcodes to multiple store clerks in different locations, flexibility in canceling the confirmation-required state can be increased. However, the type of store clerk to whom the cancellation barcode is provided depends on the circumstances of each store or business. In other words, depending on which store clerk is provided with the cancellation barcode, the type of cancellation allowed can be changed depending on the circumstances of the store or business.

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

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

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

[0188] A store clerk may check the transaction when the transaction is made using the cash register, and the transaction may proceed to the cash register without the store clerk checking the transaction at the user terminal.

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

[0190] The functions of the virtual POS server 2 and the mobile controller 3 may be realized by a single server.

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

[0192] Some or all of the functions realized by the processors 11, 21, 31, 41, and 301 through information processing can also be realized by hardware that executes information processing not based on a program, such as a logic circuit. Each of the above functions can also be realized by combining the above hardware, such as the logic circuit, with software control.

[0193] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. The inventions described in the original claims of this application are set forth below. [Appendix 1] A registration means for registering a product designated by an operation on the terminal as a product to be purchased by a customer using the terminal; a payment means for performing a payment process to allow the customer to pay for the product registered by the registration means; an acquisition means for acquiring data designated by an operation on the terminal when the products to be paid for in the payment process by the payment means include products that require confirmation by a store clerk before being sold; a control means for allowing the settlement means to start the settlement process when the data acquired by the acquisition means is predetermined cancellation data; A transaction processing system comprising: [Supplementary Note 2] 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 authentication data have a predetermined relationship. 10. A transaction processing system as described in Appendix 1. [Supplementary Note 3] The control means uses authentication data acquired via the terminal when the customer enters the store. 2. A transaction processing system as described in Appendix 2. [Supplementary Note 4] The acquiring means acquires barcode data represented by a barcode read by the terminal as the data. A transaction processing system according to any one of Supplementary Notes 1 to 3. [Appendix 5] A transaction processing system including: a registration means for registering a product designated by an operation on a terminal as a product to be purchased by a customer using the terminal; and a payment means for performing a payment process to have the customer pay for the product registered by the registration means, an acquisition means for acquiring data designated by an operation on the terminal when the products to be paid for in the payment process by the payment means include products that require confirmation by a store clerk before being sold; a control means for allowing the settlement means to start the settlement process when the data acquired by the acquisition means is predetermined cancellation data; A transaction support device equipped with the above. [Appendix 6] A computer provided in a transaction support device used in a transaction processing system including: a registration means for registering a product designated by an operation on a terminal as a product to be purchased by a customer using the terminal; and a payment means for performing a payment process to have the customer pay for the product registered by the registration means, an acquisition means for acquiring data designated by an operation on the terminal when the products to be paid for in the payment process by the payment means include products that require confirmation by a store clerk before being sold; a control means for allowing the settlement means to start the settlement process when the data acquired by the acquisition means is predetermined cancellation data; An information processing program that makes it function as such. [Appendix 7] A product designated by an operation on the terminal is registered as a product to be purchased by the customer using the terminal, When the registered products to be settled in a settlement process for allowing the customer to settle the price of the products includes a product that requires confirmation by a store clerk at the time of sale, data designated by an operation on the terminal is acquired; If the acquired data is predetermined release data, the start of the settlement process is permitted; Executing the payment process if the payment process is permitted. Transaction processing method. [Explanation of symbols]

[0194] 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 designation receiving means for receiving a designation for the start of accounting for the product registered as a purchase target by the customer; a first display means for displaying a first screen on a display device to prompt the customer to contact a store clerk when the designation is received by the designation receiving means and the products to be purchased include products that require confirmation by a store clerk before being sold; a second display means for displaying a second screen on the display device after the first display means has displayed the first screen, the second screen allowing the customer to select whether to use the customer's own terminal or an accounting machine to perform an operation for settling the price of the product to be purchased; a transmitting means for transmitting request data for requesting a settlement in response to a specification on the second screen that the operation is to be performed on the terminal; a third display means for displaying on the display device a third screen showing a transaction barcode for allowing the transaction machine to acquire data relating to the content of the transaction in response to a designation on the second screen that the operation is to be performed on the transaction machine; and An information and communication terminal equipped with the above.

2. The third display means acquires an accounting barcode from the server device to cause the accounting machine to acquire the data regarding the contents of the transaction from the server device and displays it on the third screen.

2. The information communication terminal according to claim 1.

3. the second display means displays at least one of the total number and the total price of the products to be purchased on the second screen; 3. The information communication terminal according to claim 1 or 2.

4. A computer provided in an information communication terminal equipped with a display device, A designation receiving means for receiving a designation for the start of accounting for the product registered as a purchase target by the customer; a first display means for displaying on the display device a first screen for urging the customer to contact a store clerk when the designation is received by the designation receiving means and the products to be purchased include products that require confirmation by a store clerk before being sold; a second display means for displaying a second screen on the display device after the first display means has displayed the first screen, the second screen allowing the customer to select whether to use the customer's own terminal or an accounting machine to perform an operation for settling the price of the product to be purchased; a transmitting means for transmitting request data for requesting a settlement in response to a specification on the second screen that the operation is to be performed on the terminal; a third display means for displaying on the display device a third screen showing a transaction barcode for allowing the transaction machine to acquire data relating to the content of the transaction in response to a designation on the second screen that the operation is to be performed on the transaction machine; and An information processing program that makes it function as such.

5. Equipped with an information communication terminal and a transaction support device, a designation receiving means provided in the information communication terminal for receiving a designation for starting a transaction for the product registered as a purchase target by the customer; a first display means provided in the information communication terminal, for displaying a first screen on a display device to prompt the customer to contact a store clerk when the designation is received by the designation receiving means and the products to be purchased include products that require confirmation by a store clerk before being sold; an input means provided in the information communication terminal for inputting data designated by an operation on the information communication terminal after the first screen is displayed by the first display means; an acquisition means provided in the transaction support device for acquiring data input by the input means from the information communication terminal; an instruction means provided in the transaction support device for instructing the information communication terminal to display a second screen when the data acquired by the acquisition means is predetermined release data; a second display means provided in the information communication terminal, for displaying the second screen on the display device after the first screen is displayed by the first display means, to allow the customer to select whether to use the terminal or a cash register to make a payment for the product to be purchased; a transmitting means provided in the information communication terminal for transmitting request data for requesting payment in response to a specification on the second screen that an operation is to be performed on the terminal itself; a third display means provided in the information communication terminal for displaying on the display device a third screen showing a transaction barcode for allowing the transaction machine to acquire data relating to the content of the transaction in response to a designation on the second screen that the operation should be performed on the transaction machine; and A transaction processing system comprising:

Images