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

Abstract

To save user's trouble.SOLUTION: A transaction processing system comprises determination means, decision means and registration means. The determination means determines an article as a terminal device is operated by a user. The decision means decides whether each article determined by the determination means is an object to be delivered as the terminal device is operated by the user. The registration means registers the article determined by the determination means as an object of transaction associatively whether the decision means decides the article as an object to be delivered.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present invention relates to a transaction processing system, a transaction processing device, and an information processing program. [Background technology]

[0002] A system that processes transactions using, as a user interface, a communication terminal owned by the user, such as a smartphone, or a communication terminal loaned to the user by a store, etc., is known as a "smartphone POS system." Alternatively, a system that processes transactions using, as a user interface, a communication terminal attached to a shopping cart provided as equipment in a store is known as a "cart POS system." When a user requests delivery of some of the products purchased using such a transaction processing system, the user must previously pick up all of the products from the sales floor, hand over the products to be delivered to a store clerk, and then request delivery. This requires a lot of effort on the part of the user. Given these circumstances, it has been desirable to reduce the amount of work required by users. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2018-13822 Summary of the Invention [Problem to be solved by the invention]

[0004] The problem to be solved by the present invention is to provide a transaction processing system, a transaction processing device, and an information processing program that can reduce the burden on users. [Means for solving the problem]

[0005] The transaction processing system of the embodiment includes a determination means, a decision means, and a 、 Registration method , reception means, confirmation means and display means The determination means determines a product in response to an operation by a user on a terminal device. The decision means determines, for each product determined by the determination means, whether or not the product is to be delivered in response to an operation by the user on the terminal device. The registration means associates the product determined by the determination means with whether or not the product has been determined as being to be delivered by the decision means, and registers the product as a product to be traded. The receiving means receives a specification for changing the conditions of a registered product. The confirmation means confirms whether the product for which the receiving means has received a specification for changing the conditions is a deliverable product. The display means, in response to the confirmation means confirming that the product is a deliverable product, displays a screen for accepting a specification for not making the product eligible for delivery, and in response to the determination means determining that the product is not deliverable, displays a screen indicating that the operation for specifying not to make the product eligible for delivery is not possible. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a block diagram illustrating a schematic configuration of a transaction processing system according to an embodiment. [Figure 2] FIG. 2 is a block diagram showing the main circuit configuration of the transaction processing device shown in FIG. [Figure 3] FIG. 3 is a diagram schematically showing the configuration of one data record included in the user database shown in FIG. 2. [Figure 4] 3 is a diagram showing a schematic diagram of the structure of the transaction data DAA shown in FIG. 2 and the structure of one data record included in this transaction data. [Figure 5] FIG. 2 is a block diagram showing the main circuit configuration of the accounting machine shown in FIG. 1. [Figure 6] FIG. 2 is a block diagram showing the main circuit configuration of the user terminal shown in FIG. [Figure 7] FIG. 2 is a block diagram showing the main circuit configuration of the attendant terminal shown in FIG. [Figure 8] 3 is a flowchart of a registration process performed by the processor shown in FIG. 2. [Figure 9] 3 is a flowchart of a registration process performed by the processor shown in FIG. 2. [Figure 10] 3 is a flowchart of a registration process performed by the processor shown in FIG. 2. [Figure 11] 3 is a flowchart of a registration process performed by the processor shown in FIG. 2. [Figure 12]3 is a flowchart of a registration process performed by the processor shown in FIG. 2. [Figure 13] 3 is a flowchart of a registration process performed by the processor shown in FIG. 2. [Figure 14] FIG. 10 is a diagram illustrating an example of a registration screen. [Figure 15] FIG. 10 is a diagram illustrating an example of a product scanning screen. [Figure 16] FIG. 10 is a diagram illustrating an example of a first registration confirmation screen. [Figure 17] FIG. 10 is a diagram illustrating an example of a second registration confirmation screen. [Figure 18] FIG. 10 is a diagram illustrating an example of a reception screen. [Figure 19] FIG. 10 is a diagram illustrating an example of a registration screen. [Figure 20] FIG. 10 is a diagram illustrating an example of a recommendation screen. [Figure 21] FIG. 10 is a diagram illustrating an example of a pickup confirmation screen. [Figure 22] FIG. 10 is a diagram showing an example of a first delivery instruction screen. [Figure 23] FIG. 10 is a diagram illustrating an example of a selection screen. [Figure 24] FIG. 10 is a diagram illustrating an example of a takeover screen. [Figure 25] FIG. 10 is a diagram showing an example of a second delivery instruction screen. [Figure 26] FIG. 10 is a diagram illustrating an example of a basket scan screen. [Figure 27] FIG. 10 is a diagram showing an example of a third delivery instruction screen. DETAILED DESCRIPTION OF THE INVENTION

[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 so that transaction processing device 100, accounting machine 200, user terminal 300, and attendant terminal 400 can communicate with each other via communication network 2. The communication network 2 may be the Internet, a VPN (virtual private network), a 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. Although any number of transaction processing devices 100, accounting devices 200, user terminals 300, and attendant terminals 400 may be included in transaction processing system 1, only one of each is shown in FIG.

[0008] Transaction processing device 100 performs information processing for processing a purchase and sale transaction of goods between a user and a store in accordance with operations performed by the user at the store using accounting machine 200 and user terminal 300 as user interface terminals. Transaction processing device 100 may be realized, for example, as a cloud server and process transactions at multiple stores. Transaction processing device 100 may also be realized, for example, as a local server and process transactions at only one store.

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

[0010] User terminal 300 is an information processing terminal carried by a user. User terminal 300 is typically owned by the user and brought into a store by the user for use. User terminal 300 may be an information communication terminal loaned to the user by the store, or an information communication terminal attached to a shopping cart provided as equipment in the store. User terminal 300 is a terminal device operated by the user for transaction processing at transaction processing equipment 100.

[0011] Attendant terminal 400 is an information processing terminal carried by a store clerk. Attendant terminal 400 is a terminal device for a user interface related to information processing to support the work of the store clerk regarding transactions processed by transaction processing system 1.

[0012] FIG. 2 is a block diagram showing the main circuit configuration of transaction processing apparatus 100. As shown in FIG. Transaction processing device 100 includes processor 101, main memory unit 102, auxiliary memory unit 103, communication unit 104, and 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.

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

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

[0015] The auxiliary storage unit 103 corresponds to the auxiliary storage portion of the computer. The 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 well-known storage device. The auxiliary storage unit 103 stores data used by the processor 101 when performing various processes and data generated by the processes performed by the processor 101. The auxiliary storage unit 103 may also store the information processing program. In this embodiment, the 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 that describes the procedures for transaction processing, including the registration process described below. A portion of the storage area of ​​the auxiliary storage unit 103 is used to store a user database DBA and transaction data DAA. The user database DBA is a database for managing users of the smartphone POS service described below. The transaction data DAA is data representing the contents of one transaction.

[0016] The communication unit 104 executes communication processing for performing data communication via the communication network 2. The communication unit 104 can use, for example, an existing communication device for the Internet. The transmission path 105 includes an address bus, a data bus, and control signal lines, and transmits data and control signals exchanged between the connected components.

[0017] FIG. 3 is a diagram showing a schematic configuration of one data record REA included in the user database DBA. A user database DBA is a collection of data records REA associated with a user. The data record REA includes fields FAA and FAB. The data record REA may include any number of fields after field FAC. Field FAA contains an identifier (hereinafter referred to as the "user code") for identifying the associated user. Field FAB contains various user information required for the associated user to use the smartphone POS service. The user information includes personal information such as the user's name and address. The user information may also include payment information such as credit card information. The user can register the delivery address of the product as appropriate. When the user registers the delivery address, a field containing delivery address information representing the delivery address is added to the data record REA. In other words, Figure 3 shows a state in which two delivery addresses are registered, with delivery address information for each separate delivery address set in fields FAC and FAD. The delivery address information includes information required for delivering the product, such as an address.

[0018] FIG. 4 is a diagram showing a schematic configuration of transaction data DAA and a configuration of one item of product data DAB included in this 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 no transaction data DAA is stored in auxiliary memory unit 103, or multiple transaction data DAA may be stored in auxiliary memory unit 103 simultaneously. The transaction data DAA includes fields FBA and FBB. The transaction data DAA may include any number of fields after field FBC. Field FBA contains a transaction code as an individual identifier for the transaction. Field FBB contains the user code of the user conducting the transaction. If there are registered products (hereinafter referred to as trading products) that are the subject of the transaction, fields associated with each of the trading products are added to the transaction data DAA. In other words, Figure 4 shows a situation where there are two trading products, and product data related to different trading products is set in fields FBC and FBD.

[0019] The product data DAB set in fields FBC, FBD... includes fields FCA, FCB, FCC, and FCD. Field FCA is set with a product code, which is an identifier for the relevant traded product. Field FCB is set with the quantity of the relevant traded product. Field FCC is set with a delivery flag, which indicates whether the relevant traded product is eligible for delivery. If the relevant traded product is eligible for delivery, field FCD is set with information regarding the delivery destination of the relevant traded product. Note that the product data DAB may include one or more fields in addition to fields FCA, FCB, FCC, and FCD, and various other information may be set therein, such as product name, unit price, discount information, etc.

[0020] The hardware of transaction equipment 100 may be, for example, a general-purpose server device. Transaction equipment 100 is generally transferred in a state in which transaction processing program PRA is stored in auxiliary storage unit 103, but user database DBA and transaction data DAA are not. However, transaction processing program PRA may be transferred separately from the hardware in a state in which transaction processing program PRA is not stored in auxiliary storage unit 103, or in which a different version of the same application program is stored in auxiliary storage unit 103. Transaction equipment 100 may be configured by writing transaction processing program PRA to auxiliary storage unit 103 in response to an operator's operation. Transaction processing program PRA may be transferred by recording it on a removable recording medium such as a magnetic disk, magneto-optical disk, optical disk, or semiconductor memory, or by communication via a network.

[0021] FIG. 5 is a block diagram showing the main circuit configuration of the accounting machine 200. The accounting machine 200 includes a processor 201, a main memory unit 202, an auxiliary memory unit 203, a touch panel 204, a barcode scanner 205, a credit card reader 206, a proximity communication unit 207, a card reader / writer 208, a change unit 209, a communication unit 210, and a transmission path 211. The processor 201, the main memory unit 202, the auxiliary memory unit 203, the touch panel 204, the barcode scanner 205, the credit card reader 206, the proximity communication unit 207, the card reader / writer 208, the change unit 209, and the communication unit 210 are connected to the transmission path 211.

[0022] The processor 201, the main memory unit 202 and the auxiliary memory unit 203 are connected by a transmission line 211 to form a computer for executing information processing relating to the control of the accounting machine 200. The functions of processor 201, main memory unit 202, auxiliary memory unit 203, and transmission path 211 are generally the same as those of processor 101, main memory unit 102, auxiliary memory unit 103, and transmission path 105, and therefore will not be described here. However, auxiliary memory unit 203 stores accounting processing program PRB instead of transaction processing program PRA. Accounting processing program PRB is an application program that describes the processing procedures related to information processing for accounting transactions while accepting user operations based on transaction information obtained from transaction processing device 100.

[0023] The touch panel 204 displays a screen for presenting information to the operator, and also inputs instructions by the operator touching the screen. The barcode scanner 205 optically reads a barcode placed in front of the reading port, and outputs barcode information represented by the read barcode.

[0024] The credit card reader 206 reads card information from a credit card. The proximity communication unit 207 performs proximity wireless communication with a wireless tag that is brought into proximity, acquires data stored in the wireless tag, and writes arbitrary information to the wireless tag through the proximity wireless communication. The card reader / writer 208 reads card data recorded on predetermined cards such as membership cards and prepaid cards, and also writes arbitrary data onto the membership cards.

[0025] The change unit 209 counts the value of coins inserted through the coin insertion slot and stores them in an internal storage. The change unit 209 discharges coins stored in the storage slot to a coin tray through the coin ejection slot. The change unit 209 counts the value of banknotes inserted through the banknote insertion slot and stores them in an internal storage. The change unit 209 discharges banknotes stored in the storage slot from the banknote ejection slot. The banknote ejection slot holds the discharged banknotes with a portion of them exposed to the outside.

[0026] Communication unit 210 performs communication processing for processor 201 to exchange various data with any device, such as transaction processing device 100, via communication network 2. As communication unit 210, a well-known device conforming to the communication method of communication network 2 can be used. The transmission path 211 includes an address bus, a data bus, a control signal line, etc. The transmission path 211 transmits data and signals exchanged between the components connected thereto.

[0027] The basic hardware of the accounting machine 200 can be, for example, the hardware of an accounting machine used in an existing POS system. In this case, the accounting machine 200 is generally transferred with the accounting processing program PRB stored in the auxiliary storage unit 203. However, the accounting machine 200 hardware and the accounting processing program PRB may be transferred separately without the accounting processing program PRB stored in the auxiliary storage unit 203. The accounting processing program PRB may then be written into the auxiliary storage unit 203 in response to an operator's operation. Alternatively, the accounting machine 200 hardware and the accounting processing program PRB may be transferred separately with a different version of an information processing program of the same type as the accounting processing program PRB stored in the auxiliary storage unit 203. The accounting processing program PRB may then be written to the auxiliary storage unit 203, replacing the information processing program already stored therein. The accounting processing program PRB can be transferred by recording it on a removable recording medium such as a magnetic disk, magneto-optical disk, optical disk, or semiconductor memory, or by communication via a network. The accounting processing program PRB may be stored in the main storage unit 202.

[0028] FIG. 6 is a block diagram showing the main circuit configuration of the user terminal 300. The user terminal 300 includes a processor 301, a main memory unit 302, an auxiliary memory unit 303, a touch panel 304, a camera 305, a mobile communication unit 306, a transmission path 307, and the like.

[0029] 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, and therefore will not be described here. However, auxiliary memory unit 303 stores user terminal program PRC instead of transaction processing program PRA. User terminal program PRC is an application program that describes the information processing procedures of processor 301 for operating user terminal 300 as a user interface for transaction processing by transaction processing equipment 100.

[0030] The touch panel 304 displays a screen for presenting information to the operator, and also inputs instructions by the operator touching the screen. 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. The mobile communication unit 306 is an interface for data communication via the communication network 2. As the mobile communication unit 306, for example, a well-known communication device for performing data communication via a mobile communication network can be used. The basic hardware of the user terminal 300 is assumed to be, for example, the hardware of a smartphone.

[0031] FIG. 7 is a block diagram showing the main circuit configuration of attendant terminal 400. As shown in FIG. The attendant terminal 400 includes a processor 401, a main memory unit 402, an auxiliary memory unit 403, a touch panel 404, a camera 405, a mobile communication unit 406, a transmission path 407, and the like. The functions of processor 401, main memory unit 402, auxiliary memory unit 403, and transmission path 407 are generally equivalent to those of processor 101, main memory unit 102, auxiliary memory unit 103, and transmission path 105. The functions of touch panel 404, camera 405, and mobile communication unit 406 are generally equivalent to those of touch panel 304, camera 305, and mobile communication unit 306. However, auxiliary memory unit 403 stores attendant terminal program PRD instead of transaction processing program PRA. Attendant terminal program PRD is an application program that describes the information processing procedures of processor 401 to operate attendant terminal 400 as a user interface for store clerks who support transactions processed by transaction processing device 100. A stationary computer device may be used as the hardware of the attendant terminal 400. In this case, a communication unit for wired communication may be used instead of the mobile communication unit 406.

[0032] 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 clearly explain the characteristic operations of this embodiment, explanation of some of the processes will be omitted. For example, if some kind of error occurs, processing may be performed to deal with the error, but a description of such processing will be omitted.

[0033] As explained below, the smartphone POS service is a service provided to users by transaction processing system 1. When an information communication terminal attached to a cart is used as user terminal 300, the service may also be called a cart POS service. For each product sold at a store that offers the smartphone POS service, it is predetermined whether or not it can be delivered. For products that are determined to be deliverable (hereinafter referred to as deliverable products), store staff will arrange for their delivery in response to a request from a user. Which products among those sold at a store are deemed deliverable may be determined as appropriate by the store manager, etc. Whether or not a product can be delivered is indicated for each product, for example, in the product master data. Products that are deliverable may be delivered as described above, or may be taken home by the user. Products that are not determined to be deliverable are, in principle, taken home by the user.

[0034] To use the smartphone POS service, a user registers with the smartphone POS service provider. For example, when information processing based on user terminal program PRC (hereinafter referred to as user terminal processing) is executed for the first time on user terminal 300, or when the user requests the start of user registration, processor 301 initiates processing for user registration. While receiving information input by the user, processor 301 then requests transaction equipment 100 to add a new data record REA to user database DBA stored in auxiliary storage unit 103. At this time, a user code may be determined by transaction equipment 100, for example. Processor 301 may receive notification of the user code from transaction equipment 100 and store it in auxiliary storage unit 303. After user registration, the user can appropriately register a delivery address for merchandise. The processing by processor 101 in transaction equipment 100 for registering a delivery address may be similar to that performed in, for example, an online shopping service.

[0035] Then, the user takes the user terminal 300 with the user terminal processing activated and enters a store that provides the smartphone POS service. The user operates user terminal 300 to cause a predetermined check-in process to be performed between user terminal 300 and transaction processing device 100. After completing the check-in, the user searches for the product to be traded in the store.

[0036] When processor 101 in transaction equipment 100 completes check-in processing through information processing based on transaction processing program PRA, it begins registration processing based on transaction processing program PRA. The registration processing is information processing for registering a product specified by a user as a transaction product. Transaction equipment 100 can also execute registration processes for transactions related to different users individually and in parallel. In this case, multiple user terminals 300 used by transaction equipment 100 as user interface terminals will exist simultaneously. However, the following description will focus only on processing a transaction related to one user. Thus, in the following description, "user terminal 300" refers to one user terminal 300 used by a user for the transaction processing of interest.

[0037] 8, 9, 10, 11, 12 and 13 are flowcharts of the registration process. 8, the processor 101 instructs the user terminal 300 to display a registration screen. The registration screen includes a list of products already registered as trading products, and is a screen that allows the user to recognize the registration status of the trading products. For example, the processor 101 generates screen data representing a registration screen that reflects the registration status of the trading products, and sends instruction data from the communication unit 104 to the communication network 2, addressed to the user terminal 300, for instructing the user terminal 300 to display a screen based on the screen data.

[0038] When instruction data for instructing a screen display is transmitted to user terminal 300 via communication network 2, mobile communication unit 306 in user terminal 300 receives the instruction data. Upon receiving the instruction data, mobile communication unit 306 notifies processor 301 of the reception of the instruction data. Upon receiving the instruction data for instructing a screen display, processor 301 causes touch panel 304 to display a screen represented by the screen data included in the instruction data through user terminal processing. The transmission and reception of display instructions for various screens described below are performed in the same manner as above, although the contents of the screen data differ.

[0039] FIG. 14 is a diagram showing an example of the registration screen SCA. The registration screen SCA displays an image representing the registration status in the display area ARA. The registration screen SCA displays buttons BUA and BUB. In the example of FIG. 14, the image displayed in the display area ARA shows that three items have been registered: one each of items with product names "AAAAA," "BBBBB," and "CCCCC" and unit prices of 300 yen, 400 yen, and 700 yen, respectively, with a suggested retail price of 1,400 yen. The suggested retail price is the amount calculated by subtracting discounts from various services, such as coupons, from the total unit price of all the items being traded. If the transaction were settled without changing the traded items or applied services, this suggested retail price would be the settlement amount. In the example of FIG. 14, the image displayed in the display area ARA shows that items with product names "BBBBB" and "CCCCC" are available for delivery. In the example of FIG. 14, the image displayed in the display area ARA shows that an item with product name "CCCCC" has been set as a delivery item. The image displayed in the display area ARA changes sequentially depending on the registration status of the trading product. When the processor 101 first executes ACT1 in Fig. 8, the trading product has not yet been registered. Therefore, on the registration screen SCA represented by the screen data sent to the user terminal 300 when the processor 101 first executes ACT1 in Fig. 8, the image displayed in the display area ARA does not show information about each product, but rather shows that the total number of items is 0 and the suggested price is 0 yen.

[0040] The button BUA is a soft key for receiving an instruction to transition to a state in which a new product can be scanned. The button BUB is a soft key for receiving a designation to start checkout. Note that the registration screen SCA and various screens described below illustrate the main display objects, and some display objects may be omitted from the illustration.

[0041] Processor 301 waits for some operation by the user on registration screen SCA while displaying registration screen SCA on touch panel 304. When some operation is performed on registration screen SCA, processor 301 sends notification data for notifying transaction equipment 100 of the details of the operation from mobile communication unit 306 to communication network 2. Note that the display of various screens in response to instructions from transaction equipment 100 and the notification of the details of the operation based on each screen are all executed by user terminal processing, including the processing described below.

[0042] When notification data for notifying 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 receipt of the notification data. The sending and receiving of notifications of operation details relating to various screens described below is performed in the same manner as above, although the operation details are different.

[0043] 8, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, 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 determines the answer as YES and proceeds to ACT13. In ACT 13, the processor 101 checks whether the operation performed was an operation to specify the start of a scan. If the processor 101 cannot confirm the event, it determines NO and proceeds to ACT 14.

[0044] In ACT 14, the processor 101 checks whether the operation performed was an operation to specify a change in conditions for a registered trading product. If the processor 101 cannot confirm this event, it determines NO and proceeds to ACT 15. In ACT15, processor 101 checks whether the operation performed was an operation specifying the start of a transaction. If processor 101 cannot confirm the relevant event, it determines NO, checks the content of the operation, and proceeds to other processing to perform the appropriate processing. For example, processor 101 checks that an operation specifying the cancellation of a transaction was performed, executes processing to cancel the transaction, and then terminates the registration processing. Note that a detailed explanation of the other processing will be omitted here.

[0045] When a user registers a new commodity as a trading commodity, the user performs a predetermined operation to specify the start of scanning, such as tapping button BUA on registration screen SCA. When this operation is notified from user terminal 300 to transaction equipment 100, processor 101 determines YES in ACT13 and proceeds to ACT21 in FIG. 9. In ACT21, the processor 101 instructs the user terminal 300 to display a product scan screen. The product scan screen is a screen for scanning a barcode representing a product code.

[0046] FIG. 15 is a diagram showing an example of the product scan screen SCB. The product scan screen SCB includes a display area ARB and a button BUD. The display area ARB is an area for displaying an image obtained by the camera 305. The button BUC is a soft key that allows the user to declare that the product code scanning is to be stopped. When displaying product scan screen SCB, processor 301 in user terminal 300 activates camera 305, thereby superimposing an image obtained by camera 305 within display area ARB. If the user performs any operation on product scan screen SCB, processor 301 notifies transaction processing device 100 of the content of the operation, as described below.

[0047] When processor 101 in transaction equipment 100 has finished issuing an instruction to display the product scan screen in ACT21 in FIG. 4, the process proceeds to ACT22. In ACT22, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT23. In ACT23, the processor 101 checks whether a scan has been performed. 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. For example, the processor 101 checks that an operation to stop scanning, such as tapping the button BUC, has been performed, returns to ACT1 in FIG. 8, and returns the display screen of the touch panel 304 of the user terminal 300 to the registration screen SCA. A detailed description of the other processing will be omitted here.

[0048] When product scan screen SCB appears on touch panel 304, the user points camera 305 toward the product to be registered as a transaction product so that the barcode displayed on the product is reflected in display area ARB. Processor 301 analyzes the image obtained by camera 305 and attempts to read the barcode. If processor 301 successfully reads the barcode, it notifies transaction processing device 100 that the scan has been performed, along with a notification of the data represented by the read barcode (hereinafter referred to as barcode data).

[0049] In response to the notification sent from user terminal 300 in this manner, processor 101 in transaction equipment 100 determines YES in ACT23 in FIG. 9 and proceeds to ACT24. As ACT24, the processor 101 determines the commodity to be traded based on the notified barcode data. That is, the processor 101, for example, extracts the commodity code included in the barcode data and determines the commodity identified by the commodity code as the commodity to be traded (hereinafter referred to as the candidate commodity). The processor 101 may receive notification from the user terminal 300 that a preset button displayed on the touch panel 304 has been tapped, and determine the commodity assigned to the preset button as the candidate commodity. The processor 101 may also receive notification from the user terminal 300 of a commodity code directly entered on the touch panel 304 as a numeric string, and determine the commodity identified by the commodity code as the candidate commodity. Thus, by the processor 101 executing information processing based on the transaction processing program PRA, the computer including the processor 101 as its core functions as a determination means. The camera 305 functions as a means for inputting a commodity code by scanning, and the touch panel 304 functions as a means for inputting a commodity code by tapping.

[0050] In ACT 25, the processor 101 checks whether the candidate product determined as above is a deliverable product. If the candidate product is not a deliverable product, the processor 101 determines NO and proceeds to ACT 26. As ACT26, the processor 101 instructs the user terminal 300 to display a first registration confirmation screen. The first registration confirmation screen is a screen for confirming whether or not to register a candidate product that cannot be delivered as a trading product.

[0051] FIG. 16 is a diagram showing an example of the first registration confirmation screen SCC. The first registration confirmation screen SCC shown in Figure 16 is an example where the candidate product has the product name "DDDDD" and a unit price of 250 yen. The first registration confirmation screen SCC shows a display box BOA and buttons BUD, BUE, BUF, and BUG. The display box BOA shows the quantity inside. The button BUD is a soft key for receiving a designation to decrease the quantity. The button BUE is a soft key for receiving a designation to increase the quantity. The button BUF is a soft key for receiving a designation not to register as a trading product. The button BUG is a soft key for receiving a designation to register as a trading product.

[0052] 9, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT . In ACT28, the processor 101 checks whether a change in quantity has been specified. If the processor 101 cannot confirm this event, it determines NO and proceeds to ACT29. In ACT29, processor 101 checks whether a designation to register the product as a trading product has been made. If 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. For example, processor 101 checks that a predetermined operation to designate cancellation of registration, such as tapping button BUF, has been performed, and returns to ACT21. A detailed description of the other processing will be omitted here.

[0053] If the user wishes to change the quantity, the user specifies the quantity change by a predetermined operation such as tapping the button BUD or the button BUE. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT28 and proceeds to ACT30. In ACT30, the processor 101 changes the quantity according to the specification, and then returns to the standby state in ACT27.

[0054] If the user decides to register the candidate product displayed on the first registration confirmation screen SCC as the trading product in the quantity displayed in the display box BOA, the user specifies the registration by a predetermined operation, such as tapping the button BUG. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT29 and proceeds to ACT31. In ACT31, the processor 101 registers the candidate product as a take-out item in the quantity shown in the display box BOA. A take-out item is a transaction product that the user takes home from the store without delivery. The processor 101 updates the transaction data DAA to include product data DAB in which the product code of the candidate product and the quantity shown in the display box BOA are set in fields FCA and FCB, respectively. The processor 101 sets a delivery flag in field FCC of the above-mentioned product data DAB, indicating that the product is not eligible for delivery, and does not set delivery destination information in field FCD. The processor 101 then returns to ACT11 in FIG. 8, instructs the user terminal 300 to display the registration screen SCA according to the transaction data updated as described above, and returns to the standby state in ACT12.

[0055] Meanwhile, if the candidate product determined in ACT24 in FIG. 9 is a deliverable product, the processor 101 determines YES in ACT25 and proceeds to ACT41 in FIG. In ACT41, the processor 101 instructs the user terminal 300 to display a second registration confirmation screen. The second registration confirmation screen is a screen for confirming whether or not to register the deliverable candidate product as a trading product.

[0056] Fig. 17 is a diagram showing an example of the second registration confirmation screen SCD. In Fig. 17, the same display elements as those shown in Fig. 16 are given the same reference numerals, and detailed description thereof will be omitted. The second registration confirmation screen SCD is a screen in which buttons BUH and BUI are added to the first registration confirmation screen SCC. Button BUH is a soft key for receiving a designation that the candidate product is not to be included in the delivery target. Button BUI is a soft key for receiving a designation that the candidate product is to be included in the delivery target. Note that buttons BUH and BUI are also display objects that indicate the current setting status of whether or not the candidate product is to be included in the delivery target. That is, in the example of FIG. 17, button BUI is displayed in gray out to indicate that the product is not to be included in the delivery target.

[0057] The first registration confirmation screen SCC and the second registration confirmation screen SCD may be a common registration confirmation screen like the second registration confirmation screen SCD. In this case, the processor 101 disables, for example, buttons BUH and BUI in ACT26 in Fig. 9, and indicates that they are inoperable by displaying them in grayout or the like.

[0058] If the user decides to include a candidate product in the delivery list when the candidate product is not included in the delivery list, the user designates the candidate product as such by tapping the button BUI or other predetermined operation. If the user decides not to include a candidate product in the delivery list when the candidate product is included in the delivery list, the user designates the candidate product as such by tapping the button BUH or other predetermined operation.

[0059] In ACT42, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT43. In ACT43, the processor 101 checks whether a change in quantity has been specified. If the processor 101 cannot confirm this event, it determines NO and proceeds to ACT44. In ACT44, the processor 101 checks whether or not a designation has been made to register the product as a trading product. If the processor 101 cannot confirm this event, it determines NO and proceeds to ACT45. In ACT45, the processor 101 checks whether delivery 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. For example, the processor 101 checks that a predetermined operation has been performed to specify that registration is to be canceled, such as tapping the button BUF, and returns to ACT21 in FIG. 9. A detailed description of the other processing will be omitted here.

[0060] If the user wishes to change the quantity, the user specifies the quantity change by a predetermined operation such as tapping the button BUD or the button BUE. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT43 and proceeds to ACT46. In ACT46, the processor 101 changes the quantity according to the specification, and then returns to the standby state in ACT42.

[0061] If the user decides to register the candidate products displayed on the second registration confirmation screen SCD as trading products to be taken home in the quantity displayed in the display box BOA, the user specifies the registration by a predetermined operation such as tapping the button BUG. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT44 and proceeds to ACT47. In ACT47, the processor 101 registers the candidate product as a take-out item, similar to ACT31 in Fig. 9. Then, the processor 101 returns to ACT11 in Fig. 8, instructs the user terminal 300 to display the registration screen SCA according to the transaction data updated as described above, and then returns to the standby state in ACT12.

[0062] If the user decides to request delivery of the candidate products displayed on the second registration confirmation screen SCD from the store, the user specifies the delivery by a predetermined operation, such as tapping the button BUI in Fig. 17. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT45 in Fig. 10 and proceeds to ACT48. As ACT48, the processor 101 instructs the user terminal 300 to display a reception screen. The reception screen is a screen for receiving a designation of a delivery destination.

[0063] FIG. 18 is a diagram showing an example of the reception screen SCE. The reception screen SCE shown in FIG. 18 is an example of a situation in which two delivery destinations for the user have already been registered in the user database DBA. The reception screen SCE displays buttons BUJ, BUK, BUL, and BUM. Button BUJ is a soft key for specifying a delivery destination registered in the user database DBA. The number of buttons BUJ displayed on the reception screen SCE changes depending on the number of delivery destinations registered in the user database DBA. Figure 18 shows an example of a situation where two delivery destinations are registered in the user database DBA, so two buttons BUJ are displayed. A character string is displayed within the area of ​​button BUJ to allow the user to distinguish between the delivery destinations. If no delivery destinations are registered in the user database DBA, the processor 101 changes the reception screen SCE to a screen that does not display any buttons BUJ. The button BUK is a soft key for receiving a user instruction to proceed to specify a delivery destination other than the delivery destination registered in the user database DBA. The button BUL is a soft key for receiving a specification to cancel delivery. The button BUM is a soft key for receiving a specification to confirm the delivery destination.

[0064] In ACT49, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT50. In ACT50, the processor 101 checks whether a delivery destination has been specified. If the processor 101 cannot confirm the event, it determines NO and proceeds to ACT51. In ACT51, the processor 101 checks whether a confirmation has been specified. If the processor 101 cannot confirm the event, it determines NO, checks the content of the operation, and proceeds to other processing to perform the corresponding processing. For example, the processor 101 checks that a predetermined operation has been performed to specify that delivery is to be canceled, such as tapping the button BUL, and returns to ACT41. A detailed explanation of the other processing will be omitted here.

[0065] The user specifies a delivery destination for the candidate product by a predetermined operation on the reception screen SCE. For example, if the user wants to specify one of the delivery destinations registered in the user database DBA, the user taps the button BUJ that displays the corresponding delivery destination. Alternatively, if the user wants to specify an unregistered delivery destination, the user taps the button BUK. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT50 and proceeds to ACT52. In ACT52, the processor 101 determines the delivery destination of the candidate product in accordance with the specification. For example, if button BUJ is tapped, the processor 101 determines the delivery destination associated with the tapped button BUJ as the delivery destination of the candidate product. For example, if button BUK is tapped, the processor 101 then prompts the user to specify an address on the user terminal 300, and determines the specified address as the delivery destination of the candidate product. Then, the processor 101 returns to the standby state in ACT49.

[0066] The user can also correct the delivery destination of the candidate product by performing the operation to specify the delivery destination again. In this case, the processor 101 repeats ACT52 multiple times, and the delivery destination determined by the last execution of ACT52 is set as the delivery destination of the candidate product. When the user has finished specifying the delivery destination of the candidate products, the user specifies confirmation by a predetermined operation such as tapping on the button BUM. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT51 and proceeds to ACT53.

[0067] In ACT53, the processor 101 registers the candidate product as a delivery item in the quantity shown in the display box BOA. The delivery item refers to a transaction product for which a store clerk arranges delivery to a specified delivery destination. The processor 101 updates the transaction data to include product data DAB, for example, in which the product code of the candidate product and the quantity shown in the display box BOA are set in fields FCA and FCB, respectively. The processor 101 then sets a delivery flag in field FCC of the product data DAB, indicating that the product is a delivery target, and sets delivery destination information indicating the delivery destination determined in ACT52 in field FCD. The processor 101 then proceeds to ACT16 in FIG. 8. Thus, by the processor 101 executing information processing based on the transaction processing program PRA, the computer, with the processor 101 as its core, functions as a determination means and a registration means. For take-out items, the customer picks up the registered quantity from the sales floor and carries it with them. For delivery items, the customer may pick up all or part of the items from the sales floor and carry them with them, or may not pick up any of them.

[0068] In ACT 16, processor 101 checks whether the product registered as a delivery item is in a low-stock state. A low-stock state refers to a situation in which, if a customer does not pick up the delivery item from the sales floor, the product may be sold out before a store clerk arranges for delivery. The inventory status of a delivery item that constitutes a low-stock state may be determined as appropriate by a store manager or other appropriate person. For example, in a store that maintains inventory for delivery in a store warehouse for deliveries of products that are available for delivery, a low-stock state may be defined as a state in which the number of items in stock for delivery is less than a predetermined number. Another example is to monitor the number of products displayed on the sales floor, and define a low-stock state as a state in which the number is less than a predetermined number. Another example is to monitor the total number of products in the store, and define a low-stock state as a state in which the number is less than a predetermined number. If the processor 101 cannot confirm that the inventory is low, it judges the answer as NO and returns to ACT11 in Figure 8, instructs the user terminal 300 to display the registration screen SCA according to the transaction data updated as described above, and then returns to the standby state of ACT12.

[0069] FIG. 19 is a diagram showing an example of the registration screen SCA. The registration screen SCA shown in Figure 19 is an example of what happens after two items with the product name "DDDDD" and a unit price of 250 yen have been registered as take-out items, and one item with the product name "EEEEE" and a unit price of 1,000 yen has been registered as a delivery item, from the state in which the registration screen SCA shown in Figure 14 is displayed on the user terminal 300.

[0070] Now, if it is confirmed that the inventory is low, the processor 101 determines YES in ACT16 and proceeds to ACT17. In ACT17, the processor 101 instructs the user terminal 300 to display a recommendation screen. The recommendation screen is a screen for notifying the user that it is recommended to pick up from the sales floor a product that has just been registered as a product to be delivered.

[0071] FIG. 20 is a diagram showing an example of the recommendation screen SCF. The recommendation screen SCF is a screen that displays a window WIA superimposed on the registration screen SCA. The window WIA displays a text message recommending that the user pick up the product registered for delivery from the sales floor. The window WIA displays a button BUN. The button BUN is a soft key that allows the user to declare that they have confirmed the notification on the recommendation screen SCF. Thus, the processor 101 executes information processing based on the transaction processing program PRA, and the computer with the processor 101 as its central part functions as a notification means.

[0072] 8, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT19. In ACT 19, the processor 101 checks whether a declaration of confirmation has been made. If the processor 101 cannot confirm the event, it determines NO, checks the content of the operation, and proceeds to other processing to perform processing accordingly. Note that a detailed description of the other processing will be omitted here.

[0073] After confirming the notification content on the recommendation screen SCF, the user appropriately decides whether or not to pick up the relevant product. Then, the user declares that they have confirmed the content by performing a predetermined operation such as tapping the button BUN. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT19 and returns to ACT11, instructs the user terminal 300 to display the registration screen SCA according to the transaction data updated as described above, and then returns to the standby state in ACT12.

[0074] When a user wishes to change the conditions of a registered product, the user specifies the change of conditions by a predetermined operation, such as tapping a triangular display object associated with each trading product on the registration screen SCA. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT14 in FIG. 8 and proceeds to ACT61 in FIG. 11. In ACT 61, the processor 101 checks whether the product for which the condition change has been specified is a deliverable product. If the processor 101 cannot confirm that the product is a deliverable product, it determines NO and proceeds to ACT 62, and if it can confirm that the product is a deliverable product, it determines YES and proceeds to ACT 63.

[0075] As ACT62, the processor 101 instructs the user terminal 300 to display a first change screen. The first change screen is a screen that receives a user's designation for changing the conditions for a product that is not a deliverable product. The first change screen may be a screen similar to the first registration confirmation screen SCC shown in FIG. 16, for example. However, instead of the buttons BUF and BUG, ​​the first change screen displays a button for receiving a designation to cancel the change and a button for receiving a designation to execute the change.

[0076] As ACT63, the processor 101 instructs the user terminal 300 to display a second change screen. The second change screen is a screen that receives a user's designation for changing the conditions for deliverable products. The second change screen may be a screen similar to the second registration confirmation screen SCD shown in FIG. 17, for example. However, instead of the buttons BUF and BUG, ​​the second change screen displays a button for receiving a designation to cancel the change and a button for receiving a designation to execute the change.

[0077] When the processor 101 completes the display instruction in ACT62 or ACT63, it proceeds to ACT64 in either case. In ACT64, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT65.

[0078] In ACT65, the processor 101 checks whether a change in quantity has been specified. If the processor 101 cannot confirm this event, it determines NO and proceeds to ACT66. In ACT66, the processor 101 checks whether a change has been specified regarding whether or not the item is to be included in the delivery target. If the processor 101 cannot confirm the relevant event, it determines NO, checks the details of the operation, and proceeds to other processing to perform the corresponding processing. For example, the processor 101 checks that a predetermined operation has been performed to specify the cancellation of the change, and returns to ACT11 in FIG. 8. A detailed explanation of the other processing will be omitted here.

[0079] If the user wishes to change the quantity, the user specifies the quantity change by a predetermined operation such as tapping the button BUD or the button BUE. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT65 and proceeds to ACT67. In ACT67, the processor 101 changes the quantity according to the specification, and then returns to the standby state in ACT64.

[0080] If the user wishes to change the setting to "deliver" when the setting is "not deliver" for a deliverable product, the user specifies the change in setting by a predetermined operation, such as tapping a button on the second change screen that corresponds to the button BUI in Fig. 17. Also, if the user wishes to change the setting to "not deliver" when the setting is "deliver" for a deliverable product, the user specifies the change in setting by a predetermined operation, such as tapping a button on the second change screen that corresponds to the button BUI in Fig. 17. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT66 and proceeds to ACT68. In ACT68, the processor 101 changes the setting of whether or not the product subject to the setting change is to be delivered. Specifically, the processor 101, for example, inverts the state of the delivery flag set in the field FCC of the product data DAB associated with the product subject to the setting change in the transaction data DAA. At this time, the processor 101 updates the second change screen displayed on the user terminal 300 to show the changed setting.

[0081] In ACT69, the processor 101 checks whether the changed setting is a setting for delivery or not. If the changed setting is a setting for not delivering, the processor 101 determines NO and returns to the standby state in ACT64.

[0082] If the changed setting is a setting for delivery, the processor 101 determines YES in ACT69 and proceeds to ACT70. The processor 101 as the ACT 70 instructs the user terminal 300 to display a reception screen. The reception screen here may be the same as the reception screen SCE shown in FIG.

[0083] In ACT71, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT72. In ACT72, the processor 101 checks whether a delivery destination has been specified. If the processor 101 cannot confirm the event, it determines NO and proceeds to ACT73. In ACT 73, the processor 101 checks whether a confirmation has been specified. If the processor 101 cannot confirm the event, it determines NO, checks the content of the operation, and proceeds to other processing to perform the corresponding processing. Note that a detailed description of the other processing will be omitted here.

[0084] The user specifies the delivery destination of the candidate product by a predetermined operation on the reception screen. For example, if the user wants to specify one of the delivery destinations registered in the user database DBA, the user taps the button BUJ that displays the corresponding delivery destination. Alternatively, for example, if the user wants to specify an unregistered delivery destination, the user taps the button BUK. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT72 and proceeds to ACT74. In ACT74, the processor 101 determines the delivery destination of the candidate product in accordance with the specification, similar to ACT52 in Fig. 10. Then, the processor 101 returns to the standby state of ACT71.

[0085] When the user has finished specifying the delivery destination of the candidate products, the user specifies confirmation by a predetermined operation such as tapping on the button BUM. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT73 and proceeds to ACT75. In ACT 75, processor 101 sets the delivery destination determined as described above as the delivery destination for the product whose settings are to be changed. Specifically, processor 101 sets delivery destination information representing the delivery destination determined as described above in field FCD of product data DAB associated with the product whose settings are to be changed in transaction data DAA. Then, processor 101 executes ACT 16 and subsequent steps in FIG. 8 in the same manner as described above.

[0086] After the user has registered all the products for this transaction and completed the delivery settings, he or she specifies the start of accounting by a predetermined operation, such as tapping the button BUC on the registration screen SCA. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT 15 in FIG. 8 and proceeds to ACT 81 in FIG. 12. As ACT81, processor 101 instructs user terminal 300 to display a transaction screen. The transaction screen is a screen for handing over transaction processing related to a transaction that is currently being processed to transaction processing device 200. The transaction screen displays a barcode containing information that allows transaction processing device 100 to make an inquiry about the transaction.

[0087] If a store has multiple payment machines 200 installed, the user arbitrarily selects an unused payment machine 200 from among them and has barcode scanner 205 installed in that payment machine 200 read the barcode displayed on the payment screen. Processor 201 in payment machine 200 then requests payment data from transaction processing device 100 based on the information displayed by the barcode read by barcode scanner 205.

[0088] In ACT82, the processor 101 waits for a request for accounting data from the accounting device 200. If accounting data is requested as described above, the processor 101 determines YES and proceeds to ACT83. The processor 101 as ACT83 transmits to the requesting accounting device 200 accounting data for causing the accounting device 200 to settle the transaction that is the subject of transaction processing.

[0089] In this way, in accordance with the transaction data transmitted from transaction equipment 100, processor 201 in transaction device 200 receives transaction-related user operations while appropriately displaying screens on touch panel 204. The operations received by processor 201 here include instructions to change delivery settings and instructions to execute a transaction. When a predetermined operation, including these instructions, is performed, processor 201 notifies transaction equipment 100.

[0090] After processor 101 in transaction processing apparatus 100 transmits the transaction data in ACT83 in FIG. 12, it proceeds to ACT84. In ACT84, the processor 101 waits for an operation to be performed on the payment device 200. If the operation is notified from the payment device 200 as described above, the processor 101 determines YES and proceeds to ACT85.

[0091] In ACT85, the processor 101 checks whether the operation performed was an operation to specify a change in the conditions for delivery of the traded product. If the processor 101 cannot confirm the event, it determines NO and proceeds to ACT86. As ACT86, processor 101 checks whether the operation performed was an operation specifying the execution of a transaction. If processor 101 cannot confirm the relevant event, it determines NO, checks the content of the operation, and proceeds to other processing to perform the appropriate processing. A detailed explanation of other processing will be omitted here.

[0092] If the processor 101 receives notification from the payment device 200 of an operation to specify a change in the conditions for delivery of the transaction product, the processor 101 determines YES in ACT85 and proceeds to ACT87. In ACT87, the processor 101 executes processing to change the conditions for delivery of the traded product. This processing may be similar to the processing in Figure 11 and the processing from ACT16 onwards in Figure 8, using the payment device 200 as a user interface terminal. However, each display screen may be changed to suit the display on the payment device 200. Once the processor 101 has completed this processing, it returns to the standby state in ACT84.

[0093] If the processor 101 has received notification from the payment device 200 of an operation specifying the execution of a transaction, the processor 101 determines YES in ACT86 and proceeds to ACT88. As ACT88, processor 101 instructs payment device 200 to execute the transaction. Upon receiving this instruction, processor 201 in payment device 200 executes processing to complete the transaction. This processing by processor 201 may be similar to the processing performed by payment devices in existing POS systems, for example. When processor 201 has completed the transaction, it notifies transaction processing device 100 of this fact.

[0094] After processor 101 in transaction processing device 100 issues a transaction execution instruction in ACT88 in FIG. 12, the process proceeds to ACT89. In ACT89, the processor 101 waits for some kind of notification from the payment device 200. If a notification is received from the payment device 200, the processor 101 determines YES and proceeds to ACT90.

[0095] In ACT90, processor 101 checks whether the notification indicates that the transaction is complete. If processor 101 cannot confirm the relevant event, it determines NO, checks the content of the notification, and proceeds to other processing to perform the appropriate processing. For example, if processor 101 confirms that the notification indicates that the transaction was not completed due to some kind of error, it executes processing to deal with the error. A detailed explanation of the other processing will be omitted here.

[0096] If the processor 101 receives a notification of the completion of the transaction from the payment device 200 as described above, it determines YES in ACT90 and proceeds to ACT91. In ACT91, the processor 101 checks whether the transaction items for the completed transaction include a delivery item. If the processor 101 cannot confirm this, it determines NO and ends the transaction processing. However, if the processor 101 confirms that a delivery item is included, it determines YES and proceeds to ACT92. As ACT92, the processor 101 instructs the user terminal 300 to display a pickup confirmation screen. The pickup confirmation screen is a screen for confirming whether or not the user has picked up the delivery item.

[0097] FIG. 21 is a diagram showing an example of the pickup confirmation screen SCG. The pickup confirmation screen SCG displays a text message asking the user whether or not they have picked up the delivery. The pickup confirmation screen SCG displays buttons BUO and BUP. The button BUO is a soft key for receiving a user's declaration that they have not picked up the delivery. The button BUP is a soft key for receiving a user's declaration that they have picked up the delivery.

[0098] 12, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT 101 in FIG. In ACT 101, the processor 101 checks whether a declaration to the effect that a pickup has been made has been made. If the processor 101 cannot confirm the event, it determines NO and proceeds to ACT 102. In ACT 102, the processor 101 checks whether a declaration that the item has not been picked up has been made. 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. Note that a detailed explanation of the other processing will be omitted here.

[0099] If the user has not picked up any delivery items, the user declares that they have not picked up any items by performing a predetermined operation such as tapping the button BUO on the pickup confirmation screen SCG. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT102 and proceeds to ACT103. In ACT103, processor 101 instructs attendant terminal 400 to display a first delivery instruction screen. The first delivery instruction screen is a screen that instructs the store clerk in charge of delivery procedures to pick up all of the items to be delivered from the sales floor or warehouse and then deliver them. If transaction processing system 1 includes multiple attendant terminals 400, processor 101 instructs attendant terminal 400 that has been previously designated as a notification destination among these multiple attendant terminals 400 to display the first delivery instruction screen. Then, processor 101 ends the transaction processing. When instruction data instructing the display of the first delivery instruction screen is received by the mobile communication unit 406, the processor 401 of the attendant terminal 400 causes the touch panel 404 to display the first delivery instruction screen in accordance with the instruction data.

[0100] FIG. 22 is a diagram showing an example of the first delivery instruction screen SCH. The first delivery instruction screen SCH displays various information for informing the store clerk of the delivery procedures that the store clerk should carry out, using character strings, for example, as shown in FIG. The store clerk picks up the item to be delivered from the sales floor or warehouse in accordance with the information displayed on the first delivery instruction screen SCH, and then carries out the procedures for delivery to the specified delivery destination.

[0101] If the user has picked up at least one delivery item, the user declares that the delivery item has been picked up by performing a predetermined operation such as tapping the button BUP on the pickup confirmation screen SCG. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT101 and proceeds to ACT104.

[0102] As ACT104, the processor 101 instructs the user terminal 300 to display a selection screen. The selection screen is a screen that allows the user to select a method for handing over the picked-up delivery item to a store clerk. Note that a store that provides a smartphone POS service using the transaction processing system 1 of this embodiment allows users to use two delivery methods at their discretion: "hand over to store clerk" and "add to cart." In the "hand over to store clerk" method, the user hands the delivery item to the store clerk. In the "add to cart" method, the user places the delivery item in a delivery basket (hereinafter referred to as a delivery basket) installed near the location of the payment device 200, etc.

[0103] FIG. 23 is a diagram showing an example of the selection screen SCI. The selection screen SCI displays a text message that allows the user to select the delivery method for the delivery item. The selection screen SCI displays buttons BUQ and BUR. The button BUQ is a soft key for specifying whether to have the item handed over to a store clerk. The button BUP is a soft key for specifying whether to put the item in a cart.

[0104] 13, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT . In ACT 106, the processor 101 checks whether handing over to a store clerk has been specified. If the processor 101 cannot confirm this event, it determines NO and proceeds to ACT 107. In ACT 107, the processor 101 checks whether or not a cart has been selected. If the processor 101 cannot confirm the event, it determines "NO," checks the operation, and proceeds to other processing to perform the corresponding processing. A detailed description of the other processing will be omitted here.

[0105] If the user wishes to hand over the delivery item being picked up to a store clerk, the user specifies handover to the store clerk by a predetermined operation such as tapping the button BUQ. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT106 and proceeds to ACT108. As ACT108, the processor 101 instructs the user terminal 300 to display a handover screen. The handover screen is a screen for handing over information about the delivery item to a store clerk.

[0106] FIG. 24 is a diagram showing an example of the takeover screen SCJ. The takeover screen SCJ displays a text message informing the user that the user should present this screen to the store clerk. The takeover screen SCJ displays an image IMA representing a barcode. The processor 101 includes in the barcode represented by the image IMA at least a transaction code as an identifier of the transaction being processed.

[0107] The user presents takeover screen SCJ to the store clerk. The store clerk has attendant terminal 400 scan the barcode represented by image IMA. Processor 401 of attendant terminal 400 then sends a takeover request to transaction processing device 100, accompanied by notification of the transaction code represented by the barcode.

[0108] After processor 101 of transaction equipment 100 instructs display of the transition screen in ACT 108, the process proceeds to ACT 109 in FIG. In ACT 109, the processor 101 waits for a takeover request. Then, when the processor 101 receives a takeover request from the attendant terminal 400 as described above, the processor 101 proceeds to ACT 110.

[0109] As ACT110, the processor 101 instructs the attendant terminal 400 that has made the takeover request to display a second delivery instruction screen. The second delivery instruction screen is a screen that instructs the store clerk to receive the delivery item that the user has already picked up and then deliver the delivery item including that delivery item. FIG. 25 is a diagram showing an example of the second delivery instruction screen SCK. The second delivery instruction screen SCK displays various information for informing the store clerk of the delivery procedures that the store clerk should carry out, using character strings as shown in FIG. 25, for example.

[0110] The store clerk receives the delivery item from the user who presented the handover screen SCJ. If the store clerk determines based on the second delivery instruction screen SCK that there is another delivery item other than the one received from the user, the store clerk picks up the delivery item from the sales floor or warehouse and then carries out the procedure for delivering the delivery item and the delivery item received from the user to the specified delivery address.

[0111] If the user decides to place the delivery item being picked up in the delivery basket, the user specifies the basket location by a predetermined operation such as tapping the button BUR on the selection screen SCI. When such an operation is notified from the user terminal 300, the processor 101 determines YES in ACT107 and proceeds to ACT111. As ACT111, the processor 101 instructs the user terminal 300 to display a basket scan screen. The basket scan screen is a screen for scanning the basket code of the delivery basket.

[0112] FIG. 25 is a diagram showing an example of the cart scan screen SCL. The cart scan screen SCL includes a display area ARC and a button BUS. The display area ARC is an area for displaying an image obtained by the camera 305. The button BUS is a soft key that allows the user to declare that scanning of the cart code is to be stopped.

[0113] When processor 301 of user terminal 300 displays cart scan screen SCL, it activates camera 305 and superimposes an image obtained by camera 305 within display area ARC. If the user performs any operation on cart scan screen SCL, processor 301 notifies transaction equipment 100 of the content of the operation, as described below.

[0114] Here, a store that provides a smartphone POS service using transaction processing system 1 designates a portion of the store as a delivery area for delivery items and places multiple delivery baskets in this delivery area. Instead of delivery baskets, any container such as a box or shelf may be used. The delivery area is assumed to be located near the checkout area where the checkout machine 200 is installed. Each delivery basket is assigned a basket number that allows store staff to distinguish between the multiple delivery baskets, and a basket code that serves as an identifier for each of the multiple delivery baskets. However, the basket number and basket code may be the same. The basket number is displayed on the delivery basket so that it can be seen by the store staff. A barcode representing the basket code is also displayed on the delivery basket. The user selects an empty delivery basket and places the picked-up items into it.

[0115] In transaction equipment 100, once processor 101 has finished issuing an instruction to display the basket scan screen in ACT111 in FIG. 13, the process proceeds to ACT112. In ACT112, the processor 101 waits for an operation to be performed on the user terminal 300. Then, for example, if the processor 101 receives notification of the operation content from the user terminal 300, the processor 101 determines YES and proceeds to ACT113. In ACT113, the processor 101 checks whether a scan has been performed. 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. For example, the processor 101 checks that an operation to specify that the scan has been stopped, such as tapping the button BUS, and returns to ACT104, returning the display screen of the touch panel 304 of the user terminal 300 to the selection screen SCI. A detailed description of the other processing will be omitted here.

[0116] When basket scan screen SCL is displayed on touch panel 304, the user points camera 305 at the delivery basket containing the item so that the barcode displayed on the basket is reflected in display area ARC. Processor 301 analyzes the image obtained by camera 305 and attempts to read the barcode. If processor 301 is successful in reading the barcode, it notifies transaction equipment 100 that the scan has been performed, along with a notification of the barcode data represented by the read barcode. Note that the user may place the delivery item in the delivery basket after reading the barcode.

[0117] In response to the notification sent from user terminal 300 in this manner, processor 101 in transaction equipment 100 determines YES in ACT 113 in FIG. 13 and proceeds to ACT 114. As ACT 114, processor 101 acquires the basket code represented by the notified barcode data. Thus, by processor 101 executing information processing based on transaction processing program PRA, the computer having processor 101 as its central part functions as an acquisition means.

[0118] As ACT115, processor 101 updates the transaction data relating to the transaction being processed to include the acquired basket code. Thus, by processor 101 executing information processing based on transaction processing program PRA, the computer having processor 101 as its central part functions as an association means.

[0119] In ACT116, processor 101 instructs attendant terminal 400 to display a third delivery instruction screen. The third delivery instruction screen is a screen that instructs delivery of delivery items, including delivery items placed in the delivery basket. If transaction processing system 1 includes multiple attendant terminals 400, processor 101 instructs an attendant terminal 400 that has been previously designated as a notification destination among these multiple attendant terminals 400 to display the third delivery instruction screen. Processor 101 then terminates the transaction processing. In addition to instructing display in ACT116, or without instructing display in ACT116, processor 101 may instruct display of the third delivery instruction screen as follows: That is, the store clerk causes attendant terminal 400 to scan the barcode displayed on the delivery basket in which the delivery items are placed. Processor 401 at attendant terminal 400 then requests transaction processing device 100 for a third delivery instruction screen, along with notification of the basket code represented by the scanned barcode. In response to this request, processor 101 at transaction processing device 100 instructs requesting attendant terminal 400 to display the third delivery instruction screen based on transaction data DAA including the notified basket code.

[0120] FIG. 27 is a diagram showing an example of the third delivery instruction screen SCM. The third delivery instruction screen SCM displays various information, such as character strings, to notify the store clerk of the delivery procedures that the store clerk should perform, as shown in Figure 27. The information displayed as character strings includes a basket number associated with the delivery basket identified by the basket code included in the transaction data DAA. In the example of Figure 27, "1001" is the basket number. The store clerk checks the delivery items in the delivery basket with the basket number displayed on the third delivery instruction screen SCM, and checks whether the delivery items displayed on the third delivery instruction screen SCM include any delivery items that are not in the delivery basket. If there are any such delivery items, the store clerk picks up the delivery items from the sales floor or warehouse, and then carries out procedures to deliver the delivery items and the delivery items in the delivery basket to the specified delivery destination.

[0121] As described above, transaction processing device 100 manages whether each transaction item in a transaction is a delivery item. Therefore, based on the management results, a store clerk can arrange for delivery of only the delivery items. This allows the user to leave the pickup of delivery items from the sales floor to the store clerk, and by only picking up items to take home from the sales floor, the user can save time and effort.

[0122] However, since there is a time lag between when a user registers a delivery item as a transaction item and when a store clerk arranges for delivery of the item, there is a risk that the item will be out of stock by the time the store clerk picks it up. However, if a product registered as a delivery item is low in stock, transaction equipment 100 recommends that the user pick up the product by displaying recommendation screen SCF on user terminal 300. By following this recommendation and promptly picking up the delivery item, the situation where the product is out of stock at the time of delivery arrangement can be prevented, and delivery arrangements for the delivery item can be made promptly.

[0123] If the user has not yet picked up any of the delivery items, transaction processing device 100 displays first delivery instruction screen SCH to notify the user that all delivery items are to be picked up by a store clerk, allowing the store clerk to easily recognize that each delivery item needs to be picked up from the storefront or warehouse.

[0124] When a user has picked up at least one delivery item, transaction equipment 100 can place the delivery item in a delivery basket and hand it over to a store clerk for delivery, meaning the user does not need to wait for a store clerk to handle the delivery.

[0125] When a user directly hands over a delivery item picked up by the user to a store clerk, transaction processing device 100 can easily inform the store clerk of the transaction to which the delivery item relates by having attendant terminal 400 scan the barcode displayed on user terminal 300.

[0126] Transaction processing device 100 then prompts the user to select which of the two methods to use for handing over the delivery item to a store clerk, thereby allowing the user to choose the method of their choice for handing over the delivery item.

[0127] This embodiment can be modified in various ways as follows. A part of the processing performed by processor 101 in transaction equipment 100 may be executed by processor 301 in user terminal 300. For example, transaction data may be stored in main memory unit 302 or auxiliary memory unit 303, and updated by processor 301. In this case, all or part of the determining means, deciding means, and registering means are realized by information processing by processor 301.

[0128] The store may be operated in a manner that does not require customers to pick up delivery items from the sales floor. In this case, if the processor 101 determines YES in ACT91 in FIG. 12, the process may proceed to ACT103 in FIG.

[0129] The delivery of the delivery item from the user to the store clerk may be either handing it over to the store clerk or putting it in the cart. If only handing it over to the store clerk is to be performed, the processor 101 may proceed to ACT 108 if it determines YES in ACT 101 in Fig. 13. If only putting it in the cart is to be performed, the processor 101 may proceed to ACT 111 if it determines YES in ACT 101.

[0130] The setting of whether or not to make an item a delivery item, or the setting of delivery conditions, may not be performed using the accounting device 200 as a user interface, or may be performed only using the accounting device 200 as a user interface. Some or all of the functions realized by the processors 101, 201, 301, and 401 through information processing can also be realized by hardware that executes information processing not based on a program, such as a logic circuit. Each of the above functions can also be realized by combining the above hardware, such as the logic circuit, with software control.

[0131] Although several 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 embodied 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 within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. The inventions described in the original claims of this application are set forth below. [Supplementary Note 1] A determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; A transaction processing system comprising: [Appendix 2] Accounting means for performing accounting for all commodities registered as commodities to be traded by the registration means for one transaction; a notification means for notifying a store clerk of products to be delivered among the products included in the transaction after the transaction is completed by the transaction means; 2. The transaction processing system of claim 1, further comprising: [Supplementary Note 3] A recommendation unit that recommends to the user to pick up the product from the sales floor when the product determined as the delivery target by the determination unit is in a predetermined stock shortage state; 2. A transaction processing system as described in claim 1, further comprising: [Supplementary Note 4] The determination means determines a delivery destination of the product to be delivered in response to an operation by the user on the terminal device, moreover, an acquisition means for acquiring, via the terminal device, an identifier of a container for containing the product to be delivered; an associating means for associating the identifier acquired by the acquiring means with the delivery destination determined by the determining means; 2. The transaction processing system of claim 1, further comprising: [Appendix 5] A determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; A transaction processing device comprising: [Appendix 6] The computer installed in the transaction processing device, a determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; An information processing program that makes it function as such. [Explanation of symbols]

[0132] 1...transaction processing system, 2...communication network, 100...transaction processing device, 200...accounting machine, 300...user terminal, 400...attendant terminal, 101,201,301,401...processor, 102,202,302,402...main memory unit, 103,203,303,403...auxiliary memory unit, 104,210...communication unit, 105,211,307,407...transmission path, 204,304,404...touch panel, 205...barcode scanner, 206...credit card reader, 207...near-field communication unit, 208...card reader / writer, 209...change unit, 305,405...camera, 306,406...mobile communication unit.

Claims

1. a determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; a receiving means for receiving a specification of a change in conditions of a registered product; a confirmation means for confirming whether the product for which the condition change has been specified by the acceptance means is a deliverable product; a display means for displaying a screen for accepting designation of not being eligible for delivery in response to confirmation by the confirmation means that the product is deliverable, and for displaying a screen for disabling designation of not being eligible for delivery in response to confirmation by the confirmation means that the product is not deliverable; A transaction processing system comprising:

2. accounting means for performing accounting for all commodities registered as commodities to be traded by the registration means for one transaction; a notification means for notifying a store clerk of products to be delivered among the products included in the transaction after the transaction is completed by the transaction means; The transaction processing system of claim 1 further comprising:

3. A determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; a recommendation unit that, when the product determined as the product to be delivered by the determination unit is in a predetermined stock shortage state, recommends the user to pick up the product from the sales floor; A transaction processing system comprising:

4. A determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device, and determining a delivery destination of the product to be delivered in response to an operation by the user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; an acquisition means for acquiring, via the terminal device, an identifier of a container for containing the product to be delivered; an associating means for associating the identifier acquired by the acquiring means with the delivery destination determined by the determining means; A transaction processing system comprising:

5. When the identifier is notified from the terminal device, the acquisition means acquires the identifier as the identifier of a container in which the product designated as the delivery target by the determination means is placed to be handed over from the user to a store clerk in response to an operation by the user on the terminal device that sent the notification.

5. The transaction processing system of claim 4.

6. a determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; a receiving means for receiving a specification of a change in conditions of a registered product; a confirmation means for confirming whether the product for which the condition change has been specified by the acceptance means is a deliverable product; a display means for displaying a screen for accepting designation of not being eligible for delivery in response to confirmation by the confirmation means that the product is deliverable, and for displaying a screen for disabling designation of not being eligible for delivery in response to confirmation by the confirmation means that the product is not deliverable; A transaction processing device comprising:

7. A computer installed in the transaction processing device, a determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; a receiving means for receiving a specification of a change in conditions of a registered product; a confirmation means for confirming whether the product for which the condition change has been specified by the acceptance means is a deliverable product; a display means for displaying a screen for accepting designation of not being eligible for delivery in response to confirmation by the confirmation means that the product is deliverable, and for displaying a screen for disabling designation of not being eligible for delivery in response to confirmation by the confirmation means that the product is not deliverable; An information processing program that makes it function as such.

8. A determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; a recommendation unit that, when the product determined as the product to be delivered by the determination unit is in a predetermined stock shortage state, recommends the user to pick up the product from the sales floor; A transaction processing device comprising:

9. A computer provided in a transaction processing device, a determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; a recommendation unit that, when the product determined as the product to be delivered by the determination unit is in a predetermined stock shortage state, recommends the user to pick up the product from the sales floor; An information processing program that makes it function as such.

10. A determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device, and determining a delivery destination of the product to be delivered in response to an operation by the user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; an acquisition means for acquiring, via the terminal device, an identifier of a container for containing the product to be delivered; an associating means for associating the identifier acquired by the acquiring means with the delivery destination determined by the determining means; A transaction processing device comprising:

11. A computer provided in a transaction processing device, a determination means for determining a product in response to an operation by a user on a terminal device; a determination means for determining whether or not each product determined by the determination means is to be delivered in response to an operation by a user on the terminal device, and determining a delivery destination of the product to be delivered in response to an operation by the user on the terminal device; a registration means for registering the product determined by the determination means as a product to be traded, in association with whether or not the product has been determined as a product to be delivered by the determination means; an acquisition means for acquiring, via the terminal device, an identifier of a container for containing the product to be delivered; an associating means for associating the identifier acquired by the acquiring means with the delivery destination determined by the determining means; An information processing program that makes it function as such.

Images