(57)【要約】【課題】ショッピングサイトで買い物をしている時には、口座残高が不足するか否か不明であった。【解決手段】ステップＳ３でＣＰＵ２１は、ショッピングサーバ１３から送信された購入予定金額を取得する。ステップＳ６でＣＰＵ２１は、支払口座情報２７ｄを基に、銀行へ口座残高の照会を行い、口座残高を取得する。ステップＳ９で、総合計が口座残高を超えているかを判別する。ステップＳ１８で、残高不足額などを受信した場合は、ステップＳ１９へ進み、ＣＰＵｓは、残高不足等を報知する。具体的には、ショッピングサーバ１３は、ユーザが閲覧しているウェブページに、「この買い物をすると残高不足になります。買い物を続けますか？」とメッセージによる報知する。【選択図】 図４
2015148938.tif 000002
【特許請求の範囲】
【請求項１】
ショッピングサイトで購入予定の商品の購入予定金額を取得する購入予定金額取得部と、
カード決済日までに決済される決済予定明細額の合計に前記購入予定金額を加算し、決済予定合計額を求める決済予定合計額算出部と、
取引銀行口座へ照会して口座残高を取得する口座残高取得部と、
前記取得した口座残高が前記決済予定合計額に満たない場合に、残高不足になることを報知する報知部とを備えることを特徴とするショッピング支援装置。
【請求項２】
請求項１に記載のショッピング支援装置において、
前記決済予定合計額算出部は、前記決済予定合計額に予め定められた定期支払額を加算して決済予定合計額とし、
前記報知部は、前記口座残高が前記加算された決済予定合計額に満たない場合に、残高不足になることを報知することを特徴とするショッピング支援装置。
【請求項３】
請求項１または２のいずれか１項に記載のショッピング支援装置において、
前記購入予定金額取得部で商品の購入予定金額が取得された日を基準に、次の決済日までの間に給与日があれば、前記取得した口座残高に予め定められた給与額を加算する給与額加算部を更に備え、
前記報知部は、前記加算された口座残高が前記決済予定合計額に満たない場合に、残高不足になることを報知することを特徴とするショッピング支援装置。
【請求項４】
請求項１〜３のいずれか１項に記載のショッピング支援装置において、
前記口座残高が前記決済予定合計額に満たない場合に、残高不足額を算出する残高不足額算出部を更に備え、
前記報知部は、前記算出された残高不足額を報知することを特徴とするショッピング支援装置。
【請求項５】
請求項４に記載のショッピング支援装置において、
前記報知部は、前記口座残高が前記決済予定合計額に満たない場合に、前記カード決済日を報知することを特徴とするショッピング支援装置。
【請求項６】
コンピュータに、
ショッピングサイトで購入予定の商品の購入予定金額を取得する購入予定金額取得手順、
カード決済日までに決済される決済予定明細額の合計に前記購入予定金額を加算し、決済予定合計額を求める決済予定合計額算出手順、
取引銀行口座へ照会して口座残高を取得する口座残高取得手順、
前記取得した口座残高が前記決済予定合計額に満たない場合に、残高不足になることを報知する報知手順を実行させるためのショッピング支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ショッピングサイトにおけるショッピング支援装置およびショッピング支援プログラムに関する。
【背景技術】
【０００２】
インターネットに接続されたオンラインのショッピングサイトで買い物をした場合の決済にクレジットカードが広く利用されている。  
【０００３】
ショッピングサイトでは手軽に買い物ができる反面、クレジットカードの決済日になって初めて口座残高が不足する事態が判明することがあった。
従来は、口座残高が不足している場合、予め定めた一定の金額を単位として支払う定額支払方式と、クレジットカードの利用の額に応じ、利用毎に異なる単位で支払う変額支払方式とのうち、変額支払方式による利用の請求額の支払方式を定額支払方式に変更していた（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開番号  ＷＯ２０１１/０６５３０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献１のように、口座残高が不足していることがクレジットカードの決済日に判明するが、ショッピングサイトで買い物をしている時には、口座残高が不足するか否か不明であった。
【課題を解決するための手段】
【０００６】
請求項１に記載のショッピング支援装置は、ショッピングサイトで購入予定の商品の購入予定金額を取得する購入予定金額取得部と、カード決済日までに決済される決済予定明細額の合計に購入予定金額を加算し、決済予定合計額を求める決済予定合計額算出部と、取引銀行口座へ照会して口座残高を取得する口座残高取得部と、取得した口座残高が決済予定合計額に満たない場合に、残高不足になることを報知する報知部とを備えることを特徴とする。
請求項６に記載のショッピング支援プログラムは、コンピュータに、ショッピングサイトで購入予定の商品の購入予定金額を取得する購入予定金額取得手順、カード決済日までに決済される決済予定明細額の合計に購入予定金額を加算し、決済予定合計額を求める決済予定合計額算出手順、取引銀行口座へ照会して口座残高を取得する口座残高取得手順、取得した口座残高が決済予定合計額に満たない場合に、残高不足になることを報知する報知手順を実行させる。
【発明の効果】
【０００７】
本発明によれば、ショッピングサイトで買い物をしている時に、口座残高が不足するかどうかを報知することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施の形態における全体システム構成図を示す図である。
【図２】カードサーバのハードウエア構成を示すブロック図である。
【図３】（ａ）（ｂ）（ｃ）データベースの記憶内容を示す図である。
【図４】（ａ）（ｂ）（ｃ）サーバの動作を示すフローチャートである。
【発明を実施するための形態】
【０００９】
図１は、本発明の一実施の形態に係わる全体システム構成図である。ユーザ端末装置１１は、インターネット網１２を介して、ショッピングサイトを開設しているショッピングサーバ１３に接続される。ショッピングサーバ１３は、インターネット網１２を介して、買い物をしたユーザが決済を行うクレジットカードのクレジットカード発行会社のカードサーバ１４に接続される。更に、カードサーバ１４は、インターネット網１２を介して、クレジットカードの請求額の引き落としを請求する銀行の銀行サーバ１５に接続される。カードサーバ１４と銀行サーバ１５は専用回線を介して接続される構成でもよい。
【００１０】
ユーザ端末装置１１は、パーソナルコンピュータ、携帯端末などであり、ショッピングサーバ１３から受信したショッピングサイトを閲覧して買い物を行う装置である。
【００１１】
ショッピングサーバ１３は、例えば、Apache HTTP Serverなどの、いわゆるWebサーバプログラムを実行することにより実現され、HTTP（Hypertext Transfer Protocol）に規定される手順に基づいて、テキストまたは画像などの各種のオブジェクトが含まれるHTML（Hypertext Markup Language）方式またはXML（Extensible Markup Language）方式などのウェブページによりショッピングサイトを提供する。また、ショッピングサーバ１３は、ショッピングサイトの会員ごとに会員情報、カード情報を記憶する後述のデータベースを備えている。
【００１２】
カードサーバ１４は、クレジットカードごとにカード情報、決済予定明細書、支払口座情報などを記憶する後述のデータベースを備え、ショッピングサイトで買い物が確定されるとショッピングサーバ１３からの情報に応じてデータベースを更新する。
【００１３】
銀行サーバ１５は、カードサーバ１４からのクレジットカードの請求額の引き落とし請求等に応じてユーザの支払口座から引き落としを行うと共に、カードサーバ１４からの要求に応じてユーザの支払口座の口座残高を送信する。
【００１４】
図２は、カードサーバ１４のハードウエア構成を示すブロック図である。ＣＰＵ２１は、後述のフローチャートで示すプログラムを実行し、決済予定合計額等の算出を行う。ＣＰＵ２１は、バスライン２２を介して、記憶部２３、入力部２４、出力部２５、通信部２６、データベース２７が接続される。なお、ユーザ端末装置１１、ショッピングサーバ１３、銀行サーバ１５も同様なハードウエア構成であるので図示を省略する。
【００１５】
記憶部２３には、上述のプログラムが記憶される。また記憶部２３は、ＣＰＵ２１のワークエリアとして機能する。入力部２４は、キーボード、マウスなどで構成される。出力部２５は、ディスプレイやプリンタである。通信部２６は、インターネット網１２に接続される。データベース２７は、クレジットカードごとにカード情報、決済予定明細情報、支払口座情報などを記憶する。なお、ショッピングサーバ１３、銀行サーバ１５は後述の図３（ａ）（ｃ）に示すように、それぞれデータベース２８、データベース２９を有する。
【００１６】
図３（ａ）（ｂ）（ｃ）は、それぞれ、ショッピングサーバ１３のデータベース２８、カードサーバ１４のデータベース２７、銀行サーバ１５のデータベース２９の記憶内容を示す図である。
【００１７】
ショッピングサーバ１３のデータベース２８は、図３（ａ）に示すように、会員情報２８ａとして、ＩＤ、パスワード、住所、氏名などを記憶する。ＩＤ、パスワードは、ユーザがショッピングサイトにログインするためのアカウントである。更に、カード情報２８ｂとして、カード会社名、カード番号、カード有効期限などを記憶する。カード情報２８ｂは、買い物をしたユーザが決済するクレジットカードの情報である。会員情報２８ａおよびカード情報２８ｂは、ショッピングサイトを利用するユーザ毎にそれぞれ記憶されている。
【００１８】
カードサーバ１４のデータベース２７は、図３（ｂ）に示すように、カード情報２７ａ、決済予定明細情報２７ｂ、月定期支払情報２７ｃ、支払口座情報２７ｄ、給与情報２７ｅなどを記憶する。
【００１９】
カード情報２７ａは、カード番号、カード有効期限、カードの決済日などである。決済予定明細情報２７ｂは、ユーザがカードを使用して買い物をした未決済の明細である。カードの決済日に決済が完了した場合に決済予定明細情報２７ｂは消去される。
【００２０】
月定期支払情報２７ｃは、ユーザがカードを使用せずに毎月定期的に支払っている金額である。例えば、電気料金やガス料金であり、ユーザの支払口座から差し引かれる概算金額を示し、その引き落とし日と共に予め記憶される。
【００２１】
支払口座情報２７ｄは、銀行名、口座番号などであり、カードを決済する為のユーザの口座情報である。給与情報２７ｅは、ユーザの給与の概算金額を示し、その振込日と共に予め記憶される。
【００２２】
カード情報２７ａ、決済予定明細情報２７ｂ、月定期支払情報２７ｃ、支払口座情報２７ｄ、および給与情報２７ｅは、クレジットカード毎にそれぞれ記憶されている。この例では、説明を簡単にするために、ユーザは一つのクレジットカードを使用するものとして説明する。
【００２３】
銀行サーバ１５のデータベース２９は、図３（ｃ）に示すように、口座情報２９ａなどを記憶する。口座情報２９ａは、口座番号、口座残高などであり、銀行の口座開設者毎に記憶する。
【００２４】
以下、本発明の一実施の形態に係わるショッピング支援装置の動作を説明する。図４（ａ）は、ショッピングサーバ１３の動作を示すフローチャートである。図４（ｂ）は、カードサーバ１４の動作を示すフローチャートである。図４（ｃ）は、銀行サーバ１５の動作を示すフローチャートである。
【００２５】
先ず、ユーザによる操作手順とその操作に応答するサーバの報知について説明する。
ユーザはユーザ端末装置１１を用いてショッピングサーバ１３が提供しているショッピングサイトにアクセスし、ＩＤ、パスワードを入力して、ショッピングサイトにログインする。その後、ショッピングサイトを閲覧して、ユーザが購入を希望する例えば「商品Ｄ」をマウスで指定し、次に、「ショッピングカートに入れる」のアイコンをマウスで指定する。
【００２６】
他に購入を希望する商品が無く「商品Ｄ」を購入する場合は、次に、「レジに進む」のアイコンをマウスで指定する。すると、ショッピングサーバ１３、カードサーバ１４、銀行サーバ１５は、後述の図４（ａ）（ｂ）（ｃ）に示すフローチャートを実行し、その結果、ユーザの口座残高が不足する場合は、「この買い物をすると残高不足になります。買い物を続けますか？」とメッセージによる報知が行われる。ユーザは、「YES」若しくは「NO」のアイコンを指定できるようになっており、「NO」のアイコンを指定した場合は、「商品Ｄ」は欲しいものリストへ追加されて買い物を終了する。
【００２７】
「YES」のアイコンを指定した場合は、「次回決済日の１０日までに７０００円を追加入金してください。」とメッセージによる報知が行われる。７０００円は、口座残高と比較した不足額である。ユーザは決済日までに入金が可能かを考慮して、「YES」若しくは「NO」のアイコンを指定する。「NO」のアイコンを指定した場合は、「商品Ｄ」は欲しいものリストへ追加されて買い物を終了する。決済日までに入金が可能とユーザが考えた場合は、「YES」のアイコンを指定し、次に、「注文を確定する」のアイコンを指定して買い物を終了する。
【００２８】
次に、ユーザが上述の「レジに進む」のアイコンをマウスで指定した場合に、ショッピングサーバ１３、カードサーバ１４、銀行サーバ１５で実行される処理について、図４（ａ）（ｂ）（ｃ）に示すフローチャートを参照して説明する。これらのフローチャートで示すプログラムは、カードサーバ１４の記憶部２３に記憶される他、図示省略したが、図２で示したカードサーバ１４と同様に構成されたショッピングサーバ１３、銀行サーバ１５の記憶部に記憶される。
【００２９】
図４（ａ）はショッピングサーバ１３のＣＰＵ（図示省略：以下、ＣＰＵｓと称する）が処理する動作を示すフローチャートである。ステップＳ１でＣＰＵｓは、ユーザ端末装置１１より指定された「商品Ｄ」の価格を購入予定金額として取得する。ユーザが複数の商品を購入予定の場合はその合計金額を購入予定金額として取得する。ステップＳ２でＣＰＵｓは、図３（ａ）に示すデータベース２８からカード情報２８ａを参照し、購入予定金額の他に、カード番号を含むカード情報２８ａをインターネット網１２を介してカード会社のカードサーバ１４へ送信する。
【００３０】
図４（ｂ）はカードサーバ１４のＣＰＵ２１が処理する動作を示すフローチャートである。ステップＳ３でＣＰＵ２１は、ショッピングサーバ１３から送信された購入予定金額を取得すると共に、ショッピングサーバ１３から送信されたカード番号等を基にデータベース２７内のカード番号と照合して該当するカード情報２７ａを特定する。
【００３１】
ステップＳ４でＣＰＵ２１は、決済予定明細情報２７ｂを参照して、ユーザがカードを使用して買い物をした未決済の明細「商品Ａ」〜「商品Ｃ」を合計し、更に、ショッピングサーバ１３から送信された購入予定金額、この例では「商品Ｄ」の価格を加算して決済予定合計額を求める。なお、カードの決済日に決済が完了した場合に決済予定明細情報２７ｂは消去される。
【００３２】
ステップＳ５でＣＰＵ２１は、月定期支払情報２７ｃを参照して、決済予定合計額に、現在から決済日までの月定期支払額を加算し、総合計を求める。月定期支払情報２７ｃは、ユーザがカードを使用せずに毎月定期的に口座から引き落とされている金額である。例えば、ガス料金は引き落とし日が毎月１日であり、電気料金は、引き落とし日が毎月５日である場合、現在が４日で決済日が１０日であれば、ガス料金は支払口座から既に引き落とされており、現在から決済日までの月定期支払額は電気料金の額になる。
【００３３】
ステップＳ６でＣＰＵ２１は、支払口座情報２７ｄを基に、銀行へ口座残高の照会を行う。具体的には、支払口座情報２７ｄの銀行名、口座番号などを参照して、銀行サーバ１５へ口座残高の照会を行い、口座残高を取得する。
【００３４】
図４（ｃ）は銀行サーバ１５のＣＰＵ（図示省略：以下、ＣＰＵｂと称する）が処理する動作を示すフローチャートである。ステップＳ７でＣＰＵｂは、カードサーバ１４より送信された口座番号などを基に図３（ｃ）に示す口座情報２９ａより口座照会を行う。そして、テップＳ８でＣＰＵｂは、該当する口座番号より口座残高を読出し、カードサーバ１４へ送信する。
【００３５】
銀行サーバ１５より口座残高を受信したカードサーバ１４のＣＰＵ２１は、図３（ｂ）のステップＳ９で、総合計が口座残高を超えているかを判別する。すなわち、取得した口座残高が総合計に満たないかを判別する。総合計が口座残高を超えている場合は、ステップＳ１０で、ＣＰＵ２１は、次の決済日までの間に給与日が存在するかを、カード情報２７ａおよび給与情報２７ｅを基に判別する。次の決済日までの間に給与日が存在する場合は、ステップＳ１１で、ＣＰＵ２１は、給与情報２７ｅを基に口座残高に給与額を加算する。例えば、給与の振込日が２５日と定められている場合、現在日が決済日の１０日と２５日の間であれば、口座残高に給与額が加算される。
【００３６】
ステップＳ１２で、ＣＰＵ２１は、総合計が口座残高に給与額を加算した額を超えているかを判別する。すなわち、取得した口座残高が総合計に満たないかを判別する。総合計が口座残高に給与額を加算した額を超えていると判別された場合は、ステップＳ１３で、ＣＰＵ２１は、その残高不足額を算出する。すなわち、［総合計］−（［口座残高］＋［給与額］）を算出する。上記ステップＳ１０で、次の決済日までの間に給与日が存在しない場合も、ステップＳ１３に進み、この場合は、ＣＰＵ２１は、その残高不足額を算出する。すなわち、［総合計］−［口座残高］を算出する。
【００３７】
ステップＳ１４で、ＣＰＵ２１は、カード情報２７ａから決済日を、そして、ステップＳ１３で算出した残高不足額をショッピングサーバ１３へ送信する。
【００３８】
上記ステップＳ９で、総合計が口座残高を超えていない場合は、ステップＳ１５に進み、ＣＰＵ２１は、残高不足にならないことを示す「残高内」をショッピングサーバ１３へ送信する。
【００３９】
上記ステップＳ１４若しくはステップＳ１５でショッピングサーバ１３へ通知した後、ステップＳ１６に進み、ＣＰＵ２１は、後述する購入が確定された注文の商品が有れば、その商品の明細を決済予定明細情報２７ｂに追加する。
【００４０】
カードサーバ１４より通知を受けたショッピングサーバ１３のＣＰＵｓは、図３（ａ）のステップＳ１７で、残高不足にならないことを示す「残高内」であるかを判別する。
【００４１】
「残高内」でないと判別された場合、ＣＰＵｓは、ステップＳ１８で、残高不足額などを受信したかを判別する。受信していなければステップＳ１７に戻り、カードサーバ１４からの通知を待つ。ステップＳ１８で、ＣＰＵｓは、決済日および残高不足額を受信するが、これはカードサーバ１４が、上記ステップＳ１４で、カード情報２７ａから決済日を、そして、上記ステップＳ１３で算出した残高不足額をショッピングサーバ１３へ送信したものである。
【００４２】
ステップＳ１８で、残高不足額などを受信した場合は、ステップＳ１９へ進み、ＣＰＵｓは、残高不足等を報知する。具体的には、ショッピングサーバ１３は、ユーザが閲覧しているウェブページに、「この買い物をすると残高不足になります。買い物を続けますか？」とメッセージによる報知と、「YES」および「NO」のアイコンを新たに追加してウェブページを更新し、更新したウェブページをユーザ端末装置１１へ送信する。ユーザ端末装置１１はこの更新されたウェブページを出力部に表示することにより、ユーザに残高不足であることを報知する。
【００４３】
次のステップＳ２０で、ＣＰＵｓは、ユーザ端末装置１１に表示されたウェブページ上において、「YES」または「NO」のいずれのアイコンが指定されたかを判別する。具体的には、「YES」のアイコンが指定された場合は、この指定がショッピングサーバ１３に送信され、これを判別することにより、「YES」のアイコンが指定されて買い物を続けることが判明する。
【００４４】
買い物を続けることが判明した場合は、ステップＳ２１で、ＣＰＵｓは、ユーザが閲覧しているウェブページに、「次回決済日の１０日までに７０００円を追加入金してください。」とメッセージによる報知と、「YES」および「NO」のアイコンを新たに追加してウェブページを更新し、更新したウェブページをユーザ端末装置１１へ送信する。ユーザは期日までに入金が可能かを考慮して、「YES」若しくは「NO」のアイコンを指定する。
【００４５】
ステップＳ２２で、ＣＰＵｓは、ユーザ端末装置１１に表示されたウェブページ上において、「YES」または「NO」のいずれのアイコンが指定されたかを判別する。具体的には、「YES」のアイコンが指定された場合は、この指定がショッピングサーバ１３に送信され、これを判別することにより、「YES」のアイコンが指定されてユーザが了解したことが判明する。
【００４６】
上記ステップＳ２０若しくはステップＳ２２で、「NO」のアイコンが指定された場合は、ステップＳ２３へ進み、ＣＰＵｓは、購入予定であった「商品Ｄ」は欲しいものリストへ追加されて買い物を終了する。
【００４７】
上記ステップＳ１７で、残高不足にならないことを示す「残高内」を受信した場合、若しくは上記ステップＳ２２で、「YES」のアイコンが指定された場合は、ステップＳ２４へ進み、ＣＰＵｓは、「注文を確定する」のアイコンを表示した処理画面をウェブページ上において作成し、ユーザ端末装置１１へ送信する。ユーザ端末装置１１ではユーザが「注文を確定する」のアイコンを指定して注文を確定する。なお、注文が確定されると、上記ステップＳ１６で述べたように、カードサーバ１４のＣＰＵ２１は、購入が確定された商品の明細、例えば「商品Ｄ」を決済予定明細情報２７ｂに追加する。
【００４８】
（変形例）
本発明は、以上説明した実施の形態を次のように変形して実施することができる。
【００４９】
（１）図４（ａ）（ｂ）（ｃ）に示すフローチャートはそれぞれショッピングサーバ１３、カードサーバ１４、および銀行サーバ１５で実行される処理として説明したが、処理に応じて適宜いずれかのサーバで処理するように構成してもよい。
【００５０】
（２）銀行サーバ１５への口座残高の照会を、ユーザの関与なしにカードサーバ１４より行うようにした。しかし、カードサーバ１４より送信された口座番号などを基に、銀行サーバ１５が、口座残高の照会の許可をユーザに得るための確認画面を表示して、ユーザのアカウント入力後に口座残高を照会するようにしてもよい。
【００５１】
（３）月定期支払情報２７ｃを参照して、決済予定合計額に、現在から決済日までの月定期支払額を加算し、総合計を求めた。これにより、支払口座から毎月定期的に引き落とされている金額も考慮して、ショッピングサイトにおける残高不足を報知することができる。しかし、例えば２ヶ月連続して口座残高が不足する事態が生じた場合は、月定期支払額を自動的に所定金額だけ増加するようにしてもよい。これにより、残高不足になることを早めに報知して買い過ぎを防止することができる。
【００５２】
（４）残高不足になって買い物を中断した場合は、ステップＳ２３で、購入予定であった「商品Ｄ」を欲しいものリストへ追加するようにした。この場合、口座残高が増えて、その商品が買えるようになったら、その旨を報知するようにしてもよい。なお、この場合、口座残高を定期的に銀行サーバへ問い合わせるものとする。
【００５３】
（５）月定期支払情報２７ｃを参照して、決済予定合計額に、現在から決済日までの月定期支払額を加算し、総合計を求めた。これにより、支払口座から毎月定期的に引き落とされている金額も考慮して、ショッピングサイトにおける残高不足を報知することができる。しかし、決済予定合計額に定期支払額を加算しなくてもよい。この場合、総合計には支払口座から毎月定期的に引き落とされている金額は反映されないが、ユーザは定期支払額も念頭に入れてショッピングを行えば良い。
【００５４】
以上説明した実施の形態によれば、次の作用効果が得られる。
（１）ショッピング支援装置は、ショッピングサイトで購入予定の商品の購入予定金額を取得する購入予定金額取得部（ステップＳ３）と、カード決済日までに決済される決済予定明細額の合計に購入予定金額を加算し、決済予定合計額を求める決済予定合計額算出部（ステップＳ４）と、取引銀行口座へ照会して口座残高を取得する口座残高取得部（ステップＳ６）と、取得した口座残高が決済予定合計額に満たない場合に（ステップＳ９、Ｓ１２）、残高不足になることを報知する報知部（ステップＳ１４、Ｓ１５、Ｓ１９、Ｓ２１）とを備えることを特徴とする。本発明によれば、ショッピングサイトで買い物をしている時に、リアルタイムで口座残高が不足するかを報知できるので、口座残高を考慮しながら口座残高に見合う買い物を支援することが可能になる。
【００５５】
本発明は、上記の実施の形態に限定されるものではなく、本発明の特徴を損なわない限り、本発明の技術思想の範囲内で考えられるその他の形態についても、本発明の範囲内に含まれる。また、上述の実施の形態と複数の変形例を組み合わせた構成としてもよい。
【符号の説明】
【００５６】
１１  ユーザ端末装置
１３  ショッピングサーバ
１４  カードサーバ
１５  銀行サーバ
２１  ＣＰＵ
２４  入力部
２５  出力部
２６  通信部
２７  データベース
【図１】
2015148938.tif 000003
【図２】
2015148938.tif 000004
【図３】
2015148938.tif 000005
【図４】
2015148938.tif 000006