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