Product sales processing system

Abstract

To facilitate reserved purchase of a stockout commodity.SOLUTION: A commodity sales processing system includes determination means, creating means, settlement means, and deciding means. The determination means determines a commodity. The creating means creates a list including a commodity determined by the determination means as a purchased commodity. The settlement means performs the settlement of the charge for the purchased commodity included in the list created by the creating means. The deciding means decides the purchased commodity as a reserved commodity when the purchased commodity determined by the determination means is out of stock.SELECTED DRAWING: Figure 12

Description

[Technical field]

[0001] An embodiment of the present invention relates to a product sales processing system. [Background technology]

[0002] In a store where products are displayed for sale, customers select and purchase the products they want from the products on display. Therefore, if a product is out of stock, it cannot be purchased. There is a known service in which a store clerk asks for a customer's contact information and then contacts the customer when an out-of-stock item becomes available, but this is a huge hassle for the store clerk. Due to these circumstances, it has been desirable to make it easier to pre-order out-of-stock items. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-102158 A 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 product sales processing system that can facilitate advance purchase of out-of-stock products. [Means for solving the problem]

[0005] The product sales processing system according to the embodiment is a product sales processing system for processing product sales in a store, comprising: a determination means; Reception means, confirmation means, The determination means determines whether the product is a product to be sold at the store. and the product is in stock at said store. Determine the following. The reception means receives a designation of a product to be sold at the store. The confirmation means confirms whether the product designated by the reception means is in stock at the store. The creation method is , buy top product of The list, For products for which the availability of stock cannot be confirmed by the confirmation means, a reservation is made in response to a request for reservation. Make it possible to distinguish that this is a pre-order item Including ,Also Regarding the product judged by the judgment meansMake it clear that this is not a pre-order item Including The payment means settles the price for all the purchased items included in the list created by the creation means. The determination means, when the purchased item determined by the determination means is out of stock, determines the purchased item as a reserved item. [Brief description of the drawings]

[0006] [Figure 1] 1 is a block diagram showing a schematic configuration of a product sales processing system according to an embodiment. [Diagram 2] 2 is a block diagram showing a main circuit configuration of the store server shown in FIG. 1; [Diagram 3] FIG. 5 is a schematic diagram showing the data structure of a data record contained in the reservation database shown in FIG. 4. [Figure 4] 2 is a block diagram showing a main circuit configuration of the virtual POS server shown in FIG. 1; [Diagram 5] 3 is a schematic diagram showing the data structure of a data record included in the transaction database shown in FIG. 2. [Figure 6] 2 is a block diagram showing a main circuit configuration of the mobile controller shown in FIG. 1. [Figure 7] FIG. 7 is a schematic diagram showing the data structure of a data record contained in the registration database shown in FIG. 6. [Figure 8] 2 is a block diagram showing a main circuit configuration of the user terminal shown in FIG. 1; [Figure 9] 2 is a block diagram showing the main circuit configuration of the cart terminal shown in FIG. 1. [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] 9 is a flowchart of a transaction process by the processor shown in FIG. 8 . [Figure 15] 7 is a flowchart of a transaction process by the processor shown in FIG. 6. [Figure 16] 7 is a flowchart of a transaction process by the processor shown in FIG. 6. [Figure 17] 7 is a flowchart of a transaction process by the processor shown in FIG. 6. [Figure 18] 7 is a flowchart of a transaction process by the processor shown in FIG. 6. [Figure 19] 5 is a flowchart of a transaction process by the processor shown in FIG. 4. [Figure 20] 5 is a flowchart of a transaction process by the processor shown in FIG. 4. [Figure 21] 5 is a flowchart of a transaction process by the processor shown in FIG. 4. [Figure 22] FIG. 13 is a diagram showing an example of a list screen in a state where no purchased product has been registered. [Figure 23] FIG. 13 is a diagram showing an example of a registration screen. [Figure 24] FIG. 13 is a diagram showing an example of a list screen in a state where purchased products have already been registered. [Diagram 25] FIG. 13 is a diagram showing an example of a stock-out screen. [Figure 26] FIG. 13 is a diagram showing an example of a list screen in a state where purchased products including reserved products have already been registered. [Figure 27] 3 is a flowchart of information processing by the processor shown in FIG. 2. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] Hereinafter, an embodiment of a product sales processing system will be described with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of a product sales processing system according to this embodiment. The product sales processing system includes a plurality of store systems 100, a user terminal 200, a cart terminal 300, and a relay server 400. The plurality of store systems 100, the user terminals 200, the cart terminals 300, and the relay server 400 are capable of communicating with each other via a communication network 500.

[0008] FIG. 1 shows two store systems 100. These store systems 100 are installed in two different stores, Store A and Store B, which use the product sales processing system. There may be three or more stores that use the product sales 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 who operates store A may be the same as or different from the business operator who operates store B. When the transaction system is used in other stores, the business operator who operates the other stores may be the same as or different from the business operator who operates store A or store B.

[0009] The user terminal 200 and the cart terminal 300 are information processing devices that function as a user interface for customers who use the product sales processing system to shop at a store. The user terminal 200 and the cart terminal 300 have a function of wireless communication with the store system 100 and a function of wireless communication with the communication network 500. The user terminal 200 may be a communication terminal with a data communication function such as a smartphone or a tablet computer. The user terminal 200 may be owned by the customer or may be loaned to the customer at the store. The cart terminal 300 may be a communication terminal with a data communication function such as a tablet computer, which is attached to a shopping cart installed in store A or store B. The user terminal 200 and the cart terminal 300 are mainly operated by customers. However, the user terminal 200 and the cart terminal 300 may also be operated by a store clerk or the like on behalf of the customer. The cart terminal 300 has a barcode scanner 301. The barcode scanner 301 is a reading device suitably configured to optically read a barcode showing a product code as an identifier for identifying a product using an infrared laser or the like. The barcode scanner 301 may be provided with a reading device configured to recognize and read a barcode from an image captured by an imaging device instead of or in addition to the above-mentioned reading device. The user terminal 200 and the cart terminal 300 are examples of portable terminals that can be moved around the store by customers.

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

[0011] 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 with each other 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 have the same functions for implementing the operations described below, and do not need to be completely identical. Some store systems 100 may also be equipped with devices not shown in FIG. 1.

[0012] 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 an external request. 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, there may be some differences between the information processing performed by the store server 1 provided in the store system 100-1 and the information processing performed by the store server 1 provided in the store system 100-2, for example.

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

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

[0015] The access point 6 performs communication processing to enable the user terminal 200 to access the in-store communication network 7 via wireless communication. For example, a well-known communication device that performs wireless communication according to the IEEE802.11 standard can be used as the access point 6. The access point 6 is installed in the store so that the user terminal 200 can perform wireless communication from anywhere in 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, a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. Typically, however, the in-store communication network 7 is a LAN.

[0016] 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. For this reason, 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.

[0017] The check-in data may, for example, represent information such as (1) the operation version of the store system 100, (2) a store code for identifying the store, (3) the name of the business operating the store, (4) the name of the store in which the store system 100 is installed, (5) a business code for identifying the business operating the store, (6) a flag for distinguishing between the two-dimensional code TCI and the two-dimensional code TCO, and (7) a connection destination and information required for the user terminal 200 to communicate with the store system 100. The connection destination for the user terminal 200 to communicate with the store system 100 may be the access point 6 or the relay server 400. The information required for the connection may include the domain name of the relay server 400 or an SSID (service set identifier) ​​for identifying the access point 6, and a password for accessing the access point 6 or the relay server 400. The check-in data may not include some of the various pieces of information exemplified above. Also, the check-in data may represent information other than the various pieces of information exemplified above.

[0018] FIG. 2 is a block diagram showing the main circuit configuration of the store server 1. As shown in FIG. 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 configure a computer for controlling the store server 1.

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

[0020] 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 a nonvolatile or volatile memory area. The main memory 12 uses the volatile memory area as a work area where data is appropriately rewritten by the processor 11. The nonvolatile memory area is, for example, a ROM (read only memory). The volatile memory area is, for example, a RAM (random access memory).

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

[0022] 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 between the connected components.

[0023] The auxiliary storage unit 13 stores a store management app APA, which is one of the information processing programs. The store management app APA is an application program, and describes information processing for realizing the functions of the store server 1. The store management app APA may be a separate app created for each store or for each store operating company in accordance with the store operating policy. For example, if the sales data management methods differ between store A and store B, the store management app APA used in store system 100-1 describes information processing for managing sales data adapted to the sales data management method in store A, and the store management app APA used in store system 100-2 describes information processing for managing sales data adapted to the sales data management method in store B.

[0024] A part of the storage area of ​​the auxiliary storage unit 13 is used as a database group DBAA. The database group DBAA includes a plurality of databases for various types of information management. One of the databases included in the database group DBAA is a product database for managing products sold in the store. 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 codes, prices, and product names. The product codes are identifiers determined to identify products for each SKU (stock keeping unit), and for example, JAN (Japanese article number) codes are used. The product names are names determined to make it easy for humans to distinguish between products. The price is the amount of money paid for the sale of the product.

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

[0026] One of the databases included in the database group DBAA is an inventory database DBAB. The inventory database DBAB describes inventory information that indicates the inventory status of the product identified by the product code in the store, in association with each product code of the products sold in the store. The inventory information includes, for example, the number of products in stock.

[0027] Moreover, one of the databases included in the database group DBAA is a reservation database DBAC. FIG. 3 is a schematic diagram showing the data structure of a data record REA contained in the reservation database DBAC. The reservation database DBAC is a collection of data records REA for managing advance purchases, which will be described later. The data records REA are associated with each of the products that are the subject of advance purchases, and include fields FBA, FBB, FBC, FBD, FBE, and FBF.

[0028] Field FBA is set to a reservation code as an identifier for managing pre-orders of the associated product. Field FBB is set to a customer code as an identifier for the customer who has pre-ordered the associated product. Field FBC is set to the product code of the associated product. Field FBD is set to the pre-order quantity of the associated product. Field FBE is set to the reservation date, which indicates the date and time of the pre-order. Field FBF is set to a notification flag, which indicates whether or not the product has been notified of arrival.

[0029] In addition, the database group DBAA may include various databases such as those managed by a POS server in an existing POS system. Note that the types of databases included in the database group DBAA, or the type of data and the structure in which those databases include, may be determined for each store.

[0030] FIG. 4 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 configure 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 equivalent to those of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 24, and the transmission path 25, and therefore will not be described here.

[0031] However, the auxiliary storage unit 23 stores a virtual POS application APB instead of the store management application APA. The virtual POS application APB is an application program, and describes information processing for realizing the functions of the virtual POS server 2. The virtual POS application APB may be a separate application created for each store or for each store operating company in accordance with the store operating policy. For example, if store A provides a discount service that is not provided in store B, the virtual POS application APB used in store system 100-1 describes information processing for realizing the discount service, and the virtual POS application APB used in store system 100-2 does not describe information processing for realizing the discount service.

[0032] Furthermore, a part of the storage area of ​​the auxiliary storage unit 23 is used as a transaction database DBBA and a reservation database DBAC in place of the database group DBAA. FIG. 5 is a schematic diagram showing the data structure of a data record REB contained in the transaction database DBBA. The transaction database DBBA is a collection of data records REB associated with transactions with customers shopping around the store. The data records REB include fields FAA, FAB. The data records REB may also include fields FAC, FAD, FAE, etc.

[0033] The transaction code of the associated transaction is set in field FAA. The user code of the customer of the associated transaction is set in field FAB. If purchased goods have been registered for the associated transaction, the fields following field FAC contain product data for each registered purchased item. The product data includes a product code, a product name, a price, a quantity, a reservation flag, etc. The structure of the transaction database DBBA may be determined individually for each store or for each business operator operating the store in accordance with the store management policy.

[0034] FIG. 6 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 configure a computer for controlling the mobile controller 3. Note that 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 similar to those of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 14, and the transmission path 15, and therefore a description thereof will be omitted.

[0035] However, the auxiliary storage unit 33 stores a registration support application APC instead of the store management application APA. The registration support application APC is an application program that describes information processing (described later) for supporting the registration of purchased items. The registration support application APC is common to each store system 100. However, various settings for information processing based on the registration support application APC may be customized for each store system 100.

[0036] 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 all store systems 100.

[0037] The transaction management database DBCA is a collection of data records associated with the user terminal 200 or cart terminal 300 used by a customer in the store. Therefore, when there is one customer using the user terminal 200 or cart terminal 300 in the store, the transaction management database DBCA contains one data record. On the other hand, when there are no customers using the user terminal 200 or cart terminal 300 in the store, the transaction management database DBCA does not contain any data records. The data records in the transaction management database DBCA describe the terminal code, user code, and transaction code in relation to each other. The terminal code included in the data record of the transaction management database DBCA is an identifier for identifying the associated user terminal 200 or cart terminal 300. For example, the terminal code may be a unique identification code set for each communication terminal to identify each communication terminal used as the user terminal 200 or cart terminal 300. Alternatively, for example, the terminal code may be an identification code set for a smartphone POS app described below when the smartphone POS app is installed in the user terminal 200, or an identification code set for the cart terminal app when the cart terminal app is installed in the cart terminal 300. The user code included in the data record of the transaction management database DBCA is a user code assigned to a customer using the associated user terminal 200 or cart terminal 300. The transaction code included in the data record of the transaction management database DBCA is an identifier for identifying a transaction performed using the associated user terminal 200 or cart terminal 300.

[0038] FIG. 7 is a schematic diagram showing the data structure of a data record REC contained in the registration database DBCB. The registration database DBCB is a collection of data records REC associated with transactions with customers shopping around the store. The data records REC then contain the fields FCA, FCB. The data records REC may also contain the fields FCC, FCD, ...

[0039] Field FCA is set with the transaction code of the associated transaction. This transaction code is the same as the transaction code contained in the data record associated in the transaction management database DBCA with the user terminal 200 or cart terminal 300 used in the associated transaction. Field FCB is set with registration data regarding the product registration attempted for the associated transaction. The registration data will be described later. The data record REC includes fields following the field FCC if an attempt is being made to register two or more purchase items for an associated transaction, and the fields following the field FCC are set with the same registration data as the field FCB.

[0040] FIG. 8 is a block diagram showing the main circuit configuration of the user terminal 200. As shown in FIG. The user terminal 200 includes a processor 201, a main memory 202, an auxiliary storage unit 203, a touch panel 204, a camera 205, a sound unit 206, a group of sensors 207, a wireless communication unit 208, a mobile communication unit 209, and a transmission path 210. The processor 201, the main memory 202, the auxiliary storage unit 203, the touch panel 204, the camera 205, the sound unit 206, the group of sensors 207, the wireless communication unit 208, and the mobile communication unit 209 are capable of communicating with each other via a transmission path 210. The processor 201, the main memory 202, and the auxiliary storage unit 203 are connected via the transmission path 210 to configure a computer for controlling the user terminal 200. The functions of the processor 201, the main memory 202, the auxiliary storage unit 203, and the transmission path 210 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.

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

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

[0043] The auxiliary storage unit 203 stores a smartphone POS app APD, which is one of the information processing programs. The smartphone POS app APD is an application program that describes information processing, which will be described later, for making the user terminal 200 function as a user interface for customers of the store system 100. The smartphone POS app APD is used in common by multiple user terminals 200.

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

[0045] The auxiliary storage unit 304 stores a cart terminal application APE, which is one of the information processing programs. The cart terminal application APE is an application program that describes information processing for making the cart terminal 300 function as a user interface for customers of the store system 100. The cart terminal application APE is used in common by the cart terminals 300.

[0046] The store server 1, the virtual POS server 2, the mobile controller 3, the user terminal 200, or the cart terminal 300 may be transferred in a state in which the store management application APA, the virtual POS application APB, the registration support application APC, the smartphone POS application APD, or the cart terminal application APE are stored in the auxiliary storage unit 13, 23, 33, 203, or 304, or the hardware in a state in which the store management application APA, the virtual POS application APB, the registration support application APC, the smartphone POS application APD, or the cart terminal application APE are not stored in the auxiliary storage unit 13, 23, 33, 203, or 304, and the store management application APA, the virtual POS application APB, the registration support application APC, the smartphone POS application APD, or the cart terminal application APE may be transferred individually. The transfer of the store management application APA, the virtual POS application APB, the registration support application APC, the smartphone POS application APD, or the cart terminal application APE may be performed by recording it on a removable recording medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network.

[0047] Next, the operation of the product sales 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 easily explain the characteristic operations of this embodiment, the description of some of the processes is omitted. For example, when some kind of error occurs, a process may be performed to deal with the error, but the description of some of such processes is omitted.

[0048] The service provided to customers by the operation of the product sales processing system described below is called a smartphone POS service or a cart POS service, but will be referred to as a smartphone POS service below. The following description will focus on the operation for realizing shopping using the user terminal 200. To use the smartphone POS service, the user terminal 200 exchanges data with the store system 100. The state of a flag included in the check-in data determines whether to use wireless communication with the access point 6 or wireless communication with the communication network 500 for this communication. However, in the following, for the sake of simplicity, a case will be described in which only wireless communication with the access point 6 is used. In addition, the state of a flag included in the check-in data determines whether to use a mode in which the payment machine 5 requests the mobile controller 3 to transfer data to the virtual POS server 2 to have the payment machine 5 perform a transaction, or a mode in which the mobile controller 3 transfers data to the payment machine 5 without a request from the payment machine 5. However, in the following, for the sake of simplicity, the mode in which the payment machine 5 requests the mobile controller 3 to transfer data is used as a fixed mode.

[0049] To use the smartphone POS service, a customer installs the smartphone POS app APD on a smartphone or the like that he or she owns, making it available as a user terminal 200. Alternatively, the customer borrows the user terminal 200 configured by installing the smartphone POS app APD on a tablet computer or the like from a store. The customer then enters any store in which a store system 100 is installed, carrying the user terminal 200 with information processing based on the smartphone POS app APD activated. Alternatively, after entering the store, the customer borrows a shopping cart provided in the store, together with the cart terminal 300 attached thereto.

[0050] The processor 201 of the user terminal 200 executes information processing based on the smartphone POS application APD. 10, 11, 12, 13 and 14 are flowcharts of information processing by the processor 201 based on the smartphone POS application APD. First, as ACT101 shown in Fig. 10, the processor 201 displays a main menu screen on the touch panel 204. The main menu screen is a screen for receiving a designation of one of several processes to be performed based on the smartphone POS application APD. On the main menu screen, a plurality of GUI elements are arranged, including a GUI (graphical user interface) element for designating the start of shopping. The GUI elements are, for example, soft keys.

[0051] In ACT 102, the processor 201 checks whether or not the start of shopping has been specified. If the processor 201 cannot check the event, it determines NO and proceeds to ACT 103. In ACT 103, the processor 201 checks whether or not a command other than the start of shopping has been issued. If the processor 201 cannot check the relevant event, it determines NO and returns to ACT 102. Thus, the processor 201 waits for some designation on the main menu screen in ACT102 and ACT103. If a designation other than the start of shopping is made, the processor 201 judges YES in ACT103 and proceeds to the designated process. Note that a description of the process of the processor 201 in this case will be omitted.

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

[0053] When the scan screen is displayed on the touch panel 204, the customer points the camera 205 at the two-dimensional code TCI posted near the store entrance so that the two-dimensional code TCI is reflected on the scan screen. In ACT105, the processor 201 waits for the two-dimensional code to be read. At this time, the processor 201 repeatedly analyzes the image obtained by the camera 205 and attempts to read the two-dimensional code. This reading of the two-dimensional code may be performed as a process based on the smartphone POS app APD, or may be performed as a process based on another application program for reading the two-dimensional code. Then, if the two-dimensional code is read, the processor 201 judges YES and proceeds to ACT106.

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

[0055] If the processor 201 confirms that the data represented by the read two-dimensional code is check-in data, it judges YES in ACT106 and proceeds to ACT107. The processor 201 as ACT 107 stores the read check-in data in the main memory 202 or the auxiliary storage unit 203 .

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

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

[0058] When request data for requesting check-in is received via the communication interface 34, the processor 31 of the mobile controller 3 starts information processing (hereinafter referred to as support processing) regarding the transaction with the customer attempting to check in in accordance with the registration support app APC. 15, 16, 17 and 18 are flowcharts of the support process by the processor 31.

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

[0060] As ACT201 in FIG. 15, the processor 31 performs a check-in process. For example, the processor 31 requests the virtual POS server 2 to start a transaction, along with notification of the user code included in the request data, and receives notification of the transaction code. The processor 31 then adds a new data record including the terminal code included in the request data to the transaction management database DBCA. The processor 31 includes the user code included in the request data in the new data record. The processor 31 includes the notified transaction code in the new data record. This starts management of the transaction performed using the user terminal 200 that requested the check-in. The processor 31 may also inquire of the store server 1 about the user code, and add the new data record to the transaction management database DBCA after user authentication. Thus, the processor 31 identifies the customer as a customer identified by the user code included in the request data and who will purchase the product. In other words, the processor 31 executes information processing based on the registration support application APC, and the computer having the processor 31 as the central part functions as an identification means.

[0061] When a request to start a transaction is received from the mobile controller 3, the processor 21 of the virtual POS server 2 starts information processing relating to the transaction (hereinafter referred to as transaction processing) in accordance with the virtual POS application APB. 19, 20 and 21 are flowcharts of transaction processing by the processor 21.

[0062] Processor 21 starts a transaction process each time a request to start a transaction is made. If a transaction process started based on another request is already being executed, processor 21 starts a new transaction process in parallel with the transaction process started based on another request. In other words, processor 21 may execute transaction processes for multiple transactions in parallel. In the following description, when simply referring to a "transaction," this refers to the transaction that is the subject of the transaction process being explained. As ACT301 in Fig. 19, the processor 21 executes a start process for starting processing for one transaction. The processor 21, for example, determines a new transaction code according to a predetermined rule so as not to overlap with transaction codes for identifying other transactions, and notifies the mobile controller 3 of the determined transaction code. The processor 21, for example, sets the transaction code determined as described above in the field FAA, and adds a new data record REB in which the user code included in the notification data is set in the field FAB to the transaction database DBBA.

[0063] The processor 31 of the mobile controller 3 performs the check-in process in ACT201 in Fig. 15 as described above, using the transaction code notified as described above from the virtual POS server 2. Then, when the processor 31 finishes the check-in process, it proceeds to ACT202. In ACT202, the processor 31 checks whether or not 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 judges the result as NO and proceeds to ACT203.

[0064] As ACT203, the processor 31 notifies the user terminal 200 of the error. For example, the processor 31 transmits notification data for notifying the error to the user terminal 200 via the in-store communication network 7 and the access point 6. The processor 31 includes identification data for identifying that the notification is an error notification in the notification data. The processor 31 may include an error code indicating the cause of the error in the notification data.

[0065] Various notifications from the mobile controller 3 to the user terminal 200 described below are realized by sending notification data including identification data for identifying the reason for the notification from the mobile controller 3 to the user terminal 200 via the in-store communication network 7 and the access point 6, as described above. Then, the processor 31 ends the assistance process.

[0066] On the other hand, if the check-in process is completed normally, the processor 31 judges YES in ACT202 and proceeds to ACT204. As ACT 204, the processor 31 notifies the user terminal 200 of the check-in completion.

[0067] After requesting check-in in ACT108 in FIG. 10, the processor 201 of the user terminal 200 proceeds to ACT109. In ACT109, the processor 201 checks whether or not the check-in completion has been notified. If the processor 201 cannot confirm the event, it judges "NO" and proceeds to ACT110. In ACT110, the processor 201 checks whether or not a check-in error has been notified. If the processor 201 cannot confirm the event, it determines NO and returns to ACT109. Thus, the processor 201 waits for a notification of check-in completion or an error in ACT109 and ACT110. Then, if the notification data for the error notification described above is received by the wireless communication unit 208, the processor 201 judges YES in ACT110 and proceeds to ACT111.

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

[0069] On the other hand, if the notification data for notifying the check-in completion is received by the wireless communication unit 208, the processor 201 judges YES in ACT 109 and proceeds to ACT 112 in FIG. As ACT 112, the processor 201 displays a list screen on the touch panel 204. The list screen is a screen showing a list of registered purchased products.

[0070] FIG. 22 is a diagram showing an example of the list screen SCA. The list screen SCA includes display areas ARAA, ARAB and buttons BUAA, BUAB, BUAC, and BUAD. The display area ARAA shows the total number of purchased items and the total price of the purchased items. The display area ARAB shows a list of the purchased items. The button BUAA is a soft key that allows the customer to specify that all purchased items should be cancelled and the shopping should be stopped. The button BUAB is a soft key that allows the customer to specify that a scan should be started for items to be registered as purchased items. The button BUAC is a soft key that allows the customer to specify that the checkout should be started. The button BUAD is a soft key that allows the customer to specify that a search should be started, which will be described later. 22 shows a state in which no purchased items have been registered yet. Therefore, the total number and the total amount are both shown as "0" in the display area ARAA, and nothing is shown in the display area ARAB.

[0071] 11, the processor 201 checks whether or not the start of scanning of the product has been specified. If the processor 201 cannot check the corresponding event, it determines NO and proceeds to ACT114. In ACT 114, the processor 201 checks whether or not the start of a search has been specified. If the processor 201 cannot check the relevant event, it judges the result as NO and proceeds to ACT 115. In ACT 115, the processor 201 checks whether or not a change in quantity has been specified. If the processor 201 cannot check the corresponding event, it determines NO and proceeds to ACT 116. In ACT 116, the processor 201 checks whether or not a shopping stop has been specified. If the processor 201 cannot check the corresponding event, it determines NO and proceeds to ACT 117. In ACT 117, the processor 201 checks whether the start of a transaction has been specified. If the processor 201 cannot check the corresponding event, it determines NO and proceeds to ACT 118. In ACT 118, the processor 201 checks whether or not a command to display the list screen has been issued. If the processor 201 cannot check the relevant event, it determines NO and returns to ACT 113. Thus, in ACT113 to ACT118, the processor 201 waits for any one of start of scan, start of search, quantity, stop, and start of accounting to be designated, or for an instruction to display a list screen to be given.

[0072] After notifying the check-in completion in ACT204 in FIG. 15, the processor 31 of the mobile controller 3 proceeds to ACT205. In ACT205, the processor 31 checks whether or not registration has been requested. If the processor 31 cannot check the relevant event, it judges the result as NO and proceeds to ACT206. In ACT 206, the processor 31 checks whether a search has been requested. If the processor 31 cannot check the relevant event, it judges the result as NO and proceeds to ACT 207. In ACT207, the processor 31 checks whether or not a quantity change has been requested. If the processor 31 cannot check the event, it judges the result as NO and proceeds to ACT208. In ACT208, the processor 31 checks whether or not a request to delete the purchased item has been made. If the processor 31 cannot check the relevant event, it determines that the result is NO, and proceeds to ACT209. In ACT209, the processor 31 checks whether or not a request to cancel the purchased item has been made. If the processor 31 cannot check the event, it determines that the result is NO and proceeds to ACT210. In ACT210, the processor 31 checks whether or not a transaction has been requested. If the processor 31 cannot check the relevant event, it determines NO and returns to ACT205. Thus, in ACT205 to ACT210, the processor 31 waits for any of the following to be requested: registration, search, quantity change, deletion, cancellation, or accounting.

[0073] If the customer wishes to register the product as a purchased product, the customer designates 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 201 judges YES in ACT113 in FIG. 11 and proceeds to ACT119. In ACT 119, the processor 201 displays a registration screen on the touch panel 204. 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.

[0074] FIG. 23 is a diagram showing an example of the registration screen SCB. The registration screen SCB includes a display area ARBA, a character string CSBA, and a button BUBA. The display area ARBA displays an image captured by the camera 205. The character string CSBA represents a text message that prompts the customer to read the barcode of the product. The button BUBA is a soft key that allows the customer to stop scanning the product code. The processor 201, for example, activates the camera 205, which then overlays an image obtained by the camera 205 with a line indicating the range of the display area ARBA, and an image showing the character string CSBA and the button BUBA, to generate the registration screen SCB.

[0075] In ACT120 in Fig. 11, the processor 201 checks whether the barcode has been read. At this time, the processor 201 analyzes the image obtained by the camera 205 and attempts to read the barcode. This barcode reading may be performed as a process based on the smartphone POS app APD, or may be performed as a process based on another application program for reading barcodes. If the barcode cannot be read, the processor 201 determines NO and proceeds to ACT121. In ACT121, the processor 201 checks whether or not the suspension of the scan has been specified. If the processor 201 cannot check the corresponding event, it determines NO and returns to ACT120. Thus, the processor 201 waits in ACT120 and ACT121 until the barcode is read or until a command to stop scanning is issued.

[0076] If the customer wishes to return to the display state of the list screen SCA without performing the current scan, the customer designates the cancellation of the scan by a predetermined operation such as touching the button BUBA. In response to this, the processor 201 judges YES in ACT121 and returns to ACT112. In this case, since the registration state of the purchased item is not changed, the processor 201 causes the touch panel 204 to display again the list screen SCA in the same state as that displayed before the deletion screen was displayed.

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

[0078] As described above, if a registration request is received from the user terminal 200, the processor 31 of the mobile controller 3 judges YES in ACT205 in FIG. As ACT 211, the processor 31 transfers the registration request together with notification of the transaction code to the virtual POS server 2. At this time, the processor 31 may add the transaction code to the request data sent from the user terminal 200 and transfer it to the virtual POS server 2, or may add the transaction code to the request data that has been converted by some process and send it to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the barcode data included in the request data sent from the user terminal 200.

[0079] After notifying the transaction code in ACT 301 in FIG. 19, the processor 21 of the virtual POS server 2 proceeds to ACT 302. In ACT 302, the processor 21 checks whether or not registration has been requested. If the processor 21 cannot check the relevant event, it determines NO and proceeds to ACT 303. In ACT 303, the processor 21 checks whether a search has been requested. If the processor 21 cannot check the relevant event, it judges the result as NO and proceeds to ACT 304. In ACT304, the processor 21 checks whether or not a quantity change has been requested. If the processor 21 cannot check the event, it determines that the result is NO and proceeds to ACT305. In ACT305, the processor 21 checks whether or not a request to delete a purchased item has been made. If the processor 21 cannot check the relevant event, it determines that the result is NO, and proceeds to ACT306. In ACT306, the processor 21 checks whether or not a request to cancel the purchased item has been made. If the processor 21 cannot check the event, it determines that the result is NO and proceeds to ACT307. In ACT 307, the processor 21 checks whether or not a transaction has been requested. If the processor 21 cannot check the relevant event, it determines NO and returns to ACT 302. Thus, in ACT302 to ACT307, the processor 31 waits for any of the following to be requested: registration, search, quantity change, deletion, cancellation, or accounting.

[0080] When the registration request is transferred from the mobile controller 3 as described above, the processor 21 judges YES in ACT302 and proceeds to ACT308. In ACT308, the processor 21 attempts to register the purchased item based on the barcode data included in the request data transferred from the mobile controller 3. That is, the processor 21 adds a new field to the end of the data record REB in which the above transaction code is set in the field FAA, and adds new item data. For example, the processor 21 sets the new item data to include the item code represented by the barcode data, the item name and price of the item identified by the item code, and the quantity "1", and sets the reservation flag to a state that does not indicate that the item is a purchased item by reservation (hereinafter referred to as a reserved item). Note that, for example, if the data record REB in which the above transaction code is set in the field FAA already contains item data including the item code represented by the barcode data, the processor 21 increases the quantity included in the item data by one. However, for some reason, the item code represented by the barcode data may not be registered in the item database. Also, a barcode other than the item code may be displayed on the item. In these cases, the processor 21 cannot register the purchased item and issues an error. As described above, the processor 21 determines the products based on the barcode data and registers the products as purchased products. The data record REB generated by such registration represents a list of purchased products. Thus, the processor 21 executes information processing based on the virtual POS application APB, and the computer with the processor 21 as its central part functions as a determination means and a creation means.

[0081] In ACT309, the processor 21 transmits result data indicating the result of the above-mentioned registration process to the mobile controller 3. If the registration of the purchased item is performed correctly, the processor 21 includes in the result data identification data for identifying that the notification is a valid registration, and the product code, product name, and price of the registered product. If an error occurs, 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. Then, the processor 21 returns to the standby state of ACT302 to ACT307.

[0082] After transferring the registration request in ACT211 in FIG. 15, the processor 31 of the mobile controller 3 proceeds to ACT212. The processor 31 as ACT 212 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.

[0083] The processor 31 updates the registration database DBCB based on the result data in ACT 213. This updating of the registration database DBCB is performed, for example, as follows. First case: The notification is for a formal registration and the data record REC 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 existing in data record REC 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", a reservation flag set to "0" indicating no reservation, 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 7.

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

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

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

[0087] By updating the registration database DBCB by the processor 31 in this manner, the registration database DBCB not only shows a list of purchased items already registered in the virtual POS server 2, but also records barcode reading errors.

[0088] 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, include the stored barcode data in the registration data. In this case, the processor 21 of 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, etc., based on the product code.

[0089] As ACT214, the processor 31 instructs the user terminal 200 to display a list screen. For example, the processor 31 transmits instruction data including identification data for identifying that this is an instruction to display a list screen to the user terminal 200 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity contained in the data record REC associated in the registration database DBCB with the transaction being processed. After that, the processor 31 returns to the standby state of ACT205 to ACT210.

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

[0091] After requesting registration in ACT122 in FIG. 11, the processor 201 of the user terminal 200 proceeds to ACT123. In ACT123, the processor 201 waits for an instruction to display the list screen. Then, if an instruction to display the list screen is given from the mobile controller 3 as described above, the processor 201 judges YES and returns to ACT112, where it again displays the list screen SCA on the touch panel 204. At this time, the processor 201 sets the list screen SCA to a screen showing the product name, price, and quantity of the purchased product included in the instruction data. Therefore, the customer can register the products as purchased products by repeatedly instructing the user terminal 200 to start scanning and sequentially reading the bar codes of the products to be registered.

[0092] FIG. 24 is a diagram showing an example of the list screen SCA in a state where a purchased item has already been registered. The list screen SCA shown in Fig. 24 is an example of a case where the following items have been registered as purchased: one item with the product name "AAA" and a price of 120 yen, two items with the product name "BBB" and a price of 98 yen, and one item with the product name "CCC" and a price of 1,024 yen. In the list screen SCA shown in Fig. 24, the display area ARAB shows the product names, prices, and quantities of these registered items. The display area ARAA also shows "4" as the total number and "1,340" as the total amount.

[0093] If the customer is unable to find the product he or she wishes to purchase and would like to receive information about the product, the customer designates the start of a search by a predetermined operation such as touching a button BUAD on the list screen.

[0094] If the start of a search is specified in this way, the processor 201 of the user terminal 200 judges YES in ACT 114 in FIG. 11, and proceeds to ACT 124 in FIG. As ACT 124 , the processor 201 causes the touch panel 204 to display a search screen. The search screen is a GUI screen that enables a customer to specify product search conditions, such as product name. In ACT 125, the processor 201 waits for search conditions to be specified. When the customer specifies search conditions on the search screen, the processor 201 judges YES and proceeds to ACT 126. As ACT 126, the processor 201 requests a search to the mobile controller 3. The processor 201 includes condition data indicating the specified condition in the request data transmitted here.

[0095] As described above, if a search request is received from the user terminal 200, the processor 31 of the mobile controller 3 judges YES in ACT 206 in FIG. 15, and proceeds to ACT 215 in FIG. As ACT 215, the processor 31 transfers the search request to the virtual POS server 2. At this time, the processor 31 may transfer the request data sent from the user terminal 200 to the virtual POS server 2 as is, or may transmit the request data converted by some process to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the condition data included in the request data sent from the user terminal 200.

[0096] When the search request is transferred from the mobile controller 3 as described above, the processor 21 of the virtual POS server 2 judges YES in ACT 303 in FIG. 19, and proceeds to ACT 310 in FIG. As ACT 310, the processor 21 searches the product databases included in the database group DBAA for products that match the conditions represented by the condition data included in the request data. As ACT311, the processor 21 instructs the mobile controller 3 to display a result screen. For example, the processor 21 transmits instruction data including identification data for identifying that the instruction is to display a result screen to the user terminal 200 via the in-store communication network 7 and the access point 6. The processor 21 generates a result screen showing the results of the search in ACT310, and includes screen data showing this result screen in the instruction data. Note that the contents of the result screen may be appropriately determined by, for example, the creator of the virtual POS application APB or the administrator of the virtual POS server 2. It is assumed that the result screen is, for example, a screen showing a list of products found by the search.

[0097] After transferring the search request in ACT215 in FIG. 16, the processor 31 of the mobile controller 3 proceeds to ACT216. In ACT 216, the processor 31 checks whether or not a screen display has been requested. If the processor 31 cannot check the event, it judges the result as NO and proceeds to ACT 217. In ACT217, the processor 31 checks whether or not guidance has been requested. If the processor 31 cannot check the relevant event, it judges the result as NO and proceeds to ACT218. In ACT218, the processor 31 checks whether the end of the search has been notified. If the processor 31 cannot check the event, it judges the result as NO and proceeds to ACT219. In ACT219, the processor 31 checks whether or not a reservation registration has been requested. If the processor 31 cannot check the relevant event, it judges the result as NO and returns to ACT216. Thus, the processor 31 waits for a screen display instruction, a search end notification, or reservation registration in ACT216 to ACT219. If a request to display the result screen is made as described above, the processor 31 judges YES in ACT216 and proceeds to ACT220.

[0098] In ACT220, the processor 31 transfers an instruction to display a result screen to the user terminal 200 being used for the transaction identified by the transaction code included in the instruction data. For example, the processor 31 finds a data record including the transaction code included in the instruction data from the transaction management database DBCA, and transfers the instruction data to the user terminal 200 identified by the terminal code included in the data record. At this time, the processor 31 may transfer the instruction data sent from the virtual POS server 2 to the user terminal 200 as is, or may send the instruction data converted by some processing to the user terminal 200. However, the processor 31 sends the screen data included in the instruction data sent from the virtual POS server 2 to the user terminal 200. Then, the processor 31 returns to the standby state of ACT216 to ACT219.

[0099] After the processor 201 in the user terminal 200 issues a search request in ACT 126 in FIG. In ACT 127, the processor 201 waits for an instruction to display a result screen. If an instruction to display a result screen is transferred from the mobile controller 3 as described above, the processor 201 determines that the result is YES, and proceeds to ACT 128. As ACT128, the processor 201 causes the touch panel 204 to display a result screen represented by the screen data included in the instruction data. In ACT 129, the processor 201 waits for a product to be specified.

[0100] If the customer finds that the product he or she wants is included in the list of products shown on the result screen displayed on the touch panel 204, the customer designates the product, for example, by a predetermined operation on the touch panel 204. Then, if the product is designated in this way, the processor 201 judges YES in ACT129 and proceeds to ACT130. As ACT130, the processor 201 requests information on the specified product from the mobile controller 3. The processor 201 includes the product code of the specified product in the request data transmitted here.

[0101] As described above, if a guide request is received from the user terminal 200, the processor 31 of the mobile controller 3 judges YES in ACT217 in FIG. 16, and proceeds to ACT221. In ACT221, the processor 31 transfers the guide request to the virtual POS server 2. That is, the processor 31 transfers, for example, the request data sent from the user terminal 200 for the guide request to the virtual POS server 2. Then, the processor 31 thereafter returns to the standby state of ACT216 to ACT219.

[0102] After the processor 21 of the virtual POS server 2 has finished issuing an instruction to display the result screen in ACT 311 in FIG. 20, the process proceeds to ACT 312. The processor 21 waits for a guide request in ACT 312. If the guide request has been transferred from the mobile controller 3 as described above, the processor 21 determines that the answer is YES and proceeds to ACT 313. In ACT313, the processor 21 checks whether or not the product identified by the product code included in the request data for requesting the guide is in stock. For example, the processor 21 obtains from the store server 1 stock information described in the stock database DBAB in association with the above-mentioned product code, and judges whether or not the product is in stock based on this stock information. If the product is in stock, the processor 21 judges YES and proceeds to ACT314. As ACT314, the processor 21 instructs the mobile controller 3 to display a guidance screen. For example, the processor 21 transmits instruction data including identification data for identifying that the instruction is to display a guidance screen to the user terminal 200 via the in-store communication network 7 and the access point 6. The processor 21 generates a guidance screen as a screen for informing the customer of the display location of the product designated as the target of the guidance, and includes screen data representing this guidance screen in the instruction data. Note that the contents of the guidance screen may be appropriately determined, for example, by the creator of the virtual POS application APB or the administrator of the virtual POS server 2. It is assumed that the guidance screen is, for example, a screen representing an in-store map showing the display locations.

[0103] On the other hand, if the product is out of stock, the processor 21 determines NO in ACT313 and proceeds to ACT316. As ACT316, the processor 21 instructs the mobile controller 3 to display a stock-out screen. For example, the processor 21 transmits instruction data including identification data for identifying that the instruction is to display a stock-out screen to the mobile controller 3 via the in-store communication network 7. The processor 21 generates a stock-out screen as a screen for informing the customer that the product designated as the target of the guidance is out of stock, and includes screen data representing this stock-out screen in the instruction data. Note that the contents of the stock-out screen may be appropriately determined by, for example, the creator of the virtual POS application APB or the administrator of the virtual POS server 2.

[0104] As described above, if a request has been made to display the guide screen or out-of-stock screen, the processor 31 of the mobile controller 3 judges YES in ACT216 in FIG. 16 and proceeds to ACT220. In ACT220, the processor 31 transfers an instruction to display a guide screen or a stockout screen to the user terminal 200 being used for the transaction identified by the transaction code included in the instruction data. Then, the processor 31 returns to the standby state of ACT216 to ACT219.

[0105] After the processor 201 in the user terminal 200 requests guidance in ACT130 in FIG. In ACT 131, the processor 201 checks whether or not a command to display a guide screen has been issued. If the processor 201 cannot check the relevant event, it determines NO and proceeds to ACT 132. In ACT132, the processor 201 checks whether or not a command to display a stock-out screen has been issued. If the processor 201 cannot check the event, it determines that the result is NO, and returns to ACT131. Thus, in ACT131 and ACT132, the processor 201 waits for an instruction to display a guide screen or a stock-out screen.

[0106] If the instruction data instructing to display the guide screen is transferred from the mobile controller 3 as described above, the processor 201 judges YES in ACT131 and proceeds to ACT133. As ACT 133, the processor 201 causes the touch panel 204 to display a guide screen represented by the screen data included in the instruction data. The processor 201 waits for an end instruction as ACT 134. At this time, the processor 201 keeps the guide screen displayed on the touch panel 204.

[0107] On the other hand, if the instruction data instructing to display the out-of-stock screen is transferred from the mobile controller 3 as described above, the processor 201 determines YES in ACT132 and proceeds to ACT135. As ACT 135, the processor 201 causes the touch panel 204 to display a stock-out screen represented by the screen data included in the instruction data.

[0108] FIG. 25 is a diagram showing an example of the stock-out screen SCC displayed by the user terminal 200. The out-of-stock screen SCC includes the strings CSCA, CSCB, CSCC and buttons BUCA and BUCB. The string CSCA represents a text message indicating that the product designated as the subject of the announcement is out of stock. The string CSCB represents the name of the product designated as the subject of the announcement. The string CSCC represents the unit price of the product designated as the subject of the announcement. The button BUCA is a soft key that allows the customer to specify that the designated product should be reserved. The button BUCB is a soft key that allows the customer to specify that the product confirmation process using the search function should be terminated. The out-of-stock screen SCC shown in FIG. 25 is an example in which information about a product named "DDD" whose unit price is "360 yen" is requested.

[0109] In ACT 136, the processor 201 checks whether or not an end instruction has been issued. If the processor 201 cannot check the event, it judges "NO" and proceeds to ACT 137. In ACT 137, the processor 201 checks whether or not a reservation instruction has been issued. If the processor 201 cannot check the event, it determines NO and returns to ACT 136. Thus, the processor 201 waits for an end instruction or a reservation instruction in ACT 136 and ACT 137. In this standby state, the processor 201 keeps the out-of-stock screen displayed on the touch panel 204.

[0110] The customer can check the guide screen displayed on the touch panel 204 and learn the display location of the desired product, etc. Then, when the customer has finished using the guide screen, he / she instructs the end by performing a predetermined operation, such as touching a button provided on the guide screen. In this case, the processor 201 judges YES in ACT134 and proceeds to ACT138. Furthermore, the customer can check the out-of-stock screen displayed on the touch panel 204 and know that the desired product is out of stock. If the customer decides not to purchase the product that is notified as being out of stock on the out-of-stock screen, the customer instructs to end the process by performing a predetermined operation, such as touching the button BUCB. In this case, the processor 201 judges YES in ACT136 and proceeds to ACT138. As ACT138, the processor 201 notifies the mobile controller 3 of the end. For example, the processor 201 transmits notification data for the end notification to the mobile controller 3 via the access point 6 and the in-store communication network 7. The processor 31 includes identification data for identifying that this is a notification of the end in the notification data.

[0111] If the customer decides to pre-order a product that is notified to be out of stock on the out-of-stock screen, the customer instructs the reservation by a predetermined operation such as touching the button BUCA. In this case, the processor 201 judges YES in ACT137 and proceeds to ACT139. In ACT 139, the processor 201 requests reservation registration to the mobile controller 3. The processor 201 transmits, for example, request data to the mobile controller 3, which includes identification data for identifying that the request is for reservation registration.

[0112] If an end notification is received from the user terminal 200 as described above, the processor 31 of the mobile controller 3 judges YES in ACT218 in FIG. 16, and proceeds to ACT222. As ACT 222, the processor 31 transfers the end notification to the virtual POS server 2. That is, the processor 31 transfers, for example, the notification data sent from the user terminal 200 as the end notification to the virtual POS server 2.

[0113] If a reservation registration is requested from the user terminal 200 as described above, the processor 31 judges YES in ACT219 and proceeds to ACT223. As ACT223, the processor 31 transfers the request data sent for the above reservation registration request to the virtual POS server 2, along with notification of the transaction code associated with the terminal code of the user terminal 200 in the data record of the transaction management database DBCA.

[0114] After issuing an instruction to display the guide screen in ACT 314 in FIG. 20, the processor 21 of the virtual POS server 2 proceeds to ACT 315. As ACT315, the processor 21 waits for an end instruction. Furthermore, after issuing an instruction to display the out-of-stock screen in ACT316, the processor 21 proceeds to ACT317. In ACT 317, the processor 21 checks whether or not an end instruction has been issued. If the processor 21 cannot check the event, it judges that the answer is NO and proceeds to ACT 318. In ACT 318, the processor 21 checks whether or not a reservation registration has been requested. If the processor 21 cannot check the relevant event, it judges the result as NO and returns to ACT 317. Thus, the processor 21 waits for an end instruction or a reservation registration request in ACT317 and ACT318.

[0115] If the end notification is transferred from the mobile controller 3 as described above, the processor 21 determines YES in ACT 315 or ACT 317, and returns to the standby state of ACT 302 to ACT 307 in FIG. On the other hand, if a reservation registration request is transferred from the mobile controller 3 as described above, the processor 21 judges YES in ACT318 and proceeds to ACT319. In ACT319, the processor 21 registers the reserved product. For example, if the data record REB in which the transaction code notified together with the request data for the reservation registration request is set in the field FAA is not included in the transaction database DBBA, the processor 21 sets the transaction code in the field FAA and adds a new data record REB in which the new product data is set in the field FAC to the transaction database. Also, for example, if the data record REB in which the transaction code is set in the field FAA is already included in the transaction database DBBA, the processor 21 adds a new field to the end of the data record REB and adds new product data. For example, the processor 21 adds the new product data to include the product code included in the request data for the information request, the product name and price of the product identified by the product code, and the quantity "1" in the new product data to be added, and sets the reservation flag to a state indicating that the product is a reserved product.

[0116] As described above, the processor 21 determines the product determined in accordance with the customer's designation as a reserved product, and registers the reserved product as one of the purchased products. Thus, the processor 21 executes information processing based on the virtual POS application APB, and the computer having the processor 21 as its central part functions as a determination means, creation means, and determination means. Furthermore, the function of the processor 21 as creation means is such that, if a product designated by a customer as a guide target is out of stock, the above product is included as a reserved product in the list represented by the data record REB only when a reservation is designated on the user terminal 200. As ACT320, the processor 21 transmits result data indicating the result of the process for the reservation registration to the mobile controller 3. The processor 21 includes in the result data identification data for identifying that the notification is a valid registration notification, and the product code, product name, price, quantity, and reservation flag of the registered product. Then, the processor 21 returns to the standby state of ACT302 to ACT307 in FIG. 19.

[0117] After transferring the reservation registration request in ACT223 in FIG. 16, the processor 31 of the mobile controller 3 proceeds to ACT224. The processor 31 as ACT 224 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.

[0118] In ACT225, processor 31 updates registration database DBCB based on the result data. For example, processor 31 adds a new field next to the last field already present in data record REC associated with the transaction being processed, and adds new registration data to that field. Processor 31 includes in the new registration data the product code included in the result data, an error flag set to "0" indicating no error, the product name, price, and quantity included in the result data, a reservation flag set to a state indicating a reservation, and a cancellation flag set to "0" indicating no cancellation.

[0119] Upon completing ACT225, the processor 31 proceeds to ACT226. If the processor 31 has transferred an end notification in ACT222, the processor 31 also proceeds to ACT226. In ACT226, the processor 31 instructs the user terminal 200 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 200 via the in-store communication network 7 and the access point 6. The processor 31 includes in the instruction data the product code, product name, price, and quantity included in the data record REC associated in the registration database DBCB with the transaction being processed. Then, the processor 31 returns to the standby state of ACT205 to ACT210 in FIG. 15.

[0120] After the processor 201 of the user terminal 200 issues a termination notification in ACT 138 in FIG. 12, or after requesting reservation registration in ACT 139, the processor 201 proceeds to ACT 140. In ACT 140, the processor 201 waits for an instruction to display the list screen. Then, for example, when an instruction to display the list screen is received from the mobile controller 3 as described above, the processor 201 judges YES and returns to ACT 112 in FIG. 11, and causes the list screen SCA to be displayed on the touch panel 204 again.

[0121] FIG. 26 is a diagram showing an example of the list screen SCA in a state where purchase items including reserved items have already been registered. The list screen SCA shown in FIG. 26 is an example of a case where one product with the product name "AAA" and a price of 120 yen, two products with the product name "BBB" and a price of 98 yen, and one product with the product name "CCC" and a price of 1,024 yen have been registered as purchased products that are not reserved products. The list screen SCA shown in FIG. 26 is also an example of a case where one product with the product name "DDD" and a price of 360 yen has been registered as a reserved product. In the list screen SCA shown in FIG. 26, the display area ARAB shows the product name, price, and quantity of these registered products. The display area ARAA shows the total number "5" and the total amount "1,700". The icon ICAA shows that the product with the product name "DDD" is a reserved product.

[0122] When the customer touches an area on the list screen SCA that shows the quantity, the processor 201 displays a list box for specifying the quantity overlaid on the list screen SCA. When this list box is operated, the processor 201 receives this as a specification of the quantity. In this case, the processor 201 judges YES in ACT115 in FIG. 11 and proceeds to ACT141 in FIG. 13. In ACT141, the processor 201 checks whether the designated number is 0. If the designated number is not 0, the processor 201 determines NO and proceeds to ACT142.

[0123] As ACT142, the processor 201 requests the mobile controller 3 to change the quantity. The request data sent by the processor 201 here includes specific data for identifying the product whose quantity is specified and the specified number. The specific data may be a product code, or may be data that can identify the purchased product only on the mobile controller 3, such as a number for identifying each purchased product in the 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 the list screen.

[0124] If a quantity change is requested from the user terminal 200 as described above, the processor 31 of the mobile controller 3 judges YES in ACT 207 in FIG. 15, and proceeds to ACT 227 in FIG. As ACT227, the processor 31 transfers the quantity change request together with notification of the transaction code to the virtual POS server 2. At this time, the processor 31 may add the transaction code to the request data sent from the user terminal 200 and transfer it to the virtual POS server 2, or may add the transaction code to the request data converted by some process and send it to the virtual POS server 2. However, the processor 31 notifies the virtual POS server 2 of the quantity included in the request data sent from the user terminal 200. Furthermore, if the specific data included in the request data is not a product code, the processor 31 replaces the specific data with the product code.

[0125] When the request for changing the quantity is transferred from the mobile controller 3, the processor 21 of the virtual POS server 2 judges that the result is YES in ACT304 in FIG. 19, and proceeds to ACT321. As ACT321, the processor 21 assumes that the quantity included in the request data sent from the mobile controller 3 was entered by an input device provided in the existing POS terminal, and updates the transaction database DBBA to change the quantity of the purchased item by processing similar to that of the existing POS terminal. In ACT322, the processor 21 transmits result data indicating the product code of the product whose quantity has been changed and the changed quantity to the mobile controller 3. Then, the processor 21 thereafter returns to the standby state of ACT302 to ACT307.

[0126] After transferring the quantity change request in ACT227 in FIG. 17, the processor 31 of the mobile controller 3 proceeds to ACT228. As ACT 228, 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. In ACT229, the processor 31 updates the registration database DBCB based on the result data. That is, the processor 31 finds the registration data including the notified product code from the associated data record REC. Then, the processor 31 rewrites the quantity included in the corresponding registration data to the quantity included in the result data. 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 the registered data related to the product specified by the stored specific data to the stored quantity. In this case, the processor 21 of the virtual POS server 2 does not need to include the product code and quantity in the result data.

[0127] In ACT230, the processor 31 instructs the user terminal 200 to display a list screen. The processor 31 includes in the instruction data the product code, product name, price, and quantity included in the registration data whose cancellation flag is "0" among the registration data included in the data record REC updated as described above. The processor 31 then returns to the standby state of ACT205 to ACT210 in FIG.

[0128] Now, if the designated number for changing the quantity is 0, the processor 201 of the user terminal 200 judges YES in ACT141 of FIG. 13 and proceeds to ACT143. As ACT143, the processor 201 displays a delete screen on the touch panel 204. The delete screen is a screen that notifies the customer that the product for which the quantity is specified to be set to 0 will be deleted from the purchased products. The delete screen includes a delete button for specifying the deletion, and a back button for specifying returning to the state before the quantity change was specified without changing the quantity.

[0129] In ACT 144, the processor 201 checks whether or not deletion has been specified. If the processor 201 cannot check the event, it determines NO and proceeds to ACT 145. In ACT 145, the processor 201 checks whether or not a return has been specified. If the processor 201 cannot check the relevant event, it determines NO and returns to ACT 144. Thus, the processor 201 waits for a delete or return to be specified as ACT 144 and ACT 145 .

[0130] If the customer wishes to cancel the deletion and return to the state before the quantity change was specified, the customer specifies "back" by a predetermined operation such as touching the back button on the deletion screen. In response to this, the processor 201 judges YES in ACT145, returns to ACT112 in Fig. 11, and causes the list screen SCA to be displayed again on the touch panel 204. In this case, since the registration state of the purchased product is not changed, the processor 201 causes the touch panel 204 to display again the list screen SCA in the same state as that displayed before the deletion screen was displayed.

[0131] If the customer is sure to delete the content, he or she designates the deletion by a predetermined operation such as touching the delete button on the delete screen. In response to this, the processor 201 judges YES in ACT144 and proceeds to ACT146. In ACT 146, the processor 201 requests the mobile controller 3 to delete the product. The request data transmitted by the processor 201 includes specification data for specifying the product designated for deletion.

[0132] If a deletion request is received from the user terminal 200 as described above, the processor 31 of the mobile controller 3 judges YES in ACT 208 in FIG. 15, and proceeds to ACT 231 in FIG. As ACT 231, the processor 31 transfers the deletion request together with the notification of the transaction code to the virtual POS server 2. At this time, the processor 31 may add the transaction code to the request data sent from the user terminal 200 and transfer it to the virtual POS server 2, or may add the transaction code to the request data converted by some process and send it to the virtual POS server 2. However, 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.

[0133] When the processor 21 of the virtual POS server 2 receives the deletion request from the mobile controller 3, the processor 21 judges YES in ACT305 in FIG. 19 and proceeds to ACT323. As ACT323, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a deletion instruction inputted by an input device provided on the existing POS terminal, and updates the transaction database DBBA to exclude the target item from the purchased items by processing similar to that of the existing POS terminal. In ACT324, the processor 21 transmits result data indicating the product codes of the products excluded from the purchased products to the mobile controller 3. Then, the processor 21 thereafter returns to the standby state of ACT302 to ACT307.

[0134] After transferring the deletion request in ACT231 in FIG. 17, the processor 31 of the mobile controller 3 proceeds to ACT232. The processor 31 as the ACT 232 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.

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

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

[0137] In ACT234, the processor 31 instructs the user terminal 200 to display a list screen. The processor 31 includes in the instruction data the product code, product name, price, and quantity included in the registration data whose cancellation flag is "0" among the registration data included in the data record REC updated as described above. The processor 31 then returns to the standby state of ACT205 to ACT210 in FIG.

[0138] Now, after the processor 201 of the user terminal 200 requests a quantity change in ACT 142 in FIG. 13, or after requesting a deletion in ACT 146, the processor 201 of the user terminal 200 proceeds to ACT 147. In ACT147, the processor 201 waits for an instruction to display the list screen. If an instruction to display the list screen is given from the mobile controller 3 in response to a request to change the quantity or a request to delete, the processor 201 judges the result to be YES, returns to ACT112 in Fig. 11, and causes the touch panel 204 to display the list screen SCA again. At this time, the processor 201 sets the list screen SCA to a screen showing the product name, price, and quantity of the purchased product included in the instruction data. In this case, since the registration status of the purchased product is changed, the processor 201 causes the touch panel 204 to display the list screen SCA in a state different from that displayed when the quantity change or deletion was specified.

[0139] If the customer wishes to cancel all the registered purchased items and to stop shopping, the customer designates the cancellation by a predetermined operation such as touching the button BUAA on the list screen SCA. In response to this, the processor 201 judges YES in ACT116 in FIG. 11 and proceeds to ACT148 in FIG. As ACT148, the processor 201 displays a cancel screen on the touch panel 204. The cancel screen is a screen that notifies the customer that all of the purchased items that have already been registered will be canceled. The cancel screen includes an execute button for specifying execution of the cancel, and a back button for specifying returning to the state before the quantity change was specified without changing the quantity.

[0140] In ACT 149, the processor 201 checks whether or not cancellation execution has been specified. If the processor 201 cannot check the corresponding event, it determines NO and proceeds to ACT 150. In ACT 150, the processor 201 checks whether or not a return has been specified. If the processor 201 cannot check the relevant event, it determines NO and returns to ACT 149. Thus, the processor 201 waits for a cancellation or return to be specified as ACT 149 and ACT 150 .

[0141] If the customer wishes to continue shopping, the customer specifies "back" by a predetermined operation such as touching a back button on the cancellation screen. In response to this, the processor 201 judges YES in ACT150, returns to ACT112 in Fig. 11, and causes the list screen SCA to be displayed again on the touch panel 204. In this case, since the registration status of the purchased item is not changed, the processor 201 causes the touch panel 204 to display again the list screen SCA in the same state as that displayed before the cancellation screen was displayed.

[0142] If the customer wishes to cancel the purchase, he or she designates cancellation execution by a predetermined operation such as touching an execution button on the cancellation screen. In response to this, the processor 201 judges YES in ACT149 and proceeds to ACT151. In ACT 151, the processor 201 requests the mobile controller 3 to cancel.

[0143] If a cancellation request is received from the user terminal 200 as described above, the processor 31 of the mobile controller 3 judges YES in ACT 209 in FIG. 15, and proceeds to ACT 235 in FIG. As ACT 235, the processor 31 transfers the cancellation request together with the notification of the transaction code to the virtual POS server 2. At this time, the processor 31 may add the transaction code to the request data sent from the user terminal 200 and transfer it to the virtual POS server 2, or may add the transaction code to the request data that has been converted by some processing and send it to the virtual POS server 2.

[0144] When the processor 21 of the virtual POS server 2 receives the cancellation request from the mobile controller 3, the processor 21 judges YES in ACT306 in FIG. 19 and proceeds to ACT325. As ACT325, the processor 21 regards the request based on the request data sent from the mobile controller 3 as a cancellation instruction entered by an input device provided on the existing POS terminal, and updates the transaction database DBBA to exclude all registered items associated with the notified transaction code from the purchased items by processing similar to that of the existing POS terminal. In ACT326, the processor 21 transmits result data indicating that the cancellation has been completed to the mobile controller 3. Then, the processor 21 thereafter returns to the standby state of ACT302 to ACT307.

[0145] After transferring the deletion request in ACT235 in FIG. 17, the processor 31 of the mobile controller 3 proceeds to ACT236. The processor 31 as ACT 236 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.

[0146] In ACT 237, the processor 31 updates the registration database DBCB based on the result data described above. 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 REC associated with the transaction being processed. In ACT238, the processor 31 notifies the user terminal 200 of the cancellation. Then, the processor 31 thereafter returns to the standby state of ACT205 to ACT210 in FIG.

[0147] After the processor 201 of the user terminal 200 requests cancellation in ACT151 in FIG. In ACT152, the processor 201 waits for a cancellation notification from the mobile controller 3. Then, the processor 201 determines YES if a cancellation notification is received as described above, and returns to ACT101 in FIG.

[0148] When the customer has finished registering all the products he / she wishes to purchase as purchased products or reserved products, he / she proceeds to payment. At this time, the customer specifies the start of the transaction by a predetermined operation such as touching a button BUAC on the list screen SCA. In response to this, the processor 201 judges YES in ACT117 in FIG. 11 and proceeds to ACT153 in FIG. 14. In ACT 153, the processor 201 requests accounting from the mobile controller 3.

[0149] If a payment request is received from the user terminal 200 as described above, the processor 31 of the mobile controller 3 judges YES in ACT 210 in FIG. 15, and proceeds to ACT 239 in FIG. In ACT 239, the processor 31 instructs the user terminal 200 to display an accounting screen.

[0150] After the processor 201 of the user terminal 200 requests payment in ACT 153 in FIG. In ACT 154, the processor 201 waits for an instruction to display the accounting screen. If the processor 201 confirms that an instruction to display the accounting screen has been issued as described above, the processor 201 judges YES in ACT 154 and proceeds to ACT 155.

[0151] As ACT 155, the processor 201 displays an accounting screen on the touch panel 204. The accounting screen is a screen that allows the customer to select whether to use the user terminal 200 or the accounting machine 5 to perform an operation for settling the price. When a customer wishes to perform an operation for payment at user terminal 200, the customer specifies user terminal 200 by a predetermined operation. When a customer wishes to perform an operation for payment at payment machine 5, the customer specifies payment machine 5 by a predetermined operation.

[0152] In ACT156, the processor 201 checks whether or not the user terminal 200 has been designated. If the processor 201 cannot check the event, it judges "NO" and proceeds to ACT157. In ACT157, the processor 201 checks whether or not the payment machine 5 has been designated. If the processor 201 cannot check this event, it determines "NO" and returns to ACT156. Thus, the processor 201 waits for the user terminal 200 or the payment machine 5 to be designated in ACT156 and ACT157. If the user terminal 200 is designated as described above, the processor 201 judges YES in ACT156 and proceeds to ACT158.

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

[0154] Furthermore, if the payment machine 5 is specified as described above, the processor 201 judges YES in ACT157 and proceeds to ACT159. As ACT 159, the processor 201 displays a transaction barcode screen on the touch panel 204. The transaction barcode screen is a screen that displays a transaction barcode that represents data required for the transaction machine 5 to obtain data related to the details of the transaction (hereinafter referred to as transaction data) from the virtual POS server 2. Note that although detailed processing is not shown in the figure, the processor 201 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.

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

[0156] After issuing an instruction to display the accounting screen in ACT239 in FIG. 18, the processor 31 of the mobile controller 3 proceeds to ACT240. In ACT240, the processor 31 checks whether or not a payment has been requested. If the processor 31 cannot check this event, it determines NO and proceeds to ACT241. In ACT241, the processor 31 checks whether or not the completion of the settlement has been notified. If the processor 31 cannot check the event, it judges the result as NO and returns to ACT240. Thus, the processor 31 waits for a billing request or a settlement completion notice in ACT240 and ACT241. Then, if a billing request is received from the user terminal 200 as described above, the processor 31 judges YES in ACT240 and proceeds to ACT242.

[0157] As ACT 242, the processor 31 transfers the transaction request, together with notification of the transaction code of the transaction being processed, to the virtual POS server 2. At this time, the processor 31 may transfer the request data sent from the user terminal 200 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.

[0158] When the transaction request is transferred from the mobile controller 3, the processor 21 of the virtual POS server 2 judges that the result is YES in ACT 307 in FIG. 19, and proceeds to ACT 327 in FIG. As ACT327, the processor 21 regards the request by the request data sent from the mobile controller 3 as an accounting instruction input by an input device provided in the existing POS terminal, calculates the price for the transaction identified by the notified transaction code by the same process as the existing POS terminal, and performs processing to settle the price based on the settlement data. That is, the processor 21 searches the transaction database DBBA for a data record REB in which the notified transaction code is set in the field FAA, and calculates the price based on the product data included in the corresponding data record REB. At this time, the processor 21 considers all product data regardless of the state of the reservation flag included in each product data. That is, the processor 21 also considers products registered as reserved products as the subject of settlement. The process for settlement includes, for example, a settlement request to a settlement server not shown. Thus, the processor 21 executes information processing based on the virtual POS application APB, and the computer with the processor 21 as its central part functions as a payment means.

[0159] In ACT328, the processor 21 checks whether or not there is a reserved item among the items that are the subject of the transaction for which payment has been completed as described above. For example, if the reservation flag of any of the item data included in the data record REB found in ACT327 indicates a reservation, the processor 21 determines that there is a reserved item and judges the result to be YES, and proceeds to ACT329. In ACT 329, the processor 21 notifies the shop server 1 of the new reservation. For example, the processor 21 transmits notification data for the reservation notification to the store server 1 via the in-store communication network 7. The processor 21 includes in the notification data identification data for identifying it as a reservation notification, the user code set in the field FAB of the data record REB found in ACT327, and a set of the product code and quantity for the newly registered reserved product.

[0160] The processor 11 of the store server 1 executes information processing for managing the inventory status of products in a store (hereinafter, referred to as inventory management processing) based on the store management application APA. FIG. 27 is a flowchart of the inventory management process by the processor 11. In ACT 401, the processor 11 checks whether or not a reservation notice has been issued. If the processor 11 cannot check the relevant event, it judges the result as NO and proceeds to ACT 402. In ACT402, the processor 11 checks whether or not sales data has been received. If the processor 11 cannot check the event, it determines NO and proceeds to ACT403. In ACT403, the processor 11 checks whether or not a receiving instruction has been issued. If the processor 11 cannot check the event, it determines NO and returns to ACT401. Thus, the processor 11, as ACT401 to ACT403, waits for a reservation notice to be made, for sales data to be received, or for an arrival instruction to be made.

[0161] When the notification data transmitted for reservation notification from the virtual POS server 2 is received by the communication interface 14 as described above, the processor 11 judges YES in ACT401 and proceeds to ACT404. As ACT404, the processor 11 updates the reservation database DBAC to add a new data record REA related to the reserved product that is the subject of the transaction for which the payment has been completed as described above. For example, the processor 11 sets a reservation code different from the one set in the field FBA of the other data records REA in the field FBA of the new data record REA. For example, the processor 11 sets a user code included in the notification data in the field FBB of the new data record REA. For example, the processor 11 sets each of the pairs of product code and quantity included in the notification data in the fields FBC and FBD of the new data record REA. For example, the processor 11 sets the date and time measured by a software timer realized as a separate process in the field FBE of the new data record REA. Note that the processor 11 may set the date and time measured by a hardware timer provided in the virtual POS server 2 in the field FBE of the new data record REA. For example, the processor 11 sets a notification flag indicating that the arrival notification has not been completed in the field FBF of the new data record REA. Thereafter, the processor 11 returns to the standby state of ACT401 to ACT403. By adding the data record REA to the reservation database DBAC as described above, the processor 11 manages the reserved items in association with the customers. In this way, the processor 11 executes information processing based on the store management application APA, and the computer with the processor 11 as its central part functions as a management means.

[0162] After completing ACT329 in Fig. 21, the processor 21 of the virtual POS server 2 proceeds to ACT330. If the reservation flags included in all the product data included in the data record REB found in ACT327 indicate that none of the products are reserved, the processor 21 determines NO in ACT328 as there are no reserved products. In this case, the processor 21 skips ACT329 and proceeds to ACT330. As ACT330, the processor 21 transmits to the mobile controller 3 result data indicating that the payment has been completed. As ACT331, the processor 21 transmits sales data to the store server 1. The sales data is data that allows the store server 1 to grasp the products that will be delivered to the customer in a transaction where payment has been completed as described above. In other words, the sales data includes a set of product code and quantity for each purchased product other than reserved products. The sales data may be common to so-called transaction data that is collected by the store server 1 to comprehensively manage transactions carried out in the store, or it may be separate data. Then, the processor 21 finishes the transaction processing.

[0163] After transferring the transaction request in ACT242 in FIG. 18, the processor 31 of the mobile controller 3 proceeds to ACT243. In ACT243, the processor 31 waits for a notification of the completion of the payment from the virtual POS server 2. Then, if the result data indicating that the 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 judges the result as YES and proceeds to ACT244. Also, if the processor 31 is notified of the completion of the payment at the accounting machine 5 as described above, the processor 31 judges the result as YES in ACT241 and proceeds to ACT244. As ACT244, the processor 31 notifies the user terminal 200 of the completion of the payment.

[0164] After the processor 201 of the user terminal 200 requests a transaction from the mobile controller 3 in ACT 158 in FIG. 14, or after displaying the transaction barcode screen in ACT 159, the processor 201 of the user terminal 200 proceeds to ACT 160. In ACT160, the processor 201 waits for a notification of completion of the payment. If the processor 201 receives a notification of completion of the payment from the mobile controller 3 as described above, the processor 201 determines YES and proceeds to ACT161.

[0165] In ACT 161, the processor 201 displays a completion screen on the touch panel 204. The completion screen is a screen for notifying the customer that the payment has been completed. When the customer confirms the completion screen, the customer declares that he / she has confirmed the completion by a predetermined operation such as touching a button displayed on the completion screen. In response to this, the processor 201 proceeds to ACT 162. The processor 201 may also proceed to ACT 162 when the elapsed time while the completion screen is displayed reaches a predetermined time.

[0166] As ACT162, the processor 201 displays a scan screen for checkout on the touch panel 204. The scan screen for checkout is a screen for reading the two-dimensional code TCO for checkout. The processor 201, for example, starts the camera 205, and generates a scan screen by superimposing 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 an image obtained by the camera 205.

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

[0168] In ACT163, the processor 201 waits for the two-dimensional code to be read. At this time, the processor 201 repeatedly analyzes the image obtained by the camera 205 and attempts to read the two-dimensional code. This reading of the two-dimensional code may be performed as a process based on the smartphone POS app APD, or may be performed as a process based on another application program for reading the two-dimensional code. Then, if the two-dimensional code is read, the processor 201 judges YES and proceeds to ACT164.

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

[0170] If the processor 201 confirms that the data represented by the read two-dimensional code is check-out data, it judges YES in ACT164 and proceeds to ACT165. In ACT 165 , the processor 201 requests the mobile controller 3 to check out.

[0171] After notifying the completion of the payment in ACT244 in FIG. 18, the processor 31 of the mobile controller 3 proceeds to ACT245. In ACT245, the processor 31 waits for a check-out request. If a check-out request is received from the user terminal 200 as described above, the processor 31 determines YES and proceeds to ACT246.

[0172] As ACT246, the processor 31 executes a checkout process. The checkout process is a process for clearing data stored in the main memory 32 and the auxiliary storage unit 33 for managing the transaction that was the subject of the process. The virtual POS server 2 may end the process related to the transaction in response to the completion of the settlement, or may end the process related to the transaction in response to an instruction from the mobile controller 3. In the latter case, the processor 31 issues the above instruction to the virtual POS server 2 in the checkout process. In addition, 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 a process for updating the history database in the checkout process so as to reflect the history of operations related to the current transaction. In ACT 247, the processor 31 notifies the user terminal 200 of the completion of check-out. Then, the processor 31 ends the information processing shown in FIGS.

[0173] After the processor 201 of the user terminal 200 requests check-out in ACT 165 in FIG. In ACT 166, the processor 201 waits for a notification of check-out completion. If the processor 201 receives a notification of check-out completion from the mobile controller 3 as described above, the processor 201 determines YES and proceeds to ACT 167.

[0174] In ACT167, the processor 201 clears various data temporarily used for this shopping, such as the check-in data saved in ACT107 in Fig. 10. Then, the processor 201 returns to ACT101 in Fig. 10.

[0175] As described above, when the sales data transmitted by the processor 21 of the virtual POS server 2 executing ACT331 in Fig. 21 is transmitted to the store server 1 via the in-store communication network 7, the sales data is received by the communication interface 14. In response to this, the processor 11 judges YES in ACT402 and proceeds to ACT405. In ACT 405, the processor 11 updates the inventory database DBAB to reflect the decrease in inventory due to the sale. For example, the processor 11 changes the inventory quantity included in the inventory information described in the inventory database DBAB in association with the product code shown in the sales data to a quantity obtained by subtracting the quantity that forms a pair of the same product code and the sales data from the above inventory quantity. Then, the processor 11 thereafter returns to the standby state of ACT402 and ACT403.

[0176] On the other hand, when a product arrives, the store clerk uses an information terminal (not shown in FIG. 1) to specify the arrival of the product. That is, the store clerk inputs the product code and the number of items that have arrived into the information terminal. The information terminal then transmits arrival notification data including a pair of the product code and the number of items that have arrived to the store server 1. When this arrival notification data is transmitted to the store server 1 via the in-store communication network 7, the communication interface 14 receives the arrival notification data. In response to this, the processor 11 determines YES in ACT403 and proceeds to ACT406. In ACT 406, the processor 11 updates the inventory database DBAB to reflect the increase in inventory due to the arrival of goods. For example, the processor 11 changes the inventory quantity included in the inventory information described in the inventory database DBAB in association with the product code shown in the sales data to the quantity obtained by adding the quantity paired with the same product code in the arrival notification data to the above inventory quantity. In ACT407, the processor 11 checks whether there is a reservation for the received item. For example, if none of the item codes included in the arrival notification data match the item code set in any of the fields FBC of the data records REA included in the reservation database DBAC, the processor 11 judges the answer as NO and returns to the standby state of ACT402 and ACT403. However, if any of the item codes included in the arrival notification data match the item code set in any of the fields FBC of the data records REA included in the reservation database DBAC, the processor 11 judges the answer as YES in ACT407 and proceeds to ACT408. As ACT408, the processor 11 executes a process for notifying the customer who has made a reservation of the arrival of the product. For example, for each product code included in the arrival notification data, the processor 11 extracts a data record REA from the reservation database DBAC in which the product code is set in the field FBC and the notification flag set in the field FBF indicates that the product has not been notified. The processor 11 then notifies the contact information previously determined for the user identified by the user code set in the field FBB of the extracted data record REA that the reserved product has arrived. This notification can be made, for example, by email or a push notification to the user terminal 200. The contact information may be described in association with the user code in a user database provided in the database group DBAA, for example. After making such a notification, the processor 11 updates the notification flag set in the field FBF of the corresponding data record REA to a state indicating that the notification has been made. Thus, the processor 11 executes information processing based on the store management application APA, and the computer having the processor 11 as its central part functions as a notification means. Then, when the processor 11 has finished the above notification for all of the extracted data records REA, it returns to the standby state of ACT402 and ACT403. Customers who receive a notification that an item is in stock can go to the store and pick it up.

[0177] As described above, according to this embodiment, a product that is out of stock can be registered as a pre-order product together with a purchased product and can be purchased. This makes it easy to pre-order a product that is out of stock.

[0178] In addition, the product sales processing system of this embodiment registers out-of-stock products as reserved products in response to instructions from customers. Therefore, after confirming that a specified product is out of stock, a customer can decide whether or not to register the product as a reserved product, and register it as a reserved product as necessary.

[0179] In addition, the product sales processing system of this embodiment notifies customers associated with reserved products that have arrived that the product has arrived. Therefore, when a reserved product arrives, the customer who reserved the reserved product can be promptly notified of the arrival. If the customer promptly collects the reserved product in response to this notification, the waiting time until the customer can receive the reserved product can be kept to a minimum.

[0180] In addition, the product sales processing system of this embodiment determines the reserved product according to the customer's specification from among products that meet the conditions specified by the customer. Therefore, even if the customer cannot find the desired product in the store, the product can be registered as a reserved product.

[0181] This embodiment can be modified in various ways as follows. For example, when shopping is performed using the cart terminal 300 instead of the user terminal 200, the user terminal 200 can be read as the cart terminal 300. In other words, the processor 302 of the cart terminal 300 may execute information processing that is generally similar to the information processing performed by the processor 201 of the user terminal 200. However, in the case of the cart terminal 300, for example, by storing in advance in the main memory 303 or the auxiliary storage unit 304 at least a portion of the various data indicated in the check-in data, the processes of ACT104 to ACT107 in FIG. 10 may be omitted.

[0182] The designation of the product to be registered as a reserved product may be performed by any other means, such as by reading a barcode displayed on a shelf label.

[0183] It can also be realized as a product sales processing system that does not provide a smartphone POS service. In this case, the operation related to the designation of a product and the registration of the product as a reserved product may be performed at a face-to-face or full-self-service POS terminal, or at a registration terminal or payment terminal in a semi-self-service POS system. This operation may also be performed by a store clerk.

[0184] If the customer specifies that payment for the reserved item is to be made at the time of receiving the reserved item, the reserved item may be excluded from the payment target.

[0185] Registration of a reserved item may be performed only in some of the multiple store systems.

[0186] The reservation database DBAC may be stored in the auxiliary storage unit 23 of the virtual POS server 2, the auxiliary storage unit 33 of the mobile controller 3, or an auxiliary storage unit provided in a server device not shown in Fig. 1. At least a part of the inventory management process shown in Fig. 27 may be executed by a processor of a device provided with an auxiliary storage unit that stores the reservation database DBAC.

[0187] Notification regarding the arrival of reserved items does not have to be given. In this case, for example, a reservation ticket showing the expected arrival date or a rough estimate may be printed by the printer of the accounting machine 5, or a screen showing the reservation ticket may be made displayable on the touch panel 204 of the user terminal 200.

[0188] The functions of the mobile controller 3 may be integrated into the virtual POS server 2, and the mobile controller 3 may not be provided.

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

[0190] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other 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 in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. The invention as originally claimed in the present application is set forth below. [Appendix 1] A means for determining a product; a creation means for creating a list of purchased items including the items determined by the determination means; a payment means for paying for the purchased items included in the list created by the creation means; A determination means for determining, when the purchased product determined by the determination means is out of stock, the purchased product as a reservation product; A product sales processing system comprising: [Appendix 2] When the product determined by the determination means is out of stock, the creation means includes the product in the list as a purchased product when inclusion in the list is specified. Item sales processing system according to appendix 1. [Appendix 3] An identification means for identifying a customer who purchases the purchased product; a management means for managing the reserved product determined by the determination means in association with the customer identified by the identification means; a notification means for notifying a customer managed by the management means that the reserved product is now available for delivery in association with the reserved product that is now available for delivery; 3. The product sales processing system according to claim 1 or 2, further comprising: [Appendix 4] The determination means determines a product according to a customer's designation from among products that meet the conditions designated by the customer. A product sales processing system according to any one of Supplementary Note 1 to Supplementary Note 3. [Appendix 5] The determination means determines the product in response to an operation on a portable terminal that can be moved by a customer. A product sales processing system according to any one of Supplementary Note 1 to Supplementary Note 4. [Explanation of symbols]

[0191] 100 (100-1, 100-2)... store system, 200... user terminal, 300... cart terminal, 400... relay server, 500... communication network, 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, 201, 302... processor, 12, 22, 32, 202, 303... main memory, 13, 23, 33, 203, 304... auxiliary memory unit, 14, 24, 34... communication interface, 204, 305... touch panel, 205... camera, 206, 306... sound unit, 207... sensor group, 208, 307... wireless communication unit, 209... mobile communication unit, 301... barcode scanner.

Claims

1. A product sales processing system for processing product sales in a store, A determination means for determining products that are available for sale at the store and that are in stock at the store; A reception means for receiving designation of products to be sold at the store; a confirmation means for confirming whether the product designated by the reception means is in stock at the store; a creating means for creating a list of purchased items, the list including a distinguishable indication that an item that cannot be confirmed as being in stock by the confirming means is a reserved item in response to a designation to reserve, and a distinguishable indication that an item that is determined by the determining means is not a reserved item; a payment means for paying for all the purchased items included in the list created by the creation means; A product sales processing system comprising:

2. A display means for displaying a screen informing the display location of the product confirmed to be in stock by said confirmation means; The product sales processing system according to claim 1 , further comprising:

3. An identification means for identifying a customer who purchases the merchandise; a management means for managing the reserved product in association with the customer identified by the identification means; a notification means for notifying a customer managed by the management means that the reserved product is now available for delivery in association with the reserved product that is now available for delivery; 3. The product sales processing system according to claim 1, further comprising:

4. The receiving means receives a selection by the customer from among products that meet the conditions specified by the customer. The product sales processing system according to any one of claims 1 to 3.

5. The reception means receives a designation by an operation on a portable terminal that can be moved by a customer. The product sales processing system according to any one of claims 1 to 4.

Images