JP2004030416A - 決済口座指定機能付クレジット取引用のサーバ - Google Patents

Abstract

【課題】取引毎に決済口座を任意に選択できるシステムのサーバを提供する。
【解決手段】ユーザ２毎に、主口座と付随口座とからなる決済口座情報が格納される格納場所と、その決済口座毎に口座名義人の連絡先情報が関連づけて格納される格納場所を有するデータベース１０を参照し、請求情報格納部においてユーザ２毎に格納され，かつ取引毎の決済口座が関連づけられた明細情報を、ユーザ２または付随口座名義人３の要求に応じて返信させる制御と、ユーザ２より決済口座を付随口座へ変更する通知を受けた場合、明細情報のうち、その取引の決済口座を付随口座に書き換させ、付随口座名義人が主口座名義人と異なる場合、付随口座名義人３に変更の通知を送信させる制御と、付随口座名義人３より付随口座からの決済を拒否する通知を受けた場合、明細情報のうち、その取引の決済口座を主口座に書き換えさせる制御を実行する制御部を有したサーバ１２である。
【選択図】　　　　図１

Description

【０００１】
【発明の属する技術分野】
この発明は、例えばクレジットカードを用いた取引などに代表されるクレジット取引（なお、本願におけるクレジット取引とは、後述する課題を解決しようとする手段の欄において定義する取引の意で用いる）の場面において、ユーザの支払いの便に供するために設置されるサーバに関する。
【０００２】
【従来の技術】
従来、例えばクレジットカードを用いて支払いをするとき、ユーザ（消費者）の実際の支払いは、クレジットカード会社（信用供与者）と取り決めた月日（例えば利用日翌月の１０日）に、あらかじめ指定してある決済口座（例えば銀行の普通預金口座）からクレジットカード会社への口座の自動振替によって行われる。
【０００３】
ここで、自動振替の行われる決済口座は、従来ユーザは１つしか指定できず、原則として、どのような取引でも、必ず指定した１の決済口座から請求額が引き落とされるものとなっている。
【０００４】
一方、ユーザ側からみると、取引に応じて決済口座を変えたいと希望する場面も多く想定されるものの、１つの信用供与会社の決済口座は１つしか指定できないため、それを実行するためには、多くの信用供与会社のクレジット会員となって、かつ各会社ごとに違う決済口座を指定しておき、取引ごとに例えばクレジットカードを使い分けるといった煩雑な作業が必要となる。すなわち、ユーザは複数の信用供与会社と会員契約を締結するとともに、取引毎に多数のクレジットカード等を持ち歩き、支払い時には、一々その用途を考えて、例えば多数のクレジットカードからその都度１枚のカードを選択して、支払い手続を行うということになる。
【０００５】
【発明が解決しようとする課題】
このような問題は、まずは、ユーザが信用供与会社との間で決済口座を複数指定できるようにすれば解決できるものであり、そして、複数口座が設定されるスキーム自体は、例えば特開２００２−３２５８１や特開２００２−８３１４５において提案されているので、それらを実際の取引に利用すればよいことになる。
【０００６】
しかし、特開２００２−３２５８１は、複数口座といっても、残高管理メイン口座と称する決済主口座の中に、円を外貨に換算して残高を蓄積した仮想通貨決済口座を設定するというものであり、その用途が、外貨でクレジット取引をしたような場合に限定されるので汎用性がなく、また仮想通貨決済口座のような特別の口座システムを口座保有会社（多くは銀行）が新たに設定する必要があることから、口座保有会社の負担が大きく、外貨決済が特に頻繁にある金融機関以外は他の用途のためにあえてこのようなシステムを導入する可能性が低いものとなっており、その点からも汎用性の低いシステムとなっている。しかも、仮想通貨決済口座において、円を外貨に換算して残高を蓄積しているので、常に為替リスクがともなうという問題もある。
【０００７】
一方、特開２００２−８３１４５は、１枚の決済用カードに複数のクレジットカード会社のクレジット機能をもたせたうえ、各クレジット機能毎に、複数の決済口座が指定できるというものであり、ユーザは１枚のクレジットカードを用いれば、その取引ごとに、自己の希望するクレジットカード会社（信用供与会社）のクレジット機能を選択し、またそのクレジットカート会社で指定した決済口座のうち希望する口座を選択して支払い手続ができることになるので、種々の取引に利用でき、また取引毎に希望する決済口座を選択できることになる。しかし、このシステムにおいては、ユーザは複数のクレジットカード会社と会員契約をしなければならず、ユーザにあっては、依然として煩雑な手続が強いられる。また、支払い時に、１枚のクレジットカードから、希望するクレジットカード会社のクレジット機能を選択するということは、サプライヤ（加盟店）のカード読取端末やシステムもその機能に対応させる必要があり、サプライヤにも負担を強いることになって、このシステムにあっても、汎用性が低いものとなっている。
【０００８】
そして、いずれのシステムでも、選択できる決済口座は、あくまで自己名義の複数決済口座の中からだけであり、名義が異なる決済口座からの選択は何ら想定されていないので、そのようなユーザからの要望（例えば、クレジットカード会員になれない家族のためにする支払いを、その家族名義の口座から決済したいような場合）にはまったく応えられないシステムとなっていた。
【０００９】
この発明は、従来技術の以上のような問題に鑑み創案されたもので、ユーザが取引毎に決済口座を任意に選択できるシステムを実現する技術であって、ユーザやサプライヤに何の負担も強いることなく、しかも利便性が良好で、あらゆるユーザのニーズにも応えられる、非常に汎用性の高い技術を提供しようとするものである。
【００１０】
【課題を解決しようとする手段】
本願では、クレジット取引用決済主口座とそれ以外の決済付随口座との選択を、インターネットなどの通信回線上のサーバを介して行わせようとするものであり、そのようなサーバを発明の対象としている。すなわち、この発明に係る決済口座指定機能付クレジット取引用のサーバは、少なくとも、各ユーザ毎に、クレジット取引用決済主口座とそれ以外の決済付随口座とからなる決済口座情報が格納される格納場所と、その決済口座毎にその口座名義人の連絡先情報が関連づけて格納される格納場所とが設定されるデータベースを参照しつつ、請求情報格納部において各ユーザ毎に格納されるクレジット取引の明細情報であって、取引毎に振り替えられる決済口座が関連づけられた明細情報の全部または一部を、ユーザまたは決済主口座の名義人と異なる決済付随口座の名義人の要求に応じて返信させる制御と、ユーザから、所定の取引についての決済口座を、決済主口座から決済付随口座へ変更する旨の通知を受けた場合、前記明細情報のうち、その取引の決済口座を、通知された決済付随口座に書き換させるとともに、その決済付随口座の名義人が、決済主口座の名義人と一致するかどうか判断し、異なると判断される場合、決済付随口座名義人に向けて、その口座から決済が行われる旨の通知を送信させる制御と、決済主口座の名義人と異なる決済付随口座の名義人から、所定の取引について決済付随口座からの振り替えを拒否する旨の通知を受けた場合、明細情報のうち、その取引の決済口座を決済主口座に書き換えさせる制御とを実行する制御部を有したことを特徴とする。
【００１１】
一般に、クレジット取引とは、単に個品割賦購入あっせんのことを指して用いる場合もあるが、本願においては、信用供与をともなう取引一般を指す広義の意味で用いるものとし、例えば個品割賦販売、クレジットカード取引、割賦販売、ローン提携販売等が含まれる。
【００１２】
通常、クレジット取引は、信用供与者から信用を供与されたユーザが、その信用を確認したサプライヤとの間で取引を行い、サプライヤは信用供与者から金銭支払いを受け、信用供与者はユーザから金銭支払いを受けるという形態をとる。そして、ユーザから信用供与者への金銭支払いは、上述のように、指定された期日に、ユーザがあらかじめ指定している決済口座から信用供与者の口座に振り替えられることで行われることが多いものであるが、本願では、その決済口座を複数設定するものとし、そのうちのメインとなるものを決済主口座、それ以外を決済付随口座として設定することを前提とする。なお、決済主口座と決済付随口座との口座名義人は、同一であっても、異なってもいずれでも良い。
【００１３】
ユーザから、この発明に係るサーバにアクセスがあり、自己の明細情報の要求があった場合、取引毎に振り替えられる決済口座が関連づけられた明細情報の一部または全部をそのユーザに返信させる。また、決済主口座の名義人と異なる決済付随口座の名義人からの要求に対しても、その決済付随口座名義人に同様に返信する。明細情報を閲覧したユーザから、所定取引の決済口座を、決済主口座から決済付随口座に変更する旨の通知があった場合、請求情報格納部内の前記明細情報のうち、その取引の決済口座を、通知された決済付随口座に書き換させるとともに、その決済付随口座の名義人が、決済主口座の名義人と一致するかどうか判断し、異なると判断される場合、決済付随口座名義人に向けて、その口座から決済が行われる旨の通知を送信させる。決済主口座名義人と決済付随口座名義人とが同一の場合であれば、ユーザの希望する変更内容で決済口座は確定する（ただし、その後再変更する場合は、最後に変更した内容で確定する）。一方、決済付随口座名義人が異なる場合には、前記変更の通知を受信したか、それとは別に明細情報を閲覧したかして、その決済付随口座の名義人は、所定の取引について自己の口座からの振り替えを許容するかどうか判断することになり、その結果、その名義人から決済付随口座からの振り替えを拒否する旨の通知を受けた場合、請求情報格納部内の明細情報のうち、その取引の決済口座を決済主口座に書き換えさせる。これらの制御において、アクセスのあったユーザ及び決済付随口座名義人の確認（アクセス権の確認含む）及び決済付随口座名義人への通知は、いずれも前記データベース内に格納された情報を参照して行われる。このような制御により、ユーザの取引毎の決済口座が、ユーザの自由な選択によって確定されるとともに、決済主口座名義人と決済付随口座名義人が異なる場合は、決済付随口座名義人の意思を含んだ内容で確定される。
【００１４】
また、クレジット取引においては、決済口座からの振り替え時期が、ユーザと信用供与者との間であらかじめ取り決められており、このため決済口座の変更もその時期以前に行う必要がある。このため、決済口座の変更に関する制御についても、所定期間内にのみ行うように設定するのが好ましい。
【００１５】
【発明の実施の形態】
本発明の具体的実施形態例を図面に基づき説明する。なお、以下の形態例は、クレジット取引がクレジットカード取引の場合であるが、これはあくまで一例に過ぎず、他のクレジット取引にももちろん適用が可能である。また、このクレジットカード取引の前提となる契約内容やシステムスキーム、あるいはシステム構成装置などもすべて一例であって、本発明が本形態例に限定されるものでないことは当然である。
【００１６】
まず、本形態例においては、ユーザである会員（以下単に会員という）が、信用供与者であるクレジットカード会社（以下単にカード会社という）と、あらかじめ決済口座を複数指定できるような取り決めを交わしていることを前提とする。
【００１７】
ここでは、会員のメインとなる決済主口座（以下単に主口座という）と、それ以外の決済付随口座（以下単に付随口座という）とを指定でき、主口座については会員名義であることを要するが、付随口座については他人名義でもよいものとする。付随口座が他人名義の場合、会員に対する責任を明確にするために、連帯債務契約とするのが好ましい。主口座及び付随口座のいずれも、金融機関の預金（あるいは貯金）口座などでよく、付随口座は複数指定してもよいものとする。
【００１８】
決済口座の選択は、後述するように、会員または付随口座名義人の希望により後に変更できるが、原則として当初は主口座に設定するものとし、ただし、当初から所定のサプライヤである加盟店（以下単に加盟店という）との取引については付随口座に設定するとする特約も可能とする。他人名義の場合、付随口座指定の際、その名義人から意思確認（署名・捺印や電子署名など）を行うとともに、電子メールアドレス等の連絡先を申請してもらう。各会員には、後述するサーバ１２にアクセスするためのＩＤとパスワードを付与し、付随口座が他人名義の場合はその名義人に別個のＩＤとパスワードを付与する。なお、ここでは付随口座の名義人に対しても登録審査を行う。
【００１９】
図１は本形態例が実施されるシステムの装置構成図であり、１はカード会社の処理センタ、２は会員が操作する端末、３は付随口座名義人が操作する端末、４はインターネット回線網を示している。
【００２０】
カード会社の処理センタ１には、会員データベース１０と、請求情報データベース１１と、サーバ１２が設けられ、相互にデータの授受が可能となっている。図示上、これらはハード的に別体となっているが、その態様に応じて適宜一体化させても良いし、また通信回線等を介してそれぞれ別の場所に存在する態様でも良い（その場合各ハードウエアがレンタルの態様でももちろん良い）。
【００２１】
会員データベース１０は、会員の登録情報が格納され、その中には、属性情報や会員の連絡先情報などのほか、主口座情報と付随口座情報とが含まれる。また付随口座が他人名義の場合はその名義人登録情報も格納され、その中には電子メールアドレスや電話番号、ＦＡＸ番号などの連絡先情報が含まれる。これら情報のうち、付随口座名義人の連絡先情報は付随口座情報に関連づけて格納されている。会員の連絡先情報も電子メールアドレスや電話番号、ＦＡＸ番号などであり、それらについても主口座情報に関連づけて格納させている。なお、会員が所定の加盟店取引については当初より付随口座で決済する旨の特約を交わしている場合、その加盟店情報についても格納する。
【００２２】
請求情報データベース１１は、会員の請求情報が格納されており、会員のクレジットカード取引の明細情報として、取引毎に振り替えられる決済口座が関連づけられている。
【００２３】
サーバ１２は、一般の演算処理制御手段としての機能の他、Ｗｅｂサーバとしての機能、メールサーバとしての機能を有しており、これらは機能ごとに単体で分離していてもよく、またその保有形式は上述のようにレンタルでも良い。また、前記会員データベース１０及び請求情報データベース１１の管理プログラムと協働して、次の制御が行われる。
【００２４】
すなわち、このサーバ１２のＣＰＵにおける制御部において、次の▲１▼〜▲３▼の制御が主として実行される。まず、▲１▼会員または付随口座名義人からアクセスがあり、その会員の明細情報の閲覧要求があった場合に、請求情報データベース１１内から該当する明細情報を取り出して返信する制御が実行される。ただし、本形態例では、会員への閲覧可能情報は、すべての取引に関する明細情報であるが、付随口座名義人への閲覧可能情報は、決済口座が付随口座として選択されている取引の明細情報のみとなっている。
【００２５】
次に、▲２▼会員からアクセスがあり、所定の取引についての決済口座を主口座から付随口座へ変更する旨の出力を受けた場合、請求情報データベース１１内の明細情報のうち、その取引の決済口座を、通知された付随口座に書き換させるとともに、その付随口座の名義人が、主口座の名義人と一致するかどうか判断し（本形態例では電子メールアドレスが登録されていれば異なると判断）、異なると判断される場合、付随口座名義人に向けて、その口座から決済が行われる旨の電子メールを送信させる制御が実行される。口座名義人が一致するかどうかは、前記会員データベース１０を参照して判断し、具体的には、主口座と付随口座との実際の名義が一致するどうかを確認する等種々の形態が考えられるが、本形態例では、付随口座の関連情報として、電子メールアドレスが登録されているかどうか（登録されていれば異なると判断）で判断する。
【００２６】
そして、▲３▼決済主口座の名義人と異なる決済付随口座の名義人からアクセスがあり、所定の取引について付随口座からの振り替えを拒否する旨の出力を受けた場合、明細情報のうち、その取引の決済口座を主口座に書き換えさせる制御が実行される。付随口座からの振り替えの拒否出力は、種々の態様が考えられるが、本形態例では付随口座から主口座への変更出力がそれに該当するものとしている。
【００２７】
これらの制御のうち、前記▲２▼及び▲３▼の制御は、所定期間内においてのみ実行するものとする。これは、クレジットカード取引においては、決済口座からの振り替え時期があらかじめ取り決められており、このため決済口座の変更もその時期以前に行う必要があるためである。この制御ステップの一例を、図２のフローチャートに示すが、この説明については後述する。
【００２８】
端末２，３は通信機能を備えた端末であって、インターネット４に接続できる環境にあり、前記サーバ１２からの情報を閲覧できるブラウザを備えていることを前提としている。なお、端末２は会員が操作するもの、端末３は付随口座名義人が操作するものとしてそれぞれ説明しているが、それは説明の便宜のためであり、要は、会員及び付随口座名義人が操作して前記サーバ１２との間で情報を授受できる装置構成であればどのようなものでよく、端末２を付随口座名義人が操作しても、端末３を会員が操作してももちろん良い。
【００２９】
次に、このシステムのおける流れをカード取引のあった時点から説明する。
【００３０】
他人名義の付随口座を指定して会員登録を受けた、ある会員がクレジットカードを用いていくつかの加盟店で取引をしたとする。例えば、取引はその時点で６回あったとする（それぞれ取引Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆとする）。また、取引Ａ，Ｅのあった加盟店については、会員があらかじめ当初決済口座を付随口座に指定しているとする。これらの取引の支払い手続は、会員が料金の支払い時、その加盟店においてクレジットカードを提示し、加盟店が決済端末でカード情報を読み取り、カード会社にその情報を送信してオーソリを受けた後、会員のカード支払いを了承して行われるものであり（多くはサインも求める）、ここまでは、加盟店側のハード及びシステムも含め従来と何ら異なることがない。
【００３１】
その後、会員が自己の明細情報を確認しようとして、端末２からインターネット４を介してサーバ１２にアクセスする。サーバ１２側では、会員情報データベース１０を参照して、会員のＩＤとパスワードからアクセス権を確認し、その会員の明細情報を返信する。これにより、会員の端末２には、例えば図３（ａ）に示すようなイメージで明細情報が表示される。図示の表示では、取引毎に支払額と決済口座とが表示される。決済口座の表示は、主口座と付随口座の双方とも丸いチェックボックスが並んで表示され、チェックボックスが反転して黒丸であれば、その段階における決済口座であることを示す。この例では、上述のように、当初決済口座を、取引ＡとＥを行った加盟店については付随口座に指定しているので、取引ＡとＥのみ付随口座のチェックボックスが黒丸に反転し、それ以外の取引Ｂ，Ｃ，Ｄ，Ｆは主口座のチェックボックスが黒丸に反転している。この明細情報の状態で、もし付随口座名義人が端末３からインターネット４を介してサーバ１０にアクセスしたとすると、その端末３には、図３（ｂ）に示すように、決済口座が付随口座に指定されている取引ＡとＥのみの明細情報が表示される（なお、このときサーバ１２が会員情報データベース１０を参照してアクセス権の確認をするのは同じ）。図示のように、決済口座の表示は会員の端末２と同様となっている。
【００３２】
会員が端末２から図３（ａ）の表示の明細情報を見た結果、例えば取引Ｂの決済口座を付随口座に変更したいと思った場合、図４（ａ）に示すように、その付随口座側の白丸チェックボックスをクリックして黒丸に反転させる。これにより、サーバ１２側にはその変更する旨の情報が送信される。この情報をサーバ１２側が受信することにより、その制御部において図２に示すような制御がなされる。まず、その情報の送信が前記指定期間内かどうかを判断し（Ｓ１）、指定期間内であれば、会員情報データベース１０を参照して、付随口座情報に電子メールアドレスが関連づけて格納されているかどうかを確認する（Ｓ２）。そのアドレスが格納されていれば、付随口座名義人が会員とは別人であるとこのシステムでは一応判断しているので、そのアドレスあてに、取引Ｂの決済口座が主口座から付随口座に変更になった旨電子メールを送信する（Ｓ３）。同時に、請求情報データベース１１に格納された当該明細情報におけるＢ取引の決済口座を、主口座から付随口座とする書き換えを暫定的に行う。なお、Ｓ１において、会員からの送信が指定期間経過後である場合は、変更情報を無視し、端末２，３上の表示も変更前の状態（図３）に戻す。また、Ｓ２において、付随口座に電子メールアドレスが関連づけられていなければ、指定期間経過後、請求情報データベース１１内の明細情報における決済口座を付随口座に書き換える（Ｓ７）。
【００３３】
一方、電子メールを受領した付随口座名義人が、インターネット４を介してサーバ１２にアクセスすると、アクセス権が確認された後、端末３には、図４（ｂ）に示すように、取引Ｂの情報が追加された明細情報が表示される。
【００３４】
この明細情報を見て、取引Ｂの決済口座を付随口座に変更したことについて、付随口座名義人はそれを認めるか、拒否するかを選択でき、変更を認める場合はそのままにし、変更を拒否する場合は、会員が端末２で操作したと反対に、主口座側の白丸クリックボックスをクリックして黒丸に反転させる。このクリック操作があるとサーバ１２側には再変更する旨の情報が送信されるが、この送信があるか否かについてもサーバ１２側では制御判断事項としている（Ｓ４）。その送信があった場合、それが指定期間内かどうか判断し（Ｓ５）、指定期間内であれば、請求情報データベース１１に格納された当該明細情報における取引Ｂの決済口座を、付随口座から主口座に戻す内容の書き換えを暫定的に行う。同時に、会員に対して、口座変更が拒否された旨の電子メールを送信するとともに、双方の端末２，３上の表示も変更前（図３）に戻す。その後、会員から取引Ｂについて再度の決済口座の変更操作がなく、指定期間が経過すれば、当初指定されていた主口座で決済口座を確定させる（Ｓ６）。なお、Ｓ４において、付随口座名義人から再変更する旨（変更を拒否）の情報が何ら送信されず指定期間を経過した場合、またＳ５において、再変更する旨の情報が指定期間経過後であった場合は、取引Ｂの決済口座を付随口座として確定させ、請求情報データベース１１内の明細情報における決済口座を付随口座に書き換える（Ｓ７）。以上の制御は、取引Ｂの決済口座の変更のみを説明したが、他の取引の決済口座についても、指定期間内であれば、会員及び付随口座名義人の同様の操作により種々変更可能である。もっとも、限度なく決済口座の変更が可能とすると、確認等で種々の不便が予想されるため、変更できる回数を制限する制御としても良い。
【００３５】
以上のように、本形態例によれば、本質的に、後述する本発明の効果が認められることになる。さらに、詳述にその効果を説明すると、次のとおりとなる。
【００３６】
会員側から見た効果として、決済手段が多様化して、キャッシュレス取引の利便性が向上する。特に他人の利用に供する場合、その他人口座から決済できるので便利である。複数の決済口座から選択して決済する場合でも、１つのカード会社と会員契約した１枚のクレジットカードのみで足りるので、複数のカード会社と会員契約をして複数枚のクレジットカードを保有し、その取引毎にカードを一々使い分けるといった煩雑な作業が不要となる。また、カード不適格者であっても、カード取引ができることにもなり（後述の実施例７参照）、実質的にカード発行基準の緩和がされることになる。
【００３７】
加盟店側から見た効果として、カード利用機会の増加による収益の拡大が図れる。また、加盟店の業種によっては、これまで自社リスクでやらざる得なかった料金取立・回収業務（後述の実施例６における学校の授業料の決済など）を、カード利用形態の拡充によってカード会社に委託することができ、料金未回収リスクが低減する。
【００３８】
カード会社側から見た効果として、カード利用機会の増加による収益の拡大が図れる。いわゆる法人カードは利用できなかった自営業者や小企業において、法人カード以上の利便性があることから（後述の実施例４、５参照）、それら者のカード市場の取込が可能となる。カード利用機会が増加することにより、加盟店契約を希望する加盟店の取り込みも可能となる。さらに、会員が取引に見合った決済口座を選択することになるので、料金未回収のリスクが低減する。
【００３９】
口座を保有する銀行などの金融機関から見た効果として、さまざまな口座を提供する場面が増えると同時に（後述する実施例２参照）、より多くの人から種々の口座を設けてもらう機会が増え、収益拡大の可能性が拡がる。
【００４０】
なお、以上の形態例が本発明の一例に過ぎないことは上述のとおりであり、例えば、決済口座の変更を電子メールでサーバ１２に通知するとか、付随口座の名義人へ決済口座の変更をする手段として電子メールではなくＦＡＸを用いるとか、付随口座名義人からの送信内容（口座変更拒否など）は会員に連絡しないとか、明細情報の格納場所をサーバ１２内の記憶手段にするとかなどの、仔細な変更はもとより、クレジットカードの代わりの決済処理用媒体として携帯電話を用いる態様としたり（この場合、携帯電話の中の記録媒体中に会員情報が記録される）、あるいは複数のカード会社で同様のシステムを採用し、前記センタ１を複数のカード会社の共同で運営する共同センタとするなどの変更であっても、当然に本発明の範囲に含まれるものである。
【００４１】
【実施例】
以上のような形態例がどのような場面で利用できるかについて、その利便性を基に具体的に説明する。
【００４２】
実施例１：　外国におけるカード取引が頻繁にある会員が、外国でのカード取引については外貨口座で、日本でのカード取引については日本円口座で決済したいような場合。この場合は、例えば、主口座として日本国内の金融機関の口座を指定し、付随口座として外国の金融機関の外貨建て口座を指定して、上記形態例を利用する。付随口座名義は会員自身でよい。本実施例では、付随口座が外貨建て口座であり、外貨を基準にカード取引した分については、その付随口座から決済するよう選択すれば、為替リスクがまったくなくなるというメリットが認められる。この点、前記特開２００２−３２５８１は、円建ての口座の中に、外貨に換算した仮想通貨決済口座を設けるものなので、為替リスクが生じてしまい、またそのような特別な口座を銀行側に設ける必要もある。それらデメリットは本実施例にはない。
【００４３】
実施例２：　ある条件下で金利が大きく変動する口座（例えば株価指数や為替レートに連動するような金融商品の口座）をもっている会員が、通常の口座よりその変動金利の口座の金利が低いときのみその口座から決済をしたいような場合。この場合は、例えば、主口座として通常の口座を、付随口座として変動金利の口座を指定して、上記形態例を利用する。付随口座は会員自身でよい。本実施例では、付随口座の金利が高いときは、主口座から決済をし、付随口座の金利が主口座の金利より低いときは、付随口座から決済するよう選択することで、常に金利の高い口座の残高をなるべく残すことができ、より多くの利息を受け取ることができる。
【００４４】
実施例３：　個人の利用は自分専用の口座で、夫婦共同の利用分は夫婦で管理する口座でそれぞれ決済を分けたいような場合。この場合は、例えば、一方配偶者が会員となって、主口座を自分の口座、付随口座を夫婦共同で管理する口座としてそれぞれ指定し、上記形態例を利用する。この場合も、付随口座の名義は主口座と同じで良いが、異なっても良い（付随口座が他方配偶者名義の口座となる）。本実施例では、１枚のクレジットカードを保有するのみで、会員個人と夫婦共同の支払い管理が容易に行える。
【００４５】
実施例４：　個人事業者がプライベートの利用分は個人用の口座で、事業用の利用分は事業用口座でそれぞれ決済を分けたい場合。この場合は、例えば、個人用の口座を主口座、事業用の口座を付随口座とそれぞれ指定し、上記形態例を利用する。個人事業者の口座名義は実質個人しか認められないので、この場合は、主口座と付随口座の名義は同一となる。本実施例でも、１枚のクレジットカードを保有するのみで、プライベートの支払いと事業用支払い管理が容易に行える。
【００４６】
実施例５：　個人の利用分は本人名義の口座、仕事上の利用分（交通費、出張費など）は会社名義の口座でそれぞれ決済を分けたいような場合。この場合は、例えば、主口座を自分の口座、付随口座を会社名義の口座とそれぞれ指定し、上記形態例を利用する。現行のシステムにおいては、法人が会員となって、社員一人一人に法人名義の子カードをもたせる、いわゆる法人カードがあるが、そのカードでは基本的に仕事上の利用分しか決済できず（個人利用は事実上できるが、その際は会社の経理担当者が請求明細書の内訳をチェックし、その社員に対して当該決済を否認することを告げた後、社内手続で返還させること等を要して手続が非常に煩雑となる）、結局個人支払いをカードで行いたい場合は、個人のカードをもつ必要があった。本実施例では、１枚のカードだけ保有すればそれで足りる。また、会社が明細情報を閲覧して、付随口座で決済すべき取引でないと判断すれば、本人名義の主口座に再変更するだけでよいので、手続もきわめて簡素化する。
【００４７】
実施例６：個人用の利用分は本人名義の口座、両親が支払う取り決めの費用（入学金、授業料等）は親名義の口座でそれぞれ決済を分けたいような場合。この場合は、例えば、主口座を自分の口座、付随口座を親名義の口座とそれぞれ指定し、上記形態例を利用する。子側からは、取り決め分は親側から確実に決済される一方、親側からは、自己名義口座から決済される内訳を明細情報からチェックできるので、取り決め以外の支払いに用いられていないかどうか確実に確認できる。
【００４８】
実施例７：家族の中にカード会員不適格の者（例えば成年被後見人）がいる場合、その家族の支払い分については、その者の口座で決済したいような場合。この場合は、主口座を自分の口座、付随口座をその家族名義の口座とそれぞれ指定し、上記形態例を利用する。ただし、不適格者が成年被後見人の場合は、会員自身が成年後見人であることを要する。カード会員不適格の者に対しても、会員適格者の責任の下、キャッシュレス取引ができるものとなり、カード取引の適用範囲が拡大する。
【００４９】
【発明の効果】
以上説明したように、この発明によれば、ユーザが、取引毎に複数設定されている決済口座からその取引に最適な口座をきわめて簡単に選択できるものとなっている。そして、システムの装置構成も、信用供与者側のみ変更すればよく、ユーザ、サプライヤ、さらに口座保有会社は従来どおりのシステムで十分対応可能なので、それらの者に何ら負担がかからず、汎用性が高いシステムを実現できるものとなっている。さらに、利便性が良好で、ユーザのあらゆるニーズに応えられる多様なクレジット取引の利用形態が可能となるので、ユーザにとって大きなメリットになるばかりでなく、クレジット取引の適用範囲が顕著に拡大されるという優れた効果が認められる。
【図面の簡単な説明】
【図１】本発明の一形態例が実施されるシステムの装置構成図である。
【図２】サーバにおける制御を示すフローチャート図である。
【図３】端末上に示される明細情報の表示画面の一例であり、（ａ）は会員が操作する端末上の画面、（ａ）は付随口座名義人が操作する端末上の画面を各示す。
【図４】図３から決済口座が変更された状態において、端末上に示される明細情報の表示画面の一例であり、（ａ）は会員が操作する端末上の画面、（ａ）は付随口座名義人が操作する端末上の画面を各示す。
【符号の説明】
１　　　　　　カード会社センタ
２　　　　　　会員が操作する端末
３　　　　　　付随口座名義人が操作する端末
４　　　　　　インターネット回線網
１０　　　　　　会員データベース
１１　　　　　　請求情報データベース
１２　　　　　　サーバ

Claims (2)

1. 少なくとも、各ユーザ毎に、クレジット取引用決済主口座とそれ以外の決済付随口座とからなる決済口座情報が格納される格納場所と、その決済口座毎にその口座名義人の連絡先情報が関連づけて格納される格納場所とが設定されるデータベースを参照しつつ、
   請求情報格納部において各ユーザ毎に格納されるクレジット取引の明細情報であって、取引毎に振り替えられる決済口座が関連づけられた明細情報の全部または一部を、ユーザまたは決済主口座の名義人と異なる決済付随口座の名義人の要求に応じて返信させる制御と、
   ユーザから、所定の取引についての決済口座を、決済主口座から決済付随口座へ変更する旨の通知を受けた場合、前記明細情報のうち、その取引の決済口座を、通知された決済付随口座に書き換させるとともに、その決済付随口座の名義人が、決済主口座の名義人と一致するかどうか判断し、異なると判断される場合、決済付随口座名義人に向けて、その口座から決済が行われる旨の通知を送信させる制御と、
   決済主口座の名義人と異なる決済付随口座の名義人から、所定の取引について決済付随口座からの振り替えを拒否する旨の通知を受けた場合、明細情報のうち、その取引の決済口座を決済主口座に書き換えさせる制御とを実行する制御部を有したことを特徴とする決済口座指定機能付クレジット取引用のサーバ。
2. ユーザから、所定の取引についての決済口座を、決済主口座から決済付随口座へ変更する旨の通知を受けた場合、前記明細情報のうち、その取引の決済口座を、通知された決済付随口座に書き換させるとともに、その決済付随口座の名義人が、決済主口座の名義人と一致するかどうか判断し、異なると判断される場合、決済付随口座名義人に向けて、その口座から決済が行われる旨の通知を送信させる制御と、
   決済主口座の名義人と異なる決済付随口座の名義人から、所定の取引について決済付随口座からの振り替えを拒否する旨の通知を受けた場合、明細情報のうち、その取引の決済口座を決済主口座に書き換えさせる制御について、
   それらの制御の原因となる通知が所定期間内であるかどうか判断し、所定期間内であればそれら制御を実行させ、一方、所定期間経過後の場合は、所定期間経過時に格納されている明細情報どおりの決済口座を、各取引の決済口座として処理させる指示情報を出力することを特徴とする決済口座指定機能付クレジット取引用のサーバ。

Images