図面 (/)

技術 セルフ登録システム及びセルフ登録方法

出願人 株式会社寺岡精工
発明者 金子知樹黒崎直人佐々木和哉樋口真吾渡邊和希
出願日 2018年9月7日 (2年3ヶ月経過) 出願番号 2018-168328
公開日 2020年3月19日 (9ヶ月経過) 公開番号 2020-042452
状態 未査定
技術分野 金銭登録機・受付機
主要キーワード 修正指示情報 セミセル キャンセル回数 セットマッチ セット商品 提案者 基本価格 店舗状況
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年3月19日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (19)

課題

スマートフォンを用い、導入時のコストを抑えたセルフ登録システムを提供する。

解決手段

外部の決定手段と連携するセルフ登録システムであって、商品登録を行う登録手段と、登録された取引情報蓄積する蓄積手段と、前記取引情報に基づく取引金額の算出を前記外部の決定手段に依頼する依頼手段とを備える。

概要

背景

店舗における買い物において、客のスマートフォン等を用いたセルフ登録システムが提案されている(例えば、特許文献1参照)。

概要

スマートフォンを用い、導入時のコストを抑えたセルフ登録システムを提供する。外部の決定手段と連携するセルフ登録システムであって、商品登録を行う登録手段と、登録された取引情報蓄積する蓄積手段と、前記取引情報に基づく取引金額の算出を前記外部の決定手段に依頼する依頼手段とを備える。

目的

本発明は、このような事情に鑑みてなされたもので、その目的は、スマートフォンを用いたセルフ登録システムの導入時のコストを抑える技術を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

外部の決定手段と連携するセルフ登録システムであって、商品登録を行う登録手段と、登録された取引情報蓄積する蓄積手段と、前記取引情報に基づく取引金額の算出を前記外部の決定手段に依頼する依頼手段とを備えることを特徴とするセルフ登録システム。

請求項2

前記依頼手段は、算出後に前記取引金額を表示する精算装置が前記取引情報を読み取ることにより、又は、前記登録手段が前記精算装置を識別する情報を読み取ることにより、実行されることを特徴とする請求項1に記載のセルフ登録システム。

請求項3

前記蓄積手段は、登録できた取引情報に加え、登録できなかった取引情報も蓄積可能であることを特徴とする請求項1又は請求項2に記載のセルフ登録システム。

請求項4

算出後に前記取引金額を表示する精算装置は、前記登録できなかった取引情報を取得した場合にその旨を報知する報知手段を備えることを特徴とする請求項3に記載のセルフ登録システム。

請求項5

算出後に前記取引金額を表示する精算装置は、前記登録できなかった取引情報を精算可能な取引情報へ修正する修正手段を備えることを特徴とする請求項3または4に記載のセルフ登録システム。

請求項6

算出後に前記取引金額を表示する精算装置が前記取引情報を読み取ることにより、又は、前記登録手段が前記精算装置を識別する情報を読み取ることにより、精算処理をするための取引を開始する第1精算装置と、店員登録操作で取引情報が生成されることにより、精算処理をするための取引を開始する第2精算装置と、を備えることを特徴とする請求項1乃至5のいずれか一項に記載のセルフ登録システム。

請求項7

外部の決定手段と連携するセルフ登録方法であって、商品登録を行う登録ステップと、登録された取引情報を蓄積する蓄積ステップと、前記取引情報に基づく取引金額の算出を前記外部の決定ステップに依頼する依頼ステップとを備えることを特徴とするセルフ登録方法。

技術分野

0001

本発明は、セルフ登録システム及びセルフ登録方法に関する。

背景技術

0002

店舗における買い物において、客のスマートフォン等を用いたセルフ登録システムが提案されている(例えば、特許文献1参照)。

先行技術

0003

特開2016−219034号公報

発明が解決しようとする課題

0004

しかしながら、スマートフォンを用いたセルフ登録システムを普及させるには、様々な課題があり、課題の一つは、スマートフォンを用いたセルフ登録システムの導入時において、既存の装置やシステム入れ替えが必要であるため、費用や時間がかかることであった。

0005

本発明は、このような事情に鑑みてなされたもので、その目的は、スマートフォンを用いたセルフ登録システムの導入時のコストを抑える技術を提供することにある。

課題を解決するための手段

0006

上述した課題を解決するために、本発明の一態様であるセルフ登録システムは、外部の決定手段と連携するセルフ登録システムであって、商品登録を行う登録手段と、登録された取引情報蓄積する蓄積手段と、前記取引情報に基づく取引金額の算出を前記外部の決定手段に依頼する依頼手段とを備えることを特徴とする。

0007

上記構成によれば、顧客に合わせて売価決定ロジックを用意する手間を削減するために、既存の売価決定ロジックを利用します。これにより導入工数(コスト)を小さくすることができるので、普及を容易にすることができる。

0008

上記セルフ登録システムにおいて、前記依頼手段は、算出後に前記取引金額を表示する精算装置が前記取引情報を読み取ることにより、又は、前記登録手段が前記精算装置を識別する情報を読み取ることにより、実行されるものであってもよい。

0009

上記構成によれば、簡便に取引金額の算出を依頼することができる。

0010

上記セルフ登録システムにおいて、前記蓄積手段は、登録できた取引情報に加え、登録できなかった取引情報も蓄積可能であってもよい。

0011

上記構成によれば、登録できなかった取引情報を好適に管理することができる。

0012

上記セルフ登録システムにおいて、算出後に前記取引金額を表示する精算装置は、前記登録できなかった取引情報を取得した場合にその旨を報知する報知手段を備えるものであってもよい。

0013

上記構成によれば、登録できなかった取引情報がある旨を認識することができる。

0014

上記セルフ登録システムにおいて、算出後に前記取引金額を表示する精算装置は、前記登録できなかった取引情報を精算可能な取引情報へ修正する修正手段を備えるものであってもよい。

0015

上記構成によれば、例えば店員が精算可能な取引情報に修正することにより、客は精算処理を行うことができる。

0016

上記セルフ登録システムは、算出後に前記取引金額を表示する精算装置が前記取引情報を読み取ることにより、又は、前記登録手段が前記精算装置を識別する情報を読み取ることにより、精算処理をするための取引を開始する第1精算装置と、店員の登録操作で取引情報が生成されることにより、精算処理をするための取引を開始する第2精算装置と、を備えるものであってもよい。

0017

上記構成によれば、既存のシステムをそのまま残しつつ、セルフ登録システムを導入でき、かつ、両システムを共存させることができる。

0018

上述した課題を解決するために、本発明の他の態様であるセルフ登録方法は、外部の決定手段と連携するセルフ登録方法であって、商品登録を行う登録ステップと、登録された取引情報を蓄積する蓄積ステップと、前記取引情報に基づく取引金額の算出を前記外部の決定ステップに依頼する依頼ステップとを備えることを特徴とする。

発明の効果

0019

導入時のコストを抑えることができる。

図面の簡単な説明

0020

ショッピングシステムを説明するためのネットワーク概念図である。
精算装置の設置例を示す図である。
精算装置の外観例を示す図である。
精算装置の構成例を示す図である。
第1の実施形態のショッピングシステムを説明するための各機能の概念図である。
各種の売価決定ロジック(売価決定機能)について説明する説明図である。
各種の情報について説明する説明図である。
処理の流れの概略を説明するシーケンス図である。
携帯端末の表示部における表示例である。
精算装置の表示部における表示例である。
第2の実施形態のショッピングシステムを説明するための各機能の概念図である。
処理の流れの概略を説明するシーケンス図である。
第3の実施形態のショッピングシステムを説明するための各機能の概念図である。
処理の流れの概略を説明するシーケンス図である。
商品登録時における、より詳細な動作の流れの一例を示すフローチャートである。
商品登録時における、より詳細な動作の流れの一例を示すフローチャートである。
精算時における、より詳細な動作の流れの一例を示すフローチャートである。
バスケット情報内に記憶される情報の一例である。

実施例

0021

(第1の実施形態)
図1は、ショッピングシステムを説明するためのネットワークの概念図である。図1に示すショッピングシステムは、管理装置(例えば、ストアコントローラ)10、クラウドサーバ20、精算装置30、精算装置40、及び、携帯端末50(例えば、スマートフォン等)を含む。

0022

管理装置10、精算装置30、精算装置40は、店舗内に設置されるものであり、LAN19(有線でも無線でもよい)を介して通信可能に接続されている。管理装置10は、クラウドサーバ20と通信可能である。なお、図1において、2台の精算装置30を図示したが、1店舗内の精算装置30の数は、1台であってもよいし3台以上であってもよい。また、図1において、2台の精算装置40を図示したが、1店舗内の精算装置40の数は、1台であってもよいし3台以上であってもよい。精算装置30の台数と精算装置40の台数は一致していなくてもよい。また、管理装置10は、基本的には1店舗に1台であるが、2台以上であってもよい。

0023

携帯端末50は、顧客(当該店舗の会員である買物客等)によって操作されるものである。携帯端末50は、一般的な、通信機能撮像機能カメラ)に加えて、商品に付されるバーコードスキャンして商品コードを読み取る、つまり商品に付されるバーコードを認識する認識機能を備える。なお、携帯端末50が備える認識機能は、商品コードを読み取ることができるものであればよく、読み取った商品コードが何れの商品の商品コードであるかを認識できるものでなくてもよい。つまり、携帯端末50は、撮像機能によって撮像されている撮像画像スルー画像として取得している画像)内にオブジェクトとしてバーコードが存在する場合に、当該バーコードから商品コードを読み取ることができるようになっていればよい。

0024

また、携帯端末50は、商品(例えばバーコードの付された周辺部分)を撮像し(シャッター切り)、撮像画像(画像データ)を生成する。携帯端末50は、操作者である顧客の操作に従ってシャッターを切る撮像であってもよいが、本実施形態では、携帯端末50自身の判断(例えば、後述する図15のステップS31、S45を参照)によりシャッターを切る撮像であることが好ましい。

0025

また、携帯端末50は、画像(スルー画像、撮像画像)から特徴点を抽出し、撮像対象(オブジェクト等)を認識する画像認識技術を備えていてもよい。例えば、携帯端末50は、画像認識技術を用いて、撮像した商品を特定(推定)してもよい。

0026

携帯端末50は、基本的には各顧客の所有物であることを想定しているが、店舗側貸与するものであってもよい。なお、携帯端末50の数(稼働中の数)は、来店者数等に応じて変化するものであり、図1では、複数台が可能である旨の例として2台の携帯端末50を図示している。

0027

精算装置30及び精算装置40は、共に、精算方法として少なくとも現金による支払いが可能な精算装置である。精算装置30は、クラウドサーバ20との通信機能を有しないが、精算装置30は、クラウドサーバ20との通信機能を有する。クラウドサーバ20は、例えば、顧客毎に、取引情報(バスケット情報)を管理する。

0028

なお、図1に示すショッピングシステムは、本発明の第1の実施形態(第2の実施形態、第3の実施形態も同様)に係るショッピングシステムを説明するためのものであり、本発明の第1の実施形態(第2の実施形態、第3の実施形態も同様)に係るショッピングシステムは、図1に示した全部の構成を必ずしも含むものではない。例えば、本発明の第1の実施形態(第2の実施形態、第3の実施形態も同様)に係るショッピングシステムは、例えば、クラウドサーバ20と精算装置40とから構成されるものであってもよいし、クラウドサーバ20単体であってもよいし、精算装置40単体であってもよい。

0029

図2は、精算装置40の設置例を示す図である。図2(A)は、精算装置40等を客側から見た斜視図である。図2(B)は、精算装置40等を店員側から見た斜視図である。図2(A)に示すように客側から見て精算装置40の右側にカウンタが置かれている。

0030

図3は、精算装置40の外観例を示す図である。図3(A)は、精算装置40を客側から見た斜視図である。図3(B)は、精算装置40を店員側から見た斜視図である。図4は、精算装置40の構成例を示す図である。図3及び図4において、同一部分には同一符号を付している。

0031

以下、図3を参照しつつ、図4に示した精算装置40の構成例を説明する。精算装置40は、CPU401と、ROM402と、RAM403と、ハードディスク404と、客側表示部405と、客側スキャナ部406と、カード決済部408と、釣銭機409と、店員側表示部410と、キー操作部411と、店員側スキャナ部412と、印刷部413と、音声出力部414と、通信部415とを備える。これらは、バスを介して相互に通信可能である。

0032

CPU401は、中央演算処理装置であり、ROM402に記憶されているプログラム読み出して実行することにより、精算装置40の動作を制御する。
ROM402は、読み出し専用メモリであり、プログラムをはじめとしてCPU401が利用する各種の情報を記憶する。

0033

RAM403は、読み出し書き込みメモリであり、種々の情報を記憶する。例えば、RAM403は、ROM402やハードディスク404から読みだした情報、外部から取得した情報、処理において生成した情報等を記憶する。

0034

ハードディスク404は、種々の情報を記憶する。ハードディスク404は、例えば、ROM402に代えて、CPU401が実行するプログラム等を記憶してもよい。また、RAM403に代えて、ROM402から読みだした情報、外部から取得した情報、処理において生成した情報等を記憶してもよい。

0035

客側表示部405は、客用タッチディスプレイであり、客に種々の情報を表示するとともに、客から種々の入力を受け付ける。
客側スキャナ部406は、客用のスキャナ部であり、例えば、商品に付されているバーコードをスキャンし、商品コードを読み取る。また、客側スキャナ部406は、お会計券(登録商標)に印刷されているコード(バーコード、2次元コード等)をスキャンし、精算に必要な情報を読み取ってもよい。また、客側スキャナ部406は、携帯端末50の表示部に表示されるコード(2次元コード等)をスキャンし、精算に必要な情報を読み取ってもよい。

0036

なお、客側スキャナ部406は、客が商品を登録する際に用いられるが、客は他の方法によって商品を登録してもよい。例えば、客側表示部405に、商品に対応するプリセットキー(商品を注文するボタン)が表示されている場合、客は、当該プリセットキーを操作(押下)し、商品を登録してもよい。

0037

カード決済部408は、各種カードクレジットカード交通カード等のプリペイドカード等)による決済機構である。第1の実施形態(第2の実施形態、第3の実施形態も同様)のカード決済部408は、カード認識部(読取部)や表示部や操作部を備えるが、少なくとも、カード認識部を備えるものであればよい。なお、カード認識部は、直接的には決済(精算)に使用しない各種カード(例えば、会員カードポイントカード等)を認識してもよい。

0038

釣銭機409(現金決済部)は、現金による決済機構であり、紙幣硬貨投入口、紙幣や硬貨の排出口を有し、投入口への投入金額を算出し、投入金額と買上金額の差分である釣銭金額を算出し、釣り銭を排出口から排出する。なお、当該釣銭機409は、客側に向けられており、客が操作するものである。なお、紙幣や硬貨が投入口に投入された場合にはセンサによって検出(投入があった旨の検出、金種別枚数の検出等)される。

0039

つまり、釣銭機409は、精算装置40において、登録された商品の代金を現金(貨幣)にて決済するときに使用される。釣銭機409は、紙幣を投入するための紙幣投入口、硬貨を投入するための硬貨投入口、紙幣を放出するための紙幣放出口、硬貨を放出するための硬貨放出口、投入又は放出される貨幣を計数する計数部、投入口又は放出口と収納部の間の貨幣の搬送機構、上述したセンサなどを有する。なお、紙幣投入口及び硬貨投入口は、預り金投入口とも称される。紙幣放出口及び硬貨放出口は、釣銭放出口とも称される。なお、紙幣投入口と紙幣放出口は共通であってもよく、また、硬貨投入口と硬貨放出口は共通であってもよい。

0040

また、釣銭機409は、閉店処理時に補充された貨幣を計数し、収納部に収納する。また、釣銭機409は、閉店処理時に出金する貨幣を計数し、釣銭放出口から放出する。閉店処理とは、閉店後や開店前などに釣銭機409内に収納されている金額現金有高現金在高)を基準金額に調整する処理である。

0041

店員側表示部410は、店員用のタッチディスプレイであり、店員に種々の情報を表示するとともに、店員から種々の入力を受け付ける。
キー操作部411は、各種のキー(ボタン)から構成され、店員から種々の入力を受け付ける。
店員側スキャナ部412は、店員用のスキャナ部であり、例えば、商品に付されているバーコードをスキャンし、商品コードを読み取る。また、店員側スキャナ部412は、店員の名札に付されたバーコード等をスキャンし、店員コードを読み取る。

0042

なお、店員側スキャナ部412は、店員が商品を登録する際に用いられるが、店員は他の方法によって商品を登録してもよい。例えば、キー操作部411に、商品に対応するキー(例えば、スポーツ新聞に対応するキー等)が配置されている場合、店員は、当該キーを操作(押下)し、当該商品を登録してもよい。また、店員側表示部410に、商品に対応するプリセットキーが表示されている場合、店員は、当該プリセットキーを操作し、当該商品を登録してもよい。

0043

印刷部413は、各種媒体レシート、お会計券等)を印刷、発行する。印刷部413は、店員側から客側、客側から店員側に向き(媒体発行口の方向)を回転自在に変更である。印刷部413の向きは、手動で変更してもよいし、例えば動作モード(詳細は後述)の移行切替)に応じて自動的に変更(メカ的に制御等)してもよい。なお、印刷部413の向きの正誤をセンサなどで検出してもよい。

0044

音声出力部414は、音声を出力する。例えば、音声出力部414は、音声ガイダンス等を出力する。
通信部415は、他装置(他の精算装置40、精算装置30、管理装置10)との間において情報を送受信する。

0045

以上、精算装置40の外観やハードウェア構成を説明したが、精算装置30の外観やハードウェア構成については説明を省略する。精算装置30と精算装置40とは、後述するように(図5等参照)、ソフトウェアによって実現される機能が互いに異なるが、精算装置30と精算装置40とは、外観やハードウェア構成は同一であってもよいし、異なっていてもよい。例えば、精算装置40は、2つのスキャナ部(客側スキャナ部406、店員側スキャナ部412)を有する精算装置40であるのに対し、精算装置30は、1つのスキャナ部を有する精算装置であってもよい。

0046

図5は、第1の実施形態のショッピングシステムを説明するための各機能の概念図である。図6は、各種の売価決定ロジック(売価決定機能)について説明する説明図である。図7は、各種の情報について説明する説明図である。

0047

なお、図5は、本発明の第1の実施形態に係るショッピングシステムを説明するためのものであり、本発明の第1の実施形態に係るショッピングシステムは、図1に示した全部の構成を必ずしも含むものではない。例えば、本発明の第1の実施形態に係るショッピングシステムは、クラウドサーバ20と精算装置40とから構成されるものであってもよいし、クラウドサーバ20単体であってもよいし、精算装置40単体であってもよい。また、図5は、本発明の第1の実施形態に係るショッピングシステムの特徴部分に関連する機能を抜粋して説明するものであり、一般にショッピングシステムに必要とされる機能を網羅的に説明するものではない。

0048

(精算装置30)
図5の右下に示すように、精算装置30は、売価決定ロジック(売価決定機能)、精算機能を備える。売価決定ロジックは、精算処理において求められる売価(販売対価としての請求金額)を決定(算出)する機能であり、ソフトウェアによって実現される。売価決定ロジックには、種々の種類があるが(例えば、図6参照)、図5に示した例では、精算装置30は、売価決定ロジックA、売価決定ロジックBを備えている。

0049

なお、図6に示した売価決定ロジックAは、運用中(適宜)の売価変更に対応する基本的な単品に対する値引価格基本価格算出機能である。売価決定ロジックBは、設定情報(単品値引設定情報)に基づいて単品に対する値引価格を算出する単品値引価格算出機能である。売価決定ロジックCは、設定情報(小計値引設定情報)に基づいて小計に対する値引価格を算出する小計値引価格算出機能である。売価決定ロジックDは、設定情報(会員値引設定情報)に基づいて単品又は小計に対する値引価格を算出する会員値引価格算出機能である。売価決定ロジックEは、設定情報(タイムサービス値引設定情報)に基づいて単品に対する値引価格を算出するタイムサービス値引価格算出機能である。売価決定ロジックFは、設定情報(ミックスマッチ値引設定情報)に基づいてミックス商品(組み合わせ不指定(不定)の商品群)に対する値引価格を算出するミックスマッチ値引価格算出機能である。売価決定ロジックGは、設定情報(セットマッチ値引設定情報)に基づいてセット商品(組み合わせ指定(固定)の商品群)に対する値引価格を算出するセットマッチ値引価格算出機能である。売価決定ロジックHは、設定情報(決済種別値引設定情報)に基づいて利用される決済種別に応じた値引価格を算出する決済種別値引価格算出機能である。

0050

なお、売価決定ロジックD(会員値引価格算出機能)が適用される会員は、顧客の全部(全顧客)であってもよいし、顧客の一部(例えば特定の顧客ランクの顧客)であってもよい。

0051

売価決定ロジックAに係る情報(売価変更の情報)や売価決定ロジックB〜売価決定ロジックHに対応する各種設定情報は、精算装置30の記憶部、又は、精算装置30がアクセス可能な装置)に記憶されていればよい。なお、精算装置30は、上述したように売価決定ロジックA、Bを備えるが、売価決定ロジックC〜Fは備えないため、少なくとも、売価決定ロジックAに係る情報(売価変更の情報)と、売価決定ロジックBに対応する設定情報(単品値引設定情報)と、が参照できるようになっていればよい。

0052

また、図6では図示を省略したが、夫々の売価決定ロジック(売価決定ロジックA〜H)とは別に、夫々の売価決定ロジックを統括する売価決定統括ロジックも存在する。売価決定統括ロジックは、複数の売価決定ロジックにまたがって売価を決定するためのロジックである。例えば、売価決定ロジックB(単品値引価格算出機能)と売価決定ロジックD(会員値引価格算出機能)がある場合に、売価決定統括ロジックは、売価決定ロジックBと売価決定ロジックDがある場合の値引きを設定情報(売価決定統括設定情報)に基づいて決定する。

0053

一例として、商品a(商品情報では100円)が、売価決定ロジックB(及び単品値引設定情報)によれば80円(10円値引)であり、売価決定ロジックD(及び会員値引設定情報)によれば90円(20円値引)である状態において、会員(売価決定ロジックDの適用対象である顧客)が商品aを購入した場合、売価決定統括ロジックは、売価決定ロジックDのみを適用して商品aの価格を80円(20円値引)としてもよいし、売価決定ロジックB、Dの両方を適用して商品aの価格を70円(30円値引)としてもよい。売価決定ロジックDのみを適用し商品aの価格を80円とするか、売価決定ロジックB、Dの両方を適用し商品aの価格を70円とするかは、設定情報(売価決定統括設定情報)による。なお、売価決定統括ロジックは、値引き額が小さい方を決定する場合もある。

0054

例えば、上述したように会員値引額の方が大きい場合(売価決定ロジックBによる単品値引額が10円、売価決定ロジックDによる会員値引額が20円の場合)に、売価決定ロジックDを適用せずに売価決定ロジックBのみを適用して商品aの価格を90円とする場合もありうる。具体的には、会員割引による割引限度額が設定されている場合や会員割引による購入が会員ランク実績に反映されない場合には、売価決定ロジックBのみを適用する旨を設定情報(売価決定統括設定情報)に設定してもよい。また、上記とは逆に、単品割引額の方が大きい場合(売価決定ロジックBによる単品値引額が30円、売価決定ロジックDによる会員値引額が20円の場合)に、売価決定ロジックBを適用せずに売価決定ロジックDのみを適用して商品aの価格を80円とする場合もありうる。具体的には、会員割引による購入実績が会員ランクの算出に優遇される場合には、売価決定ロジックDのみを適用する旨を設定情報(売価決定統括設定情報)に設置してもよい。

0055

上述した売価決定統括ロジックは、必要に応じて(複数の売価決定ロジックにおける調整が必要な場合に)、備えていればよい。例えば、第1の実施形態においてクラウドサーバ20(精算装置30も同様)は、売価決定ロジックA、B、Cを備えるが(図5)、更に、売価決定統括ロジックを備えていてもよい。第2、3の実施形態においても同様である。

0056

なお、売価決定統括ロジックも、図6に示した売価決定ロジックの1つと捉えてもよい。以下の説明において、図6に示したような個々の売価決定ロジックの1つ又は複数を「売価決定ロジック」と称する場合と、売価決定統括ロジックを含めて「売価決定ロジック」と称する場合とがある。つまり、単に「売価決定ロジック」と記載した場合には、売価決定統括ロジックを除外する場合と、売価決定統括ロジックを除外しない場合とがあるものとする。

0057

精算機能は、売価決定ロジックによって決定された売価に基づいて精算処理(例えば、釣銭機による現金の支払い等)を実行する機能である。

0058

なお、図5図11図13も同様)では、売価決定ロジックを、精算機能とは別の機能として説明しているが、売価決定ロジックは、精算機能の一部であると捉えてもよい。つまり、図5図12図14も同様)では、売価を決定する部分と、決定された売価に基づいて実際に支払いを実行する部分とを別個に捉え、売価を決定する部分に対応する機能を売価決定ロジックと称し、実際に支払いを実行する部分を精算機能と称しているが、売価を決定する部分も含め、精算機能と称してもよい。売価を決定する部分も含め、精算機能と称する場合には、売価決定ロジックは、精算機能の一部となる。

0059

(管理装置10)
図5の右上に示すように、管理装置10は、店舗情報、商品情報を記憶する。管理装置10は、売価決定ロジックを備えていてもよい。管理装置10が記憶する店舗情報は、当該管理装置10が設置された店舗に関する情報であって、例えば、当該店舗の店舗名、当該店舗を特定する情報等を含む。管理装置10が記憶する商品情報は、当該管理装置10が設置された店舗において販売される商品に関する情報であって、例えば、商品コード、商品名、価格等が含む。なお、管理装置10は、例えば、外部(本部のサーバ(不図示)等)から商品情報等を取得し、記憶してもよい。また、管理装置10は、外部(本部のサーバ)であってもよい。つまり、各店舗で利用される共通のまたは別個(店舗毎)の商品情報や売価決定ロジックを管理するものであってもよい。第2、第3の実施形態の管理装置10(管理装置11、12)についても同様である。

0060

(クラウドサーバ20)
図5の左上に示すように、クラウドサーバ20は、売価決定ロジックを備える。上述したように、売価決定ロジックには、種々の種類があるが(例えば、図6参照)、図5に示した例では、クラウドサーバ20は、売価決定ロジックA、売価決定ロジックB、売価決定ロジックCを備えている。なお、クラウドサーバ20は、売価決定ロジックA〜Cを備えるが、売価決定ロジックD〜Fは備えないため、少なくとも、売価決定ロジックAに係る情報(売価変更の情報)と、売価決定ロジックBに対応する設定情報(単品値引設定情報)と、売価決定ロジックCに対応する設定情報(小計値引設定情報)が参照できるようになっていればよい。

0061

また、クラウドサーバ20は、顧客情報、店舗情報、商品情報、バスケット情報を記憶する。顧客情報は、個々の顧客を管理するための情報である。クラウドサーバ20は、顧客登録時に顧客情報を生成する(ある顧客の顧客情報が記憶されることを以って当該顧客の顧客登録がなされたと解してもよい)。また、クラウドサーバ20は、バスケット情報等に基づいて、顧客情報を適宜更新する。例えば、クラウドサーバ20は、例えば毎日所定時刻にバスケット情報を参照し、顧客情報を更新してもよい。

0062

クラウドサーバ20は、例えば、図7(A)に示すような顧客情報を記憶する。図7(A)に示した顧客情報は、顧客識別情報、顧客名、顧客登録日、キャンセル情報、顧客ランク、ポイント数等を含む。顧客識別情報は、顧客を一意に識別する識別情報である。顧客名は、顧客の氏名やニックネームなどである。顧客登録日は、顧客登録した日時である。キャンセル情報は、登録後における登録商品キャンセルに関する情報である。顧客ランクは、顧客の購入実績に応じたランクである。なお、新規の顧客の顧客情報の生成時には、顧客識別情報、顧客名、顧客登録日は生成されるが、実際の取引(商品登録)の開始前であるため、他の情報(キャンセル情報等)は生成されない。

0063

クラウドサーバ20は、例えば、顧客登録の際(例えば、携帯端末50が外部(例えば、アプリ全般を提供する所定のサーバ、当該クラウドサーバ20)からクラウドサーバ20によるサービスを利用するためアプリケーション(アプリ)をダウンロード又はインストールする際)に顧客識別情報を生成し、記憶する。また、クラウドサーバ20は、例えば、顧客登録の際に、携帯端末50を用いて、登録フォーム入力フォーム)の氏名欄に入力された情報を取得し、顧客名として記憶する。また、クラウドサーバ20は、例えば、顧客登録の際の現在日時を取得し、顧客登録日として記憶する。

0064

なお、クラウドサーバ20は、自装置内の記憶部に顧客情報を記憶することに代えて又は加えて他の装置(クラウドサーバ20がアクセス可能なファイルサーバ等)に顧客情報の一部または全部を記憶してもよい。

0065

店舗情報は、各店舗の管理装置10から取得したものである(図5の送受信データ「D0」参照。なお、送受信データ「D1」〜「D6」は図8にて説明する)。つまり、クラウドサーバ20は、各店舗の管理装置10から直接又は他の装置を介して間接的に店舗情報を受信するなどして、店舗情報を記憶する。

0066

クラウドサーバ20は、例えば、図7(B)に示すような店舗情報を記憶する。図7(B)に示した店舗情報は、店舗識別情報、店舗名(支店名)、店舗特定情報1、店舗特定情報2を含む。店舗識別情報は、店舗を一意に識別する識別情報である。図7(B)に示した店舗識別情報は、店(屋号)若しくは企業のコードと、支店のコードとから構成される。店舗名は、店舗の名称である。図7(B)に示した店舗名は、店(屋号)若しくは企業と、支店名とから構成される。店舗特定情報1は、取引する店舗(商品の売買が行われる店舗)を特定するための2次元コード(QRコード(登録商標)等)の情報である。店舗特定情報2は、取引する店舗を特定するための店舗の位置情報GPS情報)である。なお、図7(B)に示した例では、店舗識別情報と店舗特定情報1とは異なるが、店舗識別情報と店舗特定情報1とは同一であってもよい。

0067

なお、クラウドサーバ20は、外部(各店舗を統括する本部のサーバ(不図示)等)から店舗情報等を取得し、記憶してもよい。また、クラウドサーバ20は、自装置内の記憶部に店舗情報を記憶することに代えて又は加えて他の装置(クラウドサーバ20がアクセス可能なファイルサーバ等)に店舗情報の一部または全部を記憶してもよい。

0068

商品情報は、各店舗の管理装置10等から取得したものである(図5の送受信データ「D0」参照。なお、送受信データ「D1」〜「D6」は図8にて説明する)。つまり、クラウドサーバ20は、各店舗の管理装置10から直接又は他の装置を介して間接的に商品情報を受信するなどして、商品情報を記憶する。なお、クラウドサーバ20は、外部(各店舗を統括する本部のサーバ(不図示)等)から商品情報を取得し、記憶してもよい。また、クラウドサーバ20は、自装置内の記憶部に店舗情報を記憶することに代えて又は加えて他の装置(クラウドサーバ20がアクセス可能なファイルサーバ等)に店舗情報の一部または全部を記憶してもよい。

0069

バスケット情報は、個々の取引を管理するための情報である。クラウドサーバ20は、取引の開始時にバスケット情報を生成する。また、クラウドサーバ20は、取引の進行にあわせて(商品が登録される度に)、バスケット情報を更新する(バスケット情報に商品が記憶されることを以って当該商品の登録がなされたと解してもよい)。

0070

クラウドサーバ20は、例えば、図7(C)に示すようなバスケット情報を記憶する。図7(C)に示したバスケット情報は、バスケット識別情報、取引開始日時、取引終了日時、顧客識別情報、登録商品情報保留商品情報、キャンセル情報等を含む。バスケット識別情報は、バスケットを一意に識別する識別情報である。図7(C)に示したバスケット識別情報は、店舗識別情報と、日付と、シリアル番号(例えば店舗別日付別のシリアル番号)とから構成される。取引開始日時は、取引の開始日時である。図7に示した取引開始日時は、当該バスケット情報の生成日時である。なお、取引開始日時は、1品目の商品の登録日時(図7(C)中の登録商品情報(登録商品1)を記憶した日時)としてもよい。バスケット情報の生成日時と1品目の商品の登録日時とを別々に両方記憶してもよい。

0071

取引終了日時は、取引の終了日時である。図7に示した取引開始日時は、精算日時である。顧客識別情報は、当該取引の顧客を識別する顧客識別情報である。なお、バスケット情報の生成時には、バスケット識別情報、取引開始日時、顧客識別情報は生成されるが、実際の取引(商品登録)の開始前であるため、他の情報(取引終了日時等)は生成されない。なお、精算日時は、精算開始日時であってもよいし(例えば、図17のステップS89の処理の実行日時)、精算終了日時であってもよい(図17のステップS91の処理の終了日時)。精算開始日時と精算終了日時とを別々に両方記憶してもよい。

0072

登録商品情報(計)は、商品が登録される毎に更新される情報である。登録商品情報(計)は、品数商品数)、概算小計金額価格決定ロジックによる価格算出前の概算の小計金額)、小計金額(価格決定ロジックによる価格算出後の小計金額)等を含む。登録商品情報(1)は、1品目の商品の登録情報である。登録商品情報(2)は、2品目の商品の登録情報である。なお、図7(C)に示す例では、登録商品情報(3)〜登録商品情報(5)の図示を省略している。登録商品情報(N;Nは整数)は、商品コード、品名(商品名)、価格等を含む。

0073

登録商品情報(N)は、当該N品目の商品の登録日時を含むものであってもよい。つまり、クラウドサーバ20は、登録商品情報として、当該登録商品の登録日時を記憶してもよい。各商品の登録日時は、タイムサービス(売価決定ロジックEによるサービス)等のサービス適用の要否や適用後の効果の判断材料としても用いてもよい。

0074

保留商品情報(計)は、保留商品(後述)が登録される毎に更新される情報である。保留商品情報(計)は、保留商品の品数(商品数)、保留商品のうちのNON−PLU(「NO−FILE」とも称する)の品数、保留商品のうちの読取NG(要不正操作確認)の品数等を含む。

0075

NON−PLUとは、店舗においてバーコードのスキャンは成功したが(商品コードを読み取ることができたが)、商品コードが商品情報に記憶されていないこと、又は、店舗において商品コードのスキャンは成功したが、商品コードが商品情報に記憶されていない商品のことである。

0076

読取NGとは、店舗において商品コードのスキャンが失敗したこと(商品コードを読み取ることができなかったこと)、又は、店舗において商品コードのスキャンが失敗した商品のことである。つまり、読取NGとは、例えば画像認識技術により一定時間商品を撮像しているがバーコード認識に至らない場合を判別できる場合にタイムアウト処理すること、タイムアウト処理された商品である。例えば、パッケージシワ等やバーコード印字カスレや汚れにより正しくバーコードを取得(認識)できない場合に読取NGと判断される。また、バーコードを読んだフリしてカゴへ投入する不正操作を検出した場合にも読取NGと判断される。なお、携帯端末50は、センサ(例えば、ジャイロセンサ加速度センサ距離センサ等)を備え、当該携帯端末50がバーコード読取中(具体的には、バーコードの読み取りのため、当該携帯端末50が傾けられている状況であり、かつ、当該携帯端末50一定距離先に物品(商品)が存在している状況)を検出可能である。そして、所定時間内にバーコードが読み取れなかった場合(バーコード読取中が所定時間継続したがバーコードを読み取れなかった場合)は、タイムアウト処理として、保留商品(読取NG)としている。

0077

保留商品情報(保留商品1)は、1品目の保留商品の情報である。保留商品情報(保留商品2)は、2品目の保留商品の情報である。保留商品情報(保留商品3)は、3品目の保留商品の情報である。

0078

保留商品情報(保留商品N;Nは整数)は、保留商品種別(当該保留商品がNON−PLUであるか読取NGであるかを示す情報)、画像データ(読取NG時に撮像された画像データ)を含む。例えば、N品目の商品がNON−PLUによる保留商品である場合には、保留商品情報(保留商品N)は、保留商品種別「1(NON−PLU)」、画像データを含む。また、N品目の商品が読取NGによう保留商品である場合には、保留商品情報(保留商品N)は、保留商品種別「2(読取NG)」、画像データを含む(図18(D)参照)。

0079

なお、クラウドサーバ20は、自装置内の記憶部にバスケット情報を記憶することに代えて又は加えて他の装置(クラウドサーバ20がアクセス可能なファイルサーバ等)にバスケット情報の一部または全部を記憶してもよい。

0080

(精算装置40)
図5の左下に示すように、精算装置40は、クラウド通信機能、携帯端末連動機能、精算機能を備える。クラウド通信機能は、クラウドサーバ20と通信する機能である。携帯端末連動機能は、携帯端末50との連動する機能であり、例えば、携帯端末50の表示部に表示されるコード(2次元コード等)を光学的にスキャンし(読み取り)、スキャンした情報(またはスキャンした情報に基づく情報)をクラウド通信機能側に供給する機能である。携帯端末50の表示部に表示されるコードは、当該携帯端末50による買上商品について精算処理を実行するために必要となる情報(例えば、バスケット識別情報)をコード化したものである。なお、クラウド通信機能、携帯端末連動機能は、精算装置30は備えていない精算装置40の固有機能である。

0081

精算機能は、クラウドサーバ20の売価決定ロジックによって決定された売価に基づいて精算処理(例えば、釣銭機による現金の支払い等)を実行する機能である。

0082

精算装置40は、クラウド通信機能、携帯端末連動機能、精算機能を備えるため、例えば、ある顧客の携帯端末50の表示部に表示されるコード(当該顧客のバスケット情報を特定可能な情報)をスキャンし、スキャンした情報(またはスキャンした情報に基づく情報)をクラウドサーバ20に送信し、クラウドサーバ20から当該顧客のバスケット情報に基づく売価(小計情報)を受信し、受信した売価に基づいて精算処理を実行することができる。

0083

(携帯端末50)
図5の左下に示すように、携帯端末50は、クラウドサーバ20と通信する。携帯端末50は、クラウドサーバ20と通信することにより商品を登録する。つまり、携帯端末50は、ある商品に付されているバーコードを撮像することにより、オブジェクトとして当該バーコードを認識し(バーコードから商品コードを読み取り)、商品コードをクラウドサーバ20に送信することにより、当該商品を登録する(具体的には、クラウドサーバ20のバスケット情報に当該商品コードを記憶させる)。

0084

また、携帯端末50は、コード(2次元コード等)を生成する。つまり、携帯端末50は、精算装置40の携帯端末連動機能に関連して、表示部にコードを表示するが、携帯端末50は、表示部に表示するコードを自ら生成し、表示部に表示する。なお、携帯端末50が、生成し、表示部に表示するコードは、上述したように、当該携帯端末50による買上商品について精算処理と実行するために必要となる情報(例えば、バスケット識別情報)をコード化したものである。

0085

なお、携帯端末50は、外部から取得したアプリの機能として、クラウドサーバ20と通信する機能や、コード(2次元コード等)を生成する機能を実現する。つまり、携帯端末50は、アプリを起動させることによって、クラウドサーバ20と通信したり、コードを生成したり、表示したりしてもよい。

0086

なお、携帯端末50は、表示部に表示するコードを生成する機能を備えていなくてもよい。例えば、携帯端末50に代えてクラウドサーバ20がコードを生成する機能を備えていてもよい。つまり、クラウドサーバ20は、携帯端末50からの要求に基づいてコードを生成し、生成したコードを携帯端末50に送信し、携帯端末50は、クラウドサーバ20にコードの生成を要求し、クラウドサーバ20によって生成されたコードを受信し、表示部に表示してもよい。

0087

図8は、図5機能構成における、処理の流れの概略を説明するシーケンス図である。具体的には、図8図12図14も同様)は、ある店舗に、ある顧客が来店し、当該店舗に陳列されている商品を登録し、登録した商品の精算が完了する迄における、当該顧客の携帯端末50、当該店舗に設置された精算装置40、データセンタ等の外部に設置されたクラウドサーバ20の夫々の処理の一例を示したものである。図8の左側が、携帯端末50の処理、中央が精算装置40の処理、右側がクラウドサーバ20の処理である。図9は、携帯端末50の表示部における表示例である。図10は、精算装置の表示部における表示例である。

0088

以下、図5図7図9図10等を参照しつつ、図8に示した動作の流れを説明する。
ステップS1:携帯端末50は、店舗を特定する情報(店舗特定情報)を取得する。例えば、店舗の入口付近に当該店舗を特定するための2次元コードを表示(2次元コードを表示画面に出力、2次元コードを印刷した媒体を貼付等)しておき、来店した顧客が、携帯端末50で2次元コードをスキャンする(読み取る)ことにより、携帯端末50は店舗特定情報を取得してもよい。なお、来店した顧客がアプリを起動させると、初期画面として2次元コードのスキャンを該顧客に指示する画面を表示するようにしてもよいし、来店した顧客が携帯端末50で2次元コードをスキャンすると、アプリが起動し、初期画面としてクラウドサーバ20に接続中である旨を該顧客に報知する画面を表示するようにしてもよい。

0089

また例えば、店舗は所在地で特定されるため、来店した顧客が、店舗において携帯端末50で位置情報(GPS情報)を取得してもよい(すなわち、店舗特定情報として当該店舗の位置情報を取得してもよい)。なお、来店した顧客がアプリを起動させると、位置情報を取得し、初期画面としてクラウドサーバ20に接続中である旨を該顧客に報知する画面を表示するようにしてもよい。位置情報から複数店舗が検出され1つに特定できない場合には、選択画面を表示し顧客に選択させるようにしてもよい。もしくは強制的に2次元コードを取得させるモードに切り替えてもよい。

0090

店舗特定情報を取得した携帯端末50は、取引開始要求として、取得した店舗特定情報を顧客識別情報とともにクラウドサーバ20に送信する(図5及び図8の送受信データ「D1」参照)。顧客識別情報については、上述したように、顧客登録の際(携帯端末50にアプリをダウンロード又はインストールする際)に、携帯端末50を用いて登録フォームの氏名欄に入力された情報がクラウドサーバ20の顧客情報に記憶されるが、クラウドサーバ20に加え、携帯端末50の記憶部にも記憶しておいてもよい。なお、店舗が特定された場合には(後述する商品登録初期画面を取得したときには)、当該店舗の店舗名や実施中のサービス(その日に配布されているチラシ情報)、利用可能なクーポン情報を画面(商品登録初期画面又は商品登録初期画面とは別の画面)に表示してもよい。なお、サービスやクーポンの情報は、例えば画面情報としてクラウドサーバ20から取得してもよい。

0091

また、送信先の情報(クラウドサーバ20のアドレス)についても、顧客登録の際(携帯端末50にアプリをダウンロード又はインストールする際)に取得し、携帯端末50の記憶部に記憶しておいてもよい。なお、2次元コードをスキャンする態様とする場合には、店舗特定情報に加え、送信先の情報)についても2次元コード化しておき、携帯端末50で2次元コードをスキャンすることにより、携帯端末50は店舗特定情報とともに送信先の情報も取得してもよい。

0092

ステップS2:携帯端末50から取引開始要求として顧客識別情報及び店舗特定情報を受信したクラウドサーバ20は、当該取引のバスケットを生成する。具体的には、図7(C)に示すようなバスケット情報を生成する。なお、バスケット情報の生成時には、バスケット識別情報、取引開始日時、顧客識別情報は生成されるが、実際の取引(商品登録)の開始前であるため、他の情報(取引終了日時等)は生成されない。

0093

クラウドサーバ20は、上述したように、図7(B)に示したような店舗情報を記憶しているため、携帯端末50から取引開始要求として店舗特定情報を受信(顧客識別情報も受信するが)した場合、受信した店舗特定情報が2次元コードであった場合には、店舗特定情報1を参照して店舗識別情報を取得し、受信した店舗特定情報が位置情報(GPS情報)であった場合には店舗特定情報2を参照して店舗識別情報を取得する。なお、クラウドサーバ20は、携帯端末50から受信した店舗特定情報が店舗識別情報を2次元コード化したものであった場合には、そのまま取得すればよい。

0094

つまり、携帯端末50から取引開始要求として顧客識別情報及び店舗特定情報を受信したクラウドサーバ20は、携帯端末50から受信した店舗特定情報から店舗識別情報を取得し、更に、現在日付を取得し、シリアル番号を発行(採番)し、店舗識別情報と現在日付とシリアル番号とを結合させて、バスケット情報内のバスケット識別情報として記憶する。また、携帯端末50から取引開始要求として店舗特定情報や顧客識別情報を受信したクラウドサーバ20は、現在日時を取得し、バスケット情報内の取引開始日時(生成日時)として記憶する。また、携帯端末50から取引開始要求として店舗特定情報や顧客識別情報を受信したクラウドサーバ20は、携帯端末50から受信した顧客識別情報をバスケット情報内の顧客識別情報として記憶する。

0095

ステップS3:当該取引のバスケットを生成したクラウドサーバ20は、商品登録初期画面情報(初期画面である商品登録画面の画面情報)を生成し、携帯端末50に送信する。具体的には、クラウドサーバ20は、例えば、携帯端末50において図9(A)に示すような商品登録初期画面が表示されるような商品登録初期画面情報を生成し、生成した商品登録初期画面情報をバスケット識別情報とともに携帯端末50に送信する(図5及び図8の送受信データ「D2」参照)。

0096

ステップS4:クラウドサーバ20からバスケット識別情報及び商品登録初期画面情報を受信した携帯端末50は、バスケット識別情報を記憶するとともに、登録画面を表示部に表示する。具体的には、携帯端末50は、例えば図9(A)に示すような商品登録初期画面を表示する。

0097

ステップS5:顧客の操作により携帯端末50は、商品に付されたバーコードをスキャンし、商品コードを読み取る。なお、図8図12図14も同様)では、バーコードのスキャンは成功したものとする。なお、図5では説明の便宜上簡略化したが、ステップS5〜ステップS9は、商品に付されたバーコードをスキャンする毎に繰り返し実行される。

0098

バーコードを取得した携帯端末50は、バスケット識別情報とともに、スキャンによって得られた商品コードをクラウドサーバ20に送信する(図5及び図8の送受信データ「D3」参照)。

0099

ステップS6:携帯端末50からバスケット識別情報及び商品コードを受信したクラウドサーバ20は、バスケット識別情報から当該取引のバスケットを特定する。

0100

ステップS7:クラウドサーバ20は、特定したバスケット内商品データを更新する。具体的には、クラウドサーバ20は、N品目として商品コードを受信した場合には、特定したバスケットのバスケット情報において、当該商品コードを登録商品情報(登録商品N)の商品コードとして記憶し、当該商品コードに対応する品名及び価格を商品情報から取得し、登録商品情報(登録商品N)の商品及び価格して記憶する。また、クラウドサーバ20は、特定したバスケットのバスケット情報において、登録商品情報(計)を更新する。

0101

ステップS8:バスケット内の商品データを更新したクラウドサーバ20は、商品登録更新画面情報(登録した商品が追加された更新画面である商品登録画面の画面情報)を生成し、携帯端末50に送信する。具体的には、クラウドサーバ20は、例えば、携帯端末50において図9(B)に示すような商品登録更新画面が表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末50に送信する(図5及び図8の送受信データ「D4」参照)。

0102

なお、図9(B)に示した商品登録画面(商品登録更新画面)は、3品目の商品として「〇〇食パン」が登録された後に携帯端末50に表示されるものである。つまり、クラウドサーバ20は、1品目として「〇〇ヨーグルト」をバスケット内に記憶したときには、携帯端末50において「〇〇ヨーグルト」が表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末50に送信し、2品目として「〇〇チョコレート」をバスケット内に記憶したときには、携帯端末50において「〇〇ヨーグルト」と「〇〇チョコレート」とが表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末50に送信し、3品目として「〇〇食パン」をバスケット内に記憶したときには、図9(B)に示すように、携帯端末50において「〇〇ヨーグルト」と「〇〇チョコレート」と「〇〇食パン」とが表示されるような商品登録更新画面情報を生成し、生成した商品登録更新画面情報をバスケット識別情報とともに携帯端末50に送信する。

0103

ステップS9:クラウドサーバ20からバスケット識別情報及び商品登録更新画面情報を受信した携帯端末50は、登録画面に商品を追加する。具体的には、携帯端末50は、例えば図9(B)に示すような商品登録更新画面を表示する。なお、上述したように、図9(B)に示した商品登録画面(商品登録更新画面)は、3品目の商品として「〇〇食パン」が登録された後に携帯端末50に表示されるものである。

0104

ステップS10:携帯端末50は、顧客の操作として会計指示を受け付ける。例えば、図9(B)に示した「お会計へ進む」ボタンのタッチを受け付ける。

0105

ステップS11:会計指示を受け付けた携帯端末50は、2次元コードを生成する。つまり、携帯端末50は、当該携帯端末50による買上商品について精算処理を実行するために必要となる情報(例えば、バスケット識別情報)を2次元コード化する。2次元コードを生成した携帯端末50は、生成した2次元コードを表示部に表示する。例えば、図9(C)に示したような2次元コードを表示したコード表示画面を表示部に表示する。

0106

ステップS12:精算装置40は、携帯端末50の表示部に表示されている2次元コードをスキャンする(読み取る)。例えば、精算装置40は、店員によって客側スキャナ部406による認識範囲内に向けられた携帯端末50の表示部に表示されている2次元コードをスキャンする。

0107

ステップS13:携帯端末50の表示部に表示されている2次元コードを読み取った精算装置40は、クラウドサーバ20に小計金額の算出を要求する。例えば、精算装置40は、小計金額の算出を要求する算出要求(小計算出要求情報)を2次元コードから取得したバスケット識別情報とともにクラウドサーバ20に送信する(図5及び図8の送受信データ「D5」参照)。

0108

ステップS14:携帯端末50からバスケット識別情報及び小計算出要求情報を受信したクラウドサーバ20は、バスケット識別情報から当該取引のバスケットを特定する。

0109

ステップS15:バスケットを特定したクラウドサーバ20は、特定したバスケットの小計金額を算出する。具体的には、クラウドサーバ20は、売価決定ロジック(図5参照)を用いて、小計金額を算出する。例えば、バスケットの商品が、図9(B)に示した3品(「〇〇ヨーグルト」、「〇〇チョコレート」、「〇〇食パン」)であって、売価決定ロジックA、B、Cによる割引の何れも適用されない場合には、クラウドサーバ20は、概算金額(図9(B)参照)である830円と同額の830円を小計金額として算出する。また例えば、バスケットの商品が、図9(B)に示した3品(「〇〇ヨーグルト」、「〇〇チョコレート」、「〇〇食パン」)であって、売価決定ロジックBによる割引によって「〇〇ヨーグルト」が30円値引となる場合には、クラウドサーバ20は、概算金額(図9(B)参照)である830円よりも30円安い800円を小計金額として算出する。

0110

ステップS16:小計金額を算出したクラウドサーバ20は、バスケット情報を更新(小計金額(算出後小計金額)を記憶)するとともに、算出した小計金額を示す小計情報をバスケット識別情報とともに精算装置40に送信する(図5及び図8の送受信データ「D6」参照)。

0111

ステップS17:クラウドサーバ20からバスケット識別情報及び小計情報を受信した精算装置40は、客側表示部405に小計金額を表示する。例えば、精算装置40は、小計金額(値引無しの830円)を示す小計情報を受信した精算装置40は、図10(A)に示すような、合計欄に小計金額830を出力した精算画面を客側表示部405に表示する。また例えば、精算装置40は、小計金額(30円値引した800円)を示す小計情報を受信した精算装置40は、図10(B)に示すような、合計欄に小計金額800を出力した精算画面を客側表示部405に表示する。

0112

ステップS18:客側表示部405に小計金額を表示した精算装置40は、支払い(精算)を実行する。具体的には、精算装置40は、決済種別の選択を受け付ける。現金の場合には、預り金の投入を受け付けて、釣り銭金額を算出し、釣り銭がある場合には、釣り銭を放出するとともに、レシートを発行する。また、精算装置40は、精算が完了した場合には、精算完了情報をバスケット情報とともにクラウドサーバ20に送信し、クラウドサーバ20は当該バスケットの取引終了日時(精算日時)を記憶する。

0113

なお、第1の実施形態(第2、第3の実施形態も同様)では、クラウドサーバ20は、売価決定ロジックH(決済種別値引価格算出機能)を有しないため、説明を省略したが、売価決定ロジックH(決済種別値引価格算出機能)を有する場合には、決済種別の選択後に、小計金額を再計算するようにしてもよい。具体的には、精算装置40は、決済種別の選択後に、クラウドサーバ20に小計金額の算出を再度要求し(例えば、選択された決済種別を示す決済種別選択情報をバスケット識別情報とともにクラウドサーバ20に送信し、クラウドサーバ20は、売価決定ロジックHを用いて小計金額を再度算出し、再度算出した小計金額を示す小計情報をバスケット識別情報とともに精算装置40に再度送信してもよい。あるいは、小計金額の算出が1回で済むように、ステップS13の算出要求以前(例えば、携帯端末50にて2次元コードを生成する前、精算装置40にて2次元コードの読取後に算出要求の送信前等)に決済種別の選択を顧客に求めるようにし、ステップS13の算出要求の際に決済種別選択情報もクラウドサーバ20に送信するようにしてもよい。

0114

(個々の商品登録時のチェック
なお、携帯端末50は、商品をスキャンした後に商品コードをクラウドサーバ20に送信するが(S5)、当該店舗(来店して商品登録初期画面を表示したときの店舗)内においてスキャンした商品以外の商品(例えば、他の店舗に移動してスキャンした商品等)について商品コードを送信しないようにしてもよい。例えば、携帯端末50は、来店時(又は商品登録初期画面の表示時)に位置情報(GPS情報)を取得し、記憶する。また、携帯端末50は、個々の商品をスキャンしたときに位置情報を取得し、商品のスキャン時に取得した位置情報と来店時(又は商品登録初期画面の表示時)に取得した位置情報とを比較する。そして、携帯端末50は、両者が一致(または略一致)した場合には当該商品の商品コードのクラウドサーバ20への送信を許可し、一致(又は略一致)しなかった場合には当該商品の商品コードのクラウドサーバ20への送信を禁止してもよい。第2、第3の実施形態についても同様である。
これにより、不適切な商品登録(例えば、他の店舗等において生成されたバスケットに対する商品登録等)を防止することができる。

0115

精算装置40は、上述のように商品コードの送信を禁止した場合には、商品のスキャン後にエラーメッセージ(例えば、「〇〇店舗内ではないため、登録ができません」)を客側表示部405に表示してもよい。また、精算装置40は、上記メッセージを客側表示部405に代えて又は加えて店員側表示部410に表示してもよい。

0116

(2次元コードの読取時のチェック)
また、精算装置40は、携帯端末50の表示部に表示されている2次元コードを読み取った後にクラウドサーバ20に小計金額の算出を要求するが(S12)、当該店舗内においてスキャンした商品以外の商品(例えば、他の店舗でスキャンした商品等)について小計金額の算出を要求しないようにしてもよい。例えば、精算装置40は、当該店舗の店舗識別情報を参照し(自精算装置40内に当該店舗の店舗識別情報を記憶し参照してもよいし、アクセス可能な他の装置内に記憶されている店舗識別情報を参照してもよい)、携帯端末50の表示部に表示されている2次元コードを読み取ったときに、当該2次元コードから得られるバスケット識別情報と、当該店舗の店舗識別情報とを比較する。そして、精算装置40は、バスケット識別情報に含まれる店舗識別情報(図7(B)のバスケット識別情報の構成を参照)が、当該店舗の店舗識別情報を含む構成である場合には小計金額の算出の要求を許可し、当該店舗の店舗識別情報を含む構成でない場合には小計金額の算出の要求を禁止してもよい。第2、第3の実施形態についても同様である。
これにより、不適切な精算(例えば、他の店舗等において商品登録された商品の精算等)を防止することができる。

0117

精算装置40は、上述のように小計金額の要求を禁止した場合には、2次元コードの読取後にエラーメッセージ(例えば、「〇〇店舗以外の商品を含むため、精算ができません」)を客側表示部405に表示してもよい。また、精算装置40は、上記メッセージを客側表示部405に代えて又は加えて店員側表示部410に表示してもよい。

0118

(第2の実施形態)
続いて、第2の実施形態について説明する。以下では、第2の実施形態について、主に第1の実施形態との差分について説明し、第1の実施形態と共通する部分については説明の一部又は全部を省略する。例えば、図1図4図6図7図9図10を用いて説明した内容は、各実施形態(第1〜第3の実施形態)で共通するため、説明を省略する。

0119

図11は、第2の実施形態のショッピングシステムを説明するための各機能の概念図である。なお、図11は、本発明の第2の実施形態に係るショッピングシステムを説明するためのものであり、本発明の第2の実施形態に係るショッピングシステムは、図11に示した全部の構成を必ずしも含むものではない。例えば、本発明の第2の実施形態に係るショッピングシステムは、クラウドサーバ20と精算装置40(精算装置41)とから構成されるものであってもよいし、クラウドサーバ20単体であってもよいし、精算装置40(精算装置41)単体であってもよい。また、図11は、本発明の第2の実施形態に係るショッピングシステムの特徴部分に関連する機能を抜粋して説明するものであり、一般にショッピングシステムに必要とされる機能を網羅的に説明するものではない。

0120

(精算装置30(精算装置31))
図11の右下に示すように、精算装置30は、売価決定ロジック(売価決定機能)、精算機能を備える。図11に示した例では、精算装置30は、売価決定ロジックA、売価決定ロジックB、売価決定ロジックC、売価決定ロジックD、売価決定ロジックGを備えている。すなわち、第2の実施形態において説明する精算装置30(図11参照)と、第1の実施形態において説明した精算装置30(図5参照)との差異は、第1の実施形態において説明した精算装置30が、売価決定ロジックA、売価決定ロジックBを備えるのに対し、第2の実施形態において説明する精算装置30は、売価決定ロジックA、売価決定ロジックBに加えて、売価決定ロジックC、売価決定ロジックD、売価決定ロジックGを備えている点である。なお、以下、第1の実施形態において説明した精算装置30と区別するため、便宜上、第2の実施形態において説明する精算装置30を精算装置31と称するものとする。

0121

(管理装置10(管理装置11))
図11の右上に示すように、管理装置10は、店舗情報、商品情報を記憶する。管理装置10は、売価決定ロジックを備えていてもよい。すなわち、第2の実施形態において説明する管理装置10(図11参照)と、第1の実施形態において説明した管理装置10(図5参照)との差異は、第1の実施形態において説明した管理装置10が、売価決定ロジックA、売価決定ロジックBを備えていてもよいのに対し、第2の実施形態において説明する管理装置10は、売価決定ロジックA、売価決定ロジックBに加えて、売価決定ロジックC、売価決定ロジックD、売価決定ロジックGを備えていてもよい点である。なお、以下、第1の実施形態において説明した管理装置10と区別するため、便宜上、第2の実施形態において説明する管理装置10を管理装置11と称するものとする。

0122

(クラウドサーバ20)
図11の左上に示すように、クラウドサーバ20は、売価決定ロジック(売価決定機能)を備える。図11に示した例では、クラウドサーバ20は、売価決定ロジックA、売価決定ロジックB、売価決定ロジックCを備えている。また、クラウドサーバ20は、顧客情報、店舗情報、商品情報、バスケット情報を記憶する。なお、第2の実施形態において説明するクラウドサーバ20(図11参照)と、第1の実施形態において説明したクラウドサーバ20(図5参照)との差異はないが、第2の実施形態において説明するクラウドサーバ20は、具備する売価決定ロジックA、売価決定ロジックB、売価決定ロジックCを使用しない。

0123

(精算装置40(精算装置41))
図11の左下に示すように、精算装置40は、クラウド通信機能、携帯端末連動機能、精算機能を備える。また、精算装置40は、売価決定ロジックA、売価決定ロジックB、売価決定ロジックCを備える。すなわち、第2の実施形態において説明する精算装置40(図11参照)と、第1の実施形態において説明した精算装置40(図5参照)との差異は、第1の実施形態において説明した精算装置40が、売価決定ロジックを備えていないのに対し、第2の実施形態において説明する精算装置40は、売価決定ロジックA、売価決定ロジックB、売価決定ロジックC、売価決定ロジックD、売価決定ロジックGを備えている点である。なお、以下、第1の実施形態において説明した精算装置40と区別するため、便宜上、第2の実施形態において説明する精算装置40を精算装置41と称するものとする。

0124

(携帯端末50)
図11の左下に示すように、携帯端末50は、クラウドサーバ20と通信する。携帯端末50は、クラウドサーバ20と通信することにより商品を登録する。また、携帯端末50は、表示部に表示するコードを自ら生成し、表示部に表示する。なお、第2の実施形態において説明する携帯端末50(図11参照)と、第1の実施形態において説明した携帯端末50(図5参照)との差異はない。

0125

図11の送受信データ「D0」〜「D4」は、図5の送受信データ「D0」〜「D4」と同様である。また。図11の送受信データ「D15」、「D16」は、図12にて説明する。

0126

図12は、図11の機能構成における、処理の流れの概略を説明するシーケンス図である。具体的には、図12は、図8の場面と同様、ある店舗に、ある顧客が来店し、当該店舗に陳列されている商品を登録し、登録した商品の精算が完了する迄における、当該顧客の携帯端末50、当該店舗に設置された精算装置41、データセンタ等の外部に設置されたクラウドサーバ20の夫々の処理の一例を示したものである。図12の左側が、携帯端末50の処理、中央が精算装置41の処理、右側がクラウドサーバ20の処理である。

0127

なお、図12のステップS101〜S112は、図8のステップS1〜S12と同様であるため、説明を省略する。

0128

ステップS113:携帯端末50の表示部に表示されている2次元コードをスキャンした精算装置41は、クラウドサーバ20にバスケット内の商品データを要求する。例えば、精算装置41は、バスケット内の商品データを要求する商品データ要求情報を2次元コードから取得したバスケット識別情報とともにクラウドサーバ20に送信する(図11及び図12の送受信データ「D15」参照)。

0129

ステップS114:携帯端末50からバスケット識別情報及び商品データ要求情報を受信したクラウドサーバ20は、バスケット識別情報から当該取引のバスケットを特定する。

0130

ステップS115:クラウドサーバ20は、特定したバスケットの商品データをバスケット識別情報とともに精算装置41に送信する(図11及び図12の送受信データ「D16」参照)。

0131

ステップS116:クラウドサーバ20からバスケット識別情報及び商品データを受信した精算装置41は、小計金額を算出する。具体的には、精算装置41は、売価決定ロジック(図11参照)を用いて、小計金額を算出する。

0132

ステップS117:小計金額を算出した精算装置41は、客側表示部405に小計金額を表示する。
ステップS118:客側表示部405に小計金額を表示した精算装置41は、支払い(精算)を実行する。

0133

なお、図12では省略しているが、小計金額を算出した精算装置41は、算出した小計金額を示す小計情報をバスケット識別情報とともにクラウドサーバ20に送信する。また、精算装置41からバスケット識別情報及び小計情報を受信したクラウドサーバ20は、バスケット情報を更新(小計金額(算出後小計金額)を記憶)する。

0134

(第3の実施形態)
続いて、第3の実施形態について説明する。以下では、第3の実施形態について、主に第1の実施形態や第2の実施形態との差分について説明し、第1の実施形態や第2の実施形態と共通する部分については説明の一部又は全部を省略する。例えば、図1図4図6図7図9図10を用いて説明した内容は、各実施形態(第1〜第3の実施形態)で共通するため、説明を省略する。

0135

図13は、第3の実施形態のショッピングシステムを説明するための各機能の概念図である。なお、図13は、本発明の第3の実施形態に係るショッピングシステムを説明するためのものであり、本発明の第3の実施形態に係るショッピングシステムは、図13に示した全部の構成を必ずしも含むものではない。例えば、本発明の第3の実施形態に係るショッピングシステムは、クラウドサーバ20(クラウドサーバ21)と精算装置40とから構成されるものであってもよいし、クラウドサーバ20(クラウドサーバ21)単体であってもよいし、精算装置40単体であってもよい。また、図13は、本発明の第3の実施形態に係るショッピングシステムの特徴部分に関連する機能を抜粋して説明するものであり、一般にショッピングシステムに必要とされる機能を網羅的に説明するものではない。

0136

(精算装置30(精算装置31))
図13の右下に示すように、図13の精算装置30は、第2の実施形態において説明した精算装置31(図11参照)と同一である。

0137

(管理装置10(管理装置12))
図13の右上に示すように、図13の管理装置10は、店舗情報、商品情報を記憶する。また、図13の管理装置10は、売価決定ロジックを備える。具体的には、図13の管理装置10は、売価決定ロジックA、売価決定ロジックB、売価決定ロジックC、売価決定ロジックD、売価決定ロジックGを備える。また、図13の管理装置10は、外部連携機能を備える。管理装置10の外部連携機能は、例えば、売価決定に関してクラウドサーバ20(21)と連携(通信)する機能である。具体的には、管理装置10の外部連携機能は、クラウドサーバ20(21)の外部連携機能から送信される小計金額の算出要求(図14の送受信データ「D26」参照)を受信する機能、当該要求に基づいて売価決定ロジックを用いて算出した小計金額(図14の送受信データ「D6」参照)をクラウドサーバ20(21)の外部連携機能に対して送信する機能を含む。以下、第1の実施形態において説明した管理装置10や第2の実施形態において説明した管理装置11と区別するため、便宜上、第3の実施形態において説明する管理装置11を管理装置12と称するものとする。

0138

(クラウドサーバ20(クラウドサーバ21))
図13の左上に示すように、クラウドサーバ20は、売価決定ロジック(売価決定機能)、外部連携機能を備える。図13に示した例では、クラウドサーバ20は、売価決定ロジックA、売価決定ロジックB、売価決定ロジックCを備えている。クラウドサーバ20の外部連携機能は、例えば、売価決定に関して管理装置12と連携(通信)する機能である。具体的には、クラウドサーバ20の外部連携機能は、小計金額の算出要求(図14の送受信データ「D26」参照)を管理装置12の外部連携機能に対して送信する機能、管理装置12の外部連携機能から送信される小計金額(図14の送受信データ「D6」参照)を受信する機能を含む。また、クラウドサーバ20は、顧客情報、店舗情報、商品情報、バスケット情報を記憶する。また、第3の実施形態において説明するクラウドサーバ20は、具備する売価決定ロジックA、売価決定ロジックB、売価決定ロジックCを使用しない。以下、第1、第2の実施形態において説明したクラウドサーバ20と区別するため、便宜上、第3の実施形態において説明するクラウドサーバ20をクラウドサーバ21と称するものとする。

0139

(精算装置40)
図13の左下に示すように、図13の精算装置40は、第1の実施形態において説明した精算装置40(図5参照)と差異はない。

0140

(携帯端末50)
図13の左下に示すように、図13の携帯端末50は、第1、第2の実施形態において説明した携帯端末50(図5図11参照)と差異はない。

0141

図13の送受信データ「D0」〜「D6」は、図5の送受信データ「D0」〜「D6」と同様である。図13の送受信データ「D26」は、図14にて説明する。

0142

図14は、図13の機能構成における、処理の流れの概略を説明するシーケンス図である。具体的には、図14は、図8図12の場面と同様、ある店舗に、ある顧客が来店し、当該店舗に陳列されている商品を登録し、登録した商品の精算が完了する迄における、当該顧客の携帯端末50、当該店舗に設置された精算装置40、データセンタ等の外部に設置されたクラウドサーバ21の夫々の処理の一例を示したものである。図14の左側が、携帯端末50の処理、中央が精算装置40の処理、右側がクラウドサーバ21の処理である。

0143

なお、図14のステップS201〜S214は、図8のステップS1〜S14と同様であるため、説明を省略する。

0144

ステップS215:バスケットを特定したクラウドサーバ21は、管理装置12に小計金額の算出を要求する。例えば、クラウドサーバ21は、小計金額の算出を要求する算出要求(小計算出要求情報)を、ステップS214にて特定したバスケットの商品データ、及び、バスケット識別情報とともに、管理装置12に送信する(図13及び図14の送受信データ「D26」参照)。

0145

ステップS216:クラウドサーバ21からバスケット識別情報、小計算出要求情報及び商品データを受信した管理装置12は、小計金額を算出する。具体的には、管理装置12は、売価決定ロジック(図13参照)を用いて、小計金額を算出する。

0146

ステップS217:小計金額を算出した管理装置12は、算出した小計金額を示す小計情報をバスケット識別情報とともにクラウドサーバ21に送信する(図13及び図14の送受信データ「D6」参照)。

0147

ステップS218:管理装置12からバスケット識別情報及び小計情報を受信したクラウドサーバ21は、バスケット情報を更新(小計金額(算出後小計金額)を記憶)するとともに、管理装置12から受信したバスケット識別情報及び小計情報を精算装置40に送信する(図13及び図14の送受信データ「D6」参照)。

0148

ステップS219:クラウドサーバ21からバスケット識別情報及び小計情報を受信した精算装置40は、客側表示部405に小計金額を表示する。
ステップS220:客側表示部405に小計金額を表示した精算装置40は、支払い(精算)を実行する。

0149

なお、ステップS215〜S216、ステップS217〜S218における各種情報(送受信データ「D26」、送受信データ「D6」)の送受信は、クラウドサーバ21側の外部連携機能、管理装置12側の外部連携機能によって実現される。

0150

以下、より詳細な動作の流れについて説明する。
図15及び図16は、商品登録時における、より詳細な動作の流れの一例を示すフローチャートである。具体的には、図15及び図16は、第1の実施形態として説明した図8のステップS5〜S11、第2の実施形態として説明した図12のステップS105〜S111、第3の実施形態として説明した図14のステップS205〜S211の範囲について、保留商品やキャンセルがある場合を考慮して説明したものである。図16図15続きである。なお、図8等にて説明した内容の一部については説明を省略している。

0151

ステップS30:携帯端末50は、商品に付されたバーコードをスキャンする操作があったか否かを判断する。例えば、携帯端末50は、各種センサ(例えば、ジャイロセンサ、加速度センサ、距離センサ等)を備え、当該携帯端末50がバーコードを読み取る姿勢になったと各種センサが判断してから所定時間継続して当該姿勢を維持したと判断した場合(つまり所定時間以上、バーコードを読み取る姿勢を維持した場合)、または、所定時間内にバーコードを読み取った場合に(つまり、商品コードを取得した場合に)、商品に付されたバーコードをスキャンする操作があったと判断する。バーコードをスキャンする操作があったと判断した場合には携帯端末50の処理としてはステップS31に進む。バーコードをスキャンする操作がなかったと判断した場合には携帯端末50の処理としては図16のステップS50に進む。

0152

ステップS31:携帯端末50は、商品コードの読み取りに成功したか否かを判断する。商品コードの読み取りに成功したと判断した場合には携帯端末50の処理としてはステップS32に進む。商品コードの読み取りに失敗したと判断した場合には携帯端末50の処理としてはステップS45に進む。

0153

ステップS32:携帯端末50は、バスケット識別情報とともに、スキャンによって得られた商品コードをクラウドサーバ20(21)に送信する。そして携帯端末50の処理としてはステップS41に進む。

0154

ステップS33:クラウドサーバ20(21)は、バスケット識別情報及び商品コードを受信したか否かを判断する。バスケット識別情報及び商品コードを受信した場合にはクラウドサーバ20(21)の処理としてはステップS34に進む。バスケット識別情報及び商品コードを受信していない場合にはクラウドサーバ20(21)の処理としてはステップS48に進む。

0155

ステップS34:クラウドサーバ20(21)は、当該店舗の商品情報を参照する。具体的には、クラウドサーバ20(21)は、当該店舗の商品情報を参照し、携帯端末50から受信した商品コードの商品を特定する(特定しようとする)。つまり、クラウドサーバ20(21)は、当該店舗の商品情報内に、携帯端末50から受信した商品コードが記憶されているかを確認する。そしてクラウドサーバ20(21)の処理としてはステップS35に進む。

0156

ステップS35:携帯端末50から受信した商品コードの商品を特定できた場合にはクラウドサーバ20(21)の処理としてはステップS36に進む。携帯端末50から受信した商品コードの商品を特定できなかった場合にはクラウドサーバ20(21)の処理としてはステップS38に進む。

0157

ステップS36:クラウドサーバ20(21)は、バスケットに登録商品情報を記憶する。具体的には、クラウドサーバ20(21)は、登録商品情報として、商品コード、品名、価格等を記憶する。そしてクラウドサーバ20(21)の処理としてはステップS37に進む。
ステップS37:クラウドサーバ20(21)は、商品登録更新画面情報(ステップS36の登録商品情報が反映された商品登録画面の画面情報)を生成し、携帯端末50に送信する。そしてクラウドサーバ20(21)の処理としてはステップS48に進む。

0158

ステップS38:クラウドサーバ20(21)は、バスケットに保留商品情報を記憶する。具体的には、クラウドサーバ20(21)は、保留商品情報として、保留商品種別「1(NON−PLU)」、商品コードを記憶する。そしてクラウドサーバ20(21)の処理としてはステップS39に進む。
ステップS39:クラウドサーバ20(21)は、商品登録更新画面情報(ステップS38の保留商品情報が反映された商品登録画面の画面情報)を生成し、携帯端末50に送信する。そしてクラウドサーバ20(21)の処理としてはステップS40に進む。
ステップS40:クラウドサーバ20(21)は、エラーメッセージ(NO−FILE)を、携帯端末50に送信する。そしてクラウドサーバ20(21)の処理としてはステップS48に進む。

0159

ステップS41:携帯端末50は、エラーメッセージを受信したか否かを判断する。エラーメッセージを受信したと判断した場合には携帯端末50の処理としてはステップS43に進む。エラーメッセージを受信していないと判断した場合には携帯端末50の処理としてはステップS42に進む。

0160

ステップS42:携帯端末50は、登録画面を更新する。つまり、携帯端末50の表示部には、ステップS30のスキャン操作を反映した登録画面(スキャン操作した商品が追加表示された登録画面)が表示される。そして携帯端末50の処理としては図16のステップS50に進む。

0161

ステップS43:携帯端末50は、登録画面を更新する。つまり、携帯端末50の表示部には、ステップS30のスキャン操作を反映した登録画面(スキャン操作した商品が保留商品(NO−FILE)として追加表示された登録画面)が表示される。そして携帯端末50の処理としてはステップS44に進む。
ステップS44:携帯端末50は、エラーメッセージを表示する。具体的には、携帯端末50は、ステップS30にてスキャン操作を行った商品が保留商品(NO−FILE)である旨のエラーメッセージを表示する。なお、携帯端末50は、保留商品(NO−FILE)である旨のエラーメッセージに代えて又は加えて、買物カゴの中で保留商品を保留商品以外の商品と分けて入れておく旨を指示するメッセージを表示してもよい。そして携帯端末50の処理としては図16のステップS50に進む。

0162

ステップS45:携帯端末50は、商品(商品コードの読み取りに失敗した商品)を撮像し、バスケット識別情報とともに、撮像画像(画像データ)をクラウドサーバ20(21)に送信する。携帯端末50は、撮像画像をクラウドサーバ20(21)に送信することに加えて、撮像画像を記憶部に記憶してもよい。そして携帯端末50の処理としてはステップS46に進む。
ステップS46:携帯端末50は、登録画面を更新する。つまり、携帯端末50の表示部には、ステップS30のスキャン操作を反映した登録画面(スキャン操作した商品が保留商品(読取NG)として追加表示された登録画面)が表示される。そして携帯端末50の処理としてはステップS47に進む。

0163

ステップS47:携帯端末50は、エラーメッセージを表示する。具体的には、携帯端末50は、ステップS30にてスキャン操作を行った商品が保留商品(読取NG)である旨のエラーメッセージを表示する。なお、携帯端末50は、保留商品(NG)である旨のエラーメッセージに代えて又は加えて、買物カゴの中で保留商品を保留商品以外の商品と分けて入れておく旨を指示するメッセージを表示してもよい。そして携帯端末50の処理としては図16のステップS50に進む。

0164

ステップS48:クラウドサーバ20(21)は、画像データを受信したか否かを判断する。画像データを受信した場合にはクラウドサーバ20(21)の処理としてはステップS49に進む。画像データを受信していない場合にはクラウドサーバ20(21)の処理としては図16のステップS52に進む。

0165

ステップS49:クラウドサーバ20(21)は、バスケットに保留商品情報を記憶する。具体的には、クラウドサーバ20(21)は、保留商品情報として、保留商品種別「1(読取NG)」、ステップS48にて受信した画像データを記憶する。そしてクラウドサーバ20(21)の処理としては図16のステップS52に進む。

0166

ステップS50:携帯端末50は、登録済の商品(ステップS36においてバスケット内に登録商品情報が記憶された商品)をキャンセルする操作(例えば、登録画面上に表示されている商品をタッチにより選択し、選択後に表示されるキャンセルボタンをタッチする操作等)があったか否かを判断する。登録済の商品をキャンセルする操作があったと判断した場合には携帯端末50の処理としてはステップS51に進む。登録済の商品をキャンセルする操作がなかったと判断した場合には携帯端末50の処理としてはステップS60に進む。

0167

ステップS51:携帯端末50は、バスケット識別情報とともに、商品キャンセル情報をクラウドサーバ20(21)に送信する。商品キャンセル情報は、例えば、キャンセルする商品の商品コード、数量等を含む。そして携帯端末50の処理としてはステップS56に進む。なお、携帯端末50が、キャンセルする商品の商品コードを取得する方法としては種々の方法が考えられるが、例えば、クラウドサーバ20(21)が携帯端末50に送信する商品登録更新画面情報内に登録済の商品の商品コードが格納(記憶)され、携帯端末50は商品登録更新画面情報からキャンセルする商品の商品コードを取得してもよい。

0168

ステップS52:クラウドサーバ20(21)は、バスケット識別情報及びキャンセル情報を受信したか否かを判断する。バスケット識別情報及びキャンセル情報を受信した場合にはクラウドサーバ20(21)の処理は終了する。なお、クラウドサーバ20(21)の処理としては、終了後に再度、図15のステップS33から開始される。バスケット識別情報及びキャンセル情報を受信した場合にはクラウドサーバ20(21)の処理としてはステップS53に進む。

0169

ステップS53:クラウドサーバ20(21)は、バスケットの登録商品情報を削除する。具体的には、クラウドサーバ20(21)は、バスケット識別情報及びキャンセル情報によって示されるバスケット内の商品登録情報を削除する。そしてクラウドサーバ20(21)の処理としてはステップS54に進む。なお、クラウドサーバ20(21)は、複数個登録された登録済の商品のうちの一部をキャンセルするキャンセル情報を受信した場合には当該登録済の商品の個数を更新する。例えば、5個登録された登録済の商品のうちの2個をキャンセルするキャンセル情報を受信した場合には当該登録済の商品の個数を5個から3個に更新する。

0170

ステップS54:クラウドサーバ20(21)は、バスケットにキャンセル情報を記憶する。具体的には、クラウドサーバ20(21)は、キャンセル情報として、商品コード、数量等を記憶する。そしてクラウドサーバ20(21)の処理としてはステップS55に進む。

0171

ステップS55:クラウドサーバ20(21)は、商品登録更新画面情報(ステップS53の登録商品情報を削除やステップS54のキャンセル情報が反映された商品登録画面の画面情報)を生成し、携帯端末50に送信する。そしてクラウドサーバ20(21)の処理は終了する。なお、クラウドサーバ20(21)の処理としては、終了後に再度、図15のステップS33から開始される。

0172

ステップS56:携帯端末50は、登録画面を更新する。つまり、携帯端末50の表示部には、ステップS50のキャンセル操作を反映した登録画面(登録済の商品が削除された登録画面、登録済の商品の個数が減少した登録画面)が表示される。そして携帯端末50の処理としてはステップS60に進む。

0173

ステップS60:携帯端末50は、会計指示(例えば、図9(B)に示した「お会計へ進む」ボタンのタッチ)があったか否かを判断する。会計指示があったと判断した場合にはステップS61に進む。会計指示がなかったと判断した場合にはステップS30に戻る。

0174

ステップS61:携帯端末50は、2次元コードを生成する。つまり、携帯端末50は、当該携帯端末50による買上商品について精算処理を実行するために必要となる情報(例えば、バスケット識別情報)を2次元コード化する。そして携帯端末50の処理としてはステップS62に進む。
ステップS62:携帯端末50は、ステップS61にて生成した2次元コードを表示部に表示する。そして携帯端末50の処理は終了する。

0175

図17は、精算時における、より詳細な動作の流れの一例を示すフローチャートである。具体的には、図17は、第1の実施形態として説明した図8のステップS12〜S18の範囲について、保留商品やキャンセルがある場合を考慮して説明したものである。なお、図8にて説明した内容の一部については説明を省略している。

0176

ステップS70:精算装置40は、携帯端末50の表示部に表示されている2次元コードの読み取ったか否かを判断する。2次元コードの読み取ったと判断した場合にはステップS71に進む。2次元コードの読み取っていないと判断した場合にはステップS70を繰り返し実行する。
ステップS71:精算装置40は、クラウドサーバ20に小計金額の算出を要求する。例えば、精算装置40は、小計金額の算出を要求する算出要求(小計算出要求情報)を2次元コードから取得したバスケット識別情報とともにクラウドサーバ20に送信する。

0177

ステップS72:クラウドサーバ20は、バスケット識別情報及び小計算出要求情報を受信したか否かを判断する。バスケット識別情報及び小計算出要求情報を受信した場合にはステップS73に進む。バスケット識別情報及び小計算出要求情報を受信していない場合にはステップS71を繰り返し実行する。

0178

ステップS73:クラウドサーバ20は、精算装置40が小計金額の算出を要求しているバスケットを特定する。具体的には、クラウドサーバ20は、精算装置40から受信したバスケット識別情報から、精算装置40が小計金額の算出を要求しているバスケットを特定する。そしてクラウドサーバ20の処理としてはステップS74に進む。
ステップS74:クラウドサーバ20は、小計金額の算出を要求している顧客(当該バスケットに係る顧客)を特定する。具体的には、クラウドサーバ20は、ステップS72において特定したバスケット内の顧客識別情報から、小計金額の算出を要求している顧客を特定する。そしてクラウドサーバ20の処理としてはステップS75に進む。

0179

ステップS75:クラウドサーバ20は、小計金額の算出を要求している顧客(ステップS74にて特定した顧客)のキャンセルの状況を確認する。具体的には、クラウドサーバ20は、当該顧客の顧客情報(図7(A)参照)のキャンセル情報を参照して、当該顧客の過去のキャンセルの状況を確認する。なお、クラウドサーバ20は、当該顧客の顧客情報(図7(A)参照)のキャンセル情報に代えて又は加えて、当該バスケット情報(図7(C))のキャンセル情報(キャンセル情報(今回の合計)等)を参照し、当該顧客の今回のキャンセルの状況を確認してもよい。そしてクラウドサーバ20の処理としてはステップS76に進む。

0180

ステップS76:クラウドサーバ20は、確認したキャンセルの状況に基づいて、警告が必要か否かを判断する。例えば、ステップS75にて過去のキャンセルの状況を確認する態様では、例えば、クラウドサーバ20は、過去2回(前回来店時、前々回の来店時)の合計のキャンセル回数と、所定の閾値(閾値Aとする)とを比較し、過去2回の合計のキャンセル回数が閾値A以上である場合には警告が必要であると判断し、過去2回の合計のキャンセル回数が閾値A未満である場合には警告が不要であると判断してもよい。また例えば、ステップS75にて今回のキャンセルの状況と過去のキャンセルの状況の両方を確認する態様では、例えば、クラウドサーバ20は、今回のキャンセルの回数と、所定の閾値(閾値Bとする)とを比較し、また、過去2回の合計のキャンセル回数と、所定の閾値(閾値Cとする)とを比較し、今回のキャンセル回数が閾値B以上かつ過去2回の合計のキャンセル回数が閾値C以上である場合には警告が必要であると判断し、他の場合(今回のキャンセル回数が閾値B未満である場合(過去2回の合計のキャンセル回数は問わない)、今回のキャンセル回数が閾値B以上であるが過去2回の合計のキャンセル回数が閾値C未満である場合)には警告が不要であると判断してもよい。また例えば、ステップS75にて今回のキャンセルの状況を確認する態様では、例えば、クラウドサーバ20は、今回のキャンセル回数と、所定の閾値(閾値Dとする)とを比較し、今回のキャンセル回数が閾値D以上である場合には警告が必要であると判断し、今回のキャンセル回数が閾値D未満である場合には警告が不要であると判断してもよい。なお、閾値A〜Dは、何れも互いに異なる数であってもよいし、2つ以上が同じ数であってもよい。警告が必要であると判断した場合にはステップS77に進む。警告が必要でない(不要である)と判断した場合にはステップS80に進む。

0181

ステップS77:クラウドサーバ20は、警告情報を精算装置40に送信する。そしてクラウドサーバ20の処理としてはステップS80に進む。

0182

ステップS78:精算装置40は、警告情報を受信したか否かを判断する。警告情報を受信した場合にはステップS79に進む。警告情報を受信していない場合にはステップS82に進む。
ステップS79:精算装置40は、警告する。例えば、精算装置40は、店員が商品の内容を確認する旨のメッセージを客側表示部406に表示してもよい。また、精算装置40は、上記に代えて又は加えて、商品のキャンセルについて確認すべきる旨のメッセージを店員側表示部410に表示してもよい。なお、精算装置40は、具体的な数値を用いたメッセージ(例えば、ステップS75にて過去のキャンセルの状況を確認した場合には当該顧客についてキャンセル実績が基準以上の〇〇回である旨のメッセージや、ステップS75にて今回のキャンセルの状況を確認した場合には当該顧客について本取引のキャンセルが基準以上の〇〇回である旨のメッセージ)を店員側表示部410に表示してもよい。

0183

ステップS80:クラウドサーバ20は、バスケット情報内に保留商品(NON−PLU、読取NG)があるか否か判断する。保留商品があると判断した場合にはステップS81に進む。保留商品がないと判断した場合にはステップS88に進む。
ステップS81:クラウドサーバ20は、バスケット情報内に保留商品について修正を指示する情報(修正指示情報)を精算装置40に送信する。そしてクラウドサーバ20の処理としてはステップS86に進む。

0184

ステップS82:精算装置40は、修正指示情報を受信したか否かを判断する。修正指示情報を受信した場合にはステップS83に進む。修正指示情報を受信していない場合にはステップS90に進む。

0185

ステップS83:精算装置40は、保留商品がある旨を報知する。例えば、精算装置40は、客側表示部405、店員側表示部410のいずれか一方又は両方において、保留商品がある旨のメッセージを表示する。例えば、精算装置40は、店員が商品の内容を確認する旨のメッセージ(図10(C)参照)を表示した小画面を客側表示部406に表示してもよい。また、精算装置40は、上記に代えて又は加えて、保留商品がある旨のメッセージを店員側表示部410に表示してもよい。そして精算装置40の処理としてはステップS84に進む。

0186

ステップS84:精算装置40は、店員による保留商品の修正を受け付ける。例えば、保留商品(読取NG)について、店員による当該商品(例えば陳列棚にある同一商品)のスキャンを行う。また例えば、保留商品(NON−PLU)について、店員による価格の入力を行う。保留商品(読取NG、NON−PLU)について、店員がキャンセルしてもよい。つまり、いずれの方法であっても、店員による保留商品の修正を受け付けることによって保留商品がなくなるようにすればよい。なお、店員によるキャンセルは、バスケット情報内の今回のキャンセル回数に(顧客情報内の過去のキャンセル回数はバスケット情報内の今回のキャンセル回数に基づくものであるため結果として顧客情報内の過去のキャンセル回数にも)に反映されないようにしてもよい。一例として、店員によるキャンセル操作を特別なキャンセル操作(顧客によって行われるキャンセル操作と異なる操作)とし、特別なキャンセル操作が行われた場合には、今回のキャンセル回数に反映されないようにしてもよい。
ステップS85:精算装置40は、店員による保留商品の修正内容を示した修正情報をバスケット識別情報とともにクラウドサーバ20に送信する。そして精算装置40の処理としてはステップS90に進む。

0187

ステップS86:クラウドサーバ20は、バスケット識別情報及び修正情報を受信したか否かを判断する。バスケット識別情報及び修正情報を受信した場合にはステップS87に進む。バスケット識別情報及び修正情報を受信していない場合にはステップS86を繰り返し実行する。
ステップS87:クラウドサーバ20は、修正情報に従ってバスケットの情報を更新する。そしてクラウドサーバ20の処理としてはステップS88に進む。

0188

ステップS88:クラウドサーバ20は、バスケットの小計金額を算出する。そしてクラウドサーバ20の処理としてはステップS89に進む。
ステップS89:クラウドサーバ20は、バスケット情報を更新(小計金額(算出後小計金額)を記憶)するとともに、算出した小計金額を示す小計情報をバスケット識別情報とともに精算装置40に送信する。そしてクラウドサーバ20の処理は終了する。

0189

ステップS90:精算装置40は、客側表示部405に小計金額を表示する。
ステップS91:精算装置40は、支払い(精算)を実行する。そして精算装置40の処理は終了する。なお、ステップS91の処理の終了時には、精算が完了した旨の情報をクラウドサーバ20に送信する。

0190

図18は、バスケット情報内に記憶される情報の一例である。なお、図18は、図7(C)に示したバスケット情報の一部を示している。

0191

図18(A)は、1品目の商品(「〇〇ヨーグルト」)が正常に登録されたときにおける(保留商品とならなかったときにおける)、バスケット情報内に記憶される情報を示している。図18(A)に示した例では、登録商品情報(計)として品数「1」と概算小計金額「260」とが記憶され、登録商品情報(登録商品1)として「〇〇ヨーグルト」の商品コード「S5111」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「260」とが記憶されている。

0192

クラウドサーバ20(21)は、1品目の商品の商品コードを受信し、当該商品コードの商品(「〇〇ヨーグルト」)を特定した場合(図15のステップS35(YES))、図18(A)に示すように登録商品情報(計)を記憶し、図18(A)に示すように登録商品情報(登録商品1)を記憶する(ステップS36)。すなわち、登録商品情報(登録商品1)は、携帯端末50において1品目の商品(「〇〇ヨーグルト」)の商品コード(「S5111」)の読み取りが成功し(図15のステップS31(YES))、クラウドサーバ20(21)に該商品コード(「S5111」)が送信され(ステップS32)、クラウドサーバ20(21)において該商品コード(「S5111」)の商品(「〇〇ヨーグルト」)が特定された場合に(ステップS35(YES))、記憶されたものである(ステップS36)。

0193

図18(B)は、3品目の商品(「〇〇食パン」)迄が正常に登録されたときにおける、バスケット情報内に記憶される情報を示している。図18(B)に示した例では、登録商品情報(計)として品数「3」と概算小計金額「830」とが記憶され、登録商品情報(登録商品1)として「〇〇ヨーグルト」の商品コード「S5111」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「260」とが記憶され、登録商品情報(登録商品2)として「〇〇チョコレート」の商品コード「S3083」と商品名「〇〇チョコレート」と「〇〇チョコレート」の価格「350」とが記憶され、登録商品情報(登録商品3)として「〇〇食パン」の商品コード「S1493」と商品名「〇〇食パン」と「〇〇食パン」の価格「220」とが記憶されている。

0194

クラウドサーバ20(21)は、3品目の商品の商品コードを受信し、当該商品コードの商品(「〇〇食パン」)を特定した場合(図15のステップS35(YES))、図18(B)に示すように登録商品情報(計)を更新し、図18(B)に示すように登録商品情報(登録商品3)を記憶する(ステップS36)。なお、登録商品情報(登録商品1)は、1品目の商品(「〇〇ヨーグルト」)が特定されたときに記憶されたものである(ステップS36)。登録商品情報(登録商品2)は、2品目の商品(「〇〇チョコレート」)が特定されたときに記憶されたものである(ステップS36)。

0195

図18(C)は、例えば図18(B)の状態から「〇〇食パン」がキャンセルされたときにおける、バスケット情報内に記憶される情報を示している。図18(C)に示した例では、登録商品情報(計)として品数「2」と概算小計金額「610」とが記憶され、登録商品情報(登録商品1)として「〇〇ヨーグルト」の商品コード「S5111」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「260」とが記憶され、登録商品情報(登録商品2)として「〇〇チョコレート」の商品コード「S3083」と商品名「〇〇チョコレート」と「〇〇チョコレート」の価格「350」とが記憶され、キャンセル情報(今回の合計)としてキャンセル回数「1」が記憶され、キャンセル情報(キャンセル1)として「〇〇食パン」の商品コード「S1493」と数量「1」とが記憶されている。

0196

クラウドサーバ20(21)は、商品キャンセル情報(「〇〇食パン」の商品コードを含む)を受信した場合(図16のステップS52(YES))、図18(C)に示すように登録商品情報(計)を更新し、図18(C)に示すように登録商品情報(登録商品3)を削除するとともに(ステップS53)、図18(C)に示すようにキャンセル情報(今回の合計)を記憶し、キャンセル情報(キャンセル1)を記憶する(ステップS54)。すなわち、携帯端末50において、既に登録済の3品目の商品「〇〇食パン」をキャンセルする操作が行われた場合(図16のステップS50(YES))、クラウドサーバ20(21)に商品キャンセル情報(「〇〇食パン」の商品コードを含む)が送信され(ステップS51)、クラウドサーバ20(21)において、商品「〇〇食パン」の登録商品情報が削除され(ステップS53)、商品「〇〇食パン」のキャンセル情報が記憶される(ステップS54)。

0197

図18(D)は、1品目の商品(「〇〇ヨーグルト」)が正常に登録され、2品目の商品(「〇〇チョコレート」)が保留商品(NON−PlU)となり、3品目の商品(「〇〇食パン」)が保留商品(読取NG)となったときにおける、バスケット情報内に記憶される情報を示している。図18(D)に示した例では、登録商品情報(計)として品数「1」と概算小計金額「260」とが記憶され、登録商品情報(登録商品1)として「〇〇ヨーグルト」の商品コード「S5111」と商品名「〇〇ヨーグルト」と「〇〇ヨーグルト」の価格「260」とが記憶され、保留商品情報(計)として全体品数「2」とNON−PLU品数「1」と読取NG(要不正操作確認)品数「1」とが記憶され、保留商品情報(保留商品1)として保留商品種別「1(NON−PLU)」と「〇〇チョコレート」の商品コード「S3083」とが記憶され、保留商品情報(保留商品2)として保留商品種別「2(読取NG)」と「〇〇食パン」のバーコードを含む部分が撮像されている撮像画像「AAA.jpeg」とが記憶されている。

0198

保留商品情報(保留商品1)は、携帯端末50において2品目の商品(「〇〇チョコレート」)の商品コード(「S3083」)の読み取りが成功し(図15のステップS31(YES))、クラウドサーバ20(21)に該商品コード(「S3083」)が送信されたが(ステップS32)、クラウドサーバ20(21)において該商品コード(「S3083」)の商品(実際には「〇〇チョコレート」)が特定されなかった場合に(ステップS35(NO))、記憶されたものである(ステップS38)。

0199

保留商品情報(保留商品2)は、携帯端末50において3品目の商品(「〇〇食パン」)の商品コード(「S1493」)の読み取りが失敗し(図15のステップS31(NO))、クラウドサーバ20(21)に該商品(「〇〇食パン」)を撮像した画像データが送信され(ステップS45)、クラウドサーバ20(21)において該画像データを受信した場合に(ステップS48(YES))、記憶されたものである(ステップS49)。

0200

以上、各実施形態について説明したが、各実施形態のコンセプト(概念)等について説明する。
図5に示した第1の実施形態のショッピングシステムにおいて、精算装置40は、クラウドサーバ20によるサービスの利用するために、新たに店舗に設置(納入)した装置であってもよい。つまり、図5に示した第1の実施形態のショッピングシステムは、クラウドサーバ20によるサービスの利用を開始するのに際し、元々店舗に設置されていた精算装置30とは別に、クラウドサーバ20によるサービスを利用するために必要となる機能(携帯端末連動機能、クラウド通信機能)を具備した新端末である精算装置40を追加的に導入して構築されたものであってもよい。換言すれば、第1の実施形態のショッピングシステムは、例えば既存の外部のクラウドサーバ20によるサービスの利用を開始するのに際し、既存の精算装置30や管理装置10に対する改修を行なわずに(管理装置10については店舗情報及び商品情報を送信するといった若干の機能追加があるが)、単に新端末である精算装置40を追加的に設置さえすればよく(クラウドサーバ20について店舗情報及び商品情報を受信するといった若干の機能追加があるが)、クラウドサーバ20によるサービスを短期間のうちに導入できるといったコンセプトに基づいて構築されたものである。

0201

クラウドサーバ20によるセルフシステム(セルフ登録システム、セルフスキャンシステム)の導入前の時点では、既存のシステム(管理装置10、精算装置30)にて運用されている売価決定ロジック(売価決定ロジックA、B)が、クラウドサーバ20が提供可能な売価決定ロジック(売価決定ロジックA、B、C)の範囲内にあるため、クラウドサーバ20によるセルフシステムの導入に際し、既存の売価決定ロジックを利用する必要はない。従って、新端末である精算装置40を追加する程度で足り、導入時のコストを抑えることができる。なお、図5に示す例では、クラウドサーバ20は、売価決定ロジックCを実装しているが、運用しない。

0202

図11に示した第2の実施形態のショッピングシステムにおいて、精算装置41は、クラウドサーバ20によるサービスの利用するために、図5に示した精算装置40、又は、既存の精算装置31を改修した装置であってもよい。つまり、図11に示した第1の実施形態のショッピングシステムは、クラウドサーバ20によるサービスの利用を開始するのに際し、新端末である精算装置40、又は、元々店舗に設置されていた精算装置31に対し、クラウドサーバ20によるサービスを利用するために必要となる機能(新端末である精算装置40に対しては売価決定ロジック、精算装置31に対しては携帯端末連動機能、クラウド通信機能)を追加して構築されたものであってもよい。換言すれば、第2の実施形態のショッピングシステムは、例えば既存の外部のクラウドサーバ20によるサービスの利用を開始するのに際し、新端末である精算装置40、又は、既存の精算装置31に対する改修を行えば(管理装置10やクラウドサーバ20についても店舗情報及び商品情報の送受信といった若干の機能追加はあるが)、クラウドサーバ20によるサービスを短期間のうちに導入できるといったコンセプトに基づいて構築されたものである。

0203

クラウドサーバ20によるセルフシステムの導入前の時点では、既存のシステム(管理装置11、精算装置31)にて運用されている売価決定ロジック(売価決定ロジックA、B、C、D、G)が、クラウドサーバ20が提供可能な売価決定ロジック(売価決定ロジックA、B、C)の範囲内にないため、クラウドサーバ20によるセルフシステムの導入に際し、既に存在する精算装置(精算装置40、精算装置31)に対し機能を追加するが、比較的、導入時のコストを抑えることができる。クラウドサーバや管理装置の改修よりも、精算装置の改修の方が容易であると判断した場合に有効である。なお、図11に示す例では、クラウドサーバ20は、売価決定ロジック(売価決定ロジックA、B、C)を実装しているが、運用しない。

0204

図13に示した第3の実施形態のショッピングシステムにおいて、精算装置40は、クラウドサーバ21によるサービスの利用するために、新たに店舗に設置(納入)した装置であってもよい。つまり、図13に示した第3の実施形態のショッピングシステムは、クラウドサーバ20によるサービスの利用を開始するのに際し、クラウドサーバ20を改修(外部連携機能を追加)してクラウドサーバ21とし、元々店舗に設置されていた管理装置11を改修(外部連携機能を追加)して管理装置12とし、更に、元々店舗に設置されていた精算装置30とは別に、クラウドサーバ21によるサービスを利用するために必要となる機能(携帯端末連動機能、クラウド通信機能)を具備した新端末である精算装置40を追加的に導入して構築されたものであってもよい。換言すれば、第3の実施形態のショッピングシステムは、例えば既存の外部のクラウドサーバ20によるサービスの利用を開始するのに際し、既存の精算装置31に対する改修を行わずに、既存のクラウドサーバ20と管理装置11に改修を行えば、あとは、単に新端末である精算装置40を追加的に設置さえすれば、改修後のクラウドサーバ21によるサービスを短期間のうちに導入できるといったコンセプトに基づいて構築されたものである。

0205

クラウドサーバ20によるセルフシステムの導入前の時点では、既存のシステム(管理装置11、精算装置31)にて運用されている売価決定ロジック(売価決定ロジックA、B、C、D、G)が、クラウドサーバ20が提供可能な売価決定ロジック(売価決定ロジックA、B、C)の範囲内にないため、クラウドサーバ20によるセルフシステムの導入に際し、クラウドサーバ20をクラウドサーバ21に改修(外部連携機能を追加)し、管理装置11を管理装置12に改修(外部連携機能を追加)するが、比較的、導入時のコストを抑えることができる。精算装置の改修よりも、クラウドサーバや管理装置の改修の方が容易であると判断した場合に有効である。なお、図13に示す例では、クラウドサーバ21は、売価決定ロジック(売価決定ロジックA、B、C)を実装しているが、運用しない。

0206

なお、クラウドサーバ20を改修(外部連携機能を追加)してクラウドサーバ21とすると説明したが、クラウドサーバ20は、元々、外部連携機能を備えていてもよい。クラウドサーバ20が外部連携機能を備えていれば、第3の実施形態のショッピングシステムにおいて、クラウドサーバ20の改修は不要となるため、一層、導入コストが削減する。

0207

一般に、新規システムを導入する際の課題(障壁)は、導入のアプローチ毎に以下のようなものが考えられる。
1.既存システムを改修して導入するアプローチの場合、既存システムにスマホ通信部やバスケット記憶部等の制御を追加するのが大変である(店舗に合わせ都度システムを作成しなければならない。つまり、店舗の数だけシステムを作る必要がある)。
2.一方、既存システムを残し、別システムとして立ち上げるアプローチの場合、既存システムと同様の売価決定ロジックを作成し、運用するのが大変(上記同様店舗の数だけ売価決定ロジックを作成する必要がある)。売価決定ロジックは、基本、顧客独自のノウハウ営業精神が蓄積されたものであると言えるため、導入先に応じて作業することは簡単ではない。
上記1、2は、いずれも店舗側・システム提案者側の両方に大きな負荷である。

0208

これに対し、各実施形態にて説明したショッピングシステムでは、元々ある売価決定ロジックを利用するといった仕組みであるため、どの店舗であっても既存のシステムをそのまま残しながら(管理装置10、11、12や精算装置30、31を稼働させつつ)、新規システムとの共存を図ることができ、上記1、2の問題をともに解決することができる。

0209

以上、各実施形態について説明したが、更に、各実施形態について補足説明する。例えば、図17に示した例では、精算装置40上(客側表示部406、店員側表示部410)で商品キャンセルに関する警告を行っているが(図17のステップS79)、例えば、精算装置40に代えて加えて、店員が携帯する店員用携帯端末に警告情報を送信することにより、店員用携帯端末上で商品キャンセルに関する警告を行ってもよいし、精算装置(精算装置30、精算装置40(41))を監視する監視装置(不図示)に警告情報を送信することにより、監視携帯端末上で商品キャンセルに関する警告を行ってもよい。また、図17に示した例では、精算装置40(客側表示部406、店員側表示部410)上で保留商品に関する報知を行っているが(図17のステップS83)、例えば、精算装置40に代えて加えて、上記店員用携帯端末に修正指示情報等を送信することにより、店員用携帯端末上で保留商品に関する報知を行ってもよいし、上記監視装置に修正指示情報等を送信し、上記監視装置上で保留商品に関する報知を行ってもよい。

0210

なお、上記実施形態において、夫々の売価決定ロジックが参照する夫々の設定情報等は、商品情報とは別の情報であってもよいし、商品情報の一部であってもよい。例えば、図5に示したクラウドサーバ20を一例に説明すると、クラウドサーバ20は、商品情報とは別に、売価決定ロジックAが参照する売価変更の情報、売価決定ロジックBが参照する単品値引設定情報、売価決定ロジックCが参照する小計値引設定情報を記憶してもよいし、クラウドサーバ20が記憶する商品情報は、売価決定ロジックAが参照する売価変更の情報、売価決定ロジックBが参照する単品値引設定情報、売価決定ロジックCが参照する小計値引設定情報を含む情報であってもよい。あるいは、売価決定ロジックAに参照する売価変更の情報は当該売価決定ロジックAに内在されていてもよい(売価決定ロジックB、Cについても同様である)。売価決定統括ロジックについても同様である。

0211

なお、第3の実施形態において、精算装置41が売価決定ロジックA、B、C、D、Gを備えるが、商品情報を備えない。従って、商品情報内に売価決定ロジックが参照する設定情報が含まれている態様である場合(換言すれば、設定情報を売価決定ロジックに内在させる態様、又は、精算装置41内に商品情報とは別個に設定情報を記憶する態様としない場合、つまり、精算装置41が自装置内に設定情報を保持していない場合)には、精算装置41は、小計金額を算出する際には(売価決定ロジックを使用する際には)、クラウドサーバ20に記憶されている設定情報(商品情報内に含まれる設定情報、又は、商品情報とは別に記憶されている設定情報)を参照する。なお、精算装置41は、小計金額を算出する際に、クラウドサーバ20に記憶されている設定情報に代えて又は加えて、管理装置11に記憶されている設定情報(商品情報内に含まれる設定情報、又は、商品情報とは別に記憶されている設定情報)を参照してもよい。なお、管理装置11に記憶されている情報が、クラウドサーバ20に記憶されている情報のよりも新しいような場合(バッチ処理によりクラウドサーバ20側に情報が反映されるような場合)には、管理装置11に記憶されている情報を参照してもよい。

0212

また、上記実施形態では、商品登録の終了後の処理の流れは、携帯端末50が表示したコードを精算装置40(41)が読み取るというものであったが、他の流れであってもよい。例えば、携帯端末50によるクラウドサーバ20(20)への要求を起点(トリガー)として、小計金額の算出が開始されるような流れであってもよい。

0213

例えば、第1の実施形態では、携帯端末50が精算処理を実行する精算装置40の装置識別情報(精算装置番号)を取得し、携帯端末50がバスケット識別情報、装置識別情報とともに、小計算出要求情報をクラウドサーバ20に送信し、クラウドサーバ20が自装置にて算出した小計金額を含む小計情報を装置識別情報によって識別される精算装置40に送信してもよい。
第2の実施形態では、携帯端末50が精算処理を実行する精算装置41の装置識別情報(精算装置番号)を取得し、携帯端末50がバスケット識別情報、装置識別情報とともに、商品データ要求情報
をクラウドサーバ20に送信し、クラウドサーバ20は、バスケット内の商品データを装置識別情報によって識別される精算装置41に送信してもよい。
第3の実施形態では、携帯端末50が精算処理を実行する精算装置40の装置識別情報(精算装置番号)を取得し、携帯端末50がバスケット識別情報、装置識別情報とともに、小計算出要求情報をクラウドサーバ21に送信し、クラウドサーバ21が管理装置11にて算出された小計金額を含む小計情報を装置識別情報によって識別される精算装置40に送信してもよい。

0214

なお、上記実施形態では、保留商品(読取NG)する場合に、すなわち、商品の読み取りが失敗した場合(タイムアウト処理となった場合)には、携帯端末50は、自動的にシャッターを切って商品の撮像画像(画像データ)を取得する態様を説明したが(図15のステップS45)、保留商品(読取NG)する場合に、顧客のタイミングによって(顧客の操作に基づいて)シャッターを切らせる態様としてもよい。例えば、携帯端末50は、商品の読み取りが失敗した場合(タイムアウト処理となった場合)に、顧客によるシャッター操作モードに切り替えるようにしてもよい。

0215

なお、読取NGの場合(後述する自己宣言商品の場合も同様)において顧客の操作に基づいてシャッターを切る態様とする場合には、顧客に対し撮像の操作を指示(例えば、登録画面上にメッセージ表示)してもよい。また、顧客の操作に基づいてシャッターが切られた場合(画像データを取得した場合)には、自動的にシャッターを切る態様と同様、自動的に画像データをクラウドサーバ20(21)に送信してもよいし、顧客の操作に基づいて画像データをクラウドサーバ20(21)に送信してもよい。

0216

また、上記実施形態では、保留商品として、NON−PLU、読取NGの2種類を管理する例を説明したが、保留商品は上記2種類に限定されない。例えば、上記2種類以外の保留商品として自己宣言商品として管理してもよい。自己宣言商品とは顧客自身が宣言して保留商品としたものである。つまり、所定時間の撮像の末、タイムアウト処理が実行されれば読取NGとなるが、仮にタイムアウト処理までに時間を要するような場合には、顧客は携帯端末50を商品にかざし続けなければならない。このような状況においてタイムアウトを待てない場合には、顧客は、自らの判断により自分で保留商品を宣言してもよい。例えば、携帯端末50の登録画面に保留宣言ボタンを配置し、保留宣言ボタンの操作(タッチ)により、バーコードの認識処理一時停止して顧客によるシャッター操作モードに切り替えるようにしてもよい(実際にシャッターを切った場合にバーコードの認識処理を終了してもよい)。または、保留宣言ボタンの操作(タッチ)により、バーコードの認識処理を終了するとともにシャッターを切ってもよい。

0217

上述のように、自己宣言商品の場合にも商品の撮像画像を取得するため(つまり撮像データを生成するため)、撮像データをクラウドサーバ20(21)に送信する。クラウドサーバ20(21)は、バスケット情報内に保留商品情報(例えば、保留商品区分:3(自己宣言)、画像データ)を記憶する。

0218

保留商品(読取NG)の場合において、管理する画像データの枚数(データ数)は、2以上であってもよい。つまり、携帯端末50では、ある商品のタイムアウト処理において当該商品の撮像画像を複数取得し(複数の画像データを生成し)、クラウドサーバ20(21)は、当該商品の画像データを複数記憶してもよい。保留商品(自己宣言)の場合についても同様である。なお、保留商品(自己宣言)の場合であって、顧客のタイミングにてシャッターを切らせる態様とするときには、顧客に撮像すべき枚数を報知(例えば、登録画面上に表示)してもよい。

0219

また、精算装置40(41)は、2つのスキャナ部(客側スキャナ部406、店員側スキャナ部412)を備える装置であったが、また、精算装置40(41)が1つのスキャナ部(客側スキャナ部406)を備える装置であってもよい。精算装置30についても同様である。また、精算装置40(41)は、精算処理に加えて登録処理も実行できる旨(例えば、カード決済部408や釣銭機409を備えることに加えて、客側スキャナ部406や店員側スキャナ部412が商品に付されているバーコードをスキャンする旨)を説明したが、登録処理は実行しない精算処理専用の装置(他の装置において登録処理された商品について精算処理を実行する精算処理専用の装置)であってもよい。精算装置30についても同様である。

0220

なお、顧客が商品をキャンセルした場合(キャンセル操作を行った場合)には、キャンセルした商品を(例えば元々の陳列位置)に戻す旨を報知(携帯端末50の表示画面で報知)してもよい。つまり、キャンセルした場合に当該商品をクラウドサーバ20(21)のバスケットや携帯端末50の表示において削除等するだけではなく、当該商品を元の棚に戻す旨を報知し、店舗の陳列秩序が維持されるように顧客に協力要請する。実際の店舗では、何らかの理由で購入をやめた商品が本来とは異なる棚に放置されていることもあるため、このようなマナーの悪い利用客への警告として有効である。

0221

なお、クラウドサーバ20(21)の情報(例えば、バスケット情報等)を電子レシートとして用いてもよい。例えば、クラウドサーバ20(21)は、電子レシート出力機能を備えていてもよい。これにより、顧客は、自身の利用履歴をクラウド上で確認したり、あるいは、携帯端末50等にダウンロードして取引履歴として保存したりすることができるようになる。

0222

クラウドサーバ20(21)は、送受信データ「D0(店舗情報、商品情報)」の送受信と同様の通信により、顧客の利用履歴を管理装置10(11、12)へ送信してもよい。これにより、管理装置10(11、12)は、既存システムで精算を終えた利用者だけでなく、セルフ登録システムを利用した顧客の利用履歴も合わせて保存、管理することが可能になる。例えば、セルフ登録システムによる取引を、従来の電子ジャーナル統合させることもでき、従来と同様、検索の対象とすることができる。なお、利用履歴上でそれぞれの取引がどのように実施されたかを識別するための利用態様識別情報(単に、利用態様情報ともいう)により個々の取引の態様を管理してもよい。

0223

(利用態様情報)
利用態様情報「1(通常)」:登録処理、精算処理ともに店員が対応した取引
利用態様情報「2(セミセルフ)」:登録処理を店員が対応し、精算処理を客自身で対応した取引
利用態様情報「3(フルセルフ)」:登録処理、精算処理ともに客が対応した取引(同一装置
利用態様情報「4(スマホセルフ)」:登録処理、精算処理ともに客が対応した取引(別装置)

0224

また、利用履歴(電子ジャーナル)を確認する際の表示画面や、店舗で印刷されるレシートにも上記利用態様が分かり易く表示してもよい。また、表示領域や印刷領域が小さい場合には、「通」、「セ」、「フ」、「ス」等の頭文字のみを出力してもよいし、更に小さい場合には、値(「1」〜「4」等)を表示してもよい。

0225

以上の様な工夫により、既存システム側でもセルフ登録システムの利用状況を把握できるため、従来の運用方法を変えることなく店舗状況(売上、在庫管理、利用履歴等の店舗に関する情報)を確認することができる。このような共存を少ない改修で実現できるため、どのような運用を実施している利用客に対しても、実施形態にて説明したシステムを提案することができる。

0226

以上、各実施形態等について説明したが、具体的な構成は各実施形態に記載した内容に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。以下に、付記A1〜A6を開示する。
(付記A1)
付記A1のセルフ登録システムは、外部の決定手段(例えば、既存の売価決定ロジック)と連携するセルフ登録システムであって、商品登録を行う登録手段(例えば携帯端末)と、登録された取引情報を蓄積する蓄積手段(例えばクラウドサーバ上のバスケット領域)と、前記取引情報に基づく取引金額の算出を前記外部の決定手段に依頼する依頼手段(例えば、売価決定ロジックの実行を依頼するリクエスト。小計算出要求情報等)とを備える。

0227

付記A1の構成によれば、顧客に合わせて売価決定ロジックを用意する手間を削減するために、既存の売価決定ロジックを利用します。これにより導入工数(コスト)を小さくすることができるので、普及を容易にすることができる。
(付記A2)
付記A2のセルフ登録システムは、付記A1のセルフ登録システムにおいて、前記依頼手段は、算出後に前記取引金額を表示する精算装置が前記取引情報を読み取ることにより、又は、前記登録手段が前記精算装置を識別する情報を読み取ることにより、実行されるものであってもよい。
付記A2の構成によれば、簡便に取引金額の算出を依頼することができる。
(付記A3)
付記A3のセルフ登録システムは、付記A1又は付記A2のセルフ登録システムにおいて、前記蓄積手段は、登録できた取引情報に加え、登録できなかった取引情報も蓄積可能であってもよい。
付記A3の構成によれば、登録できなかった取引情報を好適に管理することができる。
(付記A4)
付記A4のセルフ登録システムは、付記A1〜付記A3のいずれかのセルフ登録システムにおいて、算出後に前記取引金額を表示する精算装置は、前記登録できなかった取引情報を取得した場合にその旨を報知する報知手段を備えるものであってもよい。
付記A4の構成によれば、登録できなかった取引情報がある旨を認識することができる。例えば、顧客には、保留商品の存在や店員が来ることを報知し、店員には保留商品を処理すべき精算装置の情報を報知してもよい。
(付記A5)
付記A5のセルフ登録システムは、付記A3又は付記A5のセルフ登録システムにおいて、算出後に前記取引金額を表示する精算装置は、前記登録できなかった取引情報を精算可能な取引情報へ修正する修正手段を備えるものであってもよい。
付記A5の構成によれば、例えば店員が精算可能な取引情報に修正することにより、客は精算処理を行うことができる。
(付記A6)
付記A6のセルフ登録システムは、付記A1〜付記A5のいずれかのセルフ登録システムであって、算出後に前記取引金額を表示する精算装置が前記取引情報を読み取ることにより、又は、前記登録手段が前記精算装置を識別する情報を読み取ることにより、精算処理をするための取引を開始する第1精算装置と、店員の登録操作で取引情報が生成されることにより、精算処理をするための取引を開始する第2精算装置と、を備えるものであってもよい。
付記A6の構成によれば、既存のシステムをそのまま残しつつ、セルフ登録システムを導入でき、かつ、両システムを共存させることができる。換言すれば、既存の端末やシステムを排除することなく既存のセルフ登録システムの導入ができるため、全てのPOSユーザーを対象とした展開ができる。なお、例えば、第1精算装置は、セルフ登録システムと同時に導入されるセルフ登録システム用の精算装置であり、第2精算装置は、もともと利用されていた第2精算装置であってもよい。第2精算装置(第1精算装置も同様)は、少なくとも精算処理が可能なものであればよい。従って、例えば、精算処理に加えて商品登録処理ができる装置であってもよいし、他装置において登録された商品を精算できる精算装置であってもよい。また、登録処理が可能な場合、当該登録処理は、店員によって行われる装置であってもよいし、客自身によって行われるものであってもよい。
(付記A7)
付記A7のセルフ登録方法は、外部の決定手段と連携するセルフ登録方法であって、商品登録を行う登録ステップと、登録された取引情報を蓄積する蓄積ステップと、前記取引情報に基づく取引金額の算出を前記外部の決定ステップに依頼する依頼ステップとを備えることを特徴とする。

0228

各種クラウドサーバ20(21)が携帯端末50や精算装置40の利用状況を監視しながら、能動的に売価決定ロジックによる小計金額の決定を行う場合がある。例えば、携帯端末50で「お会計へ進む」が押下されたことをクラウドサーバ20(21)が検出した場合、売価決定ロジックが当該携帯端末50の利用者のバスケット情報を特定し、先行して小計金額を決定することができる。あとは顧客がQRコードを読取らせた精算装置40へバスケット情報や小計金額を送信する。同様に、精算装置40でQRコードを読取り、その読取操作をクラウドサーバ20(21)が検出した場合も、能動的に売価決定ロジックにより小計金額を決定し、精算装置40へ決定結果を送信することができる。このように、売価決定ロジックは精算装置からの依頼により実行される場合に限定されない。

0229

携帯端末50と精算装置40との間でのバスケット識別情報のやり取りは、2次元コードに限定されず、バーコード、RFIDやNFCやブルートゥースによる無線通信、携帯端末50または精算装置40に用意されたコネクタを経由して携帯端末50と精算装置40との有線通信など方法は問わない。

0230

商品登録を終えた顧客が精算装置40を利用する際に、店舗が広大であったりいずれの精算装置も行列をなしている場合など、どの精算装置を利用すればよいか判断できない。このような状況の場合には、最も空いている、最も近い等の条件を考慮した最適な精算装置を案内する案内装置別途設けてもよい。また、携帯端末50に案内機能を設けている場合には、例えば「お会計へ進む」が押下されると精算装置選択画面が表示され任意の精算装置を予約できてもよい。

0231

なお、以上に説明した管理装置10、11、12、クラウドサーバ20、21、精算装置40、41、携帯端末50を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録し、そのプログラムをコンピュータシステムに読み込ませて実行するようにしてもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル差分プログラム)であってもよい。

0232

10、11、12…管理装置
20、21…クラウドサーバ
30…精算装置
40、41…精算装置
50…携帯端末
401…CPU
402…ROM
403…RAM
404…ハードディスク
405…客側表示部
406…客側スキャナ部
408…カード決済部
409…釣銭機
410…店員側表示部
411…キー操作部
412…店員側スキャナ部
413…印刷部
414…音声出力部
415…通信部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社ぐるなびの「 決済支援システム、決済支援方法、及び決済支援プログラム」が 公開されました。( 2020/10/29)

    【課題】施設における利用者の利用代金の決済処理を効率よく行うことにより利用者の利便性を向上させることが可能な決済支援システム、決済支援方法、及び決済支援プログラムを提供すること。【解決手段】決済支援シ... 詳細

  • 株式会社寺岡精工の「 販売データ処理システム」が 公開されました。( 2020/10/29)

    【課題】携帯端末を使用して商品登録する販売データ処理システムにおいて、買い物袋(マイバック)を普及させるとともに、スムーズな商品登録を可能とする販売データ処理システムを提供する。【解決手段】購入する商... 詳細

  • 東芝テック株式会社の「 商品販売データ処理装置及び制御プログラム」が 公開されました。( 2020/10/29)

    【課題】商品に課せられる税の税率が消費の形態によって変化する場合でも簡単な操作で対処できるようにする。【解決手段】商品販売データ処理装置は、一取引として売り上げる商品の販売データを処理する。また同装置... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ