Information processing device and information processing program

Abstract

To prevent an operator from being distracted by operations while moving.SOLUTION: The information processing device according to an embodiment includes acquisition means, first detection means, second detection means, and determination means. The acquisition means acquires an identifier in response to an operation by an operator. The first detection means detects a presence state in which the operator is in a predetermined area. The second detection means detects the movement of the operator. The determination means determines the identifier acquired by the acquisition means as an identifier of a transaction target when the presence state is detected by the first detection means and the movement is not detected by the second detection means.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] An embodiment of the present invention relates to an information processing device and an information processing program. [Background technology]

[0002] Transaction processing systems in which transaction details are registered in response to a customer's operation of a mobile terminal device are being considered, such as cart POS systems and smartphone POS systems. In such a system, it is undesirable for customers to be distracted by operating their mobile terminal devices while on the move. In view of these circumstances, it has been desired to prevent operators such as customers from being distracted by operations while on the move. [Prior art documents] [Patent documents]

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

[0004] The problem to be solved by the present invention is to provide a terminal device and an information processing program that can prevent an operator from being distracted by operations while moving. [Means for solving the problem]

[0005] The information processing apparatus of the embodiment includes: an acquisition unit; move Detection Method 、 Decision making method and alarm means The acquisition means is , knowledge Get a separate account. move The detecting means detects the movement of the operator. move Movement by detection means Being in When the identifier is not detected, the identifier acquired by the acquisition means is determined to be the identifier of the object of transaction. The warning means performs a predetermined warning operation in response to the identifier being acquired by the acquisition means when the movement detection means detects that the mobile device is moving. [Brief explanation of the drawings]

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

[0007] An embodiment of a transaction processing system will be described below with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system according to this embodiment. The transaction processing system is configured so that a plurality of store systems 100, relay servers 200, and user terminals 300 can communicate with each other via a communication network 400. FIG. 1 shows two store systems 100. These store systems 100 are installed in two different stores, Store A and Store B, which use the transaction processing system. There may be three or more stores that use the transaction processing system, with a store system 100 installed in each store. In the following, when it is necessary to distinguish between the store systems 100 installed in each store, the store system 100 installed in Store A will be referred to as store system 100-1, and the store system 100 installed in Store B will be referred to as store system 100-2. The business operator of store A may be the same as or different from the business operator of store B. When the transaction system is used in other stores, the business operator of those stores may be the same as or different from the business operator of store A or store B.

[0008] The relay server 200 relays data communication between the user terminal 300 and the store system 100. The relay server 200 provides a data communication relay function as a cloud service via the communication network 400, for example. The user terminal 300 is an information processing device that functions as a user interface for customers who use the transaction system to shop at a store. The user terminal 300 has a function for wireless communication with the store system 100 and a function for wireless communication with the communication network 400. The user terminal 300 can be a communication terminal with a data communication function, such as a smartphone or tablet terminal. The user terminal 300 may be owned by the customer or may be loaned to the customer by the store. The communication network 400 may be, for example, the Internet, a virtual private network (VPN), a local area network (LAN), a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. Typically, the communication network 400 is a combination of a mobile communication network and the Internet or a VPN.

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

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

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

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

[0013] The access point 6 performs communication processing to enable the user terminal 300 to access the in-store communication network 7 via wireless communication. The access point 6 may be, for example, a well-known communication device that performs wireless communication according to the IEEE802.11 standard. The access point 6 is installed within the store so that the user terminal 300 can communicate wirelessly from anywhere on the sales floor of the store. Depending on the size of the store, multiple access points 6 may be installed in one store system 100. The in-store communication network 7 may be the Internet, VPN, LAN, public communication network, mobile communication network, or the like, either alone or in appropriate combination, but typically the in-store communication network 7 is a LAN.

[0014] In a 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 check-out data differ from store to store. Therefore, when it is necessary to distinguish between the two-dimensional codes TCI and TCO for store A and the two-dimensional codes TCI and TCO for store B, the codes for store A are represented as two-dimensional codes TCIA and TCOA, and the codes for store B are represented as two-dimensional codes TCIB and TCOB.

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

[0016] (4) The name of the business operator that operates the store where the store system 100 is installed. For example, the check-in data represented by the two-dimensional code TCIA represents the name of the business operator that operates store A. The check-in data represented by the two-dimensional code TCIB represents the name of the business operator that operates store B. (5) The name of the store where the store system 100 is installed. For example, the check-in data represented by the two-dimensional code 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 two-dimensional code TCI and two-dimensional code TCO. This flag in the check-in data indicates that it is check-in data. For example, this state is "1." This flag is common to all two-dimensional code TCI.

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

[0018] (10) A flag indicating whether the user terminal 300 should use wireless communication with the access point 6 or wireless communication with the communication network 400 to exchange data with the store system 100. For example, in store A, if wireless communication with the access point 6 is used to exchange data between the store system 100-1 and the user terminal 300, the flag is set to, for example, "1." For example, in store B, if wireless communication with the communication network 400 is used to exchange data between the store system 100-2 and the user terminal 300, the flag is set to, for example, "0." (11) SSID (service set identifier) ​​for identifying the access point 6. For example, the check-in data represented by the two-dimensional code 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 for 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.

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

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

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

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

[0023] (21) A flag for identifying whether or not to delete the check digit of a UPC (universal product code), which is a type of product code. For example, if store A operates without deleting the check digit, the check-in data represented by the two-dimensional code TCIA will indicate, for example, a "1" as the flag. For example, if store B operates with the check digit deleted, the check-in data represented by the two-dimensional code TCIB will indicate, for example, a "0" as the flag. (22) The time until the camera screen automatically transitions on the user terminal 300. The check-in data represented by the two-dimensional code TCIA represents the time set in advance for store A. The check-in data represented by the two-dimensional code TCIB represents the time set in advance for store B. (23) Timeout period when the user terminal 300 communicates with the store system 100 via the access point 6. The check-in data represented by the two-dimensional code TCIA represents the time set in advance for store A. The check-in data represented by the two-dimensional code TCIB represents the time set in advance for store B.

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

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

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

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

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

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

[0030] The main memory 12 corresponds to the main storage portion of the computer. The main memory 12 includes a nonvolatile memory area and a volatile memory area. The main memory 12 stores the information processing program in the nonvolatile memory area. The main memory 12 may store data required for the processor 11 to execute information processing in either the nonvolatile or volatile memory area. The main memory 12 uses the volatile memory area as a work area where data is rewritten by the processor 11 as appropriate. The nonvolatile memory area is, for example, ROM (read only memory). The volatile memory area is, for example, RAM (random access memory).

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

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

[0033] 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 that describes information processing for realizing the functions of the store server 1. A separate store management application APAA may be created for each store or for each business that operates the store, based on the store management policy of that store. For example, if store A and store B use different sales data management methods, the store management application APAA used in store system 100-1 would describe information processing for managing sales data that is adapted to the sales data management method used by store A, and the store management application APAA used in store system 100-2 would describe information processing for managing sales data that is adapted to the sales data management method used by store B.

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

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

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

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

[0038] However, the auxiliary storage unit 23 stores a virtual POS application APBA instead of the store management application APAA. The virtual POS application APBA is an application program that describes the information processing required to realize the functions of the virtual POS server 2. A separate virtual POS application APBA may be created for each store or for each store operator to suit the store management policy. For example, if store A offers a discount service that is not offered at store B, the virtual POS application APBA used in store system 100-1 will describe the information processing required to realize the discount service, while the virtual POS application APBA used in store system 100-2 will not describe the information processing required to realize the discount service.

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

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

[0041] However, the auxiliary storage unit 33 stores a registration assistance application APCA instead of the store management application APAA. The registration assistance application APCA is an application program that describes information processing, described below, for assisting in the registration of purchased items. The registration assistance application APCA is common to each store system 100. However, various settings for information processing based on the registration assistance application APCA may be customized for each store system 100.

[0042] Furthermore, part of the storage area of ​​the auxiliary storage unit 23 is used as a transaction management database DBCA and a registration database DBCB in place of the database group DBAA. The structures of the transaction management database DBCA and the registration database DBCB are common to each store system 100.

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

[0044] Field FAA is set with a terminal code for distinguishing the associated user terminal 300 from other user terminals 300. The terminal code may be, for example, a unique identification code assigned to each communication terminal used as the user terminal 300 to identify each individual communication terminal. Alternatively, the terminal code may be, for example, an identification code assigned to a smartphone POS app (described below) when the smartphone POS app is installed on the user terminal 300. Field FAB is set with a membership code for distinguishing a customer using the associated user terminal 300 from other customers. Field FAC is set with a transaction code for a transaction performed using the associated user terminal 300.

[0045] FIG. 6 is a schematic diagram showing the main data structure of a data record DRB contained in the registration database DBCB. The registration database DBCB is a collection of data records DRB associated with transactions with customers shopping around the store. The data records DRB include fields FBA, FBB. The data records DRB may also include fields FBC, FBD, etc.

[0046] Field FBA contains the transaction code of the associated transaction. This transaction code is the same as the transaction code set in field FAB of data record DRA associated with the user terminal 300 used in the associated transaction. Field FBB contains registration data regarding the attempted product registration for the associated transaction. The registration data is described below. The data record DRB includes fields FBC and subsequent fields when an attempt is made to register two or more purchase items for an associated transaction. The same registration data as field FBB is set in the fields FBC and subsequent fields.

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

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

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

[0050] The touch panel 304 functions as an input device and a display device for the user terminal 300 . The camera 305 includes an optical system and an image sensor, and generates image data representing an image within a field of view formed by the optical system using the image sensor. The sound unit 306 outputs various sounds such as voices and melodies. The sensor group 307 includes various sensors such as an angular velocity sensor and a GPS (global positioning system) sensor.

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

[0052] The auxiliary storage unit 303 stores the smartphone POS app APEA, which is one of the information processing programs. The smartphone POS app APEA is an application program that describes the information processing described below for making the user terminal 300 function as a user interface for the store system 100. The smartphone POS app APEA is used in common by multiple user terminals 300.

[0053] Now, for example, a general-purpose server device can be used as the hardware of the store server 1, the virtual POS server 2, or the mobile controller 3. The store server 1, the virtual POS server 2, or the mobile controller 3 is generally transferred in a state in which the store management application APAA, the virtual POS application APBA, or the registration assistance application APCA is stored in the auxiliary storage unit 13, 23, or 33, respectively, but the database group DBAA, the transaction database DBBA, or the transaction management database DBCA, and the registration database DBCB are not stored. However, the hardware may be transferred separately from the store management application APAA, the virtual POS application APBA, or the registration assistance application APCA in a state in which the store management application APAA, the virtual POS application APBA, or the registration assistance application APCA is not stored in the auxiliary storage unit 13, 23, or 33, or in a state in which a different version of the same application program is stored in the auxiliary storage unit 13, 23, or 33. The store server 1, the virtual POS server 2, or the mobile controller 3 may be configured by writing the store management application APAA, the virtual POS application APBA, or the registration assistance application APCA to the auxiliary storage unit 13, 23, or 33 in response to an operator's operation. The store management application APAA, the virtual POS application APBA, or the registration assistance application APCA may be transferred by recording it on a removable storage medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network. The transaction database DBBA, or the transaction management database DBCA and the registration database DBCB are configured in the auxiliary storage unit 13, 23, or 33 by the processor 11, 21, or 31 executing information processing based on the store management application APAA, the virtual POS application APBA, or the registration assistance application APCA. At least a portion of the store management application APAA and the databases included in the database group DBAA may be stored in the main memory 12. At least a portion of the virtual POS application APBA and the transaction database DBBA may be stored in the main memory 22. At least a part of the registration assistance application APCA, the transaction management database DBCA, and the registration database DBCB may be stored in the main memory 32.

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

[0055] To use the smartphone POS service, the user terminal 300 exchanges data with the store system 100. Whether to use wireless communication with the access point 6 or wireless communication with the communication network 400 for this communication is determined by the state of a flag included in the check-in data. However, for simplicity of explanation, the following will describe the case where only wireless communication with the access point 6 is used. Furthermore, to perform a transaction at the payment machine 5, whether to use a mode in which the virtual POS server 2 requests data transfer from the payment machine 5 to the mobile controller 3, or a mode in which data is transferred from the mobile controller 3 to the payment machine 5 without a request from the payment machine 5, is determined by the state of a flag included in the check-in data. However, for simplicity of explanation, the following will be described assuming that the mode in which data transfer from the payment machine 5 to the mobile controller 3 is always used.

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

[0057] In the user terminal 300, the processor 301 executes information processing as shown in FIGS. 9, 10, 11, 12, and 13 based on the smartphone POS application APEA. First, in ACT101 shown in FIG. 9, the processor 301 displays the main menu screen on the touch panel 304. The main menu screen is a screen for receiving designation of one of several processes to be performed based on the smartphone POS app APEA. The main menu screen has multiple GUI (graphical user interface) elements arranged on it, including a GUI element for designating the start of shopping. The GUI elements are, for example, soft keys.

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

[0059] When a customer enters a store and starts shopping, the customer performs a predetermined operation on the main menu screen to specify the start of shopping. When an operation to specify the start of shopping is detected, for example, on the touch panel 304, the processor 301 determines YES in ACT102 and proceeds to ACT104. As ACT104, the processor 301 displays a check-in scan screen on the touch panel 304. The check-in scan screen is a screen that prompts the customer to read the check-in two-dimensional code TCI. The processor 301, for example, activates the camera 305, and generates the scan screen by superimposing on an image obtained by the camera 305 a text message prompting the customer to read the two-dimensional code TCI and a line indicating the position where the two-dimensional code TC should be held over it.

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

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

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

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

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

[0065] In ACT201 of FIG. 14, the processor 31 performs check-in processing. For example, the processor 31 requests the virtual POS server 2 to start a transaction and receives notification of a transaction code. The processor 31 then adds a new data record DRA, in which the terminal code included in the request data is set in field FAA, to the transaction management database DBCA. If the request data includes a membership code, the processor 31 sets the membership code in field FAB of the new data record DRA. The processor 31 sets the notified transaction code in field FAC of the new data record DRA. This starts management of the transaction performed using the user terminal 300 that requested check-in. In the virtual POS server 2, when the start of a transaction is requested by the mobile controller 3, the processor 21 determines a transaction code according to predetermined rules and starts the registration process of the purchased product in association with the transaction code. The processor 21 also notifies the mobile controller 3 of the determined transaction code.

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

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

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

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

[0070] On the other hand, if the notification data for notifying the check-in completion is received by the wireless communication unit 308, the processor 301 determines YES in ACT 109 and proceeds to ACT 112 in FIG. 10. At this time, it is clear that the user terminal 300 is present inside the store. In other words, the processor 301 detects that the operator using the user terminal 300 is present inside the store, which is an example of a predetermined area. Thus, by the processor 301 executing information processing based on the smartphone POS app APEA, the computer with the processor 301 as its central part functions as a first detection means. In ACT 112, the processor 301 displays a list screen on the touch panel 304. The list screen is a screen that displays a list of registered purchased products.

[0071] FIG. 18 is a diagram showing an example of the list screen SCA. The list screen SCA includes display areas ARAA and ARAB and buttons BUAA, BUAB, and BUAC. The display area ARAA shows the total number of purchased items and the total price of the purchased items. The display area ARAB shows a list of purchased items. The button BUAA is a soft key that allows the customer to declare that they want to cancel all purchased items and stop shopping. The button BUAB is a soft key that allows the customer to declare that they want to start scanning items to be registered as purchased items. The button BUAC is a soft key that allows the customer to declare that they want to start checkout.

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

[0073] As ACT 113, processor 301 measures the moving speed of a customer operating user terminal 300 equipped therein. For example, processor 301 measures the moving speed of the customer as the moving speed of user terminal 300 equipped therein. For example, processor 301 measures the moving speed of user terminal 300 using well-known processing based on changes in angular velocity measured by an angular velocity sensor included in sensor group 307. Alternatively, processor 301 measures the moving speed of user terminal 300 using well-known processing based on changes in position measured by a GPS sensor included in sensor group 307.

[0074] In ACT 114, the processor 301 checks whether the speed is exceeding a predetermined threshold. For example, the processor 301 checks whether the measured speed is equal to or greater than a predetermined threshold. If the speed is less than the threshold, the processor 301 determines that the speed is not exceeding a threshold and proceeds to ACT 115. Alternatively, the processor 301 may perform other processing in ACT 114, such as checking whether the speed is equal to or less than a threshold and determining that the speed is not exceeding a threshold if it is. The threshold may be arbitrarily set by the creator of the smartphone POS app APEA, for example. The threshold may also be arbitrarily set by the store manager and included in the check-in data. However, the threshold should be set so that the speed is determined to be exceeding a speed when the customer is actually moving. Thus, when the processor 301 determines YES in ACT 114, it has detected the movement of the customer (the operator). Thus, by the processor 301 executing information processing based on the smartphone POS app APEA, the computer with the processor 301 as its core functions as a second detection means.

[0075] In ACT 115, the processor 301 checks whether or not a command to start scanning the product has been issued. If the command has not been issued, the processor 301 determines the result as NO and proceeds to ACT 116. In ACT 116, the processor 301 checks whether or not a change in quantity has been specified. If the processor 301 cannot confirm such a specification, it determines NO and proceeds to ACT 117. In ACT 117, the processor 301 checks whether or not a shopping cancellation has been specified. If the processor 301 cannot confirm such a specification, it determines the result as NO and proceeds to ACT 118. In ACT 118, the processor 301 checks whether or not the start of the transaction has been designated. If the processor 301 cannot confirm that the designation has been made, it determines the answer as NO and returns to ACT 113. Thus, when the speed limit is not exceeded, the processor 301 waits for one of the following to be specified in ACT115 to ACT118: start of scan, quantity, stop, or start of accounting.

[0076] On the other hand, if the moving speed is equal to or greater than the threshold value, the processor 301 determines that the speed is excessive, determines YES in ACT114, and proceeds to ACT119. In ACT119, processor 301 checks whether any operation has been performed. If processor 301 cannot confirm any operation, it determines NO and returns to ACT113. In other words, if the speed is exceeded, processor 301 repeats the check in ACT119 and waits for any operation to be performed. If processor 301 confirms that any operation has been performed in this state, it determines YES in ACT119 and proceeds to ACT120. In other words, processor 301 proceeds to ACT120 if the customer performs an operation to specify, for example, start scanning, quantity, stop, or start checkout while moving at a speed equal to or greater than the threshold.

[0077] In ACT120, the processor 301 executes an alarm operation. The alarm operation is a predetermined operation for warning customers that they cannot operate the device while it is moving. The processor 301, for example, drives the sound unit 306 to output a predetermined voice message. The output of a voice message is suitable for this alarm because it can audibly alert customers. Note that instead of or in addition to outputting a voice message, the processor 301 may execute an alarm operation such as outputting an alarm sound from the sound unit 306, displaying an alarm screen on the touch panel 304, or lighting a lamp (not shown). Note that customers often visually check the display on the touch panel 304 in order to operate the device. For this reason, a display on the touch panel 304 or the like also serves as an effective alarm. After completing the alarm operation, the processor 301 repeats ACT113 and subsequent steps in the same manner as described above.

[0078] If the customer wishes to register the product as a purchased product, he or she specifies the start of scanning by a predetermined operation such as touching a button BUAB on the list screen SCA. In response to this, the processor 301 determines YES in ACT115 and proceeds to ACT121 in FIG. In ACT 121, the processor 301 displays a registration screen on the touch panel 304. The registration screen is a screen that prompts the customer to read a barcode that represents the product code of the product to be registered as a purchased product.

[0079] FIG. 19 is a diagram showing an example of the registration screen SCB. The registration screen SCB includes a display area ARBA, a message MEBA, and a button BUBA. The display area ARBA displays an image captured by the camera 305. The message MEBA is a text message that prompts the customer to scan the barcode of the product. The button BUBA is a soft key that the customer presses to stop scanning the product code. For example, the processor 301 activates the camera 305, and generates the registration screen SCB by superimposing on the image obtained by the camera 305 a line indicating the range of the display area ARBA, and an image showing the message MEBA and button BUBA.

[0080] In ACT122, the processor 301 measures the moving speed of the customer operating the user terminal 300 provided thereto, similarly to, for example, ACT113 in Fig. 10. However, the processor 301 may perform processing different from ACT113 in ACT122. In ACT 123, the processor 301 checks whether or not the vehicle is in an overspeeding state, for example, in the same manner as in ACT 114 in Fig. 10. However, the processor 301 may perform processing in ACT 123 different from that in ACT 114. If the moving speed is less than the threshold, the processor 301 determines that the vehicle is not in an overspeeding state and determines NO, and proceeds to ACT 124.

[0081] In ACT124, the processor 301 checks whether the barcode has been read. At this time, the processor 301 analyzes the image obtained by the camera 305 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS app APEA, or may be performed as a process based on a separate application program for reading barcodes. If the barcode cannot be read, the processor 301 determines NO and proceeds to ACT125. In ACT 125, the processor 301 checks whether or not a command to stop scanning has been issued. If the processor 301 cannot confirm this command, it determines "NO" and returns to ACT 122. Thus, if the speed is not excessive, the processor 301 waits in ACT124 and ACT125 until the barcode is read or until a command to stop scanning is issued.

[0082] On the other hand, if the moving speed is equal to or greater than the threshold value, the processor 301 determines that the moving speed is excessive, determines YES in ACT123, and proceeds to ACT126. In ACT126, the processor 301 checks whether any operation has been performed. If the processor 301 cannot confirm any operation, it determines NO and returns to ACT122. In other words, if the speed limit is exceeded, the processor 301 repeats the check in ACT126 and waits for any operation to be performed. If the processor 301 confirms that any operation has been performed in this state, it determines YES in ACT126 and proceeds to ACT127. In other words, the processor 301 proceeds to ACT127 if the customer performs, for example, an operation to read a barcode or an operation to stop scanning while moving at a speed equal to or greater than the threshold. In ACT127, the processor 301 executes an alarm operation, for example, in the same manner as ACT120 in Fig. 10. Thus, the processor 301 executes information processing based on the smartphone POS application APEA, and the computer having the processor 301 as its central part functions as an alarm means. However, the processor 301 may perform processing in ACT 123 that is different from that in ACT 114. After the warning operation is completed, the processor 301 repeats ACT 122 and subsequent steps in the same manner as described above.

[0083] If the customer wishes to return to the list screen without performing this scan, the customer specifies to stop the scan by a predetermined operation such as touching the button BUBA. In response to this, the processor 301 determines YES in ACT125 and returns to ACT112 in FIG.

[0084] When the registration screen is displayed on the touch panel 304, the customer, without moving, points the camera 305 at the product to be registered as a purchased product so that the barcode displayed on the product is reflected in the display area ARBA. In response, the processor 301 determines YES in ACT124 and proceeds to ACT128. In ACT128, the processor 301 requests registration from the mobile controller 3. The request data transmitted by the processor 301 includes data represented by the read barcode (hereinafter referred to as barcode data). At this time, the processor 301 acquires the product code contained in the barcode. The product code is an example of an identifier. The processor 301 determines the acquired product code as the identifier for identifying the product to be transacted when the customer (operator) is present within a predetermined area, i.e., the store, and no movement of the customer (operator) is detected. Thus, the processor 301 executes information processing based on the smartphone POS app APEA, and the computer with the processor 301 as its central part functions as an acquisition means and a determination means.

[0085] Incidentally, when the processor 301 determines YES in ACT126 as described above, the customer's operation that triggers this is the operation for reading the barcode as described above, and the customer is often visually checking the display on the touch panel 304. For this reason, while a warning by a voice message similar to that in ACT120 is effective, it is also effective to display a warning screen. FIG. 20 is a diagram showing an example of the warning screen SCC. The warning screen SCC is a screen in which the window WICA is superimposed on the registration screen SCB, with the barcode reflected in the display area ARBA. The window WICA displays a text message urging the customer to stop moving.

[0086] After notifying the user that check-in is complete in ACT204 in FIG. 14, the processor 31 in the mobile controller 3 proceeds to ACT205. In ACT205, the processor 31 checks whether or not a registration request has been made. If the processor 31 cannot confirm the request, it determines "NO" and proceeds to ACT206. In ACT 206, the processor 301 checks whether a quantity change has been requested. If the processor 301 cannot confirm the request, it determines NO and proceeds to ACT 207. In ACT207, the processor 31 checks whether a request to delete a purchased item has been made. If the processor 31 cannot confirm the request, it determines NO and proceeds to ACT208. In ACT 208, the processor 31 checks whether a request to cancel the purchased item has been made. If the processor 31 cannot confirm such a request, it determines NO and proceeds to ACT 209. In ACT209, the processor 31 checks whether or not a payment request has been made. If the processor 31 cannot confirm the request, it determines that the result is NO and returns to ACT205. Thus, the processor 31 waits for a request for registration, quantity change, deletion, cancellation, or accounting in ACT 205 to ACT 209. If a registration request is received from the user terminal 300 as described above, the processor 31 determines YES in ACT 205 and proceeds to ACT 210 in FIG.

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

[0088] In the virtual POS server 2, the processor 21 assumes that the barcode data included in the request data sent from the mobile controller 3 was read by a barcode scanner provided in an existing POS terminal, and attempts to register the purchased item using the same processing as an existing POS terminal. However, for some reason, the product code represented by the barcode data may not be registered in the product database. Also, the product may have a barcode other than the one representing the product code. In these cases, the processor 21 is unable to register the purchased item and will report an error. In this way, the processor 21 registers the purchased item based on the reading of the barcode representing the product code registered in the product database. The processor 21 manages purchased items using the transaction database DBBA.

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

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

[0091] The processor 31 updates the registration database DBCB based on the result data in ACT 212. This updating of the registration database DBCB is performed, for example, as follows.

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

[0093] Second case: This is a notification of a regular registration, and the data record DRB associated with the transaction being processed contains registration data that includes the notified product code, but the cancellation flag for that registration data is set to "1", indicating that it has been canceled. In this case, processor 31 proceeds in the same manner as in the first case above.

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

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

[0096] By updating the registration database DBCB by the processor 31 in this way, the registration database DBCB not only shows a list of purchased products registered in the virtual POS server 2, but also records any barcode reading errors. The processor 31 may store the barcode data sent in the registration request in the main memory 32 or the auxiliary storage unit 33, and in the fourth case described above, include this stored barcode data in the registration data. In this case, the processor 21 in the virtual POS server 2 may not include the barcode data in the result data. The processor 31 may also extract a product code from the stored barcode data and perform the processes in the first to third cases based on this product code. The processor 31 may also obtain the product name and price from the store server 1 or the like based on the product code.

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

[0098] After the processor 301 in the user terminal 300 requests registration in ACT128 in FIG. 11, the process proceeds to ACT129. In ACT 129, the processor 301 waits for an instruction to display the list screen. Then, when an instruction to display the list screen is received from the mobile controller 3 as described above, the processor 301 determines YES in ACT 129, returns to ACT 112 in Fig. 10, and again displays the list screen SCA on the touch panel 304. At this time, the processor 301 sets the list screen SCA to a screen that displays the product name, price, and quantity of the purchased product included in the instruction data.

[0099] FIG. 21 is a diagram showing an example of the list screen SCA in a state where purchased products have already been registered. The list screen SCA shown in Figure 21 is an example of a case where the following items have been registered for purchase: one item with the product name "AAA" and a price of 120 yen, two items with the product name "BBB" and a price of 98 yen, and one item with the product name "CCC" and a price of 1,024 yen. On the list screen SCA shown in Figure 21, the display area ARAB shows the product name, price, and quantity of these registered items. The display area ARAA also shows "4" as the total number and "1,340" as the total amount. The area surrounded by a dashed line to the left of the product name is an area for displaying an icon. The dashed line representing this area is not actually displayed on the list screen SCA.

[0100] When the customer touches the area on the list screen SCA that shows the quantity, the processor 301 displays a list box for specifying the quantity overlaid on the list screen SCA. When this list box is operated, the processor 301 receives this as a specification of the quantity. In this case, the processor 301 determines YES in ACT116 in Figure 10 and proceeds to ACT130 in Figure 12.

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

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

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

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

[0105] In ACT 216, processor 31 updates the registration database DBCB based on the result data. That is, processor 31 finds the registration data containing the notified product code from the data record DRB associated with the transaction being processed. Then, processor 31 rewrites the quantity contained in the corresponding registration data with the quantity contained in the result data.

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

[0107] In ACT217, the processor 31 instructs the user terminal 300 to display a list screen. The processor 31 includes in the instruction data the product code, product name, price, and quantity contained in the registration data whose cancellation flag is "0" among the registration data contained in the data record DRB updated as described above. The processor 31 then returns to the standby state of ACT205 to ACT209 in FIG.

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

[0109] In ACT 133, the processor 301 checks whether or not deletion has been specified. If the processor 301 cannot confirm that the specification has been made, it determines NO and proceeds to ACT 134. In ACT 134, the processor 301 checks whether or not a return has been specified. If the processor 301 cannot confirm that a return has been specified, it determines NO and returns to ACT 133. Thus, the processor 301 waits for deletion or return to be specified in ACT133 and ACT134.

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

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

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

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

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

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

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

[0117] In ACT221, the processor 31 instructs the user terminal 300 to display a list screen. The processor 31 includes in the instruction data the product code, product name, price, and quantity contained in the registration data whose cancellation flag is "0" among the registration data contained in the data record DRB updated as described above. The processor 31 then returns to the standby state of ACT205 to ACT209 in FIG.

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

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

[0120] In ACT 138, the processor 301 checks whether or not cancellation execution has been specified. If the processor 301 cannot confirm this specification, it determines NO and proceeds to ACT 139. In ACT 139, the processor 301 checks whether or not a return has been specified. If the processor 301 cannot confirm that a return has been specified, it determines NO and returns to ACT 138. Thus, the processor 301 waits for cancellation or return to be specified as ACT138 and ACT139.

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

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

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

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

[0125] After transferring the deletion request in ACT222, the processor 31 in the mobile controller 3 proceeds to ACT223. The processor 31, as ACT 223, 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.

[0126] In ACT 224, the processor 31 updates the registration database DBCB based on the result data. That is, the processor 31 changes the cancellation flags that are set to "0" to "1" for all of the registration data included in the data record DRB associated with the transaction being processed. In ACT225, the processor 31 notifies the user terminal 300 of the cancellation. Then, the processor 31 then returns to the standby state of ACT205 to ACT209 in FIG.

[0127] After the processor 301 in the user terminal 300 requests cancellation in ACT140 in FIG. 12, the process proceeds to ACT141. In ACT141, the processor 301 waits for a cancellation notification from the mobile controller 3. If a cancellation notification is received as described above, the processor 301 determines YES and returns to ACT101 in FIG.

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

[0129] As described above, processor 301 receives the operation by the customer as a valid operation in ACT 115 to ACT 118. In other words, processor 301 receives the operation by the customer as a valid operation when the customer is present in the store, which is a predetermined area, and the movement of the customer is not detected. Thus, by processor 301 executing information processing based on the smartphone POS app APEA, the computer with processor 301 as its central part functions as an operating means.

[0130] If a payment request is received from the user terminal 300 as described above, the processor 31 in the mobile controller 3 determines YES in ACT 209 in FIG. 14 and proceeds to ACT 226 in FIG. In ACT226, the processor 31 instructs the user terminal 300 to display the accounting screen.

[0131] After the processor 301 in the user terminal 300 requests accounting in ACT 142 in FIG. 10, the process proceeds to ACT 143. In ACT 143, the processor 301 waits for an instruction to display the checkout screen. If the processor 301 confirms that an instruction to display the checkout screen has been issued as described above, it determines YES and proceeds to ACT 144 in FIG. In ACT 144, the processor 301 displays an accounting screen on the touch panel 304. The accounting screen is a screen that allows the customer to select whether to use the user terminal 300 or the accounting machine 5 to perform the operation for settling the price.

[0132] FIG. 22 is a diagram showing an example of the checkout screen SCD. The checkout screen SCD includes a display area ARDA, a message MEDA, and buttons BUDA and BUDB. The display area ARDA shows the total number of purchased items and the total price of the purchased items. The message MEDA is a text message that prompts the customer to specify whether to perform the payment operation on the user terminal 300 or the payment machine 5. The button BUDA is a soft key that allows the customer to specify the user terminal 300. The button BUDB is a soft key that allows the customer to specify the payment machine 5.

[0133] If the customer wishes to pay the bill using user terminal 300, the customer designates user terminal 300 by a predetermined operation such as touching button BUDA. If the customer wishes to pay the bill using payment machine 5, the customer designates payment machine 5 by a predetermined operation such as touching button BUDB.

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

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

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

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

[0138] After the processor 31 in the mobile controller 3 issues an instruction to display the checkout screen in ACT226 in FIG. 17, the processor 31 proceeds to ACT227. In ACT 227, the processor 31 checks whether or not a payment request has been made. If the processor 31 cannot confirm the request, it determines "NO" and proceeds to ACT 228. In ACT 228, the processor 31 checks whether or not the notice of completion of the settlement has been received. If the notice has not been received, the processor 31 determines the result as NO and returns to ACT 227. Thus, the processor 31 waits for a payment request or a payment completion notification in ACT 227 and ACT 228. Then, if a payment request is received from the user terminal 300 as described above, the processor 31 determines YES in ACT 227 and proceeds to ACT 229.

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

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

[0141] After the processor 31 in the mobile controller 3 transfers the payment request in ACT229, the processor 31 proceeds to ACT230. In ACT230, the processor 31 waits for notification of payment completion from the virtual POS server 2. Then, if the result data indicating that payment has been completed and sent by the virtual POS server 2 as described above is received by the communication interface 34, the processor 31 determines the answer as YES and proceeds to ACT231. Furthermore, if the processor 31 is notified of payment completion at the accounting machine 5 as described above, the processor 31 determines the answer as YES in ACT228 and proceeds to ACT231. In ACT231, the processor 31 notifies the user terminal 300 that the payment has been completed.

[0142] After the processor 301 in the user terminal 300 requests payment from the mobile controller 3 in ACT 147 in FIG. 13, or after displaying the accounting barcode screen in ACT 148, the processor 301 proceeds to ACT 149. In ACT 149, the processor 301 waits for notification of the completion of the payment. If the processor 301 receives notification of the completion of the payment from the mobile controller 3 as described above, the processor 301 determines YES and proceeds to ACT 150. In ACT 150, the processor 301 displays a completion screen on the touch panel 304. The completion screen is a screen for notifying the customer that the payment has been completed.

[0143] Once the customer has confirmed the completion screen, they declare that they have confirmed it by performing a predetermined operation, such as touching a button displayed on the completion screen. In response to this, the processor 301 proceeds to ACT 151. The processor 301 may also proceed to ACT 151 when the elapsed time while the completion screen is displayed reaches a predetermined time.

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

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

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

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

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

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

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

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

[0152] As described above, the user terminal 300 of this embodiment determines, as a valid product code for registration, a product code that the customer attempts to read while the customer is in the store and not moving. Therefore, the customer must remain stationary while entering the product code, preventing the customer from being distracted by the operation while moving around. Note that the operation to have the user terminal 300 read the product code is frequently performed by the customer while looking around the store. Therefore, by restricting this operation, the above-mentioned effects can be achieved efficiently.

[0153] Furthermore, the user terminal 300 does not accept operations to start scanning, specify the quantity, cancel, start accounting, or cancel scanning while the customer is in the store and not moving. Therefore, the customer must perform these operations while standing still, which prevents the customer from being distracted by operations while moving around.

[0154] Furthermore, if the user terminal 300 is present in the store but does not accept the operation as a valid operation because it is performed by a moving customer, the user terminal 300 will issue a warning, thereby letting the customer know that they should stop and operate the device.

[0155] This embodiment can be modified in various ways as follows. The above embodiment illustrates an example in which the user terminal 300 reads the product code of a product that a customer purchases from among the products displayed for sale in a store. In other words, the user terminal 300, product code, store, and purchased product in the above embodiment correspond to the information processing device, identifier, predetermined area, and transaction object. However, for example, in a shopping mall, when a customer orders a food and drink menu item at a restaurant they will visit in response to operations on a cart terminal attached to a shopping cart, which is a facility of the shopping mall, it is possible to impose similar operation restrictions as in the above embodiment. In this example, the cart terminal, the food and drink menu identification code, the shopping mall, and the food and drink menu correspond to the information processing device, identifier, predetermined area, and transaction object. In this way, the information processing device, identifier, predetermined area, and transaction object can be changed as appropriate.

[0156] If the information processing device is a shopping cart that is a facility of a shopping mall, it is possible to detect the presence status of the device in a predetermined area if it is capable of communicating with an access point provided in the shopping mall or if it is capable of receiving a beacon signal transmitted from a beacon transmitter provided in the shopping mall. In this way, the method of detecting the presence status can be changed in various ways.

[0157] If the information processing device is a cart terminal, it is also possible to measure the customer's movement speed as the movement speed of the shopping cart and detect the customer's movement based on that movement speed. In this way, the method for detecting the customer's movement can be modified in various ways.

[0158] The user terminal 300 may be operated mainly as a user interface, and the processing in ACT114, ACT119 in FIG. 10 and ACT123, ACT126 in FIG. 11, and the control processing for alarm operation in ACT120 in FIG. 10 and ACT127 in FIG. 11 may be executed by another information processing device, such as a mobile controller 3.

[0159] The processor 301 may perform the same processing as ACT114, ACT119, and ACT120 in Fig. 10 in the standby state of ACT102 and ACT103 in Fig. 9, the standby state of ACT105, the standby state of ACT133 and ACT134 in Fig. 12, the standby state of ACT138 and ACT139, or the standby state of ACT145 and ACT146 in Fig. 13. The processor 301 may also perform the same processing as ACT114, ACT119, and ACT120 in Fig. 10 in the standby state of an operation not shown in the information processing of Figs. 9 to 13. The processor 301 may also omit ACT113, ACT114, ACT119, and ACT120 in Fig. 10.

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

[0161] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. The inventions described in the original claims of this application are set forth below. [Supplementary Note 1] An acquisition means for acquiring an identifier in response to an operation by an operator; a first detection means for detecting a presence state of the operator within a predetermined area; a second detection means for detecting the movement of the operator; a determination means for determining, when the presence state is detected by the first detection means and the movement is not detected by the second detection means, the identifier acquired by the acquisition means as an identifier of the object of transaction; An information processing device equipped with the above. [Supplementary Note 2] An alarm means for performing a predetermined alarm operation in response to acquisition of the identifier by the acquisition means when the presence state is detected by the first detection means and the movement is detected by the second detection means; 2. The information processing device according to claim 1, further comprising: [Supplementary Note 3] An operation means for receiving an operation by the operator as a valid operation when the presence state is detected by the first detection means and the movement is not detected by the second detection means; 2. The information processing device according to claim 1, further comprising: [Appendix 4] An alarm means for performing a predetermined alarm action in response to the operation received by the operating means when the presence state is detected by the first detecting means and the movement is detected by the second detecting means; 4. The information processing device according to claim 3, further comprising: [Supplementary Note 5] The warning means outputs a predetermined sound as the warning action. 5. The information processing device according to claim 2 or 4. [Appendix 6] A computer provided in an information processing device, an acquisition means for acquiring an identifier in response to an operation by an operator; a first detection means for detecting a presence state of the operator within a predetermined area; a second detection means for detecting the movement of the operator; a determination means for determining, when the presence state is detected by the first detection means and the movement is not detected by the second detection means, the identifier acquired by the acquisition means as an identifier of the object of transaction; An information processing program that makes it function as such. [Explanation of symbols]

[0162] 1...store server, 2...virtual POS server, 3...mobile controller, 4...communication server, 5...accounting machine, 6...access point, 7...in-store communication network, 11,21,31,41,301...processor, 12,22,32,42,302...main memory, 13,23,33,43,303...auxiliary storage unit, 14,24,34,44...communication interface, 15,25,35,46,310...transmission path, 45...communication unit, 100(100-1,100-2)...store system, 200...middle Relay server, 300...user terminal, 304...touch panel, 305...camera, 306...sound unit, 307...sensor group, 308...wireless communication unit, 309...mobile communication unit, 400...communication network, APAA...store management application, APBA...virtual POS application, APEA...smartphone POS application, APCA...registration support application, APDA...communication processing application, DBAA...database group, DBBA...transaction database, DBCA...transaction management database, DBCB...registration database.

Claims

1. An acquisition means for acquiring an identifier; a movement detection means for detecting the movement of an operator; a determination means for determining the identifier acquired by the acquisition means as the identifier of the transaction object when the movement detection means does not detect that the transaction object is moving; an alarm means for performing a predetermined alarm operation in response to the identifier being acquired by the acquisition means when the movement detection means detects that the vehicle is moving; An information processing device comprising:

2. The movement detection means detects the movement of the operator when the operator is in a predetermined speed exceeding state. The information processing device according to claim 1 .

3. The movement detection means detects the movement of the operator when the movement speed of the operator is equal to or greater than a predetermined threshold. The information processing device according to claim 1 .

4. A mobile information processing device, an acquisition means for acquiring an identifier; movement detection means for detecting movement of the information processing device; a determination means for determining the identifier acquired by the acquisition means as the identifier of the transaction object when the movement detection means does not detect that the transaction object is moving; an alarm means for performing a predetermined alarm operation in response to the identifier being acquired by the acquisition means when the movement detection means detects that the vehicle is moving; An information processing device comprising:

5. The movement detection means detects that the information processing device is moving when the information processing device is in a predetermined speed exceeding state. The information processing device according to claim 4 .

6. The movement detection means detects the movement of the operator when the movement speed of the operator is equal to or greater than a predetermined threshold. The information processing device according to claim 1 .

7. The computer provided in the information processing device, an acquisition means for acquiring an identifier; a movement detection means for detecting the movement of an operator; a determination means for determining the identifier acquired by the acquisition means as the identifier of the transaction object when the movement detection means does not detect that the transaction object is moving; an alarm means for performing a predetermined alarm operation in response to the identifier being acquired by the acquisition means when the movement detection means detects that the vehicle is moving; An information processing program that makes it function as such.

8. A computer provided in a mobile information processing device, an acquisition means for acquiring an identifier; movement detection means for detecting movement of the information processing device; a determination means for determining the identifier acquired by the acquisition means as the identifier of the transaction object when the movement detection means does not detect that the transaction object is moving; an alarm means for performing a predetermined alarm operation in response to the identifier being acquired by the acquisition means when the movement detection means detects that the vehicle is moving; An information processing program that makes it function as such.

9. When it is not detected that the operator is moving, the acquired identifier is determined as the identifier of the transaction object. Information processing device.

Images