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

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

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

Images