WO2020136847A1 - 情報処理装置、情報処理方法、支払いシステム及びプログラム - Google Patents

情報処理装置、情報処理方法、支払いシステム及びプログラム Download PDF

Info

Publication number
WO2020136847A1
WO2020136847A1 PCT/JP2018/048344 JP2018048344W WO2020136847A1 WO 2020136847 A1 WO2020136847 A1 WO 2020136847A1 JP 2018048344 W JP2018048344 W JP 2018048344W WO 2020136847 A1 WO2020136847 A1 WO 2020136847A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
payment
order
identification information
orderer
Prior art date
Application number
PCT/JP2018/048344
Other languages
English (en)
French (fr)
Inventor
晃一 中村
威 吉村
Original Assignee
楽天株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天株式会社 filed Critical 楽天株式会社
Priority to CN201880051403.5A priority Critical patent/CN111630554A/zh
Priority to JP2019519018A priority patent/JP6591123B1/ja
Priority to PCT/JP2018/048344 priority patent/WO2020136847A1/ja
Priority to US17/044,631 priority patent/US11704721B2/en
Priority to TW108135634A priority patent/TWI720635B/zh
Publication of WO2020136847A1 publication Critical patent/WO2020136847A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K15/00—Arrangements for producing a permanent visual presentation of the output data, e.g. computer output printers
    • G06K15/40—Details not directly involved in printing, e.g. machine management, management of the arrangement as a whole or of its constitutive parts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • the present invention relates to the technical field of an information processing device, an information processing method, a payment system, and a program that receives information regarding a user's order and performs various processes.
  • Patent Document 1 in view of such a problem, an order is made by causing a self-order terminal to read menu identification information (menu code) from a menu book, and an accounting code printed by the self-order terminal is displayed. It is described that the accounting is performed by causing the accounting device to read. Further, it is described that the queue for accounting can be dispersed by appropriately arranging the required number of devices for ordering or accounting in combination.
  • menu identification information menu code
  • an object of the present invention is to provide an environment in which an appropriate accounting process can be performed while reducing a work load on a store clerk involved in the accounting process.
  • An information processing apparatus includes an information acquisition unit that acquires order identification information that can specify an order by an orderer, a transmission unit that transmits the order identification information as payment information, and an identification of the order identification information.
  • an information acquisition unit that acquires order identification information that can specify an order by an orderer
  • a transmission unit that transmits the order identification information as payment information
  • an identification of the order identification information When a print control unit that executes a print process of a possible printed matter and an additional order by the orderer are accepted, the same orderer will not be able to pay for the order identification information of the unpaid order.
  • An invalidation instruction unit that issues an invalidation instruction to invalidate the identification information to another information processing apparatus. As a result, when there are a plurality of unpaid payment information by the same orderer, only the latest payment information is valid.
  • the order identification information may include orderer identification information for identifying an orderer. Since the order identification information includes the information that enables the orderer to be specified, it is possible to determine whether or not the order is placed by the same orderer only by analyzing the order identification information.
  • the orderer identification information may include information that can specify a store that has received an order. Since the information that can specify the customer also includes the information that can specify the store, the customer specifying information is different for each store.
  • the printing process in the above-described information processing device may be a process of printing code information capable of specifying the order identification information on the printed matter.
  • code information a generally popular one-dimensional barcode or two-dimensional barcode can be used.
  • the information processing apparatus described above may include a receiving unit that receives a notification indicating that the payment is completed from the other information processing apparatus as a payment completion notification. By receiving the payment completion notification, it is possible to determine whether or not the orderer has paid the price.
  • the payment information includes amount information as a payment amount for the order, and after receiving the payment completion notification about the order by the orderer, an additional order by the same orderer is received.
  • the transmitting unit may transmit, as the amount information, information on the total amount of additional orders that have been made after the receipt of the payment completion notification and have not been paid. That is, the notification that the amount related to the paid order is removed is sent to another information processing apparatus (for example, the payment management server).
  • Another information processing apparatus is a payment information receiving unit that receives order identification information that can specify an order made by an orderer as payment information, and a storage process that executes a storage process of the received payment information.
  • a payment request receiving section that receives a payment request including order identification information and payment information of the orderer from the orderer terminal used by the orderer, and performs payment processing for the payment information based on the payment request.
  • the same orderer accepts an invalidation instruction to invalidate the order identification information so that payment of the unpaid order identification information becomes impossible.
  • an invalidation processing unit that invalidates the stored payment information.
  • the other information processing device receives the payment information from the above information processing device and executes each process.
  • Another information processing apparatus includes a receiving unit that receives order identification information that can specify an order made by an orderer as payment information, and a print that executes print processing of a printed material that can specify the order identification information.
  • a receiving unit that receives order identification information that can specify an order made by an orderer as payment information
  • a print that executes print processing of a printed material that can specify the order identification information.
  • an invalidation process is performed to invalidate the order identification information so that the same orderer cannot pay the order identification information of the unpaid order. It may be provided with a nullification processing unit.
  • the payment system can specify the order identification information, an information acquisition unit that acquires order identification information that can specify an order made by an orderer, a transmission unit that transmits the order identification information as payment information, and the order identification information.
  • the order identification information is set so that the same orderer cannot pay the unpaid order identification information.
  • An invalidation instruction unit that issues an invalidation instruction to another information processing apparatus to another information processing apparatus, a payment information receiving unit that receives the payment information, and a storage process that executes a storage process of the received payment information.
  • a payment request receiving section that receives a payment request including the order identification information and the payment information of the orderer from the orderer terminal used by the orderer, and a payment process for payment information based on the payment request.
  • the payment processing unit performs the payment
  • the invalidation processing unit receives the invalidation instruction from the invalidation instruction unit and invalidates the stored payment information.
  • an information acquisition unit that acquires order identification information that can specify an order by an orderer, a transmission unit that transmits the order identification information as payment information, and a payment information reception unit that receives the payment information.
  • a storage processing unit that executes a storage process of the received payment information, a print control unit that executes a print process of a printed material that can specify the order identification information, and the same when an additional order by an orderer is accepted. From the orderer terminal used by the orderer, an invalidation processing unit that performs an invalidation process that invalidates the order identification information so that payment of the unpaid order identification information by the orderer becomes impossible.
  • a payment system comprising: a payment request receiving unit that receives a payment request including identification information and payment information of the orderer; and a payment processing unit that performs payment processing for payment information based on the payment request. Good.
  • An information processing method includes an information acquisition step of acquiring order identification information capable of specifying an order made by an orderer, a transmission step of transmitting the order identification information as payment information, and specification of the order identification information.
  • a print control step for executing a print process of a possible printed matter, and the order identification information so that payment of the unpaid order identification information by the same orderer becomes impossible when the additional order by the orderer is accepted.
  • the information processing apparatus executes an invalidation instruction step of performing an invalidation instruction for invalidating the other information processing apparatus. This makes it possible to provide an environment in which only the latest payment information is valid when there are a plurality of unpaid payment information by the same orderer.
  • the program according to the present invention relates to a procedure for reading order identification information capable of specifying an order from a printed matter and an order made after the payment information invalidated by the invalidation instruction and which has not been paid. And a procedure of transmitting a payment request including the payment information for making the payment and the read order identification information.
  • the orderer performs the accounting work to reduce the work load on the clerk involved in the accounting process, and when there is a plurality of unpaid payment information by the same orderer, the latest payment information. Appropriate accounting can be done because only the valid status is set.
  • a configuration example of a network system including the shop server 1 of the present embodiment will be described with reference to FIG. ⁇ 1.
  • System configuration> The store server 1 according to the present embodiment is connected to the communication network 2.
  • a payment management server 3, a user terminal 4, a card company system 5, an electronic money system 6 and the like are also connected to the communication network 2.
  • the respective devices and systems can communicate with each other via the communication network 2.
  • the configuration of the communication network 2 is assumed.
  • the Internet, intranet, extranet, LAN (Local Area Network), CATV (Community Antenna TeleVision) communication network, virtual private network (Virtual Private Network), telephone line network, mobile communication network, satellite communication network, etc. are assumed.
  • various examples of transmission media forming all or part of the communication network 2 are envisioned.
  • wired such as IEEE (Institute of Electrical and Electronics Engineers) 1394, USB (Universal Serial Bus), power line carrier, telephone line, infrared rays such as IrDA (Infrared Data Association), Bluetooth (registered trademark), 802.11 wireless It can also be used by radio such as mobile phone networks, satellite circuits, and terrestrial digital networks.
  • the store server 1 is an information processing device installed in a store such as a restaurant or a retail store.
  • the store server 1 performs a process of accepting an order from a visitor (orderer), a process of transmitting order details to the kitchen, a process of transmitting payment information to the payment management server 3, and the like.
  • an order terminal 7 as an input terminal capable of inputting an order made by an orderer is appropriately installed in the store.
  • the number of order terminals 7 is an appropriate number according to the size of the store.
  • the order terminal 7 may be, for example, a handy type carried by a clerk working in a store, or a table-installed type installed on a table where a visitor eats. Various information input by the order terminal 7 is transmitted to the store server 1.
  • the order terminal 7 can accept not only new orders but also additional orders.
  • the order terminal 7 only needs to be able to communicate with at least the store server 1. Further, communication from the order terminal 7 to the store server 1 may be enabled, and communication from the store server 1 to the order terminal 7 may be disabled.
  • the store server 1 performs various processes based on the information received from the order terminal 7. Further, the store server 1 that has received the additional order information from the order terminal 7 transmits the payment information regarding the additional order to the payment management server 3 and invalidates the payment information that has been transmitted by then. To the payment management server 3.
  • the store server 1 includes an order DB 51 in which the received order information is stored in order to execute each of the above processes. In the order DB 51, menu information, unit price information, total amount information of orders, and the like for each ordered single item are stored in association with the order identification information.
  • the payment management server 3 receives the payment information from the store server 1 and stores it in the storage unit. In addition, it accepts an invalidation instruction from the store server 1 and performs processing for invalidating the corresponding payment information.
  • the payment management server 3 includes a payment DB 61 in which the received payment information is stored. In the payment DB 61, order identification information and total amount information are associated and stored.
  • the user terminal 4 is an information processing terminal used by the orderer, and is capable of reading code information (for example, a one-dimensional bar code or a two-dimensional bar code). The reading of the code information may be realized by installing software in the user terminal 4. Further, the user terminal 4 can transmit a payment request to the payment management server 3 based on the read code information. At that time, a desired payment method may be designated from a plurality of prepared payment methods such as payment by credit card and payment by electronic money.
  • the user terminal 4 is, for example, a PC (Personal Computer), a feature phone, a PDA (Personal Digital Assistants) having a communication function, or a smart device such as a smartphone or a tablet terminal.
  • the card company system 5 receives various information necessary for making payment by credit card from the payment management server 3, and performs payment processing by the credit card. It is a system that does. For example, the process of determining whether the expiration date of the specified credit card is appropriate, the process of determining whether the specified credit card is not registered in the use prohibition list, or the usage amount does not exceed the limit amount. A process for determining whether or not it is performed. Further, when it is determined that the designated credit card can be used, processing such as securing a frame for the current usage amount is also performed.
  • the card company system 5 stores a database (Database, hereinafter referred to as “DB”) in which user information (information in which personal information such as a user's name and age is associated with card information) is stored, and authorization ( A DB for performing so-called authorization, a DB in which a credit card usage history is stored, and the like are appropriately provided.
  • DB database
  • a DB for performing so-called authorization, a DB in which a credit card usage history is stored, and the like are appropriately provided.
  • the respective DBs are not shown.
  • the electronic money system 6 receives various kinds of information necessary for making payment by electronic money from the payment management server 3 when the orderer (user) specifies payment by electronic money, and performs payment processing by electronic money. It is a system that does. Therefore, the electronic money system 6 stores a user information (information in which personal information such as a user's name and age is associated with account information for using electronic money) and a usage history of electronic money. A DB and the like for storing are appropriately provided. The respective DBs are not shown.
  • a plurality of card company systems 5 and electronic money systems 6 may be provided for each card brand (card company) and type of electronic money.
  • the functional configuration of the store server 1 will be described with reference to FIG.
  • the store server 1 includes an information acquisition unit 1a, a transmission unit 1b, a print control unit 1c, an invalidation instruction unit 1d, and a reception unit 1e.
  • the information acquisition unit 1a performs a process of acquiring order identification information that can specify an order made by the orderer.
  • the order identification information is information transmitted from the order terminal 7 to the store server 1. That is, the information acquisition unit 1a acquires the order identification information from the order terminal 7.
  • the order identification information is, for example, a store code that can specify a store, a table code that can specify a table in which the orderer is seated, a unique usage code given to an orderer who has visited the table and received a service, an order It consists of a date and time code indicating the time when the input was made.
  • the store code is “001”
  • the table code is “013”
  • the store visit code is “002” (a number sequentially assigned to the orderers who have passed through the table on that day)
  • the date and time code is When it is set to “20181122110341” (representing 11:03:41 on November 22, 2018), the order identification information is set to “001013002201811122110341”.
  • the orderer places an additional order, another order identification information having a different date/time code is added to the additional order.
  • this order identification information is merely an example, and it is possible to reduce the information amount (the number of bits) of the order identification information by using a code representing the number of orders instead of using the date and time code.
  • the ordering terminal 7 When the ordering terminal 7 is a terminal used by a store clerk, the ordering information is generated by the ordering terminal 7 by the table code, the visit code, etc. being input by the store clerk. Further, when the order terminal 7 is a desk-top type terminal and a terminal used by the orderer, the order terminal 7 may be configured to automatically generate the order identification information. For example, the order terminal 7 stores a store code and a table code in advance, and when the orderer makes a new order, "1" is added to the visit code used immediately before and a new visit is made. The code may be generated, the date and time information may be acquired at the time when the order is confirmed, and the date and time code may be generated, and the order identification information may be generated using the information.
  • the store server 1 may be provided with a conversion table and date/time information for generating the store code and the table code in advance.
  • the store server 1 identifies the order terminal 7 that has sent the order information, acquires the table code from the conversion table accordingly, gives the store code according to the store order, and receives the order information.
  • the date and time code may be generated from the date and time information, and the order identification information may be acquired by using each of these pieces of information and a store code that is stored in advance.
  • the order identification information is configured to be generated by the store server 1, the order terminal 7 does not need to execute the process of generating the order identification information, so that the processing load is reduced and an inexpensive terminal is used as the order terminal. 7 can be adopted.
  • the orderer identification information is provided with the table code and the store visit code, it can be said that the orderer identification information includes the orderer identification information for identifying the orderer. Further, since the orderer identification information includes the shop code, it is possible to handle the order identification information for each shop generated by the same algorithm in the same way. That is, even if the stores are different, the order identification information is not incurred, and therefore it is not necessary to introduce a different system for each store. As a result, the same system can be used in different stores, which can contribute to a reduction in system installation cost.
  • the transmission unit 1b performs a process of transmitting the information regarding the order received by the order terminal 7 to the payment management server 3. Specifically, the order identification information and the amount information are transmitted to the payment management server 3 as payment information.
  • the amount information may be the amount of money for each item, or the total amount of money when a plurality of items are ordered in one order.
  • the print control unit 1c executes a process for printing a printed matter, for example, a printed matter such as an accounting slip, each time an order is received.
  • the print control unit 1c in this example gives an instruction to print code information such as a one-dimensional barcode or a two-dimensional barcode on a printed matter.
  • the code information includes at least order identification information.
  • the printed matter on which the code information is printed is delivered to the orderer (user) every time it is printed.
  • the code information may include payment amount information regarding the order.
  • the code information printed on the printed matter is read by the user terminal 4 such as a mobile phone carried by the orderer.
  • the user terminal 4 that has read the code information sends a payment request to the payment management server 3. This allows the orderer to pay for the order he or she has placed.
  • the invalidation instruction unit 1d ensures that only the order identification information including the latest additional order becomes valid. A process for transmitting an instruction for invalidating the order identification information other than the above to the payment management server 3 is performed.
  • the receiving unit 1e performs a process of receiving various types of information such as a notification indicating that payment by the orderer has been completed.
  • the functional configuration of the payment management server 3 will be described with reference to FIG.
  • the payment management server 3 includes a payment information receiving unit 3a, a storage processing unit 3b, a payment request receiving unit 3c, a payment processing unit 3d, and an invalidation processing unit 3e.
  • the payment information receiving unit 3a receives the payment information from the store server 1 and extracts the order identification information and the amount information from the payment information.
  • the storage processing unit 3b performs processing for storing the extracted order identification information and amount information in the payment DB 61.
  • the payment request receiving unit 3c performs a process of receiving a payment request.
  • the payment request includes order identification information capable of specifying the payment data and payment information such as information for specifying the payment method.
  • the payment information includes, for example, information for identifying the payment method selected by the orderer from a plurality of types of payment methods.
  • the payment information may include information such as a credit card number and a security code, or may include only key information (for example, user ID (Identification)) for obtaining such information. Good.
  • the payment processing unit 3d performs a process of transmitting necessary information for payment to the card company system 5 or the electronic money system 6 based on the payment method specified by the orderer, and information indicating that the payment is completed. Is received.
  • the invalidation processing unit 3e performs processing for invalidating predetermined payment information based on the invalidation instruction received from the store server 1.
  • the corresponding record may be erased, or the flag attached to the corresponding record may be rewritten from the valid state to the invalid state.
  • Hardware configuration> Information such as the store server 1, the payment management server 3, the user terminal 4, various computer devices and terminals that configure the card company system 5 and the electronic money system 6, the order DB 51, and the payment DB 61 shown in FIG. It can be realized as a computer device capable of processing and information communication as shown in FIG.
  • a CPU (Central Processing Unit) 101 of a computer device is operated in accordance with a program stored in a ROM (Read Only Memory) 102 or a program loaded from a storage unit 108 into a RAM (Random Access Memory) 103. Execute the process.
  • the RAM 103 also appropriately stores data necessary for the CPU 101 to execute various processes.
  • the CPU 101, the ROM 102, and the RAM 103 are connected to each other via a bus 104.
  • An input/output interface 105 is also connected to the bus 104.
  • An input unit 106, an output unit 107, a storage unit 108, and a communication unit 109 are connected to the input/output interface 105.
  • the input unit 106 includes a keyboard, a mouse, a touch panel, and the like.
  • the user terminal 4 in the present embodiment is provided with a configuration for acquiring (imaging) code information as an input unit 106.
  • the output unit 107 is configured by a display including an LCD (Liquid Crystal Display), a CRT (Cathode Ray Tube), an organic EL (Electroluminescence) panel, and a speaker.
  • the storage unit 108 includes an HDD (Hard Disk Drive), a flash memory device, and the like.
  • the communication unit 109 performs communication processing and communication between devices via the network 1.
  • a media drive 110 is also connected to the input/output interface 105 as needed, and a removable medium 111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately mounted, and information can be written to the removable medium 111. Reading is performed.
  • a removable medium 111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately mounted, and information can be written to the removable medium 111. Reading is performed.
  • the CPU 101 performs processing operations based on various programs, so that the store server 1, the payment management server 3, the user terminal 4, various computer devices and terminals configuring the card company system 5 and the electronic money system 6, the order DB 51, Information processing and communication required as the payment DB 61 are executed. It should be noted that the store server 1, the payment management server 3, the user terminal 4, the various computer devices and terminals forming the card company system 5 and the electronic money system 6, the information processing device forming the order DB 51, and the payment DB 61 are shown in FIG.
  • the computer device as described above is not limited to a single computer device, and a plurality of computer devices may be systematically configured.
  • the plurality of computer devices may be systematized by a LAN or the like, or may be arranged at a remote place by a VPN or the like using the Internet or the like.
  • the plurality of information processing devices may include an information processing device as a server group (cloud) that can be used by a cloud computing service.
  • Each function as the store server 1 shown in FIG. 2 and each function as the payment management server 3 shown in FIG. 3 are functions realized by the processing executed by the CPU 101 in the information processing apparatus according to a program. However, the processing of all or part of each configuration described below may be realized by hardware. Further, when each function is realized by software, each function does not need to be realized by an independent program. Processing of a plurality of functions may be executed by one program, or one function may be realized by cooperation of a plurality of program modules. Further, each function may be distributed to a plurality of information processing devices. Further, one of the functions may be realized by a plurality of information processing devices.
  • the order DB 51 included in the store server 1 and the payment DB 61 included in the payment management server 3 may be implemented in any form as long as the store server 1 and the payment management server 3 are accessible.
  • all of the order DB 51 may be formed in the storage unit in the same system as the store server 1, or part or all of the order DB 51 may be provided separately or in a computer system such as a remote place.
  • the order DB 51 does not have to be formed in one device (for example, one HDD or the like). Further, the order DB 51 does not need to be configured as one DB.
  • Each DB described in each of the following examples is merely an example of the storage unit of information related to the processing of the embodiment in the form of one DB.
  • the store clerk inputs information for generating order identification information to the handy-type ordering terminal 7 he owns. For example, a button (new button) indicating reception of a new visitor is pressed, and then the table number (or the seat number of the counter) on which the visitor is sitting is input.
  • the order terminal 7 may also be used to input the number of visitors.
  • the order terminal 7 inputs information for generating order identification information in step S101.
  • the store clerk asks the visitor about the order and inputs the information into the order terminal 7.
  • the order terminal 7 inputs order information in step S102.
  • the order information is input by, for example, inputting a number for specifying the menu or pressing a button for specifying the menu.
  • a visitor who has made an order is referred to as an “orderer”.
  • the order information includes information for generating order identification information and information for specifying the menu ordered by the orderer.
  • information for generating the order identification information for example, information for specifying a new order or an additional order and a table number are transmitted. Further, instead of the information for generating the order identification information, the order identification information may be generated and transmitted.
  • Information such as order information transmitted in the process of step S103 is received by the store server 1 in the process of step S201.
  • a process of storing the received information in the order DB 51 and a process of generating order identification information are executed.
  • the store server 1 performs a process of acquiring the order identification information and the amount information in step S202.
  • the amount information acquired here is the total amount of the order made by the orderer.
  • the order identification information for example, when the store code is “001”, the table code is “013”, and the store visit code is “002”, the first order identification information is “001013002001”. There is.
  • This order identification information includes orderer identification information (that is, "001013002").
  • the orderer identification information is different from other orderers, and is information that can specify one orderer (or one group of orderers).
  • the store server 1 performs a process of transmitting the order identification information and the amount information to the payment management server 3 as payment information in step S203.
  • the store server 1 performs a process of printing the accounting slip in step S204.
  • a two-dimensional bar code is printed on the accounting slip printed by the interview slip printing process.
  • the two-dimensional bar code includes order identification information, and based on this information, it is possible to specify the total amount of orders placed by the orderer.
  • the print processing of step S204 may be executed by the store server 1 receiving the print instruction transmitted from the payment management server 3.
  • the order identification information and the amount information (that is, “payment information”) transmitted in the process of step S203 are received by the payment management server 3 in the process of step S301.
  • the payment management server 3 performs a process of associating the order identification information with the amount information and storing them in the payment DB 61.
  • the salesclerk inputs additional order information in step S105. Specifically, a number is input to specify the menu and a button is pressed to specify the menu.
  • the order terminal 7 performs a process of transmitting order information and the like in step S106. This process is similar to step S103 in FIG.
  • the information regarding the additional order transmitted in the process of step S106 is received by the store server 1 in the process of step S205.
  • a process of storing the received information in the order DB 51 and a process of generating order identification information are executed.
  • the order identification information generated here (or the order identification information generated by the order terminal 7) is different from the order identification information for specifying the first order content. For example, when the store code is “001”, the table code is “013”, and the store visit code is “002”, the first order identification information for the first order is “001013002001”, The order identification information of the additional order, which is the second order, is set to “001013002002”.
  • the store server 1 acquires the order identification information and the amount information in step S206.
  • the amount information acquired here is the total amount of unpaid orders among a plurality of orders made by the same orderer. For example, if the initial order amount is 1000 yen, the additional order is 500 yen, and both the initial order and the additional order are unpaid, the amount information acquired in step S206 is 1500 yen.
  • step S207 the store server 1 performs a process of transmitting the order identification information (“001013002002” in the previous example) and the amount information (“1500” in the previous example) as payment information.
  • step S207 The payment information transmitted in step S207 is received by the payment management server 3 in step S303.
  • step S304 the payment management server 3 stores the received payment information in the payment DB 61.
  • Each process of step S303 and step S304 is the same process as each process of step S301 and step S302 shown in FIG.
  • the store server 1 that has completed the processing in step S207 transmits an invalidation instruction in step S208.
  • This process may be executed immediately after the process of step S207 without confirming whether the processes of steps S303 and S304 executed by the payment management server 3 are completed. That is, the process of step S208 may be executed before the process of step S303 is executed.
  • the payment information that is the target of the invalidation instruction performed in step S208 is an order that was placed by the same orderer before this additional order and is an unpaid order, and is invalidated by the invalidation instruction. It is related to the unordered orders. That is, if the same orderer has not placed an order prior to the current order, or if all orders placed prior to the current order have been paid, the process of step S208 is not executed. .. For example, in the processing related to the order shown in FIG. 5, since the order placed by the orderer is the first order, the order corresponding to step S208 in FIG. 6 is executed because the order has not been placed before the current order. Absent.
  • the payment information that is the target of the invalidation instruction in step S208 is the information whose order identification information is "001013002001".
  • the “same orderer” here does not include cases where the same person is accepted as a different visitor. That is, when a customer who came to the store the other day comes to the store as a new customer later, the customer is not treated as the same orderer.
  • the payment management server 3 that has received the invalidation instruction executes the invalidation process in step S305.
  • the invalidation process is a process of invalidating the record having the target order identification information so that the orderer is excluded from the target when making a payment. Invalidation of a record is performed, for example, by updating a flag from a state indicating valid to a state indicating invalid.
  • step S209 After issuing the invalidation instruction, the store server 1 executes a process of printing an accounting slip in step S209.
  • the process of step S209 can be performed asynchronously with the process of step S305 executed by the payment management server 3.
  • step S503 the user terminal 4 executes a process of specifying the payment method selected (designated) by the user (orderer). This process is realized, for example, by displaying a plurality of payment methods on the screen and allowing the user to select from among them.
  • the user terminal 4 executes the payment request transmission process in step S504.
  • information including the order identification information and the selected payment method is transmitted as a payment request.
  • the payment amount may be transmitted in addition to the order identification information and the information capable of specifying the payment method. In that case, the user terminal 4 can acquire the payment amount by reading the code information.
  • step S503 and step S504 will be described with an example.
  • dedicated application software for making payment using code information (for example, a two-dimensional bar code) printed on an accounting slip or the like is installed.
  • the terminal application can perform various operations as a registered member (that is, various operations while logged in) by inputting a user ID and a password.
  • Information on the user ID and password is registered in the DB managed by the payment management server 3.
  • the DB also stores credit card information, point information, and the like for each user ID.
  • step S504 Since the credit card information and the point information are stored in the DB managed by the payment management server 3, the orderer does not have to input the credit card information each time the user makes a payment if he is logged in. Accordingly, in the process of step S504, for example, only the user ID for identifying the user, the information indicating that the payment by the credit card is selected, and the order identification information are transmitted. Therefore, since the credit card information is not transmitted/received, the personal information can be protected. In addition, it is possible to avoid the risk that the input of credit card information is stolen.
  • step S503 payment using points can be selected. For example, it is possible to pay a predetermined amount of money with points and pay the remaining amount of money with a credit card.
  • the order identification information acquisition process may be performed by a terminal different from the user terminal 4 (for example, the payment management server 3) by directly transmitting the read image data of the two-dimensional barcode in step S504.
  • the payment management server 3 performs the payment request reception processing in step S306.
  • the user ID is specified from the received information, and the selected payment method is specified.
  • a process of acquiring point information and credit card information associated with the user ID is performed as necessary.
  • the payment management server 3 executes a payment process in step S307.
  • FIG. 7 shows a case where at least a part of the order amount is paid by a credit card.
  • the payment management server 3 transmits an approval request by transmitting various information to the card company system 5 in step S307.
  • the various information transmitted here is, for example, the amount of money to be paid by a credit card, credit card information, and the like.
  • the card company system 5 that has received the approval request executes the approval process in step S401.
  • the approval process for example, a process of checking the expiration date of the credit card, a process of confirming the validity of the credit card (whether it is not registered in the use prohibition list), a process of confirming the available amount of the credit card, etc. are executed.
  • the card company system 5 performs the process of notifying the approval result in step S402.
  • the result of the approval process is either “approved” or “non-approved”. If the approval result is “approval”, the payment management server 3 executes the payment completion notification process in step S308.
  • the payment completion notification process is performed on the store server 1 and the user terminal 4.
  • the store server 1 updates the payment completed order information among the order information stored in the order DB 51 as the payment completion notification receiving process in step S210.
  • this update process for example, a process of storing a flag indicating that payment has been completed is performed.
  • the user terminal 4 that has received the payment completion notification in step S308 executes the payment completion display processing in step S505.
  • a notification such as “payment is completed” is displayed on the screen of the user terminal 4.
  • step S401 when the result of the approval process in step S401 is “non-approval”, the process in subsequent step S308 is not executed, and instead the payment cannot be completed from the payment management server 3 to the store server 1 or the user terminal 4.
  • the payment management server 3 may not notify the store server 1 that the payment cannot be completed.
  • steps S401 and S402 When the orderer selects to use electronic money as the payment method, another process that replaces the processes of steps S401 and S402 is executed by the electronic money system that manages electronic money. Specifically, for example, a process of determining whether or not the user ID is valid, a process of determining whether or not the points balance is sufficient, a process of subtracting the payment amount from the points, and the like in steps S401 and S402. Execute instead of the process.
  • the order terminal 7 performs the additional order by performing the information input processing for order identification information generation in step S104, the additional order information input processing in step S105, and the order information transmission processing in step S106 based on the operation of the clerk or the like. Is received and transmitted to the store server 1. Since there are no unpaid orders up to that time, it may be processed as a new customer as shown in FIG. In that case, for example, order identification information including new orderer identification information may be generated. For example, the store code is "001", the table code is "013", the store visit code is "003", and "001013003001" to which "001" indicating the first order is added is newly added. It may be the order identification information.
  • the store server 1 executes the process of receiving the order information and the like in step S205, the process of acquiring the order identification information and the amount information in step S206, and the process of transmitting the order identification information and the amount information in step S207.
  • the amount information transmitted to the payment management server 3 in step S207 is the total amount of all additional orders made after the payment is once completed.
  • the store server 1 that has executed the process of step S207 executes the invalidation instruction process of step S208. However, since there is no unpaid payment information to be invalidated, the process may proceed to step S209 without executing the process of step S208.
  • the payment management server 3 executes the processing for receiving the order identification information and the amount information in step S303, the storage processing in step S304, and then the invalidation processing in step S305.
  • the shop server 1 does not execute the process of step S208, the invalidation instruction cannot be received, and thus the process of step S305 is not executed.
  • the record to be invalidated is deleted from each record stored in the payment DB 61. A process of searching and confirming that the target record has been paid (or a process of confirming that the target record does not exist) is executed.
  • the user terminal 4 executes the code information reading operation acceptance process of step S501, the reading process of step S502, the payment method selection process of step S503, and the payment request transmission process of step S504 according to the operation of the orderer. As a result, the payment request is transmitted to the payment management server 3.
  • the amount information transmitted to the card company system 5 at this time is the total amount relating to the additional order made after the previous payment is completed. For example, suppose that a menu for 1000 yen is ordered in the first order, an additional menu for 500 yen is ordered, and then 1500 yen is paid by the payment process. After that, when an additional order of 300 yen is ordered, the amount information transmitted to the card company system 5 in the payment process of step S307 is 300 yen.
  • the card company system 5 performs the approval process of step S401 and the approval result notification process of step S402. As a result, the payment management server 3 is notified of the approval result.
  • the payment management server 3 executes the payment completion notification process in step S308.
  • the user terminal 4 executes the payment completion display processing (step S505), and the store server 1 executes the payment completion notification receiving processing (step S210).
  • step S210 when an additional order is placed by the same orderer after completing the payment, only the order information of the additional order is stored in the order DB 51 as unpaid order information. This makes it possible to clearly distinguish the paid order information from the paid order information, and prevents payment of the paid order information from being made again.
  • an exchange (ACK or the like) for confirmation of reception may be executed every time information is transmitted/received. Omitted.
  • the store server 1 determines whether or not the order information is received from the order terminal 7 in step S601. If the order information has not been received, the store server 1 executes step S601 again. Note that the store server 1 may be configured such that each process after step S602 is executed by using the reception of the order information as a trigger.
  • the store server 1 acquires the table code from the received order information in step S602. In step S603, the store server 1 determines whether the received order information relates to a new order. Information on whether or not it is a new order can be acquired from the order information received from the order terminal 7.
  • step S604 If it is a new order, the store server 1 does not execute the processes of step S604 and step S605, and proceeds to the process of step S606. On the other hand, if it is not a new order, that is, if it is an additional order, the store server 1 performs a process of acquiring the previous order information from the order DB 51 in step S604.
  • the information stored in the order DB 51 is the order information already received, excluding the order information received from the order terminal 7 this time.
  • the order information received this time is stored in the order DB 51 by the process of step S610 described later. Therefore, the previous order information is the order placed by the orderer this time, and is the information about the newest order stored in the order DB 51. For example, if the current order is the second order since the store came, the order information stored in the order DB 51 at this time is only the information about the first order, and thus the processing of step S604 is performed. , Get the order information for the first order.
  • step S604 a search process based on the orderer identification information is performed. Specifically, the record including the store code “001”, the table code “013”, and the store visit code “002”, that is, the record including the orderer identification information indicating the orderer who placed the order this time is searched.
  • the store code is information managed by the store server 1.
  • the table code and the store visit code are included in the order information received from the order terminal 7.
  • FIG. 9A shows a part of an example of information stored in the order DB 51 managed by the shop server 1.
  • Record No. that can identify one record.
  • a store code, a table code, a store visit code, the number of orders, the order content, the total amount of money, and a paid flag are stored for each.
  • the store code, table code, and visit code are as described above.
  • the number of orders is set to 001 for the first time, and is incremented by 1 each time an additional order is received.
  • the order contents are the menu No. And a plurality of sets of information in which the number of ordered pieces is one set are stored.
  • the record shown in FIG. The menu No. is "019" and the menu is "031". Indicates that an order including two menus labeled “024” has been accepted.
  • the orderer identification information includes three pieces of information including a store code, a table code, and a store visit code. That is, the orderer can be uniquely identified by the store code, the table code, and the store visit code. Further, the order identification information is configured to include information on the number of orders in addition to the store code, the table code, and the store visit code. That is, the order information can be uniquely specified by the store code, the table code, the store visit code, and the number of orders.
  • step S604 of the orders placed by the identifiable orderer with the store code “001”, the table code “013”, and the store visit code “002”, that is, the order number is the largest.
  • the item is acquired from the order DB 51. Therefore, for example, as the previous order information, the record number whose order count is "001" is set. The record of "000001" is acquired.
  • the shop server 1 acquires the number of orders in step S605.
  • “001” is acquired.
  • the store server 1 performs a process of generating order identification information about the current order information. Specifically, the store code, the table code, and the store visit code are used as they are, and the number of orders is calculated as "002" by adding 1 to the obtained value. Since the current order is a new order, if the processing of step S606 is executed without performing the processing of steps S604 and S605, the number of orders for this order is set to "001".
  • the store server 1 generates order identification information in step S606.
  • the order identification information is, for example, information generated from a store code, a table code, a store visit code, and the number of orders, and is information that can uniquely identify an order made by the orderer. As can be understood from FIG. 9A, a plurality of order identification information may be associated with one orderer identification information.
  • step S607 the store server 1 acquires unit price information for each menu for which an order has been accepted.
  • Unit price information will be described with reference to FIG. 9B.
  • the unit price information is stored in the DB that stores the unit price of each product (menu) sold by the store.
  • This DB is managed by the store server 1.
  • FIG. 9B shows an example of the information stored in the DB.
  • the menu No. that can uniquely identify the menu Unit price information is associated with each item and stored.
  • the unit price information acquired in step S607 is the menu No. included in the order information received from the order terminal 7. Only the unit price information about. Taking the previous order (order information in which the record No. in FIG. 9A is “000001”) as an example, the menu No. At least unit price information of the menus for which "024", "031", and "019" are acquired.
  • the store server 1 acquires the number of orders from the order information in step S608. Taking the previous order as an example, the menu No. 2 for the menu with “024” as the menu No. 1 for the menu with “031” as the menu No. For the menu for which "019" is set, 1 is acquired as the number of orders.
  • the store server 1 calculates the total order amount in step S609.
  • the total order amount can be calculated from the unit price information acquired in step S607 and the number of orders acquired in step S608.
  • step S610 the store server 1 stores the current order information in the order DB 51.
  • the record number. Is "000002", the store code is "001”, the table code is “013”, the store visit code is "002”, the number of orders is "002”, and the information received from the ordering terminal 7 is stored in the order details, and the step
  • the total order amount calculated in S609 is stored in the total amount, and the record with the paid flag set to “False” is stored in the order DB 51.
  • the paid flag is changed to "True” when the order is paid. Therefore, “False” is set when new order information is stored in the order DB 51.
  • the store server 1 performs a process of transmitting payment information to the payment management server 3 in step S611.
  • information including at least the order identification information and the total amount of unpaid orders is transmitted to the payment management server 3.
  • the total amount of unpaid orders may be the sum of the total amounts of order information.
  • the total amount of unpaid order information about an orderer who can be identified by the store code “001”, the table code “013”, and the store visit code “002” is the previous order information (the first order information and the record No. "2,900 yen” is the sum of the total amount of money (that is, "2,460 yen") and the total amount of the order information newly stored in step S610 (for example, "500 yen”). It is said that.
  • the total amount of unpaid order information is summed, and the amount of paid records is excluded.
  • the store server 1 determines in step S612 whether or not the current order is a new order. This determination process is the same as the determination process of step S603.
  • step S613 If the current order is a new order, the store server 1 does not execute the process of step S613 and proceeds to the process of step S614. On the other hand, if the current order is not a new order, that is, an additional order, the store server 1 executes the process of step S613.
  • step S613 processing for transmitting an invalidation instruction to the payment management server 3 is performed.
  • the transmission of the invalidation instruction at least information that can identify the payment information to be invalidated is transmitted.
  • the information that can specify the payment information to be invalidated is, for example, order identification information or orderer identification information. In this example, "001013002001" is transmitted as the order identification information to be invalidated.
  • step S613 After executing step S613, or after determining that the current order is a new order in step S612, the store server 1 performs processing of instructing printing of the accounting slip in step S614. As a result, the accounting slip is printed. In addition, as described above, the code information capable of specifying the order identification information is printed on the accounting slip. After executing step S614, the shop server 1 returns to the process of step S601 again.
  • the payment management server 3 performs a process of determining whether or not the payment information is received from the store server in step S701. When it is determined that the payment has not been received, the payment management server 3 performs the process of step S701 again.
  • the payment management server 3 may be configured such that the reception of the payment information is a trigger to execute the processes of steps S702 and S703.
  • the payment management server 3 which has determined that the payment information has been received, acquires the order identification information and the amount information from the received information in step S702. Next, in step S703, the payment management server 3 performs a process of associating the acquired order identification information with the amount information and storing the information in the payment DB 61.
  • the payment information stored in the payment DB 61 is the record number that can uniquely identify one record. Is associated with the order identification information, the amount information, the valid flag, and the paid flag.
  • the order identification information is, for example, information generated from the store code “001”, the table code “013”, the store visit code “002”, and the order count “001”, and is given each time the orderer places an order. Is.
  • the amount information indicates the total amount to be paid when the orderer pays. That is, it may be the total sum of the order information for a plurality of times.
  • the valid flag is a flag indicating whether the payment for the record is valid or invalid. In the state shown in FIG. 11, the valid flag is set to “True”, and payment for the record can be made.
  • the payment information related to the order information is received from the store server 1, and a new information is added in step S703.
  • the order identification information is set to “001013002002”
  • the amount information is set to “2960”
  • the valid flag is set to “True”
  • the paid flag is set to “False”.
  • the record number When the information is stored in the payment DB 61, the record number. The valid flags of both the record for which "001" and the record for which "002" are set to “True” are both set.
  • step S703 After executing step S703, the payment management server 3 returns to the process of step S701 again.
  • step S305 in FIG. 6 can be realized by executing the series of processing shown in FIG.
  • step S711 the payment management server 3 determines whether the invalidation instruction is received from the store server 3. If the invalidation instruction has not been received, the payment management server 3 executes the process of step S711 again.
  • the payment management server 3 may be configured such that the reception of the invalidation instruction is used as a trigger to execute the processes of steps S712 and S713.
  • the payment management server 3 When it is determined that the invalidation instruction has been received, the payment management server 3 performs a process of acquiring order identification information for specifying the payment information to be invalidated from the received information in step S712. For example, “001013002001” is acquired as the order identification information.
  • step S713 the payment management server 3 changes the valid flag of the payment information related to the designated order identification information to “False”.
  • This processing is synonymous with turning the invalidation flag “ON”.
  • the record number At the time when the record having “002” is stored, the record number.
  • the record No. is determined by executing the process of step S713.
  • step S713 the payment management server 3 returns to the process of step S711.
  • Terminal application startup process An example of the terminal application starting process executed by the user terminal 4 will be described with reference to FIG. Note that the series of processes illustrated in FIG. 13 is a process executed by the user terminal 4 in response to the user performing an operation of activating a dedicated terminal application for making a payment in the user terminal 4 used by the user. is there. When the user terminal 4 executes the series of processes shown in FIG. 13, each process of steps S501 to S505 of FIG. 7 can be realized.
  • the user terminal 4 that has detected the activation operation of the terminal application determines whether or not it is in the login state in step S801. If not logged in, the user terminal 4 issues a login request to the user in step S802. Specifically, a user ID input field for logging in, a login password input field, and a login button for starting the execution of the authentication process are displayed on the screen.
  • the user terminal 4 executes login authentication processing in step S803. Specifically, the input user ID and password are encrypted and transmitted to the payment management server 3, the authentication process is executed, and the authentication result is received and displayed. When the authentication result is “impossible”, the user terminal 4 makes the login request of step S802 again.
  • step S804 After executing the login authentication process, the user terminal 4 determines in step S804 whether a read operation instruction has been accepted. It waits in step S804 until a reading operation instruction is given.
  • the user terminal 4 When the user performs an operation for instructing a reading operation, the user terminal 4 performs a process of activating a camera included in the user terminal 4 in step S805. Subsequently, the user terminal 4 reads the code information in step S806 according to the user's camera operation.
  • the code information includes at least the order identification information, as described above.
  • the user terminal 4 performs a process of presenting a payment method selection screen in step S807. For example, the user terminal 4 performs a process of displaying a plurality of selectable payment methods on the screen and displaying a message prompting the user to make a selection.
  • the user terminal 4 executes a process of accepting a payment method selection operation in step S808, and executes a process of transmitting a payment request to the payment management server 3 in step S809.
  • the payment request transmits, for example, information for specifying the user to be used such as a user ID, code information including the order identification information read in step S806, and information for specifying the payment method selected by the user. Processing.
  • the user terminal 4 determines in step S810 whether or not the notification for the payment request is received.
  • the notification to the payment request is, for example, a “payment completion notification” indicating that the payment is completed or a “payment failure notification” indicating that the payment cannot be made for some reason.
  • the user terminal 4 executes the processing of displaying the payment completion display on the screen of the user terminal 4 as the processing of displaying the notification content in step S811.
  • the user terminal 4 waits in the process of step S810 until the notification of the payment request is received.
  • step S810 when the payment incapability notification is received in step S810, the user terminal 4 executes the processing of displaying the payment incapability display on the screen as the notification content display processing in step S811.
  • the payment management server 3 determines whether a payment request is received from the user terminal 4 in step S721. If the payment request has not been received, the payment management server 3 executes the process of step S721 again. Note that the payment management server 3 may be configured such that the reception of the payment request is used as a trigger to execute the processes of steps S722 to S727.
  • the payment management server 3 which has determined that the payment request has been received, executes the process of acquiring the user ID in step S722. Then, the payment management server 3 performs the process which specifies a payment method in step S723. In this process, the information for identifying the payment method is acquired from the information received as the payment request.
  • step S724 the payment management server 3 performs a process of acquiring information according to the payment method from the DB.
  • the example shown in FIG. 14 illustrates a case where the user selects payment by credit card. Therefore, in step S724, the information regarding the credit card is acquired from the DB. If the payment method uses points, the point information is acquired from the DB. If the payment method uses electronic money, information regarding electronic money is acquired from the DB.
  • the payment management server 3 acquires usage amount information in step S725.
  • This process is a process of acquiring the order identification information from the information received as the payment request and acquiring the amount information (see FIG. 11) from the payment DB 61 based on the order identification information.
  • step S726 the payment management server 3 requests the card company system 5 to secure a frame for the usage amount.
  • the card company system 5 confirms the expiration date of the designated credit card and the availability of the credit card.
  • step S727 the payment management server 3 waits until it receives the frame reservation result.
  • the payment management server 3 transmits a payment completion notification or a payment failure notification in step S728.
  • the payment completion notification or the payment failure notification is transmitted to the user terminal 4 and the store server 1.
  • the store server 1 changes the paid flag of the target record stored in the order DB 51 from “False” to “True” by receiving the payment completion notification (see FIG. 9A).
  • the payment management server 3 may execute a process of acquiring information about electronic money (for example, the balance) from the DB managed by the electronic money system 6.
  • the electronic money system 6 may be requested to acquire information about electronic money together with a predetermined process related to payment by electronic money.
  • information regarding login may be transmitted and received between the user terminal 4 and the electronic money system 6.
  • the payment management server 3 executes a process of giving a print instruction to the above-described embodiment (hereinafter, referred to as “first embodiment”), and invalidation.
  • first embodiment a print instruction to the above-described embodiment
  • second embodiment invalidation.
  • the store server 1 does not execute the instruction.
  • the store server 1A according to the second embodiment includes an information acquisition unit 1a, a transmission unit 1b, a print control unit 1c, and a reception unit 1e. That is, as compared with the store server 1 of the first embodiment, the feature is that the invalidation instruction unit 1d is not provided.
  • the payment management server 3A includes a payment information receiving unit 3a, a storage processing unit 3b, a payment request receiving unit 3c, a payment processing unit 3d, an invalidation processing unit 3e, and The print instruction unit 3f is provided. That is, as compared with the payment management server 3 of the first embodiment, the print instruction unit 3f is provided.
  • the payment management server 3A transmits a print request to the store server 1A, or the payment management server 3A transmits a print request to a printing device managed in the store. Done by.
  • the process of invalidating the payment information is performed after the management server 3A that has received the new payment information identifies the old payment information that is not subject to the payment. This process can be executed without receiving the invalidation instruction from the store server 1A.
  • the store server 1A that has received the order information and the like acquires the order identification information and the payment amount information for the order in step S202, and transmits the order identification information and the amount information in step S203.
  • the payment management server 3A Upon receiving the order identification information and the amount information (step S301), the payment management server 3A executes a process of transmitting a print instruction to the store server 1A in step S309, and then stores the order identification information and the amount information in step S302. To do.
  • the store server 1A Upon receiving the print instruction, the store server 1A executes the accounting slip printing process in step S211.
  • This process is, for example, a process in which the store server 1A transmits a print instruction to a printing device. That is, unlike the first embodiment, the store server 1A executes the print processing of the accounting slip by receiving the print instruction from the payment management server 3A.
  • step S309 any of the processing in step S309 and the processing in step S302 may be executed first. Further, in the process of step S309, the payment management server 3A may realize the printing of the accounting slip by transmitting a print instruction to an information processing device other than the store server 1A belonging to the network managed by the store.
  • the store server 1A Upon receiving the order information and the like (step S205), the store server 1A acquires the order identification information and the payment amount information for the order in step S206, and transmits the order identification information and the amount information in step S207.
  • the payment management server 3A that has received the order identification information and the amount information executes the process of transmitting the print instruction to the store server 1A in step S310, and then stores the order identification information and the amount information in step S304. To do.
  • the store server 1A that has received the print instruction executes the print processing of the accounting slip in step S212.
  • the payment management server 3A executes the invalidation process in step S311.
  • the invalidation process is, for example, a process using the order identification information.
  • the same orderer searches the payment DB 61 for orders placed before that time, and performs processing to invalidate the corresponding record. That is, among the records stored in the payment DB 61, the record having the same orderer identification information as the orderer identification information included in the order information received in step S205, in other words, the same store code and the same table code.
  • the record having the orderer identification information having the same store visit code as is specified as the invalidation target.
  • the payment management server 3A executes a process of setting "False" to the valid flag of the specified target record.
  • the payment management server 3A executes the invalidation process without receiving the invalidation instruction from the store server 1A. That is, since transmission/reception of information between the store server 1A and the payment management server 3A is omitted, it is possible to reduce the processing load of both information processing apparatuses.
  • Order information acceptance process in the second embodiment An example of the order information acceptance process according to the second embodiment will be described with reference to FIG. Note that the same processing as the order information reception processing (FIG. 8) in the first embodiment is given the same reference numeral, and description thereof will be omitted as appropriate.
  • the store server 1A determines whether or not the order information is received from the order terminal 7 in step S601, and if the order information is received, the order identification information is generated by executing the processes in steps S602 to S606. To do. Further, the store server 1A executes the processes of steps S607 to S609 to calculate the amount of money (total amount of orders) related to the order information received this time.
  • the store server 1A performs a process of storing the order information in step S610, and a process of transmitting the payment information to the payment management server 3A in step S611.
  • the store server 1A determines whether or not the print instruction is received from the payment management server 3A in step S621, instead of instructing the printing device to print the accounting slip.
  • the store server 1A waits in step S621 until the print instruction is received.
  • the store server 1A which has confirmed the reception of the print instruction, executes the print processing of the accounting slip in step S622. In this process, for example, a print instruction is transmitted to the printing device.
  • the order management server 3A By waiting until the store server 1A receives a print instruction from the payment management server 3A, the order management server 3A normally receives the order identification information and the amount information, and then the printing process is executed. It is possible to avoid the problem that the payment management server 3A does not receive the order information when the used payment process is performed and the payment process cannot be performed, and a reliable payment process can be realized.
  • Payment information reception process> An example of the payment information receiving process of the second embodiment will be described with reference to FIG. Each process performed in the payment information reception process of the second embodiment is performed in each of the payment information reception process (FIG. 10) and the invalidation instruction reception process (FIG. 12) of the first embodiment. Corresponds to processing.
  • the payment management server 3A confirms the receipt of the payment information in step S701, acquires the order identification information and the amount information in step S702, and executes a storage process in step S703.
  • the payment management server 3A executes a process of transmitting a print instruction to the store server 1A.
  • this process may be a transmission process to an information processing device other than the store server 1A belonging to the network managed by the store.
  • the payment management server 3A acquires the order identification information in step S712, and executes a process of searching for a record to be invalidated in step S732.
  • the order identification information (or the orderer identification information included in the order identification information) acquired in step S712 is used.
  • the payment management server 3A determines in step S733 whether or not the record to be invalidated is searched. When the record to be invalidated is searched, the payment management server 3A sets the invalidation flag for the target record to "ON" in step S713. This may be achieved by setting the valid flag to "False", as described above.
  • step S701 the payment management server 3A executes the process of step S701 again.
  • the store server 1 transfers to the payment management server 3 in step S203 of FIG. 5 according to the order of the orderer. Different information is sent. Specifically, the order identification information and the amount information are transmitted in the first and second embodiments, but the amount information is not transmitted in the third embodiment. Different.
  • step S201 A specific processing flow will be described with reference to FIG. Until the shop server 1 receives the order information from the order terminal 7, that is, until the processing of step S201 is executed, the same processing as that of the other embodiments is executed, and thus the description thereof is omitted.
  • the store server 1 which has received the order information corresponding to the order of the orderer, executes the process of acquiring the order identification information from the received information in step S213, and in the subsequent step S214, the payment management server receives the order identification information.
  • the process of transmitting to No. 3 is executed. That is, the money amount information is not transmitted here.
  • the payment management server 3 receives the order identification information in step 312, and stores the order identification information in step S302. Thereby, the information that can identify the order of the orderer is stored.
  • step S305 is a process of invalidating the corresponding order identification information using a flag or the like.
  • the user terminal 4 executes the processing from step S501 to step S503, thereby receiving the code information reading operation, and executing the reading processing and the payment method selection processing.
  • the user terminal 4 performs a payment request transmission process in step S504.
  • the payment management server 3 does not manage the order amount. That is, at the time of executing the process of step S504, the payment management server 3 does not know the order amount of the order that can be specified by the order identification information. Therefore, in the payment request transmission process of step S504, the payment amount is transmitted from the user terminal 4 in addition to the order identification information and the information capable of specifying the payment method. That is, the code information read by the user terminal 4 includes order identification information and payment amount information.
  • the payment management server 3 executes the payment request receiving process in step S306, and executes the payment process in step S307. By this processing, the amount information received from the user terminal 4 is transmitted to the card company system 5, and the payment is completed.
  • the amount of money information is received from the user terminal 4, and the amount of money information is also received from the store server 1 to confirm the consistency of the amount of money.
  • the user terminal 4 executes the processes of steps S501 to S504, whereby a payment request including the amount information is transmitted.
  • the payment management server 3 executes the amount information confirmation process in step S313.
  • This process is a process of requesting the amount information associated with the order identification information, that is, the amount of money to be paid by the orderer, by transmitting the order identification information to the store server 1.
  • the store server 1 that has received the request acquires the amount information associated with the order identification information in step S215, and performs a process of transmitting the amount information to the payment management server 3 in step S216.
  • the payment management server 3 receives the amount information in step S314, and executes the consistency confirmation process in step S315.
  • the consistency confirmation process is a process of confirming whether the money amount information received from the user terminal 4 and the money amount information received from the store server 1 match. After executing the consistency confirmation process, the payment management server 3 executes the payment process of step S307. Since each processing executed by each information processing apparatus after this is the same as that described above, description thereof will be omitted.
  • the money amount information is not received from the user terminal 4. Instead, the money amount information is received from the store server 1.
  • the user terminal 4 executes the processes of steps S501 to S504, the payment request is transmitted without including the amount information.
  • the payment management server 3 After receiving the payment request in step S306, the payment management server 3 executes the amount information confirmation process in step S313.
  • This process is a process of requesting the amount information associated with the order identification information, that is, the amount of money to be paid by the orderer, by transmitting the order identification information to the store server 1.
  • the store server 1 that has received the request acquires the amount information associated with the order identification information in step S215, and performs a process of transmitting the amount information to the payment management server 3 in step S216.
  • the payment management server 3 After receiving the amount information in step S314, the payment management server 3 executes the payment process in step S307 without executing the process in step S315. Since each processing executed by each information processing apparatus after this is the same as that described above, description thereof will be omitted.
  • step S601 to S606 are the same as those of the other embodiments, and thus the description thereof will be omitted.
  • Each process of steps S607 to S609 is a process for calculating the total order amount.
  • the process of step S611 may be performed immediately after the process of step S606.
  • the order information reception process (see FIG. 19) executed by the store terminal 1A. That is, in the payment information transmission process of step S611 of FIG. 19, the total order amount is not transmitted. As a result, in the present embodiment, the amount of information transmitted from the store terminal 1 to the payment management server 3 is minimized, so that the communication cost can be reduced. In particular, an orderer who repeatedly makes additional orders may send the total order amount that is not referred to after being invalidated to the payment management server 3 many times. In this case, only the total order amount sent by the last order will be referenced. In the present embodiment, such useless transmission of information is suppressed.
  • step S702 The payment information reception process executed by the store terminal 1 will be described with reference to FIG.
  • the process of step S702 is different from that of the first embodiment described with reference to FIG. Specifically, since the received information does not include the amount information, the order identification information is acquired, but the amount information is not acquired. Therefore, also in the storage process of step S703, only the order identification information is stored.
  • step S702 and the processing of S703 are different.
  • step S731 the payment management server 3 does not hold the amount information, and thus the print instruction is issued to the store server 1A by designating the order identification information.
  • the store server 1A specifies the amount information based on the received order identification information, and prints the accounting slip including the information.
  • the information stored in the payment management server 3 according to the payment information receiving process is only the order identification information, so that the storage area used can be made compact. Can contribute to cost reduction.
  • Payment request reception process The payment request reception process executed by the payment management server 3 will be described with reference to FIG.
  • the series of processing shown in FIG. 14 (or the series of processing shown in FIGS. 23 and 24 described later) may be processing executed by the payment management server 3A. Note that the processes of steps S721 to S724 are the same as those of the other embodiments, and thus the description thereof will be omitted.
  • the payment management server 3 that has acquired the credit card information then acquires the information about the usage amount. Specifically, in step S725, the payment management server 3 executes a process of extracting usage amount information from the information received in step S721. That is, in the previous example, the information is acquired from the DB managed by the payment management server 3, whereas in the present embodiment, the usage amount information is extracted from the information received from the user terminal 4.
  • a payment process (that is, a series of processes shown in FIG. 14) is executed using the money amount information acquired from the user terminal 4. That is, since the money amount information is not acquired from the store server 1, the information transmission/reception process performed between the store server 1 and the payment management server 3 is reduced, which reduces the processing load and the communication amount. Can be planned.
  • step S725 the payment management server 3 executes a process of extracting usage amount information from the information received in step S721.
  • the payment management server 3 executes the amount information confirmation processing in step S731.
  • This process is the process of step S313 of FIG. 22, that is, a process of requesting the store server 1 to transmit the amount information.
  • the order identification information is transmitted to the store server 1.
  • the payment management server 3 receives the amount information from the store server 1 in step S732.
  • the payment management server 3 executes the consistency confirmation process in step S733.
  • This process is a process of determining whether or not the usage amount information received from the user terminal 4 and the amount information received from the shop server 1 are the same. When the two pieces of money amount information are different, the payment management server 3 notifies the user terminal 4 and the store server 1 that the payment has failed.
  • the payment management server 3 executes the processes of steps S726 to S728. This completes the payment of the orderer using the user terminal 4.
  • step S725, step S731, step S732, and step S733 may be executed immediately after the process of step S722. Accordingly, when the two pieces of money amount information are different, it is not necessary to perform the acquisition process of the information that is not used (payment method or credit card information), and thus the processing load can be reduced.
  • the payment management server 3 executes the amount information confirmation processing in step S731 after executing the processing in steps S721 to S724. By this processing, the request for the amount information is transmitted to the store server 1.
  • the payment management server 3 When the amount information is transmitted by the store server 1, the payment management server 3 performs a receiving process of the amount information in step S732. The payment management server 3 makes a request to secure a frame for the usage amount in step S726. A description of each subsequent process is omitted.
  • the payment management server 3 does not hold the amount information, and acquires it only when the payment request is received. Further, the acquisition of the money amount information is performed from the store server 1 and is not included in the information received from the user terminal 4. That is, since the transmission and reception of the money amount information is minimized, the communication cost can be reduced (that is, the communication traffic can be reduced, the communication processing load can be reduced, and the communication fee can be reduced).
  • the information processing apparatus as the store server 1 includes the information acquisition unit 1a that acquires the order identification information that can specify the order by the orderer, and the order identification information (in addition to the order (Which may include the amount information as the payment amount of) is transmitted as the payment information, the print control unit 1c for executing the print processing of the printed matter capable of specifying the order identification information, and the orderer
  • the print control unit 1c for executing the print processing of the printed matter capable of specifying the order identification information
  • an invalidation instruction for invalidating the order identification information of the unpaid order by the same orderer is disabled by another information processing device (payment order).
  • the invalidation instruction unit 1d for the management server 3) is provided.
  • the order identification information is information that enables the orderer to uniquely identify the order.
  • the order identification information (which may include the amount information (total order amount)) is previously transmitted as payment information to another information processing apparatus (payment management server 3) that performs the payment processing, thereby performing the payment processing.
  • the payment processing can be executed only by transmitting the order identification information, so that the time required for the payment processing in the payment management server 3 can be reduced.
  • the processing load on the store server 1 when performing the payment process is significantly reduced. It Further, when an additional order from the orderer is accepted, by issuing an invalidation instruction to the payment management server 3 to invalidate the payment information that has already been sent, unpaid payment by the same orderer. When there are a plurality of payment information, only the latest payment information is valid.
  • the data handled when performing the payment process is only the latest payment information, so that the time required for the payment process can be shortened and the processing load on the payment management server 3 can be reduced.
  • a terminal different from the information processing apparatus (store server 1) for example, an orderer terminal (user terminal 4) such as a mobile phone used by the orderer is displayed.
  • the order identification information can be read.
  • a payment request based on the read order identification information can be made from the orderer terminal (user terminal 4). That is, since the information processing device (store server 1) does not have to execute the process of transmitting the payment request, the processing load on the information processing device (store server 1) can be reduced.
  • the orderer terminal By enabling the payment request transmission process using another terminal such as 4), the payment request transmission process can be distributed, and the processing load can be prevented from being concentrated on one terminal (store server 1). It becomes possible to perform efficient processing. In addition, it is possible to avoid a situation in which the orderer has to wait in line for accounting and waste time.
  • the store server 1 does not need to implement a process for receiving information transmitted from various user terminals 4, so that the cost for constructing the store server 1 can be reduced. Further, since the processing load on the store server 1 is reduced, the performance of the store server 1 can be reduced, and the cost of the store server 1 itself can be reduced. Moreover, since it is not necessary to hold information about a large number of user terminals 4, it is possible to reduce the DB handled by the store server 1 and the storage unit included in the store server 1.
  • a receiving unit (payment information receiving unit 3a) that receives, as payment information, order identification information that may specify an order made by the orderer (in addition, it may include amount information as the payment amount for the order). ), and a print control unit (print instruction unit 3f for executing a print process of a printed matter for which order identification information can be specified, and an unpaid order by the same orderer when an additional order by the orderer is accepted.
  • an information processing device (payment management server 3A) that includes an invalidation processing unit 3e that performs invalidation processing that invalidates the order identification information so that payment of the order identification information becomes impossible. The action and effect of can be obtained.
  • the order identification information handled by the information processing apparatus as the store server 1 may include the orderer identification information that identifies the orderer. Since the order identification information includes the information that enables the orderer to be specified, it is possible to determine whether or not the order is placed by the same orderer only by analyzing the order identification information. This makes it easy for the same orderer to specify the payment information to be invalidated by the invalidation instruction, thus reducing the processing load.
  • the orderer identification information handled by the information processing device as the store server 1 may include information that can identify the store that received the order. Since the information that can specify the customer also includes the information that can specify the store, the customer specifying information is different for each store. That is, since the customer identification information transmitted from each of the plurality of stores does not overlap, it is not necessary to provide a different payment management server 3 for each store, and it is possible to reduce the processing load and the system installation cost. Becomes Further, the orderer identification information may not include personal information of the orderer.
  • the orderer identification information may be composed of a store code indicating the store that placed the order, a table code indicating the table used by the orderer, and a use code indicating the order in which the table was used.
  • the orderer identification information does not include the orderer's personal information, so that it is convenient to handle the order identification information from the viewpoint of protecting the personal information.
  • the printing process executed by the information processing apparatus as the store server 1 is a process of printing code information (for example, a two-dimensional bar code) with which the order identification information can be specified on a printed matter, such as the function description of the print control unit 1c. May be Thereby, as the code information, a generally popular one-dimensional barcode or two-dimensional barcode can be used. That is, since the existing technology can be applied to this configuration, the development cost can be reduced.
  • code information for example, a two-dimensional bar code
  • the receiving unit 1e that receives, as a payment completion notification, a notification indicating that the payment is completed from another information processing apparatus (payment management server 3). May be provided.
  • the payment completion notification it is possible to determine whether or not the orderer has paid the price. As a result, it is possible to prevent fraudulent acts that do not pay the price.
  • the processing load on the information processing device (store server 1) and the operator (store clerk) can be reduced.
  • the transmission unit 1e may transmit, as the amount information, information on the total amount of the additional order that has been made after the receipt of the payment completion notification and has not been paid.
  • the payment information includes the amount information as the payment amount for the order. That is, the notification that the amount of the paid order is removed is sent to another information processing apparatus (for example, the payment management server 3).
  • the payment management server 3 does not have to perform a process of subtracting the amount of money for the paid order, so that the processing load on the payment management server 3 can be reduced.
  • the processing capacity of the payment management server 3 may become a bottleneck, but as in this configuration, the load on the payment management server 3 for receiving and storing the payment information is reduced. By doing so, smooth processing can be executed. Also, it is possible to process requests from more stores. Furthermore, since it is possible to employ an inexpensive computer with a reduced processing capacity as the payment management server 3, it is possible to reduce the system cost.
  • the information processing device as the payment management server 3 receives, as the payment information, the payment information receiving unit 3a that receives the order identification information (which may additionally include the amount information) that can specify the order by the orderer. And a storage processing unit 3b that executes a storage process of the received payment information, order identification information and payment information of the orderer (for example, a payment method is specified from the orderer terminal (user terminal 4) used by the orderer).
  • the payment request receiving unit 3c that receives a payment request including the information), the payment processing unit 3d that performs payment processing for the payment information based on the payment request, and the payment request receiving unit 3c that are the same when an additional order from the orderer is accepted.
  • An invalidation processing unit 3e that receives an invalidation instruction that invalidates the order identification information so that payment of the unpaid order identification information by the orderer becomes impossible, and invalidates the stored payment information. , Are provided. By the invalidation processing by the invalidation processing unit 3e, only the payment information having the latest order identification information is validated, and double payment is prevented.
  • the information processing device of either the store server 1 or the payment management server 3 acquires information for obtaining order identification information that can specify an order made by the orderer.
  • the orderer 1c or the print instruction unit 3f
  • the orderer invalidates the order identification information so that the same orderer cannot pay the unsettled order identification information.
  • An invalidation instruction unit 1d that issues an invalidation instruction to another information processing apparatus (payment management server 3), a payment information receiving unit 3a that receives payment information, and a storage process of the received payment information.
  • the storage processing unit 3b, the payment request receiving unit 3c that receives the payment request including the order identification information and the payment information of the orderer from the orderer terminal (user terminal 4) used by the orderer.
  • the payment processing unit 3d performs a payment process for the payment information
  • the invalidation processing unit 3e receives the invalidation instruction from the invalidation instruction unit and invalidates the stored payment information.
  • the payment system described above may include the information acquisition unit 1a that acquires the order identification information that enables the orderer to specify the order, and the order identification information (in addition to this, the amount information as the payment amount for the order. )
  • a payment information receiving unit 3c for receiving payment information
  • a storage processing unit 3b for executing storage processing of the received payment information
  • order identification information identification is accepted, payment of the unidentified order identification information by the same orderer.
  • Invalidation processing unit 3e that performs invalidation processing to invalidate the order identification information so that the order identification information becomes impossible, and a payment request including the order identification information and the payment information of the orderer from the orderer terminal used by the orderer.
  • the payment request receiving unit 3c that receives the payment request and the payment processing unit 3d that performs the payment process for the payment information based on the payment request may be provided.
  • the store server 1 issues a print instruction for a printed matter (for example, an accounting slip) without depending on the process of the payment management server 3A, and the order identification information invalidation process does not depend on the process of the store server 1A.
  • the configuration executed by the payment management server 3A is also included.
  • the program of the embodiment causes an arithmetic processing unit of an information processing apparatus (for example, a user terminal 4) to perform a process of reading order identification information that can specify an order from a printed material (for example, a two-dimensional bar code).
  • a payment request including payment information for performing payment for an order that has been placed after the payment information that has been invalidated by the invalidation instruction and has been unpaid, and the read order identification information.
  • the arithmetic processing unit of the information processing device (for example, the user terminal 4) is caused to execute the process of transmitting. That is, this program is a program that causes the information processing apparatus (for example, the user terminal 4) to execute the processes of steps S501 to S505 described with reference to FIG.
  • Such a program can be stored in advance in an HDD as a storage medium built in a device such as a computer or a ROM in a microcomputer having a CPU. Alternatively, it can be stored (memorized) temporarily or permanently in a removable storage medium such as a semiconductor memory, a memory card, an optical disk, a magneto-optical disk, or a magnetic disk. Further, such a removable storage medium can be provided as so-called package software. Further, such a program can be installed from a removable storage medium to a personal computer or the like, or can be downloaded from a download site via a network such as a LAN or the Internet.
  • a network such as a LAN or the Internet.
  • 1 store server 1a information acquisition unit, 1b transmission unit, 1c print control unit, 1d invalidation instruction unit, 1e reception unit, 3 payment management server, 3a payment information reception unit, 3b storage processing unit, 3c payment request reception unit 3d payment processing unit, 3e invalidation processing unit, 4 user terminal

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

会計処理に携わる店員の作業負担を軽減しつつ、適切な会計処理を行うことが可能な環境を提供する。そのために、情報処理装置は、注文者による注文を特定可能な注文識別情報を取得する情報取得部と、前記注文識別情報を支払い用情報として送信する送信部と、前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文の注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置に対して行う無効化指示部と、を備えるものとした。

Description

情報処理装置、情報処理方法、支払いシステム及びプログラム
　本発明は、ユーザの注文に関する情報を受け付け各種の処理を行う情報処理装置、情報処理方法、支払いシステム及びプログラムについての技術分野に関する。
　例えば店舗にて食事をする場合に、複数の来店客の会計タイミングが集中してしまうことにより会計処理が滞ってしまい、行列が出来てしまうことがある。これによって、食事を終えた来店客が時間を無駄に浪費させられてしまうという問題が生じる虞があった。
　以下に示す特許文献１においては、このような問題点を鑑み、セルフオーダ端末にメニューブックからメニュー識別情報（メニューコード）を読み取らせることにより注文を行い、セルフオーダ端末が印刷した会計用コードを会計装置に読み取らせることにより会計を行うことが記載されている。また、注文あるいは会計を行なう各装置を必要な台数組み合わせて適宜配置することにより、会計待ちの行列を分散させることができる旨が記載されている。
特開２０１２－９４０５８号公報
　ところで、会計装置を来店客に操作させることには、予期できない不測の事態が生じる虞がある。例えば、会計装置の扱いに慣れていないことから誤操作を行ってしまい、誤った会計処理がなされてしまうことが想定される。そのような場合には、店員を呼んで会計操作をやり直して貰うというように、会計操作を店員が行っていれば本来不要であったはずの修正操作が生じてしまい、店員の作業負担の増大を招来してしまう虞がある。
　そこで、本発明は、会計処理に携わる店員の作業負担を軽減しつつ、適切な会計処理を行うことが可能な環境を提供することを目的とする。
　本発明に係る情報処理装置は、注文者による注文を特定可能な注文識別情報を取得する情報取得部と、前記注文識別情報を支払い用情報として送信する送信部と、前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文の注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置に対して行う無効化指示部と、を備えるものである。
　これにより、同一の注文者による未払いの支払い用情報が複数ある場合には最新の支払い用情報のみが有効な状態とされる。
　上述した情報処理装置において、前記注文識別情報は、注文者を識別する注文者識別情報を含むものとされてもよい。
　注文識別情報が注文者の特定を可能とする情報を含むことにより、注文識別情報を解析するだけで同一の注文者による注文であるのか否かを判定することが可能となる。
　上述した情報処理装置において、前記注文者識別情報は、注文を受け付けた店舗を特定可能な情報を含むものとされてもよい。
　顧客を特定可能な情報が店舗特定可能な情報も含むことにより、顧客特定情報は、店舗ごとに異なる情報とされる。
　上述した情報処理装置における前記印刷処理では、前記注文識別情報の特定が可能なコード情報を前記印刷物に印刷する処理とされてもよい。
　これにより、コード情報として、一般的に普及している一次元バーコードや二次元バーコードを利用することができる。
　上述した情報処理装置においては、前記他の情報処理装置から支払いが完了したことを示す通知を支払い完了通知として受信する受信部を備えていてもよい。
　支払い完了通知を受信することにより、注文者が代金を支払ったか否かを判別することが可能となる。
　上述した情報処理装置においては、前記支払い用情報には前記注文についての支払金額としての金額情報が含まれ、注文者による注文についての前記支払い完了通知を受信した後に、同一の注文者による追加注文を受け付けた場合には、前記送信部は、前記金額情報として、前記支払い完了通知の受信後に行われ且つ未払いとされた追加注文の合計金額の情報を送信してもよい。
　即ち、支払い済みの注文に関する金額が除かれた通知が他の情報処理装置（例えば支払い管理サーバ）に対して行われる。
　本発明に係る他の情報処理装置は、注文者による注文を特定可能な注文識別情報を支払い用情報として受信する支払い用情報受信部と、受信した前記支払い用情報の記憶処理を実行させる記憶処理部と、注文者が利用する注文者端末から注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部と、前記支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を受け付け、記憶された前記支払い用情報の無効化を行う無効化処理部と、を備えたものである。
　他の情報処理装置は、上述の情報処理装置から支払い用情報を受信して各処理を実行するものである。
　本発明に係る他の情報処理装置は、注文者による注文を特定可能な注文識別情報を支払い用情報として受信する受信部と、前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文の注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化処理を行う無効化処理部と、を備えたものであってもよい。
　本発明に係る支払いシステムは、注文者による注文を特定可能な注文識別情報を取得する情報取得部と、前記注文識別情報を支払い用情報として送信する送信部と、前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置に対して行う無効化指示部と、前記支払い用情報を受信する支払い用情報受信部と、受信した前記支払い用情報の記憶処理を実行させる記憶処理部と、注文者が利用する注文者端末から前記注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部と、前記支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部と、前記無効化指示部からの無効化指示を受け付け記憶された前記支払い用情報の無効化を行う無効化処理部と、を備えたものである。
　或いは、注文者による注文を特定可能な注文識別情報を取得する情報取得部と、前記注文識別情報を支払い用情報として送信する送信部と、前記支払い用情報を受信する支払い用情報受信部と、受信した前記支払い用情報の記憶処理を実行させる記憶処理部と、前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化処理を行う無効化処理部と、注文者が利用する注文者端末から前記注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部と、前記支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部と、を備えた支払いシステムであってもよい。
　本発明に係る情報処理方法は、注文者による注文を特定可能な注文識別情報を取得する情報取得ステップと、前記注文識別情報を支払い用情報として送信する送信ステップと、前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御ステップと、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置に対して行う無効化指示ステップと、を情報処理装置が実行するものである。
　これにより、同一の注文者による未払いの支払い用情報が複数ある場合に最新の支払い用情報のみが有効な状態とされる環境を提供することができる。
　本発明に係るプログラムは、注文を特定可能な注文識別情報を印刷物から読み取る手順と、無効指示がなされて無効化された支払い用情報よりも後に行った注文であって且つ未払いとされた注文についての支払いを行うための支払い情報と読み取った前記注文識別情報とを含む支払い要請を送信する手順と、をコンピュータに実行させるものである。
　これにより、同一の注文者による未払いの支払い用情報が複数ある場合に最新の支払い用情報のみが有効な状態とされる環境で支払いを行うことができる。
　本発明によれば、会計作業を注文者が行うことによって会計処理に携わる店員の作業負担が軽減されると共に、同一の注文者による未払いの支払い用情報が複数ある場合には最新の支払い用情報のみが有効な状態とされるため適切な会計処理を行うことができる。
本発明の実施の形態の店舗サーバを含むネットワークの説明図である。 実施の形態の店舗サーバの機能構成の説明図である。 実施の形態の支払い管理サーバの機能構成の説明図である。 実施の形態のコンピュータ装置のブロック図である。 注文者による最初の注文が行われる際に各端末やサーバが実行する各処理について説明するための図である。 注文者による追加の注文が行われる際に各端末やサーバが実行する各処理について説明するための図である。 注文者によって注文代金の支払いが行われる際に各端末やサーバが実行する各処理について説明するための図である。 注文情報受付処理の一例を示すフローチャートである。 注文ＤＢに記憶される注文情報等を説明するための図である。 支払い用情報受信処理の一例を示すフローチャートである。 支払い用ＤＢに記憶される情報を説明するための図である。 無効化指示受信処理の一例を示すフローチャートである。 端末アプリ起動処理の一例を示すフローチャートである。 支払い要請受信処理の一例を示すフローチャートである。 第２の実施の形態の店舗サーバの機能構成の説明図である。 第２の実施の形態の支払い管理サーバの機能構成の説明図である。 第２の実施の形態の注文者による最初の注文が行われる際に各端末やサーバが実行する各処理について説明するための図である。 第２の実施の形態の注文者による追加の注文が行われる際に各端末やサーバが実行する各処理について説明するための図である。 第２の実施の形態の注文情報受付処理の一例を示すフローチャートである。 第２の実施の形態の支払い用情報受信処理の一例を示すフローチャートである。 第３の実施の形態の注文者による最初の注文が行われる際に各端末やサーバが実行する各処理について説明するための図である。 第３の実施の形態の注文者によって注文代金の支払いが行われる際に各端末やサーバが実行する各処理について説明するための図である。 第３の実施の形態の支払い要請受信処理の例を示すフローチャートである。 第３の実施の形態の支払い要請受信処理の別の例を示すフローチャートである。
　本実施の形態の店舗サーバ１を含むネットワークシステムの構成例について、図１を参照して説明する。
＜１．システム構成＞
　本実施の形態に係る店舗サーバ１は、通信ネットワーク２に接続されている。
　通信ネットワーク２には、支払い管理サーバ３やユーザ端末４やカード会社システム５や電子マネーシステム６なども接続されている。
　各装置やシステムは通信ネットワーク２を介して相互に通信可能とされている。
　通信ネットワーク２の構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が想定される。
　また通信ネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線等の有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
　店舗サーバ１は、例えばレストランや小売店などの店舗に設置された情報処理装置である。店舗サーバ１は、来店客（注文者）による注文を受け付ける処理や、注文内容を厨房に伝えるための処理や、支払い用情報を支払い管理サーバ３に送信する処理などを行う。
　また、店舗には店舗サーバ１以外に注文者が行った注文の入力が可能な入力端末としての注文端末７が適宜配備されている。注文端末７は、店舗の広さ等に応じて適切な数とされている。
　注文端末７は、例えば、店舗で働く店員が所持するハンディタイプのものであってもよいし、来店客が食事を行うテーブルに備え付けられた卓上設置タイプのものであってもよい。
　注文端末７によって入力された各種情報は、店舗サーバ１に送信される。注文端末７は、新規の注文を入力するだけでなく、追加の注文の入力も受け付け可能とされている。
　注文端末７は、少なくとも店舗サーバ１と通信可能とされていればよい。また、注文端末７から店舗サーバ１への通信は可能とされると共に、店舗サーバ１から注文端末７への通信は不可能とされてもよい。
　店舗サーバ１は、注文端末７から受信した情報に基づいて各種処理を行う。また、追加注文の情報を注文端末７から受信した店舗サーバ１は、追加注文についての支払い用情報を支払い管理サーバ３に送信すると共に、それまでに送信済みである支払い用情報を無効化させるための無効化指示を支払い管理サーバ３に送信する。
　店舗サーバ１は、上記の各処理を実行するために、受け付けた注文情報が記憶される注文ＤＢ５１を備えている。注文ＤＢ５１には、注文された単品ごとのメニュー情報や単価情報、注文の合計金額情報などが注文識別情報に紐付けられて記憶される。
　支払い管理サーバ３は、店舗サーバ１から支払い用情報を受信し、記憶部に記憶させる処理などを行う。また、店舗サーバ１からの無効化指示を受け付け、該当の支払い用情報を無効化する処理を行う。
　そのために、支払い管理サーバ３は、受信した支払い用情報が記憶される支払い用ＤＢ６１を備えている。支払い用ＤＢ６１には、注文識別情報と合計金額情報とが紐付けられて記憶される。
　ユーザ端末４は、注文者が使用する情報処理端末であり、コード情報（例えば、一次元バーコードや二次元バーコード）の読み取りが可能とされている。コード情報の読み取りは、ユーザ端末４にソフトウェアがインストールされることにより実現可能とされていてもよい。
　また、ユーザ端末４は、読み取ったコード情報に基づいて、支払い管理サーバ３に支払い要請を送信することが可能とされている。その際には、クレジットカードによる支払いや電子マネーによる支払いなど、複数用意された支払い方法から所望する支払い方法を指定可能とされていてもよい。
　ユーザ端末４は、例えば、通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistants）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。
　カード会社システム５は、注文者（ユーザ）によってクレジットカードによる支払いを指定された際に、支払い管理サーバ３からクレジットカードによる支払いを行うために必要な各種の情報を受信し、クレジットカードにより支払い処理を行うシステムである。
　例えば、指定されたクレジットカードの有効期限が適切かどうかを判定する処理や、指定されたクレジットカードが使用禁止リストに登録されていないかを判定する処理や、利用額が限度額を超えていないかを判定する処理などを行う。また、指定されたクレジットカードを利用可能と判定した場合には、今回の利用額分の枠を確保する処理なども行う。
　そのために、カード会社システム５は、ユーザ情報（ユーザの氏名や年齢などの個人情報とカード情報が紐付けられた情報）が記憶されるデータベース（Database、以降「ＤＢ」と記載）や、オーソリゼーション（所謂オーソリ）を行うためのＤＢや、クレジットカードの利用履歴が記憶されるＤＢなどを適宜備えている。なお、それらの各ＤＢについては図示していない。
　電子マネーシステム６は、注文者（ユーザ）によって電子マネーによる支払いを指定された際に、支払い管理サーバ３から電子マネーによる支払いを行うために必要な各種の情報を受信し、電子マネーによる支払い処理を行うシステムである。そのために、電子マネーシステム６は、ユーザ情報（ユーザの氏名や年齢などの個人情報と電子マネーを利用するためのアカウント情報が紐付けられた情報）が記憶されるＤＢや、電子マネーの利用履歴が記憶されるＤＢなどを適宜備えている。なお、それらの各ＤＢについては図示していない。
　カード会社システム５や電子マネーシステム６は、カードブランド（カード会社）や電子マネーの種類ごとに複数設けられていてもよい。
＜２．機能構成＞
　店舗サーバ１の機能構成について、図２を参照して説明する。
　店舗サーバ１は、情報取得部１ａ、送信部１ｂ、印刷制御部１ｃ、無効化指示部１ｄ、受信部１ｅを備えている。
　情報取得部１ａは、注文者による注文を特定可能な注文識別情報を取得する処理を行う。
　ここで、注文識別情報について説明する。注文識別情報は、注文端末７から店舗サーバ１へ送信される情報である。即ち、情報取得部１ａは、注文端末７から注文識別情報を取得する。
　注文識別情報は、例えば、店舗を特定可能な店舗コード、注文者が着席したテーブルを特定可能なテーブルコード、該テーブルに来店してサービスを受けた注文者に付される固有の利用コード、注文の入力を行った時間を示す日時コードから成る。
　例えば、店舗コードが「００１」とされ、テーブルコードが「０１３」とされ、来店コードが「００２」（その日に該テーブルに通された注文者に順に付与される番号）とされ、日時コードが「２０１８１１２２１１０３４１」（２０１８年１１月２２日１１時３分４１秒を表す）とされた場合、注文識別情報は、「００１０１３００２２０１８１１２２１１０３４１」とされる。なお、注文者が追加注文を行った場合には、日時コードが異なる別の注文識別情報が追加注文に付与される。
　もちろん、この注文識別情報はあくまで一例であり、例えば、日時コードを使用する代わりに注文回数を表すコードを用いて注文識別情報の情報量（ビット数）を削減することも可能である。
　注文端末７が店員の使用する端末である場合には、店員によってテーブルコードや来店コードなどが入力されることにより、注文端末７にて注文識別情報の生成が行われる。
　また、注文端末７が卓上設置タイプの端末であり注文者が使用する端末である場合には、注文端末７が自動的に注文識別情報を生成するように構成してもよい。例えば、注文端末７には予め店舗コードやテーブルコードが記憶されており、注文者が新規に注文を行った場合には、直前に使用された来店コードに「１」を加算して新たに来店コードを生成し、注文を確定したタイミングで日時情報を取得して日時コードを生成するように構成し、それらの情報を用いて注文識別情報を生成してもよい。
　他にも、店舗サーバ１が予め店舗コードやテーブルコードを生成するための換算表や日時情報を備えるようにしてもよい。このような場合には、店舗サーバ１は注文情報を送信した注文端末７を特定し、それに応じてテーブルコードを換算表から取得し、来店コードを来店順に応じて付与し、注文情報を受信した日時情報から日時コードを生成し、それらの各情報と予め有している店舗コードとを用いて注文識別情報を生成することにより取得してもよい。
　注文識別情報を店舗サーバ１が生成するように構成した場合には、注文識別情報を生成する処理を注文端末７が実行する必要はなくなるため、処理負担の軽減がなされ、安価な端末を注文端末７として採用することが可能となる。
　なお、注文者識別情報は、テーブルコードと来店コードが付与されることから、注文者を識別するための注文者識別情報を含むと言える。
　また、注文者識別情報は店舗コードを含むことから、同一のアルゴリズムで生成された店舗ごとの注文識別情報を同じように扱うことが可能である。即ち、店舗が異なったとしても、注文識別情報が被ることはないため、店舗ごとに異なるシステムを導入する必要はない。これにより、異なる店舗間で同一のシステムを用いることができ、システムの導入コストの削減に寄与することができる。
　送信部１ｂは、注文端末７で受け付けた注文に関する情報を支払い管理サーバ３に送信する処理を行う。具体的には、注文識別情報と金額情報を支払い用情報として支払い管理サーバ３に送信する。
　金額情報は、品物ごとの金額であってもよいし、１回の注文で複数の商品を注文した場合の合計金額であってもよい。
　印刷制御部１ｃは、１回の注文を受け付けるごとに印刷物、例えば会計伝票のような印刷物を印刷させる処理を実行する。なお、本例における印刷制御部１ｃは、印刷物に一次元バーコードや二次元バーコードのようなコード情報を印刷するような指示を行う。
　コード情報は、注文識別情報を少なくとも含んでいる。コード情報が印刷された印刷物は、印刷されるごとに注文者（ユーザ）に渡される。なお、コード情報は注文についての支払金額情報を含んでいてもよい。
　印刷物に印刷されたコード情報は、注文者が所持する携帯電話などのユーザ端末４によって読み取られる。コード情報を読み取ったユーザ端末４は、支払い管理サーバ３に支払い要請の送信を行う。これにより、注文者は自身が注文した注文に係る支払いを行うことができる。
　無効化指示部１ｄは、注文者が追加注文を行うことにより、注文者の手元に複数の印刷物が渡された場合に、最新の追加注文を含む注文識別情報のみが有効となるように、それ以外の注文識別情報を無効化させるための指示を支払い管理サーバ３へ送信する処理を行う。
　受信部１ｅは、注文者による支払いが完了したことを示す通知など、各種の情報を受信する処理を行う。
　支払い管理サーバ３の機能構成について、図３を参照して説明する。
　支払い管理サーバ３は、支払い用情報受信部３ａ、記憶処理部３ｂ、支払い要請受信部３ｃ、支払い処理部３ｄ、無効化処理部３ｅを備えている。
　支払い用情報受信部３ａは、店舗サーバ１から支払い用情報を受信し、支払い用情報から注文識別情報と金額情報を抽出する処理を行う。
　記憶処理部３ｂは、抽出された注文識別情報と金額情報を支払い用ＤＢ６１に記憶する処理を行う。
　支払い要請受信部３ｃは、支払い要請を受信する処理を行う。支払い要請は、支払い用データを特定可能な注文識別情報と、支払い方法を特定するための情報などの支払い情報を含んでいる。
　支払い情報には、例えば、複数種類ある支払い方法のうち注文者が選択した支払い方法を特定するための情報が含まれている。また、支払い情報には、クレジットカード番号やセキュリティコードなどの情報を含んでいてもよいし、それらの情報を取得するためのキーとなる情報（例えばユーザＩＤ（Identification）など）のみを含んでいてもよい。
　支払い処理部３ｄは、注文者が指定した支払い方法に基づいて、カード会社システム５や電子マネーシステム６などに支払いを行うための必要な情報を送信する処理や、支払いが完了したことを示す情報を受信する処理などを行う。
　無効化処理部３ｅは、店舗サーバ１から受信した無効化指示に基づいて、所定の支払い用情報を無効化する処理を行う。無効化処理の例としては、例えば、該当のレコードを消去してもよいし、該当のレコードに付与されたフラグについて有効を示す状態から無効を示す状態へと書き換えてもよい。
＜３．ハードウェア構成＞
　図１に示した店舗サーバ１、支払い管理サーバ３、ユーザ端末４、カード会社システム５や電子マネーシステム６を構成する各種のコンピュータ装置や端末、注文ＤＢ５１、支払い用ＤＢ６１などの各装置は、情報処理及び情報通信が可能な図４に示すようなコンピュータ装置として実現できる。
　なお、全てのコンピュータ装置が図４に示す各部を過不足なく備えている必要はなく、一部の構成を備えていない装置や、一部の構成を複数備えている装置や、図４に示す以外の構成を備えている装置であってもよい。
　図４において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
　ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
　入出力インターフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９が接続されている。
　入力部１０６はキーボード、マウス、タッチパネルなどにより構成される。本実施の形態におけるユーザ端末４には、コード情報を取得（撮影）する構成が入力部１０６として設けられている。
　出力部１０７はＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどにより構成される。
　記憶部１０８はＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などにより構成される。
　通信部１０９はネットワーク１を介しての通信処理や機器間通信を行う。
　入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。
　このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われる。またリムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
　ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、店舗サーバ１、支払い管理サーバ３、ユーザ端末４、カード会社システム５や電子マネーシステム６を構成する各種のコンピュータ装置や端末、注文ＤＢ５１、支払い用ＤＢ６１としての必要な情報処理や通信が実行される。
　なお、店舗サーバ１、支払い管理サーバ３、ユーザ端末４、カード会社システム５や電子マネーシステム６を構成する各種のコンピュータ装置や端末、注文ＤＢ５１、支払い用ＤＢ６１を構成する情報処理装置は、図４のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。複数の情報処理装置には、クラウドコンピューティングサービスによって利用可能なサーバ群（クラウド）としての情報処理装置が含まれてもよい。
　図２に示す店舗サーバ１としての各機能や図３に示す支払い管理サーバ３としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部又は一部の各構成の処理をハードウェアにより実現してもよい。
　また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。１つのプログラムにより複数の機能の処理が実行されてもよいし、１つの機能が複数のプログラムモジュールの連携で実現されてもよい。
　また各機能は複数の情報処理装置に分散されていてもよい。さらに機能の１つが、複数の情報処理装置によって実現されてもよい。
　店舗サーバ１が備える注文ＤＢ５１や支払い管理サーバ３が備える支払い用ＤＢ６１は、店舗サーバ１や支払い管理サーバ３がそれぞれアクセス可能とされていればどのような形態で実現されていてもよい。例えば店舗サーバ１と同一システム内の記憶部に注文ＤＢ５１のすべてが形成されていてもよいし、注文ＤＢ５１の一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん注文ＤＢ５１が一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また注文ＤＢ５１が、一つのＤＢとして構成される必要もない。以下の各例で説明する各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ一つのＤＢの形態で例示したものに過ぎない。
＜４．大まかな処理の流れ＞
　先ず、添付図に示す一例を参照して、各装置が行う処理の流れの概要を説明する。
　具体的には、注文者による最初の注文が行われる際に各端末やサーバが実行する各処理（図５参照）と、注文者による追加の注文が行われる際に各端末やサーバが実行する各処理（図６参照）と、注文者によって注文代金の支払いが行われる際に各端末やサーバが実行する各処理（図７参照）とについて順に説明する。
　なお、以下の説明においては、来店客がレストランなどに来店して食事を頼む場合を例に挙げて各処理の説明を行う。
＜４－１．最初の注文に関する流れ＞　
　図５を参照して、最初の注文に係る各処理の一例を説明する。
　店舗に来店した来店客が店員によってテーブルに通された後、店員は自身が所持するハンディタイプの注文端末７に、注文識別情報を生成するための情報入力を行う。
　例えば、新規来店客の受け付けであることを示すボタン（新規ボタン）を押下し、続いて、来店客が座ったテーブル番号（或いはカウンターの席番号）を入力する。注文端末７では、他にも来店者数の入力などが行われてもよい。
　店員の上記操作に基づいて、注文端末７では、ステップＳ１０１で、注文識別情報生成用の情報入力が行われる。
　次に、店員は来店者に注文を聞き、その情報を注文端末７に入力する。これによって、注文端末７ではステップＳ１０２において、注文情報入力が行われる。
　注文情報の入力は、例えば、メニューを特定するための番号入力やメニューを特定するためのボタン押下によって行われる。
　なお、以降では、注文を行った来店者を「注文者」と記載する。
　続いて、店員が注文確定ボタンや注文送信ボタンを押下することにより、注文端末７はステップＳ１０３で注文情報送信処理を実行する。注文情報は、注文識別情報を生成するための情報や、注文者が注文したメニューを特定する情報を含んでいる。
　なお、注文識別情報を生成するための情報としては、例えば、新規注文か追加注文かを特定するための情報と、テーブル番号が送信される。また、注文識別情報を生成するための情報の代わりに、注文識別情報を生成して送信してもよい。
　ステップＳ１０３の処理で送信された注文情報などの情報は、店舗サーバ１によるステップＳ２０１の処理で受信される。
　受信処理では、受信した情報を注文ＤＢ５１に記憶する処理や、注文識別情報を生成する処理が実行される。
　次に、店舗サーバ１はステップＳ２０２で、注文識別情報と金額情報を取得する処理を行う。ここで取得する金額情報は、注文者が行った注文の合計金額である。また、注文識別情報は、例えば、店舗コードが「００１」とされ、テーブルコードが「０１３」とされ、来店コードが「００２」とされた場合に、初回の注文識別情報は「００１０１３００２００１」とさている。この注文識別情報は、注文者識別情報（即ち、「００１０１３００２」）を含むものとされる。注文者識別情報は、他の注文者と異なるものであり、一人の注文者（または一グループの注文者）を特定可能な情報とされる。
　店舗サーバ１は、ステップＳ２０３で、注文識別情報と金額情報を支払い用情報として支払い管理サーバ３へ送信する処理を行う。
　店舗サーバ１は、ステップＳ２０４で、会計伝票を印刷させる処理を行う。会見伝票印刷処理で印刷される会計伝票には、例えば二次元バーコードが印刷される。二次元バーコードには、注文識別情報が含まれており、この情報を元に注文者が行った注文の合計金額を特定することが可能とされている。
　なお、支払い管理サーバ３から送信された印刷の指示を店舗サーバ１が受信することによりステップＳ２０４の印刷処理が実行されるように構成してもよい。
　また、ステップＳ２０３の処理で送信された注文識別情報と金額情報（即ち「支払い用情報」）は、支払い管理サーバ３によるステップＳ３０１の処理で受信される。
　支払い管理サーバ３は、続くステップＳ３０２で、注文識別情報と金額情報を紐付けて支払い用ＤＢ６１に記憶する処理を行う。
　図５に示す各処理が実行されることにより、注文者が行った注文に関する情報が、店舗サーバ１が管理する注文ＤＢ５１と支払い管理サーバ３が管理する支払い用ＤＢ６１に記憶される。
＜４－２．追加の注文の流れ＞
　図６を参照して、追加の注文に係る各処理の一例を説明する。
　既に何らかの注文を行っていた注文者が追加のメニューを注文すること伝えられた店員は、注文端末７に追加注文を行うための各情報を入力する。具体的には、追加注文であることを示すボタンを押下し、テーブル番号の入力を行う。
　この操作に基づいて、注文端末７ではステップＳ１０４で注文識別情報生成用の情報入力が行われる。
　次に、注文端末７では、ステップＳ１０５において、店員による追加注文情報の入力が行われる。具体的には、メニューを特定するための番号入力やメニューを特定するためのボタン押下が行われる。
　注文端末７は、ステップＳ１０６において、注文情報等を送信する処理を行う。この処理は、図５のステップＳ１０３と同様の処理である。
　ステップＳ１０６の処理で送信された追加注文に関する情報は、店舗サーバ１によるステップＳ２０５の処理で受信される。ステップＳ２０５の受信処理では、受信した情報を注文ＤＢ５１に記憶する処理や、注文識別情報を生成する処理が実行される。なお、ここで生成する注文識別情報（或いは注文端末７で生成した注文識別情報）は、初回の注文内容を特定するための注文識別情報とは異なる注文識別情報とされる。
　例えば、店舗コードが「００１」とされ、テーブルコードが「０１３」とされ、来店コードが「００２」とされた場合に、１回目の注文である初回の注文識別情報は「００１０１３００２００１」とされ、２回目の注文である追加注文の注文識別情報が「００１０１３００２００２」とされる。
　店舗サーバ１はステップＳ２０６で、注文識別情報と金額情報を取得する。ここで取得する金額情報は、同一の注文者が行った複数の注文のうち、未払いの注文の合計金額とされる。
　例えば、初回の注文金額が１０００円であり、追加の注文が５００円のとされ、更に初回と追加の注文が共に未払いの場合、ステップＳ２０６で取得される金額情報は、１５００円とされる。
　店舗サーバ１はステップＳ２０７で、注文識別情報（先の例では「００１０１３００２００２」）と金額情報（先の例では、「１５００」）を支払い用情報として送信する処理を行う。
　ステップＳ２０７で送信された支払い用情報は、支払い管理サーバ３によるステップＳ３０３の処理で受信される。
　支払い管理サーバ３はステップＳ３０４で、受信した支払い用情報を支払い用ＤＢ６１に記憶する処理を行う。ステップＳ３０３及びステップＳ３０４の各処理は、図５に示すステップＳ３０１及びステップＳ３０２の各処理と同様の処理である。
　ステップＳ２０７の処理を終えた店舗サーバ１は、ステップＳ２０８で無効化指示を送信する。この処理は、支払い管理サーバ３が実行するステップＳ３０３及びステップＳ３０４の処理が完了したかどうかを確認することなく、ステップＳ２０７の処理の直後に実行されてもよい。即ち、ステップＳ３０３の処理が実行される前にステップＳ２０８の処理が実行されてもよい。
　ステップＳ２０８で行う無効化指示の対象とされる支払い用情報は、同一の注文者が今回の追加注文の前に行っていた注文であって、且つ未払いの注文であり、更に無効化指示によって無効化されていない注文に係るものとされる。即ち、同一の注文者が今回の注文よりも前に注文を行っていない場合や、今回の注文よりも前に行っていた注文が全て支払い済みである場合には、ステップＳ２０８の処理を実行しない。
　例えば、図５に示す注文に関する処理では、注文者が行う注文が初回の注文であるため、今回の注文よりも前に注文を行っていないため、図６のステップＳ２０８に相当する処理は行っていない。
　ここで挙げた例を用いて説明すると、ステップＳ２０８の無効化指示の対象とされる支払い用情報は、注文識別情報は「００１０１３００２００１」とされた情報である。
　なお、ここでいう「同一の注文者」には、同一の人物であっても、異なる来店者として受け付けされた場合は含まれない。即ち、先日来店した客が後日新たな客として来店した場合には、同一の注文者として扱われない。
　無効化指示を受け付けた支払い管理サーバ３は、ステップＳ３０５で、無効化処理を実行する。無効化処理は、対象の注文識別情報を有するレコードを無効化することにより、注文者が支払いを行う際の対象から外れるようにする処理である。
　レコードの無効化は、例えばフラグを、有効を示す状態から無効を示す状態へと更新することによって行われる。
　無効化指示を行った後、店舗サーバ１はステップＳ２０９で、会計伝票を印刷させる処理を実行する。ここで印刷される会計伝票には、注文識別情報（この追加注文の例では、「００１０１３００２００２」）を特定可能な二次元バーコードが印刷される。
　なお、ステップＳ２０９の処理は、支払い管理サーバ３が実行するステップＳ３０５の処理とは非同期に行うことが可能である。
＜４－３．支払いに関する流れ＞
　図７を参照して、注文者が支払いを行う際の各処理の一例を説明する。
　注文者自身が持つ携帯電話などのユーザ端末４を用いて支払いを行いたいと考え、ユーザ端末４を用いて会計伝票に印刷された二次元バーコードを読み取るための操作を行うと、ユーザ端末４はステップＳ５０１で、コード情報（本例では二次元バーコード）の読取操作を受け付ける処理を実行し、続くステップＳ５０２で、読取処理を実行する。これにより、ユーザ端末４は二次元バーコードに含まれる注文識別情報を取得することができる。
　次に、ユーザ端末４はステップＳ５０３で、ユーザ（注文者）によって選択（指定）された支払い方法を特定する処理を実行する。この処理は、例えば、画面上に複数の支払い方法を表示し、その中からユーザに選択させることにより実現される。
　ユーザ端末４は、支払い要請送信処理をステップＳ５０４で実行する。
　支払い要請送信処理では、注文識別情報と選択された支払い方法を含む情報が支払い要請として送信される。なお、支払い要請送信処理において、注文識別情報と支払い方法を特定可能な情報に加えて、支払い金額を送信するように構成してもよい。その場合には、コード情報を読み取ることで、ユーザ端末４は支払金額を取得可能とされている。
　ここで、ステップＳ５０３及びステップＳ５０４の各処理について、一例を挙げて説明する。
　ユーザ端末４には、会計伝票などに印刷されたコード情報（例えば二次元バーコード）を用いた支払いを行うための専用のアプリケーションソフトウェア（以降、「端末アプリ」と記載）がインストールされている。
　端末アプリは、ユーザＩＤとパスワードを入力することにより登録会員としての諸操作（即ちログインした状態での諸操作）を行うことが可能とされている。
　ユーザＩＤとパスワードの情報は、支払い管理サーバ３の管理しているＤＢに登録されている。該ＤＢには、他にも、ユーザＩＤごとにクレジットカード情報やポイント情報などが記憶されている。
　クレジットカード情報やポイント情報が支払い管理サーバ３の管理しているＤＢに記憶されていることにより、注文者はログイン状態であれば支払いのたびにクレジットカード情報の入力を行わなくてもよい。これにより、ステップＳ５０４の処理では、例えば、ユーザを特定するためのユーザＩＤとクレジットカードによる支払いが選択されたことを示す情報と注文識別情報のみが送信される。
　従って、クレジットカード情報の送受信が行われないため、個人情報の保護を図ることができる。また、クレジットカード情報の入力を盗み見られる危険性を回避することができる。
　なお、ステップＳ５０３の選択では、ポイントを利用した支払いなどが選択可能とされている。例えば、所定の金額をポイントで支払い、残りの金額をクレジットカードで支払うことも可能とされている。
　なお、読み取った二次元バーコードの画像データをそのままステップＳ５０４で送信することにより、注文識別情報の取得処理をユーザ端末４とは異なる端末（例えば支払い管理サーバ３）で行ってもよい。
　ステップＳ５０４の処理に応じて、支払い管理サーバ３はステップＳ３０６で支払い要請の受信処理を行う。この処理では、受信した情報からユーザＩＤを特定し、選択された支払い方法を特定する処理を行う。また、必要に応じて、ユーザＩＤに紐付けられたポイント情報やクレジットカード情報を取得する処理を行う。
　支払い管理サーバ３はステップＳ３０７で、支払い処理を実行する。図７は、注文金額の少なくとも一部がクレジットカードによって支払われる場合を示している。
　支払い管理サーバ３は、ステップＳ３０７で、カード会社システム５に対して各種の情報を送信することにより承認依頼を送信する。
　ここで送信される各種の情報とは、例えば、クレジットカードによって支払う金額、クレジットカードの情報などである。
　承認依頼を受信したカード会社システム５は、ステップＳ４０１で、承認処理を実行する。承認処理では、例えば、クレジットカードの有効期限のチェック処理、クレジットカードの有効性（使用禁止リストに登録されていないか）確認処理、クレジットカードの利用可能額の確認処理などが実行される。
　カード会社システム５は、ステップＳ４０２で、承認結果を通知する処理を実行する。
　承認処理の結果は、「承認」と「非承認」の何れかとされている。承認結果が「承認」であった場合、支払い管理サーバ３はステップＳ３０８で、支払い完了通知処理を実行する。
　支払い完了通知処理は、店舗サーバ１とユーザ端末４に対して行われる。
　支払い完了通知を受信した店舗サーバ１は、ステップＳ２１０の支払い完了通知受信処理として、注文ＤＢ５１に記憶された注文情報のうち、支払いが完了した注文情報の更新を行う。この更新処理では、例えば、支払いが完了したことを示すフラグを記憶する処理を行う。
　店舗サーバ１が管理する注文ＤＢ５１に記憶された各注文情報において、支払いが完了したことを示すフラグが設けられることにより、注文識別情報ごとに支払いが完了したか否かを判定することが可能となる。これによって、注文金額の支払いを二重に受け取ってしまうことや、未払いのまま注文客が退店してしまう可能性を低減させることができる。
　また、ステップＳ３０８の支払い完了通知を受信したユーザ端末４は、ステップＳ５０５で、支払い完了表示処理を実行する。この処理では、例えば、「支払いが完了しました」などの通知がユーザ端末４の画面上に表示される。
　一方、ステップＳ４０１の承認処理の結果が「非承認」の場合は、続くステップＳ３０８の処理は実行されず、代わりに、支払い管理サーバ３から店舗サーバ１やユーザ端末４に支払いを完了できなかった旨を示す情報が送信される。なお、支払い管理サーバ３は、支払いを完了できなかった旨の通知を店舗サーバ１に対して行わなくてもよい。
　支払いが完了できなかった旨を示す情報を受信したユーザ端末４は、画面上などに「支払いができませんでした」などの文言を表示させる処理を行う。
　また、指定した支払い方法による支払いができなかった場合には、注文者は、別の支払い方法を利用するか、或いは、現金による支払いを行う。
　なお、注文者が支払い方法として電子マネーを利用することを選択した場合、ステップＳ４０１及びステップＳ４０２の処理に替わる別の処理が電子マネーを管理する電子マネーシステムによって実行される。
　具体的に例えば、有効なユーザＩＤであるか否かを判定する処理や、ポイント残高が足りているか否かを判定する処理や、ポイントから支払い金額分を減算させる処理などをステップＳ４０１やステップＳ４０２の処理の替わりに実行する。
　なお、図５、図６及び図７の各処理のように、ユーザ端末４と店舗サーバ１間の通信は不要とされている。即ち、店舗サーバ１は、様々なユーザ端末４を想定した処理を実行する必要は無いため、店舗サーバ１に実装されるプログラムを簡易化させることができる。従って、店舗サーバ１を構築するためのコストを削減することが可能となる。
　なお、支払いを完了させた注文者が改めて追加の注文を行う場合について、図６及び図７を参照して説明する。
　注文端末７は、店員等の操作に基づいて、ステップＳ１０４の注文識別情報生成用の情報入力処理、ステップＳ１０５の追加注文情報入力処理、ステップＳ１０６の注文情報等送信処理を行うことにより、追加注文の入力を受け付け店舗サーバ１に送信する処理を行う。なお、それまでの注文で未払いのものが無いことから、図５に示すように新規の来店客として処理してもよい。その場合には、例えば新たな注文者識別情報が含まれた注文識別情報を生成してもよい。例えば、店舗コードが「００１」とされ、テーブルコードが「０１３」とされ、来店コードが「００３」とされ、初回の注文であることを示す「００１」が付加された「００１０１３００３００１」を新たな注文識別情報としてもよい。
　店舗サーバ１は、ステップＳ２０５の注文情報等受信処理、ステップＳ２０６の注文識別情報と金額情報を取得する処理、ステップＳ２０７の注文識別情報と金額情報を送信する処理を実行する。
　ステップＳ２０７で支払い管理サーバ３へ送信する金額情報は、支払いを一旦完了させた後に行われた追加注文を全て合計した金額とされる。
　ステップＳ２０７の処理を実行した、店舗サーバ１はステップＳ２０８の無効化指示処理を実行する。但し、無効化する未払いの支払い用情報が存在しないため、ステップＳ２０８の処理を実行せずにステップＳ２０９の処理に移行してもよい。
　支払い管理サーバ３は、ステップＳ３０３の注文識別情報と金額情報を受信する処理、ステップＳ３０４の記憶処理を実行した後、ステップＳ３０５の無効化処理を実行する。
　但し、店舗サーバ１がステップＳ２０８の処理を実行しなかった場合には、無効化指示を受信できないため、ステップＳ３０５の処理は実行されない。また、無効化指示を受信したとしても、本例においては無効化すべき支払い用情報が存在しないため、ステップＳ３０５の無効化処理では、支払い用ＤＢ６１に記憶された各レコードから無効化対象のレコードを検索し、該対象のレコードが支払い済みとなっていることを確認する処理（或いは対象のレコードが存在しないことを確認する処理）が実行される。
　次に、図７を参照して支払いに関する各処理について説明する。
　ユーザ端末４は、注文者の操作に応じて、ステップＳ５０１のコード情報読取操作受け付け処理、ステップＳ５０２の読取処理、ステップＳ５０３の支払い方法選択処理、ステップＳ５０４の支払い要請送信処理を実行する。これによって、支払い要請が支払い管理サーバ３に送信される。
　支払い管理サーバ３は、支払い要請をステップＳ３０６で受信した後、ステップＳ３０７で支払い処理を実行する。このときにカード会社システム５に送信される金額情報としては、前回の支払いが完了した後に行った追加注文に関する合計金額とされる。
　例えば、初回の注文で１０００円分のメニューを注文し、追加で５００円分のメニューを注文した後、支払い処理によって１５００円の支払いを行ったとする。その後に追加注文として、３００円のメニューを注文した場合においては、ステップＳ３０７の支払い処理でカード会社システム５に送信される金額情報は３００円となる。
　カード会社システム５は、ステップＳ４０１の承認処理とステップＳ４０２の承認結果通知処理を行う。これにより、支払い管理サーバ３へ承認結果が通知される。
　支払い管理サーバ３は、ステップＳ３０８で支払い完了通知処理を実行する。これに応じて、ユーザ端末４では支払い完了表示処理（ステップＳ５０５）が実行され、店舗サーバ１では支払い完了通知受信処理（ステップＳ２１０）が実行される。
　ステップＳ２１０の支払い完了通知処理では、支払いを完了させた後に同一の注文者による追加の注文が行われた場合において、該追加注文の注文情報のみが未払いの注文情報として注文ＤＢ５１に記憶される。これによって、支払い済みの注文情報と明確に区別可能とされ、支払い済みの注文情報に係る支払いが再度行われてしまうことが防止される。
　なお、図５、図６、図７の各図においては、情報を送受信するたびに行われる受信確認のためのやりとり（ＡＣＫなど）が実行されることがあるが、そのような処理の図示は省略している。
＜５．各処理＞
　図５、図６、図７の各図で説明した各装置の処理の流れを実現するために、店舗サーバ１、支払い管理サーバ３及びユーザ端末４が実行する処理の一例について、添付図を参照して説明する。
＜５－１．注文情報受付処理＞
　店舗サーバ１が実行する注文情報受付処理の一例について、図８を参照して説明する。
　なお、図８に示す一連の処理を実行することにより、図５のステップＳ２０１からステップＳ２０４の各処理、図６のステップＳ２０５からステップＳ２０９の各処理を実現することができる。
　店舗サーバ１はステップＳ６０１で、注文端末７から注文情報を受信したか否かを判定する。注文情報を受信していない場合は、店舗サーバ１は再度ステップＳ６０１を実行する。なお、注文情報を受信したことをトリガとして、ステップＳ６０２以降の各処理が実行されるように店舗サーバ１を構成してもよい。
　注文端末７から注文情報を受信したと判定した場合、店舗サーバ１はステップＳ６０２で、受信した注文情報からテーブルコードを取得する。
　店舗サーバ１はステップＳ６０３で、受信した注文情報が新規注文に係るものであるか否かを判定する。新規注文であるか否かの情報は、注文端末７から受信した注文情報から取得可能とされている。
　新規注文であった場合、店舗サーバ１はステップＳ６０４及びステップＳ６０５の各処理を実行せずにステップＳ６０６の処理へ移行する。
　一方、新規注文でなかった場合、即ち、追加注文であった場合、店舗サーバ１はステップＳ６０４において、前回の注文情報を注文ＤＢ５１から取得する処理を行う。
　なお、ステップＳ６０４の処理を実行している段階においては、注文ＤＢ５１に記憶されている情報は、今回注文端末７から受信した注文情報を除いて既に受信済みの注文情報が記憶されている。今回受信した注文情報は、後述のステップＳ６１０の処理で注文ＤＢ５１に記憶される。
　従って、前回の注文情報とは、今回の注文者が行った注文であって、注文ＤＢ５１に記憶されている最も新しい注文についての情報である。例えば、今回の注文が来店してから２回目に行った注文であった場合、この時点で注文ＤＢ５１に記憶されている注文情報は初回の注文についての情報のみであるため、ステップＳ６０４の処理では、初回の注文についての注文情報を取得する。
　ステップＳ６０４の処理では、注文者識別情報に基づく検索処理を行う。具体的には、店舗コード「００１」、テーブルコード「０１３」、来店コード「００２」を含むレコード、即ち、今回の注文を行った注文者を示す注文者識別情報が含まれるレコードを検索する。
　なお、レコードの検索に用いる情報のうち、店舗コードは、店舗サーバ１が管理している情報である。また、テーブルコード及び来店コードは、注文端末７から受信した注文情報に含まれている。
　ここで、注文者識別情報と注文識別情報の具体的な構成例について、図９を参照して説明する。
　図９Ａは、店舗サーバ１が管理する注文ＤＢ５１に記憶される情報の一例を一部抜粋したものを示している。
　一つのレコードを特定可能なレコードＮｏ．ごとに、店舗コード、テーブルコード、来店コード、注文回数、注文内容、合計金額、支払い済みフラグがそれぞれ記憶されている。
　店舗コード、テーブルコード、来店コードについては前述の通りである。
　注文回数は、初回が００１とされ、以降追加注文を受け付けるたびに１ずつ加算されていく。注文内容は、メニューＮｏ．と注文個数を一組とした情報が複数組記憶されている。図９Ａに示すレコードは、メニューＮｏ．が「０１９」と「０３１」とされたメニューを一つずつと、メニューＮｏ．が「０２４」とされたメニューを二つ含む注文を受け付けたことを示している。
　図９Ａに示すように、注文者識別情報は、店舗コードとテーブルコードと来店コードの三つの情報を含んで構成されている。即ち、店舗コードとテーブルコードと来店コードによって、一意に注文者を特定可能である。
　また、注文識別情報は、店舗コードとテーブルコードと来店コードに加えて、注文回数の情報を含んで構成されている。即ち、店舗コードとテーブルコードと来店コードと注文回数によって、一意に注文情報を特定可能である。
　図８の説明に戻る。ステップＳ６０４の処理では、店舗コードが「００１」、テーブルコードが「０１３」、来店コードが「００２」で特定可能な注文者が行った注文のうち、前回のもの、即ち、注文回数が最も大きいものを注文ＤＢ５１から取得する。従って、例えば、前回の注文情報として、注文回数が「００１」とされたレコードＮｏ．「０００００１」のレコードを取得する。
　次に、店舗サーバ１はステップＳ６０５で、注文回数を取得する。本例では、「００１」が取得される。
　店舗サーバ１はステップＳ６０６で、今回の注文情報についての注文識別情報を生成する処理を行う。具体的には、店舗コードとテーブルコードと来店コードは取得したレコードをそのまま用いると共に、注文回数を取得した値に１を加算した「００２」として算出する。
　なお、今回の注文が新規注文であるために、ステップＳ６０４及びステップＳ６０５の処理を行わずにステップＳ６０６の処理を実行する場合には、今回の注文についての注文回数を「００１」と設定する。
　店舗サーバ１はステップＳ６０６で、注文識別情報を生成する。注文識別情報は、例えば、店舗コード、テーブルコード、来店コード、注文回数から生成される情報であって、注文者が行った注文を一意に特定可能な情報である。図９Ａから理解されるように、一つの注文者識別情報について、複数の注文識別情報が対応付けられていてもよい。
　店舗サーバ１はステップＳ６０７で、注文を受け付けたメニューごとの単価情報を取得する。単価情報について、図９Ｂを参照して説明する。
　単価情報は、店舗が販売している商品（メニュー）ごとの単価を記憶したＤＢに記憶されている。このＤＢは、店舗サーバ１が管理しているものである。ＤＢに記憶された情報の一例を示したものが図９Ｂである。図示するように、メニューを一意に特定可能なメニューＮｏ．ごとに単価情報が紐付けられて記憶されている。
　ステップＳ６０７で取得する単価情報は、注文端末７から受信した注文情報に含まれるメニューＮｏ．についての単価情報のみである。前回の注文（図９ＡにおけるレコードＮｏ．が「０００００１」とされた注文情報）を例に挙げると、メニューＮｏ．が「０２４」、「０３１」、「０１９」とされたメニューの単価情報を少なくとも取得する。
　店舗サーバ１はステップＳ６０８で、注文情報から注文数を取得する。前回の注文を例に挙げると、メニューＮｏ．が「０２４」とされたメニューについては２が、メニューＮｏ．が「０３１」とされたメニューについては１が、メニューＮｏ．が「０１９」とされたメニューについては１が、注文数として取得される。
　店舗サーバ１はステップＳ６０９で、注文合計金額を算出する。注文合計金額は、ステップＳ６０７で取得した単価情報とステップＳ６０８で取得した注文数から算出可能である。
　店舗サーバ１はステップＳ６１０で、今回の注文情報を注文ＤＢ５１に記憶する処理を行う。例えば、レコードＮｏ．が「０００００２」、店舗コードが「００１」、テーブルコードが「０１３」、来店コードが「００２」、注文回数が「００２」とされ、注文内容に注文端末７から受信した情報が格納され、ステップＳ６０９で算出した注文合計金額が合計金額に格納され、支払い済みフラグが「Ｆａｌｓｅ」に設定されたレコードが注文ＤＢ５１に記憶される。
　なお、支払い済みフラグは、注文についての支払いがなされた場合に「Ｔｒｕｅ」へと変更される。従って、注文ＤＢ５１に新たな注文情報が記憶される場合には「Ｆａｌｓｅ」が設定されている。
　店舗サーバ１は、ステップＳ６１１で、支払い用情報を支払い管理サーバ３へ送信する処理を行う。この処理では、例えば、注文識別情報と未払いの注文の合計金額を少なくとも含む情報が支払い管理サーバ３へ送信される。
　なお、未払いの注文の合計金額とは、複数の注文情報の合計金額を加算したものとなり得る。
　例えば、店舗コード「００１」、テーブルコード「０１３」、来店コード「００２」で特定可能な注文者についての未払いの注文情報の合計金額は、前回の注文情報（初回の注文情報であり、レコードＮｏ．が「０００００１」とされたもの）の合計金額（即ち「２４６０円」）と、ステップＳ６１０で新たに記憶された注文情報についての合計金額（例えば「５００円」）を合算した「２９６０円」とされる。
　なお、支払い済みのレコードと未払いのレコードが複数存在する場合には、未払いの注文情報についての合計金額を合算した金額とされ、支払い済みのレコードについての金額は除外される。
　店舗サーバ１はステップＳ６１２で、今回の注文が新規注文であるか否かを判定する。この判定処理は、ステップＳ６０３の処理と同様の判定処理である。
　今回の注文が新規注文である場合は、店舗サーバ１はステップＳ６１３の処理を実行せずにステップＳ６１４の処理へと以降する。
　一方、今回の注文が新規注文でない場合、即ち追加注文である場合、店舗サーバ１はステップＳ６１３の処理を実行する。
　ステップＳ６１３では、支払い管理サーバ３に対する無効化指示を送信する処理を行う。
　無効化指示の送信では、少なくとも無効化対象の支払い用情報を特定可能な情報を送信する。無効化対象の支払い用情報を特定可能な情報とは、例えば、注文識別情報や注文者識別情報である。
　本例においては、無効化する注文識別情報として、「００１０１３００２００１」が送信される。
　ステップＳ６１３を実行した後、或いはステップＳ６１２で今回の注文が新規注文であると判定した後、店舗サーバ１はステップＳ６１４において、会計伝票の印刷を指示する処理を行う。これにより、会計伝票が印刷される。なお、上述したように会計伝票には、注文識別情報を特定可能なコード情報が印刷される。
　ステップＳ６１４を実行した後、店舗サーバ１は再びステップＳ６０１の処理へと戻る。
＜５－２．支払い用情報受信処理＞
　支払い管理サーバ３が実行する支払い用情報受信処理の一例について、図１０を参照して説明する。
　なお、図１０に示す一連の処理を実行することにより、図５のステップＳ３０１とステップＳ３０２、図６のステップＳ３０３とステップＳ３０４の各処理を実現することができる。
　支払い管理サーバ３は、ステップＳ７０１で、店舗サーバから支払い用情報を受信したか否かを判定する処理を行う。受信していないと判定した場合、支払い管理サーバ３はステップＳ７０１の処理を再度行う。なお、支払い用情報の受信をトリガとしてステップＳ７０２及びステップＳ７０３の処理が実行されるように支払い管理サーバ３を構成してもよい。
　支払い用情報を受信したと判定した支払い管理サーバ３は、ステップＳ７０２で、受信した情報から注文識別情報と金額情報を取得する。
　次に、支払い管理サーバ３はステップＳ７０３で、取得した注文識別情報と金額情報を紐付けて支払い用ＤＢ６１に記憶する処理を行う。
　ここで、支払い用ＤＢ６１に記憶される情報の一例について、図１１を参照して説明する。
　支払い用ＤＢ６１に記憶される支払い用情報は、一つのレコードを一意に特定可能なレコードＮｏ．に、注文識別情報と金額情報と有効フラグと支払い済みフラグが紐付けられている。
　注文識別情報は、例えば、店舗コード「００１」、テーブルコード「０１３」、来店コード「００２」と注文回数「００１」から生成された情報であり、注文者が注文を行うたびに付与される情報である。金額情報は、注文者が支払いを行う場合に支払うべき金額の合計を示している。即ち、複数回分の注文情報の合計金額の合算であることもあり得る。
　有効フラグは、当該レコードに対する支払いが有効であるか無効であるかを表すフラグである。図１１に示す状態は、有効フラグは「Ｔｒｕｅ」とされており、該レコードについての支払いを行うことが可能な状態とされている。
　なお、前述のように５００円の追加注文を行い、合計金額が２９６０円となった場合には、該注文情報に係る支払い用情報を店舗サーバ１から受信することにより、ステップＳ７０３において、新たにレコードＮｏ．が「００２」とされ、注文識別情報が「００１０１３００２００２」とされ、金額情報が「２９６０」とされ、有効フラグが「Ｔｒｕｅ」とされ、支払い済みフラグが「Ｆａｌｓｅ」とされたレコードが支払い用ＤＢ６１に記憶される。
　また、支払い用ＤＢ６１に当該情報が記憶された時点では、レコードＮｏ．が「００１」とされたレコードと「００２」とされたレコードの双方の有効フラグが共に「Ｔｒｕｅ」とされている。
　ステップＳ７０３を実行した後、支払い管理サーバ３は再びステップＳ７０１の処理へと戻る。
＜５－３．無効化指示受信処理＞
　支払い管理サーバ３が実行する無効化指示受信処理の一例について、図１２を参照して説明する。
　なお、図１２に示す一連の処理を実行することにより、図６のステップＳ３０５の処理を実現することができる。
　支払い管理サーバ３はステップＳ７１１において、店舗サーバ３から無効化指示を受信したか否かを判定する。無効化指示を受信していない場合、支払い管理サーバ３は再度ステップＳ７１１の処理を実行する。なお、無効化指示の受信をトリガとしてステップＳ７１２及びステップＳ７１３の処理が実行されるように支払い管理サーバ３を構成してもよい。
　無効化指示を受信したと判定した場合、支払い管理サーバ３はステップＳ７１２において、受信した情報から無効化対象とされた支払い用情報を特定するための注文識別情報を取得する処理を行う。
　例えば、注文識別情報として「００１０１３００２００１」を取得する。
　次に、支払い管理サーバ３はステップＳ７１３において、指定された注文識別情報に係る支払い用情報の有効フラグを「Ｆａｌｓｅ」に変更する処理を行う。この処理は、無効化フラグを「ＯＮ」にすることと同義である。
　先の例でいうと、支払い用ＤＢ６１にレコードＮｏ．が「００２」とされたレコードが記憶された時点では、レコードＮｏ．が「００１」とされたレコードと「００２」とされたレコードの双方の有効フラグが共に「Ｔｒｕｅ」とされていたが、ステップＳ７１３の処理を実行することにより、レコードＮｏ．が「００１」とされたレコードの有効フラグが「Ｆａｌｓｅ」に設定される。即ち、レコードＮｏ．が「００２」とされたレコードの有効フラグのみが「Ｔｒｕｅ」とされるため、誤って初回の注文情報に基づく安価な金額に基づいて支払いがなされてしまうことが防止される。
　ステップＳ７１３を実行した後、支払い管理サーバ３は再びステップＳ７１１の処理へ
＜５－４．端末アプリ起動処理＞
　ユーザ端末４が実行する端末アプリ起動処理の一例について、図１３を参照して説明する。なお、図１３に示す一連の処理は、ユーザが自身の使用するユーザ端末４において支払いを行うための専用の端末アプリを起動させる操作を行ったことに応じて、ユーザ端末４が実行する処理である。
　ユーザ端末４が図１３に示す一連の処理を実行することにより、図７のステップＳ５０１からステップＳ５０５の各処理を実現することができる。
　端末アプリの起動操作を検出したユーザ端末４は、ステップＳ８０１でログイン状態か否かを判定する。ログイン状態でない場合、ユーザ端末４はステップＳ８０２で、ログイン要求をユーザに対して行う。具体的には画面上にログインを行うためのユーザＩＤ入力欄とログインパスワード入力欄と、認証処理の実行を開始させるためのログインボタンを表示させる。
　ユーザがユーザＩＤとログインパスワードを入力してログインボタンを押下すると、ユーザ端末４はステップＳ８０３で、ログイン認証処理を実行する。具体的には、入力されたユーザＩＤとパスワードを暗号化して支払い管理サーバ３へ送信し、認証処理を実行させると共に、認証結果の受信及び表示を行う。
　認証結果が「不可」であった場合には、ユーザ端末４は再度ステップＳ８０２のログイン要求を行う。
　ログイン認証処理を実行した後、ユーザ端末４はステップＳ８０４で、読み取り操作指示を受け付けたか否かを判定する。読み取り操作の指示があるまでステップＳ８０４で待機する。
　ユーザが読み取り操作を指示するための操作を行うと、ユーザ端末４はステップＳ８０５で、ユーザ端末４が備えるカメラを起動させる処理を行う。
　続いて、ユーザのカメラ操作に応じて、ユーザ端末４はステップＳ８０６でコード情報の読み取りを行う。コード情報は、先述したように、少なくとも注文識別情報を含むものである。
　続いて、ユーザ端末４はステップＳ８０７において、支払い方法選択画面を提示する処理を行う。例えば、ユーザ端末４は、画面上に選択可能な複数の支払い方法を表示させ、ユーザに選択を促す旨を表示する処理を行う。
　ユーザが支払い方法を選択すると、ユーザ端末４はステップＳ８０８において、支払い方法の選択操作を受け付ける処理を実行し、ステップＳ８０９において、支払い要請を支払い管理サーバ３へ送信する処理を実行する。
　支払い要請は、例えば、ユーザＩＤなど使用するユーザを特定するための情報と、ステップＳ８０６で読み取った注文識別情報を含むコード情報と、ユーザによって選択された支払い方法を特定するための情報を送信する処理である。
　次に、ユーザ端末４はステップＳ８１０で支払い要請に対する通知を受信したか否かを判定する。支払い要請に対する通知とは、例えば、支払いが完了したことを示す「支払い完了通知」や何らかの理由で支払いができなかったことを示す「支払い不能通知」である。
　支払い完了通知を受信した場合、ユーザ端末４はステップＳ８１１の通知内容を表示させる処理として、支払い完了表示をユーザ端末４の画面上に表示させる処理を実行する。
　支払い要請に対する通知を受信するまで、ユーザ端末４はステップＳ８１０の処理で待機する。
　なお、ステップＳ８１０で支払い不能通知を受信した場合、ユーザ端末４はステップＳ８１１の通知内容表示処理として、支払い不能表示を画面上に表示させる処理を実行する。
＜５－５．支払い要請受信処理＞
　支払い管理サーバ３が実行する支払い要請受信処理の一例について、図１４を参照して説明する。
　なお、図１４に示す一連の処理を実行することにより、図７のステップＳ３０６、ステップＳ３０７、ステップＳ３０８の各処理を実現することができる。
　支払い管理サーバ３はステップＳ７２１において、ユーザ端末４から支払い要請を受信したか否かを判定する。支払い要請を受信していない場合、支払い管理サーバ３は再度ステップＳ７２１の処理を実行する。なお、支払い要請の受信をトリガとしてステップＳ７２２からステップＳ７２７の各処理が実行されるように支払い管理サーバ３を構成してもよい。
　支払い要請を受信したと判定した支払い管理サーバ３は、ステップＳ７２２において、ユーザＩＤを取得する処理を実行する。
　続いて、支払い管理サーバ３はステップＳ７２３において、支払い方法を特定する処理を行う。この処理では、支払い要請として受信した情報から支払い方法を特定するための情報を取得する処理である。
　支払い管理サーバ３はステップＳ７２４で、支払い方法に応じた情報をＤＢから取得する処理を行う。図１４に示す例は、ユーザがクレジットカードによる支払いを選択した場合を例示している。そのため、ステップＳ７２４では、クレジットカードに関する情報をＤＢから取得する。なお、支払い方法がポイントを使用するものである場合には、ポイント情報をＤＢから取得する。また、支払い方法が電子マネーを使用するものである場合には、電子マネーに関する情報をＤＢから取得する。
　支払い管理サーバ３はステップＳ７２５において、利用額情報の取得を行う。この処理は、支払い要請として受信した情報から注文識別情報を取得し、該注文識別情報に基づいて支払い用ＤＢ６１から金額情報（図１１参照）を取得する処理である。
　支払い管理サーバ３はステップＳ７２６において、利用額の枠を確保する依頼をカード会社システム５に対して行う。これによって、カード会社システム５では、指定されたクレジットカードの有効期限の確認や利用可否の確認等が行われる。
　支払い管理サーバ３はステップＳ７２７において、枠確保結果を受信するまで待機する。
　枠確保結果を受信した場合、支払い管理サーバ３はステップＳ７２８で支払い完了通知または支払い不能通知の送信を行う。これにより、支払い完了通知または支払い不能通知がユーザ端末４及び店舗サーバ１に対して送信される。
　なお、店舗サーバ１では、支払い完了通知を受信することにより、注文ＤＢ５１に記憶された対象のレコードの支払い済みフラグを「Ｆａｌｓｅ」から「Ｔｒｕｅ」に変更する（図９Ａ参照）。
　なお、支払い方法として電子マネーによる支払いが指定されている場合には、ステップＳ７２４において電子マネーに関する情報を支払い管理サーバ３が管理するＤＢから取得することを記載したが、それ以外の場合も考えられる。例えば、電子マネーシステム６が管理するＤＢから電子マネーに関する情報（例えば残額等）を取得する処理を支払い管理サーバ３が実行してもよい。その場合には、電子マネーによる支払いに関する所定の処理と共に電子マネーシステム６に電子マネーに関する情報の取得を依頼してもよい。また、その際には、ユーザ端末４と電子マネーシステム６の間でログインに関する情報の送受信等が行われてもよい。
＜６．第２の実施の形態における大まかな処理の流れ＞
　第２の実施の形態では、前述の実施の形態（以降、「第１の実施の形態」と記載）に対して、印刷指示を行う処理を支払い管理サーバ３が実行すること、及び、無効化指示を店舗サーバ１が実行しないことが異なる。
　以下においては、図２から図１４の各図を参照して説明した第１の実施の形態と異なる部分について説明を行うものとし、第１の実施の形態と同様の部分については、説明を簡略化または省略する。
　先ず、第２の実施の形態に係る店舗サーバ１Ａと支払い管理サーバ３Ａの構成について説明する。
　第２の実施の形態に係る店舗サーバ１Ａは、図１５に示すように、情報取得部１ａ、送信部１ｂ、印刷制御部１ｃ、受信部１ｅを備えている。即ち、第１の実施の形態の店舗サーバ１と比較して無効化指示部１ｄを備えていないことが特徴である。
　第２の実施の形態に係る支払い管理サーバ３Ａは、図１６に示すように、支払い用情報受信部３ａ、記憶処理部３ｂ、支払い要請受信部３ｃ、支払い処理部３ｄ、無効化処理部３ｅ、印刷指示部３ｆを備えている。即ち、第１の実施の形態の支払い管理サーバ３と比較して、印刷指示部３ｆを備えていることが特徴である。
　即ち、印刷物へのコード情報の印刷は、支払い管理サーバ３Ａが店舗サーバ１Ａへ印刷要求を送信することにより、或いは、支払い管理サーバ３Ａが店舗で管理する印刷機器に対して印刷要求を送信することにより行われる。
　また、支払い用情報を無効化する処理は、新たな支払い用情報を受信した管理サーバ３Ａが支払いの対象外となる古い支払い用情報を特定した上で行う。この処理は、店舗サーバ１Ａから無効化指示を受信することなく実行可能とされる。
＜６－１．第２の実施の形態における最初の注文に関する流れ＞　
　第２の実施の形態における最初の注文に関する各情報処理装置の処理の流れの概要について、図１７を参照して説明する。
　来店した来店客をテーブルに通し、店員が注文端末７を用いて注文識別情報を生成するための情報入力、及び、注文情報の入力を実行したことに応じて、注文端末７はステップＳ１０１及びステップＳ１０２の処理を実行した後、ステップＳ１０３において注文情報等の送信処理を実行する。
　注文情報等を受信（ステップＳ２０１）した店舗サーバ１Ａは、ステップＳ２０２で注文識別情報と注文についての支払い金額の情報を取得し、ステップＳ２０３で注文識別情報と金額情報の送信を行う。
　注文識別情報と金額情報を受信（ステップＳ３０１）した支払い管理サーバ３Ａは、ステップＳ３０９で印刷指示を店舗サーバ１Ａに送信する処理を実行した後、ステップＳ３０２で注文識別情報と金額情報の記憶処理を行う。
　印刷指示を受信した店舗サーバ１Ａは、ステップＳ２１１において、会計伝票の印刷処理を実行する。この処理は、例えば、店舗サーバ１Ａが印刷機器に対して印刷指示を送信する処理である。
　即ち、第１の実施の形態と異なり、店舗サーバ１Ａは、支払い管理サーバ３Ａから印刷指示を受信することにより、会計伝票の印刷処理を実行する。
　なお、ステップＳ３０９の処理とステップＳ３０２の処理は、何れの処理を先に実行してもよい。
　また、ステップＳ３０９の処理において、支払い管理サーバ３Ａは店舗が管理するネットワークに属する店舗サーバ１Ａ以外の情報処理装置に印刷指示を送信することにより、会計伝票の印刷を実現してもよい。
＜６－２．第２の実施の形態における追加の注文の流れ＞
　第２の実施の形態における追加注文に関する各情報処理装置の処理の流れの概要について、図１８を参照して説明する。
　店員が注文端末７を用いて追加注文に係る各種の情報を入力したことに応じて、注文端末７ではステップＳ１０４，ステップＳ１０５，ステップＳ１０６の各処理が実行される。
　注文情報等を受信した（ステップＳ２０５）店舗サーバ１Ａは、ステップＳ２０６で注文識別情報と注文についての支払い金額の情報を取得し、ステップＳ２０７で注文識別情報と金額情報の送信を行う。
　注文識別情報と金額情報を受信（ステップＳ３０３）した支払い管理サーバ３Ａは、ステップＳ３１０で印刷指示を店舗サーバ１Ａに送信する処理を実行した後、ステップＳ３０４で注文識別情報と金額情報の記憶処理を行う。
　印刷指示を受信した店舗サーバ１Ａは、ステップＳ２１２で会計伝票の印刷処理を実行する。
　支払い管理サーバ３Ａは、ステップＳ３１１で無効化処理を実行する。
　無効化処理は、例えば、注文識別情報を用いた処理を行う。具体的には、同一の注文者がそれ以前に行った注文を支払い用ＤＢ６１から検索し、該当するレコードを無効化する処理を行う。即ち、支払い用ＤＢ６１に記憶された各レコードのうち、ステップＳ２０５で受信した注文情報が有する注文者識別情報と同一の注文者識別情報を有するレコード、換言すれば同一の店舗コードと同一のテーブルコードと同一の来店コードから成る注文者識別情報を有するレコードを無効化対象として特定する。そして、支払い管理サーバ３Ａは、特定された対象のレコードの有効フラグに「Ｆａｌｓｅ」を設定する処理を実行する。
　なお、この無効化処理においては、同一の注文者識別情報を有するレコードであっても、既に支払い済みとされているレコード、即ち支払い済みフラグが「Ｔｒｕｅ」とされているレコードは、無効化対象としない。もちろん、支払い済みフラグによらず、該当するレコードの有効フラグに「Ｆａｌｓｅ」を設定してもよい。
　第２の実施の形態における無効化処理では、第１の実施の形態のものと異なり、店舗サーバ１Ａから無効化指示を受信することなく支払い管理サーバ３Ａが無効化処理を実行する。即ち、店舗サーバ１Ａと支払い管理サーバ３Ａ間の情報の送受信が省略されるため、双方の情報処理装置の処理負担の軽減を図ることができる。
　なお、第２の実施の形態における支払いに関する流れについては、図７に示す第１の実施の形態のものと同様であるため、図示及び説明を省略する。
＜７．第２の実施の形態における各処理＞
　図１７、図１８、図７の各図で説明した各装置の処理の流れを実現するために、店舗サーバ１Ａ、支払い管理サーバ３Ａ及びユーザ端末４が実行する処理の一例について、添付図を参照して説明する。
＜７－１．第２の実施の形態における注文情報受付処理＞
　第２の実施の形態における注文情報受付処理の一例について、図１９を参照して説明する。なお、第１の実施の形態における注文情報受付処理（図８）と同様の処理については、同一の符号を付し説明を適宜省略する。
　店舗サーバ１Ａは、ステップＳ６０１で注文端末７から注文情報を受信したか否かを判定し、受信していた場合はステップＳ６０２からステップＳ６０６の各処理を実行することにより、注文識別情報の生成を行う。
　また、ステップＳ６０７からステップＳ６０９の各処理を店舗サーバ１Ａが実行することにより、今回受信した注文情報に係る金額（注文合計金額）の算出を行う。
　更に、店舗サーバ１Ａは、ステップＳ６１０で注文情報の記憶処理を行い、ステップＳ６１１で支払い用情報を支払い管理サーバ３Ａに送信する処理を行う。
　次に、店舗サーバ１Ａは、会計伝票の印刷を印刷機器に指示する代わりに、ステップＳ６２１で支払い管理サーバ３Ａから印刷指示を受信したか否かを判定する。印刷指示を受信するまで店舗サーバ１ＡはステップＳ６２１で待機する。
　印刷指示の受信を確認した店舗サーバ１Ａは、ステップＳ６２２で会計伝票の印刷処理を実行する。この処理では、例えば、印刷機器に対して印刷指示の送信を行う。
　店舗サーバ１Ａが支払い管理サーバ３Ａから印刷指示を受信するまで待機することにより、注文管理サーバ３Ａが注文識別情報と金額情報を正常に受信してから印刷処理が実行されるため、ユーザ端末４を用いた支払い処理を行う際に支払い管理サーバ３Ａが注文情報を受信しておらず支払い処理が行えないといった不具合を回避することができ、確実な支払い処理を実現することができる。
＜７－２．支払い用情報受信処理＞
　第２の実施の形態の支払い用情報受信処理の一例について、図２０を参照して説明する。なお、第２の実施の形態の支払い用情報受信処理で行う各処理は、第１の実施の形態における支払い用情報受信処理（図１０）と無効化指示受信処理（図１２）で行った各処理に相当する。
　支払い管理サーバ３Ａは、ステップＳ７０１で支払い用情報の受信を確認し、ステップＳ７０２で注文識別情報と金額情報を取得し、ステップＳ７０３で記憶処理を実行する。
　支払い管理サーバ３Ａは、ステップＳ７３１において、印刷指示を店舗サーバ１Ａに送信する処理を実行する。この処理は、前述したように、店舗が管理するネットワークに属する店舗サーバ１Ａ以外の情報処理装置に対する送信処理であってもよい。
　続いて、支払い管理サーバ３Ａは、ステップＳ７１２で、注文識別情報の取得を行い、ステップＳ７３２で無効化対象のレコードを検索する処理を実行する。該検索処理では、ステップＳ７１２で取得した注文識別情報（或いは注文識別情報に含まれる注文者識別情報）が利用される。
　支払い管理サーバ３Ａは、ステップＳ７３３において、無効化対象のレコードが検索されたか否かを判定する。
　無効化対象のレコードが検索された場合、支払い管理サーバ３ＡはステップＳ７１３で、対象のレコードについての無効化フラグを「ＯＮ」に設定する。これは、前述のように、有効フラグを「Ｆａｌｓｅ」に設定することによって実現してもよい。
　一方、無効化対象のレコードが検索されなかった場合、支払い管理サーバ３Ａは再びステップＳ７０１の処理を実行する。
＜８．第３の実施の形態の大まかな流れ＞
　前述の第１の実施の形態及び第２の実施の形態と比較して、第３の実施の形態では、注文者の注文に応じて図５のステップＳ２０３で店舗サーバ１から支払い管理サーバ３へ送信される情報が異なる。具体的には、第１の実施の形態及び第２の実施の形態では、注文識別情報と金額情報の送信を行っていたが、第３の実施の形態では、金額情報の送信を行わない点で異なる。
　具体的な処理の流れについて、図２１を参照して説明する。
　店舗サーバ１が注文情報を注文端末７から受信するまで、即ちステップＳ２０１の処理を実行するまでは、他の実施の形態と同様の処理が実行されるため、説明を省略する。
　注文者の注文に応じた注文情報等を受信した店舗サーバ１は、ステップＳ２１３において、受信した情報から注文識別情報を取得する処理を実行し、続くステップＳ２１４において、該注文識別情報を支払い管理サーバ３へ送信する処理を実行する。即ち、ここでは金額情報の送信は行われない。
　これに応じて、支払い管理サーバ３は、ステップ３１２で注文識別情報の受信を行い、ステップＳ３０２で該注文識別情報の記憶処理を行う。
　これにより、注文者の注文を識別可能な情報が記憶される。
　注文者が追加注文を行ったことにより生じる図６の各処理については、図２１に示す各処理と同様の処理であるため、説明を省略する。なお、ステップＳ３０５の無効化処理については、フラグなどを用いて該当する注文識別情報を無効化する処理とされる。
　次に、注文者がユーザ端末４を用いて注文代金の支払いを行う場合について、いくつかの例を説明する。
　一つ目の例について、図７を参照して説明する。
　ユーザ端末４は、ステップＳ５０１からステップＳ５０３の処理を実行することにより、コード情報読取操作の受け付け、読取処理及び支払い方法選択処理を実行する。次に、ユーザ端末４はステップＳ５０４において、支払い要請送信処理を実行する。
　本実施の形態では、支払い管理サーバ３は注文金額の管理は行っていない。即ち、ステップＳ５０４の処理を実行する時点においては、注文識別情報によって特定可能な注文の注文金額を支払い管理サーバ３は把握していない。
　そこで、ステップＳ５０４の支払い要請送信処理では、ユーザ端末４から注文識別情報と支払い方法を特定可能な情報に加えて、支払い金額が送信される。即ち、ユーザ端末４で読み取ったコード情報には注文識別情報と支払金額情報が含まれている。
　支払い管理サーバ３はステップＳ３０６において、支払い要請受信処理を実行し、ステップＳ３０７において、支払い処理を実行する。この処理により、ユーザ端末４から受信した金額情報がカード会社システム５に送信され、支払いが完了する。
　二つ目の例について、図２２を参照して説明する。
　本例では、ユーザ端末４から金額情報を受信すると共に、店舗サーバ１からも金額情報を受信し、金額の整合性を確認する。
　ユーザ端末４によってステップＳ５０１からステップＳ５０４の各処理が実行されることにより、金額情報を含んだ支払い要請が送信される。
　支払い管理サーバ３は、ステップＳ３０６で支払い要請を受信した後、ステップＳ３１３で金額情報確認処理を実行する。この処理は、店舗サーバ１に注文識別情報を送信することにより、該注文識別情報に紐付けられた金額情報、即ち注文者が支払うべき金額の情報を要求する処理である。
　要求を受信した店舗サーバ１は、ステップＳ２１５で注文識別情報に紐付けられた金額情報を取得し、ステップＳ２１６で支払い管理サーバ３に該金額情報を送信する処理を行う。
　支払い管理サーバ３は、ステップＳ３１４で金額情報を受信し、ステップＳ３１５で整合性確認処理を実行する。整合性確認処理では、ユーザ端末４から受信した金額情報と店舗サーバ１から受信した金額情報が合致しているかどうかを確認する処理である。
　整合性確認処理を実行下後、支払い管理サーバ３はステップＳ３０７の支払い処理を実行する。この後に各情報処理装置が実行する各処理については、前述したものと同様の処理となるため、説明を省略する。
　三つ目の例について、図２２を参照して説明する。
　本例では、ユーザ端末４から金額情報を受信しない。代わりに店舗サーバ１から金額情報を受信する。
　ユーザ端末４によってステップＳ５０１からステップＳ５０４の各処理が実行されることにより、金額情報を含まずに支払い要請が送信される。
　支払い管理サーバ３は、ステップＳ３０６で支払い要請を受信した後、ステップＳ３１３で金額情報確認処理を実行する。この処理は、店舗サーバ１に注文識別情報を送信することにより、該注文識別情報に紐付けられた金額情報、即ち注文者が支払うべき金額の情報を要求する処理である。
　要求を受信した店舗サーバ１は、ステップＳ２１５で注文識別情報に紐付けられた金額情報を取得し、ステップＳ２１６で支払い管理サーバ３に該金額情報を送信する処理を行う。
　支払い管理サーバ３は、ステップＳ３１４で金額情報を受信した後、ステップＳ３１５の処理を実行せずにステップＳ３０７の支払い処理を実行する。この後に各情報処理装置が実行する各処理については、前述したものと同様の処理となるため、説明を省略する。
＜９．第３の実施の形態における各処理＞
　図２１、図６、図２２の各図で説明した各装置の処理の流れを実現するために、店舗サーバ１（１Ａ）及び支払い管理サーバ３（３Ａ）が実行する処理の一例について、添付図を参照して説明する。
＜９－１．注文情報受付処理＞
　店舗端末１が実行する注文情報受付処理について、図８を参照して説明する。なお、ステップＳ６０１からステップＳ６０６の各処理については、他の実施の形態と同様の処理であるため、説明を省略する。
　ステップＳ６０７からステップＳ６０９の各処理は、注文合計金額を算出するための処理である。本実施の形態では、店舗端末１から支払い管理サーバ３へ注文合計金額を送信する必要はないため、ステップＳ６１１の支払い用情報送信処理では、注文識別情報のみを送信してもよい。従って、ステップＳ６１１の処理は、ステップＳ６０６の処理の直後に行ってもよい。
　店舗端末１Ａが実行する注文情報受付処理（図１９参照）についても同様である。即ち、図１９のステップＳ６１１の支払い用情報送信処理では、注文合計金額の送信は行わない。
　これにより、本実施の形態では、店舗端末１から支払い管理サーバ３へ送信される情報量が最小限とされるため、通信コストの削減を図ることができる。特に、追加注文を何度も行う注文者においては、無効化されることによりその後参照されることのない注文合計金額が何度も支払い管理サーバ３へ送信されてしまうことがあり得る。この場合には、最後の注文によって送信された注文合計金額のみ参照されることとなる。本実施の形態では、このような無駄な情報の送信が抑制される。
＜９－２．支払い用情報受信処理＞
　店舗端末１が実行する支払い用情報受信処理について、図１０を参照して説明する。
　図１０を用いて説明した第１の実施の形態とは、ステップＳ７０２の処理が異なる。具体的には、受信した情報に金額情報が含まれていないため、注文識別情報の取得は行うが、金額情報の取得は行わない。従って、ステップＳ７０３の記憶処理においても、注文識別情報の記憶のみを行う。
　店舗端末１Ａが実行する支払い用情報受信処理について、図２０を参照して説明する。
　この場合も同様に、ステップＳ７０２の処理及びＳ７０３の処理が異なる。
　また、ステップＳ７３１の印刷指示送信処理では、支払い管理サーバ３が金額情報を保持していないため、注文識別情報を指定することにより店舗サーバ１Ａに対する印刷指示を行う。店舗サーバ１Ａは受信した注文識別情報に基づいて金額情報を特定し、該情報を含む会計伝票の印刷を行う。
　このように、本実施の形態では、支払い用情報受信処理に応じて支払い管理サーバ３が記憶する情報が注文識別情報のみとされているため、使用される記憶領域をコンパクトにすることが可能となり、コスト削減に寄与することができる。
＜９－３．支払い要請受信処理＞
　支払い管理サーバ３が実行する支払い要請受信処理について、図１４を参照して説明する。なお、図１４に示す一連の処理（或いは後述する図２３，図２４に示す一連の処理）は、支払い管理サーバ３Ａが実行する処理であってもよい。
　なお、ステップＳ７２１からステップＳ７２４の各処理については、他の実施の形態と同様の処理であるため、説明を省略する。
　クレジットカード情報を取得した支払い管理サーバ３は、次に利用額についての情報を取得する。具体的には、支払い管理サーバ３はステップＳ７２５において、ステップＳ７２１で受信した情報から利用額情報を抽出する処理を実行する。即ち、先の例では支払い管理サーバ３が管理するＤＢから情報の取得を行っていたのに対し、本実施の形態では、ユーザ端末４から受信した情報から利用額情報を抽出する。
　本例では、ユーザ端末４から取得した金額情報を用いて支払い処理（即ち図１４に示す一連の処理）が実行される。即ち、店舗サーバ１から金額情報を取得するものではないため、店舗サーバ１と支払い管理サーバ３との間で行われる情報の送受信処理が少なくされるため、処理負担の軽減及び通信量の削減を図ることができる。
　支払い管理サーバ３が実行する支払い要請受信処理の別の例について、図２３を参照して説明する。
　支払い管理サーバ３はステップＳ７２５において、ステップＳ７２１で受信した情報から利用額情報を抽出する処理を実行する。次に、支払い管理サーバ３はステップＳ７３１において、金額情報確認処理を実行する。この処理は、図２２のステップＳ３１３の処理であり、即ち店舗サーバ１に金額情報の送信を要求する処理である。この処理により、店舗サーバ１に注文識別情報が送信される。
　支払い管理サーバ３はステップＳ７３２で金額情報を店舗サーバ１から受信する。
　支払い管理サーバ３はステップＳ７３３で整合性確認処理を実行する。この処理は、ユーザ端末４から受信した利用額情報と店舗サーバ１から受信した金額情報が同じであるか否かを判定する処理である。
　二つの金額情報が異なる場合、支払い管理サーバ３はユーザ端末４及び店舗サーバ１に支払いができなかった旨を通知する。
　二つの金額情報が同じであった場合、支払い管理サーバ３はステップＳ７２６からステップＳ７２８の各処理を実行する。これにより、ユーザ端末４を用いた注文者の支払いが完了する。
　本例では、二つの金額情報を用いて整合性を確認することにより、誤った金額が支払われてしまうことによる不利益の防止を図ることができる。即ち、適切な金額情報を用いて支払い処理が実行される。
　なお、二つの金額情報が異なる場合には、ステップＳ７２３で取得した支払い方法や、ステップＳ７２４で取得したクレジットカード情報などが使用されないこととなる。
　従って、ステップＳ７２５、ステップＳ７３１、ステップＳ７３２、ステップＳ７３３の各処理については、ステップＳ７２２の処理を実行した直後に実行してもよい。これにより、二つの金額情報が異なっていた場合に、使わない情報（支払い方法やクレジットカード情報）の取得処理を実行しなくても済むため、処理負担の軽減を図ることができる。
　支払い管理サーバ３が実行する支払い要請受信処理の更に別の例について、図２４を参照して説明する。
　支払い管理サーバ３は、ステップＳ７２１からステップＳ７２４の各処理を実行した後、ステップＳ７３１で金額情報確認処理を実行する。この処理によって、金額情報の要求が店舗サーバ１に送信される。
　店舗サーバ１によって金額情報が送信されると、支払い管理サーバ３はステップＳ７３２で該金額情報の受信処理を行う。
　支払い管理サーバ３は、ステップＳ７２６で利用額の枠確保依頼を行う。その後の各処理についての説明は省略する。
　本例では、支払い管理サーバ３は金額情報を保持しておらず、支払い要請を受信した際に初めて取得するものである。また、金額情報の取得は店舗サーバ１から行い、ユーザ端末４から受信した情報には含まれていない。
　即ち、金額情報の送受信が必要最低限のものとされるため、通信コストの削減（即ち、通信トラフィックの削減や通信処理の負担軽減や通信料金の削減等）を行うことができる。
＜１０．まとめ＞
　上述した各例で説明したように、店舗サーバ１としての情報処理装置は、注文者による注文を特定可能な注文識別情報を取得する情報取得部１ａと、注文識別情報（それに加えて前記注文についての支払金額としての金額情報を含んでいてもよい）を支払い用情報として送信する送信部１ｂと、注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部１ｃと、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文の注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置（支払い管理サーバ３）に対して行う無効化指示部１ｄと、を備えている。
　注文識別情報は、注文者による注文を一意に特定することが可能とされた情報である。即ち、注文した一つ一つの品物（商品）についての情報を送受信せずに、注文識別情報の送受信によって注文を特定することが可能とされる。従って、例えば、支払いを行う際に送る情報として、注文識別情報の送受信を行うことにより、品物ごとの情報の送受信が不要とされ、情報処理装置（店舗サーバ１や支払い管理サーバ３）の処理負担の軽減や通信帯域の有効利用に寄与することができる。
　また、注文識別情報（金額情報（注文総額）を含んでいてもよい）を支払い用情報として支払い処理を行う他の情報処理装置（支払い管理サーバ３）に予め送信しておくことにより、支払い処理を行う際には、注文識別情報の送信を行うだけで支払い処理を実行させることができるため、支払い管理サーバ３における支払い処理に要する時間を削減することが可能となる。特に、上述した各例では、支払い処理を行う際の注文識別情報の送信を注文者が利用するユーザ端末４が行っているため、支払い処理を行う際の店舗サーバ１の処理負担が著しく軽減される。
　更に、注文者による追加注文を受け付けた場合には、それまでに支払い管理サーバ３に送信済みの支払い用情報を無効化するための無効化指示を行うことにより、同一の注文者による未払いの支払い用情報が複数ある場合には最新の支払い用情報のみが有効な状態とされる。これにより、支払い処理を行う際に取り扱うデータが最新の支払い用情報のみとされるため、支払い処理に要する時間を短縮させることができ、支払い管理サーバ３の処理負担の軽減を図ることができる。
　なお、注文識別情報が特定できる印刷物の印刷処理を指示することにより、情報処理装置（店舗サーバ１）とは異なる端末、例えば注文者が使用する携帯電話などの注文者端末（ユーザ端末４）で注文識別情報の読み取りを行うことができる。これにより、読み取った注文識別情報に基づいた支払い要請を注文者端末（ユーザ端末４）から行うことができる。即ち、情報処理装置（店舗サーバ１）で支払い要請を送信する処理を実行しなくて済むため、情報処理装置（店舗サーバ１）の処理負担の軽減を図ることができる。特に、注文者が複数おり、該複数の注文者が同時に支払いを行おうとした場合には、支払い要請の送信が重複する可能性もある。一つの端末（店舗サーバ１）で支払い要請の送信を行う場合には、処理負担の増加や支払い要請の送信処理の遅延が生じる虞があるが、本構成のように、注文者端末（ユーザ端末４）などの他の端末を用いて支払い要請の送信処理が可能とすることにより、支払い要請の送信処理を分散させることができ、一つの端末（店舗サーバ１）に処理負担が集中を回避することや効率的な処理を行うことが可能となる。また、注文者が会計のために行列に並ばなくてはならず、時間を浪費してしまうような事態を回避することが可能となる。
　なお、上記した各例においては、店舗サーバ１とユーザ端末４の間で情報通信を行うことなく、注文の受け付けから支払いまでを実現可能とされている。即ち、店舗サーバ１においては、多種多様なユーザ端末４から送信される情報を受け付けるための処理を実装する必要がないため、店舗サーバ１を構築するためのコストを削減することができる。また、店舗サーバ１の処理負担が軽減されるため、店舗サーバ１の性能を下げることができ、店舗サーバ１自体のコスト削減にも寄与することができる。また、多数のユーザ端末４についての情報を保持する必要がないため、店舗サーバ１が扱うＤＢの削減や店舗サーバ１が備える記憶部の削減を図ることができる。
　なお、注文者による注文を特定可能な注文識別情報（それに加えて前記注文についての支払金額としての金額情報を含んでいてもよい）を支払い用情報として受信する受信部（支払い用情報受信部３ａ）と、注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部（印刷指示部３ｆと、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文の注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化処理を行う無効化処理部３ｅと、を備えた情報処理装置（支払い管理サーバ３Ａ）を用いることによって、上記の作用や効果を得ることもできる。
　機能構成の説明や、図９の説明などのように、店舗サーバ１としての情報処理装置において扱う注文識別情報は、注文者を識別する注文者識別情報を含むものとされてもよい。
　注文識別情報が注文者の特定を可能とする情報を含むことにより、注文識別情報を解析するだけで同一の注文者による注文であるのか否かを判定することが可能となる。
　これにより、無効化指示によって無効化する同一の注文者による支払い用情報の特定が容易とされるため、処理負担の軽減が図られる。
　機能構成の説明や、図９の説明などのように、店舗サーバ１としての情報処理装置において扱う注文者識別情報は、注文を受け付けた店舗を特定可能な情報を含むものとされてもよい。
　顧客を特定可能な情報が店舗特定可能な情報も含むことにより、顧客特定情報は、店舗ごとに異なる情報とされる。
　即ち、複数の店舗それぞれから送信される顧客特定情報が重複することがないため、店舗ごとに異なる支払い管理サーバ３を設ける必要が無くなり、処理負担の軽減及びシステム導入コストの削減を図ることが可能となる。
　また、注文者識別情報は、注文者の個人的な情報を含まないものとされてもよい。例えば、注文を行った店舗を示す店舗コードと、注文者が利用したテーブルを示すテーブルコードと、該テーブルを利用した順番を示す利用コードから注文者識別情報が構成されていてもよい。これにより、注文者識別情報に注文者の個人情報が含まれないため、個人情報の保護の観点から注文識別情報を扱う際の利便性が高い。
　印刷制御部１ｃの機能説明などのように、店舗サーバ１としての情報処理装置が実行する印刷処理は、注文識別情報の特定が可能なコード情報（例えば二次元バーコード）を印刷物に印刷する処理とされてもよい。
　これにより、コード情報として、一般的に普及している一次元バーコードや二次元バーコードを利用することができる。
　即ち、既存の技術を本構成に適用することができるため、開発コストなどを削減することができる。
　図７等で説明したように、店舗サーバ１としての情報処理装置においては、他の情報処理装置（支払い管理サーバ３）から支払いが完了したことを示す通知を支払い完了通知として受信する受信部１ｅを備えていてもよい。
　支払い完了通知を受信することにより、注文者が代金を支払ったか否かを判別することが可能となる。
　これにより、代金を支払わないような不正行為を防止することができる。また、支払いが行われたか否かの確認処理を簡易化することができるため、情報処理装置（店舗サーバ１）やオペレータ（店員）の処理負担の軽減が図られる。
　支払いに関する流れにおいて図６，図７を用いて説明したように、店舗サーバ１としての情報処理装置においては、注文者による注文についての支払い完了通知を受信した後に、同一の注文者による追加注文を受け付けた場合には、送信部１ｅは、金額情報として、支払い完了通知の受信後に行われ且つ未払いとされた追加注文の合計金額の情報を送信してもよい。但し、この場合には、注文についての支払金額としての金額情報が支払い用情報に含まれるものとする。
　即ち、支払い済みの注文に関する金額が除かれた通知が他の情報処理装置（例えば支払い管理サーバ３）に対して行われる。
　これにより、支払い管理サーバ３において支払い済みの注文に関する金額を減算する処理などを行わなくて済むため、支払い管理サーバ３における処理負担の軽減が図られる。特に、多数の店舗から支払い用情報を受信するような場合においては、多数の情報を一度に受信する可能性がある。そのような場合には、支払い管理サーバ３の処理能力がボトルネックとなる虞があるが、本構成のように、支払い用情報の受信処理や記憶処理に係る支払い管理サーバ３の負担が軽減されることにより、円滑な処理を実行することができる。また、より多くの店舗からの依頼を処理可能とすることができる。更に、処理能力を抑えた安価なコンピュータを支払い管理サーバ３として採用することができるため、システムコストの削減を図ることが可能となる。
　また、支払い管理サーバ３としての情報処理装置は、注文者による注文を特定可能な注文識別情報（それに加えて金額情報を含んでいてもよい）を支払い用情報として受信する支払い用情報受信部３ａと、受信した支払い用情報の記憶処理を実行させる記憶処理部３ｂと、注文者が利用する注文者端末（ユーザ端末４）から注文識別情報と該注文者の支払い情報（例えば、支払い方法を特定する情報）を含む支払い要請を受信する支払い要請受信部３ｃと、支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部３ｄと、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を受け付け、記憶された支払い用情報の無効化を行う無効化処理部３ｅと、を備えている。
　無効化処理部３ｅによる無効化処理により、最新の注文識別情報を有する支払い用情報のみ有効とされ、二重に代金が支払われてしまうことが防止される。
　また、店舗サーバ１と支払い管理サーバ３とを備える支払いシステムにおいて、店舗サーバ１または支払い管理サーバ３の何れかの情報処理装置が、注文者による注文を特定可能な注文識別情報を取得する情報取得部１ａと、注文識別情報（それに加えて金額情報を含んでいてもよい）を支払い用情報として送信する送信部１ｂと、注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部１ｃ（或いは印刷指示部３ｆ）と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置（支払い管理サーバ３）に対して行う無効化指示部１ｄと、支払い用情報を受信する支払い用情報受信部３ａと、受信した支払い用情報の記憶処理を実行させる記憶処理部３ｂと、注文者が利用する注文者端末（ユーザ端末４）から注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部３ｃと、支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部３ｄと、無効化指示部からの無効化指示を受け付け記憶された支払い用情報の無効化を行う無効化処理部３ｅと、を備えている。
　これにより、上述のような種々の効果を得ることが可能なシステムを構築することが可能となる。
　また、上記の支払いシステムは、注文者による注文を特定可能な注文識別情報を取得する情報取得部１ａと、注文識別情報（それに加えて注文についての支払金額としての金額情報を含んでいてもよい）を支払い用情報として送信する送信部１ｂと、支払い用情報を受信する支払い用情報受信部３ｃと、受信した支払い用情報の記憶処理を実行させる記憶処理部３ｂと、注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部（印刷制御部１ｃ或いは印刷指示部３ｆ）と、注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化処理を行う無効化処理部３ｅと、注文者が利用する注文者端末から注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部３ｃと、支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部３ｄと、を備えるものであってもよい。
　なお、当該支払いシステムには、支払い管理サーバ３Ａの処理によらず店舗サーバ１が印刷物（例えば会計伝票）の印刷指示を行うと共に、注文識別情報の無効化処理は店舗サーバ１Ａの処理によらず支払い管理サーバ３Ａが実行する構成についても含まれている。
＜１１．プログラム及び記憶媒体＞
　以上、本発明の情報処理装置の実施の形態としての店舗サーバ１を説明してきたが、実施の形態のプログラムは、注文者が利用するユーザ端末４の情報処理装置（ＣＰＵ等）に各種の処理を実行させるプログラム（例えば、ユーザ端末４にインストールされたアプリケーションプログラム）などである。
　実施の形態のプログラムは、注文を特定可能な注文識別情報を印刷物（例えば二次元バーコード）から読み取る処理を情報処理装置（例えばユーザ端末４）の演算処理装置に実行させる。
　また、無効指示がなされて無効化された支払い用情報よりも後に行った注文であって且つ未払いとされた注文についての支払いを行うための支払い情報と読み取った注文識別情報とを含む支払い要請を送信する処理を情報処理装置（例えばユーザ端末４）の演算処理装置に実行させる。
　即ちこのプログラムは、情報処理装置（例えばユーザ端末４）に対して図７で説明したステップＳ５０１からステップＳ５０５の各処理を実行させるプログラムである。
　このようなプログラムにより、上述したユーザ端末４としての１又は複数の情報処理装置を実現できる。
　そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
　また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。
　１　店舗サーバ、１ａ　情報取得部、１ｂ　送信部、１ｃ　印刷制御部、１ｄ　無効化指示部、１ｅ　受信部、３　支払い管理サーバ、３ａ　支払い用情報受信部、３ｂ　記憶処理部、３ｃ　支払い要請受信部、３ｄ　支払い処理部、３ｅ　無効化処理部、４　ユーザ端末

Claims (12)

  1. 　注文者による注文を特定可能な注文識別情報を取得する情報取得部と、
    　前記注文識別情報を支払い用情報として送信する送信部と、
    　前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、
    　注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文の注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置に対して行う無効化指示部と、を備えた
    　情報処理装置。
  2. 　前記注文識別情報は、注文者を識別する注文者識別情報を含むものとされた
    　請求項１に記載の情報処理装置。
  3. 　前記注文者識別情報は、注文を受け付けた店舗を特定可能な情報を含む
    　請求項２に記載の情報処理装置。
  4. 　前記印刷処理は、前記注文識別情報の特定が可能なコード情報を前記印刷物に印刷する処理とされた
    　請求項１から請求項３の何れかに記載の情報処理装置。
  5. 　前記他の情報処理装置から支払いが完了したことを示す通知を支払い完了通知として受信する受信部を備えた
    　請求項１から請求項４の何れかに記載の情報処理装置。
  6. 　前記支払い用情報には前記注文についての支払金額としての金額情報が含まれ、
    　注文者による注文についての前記支払い完了通知を受信した後に、同一の注文者による追加注文を受け付けた場合には、前記送信部は、前記金額情報として、前記支払い完了通知の受信後に行われ且つ未払いとされた追加注文の合計金額の情報を送信する
    　請求項５に記載の情報処理装置。
  7. 　注文者による注文を特定可能な注文識別情報を支払い用情報として受信する支払い用情報受信部と、
    　受信した前記支払い用情報の記憶処理を実行させる記憶処理部と、
    　注文者が利用する注文者端末から注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部と、
    　前記支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部と、
    　注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を受け付け、記憶された前記支払い用情報の無効化を行う無効化処理部と、を備えた
    　情報処理装置。
  8. 　注文者による注文を特定可能な注文識別情報を取得する情報取得ステップと、
    　前記注文識別情報を支払い用情報として送信する送信ステップと、
    　前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御ステップと、
    　注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置に対して行う無効化指示ステップと、を
    　情報処理装置が実行する情報処理方法。
  9. 　注文者による注文を特定可能な注文識別情報を取得する情報取得部と、
    　前記注文識別情報を支払い用情報として送信する送信部と、
    　前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、
    　注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化指示を他の情報処理装置に対して行う無効化指示部と、
    　前記支払い用情報を受信する支払い用情報受信部と、
    　受信した前記支払い用情報の記憶処理を実行させる記憶処理部と、
    　注文者が利用する注文者端末から前記注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部と、
    　前記支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部と、
    　前記無効化指示部からの無効化指示を受け付け記憶された前記支払い用情報の無効化を行う無効化処理部と、を備えた
    　支払いシステム。
  10. 　注文を特定可能な注文識別情報を印刷物から読み取る手順と、
    　無効指示がなされて無効化された支払い用情報よりも後に行った注文であって且つ未払いとされた注文についての支払いを行うための支払い情報と読み取った前記注文識別情報とを含む支払い要請を送信する手順と、を
    　コンピュータに実行させるプログラム。
  11. 　注文者による注文を特定可能な注文識別情報を支払い用情報として受信する受信部と、
    　前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、
    　注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文の注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化処理を行う無効化処理部と、を備えた
    　情報処理装置。
  12. 　注文者による注文を特定可能な注文識別情報を取得する情報取得部と、
    　前記注文識別情報を支払い用情報として送信する送信部と、
    　前記支払い用情報を受信する支払い用情報受信部と、
    　受信した前記支払い用情報の記憶処理を実行させる記憶処理部と、
    　前記注文識別情報の特定が可能な印刷物の印刷処理を実行させる印刷制御部と、
    　注文者による追加注文を受け付けた場合に、同一の注文者による未払いとされた注文識別情報に関する支払いが不可能となるように該注文識別情報を無効化する無効化処理を行う無効化処理部と、
    　注文者が利用する注文者端末から前記注文識別情報と該注文者の支払い情報を含む支払い要請を受信する支払い要請受信部と、
    　前記支払い要請に基づいて支払い用情報についての支払い処理を行う支払い処理部と、を備えた
    　支払いシステム。
PCT/JP2018/048344 2018-12-27 2018-12-27 情報処理装置、情報処理方法、支払いシステム及びプログラム WO2020136847A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201880051403.5A CN111630554A (zh) 2018-12-27 2018-12-27 信息处理装置、信息处理方法、支付系统以及程序
JP2019519018A JP6591123B1 (ja) 2018-12-27 2018-12-27 情報処理装置、情報処理方法、支払いシステム及びプログラム
PCT/JP2018/048344 WO2020136847A1 (ja) 2018-12-27 2018-12-27 情報処理装置、情報処理方法、支払いシステム及びプログラム
US17/044,631 US11704721B2 (en) 2018-12-27 2018-12-27 Information processing device, information processing method, payment system and program
TW108135634A TWI720635B (zh) 2018-12-27 2019-10-02 資訊處理裝置、資訊處理方法、及支付系統

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/048344 WO2020136847A1 (ja) 2018-12-27 2018-12-27 情報処理装置、情報処理方法、支払いシステム及びプログラム

Publications (1)

Publication Number Publication Date
WO2020136847A1 true WO2020136847A1 (ja) 2020-07-02

Family

ID=68234862

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/048344 WO2020136847A1 (ja) 2018-12-27 2018-12-27 情報処理装置、情報処理方法、支払いシステム及びプログラム

Country Status (5)

Country Link
US (1) US11704721B2 (ja)
JP (1) JP6591123B1 (ja)
CN (1) CN111630554A (ja)
TW (1) TWI720635B (ja)
WO (1) WO2020136847A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7175938B2 (ja) * 2020-06-30 2022-11-21 楽天銀行株式会社 支払システム、支払方法、及びプログラム
JP2022129910A (ja) * 2021-02-25 2022-09-06 東芝テック株式会社 注文管理装置、情報処理プログラム及び注文処理システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012053850A (ja) * 2010-09-03 2012-03-15 Sii Data Service Kk 注文管理システムおよび注文管理方法
JP2016533584A (ja) * 2013-08-20 2016-10-27 インスタペイ インコーポレイテッド コード認識を利用した決済サービス方法およびそのシステム
JP2018151757A (ja) * 2017-03-10 2018-09-27 セイコーソリューションズ株式会社 注文管理システム、注文管理システムの決済方法、及びプログラム
JP2018156433A (ja) * 2017-03-17 2018-10-04 セイコーソリューションズ株式会社 情報処理システム、情報処理装置、携帯端末装置、及びプログラム

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001002948A1 (en) * 1999-06-30 2001-01-11 Silverbrook Research Pty Ltd Interactive printer reward scheme
JP2002133133A (ja) 2000-10-19 2002-05-10 Sony Corp 画像印刷受注システム及び画像印刷受注方法
US20150039450A1 (en) * 2002-02-06 2015-02-05 Konrad Hernblad Customer-based wireless food ordering and payment system and method
US20040054592A1 (en) * 2002-09-13 2004-03-18 Konrad Hernblad Customer-based wireless ordering and payment system for food service establishments using terminals and mobile devices
US20090063274A1 (en) * 2007-08-01 2009-03-05 Dublin Iii Wilbur Leslie System and method for targeted advertising and promotions using tabletop display devices
US9652773B1 (en) * 2009-03-24 2017-05-16 Wilbur Leslie Dublin, III Two-sided touch screen display
JP5671942B2 (ja) 2010-10-28 2015-02-18 株式会社寺岡精工 Ｐｏｓシステム
CN102360480B (zh) * 2011-10-06 2017-06-16 浙江易网科技股份有限公司 一种链接网上支付及记录链接的方法和系统
US9240006B2 (en) * 2011-11-30 2016-01-19 At&T Intellectual Property I, L.P. Wireless transactions for enhancing customer experience
WO2013098661A1 (en) * 2011-12-29 2013-07-04 Bhatia Shashank Collaborative, improved system and method for processing commercial transactions
US20140058902A1 (en) * 2012-08-21 2014-02-27 Ovni, Inc. Distributed system for remote ordering
US9760958B2 (en) * 2012-10-19 2017-09-12 Ncr Corporation Techniques for restaurant transaction processing
US9741083B2 (en) * 2013-04-30 2017-08-22 Ncr Corporation Systems and methods for facilitating closing of a check
US20150134441A1 (en) * 2013-11-13 2015-05-14 Tabletop Media Llc D/B/A Ziosk Table-side device integration to a point-of-sale (POS) hospitality system
US20150149307A1 (en) * 2013-11-22 2015-05-28 Harsimrat Thukral Location-based ordering
US9355418B2 (en) * 2013-12-19 2016-05-31 Twin Harbor Labs, LLC Alerting servers using vibrational signals
US20160275576A1 (en) * 2013-12-19 2016-09-22 Twin Harbor Labs, LLC System and Method for Alerting Servers Using Vibrational Signals
WO2015168128A1 (en) * 2014-04-28 2015-11-05 Reserve Media, Inc. System and method for bill splitting
US9633383B2 (en) * 2014-05-30 2017-04-25 Paypal, Inc. Voice and context recognition for bill creation
GB2528869A (en) * 2014-07-31 2016-02-10 Mastercard International Inc Payment mode selection
WO2016025604A1 (en) * 2014-08-15 2016-02-18 TableUp, LLC System and method for interacting with patrons
US20160055598A1 (en) * 2014-08-25 2016-02-25 Purna Chander Ramini Restaurant Guest Service System And Method
US10304119B2 (en) * 2014-08-28 2019-05-28 365 Technologies Holding Limited Method and system for processing food orders
US10217159B2 (en) * 2015-08-24 2019-02-26 Ncr Corporation Shared transactions
US10762484B1 (en) * 2015-09-30 2020-09-01 Square, Inc. Data structure analytics for real-time recommendations
US20170109843A1 (en) * 2015-10-20 2017-04-20 Back Home Foods LLC System and method for mobile-assisted digital waiter
KR20160073942A (ko) * 2016-04-28 2016-06-27 (주)인스타페이 코드 인식을 이용한 결제 서비스 방법 및 그 시스템
US10360648B1 (en) * 2016-06-22 2019-07-23 Square, Inc. Synchronizing KDS functionality with POS waitlist generation
CN106408367A (zh) * 2016-08-25 2017-02-15 北京三快在线科技有限公司 订单信息的获取方法及装置
US10255645B1 (en) * 2016-12-22 2019-04-09 Worldpay, Llc Systems and methods for personalized dining checks and individualized payment by associating device with dining session
US10586293B1 (en) * 2016-12-22 2020-03-10 Worldpay, Llc Systems and methods for personalized dining and individualized ordering by associating electronic device with dining session
JP6949517B2 (ja) 2017-03-17 2021-10-13 東芝テック株式会社 決済システム
CN107491958A (zh) * 2017-08-14 2017-12-19 福建米客互联网科技有限公司 一种买单结算方法及终端
CN107544765A (zh) * 2017-09-22 2018-01-05 重庆亚能软件开发有限公司 一种订单打印系统及方法
CN108074171A (zh) * 2017-12-27 2018-05-25 口碑(上海)信息技术有限公司 基于服务识别码的门店订单处理方法以及装置
CN108182628B (zh) 2018-01-29 2021-04-20 上海携程国际旅行社有限公司 旅游下单的方法、系统、设备及存储介质
US11244299B1 (en) * 2018-03-16 2022-02-08 DoorDash, Inc. Location-based transaction completion

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012053850A (ja) * 2010-09-03 2012-03-15 Sii Data Service Kk 注文管理システムおよび注文管理方法
JP2016533584A (ja) * 2013-08-20 2016-10-27 インスタペイ インコーポレイテッド コード認識を利用した決済サービス方法およびそのシステム
JP2018151757A (ja) * 2017-03-10 2018-09-27 セイコーソリューションズ株式会社 注文管理システム、注文管理システムの決済方法、及びプログラム
JP2018156433A (ja) * 2017-03-17 2018-10-04 セイコーソリューションズ株式会社 情報処理システム、情報処理装置、携帯端末装置、及びプログラム

Also Published As

Publication number Publication date
CN111630554A (zh) 2020-09-04
TW202025029A (zh) 2020-07-01
US11704721B2 (en) 2023-07-18
JPWO2020136847A1 (ja) 2021-02-15
JP6591123B1 (ja) 2019-10-16
TWI720635B (zh) 2021-03-01
US20210166295A1 (en) 2021-06-03

Similar Documents

Publication Publication Date Title
JP6912347B2 (ja) 情報処理装置およびプログラム
TWI485637B (zh) Credit card information processing system, credit card information processing method, order information receiving device, credit card checkout device, program and information recording medium
JP6725573B2 (ja) 決済支援システム、決済支援装置、決済支援方法、及びプログラム
CN102057354A (zh) 获取对应用程序的更新的技术
JP2008225601A (ja) オーダ会計システムおよび方法
JP2004326727A (ja) 決済処理サーバ、決済処理方法、決済処理プログラム、決済処理端末装置、決済処理端末方法、及び決済処理端末プログラム
WO2020136847A1 (ja) 情報処理装置、情報処理方法、支払いシステム及びプログラム
JP2009129080A (ja) 匿名オンライン通販システム
JP2020112958A (ja) プリペイドカードの管理装置、管理方法、及びそのためのプログラム
US20160078509A1 (en) Apparatus, system, and method of managing transactions of electronic books
JP2019061353A (ja) 決済システム及び利用者管理装置
JP2020181328A (ja) 電子決済システム及びプログラム
JP6368847B1 (ja) 情報管理装置、情報管理方法及びプログラム
JP6815905B2 (ja) 注文管理システム、注文管理システムの決済方法、及びプログラム
JP2016088687A (ja) 物品配達システム、ロッカー装置及び物品配達管理方法
JP2022168091A (ja) 仮想通貨決済支援装置、仮想通貨決済支援システム、仮想通貨決済支援方法、及び仮想通貨決済支援プログラム
JP2022079574A (ja) 業務管理システム
TWI575467B (zh) Information processing device, information processing method, memory media
JP7243673B2 (ja) 配送サーバ、決済システム、プログラムおよび送信方法
CN109308601B (zh) 信息处理系统及信息处理系统的信息处理方法
JP2017102551A (ja) Ａｔｍ予約システムおよび方法
JP2006072475A (ja) 情報処理装置、情報提供装置、情報処理プログラム、および情報提供プログラム
KR100454635B1 (ko) 전자 결제 장치, 전자 결제 방법, 저장 매체, 및 컴퓨터데이터 신호
JP2020154573A (ja) 買い物代行システム
JP2006018520A (ja) 情報提供システム

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2019519018

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18944452

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18944452

Country of ref document: EP

Kind code of ref document: A1