Information display device and information processing program

Abstract

The aim is to simplify the process of verifying the execution status of each transaction when different types of terminal devices are used for multiple transactions. [Solution] The information display device of this embodiment is used in a transaction processing system that processes multiple transactions in parallel using multiple terminal devices, each belonging to either a first terminal type or a second terminal type, and comprises a receiving means, a filtering means, and a display means. The receiving means accepts the designation of at least one of the first terminal type and the second terminal type. The filtering means narrows down the multiple transactions being processed in the transaction processing system to those processed using terminal devices belonging to the terminal type designated by the receiving means. The display means displays information about the transactions narrowed down by the filtering means on a display device.

Description

Technical Field

[0001] Embodiments of the present invention relate to an information display device and an information processing program.

Background Art

[0002] A POS (point-of-sale) service that performs transaction processing using an information communication terminal owned by a customer as a user, such as a smartphone, or an information communication terminal lent to the user from a store or the like as a user interface terminal, is known as a "smartphone POS service" or the like. Alternatively, a POS service that performs transaction processing using an information communication terminal attached to a shopping cart provided in a store as a user interface terminal is known as a "cart POS service" or the like.

[0003] In these smartphone POS services and cart POS services, since the user, that is, the customer of the store, becomes the operator of the user interface terminal, in the event of some trouble, the service utilization situation may be confirmed by a store clerk or the like in order to appropriately support the user. However, when both the smartphone POS service and the cart POS service can be used in the same store, transactions processed using different types of terminal devices are mixed in a plurality of transactions performed in the store, and the work of checking the implementation status of each transaction becomes complicated. Under such circumstances, it has been desired that the work of checking the implementation status of each transaction in a situation where different types of terminal devices are mixed and used in a plurality of transactions can be simplified.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] The problem that this invention aims to solve is to provide an information display device and an information processing program that can simplify the process of confirming the status of each transaction in a situation where different types of terminal devices are used for multiple transactions. [Means for solving the problem]

[0006] The information display device of this embodiment is used in a transaction processing system that processes multiple transactions in parallel using multiple terminal devices, each belonging to either a first terminal type or a second terminal type, and comprises a receiving means, a filtering means, and a display means. The receiving means accepts the designation of at least one of the first terminal type and the second terminal type. The filtering means narrows down the multiple transactions being processed in the transaction processing system to those processed using terminal devices belonging to the terminal type designated by the receiving means. The display means displays information about the transactions narrowed down by the filtering means on a display device. [Brief explanation of the drawing]

[0007] [Figure 1] A block diagram illustrating the schematic configuration of a transaction processing system 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] A schematic diagram showing the structure of transaction data in Figure 2. [Figure 5] A block diagram showing the main circuit configuration of the attendant terminal in Figure 1. [Figure 6] A block diagram showing the main circuit configuration of the user terminal in Figure 1. [Figure 7] A block diagram showing the main circuit configuration of the cart terminal in Figure 1. [Figure 8] A flowchart for smartphone POS processing. [Figure 9] Flowchart of smartphone POS processing. [Figure 10] Flowchart of smartphone POS processing. [Figure 11] Diagram representing unavailable screen. [Figure 12] Diagram representing registration screen. [Figure 13] Diagram representing product scan screen. [Figure 14] Diagram representing registration confirmation screen. [Figure 15] Diagram representing first selection screen. [Figure 16] Diagram representing permission code scan screen. [Figure 17] Flowchart of cart POS processing. [Figure 18] Diagram representing first request screen. [Figure 19] Diagram representing second request screen. [Figure 20] Diagram representing transfer screen. [Figure 21] Flowchart of confirmation support processing. [Figure 22] Diagram representing status confirmation screen. [Figure 23] Diagram representing status confirmation screen. [Figure 24] Diagram representing status confirmation screen. [Figure 25] Diagram representing status confirmation screen. [Figure 26] Diagram representing status confirmation screen. [Figure 27] Diagram representing status confirmation screen.

Mode for Carrying Out the Invention

[0008] Hereinafter, an example of an embodiment will be described with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system 1 according to the present embodiment. The transaction processing system 1 is configured such that the transaction processing device 100, accounting machine 200, attendant terminal 300, user terminal 400, cart terminal 500, and electronic receipt server 600 can communicate with each other via the communication network 2. 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 can be used in combination with the internet and a mobile communication network. Note that the transaction processing unit 100, accounting machine 200, attendant terminal 300, user terminal 400, and cart terminal 500 may be included in any number of each in the transaction processing system 1, but only one of each is shown in Figure 1.

[0009] The transaction processing device 100 is an information processing device that performs information processing to provide a transaction processing service that processes the buying and selling of goods between a user and a store, according to operations performed by the user at the store using the accounting machine 200, user terminal 400, and cart terminal 500 as user interface terminals. In other words, typically, a customer who purchases goods at the store becomes a user of the transaction processing service. The transaction processing device 100 may be implemented as, for example, a cloud server and provide the transaction processing service to multiple stores. The transaction processing device 100 may also be implemented as, for example, a local server and provide the transaction processing service to only one store. The transaction processing device 100 also has a function as an information display device that allows the attendant terminal 300 to display a screen for checking the status of the transaction.

[0010] The accounting machine 200 is installed in the store and performs accounting processing related to transactions processed by the transaction processing device 100. The accounting machine 200 receives input from an operator during accounting processing. In other words, the accounting machine 200 is a terminal device that accepts user input related to accounting. The operator of the accounting machine 200 is primarily the user. In some cases, a store employee may also operate the accounting machine 200.

[0011] The attendant terminal 300 is an information processing terminal operated by a store employee. The attendant terminal 300 is a terminal device for a user interface related to information processing, which supports the work of store employees regarding transactions processed by the transaction processing system 1.

[0012] The user terminal 400 is an information processing terminal owned by the user. Typically, the user terminal 400 is owned by the user and brought to the store for use by the user. The user terminal 400 is a terminal device that receives operations from the user for transaction processing on the transaction processing device 100.

[0013] The cart terminal 500 is an information processing terminal attached to a shopping cart provided in the store. The cart terminal 500 is lent to the user along with the shopping cart. The cart terminal 500 is a terminal device that receives operations from the user for transaction processing on the transaction processing device 100. The cart terminal 500 may also include an information and communication terminal that is lent to the user by the store and carried and used by the user.

[0014] The electronic receipt server 600 is an information processing device that performs information processing to provide electronic receipt services to users. The electronic receipt server 600 may be implemented as, for example, a cloud server and provide an electronic receipt service that allows users to electronically view transactions from multiple stores. The transaction processing device 100 may be implemented as, for example, a local server and provide an electronic receipt service that allows users to electronically view transactions from only one store.

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

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

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

[0018] 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 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 transaction data DAA is data that represents the content of a single transaction.

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

[0020] 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 device 100.

[0021] 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 information necessary for the associated store to provide transaction processing services. Store information includes, for example, information indicating the time period during which the store allows the use of transaction processing services (hereinafter referred to as the "available time period"). Field FAC contains payment method information indicating the payment methods that are permitted when settling the payment for transactions processed by the transaction processing service at the associated store using the online payment service.

[0022] Figure 4 is a schematic diagram illustrating the structure of the transaction data DAA. Transaction data DAA is generated for each transaction being processed by the transaction processing unit 100 and stored in the auxiliary storage unit 103. Thus, there may be cases where no transaction data DAA is stored in the auxiliary storage unit 103, or where multiple transaction data DAAs are stored in the auxiliary storage unit 103 simultaneously.

[0023] Transaction data DAA includes fields FBA, FBB, FBC, and FBD. Transaction data DAA may include any number of fields from field FBE onwards. Field FBA is set to the transaction code as the identifier of the transaction in question. Field FBB is set to the terminal code as the identifier of the user terminal 400 or cart terminal 500 used by the user performing the transaction in question. Field FBC is set to the user code as the identifier of the user performing the transaction in question. Field FBD is set to management data containing various data for managing the transaction in question. Management data may include, for example, start time, last operation time, status, accounting machine code, accounting processing code, and cancellation flag. Start time represents the time the transaction in question was started. Last operation time represents the time the last operation was performed on user terminal 400 or cart terminal 500 regarding the transaction in question. Status represents the progress of the transaction in question, divided into several categories. Statuses may include, for example, "Entered store," "Shopping," "Checkout," "Leaving store," and "Cancelled." The accounting machine code is an identifier for accounting machine 200 used or used for settlement of the relevant transaction. The accounting process code is an identifier used by accounting machine 200 to identify the accounting process for the relevant transaction. The cancellation flag indicates that the processing of the relevant transaction is in a temporarily suspended state. If there are registered products (hereinafter referred to as "transaction products") that are the subject of the transaction, fields FBE, FBF, ... associated with each transaction product are added to the transaction data DAA. Each of the fields FBE, FBF, ... contains product data for a different transaction product. The product data includes the product code and quantity as identifiers for the transaction product. The product data may also include various other information, such as product name, unit price, and discount information.

[0024] 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, but the store database DBA and transaction data DAA not stored therein. However, the hardware 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, and the transaction processing program PRA may be transferred separately. Furthermore, 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 worker. 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.

[0025] Figure 5 is a block diagram showing the main circuit configuration of the attendant terminal 300. The attendant terminal 300 includes a processor 301, a main memory unit 302, an auxiliary memory unit 303, a touch panel 304, a camera 305, a wireless communication unit 306, and a transmission line 307, among other things.

[0026] The general functions of the processor 301, main memory unit 302, auxiliary memory unit 303, and transmission line 307 are the same as those of the processor 101, main memory unit 102, auxiliary memory unit 103, and transmission line 105, so their explanation will be omitted. However, the auxiliary memory unit 303 stores the attendant terminal program PRC instead of the transaction processing program PRA. The attendant terminal program PRC is an application program that describes the information processing procedure of the processor 301 to operate the attendant terminal 300 as a user interface for store employees that supports transactions processed by the transaction processing device 100.

[0027] The touch panel 304 displays a screen for presenting information to the operator. The touch panel 304 also accepts input from the operator through touch operations on the screen. The camera 305 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.

[0028] The wireless communication unit 306 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 306. 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 306.

[0029] The hardware for the attendant terminal 300 can be, for example, a tablet-type information processing device or a portable information processing device such as a smartphone. Alternatively, a stationary computer device may be used as the hardware for the attendant terminal 300.

[0030] Figure 6 is a block diagram showing the main circuit configuration of the user terminal 400. The user terminal 400 includes a processor 401, a main memory unit 402, an auxiliary memory unit 403, a touch panel 404, a camera 405, a wireless communication unit 406, and a transmission line 407, among other things.

[0031] The general functions of the processor 401, main memory unit 402, auxiliary memory unit 403, and transmission line 407 are equivalent to those of the processor 101, main memory unit 102, auxiliary memory unit 103, and transmission line 105. Furthermore, the general functions of the touch panel 404, camera 405, and wireless communication unit 406 are equivalent to those of the touch panel 304, camera 305, and wireless communication unit 306. However, the auxiliary storage unit 403 stores the user terminal program PRD instead of the transaction processing program PRA. The user terminal program PRD is an application program that describes the information processing procedures for the processor 401 to operate the user terminal 400 as a user interface for transaction processing by the transaction processing device 100. The auxiliary storage unit 403 also stores the browser program PRE. The browser program PRE is an application program that describes the information processing procedures for web browsing via the communication network 2. For the browser program PRE, a general-purpose browser application that comes standard on smartphones, for example, can be used as is. The auxiliary storage unit 403 also stores the terminal code COA for the user terminal 400. The terminal code COA is an identifier for identifying each user terminal 400 and cart terminal 500. For example, the terminal code COA can be an identifier determined by the OS (operating system) of the user terminal 400 when the user terminal program PRD is installed. The terminal code COA is, for example, a 32-digit alphanumeric string. The wireless communication unit 406 also typically includes well-known communication devices for data communication over a mobile communication network. However, the wireless communication unit 406 may also include existing wireless communication devices for wireless LANs, either in place of or in addition to the above-mentioned communication devices. The basic hardware of the user terminal 400 is expected to be, for example, smartphone hardware.

[0032] Figure 7 is a block diagram showing the main circuit configuration of the cart terminal 500. The cart terminal 500 includes a processor 501, a main memory unit 502, an auxiliary memory unit 503, a touch panel 504, a scanner 505, a wireless communication unit 506, and a transmission line 507, among other things.

[0033] The general functions of the processor 501, main memory unit 502, auxiliary memory unit 503, and transmission line 507 are equivalent to those of the processor 101, main memory unit 102, auxiliary memory unit 103, and transmission line 105. Furthermore, the general functions of the touch panel 504 and wireless communication unit 506 are equivalent to those of the touch panel 304 and wireless communication unit 306. However, the auxiliary storage unit 503 stores the cart terminal program PRF instead of the transaction processing program PRA. The cart terminal program PRF is an application program that describes the information processing procedure of the processor 501 for operating the cart terminal 500 as a user interface for transaction processing by the transaction processing device 100. The auxiliary storage unit 503 also stores the terminal code COB for the cart terminal 500. The terminal code COB is an identifier for identifying each user terminal 400 and cart terminal 500. The terminal code COB is assigned to each cart terminal 500 in advance by a maintenance worker or the like, so that it can identify each of the multiple cart terminals 500 used in the same store, and so as not to overlap with the terminal code of the user terminal 400, and is written to the auxiliary storage unit 503. For example, a number from "1" to "999" is used as the terminal code COB. The wireless communication unit 506 also typically includes an existing wireless communication device for a wireless LAN. However, the wireless communication unit 506 may also include, in place of or in addition to, the above-mentioned communication device, a well-known communication device for data communication over a mobile communication network.

[0034] Scanner 505 optically scans one-dimensional barcodes, two-dimensional barcodes, and the like. The basic hardware of the cart terminal 500 is expected to be, for example, the hardware of a tablet-type information processing device. The scanner 505 is expected to be configured as a separate unit from the information processing device and attached externally to it. However, the cart terminal 500 may also be configured using the camera built into the information processing device as the imaging device for the scanner 505.

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

[0036] As described below, the services provided to users by the transaction processing system 1 are referred to as smartphone POS services when the user uses user terminal 400, and as cart POS services when the user uses cart terminal 500. To use the smartphone POS service, users must install the user terminal program PRD on their own smartphone or other information processing device, making it usable as a user terminal 400. Then, the user enters a store that provides the smartphone POS service with the user terminal 400, which has the processor 401 executing user terminal processing according to the user terminal program PRD.

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

[0038] The user operates the user terminal 400 to have the camera 405 of the user terminal 400 photograph the check-in code displayed at the store they are using. In response, the processor 401 in the user terminal 400 sends the check-in data represented by the check-in code photographed by the camera 405, along with the terminal code COA of the user terminal 400, to the transaction processing unit 100 via the wireless communication unit 406 to the communication network 2.

[0039] On the other hand, in order for a user to use the electronic receipt service provided by the electronic receipt server 600, the user must register and receive a user code. If the user wishes to use the online payment service for settlement related to transactions using the smartphone POS service, the user must link the user code for the electronic receipt service as part of the user terminal program PRD usage settings. Through this linkage, the user code is stored in the main storage unit 402 or auxiliary storage unit 403 of the user terminal 400, in a state where the processor 401 can access it during user terminal processing. When the processor 401 sends check-in data to the transaction processing device 100 as described above, if the user code is stored as described above, the processor 401 also sends the user code.

[0040] When check-in data is transmitted to the transaction processing unit 100 via the communication network 2, the transaction processing unit 100 receives the check-in 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 check-in data sent from the user terminal 400 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.

[0041] However, this check-in procedure is merely an example, and various modifications are possible. For example, the processor 401 of the user terminal 400 may, after starting the user terminal program PRD, send check-in data including location information acquired using GPS (global positioning system) or other positioning sensors to the transaction processing device 100. Then, 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 400 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.

[0042] 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 400 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 400" refers to a single user terminal 400 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.

[0043] Figures 8, 9, and 10 are flowcharts of smartphone POS processing. The following explanation will use the case where the check-in code is read by the user terminal 400 and the check-in data represented by the check-in code includes a store code as an example. In Figure 8, as ACT11, processor 101 checks whether the current time is within the available time period. That is, processor 101 searches the store database DBA for data record REA, in which the store code included in the received check-in data is set in field FAA, and determines the available time period represented by the information included in the store information set in field FAB of the data record REA. Then, if processor 101 determines that the current time is not included in the available time period determined here, it determines NO and proceeds to ACT12. Note that the available time period may be determined as appropriate for each store.

[0044] As ACT12, processor 101 instructs user terminal 400 to display an unavailable screen. 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 400 to instruct user terminal 400 to display an available screen. After this, processor 101 terminates the smartphone POS processing.

[0045] When instruction data for screen display instructions is transmitted to the user terminal 400 via the communication network 2, the wireless communication unit 406 in the user terminal 400 receives the instruction data. Upon receiving the instruction data, the wireless communication unit 406 notifies the processor 401 of this fact. If the processor 401 has received instruction data for screen display instructions, it performs user terminal processing to display the screen corresponding to that instruction data on the touch panel 404.

[0046] 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 400 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 400 and then 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 400, 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 "outside of available time slots."

[0047] If the received instruction data in the user terminal 400 contains screen data, the processor 401 displays the screen represented by that screen data directly on the touch panel 404. If the received instruction data contains a screen identifier, the processor 401 generates the screen identified by that screen identifier and displays it on the touch panel 404. If the received instruction data contains a notification identifier, the processor 401 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 404. The exchange of instructions for displaying the various screens described below will be carried out using the same procedure as above, although the content of the screens being displayed will differ.

[0048] Figure 11 shows an unavailable screen SCA. The Unavailable Screen SCA is a screen displayed on the touch panel 404 when scanning a check-in code, with a pop-up window WAA overlaid on top. The pop-up window WAA displays a text message informing the user that it is outside of the available hours, and a button BAA. The button BAA is a soft key that allows the user to acknowledge that they have seen the information on the Unavailable Screen SCA.

[0049] If the user sees the message on the unavailable screen SCA, they tap button BAA. When this operation is detected by the touch panel 404, the processor 401 terminates the display of the unavailable screen SCA and returns the touch panel 404's display screen to, for example, a screen for scanning a check-in code.

[0050] On the other hand, if the current time is included in the available time period, processor 101 determines YES in ACT11 and proceeds to ACT13. As ACT13, processor 101 generates new transaction data. Specifically, processor 101 determines a new transaction code, different from the transaction code used to identify other transactions, according to predetermined rules, sets this transaction code in field FBA, and generates new transaction data DAA by setting the terminal code received along with the check-in data in field FBB, and stores it in auxiliary storage unit 103. If a user code is received along with the check-in data, processor 101 sets the user code in field FBC of the newly generated transaction data DAA. If a user code is not received along with the check-in data, processor 101 sets field FBC of the newly generated transaction data DAA to a null state, for example. Processor 101 generates management data and sets it in field FBD of the newly generated transaction data DAA. Processor 101 includes the current time as the start time in the management data. Processor 101 includes "Entered Store" as the status in the management data. Processor 101 sets the cancellation flag to be included in the management data to a reset state. The processor 101 may also include various other types of data in its management data. The specific data to be included in the management data may be determined as appropriate by, for example, the creator of the transaction processing program PRA.

[0051] In Figure 8, as ACT14, processor 101 instructs user terminal 400 to display the registration screen. The 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 registration screen that reflects the registration status of trading products, and includes this screen data in the instruction data to instruct user terminal 400 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 registration screen may also be performed by processor 401 on user terminal 400.

[0052] Figure 12 is a diagram representing the registration screen (SCB). The registration screen SCB displays an image representing the registration status in the display area ABA. The registration screen SCB represents buttons BBA and BBB. In the example in Figure 12, the image in display area ABA shows that three items have been registered, one each with product names "AAAAA," "BBBBB," and "CCCCC," with unit prices of 300 yen, 400 yen, and 700 yen respectively, and the reference price is 1400 yen. The reference price is calculated by subtracting discounts from various services such as coupons from the sum of the unit prices of all traded items. If the traded items and applicable services are not changed when the transaction is settled, this reference price will be the settlement amount. The image in display area ABA changes sequentially according to the registration status of the traded items. When processor 101 first executes ACT14 in Figure 8, the traded items have not yet been registered. Therefore, in the registration screen SCB represented by the screen data sent to the user terminal 400 when the processor 101 first executes ACT13 in Figure 8, the image placed in the display area ABA does not represent information about each product, but rather an image that indicates a total of 0 points and a reference price of 0 yen.

[0053] Button BBA is a soft key that receives instructions to transition to the state for scanning a new product. Button BBB is a soft key that receives instructions to start the checkout process. Note that the registration screen SCB and the various screens described later illustrate the main display objects, but the illustration of some display objects may be omitted. For example, the screen may include images to help the user visualize the operations they should perform. Also, the registration screen SCB and the various screens described later are just examples and may be determined as appropriate by, for example, the creator of the transaction processing program PRA.

[0054] The processor 401 displays the registration screen SCB on the touch panel 404 and waits for any operation to be performed by the user. When the processor 401 detects any operation by the user via the touch panel 404, it sends notification data to the communication network 2 from the wireless communication unit 406 to the transaction processing unit 100 to notify the user of the operation. The display of various screens in response to instructions from the transaction processing unit 100 and the notification of operation content based on each screen are all performed by the user terminal, including the processes described later.

[0055] 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. Furthermore, 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 will differ. Although not shown in the diagram, when the processor 101 receives notification of an operation, it updates the transaction data DAA so that the time of the previous operation included in the management data set in field FBD represents the current time.

[0056] As ACT15 in Figure 8, the processor 101 waits for an operation to be performed on the user terminal 400. Then, if the processor 101 is notified by 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 ACT16. As ACT16, 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 ACT17.

[0057] As ACT17, processor 101 checks whether the operation performed was an operation that specified 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 if an operation to cancel a transaction has been performed, executes the process to cancel the transaction, and then terminates the registration process. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0058] The user searches for the product they wish to trade within the store. If the user wishes to register a product as a new trading item, they perform a predetermined operation to initiate scanning, such as tapping button BBA on the registration screen SCB. Once this operation is notified from the user terminal 400 to the transaction processing unit 100, the processor 101 determines YES in ACT16 and proceeds to ACT21 in Figure 9. As ACT21, processor 101 instructs user terminal 400 to display the product scan screen. The product scan screen is a screen for scanning a barcode representing the product code.

[0059] Figure 13 is a diagram representing the product scanning screen (SCC). The product scan screen SCC includes a display area ACA and a button BCA. The display area ACA is an area for displaying the image obtained by camera 405. The button BCA is a soft key for the user to declare that they want to stop scanning the product code.

[0060] When the processor 401 displays the product scan screen SCC on the user terminal 400, it activates the camera 405 and overlays the image obtained by the camera 405 onto the display area ACA. However, if a predetermined operation to specify the start of scanning is performed, the processor 401 may generate the product scan screen and display it on the touch panel 404 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 ACT23 (described later) as ACT16, and if it determines YES in ACT16, it proceeds to ACT24 (described later) without performing ACT21 to ACT23 (described later). If any operation is performed by the user while the product scan screen SCC is displayed, the processor 401 notifies the transaction processing unit 100 of the details of that operation as described later.

[0061] When the product scan screen SCC is displayed on the touch panel 404, the user operates the user terminal 400 so that the barcode displayed on the product to be registered as a transaction product is captured within the display area ACA. The processor 401 analyzes the image obtained by the camera 405 and attempts to read the barcode. If the barcode is read, the processor 401 notifies the transaction processing device 100 that a scan operation has been performed, along with a notification of the data represented by the read barcode (hereinafter referred to as barcode data) (product scan notification). Furthermore, if a user wants to cancel the registration of a trading item and check its registration status, they will perform a predetermined action to specify that the scan be stopped, such as tapping the BCA button.

[0062] Once the processor 101 in the transaction processing unit 100 has finished instructing the display of the product scan screen as ACT21 in Figure 9, it proceeds to ACT22. As ACT22, processor 101 waits for an operation to be performed on user terminal 400. If the user terminal 400 notifies processor 101 of the operation details, it determines it is YES and proceeds to ACT23.

[0063] As ACT23, processor 101 checks whether the operation performed was an operation to specify a product. 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 confirms that an operation to cancel the scan was performed, such as tapping button BCA, and returns to ACT14 in Figure 8, returning the display screen of the touch panel 404 on the user terminal 400 to the registration screen SCB. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0064] As described above, if the processor 101 receives barcode data and the barcode data represents a product code, it determines YES in ACT23, indicating that an operation to specify a product has been performed, and proceeds to ACT24. As ACT24, 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 that the product identified by that product code should be traded (hereinafter referred to as a candidate product). Processor 101 may also determine the product assigned to the corresponding preset button as a candidate product upon receiving notification from user terminal 400 that an operation has been performed to tap a preset button displayed on touch panel 404. Alternatively, processor 101 may also determine the product identified by the product code as a candidate product upon receiving notification from user terminal 400 of a product code directly entered as a numerical string on touch panel 404. As ACT25, processor 101 instructs user terminal 400 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 data for the candidate product and have processor 401 on user terminal 400 generate the registration confirmation screen.

[0065] Figure 14 is a diagram representing the registration confirmation screen (SCD). The registration confirmation screen SCD is an example where the candidate product is named "DDDDD" and has a unit price of 250 yen. The registration confirmation screen SCD represents the display area ADA and the buttons BDA, BDB, BDC, and BDD. The display area ADA represents the quantity internally. Button BDA is a soft key for specifying a quantity decrease. Button BDB is a soft key for specifying a quantity increase. Button BDC is a soft key for specifying not to register as a trading product. Button BDD is a soft key for specifying to register as a trading product.

[0066] In Figure 9, as ACT26, processor 101 waits for an operation to be performed on user terminal 400. When processor 101 receives notification of the operation from user terminal 400, it determines YES and proceeds to ACT27. As ACT27, processor 101 checks whether a change in quantity has been specified. If processor 101 cannot confirm the relevant event, it determines NO and proceeds to ACT28.

[0067] As ACT28, 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 if a predetermined operation to cancel the registration has been performed, such as tapping button BDC, and returns to ACT21. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0068] If a user wishes to change the quantity, they specify the quantity change by performing a predetermined operation, such as tapping button BDA or button BDB. When such an operation is notified from the user terminal 400, the processor 101 determines it as YES in ACT27 and proceeds to ACT29. As ACT29, processor 101 updates the transaction data DAA to change the quantity according to the specification. After this, processor 101 returns to ACT14 in Figure 8, instructs user terminal 400 to display the registration screen SCB according to the updated transaction data as described above, and then returns to the waiting state of ACT15.

[0069] If the user decides to register the candidate product shown on the registration confirmation screen SCD as a trading product with the quantity shown in the display area ADA, they specify the registration by performing a predetermined operation, such as tapping the button BDD. When such an operation is notified from the user terminal 400, the processor 101 determines it as YES in ACT28 and proceeds to ACT30. As ACT30, processor 101 registers the candidate product as a transaction product with the quantity shown in the display area ADA. For example, processor 101 updates the transaction data DAA to include product data that shows the product code of the candidate product and the quantity shown in the display area ADA. When processor 101 executes ACT30 for the first time, it changes the status included in the management data set in the field FBD of the transaction data DAA to "Shopping". After this, processor 101 returns to ACT14 in Figure 8, instructs the user terminal 400 to display the registration screen SCB according to the transaction data updated as described above, and then returns to the waiting state for ACT15.

[0070] 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 button BBB on the registration screen SCB. When such an operation is notified from the user terminal 400, the processor 101 determines YES at ACT17 in Figure 8 and proceeds to ACT41 in Figure 10. Although not shown in the diagram, at this time the processor 101 changes the status in the management data set in the field FBD of the transaction data DAA to "Accounting in Progress". As ACT41, processor 101 checks whether the user code has already been obtained. If processor 101 can confirm, for example, that the user code is set in the FBC field of the transaction data DAA related to the transaction, it determines that it has been obtained and YES, and proceeds to ACT42. As ACT42, processor 101 instructs user terminal 400 to display the first selection screen. The first selection screen is a screen that allows the user to specify whether to use smartphone payment or payment via accounting machine. If a notification identifier is included in the instruction data for displaying the first selection screen, it is assumed that the notification identifier may be, for example, a notification requesting notification of whether to use smartphone payment or payment via accounting machine, or a notification that the user code has been obtained.

[0071] Figure 15 is a diagram representing the first selection screen SCE. The first selection screen, SCE, displays the total discount amount, the total number of items traded, the payment amount, and the user code as strings, along with buttons BEA and BEB. Button BEA is a soft key for selecting smartphone payment. Button BEB is a soft key for selecting payment via a payment machine.

[0072] On the other hand, if processor 101 confirms, for example, that the FBC field of the transaction data DAA related to the transaction is in a null state, it determines that the user code has not been obtained and verifies NO in ACT41, then proceeds to ACT43. As ACT43, processor 101 instructs user terminal 400 to display a second selection screen. The second selection screen is a screen that allows the user to specify payment via accounting machine. The second selection screen is, for example, a screen that disables button BEA, such as by not displaying button BEA or by graying out button BEA. If a notification identifier is included in the instruction data for instructing the display of the second selection screen, it is assumed that the notification identifier may be, for example, a notification requesting an instruction to execute payment via accounting machine, or a notification that the user code has not been obtained.

[0073] If an operation to specify the start of accounting is performed on the user terminal 400, the processor 401 may execute the above ACT41 to ACT43 processes on behalf of the processor 101. In this case, if the processor 101 in the transaction processing unit 100 determines YES in ACT17 in Figure 8, for example, it proceeds to ACT44 in Figure 10.

[0074] When a user makes a payment using the online payment service by operating the user terminal 400, they perform a predetermined operation to specify smartphone payment, such as tapping the button BEA displayed on the first selection screen SCE. When a user makes a payment using the accounting machine 200, they perform a predetermined operation to specify accounting machine payment, such as tapping the button BEB displayed on the first selection screen SCE or the second selection screen.

[0075] After completing the display instructions in ACT42 or ACT43, the processor 101 proceeds to ACT44 in either case. As ACT44, processor 101 waits for an operation to be performed on user terminal 400. If the above operation is notified from user terminal 400 to transaction processing unit 100, processor 101 determines it is YES and proceeds to ACT45.

[0076] As ACT45, processor 101 checks whether smartphone payment has been specified. 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 confirms that accounting machine payment has been specified and executes a process to have accounting machine 200 perform the settlement process for the transaction in progress. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0077] The process for having accounting machine 200 perform the payment processing is as follows, as an example: The processor 101 instructs the user terminal 400 to display the accounting screen. The accounting screen is used to transfer the accounting processing related to a transaction to the accounting machine 200. The accounting screen displays a barcode that represents information that the accounting machine 200 uses to inquire about the relevant transaction from the transaction processing unit 100. If multiple accounting machines 200 are installed in the store, the user can choose any unused accounting machine 200 and have the barcode scanner on that accounting machine 200 read the barcode displayed on the accounting screen. In response, the accounting machine 200 requests accounting data from the transaction processing unit 100 based on the information represented by the barcode read by the barcode scanner.

[0078] In the transaction processing unit 100, when the processor 101 receives a request for accounting data, it sends accounting data to the requesting accounting machine 200 to cause the accounting machine 200 to settle the requested transaction. At this time, the processor 101 updates the management data set in the field FBD of the transaction data DAA to include the accounting machine code of the requesting accounting machine 200. The processor 101 also updates the management data set in the field FBD of the transaction data DAA to include the accounting processing code notified by the requesting accounting machine 200. In this manner, the accounting machine 200, in response to the accounting data transmitted from the transaction processing device 100, displays a screen as appropriate, receives user input regarding accounting, and performs accounting processing based on the accounting data. This processing by the accounting machine 200 may be similar to the processing performed by the accounting machine in an existing POS system, for example.

[0079] Now, in the transaction processing device 100, if the user terminal 400, which is displaying the first selection screen SCE, performs the operation to specify smartphone payment as described above, and the process proceeds from ACT44 to ACT45 in Figure 10, the processor 101 determines YES at ACT45 and proceeds to ACT46. However, if the processor 101 instructs the display of the second selection screen at ACT43 because the user code has not been obtained, smartphone payment will not be specified, and the process will not proceed to ACT46. As ACT46, processor 101 instructs user terminal 400 to display the authorization code scan screen. The authorization code scan screen is a screen for scanning a barcode representing the authorization code. If a notification identifier is included in the instruction data for displaying the authorization code scan screen, it is assumed that the notification identifier will identify, for example, a notification requesting the input of an authorization code.

[0080] Figure 16 shows the authorization code scan screen (SCF). The authorization code scan screen SCF includes a display area AFA and a button BFA. Display area AFA is an area for displaying the image obtained by camera 405. Button BFA is a soft key for the user to declare that they want to cancel the smartphone payment. When the processor 401 displays the authorization code scan screen SCF on the user terminal 400, it activates the camera 405 and overlays the image obtained by the camera 405 onto the display area AFA.

[0081] Within a designated checkout area within the store, a 2D barcode representing an authorization code for pre-defined smartphone payments will be displayed. The 2D barcode can be displayed by installing a sign or posting printed materials. The checkout area is the area where online payment services are permitted. The checkout area may be determined as appropriate by the store operator for each store. The authorization code may be different for each store or may be common to multiple stores. A 1D barcode representing the authorization code may be displayed instead of the 2D barcode mentioned above.

[0082] The user moves to the checkout area and operates the user terminal 400 so that the two-dimensional barcode displayed as described above is visible within the display area AFA. The processor 401 analyzes the image obtained by the camera 405 and attempts to read the two-dimensional barcode. If the two-dimensional barcode is read, the processor 401 notifies the transaction processing unit 100 that a scan operation has been performed, along with a notification of the barcode data represented by the read two-dimensional barcode. Thus, the above-mentioned sign or printed material for displaying the two-dimensional barcode is considered a medium from which the user terminal 400 obtains the authorization code.

[0083] After completing the display instructions in ACT46, processor 101 proceeds to ACT47. As ACT47, processor 101 waits for an operation to be performed on user terminal 400. If the user terminal 400 notifies processor 101 of the operation details, it determines it is YES and proceeds to ACT48.

[0084] As ACT48, processor 101 checks whether or not an authorization code scan has been performed. 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 these other processes, processor 101 confirms that an operation to cancel smartphone payment has been performed, such as tapping button BFA, and returns to ACT42, returning the display screen of the user terminal 400's touch panel 404 to the first selection screen SCE. As another other process, processor 101 confirms that an operation to scan a barcode that does not represent an authorization code has been performed, displays an error, and returns to ACT46, returning the display screen of the user terminal 400's touch panel 404 to the authorization code scan screen SCF. The error display is a screen display to inform the operator that smartphone payment cannot be performed unless an authorization code is scanned. Other processes, or multiple processes, may be selectively performed as other processes, but a detailed explanation of these will be omitted here.

[0085] If the processor 101 receives an operation notification accompanied by barcode data representing an authorization code, it determines in ACT48 that the authorization code has been scanned and proceeds to ACT49.

[0086] As ACT49, processor 101 notifies user terminal 400 of a payment URL (uniform resource locator) for accessing the online payment service via the web and settling the transaction. Processor 101 includes, for example, an address for accessing the web server providing the online payment service (hereinafter referred to as the payment server) and payment data related to the transaction in the payment URL. Processor 101 can determine, for example, the payment amount and transaction code related to the transaction from the payment data. Processor 101 can determine, for example, the identifier of the online payment service merchant to which the store where the transaction takes place belongs from the payment data. Processor 101 can determine, for example, an identifier for the payment server to identify the transaction processing unit 100 from the payment data. Note that what information processor 101 can determine from the payment data is in accordance with the specifications of the online payment service. In addition, some of the information to be included in the payment data may be sent separately from user terminal 400 or transaction processing unit 100 to the payment server via communication without being included in the payment data.

[0087] When the processor 401 receives notification of a payment URL in the user terminal processing on the user terminal 400, it starts browser processing according to the browser program PRE installed on the user terminal 400 and passes the payment URL notified by the transaction processing unit 100 to this browser processing.

[0088] Processor 401, in browser processing, accesses the payment server based on the payment URL passed from the user terminal. Subsequently, in browser processing, processor 401 performs payment using the online payment service in accordance with instructions from the payment server and operations by the user. The procedure for payment using the online payment service may be one that is known from existing online payment services, for example, and therefore its explanation is omitted here. When the payment server completes the payment, it notifies the transaction processing unit 100, which is identified by an identifier determined from the payment data contained in the payment URL used for access, of the completion of the payment, along with the transaction identifier determined from the payment URL.

[0089] In the transaction processing unit 100, after the processor 101 notifies the payment URL as ACT49 in Figure 10, it proceeds to ACT50. As ACT50, processor 101 waits for completion notification. Then, as described above, if processor 101 receives notification from the payment server that the payment is complete, it determines YES and proceeds to ACT51. As ACT51, processor 101 instructs user terminal 400 to display a completion screen. The completion screen is a screen that allows the user to recognize that the transaction has been completed. If a notification identifier is included in the instruction data for displaying the completion screen, it is assumed that the notification identifier will, for example, identify a notification that payment has been completed. Although not shown in the diagram, at this time processor 101 changes the status included in the management data set in field FBD of transaction data DAA to "exit".

[0090] As ACT52, processor 101 performs the electronic receipt registration process. That is, processor 101 sends various data such as the user code, a list of transaction items, and the payment result to the electronic receipt server 600 in order to make the details of the transaction viewable in the electronic receipt service. The electronic receipt server 600 then stores the acquired data in the transaction database and makes the details of the transaction viewable in the electronic receipt service. This electronic receipt registration process may be the same as the process performed in existing electronic receipt services, for example, and a detailed explanation is omitted here. Therefore, the data that processor 101 sends to the electronic receipt server 600 conforms to the specifications of the electronic receipt service. Processor 101 then terminates the smartphone POS processing.

[0091] To use the cart POS service, the user performs a predetermined operation to initiate use on the unused cart terminal 500. As part of the operation to initiate use, the user can also input a user code into the cart terminal 500. Upon receiving such an operation, the processor 501 of the cart terminal 500 sends the check-in data, along with the terminal code COB of the cart terminal 500, to the transaction processing unit 100 via the wireless communication unit 506 to the communication network 2. If a user code has been entered, the processor 501 also sends the entered user code along with the check-in data. The check-in data, for example, the same as that represented by the check-in code, is pre-written in the auxiliary storage unit 503. However, the check-in data written to the auxiliary storage unit 503 may differ in part from the check-in data represented by the check-in code.

[0092] When check-in data is transmitted to the transaction processing unit 100 via the communication network 2, the transaction processing unit 100 receives the check-in 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 check-in data sent from the cart terminal 500 is received by the transaction processing device 100, the processor 101 starts transaction processing for the cart POS service (hereinafter referred to as cart POS processing) according to the transaction processing program PRA. Note that smartphone POS processing and cart POS processing may be described in separate application programs.

[0093] If processor 101 has already executed a cart POS process for a transaction involving a different user, it will start a new cart POS process as a separate thread from that process. Similarly, if processor 101 has already executed the aforementioned smartphone POS process, it will start a cart POS process as a separate thread from that smartphone POS process. In other words, processor 101 may execute multiple smartphone POS processes and cart POS processes in parallel. However, the following explanation will focus only on the processing of a transaction involving a single user. Thus, in the following explanation, "cart terminal 500" refers to a single cart terminal 500 used by a user for the cart POS process under consideration. Also, in the following explanation, "transaction" refers to the transaction that is the target of the process under consideration.

[0094] Figure 17 is a flowchart of the cart POS process. The processor 101 performs the same processes in both cart POS processing and smartphone POS processing as shown in Figures 8 and 9. However, the terminal used as the user interface in cart POS processing is the cart terminal 500. Furthermore, the various screens displayed on the touch panel 504 of the cart terminal 500 may be modified for the cart terminal 500. For example, if the cart terminal 500 is mounted on a shopping cart with the touch panel 504 in landscape orientation, the aforementioned portrait-oriented screens will be modified to adapt to landscape orientation. Also, for example, if the screen size of the touch panel 504 is larger than the screen size of the touch panel 404, the screens will be modified to display more information on a single screen than the aforementioned screens. However, the functions of the various screens described above will not be changed.

[0095] Upon receiving notification from the cart terminal 500 that an operation to instruct the start of checkout has been performed, the processor 101 proceeds to ACT61 in Figure 17. As ACT61, processor 101 instructs cart terminal 500 to display a selection screen. Similar to the first selection screen, the selection screen allows the user to specify whether to use smartphone payment or payment via the payment machine.

[0096] When the processor 501 in the cart terminal 500 receives instruction data for displaying the selection screen via the wireless communication unit 506, it displays the selection screen on the touch panel 504. However, the processor 401 may display the selection screen on the touch panel 404 without receiving a display instruction from the processor 101. In this case, the processor 101 may, for example, skip ACT61 and proceed to ACT62.

[0097] When a user makes a payment using an online payment service, they perform a predetermined operation to select smartphone payment, such as tapping the button displayed on the selection screen for smartphone payment. Similarly, when a user makes a payment using the payment terminal 200, they perform a predetermined operation to select payment terminal payment, such as tapping the button displayed on the selection screen for payment terminal payment.

[0098] As ACT62, processor 101 waits for an operation to be performed on the cart terminal 500. Then, if the above operation is notified from the cart terminal 500 to the transaction processing unit 100, processor 101 determines it is YES and proceeds to ACT63. As ACT63, processor 101 checks whether smartphone payment has been specified. 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 confirms that accounting machine payment has been specified and executes a process to have accounting machine 200 perform the settlement process for the transaction in progress. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0099] Now, in the transaction processing unit 100, if the processor 101 proceeds from ACT62 to ACT63 in response to the operation to specify smartphone payment as described above at the cart terminal 500, it determines YES at ACT63 and proceeds to ACT64. As ACT64, the processor 101 instructs the cart terminal 500 to display a first request screen. The first request screen is a screen that requests the user to scan an authorization code with the cart terminal 500. If the instruction data for instructing the display of the first request screen includes a notification identifier, it is assumed that the notification identifier identifies, for example, a notification requesting the input of an authorization code.

[0100] Furthermore, if the user selects smartphone payment on the selection screen of the cart terminal 500, the processor 501 may display the first request screen on the touch panel 504 without receiving any display instructions from the transaction processing unit 100. In this case, the processor 101 in the transaction processing unit 100 does not execute ACT64.

[0101] Figure 18 is a diagram representing the first request screen SCG. The first request screen (SCG) displays a text message requesting the user to scan the authorization code with the cart terminal 500. The first request screen (SCG) also displays a button (BGA). The button (BGA) is a soft key used to receive instructions to cancel the smartphone payment.

[0102] The user operates the cart terminal 500 to have the scanner 505 read the authorization code displayed in the checkout area. When the scanner 505 reads the two-dimensional barcode, the processor 501 notifies the transaction processing unit 100 that a scan operation has been performed, along with a notification of the barcode data represented by the two-dimensional barcode.

[0103] After completing the display instruction in ACT64 in Figure 17, processor 101 proceeds to ACT65. As ACT65, processor 101 waits for an operation to be performed on the cart terminal 500. If the processor 101 receives notification of the operation from the cart terminal 500, it determines it is YES and proceeds to ACT66.

[0104] As ACT66, processor 101 checks whether or not an authorization code has been scanned. 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 these other processes, processor 101 confirms that an operation to cancel smartphone payment has been performed, such as tapping button BGA, and returns to ACT61, returning the display screen of the cart terminal 500's touch panel 504 to the selection screen. As another other process, processor 101 confirms that an operation to scan a barcode that does not represent an authorization code has been performed, displays an error, and returns to ACT64, returning the display screen of the cart terminal 500's touch panel 504 to the first request screen SCG. The error display is a screen display to inform the operator that smartphone payment cannot be performed unless an authorization code is scanned. Other processes, or multiple processes, may be selectively performed as other processes, but a detailed explanation of these is omitted here.

[0105] If the processor 101 receives an operation notification accompanied by barcode data representing an authorization code, it determines in ACT66 that the authorization code has been scanned and proceeds to ACT68. As ACT67, processor 101 checks whether the user code has been obtained. If, as part of the operation to start using the cart terminal 500, the user code has not been entered into the cart terminal 500 and the check-in data has not been obtained because the user code has not been sent from the cart terminal 500 along with the check-in data, then processor 101 determines NO and proceeds to ACT68. As ACT68, the processor 101 instructs the cart terminal 500 to display a second request screen. The second request screen is a screen that requests the user to scan a user code with the cart terminal 500. If the instruction data for instructing the display of the second request screen includes a notification identifier, it is assumed that the notification identifier identifies, for example, a notification requesting the input of a user code.

[0106] Figure 19 is a diagram representing the second request screen SCH. The second request screen, SCH, displays a text message requesting the user to scan their user code with the cart terminal 500. In this text message, the user code is referred to as the "member code." The second request screen, SCH, also displays a button, BHA. Button BHA is a soft key used to receive instructions to cancel the smartphone payment.

[0107] The user displays a barcode representing their user code on the screen of an information and communication terminal such as a smartphone owned by the user, and has the scanner 505 of the cart terminal 500 scan this barcode. When the scanner 505 reads the barcode, the processor 501 notifies the transaction processing device 100 that a scan operation has been performed, along with a notification of the barcode data represented by the barcode.

[0108] After completing the display instruction in ACT68 in Figure 17, processor 101 proceeds to ACT69. As ACT69, processor 101 waits for an operation to be performed on the cart terminal 500. If the processor 101 receives notification of the operation from the cart terminal 500, it determines it is YES and proceeds to ACT70.

[0109] As ACT70, processor 101 checks whether or not a user code has been scanned. 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 these other processes, processor 101 confirms that an operation to cancel smartphone payment has been performed, such as tapping button BHA, and returns to ACT61, returning the display screen of the cart terminal 500's touch panel 504 to the selection screen. As another other process, processor 101 confirms that a barcode scanning operation that does not represent a user code has been performed, displays an error message to notify that the scanned barcode is incorrect, and then returns to ACT68, returning the display screen of the cart terminal 500's touch panel 504 to the second request screen SCH. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0110] If the processor 101 receives an operation notification accompanied by barcode data representing the user code, it determines in ACT70 that the user code has been scanned and proceeds to ACT71. If the processor 101 confirms that the user code has already been obtained and determines in ACT67 that it is OK, it proceeds to ACT71 without performing ACT68 to ACT70. As ACT71, processor 101 instructs cart terminal 500 to display a handover screen. The handover screen is for transferring a payment made using an online payment service to another information and communication terminal. Typically, a smartphone is used as this other information and communication terminal.

[0111] Figure 20 is a diagram representing the SCI (Screen Continuity Interface) screen for the user handover. The handover screen SCI represents the total amount of applicable discounts, the total number of items traded, the payment amount, and the user code as a string, as well as a 2D barcode CIA and a button BIA. The handover screen SCI also represents a text message requesting the user to have the 2D barcode CIA read by the information and communication terminal used for payment. The 2D barcode CIA represents handover data that includes a payment URL and a command requesting that the user perform web access using the payment URL. The button BIA is a soft key for receiving instructions to cancel smartphone payment. For example, the processor 101 generates the payment URL in the same way as the payment URL notified to the user terminal 400 in ACT49 in Figure 10.

[0112] The user, for example, uses the barcode reader function of their smartphone or other information and communication terminal to scan the 2D barcode CIA. In response, the information and communication terminal uses its browser function to access the payment server based on the payment URL contained in the transfer data represented by the 2D barcode CIA. Subsequently, the information and communication terminal uses its browser function to perform payment using the online payment service, in accordance with instructions from the payment server and operations performed by the user. The procedure for payment using the online payment service may be one that is known from existing online payment services, and therefore its explanation is omitted here.

[0113] In the transaction processing unit 100, after the processor 101 issues a display instruction as ACT71 in Figure 17, it proceeds to ACT72. As ACT72, processor 101 waits for completion notification. If processor 101 receives notification from the payment server that the payment has been completed as described above, it determines YES and proceeds to ACT73.

[0114] As ACT73, processor 101 instructs cart terminal 500 to display the completion screen. The completion screen is a screen that makes the user aware that the transaction has been completed. If a notification identifier is included in the instruction data for instructing the display of the completion screen, it is assumed that the notification identifier will, for example, identify a notification that payment has been completed. Although not shown in the diagram, at this time processor 101 changes the status included in the management data set in field FBD of transaction data DAA to "exit". As ACT74, processor 101 performs the electronic receipt registration process in the same manner as ACT52 in Figure 10. Processor 101 then terminates the cart POS processing.

[0115] Next, we will explain the operation that enables the attendant terminal 300 to check the status of each transaction processed by the above transaction processing. The processor 101 starts the confirmation support process in accordance with the transaction processing program PRA, as a separate thread from the smartphone POS processing and cart POS processing described above. The confirmation support process may also be written in a separate application program from the transaction processing program PRA.

[0116] Figure 21 is a flowchart of the verification support process. As ACT81, processor 101 extracts transaction data (hereinafter referred to as target transaction data) related to the transaction to be displayed on the status confirmation screen described later from the transaction data stored in auxiliary storage unit 103. When processor 101 first executes ACT81 after starting the verification support process, it extracts the target transaction data according to the default extraction conditions. In this embodiment, the extraction conditions are as follows. However, the extraction conditions may be determined as appropriate by, for example, the creator of the transaction processing program PRA.

[0117] The extraction criteria settings include "Number of items," "Status," "Device type," and "Device ID." For the "Number of items" setting, you can selectively set the target to "All items," "10 minutes ago," or "30 minutes ago," with "All items" being the default setting. For the "Status" setting, you can set the target to at least one of "Entering the store," "Shopping," "Paying," "Leaving the store," or "Cancelled," with all of these being the default setting. For the "Device type" setting, you can set the target to at least one of "Smartphone" or "Tablet," with both "Smartphone" and "Tablet" being the default setting. For the "Device ID" setting, you can set any string corresponding to at least a part of the device code as the key, with the default state being when this key is not set.

[0118] As ACT82, processor 101 instructs attendant terminal 300 to display a status confirmation screen. The status confirmation screen is a screen that allows the store clerk using attendant terminal 300 to confirm the status of the transaction. For example, processor 101 generates screen data representing the status confirmation screen and sends instruction data from communication unit 104 to the communication network 2 addressed to attendant terminal 300 to instruct it to display the screen based on this screen data.

[0119] When instruction data for screen display instructions is transmitted to the attendant terminal 300 via the communication network 2, the wireless communication unit 306 in the attendant terminal 300 receives the instruction data. Upon receiving the instruction data, the wireless communication unit 306 notifies the processor 301 of this fact. If the processor 301 has received instruction data for screen display instructions, it performs attendant terminal processing according to the attendant terminal program PRC to display the screen corresponding to the instruction data on the touch panel 304. The exchange of display instructions for the various screens described below is performed using the same procedure as above, although the content of the screen data may differ.

[0120] Figure 22 shows an example of the status confirmation screen for SCJ. The status confirmation screen SCJ represents the display areas AJA, AJB, and button BJA. Display area AJA shows the status of the extraction conditions. Display area AJB shows the transaction execution status for the target transaction data extracted by processor 101 in ACT81 in Figure 21. Button BJA is a soft key for receiving instructions to update the filtering conditions.

[0121] In the status confirmation screen SCJ, display area AJA indicates that all settings for all configuration items are at their default values ​​as described above. Specifically, for the "Number of Items" setting, the radio button associated with "All Items" is turned on, while the radio buttons associated with "10 minutes ago" and "30 minutes ago" are turned off, indicating that the "Number of Items" setting applies to "All Items". For the "Status" setting, all five checkboxes associated with "Entering Store", "Shopping", "Paying", "Leaving Store", and "Cancelled" are checked, indicating that the setting applies to all of these states. For the "Device Type" setting, both the two checkboxes associated with "Smartphone" and "Tablet" are checked, indicating that the setting applies to both "Smartphone" and "Tablet". For the "Device ID" setting, the associated input field is left blank, indicating that no key has been set.

[0122] The Display Area AJB represents a list of the transaction status corresponding to each of the target transaction data. The list displayed in the Display Area AJB shows information for each of the following items for one transaction per row: "Terminal ID", "Transaction No.", "Journey Time", "Previous Operation Time", "Registered Items", "Status", "Accounting Machine No.", "Accounting Transaction No.", and "Cancellation Flag". The "Terminal ID" item represents the terminal code set in the FBB field of the target transaction data. If a user code is set in the FBC field of the target transaction data, a mark indicating this will be displayed to the left of the terminal code. The "Transaction No." item represents the transaction code set in the FBA field of the target transaction data. The "Journey Time" item represents the elapsed time from the start time to the current time, as included in the management data set in the FBD field of the target transaction data. The "Previous Operation Time" item represents the previous operation time, as included in the management data set in the FBD field of the target transaction data. The "Registered Items" item represents the sum of the quantities included in each of the product data set in each of the fields from FBE onwards in the target transaction data. The "Status" field contains information that is included as a status in the management data set in the FBD field of the target transaction data. The "Accounting Machine No." field contains the accounting machine code if it is included in the management data set in the FBD field of the target transaction data. The "Accounting Transaction No." field contains the accounting processing code if it is included in the management data set in the FBD field of the target transaction data. The "Cancellation Flag" field contains information that indicates the status of the cancellation flag included in the management data set in the FBD field of the target transaction data. In the example shown in Figure 22, the number of digits that can be displayed for the "Terminal ID" item is limited to 7 digits. Therefore, it is not possible to display the entire 32-digit terminal code, and the processor 301 displays only the upper 7 digits. When one of the pieces of information represented in the "Terminal ID" item in the display area AJB is specified by a predetermined operation, such as a tap, the processor 301 displays the entire terminal code if the information represents only a part of the terminal code.

[0123] As ACT83, processor 101 checks whether it is time to update the status confirmation screen. If processor 101 cannot confirm the relevant event, it determines NO and proceeds to ACT84. As ACT84, processor 101 checks whether or not a notification of the extraction conditions has been sent from attendant terminal 300. If processor 101 cannot confirm the relevant event, it determines NO and proceeds to ACT85. As ACT85, processor 101 checks whether an operation other than the operation to change the extraction conditions was performed on attendant terminal 300. If processor 101 cannot confirm the relevant event, it determines NO and returns to ACT83. Thus, processor 101 waits for ACT83 to ACT85 to be updated, for extraction conditions to be notified, or for other operations to be performed.

[0124] Processor 101, upon reaching a predetermined update timing, determines YES in ACT83 and repeats ACT81 onward. At this time, the transaction data extracted as target transaction data in ACT81 is the same as the transaction data extracted in the previous ACT81. However, if the content of the target transaction data has changed due to the progress of the transaction, the information displayed in the display area AJB of the status confirmation screen, which is displayed as ACT82, is updated. The update timing is expected to be, for example, when the elapsed time since the previous execution of ACT82 exceeds a predetermined time. Alternatively, the update timing is expected to be, for example, when it is confirmed that the transaction data extracted as target transaction data when ACT82 was previously executed has been updated. However, the update timing may be determined as appropriate by the creator of the transaction processing program PRA, etc.

[0125] If the store clerk wishes to change the extraction criteria for the transaction displayed on the status confirmation screen, they perform a predetermined operation to instruct the change. In the attendant terminal 300, the processor 301 changes the display in the display area AJA according to the operation. First example: For instance, if a store clerk wants to change the setting item "Number of items to display" to "10 minutes ago" when the status confirmation screen SCJ shown in Figure 22 is displayed, they tap the radio button associated with "10 minutes ago". In response to this operation, the processor 301 enables the tapped radio button and disables the other radio buttons. Second example: For instance, when the status confirmation screen SCJ shown in Figure 22 is displayed, if a store employee wants to exclude the two "Leave Store" and "Cancel" settings from the "Status" category, they would tap the checkboxes associated with "Leave Store" and "Cancel," respectively. In response to this operation, processor 301 hides the check marks in the checkboxes associated with "Leave Store" and "Cancel." If a checkbox whose check mark is hidden is tapped, processor 301 will display a check mark in that checkbox. A third specific example: For instance, if a store clerk wants to narrow down the transactions displayed in the display area AJB to those that are subject to smartphone POS processing when the status confirmation screen SCJ in Figure 22 is displayed, they tap the checkbox related to the setting called "tablet". In response to this operation, the processor 301 hides the check mark in the checkbox associated with the setting called "tablet". A fourth specific example: For example, if a store clerk wants to narrow down the transactions displayed in the display area AJB to those that are subject to cart POS processing when the status confirmation screen SCJ in Figure 22 is displayed, they tap the checkbox related to the setting called "smartphone". In response to this operation, the processor 301 hides the check mark in the checkbox associated with the setting called "smartphone". Fifth specific example: For example, if a store clerk wants to narrow down the transactions shown in the display area AJB to those using a terminal whose terminal code starts with "3" when the status confirmation screen SCJ in Figure 22 is displayed, they would enter "3" in the input field for the setting called "Terminal ID". In response to this operation, the processor 301 displays "3" in the corresponding input field.

[0126] The store clerk then instructs the store clerk to update the conditions by performing a predetermined operation, such as tapping button BJA, when the display area AJA matches the desired conditions. In response to this operation, the processor 301 sends notification data from the wireless communication unit 306 to the transaction processing unit 100 via the communication network 2 to notify the settings currently displayed in the display area AJB.

[0127] If the transaction processing unit 100 receives notification from the communication unit 104 that it has received notification data sent from the attendant terminal 300 to notify the settings as described above, the processor 101 determines YES in ACT84 in Figure 21 and proceeds to ACT86. As ACT86, processor 101 changes the extraction conditions for the target transaction data in response to the notification. Then processor 101 repeats ACT81 onwards as described above. At this time, processor 101 re-extracts the target transaction data with the changed extraction conditions and then instructs attendant terminal 300 to display a new status confirmation screen based on the newly extracted target transaction data.

[0128] Here, the setting item called "Terminal ID" included in the notification data represents the content of the specification of at least one of the first terminal type, "smartphone," and the second terminal type, "tablet." Thus, when the processor 101 changes the extraction conditions based on the notification data, it accepts the above specification. Thus, by the processor 101 executing information processing based on the transaction processing program PRA, the computer with the processor 101 as its central part functions as a receiving means. Furthermore, if the notification data includes a key, the processor 101 acquires the key when modifying the extraction conditions based on the notification data. Thus, by having the processor 101 perform information processing based on the transaction processing program PRA, the computer with the processor 101 as its central component functions as an acquisition means.

[0129] Figure 23 shows an example of the status confirmation screen SCK. The status confirmation screen SCK is an example of the results after modifying the extraction conditions according to the second and third specific examples described above. Processor 101, through the modification in the second specific example, excludes transaction data from the status confirmation screen SCJ in Figure 22 whose status in the management data set in field FBD is "closed" or "cancelled." In other words, processor 101 includes transaction data related to transactions with transaction code "11" as target transaction data in the status confirmation screen SCJ, but does not include it as target transaction data in the status confirmation screen SCK because its "status" is "closed" and its terminal code is a single digit.

[0130] Furthermore, due to the modifications in the third specific example, when displaying the status confirmation screen SCJ in Figure 22, the processor 101 excludes transaction data from the target transaction data where the terminal code set in field FBB identifies the cart terminal 500. The processor 101 extracts transaction data where a 32-digit terminal code is set in field FBB as target transaction data. In this embodiment, the terminal code of the user terminal 400 is 32 digits, and the terminal code of the cart terminal 500 is 3 digits or less. Therefore, the processor 101 only needs to determine that a 32-digit terminal code is set if, for example, the terminal code set in field FBB is 4 digits or more. In other words, the processor 101 includes transaction data related to transactions with transaction codes "14" and "15" as target transaction data in the status confirmation screen SCJ, but does not include them as target transaction data in the status confirmation screen SCK because the terminal code is not 4 digits or more.

[0131] Figure 24 shows an example of the status confirmation screen SCL. The status confirmation screen SCL is an example of the results after modifying the extraction conditions according to the second and fourth specific examples described above. Processor 101, through the modification in the second specific example, excludes transaction data from the status confirmation screen SCJ in Figure 22 whose status in the management data set in field FBD is "closed" or "cancelled." In other words, processor 101 includes transaction data related to transactions with transaction code "11" as target transaction data in the status confirmation screen SCJ, but does not include it as target transaction data in the status confirmation screen SCL because its "status" is "closed" and its terminal code is a single digit.

[0132] Furthermore, due to the modifications in the fourth specific example, when displaying the status confirmation screen SCJ in Figure 22, the processor 101 excludes transaction data from the target transaction data where the terminal code set in field FBB identifies the user terminal 400. The processor 101 extracts transaction data where a 1- to 3-digit terminal code is set in field FBB as target transaction data. In this embodiment, for example, the processor 101 can determine that a 1- to 3-digit terminal code is set if the terminal code set in field FBB is 3 digits or less. In other words, the processor 101 includes transaction data related to transactions with transaction codes "10", "12", and "13" as target transaction data in the status confirmation screen SCJ, but does not include them as target transaction data in the status confirmation screen SCL because the terminal code is not 3 digits or less.

[0133] Figure 25 is a diagram showing an example of a status confirmation screen in SCM. The status confirmation screen SCM is an example of the result after changing the extraction conditions according to the fifth specific example above. Processor 101, through the modification described in the fifth specific example, excludes transaction data from the status confirmation screen SCJ displayed in Figure 22 where the first digit of the terminal code set in field FBB is not "3". In other words, while Processor 101 includes transaction data for transactions with a transaction code of "12" as target transaction data on the status confirmation screen SCJ, it does not include it as target transaction data on the status confirmation screen SCM because the first digit of the terminal code is not "3". In this way, when the "device type" setting is configured to target both "smartphones" and "tablets," processor 101 performs filtering by prefix matching of the device code.

[0134] Figure 26 shows an example of the status confirmation screen SCN. The status confirmation screen SCN is an example of the status confirmation screen SCK in Figure 23, after further modifying the extraction conditions to set the key for the setting item "Terminal ID" to "31918". When displaying the status confirmation screen SCK in Figure 23, processor 101 excludes transaction data from the target transaction data if the first five digits of the terminal code set in field FBB are not "31918". In other words, processor 101 includes transaction data for transactions with transaction codes "16" and "19" as target transaction data on the status confirmation screen SCK, but does not include them as target transaction data on the status confirmation screen SCN because the first five digits of the terminal code are not "31918". In this way, when the "device type" setting is configured to target only "smartphones," processor 101 performs filtering by prefix matching of the device code.

[0135] Figure 27 shows an example of the status confirmation screen (SCO). The status confirmation screen SCO is an example of the status confirmation screen SCL shown in Figure 24, after further modifying the extraction conditions by setting the key for the "Terminal ID" setting item to "3". When displaying the status confirmation screen SCL in Figure 24, processor 101 excludes transaction data from the target transaction data if the terminal code set in field FBB is not "3". In other words, processor 101 includes transaction data for transactions with transaction codes "14" and "18" as target transaction data in the status confirmation screen SCL, but does not include them as target transaction data in the status confirmation screen SCO because the terminal code is not "3". If the "Device Type" setting in processor 101 is set to target only "Tablets," then it will perform filtering by matching all entries in the device code. This matching is also referred to as an exact match or full-digit match.

[0136] Each shopping status screen, as described above, narrows down the multiple transactions being processed by the transaction processing system to those processed using terminal devices belonging to a specified terminal type. Information regarding these narrowed-down transactions is then displayed on the attendant terminal 300 using the touch panel 304 as a display device, under the direction of the processor 101 of the transaction processing system 100. Thus, by having the processor 101 execute information processing based on the transaction processing program PRA, the computer with the processor 101 as its central component functions as both a filtering means and a display means.

[0137] When the status confirmation screen is displayed on the touch panel 304, if any operation other than changing the extraction conditions is performed, the processor 301 sends notification data to the communication network 2 from the wireless communication unit 306 to the transaction processing unit 100 to notify the details of that operation.

[0138] When notification data sent from the attendant terminal 300 as described above to notify the details of the 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. Upon receiving the above notification, processor 101 determines YES in ACT85, confirms the content of the operation, and proceeds to other processes to perform the appropriate action. As one of these other processes, processor 101 instructs attendant terminal 300 to display a screen showing the details of the transaction, such as a list of transaction products, in response to an operation to select one of the transactions displayed on the status confirmation screen. As another other process, processor 101 updates the status confirmation screen to sort the display order of each transaction in the display area AJB by comparing the values ​​of the items corresponding to the headings displayed in the specified field, in response to an operation to select a column representing a heading in the display area AJB of the status confirmation screen. Other processes, or multiple processes, may be selectively performed as other processes, but a detailed explanation of these will be omitted here. The status confirmation screen for the sorting process may be updated by the processor 301.

[0139] As described above, the transaction processing device 100 provides in parallel a smartphone POS service using the user terminal 400 as the user interface and a cart POS service using the cart terminal 500 as the user interface. The transaction processing device 100 can display the transaction status on the attendant terminal 300, focusing on transactions using the smartphone POS service, as shown in the status confirmation screen SCK in Figure 23. The transaction processing device 100 can also display the transaction status on the attendant terminal 300, focusing on transactions using the cart POS service, as shown in the status confirmation screen SCL in Figure 24. This simplifies the process of checking the status of each transaction when multiple transactions are being used with a mix of different types of terminal devices, such as the user terminal 400 and the cart terminal 500.

[0140] When the transaction processing device 100 displays a status confirmation screen on the attendant terminal 300 for transactions that are eligible for the smartphone POS service, and a key is set, it narrows down the transactions to those that match the terminal code with the key, and displays them as shown in the status confirmation screen SCN in Figure 26. This allows users to narrow down the transactions to be displayed on the status confirmation screen without having to enter, for example, the entire lengthy 32-digit terminal code.

[0141] When the transaction processing device 100 displays a status confirmation screen on the attendant terminal 300 for transactions that are subject to the cart POS service, and a key is set, it narrows down the transactions to those that match all terminal codes and keys, and displays the status confirmation screen SCO as shown in Figure 27. For example, if terminal codes "1" to "30" are set for 30 cart terminals 500, if the key "1" is filtered by prefix matching, the number of terminal codes will be narrowed down to "1", "10" to "19", and only 11 out of the total 30 terminals will be narrowed down. However, by using full matching, it is possible to narrow it down to just one terminal. This makes it easy for users to check the status of transactions using the desired cart terminal 500.

[0142] When the transaction processing device 100 displays a status confirmation screen on the attendant terminal 300 for both transactions covered by the smartphone POS service and transactions covered by the cart POS service, and a key is set, it narrows down the transactions to those selected by a prefix match between the terminal code and the key, and displays them as shown in the status confirmation screen SCM in Figure 25. This allows users to narrow down the transactions to be displayed on the status confirmation screen without having to enter, for example, the entire lengthy 32-digit terminal code.

[0143] This embodiment can be modified in various ways as follows: In the above embodiment, the transaction processing device 100 is described as performing various processes to cause the attendant terminal 300 to display a screen for confirming the status of the transaction, but the embodiment is not limited to this. For example, the transaction data DAA is managed by the transaction processing device 100 as in the above embodiment, but some or all of the processes ACT81 to ACT86 in Figure 21 may be performed by the attendant terminal 300.

[0144] Alternatively, in place of either the user terminal 400 or the cart terminal 500, or in addition to them, the store may lend a portable terminal device to the user as a user interface terminal. In this case, the processor 101 may specify that the loaned terminal device is of the same type as either the user terminal 400 or the cart terminal 500, or it may be of a different type from either the user terminal 400 or the cart terminal 500.

[0145] When filtering based on the transaction key to be displayed on the status confirmation screen, partial matching may be applied to partial matching other than prefix matching. Furthermore, the application method of filtering for each setting of the "Terminal Type" setting item can be changed as desired.

[0146] Some of the processing performed by processor 101 in the transaction processing unit 100 may be executed by processors 401 and 501 in the user terminal 400 or cart terminal 500. For example, transaction data may be stored in auxiliary storage units 403 and 503, and its updates may be performed by processors 401 and 501.

[0147] Each function realized by the processor 101 through information processing 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 above-mentioned hardware, such as logic circuits, with software control.

[0148] 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. [Explanation of symbols]

[0149] 1...Transaction processing system, 2...Communication network, 100...Transaction processing device, 200...Accounting machine, 300...Attendant terminal, 400...User terminal, 500...Cart terminal, 600...Electronic receipt server, 101, 301, 401, 501...Processor, 102, 302, 402, 502...Main storage unit, 103, 303, 403, 503...Auxiliary storage unit, 104...Communication unit, 304, 404, 504...Touch panel, 305, 405...Camera, 306, 406, 506...Wireless communication unit, 505...Scanner.

Claims

1. It is used in a transaction processing system that processes multiple transactions in parallel using multiple terminal devices, each belonging to either the first terminal type or the second terminal type. A receiving means for receiving the designation of at least one of the first terminal type and the second terminal type, A filtering means for narrowing down from among multiple transactions being processed in the transaction processing system to transactions that are processed using the terminal device belonging to the terminal type specified by the receiving means, A display means for displaying information about transactions narrowed down by the aforementioned filtering means on a display device, An information display device equipped with the following.

2. means of obtaining a key, Furthermore, The filtering means filters out transactions processed using terminal devices that belong to the terminal type designated by the receiving means, and whose identifiers have a predetermined relationship with respect to a key acquired by the acquisition means, based on predetermined conditions. The information display device according to claim 1.

3. If the target of the designation received by the receiving means is the first terminal type, the filtering means narrows down the transactions to those processed using terminal devices belonging to the first terminal type, where part of the identifier matches the key obtained by the acquisition means. The information display device according to claim 2.

4. If the target of the designation received by the receiving means is the second terminal type, the filtering means narrows down the transactions to those processed using terminal devices belonging to the second terminal type whose identifiers all match the key obtained by the acquisition means. The information display device according to claim 2.

5. If the designation received by the receiving means is for both the first terminal type and the second terminal type, the filtering means narrows down the transactions to those processed using terminal devices belonging to the first terminal type and terminal devices belonging to the second terminal type, where part of the identifier matches the key obtained by the acquisition means. The information display device according to claim 2.

6. A computer installed in an information display device used in a transaction processing system that processes multiple transactions in parallel using multiple terminal devices, each belonging to either the first terminal type or the second terminal type, A receiving means for receiving the designation of at least one of the first terminal type and the second terminal type, A filtering means for narrowing down from among multiple transactions being processed in the transaction processing system to transactions that are processed using the terminal device belonging to the terminal type specified by the receiving means, A display means for displaying information about transactions narrowed down by the aforementioned filtering means on a display device, An information processing program that enables a function to work.

Images