Information processing program, information communication device, and information processing device

Abstract

To allow a user of a service of a transaction service provided in a store to easily notify a third party before settlement of a content of the transaction to be settled.SOLUTION: In a transaction processing system for generating transaction data indicating a content of a transaction according to an operation of a user interface terminal, an information processing program of an embodiment causes a computer provided to an information communication device being used as the user interface terminal to function as execution means, acquisition means, and delivery means. The execution means executes a function as the user interface terminal. The acquisition means acquires transaction data generated by the transaction processing system on the basis of a function executed by the execution means. The delivery means delivers previous confirmation data being determined at least as a part of data contained in the transaction data acquired by the acquisition means, to an information process executed by the computer for causing another information communication device to acquire arbitrary data.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] An embodiment of the present invention relates to an information processing program, an information communication device, and an information processing device. [Background technology]

[0002] There are often cases where a shopper other than the requester performs shopping at a store upon receiving a request from the requester. In such cases, when the shopper has finished picking up products at the store and is about to pay for them, the requester may wish to check the contents of the picked up products. In view of these circumstances, it has been desirable for users of transaction processing services provided at stores to be able to easily notify a third party of the details of the transaction they are about to settle before making the settlement. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2019-49794 A Summary of the Invention [Problem to be solved by the invention]

[0004] The problem that the present invention aims to solve is to provide an information processing program, an information communication device, and an information processing device that enable a user of a transaction processing service provided in a store to easily notify a third party of the details of a transaction to be settled before the payment. [Means for solving the problem]

[0005] The information processing program of the embodiment causes a computer provided in an information communication device used as a user interface terminal in a transaction processing system that generates transaction data representing the content of a transaction according to an operation on the user interface terminal to function as an execution means, an acquisition means, and a transfer means. The execution means executes the function as a user interface terminal. The acquisition means acquires transaction data generated by the transaction processing system based on the function executed by the execution means. The transfer means transfers, to information processing executed by a computer to cause any data to be acquired by another information communication device, pre-check data defined as at least a part of the data included in the transaction data acquired by the acquisition means.

Brief Description of Drawings

[0006] [Figure 1] Block diagram showing the schematic configuration of a transaction processing system according to an embodiment. [Diagram 2] Block diagram showing the main circuit configuration of the transaction processing device in FIG. 1. [Diagram 3] Diagram schematically showing the configuration of one data record included in the store database in FIG. 2. [Figure 4] Diagram schematically showing the configuration of the transaction data in FIG. 2. [Diagram 5] Block diagram showing the main circuit configuration of the attendant terminal in FIG. 1. [Figure 6] Block diagram showing the main circuit configuration of the user terminal in FIG. 1. [Figure 7] Block diagram showing the main circuit configuration of the cart terminal in FIG. 1. [Figure 8] Flowchart of user terminal processing. [Figure 9] Flowchart of user terminal processing. [Figure 10] Flowchart of user terminal processing. [Figure 11] Flowchart of smartphone POS processing. [Figure 12] Flowchart of smartphone POS processing. [Figure 13]Flowchart of smartphone POS processing. [Figure 14] FIG. [Figure 15] FIG. [Figure 16] A diagram showing the product scanning screen. [Figure 17] FIG. 13 is a diagram showing a registration confirmation screen. [Figure 18] FIG. 13 is a diagram illustrating a first selection screen. [Figure 19] FIG. [Figure 20] FIG. 13 is a diagram showing an authorization code scanning screen. [Figure 21] 13 is a flowchart of cart terminal processing. [Figure 22] 13 is a flowchart of cart terminal processing. [Diagram 23] 13 is a flowchart of cart terminal processing. [Figure 24] 13 is a flowchart of a cart POS process. [Diagram 25] FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] An example of an embodiment will be described below with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of a transaction processing system 1 according to this embodiment. Transaction processing system 1 is configured such that transaction processing device 100, accounting machine 200, attendant terminal 300, user terminal 400, cart terminal 500, and electronic receipt server 600 are capable of communicating with each other via communication network 2. The communication network 2 may be the Internet, a virtual private network (VPN), a local area network (LAN), a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. As an example, the communication network 2 may be a combination of the Internet and a mobile communication network. It should be noted that any number of transaction processing devices 100, accounting devices 200, attendant terminals 300, user terminals 400, and cart terminals 500 may be included in transaction processing system 1, but only one of each is shown in FIG.

[0008] Transaction processing device 100 is an information processing device that processes information to provide a transaction processing service that processes a buying and selling transaction of goods between a user and a store in accordance with operations performed by the user at the store using accounting machine 200, user terminal 400, and cart terminal 500 as user interface terminals. That is, typically, customers who purchase goods at a store become users of the transaction processing service. Transaction processing device 100 is realized, for example, as a cloud server, and provides the transaction processing service at multiple stores. Transaction processing device 100 may also be realized, for example, as a local server, and provide the transaction processing service at only one store.

[0009] The payment machine 200 is installed in a store, and executes transaction processing related to the transaction processed by transaction processing device 100. The payment machine 200 is operated by an operator during transaction processing. In other words, the payment machine 200 is a terminal device that accepts operations by users related to transactions. The operator of the payment machine 200 is primarily a user. In some cases, the operator of the payment machine 200 is a store clerk.

[0010] Attendant terminal 300 is an information processing terminal operated by a store clerk. Attendant terminal 300 is a terminal device for a user interface related to information processing for supporting the work of a store clerk related to a transaction processed by transaction processing system 1.

[0011] User terminal 400 is an information communication device carried by a user. User terminal 400 is typically owned by the user and brought to a store by the user for use. User terminal 400 is a user interface terminal that receives operations by the user for transaction processing at transaction processing device 100.

[0012] Cart terminal 500 is an information processing terminal attached to a shopping cart provided in a store. Cart terminal 500 is loaned to a user together with a shopping cart. Cart terminal 500 is a terminal device operated by the user for transaction processing in transaction processing device 100. Cart terminal 500 may include an information communication terminal loaned to a user from the store and carried and used by the user.

[0013] Electronic receipt server 600 is an information processing device that performs information processing to provide an electronic receipt service to a user. Electronic receipt server 600 is realized, for example, as a cloud server, and provides an electronic receipt service that allows transactions at multiple stores to be electronically viewed. Transaction processing device 100 may be realized, for example, as a local server, and provides an electronic receipt service that allows transactions at only one store to be electronically viewed.

[0014] FIG. 2 is a block diagram showing the main circuit configuration of transaction processing device 100. As shown in FIG. Transaction processing device 100 includes a processor 101, a main memory unit 102, an auxiliary memory unit 103, a communication unit 104, and a transmission path 105. Processor 101, main memory unit 102, auxiliary memory unit 103, and communication unit 104 are capable of communicating with each other via transmission path 105.

[0015] Processor 101 , main memory unit 102 and auxiliary memory unit 103 are connected via transmission line 105 to constitute a computer that performs information processing for controlling transaction processing device 100 . Processor 101 corresponds to the central part of the computer. Processor 101 executes information processing for controlling each part to realize various functions of transaction processing device 100 in accordance with information processing programs such as an operating system and application programs.

[0016] The main memory unit 102 corresponds to the main memory portion of the computer. The main memory unit 102 includes a read-only memory area and a rewritable memory area. The main memory unit 102 stores a part of the information processing program in the read-only memory area. The main memory unit 102 may also store data required for the processor 101 to execute processes for controlling 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] Auxiliary storage unit 103 corresponds to the auxiliary storage portion of the computer. Auxiliary storage unit 103 may be, for example, an EEPROM (electric erasable programmable read-only memory), a HDD (hard disk drive), an SSD (solid state drive), or any other known storage device. Auxiliary storage unit 103 stores data used by processor 101 in performing various processes and data generated by the processes in processor 101. Auxiliary storage unit 103 may also store the information processing program. In this embodiment, auxiliary storage unit 103 stores a transaction processing program PRA, which is one of the information processing programs. The transaction processing program PRA is an application program in which the procedure of transaction processing, which will be described later, is described. A part of the storage area of ​​auxiliary storage unit 103 is used as an area for storing a store database DBA and transaction data DAA. The store database DBA is a database for managing a store that provides a transaction processing service by transaction processing device 100. The transaction data DAA is data representing the contents of one transaction.

[0018] The communication unit 104 executes communication processing for performing 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. Note that, instead of or in addition to the wired communication device, a wireless communication device connected to the communication network 2 by wireless communication may be used as the communication unit 104. The transmission path 105 includes an address bus, a data bus, and control signal lines, and transmits data and control signals between the connected components.

[0019] FIG. 3 is a diagram showing a schematic configuration of one data record REA contained in the store database DBA. Store database DBA is a collection of data records REA associated with each store that provides transaction processing services via transaction processing equipment 100 .

[0020] Data record REA includes fields FAA, FAB, and FAC. Field FAA is set with a store code as an identifier for identifying the associated store. Field FAB is set with various store information required for the associated store to provide a transaction processing service. Store information includes, for example, information indicating the time period during which the store is permitted to use the transaction processing service (hereinafter referred to as the available time period). Field FAC is set with payment method information indicating the payment method permitted to be used when the price of a transaction processed by the transaction processing service at the associated store is paid using an online payment service.

[0021] FIG. 4 is a diagram showing a schematic configuration of transaction data DAA. Transaction data DAA is generated for each transaction being processed by transaction processing device 100 and stored in auxiliary memory unit 103. Thus, there may be cases where none of the transaction data DAA is stored in auxiliary memory unit 103, or multiple transaction data DAA may be stored in auxiliary memory unit 103 simultaneously.

[0022] The transaction data DAA includes fields FBA, FBB, and FBC. The transaction data DAA may include any number of fields after the field FBD. A transaction code is set in the field FBA as an identifier of the transaction. A terminal code is set in the field FBB as an identifier of the user terminal 400 or cart terminal 500 used by the user who performs the transaction. A user code is set in the field FBC as an identifier of the user who performs the transaction. If there are registered products (hereinafter referred to as transaction products) as the target of the transaction, fields FBD, FBE, ... associated with each of the transaction products are added to the transaction data DAA. Product data related to different transaction products is set in the fields FBD, FBE, .... The product data includes a product code and a quantity as an identifier of the transaction product. The product data may include various other information such as product name, unit price, and discount information.

[0023] Now, as the hardware of transaction processing apparatus 100, for example, a general-purpose server device can be used. Transaction processing apparatus 100 is generally transferred in a state where transaction processing program PRA is stored in auxiliary storage unit 103, and store database DBA and transaction data DAA are not stored. However, the hardware in a state where transaction processing program PRA is not stored in auxiliary storage unit 103, or where a different version of the same type of application program is stored in auxiliary storage unit 103, and transaction processing program PRA may be transferred separately. Transaction processing apparatus 100 may be configured by writing transaction processing program PRA to auxiliary storage unit 103 in response to an operation by an arbitrary operator. Transaction processing program PRA may be transferred by recording it on a removable recording medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory, or by communication via a network.

[0024] FIG. 5 is a block diagram showing the main circuit configuration of the attendant terminal 300. As shown in FIG. 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, a transmission path 307, and the like.

[0025] The functions of processor 301, main memory unit 302, auxiliary memory unit 303, and transmission path 307 are generally the same as those of processor 101, main memory unit 102, auxiliary memory unit 103, and transmission path 105, so a detailed description thereof will be omitted. However, auxiliary memory unit 303 stores attendant terminal program PRC instead of transaction processing program PRA. Attendant terminal program PRC is an application program describing the information processing procedures of processor 301 for operating attendant terminal 300 as a user interface for store clerks who support transactions processed by transaction processing device 100.

[0026] The touch panel 304 displays a screen for presenting information to the operator, and also inputs instructions by the operator touching the screen through the touch panel 304. The camera 305 includes an optical system and an image sensor, and generates image data representing an image within a field of view formed by the optical system using the image sensor.

[0027] The wireless communication unit 306 executes communication processing for performing data communication via the communication network 2. For example, an existing wireless communication device for wireless LAN can be used as the wireless communication unit 306. Note that instead of or in addition to the wireless communication unit 306, a communication unit connected to the communication network 2 by wire may be used.

[0028] The hardware of the attendant terminal 300 may be, for example, a tablet information processing device or a portable information processing device such as a smartphone. The hardware of the attendant terminal 300 may be, for example, a stationary computer device.

[0029] FIG. 6 is a block diagram showing the main circuit configuration of the user terminal 400. As shown in FIG. 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 path 407.

[0030] The outline of the functions of processor 401, main storage unit 402, auxiliary storage unit 403, and transmission path 407 are equivalent to those of processor 101, main storage unit 102, auxiliary storage unit 103, and transmission path 105. The outline of the functions of touch panel 404, camera 405, and wireless communication unit 406 are equivalent to those of touch panel 304, camera 305, and wireless communication unit 306. However, auxiliary storage unit 403 stores user terminal program PRD instead of transaction processing program PRA. User terminal program PRD is an application program that describes the procedure of information processing by processor 401 for operating user terminal 400 as a user interface for transaction processing by transaction processing device 100. Auxiliary storage unit 403 also stores browser program PRE. Browser program PRE is an application program that describes the procedure of information processing for web browsing via communication network 2. As the browser program PRE, for example, a general-purpose browser application that is provided as standard in a smartphone or the like can be used as it is. The wireless communication unit 406 typically includes a known communication device for performing data communication via a mobile communication network, but may include an existing wireless communication device for wireless LAN instead of or in addition to the above communication device. The basic hardware of the user terminal 400 is assumed to be, for example, the hardware of a smartphone.

[0031] FIG. 7 is a block diagram showing the main circuit configuration of the cart terminal 500. As shown in FIG. 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 path 507.

[0032] The outline of the functions of processor 501, main memory unit 502, auxiliary memory unit 503, and transmission path 507 are equivalent to those of processor 101, main memory unit 102, auxiliary memory unit 103, and transmission path 105. The outline of the functions of touch panel 504 and wireless communication unit 506 are equivalent to those of touch panel 304 and wireless communication unit 306. However, auxiliary memory unit 503 stores cart terminal program PRF instead of transaction processing program PRA. Cart terminal program PRF is an application program describing the procedure of information processing of processor 501 for operating cart terminal 500 as a user interface for transaction processing by transaction processing device 100. Furthermore, wireless communication unit 506 typically includes an existing wireless communication device for wireless LAN. However, wireless communication unit 506 may include a well-known communication device for performing data communication via a mobile communication network instead of or in addition to the above communication device.

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

[0034] Next, the operation of the transaction processing system 1 configured as described above will be described. Note that the contents of the various processes described below are merely examples, and it is possible to change the order of some of the processes, omit some of the processes, or add other processes as appropriate. For example, in the following explanation, in order to easily explain the characteristic operations of this embodiment, the explanation of some of the processes is omitted. For example, when some kind of error occurs, a process may be performed to deal with the error, but the description of such a process is omitted.

[0035] As described below, the service provided to the user by the transaction processing system 1 is called a smartphone POS service when the user uses the user terminal 400, and is called a cart POS service when the user uses the cart terminal 500. In order to use the smartphone POS service, a user installs the user terminal program PRD on an information processing device such as a smartphone owned by the user, making it available as a user terminal 400. The user then enters a store that offers the smartphone POS service, taking the user terminal 400 with the processor 401 executing user terminal processing in accordance with the user terminal program PRD.

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

[0037] In stores that offer the smartphone POS service, a check-in code that represents check-in data is posted at the store entrance or inside the store. The check-in code is, for example, a two-dimensional barcode. The check-in data includes at least the store code. Therefore, the check-in code is different for each store.

[0038] When a user wishes to start using the smartphone POS service at a store, the user performs a predetermined operation, such as tapping a soft key displayed on the top screen, to receive check-in instructions. In ACT 112, the processor 401 waits for some operation by the user while displaying the top screen. If some operation by the user is detected, for example, by the touch panel 404, the processor 401 judges the result as YES and proceeds to ACT 113.

[0039] In ACT113, the processor 401 confirms whether the operation performed was an operation for instructing check-in. If the processor 101 cannot confirm the relevant event, it judges NO, confirms the content of the operation, and proceeds to other processing for carrying out processing accordingly. As one of the other processing, the processor 101, for example, confirms that an operation instructing cancellation has been performed, cancels the check-in procedure, and starts the processing again from ACT111. As the other processing, a different processing or multiple processing may be selectively performed, but a detailed description of such processing will be omitted here.

[0040] If an operation for instructing check-in has been performed as described above, the processor 401 determines YES in ACT113 and proceeds to ACT114. As ACT 114, the processor 401 displays a check-in screen on the touch panel 404. The check-in screen is a screen for guiding the user to have the camera 405 of the user terminal 400 capture a picture of the check-in code. The processor 401 waits for some operation to be performed by the user in ACT 115. If the processor 401 confirms that some operation has been performed by the user, it determines YES and proceeds to ACT 116.

[0041] The user operates the user terminal 400 according to the check-in screen, and causes the camera 405 of the user terminal 400 to capture a check-in code displayed in the store to be used. Even if a two-dimensional barcode is photographed by the camera 405, the processor 401 determines that an operation for reading the two-dimensional barcode has been performed and determines YES in ACT115, and proceeds to ACT116.

[0042] In ACT116, processor 401 checks whether the check-in code has been read by the above-mentioned operation. If processor 401 cannot check the event, it judges NO, checks the content of the operation, and proceeds to other processing to perform the corresponding processing. As one of the other processing, processor 401, for example, checks that the operation to read a two-dimensional barcode has been performed, but the two-dimensional barcode is not a check-in code, and displays a screen to notify the user of such an operational error. As the other processing, a different process or multiple processes may be selectively performed, but a detailed description thereof will be omitted here.

[0043] If the check-in code has been photographed by the camera 405, the processor 401 determines that the check-in code has been read by the above-described operation and judges YES in ACT116, and proceeds to ACT117. As ACT 117, processor 401 requests transaction processing device 100 to check in. Processor 401, for example, transmits request data for the check-in request from wireless communication unit 406 to communication network 2, addressed to transaction processing device 100. Processor 401 includes in the request data the check-in data represented by the check-in code photographed by camera 405 and the terminal code of user terminal 400. The terminal code is stored, for example, in auxiliary storage unit 403. As the terminal code, for example, an identifier determined by the operation system of user terminal 400 when installing user terminal program PRD can be used. This identifier is, for example, a 32-digit code including both alphanumeric characters.

[0044] On the other hand, in order to use the electronic receipt service provided by the electronic receipt server 600, the user must register and be issued a user code. If the user wishes to use an online payment service for payment related to a transaction using the smartphone POS service, the user must link the user code of the electronic receipt service as a usage setting of the user terminal program PRD. This link causes the user code to be stored in the main storage unit 402 or the auxiliary storage unit 403 of the user terminal 400 in a state accessible by the processor 401 in user terminal processing. If the user code is stored as described above, the processor 401 also includes the user code in the request data.

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

[0046] However, such a check-in procedure is merely one example, and various modifications are possible. For example, after starting user terminal program PRD, processor 401 of user terminal 400 may transmit check-in data including location information acquired using a GPS (global positioning system) or other positioning sensor to transaction processing device 100. Then, upon receiving the location information, transaction processing device 100 may, for example, acquire store information of the store where user terminal 400 that transmitted the location information is located from a database that represents store information in association with the location information, and perform check-in processing according to this store information.

[0047] If processor 101 is already executing a smartphone POS process for a transaction related to a different user, processor 101 starts a new smartphone POS process as a process of a different thread from the smartphone POS process. That is, processor 101 may execute multiple smartphone POS processes in parallel. In this case, multiple user terminals 400 that transaction processing device 100 uses as user interface terminals exist at the same time. However, the following description focuses only on the processing of a transaction related to one user. Thus, "user terminal 400" in the following description refers to one user terminal 400 used by a user for the smartphone POS process of interest. Also, "transaction" in the following description refers to the transaction that is the subject of the processing of interest.

[0048] 11, 12, and 13 are flowcharts of the smartphone POS process. The following describes an example in which a 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. In ACT211 in Fig. 11, the processor 101 checks whether the current time is within the available time slot. That is, for example, the processor 101 searches the store database DBA for a 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 slot represented by the information included in the store information set in field FAB of the data record REA. If the current time is not included in the available time slot determined here, for example, the processor 101 determines NO and proceeds to ACT212. The available time slot may be determined appropriately for each store.

[0049] As ACT212, the processor 101 instructs the user terminal 400 to display an unavailable screen in response to the check-in request. The unavailable screen is a screen for making the user aware that the smartphone POS service cannot be used. For example, the processor 101 transmits instruction data for instructing the user terminal 400 to display the available screen from the communication unit 104 to the communication network 2, addressed to the user terminal 400. Then, the processor 101 ends the smartphone POS processing.

[0050] When instruction data for instructing a screen display 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 the reception of the instruction data. Upon receiving the instruction data for instructing a screen display, the processor 401 causes the touch panel 404 to display a screen corresponding to the instruction data through user terminal processing.

[0051] The instruction data for instructing a screen display may include screen data representing a screen to be displayed in response to the instruction data, or may not include such screen data and may include data for enabling 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 includes the screen data in the instruction data. In the latter case, the processor 101, for example, includes in the instruction data a screen identifier that is predetermined to identify the screen to be displayed on the user terminal 400, or a notification identifier that identifies a notification that triggers the screen display. The notification identifier is, for example, information that is predetermined to identify a notification such as "outside the available time slot."

[0052] After the processor 401 in the user terminal 400 requests check-in in ACT 117 in FIG. In ACT118, the processor 401 waits for a response to the check-in request. If instruction data instructing the display of some screen is received by the wireless communication unit 406, the processor 401 determines that a response has been made (YES) and proceeds to ACT119.

[0053] In ACT 119, the processor 401 checks whether or not an instruction to display an unavailable screen has been given. If an instruction to display an unavailable screen has been given as described above, the processor 401 judges the answer to be YES and proceeds to ACT 120. As ACT 120, the processor 401 causes the touch panel 404 to display an unavailable screen.

[0054] If the received instruction data includes screen data, processor 401 displays the screen represented by the screen data as is on touch panel 404. If the received instruction data includes a screen identifier, processor 401 generates a screen identified by the screen identifier and displays it on touch panel 404. If the received instruction data includes a notification identifier, processor 401 determines a screen to be displayed in response to the notification identified by the notification identifier, generates the corresponding screen, and displays it on touch panel 404. The transmission and reception of display instructions for various screens, which will be described below, are performed in the same manner as above, although the contents of the screens to be displayed differ.

[0055] FIG. 14 is a diagram showing the unavailable screen SCA. The unavailable screen SCA is a screen in which a pop-up window WAA is superimposed on the screen displayed on the touch panel 404 when the check-in code is being scanned. The pop-up window WAA displays a text message informing the user that the facility is closed, and a button BAA. The button BAA is a soft key for receiving a confirmation from the user that the information on the unavailable screen SCA has been confirmed.

[0056] After confirming the guidance on the unavailable screen SCA, the user taps the button BAA. When such an operation is detected on the touch panel 404, the processor 401 ends the display of the unavailable screen SCA and returns the display screen of the touch panel 404 to a screen for, for example, scanning a check-in code.

[0057] On the other hand, if the current time is included in the available time slot, the processor 101 determines YES in ACT 211 in FIG. 11 and proceeds to ACT 213. In ACT213, the processor 101 generates new transaction data. That is, for example, the processor 101 determines a new transaction code different from transaction codes for identifying other transactions according to a predetermined rule, sets this transaction code in field FBA, and generates new transaction data DAA in which the terminal code received together with the check-in data is set in field FBB, and stores the data in the auxiliary storage unit 103. If a user code has been received together with the check-in data, the processor 101 sets the user code in field FBC of the newly generated transaction data DAA. If a user code has not been received together with the check-in data, the processor 101 leaves field FBC of the newly generated transaction data DAA in a null state, for example.

[0058] As ACT214 in FIG. 11, the processor 101 instructs the user terminal 400 to display a 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 for allowing the user to recognize the registration status of the trading products. For example, the processor 101 generates screen data representing a registration screen reflecting the registration status of the trading products, and includes the screen data in instruction data for instructing the user terminal 400 to display the screen. As described above, the processor 101 may include a screen identifier of the registration screen or a notification identifier that identifies the notification of "check-in confirmation completed" in the instruction data, instead of including the screen data. The generation of the registration screen may be performed by the processor 401 in the user terminal 400.

[0059] In the user terminal 400, when the processor 401 judges YES in ACT118 in FIG. 8 in response to receiving instruction data for instructing the display of a registration screen and proceeds to ACT119, it judges NO because the instruction is not to display an unavailable screen and proceeds to ACT121. As ACT 121, the processor 401 causes the touch panel 404 to display a registration screen.

[0060] FIG. 15 is a diagram showing the registration screen SCB. In the registration screen SCB, an image showing the registration status is placed in the display area ABA. The registration screen SCB shows buttons BBA and BBB. In the example of FIG. 15, the image placed in the display area ABA shows that a total of three items have been registered, with the product names "AAAAA", "BBBBB" and "CCCCC" and the unit prices being 300 yen, 400 yen and 700 yen, respectively, and the reference price is 1400 yen. The reference price is an amount obtained by subtracting the discount amount of various services such as coupon services from the total unit price of all the transaction items. If the transaction is settled without changing the transaction items and the applied services, this reference price will be the settlement amount. The image placed in the display area ABA changes sequentially according to the registration status of the transaction items. When the processor 101 executes ACT214 in FIG. 11 for the first time, the transaction 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 11, the image placed in the display area ABA does not represent information about each product, but rather an image indicating that there are 0 items in total and a suggested price of 0 yen.

[0061] Button BBA is a soft key for receiving an instruction to transition to a state in which a new product is scanned. Button BBB is a soft key for receiving a designation to start checkout. Note that the registration screen SCB and various screens described below illustrate the main display objects, and some display objects may be omitted. For example, an image may be included on the screen to allow the user to visualize the operations that the user should perform. Also, the registration screen SCB and various screens described below are merely examples, and may be determined as appropriate by, for example, the creator of the transaction processing program PRA.

[0062] After the processor 401 has caused the registration screen SCB to be displayed on the touch panel 404, the processor 401 proceeds to ACT131 in FIG. In ACT 131, the processor 401 waits for some operation by the user. If some operation by the user is detected on the touch panel 404, the processor 401 judges the result as YES and proceeds to ACT 132. As ACT132, processor 401 checks whether or not the performed operation needs to be notified to transaction equipment 100. If the performed operation is not one of the operations that are predetermined as targets for notification, processor 401 determines NO, checks the content of the operation, and proceeds to other processing for performing processing accordingly. As one of the other processing, processor 401 scrolls the registration screen in response to a scroll operation, for example. As the other processing, another processing or multiple processing may be selectively performed, but detailed description thereof will be omitted here.

[0063] On the other hand, if the performed operation is a predetermined operation to be notified, the processor 401 judges YES in ACT132 and proceeds to ACT133. As ACT 133, processor 401 notifies transaction equipment 100 of the operation contents. Processor 401, for example, transmits notification data for notifying transaction equipment 100 of the operation contents from wireless communication unit 406 to communication network 2.

[0064] When notification data for notifying the operation content is transmitted to transaction equipment 100 via communication network 2, communication unit 104 in transaction equipment 100 receives the notification data. Upon receiving the notification data, communication unit 104 notifies processor 101 of the reception of the notification data. The sending and receiving of notifications of operation contents on various screens described below is performed in the same manner as above, although the contents of the operations differ.

[0065] 11, the processor 101 waits for an operation to be performed on the user terminal 400. If the processor 101 is notified by the communication unit 104 that notification data for notifying the operation content as described above has been received, the processor 101 judges the result as YES and proceeds to ACT216. In ACT 216, the processor 101 checks whether the operation performed was an operation for specifying the start of a scan. If the processor 101 cannot check the event, it determines NO and proceeds to ACT 217.

[0066] In ACT217, processor 101 checks whether the operation performed was an operation to specify the start of a transaction. If processor 101 cannot confirm the relevant event, it judges NO, checks the content of the operation, and proceeds to other processing to perform processing accordingly. As one of the other processes, processor 101, for example, checks that an operation to specify the cancellation of a transaction has been performed, executes processing to cancel the transaction, and then ends the registration process. As the other process, a different process or multiple processes may be selectively performed, but a detailed description of these will be omitted here.

[0067] The user searches for a product to be traded in the store. When the user wants to register a new product as a trade product, the user performs a predetermined operation to specify the start of scanning, such as tapping the button BBA on the registration screen SCB. This operation is the subject of notification, and the processor 401 in the user terminal 400 judges YES in both ACT131 and ACT132 in FIG. 9, proceeds to ACT133, and transmits notification data to notify the user of the operation to instruct the user to start scanning.

[0068] When an operation for instructing to start scanning is thus notified from user terminal 400 to transaction equipment 100, processor 101 determines YES in ACT216 in FIG. 11, and proceeds to ACT221 in FIG. As ACT 221, the processor 101 instructs the user terminal 400 to display a product scan screen. The product scan screen is a screen for scanning a barcode representing a product code.

[0069] After the processor 401 in the user terminal 400 notifies the operation content in ACT 133 in FIG. 9, the process proceeds to ACT 134. In ACT 134, the processor 401 checks whether a display instruction has been issued. If the processor 401 cannot check the event, it determines NO and proceeds to ACT 135. In ACT 135, the processor 401 checks whether or not the payment URL has been notified. If the processor 401 cannot check the event, it determines NO and returns to ACT 134. Thus, the processor 401 waits for a display instruction or a notification of a settlement URL as ACT134 and ACT135.

[0070] Then, if instruction data instructing the display of some screen is transmitted from transaction equipment 100 and received by wireless communication unit 406, processor 401 determines YES in ACT134 and proceeds to ACT136. In response to the instruction, the processor 401 as ACT 136 updates the display screen on the touch panel 404. That is, in response to the instruction to display the product scan screen, the processor 401 updates the display screen on the touch panel 404 to the product scan screen. In ACT 137, the processor 401 checks whether the updated display screen is a first selection screen or a second selection screen, which will be described later. If the screen has been updated to a screen other than the first selection screen or the second selection screen, as in the case of updating to the product scan screen as described above, the processor 401 judges the result to be NO and proceeds to ACT 138. In ACT 138, the processor 401 checks whether the updated display screen is a completion screen, which will be described later. If the screen has been updated to a screen other than the completion screen, as in the case of updating to the product scan screen as described above, the processor 401 judges the result as NO and returns to the standby state of ACT 131. In other words, if the updated display screen is a screen other than the first selection screen, the second selection screen, and the completion screen, the processor 401 transitions to a standby state for an operation related to the updated screen.

[0071] FIG. 16 is a diagram showing the product scan 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 an image obtained by the camera 405. The button BCA is a soft key for the user to declare that the scanning of the product code is to be stopped.

[0072] When displaying product scan screen SCC in user terminal 400, processor 401 activates camera 405, and thereby superimposes an image obtained by camera 405 within display area ACA. When a predetermined operation for designating the start of scanning is performed, processor 401 may generate a product scan screen and display it on touch panel 404 without notifying transaction equipment 100 of the operation. In this case, processor 101 in transaction equipment 100 performs processing of ACT223 described below as ACT216, and if YES is determined in ACT216, proceeds to ACT224 described below without performing ACT221 to ACT223 described below.

[0073] When product scan screen SCC is displayed on touch panel 404, the user operates user terminal 400 so that the barcode displayed on the product to be registered as a transaction product is reflected within display area ACA. Processor 401 analyzes the image obtained by camera 405 and attempts to read the barcode. If processor 401 successfully reads the barcode, this operation is subject to notification, and processor 401 determines YES in both ACT131 and ACT132 in Fig. 9 and proceeds to ACT133, where it notifies transaction equipment 100 that a scan operation has been performed, along with a notification of the data represented by the read barcode (hereinafter referred to as barcode data) (product scan notification). Furthermore, if the user wishes to temporarily stop the registration of the transaction product and check the registration status of the transaction product, the user performs a predetermined operation to specify the cancellation of scanning, such as tapping button BCA. This operation is subject to notification, and processor 401 determines YES in both ACT131 and ACT132 in Fig. 9, proceeds to ACT133, and notifies transaction equipment 100 that an operation to specify the cancellation of scanning has been performed.

[0074] When processor 101 in transaction processing apparatus 100 has finished issuing an instruction to display the commodity scan screen in ACT221 in FIG. 12, the process proceeds to ACT222. In ACT222, the processor 101 waits for an operation to be performed on the user terminal 400. If the processor 101 receives a notification of the operation content from the user terminal 400, the processor 101 determines YES and proceeds to ACT223.

[0075] In ACT223, the processor 101 checks whether the operation was an operation for specifying a product. If the processor 101 cannot check the event, it judges NO, checks the content of the operation, and proceeds to other processing for performing processing according to the operation. As one of the other processing, the processor 101 checks that an operation for specifying the stop of scanning, such as tapping the button BCA, returns to ACT214 in FIG. 11, and returns the display screen of the touch panel 404 of the user terminal 400 to the registration screen SCB. As the other processing, another processing or multiple processing may be selectively performed, but a detailed description thereof will be omitted here. In addition, the operation of specifying the cancellation of scanning is not subject to notification from the user terminal 400, and 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 executed autonomously by the processor 401 on the user terminal 400 after determining NO in ACT132.

[0076] If the barcode data is notified as described above and the barcode data indicates a product code, the processor 101 determines that an operation for designating a product has been performed (YES) in ACT223 and proceeds to ACT224. As ACT224, the processor 101 determines a commodity to be traded based on the notified barcode data. That is, the processor 101, for example, extracts a commodity code included in the barcode data, and determines a commodity identified by the commodity code as a commodity to be traded (hereinafter referred to as a candidate commodity). The processor 101 may receive a notification from the user terminal 400 that a preset button displayed on the touch panel 404 has been tapped, and determine a commodity assigned to the preset button as a candidate commodity. The processor 101 may also receive a notification from the user terminal 400 of a commodity code that has been directly input on the touch panel 404 as a numeric string, and determine a commodity identified by the commodity code as a candidate commodity.

[0077] As ACT225, the processor 101 instructs the 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. The 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 may cause the processor 401 in the user terminal 400 to generate the registration confirmation screen including the data of the candidate product. When the processor 401 in the user terminal 400 receives instruction data for instructing to display the registration confirmation screen, the processor 401 judges YES in ACT134 in Fig. 9 and proceeds to ACT136, where it updates the display screen of the touch panel 404 to the registration confirmation screen. Then, since the updated screen here is neither the first selection screen nor the second selection screen, nor the completion screen, the processor 401 judges NO in both ACT137 and ACT138, and returns to the standby state of ACT131.

[0078] FIG. 17 is a diagram showing 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 shows a display area ADA and buttons BDA, BDB, BDC, and BDD. The display area ADA shows the quantity inside. The button BDA is a soft key for receiving a designation to decrease the quantity. The button BDB is a soft key for receiving a designation to increase the quantity. The button BDC is a soft key for receiving a designation not to register as a trading product. The button BDD is a soft key for receiving a designation to register as a trading product.

[0079] 12, the processor 101 waits for an operation to be performed on the user terminal 400. If the processor 101 receives a notification of the operation content from the user terminal 400, the processor 101 determines YES and proceeds to ACT 227. In ACT227, the processor 101 checks whether or not a change in quantity has been specified. If the processor 101 cannot check the event, it determines NO and proceeds to ACT228.

[0080] In ACT228, the processor 101 checks whether or not a designation has been made to register the candidate product as a trading product. If the processor 101 cannot confirm the relevant event, it judges NO, checks the content of the operation, and proceeds to other processing for performing processing accordingly. As one of the other processing, the processor 101 checks that a predetermined operation for designating cancellation of registration, such as tapping the button BDC, has been performed, and returns to ACT221. As the other processing, a different process or multiple processes may be selectively performed, but a detailed description thereof will be omitted here.

[0081] If a user wishes to change the quantity, the user specifies the quantity change by a predetermined operation such as tapping button BDA or button BDB. This operation is the subject of notification, and processor 401 in user terminal 400 determines YES in both ACT131 and ACT132 in Fig. 9, proceeds to ACT133, and notifies transaction equipment 100 that an operation instructing a quantity change has been performed. Then, in response to this notification, processor 101 in transaction equipment 100 determines YES in ACT227 in Fig. 12, and proceeds to ACT229. In ACT229, the processor 101 updates the transaction data DAA to change the quantity according to the specification. Then, the processor 101 returns to ACT214 in Fig. 11, instructs the user terminal 400 to display the registration screen SCB according to the transaction data updated as described above, and returns to the standby state in ACT215.

[0082] If the user decides to register the candidate product displayed on the registration confirmation screen SCD as the trading product in the quantity displayed in the display area ADA, the user specifies the registration by a predetermined operation such as tapping the button BDD. When such an operation is notified from the user terminal 400, the processor 101 judges YES in ACT228 and proceeds to ACT230. In ACT230, the processor 101 registers the candidate commodity as the transaction commodity in the quantity displayed in the display area ADA. The processor 101 updates the transaction data DAA to include commodity data representing, for example, the commodity code of the candidate commodity and the quantity displayed in the display area ADA. The processor 101 then returns to ACT214 in Fig. 11, instructs the user terminal 400 to display the registration screen SCB according to the transaction data updated as described above, and returns to the standby state in ACT215.

[0083] When the user has finished registering all of the transaction products related to this transaction, he or she designates the start of a transaction by a predetermined operation, such as tapping button BBB on registration screen SCB. This operation is the subject of notification, and processor 401 at user terminal 400 determines YES in both ACT131 and ACT132 in Figure 9, proceeds to ACT133, and notifies transaction equipment 100 that an operation instructing the start of a transaction has been performed. Then, in response to this notification, processor 101 at transaction equipment 100 determines YES in ACT217 in Figure 11, and proceeds to ACT241 in Figure 13. In ACT241, the processor 101 checks whether or not the user code has been acquired. If the processor 101 checks that the user code has been set in the field FBC of the transaction data DAA relating to the transaction, the processor 101 judges that the user code has been acquired (YES) and proceeds to ACT242.

[0084] As ACT242, the processor 101 instructs the user terminal 400 to display a first selection screen. The first selection screen is a screen for allowing the user to specify whether to perform smartphone payment or payment with a payment machine. When a notification identifier is included in the instruction data for instructing the display of the first selection screen, the notification identifier is expected to be, for example, a notification requesting notification of whether to perform smartphone payment or payment with a payment machine, or a notification that a user code has been acquired. When the processor 401 in the user terminal 400 receives instruction data for instructing to display the first selection screen, it judges YES in ACT 134 in FIG. 9 and proceeds to ACT 136, where it updates the display screen of the touch panel 404 to the first selection screen.

[0085] FIG. 18 is a diagram showing the first selection screen SCE. The first selection screen SCE represents the total amount of discounts applied, the total points of traded goods, the settlement amount, and further represents the user code as a character string, and represents buttons BEA, BEB, and BEC. Button BEA is a soft key for receiving a smartphone payment designation. Button BEB is a soft key for receiving a cash register payment designation. Button BEC is a soft key for receiving a designation for the user to notify a third party of the details of the transaction to be settled hereafter (hereinafter referred to as pre-settlement notification) before settlement. Note that the pre-settlement notification is performed, for example, to confirm the details of the transaction with a third party such as the requester prior to completing the transaction. For this reason, in the example of FIG. 18, the button BEC represents the character string "prior notification".

[0086] On the other hand, for example, if the processor 101 confirms that the field FBC of the transaction data DAA related to the transaction is in a null state, it determines that the user code has not been acquired, determines NO at ACT241 in FIG. 13, and proceeds to ACT243. As ACT243, the processor 101 instructs the user terminal 400 to display the second selection screen. The second selection screen is a screen for allowing the user to specify a cash register payment. The second selection screen is, for example, a screen obtained by modifying the first selection screen SCE to invalidate the button BEA, such as not representing the button BEA or displaying the button BEA in a grayed-out state. Note that when including a notification identifier in the instruction data for instructing the display of the second selection screen, the notification identifier is assumed to be, for example, a notification requesting an execution instruction for a cash register payment or a notification indicating that the user code has not been acquired.

[0087] When an operation for designating the start of accounting is performed on the user terminal 400, the processor 401 may execute the above-described processes of ACT241 to ACT243 on behalf of the processor 101. In this case, for example, if the processor 101 determines YES at ACT217 in FIG. 11 in the transaction processing device 100, it proceeds to ACT244 in FIG. 13.

[0088] When the processor 401 in the user terminal 400 receives instruction data for instructing to display the second selection screen, it judges YES in ACT 134 in FIG. 9 and proceeds to ACT 136, where it updates the display screen of the touch panel 404 to the second selection screen. After changing the display screen of the touch panel 404 to the first selection screen or the second selection screen in ACT136 as described above, the processor 401 judges YES in ACT137 and proceeds to ACT139.

[0089] In ACT 139, the processor 401 waits for some operation by the user. If some operation by the user is detected, for example, by the touch panel 404, the processor 401 judges the result as YES and proceeds to ACT 140. In ACT140, the processor 401 checks whether the operation was an operation for specifying a pre-payment notification. If the processor 401 checks that the operation is a predetermined operation for specifying a pre-payment notification, such as tapping the button BEC, the processor 401 judges that the result is YES and proceeds to ACT151 in FIG.

[0090] As ACT151, the processor 401 causes the touch panel 404 to display an execution confirmation screen. FIG. 19 is a diagram showing the execution confirmation screen SCF. The execution confirmation screen SCF is a screen for allowing the user to select an application to be used for the pre-payment notification and instruct the user to execute the pre-payment notification using that application. The execution confirmation screen SCF displays the total discount amount, the total number of items in the transaction, the payment amount, and even the user code as character strings so that the user can confirm the transaction that is the subject of the pre-payment notification. The execution confirmation screen SCF also displays buttons BFA and BFB. Buttons BFA and BFB are soft keys for specifying different applications.

[0091] The processor 401 checks which of the predetermined applications available for pre-payment notification is available on the user terminal 400, and displays buttons associated with the corresponding applications on the execution confirmation screen SCF. The predetermined applications available for pre-payment notification are, for example, a mailer application capable of sending e-mail, or an SNS (social networking service) application, and other applications that have a function of sending any data to any destination. That is, the execution confirmation screen SCF shown in FIG. 19 is an example of a case where two applications can be used for pre-payment notification. For this reason, the execution confirmation screen displayed on another user terminal 400 may have different applications associated with the buttons BFA and BFB. Alternatively, the execution confirmation screen displayed on another user terminal 400 may display one or three or more buttons instead of the buttons BFA and BFB.

[0092] In ACT 152, the processor 401 waits for some operation by the user. If some operation by the user is detected, for example, by the touch panel 404, the processor 401 judges the result as YES and proceeds to ACT 153. In ACT153, the processor 401 confirms whether the operation was an operation for specifying execution of the pre-payment notification. If the processor 401 cannot confirm the event, it judges NO, confirms the contents of the operation, and proceeds to other processing for performing processing according to the operation. As one of the other processing, the processor 401, for example, confirms that an operation for specifying the cancellation of the pre-payment notification was performed, returns the display screen of the touch panel 404 to the screen displayed before the execution confirmation screen was displayed, that is, the first selection screen or the second selection screen, and returns to the standby state of ACT139 in FIG. 9. As the other processing, another processing or multiple processing may be selectively performed, but detailed explanations thereof will be omitted here.

[0093] Now, if the user wishes to execute a pre - settlement notice, the user performs a predetermined operation to instruct such execution. At this time, for example, if a plurality of applications are presented as options as in the execution confirmation screen SCF shown in FIG. 19, the user performs an operation to specify the execution of the pre - settlement notice for the application to be used. For example, if the user decides to perform a pre - settlement notice for the application associated with the button BFA, the user taps the button BFA. If the processor 401 confirms that such a predetermined operation for specifying the execution of the pre - settlement notice has been performed, the processor 401 determines YES at ACT153 and proceeds to ACT154.

[0094] As ACT154, the processor 401 delivers pre - confirmation data to the specified application. Thus, by the processor 401 executing information processing based on the user terminal program PRD, the computer with the processor 401 as the central part functions as a selection means for selecting one of the information processes related to a plurality of applications in response to an instruction from the user, and also functions as a delivery means for delivering pre - confirmation data for the selected information process. The pre - confirmation data includes data to be presented to a third party among the data included in the transaction data. What data is included in the pre - confirmation data may be appropriately determined by, for example, the creator of the user terminal program PRD or the owner of the user terminal 400. It is assumed that the pre - confirmation data includes, for example, a list of transaction items, the total amount of discounts, the total points of transaction items, the settlement amount, or the user code. The data format of the pre - confirmation data may be appropriately determined by, for example, the creator of the user terminal program PRD or the owner of the user terminal 400. The data format of the pre - confirmation data is assumed to be, for example, text data.

[0095] Processor 401 extracts data to be included in the pre-confirmation data from data notified by transaction equipment 100, for example, each time the transaction data is updated. Processor 401 may alternatively request and obtain data to be included in the pre-confirmation data from transaction equipment 100, for example, each time ACT154 is executed. Processor 401 may alternatively extract, as data to be included in the pre-confirmation data, data displayed on the most recently displayed registration screen. Thus, processor 401 executes information processing based on user terminal program PRD, and the computer with processor 401 as its central part functions as an obtaining means.

[0096] If the application designated to be used for pre-payment notification is not running, the processor 401 starts processing of the application and passes the pre-confirmation data to the processing of the application. For example, a well-known function provided by the OS (operating system) of the user terminal 400 for data transfer between applications can be used to pass the pre-confirmation data. The user then operates the application to which the pre-check data has been delivered to send the pre-check data to the desired notification destination. In ACT 155, the processor 401 returns the display screen of the touch panel 404 to the screen that was displayed before the execution confirmation screen was displayed, that is, the first selection screen or the second selection screen. Then, the processor 401 returns to the standby state of ACT 131 in FIG.

[0097] When the user operates user terminal 400 to make a payment using an online payment service, the user performs a predetermined operation to specify smartphone payment, such as tapping button BEA displayed on first selection screen SCE. When the user makes a payment using payment machine 200, the user performs a predetermined operation to specify payment machine payment, such as tapping button BEB displayed on the first selection screen SCE or the second selection screen. These operations are subject to notification, and processor 401 determines YES in ACT139 in FIG. 9, NO in ACT140, and then YES in ACT132, proceeds to ACT133, and notifies transaction processing device 100 that an operation to specify smartphone payment or payment machine payment has been performed.

[0098] When the processor 101 finishes issuing the display instruction in ACT 242 or ACT 243 in FIG. 13, the processor 101 proceeds to ACT 244 in either case. In ACT244, processor 101 waits for an operation to be performed at user terminal 400. Then, processor 101 determines YES if the above-mentioned operation has been notified from user terminal 400 to transaction equipment 100, and proceeds to ACT245.

[0099] In ACT245, the processor 101 checks whether smartphone payment has been specified. If the processor 101 cannot confirm the relevant event, it determines NO, checks the content of the operation, and proceeds to other processing to perform the corresponding processing. As one of the other processes, the processor 101 confirms that payment with a payment device has been specified, and executes processing to have the payment device 200 perform payment processing for the price of the transaction being processed. As other processing, there may be cases where a different process or multiple processes are selectively performed, but a detailed explanation of these will be omitted here.

[0100] An example of the process for causing the payment device 200 to perform the payment process is as follows. Processor 101 instructs user terminal 400 to display a transaction screen. The transaction screen is a screen for handing over transaction processing related to the transaction to transaction apparatus 200. The transaction screen displays a barcode showing information that enables transaction apparatus 200 to make an inquiry about the transaction to transaction processing apparatus 100. When the processor 401 in the user terminal 400 receives instruction data for instructing to display the payment screen, it judges YES in ACT134 in Fig. 9 and proceeds to ACT136, where it updates the display screen on the touch panel 404 to the payment screen. Then, since the updated screen here is neither the first selection screen nor the second selection screen, nor the completion screen, the processor 401 judges NO in both ACT137 and ACT138, and returns to the standby state of ACT131. If a store has multiple payment machines 200 installed, the user arbitrarily selects an unused payment machine 200 from among them and has the barcode scanner of that payment machine 200 read the barcode displayed on the payment screen. In response, payment machine 200 requests payment data from transaction processing device 100 based on the information represented by the barcode read by the barcode scanner.

[0101] When processor 101 in transaction processing device 100 receives a request for transaction data, processor 101 transmits the transaction data to transaction device 200 that made the request, for causing transaction device 200 to settle the requested transaction. In this way, payment machine 200 executes processing to complete the transaction based on the payment data while appropriately displaying screens and receiving user operations related to the transaction in response to the payment data transmitted from transaction processing device 100. The processing performed by payment machine 200 may be similar to the processing performed by payment machines of existing POS systems, for example.

[0102] Now, in transaction processing device 100, when processor 101 proceeds from ACT244 to ACT245 in Fig. 13 in response to an operation to specify smartphone payment as described above on user terminal 400 while displaying first selection screen SCE, processor 101 determines YES in ACT245 and proceeds to ACT246. Note that if processor 101 instructs display of the second selection screen in ACT243 because a user code has not been acquired, smartphone payment is not specified and processor 101 does not proceed to ACT246.

[0103] As ACT246, the processor 101 instructs the user terminal 400 to display an authorization code scan screen. The authorization code scan screen is a screen for scanning a barcode representing an authorization code. When a notification identifier is included in the instruction data for instructing the display of the authorization code scan screen, the notification identifier is assumed to identify, for example, a notification requesting input of an authorization code. When the processor 401 in the user terminal 400 receives instruction data for instructing to display the authorization code scan screen, the processor 401 judges YES in ACT134 in Fig. 9 and proceeds to ACT136, where it updates the display screen of the touch panel 404 to the authorization code scan screen. Then, since the updated screen here is neither the first selection screen nor the second selection screen, nor the completion screen, the processor 401 judges NO in both ACT137 and ACT139, and returns to the standby state of ACT131.

[0104] FIG. 20 is a diagram showing the authorization code scan screen SCG. The authorization code scan screen SCG includes a display area AGA and a button BGA. The display area AGA is an area for displaying an image captured by the camera 405. The button BGA is a soft key that allows the user to declare that he or she wishes to cancel the smartphone payment. When displaying the authorization code scan screen SCG, the processor 401 in the user terminal 400 activates the camera 405, and thereby displays an image obtained by the camera 405 in a superimposed manner within the display area AGA.

[0105] In a checkout area, which is a predetermined area within a store, a two-dimensional barcode representing an authorization code for authorizing a predetermined smartphone payment is posted. The two-dimensional barcode can be posted by installing a sign or posting a printed matter. The checkout area is an area where payment using an online payment service is permitted. The checkout area may be appropriately determined for each store by the operator of the store. The authorization code may be different for each store or may be common to multiple stores. A one-dimensional barcode representing the authorization code may be posted instead of the above two-dimensional barcode.

[0106] The user moves to the checkout area and operates user terminal 400 so that the two-dimensional barcode displayed as described above is reflected in display area AGA. Processor 401 analyzes the image obtained by camera 405 and attempts to read the two-dimensional barcode. If the two-dimensional barcode is read, this operation is subject to notification, and processor 401 determines YES in both ACT 131 and ACT 132 in FIG. 9 and proceeds to ACT 133, notifying 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 signboard or printed matter for displaying the two-dimensional barcode corresponds to the medium from which user terminal 400 obtains the authorization code.

[0107] When the processor 101 finishes issuing the display instruction in ACT 246 in FIG. In ACT247, the processor 101 waits for an operation to be performed on the user terminal 400. If the processor 101 receives a notification of the operation content from the user terminal 400, the processor 101 judges YES and proceeds to ACT248.

[0108] In ACT248, the processor 101 checks whether the authorization code has been scanned. If the processor 101 cannot check the event, it judges NO, checks the contents of the operation, and proceeds to other processing for performing processing according to the operation. As one of the other processing, the processor 101 checks that an operation for designating the cancellation of the smartphone payment, such as tapping the button BGA, has been performed, returns to ACT242, and returns the display screen of the touch panel 404 of the user terminal 400 to the first selection screen SCE. As another processing, the processor 101 checks that a barcode that does not represent the authorization code has been scanned, displays an error, and then returns to ACT246, returning the display screen of the touch panel 404 of the user terminal 400 to the authorization code scan screen SCG. The error display is, for example, a screen display for notifying the operator that the smartphone payment cannot be performed unless the authorization code is scanned. As the other processing, another processing or multiple processing may be selectively performed, but a detailed description thereof will be omitted here.

[0109] If an operation notification accompanied by notification of barcode data representing the authorization code is made, the processor 101 determines that the authorization code has been scanned (YES) in ACT248 and proceeds to ACT249.

[0110] As ACT249, processor 101 notifies user terminal 400 of a payment URL (uniform resource locator) for making a web access to the online payment service and making a payment for the transaction. Processor 101 includes in the payment URL, for example, an address for accessing a web server (hereinafter referred to as a payment server) that provides the online payment service, and payment data related to the transaction. Processor 101, for example, is capable of determining the payment amount and transaction code related to the transaction from the payment data. Processor 101, for example, is capable of determining, from the payment data, an identifier of an affiliated store of the online payment service to which the store where the transaction is performed belongs. Processor 101, for example, is capable of determining, from the payment data, an identifier for identifying transaction processing device 100 at the payment server. Note that what information processor 101 is capable of determining from the payment data conforms to the specifications of the online payment service. Furthermore, part of the information to be included in the payment data may be sent from user terminal 400 or transaction processing device 100 to the payment server by separate communication, without being included in the payment data.

[0111] When the processor 401 in the user terminal 400 receives the notification of the payment URL, it determines YES in ACT135 in FIG. 9 and proceeds to ACT141. As ACT 141, the processor 401 starts browser processing in accordance with the browser program PRE included in the user terminal 400. If the browser processing has already been started, the processor 401 passes over this processing. As ACT 142, processor 401 passes the settlement URL notified by transaction processing apparatus 100 to the started browser process.

[0112] The processor 401 accesses the payment server based on the payment URL delivered from the user terminal processing in the browser processing. After that, the processor 401 performs payment using the online payment service in response to instructions from the payment server and operations by the user in the browser processing. Note that the procedure for payment using the online payment service may be, for example, a procedure known from existing online payment services, and a description thereof will be omitted here. When the payment server completes the payment, it notifies the transaction processing device 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 a transaction identifier determined from the payment URL.

[0113] In transaction processing apparatus 100, processor 101 notifies the payment URL in ACT249 in FIG. 13, and then proceeds to ACT250. In ACT250, the processor 101 waits for a completion notification. Then, if the processor 101 receives a notification of completion of the payment from the payment server as described above, the result of the determination is YES, and the process proceeds to ACT251. As ACT251, the processor 101 instructs the user terminal 400 to display a completion screen. The completion screen is a screen for making the user recognize that the transaction has been completed. When a notification identifier is included in the instruction data for instructing the display of the completion screen, the notification identifier is expected to identify, for example, a notification that the payment has been completed.

[0114] When the processor 401 in the user terminal 400 receives instruction data for instructing to display the completion screen, the processor 401 judges YES in ACT134 in Fig. 9 and proceeds to ACT136, where it updates the display screen of the touch panel 404 to the completion screen. Since the updated screen here is the completion screen, the processor 401 judges YES in ACT139 and proceeds to other processing. As one of the other processing, the processor 401 returns to ACT111 in Fig. 8 in response to an operation such as tapping a soft key displayed on the completion screen. As the other processing, another processing or multiple processing may be selectively performed, but a detailed description thereof will be omitted here. As described above, the processor 401 executes information processing based on the user terminal program PRD, and the computer with the processor 401 as its central part functions as an execution means that executes various functions to operate the user terminal 400 as a user interface terminal.

[0115] The processor 101 performs an electronic receipt registration process as ACT252 in Fig. 13. That is, the processor 101 sends various data such as a user code, a list of transaction items, and a settlement result to the electronic receipt server 600 so that the details of the current transaction can be viewed on the electronic receipt service. The electronic receipt server 600 then stores the acquired data in a transaction database and makes the transaction details viewable by the electronic receipt service. This electronic receipt registration process may be the same as the process performed by an existing electronic receipt service, for example, and a detailed description thereof will be omitted here. Therefore, the data sent by the processor 101 to the electronic receipt server 600 conforms to the specifications of the electronic receipt service. Then, the processor 101 ends the smartphone POS processing.

[0116] When the cart terminal 500 is in an active state, the processor 501 executes cart terminal processing in accordance with the cart terminal program PRF. 21, 22 and 23 are flowcharts of the cart terminal processing. As ACT 311 in Fig. 21, the processor 501 displays a home screen on the touch panel 504. The home screen is a screen for allowing the operator to specify a function to be executed from among various functions realized by the cart terminal processing. The home screen represents soft keys for receiving an instruction from the user to start using the system.

[0117] When a user wishes to start using the cart POS service at a store, the user indicates the start of use by a predetermined operation, such as tapping a soft key displayed on the home screen displayed on the touch panel 504 of the cart terminal 500, which is in an unused state. In ACT 312, the processor 501 waits for some operation by the operator while displaying the home screen. If some operation by the operator is detected, for example, by the touch panel 504, the processor 501 judges the result as YES and proceeds to ACT 313.

[0118] In ACT 313, the processor 501 checks whether the operation performed was an operation for instructing the start of use. If the processor 101 cannot check the relevant event, it judges NO, checks the content of the operation, and proceeds to other processing for carrying out processing according to the content. One of the other processing that the processor 101 performs is, for example, processing for maintenance in response to an operation by an authorized person such as a store clerk. As the other processing, there are cases where another processing or multiple processing are selectively performed, but a detailed description of such processing is omitted here.

[0119] If an operation to instruct the start of use has been performed as described above, the processor 501 determines YES in ACT313 and proceeds to ACT314. As ACT 314, processor 501 displays a membership confirmation screen on touch panel 504. The membership confirmation screen is a screen that asks the user whether or not he or she is a member. The membership confirmation screen shows a soft key for the user to indicate that he or she is a member and a soft key for the user to indicate that he or she is a non-member.

[0120] A user indicates that he or she is a member by performing a predetermined operation, such as tapping a soft key to indicate that he or she is a member, or a user indicates that he or she is a non-member by performing a predetermined operation, such as tapping a soft key to indicate that he or she is a non-member.

[0121] The processor 501 waits for some operation to be performed by the user in ACT 315. If the processor 501 confirms that some operation has been performed by the user, it determines YES and proceeds to ACT 316. In ACT 316, the processor 501 checks whether or not the member has been declared by the above-mentioned operation. If the processor 501 cannot check the corresponding event, it judges the result as NO and proceeds to ACT 317. In ACT 317, the processor 501 checks whether or not the operation performed above indicates that the user is a non-member. If the processor 501 cannot check the relevant event, it judges NO, checks the content of the operation, and proceeds to other processing to perform processing accordingly. As one of the other processing, the processor 501 checks, for example, that an operation to cancel the start of use has been performed, and returns to ACT 311. As the other processing, a different processing or multiple processing may be selectively performed, but a detailed description of such processing will be omitted here.

[0122] If the processor 501 confirms that an operation to declare membership has been performed, it judges YES in ACT316 and proceeds to ACT318. In ACT 318, processor 501 acquires a membership code. For example, processor 501 extracts the membership code from barcode data represented by a barcode scanned by scanner 505 from a membership card held up by the user over scanner 505. Processor 501 then attempts to acquire a user code related to the user identified by the membership code. Note that the membership code and the user code may be the same, and in this case, acquisition of the membership code may be regarded as acquisition of the user code. Alternatively, for example, if a user code is associated with the acquired membership code in a database (not shown), processor 501 acquires the user code. Then, the processor 501 proceeds to ACT 319. If the processor 501 confirms that an operation declaring non-membership has been performed, it judges YES in ACT 317, skips ACT 318, and proceeds to ACT 319.

[0123] In ACT 319, processor 501 requests transaction processing device 100 to check in. Processor 501, for example, transmits request data for the check-in request from wireless communication unit 506 to communication network 2, addressed to transaction processing device 100. Processor 501 includes the check-in data stored in auxiliary storage unit 503 and the terminal code of cart terminal 500 in the request data. The terminal code is stored, for example, in auxiliary storage unit 503. When processor 501 is able to acquire a user code in ACT 318, it also includes the user code in the request data. The check-in data, for example, the same as that represented by the check-in code, is written in advance in auxiliary storage unit 503. However, the check-in data written in auxiliary storage unit 503 may be partially different from the check-in data represented by the check-in code. The terminal code is assigned in advance to each cart terminal 500 so that each of the multiple cart terminals 500 used at the same store can be identified and so that the terminal code does not overlap with the terminal code of the user terminal 400, and is written to the auxiliary storage unit 503. For example, a numerical value from "1" to "999" is used as the terminal code of the cart terminal 500.

[0124] When the request data is transmitted to transaction processing device 100 via communication network 2 , the request data is received by communication unit 104 in transaction processing device 100 and temporarily stored in main memory unit 102 or auxiliary memory unit 103 . In this way, when the request data sent from cart terminal 500 is received by transaction processing device 100, processor 101 starts transaction processing for the cart POS service (hereinafter referred to as cart POS processing) in accordance with transaction processing program PRA. Note that the smartphone POS processing and the cart POS processing may each be written in separate application programs.

[0125] If the processor 101 is already executing a cart POS process for a transaction related to a different user, the processor 101 starts a new cart POS process as a process in a different thread from the cart POS process. Also, if the processor 101 is already executing the smartphone POS process described above, the processor 101 starts the cart POS process as a process in a different thread from the smartphone POS process. In other words, the processor 101 may execute a smartphone POS process and a cart POS process in parallel. However, the following description focuses only on the processing of a transaction related to one user. Thus, in the following description, the "cart terminal 500" refers to one cart terminal 500 used by a user for the cart POS process of interest. Also, in the following description, the "transaction" refers to the transaction that is the subject of the process of interest.

[0126] FIG. 24 is a flowchart of the cart POS process. In the cart POS process, the processor 101 performs the same processes shown in FIG. 11 and FIG. 12 in the smartphone POS process. However, the terminal used as the user interface in the cart POS process is the cart terminal 500. Also, the various screens displayed on the touch panel 504 of the cart terminal 500 may be changed for the cart terminal 500. For example, if the cart terminal 500 is attached to a shopping cart with the touch panel 504 in landscape orientation, the various vertically long screens described above are changed to accommodate 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 described above are changed to display more information on one screen than the various screens described above. However, the functions described above for the various screens are not changed.

[0127] 21, the processor 501 in the cart terminal 500 executes ACT320 to ACT323 and ACT331 to ACT333 in FIG. 22 in the same manner as ACT118 to ACT121 in FIG. 8 and ACT131 to ACT133 in FIG. After notifying the operation content in ACT333, the processor 501 proceeds to ACT334. In ACT 334, processor 501 waits for a display instruction. Then, when instruction data transmitted from transaction equipment 100 to instruct the display of some screen is received by wireless communication unit 506, processor 501 determines that the result is YES and proceeds to ACT 335.

[0128] The processor 501 as the ACT 335 updates the display screen on the touch panel 504 in response to an instruction. In ACT 336, the processor 501 checks whether the updated display screen is a selection screen, which will be described later. If the screen has been updated to a screen other than the selection screen, the processor 401 judges the result as NO and proceeds to ACT 337. In ACT 337, the processor 501 checks whether the updated display screen is a takeover screen, which will be described later. If the screen has been updated to a screen other than the takeover screen, the processor 501 determines that the answer is NO, and returns to the standby state of ACT 331. In other words, the processor 501 transitions to a standby state for an operation related to the updated screen.

[0129] In transaction processing device 100, processor 101 proceeds to ACT261 in FIG. 24 in response to notification from cart terminal 500 that an operation has been performed to instruct the start of transaction. As ACT261, the processor 101 instructs the cart terminal 500 to display a selection screen. The selection screen, like the first selection screen, is a screen for allowing the user to specify whether to perform smartphone payment or payment with an accounting machine, and to specify a pre-payment notification.

[0130] When the processor 501 in the cart terminal 500 receives instruction data for instructing to display the selection screen via the wireless communication unit 506, the processor 501 judges YES in ACT 334 in Fig. 22 and proceeds to ACT 335, where it updates the display screen of the touch panel 504 to the selection screen. 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, for example, skips ACT 261 and proceeds to ACT 262. Since the updated screen here is a selection screen, the processor 501 judges YES in ACT 336 in FIG. 22 and proceeds to ACT 338.

[0131] In ACT 338, the processor 501 waits for some operation by the user. If some operation by the user is detected, for example, by the touch panel 504, the processor 401 judges the result as YES and proceeds to ACT 339. In ACT 339, the processor 501 checks whether the operation was an operation for specifying a pre-payment notice. If the processor 501 checks that the operation is a predetermined operation for specifying a pre-payment notice, the processor 501 judges that the result is YES and proceeds to ACT 340.

[0132] The processor 501 as ACT 340 causes the touch panel 504 to display a delivery screen. FIG. 25 is a diagram showing the delivery screen SCH. The delivery screen SCH displays the total amount of discounts applied, the total number of transaction items, the payment amount, and the user code as character strings to allow the user to confirm the transaction that is the subject of the pre-payment notification, as well as the two-dimensional barcode CHA and the button BHA. The delivery screen SCH also displays a text message for requesting the user to have the information communication terminal used for the pre-payment notification read the two-dimensional barcode CHA. The two-dimensional barcode CHA represents data for opening an e-mail creation screen in which pre-confirmation data related to the transaction that is the subject of the pre-payment notification has already been entered as text data in the body of the e-mail by an application for sending e-mail (hereinafter referred to as a mailer). The contents of the pre-confirmation data may be the same as those described above regarding the user terminal 400, and may be appropriately determined, for example, by the creator of the cart terminal program PRF. The processor 501 may acquire the pre-confirmation data in the same manner as the processor 401 acquires the pre-confirmation data. Thus, the processor 501 executes information processing based on the cart terminal program PRF, and the computer with the processor 501 as the central part functions as an acquisition means.

[0133] When the user has any information and communication terminal other than the cart terminal 500 read the two-dimensional barcode CHA, the mailer of that information and communication terminal opens an email creation screen with a character string already entered as the body of the email to allow the user to confirm the transaction that is the subject of the pre-payment notification. The user operates the mailer to send the email to the desired notification destination. In this way, displaying the screen showing the two-dimensional barcode CHA is equivalent to handing over pre-confirmation data to the information and communication terminal. Thus, the processor 501 executes information processing based on the cart terminal program PRF, and the computer with processor 501 as its central part functions as a delivery means. Then, although not shown in the figure, the processor 501 waits for a user operation to instruct the display of the delivery screen to be ended, returns the display screen of the touch panel 504 to the selection screen that was displayed before the delivery screen was displayed, and returns to the standby state of ACT338 in Figure 22.

[0134] When making a payment using an online payment service, the user performs a predetermined operation to specify smartphone payment, such as tapping a button displayed on the selection screen for specifying smartphone payment. When making a payment using the payment machine 200, the user also performs a predetermined operation to specify payment machine payment, such as tapping a button displayed on the selection screen for specifying payment machine payment. Since these operations are not prior notification specifications, the processor 501 determines YES in ACT338 and NO in ACT339 in FIG. 22 and proceeds to ACT341.

[0135] In ACT341, processor 501 confirms whether or not the performed operation needs to be notified to transaction processing device 100. If the performed operation is not one of the operations previously defined as the target of notification, processor 401 determines NO, confirms the content of the operation, and proceeds to other processing for performing processing accordingly. As one of the other processing, processor 501, for example, confirms that an operation for designating the cancellation of pre-settlement notification has been performed, returns the display screen of touch panel 504 to the selection screen that was displayed before the delivery screen was displayed, and returns to the standby state of ACT334 in Fig. 22. As the other processing, a different processing or multiple processing may be selectively performed, but detailed description thereof will be omitted here. Since the operation of designating smartphone payment or accounting machine payment as described above is to be notified to transaction equipment 100, processor 501 determines YES in ACT341 and returns to ACT333 to notify transaction equipment 100 that the operation has been performed. Then, processor 501 transitions to a standby state in ACT334.

[0136] 24, processor 101 waits for an operation to be performed at cart terminal 500. Then, processor 101 determines YES if the above-mentioned operation is notified from cart terminal 500 to transaction equipment 100, and proceeds to ACT263. In ACT263, the processor 101 checks whether smartphone payment has been specified. If the processor 101 cannot confirm the relevant event, it determines NO, checks the content of the operation, and proceeds to other processing to perform the corresponding processing. As one of the other processes, the processor 101 confirms that payment with a payment machine has been specified, and executes processing to have the payment machine 200 perform payment processing for the price of the transaction being processed. As the other process, a different process or multiple processes may be selectively performed, but a detailed explanation of these will be omitted here.

[0137] Now, in transaction processing device 100, when processor 101 proceeds from ACT262 to ACT263 in response to an operation to specify smartphone payment as described above being performed on cart terminal 500, processor 101 judges 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 for requesting the user to have the cart terminal 500 scan the authorization code. When a notification identifier is included in the instruction data for instructing the user to display the first request screen, it is assumed that the notification identifier identifies, for example, a notification requesting input of the authorization code.

[0138] When an operation to designate smartphone payment is performed on the selection screen, processor 501 at cart terminal 500 may display a first request screen on touch panel 504 without receiving a display instruction from transaction processing device 100. In this case, processor 101 at transaction processing device 100 does not execute ACT264.

[0139] The user operates cart terminal 500 to have scanner 505 read the authorization code posted in the checkout area. If a two-dimensional barcode is read by scanner 505, this operation is subject to notification, and processor 501 determines YES in both ACT 331 and ACT 332 in Fig. 22 and proceeds to ACT 333, where it notifies transaction equipment 100 that a scan operation has been performed, along with notification of the barcode data represented by the two-dimensional barcode.

[0140] When the processor 101 finishes issuing the display instruction in ACT 264 in FIG. In ACT265, the processor 101 waits for an operation to be performed on the cart terminal 500. If the processor 101 receives notification of the operation content from the cart terminal 500, the processor 101 determines that the result is YES and proceeds to ACT266.

[0141] In ACT266, the processor 101 checks whether the authorization code has been scanned. If the processor 101 cannot check the event, it judges NO, checks the contents of the operation, and proceeds to other processing for performing processing according to the operation. As one of the other processing, the processor 101 checks that an operation for designating the cancellation of the smartphone payment, such as tapping the button BGA, has been performed, returns to ACT261, and returns the display screen of the touch panel 504 of the cart terminal 500 to the selection screen. As another processing, the processor 101 checks that a barcode that does not represent the authorization code has been scanned, displays an error, and then returns to ACT264, returning the display screen of the touch panel 504 of the cart terminal 500 to the first request screen. The error display is, for example, a screen display for notifying the operator that the smartphone payment cannot be performed unless the authorization code is scanned. As the other processing, another processing or multiple processing may be selectively performed, but a detailed description thereof will be omitted here.

[0142] If an operation notification accompanied by notification of barcode data representing the authorization code is made, the processor 101 determines that the authorization code has been scanned (YES) in ACT266 and proceeds to ACT267. In ACT267, the processor 101 checks whether or not the user code has been acquired. If the check-in data cannot be acquired because the user code has not been input to the cart terminal 500 as part of the operation for starting use of the cart terminal 500 and the user code has not been sent from the cart terminal 500 together with the check-in data, the processor 101 determines NO and proceeds to ACT268.

[0143] As ACT268, the processor 101 instructs the cart terminal 500 to display a second request screen. The second request screen is a screen for requesting the user to have the cart terminal 500 scan the user code. When a notification identifier is included in the instruction data for instructing the display of the second request screen, it is expected that the notification identifier will identify, for example, a notification requesting input of a user code.

[0144] When the processor 501 in the cart terminal 500 receives instruction data for instructing to display the second request screen via the wireless communication unit 506, the processor 501 judges YES in ACT334 in Fig. 22 and proceeds to ACT335, where it updates the display screen of the touch panel 504 to the second request screen. Then, since the updated screen here is neither the selection screen nor the takeover screen, the processor 501 judges NO in both ACT336 and ACT337 and returns to the standby state of ACT331.

[0145] A user displays a barcode representing a user code on the screen of an information communication terminal such as a smartphone owned by the user, and has scanner 505 of cart terminal 500 scan this barcode. If the barcode is read by scanner 505, this operation is subject to notification, and processor 501 determines YES in both ACT 331 and ACT 332 in Fig. 22 and proceeds to ACT 333, notifying transaction equipment 100 that a scan operation has been performed, along with notification of the barcode data represented by the barcode.

[0146] When the processor 101 finishes issuing the display instruction in ACT 268 in FIG. In ACT269, the processor 101 waits for an operation to be performed on the cart terminal 500. If the processor 101 receives notification of the operation content from the cart terminal 500, the processor 101 determines that the result is YES and proceeds to ACT270.

[0147] In ACT270, the processor 101 checks whether the user code has been scanned. If the processor 101 cannot check the event, it judges NO, checks the content of the operation, and proceeds to other processing to perform processing according to the operation. As one of the other processing, the processor 101 checks that an operation to specify the cancellation of the smartphone payment, such as tapping the button BHA, has been performed, returns to ACT261, and returns the display screen of the touch panel 504 of the cart terminal 500 to the selection screen. As another processing, the processor 101 checks that a barcode that does not represent a user code has been scanned, displays an error message to notify that the scanned barcode is incorrect, and then returns to ACT268, and returns the display screen of the touch panel 504 of the cart terminal 500 to the second request screen. As the other processing, another processing or multiple processing may be selectively performed, but a detailed description thereof will be omitted here.

[0148] If an operation notification accompanied by notification of barcode data representing a user code is made, the processor 101 determines that the user code has been scanned as YES in ACT270 and proceeds to ACT271. Note that if the processor 101 confirms that the user code has been acquired and determines YES in ACT267, it proceeds to ACT271 without performing ACT268 to ACT270. As ACT271, the processor 101 instructs the cart terminal 500 to display a takeover screen. The takeover screen is a screen for taking over a payment using an online payment service to another information communication terminal. A smartphone is typically used as the other information communication terminal. The takeover screen represents, for example, a two-dimensional barcode. This two-dimensional barcode represents takeover data including a payment URL and a command requesting execution of web access using the payment URL. When the processor 501 in the cart terminal 500 receives instruction data for instructing to display the transition screen via the wireless communication unit 506, it judges YES in ACT 334 in FIG. 22 and proceeds to ACT 335, where it updates the display screen of the touch panel 504 to the transition screen.

[0149] The user uses the barcode reader function of the communication terminal, such as a smartphone, owned by the user to have the communication terminal read the two-dimensional barcode displayed on the transfer screen. In response, the communication terminal uses the browser function to access the payment server based on the payment URL included in the transfer data represented by the two-dimensional barcode. After that, the communication terminal uses the browser function to make a payment using an online payment service in response to instructions from the payment server and operations by the user. The procedure for making a payment using an online payment service may be, for example, one known from existing online payment services, and a description thereof will be omitted here.

[0150] In transaction processing device 100, processor 101 issues an instruction to display the transition screen in ACT271 in FIG. 24, and then proceeds to ACT272. In ACT272, the processor 101 checks whether or not a completion notice has been sent. If the processor 101 cannot check the event, it judges the result as NO and proceeds to ACT273. In ACT 273, the processor 101 checks whether or not any operation has been performed by the user. If the processor 101 cannot check the relevant event, it determines NO and returns to ACT 272. Thus, the processor 101 waits for a completion notification or operation as ACT 272 and ACT 273.

[0151] If the processor 501 in the cart terminal 500 displays the transition screen in ACT 335 in FIG. 22, it determines NO in ACT 336 and YES in ACT 337, and proceeds to ACT 351 in FIG. In ACT 351, the processor 501 checks whether or not the user has performed any operation. If the processor 501 cannot check the relevant event, it determines NO and proceeds to ACT 352. As ACT352, the processor 501 checks whether a display instruction has been given. If the processor 501 cannot confirm the corresponding event, it determines NO and returns to ACT351. Thus, as ACT351 and ACT352, the processor 501 waits for an operation or a display instruction.

[0152] When an operation such as tapping a button shown on the handover screen is performed by the user and detected by the touch panel 504, the processor 501 determines YES in ACT351, moves to ACT332 in FIG. 22, and repeats the subsequent processing in the same manner as described above. If a predetermined operation for instructing to cancel the smartphone payment, such as tapping a button shown on the handover screen to receive an instruction to cancel the smartphone payment, is performed, the operation is a notification target, and the processor 501 determines YES in both ACT331 and ACT332 and proceeds to ACT333, and notifies the transaction processing device 100 of the operation.

[0153] When the processor 101 in the transaction processing device 100 is notified of an operation from the cart terminal 500 in this way, it determines YES in ACT273 in FIG. 24 and proceeds to other processing for performing processing according to the content of the notified operation. As one of the other processes, the processor 101, for example, confirms that an operation for specifying cancellation of the smartphone payment has been performed, returns to ACT261, and returns the display screen of the touch panel 504 of the cart terminal 500 to the selection screen. Although other processes may selectively perform another process or a plurality of processes, the detailed description thereof is omitted here.

[0154] If the payment server has completed the payment process started by receiving an access based on the payment URL, it notifies the transaction processing device 100 of the completion of the payment, accompanied by notification of the transaction code determined from the payment URL. When processor 101 in transaction processing device 100 is notified of completion in this manner, it determines YES in ACT272 in FIG. 24 in the cart POS processing being executed for the transaction identified by the notified transaction code, and proceeds to ACT274.

[0155] As ACT274, the processor 101 instructs the cart terminal 500 to display a completion screen. The completion screen is a screen for making the user recognize that the transaction has been completed. When a notification identifier is included in the instruction data for instructing the display of the completion screen, the notification identifier is expected to identify, for example, a notification that the payment has been completed. In ACT275, the processor 101 performs an electronic receipt registration process in the same manner as in ACT252 in FIG. Then, the processor 101 thereafter ends the cart POS process.

[0156] When instruction data for instructing display is received while the touch panel 504 is displaying the transition screen, the processor 501 in the cart terminal 500 judges YES in ACT352 in FIG. 22 and proceeds to ACT353. As ACT 353, the processor 501 updates the display screen on the touch panel 504 in response to the instruction from the instruction data. If an instruction to display the completion screen has been given as described above, the processor 501 updates the screen on the touch panel 504 to the completion screen.

[0157] In ACT354, the processor 501 checks whether the updated display screen is the completion screen. If the display screen has been updated to the completion screen as described above, the processor 401 judges YES and proceeds to other processing. As one of the other processing, the processor 501 returns to ACT311 in FIG. 21 in response to an operation such as tapping a soft key displayed on the completion screen. As the other processing, another processing or multiple processing may be selectively performed, but a detailed description thereof will be omitted here. In addition, there may be cases where a command is issued to display a screen other than the completion screen while the touch panel 504 is displaying the handover screen, such as when a command is issued to cancel smartphone payment. In this case, the processor 501 judges NO in ACT354 and transitions to a standby state in ACT331 in FIG. Thus, by the processor 501 executing information processing based on the cart terminal program PRF, the computer with the processor 501 as its central part functions as an execution means that executes various functions for operating the cart terminal 500 as a user interface terminal.

[0158] As described above, when a prior notification is instructed by the user, the user terminal 400 delivers the prior confirmation data to an application such as an SNS or mailer of the user terminal 400. In this way, the user can notify any third party of the details of the transaction that is about to be settled using an application such as an SNS or mailer. This enables the user to easily confirm the details of the purchase with, for example, the person who requested the purchase, before the payment.

[0159] Furthermore, when the user instructs to notify in advance, the cart terminal 500 displays a two-dimensional barcode for passing the advance confirmation data to an application such as a mailer of any other information and communication terminal. Thus, by having any information and communication terminal read the two-dimensional barcode, the user can notify any third party of the details of the transaction to be settled, using an application such as a mailer on that information and communication terminal. This allows the user to easily confirm the details of the purchase with, for example, the person requesting the purchase, before settlement. Furthermore, the cart terminal 500 does not require the user to input information such as the destination of the advance confirmation data into the cart terminal 500, so the user's work is not significantly complicated.

[0160] This embodiment can be modified in various ways as follows. The processor 401 and the processor 501 may transfer the advance confirmation data at any timing while the trading product is being registered.

[0161] The application to which the advance confirmation information is handed over from the cart terminal 500 to the information communication terminal may be an application other than a mailer, such as an SNS application.

[0162] A part or all of the processing performed by processor 101 in transaction processing device 100 may be executed by processor 401, 501 in user terminal 400 or cart terminal 500. For example, transaction data may be stored in auxiliary storage unit 403, 503, and updated by processor 401, 501.

[0163] Each function realized by the processors 101, 301, 401, and 501 through information processing can be realized in part or in whole by hardware that executes information processing not based on a program, such as a logic circuit, etc. Also, each of the above functions can be realized by combining the above hardware, such as the logic circuit, with software control.

[0164] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

[0165] 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 memory unit, 103, 303, 403, 503... Auxiliary memory unit, 104... Communication unit, 304, 404, 504... Touch panel, 305, 405... Camera, 306, 406, 506... Wireless communication unit, 505... Scanner.

Claims

1. A transaction processing system for generating transaction data representing transaction details in response to an operation on a user interface terminal, the system comprising: an execution means for executing a function as the user interface terminal; an acquisition means for acquiring pre-check data defined as at least a part of transaction data generated by the transaction processing system based on the function executed by the execution means; a transfer means for transferring the advance confirmation data acquired by the acquisition means to an information processing executed in the information communication device so that arbitrary data can be acquired by another information communication terminal; An information processing program that enables the system to function as such.

2. a selection unit that selects one of a plurality of information processing operations executed by the computer in response to an instruction from an operator in order to cause another information communication device to acquire arbitrary data; The delivery means delivers the advance confirmation data to the information processing device selected by the selection means. The information processing program according to claim 1 .

3. 1. An information communication device used as a user interface terminal in a transaction processing system that generates transaction data representing transaction details in response to an operation on a user interface terminal, an execution means for executing a function as the user interface terminal; an acquisition means for acquiring pre-check data defined as at least a part of transaction data generated by the transaction processing system based on the function executed by the execution means; a transfer means for transferring the advance confirmation data acquired by the acquisition means to an information processing executed by the information communication device so that arbitrary data can be acquired by another information communication terminal; An information and communication device comprising:

4. A transaction processing system for generating transaction data representing transaction details in response to an operation on a user interface terminal, the system comprising: an execution means for executing a function as the user interface terminal; an acquisition means for acquiring transaction data generated by the transaction processing system based on the function performed by the execution means; a transfer means for transferring the pre-confirmation data, which is determined as at least a part of the data included in the transaction data acquired by the acquisition means, to an information communication terminal capable of executing information processing for causing an arbitrary notification destination terminal to acquire arbitrary data; An information processing program that enables the system to function as such.

5. 1. An information processing device used as a user interface terminal in a transaction processing system that generates transaction data representing transaction details in response to an operation on a user interface terminal, an execution means for executing a function as the user interface terminal; an acquisition means for acquiring transaction data generated by the transaction processing system based on the function performed by the execution means; a transfer means for transferring the pre-confirmation data, which is determined as at least a part of the data included in the transaction data acquired by the acquisition means, to an information communication terminal capable of executing information processing for causing an arbitrary notification destination terminal to acquire arbitrary data; An information processing device comprising:

Images