JP2006163466A - クレジットアカウントの与信枠振替システム - Google Patents

Abstract

【課題】 クレジットの与信枠を、他人にプレゼントする。
【解決手段】 利用者Ａは、与信枠管理部１１０に対して、自己のカード番号を告げ、１万円分の与信枠を利用者Ｂにプレゼントする。与信枠管理部１１０は、決済サーバ２００に１万円分の与信枠を求め、与信ＩＤの発行を受け、この与信ＩＤに対応するギフトＩＤを発行して、電子メールにて利用者Ｂに送付する。利用者Ｂが、実店舗用ＣＡＴ端末５０もしくは仮想店舗用サーバ６０に、ギフトＩＤを入力して、１万円相当の商品購入についての決済要求を行うと、決済要求承認部１２０は、与信枠管理部１１０に問い合わせ、当該ギフトＩＤが正規のものであり、１万円が与信枠内の金額であることを確認した上で、これを承認する。決済処理部１３０は、承認後、決済サーバ２００に対して、該当する与信ＩＤについての決済処理を行う。
【選択図】 図２

Description

本発明は、クレジットアカウントの与信枠振替システムに関し、特に、所定のクレジットアカウントを有する第１の利用者が、オンライン手続によって、その与信枠の一部を第２の利用者に提供できるようにし、第２の利用者が、提供された与信枠の範囲内で、第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするためのシステムに関する。

クレジットカードの普及により、信販会社は様々な形態で利用者に対する与信業務を行っている。通常、個々の利用者には、１ヶ月単位で、所定の与信枠が設定されており、利用者は、この与信枠の金額の範囲内で、クレジットカードを利用した決済を行うことが可能になる。最近は、インターネット上の仮想店舗においても、クレジットカードを利用した決済を行うのが一般的になってきており、利用者は、実店舗と同様に、ネット上の仮想店舗においても、クレジットカードを使用することができる。

このようなネット上の仮想店舗におけるクレジット決済を行うシステムとして、たとえば、下記の特許文献１には、仮想店舗における１回の買い物ごとに、信販会社から所定の取引番号を通知し、この取引番号を利用した決済を行うことにより、利用者の個人情報を秘匿する技術が開示されている。また、下記の特許文献２には、利用者が、ネットワーク経由で有料コンテンツ配信サービスの申し込みを行う際に、信販会社に対して当該利用者の与信確認を行い、その結果に応じて、申し込みの許否を決定する技術が開示されている。
特開２００２−２２２３７６号公報 特開２００４−８６６００号公報

知人へプレゼントを行う場合、特定の商品を贈り物として実際に届ける形態とともに、商品券やギフトカードを贈り物として届ける形態も広く利用されている。後者の形態では、プレゼントの受取人が、商品券やギフトカードを自分の好みの商品と引き換えることができるため、商品の選択権を受取人側に与えることができるというメリットがある。しかしながら、従来の商品券やギフトカードは、実店舗における利用を前提としたものであり、ネット上の仮想店舗において利用することはできない。これは、金券として機能する商品券やギフトカードは、商品と引き換えに店舗側に渡す必要があるためである。

一方、ネット上の仮想店舗における決済手段として、クレジットカードの利用が一般化してきており、自宅に居ながらにして、仮想店舗でプレゼントを購入し、これを知人宛の住所に発送する手続を行うことも可能である。しかしながら、この形態では、あくまでも贈り主が特定の商品を選択することになるため、商品の選択権を受取人側に与えることはできない。

そこで本発明は、クレジットカードによる決済を利用することができ、しかも受取人側が好みの商品を選択できる形態でプレゼントを行うことを可能にするシステムを提供することを目的とする。

(1) 本発明の第１の態様は、所定のクレジットアカウントを有する第１の利用者が、このクレジットアカウントの与信枠の一部を第２の利用者に提供し、第２の利用者が、提供された与信枠の範囲内で、第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするためのクレジットアカウントの与信枠振替システムにおいて、
第１の利用者から端末装置を介して、クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、決済情報および金額情報を、クレジットアカウントの決済サーバへ送信し、これに応じて決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤを提供先情報で特定される第２の利用者に発送する処理を行う与信枠管理部と、
第２の利用者の店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、当該ギフトＩＤが与信枠管理部によって正規に発行された有効なギフトＩＤであり、かつ、当該決済金額が当該ギフトＩＤに対応する与信枠の範囲内であることを条件として、決済要求を承認する決済要求承認部と、
決済要求承認部により、所定の決済要求に対する承認が行われたときに、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を決済サーバへ送信し、第１の利用者のクレジットアカウントを用いた決済が行われるようにする決済処理部と、
を設けるようにしたものである。

(2) 本発明の第２の態様は、所定のクレジットアカウントを有する第１の利用者が、このクレジットアカウントの与信枠の一部を第２の利用者に提供し、第２の利用者が、提供された与信枠の範囲内で、第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするためのクレジットアカウントの与信枠振替システムにおいて、
第１の利用者から端末装置を介して、クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、決済情報および金額情報を、クレジットアカウントの決済サーバへ送信し、これに応じて決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤを提供先情報で特定される第２の利用者に発送するとともに、ギフトＩＤと、これに対応する与信ＩＤおよびその与信枠の金額と、ギフトＩＤが有効であることを示す情報とを、与信枠管理テーブルに記録する処理を行う与信枠管理部と、
第２の利用者の店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、与えられた決済要求に含まれていたギフトＩＤが与信枠管理テーブルに存在し、有効であることを示す情報が記録されており、かつ、その与信枠の金額が決済金額以上であった場合に、当該決済要求を承認する決済要求承認部と、
決済要求承認部により、所定の決済要求に対する承認が行われたときに、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を決済サーバへ送信し、第１の利用者のクレジットアカウントを用いた決済が行われるようにする決済処理部と、
を設け、与信枠管理部が、決済処理部による決済が行われた際に、当該決済済みの与信ＩＤに対応するギフトＩＤが無効であることを示す情報を与信枠管理テーブルに記録するようにしたものである。

(3) 本発明の第３の態様は、所定のクレジットアカウントを有する第１の利用者が、このクレジットアカウントの与信枠の一部を第２の利用者に提供し、第２の利用者が、提供された与信枠の範囲内で、第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするためのクレジットアカウントの与信枠振替システムにおいて、
第１の利用者から端末装置を介して、クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、決済情報および金額情報を、クレジットアカウントの決済サーバへ送信し、これに応じて決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤを提供先情報で特定される第２の利用者に発送するとともに、ギフトＩＤと、これに対応する与信ＩＤおよびその与信枠の金額とを、与信枠管理テーブルに記録し、ギフトＩＤごとに、利用額の履歴を管理する利用額管理テーブルを記録する与信枠管理部と、
第２の利用者の店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、与えられた決済要求に含まれていたギフトＩＤが与信枠管理テーブルに存在し、かつ、その与信枠の金額から利用額管理テーブルに記録されている利用額の合計を差し引いた残額が、決済金額以上であった場合に、決済要求を承認する決済要求承認部と、
所定のギフトＩＤについて、予め定めた所定の決済開始条件が満足されたとき、当該ギフトＩＤについて利用額管理テーブルに記録されている利用額の合計と、当該ギフトＩＤに対応する与信ＩＤとを、決済サーバへ送信し、第１の利用者のクレジットアカウントを用いた決済が行われるようにする決済処理部と、
を設けるようにしたものである。

(4) 本発明の第４の態様は、上述の第１〜第３の態様に係るクレジットアカウントの与信枠振替システムにおいて、
与信枠管理部が、提供先情報として与えられた第２の利用者の電子メールアドレスに基づいて、ギフトＩＤを電子メールによって発送する機能を有するようにしたものである。

(5) 本発明の第５の態様は、上述の第１〜第３の態様に係るクレジットアカウントの与信枠振替システムにおいて、
与信枠管理部が、提供先情報として与えられた第２の利用者の住所に基づいて、当該住所とギフトＩＤとを郵便物上に印刷する機能を有するようにしたものである。

(6) 本発明の第６の態様は、上述の第１〜第３の態様に係るクレジットアカウントの与信枠振替システムにおいて、
与信枠管理部が、提供先情報として与えられた第２の利用者の電話番号に基づいて、ギフトＩＤをファクシミリによって発送する機能を有するようにしたものである。

(7) 本発明の第７の態様は、上述の第１〜第６の態様に係るクレジットアカウントの与信枠振替システムにおいて、
与信枠管理部が、第２の利用者に対して、ギフトＩＤとともに与信枠の金額を示す情報を発送するようにしたものである。

(8) 本発明の第８の態様は、所定のクレジットアカウントを有する第１の利用者が、このクレジットアカウントの与信枠の一部を第２の利用者に提供し、第２の利用者が、提供された与信枠の範囲内で、第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするためのクレジットアカウントの与信枠振替システムにおいて、
第１の利用者から端末装置を介して、クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、決済情報および金額情報を、クレジットアカウントの決済サーバへ送信し、これに応じて決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤおよび与信枠の金額を提供先情報で特定される第２の利用者に発送する与信枠管理部と、
与信枠管理部から発送された情報を格納し、第２の利用者の店舗利用に際して、格納中のギフトＩＤと、格納中の与信枠の金額の範囲内の所定の決済金額と、を含む決済要求を送出するＩＣカードと、
このＩＣカードから決済要求が与えられたときに、当該ＩＣカードが正規のものであることを認証した後、決済要求を承認する決済要求承認部と、
決済要求承認部により、所定の決済要求に対する承認が行われたときに、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を決済サーバへ送信し、第１の利用者のクレジットアカウントを用いた決済が行われるようにする決済処理部と、
を設け、ＩＣカードが、決済要求の承認が行われた際に、承認された当該ギフトＩＤを無効化する処理を行うようにしたものである。

(9) 本発明の第９の態様は、所定のクレジットアカウントを有する第１の利用者が、このクレジットアカウントの与信枠の一部を第２の利用者に提供し、第２の利用者が、提供された与信枠の範囲内で、第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするためのクレジットアカウントの与信枠振替システムにおいて、
第１の利用者から端末装置を介して、クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、決済情報および金額情報を、クレジットアカウントの決済サーバへ送信し、これに応じて決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤおよび与信枠の金額を提供先情報で特定される第２の利用者に発送する与信枠管理部と、
与信枠管理部から発送された情報を格納し、第２の利用者の店舗利用に際して、格納中のギフトＩＤと、格納中の与信枠の金額の範囲内の所定の決済金額と、を含む決済要求を送出する機能を有するＩＣカードと、
このＩＣカードから決済要求が与えられたときに、当該ＩＣカードが正規のものであることを認証した後、決済要求を承認する決済要求承認部と、
所定のギフトＩＤについて、予め定めた所定の決済開始条件が満足されたとき、当該ギフトＩＤについての利用額の合計と、当該ギフトＩＤに対応する与信ＩＤとを、決済サーバへ送信し、第１の利用者のクレジットアカウントを用いた決済が行われるようにする決済処理部と、
を設け、ＩＣカードが、決済要求の承認が行われた際に、承認された決済金額を格納中の与信枠の金額から減ずる更新処理を行うようにしたものである。

(10) 本発明の第１０の態様は、上述の第１〜第９の態様に係るクレジットアカウントの与信枠振替システムにおいて、
与信枠管理部が、第１の利用者を特定する提供元情報を含む与信枠提供要求が与えられたときに、第２の利用者に対して、ギフトＩＤとともに提供元情報を発送するようにしたものである。

(11) 本発明の第１１の態様は、上述の第１〜第１０の態様に係るクレジットアカウントの与信枠振替システムにおいて、
与信枠管理部が、個々のギフトＩＤについてそれぞれ有効期限を設定し、この有効期限を示す情報を第２の利用者に対して発送する機能を有し、与信枠管理部もしくはＩＣカードにおいて、有効期限が経過したギフトＩＤについて無効化する処理を行うようにしたものである。

(12) 本発明の第１２の態様は、上述の第３または第９の態様に係るクレジットアカウントの与信枠振替システムにおいて、
個々のギフトＩＤについての利用額の合計が、当該ギフトＩＤについて最初に設定された与信枠に等しくなったときに、決済開始条件が満足されたと判断するものである。

(13) 本発明の第１３の態様は、上述の第３または第９の態様に係るクレジットアカウントの与信枠振替システムにおいて、
個々のギフトＩＤについて設定された所定の有効期限が経過した時点で、決済開始条件が満足されたと判断するものである。

(14) 本発明の第１４の態様は、上述の第１〜第１３の態様に係るクレジットアカウントの与信枠振替システムにおいて、
決済要求承認部が、インターネット上の仮想店舗サーバを介して決済要求を受け入れ、当該仮想店舗上での第２の利用者による決済を承認するようにしたものである。

(15) 本発明の第１５の態様は、上述の第１〜第１３の態様に係るクレジットアカウントの与信枠振替システムにおいて、
決済要求承認部が、実店舗に設置されたＣＡＴ端末を介して決済要求を受け入れ、当該実店舗上での第２の利用者による決済を承認するようにしたものである。

(16) 本発明の第１６の態様は、上述の第１〜第１５の態様に係るクレジットアカウントの与信枠振替システムにおいて、
決済処理部が、第１の利用者のクレジットアカウントを用いた決済が行われるようにする処理を実行したときに、当該決済が行われた旨を、第１の利用者宛に報告するようにしたものである。

本発明に係るクレジットアカウントの与信枠振替システムによれば、プレゼントの贈り主は、自分のクレジットアカウントの与信枠の一部を、与信ＩＤに対応したギフトＩＤを通知するという形で受取人に提供することができる。ギフトＩＤの通知を受けた受取人は、このギフトＩＤを店舗側に示すことにより、提供を受けた与信枠の金額の範囲内で、贈り主のクレジットアカウントを用いた決済を行うことが可能になる。別言すれば、贈り主のクレジットアカウントの与信枠の一部を、受取人側に振り替える取り扱いが可能になる。このように、本発明に係るシステムを利用すれば、贈り主側は、クレジットカードによる決済を行いつつ、受取人側は、実店舗においても、ネット上の仮想店舗においても、好みの商品をプレゼントとして受け取ることが可能になる。

以下、本発明を図示する実施形態に基づいて説明する。

＜＜＜ §１．基本概念 ＞＞＞
はじめに、本発明の基本概念を簡単に説明する。図１は、現在実施されているクレジットアカウントの与信枠の管理方法の一例を示す模式図である。通常、クレジットカードを発行した信販会社では、個々の利用者アカウントごとに、それぞれ１ヶ月単位で所定の与信枠を設定しており、利用者は、当該１ヶ月の間、設定された与信枠の金額の範囲内で、クレジットカードによる決済が可能になる。

図１に示す例は、利用者Ａに対して、１ヶ月分の与信枠として１０万円が設定された例である。すなわち、月の初めには、図１(a) に示すように、与信枠の１０万円がそっくり残っており、当該月には、合計１０万円分の決済が可能である。このような与信枠の管理は、信販会社が設置した決済サーバによって行われる。

さて、この利用者Ａが、クレジットカードを用いて実店舗で買い物を行う場合、当該店舗のＣＡＴ端末から決済サーバに対して、利用者Ａのクレジットアカウントによる決済に必要な決済情報（通常は、クレジットカード番号と当該カードの有効年月を示す情報）および利用金額が通知され、信販会社の承認を得る処理が行われる。決済サーバは、通知された利用金額が、当該クレジットアカウントの与信枠の残りの範囲内であれば、所定の与信ＩＤを発行し、これを店舗側に通知した上で、クレジットカードの利用を承認する。図１(b) は、利用者Ａが、クレジットカードを利用して、店舗で２万円の買い物をする場合に、これが承認されたときの決済サーバの記録内容を示している。この例では、当初の与信枠１０万円のうち、２万円分の利用について、与信ＩＤ「Ｙａ１」の発行により承認がなされたことになる。この時点での当該アカウントの与信枠の残額は８万円である。なお、ここでは便宜上、「Ｙａ１」のような簡単な与信ＩＤを用いた説明を行っているが、実際の与信ＩＤには、セキュリティを確保する上で、より複雑なコードが用いられる。

こうして、決済サーバから店舗側に対して与信ＩＤを発行して承認を通知すると、店舗側から決済サーバに対して、当該与信ＩＤを用いた決済要求が出される。決済サーバは、この決済要求に基づいて決済処理を行う。図１(c) は、このような決済処理が完了したときの決済サーバの記録内容を示している。店舗側からは、承認時に発行した与信ＩＤ「Ｙａ１」を伴う決済要求が送信されてくるので、この与信ＩＤ「Ｙａ１」に対応する与信枠の部分について決済が完了した旨の記録（図では、ハッチングを施して示す）が行われている。

続いて、この利用者Ａが、インターネット上の仮想店舗において、３万円分の買い物を行う場合を考える。この場合、当該仮想店舗を運営する販売サイトのサーバから決済サーバに対して、利用者Ａの決済情報および利用金額が通知され、与信枠の確認が行われる。決済サーバは、通知された利用金額が、当該クレジットアカウントの与信枠の残りの範囲内であれば、所定の与信ＩＤを発行し、これを店舗側に送信した上で、クレジットカードの利用を承認する。図１(d) は、この３万円分の利用について、与信ＩＤ「Ｙａ２」の発行により承認がなされた状態を示している。この時点での当該アカウントの与信枠の残額は５万円である。

一般に、実店舗での買い物の場合、与信ＩＤの発行による決済サーバからの承認が得られると、実店舗側から決済サーバに対して、当該与信ＩＤを伴う決済要求が送信され、直ちに決済処理が行われることが多い。しかしながら、仮想店舗での買い物の場合、与信ＩＤが発行され、決済サーバによる承認が得られたとしても、商品が実際に発送されるまで、決済処理が留保されることも少なくない。特に、納期が何日も先になるような取り寄せ商品の場合、与信ＩＤの発行により承認だけ受けておき、実際に商品が出荷された時点であらためて決済処理を行うのが一般的である。したがって、１つの与信ＩＤについての決済処理が完了しないうちに、次の与信ＩＤの発行が行われるケースもある。

たとえば、上述した仮想店舗における３万円分の買い物についての決済処理が完了しないうちに、この利用者Ａが更に別な実店舗で１万円分の買い物をしたとしよう。この場合、図１(e) に示すように、１万円分の利用について、与信ＩＤ「Ｙａ３」の発行により承認がなされ、この与信ＩＤ「Ｙａ３」について、店舗側から直ちに決済要求が出されたとすると、図１(f) に示すように、この１万円分の与信ＩＤ「Ｙａ３」についての決済処理がなされることになる。この時点では、与信ＩＤ「Ｙａ２」についての決済処理は行われていないが、与信枠の残額は４万円となる。

このような運用を行うことにより、利用者Ａは、１ヶ月間に１０万円分の枠を利用することができる。この与信枠の残額を超えるような金額の買い物については、決済サーバによる承認が得られないので、そのような買い物についてのクレジットカードによる決済は拒絶されることになる。月が改まると、また新たな１０万円分の与信枠が設定される。なお、ここで述べた例は、信販会社による運用の一般的な従来例を示すものであり、実用上の細かな取り扱いは、個々の信販会社によって異なる。

さて、上述したクレジットアカウントの利用形態は、実店舗あるいは仮想店舗において、あくまでも利用者Ａ自身が買い物を行うことを前提としている。したがって、図１に示されている与信ＩＤ「Ｙａ１」，「Ｙａ２」，「Ｙａ３」は、いずれも利用者Ａ自身の買い物に対して発行された与信ＩＤである（小文字ａは、利用者Ａの買い物に充てられることを示す）。本発明の基本概念は、他人が買い物を行うことを前提として与信ＩＤを発行し、当該他人が実際に買い物をしたときに、当該与信ＩＤについて決済処理を行うようにする、という発想にある。

たとえば、図１(e) に示す与信ＩＤ「Ｙａ３」は、利用者Ａ自身の１万円の買い物に対して発行されたものであるが、ここでは説明の便宜上、この１万円分の与信枠を、知人である利用者Ｂのために確保したものとしよう。別言すれば、利用者Ａが、自己のクレジットアカウントの与信枠の中から、１万円分の枠を利用者Ｂにプレゼントしたことになる。ここでは、こうして利用者Ｂに提供された与信枠についての与信ＩＤを「Ｙａ３」の代わりに「Ｙｂ３」と記述することにする（小文字ｂは、利用者Ｂの買い物に充てられることを示す）。この与信ＩＤ「Ｙｂ３」に係る与信枠の１万円は、利用者Ｂの買い物に充てられることになるため、もはや利用者Ａの関知するところではないが、利用者Ｂが買い物を行った場合、その代金は、利用者Ａの当該クレジットアカウントにより決済されることになる。したがって、与信ＩＤ「Ｙｂ３」の発行を受けて、１万円分の枠を確保した時点で、利用者Ａの与信枠の残額は、１万円分減ってしまうことになる。

結局、利用者Ｂには、利用者Ａから、「１万円分の買い物を行う権利」がプレゼントされたことになり、クレジットアカウントの与信枠が利用者Ａから利用者Ｂへと振り替えられたことになる。もちろん、利用者Ｂには、このようなプレゼントがなされた事実が通知される。そこで、利用者Ｂは、後述する方法により、この「１万円分の買い物を行う権利」を行使して、店舗にて１万円分の買い物を行うことになる。利用者Ｂが１万円分の買い物を行うと、その事実が与信ＩＤ「Ｙｂ３」とともに決済サーバへと報告され、図１(f) に示すような決済処理が実行される。決済処理が行われた金額については、後日、利用者Ａの銀行口座などからの引き落としがなされることになる。

結果的に、利用者Ａは利用者Ｂに対して、１万円分の商品をプレゼントしたことになるが、商品を選択するのは利用者Ｂであるので、受取人側が好みの商品を選択できることになる。しかも、利用者Ａは、この１万円分のプレゼントの決済を、クレジットカードによって行うことができる。これは、従来の商品券やギフトカードをプレゼントする形態に比べて、大きなメリットである。すなわち、クレジットカードによる決済が可能であるため、利用者Ａの銀行口座から１万円分の引き落としが生じるのは、利用者Ｂが実際に１万円分の買い物を行い、決済サーバにおける決済処理が完了した後のことになる。商品券やギフトカードを用いてプレゼントを行う従来の形態では、利用者Ａが商品券やギフトカードを購入する時点で、１万円分の現金が必要になる。

また、受取人である利用者Ｂにとっても、クレジットアカウントの与信枠という形態でのプレゼントは、非常に使い勝手のよいものになる。なぜなら、商品券やギフトカードは、実店舗での利用を前提としたものであり、ネット上の仮想店舗で利用することはできないが、クレジットアカウントの与信枠という形態でのプレゼントであれば、実店舗であろうが、仮想店舗であろうが、支障なく利用することが可能になるからである。

なお、プレゼントの受取人となる利用者Ｂは、利用者Ａが利用するクレジットカードの会員である必要はない。本願でいう「与信枠の振替」とは、「２つの異なるクレジットアカウント間の振替」を意味するものではなく、「利用者Ａのクレジットアカウントの与信枠を利用者Ｂの買い物に充てる」ことを意味している。また、本願にいう「利用者」とは、「クレジットカードの利用者」の意味で用いているわけではなく、「本願システムの利用者」の意味で用いているものである。

＜＜＜ §２．本発明に係るシステムの基本構成 ＞＞＞
続いて、本発明の基本的な実施形態に係るクレジットアカウントの与信枠振替システムの構成を図２のブロック図を参照しながら説明する。図２に示すとおり、この実施形態に係る与信枠振替システム１００は、与信枠管理部１１０、決済要求承認部１２０、決済処理部１３０によって構成されている。この与信枠振替システム１００を利用して、利用者Ａは、自己のクレジットアカウントの与信枠の一部を、知人である利用者Ｂにプレゼントすることが可能になる。

ここでは、説明の便宜上、利用者Ａが、信販会社Ｘのクレジットカードを保有しているものとし、この信販会社Ｘが設置した決済サーバ２００において、利用者Ａのアカウントの管理が行われているものとする。決済サーバ２００は、クレジットアカウントの決済に利用される一般的なサーバであり、図１に示した例のように、クレジットに加盟している店舗からの申請に応じた承認処理（与信ＩＤを発行する処理）と、当該店舗からの決済要求に応じた決済処理を行う機能を有している。このような決済サーバ２００自体は、既に公知のものであるため、ここでは決済サーバ２００の細かな処理機能についての説明は省略する。図２に示す決済サーバ２００のブロック内には、利用者Ａのアカウントについて、１ヶ月分の与信枠が１０万円に設定され、既に、３つの与信ＩＤ「Ｙａ１」，「Ｙａ２」，「Ｙｂ３」が発行された状態が示されている。

一方、利用者Ｂは、信販会社Ｘのクレジットカードを保有している必要は全くない。もちろん、利用者Ｂが、信販会社Ｘのクレジットカードを保有していた場合であっても、以下に説明する事例は、あくまでも利用者Ａのクレジットアカウントを用いて決済を行う事例であり、利用者Ｂのクレジットアカウントには何ら影響を与えない。

ここに示す実施形態では、図示のとおり、利用者Ａは、端末装置１０を利用して与信枠振替システム１００にアクセスすることが可能であり、利用者Ｂは、端末装置２０を利用して、与信枠振替システム１００からの通知を受けることが可能である。端末装置１０，２０は、ネットワークを利用して与信枠振替システム１００に接続可能な装置であれば、どのような装置を用いてもかまわない。実用上は、パソコン、携帯電話、ＰＤＡなどの機器を、端末装置１０，２０として用いるのが一般的である。また、ここに示す実施形態では、利用者Ｂは、実店舗だけでなく、インターネット上の仮想店舗を利用して買い物を行うことができ、端末装置２０は、実店舗用ＣＡＴ端末５０や仮想店舗用サーバ６０と交信する機能を有している。

与信枠振替システム１００の役割は、信販会社Ｘのクレジットアカウントを有する利用者Ａが、このクレジットアカウントの与信枠の一部を利用者Ｂに提供し、利用者Ｂが、提供された与信枠の範囲内で、利用者Ａのクレジットアカウントを利用した決済を行うことができるようにすることにある。この与信枠振替システム１００は、各利用者Ａ，Ｂが用いる端末装置１０，２０や、実店舗用ＣＡＴ端末５０および仮想店舗用サーバ６０と情報のやりとりを行うことができ、また、決済サーバ２００に対しても情報のやりとりを行うことができるコンピュータによって構成されている。実用上、これらの情報のやりとりは、インターネットを介して行うのが最も好ましい。この場合、与信枠振替システム１００は、インターネット上に設置されたサーバ用コンピュータに、専用のアプリケーションソフトウエアを組み込むことにより構成され、与信枠管理部１１０、決済要求承認部１２０、決済処理部１３０の各構成要素は、サーバ用コンピュータに組み込まれたプログラムによって実現されることになる。

与信枠管理部１１０の第１の機能は、端末装置１０を介して利用者Ａから与えられる与信枠提供要求を受け取る機能である。この与信枠提供要求は、利用者Ａの保有する特定のクレジットアカウントの与信枠の中の所定金額部分を、利用者Ｂに提供する意志表示を示すものであり、図示のとおり、「決済情報」、「金額情報」、「提供先情報」を含む要求として与えられる。ここで、「決済情報」は、利用者Ａのクレジットアカウントによる決済を行うために必要な情報であり、ここに示す実施形態では、利用者Ａが保有するクレジットカードの番号と有効年月を示す情報が、「決済情報」として利用されている。「金額情報」は、提供対象となる与信枠の金額を示す情報であり、利用者Ｂへのプレゼントの金額に相当する。ここでは、説明の便宜上、「１万円」という「金額情報」が与えられたものとする。最後の「提供先情報」は、プレゼントの提供先となる利用者Ｂを特定するための情報であり、ここに示す実施形態では、利用者Ｂの電子メールアドレスを「提供先情報」として用いている。もちろん、実用上は、利用者Ｂの住所、氏名、電話番号なども「提供先情報」の一部として用いるのが好ましい。

上述したように、端末装置１０としては、一般的なパソコン、携帯電話、ＰＤＡ機器などが用いられるので、与信枠管理部１１０の上述した第１の機能は、Ｗｅｂページを利用して実現するのが好ましい。すなわち、利用者Ａが、端末装置１０のＷｅｂブラウザ機能を利用して、与信枠管理部１１０が提供する所定のＷｅｂページをアクセスし、このＷｅｂページ上で、「決済情報」、「金額情報」、「提供先情報」などの情報を入力して、与信枠提供要求を行うことができるようにすればよい。結局、ここに示す例では、利用者Ａが保有する特定のアカウントから（決済情報）、利用者Ｂに対して（提供先情報）、１万円分（金額情報）の与信枠を提供する旨の与信枠提供要求がなされたことになる。

与信枠管理部１１０の第２の機能は、上述した第１の機能により与信枠提供要求を受け取ったときに、この与信枠提供要求に含まれていた「決済情報」および「金額情報」を決済サーバ２００へ送信して承認申請を行い、承認のための与信ＩＤの発行を受ける機能である。ここに示す例では、「決済情報」として、クレジットカード番号と有効年月の情報を用いているので、与信枠管理部１１０から決済サーバ２００に対して、これらの情報とともに金額情報が送信されることになる。

決済サーバ２００は、クレジットカード番号と有効年月からなる「決済情報」と１万円という「金額情報」とを含む承認申請を受け取ると、当該「決済情報」で特定される利用者Ａのアカウントの与信枠の残額を調べ、「金額情報」として与えられた１万円が、現在の与信残額の範囲内であれば、これを承認する。すなわち、与信残額を１万円分減額し、この１万円分についての与信ＩＤ「Ｙｂ３」を発行して、与信枠管理部１１０へ返信する処理を行う。図２の決済サーバ２００のブロックには、このときの状態が模式図として示されている（「Ｙａ１」，「Ｙａ２」は、利用者Ａ自身の買い物に対して発行された与信ＩＤであるが、「Ｙｂ３」は、利用者Ｂの買い物のために発行された与信ＩＤになる）。もちろん、与信残額が十分に残っていない場合、承認申請は拒絶され、与信ＩＤが発行されることはない。

与信枠管理部１１０の第３の機能は、上述した第２の機能による承認申請が認められ、決済サーバ２００によって与信ＩＤが発行されたら、この与信ＩＤを受信し、当該与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤを「提供先情報」で特定される利用者Ｂに発送する機能である。具体的には、決済サーバ２００から「Ｙｂ３」なる与信ＩＤが発行されるので、これに対応するギフトＩＤ（たとえば、「１２３４５」なるコード）を発行し、このギフトＩＤを利用者Ｂに対して発送する処理が行われる。

なお、ギフトＩＤは、与信ＩＤに対応するユニークなコードであれば、どのようなコードであってもかまわない。与信枠管理部１１０に、所定のギフトＩＤ発生アルゴリズムに基づくプログラムを用意しておけば、個々の与信ＩＤに対応したユニークなギフトＩＤを自動的に生成することが可能である。ただ、後述するように、このギフトＩＤを知得した者は、与信ＩＤ「Ｙｂ３」に対応する与信枠を利用した買い物が可能になるので、セキュリティ確保の点からは、第三者が容易に類推できないような複雑なコード（できれば、数字と英字を組み合わせた１０桁以上のコード）をギフトＩＤとして用いるのが好ましい。もちろん、与信ＩＤをそのままギフトＩＤとして用いることも可能であるが、やはりセキュリティ確保の観点からは、与信ＩＤとは異なるギフトＩＤを用いるのが好ましい。ここでは、説明の便宜上、与信ＩＤ「Ｙｂ３」に対応するギフトＩＤとして、「１２３４５」なる単純なコードが発行されたものとして、以下の説明を続けることにする。

こうして発行したギフトＩＤ「１２３４５」は、「提供先情報」で特定される利用者Ｂのもとに発送される。ここで述べる実施例の場合、「提供先情報」として、利用者Ｂの電子メールアドレスが用いられているので、ギフトＩＤ「１２３４５」は、利用者Ｂ宛の電子メールとして送信されることになり、利用者Ｂは、端末装置２０を用いて、この電子メールを受信することができる（もちろん、別な端末装置で受信した電子メールを、端末装置２０へ移してもよい）。

なお、実用上は、ギフトＩＤ「１２３４５」とともに、利用者Ａ（贈り主）を特定する提供元情報を利用者Ｂに発送するのが好ましい。そのためには、利用者Ａから与信枠管理部１１０に対して与えられる与信枠提供要求の中に、利用者Ａを特定する提供元情報を含ませておくようにすればよい。上述したように、Ｗｅｂブラウザ機能をもった端末装置１０から、Ｗｅｂページ上での入力という形式で与信枠提供要求を受け付ける場合であれば、このＷｅｂページ上で、利用者Ａの氏名などを入力してもらい、これを利用者Ｂに伝えるようにすればよい。そうすれば、利用者Ｂは、利用者Ａからのプレゼントであることを認識することができる。もっとも、贈り主の名前を匿名としたプレゼントも可能であるので、利用者Ｂに対して、贈り主が誰であるかを特定する情報（提供元情報）を発送することは、本発明を実施する上での必須事項ではない。

また、実用上は、ギフトＩＤ「１２３４５」とともに、提供された与信枠の金額を示す金額情報を利用者Ｂに発送するのが好ましい。利用者Ｂは、この金額情報を知ることにより、実店舗や仮想店舗において、いくらの価格の商品を選択することができるのかを認識できる。ただし、プレゼントの金額が受取人に明確に伝わるのは、好ましくないケースもある。このような場合には、利用者Ｂに金額情報を伝えなくてもかまわない。

このように、贈り主の名前や金額については、必要に応じて、利用者Ｂに伝えるようにすればよい。これらの情報を利用者Ｂに伝えるべきか否かは、もっぱら贈り主である利用者Ａの意向に沿うことになるので、実際には、与信枠管理部１１０が、利用者Ａから与信枠提供要求を受け付ける時点で、これらの情報を受取人に伝えるべきか否かを指示させるようにするのが好ましい。たとえば、Ｗｅｂページ上で与信枠提供要求を受け付ける場合であれば、「贈り主の名前を相手に伝える」および「利用金額を相手に伝える」といったチェック欄を設けておき、必要に応じて、このチェック欄にチェックを入れてもらうようにすればよい。

結局、本発明を実施する上では、利用者Ｂに対して、最低限、ギフトＩＤ「１２３４５」を伝えればよいことになる。もちろん、実用上は、「１２３４５」なるコードだけを伝えても無意味であるから、当該コードがギフトＩＤである旨と、その利用方法を説明する記述も付け加える必要がある。したがって、実際には、利用者Ｂ宛の電子メールの文面は、たとえば、次のような形態になる。

「利用者Ｂ様、このたび、利用者Ａ様より、１万円相当の商品がプレゼントされました。商品を選ぶのはあなたです。○○デパートの売り場にて、下記のギフトＩＤを伝えた上で、商品をお選びください。あるいは、http://www.○○○.com/のショッピングサイトへアクセスし、下記のギフトＩＤを入力した上で、商品をお選びください。
＜ギフトＩＤ：１２３４５＞」

さて、このような電子メールを受信した利用者Ｂは、ギフトＩＤ「１２３４５」を実店舗（○○デパート）あるいは仮想店舗（http://www.○○○.com/のショッピングサイト）で利用して、１万円相当の商品と引き換えることになる。

たとえば、○○デパートで引き換えを行う場合は、売り場で１万円相当の商品を選択し、実店舗用ＣＡＴ端末５０を用いた決済処理を行うことになる。すなわち、実店舗用ＣＡＴ端末５０に対して、ギフトＩＤと決済金額とを入力し、決済要求承認部１２０に対して決済要求を行う処理がなされる。上述の例の場合、「１２３４５」なるギフトＩＤと「１万円」なる決済金額とを含む決済要求が、決済要求承認部１２０に対して行われる。

なお、実用上は、利用者Ｂ自身が実店舗用ＣＡＴ端末５０を操作することは困難であるから、上記決済要求のための操作は、売り場の係員の手によって行われることになろう。より好ましい実施形態としては、端末装置２０自身に、実店舗用ＣＡＴ端末５０と協働
して決済要求の処理を行う機能を付加しておけばよい。

たとえば、端末装置２０として携帯電話を用いている場合、この携帯電話に、上述の決済要求処理を行うための専用のアプリケーションプログラムをインストールしておき、当該アプリケーションプログラムを起動させることにより、自動的に決済要求処理が行われるようにすることが可能である。具体的には、利用者Ｂには、ギフトＩＤを含む電子メールを選択する作業のみを行ってもらい、アプリケーションプログラムにより、選択された電子メールから、ギフトＩＤ「１２３４５」を自動的に抽出する処理を行い、これを赤外線通信あるいはBluetoothなどの無線通信を利用して、実店舗用ＣＡＴ端末５０側へと転送する処理を行えばよい。「１万円」なる決済金額は、同様に、電子メールから自動抽出して転送することも可能であるし、店舗の係員により、実店舗用ＣＡＴ端末５０へ直接入力させることも可能である。

なお、このように、専用のアプリケーションプログラムによって、ギフトＩＤ「１２３４５」を自動抽出する場合、利用者Ｂ自身が、ギフトＩＤの存在を認識する必要はないので、電子メールの本文にギフトＩＤを記載する必要はなくなる（たとえば、ギフトＩＤを、電子メールを構成するデータの一部に埋め込んでおくことができる）。

さて、実店舗用ＣＡＴ端末５０に対してネットワーク接続されている決済要求承認部１２０は、このような決済要求を受けると、当該決済要求に含まれているギフトＩＤが、与信枠管理部１１０によって正規に発行された有効なギフトＩＤであリ、かつ、当該決済要求に含まれている決済金額が、当該ギフトＩＤに対応する与信枠の範囲内であることを条件として、前記決済要求を承認する処理を行う。上述の例の場合、決済要求承認部１２０に対して、「１２３４５」なるギフトＩＤと「１万円」なる決済金額を含む決済要求が、実店舗用ＣＡＴ端末５０より送信されてくることになるので、決済要求承認部１２０は、この「１２３４５」なるギフトＩＤが与信枠管理部１１０によって正規に発行された有効なギフトＩＤであリ、かつ、「１万円」なる決済金額が、当該ギフトＩＤに対応する与信枠の範囲内であることを確認した上で、実店舗用ＣＡＴ端末５０に対して、決済要求を承認する旨の回答を行うことになる。もちろん、上記条件が満足されていない場合には、不承認の回答が行われる。

実店舗用ＣＡＴ端末５０に対して、承認する旨の回答が与えられた場合には、この売り場における決済処理は完了である。売り場の係員は、クレジットカード決済による通常の販売形態と同様に、利用者Ｂに「お買い上げ商品」を手渡すことになる。別言すれば、実店舗用ＣＡＴ端末５０に対しては、与信枠振替システム１００が決済サーバ２００と同等の機能を果たすことになり、与信枠振替システム１００が決済サーバ２００に代わって、実店舗用ＣＡＴ端末５０に対する代行決済を行ったことになる。

一方、決済サーバ２００に対する本来の決済処理は、決済処理部１３０によって実行される。すなわち、決済処理部１３０は、決済要求承認部１２０により、実店舗用ＣＡＴ端末５０からの決済要求に対する承認が行われたときに、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を決済サーバ２００へ送信し、利用者Ａのクレジットアカウントを用いた決済が行われるようにする。上述の例の場合、「１２３４５」なるギフトＩＤと「１万円」なる決済金額を含む決済要求に対する承認が行われたので、決済処理部１３０は、「１２３４５」なるギフトＩＤに対応する与信ＩＤを与信枠管理部１１０に問い合わせ、当該与信ＩＤが「Ｙｂ３」であることを認識し、決済サーバ２００に対して、与信ＩＤ「Ｙｂ３」と「１万円」なる決済金額を送信して決済を求めることになる。

決済サーバ２００は、決済処理部１３０からの決済要求を受けて、与信ＩＤ「Ｙｂ３」について確保しておいた「１万円」なる与信枠に対する決済処理を行う。すなわち、利用者Ａのアカウントから、１万円分の決済が行われることになり、所定の期日に、利用者Ａの銀行口座などからの引き落としが行われる。結局、利用者Ａの与信枠提供要求によって決済サーバ２００上に確保されていた与信ＩＤ「Ｙｂ３」に対応する１万円分の与信枠は、利用者Ｂが買い物をすることによって決済される運びとなる。逆に言えば、当該１万円分の与信枠は、利用者Ｂが買い物をしない限り、決済されずに残ることになり、利用者Ａの銀行口座などからの引き落としは延期される。これは、商品券やギフトカードをプレゼントした場合と大きく異なる点である。

ここに示す実施形態では、決済処理部１３０は、決済サーバ２００に対して、与信ＩＤ「Ｙｂ３」と「１万円」なる決済金額を送信して決済を求める処理を実行したときに、当該決済が行われた旨を、利用者Ａ宛に報告する処理も併せて実行する機能を有している。図２に示すブロック図の場合、利用者Ｂが１万円分の利用を行い、決済サーバ２００上で与信ＩＤ「Ｙｂ３」に関する決済が行われた時点で、決済処理部１３０から端末装置１０に対して、決済が完了した旨の報告がなされる。このような報告を行うためには、端末装置１０から与信枠管理部１１０に対して、与信枠提供要求がなされたときに、利用者Ａの電子メールアドレスを入力させるようにしておけばよい。そうすれば、決済処理部１３０から当該電子メールアドレス宛に、たとえば、「利用者Ａ様 ○月○日にお申し込みいただいた利用者Ｂ様宛の与信枠の１万円は、本日、○○デパートにおいて、商品○○の御購入により決済されました。」というような報告メールを送信することができる。このような報告メールを、たとえば、端末装置１０によって受信した利用者Ａは、支障なくプレゼントの贈呈が行われたことを確認することができ、しかも利用者Ｂがどのような商品を選択したかを認識することもできる。

本発明に係る与信枠振替システム１００を利用したプレゼントが、商品券やギフトカードのプレゼントと大きく異なるもうひとつの点は、ギフトＩＤをプレゼントされた利用者Ｂが、実店舗だけでなく、仮想店舗を利用した買い物もできるようになる点である。利用者Ｂが、インターネット上の仮想店舗を利用した買い物を行う場合の処理も、基本的には、上述した実店舗を利用した買い物の処理と同様である。すなわち、利用者Ｂは、端末装置２０を用いて、仮想店舗用サーバ６０へとアクセスし、当該仮想店舗に用意されている商品群の中から、１万円相当の好みの商品を選択するとともに、プレゼントされたギフトＩＤを入力する操作を行えばよい。仮想店舗用サーバ６０から決済要求承認部１２０に対して、ギフトＩＤと決済金額とを含む決済要求が出され、これに対して、決済要求承認部１２０による承認がなされる点は、上述した実店舗を利用した場合の処理と全く同様である。

この場合、利用者Ｂは、仮想店舗用サーバ６０に対するギフトＩＤの入力を、端末装置２０用の入力機器を利用して手作業で行うこともできるが、端末装置２０にインストールした専用アプリケーションプログラムにより、自動入力することも可能である。たとえば、端末装置２０としてパソコンや携帯電話を用いている場合、このパソコンや携帯電話に、専用のアプリケーションプログラムをインストールしておき、当該アプリケーションプログラムを起動させることにより、電子メールからギフトＩＤ「１２３４５」を自動的に抽出する処理を行い、これを仮想店舗用サーバ６０側へと自動送信させるようにすればよい。そうすれば、利用者Ｂは、ギフトＩＤの存在を全く認識する必要はない。利用者Ｂが、仮想店舗用サーバ６０によって提示されるＷｅｂページ上で、１万円相当の所望の商品を選択する操作を行えば、仮想店舗用サーバ６０を介して決済要求承認部１２０に対して、「１２３４５」なるギフトＩＤと「１万円」なる決済金額とを含んだ決済要求を自動的に送信することができる。

この決済要求に応じて、決済要求承認部１２０から仮想店舗用サーバ６０に対して、承認の回答が送信されてきたら、仮想店舗用サーバ６０は、利用者Ｂが選択した商品を発送するための処理を進めることができる。もちろん、これに付随して、決済処理部１３０によって決済サーバ２００に対して行われる決済処理も、上述した実店舗を利用した場合の処理と全く同様である。

なお、利用者Ｂに、利用金額の提示を行わない場合には、実店舗や仮想店舗において、若干の工夫が必要である。前述したように、本発明を実施する上で、与信枠管理部１１０から端末装置２０に送信する最低限の情報は、ギフトＩＤであり、提供された与信枠の金額を利用者Ｂに伝える必要はない。たとえば、香典返しの商品などを利用者Ｂに返礼するようなケースでは、金額を伝えるのはむしろ好ましくないであろう。この場合、利用者Ｂには、所定のギフトＩＤとともに、利用者Ａから香典返しとしてのプレゼントが贈呈された旨が電子メールで伝えられることになるが、金額は通知されないので、実店舗や仮想店舗において、いくらの商品を選択すればよいのかがわからない。

このように利用者Ｂに金額を通知しないケースでは、利用者Ｂが、特定の商品グループの中から商品選択を行うことができるように、何らかのガイド手段を講じておくようにすればよい。たとえば、実店舗での利用については、「○○デパートの○○売り場の松コーナーの商品とお引き換えください」のような文面を電子メールに入れておくようにして、該当金額の商品のみを陳列した松コーナーへとガイドすればよい。あるいは、仮想店舗での利用については、「http://www.○○○.com/matsu/へアクセスして、ご希望の商品をお選びください」のような文面を電子メールに入れておくようにして、該当金額の商品のみが表示されたＷｅｂページへとガイドすればよい。

もちろん、実店舗用ＣＡＴ端末５０や仮想店舗用サーバ６０を用いて、与信枠管理部１１０に対して、利用者Ｂから提示されたギフトＩＤについての金額をオンラインで照会
するようにし、回答として得られた金額に応じた商品を利用者Ｂに提示して選択させるようなことも可能である。

＜＜＜ §３．決済要求の具体的な承認方法 ＞＞＞
既に述べたとおり、図２に示す決済要求承認部１２０は、利用者Ｂの店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、当該ギフトＩＤが与信枠管理部１１０によって正規に発行された有効なギフトＩＤであリ、かつ、当該決済金額が当該ギフトＩＤに対応する与信枠の範囲内であることを条件として、与えられた決済要求を承認する処理を行う。ここでは、この決済要求承認部１２０による決済要求承認処理の具体的な方法を述べる。

実店舗用ＣＡＴ端末５０や仮想店舗用サーバ６０からの決済要求を承認するための条件は、上述したように、(1) 決済要求に含まれるギフトＩＤが与信枠管理部１１０によって正規に発行されたギフトＩＤであること、(2) 有効なギフトＩＤであること、(3) 決済要求に含まれる決済金額が当該ギフトＩＤに対応する与信枠の範囲内であること、の３条件である。このような３条件が満足されているか否かを判定する最も簡単な方法は、与信枠管理部１１０に対する照会を行う方法である。このような照会に円滑に対処するために、与信枠管理部１１０内には、図２に示すような与信枠管理テーブル１１１を用意しておくようにするのが好ましい。

この与信枠管理テーブル１１１は、図示のとおり、与信ＩＤ，ギフトＩＤ，金額，有効情報なるデータを１レコードとして記録するテーブルであり、同一レコード中に記録された与信ＩＤ，ギフトＩＤ，金額，有効情報が互いに対応関係にあるデータであることを示している。図示の例では、与信ＩＤ「Ｙｂ３」，ギフトＩＤ「１２３４５」，金額「１万円」，有効情報「○（有効であることを示す）」なるデータが、与信枠管理テーブル１１１上の１レコードとして記録されている。このような１レコードの記録は、端末装置１０からの与信枠提供要求に基づいてなされたものである。

利用者Ｂの店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられた場合、決済要求承認部１２０は、与信枠管理部１１０内の与信枠管理テーブル１１１を参照することにより、当該決済要求を承認する条件が満足されるか否かを判定することができる。すなわち、与えられた決済要求に含まれていたギフトＩＤが与信枠管理テーブル１１１に存在し、有効であることを示す情報が記録されており、かつ、その与信枠の金額が決済金額以上であった場合に、当該決済要求を承認する条件が満足されているとの判定を行うことができる。

具体的には、図２に示す例の場合、決済要求承認部１２０には、「１２３４５」なるギフトＩＤと「１万円」なる決済金額とを含む決済要求が与えられることになる。そこで、第１の確認事項として、「１２３４５」なるギフトＩＤが、与信枠管理テーブル１１１内に存在するか否かを調べると、当該ギフトＩＤは確かに与信枠管理テーブル１１１内に存在することが確認できる。これにより、上記条件(1) 決済要求に含まれるギフトＩＤが与信枠管理部１１０によって正規に発行されたギフトＩＤであること、が満足されていることが確認できる。前述したとおり、実用上は、ギフトＩＤとして、数字と文字を含むより複雑なコードが用いられるので、利用者Ｂ側から与えられたギフトＩＤが、与信枠管理テーブル１１１内のギフトＩＤと一致した場合、当該ギフトＩＤが正規に発行されたギフトＩＤであるとの判断を行っても実用上は問題ない。

このギフトＩＤの一致により、与信枠管理テーブル１１１上の１レコードが特定されることになるので、以下の確認処理は、この特定された１レコード内のデータを用いて実行される。すなわち、第２の確認事項として、当該レコード内の有効情報が「○」を示しているかが確認される。これにより、上記条件(2) 有効なギフトＩＤであること、が満足されていることが確認できる。このように、個々のギフトＩＤごとに、有効／無効を設定できるようにしているのは、後述するように、同一のギフトＩＤが重複して利用されることを防ぐためである。

そして最後に、第３の確認事項として、当該レコードの金額（与信枠の金額）が、決済金額以上であるか否かが確認される。図示の例の場合、与信枠管理テーブル１１１上の金額は「１万円」となっており、決済要求に含まれていた決済金額「１万円」に一致することが確認できる。これにより、上記条件(3) 決済要求に含まれる決済金額が当該ギフトＩＤに対応する与信枠の範囲内であること、が満足されていることが確認される。もちろん、決済金額が「８千円」のように、与信枠管理テーブル１１１に記録されている与信枠の金額よりも少なかったとしても（つまり、利用者Ｂが、プレゼントされた金額よりも安い商品を選択した場合にも）、条件満足との判断がなされる。

このように、与信枠管理部１１０内に与信枠管理テーブル１１１を設けておくようにすれば、上記３条件が満足されているか否かを容易に判断することが可能になる。

以上のようにして、決済要求承認部１２０により、決済要求が承認されると、既に述べたとおり、決済処理部１３０による決済処理が実行されることになるが、与信枠管理テーブル１１１は、この決済処理にも利用することができる。すなわち、決済要求承認部１２０は、決済要求を承認した場合、実店舗用ＣＡＴ端末５０あるいは仮想店舗用サーバ６０に対して、承認する旨の回答を行うとともに、決済処理部１３０に対して、当該決済要求が承認された旨を報知する。決済処理部１３０は、これを受けて、決済サーバ２００に対する決済処理を行うことになるが、このとき、与信枠管理テーブル１１１を参照することにより、ギフトＩＤ「１２３４５」に対応する与信ＩＤ「Ｙｂ３」を認識することができるので、この与信ＩＤ「Ｙｂ３」と決済金額「１万円」を決済サーバ２００に送信して、決済処理を行うことができる。

こうして、決済処理部１３０による決済が行われると、与信枠管理部１１０は、当該決済済みの与信ＩＤに対応するギフトＩＤが無効であることを示す情報を、与信枠管理テーブル１１１に記録する処理を行う。図示の例の場合、ギフトＩＤ「１２３４５」についての有効情報が「×（無効であることを示す）」に書き換えられることになる。これは、前述したとおり、同一のギフトＩＤが重複して利用されることを防ぐための措置である。すなわち、利用者Ｂが、ギフトＩＤ「１２３４５」を用いて「１万円」の買い物を実行した後は、与信枠管理テーブル１１１内の記録上、当該ギフトＩＤ「１２３４５」は無効化されることになるので、以後、同じギフトＩＤ「１２３４５」を用いて買い物を試みても、決済要求承認部１２０による承認は得られないことになる。

続いて、この与信枠管理テーブル１１１を利用した実施形態について、利用者Ａから利用者Ｂにプレゼントが行われる手順の流れを、図３の流れ図を用いて説明する。

まず、ステップＳ１において、利用者Ａによる与信枠提供要求がなされる。具体的には、利用者Ａは、パソコンや携帯電話などのＷｅｂブラウザ機能を有する端末装置１０を用いて、与信枠管理部１１０が提供する所定のＷｅｂページへアクセスし、当該Ｗｅｂページ上で必要な情報を入力して、所定金額の与信枠を利用者Ｂへ提供したい旨の要求を行えばよい。この与信枠提供要求には、少なくとも、利用者Ａのクレジットアカウントを用いた決済に必要な決済情報（たとえば、クレジットカード番号と有効年月）と、金額情報（たとえば、１万円）と、提供先情報（たとえば、利用者Ｂの住所、氏名、電話番号、電子メールアドレスなど）と、が含まれている必要がある。

このような与信枠提供要求を受けた与信枠管理部１１０は、ステップＳ２において、与信ＩＤを取得する処理を実行する。すなわち、与信枠提供要求に含まれていた決済情報と金額情報とを決済サーバ２００へ送信し、与信枠の承認申請を行う。決済サーバ２００は、この承認申請を受けて、利用者Ａのアカウントに、申請金額分の与信枠（この例では、１万円）を確保し、これに対応する与信ＩＤ（この例では、「Ｙｂ３」）を返信する。なお、利用者Ａのアカウントの現時点での与信枠の残額が不足していたなどの理由により、与信ＩＤが返信されなかった場合、その旨が利用者Ａに通知され、処理はここで中断する（図３では、この場合のステップは省略）。

こうして、与信ＩＤを取得した与信枠管理部１１０は、ステップＳ３において、当該与信ＩＤに対応するギフトＩＤを発行し、これを提供先となる利用者Ｂ宛に電子メールにより送付する（必要に応じて、この電子メールには、贈り主としての利用者Ａを示す情報や、贈呈金額を示す情報が盛り込まれる）。

更に、与信枠管理部１１０は、発行したギフトＩＤと、これに対応する与信ＩＤおよびその与信枠の金額と、当該ギフトＩＤが有効であることを示す情報とを、与信枠管理テーブル１１１に記録する処理を行う。具体的には、たとえば、図２の与信枠管理テーブル１１１に示されているような情報がそれぞれ記録されることになる。以上で、利用者Ａによる与信枠振替処理は完了である。

一方、ギフトＩＤの通知を受けた利用者Ｂは、ステップＳ４において、実店舗もしくは仮想店舗の利用を行う。その結果、ステップＳ５において、実店舗用ＣＡＴ端末５０あるいは仮想店舗用サーバ６０から、決済要求承認部１２０に対する決済要求が行われる。この決済要求には、ギフトＩＤと決済金額とが含まれている。続いて、決済要求承認部１２０において、この決済要求を承認する処理が行われる。承認するか否かの判断は、前述したとおり、与信枠管理テーブル１１１を参照することにより行われる。なお、決済要求が承認されなかった場合には、利用者Ｂにその旨が通知され、処理はここで中断する（図３では、この場合のステップは省略）。

こうして、承認が行われると、最後のステップＳ７において、決済処理部１３０による決済処理が実行される。すなわち、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額とが、決済サーバ２００へ送信され、利用者Ａのクレジットアカウントを用いた決済が行われる。また、与信枠管理部１１０により、当該ギフトＩＤを無効化する処理が実行される。具体的には、与信枠管理テーブル１１１に対して、当該ギフトＩＤが無効であることを示す情報が書き込まれる。

＜＜＜ §４．ギフトＩＤに有効期限を設定する変形例 ＞＞＞
続いて、本発明のいくつかの変形例を述べる。ここでは、利用者Ｂに提供されたギフトＩＤについて、有効期限を設定する変形例を説明する。

既に述べたとおり、電子メールによってギフトＩＤの通知を受けた利用者Ｂは、自分の都合に合わせて、実店舗に出向いて買い物をしたり、仮想店舗で買い物をしたりすることができる。したがって、ギフトＩＤが店舗で利用される時期は、利用者Ｂの都合によって決定される事項であり、利用者Ａが関与すべき事項ではない。しかしながら、利用者Ｂに対してギフトＩＤが発行されると、当然、利用者Ａのアカウントに所定の与信枠が確保されることになり、利用者Ｂが当該ギフトＩＤを用いた買い物を行わない限り、当該与信枠は、決済されずに残ってしまう。そのような中途半端な状態が長期間続くことは、事務処理上好ましくなく、また、利用者Ａにとっても不本意な状況と言える。

このような事態を防ぐために、実用上は、ギフトＩＤに有効期限を設定できるようにするのが好ましい。具体的には、与信枠管理部１１０が、発行した個々のギフトＩＤについてそれぞれ有効期限を設定できるようにし、利用者ＢにこのギフトＩＤを発送する際に、この有効期限を示す情報も併せて発送すればよい。そして、与信枠管理部１１０により、常に期限管理を行うようにし、有効期限が経過したギフトＩＤについては、無効化する処理を実行するようにする。

§３で述べた実施形態では、図２の与信枠管理部１１０のブロック内に示すような与信枠管理テーブル１１１を用いた管理を行った。図４は、この与信枠管理テーブル１１１のより実用的な例を示す図である。このテーブルでは、１レコードを構成する１行のデータは、日付、提供元、提供先、決済情報、与信ＩＤ、ギフトＩＤ、金額、有効期限、有効情報なる各データによって構成されている。ここでは、このテーブルの１行目に記録されたレコードの具体的なデータに基づいて、個々のデータの意味を説明する。

まず、日付欄の「２００５／０１／１５」は、与信枠管理部１１０によるギフトＩＤの発行処理が行われた日付を示すものである。続く、提供元欄の「Ａ」および提供先欄の「Ｂ」は、当該ギフトＩＤ（与信枠）の提供者、すなわち、贈り主が利用者Ａであることを示し、受取人が利用者Ｂであることを示している。そして、決済情報欄には、端末装置１０から送信されてきた利用者Ａのクレジットカードのカード番号および有効年月が記録される。また、与信ＩＤ欄の「Ｙｂ３」は、決済サーバ２００から通知された与信ＩＤであり、ギフトＩＤ欄の「１２３４５」は、この与信ＩＤ「Ｙｂ３」に対応して与信枠管理部１１０が発行したギフトＩＤであり、金額欄の「１万円」は、利用者Ａにより指定された提供対象与信枠の金額である。その次の有効期限欄の「２００５／０３／３１」が、この§４で述べる実施形態に特有のギフトＩＤの有効期限を示す情報であり、最後の有効欄の「○」は、当該ギフトＩＤが現時点で有効であることを示す情報である。

与信枠管理部１１０内に、図４に示すような与信枠管理テーブル１１１を用意しておけば、個々のギフトＩＤごとに、それぞれ有効期限を管理することが可能になる。有効期限は、利用者Ａにその都度入力させて設定するようにしてもよいが、たとえば、「ギフトＩＤ発行日から１ヶ月」のような取り決めをしておき、自動的に設定できるようにしてもかまわない。ただ、実用上は、月末の日付など、区切りのよい期日を有効期限の満了日に設定するのが好ましいので、利用者Ａに対して、たとえば、２月末、３月末、４月末というような月末の日付を提示し、その中から選択された期日を有効期限として設定するとか、あるいは、「ギフトＩＤ発行日が属する月の翌々月の末日」のような取り決めで、自動的に設定できるようにするのが好ましい。

このような有効期限を設定した場合、利用者Ｂに対して電子メールでギフトＩＤを発送する際には、この有効期限の情報も併せて送付するようにし、たとえば、「このギフトＩＤの有効期限は、２００５年３月３１日です。必ず、有効期限内にご利用ください。」のような文面により、有効期限の存在を認識させる必要がある。これにより、利用者Ｂに、有効期限内の利用を促すことができる。

一方、与信枠管理部１１０には、毎日、与信枠管理テーブル１１１上の有効期限をチェックする機能をもたせておき、有効期限が経過したギフトＩＤについては、有効欄を「×」に書き換えて、無効化する処理が行われるようにしておく。これにより、利用者Ｂが、有効期限後にギフトＩＤを利用した決済を行おうとした場合、決済要求承認部１２０によって、当該決済要求は拒絶されることになる。

なお、与信枠管理部１１０は、有効期限切れによりギフトＩＤを無効化した場合、その旨を決済サーバ２００に報告し、当該ギフトＩＤに対応する与信ＩＤの与信枠をキャンセルする処理が行われるようにし、また、その旨を利用者Ａに報告する処理が行われるようにするのが好ましい。

＜＜＜ §５．残高管理を行う変形例 ＞＞＞
これまで述べた実施形態では、利用者Ａから利用者Ｂに、たとえば１万円の与信枠のプレゼントが行われた場合、利用者Ｂが、ギフトＩＤを利用して１万円相当の商品を引き換える、という形態を前提としていた。このような形態は、結婚式の引き出物の進呈、香典返し、粗品の進呈、といったケースで広く利用可能な形態であるが、子供や孫などに「お小遣い」をプレゼントする、といったケースでは、若干、利用勝手が悪い。たとえば、孫に３万円分の小遣いをプレゼントする場合、商品券やギフトカードを３万円分プレゼントすれば、受取人は、現金３万円をもらったのと同じ形態で、これを利用することができるが、前述した実施形態に係る本発明のシステムでは、３万円相当の商品を購入せざるを得なくなる。

そこで、この§５では、本発明に係る与信枠振替システムにおいても、商品券やギフトカードと同様の利用勝手を受取人に与えることができるようにする工夫を述べる。そのためには、利用者Ａから利用者Ｂに提供された与信枠の金額に関して、残高管理を行うようにすればよい。

図５は、個々のギフトＩＤごとに、利用額の管理を行うための利用額管理テーブル１１２の一例を示す図である。図示の例は、図４の与信枠管理テーブル１１１の２行目に記録されているギフトＩＤ「６７８９０」についての利用額を管理するためのテーブルである。図４に示されているとおり、ギフトＩＤ「６７８９０」は、利用者Ｃから利用者Ｄに対してプレゼントされた３万円分の与信枠についてのものであり、有効期限は２００５年３月３１日に設定されている。

ここに示す変形例では、受取人である利用者Ｄは、この有効期限内に、合計３万円になるまで、何回でもギフトＩＤ「６７８９０」を利用して買い物を行うことができる。利用者Ｄが、ギフトＩＤ「６７８９０」を利用して買い物を行うたびに、与信枠管理部１１０内に設けられた図５に示すような利用額管理テーブル１１２に、利用額の履歴が記録されてゆくことになり、利用額の合計が積算されてゆく。図５に示す例では、利用者Ｄが、これまでにギフトＩＤ「６７８９０」を３回利用した履歴が記録されており、利用額合計が２５０００円に達した時点の状態が示されている。このような利用額管理テーブル１１２を利用すれば、各ギフトＩＤについての残高管理を行うことができるようになるので、利用者Ｄは、残高の範囲内で、何度でも同一ギフトＩＤを利用した買い物ができる。

このような残高管理を行うには、まず、与信枠管理部１１０に、個々のギフトＩＤごとに、利用額の履歴を管理する利用額管理テーブルを記録する機能をもたせておく。前掲の実施形態で述べたように、利用者ＤがギフトＩＤ「６７８９０」を利用して買い物を行うと、決済要求承認部１２０に対して決済要求が出されることになる。このとき、決済要求承認部１２０は、与信枠管理部１１０内の与信枠管理テーブル１１１を参照することにより、当該決済要求を承認するか否かの判定を行うことになるが、このとき、与信枠管理部１１０の内部で、図５に示すような利用額管理テーブル１１２を更新し、ギフトＩＤ「６７８９０」に関する利用額の履歴が逐次記録されるようにしておく。

そして、決済要求を承認するか否かの判定は、この利用額管理テーブル１１２の利用額の合計を参照して行うようにする。すなわち、利用者Ｄの店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、与えられた決済要求に含まれていたギフトＩＤが与信枠管理テーブル１１１に存在し、かつ、その与信枠の金額から利用額管理テーブル１１２に記録されている利用額の合計を差し引いた残額が、決済金額以上であった場合に、当該決済要求を承認するようにすればよい。

たとえば、ギフトＩＤ「６７８９０」についての過去の利用履歴が、図５の利用額管理テーブル１１２に示すような状態である場合に、利用者Ｄが、ギフトＩＤ「６７８９０」を用いて、更に所定金額の買い物を試みたとしよう。この場合、利用額管理テーブル１１２に記録されている利用額の合計は２５０００円であり、与信枠管理テーブル１１１に記録されている与信枠の金額は３００００円であるから、残額は５０００円であることが認識される。したがって、決済要求承認部１２０は、決済金額が５０００円以下であれば、これを承認することになるが、５０００円を超えていた場合には、拒絶することになる。

このような運用を行えば、利用者Ｄは、利用者Ｃからプレゼントされた合計３万円の与信枠の範囲内で、何度でも所望の商品を買うことができる。なお、利用額管理テーブル１１２の内容は、必要があれば、利用者Ｄに対して、電子メールなどを利用して報知するのが好ましい。

ところで、上述のような運用を採る場合、決済処理部１３０による決済処理のタイミングが問題になる。すなわち、上述の例の場合、利用者Ｃが合計３万円の与信枠を設定して、利用者Ｄにプレゼントした時点で、決済サーバ２００内の利用者Ｃのアカウントには、与信ＩＤ「Ｙｄ４」に対応する３万円分の与信枠が確保されることになるので、決済処理部１３０は、この与信枠に対して、何らかのタイミングで決済処理を行わねばならない（利用者Ｄが個々の買い物をするたびに、実店舗用ＣＡＴ端末５０や仮想店舗用サーバ６０から決済要求が出され、決済要求承認部１２０による承認がなされるが、この承認は、クレジットカードのアカウントに対する正式な決済ではなく、あくまでも与信枠振替システム１００による便宜的な代行決済というべきものであり、決済サーバ２００に対する正式な決済処理は、決済処理部１３０によって行う必要がある）。

そこで、実用上は、所定のギフトＩＤについて、予め定めた所定の決済開始条件が満足されたとき、当該ギフトＩＤについて利用額管理テーブル１１２に記録されている利用額の合計と、当該ギフトＩＤに対応する与信ＩＤとを、決済サーバ２００へ送信し、利用者Ｃのクレジットアカウントを用いた決済処理を行う機能を、決済処理部１３０にもたせておくようにすればよい。

決済開始条件としては、たとえば、「ギフトＩＤについての利用額の合計が、当該ギフトＩＤについて最初に設定された与信枠に等しくなること」という条件を設定しておくことができる。上述したギフトＩＤ「６７８９０」の場合、最初に設定された与信枠は３万円であるので、利用額管理テーブル１１２に記録された利用額の合計が３万円に等しくなった時点で、上記決済開始条件が満足されたものと判断され、決済処理部１３０による決済処理が実行されることになる。すなわち、決済処理部１３０から決済サーバ２００に対して、与信ＩＤ「Ｙｄ４」（ギフトＩＤ「６７８９０」に対応する与信ＩＤ）と、決済金額３万円とが通知され、与信ＩＤ「Ｙｄ４」に対応する与信枠の決済が完了する。

しかしながら、利用者Ｄが、プレゼントされた与信枠の金額を、必ずしも全額使い切るとは限らない。たとえば、図５に示すような利用履歴の状態において、利用者Ｄが、ギフトＩＤ「６７８９０」を用いて、更に４９８０円の買い物をした場合を考えよう。この場合、利用額の合計は、２９９８０円となるので、残額が２０円の状態になる。このようなケースでは、利用者Ｄが、更に２０円の買い物を行って、プレゼントされた３万円の与信枠を全額使い切る可能性は極めて低くなる。通常、利用者Ｄは、残額２０円の利用を断念し、そのまま放置することになろう。

このようなケースに対処するためには、§４の変形例で述べたように、個々のギフトＩＤに有効期限を設定しておくようにし、設定された有効期限が経過した時点で、決済開始条件が満足されたものとするのが好ましい。上述のギフトＩＤ「６７８９０」については、図４の与信枠管理テーブル１１１に示されているとおり、２００５年３月３１日が有効期限となっているので、利用額の合計が２９９８０円のままであっても、当該有効期限が到達した時点で、上記決済開始条件が満足されたものと判断され、決済処理部１３０による決済処理が実行されることになる。この場合、決済処理部１３０から決済サーバ２００に対して、与信ＩＤ「Ｙｄ４」（ギフトＩＤ「６７８９０」に対応する与信ＩＤ）と、決済金額２９９８０円とが通知され、与信ＩＤ「Ｙｄ４」に対応する与信枠の決済が完了する。もともと設定された与信枠は３万円であるが、決済額は２９９８０円であるため、利用者Ｃの銀行口座からは、決済額２９９８０円が引き落とされることになる。

なお、こうして決済処理部１３０によって、特定のギフトＩＤに関する決済処理が行われた場合、与信枠管理部１１０が、当該決済済みの与信ＩＤに対応するギフトＩＤが無効であることを示す情報を与信枠管理テーブル１１１に記録する処理を行うようにするのが好ましい。

＜＜＜ §６．ギフトＩＤの通知方法の変形例 ＞＞＞
これまで述べた実施形態では、与信枠管理部１１０から利用者Ｂに対するギフトＩＤの通知を、電子メールを利用して行っていた。すなわち、利用者Ａが、与信枠管理部１１０に対して与信枠提供要求を行う際に、提供先情報として利用者Ｂの電子メールアドレスを入力してもらうようにし、当該電子メールアドレス宛に、ギフトＩＤの発送を行っていた。

しかしながら、本発明を実施する上で、受取人に対するギフトＩＤの発送処理は、必ずしも電子メールを利用して行う必要はない。たとえば、利用者Ａが、与信枠管理部１１０に対して与信枠提供要求を行う際に、提供先情報として利用者Ｂの住所や電話番号を入力してもらうようにすれば、ギフトＩＤの発送を郵便やファクシミリによって行うことも可能である。

ギフトＩＤの発送を郵送で行う場合には、与信枠管理部１１０に、提供先情報として与えられた利用者Ｂの住所に基づいて、当該住所とギフトＩＤとを郵便物上に印刷する機能をもたせておけばよい。また、ギフトＩＤの発送をファクシミリを利用して行う場合には、与信枠管理部１１０に、提供先情報として与えられた利用者Ｂの電話番号に基づいて、ギフトＩＤをファクシミリによって発送する機能をもたせておけばよい。なお、あまり実用的ではないが、電話による音声で、利用者ＢにギフトＩＤを伝えることも可能である。

利用者Ｂは、郵便物やファクシミリなどの形態でギフトＩＤを受け取った場合、これを店舗で手入力すればよい。たとえば、実店舗で利用する場合であれば、実店舗用ＣＡＴ端末５０のキーを操作することにより、ギフトＩＤを入力することができる。また、仮想店舗で利用する場合であれば、パソコンや携帯電話などの端末装置２０に対して、ギフトＩＤを手入力した上で、これを仮想店舗用サーバ６０に送信することができる。

また、郵便物やファクシミリを利用してギフトＩＤを発送する場合に、ギフトＩＤをバーコードや二次元コードの形態にしておけば、手入力を行う代わりに、光学的な読取手段を利用して入力することが可能になる。

もちろん、ギフトＩＤを受け取った利用者Ｂは、これを更に第三者に譲渡することも可能である。たとえば、ギフトＩＤ「１２３４５」を受け取った利用者Ｂが、その利用権を知人ＢＢに譲渡したいと考えた場合には、このギフトＩＤ「１２３４５」を当該知人ＢＢに通知すればよい。決済要求承認部１２０は、与えられたギフトＩＤが正規かつ有効なものであり、与えられた決済金額が与信枠内のものであれば、当該決済要求を承認するので、ギフトＩＤ「１２３４５」の利用者が、利用者Ｂ本人であっても、その知人ＢＢであっても、決済要求は承認されることになる。

＜＜＜ §７．ギフトＩＤをＩＣカードに格納する変形例 ＞＞＞
上述したとおり、ギフトＩＤは、電子メール、郵便、ファクシミリなど、様々な方法で利用者Ｂ宛に発送することができるが、これらの方法は、いずれもセキュリティの観点からは、必ずしも十分ではない。電子メール、郵便物、ファクシミリ出力紙などが盗み見られてしまうと、ギフトＩＤを不正利用した買い物が行われる可能性がある。このような不正利用を防止し、十分なセキュリティを確保する上では、ギフトＩＤを、利用者Ｂが保有するＩＣカードに格納するようにするのが好ましい。

ＩＣカードは、年々小型化が進んでおり、現在では、携帯電話に装着可能な小型タイプのものまで普及している。そこで、利用者Ｂが、このようなＩＣカードが装着された携帯電話などを端末装置２０として用いているのであれば、与信枠管理部１１０から発送されたギフトＩＤを、このＩＣカード内に格納することができる。ＩＣカードは、内部において、暗号化や復号化の処理を実行する機能を有しているので、与信枠管理部１１０からギフトＩＤを発送する際に暗号化し、端末装置２０（たとえば、携帯電話）を介して受信したＩＣカードの内部で、これを復号化して格納するようにすれば、ギフトＩＤを発送するプロセスにおけるセキュリティ確保を行うことができる。また、ＩＣカード内に格納された情報は、不正な方法での読出しが極めて困難であるため、格納中のギフトＩＤについても高度なセキュリティが確保される。

このように、ＩＣカードに格納されたギフトＩＤを利用して店舗で買い物を行う際には、格納されていたギフトＩＤを読み出して、実店舗用ＣＡＴ端末５０あるいは仮想店舗用サーバ６０側に引き渡す必要がある。したがって、実用上は、端末装置２０（たとえば、携帯電話）側に、専用のアプリケーションプログラムをインストールしておき、与信枠管理部１１０から発送されたギフトＩＤをＩＣカードに格納する処理と、格納されていたギフトＩＤをＩＣカードから読み出して、実店舗用ＣＡＴ端末５０や仮想店舗用サーバ６０へ引き渡す処理とを、このアプリケーションプログラムを用いて実行できるようにしておけばよい。

ギフトＩＤの格納場所としてＩＣカードを用いると、更に別なメリットが得られる。すなわち、ＩＣカードは、十分なセキュリティが確保された環境下において、内部で演算処理を行う機能を有しているため、決済要求承認部１２０による判定（決済要求に対する承認を行うか否かの判定）処理を代行することが可能である。

たとえば、§３で述べた実施形態の場合、決済要求承認部１２０は、実店舗用ＣＡＴ端末５０や仮想店舗用サーバ６０からの決済要求を受けたときに、与信枠管理部１１０内の与信枠管理テーブル１１１を参照して、(1) 決済要求に含まれるギフトＩＤが与信枠管理部１１０によって正規に発行されたギフトＩＤであること、(2) 有効なギフトＩＤであること、(3) 決済要求に含まれる決済金額が当該ギフトＩＤに対応する与信枠の範囲内であること、の３条件が満足されているか否かを確認する処理を行い、３条件すべてが満足されている場合に、当該決済要求を承認する。

ところが、ギフトＩＤの格納場所としてＩＣカードを用いるようにすると、上記３条件を確認するために、与信枠管理テーブル１１１を参照する処理を省略することが可能になる。

たとえば、与信枠管理部１１０からＩＣカードに対して、ギフトＩＤを発送する際に、当該ギフトＩＤに係る与信枠の金額を併せて発送するようにすれば、ＩＣカードの内部において、決済金額のチェック機能を働かせることが可能になる。すなわち、利用者Ｂの店舗利用に際して、格納中のギフトＩＤと、格納中の与信枠の金額の範囲内の所定の決済金額と、を含む決済要求を送出するようなプログラムをＩＣカード内に組み込んでおけば、与信枠を超えるような決済金額をもった決済要求がＩＣカードから出されることはない。別言すれば、このＩＣカードから出された決済要求に含まれている決済金額は、事前にＩＣカードの内部においてチェックされているため、常に、与信枠の範囲内のものということになる。したがって、決済要求承認部１２０側では、上述した「(3) 決済要求に含まれる決済金額が当該ギフトＩＤに対応する与信枠の範囲内であること」という条件が満たされていることを確認するために、与信枠管理テーブル１１１を参照する必要はなくなる。

また、ＩＣカード内に、１つのギフトＩＤについての決済要求の承認が行われた場合に、承認された当該ギフトＩＤを無効化する処理プログラムを用意しておけば、ギフトＩＤを用いた買い物を１回行うと、当該ギフトＩＤがＩＣカード内部で無効化されてしまうため、同一のギフトＩＤを重複利用することはできなくなる。別言すれば、個々のギフトＩＤの有効／無効の情報を、ＩＣカードの内部で記録して管理することができる。したがって、与信枠管理部１１０側では、個々のギフトＩＤについて、有効／無効の管理を行う必要はなくなる。当然、決済要求承認部１２０側でも、上述した「(2) 有効なギフトＩＤであること」という条件が満たされていることを確認するために、与信枠管理テーブル１１１を参照する必要はなくなる。ＩＣカードから送出されたギフトＩＤは、常に、有効なものとして取り扱うことができるからである。

同様に、決済要求承認部１２０側では、上述した「(1) 決済要求に含まれるギフトＩＤが与信枠管理部１１０によって正規に発行されたギフトＩＤであること」という条件が満たされていることを確認するために、与信枠管理テーブル１１１を参照する必要はなくなる。ＩＣカードから送出されたギフトＩＤは、常に、与信枠管理部１１０によって正規に発行されたギフトＩＤであるものとして取り扱うことができるからである。

結局、決済要求承認部１２０としては、ＩＣカードからの決済要求が与えられた場合、当該ＩＣカードが正規のものであるか否かを認証する処理を行い、正規のものであるとの認証が得られた場合には、当該決済要求をそのまま承認すれば足りる。これは、当該ＩＣカードが正規のものである以上、当該ＩＣカードから出された決済要求に含まれるギフトＩＤが与信枠管理部１１０によって正規に発行されたギフトＩＤである（上記条件(1) ）と推定することができ、当該ギフトＩＤが有効なギフトＩＤである（上記条件(2) ）と推定することができ、決済要求に含まれる決済金額が当該ギフトＩＤに対応する与信枠の範囲内である（上記条件(3) ）と推定することができるからである。別言すれば、ＩＣカードが正規のものであることが認証できれば、上記３条件がいずれも満足されていると推定しても実用上の問題は生じないことになる。

なお、ＩＣカードが正規のものであるか否かの認証方法は、既に種々の方法が公知であるため、ここでは詳しい説明は省略する（たとえば、決済要求承認部１２０とＩＣカードとの間で、所定の暗号情報を取り交わすことにより、互いに相手を正規の装置として認証することが可能である）。なお、ＩＣカードは、端末装置２０に装着されて利用されるため、決済要求承認部１２０がＩＣカードを認証する際、実店舗用ＣＡＴ端末５０もしくは仮想店舗用サーバ６０と、端末装置２０を介してＩＣカードと交信する必要がある。

このように、ＩＣカードの処理機能を利用すれば、与信枠管理部１１０側で与信枠の金額を記録したり、ギフトＩＤの有効／無効を記録したりする必要がなくなるので、与信枠管理テーブル１１１自体を設ける必要がなくなる。なお、決済要求承認部１２０により、所定の決済要求に対する承認が行われたとき、決済処理部１３０は、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を決済サーバ２００へ送信して決済処理を行う必要があるが、与信ＩＤそのものをギフトＩＤとして用いるようにすれば、与信ＩＤとギフトＩＤとの対応関係を与信枠管理部１１０内に記録しておく必要もなくなる。

以上、§３で述べた実施形態に、ＩＣカードを適用した例であるが、§５で述べた残高管理を行う実施形態においても、ＩＣカードの適用により大きなメリットが得られる。すなわち、§５で述べた実施形態では、与信枠管理部１１０内に図５に示すような利用額管理テーブル１１２を用意して、１つのギフトＩＤについての利用額の履歴を記録し、残高を計算する処理を行っていたが、このような残高計算の処理をＩＣカードの内部において実行させるようにすれば、与信枠管理部１１０側に利用額管理テーブル１１２を設ける必要はなくなる。

具体的には、上述の例と同様に、与信枠管理部１１０からＩＣカードに対して、ギフトＩＤを発送する際に、当該ギフトＩＤに係る与信枠の金額を併せて発送するようにする。そして、ＩＣカードの内部において、決済金額のチェック機能を働かせるようにする。すなわち、ＩＣカードには、店舗利用に際して、格納中のギフトＩＤと、格納中の与信枠の金額の範囲内の所定の決済金額と、を含む決済要求を送出するプログラムを用意しておく。しかも、このプログラムでは、決済要求の承認が行われた際には、承認された決済金額を格納中の与信枠の金額から減ずる更新処理も行われるようにしておく。そうすれば、更新された与信枠（与信の残額）を超えるような決済金額をもった決済要求がＩＣカードから出されることはない。

たとえば、与信枠管理部１１０から、ギフトＩＤ「６７８９０」とともに「３万円」という与信枠の金額が発送され、ＩＣカードに格納されたものとしよう。ここで、利用者Ｂが、１万円の買い物を行う場合、ＩＣカード内部に用意されたプログラムによって、決済金額「１万円」が現在の与信枠の範囲内であることが確認された後、ギフトＩＤ「６７８９０」と決済金額「１万円」とを含む決済要求が出力されることになる。しかも、この決済金額「１万円」を、格納中の与信枠の金額「３万円」から減ずる処理が、ＩＣカード内部で実行され、格納中の与信枠の金額は「２万円」に更新されることになる。このように、買い物を行うたびに、与信枠の金額を更新してゆく処理をＩＣカードの内部で実行してゆくようにし、決済金額がその時点の与信枠の金額を超えるような場合には、そのような決済金額を含む決済要求が、ＩＣカード内部でキャンセルされるようにしておけば、ＩＣカードから決済要求が出された場合には、当該決済要求に含まれている決済金額は、常に、与信枠の残額範囲内ということになる。

このような機能をＩＣカード自身にもたせておけば、決済要求承認部１２０としては、ＩＣカードからの決済要求が与えられた場合、当該ＩＣカードが正規のものであるか否かを認証する処理を行い、正規のものであるとの認証が得られた場合には、当該決済要求をそのまま承認すれば足りる。当該ＩＣカードが正規のものである以上、当該ＩＣカードから出された決済要求は、必ず条件に合致したものであると推定することができるからである。

このように、ＩＣカードの処理機能を利用すれば、与信枠管理部１１０側に、与信枠管理テーブル１１１や利用額管理テーブル１１２を用意することなしに、§５で述べた実施形態と同等の運用を行うことができるようになる。

なお、ギフトＩＤをＩＣカードに格納するようにすれば、利用者ＡからギフトＩＤのプレゼントを受けた利用者Ｂが、更に、別な利用者Ｂ′に、このギフトＩＤをプレゼントするような利用形態も可能である。具体的には、ＩＣカード内に、ギフトＩＤおよびその時点での与信枠の金額を、別のＩＣカードに転送するプログラムを用意しておけばよい。この場合、利用者Ｂ′のＩＣカードへの転送が完了した時点で、利用者ＢのＩＣカード内のギフトＩＤについては無効化する処理が行われるようにしておけばよい。

現在実施されているクレジットアカウントの与信枠の管理方法の一例を示す模式図である。 本発明の基本的な実施形態に係るクレジットアカウントの与信枠振替システムの構成を示すブロック図である。 本発明に係る与信枠振替システムを用いて、利用者Ａから利用者Ｂにプレゼントが行われる手順の流れを示す流れ図である。 本発明に係る与信枠振替システムの与信枠管理部１１０で用いられる与信枠管理テーブル１１１の実用的な一例を示す図である。 図４に示す与信枠管理テーブル１１１とともに、与信枠管理部１１０で用いられる利用額管理テーブルの一例を示す図である。

符号の説明

１０…利用者Ａが用いる端末装置
２０…利用者Ｂが用いる端末装置
５０…実店舗用ＣＡＴ端末
６０…仮想店舗用サーバ
１００…与信枠振替システム
１１０…与信枠管理部
１１１…与信枠管理テーブル
１１２…利用額管理テーブル
１２０…決済要求承認部
１３０…決済処理部
２００…決済サーバ
Ｓ１〜Ｓ７…流れ図の各ステップ

Claims (16)

1. 所定のクレジットアカウントを有する第１の利用者が、前記クレジットアカウントの与信枠の一部を第２の利用者に提供し、前記第２の利用者が、提供された与信枠の範囲内で、前記第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするための与信枠振替システムであって、
   前記第１の利用者から端末装置を介して、前記クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる前記第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、前記決済情報および前記金額情報を、前記クレジットアカウントの決済サーバへ送信し、これに応じて前記決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤを前記提供先情報で特定される前記第２の利用者に発送する処理を行う与信枠管理部と、
   前記第２の利用者の店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、当該ギフトＩＤが前記与信枠管理部によって正規に発行された有効なギフトＩＤであり、かつ、当該決済金額が当該ギフトＩＤに対応する与信枠の範囲内であることを条件として、前記決済要求を承認する決済要求承認部と、
   前記決済要求承認部により、所定の決済要求に対する承認が行われたときに、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を前記決済サーバへ送信し、前記第１の利用者の前記クレジットアカウントを用いた決済が行われるようにする決済処理部と、
   を備えることを特徴とするクレジットアカウントの与信枠振替システム。
2. 所定のクレジットアカウントを有する第１の利用者が、前記クレジットアカウントの与信枠の一部を第２の利用者に提供し、前記第２の利用者が、提供された与信枠の範囲内で、前記第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするための与信枠振替システムであって、
   前記第１の利用者から端末装置を介して、前記クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる前記第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、前記決済情報および前記金額情報を、前記クレジットアカウントの決済サーバへ送信し、これに応じて前記決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤを前記提供先情報で特定される前記第２の利用者に発送するとともに、前記ギフトＩＤと、これに対応する与信ＩＤおよびその与信枠の金額と、前記ギフトＩＤが有効であることを示す情報とを、与信枠管理テーブルに記録する処理を行う与信枠管理部と、
   前記第２の利用者の店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、与えられた決済要求に含まれていたギフトＩＤが前記与信枠管理テーブルに存在し、有効であることを示す情報が記録されており、かつ、その与信枠の金額が前記決済金額以上であった場合に、前記決済要求を承認する決済要求承認部と、
   前記決済要求承認部により、所定の決済要求に対する承認が行われたときに、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を前記決済サーバへ送信し、前記第１の利用者の前記クレジットアカウントを用いた決済が行われるようにする決済処理部と、
   を備え、前記与信枠管理部が、前記決済処理部による決済が行われた際に、当該決済済みの与信ＩＤに対応するギフトＩＤが無効であることを示す情報を前記与信枠管理テーブルに記録することを特徴とするクレジットアカウントの与信枠振替システム。
3. 所定のクレジットアカウントを有する第１の利用者が、前記クレジットアカウントの与信枠の一部を第２の利用者に提供し、前記第２の利用者が、提供された与信枠の範囲内で、前記第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするための与信枠振替システムであって、
   前記第１の利用者から端末装置を介して、前記クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる前記第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、前記決済情報および前記金額情報を、前記クレジットアカウントの決済サーバへ送信し、これに応じて前記決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤを前記提供先情報で特定される前記第２の利用者に発送するとともに、前記ギフトＩＤと、これに対応する与信ＩＤおよびその与信枠の金額とを、与信枠管理テーブルに記録し、前記ギフトＩＤごとに、利用額の履歴を管理する利用額管理テーブルを記録する与信枠管理部と、
   前記第２の利用者の店舗利用に際して、所定のギフトＩＤと所定の決済金額とを含む決済要求が与えられたときに、与えられた決済要求に含まれていたギフトＩＤが前記与信枠管理テーブルに存在し、かつ、その与信枠の金額から前記利用額管理テーブルに記録されている利用額の合計を差し引いた残額が、前記決済金額以上であった場合に、前記決済要求を承認する決済要求承認部と、
   所定のギフトＩＤについて、予め定めた所定の決済開始条件が満足されたとき、当該ギフトＩＤについて前記利用額管理テーブルに記録されている利用額の合計と、当該ギフトＩＤに対応する与信ＩＤとを、前記決済サーバへ送信し、前記第１の利用者の前記クレジットアカウントを用いた決済が行われるようにする決済処理部と、
   を備えることを特徴とするクレジットアカウントの与信枠振替システム。
4. 請求項１〜３のいずれかに記載のシステムにおいて、
   与信枠管理部が、提供先情報として与えられた第２の利用者の電子メールアドレスに基づいて、ギフトＩＤを電子メールによって発送する機能を有することを特徴とするクレジットアカウントの与信枠振替システム。
5. 請求項１〜３のいずれかに記載のシステムにおいて、
   与信枠管理部が、提供先情報として与えられた第２の利用者の住所に基づいて、当該住所とギフトＩＤとを郵便物上に印刷する機能を有することを特徴とするクレジットアカウントの与信枠振替システム。
6. 請求項１〜３のいずれかに記載のシステムにおいて、
   与信枠管理部が、提供先情報として与えられた第２の利用者の電話番号に基づいて、ギフトＩＤをファクシミリによって発送する機能を有することを特徴とするクレジットアカウントの与信枠振替システム。
7. 請求項１〜６のいずれかに記載のシステムにおいて、
   与信枠管理部が、第２の利用者に対して、ギフトＩＤとともに与信枠の金額を示す情報を発送することを特徴とするクレジットアカウントの与信枠振替システム。
8. 所定のクレジットアカウントを有する第１の利用者が、前記クレジットアカウントの与信枠の一部を第２の利用者に提供し、前記第２の利用者が、提供された与信枠の範囲内で、前記第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするための与信枠振替システムであって、
   前記第１の利用者から端末装置を介して、前記クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる前記第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、前記決済情報および前記金額情報を、前記クレジットアカウントの決済サーバへ送信し、これに応じて前記決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤおよび前記与信枠の金額を前記提供先情報で特定される前記第２の利用者に発送する与信枠管理部と、
   前記与信枠管理部から発送された情報を格納し、前記第２の利用者の店舗利用に際して、格納中のギフトＩＤと、格納中の与信枠の金額の範囲内の所定の決済金額と、を含む決済要求を送出するＩＣカードと、
   前記ＩＣカードから前記決済要求が与えられたときに、前記ＩＣカードが正規のものであることを認証した後、前記決済要求を承認する決済要求承認部と、
   前記決済要求承認部により、所定の決済要求に対する承認が行われたときに、当該決済要求に係るギフトＩＤに対応する与信ＩＤと、当該決済要求に係る決済金額と、を前記決済サーバへ送信し、前記第１の利用者の前記クレジットアカウントを用いた決済が行われるようにする決済処理部と、
   を備え、前記ＩＣカードが、前記決済要求の承認が行われた際に、承認された当該ギフトＩＤを無効化することを特徴とするクレジットアカウントの与信枠振替システム。
9. 所定のクレジットアカウントを有する第１の利用者が、前記クレジットアカウントの与信枠の一部を第２の利用者に提供し、前記第２の利用者が、提供された与信枠の範囲内で、前記第１の利用者のクレジットアカウントを利用した決済を行うことができるようにするための与信枠振替システムであって、
   前記第１の利用者から端末装置を介して、前記クレジットアカウントによる決済に必要な決済情報と、提供対象となる与信枠の金額を示す金額情報と、提供先となる前記第２の利用者を特定する提供先情報と、を含む与信枠提供要求が与えられたときに、前記決済情報および前記金額情報を、前記クレジットアカウントの決済サーバへ送信し、これに応じて前記決済サーバから発行される与信ＩＤを受信し、受信した与信ＩＤに対応するギフトＩＤを発行し、発行したギフトＩＤおよび前記与信枠の金額を前記提供先情報で特定される前記第２の利用者に発送する与信枠管理部と、
   前記与信枠管理部から発送された情報を格納し、前記第２の利用者の店舗利用に際して、格納中のギフトＩＤと、格納中の与信枠の金額の範囲内の所定の決済金額と、を含む決済要求を送出する機能を有するＩＣカードと、
   前記ＩＣカードから前記決済要求が与えられたときに、前記ＩＣカードが正規のものであることを認証した後、前記決済要求を承認する決済要求承認部と、
   所定のギフトＩＤについて、予め定めた所定の決済開始条件が満足されたとき、当該ギフトＩＤについての利用額の合計と、当該ギフトＩＤに対応する与信ＩＤとを、前記決済サーバへ送信し、前記第１の利用者の前記クレジットアカウントを用いた決済が行われるようにする決済処理部と、
   を備え、前記ＩＣカードが、前記決済要求の承認が行われた際に、承認された決済金額を格納中の与信枠の金額から減ずる更新処理を行うことを特徴とするクレジットアカウントの与信枠振替システム。
10. 請求項１〜９のいずれかに記載のシステムにおいて、
    与信枠管理部が、第１の利用者を特定する提供元情報を含む与信枠提供要求が与えられたときに、第２の利用者に対して、ギフトＩＤとともに前記提供元情報を発送することを特徴とするクレジットアカウントの与信枠振替システム。
11. 請求項１〜１０のいずれかに記載のシステムにおいて、
    与信枠管理部が、個々のギフトＩＤについてそれぞれ有効期限を設定し、この有効期限を示す情報を第２の利用者に対して発送する機能を有し、与信枠管理部もしくはＩＣカードにおいて、有効期限が経過したギフトＩＤについて無効化する処理を行うことを特徴とするクレジットアカウントの与信枠振替システム。
12. 請求項３または９に記載のシステムにおいて、
    個々のギフトＩＤについての利用額の合計が、当該ギフトＩＤについて最初に設定された与信枠に等しくなったときに、決済開始条件が満足されたものとすることを特徴とするクレジットアカウントの与信枠振替システム。
13. 請求項３または９に記載のシステムにおいて、
    個々のギフトＩＤについて設定された所定の有効期限が経過した時点で、決済開始条件が満足されたものとすることを特徴とするクレジットアカウントの与信枠振替システム。
14. 請求項１〜１３のいずれかに記載のシステムにおいて、
    決済要求承認部が、インターネット上の仮想店舗サーバを介して決済要求を受け入れ、当該仮想店舗上での第２の利用者による決済を承認することを特徴とするクレジットアカウントの与信枠振替システム。
15. 請求項１〜１３のいずれかに記載のシステムにおいて、
    決済要求承認部が、実店舗に設置されたＣＡＴ端末を介して決済要求を受け入れ、当該実店舗上での第２の利用者による決済を承認することを特徴とするクレジットアカウントの与信枠振替システム。
16. 請求項１〜１５のいずれかに記載のシステムにおいて、
    決済処理部が、第１の利用者のクレジットアカウントを用いた決済が行われるようにする処理を実行したときに、当該決済が行われた旨を、第１の利用者宛に報告する機能を有することを特徴とするクレジットアカウントの与信枠振替システム。