Transaction Processing Device, Transaction Processing Method, and Program Recording Medium

Abstract

A process for storing a purchased product in accordance with a request from the terminal of a customer is configured so as to be able to temporarily link with the terminal of a store employee.　A transaction process device according to one embodiment of the present invention comprises a first registration unit, a linking unit, and a second registration unit. The first registration unit stores the content of a transaction relating to a user in accordance with a request from a first terminal by an operation of the user. The linking unit stores an association between the first terminal and the second terminal, thereby linking with the second terminal a process for storing the content of the transaction relating to the user, said transaction being performed by the first registration unit. When the content of the transaction relating to the user is sent from the second terminal, the second registration unit uses the association between the second terminal and the first terminal to store, in the first registration unit, the content of the transaction sent from the second terminal as the content of a transaction relating to the user.

Description

Technical Field

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

Background Art

[0002] A transaction processing system is known in which registration of purchased goods is performed in response to an instruction by a customer on a terminal possessed by the customer. However, due to various circumstances such as difficulty in reading barcodes, barcodes not being displayed on the goods, or the customer not recognizing the operation method, it has been difficult for the customer to register the purchased goods for some goods. Under such circumstances, it has been desired that a store clerk can temporarily perform operations related to registration of transaction details such as purchased goods.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

[0004] The problem to be solved by the present invention is to provide a transaction processing apparatus, a transaction processing method, and a program storage medium that can temporarily cooperate with a terminal used by a store clerk in processing related to registration of transaction details performed in response to a request from a terminal used by a customer.

Brief Description of the Drawings

[0005]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

[0006] The transaction processing apparatus according to the embodiment includes a first registration unit, a cooperation unit, and a second registration unit. The first registration unit performs a process of storing the details of a transaction regarding the user in response to a request from a first terminal by the operation of the user. The cooperation unit, by storing the association between the first terminal and the second terminal, causes the second terminal to cooperate in the process of storing the details of the transaction regarding the user performed by the first registration unit. When the details of a transaction regarding the user are sent from the second terminal, the second registration unit uses the association between the second terminal and the first terminal to perform a process of storing the details of the transaction sent from the second terminal in the first storage unit as the details of the transaction regarding the user.

[0007] Hereinafter, an embodiment of the transaction processing system will be described with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of the transaction processing system according to the present embodiment. The transaction processing system includes a plurality of store systems 100, a user terminal 200, a store clerk terminal 300, and a relay server 400. The plurality of store systems 100, the user terminal 200, and the relay server 400 can communicate via a communication network 500. The store clerk terminal 300 may also be able to communicate via the communication network 500.

[0008] In FIG. 1, two store systems 100 are shown. These store systems 100 are respectively provided in different stores A and B that utilize a transaction processing system. There may be three or more stores that utilize the transaction processing system, and a store system 100 is provided for each store. In the following, when it is necessary to distinguish the store systems 100 provided in each store, the store system 100 provided in store A is represented as store system 100-1, and the store system 100 provided in store B is represented as store system 100-2. The operator operating store A may or may not be the same as the operator operating store B. Also, when a transaction system is utilized in other stores, the operator operating that store may or may not be the same as the operator operating store A or store B.

[0009] The user terminal 200 is an information processing device that functions as a user interface for a customer who conducts shopping at a store using a transaction processing system. The user terminal 200 has a function of wirelessly communicating with the store system 100 and a function of wirelessly communicating with the communication network 500. As the user terminal 200, a communication terminal having a data communication function such as a smartphone or a tablet computer can be used. The user terminal 200 may be owned by the customer or may be lent to the customer at the store. The user terminal 200 has the customer as the operator. However, the user terminal 200 may sometimes 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 store clerk terminal 300 is an information processing device that functions as a user interface for a store clerk. The store clerk terminal 300 has a function of wirelessly communicating with the store system 100. As the store clerk terminal 300, a communication terminal having a data communication function such as a tablet computer can be used. The store clerk terminal 300 is provided with a barcode scanner 301. The barcode scanner 301 is a reading device suitably configured to optically read a barcode representing a product code. The store 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. For example, the relay server 400 provides a data communication relay function as a cloud service via the communication network 500. As the communication network 500, for example, the Internet, a VPN (virtual private network), a LAN (local area network), a public communication network, a mobile communication network, etc. can be used alone or in appropriate combination. Typically, a mobile communication network and the Internet or a VPN are used as the communication network 500.

[0012] The schematic configurations of the respective store systems 100 are common. That is, the store system 100 is configured such that the store server 1, the virtual POS server 2, the mobile controller 3, the communication server 4, the accounting machine 5, and the access point 6 can communicate via the in-store communication network 7. However, the store server 1, the virtual POS server 2, the mobile controller 3, the communication server 4, the accounting machine 5, the access point 6, and the in-store communication network 7 only need to have common functions for realizing the operations described later, and do not need to be completely identical. Also, some of the store systems 100 may be provided with devices not shown in FIG. 1.

[0013] The store server 1 comprehensively manages a plurality of transactions that are the targets of transaction processing realized by the store system 100 as described later. For example, the store server 1 has functions similar to those of an existing POS server. The virtual POS server 2 performs information processing such as registration of purchased goods for each transaction and settlement of the price of the purchased goods in response to requests from the outside. That is, the virtual POS server 2 virtually realizes the functions of an existing POS terminal. The information processing performed by the virtual POS server 2 is customized to adapt to differences in the operation policies of each store. That is, for example, there may be some differences between 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.

[0014] The mobile controller 3 provides assistance for the virtual POS server 2 to perform the above information processing while using the user terminal 200 as a user interface device. The communication server 4 performs communication processing for the store server 1, the virtual POS server 2, the mobile controller 3, and the cash register 5 to exchange data with a relay server 400 etc. via the communication network 500.

[0015] The cash register 5 calculates the price for each purchased item managed by the virtual POS server 2 and performs processing to settle the price with the customer. The settlement methods that the cash register 5 can use for the above settlement may be all or any part of well-known settlement methods such as cash settlement, credit card settlement, electronic money settlement, point settlement, code settlement, etc. Note that code settlement is also referred to as mobile settlement or smartphone settlement. The cash register 5 may be operated by either a store clerk or a customer. As the cash register 5, for example, a self-service cash register used in an existing semi-self-service POS system can be used. The cash register 5 may have a function of performing information processing for registering an item as a purchased item. In this case, as the cash register 5, 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 can be used.

[0016] The access point 6 performs communication processing to enable the user terminal 200 to access the in-store communication network 7 by wireless communication. As the access point 6, for example, a well-known communication device that performs wireless communication according to the IEEE802.11 standard can be used. The access point 6 is installed in the store so that the user terminal 200 can perform wireless communication from anywhere in the store sales floor. Depending on the store size, multiple access points 6 may be arranged in one store system 100. As the in-store communication network 7, the Internet, VPN, LAN, public communication network, mobile communication network, etc. can be used alone or in appropriate combination. Typically, however, the in-store communication network 7 is a LAN.

[0017] At the store where the store system 100 is installed, 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 the check-out data are different for each 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 two-dimensional codes for store A are represented as TCIA and TCOA, and the two-dimensional codes for store B are represented as TCIB and TCOB.

[0018] The check-in data represents, for example, information as shown below. (1) The operating version of the store system 100. For example, the check-in data represented by the two-dimensional code TCIA represents the operating version of the store system 100-1. The check-in data represented by the two-dimensional code TCIB represents the operating version of the store system 100-2. (2) A merchant code for identifying the merchant operating the store where the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TCIA represents the merchant code assigned to the merchant operating store A. The check-in data represented by the two-dimensional code TCIB represents the merchant code assigned to the merchant operating store B. (3) A store code for identifying the store where the store system 100 is provided. For example, the check-in data represented by the two-dimensional code TCIA represents the store code assigned to Store A. The check-in data represented by the two-dimensional code TCIB represents the store code assigned to Store B. Note that the store code may be able to identify each of all the stores using the transaction processing system, or may be able to identify each of a plurality of stores operated by the same operator.

[0019] (4) The name of the operator who operates the store where the store system 100 is provided. For example, the check-in data represented by the two-dimensional code TCIA represents the name of the operator who operates Store A. The check-in data represented by the two-dimensional code TCIB represents the name of the operator who operates Store B. (5) The name of the store where the store system 100 is provided. 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 indicating that it is check-in data. This state is, for example, "1". This flag is common to all two-dimensional codes TCI.

[0020] (7) The 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) The domain name of the relay server 400. This domain name is common to all two-dimensional codes TCI. However, a plurality of relay servers 400 with different domain names may be used separately for each store. And 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 operator of store A. The check-in data represented by the two-dimensional code TCIB represents an address for accessing, via the communication network 500, an electronic receipt server that provides an electronic receipt service used by the operator of store B. The said address may be common to all two-dimensional codes TCI, or any of a plurality of addresses may be represented for each two-dimensional code TCI.

[0021] (10) A flag indicating whether the user terminal 200 should use either wireless communication with the access point 6 or wireless communication with the communication network 500 for data transfer with the store system 100. For example, in store A, if wireless communication with the access point 6 is used for data transfer between the store system 100-1 and the user terminal 200, the said flag is, for example, set to "1". For example, in store B, if wireless communication with the communication network 500 is used for data transfer between the store system 100-2 and the user terminal 200, the said flag is, for example, set to "0". (11) An SSID (service set identifier) for identifying the access point 6. For example, the check-in data represented by the two-dimensional code TCIA represents the SSID for identifying the access point 6 included in the store system 100-1. The 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) 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) Identification number of the security method used by the access point 6. For example, for the WPA2-PSK method, "1" is assigned, for the WPA-PSK method, "2" is assigned, and for the WEP method, "3" is assigned. For example, if the access point 6 included in the store system 100-1 uses the WPA2-PSK method as the security method, the check-in data represented by the two-dimensional code TCIA represents "1" as the identification number. Also, for example, if the access point 6 included in the store system 100-2 uses the WPA-PSK method as the security method, the check-in data represented by the two-dimensional code TCIB represents "2" as the identification number. (14) A flag for identifying whether to consider it an error when the user terminal 200 fails to connect to the relay server 400 or to continue operation without considering it an error. For example, in store A, if it is set to consider it an error when the user terminal 200 fails to connect to the relay server 400, the check-in data represented by the two-dimensional code TCIA represents, for example, "1" as the flag. Also, for example, in store B, if it is set to continue operation even when the user terminal 200 fails to connect to the relay server 400, the check-in data represented by the two-dimensional code TCIB represents, for example, "0" as the flag. (15) Identification number of the transmission mode regarding 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 assigned as follows: 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 represents "1" as the identification number. Also, for example, in store B, if the second mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TCIB represents "2" as the identification number.

[0023] (16) Identification number of the transmission mode regarding the log file storing the log data of the user terminal 200. The transmission modes include, for example, a first mode, a second mode, a third mode, and a fourth mode. The identification numbers of the transmission modes are assigned as follows: 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 represents "1" as the identification number. Also, for example, in store B, if the second mode is applied as the transmission mode, the check-in data represented by the two-dimensional code TCIB represents "2" as the identification number. (17) Host name or IP address used when transmitting the log file to the relay server 400 via the communication network 500 by FTP (file transfer protocol). (18) The user name used when transmitting the log file to the relay server 400 via the communication network 500 by FTP.

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

[0025] (22) The time until the camera screen is automatically switched on the user terminal 200. The check-in data represented by the two-dimensional code TCIA represents the time preset for store A as this time. The check-in data represented by the two-dimensional code TCIB represents the time preset for store B as this 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 preset for store A as this time. The check-in data represented by the two-dimensional code TCIB represents the time preset for store B as this time. (24) The number of times retries are allowed when the 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 preset for store A as this number. The check-in data represented by the two-dimensional code TCIB represents the number of times preset for store B as this time.

[0026] (25) The 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 preset for store A as such time. The check-in data represented by the two-dimensional code TCIB represents the time preset for store B as such time. (26) The number of times retry is allowed when the 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 preset for store A as such number of times. The check-in data represented by the two-dimensional code TCIB represents the number of times preset for store B as such time. (27) Authentication data used in the authentication process for authenticating the declaration of the end of confirmation regarding a transaction targeting products that require confirmation by a store clerk. The check-in data represented by the two-dimensional code TCIA represents the authentication data preset for store A. The check-in data represented by the two-dimensional code TCIB represents the authentication data preset for store B. It is preferable that the authentication data is determined to be different for each store, but the same authentication data may be set for different stores.

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

[0028] (31) A flag for identifying whether to allow registration on the user terminal 200 for a product with a purchaser age limit (hereinafter referred to as an age-restricted product). For example, if registration on the user terminal 200 for an age-restricted product is allowed in store A, the check-in data represented by the two-dimensional code TCIA represents, for example, "1" as the flag. Also, for example, if code settlement is not allowed in store B, the check-in data represented by the two-dimensional code TCIB represents, for example, "0" as the flag. (32) Data for identifying the input mode of the member code of a point member. For example, if the store system 100-1 is set to the mode of manually entering the member code, the check-in data represented by the two-dimensional code TCIA represents, for example, "1" as the data. Also, for example, if the store system 100-2 is set to the mode of entering the member code by barcode reading, the check-in data represented by the two-dimensional code TCIB represents, for example, "2" as the data. When the mode of manually entering the member code of a point member is set, a flag for identifying whether the store clerk's confirmation is required when entering the member code. For example, if such confirmation is required at store A, the check-in data represented by the two-dimensional code TCIA represents, for example, "1" as the flag. Also, for example, if such confirmation is not required at store B, the check-in data represented by the two-dimensional code TCIB represents, for example, "0" as the flag.

[0029] (34) A threshold for checking the battery remaining amount of the user terminal 200 at the time of check-in. The threshold is set for each store or each operator. For example, when the operator operating store A sets the threshold to "20%", the check-in data represented by the two-dimensional code TCIA represents, for example, "20" as the threshold. Also, for example, when store B sets the threshold to "25%", the check-in data represented by the two-dimensional code TCIB represents, for example, "25" as the threshold. The above are examples of the information represented by the check-in data. However, the check-in data may not include some of the various types of information shown above. Also, the check-in data may represent information different from the various types of information shown above.

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

[0031] Processor 11 corresponds to the central part of the above computer. Processor 11 executes information processing for realizing various functions as the store server 1 according to information processing programs such as an operating system and application programs. Processor 11 may be, for example, a processing circuit such as a CPU (central processing unit), a GPU (Graphics Processing Unit), an application specific integrated circuit (ASIC), or a programmable logic device (for example, a simple programmable logic device (SPLD), a complex programmable logic device (CPLD), a field programmable gate array (FPGA)). Processor 11 is not limited to being configured as a single processing circuit, and may be configured as Processor 11 by combining a plurality of processing circuits. Note that the same applies to other processors according to this embodiment.

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

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

[0034] The communication interface 14 performs data communication with each part connected to the in-store communication network 7 according to a predetermined communication protocol. As the communication interface 14, for example, a well-known communication device for a LAN can be applied. The transmission path 15 includes an address bus, a data bus, control signal lines, etc., and transmits data and control signals exchanged between the connected parts. 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 application APAA which is one of the information processing programs. The store management application APAA is an application program and describes the information processing for realizing the function as the store server 1 when executed by the processor 11. The store management application APAA may be separate ones created according to the store operation policy for each store or for each operator operating the store. For example, if the sales data management methods are different between store A and store B, the store management application APAA used in the store system 100-1 describes the information processing for the management of sales data adapted to the sales data management method in store A, and the store management application APAA used in the store system 100-2 describes the information processing for the management of sales data adapted to the sales data management method in store B.

[0036] A part 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 a plurality of databases for various information management. One of the databases included in the database group DBAA is a product database for managing products sold in the store. The product database is a set of data records associated with the products to be managed. The data records of the product database include data related to the associated products, such as product codes, prices, and product names. The product code is an identifier defined for identifying products on a per-SKU (stock keeping unit) basis, and for example, a JAN (Japanese article number) code is used. The product name is a name defined so that humans can easily distinguish products. The price is the amount that serves as the consideration for selling the product.

[0037] One of the databases included in the database group DBAA is a user database for managing users of the store. The user database is a set of data records associated with customers registered as users. The data records of the user database include data related to the associated customers, such as user codes and attribute information for identifying users. The user code is a unique identification code defined for each customer to individually identify the user. The attribute information may include name, gender, age, address, phone number, etc. Also, the data records of the user database may include payment information declared by the user. The payment information is, for example, a credit number or a code payment ID (identifier). Also, when multiple payment methods can be selected, the payment information may include a payment method code for identifying the payment method. Also, in the case of a store that provides a point service, the payment information may include the ID of the point service and the number of points held.

[0038] Also, one of the databases included in the database group DBAA is a store clerk terminal database. The store clerk terminal database represents terminal codes as identifiers for identifying the store clerk terminals 300 used in the store. For example, terminal codes of terminals designated as store clerk terminals 300 in the store are set in the store clerk terminal database in advance. Alternatively, the store clerk using the store clerk terminal 300 may be authenticated, and the terminal code of the store clerk terminal 300 that has been confirmed to be used by a predetermined store clerk may be set in the store clerk terminal database. The database group DBAA can be used to determine whether the terminal that has accessed the store system 100 from the store clerk terminal 300 is a terminal designated for store clerks. The terminal code of the store clerk terminal 300 is an example of an identifier of a second terminal. The terminal code of the store clerk terminal 300 may be in any form as long as it can identify the store clerk terminal 300.

[0039] In addition, the database group DBAA may include various databases managed by a POS server in an existing POS system. Note that what databases the database group DBAA includes, or what data those databases contain and in what structure, may be determined for each store.

[0040] FIG. 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, the main memory 22, the auxiliary storage unit 23, and the communication interface 24 are capable of communicating via the transmission path 25. And since the processor 21, the main memory 22, and the auxiliary storage unit 23 are connected by the transmission path 25, a computer for controlling the virtual POS server 2 is configured. Note that since the outlines of the functions of the processor 21, the main memory 22, the auxiliary storage unit 23, the communication interface 24, and the transmission path 25 are 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, the description thereof is 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 and describes information processing for realizing the functions as the virtual POS server 2 when executed by the processor 21. The virtual POS application APBA may be separate ones created according to the store operation policies for each store or for each operator who operates the store. For example, if store A provides a discount service that is not provided in store B, the virtual POS application APBA used in the store system 100-1 describes the information processing for realizing the discount service, and the virtual POS application APBA used in the store system 100-2 does not describe the information processing for realizing the discount service. For example, the virtual POS application APBA and the hardware in a state where it is not stored in the auxiliary storage unit 23 are provided separately. Then, in response to an operation by an arbitrary operator, the virtual POS application APBA is written into the auxiliary storage unit 23. 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 stored in a removable computer-readable storage medium such as a magnetic disk, a magneto-optical disk, an optical disk, a semiconductor memory, etc., or provided by communication via a network.

[0042] Also, a part of the storage area of the auxiliary storage unit 23 is used as an area for storing the transaction database DBBA instead of the database group DBAA. The transaction database DBBA is a set of data records associated with transactions with customers who are shopping in the store. The data records of the transaction database DBBA include a transaction code and product data regarding products already registered as purchased products. The transaction code is a unique identification code set for each transaction to identify each individual transaction. The product data represents a product code, a product name, a price, a quantity, etc. The structure of the transaction database DBBA may be determined individually according to the store operation policy for each store or for each operator operating the store. The product data regarding the purchased products is an example of the content of the transaction regarding the user. The transaction code is an example of a transaction identifier for identifying the 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 certain transaction. A part of the storage area of the auxiliary storage unit 23 is an example of the first storage unit.

[0043] FIG. 4 is a block diagram showing the main circuit configuration of the mobile controller 3. The mobile controller 3 includes a processor 31, a main memory 32, an auxiliary storage unit 33, a communication interface 34, and a transmission path 35. The processor 31, the main memory 32, the auxiliary storage unit 33, and the communication interface 34 are communicable via the transmission path 35. And since the processor 31, the main memory 32, and the auxiliary storage unit 33 are connected by the transmission path 35, a computer for controlling the mobile controller 3 is configured. Note that since the outlines of 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 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, the description thereof is omitted.

[0044] However, the auxiliary storage unit 33 stores a registration support application APC A instead of the store management application APAA. The registration support application APC A is an application program, and is described for information processing, which will be described later, for supporting the registration of purchased goods when executed by the processor 31. The registration support application APC A is common to each store system 100. However, various settings for the information processing based on the registration support application APC A may be customized for each store system 100. For example, the hardware in a state where the registration support application APC A is not stored in the auxiliary storage unit 33 and the registration support application APC A are provided separately. Then, according to the operation of an arbitrary operator, the registration support application APC A is written into the auxiliary storage unit 33. Alternatively, the mobile controller 3 may be provided with the registration support application APC A stored in the auxiliary storage unit 33. The registration support application APC A can be stored in a removable computer-readable storage medium such as a magnetic disk, a magneto-optical disk, an optical disk, a semiconductor memory, or the like, or provided by communication via a network.

[0045] A part of the storage area of the auxiliary storage unit 33 is used as an area for storing a transaction management database DBCA, a cooperation database DBCB, and a registration database DBCC instead of the database group DBAA. The structures of these transaction management database DBCA, cooperation database DBCB, and registration database DBCC are common to each store system 100.

[0046] FIG. 5 is a schematic diagram showing the data structure of a data record DRA included in the transaction management database DBCA. The transaction management database DBCA is a set of data records DRA associated with the user terminal 200 used by a customer in the store. Therefore, when there is one customer using the user terminal 200 in the store, the transaction management database DBCA includes one data record DRA. Also, when there is no customer using the user terminal 200 in the store, the transaction management database DBCA does not include the data record DRA. And the data record DRA includes fields FAA, FAB, and FAC.

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

[0048] FIG. 6 is a schematic diagram showing the data structure of the data record DRB included in the cooperation database DBCB. As will be described later, the cooperation database DBCB is a set of data records DRB associated with the clerk terminal 300 that cooperates with the process of storing the details of the transaction in response to a request from the user terminal 200. For this reason, when there is only one cooperating clerk terminal 300, the cooperation database DBCB includes only one data record DRB. Also, when there is no clerk terminal 300 cooperating with the user terminal 200, the cooperation database DBCB does not include the data record DRB. And the data record DRB includes fields FBA and FBB.

[0049] The terminal code of the associated clerk terminal 300 is set in the field FBA. The terminal code of the user terminal 200 with which the associated clerk terminal 300 is cooperating is set in the field FBB. The data record DRB is an example of the association between the user terminal 200 (the first terminal) and the clerk terminal 300 (the second terminal). Also, a part of the storage area of the auxiliary storage unit 33 that stores the cooperation database DBCB is an example of the third storage unit.

[0050] FIG. 7 is a schematic diagram showing the data structure of the data record DRC included in the registration database DBCC. The registration database DBCC is a set of data records DRC associated with transactions with customers who are shopping in the store. And the data record DRC includes fields FCA and FCB. The data record DRC may also include fields FCC, FCD, ….

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

[0052] When two or more purchased products are attempted to be registered for the associated transaction in the data record DRC, fields after the field FCC are included. And in the fields after the field FCC, the same registration data as in the field FCB is set.

[0053] Figure 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 sensor group 207, a wireless communication unit 208, a mobile communication unit 209, a transmission path 210, and the like. The processor 201 can communicate with the main memory 202, the auxiliary storage unit 203, the touch panel 204, the camera 205, the sound unit 206, the sensor group 207, the wireless communication unit 208, and the mobile communication unit 209 via the transmission path 210. And the processor 201, the main memory 202, and the auxiliary storage unit 203 are connected by the transmission path 210, thereby constituting a computer for controlling the user terminal 200. Note that the outlines of the functions of the processor 201, the main memory 202, the auxiliary storage unit 203, and the transmission path 210 are the same as those of the processor 11, the main memory 12, the auxiliary storage unit 13, and the transmission path 15, so the description thereof is omitted.

[0054] The touch panel 204 functions as an input device and a display device of 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 by means of the image sensor. The sound unit 206 outputs various sounds such as voices 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 through wireless communication according to a wireless communication protocol. As the wireless communication unit 208, for example, a well-known communication device compliant with the IEEE802.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] Note that 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, and when executed by the processor 201, it 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 commonly used by a plurality of user terminals 200.

[0057] FIG. 9 is a block diagram showing the main circuit configuration of the store clerk terminal 300. In addition to the barcode scanner 301, the store 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, a transmission path 308, and the like. The processor 302, 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 are communicable via the transmission path 308. And, by connecting the processor 302, the main memory 303, and the auxiliary storage unit 304 by the transmission path 308, a computer for controlling the store clerk terminal 300 is configured. Note that since the outlines of the functions of the processor 302, the main memory 303, the auxiliary storage unit 304, the touch panel 305, the sound unit 306, the wireless communication unit 307, and the transmission path 308 are equivalent to those of the processor 11, the main memory 12, the auxiliary storage unit 13, the touch panel 204, the sound unit 206, the wireless communication unit 208, and the transmission path 15, the description thereof is omitted.

[0058] Note that the auxiliary storage unit 304 stores a store clerk terminal application APEA which is one of the information processing programs. The store clerk terminal application APEA is an application program, and is described for the information processing described later for causing the store clerk terminal 300 to function as a user interface for the store clerk of the store system 100 when executed by the processor 302. The store clerk terminal application APEA is commonly used in the store clerk terminal 300.

[0059] As the hardware of the store employee terminal 300, for example, a general-purpose tablet computer or the like can be used. The store employee terminal application APEA and the hardware in a state where it is not stored in the auxiliary storage unit 304 or in a state where an application program of the same type but different version is stored in the auxiliary storage unit 304 may be provided individually. In this case, the store employee terminal 300 is configured by writing the store employee terminal application APEA to the auxiliary storage unit 304 in response to the operation of any operator. Also, the store employee terminal 300 may be provided with the store employee terminal application APEA stored in the auxiliary storage unit 304. The store employee terminal application APEA can be provided by recording it 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 content of each of the various processes described below is an example, and it is possible to appropriately change the order of some processes, omit some processes, or add other processes. For example, in the following description, in order to explain the characteristic operations of the present embodiment in an easy-to-understand manner, the description of some processes is omitted. For example, when some error occurs, a process for dealing with the error may be performed, but the description of some of such processes is omitted.

[0061] Note that the service provided to the customer by the operation of the transaction processing system described below is referred to as the smartphone POS service. In order for the user terminal 200 to exchange data with the store system 100 for using the smartphone POS service, whether to use wireless communication with the access point 6 or wireless communication with the communication network 500 for such communication is determined by the state of the flag included in the check-in data. However, in the following, for the sake of simplicity of explanation, the case of using only wireless communication with the access point 6 will be described. Also, in order to cause the accounting machine 5 to perform accounting, whether to use the mode of transferring data from the virtual POS server 2 to the accounting machine 5 or the mode of transferring data from the mobile controller 3 to the accounting machine 5 without a request from the accounting machine 5 is determined by the state of the flag included in the check-in data. However, in the following, for the sake of simplicity of explanation, it will be described that the mode of requesting the mobile controller 3 to transfer data from the accounting machine 5 is fixedly used.

[0062] In order for a customer to use the smartphone POS service, the customer installs the smartphone POS app APDA on a smartphone or the like owned by the customer and makes it available as the user terminal 200. Alternatively, the customer borrows at the store a user terminal 200 configured by installing the smartphone POS app APDA on a tablet computer or the like. Then, the customer enters any store where the store system 100 is provided with the user terminal 200 in a state where information processing based on the smartphone POS app APDA is started.

[0063] Now, in the user terminal 200, the processor 201 executes predetermined information processing by executing the smartphone POS app APDA. FIG. 10, FIG. 11, FIG. 12, and FIG. 13 are flowcharts of information processing performed by the processor 201 by executing the smartphone POS app APDA. First, as ACT101 shown in FIG. 10, the processor 201 generates image data of the main menu screen to be displayed on the touch panel 204 so that the main menu screen is displayed on the touch panel 204. The main menu screen is a screen for receiving a designation of any of several processes to be performed based on the smartphone POS app APDA. A plurality of GUI (graphical user interface) elements including GUI elements for designating the start of shopping are arranged on the main menu screen. Note that the GUI elements are, for example, soft keys.

[0064] As ACT102, the processor 201 checks whether the start of shopping has been designated. If the processor 201 cannot confirm the corresponding designation, it determines NO and proceeds to ACT103. As ACT103, the processor 201 checks whether a designation other than the start of shopping has been made. If the processor 201 cannot confirm the corresponding designation, it determines NO and returns to ACT102. Thus, as ACT102 and ACT103, the processor 201 waits for any designation on the main menu screen. If a designation other than the start of shopping is made, the processor 201 determines YES in ACT103 and proceeds to the designated process. Note that the description of the process of the processor 201 in this case is omitted.

[0065] When a customer enters the store and starts shopping, the customer performs a predetermined operation for designating the start of shopping on the main menu screen. When the processor 201 detects an operation for designating the start of shopping, for example, on the touch panel 204, it determines YES in ACT102 and proceeds to ACT104. As ACT104, the processor 201 generates image data of a scan screen for check-in to be displayed on the touch panel 204 so that the scan screen for check-in is displayed on the touch panel 204. The scan screen for check-in is a screen that prompts the customer to read a two-dimensional code TCI for check-in. For example, the processor 201 activates the camera 205 and superimposes on the image obtained by the camera 205 a character message that prompts the customer to read the two-dimensional code TCI and a line indicating a guide to the position where the two-dimensional code TCI should be blocked to generate the scan screen.

[0066] When the scan screen is displayed on the touch panel 204, the customer turns the camera 205 toward the two-dimensional code TCI so that the two-dimensional code TCI posted near the entrance of the store is reflected on the scan screen. As ACT105, 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. The reading of this two-dimensional code may be performed as a process based on the smartphone POS app APDA or as a process based on another application program for reading two-dimensional codes. Then, if the two-dimensional code is read, the processor 201 determines YES and proceeds to ACT106.

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

[0068] If the processor 201 can confirm that the data represented by the read two-dimensional code is check-in data, it determines YES in ACT106 and proceeds to ACT107. As ACT107, the processor 201 stores the read check-in data in the main memory 202 or the auxiliary storage unit 203.

[0069] As ACT108, the processor 201 requests a 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 the two-dimensional code TCIA is pointed at by the camera 205 by the customer at 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. Then, the processor 201 transmits, addressed to the mobile controller 3, request data for requesting a check-in via the wireless communication with the access point 6. When the wireless communication with the access point 6 provided in the store system 100-1 is 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 and the in-store communication network 7 provided in the store system 100-1. Note that the request data for requesting a check-in includes identification data for identifying that it is a check-in request and the terminal code of the own terminal by the processor 201. When 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 include other data such as data for authenticating the customer in the request data.

[0070] In addition, various requests from the user terminal 200 to the mobile controller 3 described hereinafter are realized 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, in the same manner as described above.

[0071] In the mobile controller 3, when the processor 31 receives request data for requesting a check-in by the communication interface 34, it starts the execution of the registration support application APC A and performs information processing related to the transaction with the customer attempting to check in (hereinafter referred to as transaction processing). FIG. 14, FIG. 15, and FIG. 16 are flowcharts of the transaction processing performed by the processor 31 by executing the registration support application APC A.

[0072] Each time the processor 31 receives request data for requesting a check-in by the communication interface 34, it starts the transaction processing. If transaction processing already started based on another request is being executed, a new transaction processing is started in parallel therewith. That is, the processor 31 may execute a plurality of transaction processes in parallel, each targeting a plurality of user terminals 200. Hereinafter, when simply referred to as the "user terminal 200", it shall refer to the user terminal 200 that is the target of the transaction processing being described.

[0073] As ACT201 in FIG. 14, the processor 31 performs check-in processing. For example, the processor 31 requests the start of a transaction from the virtual POS server 2 and receives a notification of a transaction code. Then, the processor 31 adds a new data record DRA with the terminal code included in the request data 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 sets the notified transaction code in field FAC of the new data record DRA. Thereby, the management of the transaction performed using the user terminal 200 that requested the check-in is started.

[0074] In the virtual POS server 2, if the processor 21 is requested to start a transaction from the mobile controller 3, the processor 21 determines a transaction code according to a predetermined rule and starts the registration process of the purchased goods associated with the transaction code. Also, the processor 21 notifies the determined transaction code to the mobile controller 3.

[0075] As ACT202, the processor 31 checks whether the check-in process has been completed normally. If the processor 31 cannot complete the check-in process normally due to some abnormality, it determines NO and proceeds to ACT203.

[0076] As ACT203, the processor 31 notifies an error to the user terminal 200. For example, the processor 31 transmits notification data for 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 it is a notification of an error in the notification data. The processor 31 may include an error code representing the cause of the error in the notification data.

[0077] In addition, various notifications from the mobile controller 3 to the user terminal 200, which will be described later, 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, in the same manner as described above. Then, the processor 31 ends the transaction process.

[0078] On the other hand, if the processor 31 can normally complete the check-in process, it determines YES at ACT202 and proceeds to ACT204. As ACT204, the processor 31 notifies the user terminal 200 that the check-in is completed.

[0079] In the user terminal 200, after the processor 201 requests a check-in at ACT108 in FIG. 10, it proceeds to ACT109. As ACT109, the processor 201 checks whether a check-in completion has been notified. If the processor 201 cannot confirm the notification, it determines NO and proceeds to ACT110. As ACT110, the processor 201 checks whether a check-in error has been notified. If the processor 201 cannot confirm the notification, it determines NO and returns to ACT109. Thus, as ACT109 and ACT110, the processor 201 waits for a check-in completion or error to be notified. If the processor 201 receives the notification data for the above-described error notification by the wireless communication unit 208, it determines YES at ACT110 and proceeds to ACT111.

[0080] As ACT111, 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 defined as a screen for notifying the customer that check-in cannot be performed. If the processor 201 is instructed to cancel the display of the error screen, for example, by operating GUI elements shown in the error screen, it returns to ACT101.

[0081] On the other hand, if the processor 201 determines YES at ACT109 when the notification data for the above-mentioned check-in completion notification is received by the wireless communication unit 208, it proceeds to ACT112 in FIG. 11. As ACT112, the processor 201 generates image data of a 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 representing a list of registered purchased items.

[0082] FIG. 17 is a diagram showing an example of the list screen SCA presented to the customer. The list screen SCA includes display areas ARAA and ARAB and buttons BUAA, BUAB, BUAC, and BUAD. The display area ARAA represents the total number of purchased items and the total amount of the purchase price. The display area ARAB represents a list of purchased items. The button BUAA is a soft key for the customer to specify canceling all purchased items and aborting shopping. The button BUAB is a soft key for the customer to specify starting the scan of items to be registered as purchased items. The button BUAC is a soft key for the customer to specify starting checkout. The button BUAD is a soft key for the customer to specify the assistance service described later.

[0083] Note that the list screen SCA shown in FIG. 17 shows a state where registration of purchased items has not been performed yet. Therefore, both the total number and the total amount are represented as "0" in the display area ARAA, and nothing is represented in the display area ARAB.

[0084] As ACT113 in FIG. 11, the processor 201 checks whether the start of the assistance service has been specified. If the processor 201 cannot confirm the corresponding specification, it determines NO and proceeds to ACT114. As ACT114, the processor 201 checks whether the start of scanning the product has been specified. If the processor 201 cannot confirm the corresponding specification, it determines NO and proceeds to ACT115. As ACT115, the processor 201 checks whether a change in quantity has been specified. If the processor 201 cannot confirm the corresponding specification, it determines NO and proceeds to ACT116. As ACT116, the processor 201 checks whether the cancellation of shopping has been specified. If the processor 201 cannot confirm the corresponding specification, it determines NO and proceeds to ACT117. As ACT117, the processor 201 checks whether the start of accounting has been specified. If the processor 201 cannot confirm the corresponding specification, it determines NO and proceeds to ACT118. As ACT118, the processor 201 checks whether the display of the list screen has been instructed. If the processor 201 cannot confirm the corresponding instruction, it determines NO and returns to ACT113. Thus, as ACT113 to ACT118, the processor 201 waits for any of the start of assistance, start of scanning, quantity, cancellation, and start of accounting to be specified, or for the display of the list screen to be instructed.

[0085] Now, in the mobile controller 3, after the processor 31 gives a notice of check-in completion at ACT204 in FIG. 14, it proceeds to ACT205. As ACT205, the processor 31 checks whether the user terminal 200 has requested registration of the product to be purchased. If the processor 31 cannot confirm the corresponding request, it determines NO and proceeds to ACT206. As ACT206, the processor 31 checks whether the user terminal 200 has requested a quantity change. If the corresponding request cannot be confirmed, the processor 31 determines NO and proceeds to ACT207. As ACT207, the processor 31 checks whether the user terminal 200 has requested deletion of a purchased item. If the corresponding request cannot be confirmed, the processor 31 determines NO and proceeds to ACT208. As ACT208, the processor 31 checks whether the user terminal 200 has requested cancellation of a purchased item. If the corresponding request cannot be confirmed, the processor 31 determines NO and proceeds to ACT209. As ACT209, the processor 31 checks whether the user terminal 200 has requested accounting. If the corresponding request cannot be confirmed, the processor 31 determines NO and returns to ACT205. Thus, as ACT205 to ACT209, the processor 31 waits for the user terminal 200 to request any of registration, quantity change, deletion, cancellation, and accounting.

[0086] If the customer registers an item as a purchased item, the customer designates the start of scanning by a predetermined operation such as touching the button BUAB on the list screen SCA. In response, the processor 201 determines YES in ACT114 in FIG. 11 and proceeds to ACT119. As ACT119, the processor 201 regenerates the image data of the registration screen 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 the barcode representing the product code of the product to be registered as a purchased item.

[0087] FIG. 18 is a diagram showing an example of the registration screen SCB presented to the customer. The registration screen SCB includes a display area ARBA, a message MEBA, and a button BUBA. The display area ARBA displays an image obtained by the camera 205. The message MEBA is a character message that prompts the customer to read the barcode of the product. The button BUBA is a soft key for the customer to specify aborting the scan of the product code. The processor 201, for example, activates the camera 205, and thereby generates the registration screen SCB by superimposing an image representing the range of the display area ARBA, the message MEBA, and the button BUBA on the image obtained by the camera 205.

[0088] As ACT120 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 another application program for barcode reading. And if the processor 201 determines that the barcode cannot be read, it proceeds to ACT121. As ACT121, the processor 201 checks whether the scan has been specified to be aborted. And if the processor 201 cannot confirm the corresponding specification, it determines NO and returns to ACT120. Thus, as ACT120 and ACT121, the processor 201 waits for the barcode to be read or for the scan to be specified to be aborted.

[0089] If the customer wishes to return to the display state of the list screen SCA without performing the current scan, the customer specifies scan cancellation by a predetermined operation such as touching the button BUBA. In response, the processor 201 determines YES at ACT121 and returns to ACT112. In this case, since the registration state of the purchased product is not changed, the processor 201 regenerates the image data of the list screen SCA in the same state as that displayed on the touch panel 204 before displaying the deletion screen so that the list screen SCA in the same state as that displayed before displaying the deletion screen is again displayed 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 so that the barcode displayed on the product to be registered as a purchased product is reflected in the display area ARBA. In response, the processor 201 determines YES at ACT120 and proceeds to ACT122. As ACT122, the processor 201 requests registration from the mobile controller 3. The processor 201 includes, in the request data to be transmitted here, the data represented by the read barcode (hereinafter referred to as barcode data).

[0091] If the registration of a purchased product is requested from the user terminal 200 as described above, the processor 31 determines YES at ACT205 in FIG. 14 and proceeds to ACT210. As ACT210, the processor 31 notifies the virtual POS server of the transaction code and transfers the registration request (request data). The processor 31 refers to the transaction management database DBCA using the terminal code of the user terminal 200 that makes the registration request and acquires 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 after conversion 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] In the virtual POS server 2, the processor 21 executes the virtual POS application APBA and assumes that the barcode data included in the request data sent from the mobile controller 3 has been read by the barcode scanner provided in the existing POS terminal, and attempts to register the purchased goods by the same process as the existing POS terminal. However, due to some reasons, the product code represented by the barcode data may not be registered in the product database. In addition, there may be a barcode other than the one representing the product code displayed on the product. In these cases, the processor 21 cannot register the purchased goods and regards it as an error.

[0093] Thus, by transferring the registration request from the user terminal 200 by the processor 31 of the mobile controller 3 and registering the purchased goods by the processor 21 of the virtual POS server 2 based on this registration request, the product data sent from the user terminal 200, which is an example of the first terminal, is stored in the transaction database DBBA in the auxiliary storage unit 23 of the virtual POS server 2 as the products purchased by the user (customer) of the user terminal 200. Thus, when the processor 21 executes the virtual POS application APBA and the processor 31 executes the registration support application APCA, the functions of the first registration unit are realized by the computer (virtual POS server 2) with the processor 21 as the central part and the computer (mobile controller 3) with the processor 31 as the central part.

[0094] The processor 21 transmits the result data representing the result of such processing to the mobile controller 3. When the registration of the purchased goods can be performed correctly, the processor 21 includes, in the result data, identification data for identifying that it is a notification of regular registration, the product code, product name, and price of the registered product. When it is regarded as an error, the processor 21 includes, in the result data, identification data for identifying that it is a notification of error and the barcode data sent in the registration request.

[0095] After the processor 31 in the mobile controller 3 transfers the registration request at ACT210, it proceeds to ACT211. As ACT211, 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] As ACT212, the processor 31 updates the registration database DBCC based on the above result data. The update of this registration database DBCC is performed, for example, as follows. First case: A notification of regular registration, and when the data record DRC associated with the transaction to be processed does not contain the registration data including the notified product code. In this case, the processor 31 adds a new field next to the last field already existing in the data record DRC associated with the transaction to be processed, and adds the new registration data to the said field. The processor 31 includes in the new registration data the notified product code, an error flag set to "0" indicating that it is not an error, the notified product name and price, a quantity set to "1", and a cancellation flag set to "0" indicating that it has not been cancelled. Thus, the registration data added in this case has a structure as shown in the upper right of FIG. 6.

[0097] Second case: A notification of regular registration, and when the data record DRC associated with the transaction to be processed contains the registration data including the notified product code, but the cancellation flag of the said registration data is set to "1" indicating that it has been cancelled. In this case, the processor 31 processes in the same way as in the first case above.

[0098] Third case: A notification of regular registration, and when the data record DRC associated with the transaction to be processed contains the registration data including the notified product code, and the cancellation flag of the said registration data is set to "0". In this case, the processor 31 rewrites the value of the count included in the registration data that contains the notified product code and has a cancellation flag of "0" to a value that is one greater.

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

[0100] By being updated in this way by the processor 31, the registration database DBCC represents a list of purchased products registered in the virtual POS server 2, and in addition to this, records the barcode reading that resulted in an error.

[0101] Note that the processor 31 stores the barcode data sent in the registration request in the main memory 32 or the auxiliary storage unit 33, and in the above fourth case, may include this stored barcode data in the registration data. And in this case, in the virtual POS server 2, the processor 21 does not necessarily include the barcode data in the result data. Also, the processor 31 may extract the product code from the stored barcode data and perform the processing of the first to third cases based on this product code. Also, the product name and price may be acquired by the processor 31 from the store server 1 or the like based on the product code.

[0102] The processor 31 then proceeds to ACT213. As ACT213, 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 it is an instruction 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 the product code, product name, price, and quantity included in the data record DRC associated in the registration database DBCC for the transaction to be processed in the instruction data.

[0103] In addition, various instructions from the mobile controller 3 to the user terminal 200 described hereinafter 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 in the same manner as above. After this, the processor 31 returns to the waiting state of ACT205 to ACT209.

[0104] After the processor 201 in the user terminal 200 requests registration at ACT122 in FIG. 11, it proceeds to ACT123. As ACT123, the processor 201 waits for the display of the list screen SCA to be instructed. Then, if the display of the list screen SCA is instructed from the mobile controller 3 as described above, the processor 201 determines YES, returns to ACT112, and generates image data of the list screen SCA displayed on the touch panel 204 so that the list screen SCA is again displayed on the touch panel 204. At this time, the processor 201 makes the list screen SCA a screen representing the product name, price, and quantity of the purchased product included in the instruction data. Therefore, the customer can repeatedly specify the start of scanning and sequentially cause the user terminal 200 to read the barcodes of the products to be registered, thereby registering the products as purchased products.

[0105] FIG. 19 is a diagram showing an example of the list screen SCA representing the state of the purchased products that have been registered and presented to the customer. The list screen SCA shown in FIG. 19 is an example where there is 1 item with the product name "AAA" and a price of 120 yen, 2 items with the product name "BBB" and a price of 98 yen, and 1 item with the product name "CCC" and a price of 1,024 yen, and they are already registered as purchased items. In the list screen SCA shown in FIG. 19, the display area ARAB shows the product name, price, and quantity regarding these registered items. Also, in the display area ARAA, "4" is shown as the total quantity and "1,340" is shown as the total amount. Note that the area surrounded by the dashed line on the left side of the product name represents the area for displaying an icon. The dashed line representing this area is not actually shown on the list screen SCA.

[0106] The camera 205 of the user terminal 200 is not often an optimized reading device for barcode reading. For this reason, it may be difficult to read barcodes. Also, there may be cases where barcodes are not displayed on products. When a customer wants the help of a store clerk, for example, when barcode reading on the user terminal 200 fails, the customer specifies the assistance service by performing a predetermined operation such as touching the button BUAD on the list screen SCA.

[0107] When such an assistance service is specified in the user terminal 200, the processor 201 determines YES at ACT113 in FIG. 11 and proceeds to ACT124. As ACT124, the processor 201 generates the image data of the cooperation screen displayed on the touch panel 204 so that the cooperation screen is displayed on the touch panel 204.

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

[0109] The customer calls the store clerk and presents the linked screen SCC. The linked screen SCC is used to cooperate with the store clerk terminal 300 in the process of storing the details of the transaction conducted in response to the request from the customer's user terminal 200. When receiving the presentation of the linked screen SCC, the store clerk activates the cooperation function of the store clerk terminal 300. In the store clerk terminal 300, when the cooperation function is activated, the processor 302 executes the store clerk terminal application APEA and performs predetermined processing. Figure 21 is a flowchart of the information processing performed by the processor 302 by executing the store clerk terminal application APEA.

[0110] As ACT301, the processor 302 generates image data of a guidance screen to be displayed on the touch panel 305 so that the guidance screen is displayed on the touch panel 305. The guidance screen is a screen that prompts the store clerk to scan the barcode BCCA shown on the linked screen SCC presented by the customer. Following the guidance screen, the store clerk makes the barcode scanner 301 scan the barcode BCCA shown 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] Note that when the barcode BCCA shown on the linked screen SCC is scanned, the customer gives an instruction to return by a predetermined operation such as touching the button BUCA. Also, when the customer cancels the use of the assistance service, the customer gives an instruction to return without presenting the linked screen SCC to the store clerk.

[0112] On the user terminal 200, with the cooperation screen SCC being displayed, the processor 201 proceeds to ACT125 in FIG. 11. As ACT125, the processor 201 waits for a return instruction. If the return is instructed as described above, the processor 201 determines YES, returns to ACT112, and processes the subsequent steps in the same manner as described above.

[0113] On the store clerk terminal 300, after the processor 302 displays a guidance screen on the touch panel at ACT301 in FIG. 21, it proceeds to ACT302. As ACT302, 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, since the terminal code of the user terminal 200 included in this barcode data can be acquired, the processor 302 determines YES and proceeds to ACT303.

[0114] As ACT303, the processor 302 requests cooperation with the mobile controller 3 for the process of storing the purchased goods (transaction details) performed in response to the request from the user terminal 200. Specifically, the processor 302 establishes wireless communication between the wireless communication unit 307 and the access point 6 according to the predetermined communication settings. Then, the processor 302 transmits request data for requesting cooperation to the mobile controller 3 addressed via the 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 request data for requesting cooperation includes identification data for identifying that it is a request for cooperation and the terminal code of the user terminal 200 included in the above barcode data.

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

[0116] In the mobile controller 3, when the processor 31 receives request data for requesting cooperation by the communication interface 34, it executes the registration support application APCA and starts information processing (hereinafter referred to as cooperation processing) for causing the store employee terminal 300 to cooperate with the registration process of the purchased goods being performed using the user terminal 200. FIG. 22 is a flowchart of the cooperation processing performed by the processor 31 by executing the registration support application APCA.

[0117] The processor 31 starts the cooperation processing every time request data for requesting cooperation is received by the communication interface 34. When the processor 31 has already executed the cooperation processing started based on a request from another store employee terminal, it starts a new cooperation processing in parallel therewith. That is, the processor 31 may execute a plurality of cooperation processes in parallel for each of a plurality of store employee terminals 300. In the following description regarding the cooperation processing, when simply referred to as the "store employee terminal 300", it shall refer to the store employee terminal 300 that is the target of the cooperation processing in the description.

[0118] As ACT401, the processor 31 checks whether the requester is the store clerk terminal 300. For example, the processor 31 inquires of the store server 1 whether the terminal identified by the terminal code of the source of the request data for requesting cooperation is the store clerk terminal 300. The store server 1 refers to the store clerk terminal database, which is part of the database group DBAA in the auxiliary storage unit 13 of the store server 1, using the inquired terminal code, and checks whether the terminal code is the code of a terminal defined for store clerks. If the inquired terminal code is included in the store clerk terminal database, it notifies the mobile controller 3 that it is the store clerk terminal 300, and if it is not included, it notifies that it is not the store clerk terminal 300. Therefore, if the processor 31 is notified by the store server 1 that it is not the store clerk terminal 300, it determines NO and proceeds to ACT402.

[0119] As ACT402, the processor 31 notifies the store clerk terminal 300 of the rejection of cooperation. For example, the processor 31 transmits notification data including identification data for identifying the rejection of cooperation to the store clerk terminal 300 via the in-store communication network 7 and the access point 6. And the processor 31 ends the cooperation process with this. That is, in this case, the processor 31 does not link the store clerk terminal 300 with the user terminal 200.

[0120] On the other hand, if the processor 31 is notified by the store server 1 that it is the store clerk terminal 300, it determines YES in ACT401 and proceeds to ACT403. As ACT403, the processor 31 updates the cooperation database DBCB to store the association between the terminal code of the user terminal 200 and the terminal code of the store clerk terminal 300 in order to indicate that the store clerk terminal 300 is in cooperation with the registration process of purchased goods 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 source of the request data in the field FBA and updates the cooperation database DBCB to include a new data record DRB in which the terminal code included in the request data is set in the field FBB.

[0121] As a result, the store clerk terminal 300 as the second terminal is linked to the process of storing the purchased goods (transaction details) carried out in response to a request from the user terminal 200 as the first terminal. Thus, by the processor 31 executing information processing based on the registration support application APCA, the computer (mobile controller 3) with the processor 31 as the central part functions as a linking unit.

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

[0123] After the processor 302 at the store clerk terminal 300 requests cooperation in ACT303 in FIG. 21, it proceeds to ACT304. As ACT304, the processor 302 checks whether the display of the registration status screen has been instructed. If the corresponding designation cannot be confirmed, the processor 302 determines NO and proceeds to ACT305. As ACT305, the processor 302 checks whether a rejection of cooperation has been notified. If the corresponding notification cannot be confirmed, the processor 302 determines NO and returns to ACT304. Thus, as ACT304 and ACT305, the processor 302 waits for either an instruction to display the registration status screen or a rejection notice.

[0124] When the processor 302 determines YES in ACT305 when notification data for notifying rejection is received by the wireless communication unit 307, it proceeds to ACT306. As ACT306, the processor 302 causes an error screen to be displayed on the touch panel 305. The error screen is a screen for notifying the store clerk of the inability to communicate. Then, the processor 302 waits for a declaration by the store clerk who has confirmed the notification on the error screen or waits for the end of a predetermined display period of the error screen, and then ends the information processing shown in FIG. 21.

[0125] When the processor 302 receives, at the wireless communication unit 307, instruction data for instructing the display of the registration status screen, it determines YES in ACT304 and proceeds to ACT307. As ACT307, 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 as a screen showing 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 product on the associated user terminal 200 by visually observing the registration status screen displayed on the touch panel 204. Then, the store clerk performs a predetermined operation for designating the product that the customer wishes to register as a purchased product in response to a request from the customer. This operation is, for example, an operation for causing the barcode scanner 301 to scan a barcode representing the product code of the corresponding product. This operation may also be an operation for inputting the product code on the touch panel.

[0127] As ACT308, the processor 302 checks whether the product code has been acquired. If the processor 302 has not acquired the product code, it determines NO and proceeds to ACT309. As ACT309, the processor 302 checks whether the cancellation of the association has been instructed. If the processor 302 cannot confirm the corresponding instruction, it determines NO and returns to ACT308. Thus, as ACT308 and ACT309, the processor 302 waits for the product code to be acquired or for the cancellation to be instructed.

[0128] If an operation for designating a product is performed as described above, the processor 302 acquires the product code in response to that operation. Therefore, the processor 302 determines YES in ACT308 and proceeds to ACT310. As 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 transmitted here.

[0129] After the processor 31 in the mobile controller 3 issues an instruction to display the registration status screen in ACT404 in FIG. 22, the processor 31 proceeds to ACT405. In ACT405, the processor 31 checks whether or not a product registration has been requested. If the processor 31 cannot confirm the request, it determines that the result is NO, and proceeds to ACT406. In ACT 406, the processor 201 checks whether or not a request to release the link has been made. If the processor 31 cannot confirm the request, it determines that the result is NO, and returns to ACT 405. Thus, the processor 31 waits for a request for registration or cancellation in ACT 405 and ACT 406. Then, if registration is requested from the store clerk terminal 300 as described above, the processor 31 judges YES in ACT 405 and proceeds to ACT 407.

[0130] As the ACT407, the processor 31 transfers the product registration request to the virtual POS server 2 as request data. At this time, the processor 31 adds the transaction code of the transaction that is the target of the transaction processing being executed with respect to the user terminal 200 associated with the store clerk terminal 300 to the request data. For example, the processor 31 searches for the data record DRB in which the terminal code of the requesting store clerk terminal 300 is set in the field FBA from the association database DBCB stored in the auxiliary storage unit 33, and obtains the terminal code of the user terminal 200 set in the field FBB of the corresponding data record DRB. Subsequently, the processor 31 searches for the data record DRA in which the obtained terminal code of the user terminal 200 is set in the field FAA from the transaction management database DBCA stored in the auxiliary storage unit 33, and obtains the transaction code set in the field FAC of the corresponding data record DRA. Then, the processor 31 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. Then, the processor 21 transmits the result data representing the result of such processing to the mobile controller 3 in the same manner as ACT212.

[0132] Thus, through the transfer of the registration request from the store clerk terminal 300 by the processor 31 of the mobile controller 3 and the registration process of the purchased goods by the processor 21 of the virtual POS server 2 based on this registration request, the goods specified by the store clerk terminal 300 (the second terminal) are stored in the transaction database DBBA in the auxiliary storage unit 23 of the virtual POS server as the goods purchased by the customer who is the user of the user terminal 200. Thus, when the processor 21 executes the virtual POS application APBA and the processor 31 executes the registration support application APC A, a function as a second registration unit is realized by the computer (virtual POS server 2) with the processor 21 as the central part and the computer (mobile controller 3) with the processor 31 as the central part.

[0133] After requesting registration in ACT407, the processor 31 of the mobile controller 3 proceeds to ACT408. As ACT408, 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] As ACT409, the processor 31 updates the registration database DBCC in the same manner as described above based on the above result data. As ACT410, the processor 31 instructs the user terminal 200 associated with the store clerk terminal 300 to display a list screen. For the instruction data for this display instruction, the processor 31 includes the product code, product name, price, and quantity included in the data record DRB associated with the transaction to be processed in the registration database DBCC.

[0135] The processor 31 will then return to ACT404 and repeat the subsequent processing in the same manner as described above. That is, at this time, the processor 31 will instruct the clerk terminal 300 to display a registration status screen representing the product code, product name, price, and quantity included in the updated data record DRB associated with the transaction being processed in the registration database DBCC.

[0136] If the processor 201 in the user terminal 200 is instructed to display the list screen by the mobile controller 3 as described above, it determines YES at ACT118 in FIG. 11, returns to ACT112, and repeats the subsequent processing in the same manner as described above. That is, at this time, the processor 201 will instruct the user terminal 200 to display a list screen representing the product code, product name, price, and quantity included in the updated data record DRB associated with the transaction being processed in the registration database DBCC. Therefore, the list screen SCA displayed thereby reflects the registration result according to the operation on the clerk terminal 300.

[0137] After the processor 302 in the clerk terminal 300 requests product registration at ACT310 in FIG. 21, it proceeds to ACT311. As ACT311, the processor 302 waits for an instruction to display the registration status screen. Then, if the processor 302 determines YES when the display of the registration status screen is instructed by the mobile controller 3 as described above, it returns to ACT307 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, by the operation of the clerk on the clerk terminal 300, the purchased products related to the transaction targeted in the transaction process regarding the user terminal 200 with which the clerk terminal 300 is linked are registered.

[0138] When the clerk has finished registering all the products requested by the customer as purchased products, the clerk instructs the release of the link by a predetermined operation such as touching a button shown on the registration status screen. If the processor 302 is instructed to cancel the cooperation as described above, it determines YES at ACT309 and proceeds to ACT312. As ACT312, the processor 302 requests the mobile controller 3 to cancel the cooperation.

[0139] As ACT313, the processor 302 waits for a cancellation notice. When the processor 31 in the mobile controller 3 is requested to cancel the cooperation, it determines YES at ACT406 in FIG. 22 and proceeds to ACT411. As ACT411, the processor 31 updates the cooperation database DBCB to cancel the cooperation with the user terminal 200 regarding the requesting store terminal 300. For example, the processor 31 deletes the data record DRB in which the terminal code of the requesting store terminal 300 is set in the field FBA from the cooperation database DBCB.

[0140] As ACT412, the processor 31 notifies the store terminal 300 of the cancellation of the cooperation. Then, the processor 31 ends the cooperation process. When the processor 302 in the store terminal 300 is notified of the cancellation of the cooperation from the mobile controller 3 as described above, it determines YES at ACT313 in FIG. 21 and ends the information processing shown in FIG. 21.

[0141] When the customer touches the area representing the number on the list screen SCA, the processor 201 generates image data for displaying a list box for specifying the number overlaid on the list screen SCA so that the list box for specifying the number is displayed overlaid on the list screen SCA. When this list box is operated, the processor 201 receives this as the specification of the number. In this case, the processor 201 determines YES at ACT115 in FIG. 11 and proceeds to ACT126 in FIG. 12. As ACT126, 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 ACT127.

[0142] As ACT127, the processor 201 requests a quantity change from the mobile controller 3. The request data transmitted here by the processor 201 includes specific data for identifying the specified quantity of products and the specified quantity. The specific data may be a product code or data that can identify the purchased products only in the mobile controller 3, such as a number for identifying each purchased product in the 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 the list screen.

[0143] In the mobile controller 3, if the processor 31 is requested for a quantity change from the user terminal 200 as described above, it determines YES in ACT206 in FIG. 14 and proceeds to ACT214 in FIG. 15. As ACT214, the processor 31 transfers the quantity change request to the virtual POS server 2 along with the 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 it to the virtual POS server 2, or add the transaction code to the request data after conversion by some process 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. If the specific data included in the request data is not a product code, the processor 31 replaces the specific data with a product code.

[0144] In the virtual POS server 2, the processor 21 assumes that the quantity included in the request data sent from the mobile controller 3 is input by the input device provided in the existing POS terminal, and changes the quantity of the purchased products by the same process as the existing POS terminal. The processor 21 transmits the result data representing the product code of the product with the changed quantity and the changed quantity to the mobile controller 3.

[0145] After the processor 31 in the mobile controller 3 transfers the quantity change request at ACT214, it proceeds to ACT215. As ACT215, 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] As ACT216, the processor 31 updates the registration database DBCC based on the above result data. That is, the processor 31 finds the registration data including the notified product code from the associated data record DRC. Then, the processor 31 rewrites the quantity included in the corresponding registration data with the quantity included in the result data.

[0147] Note that the processor 31 stores the specific data and quantity sent in the quantity change request data in the main memory 32 or the auxiliary storage unit 33, and in response to receiving the result data indicating that the update is complete, may rewrite the quantity of the registration data regarding the product specified by this stored specific data with the stored quantity. And in this case, in the virtual POS server 2, the processor 21 may not include the product code and quantity in the result data.

[0148] As ACT217, the processor 31 instructs the user terminal 200 to display the list screen. The processor 31 includes the product code, product name, price, and quantity included in the registration data in the data record DRC updated as described above and having a cancellation flag of "0" in the instruction data. After that, the processor 31 returns to the standby state of ACT205 to ACT209 in FIG. 14.

[0149] Now, if the specified quantity is 0 in the user terminal 200, the processor 201 determines YES at ACT126 in FIG. 12 and proceeds to ACT128. As ACT128, 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 for notifying the customer that the product specified to have a quantity of zero is deleted from the purchased products. The deletion screen includes a deletion button for specifying deletion and a return button for specifying to return to the state before specifying the change of the quantity without changing the quantity.

[0150] As ACT129, the processor 201 checks whether deletion is specified. If the processor 201 cannot confirm the corresponding specification, it determines NO and proceeds to ACT130. As ACT130, the processor 201 checks whether return is specified. If the processor 201 cannot confirm the corresponding specification, it determines NO and returns to ACT129. Thus, as ACT129 and ACT130, 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 of the quantity, the customer specifies return by a predetermined operation such as touching the return button on the deletion screen. In response to this, the processor 201 determines YES in ACT130, returns to ACT112 in FIG. 11, and causes the list screen SCA to be displayed on the touch panel 204 again. In this case, since the registration state of the purchased product is not changed, the processor 201 causes the list screen SCA in the same state as that displayed before displaying the deletion screen to be displayed on the touch panel 204 again.

[0152] If the customer is sure about the deletion, the customer specifies deletion by a predetermined operation such as touching the deletion button on the deletion screen. In response to this, the processor 201 determines YES in ACT129 and proceeds to ACT131. As ACT131, the processor 201 requests deletion from the mobile controller 3. The request data transmitted by the processor 201 here includes specific data for specifying the product for which deletion is specified.

[0153] In the mobile controller 3, if the processor 31 is requested to delete from the user terminal 200 as described above, it determines YES at ACT207 in FIG. 14 and proceeds to ACT218 in FIG. 15. As ACT218, the processor 31 transfers the deletion request to the virtual POS server 2 along with the 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 it to the virtual POS server 2, or add the transaction code to the request data after conversion 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 a 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 the input device provided in the existing POS terminal, and excludes the target product from the purchased products registered in the transaction database DBBA stored in the auxiliary storage unit 23 by the same process as the existing POS terminal. The processor 21 transmits the result data representing the product code of the product excluded from the purchased products to the mobile controller 3.

[0155] In the mobile controller 3, after transferring the deletion request at ACT218, the processor 31 proceeds to ACT219. As ACT219, 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] As ACT220, the processor 31 updates the registration database DBCC based on the above 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. Then the processor 31 changes the cancellation flag included in the corresponding registration data to "1".

[0157] Note that the processor 31 stores the specific data sent in the deletion request data in the main memory 32 or the auxiliary storage unit 33, and may change the cancellation flag of the registration data regarding the product specified by this stored specific data in response to receiving the result data indicating that the deletion has been completed. And in this case, in the virtual POS server 2, the processor 21 does not have to include the product code in the result data.

[0158] As ACT221, the processor 31 instructs the user terminal 200 to display the list screen SCA. The processor 31 includes the product code, product name, price, and quantity included in the registration data with the cancellation flag being "0" among the registration data included in the data record DRC updated as above in the display instruction data. After that, the processor 31 returns to the waiting state of ACT205 to ACT209 in FIG. 14.

[0159] Now, after the processor 201 at the user terminal 200 requests a quantity change in ACT127 in FIG. 12 or requests a deletion in ACT131, it proceeds to ACT132. As ACT132, the processor 201 waits for an instruction to display the list screen SCA. Then, in response to a quantity change request or a deletion request, if the display of the list screen SCA is instructed from the mobile controller 3 as described above, the processor 201 determines YES, returns to ACT112 in FIG. 11, and generates image data of 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 as a screen representing 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 of the list screen SCA in a state representing a purchased product different from that displayed when a quantity change or deletion is specified so that the list screen SCA is displayed on the touch panel 204.

[0160] When the customer wants to cancel all the already registered purchased products and cancel the shopping, the customer specifies 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 at ACT116 in FIG. 11 and proceeds to ACT133 in FIG. 12. As ACT133, the processor 201 generates image data of the 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 the already registered purchased products will be cancelled. The cancellation screen includes an execution button for specifying cancellation execution and a return button for specifying a return to the state before specifying a change in quantity without changing the quantity.

[0161] As ACT134, the processor 201 checks whether cancellation execution has been specified. If the corresponding specification cannot be confirmed, the processor 201 determines NO and proceeds to ACT135. As ACT135, the processor 201 checks whether a return has been specified. If the corresponding specification cannot be confirmed, the processor 201 determines NO and returns to ACT134. Thus, as ACT134 and ACT135, the processor 201 waits for a cancellation execution or a return to be specified.

[0162] If the customer continues shopping as it is, the customer specifies a return by a predetermined operation such as touching the return button on the cancellation screen. In response, the processor 201 determines YES in ACT135, returns to ACT112 in FIG. 11, and causes the list screen SCA to be displayed again on the touch panel 204. In this case, since the registration state of the purchased product is not changed, the processor 201 causes the list screen SCA in the same state as that displayed before displaying the cancellation screen to be displayed again on the touch panel 204.

[0163] If the customer cancels the shopping, the customer specifies the execution of the transaction cancellation by a predetermined operation such as touching the execution button on the cancellation screen. In response, the processor 201 determines YES in ACT134 and proceeds to ACT136. As ACT136, the processor 201 requests the mobile controller 3 to cancel the transaction.

[0164] If the processor 31 in the mobile controller 3 is requested to cancel the transaction from the user terminal 200 as described above, the processor 31 determines YES in ACT208 in FIG. 14 and proceeds to ACT222 in FIG. 15. As ACT222, the processor 31 notifies the virtual POS server of the transaction code and transfers the 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 after conversion by some process and transmit it to the virtual POS server 2.

[0165] In the virtual POS server 2, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a cancellation instruction input by the input device provided in the existing POS terminal, and by the same process as that of the existing POS terminal, deletes all of the purchased goods registered in association with the notified transaction code in the transaction database DBBA stored in the auxiliary storage unit 23. The processor 21 transmits the result data indicating that the cancellation has been completed to the mobile controller 3.

[0166] In the mobile controller 3, after the processor 31 transfers the transaction cancellation request in ACT222, it proceeds to ACT223. As ACT223, 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] As ACT224, the processor 31 updates the registration database DBCC based on the above result data. That is, the processor 31 changes the cancellation flag, which is "0", to "1" for all of the registration data included in the data record DRC associated with the transaction being processed. As ACT225, the processor 31 notifies the user terminal 200 of the cancellation. Then, the processor 31 returns to the waiting state of ACT205 to ACT209 in FIG. 14.

[0168] Now, in the user terminal 200, after the processor 201 requests cancellation in ACT136 in FIG. 12, it proceeds to ACT137. In ACT137, the processor 201 waits to be notified of the cancellation from the mobile controller 3. Then, if the cancellation is notified as described above, the processor 201 determines that it is YES and returns to ACT101 in FIG. 10.

[0169] If the customer has finished registering all the products they wish to purchase as purchased products, they proceed to payment. At this time, the customer designates the start of accounting by performing a predetermined operation such as touching button BUAC on the list screen SCA. In response, the processor 201 determines YES at ACT117 in FIG. 11 and proceeds to ACT138 in FIG. 13. As ACT138, the processor 201 requests accounting from the mobile controller 3.

[0170] If the processor 31 in the mobile controller 3 has received an accounting request from the user terminal 200 as described above, it determines YES at ACT209 in FIG. 14 and proceeds to ACT226 in FIG. 16. As ACT226, the processor 31 instructs the user terminal 200 to display the accounting screen.

[0171] Now, after the processor 201 in the user terminal 200 has requested accounting at ACT138 in FIG. 13, it proceeds to ACT139. As ACT139, the processor 201 waits for the display of the accounting screen to be instructed. Then, if the processor 201 has confirmed that the display of the accounting screen has been instructed as described above, it determines YES at ACT139 and proceeds to ACT140.

[0172] As ACT140, 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 for the customer to select whether to perform the operation for payment settlement on either the user terminal 200 or the accounting machine 5. If the customer wishes to perform the operation for payment settlement on the user terminal 200, they specify the user terminal 200 by a predetermined operation. Also, if the customer wishes to perform the operation for payment settlement on the accounting machine 5, they specify the accounting machine 5 by a predetermined operation.

[0173] As ACT141, the processor 201 checks whether the user terminal 200 has been specified. If the processor 201 cannot confirm the specification, it determines NO and proceeds to ACT142. As ACT142, the processor 201 checks whether the accounting machine 5 has been specified. If the processor 201 cannot confirm the specification, it determines NO and returns to ACT141. Thus, as ACT141 and ACT142, the processor 201 waits for the user terminal 200 or the accounting machine 5 to be specified. If the user terminal 200 is specified as described above, the processor 201 determines YES at ACT141 and proceeds to ACT143.

[0174] As ACT143, the processor 201 requests a settlement from the mobile controller 3. Note that the processor 201 includes settlement data such as a credit number or a user code for an online settlement service, which is necessary for the settlement, in the request data for requesting the settlement.

[0175] Also, if the accounting machine 5 is specified as described above, the processor 201 determines YES at ACT142 and proceeds to ACT144. As ACT144, the processor 201 generates image data of an accounting barcode screen to be displayed on the touch panel 204 so that the accounting barcode screen is displayed on the touch panel 204. The accounting barcode screen is a screen representing an accounting barcode representing data necessary for the accounting machine 5 to acquire data (hereinafter referred to as accounting data) regarding the details of a transaction from the virtual POS server 2. Although the illustration of detailed processing is omitted, the processor 201 acquires an accounting barcode from the virtual POS server 2 via the mobile controller 3 and represents the accounting barcode on the accounting barcode screen.

[0176] The customer causes the scanner provided in the accounting machine 5 not being used by other customers to read the accounting barcode. In response, the accounting machine 5 acquires accounting data from the virtual POS server 2 according to the data represented by the accounting barcode, and executes a process for settling the settlement amount determined based on this accounting data. Then, if the settlement is completed, the accounting machine 5 notifies the virtual POS server 2 to that effect. In the virtual POS server 2, when the processor 21 is notified of the completion of the settlement from the accounting machine 5, it notifies the mobile controller 3 of the completion of the settlement. Note that the completion of the settlement in the accounting machine 5 may be directly notified from the accounting machine 5 to the mobile controller 3.

[0177] In the mobile controller 3, after the processor 31 instructs to display the accounting screen in ACT226 in FIG. 16, it proceeds to ACT227. As ACT227, the processor 31 checks whether or not a settlement is requested from the user terminal 200. If the request cannot be confirmed, the processor 31 determines NO and proceeds to ACT228. As ACT228, the processor 31 checks whether or not a completion of the settlement is notified. If the notification cannot be confirmed, the processor 31 determines NO and returns to ACT227. Thus, as ACT227 and ACT228, the processor 31 waits for a settlement request or a settlement completion notification. If a settlement is requested from the user terminal 200 as described above, the processor 31 determines YES in ACT227 and proceeds to ACT229.

[0178] As ACT229, the processor 31 transfers a settlement request to the virtual POS server 2 along with a notification of the transaction code of the transaction to be processed. At this time, the processor 31 may transfer the request data sent from the user terminal 200 as it is to the virtual POS server 2, or may send the request data after being converted by some process to the virtual POS server 2.

[0179] 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 settlement instruction input by the input device provided in the existing POS terminal, and calculates the price for the transaction identified by the notified transaction code by the same process as the existing POS terminal, and performs a process for settling this based on the settlement data. The process for settlement includes, for example, a settlement request to a settlement server (not shown). Then, the processor 21 transmits the result data indicating that the settlement has been completed to the mobile controller 3.

[0180] In the mobile controller 3, after the processor 31 transfers the settlement request in ACT229, it proceeds to ACT230. As ACT230, the processor 31 waits for the virtual POS server 2 to notify the completion of settlement. Then, if the processor 31 determines YES when the result data indicating that the settlement has been completed, which was transmitted by the virtual POS server 2 as described above, is received by the communication interface 34, it proceeds to ACT231. Also, if the processor 31 is notified of the completion of settlement at the accounting machine 5 as described above, it determines YES in ACT228 and proceeds to ACT231. As ACT231, the processor 31 notifies the user terminal 200 of the completion of settlement.

[0181] In the user terminal 200, after the processor 201 requests settlement to the mobile controller 3 in ACT143 in FIG. 13, or after displaying the accounting barcode screen in ACT144, it proceeds to ACT145. As ACT145, the processor 201 waits for the completion of settlement to be notified. Then, if the processor 201 determines YES when the completion of settlement is notified from the mobile controller 3 as described above, it proceeds to ACT146.

[0182] As ACT146, the processor 201 generates the image data of the 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. If the customer has confirmed the completion screen, the customer declares the confirmation by performing a predetermined operation such as touching a button shown on the completion screen. In response to this, the processor 201 proceeds to ACT147. Note that the processor 201 may also proceed to ACT147 when the elapsed time in the state where the completion screen is displayed reaches a predetermined time.

[0183] As ACT147, the processor 201 generates the image data of the 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 two-dimensional code TCO for checkout. For example, the processor 201 activates the camera 205 and superimposes a character message prompting the customer to read the two-dimensional code TCO on the image obtained by the camera 205 and a line indicating a guide to the position where the two-dimensional code TCO should be held to generate the scan screen.

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

[0185] As ACT148, 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. The reading of this two-dimensional code may be performed as a process based on the smartphone POS app APDA or as a process based on another application program for reading the two-dimensional code. Then, if the two-dimensional code is read, the processor 201 determines YES and proceeds to ACT149.

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

[0187] If the processor 201 can confirm that the data represented by the read two-dimensional code is checkout data, it determines YES in ACT149 and proceeds to ACT150. As ACT150, the processor 201 requests a checkout from the mobile controller 3.

[0188] In the mobile controller 3, after the processor 31 notifies the completion of the settlement in ACT231 in FIG. 16, it proceeds to ACT232. As ACT232, the processor 31 waits for a checkout to be requested. If the processor 31 determines YES when a checkout is requested from the user terminal 200 as described above, it proceeds to ACT233.

[0189] As ACT233, the processor 31 executes the checkout process. The checkout process is a process such as clearing the data stored in the main memory 32 and the auxiliary storage unit 33 for the management of the transaction that has been the processing target. Note that the virtual POS server 2 may end the processing related to the corresponding transaction in response to the completion of the settlement, or may end the processing related to the transaction in response to an instruction from the mobile controller 3. And in the latter case, the processor 31 gives the above instruction to the virtual POS server 2 in the checkout process. Also, a history database representing the history of user operations including incorrect barcode scanning etc. may be managed by the store server 1, the virtual POS server 2 or the mobile controller 3, or another server (not shown) etc. In this case, the processor 31 performs a process for updating the history database so as to reflect the history of operations related to the current transaction in the checkout process. As ACT234, the processor 31 notifies the user terminal 200 of the completion of the checkout. And the processor 31 ends the information processing shown in FIGS. 14 to 16.

[0190] In the user terminal 200, after the processor 201 requests a checkout in ACT150 in FIG. 13, it proceeds to ACT151. As ACT151, the processor 201 waits for a notification of the completion of the checkout. And if the processor 201 is notified of the completion of the checkout from the mobile controller 3 as described above, it determines YES and proceeds to ACT152.

[0191] As ACT152, the processor 201 clears various data temporarily used for the current shopping, such as the check-in data stored in ACT107 in FIG. 10 etc. And then the processor 201 returns to ACT101 in FIG. 10.

[0192] According to the present embodiment as described above, in the process of registering purchased products by the customer using the user terminal 200, the store clerk terminal 300 can be temporarily linked, and without stopping the product registration process performed using the user terminal 200, the registration process of the purchased products in response to the request from the store clerk terminal 300 operated by the store clerk can continue the previous registration process using the user terminal 200.

[0193] Even if the store clerk operates the user terminal 200, it is possible for the store clerk to substitute the operations related to the registration of purchased products. However, since the user terminal 200 belongs to the customer, considering issues such as customer privacy protection, data deletion in the user terminal 200 due to incorrect operations, and device damage, it is not preferable for the store clerk to operate the user terminal 200. In contrast, in the present embodiment, the store clerk does not operate the user terminal 200, and the information passed from the user terminal 200 to the store clerk terminal 300 is only the terminal code of the user terminal 200. Therefore, there is no need for the store clerk 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. Also, in a situation where it is difficult to register products from the user terminal 200 due to the performance of the camera 205 of the user terminal 200, etc., even if the store clerk operates the user terminal 200, it remains difficult to register products. In the present embodiment, since product registration can be performed using the store clerk terminal 300 having a barcode scanner 301 suitably configured to optically read barcodes representing product codes, the above-mentioned difficulties in performing product registration using the user terminal 200 are eliminated. Also, according to the linking function of the present embodiment, information generated inside the store system 100 such as transaction codes is not sent to the user terminal 200 or the store clerk terminal 300, so the security of the store system 100 for the customer is also protected.

[0194] According to this embodiment, in the transaction management database DBCA in the auxiliary storage unit 33 of the mobile controller 3, the "terminal code of the user terminal" and the "transaction code" are stored in association with each other, and in the transaction database DBBA in the auxiliary storage unit 23 of the virtual POS server 2, the "transaction code" and the "product code for which purchase is planned" are stored in association with each other. The registration request for the purchased product from the user terminal 200 is processed using the transaction management database DBCA and the transaction database DBBA. And when a customer needs temporary support from a store clerk while shopping around in the store, in response to a request from the store clerk terminal 300 operated by the store clerk to whom the customer has requested support, in the cooperation database DBCB in the auxiliary storage unit 33 of the mobile controller 3, the "terminal code of the user terminal" and the "terminal code of the store clerk terminal" are stored in association with each other. The mobile controller 3 can obtain the "user terminal code" of the customer who is shopping from the "store clerk terminal code" of the store clerk terminal 300 only by referring to the cooperation database DBCB. Therefore, with only a slight change in the internal configuration of the transaction processing device, that is, by adding the cooperation database DBCB, the mobile controller 3 and the virtual POS server 2 can continue the product registration process for the request from the user terminal 200 without aborting the product registration process, and can process the product registration request from the store clerk terminal 200. Also, since the release of the cooperation of the store clerk terminal 300 does not affect the contents of the transaction management database DBBA or the transaction database DBBA, the product registration process using the previous user terminal 200 can be continued. That is, the customer can receive temporary support from a store clerk at any time while shopping around in the store. For example, if it is assumed that the support for product registration is provided by a store clerk stationed at the accounting corner, the customer has to carry around products for which registration has not been completed as purchased products. Also, when putting products for which registration has not been completed into the shopping basket, it becomes troublesome to distinguish them from the registered products. According to this embodiment, these troubles do not occur.

[0195] This embodiment can be variously modified as follows. The store employee terminal 300 may be equipped with a camera, and process the image obtained by photographing the barcode with the camera to obtain barcode data. If the image processing for obtaining barcode data is suitably defined for reading the product code, the reading accuracy of the product code can be improved compared to general-purpose image processing for reading various barcodes different from those representing the product code. Note that the operation for specifying a product on the store employee terminal 300, even if it is somewhat cumbersome, can often be quickly performed by a store employee. Therefore, it is not essential for the store employee terminal 300 to have a function that can perform product specification more simply than the user terminal 200.

[0196] The cooperation of the store employee terminal 300 with the user terminal 200 may be such that a barcode representing the terminal code of the store employee terminal 300 is displayed on the touch panel 305 etc. of the store employee terminal 300, and the user terminal 200 reads this barcode to obtain the terminal code of the store employee terminal 300. In this case, a cooperation request and the terminal code of the store employee terminal 300 are sent from the user terminal 200 to the mobile controller 3. The mobile controller 3, in response to the cooperation request sent from the user terminal 200, associates and stores the "terminal code of the user terminal" and the "terminal code of the store employee terminal" in the cooperation database DBCB in the auxiliary storage unit 33. Since there is no transmission of information from the user terminal 200 to the store employee terminal 300, it becomes more certain to protect customer information from the store employee operating the store employee terminal 300. Also, the method for obtaining the terminal code of the terminal to be cooperated with on the user terminal 200 or the store employee terminal 300 may be a method that does not use a barcode, such as wireless communication. Alternatively, a cooperation code different from the terminal code may be obtained from one terminal by the other terminal, and each terminal may notify the mobile controller 3 of its own terminal code together with the cooperation code. That is, as long as the set of terminal codes of the user terminal 200 and the store employee terminal 300 to be cooperated can be notified to the mobile controller 3 by some method, that method may be arbitrary.

[0197] As part of the registration operation, an operation for discount or reduction of the purchased goods may be performed on the user terminal 200. The operation is, for example, an operation for causing the user terminal 200 to read a barcode printed on a discount coupon. And in this case, at the store clerk terminal 300, the processor 302 may accept an operation for discount or reduction of the purchased goods during cooperation with the user terminal 200, and make a request corresponding to the operation to the mobile controller 3.

[0198] As part of the registration operation, an operation for discount or reduction of the transaction may be performed on the user terminal 200. The 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 service for the transaction. As an example of the operation, it 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 proves that the customer is a person entitled to receive a discount or reduction service. And in this case, at the store clerk terminal 300, the processor 302 may accept an operation for discount or reduction of the transaction during cooperation with the user terminal 200, and make a request corresponding to the operation to the mobile controller 3.

[0199] At the store clerk terminal 300, the processor 302 may accept an operation related to at least one of quantity change, deletion of purchased goods, or cancellation of purchased goods during cooperation with the user terminal 200, and make a request corresponding to the operation to the mobile controller 3.

[0200] In the above-described embodiment, the functions as the first registration unit and the second registration unit are realized by the computer having the processor 21 as the central part and the computer having the processor 31 as the central part. That is, the above-described embodiment is an example of realizing a transaction processing apparatus by combining the virtual POS server 2 and the mobile controller 3. However, the virtual POS server 2 may directly receive requests from the user terminal 200 and the store clerk terminal 300, and the mobile controller 3 may not be provided. In this case, the functions as the first registration unit and the second registration unit will be realized by the computer having the processor 21 as the central part. And the virtual POS server 2 will correspond to the transaction processing apparatus.

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

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

[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 the electronic device. In the latter case, the program may be provided via a network, or may be provided 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 any medium capable of storing a program such as a CD-ROM or a memory card and readable by a computer, regardless of its form. Although some embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalent scope thereof. The invention described in the claims of the present application at the time of filing is appended below. [Appendix 1] A first registration unit that performs a process of storing the content of a transaction related to the user in response to a request from a first terminal by the operation of the user; A cooperation unit that stores the association between the first terminal and the second terminal, and cooperates the process of storing the content of the transaction related to the user performed by the first registration unit with the second terminal; When the content of the transaction related to the user is sent from the second terminal, a second registration unit that uses the association between the second terminal and the first terminal to store the content of the transaction sent from the second terminal in the first registration unit as the content of the transaction related to the user; A transaction processing apparatus comprising the above. [Appendix 2] The cooperation unit determines whether the second terminal is a terminal defined for store employees, and when the second terminal is a terminal defined for store employees, cooperates the process of storing the content of the transaction related to the user of the first terminal with the second terminal. The transaction processing apparatus of [Appendix 1]. [Appendix 3] When the identifier of the first terminal is acquired via the second terminal, the cooperation unit stores the association between the identifier of the first terminal and the identifier of the second terminal, and thereby cooperates the process of storing the content of the transaction related to the user performed by the first registration unit with the second terminal. The transaction processing apparatus of [Appendix 1] or [Appendix 2]. [Appendix 4] When the identifier of the second terminal is acquired via the first terminal, the cooperation unit stores the association between the identifier of the first terminal and the identifier of the second terminal, and thereby cooperates the process of storing the content of the transaction related to the user performed by the first registration unit with the second terminal. The transaction processing apparatus of [Appendix 1] or [Appendix 2]. [Appendix 5] After the cooperation between the second terminal and the process of storing the content of the transaction related to the user of the first terminal by the cooperation unit is released, the first registration unit performs a process of storing the content of the transaction related to the user in response to a request from the first terminal. The transaction processing apparatus according to any one of [Appendix 1] to [Appendix 4]. [Appendix 6] The first registration unit is any one of the transaction processing devices of [Appendix 1] to [Appendix 5], which generates a transaction identifier for identifying the transaction by the user and stores the content of the transaction in a first storage unit in association with the transaction identifier. [Appendix 7] The transaction processing device according to [Appendix 6], further comprising a second storage unit that stores the transaction identifier and the identifier of the first terminal in association with each other. [Appendix 8] The cooperation unit comprises a third storage unit that stores the association between the first terminal and the second terminal by associating and storing the identifier of the first terminal and the identifier of the second terminal, and when the content of a transaction related to the user is sent from the second terminal, obtains the identifier of the first terminal by referring to the third storage unit with the identifier of the second terminal and passes it to the second registration unit. The transaction processing device according to [Appendix 7]. [Appendix 9] stores the content of a transaction related to the user in response to a request from a first terminal by a user's operation, stores the association between the first terminal and the second terminal, thereby causing the second terminal to cooperate in the process of storing the content of the transaction related to the user, and when the content of a transaction related to the user is sent from the second terminal, uses the association between the first terminal and the second terminal to store the content of the transaction sent from the second terminal as the content of the transaction related to the user. Transaction processing method. [Appendix 10] A program recording medium having recorded thereon a program for causing a computer to store the content of a transaction related to the user in response to a request from a first terminal by a user's operation, store the association between the first terminal and the second terminal, thereby causing the second terminal to cooperate in the process of storing the content of the transaction related to the user, and when the content of a transaction related to the user is sent from the second terminal, use the association between the first terminal and the second terminal to store the content of the transaction sent from the second terminal as the content of the transaction related to the user. ​

Claims

1. A first registration unit that performs a process of storing the details of a transaction related to the user in response to a request from a first terminal by the user's operation; A cooperation unit that stores the association between the first terminal and a second terminal, and thereby cooperates with the second terminal in the process of storing the details of the transaction related to the user performed by the first registration unit; When the details of the transaction related to the user are sent from the second terminal, a second registration unit that uses the association between the second terminal and the first terminal to store the details of the transaction sent from the second terminal in the first registration unit as the details of the transaction related to the user; comprising: The cooperation unit determines whether the second terminal is a terminal designated for a store clerk, and when the second terminal is a terminal designated for a store clerk, cooperates with the second terminal in the process of storing the details of the transaction related to the user of the first terminal; When the identifier of the first terminal is acquired via the second terminal, the cooperation unit stores the association between the identifier of the first terminal and the identifier of the second terminal, and thereby cooperates with the second terminal in the process of storing the details of the transaction related to the user performed by the first registration unit; A transaction processing device.

2. A first registration unit that performs a process of storing the details of a transaction related to the user in response to a request from a first terminal by the user's operation; A cooperation unit that stores the association between the first terminal and a second terminal, and thereby cooperates with the second terminal in the process of storing the details of the transaction related to the user performed by the first registration unit; When the details of the transaction related to the user are sent from the second terminal, a second registration unit that uses the association between the second terminal and the first terminal to store the details of the transaction sent from the second terminal in the first registration unit as the details of the transaction related to the user; comprising: The cooperation unit determines whether the second terminal is a terminal designated for store staff, and when the second terminal is a terminal designated for store staff, causes the second terminal to cooperate with the process of storing the details of the transaction regarding the user of the first terminal. When the identifier of the second terminal is acquired via the first terminal, the cooperation unit stores the association between the identifier of the first terminal and the identifier of the second terminal, thereby causing the second terminal to cooperate with the process of storing the details of the transaction regarding the user performed by the first registration unit. Transaction processing device.

3. After the cooperation between the second terminal and the first registration unit for storing the details of the transaction regarding the user of the first terminal by the cooperation unit is cancelled, the first registration unit performs the process of storing the details of the transaction regarding the user in response to a request from the first terminal. The transaction processing device according to claim 1 or 2.

4. The first registration unit generates a transaction identifier for identifying the transaction by the user, and stores the details of the transaction in the first storage unit in association with the transaction identifier. The transaction processing device according to claim 1 or 2.

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

6. The cooperation unit includes a third storage unit that stores the association between the first terminal and the second terminal by storing the association between the identifier of the first terminal and the identifier of the second terminal, and when the details of the transaction regarding the user are sent from the second terminal, acquires the identifier of the first terminal by referring to the third storage unit with the identifier of the second terminal and passes it to the second registration unit. The transaction processing device according to claim 5.

7. A transaction processing method executed by a transaction processing device, ​In response to a request from a first terminal due to a user's operation, store the details of a transaction related to the user, By storing the association between the first terminal and the second terminal, cause the second terminal to cooperate in the process of storing the details of the transaction related to the user, When the details of a transaction related to the user are sent from the second terminal, use the association between the first terminal and the second terminal to store the details of the transaction sent from the second terminal as the details of the transaction related to the user, The causing to cooperate includes determining whether the second terminal is a terminal designated for store clerks, and when the second terminal is a terminal designated for store clerks, causing the second terminal to cooperate in the process of storing the details of the transaction related to the user of the first terminal, The causing to cooperate includes, when the identifier of the first terminal is acquired via the second terminal, storing the association between the identifier of the first terminal and the identifier of the second terminal, thereby causing the second terminal to cooperate in the process of storing the details of the transaction related to the user, Transaction processing method. A transaction processing method executed by a transaction processing apparatus according to claim 8, In response to a request from a first terminal due to a user's operation, store the details of a transaction related to the user, By storing the association between the first terminal and the second terminal, cause the second terminal to cooperate in the process of storing the details of the transaction related to the user, When the details of a transaction related to the user are sent from the second terminal, use the association between the first terminal and the second terminal to store the details of the transaction sent from the second terminal as the details of the transaction related to the user, The causing to cooperate includes determining whether the second terminal is a terminal designated for store clerks, and when the second terminal is a terminal designated for store clerks, causing the second terminal to cooperate in the process of storing the details of the transaction related to the user of the first terminal, The above-mentioned linking is, when the identifier of the second terminal is acquired via the first terminal, to link the process of storing the details of the transaction regarding the user to the second terminal by storing the association between the identifier of the first terminal and the identifier of the second terminal. Transaction processing method.

9. To a computer, In response to a request from a first terminal by a user's operation, storing the details of the transaction regarding the user; By storing the association between the first terminal and the second terminal, linking the process of storing the details of the transaction regarding the user to the second terminal; When the details of the transaction regarding the user are sent from the second terminal, using the association between the first terminal and the second terminal to store the details of the transaction sent from the second terminal as the details of the transaction regarding the user; A program recording medium recording a program for causing the above to be executed, The above-mentioned linking is to determine whether the second terminal is a terminal defined for store clerks, and when the second terminal is a terminal defined for store clerks, to link the process of storing the details of the transaction regarding the user of the first terminal to the second terminal; The above-mentioned linking is, when the identifier of the first terminal is acquired via the second terminal, to link the process of storing the details of the transaction regarding the user to the second terminal by storing the association between the identifier of the first terminal and the identifier of the second terminal. Program recording medium.

10. To a computer, In response to a request from a first terminal by a user's operation, storing the details of the transaction regarding the user; By storing the association between the first terminal and the second terminal, linking the process of storing the details of the transaction regarding the user to the second terminal; When the content of a transaction related to the user is sent from the second terminal, using the association between the first terminal and the second terminal, store the content of the transaction sent from the second terminal as the content of the transaction related to the user. A program recording medium recording a program for causing the above to be executed. The causing of the cooperation includes determining whether the second terminal is a terminal defined for store clerks, and when the second terminal is a terminal defined for store clerks, causing the second terminal to cooperate with the process of storing the content of the transaction related to the user of the first terminal. The causing of the cooperation includes, when the identifier of the second terminal is acquired via the first terminal, storing the association between the identifier of the first terminal and the identifier of the second terminal, thereby causing the second terminal to cooperate with the process of storing the content of the transaction related to the user. Program recording medium.

Images