商品販売データ処理装置及びその制御プログラム
【課題】価値カード，チケット類などの有効化された状態の商品が代金未収のまま店側に残るのを未然に防止する。
【解決手段】ＰＯＳ端末は、入力された買上商品のデータに基づいて商品販売データを売上処理する。ＰＯＳ端末は、売上処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の証明データを記憶部で記憶する。ＰＯＳ端末は、記憶部で証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、記憶部で記憶している証明データをサーバに送信する。
【解決手段】ＰＯＳ端末は、入力された買上商品のデータに基づいて商品販売データを売上処理する。ＰＯＳ端末は、売上処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の証明データを記憶部で記憶する。ＰＯＳ端末は、記憶部で証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、記憶部で記憶している証明データをサーバに送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品、例えば価値カードや、コンサート，演劇等のチケット等を販売する店舗向けの商品販売データ処理装置及びその制御プログラムに関する。
【背景技術】
【０００２】
インターネットを利用して、音楽、電子書籍等のコンテンツや商品またはサービスを購入する際の代金支払い方法の一つに、プリペイド式の価値カードがある。この種の価値カードは、一般に、家電量販店やコンビニエンスストア等で販売されている。販売店の店員は、客から価値カード購入の申し出を受けると、予めストックされている未使用の価値カードに印刷されているバーコードを、ＰＯＳ（Point Of Sales）端末のスキャナで読み取る。バーコードは、その価値カードに対して一意に設定されたカードＩＤをバーコードシンボル化したものである。バーコードが読み取られると、そのバーコードデータ（カードＩＤ）がＰＯＳ端末からストアサーバを経由して、外部の価値カード管理サーバに送信される。
【０００３】
価値カード管理サーバは、管理対象の全ての価値カードのカードＩＤと対応させて、価値情報とステータス情報とを記憶したデータベースを備えている。ＰＯＳ端末で読み取られたバーコードデータ（カードＩＤ）を受信すると、価値カード管理サーバはデータベースを検索し、そのカードＩＤに対応するステータス情報を、無効の状態から有効の状態に切り替える。ステータス情報が有効の状態になると、当該カードＩＤで特定される価値カードが有効となり、価値情報に相当する金額までの代金支払いに供せられる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２０４４４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のＰＯＳ端末は、価値カードのカードＩＤが入力されると、そのカードを購入する客が代金を支払う前に、そのカードが正規に販売されたことの証明データ（カードＩＤ）をサーバに送信していた。このため、例えば財布を忘れた等の理由から客が代金の支払いを取り止めた場合、有効化された状態のカードが代金未収のまま店側に残るという問題が生じる。
【０００６】
このようなことは、インターネットを利用して客が事前にコンサートや演劇等の入場券であるチケットの購入権を獲得し、その代金をコンビニエンスストア等の店舗で支払うと、チケットを入手できるようなチケット販売形式の場合にも生じる。例えば、チケットの購入権を獲得していることを証明するデータが客から提示され、当該データを読み取ると当該チケットの発券を行ない、代金の支払いを求める。この場合、客が代金を支払う前にチケットが発券されるため、客が代金の支払いを取り止めた場合に、発券により有効となったチケットが代金未収のまま店側に残ってしまう。
【０００７】
本発明が解決しようとする課題は、代金の支払い受け前に商品を有効化することを防止できる商品販売データ処理装置及びその制御プログラムを提供しようとするものである。
【課題を解決するための手段】
【０００８】
かかる課題を解決するために、一実施形態の商品販売データ処理装置は、売上処理手段と、記憶部と、証明データ送信手段とを備える。売上処理手段は、入力された買上商品のデータに基づいて商品販売データを売上処理する。記憶部は、売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の証明データを記憶する。証明データ送信手段は、記憶部で証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、記憶部で記憶している証明データをサーバに送信する。
【図面の簡単な説明】
【０００９】
【図１】商品販売データ処理装置の第１の実施形態を示すシステム構成図。
【図２】同第１の実施形態で用いる価値カードを示す平面図。
【図３】同第１の実施形態において、価値カードデータベースに記憶されるデータの一例を示す図。
【図４】同第１の実施形態におけるＰＯＳ端末のハードウェア構成を示すブロック図。
【図５】同第１の実施形態において、ＰＯＳ端末のＲＡＭに形成される有効化メモリの構成図。
【図６】同第１の実施形態において、ＰＯＳ端末のＣＰＵが実行するスキャニング処理の要部手順を示す流れ図。
【図７】同第１の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【図８】商品販売データ処理装置の第２の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【図９】商品販売データ処理装置の第３の実施形態を示すシステム構成図。
【図１０】同第３の実施形態において、価値カードデータベースに記憶されるデータの一例を示す図。
【図１１】同第３の実施形態において、ＰＯＳ端末のＲＡＭに形成されるデータバッファの構成図。
【図１２】同第３の実施形態において、ＰＯＳ端末のＣＰＵが実行するスキャニング処理の要部手順を示す流れ図。
【図１３】同第３の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【図１４】商品販売データ処理装置の第４の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【発明を実施するための形態】
【００１０】
以下、商品販売データ処理装置の実施形態を、図面を用いて説明する。
【００１１】
［第１の実施形態］
はじめに、価値カードの販売店に適用する第１の実施形態について、図１〜図７を用いて説明する。図１は、第１の実施形態のシステム構成図である。本システムは、各店舗にそれぞれ構築されるＰＯＳシステム１と、価値カードデータベース２を管理する価値カード管理サーバ３とからなる。ＰＯＳシステム１は、商品販売データ処理装置として機能する複数台のＰＯＳ端末４と、各ＰＯＳ端末４を一元的に管理するストアサーバ５とからなり、各ＰＯＳ端末４とストアサーバ５とは、ＬＡＮ（Local Area Network）６によって接続されている。各店舗のＰＯＳシステム１のストアサーバ５と前記価値カード管理サーバ３とは、インターネット等のネットワーク回線７によって接続されている。
【００１２】
図２に示すように、本実施形態で使用される価値カード８には、バーコード９が印刷されている。バーコード９は、当該価値カード８を一意に識別するためのカードＩＤをバーコードシンボル化したものである。
【００１３】
価値カードデータベース２は、図３に示すように、各価値カード８のカードＩＤに対応させて、価値情報とステータスフラグとを記憶する。価値情報は、対応するカードＩＤによって特定される価値カード８で支払いが可能な金額である。ステータスフラグは、例えば“０”は無効状態を示し、“１”は有効状態を示す。なお、価値情報は、金額に限定されない。１ポイントあたりの金額を可変設定可能なポイントであってもよい。
【００１４】
図４は、ＰＯＳ端末４の要部構成を示すブロック図である。ＰＯＳ端末４は、制御部本体としてＣＰＵ（Central Processing Unit）１１を搭載している。そしてこのＣＰＵ１１に、アドレスバス，データバス等のバスライン１２を介して、ＲＯＭ（Read Only Memory）１３、ＲＡＭ（Random Access Memory）１４、時計部１５、ＬＡＮコントローラ１６、キーボードコントローラ１７、表示コントローラ１８、表示コントローラ１９、プリンタコントローラ２０、スキャナコントローラ２１等を接続して、ＰＯＳ端末４の制御回路を構成している。
【００１５】
ＲＯＭ１３は、ＣＰＵ１１にＰＯＳ端末４としての機能を実現させるためのプログラムを記憶する。また、ＲＯＭ１３は、ＰＯＳ端末４としての機能を実現するために必要な種々の設定データを記憶する。
【００１６】
ＲＡＭ１４は、可変的なデータを一時的に記憶するためのメモリエリアを形成している。特に、図５に示すように、価値カード８の有効化要求に必要なデータを記憶する記憶部として、カードＩＤ、取引日時、店舗ＩＤ、ＰＯＳＩＤを記憶する有効化メモリ３０を形成している。店舗ＩＤは、当該ＰＯＳ端末４が稼動している店舗を識別するために予めＲＯＭ１３に設定された店舗固有のデータである。ＰＯＳＩＤは、同一店舗で稼動している各ＰＯＳ端末４を識別するために予めＲＯＭ１３に設定された端末固有のデータである。
【００１７】
時計部１５は、現在の日付及び時刻を計時する。ＬＡＮコントローラ１６は、ＬＡＮ６で接続されたストアサーバ５との間のデータ送受信を制御する。
【００１８】
キーボードコントローラ１７は、キーボード２２を制御し、操作キーに対応したキー信号を取り込む。キーボード２２は、置数キー、小計キー、締めキー、取消キー等のＰＯＳ端末４としての機能に必要な種々のキーを配設したものである。
【００１９】
表示コントローラ１８は、オペレータ用ディスプレイ２３の画面表示を制御する。表示コントローラ１９は、客用ディスプレイ２４の画面表示を制御する。オペレータ用ディスプレイ２３は、キャッシャと呼ばれるＰＯＳ端末４のオペレータに対して提供する情報の画面を表示する。客用ディスプレイ２４は、決済対象の商品を購入する客に対して提供する情報の画面を表示する。
【００２０】
プリンタコントローラ２０は、レシート用紙にデータを印字するためのプリンタ２５を制御し、領収書（レシート）等を発行させる。スキャナコントローラ２１は、商品に付されるバーコードを光学的に読み取るためのスキャナ２６を制御し、読み取られたバーコードデータを取り込む。
【００２１】
かかる構成のＰＯＳ端末４を操作するキャッシャは、客が買上商品の会計を申し出ると、その買上商品に付されているバーコードを１品ずつスキャナ２６で読み取り操作する。スキャナ２６で買上商品のバーコードが読み取られると、ＣＰＵ１１は、図６の流れ図に示す手順のスキャニング処理を実行する。なお、この処理は、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００２２】
先ず、ＣＰＵ１１は、スキャニングされたバーコードが、価値カード８に印刷されたバーコード、すなわちカードＩＤであるか否かを判断する。例えば、価値カード８に設定されるカードＩＤは、全て先頭の２桁の数値が等しい。そこでＣＰＵ１１は、スキャニングされたバーコードの先頭の２桁が価値カード８特有の数値と一致するか否かを判断する。
【００２３】
バーコードの先頭の２桁が価値カード８特有の数値と一致しない場合、ＣＰＵ１１は、買上商品の販売データを売上処理する（ＳＴ４：売上処理手段）。具体的には、ＣＰＵ１１は、バーコードを解析して得られる商品コードで商品データファイルを検索して、販売商品の品名，単価等の商品データを読み出す。そしてＣＰＵ１１は、この商品データを基に、商品コード．販売点数，販売金額等の販売商品に係わるトランザクションデータをトランザクションバッファに記憶する。またＣＰＵ１１は、商品コード，商品名，単価，販売点数，販売金額等の明細データをオペレータ用ディスプレイ２３及び客用ディスプレイ２４に表示する。
【００２４】
バーコードの先頭の２桁が価値カード８特有の数値と一致する場合、ＣＰＵ１１は、そのバーコードを解析して得られる商品コード、つまりはカードＩＤと、時計部１５で計時されている現在日時、つまりは取引日時と、予め設定された店舗ＩＤ及びＰＯＳＩＤとを有効化メモリ３０に記憶する（ＳＴ２）。ここに、有効化メモリ３０は、商品である価値カード８の販売に際し正規に販売されたことの証明データであるカードＩＤを記憶する記憶部を構成する。
【００２５】
次いで、ＣＰＵ１１は、ＲＡＭ１４のフラグエリアで記憶する価値カード取引フラグを“１”にセットする（ＳＴ３）。価値カード取引フラグは、１商取引として売り上げる商品のなかに価値カードが含まれるか否かを識別する情報であって、含まれる場合に“１”にセットされる。しかる後、ＣＰＵ１１は、この価値カードの販売データを売上処理する（ＳＴ４：売上処理手段）。
【００２６】
キャッシャは、客が買い上げる商品の売上処理を終了すると、小計キーを入力する。そうすると、１商取引の売上データとしてトランザクションバッファに記憶された商品販売データを基に合計金額が算出されてオペレータ用ディスプレイ２３及び客用ディスプレイ２４に表示されるので、キャッシャは、客に代金の支払い（代金の請求）を求める。そして代金の支払い（代金の徴収）を受けると、キャッシャは、締めキーを操作する。締めキーの操作が検知されると、ＣＰＵ１１は、図７の流れ図に示す処理を実行する。なお、この処理も、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００２７】
先ず、ＣＰＵ１１は、前記価値カード取引フラグをチェックして、１商取引として売り上げる商品のなかに価値カードが含まれる価値カード取引であるか否かを判別する（ＳＴ１１）。
【００２８】
前記価値カード取引フラグがセットされている場合、すなわち価値カード取引の場合には（ＳＴ１１のＹＥＳ）、ＣＰＵ１１は、有効化メモリ３０に記憶されているカードＩＤで識別される価値カード８の有効化を要求する。すなわち、カードＩＤを含む有効化要求問合せコマンドを生成し、ストアサーバ５経由で、価値カード管理サーバ３に送信する（ＳＴ１２：証明データ送信手段）。しかる後、ＣＰＵ１１は、ステップＳＴ１３の処理に進む。
【００２９】
価値カード管理サーバ３は、有効化要求コマンドを受信すると、価値カードデータベース２を検索する。そして、有効化要求コマンドに含まれるカードＩＤに対応するステータスフラグを、無効を示す“０”から有効を示す“１”に変更する。
【００３０】
前記価値カード取引フラグがセットされていない場合、すなわち価値カード取引でない場合には（ＳＴ１１のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ１２の処理を実行せずに、ステップＳＴ１３の処理に進む。
【００３１】
ステップＳＴ１３では、ＣＰＵ１１は、取引締め処理を実行する。この処理は、釣銭演算及び釣銭表示と、合計金額，預かり金額，釣銭額、取引日時、取引番号、ＰＯＳＩＤ等の決済に係わるトランザクションデータの保存とを含む。取引締め処理が終了すると、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する（ＳＴ１４）。
【００３２】
このように構成された第１の実施形態のＰＯＳ端末４においては、価値カード８のバーコードデータをスキャナ２６でスキャニングすると、その価値カード８の証明データであるカードＩＤを含むデータが、有効化メモリ３０に記憶される。そして、この価値カード８を購入する客との商取引の決済を宣言する締めキーが操作されると、有効化メモリ３０で記憶しているデータに基づいて、価値カード８の有効化要求コマンドが価値カード管理サーバ３に送信されて、価値カード８が有効化される。
【００３３】
このように、第１の実施形態において、価値カード８が有効化されるのは、締めキーが操作された後、つまりは客が代金を支払った後である。したがって、客が代金の支払いを取り止めた場合に有効化された価値カードが代金未収のまま店側に残るという問題はなくなる。
【００３４】
［第２の実施形態］
次に、第２の実施形態について説明する。第２の実施形態が第１の実施形態と異なる点は、ＰＯＳ端末４のＣＰＵ１１が実行する締めキー処理の手順である。その他は第１の実施形態と同様なので、図１〜図６までは第１の実施形態と共通に使用し、その説明は省略する。
【００３５】
図８は、第２の実施形態における締めキー処理の手順を示す流れ図である。１商取引として売上げる商品の販売データが売上げ処理され、続いて、この１取引の締めキーが押下されると、ＣＰＵ１１は、先ず、取引締め処理を実行する（ＳＴ２１）。次いで、ＣＰＵ１１は、前記価値カード取引フラグをチェックして、１商取引として売り上げる商品のなかに価値カードが含まれる価値カード取引であるか否かを判別する（ＳＴ２２）。
【００３６】
前記価値カード取引フラグがセットされている場合、すなわち価値カード取引の場合には（ＳＴ２２のＹＥＳ）、ＣＰＵ１１は、有効化メモリ３０に記憶されているカードＩＤで識別される価値カード８の有効化を要求する。すなわち、カードＩＤを含む有効化要求問合せコマンドを生成し、ストアサーバ５経由で、価値カード管理サーバ３に送信する（ＳＴ２３：証明データ送信手段）。しかる後、ＣＰＵ１１は、ステップＳＴ２４の処理に進む。
【００３７】
前記価値カード取引フラグがセットされていない場合、すなわち価値カード取引でない場合には（ＳＴ２２のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ２３の処理を実行せずに、ステップＳＴ２４の処理に進む。
【００３８】
ステップＳＴ２４では、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する。
【００３９】
このように、第２の実施形態において、価値カード８が有効化されるのは、締めキーが操作されたことに応じて取引締め処理が実行されて、取引が確定した後である。したがって、第１の実施形態と同様に客が代金を支払った後に価値カード８が有効となるので、有効化された価値カードが代金未収のまま店側に残るという問題はなくなる。
【００４０】
［第３の実施形態］
次に、店舗にて会計を済ますことによって有効となるコンサート，演劇等のチケット類を発券する店に適用する第３の実施形態について、図９〜図１３を用いて説明する。なお、第１の実施形態と共通する部分には同一の符号を付し、重複する説明は省略する。
【００４１】
図９は、第３の実施形態のシステム構成図である。本システムは、各店舗にそれぞれ構築されるＰＯＳシステム１と、チケットデータベース５１を管理するチケット管理サーバ５２とからなる。各店舗のＰＯＳシステム１のストアサーバ５と前記チケット管理サーバ５２とは、インターネット等のネットワーク回線７によって接続されている。
【００４２】
ＰＯＳシステム１は、前記チケットの印刷に特化したチケットプリンタ４０を含む。チケットプリンタ４０は、ＬＡＮ６に接続されており、各ＰＯＳ端末４からＬＡＮ６を介してチケット印字データを受信すると、チケットを発券する。
【００４３】
チケットデータベース５１は、図１０に示すように、インターネット等を利用して客が予約をしたコンサート，演劇等のチケットを個々に識別するチケットコードに対応して、そのチケットを印字するためのチケット印字データと、チケットの発券期限日を特定するデータと、発券済であるか否かを識別するためのステータスフラグとを記憶する。ステータスフラグは、例えば“０”は未発券状態を示し、“１”は発券済状態を示す。なお、チケットコードは、客がチケットを予約した際に印刷可能となる引換え票に、バーコードまたは二次元データコードの形式で印刷されている。あるいは、携帯電話等の携帯型通信機器のディスプレイに、バーコードまたは二次元データコードの形式で表示可能としてもよい。
【００４４】
各ＰＯＳ端末４のＲＡＭ１４には、特に、図１１に示すように、チケット管理サーバ５２から受信したチケット印字データを、そのチケット印字テータを識別するためのチケットコードとともに記憶するためのデータバッファ６０を形成している。
【００４５】
かかる構成のＰＯＳ端末４を操作するキャッシャは、客が買上商品の会計を申し出ると、その買上商品に付されているバーコードを１品ずつスキャナ２６で読み取り操作する。スキャナ２６で買上商品のバーコードが読み取られると、ＣＰＵ１１は、図１２の流れ図に示す手順のスキャニング処理を実行する。なお、この処理は、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００４６】
先ず、ＣＰＵ１１は、スキャニングされたバーコードが、チケットコードのバーコードであるか否かを判断する。例えば、チケットコードは、全て先頭の２桁の数値が等しい。そこでＣＰＵ１１は、スキャニングされたバーコードの先頭の２桁がチケットコード特有の数値と一致するか否かを判断する（ＳＴ３１）。
【００４７】
バーコードの先頭の２桁がチケットコード特有の数値と一致しない場合（ＳＴ３１のＮＯ）、ＣＰＵ１１は、買上商品の販売データを売上処理する（ＳＴ３６：売上処理手段）。
【００４８】
バーコードの先頭の２桁がチケットコード特有の数値と一致する場合（ＳＴ３１のＹＥＳ）、ＣＰＵ１１は、そのバーコードから得られるチケットコードのチケット発券を問い合わせる。すなわち、チケットコードを含む発券問合せコマンドを生成し、ストアサーバ５経由で、チケット管理サーバ５２に送信する。
【００４９】
チケット管理サーバ５２は、発券問合せコマンドを受信すると、チケットデータベース５１を検索する。そして、発券問合せコマンドに含まれるチケットコードに対応するフラグが未発券を示す“０”にリセットされていること、及び、発券期限が経過していないことを確認すると、チケットの発券を承認する。フラグが発券済を示す“１”にセットされているとき、あるいは、発券期限が経過している場合には、チケットの発券を承認しない。チケットの発券を承認する場合、チケット管理サーバ５２は、そのチケットコードに対応するチケット印字データを、チケットコードとともにコマンド送信元のＰＯＳ端末４に返信する。
【００５０】
発券問合せコマンドを送信したＰＯＳ端末４のＣＰＵ１１は、チケット印字データの受信を待機する（ＳＴ３３）。コマンド送信から所定時間が経過してもチケット印字データを受信できない場合には（ＳＴ３３のＮＯ）、今回のチケットコードの入力をエラーとする。
【００５１】
チケット印字データを受信すると（ＳＴ３３のＹＥＳ）、ＣＰＵ１１は、このチケット印字データをチケットコードとともにデータバッファ６０に記憶する。また、ＲＡＭ１４のフラグエリアで記憶するチケット取引フラグを“１”にセットする（ＳＴ３５）。チケット取引フラグは、１商取引として売り上げる商品のなかにチケットが含まれるか否かを識別する情報であって、含まれる場合に“１”にセットされる。しかる後、ＣＰＵ１１は、このチケットの販売データを売上処理する（ＳＴ３６：売上処理手段）。
【００５２】
キャッシャは、客が買い上げる商品の売上処理を終了すると、小計キーを入力する。そうすると、１商取引の売上データとしてトランザクションバッファに記憶された商品販売データを基に合計金額が算出されてオペレータ用ディスプレイ２３及び客用ディスプレイ２４に表示されるので、キャッシャは、客に代金の支払い（代金の請求）を求める。そして代金の支払い（代金の徴収）を受けると、キャッシャは、締めキーを操作する。締めキーが操作されたことを検知すると、ＣＰＵ１１は、図１３の流れ図に示す処理を実行する。なお、この処理も、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００５３】
先ず、ＣＰＵ１１は、前記チケット取引フラグをチェックして、１商取引として売り上げる商品のなかにチケットが含まれるチケット取引であるか否かを判別する（ＳＴ４１）。
【００５４】
前記チケット取引フラグがセットされている場合、すなわちチケット取引の場合には（ＳＴ４１のＹＥＳ）、ＣＰＵ１１は、データバッファ６０に記憶されているチケット印字データを、ＬＡＮコントローラ１６を介してチケットプリンタ４０に出力して、チケットの発券を制御する（ＳＴ４２：チケット発券手段）。また、ＣＰＵ１１は、データバッファ６０に記憶されているチケットコードを含む発券完了コマンドを生成し、ストアサーバ５経由で、チケット管理サーバ５２に送信する（ＳＴ４３）。しかる後、ＣＰＵ１１は、ステップＳＴ４４の処理に進む。
【００５５】
チケット管理サーバ５２は、発券完了コマンドを受信すると、チケットデータベース５１を検索する。そして、発券完了コマンドに含まれるチケットコードに対応するステータスフラグを、未発券を示す“０”から発券済を示す“１”に変更する。
【００５６】
前記チケット取引フラグがセットされていない場合、すなわちチケット取引でない場合には（ＳＴ４１のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ４２，４３の処理を実行せずに、ステップＳＴ４４の処理に進む。
【００５７】
ステップＳＴ４４では、ＣＰＵ１１は、取引締め処理を実行する。取引締め処理が終了すると、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する（ＳＴ４５）。
【００５８】
このように構成された第３の実施形態のＰＯＳ端末４においては、チケットコードのバーコードデータをスキャナ２６でスキャニングすると、そのチケットコードで識別されるチケットの発券承認をチケット管理サーバに５２に問い合わせる。そして、発券が承認され、チケット印字データを受信すると、そのチケット印字データを、データバッファ６０に記憶する。そして、このチケットを購入する客との商取引の決済を宣言する締めキーの操作を検知すると、データバッファ６０で記憶しているチケット印字データに基づいて、チケットプリンタ４０からチケットが発券されて、チケットが有効なものとなる。
【００５９】
このように、第３の実施形態において、チケットが発券されて有効となるのは、締めキーが操作された後、つまりは客が代金を支払った後である。したがって、客が代金の支払いを取り止めた場合に発券済のチケットが代金未収のまま店側に残るという問題はなくなる。
【００６０】
［第４の実施形態］
次に、第４の実施形態について説明する。第４の実施形態が第３の実施形態と異なる点は、ＰＯＳ端末４のＣＰＵ１１が実行する締めキー処理の手順である。その他は第３の実施形態と同様なので、図９〜図１２までは第３の実施形態と共通に使用し、その説明は省略する。
【００６１】
図１４は、第４の実施形態における締めキー処理の手順を示す流れ図である。１商取引として売上げる商品の販売データが売上げ処理され、続いて、この１取引に対して締めキーの操作を検知すると、ＣＰＵ１１は、先ず、取引締め処理を実行する（ＳＴ５１）。次いで、ＣＰＵ１１は、前記チケット取引フラグをチェックして、１商取引として売り上げる商品のなかにチケットが含まれるチケット取引であるか否かを判別する（ＳＴ５２）。
【００６２】
前記チケット取引フラグがセットされている場合、すなわちチケット取引の場合には（ＳＴ５２のＹＥＳ）、ＣＰＵ１１は、データバッファ６０に記憶されているチケット印字データをチケットプリンタ４０に出力して、チケットの発券を制御する（ＳＴ５３：有効化制御手段）。また、ＣＰＵ１１は、データバッファ６０に記憶されているチケットコードを含む発券完了コマンドを生成し、ストアサーバ５経由で、チケット管理サーバ５２に送信する（ＳＴ５４）。しかる後、ＣＰＵ１１は、ステップＳＴ５５の処理に進む。
【００６３】
前記チケット取引フラグがセットされていない場合、すなわちチケット取引でない場合には（ＳＴ５２のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ５３，５４の処理を実行せずに、ステップＳＴ５５の処理に進む。
【００６４】
ステップＳＴ５５では、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する。
【００６５】
このように、第４の実施形態において、チケットが発券されるのは、締めキーが操作されたことに応じて取引締め処理が実行されて、取引が確定した後である。したがって、第３の実施形態と同様に客が代金を支払った後に発券されるので、発券されたチケットが代金未収のまま店側に残るという問題はなくなる。
【００６６】
以下、前記実施形態の変形例について説明する。
前記第３または第４の実施形態においては、チケットの承認を問い合わせるための発券問合せコマンドを、チケットコードのバーコードをスキャニングしたときにチケット管理サーバ５２に送信した。この点に関し、第１または第２の実施形態のように、チケットコードのバーコードをスキャニングしたときにはそのチケットコードのデータをメモリに記憶し、締めキーが操作された後に、メモリに記憶したチケットコードで発券問合せコマンドを生成して、チケット管理サーバ５２に送信してもよい。この場合は、チケット印字データを記憶するためのデータバッファ６０が不要となる。ただし、第３または第４の実施形態のように構成することによって、締めキーが操作されてからチケットが発券されるまでの待ち時間を短縮できる効果を奏する。
【００６７】
また、前記各実施形態は、装置内部のＲＯＭに発明の機能を実現させる制御プログラムが予め記録されているものとした。しかしこれに限らず、同様のプログラムがネットワークから装置にダウンロードされてもよい。あるいは、記録媒体に記録された同様のプログラムが、装置にインストールされてもよい。記録媒体は、ＣＤ−ＲＯＭ，メモリカード等のようにプログラムを記憶でき、かつ装置が読み取り可能であれば、その形態は問わない。また、プログラムのインストールやダウンロードにより得る機能は、装置内部のＯＳ（オペレーティング・システム）等と協働してその機能を実現させるものであってもよい。
【００６８】
この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００６９】
１…ＰＯＳシステム、２…価値カードデータベース、３…価値カード管理サーバ、４…ＰＯＳ端末、５…ストアサーバ、８…価値カード、３０…有効化メモリ、４０…チケットプリンタ、５１…チケットデータベース、５２…チケット管理サーバ、６０…データバッファ。
【技術分野】
【０００１】
本発明の実施形態は、商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品、例えば価値カードや、コンサート，演劇等のチケット等を販売する店舗向けの商品販売データ処理装置及びその制御プログラムに関する。
【背景技術】
【０００２】
インターネットを利用して、音楽、電子書籍等のコンテンツや商品またはサービスを購入する際の代金支払い方法の一つに、プリペイド式の価値カードがある。この種の価値カードは、一般に、家電量販店やコンビニエンスストア等で販売されている。販売店の店員は、客から価値カード購入の申し出を受けると、予めストックされている未使用の価値カードに印刷されているバーコードを、ＰＯＳ（Point Of Sales）端末のスキャナで読み取る。バーコードは、その価値カードに対して一意に設定されたカードＩＤをバーコードシンボル化したものである。バーコードが読み取られると、そのバーコードデータ（カードＩＤ）がＰＯＳ端末からストアサーバを経由して、外部の価値カード管理サーバに送信される。
【０００３】
価値カード管理サーバは、管理対象の全ての価値カードのカードＩＤと対応させて、価値情報とステータス情報とを記憶したデータベースを備えている。ＰＯＳ端末で読み取られたバーコードデータ（カードＩＤ）を受信すると、価値カード管理サーバはデータベースを検索し、そのカードＩＤに対応するステータス情報を、無効の状態から有効の状態に切り替える。ステータス情報が有効の状態になると、当該カードＩＤで特定される価値カードが有効となり、価値情報に相当する金額までの代金支払いに供せられる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２０４４４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のＰＯＳ端末は、価値カードのカードＩＤが入力されると、そのカードを購入する客が代金を支払う前に、そのカードが正規に販売されたことの証明データ（カードＩＤ）をサーバに送信していた。このため、例えば財布を忘れた等の理由から客が代金の支払いを取り止めた場合、有効化された状態のカードが代金未収のまま店側に残るという問題が生じる。
【０００６】
このようなことは、インターネットを利用して客が事前にコンサートや演劇等の入場券であるチケットの購入権を獲得し、その代金をコンビニエンスストア等の店舗で支払うと、チケットを入手できるようなチケット販売形式の場合にも生じる。例えば、チケットの購入権を獲得していることを証明するデータが客から提示され、当該データを読み取ると当該チケットの発券を行ない、代金の支払いを求める。この場合、客が代金を支払う前にチケットが発券されるため、客が代金の支払いを取り止めた場合に、発券により有効となったチケットが代金未収のまま店側に残ってしまう。
【０００７】
本発明が解決しようとする課題は、代金の支払い受け前に商品を有効化することを防止できる商品販売データ処理装置及びその制御プログラムを提供しようとするものである。
【課題を解決するための手段】
【０００８】
かかる課題を解決するために、一実施形態の商品販売データ処理装置は、売上処理手段と、記憶部と、証明データ送信手段とを備える。売上処理手段は、入力された買上商品のデータに基づいて商品販売データを売上処理する。記憶部は、売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の証明データを記憶する。証明データ送信手段は、記憶部で証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、記憶部で記憶している証明データをサーバに送信する。
【図面の簡単な説明】
【０００９】
【図１】商品販売データ処理装置の第１の実施形態を示すシステム構成図。
【図２】同第１の実施形態で用いる価値カードを示す平面図。
【図３】同第１の実施形態において、価値カードデータベースに記憶されるデータの一例を示す図。
【図４】同第１の実施形態におけるＰＯＳ端末のハードウェア構成を示すブロック図。
【図５】同第１の実施形態において、ＰＯＳ端末のＲＡＭに形成される有効化メモリの構成図。
【図６】同第１の実施形態において、ＰＯＳ端末のＣＰＵが実行するスキャニング処理の要部手順を示す流れ図。
【図７】同第１の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【図８】商品販売データ処理装置の第２の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【図９】商品販売データ処理装置の第３の実施形態を示すシステム構成図。
【図１０】同第３の実施形態において、価値カードデータベースに記憶されるデータの一例を示す図。
【図１１】同第３の実施形態において、ＰＯＳ端末のＲＡＭに形成されるデータバッファの構成図。
【図１２】同第３の実施形態において、ＰＯＳ端末のＣＰＵが実行するスキャニング処理の要部手順を示す流れ図。
【図１３】同第３の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【図１４】商品販売データ処理装置の第４の実施形態において、ＰＯＳ端末のＣＰＵが実行する締めキー処理の要部手順を示す流れ図。
【発明を実施するための形態】
【００１０】
以下、商品販売データ処理装置の実施形態を、図面を用いて説明する。
【００１１】
［第１の実施形態］
はじめに、価値カードの販売店に適用する第１の実施形態について、図１〜図７を用いて説明する。図１は、第１の実施形態のシステム構成図である。本システムは、各店舗にそれぞれ構築されるＰＯＳシステム１と、価値カードデータベース２を管理する価値カード管理サーバ３とからなる。ＰＯＳシステム１は、商品販売データ処理装置として機能する複数台のＰＯＳ端末４と、各ＰＯＳ端末４を一元的に管理するストアサーバ５とからなり、各ＰＯＳ端末４とストアサーバ５とは、ＬＡＮ（Local Area Network）６によって接続されている。各店舗のＰＯＳシステム１のストアサーバ５と前記価値カード管理サーバ３とは、インターネット等のネットワーク回線７によって接続されている。
【００１２】
図２に示すように、本実施形態で使用される価値カード８には、バーコード９が印刷されている。バーコード９は、当該価値カード８を一意に識別するためのカードＩＤをバーコードシンボル化したものである。
【００１３】
価値カードデータベース２は、図３に示すように、各価値カード８のカードＩＤに対応させて、価値情報とステータスフラグとを記憶する。価値情報は、対応するカードＩＤによって特定される価値カード８で支払いが可能な金額である。ステータスフラグは、例えば“０”は無効状態を示し、“１”は有効状態を示す。なお、価値情報は、金額に限定されない。１ポイントあたりの金額を可変設定可能なポイントであってもよい。
【００１４】
図４は、ＰＯＳ端末４の要部構成を示すブロック図である。ＰＯＳ端末４は、制御部本体としてＣＰＵ（Central Processing Unit）１１を搭載している。そしてこのＣＰＵ１１に、アドレスバス，データバス等のバスライン１２を介して、ＲＯＭ（Read Only Memory）１３、ＲＡＭ（Random Access Memory）１４、時計部１５、ＬＡＮコントローラ１６、キーボードコントローラ１７、表示コントローラ１８、表示コントローラ１９、プリンタコントローラ２０、スキャナコントローラ２１等を接続して、ＰＯＳ端末４の制御回路を構成している。
【００１５】
ＲＯＭ１３は、ＣＰＵ１１にＰＯＳ端末４としての機能を実現させるためのプログラムを記憶する。また、ＲＯＭ１３は、ＰＯＳ端末４としての機能を実現するために必要な種々の設定データを記憶する。
【００１６】
ＲＡＭ１４は、可変的なデータを一時的に記憶するためのメモリエリアを形成している。特に、図５に示すように、価値カード８の有効化要求に必要なデータを記憶する記憶部として、カードＩＤ、取引日時、店舗ＩＤ、ＰＯＳＩＤを記憶する有効化メモリ３０を形成している。店舗ＩＤは、当該ＰＯＳ端末４が稼動している店舗を識別するために予めＲＯＭ１３に設定された店舗固有のデータである。ＰＯＳＩＤは、同一店舗で稼動している各ＰＯＳ端末４を識別するために予めＲＯＭ１３に設定された端末固有のデータである。
【００１７】
時計部１５は、現在の日付及び時刻を計時する。ＬＡＮコントローラ１６は、ＬＡＮ６で接続されたストアサーバ５との間のデータ送受信を制御する。
【００１８】
キーボードコントローラ１７は、キーボード２２を制御し、操作キーに対応したキー信号を取り込む。キーボード２２は、置数キー、小計キー、締めキー、取消キー等のＰＯＳ端末４としての機能に必要な種々のキーを配設したものである。
【００１９】
表示コントローラ１８は、オペレータ用ディスプレイ２３の画面表示を制御する。表示コントローラ１９は、客用ディスプレイ２４の画面表示を制御する。オペレータ用ディスプレイ２３は、キャッシャと呼ばれるＰＯＳ端末４のオペレータに対して提供する情報の画面を表示する。客用ディスプレイ２４は、決済対象の商品を購入する客に対して提供する情報の画面を表示する。
【００２０】
プリンタコントローラ２０は、レシート用紙にデータを印字するためのプリンタ２５を制御し、領収書（レシート）等を発行させる。スキャナコントローラ２１は、商品に付されるバーコードを光学的に読み取るためのスキャナ２６を制御し、読み取られたバーコードデータを取り込む。
【００２１】
かかる構成のＰＯＳ端末４を操作するキャッシャは、客が買上商品の会計を申し出ると、その買上商品に付されているバーコードを１品ずつスキャナ２６で読み取り操作する。スキャナ２６で買上商品のバーコードが読み取られると、ＣＰＵ１１は、図６の流れ図に示す手順のスキャニング処理を実行する。なお、この処理は、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００２２】
先ず、ＣＰＵ１１は、スキャニングされたバーコードが、価値カード８に印刷されたバーコード、すなわちカードＩＤであるか否かを判断する。例えば、価値カード８に設定されるカードＩＤは、全て先頭の２桁の数値が等しい。そこでＣＰＵ１１は、スキャニングされたバーコードの先頭の２桁が価値カード８特有の数値と一致するか否かを判断する。
【００２３】
バーコードの先頭の２桁が価値カード８特有の数値と一致しない場合、ＣＰＵ１１は、買上商品の販売データを売上処理する（ＳＴ４：売上処理手段）。具体的には、ＣＰＵ１１は、バーコードを解析して得られる商品コードで商品データファイルを検索して、販売商品の品名，単価等の商品データを読み出す。そしてＣＰＵ１１は、この商品データを基に、商品コード．販売点数，販売金額等の販売商品に係わるトランザクションデータをトランザクションバッファに記憶する。またＣＰＵ１１は、商品コード，商品名，単価，販売点数，販売金額等の明細データをオペレータ用ディスプレイ２３及び客用ディスプレイ２４に表示する。
【００２４】
バーコードの先頭の２桁が価値カード８特有の数値と一致する場合、ＣＰＵ１１は、そのバーコードを解析して得られる商品コード、つまりはカードＩＤと、時計部１５で計時されている現在日時、つまりは取引日時と、予め設定された店舗ＩＤ及びＰＯＳＩＤとを有効化メモリ３０に記憶する（ＳＴ２）。ここに、有効化メモリ３０は、商品である価値カード８の販売に際し正規に販売されたことの証明データであるカードＩＤを記憶する記憶部を構成する。
【００２５】
次いで、ＣＰＵ１１は、ＲＡＭ１４のフラグエリアで記憶する価値カード取引フラグを“１”にセットする（ＳＴ３）。価値カード取引フラグは、１商取引として売り上げる商品のなかに価値カードが含まれるか否かを識別する情報であって、含まれる場合に“１”にセットされる。しかる後、ＣＰＵ１１は、この価値カードの販売データを売上処理する（ＳＴ４：売上処理手段）。
【００２６】
キャッシャは、客が買い上げる商品の売上処理を終了すると、小計キーを入力する。そうすると、１商取引の売上データとしてトランザクションバッファに記憶された商品販売データを基に合計金額が算出されてオペレータ用ディスプレイ２３及び客用ディスプレイ２４に表示されるので、キャッシャは、客に代金の支払い（代金の請求）を求める。そして代金の支払い（代金の徴収）を受けると、キャッシャは、締めキーを操作する。締めキーの操作が検知されると、ＣＰＵ１１は、図７の流れ図に示す処理を実行する。なお、この処理も、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００２７】
先ず、ＣＰＵ１１は、前記価値カード取引フラグをチェックして、１商取引として売り上げる商品のなかに価値カードが含まれる価値カード取引であるか否かを判別する（ＳＴ１１）。
【００２８】
前記価値カード取引フラグがセットされている場合、すなわち価値カード取引の場合には（ＳＴ１１のＹＥＳ）、ＣＰＵ１１は、有効化メモリ３０に記憶されているカードＩＤで識別される価値カード８の有効化を要求する。すなわち、カードＩＤを含む有効化要求問合せコマンドを生成し、ストアサーバ５経由で、価値カード管理サーバ３に送信する（ＳＴ１２：証明データ送信手段）。しかる後、ＣＰＵ１１は、ステップＳＴ１３の処理に進む。
【００２９】
価値カード管理サーバ３は、有効化要求コマンドを受信すると、価値カードデータベース２を検索する。そして、有効化要求コマンドに含まれるカードＩＤに対応するステータスフラグを、無効を示す“０”から有効を示す“１”に変更する。
【００３０】
前記価値カード取引フラグがセットされていない場合、すなわち価値カード取引でない場合には（ＳＴ１１のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ１２の処理を実行せずに、ステップＳＴ１３の処理に進む。
【００３１】
ステップＳＴ１３では、ＣＰＵ１１は、取引締め処理を実行する。この処理は、釣銭演算及び釣銭表示と、合計金額，預かり金額，釣銭額、取引日時、取引番号、ＰＯＳＩＤ等の決済に係わるトランザクションデータの保存とを含む。取引締め処理が終了すると、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する（ＳＴ１４）。
【００３２】
このように構成された第１の実施形態のＰＯＳ端末４においては、価値カード８のバーコードデータをスキャナ２６でスキャニングすると、その価値カード８の証明データであるカードＩＤを含むデータが、有効化メモリ３０に記憶される。そして、この価値カード８を購入する客との商取引の決済を宣言する締めキーが操作されると、有効化メモリ３０で記憶しているデータに基づいて、価値カード８の有効化要求コマンドが価値カード管理サーバ３に送信されて、価値カード８が有効化される。
【００３３】
このように、第１の実施形態において、価値カード８が有効化されるのは、締めキーが操作された後、つまりは客が代金を支払った後である。したがって、客が代金の支払いを取り止めた場合に有効化された価値カードが代金未収のまま店側に残るという問題はなくなる。
【００３４】
［第２の実施形態］
次に、第２の実施形態について説明する。第２の実施形態が第１の実施形態と異なる点は、ＰＯＳ端末４のＣＰＵ１１が実行する締めキー処理の手順である。その他は第１の実施形態と同様なので、図１〜図６までは第１の実施形態と共通に使用し、その説明は省略する。
【００３５】
図８は、第２の実施形態における締めキー処理の手順を示す流れ図である。１商取引として売上げる商品の販売データが売上げ処理され、続いて、この１取引の締めキーが押下されると、ＣＰＵ１１は、先ず、取引締め処理を実行する（ＳＴ２１）。次いで、ＣＰＵ１１は、前記価値カード取引フラグをチェックして、１商取引として売り上げる商品のなかに価値カードが含まれる価値カード取引であるか否かを判別する（ＳＴ２２）。
【００３６】
前記価値カード取引フラグがセットされている場合、すなわち価値カード取引の場合には（ＳＴ２２のＹＥＳ）、ＣＰＵ１１は、有効化メモリ３０に記憶されているカードＩＤで識別される価値カード８の有効化を要求する。すなわち、カードＩＤを含む有効化要求問合せコマンドを生成し、ストアサーバ５経由で、価値カード管理サーバ３に送信する（ＳＴ２３：証明データ送信手段）。しかる後、ＣＰＵ１１は、ステップＳＴ２４の処理に進む。
【００３７】
前記価値カード取引フラグがセットされていない場合、すなわち価値カード取引でない場合には（ＳＴ２２のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ２３の処理を実行せずに、ステップＳＴ２４の処理に進む。
【００３８】
ステップＳＴ２４では、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する。
【００３９】
このように、第２の実施形態において、価値カード８が有効化されるのは、締めキーが操作されたことに応じて取引締め処理が実行されて、取引が確定した後である。したがって、第１の実施形態と同様に客が代金を支払った後に価値カード８が有効となるので、有効化された価値カードが代金未収のまま店側に残るという問題はなくなる。
【００４０】
［第３の実施形態］
次に、店舗にて会計を済ますことによって有効となるコンサート，演劇等のチケット類を発券する店に適用する第３の実施形態について、図９〜図１３を用いて説明する。なお、第１の実施形態と共通する部分には同一の符号を付し、重複する説明は省略する。
【００４１】
図９は、第３の実施形態のシステム構成図である。本システムは、各店舗にそれぞれ構築されるＰＯＳシステム１と、チケットデータベース５１を管理するチケット管理サーバ５２とからなる。各店舗のＰＯＳシステム１のストアサーバ５と前記チケット管理サーバ５２とは、インターネット等のネットワーク回線７によって接続されている。
【００４２】
ＰＯＳシステム１は、前記チケットの印刷に特化したチケットプリンタ４０を含む。チケットプリンタ４０は、ＬＡＮ６に接続されており、各ＰＯＳ端末４からＬＡＮ６を介してチケット印字データを受信すると、チケットを発券する。
【００４３】
チケットデータベース５１は、図１０に示すように、インターネット等を利用して客が予約をしたコンサート，演劇等のチケットを個々に識別するチケットコードに対応して、そのチケットを印字するためのチケット印字データと、チケットの発券期限日を特定するデータと、発券済であるか否かを識別するためのステータスフラグとを記憶する。ステータスフラグは、例えば“０”は未発券状態を示し、“１”は発券済状態を示す。なお、チケットコードは、客がチケットを予約した際に印刷可能となる引換え票に、バーコードまたは二次元データコードの形式で印刷されている。あるいは、携帯電話等の携帯型通信機器のディスプレイに、バーコードまたは二次元データコードの形式で表示可能としてもよい。
【００４４】
各ＰＯＳ端末４のＲＡＭ１４には、特に、図１１に示すように、チケット管理サーバ５２から受信したチケット印字データを、そのチケット印字テータを識別するためのチケットコードとともに記憶するためのデータバッファ６０を形成している。
【００４５】
かかる構成のＰＯＳ端末４を操作するキャッシャは、客が買上商品の会計を申し出ると、その買上商品に付されているバーコードを１品ずつスキャナ２６で読み取り操作する。スキャナ２６で買上商品のバーコードが読み取られると、ＣＰＵ１１は、図１２の流れ図に示す手順のスキャニング処理を実行する。なお、この処理は、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００４６】
先ず、ＣＰＵ１１は、スキャニングされたバーコードが、チケットコードのバーコードであるか否かを判断する。例えば、チケットコードは、全て先頭の２桁の数値が等しい。そこでＣＰＵ１１は、スキャニングされたバーコードの先頭の２桁がチケットコード特有の数値と一致するか否かを判断する（ＳＴ３１）。
【００４７】
バーコードの先頭の２桁がチケットコード特有の数値と一致しない場合（ＳＴ３１のＮＯ）、ＣＰＵ１１は、買上商品の販売データを売上処理する（ＳＴ３６：売上処理手段）。
【００４８】
バーコードの先頭の２桁がチケットコード特有の数値と一致する場合（ＳＴ３１のＹＥＳ）、ＣＰＵ１１は、そのバーコードから得られるチケットコードのチケット発券を問い合わせる。すなわち、チケットコードを含む発券問合せコマンドを生成し、ストアサーバ５経由で、チケット管理サーバ５２に送信する。
【００４９】
チケット管理サーバ５２は、発券問合せコマンドを受信すると、チケットデータベース５１を検索する。そして、発券問合せコマンドに含まれるチケットコードに対応するフラグが未発券を示す“０”にリセットされていること、及び、発券期限が経過していないことを確認すると、チケットの発券を承認する。フラグが発券済を示す“１”にセットされているとき、あるいは、発券期限が経過している場合には、チケットの発券を承認しない。チケットの発券を承認する場合、チケット管理サーバ５２は、そのチケットコードに対応するチケット印字データを、チケットコードとともにコマンド送信元のＰＯＳ端末４に返信する。
【００５０】
発券問合せコマンドを送信したＰＯＳ端末４のＣＰＵ１１は、チケット印字データの受信を待機する（ＳＴ３３）。コマンド送信から所定時間が経過してもチケット印字データを受信できない場合には（ＳＴ３３のＮＯ）、今回のチケットコードの入力をエラーとする。
【００５１】
チケット印字データを受信すると（ＳＴ３３のＹＥＳ）、ＣＰＵ１１は、このチケット印字データをチケットコードとともにデータバッファ６０に記憶する。また、ＲＡＭ１４のフラグエリアで記憶するチケット取引フラグを“１”にセットする（ＳＴ３５）。チケット取引フラグは、１商取引として売り上げる商品のなかにチケットが含まれるか否かを識別する情報であって、含まれる場合に“１”にセットされる。しかる後、ＣＰＵ１１は、このチケットの販売データを売上処理する（ＳＴ３６：売上処理手段）。
【００５２】
キャッシャは、客が買い上げる商品の売上処理を終了すると、小計キーを入力する。そうすると、１商取引の売上データとしてトランザクションバッファに記憶された商品販売データを基に合計金額が算出されてオペレータ用ディスプレイ２３及び客用ディスプレイ２４に表示されるので、キャッシャは、客に代金の支払い（代金の請求）を求める。そして代金の支払い（代金の徴収）を受けると、キャッシャは、締めキーを操作する。締めキーが操作されたことを検知すると、ＣＰＵ１１は、図１３の流れ図に示す処理を実行する。なお、この処理も、ＲＯＭ１３に記憶された制御プログラムに基づくものである。
【００５３】
先ず、ＣＰＵ１１は、前記チケット取引フラグをチェックして、１商取引として売り上げる商品のなかにチケットが含まれるチケット取引であるか否かを判別する（ＳＴ４１）。
【００５４】
前記チケット取引フラグがセットされている場合、すなわちチケット取引の場合には（ＳＴ４１のＹＥＳ）、ＣＰＵ１１は、データバッファ６０に記憶されているチケット印字データを、ＬＡＮコントローラ１６を介してチケットプリンタ４０に出力して、チケットの発券を制御する（ＳＴ４２：チケット発券手段）。また、ＣＰＵ１１は、データバッファ６０に記憶されているチケットコードを含む発券完了コマンドを生成し、ストアサーバ５経由で、チケット管理サーバ５２に送信する（ＳＴ４３）。しかる後、ＣＰＵ１１は、ステップＳＴ４４の処理に進む。
【００５５】
チケット管理サーバ５２は、発券完了コマンドを受信すると、チケットデータベース５１を検索する。そして、発券完了コマンドに含まれるチケットコードに対応するステータスフラグを、未発券を示す“０”から発券済を示す“１”に変更する。
【００５６】
前記チケット取引フラグがセットされていない場合、すなわちチケット取引でない場合には（ＳＴ４１のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ４２，４３の処理を実行せずに、ステップＳＴ４４の処理に進む。
【００５７】
ステップＳＴ４４では、ＣＰＵ１１は、取引締め処理を実行する。取引締め処理が終了すると、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する（ＳＴ４５）。
【００５８】
このように構成された第３の実施形態のＰＯＳ端末４においては、チケットコードのバーコードデータをスキャナ２６でスキャニングすると、そのチケットコードで識別されるチケットの発券承認をチケット管理サーバに５２に問い合わせる。そして、発券が承認され、チケット印字データを受信すると、そのチケット印字データを、データバッファ６０に記憶する。そして、このチケットを購入する客との商取引の決済を宣言する締めキーの操作を検知すると、データバッファ６０で記憶しているチケット印字データに基づいて、チケットプリンタ４０からチケットが発券されて、チケットが有効なものとなる。
【００５９】
このように、第３の実施形態において、チケットが発券されて有効となるのは、締めキーが操作された後、つまりは客が代金を支払った後である。したがって、客が代金の支払いを取り止めた場合に発券済のチケットが代金未収のまま店側に残るという問題はなくなる。
【００６０】
［第４の実施形態］
次に、第４の実施形態について説明する。第４の実施形態が第３の実施形態と異なる点は、ＰＯＳ端末４のＣＰＵ１１が実行する締めキー処理の手順である。その他は第３の実施形態と同様なので、図９〜図１２までは第３の実施形態と共通に使用し、その説明は省略する。
【００６１】
図１４は、第４の実施形態における締めキー処理の手順を示す流れ図である。１商取引として売上げる商品の販売データが売上げ処理され、続いて、この１取引に対して締めキーの操作を検知すると、ＣＰＵ１１は、先ず、取引締め処理を実行する（ＳＴ５１）。次いで、ＣＰＵ１１は、前記チケット取引フラグをチェックして、１商取引として売り上げる商品のなかにチケットが含まれるチケット取引であるか否かを判別する（ＳＴ５２）。
【００６２】
前記チケット取引フラグがセットされている場合、すなわちチケット取引の場合には（ＳＴ５２のＹＥＳ）、ＣＰＵ１１は、データバッファ６０に記憶されているチケット印字データをチケットプリンタ４０に出力して、チケットの発券を制御する（ＳＴ５３：有効化制御手段）。また、ＣＰＵ１１は、データバッファ６０に記憶されているチケットコードを含む発券完了コマンドを生成し、ストアサーバ５経由で、チケット管理サーバ５２に送信する（ＳＴ５４）。しかる後、ＣＰＵ１１は、ステップＳＴ５５の処理に進む。
【００６３】
前記チケット取引フラグがセットされていない場合、すなわちチケット取引でない場合には（ＳＴ５２のＮＯ）、ＣＰＵ１１は、上記ステップＳＴ５３，５４の処理を実行せずに、ステップＳＴ５５の処理に進む。
【００６４】
ステップＳＴ５５では、ＣＰＵ１１は、プリンタ２５を駆動して取引レシートを発行する。
【００６５】
このように、第４の実施形態において、チケットが発券されるのは、締めキーが操作されたことに応じて取引締め処理が実行されて、取引が確定した後である。したがって、第３の実施形態と同様に客が代金を支払った後に発券されるので、発券されたチケットが代金未収のまま店側に残るという問題はなくなる。
【００６６】
以下、前記実施形態の変形例について説明する。
前記第３または第４の実施形態においては、チケットの承認を問い合わせるための発券問合せコマンドを、チケットコードのバーコードをスキャニングしたときにチケット管理サーバ５２に送信した。この点に関し、第１または第２の実施形態のように、チケットコードのバーコードをスキャニングしたときにはそのチケットコードのデータをメモリに記憶し、締めキーが操作された後に、メモリに記憶したチケットコードで発券問合せコマンドを生成して、チケット管理サーバ５２に送信してもよい。この場合は、チケット印字データを記憶するためのデータバッファ６０が不要となる。ただし、第３または第４の実施形態のように構成することによって、締めキーが操作されてからチケットが発券されるまでの待ち時間を短縮できる効果を奏する。
【００６７】
また、前記各実施形態は、装置内部のＲＯＭに発明の機能を実現させる制御プログラムが予め記録されているものとした。しかしこれに限らず、同様のプログラムがネットワークから装置にダウンロードされてもよい。あるいは、記録媒体に記録された同様のプログラムが、装置にインストールされてもよい。記録媒体は、ＣＤ−ＲＯＭ，メモリカード等のようにプログラムを記憶でき、かつ装置が読み取り可能であれば、その形態は問わない。また、プログラムのインストールやダウンロードにより得る機能は、装置内部のＯＳ（オペレーティング・システム）等と協働してその機能を実現させるものであってもよい。
【００６８】
この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００６９】
１…ＰＯＳシステム、２…価値カードデータベース、３…価値カード管理サーバ、４…ＰＯＳ端末、５…ストアサーバ、８…価値カード、３０…有効化メモリ、４０…チケットプリンタ、５１…チケットデータベース、５２…チケット管理サーバ、６０…データバッファ。
【特許請求の範囲】
【請求項１】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段と、
前記売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の前記証明データを記憶する記憶部と、
前記記憶部で前記証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、前記記憶部で記憶している証明データを前記サーバに送信する証明データ送信手段と、
を具備したことを特徴とする商品販売データ処理装置。
【請求項２】
前記証明データ送信手段は、前記締めキーが操作されて商取引の締め処理が完了すると、前記証明データを前記サーバに送信することを特徴とする請求項１記載の商品販売データ処理装置。
【請求項３】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段と、
前記売上処理手段により処理した商品販売データのなかに、サーバで発券が承認されるとプリントアウトされるチケットの販売データが含まれるとき、そのチケットの発券に必要なデータを記憶する記憶部と、
前記記憶部で前記チケットの発券に必要なデータを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、前記記憶部で記憶しているデータに基づいてチケットプリンタを動作させて前記チケットを発券するチケット発券手段と、
を具備したことを特徴とする商品販売データ処理装置。
【請求項４】
前記チケット発券手段は、前記締めキーが操作されて商取引の締め処理が完了すると、前記チケットを発券することを特徴とする請求項３記載の商品販売データ処理装置。
【請求項５】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段及び商取引の決済を宣言する締めキーを備え、前記締めキーの操作を検知すると、前記売上処理手段により１商取引として売上処理された商品販売データを基に商取引の締め処理を実行する商品販売データ処理装置としてのコンピュータに、
前記売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の前記証明データを記憶部に記憶する機能と、
前記記憶部で前記証明データを記憶している状態で前記締めキーの操作を検知すると、前記記憶部で記憶している証明データを前記サーバに送信する機能と、
を実現させるための制御プログラム。
【請求項６】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段及び商取引の決済を宣言する締めキーを備え、前記締めキーの操作を検知すると、前記売上処理手段により１商取引として売上処理された商品販売データを基に商取引の締め処理を実行する商品販売データ処理装置としてのコンピュータに、
前記売上処理手段により処理した商品販売データのなかに、サーバで発券が承認されるとプリントアウトされるチケットの販売データが含まれるとき、そのチケットの発券に必要なデータを記憶部に記憶する機能と、
前記記憶部で前記チケットの発券に必要なデータを記憶している状態で前記締めキーの操作を検知すると、前記記憶部で記憶しているデータに基づいてチケットプリンタを動作させて前記チケットを発券する機能と、
を実現させるための制御プログラム。
【請求項１】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段と、
前記売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の前記証明データを記憶する記憶部と、
前記記憶部で前記証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、前記記憶部で記憶している証明データを前記サーバに送信する証明データ送信手段と、
を具備したことを特徴とする商品販売データ処理装置。
【請求項２】
前記証明データ送信手段は、前記締めキーが操作されて商取引の締め処理が完了すると、前記証明データを前記サーバに送信することを特徴とする請求項１記載の商品販売データ処理装置。
【請求項３】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段と、
前記売上処理手段により処理した商品販売データのなかに、サーバで発券が承認されるとプリントアウトされるチケットの販売データが含まれるとき、そのチケットの発券に必要なデータを記憶する記憶部と、
前記記憶部で前記チケットの発券に必要なデータを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、前記記憶部で記憶しているデータに基づいてチケットプリンタを動作させて前記チケットを発券するチケット発券手段と、
を具備したことを特徴とする商品販売データ処理装置。
【請求項４】
前記チケット発券手段は、前記締めキーが操作されて商取引の締め処理が完了すると、前記チケットを発券することを特徴とする請求項３記載の商品販売データ処理装置。
【請求項５】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段及び商取引の決済を宣言する締めキーを備え、前記締めキーの操作を検知すると、前記売上処理手段により１商取引として売上処理された商品販売データを基に商取引の締め処理を実行する商品販売データ処理装置としてのコンピュータに、
前記売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の前記証明データを記憶部に記憶する機能と、
前記記憶部で前記証明データを記憶している状態で前記締めキーの操作を検知すると、前記記憶部で記憶している証明データを前記サーバに送信する機能と、
を実現させるための制御プログラム。
【請求項６】
入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段及び商取引の決済を宣言する締めキーを備え、前記締めキーの操作を検知すると、前記売上処理手段により１商取引として売上処理された商品販売データを基に商取引の締め処理を実行する商品販売データ処理装置としてのコンピュータに、
前記売上処理手段により処理した商品販売データのなかに、サーバで発券が承認されるとプリントアウトされるチケットの販売データが含まれるとき、そのチケットの発券に必要なデータを記憶部に記憶する機能と、
前記記憶部で前記チケットの発券に必要なデータを記憶している状態で前記締めキーの操作を検知すると、前記記憶部で記憶しているデータに基づいてチケットプリンタを動作させて前記チケットを発券する機能と、
を実現させるための制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−１７３８５３（Ｐ２０１２−１７３８５３Ａ）
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願番号】特願２０１１−３３３１９（Ｐ２０１１−３３３１９）
【出願日】平成２３年２月１８日（２０１１．２．１８）
【出願人】（０００００３５６２）東芝テック株式会社 (5,631)
【Ｆターム（参考）】
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願日】平成２３年２月１８日（２０１１．２．１８）
【出願人】（０００００３５６２）東芝テック株式会社 (5,631)
【Ｆターム（参考）】
[ Back to top ]