Self registration system and program

Abstract

To improve the efficiency of accounting in a self registration system in which merchandise registration is performed through a customer's operation on a portable terminal.SOLUTION: A self registration system includes: a portable terminal that reads merchandise information related to a merchandise in accordance with a customer's operation, and causes merchandise registration based on the read merchandise information to be performed; and an adjustment device that enables adjustment in accordance with a transaction in accordance with the merchandise registration. The portable terminal includes specification means that specifies identification information that enables identification of the transaction based on an output of the portable terminal, and first adjustment means that causes adjustment in accordance with the merchandise registration to be performed by a specific settlement classification. The adjustment device includes determination means that determines whether the transaction indicated by the specified identification information has been adjusted by the first adjustment means, and second adjustment means that, in a case where it is determined that the transaction has not been adjusted by the first adjustment means, performs adjustment.SELECTED DRAWING: Figure 23

Description

[Technical field]

[0001] The present invention relates to a self-registration system and program. [Background technology]

[0002] POS systems that support an operation called "front handling" are known (see, for example, Patent Document 1). In the front-end handling, the products purchased by the customer are registered in advance using a terminal device for product registration, and the product registration information indicating the product registration result is associated with the code information and transferred to a higher-level device. In addition, a medium such as a label or card indicating the code information is handed over to the customer in accordance with the product registration. The store clerk operating the POS register performs an operation to read the code information from the medium, causing the POS register to obtain the product registration information associated with the code information read from the higher-level device, and executes a settlement process based on the obtained product registration information. By introducing this type of pre-clearance, products can be registered for each customer in advance, which increases the number of customers who can complete their transactions per unit time and makes accounting more efficient, compared to when product registration and payment processing are done for each transaction using a POS register. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2015-82249 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the above-mentioned Patent Document 1, for example, by having the customer register the product, the time required for registering the product for each transaction at the POS register is saved. However, as the payment is to be made at the POS register for all transactions, the customer must wait in line for payment. In this respect, there is still room for improvement in the efficiency of accounting.

[0005] The present invention has been made in consideration of the above circumstances, and has an object to improve the efficiency of checkout in a self-registration system in which product registration is performed by a customer operating a mobile terminal. [Means for solving the problem]

[0006] One aspect of the present invention that solves the above-mentioned problems is a self-registration system that includes a mobile terminal that reads product information related to a product in response to a customer's operation and performs product registration based on the read product information, and a settlement device that can settle a transaction corresponding to the product registration, the self-registration system further includes an identification means that identifies identification information capable of identifying the transaction based on the output of the mobile terminal, and a first settlement means that causes settlement corresponding to the product registration to be performed by a specific payment type on the mobile terminal, a determination means that determines whether the transaction indicated by the identified identification information has been settled by the first settlement means, and a second settlement means that settles the transaction at the settlement device when the determination means determines that the transaction has not been settled by the first settlement means.

[0007] One aspect of the present invention is a program for a self-registration system that causes a first computer to function as a portable terminal that reads product information related to a product in response to a customer's operation and performs product registration based on the read product information, and causes a second computer to function as a settlement device capable of settling a transaction in response to the product registration, the program causing the first computer to function as an identification means that identifies identification information capable of identifying the transaction based on the output of the portable terminal, and as a first settlement means that, when settlement by a specific payment type is permitted, causes settlement in response to the product registration to be performed by the specific payment type, and causes the second computer to function as a second settlement means that performs settlement when the transaction indicated by the identified identification information has not already been settled by the first settlement means. Effect of the Invention

[0008] As described above, according to the present invention, in a self-registration system in which product registration is performed by a customer operating a mobile terminal, it is possible to obtain the effect of improving the efficiency of checkout. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a conceptual diagram of a network for explaining a shopping system. [Diagram 2] FIG. 1 is a diagram showing an example of installation of a settlement device. [Diagram 3] FIG. 2 is a diagram showing an example of the appearance of a settlement device. [Figure 4] FIG. 2 is a diagram illustrating an example of the configuration of a settlement device. [Diagram 5] FIG. 2 is a conceptual diagram of each function for explaining the shopping system of the first embodiment. [Figure 6] FIG. 2 is an explanatory diagram for explaining various selling price determination logics (selling price determination functions). [Figure 7] FIG. 2 is an explanatory diagram for explaining various types of information. [Figure 8] FIG. 11 is a sequence diagram outlining a processing flow. [Figure 9]13 is a display example on a display unit of a mobile terminal. [Figure 10] 13 is an example of a display on the display unit of a settlement device. [Figure 11] FIG. 11 is a conceptual diagram of each function for explaining a shopping system according to a second embodiment. [Figure 12] FIG. 11 is a sequence diagram outlining a processing flow. [Figure 13] FIG. 11 is a conceptual diagram of each function for explaining a shopping system according to a third embodiment. [Figure 14] FIG. 11 is a sequence diagram outlining a processing flow. [Figure 15] 13 is a flowchart showing an example of a more detailed operation flow during product registration. [Figure 16] 13 is a flowchart showing an example of a more detailed operation flow during product registration. [Figure 17] 13 is a flowchart showing an example of a more detailed operation flow at the time of settlement. [Figure 18] 11 is an example of information stored in basket information. [Figure 19] FIG. 13 is a diagram illustrating an example of the configuration of a mobile terminal according to a fourth embodiment. [Figure 20] FIG. 13 is a diagram illustrating an example of the configuration of a cloud server in the fourth embodiment. [Figure 21] 13 is a flowchart showing an example of a processing procedure executed by a mobile terminal and a cloud server in relation to a transaction (product registration and payment) in the fourth embodiment. [Figure 22] A figure showing an example of a settlement device guidance screen in the fourth embodiment. [Diagram 23] 13 is a flowchart showing an example of a processing procedure executed by the settlement device and the cloud server in relation to settlement in the fourth embodiment. [Figure 24] 13A to 13C are diagrams showing examples of a standby screen in the fourth embodiment. [Diagram 25] FIG. 13 is a diagram showing an example of a settlement completion screen in the fourth embodiment. [Figure 26]FIG. 13 is a diagram showing an example of a product list screen in the fourth embodiment. [Figure 27] FIG. 13 is a diagram showing another example of a product list screen in the fourth embodiment. [Figure 28] 13 is a flowchart showing an example of a processing procedure executed by a mobile terminal and a cloud server in relation to a transaction (product registration and payment) in the fifth embodiment. [Figure 29] 13A to 13C are diagrams showing examples of a payment type selection screen and a store clerk call guide screen in the fifth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] First Embodiment Fig. 1 is a conceptual diagram of a network for explaining a shopping system. The shopping system shown in Fig. 1 includes a management device (e.g., a store controller) 10, a cloud server 20, a settlement device 30, a settlement device 40, a mobile terminal 50 (e.g., a smartphone, etc.), and a credit card payment server 60.

[0011] The management device 10, the settlement device 30, and the settlement device 40 are installed in a store, and are connected to each other so as to be able to communicate with each other via a LAN 19 (which may be wired or wireless). The management device 10 is capable of communicating with a cloud server 20. Although two settlement devices 30 are illustrated in FIG. 1, the number of settlement devices 30 in one store may be one or three or more. Although two settlement devices 40 are illustrated in FIG. 1, the number of settlement devices 40 in one store may be one or three or more. The number of settlement devices 30 and the number of settlement devices 40 do not have to be the same. Furthermore, one management device 10 is basically provided in one store, but two or more management devices may be provided.

[0012] The mobile terminal 50 is operated by a customer (such as a shopper who is a member of the store). In addition to typical communication and imaging functions (camera), the mobile terminal 50 has a recognition function for scanning a barcode attached to a product to read the product code, that is, for recognizing the barcode attached to the product. Note that the recognition function of the mobile terminal 50 only needs to be capable of reading a product code, and does not need to be capable of recognizing which product the read product code belongs to. In other words, the mobile terminal 50 only needs to be capable of reading a product code from a barcode that exists as an object in an image captured by the imaging function (an image acquired as a through image).

[0013] Furthermore, the mobile terminal 50 captures (releases the shutter) an image of the product (for example, the surrounding area with a barcode) and generates a captured image (image data). The mobile terminal 50 may release the shutter in response to an operation by the customer who is the operator, but in this embodiment, it is preferable that the mobile terminal 50 releases the shutter at its own discretion (for example, see steps S31 and S45 in FIG. 15 described later).

[0014] The mobile terminal 50 may also include an image recognition technology that extracts feature points from an image (through image, captured image) and recognizes an imaged subject (object, etc.). For example, the mobile terminal 50 may use the image recognition technology to identify (estimate) a captured product.

[0015] The mobile terminals 50 are basically assumed to be owned by each customer, but may be loaned by the store. The number of mobile terminals 50 (the number in operation) varies depending on the number of customers visiting the store, and in FIG. 1, two mobile terminals 50 are shown as an example to show that multiple units are possible.

[0016] Both the settlement device 30 and the settlement device 40 are settlement devices that are capable of at least cash payment as a settlement method. The settlement device 30 does not have a communication function with the cloud server 20, but the settlement device 30 has a communication function with the cloud server 20. The cloud server 20 manages transaction information (basket information), for example, for each customer.

[0017] The credit card payment server 60 executes a payment process corresponding to a credit card in response to a non-cash payment request transmitted from the settlement device 30, the settlement device 40, the mobile terminal 50, etc. The credit card payment server 60 may communicate with the settlement device 30 via the management device 10.

[0018] The beacon terminal BTM is installed in a store. A usage example of the beacon terminal BTM will be described later in the fourth embodiment.

[0019] The shopping system shown in Fig. 1 is for explaining a shopping system according to the first embodiment (similar to the second and third embodiments) of the present invention, and the shopping system according to the first embodiment (similar to the second and third embodiments) of the present invention does not necessarily include all of the configuration shown in Fig. 1. For example, the shopping system according to the first embodiment (similar to the second and third embodiments) of the present invention may be configured from a cloud server 20 and a settlement device 40, or may be cloud server 20 alone, or may be settlement device 40 alone.

[0020] Fig. 2 is a diagram showing an example of the installation of the settlement device 40. Fig. 2(A) is a perspective view of the settlement device 40 etc. as seen from the customer side. Fig. 2(B) is a perspective view of the settlement device 40 etc. as seen from the store clerk side. As shown in Fig. 2(A), a counter is placed on the right side of the settlement device 40 as seen from the customer side.

[0021] Fig. 3 is a diagram showing an example of the appearance of the settlement device 40. Fig. 3(A) is a perspective view of the settlement device 40 as seen from the customer side. Fig. 3(B) is a perspective view of the settlement device 40 as seen from the store clerk side. Fig. 4 is a diagram showing an example of the configuration of the settlement device 40. In Figs. 3 and 4, the same parts are given the same symbols.

[0022] An example of the configuration of settlement device 40 shown in Fig. 4 will be described below with reference to Fig. 3. Settlement device 40 includes a CPU 401, a ROM 402, a RAM 403, a hard disk 404, a customer display unit 405, a customer scanner unit 406, a card payment unit 408, a change machine 409, a store clerk display unit 410, a key operation unit 411, a store clerk scanner unit 412, a printing unit 413, an audio output unit 414, and a communication unit 415. These can communicate with each other via a bus.

[0023] 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.

[0024] The RAM 403 is a read / write memory and stores various information, such as information read from the ROM 402 or the hard disk 404, information acquired from the outside, and information generated during processing.

[0025] The hard disk 404 stores various information. 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 acquired from the outside, information generated during processing, and the like.

[0026] The customer-side display unit 405 is a touch display for customers, which displays various information to customers and accepts various inputs from customers. Customer-side scanner unit 406 is a scanner unit for customers, and for example, scans a barcode attached to a product and reads the product code. Customer-side scanner unit 406 may also scan a code (barcode, two-dimensional code, etc.) printed on a bill (registered trademark) and read information required for payment. Customer-side scanner unit 406 may also scan a code (two-dimensional code, etc.) displayed on the display unit of mobile terminal 50 and read information required for payment.

[0027] Although the customer-side scanner unit 406 is used when a customer registers a product, the customer may register the product by other methods. For example, if a preset key (a button for ordering the product) corresponding to the product is displayed on the customer-side display unit 405, the customer may operate (press) the preset key to register the product.

[0028] The card payment unit 408 is a payment mechanism that uses various cards (credit cards, prepaid cards such as transportation cards, etc.). The card payment unit 408 in the first embodiment (similar to the second and third embodiments) includes a card recognition unit (reading unit), a display unit, and an operation unit, but it is sufficient that it includes at least the card recognition unit. The card recognition unit may recognize various cards (e.g., membership cards, point cards, etc.) that are not directly used for payment (settlement).

[0029] The change machine 409 (cash settlement unit) is a cash settlement mechanism, which 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. The change machine 409 faces the customer and is operated by the customer. 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.).

[0030] That is, the change machine 409 is used when the price of registered products is settled with cash (money) in the settlement device 40. The change machine 409 has a banknote insertion port for inserting banknotes, a coin insertion port for inserting coins, a banknote discharge port for discharging banknotes, a coin discharge port for discharging coins, a counting unit for counting the inserted or discharged money, a money transport mechanism between the insertion port or discharge port and the storage unit, the above-mentioned sensor, etc. The banknote insertion port and the coin insertion port are also referred to as deposit insertion ports. The banknote discharge port and the coin discharge port are also referred to as change discharge ports. The banknote insertion port and the banknote discharge port may be a common port, and the coin insertion port and the coin discharge port may be a common port.

[0031] The change machine 409 also counts the coins replenished during the closing process and stores them in the storage unit. The change machine 409 also counts the coins to be dispensed during the closing process and discharges them from the change discharge port. The closing process is a process of adjusting the amount of money stored in the change machine 409 (cash available / cash in reserve) to a reference amount after the store is closed or before the store is opened.

[0032] The store clerk's display unit 410 is a touch display for the store clerk, which displays various information to the store clerk and receives various inputs from the store clerk. The key operation unit 411 is made up of various keys (buttons) and receives various inputs from the store clerk. The store clerk scanner unit 412 is a scanner unit for store clerks, and for example, scans a barcode attached to a product and reads the product code. The store clerk scanner unit 412 also scans a barcode attached to the name tag of the store clerk and reads the store clerk code.

[0033] Although the store clerk's scanner unit 412 is used when the store clerk registers a product, the store clerk may register the product by other methods. For example, if a key corresponding to a product (e.g., a key corresponding to a sports newspaper) is arranged on the key operation unit 411, the store clerk may operate (press) that key to register the product. Also, if a preset key corresponding to a product is displayed on the store clerk's display unit 410, the store clerk may operate that preset key to register the product.

[0034] The printing unit 413 prints and issues various media (receipts, bills, etc.). The printing unit 413 can freely rotate to change its orientation (direction of the media issuing port) from the clerk side to the customer side and from the customer side to the clerk side. The orientation of the printing unit 413 may be changed manually, or may be changed automatically (mechanically controlled, etc.) in response to, for example, a transition (switching) of an operating mode (described in detail later). The correctness of the orientation of the printing unit 413 may be detected by a sensor, etc.

[0035] The audio output unit 414 outputs audio. For example, the audio output unit 414 outputs audio guidance and the like. The communication unit 415 transmits and receives information to and from other devices (other settlement devices 40, settlement devices 30, management device 10).

[0036] The appearance and hardware configuration of settlement device 40 have been described above, but a description of the appearance and hardware configuration of settlement device 30 will be omitted. As described below (see FIG. 5, etc.), settlement device 30 and settlement device 40 have different functions realized by software, but the appearance and hardware configuration of settlement device 30 and settlement device 40 may be the same or different. For example, settlement device 40 may be a settlement device having two scanner units (customer-side scanner unit 406, store clerk-side scanner unit 412), while settlement device 30 may be a settlement device having one scanner unit.

[0037] Fig. 5 is a conceptual diagram of each function for explaining the shopping system of the first embodiment. Fig. 6 is an explanatory diagram for explaining various selling price determination logics (selling price determination functions). Fig. 7 is an explanatory diagram for explaining various information.

[0038] Note that Fig. 5 is for explaining the shopping system according to the first embodiment of the present invention, and the shopping system according to the first embodiment of the present invention does not necessarily include all of the configuration shown in Fig. 1. For example, the shopping system according to the first embodiment of the present invention may be configured from cloud server 20 and settlement device 40, or may be cloud server 20 alone, or may be settlement device 40 alone. Also, Fig. 5 explains extracted functions related to the characteristic parts of the shopping system according to the first embodiment of the present invention, and does not comprehensively explain functions generally required for a shopping system.

[0039] [Payment device 30] As shown in the lower right of Fig. 5, the settlement device 30 has a selling price determination logic (selling price determination function) and a settlement function. The selling price determination logic is a function that determines (calculates) the selling price (amount charged as the selling price) required in the settlement process, and is realized by software. There are various types of selling price determination logic (see Fig. 6, for example), but in the example shown in Fig. 5, the settlement device 30 has selling price determination logic A and selling price determination logic B.

[0040] Selling price determination logic A shown in FIG. 6 is a basic price calculation function of the discount price for a basic single item that corresponds to changes in selling price during operation (as appropriate). Selling price determination logic B is a single item discount price calculation function that calculates the discount price for a single item based on setting information (single item discount setting information). Selling price determination logic C is a subtotal discount price calculation function that calculates the discount price for the subtotal based on setting information (subtotal discount setting information). Selling price determination logic D is a member discount price calculation function that calculates the discount price for a single item or the subtotal based on setting information (member discount setting information). Selling price determination logic E is a time service discount price calculation function that calculates the discount price for a single item based on setting information (time service discount setting information). Selling price determination logic F is a mix match discount price calculation function that calculates the discount price for a mixed product (a group of products with unspecified (undefined) combinations) based on setting information (mix match discount setting information). The selling price determination logic G is a set match discount price calculation function that calculates the discount price for a set product (a group of products in a specified (fixed) combination) based on the setting information (set match discount setting information). The selling price determination logic H is a payment type discount price calculation function that calculates the discount price according to the payment type used based on the setting information (payment type discount setting information).

[0041] The members to whom the selling price determination logic D (member discount price calculation function) is applied may be all customers (all customers) or a part of customers (for example, customers of a specific customer rank).

[0042] Information related to selling price determination logic A (information on selling price changes) and various setting information corresponding to selling price determination logic B to selling price determination logic H may be stored in the storage unit of settlement device 30 or a device accessible to settlement device 30. As described above, settlement device 30 has selling price determination logic A and B, but does not have selling price determination logic C to F, and therefore it is sufficient for settlement device 30 to be able to refer to at least information related to selling price determination logic A (information on selling price changes) and setting information corresponding to selling price determination logic B (single item discount setting information).

[0043] Although not shown in FIG. 6, in addition to each selling price determination logic (selling price determination logic A to H), there is also a selling price determination overarching logic that oversees each selling price determination logic. The selling price overarching logic is logic for determining prices across multiple selling price determination logics. For example, when there is selling price determination logic B (single item discount price calculation function) and selling price determination logic D (membership discount price calculation function), the selling price determination overarching logic determines the discount when selling price determination logic B and selling price determination logic D exist based on setting information (selling price determination overarching setting information).

[0044] As an example, in a state where product a (priced at 100 yen in product information) is priced at 80 yen (10 yen discount) according to selling price determination logic B (and single item discount setting information) and 90 yen (20 yen discount) according to selling price determination logic D (and member discount setting information), when a member (a customer to whom selling price determination logic D is applied) purchases product a, the selling price determination control logic may apply only selling price determination logic D to set the price of product a at 80 yen (20 yen discount), or may apply both selling price determination logics B and D to set the price of product a at 70 yen (30 yen discount). Whether to apply only selling price determination logic D to set the price of product a at 80 yen or to apply both selling price determination logics B and D to set the price of product a at 70 yen depends on the setting information (selling price control setting information). Note that the selling price determination control logic may determine the price with the smaller discount amount.

[0045] For example, as described above, when the member discount amount is larger (when the single item discount amount according to the selling price determination logic B is 10 yen and the member discount amount according to the selling price determination logic D is 20 yen), the selling price determination logic D may not be applied and only the selling price determination logic B may be applied to set the price of the product a to 90 yen. Specifically, when a discount limit for the member discount is set or when the purchase with the member discount is not reflected in the member rank record, the setting information (selling price determination general setting information) may be set to apply only the selling price determination logic B. Conversely, when the single item discount amount is larger (when the single item discount amount according to the selling price determination logic B is 30 yen and the member discount amount according to the selling price determination logic D is 20 yen), the selling price determination logic B may not be applied and only the selling price determination logic D may be applied to set the price of the product a to 80 yen. Specifically, when the purchase record with the member discount is given preferential treatment in the calculation of the member rank, the setting information (selling price determination general setting information) may be set to apply only the selling price determination logic D.

[0046] The selling price determination general logic described above may be provided as necessary (when adjustment is required among multiple selling price determination logics). For example, in the first embodiment, the cloud server 20 (as well as the settlement device 30) is provided with selling price determination logics A, B, and C (FIG. 5), but may further be provided with a selling price determination general logic. The same applies to the second and third embodiments.

[0047] The selling price determination oversight logic may be regarded as one of the selling price determination logics shown in Fig. 6. In the following description, one or more of the individual selling price determination logics shown in Fig. 6 may be referred to as the "selling price determination logic", or the "selling price determination logic" may include the selling price determination oversight logic. In other words, when simply describing the "selling price determination logic", this may mean either excluding the selling price determination oversight logic or not excluding the selling price determination oversight logic.

[0048] The settlement function is a function that executes settlement processing (e.g., dispensing cash using a change dispenser) based on the selling price determined by the selling price determination logic.

[0049] In addition, in Fig. 5 (also in Figs. 11 and 13), the selling price determination logic is described as a function separate from the settlement function, but the selling price determination logic may be considered as part of the settlement function. In other words, in Fig. 5 (also in Figs. 12 and 14), the part that determines the selling price and the part that actually executes payment based on the determined selling price are considered separately, and the function corresponding to the part that determines the selling price is called the selling price determination logic, and the part that actually executes payment is called the settlement function, but the part that determines the selling price may also be called the settlement function. When the part that determines the selling price is called the settlement function, the selling price determination logic becomes part of the settlement function.

[0050] [Management device 10] As shown in the upper right of FIG. 5, the management device 10 stores store information and product information. The management device 10 may be equipped with a selling price determination logic. The store information stored in the management device 10 is information about the store in which the management device 10 is installed, and includes, for example, the store name of the store and information identifying the store. The product information stored in the management device 10 is information about products sold in the store in which the management device 10 is installed, and includes, for example, a product code, a product name, and a price. The management device 10 may acquire and store product information, for example, from an external device (such as a headquarter server (not shown)). The management device 10 may also be an external device (headquarters server). In other words, the management device 10 may manage common or separate (for each store) product information and selling price determination logic used in each store. The same applies to the management devices 10 (management devices 11 and 12) of the second and third embodiments.

[0051] [Cloud Server 20] As shown in the upper left of Fig. 5, the cloud server 20 is provided with selling price determination logic. As described above, there are various types of selling price determination logic (for example, see Fig. 6), but in the example shown in Fig. 5, the cloud server 20 is provided with selling price determination logic A, selling price determination logic B, and selling price determination logic C. Note that the cloud server 20 is provided with selling price determination logic A to C, but is not provided with selling price determination logic D to F, so it is sufficient if the cloud server 20 is able to refer to at least information related to selling price determination logic A (information on price change), setting information corresponding to selling price determination logic B (single item discount setting information), and setting information corresponding to selling price determination logic C (subtotal discount setting information).

[0052] Cloud server 20 also stores customer information, store information, product information, and basket information. Customer information is information for managing individual customers. Cloud server 20 generates customer information when a customer is registered (a customer's registration may be considered to have been completed when the customer information of that customer is stored). Cloud server 20 also updates customer information as appropriate based on basket information, etc. For example, cloud server 20 may refer to basket information at a predetermined time every day, for example, and update customer information.

[0053] The payment function provided in the cloud server 20 in FIG. 5 corresponds to the fourth embodiment, and therefore a description thereof will be omitted in this embodiment.

[0054] The cloud server 20 stores customer information such as that shown in FIG. 7(A). The customer information shown in FIG. 7(A) includes customer identification information, customer name, customer registration date, cancellation information, customer rank, number of points, etc. Customer identification information is identification information that uniquely identifies a customer. Customer name is the customer's name or nickname, etc. Customer registration date is the date and time when the customer was registered. Cancellation information is information regarding cancellation of registered products after registration. Customer rank is a rank according to the customer's purchase history. When generating customer information for a new customer, customer identification information, customer name, and customer registration date are generated, but other information (cancellation information, etc.) is not generated because this is before the start of an actual transaction (product registration).

[0055] In addition, since the designated payment type information and the payment type usage history in the customer information in FIG. 7(A) correspond to the fourth embodiment, the explanation thereof will be omitted here.

[0056] The cloud server 20 generates and stores customer identification information, for example, when a customer is registered (for example, when the mobile terminal 50 downloads or installs an application (app) to use a service provided by the cloud server 20 from an external source (for example, a predetermined server that provides all apps, the cloud server 20 itself)). In addition, the cloud server 20 acquires information entered into the name field of a registration form (input form) using the mobile terminal 50, for example, when a customer is registered, and stores it as the customer name. In addition, the cloud server 20 acquires the current date and time when the customer is registered, and stores it as the customer registration date.

[0057] Note that cloud server 20 may store some or all of the customer information in another device (such as a file server accessible by cloud server 20) instead of or in addition to storing the customer information in a storage unit within its own device.

[0058] The store information is acquired from the management device 10 of each store (see transmitted / received data "D0" in FIG. 5. The transmitted / received data "D1" to "D6" will be explained in FIG. 8.) In other words, the cloud server 20 receives the store information directly from the management device 10 of each store or indirectly via another device, and stores the store information.

[0059] The cloud server 20 stores, for example, store information as shown in FIG. 7(B). The store information shown in FIG. 7(B) includes store identification information, store name (branch name), store specification information 1, and store specification information 2. The store identification information is identification information that uniquely identifies a store. The store identification information shown in FIG. 7(B) is composed of a store (trade name) or company code and a branch code. The store name is the name of the store. The store name shown in FIG. 7(B) is composed of a store (trade name) or company and a branch name. The store specification information 1 is information of a two-dimensional code (QR code (registered trademark), etc.) for identifying a store where a transaction is made (a store where a product is bought and sold). The store specification information 2 is store location information (GPS information) for identifying a store where a transaction is made. Note that in the example shown in FIG. 7(B), the store identification information and the store specification information 1 are different, but the store identification information and the store specification information 1 may be the same.

[0060] Cloud server 20 may obtain and store store information and the like from an external source (such as a server (not shown) at a headquarters that manages each store). Cloud server 20 may store some or all of the store information in another device (such as a file server accessible by cloud server 20) instead of or in addition to storing the store information in a memory unit within its own device.

[0061] The product information is obtained from the management device 10 of each store, etc. (see transmitted / received data "D0" in FIG. 5. The transmitted / received data "D1" to "D6" will be explained in FIG. 8). That is, the cloud server 20 stores the product information by receiving the product information directly from the management device 10 of each store or indirectly via another device. The cloud server 20 may obtain and store the product information from an external device (such as a server (not shown) at a headquarters that manages each store). The cloud server 20 may store part or all of the store information in another device (such as a file server accessible by the cloud server 20) instead of or in addition to storing the store information in a memory unit within its own device.

[0062] The basket information is information for managing individual transactions. Cloud server 20 generates the basket information at the start of a transaction. Cloud server 20 also updates the basket information as the transaction progresses (each time a product is registered) (storing a product in the basket information may be interpreted as the product being registered).

[0063] The cloud server 20 stores basket information such as that shown in FIG. 7(C). The basket information shown in FIG. 7(C) includes basket identification information, transaction start date and time, transaction end date and time, customer identification information, registered product information, pending product information, cancellation information, etc. The basket identification information is identification information that uniquely identifies a basket. The basket identification information shown in FIG. 7(C) is composed of store identification information, date, and serial number (for example, a serial number specific to each store and each date). The transaction start date and time is the start date and time of the transaction. The transaction start date and time shown in FIG. 7 is the creation date and time of the basket information. The transaction start date and time may be the registration date and time of one product (the date and time when the registered product information (registered product 1) in FIG. 7(C) is stored). The creation date and time of the basket information and the registration date and time of one product may both be stored separately.

[0064] Incidentally, the settled flag in the basket information of FIG. 7(C) corresponds to the fourth embodiment, and therefore a description thereof will be omitted here.

[0065] The transaction end date and time is the end date and time of the transaction. The transaction start date and time shown in FIG. 7 is the settlement date and time. The customer identification information is customer identification information that identifies the customer of the transaction. When the basket information is generated, the basket identification information, transaction start date and time, and customer identification information are generated, but since this is before the start of the actual transaction (product registration), other information (transaction end date and time, etc.) is not generated. The settlement date and time may be the settlement start date and time (for example, the execution date and time of the process of step S89 in FIG. 17) or the settlement end date and time (the end date and time of the process of step S91 in FIG. 17). The settlement start date and time and the settlement end date and time may both be stored separately.

[0066] Registered product information (total) is information that is updated each time a product is registered. Registered product information (total) includes the number of products (number of products), estimated subtotal amount (estimated subtotal amount before price calculation using price determination logic), subtotal amount (subtotal amount after price calculation using price determination logic), etc. Registered product information (1) is registered information for one product item. Registered product information (2) is registered information for two products. In the example shown in Figure 7 (C), registered product information (3) to registered product information (5) are omitted from the illustration. Registered product information (N; N is an integer) includes product code, product name (product name), price, etc.

[0067] The registered product information (N) may include the registration date and time of the Nth item of product. In other words, the cloud server 20 may store the registration date and time of the registered product as the registered product information. The registration date and time of each product may also be used as a basis for determining whether or not to apply a service such as a time service (a service based on the selling price determination logic E) and the effect of the application.

[0068] The reserved product information (total) is information that is updated each time a reserved product (described later) is registered. The reserved product information (total) includes the number of reserved products (number of products), the number of NON-PLU (also called "NO-FILE") reserved products, the number of reserved products that cannot be read (check for unauthorized operation), etc.

[0069] NON-PLU refers to a product whose barcode or product code was successfully scanned in the store (the product code was successfully read), but whose product code is not stored in the product information (a product whose product information is not registered). In addition, the terms "NON-PLU", "NO-FILE", "NON FILE" and the like in the specification, drawings and the like of this application all refer to products for which product information has not been registered as described above.

[0070] The reading NG means that the scanning of the product code at the store has failed (the product code could not be read), or the product has failed to be scanned at the store. In other words, the reading NG means, for example, a timeout process when it is possible to determine that the barcode is not recognized even though the product is imaged for a certain period of time using image recognition technology, or a product that has been timed out. For example, the reading NG is determined when the barcode cannot be correctly acquired (recognized) due to wrinkles on the package or smudges or dirt on the barcode print. The reading NG is also determined when an illegal operation of pretending to read the barcode and putting it in the basket is detected. The mobile terminal 50 includes a sensor (for example, a gyro sensor, an acceleration sensor, a distance sensor, etc.) and can detect when the mobile terminal 50 is reading a barcode (specifically, when the mobile terminal 50 is tilted to read the barcode and an item (product) is present at a certain distance away from the mobile terminal 50). If the barcode cannot be read within a predetermined time (if the barcode continues to be read for a predetermined time but the barcode cannot be read), a timeout process occurs and the product is marked as pending (reading failed).

[0071] Reserved Product Information (Reserved Product 1) is information on reserved product 1. Reserved Product Information (Reserved Product 2) is information on reserved product 2. Reserved Product Information (Reserved Product 3) is information on reserved product 3.

[0072] The reserved product information (reserved product N; N is an integer) includes the reserved product type (information indicating whether the reserved product is NON-PLU or cannot be read) and image data (image data captured when reading was NG). For example, if the Nth item is a reserved product due to NON-PLU, the reserved product information (reserved product N) includes the reserved product type "1 (NON-PLU)" and image data. Also, if the Nth item is a reserved product due to reading being NG, the reserved product information (reserved product N) includes the reserved product type "2 (cannot be read)" and image data (see FIG. 18(D)).

[0073] Note that cloud server 20 may store some or all of the basket information in another device (such as a file server accessible by cloud server 20) instead of or in addition to storing the basket information in a memory unit within its own device.

[0074] [Payment device 40] As shown in the lower left of FIG. 5, the settlement device 40 has a cloud communication function, a mobile terminal linkage function, and a settlement function. The cloud communication function is a function for communicating with the cloud server 20. The mobile terminal linkage function is a function for linking with the mobile terminal 50, and is, for example, a function for optically scanning (reading) a code (such as a two-dimensional code) displayed on the display unit of the mobile terminal 50 and supplying the scanned information (or information based on the scanned information) to the cloud communication function. The code displayed on the display unit of the mobile terminal 50 is coded information (such as basket identification information) required to execute settlement processing for the products purchased by the mobile terminal 50. Note that the cloud communication function and the mobile terminal linkage function are unique functions of the settlement device 40 that are not provided in the settlement device 30.

[0075] The settlement function is a function for executing settlement processing (for example, dispensing cash using a change dispenser) based on the selling price determined by the selling price determination logic of the cloud server 20.

[0076] The settlement device 40 has a cloud communication function, a mobile terminal linkage function, and a settlement function, and can, for example, scan a code (information capable of identifying the basket information of a customer) displayed on the display of a customer's mobile terminal 50, send the scanned information (or information based on the scanned information) to the cloud server 20, receive a selling price (subtotal information) based on the basket information of the customer from the cloud server 20, and execute settlement processing based on the received selling price.

[0077] [Mobile device 50] 5, the mobile terminal 50 communicates with the cloud server 20. The mobile terminal 50 registers a product by communicating with the cloud server 20. That is, the mobile terminal 50 captures an image of a barcode attached to a product, recognizes the barcode as an object (reads a product code from the barcode), and registers the product by transmitting the product code to the cloud server 20 (specifically, stores the product code in the basket information of the cloud server 20).

[0078] Furthermore, the mobile terminal 50 generates a code (such as a two-dimensional code). That is, the mobile terminal 50 displays a code on the display unit in association with the mobile terminal linkage function of the settlement device 40, but the mobile terminal 50 generates the code to be displayed on the display unit by itself and displays it on the display unit. Note that the code that the mobile terminal 50 generates and displays on the display unit is, as described above, an encoded version of information (e.g., basket identification information) required to execute settlement processing for the items purchased by the mobile terminal 50.

[0079] The mobile terminal 50 realizes, as the functions of the application acquired from the outside, a function of communicating with the cloud server 20 and a function of generating a code (such as a two-dimensional code). That is, the mobile terminal 50 may communicate with the cloud server 20, generate a code, and display the code by activating the application.

[0080] Note that the mobile terminal 50 does not have to have a function of generating a code to be displayed on the display unit. For example, the cloud server 20 may have a function of generating a code instead of the mobile terminal 50. That is, the cloud server 20 may generate a code based on a request from the mobile terminal 50, transmit the generated code to the mobile terminal 50, and the mobile terminal 50 may request the cloud server 20 to generate a code, receive the code generated by the cloud server 20, and display it on the display unit.

[0081] FIG. 8 is a sequence diagram for explaining an outline of the flow of processing in the functional configuration of FIG. 5. Specifically, FIG. 8 (similar to FIG. 12 and FIG. 14) shows an example of processing of a mobile terminal 50 of a customer, a settlement device 40 installed in the store, and a cloud server 20 installed outside a data center or the like, from when a customer visits a store, registers products displayed in the store, and completes payment for the registered products. The left side of FIG. 8 shows processing of the mobile terminal 50, the center shows processing of the settlement device 40, and the right side shows processing of the cloud server 20. FIG. 9 shows an example of display on the display unit of the mobile terminal 50. FIG. 10 shows an example of display on the display unit of the settlement device.

[0082] The flow of operations shown in FIG. 8 will be described below with reference to FIGS. 5, 7, 9, 10, etc. Step S1: The mobile terminal 50 acquires information for identifying a store (store identification information). For example, a two-dimensional code for identifying the store may be displayed near the entrance of the store (the two-dimensional code may be output on a display screen, a medium on which the two-dimensional code is printed may be attached, etc.), and a customer who visits the store may scan (read) the two-dimensional code with the mobile terminal 50, thereby allowing the mobile terminal 50 to acquire the store identification information. When a customer who visits the store starts up the app, a screen instructing the customer to scan the two-dimensional code may be displayed as an initial screen, or when a customer who visits the store scans the two-dimensional code with the mobile terminal 50, the app may start up and a screen informing the customer that the cloud server 20 is currently connected to may be displayed as an initial screen.

[0083] Also, for example, since a store is identified by its location, a customer who visits the store may obtain location information (GPS information) at the store using the mobile terminal 50 (i.e., the store's location information may be obtained as store identification information). When a customer who visits the store starts the app, location information may be obtained, and a screen may be displayed as the initial screen informing the customer that the app is currently connected to the cloud server 20. If multiple stores are detected from the location information and it is not possible to identify one store, a selection screen may be displayed to allow the customer to select. Alternatively, a mode may be switched to forcefully obtain a two-dimensional code.

[0084] The mobile terminal 50 that has acquired the store identification information transmits the acquired store identification information together with the customer identification information to the cloud server 20 as a transaction start request (see transmission / reception data "D1" in FIG. 5 and FIG. 8). As described above, the customer identification information is stored in the customer information of the cloud server 20 by inputting the name field of the registration form using the mobile terminal 50 at the time of customer registration (when downloading or installing an app on the mobile terminal 50). However, the customer identification information may be stored in the storage unit of the mobile terminal 50 in addition to the cloud server 20. When a store is identified (when an initial product registration screen described later is acquired), the store name of the store, the service being implemented (flyer information distributed on that day), and available coupon information may be displayed on a screen (the initial product registration screen or a screen other than the initial product registration screen). The service and coupon information may be acquired from the cloud server 20 as screen information, for example.

[0085] The destination information (address of the cloud server 20) may also be obtained at the time of customer registration (when downloading or installing the app on the mobile terminal 50) and stored in the memory of the mobile terminal 50. In the case of scanning a two-dimensional code, the destination information may also be converted into a two-dimensional code in addition to the store-specific information, and the mobile terminal 50 may acquire the destination information together with the store-specific information by scanning the two-dimensional code with the mobile terminal 50.

[0086] Step S2: The cloud server 20, which has received the customer identification information and store identification information as a transaction start request from the mobile terminal 50, generates a basket for the transaction. Specifically, it generates basket information as shown in Fig. 7(C). Note that when the basket information is generated, the basket identification information, transaction start date and time, and customer identification information are generated, but since this is before the start of the actual transaction (product registration), other information (transaction end date and time, etc.) is not generated.

[0087] As described above, the cloud server 20 stores store information such as that shown in Fig. 7(B), and therefore when it receives store identification information (also receives customer identification information) as a transaction start request from the mobile terminal 50, if the received store identification information is a two-dimensional code, it acquires the store identification information by referring to store identification information 1, and if the received store identification information is location information (GPS information), it acquires the store identification information by referring to store identification information 2. Note that if the store identification information received from the mobile terminal 50 is store identification information converted into a two-dimensional code, the cloud server 20 may acquire it as is.

[0088] That is, the cloud server 20, which has received the customer identification information and the store identification information from the mobile terminal 50 as a transaction start request, acquires the store identification information from the store identification information received from the mobile terminal 50, further acquires the current date, issues (assigns) a serial number, combines the store identification information with the current date and the serial number, and stores the combined information as basket identification information in the basket information. Also, the cloud server 20, which has received the store identification information and the customer identification information from the mobile terminal 50 as a transaction start request, acquires the current date and time, and stores the current date and time as the transaction start date and time (generation date and time) in the basket information. Also, the cloud server 20, which has received the store identification information and the customer identification information from the mobile terminal 50 as a transaction start request, stores the customer identification information received from the mobile terminal 50 as the customer identification information in the basket information.

[0089] Step S3: The cloud server 20 that has generated the basket for the transaction generates product registration initial screen information (screen information of the product registration screen, which is the initial screen), and transmits it to the mobile terminal 50. Specifically, the cloud server 20 generates product registration initial screen information such that the product registration initial screen as shown in Fig. 9(A) is displayed on the mobile terminal 50, for example, and transmits the generated product registration initial screen information together with the basket identification information to the mobile terminal 50 (see transmission and reception data "D2" in Figs. 5 and 8).

[0090] Step S4: The mobile terminal 50, which has received the basket identification information and the product registration initial screen information from the cloud server 20, stores the basket identification information and displays the registration screen on the display unit. Specifically, the mobile terminal 50 displays, for example, the product registration initial screen as shown in FIG. 9(A).

[0091] Step S5: The customer operates the mobile terminal 50 to scan the barcode attached to the product and read the product code. Note that in Fig. 8 (also in Figs. 12 and 14), it is assumed that the barcode has been successfully scanned. Note that, although simplified in Fig. 5 for the sake of convenience, steps S5 to S9 are repeatedly executed every time the barcode attached to the product is scanned.

[0092] The mobile terminal 50 that has acquired the barcode transmits the scanned product code together with the basket identification information to the cloud server 20 (see the transmitted and received data "D3" in Figs. 5 and 8).

[0093] Step S6: The cloud server 20 receives the basket identification information and the product code from the mobile terminal 50 and identifies the basket of the transaction from the basket identification information.

[0094] Step S7: Cloud server 20 updates the product data in the identified basket. Specifically, when cloud server 20 receives a product code as the Nth item, it stores the product code as the product code of registered product information (registered product N) in the basket information of the identified basket, obtains the product name and price corresponding to the product code from the product information, and stores them as the product and price of the registered product information (registered product N). Cloud server 20 also updates the registered product information (total) in the basket information of the identified basket.

[0095] Step S8: Having updated the product data in the basket, the cloud server 20 generates product registration update screen information (screen information of the product registration screen which is an update screen to which the registered product has been added) and transmits it to the mobile terminal 50. Specifically, the cloud server 20 generates product registration update screen information such that a product registration update screen such as that shown in Fig. 9(B) is displayed on the mobile terminal 50, for example, and transmits the generated product registration update screen information together with the basket identification information to the mobile terminal 50 (see transmission and reception data "D4" in Figs. 5 and 8).

[0096] The product registration screen (product registration update screen) shown in Fig. 9(B) is displayed on the mobile terminal 50 after "XX bread" is registered as the third product item. That is, when "XX yogurt" is stored in the basket as the first product item, the cloud server 20 generates product registration update screen information such that "XX yogurt" is displayed on the mobile terminal 50 and transmits the generated product registration update screen information to the mobile terminal 50 together with the basket identification information, when "XX chocolate" is stored in the basket as the second product item, the cloud server 20 generates product registration update screen information such that "XX yogurt" and "XX chocolate" are displayed on the mobile terminal 50 and transmits the generated product registration update screen information to the mobile terminal 50 together with the basket identification information, and when "XX bread" is stored in the basket as the third product item, the cloud server 20 generates product registration update screen information such that "XX yogurt", "XX chocolate", and "XX bread" are displayed on the mobile terminal 50 as shown in Fig. 9(B) and transmits the generated product registration update screen information to the mobile terminal 50 together with the basket identification information.

[0097] Step S9: The mobile terminal 50, which has received the basket identification information and the product registration update screen information from the cloud server 20, adds the product to the registration screen. Specifically, the mobile terminal 50 displays a product registration update screen as shown in Fig. 9(B), for example. As described above, the product registration screen (product registration update screen) shown in Fig. 9(B) is displayed on the mobile terminal 50 after "XX bread" is registered as the third product item.

[0098] Step S10: The mobile terminal 50 accepts a checkout instruction as an operation by the customer, for example, by touching the "Proceed to Checkout" button shown in FIG.

[0099] Step S11: The mobile terminal 50 that has accepted the payment instruction generates a two-dimensional code. That is, the mobile terminal 50 converts information required to execute the settlement process for the items purchased by the mobile terminal 50 (for example, basket identification information) into a two-dimensional code. The mobile terminal 50 that has generated the two-dimensional code displays the generated two-dimensional code on the display unit. For example, a code display screen showing a two-dimensional code such as that shown in FIG. 9(C) is displayed on the display unit.

[0100] Step S12: The settlement device 40 scans (reads) the two-dimensional code displayed on the display unit of the mobile terminal 50. For example, the settlement device 40 scans the two-dimensional code displayed on the display unit of the mobile terminal 50 that is directed by a store clerk into the recognition range of the customer-side scanner unit 406.

[0101] Step S13: The settlement device 40 reads the two-dimensional code displayed on the display of the mobile terminal 50 and requests a calculation of the subtotal amount from the cloud server 20. For example, the settlement device 40 transmits a calculation request (subtotal amount request information) requesting calculation of the subtotal amount to the cloud server 20 together with the basket identification information obtained from the two-dimensional code (see transmission and reception data "D5" in Figs. 5 and 8).

[0102] Step S14: The cloud server 20, which has received the basket identification information and the sub-calculation output request information from the mobile terminal 50, identifies the basket of the transaction from the basket identification information.

[0103] Step S15: The cloud server 20, having identified the basket, calculates the subtotal amount of the identified basket. Specifically, the cloud server 20 calculates the subtotal amount using the selling price determination logic (see FIG. 5). For example, if the products in the basket are the three items ("XX yogurt", "XX chocolate", and "XX bread") shown in FIG. 9(B) and none of the discounts according to the selling price determination logics A, B, and C are applied, the cloud server 20 calculates the subtotal amount to be 830 yen, which is the same as the estimated amount (see FIG. 9(B)). Also, for example, if the products in the basket are the three items ("XX yogurt", "XX chocolate", and "XX bread") shown in FIG. 9(B) and "XX yogurt" is discounted by 30 yen due to the discount according to the selling price determination logic B, the cloud server 20 calculates the subtotal amount to be 800 yen, which is 30 yen less than the estimated amount (see FIG. 9(B)) of 830 yen.

[0104] Step S16: The cloud server 20, which has calculated the subtotal amount, updates the basket information (stores the subtotal amount (calculated subtotal amount)) and transmits the subtotal information indicating the calculated subtotal amount together with the basket identification information to the settlement device 40 (see transmission / reception data “D6” in Figures 5 and 8).

[0105] Step S17: The settlement device 40, which has received the basket identification information and the subtotal information from the cloud server 20, displays the subtotal on the customer display unit 405. For example, when the settlement device 40 receives subtotal information indicating the subtotal (830 yen without any discount), it displays a settlement screen on the customer display unit 405 with the subtotal 830 output in the total field as shown in Fig. 10(A). Also, for example, when the settlement device 40 receives subtotal information indicating the subtotal (800 yen with a discount of 30 yen), it displays a settlement screen on the customer display unit 405 with the subtotal 800 output in the total field as shown in Fig. 10(B).

[0106] Step S18: The settlement device 40, which has displayed the subtotal on the customer display unit 405, executes the payment (settlement). Specifically, the settlement device 40 accepts the selection of the payment type. In the case of cash, it accepts the deposit, calculates the amount of change, and, if there is change, dispenses the change and issues a receipt. Furthermore, when the settlement is completed, the settlement device 40 sends settlement completion information together with the basket information to the cloud server 20, and the cloud server 20 stores the transaction end date and time (settlement date and time) for that basket.

[0107] In the first embodiment (as well as the second and third embodiments), the cloud server 20 does not have the selling price determination logic H (payment type discount price calculation function), so an explanation is omitted. However, if the cloud server 20 has the selling price determination logic H (payment type discount price calculation function), the subtotal amount may be recalculated after the payment type is selected. Specifically, after selecting the payment type, the settlement device 40 may request the cloud server 20 to calculate the subtotal again (for example, by sending payment type selection information indicating the selected payment type to the cloud server 20 together with the basket identification information, and the cloud server 20 may recalculate the subtotal using the selling price determination logic H and resend the subtotal information indicating the recalculated subtotal together with the basket identification information to the settlement device 40). Alternatively, so that the subtotal only needs to be calculated once, the customer may be asked to select a payment type before the calculation request in step S13 (for example, before the mobile terminal 50 generates the two-dimensional code, or before the settlement device 40 reads the two-dimensional code and sends a calculation request), and the payment type selection information may also be sent to the cloud server 20 when making the calculation request in step S13.

[0108] [Checks when registering individual products] The mobile terminal 50 transmits the product code to the cloud server 20 after scanning the product (S5), but may not transmit product codes for products (e.g., products scanned after moving to another store) other than the products scanned in the store (the store when the customer visited the store and displayed the product registration initial screen). For example, the mobile terminal 50 acquires and stores location information (GPS information) when the customer visits the store (or when the product registration initial screen is displayed). The mobile terminal 50 also acquires location information when each product is scanned, and compares the location information acquired when the customer visited the store (or when the product registration initial screen is displayed). If the two match (or approximately match), the mobile terminal 50 may permit the transmission of the product code of the product to the cloud server 20, and if they do not match (or approximately match), the mobile terminal 50 may prohibit the transmission of the product code of the product to the cloud server 20. The same applies to the second and third embodiments. This makes it possible to prevent inappropriate product registration (for example, registering a product to a basket created in another store, etc.).

[0109] When the settlement device 40 prohibits the transmission of the product code as described above, it may display an error message (e.g., "Registration is not possible because it is not in the XX store") on the customer-side display unit 405 after scanning the product. Furthermore, the settlement device 40 may display the above message on the store clerk-side display unit 410 instead of or in addition to the message on the customer-side display unit 405.

[0110] [Check when reading 2D code] The settlement device 40 reads the two-dimensional code displayed on the display unit of the mobile terminal 50 and then requests the cloud server 20 to calculate the subtotal amount (S12), but may not request calculation of the subtotal amount for products other than the product scanned in the store (for example, products scanned in other stores). For example, the settlement device 40 refers to the store identification information of the store (the settlement device 40 may store and refer to the store identification information of the store in the self-settlement device 40, or may refer to the store identification information stored in another accessible device), and when reading the two-dimensional code displayed on the display unit of the mobile terminal 50, compares the basket identification information obtained from the two-dimensional code with the store identification information of the store. Then, the settlement device 40 may permit the request to calculate the subtotal amount if the store identification information included in the basket identification information (see the configuration of the basket identification information in FIG. 7(B)) is configured to include the store identification information of the store, and may prohibit the request to calculate the subtotal amount if it is not configured to include the store identification information of the store. The same applies to the second and third embodiments. This makes it possible to prevent inappropriate payments (for example, payment for products registered at other stores, etc.).

[0111] When the settlement device 40 prohibits the request for the subtotal amount as described above, after reading the two-dimensional code, the settlement device 40 may display an error message (e.g., "Settlement cannot be completed because the transaction includes products not from the XXX store") on the customer-side display unit 405. The settlement device 40 may also display the above message on the clerk-side display unit 410 instead of or in addition to the message on the customer-side display unit 405.

[0112] <Second embodiment> Next, a second embodiment will be described. In the following, the second embodiment will be described mainly with respect to the differences from the first embodiment, and the description of the parts common to the first embodiment will be omitted in part or in whole. For example, the contents described using Figures 1 to 4, 6, 7, 9, and 10 are common to each embodiment (first to third embodiments), and therefore will not be described.

[0113] FIG. 11 is a conceptual diagram of each function for explaining the shopping system according to the second embodiment. Note that FIG. 11 is for explaining the shopping system according to the second embodiment of the present invention, and the shopping system according to the second embodiment of the present invention does not necessarily include all of the configurations shown in FIG. 11. For example, the shopping system according to the second embodiment of the present invention may be configured from cloud server 20 and settlement device 40 (settlement device 41), may be cloud server 20 alone, or may be settlement device 40 (settlement device 41) alone. Also, FIG. 11 explains an excerpt of functions related to the characteristic parts of the shopping system according to the second embodiment of the present invention, and does not comprehensively explain functions generally required for a shopping system.

[0114] [Payment device 30 (Payment device 31)] As shown in the lower right of FIG. 11, the settlement device 30 has a selling price determination logic (selling price determination function) and a settlement function. In the example shown in FIG. 11, the settlement device 30 has selling price determination logic A, selling price determination logic B, selling price determination logic C, selling price determination logic D, and selling price determination logic G. That is, the difference between the settlement device 30 described in the second embodiment (see FIG. 11) and the settlement device 30 described in the first embodiment (see FIG. 5) is that the settlement device 30 described in the first embodiment has selling price determination logic A and selling price determination logic B, whereas the settlement device 30 described in the second embodiment has selling price determination logic C, selling price determination logic D, and selling price determination logic G in addition to selling price determination logic A and selling price determination logic B. In addition, in the following, in order to distinguish from the settlement device 30 described in the first embodiment, the settlement device 30 described in the second embodiment will be referred to as the settlement device 31 for convenience.

[0115] [Management device 10 (management device 11)] As shown in the upper right of FIG. 11, the management device 10 stores store information and product information. The management device 10 may include a selling price determination logic. That is, the difference between the management device 10 described in the second embodiment (see FIG. 11) and the management device 10 described in the first embodiment (see FIG. 5) is that the management device 10 described in the first embodiment may include selling price determination logic A and selling price determination logic B, whereas the management device 10 described in the second embodiment may include selling price determination logic C, selling price determination logic D, and selling price determination logic G in addition to selling price determination logic A and selling price determination logic B. In addition, for the sake of convenience, the management device 10 described in the second embodiment will be referred to as a management device 11 below in order to distinguish it from the management device 10 described in the first embodiment.

[0116] [Cloud Server 20] As shown in the upper left of Fig. 11, the cloud server 20 is provided with selling price determination logic (selling price determination function). In the example shown in Fig. 11, the cloud server 20 is provided with selling price determination logic A, selling price determination logic B, and selling price determination logic C. The cloud server 20 also stores customer information, store information, product information, and basket information. Note that there is no difference between the cloud server 20 described in the second embodiment (see Fig. 11) and the cloud server 20 described in the first embodiment (see Fig. 5), but the cloud server 20 described in the second embodiment does not use the selling price determination logic A, selling price determination logic B, and selling price determination logic C that it is provided with.

[0117] [Payment device 40 (Payment device 41)] As shown in the lower left of FIG. 11, the settlement device 40 has a cloud communication function, a mobile terminal linkage function, and a settlement function. The settlement device 40 also has a selling price determination logic A, a selling price determination logic B, and a selling price determination logic C. That is, the difference between the settlement device 40 described in the second embodiment (see FIG. 11) and the settlement device 40 described in the first embodiment (see FIG. 5) is that the settlement device 40 described in the first embodiment does not have a selling price determination logic, whereas the settlement device 40 described in the second embodiment has a selling price determination logic A, a selling price determination logic B, a selling price determination logic C, a selling price determination logic D, and a selling price determination logic G. In addition, in order to distinguish from the settlement device 40 described in the first embodiment, the settlement device 40 described in the second embodiment will be referred to as the settlement device 41 for convenience.

[0118] [Mobile device 50] As shown in the lower left of Fig. 11, the mobile terminal 50 communicates with the cloud server 20. The mobile terminal 50 registers a product by communicating with the cloud server 20. The mobile terminal 50 also generates a code to be displayed on the display unit, and displays the code on the display unit. There is no difference between the mobile terminal 50 described in the second embodiment (see Fig. 11) and the mobile terminal 50 described in the first embodiment (see Fig. 5).

[0119] The transmission and reception data "D0" to "D4" in Fig. 11 are the same as the transmission and reception data "D0" to "D4" in Fig. 5. Also, the transmission and reception data "D15" and "D16" in Fig. 11 will be explained with reference to Fig. 12.

[0120] Fig. 12 is a sequence diagram for explaining an outline of the flow of processing in the functional configuration of Fig. 11. Specifically, Fig. 12 shows an example of processing of each of the customer's mobile terminal 50, the settlement device 41 installed in the store, and the cloud server 20 installed outside a data center or the like, from when a customer visits a store, registers products displayed in the store, and completes payment for the registered products, similar to the scene in Fig. 8. The left side of Fig. 12 shows the processing of the mobile terminal 50, the center shows the processing of the settlement device 41, and the right side shows the processing of the cloud server 20.

[0121] It should be noted that steps S101 to S112 in FIG. 12 are similar to steps S1 to S12 in FIG. 8, and therefore the description thereof will be omitted.

[0122] Step S113: The settlement device 41 scans the two-dimensional code displayed on the display of the mobile terminal 50, and requests product data in the basket from the cloud server 20. For example, the settlement device 41 transmits product data request information requesting product data in the basket together with basket identification information acquired from the two-dimensional code to the cloud server 20 (see transmitted and received data "D15" in Figs. 11 and 12).

[0123] Step S114: The cloud server 20, which has received the basket identification information and the product data request information from the mobile terminal 50, identifies the basket of the transaction from the basket identification information.

[0124] Step S115: The cloud server 20 transmits the product data of the identified basket together with the basket identification information to the settlement device 41 (see the transmitted and received data "D16" in Figs. 11 and 12).

[0125] Step S116: The settlement device 41 calculates the subtotal amount having received the basket identification information and the product data from the cloud server 20. Specifically, the settlement device 41 calculates the subtotal amount using the selling price determination logic (see FIG. 11).

[0126] Step S117: The settlement device 41, having calculated the subtotal, displays the subtotal on the customer side display unit 405. Step S118: The settlement device 41, which has displayed the subtotal on the customer side display unit 405, executes the payment (settlement).

[0127] 12, the settlement device 41, which has calculated the subtotal amount, transmits subtotal information indicating the calculated subtotal amount together with the basket identification information to the cloud server 20. Furthermore, the cloud server 20, which has received the basket identification information and the subtotal information from the settlement device 41, updates the basket information (stores the subtotal amount (calculated subtotal amount)).

[0128] <Third embodiment> Next, the third embodiment will be described. In the following, the third embodiment will be described mainly with respect to the differences from the first and second embodiments, and the description of the parts common to the first and second embodiments will be omitted in part or in whole. For example, the contents described using Figures 1 to 4, 6, 7, 9, and 10 are common to each embodiment (first to third embodiments), and therefore will not be described.

[0129] FIG. 13 is a conceptual diagram of each function for explaining the shopping system according to the third embodiment. Note that FIG. 13 is for explaining the shopping system according to the third embodiment of the present invention, and the shopping system according to the third embodiment of the present invention does not necessarily include all of the configurations shown in FIG. 13. For example, the shopping system according to the third embodiment of the present invention may be configured from the cloud server 20 (cloud server 21) and the settlement device 40, or may be the cloud server 20 (cloud server 21) alone, or may be the settlement device 40 alone. Also, FIG. 13 explains an excerpt of functions related to the characteristic parts of the shopping system according to the third embodiment of the present invention, and does not comprehensively explain functions generally required for a shopping system.

[0130] [Payment device 30 (Payment device 31)] As shown in the lower right of FIG. 13, the settlement device 30 in FIG. 13 is the same as the settlement device 31 (see FIG. 11) described in the second embodiment.

[0131] [Management device 10 (management device 12)] As shown in the upper right of FIG. 13, the management device 10 of FIG. 13 stores store information and product information. The management device 10 of FIG. 13 also includes a selling price determination logic. Specifically, the management device 10 of FIG. 13 includes a selling price determination logic A, a selling price determination logic B, a selling price determination logic C, a selling price determination logic D, and a selling price determination logic G. The management device 10 of FIG. 13 also includes an external linking function. The external linking function of the management device 10 is, for example, a function of linking (communicating) with the cloud server 20 (21) regarding price determination. Specifically, the external linking function of the management device 10 includes a function of receiving a calculation request for a subtotal amount (see the transmission and reception data "D26" in FIG. 14) transmitted from the external linking function of the cloud server 20 (21), and a function of transmitting a subtotal amount calculated using the selling price determination logic based on the request (see the transmission and reception data "D6" in FIG. 14) to the external linking function of the cloud server 20 (21). Hereinafter, for the sake of convenience, the management device 11 described in the third embodiment will be referred to as the management device 12 in order to distinguish it from the management device 10 described in the first embodiment and the management device 11 described in the second embodiment.

[0132] [Cloud Server 20 (Cloud Server 21)] As shown in the upper left of FIG. 13, the cloud server 20 has a selling price determination logic (selling price determination function) and an external linkage function. In the example shown in FIG. 13, the cloud server 20 has a selling price determination logic A, a selling price determination logic B, and a selling price determination logic C. The external linkage function of the cloud server 20 is, for example, a function of linking (communicating) with the management device 12 regarding selling price determination. Specifically, the external linkage function of the cloud server 20 includes a function of transmitting a calculation request for a subtotal amount (see transmission / reception data "D26" in FIG. 14) to the external linkage function of the management device 12, and a function of receiving a subtotal amount transmitted from the external linkage function of the management device 12 (see transmission / reception data "D6" in FIG. 14). The cloud server 20 also stores customer information, store information, product information, and basket information. The cloud server 20 described in the third embodiment does not use the selling price determination logic A, selling price determination logic B, and selling price determination logic C that it is provided with. Hereinafter, for the sake of convenience, the cloud server 20 described in the third embodiment will be referred to as a cloud server 21 in order to distinguish it from the cloud server 20 described in the first and second embodiments.

[0133] [Payment device 40] As shown in the lower left of FIG. 13, the settlement device 40 in FIG. 13 is no different from the settlement device 40 (see FIG. 5) described in the first embodiment.

[0134] [Mobile device 50] As shown in the lower left of FIG. 13, the mobile terminal 50 in FIG. 13 is no different from the mobile terminal 50 (see FIGS. 5 and 11) described in the first and second embodiments.

[0135] The transmission and reception data "D0" to "D6" in Fig. 13 are similar to the transmission and reception data "D0" to "D6" in Fig. 5. The transmission and reception data "D26" in Fig. 13 will be described with reference to Fig. 14.

[0136] Fig. 14 is a sequence diagram for explaining an outline of the flow of processing in the functional configuration of Fig. 13. Specifically, Fig. 14 shows an example of processing of each of the customer's mobile terminal 50, the settlement device 40 installed in the store, and the cloud server 21 installed outside a data center or the like, from when a customer visits a store, registers products displayed in the store, and completes payment for the registered products, similar to the scenes of Fig. 8 and Fig. 12. The left side of Fig. 14 shows the processing of the mobile terminal 50, the center shows the processing of the settlement device 40, and the right side shows the processing of the cloud server 21.

[0137] It should be noted that steps S201 to S214 in FIG. 14 are similar to steps S1 to S14 in FIG. 8, and therefore the description thereof will be omitted.

[0138] Step S215: Having identified the basket, the cloud server 21 requests the management device 12 to calculate the subtotal amount. For example, the cloud server 21 transmits a calculation request (subtotal amount request information) requesting calculation of the subtotal amount to the management device 12 together with the product data of the basket identified in step S214 and the basket identification information (see transmitted / received data "D26" in FIGS. 13 and 14).

[0139] Step S216: The management device 12 calculates the subtotal amount having received the basket identification information, the subcalculation request information, and the product data from the cloud server 21. Specifically, the management device 12 calculates the subtotal amount using the selling price determination logic (see FIG. 13).

[0140] Step S217: Having calculated the subtotal amount, the management device 12 transmits subtotal information indicating the calculated subtotal amount together with the basket identification information to the cloud server 21 (see transmission / reception data "D6" in FIGS. 13 and 14).

[0141] Step S218: The cloud server 21, having received the basket identification information and the subtotal information from the management device 12, updates the basket information (stores the subtotal amount (calculated subtotal amount)) and transmits the basket identification information and the subtotal information received from the management device 12 to the settlement device 40 (see transmission / reception data “D6” in Figures 13 and 14).

[0142] Step S219: The settlement device 40, having received the basket identification information and the subtotal information from the cloud server 21, displays the subtotal amount on the customer side display unit 405. Step S220: The settlement device 40, which has displayed the subtotal on the customer side display unit 405, executes the payment (settlement).

[0143] The transmission and reception of various information (transmitted and received data "D26" and transmitted and received data "D6") in steps S215 to S216 and steps S217 to S218 is realized by an external linkage function on the cloud server 21 side and an external linkage function on the management device 12 side.

[0144] The flow of operations will be described in more detail below. Fig. 15 and Fig. 16 are flow charts showing an example of a more detailed operation flow when registering a product. Specifically, Fig. 15 and Fig. 16 explain the range of steps S5 to S11 in Fig. 8 described as the first embodiment, steps S105 to S111 in Fig. 12 described as the second embodiment, and steps S205 to S211 in Fig. 14 described as the third embodiment, taking into consideration the case where there are reserved products or cancellations. Fig. 16 is a continuation of Fig. 15. Note that some of the contents explained in Fig. 8 etc. are omitted.

[0145] Step S30: The mobile terminal 50 judges whether or not an operation to scan a barcode attached to a product has been performed. For example, the mobile terminal 50 includes various sensors (e.g., a gyro sensor, an acceleration sensor, a distance sensor, etc.), and when it is judged that the mobile terminal 50 has maintained the position for reading a barcode for a predetermined time after the various sensors have judged that the mobile terminal 50 has become in a position for reading a barcode (i.e., when the position for reading a barcode is maintained for a predetermined time or more), or when the barcode is read within the predetermined time (i.e., when the product code is acquired), it judges that an operation to scan a barcode attached to a product has been performed. When it is judged that an operation to scan a barcode has been performed, the process of the mobile terminal 50 proceeds to step S31. When it is judged that an operation to scan a barcode has not been performed, the process of the mobile terminal 50 proceeds to step S50 in FIG. 16.

[0146] Step S31: The mobile terminal 50 judges whether or not the reading of the product code has been successful. If it is judged that the reading of the product code has been successful, the processing of the mobile terminal 50 proceeds to step S32. If it is judged that the reading of the product code has failed, the processing of the mobile terminal 50 proceeds to step S45.

[0147] Step S32: The mobile terminal 50 transmits the product code obtained by scanning together with the basket identification information to the cloud server 20 (21). Then, the process of the mobile terminal 50 proceeds to step S41.

[0148] Step S33: The cloud server 20 (21) determines whether or not the basket identification information and the product code have been received. If the basket identification information and the product code have been received, the process of the cloud server 20 (21) proceeds to step S34. If the basket identification information and the product code have not been received, the process of the cloud server 20 (21) proceeds to step S48.

[0149] Step S34: The cloud server 20 (21) refers to the product information of the store. Specifically, the cloud server 20 (21) refers to the product information of the store and identifies (attempts to identify) the product of the product code received from the mobile terminal 50. In other words, the cloud server 20 (21) checks whether the product code received from the mobile terminal 50 is stored in the product information of the store. Then, the process of the cloud server 20 (21) proceeds to step S35.

[0150] Step S35: If the product corresponding to the product code received from the mobile terminal 50 can be identified, the process of the cloud server 20 (21) proceeds to step S36. If the product corresponding to the product code received from the mobile terminal 50 cannot be identified, the process of the cloud server 20 (21) proceeds to step S38.

[0151] Step S36: The cloud server 20 (21) stores the registered product information in the basket. Specifically, the cloud server 20 (21) stores the product code, product name, price, etc. as the registered product information. Then, the process of the cloud server 20 (21) proceeds to step S37. Step S37: The cloud server 20 (21) generates product registration update screen information (screen information of the product registration screen reflecting the registered product information of step S36) and transmits it to the mobile terminal 50. Then, the process of the cloud server 20 (21) proceeds to step S48.

[0152] Step S38: The cloud server 20 (21) stores the reserved product information in the basket. Specifically, the cloud server 20 (21) stores the reserved product type "1 (NON-PLU)" and the product code as the reserved product information. The process of the cloud server 20 (21) then proceeds to step S39. Step S39: The cloud server 20 (21) generates product registration update screen information (screen information of the product registration screen reflecting the reserved product information of step S38) and transmits it to the mobile terminal 50. Then, the process of the cloud server 20 (21) proceeds to step S40. Step S40: Cloud server 20 (21) transmits an error message (NO-FILE) to mobile terminal 50. Then, the process of cloud server 20 (21) proceeds to step S48.

[0153] Step S41: The mobile terminal 50 judges whether or not an error message has been received. If it is judged that an error message has been received, the process of the mobile terminal 50 proceeds to step S43. If it is judged that an error message has not been received, the process of the mobile terminal 50 proceeds to step S42.

[0154] Step S42: The mobile terminal 50 updates the registration screen. That is, the display unit of the mobile terminal 50 displays a registration screen reflecting the scanning operation of step S30 (a registration screen on which the scanned product is added and displayed). Then, the processing of the mobile terminal 50 proceeds to step S50 in FIG.

[0155] Step S43: The mobile terminal 50 updates the registration screen. That is, the display unit of the mobile terminal 50 displays a registration screen reflecting the scanning operation of step S30 (a registration screen in which the scanned product is added as a reserved product (NO-FILE)). Then, the processing of the mobile terminal 50 proceeds to step S44. Step S44: The mobile terminal 50 displays an error message. Specifically, the mobile terminal 50 displays an error message indicating that the product scanned in step S30 is a reserved product (NO-FILE). Note that the mobile terminal 50 may display a message instructing the user to keep the reserved product separate from products other than the reserved product in the shopping cart, instead of or in addition to the error message indicating that the product is a reserved product (NO-FILE). The mobile terminal 50 then proceeds to step S50 in FIG. 16 as its processing.

[0156] Step S45: The mobile terminal 50 captures an image of the product (the product whose product code has not been read successfully) and transmits the captured image (image data) together with the basket identification information to the cloud server 20 (21). In addition to transmitting the captured image to the cloud server 20 (21), the mobile terminal 50 may store the captured image in a storage unit. Then, the process of the mobile terminal 50 proceeds to step S46. Step S46: The mobile terminal 50 updates the registration screen. That is, the display unit of the mobile terminal 50 displays a registration screen reflecting the scanning operation of step S30 (a registration screen in which the scanned product is added as a reserved product (unreadable)). Then, the processing of the mobile terminal 50 proceeds to step S47.

[0157] Step S47: The mobile terminal 50 displays an error message. Specifically, the mobile terminal 50 displays an error message indicating that the product scanned in step S30 is a reserved product (unreadable). Note that the mobile terminal 50 may display a message instructing the user to keep the reserved product separate from other products in the shopping cart, instead of or in addition to the error message indicating that the product is a reserved product (unreadable). The mobile terminal 50 then proceeds to step S50 in FIG. 16 as a process.

[0158] Step S48: The cloud server 20 (21) determines whether or not image data has been received. If image data has been received, the process of the cloud server 20 (21) proceeds to step S49. If image data has not been received, the process of the cloud server 20 (21) proceeds to step S52 in FIG. 16.

[0159] Step S49: The cloud server 20 (21) stores the reserved product information in the basket. Specifically, the cloud server 20 (21) stores the reserved product type "1 (unreadable)" and the image data received in step S48 as the reserved product information. The process of the cloud server 20 (21) then proceeds to step S52 in FIG. 16.

[0160] Step S50: The mobile terminal 50 determines whether or not an operation to cancel a registered product (a product whose registered product information was stored in the basket in step S36) has been performed (for example, an operation to select a product displayed on the registration screen by touching it, and then touching a cancel button that is displayed after selection). If it is determined that an operation to cancel a registered product has been performed, the processing of the mobile terminal 50 proceeds to step S51. If it is determined that an operation to cancel a registered product has not been performed, the processing of the mobile terminal 50 proceeds to step S60.

[0161] Step S51: The mobile terminal 50 transmits product cancellation information together with the basket identification information to the cloud server 20 (21). The product cancellation information includes, for example, the product code and quantity of the product to be canceled. The processing of the mobile terminal 50 then proceeds to step S56. There are various possible methods for the mobile terminal 50 to acquire the product code of the product to be canceled. For example, the product code of the registered product may be stored (memorized) in the product registration update screen information that the cloud server 20 (21) transmits to the mobile terminal 50, and the mobile terminal 50 may acquire the product code of the product to be canceled from the product registration update screen information.

[0162] Step S52: The cloud server 20 (21) determines whether or not the basket identification information and the cancellation information have been received. If the basket identification information and the cancellation information have been received, the processing of the cloud server 20 (21) ends. After the processing ends, the processing of the cloud server 20 (21) starts again from step S33 in FIG. 15. If the basket identification information and the cancellation information have been received, the processing of the cloud server 20 (21) proceeds to step S53.

[0163] Step S53: The cloud server 20 (21) deletes the registered product information in the basket. Specifically, the cloud server 20 (21) deletes the product registration information in the basket indicated by the basket identification information and the cancellation information. The processing of the cloud server 20 (21) then proceeds to step S54. When the cloud server 20 (21) receives cancellation information to cancel some of the multiple registered products, it updates the number of the registered products. For example, when it receives cancellation information to cancel two of the five registered registered products, it updates the number of the registered products from five to three.

[0164] Step S54: Cloud server 20 (21) stores the cancellation information in the basket. Specifically, cloud server 20 (21) stores the product code, quantity, etc. as the cancellation information. Then, the process of cloud server 20 (21) proceeds to step S55.

[0165] Step S55: The cloud server 20 (21) generates product registration update screen information (screen information of the product registration screen reflecting the deletion of the registered product information in step S53 or the cancellation information in step S54) and transmits it to the mobile terminal 50. Then, the processing of the cloud server 20 (21) ends. After the processing ends, the processing of the cloud server 20 (21) starts again from step S33 in FIG. 15.

[0166] Step S56: The mobile terminal 50 updates the registration screen. That is, the display unit of the mobile terminal 50 displays a registration screen reflecting the cancellation operation of step S50 (a registration screen in which the registered product has been deleted, and a registration screen in which the number of registered products has been reduced). Then, the processing of the mobile terminal 50 proceeds to step S60.

[0167] Step S60: The mobile terminal 50 determines whether or not a payment instruction has been given (for example, touching the "Proceed to Payment" button shown in FIG. 9(B)). If it determines that a payment instruction has been given, it proceeds to step S61. If it determines that a payment instruction has not been given, it returns to step S30.

[0168] Step S61: The mobile terminal 50 generates a two-dimensional code. That is, the mobile terminal 50 converts information (e.g., basket identification information) required for executing a settlement process for the products purchased by the mobile terminal 50 into a two-dimensional code. Then, the process of the mobile terminal 50 proceeds to step S62. Step S62: The portable terminal 50 displays the two-dimensional code generated in step S61 on the display unit, and the process of the portable terminal 50 ends.

[0169] Fig. 17 is a flow chart showing an example of a more detailed operation flow at the time of payment. Specifically, Fig. 17 explains the range of steps S12 to S18 in Fig. 8 explained as the first embodiment, taking into consideration the case where there are reserved products or cancellations. Note that some of the contents explained in Fig. 8 are omitted.

[0170] Step S70: The settlement device 40 judges whether or not the two-dimensional code displayed on the display unit of the mobile terminal 50 has been read. If it is judged that the two-dimensional code has been read, the process proceeds to step S71. If it is judged that the two-dimensional code has not been read, the process repeats step S70. Step S71: The settlement device 40 requests the calculation of the subtotal amount to the cloud server 20. For example, the settlement device 40 transmits a calculation request (subtotal amount request information) requesting calculation of the subtotal amount to the cloud server 20 together with the basket identification information acquired from the two-dimensional code.

[0171] Step S72: The cloud server 20 judges whether or not the basket identification information and the sub-calculation output request information are received. If the basket identification information and the sub-calculation output request information are received, the process proceeds to step S73. If the basket identification information and the sub-calculation output request information are not received, the process repeats step S71.

[0172] Step S73: Cloud server 20 identifies the basket for which the settlement device 40 has requested calculation of the subtotal amount. Specifically, cloud server 20 identifies the basket for which the settlement device 40 has requested calculation of the subtotal amount, from the basket identification information received from the settlement device 40. Then, the processing of cloud server 20 proceeds to step S74. Step S74: Cloud server 20 identifies the customer requesting calculation of the subtotal amount (the customer related to the basket). Specifically, cloud server 20 identifies the customer requesting calculation of the subtotal amount from the customer identification information in the basket identified in step S72. Then, the process of cloud server 20 proceeds to step S75.

[0173] Step S75: Cloud server 20 checks the cancellation status of the customer requesting calculation of the subtotal amount (the customer identified in step S74). Specifically, cloud server 20 checks the past cancellation status of the customer by referring to the cancellation information in the customer information (see FIG. 7(A)) of the customer. Note that cloud server 20 may check the current cancellation status of the customer by referring to the cancellation information (cancellation information (current total), etc.) in the basket information (FIG. 7(C)) instead of or in addition to the cancellation information in the customer information (see FIG. 7(A)) of the customer. Then, the processing of cloud server 20 proceeds to step S76.

[0174] Step S76: Cloud server 20 judges whether a warning is necessary based on the confirmed cancellation status. For example, in the aspect of checking the past cancellation status in step S75, cloud server 20 may compare the total number of cancellations for the past two visits (the previous visit and the visit before last) with a predetermined threshold (threshold A), and may judge that a warning is necessary if the total number of cancellations for the past two visits is equal to or greater than threshold A, and may judge that a warning is unnecessary if the total number of cancellations for the past two visits is less than threshold A. Also, for example, in the mode in which both the current cancellation status and the past cancellation status are confirmed in step S75, the cloud server 20 may compare the current cancellation count with a predetermined threshold (threshold B), and also compare the total number of cancellations of the past two cancellations with a predetermined threshold (threshold C), and determine that a warning is necessary if the current cancellation count is equal to or greater than threshold B and the total number of cancellations of the past two cancellations is equal to or greater than threshold C, and may determine that a warning is unnecessary in other cases (if the current cancellation count is less than threshold B (regardless of the total number of cancellations of the past two cancellations), if the current cancellation count is equal to or greater than threshold B but the total number of cancellations of the past two cancellations is less than threshold C). Also, for example, in the mode in which the current cancellation status is confirmed in step S75, the cloud server 20 may compare the current cancellation count with a predetermined threshold (threshold D), and determine that a warning is necessary if the current cancellation count is equal to or greater than threshold D, and determine that a warning is unnecessary if the current cancellation count is less than threshold D. Note that the thresholds A to D may all be different numbers, or two or more may be the same number. If it is determined that a warning is necessary, the process proceeds to step S77, whereas if it is determined that a warning is not necessary (unnecessary), the process proceeds to step S80.

[0175] Step S77: Cloud server 20 transmits warning information to settlement device 40. Then, the processing of cloud server 20 proceeds to step S80.

[0176] Step S78: The settlement device 40 judges whether or not warning information has been received. If warning information has been received, the process proceeds to step S79. If warning information has not been received, the process proceeds to step S82. Step S79: The settlement device 40 issues a warning. For example, the settlement device 40 may display a message on the customer-side display unit 405 to the effect that the store clerk should confirm the contents of the product. Also, instead of or in addition to the above, the settlement device 40 may display a message on the store clerk-side display unit 410 to the effect that the cancellation of the product should be confirmed. The settlement device 40 may display a message using a specific numerical value on the store clerk-side display unit 410 (for example, if the past cancellation status is confirmed in step S75, a message indicating that the cancellation record for the customer is xx times or more than the standard, or if the current cancellation status is confirmed in step S75, a message indicating that the current transaction cancellations for the customer are xx times or more than the standard).

[0177] Step S80: The cloud server 20 determines whether there is a reserved product (NON-PLU, reading NG) in the basket information. If it is determined that there is a reserved product, the process proceeds to step S81. If it is determined that there is no reserved product, the process proceeds to step S88. Step S81: The cloud server 20 transmits information instructing the settlement device 40 to correct the reserved products in the basket information (correction instruction information). Then, the process of the cloud server 20 proceeds to step S86.

[0178] Step S82: The settlement device 40 judges whether or not the correction instruction information has been received. If the correction instruction information has been received, the process proceeds to step S83. If the correction instruction information has not been received, the process proceeds to step S90.

[0179] Step S83: The settlement device 40 notifies the customer that there is a reserved item. For example, the settlement device 40 displays a message indicating that there is a reserved item on either the customer side display unit 405 or the store clerk side display unit 410, or on both. For example, the settlement device 40 may display a small screen on the customer side display unit 405 that displays a message indicating that the store clerk should check the contents of the item (see FIG. 10(C)). Alternatively or in addition to the above, the settlement device 40 may display a message indicating that there is a reserved item on the store clerk side display unit 410. The process of the settlement device 40 then proceeds to step S84.

[0180] Step S84: The settlement device 40 accepts the correction of the reserved item by the store clerk. For example, for the reserved item (not readable), the store clerk scans the item (for example, the same item on the display shelf). Also, for example, for the reserved item (NON-PLU), the store clerk inputs the price. The store clerk may cancel the reserved item (not readable, NON-PLU). In other words, in either method, the reserved item may be eliminated by accepting the correction of the reserved item by the store clerk. Note that the cancellation by the store clerk may not be reflected in the current cancellation count in the basket information (and therefore in the past cancellation count in the customer information, since the past cancellation count in the customer information is based on the current cancellation count in the basket information). As an example, the cancellation operation by the store clerk may be a special cancellation operation (different from the cancellation operation performed by the customer), and when the special cancellation operation is performed, it may not be reflected in the current cancellation count. Step S85: The settlement device 40 transmits correction information, which indicates the correction content of the reserved product made by the store clerk, together with the basket identification information to the cloud server 20. Then, the process of the settlement device 40 proceeds to step S90.

[0181] Step S86: The cloud server 20 judges whether or not the basket identification information and the modification information have been received. If the basket identification information and the modification information have been received, the process proceeds to step S87. If the basket identification information and the modification information have not been received, the process repeats step S86. Step S87: Cloud server 20 updates the basket information in accordance with the revision information, and the process of cloud server 20 proceeds to step S88.

[0182] Step S88: Cloud server 20 calculates the subtotal amount of the basket. Then, the process of cloud server 20 proceeds to step S89. Step S89: Cloud server 20 updates the basket information (stores the subtotal amount (calculated subtotal amount)), and transmits subtotal information indicating the calculated subtotal amount together with the basket identification information to settlement device 40. Then, the processing of cloud server 20 ends.

[0183] Step S90: The settlement device 40 displays the subtotal on the customer side display unit 405. Step S91: The settlement device 40 executes payment (settlement). Then, the process of the settlement device 40 ends. When the process of step S91 ends, information that the settlement has been completed is transmitted to the cloud server 20.

[0184] Fig. 18 is an example of information stored in the basket information. Note that Fig. 18 shows a part of the basket information shown in Fig. 7(C).

[0185] Fig. 18(A) shows the information stored in the basket information when the first product ("XX yogurt") is registered normally (when it is not a reserved product). In the example shown in Fig. 18(A), the quantity "1" and the estimated subtotal amount "260" are stored as registered product information (total), and the product code "S5111" of "XX yogurt", the product name "XX yogurt", and the price "260" of "XX yogurt" are stored as registered product information (registered product 1).

[0186] When the cloud server 20 (21) receives the product code of the first product and identifies the product with the product code ("XX yogurt") (step S35 (YES) in FIG. 15), it stores the registered product information (total) as shown in FIG. 18 (A) and stores the registered product information (registered product 1) as shown in FIG. 18 (A) (step S36). That is, the registered product information (registered product 1) is stored (step S36) when the mobile terminal 50 successfully reads the product code ("S5111") of the first product ("XX yogurt") (step S31 (YES) in FIG. 15), the product code ("S5111") is transmitted to the cloud server 20 (21) (step S32), and the product with the product code ("S5111") ("XX yogurt") is identified in the cloud server 20 (21) (step S35 (YES)).

[0187] Fig. 18(B) shows information stored in the basket information when up to three items of products ("XX bread") have been registered normally. In the example shown in Fig. 18(B), the number of items "3" and the estimated subtotal amount "830" are stored as registered product information (total), the product code "S5111" of "XX yogurt" and the product name "XX yogurt" and the price "260" of "XX yogurt" are stored as registered product information (registered product 1), the product code "S3083" of "XX chocolate" and the product name "XX chocolate" and the price "350" of "XX chocolate" are stored as registered product information (registered product 2), and the product code "S1493" of "XX bread" and the price "220" of the product name "XX bread" and "XX bread" are stored as registered product information (registered product 3).

[0188] When the cloud server 20 (21) receives the product code of the third product and identifies the product with that product code ("XX bread") (step S35 (YES) in FIG. 15), it updates the registered product information (total) as shown in FIG. 18 (B) and stores the registered product information (registered product 3) as shown in FIG. 18 (B) (step S36). The registered product information (registered product 1) was stored when the first product ("XX yogurt") was identified (step S36). The registered product information (registered product 2) was stored when the second product ("XX chocolate") was identified (step S36).

[0189] Fig. 18(C) shows information stored in the basket information when, for example, "XX bread" is cancelled from the state of Fig. 18(B). In the example shown in Fig. 18(C), the number of items "2" and the estimated subtotal amount "610" are stored as registered product information (total), the product code "S5111" of "XX yogurt", the product name "XX yogurt", and the price "260" of "XX yogurt" are stored as registered product information (registered product 1), the product code "S3083" of "XX chocolate", the product name "XX chocolate", and the price "350" of "XX chocolate" are stored as registered product information (registered product 2), the number of cancellations "1" is stored as cancellation information (current total), and the product code "S1493" of "XX bread" and the quantity "1" are stored as cancellation information (cancellation 1).

[0190] When the cloud server 20 (21) receives the product cancellation information (including the product code of "XX bread") (step S52 (YES) in FIG. 16), it updates the registered product information (total) as shown in FIG. 18 (C), deletes the registered product information (registered product 3) as shown in FIG. 18 (C) (step S53), stores the cancellation information (current total) as shown in FIG. 18 (C), and stores the cancellation information (cancellation 1) (step S54). That is, when an operation is performed on the mobile terminal 50 to cancel the already registered third item of the product "XX bread" (step S50 (YES) in FIG. 16), the product cancellation information (including the product code of "XX bread") is sent to the cloud server 20 (21) (step S51), the registered product information of the product "XX bread" is deleted in the cloud server 20 (21) (step S53), and the cancellation information of the product "XX bread" is stored (step S54).

[0191] Figure 18 (D) shows the information stored in the basket information when the first product ("XX yogurt") is registered normally, the second product ("XX chocolate") is a reserved product (NON-PlU), and the third product ("XX bread") is a reserved product (cannot be read). In the example shown in Figure 18 (D), the number of items "1" and the estimated subtotal amount "260" are stored as registered product information (total), the product code "S5111" of "XX yogurt", the product name "XX yogurt", and the price "260" of "XX yogurt" are stored as registered product information (registered product 1), the total number of items "2", the number of NON-PLU items "1", and the number of items that cannot be read (check for unauthorized operation) "1" are stored as reserved product information (total), the reserved product type "1 (NON-PLU)" and the product code "S3083" of "XX chocolate" are stored as reserved product information (reserved product 1), and the reserved product type "2 (Cannot be read)" and the captured image "AAA.jpeg" in which the portion including the barcode of "XX bread" is captured are stored as reserved product information (reserved product 2).

[0192] The reserved product information (reserved product 1) is stored (step S38) when the mobile terminal 50 successfully reads the product code ("S3083") of the second product ("XX Chocolate") (step S31 (YES) in FIG. 15) and sends the product code ("S3083") to the cloud server 20 (21) (step S32), but the product with the product code ("S3083") (actually "XX Chocolate") is not identified (step S35 (NO)) in the cloud server 20 (21).

[0193] The reserved product information (reserved product 2) is stored (step S49) when the mobile terminal 50 fails to read the product code ("S1493") of the third product ("XX bread") (step S31 (NO) in FIG. 15), image data of the product ("XX bread") is sent to the cloud server 20 (21) (step S45), and the cloud server 20 (21) receives the image data (step S48 (YES)).

[0194] The embodiments have been described above, and the concept of each embodiment will now be described. In the shopping system of the first embodiment shown in FIG. 5, the settlement device 40 may be a device newly installed (delivered) to a store in order to use the service provided by the cloud server 20. In other words, the shopping system of the first embodiment shown in FIG. 5 may be constructed by additionally introducing a settlement device 40, which is a new terminal equipped with functions required for using the service provided by the cloud server 20 (mobile terminal linkage function, cloud communication function), in addition to the settlement device 30 originally installed in the store when starting to use the service provided by the cloud server 20. In other words, the shopping system of the first embodiment is constructed based on the concept that, for example, when starting to use a service provided by an existing external cloud server 20, it is sufficient to simply additionally install a settlement device 40, which is a new terminal, without modifying the existing settlement device 30 or management device 10 (although the management device 10 has some additional functions such as transmitting store information and product information), and the service provided by the cloud server 20 can be introduced in a short period of time (although the cloud server 20 has some additional functions such as receiving store information and product information).

[0195] Before the self-service system (self-registration system, self-scan system) is introduced by the cloud server 20, the selling price determination logic (selling price determination logic A, B) used in the existing system (management device 10, settlement device 30) is within the range of selling price determination logic (selling price determination logic A, B, C) that the cloud server 20 can provide, so there is no need to use the existing selling price determination logic when introducing the self-service system by the cloud server 20. Therefore, it is sufficient to simply add a new terminal, settlement device 40, and the cost of introduction can be reduced. In the example shown in FIG. 5, the cloud server 20 implements the selling price determination logic C, but does not operate it.

[0196] In the shopping system of the second embodiment shown in FIG. 11, the settlement device 41 may be a device obtained by modifying the settlement device 40 shown in FIG. 5 or the existing settlement device 31 in order to use the service provided by the cloud server 20. In other words, the shopping system of the first embodiment shown in FIG. 11 may be constructed by adding functions required for using the service provided by the cloud server 20 (selling price determination logic for the settlement device 40 as a new terminal, and a mobile terminal linkage function and a cloud communication function for the settlement device 31) to the settlement device 40 as a new terminal or the settlement device 31 originally installed in the store when starting to use the service provided by the cloud server 20. In other words, the shopping system of the second embodiment is constructed based on the concept that, for example, when starting to use the service provided by the existing external cloud server 20, the service provided by the cloud server 20 can be introduced in a short period of time by modifying the settlement device 40 as a new terminal or the existing settlement device 31 (although some functions such as sending and receiving store information and product information are added to the management device 10 and the cloud server 20).

[0197] Before the self-service system is introduced by the cloud server 20, the selling price determination logic (selling price determination logic A, B, C, D, G) operated by the existing system (management device 11, settlement device 31) is not within the range of selling price determination logic (selling price determination logic A, B, C) that the cloud server 20 can provide. Therefore, when the self-service system is introduced by the cloud server 20, functions are added to the already existing settlement devices (settlement device 40, settlement device 31), but the cost of introduction can be relatively reduced. This is effective when it is determined that it is easier to renovate the settlement device than to renovate the cloud server or management device. In the example shown in FIG. 11, the cloud server 20 implements the selling price determination logic (selling price determination logic A, B, C) but does not operate it.

[0198] In the shopping system of the third embodiment shown in Fig. 13, settlement device 40 may be a device newly installed (delivered) to a store in order to use the service provided by cloud server 21. In other words, the shopping system of the third embodiment shown in Fig. 13 may be constructed by modifying cloud server 20 (by adding an external linkage function) to become cloud server 21, modifying management device 11 originally installed in the store (by adding an external linkage function) to become management device 12, and additionally introducing settlement device 40, which is a new terminal equipped with functions (mobile terminal linkage function, cloud communication function) required to use the service provided by cloud server 21, in addition to settlement device 30 originally installed in the store. In other words, the shopping system of the third embodiment is constructed based on the concept that, for example, when starting to use a service provided by an existing external cloud server 20, no modifications are required to the existing settlement device 31, but modifications are made to the existing cloud server 20 and management device 11, and then the service provided by the modified cloud server 21 can be introduced in a short period of time by simply installing a new terminal, that is, a settlement device 40.

[0199] Before the self-service system using the cloud server 20 is introduced, the selling price determination logic (selling price determination logic A, B, C, D, G) operated in the existing system (management device 11, settlement device 31) is not within the range of selling price determination logic (selling price determination logic A, B, C) that the cloud server 20 can provide. Therefore, when the self-service system using the cloud server 20 is introduced, the cloud server 20 is modified to the cloud server 21 (adding an external linkage function) and the management device 11 is modified to the management device 12 (adding an external linkage function), but the cost of introduction can be relatively reduced. This is effective when it is determined that modifying the cloud server or management device is easier than modifying the settlement device. In the example shown in FIG. 13, the cloud server 21 implements the selling price determination logic (selling price determination logic A, B, C) but does not operate it.

[0200] In the above description, cloud server 20 is modified (by adding an external linking function) to become cloud server 21, but cloud server 20 may originally have the external linking function. If cloud server 20 has the external linking function, modification of cloud server 20 is not required in the shopping system of the third embodiment, which further reduces the introduction cost.

[0201] Generally, the challenges (barriers) that may arise when introducing a new system are as follows, depending on the approach taken: 1. When adopting an approach of modifying an existing system, it is difficult to add controls such as a smartphone communication unit and a shopping cart storage unit to the existing system (a system must be created each time to suit each store. In other words, a system must be created for each store). 2. On the other hand, if you choose to keep the existing system and launch a separate system, it will be difficult to create and operate a selling price determination logic similar to that of the existing system (as mentioned above, you will need to create a selling price determination logic for each store). Since selling price determination logic is essentially an accumulation of the customer's unique know-how and sales spirit, it is not easy to work with it depending on the location of implementation. Both 1 and 2 above impose a heavy burden on both the store and the system proposer.

[0202] In contrast to this, the shopping system described in each embodiment is a mechanism that utilizes existing selling price determination logic, so that any store can leave its existing system as is (while operating the management devices 10, 11, 12 and the settlement devices 30, 31) and achieve coexistence with the new system, thereby solving both problems 1 and 2 above.

[0203] Although each embodiment has been described above, further supplementary explanations will be given for each embodiment. For example, in the example shown in Fig. 17, a warning regarding product cancellation is issued on the settlement device 40 (customer side display unit 405, store clerk side display unit 410) (step S79 in Fig. 17), but for example, instead of the settlement device 40, a warning regarding product cancellation may be issued on the store clerk's mobile terminal by sending warning information to the store clerk's mobile terminal carried by the store clerk, or a warning regarding product cancellation may be issued on a monitoring device (not shown) that monitors the settlement devices (settlement device 30, settlement device 40 (41)) by sending warning information to the monitoring mobile terminal. Also, in the example shown in Figure 17, notifications regarding pending items are made on the settlement device 40 (customer display unit 405, store clerk display unit 410) (step S83 in Figure 17), but for example, instead of or in addition to the settlement device 40, notifications regarding pending items may be made on the store clerk's portable terminal by sending correction instruction information, etc. to the store clerk's portable terminal, or correction instruction information, etc. may be sent to the monitoring device and notifications regarding pending items may be made on the monitoring device.

[0204] In the above embodiment, each setting information referred to by each selling price determination logic may be information separate from the product information, or may be a part of the product information. For example, in the case of the cloud server 20 shown in FIG. 5, the cloud server 20 may store information on price changes referred to by the selling price determination logic A, information on single item discount setting referred to by the selling price determination logic B, and information on subtotal discount setting referred to by the selling price determination logic C, in addition to the product information, and the product information stored by the cloud server 20 may include information on price changes referred to by the selling price determination logic A, information on single item discount setting referred to by the selling price determination logic B, and information on subtotal discount setting referred to by the selling price determination logic C. Alternatively, the information on price changes referred to by the selling price determination logic A may be contained in the selling price determination logic A (the same applies to the selling price determination logics B and C). The same applies to the selling price determination general logic.

[0205] In the third embodiment, the settlement device 41 includes the selling price determination logics A, B, C, D, and G, but does not include product information. Therefore, in a case where the product information includes the setting information referred to by the selling price determination logic (in other words, in a case where the setting information is not included in the selling price determination logic, or the setting information is not stored separately from the product information in the settlement device 41, that is, in a case where the settlement device 41 does not hold the setting information in its own device), the settlement device 41 refers to the setting information stored in the cloud server 20 (the setting information included in the product information, or the setting information stored separately from the product information) when calculating the subtotal amount (when using the selling price determination logic). In addition, the settlement device 41 may refer to the setting information stored in the management device 11 (the setting information included in the product information, or the setting information stored separately from the product information) instead of or in addition to the setting information stored in the cloud server 20 when calculating the subtotal amount. In addition, when the information stored in management device 11 is newer than the information stored in cloud server 20 (when the information is reflected on the cloud server 20 side by batch processing), the information stored in management device 11 may be referenced.

[0206] In the above embodiment, the flow of the process after the product registration is completed is that the settlement device 40 (41) reads the code displayed by the mobile terminal 50, but other flows are also possible. For example, the calculation of the subtotal amount may be started when the mobile terminal 50 makes a request to the cloud server 20 (20) as a trigger.

[0207] For example, in the first embodiment, the mobile terminal 50 obtains device identification information (settlement device number) of the settlement device 40 that executes the settlement process, and the mobile terminal 50 transmits sub-calculation output request information to the cloud server 20 together with the basket identification information and device identification information, and the cloud server 20 transmits subtotal information including the subtotal amount calculated by its own device to the settlement device 40 identified by the device identification information. In the second embodiment, the mobile terminal 50 acquires device identification information (settlement device number) of the settlement device 41 that performs the settlement process, and the mobile terminal 50 transmits product data request information together with the basket identification information and device identification information to the cloud server 20, and the cloud server 20 transmits the product data in the basket to the settlement device 41 identified by the device identification information. In the third embodiment, the mobile terminal 50 acquires device identification information (settlement device number) of the settlement device 40 that executes the settlement process, and the mobile terminal 50 transmits sub-calculation output request information together with the basket identification information and device identification information to the cloud server 21, and the cloud server 21 transmits subtotal information including the subtotal amount calculated by the management device 11 to the settlement device 40 identified by the device identification information.

[0208] In the above embodiment, the portable terminal 50 automatically releases the shutter to acquire a captured image (image data) of the product when the product is marked as pending (reading NG), i.e., when reading of the product fails (when time-out processing occurs) (step S45 in FIG. 15), but the portable terminal 50 may release the shutter at the timing of the customer (based on the customer's operation) when the product is marked as pending (reading NG). For example, the portable terminal 50 may switch to a customer-operated shutter mode when reading of the product fails (when time-out processing occurs).

[0209] In addition, in the case where reading is NG (the same applies to the case of a self-declared product described later), if the shutter is released based on the customer's operation, the customer may be instructed to perform an image capture operation (for example, a message may be displayed on the registration screen). Also, if the shutter is released based on the customer's operation (if image data is acquired), the image data may be automatically transmitted to the cloud server 20 (21) as in the case where the shutter is automatically released, or the image data may be transmitted to the cloud server 20 (21) based on the customer's operation.

[0210] In the above embodiment, an example in which two types of reserved products, NON-PLU and read NG, are managed as reserved products is described, but the reserved products are not limited to the above two types. For example, reserved products other than the above two types may be managed as self-declared products. A self-declared product is a reserved product that is declared by the customer himself. In other words, if a timeout process is executed after a predetermined time of imaging, the product becomes read NG, but if it takes time until the timeout process, the customer must continue to hold the mobile terminal 50 over the product. In such a situation, if the customer cannot wait for the timeout, the customer may declare the product as reserved at his / her own discretion. For example, a reserved declaration button may be arranged on the registration screen of the mobile terminal 50, and the barcode recognition process may be temporarily stopped and the customer's shutter operation mode may be switched to by operating (touching) the reserved declaration button (the barcode recognition process may be ended when the shutter is actually released). Alternatively, the barcode recognition process may be ended and the shutter may be released at the same time by operating (touching) the reserved declaration button.

[0211] As described above, even in the case of a self-declared product, in order to obtain a captured image of the product (i.e., to generate captured image data), the captured image data is transmitted to the cloud server 20 (21). The cloud server 20 (21) stores reserved product information (e.g., reserved product category: 3 (self-declared), image data) in the basket information.

[0212] In the case of a reserved product (unreadable), the number of image data (number of data) to be managed may be two or more. That is, the mobile terminal 50 may obtain multiple captured images of a certain product (generate multiple image data) during timeout processing of the product, and the cloud server 20 (21) may store multiple image data of the product. The same applies to the case of a reserved product (self-declaration). Note that in the case of a reserved product (self-declaration), when the shutter is to be released at the customer's timing, the number of images to be captured may be notified to the customer (for example, displayed on the registration screen).

[0213] Also, while the settlement device 40 (41) is a device equipped with two scanner units (customer-side scanner unit 406, store clerk-side scanner unit 412), the settlement device 40 (41) may also be a device equipped with one scanner unit (customer-side scanner unit 406). The same applies to the settlement device 30. Also, it has been described that the settlement device 40 (41) can perform registration processing in addition to settlement processing (for example, in addition to being equipped with a card payment unit 408 and a change machine 409, the customer-side scanner unit 406 and the store clerk-side scanner unit 412 scan barcodes attached to products), but the settlement device 40 (41) may be a device dedicated to settlement processing that does not perform registration processing (a device dedicated to settlement processing that performs settlement processing for products that have been registered in another device). The same applies to the settlement device 30.

[0214] When a customer cancels an item (performs a cancel operation), the customer may be notified (notified on the display screen of the mobile terminal 50) that the canceled item will be returned to the shelf (for example, to its original display position). In other words, when a customer cancels an order, not only is the item deleted from the basket of the cloud server 20 (21) or the display of the mobile terminal 50, but the customer is notified that the item will be returned to its original shelf and the customer is requested to cooperate in maintaining the order of the store's displays. In an actual store, an item that a customer has decided not to purchase for some reason may be left on a shelf other than the original one, so this is an effective warning to such badly behaved customers.

[0215] Note that information from the cloud server 20 (21) (e.g., basket information, etc.) may be used as an electronic receipt. For example, the cloud server 20 (21) may have an electronic receipt output function. This allows a customer to check his / her usage history on the cloud, or to download it to a mobile terminal 50 or the like and save it as a transaction history.

[0216] The cloud server 20(21) may transmit the customer's usage history to the management device 10(11, 12) through communication similar to the transmission and reception of the transmitted and received data "D0 (store information, product information)". Thereby, the management device 10(11, 12) can store and manage not only the usage history of users who have completed settlement in the existing system but also the usage history of customers who have used the self-registration system. For example, transactions by the self-registration system can be integrated into the conventional electronic journal and can be searched in the same way as before. In addition, the mode of each transaction may be managed by usage mode identification information (simply referred to as usage mode information) for identifying how each transaction was implemented in the usage history.

[0217] [Usage mode information] Usage mode information "1 (Normal)": Transactions where the store clerk handled both the registration process and the settlement process Usage mode information "2 (Semi-self)": Transactions where the store clerk handled the registration process and the customer handled the settlement process Usage mode information "3 (Full-self)": Transactions where the customer handled both the registration process and the settlement process (using the same device) Usage mode information "4 (Smartphone self)": Transactions where the customer handled both the registration process and the settlement process (using a different device)

[0218] Also, the above usage mode may be clearly displayed on the display screen when checking the usage history (electronic journal) or on the receipt printed at the store. Also, when the display area or the printing area is small, only the initial letters such as "T", "S", "F", "S" may be output, or when it is even smaller, the value ("1" to "4", etc.) may be displayed.

[0219] With the above-mentioned measures, the existing system can also grasp the usage status of the self-registration system, so it is possible to check the store status (information related to the store such as sales, inventory management, usage history, etc.) without changing the conventional operation method. Since such coexistence can be realized with few modifications, the system described in the embodiment can be proposed to any customer who is implementing any operation.

[0220] There are cases where the various cloud servers 20 (21) actively determine the subtotal amount using the selling price determination logic while monitoring the usage of the mobile terminal 50 and the settlement device 40. For example, when the cloud server 20 (21) detects that "Proceed to checkout" has been pressed on the mobile terminal 50, the selling price determination logic identifies the basket information of the user of the mobile terminal 50 and can determine the subtotal amount in advance. After that, the basket information and the subtotal amount are transmitted to the settlement device 40 that the customer has caused to read the QR code. Similarly, when the settlement device 40 reads a QR code and the cloud server 20 (21) detects the reading operation, the subtotal amount can be actively determined using the selling price determination logic and the determination result can be transmitted to the settlement device 40. In this way, the selling price determination logic is not limited to being executed at the request of the settlement device.

[0221] The exchange of basket identification information between the mobile terminal 50 and the settlement device 40 is not limited to two-dimensional codes, and can be by any method, such as barcodes, wireless communication via RFID, NFC or Bluetooth, or wired communication between the mobile terminal 50 and the settlement device 40 via a connector provided on the mobile terminal 50 or the settlement device 40.

[0222] When a customer who has completed product registration uses a payment device 40, the customer may not be able to determine which payment device to use, for example, if the store is large or there are queues at all the payment devices. In such a situation, a separate guidance device may be provided to guide the customer to the most suitable payment device, taking into consideration factors such as the least crowded or the closest. Also, if the mobile terminal 50 is provided with a guidance function, a payment device selection screen may be displayed when "Proceed to checkout" is pressed, allowing the customer to reserve any payment device.

[0223] <Fourth embodiment> Next, a fourth embodiment will be described. The shopping system of this embodiment is as shown in Fig. 1. That is, the shopping system of this embodiment includes a settlement device 40, a mobile terminal 50, a cloud server 20, and a credit card payment server 60. Note that the settlement device 30 may also be used in this embodiment, but in the following description, for the sake of clarity, a system configuration in which the settlement device 30 is omitted from the aspect of Fig. 1 will be given as an example. In addition, the shopping system of this embodiment can be compatible with any of the functional configurations of the shopping systems shown in Figures 5, 11, and 13, but in the following explanation, the functional configuration of the shopping system in Figure 5 will be taken as an example. In accordance with the present embodiment, the cloud server 20 has a payment function. The payment function of the cloud server 20 performs payment processing corresponding to payment types other than cash (non-cash payment types), such as, for example, payment by credit card, electronic money, prepaid card, using a point balance, and payment by debiting a payment amount from a bank account.

[0224] The settlement device 40 of this embodiment is provided in a store. The settlement device 40 executes a process related to the registration of products purchased by a customer (product registration) and a process related to the settlement of the products registered by the product registration process in response to an operation by a store clerk. In the following description, a transaction includes product registration and settlement corresponding to one transaction.

[0225] The mobile terminal 50 of the present embodiment is a mobile terminal carried by a customer who visits a store to shop. The mobile terminal 50 is, for example, a smartphone, a tablet terminal, etc. The display unit of such a mobile terminal 50 is configured as a touch panel. A product registration application is installed on the mobile terminal 50. The product registration application is an application that registers products in response to operations by a customer at the time of a transaction at a store.

[0226] A beacon terminal BTM (FIG. 1) is installed in the store. The beacon terminal BTM transmits a beacon signal to a mobile terminal 50 that is within communication distance and is able to communicate, for example, by short-distance wireless communication according to the Bluetooth (registered trademark) standard. The communication distance of the beacon terminal BTM is set to, for example, about several meters to a dozen meters so that communication can be performed with the mobile terminal 50 carried by a customer who enters the facility of the store. In this embodiment, the beacon signal transmitted by the beacon terminal BTM includes a beacon terminal identifier indicating the beacon terminal BTM that transmitted the beacon signal. When the product registration application installed in the mobile terminal 50 receives a beacon signal including a beacon terminal identifier indicating the beacon terminal BTM installed in the store, the product registration mode is set and the product registration application becomes active and operates in the foreground.

[0227] In addition, the short-range wireless communication method used between the beacon terminal BTM and the mobile terminal 50 is not limited to the above-mentioned Bluetooth, and other methods may be adopted, such as ZigBee (registered trademark), NFC (Near Field Communication), etc. In addition, in the figure, one beacon terminal BTM is shown in the store, but the number of beacon terminals BTM installed in the store is not particularly limited.

[0228] An operation of registering a product on the mobile terminal 50 by a customer (product registration operation) is performed, for example, as follows. The customer holds the mobile terminal 50 in an active state with the product registration mode set, and uses the code scanner function of the mobile terminal 50 to read code information such as a barcode (which may be a two-dimensional code) attached to the product he or she has purchased. The code information thus read is stored in the mobile terminal 50. When the customer has completed the operation to register all of the purchased products, the customer performs a predetermined operation (product registration completion operation) on the mobile terminal 50 to instruct completion of product registration. In this manner, in this embodiment, a customer who has installed a product registration application on his / her mobile terminal 50 can register products by operating his / her mobile terminal 50. Since product registration is performed by the customer in this manner, in this embodiment, it is not necessary for a store clerk to operate the settlement device 40 to register products.

[0229] The cloud server 20 is installed, for example, in a store headquarters corresponding to the store in which the settlement device 40 is installed. The cloud server 20 has a function of managing the transaction results in the store. Furthermore, when settlement is made, for example, by credit card (an example of a specific payment type), which is one of the non-cash payment types, a non-cash payment request is sent from the settlement device 40 or the mobile terminal 50 to the cloud server 20. The non-cash payment request includes payment information based on the registered products and a credit card number. The product registration results are reflected in the payment information. For example, the payment information may include the total payment amount for the registered products. Furthermore, the payment information may include product registration information indicating, for example, the product identifier, product name, price, quantity, etc. for each registered product. Cloud server 20 that has received the non-cash payment request communicates with credit card payment server 60 to execute processing corresponding to the credit card payment (credit card payment processing). The cloud server 20 may be installed in the same store as the settlement device 40. Alternatively, the self-registration system of the present embodiment may be adapted to a mode in which a plurality of stores are managed under a store headquarters. In this case, the cloud server 20 at the store headquarters communicates with the settlement devices 40 set up in the plurality of stores and with the mobile terminals 50 carried by customers in each of the plurality of stores.

[0230] Next, a configuration example of the mobile terminal 50 will be described with reference to Fig. 19. The mobile terminal 50 in the figure includes a CPU 501, a storage unit 502, a RAM 503, a network-compatible communication unit 504, a short-range wireless-compatible communication unit 505, a display unit with a touch panel 506, an operation unit 507, and an imaging unit 508.

[0231] The CPU 501 executes programs to realize various processes in the mobile terminal 50. The storage unit 502 is an auxiliary storage device for the CPU 501, and stores various data in addition to the programs executed by the CPU 501. The RAM 503 is a main storage device for the CPU 501 .

[0232] A network-compatible communication unit 504 executes communication compatible with a network via a telephone line or a wireless LAN. The short-distance wireless communication unit 505 performs short-distance wireless communication according to the Bluetooth standard. That is, the short-distance wireless communication unit 505 can receive a beacon signal transmitted from a beacon terminal BTM installed in a store.

[0233] The touch panel display unit 506 is a display unit combined with a touch panel. An operation unit 507 collectively indicates keys and the like used for operations other than the touch panel display unit 506 .

[0234] The imaging unit 508 captures an image. The mobile terminal 50 has a code information scanning function that utilizes the imaging unit 508. That is, when the mobile terminal 50 recognizes that code information is included in a captured image captured by the imaging unit 508, the code information scanning function acquires the code information from the captured image.

[0235] Next, a configuration example of the cloud server 20 will be described with reference to Fig. 20. The cloud server 20 in Fig. 20 includes a CPU 201, a storage unit 202, a RAM 203, and a communication unit 204.

[0236] The CPU 201 executes programs to realize various processes in the cloud server 20. The storage unit 202 is an auxiliary storage device for the CPU 201, and stores various data in addition to the programs executed by the CPU 201. The RAM 203 is a main storage device for the CPU 201 . The communication unit 204 communicates with the settlement device 40, the mobile terminal 50, the credit card company, and the like. Note that the cloud server 20 may also be provided with a display unit, an operation unit, etc., so that an administrator can perform operations, etc.

[0237] An example of a process procedure executed by the mobile terminal 50 and cloud server 20 in this embodiment in relation to a transaction (product registration, payment) will be described with reference to the flowchart in FIG. First, an example of a process procedure executed by the mobile terminal 50 will be described. Step S1001: The mobile terminal 50 waits to receive a beacon signal compatible with the product registration application transmitted from the beacon terminal BTM of the store. Whether or not the beacon signal is compatible with the product registration application is determined based on whether or not the beacon terminal identifier included in the beacon signal indicates the beacon terminal BTM installed in the store.

[0238] Step S1002: When a beacon signal corresponding to the product registration application is received, the mobile terminal 50 sets the product registration mode for the product registration application installed in itself and starts it. As a result, the product registration application is set to an active state in which it operates in the foreground, and the product registration mode is set.

[0239] Step S1003: In response to the product registration application being launched in the product registration mode in step S1002, the mobile terminal 50 transmits a transaction identifier request requesting a transaction identifier to the cloud server 20. The transaction identifier here may be basket identification information corresponding to the basket information. Step S1004: In response to the transaction identifier request, cloud server 20 transmits a transaction identifier. Mobile terminal 50 acquires the received transaction identifier. The transaction identifier thus acquired uniquely identifies the transaction corresponding to the product registration in the product registration mode set in response to the current step S1002.

[0240] Step S1005: In a state in which the product registration mode is set in step S1002, the mobile terminal 50 determines whether or not an operation related to product registration for one product (product registration related operation) has been performed. The product registration related operation includes a product registration operation for registering a product, as follows. For example, in the product registration mode, the code scanner function is enabled. Then, when the customer has put all of his / her purchased products into the shopping cart, he / she removes the products one by one from the shopping cart and has the image capturing unit 208 of the mobile terminal 50 capture the code information attached to the product. When the code scanner function recognizes the code information in the captured image, the mobile terminal 50 determines that the product registration operation has been performed. In addition, product registration related operations may include, for example, an operation to cancel the registration of a product.

[0241] Step S1006: When it is determined that a product registration related operation has been performed, the mobile terminal 50 executes a process (product registration related process) according to the performed product registration related operation. For example, when a product registration operation has been performed, the mobile terminal 50 acquires code information recognized by a code scanner function from a captured image as the product registration process, and stores the code information in the RAM 203, for example. Furthermore, the mobile terminal 50 transmits to the cloud server 20 product registration related processing information that reflects the result of the product registration related processing executed in step S1006.

[0242] Step S1007: If it is determined in step S1005 that no product registration related operation has been performed, or after the process of step S1006, the mobile terminal 50 determines whether or not product registration has been completed. For example, when the customer has completed the product registration operation for all of the products he or she has purchased, the customer performs a product registration completion operation. If the product registration completion operation is performed, it is determined in step S1007 that the product registration is complete. If the product registration completion operation is not performed and it is not determined that the product registration is complete, the process returns to step S1005.

[0243] Step S1008: When it is determined in step S1007 that the product registration is completed in response to the product registration completion operation being performed, the mobile terminal 50 determines whether or not a specific non-cash payment is permitted. In the product registration application of the present embodiment, as one of the setting items, it is possible to select whether to permit or prohibit payment by non-cash payment type for a transaction in which a product is registered using the product registration application. To set permission for credit card payment as an example of non-cash payment, the customer registers information required for credit card payment (credit card information), such as a credit card number. The credit card information registered in this manner may be stored in the storage unit 202 as data that can be referenced only by the product registration application, for example. For example, if the registered products include reserved products, the transaction cannot be completed unless the handling of the reserved products is confirmed. Therefore, if the registered products include reserved products, the mobile terminal 50 may determine that non-cash payment is not permitted in step S1008, even if the mobile terminal 50 is set to permit non-cash payment.

[0244] Step S1009: If non-cash payment is permitted, the mobile terminal 50 transmits a payment request according to the permitted non-cash payment type to the cloud server 20. As an example, in the case of credit card payment, the payment request includes the registered credit card information and payment information reflecting the result of the current product registration. The process of step S1009 corresponds to selecting the previously permitted non-cash payment type as the payment type to be used for the current transaction. Step S1010: In response to receiving the non-cash payment request, the cloud server 20 executes a payment handling process corresponding to the specified non-cash payment type, and in response to completion of the payment, transmits a payment completion notification to the mobile terminal 50. The mobile terminal 50 receives the transmitted payment completion notification.

[0245] Step S1011: After the process of step S1010, or if it is determined in step S1008 that non-cash payment is not permitted (prohibited), the mobile terminal 50 executes the following process. That is, the mobile terminal 50 generates transaction code information (an example of identification information) indicating the transaction corresponding to the current product registration. The transaction code information thus generated includes the transaction identification information acquired in step S1004. If it is determined in step S1008 that non-cash payment is not permitted, the transaction code information may further include product registration information reflecting the result of the product registration process for the current transaction. If non-cash payment is performed in steps S1009 and S1010, the transaction code information may further include transaction record information reflecting the settlement result of the non-cash payment in the product registration information for the current transaction.

[0246] Step S1012: The mobile terminal 50 causes the touch panel display unit 506 to display a settlement device guidance screen including the transaction code information generated in step S1011 and showing a message guiding the customer to the settlement device 40.

[0247] FIG. 22(A) shows an example of the settlement device guidance screen displayed in step S1012 after the processing of steps S1009 and S1010. In the figure, the transaction code information is displayed as a QR code. Also, the settlement device guidance screen displays a message that if a paper receipt is required, the customer should go to the settlement device 40 and have the settlement device 40 read the displayed transaction code information. In this case, if the customer needs a paper receipt, he or she goes to the settlement device 40 holding the mobile terminal 50 with the settlement device guidance screen displayed. On the other hand, if a paper receipt is not required, the customer operates the "No receipt required" button on the settlement device guidance screen in the figure. In response to the operation of the "No receipt required" button, the settlement device guidance screen disappears and transitions to a specified screen. In this case, the customer can leave the store without going to the settlement device 40.

[0248] Moreover, FIG. 22(B) shows one example of the settlement device guidance screen that is displayed in step S1012 after it is determined in step S1008 that non-cash payment is not permitted. In the figure, the transaction code information is displayed as a QR code. Also, the settlement device guidance screen displays a message to the customer that if they want to have a paper receipt issued, they should go to the settlement device 40 to settle the bill, and that they should have the settlement device 40 read the displayed transaction code information.

[0249] Referring again to FIG. 21, an example of a process procedure executed by the cloud server 20 will be described. Step S2001: The cloud server 20 determines whether or not the transaction identifier request transmitted from the mobile terminal 50 in step S1003 has been received. Step S2002: When cloud server 20 receives the transaction identifier request, it generates, for example, new basket information and transmits a transaction identifier corresponding to the generated basket information to mobile terminal 50 that is the sender of the transaction identifier request.

[0250] Step S2003: If it is determined in step S2001 that the transaction identifier request has not been received, or after the processing of step S2002, cloud server 20 executes a transfer process. That is, cloud server 20 determines whether mobile terminal 50 has received product registration related processing information that reflects the result of the product registration related processing in step S1006.

[0251] Step S2004: If it is determined in step S2003 that product registration related processing information has been received, the cloud server 20 updates the product registration information (basket information) corresponding to the current transaction so as to reflect the contents of the received product registration related processing information. When updating the product registration information, if a product code is transmitted as product registration related processing information, the cloud server 20 determines whether or not the received product code is registered in the product information. If the product code is registered in the product information, the cloud server 20 adds the registered product information corresponding to the received product code to the product registration information (basket information). If the product code is not registered in the product information, the cloud server 20 adds reserved product information with a reserved product type of NON-PLU to the product registration information (basket information). Furthermore, when the received product registration related processing information corresponds to reading NG, the cloud server 20 adds the pending product information whose pending product type is reading NG to the product registration information (basket information). If the received product registration related processing information instructs the cancellation of a product that has been registered, cancellation information is added to the product registration information (basket information).

[0252] Step S2005: After the process of step S2004, or if it is determined in step S2003 that the product registration related processing information has not been received, the cloud server 20 determines whether or not the payment request transmitted from the mobile terminal 50 in step S1009 has been received. If it is determined that the payment request has not been received, the process returns to step S2001.

[0253] Step S2006: If it is determined in step S2005 that a payment request has been received, the cloud server 20 executes a payment process corresponding to the received payment request. As a specific example, when the received payment request specifies credit card payment as the non-cash payment type, the cloud server 20 transfers the payment information based on the product registration information corresponding to the current transaction and the credit card payment request to the credit card payment server 60. The credit card payment server 60 compares the credit card information included in the received credit card payment request with the credit card information stored by the credit card payment server 60 for each credit card user, and determines whether or not the credit card is available. If it is determined that the credit card is available, the credit card payment server 60 makes a payment for the total payment amount indicated in the payment information received together with the received credit card payment request. When the payment is completed, the credit card payment server 60 transmits a payment completion notice to the cloud server 20 indicating that the payment has been completed. Upon receiving the payment completion notice, the cloud server 20 recognizes that the current payment handling process has been completed.

[0254] Step S2007: In response to the completion of the payment handling process as described above, the cloud server 20 transmits a payment completion notification to the mobile terminal 50. Furthermore, in response to the completion of the payment handling process, cloud server 20 stores a value indicating that the payment has been completed in the payment completion flag of the corresponding product registration information (basket information).

[0255] Step S2008: Cloud server 20 also stores a value indicating that the payment has been completed in the settled flag of the product registration information (basket information) of the transaction corresponding to the payment handling process executed in this step S2004. This indicates that the product registration information corresponds to a settled transaction. The product registration information may be managed in a state where it is stored in storage unit 202 in cloud server 20.

[0256] An example of a process procedure executed by the settlement device 40 and the cloud server 20 in this embodiment in relation to settlement will be described with reference to the flowchart in FIG. First, an example of a processing procedure executed by the settlement device 40 will be described. Step S3001: As shown as step S1012 in FIG. 21, upon completion of product registration for one transaction, the mobile terminal 50 causes a settlement device guidance screen including transaction code information to be displayed on the touch panel display unit 506 in response to either a case where a non-cash payment has been made or a case where a non-cash payment has not been made. When a customer completes a payment using a non-cash payment method on the mobile terminal 50, if the customer requires a paper receipt, the customer is instructed to go to the payment device 40 with the mobile terminal 50 displaying the payment device guidance screen. Also, when a payment using a non-cash payment method is not completed on the mobile terminal 50, the customer is instructed to go to the payment device 40 with the mobile terminal 50 displaying the payment device guidance screen for payment.

[0257] When a customer approaches the settlement device 40, the settlement device 40 is in a standby state. In the standby state, the settlement device 40 displays a standby screen on the customer side display unit 405. Fig. 24 shows an example of the standby screen. The standby screen in Fig. 24 displays images and messages to guide the customer to perform an operation to read the QR code displayed on the settlement device guidance screen with the customer side scanner unit 406. The standby screen in Fig. 24 also has a "Back" button, a store clerk call button, a balance inquiry button, a language change button, etc. When the "Back" button is operated, the display transitions to return to a specified screen. When the store clerk call button is operated, a notification is made in the store in a predetermined manner to call a store clerk (to have the store clerk come to the settlement device 40). The balance inquiry button is a button that is operated, for example, when a customer wishes to inquire about the balance of an electronic money card. The language switching button is a button used to specify the language of messages displayed on various operation screens displayed on the settlement device 40 and output by voice.

[0258] For example, when a customer approaches settlement device 40 with the standby screen displayed as described above, the customer operates customer-side scanner unit 406 to cause customer-side scanner unit 406 to read the presented transaction code information. In response to the code information being read by customer-side scanner unit 406 in this manner, settlement device 40 acquires the transaction code information. Settlement device 40 can recognize that the code information read by customer-side scanner unit 406 is transaction code information based on the unique identifier possessed by the transaction code information.

[0259] Step S3002: In response to the transaction code information being read in step S3001, the settlement device 40 transmits a product registration information request to the cloud server 20. The product registration information request here is a command requesting product registration information (basket information) corresponding to the transaction indicated by the transaction code information read in step S3001. The product registration information request includes the transaction identifier in the transaction code information obtained in step S3001.

[0260] Step S3003: In response to receiving the product registration information request, the cloud server 20 transmits product registration information corresponding to the target transaction to the settlement device 40. In response to receiving the product registration information, the settlement device 40 determines whether the target transaction has been settled. For this purpose, the settlement device 40 judges whether or not the value of the settled flag stored in the product registration information indicates that the transaction has been settled. If the value of the settled flag indicates that the transaction has been settled, the settlement device 40 judges that the transaction has been settled. On the other hand, if the value of the settled flag indicates that the transaction has not been settled, the settlement device 40 judges that the transaction has not been settled.

[0261] Step S3004: If it is determined in step S3003 that the target transaction has not been settled, the settlement device 40 must complete the settlement. Therefore, the settlement device 40 executes settlement processing for the target transaction. As the processing in step S3004, for example, the settlement device 40 displays a settlement screen on the customer-side display unit 405, which is a touch panel. The settlement screen is a screen displayed to the customer when the settlement device 40 performs settlement processing, to present information related to settlement, to provide guidance on operations related to settlement, and to accept operations related to settlement.

[0262] As the settlement screen, for example, first, a payment type selection screen is displayed on which an operation to select a payment type is performed. On the payment type selection screen, predetermined payment types, such as payment by cash, payment by credit card, payment by electronic money, and payment by using points, are presented as options. The customer selects the payment type he or she wishes to use from the presented options. The settlement device 40 executes the settlement process corresponding to the selected payment type. In addition, for example, the checkout screen after the payment type is selected includes a list of registered products (product list) that is presented based on the received product registration information. The products in the product list may be presented in the order in which they were registered. In addition, the order in which the products are presented in the product list may be sorted, for example, in ascending order of price, which makes it easier to understand the registered products by sorting them in order of price. The store clerk can check the products registered by the customer by looking at the product list displayed on the checkout screen. If the product list can be displayed in order of price, for example, the store clerk can check the registered products even more easily. Furthermore, if necessary, the customer can check whether the product registration results are correct by comparing the products presented in the product list with the products that the customer has in their shopping cart or the like.

[0263] When the store clerk confirms that the products presented in the product list are correct, he or she operates the settlement device 40 so that the settlement is carried out with the payment type requested by the customer, and causes the settlement device 40 to execute the settlement process. Payment types that the settlement device 40 of this embodiment can handle when carrying out the settlement process include cash, credit card, gift certificate, prepaid card, and point card point balance use. For example, even if a customer registers products using the mobile terminal 50, when making a settlement using a credit card, there are cases where the customer wants to set the product registration application of the mobile terminal 50 to prohibit credit card payment and to make the settlement using the settlement device 40. Even in such a case, in the case of this embodiment, the credit card payment can be made at the settlement device 40 even for a transaction in which the product is registered using the mobile terminal 50. When the settlement process in step S3004 is completed, the settlement device 40 causes the printing unit 19 to print a receipt reflecting the settlement process result. The store clerk hands the printed receipt to the customer.

[0264] Step S3005: When the settlement process in step S3004 is completed, the settlement device 40 transmits to the cloud server 20 settlement process result information reflecting the settlement process result of the target transaction.

[0265] Step S3006: If it is determined in step S3003 that the target transaction has been settled, the settlement device 40 issues a receipt reflecting the results of the non-cash payment made via the product registration application of the mobile terminal 50 in response to the target transaction. When issuing a receipt, the settlement device 40 uses the results of the product registration process and the results of the credit card settlement indicated in the received product registration information to print on the receipt. The receipt issued in this way indicates information about each purchased product (name, price, number of purchased products, etc.), the total price of the purchased products, and the fact that the total price has been settled by credit card settlement.

[0266] Next, an example of a process performed by the cloud server 20 will be described. Step S4001: The cloud server 20 determines whether or not the product registration information request transmitted from the settlement device 40 in step S3002 has been received.

[0267] Step S4002: When the product registration information request is received, the cloud server 20 searches the storage unit 202 for product registration information associated with the same transaction identifier as that included in the received transaction inquiry request.

[0268] Step S4003: The cloud server 20 transmits the product registration information searched for in step S4002 to the settlement device 40.

[0269] Step S4004: If it is determined in step S4001 that a transaction inquiry request has not been received, or after the process of step S4003, cloud server 20 executes the following process. That is, cloud server 20 determines whether or not settlement process result information transmitted from settlement device 40 in step S3005 has been received. If the settlement process result information has not been received, the process returns to step S4001.

[0270] Step S4005: When the settlement process result information is received, the cloud server 20 sets the settlement completion flag of the same product registration information, stored in the memory unit 202, as that searched for in step S4003, to a value indicating that the settlement has been completed.

[0271] As described above, in this embodiment, a customer can register products by operating the mobile terminal 50 on which the product registration application runs. This eliminates the need for at least some customers who shop at a store to have the settlement device 40 perform product registration processing for purchased products. Furthermore, if permission for non-cash payments, such as credit card payments, is set in the product registration application, upon completion of product registration, non-cash payments can be made via the product registration application without having to receive payment at the settlement device 40. As a result, at least some of the customers who have registered products using the mobile terminal 50 on which the product registration application runs do not need to have the settlement process performed by the settlement device 40, and can simply receive a receipt at their convenience, for example. That is, in this embodiment, in the accounting of one transaction, there are cases where not only product registration but also settlement does not need to be performed by the settlement device 40. As a result, in this embodiment, the time it takes for one customer to receive a transaction at the settlement device 40 is further shortened, improving transaction efficiency.

[0272] Here, the screens displayed on the settlement device 40 in the processing from step S3003 onward in FIG. 23 will be described. First, when issuing a receipt in step S3006, the settlement device 40 causes the customer display unit 405 to display a settlement completion screen indicating that settlement has been completed (settlement completed). FIG. 25 shows an example of a settlement completion screen. The settlement completion screen in this figure displays a message to the customer that it has been confirmed that the settlement has been completed, and that they should press the "End" button (or "Receipt Available" button to receive a receipt (and invoice). It also displays the amount confirmed to have been paid by the settlement (18,020 yen in this case) and the payment type used for this settlement (credit card payment in this case). In the case of the settlement completion screen in the embodiment shown in the figure, a receipt or the like is issued when the customer operates the "End" button (or the "Receipt Available" button. In other words, a receipt is issued when the customer operates the button to instruct the issuance of a receipt or the like. However, the settlement device 40 may be configured to issue a receipt even if the customer does not perform any operation to instruct the issuance of a receipt, etc. In this case, since a receipt, etc. will be issued, a message may be displayed on the settlement completion screen informing the customer to receive the receipt.

[0273] Also, as described above, a checkout screen including a list of products registered under the processing in step S3004 (product list) is displayed. FIG. 26 shows an example of a checkout screen (product list screen) including a product list when a reserved product is included in the registered products.

[0274] A store clerk needs to handle the pending items and take a prescribed action. For this reason, when the display of the product list screen including the pending items starts, the settlement device 40 executes a store clerk call control. The store clerk call control may be, for example, a control in which an announcement is made by voice instructing the store clerk to go to the settlement device 40. The store clerk call control may also be a control in which a message instructing the store clerk to go to the settlement device 40 is notified to a terminal carried by the store clerk. The store clerk call control may also be a control in which a message instructing the store clerk to go to the settlement device 40 is output by the management device 10 by display, voice, or the like. At this time, for example, a screen (e.g., a dialogue window or a pop-up screen) may be displayed superimposed on the product list screen in the same figure, instructing the customer to wait while checking the contents of the product list screen until a store clerk arrives in response to the call.

[0275] The order of arrangement of product list items on the product list screen in the figure is first from top to bottom on the left side, and then from top to bottom on the right side. In the figure, the six reserved item list items are arranged in the order of the item list items. Each reserved item list item has a heading on the left side indicating the type of reserved item. In the figure, the types of reserved items are shown as "Age Verification," "Anti-Theft Tag," "Medicine," "Reserved Item," and "Cancelled Item." The "Age Verification" heading identifies reserved items that require age verification for purchase, such as alcoholic beverages and tobacco. The heading "Anti-theft tag" indicates that the reserved item has a security tag attached. The heading "Medicine" indicates that the product is a Class 1 medicine, subject to sale by a pharmacist as a reserved product. The heading "Reserved Products" indicates that the reserved products are products that have been registered as NON-PLU, or products whose codes were not properly read when the products were registered. Products whose codes were not properly read may include products where a malicious customer pretended to perform the code reading operation for product registration using the mobile terminal 50, but did not actually have the mobile terminal 50 read the code. The heading "Cancelled Product" indicates that the product was once registered as a reserved product, but was subsequently cancelled by the customer (this includes a case where the purchase quantity was reduced).

[0276] Following the list items of reserved items, list items of items other than reserved items are arranged according to predetermined price categories. In the figure, an example is shown in which the price categories are divided into four categories as shown by product category buttons BT1-1 to BT1-4 among the product category buttons BT1 (BT1-1 to BT1-5) arranged in the figure.

[0277] The product category button BT1-1 corresponds to products priced at 1000 yen or more. The product category button BT1-2 corresponds to products priced at 500 yen to 999 yen. The product category button BT1-3 corresponds to products priced at 300 yen to 499 yen. The product category button BT1-4 corresponds to products priced at 299 yen or less. Furthermore, the product category button BT1-5 corresponds to reserved products.

[0278] Following the list of reserved items are three list items with prices over 1000 yen. Following the list of items with prices over 1000 yen are five list items with prices between 500 yen and 999 yen. Following the list of items with prices between 500 yen and 999 yen are six list items with prices between 300 yen and 499 yen. Following the list of items with prices between 300 yen and 499 yen are four list items with prices under 299 yen. In the figure, a maximum of 24 product list items can be arranged. If the number of registered products is more than 24, tapping on the tab with the number "2" located in the upper right corner of the sheet on which the product list items are arranged will switch to the display of the second sheet on which the subsequent product list items are arranged.

[0279] In addition, in response to the operation of a product classification button BT1 arranged on the product list screen in the figure, the list items of products corresponding to the product classification corresponding to the operated product classification button BT1 are displayed in a highlighted manner relative to the list items of other products. As an example, the list items of other products may be grayed out, so that the list items of products corresponding to the product classification corresponding to the operated product classification button BT1 are displayed in a highlighted manner.

[0280] For example, on the product list screen, the list items for each product are arranged so that they are divided into reserved products and products other than reserved products. Furthermore, products other than reserved products are arranged by price range. This allows the store clerk to easily identify the reserved products first and deal with them. Also, for example, when fraud is committed, high-priced products are likely to be the target of fraud, but with the product list screen format shown in the figure, products are displayed together by price range according to predetermined price ranges, so the store clerk can focus only on the high-priced products and determine, for example, whether or not there is any fraud. For example, if no particular fraudulent activity has occurred and the store clerk has properly processed the reserved items, a screen corresponding to the subsequent settlement by the customer is displayed on the customer side display unit 405. As an example, after the product list screen shown in the figure is displayed, a button for instructing the subsequent settlement (start settlement button) may be newly placed in a predetermined position on the product list screen.

[0281] Here, as an example of the process for handling pending items displayed on the product list screen, we will explain the operation for setting the amount, product name, subcategory, etc. for one pending item registered as NON-PLU and including it in the settlement target (pending item cancellation operation). The store clerk who receives the call and goes to the settlement device 40 performs a tap operation on the list item of the reserved product to be cancelled from among the list items on the displayed product list screen. In response to a tap operation on a list item of a reserved product, a dialogue window is displayed, for example superimposed on the product list screen, to guide the clerk to read the clerk ID. The clerk then performs an operation to have the code attached to his or her clerk ID read by customer side scanner unit 406 or clerk side scanner unit 412. As a result, settlement device 40 acquires a clerk identifier and performs authentication processing to determine whether the acquired clerk identifier is legitimate. If authentication is successful, a deletion operation screen for a deletion operation is displayed superimposed on the product list screen. NON-PLU reserved products are products in which the barcode attached to the product has been read correctly, but the price, product name, subcategory (for example, vegetables, meat, fish, prepared foods, sweets, miscellaneous goods, etc.) etc. have not been associated with the product indicated by the barcode. The store clerk then inputs the price, product name, and subcategory of the product into the erase operation screen. A keyboard for inputting the price, product name, and subcategory may be provided on the erase operation screen. Furthermore, if necessary, an operation for registering other predetermined information in addition to the price, product name, and subcategory may be performed on the erase operation screen. When the store clerk has completed inputting the predetermined information such as the amount, product name, subcategory, etc., he / she performs a confirmation operation for the input contents (for example, an operation on a confirmation button arranged on the deletion operation screen). In response to the confirmation operation, the settlement device 40 releases the pending state of the target product and changes the product registration information so that the product is the target for settlement. In addition, when canceling a reserved item, if at least the amount has been input, the reserved state may be canceled even if other information such as the item name, subcategory, etc. has not been input. In addition, the input information such as the price, product name, subcategory, etc. for NON-PLU products entered on the deletion operation screen may be processed as the content of the actual registration of the product in the product master, or may be treated as the content of provisional registration so that the actual registration process can be carried out at a later opportunity. In addition, the erasing operation screen may be configured to allow an operation to instruct "image confirmation," and when the operation to instruct "image confirmation" is performed, an image of the reserved product captured by a mobile terminal such as a smartphone may be displayed. This allows the store clerk to easily confirm what the target product is.

[0282] Moreover, Fig. 27 shows another example of the product list screen including reserved products. The product list screen in Fig. 27 is in a portrait format. For example, the display surface of the customer side display unit 405 on which the product list screen is displayed may be in a portrait format. The product list screen in Fig. 27 is suitable for a case where the display surface is portrait-oriented, for example. The product list screen in the figure also shows a state in which the product classification button BT1-5 corresponding to the reserved product is operated when a reserved product handling operation such as erasing the reserved product is performed. In other words, when the product classification button BT1-5 corresponding to the reserved product is operated, the list items are rearranged (sorted) so that the list items of the reserved products are arranged together at the bottom in the arrangement of list items, as shown in the figure, and are then highlighted. Note that the list items of the reserved products may be arranged at the bottom in the arrangement of list items from the time when the display of the product list screen in the figure is started, for example. In the case where the product list screen is vertically long like this, for example, if the reserved products are arranged from the top as in Fig. 26, when a short and small store clerk performs an operation such as erasing reserved products, it may be difficult for them to reach the list items of the reserved products, making the operation difficult or tiring. Therefore, by arranging the list items of the reserved products at the bottom as in the same figure, it becomes easier for even a small store clerk to perform an operation such as erasing reserved products, and the burden of the operation is reduced. Furthermore, in the figure, the product classification buttons BT1-1 to BT1-4 corresponding to the price categories are arranged at the top of the product list screen, while the product classification button BT1-5 corresponding to the reserved products is arranged at the bottom right of the product list screen. This arrangement is also designed to make it easier for small store clerks to handle reserved products. This arrangement also prevents erroneous tapping of the product classification buttons BT1-1 to BT1-4 corresponding to adjacent price categories when trying to operate the product classification button BT1-5 corresponding to the reserved products. In addition, when a response operation is performed in response to a pending item, the deletion operation screen, etc., which is superimposed on the item list screen, can be displayed at the bottom of the item list screen, further reducing the burden of operation.

[0283] <Fifth embodiment> Next, a fifth embodiment will be described. In the fourth embodiment, if the mobile terminal 50 does not perform a payment by a non-cash payment type that is permitted in advance, the settlement device 40 selects a payment type to be used by the customer. In contrast, in this embodiment, the customer can select the payment type by operating the mobile terminal 50.

[0284] An example of a process procedure executed by the mobile terminal 50 and cloud server 20 in this embodiment in relation to a transaction (product registration, payment) will be described with reference to the flowchart in FIG. First, an example of a processing procedure of the mobile terminal 50 will be described. In the third embodiment, the permitted non-cash payment type is set in the mobile terminal 50, but in the present embodiment, for the sake of easy understanding of the explanation, a case where the permitted non-cash payment type is not set in the mobile terminal 50 will be described as an example.

[0285] First, as the processing executed by the mobile terminal 50, steps S1101 to S1107 are similar to steps S1001 to S1007 in FIG. 21, and therefore a description thereof will be omitted here.

[0286] Step S1108: When it is determined in step S1107 that the product registration is completed, the mobile terminal 50 causes the touch panel display unit 506 to display a payment type selection screen. Fig. 29(A) shows an example of a payment type selection screen. In the payment type selection screen in the figure, buttons corresponding to the payment types such as cash, credit card, and electronic money are arranged. The customer simply taps the button corresponding to the payment type he or she wishes to use from among the arranged buttons.

[0287] Step S1109: In response to an operation to select a payment type on the payment type selection screen, the mobile terminal 50 determines whether the selected payment type is a non-cash payment type that can be settled at the mobile terminal 50.

[0288] Step S1110: If it is determined in step S1109 that a non-cash payment type has been selected on the portable terminal 50, the portable terminal 50 determines whether payment can be made on the portable terminal 50 without settlement at the settlement device 40. For this reason, mobile terminal 50 transmits a payment possibility inquiry to cloud server 20. The payment possibility inquiry is a command for inquiring of cloud server 20 as to whether or not payment is possible for the transaction indicated by the transaction identifier acquired in step S1104.

[0289] In response to receiving the payment availability inquiry, the cloud server 20 refers to the product registration information corresponding to the transaction and determines whether or not payment can be made at the mobile terminal 50. In this case, the cloud server 20 determines whether or not the product registration information includes registration of a reserved product as a determination of whether or not payment is possible on the mobile terminal 50. If registration of a reserved product is included, the cloud server 20 determines that payment is not possible on the mobile terminal 50. If a NON-PLU (NO-FILE) product is registered as a reserved product, a store clerk must confirm which product the product code read from the product corresponds to and then process it. Also, if a product that cannot be read is registered as a reserved product, the customer may not have noticed that there was an error in reading the product code, or the customer may have committed fraud. In such cases, a store clerk must also respond and process the matter. Furthermore, the cloud server 20 determines whether or not payment is possible on the mobile terminal 50 by determining whether or not the number of times an operation to cancel a product that has been registered (registered product cancellation operation) has been performed is equal to or greater than a predetermined threshold. If the number of registered product cancellation operations is equal to or greater than the threshold, the cloud server 20 determines that payment is not possible on the mobile terminal 50. If the number of registered product cancellation operations is equal to or greater than the threshold, for example, the customer may be unfamiliar with operating the mobile terminal 50, and so there may be a discrepancy between the registered contents indicated by the product registration information and the breakdown of products the customer is actually trying to purchase. Alternatively, if the number of registered product cancellation operations is equal to or greater than the threshold, the customer may be committing fraud. For this reason, if the number of registered product cancellation operations is equal to or greater than the threshold, a store clerk must respond and handle the situation. On the other hand, when the contents of the product registration information indicate that no reserved products are registered and the number of registered product cancellation operations is less than the threshold value, the cloud server 20 determines that payment is possible. When the cloud server 20 determines whether or not payment is possible as described above, it transmits a payment possibility notification indicating the determination result to the mobile terminal 50. When the determination result indicates that payment is not possible, the payment possibility notification includes the reason why payment is not possible. As the reason why payment is not possible, at least one of the following is indicated: registration of a pending product, or the number of operations to cancel a registered product is equal to or exceeds a threshold value. The mobile terminal 50 determines whether or not payment is possible depending on whether the received payment feasibility notification indicates that payment is possible or not.

[0290] Step S1111: If it is determined in step S1110 that the payment is possible, the mobile terminal 50 transmits to the cloud server 20 a non-cash payment request according to the currently selected non-cash payment type. Step S1112: In response to receiving the non-cash payment request, the cloud server 20 executes a payment handling process corresponding to the specified non-cash payment type, and in response to completion of the non-cash payment, transmits a payment completion notification to the mobile terminal 50. The mobile terminal 50 receives the transmitted payment completion notification.

[0291] Step S1113: If it is determined in step S1110 that payment is not possible, the mobile terminal 50 displays a store clerk call guidance screen on the touch panel display unit 506. Fig. 29(B) and Fig. 29(C) each show an example of the store clerk call guidance screen. Fig. 29(B) is an example of the store clerk call guidance screen when the reason for payment not possible is the registration of a reserved item. Fig. 29(C) is an example of the store clerk call guidance screen when the reason for payment not possible is the number of cancellation operations exceeding a threshold value. 29(B) and 29(C), a message is displayed indicating the corresponding reason for the payment being impossible, and instructing the customer to go to the settlement device 40 in order to call a store clerk. Such a store clerk call guidance display is equivalent to informing the customer that non-cash payment using the mobile terminal 50 (settlement at the first settlement means) is impossible. The mobile terminal 50 determines which store clerk call guidance screen, FIG. 29(B) or FIG. 29(C), to display depending on the reason for payment not being possible, which is indicated in the payment impossibility notification received in step S1110.

[0292] When the store clerk call guidance screen is displayed, the customer goes to the settlement device 40 and calls a store clerk. The store clerk may be called, for example, by operating the settlement device 40. The customer may then make settlement at the settlement device 40 after the called store clerk has dealt with the pending items, confirmed that the registered items match the items in the shopping cart, and so on.

[0293] Step S1114: After the process of step S1112, or if it is determined in step S1109 that payment by cash has been selected, the mobile terminal 50 generates transaction code information indicating the transaction corresponding to the current product registration. Step S1115: The portable terminal 50 displays, on the touch panel display unit 506, a settlement device guidance screen including the transaction code information generated in step S1114 and showing a message guiding the customer to the settlement device 40. When the portable terminal 50 reaches step S1115 after steps S1111 and S1112, it displays the settlement device guidance screen of Fig. 22(A). On the other hand, when the portable terminal 50 reaches step S1115 after determining in step S1109 that payment by cash has been selected, it displays the settlement device guidance screen of Fig. 22(B).

[0294] Next, an example of a processing procedure executed by cloud server 20 will be described with reference to the same figure. Since the processing in steps S2101 to S2104 is similar to steps S2001 to S2004 in Fig. 21, a description thereof will be omitted here.

[0295] Step S2105: If it is determined in step S2003 that the product registration processing information has not been received, or after the processing of step S2104, cloud server 20 determines whether or not a payment availability inquiry transmitted from mobile terminal 40 in step S1110 has been received. If it is determined that a payment availability inquiry has not been received, the process returns to step S2001.

[0296] Step S2106: If it is determined in step S2105 that a payment availability inquiry has been received, cloud server 20 determines whether or not payment for the corresponding transaction is possible at mobile terminal 40. At this time, mobile terminal 40, as described above, refers to the product registration information for the corresponding transaction and determines whether or not the conditions that a pending product is not registered and the number of registered product cancellation operations is less than the threshold value are met. Step S2107: Cloud server 20 transmits a payment feasibility notification indicating the determination result as to whether or not payment is possible in step S2106 to mobile terminal 50. As described above, when the determination result indicates that payment is not possible, cloud server 20 includes in the payment feasibility notification the reason for the payment being not possible (at least one of registration of a pending product and the number of operations to cancel a registered product being equal to or greater than a threshold).

[0297] Step S2108: After the process of step S2107, the cloud server 20 determines whether or not the non-cash payment request transmitted from the mobile terminal 40 in step S1111 has been received. If it is determined that the non-cash payment request has not been received, the process returns to step S2101. Step S2109: When cloud server 20 determines in step S2108 that a non-cash payment request has been received, it executes a payment process corresponding to the non-cash payment type specified by the non-cash payment request. At this time, cloud server 20 may communicate with an external payment server (for example, if the non-cash payment type is credit card use, a server for credit card payment operated by a credit card company) as appropriate according to the specified non-cash payment type, etc. Step S2110: In response to the completion of the non-cash payment in step S2109, the cloud server 20 transmits a payment completion notification to the mobile terminal 50. Step S2111: Cloud server 20 sets a settled flag indicating that the payment has been settled for the merchandise registration information corresponding to the current non-cash payment completed transaction.

[0298] <Modification> Modifications of the fourth and fifth embodiments will be described below. [First Modification] The processes in steps S1110 and S1113 shown in the flowchart of Fig. 28 may also be applied to the fourth embodiment. That is, in the fourth embodiment, when it is determined in step S1108 that payment by a specific non-cash payment type is permitted, the mobile terminal 50 further determines in step S1110 whether or not payment is possible based on the contents of the product registration information. If it is determined in step S1110 that payment is impossible, the mobile terminal 50 displays a store clerk call guidance screen in step S1113. If it is determined in step S1110 that payment is possible, the mobile terminal 50 proceeds to the process of step S1111.

[0299] [Second modified example] In each of the third and fourth embodiments described above, each time a product is registered on the mobile terminal 50, information about the registered product (such as product code) is transmitted to the cloud server 20, and the cloud server 20 updates the product registration information (basket information) based on the received information. In response to this, for example, the mobile terminal 50 may refrain from sending information such as a product code to the cloud server 20 until product registration is complete, and may output product registration information reflecting the product registration results to date depending on the timing at which product registration is completed and payment is made. Specifically, in the case of a non-cash payment made on the mobile terminal 50 without using the settlement device 40, the mobile terminal 50 includes the product registration information in the non-cash payment request when sending the non-cash payment request to the cloud server 20. This enables the cloud server 20 to determine the payment amount for the non-cash payment and execute processing according to the non-cash payment. Furthermore, when settlement is performed at the settlement device 40, the mobile terminal 50 only needs to reflect the contents of the product registration information in the QR code displayed on the settlement device guidance screen. This allows the settlement device 40 to obtain the product registration information and execute settlement processing by reading the QR code.

[0300] [Third Modification] In the above third and fourth embodiments, when a payment using a non-cash payment type is completed on the mobile terminal 50 without using the payment device 40, a payment device guidance screen is displayed, but if the customer does not need a paper receipt, they can simply leave the store, assuming that their shopping is complete. However, for example, to prevent fraud, a customer who completes a payment using a non-cash payment type using a mobile terminal 50 may be required to have a paper receipt issued by the settlement device 40 as proof that the non-cash payment was completed using the mobile terminal 50. Furthermore, when operating as in each of the above embodiments, there is a possibility of fraud, such as taking away the product without issuing a receipt to prove completion of credit card payment at the settlement device 40 or receiving payment at the settlement device 40. To prevent such fraud, for example, code information may be printed on the receipt issued by the settlement device 40, and a gate equipped with a code reader may be provided at the exit where customers who have made a purchase in the store exit. The code information printed on the receipt may be, for example, a transaction identifier. When a customer who has made a purchase leaves the store, the code information printed on the receipt is read by a code reader at the exit gate. In response to reading the code information, the gate inquires of the cloud server 20, for example, as to whether or not the transaction indicated by the transaction identifier indicated by the read code information has been settled. If the cloud server 20 responds that the transaction has been settled, the gate operates to let the customer pass. On the other hand, if the cloud server 20 responds that the transaction has not been settled, the gate operates to not let the customer pass.

[0301] [Fourth Modification] When settlement (payment) is made at a settlement device without making a non-cash payment using the mobile terminal 50, the settlement device used for settlement may be one that executes the settlement process in response to operations by a store clerk rather than a customer. In this case, for example, a store clerk operating the settlement device 40 confirms (item matching) that the items presented in the product list on the settlement screen match the items in the customer's shopping cart in response to the customer who has registered the items via the product registration application on the mobile terminal 50. However, the item matching task requires the store clerk to check each item in the shopping cart against the items presented in the product list on the settlement screen, which takes a certain amount of time.

[0302] Therefore, for example, RFID (Radiofrequency Identifier) ​​tags that store product information about the corresponding products are attached to the products, and a tag reader that corresponds to the RFID tags is provided in the payment device 40. When checking products, the store clerk has the tag reader read the product information stored in the RFID tag of each product in the customer's shopping cart. In this case, the store clerk may pick up each product one by one and bring the RFID tag of the product close to the tag reader to be read. Alternatively, the shopping basket may be placed in a predetermined position corresponding to the communication range of the tag reader, so that the tag reader can read the RFID tag of each product in the shopping basket. The settlement device 40 may display, for example, on the settlement screen, a product list based on the transaction code information and a product list based on the product information read by the tag reader. In this case, the store clerk can compare the product list based on the transaction code information with the product list based on the product information read by the tag reader to perform product matching. In this case, the settlement device 40 may compare the product list based on the transaction code information with the product list based on the product information read by the tag reader to determine whether the details of the two match, and notify the store clerk of whether they match. In this case, when registering a product via the product registration application of the mobile terminal 50, the tag reader function of the mobile terminal 50 may be used to read the product information from the RFID tag of the product, thereby obtaining the product information.

[0303] Furthermore, the product matching may be configured as follows. That is, the weight of each product is registered in the product information corresponding to each product, and the total weight of the registered products is included in the product registration information indicating the product registration result. When the store clerk checks the products, he places the shopping basket containing the products on a weighing scale installed near the settlement device 40. In this case, the settlement screen displays a list of products based on the transaction code information as well as the total weight of the products included in the product registration information contained in the transaction code information. The store clerk compares the actual weight measured by the weighing scale with the total weight according to the product registration results displayed on the settlement screen to determine whether the registered products are the same as the products in the shopping basket.

[0304] [Fifth Modification] In each of the above embodiments, the receipt issued in the settlement process executed in step S3004 and the receipt issued in step S3006 in Fig. 23 may be issued as an electronic receipt. The electronic receipt may be transmitted from the cloud server 20 to the mobile terminal 50 in a format that can be output (displayed, printed, etc.) by the product registration application of the mobile terminal 50, for example, at a timing corresponding to step S3004 or step S3006. Alternatively, the electronic receipt may be issued in the form of an e-mail addressed to an e-mail address managed by the cloud server 20 as customer information of the customer who has the product registration application installed on the mobile terminal 50.

[0305] [Sixth Modification] In addition, a customer who has set permission for a specific non-cash payment type in the product registration application may be given benefits such as coupons, points, etc., at an appropriate time. In addition, when considering the provision of benefits such as points, the product registration application function of each of the above embodiments may be incorporated as a part of the point management application, for example. By offering such benefits, it is possible to encourage more customers to use the product registration application not only to register products but also to make non-cash payments such as credit card payments, thereby further improving the efficiency of checkout at the store.

[0306] [Seventh Variation] In each of the above embodiments, the presence of the mobile terminal 50 in the store is detected by receiving a beacon signal transmitted from a beacon terminal BTM installed in the store. The detection of the presence of the mobile terminal 50 in the store may be performed, for example, by using a positioning function such as a global positioning system (GPS) provided in the mobile terminal 50. For example, store location information is set in advance in a product registration application of the mobile terminal 50. The set location information may be stored in the mobile terminal 50. Then, when the currently determined location corresponds to the location of a store registered in the product registration application, the product registration application operating on the mobile terminal 50 may be set to a product registration mode and operate in the foreground.

[0307] [Eighth Modification] In the above embodiment, an example is given of a case where the system is compatible with a store such as a supermarket where customers shop. In this modified example, the system is also compatible with orders (corresponding to product registration) and payments at restaurants in addition to the above stores. In this case, the product registration application installed on the mobile terminal 50 is provided as one that can also handle product registration and payments at restaurants.

[0308] In this modified example, for example, when a customer at a certain location starts up a product registration application on the mobile terminal 50, the mobile terminal 50 displays on a map stores that are present within a certain range based on the customer's own position measured using the GPS function. The stores displayed at this time include not only supermarkets, but also restaurants, as long as they are present within the certain range. When an operation is performed to select a store such as a supermarket from among the stores displayed on the map, if the selected store is located within a certain distance range, the mobile terminal 50 displays a product registration screen corresponding to the selected store, and if the selected store is located outside the certain distance range, it displays a store information screen that provides information about the store, for example. Furthermore, when an operation is performed to select a restaurant from among the stores displayed on the map, the mobile terminal 50 transitions to a reservation screen for the selected restaurant. Depending on the reservation screen, it may be possible to perform an operation to reserve the number of people, date and time, etc. Furthermore, depending on the reservation screen, it may be possible to perform an operation to reserve a seat. When reserving a seat, for example, the seating layout in the store and the seat availability may be displayed. Furthermore, for example, in the case of a restaurant such as a family restaurant, the product registration application may be used to allow a customer to make a reservation for waiting for an available seat on the day. In this case, when making a reservation using the product registration application, the customer may be able to specify the number of people for the reservation and the seats. In this case, for example, the predicted waiting time and the number of people waiting may be presented to the customer. Also, for example, when the waiting time or the number of people waiting falls below a certain level, the mobile terminal 50 may notify the customer in a predetermined manner that it is soon their turn to come.

[0309] Then, the customer who has taken his / her seat inputs seat identification information for identifying that seat (table) into the mobile terminal 50. The seat identification information may be input by having the mobile terminal 50 running a product registration application read a code (for example, a QR code or a barcode) attached to the table. Alternatively, the seat identification information may be input by a wireless communication tag (IC tag, RFID tag, etc.) provided at a predetermined location near the table or seat and the mobile terminal 50 acquiring the information from the wireless communication tag via short-range wireless communication such as NFC (Near Field Communication) or Bluetooth (registered trademark). Alternatively, the seat identification information may be input in response to an operation of selecting a relevant seat by, for example, tapping on a screen showing the seating layout displayed on the mobile terminal 50 on which the product registration application is running. The mobile terminal 50 to which the seat identification information has been input as described above transmits the input seat identification information to a cloud server corresponding to the restaurant, whereby the seats in the restaurant are associated with the customer information.

[0310] After the seat identification information is input, the mobile terminal 50 running a product registration application displays a menu order screen corresponding to the store. A customer can select a menu from the menu order screen and perform an operation to confirm the order for the selected menu. Furthermore, when multiple people, including the customer, visit a restaurant, it may be possible to confirm the orders of multiple customers collectively using one mobile terminal 50. In this case, the orders of multiple customers may be included in one transaction corresponding to the customer as the user of the mobile terminal 50, for example, or the orders can be classified individually for each of the multiple customers by inputting customer identification information for each customer and associating the orders with each customer identification information. The confirmed order information is sent to, for example, a cloud server, and the cloud server sends the received order information to a store terminal. The waiter can cook and serve the food according to the customer's order while checking the order information received at the store terminal. At this time, the seat to which the food is to be served is specified based on the input seat identification information.

[0311] Furthermore, the settlement at the restaurant may be carried out in accordance with the fourth embodiment described with reference to Fig. 22 and Fig. 23. In other words, non-cash settlement such as credit card settlement may be completed by the product registration application without using the settlement device of the store (restaurant). Then, the mobile terminal 50 may display a settlement device guidance screen conforming to FIG. 22(B). In this case, the customer may go to the settlement device to have a receipt issued. The receipt issued in this manner serves as proof that the customer has correctly completed settlement using non-cash payment. For example, in order to prevent fraud, a store may operate in such a way that the customer is required to have the settlement device issue a receipt whenever non-cash payment is made using the mobile terminal 50.

[0312] In addition, if a store operates in such a way that coupons, discount tickets, and even parking tickets are issued at the settlement device, a settlement device guidance screen similar to that shown in Figure 22 (B) may be displayed on the mobile terminal so that customers can go to the settlement device to receive the various types of tickets mentioned above.

[0313] For example, currently, parking tickets are often printed on paper. Therefore, a ticket that waives parking fees may be issued by making payment at the payment settlement device. Furthermore, the payment settlement device may be configured to update information such as the parking time on the parking ticket. This is expected to improve the usability of the payment settlement device and prevent fraud.

[0314] In addition, if a customer orders take-out food in addition to eating and drinking in the restaurant, if non-cash payment is completed via mobile device, there is a possibility that after finishing their meal, the customer will forget that they ordered take-out food and just leave the restaurant. Therefore, in the case of the above-mentioned order contents, non-cash payment completed at the mobile terminal is not possible, and the payment may be made at the settlement device. In this case, the mobile terminal displays a settlement device guidance screen similar to that shown in FIG. 22(A) to guide the customer to make the payment at the settlement device. In this way, for example, when the customer goes to the settlement device, a store clerk working at a nearby service counter or the like can reliably hand over the take-out items to the customer, preventing the customer from leaving the store without bringing the take-out items. At this time, the store clerk working at the service counter or the like may hand over a delivery ticket for receiving the take-out items. Alternatively, in response to completing a non-cash payment using the mobile terminal 50, a message may be displayed on the mobile terminal 50, for example, instructing the customer not to forget to take home any takeaway items. In the above explanation, the product registration application of this modified example has been described as being compatible with both supermarkets and restaurants, but it may be configured, for example, to be compatible with restaurants but not with stores such as supermarkets.

[0315] <Summary of the embodiment> (1) As described above, one aspect of this embodiment is a self-registration system including a mobile terminal that reads product information related to a product in response to a customer's operation and registers the product based on the read product information, and a settlement device (e.g., settlement device 40) that can settle a transaction in response to the product registration, the self-registration system further includes an identification means that identifies identification information (e.g., transaction code information) that can identify the transaction based on the output of the mobile terminal, and a first settlement means that causes settlement in response to the product registration to be performed by a specific payment type at the mobile terminal, a determination means that determines whether the transaction indicated by the identified identification information has been settled by the first settlement means, and a second settlement means that settles the transaction at the settlement device when the determination means determines that the transaction has not been settled by the first settlement means. According to the above configuration, it is possible to register products and settle the registered products by a specific payment type on the mobile terminal 50. Then, the settlement device is configured to settle the payment in the case where the payment has not been settled on the mobile terminal 50. As a result, in this embodiment, among customers who shop at the store, there are customers who do not need to undergo product registration and payment at the payment device 40. This makes it possible to reduce the number of customers who shop at the store and undergo payment at the payment device 40, improving payment efficiency.

[0316] (2) One aspect of this embodiment is the self-registration system described in (1) above, further comprising an output means for causing the settlement device to output information corresponding to the corresponding transaction (e.g., a receipt) when the determination means determines that settlement has been completed by the first settlement means. According to the above configuration, it is possible to have the settlement device output (issue) a receipt for the corresponding transaction even if the payment has already been settled at the mobile terminal 50. This allows the customer to obtain proof that the payment was properly completed at the settlement device 40 before leaving the store.

[0317] (3) One aspect of this embodiment is the self-registration system described in (1) or (2) above, further comprising a selection means for selecting a payment type. According to the above configuration, when making a settlement using the mobile terminal 50 or the settlement device 40 (30), the customer can make the settlement using the payment type that is most preferable to him / her from among a plurality of payment types.

[0318] (4) One aspect of this embodiment is the self-registration system described in (3) above, further comprising a display control means for displaying the screen of the selection means on the settlement device when the determination means determines that settlement has not been completed by the first settlement means. According to the above configuration, when the customer does not settle the bill using the mobile terminal 50, the customer can select a payment type at the settlement device 40 (30) and then settle the bill.

[0319] (5) One aspect of this embodiment is the self-registration system described in (3) or (4) above, further comprising a notification means for notifying a customer on the mobile terminal that settlement at the first settlement means is not possible when the selection means selects a payment type for which settlement at the first settlement means is permitted, depending on the product registration result. According to the above configuration, even if a customer attempts to settle the bill using the mobile terminal 50, depending on the contents of the registered items, the customer is notified that settlement at the first settlement means is not possible. This makes it possible to deal with situations that require the assistance of a store clerk, such as when the registered items include reserved items or the number of registered item cancellation operations is large.

[0320] (6) One aspect of this embodiment is a program for a self-registration system for causing a first computer to function as a portable terminal that reads product information related to a product in response to a customer's operation and registers the product based on the read product information, and for causing a second computer to function as a settlement device capable of settling a transaction in response to the product registration, wherein the program causes the first computer to function as an identification means that identifies identification information capable of identifying the transaction based on the output of the portable terminal, and as a first settlement means that, when settlement by a specific payment type is permitted, causes settlement in response to the product registration to be performed by the specific payment type, and causes the second computer to function as a second settlement means that performs settlement when the transaction indicated by the identified identification information has not been settled by the first settlement means.

[0321] In addition, a program for realizing the functions of the settlement device 40, the mobile terminal 50, the cloud server 20, etc. described above 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 perform the processing of the settlement device 40, the mobile terminal 50, the cloud server 20, etc. described above. 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 a plurality of computer devices connected via a network including the Internet, a WAN, a LAN, a dedicated line, and other communication lines. In addition, the "computer-readable recording medium" refers to a portable medium such as a flexible disk, an optical magnetic disk, a ROM, a CD-ROM, and a storage device such as a hard disk 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 the distribution server that can be accessed from the distribution server in order 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. That is, the format in which the program is stored in the distribution server does not matter as long as the program can be downloaded from the distribution server and installed in a form executable by the terminal device. The program may be divided into multiple parts, each of which may be downloaded at a different time and then combined on the terminal device, or each of the divided programs may be distributed by a different distribution server. Furthermore, the term "computer-readable recording medium" includes a storage medium that holds a program for a certain period of time, such as a volatile memory (RAM) inside a computer system that is a server or client when a program is transmitted over a network. The program may also be one that realizes part of the above-mentioned functions.Furthermore, the above-mentioned functions may be realized in combination with a program already recorded in the computer system, that is, a so-called differential file (differential program). [Explanation of symbols]

[0322] 10, 11, 12 Management device, 20, 21 Cloud server, 30 Payment device, 40, 41 Payment device, 50 Mobile terminal, 401 CPU, 402 ROM, 403 RAM, 404 Hard disk, 405 Customer side display unit, 406 Customer side scanner unit, 408 Card payment unit, 409 Change machine, 410 Clerk side display unit, 411 Key operation unit, 412 Clerk side scanner unit, 413 Print unit, 414 Audio output unit, 415 Communication unit, 506 Touch panel display unit, 507 Operation unit, 508 Imaging unit

Claims

1. A self-registration system including a mobile terminal that reads product information related to a product in response to an operation by a customer and registers the product based on the read product information, a payment device that can settle a transaction in accordance with the product registration, and a server device, an identification means for identifying, in the settlement device, identification information capable of identifying the transaction based on an output of the mobile terminal; a first settlement means for allowing the settlement according to the registered merchandise to be carried out by a specific settlement type on the mobile terminal; a second settlement means for performing settlement for the transaction identified by the identification information in the settlement device; a settlement permission determining means for determining, in the mobile terminal, that settlement at the first settlement means is permitted when the products registered by the mobile terminal do not include products requiring a store clerk to input a price as a predetermined treatment, and determining that settlement at the first settlement means is prohibited when the registered products include the products requiring a treatment; A self-registration system comprising:

2. an acquisition means for acquiring, in the mobile terminal, identification information capable of identifying the transaction; and an output unit that outputs information corresponding to the corresponding transaction at the settlement device when the transaction indicated by the acquired identification information has been settled by the first settlement unit. The self-registration system of claim 1 .

3. The mobile terminal further includes a second display control means for displaying a payment type selectable after product registration is completed, and displaying a guide for inducing settlement by the second settlement means when settlement by the first settlement means is not possible for the selected payment type. The self-registration system according to claim 1 or 2.

4. A program for a self-service registration system for causing a first computer to function as a portable terminal that reads product information related to a product in response to an operation by a customer and registers the product based on the read product information, and for causing a second computer to function as a settlement device capable of settling a payment in accordance with a transaction in accordance with the product registration, The first computer, a first settlement means for allowing settlement according to the registered merchandise to be carried out by a specific settlement type; functioning as a settlement permission determining means for determining that settlement at the first settlement means is permitted when the registered products do not include products requiring a store clerk to input a price as a predetermined action, and determining that settlement at the first settlement means is prohibited when the registered products include products requiring a store clerk to input a price as a predetermined action; The second computer, an identification means for identifying identification information capable of identifying the transaction based on an output from the mobile terminal; to function as a second settlement means for settling the transaction identified by the identification information program.

Images