JP7716142B2 - program - Google Patents

Description

The present invention relates to a program .

In recent years, a system has become known in which a shopping application is installed on a mobile terminal device, such as a smartphone, carried by a customer, and the customer can register products themselves in a store (see, for example, Patent Document 1). The mobile terminal device periodically checks its own location and reports an error if it is not located within the store.

Special Publication No. 2013-541107

However, with conventional technology, there was a problem in that frequent error notifications could prevent customers from shopping smoothly. For example, in environments where it is difficult to obtain location information, such as when the store is located underground, the mobile terminal device may determine that it is not located within the store and may frequently issue error notifications.

The present invention was made in light of these circumstances, and its purpose is to provide technology that enables smooth shopping.

In order to solve the above-mentioned problems, one aspect of the present invention is a terminal device comprising: location information acquisition means for acquiring location information indicating a current location; store identification information acquisition means for acquiring store identification information presented at a store; registration means for starting product registration in response to the establishment of one of two start conditions: a first condition for identifying the store using the location information; and a second condition for identifying the store using the store identification information; determination means for determining whether the product registration is being carried out legitimately; and notification means for issuing an error notification using the determination result of the determination means, wherein the notification means issues the notification based on the start condition that has been established.

1 is an explanatory diagram showing a network configuration of a shopping system 1 according to an embodiment. FIG. 2 is an explanatory diagram showing an example of installation of a POS terminal device 20. FIG. 2 is a block diagram showing the hardware configuration of a POS terminal device 20. FIG. 2 is an explanatory diagram showing an example of a hardware configuration of a mobile terminal device 50. FIG. 2 is an explanatory diagram showing an example of the appearance of the weighing device 30. FIG. 2 is an explanatory diagram showing an example of the hardware configuration of the weighing device 30. 10 is an explanatory diagram showing an example of various information for each mobile terminal device 50 managed by the cloud server Sv. FIG. FIG. 2 is a sequence diagram showing the flow of processing related to product registration and payment in the shopping system 1. 10 is a flowchart showing an example of a store entry process performed by the mobile terminal device 50. FIG. 10 is an explanatory diagram showing an example of a screen displayed on the display 409 of the mobile terminal device 50 when entering a store. 10 is a flowchart showing an example of a product registration process for a barcode product performed by a mobile terminal device 50. FIG. 10 is an explanatory diagram showing an example of a screen displayed on the display 409 of the mobile terminal device 50 after the store entry process is completed. 10 is a flowchart showing an example of a product registration process for a product to be weighed, which is performed by the mobile terminal device 50. FIG. 10 is an explanatory diagram showing an example of a procedure for registering a commodity to be weighed. FIG. 10 is an explanatory diagram showing an example of a standby screen displayed on the weighing device 30. FIG. 10 is an explanatory diagram showing an example of a screen displayed on the mobile terminal device 50 after reading the connection code. 10 is an explanatory diagram showing an example of a screen displayed on the weighing device 30 and the mobile terminal device 50 during weighing. FIG. 10 is a flowchart illustrating an example of a notification process based on location information performed by the mobile terminal device 50. FIG. 10 is an explanatory diagram showing an example of an error screen based on location information displayed on the mobile terminal device 50. 10 is a flowchart illustrating an example of a notification process based on product registration operation information, which is performed by the mobile terminal device 50. FIG. 10 is an explanatory diagram showing an example of an error screen based on product registration operation information displayed on the mobile terminal device 50. 10 is a flowchart showing an example of a registration information confirmation process performed by the POS terminal 20. 10A and 10B are explanatory diagrams showing an example of screen transitions displayed on the customer display unit 205 of the POS terminal device 20 during payment. 10 is a flowchart showing a first modification of the notification process based on location information performed by the mobile terminal device 50. 10 is a flowchart showing a second modification of the notification process based on location information performed by the mobile terminal device 50. 10 is a flowchart showing a third modification of the notification process based on store identification information, which is performed by the mobile terminal device 50. 10 is a flowchart showing a fourth modified example of the notification process based on location information performed by the mobile terminal device 50. 10 is a flowchart showing a fifth modified example of a notification process based on product registration operation information, which is performed by the mobile terminal device 50. 10 is a flowchart showing a sixth modification of the notification process based on product registration operation information, which is performed by the mobile terminal device 50; 10 is a flowchart showing a seventh modified example of a notification process based on product registration operation information, which is performed by the mobile terminal device 50;

The following describes embodiments of the terminal device, product sales data processing system, notification method, and program of the present invention.

(Embodiment)
(Network Configuration of Shopping System 1)
1 is an explanatory diagram showing the network configuration of a shopping system 1 according to an embodiment. The shopping system 1 is an example of a product sales data processing system. The shopping system 1 can be introduced into various stores, such as supermarkets, home improvement stores, convenience stores, and various supply stores.

In FIG. 1, the shopping system 1 includes a cloud server Sv, a store controller (management device, store computer) 10, a transaction status management device 11, a POS (Point of Sales) terminal 20, a weighing device 30, and a mobile terminal device 50. The mobile terminal device 50 is an example of a terminal device.

Each device and terminal is communicatively connected via a network. For example, the store controller 10, transaction status management device 11, POS terminal device 20, and weighing device 30 are communicatively connected via a LAN (Local Area Network) 55. Each device and terminal is a computer device equipped with a CPU (Central Processing Unit), ROM (Read Only Memory), RAM (Random Access Memory), a communication unit, etc.

The cloud server Sv is a server device that manages various information such as information about customers, information about stores, and information about products at each store. For example, the cloud server Sv generates cart information indicating a virtual cart for each customer based on product information read by the mobile terminal device 50, and registers the products in the virtual cart. The information managed (generated and stored) by the cloud server Sv will be described later using Figure 7.

The store controller 10 manages the POS terminal devices 20 and weighing devices 30, and stores various information necessary for transactions, such as a product master. The product master is a file that stores product information such as product identification information (e.g., JAN (Japanese Article Number) code), product name, and sales price for each product. The product master also includes product identification information, product name, and unit price of products that require weighing (hereinafter referred to as "products to be weighed"). In addition to the product master, the store controller 10 also stores various information such as inventory status, sales history, and deposit and withdrawal records. The store controller 10 may also store customer membership information.

The transaction status management device 11 is a device that monitors the POS terminal device 20 and the weighing device 30. Specifically, the transaction status management device 11 displays the status of the POS terminal device 20 (operating mode, processing status, etc.) and controls the POS terminal device 20. The transaction status management device 11 also displays the processing status of the weighing device 30 and controls the weighing device 30. Note that the transaction status management device 11 may only have a monitoring function.

The POS terminal 20 is a computer device capable of executing settlement processing to settle (pay) for products registered by the mobile terminal device 50. In addition to settling for products registered by the mobile terminal device 50, the POS terminal device 20 can also settle for products registered by itself or another POS terminal device 20. In this embodiment, the POS terminal device 20 is capable of switching operating modes. Specifically, in addition to a checkout-only mode in which the POS terminal device 20 functions as a settlement-only device, it can also operate in a clerk registration mode in which products are registered by operation of a clerk, and a customer registration mode (full self-service mode) in which products are registered by operation of a customer. Note that although Figure 1 shows multiple POS terminal devices 20, there may be only one.

The weighing device 30 is a computer device that weighs the products to be weighed. The weighing device 30 calculates the price of the products to be weighed using the weighed weight (or number) and the unit price of the products to be weighed. The products to be weighed are products that are different from regular products. Here, regular products are, for example, products that have a JAN code attached. When the mobile terminal device 50 reads the JAN code, it queries the cloud server Sv for the read JAN code and obtains the price data associated with the JAN code.

On the other hand, the products to be weighed are products whose prices vary depending on the weight and quantity of the item. Examples of products to be weighed include fresh foods such as vegetables, fruits, fish, and meat, as well as prepared foods. The weighing device 30 prints and outputs a coded label containing the amount, weight, etc. of the product to be weighed. The label contains the price. The label (barcode) attached to the product to be weighed uses the NON-PLU (Price Look Up) method. Note that although Figure 1 shows an example of multiple weighing devices 30, there may be only one.

The mobile terminal device 50 is a portable computer device such as a smartphone, tablet device, or mobile phone. The mobile terminal device 50 is equipped with a communication unit, an imaging unit (camera), a touch panel, etc., and is operated by the customer. In this embodiment, the mobile terminal device 50 is detachably attached to the shopping cart. However, the mobile terminal device 50 may also be permanently attached to the shopping cart. Furthermore, the mobile terminal device 50 may be owned by the customer, or may be a loaned item loaned to the customer by the store.

The mobile terminal device 50 scans (reads) the barcode (product code) attached to the product and accepts the product's registration. In other words, the mobile terminal device 50 has a recognition function that recognizes the barcode attached to the product.

The recognition function of the mobile terminal device 50 only needs to be able to read the product code attached to the product, and does not need to be able to identify the product from the read product code. In other words, when a barcode is present as an object in an image captured by the imaging function (an image acquired as a through image), the mobile terminal device 50 only needs to be able to read the product code from the barcode.

The mobile terminal device 50 may also be equipped with image recognition technology. Specifically, the mobile terminal device 50 may be equipped with image recognition technology that extracts feature points from an image (through-the-lens image, captured image) and recognizes the imaged subject (object, etc.). For example, the mobile terminal device 50 may use image recognition technology to identify (estimate) the imaged product. By using such image recognition technology, the mobile terminal device 50 may also be able to identify fresh foods such as vegetables and fruits that do not have barcodes, for example.

In addition, application software (hereinafter sometimes referred to as the "shopping app") for registering and settling products related to the shopping system 1 is installed on the mobile terminal device 50. By launching the shopping app, the mobile terminal device 50 reads the barcode attached to the product and sends the read information to the cloud server Sv. As a result, the registered product information corresponding to the barcode is registered in the virtual cart on the cloud server Sv.

When making a payment, the mobile terminal device 50 displays a two-dimensional code (hereinafter sometimes referred to as the "payment code") corresponding to the registered product. The payment code is represented, for example, by a QR code (registered trademark). When the POS terminal device 20 reads the payment code, it requests the cloud server Sv to send registration information corresponding to the mobile terminal device 50. When the POS terminal device 20 receives the registration information from the cloud server Sv, it becomes possible to make the payment at the POS terminal device 20. Note that, hereinafter, products registered in the virtual cart may be referred to as "registered products."

In addition, in this embodiment, the device that performs the settlement is the POS terminal device 20, but this is not limited to this. For example, the device that performs the settlement may be a device dedicated to settlement installed in the store, or a computer device for settlement that is permanently attached to the shopping cart. This computer device may, for example, only enable card settlement using credit cards or prepaid cards.

(Installation example of POS terminal device 20)
FIG. 2 is an explanatory diagram showing an example of the installation of the POS terminal 20. FIG. 2(A) is a perspective view of the POS terminal 20 as seen from the customer side. FIG. 2(B) is a perspective view of the POS terminal 20 as seen from the store clerk side. As shown in FIG. 2(A), a counter is placed on the right side of the POS terminal 20 as seen from the customer side. Although not shown in the figure, a counter may also be placed on the left side of the POS terminal 20 in FIG. 2(A). In other words, counters may be placed on both sides of the POS terminal 20. The counter can also accommodate a shopping basket.

As shown in FIG. 2, the POS terminal 20 has a sign pole 220. The sign pole 220 has a light-emitting unit. The light-emitting unit of the sign pole 220 is, for example, a lamp or LED (light emitting diode), and can be illuminated in a predetermined color or a predetermined lighting pattern. The lighting pattern of the sign pole 220 can notify the usage status of the POS terminal 20 (in use, warning, calling a store clerk, etc.). The sign pole 220 is installed facing upward, so that the usage status of the POS terminal 20 can be notified to store clerks who are not near the POS terminal 20.

(Configuration example of POS terminal device 20)
Next, the configuration of the POS terminal 20 will be described with reference to FIGS.
Fig. 3 is a block diagram showing the hardware configuration of the POS terminal 20. In Fig. 2 and Fig. 3, the same parts are denoted by the same reference numerals.

An example configuration of the POS terminal 20 shown in Figure 3 will be explained below with reference to Figure 2. The POS terminal 20 comprises a CPU 201, ROM 202, RAM 203, a hard disk 204, a customer display unit 205, a customer scanner unit 206, a card payment unit 208, a change dispenser 209, a store clerk display unit 210, a key operation unit 211, a store clerk scanner unit 212, a printing unit 213, an audio output unit 214, a communication unit 215, and a camera 216. These components can communicate with each other via a bus.

The CPU 201 is a central processing unit that controls the operation of the POS terminal 20 by reading and executing various programs stored in the ROM 202 .
The ROM 202 is a read-only memory that stores various types of information used by the CPU 201, including programs.

RAM 203 is a readable and writable memory that stores various information. For example, RAM 203 stores information acquired from the outside (such as a product master acquired from the store controller 10) and information generated during processing. This information includes, for example, registration information generated during product registration processing and settlement information generated during settlement processing for registered products.

The hard disk 204 stores various types of information. For example, the hard disk 204 stores the results of imaging (e.g., video) captured by the camera 216. The hard disk 204 may store various programs, such as a product sales data processing program executed by the CPU 201, in place of the ROM 202. The hard disk 204 may also store information acquired from an external source or information generated during processing in place of the RAM 203.

The customer display unit 205 is a touch display for customers, and displays various information to customers and receives various inputs from customers.
The customer-side scanner unit 206 is a scanner for customers and optically reads various information. For example, the customer-side scanner unit 206 optically reads barcodes (e.g., product codes) attached to products and codes (e.g., barcodes, two-dimensional codes) printed on receipts (registered trademarks). In addition to the above, the customer-side scanner unit 206 may also read codes (e.g., barcodes, two-dimensional codes) printed on gift certificates (gift certificates, coupons, and complimentary coupons) and various cards (e.g., membership cards, point cards, etc.). Product registration is not limited to registration by reading codes using the customer-side scanner unit 206. For example, a preset key (a button for ordering a product) corresponding to the product can be displayed on the customer-side display unit 205, and the product can be registered by the customer operating (pressing) the preset key. The customer-side scanner unit 206 can also read a payment code displayed on the mobile terminal device 50. When the settlement code is read by the customer side scanner unit 206, the POS terminal device 20 can carry out settlement based on the read content.

The card payment unit 208 is a payment mechanism that accepts various cards (credit cards, prepaid cards such as transportation cards, point cards, etc.). The card payment unit 208 is equipped with a card recognition unit (reading unit), a display unit, and an operation unit. The card recognition unit magnetically or electrically reads information from various cards. The read information is used to settle the purchase. The card recognition unit can also recognize information to be used in settling the current purchase, for example, when using points held on a point card. The card recognition unit can also recognize information that is not used in settling the current purchase, for example, when points are awarded to a point card.

In this embodiment, the card payment unit 208 includes a card recognition unit, a display unit, and an operation unit, but is not limited to these and may include at least a card recognition unit. Furthermore, the card recognition unit in this embodiment may be compatible with contact cards (IC cards, magnetic cards) or contactless cards (IC cards).

The change dispenser 209 (cash settlement unit) is a cash settlement mechanism, and has an input port for banknotes and coins, and an output port for banknotes and coins. The change dispenser 209 calculates the amount 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 dispenser 209 faces the customer side and accepts various operations and cash insertions from customers. The change dispenser 209 also has a sensor that detects banknotes and coins inserted into the input port. This sensor detects that banknotes or coins have been inserted into the input port, and detects the number of each denomination.

The clerk display unit 210 is a touch display for the clerk. The clerk display unit 210 displays various information to the clerk and accepts various inputs from the clerk. The clerk display unit 210 displays preset keys (buttons for ordering products) corresponding to products, and products are registered by the clerk operating (pressing) these preset keys. The clerk display unit 210 also displays a subtotal key that accepts completion of product registration.

The key operation unit 211 is made up of various keys (hardware keys, buttons). The key operation unit 211 accepts various inputs from store clerks. For example, the key operation unit 211 includes buttons corresponding to products, and accepts registration of those products when those buttons are operated. Also, for example, the key operation unit 211 includes a mode switching button, and accepts switching of operating modes when that mode switching button is operated.

The clerk scanner unit 212 is a scanner unit for clerks and optically reads various types of information. For example, the clerk scanner unit 212 optically reads barcodes attached to products and clerk codes attached to clerk name tags. In addition to the above, the clerk scanner unit 212 may also read codes printed on receipts, gift certificates, and various cards. The clerk scanner unit 212 is also capable of reading two-dimensional codes used for payment. When the payment code is read by the clerk scanner unit 212, the POS terminal device 20 can make payment based on the read details.

Note that product registration is not limited to registration by reading a code using the store clerk's scanner unit 212. For example, a key corresponding to a product (e.g., XX newspaper) may be placed on the key operation unit 211, and the product may be registered by the store clerk operating (pressing) that key.

The printing unit 213 prints and outputs various media (receipts, invoices, bills, etc.). The printing unit 213 is capable of changing the orientation of its media outlet. Specifically, the printing unit 213 has a rotatable mechanism and is configured so that the media outlet faces from the store clerk side to the customer side, and from the customer side to the store clerk side. The orientation of the media outlet may be changeable manually, or it may be changeable automatically when the operating mode is switched. The printing unit 213 may also be equipped with a sensor that detects whether the orientation of the printing outlet is correct.

The audio output unit 214 outputs audio. For example, the audio output unit 214 outputs audio guidance, warning sounds, etc. The audio guidance and warning sounds are related to product registration and payment.
The communication unit 215 is an interface for sending and receiving information to and from other devices (the store controller 10, the transaction status management device 11, and other POS terminal devices 20).

The camera 216 is attached to the upper right of the customer display unit 205 as viewed from the customer side. The camera 216 continuously captures video or still images. A charge-coupled device (CCD) camera or a complementary metal oxide semiconductor (CMOS) camera can be used for the camera 216. The camera 216 captures images of the customer's operations during checkout. Specifically, the camera 216 captures images of the banknotes and coins held by the customer, the change dispenser 209, and hand movements. The camera 216 also captures images of the customer's operations during product registration. Specifically, the camera 216 can capture images of the inside (items) of the shopping carts on the counters on both sides of the POS terminal 20 and the customer's operations during registration. The camera 216 may also be installed separately on the store clerk side. In this case, the POS terminal 20 can determine the presence or absence of a store clerk based on the image captured by the camera 216 installed on the store clerk side.

(Hardware configuration of the mobile terminal device 50)
Fig. 4 is an explanatory diagram showing an example of the hardware configuration of the mobile terminal device 50. In Fig. 4, the mobile terminal device 50 includes a CPU 401, a ROM 402, a RAM 403, a memory 404, a communication unit 405, an operation unit 406, a camera 407, a microphone 408, a display 409, a speaker 410, and a GPS (Global Positioning System) unit 411. Each unit is connected to each other via a bus 420.

The CPU 401 is responsible for overall control of the mobile terminal device 50. The ROM 402 stores various programs. The RAM 403 is used as the work area of the CPU 401. In other words, the CPU 401 uses the RAM 403 as a work area and executes the various programs stored in the ROM 402, thereby controlling the entire mobile terminal device 50.

The memory 404 stores various data. For example, a flash memory is used as the memory. The memory 404 stores various programs such as a shopping application and a notification program, and various data such as map data and store information.
The communication unit 405 is connected to a network, and is connected to other devices (for example, the transaction management server Sv) via the network. Examples of communication networks that function as networks include the Internet and mobile phone networks.

The operation unit 406 is a touch panel that displays a plurality of touch keys for inputting characters, numbers, various instructions, etc., or hard keys.
The camera 407 reads barcodes attached to products and various two-dimensional codes.
The microphone 408 inputs the operator's voice.
The display 409 displays icons, cursors, menus, windows, characters, images, codes, and the like.

The speaker 410 outputs sounds including voice.
The GPS unit 411 has a function of receiving position information from GPS satellites and detecting the current position on map data of the mobile terminal device 50. The mobile terminal device 50 also includes various sensors (not shown) (e.g., a gyro sensor, an acceleration sensor, a distance sensor, etc.) and has a function of detecting various states of the mobile terminal device 50 (e.g., the inclination of the mobile terminal device 50, the distance between the mobile terminal device 50 and a product), etc.

(Configuration example of weighing device 30)
Next, a configuration example of the weighing device 30 will be described with reference to Figures 5 and 6. Below, the configuration example of the weighing device 30 shown in Figure 6 will be described with reference to Figure 5.
FIG. 5 is an explanatory diagram showing an example of the appearance of the weighing device 30.
Fig. 6 is an explanatory diagram showing an example of the hardware configuration of the weighing device 30. As shown in Fig. 5 or 6, the weighing device 30 includes a CPU 301, a ROM 302, a RAM 303, a memory 304, a communication unit 305, a display unit 306, a printing unit 307, a scanner unit 308, an audio output unit 309, a load cell 310, and a platform 320. These components can communicate with each other via a bus 330.

The CPU 301 is a central processing unit that controls the operation of the weighing device 30 by reading and executing various programs, such as a transaction information output program, stored in the ROM 302 .
The ROM 302 is a read-only memory that stores various types of information used by the CPU 301, including programs.

RAM 303 is a readable and writable memory that stores various information. For example, RAM 303 stores information read from ROM 302 or memory 304, information obtained from the outside, information generated during processing, etc.

The memory 304 stores various information. For example, the memory 304 stores the unit price of the product to be weighed obtained from the store controller 10. Note that the various information stored in the memory 304 may also be stored in an external device (for example, the store controller 10 or an external server device). In this case, when using the various information, the weighing device 30 can query the external device to obtain the various information.

In place of ROM 302, memory 304 may store programs executed by CPU 301. In place of RAM 303, memory 304 may store information read from ROM 302, information obtained from the outside, information generated during processing, etc.

The communication unit 305 is an interface for sending and receiving information to and from external devices. The communication unit 305 receives the unit price corresponding to the product identification information of the product to be weighed from the store controller 10. The weighing device 30 calculates the selling price of the product to be weighed using the weight (or number) of the product placed on the platform 320 and the unit price.

In addition to communication via network communication, the communication unit 305 also performs short-range wireless communication with the mobile terminal device 50. The number of mobile terminal devices 50 with which the communication unit 305 can connect via short-range wireless communication is limited, for example, to one. Specifically, one-to-one short-range wireless communication is performed with the mobile terminal device 50. One-to-one short-range wireless communication is, for example, Bluetooth (registered trademark). Note that one-to-one short-range wireless communication may also be communication using a communication protocol such as NFC (Near Field Communication), Wi-Fi (registered trademark), optical communication, or a 4G (Generation) line. Note that the number of mobile terminal devices 50 with which the communication unit 305 can connect via short-range wireless communication is not limited to one, and may be two or three.

The display unit 306 displays various information to the customer and accepts operations from the customer. The various information displayed on the display unit 306 includes the product name and quantity of the product being weighed, as well as guidance regarding the weighing. The various information displayed on the display unit 306 also includes a two-dimensional code (hereinafter sometimes referred to as a "connection code") that is read by the mobile terminal device 50 to initiate one-to-one communication with the mobile terminal device 50.

The printing unit 307 is a label issuing unit that outputs printed matter (hereinafter also referred to as "label") on which information about the product to be weighed (such as the weight, selling price, and barcode indicating these) is printed.
The scanner unit 308 reads various codes (bar codes, two-dimensional codes, etc.).
The audio output unit 309 outputs audio. For example, the audio output unit 309 outputs audio guidance related to weighing.
The load cell 310 is a sensor that detects weight and measures the weight of the product to be weighed placed on the platform 320.

(Example of information managed by cloud server Sv)
7 is an explanatory diagram showing an example of various information managed by the cloud server Sv for each mobile terminal device 50. The cloud server Sv stores various information including (A) customer information, (B) store information, and (C) cart information. Note that instead of or in addition to storing the various information in a storage unit within the cloud server Sv, the cloud server Sv may store some or all of the various information in another device, such as a file server, accessible by the cloud server Sv.

(Customer information)
FIG. 7A shows an example of customer information. Customer information is information for managing individual customers. Customer information may be membership information for each store or each affiliated store. As shown in FIG. 7A, customer information includes items such as customer identification information, customer name, customer registration date, customer rank, and number of points.

Customer identification information is identification information that uniquely identifies a customer. Customer identification information may be, for example, application identification information (hereinafter referred to as "app identification information") that is uniquely assigned to each shopping app installed on a mobile terminal device 50 when the shopping app is installed on the mobile terminal device 50. App identification information may be, for example, a sequentially assigned number. Alternatively, app identification information may be terminal identification information that is uniquely assigned to the mobile terminal device 50 on which the shopping app is installed. This terminal identification information may be, for example, a telephone number assigned to the customer who is the user of the mobile terminal device 50, or hardware identification information that is uniquely assigned to the hardware of the mobile terminal device 50, such as a MAC (Media Access Control) address.

The customer name is the customer's name or nickname.
The customer registration date is the date and time when customer information was newly registered in the cloud server Sv.
The customer rank is a rank according to the customer's purchase history.
The number of points is the number of points awarded to a customer for shopping using the shopping app. The number of points may include the number of points awarded to each store.

The customer identification information, customer name, and customer registration date are generated when customer information for a new customer is generated. Specifically, the customer identification information is generated when a shopping app is downloaded to the mobile terminal device 50 from the cloud server Sv or a predetermined server that provides general applications. For example, the customer name is generated based on the information entered in the name field of the registration form (input form) on the mobile terminal device 50 when registering a new customer. Furthermore, the customer registration date is generated based on the current date and time when the new customer is registered.

(Store information)
7B shows an example of store information. The store information is information for managing each store. As shown in FIG. 7B, the store information includes items such as store identification information, store name, store identification information 1 (information on a two-dimensional code), and store identification information 2 (location information).
The store identification information includes a store (trade name) or company code and a branch code.
The store name is the name of the store, and is composed of, for example, the store name (trade name) or company name and the branch name.
The store identification information 1 and 2 are information for identifying a store where a transaction takes place (a store where a product is bought and sold). The store identification information 1 is, for example, information represented by a two-dimensional code posted in the store. The store identification information 2 is location information (GPS information) indicating the location of the store.

(Cart information)
7C shows an example of cart information. The cart information is information about products registered by a customer at a store. As shown in FIG. 7C, the cart information includes items such as cart identification information, transaction start date and time, transaction end date and time, customer identification information, registered product information (total), and reserved product information (total).
The cart identification information is information for identifying the cart information, which is a virtual cart. Specifically, the cart identification information includes store identification information, a date, and a serial number (for example, a serial number for each store by date).

The transaction start date and time is the date and time when the transaction started, for example, the date and time when the cart information was created. The transaction start date and time may also be the registration date and time of a single product item, or more specifically, the date and time when the registered product information shown in Figure 7 (C) (Registered Product 1: XX Medium Thick Sauce) was stored. Alternatively, instead of or in addition to the transaction start date and time, the registration date and time for each product may be stored separately.

The transaction end date and time is the date and time when the transaction ended, specifically, the date and time when the settlement was made. For example, the transaction end date and time is the date and time when the settlement was made, but it may also be the date and time when the settlement was made.
The customer identification information is information that uniquely identifies the customer who is performing the transaction.

The registered product information (total) is cumulative information that is updated each time a product is registered. The registered product information (total) includes the number of items (number of products), the estimated subtotal amount, the subtotal amount, and the like.
Registered product information N (N is an integer) includes the number (data number) of the product registered in item N. Registered product information N includes the product code, product name, price, and the date and time of registration of the product. Specifically, registered product information 1 (XX medium-thick sauce) indicates the product registered in item 1. Registered product information 2 (XX cheese) indicates the product registered in item 2. Note that in the example shown in FIG. 7(C), registered product information for items 3 and onward is omitted from the illustration.

Next, we will explain reserved item information (total). Reserved items are items that require confirmation by a store clerk before checkout can begin. For example, reserved items include unscanned items, NON file items, age verification items, security tag items that require the security tag to be removed, and pharmaceuticals.

Unscanned products are pending products that could not be registered due to a failed product code scan (the scanner was unable to read the product). For example, if the product packaging is wrinkled or the barcode is smudged or dirty, a timeout may occur and the barcode may not be recognized.

Here, we will explain in detail why a barcode cannot be recognized due to a timeout. The mobile terminal device 50 is equipped with various sensors (e.g., a gyro sensor, an acceleration sensor, a distance sensor, etc.), and is able to determine that a barcode is being read using the detection results of the various sensors and the image capture results of the camera 407. Specifically, the mobile terminal device 50 is able to determine that a barcode is being read using the detection results of the various sensors when the mobile terminal device 50 is tilted and a product is located a certain distance away from the mobile terminal device 50. Then, if the mobile terminal device 50 determines that a barcode is being read but is unable to read it within a predetermined time, it will time out and identify the product as an unscanned product.

Furthermore, unscanned items include, for example, items that have been placed in a shopping cart by pretending to have their barcodes scanned. In other words, unscanned items include items that may have been subject to fraudulent manipulation, and therefore require confirmation by a store clerk to determine whether or not fraud has occurred. Fraudulent manipulation is detected, for example, using scan results that indicate whether or not a barcode has been scanned, image results from a camera that captures images of the inside of the shopping cart, or detection results that detect the total weight of the items in the shopping cart.

NON file products are, for example, products that are not registered in the product master. Specifically, NON file products are products whose product code was successfully scanned (not marked as an unscanned product) and the product with that product code was queried from the product master (cloud server Sv), but the product could not be registered because the product could not be identified (the product query was not successful).

Age verification products are products that cannot be purchased by minors, such as alcohol and tobacco.
Security tagged merchandise is merchandise with a security tag attached, such as merchandise over a certain amount of money.
Medicines, for example, are products that require explanation from a pharmacist.

As shown in Figure 7 (C), the reserved item information (total) includes the number of items and the type of reserved item (unscanned items, NON file items). The reserved item information (reserved item N: N is an integer) is information about N reserved items and includes the reserved item type of the N reserved items. The reserved item type is information that indicates the type of reserved item. In this example, a reserved item type of "1" indicates an unscanned item, and a reserved item type of "2" indicates a NON file item. The reserved item information also includes the registration date and time of the item. Note that the illustration shows that unscanned items and NON file items are registered as reserved items, but if age verification items, security tag items, or pharmaceuticals are registered as reserved items, these types will be stored in the reserved item information (total).

In addition, pending product information for an unscanned product includes the pending product type "1" as well as image data for the product (image data captured when the mobile terminal device 50 reads the barcode). For example, pending product information 1 includes "1 (unscanned product)," which indicates the pending product type, and image data.

In addition, the pending product information for a NON file product includes the pending product type "2 (NON file product)" as well as the product code read by the mobile terminal device 50. For example, pending product information 2 includes "2 (NON file product)," which indicates the pending product type, and the product code.

(Regarding error notification by the mobile terminal device 50)
The mobile terminal device 50 periodically determines whether or not the device is located within the store, using the location information received from the GPS unit 411. In general, the mobile terminal device 50 issues an error notification if it determines during the presence determination that the device is not located within the store or if it cannot receive location information.

For this reason, in environments where it is difficult to obtain location information, such as when the store is located underground, the mobile terminal device 50 may determine that it is not located within the store and may report an error. If errors are reported frequently, this may prevent customers from shopping smoothly. Therefore, in this embodiment, frequent error reports are suppressed, allowing customers to shop smoothly. Error reports made by the mobile terminal device 50 are described in detail below.

(Functional configuration of the mobile terminal device 50)
First, the functional configuration of the mobile terminal device 50 will be described. The mobile terminal device 50 includes a location information acquisition unit, a store identification information acquisition unit, a registration unit, a determination unit, a notification unit, and a request unit. Each unit is realized by the CPU 401. That is, the CPU 401 executes a notification program stored in the ROM 402 to realize the function of each unit.

The location information acquisition unit acquires location information indicating the current location of the mobile terminal device 50. The location information acquisition unit acquires location information from, for example, the GPS unit 411. Note that the mobile terminal device 50 is not limited to acquiring location information from the GPS unit 411. For example, the mobile terminal device 50 may acquire location information using short-range wireless communication. Examples of short-range wireless communication include Wi-Fi (registered trademark), NFC (Near field communication), Bluetooth (registered trademark), EnOcean (registered trademark), Wi-SUN, and Zigbee (registered trademark). The location information acquisition unit can estimate (acquire) the location of the mobile terminal device 50 using the radio wave strength of the short-range wireless communication or triangulation based on the radio wave strength. The location information acquisition unit can also acquire location information using iBeacon (registered trademark), a communication system that uses BLE (Bluetooth Low Energy).

The store identification information acquisition unit acquires store identification information displayed in the store. The store identification information is represented, for example, by a barcode or two-dimensional code. The store identification information is displayed near the entrance or exit of the store. The store identification information is displayed, for example, on a monitor such as digital signage. However, the store identification information may also be printed on paper and posted on a wall, etc.

The registration unit starts product registration when a start condition is met. The start condition is either a first condition or a second condition. The first condition is a condition in which a store is identified using location information. Specifically, the first condition is a condition in which it is determined that the mobile terminal device 50 is located within a store using the store location information indicated by store identification information 2 in FIG. 7(C) and location information indicating the current location of the mobile terminal device 50 obtained from the GPS unit 411. The second condition is a condition in which a store is identified using store identification information. Specifically, the second condition is a condition in which it is determined that the mobile terminal device 50 is located within a store using store identification information 1 (two-dimensional code information) in FIG. 7(C).

(Details of the validity judgment)
The determination unit determines whether product registration is being performed legitimately. The legitimate determination includes, for example, an operation determination and an existence determination. First, the operation determination will be described. The operation determination is a determination of whether an operation related to product registration is being performed legitimately. An operation being legitimate means that a product is registered as usual, and more specifically, the barcode of a product taken out from a product shelf is read by the mobile terminal device 50 installed in the shopping cart and the product is registered.

On the other hand, if the operation determination determines that an unusual product has been registered, the determination unit determines that the registration operation is improper. An unusual product registration is, for example, a registration that could be considered a price check by a competitor. More specifically, if the number of registered products exceeds a certain number (for example, 50 or more), the determination unit determines that the operation is improper. Furthermore, if all registered products are subsequently canceled, it is more likely that a price check has been performed.

The operation determination may also take into account the time required for registration; specifically, if a certain number of items are registered within a predetermined time, the determination unit may determine that the registration operation is inappropriate. The operation determination may also take into account the category of the registered products; specifically, if a certain number of items in a particular category (e.g., instant curry) are registered with a score of more than a certain number, the determination unit may determine that the registration operation is inappropriate.

Next, the presence determination will be explained. The presence determination is a determination of whether or not the mobile terminal device 50 is present in the store using location information acquired during the transaction. Specifically, the presence determination is performed using the location information of the store and the location information of the current location of the mobile terminal device 50. In the presence determination, the determination unit determines that the mobile terminal device 50 is valid if it is present in the store (within the service area). On the other hand, in the presence determination, the determination unit determines that the mobile terminal device 50 is invalid if it is not present in the store (outside the service area).

(Regarding error notification based on satisfied start conditions)
The notification unit notifies an error using the determination result of the determination unit. In principle, the notification unit notifies an error when the validity determination determines that the product is invalid, and does not notify an error when the validity determination determines that the product is valid. When notifying an error, the mobile terminal device 50 may delete the registered product. Furthermore, when notifying an error, the mobile terminal device 50 may terminate the shopping app (for example, log out).

The notification unit issues an error notification based on the start condition that has been met. Notification of an error based on the start condition means that an error notification may or may not be issued depending on the start condition. For example, an error notification based on an existence determination is issued for a transaction where the first condition is met, but not for a transaction where the second condition is met. Note that even if an error notification is not issued, the determination unit may still make a validity determination.

(Regarding location information acquisition judgment)
In this embodiment, the authenticity determination includes a location information acquisition determination in addition to the above-described operation determination and presence determination. The location information acquisition determination is a determination of whether or not location information of the current location is acquired by the location information acquisition means during the transaction. In the location information acquisition determination, the determination unit determines that the transaction is authentic if location information is acquired, and on the other hand, determines that the transaction is invalid if location information is not acquired.

Note that if the location information acquisition determination determines that location information has been acquired, the determination unit performs a presence determination using the acquired location information. Therefore, if location information is acquired in the location information acquisition determination and the presence determination determines that the mobile terminal device 50 is not in the store (outside the service area), the notification unit will notify of an error.

If the transaction is based on the fulfillment of the first condition and the result of the location information acquisition determination indicates that location information is not acquired, the notification unit will not issue an error notification if the communication environment is poor, such as when the transaction is underground, and location information cannot be acquired (if the location information acquisition determination results in an invalid result), the notification unit will not issue an error notification. In this case, the registration unit will allow product registration to continue. In other words, in this embodiment, product registration will not be interrupted if location information is not acquired.

(Request for acquisition of store-specific information)
In this embodiment, when starting shopping using the shopping app, identifying a store using location information is prioritized over identifying a store using store identification information. Specifically, if a store cannot be identified based on location information before product registration begins, i.e., if the first condition is not met, the request unit (third request means) requests acquisition of store identification information. More specifically, if a store cannot be identified using location information, the request unit requests acquisition of store identification information. The request unit makes the request by, for example, displaying a notification on the display 409 such as "Please read the store identification information."

The registration unit begins product registration when the second condition is met, which is when store-specific information is acquired in response to an acquisition request from the request unit. If the store-specific information is not acquired after a certain amount of time has passed, the request unit may request acquisition of the store-specific information again. If the store-specific information is not acquired after a certain amount of time has passed, the mobile terminal device 50 may notify the user that shopping cannot begin.

(When connected to the weighing device 30)
The registration unit can register a product to be weighed by establishing a communication connection with the weighing device 30 that weighs the product. A product to be weighed cannot be registered unless it establishes a communication connection with the weighing device 30. Therefore, the fact that a product to be weighed has been successfully registered means that the mobile terminal device 50 (customer) is present in the store. Therefore, in this embodiment, the notification unit does not issue an error notification when a product to be weighed is registered, regardless of the start conditions. Note that, although an error notification is not issued when a product to be weighed is registered, the determination unit may still determine whether the product is legitimate.

(Example of a process related to product registration and payment in the shopping system 1)
8 is a sequence diagram showing the flow of processing related to product registration and payment in the shopping system 1. Note that Fig. 8 explains the flow from when a customer visits a store, registers a product to be purchased using his/her mobile terminal device 50, to when the customer completes payment for the product using the POS terminal device 20.

Step S801: First, the mobile terminal device 50 executes a startup process to launch the shopping app in response to a customer operation. During the startup process, the mobile terminal device 50 checks the version of the shopping app and displays a screen prompting the customer to upgrade if necessary. If this is the first startup, the mobile terminal device 50 displays a screen for consent to the terms of use and obtains the customer's consent, thereby completing the startup process.

Step S802: Next, the mobile terminal device 50 performs store entry processing (see FIG. 9). In the store entry processing, the mobile terminal device 50 transmits current location information obtained from, for example, the GPS unit 411 to the cloud server Sv. When the cloud server Sv receives the current location information from the mobile terminal device 50, it searches for stores near the mobile terminal device 50 and transmits the information to the mobile terminal device 50. The mobile terminal device 50 identifies the store where the customer will shop based on the information received from the cloud server Sv, and transmits information about the identified store to the cloud server Sv.

Step S803: Upon receiving the information about the store where the customer will shop, the cloud server Sv generates cart information.
Step S804: When the store entry process is completed, the mobile terminal device 50 waits for the customer to start shopping. Specifically, the mobile terminal device 50 displays the top screen for shopping and waits for the customer to press the shopping start button.

Step S805: The mobile terminal device 50 displays the image capturing area on the display 409 and starts the shopping process.
Step S806: The mobile terminal device 50 performs product registration processing (see FIGS. 11 and 13). Specifically, the mobile terminal device 50 scans the barcode attached to the product in response to a customer operation. After scanning the product, the mobile terminal device 50 transmits the product code obtained by the scan along with cart identification information to the cloud server Sv. Note that if the product indicated by the read product code is, for example, a reserved product such as an unscanned product, the cart identification information and information indicating the reserved product are transmitted as transmission/reception data D3.

Step S807: When the cloud server Sv receives the product code and cart identification information from the mobile terminal device 50, it identifies the cart information that includes the received cart identification information and updates the registered product information. Specifically, when the cloud server Sv receives the product code for item N, it stores the registered product information (registered product N) indicated by the product code. More specifically, the cloud server Sv stores the product code, product name, and price in association with each other. In addition, the cloud server Sv updates the cumulative information (cumulative number of items, subtotal amount, etc.) of the registered product information from the identified cart information.

Step S808: When the mobile terminal device 50 performs the product registration process, it performs a validity determination to determine whether the product registration has been performed properly, and if the validity determination results in an invalid determination, it performs a notification process (see Figures 18 and 20) to notify the user of an error. This makes it possible to notify the user of an error if, for example, the user leaves the store after entering the store and an invalid product registration, such as a price check, is performed.

Step S809: The mobile terminal device 50 then performs a registered product display process to add and display the registered product on the registration screen. The registered product display process includes a process for accepting changes to the quantity, deletion, and the like.
Step S810: The mobile terminal device 50 determines whether or not an instruction to start settlement (registration completion) has been received by the customer, and if the instruction to start settlement has not been received, the process returns to step S806. If the instruction to start settlement has been received, the process proceeds to step S811.

Step S811: When the mobile terminal device 50 receives an instruction to start settlement, it generates a settlement code. The settlement code includes cart identification information and transmission request information for the POS terminal device 20 to carry out settlement. When the transmission request information is sent from the POS terminal device 20 to the cloud server Sv, the cloud server Sv sends registration information to the POS terminal device 20. The registration information is information necessary for settlement, and includes, for example, registered product information such as the product name, price, and subtotal amount. When the mobile terminal device 50 generates the settlement code, it displays the generated settlement code on the display 409.

Step S812: The POS terminal 20 reads the settlement code displayed on the mobile terminal 50. Specifically, after completing product registration, the customer causes the customer-side scanner unit 206 of the POS terminal 20 to scan the settlement code displayed on the display 409 of the mobile terminal 50. This allows the POS terminal 20 to obtain cart identification information.

Step S813: After reading the settlement code, the POS terminal 20 requests the cloud server Sv to send cart information. Specifically, the POS terminal 20 transmits the transmission request information restored from the settlement code to the cloud server Sv.

Step S814: Upon receiving the transmission request information from the POS terminal 20, the cloud server Sv extracts the cart identification information from the transmission request information and identifies the cart information that includes the cart identification information.
Step S815: Once the cloud server Sv has identified the cart information, it transmits various information necessary for settlement, including cart identification information, registration information (information indicating registered product information and the subtotal amount), and language information, to the POS terminal 20. If the identified cart information contains reserved products, the cloud server Sv transmits registration information including information about the reserved products to the POS terminal 20.

Step S816: When the POS terminal 20 receives the registration information from the cloud server Sv, it performs a customer registration information confirmation process (see FIG. 24). If the registration information includes pending items, the registration information confirmation process involves calling a store clerk, who then confirms the pending items.

Step S817: The POS terminal 20 executes the settlement process. The settlement process includes accepting the selection of the payment type. The payment type may be pre-registered in the shopping app. If the payment type is cash, the POS terminal 20 accepts the insertion of cash, dispenses change, and issues a receipt during the settlement process. The POS terminal 20 then sends information indicating the settlement details and cart information to the cloud server Sv. The cloud server Sv then stores the transaction completion date and time (settlement date and time) in the cart information.

Step S818: The cloud server Sv transmits a transaction completion notification to the mobile terminal device 50 indicating that the transaction has been completed.
Step S819: When the mobile terminal device 50 receives the transaction completion notification, it deletes the products registered in the mobile terminal device 50 and terminates the shopping app. Note that when the mobile terminal device 50 generates and displays the settlement code in step S811, it may also delete the products registered in the mobile terminal device 50 and terminate the shopping app. In this way, the series of processes ends.

In the above-described process, in step S806, the cart identification information and product code are sent to the cloud server Sv each time a product is registered (scanned) by the mobile terminal device 50. However, this transmission does not have to be done each time a product is registered. For example, the mobile terminal device 50 may send this information all at once to the cloud server Sv when it receives an instruction to start checkout. This reduces the number of communications between the mobile terminal device 50 and the cloud server Sv.

(An example of the store entry process shown in step S802 of FIG. 8)
Next, an example of the store entry process shown in step S802 in Fig. 8 will be described using Fig. 9. Fig. 9 is a flowchart showing an example of the store entry process performed by the mobile terminal device 50. As shown in Fig. 9, the mobile terminal device 50 requests the GPS unit 411 to acquire location information of the current location (step S901). The mobile terminal device 50 then determines whether or not the location information of the current location has been acquired (step S902). If the location information of the current location has been acquired (step S902: YES), the mobile terminal device 50 requests the cloud server Sv to search for nearby stores (step S903).

Upon receiving the request, the cloud server Sv uses the current location of the mobile terminal device 50 and the store information in Figure 7 (B) to search for stores within a predetermined range (within 300 m) of the current location of the mobile terminal device 50, and transmits the search results to the mobile terminal device 50. The mobile terminal device 50 references the search results received from the cloud server Sv and determines whether there are any stores near the mobile terminal device 50 (step S904).

If there are no stores near the mobile terminal device 50 (step S904: NO), the mobile terminal device 50 returns to step S903, expands the search range, and requests a search for nearby stores again. If there are no stores near the mobile terminal device 50, the mobile terminal device 50 may be notified that there are no stores nearby. If there are stores near the mobile terminal device 50 (step S904: YES), the mobile terminal device 50 determines whether there is only one store nearby (step S905).

If there is one store nearby (step S905: YES), the mobile terminal device 50 proceeds to step S907. If there is more than one store nearby (step S905: NO), that is, if there are multiple stores nearby, the mobile terminal device 50 accepts the customer's selection of the store to shop at (step S906). The mobile terminal device 50 then completes identifying the store (step S907) and ends the series of processes. Once the store has been identified in step S907, the transaction begins as the first condition is met.

If location information about the current location is not acquired in step S902 (step S902: NO), specifically, for example, if the communication environment is poor and the GPS unit 411 cannot acquire location information, the mobile terminal device 50 requests reading of the store identification code presented at the store (step S908). Specifically, in step S908, the mobile terminal device 50 displays a message on the display 409 such as "Please scan the store identification code presented at the store."

The mobile terminal device 50 waits until it reads the store identification code (step S909: NO). Once it has read the store identification code (step S909: YES), it completes the identification of the store (step S910) and ends the series of processes. Once the store is identified in step S910, the transaction begins when the second condition is met.

(Example of a screen displayed on the display 409 of the mobile terminal device 50 when entering a store)
10A and 10B are explanatory diagrams showing examples of screens displayed on the display 409 of the mobile terminal device 50 when entering a store. Fig. 10A shows a store selection screen 1000 displayed on the display 409 of the mobile terminal device 50. The store selection screen 1000 includes a map area 1001 and a selection button 1002.

The map area 1001 shows two candidate stores (Store A and Store B) located near the mobile terminal device 50 on the map screen. The selection buttons 1002 include a Store A selection button 1002a that accepts the selection of Store A, and a Store B selection button 1002b that accepts the selection of Store B. When the customer presses either selection button 1002, the store to enter is confirmed. Note that if there is only one candidate store, that store is confirmed as the store to enter.

Figure 10 (B) shows an example of when the mobile terminal device 50 acquires store identification information. In Figure 10 (B), the monitor 1010 is, for example, digital signage installed in a store. A store identification code 1011 indicating the store identification information is displayed on the monitor 1010. When a customer launches a shopping app and has the mobile terminal device 50 read the store identification code 1011, the mobile terminal device 50 can identify the store from the store identification code 1011.

The two-dimensional code does not necessarily have to be displayed on the monitor 1010; it may also be printed and displayed on a printed material such as a poster. The printed material may be displayed near the entrance or exit of the store. Alternatively, information equivalent to store-specific information may be displayed and the customer may input it manually.

Note that the cloud server Sv can also identify the store, and this will be discussed in more detail. Figure 10(C) shows an example of the cloud server Sv identifying the store where the mobile terminal device 50 is located. In Figure 10(C), the imaging terminal 1020 is installed, for example, near the entrance of the store. A barcode 1021 indicating the identification information of the mobile terminal device 50 is displayed on the mobile terminal device 50. When a customer has the imaging terminal 1020 read the barcode 1021, the imaging terminal 1020 transmits to the cloud server Sv the store identification information as well as information indicating that the mobile terminal device 50 identified by the barcode 1021 is located within the store. The cloud server Sv transmits store identification information indicating the store where the mobile terminal device 50 is located to the mobile terminal device 50 identified by the barcode 1021. In this manner, the mobile terminal device 50 can also obtain the store identification information.

(Example (part 1) of the product registration process shown in step S806 of FIG. 8)
11 is a flowchart showing an example of product registration processing for a barcode product performed by the mobile terminal device 50. As shown in Fig. 11, the mobile terminal device 50 determines whether scanning of the barcode attached to the product has started (step S1101). The mobile terminal device 50 can determine whether scanning of the barcode has started using detection results from various sensors and image capture results from the camera 407.

The mobile terminal device 50 waits until scanning of the barcode begins (step S1101: NO). Once scanning of the barcode begins (step S1101: YES), it determines whether product identification information has been acquired from the barcode by scanning (step S1102). If product identification information cannot be acquired from the barcode (step S1102: NO), the mobile terminal device 50 determines whether a timeout has occurred (step S1103). If a timeout has not occurred (step S1103: NO), the mobile terminal device 50 returns to step S1102.

If a timeout has occurred (step S1103: YES), the mobile terminal device 50 notifies the user that the item is on hold (step S1104). This notification prompts the user to place the item in a separate reserved item bag rather than in the shopping cart, and notifies the user that the item will be registered by a store clerk at the time of checkout. The mobile terminal device 50 then registers the on-hold item information (unreadable item) (step S1105), and the process ends.

If product identification information can be obtained from the barcode in step S1102 (step S1102: YES), the mobile terminal device 50 determines whether the product is a NON file product (step S1106). If it is a NON file product (step S1106: YES), the mobile terminal device 50 proceeds to step S1104 and notifies the user that the product is on hold. If it is not a NON file product (step S1106: NO), the mobile terminal device 50 registers the product (step S1107).

The mobile terminal device 50 then determines whether the registration operation is invalid (step S1108). A registration operation is invalid if, for example, the number of registered products exceeds a certain number (for example, 50 or more). If the registration operation is not invalid (step S1108: NO), the mobile terminal device 50 ends the series of processes. If the registration operation is invalid (step S1108: YES), the mobile terminal device 50 stores product registration operation information indicating that the registration operation is invalid in memory 404 (step S1109), and ends the series of processes.

(Example of a screen displayed on the display 409 of the mobile terminal device 50 after the store entry process is completed)
FIG. 12 is an explanatory diagram showing an example of a screen displayed on the display 409 of the mobile terminal device 50 after the store entry process is completed. FIG. 12(a) shows a top screen 1200 displayed on the display 409 of the mobile terminal device 50. The top screen 1200 includes information presentation buttons 1201 (1201a to 1201c) and a registration start button 1202. The store information button 1201a is a button that accepts a command to start displaying store information such as a floor guide. The announcement button 1201b is a button that accepts a command to start displaying store information such as events. The bargain information button 1201c is a button that accepts a command to start displaying sale items such as advertising information. The registration start button 1202 is a button that accepts a command to start displaying an image on the display 409.

Figure 12(b) shows a registration screen 1210 for registering a product. The registration screen 1210 includes an imaging area 1211, a registered product display area 1212, a total amount display area 1213, and a checkout start button 1214. The imaging area 1211 is an area where the barcode attached to the product can be imaged (scanned) using the camera 407 function of the mobile terminal device 50. The registered product display area 1212 is an area where various registered products (product name, quantity, price, etc.) are displayed. The registered products are displayed in the order in which they were registered in the registered product display area 1212. Specifically, the most recently registered product is displayed at the top of the registered product display area 1212.

The total amount display area 1213 is an area where the total number of registered items and the total amount are displayed. The checkout start button 1214 is a button that completes the registration of items and accepts the start of checkout. When the checkout start button 1214 is pressed in Figure 12 (B), the screen shown in Figure 12 (C) appears.

Figure 12 (C) shows the checkout start acceptance screen 1220. The checkout start acceptance screen 1220 includes a guidance display 1221, a checkout code 1222, and a registration return button 1223. The guidance display 1221 displays guidance instructing the POS terminal 20 to read the checkout code 1222. The checkout code 1222 is, for example, coded information such as cart identification information from the mobile terminal 50 or information that causes the POS terminal 20 to send a cart information transmission request to the cloud server Sv. The registration return button 1223 is a button that accepts returning to the registration screen 1210 (Figure 12 (B)). When the customer has the customer-side scanner 206 of the POS terminal 20 read the checkout code 1222, checkout is started at the POS terminal 20.

(Example (part 2) of the product registration process shown in step S806 of FIG. 8)
13 is a flowchart showing an example of a product registration process for a product to be weighed performed by the mobile terminal device 50. As shown in FIG. 13, the mobile terminal device 50 determines whether or not the temporary registration code 1403 (see FIG. 14) for the product to be weighed has been scanned (step S1301). The temporary registration code 1403 for the product to be weighed is posted near the product to be weighed. The mobile terminal device 50 waits until the temporary registration code 1403 for the product to be weighed is scanned (step S1301: NO). When the temporary registration code 1403 for the product to be weighed is scanned (step S1301: YES), the mobile terminal device 50 provisionally registers the product to be weighed (step S1302). The provisionally registered product to be weighed is displayed on the display 409.

Then, the portable terminal device 50 determines whether it has scanned the connection code displayed on the display unit 306 of the weighing device 30 (step S1303). The portable terminal device 50 waits until it scans the connection code 1511 (see FIG. 15) (step S1303: NO). If it scans the connection code 1511 (step S1303: YES), the portable terminal device 50 requests a one-to-one communication connection to the weighing device 30 (step S1304).

Even if the connection code 1511 is scanned when the product to be weighed has not been provisionally registered, the mobile terminal device 50 will not send a connection request to the weighing device 30. This is because if the connection time between one mobile terminal device 50 and the weighing device 30 becomes too long, other customers will be unable to use the weighing device 30, so the purpose is to shorten the time that one mobile terminal device 50 occupies the weighing device 30.

When a connection request is received from the mobile terminal device 50, the weighing device 30 performs a pairing determination, including authentication of one-to-one communication and determining whether the provisionally registered product is a product to be weighed by the weighing device 30. If the pairing determination is successful, the weighing device 30 begins one-to-one communication with the mobile terminal device 50.

Next, the mobile terminal device 50 determines whether a communication connection with the weighing device 30 has been established (step S1305). If a communication connection with the weighing device 30 has been established (step S1305: YES), the mobile terminal device 50 obtains the weight value of the product placed on the platform 320 by the customer from the weighing device 30 (step S1306). After the weighing is complete, the weighing device 30 issues a label indicating the weighing result in response to the customer's operation and transmits the weighing result to the mobile terminal device 50. In other words, after the weighing on the weighing device 30 is complete, the mobile terminal device 50 obtains the weighing result from the weighing device 30 in response to the customer's operation of the weighing device 30.

When the mobile terminal device 50 acquires the weighing results, it displays the weighing results (step S1307). The mobile terminal device 50 then displays a registration update screen and officially registers the items to be weighed (step S1308). The mobile terminal device 50 then determines whether weighing (official registration) of all provisionally registered items to be weighed has been completed (step S1309). If weighing of all provisionally registered items to be weighed has been completed (step S1309: YES), the mobile terminal device 50 terminates communication with the weighing device 30 (step S1310) and ends the series of processes.

On the other hand, if weighing of all provisionally registered products to be weighed has not been completed (step S1309: NO), the mobile terminal device 50 returns to step S1306 and performs processing to officially register the other provisionally registered products to be weighed.

If a communication connection with the weighing device 30 is not established in step S1305 (step S1305: NO), the mobile terminal device 50 notifies the customer of a retry (step S1311). The mobile terminal device 50 then determines whether to terminate registration (step S1312). The mobile terminal device 50 determines to terminate registration when it receives a notification from the customer that registration should be terminated, or when a certain number of retries have been performed.

If registration is not to be terminated (step S1312: NO), that is, if the customer has requested continuation of registration or if a certain number of retries have not been performed, the mobile terminal device 50 returns to step S1304. On the other hand, if registration is to be terminated (step S1312: YES), the mobile terminal device 50 deletes the provisionally registered product to be weighed (step S1313) and terminates the series of processes.

In the above process, the timing at which the weighing results are sent to the portable terminal device 50 is the timing at which the label is issued, but this is not limited to this. For example, it may be the timing at which weighing of all products is completed on the weighing device 30. In this case, the timing at which the weighing results are displayed on the portable terminal device 50 may be the timing at which the weighing is completed.

(Procedure for registering products to be weighed)
Next, the procedure for registering a commodity to be weighed will be described with reference to FIGS.
14 is an explanatory diagram showing an example of a procedure for registering a commodity to be weighed. In FIG. 14, an example is described in which the camera 407 of the mobile terminal device 50 captures an image of the identification information of a commodity to be weighed that a customer wishes to purchase.

In the fruit section (sales floor) of the store, products to be weighed 1401 (1401a-1401c) and displays 1402 (1402a-1402c) are arranged. Products to be weighed 1401 include, for example, lemon product to be weighed 1401a, apple product to be weighed 1401b, and orange product to be weighed 1401c. Displays 1402a-1402 are arranged behind each of the products to be weighed 1401a-1401c. Note that the following explanation mainly uses lemon display 1402a as an example, but the same applies to the other displays 1402b and 1402c.

Display 1402a displays the word "lemon," the unit price, and a temporary registration code 1403. The unit price indicates the price per kg. The temporary registration code 1403 includes information identifying the product 1401a to be weighed (product identification information) and unit price information. The temporary registration code 1403 is read by the mobile terminal device 50.

Note that display 1402a can change the content of temporary registration code 1403 depending on the time. For example, this can be used to provide discounts during limited-time sales or to prevent fraudulent transactions such as using barcodes read in the past. Specifically, this fraud involves, for example, taking a photo of a barcode during a limited-time sales sale the previous day with a camera, and then having the barcode read the next day to register the product 1401 to be weighed at the unit price during the limited-time sales sale the previous day. Note that the content displayed on display 1402a may be printed on a print medium such as paper.

When the mobile terminal device 50 reads the provisional registration code 1403, it provisionally registers the product 1401 to be weighed. The display screen of the mobile terminal device 50 shown in FIG. 14 shows a provisional registration screen 1410. The provisional registration screen 1410 includes an image capture result 1411, a provisional registration field 1412, a main registration field 1413, and a total display field 1414. The image capture result 1411 shows, for example, an image when the provisional registration code 1403 for a lemon is read.

The provisional registration field 1412 displays products that have been provisionally registered by reading the provisional registration code 1403. In the illustration, the provisional registration field 1412 (1412a, 1412b) shows that lemons and apples have been provisionally registered. In other words, this shows that the provisional registration code 1403 for apples was read before the provisional registration code 1403 for lemons was read. The provisional registration field 1412 displays "Weighing Required," which indicates that weighing is required, and "?? Yen," which indicates that the price has not been determined because weighing has not been completed.

The final registration field 1413 displays the final registered product and price. The display format of the final registration field 1413 is different from that of the provisional registration field 1412. In the illustration, the provisional registration field 1412 is displayed in a shaded display format. This display format makes it easier for customers to recognize that provisional registration is in progress, and encourages them to weigh the product.

Figure 15 is an explanatory diagram showing an example of a standby screen displayed on the weighing device 30. In Figure 15, the display unit 306 of the weighing device 30 displays a standby screen 1500 that is displayed during standby mode. The standby screen 1500 includes a first information field 1510 and a second information field 1520.

The first information field 1510 shows information for registering a commodity to be weighed using the mobile terminal device 50. Specifically, the first information field 1510 displays a connection code 1511 and a message to have the mobile terminal device 50 read the connection code 1511.
The second guidance field 1520 displays guidance for registering the products to be weighed without using the mobile terminal device 50. Specifically, the second guidance field 1520 displays guidance urging the user to place the products to be weighed on a scale and weigh them. The following describes the case where the mobile terminal device 50 is used.

The customer has the mobile terminal device 50 read the temporary registration code 1403 for lemon and apple shown in Figure 14, and then read the connection code 1511 shown in Figure 15. After reading the connection code 1511, the mobile terminal device 50 requests a communication connection to the weighing device 30 based on the instructions indicated by the connection code 1511.

Figure 16 is an explanatory diagram showing an example of a screen displayed on the mobile terminal device 50 after the connection code has been read. Figure 16 (A) shows the standby screen when a connection request is made. As shown in Figure 16 (A), the display 409 of the mobile terminal device 50 displays a status display 1610 indicating that a communication connection with the weighing device 30 is being attempted. When pairing is complete, the screen changes to that shown in Figure 16 (B).

Figure 16 (B) shows the screen when a communication connection is established. As shown in Figure 16 (B), a guidance message 1620 prompting the user to place the product on the scale is displayed on the display 409 of the mobile terminal device 50. Note that, because the mobile terminal device 50 provisionally registered the apple before the lemon, the guidance message 1620 prompting the user to weigh the apple is displayed before the guidance message prompting the user to weigh the lemon.

Figure 17 is an explanatory diagram showing an example of the screen displayed on the weighing device 30 and the mobile terminal device 50 during weighing. Figure 17 (A) shows the operation guide screen 1700 of the weighing device 30 when no product has been placed on the platform 320. The operation guide screen 1700 includes a guide display S1, a product name display 1701, a back button 1702, a cancel button 1703, a search button 1704, a weighing result field 1705, a unit price field 1706, a total amount field 1707, and mobile terminal information 1730.

The guidance display S1 displays guidance encouraging the user to place the product on the platform 320. The product name display 1701 displays the product name of the product to be weighed. The back button 1702 is a button that accepts returning to the previous screen. The cancel button 1703 is a button that accepts canceling weighing. The search button 1704 is a button that accepts searching for nearby mobile terminal devices 50 in order to reconnect with the mobile terminal device 50, for example, if the communication connection with the mobile terminal device 50 is lost.

The weighing result field 1705 shows the weight of the product to be weighed that has been placed on the platform 320. Note that the weighing result field 1705 is not limited to displaying the weight; for example, for products whose approximate weight per unit is known, the number of units converted based on the weight may be displayed. The unit price field 1706 shows the unit price (e.g., the price per kilogram). The total amount field 1707 shows the total amount calculated using the weighing result and the unit price. The mobile terminal information 1730 shows the currently connected mobile terminal device 50 (owner). Specifically, the mobile terminal information 1730 shows text information such as "Connected with Mr./Ms. XX."

Figure 17 (B) shows the weighing completion screen 1710 of the weighing device 30 when weighing is complete. Compared to the operation guide screen 1700 of Figure 17 (A), the weighing completion screen 1710 differs in that it displays the contents of the weighing result field 1705, the contents of the total amount field 1707, a guide display S2, and a print button 1708. The weighing result field 1705 shows the weight of the product placed on the platform 320 (e.g., 1.2006 kg). The total amount field 1707 shows the amount calculated using the product weight and unit price (e.g., ¥432).

Guidance display S2 prompts the user to press the print button 1708. The print button 1708 is a button that accepts the printing of a label. The print button 1708 is only displayed once the product has been placed on the platform 320 and the weighing value has stabilized. When the print button 1708 is pressed on the weighing completion screen 1710, the screen shown in Figure 17 (C) is displayed.

Figure 17(C) shows a guide screen 1720 after a label has been issued. The guide screen 1720 prompts the user to affix a label to the bag containing the product to be weighed (apples). When issuing the label, the weighing device 30 transmits the apple weighing results (product identification information, weighing status, price, etc.) to the mobile terminal device 50 via short-range wireless communication. When the mobile terminal device 50 receives the apple weighing results, it displays the screen shown in Figure 17(D).

Figure 17 (D) shows the screen displayed on the mobile terminal device 50 when the official registration of the apples is complete. As shown in Figure 17 (D), the mobile terminal device 50 receives the weighing results of the apples from the weighing device 30, and as a result, the official registration field 1413a corresponding to the apples is displayed instead of the provisional registration field 1412b (see Figure 14) corresponding to the apples.

In addition, the words "Weighing Required" that were displayed in the provisional registration have been changed to "Weighing" in the official registration field 1413. This indicates that the weighing of the apples has been completed. Note that instead of the word "Weighing" in the official registration field 1413, the weighed weight (e.g., 0.5 kg) or the unit price (e.g., 1,000 yen/kg) may be displayed.

After a predetermined time (e.g., 3 seconds) has elapsed since the weighing device 30 displayed the screen shown in Figure 17(C), it will transition to a screen prompting the user to weigh the lemons. The screen transitions on the weighing device 30 and mobile terminal device 50 when weighing lemons are the same as when weighing apples, and therefore will not be described here. Once the official registration of all provisionally registered products to be weighed (apples and lemons) has been completed, the weighing device 30 will display the standby screen 1500 shown in Figure 15 after a predetermined time (e.g., 3 seconds) has elapsed.

(Example (part 1) of the notification process shown in step S808 of FIG. 8)
18 is a flowchart showing an example of a notification process based on location information performed by the mobile terminal device 50. As shown in FIG. 18, the mobile terminal device 50 determines whether the registered product is a weighing target product (step S1801). If the registered product is a weighing target product (step S1801: YES), it is clear that the customer is present in the store, and the mobile terminal device 50 ends the process without performing a location information acquisition determination or a presence determination.

On the other hand, if the registered product is not a weighing target product (step S1801: NO), i.e., if the registered product is a barcode product, the mobile terminal device 50 determines whether the transaction is based on the fulfillment of the first condition (the condition under which a store is identified using location information) (step S1802). If the transaction is not based on the fulfillment of the first condition (step S1802: NO), i.e., if the transaction is based on the fulfillment of the second condition (the condition under which a store is identified using store identification information), the mobile terminal device 50 simply ends the processing. This makes it possible to avoid issuing a notification based on a presence determination in transactions where the second condition is met, thereby reducing the frequency of error notifications.

On the other hand, if the transaction is due to the first condition being met (step S1802: YES), the mobile terminal device 50 (CPU 401) requests the GPS unit 411 to acquire location information of the current location (step S1803). The mobile terminal device 50 then performs a location information acquisition determination to determine whether location information of the current location has been acquired (step S1804). If the location information acquisition determination determines that location information of the current location has not been acquired (step S1804: NO), that is, if the communication environment is not good, for example, because the mobile terminal device 50 is underground, the mobile terminal device 50 ends the process without reporting an error. This makes it possible to prevent error notifications from being issued frequently when the communication environment is not good.

On the other hand, if the location information of the current location is acquired in the location information acquisition determination (step S1804: YES), the mobile terminal device 50 compares the location information of the current location with the location information of the store to perform a presence determination to determine whether the current location of the mobile terminal device 50 is out of service area (outside the store) (step S1805). If the presence determination determines that the current location of the mobile terminal device 50 is not out of service area (step S1805: NO), that is, if the current location of the mobile terminal device 50 is within service area (inside the store), the processing ends.

On the other hand, if the presence determination indicates that the current location of the mobile terminal device 50 is out of range (step S1805: YES), that is, if there is a risk that a customer (member) who came to the store to check prices or the like has moved outside the store and is performing registration operations, an error is reported indicating that the mobile terminal device 50 (the customer) is outside the store (step S1806).

Next, the mobile terminal device 50 determines whether to perform a retry (step S1807). Note that retries are performed automatically, or by receiving a retry instruction from the customer, if the number of retries is within a preset upper limit. If the number of retries exceeds the upper limit, the process may proceed to step S1808.

If a retry is to be performed (step S1807: YES), the mobile terminal device 50 returns to step S1803. If a retry is not to be performed (step S1807: NO), the mobile terminal device 50 restricts product registration (step S1808) and ends the series of processes. Note that restricting product registration means, for example, canceling the registered product and logging out. In this case, the store clerk may be able to cancel the error notification and further allow re-login and re-product registration. This can further deter improper product registration.

(Example of an error screen based on location information displayed on the mobile terminal device 50)
FIG. 19 is an explanatory diagram showing an example of an error screen based on location information displayed on the mobile terminal device 50. As shown in FIG. 19, an error screen 1900 is displayed on the display 409 of the mobile terminal device 50. The error screen 1900 indicates that the customer is outside the store and that product registration will be canceled (the registered product will be deleted). When the Confirm button 1901 on the error screen 1900 is pressed, the registered product is deleted and the user is logged out. On the other hand, when the Retry button 1902 on the error screen 1900 is pressed, location information is acquired again and a presence determination is performed again. If the second presence determination determines that the customer is in the store, the error screen 1900 is closed and the screen returns to a screen where product registration is possible.

(Example (part 2) of the notification process shown in step S808 in FIG. 8)
20 is a flowchart showing an example of a notification process based on product registration operation information performed by the mobile terminal device 50. As shown in FIG. 20, the mobile terminal device 50 (CPU 401) requests acquisition of product registration operation information stored in the memory 404 (step S2001). Then, the mobile terminal device 50 performs an operation determination to determine whether the product registration operation information stored in the memory 404 indicates an invalid registration operation (step S2002). If the product registration operation information does not indicate an invalid registration operation (step S2002: NO), the mobile terminal device 50 ends the series of processes.

On the other hand, if the product registration operation information indicates an inappropriate registration operation (step S2002: YES), that is, for example, if the number of registered products is a certain number or more (e.g., 50 or more), the mobile terminal device 50 notifies the user of an error indicating that an unnatural registration operation has been performed (step S2003). The mobile terminal device 50 then restricts product registration (step S2004) and ends the series of processes. Note that restricting product registration means, for example, canceling the registered products and logging out.

(Example of an error screen based on product registration operation information displayed on the mobile terminal device 50)
21 is an explanatory diagram showing an example of an error screen based on product registration operation information displayed on the mobile terminal device 50. As shown in FIG. 21, an error screen 2100 is displayed on the display 409 of the mobile terminal device 50. The error screen 2100 indicates that the registration operation is invalid and that the product registration will be canceled (the registered product will be deleted). When a confirmation button 2101 is pressed on the error screen 2100, the registered product is deleted and the user is logged out.

(Example of the registration information confirmation process shown in step S816 of FIG. 8)
Figure 22 is a flowchart showing an example of registration information confirmation processing performed by the POS terminal 20. The flowchart shown in Figure 22 is premised on the POS terminal 20 reading the settlement code displayed on the mobile terminal 50 and requesting the cloud server Sv to send the registration information. Then, as shown in Figure 22, the POS terminal 20 determines whether cart information for the mobile terminal 50 has been received from the cloud server Sv (step S2201).

The POS terminal 20 waits until it receives cart information (step S2201: NO). Upon receiving the cart information (step S2201: YES), the POS terminal 20 displays a list of the cart information (registered product information and reserved product information) on the customer display unit 205 (step S2202). The POS terminal 20 then determines whether the cart information includes reserved product information (step S2203).

If the cart information does not include pending product information (step S2203: NO), the POS terminal 20 proceeds to step S2210. If the cart information includes pending product information (step S2203: YES), the POS terminal 20 performs a checkout prohibition process (step S2204). The checkout prohibition process, for example, disables operation of the customer display unit 205.

The POS terminal 20 then performs a store clerk call process (step S2205). This process involves displaying on the customer-side display unit 205 a message indicating that a store clerk is being called, lighting up the sign pole 220 in a predetermined lighting mode, and causing the transaction status management device 11 to display a message directing a store clerk to the target POS terminal 20.

Next, the POS terminal 20 determines whether the clerk has logged in (step S2206). To log in, the clerk may, for example, have the clerk scanner unit 212 read the clerk code on the clerk's name tag, or manually input the clerk code into the clerk display unit 210 or key operation unit 211.

The POS terminal 20 waits until a store clerk logs in (step S2206: NO). When the store clerk logs in (step S2206: YES), the POS terminal 20 performs a process (reserved item confirmation process) to check and register or delete each reserved item (step S2207). The POS terminal 20 continues the reserved item confirmation process until there are no reserved items left (step S2208: NO). When there are no reserved items left (step S2208: YES), the POS terminal 20 cancels the checkout prohibition process (step S2209). The POS terminal 20 then displays a checkout start screen (step S2210) and ends the process.

(Example of screen transitions displayed on the customer display unit 205 of the POS terminal device 20 during payment)
23A and 23B are explanatory diagrams showing an example of screen transitions during payment displayed on the customer display unit 205 of the POS terminal 20. FIG. 23A shows a guide screen 2310. The guide screen 2310 prompts the customer scanner unit 206 to read the payment code 1222 (see FIG. 12C). For example, the POS terminal 20 displays the guide screen 2310 while in standby mode for transaction-only mode. When the customer has the customer scanner unit 206 read the payment code 1222 displayed on the mobile terminal 50 on the guide screen 2310 shown in FIG. 23A, the screen transitions to a list display screen 2320 shown in FIG. 23B or a store clerk calling screen 2330 shown in FIG. 23C.

The list display screen 2320 shown in FIG. 23 (B) includes a registered product display area 2321, a call store clerk button 2322, and a start checkout button 2323. The registered product display area 2321 displays the product name, number of items purchased, and purchase price for each registered product, as well as the total number of items and total price for the various registered products. The registered product display area 2321 is displayed, for example, in the order of registration.

The call clerk button 2322 is a button that allows a customer to call a clerk. When a customer checks the registered product display area 2321 and finds that the registered product differs from the product they wish to purchase, the registered product must be corrected. This correction requires the action of a clerk. For example, suppose a customer checks the registered product display area 2321 and realizes that only one item of "XX meat sauce" has been registered, even though they intended to register three items. In this case, the customer presses the call clerk button 2322 to call a clerk. When the call clerk button 2322 is pressed, the screen transitions to the clerk calling screen 2330 shown in FIG. 23 (C).

The store clerk calling screen 2330 shown in Figure 23 (C) indicates that a store clerk is being called. When the confirmation button 2331 is pressed on the store clerk calling screen 2330, the screen transitions to a registered product list display screen (not shown). Note that this list display screen cannot accept the start of payment because the store clerk is being called. Once the store clerk has been called and logged in, the screen transitions to the pending product confirmation screen 2340 shown in Figure 23 (D).

On the reserved item confirmation screen 2340, the store clerk registers or deletes items while confirming with the customer each item. When there are no more reserved items, the screen transitions to the list display screen 2320 shown in Figure 23 (B).

The Start Checkout button 2323 is a button that accepts the start of the checkout process from the customer. The customer checks the registered product display area 2321, and if there is no difference between the registered product and the product they wish to purchase, the customer presses the Start Checkout button 2323. When the Start Checkout button 2323 is pressed, the POS terminal 20 can carry out the checkout process. During the checkout process, the POS terminal 20 accepts the selection of the payment type, accepts the insertion of cash or a card, and issues a receipt when the checkout is complete.

As described above, the mobile terminal device 50 according to this embodiment is configured to notify users of errors based on the transaction start conditions. This allows the frequency of error notifications to differ between transactions resulting from the fulfillment of the first condition and transactions resulting from the fulfillment of the second condition, thereby reducing the frequency of errors depending on the start conditions. Therefore, according to this embodiment, it is possible to prevent shopping from being interrupted by error notifications, allowing for smoother shopping.

Furthermore, in this embodiment, the mobile terminal device 50 issues an error notification based on an existence determination in a transaction where the first condition is met, but does not issue an error notification based on an existence determination in a transaction where the second condition is met. Therefore, the frequency of error notifications can be reduced in transactions where the second condition is met.

In addition, in this embodiment, the mobile terminal device 50 does not issue an error notification during a transaction based on the first condition, regardless of whether location information is acquired in the location information acquisition determination. This prevents frequent error notifications from occurring when the communication environment is poor.

In addition, in this embodiment, the validity determination includes an operation determination as to whether or not operations related to product registration are being performed validly. This makes it possible to notify an error if an invalid registration operation, such as a price check, is being performed. This makes it possible to prevent invalid product registrations, such as price checks. This makes it possible to prevent various store information, such as price information, from being easily leaked.

In addition, in this embodiment, the mobile terminal device 50 does not issue an error notification when a product to be weighed is registered, regardless of the start conditions. This makes it possible to avoid issuing an error notification when it is clear that a customer is present in the store.

Furthermore, in this embodiment, if the mobile terminal device 50 is unable to acquire location information at the start of a transaction, it requests the acquisition of store-specific information, and begins product registration once store-specific information is acquired in response to the acquisition request. This allows the user to be prompted to acquire store-specific information and begin product registration even when location information cannot be acquired.

(Modification of the embodiment)
Modifications 1 to 11 of the embodiment will be described below. Note that in each of the following modifications, the content described in the above embodiment will be omitted as appropriate. It is also possible to have a configuration in which the configurations shown in the above embodiment and modifications 1 to 11 are combined. Specifically, a configuration may be used that includes all of the above embodiment and modifications 1 to 11, or a configuration may be used that combines one of the above embodiment and modifications 1 to 11.

(Variation 1)
First, a first modification of the embodiment will be described. In the above-described embodiment, a configuration in which store identification information is not acquired during shopping has been described (see FIG. 18). In place of or in addition to this configuration, a first modification will be described in which store identification information is acquired during shopping.

In variant 1, the request unit (first request means) requests acquisition of store identification information in response to a determination result that location information is not acquired in the location information acquisition determination. The request unit requests acquisition of store identification information at a predetermined timing. The predetermined timing is, for example, when a predetermined period (e.g., 15 minutes) has passed since location information of the current location was not acquired. In other words, the request unit requests acquisition of store identification information when, for example, the customer is underground for a predetermined period or longer. The predetermined timing is not limited to this, and may also be when the number of times product registration has been performed without location information of the current location being acquired reaches a predetermined number or more. In response to the request for acquisition of store identification information by the request unit, the customer causes the mobile terminal device 50 to read the store identification code.

In addition, in areas of a store where the communication environment is poor, two-dimensional codes indicating store identification information can be placed appropriately. This allows the mobile terminal device 50 to read the two-dimensional code even when the customer is in a basement, for example. In other words, the store identification information acquisition unit can acquire store identification information.

Here, the validity determination includes a store-specific information acquisition determination. The store-specific information acquisition determination is a determination of whether store-specific information has been acquired during the transaction. If store-specific information has been acquired, it is clear that the customer is present in the store identified by the store-specific information. In the store-specific information acquisition determination, the determination unit determines that the transaction is valid if store-specific information has been acquired, and on the other hand, determines that the transaction is invalid if store-specific information has not been acquired even after a certain period of time has passed. The notification unit does not notify an error if a valid determination result is obtained in the store-specific information acquisition determination, and notifies an error if an invalid determination result is obtained.

(Modification 1 of the notification process shown in step S808 in FIG. 8)
24 is a flowchart illustrating a first variation of the location information-based notification process performed by the mobile terminal device 50. As shown in FIG. 24, the mobile terminal device 50 determines whether a predetermined time has come, during which a predetermined period of time has elapsed since the mobile terminal device 50 was underground, for example, and location information about the current location has not been acquired (step S2401). The mobile terminal device 50 waits until the predetermined time has come (step S2401: NO). When the predetermined time has come (step S2401: YES), the mobile terminal device 50 determines whether the product to be weighed has been registered (step S2402).

If the product to be weighed is registered (step S2402: YES), it is clear that the customer is present in the store, so the mobile terminal device 50 ends the process without performing location information acquisition or presence determination.

On the other hand, if the product to be weighed is not registered (step S2402: NO), the mobile terminal device 50 (CPU 401) requests the GPS unit 411 to acquire location information of the current location (step S2403). The mobile terminal device 50 then determines whether or not the location information of the current location has been acquired (step S2404).

If the location information of the current location has been acquired (step S2404: YES), the mobile terminal device 50 compares the location information of the current location with the location information of the store to perform a presence determination to determine whether the current location of the mobile terminal device 50 is out of service area (outside the store) (step S2405). If the presence determination determines that the current location of the mobile terminal device 50 is not out of service area (step S2405: NO), that is, if the current location of the mobile terminal device 50 is within service area (inside the store), the processing ends.

On the other hand, if the presence determination indicates that the current location of the mobile terminal device 50 is out of range (step S2405: YES), that is, if the registration operation is likely to be performed by a customer (member) who has visited the store to check prices, etc., an error is reported indicating that the mobile terminal device 50 (the customer) is outside the store (step S2406). The mobile terminal device 50 then restricts product registration (step S2407), and the series of processes ends.

Furthermore, if the location information acquisition determination in step S2404 does not acquire the location information of the current location (step S2404: NO), that is, if the communication environment is still poor, for example, when the mobile terminal device 50 is underground, the mobile terminal device 50 determines whether to perform a retry (step S2408). Note that retries are performed automatically, for example, if the number of retries is within a preset upper limit, or by receiving an operation from the customer to perform a retry. If the number of retries exceeds the upper limit, the process may proceed to step S2409.

If a retry is to be performed (step S2408: YES), the mobile terminal device 50 returns to step S2403. If a retry is not to be performed (step S2408: NO), the mobile terminal device 50 requests acquisition of store identification information for the store (step S2409). The mobile terminal device 50 then determines whether store identification information for the store has been acquired (step S2410). If store identification information for the store has been acquired (step S2410: YES), the mobile terminal device 50 ends the series of processes. On the other hand, if store identification information for the store has not been acquired even after a certain period of time has passed (step S2410: NO), the mobile terminal device 50 proceeds to step S2406 and reports an error. Note that the mobile terminal device 50 also reports an error if the acquired store identification information is not the store identification information for the store.

As described above, in variant 1, the mobile terminal device 50 requests acquisition of store identification information when location information is not acquired, and determines whether store identification information has been acquired. This allows customers to clearly indicate their presence in the store by having the mobile terminal device 50 read the store identification information (two-dimensional code), even if they are located in an area with a poor communication environment. This makes it possible to prevent unauthorized customers from registering products for price checks, etc.

(Variation 2)
Next, a second modification of the embodiment will be described. In the first modification, a configuration was described in which a notification based on the determination of acquisition of store-specific information is made regardless of the transaction start condition. In place of or in addition to this configuration, a second modification will be described in which a notification based on the determination of acquisition of store-specific information is not made for a transaction in which a second condition is met.

In variant 2, the request unit (first request means) requests acquisition of store-specific information when location information cannot be acquired in a transaction where the first condition is met, for example, when the communication environment is not good. On the other hand, the request unit does not request acquisition of store-specific information in a transaction where the second condition is met.

(Modification 2 of the notification process shown in step S808 in FIG. 8)
Fig. 25 is a flowchart showing a second modification of the notification process based on location information performed by the mobile terminal device 50. The flowchart shown in Fig. 25 differs from the flowchart shown in Fig. 24 in step S2501. Therefore, only step S2501 will be described below.

As shown in FIG. 25, if the mobile terminal device 50 determines in step S2402 that the product to be weighed is not registered (step S2402: NO), it determines whether the transaction is due to the first condition being met (the condition that the store is identified using location information) (step S2501). If the transaction is not due to the first condition being met (step S2501: NO), that is, if the transaction is due to the second condition being met (the condition that the store is identified using store identification information), the mobile terminal device 50 simply ends the processing. This prevents a notification based on a presence determination from being made in a transaction due to the second condition being met, thereby reducing the frequency of error notifications.

On the other hand, if the transaction is due to the first condition being met (step S2501: YES), the mobile terminal device 50 (CPU 401) proceeds to step S2403 and requests the GPS unit 411 to obtain location information of the current location (step S2403).

As described above, in Variation 2, the mobile terminal device 50 does not issue notifications based on the location information acquisition determination, presence determination, and store-specific information acquisition determination for transactions where the second condition is met. This reduces the frequency of error notifications for transactions where the second condition is met.

(Variation 3)
Next, a third modification of the embodiment will be described. In the second modification, a configuration was described in which a notification based on the determination of whether store-specific information was acquired is not performed in a transaction in which the second condition is met. In place of or in addition to this configuration, a third modification will be described in which a notification based on the determination of whether store-specific information was acquired is not performed in a transaction in which the first condition is met.

In variant 3, the request unit (second request means) requests acquisition of store-specific information in a transaction where the second condition is met by acquiring store-specific information, when a predetermined time has elapsed since the start of product registration. The predetermined time is, for example, 15 minutes. The request unit requests acquisition of store-specific information every time the predetermined time has elapsed between the start of the transaction and the start of settlement. On the other hand, the request unit (second request means) does not request acquisition of store-specific information in a transaction where the first condition is met by acquiring location information.

In addition, two-dimensional codes indicating store identification information may be placed throughout the store. This allows the mobile terminal device 50 to read the two-dimensional code wherever the customer is in the store. In other words, the store identification information acquisition unit can acquire the store identification information. The identification information determination is performed using the store identification information acquired in response to an acquisition request by the request unit.

Here, in a transaction where the first condition is met, the mobile terminal device 50 can periodically acquire location information and perform a presence determination. Therefore, the determination unit does not perform a store-specific information acquisition determination in a transaction where the first condition is met. Therefore, the notification unit does not notify of an error based on the store-specific information acquisition determination in a transaction where the first condition is met.

On the other hand, for transactions where the second condition is met, periodic location confirmation is not possible. Therefore, the determination unit determines whether store-specific information has been acquired for transactions where the second condition is met. Then, the notification unit notifies of an error based on the determination that store-specific information has been acquired for transactions where the second condition is met.

(Modification 3 of the notification process shown in step S808 in FIG. 8)
26 is a flowchart showing a third variation of the notification process based on store-specific information performed by the mobile terminal device 50. As shown in FIG. 26, the mobile terminal device 50 determines whether a predetermined time (e.g., 20 minutes) has elapsed (step S2601). The mobile terminal device 50 waits until the predetermined time has elapsed (step S2601: NO). After the predetermined time has elapsed (step S2601: YES), the mobile terminal device 50 determines whether the product to be weighed has been registered (step S2602).

If the product to be weighed is registered (step S2602: YES), it is clear that the customer is present in the store, so the mobile terminal device 50 ends the process without determining whether location information has been acquired.

On the other hand, if the product to be weighed is not registered (step S2602: NO), the mobile terminal device 50 determines whether the transaction is due to the first condition (a condition in which the store is identified using location information) being met (step S2603). If the transaction is due to the first condition being met (step S2603: YES), the mobile terminal device 50 ends the process without determining whether location information has been acquired.

On the other hand, if the transaction is not due to the first condition being met (step S2603: NO), that is, if the transaction is due to the second condition being met (a condition under which the store is identified using store identification information), the mobile terminal device 50 requests acquisition of store identification information for the store (step S2604). The mobile terminal device 50 then determines whether store identification information for the store has been acquired (step S2605). If store identification information for the store has been acquired (step S2605: YES), the mobile terminal device 50 ends the series of processes.

On the other hand, if the store identification information for the store is not acquired after a certain period of time has elapsed (step S2605: NO), the mobile terminal device 50 notifies an error (step S2606). Then, the mobile terminal device 50 restricts product registration (step S2607) and ends the series of processes.

As described above, in Variation 3, in a transaction where the second condition is met, the mobile terminal device 50 requests acquisition of store identification information when a predetermined time has elapsed since the start of product registration, and determines whether store identification information has been acquired using the store identification information acquired in response to the acquisition request. As a result, in a transaction where the second condition is met, the mobile terminal device 50 can read the store identification information (two-dimensional code) to reveal that the customer is in the store. This can therefore prevent unfair customer product registrations that involve price checks, etc.

Furthermore, in transactions where the first condition is met, the mobile terminal device 50 can periodically acquire location information and perform presence determination, so it is possible to avoid issuing error notifications based on the store-specific information acquisition determination. This reduces the frequency of error notifications in transactions where the first condition is met.

(Variation 4)
Next, a fourth modification of the embodiment will be described. In the third modification, a configuration in which the store identification information is not updated has been described. In place of or in addition to this configuration, the fourth modification will describe a configuration in which updated store identification information and non-updated store identification information can be used.

In variant 4, the store identification information includes updated store identification information (hereinafter referred to as "one-time password") that is updated at a predetermined timing, and non-updated store identification information that is not updated. The one-time password is displayed, for example, on a monitor. The predetermined timing is, for example, every 30 minutes. The one-time password is, for example, set with an expiration date, so that an expired one cannot identify the store. The monitor is placed near the entrance/exit of the store. The non-updated store identification information is, for example, printed on paper and posted. The one-time password and the non-updated store identification information are each presented at different stores, but may also be presented at the same store.

Here, the fact that the one-time password is read means that there is a high degree of confidence that the customer is present at the store. Therefore, the notification unit will not notify of an error based on the store-specific information acquisition determination in a transaction where the second condition is met and a one-time password is acquired.

On the other hand, by capturing and saving non-updated store-specific information with a camera, it is possible to read the old information outside the store. Therefore, when non-updated store-specific information is read, it means that there is less credibility that the customer is in the store than when updated store-specific information is obtained. Therefore, the notification unit issues an error notification based on the store-specific information acquisition determination in a transaction where the second condition is met and non-updated store-specific information is obtained.

In addition, in variant example 4, the request unit (second request means) requests acquisition of non-store-specific information in a transaction in which the second condition is met by acquiring non-updated store-specific information, when a predetermined time has passed since the start of product registration. The store-specific information that is the subject of the acquisition request is not limited to non-updated store-specific information, and may also be a one-time password. In other words, in a store where both a one-time password and non-updated store-specific information are presented, the request unit may request acquisition of a one-time password.

In addition, store identification codes (two-dimensional codes) indicating non-store identification information may be placed throughout the store. This allows the mobile terminal device 50 to read the store identification code wherever the customer is in the store. In other words, the store identification information acquisition unit can acquire non-store identification information. The identification information determination is performed using the non-store identification information acquired in response to an acquisition request by the request unit.

In addition, in Variation 4, for transactions where the first condition is met, a notification may be issued based on the store-specific information acquisition determination (as in Variation 2), or may not be issued (as in Variation 3).

(Fourth variation of the notification process shown in step S808 in FIG. 8)
FIG. 27 is a flowchart showing a fourth variation of the notification process based on location information performed by the mobile terminal device 50. The flowchart shown in FIG. 27 differs from the flowchart shown in FIG. 26 in step S2701. Therefore, only step S2701 will be described below. As shown in FIG. 27 , if the mobile terminal device 50 determines in step S2603 that the transaction is not based on the fulfillment of the first condition (step S2603: NO), that is, if the transaction is based on the fulfillment of the second condition (the condition that the store is identified using store identification information), the mobile terminal device 50 determines whether the transaction is based on the fulfillment of the second condition by obtaining a one-time password (step S2701).

If the transaction is one in which the second condition is met by obtaining a one-time password (step S2701: YES), the mobile terminal device 50 simply ends processing. This prevents notifications based on the store-specific information acquisition determination from being issued for transactions in which the second condition is met by obtaining a one-time password, thereby reducing the frequency of error notifications.

On the other hand, if the transaction does not satisfy the second condition by obtaining a one-time password (step S2701: NO), that is, if the transaction satisfies the second condition by obtaining non-updated store-specific information, the mobile terminal device 50 proceeds to step S2604 and makes a request to obtain store-specific information for the store.

As described above, in variant 4, the mobile terminal device 50 does not issue an error notification based on the store-specific information acquisition determination in a transaction where the second condition is met and a one-time password is acquired. Therefore, if it is expected that the customer is likely to be in the store, an error notification based on the store-specific information acquisition determination is not issued, thereby reducing the frequency of errors.

Furthermore, in variant 4, in transactions where the second condition is met and non-updated store-specific information is acquired, an error is reported based on the store-specific information acquisition determination. This makes it possible to report an error when it is deemed unlikely that the customer will be in the store, thereby preventing improper product registrations such as price checks.

(Variation 5)
Next, a fifth modification of the embodiment will be described. In the above-described embodiment, a configuration has been described in which a notification based on an operation determination is made regardless of the start condition of the transaction. In place of or in addition to this configuration, a fifth modification will be described in which a notification based on an operation determination is not made in a transaction in which a second condition is met.

In variant 5, in a transaction where the first condition is met, the notification unit issues a notification based on the operation determination. On the other hand, in a transaction where the second condition is met, the notification unit does not issue a notification based on the operation determination.

(Fifth Modification of the Notification Process Shown in Step S808 of FIG. 8)
Fig. 28 is a flowchart showing a fifth modified example of the notification process based on product registration operation information performed by the mobile terminal device 50. The flowchart shown in Fig. 28 differs from the flowchart shown in Fig. 20 in step S2801. Therefore, only step S2801 will be described below.

As shown in FIG. 28, the mobile terminal device 50 determines whether the transaction is due to the fulfillment of the first condition (the condition under which a store is identified using location information) (step S2801). If the transaction is not due to the fulfillment of the first condition (step S2801: NO), that is, if the transaction is due to the fulfillment of the second condition (the condition under which a store is identified using store identification information), the mobile terminal device 50 terminates the series of processes without performing an operation determination. On the other hand, if the transaction is due to the fulfillment of the first condition in step S2801 (step S2801: YES), the mobile terminal device 50 (CPU 401) proceeds to step S2001 and requests acquisition of product registration operation information stored in memory 404.

As described above, in variant 5, the mobile terminal device 50 does not notify of errors based on operation determinations in transactions where the second condition is met. This reduces the frequency of error notifications in transactions where the second condition is met.

(Variation 6)
Next, a sixth modification of the embodiment will be described. In the fifth modification described above, a configuration was described in which a notification based on an operation determination is not made in a transaction in which the second condition is met. In place of or in addition to this configuration, a sixth modification will be described in which a notification based on an operation determination is not made in a transaction in which the first condition is met.

In variant 6, in a transaction where the first condition is met, the notification unit does not issue a notification based on the operation determination. On the other hand, in a transaction where the second condition is met, the notification unit issues a notification based on the operation determination.

(Variation 6 of the notification process shown in step S808 in FIG. 8)
Fig. 29 is a flowchart showing a sixth modification of the notification process based on product registration operation information performed by the mobile terminal device 50. The flowchart shown in Fig. 29 differs from the flowchart shown in Fig. 20 in step S2901. Therefore, only step S2901 will be described below.

As shown in FIG. 29, the mobile terminal device 50 determines whether the transaction is due to the fulfillment of the second condition (the condition under which a store is identified using store identification information) (step S2901). If the transaction is not due to the fulfillment of the second condition (step S2901: NO), that is, if the transaction is due to the fulfillment of the first condition (the condition under which a store is identified using location information), the mobile terminal device 50 ends the series of processes without performing an operation determination. On the other hand, if the transaction is due to the fulfillment of the first condition in step S2901 (step S2901: YES), the mobile terminal device 50 (CPU 401) proceeds to step S2001 and requests acquisition of product registration operation information stored in memory 404.

As described above, in variant 6, the mobile terminal device 50 does not notify of errors based on operation determinations in transactions where the first condition is met. This reduces the frequency of error notifications in transactions where the first condition is met.

(Variation 7)
Next, a seventh modification of the embodiment will be described. In the sixth modification, a configuration was described in which a notification based on an operation determination is made in a transaction in which the second condition is met. In place of or in addition to this configuration, in the seventh modification, a configuration will be described in which a notification based on an operation determination is not made in a transaction in which the second condition is met but a one-time password is obtained.

If a one-time password is obtained, there is a low possibility that improper product registration, such as price checks, will occur outside the store. For this reason, in variant 7, the notification unit does not notify of an error based on the operation judgment in a transaction where the second condition is met and a one-time password is obtained.

On the other hand, in the case of non-updated store-specific information, by capturing an image with a camera and saving it, it is possible to read past information outside the store. For this reason, when non-updated store-specific information is acquired, there is a higher possibility of improper product registration, such as price checks, being carried out outside the store than when a one-time password is acquired. For this reason, the notification unit is configured to notify of an error based on an operation determination in a transaction where the second condition is met and non-updated store-specific information is acquired.

In addition, in Variation 7, in a transaction where the first condition is met, a notification based on the operation determination may be made (as in Variation 5), or may not be made (as in Variation 6).

(Seventh variation of the notification process shown in step S808 in FIG. 8)
Fig. 30 is a flowchart showing a seventh modified example of the notification process based on product registration operation information performed by the mobile terminal device 50. The flowchart shown in Fig. 30 differs from the flowchart shown in Fig. 29 in step S3001. Therefore, only step S3001 will be described below.

As shown in FIG. 30, if the mobile terminal device 50 determines in step S2901 that the transaction is due to the second condition being met (step S2901: YES), it determines whether the transaction is due to the acquisition of a one-time password (step S3001).

If the transaction is a transaction in which a one-time password is obtained (step S3001: YES), the mobile terminal device 50 simply ends processing. This prevents notifications based on operation determination from being issued for transactions in which the second condition is met by obtaining a one-time password, thereby reducing the frequency of error notifications.

On the other hand, if the transaction does not satisfy the second condition by obtaining a one-time password (step S3001: NO), that is, if the transaction satisfies the second condition by obtaining non-updated store-specific information, the mobile terminal device 50 (CPU 401) proceeds to step S2001 and requests the acquisition of product registration operation information stored in memory 404.

As described above, in variant 7, the mobile terminal device 50 does not issue an error notification based on the operation judgment in a transaction where the second condition is met and a one-time password is obtained. Therefore, if it is deemed unlikely that improper product registration, such as a price check, will occur outside the store, an error notification is not issued, thereby reducing the frequency of errors.

Furthermore, in variant 7, in transactions where the second condition is met and non-updated store-specific information is acquired, an error based on the operation determination is notified. This makes it possible to notify an error when it is deemed highly likely that improper product registration, such as price checks, will occur outside the store, thereby preventing improper product registration, such as price checks.

(Variation 8)
Next, an eighth modification of the embodiment will be described. In the above-described embodiment, an error is not notified when location information cannot be acquired (see FIG. 18 ). Instead of or in addition to this configuration, in the eighth modification, an error is notified when the GPS function is turned off.

The following description will be given with reference to FIG. 18. In Variation 8, if location information cannot be acquired in step S1804 of FIG. 18, the mobile terminal device 50 determines whether the GPS function is OFF. If the GPS function is ON, the processing ends without performing a presence determination. On the other hand, if the GPS function is OFF, a notification is issued to turn the GPS function ON. The mobile terminal device 50 may not terminate the processing shown in FIG. 18 until the GPS function is ON. If the GPS function does not turn ON after a certain period of time has passed, an error may be issued to indicate that the mobile terminal device 50 (the customer) is outside the store, or product registration may be restricted.

Variant 8 prevents customers from intentionally turning off the GPS function and performing improper product registrations, such as price checks.

(Variation 9)
Next, a ninth modification of the embodiment will be described. In the above-described embodiment, an error based on location information is not notified when a product to be weighed is registered (see FIG. 18 ). Instead of or in addition to this configuration, in the ninth modification, an error based on location information may be notified regardless of whether a product to be weighed is registered.

Specifically, in the location information-based notification process according to Variation 9 (see FIG. 18), location information acquisition determination and presence determination are performed regardless of whether or not a product to be weighed is registered. Specifically, the mobile terminal device 50 can avoid performing the process of step S1801 in FIG. 18. This allows location information acquisition determination, presence determination, and store-specific information acquisition determination to be performed even if a product to be weighed is registered. This makes it possible to notify an error according to the result of each determination.

(Variation 10)
Next, a tenth variation of the embodiment will be described. In the above-described embodiment, an error based on the registration operation information is notified regardless of whether the weighing target product is registered (see FIG. 20). Alternatively or in addition to this configuration, in the tenth variation, if the weighing target product is registered, an error based on the registration operation information may not be notified.

Specifically, in variant 10, the mobile terminal device 50 determines whether the product to be weighed is registered before processing step S2001 in FIG. 20, and if the product to be weighed is registered, it simply ends the processing. As a result, if the product to be weighed is registered, there is a low risk of an inappropriate product being registered, so it is possible to avoid reporting an error based on the operation determination. This reduces the frequency of errors.

(Modification 11)
Next, an eleventh modification of the embodiment will be described. In the above-described embodiment, an error based on a validity determination is not notified when a commodity to be weighed is registered. Instead of or in addition to this configuration, in the eleventh modification, an error based on a validity determination may not be notified simply when there is a connection history with the weighing device 30, even if a commodity to be weighed is not registered.

In this way, if there is a connection history with the weighing device 30, it is clear that the product to be weighed is present in the store even if it is not registered. This makes it possible to prevent errors based on validity judgments from being reported. Even in this way, the frequency of errors can be reduced.

The following is a summary of the embodiments.
[Title of invention] Terminal device, product sales data processing system, notification method, and program [Technical field]
The present invention relates to a terminal device, a product sales data processing system, a notification method, and a program.
[Background technology]
In recent years, a system has become known in which a shopping application is installed on a mobile terminal device such as a smartphone carried by a customer, and the customer can register products by themselves in a store (see, for example, Patent Document 1). The mobile terminal periodically checks its own location, and if it is not located within the store, it reports an error.
[Prior art documents]
[Patent Documents]
[Patent Document 1] JP-A No. 2013-541107 [Summary of the Invention]
[Problem to be solved by the invention]
However, in the conventional technology, if an error is frequently reported, it may be difficult for a customer to shop smoothly. For example, in an environment where it is difficult to obtain location information, such as when a store is located underground, the mobile terminal device may determine that it is not located within the store and may frequently report an error. The present invention has been made in consideration of such circumstances, and its purpose is to provide a technology that allows a customer to shop smoothly.
[Means for solving the problems]

(1) In order to solve the above-mentioned problems, a terminal device that is one aspect of the present invention comprises: location information acquisition means for acquiring location information indicating a current location; store identification information acquisition means for acquiring store identification information presented in a store; registration means for starting product registration in response to the establishment of one of a first condition for identifying the store using the location information and a second condition for identifying the store using the store identification information; determination means for determining whether the product registration is being carried out legitimately; and notification means for notifying of an error using the determination result of the determination means, wherein the notification means issues the notification based on the start condition that has been established.
According to the above configuration, the frequency of error notifications can be made different for transactions resulting from the fulfillment of the first condition and transactions resulting from the fulfillment of the second condition, thereby reducing the frequency of errors depending on the start condition. Therefore, according to this embodiment, it is possible to prevent shopping from being interrupted by error notifications, allowing shopping to be carried out smoothly.

(2) In the configuration of (1) above, the legitimacy determination may include a presence determination of whether or not the person is present in the store using the location information obtained during the transaction, and the notification means may issue the notification based on the presence determination in a transaction where the first condition is met, and may not issue the notification based on the presence determination in a transaction where the second condition is met.
According to the above configuration, in a transaction in which the second condition is satisfied, it is possible to prevent a notification based on the presence determination, thereby reducing the frequency of error notifications in a transaction in which the second condition is satisfied.

(3) In the configuration of (1) or (2) above, the legitimacy determination may include a location information acquisition determination as to whether the location information was acquired during the transaction, and the notification means may not issue the notification even if the determination result of the location information acquisition determination is that the location information was not acquired.
According to the above configuration, when the communication environment is not good, it is possible to prevent frequent occurrence of error notifications.

(4) In the configuration of (3) above, a first request means may be provided that makes a request to acquire the store-specific information in response to a determination result that the location information is not acquired in the location information acquisition determination.
According to the above configuration, even if a customer is located in an area with poor communication environment, the customer can clearly identify that he or she is in the store by having the mobile terminal device 50 read the store identification information (two-dimensional code). Therefore, it is possible to prevent unauthorized customers from registering products for price checks, etc.

(5) In any of the configurations (1) to (4) above, the validity determination may include an operation determination as to whether or not the operation related to the product registration is performed validly.
According to the above configuration, an error can be reported if an improper registration operation such as a price check is being performed. Therefore, improper product registration such as a price check can be prevented. Therefore, various store information such as price information can be prevented from being easily leaked.

(6) In any of the configurations (1) to (5) above, the legitimacy determination may include a store-specific information acquisition determination as to whether the store-specific information is acquired during the transaction, and the notification means may not issue the notification based on the store-specific information acquisition determination in a transaction where the first condition is met, but may issue the notification based on the store-specific information acquisition determination in a transaction where the second condition is met.
According to the above configuration, in a transaction in which the second condition is satisfied, the presence of the customer in the store can be made clear by having the mobile terminal device 50 read the store identification information (two-dimensional code). This makes it possible to prevent unauthorized customers from registering products for price checks, etc. Furthermore, in a transaction in which the first condition is satisfied, location information can be periodically acquired to determine the customer's presence, so that an error notification based on the determination of the acquisition of store identification information can be prevented. This reduces the frequency of error notifications in a transaction in which the first condition is satisfied.

(7) In the configuration of (6) above, a second request means may be provided for making a request to acquire the store-specific information in response to a predetermined time having elapsed since the start of the product registration in a transaction in which the second condition is satisfied.
According to the above configuration, in a transaction in which the second condition is satisfied, the presence of the customer in the store can be made clear by having the mobile terminal device 50 read the store identification information (two-dimensional code) every time a predetermined time period has elapsed. This makes it possible to prevent unauthorized customers from registering products for price checks, etc.

(8) In any of the configurations (1) to (7) above, the store identification information may include updated store identification information that is updated at a predetermined timing and non-updated store identification information that is not updated, and the notification means may not issue the notification based on the validity determination in a transaction resulting from the fulfillment of the second condition in which the updated store identification information is obtained, and may issue the notification based on the validity determination in a transaction resulting from the fulfillment of the second condition in which the non-updated store identification information is obtained.
According to the above configuration, in the case of a transaction based on the acquisition of updated store-specific information, it is expected that the customer is likely to be in the store, so it is possible to prevent the notification of errors based on the store-specific information acquisition determination or operation determination. Also, in the case of a transaction based on the acquisition of non-updated store-specific information, it is expected that the customer is unlikely to be in the store, so by making it possible to notify such errors, it is possible to prevent improper product registrations such as price checks.

(9) In any of the configurations (1) to (8) above, the registration means may be capable of registering the commodity to be weighed by communicating with a weighing device that weighs the commodity to be weighed, and the notification means may be configured not to issue the notification when the commodity to be weighed is registered, regardless of the start condition.
According to the above configuration, if it is clear that a customer is present in the store, it is possible to prevent an error notification from being issued.

(10) In any of the configurations (1) to (9) above, a third request means may be provided for making a request to acquire the store-specific information if the first condition is not met, and the registration means may start the product registration in response to the second condition being met by the store-specific information being acquired in response to the acquisition request by the third request means.
According to the above configuration, even if location information cannot be acquired, acquisition of store identification information can be prompted, and product registration can be started.

(11) In order to solve the above-mentioned problems, another aspect of the present invention is a product sales data processing system that includes a terminal device operated by a customer, and is equipped with: location information acquisition means for acquiring location information indicating a current location; store identification information acquisition means for acquiring store identification information presented in a store; registration means for starting product registration in response to the establishment of one of a first condition for identifying the store using the location information and a second condition for identifying the store using the store identification information; determination means for determining whether the product registration is being carried out legitimately; and notification means for notifying of an error using the determination result of the determination means, wherein the notification means issues the notification based on the start condition that has been established.
According to the above configuration, the frequency of error notifications can be made different for transactions resulting from the fulfillment of the first condition and transactions resulting from the fulfillment of the second condition, thereby reducing the frequency of errors depending on the start condition. Therefore, according to this embodiment, it is possible to prevent shopping from being interrupted by error notifications, allowing shopping to be carried out smoothly.

(12) In order to solve the above-mentioned problems, another aspect of the present invention is an alert method, which includes a computer used in a terminal device, executing a location information acquisition step to acquire location information indicating the current location, a store identification information acquisition step to acquire store identification information presented in a store, a registration step to start product registration in response to the establishment of one of a first condition for identifying the store using the location information and a second condition for identifying the store using the store identification information, a determination step to determine whether the product registration is being performed legitimately, and a notification step to notify of an error using the determination result in the determination step, wherein the notification step performs the notification based on the start condition that has been established.
According to the above configuration, the frequency of error notifications can be made different for transactions resulting from the fulfillment of the first condition and transactions resulting from the fulfillment of the second condition, thereby reducing the frequency of errors depending on the start condition. Therefore, according to this embodiment, it is possible to prevent shopping from being interrupted by error notifications, allowing shopping to be carried out smoothly.

(13) In order to solve the above-mentioned problems, another aspect of the present invention is a program that causes a computer used in a terminal device to function as: location information acquisition means that acquires location information indicating the current location; store identification information acquisition means that acquires store identification information presented in a store; registration means that starts product registration in response to the establishment of one of a first condition under which the store is identified using the location information and a second condition under which the store is identified using the store identification information; determination means that determines whether the product registration is being carried out legitimately; and notification means that notifies of an error using the determination result of the determination means, wherein the notification means issues the notification based on the start condition that has been established.
According to the above configuration, the frequency of error notifications can be made different for transactions resulting from the fulfillment of the first condition and transactions resulting from the fulfillment of the second condition, thereby reducing the frequency of errors depending on the start condition. Therefore, according to this embodiment, it is possible to prevent shopping from being interrupted by error notifications, allowing shopping to be carried out smoothly.

Note that all or part of the functions (input/output, storage, processing (including judgment)) of each device (such as the mobile terminal device 50) described above may be realized by a device other than the device described as the entity that executes the function.

Specifically, the above description has described a configuration in which the mobile terminal device 50 includes a location information acquisition unit, a store-specific information acquisition unit, a registration unit, a determination unit, a notification unit, and a request unit. All or some of these functional units may be included in another computer device. For example, all or some of these functional units may be included in the transaction status management device 11, the cloud server Sv, or another computer device. Furthermore, the number of computer devices that include these functional units is not limited to multiple, and may be one. For example, all of these functional units may be included in a single computer device.

Specifically, for example, instead of the mobile terminal device 50, the transaction status management device 11 or the cloud server Sv may store information (registration data) after product registration. Also, for example, instead of the transaction status management device 11 or the cloud server Sv, the transaction status management device 11 or the cloud server Sv may execute various processes such as notification processes (see Figures 8, 18, and 20). That is, for example, the process of determining the transaction start conditions, which is described as being executed by the mobile terminal device 50 in step S1802 of the flowchart in Figure 18, and the process of notifying an error, which is executed in step S1806, may be executed by the transaction status management device 11 or the cloud server Sv.

In relation to the above, the mobile terminal device 50 may function as a so-called thin client specialized for input/output interface components when it comes to registering products. In other words, the mobile terminal device 50 may accept various inputs (operation by the operator, detection by a device such as a scanner), send input information (operation information, scan information, etc.) to the cloud server Sv, receive processing results from the cloud server Sv based on the input information (updated screen information, device control information, etc.), and perform various outputs (display on a display unit, control of a device).

The program for implementing the shopping system 1 and mobile terminal device 50 described above may be recorded on a computer-readable recording medium and loaded into a computer system for execution. The term "computer system" as used herein includes hardware such as an OS and peripheral devices. The term "computer-readable recording medium" also refers to portable media such as flexible disks, optical magnetic disks, ROMs, and CD-ROMs, as well as storage devices such as hard disks built into a computer system. The term "computer-readable recording medium" also includes devices that retain a program for a certain period of time, such as volatile memory (RAM) within a computer system that acts as a server or client when the program is transmitted via a network such as the Internet or a communication line such as a telephone line. The program may also be transmitted from a computer system storing the program in a storage device to another computer system via a transmission medium or by transmission waves within the transmission medium. The term "transmission medium" used to transmit the program refers to a medium capable of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. The program may also be used to implement some of the aforementioned functions. Furthermore, the above functions may be realized in combination with a program already recorded in the computer system, a so-called differential file (differential program).

Sv...cloud server, 1...shopping system, 10...store controller, 11...transaction status management device, 20...POS terminal device, 30...weighing device, 50...mobile terminal device, 201, 301, 401...CPU, 205...customer display unit, 215, 305, 405...communication unit, 406...operation unit, 407...camera, 409...display, 411...GPS unit

Claims (1)

A program that causes a computer to function as a mobile terminal device that starts product registration in response to acquiring store-specific information presented in a store ,
The computer
a store identification information acquisition means capable of acquiring update type store identification information and non-update type store identification information;
a registration means for starting product registration in response to the establishment of either a first condition under which the store is identified using the update-type store identification information or a second condition under which the store is identified using the non-update-type store identification information;
It functions as
The registration means
When the product registration is started due to the second condition being satisfied, the product registration is continued by acquiring store identification information every time a predetermined time period elapses;
If the product registration is started due to the first condition being satisfied, the product registration is continued regardless of whether store identification information is acquired.
A program characterized by functioning as