JP7368573B2 - Transaction processing system, control device and information processing program - Google Patents

Description

Embodiments of the present invention relate to a transaction processing system, a control device, and an information processing program.

2. Description of the Related Art Transaction processing systems have been proposed in which purchased products are registered in response to operations by a customer on a terminal device such as a cart terminal attached to a shopping cart or a mobile information communication terminal owned by the customer.
In such a transaction processing system, the number of terminal devices used at the same time varies depending on the number of customers shopping in the store. Furthermore, in such a transaction processing system, the number of terminal devices that can be used simultaneously is limited due to resource limitations on the store side. Therefore, during times of congestion, a situation may arise in which it is not possible to start using a new terminal device.
It is desirable to reduce the possibility that such a situation will occur.

JP 2019-153089 Publication

The problem to be solved by the present invention is to provide a transaction processing system that can reduce the possibility of a situation in which the use of a new terminal device cannot be started.

The transaction processing system of the embodiment includes an operating means, a determining means, a detecting means, a controlling means, a reporting means , and a guiding means . The operating means is provided in the terminal device and is operated by an operator. The determining means is provided in one of the information processing devices and performs processing for determining the content of a transaction in accordance with an operation received by the operating means. The detection means is provided in one of the terminal device or the information processing device, and detects a non-operation state in which the operation means cannot be operated for a predetermined time limit . The control means is provided in one of the terminal device or the information processing device, and during the period from when the determining means starts processing for determining the contents of one transaction until the determination of the contents of the one transaction is completed, In response to the detection of the no-operation state by the detection means, the determination means is controlled to end the processing related to the one transaction. The reporting means is provided in one of the information processing devices, and notifies a predetermined reporting destination that the determining means has terminated the processing without completing it. The guide means is provided in one of the information processing devices, and when the operation means cannot be operated for a predetermined time shorter than the time limit, the guide means is provided in one of the information processing devices. Inform the operator that the process will be terminated.

1 is a block diagram showing a schematic configuration of a transaction processing system according to an embodiment. FIG. 2 is a block diagram showing the main circuit configuration of the store server in FIG. 1. FIG. FIG. 2 is a block diagram showing the main circuit configuration of the virtual POS server in FIG. 1. FIG. FIG. 2 is a block diagram showing the main circuit configuration of the mobile controller in FIG. 1. FIG. 5 is a schematic diagram showing the main data structure of data records included in the transaction management database shown in FIG. 4. FIG. 5 is a schematic diagram showing the main data structure of data records included in the registration database shown in FIG. 4. FIG. FIG. 2 is a block diagram showing the main circuit configuration of the user terminal in FIG. 1. FIG. FIG. 2 is a block diagram showing the main circuit configuration of the cart terminal in FIG. 1. FIG. Flowchart of smartphone UI processing. Flowchart of smartphone UI processing. Flowchart of smartphone UI processing. Flowchart of smartphone UI processing. Flowchart of cart UI processing. Flowchart of management actions. Flowchart of mediation processing. Flowchart of mediation processing. Flowchart of mediation processing. Flowchart of transaction processing. Flowchart of transaction processing. The figure which shows an example of a list screen. The figure which shows an example of a registration screen. The figure which shows an example of a list screen. The figure which shows an example of a checkout screen.

An embodiment of the transaction processing system will be described below with reference to the drawings.
The transaction processing system in this embodiment processes product transactions in a store that sells products displayed in the store to visiting customers.

FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system according to this embodiment.
The transaction processing system includes a plurality of store systems 100, a relay server 200, a user terminal 300, a cart terminal 400, a payment server 500, an electronic receipt server 600, and a communication network 700. The plurality of store systems 100 , relay server 200 , user terminal 300 , payment server 500 , and electronic receipt server 600 are enabled to communicate via communication network 700 .

In FIG. 1, two store systems 100 are shown. These store systems 100 are provided at different stores A and B that use transaction processing systems. There may be three or more stores using the transaction processing system, and a store system 100 is provided for each store. In the following, when it is necessary to distinguish between the store systems 100 installed at each store, the store system 100 installed at store A will be referred to as store system 100A, and the store system 100 installed at store B will be referred to as store system 100A. It is expressed as system 100B.
The business operator that operates store A may be the same as the business operator that operates store B, or may be different. Even when the transaction processing system is used at another store, the business operator that operates that store may be the same as the business operator that operates store A or store B, or may be different.

Relay server 200 relays data communication between user terminal 300 and store system 100. For example, the relay server 200 provides a data communication relay function as a cloud service via the communication network 700.

The user terminal 300 is a terminal device that functions as a user interface for customers who shop at a store using the transaction processing system. 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 700. As the user terminal 300, a communication terminal with a data communication function, such as a smartphone or a tablet terminal, can be used. User terminal 300 is owned by a customer. In other words, the user terminal 300 is an example of a terminal device brought into a store by a customer.

Cart terminal 400 is a terminal device that functions as a user interface for customers who shop at a store using the transaction processing system. The cart terminal 400 has a function of wirelessly communicating with the store system 100. The cart terminal 400 is attached to the shopping cart C1 and installed in the store. Cart terminal 400 is used by a customer at a store. In other words, the cart terminal 400 is an example of a terminal device lent to a customer by a store.

Payment server 500 performs payment processing for online payment in response to payment requests via communication network 700 . The payment server 500 may be compatible with only one of multiple payment methods such as credit card payment and electronic money payment, or may be compatible with multiple payment methods. . As the payment server 500, for example, an existing payment server operated by a payment agency that supports multiple payment services including multiple payment methods can be used.

The electronic receipt server 600 provides a receipt representing a transaction result as an image or a web page. As the electronic receipt server 600, for example, an existing electronic receipt server that provides electronic receipt services can be applied.

As the communication network 700, for example, the Internet, a VPN (virtual private network), a LAN (local area network), a public communication network, a mobile communication network, etc. can be used alone or in an appropriate combination. Typically, the communication network 700 is a mobile communication network, the Internet, or a VPN.

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

The store server 1 is an information processing device for comprehensively managing a plurality of transactions processed by the transaction processing system. For example, the store server 1 has functions similar to those of an existing POS server.
The virtual POS server 2 is an information processing device that performs information processing (hereinafter referred to as transaction processing) for registering purchased products for each transaction and settling the price of the purchased products in response to external requests. The virtual POS server 2 virtually implements the functions of existing POS terminals. The information processing performed by the virtual POS server 2 is customized to adapt to differences in management policies of each store. That is, for example, the transaction processing performed by the store server 1 provided in the store system 100A and the transaction processing performed by the store server 1 provided in the store system 100B may be partially different.

The mobile controller 3 is an information processing device that performs management processing and mediation processing. The management process is information processing for managing the above transaction process executed by the virtual POS server 2. The intermediary process is performed by connecting the virtual POS server 2 and the user terminal 300 or the cart terminal 400 in order to perform the above transaction process executed by the virtual POS server 2 while using the user terminal 300 or the cart terminal 400 as a user interface device. This is information processing for mediation.
The communication server 4 performs communication processing for the store server 1 , virtual POS server 2 , mobile controller 3 , and accounting machine 5 to exchange data with the relay server 200 and the like via the communication network 700 .

The accounting machine 5 performs processing for obtaining the payment for purchased products for each transaction managed by the virtual POS server 2 and having the customer settle the payment. Payment methods that can be used by the accounting machine 5 for the above-mentioned payments include well-known payment methods such as cash payment, credit card payment, electronic money payment, point payment, and code payment (also referred to as mobile payment or smartphone payment, etc.). It may be all or any part of the payment method. The checkout machine 5 may be operated by either a clerk or a customer. As the accounting machine 5, for example, a self-service accounting machine used in an existing semi-self-operated 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 to enable the user terminal 300 and the cart terminal 400 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 and the cart terminal 400 can communicate wirelessly from anywhere on the sales floor of the store. Depending on the size of the store, multiple access points 6 may be arranged in one store system 100.
As the in-store communication network 7, the Internet, VPN, LAN, public communication network, mobile communication network, etc. can be used alone or in an appropriate combination. However, typically the in-store communication network 7 is a LAN.

In a store where the store system 100 is installed, a two-dimensional code TC1 for check-in is posted near the entrance, and a two-dimensional code TC2 for check-out is posted near the exit. The two-dimensional code TC1 represents check-in data for check-in. Two-dimensional code TC2 represents checkout data for checkout. Check-in data and check-out data differ from store to store. Therefore, if 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, store A is expressed as two-dimensional codes TC1A and TC2A, and store B is expressed as two-dimensional codes TC1A and TC2A. The usage is expressed as two-dimensional codes TC1B and TC2B.

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

(4) Name of the business operator that operates the store where the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TC1A represents the name of the business operator that operates store A. The check-in data represented by the two-dimensional code TC1B represents the name of the business operator that operates store B. (5) Name of the store where the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TC1A represents the name of store A. The check-in data represented by the two-dimensional code TC1B represents the name of store B.
(6) Flag for distinguishing between two-dimensional code TC1 and 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 communication server 4. For example, the check-in data represented by the two-dimensional code TC1A represents the IP address of the communication server 4 included in the store system 100A. The check-in data represented by the two-dimensional code TC1B represents the IP address of the communication server 4 included in the store system 100B.
(8) Domain name of relay server 200. The domain name is common to all two-dimensional codes TC1. However, a plurality of relay servers 200 with different domain names may be used for each store. In this case, the check-in data represented by the two-dimensional code TC1 represents the domain name of the relay server 200 used at the corresponding store.
(9) Address of electronic receipt server 600. The address may be common to all two-dimensional codes TC1, or one of a plurality of addresses may be expressed 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 700 to exchange data with the store system 100. For example, in store A, if wireless communication with access point 6 is used to exchange data between store system 100A and user terminal 300, the flag is set to "1", for example. For example, in store B, if wireless communication with communication network 700 is used to exchange data between store system 100B and user terminal 300, the flag is set to "0", for example.
(11) SSID (service set identifier) for identifying the access point 6. For example, the check-in data represented by the two-dimensional code TC1A represents the SSID that identifies the access point 6 included in the store system 100A. The check-in data represented by the two-dimensional code TC1B represents the SSID of the access point 6 included in the store system 100B.
(12) Password for accessing access point 6. For example, the check-in data represented by the two-dimensional code TC1A represents the 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 the 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 a security method, the check-in data represented by the two-dimensional code TC1A represents "1" as the identification number. For example, if the access point 6 included in the store system 100B uses the WPA-PSK method as a 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 to cause an error when the user terminal 300 fails to connect to the relay server 200 or to continue operation without causing an error. For example, in 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 will represent "1" as the flag. . For example, in store B, if the user terminal 300 is set to continue operating even if the connection with the relay server 200 fails, the check-in data represented by the two-dimensional code TC1B will have "0" as the flag, for example. represent.

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

(16) Identification number of the transmission mode regarding the log file in which log data of the user terminal 300 is accumulated. The transmission modes include, 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 sent only to the relay server 200. In the second mode, the log file is sent only to the store system 100. In the third mode, the log file is sent to both store system 100 and relay server 200. In the fourth mode, no log file is sent. For example, in store A, if the first mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1A represents "1" as the identification number. For example, in store B, if the second mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TC1B represents "2" as the identification number.

(17) A host name or IP address used when transmitting the log file to the relay server 200 via the communication network 700 using FTP (file transfer protocol).
(18) User name used when transmitting the log file via FTP to the relay server 200 via the communication network 700.
(19) Password used when transmitting the log file via FTP to the relay server 200 via the communication network 700.
(20) Path name of the log file sent via FTP to the relay server 200 via the communication network 700.

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

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

(27) Authentication data used in authentication processing to authenticate a declaration of completion of confirmation regarding transactions involving products that require confirmation by a store clerk. The check-in data represented by the two-dimensional code TC1A represents authentication data set in advance for store A. The check-in data represented by the two-dimensional code TC1B represents authentication data set in advance for store B. It is preferable that the authentication data be set differently for each store, but the same authentication data may be set for different stores.
(28) Data for identifying the 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". Further, for example, if the store system 100B is set to a demo mode in which the transaction processing system is operated as a demonstration, the check-in data represented by the two-dimensional code TC1B represents "2", for example.
(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 that requests data transfer from the checkout machine 5 to the mobile controller 3, the check-in data represented by the two-dimensional code TC1A represents "1", for example. For example, if the store system 100B is set to a mode in which data is transferred from the mobile controller 3 to the checkout machine 5 without a request from the checkout machine 5, the check-in data represented by the two-dimensional code TC1B is For example, it represents "2".

(30) A flag indicating whether or not payment using the code payment method by operation on the user terminal 300 is permitted. For example, if the code payment is allowed at store A, the check-in data represented by the two-dimensional code TC1A represents "1" as the flag. Further, for example, if store B does not allow the code payment, 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 registration of an age-restricted product for which purchaser age restrictions are specified on the user terminal 300 is permitted. For example, if store A allows registration of age-restricted products on the user terminal 300, the check-in data represented by the two-dimensional code TC1A represents "1" as the flag. Further, for example, if store B does not allow the code payment, 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 a point member's membership code. For example, if the store system 100A is set to a mode in which the membership code is manually input, the check-in data represented by the two-dimensional code TC1A represents, for example, "1". For example, if the store system 100B is set to a mode in which a membership code is input by reading a barcode, the check-in data represented by the two-dimensional code TC1B represents, for example, "2".

(33) A flag for identifying whether or not confirmation from a store clerk is required when entering a member code when the mode for manually entering the member code of a point member is set. For example, if store A requires the confirmation, the check-in data represented by the two-dimensional code TC1A represents "1" as the flag, for example. For example, if store B does not require this confirmation, the check-in data represented by the two-dimensional code TC1B will represent, for example, "0" as the flag.
(34) 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 business operator. For example, if the business operator of 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, if 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 are examples of information represented by check-in data. However, the check-in data does not need to include some of the various types of 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 the main circuit configuration of the store server 1.
The store server 1 includes a processor 11 , a main memory 12 , an auxiliary storage unit 13 , a communication interface 14 , and a transmission line 15 . The processor 11, main memory 12, auxiliary storage unit 13, and communication interface 14 are capable of communicating via a transmission path 15. A computer for controlling the store server 1 is configured by connecting the processor 11, main memory 12, and auxiliary storage unit 13 through a transmission path 15.

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

The main memory 12 corresponds to the main memory portion of the computer. Main memory 12 includes a nonvolatile memory area and a volatile memory area. The main memory 12 stores the above information processing program in a nonvolatile memory area. The main memory 12 may store data necessary for the processor 11 to perform information processing in a nonvolatile 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 nonvolatile memory area is, for example, 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, a storage unit using a well-known storage device such as an EEPROM (electric erasable programmable read-only memory), an HDD (hard disc drive), or an SSD (solid state drive) can be used. The auxiliary storage unit 13 stores data used by the processor 11 in performing various processes, data created by processing by the processor 11, and the like. The auxiliary storage unit 13 may also store the above information processing program.

The communication interface 14 performs data communication with each section 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, etc., and transmits data and control signals exchanged between the connected parts.

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

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

One of the databases included in the database group DB11 is a user database for managing store users. A user database is a collection of data records associated with customers who are registered as users of a store. The data records of the user database include data regarding the associated customer, such as a user code and attribute information for identifying the user. The user code is a unique identification code determined for each store user to identify each store user. Attribute information may include name, gender, age, address, telephone number, etc. The data records of the user database may also include payment information declared by the store's users. The payment information is a credit number, a code payment ID (identifier), or the like. In addition, if a plurality of payment methods can be selected, the payment information may include a payment method code for identifying the payment method. In addition, in the case of a store that provides a point service, the data record of the user database may include an identifier for identifying the user of the point service (hereinafter referred to as point ID) and the number of points held. . Further, the data record of the user database may include a user identifier (hereinafter referred to as electronic receipt ID) for identifying the user of the electronic receipt service. The various data included in the data records of the user database do not need to include substantial data about all users. For example, the user database may include only point IDs or electronic receipt IDs for which the user has applied for registration in advance.

In addition, the database group DB11 may include various databases such as those managed by a POS server in an existing POS system. Note that what kind of databases the database group DB11 includes, or what kind of data and structure these databases include may be determined for each store.

FIG. 3 is a block diagram showing the main circuit configuration of the virtual POS server 2. As shown in FIG.
The virtual POS server 2 includes a processor 21, a main memory 22, an auxiliary storage unit 23, a communication interface 24, and a transmission path 25. The processor 21, main memory 22, auxiliary storage unit 23, and communication interface 24 are capable of communicating via a transmission path 25. A computer for controlling the virtual POS server 2 is configured by connecting the processor 21, main memory 22, and auxiliary storage unit 23 through a transmission path 25. Note that the functions of the processor 21, main memory 22, auxiliary storage unit 23, communication interface 24, and transmission line 25 are roughly equivalent to those of the processor 11, main memory 12, auxiliary storage unit 13, communication interface 14, and transmission line 15. Therefore, its explanation will be omitted.

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

Further, a part of the storage area of the auxiliary storage unit 23 is used as a transaction database DB21 instead of the database group DB11. The transaction database DB21 is a collection of data records associated with transactions with customers who are shopping around in the store. The data record of the transaction database DB21 includes a transaction code and product data regarding products registered as purchased products. The transaction code is a unique identification code set for each transaction to identify each transaction. The product data represents a product code, product name, price, quantity, etc. The structure of the transaction database DB21 may be individually determined in accordance with the store management policy of each store or each business operator that operates the store.

FIG. 4 is a block diagram showing the main circuit configuration of the mobile controller 3. As shown in FIG.
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, main memory 32, auxiliary storage unit 33, and communication interface 34 are capable of communicating via a transmission path 35. A computer for controlling the mobile controller 3 is configured by connecting the processor 31, main memory 32, and auxiliary storage unit 33 through a transmission path 35. Note that the functions of the processor 31, main memory 32, auxiliary storage unit 33, communication interface 34, and transmission line 35 are roughly equivalent to those of the processor 11, main memory 12, auxiliary storage unit 13, communication interface 14, and transmission line 15. Therefore, its explanation will be omitted.

However, the auxiliary storage unit 33 stores a transaction management application AP31 instead of the store management application AP11. The transaction management application AP31 is an application program in which management processing and mediation processing are described. The transaction management application AP31 is common to each store system 100. However, various settings for information processing based on the transaction management application AP31 may be customized for each store system 100.

Further, a part of the storage area of the auxiliary storage unit 23 is used as a transaction management database DB31 and a registration database DB32 instead of the database group DB11. The structures of these transaction management database DB31 and registration database DB32 are common to each store system 100.

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

A terminal code for identifying the associated user terminal 300 or cart terminal 400 is set in the field F11. As the terminal code, for example, a unique identification code set for each communication terminal to identify each communication terminal used as the user terminal 300 or the cart terminal 400 can be used. Alternatively, as the terminal code, for example, an identification code that is set for the smartphone POS application or cart terminal application when the smartphone POS application or cart terminal application described below is installed on the user terminal 300 or the cart terminal 400 can be used. . A membership code for identifying a customer using the associated user terminal 300 or cart terminal 400 from other customers is set in the field F12. A transaction code of a transaction performed using the associated user terminal 300 or cart terminal 400 is set in the field F13. An electronic receipt ID is set in field F14 as necessary. Note that the data record DR1 may include another field in which data different from the fields F11 to F14 is set.

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

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

Data record DR2 includes fields after field F23 when registration of two or more purchased products is attempted for the associated transaction. The same registration data as field F12 is also set in the fields after field F23.

FIG. 7 is a block diagram showing the main circuit configuration of the user terminal 300.
The user terminal 300 includes a processor 301, a main memory 302, an auxiliary storage unit 303, a touch panel 304, a camera 305, a wireless communication unit 306, a mobile communication unit 307, a transmission path 308, and the like. The processor 301 , main memory 302 , auxiliary storage unit 303 , touch panel 304 , camera 305 , and mobile communication unit 307 are capable of communicating via a transmission path 308 . A computer for controlling the user terminal 300 is configured by connecting the processor 301, main memory 302, and auxiliary storage unit 303 through a transmission path 308. Note that the functions of the processor 301, main memory 302, auxiliary storage unit 303, and transmission path 308 are generally the same as those of the processor 11, main memory 12, auxiliary storage unit 13, and transmission path 15, and therefore the description thereof will be omitted.

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

The wireless communication unit 306 exchanges data with the access point 6 through wireless communication according to a 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.
Mobile communication unit 307 is an interface for data communication via communication network 700. 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.

Note that the auxiliary storage unit 303 stores a smartphone POS application AP301, which is one of the information processing programs. The smartphone POS application AP301 is an application program, and describes information processing (hereinafter referred to as smartphone UI processing) to be 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.

FIG. 8 is a block diagram showing the main circuit configuration of the cart terminal 400.
The cart terminal 400 includes a tablet computer 401, a scanner 402, a reader 403, and a camera 404.

The tablet computer 401 includes a processor 401a, a main memory 401b, an auxiliary storage unit 401c, a wireless communication unit 401d, a touch panel 401e, a sound unit 401f, an interface unit 401g, and a transmission line 401h. The processor 401a, main memory 401b, auxiliary storage unit 401c, wireless communication unit 401d, touch panel 401e, sound unit 401f, and interface unit 401g are capable of communicating via a transmission path 401h. A computer for controlling the cart terminal 400 is configured by connecting the processor 401a, main memory 401b, and auxiliary storage unit 401c via a transmission path 401h. The functions of the processor 401a, main memory 401b, auxiliary storage unit 401c, touch panel 401e, wireless communication unit 401d, and transmission line 401h are summarized as follows: processor 11, main memory 12, auxiliary storage unit 13, touch panel 304, and wireless communication unit 306. and the transmission line 15, so the explanation thereof will be omitted.

However, the auxiliary storage unit 401c stores the cart terminal application AP401 instead of the store management application AP11. The cart terminal application AP 401 is an application program, and describes information processing (hereinafter referred to as cart UI processing) to be described later for causing the cart terminal 400 to function as a user interface of the store system 100. The cart terminal application AP401 is commonly used by a plurality of cart terminals 400.

The sound unit 401f outputs various sounds such as voices and melodies.
A scanner 402, a reader 403, and a camera 404 are connected to the interface unit 401g. The interface unit 401g interfaces the scanner 402, reader 403, and camera 404 with the processor 401a to exchange data. As the interface unit 401g, an existing USB (universal serial bus) controller or the like can be used.

Scanner 402 reads code symbols such as barcodes or two-dimensional data codes. The scanner 402 is mainly used to read a code symbol shown on a product and representing a product code of the product. Scanner 402 may be used to read a code symbol shown on a membership card or displayed on a mobile device and representing a membership code or the like. Scanner 402 outputs data represented by the read code symbols. The scanner 402 may be of a type that reads code symbols by scanning with laser light, or may be of a type that reads code symbols from an image captured by an imaging device.

A reader 403 reads data recorded on a recording medium and outputs it. The reader 403 is a magnetic card reader when the recording medium is a magnetic card, and is an IC card reader when the recording medium is a contact type IC card. In the case of a recording medium that uses RFID (radio frequency identification), such as a non-contact IC card or a smartphone, an RFID reader is used as the reader 403.
The camera 404 takes a bird's-eye view of the inside of the shopping cart placed on the shopping cart C1. The camera 404 then outputs image data representing the captured image.

Now, as the hardware of the store server 1, virtual POS server 2, or mobile controller 3, for example, a general-purpose server device can be used. Generally, when transferring the store server 1, virtual POS server 2, or mobile controller 3, the store management application AP11, virtual POS application AP21, or transaction management application AP31 is stored in the auxiliary storage unit 13, 23, or 33, respectively, and the database group DB11, This is performed without storing the transaction database DB21, transaction management database DB31, and registration database DB32. However, the store management application AP11, the virtual POS application AP21, or the transaction management application AP31 is not stored in the auxiliary storage unit 13, 23, or 33, or a different version of the same application program is stored in the auxiliary storage unit 13, 23, or 33. The hardware in the current state and the store management application AP11, virtual POS application AP21, or transaction management application AP31 may be transferred separately. Then, the store management application AP11, virtual POS application AP21, or transaction management application AP31 is written in the auxiliary storage unit 13, 23, or 33 in accordance with the operation of any worker, so that the store server 1, the virtual POS server 2, or A mobile controller 3 may be configured. Transfer of the store management application AP11, virtual POS application AP21, or transaction management application AP31 is performed by recording on a removable recording medium such as a magnetic disk, magneto-optical disk, optical disk, semiconductor memory, etc., or by communication via a network. be able to. The transaction database DB21, transaction management database DB31, and registration database DB32 are stored in the auxiliary storage unit 13 by the processor 11, 21, or 31 executing information processing based on the store management application AP11, the virtual POS application AP21, or the transaction management application AP31. , 23 or 33. Note that at least part of the databases included in the store management application AP11 and the database group DB11 may be stored in the main memory 12. At least a portion of the virtual POS application AP21 and the transaction database DB21 may be stored in the main memory 22. At least a portion of the transaction management 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 above will be explained. Note that the contents of various processes described below are merely examples, and the order of some processes may be changed, some processes may be omitted, or other processes may be added as appropriate. For example, in the following description, in order to explain the characteristic operations of this embodiment in an easy-to-understand manner, descriptions of some processes are omitted. For example, when some kind of error occurs, processing may be performed to deal with the error, but some of such processing is omitted from description.

A service provided to a customer using the user terminal 300 by the operation of the transaction processing system is referred to as a smartphone POS service. Further, the service provided to the customer using the cart terminal 400 through the operation of the transaction processing system is referred to as a cart POS service.
In order to use the smartphone POS service, the user terminal 300 exchanges data with the store system 100, but whether to use wireless communication with the access point 6 or wireless communication with the communication network 700 for this purpose depends on Determined by the state of the flag included in the check-in data. However, in the following, to simplify the explanation, a case will be described in which wireless communication with the access point 6 is used. In addition, in order to have the accounting machine 5 perform the transaction, data transfer from the virtual POS server 2 to the accounting machine 5 can be performed in two modes: a mode in which the accounting machine 5 requests the mobile controller 3 to transfer data, and a mode in which data transfer is requested from the accounting machine 5 to the mobile controller 3; Which mode of data transfer from the mobile controller 3 to the accounting machine 5 is used depends on the state of the flag included in the check-in data. However, in the following description, in order to simplify the explanation, it is assumed that the mode in which data transfer is requested from the accounting machine 5 to the mobile controller 3 is used permanently.

In order to use the smartphone POS service, a customer installs the smartphone POS application AP 301 on his/her smartphone or the like so that it can be used as a 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 the store. Then, the customer enters one of the stores in which the store system 100 is installed, carrying the user terminal 300 with information processing based on the smartphone POS application AP301 activated.

If the customer wishes to check the results of transactions using the smartphone POS service using the electronic receipt service, the customer must register to use the electronic receipt service. Through this usage registration, the customer is assigned an electronic receipt ID. The customer then stores the electronic receipt ID assigned to him or herself in the user terminal 300 that he or she owns. Further, in order to manage customers, the electronic receipt ID may be stored in association with the point ID in a member database managed by the store. In this case, the customer may store the point ID assigned to him or herself in the user terminal 300 that he or she owns.

The processor 301 in the user terminal 300 acquires the electronic receipt ID or point ID through a setting process based on the smartphone POS application AP301, and stores it in the auxiliary storage unit 303 as registered data regarding the smartphone POS application AP301. For example, if the operator requests registration of an electronic receipt ID, the processor 301 causes the operator to specify a login ID and a login password for authenticating the user at the electronic receipt server 600. The processor 301 then logs into the electronic receipt server 600 using the specified login ID and login password, obtains the electronic receipt ID of the user identified by the login ID, and stores it in the auxiliary storage unit 303. . For example, the processor 301 may have the operator specify an electronic receipt ID and store the specified electronic receipt ID in the auxiliary storage unit 303. Further, for example, if the operator requests registration of a point ID, the processor 301 causes the operator to specify the point ID, and stores the specified point ID in the auxiliary storage unit 303. Note that as the point ID, a point card number given to a point card distributed to a customer or the like is used. When registration of each electronic receipt ID and point ID is requested in sequence, the processor 301 executes the above processing individually and stores both the electronic receipt ID and the point ID in the auxiliary storage unit 303. . However, the processor 301 may store only one predetermined one.

9, FIG. 10, FIG. 11, and FIG. 12 are flowcharts of smartphone UI processing executed by the processor 301 according to the smartphone POS application AP 301.
First, in ACT 101 shown in FIG. 9, the processor 301 displays a main menu screen on the touch panel 304. The main menu screen is a screen for receiving designation of one of several processes to be performed according to the smartphone POS application AP301. A plurality of GUI elements are arranged on the main menu screen, including a GUI (graphical user interface) element for specifying the start of shopping. Note that the GUI element is, for example, a soft key.

As ACT 102, the processor 301 checks whether the start of shopping has been specified. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT103.
In ACT 103, the processor 301 confirms whether 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 ACT102.
In this manner, the processor 301 waits for some designation to be made on the main menu screen as ACT102 and ACT103. If a designation other than the start of shopping is made, the processor 301 determines YES in ACT 103 and proceeds to the designated process. Note that a description of the processing of the processor 301 in this case will be omitted. The process of the processor 301 for registering the electronic receipt ID or point ID described above may be one of the processes here.

When a customer enters a store and starts shopping, he or she performs a predetermined operation on the main menu screen to designate the start of shopping. When the operation is detected, for example, on the touch panel 304, the processor 301 determines YES in ACT102, and proceeds to ACT104.
As ACT 104, the processor 301 displays a scan screen for check-in on the touch panel 304. The scan screen for check-in is a screen that prompts the customer to read the two-dimensional code TC1 for check-in. For example, the processor 301 activates the camera 305, and displays on the image obtained by the camera 305 a text message urging 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 posted near the entrance of the store so that the two-dimensional code TC1 is reflected on the scan screen.

In ACT 105, the processor 301 waits for the two-dimensional code to be read. At this time, the processor 301 repeatedly analyzes images obtained by the camera 305 and attempts to read the two-dimensional code. Reading this 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. If the two-dimensional code is read, the processor 301 determines YES and proceeds to ACT106.

In ACT 106, the processor 301 checks whether the data represented by the read two-dimensional code is check-in data. Then, the processor 301 determines NO if it is not check-in data, and returns to ACT105. At this time, the processor 301 may cause the touch panel 304 to display a screen that notifies the customer that an incorrect two-dimensional code has been read.

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

As ACT 108, processor 301 requests check-in from mobile controller 3. Specifically, processor 301 establishes wireless communication between wireless communication unit 306 and access point 6 based on the data represented in the check-in data. For example, if a customer points the camera 305 at the two-dimensional code TC1A at store A, the processor 301 connects wirelessly to the access point 6 provided in the store system 100A based on the check-in data represented by the two-dimensional code TC1A. Establish communication. Processor 301 then transmits request data for requesting check-in to mobile controller 3 via wireless communication with 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. The data is then transmitted to the mobile controller 3 provided in the store system 100A. Note that the processor 301 includes, in the request data for requesting check-in, identification data for identifying that it is a request for check-in, and a terminal code. 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. If the point ID is stored in the auxiliary storage unit 303, the processor 301 also includes the point ID in the request data. Processor 301 may include other data in the request data, such as data for authenticating the customer.

Note that various requests from the user terminal 300 to the mobile controller 3, which will be described later, are sent to the access point 6 and the in-store communication network 7 by request data including identification data for identifying the reason for the request, as described above. This is realized by sending the data from the user terminal 300 to the mobile controller 3 via the mobile controller 3.

When the cart terminal 400 is activated, the processor 401a executes the cart UI process described below in accordance with the cart terminal application AP401.
FIG. 13 is a flowchart of cart UI processing executed by the processor 401a.

As ACT 161, the processor 401a notifies the mobile controller 3 that it has been activated. The processor 401a transmits notification data for activation notification to the mobile controller 3 via wireless communication between the wireless communication unit 401d and the access point 6. The relevant notification data is transmitted to the mobile controller 3 via the access point 6 and the in-store communication network 7.
As ACT 162, the processor 401a waits for a usage start operation to be performed. At this time, the processor 401a is in a state of waiting for shopping to begin using the attached shopping cart C1. For example, in this standby state, the processor 401a causes a screen showing a start button to be displayed on the touch panel 401e. When using the cart POS service, the customer takes out one of the shopping carts C1 placed in the cart storage area and sends a message to the cart terminal 400 attached to the shopping cart C1 in advance to start using the service. Perform prescribed operations. If the customer is a member, the customer causes the scanner 402 or reader 403 to read the membership code recorded on the membership card. If the customer is not a member, he or she operates the start button described above. If these operations have been performed, the processor 401a determines YES as an operation for starting use has been performed, and proceeds to ACT163.

In ACT 163, the processor 401a requests check-in from the mobile controller 3. Specifically, the processor 401a transmits request data for requesting check-in to the mobile controller 3 via wireless communication between the wireless communication unit 401d and the access point 6. The request data is transmitted via the access point 6 and the in-store communication network 7 to the mobile controller 3 . Note that the processor 401a includes, in the request data for requesting check-in, identification data for identifying the request for check-in, and a terminal code for identifying the cart terminal 400 in which the processor 401a is installed. , and the aforementioned membership code. Note that when the start button is touched, the processor 401a notifies the virtual POS server 2 of a membership code predetermined for non-members. The membership code for non-members may be common to multiple customers or may be different. The relevant notification data is transmitted to the mobile controller 3 via the access point 6 and the in-store communication network 7.

Note that various requests from the cart terminal 400 to the mobile controller 3, which will be explained later, are made by transmitting request data including identification data for identifying the reason for the request to the access point 6 and the in-store communication network 7, as described above. This is realized by sending the data from the user terminal 300 to the mobile controller 3 via the mobile controller 3.

In the mobile controller 3, the processor 31 executes management processing according to the transaction management application AP31.
FIG. 14 is a flowchart of management processing by the processor 31.

In ACT 181, the processor 31 confirms whether the activation notification has been made. If the processor 31 cannot confirm the corresponding notification, the processor 31 determines NO and proceeds to ACT182.
As ACT 182, the processor 31 checks whether a check-in request has been made. If the processor 31 cannot confirm the corresponding request, the processor 31 determines NO and proceeds to ACT183.
In ACT 183, the processor 31 checks whether the mediation process has ended. If the processor 31 cannot confirm the completion of the mediation process, it determines NO and returns to ACT181.
In this way, the processor 31 waits for a startup notification, a check-in request, or an end of mediation processing in ACT181 to ACT183.

If the communication interface 34 receives the notification data for the activation notification transmitted from the cart terminal 400 as described above, the processor 31 determines YES in ACT181 and proceeds to ACT184.
As ACT 184, the processor 31 updates the cart list. The cart list is data representing a list of terminal codes of cart terminals 400 that are in operation. The cart list is stored in the main memory 32 or the auxiliary storage unit 33. For example, the processor 31 updates the cart list to include the terminal code included in the notification data. The processor 31 may acquire various data regarding the cart terminal 400, such as the SSID of the cart terminal 400, from the cart terminal 400, and may write the data in association with the terminal code in the cart list. Thereafter, the processor 31 returns to the standby state in ACT181 to ACT183. Although a detailed explanation will be omitted, when the processor 31 detects that the cart terminal 400 has stopped operating, it updates the cart list so as to delete the terminal code of the cart terminal 400.

If the request data for the check-in request transmitted from the user terminal 300 or the cart terminal 400 is received by the communication interface 34 as described above, the processor 31 determines YES in ACT 182 and proceeds to ACT 185. .
As ACT 185, the processor 31 checks whether the virtual POS server 2 can start a new transaction process. As will be described later, the virtual POS server 2 executes multiple transaction processes in parallel. However, due to resource limitations such as the processing capacity of the processor 21, the number of transaction processes that can be executed in parallel (hereinafter referred to as the maximum number) is limited. For example, if the total number of transaction processes being executed by the processor 21 at that time is less than the maximum number, the processor 31 determines YES that the transaction process can be started, and proceeds to ACT186.

In ACT 186, the processor 31 checks whether it is the cart terminal 400 that is requesting check-in. For example, the processor 31 checks whether the terminal code included in the request data is included in the cart list. If the corresponding terminal code is not included in the cart list, the processor 31 determines NO because it is the user terminal 300 that is requesting check-in, and proceeds to ACT187.
The processor 31 may check whether the user terminal 300 or the cart terminal 400 is requesting check-in based on the type data included in the request data. However, in this case, at least one of the processor 301 of the user terminal 300 and the processor 401a of the cart terminal 400 includes type data for distinguishing between the user terminal 300 and the cart terminal 400 in request data for requesting check-in. Make it.
In ACT 187, the processor 31 checks whether the user terminal 300 is in a state where the start of transaction processing is permitted. For example, if the number of transaction processes being executed by the virtual POS server 2 regarding the user terminal 300 is a predetermined allowable number, the processor 31 determines NO and proceeds to ACT188. In order to make this determination, for example, the processor 31 compares the number of executions stored in the main memory 32 or the auxiliary storage unit 33 as described later with respect to the mediation processing targeted at the user terminal 300, with the permissible number.

For example, for each store, the administrator of the store system 100 or the like determines a limit on the number of cart terminals 400 that can be operated simultaneously within the store. The processor 31 inputs the limit number of devices according to the operation of the administrator, etc., and stores the limit number in the main memory 32 or the auxiliary storage unit 33. Note that if the limit number is already stored in the main memory 32 or the auxiliary storage unit 33, the processor 31 overwrites it with the newly input limit number. Then, the processor 31 determines the number obtained by subtracting the limit number from the maximum number as the permissible number. Specifically, if the maximum number is 24 and the limited number is 15, the allowable number is 9. In this example, it is always guaranteed that transaction processing can be executed in parallel using each of the limited number of cart terminals 400 as target terminals.

However, the limited number of devices may be determined by, for example, the creator of the transaction management application AP31, and may be fixedly applied to each store. Further, the allowable number may be determined by, for example, the creator of the transaction management application AP31, and may be fixedly applied to each store. Further, the allowable number may be the number obtained by subtracting the number of terminal codes written in the cart list, that is, the number of cart terminals 400 in operation from the maximum number. The permissible number is determined by multiplying the limit number or the number of cart terminals 400 in operation by a coefficient less than 1, or by subtracting a certain number, and then subtracting an integer value from the maximum number. It may be a number. In addition, instead of the limited number of devices, a guaranteed number of connections that is determined as a number less than the maximum number regardless of the limited number is stored in the main memory 32 or auxiliary storage unit 33, and is calculated by subtracting the guaranteed number of connections from the maximum number. The number may be an acceptable number.

In addition to when the processor 31 determines NO in ACT 187, the processor 31 also proceeds to ACT 188 when it determines NO in ACT 185. Note that if the total number of transaction processes being executed by the processor 21 matches the maximum number, the processor 31 determines NO in ACT 185 as it is not possible to start. The processor 31 calculates the above-mentioned total number, for example, as the sum of two execution numbers stored in the main memory 32 or the auxiliary storage unit 33, as described later.
In ACT 188, the processor 31 notifies the user terminal 300 or cart terminal 400, which is the source of the check-in request, of an error that check-in is not possible. Thereafter, the processor 31 returns to the standby state in ACT181 to ACT183. In other words, the processor 31 receives a check-in request made from the user terminal 300 or the cart terminal 400 while the virtual POS server 2 is unable to start a new transaction process, or when the number of executed transaction processes related to the user terminal 300 reaches the permissible number. A check-in request made from the user terminal 300 in this state is rejected.

If the virtual POS server 2 can start a new transaction process and the check-in request is from the cart terminal 400, the processor 31 determines YES in ACT186 and proceeds to ACT189. Note that, for example, if the terminal code included in the request data is included in the cart list, the processor 31 determines YES in ACT 186 because the check-in request is from the cart terminal 400. Furthermore, if the virtual POS server 2 is capable of starting new transaction processing and the check-in request is from the user terminal 300, but the number of executions of transaction processing regarding the user terminal 300 is less than the allowable number, , YES is determined in ACT187 and the process proceeds to ACT189.
In ACT 189, the processor 31 starts mediation processing targeting the user terminal 300 or cart terminal 400 that has requested check-in. Note that the mediation process is executed by the processor 31 in parallel with the management process, for example, as a process in a separate thread from the management process. Note that if the processor 31 is already executing a mediation process for another user terminal 300 or cart terminal 400, it starts a new mediation process in parallel with that mediation process. That is, the processor 31 may execute multiple mediation processes in parallel.

As ACT 190, the processor 31 increases the number of executions of mediation processing. The processor 31 manages, for example, the number of executions of mediation processing targeted at the user terminal 300 and the number of executions of mediation processing targeted at the cart terminal 400 by storing them in the main memory 12 or the auxiliary storage unit 13, for example. . When the processor 31 starts the mediation process targeting the user terminal 300 in ACT 189, it increases the number of executions of the mediation process targeting the user terminal 300 by one. Furthermore, if the processor 31 starts the mediation process targeting the cart terminal 400 in ACT 189, it increases the number of executions of the mediation process targeting the cart terminal 400 by one. Thereafter, the processor 31 returns to the standby state in ACT181 to ACT183.

When the mediation process started as described above is completed, the processor 31 determines YES in ACT183 and proceeds to ACT191.
As ACT 191, the processor 31 reduces the number of executions. For example, if the completed mediation process targeted the user terminal 300, the processor 31 decreases the number of executions of the mediation process targeted at the user terminal 300 by one. Further, if the completed mediation process was targeted at the cart terminal 400, the processor 31 decreases the number of executions of the mediation process targeted at the cart terminal 400 by one. Thereafter, the processor 31 returns to the standby state in ACT181 to ACT183.

15 and 16 are flowcharts of mediation processing by the processor 31.
As described above, the processor 31 may execute a plurality of mediation processes in parallel for a plurality of user terminals 300 or cart terminals 400, respectively. In the following explanation of the mediation process, when it is simply written as the user terminal 300 or the cart terminal 400, it refers to the user terminal 300 or the cart terminal 400 that is the target of the mediation process. In addition, when there is no need to distinguish between the user terminal 300 or the cart terminal 400 that is the target of the mediation process, it is referred to as a target terminal.

As ACT201 in FIG. 15, the processor 31 performs check-in processing. For example, the processor 31 requests the virtual POS server 2 to start a transaction and receives notification of the transaction code. The processor 31 then adds the new data record DR1 to the transaction management database DB31. The processor 31 sets the terminal code included in the request data in the field F11 of the new data record DR1. 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. If the request data includes a point ID, the processor 31 attempts to obtain the electronic receipt ID associated with this point ID. That is, the processor 31, for example, accesses the store server 1, checks the user database included in the database group DB11, and, if an electronic receipt ID is associated with the point ID, acquires the electronic receipt ID. If the processor 31 is able to obtain the electronic receipt ID in this way, it sets the electronic receipt ID in the field F14 of the new data record DR1. As a result, management of transactions performed using the target terminal is started.

In the virtual POS server 2, the processor 21 starts transaction processing according to the virtual POS application AP21 when the mobile controller 3 requests the start of the transaction.
FIG. 18 is a flowchart of transaction processing by the processor 21.

The processor 21 starts transaction processing every time a transaction start is requested. If another transaction process is already being executed, a new transaction process is started in parallel. In other words, when the mobile controller 3 executes a plurality of mediation processes in parallel, the processor 21 executes a plurality of transaction processes corresponding to each of the plurality of mediation processes in parallel.

In other words, the processor 31 starts the intermediary process in response to a request from the user terminal 300 or the cart terminal 400 as a terminal device, thereby allowing the processor of the virtual POS server 2 to process the transaction process in accordance with the instruction from the requesting terminal device. It will start on the 21st. However, the processor 31 assumes that the requesting terminal device is the user terminal 300 as a terminal device belonging to the first type, and a predetermined allowable number of transaction processes have already been executed by the processor 21 with the user terminal 300 as the target terminal. If it is inside, transaction processing in response to the above request will not be started.

As ACT 301, the processor 21 executes transaction start processing. In this transaction initiation process, the processor 21 determines a transaction code according to predetermined rules, and updates the transaction database DB 21 to include new data records for managing purchased items in the transaction identified by the transaction code. Update. The processor 21 then notifies the mobile controller 3 of the transaction code determined above.

In ACT 302, the processor 21 checks whether a change in the purchased product is requested. If the processor 21 cannot confirm the corresponding request, the processor 21 determines NO and proceeds to ACT303.
As ACT 303, processor 21 checks whether cancellation of the transaction has been requested. Then, if the processor 21 cannot confirm the corresponding request, the processor 21 determines NO and proceeds to ACT304.
As ACT 304, the processor 21 checks whether payment is requested. If the processor 21 cannot confirm the corresponding request, the processor 21 determines NO and proceeds to ACT305.
In ACT 305, the processor 21 checks whether transfer of payment data is requested. If the processor 21 cannot confirm the request, the processor 21 determines NO and proceeds to ACT306.
In ACT 306, the processor 21 checks whether termination has been instructed. Then, if the processor 21 cannot confirm the corresponding instruction, the processor 21 determines NO and returns to ACT302.
In this way, the processor 21 waits for any one of change, cancellation, settlement, or transfer to be requested, or for completion to be instructed, in ACT 302 to ACT 306.

Now, after the processor 31 in the mobile controller 3 finishes the check-in process, it proceeds to ACT202 in FIG. 15.
As ACT 202, the processor 31 confirms whether the check-in process has been completed normally. If the check-in process cannot be completed normally due to some abnormality, the processor 31 determines NO and proceeds to ACT203.
In ACT 203, the processor 31 notifies the target terminal of the error. For example, the processor 31 transmits notification data for error notification to the target terminal via the in-store communication network 7 and the access point 6. The processor 31 includes identification data for identifying that the notification is an error notification in the notification data. The processor 31 may include an error code indicating the cause of the error in the notification data. The processor 31 then ends the mediation process.

Note that various notifications from the mobile controller 3 to the target terminal, which will be explained below, are made by transmitting notification data including identification data for identifying the reason for the notification via the in-store communication network 7 and the access point 6, as described above. This is realized by sending the information from the mobile controller 3 to the target terminal.

On the other hand, if the processor 31 is able to successfully complete the check-in process, it determines YES in ACT202 and proceeds to ACT204.
As ACT 204, the processor 31 notifies the target terminal of completion of check-in.

After the processor 301 in the user terminal 300 requests check-in in ACT108 in FIG. 9, the process proceeds to ACT109.
In ACT 109, the processor 301 checks whether check-in completion has been notified. If the processor 301 cannot confirm the corresponding notification, the processor 301 determines NO and proceeds to ACT110.
As ACT 110, the processor 301 checks whether a check-in error has been notified. If the processor 301 cannot confirm the corresponding notification, the processor 301 determines NO and returns to ACT109.
In this manner, the processor 301 waits for notification of check-in completion or error as ACT 109 and ACT 110. If the wireless communication unit 306 receives notification data for error notification in ACT188 in FIG. 14 or ACT203 in FIG. 15, the processor 301 determines YES in ACT110 and proceeds to ACT111.

As ACT 111, the processor 301 displays an error screen on the touch panel 304. The error screen is a screen designed to notify customers that check-in is not possible. Note that in response to the error notification in ACT 188 in FIG. 14, the processor 301, for example, notifies you that you cannot check in because the store is crowded, and also displays an error screen that prompts you to try checking in after a while. Display. Note that if the processor 301 is instructed to eliminate the display of the error screen by, for example, operating a GUI element displayed on the error screen, the processor 301 returns to ACT101.

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

FIG. 20 is a diagram showing an example of the list screen SC1.
List screen SC1 includes display areas AR11, AR12 and buttons BU11, BU12, BU13. Display area AR11 represents the total number of purchased products and the total price of the purchased products. Display area AR12 represents a list of purchased products. Button BU11 is a soft key used by the customer to declare that he/she wants to cancel all purchased items and cancel shopping. Button BU12 is a soft key used by the customer to declare to start scanning of products to be registered as purchased products. Button BU13 is a soft key for the customer to declare that he/she wants to start payment.
Note that FIG. 20 shows the list screen SC1 in a state where no purchased products have been registered yet. Therefore, the total number and the total amount are both "0" displayed in the display area AR11, and nothing is displayed in the display area AR12.

In ACT 113 in FIG. 10, the processor 301 confirms whether or not the start of product scanning has been designated. If the processor 301 cannot confirm the corresponding designation, the processor 301 determines NO and proceeds to ACT114.
As ACT 114, the processor 301 checks whether a change in quantity has been specified. If the processor 301 cannot confirm the corresponding designation, the processor 301 determines NO and proceeds to ACT115.
As ACT 115, the processor 301 confirms whether or not the cancellation of shopping has been specified. If the processor 301 cannot confirm the corresponding designation, the processor 301 determines NO and proceeds to ACT116.
As ACT 116, the processor 301 checks whether the start of accounting has been specified. If the processor 301 cannot confirm the corresponding designation, the processor 301 determines NO and returns to ACT113.
In this way, the processor 301 waits for any one of scan start, quantity, stop, and start of accounting to be specified as ACT113 to ACT116.

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

FIG. 21 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. Display area AR21 displays images obtained by camera 305. Message ME21 is a text message urging the customer to read the barcode of the product. Button BU21 is a soft key for the customer to declare to cancel scanning of the product code.
For example, the processor 301 activates the camera 305, and generates the registration screen SC2 by superimposing a line representing the range of the display area AR21, an image representing the message ME21, and the button BU21 on the image obtained by the camera 305. do.

In ACT118 in FIG. 10, the processor 301 checks whether the barcode has been read. At this time, the processor 301 analyzes the image obtained by the camera 305 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS application AP301, or may be performed as a process based on another application program for reading barcodes. If the barcode cannot be read, the processor 301 determines NO and proceeds to ACT119.
In ACT 119, the processor 301 checks whether or not canceling the scan is specified. If the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to ACT118.
Thus, in ACT 118 and ACT 119, the processor 301 waits until the barcode is read or the scan is designated to be stopped.

If the customer wishes to return to the list screen without performing the current scan, the customer specifies to cancel the scan by a predetermined operation such as touching the button BU21. In response, the processor 301 determines YES in ACT119, and returns to ACT112.

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 a purchased product is reflected in the display area AR21. If the barcode is read in response to this, the processor 301 determines YES in ACT118, and proceeds to ACT120.
As ACT 120, processor 301 requests registration from mobile controller 3. The request data transmitted by the processor 301 includes data represented by the read barcode (hereinafter referred to as barcode data).
As ACT 121, the processor 301 waits for an instruction to display a list screen.

When the customer touches the area representing the number of items on the list screen SC1 while in the standby state of ACT113 to ACT116, the processor 301 displays a list box for specifying the number of items overlaid on the list screen SC1. When this list box is operated, the processor 301 receives this as a quantity specification. In this case, the processor 301 determines YES in ACT114 in FIG. 10, and proceeds to ACT122 in FIG.

In ACT 122, the processor 301 checks whether the specified number is 0 or not. Then, the processor 301 determines NO if the specified number is not 0, and proceeds to ACT123.
As ACT 123, the processor 301 requests the mobile controller 3 to change the quantity. The request data transmitted here by the processor 301 includes specific data for specifying the product for which the quantity is specified and the specified number. The specific data may be a product code, or may be data that allows only the mobile controller 3 to specify the purchased product, such as a number for identifying each purchased product in a list of purchased products. Note that if a product code is used as the specific code, the processor 31 includes the product code regarding each purchased product in the instruction data for instructing display of the list screen.

Now, if the specified number is 0, the processor 301 determines YES in ACT122, and proceeds to ACT124.
As ACT 124, the processor 301 displays a deletion screen on the touch panel 304. The deletion screen is a screen that notifies the customer that the product whose number is specified to be 0 will be deleted from the purchased products. The deletion screen includes a delete button for specifying deletion, and a return button for specifying to return to the state before specifying a change in the number without changing the number.

In ACT 125, the processor 301 checks whether deletion is specified. If the processor 301 cannot confirm the relevant designation, it determines NO and proceeds to ACT126.
In ACT 126, the processor 301 checks whether return is specified. Then, if the processor 301 cannot confirm the corresponding designation, the processor 301 determines NO and returns to ACT125.
Thus, the processor 301 waits for deletion or return to be specified in ACT 125 and ACT 126.

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

If the customer is sure about the deletion, he/she specifies the deletion by a predetermined operation such as touching a delete button on the deletion screen. In response, the processor 301 determines YES in ACT125, and proceeds to ACT127.
In ACT 127, the processor 301 requests the mobile controller 3 to delete it. The request data transmitted here by the processor 301 includes specific data for specifying the product designated for deletion.

After the processor 301 requests a quantity change in ACT 123 or requests deletion in ACT 127, the processor 301 proceeds to ACT 128.
In ACT 128, the processor 301 waits for an instruction to display a list screen.

Now, in the mobile controller 3, the processor 31 notifies the completion of check-in in ACT204 in FIG. 15, and then proceeds to ACT205.
In ACT 205, the processor 31 checks whether a change in the purchased product is requested. If the processor 31 cannot confirm the corresponding request, the processor 31 determines NO and proceeds to ACT206.
As ACT 206, the processor 31 checks whether cancellation of the purchased product is requested. Then, the processor 31 determines NO if the corresponding request cannot be confirmed, and proceeds to ACT207.
As ACT 207, processor 31 checks whether accounting has been requested. Then, if the processor 31 cannot confirm the corresponding request, the processor 31 determines NO and proceeds to ACT208.
As ACT 208, the processor 31 checks whether the time limit has elapsed. Then, the processor 31 determines NO if the situation is not applicable, and returns to ACT205.
Thus, in ACT 205 to ACT 208, the processor 31 waits for any one of change, cancellation, and accounting to be requested, or for the time limit to elapse. If the user terminal 300, which is the target terminal, requests registration, quantity change, or deletion as described above, the processor 31 determines YES in ACT 205, and proceeds to ACT 209 in FIG. move on.

As ACT 209, the processor 31 transfers the request from the user terminal 300 to the virtual POS server 2, along with 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 is, or may send the request data after conversion by some processing to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the barcode data or specific data included in the request data sent from the user terminal 300.

If the processor 21 in the virtual POS server 2 receives request data regarding registration, quantity change, or deletion from the mobile controller 3 while in the standby state in ACT302 to ACT305 in FIG. 18, it selects YES in ACT302. After making a determination, proceed to ACT307.
As ACT 307, the processor 21 updates the transaction database DB21 in response to the request with the transferred request data. For example, when registration is requested, the processor 21 assumes that the barcode data included in the request data has been read by a barcode scanner installed in an existing POS terminal, and uses the existing POS terminal. Attempts to register purchased items using the same process as the POS terminal. However, for some reason, the product code represented by the barcode data may not be registered in the product database. Additionally, a product may have a barcode displayed on it that is different from the product code. In these cases, the processor 21 is unable to register the purchased product and considers it an error. In this way, the processor 21 registers the purchased product based on reading the regular barcode. For example, when a quantity change is requested, the processor 21 changes the quantity already shown in the transaction database DB21 for the product subject to the quantity change. For example, when deletion is requested, the processor 21 updates the transaction database DB21 to exclude the target product from the purchased products.

As ACT 308, the processor 21 transmits result data representing the result of the above processing to the mobile controller 3. If the purchased product is successfully registered, the processor 21 includes identification data for identifying that the notification is a regular registration notice, and the product code, product name, and price of the registered product in the result data. When the quantity is changed, the processor 21 includes the product code of the changed product and the changed number in the result data. When the purchased product is deleted, the processor 21 includes the product code of the product excluded from the purchased products in the result data. Further, when the processor 21 determines that the notification is an error, the processor 21 includes identification data for identifying that the notification is an error notification and the barcode data sent in the registration request in the result data. When the processor 21 finishes transmitting the result data, it returns to the standby state in ACT302 to ACT305.

After transferring the request in ACT209, the processor 31 in the mobile controller 3 proceeds to ACT210.
As the ACT 210, the processor 31 acquires the result data transmitted from the virtual POS server as described above. The processor 31 stores the obtained result data in the main memory 32 or the auxiliary storage unit 33.

As the ACT 211, the processor 31 updates the registration database DB32 based on the above result data. The registration database DB32 is updated, for example, as follows.
First case: This is a notification of regular registration, and the data record DR2 associated with the transaction to be processed does not include registration data that includes 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 to be processed, and adds new registered data to the field. The processor 31 includes, in the new registration data, the notified product code, the error flag set to "0" to indicate that there is no error, the notified product name and price, and the number set to "1". A cancellation flag of "0" indicating that the cancellation has not been canceled is included. Thus, the registered data added in this case has a structure as shown in the upper right side of FIG.

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

Third case: This is a notification of regular registration, and the data record DR2 associated with the transaction to be processed includes registration data that includes the notified product code, and the cancellation flag of the registration data is “0”.
In this case, the processor 31 rewrites the value of the number included in the registered data that includes the notified product code and whose cancellation flag is "0" to a value that is one larger.

Fourth case: When the notification is a change in quantity.
In this case, the processor 31 finds registered 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.

Fifth case: When it is a notice of deletion.
In this case, the processor 31 finds registered 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".

Sixth 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 to be processed, and adds new registered data to the 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 registered 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 manner, the registration database DB32 represents a list of purchased products that have been registered in the virtual POS server 2, and also records barcode readings that have resulted in errors.
Note that 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 above-mentioned sixth case, the stored barcode data is used as the registration data. May be included in In this case, the processor 21 in the virtual POS server 2 does not need to include barcode data in the result data. The processor 31 may also extract a product code from the stored barcode data and process the first to fifth cases based on this product code. Further, the product name and price may be acquired by the processor 31 from the store server 1 or the like based on the product code.

As ACT 212, the processor 31 instructs the user terminal 300 to display a list screen. For example, the processor 31 transmits instruction data including identification data for identifying that the instruction is to display a list screen to the user terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity included in the data record DR2 associated with the transaction to be processed in the registration database DB32. Furthermore, if the current registration is an error, the processor 31 includes error data indicating this in the instruction data. Thereafter, the processor 31 returns to the standby state in ACT205 to ACT208 in FIG.

Note that various instructions from the mobile controller 3 to the user terminal 300, which will be explained below, are sent to the in-store communication network 7 and the access point 6 by sending instruction data including identification data for identifying the reason for the instruction, as described above. This is realized by sending the data from the mobile controller 3 to the user terminal 300 via the mobile controller 3.

When the result data in any of the first to third cases and sixth cases described above is received by the wireless communication unit 306 at the user terminal 300, the processor 301 determines YES in ACT121 in FIG. do. Further, when the result data in the fourth case or the fifth case described above is received by the wireless communication unit 306, the processor 301 determines YES in ACT128 in FIG. In these cases, the processor 301 returns to ACT112 in FIG. 10 and displays the list screen SC1 on the touch panel 304 again. At this time, the processor 301 sets the list screen SC1 as a screen showing the product name, price, and quantity of the purchased products included in the instruction data. Further, if the instruction data includes error data, the processor 301 adds a message to the list screen SC1 to indicate that the instruction data has not been correctly registered.

FIG. 22 is a diagram showing an example of the list screen SC1 in a state where purchased products have been registered.
The list screen SC1 shown in FIG. 22 has one product with the product name "AAA" and a price of 120 yen, two products with the product name "BBB" and a price of 98 yen, and This is an example in which one product whose product name is "CCC" and whose price is 1,024 yen has been registered as a purchased product. In the list screen SC1 shown in FIG. 22, a display area AR12 displays product names, prices, and quantities regarding these registered products. Furthermore, the display area AR11 shows "4" as the total number and "1,340" as the total amount. Note that the area surrounded by a broken line to the left of the product name represents an area for displaying an icon. The broken line representing the area is not actually displayed on the list screen SC1.

If the customer wants to cancel all of the purchased products that have already been registered and cancel the shopping, the customer specifies cancellation by a predetermined operation such as touching the button BU11 on the list screen SC1. In response, the processor 301 determines YES in ACT115 in FIG. 10, and proceeds to ACT129 in FIG.
As ACT 129, the processor 301 displays a cancellation screen on the touch panel 304. The cancellation screen is a screen that notifies the customer that all purchased products that have already been registered will be cancelled. The cancellation screen includes an execution button for designating cancellation, and a return button for designating returning to the state before designating a change in the number without changing the number.

As ACT 130, the processor 301 checks whether cancellation execution has been specified. If the processor 301 cannot confirm the corresponding designation, it determines NO and proceeds to ACT131.
In ACT 131, the processor 301 checks whether return is specified. Then, if the processor 301 cannot confirm the corresponding designation, the processor 301 determines NO and returns to ACT130.
In this way, the processor 301 waits for cancellation execution or return to be specified as ACT130 and ACT131.

If the customer wishes to continue shopping, he/she specifies return through a predetermined operation such as touching a return button on the cancellation screen. In response, the processor 301 determines YES in ACT131, returns to ACT112 in FIG. 10, and displays the list screen SC1 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 again the list screen SC1 in the same state as that displayed before displaying the cancellation screen.

If the customer wishes to cancel the shopping, he or she specifies the cancellation through a predetermined operation such as touching an execution button on the cancellation screen. In response, the processor 301 determines YES in ACT130, and proceeds to ACT132.
As ACT 132, the processor 301 requests the mobile controller 3 to cancel.

If the cancellation is requested from the user terminal 300 as described above, the processor 31 in the mobile controller 3 determines YES in ACT 206 in FIG. 15, and proceeds to ACT 213 in FIG. 16.
As ACT 213, the processor 31 transfers a cancellation request to the virtual POS server 2 along with notification of the transaction code of the transaction being processed. At this time, the processor 31 may transfer the request data sent from the user terminal 300 to the virtual POS server 2 as is, or may send the request data after conversion by some processing to the virtual POS server 2.

If the processor 21 in the virtual POS server 2 receives request data regarding cancellation from the mobile controller 3 while in the standby state in ACT302 to ACT305 in FIG. 18, it determines YES in ACT303 and proceeds to ACT309. and proceed.
As ACT 309, the processor 21 updates the transaction database DB21 in response to the request with the transferred request data. For example, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a cancellation instruction input by an input device provided in an existing POS terminal, and performs the same processing as the existing POS terminal. As a result, the transaction database DB21 is updated so that all registered products associated with the notified transaction code are excluded from the purchased products.

As ACT 310, processor 21 transmits result data representing the result of the above processing to mobile controller 3. The processor 21 includes the product codes of all products excluded from the purchased products in the result data. When the processor 21 finishes transmitting the result data, it returns to the standby state in ACT302 to ACT305.

As described above, the processor 21 determines the details of the transaction according to the operation received at the target terminal. As the processor 21 executes information processing based on the virtual POS application AP21, the computer having the processor 21 as its core functions as a determining means.

After transferring the request in ACT213, the processor 31 in the mobile controller 3 proceeds to ACT214.
As the ACT 214, the processor 31 acquires the result data transmitted from the virtual POS server as described above. The processor 31 stores the obtained result data in the main memory 32 or the auxiliary storage unit 33.

As ACT215, the processor 31 updates the registration database DB32 based on the above result data. That is, the processor 31 changes the cancellation flag from "0" to "1" for all of the registered data included in the data record DR2 associated with the transaction to be processed.
As ACT 216, the processor 31 notifies the user terminal 300 of the cancellation. Thereafter, the processor 31 returns to the standby state in ACT205 to ACT208 in FIG.

Now, the processor 301 in the user terminal 300 requests cancellation in ACT132 in FIG. 11, and then proceeds to ACT133.
As ACT 133, processor 301 waits for notification of cancellation from mobile controller 3. If the processor 301 is notified of cancellation as described above, it determines YES and returns to ACT101 in FIG.

Once the customer has finished registering all of the products he/she wishes to purchase as purchased products, the customer proceeds to payment. At this time, the customer specifies the start of checkout by a predetermined operation such as touching the button BU13 on the list screen SC1. In response, the processor 301 determines YES in ACT116 in FIG. 10, and proceeds to ACT134.
As ACT 134, processor 301 requests accounting from mobile controller 3. Processor 301 includes the terminal code in the request data transmitted here. Further, if the electronic receipt ID is stored in the auxiliary storage unit 303, the processor 301 includes the electronic receipt ID in the above request data.
As ACT 135, the processor 301 waits for an instruction to display the accounting screen.

When the transaction is requested from the user terminal 300 as described above, the processor 31 in the mobile controller 3 determines YES in ACT 207 in FIG. 15, and proceeds to ACT 217 in FIG. 16.
In ACT 217, the processor 31 checks whether the electronic receipt ID has been notified from the user terminal 300. Then, if the request data includes the electronic receipt ID, the processor 31 determines YES and proceeds to ACT218.

As ACT 218, the processor 31 updates the transaction management database DB31 to record the electronic receipt ID notified from the user terminal 300. For example, the processor 31 searches the transaction management database DB31 for the data record DR1 in which the terminal code included in the request data is set in the field F11. Then, the processor 31 sets the electronic receipt ID included in the request data in the field F14 of the corresponding data record DR1. Note that if the electronic receipt ID has already been set in the field F14 of the corresponding data record DR1, the processor 31 overwrites this with the electronic receipt ID included in the request data.

After the processor 31 finishes updating the transaction management database DB31, it proceeds to ACT219. Note that if the request data does not include the electronic receipt ID, the processor 31 determines NO in ACT 217, passes ACT 218, and proceeds to ACT 219.
As ACT 219, the processor 31 instructs the user terminal 300 to display the checkout screen.

If the processor 301 in the user terminal 300 is instructed to display the checkout screen as described above, it determines YES in ACT 135 in FIG. 10, and proceeds to ACT 136 in FIG. 12.
As ACT 136, the processor 301 displays a checkout screen on the touch panel 304. The checkout screen is a screen for the customer to select whether to use the user terminal 300 or the checkout machine 5 to perform the operation for payment.

FIG. 23 is a diagram showing an example of the checkout screen SC3.
The checkout screen SC3 includes a display area AR31, a message ME31, and buttons BU31 and BU32. Display area AR31 represents the total number of purchased products and the total price of the purchased products. The message ME31 is a text 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. Button BU31 is a soft key for specifying user terminal 300 by the customer. The button BU32 is a soft key for the customer to specify the accounting machine 5.

In ACT 137, the processor 301 checks whether the user terminal 300 has been designated. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and proceeds to ACT138.
In ACT 138, the processor 301 checks whether the accounting machine 5 has been designated. Then, if the corresponding designation cannot be confirmed, the processor 301 determines NO and returns to ACT137.
Thus, the processor 301 waits for the user terminal 300 or the accounting machine 5 to be designated as the ACT 137 and ACT 138.

If the customer wishes to perform an operation for payment on the user terminal 300, the customer specifies the user terminal 300 by a predetermined operation such as touching the button BU31. In response to this, the processor 301 determines YES in ACT137, and proceeds to ACT139.
As ACT 139, processor 301 requests payment from mobile controller 3. Note that the processor 301 may include payment information necessary for payment, such as a credit number or a user code for an online payment service, in the request data for requesting payment.

After the processor 31 in the mobile controller 3 instructs the display of the checkout screen in ACT219 in FIG. 16, the process proceeds to ACT220.
As ACT 220, the processor 31 checks whether payment is requested. Then, the processor 31 determines NO if the corresponding request cannot be confirmed, and proceeds to ACT221.
In ACT 221, the processor 31 checks whether the completion of payment has been notified. Then, the processor 31 determines NO if the corresponding notification cannot be confirmed, and returns to ACT220.
Thus, the processor 31 waits for a payment request or payment completion notification as ACT 220 and ACT 221. If payment is requested from the user terminal 300 as described above, the processor 31 determines YES in ACT 220 and proceeds to ACT 222.

As ACT 222, the processor 31 transfers the payment request to the virtual POS server 2 along with 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 is, or may send the request data after conversion by some processing to the virtual POS server 2. However, if the processor 31 has already acquired the electronic receipt ID for the transaction being processed, the processor 31 includes the electronic receipt ID in the request data. For example, the processor 31 searches the transaction management database DB31 for the data record DR1 in which the terminal code included in the request data is set in the field F11. Then, if the electronic receipt ID is set in the field F14 of the corresponding data record DR1, the processor 31 includes the electronic receipt ID in the request data. Further, if the request data sent from the user terminal 300 includes payment data, the processor 31 includes this payment data as is in the request data sent to the virtual POS server 2.

If the electronic receipt ID set in the field F14 of the data record DR1 is transmitted from the user terminal 300, the processor 31 transfers the electronic receipt ID to the virtual POS server 2 as the second information processing device. The communication interface 34 will be used to transfer the information to the destination.
As ACT 223, the processor 31 waits for notification of payment completion.

If request data regarding payment is transferred from the mobile controller 3 while in the standby state in ACT302 to ACT305 in FIG. 18, the processor 21 in the virtual POS server 2 determines YES in ACT304, Proceed to ACT311 in 19.
As ACT 311, the processor 21 executes payment processing for paying the price in response to the request based on the transferred request data. For example, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a payment instruction input by an input device provided in an existing POS terminal, and performs the same processing as that of an existing POS terminal. calculates the price for the transaction identified by the notified transaction code. The processor 21 then requests the payment server 500 to settle the calculated price. For example, the processor 21 refers to the user database included in the database group DB11, determines the payment method to be applied to the payment, and acquires payment information to be used for the payment using the payment method. If multiple payment methods or multiple payment information are registered in the user database, one of them is selected in response to an instruction from an operator on the user terminal 300 or according to predetermined conditions. . Note that, for example, if the request data includes payment information, the processor 21 may determine the payment method to be used for the payment based on the payment information, and may use the payment information as the payment information to be used for the payment.

In ACT 312, the processor 21 checks whether the electronic receipt ID has been notified. For example, if the electronic receipt ID is included in the request data requesting payment, the processor 21 determines YES and proceeds to ACT313.
As ACT 313, the processor 21 registers the transaction data regarding the transaction for which the payment has been completed as described above in the electronic receipt server 600 so that the user identified by the electronic receipt ID included in the above request data can view it. Perform processing. Note that this process may be similar to the process performed by existing electronic receipt services, for example. The type of data that the processor 21 includes in the transaction data follows, for example, the regulations of the electronic receipt service.

When the customer wishes to perform an operation for payment of the price using the accounting machine 5, the customer specifies the accounting machine 5 by a predetermined operation such as touching the button BU32 on the accounting screen SC3. In response, the processor 301 in the user terminal 300 determines YES in ACT138 in FIG. 12, and proceeds to ACT140.
As ACT 140, the processor 301 displays a checkout barcode screen on the touch panel 304. The accounting barcode screen is a screen showing an accounting barcode representing data necessary for the accounting machine 5 to acquire data regarding the details of the transaction from the virtual POS server 2. Although detailed processing is not shown, the processor 301 acquires the 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 the scanner provided in the checkout machine 5, which is not used by other customers, to read the checkout barcode. In response, the accounting machine 5 requests the virtual POS server 2 to transfer payment data according to the data represented by the accounting barcode. For example, the accounting machine 5 transmits request data including the transaction code included in the data represented by the accounting barcode to the virtual POS server 2.

When the processor 21 in the virtual POS server 2 receives request data for a transfer request that includes the transaction code of the transaction that is the subject of transaction processing in the standby state of ACT302 to ACT305 shown in FIG. For example, the determination is YES in ACT305, and the process proceeds to ACT314 in FIG.
As ACT 314, the processor 21 transmits payment data representing the details of the transaction to be processed and necessary for payment at the payment machine 5 to the payment machine 5 that requested the transfer. Note that the payment data may be, for example, data similar to payment data that is transferred from a registration machine to an accounting machine in an existing semi-self-type transaction processing system.
As ACT 315, the processor 21 waits for the payment to be completed at the accounting machine 5 that sent the payment data as described above.

When the accounting machine 5 receives the payment data transmitted from the virtual POS server 2, it settles the transaction price while receiving operations from the operator. The accounting machine 5 also issues various printed materials such as receipts and coupons as necessary. When the payment is completed, the accounting machine 5 notifies the virtual POS server 2 of this fact. In response to this, the processor 21 in the virtual POS server 2 determines YES in ACT315, and proceeds to ACT316.
Note that even after the processor 21 completes electronic receipt registration in ACT313, the process proceeds to ACT316. Further, if the electronic receipt ID is not included in the request data requesting payment, the processor 21 determines NO in ACT 312, passes ACT 313, and proceeds to ACT 316.
In ACT 316, the processor 21 updates the transaction database DB21 to end the management of the transaction being processed. For example, the processor 21 deletes the data record including the transaction code of the transaction to be processed from the transaction database DB21.
As ACT 317, the processor 21 notifies the mobile controller 3 of the completion of the payment. The processor 21 then ends the transaction process.

When the processor 31 in the mobile controller 3 is notified of the completion of payment from the virtual POS server 2 as described above, it determines YES in ACT221 or ACT223 in FIG. 16, and in either case, the process proceeds to ACT224. Incidentally, when the processor 21 proceeds from ACT312 or ACT313 in FIG. 18 to ACT317, the processor 31 determines YES in ACT221 in FIG. 16, and the processor 21 proceeds from ACT315 to ACT317 in FIG. In this case, YES is determined in ACT223 in FIG.
As ACT 224, the processor 31 notifies the user terminal 300 of the completion of payment.

After the processor 301 in the user terminal 300 requests payment in ACT 139 or displays the accounting barcode screen in ACT 140, the processor 301 proceeds to ACT 141.
As ACT 141, the processor 301 waits for notification of payment completion. If the processor 301 is notified of the completion of payment from the mobile controller 3 as described above, the processor 301 determines YES and proceeds to ACT142.
As ACT 142, the processor 301 displays a completion screen on the touch panel 304. The completion screen is a screen for notifying the customer that the payment has been completed.

After confirming the completion screen, the customer declares his/her confirmation by a predetermined operation such as touching a button displayed on the completion screen. In response, the processor 301 proceeds to ACT143. Note that the processor 301 may proceed to ACT 143 when the elapsed time with the completion screen displayed reaches a predetermined time.

In ACT 143, the processor 301 displays a scan screen for checkout on the touch panel 304. The scan screen for checkout is a screen for reading the two-dimensional code TC2 for checkout. For example, the processor 301 activates the camera 305, and displays, on the image obtained by the camera 305, a text message urging the customer to read the two-dimensional code TC2 and an indication 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 posted near the exit of the store so that the two-dimensional code TC2 is reflected on the scan screen.
As ACT 144, the processor 301 waits for the two-dimensional code to be read. At this time, the processor 301 repeatedly analyzes images obtained by the camera 305 and attempts to read the two-dimensional code. Reading this 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. If the two-dimensional code is read, the processor 301 determines YES and proceeds to ACT145.

In ACT 145, the processor 301 checks whether the data represented by the read two-dimensional code is checkout data. Then, the processor 301 determines NO if the data is not checkout data, and returns to ACT144. At this time, the processor 301 may cause the touch panel 304 to display a screen that notifies the customer that an incorrect two-dimensional code has been read.

If the processor 301 confirms that the data represented by the read two-dimensional code is checkout data, it determines YES in ACT145 and proceeds to ACT146.
As ACT 146, the processor 301 requests the mobile controller 3 to check out.

After the processor 31 in the mobile controller 3 notifies payment completion in ACT224 in FIG. 16, the process proceeds to ACT225.
As ACT 225, the processor 31 waits for a checkout request. If checkout is requested from the user terminal 300 as described above, the processor 31 determines YES and proceeds to ACT226.

As ACT 226, the processor 31 executes checkout processing. The checkout process is a process such as clearing data stored in the main memory 32 and the auxiliary storage unit 33 for managing the transaction being processed. Note that the virtual POS server 2 may end the processing related to the corresponding transaction in response to the completion of the payment, or may end the processing related to the transaction in response to an instruction from the mobile controller 3. In the latter case, the processor 31 issues the above instruction to the virtual POS server 2 in the checkout process. Further, a history database representing a history of user operations including erroneous barcode scans may be managed by the store server 1, the virtual POS server 2, the mobile controller 3, or another server (not shown). In this case, in the checkout process, the processor 31 performs processing to update the history database so as to reflect the history of operations related to the current transaction.
As ACT 227, the processor 31 notifies the user terminal 300 of the completion of checkout. The processor 31 then ends the mediation process.

After the processor 301 in the user terminal 300 requests checkout in ACT146 in FIG. 12, the process proceeds to ACT147.
As ACT 147, the processor 301 waits for notification of checkout completion. If the processor 301 is notified of the checkout completion from the mobile controller 3 as described above, it determines YES and proceeds to ACT148.
In ACT 148, the processor 301 clears various data temporarily used regarding the current shopping, such as check-in data saved in ACT 107 in FIG. 9, for example. The processor 301 then returns to ACT101 in FIG.

By the way, after the processor 401a in the cart terminal 400 requests check-in in ACT163 in FIG. 13, the process proceeds to ACT164.
In ACT 164, the processor 401a checks whether check-in completion has been notified. Then, if the processor 401a cannot confirm the corresponding notification, the processor 401a determines NO and proceeds to ACT165.
As ACT 165, the processor 401a checks whether a check-in error has been notified. Then, if the processor 401a cannot confirm the corresponding notification, the processor 401a determines NO and returns to ACT164.
In this manner, the processor 401a waits for notification of check-in completion or error as ACT 164 and ACT 165. If the wireless communication unit 401d receives notification data for error notification in ACT188 in FIG. 14 or ACT203 in FIG. 15, the processor 401a determines YES in ACT165, and proceeds to ACT166.

In ACT 166, the processor 401a displays an error screen on the touch panel 401e. The error screen is a screen designed to notify customers that check-in is not possible. Note that, in response to the error notification in ACT 188 in FIG. 14, the processor 401a notifies you that you cannot check in because the store is crowded, and also displays an error screen that prompts you to try checking in after a while. Display. The processor 401a returns to the standby state in ACT 162 when an instruction to cancel the display of the error screen is given, for example, by operating a GUI element displayed on the error screen.

On the other hand, if the wireless communication unit 401d receives notification data for notification of check-in completion, which is transmitted from the mobile controller 3 by the processor 31 executing ACT204 in FIG. It is determined as YES. Although not shown in FIG. 15, the processor 401a then requests registration, quantity change, cancellation, or payment to the mobile controller 3 in the same manner as the processor 301 described above, depending on the customer's operation, A barcode screen is displayed on the touch panel 401e. However, the customer's operations received by the processor 401a may be different from those received by the processor 301. For example, the scanner 402 reads a barcode displayed on a product to be registered as a purchased product.
In the mobile controller 3 and the virtual POS server 2, even in the intermediary processing and transaction processing using the cart terminal 400 as the target terminal, the above-mentioned request or accounting machine 5 Executes processing in response to transfer requests from.

As described above, the processor 21 executes transaction processing as information processing for processing transactions in response to instructions from different target terminals.

The processor 401a at the cart terminal 400 requests payment as in ACT 139 in FIG. 12, or displays the checkout barcode screen as in ACT 140, and then proceeds to ACT 171 in FIG.
As ACT 171, the processor 401a waits for notification of payment completion. Then, the processor 401a determines YES if the notification of payment completion as described above is given by ACT 224 in FIG. 16 or the notification of payment completion as described above from the accounting machine 5, and proceeds to ACT 172.
As ACT 172, the processor 401a displays an end screen on the touch panel 401e. The end screen is, for example, a screen that notifies the customer that the transaction has ended.
As ACT 173, the processor 401a clears various data temporarily used regarding the current shopping. Thereafter, the processor 401a returns to the standby state of ACT161.

For example, a customer who completes check-in may stop shopping and leave the store without completing the payment or specifying to cancel as described above. This is considered a prohibition regarding the use of POS services. However, there is a risk that customers will do so.
When the customer acts as described above, the processor 31 in the mobile controller 3 continues the standby state of ACT205 to ACT208. If the elapsed time from ACT204, ACT212 or ACT216 in FIG. 16 to the standby state of ACT205 to ACT208 reaches a predetermined time limit, the processor 31 determines YES in ACT208, Proceed to ACT228. At this time, the processor 31 detects a state in which no operation is received for a predetermined period of time as a no-operation state. As the processor 31 executes information processing based on the transaction management application AP31, the computer having the processor 31 as its core functions as a detection means.
Note that the time limit is determined, for example, by the administrator of the store system 100 for each store. The processor 31 inputs a time limit according to the operation of the administrator or the like, and stores the time limit in the main memory 32 or the auxiliary storage unit 33. Note that if the time limit is already stored in the main memory 32 or the auxiliary storage unit 33, the processor 31 overwrites it with the newly input time limit. However, the time limit may be determined by, for example, the creator of the transaction management application AP31, and may be fixedly applied to each store.

As ACT 228, the processor 31 instructs the virtual POS server 2 to terminate the transaction processing regarding the target terminal. For example, the processor 31 sends instruction data for a termination instruction to the virtual POS server 2 from the communication interface 34 to the in-store communication network 7. The processor 31 includes identification data for identifying that the instruction is a termination instruction in the instruction data. The processor 31 finds the data record DR1 in which the terminal code of the target terminal is set in the field F11 from the transaction management database DB31, and includes the transaction code set in the field F13 of the corresponding data record DR1 in the instruction data.

When the above instruction data is transmitted to the virtual POS server 2 by the in-store communication network 7, it is received by the communication interface 24. At this time, the processor 21 should be in the standby state of ACT302 to ACT306 in FIG. 18 in the transaction processing in which the transaction identified by the transaction code included in the instruction data is to be processed. Therefore, the processor 21 determines YES in ACT 306 regarding the transaction processing, and proceeds to ACT 318 in FIG. 19 .
In ACT 318, the processor 21 updates the transaction database DB21 to end the management of the transaction being processed. For example, the processor 21 deletes the data record including the transaction code of the transaction to be processed from the transaction database DB21.
As ACT 319, the processor 21 notifies the mobile controller 3 of the termination. The processor 21 includes the transaction code of the transaction to be processed in the notification data for this termination notification. The processor 21 then ends the transaction process. In other words, the processor 21 forcibly ends the transaction process, although the payment has not been completed.
In this way, the transaction process is completed in accordance with instructions from the processor 31 of the mobile controller 3. As the processor 31 executes information processing based on the transaction management application AP31, the computer with the processor 31 as a central part functions as a control means.

After the processor 31 in the mobile controller 3 instructs the end at ACT228 in FIG. 15, the process proceeds to ACT229.
As ACT 229, the processor 31 waits for the completion notification. If the processor 31 is notified of the termination from the virtual POS server 2 as described above, it determines YES and proceeds to ACT230.

As ACT 230, the processor 31 instructs a predetermined notification destination to execute a notification operation. The processor 31 then ends the mediation process.
The notification operation is an operation for notifying a predetermined reporting destination that the transaction processing has been forcibly terminated.
For example, when the transaction process is forcibly terminated as described above, it is assumed that the customer leaves the store with the cart terminal 400, which is the target terminal of the transaction process, left in the store. In other words, the shopping cart C1 containing the products is left in the store without being used by any customer. The cart terminal 400 attached to this shopping cart C1 becomes in a state where it can start a new transaction by forcibly terminating the transaction process, but since the shopping cart C1 contains products, the new customer cannot use it. Can not. Therefore, the processor 31 notifies the store clerk of the above-mentioned forced termination by causing the clerk's terminal to perform a notification operation. In response to this notification, the store clerk can make the shopping cart C1 usable by, for example, finding the shopping cart C1 that was notified in the store, removing the products contained therein, and returning it to the storage area. .

Furthermore, for example, the transaction process may be forcibly terminated even though the customer is shopping, due to circumstances such as the customer using the terminal that was subject to the forcibly terminated transaction processing being taking a break in the store's rest area. There may also be cases. Therefore, the processor 31 notifies the customer of the forcible termination by causing the target terminal of the forcibly terminated transaction processing to perform a notification operation. This notification allows the customer to know that they need to start shopping again from the beginning. Note that if there is a concern that such a situation may occur, the processor 31 determines whether the duration of the standby state in ACT205 to ACT208 in FIG. 15 has passed a predetermined time shorter than the time limit. Accordingly, the target terminal may be instructed to perform an alarm operation to inform the customer that the process will be forcibly terminated if no operation is performed. Then, in response to this instruction, the processor 301 or processor 401a in the target terminal may execute a predetermined alarm operation as described above.
Note that the processor 31 may instruct each of a plurality of terminals to execute the notification operation.
In this manner, the processor 31 instructs a predetermined terminal to perform the notification operation, thereby reporting to a predetermined destination. As the processor 31 executes information processing based on the transaction management application AP31, the computer having the processor 31 as its core functions as a reporting means.

As described above, in the transaction processing system of this embodiment, if the target terminal becomes inoperable while the processor 21 is processing a transaction in the virtual POS server 2, the transaction processing is forcibly terminated. Therefore, the resources used for processing the transaction can be released and used for new transactions. This can reduce the possibility of a situation in which it is not possible to start using a new terminal device.

This embodiment can be modified in various ways as follows.
The virtual POS server 2 may directly receive requests from the user terminal 300 and the cart terminal 400 without providing the mobile controller 3. The management process may be executed by the processor 21 in the virtual POS server 2. Further, in this case, the processor 21 executes processing corresponding to ACT208 in FIG. 15 instead of ACT306 in FIG. 18, for example. Further, the processor 21 executes processing corresponding to ACT230 in FIG. 15 instead of ACT319 in FIG. 19, for example.

The detection of the no-operation state may be executed by the processor 301 and the processor 401a in the user terminal 300 and the cart terminal 400. In the case of the processor 301, for example, it is sufficient to check whether the duration of the standby state in ACT113 to ACT116 in FIG. 10 has exceeded the time limit. Furthermore, if it is the processor 401a, it is only necessary to check whether the duration of the standby state corresponding to ACT113 to ACT116 in FIG. 10 during the cart UI processing, for example, has exceeded the time limit. If the no-operation state is detected by the user terminal 300 and the cart terminal 400, the processor 301 and processor 401a may also instruct the end of transaction processing in response to the detection of the no-operation state. .

The detection of the no-operation state can be arbitrarily changed, for example, by counting the number of times ACT 208 is repeatedly executed, and determining the no-operation state when the number of times exceeds a predetermined limit.

A plurality of virtual POS servers 2 may be provided, and a plurality of transaction processes may be shared and executed by the plurality of virtual POS servers 2. Further, one transaction process may be shared and processed by a plurality of information processing devices. For example, the process for registering purchased products and the process for payment may be executed by separate information processing devices.

Transactions to be processed by the transaction processing system are not limited to sales of products displayed in a store, but may be other types of transactions such as cooking and serving food and drinks.

The terminal device lent to the customer by the store may be carried by the user without being attached to the shopping cart C1, or such a terminal device and the cart terminal 400 may coexist.

Either one of the user terminal 300 and the cart terminal 400 may be used.

Each of the functions realized by the processors 11, 21, 31, 301, and 401a through information processing can be partially or entirely realized by hardware that executes information processing that is not based on a program, such as a logic circuit. be. Further, each of the above functions can also be realized by combining software control with hardware such as the above logic circuit.

Although several embodiments of the invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are included within the scope and gist of the invention, as well as within the scope of the invention described in the claims and its equivalents.
Below, the invention described in the original claims of the present application will be added.
[Additional Note 1] Including a terminal device and at least one information processing device,
an operating means provided in the terminal device and operated by an operator;
a determining means that is provided in one of the information processing devices and performs processing for determining the content of a transaction in accordance with an operation received by the operating means;
a detecting unit provided in one of the terminal device or the information processing device and detecting a non-operation state in which the operation cannot be performed by the operating unit;
provided in one of the terminal device or the information processing device, from when the determining means starts the process for determining the content of one transaction until the determination of the content of the one transaction is completed; control means for controlling the determining means to end the processing regarding the one transaction in response to the detection of the no-operation state by the detecting means;
A transaction processing system equipped with
[Additional Note 2] The detection means detects a state in which the operation cannot be received by the operation means for a predetermined period of time as the no-operation state.
Transaction processing system described in Appendix 1.
[Additional Note 3] Notifying means provided in one of the information processing devices and notifying a predetermined reporting destination that the determining means has terminated the processing without completing it;
The transaction processing system according to Supplementary Note 1 or 2, further comprising:
[Additional Note 4] The terminal device is lent to a customer by the store, and the customer becomes the operator,
The reporting means has an employee of the store as the reporting destination,
Transaction processing system described in Appendix 3.
[Additional note 5] A terminal device equipped with an operating means for receiving operations by an operator, and a registration processing device equipped with a determining means for determining the content of a transaction according to the operation received by the operating means, together with a transaction processing device. configure the system,
detection means for detecting a non-operation state in which the operation cannot be performed by the operation means;
In response to the detection of the no-operation state by the detection means between the time when the determination means starts the process for determining the contents of one transaction and the time when the determination of the contents of one transaction is completed. and control means for controlling the determining means to terminate the processing regarding the one transaction.
[Additional note 6] A terminal device equipped with an operating means for receiving operations by an operator, and a registration processing device equipped with a determining means for determining the content of a transaction according to the operation received by the operating means, together with a transaction processing device. The computer included in the control device that makes up the system,
detection means for detecting a non-operation state in which the operation cannot be performed by the operation means;
In response to the detection of the no-operation state by the detection means between the time when the determination means starts the process for determining the contents of one transaction and the time when the determination of the contents of one transaction is completed. and an information processing program for functioning as a control means for controlling the determination means to terminate the processing regarding the one transaction.

DESCRIPTION OF SYMBOLS 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, 301, 401a... Processor, 12 , 22, 32, 302, 401b... Main memory, 13, 23, 33, 303, 401c... Auxiliary storage unit, 14, 24, 34... Communication interface, 15, 25, 35, 308, 401h... Transmission line, 304, 401e...touch panel, 305,404...camera, 306,401d...wireless communication unit, 307...mobile communication unit, 401f...sound unit, 401g...interface unit, 402...scanner, 403...reader, 100 (100A, 100B)...store System, 200...Relay server, 300...User terminal, 400...Cart terminal, 500...Payment server, 600...Electronic receipt server, 700...Communication network.

Claims (5)

including a terminal device and at least one information processing device,
an operating means provided in the terminal device and operated by an operator;
a determining means that is provided in one of the information processing devices and performs processing for determining the content of a transaction in accordance with an operation received by the operating means;
a detecting means provided in one of the terminal device or the information processing device and detecting a non-operation state in which the operation cannot be performed by the operating means for a predetermined time limit ;
provided in one of the terminal device or the information processing device, from when the determining means starts the process for determining the content of one transaction until the determination of the content of the one transaction is completed; control means for controlling the determining means to end the processing regarding the one transaction in response to the detection of the no-operation state by the detecting means;
a reporting means that is provided in one of the information processing devices and that reports to a predetermined reporting destination that the determining means has terminated the processing without completing it;
provided in one of the information processing devices, and in the case where the operation is not received by the operation means for a predetermined time shorter than the time limit, the processing is completed if no operation is performed; a guide means for guiding the operator that the operation will be terminated without any interruption;
A transaction processing system equipped with The reporting means sets the operator of the terminal device as the reporting destination;
The transaction processing system according to claim 1. The terminal device is lent to a customer by the store, and the customer becomes the operator,
The reporting means has an employee of the store as the reporting destination,
The transaction processing system according to claim 1 or claim 2 . A transaction processing system is constituted by a terminal device equipped with an operating means for receiving operations by an operator, and a registration processing device equipped with a determining means for performing processing for determining the content of a transaction in accordance with the operation received by the operating means. ,
detection means for detecting a non-operation state in which the operation cannot be performed by the operation means for a predetermined time limit ;
In response to the detection of the no-operation state by the detection means between the time when the determination means starts the process for determining the contents of one transaction and the time when the determination of the contents of one transaction is completed. control means for controlling the determining means to terminate the processing regarding the one transaction;
reporting means for notifying a predetermined reporting destination that the determining means has terminated the processing without completing it;
If the operation cannot be performed by the operation means for a predetermined time shorter than the time limit, the operator is informed that if the operation is not performed, the process will be terminated without being completed. a guide means for
A control device comprising: A transaction processing system is constituted by a terminal device equipped with an operating means for receiving operations by an operator, and a registration processing device equipped with a determining means for performing processing for determining the content of a transaction according to the operation received by the operating means. A computer included in the control device,
detection means for detecting a non-operation state in which the operation cannot be performed by the operation means for a predetermined time limit ;
In response to the detection of the no-operation state by the detection means between the time when the determination means starts the process for determining the contents of one transaction and the time when the determination of the contents of one transaction is completed. control means for controlling the determining means to terminate the processing regarding the one transaction;
reporting means for notifying a predetermined reporting destination that the determining means has terminated the processing without completing it;
If the operation cannot be performed by the operation means for a predetermined time shorter than the time limit, the operator is informed that if the operation is not performed, the process will be terminated without being completed. a guide means for
An information processing program that makes it work.