TWI720635B - 資訊處理裝置、資訊處理方法、及支付系統 - Google Patents

資訊處理裝置、資訊處理方法、及支付系統 Download PDF

Info

Publication number
TWI720635B
TWI720635B TW108135634A TW108135634A TWI720635B TW I720635 B TWI720635 B TW I720635B TW 108135634 A TW108135634 A TW 108135634A TW 108135634 A TW108135634 A TW 108135634A TW I720635 B TWI720635 B TW I720635B
Authority
TW
Taiwan
Prior art keywords
order
information
payment
identification information
processing
Prior art date
Application number
TW108135634A
Other languages
English (en)
Other versions
TW202025029A (zh
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 日商樂天股份有限公司
Publication of TW202025029A publication Critical patent/TW202025029A/zh
Application granted granted Critical
Publication of TWI720635B publication Critical patent/TWI720635B/zh

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

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (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)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

提供一種，可一面減輕涉入結帳處理之店員的作業負擔，同時可進行適切的結帳處理的環境。為此，資訊處理裝置係具備有：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予以發送；和列印控制部，係令前記下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化指示部，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示。

Description

資訊處理裝置、資訊處理方法、及支付系統
本發明係有關於，受理使用者之下單之相關資訊並進行各種處理的資訊處理裝置、資訊處理方法、支付系統及程式之技術領域。
例如在店舖中用餐的情況下，會因為複數名來店客的結帳時序過於集中而導致結帳處理遲滯不前，甚至有時候會導致大排長龍。因此而會導致已經用餐完畢的來店客浪費無謂的時間等問題。 於以下所示的專利文獻1中係記載，有鑑於此種問題點，藉由令自助點餐終端從菜單讀取品項識別資訊(品項代碼)而進行下單，自助點餐終端所列印出來的結帳用代碼藉由結帳裝置加以讀取而進行結帳。又還記載了，藉由將進行下單或結帳的各裝置做必要的台數組合而適宜配置，就可分散等待結帳之隊伍的意旨。 [先前技術文獻] [專利文獻]
[專利文獻1] 日本特開2012-94058號公報
[發明所欲解決之課題]
可是，讓來店客操作結帳裝置，會有發生無法預期之不測事態之虞。例如可想定，不習慣結帳裝置之操作而進行了錯誤操作，導致進行錯誤的結帳處理。在如此情況下，必須叫店員來重新進行結帳操作，導致原本由店員來進行結帳操作就不需要的修正操作之發生，而有造成店員的作業負擔增大之虞。 於是，本發明的目的在於提供一種，可一面減輕涉入結帳處理之店員的作業負擔，同時可進行適切的結帳處理的環境。 [用以解決課題之手段]
本發明所述之資訊處理裝置，係具備：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予以發送；和列印控制部，係令前記下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化指示部，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示。 藉此，同一下單者所致之未付款之支付用資訊是有複數筆的情況下，只有最新的支付用資訊會被設成有效狀態。
於上述的資訊處理裝置中亦可為，前記下單識別資訊係被設成，含有用來識別下單者的下單者識別資訊。 藉由使下單識別資訊含有可特定下單者之資訊，只須解析下單識別資訊就可判定是否為同一下單者所致之下單。
於於上述的資訊處理裝置中亦可為，前記下單者識別資訊係含有：可特定受理了下單之店舖的資訊。 藉由使可特定顧客之資訊也含有可特定店舖之資訊，顧客特定資訊係被設成隨每一店舖而不同的資訊。
於上述的資訊處理裝置中的前記列印處理中亦可設成，將可特定前記下單識別資訊的代碼資訊列印至前記列印物的處理。 藉此，作為代碼資訊，可以利用一般普及的一維條碼或二維條碼。
於上述的資訊處理裝置中，亦可具備：收訊部，係從前記其他資訊處理裝置接收表示支付已完成之通知來作為支付完成通知。 藉由接收支付完成通知，就可判別下單者是否已經支付了費用。
於上述的資訊處理裝置中，亦可為，前記支付用資訊中係含有：關於前記下單的作為支付金額的金額資訊；在接收到關於下單者所致之下單的前記支付完成通知之後，受理了同一下單者所致之追加下單的情況下，前記送訊部，係將在前記支付完成通知之收訊後所被進行且為未付款之追加下單的合計金額之資訊予以發送，以作為前記金額資訊。 亦即，關於已支付之下單之金額是已被扣除的通知，會對其他資訊處理裝置(例如支付管理伺服器)進行。
本發明所述之其他資訊處理裝置，係具備：支付用資訊收訊部，係將可特定下單者所致之下單的下單識別資訊予以接收而作為支付用資訊；和記憶處理部，令已接收之前記支付用資訊之記憶處理被執行；和支付請求收訊部，係從下單者所利用之下單者終端接收含有下單識別資訊與該下單者之支付資訊的支付請求；和支付處理部，係基於前記支付請求而進行關於支付用資訊的支付處理；和無效化處理部，係在受理了下單者所致之追加下單的情況下，受理為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示，並進行已被記憶之前記支付用資訊的無效化。 其他資訊處理裝置，係從上述的資訊處理裝置接收支付用資訊而執行各處理。
本發明所述之其他資訊處理裝置，係亦可具備：收訊部，係將可特定下單者所致之下單的下單識別資訊予以接收而作為支付用資訊；和列印控制部，係令前記下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化處理部，係在受理了下單者所致之追加下單的情況下，進行為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化處理。
本發明所述之支付系統，係具備：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予以發送；和列印控制部，係令前記下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化指示部，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示；和支付用資訊收訊部，係接收前記支付用資訊；和記憶處理部，令已接收之前記支付用資訊之記憶處理被執行；和支付請求收訊部，係從下單者所利用之下單者終端接收含有前記下單識別資訊與該下單者之支付資訊的支付請求；和支付處理部，係基於前記支付請求而進行關於支付用資訊的支付處理；和無效化處理部，係將來自前記無效化指示部的無效化指示予以受理並進行已被記憶之前記支付用資訊的無效化。 或者，亦可為一種支付系統，係具備：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予以發送；和支付用資訊收訊部，係接收前記支付用資訊；和記憶處理部，令已接收之前記支付用資訊之記憶處理被執行；和列印控制部，係令前記下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化處理部，係在受理了下單者所致之追加下單的情況下，進行為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化處理；和支付請求收訊部，係從下單者所利用之下單者終端接收含有前記下單識別資訊與該下單者之支付資訊的支付請求；和支付處理部，係基於前記支付請求而進行關於支付用資訊的支付處理。
本發明所述之資訊處理方法，係由資訊處理裝置執行：資訊取得步驟，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊步驟，係將前記下單識別資訊當作支付用資訊而予以發送；和列印控制步驟，係令前記下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化指示步驟，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示。 藉此，可提供在同一下單者所致之未付款之支付用資訊是有複數筆的情況下，只有最新的支付用資訊會被設成有效狀態的環境。
本發明所述之程式，係令電腦執行：從列印物讀取可特定下單之下單識別資訊的程序；和發送支付請求的程序，該支付請求含有：針對在被進行無效指示而被無效化之支付用資訊之後所進行之下單且為未付款之下單而為了進行支付所需之支付資訊與所讀取到之前記下單識別資訊。 藉此，可在同一下單者所致之未付款之支付用資訊是有複數筆的情況下，只有最新的支付用資訊會被設成有效的狀態的環境下，進行支付。 [發明效果]
若依據本發明，則可減輕因讓下單者進行結帳作業所導致的涉入結帳處理之店員的作業負擔，同時，在同一下單者所致之未付款之支付用資訊是有複數筆的情況下，只有最新的支付用資訊會被設成有效狀態，因此可進行適切的結帳處理。
關於含有本實施形態的店舖伺服器1的網路系統之構成例，參照圖1來加以說明。 ＜1. 系統構成＞ 本實施形態所述之店舖伺服器1，係被連接至通訊網路2。 通訊網路2上係還被連接有：支付管理伺服器3或使用者終端4或發卡公司系統5或電子貨幣系統6等。 各裝置或系統係透過通訊網路2而可彼此通訊。
通訊網路2之構成係想定多樣的例子。例如想定為：網際網路、企業內網路、企業間網路、LAN(Local Area Network)、CATV(Community Antenna TeleVision)通訊網、虛擬專用網(Virtual Private Network)、電話線路網、移動體通訊網、衛星通訊網等。 又，關於構成通訊網路2之全部或部分的傳輸媒體也被想定有多種例子。例如：IEEE(Institute of Electrical and Electronics Engineers)1394、USB(Universal Serial Bus)、電力線載送、電話線等之有線也好、IrDA(Infrared Data Association)這類紅外線、藍牙(註冊商標)、802.11無線、行動電話網、衛星線路、地表波數位網等之無線都可利用。
店舖伺服器1，係為被設置在例如餐廳或零售店等之店舖中的資訊處理裝置。店舖伺服器1係進行，將來店客(下單者)所致之下單予以受理之處理、或將下單內容傳達給廚房所需之處理、或將支付用資訊發送至支付管理伺服器3之處理等。 又，店舖中係除了店舖伺服器1以外還被適宜配備有，作為可讓下單者進行下單之輸入的輸入終端的下單終端7。下單終端7，係隨著店舖的面積等，而被設置適切的數量。
下單終端7係可為例如，在店舖中工作的店員所持有的手持型，亦可為被安裝具備在來店客進行用餐之桌子上的桌上設置型。 藉由下單終端7而被輸入的各種資訊，係被發送至店舖伺服器1。下單終端7，係不只可輸入新的下單，也可受理追加的下單之輸入。 下單終端7，係只要至少可與店舖伺服器1進行通訊即可。又，亦可為，從下單終端7往店舖伺服器1之通訊是被設成可能，同時，從店舖伺服器1往下單終端7之通訊是被設成不可能。
店舖伺服器1，係基於從下單終端7所接收到的資訊而進行各種處理。又，從下單終端7接收到追加下單之資訊的店舖伺服器1，係將關於追加下單的支付用資訊發送至支付管理伺服器3，同時，將用來使目前為止已經發送過的支付用資訊變成無效化所需之無效化指示，發送至支付管理伺服器3。 店舖伺服器1，係為了執行上記之各處理，而具備將已受理之下單資訊加以記憶的下單DB51。在下單DB51中，已被下單之每一單品的品項資訊或單價資訊、下單的合計金額資訊等，是與下單識別資訊建立關連而被記憶。
支付管理伺服器3，係從店舖伺服器1接收支付用資訊，並進行將其記憶在記憶部之處理等。又，將來自店舖伺服器1的無效化指示加以受理，並進行將相應之支付用資訊變成無效化之處理。 為此，支付管理伺服器3係具備有：將已接收之支付用資訊予以記憶的支付用DB61。在支付用DB61中，下單識別資訊與合計金額資訊是被建立關連而記憶。
使用者終端4，係為下單者所使用的資訊處理終端，係被設成可讀取代碼資訊(例如一維條碼或二維條碼)。代碼資訊之讀取，係亦可藉由對使用者終端4安裝軟體而加以實現。 又，使用者終端4係被設成，可基於所讀取到的代碼資訊，而向支付管理伺服器3發送支付請求。此時，亦可設成，可從信用卡所致之支付或電子貨幣所致之支付等被複數準備的支付方法中，指定所望之支付方法。 使用者終端4係為例如：具備通訊機能的PC(Personal Computer)或功能型手機或PDA(Personal Digital Assistants)、或智慧型手機或平板終端等之智慧型裝置等。
發卡公司系統5係為，在藉由下單者(使用者)指定了信用卡所致之支付之際，從支付管理伺服器3接收為了進行信用卡所致之支付所需而必要的各種資訊，並藉由信用卡而進行支付處理的系統。 例如進行：已被指定之信用卡的有效期限是否適切的判定處理、或已被指定之信用卡是否有被登錄在使用禁止清單中的判定處理、或利用額是否超過限度額的判定處理等。又，在判定為已被指定之信用卡是可利用的情況下，則也會進行將本次之利用額的額度予以確保的處理等。 為此，發卡公司系統5係適宜具備有：將使用者資訊(使用者的姓名或年齡等之個人資訊與卡片資訊建立關連的資訊)予以記憶的資料庫(Database，以下記載成「DB」)、或用來進行授權(亦即所謂授信)所需之DB、或記憶著信用卡之利用履歷的DB等。此外，關於這些各DB係未圖示。
電子貨幣系統6係為，在藉由下單者(使用者)指定了電子貨幣所致之支付之際，從支付管理伺服器3接收為了進行電子貨幣所致之支付所需而必要的各種資訊，並進行電子貨幣所致之支付處理的系統。為此，電子貨幣系統6係適宜具備有：將使用者資訊(使用者的姓名或年齡等之個人資訊與為了利用電子貨幣所需之帳號資訊所被建立關連的資訊)予以記憶的DB、或記憶著電子貨幣之利用履歷的DB等。此外，關於這些各DB係未圖示。
發卡公司系統5或電子貨幣系統6，係亦可按照發卡機構(發卡公司)或電子貨幣之每一種類而被複數設置。
＜2. 機能構成＞ 關於店舖伺服器1之機能構成，參照圖2來加以說明。 店舖伺服器1係具備：資訊取得部1a、送訊部1b、列印控制部1c、無效化指示部1d、收訊部1e。
資訊取得部1a，係進行將可特定下單者所致之下單的下單識別資訊加以取得之處理。 此處，說明下單識別資訊。下單識別資訊，係為從下單終端7被發送至店舖伺服器1的資訊。亦即，資訊取得部1a，係從下單終端7取得下單識別資訊。 下單識別資訊係由例如：可特定店舖的店舖代碼、可特定下單者所入席之桌子的桌子代碼、來到該桌子而接受服務的下單者所被賦予的固有之利用代碼、表示進行下單輸入之時間的日期時間代碼所成。
例如，店舖代碼是被設成「001」，桌子代碼是被設成「013」，來店代碼是被設成「002」(對該日來過該桌子的下單者依序賦予的號碼)，日期時間代碼是被設成「20181122110341」(表示2018年11月22日11時3分41秒)的情況下，下單識別資訊係被設成「00101300220181122110341」。此外，下單者進行了追加下單的情況下，則日期時間代碼為不同的別的下單識別資訊，會被賦予至追加下單。 當然，此下單識別資訊係僅為一例，例如，亦可不是使用日期時間代碼而是改為使用代表下單次數之代碼以削減下單識別資訊的資訊量(位元數)。
若下單終端7為店員所使用的終端，則藉由店員而輸入桌子代碼或來店代碼等，在下單終端7中就會進行下單識別資訊之生成。 又，若下單終端7是桌上設置型之終端且為下單者所使用的終端，則亦可構成為，由下單終端7自動生成下單識別資訊。例如亦可構成為，下單終端7中預先記憶有店舖代碼或桌子代碼，在下單者進行新的下單的情況下，則對上一次被使用過的來店代碼加算「1」而生成新的來店代碼，在確定了下單的時序上取得日期時間資訊並生成日期時間代碼，使用這些資訊而生成下單識別資訊。 除此以外，店舖伺服器1亦可預先具備有用來生成店舖代碼或桌子代碼所需之換算表或日期時間資訊。在如此情況下，亦可為，店舖伺服器1係將發送了下單資訊的下單終端7加以特定，隨應於其而從換算表取得桌子代碼，按照來店順序而賦予來店代碼，根據接收到下單資訊的日期時間資訊而生成日期時間代碼，使用這些各資訊和預先具有的店舖代碼來生成下單識別資訊，藉此而加以取得之。 下單識別資訊是由店舖伺服器1所生成之構成的情況下，下單識別資訊的生成處理就不需要由下單終端7來執行，因此可減輕處理負擔，可將廉價的終端當作下單終端7而採用。
此外，下單者識別資訊，係由於被賦予有桌子代碼和來店代碼，因此也可說是含有用來識別下單者所需之下單者識別資訊。 又，由於下單者識別資訊係含有店舖代碼，因次可將藉由同一演算法而被生成的每一店舖之下單識別資訊做同等對待。亦即，即使店舖不同，下單識別資訊仍不會重複，因此不需要隨著每一店舖而導入不同的系統。藉此，可在不同店舖間使用相同的系統，可期待系統導入成本之削減。
送訊部1b係進行，將下單終端7所受理到的下單之相關資訊發送至支付管理伺服器3之處理。具體而言，是將下單識別資訊與金額資訊當作支付用資訊而發送至支付管理伺服器3。 金額資訊，係亦可為每一品項的金額，在1次下單中將複數個商品予以下單的情況下則亦可為合計金額。
列印控制部1c係執行，1次的下單受理時，用來使列印物例如結帳傳票這類列印物被列印之處理。此外，本例中的列印控制部1c係進行，對列印物列印一維條碼或二維條碼這類代碼資訊的指示。 代碼資訊，係至少含有下單識別資訊。代碼資訊所被列印的列印物，係每次被列印就被交付給下單者(使用者)。此外，代碼資訊係亦可含有關於下單的支付金額資訊。 列印物上所被列印的代碼資訊，係藉由下單者所持有的行動電話等之使用者終端4而被讀取。讀取到代碼資訊的使用者終端4，係向支付管理伺服器3進行支付請求之送訊。藉此，下單者係可進行自身所下單之下單所涉及的支付。
無效化指示部1d，係在下單者進行追加下單，而有複數個列印物被交付給下單者的手邊的情況下，進行將為了使得只有含最新之追加下單的下單識別資訊成為有效，而使其他下單識別資訊變成無效化所需之指示，發送至支付管理伺服器3之處理。
收訊部1e係進行，將表示下單者所致之支付已完成的通知等各種資訊予以接收之處理。
關於支付管理伺服器3的機能構成，參照圖3來加以說明。 支付管理伺服器3係具備：支付用資訊收訊部3a、記憶處理部3b、支付請求收訊部3c、支付處理部3d、無效化處理部3e。
支付用資訊收訊部3a係進行，從店舖伺服器1接收支付用資訊，從支付用資訊抽出下單識別資訊與金額資訊之處理。
記憶處理部3b係進行，將已被抽出之下單識別資訊與金額資訊記憶在支付用DB61中之處理。
支付請求收訊部3c，係進行接收支付請求之處理。支付請求係含有：可特定支付用資料的下單識別資訊，與用來特定支付方法所需之資訊等之支付資訊。 支付資訊中係含有例如：複數種類的支付方法之中將下單者所選擇之支付方法予以特定所需之資訊。又，支付資訊中亦可含有信用卡號碼或安全性代碼等之資訊，亦可只含有用來取得這些資訊所需之作為關鍵的資訊(例如使用者ID(Identification)等)。
支付處理部3d，係基於下單者所指定的支付方法，而進行對發卡公司系統5或電子貨幣系統6等發送用來進行支付所必須之資訊的處理、或接收表示支付已完成之資訊的處理等。
無效化處理部3e，係基於從店舖伺服器1已接收之無效化指示，而進行將所定之支付用資訊變成無效化之處理。作為無效化處理之例子係例如，亦可將相應之記錄予以消去，亦可針對相應之記錄所被賦予的旗標，從表示有效之狀態改寫成表示無效之狀態。
＜3. 硬體構成＞ 圖1所示的構成店舖伺服器1、支付管理伺服器3、使用者終端4、發卡公司系統5或電子貨幣系統6的各種電腦裝置或終端、下單DB51、支付用DB61等之各裝置，係可以用可進行資訊處理及資訊通訊的如圖4所示的電腦裝置來加以實現。
此外，所有的電腦裝置並不一定要恰好具備圖4所示的各部，亦可為不具備一部分之構成的裝置、或將一部分之構成予以複數具備的裝置、或亦可為具備有圖4所示以外之構成的裝置。
於圖4中，電腦裝置之CPU(Central Processing Unit)101，係依照ROM( Read Only Memory)102中所記憶之程式、或從記憶部108載入至RAM( Random Access Memory )103之程式，而執行各種處理。RAM103中係還適宜記憶著，CPU101執行各種處理時所必須之資料等。 CPU101、ROM102、及RAM103，係透過匯流排104而彼此連接。該匯流排104上係還連接有輸出入介面105。 輸出入介面105上係被連接有：輸入部106、輸出部107、記憶部108、通訊部109。 輸入部106係由鍵盤、滑鼠、觸控面板等所構成。本實施形態中的使用者終端4上，用來取得(拍攝)代碼資訊的構成，是作為輸入部106而被設置。 輸出部107係由LCD(Liquid Crystal Display)、CRT (Cathode Ray Tube)、有機EL(Electroluminescence)面板等所成之顯示器、以及揚聲器等所構成。 記憶部108係由HDD(Hard Disk Drive)或快閃記憶體裝置等所構成。 通訊部109係進行透過網路1的通訊處理或機器間通訊。 輸出入介面105上係還可因應需要而連接有媒體驅動器110，可適宜裝著磁碟、光碟、光磁碟、或半導體記憶體等之可移除式媒體111，對可移除式媒體111進行資訊之寫入或讀出。
在如此的電腦裝置中，藉由通訊部109所致之通訊而進行資料或程式的上傳、下載。又，可透過可移除式媒體111來收授資料或程式。 藉由CPU101基於各種程式來進行處理動作，構成店舖伺服器1、支付管理伺服器3、使用者終端4、發卡公司系統5或電子貨幣系統6的各種電腦裝置或終端、作為下單DB51、支付用DB61所必要之資訊處理或通訊，會被執行。 此外，構成店舖伺服器1、支付管理伺服器3、使用者終端4、發卡公司系統5或電子貨幣系統6的各種電腦裝置或終端、構成下單DB51、支付用DB61的資訊處理裝置，係係不限於如圖4的電腦裝置為單一地構成，亦可為複數台電腦裝置被系統化而被構成。複數電腦裝置，係亦可由LAN等而被系統化，也可藉由利用網際網路等之VPN等而被配置在遠端。複數台資訊處理裝置中亦可包含有，藉由雲端運算服務而可利用的作為伺服器群(雲端)的資訊處理裝置。
圖2所示的作為店舖伺服器1之各機能或圖3所示的作為支付管理伺服器3之各機能係為，於資訊處理裝置中藉由以CPU101按照程式所執行的處理，而被實現的機能。但是以下說明的全部或部分之各構成之處理，係亦可藉由硬體來實現。 又各機能是以軟體來實現時，各機能係沒有必要以各自獨立的程式來實現。亦可藉由1個程式來執行複數機能之處理，亦可讓1個機能是由複數程式模組之合作而被實現。 又各機能亦可被分散於複數台資訊處理裝置。甚至亦可為，機能之1者，是藉由複數台資訊處理裝置而被實現。
店舖伺服器1所具備的下單DB51或支付管理伺服器3所具備的支付用DB61，係只要能夠讓店舖伺服器1或支付管理伺服器3分別進行存取，則無論是以何種加以實現均可。例如亦可在與店舖伺服器1相同之系統內的記憶部中形成所有下單DB51，也可將下單DB51之部分或全部，設置在單體、或遠端等之電腦系統中。當然，下單DB51係沒有必要被形成在一個裝置(例如一個HDD等)內。又，下單DB51也不一定要是以一個DB的方式而被構成。以下各例子中所說明的各DB，係僅為將實施形態之處理的關連資訊之記憶部，分別以一個DB之形態來加以例示而已。
＜4. 大略的處理之流程＞ 首先，參照附圖中所示的一例，說明各裝置所進行之處理之流程的概要。 具體而言，依序說明下單者所致之最初的下單被進行之際各終端或伺服器所執行之各處理(參照圖5)，和下單者所致之追加的下單被進行之際各終端或伺服器所執行之各處理(參照圖6)，和藉由下單者而下單費用之支付被進行之際各終端或伺服器所執行之各處理(參照圖7)。 此外，以下的說明中，是舉出來店客是來到餐廳等中而點餐用餐的情況為例子而進行各處理之說明。
＜4-1. 最初的下單之相關流程＞ 參照圖5，說明最初的下單所涉及之各處理之一例。 來到店舖的來店客在被店員帶到桌子後，店員就向自身所持有的手持型之下單終端7，進行用來生成下單識別資訊所需之資訊輸入。 例如，按下表示新來店客之受理的按鈕(新增鈕)，接下來，將來店客所坐的桌子號碼(或者吧檯的座位號碼)予以輸入。在下單終端7中，其他亦可進行來店者數之輸入等。
基於店員的上記操作，在下單終端7中，係在步驟S101中，進行下單識別資訊生成用之資訊輸入。
接著，店員係向來店者詢問點餐，將該資訊輸入至下單終端7。藉此，在下單終端7中係在步驟S102中，進行下單資訊輸入。 下單資訊之輸入係例如，藉由用來特定品項所需之號碼的輸入或用來特定品項所需之按鈕的按下，而被進行。 此外，以下將進行了下單的來店者，記載成「下單者」。
接下來，店員藉由按下下單確定鈕或下單送訊鈕，下單終端7係在步驟S103中執行下單資訊送訊處理。下單資訊係含有：用來生成下單識別資訊所需之資訊、或用來特定下單者所下單之品項的資訊。 此外，作為用來生成下單識別資訊所需之資訊係例如：用來特定是新增下單還是追加下單所需之資訊、和桌子號碼，係被發送。又，亦可取代用來生成下單識別資訊所需之資訊，改為生成下單識別資訊並發送。
步驟S103之處理中所被發送的下單資訊等之資訊，係在店舖伺服器1所致之步驟S201之處理中被接收。 在收訊處理中係執行，將已接收之資訊記憶在下單DB51中之處理、或將下單識別資訊予以生成之處理。
接著，店舖伺服器1係在步驟S202中，進行將下單識別資訊與金額資訊加以取得之處理。此處所取得的金額資訊，係為下單者所進行之下單的合計金額。又，下單識別資訊係例如，店舖代碼是被設成「001」，桌子代碼是被設成「013」，來店代碼是被設成「002」的情況下，初次的下單識別資訊係被設成「001013002001」。該下單識別資訊係被設成，含有下單者識別資訊(亦即「001013002」)。下單者識別資訊，係與其他下單者不同，是被設成可特定出是一位下單者(或一群下單者)的資訊。
店舖伺服器1，係在步驟S203中，進行將下單識別資訊與金額資訊當作支付用資訊而發送至支付管理伺服器3之處理。 店舖伺服器1，係在步驟S204中，進行令結帳傳票被列印之處理。結帳傳票列印處理中所被列印的結帳傳票上，係被列印有例如二維條碼。二維條碼中係含有下單識別資訊，根據該資訊就可特定出下單者所進行過的下單之合計金額。 此外，亦可被構成為，從支付管理伺服器3所被發送的列印之指示藉由店舖伺服器1加以接收而會執行步驟S204之列印處理。
又，步驟S203之處理中所被發送的下單識別資訊與金額資訊(亦即「支付用資訊」)，係亦可在支付管理伺服器3所致之步驟S301之處理中被接收。 支付管理伺服器3，係在後續的步驟S302中，進行將下單識別資訊與金額資訊建立關連而記憶在支付用DB61中之處理。
藉由執行圖5所示的各處理，下單者所進行之下單之相關資訊，就被記憶在店舖伺服器1所管理的下單DB51與支付管理伺服器3所管理的支付用DB61中。
＜4-2. 追加的下單之流程＞ 參照圖6，說明追加的下單所涉及之各處理之一例。 已經進行過某些下單的下單者，告知店員要下單追加之品項，則店員係對下單終端7輸入用來進行追加下單所需之各資訊。具體而言，按下表示這是追加下單的按鈕，並進行桌子號碼之輸入。 基於該操作，在下單終端7中，係在步驟S104中，進行下單識別資訊生成用之資訊輸入。
接著，在下單終端7中，係於步驟S105中，店員所致之追加下單資訊之輸入會被進行。具體而言，用來特定品項所需之號碼的輸入或用來特定品項所需之按鈕的按下，會被進行。 下單終端7，係於步驟S106中，進行將下單資訊等予以發送之處理。該處理係為和圖5的步驟S103相同之處理。
步驟S106之處理中所被發送的追加下單之相關資訊，係在店舖伺服器1所致之步驟S205之處理中被接收。在步驟S205的收訊處理中係執行，將已接收之資訊記憶在下單DB51中之處理、或將下單識別資訊予以生成之處理。此外，這裡所生成的下單識別資訊(或是下單終端7中所生成的下單識別資訊)，係被設成與用來特定初次下單內容所需之下單識別資訊不同的下單識別資訊。 例如，店舖代碼是被設成「001」，桌子代碼是被設成「013」，來店代碼是被設成「002」的情況下，第1次的下單也就是初次的下單識別資訊係被設成「001013002001」，第2次的下單也就是追加下單的下單識別資訊是被設成「001013002002」。
店舖伺服器1係在步驟S206中，取得下單識別資訊與金額資訊。此處所取得的金額資訊，係為同一下單者所進行過的複數次下單之中，未付款之下單的合計金額。 例如，初次的下單金額係為1000圓，追加的下單係為500圓，然後初次與追加的下單皆為未付款的情況下，則步驟S206中所被取得的金額資訊，係為1500圓。
店舖伺服器1係在步驟S207中，進行將下單識別資訊(在之前的例子中係為「001013002002」)與金額資訊(在之前的例子中係為「1500」)當作支付用資訊而予以發送之處理。
步驟S207中所被發送之支付用資訊，係在支付管理伺服器3所致之步驟S303之處理中被接收。 支付管理伺服器3係在步驟S304中，進行將已接收之支付用資訊記憶在支付用DB61中之處理。步驟S303及步驟S304之各處理，係為與圖5所示的步驟S301及步驟S302之各處理相同之處理。
結束了步驟S207之處理的店舖伺服器1，係在步驟S208中發送無效化指示。該處理係亦可為，不確認支付管理伺服器3所執行的步驟S303及步驟S304之處理是否已經完成，在步驟S207之處理之後立刻被執行。亦即，亦可在步驟S303之處理被執行之前，執行步驟S208之處理。
步驟S208中所進行的無效化指示之對象的支付用資訊，係為同一下單者在本次之追加下單之前所進行過的下單，且為未付款之下單，甚至未藉由無效化指示而被無效化的下單所涉及者。亦即，同一下單者在本次的下單之前都未進行過下單的情況、或在本次的下單之前所進行過的下單全部都已支付的情況下，則不執行步驟S208之處理。 例如，在圖5所示的下單之相關處理中，由於下單者所進行的下單係為初次的下單，因此在本次的下單以前並未進行過下單，所以相當於圖6的步驟S208之處理係不進行。
若以此處所舉的例子來說明，則步驟S208的無效化指示之對象的支付用資訊，係為下單識別資訊是被設成「001013002001」的資訊。
此外，這裡所謂的「同一下單者」中並不包含，即使是同一人物，仍被視為不同來店者而被受理的情況。亦即，前一天來店的客人在後一天以新客人的身份來店的情況下，則不視為同一下單者。
受理了無效化指示的支付管理伺服器3，係在步驟S305中，執行無效化處理。無效化處理，係藉由將具有對象之下單識別資訊的紀錄設成無效化，以使其從下單者進行支付之際之對象被排除的處理。 紀錄的無效化係藉由例如將旗標，從表示有效之狀態更新成表示無效之狀態，而被進行。
無效化指示進行後，店舖伺服器1係在步驟S209中，執行令結帳傳票被列印之處理。此處所被列印的結帳傳票上係被列印有，可特定出下單識別資訊(在此追加下單的例子中係為「001013002002」)的二維條碼。 此外，步驟S209之處理，係可和支付管理伺服器3所執行之步驟S305之處理為非同步地進行。
＜4-3. 支付的相關流程＞ 參照圖7，說明下單者進行支付之際的各處理之一例。 下單者想要用本身所持有的行動電話等之使用者終端4來進行支付，而進行為了使用使用者終端4來讀取結帳傳票上所被列印之二維條碼所需之操作，則使用者終端4係在步驟S501中，執行將代碼資訊(本例中係為二維條碼)之讀取操作予以受理之處理，在後續的步驟S502中，執行讀取處理。藉此，使用者終端4係可取得二維條碼中所含之下單識別資訊。
接著，使用者終端4係在步驟S503中，執行將已被使用者(下單者)所選擇(指定)之支付方法予以特定之處理。該處理係藉由例如，在畫面上顯示複數種支付方法，讓使用者從其中加以選擇，而加以實現。
使用者終端4，係在步驟S504中，執行支付請求送訊處理。 在支付請求送訊處理中，含有下單識別資訊與已被選擇之支付方法的資訊，是被當作支付請求而發送。此外，於支付請求送訊處理中，亦可構成為，除了下單識別資訊與可特定支付方法之資訊以外，還將支付金額予以發送。此情況下，藉由讀取代碼資訊，使用者終端4就可取得支付金額。
此處，關於步驟S503及步驟S504之各處理，舉出一例來加以說明。 在使用者終端4中係被安裝有，使用結帳傳票等上所被列印之代碼資訊(例如二維條碼)進行支付所需之專用的應用程式軟體(以下記載為「終端應用程式」)。 終端應用程式，係藉由輸入使用者ID與密碼而可以登錄會員的身份進行各項操作(亦即在登入狀態下的各項操作)。 使用者ID與密碼之資訊係被登錄在，支付管理伺服器3所管理的DB中。該DB中，係除此以外，而按照每一使用者ID而記憶著信用卡資訊或點數資訊等。
亦可藉由，把信用卡資訊或點數資訊是被記憶在支付管理伺服器3所管理之DB中，藉此，下單者係只要是登入狀態則在每次支付時就可不必進行信用卡資訊之輸入。藉此，在步驟S504之處理中，例如，就可只發送用來特定使用者所需之使用者ID與表示信用卡所致之支付是已被選擇的資訊與下單識別資訊。 藉此，由於不會進行信用卡資訊之收送訊，因此可以達成個人資訊之保護。又，可避免信用卡資訊之輸入被偷看的危險性。
此外，在步驟S503之選擇中，亦可選擇利用點數之支付等。例如，亦可所定之金額是以點數做支付，剩下的金額是以信用卡做支付。
此外，亦可藉由將所讀取到的二維條碼之影像資料直接在步驟S504中予以發送，以使得下單識別資訊之取得處理是在與使用者終端4不同的終端(例如支付管理伺服器3)中進行。
隨應於步驟S504之處理，支付管理伺服器3係在步驟S306中進行支付請求之收訊處理。在該處理中係進行，根據已接收之資訊而特定出使用者ID，並特定出已被選擇之付方法的處理。又，因應需要，而進行將與使用者ID建立關連的點數資訊或信用卡資訊加以取得之處理。
支付管理伺服器3係在步驟S307中，執行支付處理。圖7係圖示了下單金額的至少一部分是以信用卡而被支付的情況。 支付管理伺服器3，係在步驟S307中，對發卡公司系統5發送各種資訊，以發送授權委託。 此處所被發送的各種資訊係為例如：藉由信用卡而要支付的金額、信用卡的資訊等。
接收到授權委託的發卡公司系統5，係在步驟S401中，執行授權處理。在授權處理中，例如：信用卡的有效期限的檢查處理、信用卡的有效性(是否未被登錄在使用禁止清單中)確認處理、信用卡的可利用額之確認處理等，會被執行。
發卡公司系統5，係在步驟S402中，執行將授權結果予以通知之處理。 授權處理之結果，係為「授權」與「非授權」之任一者。授權結果是「授權」的情況下，支付管理伺服器3係在步驟S308中，執行支付完成通知處理。
支付完成通知處理，係對店舖伺服器1與使用者終端4而被進行。 接收到支付完成通知的店舖伺服器1，係作為步驟S210的支付完成通知收訊處理，是在下單DB51中所記憶的下單資訊之中，進行支付已完成之下單資訊的更新。在此更新處理中係進行，例如，將表示支付已完成的旗標予以記憶之處理。 對店舖伺服器1所管理的下單DB51中所被記憶之各下單資訊，設置表示支付已完成之旗標，藉此就可按照每一下單識別資訊而判定支付是否已完成。藉此，就可降低下單金額之支付被二重收取、或下單客在未付款的狀態下直接離店的可能性。
又，接收到步驟S308之支付完成通知的使用者終端4，係在步驟S505中，執行支付完成顯示處理。在該處理中，例如，「支付已經完成」等之通知，會被顯示在使用者終端4的畫面上。
另一方面，步驟S401之授權處理之結果為「非授權」的情況，則後續的步驟S308之處理係不被執行，取而代之的是，從支付管理伺服器3往店舖伺服器1或使用者終端4會發送表示支付無法完成之意旨的資訊。此外，支付管理伺服器3，係亦可不對店舖伺服器1進行支付無法完成之意旨的通知。 接收到表示支付無法完成之意旨之資訊的使用者終端4，係進行令畫面上等顯示出「無法完成支付」等之文字。 又，所指定的支付方法所致之支付為不成功的情況下，則下單者係利用別的支付方法，或是進行現金所致之支付。
此外，下單者選擇了利用電子貨幣來作為支付方法的情況下，取代步驟S401及步驟S402之處理的別的處理，是藉由管理電子貨幣的電子貨幣系統而被執行。 具體而言例如，是否為有效的使用者ID的判定處理、或點數餘額是否足夠的判定處理、或從點數扣除支付金額部分之處理等，是取代步驟S401或步驟S402之處理而被執行。
此外，如圖5、圖6及圖7的各處理，係不需要使用者終端4與店舖伺服器1間之通訊。亦即，店舖伺服器1，係不需要想定各式各樣的使用者終端4而執行處理，因此可簡化店舖伺服器1中所被實作的程式。因此，可削減為了建構店舖伺服器1所需之成本。
此外，針對已經完成支付的下單者又重新進行追加的下單的情況，參照圖6及圖7來加以說明。 下單終端7，係基於店員等之操作，而進行步驟S104的下單識別資訊生成用之資訊輸入處理、步驟S105的追加下單資訊輸入處理、步驟S106的下單資訊等送訊處理，而進行受理追加下單之輸入並發送至店舖伺服器1之處理。此外，由於目前為止的下單中並沒有未付款者，因此亦可如圖5所示般地視為新的來店客而做處理。此情況下，亦可生成例如含有新的下單者識別資訊的下單識別資訊。例如，亦可將店舖代碼是被設成「001」，桌子代碼是被設成「013」，來店代碼是被設成「003」，被附加有表示這是初次下單的「001」的「001013003001」，當作新的下單識別資訊。
店舖伺服器1係執行：步驟S205的下單資訊等收訊處理、步驟S206的下單識別資訊與金額資訊的取得處理、步驟S207的下單識別資訊與金額資訊的送訊處理。 步驟S207中發送至支付管理伺服器3的金額資訊，係為一度完成支付後所被進行的追加下單之全部予以合計的金額。
執行了步驟S207之處理的店舖伺服器1，係執行步驟S208的無效化指示處理。但是，由於要無效化的未付款之支付用資訊係為不存在，因此亦可不執行步驟S208之處理而進入步驟S209之處理。
支付管理伺服器3，係在步驟S303的下單識別資訊與金額資訊的收訊處理、步驟S304的記憶處理的執行後，執行步驟S305的無效化處理。 但是，在店舖伺服器1未執行步驟S208之處理的情況下，由於無法接收無效化指示，因此步驟S305之處理係不被執行。又，即使接收到無效化指示，在本例中由於應被無效化的支付用資訊係為不存在，所以在步驟S305的無效化處理中，從支付用DB61中所被記憶之各紀錄檢索出無效化對象之紀錄，並確認該對象之紀錄係為已支付之處理(或者確認對象之紀錄係為不存在之處理)，會被執行。
接著，參照圖7說明關於支付的各處理。 使用者終端4，係隨應於下單者之操作，而執行步驟S501的代碼資訊讀取操作受理處理、步驟S502的讀取處理、步驟S503的支付方法選擇處理、步驟S504的支付請求送訊處理。藉此，支付請求就被發送至支付管理伺服器3。
支付管理伺服器3，係在步驟S306中接收到支付請求之後，在步驟S307中執行支付處理。此時作為被發送至發卡公司系統5的金額資訊，係為前次支付完成後所進行的追加下單所相關之合計金額。 例如，假設在初次的下單中係下單了1000圓的品項，追加下單500圓的品項後，藉由支付處理來進行1500圓之支付。其後作為追加下單，而下單了300圓之品項的情況下，則在步驟S307的支付處理中被發送至發卡公司系統5的金額資訊就變成300圓。
發卡公司系統5，係進行步驟S401的授權處理與步驟S402的授權結果通知處理。藉此，就向支付管理伺服器3通知授權結果。
支付管理伺服器3，係在步驟S308中執行支付完成通知處理。隨應於此，在使用者終端4中係執行支付完成顯示處理(步驟S505)，在店舖伺服器1中係執行支付完成通知收訊處理(步驟S210)。
在步驟S210的支付完成通知處理中，在支付已經完成後，由同一下單者所致之追加的下單被進行的情況下，只有該追加下單之下單資訊會被當作未付款之下單資訊而被記憶在下單DB51中。藉此，可與已支付之下單資訊做明確地區別，可防止已支付之下單資訊所涉及之支付被再度進行。
此外，於圖5、圖6、圖7的各圖中，係每次資訊收送訊就會被進行的收訊確認所需之交訊(ACK等)雖然會被執行，但這類處理的圖示係被省略。
＜5. 各處理＞ 為了實現圖5、圖6、圖7的各圖中所說明的各裝置之處理的流程，關於店舖伺服器1、支付管理伺服器3及使用者終端4所執行之處理的一例，參照附圖而加以說明。
＜5-1. 下單資訊受理處理＞ 關於店舖伺服器1所執行的下單資訊受理處理之一例，參照圖8來加以說明。 此外，藉由執行圖8所示的一連串之處理，就可實現圖5的步驟S201至步驟S204之各處理、圖6的步驟S205至步驟S209之各處理。
店舖伺服器1係在步驟S601中，判定是否有從下單終端7接收到下單資訊。在未接收到下單資訊的情況下，則店舖伺服器1係再度執行步驟S601。此外，亦可將店舖伺服器1構成為，以已接收到下單資訊作為觸發，而執行步驟S602以後之各處理。
在判定為從下單終端7接收到下單資訊的情況下，店舖伺服器1係在步驟S602中，從已接收之下單資訊取得桌子代碼。 店舖伺服器1係在步驟S603中，判定已接收之下單資訊是否為涉及新下單者。是否為新下單之資訊，係可從從下單終端7所接收到的下單資訊，加以取得。
若是新下單，則店舖伺服器1係不執行步驟S604及步驟S605之各處理而前進至步驟S606之處理。 另一方面，若非新下單，亦即，是追加下單的情況下，則店舖伺服器1係在步驟S604中，進行從下單DB51取得前次的下單資訊之處理。
此外，在執行步驟S604之處理的階段中，下單DB51中所被記憶的資訊，係將本次從下單終端7所接收到的下單資訊予以排除而將已經接收過的下單資訊加以記憶。本次所接收到的下單資訊，係在後述的步驟S610之處理中被記憶在下單DB51中。 因此，所謂前次的下單資訊，係為本次的下單者所進行之下單，係為下單DB51中所被記憶的關於最新之下單的資訊。例如，本次的下單是來店後第2次進行的下單的情況下，此時點上下單DB51中所被記憶之下單資訊係只有關於初次下單的資訊，因此在步驟S604之處理中，係取得關於初次下單的下單資訊。
在步驟S604之處理中，係基於下單者識別資訊而進行檢索處理。具體而言，係檢索含有店舖代碼「001」、桌子代碼「013」、來店代碼「002」之紀錄，亦即，含有表示進行了本次下單之下單者的下單者識別資訊的紀錄。 此外，紀錄的檢索時所使用的資訊之中，店舖代碼，係為店舖伺服器1所管理的資訊。又，桌子代碼及來店代碼，係被包含在從下單終端7所接收到的下單資訊。
此處，關於下單者識別資訊與下單識別資訊的具體的構成例，參照圖9加以說明。 圖9A係將店舖伺服器1所管理的下單DB51中所被記憶之資訊之一例予以部分節錄而圖示。 對於每一可特定出一筆紀錄的紀錄No.，係分別有：店舖代碼、桌子代碼、來店代碼、下單次數、下單內容、合計金額、已支付旗標，係被記憶。 關於店舖代碼、桌子代碼、來店代碼係如同前述。
下單次數，係初次是被設成001，以後每次受理追加下單就逐次加算1。下單內容，係將品項No.與下單個數構成一組的資訊，予以記憶複數組。圖9A所示的紀錄係表示，受理了包含品項No.是被設成「019」與「031」之品項是各為一個，與品項No.是被設成「024」之品項係為二個的下單。
如圖9A所示，下單者識別資訊，係含有店舖代碼與桌子代碼與來店代碼之三筆資訊而被構成。亦即，藉由店舖代碼與桌子代碼與來店代碼，就可唯一特定下單者。 又，下單識別資訊，係除了店舖代碼與桌子代碼與來店代碼以外，還包含下單次數之資訊而被構成。亦即，藉由店舖代碼與桌子代碼與來店代碼與下單次數，就可唯一特定下單資訊。
回到圖8的說明。在步驟S604的處理中，藉由店舖代碼為「001」、桌子代碼為「013」、來店代碼為「002」而可被特定的下單者所進行的下單之中，前次的下單，亦即，下單次數為最大者，是從下單DB51而被取得。因此，例如，作為前次的下單資訊，會取得下單次數是被設成「001」的紀錄No.「000001」之紀錄。
接著，店舖伺服器1係在步驟S605中，取得下單次數。在本例中，係取得「001」。 店舖伺服器1係在步驟S606中，進行生成關於本次之下單資訊的下單識別資訊之處理。具體而言，店舖代碼與桌子代碼與來店代碼係將已取得之紀錄直接加以使用，同時，對已取得下單次數之值加算1而算出成為「002」。 此外，由於本次的下單係為新下單，因此不進行步驟S604及步驟S605之處理而執行步驟S606之處理的情況下，係將關於本次之下單的下單次數設定成「001」。
店舖伺服器1係在步驟S606中，生成下單識別資訊。下單識別資訊係為例如：根據店舖代碼、桌子代碼、來店代碼、下單次數而被生成的資訊，且為可唯一特定下單者所進行之下單的資訊。如圖9A所理解，關於一筆下單者識別資訊，亦可有複數筆下單識別資訊被建立對應。
店舖伺服器1係在步驟S607中，取得已受理下單的每一品項的單價資訊。關於單價資訊，參照圖9B加以說明。 單價資訊係被記憶在，將店舖所販售之每一商品(品項)之單價予以記憶而成的DB中。該DB，係由店舖伺服器1所管理。DB中所被記憶之資訊之一例的圖示係為圖9B。如圖示，對可唯一特定品項的每一品項No.，係有單價資訊是被建立關連而記憶。 步驟S607中所取得的單價資訊，係只有關於從下單終端7所接收到的下單資訊中所含之品項No.的單價資訊。若舉出前次的下單(圖9A中的紀錄No.是被設成「000001」的下單資訊)為例，則至少取得品項No.是被設成「024」、「031」、「019」之品項的單價資訊。
店舖伺服器1係在步驟S608中，從下單資訊取得下單數。若取出前次的下單為例，則關於品項No.是被設成「024」之品項係取得2，關於品項No.是被設成「031」之品項係取得1，關於品項No.是被設成「019」之品項係取得1，來作為下單數。
店舖伺服器1係在步驟S609中，算出下單合計金額。下單合計金額，係可根據步驟S607中所取得之單價資訊與步驟S608中所取得之下單數而算出。
店舖伺服器1係在步驟S610中，進行將本次之下單資訊記憶在下單DB51中之處理。例如，紀錄No.是被設成「000002」、店舖代碼是被設成「001」、桌子代碼是被設成「013」、來店代碼是被設成「002」、下單次數是被設成「002」，下單內容中係被儲存有從下單終端7所接收到的資訊，步驟S609中所算出之下單合計金額是被儲存至合計金額，已支付旗標是被設定成「False」的紀錄，係被記憶在下單DB51中。
此外，已支付旗標，係在關於下單之支付已經被進行的情況下就被變更成「True」。因此，下單DB51中記憶有新的下單資訊的情況下是被設定成「False」。
店舖伺服器1，係在步驟S611中，進行將支付用資訊發送至支付管理伺服器3之處理。在該處理中，例如，至少含有下單識別資訊與未付款之下單之合計金額的資訊，係被發送至支付管理伺服器3。
此外，所謂未付款之下單之合計金額，係將複數筆下單資訊之合計金額予以加算而獲得。 例如，關於藉由店舖代碼「001」、桌子代碼「013」、來店代碼「002」而可被特定之下單者的未付款之下單資訊之合計金額係為，前次的下單資訊(初次的下單資訊，且紀錄No.是被設成「000001」者)之合計金額(亦即「2460圓」)，與關於步驟S610中新被記憶之下單資訊的合計金額(例如「500圓」)，所合算而成的「2960圓」。 此外，已支付之紀錄與未付款之紀錄是複數存在的情況下，則設成關於未付款之下單資訊的合計金額所合算之金額，關於已支付之紀錄的金額係被除外。
店舖伺服器1係在步驟S612中，判定本次的下單是否為新下單。該判定處理，係為和步驟S603之處理相同之判定處理。
若本次的下單為新下單，則店舖伺服器1係不執行步驟S613之處理而往步驟S614之處理前進。 另一方面，本次的下單不是新下單的情況，亦即是追加下單的情況，則店舖伺服器1係執行步驟S613之處理。
在步驟S613中，進行對支付管理伺服器3的無效化指示送訊處理。 在無效化指示的送訊中，至少發送可特定無效化對象之支付用資訊的資訊。所謂可特定無效化對象之支付用資訊的資訊係為例如：下單識別資訊或下單者識別資訊。 在本例中，作為要進行無效化的下單識別資訊，是發送「001013002001」。
在步驟S613的執行後，或步驟S612中判定為本次的下單是新下單後，店舖伺服器1係在步驟S614中，進行指示結帳傳票之列印的處理。藉此，結帳傳票係被列印。此外，如上述，結帳傳票上係被列印有，可特定下單識別資訊的代碼資訊。 在步驟S614的執行後，店舖伺服器1係再次回到步驟S601之處理。
＜5-2. 支付用資訊收訊處理＞ 關於支付管理伺服器3所執行的支付用資訊收訊處理之一例，參照圖10來加以說明。 此外，藉由執行圖10所示的一連串之處理，就可實現圖5的步驟S301和步驟S302、圖6的步驟S303和步驟S304之各處理。
支付管理伺服器3，係在步驟S701中，進行判斷是否已經從店舖伺服器接收到支付用資訊的判定處理。在判定為未接收到的情況下，支付管理伺服器3係再度進行步驟S701之處理。此外，亦可將支付管理伺服器3構成為，以支付用資訊之收訊為觸發而執行步驟S702及步驟S703之處理。
判定為已接收到支付用資訊的支付管理伺服器3，係在步驟S702中，從已接收之資訊取得下單識別資訊與金額資訊。 接著，支付管理伺服器3，係在步驟S703中，進行將已取得之下單識別資訊與金額資訊建立關連而記憶在支付用DB61中之處理。
此處，關於支付用DB61中所被記憶之資訊之一例，參照圖11來加以說明。 支付用DB61中所被記憶之支付用資訊，係對可唯一特定一筆紀錄的紀錄No.，將下單識別資訊與金額資訊與有效旗標與已支付旗標，予以建立關連。 下單識別資訊係為例如：根據店舖代碼「001」、桌子代碼「013」、來店代碼「002」與下單次數「001」而被生成的資訊，且為下單者每次進行下單就被賦予的資訊。金額資訊，係在下單者進行支付的情況下，表示應支付之金額的合計。亦即，亦可為複數次份的下單資訊之合計金額之合算。
有效旗標，係為針對該當紀錄的表示支付是有效還是無效的旗標。圖11所示的狀態係為，有效旗標是被設成「True」，關於該紀錄之支付是被設成可進行的狀態。
此外，如前述進行500圓的追加下單，合計金額變成2960圓的情況下，則藉由將該下單資訊所涉及之支付用資訊從店舖伺服器1予以接收，在步驟S703中，新的紀錄No.是被設成「002」，下單識別資訊是被設成「001013002002」，金額資訊是被設成「2960」，有效旗標是被設成「True」，已支付旗標是被設成「False」的紀錄，係被記憶在支付用DB61中。 又，在支付用DB61中記憶有該當資訊的時點上，紀錄No.是被設成「001」之紀錄與被設成「002」之紀錄的雙方之有效旗標，係皆為「True」。
在步驟S703的執行後，支付管理伺服器3係再次回到步驟S701之處理。
＜5-3. 無效化指示收訊處理＞ 關於支付管理伺服器3所執行的無效化指示收訊處理之一例，參照圖12來加以說明。 此外，藉由執行圖12所示的一連串之處理，就可實現圖6的步驟S305之處理。
支付管理伺服器3係在步驟S711中，判定是否有從店舖伺服器3接收到無效化指示。未接收到無效化指示的情況下，支付管理伺服器3係再度執行步驟S711之處理。此外，亦可將支付管理伺服器3構成為，以無效化指示之收訊為觸發而執行步驟S712及步驟S713之處理。
在判定為已接收到無效化指示的情況下，支付管理伺服器3係在步驟S712中，進行取得用來從已接收之資訊特定出無效化對象之支付用資訊所需之下單識別資訊之處理。 例如，作為下單識別資訊係取得「001013002001」。
接著，支付管理伺服器3係在步驟S713中，進行將已被指定之下單識別資訊所涉及之支付用資訊之有效旗標變更成「False」之處理。該處理，係與把無效化旗標設成「ON」同義。 若以之前的例子來說，則在支付用DB61中被記憶有紀錄No.是被設成「002」之紀錄的時點上，紀錄No.是被設成「001」之紀錄與被設成「002」之紀錄之雙方的有效旗標雖然皆被設成「True」，但藉由執行步驟S713之處理，紀錄No.是被設成「001」之紀錄的有效旗標就會被設成「False」。亦即，只有紀錄No.是被設成「002」之紀錄的有效旗標會被設成「True」，因此可以防止錯誤地根據初次下單資訊而進行基於廉價之金額的支付。
在步驟S713的執行後，支付管理伺服器3係再次回到步驟S711之處理。
＜5-4. 終端應用程式啟動處理＞ 關於使用者終端4所執行的終端應用程式啟動處理之一例，參照圖13來加以說明。此外，圖13所示的一連串之處理，係隨應於令在使用者自身所使用之使用者終端4上進行支付所需之專用之終端應用程式被啟動之操作的進行，而由使用者終端4所執行之處理。 藉由使用者終端4執行圖13所示的一連串之處理，就可實現圖7的步驟S501至步驟S505之各處理。
偵測到終端應用程式之啟動操作的使用者終端4，係在步驟S801中判定是否為登入狀態。若非登入狀態，則使用者終端4係在步驟S802中，對使用者進行登入要求。具體而言係在畫面上顯示出用來進行登入所需之使用者ID輸入欄與登入密碼輸入欄，和用來令認證處理之執行被開始所需之登入鈕。
一旦使用者輸入使用者ID與登入密碼並按下登入鈕，則使用者終端4係在步驟S803中，執行登入認證處理。具體而言，將已被輸入之使用者ID與密碼予以加密而發送至支付管理伺服器3，令其執行認證處理，並且，進行認證結果之收訊及顯示。 在認證結果為「不可」的情況下，使用者終端4係再度進行步驟S802之登入要求。
登入認證處理的執行後，使用者終端4係在步驟S804中，判定是否受理了讀取操作指示。在步驟S804中等待直到有讀取操作之指示為止。
一旦使用者進行用來指示讀取操作所需之操作，則使用者終端4係在步驟S805中，進行令使用者終端4所具備之相機啟動之處理。 接下來，隨應於使用者的相機操作，使用者終端4係在步驟S806中進行代碼資訊之讀取。代碼資訊，係如前述，使至少含有下單識別資訊。
接下來，使用者終端4係在步驟S807中，進行提示支付方法選擇畫面之處理。例如，使用者終端4係進行，令畫面上顯示出可選擇的複數種支付方法，並顯示催促使用者做選擇之意旨的處理。
一旦使用者選擇了支付方法，則使用者終端4係在步驟S808中，執行將支付方法之選擇操作予以受理之處理，在步驟S809中，執行將支付請求發送至支付管理伺服器3之處理。
支付請求係為例如，將含有使用者ID等用來特定做使用之使用者所需之資訊，和步驟S806中所讀取到的下單識別資訊的代碼資訊，與用來特定已被使用者所選擇之支付方法所需之資訊，予以發送之處理。
接著，使用者終端4係在步驟S810中判定是否有接收到針對支付請求的通知。所謂針對支付請求的通知係為例如：表示支付已完成的「支付完成通知」或表示因為某種理由而無法完成支付的「無法支付通知」。 接收到支付完成通知的情況下，使用者終端4作為令步驟S811之通知內容予以顯示之處理，係執行令支付完成顯示被顯示在使用者終端4之畫面上的處理。 使用者終端4係在步驟S810之處理中做等待，直到接收到針對支付請求的通知為止。
此外，在步驟S810中接收到無法支付通知的情況下，使用者終端4作為步驟S811之通知內容顯示處理，係執行令無法支付顯示被顯示在畫面上之處理。
＜5-5. 支付請求收訊處理＞ 關於支付管理伺服器3所執行的支付請求收訊處理之一例，參照圖14來加以說明。 此外，藉由執行圖14所示的一連串之處理，就可實現圖7的步驟S306、步驟S307、步驟S308之各處理。
支付管理伺服器3係在步驟S721中，判定是否有從使用者終端4接收到支付請求。若未接收到支付請求，則支付管理伺服器3係再度執行步驟S721之處理。此外，亦可將支付管理伺服器3構成為，以支付請求之收訊為觸發而執行步驟S722至步驟S727之各處理。
判定為已接收到支付請求的支付管理伺服器3，係於步驟S722中，執行將使用者ID予以取得之處理。 接下來，支付管理伺服器3係在步驟S723中，進行將支付方法予以特定之處理。在該處理中係為，從作為支付請求而已接收之資訊取得用來特定支付方法所需之資訊的處理。
支付管理伺服器3係在步驟S724中，進行將支付方法所相應之資訊從DB加以取得之處理。圖14所示的例子係例示了，使用者選擇了信用卡所致之支付的情況。因此，在步驟S724中，係從DB取得信用卡之相關資訊。此外，若支付方法是使用點數的情況，則從DB取得點數資訊。又，若支付方法是使用電子貨幣的情況，則從DB取得電子貨幣之相關資訊。
支付管理伺服器3係在步驟S725中，進行利用額資訊之取得。該處理係為，從作為支付請求而已接收之資訊取得下單識別資訊，基於該下單識別資訊而從支付用DB61取得金額資訊(參照圖11)之處理。
支付管理伺服器3係在步驟S726中，對發卡公司系統5進行確保利用額度之委託。藉此，在發卡公司系統5中，會進行已被指定之信用卡的有效期限之確認或利用可否之確認等。
支付管理伺服器3係在步驟S727中，一直等待直到接收到額度確保結果為止。 在接收到額度確保結果的情況下，支付管理伺服器3係在步驟S728中進行支付完成通知或無法支付通知之送訊。藉此，支付完成通知或無法支付通知係對使用者終端4及店舖伺服器1發送。
此外，在店舖伺服器1中，因為支付完成通知的收訊，而將下單DB51中所被記憶之對象之紀錄的已支付旗標從「False」變更成「True」(參照圖9A)。
此外，作為支付方法是指定了電子貨幣所致之支付的情況下，則於步驟S724中雖然記載了，將電子貨幣之相關資訊從支付管理伺服器3所管理之DB加以取得，但亦可考慮除此以外的情況。例如，亦可由支付管理伺服器3來執行，從電子貨幣系統6所管理之DB取得電子貨幣之相關資訊(例如餘額等)之處理。此情況下，亦可連同與電子貨幣所致之支付相關之所定處理，一起向電子貨幣系統6委託電子貨幣之相關資訊之取得。又，此時，亦可在使用者終端4與電子貨幣系統6之間，進行登入之相關資訊的收送訊等。
＜6. 第2實施形態中的大致的處理之流程＞ 在第2實施形態中，相對於前述的實施形態(以下記載為「第1實施形態」)，進行列印指示之處理是由支付管理伺服器3所執行，以及，店舖伺服器1係不執行無效化指示，這點有所不同。
以下係針對與參照圖2至圖14之各圖所說明的第1實施形態不同的部分進行說明，關於和第1實施形態相同之部分則簡化或省略說明。
首先說明，第2實施形態所述之店舖伺服器1A與支付管理伺服器3A之構成。 第2實施形態所述之店舖伺服器1A，係如圖15所示，具備：資訊取得部1a、送訊部1b、列印控制部1c、收訊部1e。亦即，相較於第1實施形態的店舖伺服器1而不具備無效化指示部1d，這點係為特徵。
第2實施形態所述之支付管理伺服器3A，係如圖16所示，具備：支付用資訊收訊部3a、記憶處理部3b、支付請求收訊部3c、支付處理部3d、無效化處理部3e、列印指示部3f。亦即，相較於第1實施形態的支付管理伺服器3，具備有列印指示部3f，這點係為特徵。
亦即，對列印物的代碼資訊之列印，係藉由支付管理伺服器3A對店舖伺服器1A發送列印要求，或者，藉由支付管理伺服器3A對店舖中所管理之列印機器發送列印要求，而被進行。
又，將支付用資訊予以無效化之處理，係由接收到新的支付用資訊的管理伺服器3A把支付對象外的舊的支付用資訊予以特定之後，才會進行。該處理，係即使沒有從店舖伺服器1A接收到無效化指示仍可執行。
＜6-1. 第2實施形態中的最初的下單之相關流程＞ 關於第2實施形態中的最初的下單所相關之各資訊處理裝置之處理之流程之概要，參照圖17來加以說明。 來店的來店客來到桌子，店員使用下單終端7執行用來生成下單識別資訊所需之資訊輸入，以及下單資訊之輸入後，下單終端7係在執行了步驟S101及步驟S102之處理之後，於步驟S103中執行下單資訊等之送訊處理。
接收到下單資訊等(步驟S201)的店舖伺服器1A，係在步驟S202中取得下單識別資訊與關於下單之支付金額之資訊，在步驟S203中進行下單識別資訊與金額資訊之送訊。
接收到下單識別資訊與金額資訊(步驟S301)的支付管理伺服器3A，係在步驟S309中執行了將列印指示發送至店舖伺服器1A之處理後，在步驟S302中進行下單識別資訊與金額資訊之記憶處理。
接收到列印指示的店舖伺服器1A，係於步驟S211中，執行結帳傳票之列印處理。該處理係為例如，店舖伺服器1A對列印機器發送列印指示之處理。 亦即，與第1實施形態不同，店舖伺服器1A，係藉由從支付管理伺服器3A接收列印指示，而執行結帳傳票之列印處理。
此外，步驟S309之處理和步驟S302之處理，係任一處理先執行皆可。 又，於步驟S309之處理中，支付管理伺服器3A係亦可藉由向店舖所管理之網路中所屬之店舖伺服器1A以外之資訊處理裝置發送列印指示，而實現結帳傳票之列印。
＜6-2. 第2實施形態中的追加的下單之流程＞ 關於第2實施形態中的追加下單所相關之各資訊處理裝置之處理之流程之概要，參照圖18來加以說明。 店員使用下單終端7而輸入了追加下單所涉及之各種資訊之後，在下單終端7中係執行步驟S104、步驟S105、步驟S106之各處理。
接收到下單資訊等(步驟S205)的店舖伺服器1A，係在步驟S206中取得下單識別資訊與關於下單之支付金額之資訊，在步驟S207中進行下單識別資訊與金額資訊之送訊。
接收到下單識別資訊與金額資訊(步驟S303)的支付管理伺服器3A，係在步驟S310中執行了將列印指示發送至店舖伺服器1A之處理後，在步驟S304中進行下單識別資訊與金額資訊之記憶處理。
接收到列印指示的店舖伺服器1A，係在步驟S212中，執行結帳傳票之列印處理。
支付管理伺服器3A，係在步驟S311中執行無效化處理。 無效化處理係例如，進行使用下單識別資訊之處理。具體而言是進行，將同一下單者在這之前所進行過的下單從支付用DB61中檢索出來，將符合之紀錄予以無效化之處理。亦即，在支付用DB61中所被記憶的各紀錄之中，將具有與步驟S205中所接收到的下單資訊所具有之下單者識別資訊相同的下單者識別資訊的紀錄，換言之，將具有由同一店舖代碼與同一桌子代碼與同一來店代碼所成之下單者識別資訊的紀錄，特定成為無效化對象。然後，支付管理伺服器3A係執行，將已被特定之對象之紀錄的有效旗標設定「False」之處理。 此外，該無效化處理中，即使是具有同一下單者識別資訊的紀錄，若是已經被設成已支付的紀錄，亦即已支付旗標是被設成「True」的紀錄，則不視為無效化對象。當然，亦可無論已支付旗標為何，都把相符之紀錄的有效旗標設定成「False」。
在第2實施形態的無效化處理中，與第1實施形態不同地，不必從店舖伺服器1A接收無效化指示，支付管理伺服器3A就會執行無效化處理。亦即，店舖伺服器1A與支付管理伺服器3A間的資訊之收送訊係被省略，因此可達成雙方的資訊處理裝置的處理負擔之減輕。
此外，關於第2實施形態的支付之相關流程，係和圖7所示的第1實施形態相同，因此省略圖示及說明。
＜7. 第2實施形態中的各處理＞ 為了實現圖17、圖18、圖7的各圖中所說明的各裝置之處理的流程，關於店舖伺服器1A、支付管理伺服器3A及使用者終端4所執行之處理的一例，參照附圖而加以說明。
＜7-1. 第2實施形態中的下單資訊受理處理＞ 關於第2實施形態中的下單資訊受理處理之一例，參照圖19來加以說明。此外，關於與第1實施形態中的下單資訊受理處理(圖8)相同之處理，係標示相同符號並適宜省略說明。
店舖伺服器1A，係在步驟S601中判定是否有從下單終端7接收到下單資訊，若有接收到則執行步驟S602至步驟S606之各處理，以進行下單識別資訊之生成。 又，藉由店舖伺服器1A執行步驟S607至步驟S609之各處理，以進行本次所接收之下單資訊所涉及之金額(下單合計金額)的算出。
然後，店舖伺服器1A係在步驟S610中進行下單資訊之記憶處理，在步驟S611中進行將支付用資訊發送至支付管理伺服器3A之處理。
接著，店舖伺服器1A，係不對列印機器指示結帳傳票之列印，而是在步驟S621中判定是否有從支付管理伺服器3A接收到列印指示。店舖伺服器1A係在步驟S621中等待直到接收到列印指示為止。 確認到列印指示之收訊的店舖伺服器1A，係在步驟S622中，執行結帳傳票之列印處理。在該處理中，例如，對列印機器進行列印指示之送訊。
藉由店舖伺服器1A等待直到從支付管理伺服器3A發送列印指示，下單管理伺服器3A會在正常接收到下單識別資訊與金額資訊之後才執行列印處理，可避免使用使用者終端4進行支付處理之際支付管理伺服器3A未接收到下單資訊就進行支付處理這類不良情況，可實現確實的支付處理。
＜7-2. 支付用資訊收訊處理＞ 關於第2實施形態中的支付用資訊收訊處理之一例，參照圖20來加以說明。此外，第2實施形態的支付用資訊收訊處理中所進行的各處理，係相當於第1實施形態中的支付用資訊收訊處理(圖10)與無效化指示收訊處理(圖12)中所進行的各處理。
支付管理伺服器3A，係在步驟S701中確認支付用資訊之收訊，在步驟S702中取得下單識別資訊與金額資訊，在步驟S703中執行記憶處理。 支付管理伺服器3A，係在步驟S731中，執行將列印指示發送至店舖伺服器1A之處理。該處理係如前述，亦可為對店舖所管理之網路中所屬之店舖伺服器1A以外之資訊處理裝置的送訊處理。
接下來，支付管理伺服器3A係在步驟S712中，進行下單識別資訊之取得，在步驟S732中執行無效化對象之紀錄的檢索處理。在該檢索處理中，步驟S712中所取得之下單識別資訊(或是下單識別資訊中所含之下單者識別資訊)會被利用。
支付管理伺服器3A，係在步驟S733中，判定是否有檢索到無效化對象之紀錄。 若有檢索到無效化對象之紀錄，則支付管理伺服器3A係在步驟S713中，將關於對象之紀錄的無效化旗標設定成「ON」。這亦可如前述，藉由將有效旗標設定成「False」而加以實現。
另一方面，若未檢索到無效化對象之紀錄，則支付管理伺服器3A係再度執行步驟S701之處理。
＜8. 第3實施形態的大致的流程＞ 與前述的第1實施形態及第2實施形態相比較，在第3實施形態中，隨應於下單者之下單而在圖5的在步驟S203中從店舖伺服器1往支付管理伺服器3所被發送的資訊，係有所不同。具體而言，在第1實施形態及第2實施形態中，雖然進行了下單識別資訊與金額資訊之送訊，但在第3實施形態中，不進行金額資訊之送訊，這點有所不同。
關於具體的處理流程，參照圖21來加以說明。 直到店舖伺服器1從下單終端7接收到下單資訊為止，亦即直到步驟S201之處理執行為止，係執行和其他實施形態相同之處理，因此省略說明。
接收到相應於下單者之下單的下單資訊等的店舖伺服器1，係在步驟S213中，執行從已接收之資訊取得下單識別資訊之處理，在後續的步驟S214中，執行將該下單識別資訊發送至支付管理伺服器3之處理。亦即，此處係不進行金額資訊之送訊。
隨應於此，支付管理伺服器3係在步驟312中進行下單識別資訊之收訊，在步驟S302中進行該下單識別資訊之記憶處理。 藉此，可識別下單者之下單的資訊就被記憶。
關於下單者進行了追加下單所產生的圖6的各處理，係為和圖21所示的各處理相同之處理，因此省略說明。此外，關於步驟S305之無效化處理，係為使用旗標等而將符合之下單識別資訊予以無效化之處理。
接著，關於下單者使用使用者終端4來進行下單費用之支付的情況，說明數個例子。 關於第一個例子，參照圖7來加以說明。 使用者終端4，係藉由執行步驟S501至步驟S503之處理，以執行代碼資訊讀取操作之受理、讀取處理及支付方法選擇處理。接著，使用者終端4係在步驟S504中，執行支付請求送訊處理。 在本實施形態中，支付管理伺服器3係不進行下單金額之管理。亦即，在步驟S504之處理執行的時點上，藉由下單識別資訊而可被特定的下單的下單金額，支付管理伺服器3係並未掌握。 於是，在步驟S504的支付請求送訊處理中，從使用者終端4係除了下單識別資訊與可特定支付方法的資訊以外，還將支付金額予以發送。亦即，使用者終端4所讀取到的代碼資訊中係含有下單識別資訊與支付金額資訊。
支付管理伺服器3係在步驟S306中，執行支付請求收訊處理，在步驟S307中，執行支付處理。藉由該處理，從使用者終端4所接收到的金額資訊係被發送至發卡公司系統5，完成支付。
關於第二個例子，參照圖22來加以說明。 在本例中，除了從使用者終端4接收金額資訊，還從店舖伺服器1接收金額資訊，以確認金額的整合性。 藉由使用者終端4來執行步驟S501至步驟S504之各處理，含有金額資訊的支付請求會被發送。 支付管理伺服器3，係在步驟S306中接收到支付請求之後，在步驟S313中執行金額資訊確認處理。該處理，係藉由向店舖伺服器1發送下單識別資訊，以要求與該下單識別資訊建立關連之金額資訊，亦即下單者所應支付之金額之資訊的處理。
接收到要求的店舖伺服器1，係在步驟S215中取得與下單識別資訊建立關連的金額資訊，在步驟S216中進行向支付管理伺服器3發送該金額資訊之處理。
支付管理伺服器3，係在步驟S314中接收金額資訊，在步驟S315中執行整合性確認處理。整合性確認處理係為，確認從使用者終端4所接收到之金額資訊與從店舖伺服器1所接收到之金額資訊是否相符的處理。 在整合性確認處理執行後，支付管理伺服器3係執行步驟S307之支付處理。關於其後由各資訊處理裝置所執行的各處理，係為和前述相同之處理，因此省略說明。
關於第三個例子，參照圖22來加以說明。 在本例中，不從使用者終端4接收金額資訊。取而代之的是，從店舖伺服器1接收金額資訊。 藉由使用者終端4來執行步驟S501至步驟S504之各處理，不含金額資訊的支付請求會被發送。
支付管理伺服器3，係在步驟S306中接收到支付請求之後，在步驟S313中執行金額資訊確認處理。該處理，係藉由向店舖伺服器1發送下單識別資訊，以要求與該下單識別資訊建立關連之金額資訊，亦即下單者所應支付之金額之資訊的處理。
接收到要求的店舖伺服器1，係在步驟S215中取得與下單識別資訊建立關連的金額資訊，在步驟S216中進行向支付管理伺服器3發送該金額資訊之處理。
支付管理伺服器3，係在步驟S314中接收到金額資訊後，不執行步驟S315之處理而是執行步驟S307之支付處理。關於其後由各資訊處理裝置所執行的各處理，係為和前述相同之處理，因此省略說明。
＜9. 第3實施形態中的各處理＞ 為了實現圖21、圖6、圖22的各圖中所說明的各裝置之處理的流程，關於店舖伺服器1(1A)及支付管理伺服器3(3A)所執行之處理的一例，參照附圖而加以說明。
＜9-1. 下單資訊受理處理＞ 關於店舖終端1所執行的下單資訊受理處理，參照圖8來加以說明。此外，關於步驟S601至步驟S606之各處理，係為和其他實施形態相同之處理，因此省略說明。 步驟S607至步驟S609之各處理，係為用來算出下單合計金額所需之處理。在本實施形態中，從店舖終端1往支付管理伺服器3不需要發送下單合計金額，因此在步驟S611的支付用資訊送訊處理中，亦可只發送下單識別資訊。因此，步驟S611之處理，係亦可在步驟S606的處理之後緊接著進行。
關於店舖終端1A所執行的下單資訊受理處理(參照圖19)也是同樣如此。亦即，在圖19的步驟S611的支付用資訊送訊處理中，不進行下單合計金額之送訊。 藉此，在本實施形態中，從店舖終端1往支付管理伺服器3所被發送的資訊量係被設成最小限度，可達成通訊成本之削減。尤其是，對於進行了數次追加下單的下單者，因為被無效化而其後未被參照的下單合計金額，就會多次被發送至支付管理伺服器3。此情況下，就會變成只參照藉由最後的下單而被發送的下單合計金額。在本實施形態中，可抑制此種多餘的資訊之送訊。
＜9-2. 支付用資訊收訊處理＞ 關於店舖終端1所執行的支付用資訊收訊處理，參照圖10來加以說明。 與使用圖10所說明的第1實施形態，係在步驟S702之處理有所不同。具體而言，已接收之資訊中不包含有金額資訊，因此雖然進行下單識別資訊之取得，但不進行金額資訊之取得。因此，於步驟S703之記憶處理中也是，只進行下單識別資訊之記憶。
關於店舖終端1A所執行的支付用資訊收訊處理，參照圖20來加以說明。 此情況下也是同樣地，步驟S702之處理及S703之處理係為不同。 又，在步驟S731的列印指示送訊處理中，由於支付管理伺服器3並未保持金額資訊，因此藉由指定下單識別資訊以對店舖伺服器1A進行列印指示。店舖伺服器1A係基於已接收之下單識別資訊而特定出金額資訊，進行含有該資訊的結帳傳票之列印。 如此，在本實施形態中，隨應於支付用資訊收訊處理而被支付管理伺服器3所記憶的資訊係被設成只有下單識別資訊，因此可精簡所被使用的記憶領域，可對成本削減有所貢獻。
＜9-3. 支付請求收訊處理＞ 關於支付管理伺服器3所執行的支付請求收訊處理，參照圖14來加以說明。此外，圖14所示的一連串之處理(或是後述的圖23、圖24所示的一連串之處理)，係亦可為由支付管理伺服器3A來執行的處理。 此外，關於步驟S721至步驟S724之各處理，係為和其他實施形態相同之處理，因此省略說明。
取得了信用卡資訊的支付管理伺服器3，係接著取得關於利用額之資訊。具體而言，支付管理伺服器3係在步驟S725中，執行從步驟S721中所接收之資訊抽出利用額資訊之處理。亦即，相對於在之前的例子中是進行了從支付管理伺服器3所管理之DB取得資訊，在本實施形態中，則是從已經使用者終端4所接收到的資訊中，抽出利用額資訊。
在本例中，使用從使用者終端4所取得之金額資訊而執行支付處理(亦即圖14所示的一連串之處理)。亦即，由於不從店舖伺服器1取得金額資訊，因此店舖伺服器1與支付管理伺服器3之間所被進行的資訊之收送訊處理可以變得較少，所以可達成處理負擔之減輕及通訊量之削減。
關於支付管理伺服器3所執行的支付請求收訊處理之另一例，參照圖23來加以說明。 支付管理伺服器3係在步驟S725中，執行從步驟S721中所接收之資訊抽出利用額資訊之處理。接著，支付管理伺服器3係在步驟S731中，執行金額資訊確認處理。該處理，係為圖22的步驟S313之處理，亦即是向店舖伺服器1要求金額資訊之送訊的處理。藉由該處理，對店舖伺服器1就會發送下單識別資訊。
支付管理伺服器3係在在步驟S732中從店舖伺服器1接收金額資訊。 支付管理伺服器3係在在步驟S733中執行整合性確認處理。該處理係為，判定從使用者終端4所接收之利用額資訊與從店舖伺服器1所接收到之金額資訊是否相同的處理。 二筆金額資訊為不同的情況下，支付管理伺服器3係向使用者終端4及店舖伺服器1通知無法成功支付之意旨。
二筆金額資訊為相同的情況下，支付管理伺服器3係執行步驟S726至步驟S728之各處理。藉此，使用了使用者終端4的下單者之支付就完成。
在本例中，藉由使用二筆金額資訊來確認整合性，就可防止因為支付錯誤金額而導致的不利益。亦即，可使用適切的金額資訊來執行支付處理。
此外，在二筆金額資訊為不同的情況下，則步驟S723中所取得之支付方法、或步驟S724中所取得之信用卡資訊等，就變成不會被使用。 因此，關於步驟S725、步驟S731、步驟S732、步驟S733之各處理，係亦可在步驟S722之處理執行後緊接著執行。藉此，在二筆金額資訊為不同的情況下，不必執行未使用之資訊(支付方法或信用卡資訊)的取得處理，因此可達成處理負擔之減輕。
關於支付管理伺服器3所執行的支付請求收訊處理之再另一例，參照圖24來加以說明。 支付管理伺服器3，係在執行了步驟S721至步驟S724之各處理後，在步驟S731中執行金額資訊確認處理。藉由該處理，金額資訊之要求就被發送至店舖伺服器1。
一旦藉由店舖伺服器1而發送了金額資訊，則支付管理伺服器3係在在步驟S732中進行該金額資訊之收訊處理。 支付管理伺服器3，係在步驟S726中進行利用額之額度確保委託。關於其後之各處理則省略說明。
在本例中，支付管理伺服器3係不保持金額資訊，在接收到支付請求之際才首次取得之。又，金額資訊之取得係從店舖伺服器1進行，不包含在從使用者終端4所接收到的資訊中。 亦即，金額資訊之收送訊係被設成必要之最低限度，可進行通訊成本之削減(亦即通訊流量之削減或通訊處理之負擔減輕或通訊費用之削減等)。
＜10. 總結＞ 如上述各例所說明，作為店舖伺服器1的資訊處理裝置，係具備：資訊取得部1a，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部1b，係將下單識別資訊(亦可除此以外還包含有關於前記下單的作為支付金額的金額資訊)當作支付用資訊而予以發送；和列印控制部1c，係令下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化指示部1d，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置(支付管理伺服器3)進行：為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示。 下單識別資訊，係為可將下單者所致之下單做唯一特定的資訊。亦即，不是將關於已下單之一件一件的品項(商品)的資訊予以收送訊，而是藉由下單識別資訊之收送訊，就可將下單予以特定。因此，例如，作為支付進行之際所發送的資訊，是進行下單識別資訊之收送訊，藉此，就不需要按照每一品項進行資訊之收送訊，可對資訊處理裝置(店舖伺服器1或支付管理伺服器3)之處理負擔之減輕或通訊帶域之有效利用做出貢獻。 又，藉由將下單識別資訊(亦可包含有金額資訊(下單總額))當作支付用資訊而預先發送給進行支付處理的其他資訊處理裝置(支付管理伺服器3)，在進行支付處理之際，只需進行下單識別資訊之送訊就能令支付處理被執行，因此可削減支付管理伺服器3中的支付處理所需要的時間。尤其是，在上述的各例中，進行支付處理之際的下單識別資訊之送訊是由下單者所利用的使用者終端4來進行，因此進行支付處理之際的店舖伺服器1之處理負擔會被顯著減輕。 甚至，在受理了下單者所致之追加下單的情況下，藉由進行把目前為止已經發送給支付管理伺服器3的支付用資訊設成無效化所需之無效化指示，在同一下單者所致之未付款之支付用資訊是有複數存在的情況下，則使得只有最新的支付用資訊會是有效狀態。藉此，進行支付處理之際所處理的資料會是只有最新的支付用資訊，因此可縮短支付處理所需要的時間，可達成支付管理伺服器3的處理負擔之減輕。 此外，藉由指示可特定下單識別資訊的列印物之列印處理，可在與資訊處理裝置(店舖伺服器1)不同的終端，例如下單者所使用的行動電話等之下單者終端(使用者終端4)上，進行下單識別資訊之讀取。藉此，可基於所讀取到的下單識別資訊而從下單者終端(使用者終端4)進行支付請求。亦即，在資訊處理裝置(店舖伺服器1)上不必執行發送支付請求之處理，因此可達成資訊處理裝置(店舖伺服器1)的處理負擔之減輕。尤其是，在下單者有複數名，該複數名下單者欲同時進行支付的情況下，也會有支付請求之送訊發生重複的可能性。用一個終端(店舖伺服器1)來進行支付請求之送訊的情況下，雖然會有發生處理負擔之增加或支付請求之送訊處理之延遲之虞，但像是本構成這樣，藉由使得使用下單者終端(使用者終端4)等之其他終端的支付請求之送訊處理成為可能，就可分散支付請求之送訊處理，可避免處理負擔集中於一個終端(店舖伺服器1)或進行有效率的處理。又，下單者不必為了結帳而排隊，可避免浪費時間之事態。 此外，在上記的各例中，在店舖伺服器1與使用者終端4之間不必進行資訊通訊，就可實現從下單的受理到支付為止。亦即，在店舖伺服器1中，不必實作為了接收從各式各樣的使用者終端4所被發送之資訊所需之處理，因此可削減用來建構店舖伺服器1所需之成本。又，店舖伺服器1的處理負擔係被減輕，因此可降低店舖伺服器1之性能，也可對店舖伺服器1本身的成本削減做出貢獻。又，由於不需要針對多數的使用者終端4保持資訊，因此可達成店舖伺服器1所維護的DB之削減或店舖伺服器1所具備的記憶部之削減。 此外，藉由使用具備：收訊部(支付用資訊收訊部3a)，係將可特定下單者所致之下單的下單識別資訊(亦可除此以外還包含有關於前記下單的作為支付金額的金額資訊)予以接收而作為支付用資訊；和列印控制部(列印指示部3f)，係令下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化處理部3e，係在受理了下單者所致之追加下單的情況下，進行為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化處理，的資訊處理裝置(支付管理伺服器3A)，亦可獲得上記的作用或效果。
如機能構成之說明、或圖9之說明等，作為店舖伺服器1的資訊處理裝置中所處理的下單識別資訊，係亦可包含用來識別下單者的下單者識別資訊。 藉由使下單識別資訊含有可特定下單者之資訊，只須解析下單識別資訊就可判定是否為同一下單者所致之下單。 藉此，藉由無效化指示而被無效化的同一下單者所致之支付用資訊之特定就會變得容易，因此可達成處理負擔之減輕。
如機能構成之說明、或圖9之說明等，作為店舖伺服器1的資訊處理裝置中所處理的下單者識別資訊，係亦可包含可特定受理了下單之店舖的資訊。 藉由使可特定顧客之資訊也含有可特定店舖之資訊，顧客特定資訊係被設成隨每一店舖而不同的資訊。 亦即，從複數家店舖所被分別發送的顧客特定資訊係不會有重複，因此不需要按照每一店舖而設置不同的支付管理伺服器3，可達成處理負擔之減輕及系統導入成本之削減。 又，下單者識別資訊，係亦可被設成不含有下單者的個人資訊。例如，亦可由表示進行了下單之店舖的店舖代碼、和表示下單者所利用之桌子的桌子代碼、和表示利用該桌子之順序的利用代碼，來構成下單者識別資訊。藉此，由於下單者識別資訊中不含下單者的個人資訊，因此從個人資訊保護的觀點來看，處理下單識別資訊之際的便利性較高。
如列印控制部1c之機能說明等，作為店舖伺服器1的資訊處理裝置所執行的列印處理係亦可被設成，將可特定下單識別資訊的代碼資訊(例如二維條碼)列印於列印物之處理。 藉此，作為代碼資訊，可以利用一般普及的一維條碼或二維條碼。 亦即，可將既存之技術適用於本構成，因此可削減開發成本等。
如圖7等所說明，在作為店舖伺服器1的資訊處理裝置中，亦可具備：收訊部1e，係從其他資訊處理裝置(支付管理伺服器3)接收表示支付已完成之通知來作為支付完成通知。 藉由接收支付完成通知，就可判別下單者是否已經支付了費用。 藉此，可值只未支付費用的這類不當行為。又，可使支付是否有被進行之確認處理簡易化，因此可達成資訊處理裝置(店舖伺服器1)或操作員(店員)的處理負擔之減輕。
關於支付的流程中如使用圖6、圖7所說明，在作為店舖伺服器1的資訊處理裝置中，在接收到關於下單者所致之下單的支付完成通知之後，受理了同一下單者所致之追加下單的情況下，送訊部1e係亦可將在支付完成通知之收訊後所被進行且為未付款之追加下單的合計金額之資訊予以發送，來作為金額資訊。但是，此情況下，關於下單的作為支付金額的金額資訊，係被包含在支付用資訊中。 亦即，關於已支付之下單之金額是已被扣除的通知，會對其他資訊處理裝置(例如支付管理伺服器3)進行。 藉此，於支付管理伺服器3中不必進行關於已支付之下單的金額之減算的處理等，因此可達成支付管理伺服器3的處理負擔之減輕。尤其是，在從多數家店舖接收支付用資訊的此種情況下，有可能會一次就接收多數筆資訊。在此種情況下，支付管理伺服器3的處理能力有可能會成為瓶頸，但像是本構成這樣，藉由減輕支付用資訊之收訊處理或記憶處理所涉及之支付管理伺服器3的負擔，而可執行圓滑的處理。又，可處理來自較多店舖之委託。甚至，由於可將處理能力較低的廉價的電腦當作支付管理伺服器3而採用，因此可達成系統成本之削減。
又，作為支付管理伺服器3的資訊處理裝置，係具備：支付用資訊收訊部3a，係將可特定下單者所致之下單的下單識別資訊(亦可除此以外還包含有金額資訊)予以接收而作為支付用資訊；和記憶處理部3b，令已接收之支付用資訊之記憶處理被執行；和支付請求收訊部3c，係從下單者所利用之下單者終端(使用者終端4)接收含有下單識別資訊與該下單者之支付資訊(例如用來特定支付方法的資訊)的支付請求；和支付處理部3d，係基於支付請求而進行關於支付用資訊的支付處理；和無效化處理部3e，係在受理了下單者所致之追加下單的情況下，受理為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示，並進行已被記憶之支付用資訊的無效化。 藉由無效化處理部3e所致之無效化處理，只有具有最新下單識別資訊的支付用資訊會是有效，可防止費用被雙重支付。
又，在具備店舖伺服器1和支付管理伺服器3的支付系統中，店舖伺服器1或支付管理伺服器3之任一資訊處理裝置，係具備：資訊取得部1a，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部1b，係將下單識別資訊(亦可除此以外還包含有金額資訊)當作支付用資訊而予以發送；和列印控制部1c(或列印指示部3f)，係令下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化指示部1d，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置(支付管理伺服器3)進行：為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示；和支付用資訊收訊部3a，係接收支付用資訊；和記憶處理部3b，令已接收之支付用資訊之記憶處理被執行；和支付請求收訊部3c，係從下單者所利用之下單者終端(使用者終端4)接收含有下單識別資訊與該下單者之支付資訊的支付請求；和支付處理部3d，係基於支付請求而進行關於支付用資訊的支付處理；和無效化處理部3e，係將來自無效化指示部的無效化指示予以受理並進行已被記憶之支付用資訊的無效化。 藉此，可建構出能夠獲得如上述之各種效果的系統。 又，上記的支付系統，係亦可具備：資訊取得部1a，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部1b，係將下單識別資訊(亦可除此以外還包含有關於下單的作為支付金額的金額資訊)當作支付用資訊而予以發送；和支付用資訊收訊部3c，係接收支付用資訊；和記憶處理部3b，令已接收之支付用資訊之記憶處理被執行；和列印控制部(列印控制部1c或列印指示部3f)，係令下單識別資訊之特定為可能的列印物之列印處理被執行；和無效化處理部3e，係在受理了下單者所致之追加下單的情況下，進行為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化處理；和支付請求收訊部3c，係從下單者所利用之下單者終端接收含有下單識別資訊與該下單者之支付資訊的支付請求；和支付處理部3d，係基於支付請求而進行關於支付用資訊的支付處理。 此外，該當支付系統中係也包含有，關於不依賴支付管理伺服器3A之處理就會由店舖伺服器1來進行列印物(例如結帳傳票)之列印指示，並且，下單識別資訊之無效化處理係不依賴店舖伺服器1A之處理而由支付管理伺服器3A來執行的構成。
＜11. 程式及記憶媒體＞ 以上說明了本發明的作為資訊處理裝置的實施形態的店舖伺服器1，但實施形態的程式係為令下單者所利用之使用者終端4的資訊處理裝置(CPU等)，執行各種處理的程式(例如被安裝在使用者終端4中的應用程式)等。
實施形態的程式，係令資訊處理裝置(例如使用者終端4)的演算處理裝置，執行從列印物(例如二維條碼)讀取可特定下單的下單識別資訊之處理。 又，令資訊處理裝置(例如使用者終端4)的演算處理裝置，執行發送含有針對在被進行無效指示而被無效化之支付用資訊之後所進行之下單且為未付款之下單而為了進行支付所需之支付資訊與所讀取到之下單識別資訊的支付請求之處理。 亦即該程式係為，對資訊處理裝置(例如使用者終端4)而令其執行圖7所說明之步驟S501至步驟S505之處理的程式。
藉由此種程式，可實現上述的作為使用者終端4的1或複數個資訊處理裝置。 而且此種程式，係可預先記憶在電腦裝置等之機器中所內建的作為記憶媒體之HDD、或具有CPU的微電腦內之ROM等中。又或者，可以暫時或永久性地被儲存(記憶)在半導體記憶體、記憶卡、光碟、光磁碟、磁碟等之可移除式記憶媒體中。又此種可移除式記憶媒體，係可用所謂的套裝軟體的方式來做提供。 又，此種程式，係除了可從可移除式記憶媒體安裝至個人電腦等以外，也可從下載網站，透過LAN、網際網路等之網路而下載之。
1,1A:店舖伺服器 1a:資訊取得部 1b:送訊部 1c:列印控制部 1d:無效化指示部 1e:收訊部 2:通訊網路 3,3A:支付管理伺服器 3a:支付用資訊收訊部 3b:記憶處理部 3c:支付請求收訊部 3d:支付處理部 3e:無效化處理部 3f:列印指示部 4:使用者終端 5:發卡公司系統 6:電子貨幣系統 7:下單終端 51:下單DB 61:支付用DB 101:CPU 102:ROM 103:RAM 104:匯流排 105:輸出入介面 106:輸入部 107:輸出部 108:記憶部 109:通訊部 110:媒體驅動器 111:可移除式媒體
[圖1] 含有本發明之實施形態的店舖伺服器的網路的說明圖。 [圖2] 實施形態的店舖伺服器之機能構成的說明圖。 [圖3] 實施形態的支付管理伺服器之機能構成的說明圖。 [圖4] 實施形態的電腦裝置的區塊圖。 [圖5] 下單者所致之最初的下單被進行之際各終端或伺服器所執行之各處理的說明圖。 [圖6] 下單者所致之追加的下單被進行之際各終端或伺服器所執行之各處理的說明圖。 [圖7] 藉由下單者而下單費用之支付被進行之際各終端或伺服器所執行之各處理的說明圖。 [圖8] 下單資訊受理處理之一例的流程圖。 [圖9] 下單DB中所被記憶之下單資訊等的說明圖。 [圖10] 支付用資訊收訊處理之一例的流程圖。 [圖11] 支付用DB中所被記憶之資訊的說明圖。 [圖12] 無效化指示收訊處理之一例的流程圖。 [圖13] 終端應用程式啟動處理之一例的流程圖。 [圖14] 支付請求收訊處理之一例的流程圖。 [圖15] 第2實施形態的店舖伺服器之機能構成的說明圖。 [圖16] 第2實施形態的支付管理伺服器之機能構成的說明圖。 [圖17] 第2實施形態的下單者所致之最初的下單被進行之際各終端或伺服器所執行之各處理的說明圖。 [圖18] 第2實施形態的下單者所致之追加的下單被進行之際各終端或伺服器所執行之各處理的說明圖。 [圖19] 第2實施形態的下單資訊受理處理之一例的流程圖。 [圖20] 第2實施形態的支付用資訊收訊處理之一例的流程圖。 [圖21] 第3實施形態的下單者所致之最初的下單被進行之際各終端或伺服器所執行之各處理的說明圖。 [圖22] 第3實施形態的藉由下單者而下單費用之支付被進行之際各終端或伺服器所執行之各處理的說明圖。 [圖23] 第3實施形態的支付請求收訊處理之例子的流程圖。 [圖24] 第3實施形態的支付請求收訊處理之另一例子的流程圖。

Claims (13)

  1. 一種資訊處理裝置，係具備：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予以發送；和列印控制部，係令列印有可特定前記下單識別資訊之資訊的列印物之列印處理被執行；和無效化指示部，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示。
  2. 如請求項1所記載之資訊處理裝置，其中，前記下單識別資訊係被設成，含有用來識別下單者的下單者識別資訊。
  3. 如請求項2所記載之資訊處理裝置，其中，前記下單者識別資訊係含有：可特定受理了下單之店舖的資訊。
  4. 如請求項1至請求項3之任一項所記載之資訊處理裝置，其中， 前記列印處理係被設成，將可特定前記下單識別資訊的代碼資訊列印至前記列印物的處理。
  5. 如請求項4所記載之資訊處理裝置，其中，具備：收訊部，係從前記其他資訊處理裝置接收表示支付已完成之通知來作為支付完成通知。
  6. 如請求項5所記載之資訊處理裝置，其中，前記支付用資訊中係含有：關於前記下單的作為支付金額的金額資訊；在接收到關於下單者所致之下單的前記支付完成通知之後，受理了同一下單者所致之追加下單的情況下，前記送訊部，係將在前記支付完成通知之收訊後所被進行且為未付款之追加下單的合計金額之資訊予以發送，以作為前記金額資訊。
  7. 一種資訊處理裝置，係具備：支付用資訊收訊部，係將可特定下單者所致之下單的下單識別資訊予以接收而作為支付用資訊；和記憶處理部，令已接收之前記支付用資訊之記憶處理被執行；和支付請求收訊部，係從下單者所利用之下單者終端接收含有下單識別資訊與該下單者之支付資訊的支付請求；和 支付處理部，係基於前記支付請求而進行關於支付用資訊的支付處理；和無效化處理部，係在受理了下單者所致之追加下單的情況下，受理為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示，並進行已被記憶之前記支付用資訊的無效化。
  8. 一種資訊處理方法，係由資訊處理裝置執行：資訊取得步驟，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊步驟，係將前記下單識別資訊當作支付用資訊而予以發送；和列印控制步驟，係令列印有可特定前記下單識別資訊之資訊的列印物之列印處理被執行；和無效化指示步驟，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示。
  9. 一種支付系統，係具備：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予 以發送；和列印控制部，係令列印有可特定前記下單識別資訊之資訊的列印物之列印處理被執行；和無效化指示部，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示；和支付用資訊收訊部，係接收前記支付用資訊；和記憶處理部，令已接收之前記支付用資訊之記憶處理被執行；和支付請求收訊部，係從下單者所利用之下單者終端接收含有前記下單識別資訊與該下單者之支付資訊的支付請求；和支付處理部，係基於前記支付請求而進行關於支付用資訊的支付處理；和無效化處理部，係將來自前記無效化指示部的無效化指示予以受理並進行已被記憶之前記支付用資訊的無效化。
  10. 一種資訊處理裝置，係具備：收訊部，係將可特定下單者所致之下單的下單識別資訊予以接收而作為支付用資訊；和列印控制部，係令列印有可特定前記下單識別資訊之資訊的列印物之列印處理被執行；和 無效化處理部，係在受理了下單者所致之追加下單的情況下，進行為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化處理。
  11. 一種支付系統，係具備：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予以發送；和支付用資訊收訊部，係接收前記支付用資訊；和記憶處理部，令已接收之前記支付用資訊之記憶處理被執行；和列印控制部，係令列印有可特定前記下單識別資訊之資訊的列印物之列印處理被執行；和無效化處理部，係在受理了下單者所致之追加下單的情況下，進行為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化處理；和支付請求收訊部，係從下單者所利用之下單者終端接收含有前記下單識別資訊與該下單者之支付資訊的支付請求；和支付處理部，係基於前記支付請求而進行關於支付用資訊的支付處理。
  12. 一種資訊處理裝置，係具備：資訊取得部，係將可特定下單者所致之下單的下單識別資訊，加以取得；和送訊部，係將前記下單識別資訊當作支付用資訊而予以發送；和列印控制部，係令列印有可特定前記下單識別資訊之代碼資訊的列印物之列印處理，在每次受理下單時被執行；和無效化指示部，係在受理了下單者所致之追加下單的情況下，對其他資訊處理裝置進行：為了使得同一下單者所致之未付款之下單的下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示；前記代碼資訊係可被終端所讀取。
  13. 一種資訊處理裝置，係具備：支付用資訊收訊部，係將可特定下單者所致之下單的下單識別資訊予以接收而作為支付用資訊；和記憶處理部，令已接收之前記支付用資訊之記憶處理被執行；和支付請求收訊部，係從下單者所利用之下單者終端，接收含有下單識別資訊與該下單者之支付資訊的支付請求，其中，該下單識別資訊係藉由讀取每次受理下單時所被列印之列印物上所被列印的代碼資訊即可加以特定；和 支付處理部，係基於前記支付請求而進行關於支付用資訊的支付處理；和無效化處理部，係在受理了下單者所致之追加下單的情況下，受理為了使得同一下單者所致之未付款之下單識別資訊所相關之支付變成不可能而將該下單識別資訊予以無效化的無效化指示，並進行已被記憶之前記支付用資訊的無效化。
TW108135634A 2018-12-27 2019-10-02 資訊處理裝置、資訊處理方法、及支付系統 TWI720635B (zh)

Applications Claiming Priority (2)

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

Publications (2)

Publication Number Publication Date
TW202025029A TW202025029A (zh) 2020-07-01
TWI720635B true TWI720635B (zh) 2021-03-01

Family

ID=68234862

Family Applications (1)

Application Number Title Priority Date Filing Date
TW108135634A TWI720635B (zh) 2018-12-27 2019-10-02 資訊處理裝置、資訊處理方法、及支付系統

Country Status (5)

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

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 (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW500964B (en) * 2000-10-19 2002-09-01 Sony Corp Image printing order receiving system and image printing order receiving method
CN100451943C (zh) * 1999-06-30 2009-01-14 西尔弗布鲁克研究股份有限公司 文档支付系统
CN102360480A (zh) * 2011-10-06 2012-02-22 吴东辉 一种链接网上支付及记录链接的方法和系统
JP2016533584A (ja) * 2013-08-20 2016-10-27 インスタペイ インコーポレイテッド コード認識を利用した決済サービス方法およびそのシステム
JP2018151757A (ja) * 2017-03-10 2018-09-27 セイコーソリューションズ株式会社 注文管理システム、注文管理システムの決済方法、及びプログラム

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
JP5520754B2 (ja) * 2010-09-03 2014-06-11 エスアイアイ・データサービス株式会社 注文管理システムおよび注文管理方法
JP5671942B2 (ja) 2010-10-28 2015-02-18 株式会社寺岡精工 Ｐｏｓシステム
US9240006B2 (en) * 2011-11-30 2016-01-19 At&T Intellectual Property I, L.P. Wireless transactions for enhancing customer experience
US11734748B2 (en) * 2011-12-29 2023-08-22 Shashank Bhatia Manufacture, system, and method for collaborative and improved processing of commercial transactions in a vendor service area
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
US20160275576A1 (en) * 2013-12-19 2016-09-22 Twin Harbor Labs, LLC System and Method for Alerting Servers Using Vibrational Signals
US9355418B2 (en) * 2013-12-19 2016-05-31 Twin Harbor Labs, LLC 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
CN105556562A (zh) * 2014-08-28 2016-05-04 365科技控股有限公司 食物订单处理方法及系统
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
JP6924052B2 (ja) * 2017-03-17 2021-08-25 セイコーソリューションズ株式会社 情報処理システム、情報処理装置、携帯端末装置、及びプログラム
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 (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100451943C (zh) * 1999-06-30 2009-01-14 西尔弗布鲁克研究股份有限公司 文档支付系统
TW500964B (en) * 2000-10-19 2002-09-01 Sony Corp Image printing order receiving system and image printing order receiving method
CN102360480A (zh) * 2011-10-06 2012-02-22 吴东辉 一种链接网上支付及记录链接的方法和系统
JP2016533584A (ja) * 2013-08-20 2016-10-27 インスタペイ インコーポレイテッド コード認識を利用した決済サービス方法およびそのシステム
JP2018151757A (ja) * 2017-03-10 2018-09-27 セイコーソリューションズ株式会社 注文管理システム、注文管理システムの決済方法、及びプログラム

Also Published As

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

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) 決済支援システム、決済支援装置、決済支援方法、及びプログラム
TWI541742B (zh) Information processing device, information processing method, memory media
TWI720635B (zh) 資訊處理裝置、資訊處理方法、及支付系統
JP2004326727A (ja) 決済処理サーバ、決済処理方法、決済処理プログラム、決済処理端末装置、決済処理端末方法、及び決済処理端末プログラム
WO2020196249A1 (ja) マッチングシステム及びマッチングサイトの運営方法
JP2009129080A (ja) 匿名オンライン通販システム
KR20210033157A (ko) 주문 결제 시스템
JP2018180949A (ja) ロッカーシステムを介した物品の配送を管理するためのシステム、方法、及びプログラム
JP2009122769A (ja) 店舗管理システム及び店舗管理方法
JP2019061353A (ja) 決済システム及び利用者管理装置
JP2020151542A (ja) 景品保護預りシステム、端末装置、景品保護預り方法、およびコンピュータプログラム
JP6815905B2 (ja) 注文管理システム、注文管理システムの決済方法、及びプログラム
JP2022168091A (ja) 仮想通貨決済支援装置、仮想通貨決済支援システム、仮想通貨決済支援方法、及び仮想通貨決済支援プログラム
JP2016088687A (ja) 物品配達システム、ロッカー装置及び物品配達管理方法
JP2019114105A (ja) 情報管理装置、情報管理方法及びプログラム
JP2010262598A (ja) 自動販売機決済システム、自動販売機決済方法、サーバ、および自動販売機
JP2021051499A (ja) 商品販売データ処理装置及びプログラム
JP2021051503A (ja) 情報処理装置及びプログラム
JP2020146091A (ja) 景品保護預りシステム、電子マネーシステム、端末装置、景品保護預り方法、およびコンピュータプログラム
CN109308601A (zh) 信息处理系统及信息处理系统的信息处理方法
JP7057523B2 (ja) 決済支援システム、決済支援装置、決済支援方法、及びプログラム
JP6713075B2 (ja) セルフオーダーシステム、セルフオーダー管理方法、およびプログラム
JP6856255B2 (ja) 自動サービス機器の電子決済方法、及び自動サービス機器の電子決済システム