JP2019057086A - 商品販売データ管理装置、商品販売データ管理システム及びプログラム - Google Patents

Abstract

【課題】購入する商品に関する適切なアドバイス等を、適切なタイミングで顧客に提示することで、顧客に対し、よりよい販売環境を提供すること。【解決手段】購入する商品に関する商品情報を取得する商品情報取得部と、前記商品情報を順次登録する登録部と、新たに登録された商品情報に係る商品の価格が第１の値と一致しない場合に一致しないことを知らしめるように、報知を行う報知部と、を有する商品販売データ管理装置が提供される。【選択図】図３

Description

本発明は、商品販売データ管理装置、商品販売データ管理システム及びプログラムに関する。

いわゆる１００円ショップなど、均一の売価で商品を販売する店舗、チェーン店が多数存在する。このような店舗では、従来は、均一の売価以外の商品を併せて販売することはほとんどなかった。しかしながら、昨今は、多様な顧客ニーズに答えるために、均一の売価以外の商品も販売することが一般的となっている。このような店舗の存在によって、顧客は複数店舗を訪れなくても安価な商品をひとつの店舗で購入することが容易に行えるようになってきている。

また、複数の売価の商品を扱う店舗側の業務にも変化がみられる。以前であれば商品点数と、商品の種類（商品の取扱い部門）程度を入力して会計処理を行っている店舗が大半であった。しかしながら、最近は大手チェーンを中心に、ＪＡＮコードなど、商品を特定できる識別情報を得て商品を登録するＰＯＳレジスタなどの導入も見受けられる。この方法により、売価の誤入力を回避している。加えて、このようにすることによって、在庫管理、販売戦略などに有効に利用できる情報を取得できるようになる。
従来技術としては、例えば以下の技術が存在する。

親と子とが設定され可搬性を有し商品を収納して運搬するための複数の運搬体を備え、これらの運搬体には、収納された商品に設けられた無線タグから当該商品の価格を特定するための価格情報を無線通信により取得する価格情報取得手段が設けられる。そして、親運搬体と子運搬体とは関連付け手段により関連付けされ、関連付けされた親運搬体と子運搬体とに収納された全商品の価格の総合計額を価格情報取得手段が取得した価格情報に基づいて算出する際に、その算出に必要な情報を親運搬体と子運搬体との間の無線通信により集め、総合計額を算出し、算出した総合計額を報知部により報知する技術が存在する（特許文献１参照）。

特許第４１２８９３６号公報

上記のようにＰＯＳレジスタの導入により、金額の間違いなどは低減できる。しかしながら、均一の売価以外の商品を誤って購入カートに入れても、客はそのことに気づかないことがある。この場合、顧客としては、予想と違う価格の商品を購入することとなる

本発明は、このような状況に鑑み、購入しようとする商品の価格の告知など、適切なタイミングで顧客に提示することで、顧客に対し、よりよい販売環境を提供することを目的としている。

開示の一態様によれば、購入する商品に関する商品情報を取得する商品情報取得部と、前記商品情報を順次登録する登録部と、新たに登録された商品情報に係る商品の価格が第１の値と一致しない場合に一致しないことを知らしめるように、報知を行う報知部と、を有する商品販売データ管理装置が提供される。

開示の態様によれば、顧客に対して、購入しようとする商品に関して、適切なタイミングで、適切な情報を提供することができ、顧客のニーズに、より適合した商品販売のサービスを提供することができる。

一実施例の概略を示す図である。 均一の売価でない商品を購入する際に顧客に提示されるアラートの例を示す図である。 一実施例における構成を示すブロック図である。 一実施例の処理を示すフローチャートである。 顧客の予算を勘案して適切な購入アドバイスを提供する例を示すフローチャートである。 顧客又は店舗職員があらかじめ登録しておく情報の例を示す図である。 顧客に対して表示画面に表示するユーザーインタフェースの例を示す図である。 商品を返却するときなどに商品の陳列場所を表示する例を示す図である。 一実施例のシステムの構成を示す図である。 一実施例のハードウエア構成を示す図である。

以下に、複数の実施例について、図を参照しながら説明を行う。なお、これらの実施例は例示である。したがって、個々の実施例は、発明の技術的範囲を限定するためのものではない点に留意すべきである。

それぞれの実施例は、排他的なものではなく、矛盾のない限り、適宜組み合わせて実施することができる。また、処理のフローは、矛盾のない限り、順番を変更してもよく、あるいは同時に実行してもよい点に留意すべきである。

また、実施例では、使用するハードウエアとして携帯端末を用いて説明する部分があるが、ハードウエアは、携帯端末に限定されるものではなく、店舗におけるＰＯＳ端末であってもよい。ＰＯＳ端末は、店舗の精算時に店舗職員が操作するものばかりでなく、店舗職員と顧客の両者が共同して操作するＰＯＳ端末、顧客のみが操作するＰＯＳ端末などであってもよい。また、携帯端末は、顧客が所有する携帯電話、タブレットばかりでなく、店舗が所有し顧客に貸し与えるハンディ端末などであってもよい。

すなわち、以下の実施例で実現される諸機能は、いかなる態様のハードウエアで実現されてもよく、あるいは、複数のハードウエアが連携し情報を共有しながら実現されてもよいことは言うまでもない。

なお、本明細書においては、実店舗における実施例を例示しているが、店舗は、インターネットなどのネットワーク上の仮想店舗であってもよい。この場合には、携帯端末、ＰＯＳ端末などは、顧客の操作する携帯電話、タブレット、パーソナルコンピュータなどであってもよい。

＜実施例１＞
図１は、一実施例の概略を示す図である。図１（Ａ）には、顧客が携帯端末１５０を用いて、購入する商品に関する諸情報を登録する例が示されている。携帯端末１５０は、顧客の所有する携帯電話又はタブレット、あるいは販売店が顧客に貸与する携帯用の専用端末であってもよい。図１において、スーパーマーケットなどの店舗の陳列棚１００に、複数の商品が陳列されている。陳列棚１００には、複数のマヨネーズ１１０、高級胡椒１２０及び塩１３０が陳列されている。

陳列棚１００の前面には、マヨネーズ１１０、高級胡椒１２０、塩１３０にそれぞれ近接して、それぞれのバーコード１１２、１２２、１３２が表示されている。また、同様に、それぞれの商品の名前、「マヨネーズ」１１４、「高級胡椒」１２４、「しお」１３４が記載されている。更に、それぞれの商品の価格１００円（１１６）、３００円（１２６）、１００円（１３６）が表示されている。

この店舗は１００円ショップとして営業を行っていると仮定する。したがって、１００円の商品が最も多く販売されているが、例えば高級胡椒１２０のように、３００円の商品も販売されている。

携帯端末１５０の表面の画面１５１には、携帯端末１５０の裏側のカメラ（不図示）により撮影された商品（マヨネーズ１１０ａ、高級胡椒１２０ａ等）の映像が表示されている。顧客は、購入する商品の画面位置を、指１６０でタップすることによって、購入する商品を選択することができる。画面上の商品以外に、購入する商品のバーコード、商品名、価格などをタップしてもよい。

このように、顧客は、携帯端末１５０を用いて購入する商品を指示することによって、携帯端末は、購入する商品の識別情報、金額などを取得する。携帯端末は、タップされた商品の近くにあるバーコードにより商品を識別してもよい。あるいは、商品自体の形状、又は商品名などからパターン認識の技術を用いて携帯端末が商品を認識してもよい。

バーコードには、商品の価格のみが含まれていてもよい。この場合には、商品名などの識別を行わず、商品の価格のみを登録するようにしてもよい。なお、バーコードに、商品の識別情報が含まれており価格が含まれていない場合には、商品の識別情報と価格との対応表を含むデータベースを検索することにより、商品の価格を取得するようにしてもよい。このデータベースは、携帯端末１５０が、あらかじめ店舗のサーバからダウンロードするようにしてもよい。あるいは、携帯端末１５０は、購入する商品が登録される都度、無線通信を利用して、店舗のデータベースを参照するようにしてもよい。

図１（Ｂ）は、商品である高級胡椒１２８の裏の添付ラベルに記載されている商品コード１２９が示されている。そして、ＰＯＳ端末１８０（不図示）に接続されたバーコードリーダ１８５によって、レジにおいて、バーコード１２９が読み取られている。このように、商品の識別情報の読み取りはレジにおけるＰＯＳ端末１８０（及びバーコードリーダ１８５）によってなされてもよい。あるいは、顧客が、購入しようとする商品を手に取り、当該商品コード１２９を携帯端末１５０に読み込ませることにより、購入する商品の識別情報を携帯端末１５０が取得できるようにしてもよい。この場合にも、携帯端末は、例えば上記データベースを参照することにより、商品の価格を取得し、商品情報とともに商品の価格を携帯端末等に登録することができる。

購入する商品の個数を顧客が入力できるように、個数のアップ・ダウンのボタン（不図示）が、画面１５１に表示され、タップを促すようにしてもよい。あるいは、顧客が複数回商品を携帯端末１５０に認識させるようにして、同一品種の商品を複数個購入することを携帯端末１５０に顧客が指示できるようにしてもよい。
商品の登録情報は、携帯端末１５０に登録されてもよい。あるいは商品の登録情報は、店舗のサーバに登録されるようにしてもよい。

以上の例は、携帯端末１５０が、顧客の購入する商品を認識し、商品の価格等の情報を順次登録する例を示したものである。商品を識別する手法は、上記のような手法以外に、個々の商品に付されたＲＦＩＤにより、携帯端末が認識する方法でもよい。

また、複数の顧客が一緒に同一店舗で商品を購入する場合などでは、顧客の各々が携帯端末１５０を所持し、購入する商品の価格、商品識別情報等を無線通信などで双方の携帯端末１５０が共有できるようにしてもよい。このようにすることによって、後述するように、複数人の顧客が同じ商品を重複して購入することを防止したり、購入総額などが予算オーバーになったりすること等を防止できる。

また、夫婦などが、通勤の帰りに、時間差を置いて、商品を購入する場合にも、夫婦の各々の携帯端末１５０が、購入した（あるいは購入しようとする）商品の情報を共有することができるので、後述するように、刺身などの生鮮食料品を二重に購入するなどして、同日の生鮮食料品の購入予算がオーバーしてしまうこと等も防止することができる。

なお、携帯端末に店舗のアプリケーションをインストールして店舗の会員となり、上記のような買い物をした場合には、そのインセンティブとして、購入金額、購入回数などに応じて、顧客に会員ポイントを付与するようにしてもよい。会員ポイントは、購入の際に金銭の代替として利用できるようにしてもよい。

図２は、顧客が均一の売価でない商品を購入する際に顧客に提示されるアラートの例を示す図である。
均一の売価とは、例えば、いわゆる１００円ショップと呼ばれる店舗であれば、１００円が均一の売価である（内税、外税は問わない。）。１００円ショップであれば、均一の売価の商品の種類が最も多いのが通例である。なお、本明細書において、均一の売価を扱う店舗であっても、店舗においてその均一の売価の商品の種類が最も多くなければならないわけではない。
図２（Ａ）は、１００円ショップにおいて、均一の売価（１００円）以外の商品である高級胡椒１２０を購入しようとする際に、携帯端末１５０の表示画面２６０に表示されるアラートの例を示している。この事例の場合には、高級胡椒１２０は、１００円ではなく３００円で販売されている。１００円ショップにおいては、顧客は、ほとんどの商品が１００円で販売されていることを認識しているため、高級胡椒１２０が３００円であることを気づかない場合がる。この場合、従来であれば、精算を行うレジの場所において顧客が初めてこのことに気づくことが多かった。３００円であれば、購入しないといった場合も発生することがあり、レジにおいて３００円の商品の返却処理が行われることがあった。このために、レジにおける処理が長くなり、顧客の待ち行列が長くなる原因にもなっていた。

図２（Ａ）では、高級胡椒１２０を携帯端末１５０が認識したときに、「３００円です」（２６２）とのアラートが画面２６０に表示されるため、顧客は、均一の売価の１００円でない商品であることをすぐに認識することができる。

図２（Ｂ）は、均一の売価である１００円（２７２）のマヨネーズを携帯端末１５０が認識した際に表示される画面２７０を示している。この場合には、均一の売価である１００円のマヨネーズ１１０であるため、価格が小さく表示されるようにして、図２（Ａ）のような画面２７０にアラートは表示されない。なお、アラートは、スピーカなどの音声又は音により携帯端末が顧客に報知してもよい。あるいは、携帯端末のバイブレーション機能を作動させて、顧客に報知してもよい。

なお、上記の例では、均一の売価以外の時に、アラートを報知した例を示したが、均一の売価のときにアラートが報知されるようにしてもよい。
なお、アラートの内容は、「均一価格でない商品です」又は「均一価格の商品です」のような内容であってもよい。すなわち、均一の売価の場合には、均一の売価であることが分かるように携帯端末が報知し、均一の売価以外の場合には、均一の売価以外であることがわかるように携帯端末が報知するようにしてもよい。
以上のように、均一の売価でないときに、携帯端末が顧客に所定の方法で報知することによって、顧客は、自身の購入額を適切に認識することができる。
報知の態様としては、例えば、均一の売価でないときは、均一の売価の商品よりも、携帯端末画面にその売価を大きく目立つように表示したり、上記のように、「均一価格でない商品です」というように、言葉によって表現を変えて、目立つようにしたり、音及び／又はバイブレーションをも併用して、顧客が均一の売価でないことを容易に認識できるようにしたりしてもよい。また、アラートを表示することなく、音又は音声がスピーカから出力されるのみであってもよく、バイブレーションが動作することだけであってもよい。

なお、上記の報知は、レジにおけるＰＯＳ端末においてなされてもよい。ＰＯＳ端末は、店舗の職員が操作するＰＯＳ端末、店舗の職員と顧客が共同して操作するＰＯＳ端末、顧客のみが操作するＰＯＳ端末等であってもよい。携帯端末は、ショッピングカートにあらかじめ設置されている端末であってもよい。

なお、野菜、果物など、バーコード等の識別標識が存在しない商品の場合には、予め設定された選択キー（プリセットキー）を画面１５１に表示させることで、顧客が画面に表示されたキー（例えば、野菜のキャベツであれば、キャベツの絵あるいは文字が表示されたキー）を押下することにより、購入しようとする商品の識別情報を端末に入力できるようにさせてもよい。
均一の売価は、第１の値の一例である。

＜実施例２＞

図３は、一実施例における構成を示すブロック図である。なお、各ブロックは、１つ以上の機器に分散して存在していてもよい。ブロック間の通信は、有線又は無線通信によって行われる場合がある。

商品情報取得部３１０は、例えば携帯端末１５０のカメラなどで撮像したバーコードを読むことにより商品情報３０５を取得する。上記したように、野菜などでバーコードがない商品で、商品情報が取得できない場合には、予め端末にプリセットキーを表示させることにより、キャベツなどの野菜の種類を適切に顧客又は店舗の職員が選択できるようにして、商品の情報を入力できるようにしてもよい。商品情報３０５は、商品の価格のみであり商品の識別情報を含まない情報であってもよい。少なくとも商品の価格が登録できれば、精算の処理を実行できるからである。なお、商品情報も併せて登録することができれば、在庫管理、商品販売戦略の策定等に商品情報を利用することができる。

商品情報取得部３１０で、商品の識別情報が取得できた場合であって、商品の価格が取得できていない場合には、商品の識別情報によって商品データベース３７０が検索されてもよい。商品データベース３７０は、携帯端末、ＰＯＳ端末などにあらかじめダウンロードされていてもよい。あるいは、商品データベース３７０は、店舗のサーバに存在していてもよい。商品データベース３７０がサーバに存在する場合には、店内の無線又は有線ＬＡＮ又はインターネットなどのネットワークを通じて、商品データベース３７０がアクセスされる。

商品情報取得部３１０が、商品の価格、商品識別情報、商品の個数などを取得すると、これらの情報は、登録部３２０に渡される。登録部３２０は、取得したこれらの情報を順次登録する。登録する情報は、ローカルの記憶装置又はネットワーク上のサーバなどの記憶装置に登録され得る。

登録部３２０は、登録された情報を順次報知部３３０に伝達する。報知部３３０は、例えば直近に登録された商品が、均一の売価でない場合には、均一の売価でないことを表示部３５０に通知する。表示部３５０は、均一の売価でないことを表示画面に表示することにより、報知してもよい。
既に述べたように、報知部３３０は、直近に登録された商品が均一の売価であることを報知するように動作してもよい。報知は、音、バイブレーションなどであってもよい。
登録部３２０は、登録された情報を第１の商品特定部３７５に提供する。

また、従来の販売管理の手法では、予算超過などが発生すると、顧客に対する購入商品に関するアドバイスの提供、スムーズな商品の返却など、顧客のニーズに適合するサービスが提供できていないことが多い。
第１の商品特定部３７５は、顧客個人情報記憶部３９５から、顧客が設定した予算設定表（図６、６１０）、商品カテゴリ別予算配分表（図６、６３０）から、顧客の予算に関する情報を取得する。

第１の商品特定部３７５は、上記の予算情報を基にして、購入しようとしている商品の価格の合計あるいは、商品カテゴリ別の商品の価格の合計などが、設定された予算を超えているか否かをチェックする。予算を超えている場合には、その旨を表示部３５０に通知して表示させる。
なお、月、週、日の予算のそれぞれの予算額と、その予算の期間の購入総額とを比較して、いずれかの予算額よりも購入額が超過していれば、購入者に予算額の超過を知らしめてもよい。あるいは、日の予算額が超過している場合のみ、キャンセル候補の商品又は代替品候補の商品を提案するようにして、月予算及び週予算については、予算が超過していることのみを購入者に知らしめるようにしてもよい。

第１の商品特定部３７５は、例えば、価格の総合計が予算を超えている場合には、携帯端末は、価格の高い商品、あるいは、返却すれば予算内になる商品を、返却候補として表示部３５０に表示して提案することができる。あるいは、携帯端末は、生活必需品以外のカテゴリの商品を返却候補としてリストの上位に表示することができる。
あるいは、均一の売価を取り扱う店舗においては、均一の売価以外の商品を返却候補として表示部３５０に表示して提案してもよい。
後述するように、返却する商品をリストから取り除きかつ商品を棚に戻すことで、商品登録のキャンセル処理及び商品の返却が容易に行える。

カテゴリ別の予算を超えている場合には、第１の商品特定部３７５は、例えば、当該カテゴリの商品のうちで、価格の高い商品、あるいは、返却すれば予算内になる商品を、返却候補として表示部３５０に表示して提案する。

予算を超えていて返却する商品を提案する場合には、第１の商品特定部３７５は、その旨を第２の商品特定部３８０に通知する。第２の商品特定部３８０は、例えば、返却の提案をする商品に代替する商品があれば、その商品を特定して、表示部３５０に表示するよう指示する。
返却候補の商品に代替する商品は、返却候補の表示の直上に新たな欄を挿入して、代替商品の提案であることが分かるように、画面に表示されるようにしてもよい（不図示）。

具体的な代替商品の特定方法は以下のとおりである。例えば、多数の同じスナック菓子を購入して、スナック菓子の合計価格がその日の予算配分を超過している場合には、そのスナック菓子の個数を減らすように提案してもよい。
また、不定貫の商品、例えば１００グラム５５０円のＸ牛肉を１キログラムで５，５００円購入しようとして、生鮮食料品の予算が１，０００円オーバーした場合を想定する。この場合には、１００グラム４００円のＹ牛肉を１キログラム４，０００円で購入する代替案を提案することができる。この提案によって、１，５００円の節約ができることとなり、１，０００円の予算超過を回避することができる。
卵などのパック詰めの商品の場合には、8個の卵のパック詰め商品を顧客が購入しようとしたために予算が超過している場合には、４個詰めの卵のパック詰めを購入する提案が画面に表示されてもよい（不図示）。
上記実施形態によれば、不定貫の商品及びパック詰めの商品についても、予算超過の際に代替案を提示することができる。
予算額は、第２の値の例である。

また、商品部門・カテゴリとは別に、顧客は、商品の単価の上限をその商品の予算としてもよい。不定貫の商品の場合には、顧客は、単価及び総額の両者の上限を設定できるようにしてもよい。

商品の部門・カテゴリをどのように設定するか、返却する商品の優先順位のアルゴリズムをどのように設定するかは、顧客の希望にできるだけ添う形で顧客が設定できるように設定項目を増やしておくことも重要である。
また、例えば高級品の購入があった場合は、単価が高額な順番で返却する商品を提案しても良い。
また、購入したい商品部門・カテゴリの上限の価格を顧客が設定できるようにしてもよい。

以上のような提案を顧客に提供することによって、顧客の無駄遣い防止に役立つ。顧客が商品の購入を断念する際に購入キャンセルがスムーズになるという利点がある。

以上の場合には、いったん購入しようとした商品を返却する必要がある。また、いったんカートに入れてしまったＡ商品をＢ商品に交換することが必要となる場合がある。この場合、顧客が、返却・代替要求受付部３６０に販売位置の提示を要求すると、後述するように、返却する商品あるいは交換する商品の店舗内での販売位置を画面１５１に表示することができる。商品陳列位置特定部３９０は、それぞれの商品の陳列位置を特定し、顧客の現在位置から陳列位置までの経路を表示するよう表示部３５０に指示する。

返却・代替要求受付部３６０が顧客から受け取った情報は、登録部３２０に伝達され、登録情報が変更される。登録部３２０に登録された情報が変更されると、その更新された登録情報に基づいて、第１の商品特定部３７５が、予算超過が依然として存在するか否か及び返却候補の特定があるか否かの処理を行い、その後、上記と同様の処理が繰り返されてもよい。
顧客又は店舗職員が、精算の指示を精算部３６５に与えた場合には、精算部３６５は、精算の処理を行う。

なお、予算金額、商品カテゴリ別の予算配分等の顧客個人情報は、顧客があらかじめ顧客個人情報記憶部３９５に記憶させておくことができる。顧客個人情報記憶部３９５は、携帯端末１５０あるいは、店舗の管理サーバ（図９、９１０）の記憶部に存在していてもよい。顧客は、会員ＩＤとパスワードによって、店舗の管理サーバに携帯端末１５０あるいは所有しているＰＣからインターネットなどのネットワークを介してアクセスし、予算金額などの情報をあらかじめ登録できるようにしてもよい。

図４は、本実施例の処理を示すフローチャートである。各ステップについて順を追って説明する。
［Ｓ４１０］購入しようとする商品の商品情報が取得される。ステップＳ４１５に進む。

［Ｓ４１５］取得された商品情報に、商品の価格が含まれているか否かが判断される。商品情報が含まれている場合（「はい」）の場合には、ステップＳ４２０に進む。商品情報が含まれていない場合（「いいえ」）の場合には、ステップＳ４７５に進む。

［Ｓ４７５］商品情報に価格が含まれていない場合には、商品情報に含まれている商品識別情報を用いて、商品識別情報と価格の対応表が格納された商品データベース３７０が検索され、購入しようとする商品の価格が取得され、商品情報にその価格の情報を含ませる処理が行われる。ステップＳ４２０に進む。
［Ｓ４２０］少なくとも商品の価格を含む商品情報が登録部３２０に登録される。ステップＳ４２５に進む。

［Ｓ４２５］１００円ショップなどの店舗において単一の売価（１００円）で多くの商品が販売されている場合において、直近に登録された商品の価格が単一の売価であるか否か判断される。商品の価格が単一の売価である場合には（「はい」）、ステップＳ４３０に進む。商品の価格が単一の売価でない場合には（「いいえ」）、ステップＳ４８０に進む。このフローの場合、単一の売価の商品を扱っていない店舗においては、「はい」として、Ｓ４３０に進むこととする。（なお、このステップでは、商品の価格が単一の売価のときに報知を行わせたい場合には、判断基準を逆にすることで適切な判断ができる。あるいは、いずれの場合にも、報知を行わせたい場合には、商品の価格が単一売価であることあるいは、単一の売価でないことを知らしめるため、ステップＳ４８０とステップＳ４３０との両者を実行させることとしてもよい。）

［Ｓ４３０］登録部３２０に登録されている商品のそれぞれの価格に関して所定のアルゴリズムによって、総合計及びカテゴリ別の合計の金額が計算され、各々があらかじめ定められた予算を超えるか否かが判断される。計算結果のいずれもが予算を超過していない場合（「いいえ」）は、ステップＳ４１０に戻る。いずれかの予算に対して超過することが発見された場合は（「はい」）、超過している予算項目に応じた処理をするため、ステップＳ４３５に進む。

［Ｓ４３５］予算が超過している項目（総予算、カテゴリ別予算配分の予算）について、予算の超過が回避されるように、すでに登録された商品のうち、購入を取りやめて返却する候補の商品が特定され提案される。返却される商品の特定の手法は、例えば図３の第１の商品特定部３７５ですでに述べた手法が適用できる。処理は、ステップＳ４４０に進む

［Ｓ４４０］購入を取りやめて返却する候補の商品に代替して購入する商品の候補が特定され提案される。なお、代替して購入する商品が発見できない場合には、代替商品無しとの結果が得られる。処理は、ステップＳ４５０に進む。

［Ｓ４５０］顧客の要求に応じて、返却する商品及び代替して購入する商品の店舗内での位置が顧客に分かるように、販売位置の探索が行われ販売位置が表示される。処理はステップＳ４７０に進む。

［Ｓ４７０］顧客から、返却する商品及び代替して購入する商品並びに返却する商品のいずれかが指示されたか否かが判断される。判断が「はい」である場合には、ステップＳ４６５に進む。判断が「いいえ」であれば、ステップＳ４８５にすすむ。顧客は、予算超過に関する提案を無視して、精算処理に進むこともできる。

［Ｓ４６５］顧客から、返却する商品及び代替して購入する商品並びに返却する商品のうち、指示された情報が取得され、ステップＳ４１５に戻る。

［Ｓ４８５］顧客が、精算処理を望んでいれば、精算処理が行われる。精算は、具体的には精算ボタン（不図示）を押下するなどで開始される。精算処理画面に進むと決済手段決定画面となり、客は、現金支払い、クレジット支払い、電子マネーなど、どの決済手段で支払いを行うか決定する。決済手段が決定されれば、以降それぞれの決済手段で決済処理が進む。なお、ここでは精算処理に進むフローを示したが、顧客が精算処理を望まない場合には、買い物を続けることもできる。

釣銭が発生する場合は、釣銭取り忘れを防止するために、客が釣銭をすべて取り除いた段階（使用不可の硬貨などのリジェクト用の払出口がある場合は、リジェクトされた硬貨も取り除かれた段階）で、領収書、もしくはレシートの発行が行われる。

顧客が現金で支払う場合は、現金投入金額が買上金額を超えた段階で「精算終了＝おわり」ボタンが操作可能となる。但し、小銭を使用して釣銭調整をしたい場合などがあるので、「精算終了＝おわり」ボタンを押下するタイミングは任意のタイミングである。
なお、領収書に印紙等が必要な場合は、システムが自動的に店員を呼び出すようにしてもよい。

＜実施例３＞
図５は、新たな商品が登録部に登録された際に、顧客の予算を勘案して適切な購入アドバイスを提供する例を示すフローチャートである。

顧客が店舗の会員でない場合は、店舗に入った段階で予算金額のみを設定することとなってもよい。顧客が店舗の会員として既に登録されている場合は、顧客が事前に詳細な情報を設定することで、顧客に対して様々な報知が可能である。詳細な情報の設定例については、図６を用いて後述する。
図５の各ステップについて順を追って説明する。

［Ｓ５１０］新たな商品登録があれば、カテゴリ別に商品の合計額が計算される。新たな商品の情報が登録されるたびにこの計算が行われることによって、顧客に対して迅速に適切な情報を提供することができる。ステップＳ５１５に進む。

［Ｓ５１５］各カテゴリの商品の合計額とそれぞれ対応する予算とを対比し、予算金額を超過しているカテゴリがあるか否かを判断する。判断結果において、予算超過が１つでも発見できた場合にはステップＳ５２０に進む。予算超過が発見できなかった場合、あるいは予算を超過しても、その判断を無視して顧客が買い物を続行すると希望している場合には、ステップＳ５４５に進む。
［Ｓ５２０］ステップＳ５３０との間で、各カテゴリについての処理を繰り返す。

［Ｓ５２５］予算が超過しているカテゴリの商品のうち所定の規則に従って、返却候補となる当該カテゴリの商品（カテゴリ別の返却候補の商品）を特定する。返却候補の商品の特定の手法については、図３の第１の商品特定部３７５の動作の説明で詳述したので、説明を省略する。顧客が商品の返却を無視することも含めて、次にステップＳ５４０に進む。
［Ｓ５４０］返却された商品を登録部から除外して総合計を計算する。ステップＳ５４５に進む。

［Ｓ５４５］総合計が予算を超過しているか否かを判断する。この判断結果が「いいえ」であれば、処理はＳ５１０に戻る。顧客が予算を無視する場合にも（買い物続行の場合）ステップＳ５１０に戻る。判断結果が「はい」であれば、ステップＳ５５０に進む。
［Ｓ５５０］返却候補となる商品を特定し、表示する。次にステップＳ５５５に進む。
［Ｓ５５５］顧客による商品の返却指示の受付を行う。顧客が商品の返却を無視することも含めて、次にステップＳ５６０に進む。
［Ｓ５６０］返却された商品があればそれを除外して総合計を再計算してステップＳ５１０に戻る。
［Ｓ５７０］割り込み処理で、顧客から精算の指示があれば、このフローを終了し、精算処理に移行する。

図６は、顧客又は店舗職員があらかじめ登録しておく情報の例を示す図である。顧客は、店舗の会員になることで、例えば店舗の管理するＷＥＢサーバにアクセスすることができるようにしてもよい。あるいは、店舗が配布する携帯端末用のアプリケーションを顧客が携帯端末にダウンロードして利用できるようにしてもよい。このアプリケーションを通じて、店舗のサーバに接続できるようにしてもよい。店舗のサーバ又は顧客の携帯端末のアプリケーションなどに図６に示すデータが格納されるようにしてもよい。

図６（Ａ）は、予算設定表６１０の例を示している。この予算設定表６１０は、顧客ごとに作成される。顧客は、様々な予算のルールを設定できるようになっている。予算設定表６１０は、設定区分６１１、時期６１２、金額６１３の項目を含んでいる。

例えば、通常月予算は、総予算として、金額１２万円が設定されている。顧客は通常月においては、１２万円を限度として買い物をすることを望んでいることがわかる。その他、ボーナス月予算における予算は１８万円、週予算は３万円、給与日翌週予算は４万円、日単位の予算は４千円と設定されている。
例えば、週の半ばで、その週の総予算を超えている場合には、週の予算が超過していることが、顧客に伝達され、返却する商品の候補が顧客に伝達される。その他の予算項目見ついても、その予算項目が超過した時点で、顧客にその旨が伝達されるとともに、返却する候補の商品が顧客に示されるようにしてもよい。

図６（Ｂ）は、商品カテゴリ別予算配分表６３０である。商品カテゴリ別予算配分表６３０は、カテゴリ名称６３１、カテゴリコード６３２、総予算に対する割合６３３を含む。カテゴリ名称６３１は、顧客に分かりやすい商品カテゴリの名称である。カテゴリコード６３２は、携帯端末、ＰＯＳ端末、店舗のサーバなどが使用するためのコードである。総予算に対する割合６３３は、予算設定表６１０の総予算に対する商品カテゴリ別の予算配分の割合を定義するものである。

例えば、生鮮食料品については、顧客は、予算の３０％を割り当てることができることを示している。その他、ドライ食品、惣菜、スナック菓子等のカテゴリ毎の予算配分が設定できるようになっている。

なお、カテゴリ別の予算は、総予算に対する配分ではなく、顧客が金額を設定できるようにしてもよい。顧客のニーズに合わせて、カテゴリ別の予算金額を設定できる項目を設けてもよい。

図６（Ｃ）は、商品カテゴリグループ定義表６５０の例を示している。例えば、カテゴリグループ名称６５１としてＡグループ、カテゴリグループコード６５２として１１０、カテゴリ６５３として日用品（４７６１）と医療（７１６１）が割り当てられている。
この商品カテゴリグループ定義表６５０は、システムにおいてあらかじめ定義されており、予算を定義する際に顧客が利用できるようにしてもよい。

以上のように詳細な予算設定を会員の顧客が設定できるようになっている。顧客が予算を設定できるようにすることで、顧客は余分な買い物をすることを防止することができる。また、例えば、夫婦が別々の時間帯に買い物をする場合であっても、両者の携帯端末にインストールしたアプリケーションが購入商品の情報を共有し、画面に表示することにより、夫婦が同じ日に同じ商品を重複して買ってしまうことなどを未然に防止できる。また、夫婦の買い物の時間帯が異なっていても、夫婦の買い物の合計額が予算内に収まるように買い物をすることができる。

＜実施例４＞

図７は、顧客に対して表示画面に表示するユーザーインタフェースの例を示す図である。携帯端末、タブレット、店舗用専用端末、ＰＯＳ端末等の画面に表示される様々な情報の例が示されている。

図１（Ａ）は、総予算がオーバーした場合の画面表示７１０を示している。「予算オーバーです」（７１１）というメッセージが大きく表示されている。予算７１２は、購入日の予算が４０００円であることを示している。合計額７１３は、購入予定であるとして登録した商品の金額の総合計（７１３）が、４５１０円であることを示している。オーバー額（７１４）は、その差である５１０円だけ予算をオーバーしていることを示している。図１（Ａ）に図示されているように、予算がオーバーしている５１０円が白黒反転表示されるようにしてもよい。

選択候補の表７２４には、商品を返却する候補の優先度を表示するアルゴリズムとして、金額の高い商品の順番で返却する候補を表示するアルゴリズムを採用している。したがって、金額の一番高い２３００円の刺身が一番上に表示されている。商品を返却する候補の優先度を表示するアルゴリズムは、このアルゴリズムに限定されるものではない。
選択候補の表７２４には、品名７１５、購入予定個数７１８、単価７２０、商品金額７２１が返却候補の順番に表示されている。

キャンセル指定ボタン７１６によって、顧客は、返却する商品の表示部分を選択することを意思表示することができる。キャンセル指定ボタン７１６を押した後に、返却する商品を選択することができるように表示画面７３０を表示してもよい。

買物続行ボタン７１９は、顧客が、予算オーバーを無視して、買い物を継続することを宣言するためのボタンである。買い物を継続する場合は、「予算２０パーセントオーバー」など、あらかじめ設定した値で、携帯端末が次の報知を行うようにしてもよい。
スクロールバー７２２は、返却候補の表７２４の表示をスクロールするためのものである。

図７（Ｂ）は、キャンセル処理が終了したときの表示画面７３０を示している。購入中止ボタン７３６は、購入を中止して商品を返却することを宣言するボタンである。「購入モードへ」ボタン７３９は、キャンセル処理を終わらせるボタンである。個数７４２の横にある「＋」７４３は、返却を指定した商品の個数を増加させるボタンである。「−」７４４は、返却を指定した商品の個数を減少させるボタンである。

図７（Ｂ）は、顧客がキャンセル指定ボタン７１６を押した後の画面を示している。この場合、画面は、図７（Ａ）の表示から、図７（Ｂ）の表示に変わり、「キャンセル処理」７３１が表示されるようになる。その後、例えば、顧客がポテトチップス７１０の欄をタップして、返却する商品としてポテトチップスを選択する。選択されたポテトチップスの欄は、グレーなどに表示されてもよい（不図示）。その後、「＋」ボタン７４３を１回押して、返却個数を２個に増加させる。その後購入中止ボタン７３６を押すと、ポテトチップスの行が反転表示されるとともに、購入中止ボタン７３６も反転表示される。購入中止ボタン７３６が押されてから、例えば３秒後に、反転表示されたポテトチップスの行が削除されて、ポテトチップスの登録が解除されるようにしてもよい。そして、顧客は、ポテトチップスを棚に戻す。
以上の操作手順は一例であって、その他の操作手順で商品の返却処理を入力できるようにしてもよい。例えば、購入中止ボタン７３６をタップしてから、商品のバーコードを読み込ませることで、キャンセル処理を実行させてもよい。

以上の処理で、予算額７３２の４０００円に対して、合計額７３３は、３７００円となり、予算余裕額７３４の表示に変わり、その額が３００円となり、予算内に収まっていることがわかる。そして、「予算内です」７４０のメッセージが表示される。顧客は、「購入モードへ」ボタン７３９を押すことで、購入を継続してもよい。

顧客は、精算ボタン（不図示）を押せば精算処理に移行することができる。なお、顧客は、精算処理に移行せずに、新たな商品を携帯端末に読み取らせることによって、買い物を継続することもできる。
また、例えば購入する商品の一覧から、商品を指定すると代替品候補が表示されてもよい。

＜実施例５＞
図８は、商品を返却するときなどに商品の陳列場所を表示する例を示す図である。

店舗内の地図が、画面１５１に表示されている。顧客は、現在位置８１０に位置していることがわかる。顧客の位置は、携帯端末の位置検知機能を使って携帯端末自身が把握することができる。塩を返却する位置が知りたい場合には、塩の販売場所８３０が、画面に表示される。加えて、目的地までの最短の経路８２０が表示されてもよい。

図８に示す機能は、顧客が商品を返却する場合ばかりでなく、商品を購入する際に、携帯端末に商品名を音声で入力するなどの行為によっても表示されるようにしてもよい。
あるいは、あらかじめ、顧客が複数の購入予定の商品を入力しておけば、複数の購入予定の商品の陳列場所と適切な買い物の順番を示す買い物のルートが画面１５１に表示されるようにしてもよい。

＜システム構成＞
図９は、一実施例のシステム９００の構成を示す図である。
携帯端末９３２、携帯端末９３４及びＰＯＳ端末９１２は、商品９１７、商品９１６及び商品９１５を認識し商品情報を読み取ることができる。

また、携帯端末９３２、携帯端末９３４及びＰＯＳ端末９１２は、ＷＩＦＩ、Bluetooth（登録商標）などの無線ネットワークを介して相互に通信することができ、商品情報等を共有することができる。

さらに、携帯端末９３２及び携帯端末９３４は、インターネットなどの広域ネットワークに接続することもできる。広域ネットワーク９６０を介して、電子決済業者システム９５０及び店舗の管理サーバ９１０とも情報を交換することができる。また、店舗のＰＯＳ端末９１２は、店舗のネットワークを通じて店舗の管理サーバと接続している。
このようなシステム９００により、顧客は、上記実施例を利用することができ、精算は、現金ばかりでなく、電子決済により行うこともできる。

＜ハードウエア構成＞
図１０は、一実施例のハードウエア構成１０００を示す図である。

ハードウエア構成１０００は、ＣＰＵ１００２、メモリ１００４、通信制御部１００６、入力インタフェース１００８、表示制御部１０１０、外部メモリ制御部１０１２及び出力インタフェース１０１４を有する。

そして、通信制御部１００６には、ネットワーク１０３０（ＷＩＦＩ、有線ＬＡＮ、広域ネットワーク（インターネット）、近距離無線通信等）が接続される。入力インタフェース１００８には、タッチ感知センサ１０４０などが接続される。表示制御部１０１０には、ディスプレイ１０５０が接続される。外部メモリ制御部１０１２は、記憶媒体１０６０を読み書きすることができる。出力インタフェースには、スピーカ又はバイブレータ１０７０などが接続される。
記憶媒体１０６０は、ＲＡＭ、ＲＯＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、メモリーカード等であってもよい。

以上説明した実施例のプログラムは、ハードウエア構成１０００を備えるコンピュータにより実行され得る。また，実施例のプログラムは，コンピュータに実行させる方法として，インプリメントされてもよい。本実施例のプログラムの一部又は全部は、オペレーティングシステムにより実行されてもよい。また、プログラムの一部がハードウエアにより実現されてもよい。プログラムは記憶媒体１０６０又はメモリ１００４に記憶されてもよい。
なお，上述の実施例において，プログラムのステップは、矛盾のない限り，同時に，又は順序を入れ替えて実行されてもよい。
以上の実施例は，ハードウエアの装置としてインプリメントされ得る。
以上の実施例は，請求項に記載された発明を限定するものではなく，例示として取り扱われることは言うまでもない。

３１０ 商品情報取得部
３２０ 登録部
３３０ 報知部
３５０ 表示部
３６０ 返却・代替要求受付部
３６５ 精算部
３７０ 商品データベース
３７５ 第１の商品特定部
３８０ 第２の商品特定部
３９０ 商品陳列位置特定部
３９５ 顧客個人情報記憶部

Claims (6)

1. 購入する商品に関する商品情報を取得する商品情報取得部と、
   前記商品情報を順次登録する登録部と、
   新たに登録された商品情報に係る商品の価格が第１の値と一致しない場合に一致しないことを知らしめるように、報知を行う報知部と、
   を有する商品販売データ管理装置。
2. 前記第１の値は、店舗で販売される所定の複数の商品に共通に付与される均一の売価である、
   請求項１に記載の商品販売データ管理装置。
3. 商品の陳列位置を表示装置に表示する商品陳列位置特定部、
   を更に有する請求項１又は２に記載の商品販売データ管理装置。
4. 前記請求項１ないし３のいずれか１項記に記載の商品販売データ管理装置は、顧客が操作する携帯端末であり、
   複数の顧客が共同して複数の前記携帯端末を用いて、商品を購入する場合であって、前記複数の顧客の各々が前記携帯端末の各々を使用する場合には、前記複数の携帯端末の間で無線通信を行うことで、前記複数の携帯端末が少なくとも前記購入する商品の商品情報を共有する、商品販売データ管理システム。
5. 前記携帯端末と無線通信を行うＰＯＳシステムを更に有し、
   前記ＰＯＳシステムは、無線通信を行うことで、少なくとも前記商品情報を前記携帯端末と共有し、販売商品の決済処理を行う決済処理部を有する、
   請求項４記載の商品販売データ管理システム。
6. 購入する商品に関する商品情報を取得するステップと、
   前記商品情報を順次登録するステップと、
   新たに登録された商品情報に係る商品の価格が第１の値と一致しない場合に一致しないことを知らしめるように、報知を行うステップと、
   をコンピュータに実行させる、商品販売データ管理プログラム。
   
   
   
   

Images