WO2020050414A1

WO2020050414A1 - Self registration system and self registration method

Info

Publication number: WO2020050414A1
Application number: PCT/JP2019/035251
Authority: WO
Inventors: 佐々木　和哉; 知樹金子; 直人黒崎; 真吾樋口; 和希渡邊
Original assignee: 株式会社寺岡精工
Priority date: 2018-09-07
Filing date: 2019-09-06
Publication date: 2020-03-12
Also published as: JP2020042452A

Abstract

The present invention suppresses introduction costs. A self registration system that cooperates with an external determination means. The self registration system comprises: a registration means that performs product registration; a storage means that stores registered transaction information; and a requesting means that requests that the external determination means calculate a transaction amount that is based on the transaction information.

Description

Self registration system and self registration method

The present invention relates to a self-registration system and a self-registration method.

In shopping at a store, a self-registration system using a customer's smartphone or the like has been proposed (for example, see Patent Document 1).

JP 2016-219034 A

However, there are various issues to spread the self-registration system using smartphones. One of the issues is that when installing the self-registration system using smartphones, it is necessary to replace existing devices and systems. Therefore, it was costly and time-consuming.

The present invention has been made in view of such circumstances, and an object of the present invention is to provide a technique for reducing costs when introducing a self-registration system using a smartphone.

In order to solve the above-described problems, a self-registration system according to an aspect of the present invention is a self-registration system that cooperates with an external determination unit, and includes a registration unit that performs product registration, and stores registered transaction information. And a requesting unit for requesting the external determination unit to calculate the transaction amount based on the transaction information.

によ According to the above configuration, the cost at the time of introduction can be reduced.

In the above-mentioned self-registration system, the requesting means may be configured such that the settlement device that displays the transaction amount after calculation reads the transaction information, or that the registration device reads information for identifying the settlement device, It may be executed.

According to the above configuration, it is possible to easily request the calculation of the transaction amount.

In the self-registration system, the storage means may be capable of storing, in addition to the transaction information that could be registered for settlement, the transaction information that could not be registered for settlement.

According to the configuration described above, it is possible to appropriately manage the transaction information that could not be registered for settlement.

In the above-mentioned self-registration system, the settlement device that displays the transaction amount after calculation may include a notifying unit that reports that there is transaction information that could not be registered so that settlement is possible.

According to the configuration described above, it is possible to recognize that there is transaction information that could not be registered for settlement.

In the self-registration system, the settlement device that displays the transaction amount after the calculation may include a correction unit that corrects the transaction information that could not be registered to be able to be settled into transaction information that can be settled.

によ According to the above configuration, the settlement process can be performed after the correction.

The self-registration system starts the process related to the payment by reading the transaction information by a payment device that displays the transaction amount after calculation, or by reading the information that identifies the payment device by the registration unit. It may be provided with a first payment device and a second payment device that starts processing related to payment when transaction information is generated by a clerk's registration operation.

According to the above configuration, the self-registration system can be introduced while leaving the existing system as it is, and both systems can coexist.

In order to solve the above-described problem, a self-registration method according to another aspect of the present invention is a self-registration method that cooperates with an external determination unit. And a requesting step of requesting the external determination step to calculate a transaction amount based on the transaction information.

コスト The cost of introduction can be reduced.

It is a conceptual diagram of a network for explaining a shopping system. It is a figure showing an example of installation of a checkout device. It is a figure showing an example of installation of a checkout device. It is a figure showing an example of appearance of a checkout device. It is a figure showing an example of appearance of a checkout device. It is a figure showing the example of composition of a checkout device. It is a key map of each function for explaining the shopping system of a 1st embodiment. It is an explanatory view explaining various selling price decision logics (selling price decision function). FIG. 4 is an explanatory diagram illustrating various types of information. FIG. 4 is an explanatory diagram illustrating various types of information. FIG. 4 is an explanatory diagram illustrating various types of information. FIG. 9 is a sequence diagram illustrating an outline of a processing flow. It is an example of a display on a display part of a personal digital assistant. It is an example of a display on a display part of a personal digital assistant. It is an example of a display on a display part of a personal digital assistant. It is a display example in a display part of a checkout device. It is a display example in a display part of a checkout device. It is a display example in a display part of a checkout device. It is a key map of each function for explaining the shopping system of a 2nd embodiment. FIG. 9 is a sequence diagram illustrating an outline of a processing flow. It is a key map of each function for explaining the shopping system of a 3rd embodiment. FIG. 9 is a sequence diagram illustrating an outline of a processing flow. It is a flowchart which shows an example of the more detailed operation | movement flow at the time of goods registration. It is a flowchart which shows an example of the more detailed operation | movement flow at the time of goods registration. It is a flowchart which shows an example of a more detailed operation | movement flow at the time of payment. It is an example of the information stored in basket information. It is an example of the information stored in basket information. It is an example of the information stored in basket information. It is an example of the information stored in basket information.

(First embodiment)
FIG. 1 is a conceptual diagram of a network for explaining a shopping system. The shopping system illustrated in FIG. 1 includes a management device (for example, a store controller) 10, a cloud server 20, a payment device 30, a payment device 40, and a mobile terminal 50 (for example, a smartphone or the like).

The management device 10, the settlement device 30, and the settlement device 40 are installed in a store, and are communicably connected via a LAN 19 (which may be wired or wireless). The management device 10 can communicate with the cloud server 20. Although two payment devices 30 are shown in FIG. 1, the number of payment devices 30 in one store may be one, or three or more. Also, in FIG. 1, two payment devices 40 are illustrated, but the number of payment devices 40 in one store may be one, or three or more. The number of the payment devices 30 and the number of the payment devices 40 do not need to match. The management device 10 is basically one for one store, but may be two or more.

The portable terminal 50 is operated by a customer (a shopper or the like who is a member of the store). The mobile terminal 50 reads a product code by scanning a barcode attached to a product, that is, a recognition function for recognizing a barcode attached to a product, in addition to a general communication function and an imaging function (camera). Is provided. Note that the recognition function of the portable terminal 50 may be any function that can read the product code, and may not be one that can recognize which product code the read product code is. That is, when a barcode exists as an object in an image captured by the image capturing function (an image acquired as a through image), the mobile terminal 50 can read the product code from the barcode. It should just be.

{Circle around (4)} The mobile terminal 50 captures an image of a product (for example, a peripheral portion with a barcode) (releases the shutter) and generates a captured image (image data). The mobile terminal 50 may perform imaging to release a shutter according to an operation of a customer who is an operator, but in the present embodiment, the mobile terminal 50 determines itself (for example, see steps S31 and S45 in FIG. 15 described later). It is preferable that the imaging be performed by pressing the shutter.

The mobile terminal 50 may include an image recognition technology for extracting a feature point from an image (through image, captured image) and recognizing an imaging target (such as an object). For example, the mobile terminal 50 may specify (estimate) the captured product using an image recognition technology.

The mobile terminal 50 is basically assumed to be the property of each customer, but may be lent by the store. Note that the number of mobile terminals 50 (the number in operation) changes according to the number of visitors and the like. FIG. 1 illustrates two mobile terminals 50 as an example that a plurality of mobile terminals are possible. Is shown.

Both the settlement apparatus 30 and the settlement apparatus 40 are settlement apparatuses capable of paying at least by cash as a settlement method. The settlement apparatus 30 does not have a communication function with the cloud server 20, but the settlement apparatus 30 has a communication function with the cloud server 20. The cloud server 20 manages transaction information (basket information) for each customer, for example.

The shopping system shown in FIG. 1 is for describing a shopping system according to the first embodiment of the present invention (the same applies to the second embodiment and the third embodiment). The shopping system according to the first embodiment (the same applies to the second embodiment and the third embodiment) does not necessarily include the entire configuration illustrated in FIG. 1. For example, the shopping system according to the first embodiment (similarly to the second embodiment and the third embodiment) of the present invention may be configured, for example, from the cloud server 20 and the settlement apparatus 40. Alternatively, the cloud server 20 may be used alone, or the settlement apparatus 40 may be used alone.

FIGS. 2A and 2B are diagrams illustrating an example of installation of the settlement apparatus 40. FIG. Specifically, FIG. 2A is a perspective view of the settlement apparatus 40 and the like as viewed from the customer side. FIG. 2B is a perspective view of the settlement apparatus 40 and the like as viewed from a clerk. As shown in FIG. 2A, a counter is placed on the right side of the settlement apparatus 40 when viewed from the customer side.

FIGS. 3A and 3B are diagrams showing an example of the appearance of the settlement apparatus 40. FIG. Specifically, FIG. 3A is a perspective view of the settlement apparatus 40 as seen from the customer side. FIG. 3B is a perspective view of the settlement apparatus 40 as viewed from a clerk. FIG. 4 is a diagram illustrating a configuration example of the settlement apparatus 40. 3A, 3B and 4, the same parts are denoted by the same reference numerals.

Hereinafter, a configuration example of the settlement apparatus 40 shown in FIG. 4 will be described with reference to FIGS. 3A and 3B. The settlement apparatus 40 includes a CPU 401, a ROM 402, a RAM 403, a hard disk 404, a customer display unit 405, a customer scanner unit 406, a card payment unit 408, a change machine 409, a clerk display unit 410, It includes a key operation unit 411, a clerk-side scanner unit 412, a printing unit 413, an audio output unit 414, and a communication unit 415. These can communicate with each other via a bus.

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

The RAM 403 is a read / write memory and stores various information. For example, the RAM 403 stores information read from the ROM 402 or the hard disk 404, information obtained from the outside, information generated in processing, and the like.

The hard disk 404 stores various information. The hard disk 404 may store, for example, a program executed by the CPU 401 instead of the ROM 402. Further, instead of the RAM 403, information read from the ROM 402, information obtained from the outside, information generated in the processing, and the like may be stored.

The customer-side display unit 405 is a touch display for the customer, and displays various information to the customer and receives various inputs from the customer.
The customer-side scanner unit 406 is a scanner unit for customers, for example, scans a barcode attached to a product and reads a product code. In addition, the customer-side scanner unit 406 may scan a code (a barcode, a two-dimensional code, or the like) printed on a banknote (registered trademark) and read information necessary for settlement. Further, the customer-side scanner unit 406 may scan a code (such as a two-dimensional code) displayed on the display unit of the mobile terminal 50 and read information necessary for settlement.

The customer-side scanner unit 406 is used when a customer registers a product, but the customer may register the product by another method. For example, when a preset key (button for ordering a product) corresponding to a product is displayed on the customer side display unit 405, the customer may operate (press) the preset key to register the product.

The card payment unit 408 is a payment mechanism using various cards (a credit card, a prepaid card such as a transportation card, etc.). The card settlement unit 408 of the first embodiment (the same applies to the second embodiment and the third embodiment) includes a card recognition unit (reading unit), a display unit, and an operation unit. What is necessary is just to have. Note that the card recognition unit may directly recognize various cards (for example, a membership card, a point card, and the like) that are not used for settlement (payment).

The change machine 409 (cash settlement unit) is a cash settlement mechanism, has a bill and coin insertion slot, a bill and coin ejection slot, calculates the amount of money to be inserted into the slot, and calculates the amount of money to be inserted and the purchase amount. The change amount as the difference is calculated, and the change is discharged from the discharge port. The change machine 409 is directed to the customer side, and is operated by the customer. When bills or coins are inserted into the insertion slot, they are detected by a sensor (detection of insertion, detection of the number of denominations, etc.).

In other words, the change machine 409 is used in the settlement apparatus 40 to settle the price of a registered product in cash (money). The change machine 409 includes a bill insertion slot for inserting a bill, a coin insertion slot for inserting a coin, a bill ejection opening for discharging a bill, a coin ejection opening for discharging a coin, and a thrown or ejected coin. It has a counting unit for counting money, a mechanism for transferring money between the insertion port or the discharge port and the storage unit, the above-described sensor, and the like. Note that the bill insertion slot and the coin insertion slot are also referred to as a deposit input slot. The bill outlet and the coin outlet are also referred to as change outlets. The bill slot and the bill outlet may be common, and the coin slot and the coin outlet may be common.

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

The clerk-side display unit 410 is a touch display for the clerk, displays various information to the clerk, and receives various inputs from the clerk.
The key operation unit 411 includes various keys (buttons), and receives various inputs from a clerk.
The clerk side scanner unit 412 is a clerk scanner unit, and scans, for example, a bar code attached to a product and reads the product code. The clerk-side scanner unit 412 scans a bar code or the like attached to the name tag of the clerk and reads the clerk code.

The clerk-side scanner unit 412 is used when the clerk registers the product, but the clerk may register the product by another method. For example, when a key corresponding to a product (for example, a key corresponding to a sports newspaper) is arranged in the key operation unit 411, the clerk operates (presses) the key and registers the product. Good. When a preset key corresponding to a product is displayed on the clerk side display unit 410, the clerk may operate the preset key to register the product.

The printing unit 413 prints and issues various media (receipts, bills, etc.). The printing unit 413 is rotatably changed from the clerk side to the customer side and from the customer side to the clerk side (direction of the medium issuing port). The orientation of the printing unit 413 may be manually changed, or may be automatically changed (mechanically controlled or the like) in accordance with, for example, a shift (switching) of an operation mode (details will be described later). The correctness of the orientation of the printing unit 413 may be detected by a sensor or the like.

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

Although the appearance and the hardware configuration of the settlement apparatus 40 have been described above, the description of the appearance and the hardware configuration of the settlement apparatus 30 will be omitted. As will be described later (see FIG. 5 and the like), the functions realized by software are different between the settlement apparatus 30 and the settlement apparatus 40. However, the appearance and hardware configuration of the settlement apparatus 30 and the settlement apparatus 40 are the same. May be present or different. For example, the settlement apparatus 40 is a settlement apparatus 40 having two scanner units (the customer-side scanner unit 406 and the clerk-side scanner unit 412), whereas the settlement apparatus 30 is a settlement apparatus having one scanner unit. You may.

FIG. 5 is a conceptual diagram of each function for explaining the shopping system of the first embodiment. FIG. 6 is an explanatory diagram illustrating various selling price determination logics (selling price determination function). 7A to 7C are explanatory diagrams illustrating various types of information. FIG. 7A is an example of customer information (described later). FIG. 7B is an example of store information (described later). FIG. 7C is an example of basket information (described later).

FIG. 5 is for explaining the shopping system according to the first embodiment of the present invention. The shopping system according to the first embodiment of the present invention has the entire configuration shown in FIG. It is not necessarily included. For example, the shopping system according to the first embodiment of the present invention may be configured by the cloud server 20 and the settlement apparatus 40, may be a single cloud server 20, or may be the settlement apparatus 40. It may be a single unit. FIG. 5 is a diagram for explaining a function related to a characteristic portion of the shopping system according to the first embodiment of the present invention, and comprehensively describes functions generally required for the shopping system. Not something.

(Payment device 30)
As shown in the lower right of FIG. 5, the settlement apparatus 30 includes a selling price determination logic (selling price determination function) and a payment function. The selling price determination logic is a function for determining (calculating) a selling price (a billing amount as a sales consideration) required in the settlement process, and is realized by software. There are various types of selling price determination logic (for example, see FIG. 6), but in the example shown in FIG. 5, the settlement apparatus 30 includes a selling price determination logic A and a selling price determination logic B.

The selling price determination logic A shown in FIG. 6 is a basic price calculating function of a discount price for a basic single item corresponding to a selling price change during operation (as appropriate). The selling price determination logic B is a single item discount price calculation function for calculating a discount price for a single item based on the setting information (single item discount setting information). The selling price determination logic C is a subtotal discount price calculation function that calculates a discount price for the subtotal based on the setting information (subtotal discount setting information). The selling price determination logic D is a member discount price calculation function for calculating a discount price for a single item or a subtotal based on the setting information (member discount setting information). The selling price determination logic E is a time service discount price calculation function for calculating a discount price for a single item based on the setting information (time service discount setting information). The selling price determination logic F is a mix-match discount price calculation function for calculating a discount price for a mixed product (a product group with an unspecified combination (undefined)) based on the setting information (mix-match discount setting information). The selling price determination logic G is a set match discount price calculation function that calculates a discount price for a set product (commodity group of combination designation (fixed)) based on the setting information (set match discount setting information). The selling price determination logic H is a payment type discount price calculation function that calculates a discount price according to the payment type used based on the setting information (payment type discount setting information).

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

Information relating to the selling price determination logic A (information of a selling price change) and various setting information corresponding to the selling price determination logic B to the selling price determination logic H are stored in a storage unit of the settlement apparatus 30 or a device accessible by the settlement apparatus 30). What is necessary is just to be memorized. Note that the settlement apparatus 30 includes the selling price determination logics A and B as described above, but does not include the selling price determination logics C to F. Therefore, at least the information related to the selling price determination logic A (the information of the selling price change) and the selling price The setting information (single item discount setting information) corresponding to the decision logic B may be referred to.

6. Although not shown in FIG. 6, there is also a selling price determining logic that controls each selling price determining logic, in addition to the selling price determining logics (the selling price determining logics A to H). The selling price determination overall logic is logic for determining a selling price over a plurality of selling price determining logics. For example, when there is the selling price determination logic B (single item discount price calculation function) and the selling price determination logic D (member discount price calculation function), the selling price determination general logic includes the selling price determination logic B and the selling price determination logic D. Is determined based on the setting information (sale price determination general setting information).

As an example, the product a (100 yen in the product information) is 80 yen (10 yen discount) according to the selling price determination logic B (and single item discount setting information), and the selling price determination logic D (and the member discount setting) According to the information), if the member (customer to which the selling price determination logic D is applied) purchases the product a in a state where the price is 90 yen (20 yen discount), the selling price determination overall logic is only the selling price determination logic D May be applied to make the price of the product a 80 yen (20 yen discount), or both the selling price determination logics B and D may be applied to make the price of the product a 70 yen (30 yen discount). . Whether the price of the product a is 80 yen by applying only the selling price determination logic D or the price of the product a is 70 yen by applying both the selling price determination logics B and D is determined by the setting information (the selling price determination general setting information). )by. In addition, the selling price determination general logic may determine the one with the smaller discount amount.

For example, as described above, when the member discount is larger (when the single item discount by the selling price determining logic B is 10 yen and the member discount by the selling price determining logic D is 20 yen), the selling price determining logic D is applied. Instead, only the selling price determination logic B may be applied to make the price of the product a 90 yen. Specifically, when the discount limit is set by the member discount or when the purchase by the member discount is not reflected in the member rank result, the setting information (only the selling price determination Setting information). Contrary to the above, when the single item discount is larger (when the single item discount by the selling price determination logic B is 30 yen and the member discount by the selling price determination logic D is 20 yen), the selling price determination logic B There may be a case where the price of the product a is set to 80 yen by applying only the selling price determination logic D without applying it. Specifically, when the purchase result by the member discount is favored for the calculation of the member rank, the setting information (sale price determination general setting information) to apply only the selling price determination logic D may be set.

(4) The above-mentioned selling price determination general logic may be provided as needed (when adjustment in a plurality of selling price determining logics is necessary). For example, in the first embodiment, the cloud server 20 (similar to the settlement apparatus 30) includes selling price determination logics A, B, and C (FIG. 5), but may further include selling price determination general logic. The same applies to the second and third embodiments.

The selling price determination overall logic may be regarded as one of the selling price determining logics shown in FIG. In the following description, one or more of the individual selling price determination logics as shown in FIG. 6 may be referred to as “selling price determination logic”, or may be referred to as “selling price determination logic” including the overall selling price determination logic. is there. In other words, when simply describing “sales price determination logic”, there are cases where the overall price determination logic is excluded and cases where the overall price determination logic is not excluded.

The settlement function is a function of executing a settlement process (for example, cash payment by a change machine) based on the selling price determined by the selling price determination logic.

In FIG. 5 (similarly in FIGS. 11 and 13), the selling price determination logic is described as a function different from the settlement function. However, the selling price determination logic may be regarded as a part of the settlement function. Good. That is, in FIG. 5 (similarly in FIGS. 12 and 14), a part for determining the selling price and a part for actually executing the payment based on the determined selling price are separately considered and correspond to the part for determining the selling price. The function is referred to as a selling price determination logic, and a portion for actually executing payment is referred to as a settlement function. However, a portion including a portion for determining a selling price may be referred to as a settlement function. In the case of including the part for determining the selling price and calling it the settlement function, the selling price determination logic is a part of the settlement function.

(Management device 10)
As shown in the upper right of FIG. 5, the management device 10 stores store information and product information. The management device 10 may include selling price determination logic. The store information stored in the management device 10 is information on a store in which the management device 10 is installed, and includes, for example, a store name of the store, information specifying the store, and the like. The product information stored in the management device 10 is information on a product sold at a store where the management device 10 is installed, and includes, for example, a product code, a product name, a price, and the like. Note that the management device 10 may acquire and store product information and the like from outside (for example, a server (not shown) in the headquarters). In addition, the management device 10 may be an external device (a server at the headquarters). That is, it may manage common or separate (for each store) product information and selling price determination logic used in each store. The same applies to the management device 10 (management devices 11 and 12) of the second and third embodiments.

(Cloud server 20)
As shown in the upper left of FIG. 5, the cloud server 20 includes selling price determination logic. As described above, there are various types of selling price determination logic (for example, see FIG. 6), but in the example shown in FIG. 5, the cloud server 20 determines the selling price determining logic A, the selling price determining logic B, and the selling price determining logic. Logic C is provided. Note that the cloud server 20 includes the selling price determination logics A to C, but does not include the selling price determination logics DF. Therefore, at least the information relating to the selling price determination logic A (the information of the change in the selling price) and the selling price determination logic B are included. It is sufficient that the corresponding setting information (single item discount setting information) and the setting information (subtotal discount setting information) corresponding to the selling price determination logic C can be referred to.

(4) The cloud server 20 stores customer information, store information, product information, and basket information. Customer information is information for managing individual customers. The cloud server 20 generates customer information at the time of customer registration (it may be understood that the customer registration of the customer has been made by storing the customer information of a certain customer). Further, the cloud server 20 appropriately updates the customer information based on the basket information and the like. For example, the cloud server 20 may update the customer information by referring to the basket information at a predetermined time every day, for example.

The cloud server 20 stores, for example, customer information as shown in FIG. 7A. The customer information shown in FIG. 7A includes customer identification information, customer name, customer registration date, cancellation information, customer rank, number of points, and the like. The customer identification information is identification information for uniquely identifying a customer. The customer name is a customer's name or nickname. The customer registration date is the date and time when the customer was registered. Cancellation information is information on cancellation of a registered product after registration. The customer rank is a rank according to the purchase performance of the customer. When generating customer information of a new customer, customer identification information, customer name, and customer registration date are generated. However, since the actual transaction (product registration) has not yet started, other information (cancellation information, etc.) Is not generated.

The cloud server 20 is, for example, an application (application) for using a service provided by the cloud server 20 from outside (for example, a predetermined server that provides general applications, the cloud server 20) when registering a customer. At the time of downloading or installing), generating and storing customer identification information. In addition, for example, at the time of customer registration, the cloud server 20 acquires information input to the name field of the registration form (input form) using the mobile terminal 50 and stores the information as the customer name. In addition, the cloud server 20 acquires, for example, the current date and time at the time of customer registration and stores it as the customer registration date.

The cloud server 20 stores some or all of the customer information in another device (such as a file server that can be accessed by the cloud server 20) instead of or in addition to storing the customer information in the storage unit of the cloud server 20. You may memorize it.

The store information is obtained from the management device 10 of each store (refer to the transmission / reception data “D0” in FIG. 5; the transmission / reception data “D1” to “D6” will be described with reference to FIG. 8). That is, the cloud server 20 stores the store information by directly receiving the store information from the management device 10 of each store or indirectly via another device.

The cloud server 20 stores, for example, store information as shown in FIG. 7B. The shop information shown in FIG. 7B includes shop identification information, shop name (branch name), shop identification information 1, and shop identification information 2. The store identification information is identification information for uniquely identifying a store. The shop identification information shown in FIG. 7B includes a shop (shop name) or company code, and a branch code. The store name is the name of the store. The store name shown in FIG. 7B includes a store (brand name) or a company and a branch name. The store specifying information 1 is information of a two-dimensional code (a QR code (registered trademark) or the like) for specifying a store to be traded (a store where goods are bought and sold). The store specifying information 2 is store position information (GPS information) for specifying a store to be traded. In the example shown in FIG. 7B, the shop identification information and the shop identification information 1 are different, but the shop identification information and the shop identification information 1 may be the same.

Note that the cloud server 20 may acquire and store store information and the like from outside (such as a server (not shown) of a headquarters that controls each store). Further, the cloud server 20 may store part or all of the store information in another device (a file server or the like accessible by the cloud server 20) instead of or in addition to storing the store information in the storage unit in the own device. You may memorize it.

The product information is obtained from the management device 10 or the like of each store (see the transmission / reception data “D0” in FIG. 5; the transmission / reception data “D1” to “D6” will be described with reference to FIG. 8). That is, the cloud server 20 stores the product information by directly receiving the product information from the management device 10 of each store or indirectly via another device. The cloud server 20 may acquire and store product information from the outside (a server (not shown) of a headquarters that supervises each store). Further, the cloud server 20 may store part or all of the store information in another device (a file server or the like accessible by the cloud server 20) instead of or in addition to storing the store information in the storage unit in the own device. You may memorize it.

Basket information is information for managing individual transactions. The cloud server 20 generates basket information at the start of a transaction. In addition, the cloud server 20 updates the basket information in accordance with the progress of the transaction (every time the product is registered) (it is determined that the product has been registered by storing the product in the basket information). May be used).

The cloud server 20 stores, for example, basket information as shown in FIG. 7C. The basket information shown in FIG. 7C includes basket identification information, transaction start date and time, transaction end date and time, customer identification information, registered product information, pending product information, cancellation information, and the like. The basket identification information is identification information for uniquely identifying a basket. The basket identification information shown in FIG. 7C is composed of store identification information, a date, and a serial number (for example, a serial number for each date for each store). The transaction start date and time is the date and time when the transaction is started. The transaction start date and time shown in FIG. 7C is the date and time when the basket information was generated. The transaction start date and time may be the registration date and time of one product (the date and time when the registered product information (registered product 1) in FIG. 7C is stored). Both the date and time of generation of basket information and the date and time of registration of one product may be separately stored.

Transaction end date and time is the end date and time of the transaction. The transaction start date and time shown in FIG. 7C is the settlement date and time. The customer identification information is customer identification information for identifying a customer of the transaction. When basket information is generated, basket identification information, transaction start date and time, and customer identification information are generated. However, since the actual transaction (product registration) has not yet started, other information (transaction end date and time, etc.) is generated. Not done. The settlement date and time may be the settlement start date and time (for example, the execution date and time of the process of step S89 in FIG. 17) or the settlement end date and time (the end date and time of the process of step S91 in FIG. 17). . Both the settlement start date and time and the settlement end date and time may be separately stored.

Registered product information (total) is information that is updated each time a product is registered. The registered product information (total) includes the number of items (the number of products), an approximate subtotal amount (an approximate subtotal amount before price calculation by the selling price determination logic), a subtotal amount (subtotal amount after price calculation by the selling price determination logic), and the like. The registered product information (1) is registration information of one product. The registered product information (2) is registration information of two products. In the example shown in FIG. 7C, illustration of registered product information (3) to registered product information (5) is omitted. The registered product information (N; N is an integer) includes a product code, a product name (product name), a price, and the like.

The registered product information (N) may include the registration date and time of the product of the N items. That is, the cloud server 20 may store the registration date and time of the registered product as the registered product information. The registration date and time of each product may be used as a material for determining the necessity of application of a service such as a time service (service by the selling price determination logic E) or the effect after application.

The pending product information (total) is information that is updated each time a pending product (described later) is registered. The pending product information (total) includes the number of pending products (the number of products), the number of NON-PLUs (also referred to as “NO-FILE”) among the pending products, and the reading NG of the pending products (confirmation of unauthorized operation required). Including the number of products.

The NON-PLU means that the bar code was successfully scanned in the store (the product code could be read), but the product code was not stored in the product information, or the product code was successfully scanned in the store. However, it is a product for which the product code is not stored in the product information.

Read NG means that the merchandise code scanning failed at the store (the merchandise code could not be read) or the merchandise whose merchandise code scanning failed at the store. That is, the read NG is a product that has been timed out when it is possible to determine, for example, a case where the product has been imaged for a certain period of time by image recognition technology but barcode recognition has not been performed. For example, when a barcode cannot be correctly acquired (recognized) due to a wrinkle of a package or a blur or dirt on a barcode print, it is determined to be read NG. Also, when an illegal operation of pretending to read the barcode and putting it into the basket is detected, it is determined that the reading is NG. Note that the mobile terminal 50 includes a sensor (for example, a gyro sensor, an acceleration sensor, a distance sensor, and the like), and the mobile terminal 50 is reading a barcode (specifically, the mobile terminal 50 is reading a barcode. Is tilted, and an article (commodity) exists a certain distance away from the mobile terminal 50). When the barcode cannot be read within the predetermined time (when the barcode reading is continued for a predetermined time but the barcode cannot be read), the product is regarded as a hold product (read NG) as timeout processing.

Reserved product information (reserved product 1) is information on the reserved product of one item. The reserved product information (reserved product 2) is information on the reserved product of two items. The reserved product information (reserved product 3) is information on the reserved products of three items.

The reserved product information (reserved product N; N is an integer) includes a reserved product type (information indicating whether the reserved product is NON-PLU or read NG), image data (image data captured at the time of read NG). including. For example, when the products of N items are reserved products by NON-PLU, the reserved product information (reserved product N) includes the reserved product type “1 (NON-PLU)” and image data. When the N items of merchandise are reserved products such as read NG, the reserved product information (reserved product N) includes the reserved product type “2 (read NG)” and image data (see FIG. 18D).

The cloud server 20 stores some or all of the basket information in another device (such as a file server accessible by the cloud server 20) instead of or in addition to storing the basket information in the storage unit in the cloud server 20. You may memorize it.

(Payment device 40)
As illustrated in the lower left of FIG. 5, the settlement apparatus 40 includes a cloud communication function, a mobile terminal interlocking function, and a settlement function. The cloud communication function is a function of communicating with the cloud server 20. The mobile terminal interlocking function is a function that is interlocked with the mobile terminal 50. For example, a code (two-dimensional code or the like) displayed on the display unit of the mobile terminal 50 is optically scanned (read), and the scanned information ( Or information based on scanned information) to the cloud communication function side. The code displayed on the display unit of the mobile terminal 50 encodes information (for example, basket identification information, basket information URI, and the like) required to execute the checkout process on the purchased product by the mobile terminal 50. It is. The cloud communication function and the mobile terminal interlocking function are unique functions of the settlement apparatus 40 that is not provided with the settlement apparatus 30.

The settlement function is a function of executing a settlement process (for example, cash payment by a change machine) based on the selling price determined by the selling price determination logic of the cloud server 20.

The payment device 40 has a cloud communication function, a mobile terminal interlocking function, and a payment function. For example, it scans a code (information that can specify basket information of the customer) displayed on the display unit of the mobile terminal 50 of a certain customer. Then, the scanned information (or the information based on the scanned information) is transmitted to the cloud server 20, the selling price (subtotal information) based on the basket information of the customer is received from the cloud server 20, and the settlement process is performed based on the received selling price. Can be performed.

(Mobile terminal 50)
As shown in the lower left of FIG. 5, the mobile terminal 50 communicates with the cloud server 20. The mobile terminal 50 registers a product by communicating with the cloud server 20. That is, the portable terminal 50 recognizes the barcode as an object by reading the barcode attached to a certain product (reads the product code from the barcode) and transmits the product code to the cloud server 20. Thus, the product is registered (specifically, the product code is stored in the basket information of the cloud server 20).

(4) The mobile terminal 50 generates a code (a two-dimensional code or the like). That is, the mobile terminal 50 displays the code on the display unit in association with the mobile terminal interlocking function of the settlement apparatus 40, but the mobile terminal 50 generates the code to be displayed on the display unit itself and displays the code on the display unit. . As described above, the code generated by the mobile terminal 50 and displayed on the display unit includes information (for example, basket identification information) required to execute a checkout process on the purchased product by the mobile terminal 50 and execute the same. It is coded. Note that the code (two-dimensional code or the like) is information that can specify basket information that stores the purchased product by the mobile terminal 50 as information necessary for performing the settlement process and the execution of the purchased product by the mobile terminal 50. Any code may be used as long as the basket identification information is coded as described above. However, the present invention is not limited to coding the basket identification information. For example, the code (two-dimensional code or the like) may be a code obtained by coding a URI (Uniform Resource Identifier) such as a URL (Uniform Resource Locator) of basket information in which the mobile terminal 50 stores the purchased product. That is, the code (two-dimensional code or the like) may be a code obtained by coding the location of the corresponding basket information (path information for accessing). If one piece of basket information cannot be specified, for example, because the pass information is common, a combination of store identification information, customer identification information, information such as date and time, and the use of a serial number etc. Basket information may be specified. The same applies to a case where an apparatus different from the portable terminal 50 (for example, the cloud server 20 or the like) generates the code (such as a two-dimensional code) (described later). Hereinafter, an example in which basket identification information is coded and displayed will be described. However, the same applies to a case where a URI of basket information is coded and displayed.

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

The mobile terminal 50 may not have a function of generating a code to be displayed on the display unit. For example, instead of the mobile terminal 50, the cloud server 20 may have a function of generating a code. That is, the cloud server 20 generates a code based on the request from the mobile terminal 50, transmits the generated code to the mobile terminal 50, and the mobile terminal 50 requests the cloud server 20 to generate the code, The code generated by 20 may be received and displayed on the display unit.

FIG. 8 is a sequence diagram illustrating an outline of a processing flow in the functional configuration of FIG. More specifically, FIG. 8 (similarly in FIGS. 12 and 14) illustrates a case where a certain customer visits a certain store, registers a product displayed at the store, and completes payment of the registered product. 3 shows an example of the processing of the customer's mobile terminal 50, the settlement apparatus 40 installed in the store, and the cloud server 20 installed outside a data center or the like. The left side of FIG. 8 illustrates the processing of the mobile terminal 50, the center illustrates the processing of the settlement apparatus 40, and the right side illustrates the processing of the cloud server 20. 9A to 9C are display examples on the display unit of the portable terminal 50. FIG. 9A is an example of a product registration initial screen (described later). FIG. 9B is an example of a product registration update screen (described later). FIG. 9C is an example of a code display screen (described later). 10A to 10C are display examples on the display unit of the settlement apparatus. FIG. 10A is a display example when there is no pending product. FIG. 10B is another display example when there is no pending product. FIG. 10C is a display example when there is a reserved product.

The operation flow shown in FIG. 8 will be described below with reference to FIGS. 5, 7A to 7C, 9A to 9C, 10A to 10C, and the like.
Step S1: The mobile terminal 50 acquires information for specifying a store (store specifying information). For example, a two-dimensional code for specifying the store is displayed near the entrance of the store (a two-dimensional code is output on a display screen, a medium on which the two-dimensional code is printed is attached, and the like). By scanning (reading) the two-dimensional code with the terminal 50, the mobile terminal 50 may acquire the store identification information. When the customer who visits the store activates the application, a screen for instructing the customer to scan the two-dimensional code may be displayed as an initial screen. Then, the application may be activated, and a screen notifying the customer of the connection to the cloud server 20 may be displayed as an initial screen.

Further, for example, since the store is specified by the location, a customer who has visited the store may obtain the position information (GPS information) at the store using the mobile terminal 50 (that is, obtain the position information of the store as the store specifying information). May be). When the customer who visits the store activates the application, the location information may be acquired, and a screen notifying the customer that the cloud server 20 is being connected may be displayed as an initial screen. When a plurality of stores are detected from the position information and cannot be specified as one, a selection screen may be displayed to allow the customer to select. Alternatively, the mode may be switched to a mode in which a two-dimensional code is forcibly acquired.

The mobile terminal 50 that has acquired the store identification information transmits the acquired store identification information together with the customer identification information to the cloud server 20 as a transaction start request (see the transmission / reception data “D1” in FIGS. 5 and 8). As for the customer identification information, as described above, the information entered in the name field of the registration form using the mobile terminal 50 at the time of customer registration (when downloading or installing an application in the mobile terminal 50) is stored in the cloud server 20. However, the information may be stored in the storage unit of the mobile terminal 50 in addition to the cloud server 20. When a store is specified (when a product registration initial screen described later is acquired), the store name of the store, the service being executed (flyer information distributed on that day), and available coupon information are displayed. It may be displayed on a screen (a product registration initial screen or a screen different from the product registration initial screen). The information on the service and the coupon may be acquired from the cloud server 20 as, for example, screen information.

Also, the information of the transmission destination (the address of the cloud server 20) may be acquired at the time of customer registration (when an application is downloaded or installed in the mobile terminal 50) and stored in the storage unit of the mobile terminal 50. Good. In a case where the two-dimensional code is scanned, in addition to the store identification information, the transmission destination information) is also converted into a two-dimensional code, and the mobile terminal 50 scans the two-dimensional code. 50 may also acquire the information of the transmission destination together with the store identification information.

Step S2: The cloud server 20 that has received the customer identification information and the store identification information as the transaction start request from the mobile terminal 50 generates a basket for the transaction. Specifically, basket information as shown in FIG. 7C is generated. When basket information is generated, basket identification information, transaction start date and time, and customer identification information are generated. However, since the actual transaction (product registration) has not yet started, other information (transaction end date and time, etc.) is generated. Not done.

As described above, since the cloud server 20 stores the store information as shown in FIG. 7B, when the store identification information is received from the mobile terminal 50 as a transaction start request (although the customer identification information is also received) If the received store identification information is a two-dimensional code, the store identification information is acquired by referring to the store identification information 1, and if the received store identification information is position information (GPS information), The store identification information is acquired with reference to the store identification information 2. If the store identification information received from the mobile terminal 50 is the store identification information converted into a two-dimensional code, the cloud server 20 may obtain the store identification information as it is.

That is, the cloud server 20 that has received the customer identification information and the store identification information as the transaction start request from the mobile terminal 50 acquires the store identification information from the store identification information received from the mobile terminal 50, and further acquires the current date, A serial number is issued (numbered), the store identification information, the current date, and the serial number are combined and stored as basket identification information in the basket information. Further, the cloud server 20, which has received the store identification information and the customer identification information as the transaction start request from the mobile terminal 50, acquires the current date and time and stores it as the transaction start date and time (generation date and time) in the basket information. Further, the cloud server 20 that has received the store identification information and the customer identification information as the transaction start request from the mobile terminal 50 stores the customer identification information received from the mobile terminal 50 as the customer identification information in the basket information.

Step S3: The cloud server 20 that has generated the basket of the transaction generates initial product registration screen information (screen information of the initial product registration screen) and transmits it to the mobile terminal 50. More specifically, the cloud server 20 generates, for example, product registration initial screen information such that a product registration initial screen as shown in FIG. 9A is displayed on the mobile terminal 50, and stores the generated product registration initial screen information in a basket. The data is transmitted to the portable terminal 50 together with the identification information (see the transmission / reception data “D2” in FIGS. 5 and 8).

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

Step S5: The mobile terminal 50 scans the barcode attached to the product by the operation of the customer and reads the product code. In FIG. 8 (the same applies to FIGS. 12 and 14), it is assumed that the barcode has been successfully scanned. Although FIG. 5 is simplified for convenience of description, steps S5 to S9 are repeatedly executed each time a barcode attached to a product is scanned.

The mobile terminal 50 that has acquired the barcode transmits the product code obtained by the scanning to the cloud server 20 together with the basket identification information (see the transmission / reception data “D3” in FIGS. 5 and 8).

Step S6: Upon receiving the basket identification information and the product code from the mobile terminal 50, the cloud server 20 specifies the basket of the transaction from the basket identification information.

Step S7: The cloud server 20 updates the product data in the specified basket. Specifically, when receiving the product code as N items, the cloud server 20 stores the product code as the product code of the registered product information (registered product N) in the basket information of the specified basket, and The product name and price corresponding to the product code are acquired from the product information, and the product and price of the registered product information (registered product N) are stored. Further, the cloud server 20 updates the registered product information (total) in the basket information of the specified basket.

Step S8: The cloud server 20, which has updated the product data in the basket, generates product registration update screen information (screen information of a product registration screen which is an update screen to which the registered product has been added) and transmits it to the mobile terminal 50. . Specifically, for example, the cloud server 20 generates product registration update screen information such that a product registration update screen as shown in FIG. 9B is displayed on the mobile terminal 50, and stores the generated product registration update screen information in a basket. The data is transmitted to the portable terminal 50 together with the identification information (see the transmission / reception data “D4” in FIGS. 5 and 8).

Note that the product registration screen (product registration update screen) shown in FIG. 9B is displayed on the mobile terminal 50 after “$ Bread” is registered as a product of three items. In other words, when “@yogurt” is stored in the basket as one item, the cloud server 20 generates product registration update screen information such that “@yogurt” is displayed on the mobile terminal 50, and generates the generated product. When the registration update screen information is transmitted to the portable terminal 50 together with the basket identification information, and “〇〇 chocolate” is stored in the basket as two items, “〇〇 yogurt” and “〇〇 chocolate” are displayed on the portable terminal 50. 9B when the product registration update screen information is generated and the generated product registration update screen information is transmitted to the portable terminal 50 together with the basket identification information, and "品目 bread" is stored in the basket as three items. As shown in the figure, in the portable terminal 50, “〇〇 yogurt”, “〇〇 chocolate”, and “〇〇 bread” DOO generates a product registration screen updates as displayed, and transmits the generated product registration screen updates with the basket identification information to the portable terminal 50.

Step S9: The mobile terminal 50 that has received the basket identification information and the product registration update screen information from the cloud server 20 adds a product to the registration screen. Specifically, the mobile terminal 50 displays a product registration update screen as shown in FIG. 9B, for example. Note that, as described above, the product registration screen (product registration update screen) shown in FIG. 9B is displayed on the portable terminal 50 after “@Bread” has been registered as three products.

Step S10: The mobile terminal 50 receives a transaction instruction as a customer operation. For example, the touch of the “proceed to checkout” button shown in FIG. 9B is accepted.

Step S11: The mobile terminal 50 that has received the accounting instruction generates a two-dimensional code. That is, the portable terminal 50 converts the information (for example, basket identification information) necessary for executing the checkout process for the purchased product by the portable terminal 50 into a two-dimensional code. The mobile terminal 50 that has generated the two-dimensional code displays the generated two-dimensional code on the display unit. For example, a code display screen displaying a two-dimensional code as shown in FIG. 9C is displayed on the display unit.

Step S12: The settlement apparatus 40 scans (reads) the two-dimensional code displayed on the display unit of the portable terminal 50. For example, the checkout apparatus 40 scans the two-dimensional code displayed on the display unit of the portable terminal 50 that is directed by the clerk to the recognition range of the customer-side scanner unit 406.

Step S13: The settlement apparatus 40 that has read the two-dimensional code displayed on the display unit of the mobile terminal 50 requests the cloud server 20 to calculate a subtotal amount. For example, the settlement apparatus 40 transmits a calculation request (small calculation request information) requesting calculation of the subtotal amount to the cloud server 20 together with the basket identification information obtained from the two-dimensional code (the transmission / reception data “FIG. 5 and FIG. 8”). D5 ").

Step S14: Upon receiving the basket identification information and the small calculation request information from the mobile terminal 50, the cloud server 20 specifies the basket of the transaction from the basket identification information.

Step S15: The cloud server 20 that has specified the basket calculates the subtotal amount of money for the specified basket. Specifically, the cloud server 20 calculates the subtotal amount using the selling price determination logic (see FIG. 5). For example, the items in the basket are the three items shown in FIG. 9B (“〇〇 yogurt”, “〇〇 chocolate”, and “〇〇 bread”), and any of the discounts by the selling price determination logics A, B, and C. If not applied, the cloud server 20 calculates 830 yen, which is the same as the approximate amount (see FIG. 9B), 830 yen, as a subtotal amount. Further, for example, the items in the basket are the three items shown in FIG. 9B (“〇〇 yogurt”, “〇〇 chocolate”, and “〇〇 bread”), and “割引 yogurt” is discounted by the selling price determination logic B. Is reduced by 30 yen, the cloud server 20 calculates 800 yen, which is 30 yen less than the estimated amount (see FIG. 9B) of 830 yen, as the subtotal amount.

Step S16: The cloud server 20 that has calculated the subtotal amount updates the basket information (stores the subtotal amount (the calculated subtotal amount)) and transmits the subtotal information indicating the calculated subtotal amount together with the basket identification information to the settlement apparatus 40. (See the transmission / reception data “D6” in FIGS. 5 and 8).

Step S17: The settlement apparatus 40 that has received the basket identification information and the subtotal information from the cloud server 20 displays the subtotal amount on the customer-side display unit 405. For example, the settlement apparatus 40 receives the subtotal information indicating the subtotal amount (830 yen without discount), and the settlement apparatus 40 outputs the settlement screen in which the subtotal amount 830 is output in the total column as shown in FIG. 10A. The information is displayed on the display unit 405. In addition, for example, the settlement apparatus 40 receives the subtotal information indicating the subtotal amount (800 yen minus 30 yen), and the settlement apparatus 40 outputs the subtotal amount 800 in the total column as shown in FIG. 10B. It is displayed on the customer side display unit 405.

Step S18: The settlement apparatus 40 that has displayed the subtotal amount on the customer side display unit 405 executes payment (payment). Specifically, the settlement apparatus 40 receives the selection of the settlement type. In the case of cash, the deposit is accepted and the change amount is calculated. If there is change, the change is released and a receipt is issued. When the settlement is completed, the settlement apparatus 40 transmits the settlement completion information together with the basket information to the cloud server 20, and the cloud server 20 stores the transaction end date and time (settlement date and time) of the basket.

In the first embodiment (the same applies to the second and third embodiments), the cloud server 20 does not have the selling price determination logic H (function for calculating the type of discount price). When the selling price determination logic H (settlement type discount price calculation function) is provided, the subtotal amount may be recalculated after the selection of the settlement type. Specifically, after selecting the payment type, the settlement apparatus 40 requests the cloud server 20 to calculate the subtotal amount again (for example, the payment type selection information indicating the selected payment type together with the basket identification information is transmitted to the cloud server 20). The cloud server 20 may calculate the subtotal amount again using the selling price determination logic H, and transmit the subtotal information indicating the calculated subtotal amount again to the settlement apparatus 40 together with the basket identification information. Before the calculation request in step S13 (for example, before the two-dimensional code is generated by the portable terminal 50, or after the two-dimensional code is read by the settlement device 40, and before the transmission of the calculation request, the calculation of the subtotal amount is completed only once). Etc.), the customer is requested to select the payment type, and the payment type selection information is also transmitted to the cloud server 20 at the time of the calculation request in step S13. It may be.

(Check when registering individual products)
Note that the mobile terminal 50 transmits the product code to the cloud server 20 after scanning the product (S5). However, the mobile terminal 50 transmits a product code other than the product scanned in the store (the store at the time of visiting and displaying the product registration initial screen). A product code may not be transmitted for a product (for example, a product that has been moved to another store and scanned). For example, the portable terminal 50 acquires and stores position information (GPS information) when visiting the store (or when displaying the initial product registration screen). In addition, the mobile terminal 50 acquires the position information when scanning the individual product, and compares the position information acquired when scanning the product with the position information acquired when visiting the store (or when displaying the initial product registration screen). I do. Then, the portable terminal 50 allows the product code of the product to be transmitted to the cloud server 20 when both match (or substantially match), and when the two do not match (or substantially match), the product code of the product is The transmission of the product code to the cloud server 20 may be prohibited. The same applies to the second and third embodiments.
As a result, inappropriate product registration (for example, product registration for a basket generated in another store or the like) can be prevented.

When the transmission of the product code is prohibited as described above, the payment apparatus 40 displays an error message (for example, “cannot be registered because it is not in a store”) on the customer side display unit 405 after scanning the product. It may be displayed. The settlement apparatus 40 may display the message on the clerk-side display unit 410 instead of or in addition to the customer-side display unit 405.

(Check when reading 2D code)
After reading the two-dimensional code displayed on the display unit of the mobile terminal 50, the settlement apparatus 40 requests the cloud server 20 to calculate a subtotal amount (S12). The calculation of the subtotal amount may not be required for a product (for example, a product scanned at another store). For example, the settlement apparatus 40 refers to the store identification information of the store (the store identification information of the store may be referred to and stored in the self-payment device 40, or may be stored in another accessible device. When the two-dimensional code displayed on the display unit of the portable terminal 50 is read, the basket identification information obtained from the two-dimensional code and the store identification information of the store may be referred to. Compare with If the store identification information included in the basket identification information (see the configuration of the basket identification information in FIG. 7B) includes the store identification information of the store, the settlement apparatus 40 requests the calculation of the subtotal amount. May be permitted, and the request for calculation of the subtotal amount may be prohibited if the configuration does not include the store identification information of the store. The same applies to the second and third embodiments.
As a result, inappropriate payment (for example, payment of a product registered in another store or the like) can be prevented.

When the request for the subtotal amount is prohibited as described above, the payment apparatus 40 issues an error message (for example, “Payment cannot be performed because products other than stores are included”) after reading the two-dimensional code. The information may be displayed on the display unit 405. The settlement apparatus 40 may display the message on the clerk-side display unit 410 instead of or in addition to the customer-side display unit 405.

(Second embodiment)
Next, a second embodiment will be described. In the following, the differences between the second embodiment and the first embodiment will be mainly described, and a part or all of the description common to the first embodiment will be omitted. For example, the contents described with reference to FIGS. 1 to 4, 6, 6, 7A, 7B, 7C, 9A to 9C, and 10A to 10C are described in each embodiment (first to third embodiments). Mode), the description is omitted.

FIG. 11 is a conceptual diagram of each function for explaining the shopping system of the second embodiment. FIG. 11 is for describing a shopping system according to the second embodiment of the present invention. The shopping system according to the second embodiment of the present invention has the entire configuration shown in FIG. It is not necessarily included. For example, the shopping system according to the second embodiment of the present invention may be configured by the cloud server 20 and the payment device 40 (the payment device 41), or may be a single cloud server 20. Alternatively, the settlement apparatus 40 (the settlement apparatus 41) may be used alone. FIG. 11 is a diagram for explaining a function related to a characteristic portion of the shopping system according to the second embodiment of the present invention, and comprehensively describes functions generally required for the shopping system. Not something.

(Checkout device 30 (Checkout device 31))
As shown in the lower right of FIG. 11, the settlement apparatus 30 includes a selling price determination logic (selling price determination function) and a payment function. In the example shown in FIG. 11, the settlement apparatus 30 includes a selling price determining logic A, a selling price determining logic B, a selling price determining logic C, a selling price determining logic D, and a selling price determining logic G. That is, the difference between the settlement apparatus 30 (see FIG. 11) described in the second embodiment and the settlement apparatus 30 (see FIG. 5) described in the first embodiment is the same as the settlement apparatus described in the first embodiment. The device 30 includes the selling price determination logic A and the selling price determination logic B, whereas the settlement device 30 described in the second embodiment includes the selling price determination logic C and the selling price determination logic B in addition to the selling price determination logic A and the selling price determination logic B. It is provided with a selling price determination logic D and a selling price determination logic G. In the following, in order to distinguish from the settlement apparatus 30 described in the first embodiment, the settlement apparatus 30 described in the second embodiment is referred to as a settlement apparatus 31 for convenience.

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

(Cloud server 20)
As shown in the upper left of FIG. 11, the cloud server 20 includes a selling price determination logic (sale price determining function). In the example illustrated in FIG. 11, the cloud server 20 includes a selling price determination logic A, a selling price determination logic B, and a selling price determination logic C. The cloud server 20 stores customer information, store information, product information, and basket information. Note that there is no difference between the cloud server 20 (see FIG. 11) described in the second embodiment and the cloud server 20 (see FIG. 5) described in the first embodiment, but will be described in the second embodiment. The cloud server 20 does not use the selling price determining logic A, selling price determining logic B, and selling price determining logic C.

(Payment device 40 (payment device 41))
As shown in the lower left of FIG. 11, the settlement apparatus 40 has a cloud communication function, a mobile terminal interlocking function, and a settlement function. The settlement apparatus 40 includes a selling price determination logic A, a selling price determination logic B, and a selling price determination logic C. That is, the difference between the settlement apparatus 40 (see FIG. 11) described in the second embodiment and the settlement apparatus 40 (see FIG. 5) described in the first embodiment is the same as the settlement apparatus described in the first embodiment. The device 40 does not include the selling price determination logic, whereas the settlement device 40 described in the second embodiment includes the selling price determination logic A, the selling price determination logic B, the selling price determination logic C, the selling price determination logic D, and the selling price determination logic. It is provided with logic G. In addition, hereinafter, in order to distinguish from the settlement apparatus 40 described in the first embodiment, the settlement apparatus 40 described in the second embodiment is referred to as a settlement apparatus 41 for convenience.

(Mobile terminal 50)
As shown in the lower left of FIG. 11, the mobile terminal 50 communicates with the cloud server 20. The mobile terminal 50 registers a product by communicating with the cloud server 20. Further, the mobile terminal 50 generates a code to be displayed on the display unit by itself and displays the code on the display unit. Note that there is no difference between the mobile terminal 50 (see FIG. 11) described in the second embodiment and the mobile terminal 50 (see FIG. 5) described in the first embodiment.

送受信 The transmission / reception data “D0” to “D4” in FIG. 11 are the same as the transmission / reception data “D0” to “D4” in FIG. Also. The transmission / reception data “D15” and “D16” in FIG. 11 will be described with reference to FIG.

FIG. 12 is a sequence diagram illustrating an outline of a processing flow in the functional configuration of FIG. More specifically, FIG. 12 shows a case where a customer visits a certain store, registers a product displayed at the store, and completes the payment of the registered product, similarly to the scene of FIG. It shows an example of each processing of the customer's mobile terminal 50, the settlement device 41 installed in the store, and the cloud server 20 installed outside a data center or the like. The left side of FIG. 12 shows the processing of the mobile terminal 50, the center shows the processing of the settlement apparatus 41, and the right side shows the processing of the cloud server 20.

Note that steps S101 to S112 in FIG. 12 are the same as steps S1 to S12 in FIG.

Step S113: The settlement apparatus 41 that scans the two-dimensional code displayed on the display unit of the mobile terminal 50 requests the cloud server 20 for the product data in the basket. For example, the settlement apparatus 41 transmits the product data request information for requesting the product data in the basket to the cloud server 20 together with the basket identification information acquired from the two-dimensional code (see the transmission / reception data “D15” in FIGS. 11 and 12). .

Step S114: Upon receiving the basket identification information and the product data request information from the mobile terminal 50, the cloud server 20 specifies the basket of the transaction from the basket identification information.

Step S115: The cloud server 20 transmits the product data of the specified basket together with the basket identification information to the settlement apparatus 41 (see the transmission / reception data "D16" in FIGS. 11 and 12).

Step S116: The settlement apparatus 41 which has received the basket identification information and the product data from the cloud server 20 calculates a subtotal amount. Specifically, the settlement apparatus 41 calculates a subtotal amount using the selling price determination logic (see FIG. 11).

Step S117: The settlement apparatus 41 that has calculated the subtotal amount displays the subtotal amount on the customer side display unit 405.
Step S118: The settlement apparatus 41 that has displayed the subtotal amount on the customer side display unit 405 executes payment (payment).

Although not shown in FIG. 12, the settlement apparatus 41 that has calculated the subtotal amount transmits subtotal information indicating the calculated subtotal amount together with the basket identification information to the cloud server 20. The cloud server 20 that has received the basket identification information and the subtotal information from the settlement apparatus 41 updates the basket information (stores the subtotal amount (the calculated subtotal amount)).

(Third embodiment)
Subsequently, a third embodiment will be described. In the following, the differences between the third embodiment and the first and second embodiments will be mainly described, and portions common to the first and second embodiments will be described. A part or all is omitted. For example, the contents described with reference to FIGS. 1 to 4, FIG. 6, FIGS. 7A to 7C, FIGS. 9A to 9C, and FIGS. 10A to 10C are described in each embodiment (first to third embodiments). Description is omitted because it is common.

FIG. 13 is a conceptual diagram of each function for explaining the shopping system of the third embodiment. FIG. 13 is for explaining a shopping system according to the third embodiment of the present invention. The shopping system according to the third embodiment of the present invention has the entire configuration shown in FIG. It is not necessarily included. For example, the shopping system according to the third embodiment of the present invention may be configured by the cloud server 20 (cloud server 21) and the settlement apparatus 40, or may be a single cloud server 20 (cloud server 21) Or the settlement apparatus 40 alone. FIG. 13 is a diagram for explaining a function related to a characteristic portion of the shopping system according to the third embodiment of the present invention, and generally describes functions generally required for the shopping system. Not something.

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

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

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

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

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

送受信 The transmission / reception data “D0” to “D6” in FIG. 13 are the same as the transmission / reception data “D0” to “D6” in FIG. The transmission / reception data “D26” in FIG. 13 will be described with reference to FIG.

FIG. 14 is a sequence diagram illustrating an outline of a processing flow in the functional configuration of FIG. Specifically, FIG. 14 shows a case where a customer visits a certain store, registers products displayed in the store, and completes the settlement of the registered products, as in the scenes of FIGS. 8 and 12. 5 shows an example of the processing of the mobile terminal 50 of the customer, the settlement apparatus 40 installed in the store, and the cloud server 21 installed outside the data center or the like. The left side of FIG. 14 illustrates the processing of the mobile terminal 50, the center illustrates the processing of the settlement apparatus 40, and the right side illustrates the processing of the cloud server 21.

Steps S201 to S214 in FIG. 14 are the same as steps S1 to S14 in FIG.

Step S215: The cloud server 21 specifying the basket requests the management device 12 to calculate the subtotal amount. For example, the cloud server 21 transmits a calculation request (small calculation request information) requesting calculation of the subtotal amount to the management device 12 together with the product data of the basket specified in step S214 and the basket identification information ( The transmission / reception data “D26” in FIGS. 13 and 14).

Step S216: The management device 12, which has received the basket identification information, the small calculation start request information and the product data from the cloud server 21, calculates the subtotal amount. Specifically, the management device 12 calculates the subtotal amount using the selling price determination logic (see FIG. 13).

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

Step S218: The cloud server 21 that has received the basket identification information and the subtotal information from the management device 12 updates the basket information (stores the subtotal amount (the calculated subtotal amount)), The subtotal information is transmitted to the settlement apparatus 40 (see the transmission / reception data "D6" in FIGS. 13 and 14).

Step S219: The settlement apparatus 40 that has received the basket identification information and the subtotal information from the cloud server 21 displays the subtotal amount on the customer-side display unit 405.
Step S220: The settlement apparatus 40 that has displayed the subtotal amount on the customer side display unit 405 executes payment (payment).

The transmission and reception of various information (transmission / reception data “D26” and transmission / reception data “D6”) in steps S215 to S216 and steps S217 to S218 are realized by an external cooperation function on the cloud server 21 side and an external cooperation function on the management device 12 side. Is done.

Hereinafter, a more detailed operation flow will be described.
FIG. 15 and FIG. 16 are flowcharts showing an example of a more detailed operation flow at the time of product registration. More specifically, FIGS. 15 and 16 show steps S5 to S11 in FIG. 8 described as the first embodiment, steps S105 to S111 in FIG. 12 described as the second embodiment, and FIGS. The range of steps S205 to S211 in FIG. 14 described above is described in consideration of a case where there is a reserved product or cancellation. FIG. 16 is a continuation of FIG. Note that description of a part of the contents described in FIG. 8 and the like is omitted.

Step S30: The mobile terminal 50 determines whether or not an operation for scanning a barcode attached to the product has been performed. For example, the mobile terminal 50 includes various sensors (for example, a gyro sensor, an acceleration sensor, a distance sensor, and the like), and continues for a predetermined time after the various sensors determine that the mobile terminal 50 is in an attitude of reading a barcode. When it is determined that the posture is maintained (that is, when the posture for reading the barcode is maintained for a predetermined time or more), or when the barcode is read within the predetermined time (that is, when the product code is acquired). It is determined that an operation of scanning the barcode attached to the product has been performed. If it is determined that the barcode scanning operation has been performed, the process of the portable terminal 50 proceeds to step S31. If it is determined that the operation of scanning the barcode has not been performed, the process of the portable terminal 50 proceeds to step S50 in FIG.

Step S31: The mobile terminal 50 determines whether or not the product code has been successfully read. If it is determined that the product code has been successfully read, the process of the portable terminal 50 proceeds to step S32. If it is determined that the reading of the product code has failed, the process of the portable terminal 50 proceeds to step S45.

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

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

Step S34: The cloud server 20 (21) refers to the product information of the store. Specifically, the cloud server 20 (21) refers to the merchandise information of the store and identifies (attempts to identify) the merchandise of the merchandise code received from the mobile terminal 50. That is, the cloud server 20 (21) checks whether or not the product code received from the mobile terminal 50 is stored in the product information of the store. Then, the process proceeds to step S35 as the process of the cloud server 20 (21).

Step S35: When the product of the product code received from the mobile terminal 50 has been identified, the process of the cloud server 20 (21) proceeds to step S36. If the product of the product code received from the mobile terminal 50 cannot be specified, the process of the cloud server 20 (21) proceeds to step S38.

Step S36: The cloud server 20 (21) stores the registered product information in the basket. Specifically, the cloud server 20 (21) stores a product code, a product name, a price, and the like as registered product information. Then, the process proceeds to step S37 as the process of the cloud server 20 (21).
Step S37: The cloud server 20 (21) generates merchandise registration update screen information (screen information of the merchandise registration screen on which the registered merchandise information of step S36 is reflected) and transmits the generated information to the mobile terminal 50. Then, the process proceeds to step S48 as the process of the cloud server 20 (21).

Step S38: The cloud server 20 (21) stores the pending product information in the basket. Specifically, the cloud server 20 (21) stores the reserved product type “1 (NON-PLU)” and the product code as the reserved product information. Then, the process proceeds to step S39 as the process of the cloud server 20 (21).
Step S39: The cloud server 20 (21) generates merchandise registration update screen information (screen information of the merchandise registration screen on which the pending merchandise information of step S38 is reflected) and transmits the generated information to the mobile terminal 50. Then, the process proceeds to step S40 as the process of the cloud server 20 (21).
Step S40: The cloud server 20 (21) transmits an error message (NO-FILE) to the mobile terminal 50. Then, the process proceeds to step S48 as the process of the cloud server 20 (21).

Step S41: The mobile terminal 50 determines whether an error message has been received. If it is determined that an error message has been received, the process of the portable terminal 50 proceeds to step S43. If it is determined that the error message has not been received, the process of the portable terminal 50 proceeds to step S42.

Step S42: The mobile terminal 50 updates the registration screen. That is, on the display unit of the portable terminal 50, a registration screen reflecting the scanning operation in step S30 (a registration screen on which the scanned product is additionally displayed) is displayed. Then, the process of the portable terminal 50 proceeds to step S50 in FIG.

Step S43: The mobile terminal 50 updates the registration screen. That is, a registration screen reflecting the scan operation in step S30 (a registration screen in which the scanned product is additionally displayed as a pending product (NO-FILE)) is displayed on the display unit of the portable terminal 50. Then, the process of the portable terminal 50 proceeds to step S44.
Step S44: The mobile terminal 50 displays an error message. Specifically, the mobile terminal 50 displays an error message indicating that the product on which the scanning operation has been performed in step S30 is a reserved product (NO-FILE). Note that the mobile terminal 50 instructs, instead of or in addition to the error message indicating that the product is a reserved product (NO-FILE), to store the reserved product separately from products other than the reserved product in the shopping basket. A message may be displayed. Then, the process of the portable terminal 50 proceeds to step S50 in FIG.

Step S45: The mobile terminal 50 captures an image of a product (a product for which the reading of the product code has failed) and transmits the captured image (image data) to the cloud server 20 (21) together with the basket identification information. The mobile terminal 50 may store the captured image in the storage unit in addition to transmitting the captured image to the cloud server 20 (21). Then, the process of the portable terminal 50 proceeds to step S46.
Step S46: The mobile terminal 50 updates the registration screen. That is, a registration screen reflecting the scan operation in step S30 (a registration screen in which the scanned product is additionally displayed as a pending product (read NG)) is displayed on the display unit of the portable terminal 50. Then, the process of the mobile terminal 50 proceeds to step S47.

Step S47: The mobile terminal 50 displays an error message. Specifically, the mobile terminal 50 displays an error message indicating that the product on which the scan operation has been performed in step S30 is a reserved product (read NG). Note that the mobile terminal 50 replaces or adds the error message indicating that the product is a pending product (NG) with a message indicating that the pending product is to be stored separately from products other than the pending product in the shopping basket. It may be displayed. Then, the process of the portable terminal 50 proceeds to step S50 in FIG.

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

Step S49: The cloud server 20 (21) stores the pending product information in the basket. Specifically, the cloud server 20 (21) stores the pending product type “1 (read NG)” and the image data received in step S48 as the pending product information. Then, the process of the cloud server 20 (21) proceeds to step S52 in FIG.

Step S50: The mobile terminal 50 selects an operation of canceling a registered product (a product in which the registered product information is stored in the basket in step S36) (for example, by touching a product displayed on the registration screen, It is determined whether or not an operation of touching a cancel button displayed after the selection has been performed. If it is determined that an operation to cancel a registered product has been performed, the process of the mobile terminal 50 proceeds to step S51. If it is determined that there is no operation to cancel the registered product, the process of the mobile terminal 50 proceeds to step S60.

Step S51: The mobile terminal 50 transmits the product cancellation information to the cloud server 20 (21) together with the basket identification information. The product cancellation information includes, for example, the product code and the quantity of the product to be canceled. Then, the process of the portable terminal 50 proceeds to step S56. Various methods are conceivable for the mobile terminal 50 to acquire the product code of the product to be canceled. For example, the cloud server 20 (21) registers the product code in the product registration update screen information transmitted to the mobile terminal 50. The product code of the completed product may be stored (stored), and the mobile terminal 50 may acquire the product code of the product to be canceled from the product registration update screen information.

Step S52: The cloud server 20 (21) determines whether basket identification information and cancellation information have been received. When the basket identification information and the cancellation information are received, the processing of the cloud server 20 (21) ends. The processing of the cloud server 20 (21) is started again from step S33 in FIG. 15 after the end. When the basket identification information and the cancellation information are received, the process of the cloud server 20 (21) proceeds to step S53.

Step S53: The cloud server 20 (21) deletes the registered product information of the basket. Specifically, the cloud server 20 (21) deletes the product registration information in the basket indicated by the basket identification information and the cancellation information. Then, the process of the cloud server 20 (21) proceeds to step S54. In addition, when the cloud server 20 (21) receives the cancellation information for canceling a part of the plurality of registered products, the cloud server 20 (21) updates the number of the registered products. For example, when cancel information for canceling two of the five registered products is received, the number of the registered products is updated from five to three.

Step S54: The cloud server 20 (21) stores the cancellation information in the basket. Specifically, the cloud server 20 (21) stores a product code, a quantity, and the like as cancellation information. Then, the process of the cloud server 20 (21) proceeds to step S55.

Step S55: The cloud server 20 (21) generates merchandise registration update screen information (screen information of the merchandise registration screen in which the registered merchandise information is deleted in step S53 and the cancellation information in step S54 is reflected), and Send. Then, the processing of the cloud server 20 (21) ends. The processing of the cloud server 20 (21) is started again from step S33 in FIG. 15 after the end.

Step S56: The mobile terminal 50 updates the registration screen. That is, on the display unit of the portable terminal 50, a registration screen (a registration screen in which registered products are deleted, a registration screen in which the number of registered products is reduced) reflecting the cancel operation in step S50 is displayed. Then, the process of the portable terminal 50 proceeds to step S60.

Step S60: The mobile terminal 50 determines whether or not there is a transaction instruction (for example, a touch of a “proceed to transaction” button shown in FIG. 9B). If it is determined that there is an accounting instruction, the process proceeds to step S61. If it is determined that there is no accounting instruction, the process returns to step S30.

Step S61: The mobile terminal 50 generates a two-dimensional code. That is, the portable terminal 50 converts the information (for example, basket identification information) necessary for executing the checkout process for the purchased product by the portable terminal 50 into a two-dimensional code. Then, the process of the portable terminal 50 proceeds to step S62.
Step S62: The mobile terminal 50 displays the two-dimensional code generated in step S61 on the display unit. Then, the process of the portable terminal 50 ends.

FIG. 17 is a flowchart showing an example of a more detailed operation flow at the time of settlement. More specifically, FIG. 17 illustrates the range of steps S12 to S18 in FIG. 8 described as the first embodiment in consideration of a case where there is a reserved product or cancellation. Note that description of a part of the contents described in FIG. 8 is omitted.

Step S70: The settlement apparatus 40 determines whether the two-dimensional code displayed on the display unit of the portable terminal 50 has been read. If it is determined that the two-dimensional code has been read, the process proceeds to step S71. If it is determined that the two-dimensional code has not been read, step S70 is repeatedly executed.
Step S71: The settlement apparatus 40 requests the cloud server 20 to calculate a subtotal amount. For example, the settlement apparatus 40 transmits a calculation request (small calculation request information) requesting calculation of the subtotal amount to the cloud server 20 together with the basket identification information acquired from the two-dimensional code.

Step S72: The cloud server 20 determines whether or not basket identification information and small calculation start request information have been received. If the basket identification information and the small calculation start request information have been received, the process proceeds to step S73. If the basket identification information and the small calculation start request information have not been received, step S71 is repeatedly executed.

Step S73: The cloud server 20 specifies the basket for which the settlement apparatus 40 has requested the calculation of the subtotal amount. Specifically, the cloud server 20 specifies the basket for which the settlement apparatus 40 has requested the calculation of the subtotal amount from the basket identification information received from the settlement apparatus 40. Then, the process of the cloud server 20 proceeds to step S74.
Step S74: The cloud server 20 specifies the customer who requests the calculation of the subtotal (the customer related to the basket). Specifically, the cloud server 20 specifies the customer requesting the calculation of the subtotal amount from the customer identification information in the basket specified in step S72. Then, the process of the cloud server 20 proceeds to step S75.

Step S75: The cloud server 20 confirms the cancellation status of the customer requesting the calculation of the subtotal amount (the customer specified in step S74). Specifically, the cloud server 20 refers to the cancellation information of the customer information (see FIG. 7A) of the customer and confirms the past cancellation status of the customer. In addition, the cloud server 20 refers to the cancellation information (cancellation information (total of this time) and the like) of the basket information (FIG. 7C) instead of or in addition to the cancellation information of the customer information (see FIG. 7A) of the customer. Alternatively, the customer may check the status of the cancellation this time. Then, the process of the cloud server 20 proceeds to step S76.

Step S76: The cloud server 20 determines whether a warning is necessary based on the confirmed cancellation status. For example, in the mode in which the status of the past cancellation is confirmed in step S75, for example, the cloud server 20 determines the total number of cancellations in the past two times (when visiting the store last time and when visiting the store two times before) and a predetermined threshold (threshold A). Is determined to be necessary if the total number of cancellations in the past two times is equal to or more than the threshold A, and if the total number of cancellations in the past two times is less than the threshold A, May determine that no warning is required. In addition, for example, in a mode in which both the status of the current cancellation and the status of the past cancellation are confirmed in step S75, for example, the cloud server 20 determines the number of times of the current cancellation and a predetermined threshold (hereinafter referred to as threshold B). Also, the total number of cancellations in the past two times is compared with a predetermined threshold (threshold C), and the number of cancellations this time is equal to or greater than the threshold B and the total number of cancellations in the past two times is the threshold C. If so, it is determined that a warning is necessary. In other cases (if the current number of cancellations is less than threshold B (regardless of the total number of past two cancellations), the number of current cancellations is equal to the threshold. If it is B or more, but the total number of cancellations in the past two times is less than the threshold C), it may be determined that the warning is unnecessary. In addition, for example, in a mode in which the status of the current cancellation is confirmed in step S75, for example, the cloud server 20 compares the current cancellation count with a predetermined threshold (threshold D), and determines that the current cancellation count is If the number of cancellations is less than the threshold D, it may be determined that a warning is necessary. The thresholds A to D may be different numbers from each other, or two or more may be the same number. If it is determined that a warning is necessary, the process proceeds to step S77. If it is determined that no warning is necessary (it is unnecessary), the process proceeds to step S80.

Step S77: The cloud server 20 transmits the warning information to the settlement device 40. Then, the process of the cloud server 20 proceeds to step S80.

Step S78: The settlement apparatus 40 determines whether or not the warning information has been received. If the warning information has been received, the process proceeds to step S79. If the warning information has not been received, the process proceeds to step S82.
Step S79: The settlement apparatus 40 issues a warning. For example, the checkout apparatus 40 may display a message on the customer side display unit 406 that the clerk checks the contents of the product. Alternatively, in addition to or in addition to the above, the settlement apparatus 40 may display a message on the clerk-side display unit 410 to confirm that the merchandise has been canceled. Note that the settlement apparatus 40 sends a message using a specific numerical value (for example, if the past cancellation status is confirmed in step S75, a message indicating that the cancellation result of the customer is equal to or more than the reference number of times). Alternatively, if the status of the current cancellation is confirmed in step S75, a message indicating that this transaction has been canceled more than the standard number of times for the customer may be displayed on the clerk-side display unit 410.

Step S80: The cloud server 20 determines whether or not there is a reserved product (NON-PLU, read NG) in the basket information. If it is determined that there is a reserved product, the process proceeds to step S81. If it is determined that there is no pending product, the process proceeds to step S88.
Step S81: The cloud server 20 transmits information (modification instruction information) for instructing modification of the reserved product in the basket information to the settlement apparatus 40. Then, the process of the cloud server 20 proceeds to step S86.

Step S82: The settlement apparatus 40 determines whether or not correction instruction information has been received. If the correction instruction information has been received, the process proceeds to step S83. If the correction instruction information has not been received, the process proceeds to step S90.

Step S83: The settlement apparatus 40 notifies that there is a reserved product. For example, the settlement apparatus 40 displays a message indicating that there is a reserved product on one or both of the customer-side display unit 405 and the clerk-side display unit 410. For example, the settlement apparatus 40 may display a small screen on the customer side display unit 406 on which a message (see FIG. 10C) indicating that the clerk checks the contents of the product is displayed. In addition, instead of or in addition to the above, the settlement apparatus 40 may display a message indicating that there is a reserved product on the clerk-side display unit 410. Then, the process proceeds to step S84 as the process of the settlement apparatus 40.

Step S84: The settlement apparatus 40 accepts the correction of the reserved product by the clerk. For example, for a reserved product (read NG), a clerk scans the product (for example, the same product on a display shelf). In addition, for example, a price is input by a clerk for a reserved product (NON-PLU). Stored goods (reading NG, NON-PLU) may be canceled by a clerk. In other words, in either method, it is sufficient that the correction of the reserved product by the clerk is accepted so that the reserved product disappears. Note that the cancellation by the clerk is based on the number of the current cancellation in the basket information. (The number of the past cancellation in the customer information is based on the number of the current cancellation in the basket information. ) May not be reflected. As an example, the cancel operation by the clerk may be a special cancel operation (an operation different from the cancel operation performed by the customer), and if the special cancel operation is performed, it may not be reflected in the current number of cancellations.
Step S85: The settlement apparatus 40 transmits, to the cloud server 20, correction information indicating the details of the correction of the held product by the clerk, together with the basket identification information. Then, the process proceeds to step S90 as a process of the settlement apparatus 40.

Step S86: The cloud server 20 determines whether basket identification information and correction information have been received. If the basket identification information and the correction information have been received, the process proceeds to step S87. If the basket identification information and the correction information have not been received, step S86 is repeatedly executed.
Step S87: The cloud server 20 updates the basket information according to the correction information. Then, the process of the cloud server 20 proceeds to step S88.

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

Step S90: The settlement apparatus 40 displays the subtotal amount on the customer-side display section 405.
Step S91: The settlement apparatus 40 executes payment (payment). Then, the processing of the settlement apparatus 40 ends. At the end of the process in step S91, information indicating that the settlement has been completed is transmitted to the cloud server 20.

FIGS. 18A to 18D are examples of information stored in basket information. 18A to 18D show a part of the basket information shown in FIG. 7C.

FIG. 18A shows information stored in the basket information when one item of product (“（yogurt”) is registered normally (when it is not a reserved product). In the example shown in FIG. 18A, the number of items “1” and the approximate subtotal amount “260” are stored as registered product information (total), and the product code “S5111” of “@yogurt” is stored as registered product information (registered product 1). , And a product name “@yogurt” and a price “260” of “@yogurt” are stored.

When the cloud server 20 (21) receives the product code of the product of one item and specifies the product (“@yogurt”) of the product code (step S35 (YES) in FIG. 15), the cloud server 20 (21) shown in FIG. 18A The registered merchandise information (total) is stored as described above, and the registered merchandise information (registered merchandise 1) is stored as shown in FIG. 18A (step S36). That is, the registered product information (registered product 1) successfully reads the product code ("S5111") of one product ("@yogurt") on the mobile terminal 50 (step S31 (YES) in FIG. 15). The product code ("S5111") is transmitted to the cloud server 20 (21) (step S32), and the product ("@yogurt") of the product code ("S5111") is specified in the cloud server 20 (21). If it has been performed (step S35 (YES)), it is stored (step S36).

FIG. 18B shows information stored in the basket information when up to three items of merchandise (“〇〇 bread”) are normally registered. In the example illustrated in FIG. 18B, the number of articles “3” and the approximate subtotal amount “830” are stored as registered product information (total), and the product code “S5111” of “@yogurt” is stored as registered product information (registered product 1). ”And the product name“ 〇〇 yogurt ”and the price“ 260 ”of“ 〇〇 yogurt ”are stored, and as the registered product information (registered product 2), the product code“ S3083 ”of“ 〇〇 chocolate ”and the product name“ $ ” “Chocolate” and the price “350” of “Chocolate” are stored, and as the registered product information (registered product 3), the product code “S1493” of “$ Bread”, and the product names “$ Bread” and “$” "Bread" price "220" is stored.

When the cloud server 20 (21) receives the product codes of the three product items and specifies the product (“$ food bread”) of the product code (step S35 (YES) in FIG. 15), the cloud server 20 (21) shown in FIG. 18B. Thus, the registered product information (total) is updated, and the registered product information (registered product 3) is stored as shown in FIG. 18B (step S36). The registered merchandise information (registered merchandise 1) is stored when one item of merchandise ("@yogurt") is specified (step S36). The registered merchandise information (registered merchandise 2) is stored when two items of merchandise ("$ chocolate") are specified (step S36).

FIG. 18C shows information stored in the basket information when “〇〇 bread” is canceled from the state of FIG. 18B, for example. In the example shown in FIG. 18C, the number of articles “2” and the approximate subtotal amount “610” are stored as registered product information (total), and the product code “S5111” of “@yogurt” is stored as registered product information (registered product 1). ”And the product name“ 〇〇 yogurt ”and the price“ 260 ”of“ 〇〇 yogurt ”are stored, and as the registered product information (registered product 2), the product code“ S3083 ”of“ 〇〇 chocolate ”and the product name“ $ ” "Chocolate" and the price "350" of "Chocolate" are stored, the number of cancellations "1" is stored as the cancellation information (total of this time), and the product of "Chocolate bread" as the cancellation information (Cancel 1) The code “S1493” and the quantity “1” are stored.

When the cloud server 20 (21) receives the product cancellation information (including the product code of “$ food bread”) (step S52 (YES) in FIG. 16), the registered product information (total) as shown in FIG. 18C Is updated, and the registered merchandise information (registered merchandise 3) is deleted as shown in FIG. 18C (step S53), and as shown in FIG. 18C, the cancellation information (this time total) is stored, and the cancellation information (cancel 1) is stored. Is stored (step S54). That is, when an operation of canceling the already registered three items of the product “〇〇 bread” is performed on the mobile terminal 50 (step S50 (YES) in FIG. 16), the cloud server 20 (21) stores the product cancellation information in the cloud server 20 (21). (Including the product code of “$ Bread”) is transmitted (Step S51), and the registered product information of the product “$ Bread” is deleted in the cloud server 20 (21) (Step S53), and the product “$” The cancellation information of "white bread" is stored (step S54).

FIG. 18D shows that one product (“$ yogurt”) has been successfully registered, two products (“$ chocolate”) have become pending products (NON-PlU), and three products (“$ yogurt”). The information stored in the basket information when the “bread” becomes a reserved product (read NG). In the example shown in FIG. 18D, the number of articles “1” and the approximate subtotal amount “260” are stored as registered product information (total), and the product code “S5111” of “@yogurt” is stored as registered product information (registered product 1). , And the product name “$ yogurt” and the price “260” of “$ yogurt” are stored, and the total number of products “2”, the number of NON-PLU products “1”, and the read NG Unauthorized operation confirmation) The number of items “1” is stored, and the pending product type “1 (NON-PLU)” and the product code “S3083” of “@ chocolate” are stored as the pending product information (reserved product 1), As the reserved product information (reserved product 2), a captured image “AAA.jpeg” in which a portion including a bar code of “2 (read NG)” and “$ Bread” is captured is stored.

As for the pending product information (pending product 1), the mobile terminal 50 successfully reads the product code (“S3083”) of two products (“$ chocolate”) (step S31 (YES) in FIG. 15), and stores the cloud in the cloud. The product code (“S3083”) is transmitted to the server 20 (21) (step S32), but the product (actually “@ chocolate”) of the product code (“S3083”) is sent to the cloud server 20 (21). ) Is not specified (step S35 (NO)), it is stored (step S38).

As for the pending product information (pending product 2), the reading of the product code (“S1493”) of the three products (“$ food bread”) on the mobile terminal 50 has failed (step S31 (NO) in FIG. 15) and the cloud Image data obtained by capturing the product (“$ Bread”) is transmitted to the server 20 (21) (step S45), and when the image data is received by the cloud server 20 (21) (step S48 (YES)). Is stored (step S49).

While the embodiments have been described above, the concept (concept) and the like of each embodiment will be described.
In the shopping system according to the first embodiment shown in FIG. 5, the checkout device 40 may be a device newly installed (delivered) in a store in order to use a service provided by the cloud server 20. In other words, the shopping system according to the first embodiment shown in FIG. 5, when starting the use of the service by the cloud server 20, separates the service by the cloud server 20 from the settlement apparatus 30 originally installed in the store. It may be constructed by additionally introducing the settlement apparatus 40 which is a new terminal having functions (mobile terminal interlocking function, cloud communication function) necessary for use. In other words, the shopping system according to the first embodiment, for example, when starting the use of the service by the existing external cloud server 20, does not modify the existing payment device 30 or the management device 10 (the management device). 10 has some additional functions such as transmission of store information and merchandise information), but it is only necessary to additionally install a payment terminal 40, which is a new terminal (reception of store information and merchandise information for the cloud server 20). This is constructed based on the concept that the service provided by the cloud server 20 can be introduced in a short period of time.

Prior to the introduction of the self-system (self-registration system, self-scanning system) by the cloud server 20, the selling price determination logics (sale price determining logics A and B) operated by the existing systems (the management device 10 and the settlement device 30). ) Is within the range of the selling price determination logic (the selling price determination logics A, B, and C) that can be provided by the cloud server 20, so that it is not necessary to use the existing selling price determination logic when introducing the self-system by the cloud server 20. Absent. Therefore, it is sufficient to add the settlement apparatus 40 as a new terminal, and the cost at the time of introduction can be suppressed. In the example shown in FIG. 5, the cloud server 20 implements the selling price determination logic C but does not operate it.

In the shopping system according to the second embodiment shown in FIG. 11, the settlement apparatus 41 is a modification of the settlement apparatus 40 shown in FIG. 5 or the existing settlement apparatus 31 in order to use the service provided by the cloud server 20. It may be a device. In other words, the shopping system according to the first embodiment shown in FIG. 11 starts the use of the service by the cloud server 20 when the payment device 40 as a new terminal or the payment device 31 originally installed in the store. On the other hand, the functions required to use the service provided by the cloud server 20 (the selling price determination logic for the settlement apparatus 40 as a new terminal, the mobile terminal interlocking function, and the cloud communication function for the settlement apparatus 31) are provided. It may be constructed additionally. In other words, the shopping system of the second embodiment, for example, when starting the use of the service by the existing external cloud server 20, performs a modification to the settlement apparatus 40, which is a new terminal, or the existing settlement apparatus 31. If implemented (although the management device 10 and the cloud server 20 also have some additional functions such as transmission and reception of store information and product information), the cloud server 20 can be introduced in a short period of time. Things.

Before the introduction of the self-system by the cloud server 20, the selling price determination logics (selling price determination logics A, B, C, D, and G) operated by the existing systems (the management device 11 and the settlement device 31) are: Since the cloud server 20 does not fall within the range of the selling price determination logic (selling price determination logics A, B, and C), when the cloud server 20 introduces the self-system, the existing payment devices (the payment device 40 and the payment device 31) are used. ) Is added, but the cost at the time of introduction can be relatively suppressed. This is effective when it is determined that repair of the settlement device is easier than repair of the cloud server or the management device. In the example shown in FIG. 11, the cloud server 20 implements the selling price determination logic (sale price determining logics A, B, and C), but does not operate it.

In the shopping system according to the third embodiment shown in FIG. 13, the checkout device 40 may be a device newly installed (delivered) in a store in order to use the service provided by the cloud server 21. That is, the shopping system according to the third embodiment shown in FIG. 13 modifies the cloud server 20 (adds an external cooperation function) to the cloud server 21 when starting the use of the service by the cloud server 20, and originally, In order to modify the management device 11 installed in the store (add an external cooperation function) to the management device 12, and to use the service provided by the cloud server 21 separately from the settlement device 30 originally installed in the store. May be constructed by additionally introducing a settlement device 40, which is a new terminal having the functions required for the above (mobile terminal interlocking function, cloud communication function). In other words, the shopping system according to the third embodiment, when starting the use of the service by the existing external cloud server 20, for example, does not perform the repair on the existing payment device 31 and makes the connection with the existing cloud server 20. If the management device 11 is repaired, the service based on the cloud server 21 after the repair can be introduced in a short period of time simply by additionally installing the settlement device 40 as a new terminal. It was built.

Before the introduction of the self-system by the cloud server 20, the selling price determination logics (selling price determination logics A, B, C, D, and G) operated by the existing systems (the management device 11 and the settlement device 31) are: Since the cloud server 20 does not fall within the range of the selling price determination logic (selling price determination logics A, B, and C) that can be provided, when the cloud server 20 introduces a self-system, the cloud server 20 is modified to the cloud server 21 (external cooperation function). Is added), and the management device 11 is modified to the management device 12 (an external cooperation function is added), but the cost at the time of introduction can be relatively suppressed. This is effective when it is determined that the repair of the cloud server or the management device is easier than the repair of the settlement device. In the example illustrated in FIG. 13, the cloud server 21 implements the selling price determination logic (sale price determining logics A, B, and C), but does not operate it.

Although the cloud server 20 has been described as being modified (adding an external cooperation function) to be the cloud server 21, the cloud server 20 may originally have an external cooperation function. If the cloud server 20 has the external coordination function, in the shopping system of the third embodiment, the cloud server 20 does not need to be modified, so that the introduction cost is further reduced.

In general, the issues (barriers) when introducing a new system are as follows for each approach of introduction.
1. In the case of the approach of modifying and introducing an existing system, it is difficult to add a control of a smartphone communication unit, a basket storage unit, and the like to the existing system (a system must be created each time according to a store. You need to make as many systems).
2. On the other hand, in the case of an approach that leaves the existing system and starts it up as a separate system, it is difficult to create and operate the same selling price determination logic as the existing system. is there). It can be said that the selling price determination logic is based on the basic know-how and business spirit of the customer, so it is not easy to work according to the installation destination.
The above 1 and 2 are both large loads on both the store side and the system proposer side.

On the other hand, in the shopping system described in each embodiment, since the original selling price determination logic is used, the existing system is left as it is in any store (management devices 10, 11, 12). And operating the settlement devices 30 and 31), it is possible to coexist with the new system, and both the above-mentioned problems 1 and 2 can be solved.

Although the embodiments have been described above, the embodiments will be additionally described. For example, in the example shown in FIG. 17, a warning regarding merchandise cancellation is issued on the settlement apparatus 40 (the customer display unit 406 and the clerk display unit 410) (step S79 in FIG. 17). In addition to the above, by transmitting warning information to a clerk mobile terminal carried by a clerk, a warning about merchandise cancellation may be issued on the clerk mobile terminal, or a payment device (the payment device 30, the payment device 40). By transmitting warning information to a monitoring device (not shown) that monitors (41)), a warning regarding product cancellation may be issued on the monitoring portable terminal. Further, in the example shown in FIG. 17, the notification regarding the held product is performed on the settlement apparatus 40 (the customer side display unit 406 and the clerk side display unit 410) (step S83 in FIG. 17). In addition to the above, by transmitting correction instruction information and the like to the clerk mobile terminal, it may be possible to notify the held product on the clerk mobile terminal, or to transmit the correction instruction information and the like to the monitoring device Alternatively, the monitoring device may notify the user of the pending product.

In the above embodiment, each setting information referred to by each selling price determination logic may be information different from the product information or may be a part of the product information. For example, the cloud server 20 shown in FIG. 5 will be described as an example. The cloud server 20 is a unit price change information referred to by the selling price determination logic A and a single item discount setting referred to by the selling price determination logic B separately from the product information. The information and the subtotal discount setting information referred to by the selling price determination logic C may be stored. The product information stored by the cloud server 20 may be referred to by the selling price change information referenced by the selling price determination logic A and the selling price determination logic B. It may be information including single item discount setting information, or subtotal discount setting information referred to by the selling price determination logic C. Alternatively, the information of the selling price change referred to the selling price determining logic A may be inherent in the selling price determining logic A (the same applies to the selling price determining logics B and C). The same applies to the selling price decision management logic.

In the third embodiment, the settlement apparatus 41 includes selling price determination logics A, B, C, D, and G, but does not include product information. Therefore, in the case where the product information includes the setting information referred to by the selling price determination logic (in other words, the setting information is embedded in the selling price determination logic, or the product information is not included in the settlement apparatus 41). In a case where the setting information is not separately stored, that is, in a case where the settlement apparatus 41 does not hold the setting information in its own apparatus, the settlement apparatus 41 calculates the subtotal amount (by determining the selling price). When using the logic), the setting information (setting information included in the product information or setting information stored separately from the product information) stored in the cloud server 20 is referred to. When calculating the subtotal amount, the settlement apparatus 41 substitutes for or adds to the setting information stored in the cloud server 20 and sets the setting information (setting included in the product information) stored in the management apparatus 11. Information or setting information stored separately from the product information). When the information stored in the management device 11 is newer than the information stored in the cloud server 20 (when the information is reflected on the cloud server 20 side by batch processing), Information stored in the management device 11 may be referred to.

Also, in the above-described embodiment, the flow of the process after the completion of the merchandise item registration is such that the code displayed by the portable terminal 50 is read by the settlement apparatus 40 (41). However, another flow may be used. For example, the flow may be such that the calculation of the subtotal amount is started with the request from the mobile terminal 50 to the cloud server 20 (20) as a starting point (trigger).

For example, in the first embodiment, the portable terminal 50 acquires the device identification information (payment device number) of the settlement apparatus 40 that executes the settlement process, and the portable terminal 50 outputs the small calculation information together with the basket identification information and the device identification information. The request information may be transmitted to the cloud server 20, and the cloud server 20 may transmit the subtotal information including the subtotal amount calculated by the own apparatus to the settlement apparatus 40 identified by the apparatus identification information.
In the second embodiment, the mobile terminal 50 acquires the device identification information (payment device number) of the payment device 41 that executes the payment process, and the mobile terminal 50 transmits the product data request information together with the basket identification information and the device identification information. The data may be transmitted to the cloud server 20, and the cloud server 20 may transmit the product data in the basket to the settlement apparatus 41 identified by the apparatus identification information.
In the third embodiment, the mobile terminal 50 acquires the device identification information (payment device number) of the payment device 40 that executes the payment process, and the mobile terminal 50 sends the small calculation request information together with the basket identification information and the device identification information. May be transmitted to the cloud server 21, and the cloud server 21 may transmit the subtotal information including the subtotal amount calculated by the management apparatus 11 to the settlement apparatus 40 identified by the apparatus identification information.

In the above-described embodiment, when a hold product (reading NG) is performed, that is, when reading of the product fails (when a timeout process occurs), the mobile terminal 50 automatically releases the shutter and releases the product. Has been described (step S45 in FIG. 15), but when a reserved product (reading NG) is performed, the shutter is released at the timing of the customer (based on the operation of the customer). It may be. For example, the mobile terminal 50 may switch to the shutter operation mode by the customer when the reading of the product fails (when the timeout process occurs).

In the case of reading NG (the same applies to a self-declared product described later), in a case where the shutter is released based on the customer's operation, the customer is instructed to perform imaging (for example, a message is displayed on the registration screen). Display). When the shutter is released based on the operation of the customer (when the image data is acquired), the image data is automatically transmitted to the cloud server 20 (21) in the same manner as in the mode in which the shutter is automatically released. Alternatively, the image data may be transmitted to the cloud server 20 (21) based on a customer operation.

Also, in the above-described embodiment, an example has been described in which two types of NON-PLU and read NG are managed as pending products, but the types of pending products are not limited to the two types. For example, it may be managed as a self-declared product as a reserved product other than the above two types. The self-declared product is a product that is declared by the customer himself and is a reserved product. That is, if timeout processing is executed after imaging for a predetermined time, reading is NG, but if it takes time before timeout processing, the customer must keep the portable terminal 50 over the product. If it is not possible to wait for a timeout in such a situation, the customer may declare a pending product by his own judgment. For example, a hold declaration button may be arranged on the registration screen of the mobile terminal 50, and the operation (touch) of the hold declaration button may temporarily stop the barcode recognition process and switch to the shutter operation mode by the customer (actually). The barcode recognition process may be terminated when the shutter is released at the same time. Alternatively, the barcode recognition process may be terminated and the shutter may be released by operating (touching) the hold declaration button.

As described above, even in the case of a self-declared product, the image data is transmitted to the cloud server 20 (21) in order to obtain a captured image of the product (that is, to generate image data). The cloud server 20 (21) stores the reserved product information (for example, reserved product classification: 3 (self-declaration), image data) in the basket information.

In the case of a reserved product (read NG), the number of image data to be managed (the number of data) may be two or more. That is, the mobile terminal 50 acquires a plurality of captured images of the product in the time-out processing of the product (generates a plurality of image data), and the cloud server 20 (21) stores the image data of the product in a plural number. Is also good. The same applies to the case of a reserved product (self-declaration). In the case of a reserved product (self-declaration) and the shutter is released at the timing of the customer, the customer may be notified of the number of images to be captured (for example, displayed on a registration screen).

The settlement apparatus 40 (41) has two scanner units (the customer-side scanner unit 406 and the clerk-side scanner unit 412). However, the settlement apparatus 40 (41) has one scanner unit (the customer unit). The apparatus may be provided with the side scanner unit 406). The same applies to the settlement apparatus 30. The settlement apparatus 40 (41) can also execute a registration process in addition to the settlement process (for example, in addition to including the card settlement unit 408 and the change machine 409, the customer-side scanner unit 406 and the clerk-side scanner unit 412). Describes that a bar code attached to a product is scanned), but does not perform a registration process. A device dedicated to a payment process (a device dedicated to a payment process that performs a payment process for a product registered in another device). ). The same applies to the settlement apparatus 30.

In the case where the customer cancels the product (when the cancel operation is performed), the user is notified (notified on the display screen of the mobile terminal 50) that the canceled product is returned to the shelf (for example, the original display position). Good. In other words, when the product is canceled, the product is not only deleted in the basket of the cloud server 20 (21) or the display of the mobile terminal 50, but is also notified that the product is returned to the original shelf, and the display order of the store is maintained. Ask your customers to cooperate. In an actual store, a product whose purchase has been stopped for some reason may be left on a shelf different from the original one, so that it is effective as a warning to a customer with such poor manners.

情報 In addition, information (for example, basket information or the like) of the cloud server 20 (21) may be used as an electronic receipt. For example, the cloud server 20 (21) may have an electronic receipt output function. This allows the customer to check his / her own use history on the cloud, or download it to the portable terminal 50 or the like and save it as a transaction history.

The cloud server 20 (21) may transmit the usage history of the customer to the management device 10 (11, 12) by the same communication as the transmission and reception of the transmission / reception data “D0 (store information, product information)”. As a result, the management device 10 (11, 12) can save and manage not only the user who has completed the settlement in the existing system but also the usage history of the customer who has used the self-registration system. For example, transactions by the self-registration system can be integrated into a conventional electronic journal, and can be searched as in the conventional case. Note that each transaction mode may be managed by use mode identification information (also simply referred to as usage mode information) for identifying how each transaction was performed on the usage history.

(Usage status information)
Usage mode information "1 (normal)": transaction usage mode information corresponding to the clerk for both registration processing and settlement processing "2 (semi-self)": transaction usage mode in which the clerk handles registration processing and the customer performs the payment processing Information "3 (full self)": Transactions handled by customers for both registration and settlement (same equipment)
Usage mode information "4 (smartphone self)": Transactions handled by customers for both registration processing and settlement processing (separate equipment)

Also, the usage mode may be displayed on the display screen for confirming the usage history (electronic journal) or on the receipt printed at the store in an easily understandable manner. When the display area or the print area is small, only the initials such as “tsu”, “se”, “fu”, and “su” may be output. 1 "to" 4 ").

With the above ingenuity, the existing system side can grasp the usage status of the self-registration system, so the store status (information on the store such as sales, inventory management, usage history, etc.) can be checked without changing the conventional operation method. Can be. Since such coexistence can be realized with a small repair, the system described in the embodiment can be proposed to a user who is performing any operation.

Although the embodiments have been described above, the specific configuration is not limited to the contents described in the embodiments, and may include designs and the like that do not depart from the gist of the present invention. Hereinafter, supplementary notes A1 to A6 will be disclosed.
(Appendix A1)
The self-registration system of Appendix A1 is a self-registration system that cooperates with an external determination unit (for example, an existing selling price determination logic). Accumulating means for accumulating (for example, a basket area on a cloud server) and requesting means for requesting the external determining means to calculate a transaction amount based on the transaction information (for example, a request for requesting execution of a selling price determination logic. Exit request information).

According to the configuration of Appendix A1, the cost at the time of introduction can be reduced. Since the existing sales price determination logic can be used, it is not necessary to prepare the sales price determination logic according to the customer, and the number of steps (costs) to be introduced can be reduced. This also facilitates dissemination.
(Appendix A2)
The self-registration system according to supplementary note A2, wherein in the self-registration system according to supplementary note A1, the requesting unit reads out the transaction information by a settlement apparatus that displays the transaction amount after calculation, or the registration unit executes the transaction using the settlement apparatus. The request may be executed by reading the identification information.
According to the configuration of Appendix A2, it is possible to easily request the calculation of the transaction amount.
(Appendix A3)
The self-registration system according to Supplementary Note A3 is a self-registration system according to Supplementary Note A1 or A2, wherein the storage unit includes, in addition to the transaction information that can be registered to be settled, the transaction information that cannot be registered to be settled (the pending product in FIG. 7C). Information etc.) may also be accumulable.
According to the configuration of the supplementary note A3, it is possible to appropriately manage the transaction information that could not be registered so as to enable the settlement.
(Appendix A4)
The self-registration system according to Supplementary Note A4 is a self-registration system according to any one of Supplementary Notes A1 to A3, in which the settlement apparatus that displays the transaction amount after calculation informs that there is transaction information that could not be registered so that settlement is possible. Means may be provided.
According to the configuration of Supplementary Note A4, it is possible to recognize that there is transaction information that could not be registered so as to enable payment. For example, as the notification means, the customer may be notified of the existence of a reserved product or the arrival of a store clerk, and the store clerk may be notified of information on a payment device that should process the reserved product.
(Appendix A5)
The self-registration system according to Supplementary Note A5 is a self-registration system according to Supplementary Note A3 or A5, wherein the settlement device that displays the transaction amount after calculation corrects the transaction information that could not be registered to be receivable into transaction information that can be settled. Means may be provided.
According to the configuration of the supplementary note A5, the settlement process can be performed after the correction. By effectively utilizing and correcting the transaction information that could not be registered for payment, the payment process can be quickly performed. For example, the clerk makes the correction, and the customer performs the payment processing after the clerk makes the correction.
(Appendix A6)
The self-registration system according to Supplementary Note A6 is the self-registration system according to any one of Supplementary Notes A1 to A5, wherein the settlement device that displays the transaction amount after calculation reads the transaction information, The first payment device that starts the process related to payment by reading the information that identifies the payment device, and the transaction information that is generated by the registration operation of the clerk (acquires the transaction information generated by the registration operation of the clerk) And a second payment device that starts a process related to payment.
According to the configuration of Appendix A6, a self-registration system can be introduced while leaving the existing system as it is, and both systems can coexist. In other words, since the self-registration system can be introduced without excluding existing terminals and systems, development for all POS users can be performed. In addition, for example, the first payment device may be a payment device for a self-registration system introduced at the same time as the self-registration system, and the second payment device may be a second payment device originally used. The second payment device (similarly to the first payment device) may be any device that can at least perform payment processing. Therefore, for example, a device that can perform product registration processing in addition to the payment process may be used, or a payment device that can pay out products registered in another device may be used. If the registration process is possible, the registration process may be performed by a store clerk or performed by the customer himself.
(Appendix A7)
The self-registration method of Appendix A7 is a self-registration method that cooperates with an external determination means, and includes a registration step of registering a product, a storage step of storing registered transaction information, and a transaction amount based on the transaction information. And a requesting step of requesting the external determination step to perform the calculation.
(Appendix A8)
The settlement device in Appendix A8 is a settlement device that constitutes a self-registration system that cooperates with external determination means (for example, existing selling price determination logic), and includes transaction information registered by another device (for example, a mobile terminal). Request means for requesting the external determination means to calculate the transaction amount based on the transaction amount, and settlement means for performing settlement (for example, cash settlement) based on the transaction amount obtained by the request means. I do.
(Appendix A9)
The settlement method of Appendix A9 is a settlement method in a settlement device that constitutes a self-registration system that cooperates with an external determination unit, and calculates a transaction amount based on transaction information registered by another device. And a settlement step of performing a settlement based on the transaction amount obtained in the request step.
(Appendix A10)
The program of Appendix A10 is a program that causes a computer to function as a settlement apparatus that constitutes a self-registration system that cooperates with an external determination unit. The program calculates the transaction amount based on transaction information registered by another apparatus. Is a program that functions as request means for requesting the external decision means, and settlement means for making a payment based on the transaction amount obtained by the request means.
(Appendix A11)
The storage medium of Supplementary Note A11 is a storage medium that stores a program that causes a computer to function as a checkout device that constitutes a self-registration system that cooperates with an external determination unit. Functioning as a requesting means for requesting the external determination means to calculate a transaction amount based on the transaction information registered by the user, and a settlement means for performing a settlement (for example, a cash settlement) based on the transaction amount obtained by the requesting means A storage medium for storing a program for causing

There are cases where the various cloud servers 20 (21) actively determine the subtotal amount by the selling price determination logic while monitoring the usage status of the mobile terminal 50 and the settlement apparatus 40. For example, when the cloud server 20 (21) detects that “Proceed to checkout” is pressed on the mobile terminal 50, the selling price determination logic specifies the basket information of the user of the mobile terminal 50, and A subtotal amount can be determined. After that, the customer transmits the basket information and the subtotal amount to the settlement apparatus 40 that has read the QR code. Similarly, when the QR code is read by the settlement apparatus 40 and the cloud server 20 (21) detects the reading operation, the subtotal amount is actively determined by the selling price determination logic, and the determination result is transmitted to the settlement apparatus 40. be able to. As described above, the selling price determination logic is not limited to the case where the selling price determination logic is executed by a request from the settlement apparatus.

The exchange of the basket identification information between the portable terminal 50 and the settlement apparatus 40 is not limited to the two-dimensional code, but may be a bar code, wireless communication using RFID, NFC, Bluetooth (registered trademark), the portable terminal 50 or the settlement apparatus 40. Any method, such as wired communication between the portable terminal 50 and the settlement apparatus 40 via the connector prepared in the above, is not limited.

(4) When the customer who has completed the product registration uses the payment apparatus 40, it is not possible to determine which payment apparatus to use, for example, when the store is vast or all the payment apparatuses are in a queue. In such a situation, a guide device may be provided separately to guide an optimal settlement device in consideration of the most vacant, closest condition, and the like. When the mobile terminal 50 is provided with a guidance function, for example, when “Proceed to Checkout” is pressed, a payment device selection screen may be displayed and an arbitrary payment device may be reserved.

A program for realizing the

management devices

10, 11, 12, the

cloud servers

20, 21, the settlement devices 40, 41, and the portable terminal 50 described above is recorded on a computer-readable recording medium, and the program is The program may be read by a computer system and executed. Here, the “computer system” includes an OS and hardware such as peripheral devices. The “computer-readable recording medium” refers to a portable medium such as a flexible disk, a magneto-optical disk, a ROM, and a CD-ROM, and a storage device such as a hard disk built in a computer system. Further, the “computer-readable recording medium” refers to a volatile memory (RAM) inside a computer system that becomes a server or a client when a program is transmitted through a network such as the Internet or a communication line such as a telephone line. And those holding programs for a certain period of time. Further, the above program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in the transmission medium. Here, the "transmission medium" for transmitting a program refers to a medium having a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. Further, the program may be for realizing a part of the functions described above. Furthermore, what can implement | achieve the function mentioned above in combination with the program already recorded on the computer system, and what is called a difference file (difference program) may be sufficient.

10, 11, 12 ...

management devices

20, 21 ... cloud server 30 ... settlement devices 40, 41 ... settlement devices 50 ... portable terminals 401 ... CPU
402 ... ROM
403 ... RAM
404 hard disk 405 customer display unit 406 customer scan unit 408 card settlement unit 409 change machine 410 store display unit 411 key operation unit 412 salesclerk scanner unit 413 printing unit 414 audio output unit 415 ... communication unit

Claims

A self-registration system that works with external decision means,
Registration means for performing product registration;
Storage means for storing the registered transaction information;
Requesting means for requesting the external determining means to calculate a transaction amount based on the transaction information.
The request means,
The request is executed by a payment device that displays the transaction amount after the calculation reads the transaction information, or the registration unit reads information that identifies the payment device, and executes the request. Self-registration system described.
The accumulation means,
3. The self-registration system according to claim 1, wherein, in addition to the transaction information that can be settled, the transaction information that cannot be registered can be stored.
A settlement device that displays the transaction amount after calculation,
4. The self-registration system according to claim 3, further comprising a notifying unit for notifying that there is transaction information that could not be registered for payment.
A settlement device that displays the transaction amount after calculation,
The self-registration system according to claim 3, further comprising a correction unit configured to correct the transaction information that could not be registered to be able to be settled into transaction information that can be settled.
A first payment device that starts processing related to payment by reading the transaction information by a payment device that displays the transaction amount after calculation, or by reading information that identifies the payment device by the registration unit,
The self-registration system according to any one of claims 1 to 5, further comprising: a second payment device that starts processing related to payment when transaction information is generated by a clerk's registration operation. .
A self-registration method that works with external decision means,
A registration step for registering the product,
An accumulation step of accumulating the registered transaction information;
Requesting the external decision step to calculate a transaction amount based on the transaction information.