JP7415258B2 - クレジットカードの決済システム、決済方法、ｉｃカード、カード会社のサーバ、クラウドサーバ、及びプログラム - Google Patents

Description

本発明は、クレジットカードの決済システムに関する。

従来、クレジットカードの決済システムにおけるシステムの負荷を軽減する技術が知られている。例えば、特許文献１には、クレジットカードの信用承認を行う与信照会システムと、クレジットカードの決済を行う決済システムと、クレジットカードの情報を蓄積しかつモバイルネットワークに接続可能な携帯端末と、携帯端末を通したクレジットカードの決済情報を決済システムに通知する信用照会端末とを含むクレジットカード決済システムであって、クレジットカード管理サーバが、自装置の負荷状態と与信照会システム及び決済システムの負荷状態とを確認して、与信照会システムに対する信用承認の取得処理及び決済システムに対する決済処理を分散して行う手段を含むことが開示されている。

また、特許文献２には、クレジットカード決済時に、クレジットカード管理サーバは、利用者端末から通知される少なくとも取引識別情報及び決済枠情報によりクレジットカードごとに少なくとも取引キー及び限度額が決められた決済を行う決済枠を設定する決済枠設定手順と、店舗端末から通知される少なくともクレジットカードを識別するクレジットカード情報及び取引キーに基づいて、決済枠設定手順で設定された決済枠から対応する決済枠を決定し、決済枠の限度額の範囲で決済を行う決済手順とを有することにより、従来のカードの真性を重視する仕組みとは異なり、取引の真性（一意性及び機密性）を重視する仕組みを特徴とするため、電子商店等カード会社以外での、利用者からの個人情報収集及び利用者確認の強化する負荷を軽減できることが開示されている。

特開２００９－４８５０７号公報 特開２００９－１６９８３５号公報

ところで、一般的なクレジットカードでは以下のような課題が存在する。すなわち、１回の購買に手間がかかる、少額決済の場合はその手間を考慮すると現金を使うことが多くキャッシュレス化の弊害となっている、使用額がすぐにわからず使い過ぎへの不安がある、一日の決済額が不明瞭である、といったことである。一方、交通系カードなどの電子マネーカードでは、チャージ残高が不足していた場合に購買機会を失うといった課題が存在する。また、両者に共通する課題として、購買傾向の分析がしづらい、カード会社は与信審査を同時刻に大量に行っているため膨大な処理が必要で、システムを構築するコスト、運用保守を行うためのコストが多くかかっている、といったことが挙げられる。

したがって、本発明では、上記のような課題にかんがみ、クレジットカードの利用者と店舗にとっては決済に要する時間を短縮でき、カード会社にとってはシステムの負荷を軽減するシステムを提供することを目的とする。

上記課題を解決するため、本発明は、以下のような解決手段を提供する。

（１）クレジットカードを統括するカード会社の決済システムであって、前記カード会社が管理するクラウドサーバが、前記クレジットカードで購入した購入日時及び商品代金を含む購入データを受信する受信手段と、前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことを送信先に送信することによって、前記クレジットカードを利用した店舗に対して売上成立を通知する手段と、を備え、前記カード会社のサーバは、前記クラウドサーバに保管された未処理の購入データを所定のタイミングで決済処理する購入データ制御手段と、を備えることを特徴とする。

（２）前記送信先は、前記クレジットカード、前記クレジットカードの利用者が所持する利用者端末、又は前記店舗の店舗端末のうち少なくとも１つであることを特徴とする。

（３）上記（２）に記載の構成において、前記所定のタイミングは、あらかじめ設定された期間内の前記商品代金の合計が限度額を超えたとき若しくは超えそうと判断したときであることを特徴とする。

（４）上記（２）又は（３）に記載の構成において、前記所定のタイミングは、前記サーバの処理能力に余裕があると判断したときであることを特徴とする。

（５）上記（２）～（４）のいずれか１つに記載の構成において、前記所定のタイミングは、前記利用者端末又は前記店舗端末の位置情報に基づき、前記利用者が外出していると判断できるときに前記決済処理の頻度を調整することを特徴とする。

（６）上記（２）～（５）のいずれか１つに記載の構成において、前記クレジットカードは、インターネットへの直接通信手段を備えることを特徴とする。

（７）上記（２）～（６）のいずれか１つに記載の構成において、前記利用者端末は、前記クレジットカードの機能を有し、カード情報記憶手段と購入データ記憶手段を備えることを特徴とする。

（８）クレジットカードを統括するカード会社における決済方法であって、前記クレジットカードを利用した購入日時及び商品代金を含む購入データを前記カード会社が管理するクラウドで受信するステップと、前記購入データを前記クラウドサーバに保管するステップと、前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことの通知を受けて、前記クレジットカードを利用した店舗に対して売上成立を通知するステップと、所定のタイミングで前記クラウドサーバに保管された未処理の購入データを決済処理させるステップと、をコンピュータが実行することを特徴とする。

（９）クレジットカードとして用いるためのＩＣカードであって、カード情報及び前記クレジットカードが利用されたときの購入日時及び商品代金を含む購入データを記憶するデータ記憶手段と、インターネットの直接接続可能なインターネット接続手段と、前記クレジットカードが店舗で利用されたときに、前記店舗から前記購入データを取得して前記データ記憶手段に記憶し、前記クレジットカードのカード会社が管理するクラウドサーバに前記購入データを送信する手段と、前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことの通知を受けて、前記店舗の端末に前記クレジットカードでの売上成立を通知する手段と、を備えることを特徴とする。

（１０）クレジットカードを統括するカード会社のサーバであって、前記カード会社に決済要求をする前に店舗での売上を成立させるために、前記クレジットカード、前記クレジットカードの利用者が所持する利用者端末、又は前記カード会社が管理するクラウドサーバから、前記カード会社が管理するクラウドサーバに保管され、前記クレジットカードで購入した購入日時及び商品代金を含む購入データを受信する購入データ受信手段と、前記クラウドサーバに保管された未処理の購入データを所定のタイミングで決済処理させる購入データ制御手段と、を備えることを特徴とする。

（１１）クレジットカードの機能を有する利用者端末のプログラムであって、カード情報を記憶するカード情報記憶手段、前記クレジットカードが利用されたときの購入日時及び商品代金を含む購入データを記憶する購入データ記憶手段、前記クレジットカードが店舗で利用されたときに、前記店舗から前記購入データを取得して前記購入データ記憶手段に記憶する手段、前記クレジットカードのカード会社が管理するクラウドサーバに前記購入データを送信する手段、前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことの通知を受けて、前記店舗の端末に前記クレジットカードでの売上成立を通知する手段、としてコンピュータを機能させることを特徴とする。

（１２）クレジットカードを統括するカード会社が管理するクラウドサーバであって、前記カード会社に決済要求をする前に店舗での売上を成立させるために、前記クレジットカード、前記クレジットカードを利用した店舗端末、又は前記クレジットカードの利用者が所持する利用者端末から、前記クレジットカードで購入した購入日時及び商品代金を含む購入データを受信する受信手段と、前記購入データをクラウドサーバ内に保管する手段と、前記保管された未処理の購入データを前記カード会社のサーバに送信して所定のタイミングで更新させる更新制御手段と、を備えることを特徴とする。

本発明によれば、クレジットカードの利用者と店舗にとっては決済に要する時間を短縮でき、カード会社にとってはシステムの負荷を軽減するシステムを提供することができる。

本発明の実施形態に係るシステムの基本構成を示す図である。 本発明の実施形態に係るシステムの処理イメージを具体例で示す図である。 本発明の第１の実施形態における機能構成を示す図である。 購入データ及びカード情報の具体例を示す図である。 本発明の第１の実施形態における各構成要素の処理フローを示す図である。 本発明の第２の実施形態における機能構成を示す図である。 本発明の第２の実施形態における各構成要素の処理フローを示す図である。 本発明の第３の実施形態における機能構成を示す図である。 本発明の第３の実施形態における各構成要素の処理フローを示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号又は符号を付している。また、機能構成の図において、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表す。

＜基本構成＞
図１は、本発明の実施形態に係る決済システムの基本構成を示す図である。本システムは、クレジットカードを統括するカード会社の決済システムのサーバと、カード会社が管理し、データを一時的に保管するクラウドサーバと、カードの加盟店の店舗端末と、利用者が所持するクレッジットカードなどのＩＣカード及び利用者端末とが、インターネットを介して通信可能に接続される。ＩＣカードは、店舗端末と非接触な手段でリード・ライトが可能であり、また、利用者端末と近距離無線通信が可能である。店舗端末は、利用者の端末とＩＣカードに対して、必要なデータを読み書きしても良い。また、ＩＣカードは、インターネットに対する直接通信手段を備えていてもよい。また、利用者端末とＩＣカードは、加盟店の店舗端末と近距離無線通信で接続されてもよい。ここで、利用者端末は、典型的にはスマートフォンであり、ＩＣカードとクラウドとの中継手段としての機能を果たす。

＜処理イメージ＞
図２は、本発明の実施形態に係る決済システムの処理イメージを具体例で示す図である。この図の丸数字はステップの番号を表す。今、例えば、１１月２９日に商品のＣＤをＸ店で￥３０００で購入したとすると（ステップ１）、「11/29 11:15 Ｘ店 xxxCD ＼3000」のような購入日時と商品代金を含む購入データがＩＣカードに登録（記憶）される（ステップ２）。このとき、ＩＣカードに登録された購入データは、利用者のスマートフォン経由でカード会社が管理するクラウドにも記録される（ステップ３）。そして、クラウドから保管完了の通知がなされると（ステップ４）、スマートフォンはＩＣカードにもその保管完了の通知を出す（ステップ５）。ＩＣカードは、この保管完了の通知を受けとったことに応じて、すなわち、カード会社に決済要求をする前に、Ｘ店に売上成立を通知する（ステップ６）。Ｘ店ではこの通知を受けてレシートを印字し利用者に渡す（ステップ７）。Ｙ店でコーヒーを￥２００で買ったときの手順も同様に処理される（ステップ８以降）。なお、この図では、ステップ６で、カードから売上成立をＸ店に通知するようにしているが、スマートフォン又はクラウドから売上成立をＸ店に通知するようにしてもよい。

上記の購入データは、店舗ごと又は購入商品ごとに記録され、そのデータがクラウド内に蓄積される。以降の処理としては、カード会社側からカード会社のシステムの処理に余裕があるときにクラウド内に蓄積されたデータをカード会社がチェックして決済処理してもよいし（パターンＡ）、クラウド側からクラウド内に蓄積された購入データ中の商品代金の合計が１日の限度額（ここでは￥２００００とする）を超えたときにカード会社に発信してカード会社に決済させるようにしてもよい（パターンＢ）。いずれの場合も、クラウド内に蓄積されていたデータの処理が終わると、限度額が￥２００００に戻る。このとき、クラウド内のデータは消去してもよい。

データの処理のタイミングは、サーバ主導で決定する。上記のように限度額を超えたときに処理する以外にも、超えそうになったと判断できるときに処理してもよい。なお、加盟店がネット店舗の場合は、ＩＣカードを店舗端末に読み込ませることはないが、ＩＣカードと利用者端末との間でデータを読み書きし、カードに対するすべての処理を利用者端末経由で行わせるようにすればよい。詳細については後述の処理フローで説明する。

このようにすることで、１日の買い物をカードに追加する形にし、１日単位でまとめて決済する（これを日次決済と呼ぶ）ことで、１回の購買にかかる時間を短縮することができる。また、１日単位かつ上限額を決めることで、購買ごとにカード会社の「オーソリ」をせず、購入を可能にする。ここでいう「オーソリ」とは、カード決済が行えるかどうかの利用枠の確認と、購入しようとしている額が無事に決済されるように、利用枠を押さえることをいう。ただし、店舗との間で、暗証番号、サイン、生体認証等の本人確認は、別途行うようにしてもよい。現在、食料品スーパーなどでサインや暗証番号の入力なしで買い物を完了することができるが、今回の手法でもサインや暗証番号の入力をしない場合は、電子マネーと同様のスピードで購入可能となる。また、決済の手間を減らすことで、購買機会の減少を防ぐことができる。また、１日単位で上限があることで、使い過ぎへの心配を解消し、クレジットカードの使用を促進できる。さらに、１日単位かつカート単位のデータの集合を管理することで、どういった購買傾向にあるのかを分析できる。

本発明の実施形態には第１、第２、第３と３つの形態があるが、以下、実施形態ごとに説明する。

＜第１の実施形態＞
図３は、第１の実施形態における機能構成を示す図である。第１の実施形態では、ＩＣカード１０（又は単にカードと呼ぶ）、利用者端末２０、店舗端末３０、カード会社サーバ４０（又は単にサーバと呼ぶ）、及びクラウドサーバ５０（又は単にクラウドと呼ぶ）で構成される。利用者端末２０は、一般的なスマートフォンであってよい。

ＩＣカード１０は、図示は省略するが、ＩＣチップとアンテナコイルを内部に備え、また、利用者端末２０との通信を行うチップ内モジュールを駆動するための電源（電池）を内部に備えている。また、ＩＣカード１０を店舗端末３０のカードリーダにかざすと、アンテナコイルの内側に磁力線が通ることで電磁誘導が起こり、カード内に電流が流れ、その電流でＩＣチップが起動することもできる。

ＩＣチップには、チップ内モジュールとして、データＲ／Ｗ制御手段１１、データ記憶手段１２、利用者端末通信手段１３を備える。データＲ／Ｗ制御手段１１は、外部から取得したデータ（店舗端末３０から取得した購入データ）を記憶するための不揮発性メモリであるデータ記憶手段１２の読み書きを制御する。また、利用者端末通信手段１３は、Bluetooth（登録商標）などのPeeｒ To Peerの近距離無線通信手段によって、利用者端末２０との無線通信を行う。

利用者端末２０は、ＩＣカードとのBluetooth（登録商標）の通信を行うＩＣカード通信手段２１と、クラウドサーバ５０との通信を行うＷｉ－Ｆｉ（登録商標）などのインターネット接続手段であるクラウド通信手段２２を備える。なお、ここでのBluetooth（登録商標）の通信距離は、ＩＣカード１０が手元にあることを想定し、情報漏えいを防ぐため短いほうが好ましい。

店舗端末３０は、ＩＣカード非接触Ｒ／Ｗ手段３１、制御手段３２、及び周辺機器３３を備える。ＩＣカード非接触Ｒ／Ｗ手段３１は、ＩＣカード１０と非接触でデータのリード／ライトを可能にし、制御手段３２は、ＩＣカード非接触Ｒ／Ｗ手段３１、及び周辺機器３３を制御する。周辺機器３３は、レジ機能のための周辺機器群であり、タブレット端末、バーコードリーダ、レシートプリンタ、キャッシュドロア、磁気カードリーダ、カスタマーディスプレイなどで構成される。また、店舗端末３０は、インターネットを介してクラウトと通信するクラウド通信手段３４を備えていてもよい。なお、後述する第３の実施形態では、利用者端末と通信する利用者端末通信手段３５（図示せず）を備えていてもよい。

カード会社サーバ４０は、購入データ制御手段４１、購入データ受信手段４２、未処理データ記憶手段４３、決済手段４４を備える。

購入データ制御手段４１は、クラウドサーバ５０の更新制御手段５１と交信し、クラウドサーバ５０の購入データ保管手段５２に格納された購入データを受信して処理する所定のタイミングを制御する。ここで購入データを受信する所定のタイミングはサーバが主導で決定し、カード会社サーバ４０の処理能力に余裕のあると判断したとき、購入データがあらかじめ定められた限度額を超えたこと（又は超えそうと判断されるとき）の通知を受けたとき、日付が変わるとき、所定時間ごと、などであってもよい。また、利用者が携帯する利用者端末２０又は店舗端末３０の位置情報に基づき、利用者が外出している（特に店舗の多い場所に）と判断できる場合はデータ更新の処理の頻度を上げるようにしてもよい。このようにすることで、カード会社サーバ４０の負荷を分散し、負担を軽減することができる。

未処理データ記憶手段４３は、購入データ受信手段４２を介して、クラウドサーバ５０から受信した未処理（未決済）の購入データを記憶し、決済手段４４に処理を渡す。決済手段４４は、未決済の購入データのオーソリを行う。オーソリが完了して初めてカード会社の処理が行われ、利用者には商品代金の請求明細が発行され、商品代金から決済手数料が差し引かれた金額が店舗に支払われる。

クラウドサーバ５０は、更新制御手段５１、購入データ保管手段５２を備える。なお、図示は省略するが、他の構成要素との間でデータを交信する受信手段及び送信手段を備えるのは言うまでもない。更新制御手段５１は、前述のカード会社サーバ４０の購入データ制御手段４１と交信し、ＩＣカード１０から利用者端末２０経由で受信し、又は店舗端末３０から受信し、購入データ保管手段５２に格納された、未処理の購入データをカード会社サーバ４０に送信し、所定のタイミングで更新させる。すなわちクラウドサーバ５０は、カード会社に決済要求をする前に、クラウドサーバに購入データが保管されたことを送信先（ＩＣカード１０、利用者端末２０、又は店舗端末３０自身のうち少なくとも１つ）に送信し、その受信先が店舗に保管完了を通知することによって、店舗に対して売上成立を通知する手段を備える。

図４は、購入データ及びカード情報の具体例を示す図である。第１の実施形態においては、購入データは、商品購入時に、カードを店舗端末３０のＩＣカード非接触Ｒ／Ｗ手段３１にタッチしたときにカード内に読み込まれる（店舗端末からカードに書き込む）データである。また、カード情報は、カード内又は利用者端末２０に記憶される情報である。図示は省略するが、カード情報に本人確認のための暗証番号を含んでいてもよい。なお、購入データ及びカード情報の格納場所は実施形態によって異なる。

図４で図示するように、購入データには、カードの利用日時、店舗ＩＤ，商品ＩＤ，利用金額（商品代金）、クラウド送信済フラグ、決済完了済フラグが格納される。また、カード情報には、カード番号、名義人氏名、有効期限、国際ブランド、カード会社情報、利用可能枠、利用可能枠残高、期間利用額、及び期間限度額が格納される。

ここで、利用可能枠とは、そのカードで決済可能な最大の金額で、利用者の信用度や利用実績などに応じてカード会社が決定する一定の額である。利用可能枠残高とは、利用可能枠から現時点までの未決済の利用金額を差し引いた金額であり、カードを利用するごとに変動する。また、期間利用額とは、あらかじめ設定された期間（典型的には１日）の間に利用した金額に、今回利用購入しようとしている商品の金額を加えた金額である。また、期間限度額とは、上記期間内に利用可能な上限額である。この例では、期間限度額が￥２００００と設定されているが、期間利用額が今回の購入で￥２１２００となり期間限度額を超えてしまうので、クラウドに購入データを蓄積するだけでなく、直ちにカード会社での決済処理が必要となる。

以上で第１の実施形態の説明を終わるが、上記の機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。

各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ（Solid State Drive）、ハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base）やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。このことは他の実施形態でも同様である。

＜処理フロー＞
図５は、第１の実施形態における各構成要素の処理フローを示す図である。なお、以降の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。また、以降のフローチャートでは各構成要素の符号は省略する。

（カード情報の読み取り：実店舗で購入の場合）
実店舗で商品を購入する場合は、まず、利用者が商品を店舗のレジに持参し、カードを店舗端末のカードリーダにタッチすると（ステップＳ２０）、店舗端末はカード内のカード情報を読み込み（ステップＳ１０）、カードの有効期限が切れていないか、及びカードの利用可能枠残高が今回の商品代金分が最低残っているかをチェックする（ステップＳ１１）。このチェックがＯＫの場合は、店舗端末が購入データをカードに送信する、又はカードに書き込む（ステップＳ１２）が、ＮＧの場合はその旨を表示し、ステップＳ１０に戻る。

カード情報のチェックがＯＫの場合、カード側は、店舗端末から送信された購入データを内部メモリ（データ記憶手段）に登録（記憶）し（ステップＳ２１）、その購入データを利用者端末に送信する（ステップＳ２２）。

（カード情報の読み取り：ネット店舗で購入の場合）
ネット店舗で商品を購入する場合は、図示は省略するが、上記ステップＳ１０でカード情報を店舗端末がカードから読み込む代わりに、利用者端末がカードからカード情報を読み込み、利用者がネット店舗の商品購入サイトにカード情報を入力する。あるいは、ネット店舗に登録されたカード情報を指定する。そして、購入データをネット店舗から受け取り、カードに記録する。すなわち、カードへの読み書きはすべて利用者端末経由で行うことになる。したがって、以降のステップで、「カード」と記載している箇所は、「利用者端末経由でのカード」と読み替えればよい。

（クラウドに対する処理）
利用者端末では、カードから受信した購入データをクラウドに送信する（ステップＳ３０）。又は、店舗端末から購入データをクラウドに送信するようにしてもよい。クラウドでは、利用者端末から購入データを受信し、記憶領域（購入データ保管手段）に保管する（ステップＳ４０）。その後、利用者端末にクラウドに正常に保管されたことを示す保管完了通知を送信する（ステップＳ４１）。利用者端末はこの通知を受信すると、カードに保管完了通知を送信する（ステップＳ３１）。保管完了通知を受信したカードは、内部メモリの購入データにクラウド送信済のフラグを立てて、クラウドに購入データの保管は完了したことを記憶し（ステップＳ２３）、続いて、保管完了通知を店舗端末に送信する（ステップＳ２４）。この通知を受けた店舗端末は利用者との間では売上成立とみなし、レシートを印字し処理を完了する（ステップＳ１３）。なお、ステップＳ１３では、クラウドからの保管完了通知を利用者端末経由でカードから受信するようにしたが、店舗端末が、クラウド又は利用者端末から保管完了通知を受信して、決済完了とみなすようにしてもよい。

一方、クラウド側では、ステップＳ４１で利用者端末に保管完了通知を送信した後、クラウド内に未処理のデータがあるかどうかをチェックし（ステップＳ４２）、未処理のデータがあれば、そのデータをサーバに送信する（ステップＳ４３）。

サーバがクラウド内の未処理のデータを受信すると、その購入データの合計額をチェックし、設定期間の限度額（期間内限度額）を超えていないか（超えそうな場合を含む）チェックする（ステップＳ５０）。限度額を超えていなければ、ステップＳ５１に移るが、限度額を超えていれば、ステップＳ５５に移り、購入データを決済処理する。

ステップＳ５０でＮＧの場合は、所定時間（例えば毎日２４時）に達したかどうかをチェックする（ステップＳ５１）、所定時間に達していなければ、現在のシステムの負荷が大きくなっていないかどうか（処理能力に余裕があるか）をチェックする（ステップＳ５２）。
システムの負荷が大きくなっていないときは、利用者が在宅か外出中かをチェックする（ステップＳ５３）。利用者が外出中の場合は、カードの利用があちこちで行われる可能性があるので、クラウドからのデータ更新の頻度を上げるように調整する（ステップＳ５４）。

ステップＳ５０～Ｓ５３のチェックのいずれかがＹの場合は、ステップＳ５５において決済処理を行う。ここでの決済処理が通常のクレジットカードのオーソリに相当するもので、利用限度枠、有効期限が、念のため再度チェックされる。万一、利用限度額を超えているか有効期限が切れていれば、その旨を利用端末に送信し、すでに店舗の決済が終わっている場合は、店舗での当該カードでの購入をキャンセルし、他の手段で支払うなどのリカバリー処理を求める。

＜第２の実施形態＞
図６は、第２の実施形態における機能構成を示す図である。第２の実施形態では、ＩＣカード１０、店舗端末３０、カード会社サーバ４０、及びクラウドサーバ５０で構成され、利用者端末２０は登場しない。以下、第１の実施形態と異なる部分（図の網掛けで示した部分）のみを説明する。

第２の実施形態では、ＩＣカード１０にインターネットに直接通信を可能とするインターネット接続手段１４を備える。また、カード内部に記録された期間限度額及び利用枠残高を視覚的にわかる形態で表示する表示手段１５を備えていてもよい。カード上に表示手段１５を備えることで、カードを取り出した際に利用可能枠残高、期間利用額、期間限度額などの確認が容易にできる。

ここで、利用可能枠残高等は、適宜、カード会社と通信を行い、最新の情報に更新されるものとする。また、図示は省略するが、直接通信は、利用者が自主的に行う手段、あるいはカードの利用頻度、最終購入日から利用者に優先順位をつけ、カード会社が自動で更新を行う手段を備えるようにしてもよい。

図７は、第２の実施形態における各構成要素の処理フローを示す図である。ここでも第１の実施形態の処理フロー（図５参照）と異なる部分のみを説明する。カードの処理ステップのうち、ステップＳ２２ａにおいて、購入データを利用者端末ではなくクラウドに直接送信する。また、クラウドの処理ステップのうち、ステップＳ４０ａにおいて、利用者端末からでなくカードから購入データを直接受信する。またステップＳ４１ａにおいて、保管完了通知を利用者端末でなくカードに直接送信する。

＜第３の実施形態＞
図８は、第３の実施形態における機能構成を示す図である。第３の実施形態では、利用者端末２０がＩＣカード１０の機能をすべて有する形態である。したがってＩＣカード１０は登場しない。以下、第１の実施形態と異なる部分（図の網掛けで示した部分）のみを説明する。

利用者端末２０においては、端末内データ管理手段２３が設けられる。そして、利用者端末２０内に購入データ記憶手段２４、カード情報記憶手段２５、店舗端末通信手段２６を備える。端末内データ管理手段２３は、店舗端末通信手段２６を介して近距離無線接続で、店舗端末３０の利用者端末通信手段３５と通信を行い、購入データ及びカード情報の送受信を行う。

図９は、第３の実施形態における各構成要素の処理フローを示す図である。ここでも第１の実施形態の処理フロー（図５参照）と異なる部分のみを説明する。店舗端末のステップＳ１０ａにおいては、カード情報をカードからではなく利用者端末から読み込む。また、ステップＳ１２ａにおいても、購入データをカードでなく、利用者端末に送信する。また、利用者端末のステップＳ３０ａでは、購入データはカードからではなく、店舗端末から受信し、クラウドに送信する。また、ステップＳ３１ａでは、クラウドからの保管完了通知を受信し、カードではなく店舗端末に送信する。

以上で各実施形態の説明を終わる。なお、第１～第３の実施形態は、単独の形態で実施してもよいし、場合によって複数の形態を組み合わせて実施してもよい。

（実施形態の効果）
本システムによれば、１日単位でまとめて決済することで、１回の購買にかかる時間を短縮することができる。また、１日単位かつ上限額を決めることで、購買ごとにオーソリをせず、電子マネーと同等のスピードでの購入を可能にする。また、決済の手間を減らすことで、購買機会の減少を防ぐことができる。また、１日単位で上限があることで、使い過ぎへの心配を解消し、クレジットカードの使用を促進できる。さらに、購入データを１日単位かつカート単位の集合にすることで、どういった購買傾向にあるのかを分析できる。

また、第１の実施形態においては、カードと利用者端末が連携するので、それぞれの特徴を生かしたバランスのよい実施形態が可能となる。また、第２の実施形態においては、カードが高機能化し、インターネットに直接接続可能になるので、利用者端末と併用しなくとも、カード単体での利用が可能である。カードに表示機能があれば期間利用額、期間限度額などを簡単に確認できる。また、第３の実施形態においては、カード機能を利用者端末に取り込むので、カードを携帯することが不要になる。また、複数のカードの機能を利用者端末に持たせることができる。

なお、上記の実施形態では、主にクレジットカードについて説明したが、決済処理を必要とする他のカード、例えばデビットカードなど、にも応用が可能である。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されないことは言うまでもない。上記実施形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。また、そのような変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

なお、上記の実施形態では、本発明を物の発明として、クレジットカード会社のサーバについて説明したが、本発明は、決済方法の発明又はコンピュータ・プログラムの発明としても捉えることができる。

１０ ＩＣカード
１１ データＲ／Ｗ制御手段
１２ データ記憶手段
１３ 利用者端末通信手段
１４ インターネット接続手段
１５ 表示手段
２０ 利用者端末
２１ ＩＣカード通信手段
２２ クラウド通信手段
２３ 端末内データ管理手段
２４ 購入データ記憶手段
２５ カード情報記憶手段
２６ 店舗端末通信手段
３０ 店舗端末
３１ ＩＣカード非接触Ｒ／Ｗ手段
３２ 制御手段
３３ 周辺機器
３４ クラウド通信手段
３５ 利用者端末通信手段
４０ カード会社サーバ
４１ 購入データ制御手段
４２ 購入データ受信手段
４３ 未処理データ記憶手段
４４ 決済手段
５０ クラウドサーバ
５１ 更新制御手段
５２ 購入データ保管手段

Claims (11)

1. クレジットカードを統括するカード会社の決済システムであって、
   前記カード会社が管理するクラウドサーバが、
   前記クレジットカードで購入した購入日時及び商品代金を含む購入データを受信する受信手段と、
   前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことを送信先に送信することによって、前記クレジットカードを利用した店舗に対して売上成立を通知する手段と、を備え、
   前記カード会社のサーバは、
   前記クラウドサーバに保管された未処理の購入データを所定のタイミングで決済処理する購入データ制御手段と、を備えることを特徴とする決済システム。
2. 前記送信先は、前記クレジットカード、前記クレジットカードの利用者が所持する利用者端末、又は前記店舗の店舗端末のうち少なくとも１つであることを特徴とする請求項１に記載の決済システム。
3. 前記所定のタイミングは、あらかじめ設定された期間内の前記商品代金の合計が限度額を超えたとき若しくは超えそうと判断したときであることを特徴とする請求項２に記載の決済システム。
4. 前記所定のタイミングは、前記サーバの処理能力に余裕があると判断したときであることを特徴とする請求項２又は３に記載の決済システム。
5. 前記所定のタイミングは、前記利用者端末又は前記店舗端末の位置情報に基づき、前記利用者が外出していると判断できるときに前記決済処理の頻度を調整することを特徴とする請求項２から４までのいずれか１項に記載の決済システム。
6. 前記クレジットカードは、インターネットへの直接通信手段を備えることを特徴とする請求項２から４までのいずれか１項に記載の決済システム。
7. 前記利用者端末は、前記クレジットカードの機能を有し、カード情報記憶手段と購入データ記憶手段を備えることを特徴とする請求項２から６までのいずれか１項に記載の決済システム。
8. クレジットカードを統括するカード会社における決済方法であって、
   前記クレジットカードを利用した購入日時及び商品代金を含む購入データを前記カード会社が管理するクラウドサーバで受信するステップと、
   前記購入データを前記クラウドサーバに保管するステップと、
   前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことの通知を受けて、前記クレジットカードを利用した店舗に対して売上成立を通知するステップと、
   所定のタイミングで前記クラウドサーバに保管された未処理の購入データを決済処理させるステップと、
   をコンピュータが実行することを特徴とする決済方法。
9. クレジットカードとして用いるためのＩＣカードであって、
   カード情報及び前記クレジットカードが利用されたときの購入日時及び商品代金を含む購入データを記憶するデータ記憶手段と、
   インターネットと直接接続可能なインターネット接続手段と、
   前記クレジットカードが店舗で利用されたときに、前記店舗から前記購入データを取得して前記データ記憶手段に記憶し、前記クレジットカードのカード会社が管理するクラウドサーバに前記購入データを送信する手段と、
   前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことの通知を受けて、前記店舗の端末に前記クレジットカードでの売上成立を通知する手段と、
   を備えることを特徴とするＩＣカード。
10. クレジットカードの機能を有する利用者端末のプログラムであって、
    カード情報を記憶するカード情報記憶手段、
    前記クレジットカードが利用されたときの購入日時及び商品代金を含む購入データを記憶する購入データ記憶手段、
    前記クレジットカードが店舗で利用されたときに、前記店舗から前記購入データを取得して前記購入データ記憶手段に記憶する手段、
    前記クレジットカードのカード会社が管理するクラウドサーバに前記購入データを送信する手段、
    前記カード会社に決済要求をする前に、前記クラウドサーバに前記購入データが保管されたことの通知を受けて、前記店舗の端末に前記クレジットカードでの売上成立を通知する手段、
    としてコンピュータを機能させることを特徴とするプログラム。
11. クレジットカードを統括するカード会社が管理するクラウドサーバであって、
    前記クレジットカード、前記クレジットカードを利用した店舗端末、又は前記クレジットカードの利用者が所持する利用者端末から、前記クレジットカードで購入した購入日時及び商品代金を含む購入データを受信する受信手段と、
    前記購入データをクラウドサーバ内に保管する購入データ保管手段と、
    前記カード会社が決済要求を受ける前に、前記購入データが保管されたことを送信先に送信することによって、前記クレジットカードを利用した店舗に対して売上成立を通知する手段と、
    を備えることを特徴とするクラウドサーバ。

Images