JP5882122B2 - カード支払情報通知システム、カード支払情報通知方法及びカード支払情報通知プログラム - Google Patents

Description

本発明は、カード支払情報通知システム、カード支払情報通知方法及びカード支払情報通知プログラムの分野に関する。

現在、商品やサービスの購入代金の決済手段として、クレジットカードが広く利用されている。また、従来のように店舗での利用のみならず、インターネットショッピングにおける決済手段としても広く利用されるようになった。ここで、クレジットカード決済の仕組みとしては、概ね次の通りである。

まず、カード会社は、クレジットカード発行時、利用者の審査を行い、クレジットカードの発行が可能かどうかを判断する。また併せて、利用者の信用力に応じ、カードの利用限度額を判断し設定する。カード利用者は、原則、この利用限度額の範囲内であれば、クレジットカードを用いて代金の決済を行うことができる。

利用者が、加盟店でクレジットカードを利用して支払いを行う際は、カードの利用可否を確認することで、カード会社が売上承認を行うオーソリゼーション（以下、オーソリという）といわれる処理がなされる。具体的に、加盟店に設置されたＣＡＴ端末等を用い、クレジットカードから読み取ったカード番号等をカード会社のシステムに送信する。カード会社のシステムでは、そのクレジットカードが有効かどうか、利用限度額を超過しないか、問題のあるクレジットカードに該当しないか、等々の照会を行い、照会結果（決済ＯＫ／ＮＧ）をＣＡＴ端末等に応答する。

加盟店は、照会結果が決済ＯＫの場合、ＣＡＴ端末等を通じて、レシートが印刷されるので、利用者からサイン（サイン不要の場合もある）をもらって、決済を完了する。その後、加盟店は、利用額を集計し、店舗毎の締め日単位（例えば、毎月２０日、３０日等）で、カード会社に対し当該店舗で利用されたカード利用の請求を行う。

カード会社は、加盟店から売上請求があると、カード利用者に代わって、加盟店に対し、代金の支払いを行う。また、カード会社は、カード締め日（例えば、毎月２５日等）に、加盟店から売上請求に基づいて利用者毎のカードの利用額合計を集計し、各カード利用者に対して請求する（銀行引き落とし）。

なお、これら点に関する各技術として、例えば、特許文献１には、クレジットカード等の契約者に、カードの利用があったことを素早く知らせることができるカード利用通知システムが記載されている。また、例えば、特許文献２には、クレジットカードを使用して商品を購入する場合には、クレジットカード保持者に直ちに、クレジットカードの使用が通知される機能を備えた、カード利用承認装置が記載されている。また、例えば、特許文献３には、カード発行会社が設定するカード発行者利用限度額とは別に、利用者自身で簡単に所望の利用者利用限度額を設定して運用可能なカード処理システムが記載されている。

特開２００７−２１３４９１号 特開２００４−１５１９７２号 特開２００６−０４００６２号

従来、クレジットカード処理は、加盟する店舗で、クレジットカードを利用した時点で、上述のように、カードが有効であるか等のオーソリがなされる。しかし、その時点で、その支払い代金の引落し月は、未だ確定しておらず、店舗から、店舗の締め日までのカード利用の売上請求がカード会社になされた時点で、引落し月が確定する。カード会社は、カード会社の締め日の時点で、各店舗から売上請求されてきた支払い代金の合計額を集計し、少なくとも利用者の翌月引落し金額を確定させる。利用者は、この内容を、毎月カード会社から通知される利用明細書・請求書（郵送又はＷｅｂ等）により把握する。

図１は、店舗でのクレジットカードによる買い物の引き落とし月の決定を説明する図である。図を用いて説明する。図のように、例えば、利用者が、１月上旬にＡ店で買い物をしたとする。Ａ店の締め日は、毎月２０日であるので、１月２０日にカード会社にその利用者のカード利用の売上請求がなされる。カード会社の締め日は、毎月２５日であるので、Ａ店での代金は、２月１０日に利用者の銀行口座から引き落とされる。

一方、利用者が、同時期にＢ店でも買い物をしたとする。Ｂ店の締め日は、毎月３０日であるので、１月３０日にカード会社にその利用者のカード利用の売上請求がなされる。カード会社の締め日は、毎月２５日であるので、Ｂ店での代金は、３月１０日に利用者の銀行口座から引き落とされる。この場合、利用者は、Ａ店、Ｂ店での買い物は同時期であるので、１月分として、２月１０日に、Ａ店、Ｂ店での買い物の代金が銀行口座から引き落とされると考えるところ、実際はそのようにならない。

これは、店舗毎の締め日がまちまちであることに起因する。このため、Ａ店での買い物に対する支払いは、１月２０日まで確定せず、少なくとも１月２０日以前は利用者には分からない。また、Ｂ店での買い物に対する支払いは、１月３０日まで確定せず、少なくとも１月３０日以前は利用者には分からない。また、カード会社は、１月２５日の締め日に、その日までに各店舗から売上請求されてきた代金の合計を集計するので、利用者は、１月２５日以降、カード会社からの利用明細・請求書の通知により、ようやく２月１０日の銀行口座からの引落し情報（総額代金）を知ることができる。

このように、従来、利用者は、買い物時点で、例えば２月１０日なのか又は３月１０日なのかなど、今回のＡ店やＢ点での買い物に対する支払い日（銀行口座からの引落し日）はいつなのかを知ることができなかった。このためさらに、買い物時点で、その引落し日における総額代金を知ることもできない。また、買い物時点で、残りの利用限度額を知ることもできない。

なお、上述の特許文献１、２は、カード利用により買い物がなされると、メール等でクレジットカードの使用が通知されるにすぎず、利用者は、買い物時点で、引落し日、引落し日における総額代金、又は残りの利用限度額などを知ることはできない。

本発明は上記の点に鑑みて、クレジットカードの使用時、利用者に対し、カード利用に関する支払情報を通知できるカード支払情報通知システム、カード支払情報通知方法及びカード支払情報通知プログラムを提供することを目的とする。

上記課題を解決するため、本発明に係るカード支払情報通知システムは、 クレジットカードの支払い情報を通知するカード支払情報通知システムであって、売上承認要求装置から、少なくとも、クレジットカードの利用金額を含む売上承認要求を受信し、売上承認処理を実行する売上承認処理手段と、売上請求装置から、前記売上承認処理された利用金額の売上請求を受信し、売上請求処理を実行する売上請求処理手段と、前記売上承認処理された利用金額、前記売上請求装置から売上請求された売上請求日、及び、前記売上承認処理された利用金額が引き落とされる引落予定日、を対応付けて記憶する記憶手段と、前記記憶手段を参照し、前記売上承認処理がなされたときは、当月を指定月として、前記引落予定日が前記指定月であって前記売上請求日が空欄でない前記売上承認処理された利用金額を合計して前記売上請求処理された利用金額を集計し、前記引落予定日が前記指定月であって前記売上請求日が空欄の前記売上承認処理された利用金額を合計して前記売上承認処理された利用金額を集計し、前記指定月を１つ大きくした場合に前記指定月が最も未来の前記引落予定日よりも大きくなるまで、前記売上請求処理された利用金額及び前記売上承認処理された利用金額の集計を前記指定月ごとに繰り返し行う更新手段と、前記指定月ごとに集計された、前記売上承認処理された利用金額と、前記売上請求処理された利用金額とを通知する通知手段と、を有する。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、などに適用したものも本発明の態様として有効である。

本発明によれば、クレジットカードの使用時、利用者に対し、カード利用に関する支払情報を通知できるカード支払情報通知システム、カード支払情報通知方法及びカード支払情報通知プログラムを提供することができる。

店舗でのクレジットカードによる買い物の引き落とし月の決定を説明する図である。 本実施形態に係るクレジットカード処理システムのネットワーク構成の一例を示す図である。 本実施形態に係るカード会社システム１の機能構成の一例を示す図である。 本実施形態に係るカード種別情報テーブルの一例を示す。 本実施形態に係る加盟店情報テーブルの一例を示す。 本実施形態に係る会員属性テーブルの一例を示す。 本実施形態に係るカード管理情報テーブルの一例を示す。 本実施形態に係る会員別月額払いテーブルの一例を示す。 本実施形態に係るカード利用履歴テーブルの一例を示す。 本実施形態に係るカード利用額集計テーブルの一例を示す。 本実施形態に係るカード会社システム１の主要構成を示すハードウェア構成図である。 本実施形態に係るクレジットカードの支払い情報通知例を示す。 本実施形態に係る商品購入時処理を説明するフローチャートである。 本実施形態に係るカード利用額集計テーブルの作成（更新）を説明するフローチャートである。 カード利用履歴テーブルの抽出例を示す。 カード利用額集計テーブルの更新例を示す。 本実施形態に係る売上請求処理を説明するフローチャートである。 カード利用履歴テーブルの更新例を示す。 カード利用履歴テーブルの更新例を示す。 本実施形態に係る照会処理を説明するフローチャートである。

以下、本発明を実施するための形態を実施形態において図面を用いて説明する。本発明に係るカード支払情報処理システムを、クレジットカード処理システムに適用した例を用いる。

[システム構成]
（ネットワーク構成）
図２は、本実施形態に係るクレジットカード処理システムのネットワーク構成の一例を示す図である。クレジットカード処理システムは、カード会社システム１、店舗端末２、提携団体システム３、利用者端末４を含み、通信ネットワーク５を介し接続される。

カード会社システム１は、クレジットカード会社（以下単にカード会社ともいう）が運営するカード決済システムである。カード会社システム１は、ホストコンピュータなどの各種サーバや複数のＤＢ（Database）を含み構成される（後述）。カード会社システム１は、利用者が店舗等でクレジットカード（以下単にカードともいう）を利用して支払いを行う際、店舗の店舗端末２から、カード番号や商品の金額などが送信されてくると、そのカードに対する与信、売上承認等のオーソリゼーション（以下単にオーソリという）を行う。例えば、そのカードが有効かどうか、カード利用限度額を超えていないかどうかの確認や、問題のあるカードに該当しないか、等々の照会を行って、そのカードの利用可否を判断する。

店舗端末２は、各店舗（加盟店）等に設置されるＣＡＴ端末（Credit Authorization Terminal：信用照会端末）である。また、ＣＡＴ端末の機能を含むＰＯＳシステム（Point Of Sales system）の端末でもよい。店舗端末２は、カード会社システム１と通信ネットワーク５を介してオンライン接続され、利用者が店舗等でカードを利用して支払いを行う際、利用者のカードのデータの読取りを行ない、クレジットカードのオーソリゼーションやカード伝票を自動的に作成する。

提携団体システム３は、具体的に例えば、電気、水道、ガスといったような、利用者の公共料金支払先のシステム（この場合、電気会社システム、水道会社システム、ガス会社システム）である。また、例えば、携帯電話、インターネットプロバイダなどのシステム（この場合、携帯電話会社システム、プロバイダ会社システム）である。

ここでの提携団体システム３は、一般の店舗と同様、クレジットカードの加盟店であり、利用者のクレジットカードから、使用料金を徴収する。しかし、一般の店舗とは異なり、その使用料金は、店舗端末２を用いたオーソリを通じて決済されるものではない。予め利用者は、引き落とし先の銀行口座を申告しておき、毎月の使用料金は、その銀行口座から毎月引き落とされる。いわゆる公共料金等のカード払いである。カード会社システム１は、提携団体システム３から、毎月の締め日に使用料金が通知されてくるので、その使用料金を利用者にカード利用分として集計し、店舗でのカード利用と同様に、請求を行う。

利用者端末４は、クレジットカード利用者の保持する端末である。具体的には、例えば、携帯電話、スマートフォン、携帯型タブレット、ＰＣなどである。利用者は、利用者端末４を用いて、カード会社システム１にアクセスし、Ｗｅｂ画面を通じて、利用者登録情報、支払い情報などの情報の参照、カードの利用限度額の変更操作などを行うことができる。また、利用者端末４は、カード会社システム１からの支払い情報などの情報などを含むメールを受信できる。

なお、本実施形態に係るクレジットカード処理システムはあくまで一例であり、店舗端末２や提携団体システム３は、いうまでもなく複数が存在しうる。また、カード会社システム１は、さらに他の与信機関へオーソリ処理を問い合わせる方法でもよい。

（機能構成）
次に、本実施形態に係るカード会社システム１の主要機能構成について説明する。図３は、本実施形態に係るカード会社システム１の機能構成の一例を示す図である。図に示されるように、カード会社システム１は、売上承認処理部１０１、売上請求処理部１０２、記憶部１０３、更新部１０４、通知部１０５を含む。

売上承認処理部１０１は、例えば商品購入時等に、加盟店端末２から、少なくとも、クレジットカードの利用金額を含む売上承認要求（いわゆるオーソリ処理依頼）を受信し、売上承認処理（いわゆるオーソリ処理）を実行する。

売上請求処理部１０２は、例えば加盟店の売上請求日等に、加盟店端末２から、売上承認処理（オーソリ処理）された利用金額の売上請求を受信し、売上請求処理を実行する。

記憶部１０３は、カード種別管理ＤＢ１０３ａ、カード個別管理ＤＢ１０３ｂを記憶する。これらＤＢは、各種テーブル等を含むが、その詳細は後述する。

更新部１０４は、カード種別管理ＤＢ１０３ａ、カード個別管理ＤＢ１０３ｂの各種テーブルの更新処理を行う。また更新に伴い、各種演算等も行う。

通知部１０５は、例えば、店舗端末２、利用者端末４などに対し、クレジットカードの支払い情報等の通知を行う。

以上、これらの各機能は、実際にはカード会社システム１のＣＰＵが実行するプログラムによりコンピュータに実現させるものである。また、本実施形態はあくまで一構成例であり、各機能部を外部装置や他のサーバに実装することも可能である。例えば、別個の
売上承認処理サーバ、売上請求処理サーバにより、売上承認処理部１０１、売上請求処理部１０２を実現することもできる。また、記憶部１０３は、別の記憶装置で構築することもできる。

（カード種別管理ＤＢ１０３ａのデータ例）
本実施形態に係るカード種別管理ＤＢ１０３ａは、カード種別情報テーブル、加盟店情報テーブルを含む。

図４は、本実施形態に係るカード種別情報テーブルの一例を示す。カード会社は、複数種別（種類）のクレジットカードを発行している。よって、カード種別情報テーブルは、カード会社が発行するクレジットカードの種別毎に、「カード種別コード」、「カード種別名」、「夏季ボーナス期間」、「夏季ボーナス引落日」、「冬季ボーナス期間」、「冬季ボーナス引落日」などのデータ項目を有する。

「カード種別コード」、「カード種別名」は、複数種別存在するクレジットカードの種別を一意に識別するための情報である。それぞれ固有のコード、種別名がクレジットカード毎に付され、ここに格納される。なお、例えば、「カード種別名」の一例として、一般カード、ゴールドカードなどがある。

「夏季ボーナス期間」は、夏季ボーナス期間として扱う期間が予め格納され、「夏季ボーナス引落日」が、夏季ボーナスとして扱われた請求分の銀行引落日が予め格納される。一般に、クレジットカードで買い物する場合、支払い方法として、一括、分割、リボ、ボーナス一括などの支払い方法を選択して支払える。よって、利用者により夏季ボーナス一括の支払い方法が選択されたとき、「夏季ボーナス期間」は、夏季ボーナス期間として扱う期間を示し、「夏季ボーナス引落日」は、その期間に夏季ボーナスとして扱われた請求分の銀行引落日を示す。例えば、１２月３０日に、利用者により夏季ボーナス一括の支払い方法が選択されて買い物がなされたとき、その請求分は、８月１０日に銀行口座から引き落とされる。

「冬季ボーナス期間」は、冬季ボーナス期間として扱う期間が予め格納され、「冬季ボーナス引落日」が、冬季ボーナスとして扱われた請求分の銀行引落日が予め格納される。意味するところは、上述の夏季と同様である。

図５は、本実施形態に係る加盟店情報テーブルの一例を示す。カード会社は、複数の店舗と加盟店契約を行っている。よって、加盟店情報テーブルは、カード会社が契約する加盟店毎に、「加盟店コード」、「加盟店名称」、「加盟店売り上げ請求日」などのデータ項目を有する。

「加盟店コード」、「加盟店名称」は、加盟店を一意に識別するための情報である。それぞれ固有のコード、名称がここに格納される。なお、加盟店には、店舗端末２を備える店舗のほか、具体的に例えば、「東○電気」、「東○ガス」といったようなインフラ会社も含む。上述したように、このような加盟店の特徴は、一般の店舗とは異なり、その使用料金は、店舗端末２を用いたオーソリを通じて決済されるものではない。予め利用者は、引き落とし先の銀行口座を申告しておき、毎月の使用料金は、その銀行口座から毎月引き落とされる。カード会社システム１は、提携団体システム３から毎月の締め日（例えば、１０日）に使用料金が通知されてくるので、その使用料金を利用者にカード利用分として集計し、店舗でのカード利用と同様に、請求を行う。

「加盟店売上請求日」は、加盟店毎の毎月の締め日である。加盟店は、通常、１ヶ月に１回以上（複数回可）の締め日を任意に定め、予めカード会社へ申告しておく。この締め日が「加盟店売上請求日」に格納される。例えば、利用者が、「加盟店コード」：００１の「○○レストラン」で、買い物（食事）をしたとする。この加盟店の締め日は、毎月５日であるので、毎月５日にカード会社に対し、それまで蓄積していたカード利用の請求がなされる。

なお、加盟店情報テーブルは、この他、加盟店に関する情報として、店舗の所在、代表者名、連絡先等々の店舗属性を含みうる。

（カード個別管理ＤＢ１０３ｂのデータ例）
本実施形態に係るカード個別管理ＤＢ１０３ｂは、会員属性テーブル、カード管理情報テーブル、会員別月額払いテーブル、カード利用履歴テーブル、カード利用額集計テーブルを含む。

図６は、本実施形態に係る会員属性テーブルの一例を示す。カード会社は、利用者からクレジットカード発行申込みを受付けると、利用者の与信審査を経て、クレジットカードの発行を行う。そして、その利用者を会員としてここへ登録する。よって、クレジットカードを保持する利用者（会員）の属性情報が予めここに登録される。

ここで、会員属性テーブルは、会員毎に、「ユーザＩＤ」、「照会パスワード」、「メールアドレス」、「配信フラグ」などのデータ項目を有する。上述したように、利用者（会員）は、利用者端末４を用いて、カード会社システム１にアクセスし、Ｗｅｂ画面を通じて、利用者登録情報、支払い情報などの情報の参照、カードの利用限度額の変更操作などを行うことができる。よって、「ユーザＩＤ」、「照会パスワード」は、カード会社システム１にアクセスし、ログインする際に用いられる。また、利用者端末４は、カード会社システム１からの支払い情報などの情報などを含むメールを受信できる。よって、「メールアドレス」は、利用者端末４へのメール配信先アドレスである。また、「配信フラグ」は、メール配信の有無の判断に用いられる。

なお、会員属性テーブルは、この他、会員に関する情報として、会員の住所、生年月日、連絡先等々の会員属性を含みうる。また、「ユーザＩＤ」、「照会パスワード」、「メールアドレス」、「配信フラグ」などは、利用者（会員）自身により任意に決定され、申告された情報がテーブル内に格納される。

図７は、本実施形態に係るカード管理情報テーブルの一例を示す。なお、カード会社は、利用者に対し、複数のクレジットカードを発行できる。つまり、１の利用者でも、１以上（複数）のクレジットカードを保持できる。カード管理情報テーブルは、クレジットカード毎に、そのカードの属性情報を登録したものである。

カード管理情報テーブルは、発行済みのカードの毎に、「カード種別コード」、「カード番号」、「ユーザＩＤ」、「利用限度額」、「カード締め日」、「引落日」などのデータ項目を有する。

「カード種別コード」は、複数種別存在するクレジットカードの種別を一意に識別するための固有のコード情報である（カード種別情報テーブルに対応）。「カード番号」は、発行済みのクレジットカードを一意に識別するための固有のコード情報である。発行カード数分だけ存在する。

「ユーザＩＤ」は、ログインする際に用いられる「ユーザＩＤ」である（会員属性テーブルに対応）。１枚のカード毎に１の「ユーザＩＤ」が存在する。

「利用限度額」は、そのカードに与えられている利用限度額である。例えば、「利用限度額」：￥250000の場合、そのカードを用いて、最大￥250000までの買い物を行うことができる。この限度額は、カード会社の与信により決定される。また、利用者は、「利用限度額」よりも低い金額の範囲内で任意に「利用限度額」を決定することも可能である。

「カード締め日」は、そのカード利用に対する銀行口座からの引き落としを行うために、その引き落とし額を決定するためのいわば毎月の清算日である。つまり、カードを利用した場合、日々の請求分は、「カード締め日」において、カード会社により毎月清算される。そして、その清算額は、毎月の「引落日」において、銀行口座から引き落とされる。

「引落日」は、そのカード利用に対する銀行口座からの引き落とし日である。つまり、カードを利用した場合、その請求分は、毎月の「引落日」において、カード会社により、そのカード利用の請求用の銀行口座として指定されている銀行口座から引き落とされる。

なお、「カード締め日」、「引落日」は、カード会社が任意に決定できるが、通常は毎月１回である。ここでも、カード締め日は毎月１回、１５日、その引落日は、翌月１０日とする。

図８は、本実施形態に係る会員別月額払いテーブルの一例を示す。会員別月額払いテーブルは、「カード番号」、「加盟店コード」のデータ項目を有し、これらデータ項目が対応付けられている。ここで、「カード番号」は、カード管理情報テーブルの「カード番号」に対応し、「加盟店コード」は、加盟店情報テーブルの「加盟店コード」に対応する。

ここで、上述したように、加盟店には、店舗端末２を備える店舗のほか、「東○電気」、「東○ガス」といったようなインフラ会社も含む。このような加盟店の特徴は、店舗端末２を用いたオーソリを通じて決済されるものではなく、毎月の使用料金がその銀行口座から毎月引き落とされる。これに先立ち、予め利用者は、カード会社に引き落とし先の銀行口座を申請しておく必要がある。

このように、加盟店からの使用料金の請求を受けて毎月の使用料金をその銀行口座から毎月引き落としてよいという申請が利用者からカード会社になされた場合、そのカード番号と、加盟店コードとを対応付け、会員別月額払いテーブルに登録される。

例えば、図の会員別月額払いテーブルにおいては、「カード番号」：1234876500092020は、「加盟店コード」：101及び102が登録されている。これは、○○市水道局、東○電力からの使用料金の請求がカード会社にあったとき、「カード番号」：1234876500092020のカード利用分として、請求するものである。

図９は、本実施形態に係るカード利用履歴テーブルの一例を示す。カード利用履歴テーブルは、クレジットカードの利用される度に、その履歴を記録するものである。クレジットカードの利用は、加盟店でのクレジットカードを利用した決済全てを含む。よって、カード利用履歴テーブル上、加盟店の店舗等で利用者がクレジットカードを利用して買い物を行った際、店舗端末２を用いてオーソリを通じて決済されたタイミングで、利用履歴のレコードが記録される。またさらに、いわゆる公共料金等のカード払いの利用も記録される。この場合、カード会社システム１に対し、提携団体システム３から、毎月の締め日に使用料金が通知されてくるので、そのタイミングで、その使用料金分が利用履歴のレコードとして記録される。

カード利用履歴テーブルは、「カード番号」、「利用日時」、「加盟店コード」、「利用金額」、「売上請求予定日」、「売上請求日」、「引落予定日」などのデータ項目を有する。

ここで、例えば、利用者が、加盟店の店舗でクレジットカードを利用して支払いを行う際は、加盟店に設置されたＣＡＴ端末を用い、カード会社が売上承認を行うオーソリ処理が行われる。このとき、ＣＡＴ端末は、カード会社システム１に対し、クレジットカードから読み取ったカード番号、ＣＡＴ端末に登録されている加盟店コード、買い物等を行った利用金額、支払方法（一括、分割等）などの情報を送信する。このタイミングで、カード利用履歴テーブル上、利用履歴のレコードが記録される。

よって、「カード番号」、「加盟店コード」、「利用金額」は、ＣＡＴ端末から送信されてきた情報を受信し、ここに格納される。「利用日時」は、ＣＡＴ端末から送信されてきた情報又はカード会社システム１側でそのときに取得した利用日時がここへ格納される。

次に、「売上請求予定日」は、「利用日時」、「加盟店コード」に基づき、今回決済した「利用金額」分が、店舗側からカード会社に対し売上請求される予定日をここへ格納する。この予定日は、加盟店情報テーブルを参照することにより、自動的に決まる。具体的に、例えば、図中、最上行のレコードは、「利用日時」：2011/7/11 10：05、「加盟店コード」：001となっている。加盟店情報テーブルを参照すると、「加盟店コード」：001の「加盟店売上請求日」は、（毎月）５日である。よって、「利用日時」：2011/7/11であるから、この加盟店の次の「売上請求予定日」は、2011/8/5となる。

次に、「売上請求日」は、実際に、今回決済した「利用金額」分が、店舗側からカード会社に対し売上請求された日をここへ格納する。よって、店舗側からカード会社に対し売上請求されたときに、その日がここへ格納されるため、その前までここは未記録（空欄）となる。例えば、加盟店の店舗でクレジットカードを利用して支払いを行う際のオーソリ処理の時点では、ここは未記録（空欄）である。

なお、従来、カード会社は、加盟店から売上請求があると、カード利用者に代わって、加盟店に対し、代金の支払いを行う。また、カード会社は、カード締め日（例えば、毎月２５日等）に、加盟店から売上請求に基づいて利用者毎のカードの利用額合計を集計し、各カード利用者に対して請求する。逆にいえば、カード会社は、加盟店から売上請求がない限り、加盟店に対し、代金の支払いを行わないし、その分をカード締め日にカードの利用額合計に集計することもない。

即ち、「売上請求日」に、売上請求された日が格納されているものについて、カード会社は、カード締め日にカードの利用額合計を集計し、各カード利用者に対して請求する。この意味で、カード利用履歴テーブル上、「売上請求日」が未記録（空欄）のレコードは、将来（原則、「売上請求予定日」迄）、加盟店から売上請求されるであろうレコードであるが、「売上請求日」が未記録（空欄）である限り、利用者のカードの利用額として計上できるという確定的な利用額ではない。そして仮に、加盟店側が「売上請求予定日」を過ぎて売上請求した場合、次のカード締め日にカードの利用額合計を集計し、各カード利用者に対して請求する（１ヶ月遅れる）。

次に、「引落予定日」は、「カード番号」、「売上請求予定日」に基づき、今回決済した「利用金額」分が、カード会社から銀行口座を通じて引き落とされる予定日をここへ格納する。この予定日は、カード管理情報テーブルを参照することにより、自動的に決まる。具体的に、例えば、図中、最上行のレコードにおいて、「カード番号」は、1234876500092020、「売上請求予定日」は、2011/8/5である。ここで、カード管理情報テーブルを参照すると、「カード番号」：1234876500092020（「カード種別コード」：10100）の、「カード締め日」は、（毎月）１５日、「引落日」は、その翌月１０日である。よって、「売上請求予定日」は、2011/8/5であるから、その際のカード会社の「カード締め日」は、2011/8/15である。そして、「引落日」は、その翌月の2011/9/10である。この「引落日」：2011/9/10が格納される。

なお、店舗側はカード会社に対し売上請求予定日に売上請求を行うため、これが遵守される限り、原則的には「売上請求予定日」と「売上請求日」とは一致する。また、公共料金等のカード払いの利用の場合、オーソリ処理は発生せずに、実際に提携団体システム３から、毎月の締め日に使用料金が通知されてくるので、そのタイミングで、「売上請求予定日」と「売上請求日」とを同日の日付けで、その使用料金分が利用履歴のレコードとして記録される（例えば、図中、最上行より２行目、３行目のレコード）。

図１０は、本実施形態に係るカード利用額集計テーブルの一例を示す。まず、（ａ）は、例えば、2011年7月11日時点でのカード利用額集計テーブルを示す。カード利用額集計テーブルは、カード番号と毎月毎に１つのレコードを有する。図例の場合、「カード番号」：1234876500092020のテーブルと、「カード番号」：9876543400092020のテーブルとを示す。

また、カード利用額集計テーブルは、カード利用履歴テーブルと密接な関係にある。即ち、カード利用履歴テーブル上、レコードが更新（記録）されたタイミングで、そのレコードに対応するカード番号のカード利用額集計テーブルも更新される。カード利用額集計テーブルは、カード利用履歴テーブルに基づいて生成されるものだからである。このため、例えば（ｂ）のように、カード利用額集計テーブルも更新されていく（2011年8月7日時点）。

カード利用額集計テーブルは、カード番号毎（「カード番号」毎）に、月毎（「年月」毎）に、「売上請求済金額」、「売上未請求金額」、「月払い予想金額」、「予想総額」、「利用可能残高」などのデータ項目を有する。カード利用履歴テーブルに基づいて、利用者のカード毎に、月毎の支払い等に関する金額情報を集計しまとめたテーブルである。これにより、利用者は、月毎どの位のカードの支払いがあるのか等が集計される。カード利用額集計テーブルのこれらデータ項目については、再度後述する。

（ハードウェア）
ここで、本実施形態に係るカード会社システム１のハードウェア構成について説明しておく。図１１は、本実施形態に係るカード会社システム１の主要構成を示すハードウェア構成図である。なお、カード会社システム１は、クレジットカード会社が運営するカード決済システムである。カード会社システム１は、実際、ホストコンピュータなどのサーバとして構成される。

カード会社システム１は、主要な構成として、ＣＰＵ１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、補助記憶装置１４、記憶媒体読取装置１５、入力装置１６、表示装置１７、及び通信装置１８を含む構成である。

ＣＰＵ１１は、マイクロプロセッサ及びその周辺回路から構成され、装置全体を制御する回路である。また、ＲＯＭ１２は、ＣＰＵ１１で実行される所定の制御プログラム（ソフトウェア部品）を格納するメモリであり、ＲＡＭ１３は、ＣＰＵ１１がＲＯＭ１２に格納された所定の制御プログラム（ソフトウェア部品）を実行して各種の制御を行うときの作業エリア（ワーク領域）として使用するメモリである。

補助記憶装置１４は、汎用のＯＳ（Operating System）、プログラムを含む各種情報を格納する装置であり、不揮発性の記憶装置であるＨＤＤ（Hard Disk Drive）などが用いられる。

なお、上記各種情報は、補助記憶装置１４以外にも、ＣＤ−ＲＯＭ（Compact Disk - ROM）やＤＶＤ（Digital Versatile Disk）、ＵＳＢメモリ等の携帯型メディアなどの各種記憶媒体やその他のメディアに記憶されてもよく、これらの記憶媒体に格納された各種情報は、記憶媒体読取装置１５などのドライブ装置を介して読み取ることが可能である。

入力装置１６は、ユーザが各種入力操作を行うための装置である。入力装置１６は、マウス、キーボード、表示装置１７の表示画面上に重畳するように設けられたタッチパネルスイッチなどを含む。表示装置１７は、各種データを表示画面に表示する装置である。例えば、ＬＣＤ(Liquid Crystal Display)、ＣＲＴ(Cathode Ray Tube)などから構成される。

通信装置１８は、通信ネットワーク５を介して他の機器との通信を行う装置である。有線ネットワークや無線ネットワークなど含む各種ネットワーク形態に応じた通信をサポートする。

[支払い情報通知例]
図１２は、本実施形態に係るクレジットカードの支払い情報通知例を示す。

（ａ）は、本実施形態に係る売上票（レシート）の一例を示す。利用者がクレジットカードを利用して買い物等を行うと、店舗端末２は、オーソリ（決済ＯＫ）を経て、売上票（レシート）を印刷する。このとき、売上票には、図のａ１に示されるように、「引落日」が掲載される。これは、今回の「ご利用額」分（例えば、\1000）が、利用者の銀行口座から引き落される日を示す。利用者は、売上票上、この「引落日」が掲載されることにより、今回買い物分の代金が具体的にいつ自身の銀行口座から引き落されるかを把握することができる。また、特に、買い物の金額が大きい場合など、計画的にその「引落日」までに入金しておくなどの対応をとることもできる。

また、売上票には、図のａ２に示されるように、各月ごとに、「引落予想総額」、「利用可能残高」が掲載される。「引落予想総額」は、将来の各月において、「引落日」（例えば、毎月１０日）に、利用者の銀行口座からどれくらいの金額が引き落されるかを示す。「利用可能残高」は、クレジットカードを利用して残りどのくらいの金額を決済できるかを示す。利用者は、売上票上、これらの「引落予想総額」、「利用可能残高」が掲載されることにより、将来月において、どれくらいの金額が引き落されるか、またあとどれくらいカードを利用できるかを把握することができる。また、特に、「引落予想総額」の金額が大きい場合など、以後のカード利用を控えるなどして、利用者の計画的なカード利用に寄与しうる。

なお、「引落予想総額」の「予想」とは、１００％この額で確定しているものではないため、仮にこのように呼んだものである。また、図のａ２の箇所は、省略することも可能である。売上票は、店舗のレジ担当者の目に入るため、利用者のプライバシー保護の観点から、当該箇所の印刷を控えるようするためである。

（ｂ）は、本実施形態に係るメールの一例を示す。利用者がクレジットカードを利用して買い物等を行うと、店舗端末２及びカード会社システム１間でのオーソリ（決済ＯＫ）を経て、クレジットカード決済が行われる。このとき、上記（ａ）のように、店舗端末２からは売上票（レシート）が印刷される。このときさらに、カード会社システム１は、利用者端末４に対し、（ｂ）のようなメールを送信する。利用者は、事前にそのメールアドレスを登録しておいた利用者端末４でメールを受信する。

メールの内容は、概ね上記（ａ）と同様である。但し、ａ２と比べ、ｂ１は、「引落予想総額」、「利用可能残高」のみならず、「引落確定額」、「引落未確定額」、「公共料金等」の金額も掲載されている（詳細後述）。これらは、「引落予想総額」の詳細内訳金額を示す。売上票と異なり、メールの場合には、店舗のレジ担当者の目に入らないという意味において、ｂ１の情報が掲載されていても差し支えはない。

（ｃ）は、本実施形態に係るＷｅｂ画面の一例を示す。クレジットカードの利用者（会員）は、利用者端末４を用いて、カード会社システム１に「ユーザＩＤ」、「照会パスワード」を用いてアクセスする。そして、このようなＷｅｂ画面を通じて、支払い情報などの情報の参照などを行うことができる。その内容は、概ね上記（ｂ）と同様である。

なお、（ａ）売上票、（ｂ）メールにおいて、「ご利用日」：2011年07月11日であることから、「2011年07月10日引落分」の情報は、過去の情報であり、不要とも考えられ、この場合、当該記載は省略することも可能である（8月以降のみ掲載）。

このように、本実施形態においては、利用者は、利用者がクレジットカードを利用して買い物等を行った時点で、支払い情報が通知され、例えば、今回の「ご利用額」分の「引落日」、将来の各月ごとに「引落予想総額」、「利用可能残高」などの支払い情報を把握することが可能となっている。

続いて、これら支払い情報通知するための情報処理について詳しく説明する。

[情報処理]
本実施形態に係るクレジットカード処理システムにおける情報処理について説明する。以下、（１）商品購入時処理、（２）売上請求処理、（３）照会処理に分けて、それぞれ適宜図面を参照しながら説明する。これら情報処理において、上述ＤＢの各テーブル内の各データ項目が記録、更新されることにより、最終的にカード利用額集計テーブルが生成、更新され、このカード利用額集計テーブルの情報に基づいて、利用者に対し、上述の売上票などが通知（提示）される。

（１）商品購入時処理
図１３は、本実施形態に係る商品購入時処理を説明するフローチャートである。商品購入時処理が実施される場面としては、利用者が加盟店で保有するクレジットカードを利用して支払いを行う場面である。店舗端末２は、カード会社システム１に対しオーソリ処理を依頼し、照会結果が決済ＯＫの場合、ＣＡＴ端末等を通じて、レシートが印刷されるので、利用者からサイン（サイン不要の場合もある）をもらって、決済を完了する。図に沿って、以下詳しく説明する。

Ｓ１：店舗端末２は、カード会社システム１に対し、オーソリ処理を依頼する。具体的に、店舗端末２は、利用者のカードのデータの読取りを行ない、クレジットカードから読み取ったカード番号、店舗端末２に登録されている加盟店コード、買い物等を行った利用金額、支払方法（一括、分割等）、利用日時などの情報を送信する。

なお、加盟店はＥＣサイトも含むため、インターネット上で、クレジットカードを用いてのショッピングがなされたときは、ＥＣサイトの店舗端末２に相当するシステムからカード会社システム１に対し、オーソリ処理が依頼される。よって、加盟店の店舗端末２、ＥＣサイトの店舗端末２に相当するシステムを含め、売上請求装置ともいえる。

ここでは、説明上、例えば、以下の情報がカード会社システム１に対し送信されたものとする。
「カード番号」：1234876500092020
「加盟店コード」：001
「利用金額」：￥1000
「支払方法」：一括
「利用日時」
Ｓ２：カード会社システム１（売上承認処理部１０１）は、店舗端末２からのオーソリ処理依頼（売上承認処理要求）を受信すると、オーソリ処理を実施する。カード会社システム１は、例えば、そのクレジットカードが有効かどうか、利用限度額を超過しないか、問題のあるクレジットカードに該当しないか、等々の照会を行う。

Ｓ３：カード会社システム１は、オーソリ処理の結果、決済ＯＫ、決済ＮＧによって、処理を分岐する。

Ｓ４：カード会社システム１は、オーソリ処理の結果、例えば、そのクレジットカードが有効でない場合には、照会結果（利用不可通知／決済ＮＧ）を店舗端末２に応答する。

Ｓ５：店舗端末２は、カード会社システム１から照会結果（利用不可通知／決済ＮＧ）を受信すると、クレジットカードでの決済の取消処理を行う。具体的に、店舗端末２は決済ＮＧである旨を出力し、店舗のレジ担当者に、このクレジットカードの利用不可を通知する。

Ｓ６：一方、カード会社システム１（更新部１０４）は、オーソリ処理の結果、照会結果（決済ＯＫ）の場合、続いて、カード利用履歴の記録を行う。具体的には、ここで、カード利用履歴テーブル上、今回の買い物分のカード利用履歴を作成し、追加する。

カード利用履歴テーブル（例えば、図９）は、「カード番号」、「利用日時」、「加盟店コード」、「利用金額」、「売上請求予定日」、「売上請求日」、「引落予定日」などのデータ項目を有する。そして、更新部１０４は、これらデータ項目に値を入力し、カード利用履歴のレコードを作成する。以下、データ項目ずつ、説明する。

「カード番号」：店舗端末２から受信したカード番号を入力する。ここでは、例えば、「カード番号」：1234876500092020が入力される。

「利用日時」：店舗端末２から受信した利用日時を入力する。ここでは、例えば、「利用日時」：2011/7/11 10：05が入力される。

「加盟店コード」：店舗端末２から受信した加盟店コードを入力する。ここでは、例えば、「加盟店コード」：001が入力される。

「利用金額」：店舗端末２から受信した利用金額を入力する。ここでは、例えば、「利用金額」：￥1000が入力される。

「売上請求予定日」：「利用日時」、「加盟店コード」に基づき、今回決済した「利用金額」分が、店舗側からカード会社に対し売上請求される予定日をここへ入力する。この予定日は、加盟店情報テーブルを参照することにより、自動的に決まる。ここでは、例えば、「利用日時」：2011/7/11 10：05、「加盟店コード」：001であり、加盟店情報テーブル（例えば、図５）を参照すると、「加盟店コード」：001の「加盟店売上請求日」は、（毎月）５日である。よって、「利用日時」：2011/7/11であるから、次の「売上請求予定日」は、2011/8/5となる。よって、ここでは、「売上請求予定日」：2011/8/5が入力される。

「売上請求日」：実際に、今回決済した「利用金額」分が、店舗側からカード会社に対し売上請求された日をここへ入力する。よって、店舗側からカード会社に対し売上請求されたときに、その日付が入力されるため、その前まではここは未記録（空欄）となる。よって、ここでは、未記録（空欄）のままである。

なお、いわゆる公共料金等のカード払いの利用の場合は、決まって毎月の締め日（＝「加盟店売上請求日」）に使用料金が通知されてくるので、この通知をオーソリ処理依頼相当と扱い、そのタイミングで、「売上請求予定日」及び「売上請求日」が同時に記録される（後述の図１７のＳ２２）。因みに、公共料金等のカード払いの利用の場合かどうかは、カード会社システム１が提携団体システム３から受信した通知や、会員別月額払いテーブルによって識別できる。

「引落予定日」：「「カード番号」、「売上請求予定日」に基づき、今回決済した「利用金額」分が、カード会社から銀行口座を通じて引き落とされる予定日をここへ入力する。この予定日は、カード管理情報テーブルを参照することにより、自動的に決まる。ここでは、例えば、「カード番号」は、1234876500092020、「売上請求予定日」は、2011/8/5である。ここで、カード管理情報テーブルを参照すると、「カード番号」：1234876500092020（「カード種別コード」：10100）の、「カード締め日」は、（毎月）１５日、「引落日」は、その翌月１０日である。よって、「売上請求予定日」は、2011/8/5であるから、その際のカード会社の「カード締め日」は、2011/8/15である。そして、「引落日」は、その翌月の2011/9/10である。この「引落日」：2011/9/10が格納される。よって、ここでは、例えば、「引落日」：2011/9/10が入力される。

なお、支払い方法が、夏季又は冬季ボーナス払いの場合、図４のカード種別情報テーブルを参照し、それぞれの「引落日」を入力する。例えば、支払い方法が、夏季ボーナス払いの場合、「引落日」：2011/8/10を入力する。

また、支払い方法が、分割（回数は利用者指定）払いの場合、分割分に応じた「引落日」を入力する。例えば、支払い方法が、分割：２回払いの場合、これは利用金額を２回に分けて支払うものであるので、カード利用履歴テーブル上、２つのレコードが次のように作成される。

１つめのレコード（１回目）は、「カード番号」：1234876500092020、「利用日時」：2011/7/11 10：05、「加盟店コード」：001、「利用金額」：￥500、「売上請求予定日」：2011/8/5、「売上請求日」：未記録（空欄）、「引落日」：2011/9/10である。

２つめのレコード（２回目）は、「カード番号」：1234876500092020、「利用日時」：2011/7/11 10：05、「加盟店コード」：001、「利用金額」：￥500、「売上請求予定日」：2011/8/5、「売上請求日」：未記録（空欄）、「引落日」：2011/10/10である。

両レコードにおいて、「利用金額」：￥500となっている点、「引落日」が、１回目は2011/9/10、２回目は2011/10/10となっている点に注意する。

リボ払いの場合も、分割払いと同様に、複数のレコードが作成される。リボ払いは、毎月均等の支払額を支払うものであるが、所定の計算方法によって毎月の支払額が均等になるようレコードを作成すればよい。

以上、カード利用履歴テーブル上、今回の買い物分のカード利用履歴のレコードが作成される。このレコード内には、上述の「カード番号」、「利用日時」、「加盟店コード」、「利用金額」、「売上請求予定日」、「売上請求日」、「引落予定日」などのデータ項目が入力されて作成される（例えば、図９の最上位レコード参照）。

Ｓ７：再び図１３に戻る。次に、カード会社システム１（更新部１０４）は、カード利用額集計処理を行う。具体的には、Ｓ６で追加、記録されたカード利用履歴テーブルに基づいて、カード利用額集計テーブルを更新する。

カード利用額集計テーブル（例えば、図１０）は、カード番号毎に１つのテーブルを有する。そして、カード利用額集計テーブルは、カード利用履歴テーブルと密接な関係にある。即ち、カード利用履歴テーブル上、レコードが更新（記録）されたタイミングで、そのレコードに対応するカード番号のカード利用額集計テーブルも更新される。ここでは、カード利用履歴テーブル上、「カード番号」：1234876500092020のカード利用履歴のレコードが記録されているので、「カード番号」：1234876500092020のカード利用額集計テーブルが更新の対象となる。

上述したように、カード利用額集計テーブルは、カード番号毎（「カード番号」毎）に、月毎（「年月」毎）に、「売上請求済金額」、「売上未請求金額」、「月払い予想金額」、「予想総額」、「利用可能残高」などのデータ項目を有する。つまり、カード利用履歴テーブルに基づいて、利用者のカード毎に、月毎の支払い等に関する金額情報を集計しまとめたテーブルである。これにより、その利用者が月毎どの位のカードの支払いがあるのか等が集計される。そして、ここでは、「カード番号」：1234876500092020のカード利用額集計テーブルにおいて、これらデータ項目の値を入力又は更新することにより、カード利用額集計テーブルを作成、更新する。

図１４は、本実施形態に係るカード利用額集計テーブルの作成（更新）を説明するフローチャートである。更新部１０４は、カード利用履歴テーブルを参照、集計しながら、カード利用額集計テーブル上の各データ項目の値を算出し更新する。

Ｓ７−１：まずはじめに、更新部１０４は、カード利用履歴テーブル（例えば、図９）から、対象となる「カード番号」分のカード利用履歴（レコード）を抽出する。ここで、対象となる「カード番号」は、「カード番号」：1234876500092020である。よって、「カード番号」：1234876500092020のカード利用履歴（レコード）を抽出する。この結果例を図１５に示す。図に示されるように、カード利用履歴テーブル（例えば、図９）から、「カード番号」：1234876500092020のカード利用履歴（レコード）のみが抽出されている。

Ｓ７−２：次に、最終引落日なる月を設定する。つまり、この「カード番号」：1234876500092020の利用者は、最も未来日で何月に請求（「引落予定日）があるのかを求める。対象となる「カード番号」：1234876500092020のカード利用履歴（例えば、図１５）を参照し、「引落予定日」が一番未来日付の「引落予定日」を取得し、その月を最終引落月に設定する。図１５でいえば、「カード番号」：1234876500092020のカード利用履歴（レコード）において、「引落予定日」が一番未来日付の「引落予定日」：2011/9/10を取得し、その月：9月を最終引落月に設定する。つまり、最終引落月：9月となる。

Ｓ７−３：次いで、指定月なる月を設定する。指定月として、当月を指定する。カード会社システム１が内部時計等から取得した日時から、当月は分かるので、ここでは、つまり、指定月：7月となる。

Ｓ７−４：指定月＜＝最終引落月を判定する。Ｙの場合、次のＳ７−４へ進む。一方、Ｎの場合、処理を終了する。

Ｓ７−５：対象となる「カード番号」について、指定月の「売上請求済金額」を集計し、算出する。指定月（７月）の「売上請求済金額」の意味は、利用者は、７月１０日に、銀行口座からカード利用分（5/16-6/15利用分）が引き落とされるところ、加盟店から実際に請求が既にあった７月の請求分への反映対象となる売上請求の合計額を示す。

図１５のカード利用履歴テーブルを参照し、「引落予定日」が、指定月のカード利用履歴（レコード）を検索、抽出する。そして、このカード利用履歴（レコード）の「売上請求日」が空欄（未記録）でないレコードの「利用金額」の合計額を算出し、これを当該指定月の「売上請求済金額」とする。

具体的に、図１５のカード利用履歴テーブルを参照し、指定月が７月の場合、「引落予定日」が、７月（2011/7/10）のカード利用履歴（レコード）を検索、抽出する。図１５の場合、４行のレコードが該当する。そして、このうち、このカード利用履歴（レコード）の「売上請求日」が空欄（未記録）でないこれら４行のレコードの「利用金額」の合計額を算出する。合計額は、￥20350（=\6850+\13500+\-8800+\8800）であるので、これを当該７月の「売上請求済金額」とする。

Ｓ７−６：今度は、対象となる「カード番号」について、指定月の「売上未請求金額」を集計し、算出する。指定月（７月）の「売上未請求金額」の意味は、利用者は、７月１０日に、銀行口座からカード利用分（5/16-6/15利用分）が引き落とされるところ、加盟店から実際に請求が未だない７月の請求分への反映対象となる売上請求の合計額を示す。

なお、上述したように、カード会社は、加盟店から売上請求がない限り、加盟店に対し、代金の支払いを行わないし、その分をカード締め日にカードの利用額合計に集計することもない。「売上未請求金額」は、「売上請求日」が未記録（空欄）のレコードを集計したものであるため、将来（原則、「売上請求予定日」迄）、加盟店から売上請求されるであろうとはいえるが、カード会社が、カード締め日に利用者のカードの利用額として計上できるという確定的な利用額ではない。一方これに対し、「売上請求済金額」は、「売上未請求金額」は、「売上請求日」が記録されているレコードを集計したものであるため、実際に加盟店から売上請求なされ、このためカード会社が、カード締め日に利用者のカードの利用額として計上できるという確定的な利用額である。

図１５のカード利用履歴テーブルを参照し、「引落予定日」が、指定月のカード利用履歴（レコード）を検索、抽出する。そして、このカード利用履歴（レコード）の「売上請求日」が空欄（未記録）であるレコードの「利用金額」の合計額を算出し、これを当該指定月の「売上未請求金額」とする。

具体的に、図１５のカード利用履歴テーブルを参照し、指定月が７月の場合、「引落予定日」が、７月（2011/7/10）のカード利用履歴（レコード）を検索、抽出する。図１５の場合、４行のレコードが該当する。このうち、このカード利用履歴（レコード）の「売上請求日」が空欄（未記録）のレコードの「利用金額」の合計額を算出する。ここでは、「売上請求日」が空欄（未記録）のレコードは存在しないため、合計額は、￥0である。これを当該７月の「売上未請求金額」とする。

Ｓ７−７：今度は、対象となる「カード番号」について、指定月の「月払い予想金額」を集計し、算出する。指定月（７月）の「月払い予想金額」の意味は、利用者は、７月１０日に、銀行口座からカード利用分（5/16-6/15利用分）が引き落とされるところ、公共料金等の加盟店から請求が来ると予想され、７月の請求分への反映対象となる売上請求の合計額を示す。

いわゆる公共料金等のカード払いの利用の場合は、提携団体システム３からカード会社システム１に、決まって毎月の締め日（＝「売上請求予定日」）に使用料金が通知されてくるが、実際に使用料金が通知されるまでは、具体的金額は不明である。そこで、ここでは、使用料金の予想額を算出し、その予想額を、「月払い予想金額」とする。

具体的に、図１５のカード利用履歴テーブルを参照し、「引落予定日」が、指定月のカード利用履歴（レコード）を検索、抽出する。次に、会員別月額払いテーブル（例えば、図８）を参照し、この利用者の「カード番号」が申請している月額払いの「加盟店コード」（例えば、101、102）を取得する。そして、抽出したカード利用履歴（レコード）の中から、取得した「加盟店コード」のレコードを抽出する。ここで、カード利用履歴（レコード）の中から、取得した「加盟店コード」のレコードを抽出できない場合、これは、提携団体システム３からカード会社システム１に、未だその指定月分の使用料金が未通知であることを意味する（取得した２つの「加盟店コード」のレコードを抽出できた場合、カード利用履歴（レコード）に、この２つの加盟店からのカード利用履歴が存在していることを意味する）。

この場合、更新部１０４は、提携団体システム３からカード会社システム１に、その指定月分の使用料金が通知されたとみなすべく、その使用料金の予想額を算出する。使用料金の予想額は、例えば次のように算出しうる。

１つに、当該利用者（利用者の「カード番号」）の過去のカード利用履歴（レコード）に基づいて、一定期間の実績金額の平均額を、その指定月分の使用料金の予想額とする。つまり、カード利用履歴（レコード）を検索し、月額払いの提携団体の加盟店コードに対応する過去一定期間（例えば、１年分）の使用料金を集計し、その平均額を求める。例えば、「加盟店コード」：101であれば、当該利用者（利用者の「カード番号」）がその加盟店に支払った過去１年分の使用料金を合計してから、１２で除算し、その平均額を予想額として算出できる。

また１つに、当該利用者（利用者の「カード番号」）の過去のカード利用履歴（レコード）に基づいて、指定月と同一月の実績金額の平均額を、その指定月分の使用料金の予想額とする。つまり、カード利用履歴（レコード）を検索し、月額払いの提携団体の加盟店コードに対応する指定月と同一月（例えば、過去毎年７月分）の過去数年分の使用料金を集計し、その平均額を求める。例えば、「加盟店コード」：101であれば、当該利用者（利用者の「カード番号」）がその加盟店に支払った過去５年分７月の使用料金を合計してから、５で除算し、その平均額を予想額として算出できる。

後者の場合、特に公共料金の使用料金などは、季節や月によって、変動しうるため、毎年の同一月平均に基づき予想額を算出することで、より妥当な予想額を算出できる。但し、後者の場合、ある程度の年数の間、当該利用者がクレジットカードを使用して、使用料金の支払いを行っているというカード利用履歴の蓄積が相当量ある場合に有効である。一方、前者は、利用者がクレジットカードの使用を開始してから１年以上経過していない場合に有効である。

以上のように、カード利用履歴（レコード）の中から、取得した「加盟店コード」のレコードを抽出できない場合、その指定月分の使用料金の予想額を算出する。そして、月額払いの提携団体の加盟店が１つのみの場合はその予想額を、加盟店が複数の場合はその予想額の合計を指定月の「月払い予想金額」とする。

一方、そのカード利用履歴（レコード）の中から、取得した「加盟店コード」のレコードを抽出できた場合、カード利用履歴（レコード）に、この月額払いの提携団体の加盟店からのカード利用履歴が存在していることを意味する。具体的に、この利用者は、「加盟店コード」：101、102の２つの加盟店での月額払いを申請しているところ、既にこれら加盟店からのカード利用履歴（レコード）が存在する場合、これは、提携団体システム３からカード会社システム１に、既にその指定月分の使用料金が全て通知済みであることを意味する。よって、この場合には、７月の「加盟店コード」：101、102の２行のレコードの「利用金額」の合計を指定月の「月払い予想金額」とする。ただこの場合の「月払い予想金額」は、実際は月払い確定金額というべきものであるため、「月払い予想金額」に、月払い確定金額を示す何らかのフラグを付しておくものとする。例えば、「月払い予想金額」：￥20350（確）とする。

Ｓ７−８：更新部１０４は、今度は対象となる「カード番号」について、指定月の「予想総額」を集計し、算出する。「予想総額」は、指定月において、利用者の銀行口座から引き落とされる予想金額を意味する。

具体的に、「予想総額（Ｅ）」は、これまで算出してきた値を用いて、以下の式により算出する。
「予想総額（Ｅ）」＝「売上請求済金額（Ｂ）」＋「売上未請求金額（Ｃ）」＋「月払い予想金額（Ｄ）」
なおここで、単に「総額」といわずに、「予想総額」というのは、「売上未請求金額」が含まれていること、公共料金の使用料金等の予想金額である「月払い予想金額」が含まれている場合があるからである。即ち、「売上未請求金額」は、あくまで予定であり、仮に加盟店の売上請求が、「加盟店売上請求日」までになされなかった場合には、「予想総額」は、実際の「引落日」において利用者の銀行口座から引き落とされる金額とは、乖離する。また、公共料金の使用料金などは予想金額であるため、多少の乖離は存在する。

また、仮に例えば、「売上未請求金額（Ｃ）」＝￥０、「月払い予想金額（Ｄ）」＝￥０である場合、上述の「予想総額（Ｅ）」算出式によれば、「予想総額（Ｅ）」＝「売上請求済金額（Ｂ）」である。この場合の「予想総額（Ｅ）」は、加盟店の売上請求が、「加盟店売上請求日」までに既に済んでいるため、実際の「引落日」において利用者の銀行口座から引き落とされる金額と一致する。

Ｓ７−９：更新部１０４は、カード番号に対応した指定月の「利用可能残高（Ｆ）」を算出する。「利用可能残高」は、クレジットカードを用いてあと残りどのくらいの金額を決済できるかを示すものである。具体的には、以下のように算出できる。
「利用可能残高（Ｆ）」＝「利用限度額（Ａ）」−「予想総額（Ｅ）」−｛指定月の次月以降の「売上請求済金額（Ｂ）」の合計＋指定月の次月以降の「売上未請求金額（Ｃ）」の合計｝
Ｓ７−１０：ここで、指定月の支払い予定があるか否か判定する。具体的には、「予想総額（Ｅ）」＞０であれば、指定月の支払い予定があり、「予想総額（Ｅ）」＝０であれば、指定月の支払い予定がなしと判断できる。指定月の支払い予定がない場合、カード利用額集計テーブル上、当該指定月分のレコードの新規作成は不要である。しかし、既にカード利用額集計テーブルに、当該指定月のレコードが存在すれば、更新する。これは取消処理等により、指定月の「予想総額（Ｅ）」＝０となるケースが存在するためである。

Ｓ７−１１：更新部１０４は、指定月の支払い予定がある場合、カード利用額集計テーブル上、指定月（例えば、７月）において、これまでのＳ７−５〜Ｓ７−９で集計、算出してきた「売上請求済金額、「売上未請求金額」、「月払い予想金額）」、「予想総額」、「利用可能残高」に更新する。この結果例を、図１６のカード利用額集計テーブルの７月更新例に示す。

Ｓ７−１２：指定月に１ヶ月を加算（指定月＝指定月＋１）する。その後、Ｓ７−４へ進む。つまり、これまでまず、指定月を７月とし、７月分に引き落される「予想総額（Ｅ）」等を算出し、カード利用額集計テーブルの７月分を更新した。そして、指定月に１ヶ月を加算することで、指定月を８月とし、今度は８月分に引き落される「予想総額（Ｅ）」等を算出し、カード利用額集計テーブルの８月分を更新する。これを、指定月＝最終引落月（Ｓ７−４）となるまで、繰り返す。

Ｓ８：再び図１３に戻る。今度は、通知部１０５が、メール通知情報を取得する。具体的に、当該利用者の「カード番号」に基づき、カード管理情報テーブル及び会員属性テーブルを参照し、メール通知情報として「メールアドレス」及び「配信フラグ」を取得する。ここで、例えば、「カード番号」：1234876500092020の場合、「ユーザＩＤ」：yamada1であるので、「メールアドレス」：yamada1@abcd.co.jp及び「配信フラグ」：ONを取得する。

Ｓ９：メール通知希望か否かを判定する。具体的に、「配信フラグ」：ONである場合、メール通知希望であると判定する。

Ｓ１０：通知部１０５は、「メールアドレス」に対し、支払い情報等を通知する。具体的に、支払い情報等＝カード利用額集計テーブルであるので、当該利用者の「カード番号」のカード利用額集計テーブルの情報を「メールアドレス」：yamada1@abcd.co.jpに対し、送信する。その結果、利用者端末４上、同支払い情報等が表示される（例えば、図１２（ｂ）参照）。なお、メール通知希望しない場合、当ステップは省略される。

Ｓ１１：通知部１０５は、店舗端末２に対し、支払い情報等を通知する。具体的に、支払い情報等＝カード利用額集計テーブルであるので、当該利用者の「カード番号」のカード利用額集計テーブルの情報を店舗端末２に対し、送信する。その結果、売上票（レシート）上、同支払い情報等が印字される（例えば、図１２（ａ）参照）。

なお、Ｓ１０、Ｓ１１において、支払い情報等には、今回のオーソリ処理によって、カード利用履歴テーブル上、追加されたレコードの「引落予定日」（図１５の最上位レコードの「引落予定日」：2011/9/10）を含めておく。例えば、売上票（レシート）上、今回の買物分（￥1000）が引き落とされる「引落日」として印字するためである。

また、上述したように、加盟店はＥＣサイトも含むため、インターネット上で、クレジットカードを用いてのショッピングがなされたときは、売上票（レシート）が印刷されることはない。この場合は、インターネット上の画面で、売上票（レシート）相当の支払い情報等を表示することもできるし、支払い情報等一切をメールで通知することもできる。

（２）売上請求処理
図１７は、本実施形態に係る売上請求処理を説明するフローチャートである。売上請求処理が実施される場面としては、加盟店（提携団体を含む）が加盟店毎の毎月の締め日である「加盟店売上請求日」に、カード会社に対し、それまで蓄積していたカード利用の請求を行う場面である。

なお、本売上請求処理は、加盟店（提携団体システム３を含む）がカード会社システム１に対し、オンラインで売上請求を行ってくる場合を想定したものである。一方、例えば、加盟店によっては、売上票（店舗側控え）をカード会社に送付（郵送等）することにより、売上請求を行う場合も現実想定される。この場合には、カード会社のオペレータ等が、送付された売上票を、加盟店に代わってカード会社システム１に入力することにより対応しうる。

Ｓ２１：加盟店（ＥＣサイトを含む）、月払いの提携団体は、自身の「加盟店売上請求日」になると、店舗端末２又は提携団体システム３（これら売上請求装置ともいえる）から、カード会社システム１に対し、売上請求処理を依頼する。具体的に、加盟店は、それまで蓄積していたカード利用の請求を集計し、利用毎のカード番号、利用金額、支払い方法（一括、分割等）、さらに自身の加盟店コードの情報を送信する。

ここでは、説明上、例えば、以下の売上請求（１件）がカード会社システム１に対し送信されたものとする。
「カード番号」：1234876500092020
「利用金額」：￥1000
「支払方法」：一括
「利用日時」：2011/7/11 10:05
「加盟店コード」：001
Ｓ２２：カード会社システム１（売上請求処理部１０２）は、加盟店からの売上請求処理依頼を受信すると、加盟店からの正規な依頼か否か等の認証を経て、売上請求処理を実施する。具体的には、カード利用履歴テーブルを参照し、売上請求のあった該当レコードを検索し特定する。そして、「売上請求日」に、売上請求処理依頼のあった日（本日）を入力する。

以上で売上請求処理は完了する。カード利用履歴テーブル上、「売上請求日」は、実際に、店舗側からカード会社に対し売上請求された日を格納するものである。カード会社は、店舗側から売上請求を受けて、ようやくこの請求を利用者に請求できる。逆に、カード会社は、店舗側から売上請求を受けないと、利用者に請求できないといえる。

ここで、図１８を参照する。ここでは、上述の売上請求（１件）の処理依頼を受信しているため、カード利用履歴テーブル上、最上位行のレコードを特定する。そして、この「売上請求日」に売上請求処理依頼のあった日（本日）として、2011/8/5が入力される。

なお、月払いの提携団体から売上請求がなされた場合、Ｓ２２で、売上請求のあった該当レコードを検索し特定することはできない。なぜなら、このような提携団体は、一般店舗とは異なり、売上承認処理（オーソリ処理）がなされていないためである。上述してきたように、月払いの提携団体の使用料金（公共料金等）は、店舗端末２を用いたオーソリを通じて決済されるものではなく、カード会社システム１に対し提携団体システム３から、毎月の締め日に使用料金が通知されてくる。例えば、その通知例は、以下の通りである。
「カード番号」：1234876500092020
「利用金額」：￥6850
「支払方法」：一括
「利用日時」：2011/8/10 0：00
「加盟店コード」：102
従って、Ｓ２２で、カード利用履歴テーブル上、売上請求のあった該当レコードを特定できない場合、会員別月払いテーブルを参照し、売上請求のあった「カード番号」と「加盟店コード」が登録されているかを確認する。登録がある場合、カード利用履歴テーブル上、提携団体システム３からのこの売上請求を、新しいカード利用履歴として記録する（図１３のＳ６を参照）。また、「売上請求日」には、売上請求処理依頼のあった日（本日）を入力する。この結果例を図１９に示す。

Ｓ２３：次に、カード会社システム１（更新部１０４）は、カード利用額集計処理を行う。具体的には、図１３のＳ７と同様のカード利用額集計処理をここで行う。理由は、Ｓ２２において、カード利用履歴テーブルが更新されたためである。具体的に例えば、加盟店からの売上請求に基づき「売上請求日」が入力されたため、カード利用額集計テーブル上の「売上請求済金額」、「売上未請求金額」が変わっている。また、提携団体システム３から、売上請求（使用料金の通知）がなされている場合、カード利用額集計テーブル上、新しいカード利用履歴が追加記録されている。カード利用額集計処理により、Ｓ２２で更新記録されたカード利用履歴テーブルに基づいて、カード利用額集計テーブルを最新の状態に更新する。

Ｓ２４：カード会社システム１（売上請求処理部１０２）は、店舗端末２又は提携団体システム３に対し、売上請求処理の処理結果を通知する。処理結果は、例えば処理ＯＫ又は処理ＮＧがあるが、通常特段の問題が無ければ、処理ＯＫが通知され、加盟店側でもその旨が認識される。

（３）照会処理
図２０は、本実施形態に係る照会処理を説明するフローチャートである。照会処理が実施される場面としては、クレジットカードの利用者（会員）が利用者端末４を用いて、カード会社システム１に「ユーザＩＤ」、「照会パスワード」を用いてアクセスし、Ｗｅｂ画面を通じて、支払い情報などの照会を行う場面である。

Ｓ３１：利用者は、利用者端末４を用いて、カード会社システム１（Ｗｅｂサーバを含む）に対しアクセスし、例えば、会員ページ等のＷｅｂ画面上、ログインする。利用者は、ログイン時、「ユーザＩＤ」、「照会パスワード」を入力する。

Ｓ３２：カード会社システム１は、ログイン要求を受信すると、入力された「ユーザＩＤ」、「照会パスワード」に基づいて認証処理を実施する。具体的には、会員属性テーブル（例えば、図６）を参照し、入力された「ユーザＩＤ」、「照会パスワード」が登録されている場合、認証処理を成功させる。

Ｓ３３：カード会社システム１は、認証結果に応じて処理を分岐する。認証ＮＧの場合、Ｗｅｂ画面上、認証エラーを応答する。

Ｓ３４：カード会社システム１は、認証ＯＫの場合、対象の「カード番号」を抽出する。具体的には、カード管理情報テーブル（例えば、図７）を参照し、入力された「ユーザＩＤ」に対応する「カード番号」を特定する。この「カード番号」は、入力された「ユーザＩＤ」を有する利用者のクレジットカード番号である。

Ｓ３５：カード会社システム１（通知部１０５）は、カード利用額集計テーブルを参照し、抽出した「カード番号」の支払い情報を取得する（利用者がＷｅｂ画面上「支払い情報」メニューを選択）。支払い情報は、カード利用額集計テーブルに含まれる情報であって、具体的に、対象の「カード番号」の、「年月」、「売上請求済金額」、「売上未請求金額」、「月払い予想金額」、「予想総額」、「利用可能残高」などのデータ項目値である。

Ｓ３６：カード会社システム１（通知部１０５）は、利用者端末４に対し、取得した支払い情報を通知（送信）する。この結果、利用者端末４のＷｅｂ画面上、支払い情報等が表示される（例えば、図１２（ｃ）参照）。

このように、クレジットカードの利用者（会員）は、利用者端末４を用いて、Ｗｅｂ画面を通じて、支払い情報などの照会を行う場面である。上述したように、支払い情報は、買い物時の売上票（レシート）やメールで参照できるが、Ｗｅｂ画面では、利用者が所望する時にいつでも支払い情報を参照できる。

[補足]
ここで、再び図１２（ａ）〜（ｃ）を参照する。これら売上票（レシート）、メール、Ｗｅｂ画面の支払い情報は、これまで説明したように、カード利用額集計テーブルに基づくデータ項目値から取得され、通知された結果である。

例えば、図１２（ａ）〜（ｃ）と、図１６とを比較する。具体的な対応関係は、以下の通りである。
「引落予想総額」←「予想総額」
「利用可能残高」←「利用可能残高」
「引落確定額」←「売上請求済金額」
「引落未確定額」←「売上未請求金額」
「公共料金等」←「月払い予想金額」
なお、カード利用額集計テーブルの「月払い予想金額」において、フラグ（確）がない場合、メール及びＷｅｂ画面への掲載上、金額の後ろに（予想額）の文字を付す。フラグ（確）がある場合、金額の後ろに（確定額）の文字を付す。

また、「月払い予想金額」は、フラグ（確）の有無によって、「売上未請求金額」又は「売上請求済金額」のいずれかに分類できる。フラグ（確）がない場合は、「月払い予想金額」は、あくまで過去履歴等に基づく予想金額である。つまり、月払いの提携団体から売上未請求である（今月の使用料金は未通知）。よって、フラグ（確）がない場合は、「月払い予想金額」は、「売上未請求金額」に分類できるため、「売上未請求金額」（＝「引落未確定額」）に組み入れてもよい。

一方、フラグ（確）がある場合は、「月払い予想金額」は、月払いの提携団体から売上請求済である（今月の使用料金は通知済）。よって、フラグ（確）がある場合は、「月払い予想金額」は、「売上請求済金額」に分類できるため、「売上請求済金額」（＝「引落確定額」）に組み入れてもよい。

[総括]
以上、本実施形態によれば、クレジットカードの使用時、利用者に対し、カード利用に関する支払情報を通知できるカード支払情報通知システム、カード支払情報通知方法及びカード支払情報通知プログラム等を提供することが可能となる。なお、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１ カード会社システム
２ 店舗端末
３ 提携団体システム
４ 利用者端末
５ 通信ネットワーク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 補助記憶装置
１５ 記憶媒体読取装置
１６ 入力装置
１７ 表示装置
１８ 通信装置
１０１ 売上承認処理部
１０２ 売上請求処理部
１０３ 記憶部
１０４ 更新部
１０５ 通知部

Claims (10)

1. クレジットカードの支払い情報を通知するカード支払情報通知システムであって、
   売上承認要求装置から、少なくとも、クレジットカードの利用金額を含む売上承認要求を受信し、売上承認処理を実行する売上承認処理手段と、
   売上請求装置から、前記売上承認処理された利用金額の売上請求を受信し、売上請求処理を実行する売上請求処理手段と、
   前記売上承認処理された利用金額、前記売上請求装置から売上請求された売上請求日、及び、前記売上承認処理された利用金額が引き落とされる引落予定日、を対応付けて記憶する記憶手段と、
   前記記憶手段を参照し、前記売上承認処理がなされたときは、当月を指定月として、前記引落予定日が前記指定月であって前記売上請求日が空欄でない前記売上承認処理された利用金額を合計して前記売上請求処理された利用金額を集計し、
   前記引落予定日が前記指定月であって前記売上請求日が空欄の前記売上承認処理された利用金額を合計して前記売上承認処理された利用金額を集計し、
   前記指定月を１つ大きくした場合に前記指定月が最も未来の前記引落予定日よりも大きくなるまで、前記売上請求処理された利用金額及び前記売上承認処理された利用金額の集計を前記指定月ごとに繰り返し行う更新手段と、
   前記指定月ごとに集計された、前記売上承認処理された利用金額と、前記売上請求処理された利用金額とを通知する通知手段と、
   を有することを特徴とするカード支払情報通知システム。
2. 前記売上請求処理手段は、前記売上請求装置から、前記売上承認処理されていない利用金額の売上請求を受信し、売上請求処理を実行し、
   前記記憶手段は、前記売上承認処理されていない利用金額を含むカード利用履歴を記憶し、
   前記更新手段は、前記カード利用履歴に基づいて、前記売上承認処理されていない利用金額の平均利用金額を算出し、前記記憶手段において、該平均利用金額を、前記売上承認処理された利用金額に加算すること、
   を特徴とする請求項１記載のカード支払情報通知システム。
3. 前記通知手段は、前記売上承認処理がなされたとき、前記売上承認要求装置に対し、前記売上承認要求の結果応答として、前記売上承認処理された利用金額と、前記売上請求処理された利用金額とを通知すること、
   を特徴とする請求項１又は２記載のカード支払情報通知システム。
4. 前記通知手段は、前記売上承認処理がなされたとき、前記クレジットカードの利用者端末に対し、前記売上承認処理された利用金額と、前記売上請求処理された利用金額とを通知すること、を特徴とする請求項１ないし３何れか一項記載のカード支払情報通知システム。
5. 前記通知手段は、前記売上承認処理がなされ、前記クレジットカードの利用者端末から照会要求がなされたとき、該利用者端末に対し、該照会要求の結果応答として、前記売上承認処理された利用金額と、前記売上請求処理された利用金額とを通知すること、
   を特徴とする請求項１ないし３何れか一項記載のカード支払情報通知システム。
6. 前記通知手段は、前記売上承認処理された利用金額が、加盟店から規定の売上請求日迄に前記売上請求処理された場合の、該利用金額の引落日を通知すること、
   を特徴とする請求項１ないし５何れか一項記載のカード支払情報通知システム。
7. 前記通知手段は、前記売上承認処理された利用金額と前記売上請求処理された利用金額とを加算した引落予想総額を通知すること、
   を特徴とする請求項１ないし６何れか一項記載のカード支払情報通知システム。
8. 前記記憶手段は、前記クレジットカードの利用限度額を記憶し、
   前記通知手段は、前記利用限度額から前記引落予想総額を減算した利用可能残高を通知すること、を特徴とする請求項７記載のカード支払情報通知システム。
9. クレジットカードの支払い情報を通知するカード支払情報通知方法であって、
   カード支払情報通知システムは、
   売上承認要求装置から、少なくとも、クレジットカードの利用金額を含む売上承認要求を受信し、売上承認処理を実行する売上承認処理手順と、
   売上請求装置から、前記売上承認処理された利用金額の売上請求を受信し、売上請求処理を実行する売上請求処理手順と、
   前記売上承認処理された利用金額、前記売上請求装置から売上請求された売上請求日、及び、前記売上承認処理された利用金額が引き落とされる引落予定日を対応付けて記憶する記憶手段において、前記売上承認処理がなされたときは、当月を指定月として、前記引落予定日が前記指定月であって前記売上請求日が空欄でない前記売上承認処理された利用金額を合計して前記売上請求処理された利用金額を集計し、
   前記引落予定日が前記指定月であって前記売上請求日が空欄の前記売上承認処理された利用金額を合計して前記売上承認処理された利用金額を集計し、
   前記指定月を１つ大きくした場合に前記指定月が最も未来の前記引落予定日よりも大きくなるまで、前記売上請求処理された利用金額及び前記売上承認処理された利用金額の集計を前記指定月ごとに繰り返し行う更新手順と、
   前記指定月ごとに集計された、前記売上承認処理された利用金額と、前記売上請求処理された利用金額とを通知する通知手順と、を有することを特徴とするカード支払情報通知方法。
10. 請求項９記載のカード支払情報通知方法をコンピュータに実行させるカード支払情報通知プログラム。
    

Images