以下、添付図面を参照して、本発明を実施するための形態(以下、実施形態)について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。
<第一の実施形態>
図1は、本発明の第一の実施形態に係るシステム(以下、本システムと呼ぶ)の基本構成の概念を示す図である。図中のブロック間の矢印は、データの流れ方向又は処理の流れ方向を表している。また、点線のブロックと点線の矢印は、本システムにオプションとして備えることが望ましい構成を示している。また、一点鎖線の矢印は、始点にあるボタンを押下した際に、表示される画面を指し示すものとする。
本システムは、サービス提供側のシステムとして、利用者が口座を持つ銀行の銀行システム100、銀行のATM150、利用者が利用するクレジットカードのクレジットカード会社システム200、カードが利用可能な店舗のPOS端末250(Point Of Sale端末)が、交信可能にネットワーク接続される。ネットワークは、金融機関の場合、専用ネットワークが主であるが一部汎用ネットワークであってもよい。また、銀行、クレジットカード会社以外のシステムとして、カードローンを取り扱うカードローン会社システム160、キャッシングを取り扱う消費者金融会社等システム400、ネット上のショッピングモールや価格比較サイト等の通販サービス会社システム500がネットワークに直接的または間接的に接続されて、それぞれの情報の提供を受けられるようにしてもよい。ただし、通販サービス会社システム500は、専用ネットワークではなくインターネットを介して利用者端末350に接続され、利用者が購入済の商品情報又は購入検討中の商品の情報を通販サービス会社システム500から受信する。カードローン会社システム160は、銀行本体が扱うカードローンである場合は、銀行システム100の一部としてもよい。なお、キャッシングとカードローンの主な違いは、借入額の総量規制(出願時においては年収の3分の1)の対象となるか否かであるが、本システム上での違いは特にない。
利用者側のシステムとしては、ATM150とPOS端末250から読み書き可能なICチップ搭載の利用者カード300と、予め利用者カード300と紐付けてシステムに登録された利用者端末350とで構成される。本システムで利用される利用者カード300は、キャッシュカードとクレジットカードが一体となったICカードが望ましい。また、利用者カード300は、カードを読み込ませた際に、ATM150又はPOS端末250からデータを受け取って、カード内部に記憶するデータ記憶手段301を備えるものとする。また、利用者カード300は、ATM150、POS端末250、利用者端末350と非接触でデータを読み書き可能な近距離無線通信手段303(NFC:Near Field Communication)を備えることが望ましい。これは、利用者端末350に、ATM150又はPOS端末250から取得したデータを転送して、データを表示させたり、そのデータを分析して、加工したりするためである。
利用者端末350は、一般的なスマートフォンやタブレット端末であってもよいが、利用者カード300と紐付けされて、すなわち、カード番号と端末識別子が関連付けされて、本システムに登録済みであるとする。もちろん、利用者端末350の内部にカード機能を有していてもよいが、先に述べたように、カード型の媒体は、将来もなくなることはないと考えられるので、端末とカードとを共存させ、かつ連携手段を有していることが望ましい。連携手段とは、例えば、システムから受信したデータをいったんカード内の記憶手段に保存しておき、その後、端末側からカード内のデータを読み出す手段を備えることを意味する。
また、利用者端末350は、携帯型が望ましく、ATM150やPOS端末250との通信が可能な近距離無線通信手段(以下、単にNFCと呼ぶこともある)を備えているものとする。このことにより、ATM150やPOS端末250が、NFCを備えず、スマートフォン等に対応していない場合にはカードで決済し、ATM150やPOS端末250がNFCを備え、カード機能を持ったスマートフォン等に対応している場合には、利用者端末350だけで銀行口座取引やカード決済を行うことができる。このとき、ATM150及びPOS端末250のNFCは、利用者端末350に対する収支データ(口座残高や入出金の明細を含むデータ)の送信手段として機能し、さらにカードに対する収支データの書込手段として機能する。
また、利用者端末350は、通常、インターネット接続機能を有しているので、ATM150やPOS端末250経由でなく、通販サービス会社システム500からも直接データを取得するようにしてもよい。このことにより、単に口座の利用状況だけでなく、購入を検討している商品の価格情報を取得し、口座残高の変動を見ながら適切な購入タイミングを判断することができるようになる。これについては、後述の具体例で詳しく説明する。
また、銀行システム100やクレジットカード会社システム200共、それぞれのWebサイト経由で直接、明細データ(Web明細)を取得するようにしてもよい。ただし、クレジットカードの場合は、店舗側の売上計上のタイミングやPOS端末の種類、利用者が契約しているカード会社と店舗が契約しているカード会社とが異なる場合のカード会社間の伝送処理等により、買い物の決済データ(売上計上データ)が必ずしも直ちにクレジットカード会社のWebサイトに反映されるわけではないので、Web明細は、POS端末250からの買い物決済データと併用するようにすることが望ましい。このことについては、図2で後述する。
銀行カードの場合は、通常このようなタイムラグはないが、現金での取引のデータは、ATM150からその場でカード経由若しくは直接、利用者端末350に取得することが可能であるが、カードを使用せずインターネットバンキングから振り込んだような場合には、銀行のWebシステムから今回の振込のデータを直ちに取得するようにする。
利用者が、ATM150の操作画面から出金要求のボタン(現金引き出しの場合又は口座から引き出して振込をする場合)を操作し、利用者カード300をATM150のカード読取部にタッチ又は近接させて暗証番号等の認証が終わると、その出金要求がATM150を経由して、銀行システム100に送信される。銀行システム100は、通常、出金要求が引き出しの場合は、現金の引き出しをATM150に指示し、出金要求が口座からの振込の場合は、口座間の資金移動の処理を実行する。しかし、銀行システム100は、この処理を実行する前に、今回の出金を実行した場合の口座の収支データをまずATM150に送り、ATM150は、収支データ中に含まれる当月の最低予想残高を表示し、今回の出金を行うと最低予想残高がマイナス若しくは所定金額以下になるような場合には、その旨をATM画面に表示させ、利用者に注意喚起し確認を求める。そして、利用者がこのATM画面で「はい」のボタンを押した場合に初めて処理が実行されるが、「いいえ」のボタンを押した場合はその処理がキャンセルされる。
また、このときのATM画面には、「予想明細」ボタンが表示されるようにしてもよい。利用者がこのボタンを押すと、例えば、図示するような予想残高明細を表示する。表示先は、ATM画面だけでなく、利用者端末350や、場合によっては、利用者カード300であってもよいが、利用者カード300に予想残高明細等を表示させる形態については、第二の実施形態として詳しく説明する。予想残高明細には、現在確定している入出金の明細だけではなく、過去の履歴情報中の入出金の傾向(入出金パターン)からみて当月中に発生することが予想される入出金の明細と、その明細及びその入出金パターンに基づいて算出した当月又は所定期間内の最低予想残高(現時点での残高や月末の残高ではない)が含まれる。当月だけでなく、翌月、翌々月の最低予想残高を含むようにしてもよい。この予想残高明細の表示画面については、後述の具体例で詳しく説明する。
本システムでは、銀行システム100と提携先のクレジットカード会社システム200が連携しているので、同じ利用者においては、お互いのシステムの利用明細のデータを交換することができる。すなわち、ATM画面に表示される利用明細には、銀行口座の利用明細だけでなく、クレジットカードの引き落とし予定額(次回の引落の確定額、次々回の引落の未確定額を含む)や、消費者金融等の返済予定額を含ませることができる。なお、既に述べたように、予想明細を作成する基となる収支データは、ATM150から利用者カード300に書き込んだり、カードに紐付けられた利用者端末350に送信してもよい。
利用者カード300をクレジットカードとして利用する場合も基本的には同様であり、買い物の決済の際に、利用者カード300が店舗のPOS端末250に読み込まれると、商品代金の決済要求がクレジットカード会社システム200に送信される。クレジットカード会社システム200は、銀行システム100から利用者の引落先口座を特定し、その利用明細を受信して収支データをPOS端末250に送信する。POS端末250では、収支データに基づいて、POS端末画面に表示する他、利用者カード300に書き込んだり、利用者端末350に送信することもできる。
POS端末画面では、図示するように、ATM画面とは違って、「リボ払い」ボタンや「分割回数変更」ボタンを表示させるようにしてもよい。ただし、図示するような注意喚起等のメッセージは、POS端末の形状や設置場所によって店員も見ることができる場合は、POS端末画面には表示させず、利用者端末350だけに表示させるようにしてもよい。すなわち、POS端末画面には、注意喚起があることのみが表示され、注意喚起の内容自体は、利用者端末350のほうで確認してもらうようにする。
図2は、図1で説明したシステムを機能ブロックに分けてより詳細に説明したものである。以下、機能ブロックについて順に説明する。まず、銀行システム100の主な構成としては、ATM通信手段101、予想残高算出手段102、取引明細取得手段103、入出金傾向抽出手段104、使途別枠抽出手段105、他システム連携手段106、Web明細提供手段107、未計上POSデータ加算手段208で構成される。
ATM通信手段101は、ATM150との通信を制御し、データの送受信を行い、ATM150に指示を与えたり、銀行システム100内に要求を伝えたりする役目を果たす。
予想残高算出手段102は、利用明細から当月及び当月以降の予想残高を算出する。このとき、下記の取引明細取得手段103、入出金傾向抽出手段104、使途別枠抽出手段105を呼び出し、算出データの基礎とする。予想残高の算出結果は、ATM150に送信され、利用者端末350に表示される。ATM150経由で利用者端末350に表示させるようにしてもよい。
取引明細取得手段103は、口座の取引明細データベース110並びに口座振替情報データベース111から利用者の銀行口座における取引明細データを取得する。取引明細データベース110には、当月及び一定期間の過去の取引明細を含んでいる。また、口座振替情報データベース111には、公共料金、住宅ローン、カーローン、保険料等定期的に口座振替によって引き落とされる情報を含んでいる。
入出金傾向抽出手段104は、過去の利用明細から当月及び当月以降の収入及び支出の入出金傾向を抽出する。例えば、夏場は電気料金の引落額が多くなるとか、夏休みや年末年始の期間は現金の引き出しやクレジットカードの引落額が多くなるといった傾向を抽出する。収入に対しても、残業代、賞与、児童手当、年金等の毎月入るとは限らない収入がある日とその金額を抽出する。
使途別枠抽出手段105は、利用明細の各項目を使途別(ジャンル又はカテゴリ)に分けて管理する機能を提供する。例えば、変動する支出を、食費、衣服費、娯楽費、通信費等に分けて、それぞれの支出限度枠を別途登録しておけば、その限度枠を超えそうな場合は、最低予想残高の表示と共に、注意喚起やアドバイスのメッセージを表示させることができる。
他システム連携手段106は、クレジットカード会社システム200、消費者金融会社等システム400との利用明細のデータを交換する役目を果たす。例えば、ATM150で読み取った利用者カード300のカード情報から提携するクレジットカードが有ると判断された場合は、そのクレジットカード会社に利用明細の照会依頼を送信し、銀行口座の取引明細に反映されていないクレジットカードの引落予定があれば予想残高を補正する。なお、照会できるデータは、利用明細の参照用データのみとし、個人情報や資金移動のためのデータが含まれないのは当然である。なお、システム間の相互認証手段や機密保護手段については公知の技術を利用するものとする。
Web明細提供手段107は、既存のインターネットバンキング用のWebサイトを利用し、予想残高等のデータを利用者端末350に提供する役目を果たす。この場合は、銀行のWebシステムがWeb明細として利用者に一般的に提供するデータに、上記のような予想残高等のデータが付加される。
未計上POSデータ加算手段208は、前述したように、クレジットカードで買い物をしても、利用者が参照可能なWeb明細に反映されるまでにはタイムラグがあることに対処するための手段である。すなわち、未計上POSデータ加算手段208は、POS端末250から買い物時のデータを取得した際に、Web明細提供手段207が保持する最新の利用明細データと、POS端末250から取得したPOS端末データを突合し、クレジットカードの利用明細に存在しない未計上POSデータが存在するかどうかチェックし、未計上POSデータが存在する場合は、未計上POSデータをクレジットカードの次回以降の請求分利用明細に加算する。
ATM150は、カード読取装置等のカード情報読取手段151、タッチパネルや物理ボタン等の表示/入力手段152の他、利用者端末350との近距離通信機能を有する近距離無線通信手段153を備えることが望ましい。この場合、近距離無線通信手段153は、カード読取手段及びカード書込手段としても機能させることができる。
クレジットカード会社システム200は、主な構成としては、POS端末通信手段201、予想残高補正手段202、利用明細取得手段203、利用傾向抽出手段204、使途別枠抽出手段205、他システム連携手段206、Web明細提供手段207、利用明細データベース210、リボ/分割払情報データベース211で構成される。
予想残高補正手段202は、銀行口座の取引明細にはまだ表れていない将来発生予定のクレジットカード引落額を銀行口座の予想残高に反映する。つまり、引き落とされることが確定している次回引落額と、確定はしていないが次々回に引き落とされる予定の引落額を算出して上記の予想残高に対して補正する。すなわち、利用者が買い物をしたときの決済要求をPOS端末250から受信した際、又は銀行システム100からクレジットカードの利用状況の照会依頼を受信した際に、所定期間のクレジットカードの利用明細データを取得し、クレジットカードの利用明細データに基づいて、利用者の銀行口座の対応する所定期間の予想残高を補正する。なお、未確定の引落額は、日々更新されるので、照会時期によって補正する値が異なることになる。予想残高の補正結果は、銀行システム100又はPOS端末250に送信される。POS端末250経由で利用者端末350に送信し、表示させるようにしてもよい。なお、クレジットカード会社システム200のその他の機能ブロックについては、銀行システム100と大差はないのでここでは説明を省略する。
POS端末250は、カード読取装置等のカード情報読取手段251、タッチパネルや物理ボタン等の表示/入力手段252の他、利用者端末350や利用者カード300との近距離通信機能を有する近距離無線通信手段253を備えていることが望ましい。この場合、近距離無線通信手段253は、カード読取部及びカード書込部としても機能させることができる。
利用者カード300は、先に説明したように、データ記憶手段301の他、ATM150、POS端末250、利用者端末350とのデータ送受信を可能とする近距離無線通信手段303を備えていることが望ましい。
利用者端末350は、端末にデータ分析やデータ収集のためにインストールされた専用アプリケーションであるデータ分析手段351及び購入検討商品情報収集手段354を備えており、また、利用者カード300やATM150、POS端末250やデータ通信を可能とする近距離無線通信手段353を備えているものとする。
消費者金融会社等システム400は、銀行又はクレジットカード会社のグループ又は両者と提携するキャッシングサービスを主に提供する会社のシステムである。消費者金融会社等システム400も銀行システム100又はクレジットカード会社システム200との連携手段を有しているものとする。
通販サービス会社システム500は、銀行やカード会社のような金融機関ではなく、ネット販売における様々な情報サービスを提供する会社のシステムである。具体的には、通販を行う個々の会社の通販サイト、ショッピングモールのサイト、価格比較サイト等がある。既に述べたように、通販サービス会社システム500は、インターネットを介して、利用者端末350に、主に商品情報を提供するが、クレジットカード会社システム200の他システム連携手段206を介して、クレジットカード会社にも情報を提供するようにしてもよい。
以上、上記の本システムの機能構成は、あくまで一例であり、一つの機能ブロック(データベース及び機能処理部)をさらに分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたCPU(Central Processing Unit)が、ROM(Read Only Memory)又はハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読出し、CPUにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース(DB;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア(例えば、入出力装置、表示装置、通信インターフェース装置)を制御することによって実現される。また、本発明の実施形態に係るデータベース(DB)は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。
図3は、銀行口座取引明細テーブル600の具体例を示す図である。銀行口座取引明細テーブルとは、所定期間毎(通常は月毎)に口座の入出金の項目を記録したテーブルである。図示するように、テーブルの各項目は、通常は、通帳に記入される項目であるが、本システムの銀行口座取引明細テーブル600は、過去の履歴だけでなく、将来の予測データも含むことができる。すなわち、銀行口座取引明細テーブル600は、所定期間(少なくとも1年間)の現在、過去、未来の取引データ又はその予測データを含み、取引明細データベース110に格納される。例えば、現時点が5月中旬であるとすると、5月末での予想残高を算出して、当月収支として、このテーブルに格納する。当月収支は、次の月においては前月末残高として繰り越される。
また、このテーブルには示していないが、各項目の日々の入出金予想から、当月中の予想最低残高も求めることができる。利用者がサラリーマンの場合は、給料日の直前が予想最低残高となることが多いが、予想最低残高がマイナスになることは、支払不能となる可能性が高いことを意味し、避けなければならない。将来の予測データは、過去の入出金傾向(入出金パターン)から求めることを基本とするが、利用者端末350等から、利用者が予測データを追加、訂正、削除することができる手段が提供される。また、上記の所定期間のデータは、利用者端末350にダウンロードする手段を備えてもよい。
図4は、銀行口座以外の利用明細テーブルの具体例を示す図である。以降では、銀行口座の入出金の明細データは、取引明細と呼び、銀行口座以外の明細データは、利用明細と呼び、区別することとする。銀行口座以外の利用明細には、クレジットカード、消費者金融系カード、及び購入検討商品の予定情報等が挙げられる。銀行口座の取引明細データベース110には、銀行口座で直接入出金が行われたデータは記録されるが、クレジットカード引落の利用明細までは記録されないので、クレジットカードA,Bの利用明細テーブル610,620は、クレジットカード会社システム200から取得する。消費者金融系カードの利用明細テーブル630についても同等である。なお、クレジットカード及び消費者金融カードは、本システムが提携している会社のカードであれば、複数であってもよい。
購入検討商品テーブル640は、上記の金融機関系のシステムから得られる情報ではなく、通販サービス会社システム500から、利用者端末350を使って得られる情報である。購入検討商品テーブル640は、後述する将来の商品の購入時期や支払方法等をアドバイスするための基礎データとして利用される。このような購入商品検討情報は、利用者が通販サイトで過去に入力した「ウィッシュリスト」、「欲しい物リスト」、「買物候補リスト」等から、当サイトの会員であれば利用者の利用者端末350にダウンロードすることができる。通販サービス会社は、複数であってもよく、また、必ずしも本システムに提携する事業者でなくともよい。ただし、各通販サイトからダウンロードした情報は、利用者端末350の内部で、上記のテーブル形式に収集/加工して保存しておくと、後述する支出管理処理が行い易くなる。
図5は、銀行システム100の処理の概略を示す図である。ここでいう処理とは、銀行システム100が、ATM150から出金要求を受けてから収支データを利用者側に表示させるまでの処理を言う。なお、以降に示すフローチャートの各処理ステップは、必ずしも図示した順序で行う必要はなく、各ステップのインプットとアウトプットの関係を損なわない限り、処理順序を入れ替えてもよい。
銀行システム100は、まずステップS10において、利用者の操作が口座からの出金を伴う操作であった場合には、ステップS11に移り、利用者カード300から口座番号、カードの種類、提携する他のカードの有無、カードに紐付いた携帯端末の有無等のカード情報を受信する。次に、ステップS12において暗証番号等により認証が完了すれば、ステップS14に移り、受信したカード情報から一体型カード又は提携カードの有無がチェックされる。ステップS12において認証ができなかった場合は、暗証番号の再入力を求めるが、所定回数以上認証ができなかった場合には(ステップS13:Y)、所定のエラー処理を行う。
ステップS14において、ATM150で読み込んだカードがキャッシュカード機能だけでなく、クレジットカード機能等、その他のカード機能を合わせ持つ一体型カードである場合、あるいはキャッシュカードに提携カードの登録があると判断された場合は、ステップS15に進み、提携カードの利用明細データを取得する。ICチップ内蔵の一体型カードの場合は、カード読取部にタッチ又は近接させるだけなので、従来の磁気ストライプ型のように、カードの挿入向きを利用目的によっていちいち入れ替えなくてもよい。提携カードが複数ある場合は、全ての提携カードの利用明細を取得するようにしてもよいし、明細を表示したい提携カードだけをATM150に順次読み込ませるようにしてもよい。
当銀行口座を引落先にしている提携カードの場合は、銀行口座に引落記録が残っているので、銀行口座の取引明細で現時点のカードの利用状況は判断できる。しかし、クレジットカードの場合は、引落額が確定しているが所定の引落日までまだ期間があるため引落が実行されていないものがある。また、クレジットカードの利用はあるものの、締日までにまだ期間があるため引落額自体が確定していないものもある。また、当銀行口座を引落先にしていない提携クレジットカードも考えられる。このため、ステップS15において、クレジットカードについてはそのカードのシステムに明細照会要求を送信し、所定期間内の利用明細データを必ず取得する。
ステップS14において、一体型カードでも提携カードの登録もないと判断された場合は、ステップS16において、キャッシュカードの銀行口座の取引明細だけを取得する。銀行口座の取引明細及び各提携カードの利用明細が取得されると、ステップS17において、過去の取引履歴から銀行口座の入出金パターンを抽出する。
次に、ステップS18において、先に述べたように、過去の入出金パターン及び利用者端末350からの追加・修正情報に基づいて、予想残高を算出する。そして、ステップS19において、支出管理処理を呼び出す。支出管理処理については後述の図7で説明する。
ステップS19の支出管理処理から戻ると、ステップS20において、利用者カード300(この場合はキャッシュカード)の種類を判別し、表示機能付きのカードの場合は、ステップS21において、カードに収支データを書き込む。表示機能がない場合は、ステップS21の処理をスキップする。
そして、ステップS22において、利用者カード300に紐付された利用者端末350が登録されているかどうかをチェックする。登録があれば、ステップS23に移り、利用者端末350に収支データを送信する。登録がない場合は、ステップS24に移り、ATM150に収支データを表示させる。受信した収支データは、それぞれ受信側の表示手段に合わせて加工/整形され、表示されることになる。
図6は、クレジットカード会社システム200の処理の概略を示す図である。ここでいう処理とは、クレジットカード会社システム200が、POS端末250からカードの認証要求(オーソリ依頼)を受けてから、収支データを利用者側に表示させるまでの処理を言う。
クレジットカード会社システム200は、まずステップS30において、POS端末250から決済要求があるかどうかをチェックする。決済要求があれば、ステップS31において、POS端末250が読み込んだカード情報を受信する。次にステップS32おいて読み込んだカードが一体型カードであるか、あるいは提携銀行カード(キャッシュカード)がシステムに登録されているかどうかをチェックする。ステップS32のチェックにおいて一体型カードでもなく提携銀行カードもない場合は、ステップS33に移り、通常のクレジットカードの支払処理をして処理を終了する。
ステップS32のチェックにおいて一体型カード又は提携銀行カードが有る場合は、ステップS34に移り、利用者に、一体型カード又は提携銀行カードをデビットカードとして使用して支払をするか、あるいは一体型カードをクレジットカードとして支払うかどうかの確認を行う。
一体型カードをクレジットカードとして支払う場合、又は提携銀行カードが有ってもクレジットカードで支払う場合は、ステップS38に移り、クレジットカードでの支払いであることを決定し、ステップS39において、銀行口座の情報を取得するかをさらにチェックする。銀行口座の情報を取得する場合は、ステップS35に移るが、そうでない場合は、ステップS36に移る。この場合は、銀行口座の情報を取得していないので、クレジットカードとしての利用状況を確認するのみとなる。
一体型カードをデビットカードとして支払う場合は、又は提携銀行カードをデビットカードとして支払う場合は、ステップS35に移り、提携銀行の口座、すなわち、引落先の銀行口座の最新の予想残高、利用傾向を含んだ取引明細データを取得する。そして、ステップS36において、クレジットカードの利用明細データを取得する。さらにステップS37において、クレジットカードの利用傾向(利用パターン)を取得する。
そして、ステップS40において、上記で取得した各種データに基づいて、銀行口座の予想残高に反映されていないクレジットカードの引落があれば、クレジットカードの最新利用明細を参照し、銀行口座の所定期間の予想残高を補正する。もちろん、今回の支払がクレジットカードの場合は、その支払金額を銀行口座の引落日における予想残高に反映する。今回の支払がデビットカードの場合は、銀行口座の本日の予想残高をそのまま更新する。
以上がクレジットカード会社システム200における主な処理であるが、ステップS41の支出管理処理、及びステップS42以降の収支データの表示処理は、図5の場合とほぼ同様なので説明を省略する。ただし、表示する内容は、表示先の装置の表示能力及び利用者の選択により変更可能とする。例えば、ステップS46において、POS画面に収支データを表示する際、他人からの盗み見を防止するため、POS画面には収支データを表示せず、利用者端末350の照会を促すようなメッセージのみを表示してもよい。
図7は、銀行システム100又はクレジットカード会社システム200における支出管理処理のフローを示す図である。支出管理処理は、図5のステップS19又は図6のステップS41において実行される処理である。ここでは、まずステップS50において、銀行口座の残高目標が設定されているかどうかをチェックする。残高目標が設定されている場合は、ステップS51において、残り支出可能額を算出する。例えば、当月の予想残高が11万円、残高目標が5万円である場合には差額の6万円が支出可能額として、後述する予想残高表示画面に表示する。
次に、ステップS52において、クレジットカード毎に利用限度の目標があるかをチェックする。例えば、クレジットカード毎に使用用途を分けている場合には、ステップS53において、使用用途毎の支出可能額を算出する。通常、クレジットカード毎に、締日と引落日とが異なるので、それらの日程も考慮して、支出可能額を算出する。このようにすることで、例えば、クレジットカードAの締日は15日、引落日は翌月の27日であり、クレジットカードBの締日は25日、引落日は翌々月の20日であったとすると、翌月の予想残高に応じて、クレジットカードBは、25日までに○○円使用可能だが、クレジットカードAは、15日まで使用不可とする等の注意喚起やアドバイスを予想残高表示画面に表示させることができるようになる。
次に、ステップS54においては、ジャンル別の管理を行うか否かをチェックする、ジャンル別管理とは、クレジットカード毎には利用限度を定めていないが、クレジットカードで購入する商品をジャンル毎に管理することを定めている場合には、ステップS55において、1又は複数のクレジットカードの購入商品をジャンル毎に分類し、ジャンル毎の支出可能額を算出する。このようにすることで、ジャンル毎の購入状況を予想残高表示画面に表示することができるようになる。
また、ステップS56において、欲しい物リスト(ウィッシュリスト)が取得されていれば、ステップS57において、その商品の価格変動を価格比較サイト等から取得し、予想残高に基づいて、その商品を購入可能な時期を算出することができる。このとき、購入検討商品が家電製品のように値下がりの傾向があるときは、その商品が販売終了となる直前を最適な購入時期としてアドバイスすることもできる。
図8は、予想残高表示画面の具体例1を示す図である。図示する予想残高表示画面800では、2013年10月を現時点(当月)とした確定残高、予想残高、対策加味残高を示している。確定残高とは、現時点で金額で確定している項目の合計であり、既に今月、口座に入出金が行われた項目と、これから今月末までに確実に入出金が行われる項目の合計である。予想残高は、金額は確定していないが、過去の入出金パターンから確実にこれから発生する入出金の金額を確定残高に加えたものである。図の例では、追加のATM出金、電気料金、ガス料金、電話料金別等、別のクレジットカードの引落分がこれに該当する。給与については、確定残高としては、基本給の金額のみを考慮し、残業代等の変動部分は、予想残高に加えるようにしている。
対策加味残高とは、予想残高に対して、変動支出の削減や支払時期の延長等なんらかの対策を加味した場合の残高である。図の例では、ATMからの追加の出金分を半減し、電気代とガス代を例年同時期の金額ではなく最悪ケースで見積もった場合の金額を採用し、給与の残業代の部分をゼロと仮定し、さらにクレジットカードの支払方法をリボ払にする等した対策を取った場合の残高を示している。すなわち、対策加味残高とは、収入については、最も低いケースを想定するものとし、当月支払の光熱費等(実際には先月の使用分)現時点では既に対策のとれない支出については最悪ケースを想定し、ATMからの出金追加分やクレジットカードの支払方法の変更等なんらかの対策をとれる項目については、所定の割合で削減する等した場合の予想残高である。もちろん、対策には様々な方法があり、その組合せ方も変えることができるので、対策加味残高を1種類に限る必要はない。なお、図示する当月収支は、月末時点での残高を示している。もちろん、給与受け取り前等、最低予想残高がマイナスになる場合には、その旨の警告が発せられる。
図9は、予想残高表示画面の具体例2を示す図である。図示する予想残高表示画面810では、前図の対策加味予想残高に代えて、目標設定残高を示している。目標設定残高とは、当月収支(月末残高)の目標を予め定め、それを達成するために、対策を取ることをアドバイスすることを目的としたものである。図の例では10万円とし、前図の場合と同じ対策をとった場合に、ATMからの現金支出は最大いくらまで可能かを示したものである。
なお、この例では、全体の目標残高を定め、そのために現金支出がいくらまで可能かを例に挙げたが、単に全体の残高だけでなく、支出を、利用明細のデータから食費、光熱費、衣料費、遊興費等のジャンルに分けて管理できる場合には、ジャンル毎の支出のアドバイスを提供することが可能である。例えば、「食費ならあと○○円使ってもよいが、今月は全体的にピンチなので、遊興費はあと△△円しか不可」、あるいは「今月は、外食による食費増で例月の食費の3倍になるでしょう。貯蓄目標をキープするために例月の2倍に留めると購入予定のタブレットを購入しつつも、目標達成できるでしょう」等といったアドバイスを表示することも可能となる。なお、アドバイスは上記のような自然言語で生成してもよいし、アドバイスの元となるデータのみを表示してもよい。
ATM150で引き出した現金での買い物は、ジャンル分けを示すデータがレシートのみなので、利用者端末350にレシートのバーコード読み取り手段を備えるか、又は専用アプリケーションに手入力手段を設け、購入日、商品金額、ジャンルを示すアイコンを押すだけで手軽に購入商品のデータをインプットできるようにすることで実現可能である。
図10は、予想残高表示画面の具体例3を示す図である。図示する予想残高表示画面820では、月単位の予想残高ではなく、所定日の(図の例では10日、20日、月末)予想残高を、当月、翌月、翌々月について一覧で示したケースを示している。より一般的には、予想残高を提示する所定期間や収支を計算する期間は、日単位、5日単位、週単位、10日単位、月単位、3ヶ月単位、半年単位、年単位等とすることができる。この例では、利用者は、締日、引落日が異なる2枚のクレジットカードを保持しているものとし、どちらのクレジットカードを使用して買い物をすべきかを利用者にアドバイスを提供できることを示している。
図10の上段のテーブル821では、クレジットカードAを使用して、本日(10月10日とする)、5万円の買い物を行ったケースを示している。また、図10の下段のテーブル822では、クレジットカードBを使用して、本日、同じく5万円の買い物をしたケースを示し、両者を比較している。図から容易に判るように、同じ日に同じ買い物をしても、使用するクレジットカードの締日と引落日の違いによって、翌月の当月収支や最低予想残高がマイナスになったり、プラスになったりする可能性がある。このような場合には、当月収支や最低予想残高がマイナスにならないように、使用するクレジットカードを選ぶ必要があるが、この予想残高表示画面820によって、このような状況で使用するクレジットカードを推奨することができる。もちろん、図10に示すテーブルを全て表示する必要はなく、表示装置の能力と利用場面に応じて、最も適切な部分だけを表示するようにしてもよい。
<第二の実施形態>
図11は、本発明の第二の実施形態に係る銀行口座残高管理システムの基本構成の概念を示す図である。以下では、第一の実施形態と異なる部分についてのみ説明する。なお、第二の実施形態に係る各装置、構成要素は、第一の実施形態と名称が同じであっても機能が異なる場合には、符号に「A」の文字を付けて区別することにする。
第二の実施形態に係る利用者カード300Aは、データ記憶手段301に加え、データ分析手段304、表示/入力手段302、及びメッセージ生成送信手段3045を備える。また、図示していないが、近距離無線通信手段303(NFC)は備えるものとする。詳しくは後述するが、データ記憶手段301は、カード識別情報の他、銀行口座の取引データや、カードの利用明細のデータを全て受信し蓄積して格納する。データ分析手段304は、データ記憶手段301に格納されたデータを分析して分析結果を出力する。メッセージ生成送信手段3045は、分析結果をメッセージとして、ATM150A、POS端末250A、又は利用者端末350Aに送信する。このため、ATM150A、POS端末250A、利用者端末350Aは、利用者カード300Aからメッセージを受信してそれぞれの表示手段に表示するためのメッセージ受信手段155,255,355を備えている。メッセージの送受信は、NFCを使って行われるのは言うまでもない。
ATM150Aは、利用者カード300Aがカード読取部にタッチ又は近接され、利用者が現金の引き出しや振込等の出金操作をすると、カード番号等の識別情報を読み取り、続いて暗証番号等の認証情報を確認する。そして認証が正常に終了すると、出金要求が銀行システム100Aに送信する。銀行システム100Aは、第一の実施形態と異なり、特別な処理を行わず、認証が完了し取引が正常に行われた場合は、取引が完了したことを示す口座取引データをATM150Aに返信するだけである。このときの口座取引データには、日時、出金金額、取引後の預金残高が少なくとも含まれる。ATM150Aは、口座取引データを受信後、利用者カード300Aに取引データを書き込む。
利用者カード300Aは、受信した口座取引データを分析し、分析の結果、最低予想残高が所定の金額以下となるような場合、ATM150Aに対して、用意された所定のメッセージを送信する。ATM150Aは、この受信したメッセージをATM画面に表示する。この一連の処理は、利用者がATM150Aの前に立って操作をしている間に行われる必要があるため、上記のカードが行う分析は、前もってカード内で準備しておくことが望ましい。例えば、最後にカードのデータ記憶手段301のデータを更新したときの残高及びその時点での予想残高を記憶しているので、次回予想される出金額に応じて、注意喚起のメッセージをいくつか準備しておく。そして、実際の出金額が判明した時点で、準備したメッセージのうち最適のものを送信する。
POS端末250Aも基本的には同様であり、利用者カード300Aがカード読取部にタッチ又は近接され、買い物の決済が要求されると、カードの識別情報を読み取り、暗証番号等の認証情報が入力されると、決済要求(オーソリ要求)がクレジットカード会社システム200Aに送信する。クレジットカード会社システム200Aは、第一の実施形態と異なり、特別な処理を行わず、オーソリが完了し問題がない場合、オーソリが完了したことを示す決済結果をPOS端末250Aに返信する。
POS端末250Aは、この決済結果を受信すると、利用者カード300Aに対して、決済要求の元となったカード利用デ−タを書き込む。このときのカード利用データには、日時、購入金額、商品名、店舗名が少なくとも含まれる。なお、この時点での店舗からのカード会社に対する決済要求は、多くの場合、カードの認証、有効期限、利用限度額のチェックするためのオーソリ要求であって、必ずしも店舗からカード会社に直ちに請求(売上計上)がなされるわけではないが、ここでは、便宜上、決済が正常に行われたものとして扱うことにする。実際の店舗からカード会社への請求時において利用者に影響するような問題が起きることはほとんどないからである。万一、返品等で決済取消が発生しても支払済の金額は返済されるものとする。
利用者カード300Aは、書き込まれた購入商品データを分析し、分析の結果、代金の引落先となる銀行口座の最低予想残高が所定の金額以下となるような場合、POS端末250Aに対して、所定のメッセージを送信する。そしてPOS端末250Aは、受信したメッセージをPOS端末画面に表示する。この一連の処理は、利用者がPOS端末250の前に立っている間に行われる必要があるため、上記したようなカード側での事前準備を行っておく。そして、実際の購入金額が判明した時点で直ちに準備したメッセージを送信する。
図12は、本発明の第二の実施形態に係る利用者端末の機能ブロックを示す図である。利用者カード300Aは、前述したように、データ記憶手段301、表示/入力手段302、近距離無線通信手段303、及びデータ分析手段304で構成される。データ記憶手段301に格納されるデータについては後述する。表示/入力手段302は、カード上でデータの表示と入力を行うための手段であり、典型的には表示機能と入力機能を兼ね備えたタッチパネルである。近距離無線通信手段303は、既に述べたように、ATM150A,POS端末250A,利用者端末350AとNFCでデータの送受信を可能とする。
データ分析手段304は、データ記憶手段301に格納された様々なデータを読出し、分析する機能を有し、さらに詳細には、入出金傾向抽出手段3041、予想残高算出手段3042、使途別枠抽出手段3043、購入検討情報分析手段3044、及びメッセージ生成送信手段3045から構成される。入出金傾向抽出手段3041は、図2の入出金傾向抽出手段104、利用傾向抽出手段204に対応し、予想残高算出手段3042は、図2の予想残高算出手段102、予想残高補正手段202に対応し、使途別枠抽出手段3043は、図2の使途別枠抽出手段105、205に対応するので、ここでは説明を省略する。また、購入検討情報分析手段3044も、図2のデータ分析手段351の購入検討情報分析機能(図示せず)に対応するのでここでは説明を省略する。
第二の実施形態においては、分析に必要なデータは、利用者カード300Aが、ATM150A,POS端末250A,利用者端末350Aから個々に取得し、データ記憶手段301にまとめて格納している。したがって、銀行システム100A、クレジットカード会社システム200A、消費者金融会社等システム400Aは、一般的なシステムであってよく、第一の実施形態のように、入出金素傾向を捉えて予想明細を算出するようなデータ分析機能を備えたり、システム間で互いに連携している必要はない。また、第二の実施形態では、ATM150やPOS端末250Aにおいてカードを利用するときに近距離通信でデータを取得する。したがって、カード単体ではインターネットにつながず、ATM150AやPOS端末250Aが接続するセキュリティの強固な通信環境のみに使用を限定することによって、安全性の高いサービスの提供が可能となる。
メッセージ生成送信手段3045は、図1で説明したように、上記の抽出手段及び分析手段による分析結果をメッセージとして、ATM150A、POS端末250A、利用者端末350Aに送信するが、メッセージを生成する機能も有するので、データ分析手段304の一部として扱うことにする。
利用者端末350Aは、表示/入力手段352、近距離無線通信手段353(NFC)、購入検討商品情報収集手段354、Web明細収集手段356、インターネット通信手段357を備える。図2のデータ分析手段351は、カード側に移動したため、端末側には備えないものとする。
購入検討商品情報収集手段354は、通販サービス会社システム500に自動ログインし、購入検討商品情報や購入商品情報(購入履歴)を収集する。このようにすることで、購入検討中の商品に対して、購入時期や購入店舗をアドバイスすることも可能となる。また、購入済の商品の情報も合わせて取得しておけば、入出金の傾向を抽出する際に役立つ。
Web明細収集手段356は、金融機関のWebサイト、特に、消費者金融会社等システム400Aに自動ログインし、Web明細データを収集する。第二の実施形態では、利用者カード300Aに全てのデータを集め、カード内部で、集めたデータを分析するようにしているが、ATM150AやPOS端末250Aを利用する機会が少ない場合は、データの収集や更新の頻度が少なくなる。そのため、Web明細収集手段356は、銀行やクレジットカード会社のWebサイトに定期的にアクセスし、Web明細を利用者端末350A内に取得しておく。そして、利用者端末350Aと利用者カード300Aが交信可能な状態になったときは、常にカード内のデータを更新するようにする。
なお、購入検討商品情報収集手段354、Web明細収集手段356を合わせて登録サイトデータ収集手段359と呼ぶことにする。このように登録サイトに自動ログインして必要なデータをダウンロードする方法自体は公知であり、例えば、特開2004−133879に記載のようなプログラムを用いてもよい。
図13は、本発明の第二の実施形態に係る利用者カード300Aのハードウェア構成を示す図である。図示するように、本実施形態の利用者カード300Aは、ハードウェアの構成として、ICチップ320を備えたICカードであり、ICチップ320内にCPU310、Co.CPU311、ROM312、RAM313、EEPROM314(Electrically Erasable Programmable Read-Only Memory)、インターフェース制御部315、電源制御部316、表示制御部317、タッチセンサ制御部318を含んでいる。また、カード表面又は側面には、表示/入力手段302と電源スイッチ322が備えられ、カード内部には、アンテナコイル321と超薄型の電池323を備えている。
表示/入力手段302は、典型的にはタッチパネルであり、例えば、液晶ディスプレイや有機EL(OELD:Organic Electro Luminescence Display)のような表示装置(表示手段)と、抵抗膜方式や静電容量方式のタッチセンサのような入力装置(入力手段)を組み合わせたものである。電源スイッチ322は、ICチップ320を駆動する電源をオンオフを行うための物理スイッチであり、カードの表面又は側面に装着される。電源スイッチ322は、電源のオン・オフをソフトウェアにより制御可能なソフトスイッチであることが望ましい。ソフトスイッチとすることで、電源スイッチ322は、電源スイッチ以外にも入力手段の一部としても利用できるが、入力手段として別のソフトスイッチを備えていてもよい。
アンテナコイル321は、ICカードがカード読取装置が発生させる磁場に入ると、電磁誘導により電気を起電するコイルと、NFCの電波を受信するアンテナが一体化したものである。電池323は、リチウムイオン電池のような充電式の電池であり、充電用の端子をカードの裏面又は側面に備える。また、電池323は、太陽光を受けて充電する太陽電池であってもよいが、太陽光パネルをカード表面に装備させる必要があり、その分、表示/入力手段302の表示面積が小さくなる。
図12で説明したデータ記憶手段301は、不揮発性のEEPROM314で構成され、近距離無線通信手段303(NFC)は、インターフェース制御部315とアンテナコイル321で構成される。また、データ分析手段304は、ROM312又はEEPROM314に格納されたコンピュータ・プログラムをCPU310とCo.CPU311が実行することによって実現する。Co.CPU311(コプロセッサ)は、主に、RSAのような公開鍵暗号方式の演算を高速に実行するための専用プロセッサであるがその他の処理も実行する。インターフェース制御部315は、ICカードと外部とのNFCによる通信を制御し、非接触アナログ通信回路を含む。以下、NFCは、広く普及している通信距離が10cm程度の近接型であるとして説明する。
電源制御部316は、電源スイッチ322又はCPU310からのその他の信号に応じて、電池323のオン・オフを制御する。表示制御部317は、表示/入力手段302の表示手段の部分を制御し、算出された予想残高等の収支データを表示/入力手段302の表示手段に表示可能とする。表示手段に、実際にいつどれくらいの時間表示させるかは、できるだけ電池の消耗を少なくするため、利用者が設定可能とすることが望ましい。なお、タッチセンサ制御部318は、表示/入力手段302の入力手段の部分を制御する。
電源がオフの状態であってもNFCによる通信は可能であるが、表示/入力手段302を駆動させるには、電源がオンの状態であることが必要である。ただし、通信相手が利用者端末350である場合は、利用者端末350は、通常は磁場を生成する手段を持たず、カード側に電気を供給することができないため、カード側の電源をオンにしておく必要がある。
以上の説明からわかるように、利用者カード300Aのハードウェアは、公知の技術で全て実現可能である。なお、ICカードに対応していないATMやPOS端末を利用する際の後方互換性を維持するため、利用者カード300Aの裏面には従来型の磁気ストライプを備えていてもよい。
図14は、本発明の第二の実施形態に係るデータ記憶手段301に含まれる情報である。図示するように、データ記憶手段301には、銀行口座取引明細データ3011、クレジットカード利用明細データ3012、消費者金融利用明細データ3013、商品購入検討データ3014、商品購入履歴データ3015、及びカード画像データ3016等が格納される。
銀行口座取引明細データ3011、クレジットカード利用明細データ3012、消費者金融利用明細データ3013、商品購入検討データ3014については、図4で示したデータと同様であるのでここでは説明を省略する。また、商品購入履歴データ3015は、通販サービス会社システム500からインターネットを介して取得できるデータであり、商品購入検討データ3014と共に買い物支援のアドバイスのためのメッセージを生成するために利用される。
カード画像データ3016は、利用者カード300Aに複数のカード機能を持たせるときに、それらのカードの表面の画像(写真)データである。カードの画像は、利用者端末350Aのカメラによって撮影した写真をカードに転送し、適切な解像度に変換してデータ記憶手段301に格納させておく。なお、複数のカード情報を利用者端末350Aに登録させる手段は様々な方法が考えられるが、登録したいカードがNFCを備えていれば、利用者カード300Aにそのカードを重ね、利用者カード300Aの入力手段を使って、お互いのカードの認証情報をインプットし、所定の操作をすることで、登録すべきカード情報が利用者カード300Aに転送されるようしてもよい。NFCを備えていないカードを登録するときは、利用者端末350Aにカードリーダを装着し、読み出したカード情報を利用者カード300Aに転送するようにしてもよい。
図15は、本発明の第二の実施形態に係る利用者カード300Aの一連の処理フローを示す図である。本処理フローは、利用者カード300AがATM150A、POS端末250A,利用者端末350Aのいずれかと交信し、データ分析手段304がデータ分析を行い、分析結果をメッセージとして送信又は表示する過程を示している。
利用者カード300Aが、ATM150Aとの接続を検知すると(ステップS60:Y)、ステップS61でデータ記憶手段301に記憶されたカード情報をATM150Aに送信する。利用者カード300Aに複数のカード情報が登録されている場合は、予め使用するカードをカードの入力手段を使って選択しておく。ATM150Aは、ステップS62で受け取ったカード情報を認証し、認証がOKであれば(ステップS62:Y)、ステップS64で選択されたカードがキャッシュカードとクレジットカードが一体となった一体型カードであるか否か、あるいは提携クレジットカードが有るか否かを判断する。選択されたカードが一体型カードであれば若しくは選択されたカードに提携クレジットカードがあれば(ステップS64:Y)、ステップS65で、一体となったクレジットカード若しくは提携クレジットカードの情報をデータ記憶手段301から読み出す。
次に、ステップS66で、銀行口座の明細データをデータ記憶手段301から読み出す。続いて、ステップS67で銀行口座支出入傾向を抽出する(入出金傾向抽出手段3041の処理)。そして、ステップS68で、所定期間における銀行口座の予測収支を算出する(予想残高算出手段3042の処理)。さらに、ステップS69で支出管理処理を呼び出す。銀行口座支出入傾向抽出、予想収支算出、支出管理処理については、基本的には、第一の実施形態の図5、図6、図7の場合と同様なのでここでは説明を省略する。
ステップS69の支出管理処理が終わると、ここで算出された収支データをデータ記憶手段301に書き込む(ステップS70)。支出管理処理の結果により、送信すべきメッセージがある場合は(ステップS71:Y)、ステップS72で送信メッセージを生成し、交信相手の端末(ここではATM150A)に送信する(メッセージ生成送信手段3045の処理)。
最後に、カードの電源がオンであれば、ステップS73で送信したメッセージに対応する表示を、カード自らの表示/入力手段302に表示する。カード上の表示形式は、カード上で視認し易いように単純でグラフィカルな表示が望ましく、ATM150Aの表示画面の内容と異なっていてもよい。カード上の表示は、カードが電源オンされたときには電源オフ時の表示と同じものが表示されるが、新たなデータを受信したとき、又は利用者の所定の操作があったとき、表示が更新されるのは言うまでもない。以上で利用者カード300AがATM150Aと交信したときの処理を終了する。
一方、利用者カード300Aが、POS端末250Aとの接続を検知した場合は(ステップS80:Y)、ステップS81でデータ記憶手段301に記憶されたカード情報をPOS端末250Aに送信する。利用者カード300Aに複数のカード情報が登録されている場合は、予め使用するカードをカードの入力手段を使って選択しておく。POS端末250Aは、ステップS82で受け取ったカード情報を認証し、認証がOKであれば(ステップS82:Y)、ステップS83で選択されたカードが一体型カードであるか否かあるいは提携銀行カード(一般的には引落先の口座)があるか否かを判断する。一体型カードであるか提携銀行カードがある場合は、ステップS84で提携銀行カードで支払うか(すなわちデビットカード払い)否かを判断する(予め利用者が指定しておくものとする)。デビットカードで支払う場合は、ステップS65に移り、クレジットカードで支払う場合はステップS66に移るが、以降の処理は、交信相手がATM150Aの場合と同様である。
また、利用者カード300Aが、利用者端末350Aとの接続を検知した場合は(ステップS90:Y)、ステップS91でカード記録手段にデータは収集済みであるが分析が未処理のデータがあるがどうかを判断する。未処理のデータがある場合は、ステップS92で、利用者端末350Aがその未処理のデータを受信し、分析処理を行う(使途別枠抽出手段3043と購入検討情報分析手段3044の処理)。分析結果はデータ記憶手段301に格納される。その後、ステップS71に移り、分析の結果、送信すべきメッセージがある場合は、利用者端末350Aとカード自らの表示/入力手段302に送信する。利用者カード300Aが利用者端末350Aと接続したときに、使途別枠抽出や購入検討情報の分析を行うのは、ATM150AやPOS端末250Aとの接続時には、上記のような分析を直ちに行う必要がないからである。
図16は、本発明の第二の実施形態に係る利用者カード300Aのカード表面の表示例1を示す図である。利用者カード300Aは、表示/入力手段302を備えるので、カード自体を4インチ相当(85.6m×54.0mm)のディスプレイとして、カード表面にグラフィカルな表示を行うことができる。図示するようにカード側面には電源スイッチ322が備えられている。カードの電源をオンにすると、画面910が表示され、内蔵するカード情報が、カードフェイス画像として、一又は複数表示される。カードフェイス画像は、予め利用者が保持するカードを写真撮影して画像データをカード内に転送しておくものとする。
図16(a)のカード一覧の画面910(初期画面)の例では、M銀行のキャッシュカードに現在の預金残高と今月の最低予想残高がカードフェース画像の上部に表示されている。また、引落予定のあるクレジットカードや電子マネーカードは、その引落予定日と引落額が各カ−ドフェイス画像の上部に表示されている。引落予定がないカードは、Bクレジットカード912のように、グレー表示されている。また、画面910において、カードの利用頻度を色分けして表示するようにしてもよい。また、カード全てが一画面に収まり切れない場合は、利用頻度の高いカードほど前面に出るように重ねて表示してもよい。また、長期間利用がないカードや有効期限が近いカードは、その旨のメッセージを表示するようにしてもよい。
画面910で、例えば、M銀行のキャッシュカード911をタップすると、図16(b)の画面920に表示が切り変わる。画面920では、M銀行の口座を引落口座としているクレジットカードや電子マネーカードのみが表示される。画面920で、M銀行キャッシュカード上部の残高表示921をタップすると、さらに図16(c)の画面930に表示が切り替わり、M銀行口座の今月の予想残高の明細が表示される。画面930上で指で上部にスクロールすると、通帳のように、過去の入出金記録が表示されるようにしてもよい。このようにすることで、ATM150AやPOS端末250Aとの接続時に限らず、カードを取り出して、電源スイッチ322をオンにするだけで、内蔵する全てのカードに関する様々な最新情報を手軽に確認することができる。
図17は、本発明の第二の実施形態に係る利用者カード300Aのカード表面の表示例2を示す図である。このカード一覧の画面940(初期画面)では、同じ買い物をするにしても、どのクレジットカードを使えばよいかを推奨し、その根拠となるデータを表示してくれる。図の例では、ある店舗で5万円の買い物をすると仮定した場合の、その店舗で利用可能な3つのクレジットカードを表示している。ただし、買い物をする店舗の情報は予め利用者端末350Aから転送され、カード内に記憶されているものとする。表示されるクレジットカードのデータには、次回引落予定日と引落金額、引落先の口座の当月収支、蓄積ポイント、今回の買い物で取得できるポイント等が例として示されている。クレジットカードAのポイントが高いのは、購入を予定している店舗が、クレジットカードAの会社と特約店契約をしているからである。また、あるカードでポイントバーゲン等が行われている場合はその旨を表示してもよい。
画面940で、表示されたクレジットカードフェイス941をダブルタップすると、画面960に切り替わり、使用するクレジットカードが全面に表示される。どの画面からも最前面にあるカードフェイスをダブルタップすることによって、そのクレジットカードを利用可能状態にすることができる。カード一覧の画面940に戻るには電源スイッチを押しながらダブルタップする等とする。このとき、いったん使用するカードが選択された後は、その後、カードを預けた店員などに誤って変更されないように、カードの再選択はわざと変更しづらくすることが望ましい。また、画面940で利用者が表示されたクレジットカードの明細942をタップすると、画面950に切り替わり、さらに詳細な明細が表示される。
画面940の例では、クレジットカードAを利用すると当月収支は赤字になるものの、最低予想残高がマイナスになっていなければ、取得できるポイントの高さからクレジットカードAを使用することが推奨されている。推奨されたカードは、色を変えて表示するか、最前面に大きく表示するか等して、強調表示される。このようにすることで、利用者は、これらの画面から、今回の買い物に使用するカードを簡単に選択することができる。
図18は、本発明の第二の実施形態に係る利用者カード300Aのカード表面の表示例3を示す図である。図18(g)のカード一覧の画面970(初期画面)においては、利用頻度の高いカード順又は利用金額の多い順にそのカードが前になるように表示されている。最前面のAクレジットカード971は、カードの文字が大きく表示されている。利用者が最前面ではないCクレジットカード972を使いたい場合は、そのカードをタップすると、図18(h)の画面980に表示が変わるので、最前面に表示されたCクレジットカード981をさらにタップすると、画面990に表示が切り替わり、Cクレジットカードの利用状況991が表示される。なお、画面980でCクレジットカード981をダブルタップすると、Cクレジットカードのカードフェイスが全面に表示され、Cクレジットカードが使用可能となるのは前図の場合と同様である。
図19は、本発明の第二の実施形態に係る利用者カード300Aのカード表面の表示例4を示す図である。図19(k)のカード一覧の画面1000においては、タグ1001,1002で示すように、タグ形式でメニューを選択することができる。例えば、タグ1002を押すと画面1000が表示され、現在来ている店舗からカード毎の割引データをPOS端末250A等から受信し、その商品の割引率の高いカード順にそのカードが前になるように表示される。このようにすることで、得する(知らないと損な)情報を見逃さないようにできる。また、画面1000において、タグ1001を押すと、図19(m)の画面1010に切り替わり、そこでこれから使用しようとするカードを選択すると、そのカードの限度額に対する現在の利用額が表示される。このようにすることで、カードを出したら限度額を超えていた等の格好の悪い思いをすることを避けることができる。
(第一の実施形態の効果)
本実施形態のシステムでは、銀行とクレジットカード会社が提携している金融機関グループにおいて、そのグループのカードの利用者は、銀行口座とクレジットカードの利用状況を統合的に管理することができる。このとき、総支出の管理だけでなく使途別の管理も可能である。また、利用者カードとスマートフォン等の携帯端末を連携させ、利用場面によって使い分けをすることもできる。さらに、口座残高がマイナスとなったり、所定額以下になると予想される場合には、注意喚起を行ったり、その時点で可能な対策(以降の現金支出の削減やクレジットカードの支払方法の変更等)の適切なアドバイスを利用者に提供することができる。さらに、商品の購入予定がある場合には、銀行口座の残高の予想推移を見ながら、最適な購入時期を利用者が判断できるような情報を提供することができる。また、利用者が複数のクレジットカードを保有している場合は、どのカードを使った場合に口座残高不足になる可能性が低いか等のアドバイスを提供することもできる。
(第二の実施形態の効果)
本実施形態のシステムでは、カード自体を高機能化し、複数のカードを一枚にまとめることはもちろん、銀行口座の予想残高算出や支出入傾向抽出等のデータ分析機能をカード側に持たせたので、第一の実施形態と同等な効果を得るために銀行やクレジットカードのシステムを変更する必要がほとんどない。銀行とクレジットカード会社等が提携している必要もない。また、カード表面にグラフィカルな表示機能を持たせたので、カードを取り出したときにカードの電源スイッチを押すだけで、簡単にカードの利用状況を確認することができる。カード内で分析した結果は、カード自体に表示することはもちろん、利用者端末やATMやPOS端末にもメッセージを送信し、そのメッセージをATM画面やPOS端末画面からでも確認できる。また、本実施形態では、ATMや決済端末においてカードを利用するときに近距離通信でデータを取得する。したがって、カード単体ではネットにつながず、ATMやPOS端末が接続するセキュリティの強固な通信環境のみに使用を限定することによって安全性の高いサービスの提供が可能となる。
なお、本発明の第一の実施形態、第二の実施形態において、利用者カードは、キャッシュカード、クレジットカード、電子マネーカード、消費者金融系カードを例にあげて説明したが、本発明は、交通系ICカード、証券会社の口座カード、ポイントカード等、その他の金融系のカードが含まれる場合にも適用可能である。
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明として、銀行口座残高管理システムと金融系のICカードについて説明したが、本発明は、方法の発明(銀行口座残高管理方法又は金融機関の利用状況管理方法)としても捉えることもできる。