JP6952144B2 - Transaction processing system, transaction support device, information processing program and transaction processing method - Google Patents

Description

An embodiment of the present invention relates to a transaction processing system, a transaction support device, an information processing program, and a transaction processing method.

A transaction processing system that registers the contents of a transaction in response to an operation of a terminal device by a customer is considered as, for example, a cart POS system or a smartphone POS system.
In such a system, if a payment method such as credit card payment or bar code payment is used, the payment process can be completed according to the operation of the customer on the terminal device. Further, if a self-type accounting machine that performs payment processing according to the operation of the customer is used, the payment processing can be completed according to the operation of the customer in the accounting machine. If the settlement can be completed in this way, the transaction can be completed without the involvement of the clerk.

By the way, for products that are newly sold or products that are sold for a limited time, products that are not registered in the product database may be displayed in the store due to delays in registration in the product database. obtain. In addition, a bar code different from the bar code representing the product code may be displayed on the product, and it is conceivable that the customer may have the terminal device read the bar code that does not represent the product code. In these cases, the product cannot be registered as a purchased product, but the customer may think that the product has been registered.
In such a situation, if the payment can be made without the involvement of the clerk, the unsettled product will be taken out by the customer.
Under these circumstances, it has been desired to prevent a product that the customer tried to register as a purchased product but could not be registered correctly from being taken out without being settled.

Japanese Unexamined Patent Publication No. 2019-144797

The problem to be solved by the present invention is a transaction processing system, a transaction support device, an information processing program, and a transaction processing system, a transaction support device, an information processing program, which can prevent a product that a customer tries to register as a purchased product but cannot be registered correctly is taken out without being settled. To provide a transaction processing method.

The transaction processing system of the embodiment includes registration means, payment means, acquisition means, and control means. The registration means registers the product specified by the operation on the terminal as a product to be purchased by the customer using the terminal. The payment means performs a payment process for causing the customer to settle the price of the product registered as the purchase target by the registration means. Acquisition means, when the product could not be registered as by Ri購input object to the registration means it is, obtains the data specified by the operation at the terminal. In the control means, when the data acquired by the acquisition means and the authentication data acquired via the terminal when the customer enters the store have a predetermined relationship, the data acquired by the acquisition means is the release data. Is determined, and the start of payment processing by the payment means is permitted.

A block diagram showing a schematic configuration of a transaction processing system according to an embodiment. The block diagram which shows the main part circuit configuration of the store server in FIG. The block diagram which shows the main part circuit configuration of the virtual POS server in FIG. The block diagram which shows the main part circuit composition of the mobile controller in FIG. The schematic diagram which shows the main data structure of the data record included in the transaction management database shown in FIG. The schematic diagram which shows the main data structure of the data record included in the registration database shown in FIG. The block diagram which shows the main circuit structure of the communication server in FIG. The block diagram which shows the main part circuit composition of the user terminal in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The flowchart of information processing by the processor shown in FIG. The figure which shows an example of a list screen. The figure which shows an example of the registration screen. The figure which shows an example of a list screen. The figure which shows an example of a list screen. The figure which shows an example of a guidance screen. The figure which shows an example of the confirmation screen. The figure which shows an example of the release screen. The figure which shows an example of a warning screen. The figure which shows an example of the accounting screen.

Hereinafter, an embodiment of the transaction processing system will be described with reference to the drawings.
The transaction processing system in this embodiment visits a plurality of products including products that require confirmation by a clerk at the time of sale (hereinafter referred to as confirmation-required products) due to circumstances such as age restrictions being set for the purchaser. Process the transaction of goods in the store to sell to the customer.

FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system according to the present embodiment.
The transaction processing system is configured so that a plurality of store systems 100, a relay server 200, and a user terminal 300 can communicate with each other via a communication network 400.
FIG. 1 shows two store systems 100. These store systems 100 are provided in different stores A and B that use the transaction processing system, respectively. There may be three or more stores that use the transaction processing system, and a store system 100 is provided for each store. In the following, when it is necessary to distinguish the store system 100 provided in each store, the store system 100 provided in the store A is referred to as the store system 100A, and the store system 100 provided in the store B is referred to as the store. Represented as system 100B.
The business operator that operates the store A may be the same as or different from the business operator that operates the store B. When the transaction system is used in other stores, the business operator that operates the store may be the same as or different from the business operator that operates the store A or the store B.

The relay server 200 relays data communication between the user terminal 300 and the store system 100. The relay server 200 provides, for example, a data communication relay function as a cloud service via the communication network 400.
The user terminal 300 is an information communication terminal that functions as a user interface for customers who perform shopping using a transaction system at a store. The user terminal 300 has a function of wirelessly communicating with the store system 100 and a function of wirelessly communicating with the communication network 400. As the user terminal 300, a communication terminal having a data communication function such as a smartphone or a tablet terminal can be used. The user terminal 300 may be owned by the customer or lent to the customer at the store.
As the communication network 400, for example, the Internet, VPN (virtual private network), LAN (local area network), public communication network, mobile communication network and the like can be used alone or in combination as appropriate. As the communication network 400, a mobile communication network and the Internet or VPN are typically used.

The general configuration of each store system 100 is common. That is, the store system 100 is configured so that the store server 1, the virtual POS server 2, the mobile controller 3, the communication server 4, the accounting machine 5, and the access point 6 can communicate with each other via the in-store communication network 7. However, the store server 1, the virtual POS server 2, the mobile controller 3, the communication server 4, the accounting machine 5, the access point 6, and the in-store communication network 7 need only have the same functions for realizing the operations described later, and are complete. Does not have to be the same. In addition, some store systems 100 may include devices not shown in FIG.

The store server 1 comprehensively manages a plurality of transactions subject to transaction processing realized by the store system 100 as described later. The store server 1 has, for example, a function similar to that of an existing POS server.
The virtual POS server 2 performs information processing for registering purchased products for each transaction and settling the price of the purchased products in response to an external request. That is, the virtual POS server 2 virtually realizes the functions provided by the existing POS terminal. The information processing performed by the virtual POS server 2 is customized so as to adapt to the difference in the operation policy of each store. That is, for example, the information processing performed by the store server 1 provided in the store system 100A and the information processing performed by the store server 1 provided in the store system 100B may be partially different.

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

The accounting machine 5 requests the price for the purchased product for each transaction managed by the virtual POS server 2, and performs a process for causing the customer to settle the price. The payment methods that the accounting machine 5 can use for the above payments are well-known such as cash payment, credit card payment, electronic money payment, point payment, code payment (also referred to as mobile payment or smartphone payment, etc.). It may be all or any part of the payment method. The accounting machine 5 may be operated by either a clerk or a customer. As the accounting machine 5, for example, a self-type accounting machine used in an existing semi-self-type POS system can be used. The accounting machine 5 may have a function of performing information processing for registering a product as a purchased product. In this case, as the accounting machine 5, for example, a face-to-face POS terminal used in an existing POS system or a self-type POS terminal used in an existing self-type POS system can be used.

The access point 6 performs communication processing for enabling the user terminal 300 to access the in-store communication network 7 by wireless communication. As the access point 6, for example, a well-known communication device that performs wireless communication according to the IEEE802.11 standard can be used. The access point 6 is installed in the store so that the user terminal 300 can wirelessly communicate with the user terminal 300 from anywhere in the store's sales floor. Depending on the store scale, a plurality of access points 6 may be arranged in one store system 100.
As the in-store communication network 7, the Internet, VPN, LAN, public communication network, mobile communication network, and the like can be used alone or in combination as appropriate. However, typically, the in-store communication network 7 is a LAN.

In the store where the store system 100 is provided, the two-dimensional code TC1 for check-in is posted near the entrance, and the 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 checkout data for checkout. Check-in data and check-out data differ from store to 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 two-dimensional codes TC1A and TC2A for store A are represented as the two-dimensional codes TC1A and TC2A for store B. The two-dimensional codes TC1B and TC2B are used.

Check-in data represents, for example, the following information.
(1) Operation version of store system 100. For example, the check-in data represented by the two-dimensional code TC1A represents an operating version of the store system 100A. The check-in data represented by the two-dimensional code TC1B represents an operating version of the store system 100B.
(2) A business operator code for identifying a business operator that operates a store in which the store system 100 is provided. For example, the check-in data represented by the two-dimensional code TC1A represents the business operator code assigned to the business operator that operates the store A. The check-in data represented by the two-dimensional code TC1B represents the business operator code assigned to the business operator that operates the store B.
(3) A store code for identifying a store in which the store system 100 is provided. For example, the check-in data represented by the two-dimensional code TC1A represents the store code assigned to the store A. The check-in data represented by the two-dimensional code TC1B represents the store code assigned to the store B. The store code may be one that can identify each of all the stores that use the transaction processing system, or may be one that can identify each of a plurality of stores operated by the same business operator. ..

(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 the store A. The check-in data represented by the two-dimensional code TC1B represents the name of the business operator that operates the 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 the store A. The check-in data represented by the two-dimensional code TC1B represents the name of the store B.
(6) A flag for distinguishing the two-dimensional code TC1 and the two-dimensional code TC2. The flag in the check-in data is in a state indicating that it is check-in data. The state is, for example, "1". The flag is common to all two-dimensional codes TC1.

(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) The domain name of the relay server 200. The domain name is common to all two-dimensional codes TC1. However, a plurality of relay servers 200 having different domain names may be used properly 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) Electronic receipt server address. 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 the electronic receipt server that provides the electronic receipt service used by the business operator that operates the store A via the communication network 400. The check-in data represented by the two-dimensional code TC1B represents an address for accessing the electronic receipt server that provides the electronic receipt service used by the business operator that operates the store B via the communication network 400. The address may be common to all the two-dimensional code TC1, or any one of the plurality of addresses may be represented for each two-dimensional code TC1.

(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 for exchanging data with the store system 100. For example, in the store A, if the wireless communication between the access point 6 is used for exchanging data between the store system 100A and the user terminal 300, the flag is set to, for example, "1". For example, in the store B, if wireless communication with the communication network 400 is used for data exchange between the store system 100B and the user terminal 300, the flag is set to, for example, "0".
(11) An SSID (service set identifier) for identifying the access point 6. For example, the check-in data represented by the two-dimensional code TC1A represents an 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 access point 6. For example, the check-in data represented by the two-dimensional code TC1A represents a password set in the access point 6 included in the store system 100A. The check-in data represented by the two-dimensional code TC1B represents a password set in the access point 6 included in the store system 100B.

(13) Identification number of the security method used by the access point 6. For example, the identification number is assigned "1" to the WPA2-PSK method, "2" to the WPA-PSK method, and "3" to the WEP method. For example, if the access point 6 included in the store system 100A uses the WPA2-PSK method as the security method, the check-in data represented by the two-dimensional code TC1A represents "1" as the identification number. Further, for example, if the access point 6 included in the store system 100B uses the WPA-PSK method as the security method, the check-in data represented by the two-dimensional code TC1B represents "2" as the identification number.
(14) A flag for identifying whether an error occurs when the user terminal 300 fails to connect to the relay server 200, or whether the operation is continued without making an error. For example, in the store A, if the setting is such that an error occurs when the user terminal 300 fails to connect to the relay server 200, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the flag. .. Further, for example, in the store B, if the user terminal 300 is set to continue operation even if the connection with the relay server 200 fails, the check-in data represented by the two-dimensional code TC1B is set to, for example, "0" as the flag. show.

(15) Transmission mode identification number regarding the status of the user terminal 300. The transmission mode includes, for example, a first mode, a second mode, and a third mode. For example, the identification number of the transmission mode is assigned "1" to the first mode, "2" to the second mode, and "3" to 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 the store A, if the first mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1A represents "1" as the identification number. Further, for example, in the store B, if the second mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1B represents "2" as the identification number.

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

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

(21) A flag for identifying whether to delete the check digit of the UPC (universal product cord), which is a type of product code. For example, in the store A, if the operation does not delete the check digit, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the flag. Further, for example, in the store B, if the operation is to delete the check digit, the check-in data represented by the two-dimensional code TC1B represents, for example, "0" as the flag.
(22) Time until the camera screen is automatically changed on the user terminal 300. The check-in data represented by the two-dimensional code TC1A represents a preset time for the store A as the time. The check-in data represented by the two-dimensional code TC1B represents a preset time for the store B as the time.
(23) Time-out time when the user terminal 300 communicates with the store system 100 via the access point 6. The check-in data represented by the two-dimensional code TC1A represents a preset time for the store A as the time. The check-in data represented by the two-dimensional code TC1B represents a preset time for the store B as the time.

(24) The number of times that a retry is allowed when the 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 a preset number of times for the store A as the number of times. The check-in data represented by the two-dimensional code TC1B represents a preset number of times for the store B as the time.
(25) Time-out time when the user terminal 300 communicates with the store system 100 via the relay server 200. The check-in data represented by the two-dimensional code TC1A represents a preset time for the store A as the time. The check-in data represented by the two-dimensional code TC1B represents a preset time for the store B as the time.
(26) The number of times that a retry is allowed when the 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 a preset number of times for the store A as the number of times. The check-in data represented by the two-dimensional code TC1B represents a preset number of times for the store B as the time.

(27) Authentication data used in the authentication process to authenticate the declaration of the end of confirmation regarding transactions for products that require confirmation by the clerk. The check-in data represented by the two-dimensional code TC1A represents authentication data preset for the store A. The check-in data represented by the two-dimensional code TC1B represents authentication data preset for the store B. It is preferable that the authentication data is set differently for each store, but the same authentication data may be set in different stores.
(28) Data for identifying the operation mode of the store system 100. For example, if the store system 100A is set to the normal mode in which the transaction processing system is normally operated, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the data. Further, for example, if the store system 100B is set to the demo mode in which the transaction processing system is demo-operated, the check-in data represented by the two-dimensional code TC1B represents, for example, "2" as the data.
(29) Data for identifying the mode of data transfer to the accounting machine 5. For example, if the store system 100A is set to a mode in which data transfer is requested from the accounting machine 5 to the mobile controller 3, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the data. Further, for example, if the store system 100B is set to a mode for transferring data from the mobile controller 3 to the accounting machine 5 without a request from the accounting machine 5, the check-in data represented by the two-dimensional code TC1B is used as the data. For example, it represents "2".

(30) A flag indicating whether or not payment by the code payment method by the operation on the user terminal 300 is permitted. For example, if the store A allows the code payment, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the flag. Further, for example, if the code payment is not allowed in the store B, the check-in data represented by the two-dimensional code TC1B represents, for example, "0" as the flag.
(31) A flag for identifying whether or not to allow registration of a product for which a purchaser's age limit is set (hereinafter referred to as an age-restricted product) on the user terminal 300. For example, if the store A allows the registration of the age-restricted product on the user terminal 300, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the flag. Further, for example, if the code payment is not allowed in the store B, the check-in data represented by the two-dimensional code TC1B represents, for example, "0" as the flag.
(32) Data for identifying the input mode of the membership code of the point member. For example, if the store system 100A is set to the mode in which the member code is manually input, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the data. Further, for example, if the store system 100B is set to a mode in which a member code is input by reading a barcode, the check-in data represented by the two-dimensional code TC1B represents, for example, "2" as the data.

(33) A flag for identifying whether or not the clerk's confirmation is required when entering the membership code when the mode for manually entering the membership code of the point member is set. For example, if the confirmation is required at the store A, the check-in data represented by the two-dimensional code TC1A represents, for example, "1" as the flag. Further, for example, if the confirmation is not required at the store B, the check-in data represented by the two-dimensional code TC1B represents, for example, "0" as the flag.
(34) A threshold value for checking the remaining battery level of the user terminal 300 at check-in. The threshold value is set for each store or each business operator. For example, when the business operator operating the store A defines the threshold value as "20%", the check-in data represented by the two-dimensional code TC1A represents, for example, "20" as the threshold value. Further, for example, when the store B defines the threshold value as "25%", the check-in data represented by the two-dimensional code TC1B represents, for example, "25" as the threshold value.
The above is an example of the information represented by the check-in data. However, the check-in data does not have to include a part of the various information shown above. Further, the check-in data may represent information different from the various information shown above.

FIG. 2 is a block diagram showing a 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 line 15. The processor 11, the main memory 12, the auxiliary storage unit 13, and the communication interface 14 can communicate with each other via the transmission line 15. Then, the processor 11, the main memory 12, and the auxiliary storage unit 13 are connected by the transmission line 15, so that a computer for controlling the store server 1 is configured.

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

The main memory 12 corresponds to the main memory portion of the computer. The main memory 12 includes a non-volatile memory area and a volatile memory area. The main memory 12 stores the above information processing program in the non-volatile memory area. The main memory 12 may store data necessary for the processor 11 to execute information processing in a non-volatile or volatile memory area. The main memory 12 uses a volatile memory area as a work area in which data is appropriately rewritten by the processor 11. The non-volatile memory area is, for example, a ROM (read only memory). The volatile memory area is, for example, RAM (random access memory).

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

The communication interface 14 performs data communication with each unit connected to the in-store communication network 7 according to a predetermined communication protocol. As the communication interface 14, for example, a well-known communication device for LAN can be applied.
The transmission line 15 includes an address bus, a data bus, a control signal line, and the like, and transmits data and control signals transmitted and received between each connected unit.

The auxiliary storage unit 13 stores the store management application AP11, which is one of the information processing programs. The store management application AP11 is an application program, and describes information processing for realizing the function as the store server 1. The store management application AP11 may be a separate one created in accordance with the store management policy for each store or for each business operator that operates the store. For example, if the sales data management method is different between the store A and the store B, the store management application AP11 used in the store system 100A is for managing the sales data adapted to the sales data management method in the store A. The information processing is described, and the store management application AP11 used in the store system 100B describes information processing for managing sales data adapted to the sales data management method in the store B.

A part of the storage area of the auxiliary storage unit 13 is used as the database group DB 11. The database group DB 11 includes a plurality of databases for managing various types of information. One of the databases included in the database group DB 11 is a product database for managing products sold in stores. A product database is a collection of data records associated with a product to be managed. The data record of the product database contains data about the associated product, such as product code, price and product name. The product code is an identification code defined for identifying a product for each SKU (stock keeping unit), and for example, a JAN (Japanese article number) code is used. The product name is a name defined so that humans can easily distinguish the product. The price is the amount of money for the sale of the product.

One of the databases included in the database group DB 11 is a user database for managing store users. A user database is a collection of data records associated with a customer registered as a user. The data record of the user database contains data about the associated customer, such as a user code and attribute information for identifying the user. The user code is a unique identification code defined for each customer in order to individually identify the user. Attribute information may include name, gender, age, address, telephone number, and the like. In addition, the data record of the user database may include payment information declared by the user. The payment information is a credit number, a code payment ID (identifier), or the like. Further, when a plurality of payment methods can be selected, the payment information may include a payment method code for identifying the payment method. Further, in the case of a store that provides a point service, the ID of the point service, the number of points held, and the like may be included in the payment information.

In addition, the database group DB 11 may include various databases managed by the POS server in the existing POS system. It should be noted that what kind of database the database group DB 11 includes, or what kind of data the database group includes and what kind of structure may be determined for each store.

FIG. 3 is a block diagram showing a main circuit configuration of the virtual POS server 2.
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 line 25. The processor 21, the main memory 22, the auxiliary storage unit 23, and the communication interface 24 can communicate with each other via the transmission line 25. Then, the processor 21, the main memory 22, and the auxiliary storage unit 23 are connected by the transmission line 25 to form a computer for controlling the virtual POS server 2. The outline of the functions of the processor 21, the main memory 22, the auxiliary storage unit 23, the communication interface 24, and the transmission line 25 is the same as that of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 14, and the transmission line 15. Therefore, the description thereof will be omitted.

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

A part of the storage area of the auxiliary storage unit 23 is used as the transaction database DB 21 instead of the database group DB 11. The transaction database DB 21 is a set of data records associated with transactions with customers who are buying around in the store. The data record of the transaction database DB 21 includes a transaction code and product data related to a product registered as a purchased product. The transaction code is a unique identification code set for each transaction in order to identify each transaction. The product data represents a product code, a product name, a price, a quantity, and the like. The structure of the transaction database DB 21 may be individually determined according to the store management policy for each store or each business operator that operates the store.

FIG. 4 is a block diagram showing a 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 line 35. The processor 31, the main memory 32, the auxiliary storage unit 33, and the communication interface 34 can communicate with each other via the transmission line 35. Then, the processor 31, the main memory 32, and the auxiliary storage unit 33 are connected by the transmission line 35 to form a computer for controlling the mobile controller 3. The outline of the functions of the processor 31, the main memory 32, the auxiliary storage unit 33, the communication interface 34, and the transmission line 35 is the same as that of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 14, and the transmission line 15. Therefore, the description thereof will be omitted.

However, the auxiliary storage unit 33 stores the registration support application AP31 instead of the store management application AP11. The registration support application AP31 is an application program and describes information processing described later for supporting registration of purchased products. 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.

A part of the storage area of the auxiliary storage unit 23 is used as the transaction management database DB 31 and the registration database DB 32 instead of the database group DB 11. The structures of the transaction management database DB 31 and the registration database DB 32 are common to each store system 100.

FIG. 5 is a schematic diagram showing a main data structure of the data record DR1 included in the transaction management database DB31.
The transaction management database DB 31 is a set of data records DR1 associated with the user terminal 300 used by the customer in the store. Therefore, when there is only one customer in the store, the transaction management database DB 31 includes one data record DR1. Further, when there is no customer existing in the store, the transaction management database DB 31 does not include the data record DR1. The data record DR1 includes the fields F11, F12, F13, and F14.

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

FIG. 6 is a schematic diagram showing a main data structure of the data record DR2 included in the registration database DB 32.
The registration database DB 32 is a set of data records DR2 associated with transactions with customers who are buying around in the store. The data record DR2 includes the fields F21 and F22. The data record DR1 may also include fields F23, F24, ....

The transaction code of the associated transaction is set in the field F21. This transaction code is the same as the transaction code set in the field F12 of the data record DR1 associated with the user terminal 300 used in the associated transaction. The field F22 is set with registration data relating to the attempted merchandise registration for the associated transaction. The registration data will be described later.

The data record DR2 includes fields F23 and subsequent fields when two or more purchased goods are attempted to be registered for the associated transaction. Then, the same registration data as in the field F12 is set in the fields after the field F23.

FIG. 7 is a block diagram showing a 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 line 46. The processor 41, the main memory 42, the auxiliary storage unit 43, the communication interface 44, and the communication unit 45 can communicate with each other via the transmission line 46. Then, the processor 41, the main memory 42, and the auxiliary storage unit 43 are connected by the transmission line 46 to form a computer for controlling the communication server 4. The outline of the functions of the processor 41, the main memory 42, the auxiliary storage unit 43, the communication interface 44, and the transmission line 46 is the same as that of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 14, and the transmission line 15. Therefore, the description thereof will be omitted.
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.

The auxiliary storage unit 43 stores the communication processing application AP41 in place of the store management application AP11. The communication processing application AP41 is an application program, and describes information processing for communicating with the relay server 200 via the communication network 400 so that data can be exchanged between the mobile controller 3 and the user terminal 300. ing. 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.

FIG. 8 is a block diagram showing a 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, a transmission line 308, and the like. The processor 301, the main memory 302, the auxiliary storage unit 303, the touch panel 304, the camera 305, and the mobile communication unit 307 can communicate with each other via the transmission line 308. Then, the processor 301, the main memory 302, and the auxiliary storage unit 303 are connected by the transmission line 308 to form a computer for controlling the user terminal 300. Since the outline of the functions of the processor 301, the main memory 302, the auxiliary storage unit 303, and the transmission line 308 is the same as that of the processor 11, the main memory 12, the auxiliary storage unit 13, and the transmission line 15, the description thereof will be omitted.

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

The wireless communication unit 306 exchanges data with and from the access point 6 by wireless communication according to the wireless communication protocol. As the wireless communication unit 306, for example, a well-known communication device compliant with 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.

The auxiliary storage unit 303 stores the smartphone POS application AP301, which is one of the information processing programs. The smartphone POS application AP301 is an application program, and describes information processing described later for causing the user terminal 300 to function as a user interface of the store system 100. The smartphone POS application AP301 is commonly used by a plurality of user terminals 300.

As the hardware of the store server 1, the virtual POS server 2, or the mobile controller 3, for example, a general-purpose server device can be used. Then, in the transfer of the store server 1, the virtual POS server 2 or the mobile controller 3, the store management application AP11, the virtual POS application AP21 or the registration support application AP31 are generally stored in the auxiliary storage units 13, 23 or 33, respectively, and the database group DB11, The transaction database DB21, or the transaction management database DB31 and the registration database DB32 are not stored. However, the 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 another version of the application program of the same type is stored in the auxiliary storage unit 13, 23 or 33. The hardware in the state of being in the state and the store management application AP11, the virtual POS application AP21, or the registration support application AP31 may be individually transferred. Then, the store management application AP11, the virtual POS application AP21, or the registration support application AP31 is written to the auxiliary storage unit 13, 23 or 33 according to the operation of an arbitrary worker, so that the store server 1, the virtual POS server 2 or the store server 2 or The mobile controller 3 may be configured. The transfer of the store management application AP11, the virtual POS application AP21, or the registration support application AP31 is performed by recording on a removable recording medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network. be able to. In the transaction database DB21, or the transaction management database DB31 and the registration database DB32, the processor 11,21 or 31 executes information processing based on the store management application AP11, the virtual POS application AP21, or the registration support application AP31, so that the auxiliary storage unit 13 , 23 or 33. At least a part of the database included in the store management application AP11 and the database group DB11 may be stored in the main memory 12. At least a part of the virtual POS application AP21 and the transaction database DB21 may be stored in the main memory 22. At least a part of the registration support application AP31, the transaction management database DB31, and the registration database DB32 may be stored in the main memory 32.

Next, the operation of the transaction processing system configured as described above will be described. The contents of the various processes described below are examples, and it is possible to change the order of some processes, omit some processes, add another process, and the like as appropriate. For example, in the following description, in order to explain the characteristic operation of the present embodiment in an easy-to-understand manner, the description of some processes is omitted. For example, when some error occurs, processing for dealing with the error may be performed, but a part of such processing is omitted.
The service provided to the customer by the operation of the transaction processing system described below is referred to as a smartphone POS service.

The user terminal 300 exchanges data with the store system 100 in order to use the smartphone POS service, and whether to use wireless communication with the access point 6 or wireless communication with the communication network 400 for communication for that purpose is determined. It depends on the state of the flags included in the check-in data. However, in the following, for the sake of simplification of the description, a case where only wireless communication with the access point 6 is used will be described. In addition, there is a mode in which data transfer from the virtual POS server 2 to the accounting machine 5 is requested from the accounting machine 5 to the mobile controller 3 in order for the accounting machine 5 to perform accounting, and there is no request from the accounting machine 5. Whether to use the mode of transferring data from the mobile controller 3 to the accounting machine 5 is determined by the state of the flag included in the check-in data. However, in the following description, for the sake of simplification of the description, a mode for requesting data transfer from the accounting machine 5 to the mobile controller 3 will be fixedly used.

In order to use the smartphone POS service, the customer installs the smartphone POS application AP301 on his / her own smartphone or the like and makes it available as the user terminal 300. Alternatively, the customer rents a user terminal 300 configured by installing the smartphone POS application AP301 on a tablet terminal or the like at a store. Then, the customer takes the user terminal 300 in the state of activating the information processing based on the smartphone POS application AP301 and enters any store in which the store system 100 is provided.

Now, in the user terminal 300, the processor 301 executes information processing as shown in FIGS. 9, 10, 11, 12, and 13 based on the smartphone POS application AP301.
First, as the ACT 101 shown in FIG. 9, the processor 301 displays the main menu screen on the touch panel 304. The main menu screen is a screen for receiving the designation of any of several processes to be performed based on the smartphone POS application AP301. On the main menu screen, a plurality of GUI elements including a GUI (graphical user interface) element for designating the start of shopping are arranged. The GUI element is, for example, a soft key.

As the ACT 102, the processor 301 confirms whether or not the start of shopping is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to the ACT 103.
As the ACT 103, the processor 301 confirms whether or not a designation other than the start of shopping has been made. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to the ACT 102.
Thus, the processor 301 waits for the ACT 102 and the ACT 103 to be specified on the main menu screen. Then, if a designation other than the start of shopping is made, the processor 301 determines YES in the ACT 103 and proceeds to the designated process. The description of the processing of the processor 301 in this case will be omitted.

When the customer enters the store and starts shopping, the customer performs a predetermined operation for designating the start of shopping on the main menu screen.
When the operation for designating the start of shopping is detected on the touch panel 304, the processor 301 determines YES on the ACT 102 and proceeds to the ACT 104.
As the ACT 104, the processor 301 causes the touch panel 304 to display a scan screen for check-in. The check-in scan screen is a screen that prompts the customer to read the check-in two-dimensional code TC1. For example, the processor 301 activates the camera 305, and the image obtained by the camera 305 shows a character message prompting the customer to read the two-dimensional code TC1 and an indication of the position where the two-dimensional code TC should be held. Generate a scan screen by overlapping the lines.

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

As the ACT 106, the processor 301 confirms whether or not the data represented by the read two-dimensional code is the check-in data. Then, the processor 301 determines NO if it is not the check-in data, and returns to the ACT 105. At this time, the processor 301 may display a screen on the touch panel 304 notifying the customer that the erroneous two-dimensional code has been read.

If the processor 301 can confirm that the data represented by the read two-dimensional code is the check-in data, the processor 301 determines YES in the ACT 106 and proceeds to the ACT 107.
As the ACT 107, the processor 301 stores the read check-in data in the main memory 302 or the auxiliary storage unit 303.

As an ACT 108, the processor 301 requests the mobile controller 3 to check in. Specifically, the processor 301 establishes wireless communication between the wireless communication unit 306 and the access point 6 based on the data represented in the check-in data. For example, if the customer points the camera 305 at the 2D code TC1A at the store A, the processor 301 wirelessly communicates with the access point 6 provided in the store system 100A based on the check-in data represented by the 2D code TC1A. Establish communication. Then, the processor 301 transmits the request data for requesting the check-in to the mobile controller 3 via the wireless communication with the access point 6. When wireless communication with the access point 6 provided in the store system 100A is established as described above, the request data is transmitted via the access point 6 provided in the store system 100A and the in-store communication network 7. Then, it is transmitted to the mobile controller 3 provided in the store system 100A. The processor 301 includes identification data for identifying the request for check-in 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 include other data in the request data, such as data for authenticating the customer.
In addition, as for various requests from the user terminal 300 to the mobile controller 3 described below, the request data including the identification data for identifying the reason for the request is transmitted to the access point 6 and the in-store communication network 7 in the same manner as described above. This is realized by sending data from the user terminal 300 to the mobile controller 3 via the user terminal 300.

In the mobile controller 3, when the request data for requesting check-in is received by the communication interface 34, the processor 31 starts information processing regarding the transaction with the customer who is trying to check-in.

14, 15, 16, 16 and 17 are flowcharts of information processing by the processor 31.
The processor 31 starts the information processing every time the request data for requesting the check-in is received by the communication interface 34. If the information processing started based on another request has already been executed, new information processing is started in parallel with it. That is, the processor 31 may execute a plurality of information processing in parallel for each of the plurality of user terminals 300. In the following, when the term "user terminal 300" is simply used, it means the user terminal 300 that is the target of information processing of the processor 31.

As the ACT 201 of FIG. 14, the processor 31 performs a check-in process. The processor 31 requests, for example, the virtual POS server 2 to start a transaction, and receives a notification of the transaction code. Then, the processor 31 adds a new data record DR1 in which the terminal code included in the request data is set in the field F11 to the transaction management database DB 31. If the request data includes a membership code, the processor 31 sets the membership code in the field F12 of the new data record DR1. The processor 31 sets the notified transaction code in the field F13 of the new data record DR1. Further, the processor 31 sets "0" as a confirmation flag in the field F14 of the new data record DR1. As a result, the management of transactions performed using the user terminal 300 requesting check-in is started.

When the mobile controller 3 requests the start of the transaction in the virtual POS server 2, the processor 21 determines the transaction code according to a predetermined rule, and starts the registration process of the purchased product associated with the transaction code. do. Further, the processor 21 notifies the mobile controller 3 of the determined transaction code.

As the ACT 202, the processor 31 confirms whether or not the check-in process has been completed normally. Then, if the check-in process cannot be completed normally due to some abnormality, the processor 31 determines NO and proceeds to ACT 203.
As the ACT 203, the processor 31 notifies the user terminal 300 of an error. For example, the processor 31 transmits notification data for error notification to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes identification data for identifying that it is an error notification in the notification data. The processor 31 may include an error code indicating the cause of the error in the notification data.
In addition, in the various notifications from the mobile controller 3 to the user terminal 300 described below, the notification data including the identification data for identifying the reason for the notification is transmitted to the in-store communication network 7 and the access point 6 in the same manner as described above. This is realized by sending data from the mobile controller 3 to the user terminal 300 via the mobile controller 3.

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

At the user terminal 300, the processor 301 proceeds to the ACT 109 after requesting the check-in at the ACT 108 in FIG.
As the ACT 109, the processor 301 confirms whether or not the check-in completion has been notified. Then, if the processor 301 cannot confirm the notification, it determines NO and proceeds to the ACT 110.
As the ACT 110, the processor 301 confirms whether or not a check-in error has been notified. Then, if the processor 301 cannot confirm the notification, it determines NO and returns to ACT109.
Thus, the processor 301 waits for the ACT 109 and ACT 110 to be notified of the completion of check-in or an error. Then, if the notification data for the above-mentioned error notification is received by the wireless communication unit 306, the processor 301 determines YES in the ACT 110 and proceeds to the ACT 111.

As the ACT 111, the processor 301 displays an error screen on the touch panel 304. The error screen is a screen defined as a screen for notifying the customer that check-in is not possible. The processor 301 returns to the ACT 101 when it is instructed to cancel the display of the error screen by, for example, operating the GUI element displayed in the error screen.

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

FIG. 18 is a diagram showing an example of the list screen SC1.
The list screen SC1 includes display areas AR11, AR12 and buttons BU11, BU12, and BU13. The display area AR11 represents the total number of purchased products and the total price of the purchased products. The display area AR12 represents a list of purchased products. The button BU 11 is a soft key for the customer to declare that he / she cancels all the purchased products and cancels the shopping. The button BU12 is a softkey for the customer to declare that the scan of the product registered as the purchased product is started. Button BU13 is a softkey for the customer to declare to start accounting.

Note that FIG. 18 shows the list screen SC1 in which the purchased product has not been registered yet. Therefore, both the total number and the total amount represent "0" in the display area AR11, and nothing is represented in the display area AR12.

As the ACT 113 in FIG. 10, the processor 301 confirms whether or not the start of scanning the product is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT 114.
As the ACT 114, the processor 301 confirms whether or not the quantity change is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT 115.
As the ACT 115, the processor 301 confirms whether or not the cancellation of shopping is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT116.
As the ACT 116, the processor 301 confirms whether the start of accounting has been specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to the ACT 113.
Thus, the processor 301 waits for ACT113 to ACT116 to specify any of scan start, quantity, stop, and accounting start.

If the customer registers the product as a purchased product, the customer specifies 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 the ACT 113, and proceeds to the ACT 117.
As the ACT 117, the processor 301 displays the registration screen on the touch panel 304. The registration screen is a screen that prompts the customer to read a barcode representing the product code of the product to be registered as a purchased product.

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 the image obtained by the camera 305. The message ME21 is a character message prompting the customer to read the barcode of the product. Button BU21 is a softkey for the customer to declare to stop scanning the product code.

For example, the processor 301 activates the camera 305, and superimposes the line representing the range of the display area AR21 and the image showing the message ME21 and the button BU21 on the image obtained by the camera 305 to generate the registration screen SC2. do.

As the ACT 118 in FIG. 10, the processor 301 confirms whether or not the barcode has been read. At this time, the processor 301 analyzes the image obtained by the camera 305 and tries to read the barcode. The reading of the barcode may be performed as a process based on the smartphone POS application AP301, or may be performed as a process based on another application program for reading the barcode. Then, if the bar code cannot be read, the processor 301 determines NO and proceeds to ACT119.
As the ACT 119, the processor 301 confirms whether or not the stop of the scan is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to the ACT 118.
Thus, the processor 301 waits for the ACT 118 and the ACT 119 to read the barcode or to specify that the scan should be stopped.
If the customer wishes to return to the list screen without performing this scan, the customer specifies to cancel the scan by a predetermined operation such as touching the button BU21. In response to this, the processor 301 determines YES in the ACT 119 and returns to the ACT 112.

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

By the way, in the mobile controller 3, the processor 31 proceeds to ACT205 after notifying the completion of check-in at ACT204 in FIG.
As the ACT 205, the processor 31 confirms whether registration has been requested. Then, if the corresponding request cannot be confirmed, the processor 31 determines NO and proceeds to ACT206.

As the ACT 206, the processor 301 confirms whether or not the quantity change is requested. Then, if the corresponding request cannot be confirmed, the processor 31 determines NO and proceeds to ACT207.
As the ACT 207, the processor 31 confirms whether or not the deletion of the purchased product is requested. Then, if the corresponding request cannot be confirmed, the processor 31 determines NO and proceeds to ACT208.
As the ACT 208, the processor 31 confirms whether or not the cancellation of the purchased product is requested. Then, if the corresponding request cannot be confirmed, the processor 31 determines NO and proceeds to ACT209.
As ACT209, processor 31 confirms whether accounting is required. Then, if the corresponding request cannot be confirmed, the processor 31 determines NO and returns to ACT205.
Thus, the processor 31 waits for ACT205-ACT209 to request any of registration, quantity change, deletion, cancellation, and accounting. Then, if the user terminal 300 requests registration as described above, the processor 31 determines YES in the ACT 205 and proceeds to the ACT 210 in FIG.

As the ACT 210, the processor 31 transfers the registration request to the virtual POS server 2 with the notification of the transaction code of the transaction to be 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 it is, or may transmit the converted request data 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.

In the virtual POS server 2, the processor 21 considers that the barcode data included in the request data sent from the mobile controller 3 is read by the barcode scanner provided in the existing POS terminal. , Attempts to register purchased products by the same processing as existing POS terminals. However, for some reason, the product code represented by the barcode data may not be registered in the product database. In addition, the product may have a barcode different from the one representing the product code. Then, in these cases, the processor 21 cannot register the purchased product, resulting in an error. In this way, the processor 21 registers the purchased product based on the reading of the barcode representing the product code registered in the product database. Thus, when the processor 21 executes information processing based on the virtual POS application AP21, the computer having the processor 21 as a central part functions as a registration means. The processor 21 manages purchased products using the transaction database DB 21.

The processor 21 transmits the result data representing the result of such processing to the mobile controller 3. When the purchased product is correctly registered, the processor 21 includes identification data for identifying the notification of regular registration, and the product code, product name, and price of the registered product in the result data. Further, when an error occurs, the processor 21 includes identification data for identifying that it is an error notification and bar code data sent in the registration request in the result data.

The processor 31 in the mobile controller 3 transfers the registration request in the ACT 210, and then proceeds to the ACT 211.
As the ACT 211, the processor 31 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.

As the ACT 212, the processor 31 updates the registration database DB 32 based on the above result data. The update of the registration database DB 32 is performed as follows, for example.

First case: Notification of regular registration, when the data record DR2 associated with the transaction to be processed does not include registration data including the notified product code.
In this case, the processor 31 adds a new field next to the last field that already exists in the data record DR2 associated with the transaction being processed, and adds new registration data to that field. The processor 31 includes the notified product code, an error flag set to "0" indicating that it is not an error, the notified product name and price, and the number set to "1" in the new registration data. Includes a cancellation flag set to "0" to indicate that it has not been canceled. Thus, the registration data added in this case has a structure as shown on the upper right side of FIG.

Second case: It is a notification of regular registration, and although the data record DR2 associated with the transaction to be processed contains the registration data including the notified product code, the registration data is canceled. When it is "1" indicating that the flag has been canceled.
In this case, the processor 31 processes in the same manner as in the case of the first case described above.

Third case: Notification of regular registration, the data record DR2 associated with the transaction to be processed contains registration data including the notified product code, and the cancellation flag of the registration data. When is "0".
In this case, the processor 31 rewrites the value of the number included in the registered data including the notified product code and the cancellation flag is "0" to a value one larger.

Fourth case: When it is an error notification.
In this case, the processor 31 adds a new field next to the last field that already exists in the data record DR2 associated with the transaction being processed, and adds new registration data to that field. The processor 31 includes the notified barcode data and an error flag set to "1" indicating an error in the new registration data. Thus, the registration data added in this case has a structure as shown in the lower right side of FIG.

By being updated by the processor 31 in this way, the registration database DB 32 represents a list of purchased products registered in the virtual POS server 2, and in addition, records an error bar code reading.
The processor 31 stores the barcode data sent in the registration request in the main memory 32 or the auxiliary storage unit 33, and in the fourth case described above, the stored barcode data is stored in the registration data. May be included in. In this case, the processor 21 in the virtual POS server 2 does not have to include the barcode data in the result data. Further, the processor 31 may take out the product code from the stored barcode data and process the first to third cases based on the product code. Further, the product name and the price may be acquired by the processor 31 from the store server 1 or the like based on the product code.

As ACT 213, the processor 31 confirms whether or not this registration has been performed properly. Then, for example, if the result data represents an error, the processor 31 determines NO and proceeds to ACT214.
As the ACT 214, the processor 31 rewrites the confirmation flag set in the field F14 with respect to the data record DR1 in which the transaction to be processed is associated with the transaction management database DB 31. The processor 31 may write "1" regardless of the state before rewriting, or may leave it as it is if the state before rewriting is "1".
For example, if the result data represents regular registration, the processor 31 determines YES in ACT 213 and proceeds to ACT 215.
As ACT215, the processor 31 determines whether or not the confirmation required flag set in the field F14 of the data record DR1 associated with the transaction to be processed in the transaction management database DB31 is "1". Check. Then, if the confirmation required flag is not "1", the processor 31 determines NO and proceeds to ACT216.

As the ACT 216, the processor 31 confirms whether or not the purchased product registered this time is a confirmation-required product. Then, the processor 31 determines NO if it is not a product requiring confirmation, and proceeds to ACT217. The processor 31 proceeds to ACT 217 even when the confirmation required flag is rewritten to "1" in ACT 214 and when the confirmation required flag is "1" and the ACT 215 determines YES. ..

As ACT217, the processor 31 instructs the user terminal 300 to display the list screen. For example, the processor 31 transmits instruction data including identification data for identifying the display instruction on the list screen to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes the product code, product name, price, and quantity of the transaction to be processed included in the data record DR2 associated with the registration database DB 32 in the instruction data. If the registration this time is an error, the processor 31 includes error data indicating that fact in the instruction data. Then, the processor 31 then returns to the standby state of ACT205 to ACT209 in FIG.
In addition, in the various instructions from the mobile controller 3 to the user terminal 300 described below, the instruction data including the identification data for identifying the reason for the instruction is transmitted to the in-store communication network 7 and the access point 6 in the same manner as described above. This is realized by sending data from the mobile controller 3 to the user terminal 300 via the mobile controller 3.

On the other hand, if the processor 31 determines YES in the ACT 216 because it is a product requiring confirmation, the process proceeds to the ACT 218. That is, the processor 31 proceeds to ACT218 when the officially registered product is a confirmation-required product and the confirmation-required flag is "0".
As the ACT 218, the processor 31 rewrites the confirmation flag set in the field F14 with respect to the data record DR1 in which the transaction to be processed is associated with the transaction management database DB 31.

As ACT218, the processor 31 instructs the user terminal 300 to display the guidance screen. In the instruction data for instructing the display of the guidance screen, the processor 31 includes a product code, a product name, a price, and a product code, a product name, and a price included in the data record DR2 in which the transaction to be processed is associated with the registration database DB 32. Include the number. Then, the processor 31 then returns to the standby state of ACT205 to ACT209 in FIG.

The processor 301 at the user terminal 300 requests registration at the ACT 120 in FIG. 10, and then proceeds to the ACT 121 in FIG.
As the ACT 121, the processor 301 confirms whether or not the display of the guidance screen is instructed. Then, if the corresponding instruction cannot be confirmed, the processor 301 determines NO and proceeds to ACT 122.
As the ACT 122, the processor 301 confirms whether or not the display of the list screen is instructed. Then, if the corresponding instruction cannot be confirmed, the processor 301 determines NO and returns to the ACT 121.

Thus, the processor 301 waits for the display instruction of the guidance screen or the list screen as the ACT 121 and the ACT 122. Then, if the display of the list screen is instructed by the mobile controller 3 as described above, the processor 301 determines YES in the ACT 122, returns to the ACT 112 in FIG. 10, and displays the list screen SC1 on the touch panel 304 again. Let me. At this time, the processor 301 makes the list screen SC1 a screen showing the product name, price, and quantity of the purchased product included in the instruction data.

FIG. 20 is a diagram showing an example of the list screen SC1 in a state where the purchased product is registered.
In the list screen SC1 shown in FIG. 20, one product has a product name of "AAA" and a price of 120 yen, two products have a product name of "BBB" and a price of 98 yen, and so on. This is an example in which one product whose product name is "CCC" and whose price is 1,024 yen is registered as a purchased product. And none of these products require confirmation. In the list screen SC1 shown in FIG. 20, the display area AR12 shows the product name, price, and quantity of these registered products. Further, in the display area AR11, "4" is represented as the total number and "1,340" is represented as the total amount. The area surrounded by the broken line on the left side of the product name represents the area for displaying the icon. The broken line representing the area is not actually displayed on the list screen SC1.

FIG. 21 is a diagram showing an example of the list screen SC1 in a state where the purchased product is registered.
In the list screen SC1 shown in FIG. 21, one product has a product name of "AAA" and a price of 120 yen, two products have a product name of "BBB" and a price of 98 yen, and a product. When one product whose name is "CCC" and the price is 1,024 yen, and one product whose product name is "DDD" and whose price is 380 yen is registered as a purchased product. Is an example of. A product whose product name is "DDD" is a product that requires confirmation. In the list screen SC1 shown in FIG. 21, the display area AR12 shows the product name, price, and quantity of these registered products. Further, in the display area AR11, "5" is represented as the total number and "1,720" is represented as the total amount. Further, next to the product name "DDD", an icon IC11 indicating that the product has an age limit for the purchaser is displayed.

On the other hand, if the display of the guidance screen is instructed by the mobile controller 3 as described above, the processor 301 determines YES at the ACT 121 in FIG. 11 and proceeds to the ACT 123.
As the ACT 123, the processor 301 displays the guidance screen on the touch panel 304. The guidance screen is a screen for instructing the customer that confirmation by a clerk is required at the time of checkout.

FIG. 22 is a diagram showing an example of the guidance screen SC3.
The guidance screen SC3 is a screen in which the 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 character message indicating that confirmation by a clerk is required at the time of checkout. The button BU 31 is a soft key for the customer to declare that he / she has confirmed the guidance on the guidance screen SC3. The processor 301 generates a list screen SC1 showing the product name, price, and quantity of the purchased products included in the instruction data, and superimposes the window WI31 on the list screen SC1 to generate the guidance screen SC3.

After confirming the guidance on the guidance screen SC3, the customer declares that the confirmation has been made by a predetermined operation such as touching the button BU31 on the guidance screen SC3. In response to this, the processor 301 returns from the ACT 123 in FIG. 11 to the ACT 112 in FIG. 10, and causes the list screen SC1 to be displayed on the touch panel 304 again. The processor 301 may return from the ACT 123 to the ACT 112 when the elapsed time in the state where the guidance screen SC3 is displayed reaches a predetermined time.

When the customer touches the area showing the number on the list screen SC1, the processor 301 displays a list box for specifying the number on the list screen SC1. Then, when this list box is operated, the processor 301 receives this as a designation of the number. Then, in this case, the processor 301 determines YES at the ACT 114 in FIG. 10, and proceeds to the ACT 124 in FIG.

As the ACT 124, the processor 301 confirms whether or not the specified number is 0. Then, the processor 301 determines NO if the specified number is not 0, and proceeds to the ACT 125.
As the ACT 125, the processor 301 requests the mobile controller 3 to change the quantity. The request data transmitted by the processor 301 includes specific data for specifying a specified number of products and a specified number of products. The specific data may be a product code, or may be data that can identify the purchased product only by the mobile controller 3, such as a number for identifying each purchased product in the list of purchased products. If the product code is used as the specific code, the processor 31 includes the product code related to each purchased product in the instruction data for instructing the display of the list screen or the instruction data for instructing the display of the guidance screen.

When the mobile controller 3 requests the quantity change from the user terminal 300 as described above, the processor 31 determines YES in the ACT 206 in FIG. 14 and proceeds to the ACT 220 in FIG.
As the ACT 220, the processor 31 transfers the request for quantity change to the virtual POS server 2 with the notification of the transaction code of the transaction to be 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 it is, or may transmit the converted request data by some processing to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the number included in the request data sent from the user terminal 300. 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.

In the virtual POS server 2, the processor 21 considers that the number included in the request data sent from the mobile controller 3 is input by the input device provided in the existing POS terminal, and considers that the number is input by the existing POS terminal. The number of purchased products is changed by the same processing as the POS terminal. The processor 21 transmits the product code of the product whose quantity has been changed and the result data representing the quantity after the change to the mobile controller 3.

The processor 31 in the mobile controller 3 transfers the quantity change request in the ACT 220, and then proceeds to the ACT 221.
As the ACT 221, 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.

As ACT222, the processor 31 updates the registration database DB 32 based on the above result data. That is, the processor 31 finds out the registration data including the notified product code from the data record DR2 associated with the transaction to be processed. Then, the processor 31 rewrites the number included in the corresponding registration data to the number included in the result data.

The processor 31 stores the specific data and the quantity sent in the quantity change request data in the main memory 32 or the auxiliary storage unit 33, and receives the result data indicating that the update is completed. , The number of registered data related to the product specified by the stored specific data may be rewritten to the stored number. In this case, in the virtual POS server 2, the processor 21 does not have to include the product code and the number in the result data.

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

If the designated number of the processor 301 is 0 in the user terminal 300, the processor 301 determines YES in the ACT 124 of FIG. 11 and proceeds to the ACT 126.
As the ACT 126, the processor 301 displays the deletion screen on the touch panel 304. The deletion screen is a screen for notifying the customer that the product for which the number is specified to be 0 is deleted from the purchased product. The delete screen includes a delete button for specifying deletion and a return button for specifying returning to the state before specifying the number change without changing the number.

As ACT127, processor 301 confirms whether deletion is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT128.
As ACT128, processor 301 confirms whether a return has been specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to ACT127.
Thus, the processor 301 waits for ACT 127 and ACT 128 to be designated for deletion or return.

If the customer wishes to cancel the deletion and return to the state before specifying the change in the number, the customer specifies the return by a predetermined operation such as touching the return button on the deletion screen. In response to this, the processor 301 determines YES in the ACT 128, returns to the ACT 112 in FIG. 10, and causes the list screen SC1 to be displayed on the touch panel 304 again. In this case, since the registered state of the purchased product is not changed, the processor 301 causes the touch panel 304 to display the list screen SC1 in the same state as that displayed before displaying the deletion screen again on the touch panel 304.

If there is no mistake in the deletion, the customer specifies the deletion by a predetermined operation such as touching the delete button on the delete screen. In response to this, the processor 301 determines YES in the ACT 127, and proceeds to the ACT 129.
As ACT129, the processor 301 requests the mobile controller 3 to delete it. The request data transmitted by the processor 301 includes specific data for identifying the product for which deletion is specified.

When the processor 31 is requested to be deleted from the user terminal 300 as described above in the mobile controller 3, the processor 31 determines YES in the ACT 207 in FIG. 14, and proceeds to the ACT 224 in FIG.
As the ACT 224, the processor 31 transfers the deletion request to the virtual POS server 2 with the notification of the transaction code of the transaction to be 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 it is, or may transmit the converted request data by some processing to the virtual POS server 2. However, if the specific data included in the request data is not the product code, the processor 31 replaces the specific data with the product code.

In the virtual POS server 2, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a deletion instruction input by the input device provided in the existing POS terminal, and considers the request to be a deletion instruction, and the existing POS terminal. Exclude the target product from the purchased products by the same processing as above. The processor 21 transmits the result data representing the product code of the product excluded from the purchased products to the mobile controller 3.

The processor 31 in the mobile controller 3 transfers the deletion request in the ACT 224, and then proceeds to the ACT 225.
As the ACT 225, the processor 31 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.

As the ACT 226, the processor 31 updates the registration database DB 32 based on the above result data. That is, the processor 31 finds out the registration data including the notified product code from the data record DR2 associated with the transaction to be processed. Then, the processor 31 changes the cancellation flag included in the corresponding registration data to "1".

The processor 31 saves the specific data sent as the deletion request data in the main memory 32 or the auxiliary storage unit 33, and receives the result data indicating that the deletion is completed. The cancellation flag of the registration data related to the product specified by the specific data may be changed. In this case, the processor 21 in the virtual POS server 2 does not have to include the product code in the result data.

As ACT227, the processor 301 confirms whether or not the deleted product is a product requiring confirmation. Then, the processor 301 determines YES if it is a product requiring confirmation, and proceeds to ACT228.
As ACT228, the processor 301 confirms whether or not there is another confirmation-required product in the purchased product of the transaction to be processed. Then, the processor 301 determines NO if there is no corresponding product, and proceeds to ACT229. That is, the processor 301 proceeds to ACT229 when the purchased product does not include any product requiring confirmation due to the product deletion this time.

As the ACT 229, the processor 301 changes the confirmation flag set in the field F14 to "0" for the data record DR1 in which the transaction to be processed is associated with the transaction management database DB31.
As the ACT 230, the processor 31 instructs the user terminal 300 to display the list screen. For example, the processor 31 transmits instruction data including identification data for identifying the display instruction on the list screen to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes the product code, product name, price, and quantity included in the registration data in which the cancellation flag is "0" among the registration data included in the data record DR2 updated as described above in the instruction data. .. After that, the processor 31 returns to the standby state of ACT205 to ACT209 in FIG. The processor 31 sets ACT229 and ACT230 when the deleted product is not a confirmation-required product and therefore is determined to be NO by ACT227, or when there is another confirmation-required product and is determined to be YES by ACT228. It passes and returns to the standby state of ACT205 to ACT209 in FIG.

By the way, after the processor 301 requests the quantity change in the ACT 125 or the deletion in the ACT 129 in the user terminal 300, the processor 301 proceeds to the ACT 130.
As the ACT 130, the processor 301 waits for an instruction to display the list screen. Then, the processor 301 determines YES if the display of the list screen is instructed by the mobile controller 3 as described above in response to the request for quantity change or the request for deletion, and proceeds to the ACT 112 in FIG. Is returned, and the list screen SC1 is displayed on the touch panel 304 again. At this time, the processor 301 uses the list screen SC1 as a screen showing the product name, price, and quantity of the purchased product included in the instruction data. In this case, since the registered state of the purchased product is changed, the processor 301 touches the touch panel 304 on the list screen SC1 in a state representing the purchased product different from the one displayed when the quantity change or deletion is specified. Will be displayed on.

When the customer wants to cancel all the purchased products already registered and cancel the shopping, the customer specifies the 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 the ACT 115, and proceeds to the ACT 131 in FIG.
As the ACT 131, the processor 301 displays the cancellation screen on the touch panel 304. The cancellation screen is a screen that notifies the customer that all the purchased products that have already been registered will be cancelled. The cancel screen includes an execute button for designating a cancel execution and a return button for designating a return to the state before the number change was specified without changing the number.

As the ACT 132, the processor 301 confirms whether or not the cancellation execution is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT 133.
As ACT 133, processor 301 confirms whether a return has been specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to the ACT 132.
Thus, the processor 301 waits for the ACT 132 and ACT 133 to be designated for cancellation execution or return.

If the customer continues shopping as it is, the customer specifies a return by a predetermined operation such as touching the return button on the cancel screen. In response to this, the processor 301 determines YES in the ACT 133, returns to the ACT 112 in FIG. 10, and causes the list screen SC1 to be displayed on the touch panel 304 again. In this case, since the registered state of the purchased product is not changed, the processor 301 causes the touch panel 304 to display the list screen SC1 in the same state as that displayed before displaying the cancel screen again on the touch panel 304.

If the customer cancels the shopping, the customer specifies the cancellation execution by a predetermined operation such as touching the execution button on the cancellation screen. In response to this, the processor 301 determines YES in the ACT 132, and proceeds to the ACT 134.
As the ACT 134, the processor 301 requests the mobile controller 3 to cancel.

If the mobile controller 3 requests cancellation from the user terminal 300 as described above, the processor 31 determines YES at ACT 208 in FIG. 14 and proceeds to ACT 231 in FIG.
As the ACT 231, the processor 31 transfers the cancellation request to the virtual POS server 2 with the notification of the transaction code of the transaction to be 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 it is, or may transmit the converted request data by some processing to the virtual POS server 2.

In the virtual POS server 2, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a cancellation instruction input by the input device provided in the existing POS terminal, and regards the request as a cancellation instruction, and the existing POS terminal. By the same process as above, all the registered products associated with the notified transaction code are excluded from the purchased products. The processor 21 transmits the result data indicating that the cancellation is completed to the mobile controller 3.

The processor 31 in the mobile controller 3 transfers the deletion request in the ACT 231 and then proceeds to the ACT 232.
As ACT232, the processor 31 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.

As the ACT 233, the processor 31 updates the registration database DB 32 based on the above result data. That is, the processor 31 changes the cancellation flag, which is “0”, to “1” for all the registered data included in the data record DR2 associated with the transaction to be processed.

As ACT234, the processor 301 changes the confirmation flag set in the field F14 to "0" for the data record DR1 in which the transaction to be processed is associated with the transaction management database DB31.
As ACT235, 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.

Now, the processor 301 at the user terminal 300 requests cancellation at the ACT 134, and then proceeds to the ACT 135.
As the ACT 135, the processor 301 waits for the cancellation notification from the mobile controller 3. Then, the processor 301 determines YES if the cancellation is notified as described above, and returns to the ACT 101 in FIG.

When the customer has registered all the products he / she wishes to purchase as purchased products, he / she proceeds to payment. At this time, the customer specifies the start of accounting by a predetermined operation such as touching the button BU13 on the list screen SC1. In response to this, the processor 301 determines YES at ACT116 in FIG. 10, and proceeds to ACT136.
As ACT 136, the processor 301 requests the mobile controller 3 to make an account.

If the mobile controller 3 requests accounting from the user terminal 300 as described above, the processor 31 determines YES at ACT209 in FIG. 14 and proceeds to ACT236 in FIG.
As ACT236, the processor 31 is set in the field F14 of the data record DR1 associated with the transaction to be processed in the transaction management database DB31, and confirms whether or not the confirmation required flag is “1”. Then, if the corresponding confirmation flag is "1", it is determined as YES, and the process proceeds to ACT237. That is, the processor 31 proceeds to ACT237 if the purchased product includes a product requiring confirmation or if there is a product that has not been correctly registered. In the following, such a state in which the confirmation required flag is "1" is referred to as a confirmation required state.
As ACT237, the processor 31 instructs the user terminal 300 to display the confirmation screen.

Now, the processor 301 at the user terminal 300 requests accounting at ACT 136 in FIG. 10, and then proceeds to ACT 137.
As the ACT 137, the processor 301 confirms whether or not the display of the confirmation screen is instructed. Then, if the instruction cannot be confirmed, the processor 301 determines NO and proceeds to ACT138.
As ACT138, the processor 301 confirms whether or not the display of the accounting screen is instructed. Then, if the instruction cannot be confirmed, the processor 301 determines NO and returns to ACT137.
Thus, the processor 301 waits for the ACT 137 and the ACT 138 to be instructed to display the confirmation screen or the accounting screen. Then, when the display of the confirmation screen is instructed by the mobile controller 3 as described above, the processor 301 determines YES in ACT 137 and proceeds to ACT 139 in FIG.
As ACT 139, the processor 301 displays a confirmation screen. The confirmation screen is a screen for encouraging the customer to contact the clerk to confirm the product requiring confirmation.

FIG. 23 is a diagram showing an example of the confirmation screen SC4.
The confirmation screen SC4 is a screen in which the window WI41 is superimposed on the list screen SC1 displayed immediately before. The window WI41 includes a message ME41 and buttons BU41 and BU42. The message ME41 is a character message indicating that it is necessary to receive confirmation by a clerk. The button BU41 is a softkey for the customer to specify that the customer should be confirmed by the clerk. The button BU42 is a soft key for the customer to specify to return to the product registration.

If the customer decides to receive confirmation by the clerk, he / she specifies confirmation by a predetermined operation such as touching the button BU41. If the customer decides to cancel the checkout and return to the product registration, he / she specifies the return by a predetermined operation such as touching the button BU42.

As the ACT 140 in FIG. 12, the processor 301 confirms whether or not the confirmation is specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT 141.
As ACT 141, processor 301 confirms whether a return has been specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to the ACT 140.
Thus, the processor 301 awaits confirmation or return designation for ACT 140 and ACT 141. Then, if the confirmation is specified as described above, the processor 301 determines YES in the ACT 140 and proceeds to the ACT 142.

As the ACT 142, the processor 301 displays the release screen on the touch panel 304. The release screen is a screen for causing the user terminal 300 to read the barcode for canceling the confirmation required state.

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 the image obtained by the camera 305. The message ME51 is a character message prompting the clerk to read the bar code for canceling the confirmation required state. The button BU 51 is a soft key for the customer or the clerk to declare that the scanning of the bar code for release is stopped.
For example, the processor 301 activates the camera 305, and superimposes the line representing the range of the display area AR51 and the image showing the message ME51 and the button BU51 on the image obtained by the camera 305 to generate the release screen SC5. do.

The customer asks the clerk for confirmation. For example, if the purchased product includes a product requiring confirmation, the clerk confirms that the product requiring confirmation is allowed to be sold. In addition, the clerk confirms, for example, the products owned by the customer and confirms that the unregistered products are not included. Then, if all of these are satisfied, the clerk determines that the settlement is permitted, and holds the release barcode on the camera 305 so that the release barcode is reflected in the display area AR51. The clerk should carry a card with a barcode for unlocking printed on it for this work. Alternatively, the clerk displays a bar code for cancellation on the screen of the information terminal in possession. It should be noted that the bar code for cancellation is preferably different for each store or each business operator. However, it is permissible for different stores or different businesses to use the same unlocking barcode. Further, by changing the regular cancellation barcode, for example, every day, it is possible to prevent fraud when the cancellation barcode is acquired by the customer for some reason.

If the clerk confirms that the sale of the product requiring confirmation is not permitted or that the customer has an unregistered product, the clerk can perform the product registration by a predetermined operation such as touching the button BU51. Specifies the return of. Alternatively, if the customer decides to return to the product registration without asking the clerk for confirmation, he / she specifies the return to the product registration by a predetermined operation such as touching the button BU51.
Subsequent measures for products requiring confirmation or unregistered products may be appropriately taken by the customer or the clerk. For example, the customer operates the user terminal 300 so as to cancel the confirmation-required product from the purchased product. For example, the customer performs a procedure for making the product requiring confirmation available for purchase. For example, the customer performs an operation on the user terminal 300 to register the product as a purchased product by reading a barcode representing the product code of the unregistered product. For example, the clerk performs an operation for registering an unregistered product as a purchased product by a special operation for the clerk on the user terminal 300 or an operation on the terminal for the clerk. For example, a clerk collects unregistered products. In this case, if necessary, the clerk takes measures to register the product code of the product in the product database.

As the ACT 143, the processor 301 confirms whether or not the barcode has been read. At this time, the processor 301 analyzes the image obtained by the camera 305 and tries to read the barcode. The reading of the barcode may be performed as a process based on the smartphone POS application AP301, or may be performed as a process based on another application program for reading the barcode. Then, if the bar code cannot be read, the processor 301 determines NO and proceeds to ACT 144.
As ACT 144, processor 301 confirms whether a return has been specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to ACT143.
Thus, the processor 301 waits for the ACT 143 and ACT 144 to read the barcode or specify the return.

If the return is specified as described above, the processor 301 determines YES in the ACT 144 and proceeds to the ACT 145. If the return is specified as described above in the state where the confirmation screen SC4 is displayed on the touch panel 304, the processor 301 determines YES in the ACT 141 and proceeds to the ACT 145.
As the ACT 145, the processor 301 requests the mobile controller 3 to return to the product registration. Then, the processor 301 returns to the ACT 112 in FIG.

Now, the processor 31 in the mobile controller 3 instructs the display of the confirmation screen by the ACT 237 in FIG. 17, and then proceeds to the ACT 238.
As ACT238, the processor 31 confirms whether or not the release is requested. Then, if the request cannot be confirmed, the processor 31 determines NO and proceeds to ACT239.
As ACT239, processor 31 confirms whether a return is requested. Then, if the request cannot be confirmed, the processor 31 determines NO and returns to ACT238.
Thus, the processor 31 waits for the ACT 238 and ACT 239 to be requested to be released or returned. Then, when the user terminal 300 requests the return to the product registration as described above, the processor 31 determines YES in the ACT 239, and returns to the standby state of the ACT 205 to ACT 209 in FIG.
That is, both the mobile controller 3 and the user terminal 300 return to the state of performing product registration.

On the other hand, in the user terminal 300, when the barcode is reflected in the image captured by the camera 305, the processor 301 determines YES in the ACT 143 in FIG. 12, and proceeds to the ACT 146.
As the 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.

As the ACT 147, the processor 301 requests the mobile controller 3 to release the confirmation required state. The request data transmitted by the processor 301 includes the above-mentioned stored barcode data. Further, the processor 301 includes the authentication data included in the check-in data stored in the ACT 107 in FIG. 9 in the request data transmitted here.

When the release is requested from the user terminal 300 to the mobile controller 3 in this way, the processor 31 determines YES in the ACT 238 in FIG. 17 in the mobile controller 3 and proceeds to the ACT 240.
As the ACT 240, the processor 31 performs an authentication process. The processor 31 takes out the barcode data and the authentication data from the request data, and stores them in the main memory 32 or the auxiliary storage unit 33, for example. When the processor 31 executes information processing based on the smartphone POS application AP301 in this way, the computer having the processor 31 as a central portion functions as an acquisition means. Then, the processor 31 is a process of confirming whether the read barcode is a legitimate barcode for cancellation based on the barcode data and the authentication data acquired in this way. This authentication process can be performed by any of the following, for example.

(1) When the barcode data and the authentication data match, the processor 31 determines that the normal barcode for cancellation has been read.
(2) The processor 31 processes the barcode data by a predetermined algorithm, and when the data obtained as a result and the authentication data match, it is determined that the normal barcode for cancellation has been read.
(3) The processor 31 processes the authentication data by a predetermined algorithm, and when the data obtained as a result and the barcode data match, it is determined that the normal barcode for cancellation has been read.
(4) The processor 31 processes the barcode data by the predetermined first algorithm, and processes the authentication data by the predetermined second algorithm. Then, when the two data obtained as a result of this match each other, it is determined that the normal barcode for cancellation has been read.
In addition, any process for confirming that the barcode data and the authentication data have a predetermined relationship can be applied. Then, when it is confirmed that the barcode data and the authentication data have a predetermined relationship, the processor may determine that the normal barcode for cancellation has been read.

As ACT241, the processor 31 confirms whether or not the authentication is successful. Then, if the authentication fails, the processor 31 determines NO and proceeds to ACT 242.
As the ACT 242, the processor 31 instructs the user terminal 300 to display a warning screen. After that, the processor 31 returns to the standby state of ACT 238 and ACT 239.

The processor 301 at the user terminal 300 requests cancellation at ACT 147 in FIG. 12, and then proceeds to ACT 148.
As ACT148, the processor 301 confirms whether or not the display of the warning screen is instructed. Then, if the corresponding instruction cannot be confirmed, the processor 301 determines NO and proceeds to ACT149.
As ACT149, the processor 301 confirms whether or not the display of the accounting screen is instructed. Then, if the corresponding instruction cannot be confirmed, the processor 301 determines NO and returns to ACT148.
Thus, the processor 301 waits for the ACT 148 and ACT 149 to be instructed to display the warning screen or the accounting screen. Then, if the mobile controller 3 instructs the display of the warning screen as described above, the processor 301 determines YES in the ACT 148 and proceeds to the ACT 150.

As the ACT 150, the processor 301 displays a warning screen on the touch panel 304. The warning screen is a screen for warning the clerk that the release barcode read by the clerk is incorrect.

FIG. 25 is a diagram showing an example of the warning screen SC6.
The warning screen SC6 is a screen in which the window WI61 is superimposed on the release screen SC5 displayed immediately before. The window WI61 includes a message ME61 and a button BU61. The message ME61 is a character message indicating that the read barcode is incorrect. The button BU61 is a soft key for the clerk to declare that the notification on the warning screen SC6 has been confirmed.
When the processor 301 is instructed to cancel the display of the warning screen SC6 by a predetermined operation such as touching the button BU61 displayed in the warning screen SC6, the processor 301 returns to the ACT 142.

If the processor 31 in the mobile controller 3 succeeds in the authentication as a result of the authentication process in the ACT 240 in FIG. 17, the processor 31 determines YES in the ACT 241 and proceeds to the ACT 243. If the confirmation flag is "0", the processor 31 determines NO in the ACT 236 and proceeds to the ACT 243.
As the ACT 243, the processor 31 instructs the user terminal 300 to display the accounting screen. After that, the processor 31 starts the process described below for settling the price of the product registered as the 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 when the acquired barcode data is the release data as the data having a predetermined relationship with the authentication data. Thus, when the processor 31 executes information processing based on the smartphone POS application AP301 , the computer having the processor 31 as a central portion functions as a control means.

When the processor 31 determines NO in the ACT 236 and proceeds to the ACT 243, the ACT 237 is passed, so that the user terminal 300 is not instructed to display the confirmation screen. Therefore, when the processor 31 instructs the display of the accounting screen on the ACT 243, the processor 301 is in the standby state of the ACT 137 and the ACT 138 in FIG. 10 on the user terminal 300. Therefore, the processor 301 determines YES in the ACT 138 in response to the display instruction on the accounting screen, and proceeds to the ACT 151 in FIG.

Further, when the processor 31 determines YES in the ACT 241 and proceeds to the ACT 243, when the processor 31 instructs the display of the accounting screen in the ACT 243, the processor 301 in the user terminal 300 uses the ACT 148 and the ACT 149 in FIG. Is in the standby state. Therefore, the processor 301 determines YES in the ACT 149 in response to the display instruction on the accounting screen, and proceeds to the ACT 151 in FIG.
As the ACT 151, the processor 301 displays the accounting screen on the touch panel 304. The accounting screen is a screen for the customer to select whether to perform the operation for payment of the price on the user terminal 300 or the accounting machine 5.

FIG. 26 is a diagram showing an example of the accounting screen SC7.
The accounting screen SC7 includes a display area AR71, a message ME71, and buttons BU71 and BU72. The display area AR71 represents the total number of purchased products and the total price of the purchased products. The message ME71 is a character message prompting the customer to specify whether to perform the operation for payment of the price on the user terminal 300 or the accounting machine 5. The button BU71 is a soft key for the customer to specify the user terminal 300. The button BU 72 is a soft key for the customer to specify the accounting machine 5.

When the customer wants to perform an operation for payment of the price on the user terminal 300, the customer designates the user terminal 300 by a predetermined operation such as touching the button BU71. Further, when the customer wants to perform the operation for settlement of the price on the accounting machine 5, the customer designates the accounting machine 5 by a predetermined operation such as touching the button BU72.

As the ACT 152, the processor 301 confirms whether or not the user terminal 300 has been designated. Then, if the designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT153.
The processor 301 confirms whether or not the accounting machine 5 is designated as the ACT 153. Then, if the designation cannot be confirmed, the processor 301 determines NO and returns to the ACT 152.
Thus, the processor 301 waits for the user terminal 300 or the accounting machine 5 to be designated as the ACT 152 and the ACT 153. Then, if the user terminal 300 is designated as described above, the processor 301 determines YES in the ACT 152 and proceeds to the ACT 154.

As the ACT 154, the processor 301 requests the mobile controller 3 to make a payment. The processor 301 includes payment data such as a credit number or a user code for an online payment service, which is necessary for payment, in the request data for requesting payment.

Further, if the accounting machine 5 is designated as described above, the processor 301 determines YES in the ACT 153 and proceeds to the ACT 155.
As the ACT 155, the processor 301 displays the accounting barcode screen on the touch panel 304. The accounting barcode screen is a screen showing an accounting barcode representing data required for the accounting machine 5 to acquire data related to the contents of a transaction from the virtual POS server 2. Although detailed processing is not shown, the processor 301 acquires an accounting barcode from the virtual POS server 2 via the mobile controller 3 and displays the accounting barcode on the accounting barcode screen.

The customer causes a scanner provided in the accounting machine 5 that is not used by another customer to read the accounting barcode. In response to this, the accounting machine 5 acquires data on the contents of the transaction from the virtual POS server 2 according to the data represented by the accounting barcode, and executes a process for settling the settlement amount calculated based on this data. Then, when the settlement is completed, the accounting machine 5 notifies the virtual POS server 2 to that effect. When the accounting machine 5 notifies the completion of payment, the processor 21 notifies the mobile controller 3 of the completion of payment on the virtual POS server 2. The completion of payment on the accounting machine 5 may be notified directly from the accounting machine 5 to the mobile controller 3. Thus, the accounting machine 5 is an example of a payment means.

The processor 31 in the mobile controller 3 instructs the display of the accounting screen by the ACT 243 in FIG. 17, and then proceeds to the ACT 244.
As the ACT 244, the processor 31 confirms whether or not payment has been requested. Then, if the request cannot be confirmed, the processor 31 determines NO and proceeds to ACT245.
As ACT245, the processor 31 confirms whether or not the payment completion has been notified. Then, if the notification cannot be confirmed, the processor 31 determines NO and returns to ACT244.
Thus, the processor 31 waits for the settlement request or the settlement completion notification as the ACT 244 and the ACT 245. Then, if the user terminal 300 requests payment as described above, the processor 31 determines YES in the ACT 244 and proceeds to the ACT 246.

As the ACT 246, the processor 31 transfers the settlement request to the virtual POS server 2 with the notification of the transaction code of the transaction to be 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 it is, or may transmit the converted request data by some processing to the virtual POS server 2.

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 by the input device provided in the existing POS terminal, and considers the request to be a payment instruction input by the existing POS terminal. By the same process as above, the price related to the transaction identified by the notified transaction code is calculated, and the process for settlement based on the settlement data is performed. The process for settlement includes, for example, a settlement request to a settlement server (not shown). Then, the processor 21 transmits the result data indicating that the payment is completed to the mobile controller 3. Thus, when the processor 21 executes information processing based on the virtual POS application AP21, the computer having the processor 21 as a central part functions as a payment means.

The processor 31 in the mobile controller 3 transfers the payment request in the ACT 246, and then proceeds to the ACT 247.
As ACT247, the processor 31 waits for the virtual POS server 2 to notify the completion of payment. Then, the processor 31 determines YES if the result data indicating that the settlement is completed, which is transmitted by the virtual POS server 2 as described above, is received by the communication interface 34, and proceeds to ACT 248. Further, if the processor 31 is notified of the completion of the settlement by the accounting machine 5 as described above, the processor 31 determines YES in the ACT 245 and proceeds to the ACT 248.
As ACT248, the processor 31 notifies the user terminal 300 of the completion of payment.

At the user terminal 300, the processor 301 requests the mobile controller 3 to make a payment at the ACT 154 in the ACT 14, or displays the accounting barcode screen at the ACT 155, and then proceeds to the ACT 156.
As ACT156, processor 301 waits for notification of payment completion. Then, the processor 301 determines YES when the payment completion is notified from the mobile controller 3 as described above, and proceeds to ACT157.
As ACT157, the processor 301 displays the completion screen on the touch panel 304. The completion screen is a screen for notifying the customer that the payment has been completed.

After confirming the completion screen, the customer declares that the confirmation has been made by a predetermined operation such as touching a button displayed on the completion screen. In response, processor 301 proceeds to ACT 158. The processor 301 may proceed to the ACT 158 when the elapsed time in the state where the completion screen is displayed reaches a predetermined time.

As the ACT 158, the processor 301 causes the touch panel 304 to display a scan screen for checkout. The checkout scan screen is a screen for reading the checkout two-dimensional code TC2. For example, the processor 301 activates the camera 305, and the image obtained by the camera 305 shows a character message prompting the customer to read the two-dimensional code TC2 and a guideline of the position where the two-dimensional code TC2 should be held. Generate a scan screen by overlapping the lines.

When the scan screen for checkout is displayed on the touch panel 304, the customer points the camera 305 at the two-dimensional code TC2 so that the two-dimensional code TC2 posted near the exit of the store is reflected on the scan screen.

As the ACT 159, the processor 301 waits for the two-dimensional code to be read. At this time, the processor 301 repeatedly analyzes the image obtained by the camera 305 and attempts to read the two-dimensional code. The reading of the two-dimensional code may be performed as a process based on the smartphone POS application AP301, or may be performed as a process based on another application program for reading the two-dimensional code. Then, if the two-dimensional code is read, the processor 301 determines YES and proceeds to the ACT 160.

As the ACT 160, the processor 301 confirms whether or not the data represented by the read two-dimensional code is the checkout data. Then, the processor 301 determines NO if it is not the checkout data, and returns to ACT159. At this time, the processor 301 may display a screen on the touch panel 304 notifying the customer that the erroneous two-dimensional code has been read.

If the processor 301 can confirm that the data represented by the read two-dimensional code is the checkout data, the processor 301 determines YES in the ACT 160 and proceeds to the ACT 161.
As ACT161, processor 301 requests mobile controller 3 to check out.

The processor 31 in the mobile controller 3 notifies the completion of payment by ACT248 in FIG. 17, and then proceeds to ACT249.
As an ACT 249, the processor 31 waits for a checkout request. Then, the processor 31 determines YES if the checkout is requested from the user terminal 300 as described above, and proceeds to the ACT 250.

As the ACT 250, the processor 31 executes a checkout process. The checkout process is a process such as clearing the data stored in the main memory 32 and the auxiliary storage unit 33 for managing the transaction to be processed. The virtual POS server 2 may end the processing related to the corresponding transaction when the settlement is completed, or may end the processing related to the transaction according to the instruction from the mobile controller 3. In the latter case, the processor 31 gives the above instruction to the virtual POS server 2 in the checkout process. In addition, a history database representing the history of user operations including erroneous barcode scanning may be managed by a store server 1, a virtual POS server 2, a mobile controller 3, or another server (not shown). In this case, in the checkout process, the processor 31 performs a process for updating the history database so as to reflect the history of operations related to the current transaction.
As ACT251, the processor 31 notifies the user terminal 300 of the completion of the checkout. Then, the processor 31 ends the information processing shown in FIGS. 14 to 17.

After requesting checkout at ACT161 in FIG. 13, the processor 301 at the user terminal 300 proceeds to ACT162.
As ACT162, processor 301 awaits notification of checkout completion. Then, the processor 301 determines YES when the checkout completion is notified from the mobile controller 3 as described above, and proceeds to ACT163.
As the ACT 163, the processor 301 clears various data temporarily used for this shopping, such as the check-in data saved in the ACT 107 in FIG. Then, the processor 301 returns to the ACT 101 in FIG.

As described above, according to the transaction processing system of the present embodiment, the user terminal 300 does not proceed to the processing for accounting in the confirmation required state. In other words, if there is a product that the customer tried to register as a purchased product but could not be registered correctly, the processing for accounting will not proceed. This makes it possible to prevent such goods from being taken out without being settled.

Then, when the user terminal 300 reads the legitimate barcode for cancellation, the user terminal 300 proceeds to the accounting process under the authentication by the mobile controller 3. In this way, the confirmation by the clerk can be completed on the user terminal 300, and the accounting can be completed without using the accounting corner where the clerk is assigned.

Further, according to the transaction processing system of the present embodiment, the clerk only needs to have the user terminal 300 read the bar code for cancellation in order to cancel the confirmation required state, so that the work for that is a heavy burden on the clerk. It doesn't become.

Further, according to the transaction processing system of the present embodiment, the clerk may perform an operation on the user terminal 300 in order to cancel the confirmation required state. For this reason, the customer may stop the clerk who is patrolling the store and request the cancellation of the confirmation required state, or go to the service counter or the like and request the clerk resident there to cancel the confirmation required state. You can also do it. That is, it is possible to increase the flexibility of canceling the confirmation-required state by giving a barcode for cancellation to a plurality of clerk in different locations. However, what kind of clerk is given the barcode for cancellation depends on the circumstances of each store or each business operator. In other words, it is possible to change in what form the cancellation is permitted depending on the circumstances of the store or the business operator, depending on which store clerk is given the barcode for cancellation.

Further, according to the transaction processing system of the present embodiment, the authentication process is performed based on the request data included in the check-in data. Therefore, it is easy to make the bar code for cancellation different for each store or each business operator.

This embodiment can be modified in various ways as follows.
The data for canceling the confirmation required state can be obtained by any other method such as acquiring the specified data by a manual input operation or acquiring the data electronically recorded on the recording medium by proximity wireless communication. May be obtained.

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

The clerk may confirm the payment at the time of accounting by the accounting machine, and the payment at the accounting machine may proceed without the confirmation of the clerk at the user terminal.

When the regular cancellation bar code is read at an arbitrary timing before the customer finishes the product registration, the confirmation required flag may be set to "0" to cancel the confirmation required state. In this way, when the customer sees a clerk while looking around the store, he / she can request the clerk to cancel the confirmation required state. However, in this case, if the confirmation-required product is registered as a purchased product after the confirmation-required state is canceled, the confirmation-required flag is set to "1" and the confirmation-required state is set, so that the confirmation-required state needs to be canceled again.

Only the state where there is a product that could not be registered as a purchased product may be the state requiring confirmation.

The function of the virtual POS server 2 and the function of the mobile controller 3 may be realized by one server.

The user terminal 300 may be a so-called cart terminal attached to a shopping cart installed in the store. That is, the transaction processing system may be realized as a cart POS system. Alternatively, as the user terminal 300, a terminal carried by the user and a terminal attached to the shopping cart may coexist.

Each function realized by the processors 11,21,31,41,301 by information processing can also be realized by hardware that executes information processing that is not based on a program such as a logic circuit in part or all of it. be. Further, each of the above-mentioned functions can be realized by combining software control with the above-mentioned hardware such as a logic circuit.

Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other embodiments, and various omissions, replacements, and changes can be made without departing from the gist of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are also included in the scope of the invention described in the claims and the equivalent scope thereof.
The inventions described in the original claims of the present application are described below.
[Appendix 1] A registration means for registering a product specified by an operation on the terminal as a product to be purchased by a customer using the terminal, and
A payment means that performs a payment process for causing the customer to settle the price of the product registered by the registration means, and a payment means.
When there is a product that could not be registered as the purchase target by the registration means, the acquisition means for acquiring the data specified by the operation on the terminal and the acquisition means.
When the data acquired by the acquisition means is predetermined release data, the control means that allows the settlement process to start the settlement process and the control means.
Transaction processing system equipped with.
[Appendix 2] When the data acquired by the acquisition means and the authentication data have a predetermined relationship, the control means determines that the data acquired by the acquisition means is the release data. do,
The transaction processing system described in Appendix 1.
[Appendix 3] The transaction processing system according to Appendix 2, wherein the control means uses authentication data acquired via the terminal when the customer enters the store.
[Appendix 4] The acquisition means acquires the barcode data represented by the barcode read by the terminal as the data.
The transaction processing system according to any one of Supplementary notes 1 to 3.
[Appendix 5] A registration means for registering a product specified by an operation on the terminal as a product to be purchased by a customer using the terminal, and a payment for the product registered by the registration means to the customer. It is used in a transaction processing system equipped with a payment means that performs payment processing to make the product.
When there is a product that could not be registered as the purchase target by the registration means, the acquisition means for acquiring the data specified by the operation on the terminal and the acquisition means.
When the data acquired by the acquisition means is predetermined release data, the control means that allows the settlement process to start the settlement process and the control means.
A transaction support device equipped with.
[Appendix 6] A registration means for registering a product specified by an operation on the terminal as a product to be purchased by a customer using the terminal, and a payment for the product registered by the registration means to the customer. A computer provided in a transaction support device used in a transaction processing system equipped with a payment means for performing payment processing for the purpose of
When there is a product that could not be registered as the purchase target by the registration means, the acquisition means for acquiring the data specified by the operation on the terminal and the acquisition means.
When the data acquired by the acquisition means is predetermined release data, the control means that allows the settlement process to start the settlement process and the control means.
An information processing program to make it work.

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 line , 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 (7)

A registration means for registering a product specified by an operation on a terminal as a product to be purchased by a customer using the terminal, and
And settlement means for performing the settlement process to settle the price of goods that have been registered as a purchase target by the registration means to the customer,
If the goods can not be registered as by Ri購input object in the registration means is, an acquisition unit configured to acquire data specified by the operation in the terminal,
When in the acquired data and relationships that the authentication data obtained through the terminal at the time of visiting the predetermined of the customer by the acquisition unit, the data obtained by the obtaining unit releases the data control means for determining, and allowing starting of by that settlement processing on the payment means and is,
Transaction processing system equipped with. The acquisition unit is a bar code data bar code read by the terminal represented, acquired as data specified by the operation in the terminal,
The transaction processing system according to claim 1. A registration means for registering a product specified 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 for causing the customer to settle the price of a product registered as a purchase target by the registration means, and a payment means.
When there is a product that could not be registered as a purchase target by the registration means, the acquisition means for acquiring the barcode data represented by the barcode read by the terminal, and the acquisition means.
When the barcode data acquired by the acquisition means is predetermined release data, the control means for allowing the payment means to start the payment process and the control means.
Transaction processing system equipped with. Products that have been designated by an operation at the terminal, to the settlement and registration means for registering as a product of the purchased by customers who are using the terminal, the price of the registered goods as purchased by the registration means to the customer Used in transaction processing systems equipped with a payment method that performs payment processing for
If the goods can not be registered as by Ri購input object in the registration means is, an acquisition unit configured to acquire data specified by the operation in the terminal,
When in the acquired data and relationships that the authentication data obtained through the terminal at the time of visiting the predetermined of the customer by the acquisition unit, the data obtained by the obtaining unit releases the data control means for determining, and allowing starting of by that settlement processing on the payment means and is,
A transaction support device equipped with. A registration means for registering a product specified by an operation on a terminal as a product to be purchased by a customer using the terminal, and for having the customer settle the price of the product registered as a purchase target by the registration means. It is used in a transaction processing system equipped with a payment method for processing payments.
When there is a product that could not be registered as a purchase target by the registration means, the acquisition means for acquiring the barcode data represented by the barcode read by the terminal, and the acquisition means.
When the barcode data acquired by the acquisition means is predetermined release data, the control means for allowing the payment means to start the payment process and the control means.
A transaction support device equipped with. Products that have been designated by an operation at the terminal, to the settlement and registration means for registering as a product of the purchased by customers who are using the terminal, the price of the registered goods as purchased by the registration means to the customer A computer provided in a transaction support device used in a transaction processing system equipped with a payment means for performing payment processing for
If the goods can not be registered as by Ri購input object in the registration means is, an acquisition unit configured to acquire data specified by the operation in the terminal,
When in the acquired data and relationships that the authentication data obtained through the terminal at the time of visiting the predetermined of the customer by the acquisition unit, the data obtained by the obtaining unit releases the data control means for determining, and allowing starting of by that settlement processing on the payment means and is,
An information processing program to make it work. A registration means for registering a product specified by an operation on a terminal as a product to be purchased by a customer using the terminal, and for having the customer settle the price of the product registered as a purchase target by the registration means. A computer provided in a transaction support device used in a transaction processing system equipped with a payment means for processing the payment of
When there is a product that could not be registered as a purchase target by the registration means, the acquisition means for acquiring the barcode data represented by the barcode read by the terminal, and the acquisition means.
When the barcode data acquired by the acquisition means is predetermined release data, the control means for allowing the payment means to start the payment process and the control means.
An information processing program to make it work.

Images