Transaction processing system, product sales system, and information processing program

Abstract

The objective is to provide a transaction processing device and information processing program that can restrict the use of a store during certain hours within its operating hours. [Solution] The transaction processing device of the embodiment comprises registration means and control means. The registration means registers a product specified by a user operating on a terminal device within the store as a transaction product. The control means controls the registration means to start registering the transaction product for a given transaction only if the predetermined operation for starting the registration of the transaction product for that transaction is performed within a predetermined time period.

Description

Technical Field

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

Background Art

[0002] A system 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 is known as a "smartphone POS system" or the like. Alternatively, a transaction processing system that performs transaction processing using an information communication terminal attached to a shopping cart provided in a store as a user interface is known as a "cart POS system" or the like. In such a transaction processing system, it has been desired to be able to restrict the use during a certain time period even within the business hours of the store.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The problem to be solved by the present invention is to provide a transaction processing device, a product sales system, and an information processing program capable of restricting the use during a part of the time period within the business hours of the store.

Means for Solving the Problems

[0005] The transaction processing device of this embodiment includes registration means and control means. The registration means registers a product specified by a user operating on a terminal device within a store as a transaction product. The control means controls the registration means to start registering the transaction product for a given transaction only if the predetermined operation for starting the registration of the transaction product for that transaction is performed within a predetermined time period. [Brief explanation of the drawing]

[0006] [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 of user terminal processing. [Figure 9] A flowchart of user terminal processing. [Figure 10] A flowchart for smartphone POS processing. [Figure 11] A flowchart for smartphone POS processing. [Figure 12] A flowchart for smartphone POS processing. [Figure 13] A diagram showing an unavailable screen. [Figure 14] A diagram representing the registration screen. [Figure 15] A diagram showing the product scanning screen. [Figure 16] A diagram showing the registration confirmation screen. [Figure 17] Figure showing the first selection screen. [Figure 18] Figure showing the permission code scan screen. [Figure 19] Flowchart of cart terminal processing. [Figure 20] Flowchart of cart terminal processing. [Figure 21] Flowchart of cart POS processing. [Figure 22] Figure showing the first request screen. [Figure 23] Figure showing the second request screen. [Figure 24] Figure showing the transfer screen. [Figure 25] Figure showing a modification example of user terminal processing. [Figure 26] Figure showing a modification example of the content of one data record included in the store database.

Mode for Carrying Out the Invention

[0007] 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 a transaction processing device 100, a cash register 200, an attendant terminal 300, a user terminal 400, a cart terminal 500, and an electronic receipt server 600 can communicate via a communication network 2. The communication network 2 can be used alone or in an appropriate combination, such as the Internet, a VPN (virtual private network), a LAN (local area network), a public communication network, a mobile communication network, etc. As an example, the Internet and a mobile communication network are used in combination as the communication network 2. Note that the transaction processing device 100, the cash register 200, the attendant terminal 300, the user terminal 400, and the cart terminal 500 may each be included in the transaction processing system 1 in any number, but only one of each is shown in FIG. 1.

[0008] 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 transactions of goods between a user and a store, according to operations performed by the user as they move around the sales floor in the store, using the accounting machine 200, user terminal 400, and cart terminal 500 as terminal devices for the user interface. In other words, typically, a customer who purchases goods in 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. Since the transaction processing service processes the buying and selling transactions of goods, it is an example of a product sales system.

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

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

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

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

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

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

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

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

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

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

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

[0020] 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 configuration information necessary for providing transaction processing services at the associated store. In other words, the configuration information represents the various settings for providing transaction processing services at each store. The configuration information includes, for example, information indicating the time period during which the transaction processing service is permitted at the store (hereinafter referred to as the available time period). Field FAC contains payment method information indicating the payment methods permitted when settling the payment for transactions processed by the transaction processing service at the associated store using an online payment service. If the same configuration information is to be applied to multiple stores operated by the same company, the company code to identify the company may be set in field FAA instead of the store code. Also, if the same store code can be used by different companies, both the company code and the store code may be set in field FAA. Furthermore, the various setting information set in the Field FAB is updated as appropriate by the processor 101, for example, by receiving access via the communication network 2 from any information and communication terminal, and in response to instructions from a store manager or the like who operates the information and communication terminal.

[0021] 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 multiple transaction data DAA may be stored in the auxiliary storage unit 103 simultaneously.

[0022] The transaction data DAA includes fields FBA, FBB, and FBC. The transaction data DAA may include any number of fields starting from field FBD. 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. If there are registered products that are the subject of the transaction in question (hereinafter referred to as transaction products), fields FBD, FBE, ... associated with each transaction product are added to the transaction data DAA. Fields FBD, FBE, ... each contain product data for a separate transaction product. The product data includes the product code and quantity as identifiers for the transaction product in question. The product data may also include various other information, such as product name, unit price, and discount information.

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

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

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

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

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

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

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

[0030] 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. Similarly, 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 memory 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 memory 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, such as those standard on smartphones, can be used as is. 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.

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

[0032] 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. The general functions of the touch panel 504 and wireless communication unit 506 are also equivalent to those of the touch panel 304 and wireless communication unit 306. However, the auxiliary memory 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 procedures of the processor 501 for operating the cart terminal 500 as a user interface for transaction processing by the transaction processing unit 100. The wireless communication unit 506 typically includes an existing wireless communication device for a wireless LAN. However, the wireless communication unit 506 may include, in addition to or instead of the above-mentioned communication device, a well-known communication device for data communication over a mobile communication network.

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

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

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

[0036] Figures 8 and 9 are flowcharts of user terminal processing. As ACT111, processor 401 displays the top screen on touch panel 404. The top screen is a screen that allows the user to specify the function to be executed from among the various functions realized by user terminal processing. The top screen represents soft keys for receiving check-in instructions.

[0037] Stores that offer the smartphone POS service will display a check-in code, which represents the check-in data, at the store entrance or inside the store. The check-in code is, for example, a 2D barcode. The check-in data includes at least the store code. Therefore, the check-in code will be different for each store.

[0038] If a user wants to start using the smartphone POS service at a store, they will perform predetermined actions, such as tapping a soft key displayed on the top screen, to receive instructions to check in. As ACT112, processor 401 displays the top screen and waits for some operation by the user. If any operation by the user is detected, for example, by touch panel 404, processor 401 determines YES and proceeds to ACT113.

[0039] As ACT113, processor 401 checks whether the operation performed was an operation to instruct a check-in. Then, processor 101 determines NO if it cannot confirm the relevant event, checks the content of the operation, and proceeds to other processes to perform the appropriate action. As one of the other processes, processor 101 may, for example, confirm that an operation to instruct abort has been performed, cancel the check-in procedure, and restart the process from ACT111. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0040] If the operation to instruct the check-in has been performed as described above, processor 401 will determine YES in ACT113 and proceed to ACT114. As ACT114, processor 401 displays the check-in screen on touch panel 404. The check-in screen is a screen that guides the user to take a picture of the check-in code with the camera 405 of the user terminal 400. As ACT115, processor 401 waits for some action to be taken by the user. If processor 401 confirms that some action has been taken by the user, it determines YES and proceeds to ACT116.

[0041] The user operates the user terminal 400 according to the check-in screen and has the camera 405 of the user terminal 400 photograph the check-in code displayed at the store they are using. The user's operation of the user terminal 400 at this time is an example of the operation to start registering the transaction items for a single transaction using the smartphone POS service. Even if a 2D barcode is captured by the camera 405, the processor 401 determines YES in ACT115, assuming that an operation to read the 2D barcode has been performed, and proceeds to ACT116.

[0042] As ACT116, processor 401 checks whether the check-in coder was read by the operation performed above. If processor 401 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 401 may check if an operation to read a 2D barcode has been performed, but the 2D barcode in question is not a check-in code, and then display a screen to notify the user of such an operational error. Other processes, or multiple processes, may be performed selectively as other processes, but a detailed explanation of these will be omitted here.

[0043] If the check-in code has been captured by the camera 405, the processor 401 determines in ACT116 that the check-in code has been read by the operation performed above, and proceeds to ACT117. As ACT117, processor 401 requests a check-in from transaction processing unit 100. For example, processor 401 sends request data for the check-in request from wireless communication unit 406 to communication network 2 addressed to transaction processing unit 100. Processor 401 includes the check-in data represented by the check-in code captured by camera 405 and the terminal code of user terminal 400 in the above request data. The terminal code is stored, for example, in auxiliary storage unit 403. As the terminal code, for example, an identifier determined by the operating system of user terminal 400 during the installation of the user terminal program PRD can be used. This identifier is, for example, a 32-digit code containing a mixture of alphanumeric characters.

[0044] 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. If the user code is stored as described above, the processor 401 then includes the user code in the request data.

[0045] When request data for a check-in request is transmitted to the transaction processing unit 100 via the communication network 2, the transaction processing unit 100 receives the request data via the communication unit 104 and temporarily stores it in the main storage unit 102 or the auxiliary storage unit 103. In this manner, when the request data sent from the user terminal 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.

[0046] 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 the user terminal program PRD is started, send check-in data including location information acquired using GPS (global positioning system) or other positioning sensors to the transaction processing device 100. When the transaction processing device 100 receives the above location information, it may, for example, retrieve the setting information of the store where the user terminal 400 that sent the location information is located from a database that represents setting information associated with the location information, and perform the check-in process according to this setting information.

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

[0048] Figures 10, 11, and 12 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 10, as ACT211, 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 contained in the setting 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 ACT212. Note that the available time period may be determined as appropriate for each store.

[0049] As ACT212, 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.

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

[0051] 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."

[0052] On the user terminal 400, the processor 401 requests a check-in at ACT117 in Figure 8, and then proceeds to ACT118. As ACT118, processor 401 waits for a response to the check-in request. If instruction data instructing the display of some screen is received by wireless communication unit 406, processor 401 determines that a response has been made and YES, and proceeds to ACT119.

[0053] As ACT119, processor 401 checks whether or not the display of the unavailable screen has been instructed. If, as described above, the display of the unavailable screen has been instructed, processor 401 determines it to be YES and proceeds to ACT120. As ACT120, processor 401 displays an unavailable screen on touch panel 404.

[0054] If the received instruction data includes screen data, the processor 401 displays the screen represented by that screen data directly on the touch panel 404. If the received instruction data includes 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 includes 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 is carried out using the same procedure as above, although the content of the screens being displayed may differ.

[0055] Figure 13 shows the SCA (Screen Counters Affected) screens that are unavailable. 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. The processor 101 displays this unavailable screen SCA on the user terminal 400 to notify the user that they cannot start registering transaction items using the smartphone POS service because it is outside of the available hours. Thus, by having the processor 101 execute the smartphone POS processing based on the transaction processing program PRA, the computer with the processor 101 as its central component functions as a notification means.

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

[0057] On the other hand, if the current time is included in the available time period, processor 101 determines YES at ACT211 in Figure 10 and proceeds to ACT213. After this, processor 101 performs processing for registering trading products, as will be described later. Thus, by having processor 101 perform information processing based on the trading processing program PRA, the computer with processor 101 as its central component functions as a control means.

[0058] As ACT213, 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.

[0059] In Figure 10, as ACT214, processor 101 instructs user terminal 400 to display the registration screen in response to the check-in request. 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 be performed by processor 401 on user terminal 400.

[0060] If the processor 401 in the user terminal 400 receives instruction data for displaying the registration screen and determines YES at ACT118 in Figure 8, and proceeds to ACT119, it determines NO because it is not an instruction to display the unavailable screen, and proceeds to ACT121. As ACT121, processor 401 displays the registration screen on touch panel 404.

[0061] Figure 14 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 14, 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 coupon services 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 ACT214 in Figure 10, 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 ACT213 in Figure 10, 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.

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

[0063] If the processor 401 displays the registration screen SCB on the touch panel 404, it proceeds to ACT131 in Figure 9. As ACT131, processor 401 waits for some kind of operation to be performed by the user. If any operation by the user is detected by touch panel 404, processor 401 determines it to be YES and proceeds to ACT132. As ACT132, processor 401 checks whether it is necessary to notify the transaction processing unit 100 of the operation that has been performed. If the operation performed is not one of the operations predetermined to be subject to notification, processor 401 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 401 may scroll the registration screen in response to a scroll operation. Other processes, or multiple processes, may be selectively performed as other processes, but a detailed explanation of these will be omitted here.

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

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

[0066] In Figure 10, as ACT215, 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 ACT216. As ACT216, 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 ACT217.

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

[0068] The user searches for the product they wish to trade within the store. When the user registers a product as a new trading item, they perform a predetermined operation to specify the start of scanning, such as tapping button BBA on the registration screen SCB. This operation is subject to notification, and the processor 401 in the user terminal 400 determines YES in both ACT131 and ACT132 in Figure 9, proceeds to ACT133, and sends notification data to notify the user of the operation to start scanning.

[0069] Once the user terminal 400 has notified the transaction processing unit 100 of the operation to initiate scanning, the processor 101 determines YES at ACT216 in Figure 10 and proceeds to ACT221 in Figure 11. As ACT221, 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.

[0070] On the user terminal 400, the processor 401 notifies the user of the operation details in ACT133 in Figure 9, and then proceeds to ACT134. As ACT134, processor 401 checks whether a display instruction has been given. If processor 401 cannot confirm the relevant event, it determines NO and proceeds to ACT135. As ACT135, processor 401 checks whether or not a payment URL has been notified. If processor 401 cannot confirm the event, it determines NO and returns to ACT134. Thus, the processor 401 awaits notification of display instructions or payment URLs as ACT134 and ACT135.

[0071] Then, if the processor 401 receives instruction data from the transaction processing unit 100 that instructs the display of some screen, and this is received by the wireless communication unit 406, it determines YES in ACT 134 and proceeds to ACT 136. As ACT136, processor 401 updates the display screen on touch panel 404 in response to instructions. In other words, in response to the instruction to display the above-mentioned product scan screen, processor 401 updates the display screen on touch panel 404 to the product scan screen. As ACT137, processor 401 checks whether the updated display screen is the completion screen described later. If the screen has been updated to a screen other than the completion screen, such as when it was updated to the product scan screen as described above, processor 401 determines NO and returns to the waiting state of ACT131. In other words, processor 401 transitions to a state where it waits for operations related to the updated screen.

[0072] Figure 15 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.

[0073] 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 described in ACT223 as ACT216, and if it determines YES in ACT216, it proceeds to ACT224 described in the same way, without performing ACT221 to ACT223 described in the same way.

[0074] 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 determines that this operation is subject to notification, and proceeds to ACT133, where it notifies the transaction processing device 100 that a scan operation has been performed, along with 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 product and check its registration status, they perform a predetermined operation to specify the cancellation of the scan, such as tapping button BCA. This operation is notifiable, and the processor 401 determines YES in both ACT131 and ACT132 in Figure 9 and proceeds to ACT133, notifying the transaction processing unit 100 that an operation to instruct the cancellation of the scan has been performed.

[0075] In the transaction processing unit 100, once the processor 101 has finished instructing the display of the product scan screen as ACT221 in Figure 11, it proceeds to ACT222. As ACT222, processor 101 waits for an operation to be performed on user terminal 400. If an operation is notified from user terminal 400, processor 101 determines it is YES and proceeds to ACT223.

[0076] As ACT223, 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 ACT214 in Figure 10, 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. Furthermore, the operation to cancel the scan is not subject to notification from the user terminal 400. Instead, the process of returning the display screen of the touch panel 404 on the user terminal 400 to the registration screen SCB, as described above, may be autonomously executed by the processor 401 on the user terminal 400 after it has determined NO in ACT132.

[0077] As described above, if the processor 101 receives barcode data and the barcode data represents a product code, it determines in ACT223 that an operation to specify a product has been performed and proceeds to ACT224. As ACT224, 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 sequence on touch panel 404. In this way, the processor 101 and the touch panel 404 or camera 405 work together to realize the function of inputting a product code as identification information for identifying products.

[0078] As ACT225, 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 candidate product data and have processor 401 on user terminal 400 generate the registration confirmation screen. When the processor 401 in the user terminal 400 receives instruction data for displaying the registration confirmation screen, it determines YES in ACT134 in Figure 9 and proceeds to ACT136, updating the display screen of the touch panel 404 to the registration confirmation screen. Then, since the updated screen is not the completion screen, the processor 401 determines NO in ACT137 and returns to the waiting state of ACT131.

[0079] Figure 16 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.

[0080] In Figure 11, as ACT226, processor 101 waits for an operation to be performed on the user terminal 400. When the user terminal 400 notifies processor 101 of the operation details, it determines it is YES and proceeds to ACT227. As ACT227, 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 ACT228.

[0081] As ACT228, 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 ACT221. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here.

[0082] 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. This operation is notifiable, and the processor 401 on the user terminal 400 determines YES in both ACT131 and ACT132 in Figure 9 and proceeds to ACT133, notifying the transaction processing unit 100 that an operation to instruct a quantity change has been performed. In response to this notification, the processor 101 on the transaction processing unit 100 determines YES in ACT227 in Figure 11 and proceeds to ACT229. As ACT229, processor 101 updates the transaction data DAA to change the quantity according to the specification. After this, processor 101 returns to ACT214 in Figure 10, instructs user terminal 400 to display the registration screen SCB corresponding to the updated transaction data as described above, and then returns to the waiting state of ACT215.

[0083] 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 YES in ACT228 and proceeds to ACT230. As ACT230, processor 101 registers the candidate product as a trading product with the quantity shown in the display area ADA. For example, processor 101 updates the trading data DAA to include product data that represents the product code of the candidate product and the quantity shown in the display area ADA. Thus, by having processor 101 perform information processing based on the trading processing program PRA, the computer with processor 101 as its central component functions as a registration means. After this, processor 101 returns to ACT214 in Figure 10, instructs the user terminal 400 to display the registration screen SCB corresponding to the trading data updated as described above, and then returns to the waiting state of ACT215.

[0084] Once the user has finished registering all the transaction items for this transaction, they specify the start of accounting by performing a predetermined operation, such as tapping the button BBB on the registration screen SCB. This operation is notifiable, and the processor 401 on the user terminal 400 determines YES in both ACT131 and ACT132 in Figure 9 and proceeds to ACT133, notifying the transaction processing unit 100 that the operation to instruct the start of accounting has been performed. In response to this notification, the processor 101 on the transaction processing unit 100 determines YES in ACT217 in Figure 10 and proceeds to ACT241 in Figure 12. As ACT241, 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 ACT242.

[0085] As ACT242, 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.

[0086] When the processor 401 in the user terminal 400 receives instruction data for displaying the first selection screen, it determines YES at ACT134 in Figure 9 and proceeds to ACT136, updating the display screen of the touch panel 404 to the first selection screen. Then, since the updated screen is not the completion screen, the processor 401 determines NO at ACT137 and returns to the waiting state of ACT131.

[0087] Figure 17 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.

[0088] 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 ACT241 in Figure 12, and proceeds to ACT243. As ACT243, 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.

[0089] When the processor 401 in the user terminal 400 receives instruction data for displaying the second selection screen, it determines YES at ACT134 in Figure 9 and proceeds to ACT136, updating the display screen of the touch panel 404 to the second selection screen. Then, since the updated screen is not the completion screen, the processor 401 determines NO at ACT137 and returns to the waiting state of ACT131.

[0090] If an operation to specify the start of accounting is performed on the user terminal 400, the processor 401 may execute the above processes ACT241 to ACT243 on behalf of the processor 101. In this case, if the processor 101 in the transaction processing unit 100 determines YES at ACT217 in Figure 10, for example, it proceeds to ACT244 in Figure 12.

[0091] 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. Alternatively, 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. These operations are subject to notification, and the processor 401 determines YES in both ACT131 and ACT132 in Figure 9 and proceeds to ACT133, notifying the transaction processing unit 100 that an operation to specify smartphone payment or accounting machine payment has been performed.

[0092] After completing the display instructions in ACT242 or ACT243 in Figure 12, the processor 101 proceeds to ACT244 in either case. As ACT244, 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 ACT245.

[0093] As ACT245, processor 101 checks whether smartphone payment is 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 is specified and executes a process to have accounting machine 200 perform the settlement of 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.

[0094] 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. When the processor 401 in the user terminal 400 receives instruction data for displaying the accounting screen, it determines YES in ACT134 in Figure 9 and proceeds to ACT136, updating the display screen of the touch panel 404 to the accounting screen. Then, since the updated screen is not the completion screen, the processor 401 determines NO in ACT137 and returns to the waiting state of ACT131.

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

[0096] When the transaction processing unit 100 receives a request for accounting data, the processor 101 sends accounting data to the requesting accounting machine 200 so that the accounting machine 200 can settle the requested transaction. 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.

[0097] 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 ACT244 to ACT245 in Figure 12, the processor 101 determines YES at ACT245 and proceeds to ACT246. However, if the processor 101 instructs the display of the second selection screen at ACT243 because the user code has not been obtained, smartphone payment will not be specified, and the process will not proceed to ACT246.

[0098] As ACT246, 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. When the processor 401 in the user terminal 400 receives instruction data for displaying the authorization code scan screen, it determines YES in ACT134 in Figure 9 and proceeds to ACT136, updating the display screen of the touch panel 404 to the authorization code scan screen. Then, since the updated screen is not the completion screen, the processor 401 determines NO in ACT137 and returns to the waiting state of ACT131.

[0099] Figure 18 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.

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

[0101] 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, this operation is subject to notification, and the processor 401 determines YES in both ACT131 and ACT132 in Figure 9 and proceeds to ACT133, notifying the transaction processing device 100 that a scan operation has been performed, along with 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 corresponds to the medium from which the user terminal 400 obtains the authorization code.

[0102] After completing the display instruction at ACT246 in Figure 12, processor 101 proceeds to ACT247. As ACT247, processor 101 waits for an operation to be performed on user terminal 400. If an operation is notified from user terminal 400, processor 101 determines it is YES and proceeds to ACT248.

[0103] As ACT248, 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 ACT242, 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 ACT246, 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.

[0104] If the processor 101 receives an operation notification accompanied by barcode data representing an authorization code, it determines in ACT248 that the authorization code has been scanned and proceeds to ACT249. As ACT249, 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.

[0105] When the processor 401 on the user terminal 400 receives notification of the payment URL, it determines YES at ACT135 in Figure 9 and proceeds to ACT138. As ACT138, processor 401 initiates browser processing according to the browser program PRE installed on user terminal 400. If browser processing is already running, processor 401 skips this step. As ACT139, processor 401 passes the settlement URL notified by transaction processing unit 100 to the browser process launched above.

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

[0107] In the transaction processing unit 100, after the processor 101 notifies the payment URL as ACT249 in Figure 12, it proceeds to ACT250. As ACT250, 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 ACT251. As ACT251, 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.

[0108] When the processor 401 receives instruction data for displaying the completion screen on the user terminal 400, it determines YES at ACT134 in Figure 9 and proceeds to ACT136, updating the display screen of the touch panel 404 to the completion screen. Since the updated screen is the completion screen, the processor 401 determines YES at ACT137 and proceeds to other processes. As one of these other processes, the processor 401 returns to ACT111 in Figure 8 in response to an operation such as tapping a soft key displayed on the completion screen. Other processes, or multiple processes, may be selectively performed as other processes, but a detailed explanation of these is omitted here.

[0109] In Figure 12, the processor 101, designated as ACT252, performs electronic receipt registration processing. Specifically, the 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 so that the details of the transaction can be viewed on the electronic receipt service. Thus, by executing information processing based on the transaction processing program PRA, the computer with the processor 101 as its central component functions as a transmission means.

[0110] The electronic receipt server 600 then stores the acquired data in a transaction database and makes the transaction details viewable through the electronic receipt service. This electronic receipt registration process may be the same as the process performed in existing electronic receipt services, and a detailed explanation of it is omitted here. Therefore, the data that the 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.

[0111] When the cart terminal 500 is in the startup state, the processor 501 executes cart terminal processing according to the cart terminal program PRF. Figures 19 and 20 are flowcharts of the cart terminal processing. As ACT311, processor 501 displays the home screen on touch panel 504. The home screen is a screen that allows the operator to specify the function to be executed from among the various functions realized by the cart terminal processing. The home screen represents soft keys for receiving instructions from the user to start using the system.

[0112] If a user wishes to start using the cart POS service at a store, they initiate use by performing a predetermined operation, such as tapping a soft key displayed on the home screen shown on the touch panel 504 of the unused cart terminal 500. The operation of the cart terminal 500 by the user in this case is an example of an operation to start registering the transaction items for a single transaction using the cart POS service. As ACT312, the processor 501 displays the home screen and waits for some operation to be performed by the user. If any operation by the user is detected, for example, by the touch panel 504, the processor 501 determines it is YES and proceeds to ACT313.

[0113] As ACT313, processor 501 checks whether the operation performed was an operation to instruct the system to begin use. 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. One example of other processes that processor 101 may perform is maintenance in response to an operation by an authorized person such as a store employee. Other processes, or multiple processes, may be performed selectively, but a detailed explanation of these will be omitted here.

[0114] If the operation to instruct the system to start using the system has been performed as described above, the processor 501 will determine YES in ACT313 and proceed to ACT314. As ACT314, processor 501 displays a member verification screen on touch panel 504. The member verification screen is a screen that asks the user whether or not they are a member. The member verification screen displays soft keys for the user to indicate that they are a member and soft keys for the user to indicate that they are not a member.

[0115] Users declare their membership status by performing a predetermined action, such as tapping a soft key to indicate they are a member. Alternatively, users declare their non-member status by performing a predetermined action, such as tapping a soft key to indicate they are not a member.

[0116] As ACT315, processor 501 waits for some operation to be performed by the user. If processor 501 confirms that some operation has been performed by the user, it determines YES and proceeds to ACT316. As ACT316, processor 501 checks whether the above operation has resulted in a declaration of membership. If processor 501 cannot confirm the event, it determines NO and proceeds to ACT317.

[0117] As ACT317, processor 501 checks whether the above operation has declared that the user is not a member. If processor 501 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 501 checks whether an operation to cancel the start of use has been performed and returns to ACT311. Other processes, or multiple processes, may be selectively performed as other processes, but a detailed explanation of these will be omitted here.

[0118] If processor 501 confirms that an operation to declare membership has been performed, it determines YES in ACT316 and proceeds to ACT318. As ACT318, processor 501 obtains the member code. For example, processor 501 extracts the member code from the barcode data represented by the barcode scanned by scanner 505 from the member card held over the scanner 505 by the user. Then processor 501 attempts to obtain the user code related to the user identified by the member code. Note that the member code and user code may be the same, and in this case, obtaining the member code as described above may be considered obtaining the user code. Alternatively, if a user code is associated with the obtained member code in a database (not shown), processor 501 may obtain that user code.

[0119] Processor 501 then proceeds to ACT319. If processor 501 confirms that an operation to declare that the user is not a member has been performed, it will determine YES in ACT317, skip ACT318, and proceed to ACT319. As ACT319, processor 501 requests a check-in from transaction processing unit 100. For example, processor 501 sends request data for the check-in request from wireless communication unit 506 to communication network 2 addressed to transaction processing unit 100. Processor 501 includes the check-in data stored in auxiliary storage unit 503 and the terminal code of the cart terminal 500 in the above request data. The terminal code is stored in auxiliary storage unit 503, for example. If processor 501 has obtained a user code in ACT318, it also includes the user code in the request data. The check-in data is pre-written in auxiliary storage unit 503, for example, the same as that represented by the check-in code. However, the check-in data written to auxiliary storage unit 503 may differ in part from the check-in data represented by the check-in code. A terminal code is assigned to each cart terminal 500 in advance and written to the auxiliary storage unit 503, so that each of the multiple cart terminals 500 used in the same store can be identified, and so as not to overlap with the terminal code of the user terminal 400. For example, a number from "1" to "999" is used as the terminal code for the cart terminal 500.

[0120] When the request data is transmitted to the transaction processing unit 100 via the communication network 2, the transaction processing unit 100 receives the request data via the communication unit 104 and temporarily stores it in the main storage unit 102 or the auxiliary storage unit 103. In this manner, when the request data sent from the 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.

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

[0122] Figure 21 is a flowchart of the cart POS processing. The processor 101 performs the same processes in both cart POS processing and smartphone POS processing as shown in Figures 10 and 11. 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 504, the various screens will be modified to display more information on a single screen than those mentioned above. However, the functions of the various screens mentioned above will not be changed.

[0123] Thus, even if an attempt is made to use the cart terminal 500 outside of the available hours, the processor 101 will display a screen on the cart terminal 500 with a function similar to the unavailable screen SCA, thereby notifying the user that they cannot start registering transaction items using the cart POS service because it is outside of the available hours. In this way, by the processor 101 executing the cart POS processing based on the transaction processing program PRA, the computer with the processor 101 as its central component functions as a notification means.

[0124] Therefore, at the cart terminal 500, after requesting a check-in with ACT319 in Figure 19, the processor 501 executes ACT320~ACT323 and ACT331~ACT33 in Figure 20 in the same way as ACT118~ACT121 in Figure 8 and ACT131~ACT133 in Figure 9. After notifying the operation details via ACT333, processor 501 proceeds to ACT334. As ACT334, processor 501 awaits a display instruction. When instruction data sent from transaction processing unit 100 to instruct the display of some screen is received by wireless communication unit 506, processor 501 determines it to be YES and proceeds to ACT335.

[0125] As ACT335, processor 501 updates the display screen on touch panel 504 in response to instructions. As ACT336, processor 501 checks whether the updated display screen is the handover screen described later. If the screen has been updated to anything other than the handover screen, processor 501 determines NO and returns to the waiting state of ACT331. In other words, processor 501 transitions to a state where it waits for operations related to the updated screen.

[0126] In the transaction processing device 100, the processor 101 proceeds to ACT261 in Figure 21 when it receives notification from the cart terminal 500 that an operation to instruct the start of accounting has been performed. As ACT261, 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.

[0127] When the processor 501 receives instruction data for displaying the selection screen via the wireless communication unit 506 in the cart terminal 500, it determines YES at ACT334 in Figure 20 and proceeds to ACT335, updating the display screen of the touch panel 504 to the selection screen. Then, since the updated screen is not a carryover screen, the processor 501 determines NO at ACT366 and returns to the waiting state of ACT331. However, the processor 501 may display the selection screen on the touch panel 504 without receiving a display instruction from the processor 101. In this case, the processor 101 may, for example, skip ACT261 and proceed to ACT262.

[0128] When a user makes a payment using an online payment service, they perform a predetermined operation to specify smartphone payment, such as tapping a button displayed on the selection screen for smartphone payment. When a user makes a payment using the accounting machine 200, they perform a predetermined operation to specify accounting machine payment, such as tapping a button displayed on the selection screen for accounting machine payment. These operations are subject to notification, and the processor 501 determines that both ACT331 and ACT332 in Figure 20 are YES, proceeds to ACT333, and notifies the transaction processing unit 100 that an operation to specify smartphone payment or accounting machine payment has been performed.

[0129] In Figure 21, as ACT262, 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 ACT263. As ACT263, processor 101 checks whether smartphone payment is 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 is 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.

[0130] Now, in the transaction processing unit 100, if the processor 101 proceeds from ACT262 to ACT263 in response to the operation to specify smartphone payment as described above in the cart terminal 500, it determines YES in ACT263 and proceeds to ACT264. As ACT264, 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.

[0131] 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 ACT264.

[0132] Figure 22 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.

[0133] The user operates the cart terminal 500 to have the scanner 505 read the authorization code displayed in the checkout area. If the scanner 505 reads the 2D barcode, this operation is subject to notification, and the processor 501 determines YES in both ACT331 and ACT332 in Figure 20 and proceeds to ACT333, notifying the transaction processing unit 100 that a scan operation has been performed, along with the notification of the barcode data represented by the 2D barcode.

[0134] After completing the display instruction in ACT264 in Figure 21, processor 101 proceeds to ACT265. As ACT265, 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 ACT266.

[0135] As ACT266, 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 ACT261, 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 ACT264, 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.

[0136] If the processor 101 receives an operation notification accompanied by barcode data representing an authorization code, it determines in ACT266 that the authorization code has been scanned and proceeds to ACT267. At this point, the processor 101 detects that the cart terminal 500 is in an acceptable state, located within the checkout area. Thus, by executing information processing based on the transaction processing program PRA, the computer with the processor 101 as its central component functions as a detection means.

[0137] As ACT267, 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 ACT268.

[0138] As ACT268, 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.

[0139] When the processor 501 in the cart terminal 500 receives instruction data for displaying the second request screen via the wireless communication unit 506, it determines YES at ACT334 in Figure 20 and proceeds to ACT335, updating the display screen of the touch panel 504 to the second request screen. Then, since the updated screen is not a handover screen, the processor 501 determines NO at ACT366 and returns to the waiting state of ACT331.

[0140] Figure 23 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.

[0141] The user displays a barcode representing their user code on the screen of an information and communication terminal, such as a smartphone, and has the scanner 505 of the cart terminal 500 scan this barcode. If the scanner 505 reads the barcode, this operation is subject to notification, and the processor 501 determines YES in both ACT331 and ACT332 in Figure 20 and proceeds to ACT333, notifying the transaction processing device 100 that a scan operation has been performed, along with the notification of the barcode data represented by the barcode.

[0142] After completing the display instruction in ACT268 in Figure 21, processor 101 proceeds to ACT269. As ACT269, 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 ACT270.

[0143] As ACT270, 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 ACT261, 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 ACT268, 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.

[0144] If the processor 101 receives an operation notification accompanied by barcode data representing the user code, it determines in ACT270 that the user code has been scanned and proceeds to ACT271. If the processor 101 confirms that the user code has already been obtained and determines in ACT267 that it is OK, it proceeds to ACT271 without performing ACT268 to ACT270.

[0145] As ACT271, 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. When the processor 501 in the cart terminal 500 receives instruction data for displaying the handover screen via the wireless communication unit 506, it determines YES at ACT334 in Figure 20 and proceeds to ACT335, updating the display screen of the touch panel 504 to the handover screen.

[0146] Figure 24 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 by ACT249 in Figure 12.

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

[0148] Thus, displaying the handover screen SCI on the cart terminal 500 corresponds to having the information communication terminal perform information processing for payment using the online payment service, and to the process of transferring the payment amount to that process. The processor 101 starts this process only when it is detected that the cart terminal 500 is located within the checkout area. In this way, the computer with the processor 101 as its central component functions as a processing means by having the processor 101 execute information processing based on the transaction processing program PRA.

[0149] In the transaction processing unit 100, processor 101 issues an instruction to display the handover screen as ACT271 in Figure 21, and then proceeds to ACT272. As ACT272, processor 101 checks whether a completion notification has been issued. If processor 101 cannot confirm the relevant event, it determines NO and proceeds to ACT273. As ACT273, processor 101 checks whether or not any operation has been performed by the user. If processor 101 cannot confirm the relevant event, it determines NO and returns to ACT272. Thus, the processor 101 awaits completion notifications or operations as ACT272 and ACT273.

[0150] If, in the cart terminal 500, the processor 501 displays the handover screen at ACT335 in Figure 20 and then proceeds to ACT366, it determines YES and proceeds to ACT337. As ACT337, processor 501 checks whether or not any operation has been performed by the user. If processor 501 cannot confirm the relevant event, it determines NO and proceeds to ACT338. As ACT338, processor 501 checks whether a display instruction has been given. If processor 501 cannot confirm the relevant event, it determines NO and returns to ACT337. Thus, the processor 501, as ACT337 and ACT338, awaits operation or display instructions.

[0151] When the user performs an operation such as tapping the BIA button displayed on the handover screen, and this is detected by the touch panel 504, the processor 501 determines YES in ACT337 and proceeds to ACT332, repeating the subsequent processing as described above. Pre-defined operations for instructing the user to cancel a smartphone payment, such as tapping the BIA button, are subject to notification, and the processor 501 determines YES in both ACT331 and ACT332 in Figure 20, proceeds to ACT333, and notifies the transaction processing unit 100 of the operation.

[0152] In the transaction processing device 100, if the processor 101 receives notification of an operation from the cart terminal 500 in this manner, it determines YES at ACT273 in Figure 21 and proceeds to other processes to perform processing according to the content of the notified operation. As one of the other processes, the processor 101 confirms that an operation to cancel smartphone payment has been performed, returns to ACT261, and returns the display screen of the cart terminal 500's touch panel 504 to the selection screen. Other processes, or multiple processes, may be performed selectively, but a detailed explanation of these will be omitted here.

[0153] Once the payment server has completed the payment processing initiated by receiving an access based on the payment URL, it notifies the transaction processing unit 100 of the completion of the payment, along with the transaction code determined from the payment URL. When the transaction processing unit 100 receives notification of completion in this manner, the processor 101 determines YES in ACT272 in Figure 21 of the ongoing cart POS processing for the transaction identified by the transaction code also notified, and proceeds to ACT273.

[0154] As ACT273, processor 101 instructs cart terminal 500 to display a 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. As ACT274, processor 101 performs the electronic receipt registration process in the same manner as ACT252 in Figure 12. Processor 101 then terminates the cart POS processing.

[0155] When the touch panel 504 in the cart terminal 500 receives instruction data for display instructions while the touch panel 504 is displaying the handover screen, the processor 501 determines YES in ACT338 in Figure 20 and proceeds to ACT339. As ACT339, the processor 501 updates the display screen on the touch panel 504 according to the instructions given by the instruction data. If the processor 501 is instructed to display the completion screen as described above, it updates the screen on the touch panel 504 to the completion screen.

[0156] As ACT340, processor 501 checks whether the updated display screen is a completion screen. Then, if processor 401 has updated to a completion screen as described above, it determines YES and proceeds to other processes. As one of the other processes, processor 501 returns to ACT311 in Figure 19 in response to an operation such as tapping a soft key displayed on the completion screen. Other processes may be performed selectively, or multiple processes may be performed, but a detailed explanation of these will be omitted here. In addition, there may be cases where, for example, when the user is instructed to cancel a smartphone payment, the touch panel 504 is displaying the handover screen and the user is instructed to display a screen other than the completion screen. In this case, the processor 501 determines NO at ACT340 and transitions to the standby state of ACT331.

[0157] As described above, according to this embodiment, the user terminal 400 and the cart terminal 500 will only start registering transaction items if the predetermined operation for starting the registration of transaction items for a single transaction is performed within the available time period. Thus, even during business hours, the use of the smartphone POS service and the cart POS service can be restricted to certain time periods. This allows for flexible operation according to the store's needs, such as restricting the use of the smartphone POS service and the cart POS service during times when it is not possible to have staff available to assist users of the smartphone POS service and the cart POS service.

[0158] Furthermore, according to this embodiment, if the registration of trading products is suppressed outside of the available hours, the user is notified of this fact by displaying an unavailable screen on the user terminal 400 and the cart terminal 500. This ensures that the user is reliably aware that the smartphone POS service and the cart POS service are unavailable.

[0159] This embodiment can be modified in various ways as follows: (First variation) The decision of whether or not to display the unavailable screen SCA may be made by the processor 401 on the user terminal 400, or by the processor 501 on the cart terminal 500. Figure 25 shows a modified example of user terminal processing in this case. Processor 401 executes in the same manner as in the above embodiment up to ACT118. In this modified example, in the transaction processing device 100, processor 101, in response to a check-in request, sends to the requesting user terminal 400, as a response to the check-in request, at least the setting information representing the available time period from the setting information associated with the store code included in the check-in data in the store database DBA, regardless of whether it is within the available time period or not.

[0160] If the processor 401 confirms in ACT118 that a response has been received from the transaction processing unit 100, it proceeds to ACT125. As ACT125, processor 401 checks whether the current time is within the available time period based on the configuration information transmitted from the transaction processing device 100 as described above. If it is not within the available time period, processor 401 determines NO and proceeds to ACT126. At this time, processor 401 has obtained the configuration information from the transaction processing device 100. Thus, by having processor 401 perform information processing based on the user terminal program PRD, the computer with processor 401 as its central component functions as an acquisition means.

[0161] As ACT126, processor 401 displays a predetermined unavailable screen SCA on touch panel 404. Thus, by having processor 401 perform information processing based on the user terminal program PRD, the computer with processor 401 as its central component functions as a control means to notify the user via touch panel 404, which acts as a display means, that the smartphone POS service is unavailable. If processor 401 confirms that it is within the available time period, it will determine YES in ACT125 and proceed to ACT121, and thereafter proceed with processing in the same manner as in the embodiment described above.

[0162] In the cart terminal 500, processor 501 should perform the same processing as processor 401 described above. In the case of the cart terminal 500, information representing the available time period may be stored in the auxiliary storage unit 503, and the processor 501 may check whether the current time is within the available time period based on the information stored in the auxiliary storage unit 503. The information representing the available time period may be downloaded from the transaction processing unit 100 or a server installed in the store and stored in the auxiliary storage unit 503 when the cart terminal 500 is started up, for example during store opening preparations, or it may be written to the auxiliary storage unit 503 as one of the operating settings of the cart terminal 500, such as during the initial setup of the cart terminal 500.

[0163] When a cart terminal 500 is put into use at a store, terminal authentication is performed on the cart terminal 500. For example, when the processor 501 is waiting for a barcode representing a product code to be scanned by the scanner 505, and a barcode representing an employee code (as an identifier for an employee) is scanned by the scanner 505, the processor 501 displays a terminal authentication screen on the touch panel 504 for entering the company code (as an identifier for the company operating the store), the store code, and the terminal code. After the company code, store code, and terminal code have been entered and an operation to start use has been performed, the processor 501 transmits authentication information, including the entered company code, store code, and terminal code, to the transaction processing unit 100. The processor 101 in the transaction processing unit 100 authenticates the cart terminal 500 as the cart terminal 500 identified by the terminal code at the store corresponding to the company code and store code, based on the authentication information transmitted from the cart terminal 500, and transmits an authentication completion response to the cart terminal 500. Upon receiving an authentication completion response from the transaction processing device 100, the cart terminal 500 transitions to an operational state where it can be used by the user at the store corresponding to the entered company code and store code. Alternatively, during this terminal authentication process, information indicating the available time period may be obtained from the transaction processing device 100 to the cart terminal 500 along with the authentication completion response and written to the auxiliary storage unit 503.

[0164] (Second variation) In response to a check-in request, the transaction processing device 100 may send various configuration information other than the configuration information representing the available time period to the user terminal 400 or cart terminal 500, in addition to the configuration information representing the available time period. Then, processor 101 or processor 401 controls various functions of the user terminal 400, and processor 101 or processor 501 controls various functions of the cart terminal 500 based on the configuration information. Alternatively, the processor 401 of the user terminal 400 or the processor 501 of the cart terminal 500 may obtain configuration information from the transaction processing unit 100 and then control various functions based on that configuration information.

[0165] For example, the following controls are conceivable. The configuration information for each of the following controls is set, for example, in the FAB field of the data record REA in the store database DBA. Thus, each control can be configured individually for each store. Figure 26 shows an example of how the contents of a data record REA can be changed. In the data record REA shown in Figure 26, the setting information set in field FAB includes, in addition to the setting information IAA representing the available time period as described above, setting information IAB, IAC, IAD, IAE, IAF, IAG, IAH, and IAI.

[0166] The configuration information IAB indicates whether or not to allow the use of smartphone payments. Based on the configuration information IAB, processor 101 or processors 401 and 501 switch, for example, whether or not to execute processing for smartphone payments. For example, based on the configuration information IAB indicating that the use of smartphone payments is not allowed, processor 101 or processor 401 does not display the first selection screen and does not receive a request to execute smartphone payments. Also, based on the configuration information IAB indicating that the use of smartphone payments is not allowed, processor 101 or processor 501 does not display or disable the button for selecting smartphone payments on the selection screen and does not receive a request to execute smartphone payments.

[0167] The configuration information IAC indicates whether the operation of value discount stickers is enabled or disabled. If the operation of value discount stickers is enabled, the configuration information IAC also indicates the type of value discount sticker to be enabled. Based on the configuration information IAC, processor 101 or processors 401, 501 switches, for example, whether to execute or not execute the process for reading value discount stickers.

[0168] The configuration information IAD indicates whether the check for forgotten shopping bags is enabled or disabled. Based on the configuration information IAD, processor 101 or processors 401, 501 switches, for example, whether to execute or not execute the process for checking for forgotten shopping bags. When the check for forgotten shopping bags is enabled, processor 101 or processors 401, 501 displays a screen on touch panel 404, 504 to ask the user whether they need a shopping bag, in response to an operation to start checkout. If the shopping bag has a barcode, this screen will guide the user to scan the barcode. If the shopping bag does not have a barcode, this screen will display a soft key to receive a request to purchase a shopping bag.

[0169] The configuration information IAE indicates whether the display of special offers (campaigns, promotions for discounted items, coupons, etc.) is enabled or disabled. Based on the configuration information IAE, processor 101 or processors 401, 501, for example, switches the execution of the process to display special offers on the user terminal 400 or cart terminal 500 at an appropriate time.

[0170] The configuration information IAF indicates whether the age verification screen is enabled or disabled when an age-restricted product is registered as a trading product. Based on the configuration information IAF, processor 101 or processors 401, 501, for example, switches the execution of the process to display the age verification screen on the user terminal 400 or cart terminal 500.

[0171] The configuration information IAG indicates whether or not each product can be set as eat-in or takeout. Based on the configuration information IAG, processor 101 or processors 401 and 501, for example, when a new candidate product is identified, switch between executing or not executing the process to determine whether that candidate product is eat-in or takeout.

[0172] The configuration information IAH indicates whether the fraud prevention function is enabled or disabled. Based on the configuration information IAH, processor 101 or processors 401 and 501 switch, for example, whether to execute or not execute the process to implement the fraud prevention function. One example of the fraud prevention function is a function that automatically takes a picture of the inside of the shopping cart at predetermined timings (for every item, or every time the registered content is changed), or displays a message prompting the user to take a picture, and saves the captured image. Another example of the fraud prevention function is a function that takes an image or sends a notification when it detects that an item not registered as a transaction item has been placed in the shopping cart.

[0173] The configuration information IAI indicates whether the automatic power ON / OFF function is enabled or disabled. If the automatic power ON / OFF function is enabled, the configuration information IAI also indicates the ON time, OFF time, and target days of the week. Based on the configuration information IAI, processor 101 or processor 501 switches, for example, whether to execute or not execute the process necessary to implement the automatic power ON / OFF function. The automatic power ON / OFF function is a function that automatically starts the operation of the cart terminal 500 at the ON time on the target days of the week and automatically stops it at the OFF time on the target days of the week.

[0174] (Other variations) Some or all of the processing performed by processor 101 in the transaction processing device 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. In this case, the registration means will be realized by information processing by processors 401 and 501.

[0175] The functions realized by processors 101, 301, 401, and 501 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 aforementioned hardware, such as logic circuits, with software control.

[0176] 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]

[0177] 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. A registration means for registering a product specified by a user through operation on a terminal device within the store as a trading product, A control means that controls the registration means to start registering trading products related to a transaction only if a predetermined operation for starting the registration of trading products related to a transaction is performed within a predetermined time period, A transaction processing device equipped with the following.

2. A notification means that performs a predetermined notification process to notify the user that registration of trading products cannot be performed by the registration means when a predetermined operation for initiating the registration of trading products related to a transaction is performed outside of a predetermined time period. The transaction processing apparatus according to claim 1, further comprising:

3. The notification means performs the notification process of causing the display device provided by the terminal device to display a screen indicating that the registration of the trading product by the registration means cannot be performed. The transaction processing apparatus according to claim 2.

4. Computers, A registration means for registering a product specified by a user through operation on a terminal device within the store as a trading product, A control means that controls the registration means to start registering trading products related to a transaction only if a predetermined operation for starting the registration of trading products related to a transaction is performed within a predetermined time period, An information processing program that enables a function to work.

5. A product sales system including a terminal device equipped with an input means for inputting identification information to identify a product, which enables a service that allows users to register products while walking around the sales floor, and a transaction processing device equipped with a registration means for registering products corresponding to the identification information entered by the input means as transaction products that are the subject of a transaction, The aforementioned terminal device is An acquisition means for acquiring setting information associated with a company or store from the transaction processing device, A control means that enables the input of product identification information via the input means only if the predetermined operation for initiating the registration of trading products related to a single transaction is performed within the time period specified in the setting information, and notifies the user via the display means that the service is unavailable if the operation is performed outside the time period, A product sales system equipped with the following features.

6. A computer in a product sales system that includes a terminal device equipped with an input means for inputting identification information to identify a product, and capable of providing a service that allows users to register products while walking around the sales floor, and a transaction processing device equipped with a registration means for registering products corresponding to the identification information entered by the input means as transaction products, is provided for use in the terminal device. Acquisition means for acquiring setting information associated with a company or store from the transaction processing device, A control means that enables the input of product identification information via the input means only if the predetermined operation for initiating the registration of trading products related to a single transaction is performed within the time period specified in the setting information, and notifies the user via a display means that the service is unavailable if the operation is performed outside the time period. A program that can function as such.

Images