JP2023160917A - 取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラム - Google Patents

取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラム Download PDF

Info

Publication number
JP2023160917A
JP2023160917A JP2023143053A JP2023143053A JP2023160917A JP 2023160917 A JP2023160917 A JP 2023160917A JP 2023143053 A JP2023143053 A JP 2023143053A JP 2023143053 A JP2023143053 A JP 2023143053A JP 2023160917 A JP2023160917 A JP 2023160917A
Authority
JP
Japan
Prior art keywords
processor
data
product
store
payment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023143053A
Other languages
English (en)
Inventor
茂樹 二宮
Shigeki Ninomiya
文雄 中司
Fumio Nakatsuka
幹生 伊藤
Mikio Ito
清充 山口
Kiyomitsu Yamaguchi
剛士 川本
Takeshi Kawamoto
卓哉 羽毛田
Takuya Haketa
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba TEC Corp
Original Assignee
Toshiba TEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba TEC Corp filed Critical Toshiba TEC Corp
Priority to JP2023143053A priority Critical patent/JP2023160917A/ja
Publication of JP2023160917A publication Critical patent/JP2023160917A/ja
Pending legal-status Critical Current

Links

Landscapes

  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】客が購入商品として登録しようとしたものの正しく登録できなかった商品が決済されることなく持ち出されることを防止する。
【解決手段】 実施形態の取引処理システムは、登録手段、決済手段、取得手段及び制御手段を備える。登録手段は、端末における操作により指定された商品を、端末を利用している客による購入対象の商品として登録する。決済手段は、登録手段により登録された商品の代金を客に決済させるための決済処理を行う。取得手段は、登録手段により購入対象として登録できなかった商品が有る場合に、端末における操作により指定されるデータを取得する。制御手段は、取得手段により取得されたデータが予め定められた解除データである場合に、決済手段による決済処理の開始を許容する。
【選択図】 図17

Description

本発明の実施形態は、取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法に関する。
客による端末装置の操作に応じて取引の内容を登録する取引処理システムが、例えばカートPOSシステム又はスマホPOSシステムなどとして考えられている。
このようなシステムにおいては、クレジットカード決済又はバーコード決済などの決済方法を用いれば、決済の処理は端末装置における客の操作に応じて完結することが可能である。また、客の操作に応じて決済処理を行うセルフタイプの会計機を用いれば、決済の処理は会計機における客の操作に応じて完結することが可能である。そしてこのようにして決済を完結できれば、店員が関与すること無しに取引を完了することが可能である。
ところで、新規に販売を開始した商品、あるいは期間限定で販売する商品などに関しては、商品データベースへの登録が遅れるなどして、商品データベースに登録されていない商品が店舗に陳列されてしまうことがあり得る。また、商品には商品コードを表したバーコードとは別のバーコードが表示される場合もあり、当該商品コードを表さないバーコードを客が端末装置に読み取らせてしまうことも考えられる。これらのケースでは、該当の商品を購入商品として登録することができないが、客は登録できたと思い込んでしまう場合がある。
そしてこのような状況で、店員が関与することなしに決済が行えてしまうと、決済されていない商品が客によって持ち出されてしまうことになる。
このような事情から、客が購入商品として登録しようとしたものの正しく登録できなかった商品が決済されることなく持ち出されることを防止できることが望まれていた。
特開2019-144797号公報
本発明が解決しようとする課題は、客が購入商品として登録しようとしたものの正しく登録できなかった商品が決済されることなく持ち出されることを防止できる取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法を提供することである。
実施形態の取引処理システムは、登録手段、決済手段、取得手段及び制御手段を備える。登録手段は、端末における操作により指定された商品を、端末を利用している客による購入対象の商品として登録する。決済手段は、登録手段により登録された商品の代金を客に決済させるための決済処理を行う。取得手段は、登録手段により前記購入対象として登録できなかった商品が有る場合に、端末における操作により指定されるデータを取得する。制御手段は、取得手段により取得されたデータが予め定められた解除データである場合に、決済手段による決済処理の開始を許容する。
一実施形態に係る取引処理システムの概略構成を示すブロック図。 図1中の店舗サーバの要部回路構成を示すブロック図。 図1中の仮想POSサーバの要部回路構成を示すブロック図。 図1中のモバイルコントローラの要部回路構成を示すブロック図。 図4に示す取引管理データベースに含まれるデータレコードの主要なデータ構造を示す模式図。 図4に示す登録データベースに含まれるデータレコードの主要なデータ構造を示す模式図。 図1中の通信サーバの要部回路構成を示すブロック図。 図1中のユーザ端末の要部回路構成を示すブロック図。 図8に示されるプロセッサによる情報処理のフローチャート。 図8に示されるプロセッサによる情報処理のフローチャート。 図8に示されるプロセッサによる情報処理のフローチャート。 図8に示されるプロセッサによる情報処理のフローチャート。 図8に示されるプロセッサによる情報処理のフローチャート。 図4に示されるプロセッサによる情報処理のフローチャート。 図4に示されるプロセッサによる情報処理のフローチャート。 図4に示されるプロセッサによる情報処理のフローチャート。 図4に示されるプロセッサによる情報処理のフローチャート。 一覧画面の一例を示す図。 登録画面の一例を示す図。 一覧画面の一例を示す図。 一覧画面の一例を示す図。 ガイダンス画面の一例を示す図。 確認画面の一例を示す図。 解除画面の一例を示す図。 警告画面の一例を示す図。 会計画面の一例を示す図。
以下、取引処理システムの一実施形態について、図面を用いて説明する。
この実施形態における取引処理システムは、購入者に年齢制限が定められている等の事情により、販売に際して店員による確認を要する商品(以下、要確認商品と称する)を含んだ複数の商品を、来訪した客に対して販売する店舗における商品の取引を処理する。
図1は、本実施形態に係る取引処理システムの概略構成を示すブロック図である。
取引処理システムは、複数の店舗システム100、中継サーバ200及びユーザ端末300を、通信ネットワーク400を介して通信可能として構成される。
図1では、2つの店舗システム100を示している。これら店舗システム100は、取引処理システムを利用するそれぞれ異なる店舗A及び店舗Bにそれぞれ設けられる。取引処理システムを利用する店舗が3つ以上存在してもよく、店舗毎に店舗システム100が設けられる。なお以下において、各店舗に設けられた店舗システム100を区別する必要がある場合には、店舗Aに設けられた店舗システム100を店舗システム100Aと表し、店舗Bに設けられた店舗システム100を店舗システム100Bと表す。
店舗Aを運営する事業者は、店舗Bを運営する事業者と同じであっても、別であってもよい。その他の店舗で取引システムが利用される場合も、その店舗を運営する事業者は、店舗A又は店舗Bを運営する事業者と同じであっても、別であってもよい。
中継サーバ200は、ユーザ端末300と店舗システム100との間でのデータ通信を中継する。中継サーバ200は例えば、通信ネットワーク400を介したクラウドサービスとしてデータ通信の中継機能を提供する。
ユーザ端末300は、取引システムを利用した買い物を店舗にて行う客のためのユーザインタフェースとして機能する情報通信端末である。ユーザ端末300は、店舗システム100と無線通信する機能と、通信ネットワーク400と無線通信する機能とを備える。ユーザ端末300としては、スマートフォン又はタブレット端末等のデータ通信機能を備えた通信端末が利用できる。ユーザ端末300は、客により所有されていてもよいし、店舗にて客に貸与されてもよい。
通信ネットワーク400としては例えば、インターネット、VPN(virtual private network)、LAN(local area network)、公衆通信網、移動体通信網などを、単独又は適宜に組み合わせて用いることができる。通信ネットワーク400としては典型的には、移動体通信網とインターネット又はVPNとが利用される。
各店舗システム100の概略的な構成は共通である。すなわち店舗システム100は、店舗サーバ1、仮想POSサーバ2、モバイルコントローラ3、通信サーバ4、会計機5及びアクセスポイント6を、店内通信ネットワーク7を介して通信可能として構成される。ただし、店舗サーバ1、仮想POSサーバ2、モバイルコントローラ3、通信サーバ4、会計機5、アクセスポイント6及び店内通信ネットワーク7は、後述する動作を実現するための機能が共通であればよく、完全に同一である必要は無い。また一部の店舗システム100は、図1に示されない装置を備えてもよい。
店舗サーバ1は、店舗システム100により後述のように実現される取引処理の対象となった複数の取引を総合的に管理する。店舗サーバ1は例えば、既存のPOSサーバと同様な機能を有する。
仮想POSサーバ2は、外部からの要求に応じて取引毎の購入商品の登録及び当該購入商品の代金の決済などのための情報処理を行う。つまり仮想POSサーバ2は、既存のPOS端末が備える機能を仮想的に実現する。仮想POSサーバ2が行う情報処理は、店舗毎の運営方針の違いに適応するようにカスタマイズされる。つまり、例えば店舗システム100Aに備えられた店舗サーバ1が行う情報処理と、店舗システム100Bに備えられた店舗サーバ1が行う情報処理とでは、一部相違する場合がある。
モバイルコントローラ3は、仮想POSサーバ2による上記の情報処理を、ユーザ端末300をユーザインタフェースデバイスとして用いつつ行わせるための支援を行う。モバイルコントローラ3は、取引支援装置の一例である。
通信サーバ4は、店舗サーバ1、仮想POSサーバ2、モバイルコントローラ3及び会計機5が、通信ネットワーク400を介して中継サーバ200等とデータを授受するための通信処理を行う。
会計機5は、仮想POSサーバ2で管理されている取引毎の購入商品に関する代金を求めて、当該代金を客に決済させるための処理を行う。会計機5が上記の決済のために利用可能とする決済方法は、現金決済、クレジットカード決済、電子マネー決済、ポイント決済、コード決済(モバイル決済又はスマートフォン決済等とも称される)等、周知の決済方法の全て又は任意の一部であってよい。会計機5は、店員及び客のいずれにより操作されるのであってもよい。会計機5としては例えば、既存のセミセルフ方式のPOSシステムで用いられるセルフ方式の会計機を用いることができる。会計機5は、商品を購入商品として登録するための情報処理を行う機能を有していてもよい。この場合に会計機5としては例えば、既存のPOSシステムで用いられる対面式のPOS端末又は既存のセルフ方式のPOSシステムで用いられるセルフ式のPOS端末を用いることができる。
アクセスポイント6は、ユーザ端末300が無線通信により店内通信ネットワーク7へとアクセスすることを可能とするための通信処理を行う。アクセスポイント6としては例えば、IEEE802.11規格により無線通信を行う周知の通信デバイスを用いることができる。アクセスポイント6は、店舗の売場のどこからでもユーザ端末300が無線通信可能なように、店舗内に設置される。店舗規模によっては、複数のアクセスポイント6が、1つの店舗システム100に配置される場合もある。
店内通信ネットワーク7としては、インターネット、VPN、LAN、公衆通信網、移動体通信網などを、単独又は適宜に組み合わせて用いることができる。ただし典型的には、店内通信ネットワーク7は、LANである。
店舗システム100が設けられた店舗には、その入口付近にチェックイン用の2次元コードTC1が掲示され、その出口付近にチェックアウト用の2次元コードTC2が掲示される。2次元コードTC1は、チェックインのためのチェックインデータを表す。2次元コードTC2は、チェックアウトのためのチェックアウトデータを表す。チェックインデータ及びチェックアウトデータは店舗毎に異なる。このため、店舗A用の2次元コードTC1,TC2と店舗B用の2次元コードTC1,TC2とを区別する必要がある場合には、店舗A用を2次元コードTC1A,TC2Aと表し、店舗B用を2次元コードTC1B,TC2Bと表す。
チェックインデータは例えば、以下に示すような情報を表す。
(1) 店舗システム100の動作バージョン。例えば、2次元コードTC1Aが表すチェックインデータは、店舗システム100Aの動作バージョンを表す。2次元コードTC1Bが表すチェックインデータは、店舗システム100Bの動作バージョンを表す。
(2) 店舗システム100が設けられる店舗を運営する事業者を識別するための事業者コード。例えば2次元コードTC1Aが表すチェックインデータは、店舗Aを運営する事業者に割り当てられた事業者コードを表す。2次元コードTC1Bが表すチェックインデータは、店舗Bを運営する事業者に割り当てられた事業者コードを表す。
(3) 店舗システム100が設けられる店舗を識別するための店舗コード。例えば2次元コードTC1Aが表すチェックインデータは、店舗Aに割り当てられた店舗コードを表す。2次元コードTC1Bが表すチェックインデータは、店舗Bに割り当てられた店舗コードを表す。なお店舗コードは、取引処理システムを利用する全ての店舗の個々を識別可能なものであってもよいし、同じ事業者により運営される複数の店舗の個々を識別可能なものであってもよい。
(4) 店舗システム100が設けられる店舗を運営する事業者の名称。例えば2次元コードTC1Aが表すチェックインデータは、店舗Aを運営する事業者の名称を表す。2次元コードTC1Bが表すチェックインデータは、店舗Bを運営する事業者の名称を表す。
(5) 店舗システム100が設けられる店舗の名称。例えば2次元コードTC1Aが表すチェックインデータは、店舗Aの名称を表す。2次元コードTC1Bが表すチェックインデータは、店舗Bの名称を表す。
(6) 2次元コードTC1と2次元コードTC2とを区別するためのフラグ。チェックインデータにおける当該フラグは、チェックインデータであることを表す状態とされる。当該状態は、例えば“1”である。当該フラグは、全ての2次元コードTC1で共通である。
(7) 通信サーバ4のIPアドレス。例えば2次元コードTC1Aが表すチェックインデータは、店舗システム100Aに含まれる通信サーバ4のIPアドレスを表す。2次元コードTC1Bが表すチェックインデータは、店舗システム100Bに含まれる通信サーバ4のIPアドレスを表す。
(8) 中継サーバ200のドメイン名。当該ドメイン名は、全ての2次元コードTC1で共通である。ただし、ドメイン名が互いに異なる複数の中継サーバ200が、店舗毎に使い分けられてもよい。そしてこの場合には、2次元コードTC1が表すチェックインデータは、対応する店舗で使用される中継サーバ200のドメイン名が表される。
(9) 電子レシートサーバのアドレス。電子レシートサーバは、図1に示す取引処理システムに含まれず、通信ネットワーク400を介して電子レシートサービスを提供する。例えば2次元コードTC1Aが表すチェックインデータは、店舗Aを運営する事業者が利用する電子レシートサービスを提供する電子レシートサーバに通信ネットワーク400を介してアクセスするためのアドレスを表す。2次元コードTC1Bが表すチェックインデータは、店舗Bを運営する事業者が利用する電子レシートサービスを提供する電子レシートサーバに通信ネットワーク400を介してアクセスするためのアドレスを表す。当該アドレスは、全ての2次元コードTC1で共通であってもよいし、複数のアドレスのいずれかが2次元コードTC1毎に表されていてもよい。
(10) 店舗システム100とのデータ授受のためにユーザ端末300が、アクセスポイント6との無線通信及び通信ネットワーク400との無線通信とのいずれを利用すべきかを示すフラグ。例えば、店舗Aにおいては、店舗システム100Aとユーザ端末300とのデータ授受にアクセスポイント6との無線通信を利用するのであれば、当該フラグは例えば“1”とされる。例えば、店舗Bにおいては、店舗システム100Bとユーザ端末300とのデータ授受に通信ネットワーク400との無線通信を利用するのであれば、当該フラグは例えば“0”とされる。
(11) アクセスポイント6を識別するためのSSID(service set identifier)。例えば2次元コードTC1Aが表すチェックインデータは、店舗システム100Aに含まれるアクセスポイント6を識別するSSIDを表す。2次元コードTC1Bが表すチェックインデータは、店舗システム100Bに含まれるアクセスポイント6のSSIDを表す。
(12) アクセスポイント6にアクセスするためのパスワード。例えば2次元コードTC1Aが表すチェックインデータは、店舗システム100Aに含まれるアクセスポイント6に設定されているパスワードを表す。2次元コードTC1Bが表すチェックインデータは、店舗システム100Bに含まれるアクセスポイント6に設定されているパスワードを表す。
(13) アクセスポイント6が利用するセキュリティ方式の識別番号。当該識別番号は例えば、WPA2-PSK方式には“1”が、WPA-PSK方式には“2”が、そしてWEP方式には“3”が割り付けられる。例えば、店舗システム100Aに含まれるアクセスポイント6がセキュリティ方式としてWPA2-PSK方式を利用するならば、2次元コードTC1Aが表すチェックインデータは当該識別番号として“1”を表す。また例えば、店舗システム100Bに含まれるアクセスポイント6がセキュリティ方式としてWPA-PSK方式を利用するならば、2次元コードTC1Bが表すチェックインデータは当該識別番号として“2”を表す。
(14) ユーザ端末300が中継サーバ200との接続に失敗したときにエラーとするか、エラーとすることなく運用を続けるかを識別するためのフラグ。例えば、店舗Aにおいては、ユーザ端末300が中継サーバ200との接続に失敗したときにエラーとする設定であるならば、2次元コードTC1Aが表すチェックインデータは当該フラグとして例えば“1”を表す。また例えば、店舗Bにおいては、ユーザ端末300が中継サーバ200との接続に失敗しても運用を続ける設定であるならば、2次元コードTC1Bが表すチェックインデータは当該フラグとして例えば“0”を表す。
(15) ユーザ端末300のステータスに関する送信モードの識別番号。当該送信モードには、例えば第1モード、第2モード及び第3モードがある。当該送信モードの識別番号は例えば、第1モードには“1”が、第2モードには“2”が、第3モードには“3”が割り付けられる。第1モードでは、ユーザ端末300のステータスを中継サーバ200に送信する。第2モードでは、ユーザ端末300のステータスを店舗システム100に送信する。第2モードでは、ユーザ端末300のステータスを送信しない。例えば、店舗Aにおいては、送信モードとして第1モードを適用するのであれば、2次元コードTC1Aが表すチェックインデータは当該識別番号として“1”を表す。また例えば、店舗Bにおいては、送信モードとして第2モードを適用するのであれば、2次元コードTC1Bが表すチェックインデータは当該識別番号として“2”を表す。
(16) ユーザ端末300のログデータを蓄積したログファイルに関する送信モードの識別番号。当該送信モードには、例えば第1モード、第2モード、第3モード及び第4モードがある。当該送信モードの識別番号は例えば、第1モードには“1”が、第2モードには“2”が、第3モードには“3”が、第4モードには“4”が割り付けられる。第1モードでは、ログファイルを中継サーバ200にのみ送信する。第2モードでは、ログファイルを店舗システム100にのみ送信する。第3モードでは、ログファイルを店舗システム100及び中継サーバ200の双方に送信する。第4モードでは、ログファイルを送信しない。例えば、店舗Aにおいては、送信モードとして第1モードを適用するのであれば、2次元コードTC1Aが表すチェックインデータは当該識別番号として“1”を表す。また例えば、店舗Bにおいては、送信モードとして第2モードを適用するのであれば、2次元コードTC1Bが表すチェックインデータは当該識別番号として“2”を表す。
(17) ログファイルを、通信ネットワーク400を介して中継サーバ200へとFTP(file transfer protocol)により送信する際に使用するホスト名又はIPアドレス。
(18) ログファイルを、通信ネットワーク400を介して中継サーバ200へとFTPにより送信する際に使用するユーザ名。
(19) ログファイルを、通信ネットワーク400を介して中継サーバ200へとFTPにより送信する際に使用するパスワード。
(20) 通信ネットワーク400を介して中継サーバ200へとFTPにより送信するログファイルのパス名。
(21) 商品コードの一種であるUPC(universal product cord)のチェックデジットを削除するか否かを識別するためのフラグ。例えば、店舗Aにおいては、当該のチェックデジットを削除しない運用であるならば、2次元コードTC1Aが表すチェックインデータは当該フラグとして例えば“1”を表す。また例えば、店舗Bにおいては、当該のチェックデジットを削除する運用であるならば、2次元コードTC1Bが表すチェックインデータは当該フラグとして例えば“0”を表す。
(22) ユーザ端末300においてカメラ画面を自動遷移させるまでの時間。2次元コードTC1Aが表すチェックインデータは当該時間として、店舗Aに関して予め設定された時間を表す。2次元コードTC1Bが表すチェックインデータは当該時間として、店舗Bに関して予め設定された時間を表す。
(23) ユーザ端末300がアクセスポイント6を介して店舗システム100と通信を行う際のタイムアウト時間。2次元コードTC1Aが表すチェックインデータは当該時間として、店舗Aに関して予め設定された時間を表す。2次元コードTC1Bが表すチェックインデータは当該時間として、店舗Bに関して予め設定された時間を表す。
(24) ユーザ端末300と店舗システム100とのアクセスポイント6を介した通信がタイムアウトした場合にリトライを許容する回数。2次元コードTC1Aが表すチェックインデータは当該回数として、店舗Aに関して予め設定された回数を表す。2次元コードTC1Bが表すチェックインデータは当該時間として、店舗Bに関して予め設定された回数を表す。
(25) ユーザ端末300が中継サーバ200を介して店舗システム100と通信を行う際のタイムアウト時間。2次元コードTC1Aが表すチェックインデータは当該時間として、店舗Aに関して予め設定された時間を表す。2次元コードTC1Bが表すチェックインデータは当該時間として、店舗Bに関して予め設定された時間を表す。
(26) ユーザ端末300と店舗システム100との中継サーバ200を介した通信がタイムアウトした場合にリトライを許容する回数。2次元コードTC1Aが表すチェックインデータは当該回数として、店舗Aに関して予め設定された回数を表す。2次元コードTC1Bが表すチェックインデータは当該時間として、店舗Bに関して予め設定された回数を表す。
(27) 店員による確認が必要な商品を対象とした取引に関する確認終了の宣言を認証するための認証処理で用いる認証データ。2次元コードTC1Aが表すチェックインデータは、店舗Aに関して予め設定された認証データを表す。2次元コードTC1Bが表すチェックインデータは、店舗Bに関して予め設定された認証データを表す。認証データは、店舗毎で異なるように定められることが好ましいが、異なる店舗で同じ認証データが設定されても構わない。
(28) 店舗システム100の動作モードを識別するためのデータ。例えば、店舗システム100Aが、取引処理システムを通常に運用する通常モードに設定されているならば、2次元コードTC1Aが表すチェックインデータは当該データとして例えば“1”を表す。また例えば、店舗システム100Bが、取引処理システムをデモ運用するデモモードに設定されているならば、2次元コードTC1Bが表すチェックインデータは当該データとして例えば“2”を表す。
(29) 会計機5へのデータ転送のモードを識別するためのデータ。例えば、店舗システム100Aが、会計機5からモバイルコントローラ3にデータ転送を要求するモードに設定されているならば、2次元コードTC1Aが表すチェックインデータは当該データとして例えば“1”を表す。また例えば、店舗システム100Bが、会計機5からの要求無しにモバイルコントローラ3から会計機5へとデータ転送するモードに設定されているならば、2次元コードTC1Bが表すチェックインデータは当該データとして例えば“2”を表す。
(30) ユーザ端末300での操作によるコード決済方式での決済を許容するか否かを表すフラグ。例えば、店舗Aでは当該のコード決済を許容されるならば、2次元コードTC1Aが表すチェックインデータは当該フラグとして例えば“1”を表す。また例えば、店舗Bでは当該のコード決済が許容されないならば、2次元コードTC1Bが表すチェックインデータは当該フラグとして例えば“0”を表す。
(31) 購入者の年齢制限が定められている商品(以下、年齢制限商品と称する)のユーザ端末300での登録を許容するか否かを識別するためのフラグ。例えば、店舗Aでは年齢制限商品のユーザ端末300での登録が許容されるならば、2次元コードTC1Aが表すチェックインデータは当該フラグとして例えば“1”を表す。また例えば、店舗Bでは当該のコード決済が許容されないならば、2次元コードTC1Bが表すチェックインデータは当該フラグとして例えば“0”を表す。
(32) ポイント会員の会員コードの入力モードを識別するためのデータ。例えば、店舗システム100Aが、会員コードを手入力するモードに設定されているならば、2次元コードTC1Aが表すチェックインデータは当該データとして例えば“1”を表す。また例えば、店舗システム100Bが、バーコードの読み取りにより会員コードを入力するモードに設定されているならば、2次元コードTC1Bが表すチェックインデータは当該データとして例えば“2”を表す。
(33) ポイント会員の会員コードを手入力するモードが設定されている場合に、会員コードの入力に際して店員の確認を必要とするか否かを識別するためのフラグ。例えば、店舗Aにて当該確認を必要とするならば、2次元コードTC1Aが表すチェックインデータは当該フラグとして例えば“1”を表す。また例えば、店舗Bにて当該確認を不要とするならば、2次元コードTC1Bが表すチェックインデータは当該フラグとして例えば“0”を表す。
(34) チェックイン時にユーザ端末300のバッテリ残量のチェックをするための閾値。当該閾値は、店舗毎又は事業者毎に設定される。例えば店舗Aを運営する事業者が当該閾値を「20%」と定めている場合は、2次元コードTC1Aが表すチェックインデータは当該閾値として例えば“20”を表す。また例えば店舗Bが当該閾値を「25%」と定めている場合は、2次元コードTC1Bが表すチェックインデータは当該閾値として例えば“25”を表す。
以上が、チェックインデータが表す情報の例である。ただし、チェックインデータは、以上に示した各種の情報のうちの一部を含まなくてもよい。またチェックインデータは、以上に示した各種の情報とは別の情報を表してもよい。
図2は店舗サーバ1の要部回路構成を示すブロック図である。
店舗サーバ1は、プロセッサ11、メインメモリ12、補助記憶ユニット13、通信インタフェース14及び伝送路15を含む。プロセッサ11、メインメモリ12、補助記憶ユニット13及び通信インタフェース14は、伝送路15を介して通信可能とされている。そして、プロセッサ11、メインメモリ12及び補助記憶ユニット13が伝送路15により接続されていることによって、店舗サーバ1を制御するためのコンピュータが構成される。
プロセッサ11は、上記コンピュータの中枢部分に相当する。プロセッサ11は、オペレーティングシステム及びアプリケーションプログラム等の情報処理プログラムに従って、店舗サーバ1としての各種の機能を実現するための情報処理を実行する。プロセッサ11は、例えばCPU(central processing unit)である。
メインメモリ12は、上記コンピュータの主記憶部分に相当する。メインメモリ12は、不揮発性のメモリ領域と揮発性のメモリ領域とを含む。メインメモリ12は、不揮発性のメモリ領域では上記の情報処理プログラムを記憶する。メインメモリ12は、プロセッサ11が情報処理を実行する上で必要なデータを不揮発性又は揮発性のメモリ領域で記憶する場合もある。メインメモリ12は、揮発性のメモリ領域を、プロセッサ11によってデータが適宜書き換えられるワークエリアとして使用する。不揮発性のメモリ領域は、例えばROM(read only memory)である。揮発性のメモリ領域は、例えばRAM(random access memory)である。
補助記憶ユニット13は、上記コンピュータの補助記憶部分に相当する。補助記憶ユニット13としては、例えばEEPROM(electric erasable programmable read-only memory)、HDD(hard disc drive)、あるいはSSD(solid state drive)等の周知の記憶デバイスを用いた記憶ユニットを利用できる。補助記憶ユニット13は、プロセッサ11が各種の処理を行う上で使用するデータ、あるいはプロセッサ11での処理によって作成されたデータ等を保存する。補助記憶ユニット13は、上記の情報処理プログラムを記憶する場合もある。
通信インタフェース14は、店内通信ネットワーク7に接続された各部との間で所定の通信プロトコルに従いデータ通信を行う。通信インタフェース14としては、例えばLAN用の周知の通信デバイスを適用できる。
伝送路15は、アドレスバス、データバス及び制御信号線等を含み、接続された各部の間で授受されるデータ及び制御信号を伝送する。
補助記憶ユニット13は、情報処理プログラムの1つである店舗管理アプリAP11を記憶する。店舗管理アプリAP11は、アプリケーションプログラムであり、店舗サーバ1としての機能を実現するための情報処理について記述されている。店舗管理アプリAP11は、店舗毎、あるいは店舗を運営する事業者毎の店舗運営方針に適応して作成された別々のものであってよい。例えば、店舗Aと店舗Bとで売上データの管理方法が異なるならば、店舗システム100Aで用いられる店舗管理アプリAP11は、店舗Aでの売上データの管理方法に適応した売上データの管理のための情報処理について記述され、店舗システム100Bで用いられる店舗管理アプリAP11は、店舗Bでの売上データの管理方法に適応した売上データの管理のための情報処理について記述される。
補助記憶ユニット13の記憶領域の一部は、データベース群DB11として使用される。データベース群DB11は、各種の情報管理のための複数のデータベースを含む。データベース群DB11に含まれるデータベースの1つは、店舗で販売する商品を管理するための商品データベースである。商品データベースは、管理の対象となる商品に関連付けられたデータレコードの集合である。商品データベースのデータレコードには、商品コード、価格及び商品名等の、関連付けられた商品に関するデータが含まれる。商品コードは、商品をSKU(stock keeping unit)毎に識別するために定められた識別コードであり、例えばJAN(Japanese article number)コードが用いられる。商品名は、商品を人間が区別し易いように定められた名称である。価格は、商品の販売の対価となる金額である。
データベース群DB11に含まれるデータベースの1つは、店舗の利用者を管理するための利用者データベースである。利用者データベースは、利用者として登録された客に関連付けられたデータレコードの集合である。利用者データベースのデータレコードには、利用者コード及び利用者を特定するための属性情報等の、関連付けられた客に関するデータが含まれる。利用者コードは、利用者を個々に識別するために客毎に定められた一意の識別コードである。属性情報は、氏名、性別、年齢、住所、電話番号などを含み得る。また利用者データベースのデータレコードには、利用者が申告した決済情報を含む場合もある。決済情報は、クレジット番号又はコード決済ID(identifier)などである。また複数の決済方法を選択可能とする場合には、決済情報に決済方法を識別するための決済方法コードを含む場合もある。また、ポイントサービスを提供する店舗の場合には、ポイントサービスのID及び保有ポイント数などを決済情報に含む場合もある。
この他、データベース群DB11には、既存のPOSシステムにおけるPOSサーバで管理されるような様々なデータベースが含まれ得る。なお、データベース群DB11がどのようなデータベースと含むか、あるいはそれらデータベースがどのようなデータをどのような構造で含んでいるかは、店舗毎に定められてよい。
図3は仮想POSサーバ2の要部回路構成を示すブロック図である。
仮想POSサーバ2は、プロセッサ21、メインメモリ22、補助記憶ユニット23、通信インタフェース24及び伝送路25を含む。プロセッサ21、メインメモリ22、補助記憶ユニット23及び通信インタフェース24は、伝送路25を介して通信可能とされている。そして、プロセッサ21、メインメモリ22及び補助記憶ユニット23が伝送路25により接続されていることによって、仮想POSサーバ2を制御するためのコンピュータが構成される。なお、プロセッサ21、メインメモリ22、補助記憶ユニット23、通信インタフェース24及び伝送路25の機能の概略は、プロセッサ11、メインメモリ12、補助記憶ユニット13、通信インタフェース14及び伝送路15と同等であるので、その説明は省略する。
ただし補助記憶ユニット23は、店舗管理アプリAP11に代えて仮想POSアプリAP21を記憶する。仮想POSアプリAP21は、アプリケーションプログラムであり、仮想POSサーバ2としての機能を実現するための情報処理について記述されている。仮想POSアプリAP21は、店舗毎、あるいは店舗を運営する事業者毎の店舗運営方針に適応して作成された別々のものであってよい。例えば、店舗Aでは、店舗Bでは行われない割引サービスを行うのであるならば、店舗システム100Aで用いられる仮想POSアプリAP21は、当該割引サービスを実現するための情報処理について記述され、店舗システム100Bで用いられる仮想POSアプリAP21は、当該割引サービスを実現するための情報処理について記述されない。
また補助記憶ユニット23の記憶領域の一部は、データベース群DB11に代えて取引データベースDB21として使用される。取引データベースDB21は、店内で買い回り中である客との取引に関連付けられたデータレコードの集合である。取引データベースDB21のデータレコードには、取引コードと、購入商品として登録済みの商品に関する商品データとを含む。取引コードは、取引の個々を識別するために取引毎に設定された一意の識別コードである。商品データは、商品コード、商品名、価格及び個数などを表す。取引データベースDB21の構造は、店舗毎、あるいは店舗を運営する事業者毎の店舗運営方針に適応して個別に定められてよい。
図4はモバイルコントローラ3の要部回路構成を示すブロック図である。
モバイルコントローラ3は、プロセッサ31、メインメモリ32、補助記憶ユニット33、通信インタフェース34及び伝送路35を含む。プロセッサ31、メインメモリ32、補助記憶ユニット33及び通信インタフェース34は、伝送路35を介して通信可能とされている。そして、プロセッサ31、メインメモリ32及び補助記憶ユニット33が伝送路35により接続されていることによって、モバイルコントローラ3を制御するためのコンピュータが構成される。なお、プロセッサ31、メインメモリ32、補助記憶ユニット33、通信インタフェース34及び伝送路35の機能の概略は、プロセッサ11、メインメモリ12、補助記憶ユニット13、通信インタフェース14及び伝送路15と同等であるので、その説明は省略する。
ただし補助記憶ユニット33は、店舗管理アプリAP11に代えて登録支援アプリAP31を記憶する。登録支援アプリAP31は、アプリケーションプログラムであり、購入商品の登録を支援するための後述する情報処理について記述されている。登録支援アプリAP31は、各店舗システム100で共通である。ただし、登録支援アプリAP31に基づく情報処理のための各種の設定は、店舗システム100毎にカスタマイズされてもよい。
また補助記憶ユニット23の記憶領域の一部は、データベース群DB11に代えて取引管理データベースDB31及び登録データベースDB32として使用される。これら取引管理データベースDB31及び登録データベースDB32の構造は、各店舗システム100で共通である。
図5は取引管理データベースDB31に含まれるデータレコードDR1の主要なデータ構造を示す模式図である。
取引管理データベースDB31は、店内で客が利用するユーザ端末300に関連付けられたデータレコードDR1の集合である。このため、店内に存在する客が1人であるときには、取引管理データベースDB31はデータレコードDR1を1つ含む。また店内に存在する客が1人も居ないときには、取引管理データベースDB31はデータレコードDR1を含まない。そしてデータレコードDR1は、フィールドF11,F12,F13,F14を含む。
フィールドF11には、関連付けられたユーザ端末300を他のユーザ端末300と識別するための端末コードがセットされる。端末コードとしては例えば、ユーザ端末300として利用される通信端末の個々を識別するために通信端末毎に設定された一意の識別コードを用いることができる。あるいは端末コードとしては例えば、後述するスマホPOSアプリをユーザ端末300にインストールする際に当該スマホPOSアプリに対して設定される識別コードを用いることができる。フィールドF12には、関連付けられたユーザ端末300を使用している客を他の客と識別するための会員コードがセットされる。フィールドF13には、関連付けられたユーザ端末300を用いて行われる取引の取引コードがセットされる。フィールドF14には、関連付けられたユーザ端末300を利用して購入商品として登録済みの商品に、要確認商品が含まれるか否かを識別するための要確認フラグがセットされる。本実施形態では、要確認フラグは、“1”であるときに要確認商品が含まれることを表すこととする。なお、データレコードDR1には、フィールドF11~F15とは別のデータがセットされる別のフィールドが含まれてもよい。言い換えれば、要確認フラグは、店員による確認が必要であるか否かを表している。
図6は登録データベースDB32に含まれるデータレコードDR2の主要なデータ構造を示す模式図である。
登録データベースDB32は、店内で買い回り中である客との取引に関連付けられたデータレコードDR2の集合である。そしてデータレコードDR2は、フィールドF21,F22を含む。データレコードDR1はまた、フィールドF23,F24,…を含み得る。
フィールドF21には、関連付けられた取引の取引コードがセットされる。この取引コードは、関連付けられた取引で使用されているユーザ端末300に関連付けられたデータレコードDR1のフィールドF12にセットされた取引コードと同一である。フィールドF22には、関連付けられた取引に関して試みられた商品登録に関する登録データがセットされる。登録データについては、後述する。
データレコードDR2には、関連付けられた取引に関して2つ以上の購入商品の登録が試みられている場合に、フィールドF23以降のフィールドが含まれる。そしてフィールドF23以降のフィールドにも、フィールドF12と同様な登録データがセットされる。
図7は通信サーバ4の要部回路構成を示すブロック図である。
通信サーバ4は、プロセッサ41、メインメモリ42、補助記憶ユニット43、通信インタフェース44、通信ユニット45及び伝送路46を含む。プロセッサ41、メインメモリ42、補助記憶ユニット43、通信インタフェース44及び通信ユニット45は、伝送路46を介して通信可能とされている。そして、プロセッサ41、メインメモリ42及び補助記憶ユニット43が伝送路46により接続されていることによって、通信サーバ4を制御するためのコンピュータが構成される。なお、プロセッサ41、メインメモリ42、補助記憶ユニット43、通信インタフェース44及び伝送路46の機能の概略は、プロセッサ11、メインメモリ12、補助記憶ユニット13、通信インタフェース14及び伝送路15と同等であるので、その説明は省略する。
通信ユニット45は通信ネットワーク400を介したデータ通信のための通信処理を行う。通信ユニット45としては、例えば周知のインターネット接続デバイスを適用できる。
補助記憶ユニット43は、店舗管理アプリAP11に代えて通信処理アプリAP41を記憶する。通信処理アプリAP41は、アプリケーションプログラムであり、モバイルコントローラ3とユーザ端末300との間でのデータ授受を可能とするべく、通信ネットワーク400を介して中継サーバ200と通信するための情報処理について記述されている。通信処理アプリAP41は、各店舗システム100で共通である。ただし、通信処理アプリAP41に基づく情報処理のための各種の設定は、店舗システム100毎にカスタマイズされてもよい。
図8はユーザ端末300の要部回路構成を示すブロック図である。
ユーザ端末300は、プロセッサ301、メインメモリ302、補助記憶ユニット303、タッチパネル304、カメラ305、無線通信ユニット306、モバイル通信ユニット307及び伝送路308等を備える。プロセッサ301と、メインメモリ302、補助記憶ユニット303、タッチパネル304、カメラ305及びモバイル通信ユニット307とは、伝送路308を介して通信可能とされている。そして、プロセッサ301、メインメモリ302及び補助記憶ユニット303が伝送路308により接続されていることによって、ユーザ端末300を制御するためのコンピュータが構成される。なお、プロセッサ301、メインメモリ302、補助記憶ユニット303及び伝送路308の機能の概略は、プロセッサ11、メインメモリ12、補助記憶ユニット13及び伝送路15と同等であるので、その説明は省略する。
タッチパネル304は、ユーザ端末300の入力デバイス及び表示デバイスとして機能する。
カメラ305は、光学系及びイメージセンサを含み、光学系により形成される視野内の像を表した画像データをイメージセンサにより生成する。
無線通信ユニット306は、アクセスポイント6との間で無線通信プロトコルに従った無線通信によりデータを授受する。無線通信ユニット306としては、例えばIEEE802.11規格に準拠した周知の通信デバイスを利用できる。
モバイル通信ユニット307は、通信ネットワーク400を介したデータ通信のインタフェースである。モバイル通信ユニット307としては、例えば移動通信網を介したデータ通信を行うための周知の通信デバイスを利用できる。
なお補助記憶ユニット303は、情報処理プログラムの1つであるスマホPOSアプリAP301を記憶する。スマホPOSアプリAP301は、アプリケーションプログラムであり、ユーザ端末300を店舗システム100のユーザインタフェースとして機能させるための後述する情報処理について記述されている。スマホPOSアプリAP301は、複数のユーザ端末300で共通に利用される。
さて、店舗サーバ1、仮想POSサーバ2又はモバイルコントローラ3のハードウェアとしては、例えば汎用のサーバ装置を用いることができる。そして店舗サーバ1、仮想POSサーバ2又はモバイルコントローラ3の譲渡は一般に、補助記憶ユニット13,23又は33に店舗管理アプリAP11、仮想POSアプリAP21又は登録支援アプリAP31がそれぞれ記憶され、データベース群DB11、取引データベースDB21、又は取引管理データベースDB31及び登録データベースDB32が記憶されない状態にて行われる。しかし、店舗管理アプリAP11、仮想POSアプリAP21又は登録支援アプリAP31が補助記憶ユニット13,23又は33に記憶されない状態、あるいは同種の別バージョンのアプリケーションプログラムが補助記憶ユニット13,23又は33に記憶された状態のハードウェアと、店舗管理アプリAP11、仮想POSアプリAP21又は登録支援アプリAP31とが個別に譲渡されてもよい。そして、任意の作業者の操作に応じて、補助記憶ユニット13,23又は33に店舗管理アプリAP11、仮想POSアプリAP21又は登録支援アプリAP31が書き込まれることによって、店舗サーバ1、仮想POSサーバ2又はモバイルコントローラ3が構成されてもよい。店舗管理アプリAP11、仮想POSアプリAP21又は登録支援アプリAP31の譲渡は、磁気ディスク、光磁気ディスク、光ディスク、半導体メモリなどのようなリムーバブルな記録媒体に記録して、あるいはネットワークを介した通信により行うことができる。取引データベースDB21、又は取引管理データベースDB31及び登録データベースDB32は、プロセッサ11,21又は31が店舗管理アプリAP11、仮想POSアプリAP21又は登録支援アプリAP31に基づく情報処理を実行することで、補助記憶ユニット13,23又は33内に構成される。なお、店舗管理アプリAP11及びデータベース群DB11に含まれるデータベースの少なくとも一部が、メインメモリ12に記憶されてもよい。仮想POSアプリAP21及び取引データベースDB21の少なくとも一部が、メインメモリ22に記憶されてもよい。登録支援アプリAP31、取引管理データベースDB31及び登録データベースDB32の少なくとも一部が、メインメモリ32に記憶されてもよい。
次に以上のように構成された取引処理システムの動作について説明する。なお、以下に説明する各種の処理の内容は一例であって、一部の処理の順序の変更、一部の処理の省略、あるいは別の処理の追加などは適宜に可能である。例えば、以下の説明では、本実施形態の特徴的な動作を分かり易く説明するために、一部の処理についての説明を省略している。例えば、何らかのエラーが発生した場合に、そのエラーに対処するための処理が行われる場合があるが、そのような処理の一部については記載を省略している。
なお、以下に説明する取引処理システムの動作により客に提供されるサービスをスマホPOSサービスと称する。
スマホPOSサービスを利用するためにユーザ端末300が店舗システム100とデータを授受するが、そのための通信にアクセスポイント6との無線通信及び通信ネットワーク400との無線通信とのいずれを利用するかは、チェックインデータに含まれるフラグの状態により決まる。しかしながら以下においては説明の簡略化のために、アクセスポイント6との無線通信のみを用いる場合について説明する。また、会計機5で会計を行わせるために仮想POSサーバ2から会計機5へのデータ転送を、会計機5からモバイルコントローラ3にデータ転送を要求するモードと、会計機5からの要求無しにモバイルコントローラ3から会計機5へとデータ転送するモードとのいずれを利用するかは、チェックインデータに含まれるフラグの状態により決まる。しかしながら以下においては説明の簡略化のために、会計機5からモバイルコントローラ3にデータ転送を要求するモードが固定的に用いられることとして説明する。
客は、スマホPOSサービスを利用するためには、自らが所有するスマートフォン等にスマホPOSアプリAP301をインストールして、ユーザ端末300として利用可能としておく。あるいは、客は、タブレット端末などにスマホPOSアプリAP301をインストールして構成されたユーザ端末300を店舗にて借りる。そして客は、スマホPOSアプリAP301に基づく情報処理を起動した状態のユーザ端末300を持って、店舗システム100が設けられたいずれかの店舗へと入る。
さてユーザ端末300においてプロセッサ301は、スマホPOSアプリAP301に基づいて図9、図10、図11、図12及び図13に示すような情報処理を実行する。
まず図9に示すACT101としてプロセッサ301は、メインメニュー画面をタッチパネル304に表示させる。メインメニュー画面は、スマホPOSアプリAP301に基づいて行うべきいくつかの処理のいずれかの指定を受けるための画面である。メインメニュー画面には、買い物の開始を指定するためのGUI(graphical user interface)要素を含む、複数のGUI要素が配置されている。なおGUI要素は、例えばソフトキーである。
ACT102としてプロセッサ301は、買い物の開始が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できないならばNOと判定し、ACT103へと進む。
ACT103としてプロセッサ301は、買い物の開始以外の指定がなされたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できないならばNOと判定し、ACT102へと戻る。
かくしてプロセッサ301はACT102及びACT103としては、メインメニュー画面での何らかの指定がなされるのを待ち受ける。そしてプロセッサ301は、買い物の開始以外の指定がなされたならば、ACT103にてYESと判定し、指定された処理へと進む。なおこの場合のプロセッサ301の処理についての説明は省略する。
客は、店舗に入って買い物を開始する場合には、メインメニュー画面にて買い物の開始を指定するための予め定められた操作を行う。
プロセッサ301は、買い物の開始を指定するための操作が例えばタッチパネル304にて検出されると、ACT102にてYESと判定し、ACT104へと進む。
ACT104としてプロセッサ301は、チェックイン用のスキャン画面をタッチパネル304に表示させる。チェックイン用のスキャン画面は、チェックイン用の2次元コードTC1を読み取るように客に促す画面である。プロセッサ301は例えば、カメラ305を起動し、これによりカメラ305で得られた画像に、2次元コードTC1を読み取るように客に促す文字メッセージと、2次元コードTCを翳すべき位置の目安を示すラインとを重ねてスキャン画面を生成する。
客は、スキャン画面がタッチパネル304に表示されたならば、店舗の入口付近に掲示されている2次元コードTC1がスキャン画面に映り込むようにカメラ305を2次元コードTC1に向ける。
ACT105としてプロセッサ301は、2次元コードが読み取れるのを待ち受ける。このときにプロセッサ301は、カメラ305で得られる画像を繰り返し解析し、2次元コードの読み取りを試みる。この2次元コードの読み取りは、スマホPOSアプリAP301に基づく処理として行われてもよいし、2次元コードの読み取り用の別のアプリケーションプログラムに基づく処理として行われてもよい。そしてプロセッサ301は、2次元コードが読み取れたならばYESと判定し、ACT106へと進む。
ACT106としてプロセッサ301は、読み取った2次元コードが表すデータがチェックインデータであるか否かを確認する。そしてプロセッサ301は、チェックインデータでなければNOと判定し、ACT105へと戻る。このときにプロセッサ301は、誤った2次元コードが読み取られたことを客に通知する画面をタッチパネル304に表示させてもよい。
プロセッサ301は、読み取った2次元コードが表すデータがチェックインデータであることが確認できたならば、ACT106にてYESと判定し、ACT107へと進む。
ACT107としてプロセッサ301は、読み取ったチェックインデータを、メインメモリ302又は補助記憶ユニット303に保存する。
ACT108としてプロセッサ301は、モバイルコントローラ3に対して、チェックインを要求する。具体的にはプロセッサ301は、チェックインデータに表されたデータに基づいて、無線通信ユニット306とアクセスポイント6との無線通信を確立する。例えば店舗Aにて2次元コードTC1Aに客によってカメラ305が向けられたならば、2次元コードTC1Aが表すチェックインデータに基づいてプロセッサ301は、店舗システム100Aに設けられたアクセスポイント6との無線通信を確立する。そしてプロセッサ301は、アクセスポイント6との無線通信を介して、チェックインを要求するための要求データをモバイルコントローラ3に宛てて送信する。上述のように店舗システム100Aに設けられたアクセスポイント6との無線通信が確立している場合には、当該の要求データは、店舗システム100Aに設けられたアクセスポイント6及び店内通信ネットワーク7を介して、店舗システム100Aに設けられたモバイルコントローラ3へと伝送される。なおプロセッサ301は、チェックインを要求するための要求データには、チェックインの要求であることを識別するための識別データと、端末コードとを含める。プロセッサ301は、客がスマホPOSサービスの利用登録者であり、会員コードを有している場合には、その会員コードも要求データに含める。会員コードは例えば、ユーザ端末300の補助記憶ユニット303で記憶される。プロセッサ301は、例えば客を認証するためのデータなどのその他のデータを要求データに含めてもよい。
なお、以降において説明するユーザ端末300からモバイルコントローラ3への各種の要求は、上記と同様に、要求の理由を識別するための識別データを含んだ要求データをアクセスポイント6及び店内通信ネットワーク7を介してユーザ端末300からモバイルコントローラ3へと送ることにより実現される。
モバイルコントローラ3においてプロセッサ31は、チェックインを要求するための要求データが通信インタフェース34によって受信されると、チェックインしようとしている客との取引に関する情報処理を開始する。
図14、図15、図16及び図17はプロセッサ31による情報処理のフローチャートである。
プロセッサ31は、チェックインを要求するための要求データが通信インタフェース34によって受信される毎に、当該情報処理を開始する。別の要求に基づいて開始した情報処理を既に実行している場合には、それに並行して新たな情報処理を開始する。つまりプロセッサ31は、複数のユーザ端末300をそれぞれ対象として情報処理を複数並行して実行する場合がある。以下においては、単に「ユーザ端末300」と表す場合には、プロセッサ31の情報処理の対象となっているユーザ端末300を指すこととする。
図14のACT201としてプロセッサ31は、チェックイン処理を行う。プロセッサ31は例えば、仮想POSサーバ2に取引の開始を要求し、取引コードの通知を受ける。そしてプロセッサ31は、要求データに含まれた端末コードをフィールドF11にセットした新たなデータレコードDR1を取引管理データベースDB31に追加する。プロセッサ31は、要求データに会員コードが含まれるならば、当該会員コードを、新たなデータレコードDR1のフィールドF12にセットする。プロセッサ31は、上記の通知された取引コードを、新たなデータレコードDR1のフィールドF13にセットする。またプロセッサ31は、“0”を要確認フラグとして新たなデータレコードDR1のフィールドF14にセットする。これにより、チェックインを要求したユーザ端末300を用いて行われる取引の管理が開始される。
なお仮想POSサーバ2においてプロセッサ21は、取引の開始がモバイルコントローラ3から要求されたならば、予め定められたルールに従って取引コードを決定し、その取引コードに関連付けての購入商品の登録処理を開始する。またプロセッサ21は、決定した取引コードをモバイルコントローラ3に通知する。
ACT202としてプロセッサ31は、チェックイン処理を正常に完了したか否かを確認する。そしてプロセッサ31は、何らかの異常によりチェックイン処理を正常に完了することができなかったならばNOと判定し、ACT203へと進む。
ACT203としてプロセッサ31は、ユーザ端末300に対してエラーを通知する。プロセッサ31は例えば、エラー通知のための通知データを、店内通信ネットワーク7及びアクセスポイント6を介してユーザ端末300へと送信する。プロセッサ31は、エラーの通知であることを識別するための識別データを通知データに含める。プロセッサ31は、エラーの原因を表すエラーコードを通知データに含めてもよい。
なお、以降において説明するモバイルコントローラ3からユーザ端末300への各種の通知は、上記と同様に、通知の理由を識別するための識別データを含んだ通知データを店内通信ネットワーク7及びアクセスポイント6を介してモバイルコントローラ3からユーザ端末300へと送ることにより実現される。
プロセッサ31は一方、チェックイン処理を正常に完了することができたならばACT202にてYESと判定し、ACT204へと進む。
ACT204としてプロセッサ31は、ユーザ端末300に対してチェックイン完了を通知する。プロセッサ31は例えば、チェックイン完了の通知のための通知データを、店内通信ネットワーク7及びアクセスポイント6を介してユーザ端末300へと送信する。プロセッサ31は、チェックイン完了の通知であることを識別するための識別データを通知データに含める。
ユーザ端末300においてプロセッサ301は、図9中のACT108にてチェックインを要求した後には、ACT109へと進む。
ACT109としてプロセッサ301は、チェックイン完了が通知されたか否かを確認する。そしてプロセッサ301は、当該の通知を確認できないならばNOと判定し、ACT110へと進む。
ACT110としてプロセッサ301は、チェックインのエラーが通知されたか否かを確認する。そしてプロセッサ301は、当該の通知を確認できないならばNOと判定し、ACT109へと戻る。
かくしてプロセッサ301はACT109及びACT110としては、チェックインの完了又はエラーが通知されるのを待ち受ける。そしてプロセッサ301は、前述のエラー通知のための通知データが無線通信ユニット306により受信されたならばACT110にてYESと判定し、ACT111へと進む。
ACT111としてプロセッサ301は、エラー画面をタッチパネル304に表示させる。エラー画面は、チェックインできないことを客に報知するものとして定められた画面である。プロセッサ301は、例えばエラー画面中に表したGUI要素の操作などによりエラー画面の表示解消が指示されたならば、ACT101に戻る。
プロセッサ301は一方、前述のチェックイン完了の通知のための通知データが無線通信ユニット306により受信されたならばACT109にてYESと判定し、図10中のACT112へと進む。
ACT112としてプロセッサ301は、一覧画面をタッチパネル304に表示させる。一覧画面は、登録済みの購入商品の一覧を表した画面である。
図18は一覧画面SC1の一例を示す図である。
一覧画面SC1は、表示エリアAR11,AR12及びボタンBU11,BU12,BU13を含む。表示エリアAR11は、購入商品の総数と、購入商品の代金の総額とを表す。表示エリアAR12は、購入商品の一覧を表す。ボタンBU11は、購入商品の全てを取り消して買い物を中止することを客が宣言するためのソフトキーである。ボタンBU12は、購入商品として登録する商品のスキャンを開始することを客が宣言するためのソフトキーである。ボタンBU13は、会計を開始することを客が宣言するためのソフトキーである。
なお、図18は、まだ購入商品の登録が行われていない状態の一覧画面SC1を示している。このため、表示エリアAR11には総数及び総額としていずれも“0”を表し、表示エリアAR12には何も表さない。
図10中のACT113としてプロセッサ301は、商品のスキャン開始が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できなければNOと判定し、ACT114へと進む。
ACT114としてプロセッサ301は、数量の変更が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できなければNOと判定し、ACT115へと進む。
ACT115としてプロセッサ301は、買い物の中止が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できなければNOと判定し、ACT116へと進む。
ACT116としてプロセッサ301は、会計の開始が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できなければNOと判定し、ACT113へと戻る。
かくしてプロセッサ301はACT113~ACT116としては、スキャン開始、数量、中止、会計開始のいずれかが指定されるのを待ち受ける。
客は、商品を購入商品として登録するならば、一覧画面SC1におけるボタンBU12にタッチするなどの予め定められた操作によってスキャン開始を指定する。これに応じてプロセッサ301は、ACT113にてYESと判定し、ACT117へと進む。
ACT117としてプロセッサ301は、登録画面をタッチパネル304に表示させる。登録画面は、購入商品として登録する商品の商品コードを表したバーコードを読み取るように客に促す画面である。
図19は登録画面SC2の一例を示す図である。
登録画面SC2は、表示エリアAR21、メッセージME21及びボタンBU21を含む。表示エリアAR21は、カメラ305で得られた画像を表示する。メッセージME21は、商品のバーコードを読み取るように客に促す文字メッセージである。ボタンBU21は、商品コードのスキャンを中止することを客が宣言するためのソフトキーである。
プロセッサ301は例えば、カメラ305を起動し、これによりカメラ305で得られた画像に、表示エリアAR21の範囲を表すラインと、メッセージME21及びボタンBU21とを表した画像を重ねて登録画面SC2を生成する。
図10中のACT118としてプロセッサ301は、バーコードが読み取れたか否かを確認する。このときにプロセッサ301は、カメラ305で得られる画像を解析し、バーコードの読み取りを試みる。このバーコードの読み取りは、スマホPOSアプリAP301に基づく処理として行われてもよいし、バーコードの読み取り用の別のアプリケーションプログラムに基づく処理として行われてもよい。そしてプロセッサ301は、バーコードが読み取れないならばNOと判定し、ACT119へと進む。
ACT119としてプロセッサ301は、スキャンの中止が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できないならばNOと判定し、ACT118に戻る。
かくしてプロセッサ301はACT118及びACT119としては、バーコードが読み取れるか、スキャン中止が指定されるのを待ち受ける。
客は、今回のスキャンは行わずに一覧画面に戻ることを希望する場合には、ボタンBU21にタッチするなどの予め定められた操作によってスキャン中止を指定する。これに応じてプロセッサ301は、ACT119にてYESと判定し、ACT112へと戻る。
客は、登録画面がタッチパネル304に表示されたならば、購入商品として登録しようとする商品に表示されたバーコードが表示エリアAR21に映り込むようにカメラ305を商品に向ける。これに応じてプロセッサ301は、ACT118にてYESと判定し、ACT120へと進む。
ACT120としてプロセッサ301は、モバイルコントローラ3に対して登録を要求する。プロセッサ301はここで送信する要求データには、読み取ったバーコードが表すデータ(以下、バーコードデータと称する)を含める。
さて、モバイルコントローラ3においてプロセッサ31は、図14中のACT204にてチェックイン完了の通知を行った後には、ACT205へと進む。
ACT205としてプロセッサ31は、登録が要求されたか否かを確認する。そしてプロセッサ31は、該当の要求が確認できなければNOと判定し、ACT206へと進む。
ACT206としてプロセッサ301は、数量変更が要求されたか否かを確認する。そしてプロセッサ31は、該当の要求が確認できなければNOと判定し、ACT207へと進む。
ACT207としてプロセッサ31は、購入商品の削除が要求されたか否かを確認する。そしてプロセッサ31は、該当の要求が確認できなければNOと判定し、ACT208へと進む。
ACT208としてプロセッサ31は、購入商品の取消が要求されたか否かを確認する。そしてプロセッサ31は、該当の要求が確認できなければNOと判定し、ACT209へと進む。
ACT209としてプロセッサ31は、会計が要求されたか否かを確認する。そしてプロセッサ31は、該当の要求が確認できなければNOと判定し、ACT205へと戻る。
かくしてプロセッサ31はACT205~ACT209としては、登録、数量変更、削除、取消及び会計のいずれかが要求されるのを待ち受ける。そしてプロセッサ31は、前述のようにユーザ端末300から登録が要求されたならばACT205にてYESと判定し、図15中のACT210へと進む。
ACT210としてプロセッサ31は、処理対象となっている取引の取引コードの通知を伴って、登録の要求を仮想POSサーバ2に転送する。プロセッサ31はこのとき、ユーザ端末300から送られてきた要求データをそのまま仮想POSサーバ2に転送してもよいし、何らかの処理による変換後の要求データを仮想POSサーバ2に送信してもよい。ただしプロセッサ31は、ユーザ端末300から送られてきた要求データに含まれたバーコードデータは、仮想POSサーバ2へと通知する。
仮想POSサーバ2においてプロセッサ21は、モバイルコントローラ3から送られた要求データに含まれたバーコードデータが、既存のPOS端末に備えられたバーコードスキャナにより読み取られたものであると見做して、既存のPOS端末と同様な処理によって購入商品の登録を試みる。ただし、何らかの事情により、バーコードデータが表す商品コードが商品データベースに登録されていない場合がある。また、商品には、商品コードを表すのとは別のバーコードが表示されている場合もある。そして、これらの場合にプロセッサ21は、購入商品の登録を行えず、エラーとする。このようにプロセッサ21は、商品データベースに登録された商品コードを表すバーコードの読み取りに基づく購入商品の登録を行う。かくして仮想POSアプリAP21に基づく情報処理をプロセッサ21が実行することによって、プロセッサ21を中枢部分とするコンピュータは登録手段として機能する。なおプロセッサ21は、取引データベースDB21を用いて購入商品を管理する。
プロセッサ21は、このような処理の結果を表した結果データを、モバイルコントローラ3に送信する。プロセッサ21は、購入商品の登録が正しく行えた場合には、正規登録の通知であることを識別するための識別データと、登録した商品の商品コード、商品名及び価格を結果データに含める。またプロセッサ21は、エラーとした場合には、エラーの通知であることを識別するための識別データと、登録要求で送られてきたバーコードデータとを結果データに含める。
モバイルコントローラ3にてプロセッサ31は、ACT210にて登録要求を転送したのちには、ACT211へと進む。
ACT211としてプロセッサ31は、上記のようにして仮想POSサーバから送信される結果データを取得する。プロセッサ31は、取得した結果データをメインメモリ32又は補助記憶ユニット33に保存する。
ACT212としてプロセッサ31は、上記の結果データに基づいて登録データベースDB32を更新する。この登録データベースDB32の更新は、例えば以下のように行われる。
第1のケース:正規登録の通知であり、処理対象となっている取引が関連付けられたデータレコードDR2に、通知された商品コードを含んだ登録データが含まれていない場合。
このケースにてプロセッサ31は、処理対象となっている取引が関連付けられたデータレコードDR2に既に存在する最後のフィールドの次に新たなフィールドを追加し、当該フィールドに新たな登録データを追加する。プロセッサ31は、新たな登録データには、通知された商品コードと、エラーではないことを表す“0”としたエラーフラグと、通知された商品名及び価格と、“1”とした個数と、取り消されていないことを表す“0”とした取消フラグとを含める。かくしてこのケースで追加される登録データは、図6の右上側に示されるような構造となる。
第2のケース:正規登録の通知であり、処理対象となっている取引が関連付けられたデータレコードDR2に、通知された商品コードを含んだ登録データが含まれているものの、当該登録データの取消フラグが取り消されていることを表す“1”となっている場合。
このケースにおいてプロセッサ31は、上記の第1のケースの場合と同様に処理する。
第3のケース:正規登録の通知であり、処理対象となっている取引が関連付けられたデータレコードDR2に、通知された商品コードを含んだ登録データが含まれており、当該登録データの取消フラグが“0”となっている場合。
このケースにおいてプロセッサ31は、通知された商品コードを含み、取消フラグが“0”となっている登録データに含まれる個数の値を、1つ大きな値に書き替える。
第4のケース:エラーの通知である場合。
このケースにおいてプロセッサ31は、処理対象となっている取引が関連付けられたデータレコードDR2に既に存在する最後のフィールドの次に新たなフィールドを追加し、当該フィールドに新たな登録データを追加する。プロセッサ31は、新たな登録データには、通知されたバーコードデータと、エラーを表す“1”としたエラーフラグとを含める。かくしてこのケースで追加される登録データは、図6の右下側に示されるような構造となる。
このようにプロセッサ31により更新されることにより登録データベースDB32は、仮想POSサーバ2で登録済みの購入商品のリストを表すとともに、これに加えてエラーとなったバーコード読み取りを記録したものとなる。
なおプロセッサ31は、登録要求で送られてきたバーコードデータをメインメモリ32又は補助記憶ユニット33に保存しておき、上記のケース4においては、この保存してあるバーコードデータを登録データに含めてもよい。そしてこの場合には、仮想POSサーバ2においてプロセッサ21は、結果データにバーコードデータを含めなくてもよい。またプロセッサ31は、保存してあるバーコードデータから商品コードを取り出し、この商品コードに基づいて第1~第3のケースの処理を行ってもよい。また商品名及び価格は、プロセッサ31が商品コードに基づいて店舗サーバ1などから取得してもよい。
ACT213としてプロセッサ31は、今回の登録が正規に行われたか否かを確認する。そしてプロセッサ31は、例えば結果データがエラーを表していたならばNOと判定し、ACT214へと進む。
ACT214としてプロセッサ31は、処理対象となっている取引が取引管理データベースDB31にて関連付けられたデータレコードDR1に関して、そのフィールドF14にセットされている要確認フラグを“1”に書き替える。なおプロセッサ31は、書き替え前の状態に拘わらずに“1”を書き込むのでもよいし、書き替え前の状態が“1”であるならばそのままとするのでもよい。
プロセッサ31は、例えば結果データが正規登録を表していたならばACT213にてYESと判定し、ACT215へと進む。
ACT215としてプロセッサ31は、処理対象となっている取引が取引管理データベースDB31にて関連付けられたデータレコードDR1に関して、そのフィールドF14にセットされている要確認フラグが“1”となっているか否かを確認する。そしてプロセッサ31は、要確認フラグが“1”となっていないならばNOと判定し、ACT216へと進む。
ACT216としてプロセッサ31は、今回登録された購入商品が要確認商品であるか否かを確認する。そしてプロセッサ31は、要確認商品ではないならばNOと判定し、ACT217へと進む。なおプロセッサ31は、ACT214にて要確認フラグを“1”に書き替えた場合と、要確認フラグが“1”となっているためにACT215にてYESと判定した場合にも、ACT217へと進む。
ACT217としてプロセッサ31は、一覧画面の表示をユーザ端末300に対して指示する。プロセッサ31は例えば、一覧画面の表示指示であることを識別するための識別データを含んだ指示データを、店内通信ネットワーク7及びアクセスポイント6を介してユーザ端末300へと送信する。プロセッサ31は、処理対象となっている取引が登録データベースDB32にて関連付けられたデータレコードDR2に含まれている商品コード、商品名、価格及び個数を指示データに含める。またプロセッサ31は、今回の登録がエラーとされているならば、その旨を表すエラーデータを指示データに含める。そしてプロセッサ31はこののち、図14中のACT205~ACT209の待受状態に戻る。
なお、以降において説明するモバイルコントローラ3からユーザ端末300への各種の指示は、上記と同様に、指示の理由を識別するための識別データを含んだ指示データを店内通信ネットワーク7及びアクセスポイント6を介してモバイルコントローラ3からユーザ端末300へと送ることにより実現される。
一方でプロセッサ31は、要確認商品であるためにACT216にてYESと判定したならば、ACT218へと進む。つまりプロセッサ31は、正規登録された商品が要確認商品であって、かつ要確認フラグが“0”である場合に、ACT218へと進む。
ACT218としてプロセッサ31は、処理対象となっている取引が取引管理データベースDB31にて関連付けられたデータレコードDR1に関して、そのフィールドF14にセットされている要確認フラグを“1”に書き替える。
ACT218としてプロセッサ31は、ガイダンス画面の表示をユーザ端末300に対して指示する。プロセッサ31は、ガイダンス画面の表示を指示するための指示データには、処理対象となっている取引が登録データベースDB32にて関連付けられたデータレコードDR2に含まれている商品コード、商品名、価格及び個数を含める。そしてプロセッサ31はこののち、図14中のACT205~ACT209の待受状態に戻る。
ユーザ端末300にてプロセッサ301は、図10のACT120にて登録を要求したのちには、図11中のACT121へと進む。
ACT121としてプロセッサ301は、ガイダンス画面の表示が指示されたか否かを確認する。そしてプロセッサ301は、該当の指示が確認できなければNOと判定し、ACT122へと進む。
ACT122としてプロセッサ301は、一覧画面の表示が指示されたか否かを確認する。そしてプロセッサ301は、該当の指示が確認できなければNOと判定し、ACT121へと戻る。
かくしてプロセッサ301はACT121及びACT122としては、ガイダンス画面又は一覧画面の表示指示を待ち受ける。そしてプロセッサ301は、前述のように一覧画面の表示がモバイルコントローラ3から指示されたならば、ACT122にてYESと判定し、図10中のACT112へと戻り、再び一覧画面SC1をタッチパネル304に表示させる。このときにプロセッサ301は、一覧画面SC1を、指示データに含まれた購入商品の商品名、価格及び個数を表す画面とする。
図20は購入商品が登録済みである状態での一覧画面SC1の一例を示す図である。
図20に示す一覧画面SC1は、商品名が“AAA”であり、価格が120円である商品が1個、商品名が“BBB”であり、価格が98円である商品が2個、そして商品名が“CCC”であり、価格が1,024円である商品が1個、購入商品として登録済みである場合の例である。そしてこれらの商品はいずれも、要確認商品ではない。図20に示す一覧画面SC1では、表示エリアAR12には、これらの登録済みの商品に関する商品名、価格及び個数を表している。また表示エリアAR11には、総数として“4”を表すとともに、総額として“1,340”を表している。なお、商品名の左側の破線で囲まれたエリアは、アイコンを表示するためのエリアを表す。当該エリアを表す破線は、実際には一覧画面SC1には表されない。
図21は購入商品が登録済みである状態での一覧画面SC1の一例を示す図である。
図21に示す一覧画面SC1は、商品名が“AAA”であり、価格が120円である商品が1個、商品名が“BBB”であり、価格が98円である商品が2個、商品名が“CCC”であり、価格が1,024円である商品が1個、さらに商品名が“DDD”であり、価格が380円である商品が1個、購入商品として登録済みである場合の例である。そして商品名が“DDD”である商品は、要確認商品である。図21に示す一覧画面SC1では、表示エリアAR12には、これらの登録済みの商品に関する商品名、価格及び個数を表している。また表示エリアAR11には、総数として“5”を表すとともに、総額として“1,720”を表している。また、商品名が“DDD”の横には、購入者に年齢制限がある商品であることを表すアイコンIC11を表している。
一方でプロセッサ301は、前述のようにガイダンス画面の表示がモバイルコントローラ3から指示されたならば、図11中のACT121にてYESと判定し、ACT123へと進む。
ACT123としてプロセッサ301は、ガイダンス画面をタッチパネル304に表示させる。ガイダンス画面は、会計時に店員による確認が必要であることを客に対して案内するための画面である。
図22はガイダンス画面SC3の一例を示す図である。
ガイダンス画面SC3は、一覧画面SC1にウィンドウWI31を重ねて表した画面である。ウィンドウWI31は、メッセージME31及びボタンBU31を含む。メッセージME31は、会計時に店員による確認が必要であることを表した文字メッセージである。ボタンBU31は、ガイダンス画面SC3での案内を確認したことを客が宣言するためのソフトキーである。プロセッサ301は、指示データに含まれた購入商品の商品名、価格及び個数を表す一覧画面SC1を生成し、これにウィンドウWI31を重ねてガイダンス画面SC3を生成する。
客は、ガイダンス画面SC3での案内を確認したならば、ガイダンス画面SC3におけるボタンBU31にタッチするなどの予め定められた操作によって、確認したことを宣言する。これに応じてプロセッサ301は、図11中のACT123から図10中のACT112へと戻り、再び一覧画面SC1をタッチパネル304に表示させる。なおプロセッサ301は、ガイダンス画面SC3を表示した状態での経過時間が予め定めた時間に到達した場合に、ACT123からACT112へと戻ってもよい。
客が一覧画面SC1における個数を表しているエリアにタッチすると、プロセッサ301は一覧画面SC1に重ねて個数指定のためのリストボックスを表示させる。そしてこのリストボックスが操作されると、プロセッサ301はこれを個数の指定として受ける。そしてプロセッサ301はこの場合、図10中のACT114にてYESと判定し、図11中のACT124へと進む。
ACT124としてプロセッサ301は、指定数が0であるか否かを確認する。そしてプロセッサ301は、指定数が0ではなければNOと判定し、ACT125へと進む。
ACT125としてプロセッサ301は、モバイルコントローラ3に対して数量変更を要求する。プロセッサ301はここで送信する要求データには、個数が指定された商品を特定するための特定データと指定数を含める。特定データは、商品コードでもよいし、購入商品のリスト内で各購入商品を識別するための番号などのようにモバイルコントローラ3でのみ購入商品を特定可能なデータであってもよい。なお、特定コードとして商品コードを用いるならば、プロセッサ31は、一覧画面の表示を指示するための指示データ又はガイダンス画面の表示を指示するための指示データに、各購入商品に関する商品コードを含める。
モバイルコントローラ3にてプロセッサ31は、上記のようにユーザ端末300から数量変更が要求されたならば、図14中のACT206にてYESと判定し、図15中のACT220へと進む。
ACT220としてプロセッサ31は、処理対象となっている取引の取引コードの通知を伴って、数量変更の要求を仮想POSサーバ2に転送する。プロセッサ31はこのとき、ユーザ端末300から送られてきた要求データをそのまま仮想POSサーバ2に転送してもよいし、何らかの処理による変換後の要求データを仮想POSサーバ2に送信してもよい。ただしプロセッサ31は、ユーザ端末300から送られてきた要求データに含まれた個数は、仮想POSサーバ2へと通知する。また要求データに含まれる特定データが商品コードではないならば、プロセッサ31は、当該特定データを商品コードに置き換える。
仮想POSサーバ2においてプロセッサ21は、モバイルコントローラ3から送られた要求データに含まれた個数が、既存のPOS端末に備えられた入力デバイスにより入力されたものであると見做して、既存のPOS端末と同様な処理によって購入商品の個数を変更する。プロセッサ21は、個数を変更した商品の商品コードと、変更後の個数とを表した結果データを、モバイルコントローラ3に送信する。
モバイルコントローラ3にてプロセッサ31は、ACT220にて数量変更の要求を転送したのちには、ACT221へと進む。
ACT221としてプロセッサ31は、上記のようにして仮想POSサーバ2から送信される結果データを取得する。プロセッサ31は、取得した結果データをメインメモリ32又は補助記憶ユニット33に保存する。
ACT222としてプロセッサ31は、上記の結果データに基づいて登録データベースDB32を更新する。つまりプロセッサ31は、処理対象となっている取引が関連付けられたデータレコードDR2から、通知された商品コードを含んだ登録データを見つけ出す。そしてプロセッサ31は、該当する登録データに含まれる個数を、結果データに含まれた個数に書き替える。
なおプロセッサ31は、数量変更の要求データで送られてきた特定データ及び個数をメインメモリ32又は補助記憶ユニット33に保存しておき、更新が完了した旨を表す結果データを受けたことに応じて、この保存してある特定データで特定される商品に関する登録データの個数を、保存してある個数に書き替えてもよい。そしてこの場合には、仮想POSサーバ2においてプロセッサ21は、結果データに商品コード及び個数を含めなくてもよい。
ACT223としてプロセッサ31は、一覧画面の表示をユーザ端末300に対して指示する。プロセッサ31は例えば、一覧画面の表示指示であることを識別するための識別データを含んだ指示データを、店内通信ネットワーク7及びアクセスポイント6を介してユーザ端末300へと送信する。プロセッサ31は、上記のように更新したデータレコードDR2に含まれる登録データのうちで取消フラグが“0”である登録データに含まれている商品コード、商品名、価格及び個数を指示データに含める。プロセッサ31はこののち、図14中のACT205~ACT209の待受状態に戻る。
さて、ユーザ端末300にてプロセッサ301は、指定数が0であったならば、図11のACT124にてYESと判定し、ACT126へと進む。
ACT126としてプロセッサ301は、削除画面をタッチパネル304に表示させる。削除画面は、個数を0個とすることが指定された商品が購入商品から削除されることを客に報知する画面である。削除画面は、削除を指定するための削除ボタンと、個数を変更せずに個数の変更を指定する前の状態に戻ることを指定するための戻りボタンとを含む。
ACT127としてプロセッサ301は、削除が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定を確認できないならばNOと判定し、ACT128へと進む。
ACT128としてプロセッサ301は、戻りが指定されたか否かを確認する。そしてプロセッサ301は、該当の指定を確認できないならばNOと判定し、ACT127へと戻る。
かくしてプロセッサ301はACT127及びACT128としては、削除又は戻りが指定されるのを待ち受ける。
客は、削除を取り止めて、個数の変更を指定する前の状態に戻ること望むならば、削除画面において戻りボタンにタッチするなどの予め定められた操作により戻りを指定する。これに応じてプロセッサ301は、ACT128にてYESと判定し、図10中のACT112へと戻り、再び一覧画面SC1をタッチパネル304に表示させる。この場合には、購入商品の登録状態は変更されないので、プロセッサ301は、削除画面を表示する前に表示していたのと同じ状態の一覧画面SC1をタッチパネル304に再び表示させる。
客は、削除で間違いないならば、削除画面において削除ボタンにタッチするなどの予め定められた操作により削除を指定する。これに応じてプロセッサ301は、ACT127にてYESと判定し、ACT129へと進む。
ACT129としてプロセッサ301は、モバイルコントローラ3に対して削除を要求する。プロセッサ301はここで送信する要求データには、削除が指定された商品を特定するための特定データを含める。
モバイルコントローラ3にてプロセッサ31は、上記のようにユーザ端末300から削除が要求されたならば、図14中のACT207にてYESと判定し、図16中のACT224へと進む。
ACT224としてプロセッサ31は、処理対象となっている取引の取引コードの通知を伴って、削除の要求を仮想POSサーバ2に転送する。プロセッサ31はこのとき、ユーザ端末300から送られてきた要求データをそのまま仮想POSサーバ2に転送してもよいし、何らかの処理による変換後の要求データを仮想POSサーバ2に送信してもよい。ただしプロセッサ31は、要求データに含まれる特定データが商品コードではないならば、プロセッサ31は、当該特定データを商品コードに置き換える。
仮想POSサーバ2においてプロセッサ21は、モバイルコントローラ3から送られた要求データによる要求を、既存のPOS端末に備えられた入力デバイスにより入力された削除指示であると見做して、既存のPOS端末と同様な処理によって対象となる商品を購入商品から除外する。プロセッサ21は、購入商品から除外した商品の商品コードを表した結果データを、モバイルコントローラ3に送信する。
モバイルコントローラ3にてプロセッサ31は、ACT224にて削除の要求を転送したのちには、ACT225へと進む。
ACT225としてプロセッサ31は、上記のようにして仮想POSサーバから送信される結果データを取得する。プロセッサ31は、取得した結果データをメインメモリ32又は補助記憶ユニット33に保存する。
ACT226としてプロセッサ31は、上記の結果データに基づいて登録データベースDB32を更新する。つまりプロセッサ31は、処理対象となっている取引が関連付けられたデータレコードDR2から、通知された商品コードを含んだ登録データを見つけ出す。そしてプロセッサ31は、該当する登録データに含まれる取消フラグを“1”に変更する。
なおプロセッサ31は、削除の要求データで送られてきた特定データをメインメモリ32又は補助記憶ユニット33に保存しておき、削除が完了した旨を表す結果データを受けたことに応じて、この保存してある特定データで特定される商品に関する登録データの取消フラグを変更してもよい。そしてこの場合には、仮想POSサーバ2においてプロセッサ21は、結果データに商品コードを含めなくてもよい。
ACT227としてプロセッサ301は、削除した商品が要確認商品であるか否かを確認する。そしてプロセッサ301は、要確認商品であったならばYESと判定し、ACT228へと進む。
ACT228としてプロセッサ301は、処理対象となっている取引の購入商品に他の要確認商品があるか否かを確認する。そしてプロセッサ301は、該当の商品がないならばNOと判定し、ACT229へと進む。つまりプロセッサ301は、今回の商品削除によって購入商品に要確認商品が1つも含まれなくなったならば、ACT229へと進む。
ACT229としてプロセッサ301は、処理対象となっている取引が取引管理データベースDB31にて関連付けられたデータレコードDR1に関して、そのフィールドF14にセットされている要確認フラグを“0”に変更する。
ACT230としてプロセッサ31は、一覧画面の表示をユーザ端末300に対して指示する。プロセッサ31は例えば、一覧画面の表示指示であることを識別するための識別データを含んだ指示データを、店内通信ネットワーク7及びアクセスポイント6を介してユーザ端末300へと送信する。プロセッサ31は、上記のように更新したデータレコードDR2に含まれる登録データのうちで取消フラグが“0”である登録データに含まれている商品コード、商品名、価格及び個数を指示データに含める。プロセッサ31はこののち、図14中のACT205~ACT209の待受状態に戻る。なおプロセッサ31は、削除した商品が要確認商品ではないためにACT227にてNOと判定した場合と、要確認商品が他にあるためにACT228にてYESと判定した場合には、ACT229及びACT230をパスして、図14中のACT205~ACT209の待受状態に戻る。
さて、ユーザ端末300にてプロセッサ301は、ACT125にて数量変更を要求したのち、あるいはACT129にて削除を要求したのちには、ACT130へと進む。
ACT130としてプロセッサ301は、一覧画面の表示が指示されるのを待ち受ける。そしてプロセッサ301は、数量変更の要求に応じて、あるいは削除の要求に応じて、前述のように一覧画面の表示がモバイルコントローラ3から指示されたならばYESと判定し、図10中のACT112へと戻り、再び一覧画面SC1をタッチパネル304に表示させる。このときにプロセッサ301は、一覧画面SC1を、指示データに含まれた購入商品の商品名、価格及び個数を表す画面とする。この場合には、購入商品の登録状態が変更されるので、プロセッサ301は、数量変更又は削除が指定されるときに表示していたのとは異なる購入商品を表す状態の一覧画面SC1をタッチパネル304に表示させることになる。
客は、既に登録した購入商品の全てをキャンセルし、買い物を中止したい場合には、一覧画面SC1においてボタンBU11にタッチするなどの予め定められた操作により中止を指定する。これに応じてプロセッサ301は、ACT115にてYESと判定し、図11中のACT131へと進む。
ACT131としてプロセッサ301は、取消画面をタッチパネル304に表示させる。取消画面は、既に登録した購入商品の全てが取り消されることを客に報知する画面である。取消画面は、取消実行を指定するための実行ボタンと、個数を変更せずに個数の変更を指定する前の状態に戻ることを指定するための戻りボタンとを含む。
ACT132としてプロセッサ301は、取消実行が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定を確認できないならばNOと判定し、ACT133へと進む。
ACT133としてプロセッサ301は、戻りが指定されたか否かを確認する。そしてプロセッサ301は、該当の指定を確認できないならばNOと判定し、ACT132へと戻る。
かくしてプロセッサ301はACT132及びACT133としては、取消実行又は戻りが指定されるのを待ち受ける。
客は、そのまま買い物を続けるならば、取消画面において戻りボタンにタッチするなどの予め定められた操作により戻りを指定する。これに応じてプロセッサ301は、ACT133にてYESと判定し、図10中のACT112へと戻り、再び一覧画面SC1をタッチパネル304に表示させる。この場合には、購入商品の登録状態は変更されないので、プロセッサ301は、取消画面を表示する前に表示していたのと同じ状態の一覧画面SC1をタッチパネル304に再び表示させる。
客は、買い物を取り止めるのであれば、取消画面において実行ボタンにタッチするなどの予め定められた操作により取消実行を指定する。これに応じてプロセッサ301は、ACT132にてYESと判定し、ACT134へと進む。
ACT134としてプロセッサ301は、モバイルコントローラ3に対して取消を要求する。
モバイルコントローラ3にてプロセッサ31は、上記のようにユーザ端末300から取消が要求されたならば、図14中のACT208にてYESと判定し、図16中のACT231へと進む。
ACT231としてプロセッサ31は、処理対象となっている取引の取引コードの通知を伴って、取消の要求を仮想POSサーバ2に転送する。プロセッサ31はこのとき、ユーザ端末300から送られてきた要求データをそのまま仮想POSサーバ2に転送してもよいし、何らかの処理による変換後の要求データを仮想POSサーバ2に送信してもよい。
仮想POSサーバ2においてプロセッサ21は、モバイルコントローラ3から送られた要求データによる要求を、既存のPOS端末に備えられた入力デバイスにより入力された取消指示であると見做して、既存のPOS端末と同様な処理によって、通知された取引コードに関連付けて登録済みの商品の全てを購入商品から除外する。プロセッサ21は、取消が完了したことを表した結果データを、モバイルコントローラ3に送信する。
モバイルコントローラ3にてプロセッサ31は、ACT231にて削除の要求を転送したのちには、ACT232へと進む。
ACT232としてプロセッサ31は、上記のようにして仮想POSサーバから送信される結果データを取得する。プロセッサ31は、取得した結果データをメインメモリ32又は補助記憶ユニット33に保存する。
ACT233としてプロセッサ31は、上記の結果データに基づいて登録データベースDB32を更新する。つまりプロセッサ31は、処理対象となっている取引が関連付けられたデータレコードDR2に含まれる登録データの全てに関して、“0”となっている取消フラグを“1”に変更する。
ACT234としてプロセッサ301は、処理対象となっている取引が取引管理データベースDB31にて関連付けられたデータレコードDR1に関して、そのフィールドF14にセットされている要確認フラグを“0”に変更する。
ACT235としてプロセッサ31は、ユーザ端末300に対して取消を通知する。そしてプロセッサ31はこののち、図14中のACT205~ACT209の待受状態に戻る。
さて、ユーザ端末300にてプロセッサ301は、ACT134にて取消を要求したのちには、ACT135へと進む。
ACT135としてプロセッサ301は、モバイルコントローラ3から取消が通知されるのを待ち受ける。そしてプロセッサ301は、前述のように取消が通知されたならばYESと判定し、図9中のACT101へと戻る。
客は、購入を希望する商品の全てを購入商品として登録し終えたならば、決済に進む。このときに客は、一覧画面SC1におけるボタンBU13にタッチするなどの予め定められた操作によって会計開始を指定する。これに応じてプロセッサ301は、図10中のACT116にてYESと判定し、ACT136へと進む。
ACT136としてプロセッサ301は、モバイルコントローラ3に対して会計を要求する。
モバイルコントローラ3にてプロセッサ31は、上記のようにユーザ端末300から会計が要求されたならば、図14中のACT209にてYESと判定し、図17中のACT236へと進む。
ACT236としてプロセッサ31は、処理対象となっている取引に取引管理データベースDB31にて関連付けられたデータレコードDR1のフィールドF14にセットされ要確認フラグが“1”であるか否かを確認する。そして該当の要確認フラグが“1”であるならばYESと判定し、ACT237へと進む。つまりプロセッサ31は、購入商品に要確認商品が含まれるか、正しく登録できていない商品があるならば、ACT237へと進む。なお以下においては、このよう要確認フラグが“1”である状態を要確認状態と称する。
ACT237としてプロセッサ31は、確認画面の表示をユーザ端末300に対して指示する。
さてユーザ端末300にてプロセッサ301は、図10中のACT136にて会計を要求したのちには、ACT137へと進む。
ACT137としてプロセッサ301は、確認画面の表示が指示されたか否かを確認する。そしてプロセッサ301は、当該の指示が確認できないならばNOと判定し、ACT138へと進む。
ACT138としてプロセッサ301は、会計画面の表示が指示されたか否かを確認する。そしてプロセッサ301は、当該の指示が確認できないならばNOと判定し、ACT137へと戻る。
かくしてプロセッサ301はACT137及びACT138としては、確認画面又は会計画面の表示が指示されるのを待ち受ける。そしてプロセッサ301は、前述のようにモバイルコントローラ3から確認画面の表示が指示されたならば、ACT137にてYESと判定し、図12中のACT139へと進む。
ACT139としてプロセッサ301は、確認画面を表示する。確認画面は、要確認商品の確認のために店員に連絡することを客に促すための画面である。
図23は確認画面SC4の一例を示す図である。
確認画面SC4は、直前に表示していた一覧画面SC1にウィンドウWI41を重ねて表した画面である。ウィンドウWI41は、メッセージME41及びボタンBU41,BU42を含む。メッセージME41は、店員による確認を受ける必要があることを表した文字メッセージである。ボタンBU41は、店員による確認を受けることを客が指定するためのソフトキーである。ボタンBU42は、商品登録に戻ることを客が指定するためのソフトキーである。
客は、店員による確認を受けることを決めたならば、ボタンBU41にタッチするなどの予め定められた操作によって確認を指定する。また客は、会計を一旦取り止め、商品登録に戻ることを決めたならば、ボタンBU42にタッチするなどの予め定められた操作によって、戻りを指定する。
図12中のACT140としてプロセッサ301は、確認が指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できなければNOと判定し、ACT141へと進む。
ACT141としてプロセッサ301は、戻りが指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できなければNOと判定し、ACT140へと戻る。
かくしてプロセッサ301はACT140及びACT141としては、確認又は戻りが指定されるのを待ち受ける。そしてプロセッサ301は、前述のように確認が指定されたならば、ACT140にてYESと判定し、ACT142へと進む。
ACT142としてプロセッサ301は、解除画面をタッチパネル304に表示させる。解除画面は、要確認状態を解除するためのバーコードをユーザ端末300に読み取らせるための画面である。
図24は解除画面SC5の一例を示す図である。
解除画面SC5は、表示エリアAR51、メッセージME51及びボタンBU51を含む。表示エリアAR51は、カメラ305で得られた画像を表示する。メッセージME51は、要確認状態の解除用のバーコードを読み取るように店員に促す文字メッセージである。ボタンBU51は、解除用のバーコードのスキャンを中止することを客又は店員が宣言するためのソフトキーである。
プロセッサ301は例えば、カメラ305を起動し、これによりカメラ305で得られた画像に、表示エリアAR51の範囲を表すラインと、メッセージME51及びボタンBU51とを表した画像を重ねて解除画面SC5を生成する。
客は、店員に確認を依頼する。店員は例えば、購入商品に要確認商品が含まれるならば、その要確認商品の販売が許容されることを確認する。また店員は例えば、客が所持している商品を確認し、未登録の商品が含まれないことを確認する。そして店員は、これらがいずれも満たされるならば、決済が許容されると判定し、解除用のバーコードが表示エリアAR51に映り込むようにカメラ305に解除用のバーコードを翳す。なお店員はこの作業のために、解除用のバーコードが印刷されたカードなどを所持しておく。あるいは、店員は、所持している情報端末の画面に解除用のバーコードを表示させる。なお、解除用のバーコードは、好ましくは店舗毎又は事業者毎に異なるものが用いられる。ただし、異なる店舗又は異なる事業者で、同じ解除用のバーコードが用いられることは許容される。また正規の解除用のバーコードを例えば1日毎などのように変更することにより、解除用のバーコードが何らかの事情で客に取得された場合における不正を防止することが可能となる。
なお店員は、要確認商品の販売が許容されないこと、あるいは未登録の商品を客が所持していることを確認したならば、ボタンBU51にタッチするなどの予め定められた操作によって、商品登録への戻りを指定する。あるいは客は、店員に確認を依頼することなく商品登録に戻ることを決めたならば、ボタンBU51にタッチするなどの予め定められた操作によって、商品登録への戻りを指定する。
この後の要確認商品又は未登録の商品に関する処置は、客又は店員により適宜に行われてよい。例えば客は、要確認商品を購入商品から取り消すようにユーザ端末300を操作する。例えば客は、要確認商品を購入可能とするための手続きを行う。例えば客は、未登録の商品の商品コードを表したバーコードの読み取りにより当該商品を購入商品として登録するための操作をユーザ端末300にて行う。例えば店員は、ユーザ端末300での店員用の特別な操作、あるいは店員用の端末での操作により、未登録の商品を購入商品として登録するための操作を行う。例えば店員は、未登録の商品を回収する。この場合に店員は必要があれば、当該商品の商品コードを商品データベースに登録するための処置を講じる。
ACT143としてプロセッサ301は、バーコードが読み取れたか否かを確認する。このときにプロセッサ301は、カメラ305で得られる画像を解析し、バーコードの読み取りを試みる。このバーコードの読み取りは、スマホPOSアプリAP301に基づく処理として行われてもよいし、バーコードの読み取り用の別のアプリケーションプログラムに基づく処理として行われてもよい。そしてプロセッサ301は、バーコードが読み取れないならばNOと判定し、ACT144へと進む。
ACT144としてプロセッサ301は、戻りが指定されたか否かを確認する。そしてプロセッサ301は、該当の指定が確認できないならばNOと判定し、ACT143に戻る。
かくしてプロセッサ301はACT143及びACT144としては、バーコードが読み取れるか、戻りが指定されるのを待ち受ける。
プロセッサ301は、前述のように戻りが指定されたならば、ACT144にてYESと判定し、ACT145へと進む。なおプロセッサ301は、確認画面SC4をタッチパネル304に表示させている状態において、前述のように戻りが指定されたならば、ACT141にてYESと判定し、ACT145へと進む。
ACT145としてプロセッサ301は、商品登録への戻りをモバイルコントローラ3に対して要求する。そしてプロセッサ301は、図10中のACT112へと戻る。
さてモバイルコントローラ3にてプロセッサ31は、図17中のACT237にて確認画面の表示を指示したのちには、ACT238へと進む。
ACT238としてプロセッサ31は、解除が要求されたか否かを確認する。そしてプロセッサ31は、当該の要求が確認できないならばNOと判定し、ACT239へと進む。
ACT239としてプロセッサ31は、戻りが要求されたか否かを確認する。そしてプロセッサ31は、当該の要求が確認できないならばNOと判定し、ACT238へと戻る。
かくしてプロセッサ31はACT238及びACT239としては、解除又は戻りが要求されるのを待ち受ける。そしてプロセッサ31は、前述のように商品登録への戻りがユーザ端末300から要求されたならば、ACT239にてYESと判定し、図14中のACT205~ACT209の待受状態に戻る。
つまり、モバイルコントローラ3及びユーザ端末300ともに、商品登録を行う状態に戻る。
一方で、ユーザ端末300では、カメラ305により撮影される画像にバーコードが映り込むと、プロセッサ301は、図12中のACT143にてYESと判定し、ACT146へと進む。
ACT146としてプロセッサ301は、読み取ったバーコードが表すバーコードデータを、メインメモリ302又は補助記憶ユニット303に保存する。
ACT147としてプロセッサ301は、モバイルコントローラ3に対して要確認状態の解除を要求する。プロセッサ301はここで送信する要求データには、上記の保存したバーコードデータを含める。またプロセッサ301はここで送信する要求データには、図9中のACT107にて保存してあるチェックインデータに含まれる認証データを含める。
このようにユーザ端末300からモバイルコントローラ3へと解除が要求されると、モバイルコントローラ3にてプロセッサ31は、図17中のACT238にてYESと判定し、ACT240へと進む。
ACT240としてプロセッサ31は、認証処理を行う。プロセッサ31は例えば、要求データからバーコードデータ及び認証データを取り出し、メインメモリ32又は補助記憶ユニット33へと保存する。このようにスマホPOSアプリAP31に基づく情報処理をプロセッサ31が実行することによって、プロセッサ31を中枢部分とするコンピュータは取得手段として機能する。そしてプロセッサ31は、このように取得したバーコードデータと認証データとに基づき、読み取られたバーコードが解除用の正規のバーコードであるかを確認する処理である。この認証処理は、例えば次のいずれかにより行うことができる。
(1) プロセッサ31は、バーコードデータと認証データとが一致する場合に、解除用の正規のバーコードが読み取られたと判定する。
(2) プロセッサ31は、バーコードデータを予め定められたアルゴリズムで処理し、この結果得られるデータと認証データとが一致する場合に、解除用の正規のバーコードが読み取られたと判定する。
(3) プロセッサ31は、認証データを予め定められたアルゴリズムで処理し、この結果得られるデータとバーコードデータとが一致する場合に、解除用の正規のバーコードが読み取られたと判定する。
(4) プロセッサ31は、バーコードデータを予め定められた第1のアルゴリズムで処理し、認証データを予め定められた第2のアルゴリズムで処理する。そしてこれの結果として得られる2つのデータが互いに一致する場合に、解除用の正規のバーコードが読み取られたと判定する。
この他、バーコードデータと認証データとが予め定められた関係にあることを確認する如何なる処理も適用が可能である。そしてプロセッサは、バーコードデータと認証データとが予め定められた関係にあることが確認できた場合に、解除用の正規のバーコードが読み取られたと判定すればよい。
ACT241としてプロセッサ31は、認証に成功したか否かを確認する。そしてプロセッサ31は、認証に失敗したならばNOと判定し、ACT242へと進む。
ACT242としてプロセッサ31は、警告画面の表示をユーザ端末300に対して指示する。そしてプロセッサ31はこののち、ACT238及びACT239の待受状態に戻る。
ユーザ端末300にてプロセッサ301は、図12中のACT147にて解除を要求したのちには、ACT148へと進む。
ACT148としてプロセッサ301は、警告画面の表示が指示されたか否かを確認する。そしてプロセッサ301は、該当の指示が確認できないならばNOと判定し、ACT149へと進む。
ACT149としてプロセッサ301は、会計画面の表示が指示されたか否かを確認する。そしてプロセッサ301は、該当の指示が確認できないならばNOと判定し、ACT148へと戻る。
かくしてプロセッサ301はACT148及びACT149としては、警告画面又は会計画面の表示が指示されるのを待ち受ける。そしてプロセッサ301は、前述のようにモバイルコントローラ3から警告画面の表示が指示されたならば、ACT148にてYESと判定し、ACT150へと進む。
ACT150としてプロセッサ301は、警告画面をタッチパネル304に表示させる。警告画面は、店員が読み取らせた解除用のバーコードが正しくないことを店員に警告するための画面である。
図25は警告画面SC6の一例を示す図である。
警告画面SC6は、直前に表示していた解除画面SC5にウィンドウWI61を重ねて表した画面である。ウィンドウWI61は、メッセージME61及びボタンBU61を含む。メッセージME61は、読み取ったバーコードが正しくないことを表した文字メッセージである。ボタンBU61は、警告画面SC6での報知を確認したことを店員が宣言するためのソフトキーである。
プロセッサ301は、例えば警告画面SC6中に表したボタンBU61へのタッチなどの予め定められた操作により警告画面SC6の表示解消が指示されたならば、ACT142に戻る。
モバイルコントローラ3にてプロセッサ31は、図17中のACT240における認証処理の結果、認証に成功したならば、ACT241にてYESと判定し、ACT243へと進む。なおプロセッサ31は、要確認フラグが“0”であるならば、ACT236にてNOと判定し、ACT243へと進む。
ACT243としてプロセッサ31は、会計画面の表示をユーザ端末300に指示する。こののちプロセッサ31は、仮想POSサーバ2又は会計機5により購入商品として登録されている商品の代金を決済させるための以下に説明する処理を開始する。つまりプロセッサ31は、取得したバーコードデータが認証データに対して予め定められた関係にあるデータとしての解除データである場合に、決済処理の開始を許容する。かくしてスマホPOSアプリAP31に基づく情報処理をプロセッサ31が実行することによって、プロセッサ31を中枢部分とするコンピュータは制御手段として機能する。
プロセッサ31がACT236にてNOと判定してACT243へと進んだ場合、ACT237はパスされるから、ユーザ端末300に確認画面の表示が指示されることはない。このため、プロセッサ31がACT243にて会計画面の表示を指示するときには、ユーザ端末300にてプロセッサ301は、図10中のACT137及びACT138の待受状態にある。このためプロセッサ301は上記の会計画面の表示指示に応じてACT138にてYESと判定し、図13中のACT151へと進む。
またプロセッサ31がACT241にてYESと判定してACT243へと進んだ場合、プロセッサ31がACT243にて会計画面の表示を指示するときには、ユーザ端末300にてプロセッサ301は、図12中のACT148及びACT149の待受状態にある。このためプロセッサ301は上記の会計画面の表示指示に応じてACT149にてYESと判定し、図13中のACT151へと進む。
ACT151としてプロセッサ301は、会計画面をタッチパネル304に表示させる。会計画面は、代金の決済のための操作をユーザ端末300及び会計機5のいずれで行うかを客が選択するための画面である。
図26は会計画面SC7の一例を示す図である。
会計画面SC7は、表示エリアAR71、メッセージME71及びボタンBU71,BU72を含む。表示エリアAR71は、購入商品の総数と、購入商品の代金の総額とを表す。メッセージME71は、代金の決済のための操作をユーザ端末300及び会計機5のいずれで行うかを指定するように客に促す文字メッセージである。ボタンBU71は、ユーザ端末300を客が指定するソフトキーである。ボタンBU72は、会計機5を客が指定するためのソフトキーである。
客は、代金の決済のための操作をユーザ端末300で行いたい場合には、ボタンBU71にタッチするなどの予め定められた操作によりユーザ端末300を指定する。また客は、代金の決済のための操作を会計機5で行いたい場合には、ボタンBU72にタッチするなどの予め定められた操作により会計機5を指定する。
ACT152としてプロセッサ301は、ユーザ端末300が指定されたか否かを確認する。そしてプロセッサ301は、当該の指定が確認できないならばNOと判定し、ACT153へと進む。
ACT153としてプロセッサ301は、会計機5が指定されたか否かを確認する。そしてプロセッサ301は、当該の指定が確認できないならばNOと判定し、ACT152へと戻る。
かくしてプロセッサ301はACT152及びACT153としては、ユーザ端末300又は会計機5が指定されるのを待ち受ける。そしてプロセッサ301は、上述のようにユーザ端末300が指定されたならば、ACT152にてYESと判定し、ACT154へと進む。
ACT154としてプロセッサ301は、モバイルコントローラ3に対して決済を要求する。なおプロセッサ301は、決済を要求するための要求データには、決済のために必要な、クレジット番号又はオンライン決済サービス用の利用者コードなどのような決済データを含める。
またプロセッサ301は、上述のように会計機5が指定されたならば、ACT153にてYESと判定し、ACT155へと進む。
ACT155としてプロセッサ301は、会計バーコード画面をタッチパネル304に表示させる。会計バーコード画面は、会計機5が仮想POSサーバ2から取引の内容に関するデータを取得するために必要となるデータを表した会計バーコードを表した画面である。なお、詳細な処理の図示は省略しているが、プロセッサ301は、モバイルコントローラ3を介して仮想POSサーバ2から会計バーコードを取得して、当該会計バーコードを会計バーコード画面に表す。
客は、他の客により使用されていない会計機5が備えるスキャナに、会計バーコードを読み取らせる。これに応じて会計機5は、会計バーコードが表すデータに従って、仮想POSサーバ2から取引の内容に関するデータを取得し、このデータに基づいて算出した決済額を決済するための処理を実行する。そして会計機5は、決済が完了したならば、その旨を仮想POSサーバ2に通知する。仮想POSサーバ2にてプロセッサ21は、会計機5から決済完了が通知されたならば、モバイルコントローラ3へと決済完了を通知する。なお、会計機5での決済完了は、会計機5からモバイルコントローラ3へと直接通知されてもよい。かくして会計機5は決済手段の一例である。
モバイルコントローラ3にてプロセッサ31は、図17中のACT243にて会計画面の表示を指示したのちには、ACT244へと進む。
ACT244としてプロセッサ31は、決済が要求されたか否かを確認する。そしてプロセッサ31は、当該の要求が確認できないならばNOと判定し、ACT245へと進む。
ACT245としてプロセッサ31は、決済完了が通知されたか否かを確認する。そしてプロセッサ31は、当該の通知が確認できないならばNOと判定し、ACT244へと戻る。
かくしてプロセッサ31はACT244及びACT245としては、決済要求又は決済完了通知を待ち受ける。そしてプロセッサ31は、前述のようにユーザ端末300から決済が要求されたならばACT244にてYESと判定し、ACT246へと進む。
ACT246としてプロセッサ31は、処理対象となっている取引の取引コードの通知を伴って、決済の要求を仮想POSサーバ2に転送する。プロセッサ31はこのとき、ユーザ端末300から送られてきた要求データをそのまま仮想POSサーバ2に転送してもよいし、何らかの処理による変換後の要求データを仮想POSサーバ2に送信してもよい。
仮想POSサーバ2においてプロセッサ21は、モバイルコントローラ3から送られた要求データによる要求を、既存のPOS端末に備えられた入力デバイスにより入力された決済指示であると見做して、既存のPOS端末と同様な処理によって、通知された取引コードで識別される取引に関する代金を算出し、これを決済データに基づいて決済するための処理を行う。なお決済のための処理は例えば、図示しない決済サーバへの決済要求を含む。そしてプロセッサ21は、決済が完了したことを表した結果データを、モバイルコントローラ3に送信する。かくして仮想POSアプリAP21に基づく情報処理をプロセッサ21が実行することによって、プロセッサ21を中枢部分とするコンピュータは決済手段として機能する。
モバイルコントローラ3にてプロセッサ31は、ACT246にて決済の要求を転送したのちには、ACT247へと進む。
ACT247としてプロセッサ31は、決済完了が仮想POSサーバ2から通知されるのを待ち受ける。そしてプロセッサ31は、上述のように仮想POSサーバ2が送信した、決済が完了したことを表した結果データが通信インタフェース34により受信されたならばYESと判定し、ACT248へと進む。またプロセッサ31は、前述のように会計機5での決済完了が通知されたならば、ACT245にてYESと判定し、ACT248へと進む。
ACT248としてプロセッサ31は、ユーザ端末300に対して決済完了を通知する。
ユーザ端末300にてプロセッサ301は、ACT14中のACT154にてモバイルコントローラ3へと決済を要求したのち、あるいはACT155にて会計バーコード画面を表示したのちには、ACT156へと進む。
ACT156としてプロセッサ301は、決済完了が通知されるのを待ち受ける。そしてプロセッサ301は、上述のようにモバイルコントローラ3から決済完了が通知されたならばYESと判定し、ACT157へと進む。
ACT157としてプロセッサ301は、完了画面をタッチパネル304に表示させる。完了画面は、決済が完了したことを客に報知するための画面である。
客は、完了画面を確認したならば、完了画面に表されたボタンにタッチするなどの予め定められた操作によって、確認したことを宣言する。これに応じてプロセッサ301はACT158へと進む。なおプロセッサ301は、完了画面を表示した状態での経過時間が予め定めた時間に到達した場合に、ACT158へと進んでもよい。
ACT158としてプロセッサ301は、チェックアウト用のスキャン画面をタッチパネル304に表示させる。チェックアウト用のスキャン画面は、チェックアウト用の2次元コードTC2を読み取るための画面である。プロセッサ301は例えば、カメラ305を起動し、これによりカメラ305で得られた画像に、2次元コードTC2を読み取るように客に促す文字メッセージと、2次元コードTC2を翳すべき位置の目安を示すラインとを重ねてスキャン画面を生成する。
客は、チェックアウト用のスキャン画面がタッチパネル304に表示されたならば、店舗の出口付近に掲示されている2次元コードTC2がスキャン画面に映り込むようにカメラ305を2次元コードTC2に向ける。
ACT159としてプロセッサ301は、2次元コードが読み取れるのを待ち受ける。このときにプロセッサ301は、カメラ305で得られる画像を繰り返し解析し、2次元コードの読み取りを試みる。この2次元コードの読み取りは、スマホPOSアプリAP301に基づく処理として行われてもよいし、2次元コードの読み取り用の別のアプリケーションプログラムに基づく処理として行われてもよい。そしてプロセッサ301は、2次元コードが読み取れたならばYESと判定し、ACT160へと進む。
ACT160としてプロセッサ301は、読み取った2次元コードが表すデータがチェックアウトデータであるか否かを確認する。そしてプロセッサ301は、チェックアウトデータでなければNOと判定し、ACT159へと戻る。このときにプロセッサ301は、誤った2次元コードが読み取られたことを客に通知する画面をタッチパネル304に表示させてもよい。
プロセッサ301は、読み取った2次元コードが表すデータがチェックアウトデータであることが確認できたならば、ACT160にてYESと判定し、ACT161へと進む。
ACT161としてプロセッサ301は、モバイルコントローラ3に対して、チェックアウトを要求する。
モバイルコントローラ3にてプロセッサ31は、図17中のACT248にて決済完了を通知したのちには、ACT249へと進む。
ACT249としてプロセッサ31は、チェックアウトが要求されるのを待ち受ける。そしてプロセッサ31は、上述のようにユーザ端末300からチェックアウトが要求されたならばYESと判定し、ACT250へと進む。
ACT250としてプロセッサ31は、チェックアウト処理を実行する。チェックアウト処理は、処理対象となっていた取引の管理のためにメインメモリ32及び補助記憶ユニット33に保存してあるデータをクリアするなどの処理である。なお仮想POSサーバ2は、決済が完了したことに応じて、該当する取引に関する処理を終了してもよいし、モバイルコントローラ3からの指示に応じて取引に関する処理を終了してもよい。そして後者の場合には、プロセッサ31はチェックアウト処理において、仮想POSサーバ2に対して上記指示をする。また、誤ったバーコードスキャンなどを含むユーザの操作の履歴を表した履歴データベースを店舗サーバ1、仮想POSサーバ2又はモバイルコントローラ3、あるいは図示されない別のサーバ等で管理する場合がある。この場合には、プロセッサ31はチェックアウト処理において、今回の取引に関する操作の履歴を反映するように履歴データベースを更新するための処理を行う。
ACT251としてプロセッサ31は、チェックアウトの完了をユーザ端末300に通知する。そしてプロセッサ31は、図14~図17に示す情報処理を終了する。
ユーザ端末300にてプロセッサ301は、図13中のACT161にてチェックアウトを要求したのちには、ACT162へと進む。
ACT162としてプロセッサ301は、チェックアウト完了の通知を待ち受ける。そしてプロセッサ301は、上述のようにモバイルコントローラ3からチェックアウト完了が通知されたならばYESと判定し、ACT163へと進む。
ACT163としてプロセッサ301は、例えば図9中のACT107にて保存したチェックインデータなどのような、今回の買い物に関して一時的に利用する各種のデータをクリアする。そしてプロセッサ301はこののち、図9中のACT101に戻る。
以上のように本実施形態の取引処理システムによれば、ユーザ端末300では、要確認状態では会計のための処理には進まない。つまり、客が購入商品として登録しようとしたものの正しく登録できなかった商品がある場合には、会計のための処理には進まない。これにより、そのような商品が決済されることなく持ち出されることを防止できる。
そしてユーザ端末300は、解除用の正規のバーコードを読み取ったならば、モバイルコントローラ3での認証の下に、会計のための処理に進む。かくして、店員による確認をユーザ端末300で終えることができ、店員を配置した会計コーナーを利用することなしに会計を完了できる。
また本実施形態の取引処理システムによれば、要確認状態の解除のために店員は、解除用のバーコードをユーザ端末300に読み取らせるだけでよいので、そのための作業は店員の大きな負担とはならない。
また本実施形態の取引処理システムによれば、要確認状態の解除のために店員は、ユーザ端末300での操作を行えばよい。このため、客は、店内を巡回している店員を呼び止めて要確認状態の解除を要求することも、あるいはサービスカウンタなどに出向いて、そこに常駐する店員に対して要確認状態の解除を要求することもできる。つまり、所在エリアの異なる複数の店員に解除用のバーコードを与えておくことにより、要確認状態の解除の柔軟性を高めることが可能である。ただし、どのような店員に解除用のバーコードを与えるかは、店舗毎又は事業者毎の事情による。つまりどの店員に解除用のバーコードを与えるかにより、どのような形態での解除を許容するかを店舗又は事業者側の事情に応じて変更することも可能である。
また本実施形態の取引処理システムによれば、認証処理を、チェックインデータに含まれる要求データに基づいて行う。このため、店舗毎あるいは事業者毎に解除用のバーコードを異ならせることが容易である。
この実施形態は、次のような種々の変形実施が可能である。
要確認状態の解除用のデータは、手動での入力操作により指定されたデータを取得する、あるいは記録媒体に電子的に記録されたデータを近接無線通信により取得する等、別の任意の方法で取得されてもよい。
認証データは、店舗システム100内に設けられている任意の記憶デバイスに記憶されていてもよい。例えば認証データは、モバイルコントローラ3にてメインメモリ32又は補助記憶ユニット33に記憶されていてもよい。
会計機による会計の際に店員による確認を行うようにし、会計機での決済へはユーザ端末での店員の確認を経ずに進めるようにしてもよい。
客が商品登録を終了する前の任意のタイミングで正規の解除用のバーコードが読み取られた場合には、要確認フラグを“0”として要確認状態を解除してもよい。このようにすれば、客は店内を見回っている最中に店員を見かけたときに、その店員に要確認状態の解除を要求することができる。ただしこの場合には、要確認状態の解除後に要確認商品を購入商品として登録したならば、要確認フラグが“1”とされて要確認状態となるから、再度の解除が必要となる。
購入商品として登録することができなかった商品が有る状態のみを要確認状態としてもよい。
仮想POSサーバ2の機能と、モバイルコントローラ3の機能とを、1つのサーバで実現してもよい。
ユーザ端末300は、店舗に備え付けられたショッピングカートに取り付けられた、いわゆるカート端末であってもよい。つまり取引処理システムが、カートPOSシステムとして実現されてもよい。あるいは、ユーザ端末300として、ユーザが携帯する端末と、ショッピングカートに取り付けられた端末とが混在していてもよい。
情報処理によりプロセッサ11,21,31,41,301が実現する各機能は、その一部又は全てをロジック回路などのようなプログラムに基づかない情報処理を実行するハードウェアにより実現することも可能である。また上記の各機能のそれぞれは、上記のロジック回路などのハードウェアにソフトウェア制御を組み合わせて実現することも可能である。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
1…店舗サーバ、2…仮想POSサーバ、3…モバイルコントローラ、4…通信サーバ、5…会計機、6…アクセスポイント、7…店内通信ネットワーク、11,21,31,41,301…プロセッサ、12,22,32,42,302…メインメモリ、13,23,33,43,303…補助記憶ユニット、14,24,34,44,…通信インタフェース、15,25,35,46,308…伝送路、45…通信ユニット、304…タッチパネル、305…カメラ、306…無線通信ユニット、307…モバイル通信ユニット、100(100A,100B)…店舗システム、200…中継サーバ、300…ユーザ端末、400…通信ネットワーク。

本発明の実施形態は、取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラムに関する。
本発明が解決しようとする課題は、客が購入商品として登録しようとしたものの正しく登録できなかった商品が決済されることなく持ち出されることを防止できる取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラムを提供することである。
実施形態の取引処理システムは、登録要求手段、会計要求手段、決済要求手段、表示手段、取得手段、通知手段、登録判定手段、指示手段、決済手段及び制御手段を備える。登録要求手段は、購入対象として登録しようとする商品の登録を店舗システムに要求する。会計要求手段は、会計開始が指示されたことに応じて店舗システムに会計を要求する。決済要求手段は、会計要求手段により会計が要求されたのちに、購入対象として登録済みの商品の代金の決済を店舗システムに要求する。表示手段は、会計要求手段による要求に応じて店舗システムから確認画面の表示指示を受けた場合、当該確認画面を表示する。取得手段は、表示手段により確認画面が表示されたのちに、解除データを取得する。通知手段は、取得手段による解除データの取得に応じて、当該解除データを店舗システムに通知する。登録判定手段は、登録要求手段による要求に応じて該当の商品を購入対象として登録できるかを判定する。指示手段は、登録判定手段により登録できないと判定された商品がある場合、会計要求手段による要求に応じて、確認画面の表示を端末に指示する。決済手段は、決済要求手段による要求に応じて、登録判定手段により登録できると判定された商品の代金を客に決済させるための決済処理を行う。制御手段は、指示手段により確認画面の表示を指示した場合には、通知手段により通知された解除データが解除用の正規の解除データである場合に、決済手段決済処理を行うことを許容する。
このようにプロセッサ31により更新されることにより登録データベースDB32は、仮想POSサーバ2で登録済みの購入商品のリストを表すとともに、これに加えてエラーとなったバーコード読み取りを記録したものとなる。
なおプロセッサ31は、登録要求で送られてきたバーコードデータをメインメモリ32又は補助記憶ユニット33に保存しておき、上記の第4のケースにおいては、この保存してあるバーコードデータを登録データに含めてもよい。そしてこの場合には、仮想POSサーバ2においてプロセッサ21は、結果データにバーコードデータを含めなくてもよい。またプロセッサ31は、保存してあるバーコードデータから商品コードを取り出し、この商品コードに基づいて第1~第3のケースの処理を行ってもよい。また商品名及び価格は、プロセッサ31が商品コードに基づいて店舗サーバ1などから取得してもよい。
このようにユーザ端末300からモバイルコントローラ3へと解除が要求されると、モバイルコントローラ3にてプロセッサ31は、図17中のACT238にてYESと判定し、ACT240へと進む。
ACT240としてプロセッサ31は、認証処理を行う。プロセッサ31は例えば、要求データからバーコードデータ及び認証データを取り出し、メインメモリ32又は補助記憶ユニット33へと保存する。このようにスマホPOSアプリAP301に基づく情報処理をプロセッサ31が実行することによって、プロセッサ31を中枢部分とするコンピュータは取得手段として機能する。そしてプロセッサ31は、このように取得したバーコードデータと認証データとに基づき、読み取られたバーコードが解除用の正規のバーコードであるかを確認する処理である。この認証処理は、例えば次のいずれかにより行うことができる。
モバイルコントローラ3にてプロセッサ31は、図17中のACT240における認証処理の結果、認証に成功したならば、ACT241にてYESと判定し、ACT243へと進む。なおプロセッサ31は、要確認フラグが“0”であるならば、ACT236にてNOと判定し、ACT243へと進む。
ACT243としてプロセッサ31は、会計画面の表示をユーザ端末300に指示する。こののちプロセッサ31は、仮想POSサーバ2又は会計機5により購入商品として登録されている商品の代金を決済させるための以下に説明する処理を開始する。つまりプロセッサ31は、取得したバーコードデータが認証データに対して予め定められた関係にあるデータとしての解除データである場合に、決済処理の開始を許容する。かくしてスマホPOSアプリAP301に基づく情報処理をプロセッサ31が実行することによって、プロセッサ31を中枢部分とするコンピュータは制御手段として機能する。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
以下に、本願の当初の特許請求の範囲に記載された発明を付記する。
[付記1] 端末における操作により指定された商品を、前記端末を利用している客による購入対象の商品として登録する登録手段と、
前記登録手段により登録された前記商品の代金を前記客に決済させるための決済処理を行う決済手段と、
前記登録手段により前記購入対象として登録できなかった商品が有る場合に、前記端末における操作により指定されるデータを取得する取得手段と、
前記取得手段により取得された前記データが予め定められた解除データである場合に、前記決済手段による前記決済処理の開始を許容する制御手段と、
を具備した取引処理システム。
[付記2] 前記制御手段は、前記取得手段により取得された前記データと認証データとが予め定められた関係にある場合に、前記取得手段により取得された前記データが前記解除データであると判定する、
付記1に記載の取引処理システム。
[付記3] 前記制御手段は、前記客の入店時に前記端末を介して取得された認証データを用いる、付記2に記載の取引処理システム。
[付記4] 前記取得手段は、前記端末で読み取られたバーコードが表すバーコードデータを前記データとして取得する、
付記1~付記3のいずれか一項に記載の取引処理システム。
[付記5] 端末における操作により指定された商品を、前記端末を利用している客による購入対象の商品として登録する登録手段と、前記登録手段により登録された前記商品の代金を前記客に決済させるための決済処理を行う決済手段と、を備えた取引処理システムで用いられ、
前記登録手段により前記購入対象として登録できなかった商品が有る場合に、前記端末における操作により指定されるデータを取得する取得手段と、
前記取得手段により取得された前記データが予め定められた解除データである場合に、前記決済手段による前記決済処理の開始を許容する制御手段と、
を具備した取引支援装置。
[付記6] 端末における操作により指定された商品を、前記端末を利用している客による購入対象の商品として登録する登録手段と、前記登録手段により登録された前記商品の代金を前記客に決済させるための決済処理を行う決済手段と、を備えた取引処理システムで用いられる取引支援装置に設けられているコンピュータを、
前記登録手段により前記購入対象として登録できなかった商品が有る場合に、前記端末における操作により指定されるデータを取得する取得手段と、
前記取得手段により取得された前記データが予め定められた解除データである場合に、前記決済手段による前記決済処理の開始を許容する制御手段と、
して機能させるための情報処理プログラム。

Claims (6)

  1. 端末における操作により指定された商品を、前記端末を利用している客による購入対象の商品として登録する登録手段と、
    前記登録手段により登録された前記商品の代金を前記客に決済させるための決済処理を行う決済手段と、
    前記登録手段により前記購入対象として登録できなかった商品が有る場合に、前記端末における操作により指定されるデータを取得する取得手段と、
    前記取得手段により取得された前記データが予め定められた解除データである場合に、前記決済手段による前記決済処理の開始を許容する制御手段と、
    を具備した取引処理システム。
  2. 前記制御手段は、前記取得手段により取得された前記データと認証データとが予め定められた関係にある場合に、前記取得手段により取得された前記データが前記解除データであると判定する、
    請求項1に記載の取引処理システム。
  3. 前記制御手段は、前記客の入店時に前記端末を介して取得された認証データを用いる、請求項2に記載の取引処理システム。
  4. 前記取得手段は、前記端末で読み取られたバーコードが表すバーコードデータを前記データとして取得する、
    請求項1~請求項3のいずれか一項に記載の取引処理システム。
  5. 端末における操作により指定された商品を、前記端末を利用している客による購入対象の商品として登録する登録手段と、前記登録手段により登録された前記商品の代金を前記客に決済させるための決済処理を行う決済手段と、を備えた取引処理システムで用いられ、
    前記登録手段により前記購入対象として登録できなかった商品が有る場合に、前記端末における操作により指定されるデータを取得する取得手段と、
    前記取得手段により取得された前記データが予め定められた解除データである場合に、前記決済手段による前記決済処理の開始を許容する制御手段と、
    を具備した取引支援装置。
  6. 端末における操作により指定された商品を、前記端末を利用している客による購入対象の商品として登録する登録手段と、前記登録手段により登録された前記商品の代金を前記客に決済させるための決済処理を行う決済手段と、を備えた取引処理システムで用いられる取引支援装置に設けられているコンピュータを、
    前記登録手段により前記購入対象として登録できなかった商品が有る場合に、前記端末における操作により指定されるデータを取得する取得手段と、
    前記取得手段により取得された前記データが予め定められた解除データである場合に、前記決済手段による前記決済処理の開始を許容する制御手段と、
    して機能させるための情報処理プログラム。


JP2023143053A 2020-02-07 2023-09-04 取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラム Pending JP2023160917A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023143053A JP2023160917A (ja) 2020-02-07 2023-09-04 取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2020019350A JP6952144B2 (ja) 2020-02-07 2020-02-07 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法
JP2021156829A JP2022000800A (ja) 2020-02-07 2021-09-27 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法
JP2023143053A JP2023160917A (ja) 2020-02-07 2023-09-04 取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2021156829A Division JP2022000800A (ja) 2020-02-07 2021-09-27 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法

Publications (1)

Publication Number Publication Date
JP2023160917A true JP2023160917A (ja) 2023-11-02

Family

ID=77459590

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2020019350A Active JP6952144B2 (ja) 2020-02-07 2020-02-07 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法
JP2021156829A Pending JP2022000800A (ja) 2020-02-07 2021-09-27 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法
JP2023143053A Pending JP2023160917A (ja) 2020-02-07 2023-09-04 取引処理システム、端末装置、店舗システム、取引支援装置及び情報処理プログラム

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2020019350A Active JP6952144B2 (ja) 2020-02-07 2020-02-07 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法
JP2021156829A Pending JP2022000800A (ja) 2020-02-07 2021-09-27 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法

Country Status (1)

Country Link
JP (3) JP6952144B2 (ja)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008257429A (ja) * 2007-04-04 2008-10-23 Toshiba Tec Corp 商品販売データ処理装置
JP5531511B2 (ja) * 2009-08-31 2014-06-25 株式会社寺岡精工 携帯端末およびposシステム
JP5294332B2 (ja) * 2009-12-24 2013-09-18 Necインフロンティア株式会社 接客システム
JP5614370B2 (ja) * 2011-05-23 2014-10-29 富士通株式会社 取引承認システム、および取引承認方法
JP2015114891A (ja) * 2013-12-12 2015-06-22 日本郵便株式会社 配送管理サーバ、配送管理方法及び配送管理プログラム
JP7130355B2 (ja) * 2017-03-06 2022-09-05 東芝テック株式会社 チェック装置、及びチェックプログラム
JP7163604B2 (ja) * 2018-03-22 2022-11-01 日本電気株式会社 精算システム、精算方法及びプログラム
JP7035888B2 (ja) * 2018-07-31 2022-03-15 豊田合成株式会社 エアバッグ

Also Published As

Publication number Publication date
JP2022000800A (ja) 2022-01-04
JP2021125061A (ja) 2021-08-30
JP6952144B2 (ja) 2021-10-20

Similar Documents

Publication Publication Date Title
JP2024097969A (ja) 取引処理システム、携帯端末及び情報処理プログラム
JP7534080B2 (ja) 取引処理システム
JP2024019619A (ja) 情報処理装置及び情報処理プログラム
JP2023029402A (ja) 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法
JP6952144B2 (ja) 取引処理システム、取引支援装置、情報処理プログラム及び取引処理方法
JP7348257B2 (ja) 情報処理装置
JP7368573B2 (ja) 取引処理システム、制御装置及び情報処理プログラム
JP7478768B2 (ja) 取引処理システム
JP7148703B2 (ja) 取引処理システム、制御装置及び情報処理プログラム
JP6993443B2 (ja) 取引処理システム、制御装置及び情報処理プログラム
WO2022050383A1 (ja) 取引処理装置、取引処理方法及びプログラム記録媒体
JP7475961B2 (ja) 取引処理システム
US20230096680A1 (en) Information processing device and information processing method
JP2021096626A (ja) 情報処理装置及びその制御プログラム
US20210182819A1 (en) Transaction processing system
JP2022139573A (ja) 商品販売処理システム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230904

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230904

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240618

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240808

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240903