JP7555579B2 - Product sales data processing system and payment device - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act (1) ▲1▼ Sales and implementation date (publication date) November 21, 2020 (employee use start date) November 27, 2020 (general public use start date) ▲2▼ Sales destination Head office "Zennihon Shokuhin Co., Ltd." (6-2-2 Iriya, Adachi-ku, Tokyo 121-0836) Implementation location (store) "Super Ace 30-jo Store" (1-2-8 Kita 30-jo Higashi, Higashi-ku, Sapporo, Hokkaido 065-0030) (Implementation location general public use notice / web publication URL: https://ptl.zchain.co.jp/store/385?store_group_id=1)

The present invention relates to a product sales data processing system and a settlement device.

A system has been proposed in which customers themselves can register products using mobile terminals (see, for example, Patent Document 1).

JP 2018-055700 A

However, various problems may arise when checking out after registering a product.

The present invention was made in light of these circumstances, and aims to provide technology to resolve various problems that arise during checkout in a system in which customers themselves register products using mobile terminals.

One aspect of the present invention to solve the above-mentioned problems is a product sales data processing system that registers products using a portable registration device operated by the customer, and includes a registration means that executes a registration process to obtain product information corresponding to a specified product code from a first product information database and register the product, a settlement means that executes a settlement process by referring to the product information after the registration process by the registration means is completed, and a notification means that notifies the customer, and the settlement means is further capable of executing an automatic registration process to obtain product information corresponding to the product code from a second product information database without operation and register the product if the product code is specified but product information corresponding to the product code cannot be obtained from the first product information database, and the notification means is characterized in that when the automatic registration process is executed, the product sales data processing system automatically notifies that a product has been registered.

FIG. 1 is a conceptual diagram of a network for explaining a sales system. FIG. 2 is a diagram illustrating a settlement device. 13 is an example of a file related to a sales system. 13 is an example of a file related to a sales system. 13 is a display example of a mobile terminal. 13 is a display example of a mobile terminal. 13 is a display example of a mobile terminal. 13 is a display example of a mobile terminal. FIG. 11 is a sequence diagram showing an example of processing by a mobile terminal and a cloud server. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 11 is a sequence diagram showing an example of processing by the settlement device and the cloud server. FIG. A sequence diagram showing an example of processing by a settlement device, a store controller, a headquarters server, a cloud server, and a mobile terminal. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device. 13 is an example of a display on a settlement device.

Figure 1 is a conceptual diagram of a network to explain the sales system 1. The sales system 1 shown in Figure 1 includes a headquarters server 10, a cloud server 20, a store controller 30 (e.g., a server, etc.), a settlement device 40, a transaction status management device 50 (e.g., a personal computer, etc.), and a mobile terminal 60 (e.g., a smartphone, etc.). The sales system 1 can be introduced in various stores, etc. (supermarkets, convenience stores, drug stores, home centers, home appliance retailers, other specialty stores, etc.).

The sales system 1 provides a self-service (hereinafter, sometimes referred to as service A) in which a customer uses a mobile terminal 60 to register products and uses a settlement device 40 to settle the payment. In other words, service A is a self-service in which the customer registers products and settles the payment himself/herself, using a mobile terminal 60 for product registration and a settlement device 40 for settlement.

The sales system 1 may provide other services in addition to service A. For example, as the other services, the sales system 1 may provide one or more of the following: a service in which a customer uses a registration and settlement device 41 (not shown) to register and settle products; a service in which a store clerk uses a registration and settlement device 42 (not shown) to register products and settle; or a service in which a store clerk registers products using a registration and settlement device 42 (not shown) or a registration device 43 (not shown) and a customer settles using a settlement device 40 or a settlement device 44 (not shown).

The headquarters server 10 is installed outside the store (e.g., at a head office or a data center) and is a server that manages the entire sales system 1. The headquarters server 10 stores, for example, various information required for the operation of service A (e.g., product master, special sale file, etc.) and performance information of service A in the store (e.g., sales performance information, product sales performance information, etc.). The headquarters server 10 communicates with other devices, etc. (e.g., cloud server 20, store controller 30, product ordering system (not shown), etc.). Note that the headquarters server 10 may be composed of multiple servers.

The cloud server 20 is installed outside the store (e.g., in a data center, etc.) and is a server that provides service A. The cloud server 20 stores, for example, various information (e.g., product master, transaction information, etc.) necessary for the operation of service A. The cloud server 20 communicates with other devices, etc. (e.g., the headquarters server 10, the store controller 30, the mobile terminal 60, etc.). Note that the cloud server 20 may be composed of multiple servers.

The store controller 30, settlement device 40, and transaction status management device 50 are installed in the store and are connected to each other so that they can communicate with each other via a LAN 19 (which may be wired or wireless). Note that the number of each device shown in FIG. 1 is just an example. For example, while two settlement devices 40 are shown in FIG. 1, the number of settlement devices 40 in one store may be one or three or more. Also, while one transaction status management device 50 is shown in FIG. 1, the number of transaction status management devices 50 in one store may be two or more.

Mobile terminals 60 may also be present within the store. The number of mobile terminals 60 within a store varies depending on the number of users (number of customers) of service A at the store. In FIG. 1, two mobile terminals 60 are illustrated as an example of a system that can be used by multiple people at the same time. Note that it is assumed that the mobile terminals 60 are owned by the individual customer (or corporation) who uses service A, but they may also be loaned by the store.

The mobile terminal 60 is a terminal used when registering a product in service A. That is, the customer uses the mobile terminal 60 when registering a product in service A. The mobile terminal 60 has a communication function, an imaging function (camera), and a recognition function for recognizing various codes (barcodes, two-dimensional codes, etc.). For example, the mobile terminal 60 recognizes a barcode attached to a product. For example, the mobile terminal 60 may extract feature points in an image captured by the imaging function (an image acquired as a through image (live view)) and recognize an object (various codes).

The settlement device 40 is a device used for settling payments in service A. In other words, the customer uses the settlement device 40 when settling payments for products registered using the mobile terminal 60. The configuration of the settlement device 40 will be described later.

The store controller 30 is a device that controls the part of the sales system 1 that is related to the store. The store controller 30 communicates with other devices outside the LAN 19 (e.g., the headquarters server 10, the cloud server 20, etc.). For example, the store controller 30 receives product master data and sale files from the headquarters server 10 and supplies them to the settlement device 40.

The transaction status management device 50 is a device that mainly manages various devices within the LAN 19. For example, the transaction status management device 50 monitors the operating status of the settlement device 40, etc.

Figure 2 is a diagram explaining the settlement device 40. Figure 2 (A) is a diagram showing an example of the appearance of the settlement device 40 (front view seen from the customer side). Figure 2 (B) is a diagram showing an example of the configuration of the settlement device 40. In Figures 2 (A) and 2 (B), the same parts are given the same reference numerals.

Below, an example of the configuration of the settlement device 40 shown in FIG. 2(B) will be described with reference to FIG. 2(A). The settlement device 40 comprises a CPU 401, a ROM 402, a RAM 403, a hard disk 404, a display unit 405, a scanner unit 406, a card payment unit 408, a change machine 409, a printing unit 413, an audio output unit 414, a communication unit 415, an imaging unit 416 (camera), and a sign pole 417. These can communicate with each other via a bus. The settlement device 40 may further comprise a key operation unit composed of various keys (buttons), a sensor for detecting the presence of a person (such as a human sensor), etc.

The CPU 401 is a central processing unit, and controls the operation of the settlement device 40 by reading and executing programs stored in the ROM 402 .
The ROM 402 is a read-only memory, and stores various types of information used by the CPU 401, including programs.

RAM 403 is a read/write memory, and stores various information as a main storage device. For example, RAM 403 stores information read from ROM 402 or hard disk 404, information acquired from the outside, information generated during processing, etc.

The hard disk 404 stores various information as an auxiliary storage device. For example, the hard disk 404 may store programs executed by the CPU 401 instead of the ROM 402. Also, instead of the RAM 403, the hard disk 404 may store information read from the ROM 402, information obtained from the outside, information generated during processing, etc. Note that a storage device such as an SSD (Solid State Drive) may be provided instead of the hard disk 404.

The display unit 405 is a touch display that displays various information and accepts various inputs.

The scanner unit 406 optically reads various information. Specifically, the scanner unit 406 scans the code (two-dimensional code 605 for settlement (described later)) displayed on the display unit of the mobile terminal 60, and reads the information necessary for the settlement process. The scanner unit 406 may also scan a code attached to a store clerk's name tag or the like, and read the store clerk code. The scanner unit 406 may also scan codes attached to gift certificates (gift certificates, coupons, complimentary tickets) and various cards (e.g., membership cards, point cards, etc.), and read the respective information.

In addition to the above, the scanner unit 406 may scan a code attached to a product and read the product code (such as a JAN code). The scanner unit 406 may also scan a code printed on a receipt (registered trademark) printed and issued by another device (e.g., a registration settlement device 42 (not shown), a registration device 43 (not shown)) and read information required for settlement processing.

The card payment unit 408 is a payment mechanism that uses various cards (credit cards, prepaid cards such as transportation cards, cash cards for debit payments, point cards for point payments, etc.). The card payment unit 408 is equipped with a card recognition unit (reading unit), a display unit, and an operation unit, but it is sufficient that it is equipped with at least the card recognition unit. The card recognition unit may recognize various cards (e.g., point cards, membership cards, shareholder cards, etc.) for the purpose of granting benefits, discounts, etc.

The change dispenser 409 (cash settlement unit) is a cash settlement mechanism that has an input port for banknotes and coins and an output port for banknotes and coins, calculates the amount of money inserted into the input port, calculates the change amount, which is the difference between the input amount and the purchase amount, and outputs the change from the output port. When banknotes or coins are inserted into the input port, they are detected by a sensor (detecting that they have been inserted, detecting the number of coins by denomination, etc.).

The printing unit 413 prints and issues various media (receipts, etc.).
The audio output unit 414 outputs audio. For example, the audio output unit 414 outputs a confirmation sound, a warning sound, audio guidance, etc.

The communication unit 415 transmits and receives information to and from other devices (e.g., the store controller 30).
The imaging unit 416, for example, captures an image of the customer. The settlement device 40 may include two or more imaging units 416, and may simultaneously capture an image of the face and hands (near the insertion and ejection ports of the change dispenser 409).
The sign pole 417 has a light emitting part at its tip, and various information (calling a store clerk, operating status, etc.) is communicated depending on the light emitting state of the light emitting part.

Figure 3 is an example of a file related to the sales system 1. Figure 3 (A) is an example of a product master (referred to as a checkout product master) stored by the headquarters server 10. Figure 3 (B) is an example of a bargain file stored by the headquarters server 10. In addition to the headquarters server 10, the store controller 30 and the settlement device 40 also store a checkout product master and bargain files (details will be described later).

The checkout product master may be referenced when checking out using service A (checkout using the checkout device 40). Specifically, the checkout product master is referenced when the products being purchased at checkout include products whose product codes are not stored in the registration product master (i.e., products that are not registered in the registration product master; also known as NON-FILE products).

The checkout product master stores information such as a product code (product identification information) that identifies a product, product name (item name), and price (sales price). In the example of Figure 3 (A), the checkout product master stores the product name and price in association with the product code. Note that the product codes such as "S0123" and "S0135" shown in Figure 3 (A) are examples given for the sake of convenience, and may be JAN codes or the like. Hereinafter, either or both of the product name and price may be referred to as product information. Product codes may also be referred to as product information.

The sale file is referenced when settlement is made through service A. The sale file stores a sale code (sale identification information) that identifies the sale, the sale conditions (target product), and the sale details (discount amount). In the example of FIG. 3(B), the sale file stores the sale conditions and sale details in association with the sale code. Hereinafter, either or both of the sale conditions and sale details may be referred to as sale information. The sale code may also be referred to as sale information.

Figure 4 shows an example of a file related to the sales system 1. Figure 4 (A) shows an example of a product master (called a product master for registration) stored in the cloud server 20. Figure 4 (B) shows an example of a temporary product file stored in the cloud server 20.

The product master for registration is referenced when registering a product using service A (registering a product using the mobile terminal 60). The product master for registration stores information such as the product code, product name, and price, just like the product master for checkout. In the example of FIG. 4(A), the product master for registration stores the product name and price in association with the product code.

The provisional product file may be referenced when a product is registered by service A. Specifically, the provisional product file is referenced when the product code sent from the mobile terminal 60 is not stored in the product master for registration at the time of product registration. The provisional product file may always be referenced when a product is registered by service A. In other words, the order of reference may be the product master for registration → provisional product file, or the provisional product file → product master for registration at the time of product registration. In the latter case, the provisional product file is always referenced when a product is registered by service A. In the latter case, the product master for registration at the time of product registration may not be referenced (if the product code sent from the mobile terminal 60 is stored in the provisional product file that is referenced first, the product master for registration at the time of product registration is not referenced).

The provisional product file stores information such as the product code, product name, and price, just like the product master for registration. In the example of FIG. 4(B), the provisional product file stores the product name and price in association with the product code. Note that if the product master for registration is updated, for example, and the information in the provisional product file is reflected in the product master for registration, the information in the provisional product file may be erased.

The headquarters server 10 transmits the checkout product master to the store controller 30. The store controller 30 stores the checkout product master received from the headquarters server 10 in its own device and transmits it to each checkout device 40. The checkout device 40 stores the checkout product master received from the store controller 30 in its own device. In other words, in addition to the headquarters server 10, the store controller 30 and the checkout device 40 also store the checkout product master.

The headquarters server 10 also transmits the checkout product master to the cloud server 20 in addition to the store controller 30. The cloud server 20 stores the checkout product master received from the headquarters server 10 as the registration product master.

The information stored in the product master for registration at a certain point in time may differ from the information stored in the product master for checkout at that point in time. Specifically, both the product master for registration stored in the cloud server 20 and the product master for checkout stored in, for example, the checkout device 40 are derived from the product master for checkout stored in the headquarters server 10, but because of the difference in frequency of transmission and reception (frequency of updates), the contents of the former may be older than the contents of the latter. For example, in the example shown in Figures 3 (A) and 4 (A), the product master for checkout (Figure 3 (A)) stores the product with product code "S0274" (○○ gum) and the product with product code "S0275" (○○ snack) as new sales products, whereas the product master for registration (Figure 4 (A)) does not store the product with product code "S0274" (○○ gum) or the product with product code "S0275" (○○ snack).

In this example, the headquarters server 10 transmits the checkout product master to the store controller 30 at least once a day, the store controller 30 immediately stores the received checkout product master, and transmits the checkout product master to the checkout device 40 at least once a day, and the checkout device 40 immediately stores the received checkout product master. In this example, the headquarters server 10 transmits the checkout product master to the cloud server 20 several times a week or month, and the cloud server 20 immediately stores the received checkout product master as a registration product master. In other words, in this example, the checkout product master is updated at least once a day, and the registration product master is updated several times a week or month. In other words, the registration product master is older than the checkout product master, as information reflected in the checkout product master may not be reflected in the registration product master.

The headquarters server 10 also transmits the sale file to the store controller 30. The store controller 30 stores the sale file received from the headquarters server 10 in its own device and transmits it to each settlement device 40. The settlement device 40 stores the sale file received from the store controller 30 in its own device. In other words, in addition to the headquarters server 10, the store controller 30 and the settlement device 40 also store the sale file.

The cloud server 20 generates and updates a provisional product file based on receiving NON-FILE resolution information (described below) that includes the product code, product name, and price.

The NON-FILE resolution information is information indicating that a NON-FILE has been resolved (that a NON-FILE has been resolved), and is generated and transmitted by the settlement device 40. The settlement device 40 may generate and transmit the NON-FILE resolution information when settlement is made for service A (settlement by the settlement device 40). Specifically, the settlement device 40 generates and transmits the NON-FILE resolution information after the NON-FILE is resolved if, at the time of settlement, a NON-FILE product (a product not registered in the product master for registration) is included among the products being purchased and the product code of the NON-FILE product is stored in the product master for settlement (i.e., when the NON-FILE can be resolved), the settlement device 40 generates and transmits the NON-FILE resolution information. The cloud server 20 receives the NON-FILE resolution information transmitted from the settlement device 40 via another device or directly from the settlement device 40. Note that resolving a NON-FILE means resolving a problem caused by a NON-FILE that occurred when registering a product on the mobile terminal 60 (a situation in which the price, etc., was not obtained) in the settlement device 40 (obtaining the price, etc., that was not obtained).

(Display example of mobile terminal 60 (transaction example (purchased product example) 1))
FIG. 5 is a display example of the mobile terminal 60. FIG. 6 is a display example of the mobile terminal 60. FIGS. 5(A) and 5(B) are display examples of a scene before registering a product. FIGS. 5(C) to 6(B) are display examples of a scene in which each of products 1 to 3 is registered as a NON-FILE product as transaction example 1. FIG. 6(C) is a display example of a two-dimensional code display screen corresponding to the above transaction example 1. FIGS. 5 and 6 transition in the order of FIG. 5(A) → FIG. 5(B) → FIG. 5(C) → FIG. 5(D) → FIG. 6(A) → FIG. 6(B) → FIG. 6(C).

Figure 5 (A) is the start screen (menu screen) of service A. When using service A, the mobile terminal 60 displays a start screen such as that shown in Figure 5 (A). Various buttons are arranged on the start screen. For example, the start screen has a start shopping button BT600 that accepts an instruction to start shopping. When a customer wants to start shopping, they operate the start shopping button BT600.

Figure 5 (B) is a registration screen (registration screen before registering one product; initial registration screen) that is displayed after the Start Shopping button BT600 is operated on the start screen of Figure 5 (A). The upper side of the registration screen is a captured image display area HR601 that mainly displays captured images. The lower side of the registration screen is a registration information display area HR602 that mainly displays product registration information.

Figure 5 (C) is the registration screen when the barcode attached to the first item is imaged on the registration screen of Figure 5 (B). In other words, when a customer registers a desired item (item to be purchased), the barcode attached to the item is read as shown in Figure 5 (C). Note that the barcode attached to the first item is a barcode that encodes the product code "S0204".

Figure 5 (D) is a registration screen after the registration of one product item is completed (registration screen after product registration). Specifically, the mobile terminal 60 transmits the product code "S0204" obtained from the barcode (a barcode obtained by encoding the product code "S0204") to the cloud server 20. The cloud server 20 refers to the product master for registration (Figure 4 (A)) and obtains the product name "XX bread" and the price "¥220" based on the product code "S0204". The cloud server 20 stores the product information (product code "S0204", product name "XX bread", quantity "1", price "¥220", etc.) as transaction information (cart information) for the transaction, and transmits the product information (product name "XX bread", price "¥220", etc.) to the mobile terminal 60. The mobile terminal 60, which has received the product information from the cloud server 20, reflects the product information for that one item in the registration information display area HR602. Specifically, as shown in FIG. 5(D), the mobile terminal 60 displays the registration information for that product (product name "XXX bread", quantity "1", price "¥220") (symbol a), and displays the total information (estimated total "1 item ¥220") (symbol b). The mobile terminal 60 displays part of the registration information (quantity) as a quantity button BT603. The quantity button BT603 is a button for changing the quantity.

After registering a product (one item of product), the mobile terminal 60 also displays an operable button BT604 for proceeding to checkout, which accepts checkout instructions, as shown in FIG. 5(D). When the customer wishes to proceed to payment (checkout) (when product registration is complete), the customer operates the button BT604 for proceeding to checkout.

Figure 6 (A) shows the registration screen after the registration of the second product has been completed, following the scene in Figure 5 (D). Specifically, the mobile terminal 60 captures an image of the barcode attached to the second product. It is assumed that the barcode attached to the second product is a coded barcode of the product code "S0245". The mobile terminal 60 transmits the product code "S0245" obtained from the barcode to the cloud server 20. The cloud server 20 refers to the product master for registration (Figure 4 (A)) and obtains the product name "XX Oolong Tea" and the price "150 yen" based on the product code "S0245". The cloud server 20 stores the product information (product code "S0245", product name "XX Oolong Tea", quantity "1", price "¥150", etc.) as transaction information for the transaction, and transmits the product information (product name "XX Oolong Tea", price "¥150", etc.) to the mobile terminal 60. Having received the product information from the cloud server 20, the mobile terminal 60 reflects the product information for the two items in the registered information display area HR602. Specifically, as shown in FIG. 6(A), the mobile terminal 60 displays (adds) the registered information for the product (product name "XX Oolong Tea", quantity "1", price "¥150") and displays (updates) the total information (estimated total "2 items ¥370").

Figure 6 (B) is a registration screen following the scene in Figure 6 (A) after the registration of the three items has been completed (registration as unregistered items has been completed). Specifically, the mobile terminal 60 captures an image of the barcode attached to the three items. It is assumed that the barcode attached to the three items is a barcode that encodes the product code "S0275". The mobile terminal 60 transmits the product code "S0275" obtained from the barcode to the cloud server 20. The cloud server 20 refers to the product master for registration (Figure 4 (A)) and recognizes (determines) that the product code "S0275" is not stored in the product master for registration. Furthermore, the cloud server 20 refers to the provisional product file (Figure 4 (B)) and recognizes that the product code "S0275" is not stored in the provisional product file either. Cloud server 20 stores the product information (product code "S0275", NON-FILE, quantity "1", etc.) as transaction information for the transaction, and transmits the product information (information indicating that it is a NON-FILE, etc.) to mobile terminal 60. Mobile terminal 60 receives the product information from cloud server 20 and reflects the product information for the three items in registration information display area HR602. Specifically, as shown in FIG. 6(B), mobile terminal 60 displays (adds) the registration information for the product ("unregistered product" indicating that it is a NON-FILE, quantity "1") and displays (updates) the total information (estimated total "3 items, 370 yen").

Figure 6 (C) shows a two-dimensional code display screen that is displayed after the Proceed to Checkout button BT604 is operated, following the scene in Figure 6 (B). The two-dimensional code display screen shows a two-dimensional code 605 for checkout. The two-dimensional code 605 for checkout is a two-dimensional code of information required to execute the checkout process. For example, the two-dimensional code 605 for checkout is a two-dimensional code of transaction identification information (cart identification information) that identifies the transaction information of the transaction from among multiple pieces of transaction information stored in the cloud server 20. Note that the information that is two-dimensionally coded does not have to be transaction identification information, as long as the transaction information of the transaction can be obtained after reading. For example, the two-dimensional code 605 for checkout may be a two-dimensional code of location information of the transaction information of the transaction (a storage location in the sales system 1, such as a URI (Uniform Resource Identifier)).

The two-dimensional code display screen also has an estimated total display area HR606 and a back button BT607. In the example of FIG. 6(C), the estimated total display area HR606 displays the estimated total of "3 items, 370 yen," and also displays the message "Unregistered item (1 item) not included." This message notifies the user that the price of the unregistered item (1 item) is not reflected in the estimated total. The back button BT607 is a button for returning to shopping (restarting shopping). When the back button BT607 is operated, the mobile terminal 60 displays a registration screen (the registration screen displayed immediately before the Proceed to Checkout button BT604 is operated) instead of the two-dimensional code display screen.

Figure 6 (D) shows how the settlement device 40 reads the settlement two-dimensional code 605. After completing product registration, the customer has the settlement device 40 read the settlement two-dimensional code 605 displayed on the mobile terminal 60, as shown in Figure 6 (D).

(Display example of mobile terminal 60 (transaction example 2))
Fig. 7 shows an example of a display on the mobile terminal 60. Fig. 7(A) to Fig. 7(C) show an example of a display when registering products (items 1 to 3) different from those in transaction example 1 as transaction example 2. Fig. 7(D) shows an example of a display of a two-dimensional code display screen corresponding to transaction example 2. Note that Fig. 7(A) is a continuation of Fig. 5(B), and the transition is as follows: Fig. 5(A) → Fig. 5(B) → Fig. 7(A) → Fig. 7(B) → Fig. 7(C) → Fig. 7(D).

Fig. 7 (A) is a registration screen following the scene in Fig. 5 (B) after the registration of one product item has been completed. Specifically, the mobile terminal 60 shows a registration screen after the registration of XX Gyoza (product code "S0123") has been completed. As shown in Fig. 7 (A), the mobile terminal 60 displays the registration information for that product (product name "XX Gyoza", quantity "1", price "¥290") and total information (estimated total "1 item ¥290").

Figure 7 (B) is a registration screen following the scene in Figure 7 (A) after the registration of the second product has been completed. Specifically, the mobile terminal 60 shows a registration screen after the registration of XX stir fry (product code "S0144") has been completed. As shown in Figure 7 (B), the mobile terminal 60 displays the registration information for that product (product name "XX stir fry", quantity "1", price "¥420") and total information (estimated total "2 items ¥710")

Figure 7 (C) shows the registration screen after the registration of three items and the change in quantity, following the scene in Figure 7 (B). Specifically, the mobile terminal 60 shows the registration screen after the registration of XX socks (product code "S0597") is completed and the quantity is then changed to three by operating the quantity button BT603. As shown in Figure 7 (C), the mobile terminal 60 displays the registration information for that product (product name "XX socks", quantity "3", price "¥900") and total information (estimated total "5 items ¥1610")

Figure 7 (D) shows a two-dimensional code display screen that is displayed after the Proceed to Checkout button BT604 is operated, following the scene in Figure 7 (C). In the example of Figure 7 (D), the estimated total display area HR606 shows the estimated total "5 items, 1610 yen."

(Display example of mobile terminal 60 (transaction example 3))
Fig. 8 is a display example of the mobile terminal 60. Fig. 8(A) to Fig. 8(C) are display examples of a scene in which products (items 1 to 3) different from those in transaction examples 1 and 2 are registered as transaction example 3. Fig. 8(D) is a display example of a two-dimensional code display screen corresponding to the above transaction example 3. Note that Fig. 8(A) is a continuation of Fig. 5(B), and the transition is as follows: Fig. 5(A) → Fig. 5(B) → Fig. 8(A) → Fig. 8(B) → Fig. 8(C) → Fig. 8(D).

Fig. 8 (A) is a registration screen following the scene in Fig. 5 (B) after the registration of one product item has been completed. Specifically, the mobile terminal 60 shows a registration screen after the registration of XX bento (product code "S0175") has been completed. As shown in Fig. 8 (A), the mobile terminal 60 displays the registration information for that product (product name "XX bento", quantity "1", price "￥620") and total information (estimated total "1 item ￥620")

Figure 8 (B) is a registration screen following the scene in Figure 8 (A) after the registration of two items has been completed. Specifically, the mobile terminal 60 shows a registration screen after the registration of XX Green Tea (product code "S0215") has been completed. As shown in Figure 8 (B), the mobile terminal 60 displays (adds) the registration information for that product (product name "XX Green Tea, quantity "1", price "¥130") and displays total information (estimated total "2 items ¥750").

Following on from the scene in FIG. 8(B), FIG. 8(C) shows the registration screen after the registration of three items and the change in quantity have been completed. Specifically, the mobile terminal 60 shows the registration screen after the registration of XX salad (product code "S0170") has been completed. As shown in FIG. 8(C), the mobile terminal 60 displays (adds) the registration information for that product (product name "XX salad", quantity "1", price "¥280") and displays total information (estimated total "3 items ¥1030").

Figure 8 (D) shows a two-dimensional code display screen that is displayed after the Proceed to Checkout button BT604 is operated, following the scene in Figure 8 (C). In the example of Figure 8 (D), the estimated total display area HR606 shows the estimated total "3 items, 1,030 yen."

Figure 9 is a sequence diagram showing an example of the processing of the mobile terminal 60 and cloud server 20. Specifically, the sequence diagram of Figure 9 shows an example of the processing of the mobile terminal 60 and cloud server 20 from when one product item is registered on the mobile terminal 60 until the two-dimensional code 605 for settlement is displayed. The left side of Figure 9 shows the processing of the mobile terminal 60, and the right side shows the processing of the cloud server 20. Note that at the start of the sequence diagram of Figure 9 (the start of the processing of step S1 for the first time), the mobile terminal 60 is assumed to be displaying an initial registration screen such as that shown in Figure 5 (B).

Step S1: The mobile terminal 60 reads the barcode attached to the product in response to a reading operation by the customer. That is, the mobile terminal 60 obtains the product code from the barcode attached to the product in response to a reading operation by the customer.
Step S2: The mobile terminal 60 transmits to the cloud server 20 transaction identification information that identifies the transaction information of the transaction and the product code acquired in step S1.

Step S3: The cloud server 20 receives the transaction identification information and the product code.
Step S4: The cloud server 20 updates the transaction information of the transaction. That is, the cloud server 20 updates the transaction information corresponding to the transaction identification information received in step S3 based on the product code received in step S3.

The processing of step S4 will be described in detail. If the product code is stored in the product master for registration or the provisional product file, the cloud server 20 acquires (extracts) information corresponding to the product code (product name, price) from the product master for registration or the provisional product file, and stores the product code, product name, quantity, price, etc. in the transaction information corresponding to the transaction identification information. On the other hand, if the product code is not stored in either the product master for registration or the provisional product file, the cloud server 20 stores the product code, information indicating that it is a NON-FILE product, quantity, etc. in the transaction information corresponding to the transaction identification information.

By processing step S4, if the product whose product code was obtained in step S1 (the product whose barcode was read) is not a NON-FILE product (if the product code of the product is stored in the product master for registration, etc.), the product code, product name, quantity, price, etc. are stored in the transaction information of the transaction. On the other hand, if the product whose product code was obtained in step S1 is a NON-FILE product (if the product code of the product is not stored in the product master for registration, etc.), the product code, information indicating that it is a NON-FILE product, quantity, etc. are stored in the transaction information of the transaction.

Step S5: The cloud server 20 transmits product information for the product code (such as the product name and price, or information indicating that the product is a NON-FILE). For example, the cloud server 20 generates screen information that reflects the contents of the updated transaction information, and transmits it to the mobile terminal 60.

The process of step S5 will be described in detail. If the product whose product code was acquired in step S1 is not a NON-FILE product, the cloud server 20 transmits the product name, price, etc., as product information of the product code to the mobile terminal 60. On the other hand, if the product whose product code was acquired in step S1 is a NON-FILE product, the cloud server 20 transmits information indicating that the product code is a NON-FILE to the mobile terminal 60 as product information of the product code. Note that in step S4, if the product whose product code was acquired in step S1 is not a NON-FILE product, the product code, product name, quantity, price, etc. are stored in the transaction information of the transaction, and if the product whose product code was acquired in step S1 is a NON-FILE product, the product code, information indicating that the product is a NON-FILE product, quantity, etc. are stored in the transaction information of the transaction. Therefore, in the process of step S5, the cloud server 20 may simply generate screen information reflecting the contents of the updated transaction information and transmit it to the mobile terminal 60.

By the processing of step S5, if the product whose product code was obtained in step S1 is not a NON-FILE product, the product name and price of the product (e.g., screen information reflecting the product name and price of the product) are sent to the mobile terminal 60. On the other hand, if the product whose product code was obtained in step S1 is a NON-FILE product, information indicating that it is a NON-FILE product (e.g., screen information reflecting information indicating that it is a NON-FILE product) is sent to the mobile terminal 60.

Step S6: The mobile terminal 60 receives the product information (screen information) of the product code.
Step S7: The mobile terminal 60 updates the registration screen based on the information (screen information) received in step S6.
By the process of step S7, if the product whose product code was obtained in step S1 is not a NON-FILE product, the product name, price, etc. of the product are displayed on the registration screen. On the other hand, if the product whose product code was obtained in step S1 is a NON-FILE product, information indicating that it is a NON-FILE product is displayed on the registration screen. Steps S1 to S7 are repeatedly executed by reading the barcode attached to the product.

Step S8: The mobile terminal 60 generates a two-dimensional code 605 for payment based on the customer's payment instructions (operation of the Proceed to Payment button BT604) and displays it on the two-dimensional code display screen. Then, the sequence diagram in FIG. 9 ends.

FIGS. 10 to 17 are examples of the display of the settlement device 40. FIG. 10 shows the initial screen GM01. As shown in FIG. 10, the initial screen GM01 displays a message and a guide map to read the settlement two-dimensional code 605 (QR code (registered trademark) in the figure) displayed on the mobile terminal 60. The initial screen GM01 also has a store clerk call button BT401, a balance inquiry button BT402, and language switching buttons BT403 to BT405. The store clerk call button BT401 is a button for calling a store clerk. The balance inquiry button BT402 is a button for inquiring about the balances of various cards. The language switching button BT403 is a button for switching the display (text) on the initial screen GM01 from Japanese to English. The language switching button BT404 is a button for switching to Chinese. The language switching button BT405 is a button for switching to Korean.

After completing product registration, the customer follows the instructions on the initial screen GM01 to have the settlement device 40 read the two-dimensional settlement code 605 displayed on the mobile terminal 60. When the settlement device 40 reads the two-dimensional settlement code 605, it obtains from the cloud server 20 the transaction information of the transaction identified by the two-dimensional settlement code 605.

(Operation of settlement device 40 after acquiring transaction information)
After acquiring the transaction information from the cloud server 20, the settlement device 40 performs, for example, the following two processes related to the products in the transaction information (processing related to NON-FILE products, processing related to sale prices).

(Processing of NON-FILE products)
The settlement device 40 determines whether or not the transaction information obtained from the cloud server 20 includes any NON-FILE products (products that the mobile terminal 60 has displayed as “unregistered products” (FIG. 6(B)). If the transaction information does not include any NON-FILE products, the operation ends. In other words, since there are no NON-FILE products in the transaction information obtained from the cloud server 20, the processing ends.

If a NON-FILE product is included in the transaction information obtained from the cloud server 20, the settlement device 40 refers to the settlement product master (Figure 3 (A)) and determines whether the product code of the NON-FILE product is stored in the settlement product master (Figure 3 (A)). If the product code is stored in the settlement product master, it becomes possible to resolve the NON-FILE for the product with that product code.

If the product code of the NON-FILE product is stored in the checkout product master, the settlement device 40 obtains the product name, price, etc. of the NON-FILE product from the checkout product master, recalculates the total amount, and reflects this in the transaction information. In other words, the settlement device 40 resolves the NON-FILE for that product. Specifically, the settlement device 40 additionally stores the product name, price, etc. obtained from the checkout product master in the transaction information without erasing (overwriting) the information indicating that the product is a NON-FILE product, and additionally stores the recalculated total amount without erasing the total amount before the recalculation.

On the other hand, if the product code of the NON-FILE product is not stored in the product master for checkout, the settlement device 40, for example, illuminates the sign pole 417 in a predetermined illumination mode that indicates a call for a store clerk (or, more specifically, a predetermined illumination mode that indicates that the NON-FILE cannot be resolved). The store clerk called by the settlement device 40 enters product information (such as the product price) of the NON-FILE and proceeds with the checkout. Note that the manner of calling a store clerk when the product code of the NON-FILE product is not stored in the product master for checkout is not limited to this. For example, instead of or in addition to illuminating the sign pole 417, the settlement device 40 may send a call notification to a device operated by the store clerk (such as the transaction status management device 50 or a mobile terminal carried by the store clerk).

In other words, for products (NON-FILE products) for which the product name, price, etc. could not be obtained from the registration product master because the product code was not stored in the registration product master (FIG. 4(A)) at the time the mobile terminal 60 obtained the product code, the settlement device 40 refers to the settlement product master, which is different from the registration product master, and if the product code is stored in the settlement product master, it obtains the product name, price, etc. from the settlement product master, recalculates the total amount, and reflects this in the transaction information (resolves the NON-FILE). On the other hand, if the product code is not stored in the settlement product master, a store clerk will handle the matter. Note that if there are multiple NON-FILE products, a store clerk may be called if the NON-FILE has not been resolved for at least some of them (a store clerk may not be called if the NON-FILE has been resolved for all of them).

(Referenced product master for checkout)
As described above, the checkout product master is transmitted from the headquarters server 10 to the store controller 30 to the checkout device 40, and is stored in each device (the headquarters server 10, the store controller 30, and the checkout device 40). Therefore, the checkout product master referenced when a NON-FILE product is included in the transaction information obtained from the cloud server 20 may basically be the checkout product master stored in any device.

As an example, if a NON-FILE product is included in the transaction information obtained from the cloud server 20, the product master for checkout in the checkout device 40 → the product master for checkout in the store controller 30 → the product master for checkout in the headquarters server 10 may be referenced in stages, as shown below.

(1) The settlement device 40 refers to the settlement product master stored in the settlement device 40. If the NON-FILE is not resolved, the settlement device 40 inquires about the NON-FILE to the store controller 30 (for example, sends NON-FILE inquiry information including the product code).
(2) The store controller 30 that has received the NON-FILE inquiry information refers to the checkout product master stored in its own device. If the NON-FILE is resolved, the store controller 30 responds to the checkout device 40 to inform it of the resolution (for example, by sending the product name, price, etc.). On the other hand, if the NON-FILE is not resolved, the store controller 30 inquires about the NON-FILE to the head office server 10 (by sending the NON-FILE inquiry information).
(3) The headquarters server 10 that has received the NON-FILE inquiry information refers to the checkout product master within its own device. If the NON-FILE is resolved, the headquarters server 10 responds to the store controller 30 that the NON-FILE has been resolved (sends the product name, price, etc.). The store controller 30 that has received the notification of the resolution then responds to the checkout device 40 that the NON-FILE has been resolved. On the other hand, if the NON-FILE is not resolved, the headquarters server 10 responds to the store controller 30 that the NON-FILE will not be resolved (sends information that the NON-FILE will not be resolved). The store controller 30 that has received the notification of the resolution then responds to the checkout device 40 that the NON-FILE will not be resolved.

If there is a time lag in the process of transmitting the checkout product master (from the head office server 10 to the store controller 30 to the checkout device 40), the NON-FILE may be resolved in the checkout product master in the store controller 30 even if it is not resolved in the checkout product master in the checkout device 40, or the NON-FILE may be resolved in the checkout product master in the head office server 10 even if it is not resolved in the checkout product master in the store controller 30.

Due to the time lag problem in the process of transmitting the checkout product master (from the head office server 10 to the store controller 30 to the checkout device 40), the checkout product master in the head office server 10 or the store controller 30 may always be referenced without referencing the checkout product master in the checkout device 40, or the checkout product master in the head office server 10 may always be referenced without referencing the checkout product master in the checkout device 40 or the store controller 30. In the former case (when the checkout product master in the checkout device 40 is not referenced), the store controller 30 does not transmit the checkout product master to the checkout device 40 (i.e., the checkout device 40 does not store the checkout product master in its own device). In the latter case, the head office server 10 does not transmit the checkout product master to the store controller 30 (i.e., the store controller 30 and the checkout device 40 do not store the checkout product master in their own devices).

(Treatment of special sale prices)
The settlement device 40 refers to the sale file (FIG. 3(B)) and judges whether the product included in the transaction information obtained from the cloud server 20 (if the product name, price, etc. of the NON-FILE product is reflected, the reflected transaction information) matches the sale conditions (i.e., whether the sale (discount, discount, etc.) is applied). If the sale conditions are not met, the operation ends. If the sale conditions are met, the settlement device 40 obtains the details of the sale (sale price, etc.) from the sale file, recalculates the total amount, and reflects it in the transaction information. Specifically, the settlement device 40 additionally stores the sale price, etc. obtained from the sale file without erasing (overwriting) the product price, etc. before the sale price is applied, and additionally stores the recalculated total amount without erasing the total amount before the recalculation.

In other words, the settlement device 40 refers to the sale file that was not referenced when the product was registered on the mobile terminal 60, and if the conditions for applying the sale price (sale) are met, it obtains the applicable sale price, etc. from the sale file, recalculates the total amount, and reflects it in the transaction information.

(Referenced sale file)
As with the checkout product master, the sale file is transmitted from the headquarters server 10 to the store controller 30 to the checkout device 40, and is stored in each device (the headquarters server 10, the store controller 30, and the checkout device 40). Therefore, the sale file to be referenced may basically be a sale file stored in any device. For example, as with the checkout product master, the sale file may be referenced in stages in the order of the sale file in the checkout device 40 → the sale file in the store controller 30 → the sale file in the headquarters server 10. Also, as with the checkout product master, the sale file in the headquarters server 10 or the store controller 30 may always be referenced without referring to the sale file in the checkout device 40, or the sale file in the headquarters server 10 may always be referenced without referring to the sale file in the checkout device 40 or the store controller 30.

As described above, the settlement device 40 automatically reflects necessary information in the transaction information when settling (adds and updates necessary information to the transaction information). That is, if there is a NON-FILE product, the settlement device 40 additionally stores the price of the NON-FILE product and the recalculated total amount, etc. in the transaction information, and if a sale is applied, the settlement device 40 additionally stores the sale price and the recalculated total amount, etc. in the transaction information.

(Example of Operation of Settlement Device 40 (Transaction Example 1))
For example, when a customer has the settlement device 40 read the two-dimensional settlement code 605 (two-dimensional settlement code 605 shown in FIG. 6(C)) displayed on the mobile terminal 60 after registering the product in Transaction Example 1 (FIGS. 5(C) to 6(B)), the settlement device 40 obtains transaction information from the cloud server 20, including XX bread (product code "S0204", product name "XX bread", 1 item, ¥220) as the first product, XX oolong tea (product code "S0245", product name "XX oolong tea", 1 item, ¥150) as the second product, and a NON-FILE product (product code "S0275", information indicating that it is a NON-FILE product, 1 item) as the third product.

As the transaction information includes a NON-FILE product, the settlement device 40 refers to the settlement product master (Figure 3 (A)) and determines whether the product code "S0275" of the NON-FILE product is stored in the settlement product master (Figure 3 (A)). As the product code "S0275" of the NON-FILE product is stored in the settlement product master, the settlement device 40 obtains the product name "XX Snack", price "¥160", etc. of the NON-FILE product from the settlement product master and recalculates the total amount "¥530". The settlement device 40 then stores the product name "XX Snack" and the price "¥160" in the transaction information for the product with product code "S0275" without erasing the information that the product was a NON-FILE product, and stores the recalculated total amount "¥530" without erasing the total amount before the recalculation "¥370."

The settlement device 40 then refers to the sale file (Figure 3(B)) and determines whether the product included in the transaction information (the transaction information updated as described above in relation to the NON-FILE) meets the sale conditions. The settlement device 40 determines that the product does not meet the sale conditions. In other words, the settlement device 40 does not update the transaction information related to the sale.

(Display example of settlement device 40 (transaction example 1))
Fig. 11 is a display example of the settlement device 40 when the two-dimensional settlement code 605 shown in Fig. 6(C) is read on the initial screen GM01 of Fig. 10. When the settlement device 40 reads the two-dimensional settlement code 605 of Fig. 6(C), it displays a product list screen GM02 as shown in Fig. 11, and further displays a small screen SG10 in front of the product list screen GM02. The product list screen GM02 will be described later.

The small screen SG10 displays a message saying "Product information was found and some products were automatically registered." This message notifies the user that a NON-FILE product has been automatically registered (i.e., that the NON-FILE has been automatically resolved). In other words, when the settlement device 40 automatically registers a NON-FILE product, it uses the small screen SG10 to notify the user that the NON-FILE product has been automatically registered. The settlement device 40 uses the icon ICN415 (described below) on the product list screen GM02 to notify the user that the automatically registered product is an automatically registered product. The small screen SG10 is provided with an OK button. The OK button is a button for confirming the message on the small screen SG10 and erasing the small screen SG10.

Figure 12 shows an example of the display of the settlement device 40 when the OK button is operated on the small screen SG10 of Figure 11. When the OK button is operated, the settlement device 40 erases the small screen SG10 as shown in Figure 12 (i.e., simply displays the product list screen GM02).

The product list screen GM02 has a product list display area HR410, a product quantity by price range display area HR411, and a total display area HR412. The product list screen GM02 also has a call store clerk button BT401 and a checkout button BT409. The checkout button BT409 is a button for confirming that there are no problems with the content displayed on the product list screen GM02 and for proceeding with the process.

The product list display area HR410 is an area for displaying a list of products to be settled (purchased). The settlement device 40 displays a list of products (product name, quantity, price) included in the transaction information obtained by reading the settlement two-dimensional code 605 (or the updated transaction information if the settlement device 40 has updated the content) in the product list display area HR410.

In the example of FIG. 12, the settlement device 40 displays XX bread, XX oolong tea, and XX snack in the product list display area HR410. XX bread is the first product in transaction example 1 (FIG. 5(D)). XX oolong tea is the second product in transaction example 1 (FIG. 6(A)). XX snack is the third product in transaction example 1 (FIG. 6(B)) and is a product that was automatically registered by the settlement device 40. In addition, the icon ICN415 displayed in association with XX snack notifies the user that it is a product that was automatically registered by the settlement device 40.

The price range product quantity display area HR411 is an area for displaying the quantity of products to be paid for (purchased) by price range (over 1,000 yen, between 500 yen and less than 1,000 yen, between 200 yen and less than 500 yen, and less than 200 yen).

The total display area HR412 is an area for displaying the total of the transaction. In the example of FIG. 12, the settlement device 40 displays in the total display area HR412 a total number of points of 3 (indicated as "Total 3 points" in the figure), an estimated total amount of 370 yen (indicated as "Estimated total (amount displayed on smartphone) 370 yen"), and a final total amount of 530 yen (indicated as "Final total (amount to be paid) 530 yen"). The estimated total amount of 370 yen is the total amount displayed on the mobile terminal 60 (the total amount does not include the price of the XX snack (160 yen) that was automatically registered by the settlement device 40; the total amount before recalculation). The final total amount of 530 yen is the total amount recalculated by the settlement device 40 (the total amount including the price of the XX snack (160 yen) that was automatically registered by the settlement device 40).

In this example, the product code "S0275" of XX Snack is not stored in the product master for registration (the price of the product with the product code "S0275" cannot be obtained when registering with the mobile terminal 60), but if the product code "S0275" of XX Snack is stored in the product master for registration (the mobile terminal 60 can obtain the price of the product with the product code "S0275"), both the estimated total amount and the final total amount will be 530 yen. In other words, if the settlement device 40 does not recalculate the total amount, it displays the total amount displayed by the mobile terminal 60 as the estimated total amount and the final total amount in the total display area HR412. If the settlement device 40 recalculates the total amount, it displays the total amount displayed by the mobile terminal 60 (the total amount before recalculation) as the estimated total amount in the total display area HR412, and displays the total amount after recalculation as the final total amount.

In this example, the product code "S0275" of XX Snack is stored in the product master for checkout (the price, etc. of the product with product code "S0275" can be obtained at the time of checkout by the checkout device 40), but if the product code "S0275" of XX Snack is not stored in the product master for checkout (if the price, etc. of the product with product code "S0275" cannot be obtained at the time of checkout by the checkout device 40, in other words, if the NON-FILE cannot be resolved), the store clerk will input the price, etc. at the checkout device 40.

Figure 13 is an example of the display of the settlement device 40 when the checkout button BT409 is operated on the product list screen GM02 of Figure 12. When the checkout button BT409 is operated, the settlement device 40 displays the payment type selection screen GM03 as shown in Figure 13.

The payment type selection screen GM03 has a payment type selection area SR420 and a captured image display area HR421. The payment type selection screen GM03 also has a store clerk call button BT401, a balance inquiry button BT402, language switch buttons BT403 to BT405, and a back button BT419. The back button BT419 is a button for returning to the product list screen GM02.

The payment type selection area SR420 is an area for selecting a payment type (payment method). In the payment type selection area SR420, buttons corresponding to various payment types such as cash, credit card, etc. are arranged.

The captured image display area HR421 is an area for displaying a captured image of the customer. For example, the settlement device 40 may capture an image of the area around the change machine 409 (i.e., the customer's hands operating the change machine 409) using its own camera (imaging unit 416) and display the captured image in the captured image display area HR421, or may display an image captured by an external camera (a camera installed in a position that can capture an image of the area around the change machine 409) in the captured image display area HR421. The captured image displayed in the captured image display area HR421 may be a real-time output of the current situation (live view/through image), or may be a temporarily stored image that is played back. The captured image may be a video or a still image (e.g., still images displayed continuously).

When a payment type is selected on the payment type selection screen (when a button corresponding to a payment type is operated in the payment type selection area SR420), the settlement device 40 displays a payment screen corresponding to the selected payment type and executes the payment corresponding to the selected payment type. For example, when the cash button (cash payment) is operated in the payment type selection area SR420, the settlement device 40 sequentially displays payment screens (payment screens appropriately displaying the finalized total amount, the amount inserted (amount deposited), the shortfall amount, the change amount, various messages, etc.) corresponding to the progress of the customer's actions related to the cash payment (button operation, cash insertion, etc.), executes the payment process based on the confirmation operation on the payment screen (operation to execute the payment process), dispenses the change if there is any, and prints and issues a receipt. For example, when the credit button (an example of a non-cash payment) is operated in the payment type selection area SR420, the settlement device 40 sequentially displays payment screens (payment screens appropriately displaying the finalized total amount, number of payments, PIN number, various messages, etc.) according to the progress of the customer's actions (button operation, card insertion, etc.) related to the non-cash payment by the card payment unit 408, and causes the card payment unit 408 to execute the payment process (or the settlement device 40 itself executes the payment process) based on the confirmation operation on the payment screen, and prints and issues a receipt.

(Example of Operation of Settlement Device 40 (Transaction Example 2))
For example, when a customer has the settlement device 40 read the two-dimensional settlement code 605 (two-dimensional settlement code 605 shown in Figure 7 (D)) displayed on the mobile terminal 60 after registering the product in transaction example 2 (Figures 7 (A) to 7 (C)), the settlement device 40 obtains transaction information from the cloud server 20, including XX gyoza (product code "S0123", product name "XX gyoza", 1 item, ¥290) as the first product, XX stir fry (product code "S0144", product name "XX stir fry", 1 item, ¥420) as the second product, and XX socks (product code "S0597", product name "XX socks", 3 items, ¥900) as the third product.

The settlement device 40 does not update the transaction information related to the NON-FILE product because the transaction information does not include the NON-FILE product.

The settlement device 40 then refers to the sale file (FIG. 3B) and determines whether the product included in the transaction information matches the sale conditions. The settlement device 40 determines that the product matches the sale conditions (specifically, matches the sale conditions for sale code "T003"), obtains the sale details (sale price "¥800" for sale code "T003") from the sale file, and recalculates the total amount "¥1510". The settlement device 40 then stores the sale price of the target product ("¥800" for three pairs of ○○ socks) in the transaction information without erasing the price of the target product before the sale price was applied ("¥900" for three pairs of ○○ socks), and stores the total amount after recalculation "¥1510" without erasing the total amount before recalculation "¥1610".

(Display example of settlement device 40 (transaction example 2))
Fig. 14 is an example of the display of the settlement device 40 when the two-dimensional settlement code 605 shown in Fig. 7(D) is read on the initial screen GM01 of Fig. 10. When the settlement device 40 reads the two-dimensional settlement code 605 of Fig. 7(D), it displays a product list screen GM02 as shown in Fig. 14.

In the example of FIG. 14, the settlement device 40 displays XX Gyoza, XX Stir Fry, and XX Socks in the product list display area HR410. XX Gyoza is the first product in transaction example 2 (FIG. 7(A)). XX Stir Fry is the second product in transaction example 2 (FIG. 7(B)). XX Socks is the third product in transaction example 2 (FIG. 7(C)). In addition, the icon ICN417 displayed in association with XX Socks indicates that the product is sold at a special sale price.

In the example of FIG. 14, the settlement device 40 displays in the total display area HR412 a total of 5 points (shown as "5 points total" in the figure), an estimated total of 1610 yen (shown as "Estimated total (amount displayed on smartphone) ¥1610" in the figure), a final total of 1510 yen (shown as "Final total (amount to be paid) ¥1510" in the figure), and the difference between the estimated total and the final total, in this example, -100 yen (shown as "-¥100" in the figure) obtained by subtracting the estimated total from the final total. The estimated total of 1610 yen is the total amount displayed on the mobile terminal 60 (the total amount before recalculation). The final total amount of 1510 yen is the total amount recalculated by the settlement device 40.

The settlement device 40 can display the details of the sale applied to an item to which a special sale price has been applied (such socks in transaction example 2). For example, the settlement device 40 displays the details of the sale applied to an item to which a special sale price has been applied based on an operation.

Figure 15 shows an example of the display on the settlement device 40 when the area for XX socks to which a special sale price has been applied is operated in the product list display area HR410 of the product list screen GM02 in Figure 14 (for example, when the icon ICN417 is operated).

When the area of the XX socks to which a sale price has been applied is operated, the settlement device 40 enlarges the area as shown in FIG. 15, makes the sale details display area HR418 appear within the enlarged area, and displays the details of the sale applied to the XX socks in the sale details display area HR418 (in this example, "100 yen off for every three XX socks (¥900 → ¥800)"). When the close button located in the sale details display area HR418 is operated, the settlement device 40 reduces the XX socks area to its original display (and erases the sale details display area HR418) (as shown in FIG. 15 → FIG. 14).

The payment type selection screen GM03 that is displayed when the Checkout button BT409 is operated on the product list screen GM02 of FIG. 14 or FIG. 15 has the same configuration as the payment type selection screen GM03 (FIG. 13) that is displayed when the Checkout button BT409 is operated on the product list screen GM02 of FIG. 12, so illustrations and explanations are omitted.

(Example of Operation of Settlement Device 40 (Transaction Example 3))
For example, when a customer has the settlement device 40 read the settlement two-dimensional code 605 (the settlement two-dimensional code 605 shown in FIG. 8(D)) displayed on the mobile terminal 60 after registering the product of transaction example 3 (FIGS. 8(A) to 8(C)), the settlement device 40 acquires transaction information from the cloud server 20 including XX bento (product code "S0175", product name "XX bento", 1 item, 620 yen) as the first product, XX green tea (product code "S0215", product name "XX green tea", 1 item, 130 yen) as the second product, and XX salad (product code "S0170", product name "XX salad", 1 item, 280 yen) as the third product. It is assumed that the time is after 8 p.m.

The settlement device 40 does not update the transaction information related to the NON-FILE product because the transaction information does not include the NON-FILE product.

Next, the settlement device 40 refers to the sale file (Figure 3 (B)) and determines whether the product included in the transaction information matches the sale conditions. The settlement device 40 determines that the sale conditions match (specifically, the sale conditions for sale code "T002" and sale code "T004"), obtains the sale details (sale price "30 yen off" for sale code "T002", 30 yen off and 50 yen off for sale code "T0004") from the sale file, and recalculates the total amount "920 yen". Then, the settlement device 40 stores the sale prices of the target products ("¥555" for the XX bento, "¥115" for the XX green tea, and "¥250" for the XX salad) in the transaction information without erasing the prices of the target products before the sale price was applied ("¥620" for the XX bento, "¥130" for the XX green tea, and "¥280" for the XX salad), and stores the total amount after the recalculation of "¥920" without erasing the total amount before the recalculation of "¥1,030."

(Display example of settlement device 40 (transaction example 3))
Fig. 16 is an example of the display of the settlement device 40 when the two-dimensional settlement code 605 shown in Fig. 8(D) is read on the initial screen GM01 of Fig. 10. When the settlement device 40 reads the two-dimensional settlement code 605 of Fig. 8(D), it displays a product list screen GM02 as shown in Fig. 16.

The settlement device 40 reads the settlement two-dimensional code 605 in FIG. 8 (D) to obtain transaction information for the transaction (the transaction in which the mobile terminal 60 registered the product in transaction example 3) from the cloud server 20.

In the example of FIG. 16, the settlement device 40 displays XX bento, XX green tea, and XX salad in the product list display area HR410. XX bento is the first product in transaction example 3 (FIG. 8(A)). XX green tea is the second product in transaction example 3 (FIG. 8(B)). XX salad is the third product in transaction example 3 (FIG. 8(C)). Icons ICN417 displayed in association with each of XX bento, XX green tea, and XX salad indicate that a special sale price has been applied to these products.

In the example of FIG. 16, the settlement device 40 displays in the total display area HR412 a total of 3 points (shown as "Total 3 points" in the figure), an estimated total of 1,030 yen (shown as "Estimated total (amount displayed on smartphone) ¥1,030" in the figure), a final total of 920 yen (shown as "Final total (amount to be paid) ¥920" in the figure), and a difference of -110 yen (shown as "-¥110" in the figure) obtained by subtracting the estimated total from the final total amount. The estimated total amount of 1,030 yen is the total amount displayed on the mobile terminal 60. The final total amount of 920 yen is the total amount recalculated by the settlement device 40.

Figure 17 is an example of the display of the settlement device 40 when the areas of XX bento, XX green tea, and XX salad, to which a special sale price has been applied, are all operated in the product list display area HR410 of the product list screen GM02 of Figure 16. As shown in Figure 17, the settlement device 40 displays the details of the sale applied to the XX bento when the XX bento area is operated, displays the details of the sale applied to the XX green tea when the XX green tea area is operated, and displays the details of the sale applied to the XX salad when the XX salad area is operated.

The payment type selection screen GM03 that is displayed when the Checkout button BT409 is operated on the product list screen GM02 of FIG. 16 or FIG. 17 has the same configuration as the payment type selection screen GM03 (FIG. 13) that is displayed when the Checkout button BT409 is operated on the product list screen GM02 of FIG. 12, so illustrations and explanations are omitted.

Figure 18 is a sequence diagram showing an example of the processing of the settlement device 40 and cloud server 20. Specifically, the sequence diagram of Figure 18 shows an example of the processing of the settlement device 40 and cloud server 20 from when the settlement two-dimensional code 605 is read by the settlement device 40 to when the payment type selection screen GM03 is displayed. The left side of Figure 18 shows the processing of the settlement device 40, and the right side shows the processing of the cloud server 20. It should be noted that at the start of the sequence diagram of Figure 18, the settlement device 40 is displaying the initial screen GM01 as shown in Figure 10.

Step S11: In response to a reading operation by the customer, the settlement device 40 reads the settlement two-dimensional code 605 displayed on the mobile terminal 60. That is, the settlement device 40 obtains transaction identification information that identifies the transaction information of the transaction.
Step S12: The settlement device 40 requests transaction information of the transaction from the cloud server 20. For example, the settlement device 40 transmits request information (transaction information acquisition request information) including transaction identification information that identifies the transaction information of the transaction to the cloud server 20.

Step S13: The cloud server 20 receives the request (transaction information acquisition request information).
Step S14: In response to the request, the cloud server 20 transmits the transaction information of the transaction to the settlement device 40. For example, the cloud server 20 transmits to the settlement device 40 the transaction information corresponding to the transaction identification information included in the transaction information acquisition request information received in step S13.

Step S15: The settlement device 40 receives and stores the transaction information of the transaction.
Step S16: If a NON-FILE product is included, the settlement device 40 refers to the settlement product master, and if the product code is stored in the settlement product master, obtains the product name, price, etc. of the product, recalculates the total amount, and reflects it in the transaction information (additionally stores it). The details of step S16 have already been explained in "Processing for NON-FILE Products", so they will be omitted here.

Step S17: The settlement device 40 refers to the sale file, and if the sale conditions are met, obtains the details of the sale (sale price, etc.), recalculates the total amount, and reflects this in the transaction information (additionally stores it). Details of step S17 have already been explained in "Processing related to sale prices," so they will be omitted here.

Step S18: The settlement device 40 displays the product list screen GM02 based on the transaction information. For example, in transaction example 1, the settlement device 40 displays the product list screen GM02 as shown in FIG. 11, in transaction example 2, the product list screen GM02 as shown in FIG. 14, and in transaction example 3, the product list screen GM02 as shown in FIG. 16. Note that, since FIG. 11 shows a scene after the processing of step S19 (described later), the small screen SG10 displayed in step S19 is displayed in front of the product list screen GM02 displayed in step S18.
Step S19: When the settlement device 40 resolves the NON-FILE, it notifies the user that the NON-FILE has been automatically resolved (that the NON-FILE product has been automatically registered). For example, the settlement device 40 displays a small screen SG10 as shown in FIG. 11 on the front of the product list screen GM02.

Step S20: The settlement device 40 displays the payment type selection screen GM03 based on the customer's confirmation operation (operation of the checkout button BT409 on the product list screen GM02). Then, the sequence diagram in FIG. 18 ends.

Figure 19 is a sequence diagram showing an example of the processing of the settlement device 40, the store controller 30, the headquarters server 10, the cloud server 20, and the mobile terminal 60. Specifically, the sequence diagram of Figure 19 shows an example of the processing of the settlement device 40, the store controller 30, the headquarters server 10, the cloud server 20, and the mobile terminal 60 after the display of the payment type selection screen GM03 in the settlement device 40. The leftmost part of Figure 19 shows the processing of the settlement device 40, the second from the left shows the processing of the store controller 30, the third from the left (middle) shows the processing of the headquarters server 10, the fourth from the left (second from the right) shows the processing of the cloud server 20, and the rightmost part shows the processing of the mobile terminal 60. Note that at the start of the sequence diagram of Figure 19, the settlement device 40 is displaying the payment type selection screen GM03 as shown in Figure 13.

Step S31: The settlement device 40 executes the settlement process based on the customer's operation (confirmation operation on the settlement screen). That is, the settlement device 40 displays a settlement screen according to the payment type selected on the settlement type selection screen GM03, and executes the settlement process based on the confirmation operation on the settlement screen.

Step S32: The settlement device 40 transmits payment information (transaction result information) to the store controller 30. Furthermore, if the NON-FILE has been resolved, the settlement device 40 transmits NON-FILE resolution information to the store controller 30 in addition to the payment information. The payment information includes, for example, transaction identification information, detailed information (product code, quantity), payment method, payment amount, etc. The NON-FILE resolution information is information indicating that the NON-FILE has been resolved (that the NON-FILE has been resolved), and includes, for example, the product code, product name, price, etc. The settlement device 40 may transmit the NON-FILE resolution information to the store controller 30 as part of the payment information.

Step S33: In the case of cash settlement, if there is change, the settlement device 40 dispenses the change.
Step S34: The settlement device 40 prints and issues a receipt. The settlement device 40 may be provided with a sensor capable of detecting the removal of change, and may print and issue a receipt after detecting the removal of the dispensed change when the change is dispensed.
Step S35: The settlement device 40 displays the initial screen GM01. The settlement device 40 may be provided with a sensor capable of detecting removal of a receipt, and may display the initial screen GM01 after detecting removal of an issued receipt.

Step S36: The store controller 30 receives the payment information. In addition to the payment information, the store controller 30 may also receive NON-FILE resolution information.
Step S37: The store controller 30 transmits the payment information to the head office server 10. If the store controller 30 has also received the NON-FILE resolution information, it also transmits the NON-FILE resolution information to the head office server 10.

Step S38: The head office server 10 receives the payment information. In addition to the payment information, the head office server 10 may also receive NON-FILE resolution information.
Step S39: The head office server 10 transmits the payment information to the cloud server 20. If the head office server 10 has also received the NON-FILE resolution information, it transmits the NON-FILE resolution information to the cloud server 20 as well.
Step S40: The headquarters server 10 records the results. For example, the headquarters server 10 updates the results information (sales results information, etc.) based on the payment amount, etc., included in the payment information. The headquarters server 10 also updates the results information (product sales results information, etc.) based on the detailed information, etc., included in the payment information. This information may be compiled and used, for example, for accounting (financial accounting, management accounting), ordering, product development, etc.

Step S41: The cloud server 20 receives payment information. In addition to the payment information, the cloud server 20 may also receive NON-FILE resolution information.
Step S42: The cloud server 20 updates the transaction information of the transaction (stores information related to the completion of settlement). For example, the cloud server 20 identifies the transaction information of the transaction based on the transaction identification information included in the payment information. The cloud server 20 additionally stores information based on the payment method, payment amount, etc. included in the payment information (information related to the payment method, payment amount) in the transaction information of the transaction. Note that while it is possible to determine whether the payment (transaction) is incomplete/completed based on the presence or absence of storage of the payment amount, etc., the cloud server 20 may additionally store information indicating the completion of the payment (transaction completion) in the transaction information of the transaction (note that, if the transaction information includes a processing status classification (status) as a data item, the processing status classification may be updated to a classification (status) indicating the completion of the payment (transaction completion) instead of additionally storing the information).

Step S43: The cloud server 20 transmits payment completion information to the mobile terminal 60 to the effect that the payment (transaction) has been completed.
Step S44: When the cloud server 20 receives the NON-FILE resolution information, the cloud server 20 updates the provisional product file. For example, the cloud server 20 adds the product code, product name, price, etc. included in the NON-FILE resolution information to the provisional product file.

Step S45: The mobile terminal 60 receives the payment completion information.
Step S46: The mobile terminal 60 displays a transaction completion screen (not shown). That is, the mobile terminal 60 switches the display from the two-dimensional code display screen to the transaction completion screen based on receiving the payment completion information. For example, an OK button or the like is provided on the transaction completion screen, and the mobile terminal 60 may erase the transaction completion screen based on the operation of the OK button.

If the estimated total amount and the finalized total amount differ, information about this may be notified on the transaction completion screen displayed by the mobile terminal 60 in step S46. For example, the mobile terminal 60 may display the estimated total amount and the finalized total amount on the transaction completion screen, or may display the estimated total amount, the finalized total amount, and the difference (the difference obtained by subtracting the estimated total amount from the finalized total amount), or may display the finalized total amount and the difference. Also, if a special sale price has been applied, the mobile terminal 60 may display, instead of or in addition to the amounts, etc., on the transaction completion screen, a message to the effect that the special sale price has been applied, the products to which the special sale price has been applied, the details of the sale, etc.

As described above, sales system 1 solves (eliminates or reduces) some of the problems that occur during checkout.

(1) According to the sales system 1, the information required for payment is automatically replenished (or supplemented) at the time of payment. This reduces the burden on store clerks and shortens the payment time.

For example, if NON-FILE products are not automatically registered at checkout, a store clerk is called and the called store clerk is required to register the NON-FILE products. However, in the sales system 1, the checkout device 40 references the product master for checkout, and when it is possible to register a NON-FILE product, it automatically registers the NON-FILE product. This removes the burden on the store clerk. As long as there are at least situations where NON-FILE products are automatically registered (as long as there are fewer situations where NON-FILE products are not automatically registered), this will at least contribute to reducing the burden on the store clerk. In addition, the checkout time is reduced compared to when a store clerk registers a NON-FILE product. As long as there are at least situations where NON-FILE products are automatically registered, this will at least contribute to reducing the checkout time.

(2) According to sales system 1, when information necessary for payment is automatically replenished, the customer is notified of the replenishment. In other words, even when information necessary for payment is automatically replenished, the billing details are clear, so that the customer does not feel uneasy or misunderstood.

For example, when a NON-FILE product is automatically registered, the settlement device 40 notifies the customer that the NON-FILE product has been automatically registered (Figure 11). Therefore, when a NON-FILE product is automatically registered, the customer can easily recognize (understand) that the NON-FILE product has been automatically registered. This prevents the customer from feeling anxious or confused (or at least makes it less likely to happen) as might occur if the customer were not aware of this.

For example, when a NON-FILE product is automatically registered or a special sale price is reflected, the settlement device 40 notifies the customer which product is the target product (the product that was automatically registered or the product to which the special sale price has been applied) (Figures 12, 14, 15, 16, 17). Therefore, when a NON-FILE product is automatically registered or a special sale price is reflected, the customer can easily recognize the target product. This prevents the customer from feeling anxious or confused (or at least makes it less likely to happen) as might occur if the product was not recognized.

For example, when the sale price is reflected, the settlement device 40 notifies the customer of the details of the sale (Figs. 15 and 17). Therefore, when the sale price is reflected, the customer can easily recognize the details of the sale. This prevents the customer from feeling anxious or confused (or at least makes it less likely to happen) if the customer does not recognize the details.

For example, when a NON-FILE product is automatically registered or a sale price is reflected, the settlement device 40 displays the total amount after the NON-FILE product is registered or after the sale price is reflected, together with the total amount before the NON-FILE product was registered or before the sale price was reflected (Figures 12, 14, 15, 16, 17). Therefore, when a NON-FILE product is automatically registered or a sale price is reflected, the customer can easily recognize that the total amount has increased or decreased and the extent of the increase or decrease. This prevents (or at least makes it less likely to cause) the customer anxiety or misunderstanding that could arise if the customer did not recognize the information.

In the above embodiment, transaction example 1 (FIGS. 6, 11, 12, etc.) was used for NON-FILE products, and transaction example 2 (FIGS. 7, 14, 15, etc.) and transaction example 3 (FIGS. 8, 16, 17, etc.) were used for products to which a special sale price is applied. However, when NON-FILE products and products to which a special sale price are mixed in one transaction, each product is processed in the same manner. For example, when the settlement device 40 reads the settlement two-dimensional code 605 for a transaction in which NON-FILE products and products to which a special sale price are mixed in one transaction, if the NON-FILE is resolved, the small screen SG10 is displayed, and if the special sale price is applied, the total amount after the NON-FILE is resolved and the special sale price is applied is recalculated on the product list screen GM02. In addition, the settlement device 40 displays the recalculated total amount (confirmed total amount) together with the estimated total amount, etc., in the total display area HR412 of the product list screen GM02, and adds the icon ICN415 to products for which the NON-FILE has been resolved (i.e. products that have been automatically registered) in the product list display area HR410 of the product list screen GM02, and adds the icon ICN417 to products for which a special sale price has been applied.

(Modifications, etc.)
Although the embodiment has been described above, the device configuration, data configuration, processing flow, display and output modes, etc. can be appropriately changed, for example, as shown in the following (1), (2), .... In addition, the following (1), (2), ... may be appropriately combined.

(1) For example, in the above embodiment, the settlement device 40 was described as automatically reflecting necessary information in the transaction information at the time of settlement (adding and updating necessary information to the transaction information), but the necessary information may be automatically reflected in the transaction information after a customer's confirmation operation. For example, when the settlement device 40 reads the settlement two-dimensional code 605 (for example, the settlement two-dimensional code 605 in FIG. 6(C)) for a transaction including a NON-FILE product, it may display a small screen with a confirmation button (which may display a message indicating that registration will be attempted again because there is a NON-FILE product), and based on the operation of the confirmation button, it may refer to the settlement product master and, if the NON-FILE is resolved, display a small screen SG10 indicating that the NON-FILE product has been automatically registered (indicating that the NON-FILE has been automatically resolved).

(2) In the above embodiment, when a NON-FILE product is automatically registered, the small screen SG10 notifies the user that the NON-FILE product has been automatically registered (FIG. 11), but the manner of notification is not limited to this.

For example, the automatic registration of a NON-FILE product may be notified on the same full screen (whole screen) as the product list screen GM02. Specifically, when the two-dimensional settlement code 605 shown in FIG. 6(C) is read, the settlement device 40 may display a full screen (automatic product registration notification screen) notifying the automatic registration of a NON-FILE product. In addition, an OK button may be provided on the automatic product registration notification screen, and when the OK button is operated, the settlement device 40 may display the product list screen GM02 (FIG. 12) instead of the automatic product registration notification screen. In terms of timing, the notification example using the small screen SG10 is an example in which the display of the small screen SG10 is started during the display of the product list screen GM02 (after the display starts) (steps S18 and S19 in FIG. 18), but the notification example using the automatic product registration notification screen is an example in which the display of the automatic product registration notification screen is started before the display of the product list screen GM02 starts.

For example, it is not necessary to prepare a dedicated screen (small screen SG10, automatic product registration notification screen) for notifying that a NON-FILE product has been automatically registered. Specifically, when the settlement device 40 reads the two-dimensional settlement code 605 shown in FIG. 6(C), the settlement device 40 may display a product list screen GM02 that displays a message or the like to the effect that a NON-FILE product has been automatically registered (a product list screen GM02 in FIG. 12 that displays the above message or the like).

(3) In the above embodiment, when a NON-FILE product is automatically registered, a notification is given that the NON-FILE product has been automatically registered (FIG. 11). However, even when a NON-FILE product is automatically registered, there may be cases where the notification is not given that the NON-FILE product has been automatically registered. For example, when there are multiple NON-FILE products, if all NON-FILE products are automatically registered (if all NON-FILEs are resolved), a notification is given that the NON-FILE products have been automatically registered, and if some NON-FILE products are automatically registered (if some NON-FILEs are not resolved), a notification is not given that the NON-FILE products have been automatically registered.

(4) In the case where there are multiple NON-FILE products and at least some of the NON-FILE products have been automatically registered (when some or all of the NON-FILEs have been resolved), the number of products that were automatically registered (the number of products that were resolved) may be notified. In addition, in the case where there are multiple NON-FILE products and at least some of the NON-FILE products have not been automatically registered (when some or all of the NON-FILEs have not been resolved), the number of products that were not automatically registered (the number of products that were not resolved) may be notified.

(5) In the above embodiment, when a NON-FILE product is automatically registered, the automatically registered product is notified by icon ICN415 (notifying which product is the automatically registered product) (FIG. 12), but the manner of notification is not limited to this. Instead of or in addition to icon ICN415, the automatically registered product may be notified by the size of the product name, the color of the product name, the blinking of the product name, the background of the product name, etc. The same applies when a sale price is applied. That is, in the above embodiment, the product to which the sale price is applied is notified by icon ICN417, but instead of or in addition to icon ICN417, the product to which the sale price is applied may be notified by the size of the product name, the color of the product name, the blinking of the product name, the background of the product name, etc.

(6) In the above embodiment, when a NON-FILE product is automatically registered, the estimated total amount and the finalized total amount are displayed, and the difference obtained by subtracting the estimated total amount from the finalized total amount is not displayed (FIG. 12). However, the display of the total amount when a NON-FILE product is automatically registered is not limited to this. For example, the estimated total amount, the finalized total amount, and the above-mentioned difference may be displayed. Also, the finalized total amount may be displayed, and the estimated total amount and the above-mentioned difference may not be displayed.

(7) In the above embodiment, when the special sale price is reflected, the estimated total amount, the finalized total amount, and the difference obtained by subtracting the estimated total amount from the finalized total amount are displayed (e.g., FIG. 14), but the display of the total amount when the special sale price is reflected is not limited to this. For example, the estimated total amount and the finalized total amount may be displayed, without displaying the difference. Also, the finalized total amount may be displayed, without displaying the estimated total amount and the difference.

(8) In relation to (6) and (7) above, the display of the total amount, etc. is not limited to the display format shown in the above embodiments (Figures 12, 14, 16, etc.).

Figure 20 is an example of the display of the settlement device 40. Each of Figures 20 (A) to 20 (D) shows a portion (lower part) of the product list screen GM02. The settlement device 40 may display, for example, a product list screen GM02 as shown in Figure 20 (A), Figure 20 (B), Figure 20 (C), or Figure 20 (D) instead of the product list screen GM02 of transaction example 2 (product list screen GM02 of Figure 14).

In each example shown in FIG. 20(A) to FIG. 20(D), the settlement device 40 does not display "estimated total amount" but displays "smartphone display amount". In addition, in each example shown in FIG. 20(C) and FIG. 20(D), the settlement device 40 displays "payment amount" instead of "confirmed total amount". In addition, in each example shown in FIG. 20(A) and FIG. 20(B), the settlement device 40 does not display "confirmed total amount" or "payment amount". In addition, for example, in each example shown in FIG. 20(A), FIG. 20(B), and FIG. 20(C), the settlement device 40 displays the confirmed total amount (¥1510) larger than the estimated total amount (¥1610). Note that instead of or in addition to size, the confirmed total amount may be displayed more prominently than the estimated total amount by using text color, flashing, background, etc. Also, for example, in the examples shown in FIG. 20(C) and FIG. 20(D), a speech bubble (or the outer part of the total display area HR412) is used to emphasize the fact that the price has become cheaper. Note that the fact that the price has become cheaper may be emphasized and notified using animation or the like. Also, for example, in the examples shown in FIG. 20(B) and FIG. 20(D), the amount of the reduction (100 yen) is displayed in large letters. Note that instead of or in addition to the size, the amount of the reduction may be emphasized and displayed using the text color, blinking, background, or the like. Also, for example, in the example shown in FIG. 20(C), the reason for the reduction (discount) is notified. Note that the manner of notifying the reason for the reduction is not limited to this. For example, the total display area HR412 may simply display the words "Discount" or "Discount Applied," or a mark, pattern, icon, or the like indicating the discount may be displayed. Note that FIG. 20 shows the case of a special sale, but the same applies to the case of NON-FILE.

(9) In the above embodiment, the sale details applied to a product are displayed on the product list screen GM02 based on the operation of the area of the product to which the sale price is applied (icon ICN417, etc.) (FIGS. 15 and 17), but the operation of displaying the sale details is not limited to this. For example, a difference button (a button displaying the difference) may be placed in the total display area HR412 (i.e., the difference display is made into a button), and the sale details applied to each product may be displayed based on the operation of the difference button. In the example of FIG. 14, a difference button displaying "-￥100" may be placed in the total display area HR412, and when the difference button is operated, the sale details of "XX socks" may be displayed as shown in FIG. 15. In the example of FIG. 16, a difference button displaying "-￥110" may be placed in the total display area HR412, and when the difference button is operated, the sale details of "XX bento", "XX green tea", and "XX salad" may be displayed as shown in FIG. 17. Note that the operation of the area of the product to which the special sale price is applied and the operation of the price difference button may coexist.

(10) In the above embodiment, the product list screen GM02 does not have the language switching buttons BT403 to BT405, but the product list screen GM02 may have the language switching buttons BT403 to BT405. The same applies to the balance inquiry button BT402 and the captured image display area HR421.

(11) In the above embodiment, the flow of sending and receiving information after the settlement process in the settlement device 40 is described as the flow of settlement device 40 → store controller 30 → headquarters server 10 → cloud server 20 → mobile terminal 60 in FIG. 19, but the flow of sending and receiving is not limited to this. For example, NON-FILE resolution information may be sent from settlement device 40 → store controller 30 → cloud server 20 (finally sent to cloud server 20 without passing through headquarters server 10), or from settlement device 40 → cloud server 20 (sent directly to cloud server 20 without passing through store controller 30 and headquarters server 10).

(12) In the above embodiment, when product information corresponding to a product code read by the mobile terminal 60 is not stored in the product master for registration (FIG. 4(A)), the settlement device 40 automatically registers the product information corresponding to the product code by referring to the product master for registration (FIG. 3(A)). However, the automatic registration is not limited to this. For example, when product information corresponding to a product code read by the mobile terminal 60 is stored in the product master for registration (FIG. 4(A)), but the product information cannot be obtained from the product master for registration at the product registration stage (for example, when a communication or processing capacity problem or a software or hardware malfunction occurs), the settlement device 40 may automatically register the product information corresponding to the product code by referring to the product master for registration (FIG. 3(A)). In other words, this is applicable to all situations where a product code is obtained at the product registration stage, but product information corresponding to the product code cannot be obtained.

Note that a product for which product information corresponding to the product code read by the mobile terminal 60 is not stored in the product master for registration and therefore the product information cannot be obtained from the product master for registration at the product registration stage (here, a type 1 unregistered product) and a product for which product information corresponding to the product code read by the mobile terminal 60 is stored in the product master for registration but the product information cannot be obtained from the product master for registration at the product registration stage (here, a type 2 unregistered product) may be collectively referred to as an unregistered product. In addition, in the above embodiment, the type 1 unregistered product is referred to as a "NON-FILE product" and the mobile terminal 60 displays the type 1 unregistered product (NON-FILE product) as an "unregistered product" (FIGS. 6B and 6C), but the mobile terminal 60 may also display the type 2 unregistered product as an "unregistered product" in the same way as the type 1 unregistered product. In other words, at least to the customer, it is not necessary to distinguish between unregistered products of type 1 and unregistered products of type 2. Alternatively, the mobile terminal 60 may distinguish between the two by displaying unregistered products of type 1 as "unregistered products (not registered in master)" and unregistered products of type 2 as "unregistered products (XX abnormality)."

(13) In the above embodiment, the types of sales are exemplified as mix match (sale code "T001"), set match (sale code "T002"), bundle (sale code "T003"), and time service price (sale code "T004") in the sale file shown in FIG. 3(B), but the types of sales are not limited to these. For example, the types of sales may be a discount on a specific product (a fixed or specified product each time) on a specific date (e.g., a specified date each month), a discount based on the total amount, or a discount based on past purchasing history (accumulated (total) purchase amount, etc.).

(14) In the above embodiment, an example was described in which all types of special sales are referenced for the first time at the time of settlement by the settlement device 40 (an example in which special sales are not referenced at all at the time of product registration by the mobile terminal 60), but it may be a mode in which at least some types of special sales are referenced for the first time at the time of settlement by the settlement device 40 (a mode in which some types of special sales are referenced at the time of product registration by the mobile terminal 60). As an example, a special sale file (sale file A) related to bundles (sale code "T003") and time service prices (sale code "T004") is stored in the cloud server 20 for use at the time of registration, and a special sale file (sale file B) related to mix matches (sale code "T001") and set matches (sale code "T002") is stored in the settlement device 40, etc., and the bundles, etc. are reflected at the time of product registration by the mobile terminal 60, and the mix matches, etc. are reflected at the time of settlement by the settlement device 40. In addition, the above-mentioned discounts according to the total amount may be reflected at the time of settlement.

Figures 21 and 22 are examples of displays on the settlement device 40. The settlement device 40 is related to (13) and (15) above, and can display, for example, a product list screen GM02 as shown in Figure 21.

The example shown in FIG. 21 is an example in which a special discount has been applied to the example shown in FIG. 14. The special discount is an example of the discount according to the total amount or the discount according to past purchase history (i.e., sale) described above. In this example, if the cumulative shopping amount of each transaction up to the previous time (for example, the cumulative amount of the confirmed total amount of each transaction since the date) has not reached a predetermined amount (for example, 10,000 yen), but the cumulative shopping amount added with the total amount of the current transaction reaches the predetermined amount, a special discount of 100 yen is applied. The above-mentioned predetermined amount may be set in any number of stages (10,000 yen, 20,000 yen, 30,000 yen, ...) (the discount amount may be different for each stage). In addition, the special discount may be a discount on the entire transaction rather than a discount on a specific product (or a specific group of products), and may be applied, for example, to the first transaction of the month (regardless of transaction amount) when the cumulative shopping amount for the last month was a predetermined amount (for example, 50,000 yen) or more.

Since the special discount is not a discount on a specific product (or a specific group of products) but a discount on the entire transaction, the settlement device 40 displays the special discount in the product list display area HR410 separately from the display of the products (XX dumplings, XX stir fry, XX socks). In the example shown in FIG. 21, the settlement device 40 displays the special discount with a space of one line (one product).

When judging whether the cumulative shopping amount, which is the sum of the total amount of the current transaction, has reached the specified amount, the total amount to be added should be the final total, not the estimated total. Also, when judging whether it is the first transaction of the current month when the cumulative shopping amount for the last month was equal to or more than the specified amount, the conclusion of the transaction (judgment of whether it is a transaction) should be based on at least the stage of proceeding to settlement (the stage after the two-dimensional code 605 for settlement is read). Furthermore, the same applies to the total amount and the conclusion of the transaction in cases where a special discount is given simply based on the total amount of the current transaction. For the above reasons, the special discount is not notified at the registration stage but at the settlement stage (reflected in the final total, not in the estimated total). Since there is no notification at the registration stage, the store side is concerned that the special discount that was given with great effort will not be recognized by the customer, and customers (especially those who are aware that it will be offered) are worried about whether it will be properly given, so the settlement device 40 displays the special discount prominently. In the example shown in FIG. 21, the settlement device 40 displays the special discount prominently, with a space of one line between the discounts. Note that instead of or in addition to the display position (setting the space between the discounts), the special discount may be displayed prominently by using the size, color, blinking, background, etc. of the display.

The settlement device 40 may display the product list screen GM02 shown in FIG. 22(A) and FIG. 22(B) instead of the product list screen GM02 shown in FIG. 21. Note that each of FIG. 22(A) and FIG. 22(B) shows a part of the product list screen GM02 (product list display area HR410). The product list screen GM02 shown in FIG. 22(A) differs from the product list screen GM02 shown in FIG. 21 in that it displays an icon ICN417 in association with a service discount. When the special discount area is operated in the product list display area HR410 of the product list screen GM02 shown in FIG. 22(A) (for example, when the icon ICN417 corresponding to the special discount is operated), the settlement device 40 displays the details of the special discount (in this example, the amount (-￥100) is already displayed in the product list display area HR410, so the condition "Total shopping amount since XX/XX/XX reaches 10,000 yen") as shown in FIG. 22(B).

In addition, in a mode in which the settlement device 40 does not display the icon ICN417 associated with the service discount as shown in FIG. 21, when the service discount area is operated, the settlement device 40 may display the details of the service discount as shown in FIG. 22 (B) (however, the icon ICN417 is not displayed).

(15) In the example shown in FIG. 15, the sale details (100 yen off for every three pairs of XX socks (¥900 → ¥800)) are displayed in the product list display area HR410 based on an operation (such as an operation of icon ICN417), but the sale details may also be displayed on a small screen based on an operation. The same applies to the examples shown in FIG. 17 and FIG. 22(B).

(16) In the example shown in FIG. 14 (similar to FIG. 16 and FIG. 22(A)), it was explained that the details of the sale are displayed by operating the icon ICN417, etc., but it can also be said that the icon ICN417 notifies that the sale price has been applied to the product and at the same time suggests that it can be operated. However, just as the icon ICN415 related to the automatic registration shown in FIG. 12 simply notifies that a NON-FILE product has been automatically registered (it does not suggest that it can be operated), there is a risk that the icon ICN417 may also be recognized as simply notifying that the sale price has been applied to the product. Therefore, when a sale (including a service discount) is applied, the product list screen GM02 may display a message indicating that the sale details can be confirmed by operation (the sale details can be confirmed) (for example, you can confirm the details by touching the discount application icon).

(17) In the above embodiment, an example was described in which the settlement device 40 notifies a store clerk when the NON-FILE is not resolved (by calling the store clerk by illuminating the sign pole 417 and sending a call notification to a device operated by the store clerk), but the circumstances in which the settlement device 40 notifies the store clerk are not limited to this. For example, the settlement device 40 may notify the store clerk when the confirmed total amount is higher than the estimated total amount (when the difference between the confirmed total amount and the estimated total amount is positive).
(a) For example, if the finalized total amount (excluding the prices of products for which the NON-FILE has been resolved if a NON-FILE has occurred at the time of registration) becomes higher than the estimated total amount, that is, if the finalized total amount for products other than the NON-FILE product becomes higher than the estimated total amount for products other than the NON-FILE product, the settlement device 40 may notify the store clerk (such as by sending a notification to a device operated by the store clerk that the finalized total amount is higher than the estimated total amount). Normally, the difference should not be positive for reasons other than NON-FILE, but if the difference is positive for reasons other than NON-FILE, it may be that some problem has occurred (for example, a problem such as the product master or sale file not being updated properly, or the prices, etc. of the product master or sale file being incorrect). In addition, it is difficult (in terms of cost, operation, and technology) to constantly monitor the consistency and validity of information such as prices between servers (e.g., cloud server 20 and headquarters server 10). Therefore, if the difference becomes positive for reasons other than NON-FILE, a notice may be sent to a store clerk to prompt the appropriate action (confirmation, necessary maintenance, etc.).
(b) For example, the settlement device 40 may also notify a store clerk when a NON-FILE is resolved (send a NON-FILE resolution notice including the name of the relevant product to a device operated by the store clerk). This allows the store clerk to know that a NON-FILE has occurred (and the relevant product) and that it has been resolved, and the store can grasp the situation regarding the occurrence of a NON-FILE, and therefore can consider the need for improvements in, for example, the frequency and timing of updates of the registration product master in the cloud server 20 (the frequency and timing at which the cloud server 20 receives the settlement product master and stores it as the registration product master).

(18) The product master for registration shown in FIG. 4(A) is a product master for registration in which the product code, product name, and price are stored as a set in all records (rows), but it is also possible to use a product master for registration that includes records in which the product code is stored but the product name and price are not stored. In other words, the product master for registration shown in FIG. 4(A) is such that if a product code is stored, product information corresponding to that product code can always be obtained, but it is also possible to use a product master for registration in which even if a product code is stored, it is sometimes not possible to obtain product information corresponding to that product code. The same applies to the provisional product file in FIG. 4(B) and the product master for checkout in FIG. 3(A).

When using a registration product master or a provisional product file in which the product code, product name, and price are stored as a set in all records (rows), such as the registration product master in FIG. 4(A) or the provisional product file in FIG. 4(B), the settlement device 40 may determine whether or not it is a NON-FILE based on whether or not the product code read by the mobile terminal 60 is stored, or may determine whether or not it is a NON-FILE based on whether or not product information corresponding to the product code read by the mobile terminal 60 is stored. On the other hand, when using a registration product master or a provisional product file that includes records in which the product code is stored but the product name and price are not stored, the settlement device 40 cannot accurately determine whether or not it is a NON-FILE based on whether or not the product code read by the mobile terminal 60 is stored, so it determines whether or not it is a NON-FILE based on whether or not product information corresponding to the product code read by the mobile terminal 60 is stored.

(19) In the above embodiment, it was explained that the product master for registration is older than the product master for checkout because information reflected in the product master for registration may not be reflected in the product master for registration. However, the product master for registration does not have to be older than the product master for checkout. Specifically, the product master for registration and the product master for checkout may be the same. Even if the product master for registration and the product master for checkout are the same, depending on the timing (the timing of reading the product code, updating the product master, and starting checkout), a NON-FILE may occur when a product is registered, and be resolved at checkout, just as when the product master for registration is older than the product master for checkout.

For example, in the case of the following timings (time 1 to time 3; time 2 is later than time 1, and time 3 is later than time 2), even if the product master for registration and the product master for checkout are identical, a NON-FILE occurs when the product is registered and is resolved at checkout. Note that at time 2, both product masters (product master for registration, product master for checkout) are updated, and new product information for product A is added to both product masters.
(Time 1) Based on a reading operation by a certain customer K, the portable terminal 60 reads the product code attached to the product A. The product master for registration is referenced, and the product A becomes a NON-FILE product.
(Time 2) Product information for Product A is added to both product masters. At Time 2, Customer K is selecting a product in the store.
(Time 3) Based on the reading operation of customer K, the settlement device 40 reads the settlement two-dimensional code 605 for the transaction including the NON-FILE product A. The settlement product master is referenced, and the NON-FILE for product A is resolved.

(20) In the above embodiment, when the automatic registration process is executed (when the NON-FILE is resolved), an example is described in which the settlement device 40 sends NON-FILE resolution information and the temporary product file is updated (FIG. 19). However, it is also possible to update the product master for registration without providing a temporary product file. In other words, if a product becomes a NON-FILE when the product is registered by the mobile terminal 60 and the NON-FILE is resolved for that product during settlement by the settlement device 40, it is sufficient that the result of the resolution is reflected in the master or file referenced when the product is registered by the mobile terminal 60 so that the product does not become a NON-FILE when the product is subsequently registered by the mobile terminal 60.

(21) In the above embodiment, an example of identifying a product from a barcode attached to the product (i.e., by image recognition of a captured image of the barcode portion) has been described, but the method of identifying a product is not limited to this. For example, a product may be identified from the product's appearance (i.e., by image recognition of a captured image of the product's appearance). Also, a product may be identified from an electronic tag attached to the product (or a display shelf) by, for example, equipping the mobile terminal 60 with an electronic tag recognition unit that recognizes information on an electronic tag.

(Aspect of identifying a product from its appearance)
There are several possible configurations for identifying a product from its appearance, depending on, for example, where image recognition of a captured image of the product's appearance is performed and what is obtained as a result of performing the image recognition.
(Configuration a) Configuration a is a configuration in which the mobile terminal 60 performs image recognition and acquires a product code (JAN code, etc.) as a result of the image recognition. In the case of configuration a, for example, information indicating the correspondence between the image recognition result (or information to be compared with the image recognition result; the same applies below) and the product code is stored in a device that the mobile terminal 60 can refer to (for example, each mobile terminal 60). The mobile terminal 60 captures an image of the exterior of the product, performs image recognition on the captured image, and acquires the product code based on the image recognition result (i.e., identifies the product).
(Configuration b) Configuration b is a configuration in which the mobile terminal 60 performs image recognition, and acquires, as a result of the image recognition, identification information of a system different from the product code (identification information from which one product code can be acquired from one piece of identification information). In the case of configuration b, for example, information indicating the correspondence between the image recognition result and the identification information is stored in a device that the mobile terminal 60 can refer to (for example, each mobile terminal 60), and information indicating the correspondence between the identification information and the product code is stored in the cloud server 20. The mobile terminal 60 captures an image of the exterior of the product, performs image recognition on the captured image, acquires the above-mentioned identification information based on the image recognition result, and transmits the acquired identification information to the cloud server 20. The cloud server 20 acquires the product code from the identification information acquired from the mobile terminal 60 (i.e., identifies the product).
(Configuration c) Configuration c is a configuration in which the cloud server 20 performs image recognition and acquires a product code as a result of the image recognition. In the case of configuration c, for example, information indicating the correspondence between the image recognition result and the product code is stored in the cloud server 20. The mobile terminal 60 captures an image of the exterior of the product and transmits the captured image to the cloud server 20. The cloud server 20 performs image recognition on the captured image acquired from the mobile terminal 60 and acquires a product code based on the image recognition result (i.e., identifies the product).

In addition, for the purpose of settlement, information showing the above-mentioned correspondence may also be stored in devices that the settlement terminal 40 can refer to (e.g., each settlement device 40, the store controller 30, the headquarters server 10, etc.). The same applies to the aspect of identifying products from electronic tags.

(Aspects of identifying products from electronic tags)
There are several possible configurations for identifying a product from an electronic tag, depending on, for example, what is acquired from the electronic tag (what information the electronic tag stores).
(Configuration a) Configuration a is a configuration in which a product code (JAN code, etc.) is obtained from an electronic tag. In the case of configuration a, the product code is stored in the electronic tag. The mobile terminal 60 obtains the product code from the electronic tag (i.e., identifies the product).
(Configuration b) Configuration b is a configuration in which identification information of a different system from the product code (identification information that allows one product code to be obtained from one identification information) is obtained from the electronic tag. In the case of configuration b, the identification information is stored in the electronic tag. Configuration b is classified into a configuration (configuration b1) in which the mobile terminal 60 stores information indicating the correspondence between the identification information and the product code, and a configuration (configuration b2) in which the cloud server 20 stores information indicating the correspondence. In the former case (configuration b1), the mobile terminal 60 obtains the identification information from the electronic tag and obtains the product code from the obtained identification information (i.e., identifies the product). In the latter case (configuration b2), the mobile terminal 60 obtains the identification information from the electronic tag and transmits the obtained identification information to the cloud server 20. The cloud server 20 obtains the product code from the identification information obtained from the mobile terminal 60 (i.e., identifies the product).

(22) In the above embodiment, an example was described in which the product master (product master for registration) stored in the cloud server 20 is referenced when registering a product, and the product master (product master for registration) stored in the settlement device 40, the store controller 30, or the headquarters server 10 is referenced as necessary when settling. However, the mobile terminal 60 may store the product master for registration (the mobile terminal 60 may store the product master for registration instead of or in addition to the cloud server 20), and the mobile terminal 60 may reference the product master for registration in its own device when registering a product, and a product for which product information cannot be obtained from the product master for registration in its own device may be treated as a NON-FILE product.

As an example, in the aspect of identifying a product from its appearance (21) (for example, configuration a), the mobile terminal 60 stores a product master for registration instead of or in addition to the cloud server 20, and after image recognition, the mobile terminal 60 refers to the image recognition database in its own device (information showing the above correspondence, product master for registration), and if product information cannot be obtained from the image recognition database in its own device, it may treat the product as a NON-FILE. Note that if the mobile terminal 60 cannot obtain product information from the image recognition database in its own device, it may refer to the image recognition database stored in the cloud server 20. Whether or not to refer to the image recognition database stored in the cloud server 20 when product information cannot be obtained from the image recognition database in its own device may be determined taking into consideration the response time (time is already required for image recognition, etc.) and the possibility of obtaining product information from the image recognition database stored in the cloud server 20.

(23) In the above embodiment, an example was described in which a customer registers a product using a mobile terminal 60. However, the device does not have to be a mobile terminal 60, as long as it is a mobile (portable) device that can register products at the product display location. For example, products may be registered using a tablet terminal lent to customers by the store, or a shopping cart with a display unit (or a display device that can be attached and detached to the shopping cart). The shopping cart may be equipped with an electronic tag recognition unit that recognizes information from an electronic tag.

(24) Some or all of the functions (input/output, storage, processing (including judgment)) of the settlement device 40 in the above embodiment may be realized in a device other than the device described as the executing entity of the function. For example, at least some of the processes described using the sequence diagrams of Figures 18 and 19 as the processing of the settlement device 40 may be executed by the store controller 30 or the cloud server 20 instead of the settlement device 40. In relation to the above, the settlement device 40 may function as a so-called thin client specialized for input/output interfaces, etc. For example, the settlement device 40 may accept various inputs (customer operations, detection by a device such as a scanner) and transmit the input information (operation information, image information, etc.) to the cloud server 20, and then the cloud server 20 may execute processing according to the information received from the settlement device 40 and transmit the processing result (update screen information, etc.) to the settlement device 40, and then the settlement device 40 may execute an operation according to the information received from the cloud server 20 (display on a display unit, etc.). In other words, the cloud server 20 may execute a program for controlling the operation of the settlement device 40.

<Overview of the embodiment>
[Technical field]
The present invention relates to a product sales data processing system and a settlement device.
[Background Art]
A system has been proposed in which customers themselves can register products using mobile terminals (see, for example, Japanese Patent Application Laid-Open No. 2003-233694).
[Prior Art Literature]
[Patent Documents]
[Patent Document 1] JP 2018-055700 A [Summary of the Invention]
[Problem to be solved by the invention]
However, various problems may occur during payment after product registration (e.g., burden on store clerks, anxiety of customers, etc.) The present invention has been made in consideration of such circumstances, and aims to provide a technique for solving various problems during payment in a system in which customers themselves register products using mobile terminals.
[Means for solving the problems]
(A1) A product sales data processing system for registering a product using a portable registration device (e.g., a mobile terminal 60) operated by a customer, the system comprising: registration means (e.g., registration by the mobile terminal 60) for executing a registration process for acquiring product information corresponding to an identified product code (e.g., a product code identified from a barcode, a product code identified from the appearance of a product, a product code identified from an electronic tag, etc.) from a first product information database (e.g., a product master for registration in FIG. 4(A)) and registering the product; settlement means (e.g., settlement process by the settlement device 40) for executing a settlement process by referring to the product information after the registration process by the registration means is completed (e.g., after the button BT604 for proceeding to checkout is operated); and notification means for notifying a customer; When a product code is identified but product information corresponding to the product code cannot be obtained from the first product information database (for example, when there is a NON-FILE product), the means can further execute an automatic registration process (for example, the process of step S16 in FIG. 18) to obtain product information corresponding to the product code from a second product information database (for example, the product master for checkout in FIG. 3(A)) without any operation (for example, without the need for a store clerk to enter product information) and register the product, and the notification means is a product sales data processing system characterized in that when the automatic registration process is executed, the notification means automatically notifies that a product has been registered (for example, by displaying the small screen SG10 in FIG. 11 or displaying the icon ICN415 in FIG. 12).
According to the configuration of (A1), the information required for settlement is automatically replenished (or complemented), thereby reducing the burden on store clerks and shortening the settlement time.

(A2) The product sales data processing system described in (A1) is characterized in that, when the automatic registration process is executed, the notification means begins to notify the user that there are products that have been automatically registered before a list screen (e.g., product list screen GM02) for checking the products to be settled is displayed, or while the list screen is displayed.
According to the configuration of (A2), it is possible to preferably notify the user that there is a registered product automatically.

(A3) A product sales data processing system as described in (A1) or (A2), characterized in that when the automatic registration process is executed, the notification means notifies (for example, by icon ICN415 as shown in Figure 12) which products have been automatically registered on a list screen for checking the products to be settled.
According to the configuration of (A3), it is possible to preferably notify which products are automatically registered products.

(A4) A product sales data processing system described in any of (A1) to (A3), characterized in that when the automatic registration process is executed, the notification means notifies at least the payment amount, which is the total amount of the products registered in the registration process by the registration means plus the amount of the products registered in the automatic registration process by the settlement means (for example, by displaying a ``confirmed total (payment amount)'' as shown in Figure 12).
According to the configuration of (A4), even if the information required for settlement is automatically supplemented, the billing details (final payment amount) are clear, so that the customer is not caused unnecessary anxiety or misunderstanding.

(A5) A product sales data processing system as described in any of (A1) to (A4), further comprising a store clerk call means capable of executing a store clerk call process to call a store clerk when, after the registration process by the registration means is completed, there is a product whose product code has been identified but product information corresponding to the product code cannot be obtained from the first product information database, and the store clerk call means is characterized in that, if, at the time the registration process by the registration means is completed, there is a product whose product code has been identified but product information corresponding to the product code cannot be obtained from the first product information database, the store clerk call means does not execute the store clerk call process when the automatic registration process has been performed for all of the product, and executes the store clerk call process when the automatic registration process has not been performed for at least some of the product.
According to the configuration of (A5), a store clerk can be conveniently called. The latter part of (A5) (i.e., "When there exists a product whose product code has been specified but whose product information corresponding to the product code cannot be obtained from the first product information database at the time when the registration process by the registration means is completed, the store clerk call means does not execute the store clerk call process when the automatic registration process is performed for all of the products, and executes the store clerk call process when the automatic registration process is not performed for at least some of the products") describes the cases where there is one product that could not be obtained and the cases where there are multiple products that could not be obtained. In other words, the latter part indicates that (a) when there are multiple products that could not be obtained, the store clerk call process is not executed when the automatic registration process is performed for all of the multiple products, and the store clerk call process is executed when the automatic registration process is not performed for at least some of the multiple products, and (b) when there is a single product that could not be obtained, the store clerk call process is not executed when the automatic registration process is performed for the product, and the store clerk call process is executed when the automatic registration process is not performed for the product.

(A6) A product sales data processing system described in any of (A1) to (A5), characterized in that, when the automatic registration process is executed, the notification means separately notifies an estimated total amount, which is the total amount of the products registered in the registration process by the registration means, and a payment amount, which is the estimated total amount plus the amount of the products registered in the automatic registration process by the settlement means (for example, displaying an "estimated total (amount displayed on smartphone)" and a "final total (amount to be paid)" as shown in Figure 12).
According to the configuration of (A6), even if the information required for settlement is automatically filled in, the accounting details (total amount at the time of registration, final payment amount) are clear, so that the customer is not caused unnecessary anxiety or misunderstanding.

(A7) A product sales data processing system described in any of (A1) to (A6), characterized in that when the automatic registration process is executed, the settlement means transmits product information of products registered in the automatic registration process (e.g., products for which NON-FILE has been resolved) to be stored in the first product information database.
According to the configuration of (A7), NON-FILE will not occur for the product from the next time, which reduces the burden on the store clerk and shortens the checkout time. In addition, the product will not be registered as an unregistered product when registering the product on the mobile terminal 60 from the next time, which is easy for the customer to understand.

(A8) A product sales data processing system for registering a product using a portable registration device (e.g., a mobile terminal 60) operated by a customer, the system comprising: a first registration means (e.g., a registration process by the mobile terminal 60) for executing a registration process for obtaining product information corresponding to an identified product code (e.g., a product code identified from a barcode, a product code identified from the appearance of a product, a product code identified from an electronic tag, etc.) from a first product information database (e.g., a product master for registration in FIG. 4(A)) and registering the product; a settlement means (e.g., a settlement process by the settlement device 40) for executing a settlement process by referring to the product information after the registration process by the first registration means is completed (e.g., after the “Proceed to checkout” button BT604 is operated); and a second product information processing means (e.g., a settlement process by the settlement device 40) for obtaining product information corresponding to the identified product code from a second product information database (e.g., a product master for registration in FIG. 4(A)) after the registration process by the first registration means is completed and before the settlement process by the settlement means is started. a second registration means (e.g., a registration process by a payment device 40) for executing a registration process to obtain product information from a product master for checkout in FIG. 3 (A) and register the product, and a notification means for notifying a customer, wherein the second registration means is capable of executing an automatic registration process (e.g., the process of step S16 in FIG. 18) to obtain product information corresponding to the product code from the second product information database and automatically register the product when a product code has been identified but the product code could not be registered by the first registration means (e.g., a NON-FILE product), without requiring any operation (e.g., without the need for a store clerk to input product information), and the notification means notifies a customer that a product has been automatically registered when the automatic registration process has been executed (e.g., by displaying the small screen SG10 in FIG. 11 or displaying the icon ICN415 in FIG. 12).
According to the configuration (A8), the information required for settlement is automatically replenished (or complemented), reducing the burden on store clerks and shortening the settlement time.

(A9) A settlement device that settles for goods registered by a portable registration device that executes a registration process to obtain product information corresponding to an identified product code from a first product information database and register the product, comprising: a settlement means that executes the settlement process by referring to the product information after the registration process by the portable registration device is completed; and a notification means that notifies a customer; wherein the settlement means is further capable of executing an automatic registration process to obtain product information corresponding to the product code from a second product information database and register the product without any operation when a product code is identified but product information corresponding to the product code cannot be obtained from the first product information database; and wherein the notification means automatically notifies that a product has been registered when the automatic registration process is executed.
According to the configuration of (A9), the information required for settlement is automatically replenished (or complemented), thereby reducing the burden on store clerks and shortening the settlement time.

(A10) A settlement device that settles for goods registered by a portable registration device that obtains product information corresponding to an identified product code from a first product information database and registers the product, comprising: a settlement means that executes a settlement process by referring to the product information after the registration of the product by the portable registration device is completed; a registration means that obtains product information corresponding to the identified product code from a second product information database and registers the product after the registration of the product by the portable registration device is completed and before the settlement process by the settlement means begins; and a notification means that notifies a customer; wherein the registration means is capable of executing an automatic registration process that, when a product code has been identified but the product could not be registered in the portable registration device, obtains product information corresponding to the product code from the second product information database without any operation and automatically registers the product, and the notification means notifies a customer that a product has been automatically registered when the automatic registration process has been executed.
According to the configuration of (A10), the information required for settlement is automatically replenished (or complemented), thereby reducing the burden on store clerks and shortening the settlement time.

(B1) A product sales data processing system including a portable registration device (e.g., a mobile terminal 60) that registers products through operation by a customer, and a settlement device (e.g., a settlement device 40) that settles the registered products, wherein the portable registration device has a registration means that executes a registration process to register product information including price information of an identified product (e.g., a product identified from a barcode, a product identified from its appearance, a product identified from an electronic tag, etc.), and the settlement device has a settlement means that settles based on the product information and a display means that displays information related to the settlement, and the display means displays (in a total display area HR412 as shown in Figures 14, 16 and 20) an estimated total amount based on the product information at the end of the registration process by the registration means and a confirmed total amount which is the amount to be settled by the settlement means.
According to the configuration of (B1), even if the product information is changed, the billing details (the total amount at the time of registration, the final payment amount) are clear, so that the customer is not caused unnecessary anxiety or misunderstanding.

(B2) In a product sales data processing system including a portable registration device (e.g., a mobile terminal 60) that registers products through operation by a customer, and a settlement device (e.g., a settlement device 40) that settles the payment for the registered products, the portable registration device has a registration means that executes a registration process to register product information including price information of a specified product, and the settlement device has an acquisition means that acquires the product information after the registration process by the registration means is completed (e.g., after the operation of a proceed to checkout button BT604), and a payment device that acquires the product information based on the product information after the registration process by the registration means is completed. a change means (e.g., processing of step S17 in FIG. 18) that can change the product information (e.g., change to a sale price) before settlement by the settlement means, and a display means that displays information related to the settlement, wherein when the product information is changed by the change means, the display means displays (in total display area HR412 as shown in FIG. 14, FIG. 16, or FIG. 20) an estimated total amount based on the product information before the change and a final total amount based on the product information after the change.
According to the configuration of (B2), even if the product information is changed, the billing details (the total amount at the time of registration, the final payment amount) are clear, so that the customer is not caused unnecessary anxiety or misunderstanding.

(B3) A product sales data processing system as described in (B1) or (B2), characterized in that the display means displays the difference between the estimated total amount and the final total amount (for example, the discount amount due to a special sale as shown in Figures 14 and 16).
According to the configuration of (B3), the difference can be directly recognized.

(B4) A product sales data processing system as described in any of (B1) to (B3), characterized in that the display means displays the reason for the difference between the estimated total amount and the final total amount (for example, as shown in Figure 15, Figure 17, or Figure 20 (C)).
The configuration of (B4) prevents unnecessary anxiety and misunderstanding from being caused to customers.

(B5) A product sales data processing system as described in any of (B1) to (B4), characterized in that the display means displays products that have caused a difference between the estimated total amount and the final total amount in a display manner different from that of other products (for example, by notifying them by icon ICN417 as shown in Figures 14 and 16).
According to the configuration of (B5), it is possible to preferably notify which product caused the price difference (the product to which the special sale was applied).

(B6) A settlement device that settles for goods registered in a portable registration device that registers product information including price information of identified goods, comprising: a settlement means that settles based on the product information; and a display means that displays information related to the settlement, wherein the display means displays an estimated total amount based on the product information at the time when registration by the portable registration device is completed, and a final total amount that is the amount to be settled by the settlement means.
According to the configuration of (B6), even if the product information is changed, the billing details (the total amount at the time of registration, the final payment amount) are clear, so that the customer is not caused unnecessary anxiety or misunderstanding.

(B7) A program that causes a computer to function as a settlement device that settles for goods registered in a portable registration device that registers product information including price information of identified goods, the program causing the computer to function as a settlement means that settles based on the product information and a display means that displays information related to the settlement, the display means displaying an estimated total amount based on the product information at the time when registration by the portable registration device is completed and a confirmed total amount that is the amount to be settled by the settlement means.
According to the configuration of (B7), even if the product information is changed, the billing details (the total amount at the time of registration, the final payment amount) are clear, so that the customer is not caused unnecessary anxiety or misunderstanding.

In addition, a program for implementing the functions of each device described above (headquarters server 10, store controller 30, settlement terminal 40, transaction status management device 50, mobile terminal 60, etc.) may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read into a computer system and executed to process each device. Here, "reading a program recorded on a recording medium into a computer system and executing it" includes installing the program into a computer system. The "computer system" here includes hardware such as an OS and peripheral devices. In addition, the "computer system" may include multiple computer devices connected via a network including the Internet, WAN, LAN, dedicated lines, and other communication lines. In addition, the "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs, CD-ROMs, and storage devices such as hard disks built into a computer system. In this way, the recording medium storing the program may be a non-transient recording medium such as a CD-ROM. In addition, the recording medium also includes a recording medium provided inside or outside and accessible from a distribution server to distribute the program. The code of the program stored in the recording medium of the distribution server may be different from the code of the program in a format executable by the terminal device. In other words, as long as it can be downloaded from the distribution server and installed in a format executable by the terminal device, the format in which it is stored in the distribution server does not matter. The program may be divided into multiple parts, downloaded at different times, and then combined on the terminal device, or each of the divided programs may be distributed by a different distribution server. Furthermore, the "computer-readable recording medium" includes a memory that holds a program for a certain period of time, such as a volatile memory (RAM) inside a computer system that becomes a server or client when a program is transmitted over a network. The program may also be a program for realizing part of the above-mentioned functions. Furthermore, the program may be a so-called difference file (difference program) that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

1...Sales system 10...Head office server 20...Cloud server 30...Store controller 40...Payment device 50...Transaction status management device 60...Mobile terminal 401...CPU 402...ROM 403...RAM 404...Hard disk 405...Display unit 406...Scanner unit 408...Card payment unit 409...Change machine 413...Printing unit 414...Audio output unit 415...Communication unit 416...Imaging unit 417...Sign pole

Claims (7)

A product sales data processing system for registering products using a portable registration device operated by a customer, comprising:
a registration means for executing a registration process for acquiring product information corresponding to the identified product code from a first product information database and registering the product;
a payment means for executing a payment process by referring to the product information after the registration process by the registration means is completed;
A notification means for notifying a customer;
Equipped with
The settlement means is
If a product code is identified but product information corresponding to the product code cannot be obtained from the first product information database, an automatic registration process can be further executed to obtain product information corresponding to the product code from a second product information database and register the product without requiring any operation;
The notification means includes:
A merchandise sales data processing system characterized in that, when the automatic registration process is executed, a notification is automatically given that there is a registered merchandise. The notification means includes:
The product sales data processing system described in claim 1, characterized in that when the automatic registration process is executed, a notification that there are products that have been automatically registered is started before a list screen for confirming the products to be settled is displayed, or while the list screen is displayed. The notification means includes:
A product sales data processing system as described in claim 1 or claim 2, characterized in that when the automatic registration process is executed, a list screen for confirming the products to be settled notifies the user which products have been automatically registered. The notification means includes:
A product sales data processing system as described in any one of claims 1 to 3, characterized in that when the automatic registration process is executed, a payment amount is notified, which is at least the total amount of the products registered in the registration process by the registration means plus the amount of the products registered in the automatic registration process by the settlement means. a store clerk calling means for executing a store clerk calling process for calling a store clerk when a product code is identified but product information corresponding to the product code cannot be acquired from the first product information database after the registration process by the registration means is completed,
The store clerk calling means includes:
A product sales data processing system as described in any one of claims 1 to 4, characterized in that if there is a product whose product code has been identified but product information corresponding to the product code cannot be obtained from the first product information database at the time when the registration process by the registration means is completed, the store clerk call process is not executed when the automatic registration process has been executed for all of the product, and the store clerk call process is executed when the automatic registration process has not been executed for at least a part of the product. The settlement means is
A product sales data processing system as described in any one of claims 1 to 5, characterized in that when the automatic registration process is executed, product information of the product registered in the automatic registration process is transmitted to be stored in the first product information database. A settlement device that settles for a commodity registered by a portable registration device that executes a registration process of acquiring commodity information corresponding to a specified commodity code from a first commodity information database and registering the commodity,
a payment means for executing a payment process by referring to the product information after the registration process by the portable registration device is completed;
A notification means for notifying a customer;
Equipped with
The settlement means is
If a product code is identified but product information corresponding to the product code cannot be obtained from the first product information database, an automatic registration process can be further executed to obtain product information corresponding to the product code from a second product information database and register the product without requiring any operation;
The notification means includes:
When the automatic registration process is executed, the settlement device notifies the user that there is an automatically registered product.

Images