JP2006209463A - カード活用システム - Google Patents

Abstract

【課題】 代金支払い時に細かな釣銭を不要にすると共に、自動的に貯蓄額を増加させることもできるカード活用システムを提供する。
【解決手段】 代金支払い時に、会員各自が所有するカードからカード情報を読み取る信用照会端末Ｔ１〜Ｔｊと、通信回線ＮＥＴを通して、信用照会端末Ｔ１〜Ｔｊと中央処理装置Ｍ１〜Ｍｉを経由して接続される貯蓄管理装置ＳＶと、貯蓄管理装置ＳＶとインターネット回線を通して直接的に接続される会員所有のパソコンＰＣ１〜ＰＣｎとを備える。貯蓄管理装置ＳＶには、本来の支払い代金を切り上げた決済代金と、前記切り上げられた金額と会員種別に応じて決定されるポイントとを記憶する貯蓄管理テーブルＴＢＬ３と、パソコンＰＣ１〜ＰＣｎからの依頼内容を一時記憶する依頼管理テーブルＴＢＬ４とが会員毎に設けられている。
【選択図】 図１

Description

本発明は、信販会社が発行するクレジットカードや、各店舗が発行するポイントカードを利用して、有効な貯蓄や便利な買い物を実現するカード活用システムに関する。

現在、日本で普及しているクレジットカードとしては、VISA、MASTER CARD、JCB、American Express（各々登録商標）などの著名ブランドが知られている。このようなクレジットカードの保有者は、日本で約８８００万人と言われており、１８歳以上の９割弱が保有していることになる。

しかし、日本人のクレジッドカードの利用率は、消費型のアメリカ人などに比べると決して高くなく、若年層を除けば、殆ど利用しないカード所持者も少なくない。特に、クレジットカードの利用状況は、銀行からの現金引落し処理に対応して、月単位でしか利用者に知らされないので、貯蓄好きで堅実な性格の多い日本人にとって、少なからず抵抗感を覚えるものであった。そこで、かかる日本人の特性に合わせたクレジットカードの活用法が強く望まれるところである。

ところで、スーパーマーケットなどでの一般の買い物では、クレジットカードを使用することが稀であり、日本では、もっぱら現金での支払いを行っている。そして、各商品には数パーセントの消費税が加算されるため、支払い時に一円玉を用意する必要が生じ、そのための買い物客やレジ係員の手間に起因して、時として、支払い待ちの長い行列ができるのが実情である。なお、かかる釣銭問題を解消するため、特許文献１や特許文献２の提案もあるが、現実的な有効性に欠け、全く普及していない。
特開平６−１３１５３６ 特開２００４−２３４０９１

上記した種々の実情を踏まえると、クレジットカードをより日本人にとって身近なものに普及させ、常に釣銭を不要にする買い物を実現できるのが理想的である。但し、全ての買い物にクレジットカードを適用するのは日本では現実的ではないので、貯蓄型の日本人に馴染みやすいシステムの構築が望まれる。

本発明は、上記の着想に基づくものであって、代金支払い時に細かな釣銭を不要にすると共に、自動的に貯蓄額を増加させることもできるカード活用システムを提供することを課題とする。

上記目的を達成するために、本発明に係るカード活用システムは、代金支払い時に、会員各自が所有するカードからカード情報を読み取るカード端末と、通信回線を通して、前記カード端末と直接的又は間接的に接続される管理コンピュータ装置と、前記管理コンピュータ装置と通信回線を通して直接的に接続される会員所有の端末コンピュータ装置とを備え、前記管理コンピュータ装置には、(a)本来の支払い代金を切り上げた決済代金、及び、前記切り上げられた金額と会員種別に応じて決定されるポイントを記憶する貯蓄管理テーブルと、(b)前記端末コンピュータ装置からの依頼内容を一時記憶する依頼管理テーブルとが会員毎に設けられている。

前記管理コンピュータ装置は、好ましくは、前記端末コンピュータ装置からの要求に応じて、前記貯蓄管理テーブルの内容を返送するよう構成されている。また、前記管理コンピュータ装置は、中央処理装置を経由して前記カード端末に接続され、前記中央処理装置では、本来の支払い代金を切り上げた決済代金と、前記切り上げられた金額と会員種別に応じて決定されるポイントとを決定しているのが好ましい。前記カードは、典型的にはクレジットカードであり、前記中央処理装置は、カード会社毎に設けられている。

また、本発明は、請求項１〜４の何れかに記載のシステムで使用されるコンピュータ装置、請求項１〜４の何れかに記載のシステムで使用されるカード、請求項１〜４の何れかに記載のシステムで使用されるプログラムでもある。

以上説明した本発明によれば、代金支払い時に細かな釣銭を不要にすると共に、自動的に貯蓄額を増加させることもできるカード活用システムを実現できる。

以下、実施例に基づいて、本発明を更に詳細に説明する。図１は、本発明の第１実施例の貯蓄システムＳＹＳ１を示すブロック図である。この貯蓄システムＳＹＳ１は、クレジットカード（以下、カードと略すことがある）の利用時に、支払い金額の端数を自動的に貯蓄できると共に、その貯蓄額に応じた特典が得られるシステムである。また、このシステムＳＹＳ１によれば、カード利用者は、カードの利用状況を何時でも簡単にインターネット環境下で把握することができる。

図１に示す通り、この貯蓄システムＳＹＳ１は、カード決済処理などを行う中央処理装置Ｍ１〜Ｍｉと、カード会社の加盟店にそれぞれ配置される信用照会端末(ＣＡＴ：Credit Authorization Terminal)Ｔ１〜Ｔｊと、カード利用者の貯蓄額を一元管理する貯蓄管理装置ＳＶと、個々のカード利用者が保有するコンピュータ装置（典型的にはパソコン）ＰＣ１〜ＰＣｎとが、通信回線ＮＥＴを介して接続されて構成されている。

中央処理装置Ｍ１〜Ｍｉは、カード会社それぞれに設けられており、各信用照会端末Ｔ１〜Ｔｊは、対応する中央処理装置Ｍ１〜Ｍｉとの間が、専用回線によって接続されている。また、全ての中央処理装置Ｍ１〜Ｍｉは、別の専用回線によって貯蓄管理サーバＳＶに接続されていて、定期的に必要な情報を送受信するようになっている。一方、コンピュータ装置ＰＣ１〜ＰＣｎと貯蓄管理装置ＳＶとは、インターネット回線によって接続されていて、カード利用者は何時でも貯蓄管理装置ＳＶにアクセスできるようになっている。

この貯蓄システムＳＹＳ１を利用できるのは、クレジットカードの所有者のうち、この貯蓄サービスを受けることをカード会社に希望して、支払金額の端数を切り上げることに同意している特別会員である。このような特別会員がクレジッドカードを使用すると、カード決済時に端数金額が、中央処理装置Ｍ１〜Ｍｉにおいて切り上げ処理され、その切り上げ分の金額が当該特別会員の名義で自動的に貯蓄される。

切り上げ処理される端数金額の設定は、各特別会員の判断に委ねられており、この実施例では、１０円未満の端数の切り上げるＡ会員と、５０円未満の端数の切り上げるＢ会員と、１００円未満の端数の切り上げるＣ会員と、１０００円未満の端数の切り上げるＳ会員と、５０００円未満の端数の切り上げるＳＳ会員とに区分される。

例えば、税込み６１３５円の買い物をした場合、Ａ会員には５円切り上げ処理されて６１４０円の決済となり、Ｂ会員には１５円切り上げ処理されて６１５０円の決済となり、Ｃ会員には６５円切り上げ処理されて６２００円の決済となり、Ｓ会員には８６５円切り上げ処理されて７０００円の決済となり、ＳＳ会員には３８６５円切り上げ処理されて１００００円の決済となる。そして、貯蓄額は、Ａ会員、Ｂ会員、Ｃ会員、Ｓ会員、ＳＳ会員に対して、それぞれ、５円、１５円、６５円、８６５円、３８６５円が加算される。

各中央処理装置Ｍ（Ｍ１〜Ｍｉ）は、カード決済処理と貯蓄交信処理とを行うコンピュータ装置であり、加盟店の信用照会端末Ｔ（Ｔ１〜Ｔｊ）に対する中央処理装置として機能すると共に、貯蓄管理装置ＳＶに対する交信端末として機能する。この中央処理装置Ｍは、カード決済を実現するデータベースＤＢに接続されているが、このデータベースＤＢには、信用照会端末Ｔから受けた売買情報や、貯蓄管理装置ＳＶから受けた依頼情報を記憶する使用実績管理テーブルＴＢＬ１と、切り上げ金額と貯蓄ポイントとの換算比を規定する換算テーブルＴＢＬ２とが設けられている。

図２（ａ）は、使用実績管理テーブルＴＢＬ１を例示したものである。図示の通り、使用実績管理テーブルＴＢＬ１は、会員氏名、会員種別、会員ＩＤなどのプライベート情報を特定して、会員毎に設けられている。会員種別は、本実施例では、Ａ，Ｂ，Ｃ，Ｓ，ＳＳに区分されているが、この会員種別の欄がブランクである会員は、特別会員ではないことを意味する。したがって、本実施例では、特別会員であるか否かに拘わらず、統一した使用実績管理テーブルＴＢＬ１を使用できる利点がある。また、クレジットカードそのものにも、特別な記憶データを追加する必要もない。なお、使用実績管理テーブルＴＢＬ１の会員ＩＤとしても、各クレジットカードに刻印されているクレジットカード番号を使用するのが簡易的である。

この使用実績管理テーブルＴＢＬ１は、会員種別、決済年月日、加盟店で処理された売買代金、決済代金、貯蓄金額、及び貯蓄ポイントを、その他の必要事項と共に記憶可能に構成されている。ここで、売買代金とは、カードを使用したカード加盟店の売上伝票に記入される金額と同一額であり、必要な消費税や地方税などを加味した金額である。一方、決済代金とは、売買代金から、会員種別に応じた端数を切り上げた金額である。そして、決済代金と売買代金の差額が貯蓄金額であり、この貯蓄金額に基づいて換算テーブルＴＢＬ２を参照して算出される値が貯蓄ポイントである。なお、会員種別を他の情報と共に記憶するのは、本システムＳＹＳ１では、カード取得時に決定される会員種別が、その後の本人の申告に応じて自由に変更可能だからである。

図２（ｂ）は、ポイント換算テーブルＴＢＬ２を例示したものである。図示の通り、貯蓄金額と貯蓄ポイントとの換算比は、会員種別毎に規定されており、且つ、貯蓄金額が増加する毎に、換算比率が増加するように設定されている。ここで、換算テーブルＴＢＬ２を設けることなく、定型的なポイント換算式を使用しても良いが、本実施例のように、換算テーブルＴＢＬ２を用いることによって、きめ細かな換算比率を任意に設定できる利点がある。なお、換算テーブルＴＢＬ２又は簡易的にはポイント換算式による換算処理を、貯蓄管理装置ＳＶに委ねても良いが、中央処理装置Ｍ１〜Ｍｉで処理することによって、カード会社毎の独自のサービスや、サービス内容の変更が容易となる。

ところで、決済代金と売買代金の差額と、貯蓄金額とを、必ずしも一致させる必要はない。そこで、図２（ｂ）と同様の貯蓄換算テーブルＴＢＬ２’によって利子αを特定して、貯蓄金額＝（１＋α）×（決済代金−売買代金）の貯蓄額としても良い。なお、この場合の利子αとしては、例えば、長期金利より３％増加させるよう定式化しても良い。

一方、貯蓄管理装置ＳＶは、中央処理装置Ｍと一日一回専用回線を通して交信して、使用実績管理テーブルＴＢＬの新規データを受け取る貯蓄処理サーバとして機能すると共に、特別会員のパソコンＰＣからの要求に応じて必要なデータを送信する照会処理サーバとして機能している。なお、この照会処理サーバは、単にＨＴＭＬデータを特別会員に配信するだけでなく、特別会員パソコンＰＣからＰＯＳＴデータとして送信される依頼データを受け取る機能も持っている。ここで、依頼データとは、貯蓄ポイントの清算依頼や、会員種別の変更依頼を特定するＨＴＴＰ上の文字データである。

この貯蓄管理装置ＳＶは、管理業務を実現するためにデータベースＤＢｓに接続されているが、図３（ａ）は、データベースＤＢｓに設けられた貯蓄管理テーブルＴＢＬ３を例示したものである。図示の通り、貯蓄管理テーブルＴＢＬ３は、会員氏名、会員種別、会員ＩＤなどのプライベート情報を特定して、会員毎に設けられている。

その他の内容は、中央処理装置Ｍの使用実績管理テーブルＴＢＬ１の内容と同じである。先に説明した通り、中央処理装置Ｍは、専用回線を使用して毎日一回、貯蓄管理装置ＳＶを呼び出しており、この時の交信内容に応じて、貯蓄管理テーブルＴＢＬ３に最新の内容が追加される。図２（ａ）の使用実績管理テーブルＴＢＬ１が２００５年１月２０日段階のものであるのに対して、同じ内容を有する図３（ａ）の貯蓄管理テーブルＴＢＬ３が、２００５年１月２１日段階となっているのは、中央処理装置Ｍと貯蓄管理装置ＳＶの交信処理（２００５年１月２１日に実行）を経てから、貯蓄管理テーブルＴＢＬ３が書き換えられるからである。

図３（ｂ）は、特別会員のパソコンＰＣから、インターネット回線を通して各種の依頼を受けた場合に、その内容を記憶する依頼管理テーブルＴＢＬ４を例示したものである。依頼管理テーブルＴＢＬ４には、受付年月日、依頼内容、清算ポイント、会員種別の記入欄が設けられており、また完了フラグ欄が設けられている。ここで完了フラグは、依頼管理テーブルＴＢＬ４の内容が、貯蓄管理テーブルＴＢＬ３や使用実績管理テーブルＴＢＬ１に反映されたことを示すデータである。この例では、２００５年１月１５日段階の依頼管理テーブルＴＢＬ４が示されているので、当日受け付けた依頼内容は未処理状態である。

以下、例示された依頼管理テーブルＴＢＬ４の内容を説明すると、特別会員○○××は、２００３年１０月３日に、自己の貯蓄ポイントを６５００ポイント使用して「痩身セット」と交換することを希望している。また、２００３年１２月９日に、Ｂ会員からＣ会員への変更を希望している。なお、この変更希望は、翌日の１２月１０日に使用実績管理テーブルＴＢＬ１と貯蓄管理テーブルＴＢＬ３に登録されており、それ以降はＣ会員として取り扱われている。

更にまた、２００５年１月１５日には、それまでの貯蓄金額のうち５０００円については現金で清算したい旨を希望している。この依頼は、翌日の１月２０日には実効化され、使用実績管理テーブルＴＢＬ１と貯蓄管理テーブルＴＢＬ３に反映される。

そして、その後、この特別会員は、２００５年１月２０日に２８５０円の買い物をしているが、本人の希望通り、それまでの貯蓄金額から２８５０円が取り崩されている。そのため、１月２０日の売買では、貯蓄金額が−２８５０円となり、貯蓄ポイントが−３２００となっている。これらの点は、図２（ａ）の使用実績管理テーブルＴＢＬ１と、図３（ａ）の貯蓄管理テーブルＴＢＬ３に記載の通りである。なお、この１月２０日の買い物に対しては、後日、特別会員の銀行口座から２８５０円の引き落としが起きないのは勿論である。

ところで、図１に戻って説明を続けると、特別会員の所有するコンピュータ装置ＰＣ１〜ＰＣｎは、具体的には、ブラウザの搭載されたパソコンで実現される。そして、このパソコンＰＣ１〜ＰＣｎは、インターネット回線を通して貯蓄管理装置ＳＶをアクセスして、自己の貯蓄ポイントの照会や、カードの利用状況の照会を行うことになる。また、貯蓄管理装置（照会処理サーバ）ＳＶから配信されるＨＴＭＬファイルに基づいて、ＨＴＭＬのＦＯＲＭアクション（ＰＯＳＴメソッド）を実行して自己の依頼データ（ＰＯＳＴデータ）を貯蓄管理装置ＳＶに送信する。先に説明した通り、依頼内容としては、この実施例では、貯蓄ポイントの清算依頼、貯蓄金額の払い出し依頼、会員種別の変更依頼である。

図４は、パソコンＰＣ（ブラウザ）からの照会処理に基づいて、貯蓄管理装置ＳＶから配信されるＨＴＭＬファイルの内容を例示したものである。なお、このＨＴＭＬファイルは、特別会員本人確認用のＩＤと、これに対応するパスワードによる認証にパスすることを条件に、貯蓄管理装置ＳＶから配信される。

表示内容は、貯蓄管理テーブルＴＢＬ３の一部であり、会員種別、処理年月日、商品代金、決済金額、貯蓄金額、貯蓄ポイントの内容が処理年月日の順番に示される。なお、この配信データ（ＨＴＭＬファイル）には、カード会社を特定して配信されるので、所持するクレジットカードが複数の場合にも、それぞれの使用状況を確実に把握することができる。

図４に示す照会画面（ＨＴＭＬファイル）には、貯蓄ポイントと交換可能な商品の紹介ページや、貯蓄金額の清算を可能にするページや、会員種別の変更手続きページがリンクされている。そして、該当ページにおいて必要な手続きをすると、手続き内容は貯蓄管理装置ＳＶに返送されて、依頼管理テーブルＴＢＬ４に登録される。但し、依頼内容が、貯蓄管理テーブルＴＢＬ３や、使用実績管理テーブルＴＢＬ１に反映されるのは、貯蓄管理装置ＳＶと中央処理装置Ｍとの交信処理を経た後である。

図５（ａ)は、カード決済処理時における中央処理装置Ｍの処理内容を示すフローチャートである。中央処理装置Ｍは、先ず、信用照会端末Ｔから送信されるカードデータに基づいて、そのクレジットカードの有効性の確認や、当該カード会員のカード与信残高の照合処理などの通常の処理を行う（ＳＴ１）。そして、カード決済可能な場合には、当該特別会員が貯蓄金額の清算を希望しているか否かを判定する（ＳＴ２）。

特別会員が貯蓄金額の清算を希望した場合には、既に、その清算依頼は、パソコンＰＣ→貯蓄管理装置ＳＶ（依頼管理テーブルＴＢＬ４）→中央処理装置Ｍの順に、伝送され記憶されている。そこで、中央処理装置Ｍでは過去に受信して記憶している依頼情報に基づいて判断し、もし依頼を受けていれば、代金清算の処理を行うことになる（ＳＴ３）。図２（ａ）に示す２００５年１月２０日の処理は、この代金清算処理を示している。この例では、信用照会端末Ｔから２８５０円の代金請求を受けているが、特別会員○○××の貯蓄金額から２８５０円を清算処理している。また、この清算処理に対応して、２８５０円に対応する貯蓄ポイント３２００を減算している。

一方、貯蓄金額の清算を希望していない通常の場合には、信用照会端末Ｔからの代金請求に応じて代金決済の処理を行う（ＳＴ４）。例えば、図２（ａ）に示す２００５年１２月１５日の処理は、この代金決済処理を示している。信用照会端末Ｔからは、２７１９円の代金請求を受けているが、この特別会員がＣ会員であることから、１００円未満である８１円を切り上げて、２８００円の決済として、管理テーブルＴＢＬ１の該当欄に記憶する。また、その時点での累積貯蓄額を踏まえて換算テーブルＴＢＬ２を参照し、得られる割増率８４％に基づいて、貯蓄ポイントを１４９．０４（＝８１×１．８４）と算出し、管理テーブルＴＢＬ１の該当欄に記憶する。

図５（ｂ）は、中央処理装置Ｍにおける貯蓄管理装置ＳＶとの交信処理を示すフローチャートである。中央処理装置Ｍは、一日に一回（例えば午前０時）になると、貯蓄管理装置ＳＶと通話路を構築し（ＳＴ５，ＳＴ６）、貯蓄管理装置ＳＶの依頼管理テーブルＴＢＬ４の内容を取得する（ＳＴ７）。先に説明した通り、依頼管理テーブルＴＢＬ４には、貯蓄ポイントの商品への交換希望や、会員種別の変更希望や、貯蓄金額の精算希望が記憶されている。

そこで、それらの情報を取得した中央処理装置Ｍでは、使用実績管理テーブルＴＢＬ１の関連箇所を書き換えるか、必要事項を記憶するか、或いは、その他必要な処理を開始する（ＳＴ８）。書換えられるのは、具体的には会員種別であり、使用実績管理テーブルＴＢＬ１の該当箇所が変更される。また、記憶事項としては清算金額、清算ポイント、その他、交換希望商品などが該当する。また、貯蓄ポイントを希望商品と交換することを希望している場合には、商品発送に向けた他の処理プログラムが起動される。

以上のようなステップＳＴ８の処理が終われば、貯蓄管理装置ＳＶに対して、更新された使用実績管理テーブルＴＢＬのうち、過去１日分のデータを送信する（ＳＴ９）。そして、その後、通信路を開放して処理を終える（ＳＴ１０）。なお、ステップＳＴ９の処理において、送信データを過去１日分に限るのは、定期的に毎日、貯蓄管理装置ＳＶにデータ送信処理を行っているからである。

図５（ｃ）は、図５（ｂ）に対応するものであり、貯蓄管理装置ＳＶにおける中央処理装置Ｍとの交信処理を示すフローチャートである。貯蓄管理装置ＳＶでは、中央処理装置Ｍからアクセスがあると（ＳＴ２０）、先ず、依頼管理テーブルＴＢＬ４の内容を送信する（ＳＴ２１）。次に、中央処理装置ＭのステップＳＴ９の処理を待ち、送信されてくる使用実績管理テーブルＴＢＬ１の一日分のデータを受け取る（ＳＴ２２）。

そして、受信したデータを貯蓄管理テーブルＴＢＬ３の該当欄に記入する（ＳＴ２３）。このように、貯蓄管理装置ＳＶ（依頼管理テーブルＴＢＬ４）→中央処理装置Ｍ→貯蓄管理装置ＳＶ（貯蓄管理テーブルＴＢＬ３）の順番に記憶処理が実行させるので、会員の希望が正式に登録されるのに最大２４時間の遅れが生じるが、ただし実質的な弊害はない。

図６は、本発明の第２実施例である釣銭解消システムＳＹＳ２を示すブロック図であり、百貨店、スーパーマーケット、ファミリーレストランなどが発行するポイントカードを適用対象となる。この釣銭解消システムＳＹＳ２では、日々の買い物での支払い額が、切りの良い金額に繰り上がるので、1円単位の釣銭の授受が全く不要となり、レジ係員とカード所持者双方の負担が大幅に軽減される。

図６に示すように、この釣銭解消システムＳＹＳ２は、ポイントカードの情報を読み取るカード端末Ｔ１〜Ｔｊと、ポイントカード利用者の貯蓄額を一元管理する貯蓄管理装置ＳＶと、個々のカード利用者が保有するパソコンＰＣ１〜ＰＣｎとが、通信回線ＮＥＴを介して接続されて構成されている。ここで、カード端末Ｔ１〜Ｔｊは、各店舗の金銭レジスタに近接して配置され、且つ、金銭レジスタに接続されて構成されている。

例えば、この釣銭解消システムＳＹＳ２がスーパーマーケットに導入されている場合には、貯蓄管理装置ＳＶは、スーパーマーケットの管理本部に設置されることになり、各店舗のカード端末Ｔ１〜Ｔｊとは専用回線で接続される。そして、本システムＳＹＳ２では、貯蓄管理装置ＳＶが、図１に示す中央処理装置Ｍの機能を代行するので、貯蓄管理装置ＳＶのデータベースＤＢｓには、貯蓄管理テーブルＴＢＬ３と依頼管理テーブルＴＢＬ４の他に、ポイント換算テーブルＴＢＬ２が設けられている。

カード所持者が、購入商品と共にポイントカードをレジ係員に渡すと、レジ係員は、商品代金を金銭レジスタに打ち込むと共に、受け取ったポイントカードをカード端末Ｔに投入する。すると、専用回線を通して、カード端末Ｔと貯蓄管理装置ＳＶが接続されて、消費税などを含む商品代金が貯蓄管理テーブルＴＢＬ３に記憶される。

また、会員種別に応じて、商品代金が切り上げ換算されて決済金額が決定されて、貯蓄管理テーブルＴＢＬ３の該当欄に記憶される。更にまた、換算テーブルＴＢＬ２に基づいて、貯蓄ポイント（或いは、追加して貯蓄金額）が決定されて貯蓄管理テーブルＴＢＬ３の該当欄に記憶される。

しかる後、決定された決済代金が、専用回線及びカード端末Ｔを経由して、金銭レジスタに返送される。例えば、Ａ会員が商品代金５４３円の買い物をした場合には、決済金額５５０円の支払いとなる。そのため、カード会員やレジ係員が、いちいち1円玉を用意する必要がなくなり、金銭授受の処理が円滑化されて買い物客の待ち行列の発生が防止される。しかも、差額の７円は、割り増し演算されて、自己の貯蓄ポイントか貯蓄金額に加算されるので、この意味でも、買い物客にとっては有効である。

本システムＳＹＳ２において、カード会員が所有するパソコンＰＣと貯蓄管理装置ＳＶとの関係は、図１のシステムＳＹＳ１の場合と同じであり、カード会員は何時でも自己の買い物履歴や、貯蓄ポイントや、貯蓄金額を確認することができる。また、会員種別の変更や貯蓄金額の清算も可能であり、例えば、貯蓄金額の精算を希望した場合には、その後の買い物では、貯蓄金額が取り崩されることで細かな単位の釣銭が不要となる。なお、不要となる釣銭の単位は、会員種別に応じて異なり、１円、１０円、１００円・・・である。

以上、本発明の実施例について具体的に説明したが、本発明の趣旨を逸脱することなく更に各種の変更が可能である。例えば、図６のシステムＳＹＳ２では、会員からの依頼内容は、インターネットによる通信完了後、直ちに、貯蓄管理テーブルＴＢＬ３に反映させることができるので、依頼管理テーブルＴＢＬ４を固定的なものとする必要はない。例えば、適当な時期に消失するテンポラリファイルや、メモリのワークエリア（作業領域）などで代用することができる。

第一実施例の係る貯蓄システムの構成を示すブロック図である。 使用実績管理テーブルと換算テーブルとを例示したものである。 貯蓄管理テーブルと依頼管理テーブルとを例示したものである。 インターネットで配信されるＨＴＭＬファイルの表示例を示したものである。 中央処理装置及び貯蓄管理装置の処理内容を示すフローチャートである。 第二実施例の係る釣銭解消システムの構成を示すブロック図である。

符号の説明

Ｔ１〜Ｔｊ カード端末（信用照会端末）
ＮＥＴ 通信回線
ＳＶ 管理コンピュータ装置（貯蓄管理装置）
ＰＣ１〜ＰＣｎ 端末コンピュータ装置（パソコン）
ＴＢＬ３ 貯蓄管理テーブル
ＴＢＬ４ 依頼管理テーブル

Claims (7)

1. 代金支払い時に、会員各自が所有するカードからカード情報を読み取るカード端末と、通信回線を通して、前記カード端末と直接的又は間接的に接続される管理コンピュータ装置と、前記管理コンピュータ装置と通信回線を通して直接的に接続される会員所有の端末コンピュータ装置とを備え、
   前記管理コンピュータ装置には、(a)本来の支払い代金を切り上げた決済代金、及び、前記切り上げられた金額と会員種別に応じて決定されるポイントを記憶する貯蓄管理テーブルと、(b)前記端末コンピュータ装置からの依頼内容を一時記憶する依頼管理テーブルとが、会員毎に設けられていることを特徴とするカード活用システム。
2. 前記管理コンピュータ装置は、前記端末コンピュータ装置からの要求に応じて、前記貯蓄管理テーブルの内容を返送するよう構成されている請求項１に記載のカード活用システム。
3. 前記管理コンピュータ装置は、中央処理装置を経由して前記カード端末に接続され、前記中央処理装置では、本来の支払い代金を切り上げた決済代金と、前記切り上げられた金額と会員種別に応じて決定されるポイントとを決定している請求項１又は２に記載のカード活用システム。
4. 前記カードはクレジットカードであり、前記中央処理装置は、カード会社毎に設けられている請求項３に記載のカード活用システム。
5. 請求項１〜４の何れかに記載のシステムで使用されるコンピュータ装置。
6. 請求項１〜４の何れかに記載のシステムで使用されるカード。
7. 請求項１〜４の何れかに記載のシステムで使用されるプログラム。

Images