(58)【調査した分野】(Int.Cl.,DB名)
クレジットカード会社システムと、クレジットカードの加盟店システムと、当該クレジットカードの会員の端末とがネットワークで接続され、会員が自己のクレジットカードで買い物をする際の代金を別の会員が援助することを可能とするクレジットカード援助支援システムであって、
前記クレジットカード会社システムは、
援助者となる会員の端末から、当該会員のカード識別番号と、被援助者となる会員のカード識別番号と、援助条件とを含む援助情報を受け付け、援助情報DBに格納する援助登録受付部と、
前記援助情報DBを参照して、前記被援助者の買い物が前記援助条件を満たすかどうかを判定する援助条件判定部と、
前記援助条件判定部が前記援助条件を満たすと判定した場合に、前記被援助者が自己のクレジットカードで購入する商品又はサービスの代金の一部又は全部を、前記援助者のクレジットカードに課金することを認証する認証部とを、
備えることを特徴とするクレジットカード援助支援システム。
前記加盟店システムは、一人の前記被援助者に対して複数の援助者が存在する場合に、前記購入する代金に対する前記複数の援助者の負担割合を前記被援助者に決定させる手段を備えることを特徴とする請求項1又は2に記載のクレジットカード援助支援システム。
前記加盟店システムは、一人の前記被援助者に対して複数の援助者が存在する場合に、前記購入する代金を、前記複数の援助者の援助額を合算して決済するかどうかを前記被援助者に決定させる手段を備えることを特徴とする請求項1又は2に記載のクレジットカード援助支援システム。
前記加盟店システムは、前記援助者からの援助の申し出の際に、前記被援助者が前記援助者を登録する手段を備えることを特徴とする請求項5に記載のクレジットカード援助支援システム。
前記援助情報は、前記援助者から被援助者へのメッセージを含み、前記加盟店システムは、前記援助者からの援助の申し出の際に、前記メッセージを前記被援助者に通知する手段を備えることを特徴とする請求項5又は6に記載のクレジットカード援助支援システム。
前記加盟店システムは、前記援助者のメッセージに対する返信メッセージを、前記被援助者が入力する手段を備えることを特徴とする請求項7に記載のクレジットカード援助支援システム。
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記の特許文献1の方法は、クレジットカードで得たポイントを自分以外の他者を援助するために使用するものであるが、ポイントが溜まるまでは援助をしたくてもできないので、援助が必要な人に対して必要なタイミングで必ずしも援助ができないという課題がある。援助者(親、祖父母等)が、被援助者(子供、孫、親戚、友人等)の特定の支出に対して、金銭的援助や一部の補助をしたい場合、現金の送金や銀行振込でなく、クレジットカードや電子マネーを利用できれば便利であるが、特許文献2のような分割精算システムを応用しようとしても、援助者が被援助者の買い物の場にカードを持参して同席しなければならず、利用場面が限られる。また、援助される側にとっても、援助者が同席されると気遣いが必要で援助をお願いすることが躊躇らわれる。また、予め援助をお願いすることは、おねだりをしているようで気が引ける。
【0005】
したがって、本発明では、上記のような課題に鑑み、援助する側にとっては利用しやすく、援助される側にとってもおねだりや気遣いが不要なクレジットカード援助支援システムを提供すること、すなわち、被援助者が自己のクレジットカードを利用して買い物をしようとする際に、援助者がその場にいなくとも、予め登録があった援助者からの援助を受けることができるクレジットカード援助支援システム及びその方法を提供することを目的とする。
【課題を解決するための手段】
【0006】
上記課題を解決するため、本発明のクレジットカード援助支援システムは、以下のような解決手段を提供する。
【0007】
請求項1に記載の発明は、クレジットカード会社システムと、クレジットカードの加盟店システムと、当該クレジットカードの会員の端末とがネットワークで接続され、会員が自己のクレジットカードで買い物をする際の代金を別の会員が援助することを可能とするクレジットカード援助支援システムであって、前記クレジットカード会社システムは、援助者となる会員の端末から、当該会員のカード識別番号と、被援助者となる会員のカード識別番号と、援助条件とを含む援助情報を受け付け、援助情報DBに格納する援助登録受付部と、前記援助情報DBを参照して、前記被援助者の買い物が前記援助条件を満たすかどうかを判定する援助条件判定部と、前記援助条件判定部が前記援助条件を満たすと判定した場合に、前記被援助者が自己のクレジットカードで購入する商品
又はサービスの代金の一部
又は全部を、前記援助者のクレジットカードに課金することを認証する認証部とを、備えることを特徴とする。
【0008】
上記の構成によれば、援助者は、予め援助したい被援助者のカード識別番号と援助可能な条件を定めた援助条件を自己のクレジットカード会社のシステムに登録しておく。被援助者が自分のクレジットカードを利用して実際に買い物をしようとすると、その買い物をする加盟店のシステムからクレジットカード会社のシステムにカードの認証要求が送信され、被援助者の買い物が前記の援助条件を満たすかどうかを判定し、援助条件を満たすと判定すると、その購入代金の支払いの一部又は全部を援助者のクレジットカードで認証させ課金させる。このようにすることで、援助者が買い物の場にいあわせなくても、被援助者が購入した商品又はサービス(商品等)の代金を援助することができる。
【0009】
請求項2に記載の発明は、請求項1に記載の発明において、前記援助条件は、前記援助者が予め定めた援助限度額、援助対象期間、援助対象
の商品又はサービス、援助対象店舗のうち少なくとも一つを含むことを特徴とする。
【0010】
上記の構成によれば、援助者が予め定める援助条件には、援助限度額はもちろんとして、援助の対象期間、援助の対象商品等、援助の対象店舗を指定できるので、援助者が援助したい目的にそって援助内容をきめ細かく指定できる。また、被援助者以外の者の悪用も防止できる。
【0011】
請求項3に記載の発明は、請求項1又は2に記載の発明において、前記加盟店システムは、一人の前記被援助者に対して複数の援助者が存在する場合に、前記購入する代金に対する前記複数の援助者の負担割合を前記被援助者に決定させる手段を備えることを特徴とする。
【0012】
上記の構成によれば、援助者が複数いる場合で、ある買い物に対して同時に複数の援助の申し出があった際に、各援助者が負担する商品代金の割合である負担割合を被援助者が指定することができる。したがって、援助者が指定した援助限度額にかかわらず、被援助者は、援助者や購入した商品等の代金を考慮して、最も適切と思われる援助を受けることができる。
【0013】
請求項4に記載の発明は、請求項1又は2に記載の発明において、前記加盟店システムは、一人の前記被援助者に対して複数の援助者が存在する場合に、前記購入する代金を、前記複数の援助者の援助額を合算して決済するかどうかを前記被援助者に決定させる手段を備えることを特徴とする。
【0014】
上記の構成によれば、援助者が複数いる場合で、ある買い物に対して同時に複数の援助の申し出があった際に、複数の援助者の援助額を合算して商品等の代金に充てることができる。したがって、単独の援助者の場合に比べ、より高額の商品等が購入可能となる。
【0015】
請求項5に記載の発明は、請求項1〜4に記載の発明において、前記加盟店システムは、前記被援助者が前記援助者からの援助の申し出を受諾するか否かを選択させる手段を備えることを特徴とする。
【0016】
上記の構成によれば、被援助者は、援助者からの援助の申し出を受けるか、遠慮するかを選択することができる。
【0017】
請求項6に記載の発明は、請求項5に記載の発明において、前記加盟店システムは、前記援助者からの援助の申し出の際に、前記被援助者が前記援助者を登録する手段を備えることを特徴とする。
【0018】
上記の構成によれば、被援助者は、初めての援助者から援助の申し出を知った時点で、援助を受けるか受けないかに関わらず、その援助者を登録することで、後日のお礼やお返し等に利用することができる。お返しは、援助を受けた者が逆に自分を援助者にして、援助の申し出があった者を被援助者として登録することによっても可能である。
【0019】
請求項7に記載の発明は、請求項5又は6に記載の発明において、前記援助情報は、前記援助者から被援助者へのメッセージを含み、前記加盟店システムは、前記援助者からの援助の申し出の際に、前記メッセージを前記被援助者に通知する手段を備えることを特徴とする。
【0020】
上記の構成によれば、援助者は、自分の援助の申し出を被援助者が知った際に、何らかのメッセージを伝えることができる。
【0021】
請求項8に記載の発明は、請求項7に記載の発明において、前記加盟店システムは、前記援助者のメッセージに対する返信メッセージを、前記被援助者が入力する手段を備えることを特徴とする。
【0022】
上記の構成によれば、援助者からのメッセージに対して被援助者から返信することができる。このことにより、援助者への感謝の気持ちを伝えることができる。
【0023】
請求項9に記載の発明は、クレジットカードの会員が自己のクレジットカードで買い物をする際の代金を別の会員が援助することを可能とするクレジットカード援助支援方法であって、前記クレジットカードを発行したクレジットカード会社のシステムが実行する前記クレジットカード援助支援方法は、援助者となる会員の端末から、当該会員のカード識別番号と、被援助者となる会員のカード識別番号と、援助条件とを含む援助情報を受け付け、援助情報DBに格納する援助登録受付段階と、前記援助情報DBを参照して、前記被援助者の買い物が前記援助条件を満たすかどうかを判定する援助条件判定段階と、前記援助条件判定段階で前記援助条件を満たすと判定された場合に、前記被援助者が自己のクレジットカードで購入する商品
又はサービスの代金の一部
又は全部を、前記援助者のクレジットカードに課金することを認証する認証段階とを、含むことを特徴とする。
【0024】
上記請求項9の発明は、請求項1のシステムを方法の発明と捉えたものであり、請求項1の発明と同様な作用効果を奏する。
【発明の効果】
【0025】
本発明によれば、援助する側にとっては利用しやすく効果的で、援助される側にとってもおねだりや気遣いが不要な援助支援システムを提供することができる。すなわち、被援助者が自己のクレジットカードを利用して買い物をしようとする際に、援助者がその場にいなくとも、予め申し出があった援助者からの援助を受けることができるクレジットカード援助支援システム及びその方法を提供することができる。
【発明を実施するための形態】
【0027】
以下、添付図面を参照して、本発明を実施するための形態(以下、実施形態)について詳細に説明する。なお、実施形態の説明の全体を通して、同じ要素には同じ番号または符号を付している。また、機能ブロック間の矢印は、データの流れの方向、又は処理の流れの方向を表している。
【0028】
図1は、本発明の第一の実施形態に係るクレジットカード援助支援システム(以下、本システムと言う)のシステム構成及び機能ブロックを示す図である。本システムは、図示するように、クレジットカード会員10が所持する端末11がクレジットカード会社システム20とインターネットを介して通信可能に接続され、クレジットカード会社システム20は、自社の加盟店のシステムである加盟店システム30と汎用回線又は専用回線を介して接続される。会員の端末11は、パーソナルコンピュータ(PC)、スマートフォン、タブレット端末、携帯電話等、インターネットに接続できるものであればなんでもよい。
【0029】
クレジットカード会社システム20は、機能ブロックとして、援助をしたい会員から援助登録を受け付ける援助登録受付部21,顧客がクレジットカードで買い物をした際に加盟店から送信されるクレジットカード情報の認証を行う認証部24、援助情報DB23の内容を照会し、援助条件を満たすかどうかを判定する援助条件判定部25を有し、データベースとして、会員の情報を格納した会員情報DB22、会員の被援助者及び援助条件等を格納した援助情報DB23,加盟店の情報を格納した加盟店DB26を備えている。会員情報DB22及び援助情報DB23に格納されるデータについて詳しくは、後述の
図2で説明する。
【0030】
加盟店システム30は、加盟店Xのシステムであり、典型的には、加盟店端末31と加盟店サーバ(図示せず)で構成され、加盟店サーバには、インターネットでの買い物をクレジットカードで決済する場合の決済要求を受け付けるネットショッピング・カード決済部33と、カード認証依頼部34とを備えている。カード認証依頼部34は、加盟店端末31又はネットショッピング・カード決済部33から顧客が決済に用いるカード情報を受け取り、クレジットカード会社システム20に送信して認証(オーソリ)を依頼する。また、加盟店端末31には、顧客のクレジットカードに記録されたデータを読み取るICカードリーダ32が接続されている。
【0031】
なお、クレジットカード会社システム20及び加盟店システム30には、上記以外にも顧客管理や販売支援等の様々な機能を有する機能ブロックも存在するが、
図1では本発明に関係のない部分は省略している。
【0032】
図1において、会員10が、同じクレジットカード会社の会員40(例えば、子供、孫、親戚、友人、会社の部下等)がクレジットカードを利用して特定の買い物をした際に、その金額を一部または全部補助したいと考えているとする。特定の買い物とは、援助者が被援助者のために援助したい商品又はサービス(以下、「商品等」と呼ぶ)の購入であり、例えば、子供や孫のための、学費、病気や怪我の治療費、引越費用、家賃、家具や家電の購入費、資格取得費用等、衣服、おもちゃ、ベビー用品、配偶者や婚約者が特定の目的で購入する商品等、友人や部下のパーティ、宴会費用等、様々なものが考えられるが、お祝いやプレゼントとしての意味合いも含む。
【0033】
このような場合に、本システムの援助登録受付部21は、会員10(援助者)が、援助したいと考えている別の会員40(被援助者)をクレジットカード会社システム20に登録するための情報(援助者及び被援助者のカード番号等、援助条件(金額、用途、期間等)を受け付ける。本実施形態においては、被援助者40は、同じクレジットカード会社の会員であれば誰でもよく、家族等でなくてもよい。また、この登録は援助者だけで行うことができ、被援助者の同意や事前通知などはなくともよい。援助登録受付部21が受け付けた情報は、被援助者のクレジットカード番号(又はカードを一意に識別できるカード識別番号)を含み、援助情報DB23に格納される。
【0034】
認証部24は、会員が加盟店でクレジットカード41を利用して買い物をしようとする際に、加盟店端末31に接続されたICカードリーダ32で読み取った会員のカード情報を受信し、受信したカード情報が会員情報DB22に格納された会員固有の認証データと一致するかどうかを調べる。認証データと一致した際に、そのカードの認証をOKとする(以下、この処理を、オーソリ処理と呼ぶことにする)。会員が加盟店の実店舗でなく、加盟店のネットショップで買い物をする場合は、加盟店システム30内のネットショッピング・カード決済部33が、会員の端末42から、決済に用いるクレジットカード情報のデータ入力(カード番号、有効期限、名義人名、暗証番号/暗証パスワード等)を受け付け、カード認証依頼部34にその入力データを渡し、クレジットカード会社システム20の認証部24にオーソリ処理を依頼する。
【0035】
本システムの認証部24は、通常のオーソリ処理だけでなく、会員情報DB22を参照し、購入者に援助者がいる場合には、援助条件判定部25を呼出し、援助条件判定部25は、会員40(被援助者)の今回の買い物が、援助者が予め定めた援助条件を満たすかどうかを判定する。援助条件を満たさなければ、その旨と共に認証部24に処理を戻すが、援助条件を満たしていれば、その旨および関連する情報(援助条件、援助者からのメッセージ等)を認証部24に渡す。認証部24は、この渡された情報を加盟店システム30に送信し、会員40の今回の買い物は、援助者10が登録されており援助条件も満たすので、購入代金の一部または全部を援助者のクレジットカードで決済することが可能であることを通知する。
【0036】
この通知を受けた加盟店システム30は、会員40にそのことを伝える。具体的には、店員が口頭で、又は会員の端末42にその情報を表示する。このようにすることで、会員40は、その場で初めて、援助者からの援助の申し出があることを知ってサプライズすることになる。会員40がその援助を口頭または端末42に表示された受諾ボタン等で受諾すれば、加盟店システム30は、援助条件に従って、援助者のクレジットカードで決済するようクレジットカード会社システム20の認証部24に返信する。この返信を受けた認証部24は、援助者である会員10のクレジットカードから援助金額に相当する部分を決済するように決済処理部(図示せず)に指示する。また、援助限度額が商品等の購入代金に満たない場合は、会員40のクレジットカード41から残りの代金を決済するように決済処理部に指示する。このようにして、会員40がクレジットカードで購入した商品等の代金を一部又は全部援助者が肩代わり(援助)することができる。
【0037】
図2は、会員情報DB及び援助情報DBに格納されるデータの具体例を示す図である。
図2上段の会員情報DB22には、通常のクレジットカードシステムと同様に、会員ID(会員識別子)の他、カードの認証データ221として、クレジットカード番号、セキュリティコード、暗証番号、有効期限、名義人氏名などが記憶される。また、名義人の住所、生年月日、電話番号、メールアドレス等の個人情報を含む。更に、図示していないが、ネット上での会員サービスや会員サポートシステムのためのログインID及びログインパスワード等を含んでもよい。
【0038】
そして、援助登録をした会員には、本システム特有の情報である援助登録情報223として、会員の援助者としての使用する援助者カード識別番号、及び援助したい会員のカードを識別する被援助者カード識別番号が会員情報DB22に格納される。援助登録情報223には、援助者と被援助者の組み合わせごとに、対応する詳細情報が援助情報DB23に格納される。援助者カード識別番号、被援助者カード識別番号は、所有するカードごとに紐づいた番号であるので複数であってもよい。また、援助者カード識別番号及び被援助者カード識別番号は、通常、16桁のクレジットカード番号そのものであってもよいが、クレジットカード発行時又はその後に発行され、クレジットカードを一意に識別できる別の番号であってもよい。これは、クレジットカード番号そのものを相手とやりすることで発生し得る不正利用の危険性を少なくするためである。なお、この例及び以降の例では、説明を簡単にするため、援助者及び被援助者が所有するカードは各1枚であるとする。
【0039】
図2下段の援助情報DB23には、援助者と被援助者の組み合わせごとに援助情報レコード230,231,・・・が作成され、援助者カード識別番号、被援助者カード識別番号、被援助者氏名、援助者との関係が記憶される。また、各援助情報レコードには、援助条件が含まれる。援助条件とは、援助者が援助する条件を予め定めたものであり、具体的には、援助対象期間、援助限度額、援助対象となる商品等(以下、「対象商品等」と呼ぶ)、商品等を購入する店舗、などの項目を指定することができる。各項目がブランクであれば、その項目に対しては条件がないものとする。ただし、援助限度額がブランクである場合には、援助限度額は、その援助者の与信限度額となる。もちろん、複数の被援助者を登録している場合は、それぞれの援助限度額の合計は、与信限度額を超えることはできないものとする。また、援助対象期間は、被援助者にとって特別な記念日、誕生日などであってよい。或いは、援助者にとって支払い余力のある期間を設定してもよい。例えば、給料日直後や賞与後、宝くじが当たった後の一定期間などである。
【0040】
援助情報レコードには、援助者から被援助者に対するメッセージを格納した記憶場所のアドレス(メッセージURL)を含むことができる。ここに記憶されたメッセージは、被援助者が、加盟店で自分のクレジットカードを使って買い物の決済をしようとした際に、加盟店端末31又は被援助者の端末42に表示される。メッセージには、文字情報の他、音声、画像を含んでもよい。このようにすることで、被援助者が、商品等の購入のその場で援助者からの生のメッセージを聞くことになるのでサプライズ効果を高めることができる。
【0041】
図3は、第一の実施形態における決済処理フローを示す図である。この決済処理は、加盟店システムのサーバと、クレジット会社システムのサーバ間で行われる処理である。
【0042】
まず、加盟店システムは、ステップS10において、顧客の支払いがクレジットカードであることを確認する。クレジットカード払いでない場合は、現金での決済処理(ステップS19)に移る(現金決済処理の説明は省略する)。クレジットカード払いの場合は、ステップS11に移り、クレジットカード会社システムに顧客のカード情報と購買情報を含んだオーソリ要求を送信する。ここで送信される購買情報には、顧客が購入しようとする商品等の品目、金額、購入日時、及び店舗名が含まれる。商品等の品目には商品等の名称の他、商品等の分類コードを含んでいることが望ましい。クレジットカード会社システムでは、ステップS20において、このオーソリ要求を受信すると、ステップS21に進み、会員情報DB22を参照して、受信したカード情報に援助者登録があるかどうかをチェックする。
【0043】
カードに援助者登録がある場合は(ステップS21:Y)、援助条件判定部25を呼出し、援助条件判定部25は、援助情報DB23を参照して、受信したカード情報と購買情報から、顧客の今回の購買が援助条件(対象期間、援助限度額、対象店舗)を満たすかどうかを判定し、認証部24に処理を戻す(ステップS22)。
【0044】
認証部24は、援助条件を満たすと判定された場合は、ステップS23において、今回の顧客の購入に援助者が登録されており、かつ援助者のカードで決済可能であることを示す援助付オーソリ結果を加盟店システムに送信する。援助条件を満たさないと判定された場合は(ステップS22:N)、ステップS24において、通常のオーソリ結果(購入した顧客のカードのオーソリ結果)を送信する。
【0045】
加盟店システムでは、ステップS12において、オーソリ結果を受信すると、さらにステップS13において、オーソリ結果がOKであることを確認し、ステップS14に進む。ステップS14においては、オーソリ結果が援助付か否かをチェックする。援助付オーソリ結果を受信しているのでなければ、ステップS18に飛び、顧客(被援助者)のカード番号で決済されたことを確認する。
【0046】
援助付オーソリ結果を受信した場合は、ステップS15において援助者から援助の申し出があることを顧客に通知する。この通知は、店員が口頭で顧客にそのことを伝えてもよいし、加盟店端末の画面を顧客に見せて行ってもよい。また、顧客がスマートフォン等の携帯端末を携帯している場合には、表示内容を近距離通信手段で、加盟店端末から顧客の携帯端末に送信するようにしてもよい。ネットショッピングの場合は、表示内容の画面が顧客の端末に直接表示される。
【0047】
ステップS16において、顧客が申し出のあった援助を受託すると、ステップS17に移り、顧客のカード番号ではなく援助者のカード番号で決済するようにクレジットカード会社システムに通知する。顧客は、援助を受託する際には、被援助者本人であることを証明するために、実店舗の場合は、身分証明書の提示又は自分のクレジットカードの暗証番号を加盟店端末に入力するようにしてもよい。ネットショッピングの場合は、身分証明書の代わりにネット決済用の暗証パスワードを入力するようにしてもよい。顧客は、この援助の申し出を断ることもでき、その場合は、ステップS18で顧客自身のカード番号で決済するように依頼し、その結果を確認する。
【0048】
クレジットカード会社システムでは、ステップS25において、顧客が援助を受託したことを確認すると、援助者のカード番号で決済を実行する(ステップS26)。そして、ステップS27で、援助者に援助が実行されたことを通知するためのメッセージを送信する。このメッセージは、援助者がメールアドレスを所持していない場合には、カード利用明細書に記載してもよい。顧客が援助を受諾しない場合(ステップS25:N)は、顧客(被援助者)自身のカードのオーソリがOKであれば(ステップS28;Y)、顧客のそのカード番号で決済を実行する(ステップS29)。もちろん、顧客のカードのオーソリもNGであれば現金での決済となる。ステップS29又はステップS27の処理が終了すると、この案件のクレジットカード会社システム側での決済処理は終了となり、ステップS20に戻って、新たな決済のオーソリ要求が来るのを待つ。
【0049】
なお、単純化のため図示は省略したが、顧客のクレジットカードと援助者のクレジットカードで商品等の代金を分割して支払うことも可能である。例えば、商品等の代金が10万円であり、援助者が指定した援助限度額が5万円であれば、5万円ずつが顧客と援助者のカードにそれぞれ課金される。また、被援助者は、指定された援助限度額いっぱいまで援助額を購入代金に充ててもよいし、援助限度額の一部だけを購入代金に充ててもよい。
【0050】
したがって、このようにすることで、クレジットカードで買い物をする際に、被援助者は、援助の申し出があることをその場ではじめて知り、サプライズとともに感謝の気持ちを高めることになる。また、商品等を購入した被援助者のカードがたとえ限度額超過などでオーソリがNGであっても、援助者がいる場合には、援助者のカードのオーソリがOKであれば、被援助者は商品等を購入することができる。もちろん、援助者に購入代金の全額を負担してもらうことも、一部だけを負担してもらうことも指定できる。また、被援助者のカード限度額と援助者の援助限度額を合算して高額の商品を購入することもできる。
【0051】
図4は、本発明の第二の実施形態に係るクレジットカード援助支援システムのシステム構成及び機能ブロックを示す図である。
図5は、第二の実施形態における決済処理フローを示す図である。前述の第一の実施形態では、援助者のカードと被援助者のカードが同じクレジットカード会社のカードである場合について説明したが、第二の実施形態では、両者のカードが別々のクレジットカード会社である場合について、以下、
図4、
図5を参照しながら説明する。
【0052】
図4で示すように、援助者10の所持するカードは、クレジットカード会社Aのカードであり、被援助者40が所持するカードは、クレジットカード会社Bのカードであるとする。加盟店Yは、援助者側のクレジットカード会社Aと、被援助者側のクレジットカード会社Bのどちらにも加盟する店舗であるとする。
【0053】
この場合、被援助者40がクレジットカード41を用いて買い物をすると、認証要求は、クレジットカード会社Bシステム20bに対して行われる(ステップS1)。クレジットカード会社Bシステム20bは、加盟店システム30からのカード認証要求に対して、自社の会員情報DB22b及び援助情報DB23を参照して、購入者(被援助者40)に対して、他社のカード会員である援助者10が登録されていることを検知すると、加盟店システム30に対してその旨を通知する(ステップS2)。
【0054】
これを受信した加盟店のカード認証依頼部34は、今度は、クレジットカード会社Aシステム20aに対して援助者10の認証要求を行う(ステップS3)。ここで、援助情報DB23は、クレジットカード会社Aとクレジットカード会社Bで共有しているとする。援助情報DB23は、図ではそれぞれのシステム内に存在するように描かれているが、実際はクレジットカード業界団体が管理するシステム内に存在するものとする。この場合、援助情報DB23に格納される援助者カード識別番号及び被援助者カード識別番号は、クレジットカード番号でなく、業界内でカードを一意に識別できる別の管理番号であってよい。
【0055】
クレジットカード会社Aシステム20aでは、認証部24aは、援助者10が会員情報DB22aに存在することを確認すると、援助条件判定部25aを呼出し、加盟店から送信された購買条件が援助条件を満たすかどうかを判定させる。援助条件を満たすと判断するとその旨が加盟店システム30に送信される(ステップS4)。
【0056】
以上の処理をより詳しく示したのが
図5の決済フローチャートである。クレジットカード会社Aシステム20aと、クレジットカード会社Bシステム20bは、同じ決済処理のプログラムが実装されている。そのため、図のフローチャートも左右対象となっており、両者の処理は、援助者側の処理(ここではクレジットカード会社A)か、被援助者側の処理(ここではクレジットカード会社B)かが異なるのみである。
【0057】
加盟店システム30内の処理は、ステップS12において、オーソリ結果を受信した際に、ステップS12Aにおいて、援助者がいる場合に、購入者のクレジットカードとは別のクレジットカード会社(他社)に対して転送が必要かどうかを判断し、他社転送が必要であれば、援助者のオーソリ要求を被援助者の購買情報と共にそのクレジットカード会社システムに送信する(ステップS12B)点が
図3の処理と大きく異なる。そして、援助者のオーソリ結果がOKであると(ステップS13:Y)、次のステップで「援助者決済処理」を行うが、この処理は、
図3で説明したステップS14〜S18と同様なので、ここでは説明は省略する。
【0058】
各クレジットカード会社システムでは、ステップS30a又はS30bにおいて、オーソリ要求を加盟店システムから受信すると、ステップS31a又はS31bに進み、他社からの転送かどうかを判断する。他社からの転送とは、自社の会員ではない他社の会員が買い物をした際の援助者が自社の会員であったために、オーソリ要求と購買情報が他社から加盟店を介して転送されてきたことを示す。他社からの転送である場合には(ステップS31a又は31b:Y)、援助者が自社の会員であるので、ステップS36bに進み、「自社援助者オーソリ処理」を行う。
【0059】
他社からの転送でない場合は(ステップS31a又はS31b:N)、ステップS32a又はS32bに進み、カードに援助者登録があるかどうかをチェックし、援助者が自社の会員であれば、「自社顧客オーソリ処理」S35a又はS35bを実行する。援助者が自社の会員でなければ(ステップS34a又はS34b:N)、ステップS33a又はS33bに移り、他社転送情報(援助者のオーソリに必要な情報及び被援助者の購買情報)を送信する。
【0060】
なお、「自社顧客オーソリ処理」S35a及びS35bは、
図3のステップS24に相当し、また、「自社援助者オーソリ処理」S36a及びS36bは、
図3のステップS23とステップS25〜S29に相当するので、ここでは説明を省略する。
【0061】
図6は、本発明の第三の実施形態に係るクレジットカード援助支援システムのシステム構成及び機能ブロックを示す図である。
図7は、第三の実施形態における決済処理フローを示す図である。前述の第一の実施形態では、援助者のカードと被援助者のカードが同じクレジットカード会社のカードである場合について説明した。また、第二の実施形態では、両者のカードが別々のクレジットカード会社である場合について、説明したが、第三の実施形態では、一人の援助者に複数の援助者が存在し、しかも被援助者と援助者ぞれぞれのカードのクレジットカード会社がすべて異なっている場合について、
図6、
図7を参照しながら以下説明する。
【0062】
図6で示すように、ここでは援助者10Aのカードは、クレジットカード会社Aに属し、被援助者40のカードは、クレジットカード会社Bに、もう一人の援助者10Cのカードは、クレジットカード会社Cに属しているとする。
【0063】
被援助者が加盟店Xで、クレジットカード41で買い物をすると、加盟店システム30から、クレジットカード会社Bシステム20bにカードの認証要求が送信される(ステップS1)。クレジットカード会社Bシステム20bの認証部24bが、自社の会員情報DB22b及び援助情報DB23を参照して、購入者(被援助者40)に対して、他社のカード会員である援助者10が登録されていることを検出すると、加盟店システム30に対してその旨を通知する(ステップS2)ことは、第二の実施形態の場合と同様である。ただしこの場合は、援助者が複数存在し、各援助者のクレジットカード会社も別であることを通知する。
【0064】
この通知を受信した加盟店システム30のカード認証依頼部34は、今度は、クレジットカード会社Aシステム20a及びクレジットカード会社Cシステム20cに対して援助者10A、10Cの認証要求を振り分けて送信する(ステップS3、S3’)。認証要求を受けた認証部24a及び認証部24cは、援助者が自社の会員であること及び援助登録があることを確認すると、援助条件判定部25a,25cを呼出して、援助情報DB23を参照して援助条件を満たすかどうかをチェックさせる。ここで、援助情報DB23は、クレジットカード会社A、B,Cで共有していることは言うまでもない。それぞれの援助条件判定の結果が、加盟店システム30のカード認証依頼部34に返信される。
【0065】
返信を受けた加盟店システム30は、第一、第二の実施形態の場合と同様に、顧客(被援助者)の意思を確認後、それぞれの援助者のカードで決済を完了するように、各クレジットカード会社のシステムに通知する(ステップS4、S4’)。なお、援助者の片方が援助条件を満たさない場合は、援助条件を満たした援助者の申し出のみが顧客に通知される。どちらの援助者とも援助条件を満たさない場合には、顧客にはいっさい援助の申し出があったことは通知されない。
【0066】
決済処理のフローチャートは、第二の実施形態でのフローチャートと基本的には同様であるが、加盟店システムでの最終ステップである援助者決済処理S14〜S18が異なる(
図5参照)。
図7に第三の実施形態での援助者決済処理を示す。
【0067】
第三の実施形態における援助者決済処理では、ステップS14において、援助付オーソリ情報を受信すると、援助者の数と、それぞれの援助者の申し出情報を加盟店端末に表示する(ステップS15A)。実店舗の場合は、店員がこの申し出情報を顧客に口頭で知らせる。スマートフォン等に転送してもよい。顧客が援助を受託すると(ステップS16:Y)、ステップS16Aにおいて、援助者間の負担割合を決定させる。例えば、一方の援助者の援助限度額が8万円、もう一方の援助者限度額が5万円、購入金額が10万円だったとすると、10万円の購入金額をどのように分割するかを顧客(被援助者)に決定してもらう(例えば5万円ずつ負担してもらうか、8万円と2万円に分けて負担してもらうかなど)。もちろん、購入金額の一部を顧客自身が負担するようにしてもよい。
【0068】
ただし、顧客が入力した負担割合は、援助者それぞれの援助条件の詳細を満たすかどうかが更にチェックされる。例えば、購入品の中に、援助者10Cの援助条件中の対象商品等には相当するが、援助者10Aの援助条件中の対象商品等に相当しない商品等がある場合は、その商品等の金額は、たとえ援助者10Aの援助限度額内であっても援助者10Aの負担割合に含めることはできない。
【0069】
そして、このようにして決定された負担割合の金額を、各クレジットカード会社に援助者のカード番号で決済するように依頼する(ステップS17A)。顧客が援助を受託しなかった場合には、顧客自身のカード番号で決済するように顧客のカードのクレジットカード会社に依頼する(ステップS18)。
【0070】
上記の第一から第三までの実施形態において、
図1、
図4、
図6で示したシステム構成及び機能ブロックの構成は、あくまでも一例であり、一つの機能ブロックを更に分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能ブロックは、コンピュータに内蔵されたCPU(Central Processing Unit)が、ROM(Read Only Memory)またはハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、CPUにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能ブロックは、このコンピュータ・プログラムが、記憶装置に格納されたデータベース(DB;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア(例えば、入出力装置、表示装置、通信インターフェース装置)を制御することによって実現される。また、本発明の実施形態におけるデータベース(DB)は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。
【0071】
図8は、被援助者に通知するための援助申し出通知画面の一例を示す図である。図示するように、援助申し出通知画面100Aは、被援助者に対して援助者から援助の申し出があることを通知する手段の一例であり、被援助者の購買情報101に対して、援助者の申し出があることが加盟店端末又は被援助者の端末に表示される。この援助申し出通知画面100Aには、援助者の氏名と、援助条件102が含まれる。また、援助者のメッセージ103が含まれていてもよい。
【0072】
援助申し出通知画面100Aには、被援助者がこの申し出を受ける場合の受諾ボタン104と申し出を遠慮する遠慮ボタン105が用意される。これらのボタンは、援助の申し出を受託するか否かを被援助者に選択させる手段として用いられる。援助申し出通知画面100Aには、更に、被援助者から援助者への返信メッセージを入力する手段である返信メッセージ欄106、被援助者が援助者を登録する手段である援助者登録ボタン107が備えられる。援助者登録ボタン107は、初めての援助申し出等で、被援助者が認識していなかった援助者を登録し、援助内容を記憶するためのボタンである。すなわち、援助者登録ボタン107は、被援助者側から援助者を登録する手段である。被援助者はこの援助内容をいつでも自らの端末から呼出し記憶にとどめたり、逆に、自らを援助者とし今回援助をもらった人(実際にはカード識別番号)を被援助者として登録したりすることもできる。このようにすることで、後のお礼や、「お返し」等に利用することができる。
【0073】
図9は、被援助者に通知するための援助申し出通知画面の別の一例を示す図である。この援助申し出通知画面100Bの援助条件102には、援助対象の代わりに、援助対象日、援助対象店がピンポイントで指定されている。このようにすることで、援助者は、被援助者の特定の日、特定の加盟店での商品等の購入に限定して援助することができる。例えば、この画面の例では、部下がプロジェクト等の打ち上げ会を開くのを察知した会社の上司が、幹事社員のクレジットカード番号又はカード識別番号と、打ち上げ会の日時や開催する店の名前をなんらかの方法で事前に聞き出しておき、打ち上げ会の費用を一部援助するような場面を示している。クレジットカード番号又はカード識別番号を聞き出す際に目的を告げずにしておけば、サプライズが生まれ援助の効果が高まる。また、援助条件を細かく指定しておけば、意図せぬ商品等にまで援助してしまうことや、被援助者以外の悪用も防止できる。なお、クレジットカード番号ではないカード識別番号は、被援助者となり得る者(援助を期待する者)が、メールのフッタやブログなどで予めそれとなく公開しておいてもよい。このようにすることで、「おねだり」のような露骨感が少なくなる。
【0074】
図10は、被援助者に通知するための援助申し出通知画面の更に別の一例を示す図である。この援助申し出通知画面100Cでは、二人の援助者からの援助申し出が通知されている。援助者が二人いる場合には、被援助者の選択により、援助を双方から受けることも、援助を一方のみから受けることもできる。もちろん、どちらの援助も遠慮することもできる。
【0075】
援助を双方から受ける場合に備えて、被援助者が援助者間の負担割合を決定される手段として、負担割合入力欄110a,110bが用意される。負担割合入力欄110a,110bは、援助者の援助額を合算することを被援助者に決定させる手段としても機能する。負担割合は、金額で指定してもよいし、購買情報中の商品番号で指定してもよい。この例では、負担割合入力欄110aには金額で、負担割合入力欄110bには商品番号で指定した場合を示している。この例のように、援助条件102aで指定された対象外の商品を被援助者が同時に購入している場合は、援助条件102aを指定した援助者の負担割合には、援助対象品の金額又は商品番号だけが指定できる。例えば、この画面の場合、負担割合入力欄110aに、援助対象品に合致するICレコーダの代金以外を入力するとエラーとなる。商品番号で負担割合を入力する場合も同様である(商品番号3の「ゲーム攻略本」は、「参考書」には該当しないものとする)。
【0076】
図11は、援助者に送付される援助結果通知の一例を示す図である。本システムでは、被援助者が援助を活用して実際に買い物をしたことが援助者にも通知することができる。この通知は、メール、郵便の他、クレジットカード明細書に含めてもよい。図示するようにこの例の援助結果通知200には、被援助者の購買情報201、援助者が負担した援助負担結果202が記載される。自分以外の援助者がいる場合は、他援助者の援助負担結果203を記載してもよい(ただし、他援助者の氏名までは記載しなくてもよい)。このようにすることで、援助者は、自分の援助が被援助者によって有効に使われたことを知ることができる。
【0077】
この例の購買情報201には、購入品それぞれに対して、商品等の分類と援助対象であったかどうかを示す援助対象記号が示されているが、先に説明した援助申し出画面の購買情報101にも同じように商品等の分類と援助対象記号を表示するようにしてもよい。
【0078】
なお、上記の第一、第二、第三の実施形態は、すべて、典型例として、顧客の所持する電子カードがクレジットカードであるとして説明したが、ポストペイ型の電子マネーカードにも同様の仕組みが適用できる。
【0079】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は、上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に多様な変更または改良を加えることが可能であることは、当業者にとって明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。