Transaction processing system, transaction processing device, and information processing program

Abstract

To reduce the burden on an employee related to replenishment operations.SOLUTION: A transaction processing system comprises registration means, determination means, and notification means. The registration means registers commodities designated by a mobile terminal as transaction commodities to be targets of transaction. When a report instruction targeted to one of the transaction commodities registered by the registration means is performed by an operation of the mobile terminal, the determination means determines a transaction commodity targeted by the report instruction. The notification means performs predetermined notification processing for notifying a predetermined notification destination that the same commodity as the transaction commodity determined by the determination means should be replenished to a display place.SELECTED DRAWING: Figure 9

Description

Technical Field

[0001] Embodiments of the present invention relate to a transaction processing system, a transaction processing device, and an information processing program.

Background Art

[0002] In a store that sells products by displaying them, monitoring the display status of products on display shelves and replenishing products with reduced quantities is a burden on employees. Under such circumstances, it has been desired to reduce the burden on employees involved in replenishment work.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The problem to be solved by the present invention is to provide a transaction processing system, a transaction processing device, and an information processing program capable of reducing the burden on employees involved in replenishment work.

Means for Solving the Problems

[0005] The transaction processing system according to the embodiment includes a registration unit, a determination unit, and a notification unit. The registration unit registers a product specified by a mobile terminal as a transaction product to be the subject of a transaction. The determination unit, when a notification instruction targeting any one of the transaction products registered by the registration unit is made by an operation on the mobile terminal, determines the Trading products registered via the registration method immediately before the notification instruction transaction product targeted by do the notification instruction. The notification unit performs a predetermined notification process for notifying a predetermined notification destination that the same product as the transaction product determined by the determination unit should be replenished to the display location. Subject to reporting instructions [Brief explanation of the drawing]

[0006] [Figure 1] A block diagram showing the schematic configuration of a transaction processing system 1 according to one embodiment. [Figure 2] A block diagram showing the main circuit configuration of the transaction processing device in Figure 1. [Figure 3] This diagram schematically represents the structure of a single data record included in the store database shown in Figure 2. [Figure 4] This diagram schematically represents the structure of a single data record included in the notification history database shown in Figure 2. [Figure 5] A schematic diagram showing the structure of transaction data in Figure 2. [Figure 6] A block diagram showing the main circuit configuration of the user terminal in Figure 1. [Figure 7] A flowchart of user terminal processing. [Figure 8] A flowchart for smartphone POS processing. [Figure 9] A flowchart for smartphone POS processing. [Figure 10] A diagram showing the first registration screen. [Figure 11] A diagram showing the product scanning screen. [Figure 12] A diagram showing the registration confirmation screen. [Figure 13] A diagram showing the second registration screen. [Figure 14] A diagram showing the first notification guidance screen. [Figure 15] A diagram showing an example of the first registration screen. [Figure 16] A sequence diagram illustrating the processing flow following a notification of out-of-stock items. [Modes for carrying out the invention]

[0007] An example of an embodiment will be described below with reference to the drawings. Figure 1 is a block diagram showing the schematic configuration of the transaction processing system 1 according to this embodiment. The transaction processing system 1 is configured to enable communication among a transaction processing device 100, a user terminal 200, a cart terminal 300, a corporate server 400, an in-store Web client 500, an in-store POS 600, an accounting machine 700, and an employee terminal 800 via a communication network 2.

[0008] The transaction processing device 100 is an information processing device that performs information processing to provide a transaction processing service for processing a merchandise purchase and sale transaction between a user and a store according to operations performed by a store user at the store using the user terminal 200, the cart terminal 300, and the accounting machine 700 as user interface terminals. That is, typically, a customer who purchases merchandise at a store becomes a user of the transaction processing service. The transaction processing device 100 is realized, for example, as a cloud server and provides the transaction processing service at multiple stores. The transaction processing device 100 may also be realized, for example, as a local server and provide the transaction processing service at only one store.

[0009] The user terminal 200 is an information communication device held by a user. The user terminal 200 is typically owned by the user and brought into the store by the user for use. The user terminal 200 is a user interface terminal that receives operations by the user for transaction processing at the transaction processing device 100. The user terminal 200 may also be temporarily lent to the user by the store.

[0010] The cart terminal 300 is an information processing terminal attached to a shopping cart provided in a store. The cart terminal 300 is lent to the user together with the shopping cart. The cart terminal 300 is a terminal device that receives operations by the user for transaction processing at the transaction processing device 100. The corporate server 400 is an information processing device that performs information processing for information management and the like in a company that operates a store in which the in-store system shown in FIG. 1 is constructed.

[0011] The in-store Web client 500, the in-store POS 600, the accounting machine 700, and the employee terminal 800 belong to an in-store system constructed within a single store. The in-store Web client 500 is an information processing device that performs information processing for using Web services such as cloud services provided by the transaction processing device 100 in the in-store system.

[0012] The in-store POS 600 is a conventional system that performs transaction processing using a store-installed device different from the user terminal 200 or the cart terminal 300, such as a face-to-face type, self-service type, or semi-self-service type. The accounting machine 700 is installed in the store and executes accounting processing related to the accounting of transactions processed by the transaction processing device 100. The accounting machine 700 receives an operation by an operator during accounting processing. That is, the accounting machine 700 is a terminal device that receives operations of users related to accounting. The operator of the accounting machine 700 is mainly a user. In some cases, a store employee may be the operator of the accounting machine 700.

[0013] The employee terminal 800 is an information processing terminal operated by store employees. The employee terminal 800 is a terminal device for a user interface related to information processing to support employees who perform replenishment operations of products to store display shelves and the like. The employee terminal 800 includes a display device that performs screen display for presenting information to employees and an input device for inputting various instructions by employees. As the employee terminal 800, for example, a GOT (graphic order terminal), an HTL (handy terminal), a tablet terminal, a smart device, etc. are used.

[0014] Communication network 2 can use the internet, VPN (virtual private network), LAN (local area network), public communication network, mobile communication network, etc., individually or in appropriate combinations. As an example, communication network 2 may be used in combination with the LAN, the internet, and a mobile communication network. For communication between the transaction processing device 100 and the user terminal 200, for example, a mobile communication network and the internet are used. For communication between the transaction processing device 100 and the cart terminal 300, for example, a LAN installed in the store and the internet are used. For communication between the transaction processing device 100 and the corporate server 400, or between the corporate server 400 and the in-store web client, for example, the internet is used. For communication within the in-store system, for example, a LAN installed in the store is used.

[0015] Note that the transaction processing device 100, user terminal 200, cart terminal 300, corporate server 400, in-store web client 500, in-store POS 600, accounting machine 700, and employee terminal 800 may each be included in any number in the transaction processing system 1, but only one of each is shown in Figure 1. For example, the transaction processing system 1 may include multiple in-store systems operated by one company, and further may include one or more corporate servers 400 related to that company. Alternatively, for example, the transaction processing system 1 may include multiple in-store systems operated by different companies, and further may include one or more corporate servers 400 related to each of those companies.

[0016] Figure 2 is a block diagram showing the main circuit configuration of the transaction processing device 100. The transaction processing device 100 includes a processor 101, a main storage unit 102, an auxiliary storage unit 103, a communication unit 104, and a transmission line 105, etc. The processor 101, the main storage unit 102, the auxiliary storage unit 103, and the communication unit 104 are able to communicate with each other via the transmission line 105.

[0017] By connecting the processor 101, the main storage unit 102, and the auxiliary storage unit 103 with a transmission line 105, a computer is configured to perform information processing for controlling the transaction processing device 100. The processor 101 corresponds to the central part of the computer described above. The processor 101 performs information processing to control each part in order to realize various functions as a transaction processing device 100, in accordance with information processing programs such as the operating system and application programs.

[0018] The main memory unit 102 corresponds to the main memory portion of the computer described above. The main memory unit 102 includes a read-only memory area and a rewritable memory area. The main memory unit 102 stores a portion of the information processing program described above in the read-only memory area. The main memory unit 102 may also store data necessary for the processor 101 to perform processing to control each part in the read-only memory area or the rewritable memory area. The main memory unit 102 uses the rewritable memory area as a work area for the processor 101.

[0019] The auxiliary storage unit 103 corresponds to the auxiliary storage portion of the computer described above. The auxiliary storage unit 103 can utilize, for example, an EEPROM (electric erasable programmable read-only memory), an HDD (hard disk drive), an SSD (solid state drive), or various other well-known storage devices. The auxiliary storage unit 103 stores data used by the processor 101 in performing various processes and data generated by the processing performed by the processor 101. The auxiliary storage unit 103 may also store the information processing program described above. In this embodiment, the auxiliary storage unit 103 stores the transaction processing program PRA, which is one of the information processing programs. The transaction processing program PRA is an application program that describes the procedure for transaction processing, which will be described later. A portion of the storage area of ​​the auxiliary storage unit 103 is used as an area for storing the store database DBA, the notification history database DBB, and the transaction data DAA. The store database DBA is a database for managing stores that provide transaction processing services by the transaction processing device 100. The notification history database DBB is a database for managing the history of out-of-stock notifications, which will be described later. Transaction data (DAA) is data that represents the details of a single transaction.

[0020] The communication unit 104 performs communication processing for data communication via the communication network 2. For example, an existing wired communication device for the internet can be used as the communication unit 104. Alternatively, a wireless communication device connected to the communication network 2 via wireless communication may be used as the communication unit 104, either in place of or in addition to the wired communication device. The transmission line 105 includes an address bus, a data bus, and control signal lines, and transmits data and control signals exchanged between the connected parts.

[0021] Figure 3 schematically represents the structure of a single data record REA included in the store database DBA. The store database DBA is a collection of data records REA associated with each store that provides transaction processing services by the transaction processing unit 100.

[0022] The data record REA includes fields FAA, FAB, and FAC. Field FAA contains the store code, which serves as an identifier to identify the associated store. Field FAB contains various store data necessary for the associated store to provide transaction processing services. The store data may include information representing settings related to out-of-stock notifications, as described later. Field FAC contains reward data representing the rules for granting rewards for out-of-stock notifications, as described later, at the associated store.

[0023] Figure 4 is a schematic diagram illustrating the structure of a single data record REB included in the notification history database DBB. The notification history database DBB is a collection of data records REB associated with each individual missing item notification, as described later.

[0024] The data record REB includes the fields FBA, FBB, FBC, and FBD. The FBA field contains the notification code, which serves as an identifier to identify each out-of-stock notification. The FBB field contains the product code of the product that was the subject of the out-of-stock notification. The FBC field contains truth / false data indicating whether the out-of-stock notification is true or false, or unverified. The FBD field contains the user code of the user who specified the out-of-stock notification.

[0025] Figure 5 is a schematic diagram illustrating the structure of the transaction data DAA. The transaction data DAA includes fields FCA, FCB, and FCC. The transaction data DAA may include any number of fields from field FCD onward. Field FCA is set to the transaction code as the identifier of the transaction in question. Field FCB is set to the terminal code as the identifier of the user terminal 200 or cart terminal 300 used by the user performing the transaction in question. Field FCC is set to the user code as the identifier of the user performing the transaction in question. If there are registered products (hereinafter referred to as transaction products) that are the subject of the transaction in question, fields FCD, FCE, ... associated with each transaction product are added to the transaction data DAA. Fields FCD, FCE, ... each contain product data for a separate transaction product. The product data includes the product code and quantity as identifiers for the transaction product in question. The product data may also include various other information such as product name, unit price, tax category, and discount information.

[0026] Now, as the hardware for the transaction processing device 100, for example, a general-purpose server device can be used. Generally, the transfer of the transaction processing device 100 is carried out with the transaction processing program PRA stored in the auxiliary storage unit 103. However, the hardware and the transaction processing program PRA may be transferred separately, either in a state where the transaction processing program PRA is not stored in the auxiliary storage unit 103, or in a state where a different version of the same type of application program is stored in the auxiliary storage unit 103. The transaction processing device 100 may be configured by writing the transaction processing program PRA to the auxiliary storage unit 103 in response to an operation by any operator. The transfer of the transaction processing program PRA can be carried out by recording it on a removable recording medium such as a magnetic disk, magneto-optical disk, optical disk, or semiconductor memory, or by communication over a network.

[0027] Figure 6 is a block diagram showing the main circuit configuration of the user terminal 200. The user terminal 200 includes a processor 201, a main memory unit 202, an auxiliary memory unit 203, a touch panel 204, a camera 205, a wireless communication unit 206, and a transmission line 207, among other things.

[0028] The general functions of the processor 201, main memory unit 202, auxiliary memory unit 203, and transmission line 207 are equivalent to those of the processor 101, main memory unit 102, auxiliary memory unit 103, and transmission line 105. However, the auxiliary storage unit 203 stores the user terminal program PRB instead of the transaction processing program PRA. The user terminal program PRB is an application program that describes the information processing procedures for the processor 201 to operate the user terminal 200 as a user interface for transaction processing by the transaction processing device 100.

[0029] The touch panel 204 displays a screen for presenting information to the operator. The touch panel 204 also accepts input from the operator through touch operations on the screen. The camera 205 includes an optical system and an image sensor, and the image sensor generates image data representing the image within the field of view formed by the optical system.

[0030] The wireless communication unit 206 performs communication processing for data communication via the communication network 2. For example, an existing wireless communication device for a wireless LAN can be used as the wireless communication unit 206. Alternatively, a communication unit connected to the communication network 2 via a wired connection may be used instead of, or in addition to, the wireless communication unit 206. The basic hardware of the user terminal 200 is expected to be, for example, smartphone hardware.

[0031] The main circuit configuration of the cart terminal 300 is substantially the same as that shown in Figure 6, for example, so its illustration and explanation are omitted. However, it is assumed that the basic hardware of the cart terminal 300 will be the hardware of a tablet computer. Also, the cart terminal program will be used instead of the user terminal program PRB. The cart terminal program is an application program that describes the information processing procedures for operation as a user interface for transaction processing by the transaction processing device 100, similar to the user terminal program PRB.

[0032] A general-purpose information processing device for servers can be used as the basic hardware for the corporate server 400. A general-purpose information processing device for clients can be used as the basic hardware for the in-store web client 500. Existing devices can be used for the accounting machine 700 and employee terminal 800. Therefore, diagrams and explanations of the configurations of the corporate server 400, in-store web client 500, accounting machine 700, and employee terminal 800 are omitted.

[0033] Next, the operation of the transaction processing system 1 configured as described above will be explained. Note that the content of the various processes described below is merely an example, and it is possible to change the order of some processes, omit some processes, or add other processes as appropriate. For example, in the following explanation, some processes have been omitted in order to clearly illustrate the characteristic operation of this embodiment. For example, if an error occurs, processing to deal with that error may be performed, but such processing has been omitted from the description.

[0034] As described below, the services provided to users by the transaction processing system 1 are referred to as the smartphone POS service when the user uses the user terminal 200, and as the cart POS service when the user uses the cart terminal 300. However, since the out-of-stock notification, which is a characteristic feature of this embodiment, is implemented similarly for both the smartphone POS service and the cart POS service, the following description will focus on the smartphone POS service.

[0035] To use the smartphone POS service, users must install the user terminal program PRB on their own smartphone or other information processing device and make it available as a user terminal 200. Users must also register for the user terminal program PRB and obtain a user code. The user code is stored in the auxiliary storage unit 203 of the user terminal 200 as one of the setting data related to the user terminal program PRB. The user then enters a store that provides the smartphone POS service with the user terminal 200, which has the processor 201 executing user terminal processing according to the user terminal program PRB.

[0036] Figure 7 is a flowchart of the user terminal processing. As ACT201, processor 201 displays the top screen on touch panel 204. The top screen is a screen that allows the user to specify the function to be executed from among the various functions realized by user terminal processing. The top screen represents soft keys for receiving check-in instructions.

[0037] Stores that offer the smartphone POS service will display a check-in code, which represents the check-in data, at the store entrance or inside the store. The check-in code is, for example, a 2D barcode. The check-in data includes at least the store code. Therefore, the check-in code will be different for each store. If a user wants to start using the smartphone POS service at a store, they will perform predetermined actions, such as tapping a soft key displayed on the top screen, to receive instructions to check in.

[0038] As ACT202, processor 201 displays the top screen and waits for some kind of operation from the user. If any operation from the user is detected, for example, by touch panel 204, processor 201 determines it to be YES and proceeds to ACT203.

[0039] As ACT203, processor 201 verifies whether the operation performed was an operation for a check-in instruction. If processor 101 cannot confirm the event, it determines NO, verifies the content of the operation, and proceeds to other processes to perform the appropriate action. One example of other processes is the process of changing user settings related to the user terminal program PRB according to the user's instructions. Other processes may be performed selectively, or different processes from those mentioned above, but a detailed explanation of these will be omitted here.

[0040] If the operation to instruct the check-in has been performed as described above, processor 201 will determine YES in ACT203 and proceed to ACT204. As ACT204, processor 201 displays the check-in screen on touch panel 204. The check-in screen is designed to guide the user to take a picture of the check-in code with the camera 205 of user terminal 200. As ACT205, processor 201 waits for some action to be taken by the user. If processor 201 confirms that some action has been taken by the user, it determines YES and proceeds to ACT206.

[0041] The user operates the user terminal 200 according to the check-in screen and has the camera 205 of the user terminal 200 take a picture of the check-in code displayed at the store they are using. When the 2D barcode is captured by the camera 205 in this manner, the processor 201 determines YES in ACT205, indicating that an operation to read the 2D barcode has been performed, and proceeds to ACT206.

[0042] As ACT206, processor 201 checks whether the check-in coder was read by the operation performed above. If processor 201 cannot confirm the event, it determines NO, checks the content of the operation, and proceeds to other processes to perform the appropriate action. As one of these other processes, processor 201 may check if an operation to read a 2D barcode has been performed, but the 2D barcode in question is not the check-in code, and then display a screen to notify the user of such an operational error. Other processes may be performed separately from the above, or multiple processes may be performed selectively, but a detailed explanation of these will be omitted here.

[0043] If the check-in code has been captured by the camera 205, the processor 201 determines in ACT206 that the check-in code has been read by the operation performed above, and proceeds to ACT207. As ACT207, processor 201 requests a check-in from transaction processing unit 100. For example, processor 201 sends request data for the check-in request from wireless communication unit 206 to communication network 2 addressed to transaction processing unit 100. Processor 201 includes check-in data represented by the check-in code captured by camera 205, as well as the terminal code and user code in the above request data. The terminal code is stored, for example, in auxiliary storage unit 203. As the terminal code, for example, an identifier determined by the operating system of user terminal 200 when installing the user terminal program PRB can be used. This identifier is, for example, a 32-digit code containing a mixture of alphanumeric characters. The user code is stored in auxiliary storage unit 203 as described above. However, the user code does not need to be stored in auxiliary storage unit 203, and may be specified by the user each time a check-in is performed.

[0044] When request data for a check-in request is transmitted to the transaction processing unit 100 via the communication network 2, the transaction processing unit 100 receives the request data via the communication unit 104 and temporarily stores it in the main storage unit 102 or the auxiliary storage unit 103. In this manner, when the request data sent from the user terminal 200 is received by the transaction processing device 100, the processor 101 starts transaction processing for the smartphone POS service (hereinafter referred to as smartphone POS processing) according to the transaction processing program PRA.

[0045] However, this check-in procedure is merely an example, and various modifications are possible. For example, the processor 201 of the user terminal 200 may, after the user terminal program PRB is started, send check-in data including location information acquired using GPS (global positioning system) or other positioning sensors to the transaction processing device 100. When the transaction processing device 100 receives the above location information, it may, for example, retrieve the store information of the store where the user terminal 200 that sent the location information is located from a database that represents store information associated with the location information, and perform the check-in process according to this store information.

[0046] If processor 101 is already executing a smartphone POS process for a transaction involving a different user, it will start a new smartphone POS process as a separate thread from the existing one. In other words, processor 101 may execute multiple smartphone POS processes in parallel. In this case, there will be multiple user terminals 200 that the transaction processing unit 100 uses as user interface terminals simultaneously. However, the following explanation will focus only on the processing of a transaction involving a single user. Thus, in the following explanation, "user terminal 200" refers to a single user terminal 200 used by a user for the smartphone POS process under consideration. Also, in the following explanation, "transaction" refers to the transaction that is the subject of the process under consideration.

[0047] Figures 8 and 9 are flowcharts of smartphone POS processing. In Figure 8, as ACT101, processor 101 checks whether the user terminal 200 attempting to check in is able to use the smartphone POS service. For example, if the smartphone POS service is not available during the time period when the store where the check-in is being attempted is not open, or if any other predetermined availability conditions are not met, the smartphone POS service cannot be used. If processor 101 cannot determine that it is available, it determines NO and proceeds to ACT102.

[0048] As ACT102, processor 101 instructs user terminal 200 to display an unavailable screen in response to the check-in request. The unavailable screen is a screen that makes the user aware that they cannot use the smartphone POS service. For example, processor 101 sends instruction data from communication unit 104 to communication network 2 to user terminal 200 to instruct user terminal 200 to display an available screen. After this, processor 101 terminates the smartphone POS processing.

[0049] When instruction data for screen display instructions is transmitted to the user terminal 200 via the communication network 2, the wireless communication unit 206 in the user terminal 200 receives the instruction data. Upon receiving the instruction data, the wireless communication unit 206 notifies the processor 201 of this fact.

[0050] The instruction data for instructing screen display may include screen data representing the screen to be displayed according to the instruction data, or it may not include such screen data but may include data that allows the user terminal 200 to identify the screen to be displayed. In the former case, the processor 101, for example, generates screen data representing the screen to be displayed on the user terminal 200 and includes said screen data in the instruction data. In the latter case, the processor 101 includes in the instruction data, for example, a screen identifier predetermined to identify the screen to be displayed on the user terminal 200, or a notification identifier that identifies the notification that triggers the screen display. The notification identifier is, for example, information predetermined to identify a notification such as "unavailable".

[0051] On the user terminal 200, the processor 201 requests a check-in at ACT207 in Figure 7, and then proceeds to ACT208. As ACT208, processor 201 waits for a response to the check-in request. If instruction data instructing the display of some screen is received by wireless communication unit 206, processor 201 determines that a response has been made, and proceeds to ACT209.

[0052] As ACT209, processor 201 checks whether the display of the registration screen, described later, has been instructed. If, as mentioned above, the display of the unavailable screen has been instructed, processor 201 determines NO and proceeds to other processes to perform the processing corresponding to the screen that has been instructed to be displayed. As one of these other processes, processor 201 may, for example, display the unavailable screen on touch panel 204 and return to ACT201 after a predetermined confirmation operation has been performed. Other processes may include processes different from those described above, or multiple processes may be selectively performed, but a detailed explanation of these will be omitted here.

[0053] Furthermore, if the instruction data that instructs the display of a screen includes screen data, the processor 201 displays the screen represented by that screen data directly on the touch panel 204. If the received instruction data includes a screen identifier, the processor 201 generates the screen identified by that screen identifier and displays it on the touch panel 204. If the received instruction data includes a notification identifier, the processor 201 determines which screen should be displayed according to the notification identified by that notification identifier, generates the corresponding screen, and displays it on the touch panel 204. The exchange of instructions for displaying the various screens described below is carried out using the same procedure as above, although the content of the screens being displayed may differ.

[0054] On the other hand, if processor 101 is confirmed to be available in ACT101 in Figure 8, it determines YES and proceeds to ACT103. As ACT103, processor 101 generates new transaction data. That is, processor 101 determines a new transaction code that is different from the transaction code used to identify other transactions, according to predetermined rules. Processor 101 sets this new transaction code in field FCA and generates new transaction data DAA by setting the terminal code received along with the check-in data in field FCB, and stores it in auxiliary storage unit 103. As mentioned above, user terminal 200 includes the user code in the request data when making a check-in request. Also, if the cart terminal 300 was able to obtain the user code because the user performed user authentication when the user started using it, it includes the user code in the request data when making a check-in request. Thus, in these cases, processor 101 sets the user code in field FCC of the newly generated transaction data DAA. However, if use of the cart terminal 300 by a user who has not registered is permitted, the cart terminal 300 may not include the user code in the request data when making a check-in request. In this case, the processor 101 sets the FCC field of the newly generated transaction data DAA to a predetermined state, such as null, to indicate that the user code has not been obtained.

[0055] As ACT104, processor 101 instructs user terminal 200 to display the first registration screen in response to the check-in request. The first registration screen includes a list of products already registered as trading products and is a screen that allows the user to recognize the registration status of trading products. For example, processor 101 generates screen data representing the first registration screen that reflects the registration status of trading products, and includes this screen data in the instruction data to instruct user terminal 200 to display the screen. As mentioned above, processor 101 may also include a screen identifier for the registration screen or a notification identifier that identifies the notification "Check-in confirmation complete" in the instruction data instead of including the screen data. The generation of the first registration screen may be performed by processor 201 on user terminal 200.

[0056] If the processor 201 in the user terminal 200 receives instruction data for displaying the first registration screen and determines YES at ACT208 in Figure 7, and proceeds to ACT209, it determines YES again because it is an instruction to display the first registration screen, and proceeds to ACT210. As ACT210, processor 201 displays the first registration screen on touch panel 204.

[0057] Figure 10 is a diagram representing the first registration screen SCA. The first registration screen SCA has an image representing the registration status placed in the display area ARA. The first registration screen SCA represents buttons BUA and BUB. In the example in Figure 10, the image placed in the display area ARA does not represent specific information about the trading product because the trading product has not yet been registered, and instead shows a total of 0 points and a reference price of 0 yen.

[0058] Button BUA is a soft key for initiating the scanning of a new product. Button BUB is a soft key for initiating the checkout process. Note that the first registration screen SCA and the various screens described later illustrate the main display objects, but may omit the illustration of some display objects. For example, the screen may include images to help the user visualize the operations they should perform. Furthermore, the first registration screen SCA and the various screens described later are examples and may be determined as appropriate by, for example, the creator of the transaction processing program PRA.

[0059] Once the processor 201 displays the first registration screen SCA on the touch panel 204, it proceeds to ACT211 in Figure 7. As ACT211, processor 201 waits for some kind of operation to be performed by the user. If any operation by the user is detected by touch panel 204, processor 201 determines it to be YES and proceeds to ACT212.

[0060] As ACT212, processor 201 checks whether it is necessary to notify the transaction processing unit 100 of the operation that has been performed. If the operation performed is not one of the operations predetermined to be subject to notification, processor 201 determines NO, checks the content of the operation, and proceeds to other processes to perform the appropriate action. As one of the other processes, processor 201 may scroll the registration screen in response to a scroll operation. Other processes may be performed separately from the above, or multiple processes may be performed selectively, but a detailed explanation of these will be omitted here.

[0061] On the other hand, if the operation performed by processor 201 is one of the operations predetermined to be subject to notification, it determines YES in ACT212 and proceeds to ACT213. As ACT213, the processor 201 notifies the transaction processing unit 100 of the operation details. For example, the processor 201 sends notification data for notifying the operation details from the wireless communication unit 206 to the transaction processing unit 100 via the communication network 2.

[0062] When notification data for informing the details of an operation is transmitted to the transaction processing unit 100 via the communication network 2, the communication unit 104 in the transaction processing unit 100 receives the notification data. Upon receiving the notification data, the communication unit 104 notifies the processor 101 of this fact. The sending and receiving of notifications regarding the operations on the various screens described below will be performed using the same procedure as above, although the operations themselves may differ.

[0063] After the processor 101 instructs the display of the first registration screen as ACT104 in Figure 8, it proceeds to ACT105. As ACT105, the processor 101 waits for an operation to be performed on the user terminal 200. Then, if the processor 101 receives notification from the communication unit 104 that it has received notification data to inform the user of the operation details as described above, it determines YES and proceeds to ACT106. As ACT106, processor 101 checks whether the operation performed was an operation that specified the start of a scan. If processor 101 cannot confirm the event, it determines NO and proceeds to ACT107.

[0064] As ACT107, processor 101 checks whether the operation performed was an operation to specify the start of accounting. If processor 101 cannot confirm the event, it determines NO, checks the content of the operation, and proceeds to other processes to perform the appropriate action. As one of the other processes, processor 101 checks whether an operation to specify transaction cancellation was performed, executes the process to cancel the transaction, and then terminates the registration process. Other processes may include processes other than those described above, or multiple processes may be selectively performed, but a detailed explanation of these will be omitted here.

[0065] The user searches for the product they wish to purchase, i.e., the product to be traded, within the store. If the user wishes to register the product as a new transaction item, they perform a predetermined operation to specify the start of a scan, such as tapping the BUA button on the first registration screen, SCA. This operation is subject to notification, and the processor 201 on the user terminal 200 determines YES in both ACT211 and ACT212 in Figure 7, proceeds to ACT213, and sends notification data to notify the user of the operation to specify the start of a scan.

[0066] Once the operation to specify the start of the scan has been notified from the user terminal 200 to the transaction processing unit 100, the processor 101 determines YES at ACT106 in Figure 8 and proceeds to ACT108. As ACT108, processor 101 instructs user terminal 200 to display the product scan screen. The product scan screen is a screen for scanning a barcode representing the product code.

[0067] On the user terminal 200, the processor 201 notifies the user of the operation details via ACT213 in Figure 7, and then proceeds to ACT214. As ACT214, the processor 201 waits for a display instruction. Then, if the processor 201 receives instruction data from the transaction processing unit 100 instructing the display of some screen, and this is received by the wireless communication unit 206, it determines it is YES and proceeds to ACT215.

[0068] As ACT215, processor 201 updates the display screen on touch panel 204 according to the instructions. In other words, when instructed to display the product scan screen, processor 201 updates the display screen on touch panel 204 to the product scan screen. After this, processor 201 returns to the standby state of ACT211.

[0069] Figure 11 is a diagram representing the product scanning screen (SCB). The product scan screen (SCB) includes a display area (ARB) and a button (BUC). The display area (ARB) is an area for displaying images obtained by camera 205. The button (BUC) is a soft key for the user to declare that they want to stop scanning the product code.

[0070] When the processor 201 displays the product scan screen SCB on the user terminal 200, it activates the camera 205 and overlays the image obtained by the camera 205 onto the display area ARB. However, if a predetermined operation to specify the start of scanning is performed, the processor 201 may generate the product scan screen SCB and display it on the touch panel 204 without notifying the transaction processing unit 100 of the operation. In this case, the processor 101 in the transaction processing unit 100 performs the process of ACT110 (described later) as ACT106, and if it determines YES in ACT106, it proceeds to ACT111 (described later) without performing ACT108 to ACT110 (described later).

[0071] When the product scan screen (SCB) is displayed on the touch panel (204), the user operates the user terminal (200) so that the barcode displayed on the product to be registered as a transaction item is captured within the display area (ARB). The processor (201) analyzes the image obtained by the camera (205) and attempts to read the barcode. If the barcode is read, the processor (201) determines that the operation to read such a barcode is subject to notification. Therefore, the processor (201) determines YES in both ACT (211) and ACT (212) in Figure 7 and proceeds to ACT (213), notifying the transaction processing device (100) that a scan operation has been performed, along with the notification of the data represented by the read barcode (hereinafter referred to as barcode data).

[0072] Furthermore, if a user wants to cancel the registration of a trading product and check its registration status, they perform a predetermined operation to specify the cancellation of the scan, such as tapping the BUC button on the product scan screen SCB. This operation is notifiable, and the processor 201 determines YES in both ACT211 and ACT212 in Figure 9 and proceeds to ACT213, notifying the transaction processing unit 100 that the operation to cancel the scan has been performed.

[0073] Once the processor 101 in the transaction processing unit 100 has finished instructing the display of the product scan screen as ACT108 in Figure 8, it proceeds to ACT109. As ACT109, processor 101 waits for an operation to be performed on user terminal 200. If the user terminal 200 notifies processor 101 of the operation details, it determines it is YES and proceeds to ACT110.

[0074] As ACT110, processor 101 verifies whether the operation performed was for specifying a product. If processor 101 cannot confirm the event, it determines NO, verifies the content of the operation, and proceeds to other processes to perform the appropriate action. As one of these other processes, processor 101 verifies that an operation to cancel the scan was performed, such as tapping button BUC, and returns to ACT104, returning the display screen of the touch panel 204 on the user terminal 200 to the first registration screen SCA. Other processes may include processes different from those described above, or multiple processes may be selectively performed, but a detailed explanation of these will be omitted here.

[0075] Furthermore, the operation to cancel the scan is not subject to notification from the user terminal 200. Instead, the process of returning the display screen of the touch panel 204 on the user terminal 200 to the first registration screen SCA, as described above, may be autonomously executed by the processor 201 on the user terminal 200 after it determines NO in ACT212 in Figure 7.

[0076] As described above, if the processor 101 receives barcode data and the barcode data represents a product code, it determines YES in ACT 110, indicating that an operation to specify a product has been performed, and proceeds to ACT 111. As ACT111, processor 101 determines which products should be traded based on the notified barcode data. That is, processor 101 extracts the product code contained in the barcode data and determines which products identified by that product code should be traded (hereinafter referred to as candidate products). Processor 101 may also determine which products are assigned to which preset buttons are candidate products upon receiving notification from user terminal 200 that an operation has been performed to tap a preset button displayed on touch panel 204. Alternatively, processor 101 may also determine which products are candidate products upon receiving notification from user terminal 200 of a product code directly entered as a numerical string on touch panel 204.

[0077] As ACT112, processor 101 instructs user terminal 200 to display a registration confirmation screen. The registration confirmation screen is a screen for confirming whether or not to register the candidate product as a trading product. Processor 101 may include screen data representing the registration confirmation screen in the instruction data for instructing the display of the registration confirmation screen, or it may include candidate product data and have the user terminal 200 generate the registration confirmation screen using processor 201. When the processor 201 in the user terminal 200 receives instruction data for displaying the registration confirmation screen, it determines YES at ACT214 in Figure 8 and proceeds to ACT215, updating the display screen of the touch panel 204 to the registration confirmation screen.

[0078] Figure 12 is a diagram representing the registration confirmation screen (SCC). The registration confirmation screen SCC is an example where the candidate product is named "AAAAA" and has a unit price of 300 yen. The registration confirmation screen SCC represents the display area ARC and the buttons BUD, BUE, BUF, and BUG. The display area ARC represents the quantity internally. Button BUD is a soft key for specifying a quantity decrease. Button BUE is a soft key for specifying a quantity increase. Button BUF is a soft key for specifying not to register as a trading product. Button BUG is a soft key for specifying to register as a trading product.

[0079] In Figure 8, as ACT113, processor 101 waits for an operation to be performed on user terminal 200. When processor 101 receives notification of the operation from user terminal 200, it determines it is YES and proceeds to ACT114. As ACT114, processor 101 checks if a change in quantity has been specified.

[0080] If a user wishes to change the quantity, they specify the quantity change by performing a predetermined operation, such as tapping button BUD or button BUE. This operation is subject to notification, and on the user terminal 200, processor 201 determines YES in both ACT211 and ACT212 in Figure 7 and proceeds to ACT213, notifying the transaction processing unit 100 that an operation to specify a quantity change has been performed. In response to this notification, processor 101 on the transaction processing unit 100 determines YES in ACT114 in Figure 8 and proceeds to ACT115. As ACT115, processor 101 changes the quantity of candidate products. After this, processor 101 returns to the standby state for ACT113.

[0081] If the operation performed while the registration confirmation screen SCC is displayed does not specify a change in quantity, the processor 101 determines NO in ACT114 and proceeds to ACT121 in Figure 9. As ACT121, processor 101 checks whether a designation has been made to register the candidate product as a trading product. If processor 101 cannot confirm the relevant event, it determines NO, checks the content of the operation, and proceeds to other processes to perform the appropriate action. As one of the other processes, processor 101 checks whether a predetermined operation to cancel the registration has been performed, such as tapping button BUF, and returns to ACT108. Other processes may include processes different from the above, or multiple processes may be selectively performed, but a detailed explanation of these will be omitted here.

[0082] If the user decides to register the candidate product shown on the registration confirmation screen SCC as a trading product with the quantity shown in the display area ARC, they specify the registration by performing a predetermined operation, such as tapping the button BUG. When such an operation is notified from the user terminal 200, the processor 101 determines it as YES in ACT121 and proceeds to ACT122.

[0083] As ACT122, processor 101 registers the candidate product as a transaction product with the quantity shown in the display area ARC. For example, processor 101 updates the transaction data DAA to include product data representing the product code of the candidate product and the quantity shown in the display area ARC. Thus, by having processor 101 perform information processing based on the transaction processing program PRA, the computer with processor 101 as its central component functions as a registration means.

[0084] As ACT123, processor 101 instructs user terminal 200 to display the second registration screen. The second registration screen includes a list of products already registered as trading products, allowing the user to recognize the registration status of trading products, and is also a screen for receiving notifications of out-of-stock items.

[0085] In the user terminal 200, the processor 201, upon receiving instruction data for displaying the second registration screen, determines YES at ACT214 in Figure 7 and proceeds to ACT215, displaying the second registration screen on the touch panel 204. The processor 201 then returns to the standby state of ACT211.

[0086] Figure 13 is a diagram representing the second registration screen (SCD). In Figure 13, the same reference numerals are used for display elements that are the same as those in Figure 10, and their detailed explanations are omitted. The second registration screen, SCD, represents the display area ARA, buttons BUA, BUB, and BUH. In other words, the second registration screen, SCD, is the first registration screen, SCA, with the button BUH added. Button BUH is a soft key used to specify a stock shortage notification.

[0087] The second registration screen SCD shown in Figure 13 is an example where one product each named "AAAAA" and "BBBBB" with unit prices of 300 yen and 400 yen respectively have already been registered, and then one product named "CCCCC" with a unit price of 700 yen is added and registered. Therefore, the display area ARA represents the list of these trading products and shows that a total of 3 items have been registered, with a reference price of 1400 yen. The reference price is the amount obtained by subtracting the discount amount from various services such as coupon services from the sum of the unit prices of all trading products. If the trading products and applicable services are not changed when the transaction is settled, this reference price will be the settlement amount.

[0088] Even while the second registration screen SCD is displayed, the operator can specify the registration of another new trading product by performing the same operations as when the first registration screen SCA is displayed. In other words, when a user registers a product as a new trading product, they perform a predetermined operation to specify the start of a scan, such as tapping the button BUA on the second registration screen SCD. This operation is subject to notification, and the processor 201 on the user terminal 200 determines YES in both ACT211 and ACT212 in Figure 7, proceeds to ACT213, and sends notification data to notify the operation to specify the start of a scan.

[0089] In the transaction processing unit 100, the processor 101 instructs the display of the second registration screen SCD as ACT123 in Figure 9, and then proceeds to ACT124. As ACT124, processor 101 waits for an operation to be performed on user terminal 200. Therefore, if the operation to specify the start of scanning is notified from user terminal 200 to transaction processing unit 100 as described above, processor 101 determines it to be YES and proceeds to ACT125.

[0090] As ACT125, processor 101 checks whether the operation performed was an operation to specify the start of a scan. If processor 101 has notified that a scan start was specified as described above, it determines YES and returns to ACT108 in Figure 8, and repeats the subsequent processing as described above. In other words, users can add trading products even while the second registration screen, SCD, is being displayed, just as they can while the first registration screen, SCA, is being displayed.

[0091] If a user notices that the remaining number of items on display for a recently registered transaction meets a predetermined reporting rule, they can specify a stockout by performing a predetermined operation, such as tapping the BUH button displayed on the second registration screen (SCD). The reporting rule can be determined as appropriate by, for example, the store manager. One example of this reporting rule is "zero remaining items." However, for items that are often purchased in bulk, it could also be set as "five or fewer remaining items." The reporting rule is communicated to the user in advance as part of the terms of use for the smartphone POS service. The processor 101 may also display the reporting rule as a message on the second registration screen (SCD) along with the BUH button for notifying of stock shortages. In this case, the processor 101 may display a message such as "Tap the BUH button if the remaining items are zero" or "Tap the BUH button if the remaining items are five or fewer." This allows the user to be informed of the reporting rule.

[0092] The operation to specify this stockout notification is subject to notification, and the processor 201 at the user terminal 200 determines YES in both ACT211 and ACT212 in Figure 7, proceeds to ACT213, and sends notification data to notify the operation to specify the stockout notification. In the transaction processing device 100, if the user terminal 200 notifies the transaction processing device 100 of an operation to specify a stockout notification as described above, the processor 101 determines YES at ACT124 in Figure 9 and proceeds to ACT125. However, since it is not a scan start specification, it determines NO at ACT125 and proceeds to ACT126.

[0093] As ACT126, processor 101 checks whether the operation performed was an operation to specify the start of accounting. If processor 101 cannot confirm the event, it determines NO and proceeds to ACT127. If, as described above, an operation to specify a stockout notification is notified from user terminal 200 to transaction processing unit 100, processor 101 determines NO in ACT126 and proceeds to ACT127.

[0094] As ACT127, processor 101 verifies whether the operation performed was an operation to specify a stockout notification. If processor 101 cannot confirm that it was an operation to specify a stockout notification, it determines NO, verifies the content of the operation, and proceeds to other processes to perform the appropriate action. As one of these other processes, processor 101 may, for example, confirm that an operation to specify transaction cancellation was performed, execute the process to cancel the transaction, and then terminate the registration process. Other processes may include processes different from those described above, or multiple processes may be selectively performed, but a detailed explanation of these will be omitted here.

[0095] If the processor 101 receives notification from the user terminal 200 to the transaction processing unit 100 for an operation to specify a stock shortage notification as described above, it determines YES in ACT 127 and proceeds to ACT 128. As ACT128, processor 101 requests a stockout notification from the in-store Web client 500. Processor 101 includes a notification code and a product code in the request data for this stockout notification. That is, processor 101 determines a new notification code, different from the notification code used to identify other stockout notifications, according to predetermined rules, and includes this new notification code in the request data. Processor 101 also includes the product code of the transaction product registered immediately before the operation to designate the stockout notification in the request data. In other words, processor 101 determines that the transaction product registered immediately before the operation to designate the stockout notification is the target of the stockout notification, and by executing information processing based on the transaction processing program PRA, processor 101 functions as a determination means. Furthermore, processor 101 executes the request for the stockout notification as a notification process to a predetermined notification destination, as described later, and by executing information processing based on the transaction processing program PRA, processor 101 functions as a notification means.

[0096] The processor 101 may either send the request data from the communication unit 104 to the in-store web client 500 via the communication network 2, or from the communication unit 104 to the corporate server 400 via the communication network 2. However, in the latter case, the processor 101 includes the store code of the store where the user terminal 200 is being used in the request data.

[0097] When the corporate server 400 receives the request data sent from the transaction processing device 100 as described above to request a stockout notification, it forwards the request data to the in-store web client 500 located in the store identified by the store code included in the request data. The corporate server 400 may either forward the request data sent from the transaction processing device 100 as is, or it may forward the request data after making some modifications.

[0098] As ACT129, processor 101 checks whether the user code has been obtained. If processor 101 can confirm, for example, that the user code is set in the FCC field of the transaction data DAA related to the transaction, it determines that it has been obtained and YES, and proceeds to ACT130.

[0099] As ACT130, processor 101 adds a notification history related to the current stock shortage notification. Specifically, processor 101 generates a new data record REB, for example, by setting the notification code and product code included in the request data sent in ACT128 in fields FBA and FBB, respectively, and updates the notification history database DBB to include this data record REB. Processor 101 sets the truth value data set in field FBC of the data record REB generated here to indicate that the truth value is unverified. Also, processor 101 sets the user code found in ACT129 in field FBD of the data record REB generated here.

[0100] As ACT131, processor 101 instructs user terminal 200 to display the first notification guidance screen. The first notification guidance screen is a screen that guides the user to submit a stock shortage notification as specified. In the user terminal 200, the processor 201, upon receiving instruction data for displaying the first notification guidance screen, determines YES at ACT214 in Figure 7 and proceeds to ACT215, displaying the first notification guidance screen on the touch panel 204. The processor 201 then returns to the standby state of ACT211.

[0101] Figure 14 is a diagram representing the first notification guidance screen (SCE). The first notification guidance screen SCE is a screen that overlays the second registration screen SCD, which was displayed on user terminal 200 before the first notification guidance screen SCE, with the window WIA displayed and the button BUI replaced with the button BUH.

[0102] The window WIA displays a text message to inform the user that their request for a stock shortage notification has been received. In this embodiment, the text message displayed in the window WIA indicates that points may be awarded. The button BUI is a soft key to receive a declaration from the user that they have finished confirming the first notification guidance screen SCE.

[0103] Now, for example, if the user code is not set in the FCC field of the transaction data DAA related to the transaction, the processor 101 determines NO in ACT129 in Figure 9, stating that the user code has not been obtained, and proceeds to ACT132. As ACT132, processor 101 adds a notification history related to the current stock shortage notification. Specifically, processor 101 generates a new data record REB, for example, by setting the notification code and product code included in the request data sent in ACT128 to fields FBA and FBB respectively, and updates the notification history database DBB to include the said data record REB. Processor 101 sets the truth value data set in field FBC of the data record REB generated here to a state indicating that the truth value is unverified. Also, processor 101 sets the field FBD of the data record REB generated here to a predetermined state indicating that the user code has not been obtained, for example, by setting it to null.

[0104] As ACT133, processor 101 instructs user terminal 200 to display a second notification guidance screen. The second notification guidance screen is a screen that guides the user to submit a stock shortage notification as specified. The second notification guidance screen is expected to have a similar configuration to the first notification guidance screen SCE, for example. However, since the user code has not been obtained and points cannot be awarded to the user, the text message displayed in window WIA, for example, will not include content that indicates that points may be awarded.

[0105] In the user terminal 200, the processor 201, upon receiving instruction data for displaying the second notification guidance screen, determines YES at ACT214 in Figure 7 and proceeds to ACT215, displaying the second notification guidance screen on the touch panel 204. The processor 201 then returns to the standby state of ACT211.

[0106] In the transaction processing unit 100, after the processor 101 instructs the display of the first notification guidance screen SCE or the second notification guidance screen in ACT131 or ACT133 in Figure 9, the process proceeds to ACT134 in either case. As ACT134, processor 101 awaits confirmation declarations regarding the first notification guidance screen SCE or the second notification guidance screen.

[0107] Once the user has finished reviewing the instructions on the first notification guidance screen SCE or the second notification guidance screen, they declare that they have finished reviewing the instructions by performing a predetermined operation, such as tapping the button BUI displayed on the first notification guidance screen SCE. The operation to declare that this confirmation has been completed is subject to notification, and the processor 201 on the user terminal 200 determines YES in both ACT211 and ACT212 in Figure 7, proceeds to ACT213, and sends notification data to notify the user of the operation.

[0108] In the transaction processing device 100, if the user terminal 200 notifies the transaction processing device 100 of the operation to declare that the confirmation has been completed as described above, the processor 101 determines YES at ACT134 in Figure 9 and returns to ACT104 in Figure 8. In other words, the processor 101 returns the display on the user terminal 200 to the first registration screen SCA and repeats ACT105 onwards as described above.

[0109] Figure 15 shows an example of the first registration screen SCA. The first registration screen SCA shown in Figure 15 is an example of a screen that is displayed after the first notification guidance screen SCE shown in Figure 14 is displayed in response to an operation to specify a shortage notification while the second registration screen SCD shown in Figure 13 is being displayed, and then the processor 101 returns to ACT104 in Figure 8 as described above. In other words, processor 101 will not be designated as out of stock until it registers new trading products.

[0110] Once the user has finished registering all the transaction items for the current transaction, they specify the start of accounting by performing a predetermined operation, such as tapping the BUB button on the first registration screen SCA. This operation is notifiable, and the processor 201 on the user terminal 200 determines YES in both ACT211 and ACT212 in Figure 7 and proceeds to ACT213, notifying the transaction processing unit 100 that the operation to instruct the start of accounting has been performed. In response to this notification, the processor 101 on the transaction processing unit 100 determines YES in ACT107 in Figure 8 or ACT126 in Figure 9 and proceeds to accounting. The accounting process may be the same as that performed in existing smartphone POS services, and its illustration is omitted. For example, the processor 101 performs the process of transferring transaction data to the accounting machine 700 as accounting. Alternatively, it may perform the process of making a payment using an online payment service such as code payment as accounting.

[0111] Figure 16 is a sequence diagram showing the processing flow associated with a stock shortage notification. The operation of the transaction processing unit 100, the in-store web client 500, and the employee terminal 800, as described below, is realized through information processing by the processor 101 provided in the transaction processing unit 100 and the processors provided in the in-store web client 500 and the employee terminal 800, respectively.

[0112] As described above, when the in-store web client 500 receives the request data sent from the transaction processing device 100 for the request of stockout notification, either directly or via the corporate server 400, it proceeds to ACT 501. As ACT501, the in-store web client 500 instructs the employee terminal 800 to display the out-of-stock notification screen. The out-of-stock notification screen is a screen that informs the employee that there has been an out-of-stock notification for a product identified by the product code included in the request data. The out-of-stock notification screen can be any screen as long as it allows the employee to recognize that the out-of-stock notification was made by a user and to identify which product is the one in question.

[0113] As ACT801, employee terminal 800 displays the out-of-stock notification screen in response to instructions from the in-store web client 500. Employee terminal 800 may either automatically display the out-of-stock notification screen in response to instructions, or it may display the out-of-stock notification screen in response to a predetermined operation to instruct its display.

[0114] Employees, upon visually checking the stock shortage notification screen displayed on employee terminal 800 and confirming the contents of the stock shortage notification, will then check the display status of the product in question and take necessary measures such as replenishment. Furthermore, employees who have checked the display status will declare whether the stock shortage report is true or false by performing a predetermined operation on the employee terminal 800. For example, if an employee determines that the stock shortage report on the stock shortage report screen is true, they will tap the button displayed on the same stock shortage report screen to declare that it is true. Alternatively, if an employee determines that the stock shortage report on the stock shortage report screen is false, they will tap the button displayed on the same stock shortage report screen to declare that it is false.

[0115] When employee terminal 800 receives such a declaration of authenticity, it proceeds to ACT802. As ACT802, the employee terminal 800 notifies the in-store web client 500 about the truth declaration made, for example, by sending notification data that includes a flag indicating whether a declaration of truth or falsehood was made.

[0116] When in-store web client 500 receives a notification regarding the declaration of authenticity in this manner, it proceeds to ACT502. As ACT502, the in-store web client 500 requests the transaction processing unit 100 to update the notification history. The in-store web client 500 sends request data to the transaction processing unit 100, for example, to request an update to the notification history, either directly or via the corporate server 400. The in-store web client 500 includes, for example, in the request data the notification code included in the notification data for the out-of-stock notification and the flag included in the notification data for the truth / false declaration notification.

[0117] The transaction processing unit 100 performs information processing to manage the record of stockout notifications, separate from the aforementioned transaction processing, based on the transaction processing program PRA. However, the transaction processing unit 100 may also perform the information processing to manage the record of stockout notifications based on an information processing program other than the transaction processing program PRA. If an update is requested from the in-store Web client 500 as described above, the transaction processing unit 100 proceeds to ACT151.

[0118] As ACT151, the transaction processing unit 100 updates the notification history database DBB. Specifically, the transaction processing unit 100 finds the data record REB in the notification history database DBB in which the notification code included in the notification data is set in the field FBA. The transaction processing unit 100 then rewrites the truth value data set in the field FBC of the corresponding data record REB to either a state indicating true or a state indicating false, according to the flag included in the notification data.

[0119] As ACT152, the transaction processing unit 100 checks if there is a user code for the user who specified the stock shortage notification. If, for example, a valid user code is set in the FBD field of the data record REB updated in ACT151, the transaction processing unit 100 determines that the user code exists and YES, and proceeds to ACT153.

[0120] As ACT153, the transaction processing unit 100 verifies whether the stock shortage notification was true. If, for example, the truth value data was changed to a state indicating true in ACT151, the transaction processing unit 100 determines YES and proceeds to ACT154. As ACT154, the transaction processing unit 100 awards predetermined points to the user identified by the above user code. In other words, for stock shortage reports declared true by an employee, the transaction processing unit 100 awards points to the user who made the stock shortage report, if that user is known. For example, the transaction processing unit 100, The store database DBA finds the data record REA associated with the store where the in-store web client 500 that sent notification data for the declaration of truthfulness is located. The transaction processing unit 100 then awards points according to the awarding rules represented by the reward data set in the FAC field of the corresponding data record REA. Thus, the transaction processing unit 100 can also, for example, vary the number of points awarded depending on the store where the out-of-stock notification was made.

[0121] Furthermore, if the transaction processing unit 100 cannot confirm the existence of a user code, it will determine NO in ACT152, and if it cannot confirm that the stockout notification is true, it will determine NO in ACT153, and in either case, it will skip ACT154. In other words, in these cases, the transaction processing unit 100 will not award points to the user who specified the stockout notification.

[0122] As described above, the transaction processing device 100 prompts employees to confirm the stock shortage notification via a screen display on the employee terminal 800, in response to the user's designation of a stock shortage notification on the user terminal 200. This allows the user to take part in checking the product display status, reducing the burden on employees. The transaction processing device 100 then targets the stock shortage notification for the transaction product registered immediately before the designation of the stock shortage notification. As a result, when designating a stock shortage notification, the user does not need to specify the target product; a simple operation such as tapping the BUH button is sufficient, and the burden on the user does not increase excessively. Furthermore, the user only needs to designate a stock shortage notification for a product that they have taken from its display location as a transaction product, if they notice that the notification rule is met. In other words, the user only needs to designate a notification for stock shortages they notice while shopping, so in this respect as well, the burden on the user does not increase excessively. Moreover, since the user cannot designate a stock shortage notification for a product that is not registered as a transaction product, the possibility of stock shortage notifications being made for malicious purposes is reduced.

[0123] Furthermore, the transaction processing device 100 awards points to a user if it is clear that the user who designated the stock shortage notification declared by an employee to be true is the user in question. This makes it possible to encourage users to proactively submit stock shortage notifications.

[0124] Furthermore, the transaction processing device 100 will not award points for stockout reports that have not been declared as true by an employee, even if the user is aware of this. Therefore, it is possible to prevent stockout reports from being made inappropriately for the purpose of awarding points.

[0125] This embodiment can be modified in various ways as follows: Before or after designating which of the registered trading products should be subject to the out-of-stock notification, users may be allowed to specify which of the registered trading products should be included in the out-of-stock notification.

[0126] For example, the rewards could be in the form of something other than points, such as redemption in the form of electronic money or issuance of coupons.

[0127] The benefit may be linked to user terminal 200. In other words, a coupon that can only be used on user terminal 200 designated as the out-of-stock item may be issued. In this case, the benefit may be granted regardless of whether the user is identifiable or not.

[0128] Rewards may be awarded regardless of the veracity of the stock shortage report. However, in this case, it is preferable to offer a more favorable reward to the user when the report is true than when it is false, in order to prevent fraudulent reports. For example, one possible implementation would be to award 5 points for a true report and 1 point for a false report.

[0129] The in-store web client 500 may promptly issue a command to display the out-of-stock notification screen upon receiving the request data, or it may wait until a predetermined display timing arrives. Furthermore, if the in-store web client 500 receives multiple request data related to out-of-stock notifications during a certain reception period, it may also issue a command to display an out-of-stock notification screen showing a list of products identified by the product codes included in each of those request data. The in-store web client 500 may also issue a command to display the out-of-stock notification screen to a specific employee terminal 800 from among multiple employee terminals 800 included in the same in-store system, depending on the product subject to the out-of-stock notification. In other words, for example, the in-store web client 500 may switch which employee terminal 800 is instructed to display the out-of-stock notification screen according to predetermined rules. For instance, it may display the out-of-stock notification screen for products displayed in the first sales area on an employee terminal 800 held by an employee responsible for stocking products in the first sales area, and display the out-of-stock notification screen for products displayed in the second sales area on an employee terminal 800 held by an employee responsible for stocking products in the second sales area.

[0130] Furthermore, the awarding of points may be performed by a separate processing unit, such as a processing unit that performs information processing for point management, in response to a request from the transaction processing unit 100, or autonomously based on the notification history database DBB. In this case, the processing unit that performs information processing for point management will also function as the point awarding means.

[0131] The declaration that a stockout notification is true may be received by an information processing device other than the employee terminal 800 that displayed the stockout notification screen. For example, the company server 400 may display a screen showing a list of completed stockout notifications based on the notification history database DBB to an information terminal that accesses the company server 400, and receive a declaration of truth or falsity regarding the specified stockout notification based on the operation on this screen. In this case, the company server 400 will function as the receiving device.

[0132] The processor 201 on the user terminal 200 may perform some or all of the processing that the processor 101 performs on the transaction processing device 100. For example, transaction data may be stored in the auxiliary storage unit 203, and its updates may be performed by the processor 201. In this case, the computer with the processor 201 as its central component functions as a registration means by the processor 201 performing information processing based on the user terminal program PRB. Alternatively, for example, the processor 201 may, in response to an operation to specify a stockout notification, send request data to the in-store Web client 500 to request a stockout notification for the product identified by the product code obtained for the most recent product registration. In this case, the computer with the processor 201 as its central component functions as a determination means and a notification means by the processor 201 performing information processing based on the user terminal program PRB.

[0133] Some or all of the processing performed by the processor 101 in the transaction processing device 100 may be performed by any information processing device other than the transaction processing device 100, such as the shopping cart terminal 300, the corporate server 400, or the in-store web client 500. For example, transaction data may be stored in a storage unit provided in the shopping cart terminal 300, and its updates may be performed by the processor provided in the shopping cart terminal 300. In this case, a computer with the processor provided in the shopping cart terminal 300 as its central component will function as a registration means.

[0134] The various functions realized by information processing in various devices can also be partially or entirely realized by hardware that performs non-program-based information processing, such as logic circuits. Furthermore, each of the above functions can also be realized by combining the aforementioned hardware, such as logic circuits, with software control.

[0135] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. The invention described in the original claims of this application is listed below. [Note 1] A registration means for registering a product specified on a mobile terminal as a trading product subject to transaction, When a notification instruction is made via operation on the mobile terminal targeting any of the trading products registered by the registration means, the determination means determines which trading product is the target of the notification instruction. A notification means that performs a predetermined notification process to notify a predetermined recipient that the same product as the traded product determined by the determination means should be replenished in the display area, A transaction processing system equipped with the following features. [Note 2] The determination means determines that the trading product registered by the registration means immediately before the notification instruction is the trading product that is the subject of the notification instruction. The transaction processing system described in Appendix 1. [Note 3] The determination means determines that the trading products designated by the operation on the mobile terminal from among the trading products registered by the registration means are the trading products subject to notification instructions. The transaction processing system described in Appendix 1. [Note 4] A receiving means that receives a declaration that the report is true as a response to the report by the reporting means, A granting means for granting a reward to a report that has been declared true by the aforementioned receiving means, A transaction processing system described in any one of the appendices 1 to 3, further comprising the above. [Note 5] A registration means for registering a product specified on a mobile terminal as a trading product subject to transaction, When a notification instruction is made via operation on the mobile terminal targeting any of the trading products registered by the registration means, the determination means determines which trading product is the target of the notification instruction. A notification means that performs a predetermined notification process to notify a predetermined recipient that the same product as the traded product determined by the determination means should be replenished in the display area, A transaction processing device equipped with the following. [Note 6] Computers, A registration method for registering products specified on a mobile terminal as trading products subject to transactions, When a notification instruction is made via operation on the mobile terminal targeting any of the trading products registered by the registration means, the determination means determines which trading product is the target of the notification instruction. A notification means that performs a predetermined notification process to notify a predetermined recipient that the same product as the traded product determined by the determination means should be replenished in the display area, An information processing program that enables a function to work. [Explanation of Symbols]

[0136] 1...Transaction processing system, 2...Communication network, 100...Transaction processing unit, 101...Processor, 102...Main memory unit, 103...Auxiliary memory unit, 104...Communication unit, 105...Transmission line, 200...User terminal, 201...Processor, 202...Main memory unit, 203...Auxiliary memory unit, 204...Touch panel, 205...Camera, 206...Wireless communication unit, 207...Transmission line, 300...Cart terminal, 400...In-house server, 500...In-store web client, 600...In-store POS, 700...Accounting machine, 800...Employee terminal.

Claims

1. A registration method for registering products specified on a mobile terminal as trading products subject to transactions, When a notification instruction is made by operation on the mobile terminal targeting any of the trading products already registered by the registration means, a determination means determines that the trading product registered by the registration means immediately before the notification instruction is the target of the notification instruction, A notification means that performs a predetermined notification process to notify a predetermined recipient that the same product as the traded product determined by the determination means to be subject to notification instructions should be replenished in the display area, A transaction processing system equipped with the following features.

2. A receiving means that receives a declaration that the report is true as a response to the report made by the reporting means, A granting means for granting a reward to a report that has been declared true by the aforementioned receiving means, The transaction processing system according to claim 1, further comprising:

3. A registration method for registering products specified on a mobile terminal as trading products subject to transactions, When a notification instruction is made by operation on the mobile terminal targeting any of the trading products already registered by the registration means, a determination means determines the trading product to be the target of the notification instruction, which is the trading product registered by the registration means immediately before the notification instruction was made. A notification means that performs a predetermined notification process to notify a predetermined recipient that the same product as the traded product determined by the determination means to be subject to notification instructions should be replenished in the display area, A transaction processing device equipped with the following.

4. Computers, A registration method for registering products specified on a mobile terminal as trading products subject to transactions, When a notification instruction is made by operation on the mobile terminal targeting any of the trading products already registered by the registration means, a determination means determines the trading product to be the target of the notification instruction, which is the trading product registered by the registration means immediately before the notification instruction was made. A notification means that performs a predetermined notification process to notify a predetermined recipient that the same product as the traded product determined by the determination means to be subject to notification instructions should be replenished in the display area, An information processing program that enables a function to work.

Images