JP6789435B1 - 決済端末、決済方法、およびプログラム - Google Patents

Abstract

【課題】従来、商品の販売の際の決済において、商品識別情報の読み忘れ、または同一商品の商品識別情報の複数回の読み取り等のトラブルが発生し得る状況であった。【解決手段】商品を識別する商品識別情報を受け付ける第一受付部１２１と、商品の代金の支払いのための代金支払情報を受け付ける第二受付部１２２と、第一受付部１２１が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた場合に、エラー処理を行うエラー処理部１３３と、第一受付部１２１が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二受付部１２２が代金支払情報を受け付けた場合に、第一商品の販売のための決済処理を行う決済処理部１３２とを具備する決済端末１により、１商品ごとに１つの決済を行う決済端末により、商品の販売の際の決済のトラブルを防止できる。【選択図】図２

Description

本発明は、商品販売の際の決済を行う決済端末等に関するものである。

従来技術において、キャッシュレス決済を活用して商品を販売するオフィスコンビニサービスがあった（例えば、非特許文献１参照）。

また、従来、商品に貼付されたバーコードを探すといった煩雑な作業を顧客に強いることなく、迅速に購入商品を精算することが可能である、とするセルフレジシステムに関する技術が存在した（例えば、特許文献１参照）。

特開２０２０−１１９０３３号公報

"無?コンビニサービス「スマートマルシェ」"、［online］、SoftBank（登録商標）、［令和２年７月３０日検索］、インターネット［URL：https://www.softbank.jp/biz/iot/service/marche/］

しかしながら、従来技術においては、商品の販売の際の決済において、商品識別情報の読み取りの忘れ、または同一商品の商品識別情報の複数回の読み取り等のトラブルが発生し得る状況にあった。

また、従来技術においては、商品識別情報の読み取り時のトラブルをユーザが回避しようとするために、ユーザの商品確認の手間が発生したり、決済手段選択の手間が発生したりしていた。

さらに、従来技術においては、商品の販売の際の決済において、不特定多数のユーザが接触する画面を、ユーザがタッチする必要があることによる衛生面の心理的不安が、ユーザにとって大きな課題となっていた。

そのため、従来の決済端末において、高速かつ確実で衛生的なセルフレジ決済が困難であった。

本第一の発明の決済端末は、商品を識別する商品識別情報を受け付ける第一受付部と、商品の代金の支払いのための代金支払情報を受け付ける第二受付部と、第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた場合に、エラー処理を行うエラー処理部と、第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二受付部が代金支払情報を受け付けた場合に、第一商品の販売のための決済処理を行う決済処理部とを具備する決済端末である。

かかる構成により、１商品ごとに１つの決済を行う決済端末により、商品の販売の際の決済のトラブルを防止できる。その結果、高速かつ確実で衛生的なセルフレジ決済が実行できる。

また、本第二の発明の決済端末は、第一の発明に対して、第一受付部が第一商品識別情報を受け付ける前に、第二受付部が、代金支払情報を受け付けた場合には、代金支払情報に対応する残高データを取得する残高データ取得部と、残高データを出力する残高データ出力部をさらに具備する決済端末である。

かかる構成により、代金支払情報に対応する残高データを確認できる。

また、本第三の発明の決済端末は、第一または第二の発明に対して、第二受付部は、代金支払情報に代えて、または代金支払情報に加えて、第一商品の値引きをするクーポンを特定するクーポン情報を受け付けることが可能であり、決済処理部は、第二受付部がクーポン情報を受け付けた場合、クーポン情報に対応する値引きを行った価格の決済処理を行う決済端末である。

かかる構成により、一商品一決済を行い得る決済端末において、クーポンを使用できる。

また、本第四の発明の決済端末は、第一から第三いずれか１つの発明に対して、決済処理の対応する第一商品の売り上げに関する売上情報であり、第一商品識別情報を含む売上情報をサーバに送信する売上情報送信部をさらに具備する決済端末である。

かかる構成により、一商品一決済を行い得る決済端末における売上情報を、サーバで管理できる。

また、本第五の発明の決済端末は、第四の発明に対して、代金支払情報は、ユーザを識別するユーザ識別子を含み、第一受付部が受け付けた第一商品識別情報と、代金支払情報に含まれるユーザ識別子と、決済処理に対応する金額情報とを取得し、第一商品識別情報とユーザ識別子と金額情報とを有する売上情報を構成する売上情報構成部をさらに具備し、売上情報送信部は、売上情報構成部が構成した売上情報をサーバに送信する決済端末である。

かかる構成により、一商品一決済を行い得る決済端末における適切な売上情報を、サーバで管理できる。

本発明による決済端末によれば、１商品ごとに１つの決済を行う決済端末により、商品の販売の際の決済のトラブルを防止できる。その結果、高速かつ確実で衛生的なセルフレジ決済が実行できる。

実施の形態１における決済システムＡの概念図 同決済システムＡのブロック図 同決済端末１の動作例について説明するフローチャート 同決済端末１の動作例について説明するフローチャート 同サーバ２の動作例について、説明するフローチャート 同クーポン管理データベースを示す図

以下、決済端末等の実施形態について図面を参照して説明する。なお、実施の形態において同じ符号を付した構成要素は同様の動作を行うので、再度の説明を省略する場合がある。

（実施の形態１）
本実施の形態において、商品識別情報を受け付けた後、代金支払情報を受け付けた場合に、決済処理を行う決済端末について説明する。つまり、本実施の形態において、商品ごとに決済を行う一商品一決済を実現する決済端末について説明する。

また、本実施の形態において、第一商品識別情報を受け付けた後、続けて、第二商品識別情報を受け付けた場合、エラーとなる決済処理を行う決済端末について説明する。

また、本実施の形態において、第一商品識別情報を受け付ける前に、代金支払情報を受け付けた場合に、当該代金支払情報に対応する残高データを出力する決済端末について説明する。

また、本実施の形態において、第一商品識別情報を受け付けた後または第一商品識別情報を受け付ける前に、クーポン情報を受け付け可能な決済端末について説明する。

さらに、本実施の形態において、決済処理に対応する売上情報をサーバに送信する決済端末について説明する。

図１は、本実施の形態における決済システムＡの概念図である。決済システムＡは、１または２以上の決済端末１、およびサーバ２を備える。

決済端末１は、商品の販売の際に決済を行う場合に使用する端末である。決済端末１は、例えば、商品を販売する店舗に設置されている端末である。決済端末１は、例えば、セルフレジで使用される端末である。決済端末１は、例えば、決済のためにタップする必要のないタップレスの端末である。

サーバ２は、決済端末１から売上情報を受信し、管理する装置である。サーバ２は、例えば、決済端末１における決済の可否を判断する装置である。サーバ２は、例えば、決済端末１から送信されたクーポン情報に対応するクーポンが使用可能であるか否かを判断する装置である。サーバ２は、例えば、ＡＳＰのサーバ、クラウドサーバ等である。但し、サーバ２の種類は問わない。

決済端末１とサーバ２とは、インターネット、ＬＡＮ等のネットワークにより通信可能である。

図２は、本実施の形態における決済システムＡのブロック図である。

決済端末１は、格納部１１、受付部１２、処理部１３、送信部１４、および出力部１５を備える。受付部１２は、第一受付部１２１、および第二受付部１２２を備える。処理部１３は、判断部１３１、決済処理部１３２、エラー処理部１３３、残高データ取得部１３４、および売上情報構成部１３５を備える。送信部１４は、売上情報送信部１４１を備える。出力部１５は、残高データ出力部１５１を備える。

サーバ２は、サーバ格納部２１、サーバ受信部２２、サーバ処理部２３、およびサーバ送信部２４を備える。

決済端末１を構成する格納部１１には、各種の情報が格納される。各種の情報は、例えば、決済端末１を識別する端末識別子である。端末識別子は、例えば、ＩＤ、店舗名、ＩＰアドレス、ＭＡＣアドレス等である。各種の情報は、例えば、受付部１２が受け付けた情報である。

各種の情報は、例えば、優先順位情報である。優先順位情報は、支払手段の優先順位を特定する情報である。優先順位情報は、例えば、優先順位の順番に、支払手段の種類を示す２以上の支払手段種類識別子を有する。優先順位情報は、例えば、優先順位と対になる２以上の支払手段種類識別子を有する。なお、優先順位情報は、支払手段の優先順位を特定できる情報であれば良く、そのデータ構造は問わない。また、優先順位情報は、図示しない優先順位情報格納部に格納されていても良い。また、優先順位情報は、例えば、「交通系ＩＣ，Ｅｄｙ（登録商標），決済アプリ」「＜優先順位＞１＜支払手段種類識別子＞交通系ＩＣ，＜優先順位＞２＜支払手段種類識別子＞Ｅｄｙ，＜優先順位＞３＜支払手段種類識別子＞決済アプリ」である。

また、各種の情報とは、例えば、商品データベース、クーポン管理データベースである。なお、商品データベース、クーポン管理データベースは、サーバ２に存在していることは好適である。かかる場合、格納部１１には、通常、商品データベース、クーポン管理データベースは存在しない。

商品データベースは、商品に関する１または２以上のレコードを有する。商品データベースは、商品識別情報と価格情報とを有する１または２以上のレコードを有する。

クーポン管理データベースは、クーポンに関する情報である１または２以上のレコードを有する。クーポン管理データベースのレコードは、クーポンが使用可能な商品を特定する情報である。当該レコードは、例えば、クーポンを識別するクーポン識別情報と当該クーポンに対応する１または２以上の各商品の商品識別情報とを有する。当該レコードは、例えば、無料クーポンであるか否かを示す情報を有しても良い。また、当該レコードは、例えば、クーポンの価値を示す情報であるクーポン価値情報（例えば、割引価格、割引率）を有しても良い。

受付部１２は、各種の情報を受け付ける。各種の情報は、例えば、後述する商品識別情報や後述する代金支払情報や後述するクーポン情報である。各種の情報の受け付け手段は、近距離無線通信、ＩＣカードリーダー、二次元コードリーダー等が好適であるが、問わない。各種の情報の入力手段は、タッチパネルやキーボードやマウスやメニュー画面によるもの等でも良い。受付部１２は、例えば、近距離無線通信、ＩＣカードリーダー、または二次元コードリーダーで実現され得る。

第一受付部１２１は、商品を識別する商品識別情報を受け付ける。商品識別情報は、例えば、ＪＡＮコード、商品ＩＤである。ただし、商品識別情報は、販売対象の商品を識別できる情報であれば何でも良い。なお、商品は、例えば、飲料、食品等であるが、何でも良い。また、商品は、サービスを含んでも良い。商品識別情報は、例えば、バーコード、ＱＲコード（登録商標）、カラーコード等の二次元コードに埋め込まれていることは好適である。また、商品識別情報が埋め込まれた二次元コードは、当該商品識別情報で識別される商品の包装または商品の表面に表出していることは好適である。

第一受付部１２１は、例えば、コードリーダーにより実現される。第一受付部１２１は、例えば、バーコードリーダー、ＱＲコードリーダーにより実現される。

ここでの受け付けは、例えば、コードの読み取りであることは好適である。ただし、商品識別情報の受け付けは、キーボードやマウス、タッチパネルなどの入力デバイスから入力された情報の受け付け、有線もしくは無線の通信回線を介して送信された情報の受信、光ディスクや磁気ディスク、半導体メモリなどの記録媒体から読み出された情報の受け付けなどを含む概念であっても良い。

第二受付部１２２は、代金支払情報を受け付ける。代金支払情報は、商品の代金の支払いのための情報である。代金支払情報は、例えば、商品の代金の支払いに使用される支払手段の識別子を有する。代金支払情報は、例えば、ユーザ識別子を有する。ユーザ識別子は、例えば、ユーザＩＤ、氏名、電話番号、メールアドレス、ユーザの携帯端末のＩＤ、ユーザの携帯端末のＭＡＣアドレス等である。代金支払情報は、例えば、残高データを有する。残高データは、残高を示す情報である。商品の代金の支払手段は、例えば、ＩＣカード（特に、非接触ＩＣカードが好適である）、携帯端末、クレジットカード、二次元コード、決済アプリである。代金支払情報は、例えば、ＩＣカードの識別子、非接触ＩＣカードの識別子、携帯端末の識別子、クレジットカード番号、二次元コードに埋め込まれた識別子、決済アプリ（例えば、Ｐａｙｐａｙ（登録商標）、ａｕ ＰＡＹ（登録商標）等）の識別子である。携帯端末の識別子は、契約者固有ＩＤ、電話番号、メールアドレス、ＭＡＣアドレス、ＩＰアドレス等である。代金支払情報は、例えば、支払手段種類識別子を有する。支払手段種類識別子は、支払手段の識別子に埋め込まれていても良い。つまり、支払手段の識別子から支払手段種類識別子が取得可能でも良い。

第二受付部１２２は、２以上の代金支払情報を受け付けても良い。第二受付部１２２は、例えば、２以上の代金支払情報を、一緒に受け付けても良い。また、第二受付部１２２は、例えば、２以上の代金支払情報を、予め決められた条件を満たすほど短時間の間に受け付けても良い。

第二受付部１２２は、クーポン情報を受け付けても良い。第二受付部１２２は、代金支払情報に代えて、または代金支払情報に加えて、クーポン情報を受け付けても良い。クーポン情報は、第一商品の値引きをするクーポンを特定する情報である。値引きは、当該商品の一部の金額の値引きでも良いし、当該商品を無料とするものでも良い。クーポン情報は、例えば、クーポンを識別するクーポン識別情報を有する。クーポン情報は、例えば、ユーザ識別子を有する。

クーポン情報は、例えば、二次元コード、ＩＤである。ただし、クーポン情報のデータ構造等は問わない。

第二受付部１２２は、例えば、ＩＣカードリーダー（特に、非接触ＩＣカードが好適である）、コードリーダー、通信手段、近距離無線通信手段で実現される。

処理部１３は、各種の処理を行う。各種の処理とは、例えば、判断部１３１、決済処理部１３２、エラー処理部１３３、残高データ取得部１３４、売上情報構成部１３５が行う処理である。

処理部１３は、例えば、第二受付部１２２が２以上の代金支払情報を受け付けた場合に、優先順位情報格納部に格納されている優先順位情報を参照し、受け付けられた２以上の代金支払情報の中で、優先順位が最も高い支払手段に対応する代金支払情報を決定する。

さらに具体的には、処理部１３は、例えば、第二受付部１２２が２以上の代金支払情報を受け付けた場合に、２以上の各代金支払情報を用いて支払手段種類識別子を取得する。次に、
処理部１３は、優先順位情報格納部に格納されている優先順位情報を参照し、２以上の支払手段種類識別子のうち、最も優先順位の高い支払手段種類識別子を決定する。次に、処理部１３は、当該支払手段種類識別子に対応する代金支払情報を決定する。

なお、かかる代金支払情報を決定する処理は、図示しない決定部が行っても良い。また、決定部が決定した代金支払情報を用いて、後述する決済処理部１３２が後述する決済処理を行う。

判断部１３１は、各種の判断処理を行う。判断部１３１は、例えば、後述する第一判断、後述する第二判断、後述する第三判断、後述する第四判断を行う。
（１）第一判断について

判断部１３１は、例えば、第一受付部１２１が商品識別情報を受け付けた場合に、既に、未決済の商品識別情報が受け付けられているか否かを判断する。つまり、判断部１３１は、例えば、第一受付部１２１が商品識別情報を受け付けた場合に、未決済の商品の商品識別情報が格納部１１に格納されているか否かを判断する。かかる第一判断は、一商品一決済のために必要である。
（２）第二判断について

判断部１３１は、例えば、第二受付部１２２が代金支払情報を受け付けた場合に、既に、商品識別情報を受け付けているか否かを判断する。つまり、判断部１３１は、例えば、第二受付部１２２が代金支払情報を受け付けた場合に、受け付けられた未決済の商品の商品識別情報が格納部１１に格納されているか否かを判断する。

判断部１３１は、例えば、第二受付部１２２がクーポン情報を受け付けた場合に、既に、商品識別情報を受け付けているか否かを判断する。つまり、判断部１３１は、例えば、第二受付部１２２がクーポン情報を受け付けた場合に、受け付けられた未決済の商品の商品識別情報が格納部１１に格納されているか否かを判断する。
（３）第三判断について

判断部１３１は、例えば、第二受付部１２２が代金支払情報を受け付けた場合に、当該代金支払情報を用いて、第一受付部１２１が受け付けた商品識別情報で識別される商品の決済が可能であるか否かを判断する。

つまり、判断部１３１は、例えば、第二受付部１２２が受け付けた代金支払情報が正当な情報であるか否かを判断する。判断部１３１は、例えば、代金支払情報を図示しない外部サーバに送信し、当該代金支払情報が正当であるか否かの判断結果を受信する。判断部１３１は、例えば、代金支払情報を図示しないサーバ２に送信し、当該代金支払情報が正当であるか否かの判断結果をサーバ２から受信する。

また、判断部１３１は、例えば、第二受付部１２２が受け付けた代金支払情報に対応する残高データを取得する。また、判断部１３１は、例えば、第一受付部１２１が受け付けた商品識別情報と対になる価格情報を取得する。そして、判断部１３１は、例えば、「取得した残高データ＞＝取得した価格情報」であるか否か（決済可能であるか否か）を判断する。

なお、残高データは、例えば、後述する残高データ取得部１３４が取得した情報である。また、判断部１３１は、例えば、格納部１１の商品データベースから第一受付部１２１が受け付けた商品識別情報と対になる価格情報を取得しても良いし、第一受付部１２１が受け付けた商品識別情報をキーとして、サーバ２を検索し、商品識別情報と対になる価格情報を取得しても良い。

判断部１３１は、例えば、第二受付部１２２がクーポン情報を受け付けた場合に、当該クーポン情報を用いて、第一受付部１２１が受け付けた商品識別情報で識別される商品の決済を完了できるか否かを判断する。さらに具体的には、判断部１３１は、例えば、第二受付部１２２がクーポン情報を受け付けた場合に、当該クーポン情報が、第一受付部１２１が受け付けた商品識別情報で識別される商品の無料のクーポンの情報であるか否かを判断する。そして、無料のクーポンの情報であれば、判断部１３１は、決済を完了できると判断する。

なお、判断部１３１は、例えば、格納部１１またはサーバ２に、第二受付部１２２が受け付けたクーポン情報と第一受付部１２１が受け付けた商品識別情報とを対応付ける情報が格納されているか否かを判断する。

判断部１３１は、例えば、受け付けられた代金支払情報とクーポン情報と商品識別情報とを用いて、クーポン情報に対応する割引額または割引率と商品識別情報と対になる価格情報とから、ユーザが負担する価格情報を取得する。また、残高データ取得部１３４は、受け付けられた代金支払情報と対になる残高データを取得する。そして、判断部１３１は、例えば、「残高データ＞＝ユーザが負担する価格情報」であるか否かを判断する。そして、判断部１３１は、「残高データ＞＝ユーザが負担する価格情報」を満たす場合に、商品の決済を完了できる、と判断する。

判断部１３１は、例えば、受け付けられた代金支払情報と商品識別情報とをサーバ２に送信し、サーバ２から商品識別情報で識別される商品の決済が可能であるか否かを示す判断結果を受信しても良い。

判断部１３１は、例えば、受け付けられた商品識別情報とクーポン情報とをサーバ２に送信し、サーバ２から商品識別情報で識別される商品の決済が可能であるか否かを示す判断結果を受信しても良い。

判断部１３１は、例えば、受け付けられた代金支払情報と商品識別情報とクーポン情報とをサーバ２に送信し、サーバ２から商品識別情報で識別される商品の決済が可能であるか否かを示す判断結果を受信しても良い。

つまり、商品の決済が可能であるか否かの判断結果は、サーバ２が判断した情報でも良いし、決済端末１が判断した情報でも良い。
（４）第四判断について

判断部１３１は、例えば、第二受付部１２２がクーポン情報を受け付けた場合に、当該クーポン情報が、第一受付部１２１が受け付けた商品識別情報で識別される商品の決済に利用できるか否かを判断する。判断部１３１は、例えば、クーポン管理データベースの中に、第二受付部１２２が受け付けたクーポン情報に対応付けて、第一受付部１２１が受け付けた商品識別情報が格納されているか否かを判断する。

判断部１３１は、例えば、第二受付部１２２がクーポン情報をサーバ２に送信し、当該クーポン情報が受け付けられている商品識別情報で識別される商品の決済に利用できるか否かを示す判断結果をサーバ２から受信しても良い。

決済処理部１３２は、第一受付部１２１が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二受付部１２２が代金支払情報を受け付けた場合に、第一商品の販売のための決済処理を行う。

決済処理部１３２は、第二受付部１２２がクーポン情報を受け付けた場合、クーポン情報に対応する値引きを行った価格の決済処理を行う。決済処理部１３２は、第二受付部１２２が無料クーポンに対応するクーポン情報を受け付けた場合、無料で商品を引き渡すための処理である決済処理を行う。

決済処理部１３２は、判断部１３１が決済可能であると判断した場合に、決済処理を行うことは好適である。

なお、決済処理とは、ユーザが商品の代金を支払うための処理である。決済処理は、例えば、代金支払情報に対応する残高データから、第一商品の価格情報を減額する処理である。決済処理は、例えば、サーバ２に決済情報を送信する処理である。なお、決済処理は、決済に関連する処理であれば良い。

クーポン情報に対応する値引きに関するクーポン価値情報は、決済端末１の格納部１１に格納されていても良いし、サーバ２に格納されていても良い。

エラー処理部１３３は、判断部１３１のおける第一判断または第二判断または第三判断または第四判断における判断結果が不当（エラー）である場合に、当該判断に対応するエラー処理を行う。

エラー処理は、例えば、ブザーの出力、エラーの旨の表示、エラーの旨の内容の出力、受け付けた商品識別情報のキャンセルなどである。エラー処理は、例えば、既に受け付けられている商品識別情報または代金支払情報であり、格納部１１に格納されている商品識別情報または代金支払情報を削除することである。なお、エラー処理の内容は問わない。

エラー処理部１３３は、例えば、第一受付部１２１が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた場合に、エラー処理を行う。なお、ここで、第一商品と第二商品とは、異なる種類の商品であっても、同じ種類の商品であっても良い。また、かかるエラー処理は、第一エラー処理という。第一エラー処理は、判断部１３１における第一判断に対応するエラー処理である。

ここで、「引き続いて」とは、時間間隔が閾値以内であることは好適であるが、時間間隔は問わなくても良い。「第一商品識別情報を受け付けた後に、引き続いて、第二商品識別情報を受け付ける」ことは、通常、第一商品識別情報と第二商品識別情報の受け付けの間に、他の情報が受け付けられていないことである。

エラー処理部１３３は、例えば、第二受付部１２２が受け付けた代金支払情報を用いた商品の決済が可能でないと判断された場合に、第二エラー処理を行う。第二エラー処理は、例えば、決済できない旨のエラーメッセージの出力、残高が足りない旨のエラーメッセージの出力である。なお、第二エラー処理は、判断部１３１における第三判断に対応するエラー処理である。

エラー処理部１３３は、例えば、第二受付部１２２が受け付けたクーポン情報が、第一受付部１２１が受け付けた商品識別情報で識別される商品の決済に利用できない場合に、第三エラー処理を行う。第三エラー処理は、例えば、クーポン情報に対応するクーポンが使用できない旨の出力である。なお、第二エラー処理は、判断部１３１における第四判断に対応するエラー処理である。

エラー処理部１３３は、例えば、第二受付部１２２がクーポン情報を受け付けた際に、未決済の商品識別情報が格納部１１に存在しない場合に、第四エラー処理を行う。第四エラー処理は、例えば、購入する商品のコードを読み込ませることを促す情報の出力である。

残高データ取得部１３４は、第二受付部１２２が受け付けた代金支払情報に対応する残高データを取得する。

残高データ取得部１３４は、例えば、第一受付部１２１が第一商品識別情報を受け付ける前に、第二受付部１２２が代金支払情報を受け付けた場合に、当該代金支払情報に対応する残高データを取得する。

残高データ取得部１３４は、例えば、第二受付部１２２が受け付けた代金支払情報が格納されているＩＣカードから残高データを取得する。残高データ取得部１３４は、例えば、第二受付部１２２が受け付けた代金支払情報をキーとして、図示しない外部サーバを検索し、残高データを取得する。残高データ取得部１３４は、例えば、受け付けられた代金支払情報をサーバ２に送信し、当該外部サーバから当該代金支払情報に対応する残高データを当該サーバ２から受信する。

売上情報構成部１３５は、第一受付部１２１が受け付けた第一商品識別情報と、代金支払情報またはクーポン情報に含まれるユーザ識別子と、決済処理に対応する金額情報とを取得し、第一商品識別情報とユーザ識別子と金額情報とを有する売上情報を構成する。金額情報は、通常、ユーザが負担した金額を特定する情報であるが、商品の価格情報でも良い。

代金支払情報またはクーポン情報は、ユーザを識別するユーザ識別子を含むことは好適である。

送信部１４は、各種の情報を送付する。各種の情報は、例えば、売上情報構成部１３５が構成した売上情報である。

売上情報送信部１４１は、売上情報をサーバ２に送信する。売上情報は、売上情報構成部１３５が構成した情報である。売上情報は、決済処理の対応する商品の売り上げに関する情報である。売上情報は、通常、商品識別情報を含む。

出力部１５は、各種の情報を出力する。各種の情報は、例えば、残高データ取得部１３４が取得した残高データである。

ここで、出力とは、ディスプレイへの表示、プロジェクターを用いた投影、プリンタでの印字、音出力、外部の装置への送信、記録媒体への蓄積、他の処理装置や他のプログラムなどへの処理結果の引渡しなどを含む概念である。

残高データ出力部１５１は、残高データ取得部１３４が取得した残高データを出力する。ここで、残高データの出力は、通常、ディスプレイへの表示であるが、音声出力や端末への送信等でも良い。

サーバ２を構成するサーバ格納部２１には、各種の情報が格納される。各種の情報とは、例えば、商品データベース、クーポン管理データベース、売上データベースである。

商品データベース、クーポン管理データベースについては、上述したので、ここでの説明は省略する。

売上データベースは、売上情報を管理するデータベースである。売上データベースの売上情報は、例えば、端末識別子と対になっていることが好適である。

サーバ受信部２２は、各種の情報を受信する。サーバ受信部２２は、例えば、決済端末１から各種の情報を受信する。各種の情報は、例えば、売上情報、商品識別情報、代金支払情報、クーポン情報である。

サーバ処理部２３は、各種の処理を行う。各種の処理は、例えば、決済可否判断、クーポン使用可否判断、クーポン価値判断、代金支払情報判断、売上情報蓄積処理、売上情報統計処理である。

決済可否判断とは、決済端末１から受信された代金支払情報と商品識別情報とを用いて、当該商品識別情報で識別される商品の決済が可能であるか否かを判断する処理である。

サーバ処理部２３は、例えば、受信された代金支払情報が支払いの媒体として使用可能であるか否かを、図示しない外部サーバに問合せ、その結果（使用可能、または使用不可）を受信する。

サーバ処理部２３は、例えば、商品識別情報と対になる価格情報をサーバ格納部２１の商品データベースから取得する。また、サーバ処理部２３は、例えば、受信された代金支払情報をキーとして図示しない外部サーバから残高データを取得する。次に、サーバ処理部２３は、例えば、「残高データ＞＝価格情報」であるか否か（支払可能であるか否か）を判断し、決済可能であるか否かを示す判断結果を取得する。

サーバ処理部２３は、例えば、受信された商品識別情報、代金支払情報、クーポン情報を用いて、決済可能であるか否かを判断する。サーバ処理部２３は、例えば、商品識別情報と対になる価格情報をサーバ格納部２１の商品データベースから取得する。また、サーバ処理部２３は、例えば、受信された代金支払情報をキーとして図示しない外部サーバから残高データを取得する。また、サーバ処理部２３は、例えば、受信されたクーポン情報に対応する価値を、サーバ格納部２１のクーポン管理データベースから取得する。そして、サーバ処理部２３は、例えば、クーポン情報に対応する価値（例えば、割引価格、割引率）と価格情報とから、ユーザが支払うべき金額情報を取得する。次に、サーバ処理部２３は、例えば、「残高データ＞＝金額情報」であるか否かを判断し、決済可能であるか否かを示す判断結果を取得する。

クーポン使用可否判断は、例えば、受信されたクーポン情報を用いて、当該クーポン情報により特定されるクーポンが使用可能であるか否かを判断する処理である。クーポン使用可否判断は、例えば、受信されたクーポン情報と商品識別情報とを用いて、当該クーポン情報により特定されるクーポンが、当該商品識別情報により識別される商品に使用可能であるか否かを判断する処理である。

クーポン価値判断とは、例えば、受信されたクーポン情報により特定されるクーポンが、商品が無料になるクーポンであるか否かを判断する処理である。クーポン価値判断とは、例えば、受信されたクーポン情報により特定されるクーポンの価値（例えば、割引価格、割引率）を取得する処理である。

代金支払情報判断とは、代金支払情報が正当であるか否かの判断である。サーバ処理部２３は、受信された代金支払情報をキーとして図示しない外部サーバを検索し、代金支払情報が正当であるか否かの情報を外部サーバから受信する。

売上情報蓄積処理とは、受信された売上情報をサーバ格納部２１に蓄積する処理である。

売上情報統計処理とは、２以上の売上情報に対する統計処理である。統計処理の内容は問わない。売上情報統計処理は、例えば、商品識別情報ごとの売上数、売上の総金額を算出する処理である。売上情報統計処理は、例えば、商品の属性値ごとに、売上数、売上の総金額を算出する処理である。かかる場合、商品データベースには、商品識別情報に対応する商品の属性値が管理されている。売上情報統計処理は、例えば、全商品の売上数、売上の総金額を算出する処理である。

サーバ送信部２４は、各種の情報を決済端末１に送信する。各種の情報は、例えば、サーバ処理部２３が取得した決済可能であるか否かを示す判断結果、クーポン情報が使用可能であるか否かを示す判断結果、残高が足りているか否かを示す判断結果である。

格納部１１、およびサーバ格納部２１は、不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。

格納部１１等に情報が記憶される過程は問わない。例えば、記録媒体を介して情報が格納部１１等で記憶されるようになってもよく、通信回線等を介して送信された情報が格納部１１等で記憶されるようになってもよく、あるいは、入力デバイスを介して入力された情報が格納部１１等で記憶されるようになってもよい。

受付部１２、第一受付部１２１、および第二受付部１２２は、例えば、コードリーダー、ＩＣカードリーダー、通信手段、または近距離無線通信手段等で実現される。

処理部１３、判断部１３１、決済処理部１３２、エラー処理部１３３、残高データ取得部１３４、売上情報構成部１３５、およびサーバ処理部２３は、通常、プロセッサやメモリ等から実現され得る。処理部１３の処理手順は、通常、ソフトウェアで実現され、当該ソフトウェアはＲＯＭ等の記録媒体に記録されている。但し、ハードウェア（専用回路）で実現しても良い。なお、プロセッサは、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵであるが、その種類は問わない。

送信部１４、売上情報送信部１４１、およびサーバ送信部２４は、通常、無線または有線の通信手段で実現されるが、放送手段で実現されても良い。

出力部１５、および残高データ出力部１５１は、ディスプレイやスピーカー等の出力デバイスを含むと考えても含まないと考えても良い。出力部１５等は、出力デバイスのドライバーソフトまたは、出力デバイスのドライバーソフトと出力デバイス等で実現され得る。

サーバ受信部２２は、通常、無線または有線の通信手段で実現されるが、放送を受信する手段で実現されても良い。

次に、決済システムＡの動作例について説明する。まず、決済端末１の動作例について、図３、図４のフローチャートを用いて説明する。

（ステップＳ３０１）第一受付部１２１は、商品識別情報を受け付けたか否かを判断する。商品識別情報を受け付けた場合はステップＳ３０２に行き、商品識別情報を受け付けなかった場合はステップＳ３０５に行く。なお、例えば、商品に表出している二次元コードを、ユーザがコードリーダーに読ませることにより、第一受付部１２１は商品識別情報を受け付ける。

（ステップＳ３０２）判断部１３１は、未決済の商品の商品識別情報が格納部１１に格納されているか否かを判断する。格納されている場合はステップＳ３０３に行き、格納されていない場合はステップＳ３０４に行く。

（ステップＳ３０３）判断部１３１は、ステップＳ３０１で受け付けられた商品識別情報を格納部１１に蓄積する。ステップＳ３０１に戻る。なお、この商品識別情報は、未決済の商品の商品識別情報である。

（ステップＳ３０４）エラー処理部１３３は、第一エラー処理を行う。つまり、エラー処理部１３３は、「第一受付部１２１が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた」ことに対応するエラー処理を行う。ステップＳ３０１に戻る。

なお、エラー処理部１３３は、例えば、２つ目の商品の商品識別情報が受け付けられたエラーである旨のメッセージを出力する。また、エラー処理部１３３は、例えば、代金支払情報の受け付けを促す情報を出力する。なお、かかる出力されるエラーの情報は、格納部１１に格納されている。

（ステップＳ３０５）第二受付部１２２は、代金支払情報を受け付けたか否かを判断する。代金支払情報を受け付けた場合はステップＳ３０６に行き、代金支払情報を受け付けなかった場合はステップＳ３１９に行く。

なお、例えば、ユーザが、非接触ＩＣカードを第二受付部１２２のカードリーダーにかざすことにより、第二受付部１２２は代金支払情報を受け付ける。また、例えば、ユーザが、当該ユーザの携帯端末と第二受付部１２２とが通信することにより、第二受付部１２２は代金支払情報を受け付ける。その他、代金支払情報の受け付け方法は問わない。

（ステップＳ３０６）判断部１３１は、未決済の商品の商品識別情報が格納部１１に存在するか否かを判断する。商品識別情報が存在する場合にはステップＳ３０７に行き、商品識別情報が存在しない場合にはステップＳ３１７に行く。

（ステップＳ３０７）判断部１３１は、商品識別情報と代金支払情報とを用いて、決済可能であるか否かを判断する。

判断部１３１は、例えば、サーバ２に商品識別情報と代金支払情報とを送信し、決済可能であるか否かを示す判断結果を受信する。判断部１３１は、例えば、「商品識別情報に対応する価格情報＜＝代金支払情報に含まれる残高データ」であるか否かを示す判断結果を取得する。

（ステップＳ３０８）ステップＳ３０７における判断結果が、決済可能であるとの場合はステップＳ３０９に行き、決済可能でないとの場合はステップＳ３１６に行く。

（ステップＳ３０９）決済処理部１３２は、決済を行うための金額情報を取得する。金額情報は、例えば、商品識別情報と対になる価格情報である。金額情報は、例えば、商品識別情報と対になる価格情報からクーポン情報に対応する減額分を引いた金額である。

（ステップＳ３１０）決済処理部１３２は、ステップＳ３０９で取得された金額情報を用いて決済処理を行う。

（ステップＳ３１１）決済処理部１３２は、商品識別情報を格納部１１から削除する。なお、ここでの削除の処理は、決済完了を示すフラグを商品識別情報に対応付けて付加する処理でも良い。かかる付加する処理は、削除フラグを付加する処理と同様である。

（ステップＳ３１２）売上情報構成部１３５は、商品識別情報、ステップＳ３０９で取得された金額情報を有する売上情報を取得する。

（ステップＳ３１３）売上情報送信部１４１は、ステップＳ３１２で取得された売上情報をサーバ２に送信する。

（ステップＳ３１４）判断部１３１は、ステップＳ３１０における決済処理において、クーポン情報が使用されたか否かを判断する。クーポン情報が使用された場合はステップＳ３１５に行き、クーポン情報が使用されなかった場合はステップＳ３０１に戻る。なお、クーポン情報が使用されたか否かは、例えば、受け付けられたクーポン情報が格納部１１に存在するか否かにより判断され得る。

（ステップＳ３１５）処理部１３は、受け付けられたクーポン情報に対応する処理を行う。ステップＳ３０１に戻る。かかる処理は、当該クーポン情報を再使用させないための無効化の処理である。また、かかる処理は、例えば、当該クーポン情報を含む無効化情報をサーバ２に送信する処理である。また、かかる処理は、例えば、当該クーポン情報を格納部１１から削除する処理である。なお、ステップＳ３１５における処理は、当該クーポン情報を再使用させないための無効化の処理であれば何でも良い。

（ステップＳ３１６）エラー処理部１３３は、第二エラー処理を行う。つまり、エラー処理部１３３は、決済できない場合の処理を行う。ステップＳ３０１に戻る。なお、かかる処理は、例えば、決済できない旨のエラーメッセージの出力である。

（ステップＳ３１７）残高データ取得部１３４は、受け付けられた代金支払情報に対応する残高データを取得する。

（ステップＳ３１８）残高データ出力部１５１は、ステップＳ３１７で取得された残高データを出力する。ステップＳ３０１に戻る。

（ステップＳ３１９）第二受付部１２２は、クーポン情報を受け付けたか否かを判断する。クーポン情報を受け付けた場合はステップＳ３２０に行き、クーポン情報を受け付けなかった場合はステップＳ３０１に戻る。

（ステップＳ３２０）判断部１３１は、ステップＳ３１９で受け付けられたクーポン情報に対応するクーポンが使用可能であるか否かを判断する。使用可能である場合はステップＳ３２１に行き、使用可能でない場合はステップＳ３２７に行く。判断部１３１は、例えば、クーポン情報と商品識別情報とをサーバ２に送信し、クーポンが使用可能であるか否かの判断結果を受信する。

（ステップＳ３２１）判断部１３１は、未決済の商品の商品識別情報が格納部１１に存在するか否かを判断する。商品識別情報が存在する場合にはステップＳ３２２に行き、商品識別情報が存在しない場合にはステップＳ３２６に行く。

（ステップＳ３２２）判断部１３１は、ステップＳ３１９で受け付けられたクーポン情報が無料クーポンの情報であるか否かを判断する。無料クーポンの情報であればステップＳ３２３に行き、無料クーポンの情報でなければステップＳ３２５に行く。

（ステップＳ３２３）決済処理部１３２は、金額情報に０を代入する。ステップＳ３１０に行く。

（ステップＳ３２４）決済処理部１３２は、商品識別情報と対になる価格情報から、クーポン情報の分だけ減額した金額情報を取得する。

（ステップＳ３２５）エラー処理部１３３は、第四エラー処理を行う。ステップＳ３０１に戻る。なお、ここで、エラー処理部１３３は、例えば、クーポンを使用する商品が指定されていない旨のエラーメッセージを出力する。

（ステップＳ３２６）エラー処理部１３３は、第三エラー処理を行う。ステップＳ３０１に戻る。なお、ここで、エラー処理部１３３は、例えば、クーポン情報に対応するクーポンが使用できない旨のエラーメッセージを出力する。

なお、図４のフローチャートにおいて、ステップＳ３２３の直前または直後に、判断部１３１が、商品識別情報とクーポン情報と代金支払情報とを用いて、決済可能であるか否かを判断し、決済可能であれば、ステップＳ３１０に行くことは好適である。

また、図３、図４のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

次に、サーバ２の動作例について、図５のフローチャートを用いて説明する。

（ステップＳ５０１）サーバ受信部２２は、代金支払情報等を受信したか否かを判断する。代金支払情報等を受信した場合はステップＳ５０２に行き、代金支払情報等を受信しなかった場合はステップＳ５１０に行く。なお、代金支払情報等とは、例えば、代金支払情報と商品識別情報である。また、代金支払情報等とは、例えば、クーポン情報と商品識別情報である。また、代金支払情報等とは、例えば、代金支払情報とクーポン価値情報と商品識別情報である。

（ステップＳ５０２）サーバ処理部２３は、代金支払情報判断を行う。代金支払情報判断とは、代金支払情報が正当であるか否かを判断することである。

（ステップＳ５０３）ステップＳ５０２における判断の結果が「正当」であればステップＳ５０４に行き、「正当」でなければステップＳ５１０に行く。

（ステップＳ５０４）サーバ処理部２３は、ステップＳ５０１で受信された情報の中に、クーポン情報またはクーポン価値情報が存在するか否かを判断する。クーポン情報またはクーポン価値情報が存在する場合はステップＳ５０６に行き、クーポン情報またはクーポン価値情報が存在しない場合はステップＳ５０５に行く。

（ステップＳ５０５）サーバ処理部２３は、受信された商品識別情報と対になる価格情報を、商品データベースから取得する。ステップＳ５０７に行く。

（ステップＳ５０６）サーバ処理部２３は、受信された商品識別情報と対になる価格情報を、商品データベースから取得する。また、サーバ処理部２３は、クーポン情報に対応する割引額を、クーポン管理データベースを用いて取得する。サーバ処理部２３は、価格情報と割引額とを用いて、ユーザが負担する金額である金額情報を算出する。

（ステップＳ５０７）サーバ処理部２３は、代金支払情報に対応する残高データを取得する。サーバ処理部２３は、残高データと、価格情報または金額情報を用いて、決済可能であるか否かを判断する。

（ステップＳ５０８）サーバ処理部２３は、ステップＳ５０７における判断結果を取得する。

（ステップＳ５０９）サーバ送信部２４は、ステップＳ５０８で取得された判断結果を決済端末１に送信する。ステップＳ５０１に戻る。

（ステップＳ５１０）サーバ処理部２３は、変数「判断結果」に「代金支払情報が不当」である旨を代入する。ステップＳ５０９に行く。

（ステップＳ５１１）サーバ受信部２２は、クーポン情報等を受信したか否かを判断する。クーポン情報等を受信した場合はステップＳ５１２に行き、クーポン情報等を受信しなかった場合はステップＳ５１８に行く。

（ステップＳ５１２）サーバ処理部２３は、クーポン情報判断処理を行う。つまり、サーバ処理部２３は、クーポン情報が使用可能（正当）であるか否かを判断する。

（ステップＳ５１３）ステップＳ５１２における判断結果が「正当」であればステップＳ５１４に行き、「正当」でなければステップＳ５１７に行く。

（ステップＳ５１４）サーバ処理部２３は、クーポン情報に対応するクーポン価値情報をクーポン管理データベースから取得する。

（ステップＳ５１５）サーバ処理部２３は、変数「判断結果」に、ステップＳ５１４で取得したクーポン価値情報を代入する。

（ステップＳ５１６）サーバ送信部２４は、ステップＳ５０８で取得された判断結果を決済端末１に送信する。ステップＳ５０１に戻る。

（ステップＳ５１７）サーバ処理部２３は、変数「判断結果」に、クーポン情報が不当である旨を代入する。ステップＳ５１６に行く。

（ステップＳ５１８）サーバ受信部２２は、売上情報等を受信したか否かを判断する。売上情報等を受信した場合はステップＳ５１９に行き、売上情報等を受信しなかった場合はステップＳ５０１に戻る。

（ステップＳ５１９）サーバ処理部２３は、ステップＳ５１８で受信された売上情報をサーバ格納部２１に蓄積する。ステップＳ５０１に戻る。

なお、図５のフローチャートにおいて、サーバ処理部２３は、売上情報統計処理を行っても良い。また、売上情報統計処理を行うタイミングは問わない。

また、図５のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

以下、本実施の形態における決済システムＡの具体的な動作について説明する。決済システムＡの概念図は図１である。

今、決済端末１の格納部１１には、商品データベースが格納されている、とする。商品データベースは、商品識別情報と価格情報とを有する１以上のレコードを有する。価格情報は、商品識別情報で識別される商品の販売価格を示す情報である。

また、サーバ２のサーバ格納部２１には、図６に示すクーポン管理データベースが格納されている、とする。クーポン管理データベースは、「ＩＤ」「クーポン識別情報」「対象商品識別情報」「クーポン価値情報」「使用フラグ」を有する１以上のレコードを有する。「対象商品識別情報」は、対象となる商品の商品識別情報である。「使用フラグ」は、クーポンが既に使用された（「１」）か使用されていない（「０」）かを示す情報である。なお、図６の「Ｄ３＊＊」は正規表現であり、「＊」には任意の文字（ここでは、数字）が入る意味である。

かかる状況において、以下の３つの具体例について説明する。具体例１は、ユーザが、決済端末１に、２つの商品の二次元コードを連続して読み込ませた場合である。具体例２は、ユーザが、決済端末１に、一の商品の二次元コードを読み込ませ、引き続き、ユーザが保有する支払手段であるＩＣカードを決済端末１に読み込ませた場合である。具体例３は、ユーザが無料クーポンを用いて商品を得る場合である。

（具体例１）
ユーザが、缶コーヒー（図１の１０１）を購入するために、決済端末１のバーコードリーダーに、缶コーヒーのバーコードを読み込ませた、とする。なお、かかるバーコードには、商品識別情報「Ｄ２０３」が埋め込まれている、とする。

すると、決済端末１の第一受付部１２１は、商品識別情報「Ｄ２０３」を受け付ける。次に、判断部１３１は、未決済の商品の商品識別情報が格納部１１に格納されていない、と判断する。次に、判断部１３１は、受け付けられた商品識別情報「Ｄ２０３」を格納部１１に蓄積する。

次に、このユーザは、パンを購入するために、決済端末１のバーコードリーダーに、缶コーヒーのバーコードを読み込ませた、とする。なお、かかるバーコードには、商品識別情報「Ｄ３０１」が埋め込まれている、とする。

すると、決済端末１の第一受付部１２１は、商品識別情報「Ｄ３０１」を受け付ける。次に、判断部１３１は、未決済の商品の商品識別情報（ここでは「Ｄ３０１」）が格納部１１に格納されている、と判断する。

次に、エラー処理部１３３は、第一エラー処理を行う。つまり、エラー処理部１３３は、かかるエラーに対応するメッセージ「複数の商品を一度に決済できません。決済のためにＩＣカードをカードリーダーにかざして下さい。」を格納部１１から読み出し、出力する。

以上の処理により、複数の商品の商品識別情報を連続して読み込ませることを防止できる。

（具体例２）
具体例１の処理の後、当該ユーザは、保持している非接触ＩＣカード（残高５００円）を、ＩＣカードリーダーにかざした、とする。

すると、第二受付部１２２は、代金支払情報（ここでは、ＩＣカードのＩＤ「Ｃ００１」と残高データ「５００円」を有する）を受け付ける。

次に、判断部１３１は、未決済の商品の商品識別情報「Ｄ３０１」が格納部１１に存在する、と判断する。

次に、判断部１３１は、商品識別情報「Ｄ３０１」と対になる価格情報「１００円」を、格納部１１の商品データベースから取得する。次に、判断部１３１は、「残高データ「５００円」＞＝価格情報「１００円」」であるので、決済可能である、と判断する。

次に、決済処理部１３２は、決済を行うための金額情報「１００円」を取得する。そして、決済処理部１３２は、取得された金額情報「１００円」を用いて決済処理を行う。つまり、決済処理部１３２は、ユーザのＩＣカードの残高データを「５００円」から「１００円」減額するための処理（例えば、ＩＣカードのデータを「４００円」に書き換える処理）を行う。なお、かかる処理は、例えば、図示しない外部サーバまたはサーバ２に、ＩＣカードのＩＤ「Ｃ００１」と、金額情報「１００円」または残高データ「４００円」とを送信する処理でも良い。かかる処理により、ユーザのＩＣカードの残高が１００円減額されれば良い。

次に、決済処理部１３２は、商品識別情報「Ｄ３０１」を格納部１１から削除する。

次に、売上情報構成部１３５は、商品識別情報「Ｄ３０１」、金額情報「１００円」を有する売上情報を取得する。次に、売上情報構成部１３５は、格納部１１の端末識別子を取得する。そして、売上情報構成部１３５は、売上情報と端末識別子とを有する情報を構成する。
そして、売上情報送信部１４１は、取得された売上情報等をサーバ２に送信する。

次に、サーバ２のサーバ受信部２２は、売上情報（商品識別情報「Ｄ３０１」、金額情報「１００円」）と決済端末１の端末識別子とを有する情報を受信する。次に、サーバ処理部２３は、受信された売上情報を、端末識別子に対応付けてサーバ格納部２１に蓄積する。

以上の処理により、一商品一決済が実現できた。

（具体例３）
次に、ユーザは、ペットボトル（図１の１０３）を購入するために、決済端末１のバーコードリーダーに、ペットボトルのバーコードを読み込ませた、とする。なお、かかるバーコードには、商品識別情報「Ｄ１００」が埋め込まれている、とする。

すると、決済端末１の第一受付部１２１は、商品識別情報「Ｄ１００」を受け付ける。次に、判断部１３１は、未決済の商品の商品識別情報が格納部１１に格納されていない、と判断する。次に、判断部１３１は、受け付けられた商品識別情報「Ｄ１００」を格納部１１に蓄積する。

次に、ユーザは、無料クーポン（図１の１０４）を、決済端末１のＱＲコードリーダーに読み込ませた、とする。なお、かかるＱＲコードには、クーポン識別情報「Ｃ００１」が埋め込まれている、とする。

次に、第二受付部１２２は、クーポン識別情報「Ｃ００１」を有するクーポン情報を受け付ける。

次に、送信部１４は、クーポン識別情報「Ｃ００１」と商品識別情報「Ｄ１００」とをサーバ２に送信する。

次に、サーバ２のサーバ受信部２２は、クーポン識別情報「Ｃ００１」と商品識別情報「Ｄ１００」とを受信する。

次に、サーバ処理部２３は、図６を参照し、受信されたクーポン識別情報「Ｃ００１」と商品識別情報「Ｄ１００」とが対になるレコードがクーポン管理データベースに存在し、かつ使用フラグが「０」であるか否かを判断する。ここで、サーバ処理部２３は、クーポン識別情報「Ｃ００１」と商品識別情報「Ｄ１００」とが対になるレコードがクーポン管理データベースに存在し、かつ使用フラグが「０」である、と判断する。つまり、サーバ処理部２３は、当該クーポン情報が使用可能である、と判断する。

次に、サーバ処理部２３は、クーポン識別情報「Ｃ００１」と対になるクーポン価値情報「無料」をクーポン管理データベースから取得する。

次に、サーバ処理部２３は、変数「判断結果」にクーポン価値情報「無料」を代入する。

次に、サーバ送信部２４は、当該判断結果を決済端末１に送信する。

次に、決済端末１の判断部１３１は、クーポン価値情報「無料」を受信する。そして、判断部１３１は、当該クーポン情報に対応するクーポンが使用可能である、と判断する。

次に、判断部１３１は、未決済の商品の商品識別情報「Ｄ１００」が格納部１１に存在する、と判断する。

次に、判断部１３１は、受け付けられたクーポン情報が無料クーポンの情報である、と判断する。

次に、決済処理部１３２は、金額情報に０を代入する。

次に、決済端末１の決済処理部１３２は、取得された金額情報「０」を用いて決済処理を行う。

次に、決済処理部１３２は、商品識別情報「Ｄ１００」を格納部１１から削除する。

次に、売上情報構成部１３５は、商品識別情報「Ｄ１００」、金額情報「０」を有する売上情報を取得する。

次に、売上情報送信部１４１は、取得された売上情報をサーバ２に送信する。

次に、決済端末１の処理部１３は、クーポン識別情報「Ｃ００１」に対応するクーポン情報が使用不可となるように、クーポン識別情報「Ｃ００１」をサーバ２に送信する。

次に、サーバ２は、売上情報を受信し、蓄積する。また、サーバ２は、クーポン識別情報「Ｃ００１」を受信し、当該クーポン識別情報「Ｃ００１」と対になる使用フラグを「１」に書き換える。

以上により、無料クーポンを用いた処理が完了した。

以上、本実施の形態によれば、一商品一決済を行う決済端末１を提供できる。そして、かかる決済端末１により、商品の販売の際の決済のトラブルを防止できる。その結果、高速かつ確実で衛生的なセルフレジ決済が実行できる。

また、本実施の形態において、代金支払情報に対応する残高データを確認できる。

また、本実施の形態において、一商品一決済を行い得る決済端末１において、クーポンを使用できる。

さらに、本実施の形態において、一商品一決済を行い得る決済端末１における売上情報を、サーバで管理できる。

なお、本実施の形態における処理は、ソフトウェアで実現しても良い。そして、このソフトウェアをソフトウェアダウンロード等により配布しても良い。また、このソフトウェアをＣＤ−ＲＯＭなどの記録媒体に記録して流布しても良い。なお、このことは、本明細書における他の実施の形態においても該当する。なお、本実施の形態における決済端末１を実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、コンピュータを、商品を識別する商品識別情報を受け付ける第一受付部と、前記商品の代金の支払いのための代金支払情報を受け付ける第二受付部と、前記第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた場合に、エラー処理を行うエラー処理部と、前記第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、前記第二受付部が前記代金支払情報を受け付けた場合に、前記第一商品の販売のための決済処理を行う決済処理部として機能させるためのプログラムである。

なお、上記プログラムにおいて、情報を送信する送信ステップや、情報を受信する受信ステップなどでは、ハードウェアによって行われる処理、例えば、送信ステップにおけるモデムやインターフェースカードなどで行われる処理（ハードウェアでしか行われない処理）は含まれない。

また、上記プログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、あるいは分散処理を行ってもよい。

また、上記各実施の形態において、一の装置に存在する２以上の通信手段は、物理的に一の媒体で実現されても良いことは言うまでもない。

また、上記各実施の形態において、各処理（各機能）は、単一の装置（システム）によって集中処理されることによって実現されてもよく、あるいは、複数の装置によって分散処理されることによって実現されてもよい。

本発明は、以上の実施の形態に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

以上のように、本発明にかかる決済端末は、１商品ごとに１つの決済を行う決済端末により、商品の販売の際の決済のトラブルを防止できる、という効果を有し、セルフレジ等における決済端末として有用である。

１ 決済端末
２ サーバ
１１ 格納部
１２ 受付部
１３ 処理部
１４ 送信部
１５ 出力部
２１ サーバ格納部
２２ サーバ受信部
２３ サーバ処理部
２４ サーバ送信部
１２１ 第一受付部
１２２ 第二受付部
１３１ 判断部
１３２ 決済処理部
１３３ エラー処理部
１３４ 残高データ取得部
１３５ 売上情報構成部
１４１ 売上情報送信部
１５１ 残高データ出力部

Claims (7)

1. 商品を識別する商品識別情報を受け付ける第一受付部と、
   前記商品の代金の支払いのための代金支払情報を受け付ける第二受付部と、
   前記第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた場合に、エラー処理を行うエラー処理部と、
   前記第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、前記第二受付部が前記代金支払情報を受け付けた場合に、前記第一商品の販売のための決済処理を行う決済処理部とを具備する決済端末。
2. 前記第一受付部が前記第一商品識別情報を受け付ける前に、前記第二受付部が、前記代金支払情報を受け付けた場合には、当該代金支払情報に対応する残高データを取得する残高データ取得部と、
   当該残高データを出力する残高データ出力部をさらに具備する請求項１記載の決済端末。
3. 前記第二受付部は、
   前記代金支払情報に代えて、または前記代金支払情報に加えて、前記第一商品の値引きをするクーポンを特定するクーポン情報を受け付けることが可能であり、
   前記決済処理部は、
   前記第二受付部が前記クーポン情報を受け付けた場合、当該クーポン情報に対応する値引きを行った価格の決済処理を行う請求項１または請求項２記載の決済端末。
4. 前記決済処理の対応する前記第一商品の売り上げに関する売上情報であり、前記第一商品識別情報を含む売上情報をサーバに送信する売上情報送信部をさらに具備する請求項１から請求項３いずれか一項に記載の決済端末。
5. 前記代金支払情報は、ユーザを識別するユーザ識別子を含み、
   前記第一受付部が受け付けた第一商品識別情報と、前記代金支払情報に含まれるユーザ識別子と、前記決済処理に対応する金額情報とを取得し、当該第一商品識別情報と当該ユーザ識別子と当該金額情報とを有する売上情報を構成する売上情報構成部をさらに具備し、
   前記売上情報送信部は、
   前記売上情報構成部が構成した前記売上情報をサーバに送信する請求項４記載の決済端末。
6. 第一受付部と、第二受付部と、エラー処理部と、決済処理部とにより実現される決済方法であって、
   前記第一受付部が、商品を識別する商品識別情報を受け付ける第一受付ステップと、
   前記第二受付部が、前記商品の代金の支払いのための代金支払情報を受け付ける第二受付ステップと、
   前記エラー処理部が、前記第一受付ステップで第一商品を識別する第一商品識別情報が受け付けられた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた場合に、エラー処理を行うエラー処理ステップと、
   前記決済処理部が、前記第一受付ステップで第一商品を識別する第一商品識別情報を受け付けられた後に、引き続いて、前記第二受付ステップで前記代金支払情報が受け付けられた場合に、前記第一商品の販売のための決済処理を行う決済処理ステップとを具備する決済方法。
7. コンピュータを、
   商品を識別する商品識別情報を受け付ける第一受付部と、
   前記商品の代金の支払いのための代金支払情報を受け付ける第二受付部と、
   前記第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、第二商品を識別する第二商品識別情報を受け付けた場合に、エラー処理を行うエラー処理部と、
   前記第一受付部が第一商品を識別する第一商品識別情報を受け付けた後に、引き続いて、前記第二受付部が前記代金支払情報を受け付けた場合に、前記第一商品の販売のための決済処理を行う決済処理部として機能させるためのプログラム。