"入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段と、前記売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の前記証明データを記憶する記憶部と、前記記憶部で前記証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、前記記憶部で記憶している証明データを前記サーバに送信する証明データ送信手段と、を具備したことを特徴とする商品販売データ処理装置。前記証明データ送信手段は、前記締めキーが操作されて商取引の締め処理が完了すると、前記証明データを前記サーバに送信することを特徴とする請求項1記載の商品販売データ処理装置。入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段と、前記売上処理手段により処理した商品販売データのなかに、サーバで発券が承認されるとプリントアウトされるチケットの販売データが含まれるとき、そのチケットの発券に必要なデータを記憶する記憶部と、前記記憶部で前記チケットの発券に必要なデータを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、前記記憶部で記憶しているデータに基づいてチケットプリンタを動作させて前記チケットを発券するチケット発券手段と、を具備したことを特徴とする商品販売データ処理装置。前記チケット発券手段は、前記締めキーが操作されて商取引の締め処理が完了すると、前記チケットを発券することを特徴とする請求項3記載の商品販売データ処理装置。入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段及び商取引の決済を宣言する締めキーを備え、前記締めキーの操作を検知すると、前記売上処理手段により1商取引として売上処理された商品販売データを基に商取引の締め処理を実行する商品販売データ処理装置としてのコンピュータに、前記売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の前記証明データを記憶部に記憶する機能と、前記記憶部で前記証明データを記憶している状態で前記締めキーの操作を検知すると、前記記憶部で記憶している証明データを前記サーバに送信する機能と、を実現させるための制御プログラム。入力された買上商品のデータに基づいて商品販売データを売上処理する売上処理手段及び商取引の決済を宣言する締めキーを備え、前記締めキーの操作を検知すると、前記売上処理手段により1商取引として売上処理された商品販売データを基に商取引の締め処理を実行する商品販売データ処理装置としてのコンピュータに、前記売上処理手段により処理した商品販売データのなかに、サーバで発券が承認されるとプリントアウトされるチケットの販売データが含まれるとき、そのチケットの発券に必要なデータを記憶部に記憶する機能と、前記記憶部で前記チケットの発券に必要なデータを記憶している状態で前記締めキーの操作を検知すると、前記記憶部で記憶しているデータに基づいてチケットプリンタを動作させて前記チケットを発券する機能と、を実現させるための制御プログラム。従来のPOS端末は、価値カードのカードIDが入力されると、そのカードを購入する客が代金を支払う前に、そのカードが正規に販売されたことの証明データカードIDをサーバに送信していた。このため、例えば財布を忘れた等の理由から客が代金の支払いを取り止めた場合、有効化された状態のカードが代金未収のまま店側に残るという問題が生じる。このようなことは、インターネットを利用して客が事前にコンサートや演劇等の入場券であるチケットの購入権を獲得し、その代金をコンビニエンスストア等の店舗で支払うと、チケットを入手できるようなチケット販売形式の場合にも生じる。例えば、チケットの購入権を獲得していることを証明するデータが客から提示され、当該データを読み取ると当該チケットの発券を行ない、代金の支払いを求める。この場合、客が代金を支払う前にチケットが発券されるため、客が代金の支払いを取り止めた場合に、発券により有効となったチケットが代金未収のまま店側に残ってしまう。本発明が解決しようとする課題は、代金の支払い受け前に商品を有効化することを防止できる商品販売データ処理装置及びその制御プログラムを提供しようとするものである。かかる課題を解決するために、一実施形態の商品販売データ処理装置は、売上処理手段と、記憶部と、証明データ送信手段とを備える。売上処理手段は、入力された買上商品のデータに基づいて商品販売データを売上処理する。記憶部は、売上処理手段により処理した商品販売データのなかに、その商品の販売に際し正規に販売されたことの証明データをサーバに送信することが求められる商品の販売データが含まれるとき、その商品の証明データを記憶する。証明データ送信手段は、記憶部で証明データを記憶している状態で商取引の決済を宣言する締めキーの操作を検知すると、記憶部で記憶している証明データをサーバに送信する。以下、商品販売データ処理装置の実施形態を、図面を用いて説明する。[第1の実施形態]はじめに、価値カードの販売店に適用する第1の実施形態について、図1~図7を用いて説明する。図1は、第1の実施形態のシステム構成図である。本システムは、各店舗にそれぞれ構築されるPOSシステム1と、価値カードデータベース2を管理する価値カード管理サーバ3とからなる。POSシステム1は、商品販売データ処理装置として機能する複数台のPOS端末4と、各POS端末4を一元的に管理するストアサーバ5とからなり、各POS端末4とストアサーバ5とは、LANLocalAreaNetwork6によって接続されている。各店舗のPOSシステム1のストアサーバ5と前記価値カード管理サーバ3とは、インターネット等のネットワーク回線7によって接続されている。図2に示すように、本実施形態で使用される価値カード8には、バーコード9が印刷されている。バーコード9は、当該価値カード8を一意に識別するためのカードIDをバーコードシンボル化したものである。価値カードデータベース2は、図3に示すように、各価値カード8のカードIDに対応させて、価値情報とステータスフラグとを記憶する。価値情報は、対応するカードIDによって特定される価値カード8で支払いが可能な金額である。ステータスフラグは、例えば0は無効状態を示し、1は有効状態を示す。なお、価値情報は、金額に限定されない。1ポイントあたりの金額を可変設定可能なポイントであってもよい。図4は、POS端末4の要部構成を示すブロック図である。POS端末4は、制御部本体としてCPUCentralProcessingUnit11を搭載している。そしてこのCPU11に、アドレスバス,データバス等のバスライン12を介して、ROMReadOnlyMemory13、RAMRandomAccessMemory14、時計部15、LANコントローラ16、キーボードコントローラ17、表示コントローラ18、表示コントローラ19、プリンタコントローラ20、スキャナコントローラ21等を接続して、POS端末4の制御回路を構成している。ROM13は、CPU11にPOS端末4としての機能を実現させるためのプログラムを記憶する。また、ROM13は、POS端末4としての機能を実現するために必要な種々の設定データを記憶する。RAM14は、可変的なデータを一時的に記憶するためのメモリエリアを形成している。特に、図5に示すように、価値カード8の有効化要求に必要なデータを記憶する記憶部として、カードID、取引日時、店舗ID、POSIDを記憶する有効化メモリ30を形成している。店舗IDは、当該POS端末4が稼動している店舗を識別するために予めROM13に設定された店舗固有のデータである。POSIDは、同一店舗で稼動している各POS端末4を識別するために予めROM13に設定された端末固有のデータである。時計部15は、現在の日付及び時刻を計時する。LANコントローラ16は、LAN6で接続されたストアサーバ5との間のデータ送受信を制御する。キーボードコントローラ17は、キーボード22を制御し、操作キーに対応したキー信号を取り込む。キーボード22は、置数キー、小計キー、締めキー、取消キー等のPOS端末4としての機能に必要な種々のキーを配設したものである。表示コントローラ18は、オペレータ用ディスプレイ23の画面表示を制御する。表示コントローラ19は、客用ディスプレイ24の画面表示を制御する。オペレータ用ディスプレイ23は、キャッシャと呼ばれるPOS端末4のオペレータに対して提供する情報の画面を表示する。客用ディスプレイ24は、決済対象の商品を購入する客に対して提供する情報の画面を表示する。プリンタコントローラ20は、レシート用紙にデータを印字するためのプリンタ25を制御し、領収書レシート等を発行させる。スキャナコントローラ21は、商品に付されるバーコードを光学的に読み取るためのスキャナ26を制御し、読み取られたバーコードデータを取り込む。かかる構成のPOS端末4を操作するキャッシャは、客が買上商品の会計を申し出ると、その買上商品に付されているバーコードを1品ずつスキャナ26で読み取り操作する。スキャナ26で買上商品のバーコードが読み取られると、CPU11は、図6の流れ図に示す手順のスキャニング処理を実行する。なお、この処理は、ROM13に記憶された制御プログラムに基づくものである。先ず、CPU11は、スキャニングされたバーコードが、価値カード8に印刷されたバーコード、すなわちカードIDであるか否かを判断する。例えば、価値カード8に設定されるカードIDは、全て先頭の2桁の数値が等しい。そこでCPU11は、スキャニングされたバーコードの先頭の2桁が価値カード8特有の数値と一致するか否かを判断する。バーコードの先頭の2桁が価値カード8特有の数値と一致しない場合、CPU11は、買上商品の販売データを売上処理するST4:売上処理手段。具体的には、CPU11は、バーコードを解析して得られる商品コードで商品データファイルを検索して、販売商品の品名,単価等の商品データを読み出す。そしてCPU11は、この商品データを基に、商品コード.販売点数,販売金額等の販売商品に係わるトランザクションデータをトランザクションバッファに記憶する。またCPU11は、商品コード,商品名,単価,販売点数,販売金額等の明細データをオペレータ用ディスプレイ23及び客用ディスプレイ24に表示する。バーコードの先頭の2桁が価値カード8特有の数値と一致する場合、CPU11は、そのバーコードを解析して得られる商品コード、つまりはカードIDと、時計部15で計時されている現在日時、つまりは取引日時と、予め設定された店舗ID及びPOSIDとを有効化メモリ30に記憶するST2。ここに、有効化メモリ30は、商品である価値カード8の販売に際し正規に販売されたことの証明データであるカードIDを記憶する記憶部を構成する。次いで、CPU11は、RAM14のフラグエリアで記憶する価値カード取引フラグを1にセットするST3。価値カード取引フラグは、1商取引として売り上げる商品のなかに価値カードが含まれるか否かを識別する情報であって、含まれる場合に1にセットされる。しかる後、CPU11は、この価値カードの販売データを売上処理するST4:売上処理手段。キャッシャは、客が買い上げる商品の売上処理を終了すると、小計キーを入力する。そうすると、1商取引の売上データとしてトランザクションバッファに記憶された商品販売データを基に合計金額が算出されてオペレータ用ディスプレイ23及び客用ディスプレイ24に表示されるので、キャッシャは、客に代金の支払い代金の請求を求める。そして代金の支払い代金の徴収を受けると、キャッシャは、締めキーを操作する。締めキーの操作が検知されると、CPU11は、図7の流れ図に示す処理を実行する。なお、この処理も、ROM13に記憶された制御プログラムに基づくものである。先ず、CPU11は、前記価値カード取引フラグをチェックして、1商取引として売り上げる商品のなかに価値カードが含まれる価値カード取引であるか否かを判別するST11。前記価値カード取引フラグがセットされている場合、すなわち価値カード取引の場合にはST11のYES、CPU11は、有効化メモリ30に記憶されているカードIDで識別される価値カード8の有効化を要求する。すなわち、カードIDを含む有効化要求問合せコマンドを生成し、ストアサーバ5経由で、価値カード管理サーバ3に送信するST12:証明データ送信手段。しかる後、CPU11は、ステップST13の処理に進む。価値カード管理サーバ3は、有効化要求コマンドを受信すると、価値カードデータベース2を検索する。そして、有効化要求コマンドに含まれるカードIDに対応するステータスフラグを、無効を示す0から有効を示す1に変更する。前記価値カード取引フラグがセットされていない場合、すなわち価値カード取引でない場合にはST11のNO、CPU11は、上記ステップST12の処理を実行せずに、ステップST13の処理に進む。ステップST13では、CPU11は、取引締め処理を実行する。この処理は、釣銭演算及び釣銭表示と、合計金額,預かり金額,釣銭額、取引日時、取引番号、POSID等の決済に係わるトランザクションデータの保存とを含む。取引締め処理が終了すると、CPU11は、プリンタ25を駆動して取引レシートを発行するST14。このように構成された第1の実施形態のPOS端末4においては、価値カード8のバーコードデータをスキャナ26でスキャニングすると、その価値カード8の証明データであるカードIDを含むデータが、有効化メモリ30に記憶される。そして、この価値カード8を購入する客との商取引の決済を宣言する締めキーが操作されると、有効化メモリ30で記憶しているデータに基づいて、価値カード8の有効化要求コマンドが価値カード管理サーバ3に送信されて、価値カード8が有効化される。このように、第1の実施形態において、価値カード8が有効化されるのは、締めキーが操作された後、つまりは客が代金を支払った後である。したがって、客が代金の支払いを取り止めた場合に有効化された価値カードが代金未収のまま店側に残るという問題はなくなる。[第2の実施形態]次に、第2の実施形態について説明する。第2の実施形態が第1の実施形態と異なる点は、POS端末4のCPU11が実行する締めキー処理の手順である。その他は第1の実施形態と同様なので、図1~図6までは第1の実施形態と共通に使用し、その説明は省略する。図8は、第2の実施形態における締めキー処理の手順を示す流れ図である。1商取引として売上げる商品の販売データが売上げ処理され、続いて、この1取引の締めキーが押下されると、CPU11は、先ず、取引締め処理を実行するST21。次いで、CPU11は、前記価値カード取引フラグをチェックして、1商取引として売り上げる商品のなかに価値カードが含まれる価値カード取引であるか否かを判別するST22。前記価値カード取引フラグがセットされている場合、すなわち価値カード取引の場合にはST22のYES、CPU11は、有効化メモリ30に記憶されているカードIDで識別される価値カード8の有効化を要求する。すなわち、カードIDを含む有効化要求問合せコマンドを生成し、ストアサーバ5経由で、価値カード管理サーバ3に送信するST23:証明データ送信手段。しかる後、CPU11は、ステップST24の処理に進む。前記価値カード取引フラグがセットされていない場合、すなわち価値カード取引でない場合にはST22のNO、CPU11は、上記ステップST23の処理を実行せずに、ステップST24の処理に進む。ステップST24では、CPU11は、プリンタ25を駆動して取引レシートを発行する。このように、第2の実施形態において、価値カード8が有効化されるのは、締めキーが操作されたことに応じて取引締め処理が実行されて、取引が確定した後である。したがって、第1の実施形態と同様に客が代金を支払った後に価値カード8が有効となるので、有効化された価値カードが代金未収のまま店側に残るという問題はなくなる。[第3の実施形態]次に、店舗にて会計を済ますことによって有効となるコンサート,演劇等のチケット類を発券する店に適用する第3の実施形態について、図9~図13を用いて説明する。なお、第1の実施形態と共通する部分には同一の符号を付し、重複する説明は省略する。図9は、第3の実施形態のシステム構成図である。本システムは、各店舗にそれぞれ構築されるPOSシステム1と、チケットデータベース51を管理するチケット管理サーバ52とからなる。各店舗のPOSシステム1のストアサーバ5と前記チケット管理サーバ52とは、インターネット等のネットワーク回線7によって接続されている。POSシステム1は、前記チケットの印刷に特化したチケットプリンタ40を含む。チケットプリンタ40は、LAN6に接続されており、各POS端末4からLAN6を介してチケット印字データを受信すると、チケットを発券する。チケットデータベース51は、図10に示すように、インターネット等を利用して客が予約をしたコンサート,演劇等のチケットを個々に識別するチケットコードに対応して、そのチケットを印字するためのチケット印字データと、チケットの発券期限日を特定するデータと、発券済であるか否かを識別するためのステータスフラグとを記憶する。ステータスフラグは、例えば0は未発券状態を示し、1は発券済状態を示す。なお、チケットコードは、客がチケットを予約した際に印刷可能となる引換え票に、バーコードまたは二次元データコードの形式で印刷されている。あるいは、携帯電話等の携帯型通信機器のディスプレイに、バーコードまたは二次元データコードの形式で表示可能としてもよい。各POS端末4のRAM14には、特に、図11に示すように、チケット管理サーバ52から受信したチケット印字データを、そのチケット印字テータを識別するためのチケットコードとともに記憶するためのデータバッファ60を形成している。かかる構成のPOS端末4を操作するキャッシャは、客が買上商品の会計を申し出ると、その買上商品に付されているバーコードを1品ずつスキャナ26で読み取り操作する。スキャナ26で買上商品のバーコードが読み取られると、CPU11は、図12の流れ図に示す手順のスキャニング処理を実行する。なお、この処理は、ROM13に記憶された制御プログラムに基づくものである。先ず、CPU11は、スキャニングされたバーコードが、チケットコードのバーコードであるか否かを判断する。例えば、チケットコードは、全て先頭の2桁の数値が等しい。そこでCPU11は、スキャニングされたバーコードの先頭の2桁がチケットコード特有の数値と一致するか否かを判断するST31。バーコードの先頭の2桁がチケットコード特有の数値と一致しない場合ST31のNO、CPU11は、買上商品の販売データを売上処理するST36:売上処理手段。バーコードの先頭の2桁がチケットコード特有の数値と一致する場合ST31のYES、CPU11は、そのバーコードから得られるチケットコードのチケット発券を問い合わせる。すなわち、チケットコードを含む発券問合せコマンドを生成し、ストアサーバ5経由で、チケット管理サーバ52に送信する。チケット管理サーバ52は、発券問合せコマンドを受信すると、チケットデータベース51を検索する。そして、発券問合せコマンドに含まれるチケットコードに対応するフラグが未発券を示す0にリセットされていること、及び、発券期限が経過していないことを確認すると、チケットの発券を承認する。フラグが発券済を示す1にセットされているとき、あるいは、発券期限が経過している場合には、チケットの発券を承認しない。チケットの発券を承認する場合、チケット管理サーバ52は、そのチケットコードに対応するチケット印字データを、チケットコードとともにコマンド送信元のPOS端末4に返信する。発券問合せコマンドを送信したPOS端末4のCPU11は、チケット印字データの受信を待機するST33。コマンド送信から所定時間が経過してもチケット印字データを受信できない場合にはST33のNO、今回のチケットコードの入力をエラーとする。チケット印字データを受信するとST33のYES、CPU11は、このチケット印字データをチケットコードとともにデータバッファ60に記憶する。また、RAM14のフラグエリアで記憶するチケット取引フラグを1にセットするST35。チケット取引フラグは、1商取引として売り上げる商品のなかにチケットが含まれるか否かを識別する情報であって、含まれる場合に1にセットされる。しかる後、CPU11は、このチケットの販売データを売上処理するST36:売上処理手段。キャッシャは、客が買い上げる商品の売上処理を終了すると、小計キーを入力する。そうすると、1商取引の売上データとしてトランザクションバッファに記憶された商品販売データを基に合計金額が算出されてオペレータ用ディスプレイ23及び客用ディスプレイ24に表示されるので、キャッシャは、客に代金の支払い代金の請求を求める。そして代金の支払い代金の徴収を受けると、キャッシャは、締めキーを操作する。締めキーが操作されたことを検知すると、CPU11は、図13の流れ図に示す処理を実行する。なお、この処理も、ROM13に記憶された制御プログラムに基づくものである。先ず、CPU11は、前記チケット取引フラグをチェックして、1商取引として売り上げる商品のなかにチケットが含まれるチケット取引であるか否かを判別するST41。前記チケット取引フラグがセットされている場合、すなわちチケット取引の場合にはST41のYES、CPU11は、データバッファ60に記憶されているチケット印字データを、LANコントローラ16を介してチケットプリンタ40に出力して、チケットの発券を制御するST42:チケット発券手段。また、CPU11は、データバッファ60に記憶されているチケットコードを含む発券完了コマンドを生成し、ストアサーバ5経由で、チケット管理サーバ52に送信するST43。しかる後、CPU11は、ステップST44の処理に進む。チケット管理サーバ52は、発券完了コマンドを受信すると、チケットデータベース51を検索する。そして、発券完了コマンドに含まれるチケットコードに対応するステータスフラグを、未発券を示す0から発券済を示す1に変更する。前記チケット取引フラグがセットされていない場合、すなわちチケット取引でない場合にはST41のNO、CPU11は、上記ステップST42,43の処理を実行せずに、ステップST44の処理に進む。ステップST44では、CPU11は、取引締め処理を実行する。取引締め処理が終了すると、CPU11は、プリンタ25を駆動して取引レシートを発行するST45。このように構成された第3の実施形態のPOS端末4においては、チケットコードのバーコードデータをスキャナ26でスキャニングすると、そのチケットコードで識別されるチケットの発券承認をチケット管理サーバに52に問い合わせる。そして、発券が承認され、チケット印字データを受信すると、そのチケット印字データを、データバッファ60に記憶する。そして、このチケットを購入する客との商取引の決済を宣言する締めキーの操作を検知すると、データバッファ60で記憶しているチケット印字データに基づいて、チケットプリンタ40からチケットが発券されて、チケットが有効なものとなる。このように、第3の実施形態において、チケットが発券されて有効となるのは、締めキーが操作された後、つまりは客が代金を支払った後である。したがって、客が代金の支払いを取り止めた場合に発券済のチケットが代金未収のまま店側に残るという問題はなくなる。[第4の実施形態]次に、第4の実施形態について説明する。第4の実施形態が第3の実施形態と異なる点は、POS端末4のCPU11が実行する締めキー処理の手順である。その他は第3の実施形態と同様なので、図9~図12までは第3の実施形態と共通に使用し、その説明は省略する。図14は、第4の実施形態における締めキー処理の手順を示す流れ図である。1商取引として売上げる商品の販売データが売上げ処理され、続いて、この1取引に対して締めキーの操作を検知すると、CPU11は、先ず、取引締め処理を実行するST51。次いで、CPU11は、前記チケット取引フラグをチェックして、1商取引として売り上げる商品のなかにチケットが含まれるチケット取引であるか否かを判別するST52。前記チケット取引フラグがセットされている場合、すなわちチケット取引の場合にはST52のYES、CPU11は、データバッファ60に記憶されているチケット印字データをチケットプリンタ40に出力して、チケットの発券を制御するST53:有効化制御手段。また、CPU11は、データバッファ60に記憶されているチケットコードを含む発券完了コマンドを生成し、ストアサーバ5経由で、チケット管理サーバ52に送信するST54。しかる後、CPU11は、ステップST55の処理に進む。前記チケット取引フラグがセットされていない場合、すなわちチケット取引でない場合にはST52のNO、CPU11は、上記ステップST53,54の処理を実行せずに、ステップST55の処理に進む。ステップST55では、CPU11は、プリンタ25を駆動して取引レシートを発行する。このように、第4の実施形態において、チケットが発券されるのは、締めキーが操作されたことに応じて取引締め処理が実行されて、取引が確定した後である。したがって、第3の実施形態と同様に客が代金を支払った後に発券されるので、発券されたチケットが代金未収のまま店側に残るという問題はなくなる。以下、前記実施形態の変形例について説明する。前記第3または第4の実施形態においては、チケットの承認を問い合わせるための発券問合せコマンドを、チケットコードのバーコードをスキャニングしたときにチケット管理サーバ52に送信した。この点に関し、第1または第2の実施形態のように、チケットコードのバーコードをスキャニングしたときにはそのチケットコードのデータをメモリに記憶し、締めキーが操作された後に、メモリに記憶したチケットコードで発券問合せコマンドを生成して、チケット管理サーバ52に送信してもよい。この場合は、チケット印字データを記憶するためのデータバッファ60が不要となる。ただし、第3または第4の実施形態のように構成することによって、締めキーが操作されてからチケットが発券されるまでの待ち時間を短縮できる効果を奏する。また、前記各実施形態は、装置内部のROMに発明の機能を実現させる制御プログラムが予め記録されているものとした。しかしこれに限らず、同様のプログラムがネットワークから装置にダウンロードされてもよい。あるいは、記録媒体に記録された同様のプログラムが、装置にインストールされてもよい。記録媒体は、CD-ROM,メモリカード等のようにプログラムを記憶でき、かつ装置が読み取り可能であれば、その形態は問わない。また、プログラムのインストールやダウンロードにより得る機能は、装置内部のOSオペレーティングシステム等と協働してその機能を実現させるものであってもよい。この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。"