Transaction processing device, transaction processing method, and program recording medium

Abstract

A transaction processing device of an embodiment includes a first registration unit (31), a linkage unit (31), and a second registration unit (31). The first registration unit (31) stores a content of a transaction related to a user in response to a request from a first terminal made by an operation of the user. The linkage unit (31) links the process of storing the content of the transaction related to the user performed by the first registration unit to a second terminal. When the content of the transaction related to the user is sent from the second tenninal, the second registration unit (31) stores the content of the transaction sent from the second terminal as the content of the transaction related to the user in the first registration unit by using the association.

Description

Transaction processing device, transaction processing method, and program recording medium

[0001] FIELD Embodiments of the present invention relate to a transaction processing device, a transaction processing method, and a program recording medium.

[0002] There are known transaction processing systems that register purchased items in response to instructions from customers using terminals carried by the customers. However, for various reasons, such as difficulty in reading barcodes, the absence of barcodes on the items, or the customers not knowing how to operate the system, customers may have difficulty registering some items. For these reasons, it has been desirable to have a store clerk temporarily perform operations related to registering transaction details, such as purchased items, on behalf of the customer.

[0003] Japanese Patent Application Publication No. 2019-149176

[0004] The problem that this invention aims to solve is to provide a transaction processing device, a transaction processing method, and a program storage medium that can temporarily link the processing related to the registration of transaction details, which is performed in response to a request from a terminal used by a customer, with a terminal used by a store clerk.

[0005] FIG. 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 circuit configuration of the store server shown in FIG. 1. FIG. 3 is a block diagram showing the circuit configuration of the virtual POS server shown in FIG. 1. FIG. 4 is a block diagram showing the circuit configuration of the mobile controller shown in FIG. 1. FIG. 5 is a schematic diagram showing the data structure of a data record included in the transaction management database shown in FIG. 4. FIG. 6 is a schematic diagram showing the data structure of a data record included in the linked database shown in FIG. 4. FIG. 7 is a schematic diagram showing the data structure of a data record included in the registration database shown in FIG. 4. FIG. 8 is a block diagram showing the circuit configuration of the user terminal shown in FIG. 1. FIG. 9 is a block diagram showing the circuit configuration of the clerk terminal shown in FIG. 1. FIG. 10 is a flowchart of information processing by the processor shown in FIG. 8. FIG. 11 is a flowchart of information processing by the processor shown in FIG. 8. FIG. 12 is a flowchart of information processing by the processor shown in FIG. 8. FIG. 13 is a flowchart of information processing by the processor shown in FIG. 8. FIG. 14 is a flowchart of transaction processing by the processor shown in FIG. 4. FIG. 15 is a flowchart of transaction processing by the processor shown in FIG. 4. FIG. 16 is a flowchart of transaction processing by the processor shown in FIG. 4. FIG. 17 is a diagram showing an example of a list screen in a state where no purchased items have been registered. FIG. 18 is a diagram showing an example of a registration screen. FIG. 19 is a diagram showing an example of a list screen in a state where purchased items have been registered. FIG. 20 is a diagram showing an example of a linkage screen. FIG. 21 is a flowchart of information processing by the processor shown in FIG. 9. FIG. 22 is a flowchart of linkage processing by the processor shown in FIG. 4. Embodiment

[0006] A transaction processing device according to an embodiment includes a first registration unit, a linking unit, and a second registration unit. The first registration unit performs a process of storing transaction details related to a user in response to a request from a first terminal operated by the user. The linking unit stores an association between the first terminal and a second terminal, thereby linking the process of storing transaction details related to the user performed by the first registration unit to the second terminal. When transaction details related to a user are sent from the second terminal, the second registration unit uses the association between the second terminal and the first terminal to store the transaction details sent from the second terminal in the first storage unit as transaction details related to the user.

[0007] An embodiment of a transaction processing system will be described below with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system according to this embodiment. The transaction processing system includes multiple store systems 100, user terminals 200, clerk terminals 300, and a relay server 400. The multiple store systems 100, user terminals 200, and relay server 400 are capable of communicating with each other via a communication network 500. The clerk terminal 300 may also be capable of communicating with each other via the communication network 500.

[0008] FIG. 1 shows two store systems 100. These store systems 100 are installed in two different stores, Store A and Store B, which use the transaction processing system. There may be three or more stores that use the transaction processing system, with a store system 100 installed in each store. In the following, when it is necessary to distinguish between the store systems 100 installed in each store, the store system 100 installed in Store A will be referred to as store system 100-1, and the store system 100 installed in Store B will be referred to as store system 100-2. The operator operating Store A may be the same as the operator operating Store B, or may be a different operator. When the transaction system is used in another store, the operator operating that store may be the same as the operator operating Store A or Store B, or may be a different operator.

[0009] The user terminal 200 is an information processing device that functions as a user interface for customers who shop at a store using the transaction processing system. The user terminal 200 has a function for wireless communication with the store system 100 and a function for wireless communication with the communication network 500. The user terminal 200 can be a communication terminal with a data communication function, such as a smartphone or tablet computer. The user terminal 200 may be owned by the customer or may be loaned to the customer at the store. The customer is the operator of the user terminal 200. However, the user terminal 200 may also be operated by a store clerk or the like on behalf of the customer. The user terminal 200 is an example of a first terminal. The customer is an example of a user of the first terminal.

[0010] The clerk terminal 300 is an information processing device that functions as a user interface for the clerk. The clerk terminal 300 has a function for wireless communication with the store system 100. A communication terminal with a data communication function, such as a tablet computer, can be used as the clerk terminal 300. The clerk terminal 300 has a barcode scanner 301. The barcode scanner 301 is a reading device that is suitably configured to optically read barcodes that represent product codes. The clerk terminal 300 is an example of a second terminal.

[0011] The relay server 400 relays data communication between the store system 100 and the user terminal 200. The relay server 400 provides a data communication relay function as a cloud service via a communication network 500, for example. The communication network 500 may be, for example, the Internet, a virtual private network (VPN), a local area network (LAN), a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. The communication network 500 typically uses a mobile communication network and the Internet or a VPN.

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

[0013] The store server 1 comprehensively manages multiple transactions that are the subject of transaction processing implemented by the store system 100 as described below. The store server 1 has functions similar to those of an existing POS server, for example. The virtual POS server 2 performs information processing for registering purchased items for each transaction and settling the price of the purchased items in response to external requests. In other words, the virtual POS server 2 virtually implements the functions of an existing POS terminal. The information processing performed by the virtual POS server 2 is customized to accommodate differences in the management policies of each store. In other words, for example, the information processing performed by the store server 1 provided in the store system 100-1 and the information processing performed by the store server 1 provided in the store system 100-2 may differ in part.

[0014] The mobile controller 3 supports the virtual POS server 2 in performing the above information processing using the user terminal 200 as a user interface device. The communication server 4 performs communication processing for the store server 1, virtual POS server 2, mobile controller 3, and payment machine 5 to exchange data with the relay server 400 and the like via the communication network 500.

[0015] The payment machine 5 calculates the price of each purchased item for each transaction managed by the virtual POS server 2 and processes the payment for the customer. The payment methods available to the payment machine 5 for the above-mentioned payment may include all or any of well-known payment methods, such as cash payment, credit card payment, electronic money payment, points payment, and code payment. Code payment is also referred to as mobile payment or smartphone payment. The payment machine 5 may be operated by either a store clerk or a customer. The payment machine 5 may be, for example, a self-service payment machine used in an existing semi-self-service POS system. The payment machine 5 may also have a function for processing information to register items as purchased items. In this case, the payment machine 5 may be, for example, a face-to-face POS terminal used in an existing POS system or a self-service POS terminal used in an existing self-service POS system.

[0016] The access point 6 performs communication processing to enable the user terminal 200 to access the in-store communication network 7 via wireless communication. The access point 6 may be, for example, a well-known communication device that performs wireless communication according to the IEEE 802.11 standard. The access point 6 is installed in the store so that the user terminal 200 can communicate wirelessly from anywhere on the store's sales floor. Depending on the size of the store, multiple access points 6 may be installed in one store system 100. The in-store communication network 7 may be the Internet, VPN, LAN, public communication network, mobile communication network, etc., used alone or in appropriate combination. However, the in-store communication network 7 is typically a LAN.

[0017] In a store equipped with the store system 100, a two-dimensional code TCI for check-in is posted near the entrance, and a two-dimensional code TCO for check-out is posted near the exit. The two-dimensional code TCI represents check-in data for check-in. The two-dimensional code TCO represents check-out data for check-out. The check-in data and check-out data differ from store to store. Therefore, when it is necessary to distinguish between the two-dimensional codes TCI and TCO for store A and the two-dimensional codes TCI and TCO for store B, the codes for store A are represented as two-dimensional codes TCIA and TCOA, and the codes for store B are represented as two-dimensional codes TCIB and TCOB.

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

[0019] (4) The name of the business that operates the store in which the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TCIA represents the name of the business that operates store A. The check-in data represented by the two-dimensional code TCIB represents the name of the business that operates store B. (5) The name of the store in which the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TCIA represents the name of store A. The check-in data represented by the two-dimensional code TCIB represents the name of store B. (6) A flag for distinguishing between the two-dimensional code TCI and the two-dimensional code TCO. The flag in the check-in data is set to a state that indicates that it is check-in data. The state is, for example, "1." The flag is common to all two-dimensional codes TCI.

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

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

[0022] (13) An identification number for the security method used by the access point 6. For example, the identification number is assigned "1" for WPA2-PSK, "2" for WPA-PSK, and "3" for WEP. For example, if the access point 6 included in the store system 100-1 uses WPA2-PSK as its security method, the check-in data represented by the two-dimensional code TCIA will indicate "1" as the identification number. For example, if the access point 6 included in the store system 100-2 uses WPA-PSK as its security method, the check-in data represented by the two-dimensional code TCIB will indicate "2" as the identification number. (14) A flag for identifying whether to report an error when the user terminal 200 fails to connect to the relay server 400 or to continue operation without reporting an error. For example, in store A, if the user terminal 200 is set to report an error when it fails to connect to the relay server 400, the check-in data represented by the two-dimensional code TCIA will indicate "1" as the flag. Also, for example, in store B, if the user terminal 200 is configured to continue operation even if it fails to connect to the relay server 400, the check-in data represented by the two-dimensional code TCIB will indicate, for example, "0" as the flag. (15) Identification number of the transmission mode related to the status of the user terminal 200. The transmission modes include, for example, a first mode, a second mode, and a third mode. The identification numbers of the transmission modes are, for example, "1" for the first mode, "2" for the second mode, and "3" for the third mode. In the first mode, the status of the user terminal 200 is transmitted to the relay server 400. In the second mode, the status of the user terminal 200 is transmitted to the store system 100. In the third mode, the status of the user terminal 200 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 TCIA will indicate, for example, "1" as the identification number. Also, for example, if the second mode is applied as the transmission mode in store B, the check-in data represented by the two-dimensional code TCIB will indicate "2" as the identification number.

[0023] (16) Identification number of the transmission mode for the log file that accumulates the log data of the user terminal 200. The transmission modes include, for example, first mode, second mode, third mode, and fourth mode. The identification numbers for the transmission modes are, for example, "1" for the first mode, "2" for the second mode, "3" for the third mode, and "4" for the fourth mode. In the first mode, the log file is transmitted only to the relay server 400. In the second mode, the log file is transmitted only to the store system 100. In the third mode, the log file is transmitted to both the store system 100 and the relay server 400. In the fourth mode, the log file is not transmitted. For example, in store A, if the first mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TCIA will have the identification number "1." In store B, if the second mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TCIB will have the identification number "2." (17) The host name or IP address to be used when sending the log file to Relay Server 400 via communication network 500 by FTP (file transfer protocol). (18) The user name to be used when sending the log file to Relay Server 400 via communication network 500 by FTP.

[0024] (19) A password used when transmitting the log file to relay server 400 via communication network 500 by FTP. (20) A path name of the log file to be transmitted to relay server 400 via communication network 500 by FTP. (21) A flag for identifying whether or not to delete the check digit of a UPC (universal product code), which is a type of product code. For example, in store A, if the check digit is not to be deleted, the check-in data represented by two-dimensional code TCIA indicates, for example, "1" as the flag. Also, in store B, if the check digit is to be deleted, the check-in data represented by two-dimensional code TCIB indicates, for example, "0" as the flag.

[0025] (22) The time until the camera screen on the user terminal 200 is automatically changed. The check-in data represented by the two-dimensional code TCIA represents the time that has been preset for store A as the relevant time. The check-in data represented by the two-dimensional code TCIB represents the time that has been preset for store B as the relevant time. (23) The timeout time when the user terminal 200 communicates with the store system 100 via the access point 6. The check-in data represented by the two-dimensional code TCIA represents the time that has been preset for store A as the relevant time. The check-in data represented by the two-dimensional code TCIB represents the time that has been preset for store B as the relevant time. (24) The number of retries allowed when communication between the user terminal 200 and the store system 100 via the access point 6 times out. The check-in data represented by the two-dimensional code TCIA represents the number of times that has been preset for store A as the relevant time. The check-in data represented by the two-dimensional code TCIB represents the number of times that has been preset for store B as the relevant time.

[0026] (25) Timeout time when the user terminal 200 communicates with the store system 100 via the relay server 400. The check-in data represented by the two-dimensional code TCIA represents the time that has been preset for store A. The check-in data represented by the two-dimensional code TCIB represents the time that has been preset for store B. (26) The number of retries allowed when communication between the user terminal 200 and the store system 100 via the relay server 400 times out. The check-in data represented by the two-dimensional code TCIA represents the number of times that has been preset for store A. The check-in data represented by the two-dimensional code TCIB represents the number of times that has been preset for store B. (27) Authentication data used in the authentication process to authenticate the declaration of completion of confirmation for a transaction involving products that require confirmation by a store clerk. The check-in data represented by the two-dimensional code TCIA represents the authentication data that has been preset for store A. The check-in data represented by the two-dimensional code TCIB represents the authentication data that has been preset for store B. It is preferable that the authentication data be set differently for each store, but the same authentication data may be set for different stores.

[0027] (28) Data for identifying the operating mode of the store system 100. For example, if the store system 100-1 is set to a normal mode in which the transaction processing system is normally operated, the check-in data represented by the two-dimensional code TCIA represents, for example, "1." Alternatively, if the store system 100-2 is set to a demo mode in which the transaction processing system is demo-operated, the check-in data represented by the two-dimensional code TCIB represents, for example, "2." (29) Data for identifying the mode of data transfer to the payment machine 5. For example, if the store system 100-1 is set to a mode in which the payment machine 5 requests data transfer from the mobile controller 3, the check-in data represented by the two-dimensional code TCIA represents, for example, "1." Alternatively, if the store system 100-2 is set to a mode in which data is transferred from the mobile controller 3 to the payment machine 5 without a request from the payment machine 5, the check-in data represented by the two-dimensional code TCIB represents, for example, "2." (30) A flag indicating whether or not payment by code payment method via operation on user terminal 200 is permitted. For example, if code payment is permitted at store A, the check-in data represented by two-dimensional code TCIA indicates, for example, "1" as the flag. Also, for example, if code payment is not permitted at store B, the check-in data represented by two-dimensional code TCIB indicates, for example, "0" as the flag.

[0028] (31) A flag for identifying whether or not registration of a product with a purchaser age restriction (hereinafter referred to as an "age-restricted product") is permitted on the user terminal 200. For example, if store A permits registration of an age-restricted product on the user terminal 200, the check-in data represented by the two-dimensional code TCIA indicates, for example, a "1" as the flag. For example, if store B does not permit code payment, the check-in data represented by the two-dimensional code TCIB indicates, for example, a "0" as the flag. (32) Data for identifying the input mode of the point member's membership code. For example, if store system 100-1 is set to a mode in which the membership code is manually entered, the check-in data represented by the two-dimensional code TCIA indicates, for example, a "1" as the data. For example, if store system 100-2 is set to a mode in which the membership code is entered by reading a barcode, the check-in data represented by the two-dimensional code TCIB indicates, for example, a "2" as the data. (33) A flag for identifying whether confirmation by a store clerk is required when entering a point member's membership code when the mode for manually entering the membership code is set. For example, if confirmation is required at store A, the check-in data represented by the two-dimensional code TCIA indicates, for example, a "1" as the flag. Also, for example, if confirmation is not required at store B, the check-in data represented by the two-dimensional code TCIB indicates, for example, a "0" as the flag.

[0029] (34) A threshold for checking the remaining battery charge of the user terminal 200 at check-in. The threshold is set for each store or business. For example, if the business operating store A sets the threshold at "20%," the check-in data represented by the two-dimensional code TCIA represents the threshold at, for example, "20." Furthermore, if store B sets the threshold at "25%,," the check-in data represented by the two-dimensional code TCIB represents the threshold at, for example, "25." The above are examples of information represented by check-in data. However, the check-in data may not include all of the various pieces of information shown above. Furthermore, the check-in data may represent information other than the various pieces of information shown above.

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

[0031] The processor 11 corresponds to the central part of the computer. The processor 11 executes information processing to realize various functions of the store server 1 in accordance with information processing programs such as an operating system and application programs. The processor 11 may be a processing circuit such as a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a programmable logic device (e.g., a simple programmable logic device (SPLD), a complex programmable logic device (CPLD), or a field programmable gate array (FPGA)). The processor 11 is not limited to being configured as a single processing circuit, and may also be configured as a combination of multiple processing circuits. The same applies to other processors according to this embodiment.

[0032] The main memory 12 may be a volatile memory (random access memory) or a non-volatile memory (read-only memory, non-volatile random access memory). The main memory 12 stores information processing programs and data necessary for information processing. The processor 11 realizes a predetermined function by reading and executing the program stored in the main memory 12. Note that instead of storing the program in the main memory 12, the program may be configured to be directly embedded in the processor 11. In this case, the processor 11 realizes a predetermined function by reading and executing the program embedded therein. Furthermore, the predetermined function may not only be realized by the processor 11 executing a program, but also by a combination of logic circuits.

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

[0034] The communication interface 14 performs data communication with each unit connected to the in-store communication network 7 in accordance with a predetermined communication protocol. For example, a well-known communication device for a LAN can be used as the communication interface 14. The transmission path 15 includes an address bus, a data bus, a control signal line, etc., and transmits data and control signals exchanged between each connected unit. The transmission path 15 may be a serial transmission path or a parallel transmission path.

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

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

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

[0038] One of the databases included in the database group DBAA is a clerk terminal database. The clerk terminal database represents terminal codes as identifiers for identifying clerk terminals 300 used in the store. For example, the clerk terminal database is preset with the terminal codes of terminals designated as clerk terminals 300 in the store. Alternatively, the clerk using the clerk terminal 300 may be authenticated, and the terminal code of the clerk terminal 300 that is confirmed to be used by a predetermined clerk may be set in the clerk terminal database. When a clerk terminal 300 accesses the store system 100, the database group DBAA can be used to determine whether the accessed terminal is a terminal designated for use by the clerk. The terminal code of the clerk terminal 300 is an example of a second terminal identifier. The terminal code of the clerk terminal 300 may be in any form as long as it is information that can identify the clerk terminal 300.

[0039] In addition, the database group DBAA may include various databases such as those managed by POS servers in existing POS systems. The types of databases included in the database group DBAA, or the types of data and structures contained in those databases, may be determined for each store.

[0040] 3 is a block diagram showing the main circuit configuration of the virtual POS server 2. The virtual POS server 2 includes a processor 21, 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 with each other via the transmission path 25. The processor 21, main memory 22, and auxiliary storage unit 23 are connected via the transmission path 25 to form a computer for controlling the virtual POS server 2. The functions of the processor 21, main memory 22, auxiliary storage unit 23, communication interface 24, and transmission path 25 are generally the same as those of the processor 11, main memory 12, auxiliary storage unit 13, communication interface 14, and transmission path 15, so a description thereof will be omitted.

[0041] However, the auxiliary storage unit 23 stores a virtual POS application APBA instead of the store management application APAA. The virtual POS application APBA is an application program that, when executed by the processor 21, describes the information processing required to implement the functions of the virtual POS server 2. A separate virtual POS application APBA may be created to suit the store management policies of each store or each store operator. For example, if store A offers a discount service that is not offered at store B, the virtual POS application APBA used in store system 100-1 would describe the information processing required to implement that discount service, while the virtual POS application APBA used in store system 100-2 would not. For example, the virtual POS application APBA is provided separately from hardware in which the virtual POS application APBA is not stored in the auxiliary storage unit 23. The virtual POS application APBA is then written to the auxiliary storage unit 23 in response to an operator's operation. Alternatively, the virtual POS server 2 may be provided with the virtual POS application APBA stored in the auxiliary storage unit 23. The virtual POS application APBA may be provided by being stored on a removable computer-readable storage medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network.

[0042] Furthermore, a portion of the storage area of ​​the auxiliary memory unit 23 is used to store a transaction database DBBA instead of the database group DBAA. The transaction database DBBA is a collection of data records associated with transactions with customers shopping in the store. The data records of the transaction database DBBA include a transaction code and product data related to products registered as purchased products. The transaction code is a unique identification code assigned to each transaction to identify each transaction. The product data represents the product code, product name, price, quantity, etc. The structure of the transaction database DBBA may be individually determined to suit the store management policy of each store or each business operator operating the store. The product data related to purchased products is an example of the content of a transaction related to a user. The transaction code is an example of a transaction identifier that identifies a purchase (transaction) of a product by a customer (user). The transaction code may be in any form as long as it can uniquely identify a transaction. A portion of the storage area of ​​the auxiliary memory unit 23 is an example of a first memory section.

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

[0044] However, the auxiliary storage unit 33 stores a registration assistance app APCA instead of the store management app APAA. The registration assistance app APCA is an application program that, when executed by the processor 31, describes information processing (described below) for assisting in the registration of purchased items. The registration assistance app APCA is common to each store system 100. However, various settings for information processing based on the registration assistance app APCA may be customized for each store system 100. For example, hardware without the registration assistance app APCA stored in the auxiliary storage unit 33 and the registration assistance app APCA may be provided separately. The registration assistance app APCA is then written into the auxiliary storage unit 33 in response to an operator's operation. Alternatively, the mobile controller 3 may be provided with the registration assistance app APCA stored in the auxiliary storage unit 33. The registration assistance app APCA may be provided by being stored on a removable computer-readable storage medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network.

[0045] Furthermore, part of the storage area of ​​the auxiliary storage unit 33 is used as an area for storing the transaction management database DBCA, the link database DBCB, and the registration database DBCC in place of the database group DBAA. The structures of the transaction management database DBCA, the link database DBCB, and the registration database DBCC are common to each store system 100.

[0046] 5 is a schematic diagram showing the data structure of a data record DRA contained in the transaction management database DBCA. The transaction management database DBCA is a collection of data records DRA associated with the user terminals 200 used by customers in the store. Therefore, when there is one customer using the user terminal 200 in the store, the transaction management database DBCA contains one data record DRA. On the other hand, when there are no customers using the user terminal 200 in the store, the transaction management database DBCA does not contain any data record DRA. The data record DRA contains fields FAA, FAB, and FAC.

[0047] Field FAA is set with a terminal code, which is an identifier for identifying the associated user terminal 200. The terminal code may be, for example, a unique identification code assigned to each communication terminal used as the user terminal 200 to identify each individual communication terminal. Alternatively, the terminal code may be, for example, an identification code assigned to a smartphone POS app (described later) when the smartphone POS app is installed on the user terminal 200. The terminal code of the user terminal 200 is an example of a first terminal identifier. The terminal code of the user terminal 200 may be in any form as long as it can identify the user terminal 200. Field FAB is set with a membership code, which is an identifier for identifying a customer using the associated user terminal 200. Field FAC is set with a transaction code, which is an identifier for identifying a transaction performed using the associated user terminal 200. Data record DRA is an example of an association between a first terminal and a transaction. Furthermore, a portion of the memory area of ​​the auxiliary memory unit 33 that stores the transaction management database DBCA is an example of a second memory section.

[0048] 6 is a schematic diagram showing the data structure of a data record DRB contained in the linked database DBCB. As will be described later, the linked database DBCB is a collection of data records DRB associated with clerk terminals 300 that are linked to the process of storing transaction details in response to a request from the user terminal 200. Therefore, when there is only one linked clerk terminal 300, the linked database DBCB contains only one data record DRB. On the other hand, when there are no clerk terminals 300 linked to the user terminal 200, the linked database DBCB does not contain any data record DRB. The data record DRB contains fields FBA and FBB.

[0049] Field FBA is set with the terminal code of the associated clerk terminal 300. Field FBB is set with the terminal code of the user terminal 200 with which the associated clerk terminal 300 is linked. Data record DRB is an example of an association between a user terminal 200 (first terminal) and a clerk terminal 300 (second terminal). In addition, a portion of the memory area of ​​auxiliary memory unit 33 that stores linked database DBCB is an example of a third memory section.

[0050] 7 is a schematic diagram showing the data structure of a data record DRC contained in a registration database DBCC. The registration database DBCC is a collection of data records DRC associated with transactions with customers shopping around the store. Each data record DRC includes fields FCA and FCB. The data record DRC may also include fields FCC, FCD, etc.

[0051] Field FCA contains the transaction code of the associated transaction. This transaction code is the same as the transaction code set in field FAB of data record DRA associated with the user terminal 200 used in the associated transaction. Field FCB contains registration data regarding the attempted product registration for the associated transaction. The registration data is described below.

[0052] The data record DRC includes fields following field FCC when an attempt is made to register two or more purchase items for an associated transaction. The fields following field FCC are also set with the same registration data as field FCB.

[0053] 8 is a block diagram showing the main circuit configuration of the user terminal 200. The user terminal 200 includes a processor 201, a main memory 202, an auxiliary storage unit 203, a touch panel 204, a camera 205, a sound unit 206, a group of sensors 207, a wireless communication unit 208, a mobile communication unit 209, and a transmission path 210. The processor 201, the main memory 202, the auxiliary storage unit 203, the touch panel 204, the camera 205, the sound unit 206, the group of sensors 207, the wireless communication unit 208, and the mobile communication unit 209 are capable of communicating with each other via the transmission path 210. The processor 201, the main memory 202, and the auxiliary storage unit 203 are connected via the transmission path 210 to form a computer for controlling the user terminal 200. The functions of the processor 201, main memory 202, auxiliary storage unit 203 and transmission path 210 are roughly the same as those of the processor 11, main memory 12, auxiliary storage unit 13 and transmission path 15, so a description thereof will be omitted.

[0054] The touch panel 204 functions as an input device and a display device for the user terminal 200. The camera 205 includes an optical system and an image sensor, and generates image data representing an image within the field of view formed by the optical system using the image sensor. The sound unit 206 outputs various sounds such as voice and melodies. The sensor group 207 includes various sensors such as an angular velocity sensor and a GPS (global positioning system) sensor.

[0055] The wireless communication unit 208 exchanges data with the access point 6 via wireless communication in accordance with a wireless communication protocol. As the wireless communication unit 208, for example, a well-known communication device conforming to the IEEE 802.11 standard can be used. The mobile communication unit 209 is an interface for data communication via the communication network 500. As the mobile communication unit 209, for example, a well-known communication device for performing data communication via a mobile communication network can be used.

[0056] The auxiliary storage unit 203 stores the smartphone POS app APDA, which is one of the information processing programs. The smartphone POS app APDA is an application program that, when executed by the processor 201, describes the information processing described below for causing the user terminal 200 to function as a user interface for customers of the store system 100. The smartphone POS app APDA is shared by multiple user terminals 200.

[0057] 9 is a block diagram showing the main circuit configuration of the clerk terminal 300. In addition to the barcode scanner 301, the clerk terminal 300 includes a processor 302, a main memory 303, an auxiliary storage unit 304, a touch panel 305, a sound unit 306, a wireless communication unit 307, and a transmission path 308. The processor 302 is capable of communicating with the barcode scanner 301, the main memory 303, the auxiliary storage unit 304, the touch panel 305, the sound unit 306, and the wireless communication unit 307 via the transmission path 308. The processor 302, the main memory 303, and the auxiliary storage unit 304 are connected via the transmission path 308 to form a computer for controlling the clerk terminal 300. The functions of the processor 302, main memory 303, auxiliary storage unit 304, touch panel 305, sound unit 306, wireless communication unit 307 and transmission path 308 are generally the same as those of the processor 11, main memory 12, auxiliary storage unit 13, touch panel 204, sound unit 206, wireless communication unit 208 and transmission path 15, so their explanation will be omitted.

[0058] The auxiliary storage unit 304 stores the clerk terminal application APEA, which is one of the information processing programs. The clerk terminal application APEA is an application program that describes the information processing described below, which is executed by the processor 302 to cause the clerk terminal 300 to function as a user interface for clerks in the store system 100. The clerk terminal application APEA is used in common by all the clerk terminals 300.

[0059] The hardware of the clerk terminal 300 may be, for example, a general-purpose tablet computer. The clerk terminal app APEA may be provided separately from the hardware in a state where the clerk terminal app APEA is not stored in the auxiliary storage unit 304, or in a state where a different version of the same application program is stored in the auxiliary storage unit 304. In this case, the clerk terminal 300 is configured by writing the clerk terminal app APEA to the auxiliary storage unit 304 in response to an operation by an arbitrary worker. The clerk terminal 300 may also be provided with the clerk terminal app APEA stored in the auxiliary storage unit 304. The clerk terminal app APEA may be provided by being recorded on a removable recording medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network.

[0060] Next, the operation of the transaction processing system configured as described above will be described. Note that the contents of the various processes described below are merely examples, and it is possible to change the order of some of the processes, omit some of the processes, or add other processes as appropriate. For example, in the following description, in order to clearly explain the characteristic operations of this embodiment, explanation of some of the processes will be omitted. For example, if some kind of error occurs, processing may be performed to deal with the error, but a description of some of such processing will be omitted.

[0061] The service provided to customers through the operation of the transaction processing system described below is referred to as the smartphone POS service. To use the smartphone POS service, the user terminal 200 exchanges data with the store system 100. Whether wireless communication with the access point 6 or wireless communication with the communication network 500 is used for this communication is determined by the status of a flag included in the check-in data. For simplicity's sake, however, the following description will focus on the case where only wireless communication with the access point 6 is used. Furthermore, the status of a flag included in the check-in data determines whether data transfer from the virtual POS server 2 to the payment machine 5 to complete a transaction is performed in a mode where the payment machine 5 requests data transfer from the mobile controller 3, or in a mode where data is transferred from the mobile controller 3 to the payment machine 5 without a request from the payment machine 5. For simplicity's sake, however, the following description will be limited to the case where the mode where data transfer from the payment machine 5 to the mobile controller 3 is used.

[0062] To use the smartphone POS service, a customer installs the smartphone POS app APDA on their own smartphone or other device, making it available as a user terminal 200. Alternatively, the customer may borrow a user terminal 200 from a store, which is configured by installing the smartphone POS app APDA on a tablet computer or other device. The customer then enters any store that has a store system 100, carrying the user terminal 200 with information processing based on the smartphone POS app APDA activated.

[0063] The processor 201 in the user terminal 200 executes the smartphone POS app APDA to perform predetermined information processing. Figures 10, 11, 12, and 13 are flowcharts of the information processing performed by the processor 201 when the processor 201 executes the smartphone POS app APDA. First, in ACT 101 shown in Figure 10, the processor 201 generates image data for the main menu screen to be displayed on the touch panel 204. The main menu screen is used to specify one of several processes to be performed based on the smartphone POS app APDA. The main menu screen includes multiple graphical user interface (GUI) elements, including a GUI element for specifying the start of shopping. The GUI elements are, for example, soft keys.

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

[0065] When a customer enters a store and starts shopping, the customer performs a predetermined operation on the main menu screen to specify the start of shopping. When the operation to specify the start of shopping is detected, for example, on the touch panel 204, the processor 201 determines YES in ACT 102 and proceeds to ACT 104. In ACT 104, the processor 201 generates image data of a check-in scan screen to be displayed on the touch panel 204 so that the check-in scan screen is displayed on the touch panel 204. The check-in scan screen is a screen that prompts the customer to read the check-in two-dimensional code TCI. The processor 201, for example, activates the camera 205, and generates a scan screen by superimposing a text message prompting the customer to read the two-dimensional code TCI and a line indicating the position where the two-dimensional code TCI should be held over the image obtained by the camera 205.

[0066] When the scan screen is displayed on the touch panel 204, the customer points the camera 205 toward the two-dimensional code TCI posted near the store entrance so that the two-dimensional code TCI is reflected on the scan screen. In ACT 105, the processor 201 waits for the two-dimensional code to be read. At this time, the processor 201 repeatedly analyzes the image obtained by the camera 205 and attempts to read the two-dimensional code. This reading of the two-dimensional code may be performed as a process based on the smartphone POS app APDA, or may be performed as a process based on a separate application program for reading two-dimensional codes. If the two-dimensional code is read, the processor 201 determines YES and proceeds to ACT 106.

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

[0068] If the processor 201 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. In ACT 107, the processor 201 stores the read check-in data in the main memory 202 or the auxiliary storage unit 203.

[0069] In ACT 108, the processor 201 requests check-in from the mobile controller 3. Specifically, the processor 201 establishes wireless communication between the wireless communication unit 208 and the access point 6 based on the data represented in the check-in data. For example, if a customer points the camera 205 at two-dimensional code TCIA in store A, the processor 201 establishes wireless communication with the access point 6 provided in the store system 100-1 based on the check-in data represented by the two-dimensional code TCIA. The processor 201 then transmits request data for requesting check-in to the mobile controller 3 via wireless communication with the access point 6. When wireless communication with the access point 6 provided in the store system 100-1 has been established as described above, the request data is transmitted to the mobile controller 3 provided in the store system 100-1 via the access point 6 provided in the store system 100-1 and the in-store communication network 7. The processor 201 includes identification data for identifying that the request is a check-in request and the terminal code of its own terminal in the request data for requesting check-in. If the customer is a registered user of the smartphone POS service and has a membership code, the processor 201 also includes the membership code in the request data. The membership code is stored, for example, in the auxiliary storage unit 203 of the user terminal 200. The processor 201 may also include other data, such as data for authenticating the customer, in the request data.

[0070] The various requests from the user terminal 200 to the mobile controller 3 described below are realized, as described above, by sending request data including identification data for identifying the reason for the request from the user terminal 200 to the mobile controller 3 via the access point 6 and the in-store communication network 7.

[0071] When request data for requesting check-in is received via the communication interface 34, the processor 31 in the mobile controller 3 starts executing the registration assistance application APCA and performs information processing regarding the transaction with the customer attempting to check in (hereinafter referred to as transaction processing). Figures 14, 15, and 16 are flowcharts of the transaction processing performed by the processor 31 executing the registration assistance application APCA.

[0072] The processor 31 starts the transaction process each time request data for requesting check-in is received by the communication interface 34. If a transaction process started based on another request is already being executed, the processor 31 starts a new transaction process in parallel with the other transaction process. In other words, the processor 31 may execute multiple transaction processes in parallel, each targeting multiple user terminals 200. In the following, when the term "user terminal 200" is simply used, it refers to the user terminal 200 that is the target of the transaction process being explained.

[0073] As shown in ACT 201 of FIG. 14, the processor 31 performs check-in processing. For example, the processor 31 requests the virtual POS server 2 to start a transaction and receives a transaction code. The processor 31 then adds a new data record DRA, in which the terminal code included in the request data is set in field FAA, to the transaction management database DBCA. If the request data includes a membership code, the processor 31 sets the membership code in field FAB of the new data record DRA. The processor 31 then sets the notified transaction code in field FAC of the new data record DRA. This initiates management of transactions performed using the user terminal 200 that requested check-in.

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

[0075] In ACT 202, the processor 31 checks whether the check-in process has been completed normally. If the check-in process could not be completed normally due to some abnormality, the processor 31 determines that the result is NO and proceeds to ACT 203.

[0076] In ACT 203, the processor 31 notifies the user terminal 200 of the error. For example, the processor 31 transmits notification data for the error notification to the user terminal 200 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 in the notification data. The processor 31 may also include an error code indicating the cause of the error in the notification data.

[0077] Note that various notifications from the mobile controller 3 to the user terminal 200, which will be described below, are realized by sending notification data including identification data for identifying the reason for the notification from the mobile controller 3 to the user terminal 200 via the in-store communication network 7 and the access point 6, as described above. Then, the processor 31 ends the transaction processing.

[0078] On the other hand, if the check-in process has been completed successfully, the processor 31 determines YES in ACT 202 and proceeds to ACT 204. In ACT 204, the processor 31 notifies the user terminal 200 that the check-in has been completed.

[0079] In the user terminal 200, after requesting check-in in ACT 108 in FIG. 10 , the processor 201 proceeds to ACT 109. In ACT 109, the processor 201 checks whether check-in completion has been notified. If the processor 201 cannot confirm the notification, the processor 201 determines "NO" and proceeds to ACT 110. In ACT 110, the processor 201 checks whether a check-in error has been notified. If the processor 201 cannot confirm the notification, the processor 201 determines "NO" and returns to ACT 109. Thus, in ACT 109 and ACT 110, the processor 201 waits for notification of check-in completion or error. If the notification data for the error notification described above is received by the wireless communication unit 208, the processor 201 determines "YES" in ACT 110 and proceeds to ACT 111.

[0080] In ACT 111, the processor 201 generates image data of an error screen to be displayed on the touch panel 204 so that the error screen is displayed on the touch panel 204. The error screen is a screen that is defined to notify the guest that check-in is not possible. If an instruction to cancel the display of the error screen is given, for example, by operating a GUI element displayed on the error screen, the processor 201 returns to ACT 101.

[0081] On the other hand, if the notification data for notifying the check-in completion described above is received by the wireless communication unit 208, the processor 201 determines YES in ACT 109 and proceeds to ACT 112 in Fig. 11. In ACT 112, the processor 201 generates image data of the list screen to be displayed on the touch panel 204 so that the list screen is displayed on the touch panel 204. The list screen is a screen that displays a list of registered purchased products.

[0082] FIG. 17 is a diagram showing an example of a list screen SCA presented to a customer. The list screen SCA includes display areas ARAA and ARAB and buttons BUAA, BUAB, BUAC, and BUAD. The display area ARAA shows the total number of purchased items and the total price of the purchased items. The display area ARAB shows a list of purchased items. The button BUAA is a soft key that allows the customer to specify that all purchased items should be canceled and the shopping should be stopped. The button BUAB is a soft key that allows the customer to specify that scanning of items to be registered as purchased items should be started. The button BUAC is a soft key that allows the customer to specify that checkout should be started. The button BUAD is a soft key that allows the customer to specify the assistance service described below.

[0083] 17 shows a state in which no purchased products have been registered yet, so the total number and total amount are both shown as "0" in the display area ARAA, and nothing is shown in the display area ARAB.

[0084] In ACT 113 in FIG. 11 , the processor 201 checks whether the start of a help service has been specified. If the processor 201 cannot confirm the corresponding specification, it determines the result to be NO and proceeds to ACT 114. In ACT 114, the processor 201 checks whether the start of scanning of products has been specified. If the processor 201 cannot confirm the corresponding specification, it determines the result to be NO and proceeds to ACT 115. In ACT 115, the processor 201 checks whether a change in quantity has been specified. If the processor 201 cannot confirm the corresponding specification, it determines the result to be NO and proceeds to ACT 116. In ACT 116, the processor 201 checks whether a cancellation of shopping has been specified. If the processor 201 cannot confirm the corresponding specification, it determines the result to be NO and proceeds to ACT 117. In ACT 117, the processor 201 checks whether the start of checkout has been specified. If the processor 201 cannot confirm the corresponding specification, it determines the result to be NO and proceeds to ACT 118. In ACT 118, the processor 201 checks whether or not a command to display the list screen has been issued. If the processor 201 cannot confirm the command, it determines the result as NO and returns to ACT 113. Thus, in ACT 113 to ACT 118, the processor 201 waits for one of the following to be specified: start assistance, start scanning, quantity, cancel, or start accounting, or for a command to display the list screen to be issued.

[0085] After notifying the user of the check-in completion in ACT 204 in FIG. 14 , the processor 31 in the mobile controller 3 proceeds to ACT 205. In ACT 205, the processor 31 checks whether the user terminal 200 has requested registration of a product to be purchased. If the processor 31 cannot confirm the request, it determines "NO" and proceeds to ACT 206. In ACT 206, the processor 31 checks whether the user terminal 200 has requested a quantity change. If the processor 31 cannot confirm the request, it determines "NO" and proceeds to ACT 207. In ACT 207, the processor 31 checks whether the user terminal 200 has requested deletion of a purchased product. If the processor 31 cannot confirm the request, it determines "NO" and proceeds to ACT 208. In ACT 208, the processor 31 checks whether the user terminal 200 has requested cancellation of a purchased product. If the processor 31 cannot confirm the request, it determines the answer as NO and proceeds to ACT 209. In ACT 209, the processor 31 checks whether the user terminal 200 has requested a checkout. If the processor 31 cannot confirm the request, it determines the answer as NO and returns to ACT 205. Thus, in ACT 205 to ACT 209, the processor 31 waits for the user terminal 200 to request any of registration, quantity change, deletion, cancellation, and checkout.

[0086] If the customer wishes to register the product as a purchased product, the customer specifies the start of scanning by a predetermined operation such as touching the button BUAB on the list screen SCA. In response to this, the processor 201 determines YES in ACT 114 in Fig. 11 and proceeds to ACT 119. In ACT 119, the processor 201 again generates image data of the registration screen to be displayed on the touch panel 204 so that the registration screen is displayed on the touch panel 204. The registration screen is a screen that prompts the customer to read a barcode representing the product code of the product to be registered as a purchased product.

[0087] 18 is a diagram showing an example of a registration screen SCB presented to a customer. The registration screen SCB includes a display area ARBA, a message MEBA, and a button BUBA. The display area ARBA displays an image acquired by the camera 205. The message MEBA is a text message urging the customer to scan the barcode of the product. The button BUBA is a soft key that the customer uses to specify that scanning of the product code should be stopped. The processor 201, for example, activates the camera 205, thereby generating the registration screen SCB by superimposing an image on the image acquired by the camera 205, including a line representing the range of the display area ARBA, the message MEBA, and the button BUBA.

[0088] In ACT 120 in FIG. 11 , the processor 201 checks whether the barcode has been read. At this time, the processor 201 analyzes the image obtained by the camera 205 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS app APDA, or may be performed as a process based on a separate application program for reading barcodes. If the barcode cannot be read, the processor 201 determines "NO" and proceeds to ACT 121. In ACT 121, the processor 201 checks whether a command to stop scanning has been issued. If the command is not confirmed, the processor 201 determines "NO" and returns to ACT 120. Thus, in ACT 120 and ACT 121, the processor 201 waits for the barcode to be read or for a command to stop scanning to be issued.

[0089] If the customer wishes to return to the display state of the list screen SCA without performing this scan, the customer specifies to stop scanning by a predetermined operation such as touching the button BUBA. In response to this, the processor 201 determines YES in ACT 121 and returns to ACT 112. In this case, since the registration state of the purchased product is not changed, the processor 201 generates again image data of the list screen SCA in the same state as that displayed on the touch panel 204 before the deletion screen was displayed so that the list screen SCA in the same state as that displayed on the touch panel 204 before the deletion screen was displayed is displayed again on the touch panel 204.

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

[0091] When the user terminal 200 requests the registration of a purchased item as described above, the processor 31 determines YES in ACT 205 of FIG. 14 and proceeds to ACT 210. In ACT 210, the processor 31 notifies the virtual POS server of the transaction code and transfers a registration request (request data). The processor 31 references the transaction management database DBCA using the terminal code of the user terminal 200 making the registration request and obtains the transaction code corresponding to the user terminal 200. At this time, the processor 31 may add the transaction code to the request data sent from the user terminal 200 and transfer it to the virtual POS server 2, or may add the transaction code to the request data converted by some process and send it to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the barcode data included in the request data sent from the user terminal 200.

[0092] By executing the virtual POS application APBA, the processor 21 in the virtual POS server 2 assumes that the barcode data included in the request data sent from the mobile controller 3 was read by a barcode scanner installed in an existing POS terminal, and attempts to register the purchased item using the same process as an existing POS terminal. However, for some reason, the product code represented by the barcode data may not be registered in the product database. Also, the product may have a barcode other than the one representing the product code. In these cases, the processor 21 is unable to register the purchased item and will report an error.

[0093] Thus, the processor 31 of the mobile controller 3 transfers the registration request from the user terminal 200, and the processor 21 of the virtual POS server 2 registers the purchased item based on this registration request, so that the item data sent from the user terminal 200, which is an example of a first terminal, is stored in the transaction database DBBA in the auxiliary storage unit 23 of the virtual POS server 2 as an item purchased by the user (customer) of the user terminal 200. Thus, the processor 21 executes the virtual POS application APBA, and the processor 31 executes the registration assistance application APCA, so that the computer (virtual POS server 2) with the processor 21 as its central part and the computer (mobile controller 3) with the processor 31 as its central part realize the function of a first registration unit.

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

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

[0096] In ACT 212, the processor 31 updates the registration database DBCC based on the result data. This update of the registration database DBCC is performed, for example, as follows. Case 1: The notification is for a valid registration, and the data record DRC associated with the transaction being processed does not contain registration data including the notified product code. In this case, the processor 31 adds a new field next to the last field already present in the data record DRC associated with the transaction being processed, and adds new registration data to that field. The processor 31 includes in the new registration data the notified product code, an error flag set to "0" indicating no error, the notified product name and price, the quantity set to "1," and a cancellation flag set to "0" indicating no cancellation. Thus, the registration data added in this case has the structure shown in the upper right corner of FIG. 6.

[0097] Second case: The notification is for a valid registration, and the data record DRC associated with the transaction being processed contains registration data including the notified product code, but the cancellation flag for the registration data is set to "1," indicating that the registration data has been canceled. In this case, the processor 31 processes the same as in the first case above.

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

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

[0100] By updating the registration database DBCC in this way by the processor 31, the registration database DBCC not only shows a list of purchased items registered on the virtual POS server 2, but also records any barcode reading errors.

[0101] The processor 31 may store the barcode data sent in the registration request in the main memory 32 or the auxiliary storage unit 33, and in the fourth case described above, include this stored barcode data in the registration data. In this case, the processor 21 in the virtual POS server 2 does not need to include the barcode data in the result data. The processor 31 may also extract a product code from the stored barcode data and perform the processing of the first to third cases based on this product code. The processor 31 may also obtain the product name and price from the store server 1 or the like based on the product code.

[0102] The processor 31 then proceeds to ACT 213. In ACT 213, the processor 31 instructs the user terminal 200 to display the list screen SCA. For example, the processor 31 transmits instruction data including identification data for identifying that the instruction is to display the list screen SCA to the user terminal 200 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity contained in the data record DRC associated in the registration database DBCC with the transaction being processed.

[0103] Note that various instructions from the mobile controller 3 to the user terminal 200, which will be described below, are realized by sending instruction data including identification data for identifying the reason for the instruction from the mobile controller 3 to the user terminal 200 via the in-store communication network 7 and the access point 6, as described above. After this, the processor 31 returns to the standby state of ACT205 to ACT209.

[0104] After requesting registration in ACT 122 in FIG. 11 , the processor 201 in the user terminal 200 proceeds to ACT 123. In ACT 123, the processor 201 waits for an instruction to display the list screen SCA. If an instruction to display the list screen SCA is received from the mobile controller 3 as described above, the processor 201 determines YES, returns to ACT 112, and generates image data for the list screen SCA to be displayed on the touch panel 204 again so that the list screen SCA is displayed on the touch panel 204. At this time, the processor 201 sets the list screen SCA to a screen that displays the product name, price, and quantity of the purchased product included in the instruction data. Therefore, the customer can register the products as purchased products by repeatedly specifying the start of scanning and having the user terminal 200 sequentially read the barcodes of the products to be registered.

[0105] FIG. 19 shows an example of a list screen SCA presented to a customer, showing the status of registered purchased items. The list screen SCA shown in FIG. 19 shows an example in which the following items have been registered as purchased: one item with the product name "AAA" and a price of 120 yen; two items with the product name "BBB" and a price of 98 yen; and one item with the product name "CCC" and a price of 1,024 yen. In the list screen SCA shown in FIG. 19, the display area ARAB shows the product names, prices, and quantities of these registered items. The display area ARAA also shows the total number of "4" and the total amount of "1,340." The area surrounded by a dashed line to the left of the product name represents an area for displaying an icon. The dashed line representing this area is not actually displayed on the list screen SCA.

[0106] In many cases, the camera 205 of the user terminal 200 is not a reading device optimized for reading barcodes. This can make it difficult to read barcodes. In addition, there are also cases where the barcode is not displayed on the product. If a customer is unable to successfully read a barcode with the user terminal 200 and would like help from a store clerk, the customer can specify a help service by performing a predetermined operation, such as touching the button BUAD on the list screen SCA.

[0107] If the help service is specified in this way, the processor 201 in the user terminal 200 determines YES in ACT 113 in Fig. 11 and proceeds to ACT 124. In ACT 124, the processor 201 generates image data of the linked screen to be displayed on the touch panel 204 so that the linked screen is displayed on the touch panel 204.

[0108] 20 is a diagram showing an example of the linked screen SCC presented to a customer. The linked screen SCC includes a message MECA, a barcode BCCA, and a button BUCA. The message MECA is a text message urging the customer to present the linked screen SCC to a store clerk. The barcode BCCA represents barcode data including the terminal code of the user terminal 200. The button BUCA is a soft key that the customer uses to specify that the display screen should be returned to the list screen.

[0109] The customer calls out to a store clerk and presents the link screen SCC. The link screen SCC is used to link the process of storing the details of a transaction being carried out in response to a request from the customer's user terminal 200 with the store clerk terminal 300. When the store clerk is presented with the link screen SCC, the store clerk activates the link function of the store clerk terminal 300. When the link function is activated, the processor 302 of the store clerk terminal 300 executes the store clerk terminal app APEA and performs predetermined processing. Figure 21 is a flowchart of information processing performed by the processor 302 executing the store clerk terminal app APEA.

[0110] In ACT 301, the processor 302 generates image data for a guide screen to be displayed on the touch panel 305 so that the guide screen is displayed on the touch panel 305. The guide screen is a screen that prompts the store clerk to scan the barcode BCCA displayed on the linked screen SCC presented by the customer. The store clerk follows the instructions on the guide screen and causes the barcode scanner 301 to scan the barcode BCCA displayed on the linked screen SCC presented by the customer. When the barcode scanner 301 scans the barcode BCCA, it notifies the processor 302 of the barcode data represented by the barcode BCCA.

[0111] When the barcode BCCA displayed on the linked screen SCC is scanned, the customer instructs the store clerk to return by performing a predetermined operation such as touching the button BUCA. If the customer wishes to cancel the use of the assistance service, the customer can instruct the store clerk to return without showing the linked screen SCC to the store clerk.

[0112] The processor 201 of the user terminal 200 proceeds to ACT 125 in Fig. 11 with the collaboration screen SCC displayed. In ACT 125, the processor 201 waits for a return instruction. If a return instruction is given as described above, the processor 201 determines YES, returns to ACT 112, and performs subsequent processing in the same manner as described above.

[0113] 21, the processor 302 of the store clerk terminal 300 displays a guide screen on the touch panel, and then proceeds to ACT 302. In ACT 302, the processor 302 waits for the terminal code of the user terminal 200 to be acquired. When the barcode data is notified from the barcode scanner 301 as described above, the processor 302 determines YES and proceeds to ACT 303 because the terminal code of the user terminal 200 included in the barcode data has been acquired.

[0114] In ACT 303, the processor 302 requests the mobile controller 3 to cooperate with the process of storing purchased items (details of the transaction) being performed in response to a request from the user terminal 200. Specifically, the processor 302 establishes wireless communication between the wireless communication unit 307 and the access point 6 in accordance with predetermined communication settings. The processor 302 then transmits request data for requesting cooperation to the mobile controller 3 via wireless communication with the access point 6. This request data is transmitted to the mobile controller 3 via the access point 6 and the in-store communication network 7. The processor 302 includes, in the request data for requesting cooperation, identification data for identifying that the request is for cooperation and the terminal code of the user terminal 200 included in the barcode data.

[0115] The various requests from the store clerk terminal 300 to the mobile controller 3 described below are realized by sending request data including identification data for identifying the reason for the request from the store clerk terminal 300 to the mobile controller 3 via the access point 6 and the in-store communication network 7, as described above.

[0116] When request data for requesting cooperation is received by the communication interface 34, the processor 31 in the mobile controller 3 executes the registration assistance application APCA and starts information processing (hereinafter referred to as cooperation processing) for linking the store clerk terminal 300 with the purchase product registration processing being performed using the user terminal 200. Figure 22 is a flowchart of the cooperation processing performed by the processor 31 executing the registration assistance application APCA.

[0117] The processor 31 starts the linkage process each time request data for requesting linkage is received by the communication interface 34. If the processor 31 is already executing a linkage process that was started based on a request from another clerk terminal, the processor 31 starts a new linkage process in parallel with the previous linkage process. In other words, the processor 31 may execute multiple linkage processes in parallel, each targeting multiple clerk terminals 300. In the following description of the linkage process, when the term "clerk terminal 300" is simply used, it refers to the clerk terminal 300 that is the target of the linkage process being described.

[0118] In ACT 401, the processor 31 confirms whether the request source is the clerk terminal 300. For example, the processor 31 inquires of the store server 1 whether the terminal identified by the terminal code of the sender of the request data for requesting cooperation is the clerk terminal 300. The store server 1 uses the inquired terminal code to refer to the clerk terminal database, which is part of the database group DBAA stored in the auxiliary storage unit 13 of the store server 1, and confirms whether the terminal code is the code of a terminal designated for use by a clerk. If the inquired terminal code is included in the clerk terminal database, the processor 31 notifies the mobile controller 3 that the terminal is the clerk terminal 300; if not, the processor 31 notifies the mobile controller 3 that the terminal is not the clerk terminal 300. If the store server 1 notifies the processor 31 that the terminal is not the clerk terminal 300, the processor 31 determines NO and proceeds to ACT 402.

[0119] In ACT 402, the processor 31 notifies the clerk terminal 300 of the denial of the link. For example, the processor 31 transmits notification data including identification data for identifying that the link has been denied to the clerk terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 then ends the linking process. In other words, in this case, the processor 31 does not link the clerk terminal 300 with the user terminal 200.

[0120] On the other hand, if the store server 1 notifies the processor 31 that the requested data is the clerk terminal 300, the processor 31 determines YES in ACT 401 and proceeds to ACT 403. In ACT 403, the processor 31 updates the link database DBCB to store an association between the terminal code of the user terminal 200 and the terminal code of the clerk terminal 300, in order to indicate that the clerk terminal 300 is linked with the purchase product registration process using the user terminal 200 identified by the terminal code included in the request data. For example, the processor 31 sets the terminal code of the sender of the request data in field FBA, and updates the link database DBCB to include a new data record DRB in which the terminal code included in the request data is set in field FBB.

[0121] As a result, the clerk terminal 300 as the second terminal is linked to the process of storing the purchased items (details of the transaction) performed in response to a request from the user terminal 200 as the first terminal. In this way, the processor 31 executes information processing based on the registration assistance application APCA, and the computer (mobile controller 3) with the processor 31 as its central part functions as a linking unit.

[0122] In ACT 404, the processor 31 instructs the clerk terminal 300 to display a registration status screen. For example, the processor 31 transmits instruction data including identification data for identifying that the instruction is to display the registration status screen to the clerk terminal 300 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data for the clerk terminal 300 the product code, product name, price, and quantity contained in the data record DRB stored in the registration database DBCC in association with the transaction related to the user terminal 200.

[0123] After the processor 302 of the store clerk terminal 300 requests cooperation in ACT 303 in FIG. 21 , the processor 302 proceeds to ACT 304. In ACT 304, the processor 302 checks whether an instruction to display a registration status screen has been issued. If the corresponding designation cannot be confirmed, the processor 302 determines "NO" and proceeds to ACT 305. In ACT 305, the processor 302 checks whether a refusal of cooperation has been notified. If the corresponding notification cannot be confirmed, the processor 302 determines "NO" and returns to ACT 304. Thus, in ACT 304 and ACT 305, the processor 302 waits for either an instruction to display a registration status screen or a refusal notification.

[0124] When the wireless communication unit 307 receives notification data notifying the refusal, the processor 302 determines YES in ACT 305 and proceeds to ACT 306. In ACT 306, the processor 302 displays an error screen on the touch panel 305. The error screen is a screen for notifying the store clerk that linking is not possible. The processor 302 then waits for the store clerk to declare that they have confirmed the notification on the error screen, or for the end of a predetermined display period for the error screen, and then ends the information processing shown in FIG. 21 .

[0125] When the instruction data instructing to display the registration status screen is received by the wireless communication unit 307, the processor 302 determines YES in ACT 304 and proceeds to ACT 307. In ACT 307, the processor 302 generates image data of the registration status screen to be displayed on the touch panel 204 so that the registration status screen is displayed on the touch panel 204. At this time, the processor 302 sets the registration status screen to a screen that displays the product name, price, and quantity of the purchased product included in the instruction data.

[0126] Thus, the store clerk can check the registration status of the purchased item in the linked user terminal 200 by visually checking the registration status screen displayed on the touch panel 204. Then, in response to a request from the customer, the store clerk performs a predetermined operation to specify the item that the customer wishes to register as a purchased item. This operation is, for example, an operation to have the barcode scanner 301 scan a barcode representing the product code of the relevant item. This operation may also be an operation to input the product code on the touch panel.

[0127] In ACT 308, the processor 302 checks whether the product code has been acquired. If the product code has not been acquired, the processor 302 determines the result as NO and proceeds to ACT 309. In ACT 309, the processor 302 checks whether an instruction to cancel the link has been issued. If the instruction has not been issued, the processor 302 determines the result as NO and returns to ACT 308. Thus, in ACT 308 and ACT 309, the processor 302 waits for the product code to be acquired or for an instruction to cancel the link to be issued.

[0128] When an operation to specify a product is performed as described above, the processor 302 acquires a product code in response to that operation. Therefore, the processor 302 determines YES in ACT 308 and proceeds to ACT 310. In ACT 310, the processor 302 requests the mobile controller 3 to register the product. The processor 302 includes the acquired product code in the request data that is transmitted here.

[0129] The processor 31 in the mobile controller 3 instructs the display of the registration status screen in ACT 404 in FIG. 22 , and then proceeds to ACT 405. In ACT 405, the processor 31 checks whether product registration has been requested. If the processor 31 cannot confirm the request, it determines "NO" and proceeds to ACT 406. In ACT 406, the processor 31 checks whether cancellation of linkage has been requested. If the processor 31 cannot confirm the request, it determines "NO" and returns to ACT 405. Thus, in ACT 405 and ACT 406, the processor 31 waits for a registration or cancellation request. If registration has been requested from the store clerk terminal 300 as described above, the processor 31 determines "YES" in ACT 405 and proceeds to ACT 407.

[0130] In ACT 407, the processor 31 transfers a product registration request as request data to the virtual POS server 2. At this time, the processor 31 adds to the request data the transaction code of the transaction being processed by the user terminal 200 linked to the clerk terminal 300. For example, the processor 31 searches the linked database DBCB stored in the auxiliary storage unit 33 for a data record DRB in which the terminal code of the requesting clerk terminal 300 is set in field FBA, and obtains the terminal code of the user terminal 200 set in field FBB of the corresponding data record DRB. The processor 31 then searches the transaction management database DBCA stored in the auxiliary storage unit 33 for a data record DRA in which the terminal code of the obtained user terminal 200 is set in field FAA, and obtains the transaction code set in field FAC of the corresponding data record DRA. The processor 31 then adds the obtained transaction code to the request data transferred to the virtual POS server 2.

[0131] In the virtual POS server 2, the processor 21 registers the product code included in the request data sent from the mobile controller 3 as the purchased product of the transaction identified by the transaction code included in the request data in the transaction database DBBA stored in the auxiliary storage unit 23. The processor 21 then transmits result data indicating the results of this processing to the mobile controller 3 in the same manner as in ACT 212.

[0132] Thus, the processor 31 of the mobile controller 3 transfers the registration request from the clerk terminal 300, and the processor 21 of the virtual POS server 2 registers the purchased item based on this registration request, causing the item specified on the clerk terminal 300 (second terminal) to be stored in the transaction database DBBA in the auxiliary storage unit 23 of the virtual POS server as an item to be purchased by the customer who is using the user terminal 200. Thus, the processor 21 executes the virtual POS application APBA, and the processor 31 executes the registration assistance application APCA, thereby realizing the function of a second registration unit by the computer (virtual POS server 2) in which the processor 21 is the central part, and the computer (mobile controller 3) in which the processor 31 is the central part.

[0133] After requesting registration in ACT 407, the processor 31 of the mobile controller 3 proceeds to ACT 408. In ACT 408, the processor 31 acquires the result data transmitted from the virtual POS server as described above. The processor 31 stores the acquired result data in the main memory 32 or the auxiliary storage unit 33.

[0134] In ACT 409, the processor 31 updates the registration database DBCC based on the result data in the same manner as described above. In ACT 410, the processor 31 instructs the user terminal 200, which is linked to the clerk terminal 300, to display a list screen. The processor 31 includes in the instruction data for this display instruction the product code, product name, price, and quantity contained in the data record DRB associated in the registration database DBCC with the transaction being processed.

[0135] The processor 31 then returns to ACT 404 and repeats the subsequent processes in the same manner as described above. That is, at this time, the processor 31 instructs the clerk terminal 300 to display a registration status screen showing the product code, product name, price, and quantity contained in the updated data record DRB associated in the registration database DBCC with the transaction being processed.

[0136] When the processor 201 in the user terminal 200 receives an instruction from the mobile controller 3 to display a list screen as described above, the processor 201 determines YES in ACT 118 in Fig. 11, returns to ACT 112, and repeats the subsequent processing in the same manner as described above. That is, at this time, the processor 201 instructs the user terminal 200 to display a list screen showing the product code, product name, price, and quantity contained in the updated data record DRB associated in the registration database DBCC with the transaction being processed. Therefore, the list screen SCA displayed thereby reflects the registration results in response to the operation at the clerk terminal 300.

[0137] After the processor 302 in the clerk terminal 300 requests product registration in ACT 310 in FIG. 21 , the processor 302 proceeds to ACT 311. In ACT 311, the processor 302 waits for an instruction to display a registration status screen. If an instruction to display the registration status screen is received from the mobile controller 3 as described above, the processor 302 determines YES, returns to ACT 307, and generates image data of the registration status screen to be displayed on the touch panel 305 so that the registration status screen is again displayed on the touch panel 305. As described above, the purchased product related to the transaction that is the subject of transaction processing related to the user terminal 200 with which the clerk terminal 300 is linked is registered by the operation of the clerk on the clerk terminal 300.

[0138] When the store clerk has finished registering all the products requested by the customer as purchased products, he / she instructs the cancellation of the linkage by a predetermined operation, such as touching a button shown on the registration status screen. If the cancellation of the linkage is instructed as described above, the processor 302 determines YES in ACT 309 and proceeds to ACT 312. In ACT 312, the processor 302 requests the mobile controller 3 to cancel the linkage.

[0139] In ACT 313, the processor 302 waits for a release notification. When release of linkage is requested, the processor 31 in the mobile controller 3 determines YES in ACT 406 in FIG. 22 and proceeds to ACT 411. In ACT 411, the processor 31 updates the linkage database DBCB so as to release the linkage between the requesting clerk terminal 300 and the user terminal 200. For example, the processor 31 deletes from the linkage database DBCB the data record DRB in which the terminal code of the requesting clerk terminal 300 is set in field FBA.

[0140] In ACT 412, the processor 31 notifies the store clerk terminal 300 of the cancellation of the linkage. Then, the processor 31 ends the linkage processing. When the processor 302 in the store clerk terminal 300 is notified of the cancellation of the linkage from the mobile controller 3 as described above, the processor 302 determines YES in ACT 313 in Figure 21 and ends the information processing shown in Figure 21.

[0141] When a customer touches an area on the list screen SCA that indicates the number of items, the processor 201 generates image data for displaying a list box for specifying the number of items superimposed on the list screen SCA so that a list box for specifying the number of items is displayed superimposed on the list screen SCA. When this list box is operated, the processor 201 receives this as a specification of the number of items. In this case, the processor 201 determines YES in ACT 115 of FIG. 11 and proceeds to ACT 126 of FIG. 12. In ACT 126, the processor 201 checks whether the specified number is 0. If the specified number is not 0, the processor 201 determines NO and proceeds to ACT 127.

[0142] In ACT 127, the processor 201 requests the mobile controller 3 to change the quantity. The request data sent by the processor 201 here includes specific data for identifying the product whose quantity is specified and the specified number. The specific data may be a product code, or may be data that can identify the purchased product only on the mobile controller 3, such as a number for identifying each purchased product in a list of purchased products. If a product code is used as the specific data, the processor 31 includes the product code for each purchased product in the instruction data for instructing the display of a list screen.

[0143] When a quantity change is requested from the user terminal 200 as described above, the processor 31 in the mobile controller 3 determines YES in ACT 206 in FIG. 14 and proceeds to ACT 214 in FIG. 15. In ACT 214, the processor 31 forwards the quantity change request to the virtual POS server 2 along with notification of the transaction code. At this time, the processor 31 may add the transaction code to the request data sent from the user terminal 200 and forward it to the virtual POS server 2, or may add the transaction code to the request data after conversion through some processing and send it to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the quantity included in the request data sent from the user terminal 200. Furthermore, if the specific data included in the request data is not a product code, the processor 31 replaces the specific data with the product code.

[0144] The processor 21 in the virtual POS server 2 assumes that the quantity included in the request data sent from the mobile controller 3 was entered using an input device provided on the existing POS terminal, and changes the quantity of the purchased item using the same process as the existing POS terminal. The processor 21 sends result data indicating the product code of the product whose quantity has been changed and the new quantity to the mobile controller 3.

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

[0146] In ACT 216, the processor 31 updates the registration database DBCC based on the result data. That is, the processor 31 finds the registration data including the notified product code from the associated data record DRC. The processor 31 then rewrites the quantity included in the corresponding registration data with the quantity included in the result data.

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

[0148] In ACT 217, the processor 31 instructs the user terminal 200 to display a list screen. The processor 31 includes, in the instruction data, the product code, product name, price, and quantity contained in the registration data whose cancellation flag is "0" among the registration data contained in the data record DRC updated as described above. The processor 31 then returns to the standby state of ACT 205 to ACT 209 in FIG. 14.

[0149] Now, if the specified quantity is 0, the processor 201 in the user terminal 200 determines YES in ACT 126 of Fig. 12 and proceeds to ACT 128. In ACT 128, the processor 201 generates image data of a deletion screen to be displayed on the touch panel 204 so that the deletion screen is displayed on the touch panel 204. The deletion screen is a screen that notifies the customer that the product for which the quantity has been specified to be 0 will be deleted from the purchased products. The deletion screen includes a delete button for specifying deletion and a back button for specifying returning to the state before the quantity change was specified without changing the quantity.

[0150] In ACT 129, the processor 201 checks whether or not deletion has been specified. If the processor 201 cannot confirm the corresponding specification, it determines "NO" and proceeds to ACT 130. In ACT 130, the processor 201 checks whether or not return has been specified. If the processor 201 cannot confirm the corresponding specification, it determines "NO" and returns to ACT 129. Thus, in ACT 129 and ACT 130, the processor 201 waits for deletion or return to be specified.

[0151] If the customer wishes to cancel the deletion and return to the state before specifying the change in quantity, the customer specifies "back" by a predetermined operation such as touching the back button on the deletion screen. In response to this, the processor 201 determines YES in ACT 130, returns to ACT 112 in Fig. 11, and again displays the list screen SCA on the touch panel 204. In this case, the registration state of the purchased product is not changed, so the processor 201 again displays the list screen SCA on the touch panel 204 in the same state as that displayed before the deletion screen was displayed.

[0152] If the customer is sure to delete the product, he or she specifies the deletion by a predetermined operation such as touching the delete button on the deletion screen. In response to this, the processor 201 determines YES in ACT 129 and proceeds to ACT 131. In ACT 131, the processor 201 requests the mobile controller 3 to delete the product. The request data transmitted by the processor 201 here includes specific data for identifying the product specified for deletion.

[0153] When a deletion request is received from the user terminal 200 as described above, the processor 31 in the mobile controller 3 determines YES in ACT 207 in Fig. 14 and proceeds to ACT 218 in Fig. 15. In ACT 218, the processor 31 transfers the deletion request to the virtual POS server 2 along with notification of the transaction code. At this time, the processor 31 may add the transaction code to the request data sent from the user terminal 200 and transfer the data to the virtual POS server 2, or may add the transaction code to the request data converted by some process and send it to the virtual POS server 2. However, if the specific data included in the request data is not a product code, the processor 31 replaces the specific data with the product code.

[0154] In the virtual POS server 2, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a deletion instruction input by an input device provided on the existing POS terminal, and performs processing similar to that of the existing POS terminal to remove the target product from the purchased products registered in the transaction database DBBA stored in the auxiliary storage unit 23. The processor 21 sends result data indicating the product codes of the products removed from the purchased products to the mobile controller 3.

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

[0156] In ACT 220, the processor 31 updates the registration database DBCC based on the result data. That is, the processor 31 finds the registration data including the notified product code from the data record DRC associated with the transaction code. The processor 31 then changes the cancellation flag included in the corresponding registration data to "1."

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

[0158] In ACT 221, the processor 31 instructs the user terminal 200 to display the list screen SCA. The processor 31 includes in the display instruction data the product code, product name, price, and quantity contained in the registration data whose cancellation flag is "0" among the registration data contained in the data record DRC updated as described above. The processor 31 then returns to the standby state of ACT 205 to ACT 209 in FIG. 14.

[0159] Now, after requesting a quantity change in ACT 127 in FIG. 12 or requesting deletion in ACT 131, the processor 201 in the user terminal 200 proceeds to ACT 132. In ACT 132, the processor 201 waits for an instruction to display the list screen SCA. If an instruction to display the list screen SCA is received from the mobile controller 3 in response to the request for quantity change or deletion, as described above, the processor 201 determines YES, returns to ACT 112 in FIG. 11, and generates image data for the list screen SCA to be displayed on the touch panel 204 again so that the list screen SCA is displayed on the touch panel 204. At this time, the processor 201 sets the list screen SCA to a screen displaying the product name, price, and quantity of the purchased product included in the instruction data. In this case, since the registration status of the purchased product is changed, the processor 201 generates image data for the list screen SCA so that the list screen SCA displayed on the touch panel 204 is different from the list screen SCA displayed when the quantity change or deletion was specified.

[0160] If a customer wishes to cancel all of the purchased items that have already been registered and to stop shopping, the customer specifies the cancellation by a predetermined operation, such as touching the button BUAA on the list screen SCA. In response to this, the processor 201 determines YES in ACT 116 in FIG. 11 and proceeds to ACT 133 in FIG. 12. In ACT 133, the processor 201 generates image data of a cancellation screen to be displayed on the touch panel 204 so that the cancellation screen is displayed on the touch panel 204. The cancellation screen is a screen that notifies the customer that all of the purchased items that have already been registered will be canceled. The cancellation screen includes an execute button for specifying cancellation execution and a return button for specifying returning to the state before the quantity change was specified without changing the quantity.

[0161] In ACT 134, the processor 201 checks whether or not cancel execution has been specified. If the processor 201 cannot confirm the corresponding specification, it determines "NO" and proceeds to ACT 135. In ACT 135, the processor 201 checks whether or not return has been specified. If the processor 201 cannot confirm the corresponding specification, it determines "NO" and returns to ACT 134. Thus, in ACT 134 and ACT 135, the processor 201 waits for cancel execution or return to be specified.

[0162] If the customer wishes to continue shopping, the customer specifies "Back" by a predetermined operation such as touching the "Back" button on the cancellation screen. In response to this, the processor 201 determines "YES" in ACT 135, returns to ACT 112 in Fig. 11, and causes the list screen SCA to be displayed again on the touch panel 204. In this case, the registration status of the purchased products is not changed, so the processor 201 causes the list screen SCA to be displayed again on the touch panel 204 in the same state as that displayed before the cancellation screen was displayed.

[0163] If the customer wishes to cancel the purchase, the customer specifies the cancellation of the transaction by a predetermined operation such as touching the execute button on the cancellation screen. In response to this, the processor 201 determines YES in ACT 134 and proceeds to ACT 136. In ACT 136, the processor 201 requests the mobile controller 3 to cancel the transaction.

[0164] If a transaction cancellation request is received from the user terminal 200 as described above, the processor 31 in the mobile controller 3 determines YES in ACT 208 in Fig. 14 and proceeds to ACT 222 in Fig. 15. In ACT 222, the processor 31 notifies the virtual POS server of the transaction code and transfers a transaction cancellation request (request data) to the virtual POS server 2. At this time, the processor 31 may add the transaction code to the request data and transfer it to the virtual POS server 2, or may add the transaction code to the request data that has been converted by some process and send it to the virtual POS server 2.

[0165] The processor 21 in the virtual POS server 2 regards the request based on the request data sent from the mobile controller 3 as a cancellation instruction entered using an input device provided on the existing POS terminal, and performs processing similar to that of the existing POS terminal to delete all of the purchased items registered in association with the notified transaction code in the transaction database DBBA stored in the auxiliary storage unit 23. The processor 21 sends result data indicating that the cancellation has been completed to the mobile controller 3.

[0166] After transferring the transaction cancellation request in ACT 222, the processor 31 in the mobile controller 3 proceeds to ACT 223. In ACT 223, the processor 31 acquires the result data transmitted from the virtual POS server as described above. The processor 31 stores the acquired result data in the main memory 32 or the auxiliary storage unit 33.

[0167] In ACT 224, the processor 31 updates the registration database DBCC based on the result data. That is, the processor 31 changes the cancellation flags that are set to "0" to "1" for all of the registration data included in the data record DRC associated with the transaction being processed. In ACT 225, the processor 31 notifies the user terminal 200 of the cancellation. Then, the processor 31 returns to the standby state of ACT 205 to ACT 209 in FIG. 14.

[0168] After the processor 201 in the user terminal 200 requests cancellation in ACT 136 in Fig. 12, the processor 201 proceeds to ACT 137. In ACT 137, the processor 201 waits for a cancellation notification from the mobile controller 3. If the cancellation notification is received as described above, the processor 201 determines YES and returns to ACT 101 in Fig. 10.

[0169] When the customer has finished registering all of the products they wish to purchase as purchased products, they proceed to payment. At this time, the customer specifies the start of payment by a predetermined operation, such as touching the button BUAC on the list screen SCA. In response, the processor 201 determines YES in ACT 117 in Fig. 11 and proceeds to ACT 138 in Fig. 13. In ACT 138, the processor 201 requests payment from the mobile controller 3.

[0170] If the processor 31 in the mobile controller 3 receives a billing request from the user terminal 200 as described above, the processor 31 determines YES in ACT 209 in Fig. 14 and proceeds to ACT 226 in Fig. 16. In ACT 226, the processor 31 instructs the user terminal 200 to display a billing screen.

[0171] After the processor 201 of the user terminal 200 makes a billing request in ACT 138 in Fig. 13, the processor 201 proceeds to ACT 139. In ACT 139, the processor 201 waits for an instruction to display the billing screen. If the processor 201 confirms that an instruction to display the billing screen has been issued as described above, the processor 201 determines YES in ACT 139 and proceeds to ACT 140.

[0172] As ACT 140, the processor 201 generates image data of the accounting screen to be displayed on the touch panel 204 so that the accounting screen is displayed on the touch panel 204. The accounting screen is a screen that allows the customer to select whether to perform the operation to pay the price on the user terminal 200 or the payment machine 5. If the customer wants to perform the operation to pay the price on the user terminal 200, the customer specifies the user terminal 200 using a predetermined operation. If the customer wants to perform the operation to pay the price on the payment machine 5, the customer specifies the payment machine 5 using a predetermined operation.

[0173] In ACT 141, the processor 201 checks whether the user terminal 200 has been designated. If the processor 201 cannot confirm the designation, it determines "NO" and proceeds to ACT 142. In ACT 142, the processor 201 checks whether the payment device 5 has been designated. If the processor 201 cannot confirm the designation, it determines "NO" and returns to ACT 141. Thus, in ACT 141 and ACT 142, the processor 201 waits for the user terminal 200 or the payment device 5 to be designated. If the user terminal 200 has been designated as described above, the processor 201 determines "YES" in ACT 141 and proceeds to ACT 143.

[0174] In ACT 143, the processor 201 requests payment from the mobile controller 3. The processor 201 includes payment data necessary for payment, such as a credit number or a user code for an online payment service, in the request data for requesting payment.

[0175] Furthermore, if a payment machine 5 is specified as described above, the processor 201 determines YES in ACT 142 and proceeds to ACT 144. In ACT 144, the processor 201 generates image data for the payment barcode screen to be displayed on the touch panel 204 so that the payment barcode screen is displayed on the touch panel 204. The payment barcode screen is a screen that displays a payment barcode, which represents data necessary for the payment machine 5 to obtain data related to the details of the transaction (hereinafter referred to as payment data) from the virtual POS server 2. Note that, although detailed processing is not shown in the figure, the processor 201 obtains the payment barcode from the virtual POS server 2 via the mobile controller 3 and displays the payment barcode on the payment barcode screen.

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

[0177] After instructing the processor 31 in the mobile controller 3 to display the accounting screen in ACT 226 in FIG. 16 , the processor 31 proceeds to ACT 227. In ACT 227, the processor 31 checks whether a payment request has been made from the user terminal 200. If the request cannot be confirmed, the processor 31 determines NO and proceeds to ACT 228. In ACT 228, the processor 31 checks whether a notification of payment completion has been made. If the notification cannot be confirmed, the processor 31 determines NO and returns to ACT 227. Thus, in ACT 227 and ACT 228, the processor 31 waits for a payment request or a payment completion notification. If a payment request has been made from the user terminal 200 as described above, the processor 31 determines YES in ACT 227 and proceeds to ACT 229.

[0178] In ACT 229, the processor 31 transfers a payment request, along with a notification of the transaction code of the transaction being processed, to the virtual POS server 2. At this time, the processor 31 may transfer the request data sent from the user terminal 200 directly to the virtual POS server 2, or may transmit the request data to the virtual POS server 2 after converting it in some way.

[0179] The processor 21 in the virtual POS server 2 regards the request data sent from the mobile controller 3 as a payment instruction entered through an input device on an existing POS terminal, calculates the amount of the transaction identified by the notified transaction code using the same processing as an existing POS terminal, and performs processing to settle the amount based on the payment data. The settlement processing includes, for example, a payment request to a settlement server (not shown). The processor 21 then sends result data indicating that the settlement has been completed to the mobile controller 3.

[0180] After transferring the payment request in ACT 229, the processor 31 in the mobile controller 3 proceeds to ACT 230. In ACT 230, the processor 31 waits for notification of payment completion from the virtual POS server 2. Then, if the result data indicating that payment has been completed and sent by the virtual POS server 2 as described above is received by the communication interface 34, the processor 31 determines YES and proceeds to ACT 231. Furthermore, if the processor 31 is notified of payment completion at the accounting machine 5 as described above, the processor 31 determines YES in ACT 228 and proceeds to ACT 231. In ACT 231, the processor 31 notifies the user terminal 200 of payment completion.

[0181] After the processor 201 of the user terminal 200 requests payment from the mobile controller 3 in ACT 143 in Fig. 13, or after displaying the accounting barcode screen in ACT 144, the processor 201 proceeds to ACT 145. In ACT 145, the processor 201 waits for notification that payment is complete. If the processor 201 receives notification of payment completion from the mobile controller 3 as described above, the processor 201 determines YES and proceeds to ACT 146.

[0182] In ACT 146, the processor 201 generates image data of a completion screen to be displayed on the touch panel 204 so that the completion screen is displayed on the touch panel 204. The completion screen is a screen for notifying the customer that the payment has been completed. After confirming the completion screen, the customer declares that they have confirmed the completion screen by performing a predetermined operation, such as touching a button displayed on the completion screen. In response to this, the processor 201 proceeds to ACT 147. The processor 201 may also proceed to ACT 147 if the elapsed time while the completion screen is displayed reaches a predetermined time.

[0183] In ACT 147, the processor 201 generates image data of a checkout scan screen to be displayed on the touch panel 204 so that the checkout scan screen is displayed on the touch panel 204. The checkout scan screen is a screen for reading the checkout two-dimensional code TCO. The processor 201, for example, activates the camera 205, and generates the scan screen by superimposing on the image obtained by the camera 205 a text message urging the customer to read the two-dimensional code TCO and a line indicating the position where the two-dimensional code TCO should be held over it.

[0184] When the checkout scan screen is displayed on the touch panel 204, the customer points the camera 205 at the two-dimensional code TCO posted near the exit of the store so that the two-dimensional code TCO is reflected on the scan screen.

[0185] In ACT 148, the processor 201 waits for the two-dimensional code to be read. At this time, the processor 201 repeatedly analyzes the image obtained by the camera 205 and attempts to read the two-dimensional code. This reading of the two-dimensional code may be performed as a process based on the smartphone POS app APDA, or may be performed as a process based on a separate application program for reading two-dimensional codes. If the two-dimensional code is read, the processor 201 determines YES and proceeds to ACT 149.

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

[0187] If the processor 201 confirms that the data represented by the read two-dimensional code is check-out data, it determines YES in ACT 149 and proceeds to ACT 150. In ACT 150, the processor 201 requests the mobile controller 3 to check out.

[0188] After notifying the completion of payment in ACT 231 in Fig. 16, the processor 31 in the mobile controller 3 proceeds to ACT 232. In ACT 232, the processor 31 waits for a check-out request. Then, if a check-out request is received from the user terminal 200 as described above, the processor 31 determines YES and proceeds to ACT 233.

[0189] In ACT 233, the processor 31 executes checkout processing. This processing includes clearing data stored in the main memory 32 and the auxiliary storage unit 33 for managing the transaction being processed. The virtual POS server 2 may terminate processing related to the transaction upon completion of the settlement, or may terminate processing related to the transaction in response to an instruction from the mobile controller 3. In the latter case, the processor 31 issues the above instruction to the virtual POS server 2 during checkout processing. A history database containing 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, the processor 31 performs processing during checkout processing to update the history database to reflect the operation history related to this transaction. In ACT 234, the processor 31 notifies the user terminal 200 that checkout is complete. The processor 31 then terminates the information processing shown in FIGS. 14 to 16.

[0190] 13, the processor 201 in the user terminal 200 requests check-out, and then proceeds to ACT 151. In ACT 151, the processor 201 waits for a notification of check-out completion. If the processor 201 receives a notification of check-out completion from the mobile controller 3 as described above, the processor 201 determines YES and proceeds to ACT 152.

[0191] In ACT 152, the processor 201 clears various data temporarily used for this shopping, such as the check-in data saved in ACT 107 in Fig. 10. Then, the processor 201 returns to ACT 101 in Fig. 10.

[0192] As described above, according to this embodiment, the clerk terminal 300 can be temporarily linked to the process in which a customer registers purchased items using the user terminal 200, and the registration process using the previous user terminal 200 can be continued as the registration process for purchased items in response to a request from the clerk terminal 300 operated by the clerk, without terminating the product registration process being performed using the user terminal 200.

[0193] It is also possible for a store clerk to operate the user terminal 200 and perform operations related to registering purchased items on behalf of the customer. However, because the user terminal 200 is owned by the customer, it is not desirable for the store clerk to operate the user terminal 200 in consideration of protecting the customer's privacy and the risk of data deletion or equipment damage in the user terminal 200 due to incorrect operation. In contrast, in this embodiment, the store clerk does not operate the user terminal 200, and the only information passed from the user terminal 200 to the store clerk terminal 300 is the terminal code of the user terminal 200. Therefore, the store clerk does not need to operate the user terminal 200, and there is no opportunity for the store clerk to access the information stored in the user terminal 200. Furthermore, in situations where product registration from the user terminal 200 is difficult due to the performance of the camera 205 of the user terminal 200, product registration remains difficult even if the store clerk operates the user terminal 200. In this embodiment, product registration can be performed using a store clerk terminal 300 equipped with a barcode scanner 301 that is suitably configured to optically read barcodes representing product codes, thereby eliminating the aforementioned difficulties associated with registering products using a user terminal 200. Furthermore, the linking function of this embodiment ensures that information generated within the store system 100, such as transaction codes, is not sent to the user terminal 200 or store clerk terminal 300, thereby protecting the security of the store system 100 from customers.

[0194] According to this embodiment, the transaction management database DBCA in the auxiliary storage unit 33 of the mobile controller 3 stores the "user terminal terminal code" and the "transaction code" in association with each other, and the transaction database DBBA in the auxiliary storage unit 23 of the virtual POS server 2 stores the "transaction code" and the "product code to be purchased" in association with each other. A purchase product registration request from the user terminal 200 is processed using the transaction management database DBCA and the transaction database DBBA. If a customer needs temporary assistance from a store clerk while shopping in the store, the "user terminal terminal code" and the "clerk terminal terminal code" are stored in association with each other in the link database DBCB in the auxiliary storage unit 33 of the mobile controller 3 in response to a request from the clerk terminal 300 operated by the clerk to whom the customer has requested assistance. The mobile controller 3 can obtain the "user terminal code" of the customer currently shopping from the "clerk terminal code" of the clerk terminal 300 simply by referencing the link database DBCB. Therefore, with only a slight change to the internal configuration of the transaction processing device, such as adding the linked database DBCB, the mobile controller 3 and virtual POS server 2 can continue the product registration process and process product registration requests from the clerk terminal 200 without interrupting the product registration process in response to a request from the user terminal 200. Furthermore, because the disconnection of the clerk terminal 300 does not affect the contents of the transaction management database DBBA or the transaction database DBBA, product registration processing can continue using the previous user terminal 200. In other words, customers can receive temporary support from a clerk at any time while shopping in the store. For example, if product registration support were provided by a clerk stationed at the cash register, customers would have to carry around products that have not yet been registered as purchases. Furthermore, when adding unregistered products to a shopping cart, it would be difficult to distinguish them from registered products. This embodiment eliminates these inconveniences.

[0195] This embodiment can be modified in various ways, as follows: The clerk terminal 300 may be equipped with a camera, and may acquire barcode data by processing the image acquired by capturing a barcode with the camera. By defining image processing for acquiring barcode data that is suitable for reading product codes, the accuracy of reading product codes can be improved compared to general-purpose image processing that reads various barcodes that do not represent product codes. Furthermore, even if the operation for specifying a product on the clerk terminal 300 is somewhat cumbersome, a clerk can often quickly perform it. Therefore, it is not essential that the clerk terminal 300 have a function that allows product selection to be performed more easily than the user terminal 200.

[0196] The clerk terminal 300 may be linked to the user terminal 200 by displaying a barcode representing the terminal code of the clerk terminal 300 on the touch panel 305 of the clerk terminal 300, and then reading the barcode with the user terminal 200 to obtain the terminal code of the clerk terminal 300. In this case, the user terminal 200 sends a link request and the terminal code of the clerk terminal 300 to the mobile controller 3. In response to the link request sent from the user terminal 200, the mobile controller 3 associates and stores the "user terminal terminal code" and the "clerk terminal terminal code" in the link database DBCB in the auxiliary storage unit 33. Since no information is transmitted from the user terminal 200 to the clerk terminal 300, customer information is more reliably protected from the clerk operating the clerk terminal 300. Furthermore, the user terminal 200 or the clerk terminal 300 may obtain the terminal code of the linked terminal by a method that does not use a barcode, such as wireless communication. Alternatively, a linking code that is different from the terminal code may be acquired from one terminal to the other, and each terminal may notify its own terminal code together with the linking code to the mobile controller 3. In other words, any method may be used as long as the set of terminal codes of the user terminal 200 and the store clerk terminal 300 to be linked can be notified to the mobile controller 3 in some way.

[0197] As part of the operations related to registration, an operation for discounting or giving a discount on a purchased item may be performed on the user terminal 200. For example, this operation is an operation for causing the user terminal 200 to read a barcode printed on a discount coupon. In this case, the processor 302 of the store clerk terminal 300 may accept the operation for discounting or giving a discount on a purchased item while linked with the user terminal 200, and may make a request corresponding to the operation to the mobile controller 3.

[0198] As part of the registration-related operations, an operation for a discount or reduction on the transaction may be performed on the user terminal 200. This operation is, for example, an operation for authenticating that the customer operating the user terminal 200 is a person entitled to receive a discount or reduction on the transaction. One example of this operation is an operation for causing the user terminal 200 to read a card, such as a membership card or a child-rearing support card, that certifies that the customer is a person entitled to receive a discount or reduction on the transaction. In this case, the processor 302 of the store clerk terminal 300 may accept the operation for a discount or reduction on the transaction while linked to the user terminal 200, and may make a request corresponding to the operation to the mobile controller 3.

[0199] The processor 302 in the store clerk terminal 300 may accept operations related to at least one of changing the quantity, deleting a purchased item, or canceling a purchased item while in communication with the user terminal 200, and may make a request to the mobile controller 3 in accordance with the operation.

[0200] In the above embodiment, the functions of the first registration unit and the second registration unit are realized by a computer having processor 21 as its central part and a computer having processor 31 as its central part. In other words, the above embodiment is an example in which a transaction processing device is realized by combining virtual POS server 2 and mobile controller 3. However, it is also possible to have virtual POS server 2 directly receive requests from user terminal 200 and clerk terminal 300, and not provide mobile controller 3. In this case, the functions of the first registration unit and the second registration unit are realized by a computer having processor 21 as its central part. The virtual POS server 2 then corresponds to the transaction processing device.

[0201] When the user terminal 200 is provided to a customer in a store as a tablet terminal attached to a shopping cart, the reading of the two-dimensional code TCI for check-in may be omitted by storing various data included in the check-in data in advance in the user terminal 200. Also, check-out may be replaced with another process, such as the process performed by an existing cart POS system.

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

[0203] The program according to this embodiment may be provided in a state stored in an electronic device, or may be provided in a state not stored in an electronic device. In the latter case, the program may be provided via a network or in a state recorded on a recording medium. The recording medium may be a non-transitory tangible medium. The recording medium may be a computer-readable medium. The recording medium may be a medium capable of storing a program and being readable by a computer, such as a CD-ROM or a memory card, and its form is not important. Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments may be embodied in various other forms, and various omissions, substitutions, and modifications may be made without departing from the spirit of the invention. These embodiments and their modifications are within the scope and spirit of the invention, as well as within the scope of the invention and its equivalents as set forth in the claims.

Claims

1. A transaction processing device comprising: a first registration unit that performs processing to store the details of a transaction related to a user in response to a request from a first terminal operated by the user; a linking unit that links the processing to store the details of a transaction related to the user performed by the first registration unit to the second terminal by storing an association between the first terminal and a second terminal; and a second registration unit that, when the details of a transaction related to the user are sent from the second terminal, performs processing to store the details of the transaction sent from the second terminal as the details of a transaction related to the user in the first registration unit using the association between the second terminal and the first terminal.

2. The transaction processing device of claim 1, wherein the linking unit determines whether the second terminal is a terminal designated for use by a store clerk, and if the second terminal is a terminal designated for use by a store clerk, links the second terminal to a process for storing the details of transactions related to the user of the first terminal.

3. A transaction processing device according to claim 1 or 2, wherein the linking unit links the process of storing the details of the transaction relating to the user performed by the first registration unit to the second terminal by storing the association between the identifier of the first terminal and the identifier of the second terminal when the identifier of the first terminal is obtained via the second terminal.

4. A transaction processing device according to claim 1 or 2, wherein the linking unit links the process of storing the details of the transaction relating to the user performed by the first registration unit to the second terminal by storing the association between the identifier of the first terminal and the identifier of the second terminal when the identifier of the second terminal is obtained via the first terminal.

5. A transaction processing device according to any one of claims 1 to 4, wherein the first registration unit performs a process of storing the details of transactions related to the user in response to a request from the first terminal after the link between the second terminal and the process of storing the details of transactions related to the user at the first terminal by the link unit is released.

6. A transaction processing device according to any one of claims 1 to 5, wherein the first registration unit generates a transaction identifier that identifies the transaction by the user, and stores the contents of the transaction in association with the transaction identifier in the first memory unit.

7. The transaction processing device according to claim 6, further comprising a second storage unit that stores the transaction identifier and the identifier of the first terminal in association with each other.

8. The transaction processing device described in claim 7, wherein the linking unit includes a third memory unit that stores the association between the first terminal and the second terminal by associating and storing the identifier of the first terminal with the identifier of the second terminal, and when transaction details related to the user are sent from the second terminal, the third memory unit is referenced using the identifier of the second terminal to obtain the identifier of the first terminal and passes it to the second registration unit.

9. A transaction processing method comprising: storing transaction details relating to a user in response to a request from a first terminal operated by the user; linking the process of storing the transaction details relating to the user to the second terminal by storing an association between the first terminal and a second terminal; and, when transaction details relating to the user are sent from the second terminal, using the association between the first terminal and the second terminal, storing the transaction details sent from the second terminal as transaction details relating to the user.

10. A program recording medium having recorded thereon a program that causes a computer to execute the following operations: storing the details of a transaction related to a user in response to a request from a first terminal operated by the user; linking the process of storing the details of the transaction related to the user to the second terminal by storing an association between the first terminal and a second terminal; and, when the details of the transaction related to the user are sent from the second terminal, using the association between the first terminal and the second terminal, storing the details of the transaction sent from the second terminal as the details of the transaction related to the user.