JP2020107122A - セルフ登録システム及びプログラム - Google Patents

セルフ登録システム及びプログラム Download PDF

Info

Publication number
JP2020107122A
JP2020107122A JP2018245931A JP2018245931A JP2020107122A JP 2020107122 A JP2020107122 A JP 2020107122A JP 2018245931 A JP2018245931 A JP 2018245931A JP 2018245931 A JP2018245931 A JP 2018245931A JP 2020107122 A JP2020107122 A JP 2020107122A
Authority
JP
Japan
Prior art keywords
product
information
settlement
cloud server
mobile terminal
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2018245931A
Other languages
English (en)
Other versions
JP7325796B2 (ja
Inventor
文克 齋藤
Fumikatsu Saito
文克 齋藤
善弘 水谷
Yoshihiro Mizutani
善弘 水谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Teraoka Seiko Co Ltd
Original Assignee
Teraoka Seiko Co Ltd
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 Teraoka Seiko Co Ltd filed Critical Teraoka Seiko Co Ltd
Priority to JP2018245931A priority Critical patent/JP7325796B2/ja
Publication of JP2020107122A publication Critical patent/JP2020107122A/ja
Priority to JP2023121152A priority patent/JP2023138560A/ja
Application granted granted Critical
Publication of JP7325796B2 publication Critical patent/JP7325796B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】顧客の携帯端末に対する操作により商品登録が行われるセルフ登録システムにおいて、会計の効率の改善が図られるようにする。【解決手段】顧客の操作に応じて商品に関連する商品情報を読み取り、読み取られた商品情報に基づく商品登録が行われるようにする携帯端末と、商品登録に応じた取引に応じた精算が可能な精算装置とを備え、携帯端末は、取引を識別可能な識別情報を前記携帯端末の出力に基づき特定する特定手段と、商品登録に応じた精算が特定の決済種別により行われるようにする第１精算手段とを備え、精算装置は、特定された識別情報により示される取引が第１精算手段により精算済みであるか否かを判定する判定手段と、第１精算手段により精算済みではないことが判定された場合に精算を行う第２精算手段とを備えてセルフ登録システムを構成する。【選択図】図２３

Description

本発明は、セルフ登録システム及びプログラムに関する。
「前捌き」と呼ばれる運用に対応したＰＯＳシステムが知られている（例えば、特許文献１参照）。
前捌きでは、商品登録用の端末装置を使用して事前に顧客の買上商品の登録が行われ、商品登録結果を示す商品登録情報とコード情報とが対応付けられて上位装置に転送される。また、商品登録に応じて、コード情報を示すラベルやカードなどの媒体が顧客側に渡される。ＰＯＳレジスタを操作する店員は、媒体からコード情報を読み取らせる操作を行って、ＰＯＳレジスタに上位装置から読み取ったコード情報に対応付けられた商品登録情報を取得させ、取得された商品登録情報に基づく精算処理を実行させる。
このような前捌きの導入により、事前に顧客ごとの商品登録を済ませておくことができる。これにより、ＰＯＳレジスタにより取引ごとに商品登録と精算処理とを行う場合と比較して、単位時間あたりに会計を済ませることのできる顧客の数を増やして会計を効率よく進めていくことができる。
特開２０１５−８２２４９号公報
上記の特許文献１においては、例えば顧客に商品登録を行わせていることで、ＰＯＳレジスタにおいて取引ごとに商品登録が行われる時間が省かれるようにしている。しかしながら、精算に関してはいずれの取引についてもＰＯＳレジスタにて行うことになるので、顧客は精算に関しては順番待ちをすることになる。このような点で、会計の効率が改善される余地が残る。
本発明は、このような事情に鑑みてなされたもので、顧客の携帯端末に対する操作により商品登録が行われるセルフ登録システムにおいて、会計の効率の改善が図られるようにすることを目的とする。
上述した課題を解決する本発明の一態様は、顧客の操作に応じて商品に関連する商品情報を読み取り、読み取られた商品情報に基づく商品登録が行われるようにする携帯端末と、前記商品登録に応じた取引に応じた精算が可能な精算装置とを備えるセルフ登録システムにおいて、前記取引を識別可能な識別情報を前記携帯端末の出力に基づき特定する特定手段と、前記携帯端末にて、前記商品登録に応じた精算が特定の決済種別により行われるようにする第１精算手段とを備え、特定された識別情報により示される取引が前記第１精算手段により精算済みであるか否かを判定する判定手段と、前記第１精算手段により精算済みではないことが前記判定手段により判定された場合に前記精算装置にて精算を行う第２精算手段とを備えるセルフ登録システムである。
本発明の一態様は、顧客の操作に応じて商品に関連する商品情報を読み取り、読み取られた商品情報に基づく商品登録が行われるようにする携帯端末として第１コンピュータを機能させ、前記商品登録に応じた取引に応じた精算が可能な精算装置として第２コンピュータを機能させるための、セルフ登録システムのプログラムであって、前記第１コンピュータを、前記取引を識別可能な識別情報を前記携帯端末の出力に基づき特定する特定手段、特定の決済種別による精算が許可されている場合に、前記商品登録に応じた精算が前記特定の決済種別により行われるようにする第１精算手段として機能させ、前記第２コンピュータを、特定された識別情報により示される取引が前記第１精算手段により精算済みではない場合に精算を行う第２精算手段として機能させるためのプログラムである。
以上説明したように、本発明によれば、顧客の携帯端末に対する操作により商品登録が行われるセルフ登録システムにおいて、会計の効率の改善が図られるようになるという効果が得られる。
ショッピングシステムを説明するためのネットワークの概念図である。 精算装置の設置例を示す図である。 精算装置の外観例を示す図である。 精算装置の構成例を示す図である。 第１実施形態のショッピングシステムを説明するための各機能の概念図である。 各種の売価決定ロジック（売価決定機能）について説明する説明図である。 各種の情報について説明する説明図である。 処理の流れの概略を説明するシーケンス図である。 携帯端末の表示部における表示例である。 精算装置の表示部における表示例である。 第２実施形態のショッピングシステムを説明するための各機能の概念図である。 処理の流れの概略を説明するシーケンス図である。 第３実施形態のショッピングシステムを説明するための各機能の概念図である。 処理の流れの概略を説明するシーケンス図である。 商品登録時における、より詳細な動作の流れの一例を示すフローチャートである。 商品登録時における、より詳細な動作の流れの一例を示すフローチャートである。 精算時における、より詳細な動作の流れの一例を示すフローチャートである。 バスケット情報内に記憶される情報の一例である。 第４実施形態における携帯端末の構成例を示す図である。 第４実施形態におけるクラウドサーバの構成例を示す図である。 第４実施形態における携帯端末とクラウドサーバとが会計（商品登録、精算）に関連して実行する処理手順例を示すフローチャートである。 第４実施形態における精算装置誘導画面の態様例を示す図である。 第４実施形態における精算装置とクラウドサーバとが精算に関連して実行する処理手順例を示すフローチャートである。 第４実施形態における待機画面の態様例を示す図である。 第４実施形態における精算終了画面の態様例を示す図である。 第４実施形態における商品リスト画面の態様例を示す図である。 第４実施形態における商品リスト画面の他の態様例を示す図である。 第５実施形態における携帯端末とクラウドサーバとが会計（商品登録、精算）に関連して実行する処理手順例を示すフローチャートである。 第５実施形態における決済種別選択画面と店員呼出案内画面の態様例を示す図である。
＜第１実施形態＞
図１は、ショッピングシステムを説明するためのネットワークの概念図である。図１に示すショッピングシステムは、管理装置（例えば、ストアコントローラ）１０、クラウドサーバ２０、精算装置３０、精算装置４０、及び、携帯端末５０（例えば、スマートフォン等）、及びクレジットカード決済サーバ６０を含む。
管理装置１０、精算装置３０、精算装置４０は、店舗内に設置されるものであり、ＬＡＮ１９（有線でも無線でもよい）を介して通信可能に接続されている。管理装置１０は、クラウドサーバ２０と通信可能である。なお、図１において、２台の精算装置３０を図示したが、１店舗内の精算装置３０の数は、１台であってもよいし３台以上であってもよい。また、図１において、２台の精算装置４０を図示したが、１店舗内の精算装置４０の数は、１台であってもよいし３台以上であってもよい。精算装置３０の台数と精算装置４０の台数は一致していなくてもよい。また、管理装置１０は、基本的には１店舗に１台であるが、２台以上であってもよい。
携帯端末５０は、顧客（当該店舗の会員である買物客等）によって操作されるものである。携帯端末５０は、一般的な、通信機能や撮像機能（カメラ）に加えて、商品に付されるバーコードをスキャンして商品コードを読み取る、つまり商品に付されるバーコードを認識する認識機能を備える。なお、携帯端末５０が備える認識機能は、商品コードを読み取ることができるものであればよく、読み取った商品コードがいずれの商品の商品コードであるかを認識できるものでなくてもよい。つまり、携帯端末５０は、撮像機能によって撮像されている撮像画像（スルー画像として取得している画像）内にオブジェクトとしてバーコードが存在する場合に、当該バーコードから商品コードを読み取ることができるようになっていればよい。
また、携帯端末５０は、商品（例えばバーコードの付された周辺部分）を撮像し（シャッターを切り）、撮像画像（画像データ）を生成する。携帯端末５０は、操作者である顧客の操作に従ってシャッターを切る撮像であってもよいが、本実施形態では、携帯端末５０自身の判断（例えば、後述する図１５のステップＳ３１、Ｓ４５を参照）によりシャッターを切る撮像であることが好ましい。
また、携帯端末５０は、画像（スルー画像、撮像画像）から特徴点を抽出し、撮像対象（オブジェクト等）を認識する画像認識技術を備えていてもよい。例えば、携帯端末５０は、画像認識技術を用いて、撮像した商品を特定（推定）してもよい。
携帯端末５０は、基本的には各顧客の所有物であることを想定しているが、店舗側が貸与するものであってもよい。なお、携帯端末５０の数（稼働中の数）は、来店者数等に応じて変化するものであり、図１では、複数台が可能である旨の例として２台の携帯端末５０を図示している。
精算装置３０及び精算装置４０は、共に、精算方法として少なくとも現金による支払いが可能な精算装置である。精算装置３０は、クラウドサーバ２０との通信機能を有しないが、精算装置３０は、クラウドサーバ２０との通信機能を有する。クラウドサーバ２０は、例えば、顧客ごとに、取引情報（バスケット情報）を管理する。
クレジットカード決済サーバ６０は、精算装置３０、精算装置４０、携帯端末５０等からの非現金決済要求の送信に応じて、クレジットカードに対応する決済処理を実行する。クレジットカード決済サーバ６０は、精算装置３０とは管理装置１０経由で通信を行うようにされてよい。
ビーコン端末ＢＴＭは、店舗において設置される。ビーコン端末ＢＴＭの使用例については、第４実施形態にて後述する。
なお、図１に示すショッピングシステムは、本発明の第１実施形態（第２実施形態、第３実施形態も同様）に係るショッピングシステムを説明するためのものであり、本発明の第１実施形態（第２実施形態、第３実施形態も同様）に係るショッピングシステムは、図１に示した全部の構成を必ずしも含むものではない。例えば、本発明の第１実施形態（第２実施形態、第３実施形態も同様）に係るショッピングシステムは、例えば、クラウドサーバ２０と精算装置４０とから構成されるものであってもよいし、クラウドサーバ２０単体であってもよいし、精算装置４０単体であってもよい。
図２は、精算装置４０の設置例を示す図である。図２（Ａ）は、精算装置４０等を客側から見た斜視図である。図２（Ｂ）は、精算装置４０等を店員側から見た斜視図である。図２（Ａ）に示すように客側から見て精算装置４０の右側にカウンタが置かれている。
図３は、精算装置４０の外観例を示す図である。図３（Ａ）は、精算装置４０を客側から見た斜視図である。図３（Ｂ）は、精算装置４０を店員側から見た斜視図である。図４は、精算装置４０の構成例を示す図である。図３及び図４において、同一部分には同一符号を付している。
以下、図３を参照しつつ、図４に示した精算装置４０の構成例を説明する。精算装置４０は、ＣＰＵ４０１と、ＲＯＭ４０２と、ＲＡＭ４０３と、ハードディスク４０４と、客側表示部４０５と、客側スキャナ部４０６と、カード決済部４０８と、釣銭機４０９と、店員側表示部４１０と、キー操作部４１１と、店員側スキャナ部４１２と、印刷部４１３と、音声出力部４１４と、通信部４１５とを備える。これらは、バスを介して相互に通信可能である。
ＣＰＵ４０１は、中央演算処理装置であり、ＲＯＭ４０２に記憶されているプログラムを読み出して実行することにより、精算装置４０の動作を制御する。
ＲＯＭ４０２は、読み出し専用メモリであり、プログラムをはじめとしてＣＰＵ４０１が利用する各種の情報を記憶する。
ＲＡＭ４０３は、読み出し書き込みメモリであり、種々の情報を記憶する。例えば、ＲＡＭ４０３は、ＲＯＭ４０２やハードディスク４０４から読み出した情報、外部から取得した情報、処理において生成した情報等を記憶する。
ハードディスク４０４は、種々の情報を記憶する。ハードディスク４０４は、例えば、ＲＯＭ４０２に代えて、ＣＰＵ４０１が実行するプログラム等を記憶してもよい。また、ＲＡＭ４０３に代えて、ＲＯＭ４０２から読み出した情報、外部から取得した情報、処理において生成した情報等を記憶してもよい。
客側表示部４０５は、客用のタッチディスプレイであり、客に種々の情報を表示するとともに、客から種々の入力を受け付ける。
客側スキャナ部４０６は、客用のスキャナ部であり、例えば、商品に付されているバーコードをスキャンし、商品コードを読み取る。また、客側スキャナ部４０６は、お会計券（登録商標）に印刷されているコード（バーコード、２次元コード等）をスキャンし、精算に必要な情報を読み取ってもよい。また、客側スキャナ部４０６は、携帯端末５０の表示部に表示されるコード（２次元コード等）をスキャンし、精算に必要な情報を読み取ってもよい。
なお、客側スキャナ部４０６は、客が商品を登録する際に用いられるが、客は他の方法によって商品を登録してもよい。例えば、客側表示部４０５に、商品に対応するプリセットキー（商品を注文するボタン）が表示されている場合、客は、当該プリセットキーを操作（押下）し、商品を登録してもよい。
カード決済部４０８は、各種カード（クレジットカード、交通系カード等のプリペイドカード等）による決済機構である。第１実施形態（第２実施形態、第３実施形態も同様）のカード決済部４０８は、カード認識部（読取部）や表示部や操作部を備えるが、少なくとも、カード認識部を備えるものであればよい。なお、カード認識部は、直接的には決済（精算）に使用しない各種カード（例えば、会員カード、ポイントカード等）を認識してもよい。
釣銭機４０９（現金決済部）は、現金による決済機構であり、紙幣や硬貨の投入口、紙幣や硬貨の排出口を有し、投入口への投入金額を算出し、投入金額と買上金額の差分である釣銭金額を算出し、釣り銭を排出口から排出する。なお、当該釣銭機４０９は、客側に向けられており、客が操作するものである。なお、紙幣や硬貨が投入口に投入された場合にはセンサによって検出（投入があった旨の検出、金種別の枚数の検出等）される。
つまり、釣銭機４０９は、精算装置４０において、登録された商品の代金を現金（貨幣）にて決済するときに使用される。釣銭機４０９は、紙幣を投入するための紙幣投入口、硬貨を投入するための硬貨投入口、紙幣を放出するための紙幣放出口、硬貨を放出するための硬貨放出口、投入又は放出される貨幣を計数する計数部、投入口又は放出口と収納部の間の貨幣の搬送機構、上述したセンサなどを有する。なお、紙幣投入口及び硬貨投入口は、預り金投入口とも称される。紙幣放出口及び硬貨放出口は、釣銭放出口とも称される。なお、紙幣投入口と紙幣放出口は共通であってもよく、また、硬貨投入口と硬貨放出口は共通であってもよい。
また、釣銭機４０９は、閉店処理時に補充された貨幣を計数し、収納部に収納する。また、釣銭機４０９は、閉店処理時に出金する貨幣を計数し、釣銭放出口から放出する。閉店処理とは、閉店後や開店前などに釣銭機４０９内に収納されている金額（現金有高／現金在高）を基準金額に調整する処理である。
店員側表示部４１０は、店員用のタッチディスプレイであり、店員に種々の情報を表示するとともに、店員から種々の入力を受け付ける。
キー操作部４１１は、各種のキー（ボタン）から構成され、店員から種々の入力を受け付ける。
店員側スキャナ部４１２は、店員用のスキャナ部であり、例えば、商品に付されているバーコードをスキャンし、商品コードを読み取る。また、店員側スキャナ部４１２は、店員の名札に付されたバーコード等をスキャンし、店員コードを読み取る。
なお、店員側スキャナ部４１２は、店員が商品を登録する際に用いられるが、店員は他の方法によって商品を登録してもよい。例えば、キー操作部４１１に、商品に対応するキー（例えば、スポーツ新聞に対応するキー等）が配置されている場合、店員は、当該キーを操作（押下）し、当該商品を登録してもよい。また、店員側表示部４１０に、商品に対応するプリセットキーが表示されている場合、店員は、当該プリセットキーを操作し、当該商品を登録してもよい。
印刷部４１３は、各種媒体（レシート、お会計券等）を印刷、発行する。印刷部４１３は、店員側から客側、客側から店員側に向き（媒体発行口の方向）を回転自在に変更である。印刷部４１３の向きは、手動で変更してもよいし、例えば動作モード（詳細は後述）の移行（切替）に応じて自動的に変更（メカ的に制御等）してもよい。なお、印刷部４１３の向きの正誤をセンサなどで検出してもよい。
音声出力部４１４は、音声を出力する。例えば、音声出力部４１４は、音声ガイダンス等を出力する。
通信部４１５は、他装置（他の精算装置４０、精算装置３０、管理装置１０）との間において情報を送受信する。
以上、精算装置４０の外観やハードウェア構成を説明したが、精算装置３０の外観やハードウェア構成については説明を省略する。精算装置３０と精算装置４０とは、後述するように（図５等参照）、ソフトウェアによって実現される機能が互いに異なるが、精算装置３０と精算装置４０とは、外観やハードウェア構成は同一であってもよいし、異なっていてもよい。例えば、精算装置４０は、２つのスキャナ部（客側スキャナ部４０６、店員側スキャナ部４１２）を有する精算装置４０であるのに対し、精算装置３０は、１つのスキャナ部を有する精算装置であってもよい。
図５は、第１実施形態のショッピングシステムを説明するための各機能の概念図である。図６は、各種の売価決定ロジック（売価決定機能）について説明する説明図である。図７は、各種の情報について説明する説明図である。
なお、図５は、本発明の第１実施形態に係るショッピングシステムを説明するためのものであり、本発明の第１実施形態に係るショッピングシステムは、図１に示した全部の構成を必ずしも含むものではない。例えば、本発明の第１実施形態に係るショッピングシステムは、クラウドサーバ２０と精算装置４０とから構成されるものであってもよいし、クラウドサーバ２０単体であってもよいし、精算装置４０単体であってもよい。また、図５は、本発明の第１実施形態に係るショッピングシステムの特徴部分に関連する機能を抜粋して説明するものであり、一般にショッピングシステムに必要とされる機能を網羅的に説明するものではない。
［精算装置３０］
図５の右下に示すように、精算装置３０は、売価決定ロジック（売価決定機能）、精算機能を備える。売価決定ロジックは、精算処理において求められる売価（販売対価としての請求金額）を決定（算出）する機能であり、ソフトウェアによって実現される。売価決定ロジックには、種々の種類があるが（例えば、図６参照）、図５に示した例では、精算装置３０は、売価決定ロジックＡ、売価決定ロジックＢを備えている。
なお、図６に示した売価決定ロジックＡは、運用中（適宜）の売価変更に対応する基本的な単品に対する値引価格の基本価格算出機能である。売価決定ロジックＢは、設定情報（単品値引設定情報）に基づいて単品に対する値引価格を算出する単品値引価格算出機能である。売価決定ロジックＣは、設定情報（小計値引設定情報）に基づいて小計に対する値引価格を算出する小計値引価格算出機能である。売価決定ロジックＤは、設定情報（会員値引設定情報）に基づいて単品又は小計に対する値引価格を算出する会員値引価格算出機能である。売価決定ロジックＥは、設定情報（タイムサービス値引設定情報）に基づいて単品に対する値引価格を算出するタイムサービス値引価格算出機能である。売価決定ロジックＦは、設定情報（ミックスマッチ値引設定情報）に基づいてミックス商品（組み合わせ不指定（不定）の商品群）に対する値引価格を算出するミックスマッチ値引価格算出機能である。売価決定ロジックＧは、設定情報（セットマッチ値引設定情報）に基づいてセット商品（組み合わせ指定（固定）の商品群）に対する値引価格を算出するセットマッチ値引価格算出機能である。売価決定ロジックＨは、設定情報（決済種別値引設定情報）に基づいて利用される決済種別に応じた値引価格を算出する決済種別値引価格算出機能である。
なお、売価決定ロジックＤ（会員値引価格算出機能）が適用される会員は、顧客の全部（全顧客）であってもよいし、顧客の一部（例えば特定の顧客ランクの顧客）であってもよい。
売価決定ロジックＡに係る情報（売価変更の情報）や売価決定ロジックＢ〜売価決定ロジックＨに対応する各種設定情報は、精算装置３０の記憶部、又は、精算装置３０がアクセス可能な装置）に記憶されていればよい。なお、精算装置３０は、上述したように売価決定ロジックＡ、Ｂを備えるが、売価決定ロジックＣ〜Ｆは備えないため、少なくとも、売価決定ロジックＡに係る情報（売価変更の情報）と、売価決定ロジックＢに対応する設定情報（単品値引設定情報）と、が参照できるようになっていればよい。
また、図６では図示を省略したが、夫々の売価決定ロジック（売価決定ロジックＡ〜Ｈ）とは別に、夫々の売価決定ロジックを統括する売価決定統括ロジックも存在する。売価決定統括ロジックは、複数の売価決定ロジックにまたがって売価を決定するためのロジックである。例えば、売価決定ロジックＢ（単品値引価格算出機能）と売価決定ロジックＤ（会員値引価格算出機能）がある場合に、売価決定統括ロジックは、売価決定ロジックＢと売価決定ロジックＤがある場合の値引きを設定情報（売価決定統括設定情報）に基づいて決定する。
一例として、商品ａ（商品情報では１００円）が、売価決定ロジックＢ（及び単品値引設定情報）によれば８０円（１０円値引）であり、売価決定ロジックＤ（及び会員値引設定情報）によれば９０円（２０円値引）である状態において、会員（売価決定ロジックＤの適用対象である顧客）が商品ａを購入した場合、売価決定統括ロジックは、売価決定ロジックＤのみを適用して商品ａの価格を８０円（２０円値引）としてもよいし、売価決定ロジックＢ、Ｄの両方を適用して商品ａの価格を７０円（３０円値引）としてもよい。売価決定ロジックＤのみを適用し商品ａの価格を８０円とするか、売価決定ロジックＢ、Ｄの両方を適用し商品ａの価格を７０円とするかは、設定情報（売価決定統括設定情報）による。なお、売価決定統括ロジックは、値引き額が小さい方を決定する場合もある。
例えば、上述したように会員値引額の方が大きい場合（売価決定ロジックＢによる単品値引額が１０円、売価決定ロジックＤによる会員値引額が２０円の場合）に、売価決定ロジックＤを適用せずに売価決定ロジックＢのみを適用して商品ａの価格を９０円とする場合もありうる。具体的には、会員割引による割引限度額が設定されている場合や会員割引による購入が会員ランクの実績に反映されない場合には、売価決定ロジックＢのみを適用する旨を設定情報（売価決定統括設定情報）に設定してもよい。また、上記とは逆に、単品割引額の方が大きい場合（売価決定ロジックＢによる単品値引額が３０円、売価決定ロジックＤによる会員値引額が２０円の場合）に、売価決定ロジックＢを適用せずに売価決定ロジックＤのみを適用して商品ａの価格を８０円とする場合もありうる。具体的には、会員割引による購入実績が会員ランクの算出に優遇される場合には、売価決定ロジックＤのみを適用する旨を設定情報（売価決定統括設定情報）に設置してもよい。
上述した売価決定統括ロジックは、必要に応じて（複数の売価決定ロジックにおける調整が必要な場合に）、備えていればよい。例えば、第１実施形態においてクラウドサーバ２０（精算装置３０も同様）は、売価決定ロジックＡ、Ｂ、Ｃを備えるが（図５）、更に、売価決定統括ロジックを備えていてもよい。第２、３の実施形態においても同様である。
なお、売価決定統括ロジックも、図６に示した売価決定ロジックの１つと捉えてもよい。以下の説明において、図６に示したような個々の売価決定ロジックの１つ又は複数を「売価決定ロジック」と称する場合と、売価決定統括ロジックを含めて「売価決定ロジック」と称する場合とがある。つまり、単に「売価決定ロジック」と記載した場合には、売価決定統括ロジックを除外する場合と、売価決定統括ロジックを除外しない場合とがあるものとする。
精算機能は、売価決定ロジックによって決定された売価に基づいて精算処理（例えば、釣銭機による現金の支払い等）を実行する機能である。
なお、図５（図１１、図１３も同様）では、売価決定ロジックを、精算機能とは別の機能として説明しているが、売価決定ロジックは、精算機能の一部であると捉えてもよい。つまり、図５（図１２、図１４も同様）では、売価を決定する部分と、決定された売価に基づいて実際に支払いを実行する部分とを別個に捉え、売価を決定する部分に対応する機能を売価決定ロジックと称し、実際に支払いを実行する部分を精算機能と称しているが、売価を決定する部分も含め、精算機能と称してもよい。売価を決定する部分も含め、精算機能と称する場合には、売価決定ロジックは、精算機能の一部となる。
［管理装置１０］
図５の右上に示すように、管理装置１０は、店舗情報、商品情報を記憶する。管理装置１０は、売価決定ロジックを備えていてもよい。管理装置１０が記憶する店舗情報は、当該管理装置１０が設置された店舗に関する情報であって、例えば、当該店舗の店舗名、当該店舗を特定する情報等を含む。管理装置１０が記憶する商品情報は、当該管理装置１０が設置された店舗において販売される商品に関する情報であって、例えば、商品コード、商品名、価格等が含む。なお、管理装置１０は、例えば、外部（本部のサーバ（不図示）等）から商品情報等を取得し、記憶してもよい。また、管理装置１０は、外部（本部のサーバ）であってもよい。つまり、各店舗で利用される共通のまたは別個（店舗毎）の商品情報や売価決定ロジックを管理するものであってもよい。第２、第３実施形態の管理装置１０（管理装置１１、１２）についても同様である。
［クラウドサーバ２０］
図５の左上に示すように、クラウドサーバ２０は、売価決定ロジックを備える。上述したように、売価決定ロジックには、種々の種類があるが（例えば、図６参照）、図５に示した例では、クラウドサーバ２０は、売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣを備えている。なお、クラウドサーバ２０は、売価決定ロジックＡ〜Ｃを備えるが、売価決定ロジックＤ〜Ｆは備えないため、少なくとも、売価決定ロジックＡに係る情報（売価変更の情報）と、売価決定ロジックＢに対応する設定情報（単品値引設定情報）と、売価決定ロジックＣに対応する設定情報（小計値引設定情報）が参照できるようになっていればよい。
また、クラウドサーバ２０は、顧客情報、店舗情報、商品情報、バスケット情報を記憶する。顧客情報は、個々の顧客を管理するための情報である。クラウドサーバ２０は、顧客登録時に顧客情報を生成する（ある顧客の顧客情報が記憶されることを以って当該顧客の顧客登録がなされたと解してもよい）。また、クラウドサーバ２０は、バスケット情報等に基づいて、顧客情報を適宜更新する。例えば、クラウドサーバ２０は、例えば毎日所定時刻にバスケット情報を参照し、顧客情報を更新してもよい。
なお、図５のクラウドサーバ２０が備える決済機能は、第４実施形態に対応するものであることから、本実施形態での説明は省略する。
クラウドサーバ２０は、例えば、図７（Ａ）に示すような顧客情報を記憶する。図７（Ａ）に示した顧客情報は、顧客識別情報、顧客名、顧客登録日、キャンセル情報、顧客ランク、ポイント数等を含む。顧客識別情報は、顧客を一意に識別する識別情報である。顧客名は、顧客の氏名やニックネームなどである。顧客登録日は、顧客登録した日時である。キャンセル情報は、登録後における登録商品のキャンセルに関する情報である。顧客ランクは、顧客の購入実績に応じたランクである。なお、新規の顧客の顧客情報の生成時には、顧客識別情報、顧客名、顧客登録日は生成されるが、実際の取引（商品登録）の開始前であるため、他の情報（キャンセル情報等）は生成されない。
なお、図７（Ａ）の顧客情報において、指定決済種別情報と決済種別利用履歴とについては、第４実施形態に対応するものであることから、ここでの説明は省略する。
クラウドサーバ２０は、例えば、顧客登録の際（例えば、携帯端末５０が外部（例えば、アプリ全般を提供する所定のサーバ、当該クラウドサーバ２０）からクラウドサーバ２０によるサービスを利用するためアプリケーション（アプリ）をダウンロード又はインストールする際）に顧客識別情報を生成し、記憶する。また、クラウドサーバ２０は、例えば、顧客登録の際に、携帯端末５０を用いて、登録フォーム（入力フォーム）の氏名欄に入力された情報を取得し、顧客名として記憶する。また、クラウドサーバ２０は、例えば、顧客登録の際の現在日時を取得し、顧客登録日として記憶する。
なお、クラウドサーバ２０は、自装置内の記憶部に顧客情報を記憶することに代えて又は加えて他の装置（クラウドサーバ２０がアクセス可能なファイルサーバ等）に顧客情報の一部または全部を記憶してもよい。
店舗情報は、各店舗の管理装置１０から取得したものである（図５の送受信データ「Ｄ０」参照。なお、送受信データ「Ｄ１」〜「Ｄ６」は図８にて説明する）。つまり、クラウドサーバ２０は、各店舗の管理装置１０から直接又は他の装置を介して間接的に店舗情報を受信するなどして、店舗情報を記憶する。
クラウドサーバ２０は、例えば、図７（Ｂ）に示すような店舗情報を記憶する。図７（Ｂ）に示した店舗情報は、店舗識別情報、店舗名（支店名）、店舗特定情報１、店舗特定情報２を含む。店舗識別情報は、店舗を一意に識別する識別情報である。図７（Ｂ）に示した店舗識別情報は、店（屋号）もしくは企業のコードと、支店のコードとから構成される。店舗名は、店舗の名称である。図７（Ｂ）に示した店舗名は、店（屋号）もしくは企業と、支店名とから構成される。店舗特定情報１は、取引する店舗（商品の売買が行われる店舗）を特定するための２次元コード（ＱＲコード（登録商標）等）の情報である。店舗特定情報２は、取引する店舗を特定するための店舗の位置情報（ＧＰＳ情報）である。なお、図７（Ｂ）に示した例では、店舗識別情報と店舗特定情報１とは異なるが、店舗識別情報と店舗特定情報１とは同一であってもよい。
なお、クラウドサーバ２０は、外部（各店舗を統括する本部のサーバ（不図示）等）から店舗情報等を取得し、記憶してもよい。また、クラウドサーバ２０は、自装置内の記憶部に店舗情報を記憶することに代えて又は加えて他の装置（クラウドサーバ２０がアクセス可能なファイルサーバ等）に店舗情報の一部または全部を記憶してもよい。
商品情報は、各店舗の管理装置１０等から取得したものである（図５の送受信データ「Ｄ０」参照。なお、送受信データ「Ｄ１」〜「Ｄ６」は図８にて説明する）。つまり、クラウドサーバ２０は、各店舗の管理装置１０から直接又は他の装置を介して間接的に商品情報を受信するなどして、商品情報を記憶する。なお、クラウドサーバ２０は、外部（各店舗を統括する本部のサーバ（不図示）等）から商品情報を取得し、記憶してもよい。また、クラウドサーバ２０は、自装置内の記憶部に店舗情報を記憶することに代えて又は加えて他の装置（クラウドサーバ２０がアクセス可能なファイルサーバ等）に店舗情報の一部または全部を記憶してもよい。
バスケット情報は、個々の取引を管理するための情報である。クラウドサーバ２０は、取引の開始時にバスケット情報を生成する。また、クラウドサーバ２０は、取引の進行にあわせて（商品が登録される度に）、バスケット情報を更新する（バスケット情報に商品が記憶されることを以って当該商品の登録がなされたと解してもよい）。
クラウドサーバ２０は、例えば、図７（Ｃ）に示すようなバスケット情報を記憶する。図７（Ｃ）に示したバスケット情報は、バスケット識別情報、取引開始日時、取引終了日時、顧客識別情報、登録商品情報、保留商品情報、キャンセル情報等を含む。バスケット識別情報は、バスケットを一意に識別する識別情報である。図７（Ｃ）に示したバスケット識別情報は、店舗識別情報と、日付と、シリアル番号（例えば店舗別日付別のシリアル番号）とから構成される。取引開始日時は、取引の開始日時である。図７に示した取引開始日時は、当該バスケット情報の生成日時である。なお、取引開始日時は、１品目の商品の登録日時（図７（Ｃ）中の登録商品情報（登録商品１）を記憶した日時）としてもよい。バスケット情報の生成日時と１品目の商品の登録日時とを別々に両方記憶してもよい。
なお、図７（Ｃ）のバスケット情報における、精算済フラグについては、第４実施形態に対応するものであることから、ここでの説明は省略する。
取引終了日時は、取引の終了日時である。図７に示した取引開始日時は、精算日時である。顧客識別情報は、当該取引の顧客を識別する顧客識別情報である。なお、バスケット情報の生成時には、バスケット識別情報、取引開始日時、顧客識別情報は生成されるが、実際の取引（商品登録）の開始前であるため、他の情報（取引終了日時等）は生成されない。なお、精算日時は、精算開始日時であってもよいし（例えば、図１７のステップＳ８９の処理の実行日時）、精算終了日時であってもよい（図１７のステップＳ９１の処理の終了日時）。精算開始日時と精算終了日時とを別々に両方記憶してもよい。
登録商品情報（計）は、商品が登録されるごとに更新される情報である。登録商品情報（計）は、品数（商品数）、概算小計金額（価格決定ロジックによる価格算出前の概算の小計金額）、小計金額（価格決定ロジックによる価格算出後の小計金額）等を含む。登録商品情報（１）は、１品目の商品の登録情報である。登録商品情報（２）は、２品目の商品の登録情報である。なお、図７（Ｃ）に示す例では、登録商品情報（３）〜登録商品情報（５）の図示を省略している。登録商品情報（Ｎ；Ｎは整数）は、商品コード、品名（商品名）、価格等を含む。
登録商品情報（Ｎ）は、当該Ｎ品目の商品の登録日時を含むものであってもよい。つまり、クラウドサーバ２０は、登録商品情報として、当該登録商品の登録日時を記憶してもよい。各商品の登録日時は、タイムサービス（売価決定ロジックＥによるサービス）等のサービス適用の要否や適用後の効果の判断材料としても用いてもよい。
保留商品情報（計）は、保留商品（後述）が登録されるごとに更新される情報である。保留商品情報（計）は、保留商品の品数（商品数）、保留商品のうちのＮＯＮ−ＰＬＵ（「ＮＯ−ＦＩＬＥ」とも称する）の品数、保留商品のうちの読取ＮＧ（要不正操作確認）の品数等を含む。
ＮＯＮ−ＰＬＵとは、店舗においてバーコードもしくは商品コードのスキャンは成功したが（商品コードを読み取ることができたが）、商品コードが商品情報に記憶されていない、商品（商品情報未登録の商品）を示す。
なお、本願の明細書、図面等における「ＮＯＮ−ＰＬＵ」、「ＮＯ−ＦＩＬＥ」、「ＮＯＮファイル」等の記載は、いずれも上記のような商品情報未登録の商品を示す。
読取ＮＧとは、店舗において商品コードのスキャンが失敗したこと（商品コードを読み取ることができなかったこと）、又は、店舗において商品コードのスキャンが失敗した商品のことである。つまり、読取ＮＧとは、例えば画像認識技術により一定時間商品を撮像しているがバーコード認識に至らない場合を判別できる場合にタイムアウト処理すること、タイムアウト処理された商品である。例えば、パッケージのシワ等やバーコード印字のカスレや汚れにより正しくバーコードを取得（認識）できない場合に読取ＮＧと判断される。また、バーコードを読んだフリしてカゴへ投入する不正操作を検出した場合にも読取ＮＧと判断される。なお、携帯端末５０は、センサ（例えば、ジャイロセンサや加速度センサや距離センサ等）を備え、当該携帯端末５０がバーコード読取中（具体的には、バーコードの読み取りのため、当該携帯端末５０が傾けられている状況であり、かつ、当該携帯端末５０一定距離先に物品（商品）が存在している状況）を検出可能である。そして、所定時間内にバーコードが読み取れなかった場合（バーコード読取中が所定時間継続したがバーコードを読み取れなかった場合）は、タイムアウト処理として、保留商品（読取ＮＧ）としている。
保留商品情報（保留商品１）は、１品目の保留商品の情報である。保留商品情報（保留商品２）は、２品目の保留商品の情報である。保留商品情報（保留商品３）は、３品目の保留商品の情報である。
保留商品情報（保留商品Ｎ；Ｎは整数）は、保留商品種別（当該保留商品がＮＯＮ−ＰＬＵであるか読取ＮＧであるかを示す情報）、画像データ（読取ＮＧ時に撮像された画像データ）を含む。例えば、Ｎ品目の商品がＮＯＮ−ＰＬＵによる保留商品である場合には、保留商品情報（保留商品Ｎ）は、保留商品種別「１（ＮＯＮ−ＰＬＵ）」、画像データを含む。また、Ｎ品目の商品が読取ＮＧによう保留商品である場合には、保留商品情報（保留商品Ｎ）は、保留商品種別「２（読取ＮＧ）」、画像データを含む（図１８（Ｄ）参照）。
なお、クラウドサーバ２０は、自装置内の記憶部にバスケット情報を記憶することに代えて又は加えて他の装置（クラウドサーバ２０がアクセス可能なファイルサーバ等）にバスケット情報の一部または全部を記憶してもよい。
［精算装置４０］
図５の左下に示すように、精算装置４０は、クラウド通信機能、携帯端末連動機能、精算機能を備える。クラウド通信機能は、クラウドサーバ２０と通信する機能である。携帯端末連動機能は、携帯端末５０との連動する機能であり、例えば、携帯端末５０の表示部に表示されるコード（２次元コード等）を光学的にスキャンし（読み取り）、スキャンした情報（またはスキャンした情報に基づく情報）をクラウド通信機能側に供給する機能である。携帯端末５０の表示部に表示されるコードは、当該携帯端末５０による買上商品について精算処理を実行するために必要となる情報（例えば、バスケット識別情報）をコード化したものである。なお、クラウド通信機能、携帯端末連動機能は、精算装置３０は備えていない精算装置４０の固有機能である。
精算機能は、クラウドサーバ２０の売価決定ロジックによって決定された売価に基づいて精算処理（例えば、釣銭機による現金の支払い等）を実行する機能である。
精算装置４０は、クラウド通信機能、携帯端末連動機能、精算機能を備えるため、例えば、ある顧客の携帯端末５０の表示部に表示されるコード（当該顧客のバスケット情報を特定可能な情報）をスキャンし、スキャンした情報（またはスキャンした情報に基づく情報）をクラウドサーバ２０に送信し、クラウドサーバ２０から当該顧客のバスケット情報に基づく売価（小計情報）を受信し、受信した売価に基づいて精算処理を実行することができる。
［携帯端末５０］
図５の左下に示すように、携帯端末５０は、クラウドサーバ２０と通信する。携帯端末５０は、クラウドサーバ２０と通信することにより商品を登録する。つまり、携帯端末５０は、ある商品に付されているバーコードを撮像することにより、オブジェクトとして当該バーコードを認識し（バーコードから商品コードを読み取り）、商品コードをクラウドサーバ２０に送信することにより、当該商品を登録する（具体的には、クラウドサーバ２０のバスケット情報に当該商品コードを記憶させる）。
また、携帯端末５０は、コード（２次元コード等）を生成する。つまり、携帯端末５０は、精算装置４０の携帯端末連動機能に関連して、表示部にコードを表示するが、携帯端末５０は、表示部に表示するコードを自ら生成し、表示部に表示する。なお、携帯端末５０が、生成し、表示部に表示するコードは、上述したように、当該携帯端末５０による買上商品について精算処理と実行するために必要となる情報（例えば、バスケット識別情報）をコード化したものである。
なお、携帯端末５０は、外部から取得したアプリの機能として、クラウドサーバ２０と通信する機能や、コード（２次元コード等）を生成する機能を実現する。つまり、携帯端末５０は、アプリを起動させることによって、クラウドサーバ２０と通信したり、コードを生成したり、表示したりしてもよい。
なお、携帯端末５０は、表示部に表示するコードを生成する機能を備えていなくてもよい。例えば、携帯端末５０に代えてクラウドサーバ２０がコードを生成する機能を備えていてもよい。つまり、クラウドサーバ２０は、携帯端末５０からの要求に基づいてコードを生成し、生成したコードを携帯端末５０に送信し、携帯端末５０は、クラウドサーバ２０にコードの生成を要求し、クラウドサーバ２０によって生成されたコードを受信し、表示部に表示してもよい。
図８は、図５の機能構成における、処理の流れの概略を説明するシーケンス図である。具体的には、図８（図１２、図１４も同様）は、ある店舗に、ある顧客が来店し、当該店舗に陳列されている商品を登録し、登録した商品の精算が完了する迄における、当該顧客の携帯端末５０、当該店舗に設置された精算装置４０、データセンタ等の外部に設置されたクラウドサーバ２０の夫々の処理の一例を示したものである。図８の左側が、携帯端末５０の処理、中央が精算装置４０の処理、右側がクラウドサーバ２０の処理である。図９は、携帯端末５０の表示部における表示例である。図１０は、精算装置の表示部における表示例である。
以下、図５、図７、図９、図１０等を参照しつつ、図８に示した動作の流れを説明する。
ステップＳ１：携帯端末５０は、店舗を特定する情報（店舗特定情報）を取得する。例えば、店舗の入口付近に当該店舗を特定するための２次元コードを表示（２次元コードを表示画面に出力、２次元コードを印刷した媒体を貼付等）しておき、来店した顧客が、携帯端末５０で２次元コードをスキャンする（読み取る）ことにより、携帯端末５０は店舗特定情報を取得してもよい。なお、来店した顧客がアプリを起動させると、初期画面として２次元コードのスキャンを該顧客に指示する画面を表示するようにしてもよいし、来店した顧客が携帯端末５０で２次元コードをスキャンすると、アプリが起動し、初期画面としてクラウドサーバ２０に接続中である旨を該顧客に報知する画面を表示するようにしてもよい。
また例えば、店舗は所在地で特定されるため、来店した顧客が、店舗において携帯端末５０で位置情報（ＧＰＳ情報）を取得してもよい（すなわち、店舗特定情報として当該店舗の位置情報を取得してもよい）。なお、来店した顧客がアプリを起動させると、位置情報を取得し、初期画面としてクラウドサーバ２０に接続中である旨を該顧客に報知する画面を表示するようにしてもよい。位置情報から複数店舗が検出され１つに特定できない場合には、選択画面を表示し顧客に選択させるようにしてもよい。もしくは強制的に２次元コードを取得させるモードに切り替えてもよい。
店舗特定情報を取得した携帯端末５０は、取引開始要求として、取得した店舗特定情報を顧客識別情報とともにクラウドサーバ２０に送信する（図５及び図８の送受信データ「Ｄ１」参照）。顧客識別情報については、上述したように、顧客登録の際（携帯端末５０にアプリをダウンロード又はインストールする際）に、携帯端末５０を用いて登録フォームの氏名欄に入力された情報がクラウドサーバ２０の顧客情報に記憶されるが、クラウドサーバ２０に加え、携帯端末５０の記憶部にも記憶しておいてもよい。なお、店舗が特定された場合には（後述する商品登録初期画面を取得したときには）、当該店舗の店舗名や実施中のサービス（その日に配布されているチラシ情報）、利用可能なクーポン情報を画面（商品登録初期画面又は商品登録初期画面とは別の画面）に表示してもよい。なお、サービスやクーポンの情報は、例えば画面情報としてクラウドサーバ２０から取得してもよい。
また、送信先の情報（クラウドサーバ２０のアドレス）についても、顧客登録の際（携帯端末５０にアプリをダウンロード又はインストールする際）に取得し、携帯端末５０の記憶部に記憶しておいてもよい。なお、２次元コードをスキャンする態様とする場合には、店舗特定情報に加え、送信先の情報）についても２次元コード化しておき、携帯端末５０で２次元コードをスキャンすることにより、携帯端末５０は店舗特定情報とともに送信先の情報も取得してもよい。
ステップＳ２：携帯端末５０から取引開始要求として顧客識別情報及び店舗特定情報を受信したクラウドサーバ２０は、当該取引のバスケットを生成する。具体的には、図７（Ｃ）に示すようなバスケット情報を生成する。なお、バスケット情報の生成時には、バスケット識別情報、取引開始日時、顧客識別情報は生成されるが、実際の取引（商品登録）の開始前であるため、他の情報（取引終了日時等）は生成されない。
クラウドサーバ２０は、上述したように、図７（Ｂ）に示したような店舗情報を記憶しているため、携帯端末５０から取引開始要求として店舗特定情報を受信（顧客識別情報も受信するが）した場合、受信した店舗特定情報が２次元コードであった場合には、店舗特定情報１を参照して店舗識別情報を取得し、受信した店舗特定情報が位置情報（ＧＰＳ情報）であった場合には店舗特定情報２を参照して店舗識別情報を取得する。なお、クラウドサーバ２０は、携帯端末５０から受信した店舗特定情報が店舗識別情報を２次元コード化したものであった場合には、そのまま取得すればよい。
つまり、携帯端末５０から取引開始要求として顧客識別情報及び店舗特定情報を受信したクラウドサーバ２０は、携帯端末５０から受信した店舗特定情報から店舗識別情報を取得し、更に、現在日付を取得し、シリアル番号を発行（採番）し、店舗識別情報と現在日付とシリアル番号とを結合させて、バスケット情報内のバスケット識別情報として記憶する。また、携帯端末５０から取引開始要求として店舗特定情報や顧客識別情報を受信したクラウドサーバ２０は、現在日時を取得し、バスケット情報内の取引開始日時（生成日時）として記憶する。また、携帯端末５０から取引開始要求として店舗特定情報や顧客識別情報を受信したクラウドサーバ２０は、携帯端末５０から受信した顧客識別情報をバスケット情報内の顧客識別情報として記憶する。
ステップＳ３：当該取引のバスケットを生成したクラウドサーバ２０は、商品登録初期画面情報（初期画面である商品登録画面の画面情報）を生成し、携帯端末５０に送信する。具体的には、クラウドサーバ２０は、例えば、携帯端末５０において図９（Ａ）に示すような商品登録初期画面が表示されるような商品登録初期画面情報を生成し、生成した商品登録初期画面情報をバスケット識別情報とともに携帯端末５０に送信する（図５及び図８の送受信データ「Ｄ２」参照）。
ステップＳ４：クラウドサーバ２０からバスケット識別情報及び商品登録初期画面情報を受信した携帯端末５０は、バスケット識別情報を記憶するとともに、登録画面を表示部に表示する。具体的には、携帯端末５０は、例えば図９（Ａ）に示すような商品登録初期画面を表示する。
ステップＳ５：顧客の操作により携帯端末５０は、商品に付されたバーコードをスキャンし、商品コードを読み取る。なお、図８（図１２、図１４も同様）では、バーコードのスキャンは成功したものとする。なお、図５では説明の便宜上簡略化したが、ステップＳ５〜ステップＳ９は、商品に付されたバーコードをスキャンするごとに繰り返し実行される。
バーコードを取得した携帯端末５０は、バスケット識別情報とともに、スキャンによって得られた商品コードをクラウドサーバ２０に送信する（図５及び図８の送受信データ「Ｄ３」参照）。
ステップＳ６：携帯端末５０からバスケット識別情報及び商品コードを受信したクラウドサーバ２０は、バスケット識別情報から当該取引のバスケットを特定する。
ステップＳ７：クラウドサーバ２０は、特定したバスケット内の商品データを更新する。具体的には、クラウドサーバ２０は、Ｎ品目として商品コードを受信した場合には、特定したバスケットのバスケット情報において、当該商品コードを登録商品情報（登録商品Ｎ）の商品コードとして記憶し、当該商品コードに対応する品名及び価格を商品情報から取得し、登録商品情報（登録商品Ｎ）の商品及び価格して記憶する。また、クラウドサーバ２０は、特定したバスケットのバスケット情報において、登録商品情報（計）を更新する。
ステップＳ８：バスケット内の商品データを更新したクラウドサーバ２０は、商品登録更新画面情報（登録した商品が追加された更新画面である商品登録画面の画面情報）を生成し、携帯端末５０に送信する。具体的には、クラウドサーバ２０は、例えば、携帯端末５０において図９（Ｂ）に示すような商品登録更新画面が表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末５０に送信する（図５及び図８の送受信データ「Ｄ４」参照）。
なお、図９（Ｂ）に示した商品登録画面（商品登録更新画面）は、３品目の商品として「〇〇食パン」が登録された後に携帯端末５０に表示されるものである。つまり、クラウドサーバ２０は、１品目として「〇〇ヨーグルト」をバスケット内に記憶したときには、携帯端末５０において「〇〇ヨーグルト」が表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末５０に送信し、２品目として「〇〇チョコレート」をバスケット内に記憶したときには、携帯端末５０において「〇〇ヨーグルト」と「〇〇チョコレート」とが表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末５０に送信し、３品目として「〇〇食パン」をバスケット内に記憶したときには、図９（Ｂ）に示すように、携帯端末５０において「〇〇ヨーグルト」と「〇〇チョコレート」と「〇〇食パン」とが表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末５０に送信する。
ステップＳ９：クラウドサーバ２０からバスケット識別情報及び商品登録更新画面情報を受信した携帯端末５０は、登録画面に商品を追加する。具体的には、携帯端末５０は、例えば図９（Ｂ）に示すような商品登録更新画面を表示する。なお、上述したように、図９（Ｂ）に示した商品登録画面（商品登録更新画面）は、３品目の商品として「〇〇食パン」が登録された後に携帯端末５０に表示されるものである。
ステップＳ１０：携帯端末５０は、顧客の操作として会計指示を受け付ける。例えば、図９（Ｂ）に示した「お会計へ進む」ボタンのタッチを受け付ける。
ステップＳ１１：会計指示を受け付けた携帯端末５０は、２次元コードを生成する。つまり、携帯端末５０は、当該携帯端末５０による買上商品について精算処理を実行するために必要となる情報（例えば、バスケット識別情報）を２次元コード化する。２次元コードを生成した携帯端末５０は、生成した２次元コードを表示部に表示する。例えば、図９（Ｃ）に示したような２次元コードを表示したコード表示画面を表示部に表示する。
ステップＳ１２：精算装置４０は、携帯端末５０の表示部に表示されている２次元コードをスキャンする（読み取る）。例えば、精算装置４０は、店員によって客側スキャナ部４０６による認識範囲内に向けられた携帯端末５０の表示部に表示されている２次元コードをスキャンする。
ステップＳ１３：携帯端末５０の表示部に表示されている２次元コードを読み取った精算装置４０は、クラウドサーバ２０に小計金額の算出を要求する。例えば、精算装置４０は、小計金額の算出を要求する算出要求（小計算出要求情報）を２次元コードから取得したバスケット識別情報とともにクラウドサーバ２０に送信する（図５及び図８の送受信データ「Ｄ５」参照）。
ステップＳ１４：携帯端末５０からバスケット識別情報及び小計算出要求情報を受信したクラウドサーバ２０は、バスケット識別情報から当該取引のバスケットを特定する。
ステップＳ１５：バスケットを特定したクラウドサーバ２０は、特定したバスケットの小計金額を算出する。具体的には、クラウドサーバ２０は、売価決定ロジック（図５参照）を用いて、小計金額を算出する。例えば、バスケットの商品が、図９（Ｂ）に示した３品（「〇〇ヨーグルト」、「〇〇チョコレート」、「〇〇食パン」）であって、売価決定ロジックＡ、Ｂ、Ｃによる割引のいずれも適用されない場合には、クラウドサーバ２０は、概算金額（図９（Ｂ）参照）である８３０円と同額の８３０円を小計金額として算出する。また例えば、バスケットの商品が、図９（Ｂ）に示した３品（「〇〇ヨーグルト」、「〇〇チョコレート」、「〇〇食パン」）であって、売価決定ロジックＢによる割引によって「〇〇ヨーグルト」が３０円値引となる場合には、クラウドサーバ２０は、概算金額（図９（Ｂ）参照）である８３０円よりも３０円安い８００円を小計金額として算出する。
ステップＳ１６：小計金額を算出したクラウドサーバ２０は、バスケット情報を更新（小計金額（算出後小計金額）を記憶）するとともに、算出した小計金額を示す小計情報をバスケット識別情報とともに精算装置４０に送信する（図５及び図８の送受信データ「Ｄ６」参照）。
ステップＳ１７：クラウドサーバ２０からバスケット識別情報及び小計情報を受信した精算装置４０は、客側表示部４０５に小計金額を表示する。例えば、精算装置４０は、小計金額（値引無しの８３０円）を示す小計情報を受信した精算装置４０は、図１０（Ａ）に示すような、合計欄に小計金額８３０を出力した精算画面を客側表示部４０５に表示する。また例えば、精算装置４０は、小計金額（３０円値引した８００円）を示す小計情報を受信した精算装置４０は、図１０（Ｂ）に示すような、合計欄に小計金額８００を出力した精算画面を客側表示部４０５に表示する。
ステップＳ１８：客側表示部４０５に小計金額を表示した精算装置４０は、支払い（精算）を実行する。具体的には、精算装置４０は、決済種別の選択を受け付ける。現金の場合には、預り金の投入を受け付けて、釣り銭金額を算出し、釣り銭がある場合には、釣り銭を放出するとともに、レシートを発行する。また、精算装置４０は、精算が完了した場合には、精算完了情報をバスケット情報とともにクラウドサーバ２０に送信し、クラウドサーバ２０は当該バスケットの取引終了日時（精算日時）を記憶する。
なお、第１実施形態（第２、第３実施形態も同様）では、クラウドサーバ２０は、売価決定ロジックＨ（決済種別値引価格算出機能）を有しないため、説明を省略したが、売価決定ロジックＨ（決済種別値引価格算出機能）を有する場合には、決済種別の選択後に、小計金額を再計算するようにしてもよい。具体的には、精算装置４０は、決済種別の選択後に、クラウドサーバ２０に小計金額の算出を再度要求し（例えば、選択された決済種別を示す決済種別選択情報をバスケット識別情報とともにクラウドサーバ２０に送信し、クラウドサーバ２０は、売価決定ロジックＨを用いて小計金額を再度算出し、再度算出した小計金額を示す小計情報をバスケット識別情報とともに精算装置４０に再度送信してもよい。あるいは、小計金額の算出が１回で済むように、ステップＳ１３の算出要求以前（例えば、携帯端末５０にて２次元コードを生成する前、精算装置４０にて２次元コードの読取後に算出要求の送信前等）に決済種別の選択を顧客に求めるようにし、ステップＳ１３の算出要求の際に決済種別選択情報もクラウドサーバ２０に送信するようにしてもよい。
［個々の商品登録時のチェック］
なお、携帯端末５０は、商品をスキャンした後に商品コードをクラウドサーバ２０に送信するが（Ｓ５）、当該店舗（来店して商品登録初期画面を表示したときの店舗）内においてスキャンした商品以外の商品（例えば、他の店舗に移動してスキャンした商品等）について商品コードを送信しないようにしてもよい。例えば、携帯端末５０は、来店時（又は商品登録初期画面の表示時）に位置情報（ＧＰＳ情報）を取得し、記憶する。また、携帯端末５０は、個々の商品をスキャンしたときに位置情報を取得し、商品のスキャン時に取得した位置情報と来店時（又は商品登録初期画面の表示時）に取得した位置情報とを比較する。そして、携帯端末５０は、両者が一致（または略一致）した場合には当該商品の商品コードのクラウドサーバ２０への送信を許可し、一致（または略一致）しなかった場合には当該商品の商品コードのクラウドサーバ２０への送信を禁止してもよい。第２、第３実施形態についても同様である。
これにより、不適切な商品登録（例えば、他の店舗等において生成されたバスケットに対する商品登録等）を防止することができる。
精算装置４０は、上述のように商品コードの送信を禁止した場合には、商品のスキャン後にエラーメッセージ（例えば、「〇〇店舗内ではないため、登録ができません」）を客側表示部４０５に表示してもよい。また、精算装置４０は、上記メッセージを客側表示部４０５に代えて又は加えて店員側表示部４１０に表示してもよい。
［２次元コードの読取時のチェック］
また、精算装置４０は、携帯端末５０の表示部に表示されている２次元コードを読み取った後にクラウドサーバ２０に小計金額の算出を要求するが（Ｓ１２）、当該店舗内においてスキャンした商品以外の商品（例えば、他の店舗でスキャンした商品等）について小計金額の算出を要求しないようにしてもよい。例えば、精算装置４０は、当該店舗の店舗識別情報を参照し（自精算装置４０内に当該店舗の店舗識別情報を記憶し参照してもよいし、アクセス可能な他の装置内に記憶されている店舗識別情報を参照してもよい）、携帯端末５０の表示部に表示されている２次元コードを読み取ったときに、当該２次元コードから得られるバスケット識別情報と、当該店舗の店舗識別情報とを比較する。そして、精算装置４０は、バスケット識別情報に含まれる店舗識別情報（図７（Ｂ）のバスケット識別情報の構成を参照）が、当該店舗の店舗識別情報を含む構成である場合には小計金額の算出の要求を許可し、当該店舗の店舗識別情報を含む構成でない場合には小計金額の算出の要求を禁止してもよい。第２、第３実施形態についても同様である。
これにより、不適切な精算（例えば、他の店舗等において商品登録された商品の精算等）を防止することができる。
精算装置４０は、上述のように小計金額の要求を禁止した場合には、２次元コードの読取後にエラーメッセージ（例えば、「〇〇店舗以外の商品を含むため、精算ができません」）を客側表示部４０５に表示してもよい。また、精算装置４０は、上記メッセージを客側表示部４０５に代えて又は加えて店員側表示部４１０に表示してもよい。
＜第２実施形態＞
続いて、第２実施形態について説明する。以下では、第２実施形態について、主に第１実施形態との差分について説明し、第１実施形態と共通する部分については説明の一部又は全部を省略する。例えば、図１〜図４、図６、図７、図９、図１０を用いて説明した内容は、各実施形態（第１〜第３実施形態）で共通するため、説明を省略する。
図１１は、第２実施形態のショッピングシステムを説明するための各機能の概念図である。なお、図１１は、本発明の第２実施形態に係るショッピングシステムを説明するためのものであり、本発明の第２実施形態に係るショッピングシステムは、図１１に示した全部の構成を必ずしも含むものではない。例えば、本発明の第２実施形態に係るショッピングシステムは、クラウドサーバ２０と精算装置４０（精算装置４１）とから構成されるものであってもよいし、クラウドサーバ２０単体であってもよいし、精算装置４０（精算装置４１）単体であってもよい。また、図１１は、本発明の第２実施形態に係るショッピングシステムの特徴部分に関連する機能を抜粋して説明するものであり、一般にショッピングシステムに必要とされる機能を網羅的に説明するものではない。
［精算装置３０（精算装置３１）］
図１１の右下に示すように、精算装置３０は、売価決定ロジック（売価決定機能）、精算機能を備える。図１１に示した例では、精算装置３０は、売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣ、売価決定ロジックＤ、売価決定ロジックＧを備えている。すなわち、第２実施形態において説明する精算装置３０（図１１参照）と、第１実施形態において説明した精算装置３０（図５参照）との差異は、第１実施形態において説明した精算装置３０が、売価決定ロジックＡ、売価決定ロジックＢを備えるのに対し、第２実施形態において説明する精算装置３０は、売価決定ロジックＡ、売価決定ロジックＢに加えて、売価決定ロジックＣ、売価決定ロジックＤ、売価決定ロジックＧを備えている点である。なお、以下、第１実施形態において説明した精算装置３０と区別するため、便宜上、第２実施形態において説明する精算装置３０を精算装置３１と称するものとする。
［管理装置１０（管理装置１１）］
図１１の右上に示すように、管理装置１０は、店舗情報、商品情報を記憶する。管理装置１０は、売価決定ロジックを備えていてもよい。すなわち、第２実施形態において説明する管理装置１０（図１１参照）と、第１実施形態において説明した管理装置１０（図５参照）との差異は、第１実施形態において説明した管理装置１０が、売価決定ロジックＡ、売価決定ロジックＢを備えていてもよいのに対し、第２実施形態において説明する管理装置１０は、売価決定ロジックＡ、売価決定ロジックＢに加えて、売価決定ロジックＣ、売価決定ロジックＤ、売価決定ロジックＧを備えていてもよい点である。なお、以下、第１実施形態において説明した管理装置１０と区別するため、便宜上、第２実施形態において説明する管理装置１０を管理装置１１と称するものとする。
［クラウドサーバ２０］
図１１の左上に示すように、クラウドサーバ２０は、売価決定ロジック（売価決定機能）を備える。図１１に示した例では、クラウドサーバ２０は、売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣを備えている。また、クラウドサーバ２０は、顧客情報、店舗情報、商品情報、バスケット情報を記憶する。なお、第２実施形態において説明するクラウドサーバ２０（図１１参照）と、第１実施形態において説明したクラウドサーバ２０（図５参照）との差異はないが、第２実施形態において説明するクラウドサーバ２０は、具備する売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣを使用しない。
［精算装置４０（精算装置４１）］
図１１の左下に示すように、精算装置４０は、クラウド通信機能、携帯端末連動機能、精算機能を備える。また、精算装置４０は、売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣを備える。すなわち、第２実施形態において説明する精算装置４０（図１１参照）と、第１実施形態において説明した精算装置４０（図５参照）との差異は、第１実施形態において説明した精算装置４０が、売価決定ロジックを備えていないのに対し、第２実施形態において説明する精算装置４０は、売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣ、売価決定ロジックＤ、売価決定ロジックＧを備えている点である。なお、以下、第１実施形態において説明した精算装置４０と区別するため、便宜上、第２実施形態において説明する精算装置４０を精算装置４１と称するものとする。
［携帯端末５０］
図１１の左下に示すように、携帯端末５０は、クラウドサーバ２０と通信する。携帯端末５０は、クラウドサーバ２０と通信することにより商品を登録する。また、携帯端末５０は、表示部に表示するコードを自ら生成し、表示部に表示する。なお、第２実施形態において説明する携帯端末５０（図１１参照）と、第１実施形態において説明した携帯端末５０（図５参照）との差異はない。
図１１の送受信データ「Ｄ０」〜「Ｄ４」は、図５の送受信データ「Ｄ０」〜「Ｄ４」と同様である。また。図１１の送受信データ「Ｄ１５」、「Ｄ１６」は、図１２にて説明する。
図１２は、図１１の機能構成における、処理の流れの概略を説明するシーケンス図である。具体的には、図１２は、図８の場面と同様、ある店舗に、ある顧客が来店し、当該店舗に陳列されている商品を登録し、登録した商品の精算が完了する迄における、当該顧客の携帯端末５０、当該店舗に設置された精算装置４１、データセンタ等の外部に設置されたクラウドサーバ２０の夫々の処理の一例を示したものである。図１２の左側が、携帯端末５０の処理、中央が精算装置４１の処理、右側がクラウドサーバ２０の処理である。
なお、図１２のステップＳ１０１〜Ｓ１１２は、図８のステップＳ１〜Ｓ１２と同様であるため、説明を省略する。
ステップＳ１１３：携帯端末５０の表示部に表示されている２次元コードをスキャンした精算装置４１は、クラウドサーバ２０にバスケット内の商品データを要求する。例えば、精算装置４１は、バスケット内の商品データを要求する商品データ要求情報を２次元コードから取得したバスケット識別情報とともにクラウドサーバ２０に送信する（図１１及び図１２の送受信データ「Ｄ１５」参照）。
ステップＳ１１４：携帯端末５０からバスケット識別情報及び商品データ要求情報を受信したクラウドサーバ２０は、バスケット識別情報から当該取引のバスケットを特定する。
ステップＳ１１５：クラウドサーバ２０は、特定したバスケットの商品データをバスケット識別情報とともに精算装置４１に送信する（図１１及び図１２の送受信データ「Ｄ１６」参照）。
ステップＳ１１６：クラウドサーバ２０からバスケット識別情報及び商品データを受信した精算装置４１は、小計金額を算出する。具体的には、精算装置４１は、売価決定ロジック（図１１参照）を用いて、小計金額を算出する。
ステップＳ１１７：小計金額を算出した精算装置４１は、客側表示部４０５に小計金額を表示する。
ステップＳ１１８：客側表示部４０５に小計金額を表示した精算装置４１は、支払い（精算）を実行する。
なお、図１２では省略しているが、小計金額を算出した精算装置４１は、算出した小計金額を示す小計情報をバスケット識別情報とともにクラウドサーバ２０に送信する。また、精算装置４１からバスケット識別情報及び小計情報を受信したクラウドサーバ２０は、バスケット情報を更新（小計金額（算出後小計金額）を記憶）する。
＜第３実施形態＞
続いて、第３実施形態について説明する。以下では、第３実施形態について、主に第１実施形態や第２実施形態との差分について説明し、第１実施形態や第２実施形態と共通する部分については説明の一部又は全部を省略する。例えば、図１〜図４、図６、図７、図９、図１０を用いて説明した内容は、各実施形態（第１〜第３実施形態）で共通するため、説明を省略する。
図１３は、第３実施形態のショッピングシステムを説明するための各機能の概念図である。なお、図１３は、本発明の第３実施形態に係るショッピングシステムを説明するためのものであり、本発明の第３実施形態に係るショッピングシステムは、図１３に示した全部の構成を必ずしも含むものではない。例えば、本発明の第３実施形態に係るショッピングシステムは、クラウドサーバ２０（クラウドサーバ２１）と精算装置４０とから構成されるものであってもよいし、クラウドサーバ２０（クラウドサーバ２１）単体であってもよいし、精算装置４０単体であってもよい。また、図１３は、本発明の第３実施形態に係るショッピングシステムの特徴部分に関連する機能を抜粋して説明するものであり、一般にショッピングシステムに必要とされる機能を網羅的に説明するものではない。
［精算装置３０（精算装置３１）］
図１３の右下に示すように、図１３の精算装置３０は、第２実施形態において説明した精算装置３１（図１１参照）と同一である。
［管理装置１０（管理装置１２）］
図１３の右上に示すように、図１３の管理装置１０は、店舗情報、商品情報を記憶する。また、図１３の管理装置１０は、売価決定ロジックを備える。具体的には、図１３の管理装置１０は、売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣ、売価決定ロジックＤ、売価決定ロジックＧを備える。また、図１３の管理装置１０は、外部連携機能を備える。管理装置１０の外部連携機能は、例えば、売価決定に関してクラウドサーバ２０（２１）と連携（通信）する機能である。具体的には、管理装置１０の外部連携機能は、クラウドサーバ２０（２１）の外部連携機能から送信される小計金額の算出要求（図１４の送受信データ「Ｄ２６」参照）を受信する機能、当該要求に基づいて売価決定ロジックを用いて算出した小計金額（図１４の送受信データ「Ｄ６」参照）をクラウドサーバ２０（２１）の外部連携機能に対して送信する機能を含む。以下、第１実施形態において説明した管理装置１０や第２実施形態において説明した管理装置１１と区別するため、便宜上、第３実施形態において説明する管理装置１１を管理装置１２と称するものとする。
［クラウドサーバ２０（クラウドサーバ２１）］
図１３の左上に示すように、クラウドサーバ２０は、売価決定ロジック（売価決定機能）、外部連携機能を備える。図１３に示した例では、クラウドサーバ２０は、売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣを備えている。クラウドサーバ２０の外部連携機能は、例えば、売価決定に関して管理装置１２と連携（通信）する機能である。具体的には、クラウドサーバ２０の外部連携機能は、小計金額の算出要求（図１４の送受信データ「Ｄ２６」参照）を管理装置１２の外部連携機能に対して送信する機能、管理装置１２の外部連携機能から送信される小計金額（図１４の送受信データ「Ｄ６」参照）を受信する機能を含む。また、クラウドサーバ２０は、顧客情報、店舗情報、商品情報、バスケット情報を記憶する。また、第３実施形態において説明するクラウドサーバ２０は、具備する売価決定ロジックＡ、売価決定ロジックＢ、売価決定ロジックＣを使用しない。以下、第１、第２実施形態において説明したクラウドサーバ２０と区別するため、便宜上、第３実施形態において説明するクラウドサーバ２０をクラウドサーバ２１と称するものとする。
［精算装置４０］
図１３の左下に示すように、図１３の精算装置４０は、第１実施形態において説明した精算装置４０（図５参照）と差異はない。
［携帯端末５０］
図１３の左下に示すように、図１３の携帯端末５０は、第１、第２実施形態において説明した携帯端末５０（図５、図１１参照）と差異はない。
図１３の送受信データ「Ｄ０」〜「Ｄ６」は、図５の送受信データ「Ｄ０」〜「Ｄ６」と同様である。図１３の送受信データ「Ｄ２６」は、図１４にて説明する。
図１４は、図１３の機能構成における、処理の流れの概略を説明するシーケンス図である。具体的には、図１４は、図８や図１２の場面と同様、ある店舗に、ある顧客が来店し、当該店舗に陳列されている商品を登録し、登録した商品の精算が完了する迄における、当該顧客の携帯端末５０、当該店舗に設置された精算装置４０、データセンタ等の外部に設置されたクラウドサーバ２１の夫々の処理の一例を示したものである。図１４の左側が、携帯端末５０の処理、中央が精算装置４０の処理、右側がクラウドサーバ２１の処理である。
なお、図１４のステップＳ２０１〜Ｓ２１４は、図８のステップＳ１〜Ｓ１４と同様であるため、説明を省略する。
ステップＳ２１５：バスケットを特定したクラウドサーバ２１は、管理装置１２に小計金額の算出を要求する。例えば、クラウドサーバ２１は、小計金額の算出を要求する算出要求（小計算出要求情報）を、ステップＳ２１４にて特定したバスケットの商品データ、及び、バスケット識別情報とともに、管理装置１２に送信する（図１３及び図１４の送受信データ「Ｄ２６」参照）。
ステップＳ２１６：クラウドサーバ２１からバスケット識別情報、小計算出要求情報及び商品データを受信した管理装置１２は、小計金額を算出する。具体的には、管理装置１２は、売価決定ロジック（図１３参照）を用いて、小計金額を算出する。
ステップＳ２１７：小計金額を算出した管理装置１２は、算出した小計金額を示す小計情報をバスケット識別情報とともにクラウドサーバ２１に送信する（図１３及び図１４の送受信データ「Ｄ６」参照）。
ステップＳ２１８：管理装置１２からバスケット識別情報及び小計情報を受信したクラウドサーバ２１は、バスケット情報を更新（小計金額（算出後小計金額）を記憶）するとともに、管理装置１２から受信したバスケット識別情報及び小計情報を精算装置４０に送信する（図１３及び図１４の送受信データ「Ｄ６」参照）。
ステップＳ２１９：クラウドサーバ２１からバスケット識別情報及び小計情報を受信した精算装置４０は、客側表示部４０５に小計金額を表示する。
ステップＳ２２０：客側表示部４０５に小計金額を表示した精算装置４０は、支払い（精算）を実行する。
なお、ステップＳ２１５〜Ｓ２１６、ステップＳ２１７〜Ｓ２１８における各種情報（送受信データ「Ｄ２６」、送受信データ「Ｄ６」）の送受信は、クラウドサーバ２１側の外部連携機能、管理装置１２側の外部連携機能によって実現される。
以下、より詳細な動作の流れについて説明する。
図１５及び図１６は、商品登録時における、より詳細な動作の流れの一例を示すフローチャートである。具体的には、図１５及び図１６は、第１実施形態として説明した図８のステップＳ５〜Ｓ１１、第２実施形態として説明した図１２のステップＳ１０５〜Ｓ１１１、第３実施形態として説明した図１４のステップＳ２０５〜Ｓ２１１の範囲について、保留商品やキャンセルがある場合を考慮して説明したものである。図１６は図１５の続きである。なお、図８等にて説明した内容の一部については説明を省略している。
ステップＳ３０：携帯端末５０は、商品に付されたバーコードをスキャンする操作があったか否かを判断する。例えば、携帯端末５０は、各種センサ（例えば、ジャイロセンサ、加速度センサ、距離センサ等）を備え、当該携帯端末５０がバーコードを読み取る姿勢になったと各種センサが判断してから所定時間継続して当該姿勢を維持したと判断した場合（つまり所定時間以上、バーコードを読み取る姿勢を維持した場合）、または、所定時間内にバーコードを読み取った場合に（つまり、商品コードを取得した場合に）、商品に付されたバーコードをスキャンする操作があったと判断する。バーコードをスキャンする操作があったと判断した場合には携帯端末５０の処理としてはステップＳ３１に進む。バーコードをスキャンする操作がなかったと判断した場合には携帯端末５０の処理としては図１６のステップＳ５０に進む。
ステップＳ３１：携帯端末５０は、商品コードの読み取りに成功したか否かを判断する。商品コードの読み取りに成功したと判断した場合には携帯端末５０の処理としてはステップＳ３２に進む。商品コードの読み取りに失敗したと判断した場合には携帯端末５０の処理としてはステップＳ４５に進む。
ステップＳ３２：携帯端末５０は、バスケット識別情報とともに、スキャンによって得られた商品コードをクラウドサーバ２０（２１）に送信する。そして携帯端末５０の処理としてはステップＳ４１に進む。
ステップＳ３３：クラウドサーバ２０（２１）は、バスケット識別情報及び商品コードを受信したか否かを判断する。バスケット識別情報及び商品コードを受信した場合にはクラウドサーバ２０（２１）の処理としてはステップＳ３４に進む。バスケット識別情報及び商品コードを受信していない場合にはクラウドサーバ２０（２１）の処理としてはステップＳ４８に進む。
ステップＳ３４：クラウドサーバ２０（２１）は、当該店舗の商品情報を参照する。具体的には、クラウドサーバ２０（２１）は、当該店舗の商品情報を参照し、携帯端末５０から受信した商品コードの商品を特定する（特定しようとする）。つまり、クラウドサーバ２０（２１）は、当該店舗の商品情報内に、携帯端末５０から受信した商品コードが記憶されているかを確認する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ３５に進む。
ステップＳ３５：携帯端末５０から受信した商品コードの商品を特定できた場合にはクラウドサーバ２０（２１）の処理としてはステップＳ３６に進む。携帯端末５０から受信した商品コードの商品を特定できなかった場合にはクラウドサーバ２０（２１）の処理としてはステップＳ３８に進む。
ステップＳ３６：クラウドサーバ２０（２１）は、バスケットに登録商品情報を記憶する。具体的には、クラウドサーバ２０（２１）は、登録商品情報として、商品コード、品名、価格等を記憶する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ３７に進む。
ステップＳ３７：クラウドサーバ２０（２１）は、商品登録更新画面情報（ステップＳ３６の登録商品情報が反映された商品登録画面の画面情報）を生成し、携帯端末５０に送信する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ４８に進む。
ステップＳ３８：クラウドサーバ２０（２１）は、バスケットに保留商品情報を記憶する。具体的には、クラウドサーバ２０（２１）は、保留商品情報として、保留商品種別「１（ＮＯＮ−ＰＬＵ）」、商品コードを記憶する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ３９に進む。
ステップＳ３９：クラウドサーバ２０（２１）は、商品登録更新画面情報（ステップＳ３８の保留商品情報が反映された商品登録画面の画面情報）を生成し、携帯端末５０に送信する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ４０に進む。
ステップＳ４０：クラウドサーバ２０（２１）は、エラーメッセージ（ＮＯ−ＦＩＬＥ）を、携帯端末５０に送信する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ４８に進む。
ステップＳ４１：携帯端末５０は、エラーメッセージを受信したか否かを判断する。エラーメッセージを受信したと判断した場合には携帯端末５０の処理としてはステップＳ４３に進む。エラーメッセージを受信していないと判断した場合には携帯端末５０の処理としてはステップＳ４２に進む。
ステップＳ４２：携帯端末５０は、登録画面を更新する。つまり、携帯端末５０の表示部には、ステップＳ３０のスキャン操作を反映した登録画面（スキャン操作した商品が追加表示された登録画面）が表示される。そして携帯端末５０の処理としては図１６のステップＳ５０に進む。
ステップＳ４３：携帯端末５０は、登録画面を更新する。つまり、携帯端末５０の表示部には、ステップＳ３０のスキャン操作を反映した登録画面（スキャン操作した商品が保留商品（ＮＯ−ＦＩＬＥ）として追加表示された登録画面）が表示される。そして携帯端末５０の処理としてはステップＳ４４に進む。
ステップＳ４４：携帯端末５０は、エラーメッセージを表示する。具体的には、携帯端末５０は、ステップＳ３０にてスキャン操作を行った商品が保留商品（ＮＯ−ＦＩＬＥ）である旨のエラーメッセージを表示する。なお、携帯端末５０は、保留商品（ＮＯ−ＦＩＬＥ）である旨のエラーメッセージに代えて又は加えて、買い物カゴの中で保留商品を保留商品以外の商品と分けて入れておく旨を指示するメッセージを表示してもよい。そして携帯端末５０の処理としては図１６のステップＳ５０に進む。
ステップＳ４５：携帯端末５０は、商品（商品コードの読み取りに失敗した商品）を撮像し、バスケット識別情報とともに、撮像画像（画像データ）をクラウドサーバ２０（２１）に送信する。携帯端末５０は、撮像画像をクラウドサーバ２０（２１）に送信することに加えて、撮像画像を記憶部に記憶してもよい。そして携帯端末５０の処理としてはステップＳ４６に進む。
ステップＳ４６：携帯端末５０は、登録画面を更新する。つまり、携帯端末５０の表示部には、ステップＳ３０のスキャン操作を反映した登録画面（スキャン操作した商品が保留商品（読取ＮＧ）として追加表示された登録画面）が表示される。そして携帯端末５０の処理としてはステップＳ４７に進む。
ステップＳ４７：携帯端末５０は、エラーメッセージを表示する。具体的には、携帯端末５０は、ステップＳ３０にてスキャン操作を行った商品が保留商品（読取ＮＧ）である旨のエラーメッセージを表示する。なお、携帯端末５０は、保留商品（ＮＧ）である旨のエラーメッセージに代えて又は加えて、買い物カゴの中で保留商品を保留商品以外の商品と分けて入れておく旨を指示するメッセージを表示してもよい。そして携帯端末５０の処理としては図１６のステップＳ５０に進む。
ステップＳ４８：クラウドサーバ２０（２１）は、画像データを受信したか否かを判断する。画像データを受信した場合にはクラウドサーバ２０（２１）の処理としてはステップＳ４９に進む。画像データを受信していない場合にはクラウドサーバ２０（２１）の処理としては図１６のステップＳ５２に進む。
ステップＳ４９：クラウドサーバ２０（２１）は、バスケットに保留商品情報を記憶する。具体的には、クラウドサーバ２０（２１）は、保留商品情報として、保留商品種別「１（読取ＮＧ）」、ステップＳ４８にて受信した画像データを記憶する。そしてクラウドサーバ２０（２１）の処理としては図１６のステップＳ５２に進む。
ステップＳ５０：携帯端末５０は、登録済の商品（ステップＳ３６においてバスケット内に登録商品情報が記憶された商品）をキャンセルする操作（例えば、登録画面上に表示されている商品をタッチにより選択し、選択後に表示されるキャンセルボタンをタッチする操作等）があったか否かを判断する。登録済の商品をキャンセルする操作があったと判断した場合には携帯端末５０の処理としてはステップＳ５１に進む。登録済の商品をキャンセルする操作がなかったと判断した場合には携帯端末５０の処理としてはステップＳ６０に進む。
ステップＳ５１：携帯端末５０は、バスケット識別情報とともに、商品キャンセル情報をクラウドサーバ２０（２１）に送信する。商品キャンセル情報は、例えば、キャンセルする商品の商品コード、数量等を含む。そして携帯端末５０の処理としてはステップＳ５６に進む。なお、携帯端末５０が、キャンセルする商品の商品コードを取得する方法としては種々の方法が考えられるが、例えば、クラウドサーバ２０（２１）が携帯端末５０に送信する商品登録更新画面情報内に登録済の商品の商品コードが格納（記憶）され、携帯端末５０は商品登録更新画面情報からキャンセルする商品の商品コードを取得してもよい。
ステップＳ５２：クラウドサーバ２０（２１）は、バスケット識別情報及びキャンセル情報を受信したか否かを判断する。バスケット識別情報及びキャンセル情報を受信した場合にはクラウドサーバ２０（２１）の処理は終了する。なお、クラウドサーバ２０（２１）の処理としては、終了後に再度、図１５のステップＳ３３から開始される。バスケット識別情報及びキャンセル情報を受信した場合にはクラウドサーバ２０（２１）の処理としてはステップＳ５３に進む。
ステップＳ５３：クラウドサーバ２０（２１）は、バスケットの登録商品情報を削除する。具体的には、クラウドサーバ２０（２１）は、バスケット識別情報及びキャンセル情報によって示されるバスケット内の商品登録情報を削除する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ５４に進む。なお、クラウドサーバ２０（２１）は、複数個登録された登録済の商品のうちの一部をキャンセルするキャンセル情報を受信した場合には当該登録済の商品の個数を更新する。例えば、５個登録された登録済の商品のうちの２個をキャンセルするキャンセル情報を受信した場合には当該登録済の商品の個数を５個から３個に更新する。
ステップＳ５４：クラウドサーバ２０（２１）は、バスケットにキャンセル情報を記憶する。具体的には、クラウドサーバ２０（２１）は、キャンセル情報として、商品コード、数量等を記憶する。そしてクラウドサーバ２０（２１）の処理としてはステップＳ５５に進む。
ステップＳ５５：クラウドサーバ２０（２１）は、商品登録更新画面情報（ステップＳ５３の登録商品情報を削除やステップＳ５４のキャンセル情報が反映された商品登録画面の画面情報）を生成し、携帯端末５０に送信する。そしてクラウドサーバ２０（２１）の処理は終了する。なお、クラウドサーバ２０（２１）の処理としては、終了後に再度、図１５のステップＳ３３から開始される。
ステップＳ５６：携帯端末５０は、登録画面を更新する。つまり、携帯端末５０の表示部には、ステップＳ５０のキャンセル操作を反映した登録画面（登録済の商品が削除された登録画面、登録済の商品の個数が減少した登録画面）が表示される。そして携帯端末５０の処理としてはステップＳ６０に進む。
ステップＳ６０：携帯端末５０は、会計指示（例えば、図９（Ｂ）に示した「お会計へ進む」ボタンのタッチ）があったか否かを判断する。会計指示があったと判断した場合にはステップＳ６１に進む。会計指示がなかったと判断した場合にはステップＳ３０に戻る。
ステップＳ６１：携帯端末５０は、２次元コードを生成する。つまり、携帯端末５０は、当該携帯端末５０による買上商品について精算処理を実行するために必要となる情報（例えば、バスケット識別情報）を２次元コード化する。そして携帯端末５０の処理としてはステップＳ６２に進む。
ステップＳ６２：携帯端末５０は、ステップＳ６１にて生成した２次元コードを表示部に表示する。そして携帯端末５０の処理は終了する。
図１７は、精算時における、より詳細な動作の流れの一例を示すフローチャートである。具体的には、図１７は、第１実施形態として説明した図８のステップＳ１２〜Ｓ１８の範囲について、保留商品やキャンセルがある場合を考慮して説明したものである。なお、図８にて説明した内容の一部については説明を省略している。
ステップＳ７０：精算装置４０は、携帯端末５０の表示部に表示されている２次元コードの読み取ったか否かを判断する。２次元コードの読み取ったと判断した場合にはステップＳ７１に進む。２次元コードの読み取っていないと判断した場合にはステップＳ７０を繰り返し実行する。
ステップＳ７１：精算装置４０は、クラウドサーバ２０に小計金額の算出を要求する。例えば、精算装置４０は、小計金額の算出を要求する算出要求（小計算出要求情報）を２次元コードから取得したバスケット識別情報とともにクラウドサーバ２０に送信する。
ステップＳ７２：クラウドサーバ２０は、バスケット識別情報及び小計算出要求情報を受信したか否かを判断する。バスケット識別情報及び小計算出要求情報を受信した場合にはステップＳ７３に進む。バスケット識別情報及び小計算出要求情報を受信していない場合にはステップＳ７１を繰り返し実行する。
ステップＳ７３：クラウドサーバ２０は、精算装置４０が小計金額の算出を要求しているバスケットを特定する。具体的には、クラウドサーバ２０は、精算装置４０から受信したバスケット識別情報から、精算装置４０が小計金額の算出を要求しているバスケットを特定する。そしてクラウドサーバ２０の処理としてはステップＳ７４に進む。
ステップＳ７４：クラウドサーバ２０は、小計金額の算出を要求している顧客（当該バスケットに係る顧客）を特定する。具体的には、クラウドサーバ２０は、ステップＳ７２において特定したバスケット内の顧客識別情報から、小計金額の算出を要求している顧客を特定する。そしてクラウドサーバ２０の処理としてはステップＳ７５に進む。
ステップＳ７５：クラウドサーバ２０は、小計金額の算出を要求している顧客（ステップＳ７４にて特定した顧客）のキャンセルの状況を確認する。具体的には、クラウドサーバ２０は、当該顧客の顧客情報（図７（Ａ）参照）のキャンセル情報を参照して、当該顧客の過去のキャンセルの状況を確認する。なお、クラウドサーバ２０は、当該顧客の顧客情報（図７（Ａ）参照）のキャンセル情報に代えて又は加えて、当該バスケット情報（図７（Ｃ））のキャンセル情報（キャンセル情報（今回の合計）等）を参照し、当該顧客の今回のキャンセルの状況を確認してもよい。そしてクラウドサーバ２０の処理としてはステップＳ７６に進む。
ステップＳ７６：クラウドサーバ２０は、確認したキャンセルの状況に基づいて、警告が必要か否かを判断する。例えば、ステップＳ７５にて過去のキャンセルの状況を確認する態様では、例えば、クラウドサーバ２０は、過去２回（前回来店時、前々回の来店時）の合計のキャンセル回数と、所定の閾値（閾値Ａとする）とを比較し、過去２回の合計のキャンセル回数が閾値Ａ以上である場合には警告が必要であると判断し、過去２回の合計のキャンセル回数が閾値Ａ未満である場合には警告が不要であると判断してもよい。また例えば、ステップＳ７５にて今回のキャンセルの状況と過去のキャンセルの状況の両方を確認する態様では、例えば、クラウドサーバ２０は、今回のキャンセルの回数と、所定の閾値（閾値Ｂとする）とを比較し、また、過去２回の合計のキャンセル回数と、所定の閾値（閾値Ｃとする）とを比較し、今回のキャンセル回数が閾値Ｂ以上かつ過去２回の合計のキャンセル回数が閾値Ｃ以上である場合には警告が必要であると判断し、他の場合（今回のキャンセル回数が閾値Ｂ未満である場合（過去２回の合計のキャンセル回数は問わない）、今回のキャンセル回数が閾値Ｂ以上であるが過去２回の合計のキャンセル回数が閾値Ｃ未満である場合）には警告が不要であると判断してもよい。また例えば、ステップＳ７５にて今回のキャンセルの状況を確認する態様では、例えば、クラウドサーバ２０は、今回のキャンセル回数と、所定の閾値（閾値Ｄとする）とを比較し、今回のキャンセル回数が閾値Ｄ以上である場合には警告が必要であると判断し、今回のキャンセル回数が閾値Ｄ未満である場合には警告が不要であると判断してもよい。なお、閾値Ａ〜Ｄは、何れも互いに異なる数であってもよいし、２つ以上が同じ数であってもよい。警告が必要であると判断した場合にはステップＳ７７に進む。警告が必要でない（不要である）と判断した場合にはステップＳ８０に進む。
ステップＳ７７：クラウドサーバ２０は、警告情報を精算装置４０に送信する。そしてクラウドサーバ２０の処理としてはステップＳ８０に進む。
ステップＳ７８：精算装置４０は、警告情報を受信したか否かを判断する。警告情報を受信した場合にはステップＳ７９に進む。警告情報を受信していない場合にはステップＳ８２に進む。
ステップＳ７９：精算装置４０は、警告する。例えば、精算装置４０は、店員が商品の内容を確認する旨のメッセージを客側表示部４０５に表示してもよい。また、精算装置４０は、上記に代えて又は加えて、商品のキャンセルについて確認すべきる旨のメッセージを店員側表示部４１０に表示してもよい。なお、精算装置４０は、具体的な数値を用いたメッセージ（例えば、ステップＳ７５にて過去のキャンセルの状況を確認した場合には当該顧客についてキャンセル実績が基準以上の〇〇回である旨のメッセージや、ステップＳ７５にて今回のキャンセルの状況を確認した場合には当該顧客について本取引のキャンセルが基準以上の〇〇回である旨のメッセージ）を店員側表示部４１０に表示してもよい。
ステップＳ８０：クラウドサーバ２０は、バスケット情報内に保留商品（ＮＯＮ−ＰＬＵ、読取ＮＧ）があるか否か判断する。保留商品があると判断した場合にはステップＳ８１に進む。保留商品がないと判断した場合にはステップＳ８８に進む。
ステップＳ８１：クラウドサーバ２０は、バスケット情報内に保留商品について修正を指示する情報（修正指示情報）を精算装置４０に送信する。そしてクラウドサーバ２０の処理としてはステップＳ８６に進む。
ステップＳ８２：精算装置４０は、修正指示情報を受信したか否かを判断する。修正指示情報を受信した場合にはステップＳ８３に進む。修正指示情報を受信していない場合にはステップＳ９０に進む。
ステップＳ８３：精算装置４０は、保留商品がある旨を報知する。例えば、精算装置４０は、客側表示部４０５、店員側表示部４１０のいずれか一方又は両方において、保留商品がある旨のメッセージを表示する。例えば、精算装置４０は、店員が商品の内容を確認する旨のメッセージ（図１０（Ｃ）参照）を表示した小画面を客側表示部４０５に表示してもよい。また、精算装置４０は、上記に代えて又は加えて、保留商品がある旨のメッセージを店員側表示部４１０に表示してもよい。そして精算装置４０の処理としてはステップＳ８４に進む。
ステップＳ８４：精算装置４０は、店員による保留商品の修正を受け付ける。例えば、保留商品（読取ＮＧ）について、店員による当該商品（例えば陳列棚にある同一商品）のスキャンを行う。また例えば、保留商品（ＮＯＮ−ＰＬＵ）について、店員による価格の入力を行う。保留商品（読取ＮＧ、ＮＯＮ−ＰＬＵ）について、店員がキャンセルしてもよい。つまり、いずれの方法であっても、店員による保留商品の修正を受け付けることによって保留商品がなくなるようにすればよい。なお、店員によるキャンセルは、バスケット情報内の今回のキャンセル回数に（顧客情報内の過去のキャンセル回数はバスケット情報内の今回のキャンセル回数に基づくものであるため結果として顧客情報内の過去のキャンセル回数にも）に反映されないようにしてもよい。一例として、店員によるキャンセル操作を特別なキャンセル操作（顧客によって行われるキャンセル操作と異なる操作）とし、特別なキャンセル操作が行われた場合には、今回のキャンセル回数に反映されないようにしてもよい。
ステップＳ８５：精算装置４０は、店員による保留商品の修正内容を示した修正情報をバスケット識別情報とともにクラウドサーバ２０に送信する。そして精算装置４０の処理としてはステップＳ９０に進む。
ステップＳ８６：クラウドサーバ２０は、バスケット識別情報及び修正情報を受信したか否かを判断する。バスケット識別情報及び修正情報を受信した場合にはステップＳ８７に進む。バスケット識別情報及び修正情報を受信していない場合にはステップＳ８６を繰り返し実行する。
ステップＳ８７：クラウドサーバ２０は、修正情報に従ってバスケットの情報を更新する。そしてクラウドサーバ２０の処理としてはステップＳ８８に進む。
ステップＳ８８：クラウドサーバ２０は、バスケットの小計金額を算出する。そしてクラウドサーバ２０の処理としてはステップＳ８９に進む。
ステップＳ８９：クラウドサーバ２０は、バスケット情報を更新（小計金額（算出後小計金額）を記憶）するとともに、算出した小計金額を示す小計情報をバスケット識別情報とともに精算装置４０に送信する。そしてクラウドサーバ２０の処理は終了する。
ステップＳ９０：精算装置４０は、客側表示部４０５に小計金額を表示する。
ステップＳ９１：精算装置４０は、支払い（精算）を実行する。そして精算装置４０の処理は終了する。なお、ステップＳ９１の処理の終了時には、精算が完了した旨の情報をクラウドサーバ２０に送信する。
図１８は、バスケット情報内に記憶される情報の一例である。なお、図１８は、図７（Ｃ）に示したバスケット情報の一部を示している。
図１８（Ａ）は、１品目の商品（「〇〇ヨーグルト」）が正常に登録されたときにおける（保留商品とならなかったときにおける）、バスケット情報内に記憶される情報を示している。図１８（Ａ）に示した例では、登録商品情報（計）として品数「１」と概算小計金額「２６０」とが記憶され、登録商品情報（登録商品１）として「〇〇ヨーグルト」の商品コード「Ｓ５１１１」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「２６０」とが記憶されている。
クラウドサーバ２０（２１）は、１品目の商品の商品コードを受信し、当該商品コードの商品（「〇〇ヨーグルト」）を特定した場合（図１５のステップＳ３５（ＹＥＳ））、図１８（Ａ）に示すように登録商品情報（計）を記憶し、図１８（Ａ）に示すように登録商品情報（登録商品１）を記憶する（ステップＳ３６）。すなわち、登録商品情報（登録商品１）は、携帯端末５０において１品目の商品（「〇〇ヨーグルト」）の商品コード（「Ｓ５１１１」）の読み取りが成功し（図１５のステップＳ３１（ＹＥＳ））、クラウドサーバ２０（２１）に該商品コード（「Ｓ５１１１」）が送信され（ステップＳ３２）、クラウドサーバ２０（２１）において該商品コード（「Ｓ５１１１」）の商品（「〇〇ヨーグルト」）が特定された場合に（ステップＳ３５（ＹＥＳ））、記憶されたものである（ステップＳ３６）。
図１８（Ｂ）は、３品目の商品（「〇〇食パン」）迄が正常に登録されたときにおける、バスケット情報内に記憶される情報を示している。図１８（Ｂ）に示した例では、登録商品情報（計）として品数「３」と概算小計金額「８３０」とが記憶され、登録商品情報（登録商品１）として「〇〇ヨーグルト」の商品コード「Ｓ５１１１」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「２６０」とが記憶され、登録商品情報（登録商品２）として「〇〇チョコレート」の商品コード「Ｓ３０８３」と商品名「〇〇チョコレート」と「〇〇チョコレート」の価格「３５０」とが記憶され、登録商品情報（登録商品３）として「〇〇食パン」の商品コード「Ｓ１４９３」と商品名「〇〇食パン」と「〇〇食パン」の価格「２２０」とが記憶されている。
クラウドサーバ２０（２１）は、３品目の商品の商品コードを受信し、当該商品コードの商品（「〇〇食パン」）を特定した場合（図１５のステップＳ３５（ＹＥＳ））、図１８（Ｂ）に示すように登録商品情報（計）を更新し、図１８（Ｂ）に示すように登録商品情報（登録商品３）を記憶する（ステップＳ３６）。なお、登録商品情報（登録商品１）は、１品目の商品（「〇〇ヨーグルト」）が特定されたときに記憶されたものである（ステップＳ３６）。登録商品情報（登録商品２）は、２品目の商品（「〇〇チョコレート」）が特定されたときに記憶されたものである（ステップＳ３６）。
図１８（Ｃ）は、例えば図１８（Ｂ）の状態から「〇〇食パン」がキャンセルされたときにおける、バスケット情報内に記憶される情報を示している。図１８（Ｃ）に示した例では、登録商品情報（計）として品数「２」と概算小計金額「６１０」とが記憶され、登録商品情報（登録商品１）として「〇〇ヨーグルト」の商品コード「Ｓ５１１１」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「２６０」とが記憶され、登録商品情報（登録商品２）として「〇〇チョコレート」の商品コード「Ｓ３０８３」と商品名「〇〇チョコレート」と「〇〇チョコレート」の価格「３５０」とが記憶され、キャンセル情報（今回の合計）としてキャンセル回数「１」が記憶され、キャンセル情報（キャンセル１）として「〇〇食パン」の商品コード「Ｓ１４９３」と数量「１」とが記憶されている。
クラウドサーバ２０（２１）は、商品キャンセル情報（「〇〇食パン」の商品コードを含む）を受信した場合（図１６のステップＳ５２（ＹＥＳ））、図１８（Ｃ）に示すように登録商品情報（計）を更新し、図１８（Ｃ）に示すように登録商品情報（登録商品３）を削除するとともに（ステップＳ５３）、図１８（Ｃ）に示すようにキャンセル情報（今回の合計）を記憶し、キャンセル情報（キャンセル１）を記憶する（ステップＳ５４）。すなわち、携帯端末５０において、既に登録済の３品目の商品「〇〇食パン」をキャンセルする操作が行われた場合（図１６のステップＳ５０（ＹＥＳ））、クラウドサーバ２０（２１）に商品キャンセル情報（「〇〇食パン」の商品コードを含む）が送信され（ステップＳ５１）、クラウドサーバ２０（２１）において、商品「〇〇食パン」の登録商品情報が削除され（ステップＳ５３）、商品「〇〇食パン」のキャンセル情報が記憶される（ステップＳ５４）。
図１８（Ｄ）は、１品目の商品（「〇〇ヨーグルト」）が正常に登録され、２品目の商品（「〇〇チョコレート」）が保留商品（ＮＯＮ−ＰｌＵ）となり、３品目の商品（「〇〇食パン」）が保留商品（読取ＮＧ）となったときにおける、バスケット情報内に記憶される情報を示している。図１８（Ｄ）に示した例では、登録商品情報（計）として品数「１」と概算小計金額「２６０」とが記憶され、登録商品情報（登録商品１）として「〇〇ヨーグルト」の商品コード「Ｓ５１１１」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「２６０」とが記憶され、保留商品情報（計）として全体品数「２」とＮＯＮ−ＰＬＵ品数「１」と読取ＮＧ（要不正操作確認）品数「１」とが記憶され、保留商品情報（保留商品１）として保留商品種別「１（ＮＯＮ−ＰＬＵ）」と「〇〇チョコレート」の商品コード「Ｓ３０８３」とが記憶され、保留商品情報（保留商品２）として保留商品種別「２（読取ＮＧ）」と「〇〇食パン」のバーコードを含む部分が撮像されている撮像画像「ＡＡＡ.ｊｐｅｇ」とが記憶されている。
保留商品情報（保留商品１）は、携帯端末５０において２品目の商品（「〇〇チョコレート」）の商品コード（「Ｓ３０８３」）の読み取りが成功し（図１５のステップＳ３１（ＹＥＳ））、クラウドサーバ２０（２１）に該商品コード（「Ｓ３０８３」）が送信されたが（ステップＳ３２）、クラウドサーバ２０（２１）において該商品コード（「Ｓ３０８３」）の商品（実際には「〇〇チョコレート」）が特定されなかった場合に（ステップＳ３５（ＮＯ））、記憶されたものである（ステップＳ３８）。
保留商品情報（保留商品２）は、携帯端末５０において３品目の商品（「〇〇食パン」）の商品コード（「Ｓ１４９３」）の読み取りが失敗し（図１５のステップＳ３１（ＮＯ））、クラウドサーバ２０（２１）に該商品（「〇〇食パン」）を撮像した画像データが送信され（ステップＳ４５）、クラウドサーバ２０（２１）において該画像データを受信した場合に（ステップＳ４８（ＹＥＳ））、記憶されたものである（ステップＳ４９）。
以上、各実施形態について説明したが、各実施形態のコンセプト（概念）等について説明する。
図５に示した第１実施形態のショッピングシステムにおいて、精算装置４０は、クラウドサーバ２０によるサービスの利用するために、新たに店舗に設置（納入）した装置であってもよい。つまり、図５に示した第１実施形態のショッピングシステムは、クラウドサーバ２０によるサービスの利用を開始するのに際し、元々店舗に設置されていた精算装置３０とは別に、クラウドサーバ２０によるサービスを利用するために必要となる機能（携帯端末連動機能、クラウド通信機能）を具備した新端末である精算装置４０を追加的に導入して構築されたものであってもよい。換言すれば、第１実施形態のショッピングシステムは、例えば既存の外部のクラウドサーバ２０によるサービスの利用を開始するのに際し、既存の精算装置３０や管理装置１０に対する改修を行わずに（管理装置１０については店舗情報及び商品情報を送信するといった若干の機能追加があるが）、単に新端末である精算装置４０を追加的に設置さえすればよく（クラウドサーバ２０について店舗情報及び商品情報を受信するといった若干の機能追加があるが）、クラウドサーバ２０によるサービスを短期間のうちに導入できるといったコンセプトに基づいて構築されたものである。
クラウドサーバ２０によるセルフシステム（セルフ登録システム、セルフスキャンシステム）の導入前の時点では、既存のシステム（管理装置１０、精算装置３０）にて運用されている売価決定ロジック（売価決定ロジックＡ、Ｂ）が、クラウドサーバ２０が提供可能な売価決定ロジック（売価決定ロジックＡ、Ｂ、Ｃ）の範囲内にあるため、クラウドサーバ２０によるセルフシステムの導入に際し、既存の売価決定ロジックを利用する必要はない。従って、新端末である精算装置４０を追加する程度で足り、導入時のコストを抑えることができる。なお、図５に示す例では、クラウドサーバ２０は、売価決定ロジックＣを実装しているが、運用しない。
図１１に示した第２実施形態のショッピングシステムにおいて、精算装置４１は、クラウドサーバ２０によるサービスの利用するために、図５に示した精算装置４０、又は、既存の精算装置３１を改修した装置であってもよい。つまり、図１１に示した第１実施形態のショッピングシステムは、クラウドサーバ２０によるサービスの利用を開始するのに際し、新端末である精算装置４０、又は、元々店舗に設置されていた精算装置３１に対し、クラウドサーバ２０によるサービスを利用するために必要となる機能（新端末である精算装置４０に対しては売価決定ロジック、精算装置３１に対しては携帯端末連動機能、クラウド通信機能）を追加して構築されたものであってもよい。換言すれば、第２実施形態のショッピングシステムは、例えば既存の外部のクラウドサーバ２０によるサービスの利用を開始するのに際し、新端末である精算装置４０、又は、既存の精算装置３１に対する改修を行えば（管理装置１０やクラウドサーバ２０についても店舗情報及び商品情報の送受信といった若干の機能追加はあるが）、クラウドサーバ２０によるサービスを短期間のうちに導入できるといったコンセプトに基づいて構築されたものである。
クラウドサーバ２０によるセルフシステムの導入前の時点では、既存のシステム（管理装置１１、精算装置３１）にて運用されている売価決定ロジック（売価決定ロジックＡ、Ｂ、Ｃ、Ｄ、Ｇ）が、クラウドサーバ２０が提供可能な売価決定ロジック（売価決定ロジックＡ、Ｂ、Ｃ）の範囲内にないため、クラウドサーバ２０によるセルフシステムの導入に際し、既に存在する精算装置（精算装置４０、精算装置３１）に対し機能を追加するが、比較的、導入時のコストを抑えることができる。クラウドサーバや管理装置の改修よりも、精算装置の改修の方が容易であると判断した場合に有効である。なお、図１１に示す例では、クラウドサーバ２０は、売価決定ロジック（売価決定ロジックＡ、Ｂ、Ｃ）を実装しているが、運用しない。
図１３に示した第３実施形態のショッピングシステムにおいて、精算装置４０は、クラウドサーバ２１によるサービスの利用するために、新たに店舗に設置（納入）した装置であってもよい。つまり、図１３に示した第３実施形態のショッピングシステムは、クラウドサーバ２０によるサービスの利用を開始するのに際し、クラウドサーバ２０を改修（外部連携機能を追加）してクラウドサーバ２１とし、元々店舗に設置されていた管理装置１１を改修（外部連携機能を追加）して管理装置１２とし、更に、元々店舗に設置されていた精算装置３０とは別に、クラウドサーバ２１によるサービスを利用するために必要となる機能（携帯端末連動機能、クラウド通信機能）を具備した新端末である精算装置４０を追加的に導入して構築されたものであってもよい。換言すれば、第３実施形態のショッピングシステムは、例えば既存の外部のクラウドサーバ２０によるサービスの利用を開始するのに際し、既存の精算装置３１に対する改修を行わずに、既存のクラウドサーバ２０と管理装置１１に改修を行えば、あとは、単に新端末である精算装置４０を追加的に設置さえすれば、改修後のクラウドサーバ２１によるサービスを短期間のうちに導入できるといったコンセプトに基づいて構築されたものである。
クラウドサーバ２０によるセルフシステムの導入前の時点では、既存のシステム（管理装置１１、精算装置３１）にて運用されている売価決定ロジック（売価決定ロジックＡ、Ｂ、Ｃ、Ｄ、Ｇ）が、クラウドサーバ２０が提供可能な売価決定ロジック（売価決定ロジックＡ、Ｂ、Ｃ）の範囲内にないため、クラウドサーバ２０によるセルフシステムの導入に際し、クラウドサーバ２０をクラウドサーバ２１に改修（外部連携機能を追加）し、管理装置１１を管理装置１２に改修（外部連携機能を追加）するが、比較的、導入時のコストを抑えることができる。精算装置の改修よりも、クラウドサーバや管理装置の改修の方が容易であると判断した場合に有効である。なお、図１３に示す例では、クラウドサーバ２１は、売価決定ロジック（売価決定ロジックＡ、Ｂ、Ｃ）を実装しているが、運用しない。
なお、クラウドサーバ２０を改修（外部連携機能を追加）してクラウドサーバ２１とすると説明したが、クラウドサーバ２０は、元々、外部連携機能を備えていてもよい。クラウドサーバ２０が外部連携機能を備えていれば、第３実施形態のショッピングシステムにおいて、クラウドサーバ２０の改修は不要となるため、一層、導入コストが削減する。
一般に、新規システムを導入する際の課題（障壁）は、導入のアプローチごとに以下のようなものが考えられる。
１．既存システムを改修して導入するアプローチの場合、既存システムにスマホ通信部やバスケット記憶部等の制御を追加するのが大変である（店舗に合わせ都度システムを作成しなければならない。つまり、店舗の数だけシステムを作る必要がある）。
２．一方、既存システムを残し、別システムとして立ち上げるアプローチの場合、既存システムと同様の売価決定ロジックを作成し、運用するのが大変（上記同様店舗の数だけ売価決定ロジックを作成する必要がある）。売価決定ロジックは、基本、顧客独自のノウハウや営業精神が蓄積されたものであると言えるため、導入先に応じて作業することは簡単ではない。
上記１、２は、いずれも店舗側・システム提案者側の両方に大きな負荷である。
これに対し、各実施形態にて説明したショッピングシステムでは、元々ある売価決定ロジックを利用するといった仕組みであるため、どの店舗であっても既存のシステムをそのまま残しながら（管理装置１０、１１、１２や精算装置３０、３１を稼働させつつ）、新規システムとの共存を図ることができ、上記１、２の問題をともに解決することができる。
以上、各実施形態について説明したが、更に、各実施形態について補足説明する。例えば、図１７に示した例では、精算装置４０上（客側表示部４０５、店員側表示部４１０）で商品キャンセルに関する警告を行っているが（図１７のステップＳ７９）、例えば、精算装置４０に代えて加えて、店員が携帯する店員用携帯端末に警告情報を送信することにより、店員用携帯端末上で商品キャンセルに関する警告を行ってもよいし、精算装置（精算装置３０、精算装置４０（４１））を監視する監視装置（不図示）に警告情報を送信することにより、監視携帯端末上で商品キャンセルに関する警告を行ってもよい。また、図１７に示した例では、精算装置４０（客側表示部４０５、店員側表示部４１０）上で保留商品に関する報知を行っているが（図１７のステップＳ８３）、例えば、精算装置４０に代えて加えて、上記店員用携帯端末に修正指示情報等を送信することにより、店員用携帯端末上で保留商品に関する報知を行ってもよいし、上記監視装置に修正指示情報等を送信し、上記監視装置上で保留商品に関する報知を行ってもよい。
なお、上記実施形態において、夫々の売価決定ロジックが参照する夫々の設定情報等は、商品情報とは別の情報であってもよいし、商品情報の一部であってもよい。例えば、図５に示したクラウドサーバ２０を一例に説明すると、クラウドサーバ２０は、商品情報とは別に、売価決定ロジックＡが参照する売価変更の情報、売価決定ロジックＢが参照する単品値引設定情報、売価決定ロジックＣが参照する小計値引設定情報を記憶してもよいし、クラウドサーバ２０が記憶する商品情報は、売価決定ロジックＡが参照する売価変更の情報、売価決定ロジックＢが参照する単品値引設定情報、売価決定ロジックＣが参照する小計値引設定情報を含む情報であってもよい。あるいは、売価決定ロジックＡに参照する売価変更の情報は当該売価決定ロジックＡに内在されていてもよい（売価決定ロジックＢ、Ｃについても同様である）。売価決定統括ロジックについても同様である。
なお、第３実施形態において、精算装置４１が売価決定ロジックＡ、Ｂ、Ｃ、Ｄ、Ｇを備えるが、商品情報を備えない。従って、商品情報内に売価決定ロジックが参照する設定情報が含まれている態様である場合（換言すれば、設定情報を売価決定ロジックに内在させる態様、又は、精算装置４１内に商品情報とは別個に設定情報を記憶する態様としない場合、つまり、精算装置４１が自装置内に設定情報を保持していない場合）には、精算装置４１は、小計金額を算出する際には（売価決定ロジックを使用する際には）、クラウドサーバ２０に記憶されている設定情報（商品情報内に含まれる設定情報、又は、商品情報とは別に記憶されている設定情報）を参照する。なお、精算装置４１は、小計金額を算出する際に、クラウドサーバ２０に記憶されている設定情報に代えて又は加えて、管理装置１１に記憶されている設定情報（商品情報内に含まれる設定情報、又は、商品情報とは別に記憶されている設定情報）を参照してもよい。なお、管理装置１１に記憶されている情報が、クラウドサーバ２０に記憶されている情報のよりも新しいような場合（バッチ処理によりクラウドサーバ２０側に情報が反映されるような場合）には、管理装置１１に記憶されている情報を参照してもよい。
また、上記実施形態では、商品登録の終了後の処理の流れは、携帯端末５０が表示したコードを精算装置４０（４１）が読み取るというものであったが、他の流れであってもよい。例えば、携帯端末５０によるクラウドサーバ２０（２０）への要求を起点（トリガー）として、小計金額の算出が開始されるような流れであってもよい。
例えば、第１実施形態では、携帯端末５０が精算処理を実行する精算装置４０の装置識別情報（精算装置番号）を取得し、携帯端末５０がバスケット識別情報、装置識別情報とともに、小計算出要求情報をクラウドサーバ２０に送信し、クラウドサーバ２０が自装置にて算出した小計金額を含む小計情報を装置識別情報によって識別される精算装置４０に送信してもよい。
第２実施形態では、携帯端末５０が精算処理を実行する精算装置４１の装置識別情報（精算装置番号）を取得し、携帯端末５０がバスケット識別情報、装置識別情報とともに、商品データ要求情報をクラウドサーバ２０に送信し、クラウドサーバ２０は、バスケット内の商品データを装置識別情報によって識別される精算装置４１に送信してもよい。
第３実施形態では、携帯端末５０が精算処理を実行する精算装置４０の装置識別情報（精算装置番号）を取得し、携帯端末５０がバスケット識別情報、装置識別情報とともに、小計算出要求情報をクラウドサーバ２１に送信し、クラウドサーバ２１が管理装置１１にて算出された小計金額を含む小計情報を装置識別情報によって識別される精算装置４０に送信してもよい。
なお、上記実施形態では、保留商品（読取ＮＧ）する場合に、すなわち、商品の読み取りが失敗した場合（タイムアウト処理となった場合）には、携帯端末５０は、自動的にシャッターを切って商品の撮像画像（画像データ）を取得する態様を説明したが（図１５のステップＳ４５）、保留商品（読取ＮＧ）する場合に、顧客のタイミングによって（顧客の操作に基づいて）シャッターを切らせる態様としてもよい。例えば、携帯端末５０は、商品の読み取りが失敗した場合（タイムアウト処理となった場合）に、顧客によるシャッター操作モードに切り替えるようにしてもよい。
なお、読取ＮＧの場合（後述する自己宣言商品の場合も同様）において顧客の操作に基づいてシャッターを切る態様とする場合には、顧客に対し撮像の操作を指示（例えば、登録画面上にメッセージ表示）してもよい。また、顧客の操作に基づいてシャッターが切られた場合（画像データを取得した場合）には、自動的にシャッターを切る態様と同様、自動的に画像データをクラウドサーバ２０（２１）に送信してもよいし、顧客の操作に基づいて画像データをクラウドサーバ２０（２１）に送信してもよい。
また、上記実施形態では、保留商品として、ＮＯＮ−ＰＬＵ、読取ＮＧの２種類を管理する例を説明したが、保留商品は上記２種類に限定されない。例えば、上記２種類以外の保留商品として自己宣言商品として管理してもよい。自己宣言商品とは顧客自身が宣言して保留商品としたものである。つまり、所定時間の撮像の末、タイムアウト処理が実行されれば読取ＮＧとなるが、仮にタイムアウト処理までに時間を要するような場合には、顧客は携帯端末５０を商品にかざし続けなければならない。このような状況においてタイムアウトを待てない場合には、顧客は、自らの判断により自分で保留商品を宣言してもよい。例えば、携帯端末５０の登録画面に保留宣言ボタンを配置し、保留宣言ボタンの操作（タッチ）により、バーコードの認識処理を一時停止して顧客によるシャッター操作モードに切り替えるようにしてもよい（実際にシャッターを切った場合にバーコードの認識処理を終了してもよい）。または、保留宣言ボタンの操作（タッチ）により、バーコードの認識処理を終了するとともにシャッターを切ってもよい。
上述のように、自己宣言商品の場合にも商品の撮像画像を取得するため（つまり撮像データを生成するため）、撮像データをクラウドサーバ２０（２１）に送信する。クラウドサーバ２０（２１）は、バスケット情報内に保留商品情報（例えば、保留商品区分：３（自己宣言）、画像データ）を記憶する。
保留商品（読取ＮＧ）の場合において、管理する画像データの枚数（データ数）は、２以上であってもよい。つまり、携帯端末５０では、ある商品のタイムアウト処理において当該商品の撮像画像を複数取得し（複数の画像データを生成し）、クラウドサーバ２０（２１）は、当該商品の画像データを複数記憶してもよい。保留商品（自己宣言）の場合についても同様である。なお、保留商品（自己宣言）の場合であって、顧客のタイミングにてシャッターを切らせる態様とするときには、顧客に撮像すべき枚数を報知（例えば、登録画面上に表示）してもよい。
また、精算装置４０（４１）は、２つのスキャナ部（客側スキャナ部４０６、店員側スキャナ部４１２）を備える装置であったが、また、精算装置４０（４１）が１つのスキャナ部（客側スキャナ部４０６）を備える装置であってもよい。精算装置３０についても同様である。また、精算装置４０（４１）は、精算処理に加えて登録処理も実行できる旨（例えば、カード決済部４０８や釣銭機４０９を備えることに加えて、客側スキャナ部４０６や店員側スキャナ部４１２が商品に付されているバーコードをスキャンする旨）を説明したが、登録処理は実行しない精算処理専用の装置（他の装置において登録処理された商品について精算処理を実行する精算処理専用の装置）であってもよい。精算装置３０についても同様である。
なお、顧客が商品をキャンセルした場合（キャンセル操作を行った場合）には、キャンセルした商品を棚（例えば元々の陳列位置）に戻す旨を報知（携帯端末５０の表示画面で報知）してもよい。つまり、キャンセルした場合に当該商品をクラウドサーバ２０（２１）のバスケットや携帯端末５０の表示において削除等するだけではなく、当該商品を元の棚に戻す旨を報知し、店舗の陳列秩序が維持されるように顧客に協力を要請する。実際の店舗では、何らかの理由で購入をやめた商品が本来とは異なる棚に放置されていることもあるため、このようなマナーの悪い利用客への警告として有効である。
なお、クラウドサーバ２０（２１）の情報（例えば、バスケット情報等）を電子レシートとして用いてもよい。例えば、クラウドサーバ２０（２１）は、電子レシート出力機能を備えていてもよい。これにより、顧客は、自身の利用履歴をクラウド上で確認したり、あるいは、携帯端末５０等にダウンロードして取引履歴として保存したりすることができるようになる。
クラウドサーバ２０（２１）は、送受信データ「Ｄ０（店舗情報、商品情報）」の送受信と同様の通信により、顧客の利用履歴を管理装置１０（１１、１２）へ送信してもよい。これにより、管理装置１０（１１、１２）は、既存システムで精算を終えた利用者だけでなく、セルフ登録システムを利用した顧客の利用履歴も合わせて保存、管理することが可能になる。例えば、セルフ登録システムによる取引を、従来の電子ジャーナルに統合させることもでき、従来と同様、検索の対象とすることができる。なお、利用履歴上でそれぞれの取引がどのように実施されたかを識別するための利用態様識別情報（単に、利用態様情報ともいう）により個々の取引の態様を管理してもよい。
［利用態様情報］
利用態様情報「１（通常）」：登録処理、精算処理ともに店員が対応した取引
利用態様情報「２（セミセルフ）」：登録処理を店員が対応し、精算処理を客自身で対応した取引
利用態様情報「３（フルセルフ）」：登録処理、精算処理ともに客が対応した取引（同一装置）
利用態様情報「４（スマホセルフ）」：登録処理、精算処理ともに客が対応した取引（別装置）
また、利用履歴（電子ジャーナル）を確認する際の表示画面や、店舗で印刷されるレシートにも上記利用態様が分かり易く表示してもよい。また、表示領域や印刷領域が小さい場合には、「通」、「セ」、「フ」、「ス」等の頭文字のみを出力してもよいし、更に小さい場合には、値（「１」〜「４」等）を表示してもよい。
以上のような工夫により、既存システム側でもセルフ登録システムの利用状況を把握できるため、従来の運用方法を変えることなく店舗状況（売上、在庫管理、利用履歴等の店舗に関する情報）を確認することができる。このような共存を少ない改修で実現できるため、どのような運用を実施している利用客に対しても、実施形態にて説明したシステムを提案することができる。
各種クラウドサーバ２０（２１）が携帯端末５０や精算装置４０の利用状況を監視しながら、能動的に売価決定ロジックによる小計金額の決定を行う場合がある。例えば、携帯端末５０で「お会計へ進む」が押下されたことをクラウドサーバ２０（２１）が検出した場合、売価決定ロジックが当該携帯端末５０の利用者のバスケット情報を特定し、先行して小計金額を決定することができる。あとは顧客がＱＲコードを読み取らせた精算装置４０へバスケット情報や小計金額を送信する。同様に、精算装置４０でＱＲコードを読み取り、その読取操作をクラウドサーバ２０（２１）が検出した場合も、能動的に売価決定ロジックにより小計金額を決定し、精算装置４０へ決定結果を送信することができる。このように、売価決定ロジックは精算装置からの依頼により実行される場合に限定されない。
携帯端末５０と精算装置４０との間でのバスケット識別情報のやり取りは、２次元コードに限定されず、バーコード、ＲＦＩＤやＮＦＣやＢｌｕｅｔｏｏｔｈによる無線通信、携帯端末５０または精算装置４０に用意されたコネクタを経由して携帯端末５０と精算装置４０との有線通信など方法は問わない。
商品登録を終えた顧客が精算装置４０を利用する際に、店舗が広大であったりいずれの精算装置も行列をなしている場合など、どの精算装置を利用すればよいか判断できない。このような状況の場合には、最も空いている、最も近い等の条件を考慮した最適な精算装置を案内する案内装置を別途設けてもよい。また、携帯端末５０に案内機能を設けている場合には、例えば「お会計へ進む」が押下されると精算装置選択画面が表示され任意の精算装置を予約できてもよい。
＜第４実施形態＞
続いて、第４実施形態について説明する。本実施形態のショッピングシステムは、図１に示されるものとなる。つまり、本実施形態のショッピングシステムは、精算装置４０、携帯端末５０、クラウドサーバ２０、及びクレジットカード決済サーバ６０を備える。なお、本実施形態においても精算装置３０が使用されてよいが、以下の説明では、説明を分かりやすくすることの便宜上、図１の態様から精算装置３０を省略したシステム構成である場合を例に挙げる。
また、本実施形態のショッピングシステムは、図５、図１１、図１３のいずれのショッピングシステムの機能構成にも対応可能であるが、以降の説明においては、図５のショッピングシステムの機能構成である場合を例に挙げる。
本実施形態との対応では、クラウドサーバ２０は、決済機能を備える。クラウドサーバ２０の決済機能は、例えばクレジットカード、電子マネー、プリペイドカード、ポイント残高利用による支払い、、支払金額を銀行口座から引き落とす決済等の、現金以外の決済種別（非現金決済種別）に対応する決済処理を行う。
本実施形態の精算装置４０は、店舗において備えられる。精算装置４０は、店舗の店員の操作に応じて、顧客の買上商品の登録（商品登録）に関連する処理と、商品登録処理により登録された商品についての精算とに関連する処理を実行する。
なお、以降の説明において、会計とは、一取引に対応する商品登録と精算とを含む。
また、本実施形態の携帯端末５０は、買い物のために店舗に赴いた顧客が所持する携帯型の端末である。携帯端末５０は、例えばスマートフォン、タブレット端末等である。このような携帯端末５０の表示部はタッチパネルとして構成される。
携帯端末５０には、商品登録アプリケーションがインストールされている。商品登録アプリケーションは、店舗での会計にあたり、顧客の操作に応じて商品登録が行われるようにされたアプリケーションである。
店舗においては、ビーコン端末ＢＴＭ（図１）が設置される。ビーコン端末ＢＴＭは、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に従った近距離無線通信により、通信距離内に位置して通信可能となった携帯端末５０に対してビーコン信号を送信する。
ビーコン端末ＢＴＭの通信距離は、店舗の施設に入場した顧客が所持する携帯端末５０と通信が行われるように、例えば数メートル〜十数メートル程度に設定される。
本実施形態においてビーコン端末ＢＴＭが送信するビーコン信号は、送信元のビーコン端末ＢＴＭを示すビーコン端末識別子を含む。携帯端末５０にインストールされている商品登録アプリケーションは、店舗に設置されたビーコン端末ＢＴＭを示すビーコン端末識別子を含むビーコン信号を受信すると、商品登録モードが設定されたうえで、フォアグラウンドで動作するアクティブ状態となる。
なお、ビーコン端末ＢＴＭと携帯端末５０との間で使用する近距離無線通信方式は、上記のＢｌｕｅｔｏｏｔｈに限定されるものではなく、例えばＺｉｇＢｅｅ（登録商標）、ＮＦＣ（Near Field Communication）などをはじめとして他の方式が採用されてよい。
なお、同図では、店舗において１つのビーコン端末ＢＴＭが示されているが、店舗に設置されるビーコン端末ＢＴＭの数は特に限定されない。
顧客による携帯端末５０に対する商品登録の操作（商品登録操作）は、例えば以下のようにして行われる。
顧客は、商品登録モードが設定されてアクティブ状態の携帯端末５０を手に持ち、携帯端末５０のコードスキャナ機能を利用して、自分の買上商品に付されたバーコード（二次元コードであってもよい）等のコード情報を読み取らせる操作を行う。このように読み取られたコード情報は、携帯端末５０にて記憶される。顧客は、全ての買上商品について登録する操作を終えると、商品登録の完了を指示する所定操作（商品登録完了操作）を携帯端末５０に対して行う。
このようにして本実施形態では、自分の所持する携帯端末５０に商品登録アプリケーションをインストールしている顧客は、自分の携帯端末５０に対する操作により商品登録を行うことができる。このように顧客により商品登録が行われることで、本実施形態では、店員が精算装置４０を操作して商品登録を行う必要がない。
クラウドサーバ２０は、例えば精算装置４０が設置される店舗に対応する店舗本部に設置される。クラウドサーバ２０は、店舗における取引の実績を管理する機能を有する。
また、精算にあたって、例えば非現金決済種別の１つであるクレジットカード（特定の決済種別の一例）による決済が行われる場合、精算装置４０または携帯端末５０からクラウドサーバ２０に対して非現金決済要求が送信される。非現金決済要求には、登録された商品に基づく決済情報と、クレジットカード番号とが含まれる。決済情報には、商品の登録結果が反映される。例えば決済情報には、登録された商品についての支払総額が含まれてよい。さらに、決済情報には、例えば登録された商品ごとの商品識別子、商品名、価格、個数等を示す商品登録情報が含まれてよい。
非現金決済要求を受信したクラウドサーバ２０は、クレジットカード決済サーバ６０との通信により、クレジットカード決済に対応する処理（クレジットカード決済対応処理）を実行する。
なお、クラウドサーバ２０は、例えば精算装置４０が備えられるのと同じ店舗において備えられてよい。あるいは、本実施形態のセルフ登録システムは、店舗本部の下位にて複数の店舗が管理されるような態様に対応していてもよい。この場合、店舗本部のクラウドサーバ２０は、複数の店舗に設定された精算装置４０や、複数の店舗のそれぞれにおいて顧客が所持する携帯端末５０と通信を行うようにされる。
次に、図１９を参照して、携帯端末５０の構成例について説明する。同図の携帯端末５０は、ＣＰＵ５０１、記憶部５０２、ＲＡＭ５０３、ネットワーク対応通信部５０４、近距離無線対応通信部５０５、タッチパネル付表示部５０６、操作部５０７、及び撮像部５０８を備える。
ＣＰＵ５０１は、プログラムを実行することにより、携帯端末５０における各種の処理を実現する。
記憶部５０２は、ＣＰＵ５０１の補助記憶装置であって、ＣＰＵ５０１に実行させるプログラムのほか、各種のデータを記憶する。
ＲＡＭ５０３は、ＣＰＵ５０１の主記憶装置である。
ネットワーク対応通信部５０４は、電話回線あるいは無線ＬＡＮ経由でネットワークに対応する通信を実行する。
近距離無線対応通信部５０５は、Ｂｌｕｅｔｏｏｔｈの規格に従った近距離無線通信を行う。即ち、近距離無線対応通信部５０５は、店舗に設置されたビーコン端末ＢＴＭから送信されるビーコン信号を受信することができる。
タッチパネル付表示部５０６は、タッチパネルが組み合わされた表示部である。
操作部５０７は、タッチパネル付表示部５０６以外であって、操作が行われるキー等を一括示す。
撮像部５０８は、撮像を行う。携帯端末５０は、撮像部５０８を利用したコード情報スキャン機能を有する。つまり、携帯端末５０は、コード情報スキャン機能として、撮像部５０８により撮像して得られた撮像画像においてコード情報が含まれていることを認識すると、撮像画像からコード情報を取得する。
次に、図２０を参照して、クラウドサーバ２０の構成例について説明する。同図のクラウドサーバ２０は、ＣＰＵ２０１、記憶部２０２、ＲＡＭ２０３、及び通信部２０４を備える。
ＣＰＵ２０１は、プログラムを実行することにより、クラウドサーバ２０における各種の処理を実現する。
記憶部２０２は、ＣＰＵ２０１の補助記憶装置であって、ＣＰＵ２０１に実行させるプログラムのほか、各種のデータを記憶する。
ＲＡＭ２０３は、ＣＰＵ２０１の主記憶装置である。
通信部２０４は、精算装置４０、携帯端末５０、及びクレジット会社等と通信を実行する。
なお、クラウドサーバ２０においても表示部、操作部等が設けられ、管理者が操作等を行えるようにされてもよい。
図２１のフローチャートを参照して、本実施形態の携帯端末５０とクラウドサーバ２０とが会計（商品登録、精算）に関連して実行する処理手順例について説明する。
まず、携帯端末５０が実行する処理手順例について説明する。
ステップＳ１００１：携帯端末５０は、店舗のビーコン端末ＢＴＭから送信される、商品登録アプリケーション対応のビーコン信号が受信されるのを待機している。ビーコン信号が商品登録アプリケーション対応であるか否かは、ビーコン信号に含まれるビーコン端末識別子が、店舗に設置されたビーコン端末ＢＴＭを示すものであるか否かによって判定される。
ステップＳ１００２：商品登録アプリケーション対応のビーコン信号が受信されると、携帯端末５０は、自己にインストールされている商品登録アプリケーションについて商品登録モードを設定したうえで起動させる。これにより、商品登録アプリケーションは、フォアグラウンドで動作するアクティブ状態とされたうえで、商品登録モードが設定された状態となる。
ステップＳ１００３：ステップＳ１００２により商品登録アプリケーションが商品登録モードで起動されたことに応じて、携帯端末５０は、取引識別子を要求する取引識別子要求をクラウドサーバ２０に送信する。ここでの取引識別子は、バスケット情報に対応するバスケット識別情報であってよい。
ステップＳ１００４：取引識別子要求に応じて、クラウドサーバ２０は取引識別子を送信してくる。携帯端末５０は、受信された取引識別子を取得する。このように取得された取引識別子は、今回のステップＳ１００２に応じて設定された商品登録モードによる商品登録に応じた取引を一意に示すものとなる。
ステップＳ１００５：ステップＳ１００２により商品登録モードが設定された状態のもとで、携帯端末５０は、１つの商品に応じた商品登録に関連する操作（商品登録関連操作）が行われたか否かについて判定する。商品登録関連操作には、以下のように、商品を登録する商品登録操作が含まれる。
例えば商品登録モードにおいては、コードスキャナ機能が有効とされている。そこで、顧客は、例えば自分の買上商品の全てを買い物カゴに容れ終えると、買い物カゴから１つずつ商品を取り出し、商品に付されているコード情報を、携帯端末５０の撮像部２０８により撮像させる。携帯端末５０は、コードスキャナ機能により、撮像画像においてコード情報が認識されると、商品登録操作が行われたと判定する。
なお、商品登録関連操作には、例えば商品の登録をキャンセルする操作等が含まれてよい。
ステップＳ１００６：商品登録関連操作が行われたと判定すると、携帯端末５０は、行われた商品登録関連操作に応じた処理（商品登録関連処理）を実行する。例えば、商品登録操作が行われた場合、携帯端末５０は、例えば商品登録処理として、コードスキャナ機能により認識したコード情報を撮像画像から取得し、例えばＲＡＭ２０３に記憶させる。
また、携帯端末５０は、ステップＳ１００６により実行された商品登録関連処理の結果が反映された商品登録関連処理情報を、クラウドサーバ２０に送信する。
ステップＳ１００７：ステップＳ１００５にて商品登録関連操作が行われなかったと判定された場合、あるいはステップＳ１００６の処理の後、携帯端末５０は、商品登録が完了したか否かについて判定する。
顧客は、例えば自分の買上商品の全てについて商品登録操作を終えると、商品登録完了操作を行う。商品登録完了操作が行われれば、ステップＳ１００７にて商品登録が完了したものと判定される。商品登録完了操作が行われず、商品登録が完了したものと判定されなかった場合には、ステップＳ１００５に処理が戻される。
ステップＳ１００８：商品登録完了操作が行われたことに応じて、ステップＳ１００７にて商品登録が完了したものと判定されると、携帯端末５０は、特定の非現金決済が許可されているか否かについて判定する。
本実施形態の商品登録アプリケーションでは、設定項目の１つとして、商品登録アプリケーションを利用して商品登録を行った取引について、非現金決済種別による決済の許可または禁止を選択することができる。
非現金決済として、一例としてクレジットカード決済の許可を設定するにあたっては、顧客は、クレジットカード番号等のクレジットカード決済に必要な情報（クレジットカード情報）を登録する操作を行う。このように登録されたクレジットカード情報は、例えば商品登録アプリケーションのみが参照可能なデータとして記憶部２０２に記憶されればよい。
なお、例えば登録された商品に保留商品が含まれている場合には、保留商品の対処が確定させなければ会計を終了させることができない。そこで、携帯端末５０は、登録された商品に保留商品が含まれている場合には、非現金決済を許可する設定であったとしても、当該ステップＳ１００８にて、非現金決済が許可されていないと判定してよい。
ステップＳ１００９：非現金決済が許可されている場合、携帯端末５０は、許可された非現金決済種別に応じた決済要求をクラウドサーバ２０に対して送信する。一例として、クレジットカード決済の場合、決済要求には、登録されたクレジットカード情報と、今回の商品登録の結果が反映された決済情報が含まれる。なお、ステップＳ１００９の処理は、今回の取引に対する決済に利用する決済種別として、予め許可された非現金決済種別を選択していることに相当する。
ステップＳ１０１０：クラウドサーバ２０は、非現金決済要求の受信に応じて、指定の非現金決済種別に対応する決済対応処理を実行し、決済が完了したことに応じて、携帯端末５０に対して決済完了通知を送信する。携帯端末５０は、送信された決済完了通知を受信する。
ステップＳ１０１１：ステップＳ１０１０の処理の後、あるいはステップＳ１００８にて非現金決済が許可されていない（禁止されている）と判定された場合、携帯端末５０は、以下の処理を実行する。
即ち、携帯端末５０は、今回の商品登録に応じた取引を示す取引コード情報（識別情報の一例）を生成する。このように生成される取引コード情報には、ステップＳ１００４にて取得された取引識別情報が含まれる。
また、ステップＳ１００８にて非現金決済が許可されていないと判定された場合、取引コード情報には、今回の取引に応じた商品登録処理の結果が反映された商品登録情報がさらに含まれてよい。また、ステップＳ１００９、Ｓ１０１０により非現金決済が行われた場合には、取引コード情報には、今回の取引に応じた商品登録情報に、非現金決済による精算結果とを反映させた取引実績情報がさらに含まれてよい。
ステップＳ１０１２：携帯端末５０は、ステップＳ１０１１により生成された取引コード情報を含み、顧客を精算装置４０に誘導するメッセージが示される精算装置誘導画面を、タッチパネル付表示部５０６に表示させる。
図２２（Ａ）は、ステップＳ１００９、Ｓ１０１０の処理を経た場合に、ステップＳ１０１２により表示される精算装置誘導画面の一態様例を示している。
同図においては、取引コード情報がＱＲコードにより表示されている。また、精算装置誘導画面には、紙媒体によるレシートの発行をしてもらいたい場合には、精算装置４０にまで赴いて、表示された取引コード情報を精算装置４０にて読み取らせるべき旨のメッセージが表示されている。
この場合の顧客は、紙媒体のレシートが必要である場合には、精算装置誘導画面を表示させた状態の携帯端末５０を持ち、精算装置４０に赴くようにされる。
一方、紙媒体のレシートが不要である場合、顧客は、同図の精算装置誘導画面に配置される「レシート不要」ボタンを操作する。「レシート不要」ボタンが操作されたことに応じて、精算装置誘導画面の表示が消去され、所定の画面に遷移する。この場合、顧客は、精算装置４０に赴くことなく、店舗を出ることもできる。
また、図２２（Ｂ）は、ステップＳ１００８にて非現金決済が許可されていないと判定されたうえで、ステップＳ１０１２により表示される精算装置誘導画面の一態様例を示している。
同図においても、取引コード情報がＱＲコードにより表示されている。また、精算装置誘導画面には、紙媒体によるレシートの発行をしてもらいたい場合には、客に向けて、精算装置４０にまで赴いて精算を行ってもらうべき旨と、表示された取引コード情報を精算装置４０にて読み取らせるべき旨のメッセージが表示されている。
再度、図２１を参照して、クラウドサーバ２０が実行する処理手順例について説明する。
ステップＳ２００１：クラウドサーバ２０は、ステップＳ１００３により携帯端末５０から送信された取引識別子要求が受信されたか否かについて判定する。
ステップＳ２００２：クラウドサーバ２０は、取引識別子要求が受信されると、例えば新規にバスケット情報を生成したうえで、生成されたバスケット情報に対応する取引識別子を、取引識別子要求の送信元の携帯端末５０に対して送信する。
ステップＳ２００３：ステップＳ２００１にて取引識別子要求が受信されなかったことが判定された場合、あるいはステップＳ２００２の処理の後、クラウドサーバ２０は、移管処理を実行する。つまり、クラウドサーバ２０は、携帯端末５０がステップＳ１００６による商品登録関連処理の結果が反映された商品登録関連処理情報が受信されたかについて判定する。
ステップＳ２００４：ステップＳ２００３にて商品登録関連処理情報が受信されたことが判定された場合、クラウドサーバ２０は、受信された商品登録関連処理情報の内容が反映されるように、今回の取引に対応する商品登録情報（バスケット情報）を更新する。
商品登録情報の更新にあたり、クラウドサーバ２０は、商品登録関連処理情報として商品コードが送信された場合には、受信された商品コードが商品情報に登録されているか否かについて判定する。商品コードが商品情報に登録されている場合、クラウドサーバ２０は、受信された商品コードに対応する登録商品情報を商品登録情報（バスケット情報）に追加する。また、商品コードが商品情報に登録されていない場合には、保留商品種別がＮＯＮ−ＰＬＵの保留商品情報を商品登録情報（バスケット情報）に追加する。
また、受信された商品登録関連処理情報が読取ＮＧに対応するものである場合、クラウドサーバ２０は、保留商品種別が読取ＮＧの保留商品情報を商品登録情報（バスケット情報）に追加する。
受信された商品登録関連処理情報が、一旦登録された商品のキャンセルを指示するものである場合には、キャンセル情報を商品登録情報（バスケット情報）に追加する。
ステップＳ２００５：ステップＳ２００４の処理の後、あるいはステップＳ２００３にて商品登録関連処理情報が受信されなかったと判定された場合、クラウドサーバ２０は、ステップＳ１００９により携帯端末５０から送信された決済要求が受信されたか否かについて判定する。決済要求が受信されないことが判定された場合には、ステップＳ２００１に処理が戻される。
ステップＳ２００６：ステップＳ２００５にて決済要求が受信されたと判定された場合、クラウドサーバ２０は、受信された決済要求に対応する決済対応処理を実行する。
具体例として、受信された決済要求が、非現金決済種別としてクレジットカード決済を指定するものである場合、クラウドサーバ２０は、今回の取引に対応する商品登録情報に基づく決済情報と、クレジットカード決済要求をクレジットカード決済サーバ６０に転送する。クレジットカード決済サーバ６０は、受信されたクレジットカード決済要求に含まれるクレジットカード情報と、自己が記憶するクレジットカード利用者ごとのクレジットカード情報とを照合し、利用可能なクレジットカードであるか否かの判定を行う。利用可能なクレジットカードであると判定されると、クレジットカード決済サーバ６０は、受信されたクレジットカード決済要求とともに受信された決済情報が示す支払総額についての決済を行う。クレジットカード決済サーバ６０は、決済が完了すると、決済が完了したことを示す決済完了通知をクラウドサーバ２０に送信する。クラウドサーバ２０は、決済完了通知の受信により、今回の決済対応処理が完了したことを認識する。
ステップＳ２００７：上記のように決済対応処理が完了したことに応じて、クラウドサーバ２０は、携帯端末５０に対して決済完了通知を送信する。
また、クラウドサーバ２０は、決済対応処理が完了したことに応じて、対応の商品登録情報（バスケット情報）の精算済フラグについて、精算済であることを示す値を格納する。
ステップＳ２００８：また、クラウドサーバ２０は、今回のステップＳ２００４により実行された決済対応処理に対応する取引の商品登録情報（バスケット情報）の精算済フラグについて、精算済であることを示す値を格納する。これにより、商品登録情報が、精算済みの取引に対応するものであることが示される。なお、商品登録情報は、クラウドサーバ２０における記憶部２０２にて記憶された状態で管理されればよい。
図２３のフローチャートを参照して、本実施形態の精算装置４０とクラウドサーバ２０とが精算に関連して実行する処理手順例について説明する。
まず、精算装置４０が実行する処理手順例について説明する。
ステップＳ３００１：図２１のステップＳ１０１２として示したように、携帯端末５０は、一取引に応じた商品登録が完了したことに応じて、非現金決済が行われた場合と、非現金決済が行われなかった場合とのそれぞれに対応して、取引コード情報を含む精算装置誘導画面をタッチパネル付表示部５０６に表示させる。
顧客は、携帯端末５０で非現金決済種別による決済が完了した場合には、紙媒体のレシートが必要であれば、精算装置誘導画面が表示された状態の携帯端末５０を持って、精算装置４０に赴くようにされる。また、顧客は、携帯端末５０で非現金決済種別による決済が行われなかった場合には、精算のために、精算装置誘導画面が表示された状態の携帯端末５０を持って、精算装置４０に赴くようにされる。
顧客が精算装置４０に赴いた際には、精算装置４０は待機状態となっている。待機状態において、精算装置４０は、客側表示部４０５に待機画面を表示する。
図２４は、待機画面の一態様例を示している。同図の待機画面においては、顧客に向けて、精算装置誘導画面にて表示されたＱＲコードを客側スキャナ部４０６により読み取らせる操作を行ってもらうことを案内する画像、メッセージが表示される。また、同図の待機画面においては、「もどる」ボタン、店員呼出ボタン、及び残高照会ボタン、言語切替ボタン等が配置されている。
「もどる」ボタンが操作された場合には、所定の画面に表示が戻るように遷移する。
店員呼出ボタンが操作された場合には、所定の態様により店員を呼び出す（店員に精算装置４０にまで来てもらう）ための報知が店舗にて行われる。
残高照会ボタンは、例えば顧客が電子マネーカードの残高照会をしようとする際に操作するボタンである。
言語切替ボタンは、精算装置４０にて表示される各種操作画面において表示されたり、音声により出力されたりするメッセージの言語を指定する操作が行われるボタンである。
例えば上記のように待機画面が表示された状態の精算装置４０に赴いた顧客は、例えば客側スキャナ部４０６を操作して、客側スキャナ部４０６により、提示された取引コード情報を読み取らせる操作を行う。このようにして客側スキャナ部４０６によりコード情報が読み取られたことに応じて、精算装置４０は、取引コード情報を取得する。精算装置４０は、客側スキャナ部４０６により読み取られたコード情報が取引コード情報であることについて、取引コード情報が有する固有の識別子に基づいて認識できる。
ステップＳ３００２：ステップＳ３００１により取引コード情報が読み取られたことに応じて、精算装置４０は、商品登録情報要求をクラウドサーバ２０に送信する。
ここでの商品登録情報要求は、ステップＳ３００１により読み取られた取引コード情報が示す取引に対応する商品登録情報（バスケット情報）を要求するコマンドである。商品登録情報要求には、ステップＳ３００１にて取得された取引コード情報における取引識別子が含まれている。
ステップＳ３００３：クラウドサーバ２０は、商品登録情報要求の受信に応答して、対象取引に対応する商品登録情報を精算装置４０に送信する。精算装置４０は、商品登録情報の受信に応じて、対象取引が精算済みであるか否かについて判定する。
このために、精算装置４０は、商品登録情報に格納される精算済みフラグの値が精算済であることを示しているか否かについて判定する。精算済みフラグの値が精算済みであることを示している場合、精算装置４０は、対象取引について精算済みであると判定する。一方、精算済みフラグの値が精算済みでないことを示している場合、精算装置４０は、対象取引について精算済みではないと判定する。
ステップＳ３００４：ステップＳ３００３にて対象取引は精算済ではないと判定された場合には、精算装置４０にて精算を済ませる必要がある。そこで、精算装置４０は、対象取引についての精算処理を実行する。ステップＳ３００４の処理として、例えば精算装置４０は、タッチパネルである客側表示部４０５に精算画面を表示させる。精算画面は、精算装置４０が精算処理を行うにあたって、顧客に向けて、精算に関する情報を提示したり、精算に関する操作の案内をしたり、精算に関する操作を受け付けるために表示される画面である。
精算画面としては、例えばまず、決済種別を選択する操作が行われる決済種別選択画面が表示される。決済種別選択画面においては、例えば現金による決済、クレジットカードによる決済、電子マネーによる決済、ポイント利用による決済等の所定の決済種別が選択肢として提示される。顧客は提示された選択肢のうちから、自分が利用する決済種別を選択する操作を行う。精算装置４０は、選択された決済種別に対応する精算処理を実行する。
また、例えば決済種別が選択された後における精算画面では、受信された商品登録情報に基づいて提示される、登録された商品のリスト（商品リスト）が含まれる。商品リストにおける商品は、登録された順に提示されてよい。
そのうえで、商品リストにおける商品の提示順は、例えば価格の高い順に従ってソート可能なようにされてもよい。登録された商品に関しては価格順に並べられることで把握がしやすくなるという側面がある。
店員は、精算画面において表示される商品リストを見ることで、客が登録した商品を把握することができる。そのうえで、例えば商品リストが価格順に従って提示できるようにすれば、店員としては登録された商品をさらに把握しやすくなる。
また、客は、必要に応じて、商品リストにて提示される商品と、客が買い物カゴ等に容れている商品とを照らし合わせることで、商品登録結果に間違いがないかどうかを確認できる。
店員は、商品リストにて提示された商品に間違いのないことを確認すると、顧客の申し出た決済種別による決済を伴う精算が行われるように精算装置４０を操作し、精算装置４０に精算処理を実行させる。本実施形態の精算装置４０が精算処理を行うにあたり対応可能な決済種別としては、現金、クレジットカード、商品券、プリペイドカード、ポイントカードのポイント残高利用等を挙げることができる。例えば携帯端末５０にて商品登録を行う客であっても、クレジットカードの利用により精算を行うにあたり、携帯端末５０の商品登録アプリケーションでのクレジットカード決済は禁止に設定しておき、精算装置４０にて行いたいという場合がある。このような場合であっても、本実施形態の場合であれば、携帯端末５０により商品を登録した取引であっても、精算装置４０にてクレジットカード決済を行うことができる。
また、当該ステップＳ３００４による精算処理が完了するタイミングで、精算装置４０は、精算処理結果が反映されたレシートを印字部１９により発行させる。店員は発行されたレシートを顧客に渡す。
ステップＳ３００５：精算装置４０は、ステップＳ３００４による精算処理が完了されると、対象の取引の精算処理結果が反映された精算処理結果情報をクラウドサーバ２０に送信する。
ステップＳ３００６：ステップＳ３００３にて対象取引が精算済みであることが判定された場合、精算装置４０は、対象取引に対応して携帯端末５０の商品登録アプリケーション経由で行われた非現金決済の結果が反映されたレシートを発行する。
レシートの発行にあたり、精算装置４０は、受信された商品登録情報において示される商品登録処理の結果やクレジットカード決済の結果を利用して、レシートに印刷を行う。このように発行されるレシートには、購入された商品ごとの情報（名称、価格、購入個数等）と、購入された商品の合計金額と、合計金額に対する精算がクレジットカード決済により行われたこと等が示される。
次に、クラウドサーバ２０が実行する処理手順例について説明する。
ステップＳ４００１：クラウドサーバ２０は、ステップＳ３００２により精算装置４０から送信される商品登録情報要求が受信されたか否かについて判定する。
ステップＳ４００２：商品登録情報要求が受信されると、クラウドサーバ２０は、受信された取引照会要求に含まれるのと同じ取引識別子が対応付けられた商品登録情報を記憶部２０２から検索する。
ステップＳ４００３：クラウドサーバ２０は、ステップＳ４００２により検索された商品登録情報を、精算装置４０に対して送信する。
ステップＳ４００４：ステップＳ４００１にて取引照会要求が受信されないと判定された場合、あるいはステップＳ４００３の処理の後、クラウドサーバ２０は、以下の処理を実行する。つまり、クラウドサーバ２０は、ステップＳ３００５により精算装置４０から送信される精算処理結果情報が受信されたか否かについて判定する。
精算処理結果情報が受信されない場合、ステップＳ４００１に処理が戻される。
ステップＳ４００５：精算処理結果情報が受信されると、クラウドサーバ２０は、記憶部２０２に記憶されている、ステップＳ４００３にて検索されたのと同じ商品登録情報の精算済フラグについて、精算済みであることを示す値を設定する。
以上説明したように、本実施形態においては、商品登録アプリケーションが動作する携帯端末５０を顧客が操作して商品登録を行うことができる。これにより、店舗にて買い物をする顧客のうちの少なくとも一部は、精算装置４０にて買上商品についての商品登録処理を行ってもらう必要がなくなる。
そのうえで、商品登録アプリケーションにおいて、クレジットカード決済等の非現金決済の許可を設定した場合には、商品登録の完了に応じて、精算装置４０にて精算を受けなくとも、商品登録アプリケーション経由で非現金決済を行うことができる。
これにより、商品登録アプリケーションが動作する携帯端末５０を使用して商品登録を行った顧客のうちの少なくとも一部は、精算装置４０にて精算処理を行ってもらう必要が無く、例えば顧客の都合でレシートの発行を受けるだけでよい。即ち、本実施形態においては、一取引の会計において、商品登録だけでなく、精算についても精算装置４０にて行う必要のない場合がある。
これにより、本実施形態においては、１顧客が精算装置４０にて会計を受ける時間がさらに短縮されることになり、会計の効率の改善が図られる。
ここで、図２３のステップＳ３００３以降の処理のもとで精算装置４０にて表示される画面について説明する。
まず、ステップＳ３００６によりレシートを発行する際、精算装置４０は、精算済（精算終了）であることに応じた精算終了画面を客側表示部４０５に表示させる。
図２５は、精算終了画面の一例を示している。同図の精算終了画面においては、顧客に向けて、精算が終了していることが確認済みであることと、レシート（及び領収書）の発行を受けるために「おわり」ボタン（または「領収書あり」ボタンを操作してもらうことを案内するメッセージが表示される。また、精算により支払いが確認された金額（この場合には１８０２０円）と、今回の精算に利用された決済種別（この場合にはクレジットカード決済）が示される。
同図の態様による精算終了画面の場合、レシート等は、顧客が、「おわり」ボタン（または「領収書あり」ボタンに対する操作を行うことに応じて発行される。即ち、レシートは、顧客がレシート等の発行を指示する操作を行うことに応じて発行されるようにされている。
しかしながら、特に顧客がレシート等の発行を指示する操作を行わなくとも精算装置４０がレシートを発行するようにしてよい。この場合、精算終了画面においては、レシート等が発行されるので、レシートを受け取るようにしてもらうことを案内するメッセージが表示されるようにしてよい。
また、前述のように、ステップＳ３００４の処理のもとで登録された商品のリスト（商品リスト）を含む精算画面が表示される。
図２６は、商品リストを含む精算画面（商品リスト画面）として、登録された商品のうちに保留商品が含まれていた場合の商品リスト画面の一態様例を示している。
保留商品は、店員が応対して所定の処置を行う必要がある。このため、保留商品を含む商品リスト画面の表示が開始される際には、精算装置４０により店員呼び出し制御が実行される。店員呼び出し制御は、例えば精算装置４０にまで赴くことを店員に指示するアナウンスが音声により行われるようにする制御であってよい。また店員呼び出し制御は、店員が所持する端末に精算装置４０にまで赴くことを指示するメッセージが報知されるようにする制御であってよい。また、店員呼び出し制御は、管理装置１０にて表示、音声等により、精算装置４０にまで赴くことを店員に指示するメッセージ等が出力されるようにしてよい。
この際、例えば、同図の商品リスト画面に重畳するようして、呼び出しに応じて店員が到着するまで商品リスト画面の内容を確認しながら待ってもらうよう顧客に案内する画面（例えば、ダイアログウィンドウやポップアップ画面）が表示されるようにしてよい。
同図の商品リスト画面における商品のリスト項目の配列順は、まず、左側の上から下にかけていき、次に、右の上から下にかけていくものとなる。
同図においては、商品のリスト項目の配列順に従って、まず、６つの保留商品のリスト項目が配列される。保留商品のリスト項目においては、左端に保留商品の種別を示す見出しが付されている。同図では、保留商品の種別として、「年齢確認」、「防犯タグ」、「医薬品」、「保留商品」、「取消商品」が示されている。
「年齢確認」の見出しは、保留商品として、例えばアルコール飲料やたばこ等のように、購入にあたり年齢確認が必要な商品を示す。
「防犯タグ」の見出しは、保留商品として、防犯用のタグが取り付けられた商品で有ることを示す。
「医薬品」の見出しは、保留商品として、薬剤師による販売が条件となる第１類医薬品としての商品であることを示す。
「保留商品」の見出しは、保留商品として、ＮＯＮ−ＰＬＵとして登録された商品、もしくは商品登録に際して正常にコードの読み取りが行われなかった商品であることを示す。正常にコードの読み取りが行われなかった商品については、悪意のある顧客が、携帯端末５０により商品登録のためのコードの読み取りの操作を行ったふりをしただけで、実際にはコードを携帯端末５０に読み取らせていないものが含まれる可能性がある。
「取消商品」の見出しは、保留商品として、一旦登録されたが、その後において、顧客の操作によってキャンセル（購入数量を減らした場合も含まれる）された商品であることを示す。
保留商品のリスト項目に続いては、保留商品以外の商品のリスト項目が、予め定められた金額区分に応じて配置される。同図では、金額区分について、同図において配置される商品分類ボタンＢＴ１（ＢＴ１−１〜ＢＴ１−５）のうち、商品分類ボタンＢＴ１−１〜ＢＴ１−４において示されるように４つに区分して設定された例が示されている。
商品分類ボタンＢＴ１−１は、１０００円以上の金額の商品に対応する。商品分類ボタンＢＴ１−２は、５００円から９９９円の金額の商品に対応する。商品分類ボタンＢＴ１−３は、３００円〜４９９円の金額の商品に対応する。商品分類ボタンＢＴ１−４は、２９９円以下の金額の商品に対応する。また、商品分類ボタンＢＴ１−５は、保留商品に対応する。
保留商品のリスト項目に続いては、３つのリスト項目により、１０００円以上の金額の商品が示されている。１０００円以上の金額の商品のリスト項目に続いては、５つのリスト項目により、５００円から９９９円の金額の商品が示されている。５００円から９９９円の金額の商品のリスト項目に続いては、６つのリスト項目により、３００円〜４９９円の金額の商品が示されている。さらに、３００円〜４９９円の金額の商品のリスト項目に続いては、４つの２９９円以下の金額の商品が示されている。
同図においては、最大で２４個の商品のリスト項目が配置可能とされている。登録された商品の数が２４よりも多い場合には、商品のリスト項目が配置されたシートの右上に配置される、「２」が表示されたタブに対してタップ操作を行うことで、続きの商品のリスト項目が配置された、２枚目のシートの表示に切り替わる。
また、同図の商品リスト画面において配置される商品分類ボタンＢＴ１が操作されることに応じては、操作された商品分類ボタンＢＴ１に対応する商品分類に該当する商品のリスト項目が、他の商品のリスト項目に対して強調されるように表示される。一例として、他の商品のリスト項目についてはグレーアウトとすることで、相対的に操作された商品分類ボタンＢＴ１に対応する商品分類に該当する商品のリスト項目が強調して表示されるようにしてよい。
例えば、商品リスト画面においては、商品ごとのリスト項目が、保留商品と、保留商品以外の商品とで区分されるようにして配列される。さらに、保留商品以外の商品については、金額区分ごとに配列される。これにより、店員は、まず、保留商品を容易に特定して応対することができる。また、例えば不正が行われる場合には、高額の商品が不正の対象となりやすいが、同図の商品リスト画面の態様であれば、予め定められた金額区分に従って商品が価格帯ごとにまとまって表示されることから、店員は高額商品のみに注目して、例えば不正がないかどうかを判断することもできる。
例えば、特に不正が行われていなかったうえで、店員が保留商品についての処理を適正に行った場合、客側表示部４０５においては例えば以降の顧客による精算に応じた画面が表示される。一例として、例えば、同図の商品リスト画面が表示されたうえで、商品リスト画面の所定の位置にて、以降の精算を指示するボタン（精算開始ボタン）が新たに配置されるようにしてよい。
ここで、商品リスト画面に表示された保留商品への応対処理の一例として、ＮＯＮ−ＰＬＵとして登録された１つの保留商品について、金額、商品名、小分類等を設定して精算対象に含めるための操作（保留商品消し込み操作）について説明する。
店員呼出を受けて精算装置４０に赴いた店員は、表示されている商品リスト画面におけるリスト項目のうちから、消し込み対象の保留商品のリスト項目に対するタップ操作を行う。
保留商品のリスト項目に対するタップ操作が行われたことに応じて、例えば商品リスト画面上に重畳するようにして、店員に向けて店員証の読み取りを案内するダイアログウィンドウが表示される。そこで、店員は、自分の店員証に付されたコードを、客側スキャナ部４０６または店員側スキャナ部４１２により読み取らせる操作を行う。これにより、精算装置４０は、店員識別子を取得し、取得された店員識別子が正統なものであるか否かの認証処理を行い、認証が成立したのであれば、消し込み操作のための消し込み操作画面を、商品リスト画面上に重畳させるようにして表示する。
ＮＯＮ−ＰＬＵの保留商品は、商品に付されていたバーコードについては正常に読み取りが行われているが、バーコードが示す商品に対して、金額、商品名、小分類（例えば、野菜、肉類、魚類、総菜、菓子、雑貨等の分類）等が対応付けられていない状態の商品である。
そこで、店員は、消し込み操作画面に対して、商品の金額と、商品の商品名と、商品の小分類とを入力する操作を行う。消し込み操作画面においては、金額、商品名、小分類の入力のためのキーボードが配置されてよい。
また、必要に応じて、金額、商品名、小分類以外の他の所定の情報も登録する操作が消し込み操作画面に対して行えるようにされてよい。
店員は、金額、商品名、小分類等の所定の情報の入力を完了させると、入力内容についての確定操作（例えば、消し込み操作画面に配置される確定ボタンに対する操作）を行う。確定操作に応じて、精算装置４０は、対象の商品についての保留状態を解除し、精算対象の商品とするように商品登録情報を変更する。
なお、保留商品の消し込みにあたっては、例えば少なくとも金額が入力されたのであれば、商品名、小分類等の他の情報が入力されていなくとも、保留状態が解消されるようにしてよい。
また、消し込み操作画面に対して行われたＮＯＮ−ＰＬＵの商品についての金額、商品名、小分類等の入力内容は、商品マスタに対する商品の本登録の内容として処理されてもよいし、仮登録の内容とされて、後の或る機会において本登録の処理が行われるようにされてもよい。
また、消し込み操作画面において、例えば「画像確認」を指示する操作が可能なようにして、「画像確認」を指示する操作が行われた場合には、例えばスマートフォン等の携帯端末により撮像された保留対象の商品の画像が表示されるようにしてよい。これにより、対象の商品がどのようなものであるのかについて、店員が容易に確認できる。
また、図２７は保留商品を含む商品リスト画面の他の態様例を示している。同図の商品リスト画面は、縦長の形式である。例えば商品リスト画面が表示される客側表示部４０５等の表示面は縦長の形式であってもよい。同図の商品リスト画面は、例えば、表示面が縦長である場合に好適なものとなる。
また、同図の商品リスト画面では、保留商品の消し込み等の保留商品応対操作にあたり、保留商品に対応の商品分類ボタンＢＴ１−５が操作された場合の態様が示されている。
つまり、保留商品に対応の商品分類ボタンＢＴ１−５が操作されたことによっては、同図のように保留商品のリスト項目がリスト項目の配列における下側にまとまって配置されるように、リスト項目の並び替え（ソート）が行われたうえで、強調表示される。なお、保留商品のリスト項目は、例えば同図の商品リスト画面の表示が開始されたときから、リスト項目の配列における下側に配置されていてもよい。
このように商品リスト画面が縦長である場合に、例えば図２６の態様に準じて保留商品が上側から配列されるような態様であると、保留商品の消し込み等の応対操作に際して、例えば身長の低い小柄な店員の場合には、保留商品のリスト項目にまで手が届きにくく、操作がしづらかったり、操作に疲れてしまったりする可能性がある。そこで、同図のように保留商品のリスト項目については下側に配置することで、小柄な店員でも保留商品の消し込み操作等を行いやすくなり、操作の負担が軽減される。
さらに同図では、金額区分に対応する商品分類ボタンＢＴ１−１〜ＢＴ１−４については、商品リスト画面の上側に配置しているのに対して、保留商品に対応する商品分類ボタンＢＴ１−５については商品リスト画面の右下に配置している。このような配置によっても、小柄な店員による保留商品に関する応対の操作が行いやすいように配慮されている。また、このような配置であれば、保留商品に対応する商品分類ボタンＢＴ１−５を操作しようとして、隣接の金額区分に対応する商品分類ボタンＢＴ１−１〜ＢＴ１−４等を誤ってタップしてしまうといった操作を防ぐこともできる。
また、保留商品に対応する応対操作が行われる際に、商品リスト画面上に重畳して表示される消し込み操作画面等についても、商品リスト画面における下側に位置するように表示されるようにすることで、さらに操作の負担軽減を図ることが可能になる。
＜第５実施形態＞
続いて、第５実施形態について説明する。先の第４実施形態においては、携帯端末５０により予め許可された非現金決済種別による決済が行われない場合には、精算装置４０にて顧客が利用する決済種別が選択されるようにされていた。
これに対して、本実施形態においては、携帯端末５０に対する操作により顧客が決済種別を選択可能なようにされる。
図２８のフローチャートを参照して、本実施形態の携帯端末５０とクラウドサーバ２０とが会計（商品登録、精算）に関連して実行する処理手順例について説明する。
先ず、携帯端末５０の処理手順例について説明する。第３実施形態においては、携帯端末５０にて許可される非現金決済種別が設定されていたが、本実施形態においては、説明を分かりやすくすることの便宜上、携帯端末５０にて許可される非現金決済種別については設定されていない場合を例に挙げる。
まず、携帯端末５０が実行する処理として、ステップＳ１１０１〜Ｓ１１０７の処理は、図２１のステップＳ１００１〜Ｓ１００７と同様であることから、ここでの説明は省略する。
ステップＳ１１０８：ステップＳ１１０７にて商品登録の完了したことが判定されると、携帯端末５０は、タッチパネル付表示部５０６に、決済種別選択画面を表示させる。
図２９（Ａ）は、決済種別選択画面の一態様例を示している。同図の決済種別選択画面においては、決済種別として、現金、クレジットカード、電子マネー等に対応するボタンが配置されている。顧客は、配置されたボタンのうちから、自分が利用する決済種別に対応するボタンをタップする操作を行えばよい。
ステップＳ１１０９：決済種別選択画面に対して決済種別を選択する操作が行われたことに応じて、携帯端末５０は、選択された決済種別が、携帯端末５０にて精算が可能な非現金決済種別であるか否かについて判定する。
ステップＳ１１１０：ステップＳ１１０９により携帯端末５０にて非現金決済種別が選択されたことが判定された場合、携帯端末５０は、精算装置４０にて精算を行うことなく携帯端末５０にて決済が可能であるか否かについて判定する。
このため、携帯端末５０は、決済可否問合せを、クラウドサーバ２０に対して送信する。決済可否問合せは、ステップＳ１１０４により取得した取引識別子が示す取引について決済が可能であるか否かをクラウドサーバ２０に問い合わせるコマンドである。
クラウドサーバ２０は、決済可否問合せの受信に応じて、該当の取引に対応する商品登録情報を参照して、携帯端末５０にて決済が可能であるか否かについて判定する。
この場合において、クラウドサーバ２０は、携帯端末５０にて決済が可能であるか否かの判定として、商品登録情報において、保留商品の登録が含まれているか否かについて判定する。保留商品の登録が含まれている場合、クラウドサーバ２０は、携帯端末５０にて決済が不可であると判定する。
保留商品として、ＮＯＮ−ＰＬＵ（ＮＯ−ＦＩＬＥ）の商品が登録されている場合には、商品から読み取られた商品コードが何の商品に対応するものであるのかを、店員が確認して処理する必要がある。また、保留商品として、読取ＮＧの商品が登録されている場合には、商品コードの読み取りがエラーとなっていることに顧客が気付いていない可能性、もしくは顧客により不正が行われた可能性がある。このような場合にも、店員が対応して処理する必要がある。
また、クラウドサーバ２０は、携帯端末５０にて決済が可能であるか否かの判定として、一旦登録された商品をキャンセルする操作（登録商品キャンセル操作）が行われた回数が、予め定められた閾値以上であるか否かについて判定する。登録商品キャンセル操作の回数が閾値以上である場合、クラウドサーバ２０は、携帯端末５０にて決済が不可であると判定する。
登録商品キャンセル操作の回数が閾値以上である場合、例えば顧客が携帯端末５０の操作に不慣れである可能性があるため、商品登録情報が示す登録内容と、実際に顧客が購入しようとする商品の内訳とで相違している可能性がある。あるいは、登録商品キャンセル操作の回数が閾値以上である場合、顧客が不正を行っている可能性がある。このため、登録商品キャンセル操作の回数が閾値以上である場合には、店員が対応して処理する必要がある。
一方、商品登録情報の内容について、保留商品が登録されておらず、かつ、登録商品キャンセル操作の回数の閾値未満である場合、クラウドサーバ２０は、決済可能であると判定する。
クラウドサーバ２０は、上記のように決済可否について判定すると、判定結果を示す決済可否通知を携帯端末５０に送信する。決済不可の判定結果を示す場合、決済可否通知には、決済不可の理由が含まれる。決済不可の理由としては、保留商品の登録と、登録商品キャンセル操作回数が閾値以上であったこととの少なくともいずれか一方が示される。
携帯端末５０は、受信された決済可否通知が、決済可能と決済不可とのいずれを示しているのかにより、決済が可能か否かを判定する。
ステップＳ１１１１：ステップＳ１１１０にて決済可能であると判定された場合、携帯端末５０は、今回選択された非現金決済種別に応じた非現金決済要求をクラウドサーバ２０に対して送信する。
ステップＳ１１１２：クラウドサーバ２０は、非現金決済要求の受信に応じて、指定の非現金決済種別に対応する決済対応処理を実行し、非現金決済が完了したことに応じて、携帯端末５０に対して決済完了通知を送信する。携帯端末５０は、送信された決済完了通知を受信する。
ステップＳ１１１３：ステップＳ１１１０にて決済不可であると判定された場合、携帯端末５０は、タッチパネル付表示部５０６において、店員呼出案内画面の表示を行う。図２９（Ｂ）、図２９（Ｃ）は、それぞれ、店員呼出案内画面の態様例を示している。図２９（Ｂ）は、決済不可の理由が保留商品の登録であった場合の店員呼出案内画面の例である。図２９（Ｃ）は、決済不可の理由がキャンセル操作回数が閾値以上であった場合の店員呼出案内画面の例である。
図２９（Ｂ）、図２９（Ｃ）の店員呼出案内表示においては、それぞれに対応する決済不可の理由とともに、店員を呼び出すにあたり、客に精算装置４０にまで赴いてもらうように案内するメッセージが示される。このような店員呼出案内表示は、顧客に対して、携帯端末５０による非現金決済（第１精算手段での精算）が不可であることを報知していることに相当する。
携帯端末５０は、ステップＳ１１１０にて受信された、決済不可を示す決済可否通知において示される決済不可の理由に応じて、図２９（Ｂ）、図２９（Ｃ）のうちいずれの店員呼出案内画面を表示すべきかを判定する。
店員呼出案内画面が表示された場合、顧客は、精算装置４０にまで赴いて、店員を呼び出す。店員の呼び出しは、例えば精算装置４０に対する操作によって行われるようにされてよい。客は、呼び出された店員により、例えば保留商品についての対応や、登録された商品と、買い物カゴに入っている商品との一致の確認等をしてもらったうえで、精算装置４０にて精算を行えばよい。
ステップＳ１１１４：ステップＳ１１１２の処理の後、あるいはステップＳ１１０９にて現金による決済が選択されたことが判定された場合、携帯端末５０は、今回の商品登録に応じた取引を示す取引コード情報を生成する。
ステップＳ１１１５：携帯端末５０は、ステップＳ１１１４により生成された取引コード情報を含み、顧客を精算装置４０に誘導するメッセージが示される精算装置誘導画面を、タッチパネル付表示部５０６に表示させる。携帯端末５０は、ステップＳ１１１１、Ｓ１１１２を経てステップＳ１１１５に至った場合には、図２２（Ａ）の精算装置誘導画面を表示させる。一方、携帯端末５０は、ステップＳ１１０９にて現金による決済が選択されたことが判定されたうえでステップＳ１１１５に至った場合には、図２２（Ｂ）の精算装置誘導画面を表示させる。
次に、同図を参照して、クラウドサーバあら２０が実行する処理手順例について説明する。ステップＳ２１０１〜Ｓ２１０４の処理は、図２１のステップＳ２００１〜Ｓ２００４と同様であることから、ここでの説明は省略する。
ステップＳ２１０５：ステップＳ２００３にて商品登録可憐処理情報が受信されなかったことが判定された場合、もしくはステップＳ２１０４の処理の後、クラウドサーバ２０は、ステップＳ１１１０により携帯端末４０から送信される決済可否問合せが受信されたか否かについて判定する。決済可否問合せが受信されないことが判定された場合には、ステップＳ２００１に処理が戻される。
ステップＳ２１０６：ステップＳ２１０５にて決済可否問合せが受信されたことが判定された場合、クラウドサーバ２０は、対応の取引について、携帯端末４０にて決済が可能であるか否かについて判定する。この際、携帯端末４０は、前述のように、対応の取引の商品登録情報を参照して、保留商品が登録されておらず、かつ、登録商品キャンセル操作の回数の閾値未満であるとの条件が満たされるか否かについて判定する。
ステップＳ２１０７：クラウドサーバ２０は、ステップＳ２１０６による決済可否についての判定結果を示す決済可否通知を携帯端末５０に送信する。前述のように、決済不可の判定結果を示す場合、クラウドサーバ２０は、決済可否通知に、決済不可の理由（保留商品の登録と、登録商品キャンセル操作回数が閾値以上であったこととの少なくともいずれか一方）を含める。
ステップＳ２１０８：ステップＳ２１０７の処理の後、クラウドサーバ２０は、ステップＳ１１１１により携帯端末４０から送信される非現金決済要求が受信されたか否かについて判定する。非現金決済要求が受信されないことが判定された場合、ステップＳ２１０１に処理が戻される。
ステップＳ２１０９：クラウドサーバ２０は、ステップＳ２１０８により非現金決済要求が受信されたことを判定すると、非現金決済要求により指定される非現金決済種別に対応する決済対応処理を実行する。この際、クラウドサーバ２０は、指定される非現金決済種別等に応じて、適宜、外部の決済サーバ（例えば、非現金決済種別がクレジットカード利用である場合には、クレジットカード会社が運用するクレジットカード決済用のサーバ）と通信を行ってよい。
ステップＳ２１１０：クラウドサーバ２０は、ステップＳ２１０９による非現金決済が完了したことに応じて、携帯端末５０に対して決済完了通知を送信する。
ステップＳ２１１１：クラウドサーバ２０は、今回の非現金決済が完了した取引に対応する商品登録情報に対して、精算済であることを示す精算済フラグを設定する。
＜変形例＞
以下、第４実施形態及び第５実施形態の変形例について説明する。
［第１変形例］
なお、図２８のフローチャートに示されるステップＳ１１１０、Ｓ１１１３による処理は、第４実施形態にも適用されてよい。つまり、第４実施形態において、携帯端末５０は、ステップＳ１１０８にて特定の非現金決済種別による決済が許可されていると判定された場合に、さらにステップＳ１１１０により、商品登録情報の内容に基づき決済が可能であるか否かについて判定する。ステップＳ１１１０により決済不可であると判定されれば、携帯端末５０は、ステップＳ１１１３により店員呼出案内画面を表示させる。ステップＳ１１１０により決済可能であると判定されれば、携帯端末５０は、ステップＳ１１１１の処理に進むようにされる。
［第２変形例］
上記第３実施形態及び第４実施形態の各実施形態では、携帯端末５０にて商品登録が行われる都度、登録された商品に関する情報（商品コード等）がクラウドサーバ２０に送信され、クラウドサーバ２０では、受信された情報により商品登録情報（バスケット情報）を更新するようにされていた。
これに対して、例えば携帯端末５０は、商品登録が完了するまでは特にクラウドサーバ２０への商品コード等の情報を送信せずにおき、商品登録が完了して決済が行われるタイミングに応じて、これまでの商品登録結果が反映された商品登録情報を出力するようにされてよい。
具体的に、精算装置４０を利用せずに携帯端末５０にて行われる非現金決済の場合には、携帯端末５０は、非現金決済要求をクラウドサーバ２０に送信するにあたって、商品登録情報を非現金決済要求に含めるようにする。これにより、クラウドサーバ２０は、非現金決済による決済金額を確定させ、非現金決済に応じた処理を実行することができる。
また、精算装置４０にて精算を行う場合には、携帯端末５０は、精算装置誘導画面において配置されるＱＲコードについて、商品登録情報の内容を反映させればよい。これにより、精算装置４０は、ＱＲコードを読み取ることにより、商品登録情報を取得して精算処理を実行することができる。
［第３変形例］
上記第３実施形態及び第４実施形態では、精算装置４０を利用することなく携帯端末５０にて非現金決済種別による決済が完了した場合には、精算装置誘導画面が表示されはするものの、顧客は、紙媒体のレシートが不要であれば、そのまま買い物を終えたとして店舗を出て行くことができる。
しかしながら、例えば、不正防止等のために、携帯端末５０にて非現金決済種別による決済を完了させた顧客にも、携帯端末５０により非現金決済を済ませたことの証明として、必ず精算装置４０にて紙媒体のレシートを発行してもらうようにする、という運用とされてよい。
また、上記各実施形態のような運用では、例えば精算装置４０におけるクレジットカード決済完了の証明のレシートの発行、あるいは精算装置４０における精算を受けることなく、商品を持ち帰ってしまうという不正が行われる可能性がある。
このような不正の防止を考慮した場合には、例えば精算装置４０にて発行されるレシートに、コード情報をさらに印刷するとともに、店舗において買い物をした顧客が退出する出口にコードリーダを備えたゲートを設ける。なお、レシートに印刷されるコード情報は、例えば取引識別子であればよい。
そして、買い物をした顧客が店舗から退出する際には、出口のゲートにて、レシートに印刷されたコード情報をコードリーダにより読み取らせるようにする。コード情報の読み取りが行われたことに応じて、ゲートは、例えば読み取られたコード情報が示す取引識別子が示す取引は精算済みであるか否かの問合せをクラウドサーバ２０に対して行う。クラウドサーバ２０から精算済みであることの応答が得られた場合、ゲートは顧客を通過させるように動作する。一方、クラウドサーバ２０から精算済みでないことの応答が得られた場合、ゲートは顧客を通過させないように動作する。
［第４変形例］
携帯端末５０により非現金決済を行うことなく精算装置にて精算（決済）を行う場合において、精算に使用される精算装置は、顧客ではなく店員の操作に応じて精算処理を実行するものであってよい。
この場合において、例えば精算装置４０を操作する店員は、携帯端末５０の商品登録アプリケーション経由で商品登録を行った顧客に対応して、精算画面の商品リストにて提示された商品と、顧客の買い物カゴに容れられている商品が一致していることの確認（商品照合）を行うようにされる。しかしながら、商品照合の作業として、店員が買い物カゴに容れられている商品を１つずつ精算画面の商品リストにて提示された商品と照らし合わせて確認していると或る程度の時間を要してしまう。
そこで、例えば商品には、対応の商品についての商品情報を記憶するＲＦＩＤ（Radio frequency identifier）タグを付したうえで、精算装置４０には、ＲＦＩＤタグに対応するタグリーダを設ける。店員は、商品照合にあたり、顧客の買い物カゴに容れられている商品ごとのＲＦＩＤタグに記憶された商品情報をタグリーダにより読み取らせる。
この際には、店員が１つずつ商品を手に取るようにして、手に取った商品のＲＦＩＤタグをタグリーダに近付けて読み取らせるようにしてもよい。あるいは、タグリーダの通信範囲に対応する所定の位置に買い物カゴを置くことで、買い物カゴに容れられている各商品のＲＦＩＤタグをタグリーダが読み取ることができるようにしてよい。
精算装置４０は、例えば精算画面において、取引コード情報に基づく商品リストとともに、タグリーダにより読み取られた商品情報に基づく商品リストを表示してよい。この場合、店員は、取引コード情報に基づく商品リストと、タグリーダにより読み取られた商品情報に基づく商品リストとを比較し、商品照合を行うことができる。
また、この場合には、精算装置４０が、取引コード情報に基づく商品リストとタグリーダにより読み取られた商品情報に基づく商品リストとを比較して両者の内訳が一致しているか否かを判定し、一致しているか否かの報知を店員に行うようにしてもよい。
また、この場合には、携帯端末５０の商品登録アプリケーション経由での商品登録に際して、携帯端末５０が備えるタグリーダ機能を利用して、商品のＲＦＩＤタグから商品情報を読み取ることで商品情報が取得できるようにしてもよい。
また、商品照合に関して、以下のような構成としてもよい。
つまり、商品ごとに対応する商品情報において商品の重量の情報も登録しておくようにする。そのうで、商品登録結果を示す商品登録情報には、登録された商品の総重量も含まれるようにする。
そして、店員が商品照合を行う際には、商品の容れられた買い物カゴを、精算装置４０の近傍に設置された重量計の上に載せるようにする。また、この場合には、精算画面においては、取引コード情報に基づく商品リストとともに、取引コード情報に含まれる商品登録情報に含まれる商品の総重量が表示される。店員は、重量計により計測された実際の重量と、精算画面において表示される商品登録結果に応じた総重量とを比較することにより、登録された商品と、買い物カゴに容れられている商品とが同じであるか否かを判断する。
［第５変形例］
上記各実施形態において、図２３のステップＳ３００４により実行される精算処理において発行されるレシートと、ステップＳ３００６により発行されるレシートは、電子レシートとして発行されてもよい。電子レシートは、例えばステップＳ３００４またはステップＳ３００６に対応するタイミングで、携帯端末５０の商品登録アプリケーションが出力（表示、印刷等）可能な形式で、クラウドサーバ２０から携帯端末５０に送信されるようにしてよい。あるいは、携帯端末５０に商品登録アプリケーションをインストールしている顧客の顧客情報としてクラウドサーバ２０にて管理されているメールアドレスを宛先とする電子メールの形式で電子レシートが発行されるようにしてもよい。
［第６変形例］
また、商品登録アプリケーションに所定の非現金決済種別について許可を設定している顧客には、適当なタイミングでクーポン、ポイント加算等の特典が付与されるようにしてよい。また、ポイント加算等の特典の付与を考慮した場合には、上記各実施形態の商品登録アプリケーションとしての機能は、例えばポイント管理アプリケーションの一部機能として組み込まれるようにされてもよい。
このように特典が付与されることで、より多くの顧客に商品登録アプリケーションを利用して、商品登録だけでなく、クレジットカード決済等の非現金決済までを行うようにしてもらうことが促進される。この結果、店舗での会計の効率がさらに改善される。
［第７変形例］
なお、上記各実施形態において、携帯端末５０が店舗に存在していることの検知は、店舗に設置されるビーコン端末ＢＴＭから送信されるビーコン信号の受信によって行われている。
携帯端末５０が店舗に存在していることの検知は、例えば携帯端末５０が備えるＧＰＳ（Global Positioning System）等による測位機能を利用して行われてもよい。例えば、携帯端末５０の商品登録アプリケーションに対し、予め店舗の位置情報を設定しておく。設定された位置情報は、携帯端末５０が記憶していてよい。そして、携帯端末５０にて動作する商品登録アプリケーションは、現在において測位される位置が、商品登録アプリケーションに登録された店舗の位置に該当する場合に、商品登録モードを設定してフォアグラウンドで動作する状態となるようにすればよい。
［第８変形例］
上記実施形態においては、スーパーマーケットのように顧客が買い物をするのに利用される店舗に対応する場合を例に挙げた。本変形例としては、上記のような店舗に加えて、さらに飲食店での注文（商品登録に相当）や精算に対応可能とされる。この場合、携帯端末５０にインストールされる商品登録アプリケーションは、飲食店での商品登録、精算にも対応可能なものとして提供される。
本変形例において、例えば或る場所にて、顧客が携帯端末５０の商品登録アプリケーションを起動させると、携帯端末５０は、ＧＰＳ機能を利用して測定した自己の位置を基準とする一定範囲内に存在する店舗を地図上に表示させる。この際に表示される店舗には、一定範囲内に存在してさえいれば、スーパーマーケット等のほか、飲食店も表示される。
地図上に表示された店舗のうちから、スーパーマーケット等の店舗を選択する操作が行われた場合、携帯端末５０は、選択された店舗が一定距離の範囲内に位置していれば、選択された店舗に対応する商品登録画面を表示させ、一定距離の範囲外に位置していれば、例えば店舗に関する情報が提供される店舗情報画面を表示させる。
また、地図上に表示された店舗のうちから、飲食店を選択する操作が行われた場合、携帯端末５０は、選択された飲食店の予約画面に遷移する。予約画面によっては、例えば人数、日時等を予約する操作が可能とされる。さらには、予約画面によっては、座席を予約する操作が可能とされてよい。座席の予約にあたっては、例えば店舗における座席のレイアウトとともに座席の空き状況が示されるようにしてよい。
また、例えばファミリーレストランなどのような飲食店に関しては、商品登録アプリケーションにより当日の空席の順番待ちのための予約が可能なようにされてよい。この場合には、商品登録アプリケーションにより予約するにあたり、予約の人数、座席の指定等も行えるようにされてよい。この場合には、例えば予測される待ち時間や待ちの人数等が顧客に提示されるようにしてよい。また、例えば待ち時間や待ち人数が一定以下となったことに応じて、顧客の順番の来ることが近くなったことが携帯端末５０により顧客に向けて所定の態様で報知されるようにしてよい。
そして、座席に着いた顧客は、その座席（テーブル）を識別する座席識別情報を携帯端末５０に入力させる。
座席識別情報の入力は、商品登録アプリケーションが動作する携帯端末５０により、テーブルに貼り付けられているコード（例えば、ＱＲコード、あるいはバーコード等）を読み取らせることによって行われてよい。
あるいは、座席識別情報の入力は、テーブルもしくは座席の近傍の所定の場所に設けられた無線通信タグ（ＩＣタグ、ＲＦＩＤタグ等）と携帯端末５０とがＮＦＣ（Near Field Communication）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の近距離無線通信を介して、無線通信タグから取得することにより行われるようにされてもよい。
あるいは、座席識別情報の入力は、商品登録アプリケーションが動作する携帯端末５０にて表示される座席のレイアウトが示される画面に対して、該当の座席をタップ操作などにより選択する操作が行われることに応じて行われるようにされてよい。
上記のように座席識別情報が入力された携帯端末５０は、入力された座席識別情報を、飲食店に対応するクラウドサーバに送信する。これにより、店舗における座席と顧客の情報との対応付けが行われる。
座席識別情報の入力が行われた後、商品登録アプリケーションが動作する携帯端末５０は、店舗に対応するメニュー注文画面が表示される。
顧客は、メニュー注文画面からメニューを選択し、選択したメニューの注文を確定させる操作を行うことができる。また、顧客を含め複数人で来店している場合には、１つの携帯端末５０により、複数の客の注文をまとめて確定することが可能とされてよい。この際、複数の客の注文については、例えば携帯端末５０のユーザとしての顧客に対応する１取引に含まれるようにされてもよいし、顧客ごとに顧客識別情報を入力したうえで、顧客識別情報ごとに注文を対応付けることで、複数人の顧客ごとに個別に注文を区分することができる。
確定された注文の情報は、例えば、クラウドサーバに送信され、クラウドサーバは受信された注文の情報を店舗端末に送信する。店員は、店舗端末にて受信された注文の情報を確認しながら、顧客からの注文に応じた調理、配膳等を行うことができる。この際、配膳先は、入力された座席識別情報により、いずれの座席であるのかが特定される。
また、飲食店での精算は、第４実施形態において図２２、図２３による説明に準じて行われるようにされてよい。つまり、クレジットカード決済等の非現金決済に関しては、店舗（飲食店）の精算装置を使用せずに商品登録アプリケーションによって完結して行われてよい。
そのうえで、携帯端末５０は、図２２（Ｂ）に準じた精算装置誘導画面を表示してよい。この場合、顧客は、精算装置に赴いてレシートを発行させるようにしてよい。このように発行されたレシートは、顧客が訂正に非現金決済による精算を完了させていることの証明となる。例えば、店舗としては、不正防止のために、携帯端末５０により非現金決済が行われた場合には、必ず精算装置にてレシートの発行を顧客に受けてもらうようにする、という運用としてよい。
また、店舗がクーポン券、割引券、さらには駐車券等を精算装置で発行するように運用している場合にも、携帯端末にて、図２２（Ｂ）に準じた精算装置誘導画面を表示させて、顧客に精算装置にて赴いて上記の各種の券の発行を受けてもらえるようにしてよい。
例えば、特に駐車券については、現状、紙媒体のものが使用されることが多い。そこで、精算装置で精算を行うことで駐車料金を無料にする券を発行するようにされてよい。さらには駐車券の駐車可能時間の変更などの情報の更新を精算装置にて行えるようにしてもよい。これにより、精算装置の利用性の向上や、不正抑止の効果を期待することができる。
また、店内での飲食とは別に持ち帰り商品を注文していた場合、携帯端末で完結する非現金決済が行われてしまうと、飲食を終えた顧客が持ち帰り商品を注文していたことを忘れてそのまま退店してしまうといったことが起こる可能性がある。
そこで、上記のような注文内容の場合には、携帯端末で完結する非現金決済は不可として、精算装置での精算を行ってもらうという運用とされてよい。この場合、携帯端末は、図２２（Ａ）に準じた精算装置誘導画面を表示して、顧客に向けて、精算装置にて精算を行ってもらうように案内する。これにより、例えば精算装置に顧客が赴いた際に、近傍のサービスカウンタ等で業務を担当している店員が、持ち帰りの商品を顧客に対して確実に手渡ししたりすることができ、顧客が持ち帰り商品を忘れたまま退店してしまうことが防がれる。この際、サービスカウンタ等で業務を担当している店員が、持ち帰り商品を受け取るための引き渡し券を渡すようにしてもよい。
あるいは、携帯端末５０により非現金決済を完了させたことに応じて、例えば、持ち帰り商品を忘れずに持ち帰ってもらうことを顧客に案内するメッセージが、携帯端末５０にて表示されるようにされてもよい。
なお、上記の説明では、本変形例の商品登録アプリケーションは、スーパーマーケット等と飲食店との双方に対応可能なものとして説明したが、例えば飲食店には対応するが、スーパーマーケット等の店舗には対応しないものとして構成されてよい。
＜実施形態の総括＞
（１）以上説明したように、本実施形態の一態様は、顧客の操作に応じて商品に関連する商品情報を読み取り、読み取られた商品情報に基づく商品登録が行われるようにする携帯端末と、前記商品登録に応じた取引に応じた精算が可能な精算装置（例えば、精算装置４０）とを備えるセルフ登録システムにおいて、前記取引を識別可能な識別情報（例えば、取引コード情報）を前記携帯端末の出力に基づき特定する特定手段と、前記携帯端末にて、前記商品登録に応じた精算が特定の決済種別により行われるようにする第１精算手段とを備え、特定された識別情報により示される取引が前記第１精算手段により精算済みであるか否かを判定する判定手段と、前記第１精算手段により精算済みではないことが前記判定手段により判定された場合に前記精算装置にて精算を行う第２精算手段とを備えるセルフ登録システムである。
上記構成によれば、携帯端末５０にて、商品登録と、登録された商品についての特定の決済種別による精算とが可能とされる。そのうえで、精算装置は、携帯端末５０にて精算済でない場合に対応して精算を行うようにされる。
これにより、本実施形態においては、店舗にて買い物をする顧客のうちで、精算装置４０により商品登録と精算とを受けなくともよい顧客がいることになる。これにより、店舗で買い物をする顧客のうちで精算装置４０にて会計を受ける顧客の数を減少させることが可能となり、会計の効率の改善が図られることになる。
（２）本実施形態の一態様は、上記（１）に記載のセルフ登録システムであって、前記判定手段により、前記第１精算手段により精算済みであると判定された場合に、対応の取引に応じた情報（例えば、レシート）を前記精算装置にて出力させる出力手段をさらに備える。
上記構成によれば、携帯端末５０にて精算済である場合にも、精算装置にて対応の取引に応じたレシートを出力（発行）させることが可能となる。これにより、精算装置４０にて完結して行われた精算が適正に行われたことの証明を、顧客が店舗から退出する前の段階で得ることができる。
（３）本実施形態の一態様は、上記（１）または（２）に記載のセルフ登録システムであって、決済種別を選択する選択手段をさらに備える。
上記構成によれば、携帯端末５０または精算装置４０（３０）にて精算を行うにあたり、複数の決済種別のうちから、顧客が、自分にとって好ましい決済種別を利用して精算を行える。
（４）本実施形態の一態様は、上記（３）に記載のセルフ登録システムであって、前記判定手段が前記第１精算手段により精算済みでないことを判定した場合に、前記精算装置にて前記選択手段の画面を表示させる表示制御手段をさらに備える。
上記構成によれば、顧客は、携帯端末５０により精算を行わない場合には、精算装置４０（３０）にて決済種別を選択のうえで、精算を行うことができる。
（５）本実施形態の一態様は、上記（３）または（４）に記載のセルフ登録システムであって、前記選択手段により前記第１精算手段での精算が許可される決済種別が選択された場合、商品登録結果に応じて、前記携帯端末にて、前記第１精算手段での精算が不可であることを客に報知する報知手段をさらに備える。
上記構成によれば、顧客が携帯端末５０により精算を行おうとしても、商品登録の内容によっては、第１精算手段での精算が不可であることを客に報知するようにされる。これにより、例えば、登録された商品において保留商品が含まれていたり、登録商品キャンセル操作回数が多かったりする場合のように、店員による対応が必要な状況に対応できる。
（６）本実施形態の一態様は、顧客の操作に応じて商品に関連する商品情報を読み取り、読み取られた商品情報に基づく商品登録が行われるようにする携帯端末として第１コンピュータを機能させ、前記商品登録に応じた取引に応じた精算が可能な精算装置として第２コンピュータを機能させるための、セルフ登録システムのプログラムであって、前記第１コンピュータを、前記取引を識別可能な識別情報を前記携帯端末の出力に基づき特定する特定手段、特定の決済種別による精算が許可されている場合に、前記商品登録に応じた精算が前記特定の決済種別により行われるようにする第１精算手段として機能させ、前記第２コンピュータを、特定された識別情報により示される取引が前記第１精算手段により精算済みではない場合に精算を行う第２精算手段として機能させるためのプログラムである。
なお、上述の精算装置４０、携帯端末５０、クラウドサーバ２０等としての機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより上述の精算装置４０、携帯端末５０、クラウドサーバ２０等としての処理を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であってもよい。また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部または外部に設けられた記録媒体も含まれる。配信サーバの記録媒体に記憶されるプログラムのコードは、端末装置で実行可能な形式のプログラムのコードと異なるものでもよい。すなわち、配信サーバからダウンロードされて端末装置で実行可能な形でインストールができるものであれば、配信サーバで記憶される形式は問わない。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に端末装置で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
１０、１１、１２ 管理装置、２０、２１ クラウドサーバ、３０ 精算装置、４０、４１ 精算装置、５０ 携帯端末、４０１ ＣＰＵ、４０２ ＲＯＭ、４０３ ＲＡＭ、４０４ ハードディスク、４０５ 客側表示部、４０６ 客側スキャナ部、４０８ カード決済部、４０９ 釣銭機、４１０ 店員側表示部、４１１ キー操作部、４１２ 店員側スキャナ部、４１３ 印刷部、４１４ 音声出力部、４１５ 通信部、５０６ タッチパネル付表示部、５０７ 操作部、５０８ 撮像部

Claims (6)

  1. 顧客の操作に応じて商品に関連する商品情報を読み取り、読み取られた商品情報に基づく商品登録が行われるようにする携帯端末と、前記商品登録に応じた取引に応じた精算が可能な精算装置とを備えるセルフ登録システムにおいて、
    前記取引を識別可能な識別情報を前記携帯端末の出力に基づき特定する特定手段と、
    前記携帯端末にて、前記商品登録に応じた精算が特定の決済種別により行われるようにする第１精算手段とを備え、
    特定された識別情報により示される取引が前記第１精算手段により精算済みであるか否かを判定する判定手段と、
    前記第１精算手段により精算済みではないことが前記判定手段により判定された場合に前記精算装置にて精算を行う第２精算手段とを備える
    セルフ登録システム。
  2. 前記判定手段により、前記第１精算手段により精算済みであると判定された場合に、対応の取引に応じた情報を前記精算装置にて出力させる出力手段をさらに備える
    請求項１に記載のセルフ登録システム。
  3. 決済種別を選択する選択手段をさらに備える
    請求項１または２に記載のセルフ登録システム。
  4. 前記判定手段が前記第１精算手段により精算済みでないことを判定した場合に、前記精算装置にて前記選択手段の画面を表示させる表示制御手段をさらに備える
    請求項３に記載のセルフ登録システム。
  5. 前記選択手段により前記第１精算手段での精算が許可される決済種別が選択された場合に、商品登録結果に応じて、前記携帯端末にて、前記第１精算手段での精算が不可であることを客に報知する報知手段をさらに備える
    請求項３または４に記載のセルフ登録システム。
  6. 顧客の操作に応じて商品に関連する商品情報を読み取り、読み取られた商品情報に基づく商品登録が行われるようにする携帯端末として第１コンピュータを機能させ、前記商品登録に応じた取引に応じた精算が可能な精算装置として第２コンピュータを機能させるための、セルフ登録システムのプログラムであって、
    前記第１コンピュータを、
    前記取引を識別可能な識別情報を前記携帯端末の出力に基づき特定する特定手段、
    特定の決済種別による精算が許可されている場合に、前記商品登録に応じた精算が前記特定の決済種別により行われるようにする第１精算手段として機能させ、
    前記第２コンピュータを、
    特定された識別情報により示される取引が前記第１精算手段により精算済みではない場合に精算を行う第２精算手段として機能させるための
    プログラム。
JP2018245931A 2018-12-27 2018-12-27 セルフ登録システム及びプログラム Active JP7325796B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2018245931A JP7325796B2 (ja) 2018-12-27 2018-12-27 セルフ登録システム及びプログラム
JP2023121152A JP2023138560A (ja) 2018-12-27 2023-07-25 セルフ登録システム及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018245931A JP7325796B2 (ja) 2018-12-27 2018-12-27 セルフ登録システム及びプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023121152A Division JP2023138560A (ja) 2018-12-27 2023-07-25 セルフ登録システム及びプログラム

Publications (2)

Publication Number Publication Date
JP2020107122A true JP2020107122A (ja) 2020-07-09
JP7325796B2 JP7325796B2 (ja) 2023-08-15

Family

ID=71449163

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2018245931A Active JP7325796B2 (ja) 2018-12-27 2018-12-27 セルフ登録システム及びプログラム
JP2023121152A Pending JP2023138560A (ja) 2018-12-27 2023-07-25 セルフ登録システム及びプログラム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023121152A Pending JP2023138560A (ja) 2018-12-27 2023-07-25 セルフ登録システム及びプログラム

Country Status (1)

Country Link
JP (2) JP7325796B2 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001155107A (ja) * 1999-11-30 2001-06-08 Oki Electric Ind Co Ltd 電子決済システム
JP2009163323A (ja) * 2007-12-28 2009-07-23 Teraoka Seiko Co Ltd 商品販売処理システム
JP2013541107A (ja) * 2010-10-13 2013-11-07 ウォルマート ストアーズ，インコーポレーティッド 携帯装置による自己精算の方法
JP2014235530A (ja) * 2013-05-31 2014-12-15 Kddi株式会社 セルフショッピングシステム、携帯端末、コンピュータプログラムおよびセルフショッピング方法
WO2016136110A1 (ja) * 2015-02-27 2016-09-01 日本電気株式会社 情報処理装置、精算装置、情報処理方法、およびプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001155107A (ja) * 1999-11-30 2001-06-08 Oki Electric Ind Co Ltd 電子決済システム
JP2009163323A (ja) * 2007-12-28 2009-07-23 Teraoka Seiko Co Ltd 商品販売処理システム
JP2013541107A (ja) * 2010-10-13 2013-11-07 ウォルマート ストアーズ，インコーポレーティッド 携帯装置による自己精算の方法
JP2014235530A (ja) * 2013-05-31 2014-12-15 Kddi株式会社 セルフショッピングシステム、携帯端末、コンピュータプログラムおよびセルフショッピング方法
WO2016136110A1 (ja) * 2015-02-27 2016-09-01 日本電気株式会社 情報処理装置、精算装置、情報処理方法、およびプログラム

Also Published As

Publication number Publication date
JP7325796B2 (ja) 2023-08-15
JP2023138560A (ja) 2023-10-02

Similar Documents

Publication Publication Date Title
JP6947427B2 (ja) 免税商品購入支援システム及び方法、サーバ装置
WO2020050410A1 (ja) 携帯端末、計量装置、ｐｏｓ端末、プログラム、記憶媒体、販売処理システム、及び、販売処理方法
JP7376906B2 (ja) 商品登録システム、プログラム、商品登録方法、及び計量装置
WO2020050414A1 (ja) セルフ登録システム及びセルフ登録方法
JP2023138581A (ja) 販売処理システム
JP2023126581A (ja) 商品販売データ処理システム、商品販売データ処理方法、精算装置、及びプログラム
JP7325796B2 (ja) セルフ登録システム及びプログラム
JP7270241B2 (ja) 携帯端末、システム、制御方法及びプログラム
JP2022045022A (ja) 商品販売データ処理システム及びプログラム
JP7303542B2 (ja) 商品販売データ処理システム、及び商品販売データ処理方法
US20240087427A1 (en) Server apparatus, purchase management method, information processing system, information processing method, and recording medium
US20230298004A1 (en) Store system, information processing device, and control method
JP7403798B2 (ja) 精算システム、精算装置及びプログラム
JP7335033B2 (ja) 商品販売データ処理システム、精算装置、及びプログラム
JP7394449B2 (ja) 商品登録システム、登録端末、計量装置、商品登録方法、計量方法、及びプログラム
US20240054870A1 (en) Purchase management system, server apparatus, purchase management method, and recording medium
JP7455367B2 (ja) 商品販売データ処理システム
US20230297988A1 (en) Money processing system, terminal apparatus and money processing method
WO2020179783A1 (ja) 計量装置、商品データ処理システム、及びプログラム
JP2023107378A (ja) 登録装置、システム、およびプログラム
JP2022067430A (ja) 商品販売データ処理システム、プログラム、監視装置、及びサーバ装置
JP2022026584A (ja) 商品販売データ処理システム及び商品販売データ処理方法
JP2022000737A (ja) 取引状況監視装置
JP2022148380A (ja) 可搬型登録装置、商品販売データ処理システム、取引完了装置、およびプログラム
JP2023028007A (ja) プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211216

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221206

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230206

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230322

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230519

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230627

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230726

R150 Certificate of patent or registration of utility model

Ref document number: 7325796

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150