JP3410087B2 - 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム - Google Patents
決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラムInfo
- Publication number
- JP3410087B2 JP3410087B2 JP2001328283A JP2001328283A JP3410087B2 JP 3410087 B2 JP3410087 B2 JP 3410087B2 JP 2001328283 A JP2001328283 A JP 2001328283A JP 2001328283 A JP2001328283 A JP 2001328283A JP 3410087 B2 JP3410087 B2 JP 3410087B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- server
- payment
- unit
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Description
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、決済支援技術に関
し、とくに、商品又は役務の購入に伴う決済を支援する
決済支援システム、決済支援サーバ、決済支援方法、及
び決済支援機能をコンピュータに実現させるプログラム
に関する。
し、とくに、商品又は役務の購入に伴う決済を支援する
決済支援システム、決済支援サーバ、決済支援方法、及
び決済支援機能をコンピュータに実現させるプログラム
に関する。
【０００２】
【従来の技術】近年、パーソナルコンピュータなどの端
末が広く普及するとともに、ネットワークインフラの整
備が急速に進み、インターネット、とくに、ＷＷＷ（Wo
rld Wide Web）の利用者が激増している。対面、非対面
を問わず、会社でも、自宅でも、携帯端末や携帯電話な
どの移動端末を利用して移動中でもアクセスできるとい
うＷＷＷの特徴を生かし、ＷＷＷを利用して商品又は役
務の提供、販売を行うオンラインショッピングサイトが
数多く開設されている。このような消費者向け（Ｂｔｏ
Ｃ）の電子商取引技術は、消費者には、自宅や会社にい
ながらにしてさまざまな商品を購入できるという利点を
もたらし、販売主体には、宣伝広告費や運営費などの経
費を削減でき、さらに、世界中の消費者をターゲットに
できるという利点をもたらした。
末が広く普及するとともに、ネットワークインフラの整
備が急速に進み、インターネット、とくに、ＷＷＷ（Wo
rld Wide Web）の利用者が激増している。対面、非対面
を問わず、会社でも、自宅でも、携帯端末や携帯電話な
どの移動端末を利用して移動中でもアクセスできるとい
うＷＷＷの特徴を生かし、ＷＷＷを利用して商品又は役
務の提供、販売を行うオンラインショッピングサイトが
数多く開設されている。このような消費者向け（Ｂｔｏ
Ｃ）の電子商取引技術は、消費者には、自宅や会社にい
ながらにしてさまざまな商品を購入できるという利点を
もたらし、販売主体には、宣伝広告費や運営費などの経
費を削減でき、さらに、世界中の消費者をターゲットに
できるという利点をもたらした。
【０００３】電子商取引が広く利用されるようになり、
クレジットカードなどを利用した電子決済技術も注目を
集めるようになっている。電子商取引においてクレジッ
トカードによる決済を行う場合、ユーザに対する与信の
可否の照会及び与信枠の確保の要求（以下、「オーソリ
要求」ともいう。）をリアルタイムに行おうとすると、
現実の店舗におけるＣＡＴ（Credit Authorization Ter
minal）端末の機能を、オンラインショッピングサイト
を提供するサーバに持たせる必要があるが、このような
機能を実現するシステムを導入し、決済業務の一部を代
行する業者の出現により、クレジットカードによる決済
を扱うオンラインショッピングサイトが増加し、電子決
済技術が広く浸透してきている。
クレジットカードなどを利用した電子決済技術も注目を
集めるようになっている。電子商取引においてクレジッ
トカードによる決済を行う場合、ユーザに対する与信の
可否の照会及び与信枠の確保の要求（以下、「オーソリ
要求」ともいう。）をリアルタイムに行おうとすると、
現実の店舗におけるＣＡＴ（Credit Authorization Ter
minal）端末の機能を、オンラインショッピングサイト
を提供するサーバに持たせる必要があるが、このような
機能を実現するシステムを導入し、決済業務の一部を代
行する業者の出現により、クレジットカードによる決済
を扱うオンラインショッピングサイトが増加し、電子決
済技術が広く浸透してきている。
【０００４】
【発明が解決しようとする課題】クレジットカードによ
る決済業務を実現する金融ネットワークでは、店舗から
クレジットカード会社に与信照会要求を送信するための
ＰＯＳ（Point-Of-Sale）端末、ＣＡＴ（Credit Author
ization Terminal）端末、ＡＴＭ（Automated Teller M
achine）端末などの照会端末のそれぞれに端末識別番号
を一意的に割り当て、端末識別番号を用いて与信照会の
送信元を識別している。このため、一つの端末から同時
に複数の与信照会要求を送信することは想定されておら
ず、ある端末識別番号の端末からの与信照会の処理中
に、それと同一の端末識別番号により与信照会を要求す
ることは許されない。電子商取引における仮想店舗の場
合、同時に複数のユーザがアクセスして決済を要求する
可能性があるが、与信照会は一度に一人ずつしか行えな
いため、ユーザを長時間待たせることになる恐れがあっ
た。従来は、オンラインショッピングサイトを提供する
サーバの処理能力の問題で、一度に多くのユーザを扱い
きれなかったが、サーバの処理能力の向上に伴い同時に
多くのユーザがオンラインショッピングサイトにアクセ
ス可能となった現在、与信照会の際の待ち時間の問題は
より顕著となり、迅速さが求められる電子商取引におい
ては致命的な問題となりかねない。
る決済業務を実現する金融ネットワークでは、店舗から
クレジットカード会社に与信照会要求を送信するための
ＰＯＳ（Point-Of-Sale）端末、ＣＡＴ（Credit Author
ization Terminal）端末、ＡＴＭ（Automated Teller M
achine）端末などの照会端末のそれぞれに端末識別番号
を一意的に割り当て、端末識別番号を用いて与信照会の
送信元を識別している。このため、一つの端末から同時
に複数の与信照会要求を送信することは想定されておら
ず、ある端末識別番号の端末からの与信照会の処理中
に、それと同一の端末識別番号により与信照会を要求す
ることは許されない。電子商取引における仮想店舗の場
合、同時に複数のユーザがアクセスして決済を要求する
可能性があるが、与信照会は一度に一人ずつしか行えな
いため、ユーザを長時間待たせることになる恐れがあっ
た。従来は、オンラインショッピングサイトを提供する
サーバの処理能力の問題で、一度に多くのユーザを扱い
きれなかったが、サーバの処理能力の向上に伴い同時に
多くのユーザがオンラインショッピングサイトにアクセ
ス可能となった現在、与信照会の際の待ち時間の問題は
より顕著となり、迅速さが求められる電子商取引におい
ては致命的な問題となりかねない。
【０００５】また、決済処理に関する情報を、ネットワ
ークを利用して送受信する以上、通信障害により生じる
処理結果の認識の不整合は、完全には排除しきれない問
題である。たとえば、店舗がクレジットカード会社にユ
ーザの与信枠の確保を要求したとき、クレジットカード
会社は与信枠の確保に成功して応答情報を送信したにも
関わらず、その応答情報が何らかの通信障害により店舗
側に届かなかった場合、クレジットカード会社側では与
信枠の確保に成功したと認識され、店舗側では与信枠の
確保に失敗したと認識されるため、両者に不整合が生じ
る。このような不整合の発生を最小限に抑えるととも
に、不整合が発生したときに的確に検知し、適切に対処
する技術が求められる。
ークを利用して送受信する以上、通信障害により生じる
処理結果の認識の不整合は、完全には排除しきれない問
題である。たとえば、店舗がクレジットカード会社にユ
ーザの与信枠の確保を要求したとき、クレジットカード
会社は与信枠の確保に成功して応答情報を送信したにも
関わらず、その応答情報が何らかの通信障害により店舗
側に届かなかった場合、クレジットカード会社側では与
信枠の確保に成功したと認識され、店舗側では与信枠の
確保に失敗したと認識されるため、両者に不整合が生じ
る。このような不整合の発生を最小限に抑えるととも
に、不整合が発生したときに的確に検知し、適切に対処
する技術が求められる。
【０００６】さらに、クレジットカード会社と店舗との
契約上の制限により、店舗側に無用な負担を強いている
場合があった。たとえば、一度要求した決済の金額を変
更する場合、契約上は一部を返品する処理が認められて
いなかったため、いったん元の決済について返品処理を
要求したあと、つづいて、変更後の金額による新たな決
済を要求する必要がある。より多くの店舗にクレジット
カードを利用した電子決済サービスを導入させ、電子決
済サービスを一般に広く浸透させるためには、決済代行
業者がこのような店舗側の負担をできる限り吸収し、よ
り利便性の高い決済支援技術を提供していく必要があ
る。
契約上の制限により、店舗側に無用な負担を強いている
場合があった。たとえば、一度要求した決済の金額を変
更する場合、契約上は一部を返品する処理が認められて
いなかったため、いったん元の決済について返品処理を
要求したあと、つづいて、変更後の金額による新たな決
済を要求する必要がある。より多くの店舗にクレジット
カードを利用した電子決済サービスを導入させ、電子決
済サービスを一般に広く浸透させるためには、決済代行
業者がこのような店舗側の負担をできる限り吸収し、よ
り利便性の高い決済支援技術を提供していく必要があ
る。
【０００７】そこで、本発明は、上記の課題を解決する
ことのできる決済支援システム、決済支援サーバ、決済
支援方法、及び決済支援機能をコンピュータに実現させ
るプログラムを提供することを目的とする。この目的は
特許請求の範囲における独立項に記載の特徴の組合せに
より達成される。また従属項は本発明の更なる有利な具
体例を規定する。
ことのできる決済支援システム、決済支援サーバ、決済
支援方法、及び決済支援機能をコンピュータに実現させ
るプログラムを提供することを目的とする。この目的は
特許請求の範囲における独立項に記載の特徴の組合せに
より達成される。また従属項は本発明の更なる有利な具
体例を規定する。
【０００８】
【課題を解決するための手段】上記目的を達成するため
に、本発明の第１の形態に係る決済支援方法は、商品又
は役務の購入要求を受け付ける購入受付サーバが、ユー
ザから、購入に伴う決済要求を受け付ける工程と、購入
受付サーバが、そのユーザに対する与信の可否をクレジ
ットカード会社の決済処理サーバに照会するための照会
情報を生成する工程と、購入受付サーバが、照会情報に
付与するための端末識別番号を複数格納したテーブルか
ら、使用中でない端末識別番号を読み出して照会情報に
付与する工程と、購入受付サーバが、付与する工程で付
与された端末識別番号の使用状況を使用中に設定する工
程と、購入受付サーバが、決済を支援する決済支援サー
バに照会情報を送信する工程と、決済支援サーバが、購
入受付サーバから受け付けた照会情報を、決済処理を行
う決済処理サーバに送信する工程と、決済処理サーバ
が、決済支援サーバから受け付けた照会情報に基づいて
与信の可否を判断し、その判断結果を含む応答情報を生
成して、決済支援サーバに送信する工程と、決済支援サ
ーバが、決済処理サーバから受け付けた応答情報を、購
入受付サーバに送信する工程と、購入受付サーバが、応
答情報を決済支援サーバから取得する工程と、購入受付
サーバが、取得する工程で取得した応答情報に対応する
照会情報に付与されていた端末識別番号の使用状況を非
使用中に設定する工程とを含む。
に、本発明の第１の形態に係る決済支援方法は、商品又
は役務の購入要求を受け付ける購入受付サーバが、ユー
ザから、購入に伴う決済要求を受け付ける工程と、購入
受付サーバが、そのユーザに対する与信の可否をクレジ
ットカード会社の決済処理サーバに照会するための照会
情報を生成する工程と、購入受付サーバが、照会情報に
付与するための端末識別番号を複数格納したテーブルか
ら、使用中でない端末識別番号を読み出して照会情報に
付与する工程と、購入受付サーバが、付与する工程で付
与された端末識別番号の使用状況を使用中に設定する工
程と、購入受付サーバが、決済を支援する決済支援サー
バに照会情報を送信する工程と、決済支援サーバが、購
入受付サーバから受け付けた照会情報を、決済処理を行
う決済処理サーバに送信する工程と、決済処理サーバ
が、決済支援サーバから受け付けた照会情報に基づいて
与信の可否を判断し、その判断結果を含む応答情報を生
成して、決済支援サーバに送信する工程と、決済支援サ
ーバが、決済処理サーバから受け付けた応答情報を、購
入受付サーバに送信する工程と、購入受付サーバが、応
答情報を決済支援サーバから取得する工程と、購入受付
サーバが、取得する工程で取得した応答情報に対応する
照会情報に付与されていた端末識別番号の使用状況を非
使用中に設定する工程とを含む。
【０００９】端末識別番号は、ＰＯＳ端末、ＣＡＴ端
末、ＡＴＭ端末等、与信照会を要求するための端末を一
意に識別するための番号であってもよい。クレジットカ
ード会社の決済処理サーバは、この端末識別番号によ
り、与信照会元の加盟店を識別する。購入受付サーバ
が、ＷＷＷなどを利用してオンラインショッピングサイ
トを提供する場合、端末識別番号は、その仮想的な店舗
に設けられた仮想的な照会端末を一意に識別するための
番号であってもよい。店舗ごとに複数の端末識別番号を
割り当てることにより、複数の与信照会を同時に並列し
て処理することができる。
末、ＡＴＭ端末等、与信照会を要求するための端末を一
意に識別するための番号であってもよい。クレジットカ
ード会社の決済処理サーバは、この端末識別番号によ
り、与信照会元の加盟店を識別する。購入受付サーバ
が、ＷＷＷなどを利用してオンラインショッピングサイ
トを提供する場合、端末識別番号は、その仮想的な店舗
に設けられた仮想的な照会端末を一意に識別するための
番号であってもよい。店舗ごとに複数の端末識別番号を
割り当てることにより、複数の与信照会を同時に並列し
て処理することができる。
【００１０】本発明の第２の形態に係る決済支援システ
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、購入に伴う決済を支援する決済支援
サーバと、決済処理を行う決済処理サーバとを備え、購
入受付サーバは、ユーザから購入に伴う決済要求を受け
付けたときに、そのユーザに対する与信の可否を照会す
るための照会情報を生成する生成部と、照会情報に付与
するための端末識別番号を複数格納する格納部と、格納
部に格納された複数の端末識別番号のうち、使用中でな
い端末識別番号を読み出して、照会情報に付与する付与
部と、照会情報を決済支援サーバに送信する第１の照会
情報送信部と、照会に対する応答情報を決済支援サーバ
から受信する応答情報受信部と、付与部が照会情報に端
末識別番号を付与したときに、その端末識別番号の使用
状況を使用中に設定し、応答情報受信部が応答情報を受
信したときに、その応答情報に対応する照会情報に付与
されていた端末識別番号の使用状況を非使用中に設定す
る管理部とを含み、決済支援サーバは、購入受付サーバ
から照会情報を受け付けて決済処理サーバへ送信する第
２の照会情報送信部と、決済処理サーバから応答情報を
受け付けて購入受付サーバへ送信する第１の応答情報送
信部とを含み、決済処理サーバは、決済支援サーバか
ら、照会情報を受け付ける照会情報受付部と、照会情報
に基づいて、与信の可否を判断する判断部と、判断部に
よる判断結果を含む応答情報を生成して決済支援サーバ
に送信する第２の応答情報送信部とを含む。
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、購入に伴う決済を支援する決済支援
サーバと、決済処理を行う決済処理サーバとを備え、購
入受付サーバは、ユーザから購入に伴う決済要求を受け
付けたときに、そのユーザに対する与信の可否を照会す
るための照会情報を生成する生成部と、照会情報に付与
するための端末識別番号を複数格納する格納部と、格納
部に格納された複数の端末識別番号のうち、使用中でな
い端末識別番号を読み出して、照会情報に付与する付与
部と、照会情報を決済支援サーバに送信する第１の照会
情報送信部と、照会に対する応答情報を決済支援サーバ
から受信する応答情報受信部と、付与部が照会情報に端
末識別番号を付与したときに、その端末識別番号の使用
状況を使用中に設定し、応答情報受信部が応答情報を受
信したときに、その応答情報に対応する照会情報に付与
されていた端末識別番号の使用状況を非使用中に設定す
る管理部とを含み、決済支援サーバは、購入受付サーバ
から照会情報を受け付けて決済処理サーバへ送信する第
２の照会情報送信部と、決済処理サーバから応答情報を
受け付けて購入受付サーバへ送信する第１の応答情報送
信部とを含み、決済処理サーバは、決済支援サーバか
ら、照会情報を受け付ける照会情報受付部と、照会情報
に基づいて、与信の可否を判断する判断部と、判断部に
よる判断結果を含む応答情報を生成して決済支援サーバ
に送信する第２の応答情報送信部とを含む。
【００１１】照会情報受付部は、照会情報に付与された
端末識別番号を参照して、ある端末識別番号が付与され
た照会情報の処理中に、それと同一の端末識別番号が付
与された照会情報の受け付けを拒否してもよい。このよ
うな場合であっても、購入受付サーバが、複数の端末識
別番号のうち、使用中でないものを順次照会情報に付与
するので、適切に与信照会を行うことができる。
端末識別番号を参照して、ある端末識別番号が付与され
た照会情報の処理中に、それと同一の端末識別番号が付
与された照会情報の受け付けを拒否してもよい。このよ
うな場合であっても、購入受付サーバが、複数の端末識
別番号のうち、使用中でないものを順次照会情報に付与
するので、適切に与信照会を行うことができる。
【００１２】本発明の第３の形態に係る決済支援システ
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、購入に伴う決済を支援する決済支援
サーバとを備え、購入受付サーバは、ユーザから購入に
伴う決済要求を受け付けたときに、そのユーザに対する
与信の可否を、決済処理を行う決済処理サーバに照会す
るための照会情報を生成する生成部と、照会情報に付与
するための符号情報を複数格納する格納部と、格納部に
格納された複数の符号情報のうち、使用中でない符号情
報を読み出して、照会情報に付与する付与部と、照会情
報を決済支援サーバに送信する第１の照会情報送信部
と、照会に対する応答情報を決済支援サーバから受信す
る応答情報受信部とを含み、決済支援サーバは、購入受
付サーバから照会情報を受け付けて決済処理サーバへ送
信する第２の照会情報送信部と、決済処理サーバから応
答情報を受け付けて購入受付サーバへ送信する応答情報
送信部とを含む。
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、購入に伴う決済を支援する決済支援
サーバとを備え、購入受付サーバは、ユーザから購入に
伴う決済要求を受け付けたときに、そのユーザに対する
与信の可否を、決済処理を行う決済処理サーバに照会す
るための照会情報を生成する生成部と、照会情報に付与
するための符号情報を複数格納する格納部と、格納部に
格納された複数の符号情報のうち、使用中でない符号情
報を読み出して、照会情報に付与する付与部と、照会情
報を決済支援サーバに送信する第１の照会情報送信部
と、照会に対する応答情報を決済支援サーバから受信す
る応答情報受信部とを含み、決済支援サーバは、購入受
付サーバから照会情報を受け付けて決済処理サーバへ送
信する第２の照会情報送信部と、決済処理サーバから応
答情報を受け付けて購入受付サーバへ送信する応答情報
送信部とを含む。
【００１３】購入受付サーバは、商品又は役務の複数の
提供主体に対する購入要求を受け付け、格納部は、提供
主体ごとに、その提供主体が利用可能な複数の符号情報
を格納し、付与部は、提供主体が利用可能な複数の符号
情報のうち、使用中でない符号情報を読み出して、照会
情報に付与してもよい。各提供主体が格納部に格納され
た全ての符号情報を利用可能とし、与信照会が要求され
るたびに、その時点で使用中でない符号情報を付与して
もよい。
提供主体に対する購入要求を受け付け、格納部は、提供
主体ごとに、その提供主体が利用可能な複数の符号情報
を格納し、付与部は、提供主体が利用可能な複数の符号
情報のうち、使用中でない符号情報を読み出して、照会
情報に付与してもよい。各提供主体が格納部に格納され
た全ての符号情報を利用可能とし、与信照会が要求され
るたびに、その時点で使用中でない符号情報を付与して
もよい。
【００１４】購入受付サーバは、符号情報の使用状況を
管理する管理部をさらに含み、管理部は、符号情報が付
与部により照会情報に付与されたときに、その符号情報
の使用状況を使用中とし、応答情報受信部が応答情報を
受信したときに、その応答情報に対応する照会情報に付
与された符号情報の使用状況を非使用中としてもよい。
管理部は、所定の時間が経過しても応答情報受信部が応
答情報を受信しなかったときに、その応答情報に対応す
る照会情報に付与された符号情報の使用状況を非使用中
としてもよい。これにより、与信照会の終了とともに符
号情報を解放し、他の与信照会に利用可能とするので、
限られた符号情報を効率よく利用することができる。
管理する管理部をさらに含み、管理部は、符号情報が付
与部により照会情報に付与されたときに、その符号情報
の使用状況を使用中とし、応答情報受信部が応答情報を
受信したときに、その応答情報に対応する照会情報に付
与された符号情報の使用状況を非使用中としてもよい。
管理部は、所定の時間が経過しても応答情報受信部が応
答情報を受信しなかったときに、その応答情報に対応す
る照会情報に付与された符号情報の使用状況を非使用中
としてもよい。これにより、与信照会の終了とともに符
号情報を解放し、他の与信照会に利用可能とするので、
限られた符号情報を効率よく利用することができる。
【００１５】格納部は、購入受付サーバまたは提供主体
による照会の頻度に応じて予め割り当てられた符号情報
を格納してもよい。または、照会の頻度の変動状況に応
じて、符号情報を動的に割り当ててもよい。付与部は、
ユーザが購入する商品又は役務の種類に基づいて、照会
情報に付与すべき符号情報を決定してもよい。付与部
は、ユーザの属性情報に基づいて、照会情報に付与すべ
き符号情報を決定してもよい。
による照会の頻度に応じて予め割り当てられた符号情報
を格納してもよい。または、照会の頻度の変動状況に応
じて、符号情報を動的に割り当ててもよい。付与部は、
ユーザが購入する商品又は役務の種類に基づいて、照会
情報に付与すべき符号情報を決定してもよい。付与部
は、ユーザの属性情報に基づいて、照会情報に付与すべ
き符号情報を決定してもよい。
【００１６】本発明の第４の形態に係る決済支援システ
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、購入に伴う決済を支援する決済支援
サーバとを備え、購入受付サーバは、ユーザから購入に
伴う決済要求を受け付けたときに、そのユーザに対する
与信の可否を、決済処理を行う決済処理サーバに照会す
るための照会情報を生成する生成部と、商品又は役務の
提供主体或いは購入受付サーバの識別情報とともに照会
情報を決済支援サーバに送信する第１の照会情報送信部
と、照会に対する応答情報を決済支援サーバから受信す
る応答情報受信部とを含み、決済支援サーバは、購入受
付サーバから照会情報を受け付ける照会情報受付部と、
照会情報に付与するための符号情報を複数格納する格納
部と、格納部に格納された複数の符号情報のうち、使用
中でない符号情報を読み出して、照会情報に付与する付
与部と、照会情報を決済処理サーバへ送信する第２の照
会情報送信部と、決済処理サーバから応答情報を受け付
けて購入受付サーバへ送信する応答情報送信部とを含
む。
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、購入に伴う決済を支援する決済支援
サーバとを備え、購入受付サーバは、ユーザから購入に
伴う決済要求を受け付けたときに、そのユーザに対する
与信の可否を、決済処理を行う決済処理サーバに照会す
るための照会情報を生成する生成部と、商品又は役務の
提供主体或いは購入受付サーバの識別情報とともに照会
情報を決済支援サーバに送信する第１の照会情報送信部
と、照会に対する応答情報を決済支援サーバから受信す
る応答情報受信部とを含み、決済支援サーバは、購入受
付サーバから照会情報を受け付ける照会情報受付部と、
照会情報に付与するための符号情報を複数格納する格納
部と、格納部に格納された複数の符号情報のうち、使用
中でない符号情報を読み出して、照会情報に付与する付
与部と、照会情報を決済処理サーバへ送信する第２の照
会情報送信部と、決済処理サーバから応答情報を受け付
けて購入受付サーバへ送信する応答情報送信部とを含
む。
【００１７】格納部は、提供主体ごとに、その提供主体
における照会の頻度に応じて予め割り当てられた符号情
報を格納し、付与部は、照会情報の送信元の提供主体に
割り当てられた符号情報のうち、使用中でない符号情報
を読み出して、その照会情報に付与してもよい。格納部
は、提供主体ごとに、その提供主体における照会の頻度
の変動状況に応じて動的に割り当てられた符号情報を格
納し、付与部は、照会情報の送信元の提供主体に割り当
てられた符号情報のうち、使用中でない符号情報を読み
出して、その照会情報に付与してもよい。決済支援サー
バは、提供主体における照会の頻度に応じて、その提供
主体に割り当てる符号情報を変更する変更部をさらに含
んでもよい。
における照会の頻度に応じて予め割り当てられた符号情
報を格納し、付与部は、照会情報の送信元の提供主体に
割り当てられた符号情報のうち、使用中でない符号情報
を読み出して、その照会情報に付与してもよい。格納部
は、提供主体ごとに、その提供主体における照会の頻度
の変動状況に応じて動的に割り当てられた符号情報を格
納し、付与部は、照会情報の送信元の提供主体に割り当
てられた符号情報のうち、使用中でない符号情報を読み
出して、その照会情報に付与してもよい。決済支援サー
バは、提供主体における照会の頻度に応じて、その提供
主体に割り当てる符号情報を変更する変更部をさらに含
んでもよい。
【００１８】本発明の第５の形態に係る決済支援システ
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、商品又は役務の複数の提供主体或い
は複数の購入受付サーバを統括的に管理する管理サーバ
と、購入に伴う決済を支援する決済支援サーバとを備
え、購入受付サーバは、ユーザから購入に伴う決済要求
を受け付けたときに、そのユーザに対する与信の可否
を、決済処理を行う決済処理サーバに照会するための照
会情報を生成する生成部と、提供主体又は購入受付サー
バの識別情報とともに、照会情報を管理サーバに送信す
る第１の照会情報送信部と、照会に対する応答情報を管
理サーバから受信する第１の応答情報受信部とを含み、
管理サーバは、購入受付サーバから照会情報を受け付け
る第１の照会情報受信部と、照会情報に付与するための
符号情報を複数格納する格納部と、格納部に格納された
複数の符号情報のうち、使用中でない符号情報を読み出
して、照会情報に付与する付与部と、照会情報を決済支
援サーバへ送信する第２の照会情報送信部と、決済支援
サーバから応答情報を受信する第２の応答情報受信部
と、応答情報を購入受付サーバへ送信する第１の応答情
報送信部とを含み、決済支援サーバは、管理サーバから
照会情報を受け付ける第２の照会情報受信部と、照会情
報を決済処理サーバへ送信する第３の照会情報送信部
と、決済処理サーバから応答情報を受信する第３の応答
情報受信部と、応答情報を管理サーバへ送信する第２の
応答情報送信部とを含む。
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバと、商品又は役務の複数の提供主体或い
は複数の購入受付サーバを統括的に管理する管理サーバ
と、購入に伴う決済を支援する決済支援サーバとを備
え、購入受付サーバは、ユーザから購入に伴う決済要求
を受け付けたときに、そのユーザに対する与信の可否
を、決済処理を行う決済処理サーバに照会するための照
会情報を生成する生成部と、提供主体又は購入受付サー
バの識別情報とともに、照会情報を管理サーバに送信す
る第１の照会情報送信部と、照会に対する応答情報を管
理サーバから受信する第１の応答情報受信部とを含み、
管理サーバは、購入受付サーバから照会情報を受け付け
る第１の照会情報受信部と、照会情報に付与するための
符号情報を複数格納する格納部と、格納部に格納された
複数の符号情報のうち、使用中でない符号情報を読み出
して、照会情報に付与する付与部と、照会情報を決済支
援サーバへ送信する第２の照会情報送信部と、決済支援
サーバから応答情報を受信する第２の応答情報受信部
と、応答情報を購入受付サーバへ送信する第１の応答情
報送信部とを含み、決済支援サーバは、管理サーバから
照会情報を受け付ける第２の照会情報受信部と、照会情
報を決済処理サーバへ送信する第３の照会情報送信部
と、決済処理サーバから応答情報を受信する第３の応答
情報受信部と、応答情報を管理サーバへ送信する第２の
応答情報送信部とを含む。
【００１９】本発明の第６の形態に係る決済支援方法
は、ユーザから商品又は役務の購入に伴う決済要求を受
け付けたときに、そのユーザに対する与信の可否を、決
済処理を行うサーバに照会するための照会情報を生成す
る工程と、照会情報に付与するための符号情報を複数格
納するテーブルから、使用中でない符号情報を読み出し
て、照会情報に付与する工程と、照会情報を送信する工
程と、サーバによる照会に対する応答情報を受信する工
程とを含む。
は、ユーザから商品又は役務の購入に伴う決済要求を受
け付けたときに、そのユーザに対する与信の可否を、決
済処理を行うサーバに照会するための照会情報を生成す
る工程と、照会情報に付与するための符号情報を複数格
納するテーブルから、使用中でない符号情報を読み出し
て、照会情報に付与する工程と、照会情報を送信する工
程と、サーバによる照会に対する応答情報を受信する工
程とを含む。
【００２０】本発明の第７の形態に係る決済支援システ
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバを備え、購入受付サーバは、ユーザから
購入に伴う決済要求を受け付けたときに、そのユーザに
対する与信の可否を、決済処理を行う決済処理サーバに
照会するための照会情報を生成する生成部と、照会情報
に付与するための符号情報を複数格納する格納部と、格
納部に格納された複数の符号情報のうち、使用中でない
符号情報を読み出して、照会情報に付与する付与部と、
照会情報を送信する照会情報送信部と、照会に対する応
答情報を受信する応答情報受信部とを含む。
ムは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバを備え、購入受付サーバは、ユーザから
購入に伴う決済要求を受け付けたときに、そのユーザに
対する与信の可否を、決済処理を行う決済処理サーバに
照会するための照会情報を生成する生成部と、照会情報
に付与するための符号情報を複数格納する格納部と、格
納部に格納された複数の符号情報のうち、使用中でない
符号情報を読み出して、照会情報に付与する付与部と、
照会情報を送信する照会情報送信部と、照会に対する応
答情報を受信する応答情報受信部とを含む。
【００２１】本発明の第８の形態に係る決済支援システ
ムは、商品又は役務の購入に伴う決済を支援する決済支
援サーバを備え、決済支援サーバは、ユーザから商品又
は役務の購入に伴う決済要求を受け付けた購入受付サー
バから、そのユーザに対する与信の可否を照会するため
の照会情報を取得する照会情報受付部と、照会情報に付
与するための符号情報を複数格納する格納部と、格納部
に格納された複数の符号情報のうち、使用中でない符号
情報を読み出して、照会情報に付与する付与部と、照会
情報を、決済処理を行う決済処理サーバへ送信する照会
情報送信部と、決済処理サーバから照会に対する応答情
報を受け付けて購入受付サーバへ送信する応答情報送信
部とを含む。
ムは、商品又は役務の購入に伴う決済を支援する決済支
援サーバを備え、決済支援サーバは、ユーザから商品又
は役務の購入に伴う決済要求を受け付けた購入受付サー
バから、そのユーザに対する与信の可否を照会するため
の照会情報を取得する照会情報受付部と、照会情報に付
与するための符号情報を複数格納する格納部と、格納部
に格納された複数の符号情報のうち、使用中でない符号
情報を読み出して、照会情報に付与する付与部と、照会
情報を、決済処理を行う決済処理サーバへ送信する照会
情報送信部と、決済処理サーバから照会に対する応答情
報を受け付けて購入受付サーバへ送信する応答情報送信
部とを含む。
【００２２】本発明の第９の形態に係るプログラムは、
コンピュータに、ユーザから商品又は役務の購入に伴う
決済要求を受け付けたときに、そのユーザに対する与信
の可否をサーバに照会するための照会情報を生成する機
能と、照会情報に付与するための符号情報を複数格納す
るテーブルから、使用中でない符号情報を読み出して、
照会情報に付与する機能と、照会情報を送信する機能
と、サーバによる照会に対する応答情報を受信する機能
とを実現させる。
コンピュータに、ユーザから商品又は役務の購入に伴う
決済要求を受け付けたときに、そのユーザに対する与信
の可否をサーバに照会するための照会情報を生成する機
能と、照会情報に付与するための符号情報を複数格納す
るテーブルから、使用中でない符号情報を読み出して、
照会情報に付与する機能と、照会情報を送信する機能
と、サーバによる照会に対する応答情報を受信する機能
とを実現させる。
【００２３】本発明の第１０の形態に係るプログラム
は、コンピュータに、ユーザから商品又は役務の購入に
伴う決済要求を受け付けた購入受付サーバから、そのユ
ーザに対する与信の可否を照会するための照会情報を取
得する機能と、照会情報に付与するための符号情報を複
数格納するテーブルから、使用中でない符号情報を読み
出して、照会情報に付与する機能と、照会情報を、決済
処理を行う決済処理サーバに送信する機能と、照会に対
する応答情報を決済処理サーバから受信する機能と、応
答情報を購入受付サーバに送信する機能とを実現させ
る。
は、コンピュータに、ユーザから商品又は役務の購入に
伴う決済要求を受け付けた購入受付サーバから、そのユ
ーザに対する与信の可否を照会するための照会情報を取
得する機能と、照会情報に付与するための符号情報を複
数格納するテーブルから、使用中でない符号情報を読み
出して、照会情報に付与する機能と、照会情報を、決済
処理を行う決済処理サーバに送信する機能と、照会に対
する応答情報を決済処理サーバから受信する機能と、応
答情報を購入受付サーバに送信する機能とを実現させ
る。
【００２４】本発明の第１１の形態に係る決済支援シス
テムは、ユーザから購入に伴う決済要求を受け付け、そ
のユーザに対する与信の可否を、決済処理を行う決済処
理サーバに照会するための照会情報を生成する生成部
と、照会情報を所定の時期が到来するまで保持する保持
部と、照会情報に付与するための符号情報を複数格納す
る格納部と、所定の時期が到来したときに、保持部から
照会情報を読み出すバッチ処理部と、格納部に格納され
た複数の符号情報のうち、使用中でない符号情報を読み
出して、照会情報に付与する付与部と、照会情報を送信
する照会情報送信部と、照会に対する応答情報を受信す
る応答情報受信部とを含む。これにより、与信照会をま
とめて大量に実行することができる。
テムは、ユーザから購入に伴う決済要求を受け付け、そ
のユーザに対する与信の可否を、決済処理を行う決済処
理サーバに照会するための照会情報を生成する生成部
と、照会情報を所定の時期が到来するまで保持する保持
部と、照会情報に付与するための符号情報を複数格納す
る格納部と、所定の時期が到来したときに、保持部から
照会情報を読み出すバッチ処理部と、格納部に格納され
た複数の符号情報のうち、使用中でない符号情報を読み
出して、照会情報に付与する付与部と、照会情報を送信
する照会情報送信部と、照会に対する応答情報を受信す
る応答情報受信部とを含む。これにより、与信照会をま
とめて大量に実行することができる。
【００２５】本発明の第１２の形態に係る決済支援シス
テムは、複数のユーザから商品又は役務の購入に伴う決
済要求を受け付けた店舗から、それぞれのユーザに対す
る与信の可否を照会するための複数の照会情報をまとめ
て取得する照会情報受付部と、複数の照会情報を保持す
る保持部と、照会情報に付与するための符号情報を複数
格納する格納部と、保持部から照会情報を読み出すバッ
チ処理部と、格納部に格納された複数の符号情報のう
ち、使用中でない符号情報を読み出して、照会情報に付
与する付与部と、照会情報を、決済処理を行う決済処理
サーバへ送信する照会情報送信部と、決済処理サーバか
ら応答情報を受信する応答情報受信部と、応答情報を所
定の出力形式に変換する変換部とを含む。
テムは、複数のユーザから商品又は役務の購入に伴う決
済要求を受け付けた店舗から、それぞれのユーザに対す
る与信の可否を照会するための複数の照会情報をまとめ
て取得する照会情報受付部と、複数の照会情報を保持す
る保持部と、照会情報に付与するための符号情報を複数
格納する格納部と、保持部から照会情報を読み出すバッ
チ処理部と、格納部に格納された複数の符号情報のう
ち、使用中でない符号情報を読み出して、照会情報に付
与する付与部と、照会情報を、決済処理を行う決済処理
サーバへ送信する照会情報送信部と、決済処理サーバか
ら応答情報を受信する応答情報受信部と、応答情報を所
定の出力形式に変換する変換部とを含む。
【００２６】バッチ処理部は、保持部に保持された照会
情報を順次読み出して付与部に送り、付与部は、全ての
符号情報が使用中になったときに、いずれかの符号情報
が非使用中となるまで待機し、非使用中となった符号情
報を順次照会情報に付与してもよい。決済支援システム
は、照会を終了すべき日時を受け付け、照会情報の量と
日時とに基づいて、照会に使用可能な符号情報の数を決
定してもよい。たとえば、大量の与信照会を短時間で処
理しなければならない場合は、多くの符号情報を割り当
てる必要があるが、時間的に余裕がある場合は、割り当
てる符号情報の数を少なくしてもよい。
情報を順次読み出して付与部に送り、付与部は、全ての
符号情報が使用中になったときに、いずれかの符号情報
が非使用中となるまで待機し、非使用中となった符号情
報を順次照会情報に付与してもよい。決済支援システム
は、照会を終了すべき日時を受け付け、照会情報の量と
日時とに基づいて、照会に使用可能な符号情報の数を決
定してもよい。たとえば、大量の与信照会を短時間で処
理しなければならない場合は、多くの符号情報を割り当
てる必要があるが、時間的に余裕がある場合は、割り当
てる符号情報の数を少なくしてもよい。
【００２７】本発明の第１３の形態に係る決済支援シス
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバを備え、購入受付サーバは、当該購入
受付サーバに割り当てられた複数の端末識別番号を格納
する格納部と、複数の端末識別番号のそれぞれにより識
別され、ユーザによる購入に伴う決済要求を受け付ける
複数の仮想的な照会端末とを含み、複数の照会端末は、
互いに独立してデータの送受信を可能とし、複数のユー
ザからの決済要求を並列に処理可能とする。
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバを備え、購入受付サーバは、当該購入
受付サーバに割り当てられた複数の端末識別番号を格納
する格納部と、複数の端末識別番号のそれぞれにより識
別され、ユーザによる購入に伴う決済要求を受け付ける
複数の仮想的な照会端末とを含み、複数の照会端末は、
互いに独立してデータの送受信を可能とし、複数のユー
ザからの決済要求を並列に処理可能とする。
【００２８】本発明の第１４の形態に係る決済支援方法
は、商品又は役務の購入要求を受け付ける購入受付サー
バが、ユーザから、購入に伴う決済要求を受け付ける工
程と、購入受付サーバが、ユーザに対する与信枠を確保
するよう要求するための要求情報を生成する工程と、購
入受付サーバが、決済を支援する決済支援サーバに、要
求情報を送信する工程と、決済支援サーバが、購入受付
サーバから要求情報を受け付け、決済処理を行う決済処
理サーバに、購入受付サーバから受け付けた要求情報を
送信する工程と、決済処理サーバが、決済支援サーバか
ら要求情報を受け付け、要求情報に基づいてユーザに対
する与信の可否を判断し、ユーザに対する与信が可能と
判断したときに与信枠を確保する工程と、決済処理サー
バが、要求情報に対する応答情報を生成し、応答情報を
決済支援サーバに送信する工程と、決済支援サーバが、
決済処理サーバから応答情報を受信し、購入受付サーバ
に応答情報を送信する工程と、購入受付サーバが、応答
情報の受信状況を決済支援サーバへ通知する工程とを含
む。
は、商品又は役務の購入要求を受け付ける購入受付サー
バが、ユーザから、購入に伴う決済要求を受け付ける工
程と、購入受付サーバが、ユーザに対する与信枠を確保
するよう要求するための要求情報を生成する工程と、購
入受付サーバが、決済を支援する決済支援サーバに、要
求情報を送信する工程と、決済支援サーバが、購入受付
サーバから要求情報を受け付け、決済処理を行う決済処
理サーバに、購入受付サーバから受け付けた要求情報を
送信する工程と、決済処理サーバが、決済支援サーバか
ら要求情報を受け付け、要求情報に基づいてユーザに対
する与信の可否を判断し、ユーザに対する与信が可能と
判断したときに与信枠を確保する工程と、決済処理サー
バが、要求情報に対する応答情報を生成し、応答情報を
決済支援サーバに送信する工程と、決済支援サーバが、
決済処理サーバから応答情報を受信し、購入受付サーバ
に応答情報を送信する工程と、購入受付サーバが、応答
情報の受信状況を決済支援サーバへ通知する工程とを含
む。
【００２９】従来のように、決済支援サーバが購入受付
サーバに応答情報を送信しただけでは、それを購入受付
サーバ側が受け取れたか否かは、決済支援サーバ側では
知ることができない。そこで、購入受付サーバが応答情
報を受け取れたか否かを決済支援サーバが把握するため
に、購入受付サーバに受信状況を送信させる。これによ
り、購入受付サーバの受信状況を、決済支援サーバ側で
的確に把握することができる。
サーバに応答情報を送信しただけでは、それを購入受付
サーバ側が受け取れたか否かは、決済支援サーバ側では
知ることができない。そこで、購入受付サーバが応答情
報を受け取れたか否かを決済支援サーバが把握するため
に、購入受付サーバに受信状況を送信させる。これによ
り、購入受付サーバの受信状況を、決済支援サーバ側で
的確に把握することができる。
【００３０】本発明の第１５の形態に係る決済支援シス
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバと、購入に伴う決済を支援する決済支
援サーバとを備え、購入受付サーバは、購入に伴う決済
を要求したユーザに対する与信枠を確保するよう要求す
るための要求情報を決済支援サーバに送信する第１の要
求送信部と、要求に対する応答情報を決済支援サーバか
ら受信する第１の応答受信部と、応答情報の受信状況を
決済支援サーバへ通知する受信状況通知部とを含み、決
済支援サーバは、購入受付サーバから要求情報を受け付
ける要求受付部と、要求情報を、決済処理を行う決済処
理サーバへ送信する第２の要求送信部と、要求に対する
応答情報を決済処理サーバから受信する第２の応答受信
部と、応答情報を購入受付サーバへ送信する応答送信部
と、受信状況を取得する購入受付サーバから受信状況取
得部とを含む。
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバと、購入に伴う決済を支援する決済支
援サーバとを備え、購入受付サーバは、購入に伴う決済
を要求したユーザに対する与信枠を確保するよう要求す
るための要求情報を決済支援サーバに送信する第１の要
求送信部と、要求に対する応答情報を決済支援サーバか
ら受信する第１の応答受信部と、応答情報の受信状況を
決済支援サーバへ通知する受信状況通知部とを含み、決
済支援サーバは、購入受付サーバから要求情報を受け付
ける要求受付部と、要求情報を、決済処理を行う決済処
理サーバへ送信する第２の要求送信部と、要求に対する
応答情報を決済処理サーバから受信する第２の応答受信
部と、応答情報を購入受付サーバへ送信する応答送信部
と、受信状況を取得する購入受付サーバから受信状況取
得部とを含む。
【００３１】受信状況通知部は、第１の応答受信部が応
答情報を受信したときに、その旨を決済支援サーバへ通
知してもよい。第１の応答受信部は、第１の時間が経過
しても応答情報を受信しなかったときに、応答送信部に
応答情報の送信を要求してもよい。受信状況通知部は、
第２の時間が経過しても第１の応答受信部が応答情報を
受信しなかったときに、その旨を決済支援サーバへ通知
してもよい。決済支援サーバは、受信状況通知部から、
応答情報を受信しなかった旨の通知を取得したときに、
決済処理サーバに、確保された与信枠を解放するよう要
求してもよい。購入受付サーバは、第２の時間が経過し
ても第１の応答受信部が応答情報を受信しなかったとき
に、その決済の要求を取り消すか否かを判断する第１の
判断部をさらに含み、受信状況通知部は、第１の判断部
が決済の要求を取り消すと判断したときに、その旨を決
済支援サーバへ通知してもよい。決済支援サーバは、受
信状況通知部から、決済の要求を取り消す旨の通知を取
得したときに、決済処理サーバに、確保された与信枠を
解放するよう要求してもよい。
答情報を受信したときに、その旨を決済支援サーバへ通
知してもよい。第１の応答受信部は、第１の時間が経過
しても応答情報を受信しなかったときに、応答送信部に
応答情報の送信を要求してもよい。受信状況通知部は、
第２の時間が経過しても第１の応答受信部が応答情報を
受信しなかったときに、その旨を決済支援サーバへ通知
してもよい。決済支援サーバは、受信状況通知部から、
応答情報を受信しなかった旨の通知を取得したときに、
決済処理サーバに、確保された与信枠を解放するよう要
求してもよい。購入受付サーバは、第２の時間が経過し
ても第１の応答受信部が応答情報を受信しなかったとき
に、その決済の要求を取り消すか否かを判断する第１の
判断部をさらに含み、受信状況通知部は、第１の判断部
が決済の要求を取り消すと判断したときに、その旨を決
済支援サーバへ通知してもよい。決済支援サーバは、受
信状況通知部から、決済の要求を取り消す旨の通知を取
得したときに、決済処理サーバに、確保された与信枠を
解放するよう要求してもよい。
【００３２】決済支援サーバは、第３の時間が経過して
も受信状況取得部が受信状況を受信しなかったときに、
決済処理サーバに、確保された与信枠を解放するよう要
求してもよい。決済支援サーバは、第３の時間が経過し
ても受信状況取得部が受信状況を受信しなかったとき
に、決済処理サーバに確保された与信枠を解放するよう
要求するか否かを判断する第２の判断部をさらに含み、
第２の判断部が要求すると判断したときに、決済処理サ
ーバに、確保された与信枠を解放するよう要求してもよ
い。決済支援サーバは、第３の時間が経過しても受信状
況取得部が受信状況を受信しなかった決済の情報を出力
する出力部をさらに備えてもよい。出力された情報は、
購入受付サーバが保持している決済の情報と比較され、
不整合の有無を確認するために用いられてもよい。
も受信状況取得部が受信状況を受信しなかったときに、
決済処理サーバに、確保された与信枠を解放するよう要
求してもよい。決済支援サーバは、第３の時間が経過し
ても受信状況取得部が受信状況を受信しなかったとき
に、決済処理サーバに確保された与信枠を解放するよう
要求するか否かを判断する第２の判断部をさらに含み、
第２の判断部が要求すると判断したときに、決済処理サ
ーバに、確保された与信枠を解放するよう要求してもよ
い。決済支援サーバは、第３の時間が経過しても受信状
況取得部が受信状況を受信しなかった決済の情報を出力
する出力部をさらに備えてもよい。出力された情報は、
購入受付サーバが保持している決済の情報と比較され、
不整合の有無を確認するために用いられてもよい。
【００３３】決済支援サーバは、第３の時間が経過して
も受信状況取得部が受信状況を受信しなかった決済につ
いて、与信枠が確保されており、かつ、購入受付サーバ
が応答情報を受信していたことを示す確認情報を取得し
たときに、決済が成功したものとして処理してもよい。
決済支援サーバは、第３の時間が経過しても受信状況取
得部が受信状況を受信しなかった決済について、与信枠
を確保できたにも関わらず、購入受付サーバが応答情報
を受信していなかったことを示す確認情報を取得したと
きに、決済処理サーバに、確保された与信枠を解放する
よう要求してもよい。決済支援サーバは、第３の時間が
経過しても受信状況取得部が受信状況を受信しなかった
決済について、与信枠を確保できたにも関わらず、購入
受付サーバが応答情報を受信していなかったことを示す
確認情報を取得したときに、与信枠の確保を維持するか
否かを購入受付サーバに問い合わせてもよい。購入受付
サーバから与信枠の確保を維持すべき旨の回答を取得し
たときに、決済が成功したものとして処理してもよい。
購入受付サーバから与信枠を解放すべき旨の回答を取得
したときに、決済処理サーバに、確保された与信枠を解
放するよう要求してもよい。
も受信状況取得部が受信状況を受信しなかった決済につ
いて、与信枠が確保されており、かつ、購入受付サーバ
が応答情報を受信していたことを示す確認情報を取得し
たときに、決済が成功したものとして処理してもよい。
決済支援サーバは、第３の時間が経過しても受信状況取
得部が受信状況を受信しなかった決済について、与信枠
を確保できたにも関わらず、購入受付サーバが応答情報
を受信していなかったことを示す確認情報を取得したと
きに、決済処理サーバに、確保された与信枠を解放する
よう要求してもよい。決済支援サーバは、第３の時間が
経過しても受信状況取得部が受信状況を受信しなかった
決済について、与信枠を確保できたにも関わらず、購入
受付サーバが応答情報を受信していなかったことを示す
確認情報を取得したときに、与信枠の確保を維持するか
否かを購入受付サーバに問い合わせてもよい。購入受付
サーバから与信枠の確保を維持すべき旨の回答を取得し
たときに、決済が成功したものとして処理してもよい。
購入受付サーバから与信枠を解放すべき旨の回答を取得
したときに、決済処理サーバに、確保された与信枠を解
放するよう要求してもよい。
【００３４】本発明の第１６の形態に係る決済支援シス
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバを備え、購入に伴う決済を要求したユ
ーザに対する与信枠を確保するよう要求するための要求
情報を生成して、決済を支援する決済支援サーバへ送信
する要求送信部と、要求に対する応答情報を決済支援サ
ーバから受信する応答受信部と、応答情報の受信状況を
決済支援サーバへ通知する受信状況通知部とを含む。
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバを備え、購入に伴う決済を要求したユ
ーザに対する与信枠を確保するよう要求するための要求
情報を生成して、決済を支援する決済支援サーバへ送信
する要求送信部と、要求に対する応答情報を決済支援サ
ーバから受信する応答受信部と、応答情報の受信状況を
決済支援サーバへ通知する受信状況通知部とを含む。
【００３５】本発明の第１７の形態に係る決済支援方法
は、ユーザから商品又は役務の購入に伴う決済要求を受
け付けたときに、そのユーザに対する与信枠を確保する
よう要求するための要求情報を生成して、決済を支援す
る決済支援サーバへ送信する工程と、要求に対する応答
情報を決済支援サーバから受信する工程と、応答情報の
受信状況を決済支援サーバへ通知する工程とを含む。
は、ユーザから商品又は役務の購入に伴う決済要求を受
け付けたときに、そのユーザに対する与信枠を確保する
よう要求するための要求情報を生成して、決済を支援す
る決済支援サーバへ送信する工程と、要求に対する応答
情報を決済支援サーバから受信する工程と、応答情報の
受信状況を決済支援サーバへ通知する工程とを含む。
【００３６】本発明の第１８の形態に係るプログラム
は、コンピュータに、ユーザから商品又は役務の購入に
伴う決済要求を受け付けたときに、そのユーザに対する
与信枠を確保するよう要求するための要求情報を生成し
て、決済を支援する決済支援サーバへ送信する機能と、
要求に対する応答情報を決済支援サーバから受信する機
能と、応答情報の受信状況を決済支援サーバへ通知する
機能とを実現させる。
は、コンピュータに、ユーザから商品又は役務の購入に
伴う決済要求を受け付けたときに、そのユーザに対する
与信枠を確保するよう要求するための要求情報を生成し
て、決済を支援する決済支援サーバへ送信する機能と、
要求に対する応答情報を決済支援サーバから受信する機
能と、応答情報の受信状況を決済支援サーバへ通知する
機能とを実現させる。
【００３７】本発明の第１９の形態に係る決済支援シス
テムは、商品または役務の購入に伴う決済を支援する決
済支援サーバを備え、商品または役務の購入要求を受け
付ける購入受付サーバから、決済を要求したユーザに対
する与信枠を確保するよう要求するための要求情報を受
け付ける要求受付部と、要求情報を、決済処理を行う決
済処理サーバへ送信する要求送信部と、要求に対する応
答情報を決済処理サーバから受信する応答受信部と、応
答情報を購入受付サーバへ送信する応答送信部と、購入
受付サーバから応答情報の受信状況を取得する受信状況
取得部とを含む。
テムは、商品または役務の購入に伴う決済を支援する決
済支援サーバを備え、商品または役務の購入要求を受け
付ける購入受付サーバから、決済を要求したユーザに対
する与信枠を確保するよう要求するための要求情報を受
け付ける要求受付部と、要求情報を、決済処理を行う決
済処理サーバへ送信する要求送信部と、要求に対する応
答情報を決済処理サーバから受信する応答受信部と、応
答情報を購入受付サーバへ送信する応答送信部と、購入
受付サーバから応答情報の受信状況を取得する受信状況
取得部とを含む。
【００３８】本発明の第２０の形態に係る決済支援方法
は、商品または役務の購入要求を受け付ける購入受付サ
ーバから、購入に伴う決済を要求したユーザに対する与
信枠を確保するよう要求するための要求情報を受け付け
る工程と、要求情報を、決済処理を行う決済処理サーバ
へ送信する工程と、要求に対する応答情報を決済処理サ
ーバから受信する工程と、応答情報を購入受付サーバへ
送信する工程と、購入受付サーバから応答情報の受信状
況を取得する工程とを含む。
は、商品または役務の購入要求を受け付ける購入受付サ
ーバから、購入に伴う決済を要求したユーザに対する与
信枠を確保するよう要求するための要求情報を受け付け
る工程と、要求情報を、決済処理を行う決済処理サーバ
へ送信する工程と、要求に対する応答情報を決済処理サ
ーバから受信する工程と、応答情報を購入受付サーバへ
送信する工程と、購入受付サーバから応答情報の受信状
況を取得する工程とを含む。
【００３９】本発明の第２１の形態に係るプログラム
は、コンピュータに、商品または役務の購入要求を受け
付ける購入受付サーバから、購入に伴う決済を要求した
ユーザに対する与信枠を確保するよう要求するための要
求情報を受け付ける機能と、要求情報を、決済処理を行
う決済処理サーバへ送信する機能と、要求に対する応答
情報を決済処理サーバから受信する機能と、応答情報を
購入受付サーバへ送信する機能と、購入受付サーバから
応答情報の受信状況を取得する機能とを実現させる。
は、コンピュータに、商品または役務の購入要求を受け
付ける購入受付サーバから、購入に伴う決済を要求した
ユーザに対する与信枠を確保するよう要求するための要
求情報を受け付ける機能と、要求情報を、決済処理を行
う決済処理サーバへ送信する機能と、要求に対する応答
情報を決済処理サーバから受信する機能と、応答情報を
購入受付サーバへ送信する機能と、購入受付サーバから
応答情報の受信状況を取得する機能とを実現させる。
【００４０】本発明の第２２の形態に係る決済支援方法
は、商品又は役務の購入要求を受け付ける購入受付サー
バが、既に要求した決済の金額を変更するよう要求する
ための金額変更要求情報を生成して、決済を支援する決
済支援サーバへ送信する工程と、決済支援サーバが、購
入受付サーバから金額変更要求情報を受信し、金額変更
要求情報をもとに、既に要求した決済について返品処理
を行うよう、決済処理を行う決済処理サーバへ要求する
工程と、決済処理サーバが、返品処理を行い、その返品
処理に対する返品処理応答情報を生成して、決済支援サ
ーバに送信する工程と、決済支援サーバが、決済処理サ
ーバから返品処理応答情報を受信し、返品処理が成功し
ていたときに、つづいて、金額が変更された新たな決済
を決済処理サーバへ要求する工程と、決済処理サーバ
が、新たな決済処理を行い、その決済処理に対する再売
上応答情報を生成して、決済支援サーバへ送信する工程
と、決済支援サーバが、決済処理サーバから再売上応答
情報を受信し、返品処理応答情報および再売上応答情報
に基づいて、金額変更要求に対する金額変更応答情報を
生成して購入受付サーバへ送信する工程とを含む。
は、商品又は役務の購入要求を受け付ける購入受付サー
バが、既に要求した決済の金額を変更するよう要求する
ための金額変更要求情報を生成して、決済を支援する決
済支援サーバへ送信する工程と、決済支援サーバが、購
入受付サーバから金額変更要求情報を受信し、金額変更
要求情報をもとに、既に要求した決済について返品処理
を行うよう、決済処理を行う決済処理サーバへ要求する
工程と、決済処理サーバが、返品処理を行い、その返品
処理に対する返品処理応答情報を生成して、決済支援サ
ーバに送信する工程と、決済支援サーバが、決済処理サ
ーバから返品処理応答情報を受信し、返品処理が成功し
ていたときに、つづいて、金額が変更された新たな決済
を決済処理サーバへ要求する工程と、決済処理サーバ
が、新たな決済処理を行い、その決済処理に対する再売
上応答情報を生成して、決済支援サーバへ送信する工程
と、決済支援サーバが、決済処理サーバから再売上応答
情報を受信し、返品処理応答情報および再売上応答情報
に基づいて、金額変更要求に対する金額変更応答情報を
生成して購入受付サーバへ送信する工程とを含む。
【００４１】金額変更に必要な、返品処理及び再売上の
要求を、決済支援サーバが代行するので、購入受付サー
バは、金額変更を決済支援サーバに１回要求するだけで
よい。これにより、加盟店側の負担を軽減することがで
きる。
要求を、決済支援サーバが代行するので、購入受付サー
バは、金額変更を決済支援サーバに１回要求するだけで
よい。これにより、加盟店側の負担を軽減することがで
きる。
【００４２】本発明の第２３の形態に係る決済支援シス
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバと、購入に伴う決済を支援する決済支
援サーバとを備え、購入受付サーバは、既に要求した決
済の金額を変更するよう要求するための金額変更要求情
報を生成して決済支援サーバへ送信する金額変更要求送
信部と、金額変更要求情報に対する金額変更応答情報を
決済支援サーバから受信する金額変更応答受信部とを含
み、決済支援サーバは、購入受付サーバから金額変更要
求情報を受け付ける金額変更要求受信部と、既に要求し
た決済について返品処理を行うよう、決済処理を行う決
済処理サーバへ要求する返品処理要求部と、返品処理に
対する返品処理応答情報を決済処理サーバから受信する
返品処理応答受信部と、返品処理が成功したときに、つ
づいて、金額が変更された新たな決済を決済処理サーバ
へ要求する再売上要求部と、新たな決済の要求に対する
再売上応答情報を決済処理サーバから受信する再売上応
答受信部と、返品処理応答情報および再売上応答情報に
基づいて、金額変更応答情報を生成して購入受付サーバ
へ送信する金額変更応答送信部とを含む。
テムは、ユーザから商品又は役務の購入要求を受け付け
る購入受付サーバと、購入に伴う決済を支援する決済支
援サーバとを備え、購入受付サーバは、既に要求した決
済の金額を変更するよう要求するための金額変更要求情
報を生成して決済支援サーバへ送信する金額変更要求送
信部と、金額変更要求情報に対する金額変更応答情報を
決済支援サーバから受信する金額変更応答受信部とを含
み、決済支援サーバは、購入受付サーバから金額変更要
求情報を受け付ける金額変更要求受信部と、既に要求し
た決済について返品処理を行うよう、決済処理を行う決
済処理サーバへ要求する返品処理要求部と、返品処理に
対する返品処理応答情報を決済処理サーバから受信する
返品処理応答受信部と、返品処理が成功したときに、つ
づいて、金額が変更された新たな決済を決済処理サーバ
へ要求する再売上要求部と、新たな決済の要求に対する
再売上応答情報を決済処理サーバから受信する再売上応
答受信部と、返品処理応答情報および再売上応答情報に
基づいて、金額変更応答情報を生成して購入受付サーバ
へ送信する金額変更応答送信部とを含む。
【００４３】金額変更要求情報は、既に要求した決済の
識別情報と、新たな決済の識別情報と、変更後の金額と
を含んでもよい。決済支援サーバは、決済の履歴情報を
格納する履歴データベースをさらに含み、返品処理要求
部は、既に要求した決済の識別情報をもとに、履歴デー
タベースを参照し、既に要求した決済の金額を取得して
もよい。返品処理応答受信部が返品処理に失敗した旨の
返品処理応答情報を受信したときに、その旨を金額変更
応答送信部により購入受付サーバへ送信してもよい。再
売上応答受信部が再売上処理に失敗した旨の再売上応答
情報を受信したときに、その旨を金額変更応答送信部に
より購入受付サーバへ送信するとともに、返品処理を取
り消すよう決済処理サーバへ要求してもよい。
識別情報と、新たな決済の識別情報と、変更後の金額と
を含んでもよい。決済支援サーバは、決済の履歴情報を
格納する履歴データベースをさらに含み、返品処理要求
部は、既に要求した決済の識別情報をもとに、履歴デー
タベースを参照し、既に要求した決済の金額を取得して
もよい。返品処理応答受信部が返品処理に失敗した旨の
返品処理応答情報を受信したときに、その旨を金額変更
応答送信部により購入受付サーバへ送信してもよい。再
売上応答受信部が再売上処理に失敗した旨の再売上応答
情報を受信したときに、その旨を金額変更応答送信部に
より購入受付サーバへ送信するとともに、返品処理を取
り消すよう決済処理サーバへ要求してもよい。
【００４４】本発明の第２４の形態に係る決済支援サー
バは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバから、購入受付サーバが既に要求した決
済の金額を変更するよう要求するための金額変更要求情
報を受け付ける金額変更要求受信部と、既に要求した決
済について返品処理を行うよう、決済処理を行う決済処
理サーバへ要求する返品処理要求部と、返品処理に対す
る返品処理応答情報を決済処理サーバから受信する返品
処理応答受信部と、返品処理が成功したときに、つづい
て、金額が変更された新たな決済を決済処理サーバへ要
求する再売上要求部と、新たな決済の要求に対する再売
上応答情報を決済処理サーバから受信する再売上応答受
信部と、返品処理応答情報および再売上応答情報に基づ
いて、金額変更要求情報に対する金額変更応答情報を生
成して購入受付サーバへ送信する金額変更応答送信部と
を含む。
バは、ユーザから商品又は役務の購入要求を受け付ける
購入受付サーバから、購入受付サーバが既に要求した決
済の金額を変更するよう要求するための金額変更要求情
報を受け付ける金額変更要求受信部と、既に要求した決
済について返品処理を行うよう、決済処理を行う決済処
理サーバへ要求する返品処理要求部と、返品処理に対す
る返品処理応答情報を決済処理サーバから受信する返品
処理応答受信部と、返品処理が成功したときに、つづい
て、金額が変更された新たな決済を決済処理サーバへ要
求する再売上要求部と、新たな決済の要求に対する再売
上応答情報を決済処理サーバから受信する再売上応答受
信部と、返品処理応答情報および再売上応答情報に基づ
いて、金額変更要求情報に対する金額変更応答情報を生
成して購入受付サーバへ送信する金額変更応答送信部と
を含む。
【００４５】本発明の第２５の形態に係る決済支援方法
は、ユーザから商品又は役務の購入要求を受け付ける購
入受付サーバから、購入受付サーバが既に要求した決済
の金額を変更するよう要求するための金額変更要求情報
を受け付ける工程と、既に要求した決済について返品処
理を行うよう、決済処理を行う決済処理サーバへ要求す
る工程と、返品処理に対する返品処理応答情報を決済処
理サーバから受信する工程と、返品処理が成功したとき
に、つづいて、金額が変更された新たな決済を決済処理
サーバへ要求する工程と、新たな決済の要求に対する再
売上応答情報を決済処理サーバから受信する工程と、返
品処理応答情報および再売上応答情報に基づいて、金額
変更要求情報に対する金額変更応答情報を生成して購入
受付サーバへ送信する工程とを含む。
は、ユーザから商品又は役務の購入要求を受け付ける購
入受付サーバから、購入受付サーバが既に要求した決済
の金額を変更するよう要求するための金額変更要求情報
を受け付ける工程と、既に要求した決済について返品処
理を行うよう、決済処理を行う決済処理サーバへ要求す
る工程と、返品処理に対する返品処理応答情報を決済処
理サーバから受信する工程と、返品処理が成功したとき
に、つづいて、金額が変更された新たな決済を決済処理
サーバへ要求する工程と、新たな決済の要求に対する再
売上応答情報を決済処理サーバから受信する工程と、返
品処理応答情報および再売上応答情報に基づいて、金額
変更要求情報に対する金額変更応答情報を生成して購入
受付サーバへ送信する工程とを含む。
【００４６】本発明の第２６の形態に係るプログラム
は、コンピュータに、ユーザから商品又は役務の購入要
求を受け付ける購入受付サーバから、購入受付サーバが
既に要求した決済の金額を変更するよう要求するための
金額変更要求情報を受け付ける機能と、既に要求した決
済について返品処理を行うよう、決済処理を行う決済処
理サーバへ要求する機能と、返品処理に対する返品処理
応答情報を決済処理サーバから受信する機能と、返品処
理が成功したときに、つづいて、金額が変更された新た
な決済を決済処理サーバへ要求する機能と、新たな決済
の要求に対する再売上応答情報を決済処理サーバから受
信する機能と、返品処理応答情報および再売上応答情報
に基づいて、金額変更要求情報に対する金額変更応答情
報を生成して購入受付サーバへ送信する機能とを実現さ
せる。
は、コンピュータに、ユーザから商品又は役務の購入要
求を受け付ける購入受付サーバから、購入受付サーバが
既に要求した決済の金額を変更するよう要求するための
金額変更要求情報を受け付ける機能と、既に要求した決
済について返品処理を行うよう、決済処理を行う決済処
理サーバへ要求する機能と、返品処理に対する返品処理
応答情報を決済処理サーバから受信する機能と、返品処
理が成功したときに、つづいて、金額が変更された新た
な決済を決済処理サーバへ要求する機能と、新たな決済
の要求に対する再売上応答情報を決済処理サーバから受
信する機能と、返品処理応答情報および再売上応答情報
に基づいて、金額変更要求情報に対する金額変更応答情
報を生成して購入受付サーバへ送信する機能とを実現さ
せる。
【００４７】なお、上記の発明の概要は、本発明の必要
な特徴の全てを列挙したものではなく、これらの特徴の
組合せも又発明となりうる。また、本発明の表現を装
置、方法、システム、コンピュータプログラムの間で置
換したものもまた、本発明の態様として有効である。
な特徴の全てを列挙したものではなく、これらの特徴の
組合せも又発明となりうる。また、本発明の表現を装
置、方法、システム、コンピュータプログラムの間で置
換したものもまた、本発明の態様として有効である。
【００４８】
【発明の実施の形態】以下、発明の実施の形態を通じて
本発明を説明するが、以下の実施の形態は特許請求の範
囲に係る発明を限定するものではなく、又実施の形態の
中で説明されている特徴の組合せの全てが発明の解決手
段に必須であるとは限らない。
本発明を説明するが、以下の実施の形態は特許請求の範
囲に係る発明を限定するものではなく、又実施の形態の
中で説明されている特徴の組合せの全てが発明の解決手
段に必須であるとは限らない。
【００４９】（第１の実施の形態）図１は、第１の実施
の形態に係る決済支援システム１０の全体構成を示す。
決済支援システム１０において、ユーザの端末２０、購
入受付サーバ１００、及び決済支援サーバ２００は、そ
れぞれネットワークの一例としてのインターネット３０
に接続されている。また、決済支援サーバ２００及び決
済処理サーバ３００は、ネットワークの一例としての専
用線４０に接続されている。ネットワークとして、ＬＡ
Ｎ（Local Area Network）、ＷＡＮ（Wide Area Networ
k）、その他、有線又は無線の任意の通信手段を利用し
てもよい。本実施の形態では、高い安全性及び機密性を
確保するために、決済支援サーバ２００と決済処理サー
バ３００とを専用線４０により接続している。
の形態に係る決済支援システム１０の全体構成を示す。
決済支援システム１０において、ユーザの端末２０、購
入受付サーバ１００、及び決済支援サーバ２００は、そ
れぞれネットワークの一例としてのインターネット３０
に接続されている。また、決済支援サーバ２００及び決
済処理サーバ３００は、ネットワークの一例としての専
用線４０に接続されている。ネットワークとして、ＬＡ
Ｎ（Local Area Network）、ＷＡＮ（Wide Area Networ
k）、その他、有線又は無線の任意の通信手段を利用し
てもよい。本実施の形態では、高い安全性及び機密性を
確保するために、決済支援サーバ２００と決済処理サー
バ３００とを専用線４０により接続している。
【００５０】購入受付サーバ１００は、ユーザ端末２０
から商品又は役務（以下、簡便のため「商品」で代表さ
せる。）の購入要求を受け付ける。本実施の形態では、
購入受付サーバ１００はウェブサーバとしての機能を有
しており、インターネット３０を介して、自身が提供す
る商品に関する情報を含むウェブページをユーザ端末２
０に配信し、ユーザ端末２０から商品の購入要求及び購
入に伴う決済要求を受け付ける。すなわち、購入受付サ
ーバ１００は、インターネット３０を介した電子商取引
を実現する仮想的な店舗を提供する。
から商品又は役務（以下、簡便のため「商品」で代表さ
せる。）の購入要求を受け付ける。本実施の形態では、
購入受付サーバ１００はウェブサーバとしての機能を有
しており、インターネット３０を介して、自身が提供す
る商品に関する情報を含むウェブページをユーザ端末２
０に配信し、ユーザ端末２０から商品の購入要求及び購
入に伴う決済要求を受け付ける。すなわち、購入受付サ
ーバ１００は、インターネット３０を介した電子商取引
を実現する仮想的な店舗を提供する。
【００５１】決済処理サーバ３００は、商品の購入に伴
う代金の決済処理を行う。決済処理サーバ３００は、ク
レジットカード会社などの消費者与信業者が運営しても
よいし、クレジットカード会社などから決済業務を委託
された業者が運営してもよいし、金融機関が運営しても
よい。本実施の形態では、簡便のため、決済処理サーバ
３００をクレジットカード会社が運営しているものとし
て説明する。決済処理サーバ３００は、決済支援サーバ
２００を介して各購入受付サーバ１００から決済要求を
受け付け、ユーザに対する与信が可能か否かの判断や、
ユーザの与信枠の確保、解放などの処理を行う。
う代金の決済処理を行う。決済処理サーバ３００は、ク
レジットカード会社などの消費者与信業者が運営しても
よいし、クレジットカード会社などから決済業務を委託
された業者が運営してもよいし、金融機関が運営しても
よい。本実施の形態では、簡便のため、決済処理サーバ
３００をクレジットカード会社が運営しているものとし
て説明する。決済処理サーバ３００は、決済支援サーバ
２００を介して各購入受付サーバ１００から決済要求を
受け付け、ユーザに対する与信が可能か否かの判断や、
ユーザの与信枠の確保、解放などの処理を行う。
【００５２】決済支援サーバ２００は、購入受付サーバ
１００から与信照会や与信枠確保などの要求を受け付
け、決済処理サーバ３００との間で必要な処理を代行
し、その結果を購入受付サーバ１００に送信する。決済
処理サーバ３００との間の通信は、上述のＣＡＦＩＳを
利用して行われてもよい。決済支援サーバ２００は、購
入受付サーバ１００と決済処理サーバ３００との間で、
決済に関する処理を仲介するだけでなく、決済に付随す
るさまざまなサービスを購入受付サーバ１００または店
舗の運営主体に提供する。
１００から与信照会や与信枠確保などの要求を受け付
け、決済処理サーバ３００との間で必要な処理を代行
し、その結果を購入受付サーバ１００に送信する。決済
処理サーバ３００との間の通信は、上述のＣＡＦＩＳを
利用して行われてもよい。決済支援サーバ２００は、購
入受付サーバ１００と決済処理サーバ３００との間で、
決済に関する処理を仲介するだけでなく、決済に付随す
るさまざまなサービスを購入受付サーバ１００または店
舗の運営主体に提供する。
【００５３】以下、「ユーザ」というとき、ユーザ自身
とユーザの端末をとくに区別しない。また、「店舗」と
いう語を用いるとき、現実の店舗を意味するときもあ
り、購入受付サーバ１００が提供する仮想的な店舗を意
味するときもあり、双方を区別せずに用いるときもあ
る。また、「店舗」という語を、その店舗の運営主体と
同義に用いることもあり、その店舗で扱われる商品又は
役務の提供主体と同義に用いることもある。
とユーザの端末をとくに区別しない。また、「店舗」と
いう語を用いるとき、現実の店舗を意味するときもあ
り、購入受付サーバ１００が提供する仮想的な店舗を意
味するときもあり、双方を区別せずに用いるときもあ
る。また、「店舗」という語を、その店舗の運営主体と
同義に用いることもあり、その店舗で扱われる商品又は
役務の提供主体と同義に用いることもある。
【００５４】図２は、本実施の形態の決済支援システム
１０における一連の処理の流れを概略的に示す。ユーザ
が購入受付サーバ１００に商品の購入を要求し（Ｓ１０
０）、その商品の購入に伴う決済の方法として、クレジ
ットカードなど、与信照会が必要な決済を要求した場合
（Ｓ１０２）、購入受付サーバ１００は、ユーザからク
レジットカードの番号や有効期限など、与信の照会に必
要な情報を受け付けて照会情報を生成する（Ｓ１０
４）。つづいて、購入受付サーバ１００は、照会情報に
付与すべき符号情報を複数格納したテーブルから、使用
中でない符号情報を読み出して照会情報に付与する（Ｓ
１０６）。このとき、付与した符号情報の使用状況を
「使用中」に設定しておき、以降、その符号情報を利用
できないようにロックする。購入受付サーバ１００は、
符号情報を付与した照会情報を決済支援サーバ２００に
送信する（Ｓ１０８）。決済支援サーバ２００は、購入
受付サーバ１００から受け付けた照会情報を決済処理サ
ーバ３００へ送信する（Ｓ１１０）。
１０における一連の処理の流れを概略的に示す。ユーザ
が購入受付サーバ１００に商品の購入を要求し（Ｓ１０
０）、その商品の購入に伴う決済の方法として、クレジ
ットカードなど、与信照会が必要な決済を要求した場合
（Ｓ１０２）、購入受付サーバ１００は、ユーザからク
レジットカードの番号や有効期限など、与信の照会に必
要な情報を受け付けて照会情報を生成する（Ｓ１０
４）。つづいて、購入受付サーバ１００は、照会情報に
付与すべき符号情報を複数格納したテーブルから、使用
中でない符号情報を読み出して照会情報に付与する（Ｓ
１０６）。このとき、付与した符号情報の使用状況を
「使用中」に設定しておき、以降、その符号情報を利用
できないようにロックする。購入受付サーバ１００は、
符号情報を付与した照会情報を決済支援サーバ２００に
送信する（Ｓ１０８）。決済支援サーバ２００は、購入
受付サーバ１００から受け付けた照会情報を決済処理サ
ーバ３００へ送信する（Ｓ１１０）。
【００５５】決済処理サーバ３００は、決済支援サーバ
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ１１２）、その判断結果を
含む応答情報を生成し（Ｓ１１４）、決済支援サーバ２
００に送信する（Ｓ１１６）。決済支援サーバ２００
は、決済処理サーバ３００から受け付けた応答情報を購
入受付サーバ１００へ送信する（Ｓ１１８）。このと
き、符号情報を参照して、どの購入受付サーバ１００へ
送信すべきかを判断する。購入受付サーバ１００は、決
済支援サーバ２００から応答情報を受信すると、その応
答情報に対応する照会情報に付与されていた符号情報の
使用状況を「非使用中」に設定し、以降、その符号情報
を利用できるよう解放する（Ｓ１２０）。購入受付サー
バ１００は、決済を要求したユーザに応答情報を提示す
る（Ｓ１２２）。以上の手順により、ユーザ及び購入受
付サーバ１００は、クレジットカードによる決済の可否
を知ることができる。
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ１１２）、その判断結果を
含む応答情報を生成し（Ｓ１１４）、決済支援サーバ２
００に送信する（Ｓ１１６）。決済支援サーバ２００
は、決済処理サーバ３００から受け付けた応答情報を購
入受付サーバ１００へ送信する（Ｓ１１８）。このと
き、符号情報を参照して、どの購入受付サーバ１００へ
送信すべきかを判断する。購入受付サーバ１００は、決
済支援サーバ２００から応答情報を受信すると、その応
答情報に対応する照会情報に付与されていた符号情報の
使用状況を「非使用中」に設定し、以降、その符号情報
を利用できるよう解放する（Ｓ１２０）。購入受付サー
バ１００は、決済を要求したユーザに応答情報を提示す
る（Ｓ１２２）。以上の手順により、ユーザ及び購入受
付サーバ１００は、クレジットカードによる決済の可否
を知ることができる。
【００５６】図３は、購入受付サーバ１００、決済支援
サーバ２００、及び決済処理サーバ３００の内部構成を
示す。これらの構成は、ハードウエアコンポーネントで
いえば、任意のコンピュータのＣＰＵ、メモリ、メモリ
にロードされたプログラムなどによって実現されるが、
ここではそれらの連携によって実現される機能ブロック
を描いている。したがって、これらの機能ブロックがハ
ードウエアのみ、ソフトウエアのみ、またはそれらの組
合せによっていろいろな形で実現できることは、当業者
には理解されるところである。
サーバ２００、及び決済処理サーバ３００の内部構成を
示す。これらの構成は、ハードウエアコンポーネントで
いえば、任意のコンピュータのＣＰＵ、メモリ、メモリ
にロードされたプログラムなどによって実現されるが、
ここではそれらの連携によって実現される機能ブロック
を描いている。したがって、これらの機能ブロックがハ
ードウエアのみ、ソフトウエアのみ、またはそれらの組
合せによっていろいろな形で実現できることは、当業者
には理解されるところである。
【００５７】購入受付サーバ１００は、購入要求受付部
１１０、決済要求受付部１１２、応答情報提示部１１
４、照会情報生成部１３０、符号情報付与部１３２、符
号情報格納部１３４、符号情報管理部１３６、照会情報
送信部１５０、及び応答情報受信部１６０を含む。購入
要求受付部１１０は、ユーザ端末２０から商品の購入要
求を受け付ける。決済要求受付部１１２は、ユーザ端末
２０から商品の購入に伴う決済の要求を受け付ける。購
入要求受付部１１０及び決済要求受付部１１２は、購入
又は決済の要求を受け付けるためのウェブページをユー
ザ端末２０に提示し、ＣＧＩ（Common Gateway Interfa
ce）、ＳＳＩ（Server Side Include）などの機能によ
り要求を受け付けてもよい。このとき、ユーザのクレジ
ットカード番号、有効期限、連絡先など、必要な情報を
ユーザから取得する。照会情報生成部１３０は、決済要
求受付部１１２が受け付けた情報をもとに、ユーザに対
する与信の可否を決済処理サーバ３００に照会するため
の照会情報を生成する。
１１０、決済要求受付部１１２、応答情報提示部１１
４、照会情報生成部１３０、符号情報付与部１３２、符
号情報格納部１３４、符号情報管理部１３６、照会情報
送信部１５０、及び応答情報受信部１６０を含む。購入
要求受付部１１０は、ユーザ端末２０から商品の購入要
求を受け付ける。決済要求受付部１１２は、ユーザ端末
２０から商品の購入に伴う決済の要求を受け付ける。購
入要求受付部１１０及び決済要求受付部１１２は、購入
又は決済の要求を受け付けるためのウェブページをユー
ザ端末２０に提示し、ＣＧＩ（Common Gateway Interfa
ce）、ＳＳＩ（Server Side Include）などの機能によ
り要求を受け付けてもよい。このとき、ユーザのクレジ
ットカード番号、有効期限、連絡先など、必要な情報を
ユーザから取得する。照会情報生成部１３０は、決済要
求受付部１１２が受け付けた情報をもとに、ユーザに対
する与信の可否を決済処理サーバ３００に照会するため
の照会情報を生成する。
【００５８】符号情報格納部１３４は、照会情報に付与
するための符号情報を複数格納する。図４はその構成例
であり、符号情報欄５００及び使用状況欄５０２が設け
られている。一例として、符号情報「０００１」及び
「０００２」は現在「使用中」であり、符号情報「００
０３」及び「０００４」は現在「非使用中」であること
が記録されている。符号情報は、照会情報の送信元を識
別するための端末識別番号であってもよい。符号情報格
納部１３４に格納される符号情報は、商品の提供主体が
契約したクレジットカード会社又は決済支援サーバの運
営主体により、予め割り当てられてもよい。割り当てら
れる符号情報の数は、その店舗から要求される与信照会
の頻度に応じて定められてもよい。
するための符号情報を複数格納する。図４はその構成例
であり、符号情報欄５００及び使用状況欄５０２が設け
られている。一例として、符号情報「０００１」及び
「０００２」は現在「使用中」であり、符号情報「００
０３」及び「０００４」は現在「非使用中」であること
が記録されている。符号情報は、照会情報の送信元を識
別するための端末識別番号であってもよい。符号情報格
納部１３４に格納される符号情報は、商品の提供主体が
契約したクレジットカード会社又は決済支援サーバの運
営主体により、予め割り当てられてもよい。割り当てら
れる符号情報の数は、その店舗から要求される与信照会
の頻度に応じて定められてもよい。
【００５９】店舗が利用する符号情報を予めクレジット
カード会社に登録しておく必要がある場合は、登録した
符号情報を符号情報格納部１３４に格納する。登録の必
要がない場合は、照会要求の頻度などの状況に応じて、
割り当てる符号情報の数を動的に変更してもよい。たと
えば、１ヶ月ごとに照会要求の頻度を集計し、頻度の高
い店舗に多くの符号情報を割り当て、頻度の低い店舗に
少ない符号情報を割り当ててもよい。符号情報格納部１
３４の更新は、購入受付サーバ１００の図示しない入力
インターフェイスにより運営主体が行ってもよいし、ネ
ットワークを介して決済支援サーバ２００又は決済処理
サーバ３００が行ってもよい。更新の時間間隔を短くと
って、与信照会要求の発生状況をリアルタイムに反映さ
せてもよい。たとえば、タイムセールの実施などの要因
により、一時的に多くのユーザがアクセスして与信照会
処理が集中している店舗に、一時的に多くの符号情報を
割り当てて迅速に与信照会処理が実行できるようにして
もよい。
カード会社に登録しておく必要がある場合は、登録した
符号情報を符号情報格納部１３４に格納する。登録の必
要がない場合は、照会要求の頻度などの状況に応じて、
割り当てる符号情報の数を動的に変更してもよい。たと
えば、１ヶ月ごとに照会要求の頻度を集計し、頻度の高
い店舗に多くの符号情報を割り当て、頻度の低い店舗に
少ない符号情報を割り当ててもよい。符号情報格納部１
３４の更新は、購入受付サーバ１００の図示しない入力
インターフェイスにより運営主体が行ってもよいし、ネ
ットワークを介して決済支援サーバ２００又は決済処理
サーバ３００が行ってもよい。更新の時間間隔を短くと
って、与信照会要求の発生状況をリアルタイムに反映さ
せてもよい。たとえば、タイムセールの実施などの要因
により、一時的に多くのユーザがアクセスして与信照会
処理が集中している店舗に、一時的に多くの符号情報を
割り当てて迅速に与信照会処理が実行できるようにして
もよい。
【００６０】符号情報付与部１３２は、符号情報格納部
１３４に格納された符号情報のうち、使用中でない符号
情報を読み出して照会情報に付与する。符号情報付与部
１３２は、符号情報格納部１３４に格納された全ての符
号情報が使用中であった場合は、いずれかの符号情報が
非使用中になるまで待機し、非使用中となった符号情報
を順次読み出して照会情報に付与する。このとき、ユー
ザ端末２０のウェブブラウザがタイムアウト処理を行う
前に、ユーザ端末２０に応答情報を送信する必要がある
ので、ウェブブラウザのタイムアウト時間よりも短いタ
イムアウト時間を設定しておき、そのタイムアウト時間
が経過すると、他のユーザが与信照会中のため、与信照
会が行えなかった旨の応答情報を、応答情報提示部１１
４を介してユーザ端末２０に提示する。
１３４に格納された符号情報のうち、使用中でない符号
情報を読み出して照会情報に付与する。符号情報付与部
１３２は、符号情報格納部１３４に格納された全ての符
号情報が使用中であった場合は、いずれかの符号情報が
非使用中になるまで待機し、非使用中となった符号情報
を順次読み出して照会情報に付与する。このとき、ユー
ザ端末２０のウェブブラウザがタイムアウト処理を行う
前に、ユーザ端末２０に応答情報を送信する必要がある
ので、ウェブブラウザのタイムアウト時間よりも短いタ
イムアウト時間を設定しておき、そのタイムアウト時間
が経過すると、他のユーザが与信照会中のため、与信照
会が行えなかった旨の応答情報を、応答情報提示部１１
４を介してユーザ端末２０に提示する。
【００６１】照会情報送信部１５０は、符号情報が付与
された照会情報を決済支援サーバ２００に送信する。応
答情報受信部１６０は、決済支援サーバ２００から応答
情報を受信する。応答情報提示部１１４は、応答情報を
ユーザ端末２０に提示する。応答情報受信部１６０は、
照会情報送信部１５０が照会情報を送信してから所定の
時間が経過しても応答情報を受信しなかったときに、決
済支援サーバ２００に応答情報の送信を要求してもよ
い。それでも応答情報を受信できず、所定のタイムアウ
ト時間が経過したときは、応答情報が得られなかった旨
の応答情報を、応答情報提示部１１４を介してユーザ端
末２０に提示する。
された照会情報を決済支援サーバ２００に送信する。応
答情報受信部１６０は、決済支援サーバ２００から応答
情報を受信する。応答情報提示部１１４は、応答情報を
ユーザ端末２０に提示する。応答情報受信部１６０は、
照会情報送信部１５０が照会情報を送信してから所定の
時間が経過しても応答情報を受信しなかったときに、決
済支援サーバ２００に応答情報の送信を要求してもよ
い。それでも応答情報を受信できず、所定のタイムアウ
ト時間が経過したときは、応答情報が得られなかった旨
の応答情報を、応答情報提示部１１４を介してユーザ端
末２０に提示する。
【００６２】符号情報管理部１３６は、符号情報格納部
１３４に格納された符号情報の使用状況を管理する。符
号情報管理部１３６は、符号情報付与部１３２により照
会情報に付与された符号情報の使用状況を「使用中」に
設定し、他の与信照会に利用できないように制限する。
また、応答情報受信部１６０が受信した応答情報に対応
する照会情報に付与されていた符号情報の使用状況を
「非使用中」に設定し、新たな与信照会に利用できるよ
うに解放する。これにより、ある符号情報が付与された
照会情報の処理中に、それと同一の符号情報が付与され
た照会情報を送信することを防ぐことができる。上述の
ように、所定のタイムアウト時間が経過しても応答情報
が得られなかったときに、その応答情報に対応する照会
情報に付与されていた符号情報の使用状況を「非使用
中」に設定してもよい。これにより、応答情報が返って
こない照会情報に付与されていた符号情報の使用制限を
適切に解放することができ、限られた符合情報を効率よ
く使い回すことができる。
１３４に格納された符号情報の使用状況を管理する。符
号情報管理部１３６は、符号情報付与部１３２により照
会情報に付与された符号情報の使用状況を「使用中」に
設定し、他の与信照会に利用できないように制限する。
また、応答情報受信部１６０が受信した応答情報に対応
する照会情報に付与されていた符号情報の使用状況を
「非使用中」に設定し、新たな与信照会に利用できるよ
うに解放する。これにより、ある符号情報が付与された
照会情報の処理中に、それと同一の符号情報が付与され
た照会情報を送信することを防ぐことができる。上述の
ように、所定のタイムアウト時間が経過しても応答情報
が得られなかったときに、その応答情報に対応する照会
情報に付与されていた符号情報の使用状況を「非使用
中」に設定してもよい。これにより、応答情報が返って
こない照会情報に付与されていた符号情報の使用制限を
適切に解放することができ、限られた符合情報を効率よ
く使い回すことができる。
【００６３】決済支援サーバ２００は、照会情報受信部
２１０、照会情報送信部２５０、応答情報受信部２６
０、及び応答情報送信部２７０を含む。照会情報受信部
２１０は、購入受付サーバ１００から照会情報を受信す
る。照会情報送信部２５０は、照会情報受信部２１０が
受信した照会情報を、決済処理サーバ３００へ送信す
る。応答情報受信部２６０は、決済処理サーバ３００か
ら応答情報を受信する。応答情報送信部２７０は、応答
情報受信部２６０が受信した応答情報を購入受付サーバ
１００へ送信する。このように、決済支援サーバ２００
は、購入受付サーバ１００から与信照会の依頼を受け付
け、決済処理サーバ３００への与信照会処理を代行し、
その結果を購入受付サーバ１００へ通知する。
２１０、照会情報送信部２５０、応答情報受信部２６
０、及び応答情報送信部２７０を含む。照会情報受信部
２１０は、購入受付サーバ１００から照会情報を受信す
る。照会情報送信部２５０は、照会情報受信部２１０が
受信した照会情報を、決済処理サーバ３００へ送信す
る。応答情報受信部２６０は、決済処理サーバ３００か
ら応答情報を受信する。応答情報送信部２７０は、応答
情報受信部２６０が受信した応答情報を購入受付サーバ
１００へ送信する。このように、決済支援サーバ２００
は、購入受付サーバ１００から与信照会の依頼を受け付
け、決済処理サーバ３００への与信照会処理を代行し、
その結果を購入受付サーバ１００へ通知する。
【００６４】決済処理サーバ３００は、照会情報受付部
３１０、与信可否判断部３２０、ユーザデータベース３
３０、応答情報生成部３４０、及び応答情報送信部３５
０を含む。照会情報受付部３１０は、決済支援サーバ２
００から照会情報を受け付ける。照会情報受付部３１０
は、購入受付サーバ１００又は店舗の端末から直接照会
情報を受け付けてもよい。本実施の形態の照会情報受付
部３１０は、照会情報に付与された符号情報により照会
情報の送信元を識別し、ある符号情報が付与された照会
情報の処理中に、それと同一の符号情報が付与された照
会情報を受信したとき、後に受信した照会情報の受け付
けを拒否する。与信可否判断部３２０は、照会情報受付
部３１０にて受け付けた照会情報をもとに、ユーザデー
タベース３３０を参照して、ユーザに対する与信が可能
か否かを判断する。与信可否判断部３２０は、与信が可
能であったときに、そのユーザの与信枠を確保してもよ
い。ユーザデータベース３３０は、ユーザのクレジット
カードの番号、有効期限、与信枠、利用可否情報などを
格納する。応答情報生成部３４０は、与信可否判断部３
２０による判断結果を含む応答情報を生成する。応答情
報送信部３５０は、応答情報生成部３４０にて生成され
た応答情報を決済支援サーバ２００に送信する。
３１０、与信可否判断部３２０、ユーザデータベース３
３０、応答情報生成部３４０、及び応答情報送信部３５
０を含む。照会情報受付部３１０は、決済支援サーバ２
００から照会情報を受け付ける。照会情報受付部３１０
は、購入受付サーバ１００又は店舗の端末から直接照会
情報を受け付けてもよい。本実施の形態の照会情報受付
部３１０は、照会情報に付与された符号情報により照会
情報の送信元を識別し、ある符号情報が付与された照会
情報の処理中に、それと同一の符号情報が付与された照
会情報を受信したとき、後に受信した照会情報の受け付
けを拒否する。与信可否判断部３２０は、照会情報受付
部３１０にて受け付けた照会情報をもとに、ユーザデー
タベース３３０を参照して、ユーザに対する与信が可能
か否かを判断する。与信可否判断部３２０は、与信が可
能であったときに、そのユーザの与信枠を確保してもよ
い。ユーザデータベース３３０は、ユーザのクレジット
カードの番号、有効期限、与信枠、利用可否情報などを
格納する。応答情報生成部３４０は、与信可否判断部３
２０による判断結果を含む応答情報を生成する。応答情
報送信部３５０は、応答情報生成部３４０にて生成され
た応答情報を決済支援サーバ２００に送信する。
【００６５】図５は、本実施の形態の決済支援システム
１０の機能を現実の店舗にたとえて表現した図である。
購入受付サーバ１００は、電子商取引を実現する仮想店
舗を提供する。購入要求受付部１１０は、商品の情報を
ウェブページによりユーザに提示し、商品の購入要求を
受け付ける仮想の売り場１８０に相当し、決済要求受付
部１１２は、決済要求を受け付ける仮想の決済受付窓口
１８２に相当する。さらに、符号情報格納部１３４に格
納された符号情報の数だけ、仮想のＣＡＴ端末１８４が
実現される。それぞれの仮想ＣＡＴ端末１８４には、符
号情報の一例としての端末識別番号が割り当てられてお
り、現実のＣＡＴ端末と同様に、一度に一つの与信照会
要求を送信することができる。符号情報付与部１３２の
機能は、空いている仮想ＣＡＴ端末１８４を選択して与
信照会を依頼することに相当する。与信照会を行うユー
ザの数が、仮想ＣＡＴ端末１８４の数、すなわち符号情
報格納部１３４に格納された端末識別番号の数を超えた
ときは、仮想決済受付窓口１８２にてユーザを待機さ
せ、空いた仮想ＣＡＴ端末１８４を順次使用して与信照
会を行う。
１０の機能を現実の店舗にたとえて表現した図である。
購入受付サーバ１００は、電子商取引を実現する仮想店
舗を提供する。購入要求受付部１１０は、商品の情報を
ウェブページによりユーザに提示し、商品の購入要求を
受け付ける仮想の売り場１８０に相当し、決済要求受付
部１１２は、決済要求を受け付ける仮想の決済受付窓口
１８２に相当する。さらに、符号情報格納部１３４に格
納された符号情報の数だけ、仮想のＣＡＴ端末１８４が
実現される。それぞれの仮想ＣＡＴ端末１８４には、符
号情報の一例としての端末識別番号が割り当てられてお
り、現実のＣＡＴ端末と同様に、一度に一つの与信照会
要求を送信することができる。符号情報付与部１３２の
機能は、空いている仮想ＣＡＴ端末１８４を選択して与
信照会を依頼することに相当する。与信照会を行うユー
ザの数が、仮想ＣＡＴ端末１８４の数、すなわち符号情
報格納部１３４に格納された端末識別番号の数を超えた
ときは、仮想決済受付窓口１８２にてユーザを待機さ
せ、空いた仮想ＣＡＴ端末１８４を順次使用して与信照
会を行う。
【００６６】上記の通り、本実施の形態の決済支援シス
テム１０では、符号情報格納部１３４に複数の符号情報
を格納しておき、それらのうち使用中でないものを順次
照会情報に付与して送信することで、同時に複数の与信
照会要求を並列に処理することができる。これにより、
与信照会を迅速に行うことができ、与信照会の際のユー
ザの待ち時間を減らすことができる。また、与信照会の
頻度に合わせて符号情報を割り当てることにより、限ら
れた数の符号情報を効率よく利用することができる。さ
らに、購入受付サーバ１００側が符号情報の付与を担当
し、購入受付サーバ１００ごとに同時並行処理を実現す
ることができるので、必要な処理を分散させ、決済支援
サーバ２００側の負担を軽減することができる。
テム１０では、符号情報格納部１３４に複数の符号情報
を格納しておき、それらのうち使用中でないものを順次
照会情報に付与して送信することで、同時に複数の与信
照会要求を並列に処理することができる。これにより、
与信照会を迅速に行うことができ、与信照会の際のユー
ザの待ち時間を減らすことができる。また、与信照会の
頻度に合わせて符号情報を割り当てることにより、限ら
れた数の符号情報を効率よく利用することができる。さ
らに、購入受付サーバ１００側が符号情報の付与を担当
し、購入受付サーバ１００ごとに同時並行処理を実現す
ることができるので、必要な処理を分散させ、決済支援
サーバ２００側の負担を軽減することができる。
【００６７】（第２の実施の形態）つづいて、第２の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、ユーザが購入
する商品の種類や、ユーザの属性情報に応じて定められ
た符号情報を照会情報に付与する。本実施の形態の決済
支援システム１０の全体構成は、図１に示した第１の実
施の形態の決済支援システム１０と同様である。また、
決済支援サーバ２００及び決済処理サーバ３００の内部
構成も、図３に示した第１の実施の形態の決済支援サー
バ２００及び決済処理サーバ３００と同様である。購入
受付サーバ１００の内部構成のうち、図３に示した第１
の実施の形態の購入受付サーバ１００と異なる点につい
て説明する。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、ユーザが購入
する商品の種類や、ユーザの属性情報に応じて定められ
た符号情報を照会情報に付与する。本実施の形態の決済
支援システム１０の全体構成は、図１に示した第１の実
施の形態の決済支援システム１０と同様である。また、
決済支援サーバ２００及び決済処理サーバ３００の内部
構成も、図３に示した第１の実施の形態の決済支援サー
バ２００及び決済処理サーバ３００と同様である。購入
受付サーバ１００の内部構成のうち、図３に示した第１
の実施の形態の購入受付サーバ１００と異なる点につい
て説明する。
【００６８】図６は、本実施の形態の符号情報格納部１
３４の構成例であり、符号情報欄５００、使用状況欄５
０２、商品種別欄５０４、及びユーザ属性欄５０６が設
けられている。一例として、符号情報「０００１」は、
現在「使用中」であり、商品種別が「本」でユーザ属性
が「男性」である照会情報に付与されることが記録され
ている。
３４の構成例であり、符号情報欄５００、使用状況欄５
０２、商品種別欄５０４、及びユーザ属性欄５０６が設
けられている。一例として、符号情報「０００１」は、
現在「使用中」であり、商品種別が「本」でユーザ属性
が「男性」である照会情報に付与されることが記録され
ている。
【００６９】符号情報付与部１３２は、照会情報生成部
１３０が生成した照会情報を参照し、商品種別とユーザ
属性情報に基づいて、その照会情報に付与すべき符号情
報を決定する。たとえば、図６の例では、商品種別が
「家具」である照会情報には、符号情報「０００４」を
付与するが、これは現在「非使用中」であるから、符号
情報付与部１３２は照会情報に符号情報「０００４」を
付与して照会情報送信部１５０に送る。また、商品種別
が「本」であり、ユーザ属性情報が「女性」である照会
情報には、符号情報「０００３」を付与するが、これは
現在「使用中」であるから、その照会が終了して符号情
報「０００３」が「非使用中」になるまで待機する。そ
の他の構成及び動作は、第１の実施の形態と同様であ
る。
１３０が生成した照会情報を参照し、商品種別とユーザ
属性情報に基づいて、その照会情報に付与すべき符号情
報を決定する。たとえば、図６の例では、商品種別が
「家具」である照会情報には、符号情報「０００４」を
付与するが、これは現在「非使用中」であるから、符号
情報付与部１３２は照会情報に符号情報「０００４」を
付与して照会情報送信部１５０に送る。また、商品種別
が「本」であり、ユーザ属性情報が「女性」である照会
情報には、符号情報「０００３」を付与するが、これは
現在「使用中」であるから、その照会が終了して符号情
報「０００３」が「非使用中」になるまで待機する。そ
の他の構成及び動作は、第１の実施の形態と同様であ
る。
【００７０】再び図５を用いて、本実施の形態の決済支
援システム１０を現実の店舗と対比して説明すると、商
品種類ごとに付与する符号情報を変えることは、商品種
類により分別された売り場ごとにＣＡＴ端末を設けるこ
とに相当する。また、ユーザの属性情報ごとに付与する
符号情報を変えることは、ユーザの属性情報ごとに専用
のＣＡＴ端末を設けることに相当する。これにより、符
号情報、すなわち仮想端末ごとに売上を集計すること
で、商品別の売上状況や、ユーザ属性別の売上状況を把
握することができ、売上の管理が容易となる。また、こ
れらの情報をマーケティングに利用することもできる。
符号情報と、商品種類又はユーザ属性情報との対応は、
予め固定的に定められてもよいし、与信照会の頻度に応
じて動的に変更されてもよい。たとえば、「本」の購入
に伴う決済要求の頻度が高い場合は、商品種類「本」に
対応する符号情報の数を多くしてもよい。これは、現実
の店舗でいうと、「本」の売り場のＣＡＴ端末を増やす
ことに相当する。
援システム１０を現実の店舗と対比して説明すると、商
品種類ごとに付与する符号情報を変えることは、商品種
類により分別された売り場ごとにＣＡＴ端末を設けるこ
とに相当する。また、ユーザの属性情報ごとに付与する
符号情報を変えることは、ユーザの属性情報ごとに専用
のＣＡＴ端末を設けることに相当する。これにより、符
号情報、すなわち仮想端末ごとに売上を集計すること
で、商品別の売上状況や、ユーザ属性別の売上状況を把
握することができ、売上の管理が容易となる。また、こ
れらの情報をマーケティングに利用することもできる。
符号情報と、商品種類又はユーザ属性情報との対応は、
予め固定的に定められてもよいし、与信照会の頻度に応
じて動的に変更されてもよい。たとえば、「本」の購入
に伴う決済要求の頻度が高い場合は、商品種類「本」に
対応する符号情報の数を多くしてもよい。これは、現実
の店舗でいうと、「本」の売り場のＣＡＴ端末を増やす
ことに相当する。
【００７１】上記の通り、本実施の形態の決済支援シス
テム１０によれば、同時に複数の与信照会を並列に処理
できるとともに、主に店舗側における決済データの管理
の効率を向上させることができる。
テム１０によれば、同時に複数の与信照会を並列に処理
できるとともに、主に店舗側における決済データの管理
の効率を向上させることができる。
【００７２】（第３の実施の形態）つづいて、第３の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、一つの購入受
付サーバ１００内に複数の仮想店舗が設けられている。
本実施の形態の決済支援システム１０の全体構成は、図
１に示した第１の実施の形態の決済支援システム１０と
同様である。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、一つの購入受
付サーバ１００内に複数の仮想店舗が設けられている。
本実施の形態の決済支援システム１０の全体構成は、図
１に示した第１の実施の形態の決済支援システム１０と
同様である。
【００７３】図７は、第３の実施の形態に係る購入受付
サーバ１００、決済支援サーバ２００、及び決済処理サ
ーバ３００の内部構成を示す。本実施の形態の決済支援
サーバ２００及び決済処理サーバ３００の内部構成は、
図３に示した第１の実施の形態の決済支援サーバ２００
及び決済処理サーバ３００と同様である。購入受付サー
バ１００の内部構成のうち、図３に示した第１の実施の
形態の購入受付サーバ１００と異なる点について説明す
る。
サーバ１００、決済支援サーバ２００、及び決済処理サ
ーバ３００の内部構成を示す。本実施の形態の決済支援
サーバ２００及び決済処理サーバ３００の内部構成は、
図３に示した第１の実施の形態の決済支援サーバ２００
及び決済処理サーバ３００と同様である。購入受付サー
バ１００の内部構成のうち、図３に示した第１の実施の
形態の購入受付サーバ１００と異なる点について説明す
る。
【００７４】本実施の形態では、購入要求受付部１１０
が複数設けられている。それぞれの購入要求受付部１１
０は、独立した仮想店舗の売り場として機能する。たと
えば、購入要求受付部１１０ａは、店舗Ａの扱う商品の
情報を提示して、その商品の購入要求を受け付け、購入
要求受付部１１０ｂは、店舗Ｂの扱う商品の情報を提示
して、その商品の購入要求を受け付ける。それぞれの仮
想店舗においてクレジットカードによる決済を希望する
ユーザがいれば、決済要求受付部１１２にて必要な情報
を受け付ける。本実施の形態では、各仮想店舗が共通し
て利用する一つの決済要求受付部１１２を設けている
が、別の例においては、決済要求受付部１１２も仮想店
舗ごとに複数設けられてもよい。
が複数設けられている。それぞれの購入要求受付部１１
０は、独立した仮想店舗の売り場として機能する。たと
えば、購入要求受付部１１０ａは、店舗Ａの扱う商品の
情報を提示して、その商品の購入要求を受け付け、購入
要求受付部１１０ｂは、店舗Ｂの扱う商品の情報を提示
して、その商品の購入要求を受け付ける。それぞれの仮
想店舗においてクレジットカードによる決済を希望する
ユーザがいれば、決済要求受付部１１２にて必要な情報
を受け付ける。本実施の形態では、各仮想店舗が共通し
て利用する一つの決済要求受付部１１２を設けている
が、別の例においては、決済要求受付部１１２も仮想店
舗ごとに複数設けられてもよい。
【００７５】図８は、符号情報格納部１３４の構成例で
あり、符号情報欄５００、使用状況欄５０２、店舗識別
情報欄５０８、及びユーザ識別情報欄５１０が設けられ
ている。一例として、符号情報「０００１」は、店舗
「Ａ」のユーザ「ａ」が「使用中」であり、符号情報
「０００２」は、店舗「Ｂ」のユーザ「ｃ」が「使用
中」であることが記録されている。
あり、符号情報欄５００、使用状況欄５０２、店舗識別
情報欄５０８、及びユーザ識別情報欄５１０が設けられ
ている。一例として、符号情報「０００１」は、店舗
「Ａ」のユーザ「ａ」が「使用中」であり、符号情報
「０００２」は、店舗「Ｂ」のユーザ「ｃ」が「使用
中」であることが記録されている。
【００７６】符号情報付与部１３２は、各仮想店舗にお
いて生成された照会情報に、非使用中の符号情報を順次
付与する。これにより、購入受付サーバ１００が予め確
保して符号情報格納部１３４に格納した符号情報を、各
仮想店舗に動的に割り当てて与信照会を行うことができ
る。符号情報管理部１３６は、符号情報付与部１３２が
照会情報に符号情報を付与したときに、その符号情報の
使用状況欄５０２を「使用中」に設定するとともに、店
舗識別情報欄５０８に照会情報の送信元の店舗の識別情
報を、ユーザ識別情報欄５１０に照会を要求したユーザ
の識別情報を格納する。応答情報受信部１６０は、店舗
識別情報欄５０８及びユーザ識別情報欄５１０を参照し
て、応答情報を提示すべき相手を判断する。符号情報格
納部１３４に、ユーザとのＨＴＴＰ（Hyper Text Trans
fer Protocol）セッションのセッションＩＤを格納して
もよい。
いて生成された照会情報に、非使用中の符号情報を順次
付与する。これにより、購入受付サーバ１００が予め確
保して符号情報格納部１３４に格納した符号情報を、各
仮想店舗に動的に割り当てて与信照会を行うことができ
る。符号情報管理部１３６は、符号情報付与部１３２が
照会情報に符号情報を付与したときに、その符号情報の
使用状況欄５０２を「使用中」に設定するとともに、店
舗識別情報欄５０８に照会情報の送信元の店舗の識別情
報を、ユーザ識別情報欄５１０に照会を要求したユーザ
の識別情報を格納する。応答情報受信部１６０は、店舗
識別情報欄５０８及びユーザ識別情報欄５１０を参照し
て、応答情報を提示すべき相手を判断する。符号情報格
納部１３４に、ユーザとのＨＴＴＰ（Hyper Text Trans
fer Protocol）セッションのセッションＩＤを格納して
もよい。
【００７７】図９は、本実施の形態の決済支援システム
１０の機能を現実の店舗にたとえて表現した図である。
購入受付サーバ１００は、電子商取引を実現する複数の
仮想店舗１８０を提供する。各仮想店舗は、仮想決済受
付窓口１８２を介して与信照会を依頼する。符号情報付
与部１３２は、依頼された与信照会を、依頼元の仮想店
舗に関係なく、空いている仮想ＣＡＴ端末１８４に順次
処理させる。
１０の機能を現実の店舗にたとえて表現した図である。
購入受付サーバ１００は、電子商取引を実現する複数の
仮想店舗１８０を提供する。各仮想店舗は、仮想決済受
付窓口１８２を介して与信照会を依頼する。符号情報付
与部１３２は、依頼された与信照会を、依頼元の仮想店
舗に関係なく、空いている仮想ＣＡＴ端末１８４に順次
処理させる。
【００７８】本実施の形態の決済支援システム１０で
は、各仮想店舗が送信する照会情報に付与される符号情
報は決まっておらず、随時、非使用中の符号情報が付与
される。そのため、クレジットカード会社からは照会情
報を実際に送信した販売主体を識別することができない
ので、購入受付サーバ１００の運営主体が、自身のサー
バを利用して仮想店舗を出店している販売主体を統括し
て管理し、クレジットカード会社に対する取引の窓口と
なってもよい。すなわち、購入受付サーバ１００の運営
主体がクレジットカード会社からの入金を一括して受け
入れ、各販売主体に分配するような仕組みであってもよ
い。
は、各仮想店舗が送信する照会情報に付与される符号情
報は決まっておらず、随時、非使用中の符号情報が付与
される。そのため、クレジットカード会社からは照会情
報を実際に送信した販売主体を識別することができない
ので、購入受付サーバ１００の運営主体が、自身のサー
バを利用して仮想店舗を出店している販売主体を統括し
て管理し、クレジットカード会社に対する取引の窓口と
なってもよい。すなわち、購入受付サーバ１００の運営
主体がクレジットカード会社からの入金を一括して受け
入れ、各販売主体に分配するような仕組みであってもよ
い。
【００７９】上記の通り、本実施の形態の決済支援シス
テム１０によれば、同一のサーバ上に複数の仮想店舗が
出店している、いわゆるショッピングモール型の電子商
取引においても、同時に複数の与信照会を並列に処理す
ることができる。
テム１０によれば、同一のサーバ上に複数の仮想店舗が
出店している、いわゆるショッピングモール型の電子商
取引においても、同時に複数の与信照会を並列に処理す
ることができる。
【００８０】（第４の実施の形態）つづいて、第４の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０においても、一つの
購入受付サーバ１００内に複数の仮想店舗が設けられて
いるが、第３の実施の形態とは異なり、各仮想店舗が利
用可能な符号情報が予め定められている。本実施の形態
の決済支援システム１０の全体構成は、図１に示した第
１の実施の形態の決済支援システム１０と同様であり、
決済支援サーバ２００及び決済処理サーバ３００の内部
構成は、図７に示した第３の実施の形態の構成と同様で
ある。購入受付サーバ１００の内部構成のうち、図７に
示した第３の実施の形態の購入受付サーバ１００と異な
る点について説明する。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０においても、一つの
購入受付サーバ１００内に複数の仮想店舗が設けられて
いるが、第３の実施の形態とは異なり、各仮想店舗が利
用可能な符号情報が予め定められている。本実施の形態
の決済支援システム１０の全体構成は、図１に示した第
１の実施の形態の決済支援システム１０と同様であり、
決済支援サーバ２００及び決済処理サーバ３００の内部
構成は、図７に示した第３の実施の形態の構成と同様で
ある。購入受付サーバ１００の内部構成のうち、図７に
示した第３の実施の形態の購入受付サーバ１００と異な
る点について説明する。
【００８１】図１０は、符号情報格納部１３４の構成例
であり、符号情報欄５００、使用状況欄５０２、店舗識
別情報欄５０８、及びユーザ識別情報欄５１０が設けら
れている。本実施の形態では、店舗識別情報欄５０８の
内容は符号情報が照会情報に付与されるたびに格納され
るのではなく、予め格納されている。すなわち、それぞ
れの符号情報は、利用できる店舗が予め決まっており、
その店舗以外の店舗は利用できない。一例として、符号
情報「０００１」から「０００８」までは、店舗「Ａ」
に割り当てられた符号情報であり、そのうち、符号情報
「０００１」はユーザ「ａ」により「使用中」であり、
符号情報「０００２」はユーザ「ｂ」により「使用中」
であり、符号情報「０００８」は「非使用中」であるこ
とが記録されている。符号情報付与部１３２は、各仮想
店舗において生成された照会情報に、その仮想店舗が利
用可能な符号情報のうち、非使用中のものを順次付与す
る。
であり、符号情報欄５００、使用状況欄５０２、店舗識
別情報欄５０８、及びユーザ識別情報欄５１０が設けら
れている。本実施の形態では、店舗識別情報欄５０８の
内容は符号情報が照会情報に付与されるたびに格納され
るのではなく、予め格納されている。すなわち、それぞ
れの符号情報は、利用できる店舗が予め決まっており、
その店舗以外の店舗は利用できない。一例として、符号
情報「０００１」から「０００８」までは、店舗「Ａ」
に割り当てられた符号情報であり、そのうち、符号情報
「０００１」はユーザ「ａ」により「使用中」であり、
符号情報「０００２」はユーザ「ｂ」により「使用中」
であり、符号情報「０００８」は「非使用中」であるこ
とが記録されている。符号情報付与部１３２は、各仮想
店舗において生成された照会情報に、その仮想店舗が利
用可能な符号情報のうち、非使用中のものを順次付与す
る。
【００８２】図１１は、本実施の形態の決済支援システ
ム１０の機能を現実の店舗にたとえて表現した図であ
る。購入受付サーバ１００は、電子商取引を実現する複
数の仮想店舗１８０を提供する。各仮想店舗は、仮想決
済受付窓口１８２を介して与信照会を依頼する。符号情
報付与部１３２は、依頼された与信照会を、その仮想店
舗が利用可能な仮想ＣＡＴ端末１８４のうち、空いてい
る仮想ＣＡＴ端末１８４に順次処理させる。
ム１０の機能を現実の店舗にたとえて表現した図であ
る。購入受付サーバ１００は、電子商取引を実現する複
数の仮想店舗１８０を提供する。各仮想店舗は、仮想決
済受付窓口１８２を介して与信照会を依頼する。符号情
報付与部１３２は、依頼された与信照会を、その仮想店
舗が利用可能な仮想ＣＡＴ端末１８４のうち、空いてい
る仮想ＣＡＴ端末１８４に順次処理させる。
【００８３】本実施の形態の決済支援システム１０で
は、販売主体ごとに符号情報が予め決められているの
で、これをクレジットカード会社に登録しておくことも
できる。すなわち、販売主体が直接クレジットカード会
社と契約して取引することができる。所定の期間におけ
る与信照会の頻度を仮想店舗ごとに集計し、頻度に応じ
て符号情報の数を割り当て、符号情報格納部１３４を更
新してもよい。このとき、必要であれば、クレジットカ
ード会社に登録した符号情報も変更しておく。
は、販売主体ごとに符号情報が予め決められているの
で、これをクレジットカード会社に登録しておくことも
できる。すなわち、販売主体が直接クレジットカード会
社と契約して取引することができる。所定の期間におけ
る与信照会の頻度を仮想店舗ごとに集計し、頻度に応じ
て符号情報の数を割り当て、符号情報格納部１３４を更
新してもよい。このとき、必要であれば、クレジットカ
ード会社に登録した符号情報も変更しておく。
【００８４】（第５の実施の形態）つづいて、第５の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、購入受付サー
バ１００ではなく、決済支援サーバ２００が照会情報に
符号情報を付与する。本実施の形態の決済支援システム
１０の全体構成は、図１に示した第１の実施の形態の決
済支援システム１０と同様である。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、購入受付サー
バ１００ではなく、決済支援サーバ２００が照会情報に
符号情報を付与する。本実施の形態の決済支援システム
１０の全体構成は、図１に示した第１の実施の形態の決
済支援システム１０と同様である。
【００８５】図１２は、本実施の形態の決済支援システ
ム１０における一連の処理の流れを概略的に示す。ユー
ザが購入受付サーバ１００に商品の購入を要求し（Ｓ１
３０）、その商品の購入に伴う決済の方法として、クレ
ジットカードなど、与信照会が必要な決済を要求した場
合（Ｓ１３２）、購入受付サーバ１００は、ユーザから
クレジットカードの番号や有効期限など、与信の照会に
必要な情報を受け付けて照会情報を生成する（Ｓ１３
４）。つづいて、購入受付サーバ１００は、商品の提供
主体又は購入受付サーバ１００の識別情報とともに、照
会情報を決済支援サーバ２００に送信する（Ｓ１３
６）。決済支援サーバ２００は、照会情報に付与すべき
符号情報を複数格納したテーブルから、使用中でない符
号情報を読み出して照会情報に付与する（Ｓ１３８）。
このとき、付与した符号情報の使用状況を「使用中」に
設定しておき、以降、その符号情報を利用できないよう
にロックする。決済支援サーバ２００は、符号情報を付
与した照会情報を決済処理サーバ３００に送信する（Ｓ
１４０）。
ム１０における一連の処理の流れを概略的に示す。ユー
ザが購入受付サーバ１００に商品の購入を要求し（Ｓ１
３０）、その商品の購入に伴う決済の方法として、クレ
ジットカードなど、与信照会が必要な決済を要求した場
合（Ｓ１３２）、購入受付サーバ１００は、ユーザから
クレジットカードの番号や有効期限など、与信の照会に
必要な情報を受け付けて照会情報を生成する（Ｓ１３
４）。つづいて、購入受付サーバ１００は、商品の提供
主体又は購入受付サーバ１００の識別情報とともに、照
会情報を決済支援サーバ２００に送信する（Ｓ１３
６）。決済支援サーバ２００は、照会情報に付与すべき
符号情報を複数格納したテーブルから、使用中でない符
号情報を読み出して照会情報に付与する（Ｓ１３８）。
このとき、付与した符号情報の使用状況を「使用中」に
設定しておき、以降、その符号情報を利用できないよう
にロックする。決済支援サーバ２００は、符号情報を付
与した照会情報を決済処理サーバ３００に送信する（Ｓ
１４０）。
【００８６】決済処理サーバ３００は、決済支援サーバ
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ１４２）、その判断結果を
含む応答情報を生成し（Ｓ１４４）、決済支援サーバ２
００に送信する（Ｓ１４６）。決済支援サーバ２００
は、決済処理サーバ３００から応答情報を受信すると、
その応答情報に対応する照会情報に付与されていた符号
情報の使用状況を「非使用中」に設定し、以降、その符
号情報を利用できるよう解放する（Ｓ１４８）。決済支
援サーバ２００は、応答情報を購入受付サーバ１００に
送信する（Ｓ１５０）。購入受付サーバ１００は、決済
を要求したユーザに応答情報を提示する（Ｓ１５２）。
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ１４２）、その判断結果を
含む応答情報を生成し（Ｓ１４４）、決済支援サーバ２
００に送信する（Ｓ１４６）。決済支援サーバ２００
は、決済処理サーバ３００から応答情報を受信すると、
その応答情報に対応する照会情報に付与されていた符号
情報の使用状況を「非使用中」に設定し、以降、その符
号情報を利用できるよう解放する（Ｓ１４８）。決済支
援サーバ２００は、応答情報を購入受付サーバ１００に
送信する（Ｓ１５０）。購入受付サーバ１００は、決済
を要求したユーザに応答情報を提示する（Ｓ１５２）。
【００８７】図１３は、本実施の形態に係る購入受付サ
ーバ１００、決済支援サーバ２００、及び決済処理サー
バ３００の内部構成を示す。本実施の形態の決済処理サ
ーバ３００の内部構成は、図３に示した第１の実施の形
態の構成と同様である。本実施の形態の購入受付サーバ
１００では、図３に示した第１の実施の形態の購入受付
サーバ１００から、符号情報付与部１３２、符号情報格
納部１３４、及び符号情報管理部１３６が除かれてい
る。また、本実施の形態の決済支援サーバ２００には、
図３に示した第１の実施の形態の決済支援サーバ２００
の構成に加えて、符号情報付与部２３２、符号情報格納
部２３４、及び符号情報管理部２３６が設けられてい
る。以下、第１の実施の形態と異なる点について説明す
る。
ーバ１００、決済支援サーバ２００、及び決済処理サー
バ３００の内部構成を示す。本実施の形態の決済処理サ
ーバ３００の内部構成は、図３に示した第１の実施の形
態の構成と同様である。本実施の形態の購入受付サーバ
１００では、図３に示した第１の実施の形態の購入受付
サーバ１００から、符号情報付与部１３２、符号情報格
納部１３４、及び符号情報管理部１３６が除かれてい
る。また、本実施の形態の決済支援サーバ２００には、
図３に示した第１の実施の形態の決済支援サーバ２００
の構成に加えて、符号情報付与部２３２、符号情報格納
部２３４、及び符号情報管理部２３６が設けられてい
る。以下、第１の実施の形態と異なる点について説明す
る。
【００８８】照会情報送信部１５０は、照会情報の送信
元である販売主体又は購入受付サーバ１００の識別情報
とともに、照会情報を決済支援サーバ２００に送信す
る。符号情報付与部２３２、符号情報格納部２３４、及
び符号情報管理部２３６の構成及び動作は、それぞれ、
第３の実施の形態の符号情報付与部１３２、符号情報格
納部２３４、及び符号情報管理部２３６と同様である。
符号情報格納部２３４は、図８に示した第３の実施の形
態の符号情報格納部１３４と同様に、複数の符号情報を
格納する。符号情報付与部２３２は、複数の販売主体又
は購入受付サーバ１００から与信照会要求を受け付け、
照会情報の送信元に関係なく、符号情報格納部２３４に
格納された複数の符号情報のうち、使用中でないものを
読み出して付与する。符号情報管理部２３６は、符号情
報付与部２３２が符号情報を照会情報に付与したとき
に、その符号情報の使用状況を「使用中」に設定し、応
答情報受信部２６０が応答情報を受信したとき、又は、
応答情報受信部２６０が応答情報を受信しないまま所定
のタイムアウト時間が経過したときに、その符号情報を
「非使用中」に設定する。なお、応答情報受信部２６０
のタイムアウト時間は、決済支援サーバ２００と購入受
付サーバ１００との間の通信に要する時間を考慮して、
応答情報受信部１６０のタイムアウト時間よりも短く設
定されるのが好ましい。
元である販売主体又は購入受付サーバ１００の識別情報
とともに、照会情報を決済支援サーバ２００に送信す
る。符号情報付与部２３２、符号情報格納部２３４、及
び符号情報管理部２３６の構成及び動作は、それぞれ、
第３の実施の形態の符号情報付与部１３２、符号情報格
納部２３４、及び符号情報管理部２３６と同様である。
符号情報格納部２３４は、図８に示した第３の実施の形
態の符号情報格納部１３４と同様に、複数の符号情報を
格納する。符号情報付与部２３２は、複数の販売主体又
は購入受付サーバ１００から与信照会要求を受け付け、
照会情報の送信元に関係なく、符号情報格納部２３４に
格納された複数の符号情報のうち、使用中でないものを
読み出して付与する。符号情報管理部２３６は、符号情
報付与部２３２が符号情報を照会情報に付与したとき
に、その符号情報の使用状況を「使用中」に設定し、応
答情報受信部２６０が応答情報を受信したとき、又は、
応答情報受信部２６０が応答情報を受信しないまま所定
のタイムアウト時間が経過したときに、その符号情報を
「非使用中」に設定する。なお、応答情報受信部２６０
のタイムアウト時間は、決済支援サーバ２００と購入受
付サーバ１００との間の通信に要する時間を考慮して、
応答情報受信部１６０のタイムアウト時間よりも短く設
定されるのが好ましい。
【００８９】図１４は、本実施の形態の決済支援システ
ム１０の機能を現実の店舗にたとえて表現した図であ
る。購入受付サーバ１００ａ及び１００ｂは、それぞ
れ、電子商取引を実現する仮想店舗１８０ａ及び１８０
ｂを提供する。各仮想店舗は、決済支援サーバ２００の
仮想決済受付窓口２８２を介して与信照会を依頼する。
符号情報付与部２３２は、依頼された与信照会を、依頼
元の仮想店舗に関係なく、空いている仮想ＣＡＴ端末２
８４に順次処理させる。購入受付サーバ１００が複数の
仮想店舗を含む場合も同様である。
ム１０の機能を現実の店舗にたとえて表現した図であ
る。購入受付サーバ１００ａ及び１００ｂは、それぞ
れ、電子商取引を実現する仮想店舗１８０ａ及び１８０
ｂを提供する。各仮想店舗は、決済支援サーバ２００の
仮想決済受付窓口２８２を介して与信照会を依頼する。
符号情報付与部２３２は、依頼された与信照会を、依頼
元の仮想店舗に関係なく、空いている仮想ＣＡＴ端末２
８４に順次処理させる。購入受付サーバ１００が複数の
仮想店舗を含む場合も同様である。
【００９０】上記の通り、本実施の形態の決済支援シス
テム１０によっても、複数の購入受付サーバ１００から
送信された与信照会要求を、同時に並列処理することが
できる。本決済支援システム１０では、決済代行業者の
決済支援サーバ２００が一括して符号情報を管理するの
で、比較的大量の符号情報を扱うことができ、全ての符
号情報が使用中となってユーザが与信照会の順番を待た
なければならない機会を大幅に軽減することができる。
テム１０によっても、複数の購入受付サーバ１００から
送信された与信照会要求を、同時に並列処理することが
できる。本決済支援システム１０では、決済代行業者の
決済支援サーバ２００が一括して符号情報を管理するの
で、比較的大量の符号情報を扱うことができ、全ての符
号情報が使用中となってユーザが与信照会の順番を待た
なければならない機会を大幅に軽減することができる。
【００９１】（第６の実施の形態）つづいて、第６の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０でも、決済支援サー
バ２００が照会情報に符号情報を付与するが、第５の実
施の形態とは異なり、各仮想店舗が利用可能な符号情報
が定められている。本実施の形態の決済支援システム１
０の全体構成は、図１に示した第１の実施の形態の決済
支援システム１０と同様である。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０でも、決済支援サー
バ２００が照会情報に符号情報を付与するが、第５の実
施の形態とは異なり、各仮想店舗が利用可能な符号情報
が定められている。本実施の形態の決済支援システム１
０の全体構成は、図１に示した第１の実施の形態の決済
支援システム１０と同様である。
【００９２】図１５は、本実施の形態の購入受付サーバ
１００、決済支援サーバ２００、及び決済処理サーバ３
００の内部構成を示す。本実施の形態の購入受付サーバ
１００及び決済処理サーバ３００の内部構成は、図１３
に示した第５の実施の形態の構成と同様である。本実施
の形態の決済支援サーバ２００は、図１３に示した第５
の実施の形態の決済支援サーバ２００の構成に加えて、
符号情報変更部２３８が設けられている。
１００、決済支援サーバ２００、及び決済処理サーバ３
００の内部構成を示す。本実施の形態の購入受付サーバ
１００及び決済処理サーバ３００の内部構成は、図１３
に示した第５の実施の形態の構成と同様である。本実施
の形態の決済支援サーバ２００は、図１３に示した第５
の実施の形態の決済支援サーバ２００の構成に加えて、
符号情報変更部２３８が設けられている。
【００９３】本実施の形態の符号情報付与部２３２、符
号情報格納部２３４、及び符号情報管理部２３６の構成
及び動作は、それぞれ、第４の実施の形態の符号情報付
与部１３２、符号情報格納部１３４、及び符号情報管理
部２３６と同様である。すなわち、符号情報格納部２３
４に格納された符号情報は、利用可能な主体が予め定め
られており、符号情報付与部２３２は、照会情報ととも
に取得した識別情報を参照して照会情報の送信元を識別
し、その送信元が利用可能な符号情報のうち、使用中で
ないものを付与する。
号情報格納部２３４、及び符号情報管理部２３６の構成
及び動作は、それぞれ、第４の実施の形態の符号情報付
与部１３２、符号情報格納部１３４、及び符号情報管理
部２３６と同様である。すなわち、符号情報格納部２３
４に格納された符号情報は、利用可能な主体が予め定め
られており、符号情報付与部２３２は、照会情報ととも
に取得した識別情報を参照して照会情報の送信元を識別
し、その送信元が利用可能な符号情報のうち、使用中で
ないものを付与する。
【００９４】図１６は、本実施の形態の決済支援システ
ム１０の機能を現実の店舗にたとえて表現した図であ
る。購入受付サーバ１００ａ及び１００ｂは、それぞ
れ、電子商取引を実現する仮想店舗１８０ａ及び１８０
ｂを提供する。各仮想店舗は、決済支援サーバ２００の
仮想決済受付窓口２８２を介して与信照会を依頼する。
符号情報付与部２３２は、依頼された与信照会を、その
仮想店舗が利用可能な仮想ＣＡＴ端末２８４のうち、空
いている仮想ＣＡＴ端末２８４に順次処理させる。購入
受付サーバ１００が複数の仮想店舗を含む場合も同様で
ある。
ム１０の機能を現実の店舗にたとえて表現した図であ
る。購入受付サーバ１００ａ及び１００ｂは、それぞ
れ、電子商取引を実現する仮想店舗１８０ａ及び１８０
ｂを提供する。各仮想店舗は、決済支援サーバ２００の
仮想決済受付窓口２８２を介して与信照会を依頼する。
符号情報付与部２３２は、依頼された与信照会を、その
仮想店舗が利用可能な仮想ＣＡＴ端末２８４のうち、空
いている仮想ＣＡＴ端末２８４に順次処理させる。購入
受付サーバ１００が複数の仮想店舗を含む場合も同様で
ある。
【００９５】符号情報変更部２３８は、符号情報の利用
状況、すなわち、与信照会の頻度に応じて、それぞれの
主体に割り当てる符号情報を変更し、符号情報格納部２
３４を更新する。図１７は、符号情報変更部２３８によ
り、符号情報の割り当て状況が変更された様子を示す。
仮想店舗Ａに割り当てられた符号情報は、図１６では
「０００１」から「０００８」までであったが、図１７
では「０００１」から「００１０」までに増加してい
る。また、仮想店舗Ｂに割り当てられた符号情報は、図
１６では「０００９」から「００１８」までであった
が、図１７では「００１１」から「００１５」までに減
少している。各店舗が利用する符号情報を予めクレジッ
トカード会社に登録している場合は、符号情報を変更し
たことをクレジットカード会社にも通知しておく。
状況、すなわち、与信照会の頻度に応じて、それぞれの
主体に割り当てる符号情報を変更し、符号情報格納部２
３４を更新する。図１７は、符号情報変更部２３８によ
り、符号情報の割り当て状況が変更された様子を示す。
仮想店舗Ａに割り当てられた符号情報は、図１６では
「０００１」から「０００８」までであったが、図１７
では「０００１」から「００１０」までに増加してい
る。また、仮想店舗Ｂに割り当てられた符号情報は、図
１６では「０００９」から「００１８」までであった
が、図１７では「００１１」から「００１５」までに減
少している。各店舗が利用する符号情報を予めクレジッ
トカード会社に登録している場合は、符号情報を変更し
たことをクレジットカード会社にも通知しておく。
【００９６】上記の通り、本実施の形態の決済支援シス
テム１０によれば、複数の購入受付サーバ１００を介し
て、複数の販売主体から与信照会の依頼を受け付け、依
頼元の販売主体を明確に識別しつつ、同時に複数の与信
照会を並列に処理することができる。
テム１０によれば、複数の購入受付サーバ１００を介し
て、複数の販売主体から与信照会の依頼を受け付け、依
頼元の販売主体を明確に識別しつつ、同時に複数の与信
照会を並列に処理することができる。
【００９７】（第７の実施の形態）つづいて、第７の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、複数の購入受
付サーバ１００を統括的に管理する管理サーバ４００が
新たに設けられている。本実施の形態の決済支援システ
ム１０の全体構成は、図１に示した第１の実施の形態の
決済支援システム１０に加えて、管理サーバ４００がイ
ンターネット３０に接続されている。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０では、複数の購入受
付サーバ１００を統括的に管理する管理サーバ４００が
新たに設けられている。本実施の形態の決済支援システ
ム１０の全体構成は、図１に示した第１の実施の形態の
決済支援システム１０に加えて、管理サーバ４００がイ
ンターネット３０に接続されている。
【００９８】図１８は、本実施の形態の購入受付サーバ
１００、決済支援サーバ２００、決済処理サーバ３０
０、及び管理サーバ４００の内部構成を示す。本実施の
形態の購入受付サーバ１００及び決済処理サーバ３００
の内部構成は、図１３に示した第５の実施の形態の構成
と同様である。本実施の形態の決済支援サーバ２００
は、図３に示した第１の実施の形態の決済支援サーバ２
００と同様である。本実施の形態の管理サーバ４００の
内部構成は、図１３に示した第５の実施の形態の決済支
援サーバ２００の内部構成と同様である。
１００、決済支援サーバ２００、決済処理サーバ３０
０、及び管理サーバ４００の内部構成を示す。本実施の
形態の購入受付サーバ１００及び決済処理サーバ３００
の内部構成は、図１３に示した第５の実施の形態の構成
と同様である。本実施の形態の決済支援サーバ２００
は、図３に示した第１の実施の形態の決済支援サーバ２
００と同様である。本実施の形態の管理サーバ４００の
内部構成は、図１３に示した第５の実施の形態の決済支
援サーバ２００の内部構成と同様である。
【００９９】本実施の形態の決済支援システム１０は、
大型店舗において複数の購入受付サーバ１００を設けて
いる場合や、複数の購入受付サーバ１００にわたるショ
ッピングモール型の電子商取引サイトなどに利用され
る。本決済支援システム１０では、それぞれの購入受付
サーバ１００から送信される照会情報に、管理サーバ４
００が符号情報を付与して決済支援サーバ２００に送信
する。管理サーバ４００の符号情報付与部４３２及び符
号情報格納部４３４の構成及び動作は、第５の実施の形
態と同様に、照会情報の送信元に関係なく符号情報を付
与するようになっていてもよいし、第６の実施の形態と
同様に、照会情報の送信元ごとに利用可能な符号情報が
定められていてもよい。
大型店舗において複数の購入受付サーバ１００を設けて
いる場合や、複数の購入受付サーバ１００にわたるショ
ッピングモール型の電子商取引サイトなどに利用され
る。本決済支援システム１０では、それぞれの購入受付
サーバ１００から送信される照会情報に、管理サーバ４
００が符号情報を付与して決済支援サーバ２００に送信
する。管理サーバ４００の符号情報付与部４３２及び符
号情報格納部４３４の構成及び動作は、第５の実施の形
態と同様に、照会情報の送信元に関係なく符号情報を付
与するようになっていてもよいし、第６の実施の形態と
同様に、照会情報の送信元ごとに利用可能な符号情報が
定められていてもよい。
【０１００】（第８の実施の形態）つづいて、第８の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０は、ユーザから決済
要求を受け付けたときに、ただちに与信照会を行ってそ
の結果をユーザに提示するのではなく、照会情報を蓄積
しておき、所定のタイミングでバッチ処理を行う。本実
施の形態の決済支援システム１０の全体構成は、図１に
示した第１の実施の形態の決済支援システム１０と同様
である。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０は、ユーザから決済
要求を受け付けたときに、ただちに与信照会を行ってそ
の結果をユーザに提示するのではなく、照会情報を蓄積
しておき、所定のタイミングでバッチ処理を行う。本実
施の形態の決済支援システム１０の全体構成は、図１に
示した第１の実施の形態の決済支援システム１０と同様
である。
【０１０１】図１９は、本実施の形態の決済支援システ
ム１０における一連の処理の流れを概略的に示す。ユー
ザが購入受付サーバ１００に商品の購入を要求し（Ｓ１
６０）、その商品の購入に伴う決済の方法として、クレ
ジットカードなど、与信照会が必要な決済を要求した場
合（Ｓ１６２）、購入受付サーバ１００は、ユーザから
クレジットカードの番号や有効期限など、与信の照会に
必要な情報を受け付けて照会情報を生成する（Ｓ１６
４）。生成された照会情報は、いったん保持され（Ｓ１
６６）、バッチ処理開始の時期が到来するまで蓄積され
る。バッチ処理開始のタイミングが到来すると（Ｓ１６
８のＹ）、与信照会の量と、バッチ処理を終了すべき日
時とを考慮して、必要な数だけ符号情報を割り当てる
（Ｓ１７０）。つづいて、購入受付サーバ１００は、蓄
積された照会情報を順次読み出し（Ｓ１７２）、Ｓ１７
０で割り当てられた複数の符号情報のうち、使用中でな
い符号情報を読み出して照会情報に付与する（Ｓ１７
４）。このとき、付与した符号情報の使用状況を「使用
中」に設定しておき、以降、その符号情報を利用できな
いようにロックする。購入受付サーバ１００は、符号情
報を付与した照会情報を決済支援サーバ２００に送信す
る（Ｓ１７６）。決済支援サーバ２００は、購入受付サ
ーバ１００から受け付けた照会情報を決済処理サーバ３
００へ送信する（Ｓ１７８）。
ム１０における一連の処理の流れを概略的に示す。ユー
ザが購入受付サーバ１００に商品の購入を要求し（Ｓ１
６０）、その商品の購入に伴う決済の方法として、クレ
ジットカードなど、与信照会が必要な決済を要求した場
合（Ｓ１６２）、購入受付サーバ１００は、ユーザから
クレジットカードの番号や有効期限など、与信の照会に
必要な情報を受け付けて照会情報を生成する（Ｓ１６
４）。生成された照会情報は、いったん保持され（Ｓ１
６６）、バッチ処理開始の時期が到来するまで蓄積され
る。バッチ処理開始のタイミングが到来すると（Ｓ１６
８のＹ）、与信照会の量と、バッチ処理を終了すべき日
時とを考慮して、必要な数だけ符号情報を割り当てる
（Ｓ１７０）。つづいて、購入受付サーバ１００は、蓄
積された照会情報を順次読み出し（Ｓ１７２）、Ｓ１７
０で割り当てられた複数の符号情報のうち、使用中でな
い符号情報を読み出して照会情報に付与する（Ｓ１７
４）。このとき、付与した符号情報の使用状況を「使用
中」に設定しておき、以降、その符号情報を利用できな
いようにロックする。購入受付サーバ１００は、符号情
報を付与した照会情報を決済支援サーバ２００に送信す
る（Ｓ１７６）。決済支援サーバ２００は、購入受付サ
ーバ１００から受け付けた照会情報を決済処理サーバ３
００へ送信する（Ｓ１７８）。
【０１０２】決済処理サーバ３００は、決済支援サーバ
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ１８０）、その判断結果を
含む応答情報を生成し（Ｓ１８２）、決済支援サーバ２
００に送信する（Ｓ１８４）。決済支援サーバ２００
は、決済処理サーバ３００から受け付けた応答情報を購
入受付サーバ１００へ送信する（Ｓ１８６）。このと
き、符号情報を参照して、どの購入受付サーバ１００へ
送信すべきかを判断する。購入受付サーバ１００は、決
済支援サーバ２００から応答情報を受信すると、その応
答情報に対応する照会情報に付与されていた符号情報の
使用状況を「非使用中」に設定し、以降、その符号情報
を利用できるよう解放する（Ｓ１８８）。バッチ処理が
終了していないときは（Ｓ１９０のＮ）、Ｓ１７２に戻
りバッチ処理を続行する。バッチ処理が終了すると（Ｓ
１９０のＹ）、購入受付サーバ１００は、決済を要求し
たユーザに応答情報を提示する（Ｓ１９２）。ユーザに
対する応答情報の提示は、応答情報を受信するたびに随
時行ってもよいし、バッチ処理が終了してからまとめて
行ってもよい。
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ１８０）、その判断結果を
含む応答情報を生成し（Ｓ１８２）、決済支援サーバ２
００に送信する（Ｓ１８４）。決済支援サーバ２００
は、決済処理サーバ３００から受け付けた応答情報を購
入受付サーバ１００へ送信する（Ｓ１８６）。このと
き、符号情報を参照して、どの購入受付サーバ１００へ
送信すべきかを判断する。購入受付サーバ１００は、決
済支援サーバ２００から応答情報を受信すると、その応
答情報に対応する照会情報に付与されていた符号情報の
使用状況を「非使用中」に設定し、以降、その符号情報
を利用できるよう解放する（Ｓ１８８）。バッチ処理が
終了していないときは（Ｓ１９０のＮ）、Ｓ１７２に戻
りバッチ処理を続行する。バッチ処理が終了すると（Ｓ
１９０のＹ）、購入受付サーバ１００は、決済を要求し
たユーザに応答情報を提示する（Ｓ１９２）。ユーザに
対する応答情報の提示は、応答情報を受信するたびに随
時行ってもよいし、バッチ処理が終了してからまとめて
行ってもよい。
【０１０３】図２０は、本実施の形態の購入受付サーバ
１００、決済支援サーバ２００、及び決済処理サーバ３
００の内部構成を示す。本実施の形態の決済支援サーバ
２００及び決済処理サーバ３００の内部構成は、図３に
示した第１の実施の形態の構成と同様である。本実施の
形態の購入受付サーバ１００は、図３に示した第１の実
施の形態の購入受付サーバ１００の構成に加えて、照会
情報保持部１４０、バッチ処理部１４２が設けられてい
る。
１００、決済支援サーバ２００、及び決済処理サーバ３
００の内部構成を示す。本実施の形態の決済支援サーバ
２００及び決済処理サーバ３００の内部構成は、図３に
示した第１の実施の形態の構成と同様である。本実施の
形態の購入受付サーバ１００は、図３に示した第１の実
施の形態の購入受付サーバ１００の構成に加えて、照会
情報保持部１４０、バッチ処理部１４２が設けられてい
る。
【０１０４】照会情報保持部１４０は、照会情報生成部
１３０にて生成された照会情報を、所定の時期が到来す
るまで蓄積する。バッチ処理部１４２は、所定の時期が
到来したときに、与信照会のためのバッチ処理を開始す
る。バッチ処理の開始に先立って、与信照会の量と、バ
ッチ処理を終了すべき日時とを考慮して、必要な数だけ
符号情報を割り当ててもよい。バッチ処理部１４２は、
照会情報保持部１４０から順次照会情報を読み出し、符
号情報付与部１３２に送る。符号情報付与部１３２は、
符号情報格納部１３４に格納された、バッチ処理用に割
り当てられた符号情報のうち、使用中でないものを読み
出して照会情報に付与する。符号情報付与部１３２は、
利用可能な全ての符号情報が使用中になると、いずれか
の符号情報が非使用中になるまで待機し、非使用中にな
った符号情報から順次、再び照会情報に付与する。その
他の構成及び動作は、第１の実施の形態と同様である。
１３０にて生成された照会情報を、所定の時期が到来す
るまで蓄積する。バッチ処理部１４２は、所定の時期が
到来したときに、与信照会のためのバッチ処理を開始す
る。バッチ処理の開始に先立って、与信照会の量と、バ
ッチ処理を終了すべき日時とを考慮して、必要な数だけ
符号情報を割り当ててもよい。バッチ処理部１４２は、
照会情報保持部１４０から順次照会情報を読み出し、符
号情報付与部１３２に送る。符号情報付与部１３２は、
符号情報格納部１３４に格納された、バッチ処理用に割
り当てられた符号情報のうち、使用中でないものを読み
出して照会情報に付与する。符号情報付与部１３２は、
利用可能な全ての符号情報が使用中になると、いずれか
の符号情報が非使用中になるまで待機し、非使用中にな
った符号情報から順次、再び照会情報に付与する。その
他の構成及び動作は、第１の実施の形態と同様である。
【０１０５】本実施の形態の決済支援システム１０は、
逐次与信照会を実行するのではなく、所定の量、または
所定の期間ごとに、まとめて与信照会を実行したい場合
に利用できる。商品又は役務の種類や、ユーザの属性情
報などに応じて、リアルタイムに与信照会を実行する場
合と、まとめて与信照会を実行する場合を使い分けても
よい。
逐次与信照会を実行するのではなく、所定の量、または
所定の期間ごとに、まとめて与信照会を実行したい場合
に利用できる。商品又は役務の種類や、ユーザの属性情
報などに応じて、リアルタイムに与信照会を実行する場
合と、まとめて与信照会を実行する場合を使い分けても
よい。
【０１０６】上記の通り、本実施の形態の決済支援シス
テム１０によれば、所定のタイミングで与信照会をまと
めて実行することができる。また、必要な数の符号情報
を割り当て、使い終わった符合情報を順次使い回すの
で、迅速かつ効率良く与信照会を実行することができ
る。
テム１０によれば、所定のタイミングで与信照会をまと
めて実行することができる。また、必要な数の符号情報
を割り当て、使い終わった符合情報を順次使い回すの
で、迅速かつ効率良く与信照会を実行することができ
る。
【０１０７】（第９の実施の形態）つづいて、第９の実
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０においても、与信照
会をまとめてバッチ処理するが、第８の実施の形態とは
異なり、購入受付サーバ１００ではなく決済支援サーバ
２００によりバッチ処理が実行される。本実施の形態の
決済支援システム１０の全体構成は、図１に示した第１
の実施の形態の決済支援システム１０と同様である。
施の形態に係る決済支援システムについて説明する。本
実施の形態の決済支援システム１０においても、与信照
会をまとめてバッチ処理するが、第８の実施の形態とは
異なり、購入受付サーバ１００ではなく決済支援サーバ
２００によりバッチ処理が実行される。本実施の形態の
決済支援システム１０の全体構成は、図１に示した第１
の実施の形態の決済支援システム１０と同様である。
【０１０８】図２１は、本実施の形態の決済支援システ
ム１０における一連の処理の流れを概略的に示す。決済
支援サーバ２００は、商品を提供する店舗から、バッチ
処理の依頼を受け（Ｓ２００）、照会情報をまとめて取
得する（Ｓ２０２）。決済支援サーバ２００は、取得し
た照会情報をいったん格納し（Ｓ２０４）、与信照会の
量と、バッチ処理を終了すべき日時とを考慮して、必要
な数だけ符号情報を割り当てる（Ｓ２０６）。つづい
て、決済支援サーバ２００は、保持された照会情報を順
次読み出し（Ｓ２０８）、Ｓ２０６で割り当てられた複
数の符号情報のうち、使用中でない符号情報を読み出し
て照会情報に付与する（Ｓ２１０）。このとき、付与し
た符号情報の使用状況を「使用中」に設定しておき、以
降、その符号情報を利用できないようにロックする。決
済支援サーバ２００は、符号情報を付与した照会情報を
決済処理サーバ３００に送信する（Ｓ２１２）。
ム１０における一連の処理の流れを概略的に示す。決済
支援サーバ２００は、商品を提供する店舗から、バッチ
処理の依頼を受け（Ｓ２００）、照会情報をまとめて取
得する（Ｓ２０２）。決済支援サーバ２００は、取得し
た照会情報をいったん格納し（Ｓ２０４）、与信照会の
量と、バッチ処理を終了すべき日時とを考慮して、必要
な数だけ符号情報を割り当てる（Ｓ２０６）。つづい
て、決済支援サーバ２００は、保持された照会情報を順
次読み出し（Ｓ２０８）、Ｓ２０６で割り当てられた複
数の符号情報のうち、使用中でない符号情報を読み出し
て照会情報に付与する（Ｓ２１０）。このとき、付与し
た符号情報の使用状況を「使用中」に設定しておき、以
降、その符号情報を利用できないようにロックする。決
済支援サーバ２００は、符号情報を付与した照会情報を
決済処理サーバ３００に送信する（Ｓ２１２）。
【０１０９】決済処理サーバ３００は、決済支援サーバ
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ２１４）、その判断結果を
含む応答情報を生成し（Ｓ２１６）、決済支援サーバ２
００に送信する（Ｓ２１８）。決済支援サーバ２００
は、決済処理サーバ３００から応答情報を受信すると、
その応答情報に対応する照会情報に付与されていた符号
情報の使用状況を「非使用中」に設定し、以降、その符
号情報を利用できるよう解放する（Ｓ２２０）。バッチ
処理が終了していないときは（Ｓ２２２のＮ）、Ｓ２０
８に戻りバッチ処理を続行する。バッチ処理が終了する
と（Ｓ２２２のＹ）、決済支援サーバ２００は、応答情
報を所定の出力形式に変換し（Ｓ２２４）、決済を要求
した店舗に応答情報を提示する（Ｓ２２６）。店舗に対
する応答情報の提示は、応答情報を受信するたびに随時
行ってもよいし、バッチ処理が終了してからまとめて行
ってもよい。
２００から受け付けた照会情報に基づいて、ユーザに対
する与信の可否を判断し（Ｓ２１４）、その判断結果を
含む応答情報を生成し（Ｓ２１６）、決済支援サーバ２
００に送信する（Ｓ２１８）。決済支援サーバ２００
は、決済処理サーバ３００から応答情報を受信すると、
その応答情報に対応する照会情報に付与されていた符号
情報の使用状況を「非使用中」に設定し、以降、その符
号情報を利用できるよう解放する（Ｓ２２０）。バッチ
処理が終了していないときは（Ｓ２２２のＮ）、Ｓ２０
８に戻りバッチ処理を続行する。バッチ処理が終了する
と（Ｓ２２２のＹ）、決済支援サーバ２００は、応答情
報を所定の出力形式に変換し（Ｓ２２４）、決済を要求
した店舗に応答情報を提示する（Ｓ２２６）。店舗に対
する応答情報の提示は、応答情報を受信するたびに随時
行ってもよいし、バッチ処理が終了してからまとめて行
ってもよい。
【０１１０】図２２は、本実施の形態の決済支援サーバ
２００及び決済処理サーバ３００の内部構成を示す。本
実施の形態の決済処理サーバ３００の内部構成は、図３
に示した第１の実施の形態の構成と同様である。本実施
の形態の決済支援サーバ２００は、図１３に示した第５
の実施の形態の決済支援サーバ２００の構成に加えて、
照会情報保持部２４０、バッチ処理部２４２が設けられ
ており、照会情報受信部２１０に代えて照会情報受付部
２２０が、応答情報送信部２７０に代えて応答情報変換
部２８０が設けられている。
２００及び決済処理サーバ３００の内部構成を示す。本
実施の形態の決済処理サーバ３００の内部構成は、図３
に示した第１の実施の形態の構成と同様である。本実施
の形態の決済支援サーバ２００は、図１３に示した第５
の実施の形態の決済支援サーバ２００の構成に加えて、
照会情報保持部２４０、バッチ処理部２４２が設けられ
ており、照会情報受信部２１０に代えて照会情報受付部
２２０が、応答情報送信部２７０に代えて応答情報変換
部２８０が設けられている。
【０１１１】照会情報受付部２２０は、店舗から照会情
報をまとめて受け付ける。照会情報は、オンラインにて
受け付けてもよいし、オフラインにて受け付けてもよ
い。既に入力され所定のフォーマットに変換されたデー
タを受け付けてもよいし、店舗から電話、ファックス、
その他任意の手段で入手した情報を図示しない入力イン
ターフェイスを介して入力してもよい。照会情報保持部
２４０は、照会情報受付部２２０にて受け付けた照会情
報を、一時保持する。バッチ処理部２４２は、与信照会
のためのバッチ処理を実行する。バッチ処理の開始に先
立って、与信照会の量と、バッチ処理を終了すべき日時
とを考慮して、必要な数だけ符号情報を割り当ててもよ
い。バッチ処理部２４２は、照会情報保持部２４０から
順次照会情報を読み出し、符号情報付与部２３２に送
る。符号情報付与部２３２は、符号情報格納部２３４に
格納された、バッチ処理用に割り当てられた符号情報の
うち、使用中でないものを読み出して照会情報に付与す
る。符号情報付与部２３２は、利用可能な全ての符号情
報が使用中になると、いずれかの符号情報が非使用中に
なるまで待機し、非使用中になった符号情報から順次、
再び照会情報に付与する。応答情報変換部２８０は、応
答情報受信部２６０が受信した応答情報を、所定の出力
形式に変換する。変換された応答情報は、オンライン又
はオフラインにて店舗へ提供される。その他の構成及び
動作は、第５の実施の形態と同様である。
報をまとめて受け付ける。照会情報は、オンラインにて
受け付けてもよいし、オフラインにて受け付けてもよ
い。既に入力され所定のフォーマットに変換されたデー
タを受け付けてもよいし、店舗から電話、ファックス、
その他任意の手段で入手した情報を図示しない入力イン
ターフェイスを介して入力してもよい。照会情報保持部
２４０は、照会情報受付部２２０にて受け付けた照会情
報を、一時保持する。バッチ処理部２４２は、与信照会
のためのバッチ処理を実行する。バッチ処理の開始に先
立って、与信照会の量と、バッチ処理を終了すべき日時
とを考慮して、必要な数だけ符号情報を割り当ててもよ
い。バッチ処理部２４２は、照会情報保持部２４０から
順次照会情報を読み出し、符号情報付与部２３２に送
る。符号情報付与部２３２は、符号情報格納部２３４に
格納された、バッチ処理用に割り当てられた符号情報の
うち、使用中でないものを読み出して照会情報に付与す
る。符号情報付与部２３２は、利用可能な全ての符号情
報が使用中になると、いずれかの符号情報が非使用中に
なるまで待機し、非使用中になった符号情報から順次、
再び照会情報に付与する。応答情報変換部２８０は、応
答情報受信部２６０が受信した応答情報を、所定の出力
形式に変換する。変換された応答情報は、オンライン又
はオフラインにて店舗へ提供される。その他の構成及び
動作は、第５の実施の形態と同様である。
【０１１２】上記の通り、本実施の形態の決済支援シス
テム１０によれば、第８の実施の形態と同様に、所定の
タイミングで与信照会をまとめて実行することができ
る。また、必要な数の符号情報を割り当て、使い終わっ
た符合情報を順次使い回すので、迅速かつ効率良く与信
照会を実行することができる。また、商品の提供主体
は、決済に必要なシステム等を自身の店舗に導入するこ
となく、決済業務をアウトソーシングすることができる
ので、費用の面からも有用性が高い。
テム１０によれば、第８の実施の形態と同様に、所定の
タイミングで与信照会をまとめて実行することができ
る。また、必要な数の符号情報を割り当て、使い終わっ
た符合情報を順次使い回すので、迅速かつ効率良く与信
照会を実行することができる。また、商品の提供主体
は、決済に必要なシステム等を自身の店舗に導入するこ
となく、決済業務をアウトソーシングすることができる
ので、費用の面からも有用性が高い。
【０１１３】（第１０の実施の形態）つづいて、第１０
の実施の形態に係る決済支援システムについて説明す
る。本実施の形態の決済支援システム１０は、ユーザに
対する与信の可否の照会及び与信枠の確保の要求（以
下、「オーソリ要求」ともいう。）を行ったときに、通
信障害などに起因して発生する処理結果の認識の不整合
を的確に検知するために、購入受付サーバ１００から決
済支援サーバ２００へ、応答情報の受信状況を通知す
る。本実施の形態の決済支援システム１０の全体構成
は、図１に示した第１の実施の形態の決済支援システム
１０と同様である。
の実施の形態に係る決済支援システムについて説明す
る。本実施の形態の決済支援システム１０は、ユーザに
対する与信の可否の照会及び与信枠の確保の要求（以
下、「オーソリ要求」ともいう。）を行ったときに、通
信障害などに起因して発生する処理結果の認識の不整合
を的確に検知するために、購入受付サーバ１００から決
済支援サーバ２００へ、応答情報の受信状況を通知す
る。本実施の形態の決済支援システム１０の全体構成
は、図１に示した第１の実施の形態の決済支援システム
１０と同様である。
【０１１４】図２３は、本実施の形態の決済支援システ
ム１０における一連の処理の流れを概略的に示す。ユー
ザが購入受付サーバ１００に商品の購入を要求し（Ｓ３
００）、その商品の購入に伴う決済の方法として、クレ
ジットカードなど、与信照会が必要な決済を要求した場
合（Ｓ３０２）、購入受付サーバ１００は、ユーザから
クレジットカードの番号や有効期限など、与信の照会に
必要な情報を受け付けてオーソリ要求情報を生成し（Ｓ
３０４）、決済支援サーバ２００に送信する（Ｓ３０
６）。決済支援サーバ２００は、購入受付サーバ１００
から受け付けたオーソリ要求情報を決済処理サーバ３０
０へ送信する（Ｓ３０８）。
ム１０における一連の処理の流れを概略的に示す。ユー
ザが購入受付サーバ１００に商品の購入を要求し（Ｓ３
００）、その商品の購入に伴う決済の方法として、クレ
ジットカードなど、与信照会が必要な決済を要求した場
合（Ｓ３０２）、購入受付サーバ１００は、ユーザから
クレジットカードの番号や有効期限など、与信の照会に
必要な情報を受け付けてオーソリ要求情報を生成し（Ｓ
３０４）、決済支援サーバ２００に送信する（Ｓ３０
６）。決済支援サーバ２００は、購入受付サーバ１００
から受け付けたオーソリ要求情報を決済処理サーバ３０
０へ送信する（Ｓ３０８）。
【０１１５】決済処理サーバ３００は、決済支援サーバ
２００から受け付けたオーソリ要求情報に基づいて、ユ
ーザに対する与信の可否を判断し（Ｓ３１０）、与信が
可能であれば（Ｓ３１０のＹ）、与信枠を確保する（Ｓ
３１２）。与信が不可能であれば（Ｓ３１０のＮ）、Ｓ
３１２をスキップする。決済処理サーバ３００は、オー
ソリ要求に対する応答情報を生成し（Ｓ３１４）、決済
支援サーバ２００に送信する（Ｓ３１６）。決済支援サ
ーバ２００は、決済処理サーバ３００から受け付けた応
答情報を購入受付サーバ１００へ送信する（Ｓ３１
８）。このとき、決済支援サーバ２００は、この決済の
受信確認フラグを「保留」に設定しておく。購入受付サ
ーバ１００は、決済支援サーバ２００から応答情報を受
信すると、決済を要求したユーザに応答情報を提示し
（Ｓ３２０）、決済支援サーバ２００に応答情報を受信
した旨を通知する（Ｓ３２２）。決済支援サーバ２００
がこの受信確認を受け取れた場合は、その決済の受信確
認フラグを「受信済み」に設定する。決済支援サーバ２
００から購入受付サーバ１００への応答情報の送信（Ｓ
３１８）又は購入受付サーバ１００から決済支援サーバ
２００への受信状況の通知（Ｓ３２０）の際に通信障害
が発生した場合は、両者の間で処理結果の認識に不整合
が生じる恐れがある。本実施の形態では、購入受付サー
バ１００が、応答情報を受信したときには受信確認を決
済支援サーバ２００に送信し、応答情報を受信しなかっ
たときには何も送信しない。すなわち、受信確認フラグ
が「保留」のままである決済については、整合性が確認
されていないことが分かる。これにより、決済支援サー
バ２００側で、不整合の生じた可能性のある決済を的確
に検知することができる。
２００から受け付けたオーソリ要求情報に基づいて、ユ
ーザに対する与信の可否を判断し（Ｓ３１０）、与信が
可能であれば（Ｓ３１０のＹ）、与信枠を確保する（Ｓ
３１２）。与信が不可能であれば（Ｓ３１０のＮ）、Ｓ
３１２をスキップする。決済処理サーバ３００は、オー
ソリ要求に対する応答情報を生成し（Ｓ３１４）、決済
支援サーバ２００に送信する（Ｓ３１６）。決済支援サ
ーバ２００は、決済処理サーバ３００から受け付けた応
答情報を購入受付サーバ１００へ送信する（Ｓ３１
８）。このとき、決済支援サーバ２００は、この決済の
受信確認フラグを「保留」に設定しておく。購入受付サ
ーバ１００は、決済支援サーバ２００から応答情報を受
信すると、決済を要求したユーザに応答情報を提示し
（Ｓ３２０）、決済支援サーバ２００に応答情報を受信
した旨を通知する（Ｓ３２２）。決済支援サーバ２００
がこの受信確認を受け取れた場合は、その決済の受信確
認フラグを「受信済み」に設定する。決済支援サーバ２
００から購入受付サーバ１００への応答情報の送信（Ｓ
３１８）又は購入受付サーバ１００から決済支援サーバ
２００への受信状況の通知（Ｓ３２０）の際に通信障害
が発生した場合は、両者の間で処理結果の認識に不整合
が生じる恐れがある。本実施の形態では、購入受付サー
バ１００が、応答情報を受信したときには受信確認を決
済支援サーバ２００に送信し、応答情報を受信しなかっ
たときには何も送信しない。すなわち、受信確認フラグ
が「保留」のままである決済については、整合性が確認
されていないことが分かる。これにより、決済支援サー
バ２００側で、不整合の生じた可能性のある決済を的確
に検知することができる。
【０１１６】図２４は、決済支援サーバ２００から購入
受付サーバ１００への応答情報送信の際に通信障害が発
生したときの処理の手順を示す。購入受付サーバ１００
は、決済支援サーバ２００から応答情報を受信できなか
ったとき、第１の時間が経過するまで待機する（Ｓ３５
０のＮ）。第１の時間は、購入受付サーバ１００がオー
ソリ要求を送信してから応答情報を受信するまでに通常
要する時間よりも少し長めに設定されてもよく、たとえ
ば、数十秒程度であってもよい。第１の時間が経過する
と（Ｓ３５０のＹ）、購入受付サーバ１００は、決済支
援サーバ２００に応答情報の送信を要求する（Ｓ３５
２）。これにより、通信障害などの理由で応答情報が受
信できなかった場合であっても、応答情報を受信するこ
とができる。決済支援サーバ２００が応答情報送信要求
を受け取って、応答情報を購入受付サーバ１００へ送信
したときに、通信障害などの理由で購入受付サーバ１０
０が応答情報を受信できなかった場合、購入受付サーバ
１００は第２の時間が経過するまで待機する（Ｓ３５６
のＮ）。第２の時間は、ユーザ端末２０のウェブブラウ
ザがタイムアウト処理を行うまでの時間よりも短く設定
されるのが好ましく、たとえば、２００秒から２７０秒
程度であってもよい。第２の時間が経過すると（Ｓ３５
６のＹ）、購入受付サーバ１００は、応答情報が受信で
きなかった旨をユーザ端末２０に伝達する（Ｓ３５
８）。上記の処理の過程で、購入受付サーバ１００が応
答情報を受信できたときは、購入受付サーバ１００は決
済支援サーバ２００に受信確認を送信する。
受付サーバ１００への応答情報送信の際に通信障害が発
生したときの処理の手順を示す。購入受付サーバ１００
は、決済支援サーバ２００から応答情報を受信できなか
ったとき、第１の時間が経過するまで待機する（Ｓ３５
０のＮ）。第１の時間は、購入受付サーバ１００がオー
ソリ要求を送信してから応答情報を受信するまでに通常
要する時間よりも少し長めに設定されてもよく、たとえ
ば、数十秒程度であってもよい。第１の時間が経過する
と（Ｓ３５０のＹ）、購入受付サーバ１００は、決済支
援サーバ２００に応答情報の送信を要求する（Ｓ３５
２）。これにより、通信障害などの理由で応答情報が受
信できなかった場合であっても、応答情報を受信するこ
とができる。決済支援サーバ２００が応答情報送信要求
を受け取って、応答情報を購入受付サーバ１００へ送信
したときに、通信障害などの理由で購入受付サーバ１０
０が応答情報を受信できなかった場合、購入受付サーバ
１００は第２の時間が経過するまで待機する（Ｓ３５６
のＮ）。第２の時間は、ユーザ端末２０のウェブブラウ
ザがタイムアウト処理を行うまでの時間よりも短く設定
されるのが好ましく、たとえば、２００秒から２７０秒
程度であってもよい。第２の時間が経過すると（Ｓ３５
６のＹ）、購入受付サーバ１００は、応答情報が受信で
きなかった旨をユーザ端末２０に伝達する（Ｓ３５
８）。上記の処理の過程で、購入受付サーバ１００が応
答情報を受信できたときは、購入受付サーバ１００は決
済支援サーバ２００に受信確認を送信する。
【０１１７】図２５は、購入受付サーバ１００から決済
支援サーバ２００への受信状況通知の際に通信障害が発
生したときの処理の手順を示す。購入受付サーバ１００
は、決済支援サーバ２００から応答情報を受信すると
（Ｓ３１８）、ユーザ端末２０に応答情報を提示し（Ｓ
３２０）、決済支援サーバ２００に受信確認を送信する
が（Ｓ３２２）、この受信確認が通信障害などの原因で
決済支援サーバ２００に到着しなかったとする。このと
き、決済支援サーバ２００は、第３の時間が経過するま
で待機する（Ｓ３２４のＮ）。第３の時間は、ユーザ端
末２０のウェブブラウザのタイムアウト時間よりも少し
長めに設定されてもよく、たとえば、３００秒程度であ
ってもよい。購入受付サーバ１００は、ユーザ端末２０
のウェブブラウザがタイムアウト処理を行う前に、ユー
ザ端末２０に何らかの応答情報を送信しているはずであ
るから、それよりも少し長い時間待機しても受信状況が
通知されなかった場合は、購入受付サーバ１００が受信
状況を通知していないか、通知していても通信障害によ
り決済支援サーバ２００に到着しなかった可能性が高い
ので、ブラウザのタイムアウト時間よりも少し長い時間
待機すれば十分である。または、決済支援サーバ２００
が処理結果の認識の整合性を購入受付サーバ１００との
間で確認する時間間隔を第３の時間としてもよく、たと
えば、１日に１回整合性を確認したい場合には、第３の
時間は１日であってもよい。
支援サーバ２００への受信状況通知の際に通信障害が発
生したときの処理の手順を示す。購入受付サーバ１００
は、決済支援サーバ２００から応答情報を受信すると
（Ｓ３１８）、ユーザ端末２０に応答情報を提示し（Ｓ
３２０）、決済支援サーバ２００に受信確認を送信する
が（Ｓ３２２）、この受信確認が通信障害などの原因で
決済支援サーバ２００に到着しなかったとする。このと
き、決済支援サーバ２００は、第３の時間が経過するま
で待機する（Ｓ３２４のＮ）。第３の時間は、ユーザ端
末２０のウェブブラウザのタイムアウト時間よりも少し
長めに設定されてもよく、たとえば、３００秒程度であ
ってもよい。購入受付サーバ１００は、ユーザ端末２０
のウェブブラウザがタイムアウト処理を行う前に、ユー
ザ端末２０に何らかの応答情報を送信しているはずであ
るから、それよりも少し長い時間待機しても受信状況が
通知されなかった場合は、購入受付サーバ１００が受信
状況を通知していないか、通知していても通信障害によ
り決済支援サーバ２００に到着しなかった可能性が高い
ので、ブラウザのタイムアウト時間よりも少し長い時間
待機すれば十分である。または、決済支援サーバ２００
が処理結果の認識の整合性を購入受付サーバ１００との
間で確認する時間間隔を第３の時間としてもよく、たと
えば、１日に１回整合性を確認したい場合には、第３の
時間は１日であってもよい。
【０１１８】第３の時間が経過すると（Ｓ３２４の
Ｙ）、決済支援サーバ２００は、決済処理サーバ３００
から与信枠の確保に成功した旨の応答情報を受信してい
た決済について、所定の判断基準に基づいて、確保され
た与信枠を解放するか否かを判断する（Ｓ３２６）。与
信枠を解放すると判断したときには（Ｓ３２６のＹ）、
決済支援サーバ２００が保持しているその決済の情報を
削除するとともに、与信枠の解放を決済処理サーバ３０
０に要求する（Ｓ３４２）。与信枠を解放しないと判断
したときには（Ｓ３２６のＮ）、受信状況を取得できな
かった決済情報を出力する（Ｓ３２８）。決済支援サー
バ２００は、出力された決済情報について、購入受付サ
ーバ１００との間で整合性がとれているか否かを確認す
る（Ｓ３３０）。決済支援サーバ２００は、購入受付サ
ーバ１００からの回答を受けて（Ｓ３３２）、不整合が
生じているか否かを判断する（Ｓ３３４）。
Ｙ）、決済支援サーバ２００は、決済処理サーバ３００
から与信枠の確保に成功した旨の応答情報を受信してい
た決済について、所定の判断基準に基づいて、確保され
た与信枠を解放するか否かを判断する（Ｓ３２６）。与
信枠を解放すると判断したときには（Ｓ３２６のＹ）、
決済支援サーバ２００が保持しているその決済の情報を
削除するとともに、与信枠の解放を決済処理サーバ３０
０に要求する（Ｓ３４２）。与信枠を解放しないと判断
したときには（Ｓ３２６のＮ）、受信状況を取得できな
かった決済情報を出力する（Ｓ３２８）。決済支援サー
バ２００は、出力された決済情報について、購入受付サ
ーバ１００との間で整合性がとれているか否かを確認す
る（Ｓ３３０）。決済支援サーバ２００は、購入受付サ
ーバ１００からの回答を受けて（Ｓ３３２）、不整合が
生じているか否かを判断する（Ｓ３３４）。
【０１１９】購入受付サーバ１００が応答情報を受信し
て受信確認を送信したにも関わらず、何らかの原因で決
済支援サーバ２００に到着しなかったことが確認された
場合は、両者に処理結果の認識に不整合がないので（Ｓ
３３４のＮ）、処理を終了する。購入受付サーバ１００
が応答情報を受信できず、受信状況を通知しなかったこ
とが確認された場合は、両者に不整合が生じている可能
性がある（Ｓ３３４のＹ）。与信枠の確保に失敗してい
た場合は、その旨を通知するだけでよいが、与信枠の確
保に成功していた場合は、その与信枠を解放すべきか否
かを購入受付サーバ１００に問い合わせる（Ｓ３３
６）。決済支援サーバ２００は、購入受付サーバ１００
からの回答を受けて（Ｓ３３８）、与信枠を解放する場
合は（Ｓ３４０のＹ）、決済支援サーバ２００が保持し
ているその決済の情報を削除するとともに、与信枠の解
放を決済処理サーバ３００に要求し（Ｓ３４２）、与信
枠を解放しない場合は（Ｓ３４０のＮ）、その決済が成
功していたものとして処理する。決済処理サーバ３００
は、決済支援サーバ２００から与信枠の解放を要求され
た場合は、与信枠を解放する（Ｓ３４４）。
て受信確認を送信したにも関わらず、何らかの原因で決
済支援サーバ２００に到着しなかったことが確認された
場合は、両者に処理結果の認識に不整合がないので（Ｓ
３３４のＮ）、処理を終了する。購入受付サーバ１００
が応答情報を受信できず、受信状況を通知しなかったこ
とが確認された場合は、両者に不整合が生じている可能
性がある（Ｓ３３４のＹ）。与信枠の確保に失敗してい
た場合は、その旨を通知するだけでよいが、与信枠の確
保に成功していた場合は、その与信枠を解放すべきか否
かを購入受付サーバ１００に問い合わせる（Ｓ３３
６）。決済支援サーバ２００は、購入受付サーバ１００
からの回答を受けて（Ｓ３３８）、与信枠を解放する場
合は（Ｓ３４０のＹ）、決済支援サーバ２００が保持し
ているその決済の情報を削除するとともに、与信枠の解
放を決済処理サーバ３００に要求し（Ｓ３４２）、与信
枠を解放しない場合は（Ｓ３４０のＮ）、その決済が成
功していたものとして処理する。決済処理サーバ３００
は、決済支援サーバ２００から与信枠の解放を要求され
た場合は、与信枠を解放する（Ｓ３４４）。
【０１２０】図２６は、本実施の形態の購入受付サーバ
１００、決済支援サーバ２００、及び決済処理サーバ３
００の内部構成を示す。図３に示した第１の実施の形態
の購入受付サーバ１００、決済支援サーバ２００、及び
決済処理サーバ３００の構成と同様の構成には、同一の
符号を付している。以下、主に、第１の実施の形態の構
成及び動作と異なる点に重点をおいて説明する。
１００、決済支援サーバ２００、及び決済処理サーバ３
００の内部構成を示す。図３に示した第１の実施の形態
の購入受付サーバ１００、決済支援サーバ２００、及び
決済処理サーバ３００の構成と同様の構成には、同一の
符号を付している。以下、主に、第１の実施の形態の構
成及び動作と異なる点に重点をおいて説明する。
【０１２１】購入要求受付部１１０は、ユーザ端末２０
から商品の購入要求を受け付ける。決済要求受付部１１
２は、商品の購入に伴う決済要求を受け付ける。このと
き、クレジットカードの番号、有効期限など、必要な情
報を取得する。要求情報生成部１３１は、決済を要求し
たユーザの与信枠を確保するためのオーソリ要求情報を
生成する。要求情報送信部１５１は、要求情報生成部に
より生成されたオーソリ情報を決済支援サーバ２００に
送信する。要求情報受信部２１１は、購入受付サーバ１
００からオーソリ要求を受信する。要求情報送信部２５
１は、要求情報受信部２１１が受信したオーソリ要求を
決済処理サーバ３００へ送信する。
から商品の購入要求を受け付ける。決済要求受付部１１
２は、商品の購入に伴う決済要求を受け付ける。このと
き、クレジットカードの番号、有効期限など、必要な情
報を取得する。要求情報生成部１３１は、決済を要求し
たユーザの与信枠を確保するためのオーソリ要求情報を
生成する。要求情報送信部１５１は、要求情報生成部に
より生成されたオーソリ情報を決済支援サーバ２００に
送信する。要求情報受信部２１１は、購入受付サーバ１
００からオーソリ要求を受信する。要求情報送信部２５
１は、要求情報受信部２１１が受信したオーソリ要求を
決済処理サーバ３００へ送信する。
【０１２２】要求情報受付部３１１は、決済支援サーバ
２００からオーソリ要求を受け付ける。オーソリ処理部
３２１は、要求情報受付部３１１にて受け付けたオーソ
リ要求情報をもとに、ユーザデータベース３３０を参照
して、ユーザに対する与信の可否を判断し、与信が可能
であれば、与信枠を確保する。応答情報生成部３４０
は、オーソリ要求に対する応答情報を生成する。応答情
報送信部３５０は、応答情報生成部３４０にて生成され
た応答情報を決済支援サーバ２００に送信する。応答情
報受信部２６０は、決済処理サーバ３００から応答情報
を受信する。応答情報送信部２７０は、応答情報受信部
２６０が受信した応答情報を購入受付サーバ１００に送
信する。応答情報受信部１６０は、決済支援サーバ２０
０から応答情報を受信する。応答情報受信部１６０は、
第１の時間待機しても決済支援サーバ２００から応答情
報を受信しなかったときには、決済支援サーバ２００に
応答情報の送信を要求してもよい。応答情報提示部１１
４は、応答情報をユーザに提示する。
２００からオーソリ要求を受け付ける。オーソリ処理部
３２１は、要求情報受付部３１１にて受け付けたオーソ
リ要求情報をもとに、ユーザデータベース３３０を参照
して、ユーザに対する与信の可否を判断し、与信が可能
であれば、与信枠を確保する。応答情報生成部３４０
は、オーソリ要求に対する応答情報を生成する。応答情
報送信部３５０は、応答情報生成部３４０にて生成され
た応答情報を決済支援サーバ２００に送信する。応答情
報受信部２６０は、決済処理サーバ３００から応答情報
を受信する。応答情報送信部２７０は、応答情報受信部
２６０が受信した応答情報を購入受付サーバ１００に送
信する。応答情報受信部１６０は、決済支援サーバ２０
０から応答情報を受信する。応答情報受信部１６０は、
第１の時間待機しても決済支援サーバ２００から応答情
報を受信しなかったときには、決済支援サーバ２００に
応答情報の送信を要求してもよい。応答情報提示部１１
４は、応答情報をユーザに提示する。
【０１２３】受信状況通知部１７０は、応答情報の受信
状況を決済支援サーバ２００に通知する。受信状況通知
部１７０は、応答情報受信部１６０が応答情報を受信し
たときには、その旨を決済支援サーバ２００に通知す
る。受信状況通知部１７０は、応答情報受信部１６０が
第２の時間待機しても応答情報を受信しなかったときに
は、決済支援サーバ２００に受信状況を通知しない。こ
れにより、決済支援サーバ２００は、購入受付サーバ１
００からの受信状況の通知の有無で、購入受付サーバ１
００が応答情報を受信したか否かを把握することができ
る。判断部１７２は、応答情報受信部１６０が第２の時
間待機しても応答情報を受信しなかったとき、与信枠が
確保されていた場合にその解放を要求するか否かを判断
する。
状況を決済支援サーバ２００に通知する。受信状況通知
部１７０は、応答情報受信部１６０が応答情報を受信し
たときには、その旨を決済支援サーバ２００に通知す
る。受信状況通知部１７０は、応答情報受信部１６０が
第２の時間待機しても応答情報を受信しなかったときに
は、決済支援サーバ２００に受信状況を通知しない。こ
れにより、決済支援サーバ２００は、購入受付サーバ１
００からの受信状況の通知の有無で、購入受付サーバ１
００が応答情報を受信したか否かを把握することができ
る。判断部１７２は、応答情報受信部１６０が第２の時
間待機しても応答情報を受信しなかったとき、与信枠が
確保されていた場合にその解放を要求するか否かを判断
する。
【０１２４】受信状況取得部２７２は、受信状況通知部
１７０から受信状況を取得する。出力部２７６は、第３
の時間が経過しても受信状況取得部２７２が受信状況を
取得しなかった決済の情報を出力する。出力された決済
情報は、購入受付サーバ１００に保持された決済情報と
比較され、不整合の有無が確認される。判断部２７４
は、第３の時間が経過しても受信状況取得部２７２が受
信状況を取得しなかったときに、与信枠の確保に成功し
ていた場合には、その与信枠を解放するよう要求するか
否かを判断する。判断部２７４は、所定の判断基準を保
持してもよい。判断基準は、たとえば、受信状況を取得
しなかったときには必ず与信枠を解放する、必ず与信枠
を解放しない、などであってもよい。ユーザの属性情報
や商品の種類に応じて与信枠の解放を要求するか否かを
判断してもよい。解放要求送信部２７８は、判断部２７
４が与信枠の解放を要求すると判断したときに、決済処
理サーバ３００に与信枠の解放を要求する。このとき、
決済支援サーバ２００が保持している決済の履歴情報か
ら、その決済の情報を削除する。決済処理サーバ３００
は、与信枠の解放を要求されたときは、確保していた与
信枠を解放する。
１７０から受信状況を取得する。出力部２７６は、第３
の時間が経過しても受信状況取得部２７２が受信状況を
取得しなかった決済の情報を出力する。出力された決済
情報は、購入受付サーバ１００に保持された決済情報と
比較され、不整合の有無が確認される。判断部２７４
は、第３の時間が経過しても受信状況取得部２７２が受
信状況を取得しなかったときに、与信枠の確保に成功し
ていた場合には、その与信枠を解放するよう要求するか
否かを判断する。判断部２７４は、所定の判断基準を保
持してもよい。判断基準は、たとえば、受信状況を取得
しなかったときには必ず与信枠を解放する、必ず与信枠
を解放しない、などであってもよい。ユーザの属性情報
や商品の種類に応じて与信枠の解放を要求するか否かを
判断してもよい。解放要求送信部２７８は、判断部２７
４が与信枠の解放を要求すると判断したときに、決済処
理サーバ３００に与信枠の解放を要求する。このとき、
決済支援サーバ２００が保持している決済の履歴情報か
ら、その決済の情報を削除する。決済処理サーバ３００
は、与信枠の解放を要求されたときは、確保していた与
信枠を解放する。
【０１２５】上記の通り、本実施の形態の決済支援シス
テム１０によれば、通信障害などに起因する処理結果の
認識の不整合を的確に検知し、不整合が生じたときに適
切に処置することができる。従来は、購入受付サーバ１
００側と決済支援サーバ２００側の整合性のチェックを
加盟店に任せるケースが多かったが、本システムによれ
ば、決済代行業者側で不整合の発生を検知して加盟店に
問い合わせるので、加盟店側の負担を大幅に軽減するこ
とができる。また、決済代行業者は、通信障害の発生確
率などシステムの保守に必要な情報を的確に把握するこ
とができる。
テム１０によれば、通信障害などに起因する処理結果の
認識の不整合を的確に検知し、不整合が生じたときに適
切に処置することができる。従来は、購入受付サーバ１
００側と決済支援サーバ２００側の整合性のチェックを
加盟店に任せるケースが多かったが、本システムによれ
ば、決済代行業者側で不整合の発生を検知して加盟店に
問い合わせるので、加盟店側の負担を大幅に軽減するこ
とができる。また、決済代行業者は、通信障害の発生確
率などシステムの保守に必要な情報を的確に把握するこ
とができる。
【０１２６】（第１１の実施の形態）つづいて、第１１
の実施の形態に係る決済支援システムについて説明す
る。第１０の実施の形態の決済支援システム１０では、
購入受付サーバ１００が応答情報を受信しなかったとき
に受信状況を通知しなかったが、本実施の形態の決済支
援システム１０では、購入受付サーバ１００が応答情報
を受信しなかったときに、未受信確認を決済支援サーバ
２００に通知する。本実施の形態の決済支援システム１
０の全体構成は、図１に示した第１の実施の形態の決済
支援システム１０と同様であり、購入受付サーバ１０
０、決済支援サーバ２００、及び決済処理サーバ３００
の内部構成は、図２６に示した第１０の実施の形態と同
様である。
の実施の形態に係る決済支援システムについて説明す
る。第１０の実施の形態の決済支援システム１０では、
購入受付サーバ１００が応答情報を受信しなかったとき
に受信状況を通知しなかったが、本実施の形態の決済支
援システム１０では、購入受付サーバ１００が応答情報
を受信しなかったときに、未受信確認を決済支援サーバ
２００に通知する。本実施の形態の決済支援システム１
０の全体構成は、図１に示した第１の実施の形態の決済
支援システム１０と同様であり、購入受付サーバ１０
０、決済支援サーバ２００、及び決済処理サーバ３００
の内部構成は、図２６に示した第１０の実施の形態と同
様である。
【０１２７】応答情報受信部１６０が応答情報を受信し
たときは、図２３の手順と同様に、受信状況通知部１７
０は、受信確認を決済支援サーバ２００に送信する。決
済支援サーバ２００から購入受付サーバ１００への応答
情報送信の際に通信障害が発生したときは、図２４の手
順につづいて、図２７の手順が実行される。購入受付サ
ーバ１００は、第２の時間が経過しても応答情報受信部
１６０が応答情報を受信しなかったとき、未受信確認を
決済支援サーバ２００に送信する（Ｓ３６０）。決済支
援サーバ２００は、決済処理サーバ３００から与信枠の
確保に成功した旨の応答情報を受信していた場合には、
所定の判断基準に基づいて、確保された与信枠を解放す
るか否かを判断する（Ｓ３６２）。与信枠を解放すると
判断したときには（Ｓ３６２のＹ）、決済支援サーバ２
００が保持しているその決済の情報を削除するととも
に、与信枠の解放を決済処理サーバ３００に要求する
（Ｓ３７０）。与信枠を解放しないと判断したときには
（Ｓ３６２のＮ）、購入受付サーバ１００との不整合を
解消すべく、与信枠を解放すべきか否かを購入受付サー
バ１００に問い合わせる（Ｓ３６４）。決済支援サーバ
２００は、購入受付サーバ１００からの回答を受けて
（Ｓ３６６）、与信枠を解放する場合は（Ｓ３６８の
Ｙ）、決済支援サーバ２００が保持しているその決済の
情報を削除するとともに、与信枠の解放を決済処理サー
バ３００に要求し（Ｓ３７０）、与信枠を解放しない場
合は（Ｓ３６８のＮ）、その決済が成功していたものと
して処理する。決済処理サーバ３００は、決済支援サー
バ２００から与信枠の解放を要求された場合は、与信枠
を解放する（Ｓ３７２）。
たときは、図２３の手順と同様に、受信状況通知部１７
０は、受信確認を決済支援サーバ２００に送信する。決
済支援サーバ２００から購入受付サーバ１００への応答
情報送信の際に通信障害が発生したときは、図２４の手
順につづいて、図２７の手順が実行される。購入受付サ
ーバ１００は、第２の時間が経過しても応答情報受信部
１６０が応答情報を受信しなかったとき、未受信確認を
決済支援サーバ２００に送信する（Ｓ３６０）。決済支
援サーバ２００は、決済処理サーバ３００から与信枠の
確保に成功した旨の応答情報を受信していた場合には、
所定の判断基準に基づいて、確保された与信枠を解放す
るか否かを判断する（Ｓ３６２）。与信枠を解放すると
判断したときには（Ｓ３６２のＹ）、決済支援サーバ２
００が保持しているその決済の情報を削除するととも
に、与信枠の解放を決済処理サーバ３００に要求する
（Ｓ３７０）。与信枠を解放しないと判断したときには
（Ｓ３６２のＮ）、購入受付サーバ１００との不整合を
解消すべく、与信枠を解放すべきか否かを購入受付サー
バ１００に問い合わせる（Ｓ３６４）。決済支援サーバ
２００は、購入受付サーバ１００からの回答を受けて
（Ｓ３６６）、与信枠を解放する場合は（Ｓ３６８の
Ｙ）、決済支援サーバ２００が保持しているその決済の
情報を削除するとともに、与信枠の解放を決済処理サー
バ３００に要求し（Ｓ３７０）、与信枠を解放しない場
合は（Ｓ３６８のＮ）、その決済が成功していたものと
して処理する。決済処理サーバ３００は、決済支援サー
バ２００から与信枠の解放を要求された場合は、与信枠
を解放する（Ｓ３７２）。
【０１２８】第３の時間が経過しても受信状況取得部２
７２が受信状況を取得しなかったときは、受信状況通知
部１７０が受信確認を送信していたのか、未受信確認を
送信していたのか、決済支援サーバ２００側では知るこ
とができない。このときの処理の手順は、図２５に示し
た第１０の実施の形態と同様である。
７２が受信状況を取得しなかったときは、受信状況通知
部１７０が受信確認を送信していたのか、未受信確認を
送信していたのか、決済支援サーバ２００側では知るこ
とができない。このときの処理の手順は、図２５に示し
た第１０の実施の形態と同様である。
【０１２９】上記の通り、本実施の形態の決済支援シス
テム１０によっても、通信障害などに起因する処理結果
の認識の不整合を的確に検知することができる。本実施
の形態では、購入受付サーバ１００が応答情報を受信し
なかったときに、未受信確認を送信するので、決済支援
サーバ２００は、より的確に受信状況を把握することが
できる。
テム１０によっても、通信障害などに起因する処理結果
の認識の不整合を的確に検知することができる。本実施
の形態では、購入受付サーバ１００が応答情報を受信し
なかったときに、未受信確認を送信するので、決済支援
サーバ２００は、より的確に受信状況を把握することが
できる。
【０１３０】（第１２の実施の形態）つづいて、第１２
の実施の形態に係る決済支援システムについて説明す
る。第１０の実施の形態の決済支援システム１０では、
購入受付サーバ１００が応答情報を受信しなかったとき
に受信状況を通知しなかったが、本実施の形態の決済支
援システム１０では、購入受付サーバ１００が応答情報
を受信しなかったときに、自動取消要求を決済支援サー
バ２００に通知する。本実施の形態の決済支援システム
１０の全体構成は、図１に示した第１の実施の形態の決
済支援システム１０と同様であり、購入受付サーバ１０
０、決済支援サーバ２００、及び決済処理サーバ３００
の内部構成は、図２６に示した第１０の実施の形態と同
様である。
の実施の形態に係る決済支援システムについて説明す
る。第１０の実施の形態の決済支援システム１０では、
購入受付サーバ１００が応答情報を受信しなかったとき
に受信状況を通知しなかったが、本実施の形態の決済支
援システム１０では、購入受付サーバ１００が応答情報
を受信しなかったときに、自動取消要求を決済支援サー
バ２００に通知する。本実施の形態の決済支援システム
１０の全体構成は、図１に示した第１の実施の形態の決
済支援システム１０と同様であり、購入受付サーバ１０
０、決済支援サーバ２００、及び決済処理サーバ３００
の内部構成は、図２６に示した第１０の実施の形態と同
様である。
【０１３１】応答情報受信部１６０が応答情報を受信し
たときは、図２３の手順と同様に、受信状況通知部１７
０は、受信確認を決済支援サーバ２００に送信する。決
済支援サーバ２００から購入受付サーバ１００への応答
情報送信の際に通信障害が発生したときは、図２４の手
順につづいて、図２８の手順が実行される。購入受付サ
ーバ１００の判断部１７２は、第２の時間が経過しても
応答情報受信部１６０が応答情報を受信しなかった決済
について、その決済を自動的に取り消すよう要求するか
否かを判断する（Ｓ３８０）。要求しないと判断された
ときは（Ｓ３８０のＮ）、処理を終了してもよいし、第
１１の実施の形態と同様に、未受信確認を決済支援サー
バ２００に送信してもよい。要求すると判断されたとき
は（Ｓ３８０のＹ）、受信状況通知部１７０は、決済支
援サーバ２００に自動取消要求を送信する（Ｓ３８
２）。受信状況取得部２７２が自動取消要求を受信する
と、解放要求送信部２７８は、決済支援サーバ２００が
保持しているその決済の情報を削除するとともに、決済
処理サーバ３００に確保された与信枠の解放を要求する
（Ｓ３８４）。決済処理サーバ３００は、与信枠の解放
要求を受けて、そのユーザの与信枠を解放する（Ｓ３８
６）。
たときは、図２３の手順と同様に、受信状況通知部１７
０は、受信確認を決済支援サーバ２００に送信する。決
済支援サーバ２００から購入受付サーバ１００への応答
情報送信の際に通信障害が発生したときは、図２４の手
順につづいて、図２８の手順が実行される。購入受付サ
ーバ１００の判断部１７２は、第２の時間が経過しても
応答情報受信部１６０が応答情報を受信しなかった決済
について、その決済を自動的に取り消すよう要求するか
否かを判断する（Ｓ３８０）。要求しないと判断された
ときは（Ｓ３８０のＮ）、処理を終了してもよいし、第
１１の実施の形態と同様に、未受信確認を決済支援サー
バ２００に送信してもよい。要求すると判断されたとき
は（Ｓ３８０のＹ）、受信状況通知部１７０は、決済支
援サーバ２００に自動取消要求を送信する（Ｓ３８
２）。受信状況取得部２７２が自動取消要求を受信する
と、解放要求送信部２７８は、決済支援サーバ２００が
保持しているその決済の情報を削除するとともに、決済
処理サーバ３００に確保された与信枠の解放を要求する
（Ｓ３８４）。決済処理サーバ３００は、与信枠の解放
要求を受けて、そのユーザの与信枠を解放する（Ｓ３８
６）。
【０１３２】第３の時間が経過しても受信状況取得部２
７２が受信状況を取得しなかったときは、受信状況通知
部１７０が受信確認を送信していたのか、自動取消要求
を送信していたのか、何も送信しなかったのか、決済支
援サーバ２００側では知ることができない。このときの
処理の手順は、図２５に示した第１０の実施の形態と同
様である。
７２が受信状況を取得しなかったときは、受信状況通知
部１７０が受信確認を送信していたのか、自動取消要求
を送信していたのか、何も送信しなかったのか、決済支
援サーバ２００側では知ることができない。このときの
処理の手順は、図２５に示した第１０の実施の形態と同
様である。
【０１３３】上記の通り、本実施の形態の決済支援シス
テム１０によっても、通信障害などに起因する処理結果
の認識の不整合を的確に検知することができる。本実施
の形態では、購入受付サーバ１００が応答情報を受信し
なかったときに、その決済要求を取り消すか否かを判断
して、自動取消要求を送信するので、決済支援サーバ２
００はより的確に販売主体の意向に沿った処理を行うこ
とができる。
テム１０によっても、通信障害などに起因する処理結果
の認識の不整合を的確に検知することができる。本実施
の形態では、購入受付サーバ１００が応答情報を受信し
なかったときに、その決済要求を取り消すか否かを判断
して、自動取消要求を送信するので、決済支援サーバ２
００はより的確に販売主体の意向に沿った処理を行うこ
とができる。
【０１３４】（第１３の実施の形態）つづいて、第１３
の実施の形態に係る決済支援システムについて説明す
る。第１３の実施の形態の決済支援システム１０では、
購入受付サーバ１００が決済支援サーバ２００に、既に
要求した決済の金額を変更するよう要求すると、決済支
援サーバ２００は、決済処理サーバ３００に元の決済の
返品処理を要求し、つづいて、新たな金額の決済を要求
する。本実施の形態の決済支援システム１０の全体構成
は、図１に示した第１の実施の形態の決済支援システム
１０と同様である。
の実施の形態に係る決済支援システムについて説明す
る。第１３の実施の形態の決済支援システム１０では、
購入受付サーバ１００が決済支援サーバ２００に、既に
要求した決済の金額を変更するよう要求すると、決済支
援サーバ２００は、決済処理サーバ３００に元の決済の
返品処理を要求し、つづいて、新たな金額の決済を要求
する。本実施の形態の決済支援システム１０の全体構成
は、図１に示した第１の実施の形態の決済支援システム
１０と同様である。
【０１３５】図２９は、本実施の形態に係る決済支援シ
ステム１０における処理の流れを概略的に示す図であ
る。購入受付サーバ１００は、ユーザから既に要求した
決済の金額を変更するよう要求されると（Ｓ４００）、
既に要求した元の決済の伝票番号と、金額変更後の新た
な決済の伝票番号と、変更後の金額とを含む金額変更要
求情報を決済支援サーバ２００に送信する（Ｓ４０
２）。決済支援サーバ２００は、金額変更要求情報を受
け付けると、元の決済の伝票番号をもとに、決済の履歴
を格納した決済履歴データベースを検索し、元の決済の
金額を取得する（Ｓ４０４）。決済支援サーバ２００
は、決済処理サーバ３００に、元の決済の金額を通知し
つつ返品処理要求を送信する（Ｓ４０６）。決済処理サ
ーバ３００は、返品処理を行い（Ｓ４０８）、その返品
処理要求に対する返品処理応答情報を生成して（Ｓ４１
０）、決済支援サーバ２００に送信する（Ｓ４１２）。
決済支援サーバ２００は、返品処理応答情報を参照し
て、返品処理に失敗していれば（Ｓ４１４のＮ）、その
旨を通知するための金額変更応答情報を生成する（Ｓ４
３０）。
ステム１０における処理の流れを概略的に示す図であ
る。購入受付サーバ１００は、ユーザから既に要求した
決済の金額を変更するよう要求されると（Ｓ４００）、
既に要求した元の決済の伝票番号と、金額変更後の新た
な決済の伝票番号と、変更後の金額とを含む金額変更要
求情報を決済支援サーバ２００に送信する（Ｓ４０
２）。決済支援サーバ２００は、金額変更要求情報を受
け付けると、元の決済の伝票番号をもとに、決済の履歴
を格納した決済履歴データベースを検索し、元の決済の
金額を取得する（Ｓ４０４）。決済支援サーバ２００
は、決済処理サーバ３００に、元の決済の金額を通知し
つつ返品処理要求を送信する（Ｓ４０６）。決済処理サ
ーバ３００は、返品処理を行い（Ｓ４０８）、その返品
処理要求に対する返品処理応答情報を生成して（Ｓ４１
０）、決済支援サーバ２００に送信する（Ｓ４１２）。
決済支援サーバ２００は、返品処理応答情報を参照し
て、返品処理に失敗していれば（Ｓ４１４のＮ）、その
旨を通知するための金額変更応答情報を生成する（Ｓ４
３０）。
【０１３６】返品処理に成功していれば（Ｓ４１４の
Ｙ）、つづいて、決済処理サーバ３００に、金額が変更
された新たな決済を要求する（Ｓ４１６）。決済処理サ
ーバ３００は、再売上処理を行い（Ｓ４１８）、その再
売上要求に対する再売上応答情報を生成して（Ｓ４２
０）、決済支援サーバ２００に送信する（Ｓ４２２）。
決済支援サーバ２００は、再売上応答情報を参照して、
再売上に失敗していれば（Ｓ４２４のＮ）、決済処理サ
ーバ３００に返品処理の取消を要求し（Ｓ４２６）、決
済処理サーバ３００は返品処理を取り消す（Ｓ４２
８）。決済支援サーバ２００は、返品処理応答情報及び
再売上応答情報に基づいて、金額変更要求に対する金額
変更応答情報を生成して（Ｓ４３０）、購入受付サーバ
１００に送信する（Ｓ４３２）。購入受付サーバ１００
は、決済支援サーバ２００から受信した金額変更応答情
報をユーザに提示する（Ｓ４３４）。
Ｙ）、つづいて、決済処理サーバ３００に、金額が変更
された新たな決済を要求する（Ｓ４１６）。決済処理サ
ーバ３００は、再売上処理を行い（Ｓ４１８）、その再
売上要求に対する再売上応答情報を生成して（Ｓ４２
０）、決済支援サーバ２００に送信する（Ｓ４２２）。
決済支援サーバ２００は、再売上応答情報を参照して、
再売上に失敗していれば（Ｓ４２４のＮ）、決済処理サ
ーバ３００に返品処理の取消を要求し（Ｓ４２６）、決
済処理サーバ３００は返品処理を取り消す（Ｓ４２
８）。決済支援サーバ２００は、返品処理応答情報及び
再売上応答情報に基づいて、金額変更要求に対する金額
変更応答情報を生成して（Ｓ４３０）、購入受付サーバ
１００に送信する（Ｓ４３２）。購入受付サーバ１００
は、決済支援サーバ２００から受信した金額変更応答情
報をユーザに提示する（Ｓ４３４）。
【０１３７】図３０は、本実施の形態に係る購入受付サ
ーバ１００、決済支援サーバ２００、及び決済処理サー
バ３００の内部構成を示す。金額変更要求受付部１１６
は、ユーザから金額変更要求を受け付ける。このとき、
既に要求した元の決済の識別情報、たとえば伝票番号を
取得してもよい。金額変更要求送信部１１８は、決済支
援サーバ２００に金額変更要求情報を送信する。金額変
更要求情報は、元の決済及び新たな決済の識別情報と、
変更後の金額とを含む。決済の識別情報は、たとえば、
伝票番号であってもよい。金額変更応答受信部１６２
は、決済支援サーバ２００から、金額変更要求に対する
応答情報を受信する。応答情報提示部１１４は、金額変
更応答受信部１６２が受信した応答情報をユーザに提示
する。
ーバ１００、決済支援サーバ２００、及び決済処理サー
バ３００の内部構成を示す。金額変更要求受付部１１６
は、ユーザから金額変更要求を受け付ける。このとき、
既に要求した元の決済の識別情報、たとえば伝票番号を
取得してもよい。金額変更要求送信部１１８は、決済支
援サーバ２００に金額変更要求情報を送信する。金額変
更要求情報は、元の決済及び新たな決済の識別情報と、
変更後の金額とを含む。決済の識別情報は、たとえば、
伝票番号であってもよい。金額変更応答受信部１６２
は、決済支援サーバ２００から、金額変更要求に対する
応答情報を受信する。応答情報提示部１１４は、金額変
更応答受信部１６２が受信した応答情報をユーザに提示
する。
【０１３８】金額変更要求受信部２１２は、購入受付サ
ーバ１００から金額変更要求を受け付ける。決済履歴デ
ータベース２２２は、決済支援サーバ２００が取り扱っ
た決済の履歴情報を格納する。金額変更要求受信部２１
２は、金額変更要求を受け付けると、元の決済の伝票番
号をもとに、決済履歴データベース２２２を検索して、
元の決済の金額を取得する。返品処理要求部２１４は、
決済処理サーバ３００に元の決済についての返品処理要
求を送信する。返品処理応答受信部２１６は、決済処理
サーバ３００から、返品処理要求に対する返品処理応答
情報を受信する。返品処理が失敗していたときは、応答
情報送信部２７０が、返品処理に失敗した旨を示す金額
変更応答情報を生成して、購入受付サーバ１００へ送信
する。返品処理が成功していたときは、つづいて、再売
上要求部２１８が、決済処理サーバ３００に金額が変更
された新たな決済を要求する。再売上応答受信部２２１
は、決済処理サーバ３００から、再売上要求に対する再
売上応答情報を受信する。再売上が失敗していたとき
は、返品処理要求取消部２２４が、決済処理サーバ３０
０に返品処理の取消を要求するとともに、応答情報送信
部２７０が、再売上に失敗した旨を示す金額変更応答情
報を生成して、購入受付サーバ１００に送信する。返品
処理だけが成功した状態のままにしておくと、金額の変
更を要求されたにも関わらず、元の決済を取り消してし
まうことになるので、返品処理だけが成功して再売上に
失敗したときは、返品処理を取り消して、金額変更を要
求される前の状態に戻しておく。再売上に成功していた
ときは、応答情報送信部２７０が、金額変更に失敗した
旨を示す金額変更応答情報を生成して、購入受付サーバ
１００に送信する。
ーバ１００から金額変更要求を受け付ける。決済履歴デ
ータベース２２２は、決済支援サーバ２００が取り扱っ
た決済の履歴情報を格納する。金額変更要求受信部２１
２は、金額変更要求を受け付けると、元の決済の伝票番
号をもとに、決済履歴データベース２２２を検索して、
元の決済の金額を取得する。返品処理要求部２１４は、
決済処理サーバ３００に元の決済についての返品処理要
求を送信する。返品処理応答受信部２１６は、決済処理
サーバ３００から、返品処理要求に対する返品処理応答
情報を受信する。返品処理が失敗していたときは、応答
情報送信部２７０が、返品処理に失敗した旨を示す金額
変更応答情報を生成して、購入受付サーバ１００へ送信
する。返品処理が成功していたときは、つづいて、再売
上要求部２１８が、決済処理サーバ３００に金額が変更
された新たな決済を要求する。再売上応答受信部２２１
は、決済処理サーバ３００から、再売上要求に対する再
売上応答情報を受信する。再売上が失敗していたとき
は、返品処理要求取消部２２４が、決済処理サーバ３０
０に返品処理の取消を要求するとともに、応答情報送信
部２７０が、再売上に失敗した旨を示す金額変更応答情
報を生成して、購入受付サーバ１００に送信する。返品
処理だけが成功した状態のままにしておくと、金額の変
更を要求されたにも関わらず、元の決済を取り消してし
まうことになるので、返品処理だけが成功して再売上に
失敗したときは、返品処理を取り消して、金額変更を要
求される前の状態に戻しておく。再売上に成功していた
ときは、応答情報送信部２７０が、金額変更に失敗した
旨を示す金額変更応答情報を生成して、購入受付サーバ
１００に送信する。
【０１３９】要求情報受付部３１１は、決済支援サーバ
２００から、決済の要求を受け付ける。オーソリ処理部
３２１は、決済要求の内容に応じて、ユーザの与信枠の
確保や解放などの処理を実行する。ユーザデータベース
３３０は、ユーザのクレジットカードの番号、有効期
限、暗証番号などの情報を格納する。応答情報生成部３
４０は、決済要求に対する応答情報を生成する。応答情
報送信部３５０は、応答情報生成部３４０が生成した応
答情報を、決済支援サーバ２００に送信する。
２００から、決済の要求を受け付ける。オーソリ処理部
３２１は、決済要求の内容に応じて、ユーザの与信枠の
確保や解放などの処理を実行する。ユーザデータベース
３３０は、ユーザのクレジットカードの番号、有効期
限、暗証番号などの情報を格納する。応答情報生成部３
４０は、決済要求に対する応答情報を生成する。応答情
報送信部３５０は、応答情報生成部３４０が生成した応
答情報を、決済支援サーバ２００に送信する。
【０１４０】上記の通り、本実施の形態の決済支援シス
テム１０によれば、既に要求した決済の金額を変更する
際に、購入受付サーバ１００は、返品処理と再売上を要
求する必要はなく、１回だけ金額変更を要求すればよい
ので、店舗側の負担を軽減することができる。
テム１０によれば、既に要求した決済の金額を変更する
際に、購入受付サーバ１００は、返品処理と再売上を要
求する必要はなく、１回だけ金額変更を要求すればよい
ので、店舗側の負担を軽減することができる。
【０１４１】図３１は、購入受付サーバ１００、決済支
援サーバ２００、決済処理サーバ３００、及び管理サー
バ４００のハードウェアコンポーネントを示す。購入受
付サーバ１００、決済支援サーバ２００、決済処理サー
バ３００、及び管理サーバ４００は、それぞれ、ＣＰＵ
６２０、入力装置６２２、表示装置６２４、ＲＡＭ（ラ
ンダムアクセスメモリ）６３０、ハードディスク６３
２、およびドライブ装置６２８を備える。これらの構成
は、バス６２６などの信号伝送路により電気的に接続さ
れている。
援サーバ２００、決済処理サーバ３００、及び管理サー
バ４００のハードウェアコンポーネントを示す。購入受
付サーバ１００、決済支援サーバ２００、決済処理サー
バ３００、及び管理サーバ４００は、それぞれ、ＣＰＵ
６２０、入力装置６２２、表示装置６２４、ＲＡＭ（ラ
ンダムアクセスメモリ）６３０、ハードディスク６３
２、およびドライブ装置６２８を備える。これらの構成
は、バス６２６などの信号伝送路により電気的に接続さ
れている。
【０１４２】ハードディスク６３２は、大容量の磁気記
憶装置であり、各種データベースなどを記憶する。記録
媒体６４０は、実施の形態に関連して説明した購入受付
サーバ１００、決済支援サーバ２００、決済処理サーバ
３００、及び管理サーバ４００の機能を、ＣＰＵ１２０
に実現させるためのプログラムを記録する。記録媒体６
４０がドライブ装置６２８に挿入されると、そのプログ
ラムは、ＲＡＭ６３０またはハードディスク６３２に読
み出され、ＣＰＵ６２０は、読み出されたプログラムに
より決済支援処理を行う。この記録媒体６４０は、ＣＤ
−ＲＯＭ、ＤＶＤ、ＦＤなどのコンピュータ読み取り可
能な媒体である。
憶装置であり、各種データベースなどを記憶する。記録
媒体６４０は、実施の形態に関連して説明した購入受付
サーバ１００、決済支援サーバ２００、決済処理サーバ
３００、及び管理サーバ４００の機能を、ＣＰＵ１２０
に実現させるためのプログラムを記録する。記録媒体６
４０がドライブ装置６２８に挿入されると、そのプログ
ラムは、ＲＡＭ６３０またはハードディスク６３２に読
み出され、ＣＰＵ６２０は、読み出されたプログラムに
より決済支援処理を行う。この記録媒体６４０は、ＣＤ
−ＲＯＭ、ＤＶＤ、ＦＤなどのコンピュータ読み取り可
能な媒体である。
【０１４３】ここでは、決済支援用のプログラムが記録
媒体６４０に記録されている例について説明したが、別
の例においては、このプログラムは、無線、有線を問わ
ず、外部のサーバから送信されてもよい。図３１に示し
たハードウェア構成において、プログラムは、コンピュ
ータに決済支援機能を実現させればよいのであって、外
部から供給される場合だけでなく、予めハードディスク
６３２に格納されていてよいことも当業者には理解され
るところである。
媒体６４０に記録されている例について説明したが、別
の例においては、このプログラムは、無線、有線を問わ
ず、外部のサーバから送信されてもよい。図３１に示し
たハードウェア構成において、プログラムは、コンピュ
ータに決済支援機能を実現させればよいのであって、外
部から供給される場合だけでなく、予めハードディスク
６３２に格納されていてよいことも当業者には理解され
るところである。
【０１４４】以上、本発明を実施の形態をもとに説明し
たが、本発明の技術的範囲は上記実施の形態に記載の範
囲には限定されない。上記実施の形態は例示であり、各
構成要素や各処理プロセスの組合せに、さらにいろいろ
な変形例が可能なこと、またそうした変形例も本発明の
範囲にあることは当業者に理解されるところである。
たが、本発明の技術的範囲は上記実施の形態に記載の範
囲には限定されない。上記実施の形態は例示であり、各
構成要素や各処理プロセスの組合せに、さらにいろいろ
な変形例が可能なこと、またそうした変形例も本発明の
範囲にあることは当業者に理解されるところである。
【０１４５】そのような変形例の一例として、本実施の
形態の決済支援システム１０は、購入受付サーバ１０
０、決済支援サーバ２００、決済処理サーバ３００、及
び管理サーバ４００を備えていたが、このような構成は
必須ではなく、これらが１つのサーバとして設けられて
いてもよいし、それぞれのサーバの構成部材の一部また
は全部が他のサーバに設けられていてもよく、その構成
の自由度が非常に高いことは当業者に理解されるところ
である。
形態の決済支援システム１０は、購入受付サーバ１０
０、決済支援サーバ２００、決済処理サーバ３００、及
び管理サーバ４００を備えていたが、このような構成は
必須ではなく、これらが１つのサーバとして設けられて
いてもよいし、それぞれのサーバの構成部材の一部また
は全部が他のサーバに設けられていてもよく、その構成
の自由度が非常に高いことは当業者に理解されるところ
である。
【０１４６】各サーバの運営主体についても、実施の形
態では、購入受付サーバ１００を商品の提供主体が、決
済支援サーバ２００を決済代行業者が、決済処理サーバ
３００をクレジットカード会社が運営する例を中心に説
明したが、これら全てを一つの運営主体が運営してもよ
いし、一つのサーバを複数の運営主体が共同して運営し
てもよい。
態では、購入受付サーバ１００を商品の提供主体が、決
済支援サーバ２００を決済代行業者が、決済処理サーバ
３００をクレジットカード会社が運営する例を中心に説
明したが、これら全てを一つの運営主体が運営してもよ
いし、一つのサーバを複数の運営主体が共同して運営し
てもよい。
【０１４７】実施の形態では、購入受付サーバ１００
は、インターネット３０を介してユーザ端末２０に仮想
的な店舗を提供するウェブサーバであったが、もちろ
ん、購入受付サーバ１００は、現実の店舗に設けられて
購入及び決済の要求を受け付けてもよいし、通信販売な
どユーザと対面しない販売形態の店舗に設けられてユー
ザからの購入及び決済の要求を間接的に受け付けてもよ
い。また、購入受付サーバ１００として、ＰＯＳ端末、
ＣＡＴ端末、ＡＴＭ端末などの端末を利用することもで
きる。
は、インターネット３０を介してユーザ端末２０に仮想
的な店舗を提供するウェブサーバであったが、もちろ
ん、購入受付サーバ１００は、現実の店舗に設けられて
購入及び決済の要求を受け付けてもよいし、通信販売な
どユーザと対面しない販売形態の店舗に設けられてユー
ザからの購入及び決済の要求を間接的に受け付けてもよ
い。また、購入受付サーバ１００として、ＰＯＳ端末、
ＣＡＴ端末、ＡＴＭ端末などの端末を利用することもで
きる。
【０１４８】
【発明の効果】本発明によれば、利便性の高い決済支援
技術を提供することができる。
技術を提供することができる。
【図１】第１の実施の形態に係る決済支援システムの全
体構成を示す図である。
体構成を示す図である。
【図２】第１の実施の形態に係る決済支援システムにお
ける処理の流れを概略的に示す図である。
ける処理の流れを概略的に示す図である。
【図３】第１の実施の形態に係る購入受付サーバ、決済
支援サーバ、及び決済処理サーバの内部構成を示す図で
ある。
支援サーバ、及び決済処理サーバの内部構成を示す図で
ある。
【図４】第１の実施の形態に係る購入受付サーバの符号
情報格納部の内部データを示す図である。
情報格納部の内部データを示す図である。
【図５】第１の実施の形態に係る決済支援システムの機
能を現実の店舗にたとえて表現した図である。
能を現実の店舗にたとえて表現した図である。
【図６】第２の実施の形態に係る購入受付サーバの符号
情報格納部の内部データを示す図である。
情報格納部の内部データを示す図である。
【図７】第３の実施の形態に係る購入受付サーバ、決済
支援サーバ、及び決済処理サーバの内部構成を示す図で
ある。
支援サーバ、及び決済処理サーバの内部構成を示す図で
ある。
【図８】第３の実施の形態に係る購入受付サーバの符号
情報格納部の内部データを示す図である。
情報格納部の内部データを示す図である。
【図９】第３の実施の形態に係る決済支援システムの機
能を現実の店舗にたとえて表現した図である。
能を現実の店舗にたとえて表現した図である。
【図１０】第４の実施の形態に係る購入受付サーバの符
号情報格納部の内部データを示す図である。
号情報格納部の内部データを示す図である。
【図１１】第４の実施の形態に係る決済支援システムの
機能を現実の店舗にたとえて表現した図である。
機能を現実の店舗にたとえて表現した図である。
【図１２】第５の実施の形態に係る決済支援システムに
おける処理の流れを概略的に示す図である。
おける処理の流れを概略的に示す図である。
【図１３】第５の実施の形態に係る購入受付サーバ、決
済支援サーバ、及び決済処理サーバの内部構成を示す図
である。
済支援サーバ、及び決済処理サーバの内部構成を示す図
である。
【図１４】第５の実施の形態に係る決済支援システムの
機能を現実の店舗にたとえて表現した図である。
機能を現実の店舗にたとえて表現した図である。
【図１５】第６の実施の形態に係る購入受付サーバ、決
済支援サーバ、及び決済処理サーバの内部構成を示す図
である。
済支援サーバ、及び決済処理サーバの内部構成を示す図
である。
【図１６】第６の実施の形態に係る決済支援システムの
機能を現実の店舗にたとえて表現した図である。
機能を現実の店舗にたとえて表現した図である。
【図１７】第６の実施の形態に係る決済支援システムに
おいて、符号情報変更部により、符号情報の割り当て状
況が変更された様子を示す図である。
おいて、符号情報変更部により、符号情報の割り当て状
況が変更された様子を示す図である。
【図１８】第７の実施の形態に係る購入受付サーバ、決
済支援サーバ、決済処理サーバ、及び管理サーバの内部
構成を示す図である。
済支援サーバ、決済処理サーバ、及び管理サーバの内部
構成を示す図である。
【図１９】第８の実施の形態に係る決済支援システムに
おける処理の流れを概略的に示す図である。
おける処理の流れを概略的に示す図である。
【図２０】第８の実施の形態に係る購入受付サーバ、決
済支援サーバ、及び決済処理サーバの内部構成を示す図
である。
済支援サーバ、及び決済処理サーバの内部構成を示す図
である。
【図２１】第９の実施の形態に係る決済支援システムに
おける処理の流れを概略的に示す図である。
おける処理の流れを概略的に示す図である。
【図２２】第９の実施の形態に係る決済支援サーバ及び
決済処理サーバの内部構成を示す図である。
決済処理サーバの内部構成を示す図である。
【図２３】第１０の実施の形態に係る決済支援システム
における処理の流れを概略的に示す図である。
における処理の流れを概略的に示す図である。
【図２４】第１０の実施の形態に係る決済支援システム
において、決済支援サーバから購入受付サーバへの応答
情報送信の際に通信障害が発生したときの処理の手順を
示す図である。
において、決済支援サーバから購入受付サーバへの応答
情報送信の際に通信障害が発生したときの処理の手順を
示す図である。
【図２５】第１０の実施の形態に係る決済支援システム
において、購入受付サーバから決済支援サーバへの受信
状況通知の際に通信障害が発生したときの処理の手順を
示す図である。
において、購入受付サーバから決済支援サーバへの受信
状況通知の際に通信障害が発生したときの処理の手順を
示す図である。
【図２６】第１０の実施の形態に係る購入受付サーバ、
決済支援サーバ、及び決済処理サーバの内部構成を示す
図である。
決済支援サーバ、及び決済処理サーバの内部構成を示す
図である。
【図２７】第１１の実施の形態に係る決済支援システム
において、決済支援サーバから購入受付サーバへの応答
情報送信の際に通信障害が発生したときの処理の手順を
示す図である。
において、決済支援サーバから購入受付サーバへの応答
情報送信の際に通信障害が発生したときの処理の手順を
示す図である。
【図２８】第１２の実施の形態に係る決済支援システム
において、決済支援サーバから購入受付サーバへの応答
情報送信の際に通信障害が発生したときの処理の手順を
示す図である。
において、決済支援サーバから購入受付サーバへの応答
情報送信の際に通信障害が発生したときの処理の手順を
示す図である。
【図２９】第１３の実施の形態に係る決済支援システム
における処理の流れを概略的に示す図である。
における処理の流れを概略的に示す図である。
【図３０】第１３の実施の形態に係る購入受付サーバ、
決済支援サーバ、及び決済処理サーバの内部構成を示す
図である。
決済支援サーバ、及び決済処理サーバの内部構成を示す
図である。
【図３１】実施の形態に係る購入受付サーバ、決済支援
サーバ、決済処理サーバ、及び管理サーバのハードウェ
アコンポーネントを示す図である。
サーバ、決済処理サーバ、及び管理サーバのハードウェ
アコンポーネントを示す図である。
【符号の説明】
１０・・・決済支援システム、１００・・・購入受付サ
ーバ、１１４・・・応答情報提示部、１１６・・・金額
変更要求受付部、１１８・・・金額変更要求送信部、１
３０・・・照会情報生成部、１３１・・・要求情報生成
部、１３２・・・符号情報付与部、１３４・・・符号情
報格納部、１３６・・・符号情報管理部、１４０・・・
照会情報保持部、１４２・・・バッチ処理部、１５０・
・・照会情報送信部、１５１・・・要求情報送信部、１
６０・・・応答情報受信部、１６２・・・金額変更応答
受信部、１７０・・・受信状況通知部、１７２・・・判
断部、２００・・・決済支援サーバ、２１０・・・照会
情報受信部、２１１・・・要求情報受信部、２１２・・
・金額変更要求受信部、２１４・・・返品処理要求部、
２１６・・・返品処理応答受信部、２１８・・・再売上
要求部、２２０・・・照会情報受付部、２２１・・・再
売上応答受信部、２２２・・・決済履歴データベース、
２２４・・・返品処理要求取消部、２３２・・・符号情
報付与部、２３４・・・符号情報格納部、２３６・・・
符号情報管理部、２３８・・・符号情報変更部、２４０
・・・照会情報保持部、２４２・・・バッチ処理部、２
５０・・・照会情報送信部、２５１・・・要求情報送信
部、２６０・・・応答情報受信部、２７０・・・応答情
報送信部、２７２・・・受信状況取得部、２７４・・・
判断部、２７６・・・出力部、２７８・・・解放要求送
信部、２８０・・・応答情報変換部、３００・・・決済
処理サーバ、３１０・・・照会情報受付部、３１１・・
・要求情報受付部、３２０・・・与信可否判断部、３２
１・・・オーソリ処理部、３３０・・・ユーザデータベ
ース、３４０・・・応答情報生成部、３５０・・・応答
情報送信部、４００・・・管理サーバ、４３２・・・符
号情報付与部、４３４・・・符号情報格納部。
ーバ、１１４・・・応答情報提示部、１１６・・・金額
変更要求受付部、１１８・・・金額変更要求送信部、１
３０・・・照会情報生成部、１３１・・・要求情報生成
部、１３２・・・符号情報付与部、１３４・・・符号情
報格納部、１３６・・・符号情報管理部、１４０・・・
照会情報保持部、１４２・・・バッチ処理部、１５０・
・・照会情報送信部、１５１・・・要求情報送信部、１
６０・・・応答情報受信部、１６２・・・金額変更応答
受信部、１７０・・・受信状況通知部、１７２・・・判
断部、２００・・・決済支援サーバ、２１０・・・照会
情報受信部、２１１・・・要求情報受信部、２１２・・
・金額変更要求受信部、２１４・・・返品処理要求部、
２１６・・・返品処理応答受信部、２１８・・・再売上
要求部、２２０・・・照会情報受付部、２２１・・・再
売上応答受信部、２２２・・・決済履歴データベース、
２２４・・・返品処理要求取消部、２３２・・・符号情
報付与部、２３４・・・符号情報格納部、２３６・・・
符号情報管理部、２３８・・・符号情報変更部、２４０
・・・照会情報保持部、２４２・・・バッチ処理部、２
５０・・・照会情報送信部、２５１・・・要求情報送信
部、２６０・・・応答情報受信部、２７０・・・応答情
報送信部、２７２・・・受信状況取得部、２７４・・・
判断部、２７６・・・出力部、２７８・・・解放要求送
信部、２８０・・・応答情報変換部、３００・・・決済
処理サーバ、３１０・・・照会情報受付部、３１１・・
・要求情報受付部、３２０・・・与信可否判断部、３２
１・・・オーソリ処理部、３３０・・・ユーザデータベ
ース、３４０・・・応答情報生成部、３５０・・・応答
情報送信部、４００・・・管理サーバ、４３２・・・符
号情報付与部、４３４・・・符号情報格納部。
─────────────────────────────────────────────────────
フロントページの続き
(56)参考文献 特開 平８−329144（ＪＰ，Ａ)
特開 昭60−65376（ＪＰ，Ａ)
特開2000−268097（ＪＰ，Ａ)
特開 平９−252349（ＪＰ，Ａ)
特開 平６−89263（ＪＰ，Ａ)
特開2000−331095（ＪＰ，Ａ)
特開2001−250058（ＪＰ，Ａ)
特開2001−175737（ＪＰ，Ａ)
特開 平11−282735（ＪＰ，Ａ)
特開 平11−215205（ＪＰ，Ａ)
(58)調査した分野(Int.Cl.7，ＤＢ名)
G06F 17/60
ＪＩＣＳＴファイル（ＪＯＩＳ)
Claims (18)
- 【請求項１】 ユーザから商品又は役務の購入要求を受
け付ける購入受付サーバと、 購入に伴う決済を支援する決済支援サーバと、を備え、 複数の要求の並列処理機能と、金額変更処理機能とを有
する決済支援システムにおいて、 前記購入受付サーバは、 前記並列処理機能を実現するために、 ユーザから購入に伴う決済要求を受け付けたときに、そ
のユーザに対する与信の可否を照会するための照会情報
を生成する生成部と、 前記照会情報に付与するための符号情報を複数格納する
格納部と、 前記格納部に格納された複数の前記符号情報のうち、使
用中でない符号情報を読み出して、前記照会情報に付与
する付与部と、 前記照会情報を前記決済支援サーバに送信する第１の照
会情報送信部と、 前記照会に対する応答情報を、決済を行う決済処理サー
バから、前記決済支援サーバを介して受信する応答情報
受信部と、を含み、 前記金額変更処理機能を実現するために、 既に要求した決済の金額を変更するよう要求するための
金額変更要求情報を生成して前記決済支援サーバへ送信
する金額変更要求送信部と、 前記金額変更要求情報に対する金額変更応答情報を前記
決済支援サーバから受信する金額変更応答受信部と、を
含み、 前記決済支援サーバは、 前記並列処理機能を実現するために、 前記購入受付サーバから前記照会情報を受け付けて前記
決済処理サーバへ送信する第２の照会情報送信部と、 前記決済処理サーバから前記応答情報を受け付けて前記
購入受付サーバへ送信する応答情報送信部と、を含み、 前記金額変更処理機能を実現するために、 前記購入受付サーバから、前記既に要求した決済の識別
情報と、変更後の金額 とを含む前記金額変更要求情報を
受け付ける金額変更要求受信部と、 前記既に要求した決済について返品処理を行うよう前記
決済処理サーバへ要求する返品処理要求部と、 前記返品処理に対する返品処理応答情報を前記決済処理
サーバから受信する返品処理応答受信部と、 前記返品処理が成功したときに、つづいて、金額が変更
された新たな決済を前記決済処理サーバへ要求する再売
上要求部と、 前記新たな決済の要求に対する再売上応答情報を前記決
済処理サーバから受信する再売上応答受信部と、を含
み、 前記応答情報送信部は、前記金額変更処理機能を実現す
るときには、前記返品処理応答情報および前記再売上応
答情報に基づいて、前記金額変更応答情報を生成して前
記購入受付サーバへ送信し、 前記購入受付サーバは、既に要求した決済の金額を変更
する際に、返品処理と再売上を要求することなく、１回
だけ金額変更を要求する ことを特徴とする決済支援シス
テム。 - 【請求項２】 前記購入受付サーバは、前記商品又は役
務の複数の提供主体に対する購入要求を受け付け、 前記格納部は、前記提供主体ごとに、その提供主体が利
用可能な複数の符号情報を格納し、 前記付与部は、提供主体が利用可能な複数の符号情報の
うち、使用中でない符号情報を読み出して、前記照会情
報に付与することを特徴とする請求項１に記載の決済支
援システム。 - 【請求項３】 前記購入受付サーバは、前記符号情報の
使用状況を管理する管理部をさらに含み、 前記管理部は、前記符号情報が前記付与部により前記照
会情報に付与されたときに、その符号情報の使用状況を
使用中とし、前記応答情報受信部が前記応答情報を受信
したときに、その応答情報に対応する照会情報に付与さ
れた符号情報の使用状況を非使用中とすることを特徴と
する請求項１または２に記載の決済支援システム。 - 【請求項４】 前記管理部は、所定の時間が経過しても
前記応答情報受信部が前記応答情報を受信しなかったと
きに、その応答情報に対応する照会情報に付与された符
号情報の使用状況を非使用中とすることを特徴とする請
求項３に記載の決済支援システム。 - 【請求項５】 前記格納部は、前記購入受付サーバまた
は前記提供主体による照会の頻度に応じて予め割り当て
られた前記符号情報を格納することを特徴とする請求項
１から４のいずれかに記載の決済支援システム。 - 【請求項６】 前記格納部は、前記提供主体ごとに、そ
の提供主体における照会の頻度の変動状況に応じて動的
に割り当てられた前記符号情報を格納することを特徴と
する請求項２から４のいずれかに記載の決済支援システ
ム。 - 【請求項７】 前記付与部は、前記ユーザが購入する商
品又は役務の種類に基づいて、前記照会情報に付与すべ
き前記符号情報を決定することを特徴とする請求項１か
ら６のいずれかに記載の決済支援システム。 - 【請求項８】 前記付与部は、前記ユーザの属性情報に
基づいて、前記照会情報に付与すべき前記符号情報を決
定することを特徴とする請求項１から７のいずれかに記
載の決済支援システム。 - 【請求項９】 前記決済支援サーバは、決済の履歴情報
を格納する履歴データベースをさらに含み、 前記金額変更要求受信部は、前記既に要求した決済の識
別情報をもとに、前記履歴データベースを参照し、前記
既に要求した決済の金額を取得することを特徴とする請
求項１から８のいずれかに記載の決済支援システム。 - 【請求項１０】 前記返品処理応答受信部が返品処理に
失敗した旨の返品処理応答情報を受信したときに、その
旨を前記応答情報送信部により前記購入受付サーバへ送
信することを特徴とする請求項１から９のいずれかに記
載の決済支援システム。 - 【請求項１１】 前記再売上応答受信部が再売上処理に
失敗した旨の再売上応答情報を受信したときに、その旨
を前記応答情報送信部により前記購入受付サーバへ送信
するとともに、返品処理要求取消部により前記返品処理
を取り消すよう前記決済処理サーバへ要求することを特
徴とする請求項１から１０のいずれかに記載の決済支援
システム。 - 【請求項１２】 ユーザから商品又は役務の購入要求を
受け付ける購入受付サーバと、 購入に伴う決済を支援する決済支援サーバと、を備え、 前記購入受付サーバは、 ユーザから購入に伴う決済要求を受け付けたときに、そ
のユーザに対する与信の可否を照会し、与信枠を確保す
るよう要求するための照会情報を生成する生成部と、 前記照会情報に付与するための符号情報を複数格納する
格納部と、 前記格納部に格納された複数の前記符号情報のうち、使
用中でない符号情報を読み出して、前記照会情報に付与
する付与部と、 前記照会情報を前記決済支援サーバに送信する第１の照
会情報送信部と、 前記照会に対する応答情報を前記決済支援サーバから受
信する応答情報受信部と、 前記応答情報の受信状況を前記決済支援サーバへ通知す
る受信状況通知部と、を含み、 前記決済支援サーバは、 前記購入受付サーバから前記照会情報を受け付けて、決
済処理を行う決済処理サーバへ送信する第２の照会情報
送信部と、 前記決済処理サーバから前記応答情報を受け付けて前記
購入受付サーバへ送信する応答情報送信部と、 前記受信状況を前記購入受付サーバから取得する受信状
況取得部と、を含み、 前記受信状況通知部は、ユーザの端末のウェブブラウザ
のタイムアウト時間よりも短い第２の時間が経過しても
前記応答情報受信部が前記応答情報を受信しなかったと
きに、その旨を前記決済支援サーバへ通知し、 前記決済支援サーバは、前記受信状況通知部から、前記
応答情報を受信しなかった旨の通知を取得したときに、
前記決済処理サーバから与信枠の確保に成功した旨の応
答情報を受信していた場合には、前記決済処理サーバ
に、確保された与信枠を解放するよう要求する解放要求
送信部をさらに含む ことを特徴とする決済支援システ
ム。 - 【請求項１３】 前記購入受付サーバは、前記第２の時
間が経過しても前記応答情報受信部が前記応答情報を受
信しなかったときに、その決済の要求を取り消すか否か
を判断する第１の判断部をさらに含み、 前記受信状況通知部は、前記第１の判断部が前記決済の
要求を取り消すと判断したときに、その旨を前記決済支
援サーバへ通知し、 前記決済支援サーバは、前記受信状況通知部から、前記
決済の要求を取り消す旨の通知を取得したときに、前記
決済処理サーバに、確保された与信枠を解放するよう要
求する解放要求送信部をさらに含む ことを特徴とする請
求項１２に記載の決済支援システム。 - 【請求項１４】 前記解放要求送信部は、ユーザの端末
のウェブブラウザのタイムアウト時間よりも長い第３の
時間が経過しても前記受信状況取得部が前記受信状況を
受信しなかったときに、前記決済処理サーバに、確保さ
れた与信枠を解放するよう要求することを特徴とする請
求項１２または１３に記載の決済支援システム。 - 【請求項１５】 ユーザから商品又は役務の購入要求を
受け付ける購入受付サーバと、 購入に伴う決済を支援する決済支援サーバと、を備え、 前記購入受付サーバは、 ユーザから購入に伴う決済要求を受け付けたときに、そ
のユーザに対する与信の可否を照会し、与信枠を確保す
るよう要求するための照会情報を生成する生成部と、 前記照会情報に付与するための符号情報を複数格納する
格納部と、 前記格納部に格納された複数の前記符号情報のうち、使
用中でない符号情報を読み出して、前記照会情報に付与
する付与部と、 前記照会情報を前記決済支援サーバに送信する第１の照
会情報送信部と、 前記照会に対する応答情報を前記決済支援サーバから受
信する応答情報受信部と、 前記応答情報の受信状況を前記決済支援サーバへ通知す
る受信状況通知部と、を含み、 前記決済支援サーバは、 前記購入受付サーバから前記照会情報を受け付けて、決
済処理を行う決済処理サーバへ送信する第２の照会情報
送信部と、 前記決済処理サーバから前記応答情報を受け付けて前記
購入受付サーバへ送信する応答情報送信部と、 前記受信状況を前記購入受付サーバから取得する受信状
況取得部と、を含み、 前記受信状況通知部は、前記応答情報受信部が前記応答
情報を受信したときに、その旨を前記決済支援サーバへ
通知し、 前記応答情報受信部は、第１の時間が経過しても前記応
答情報を受信しなかったときに、前記決済支援サーバに
前記応答情報の送信を要求し、 前記決済支援サーバは、ユーザの端末のウェブブラウザ
のタイムアウト時間よりも長い第３の時間が経過しても
前記受信状況取得部が前記受信状況を受信しなかったと
きに、前記決済処理サーバから与信枠の確保に成功した
旨の応答情報を受信していた場合には、前記決済処理サ
ーバに、確保された与信枠を解放するよう要求する解放
要求送信部をさらに含む ことを特徴とする決済支援シス
テム。 - 【請求項１６】 前記決済支援サーバは、前記第３の時
間が経過しても前記受信状況取得部が前記受信状況を受
信しなかったときに、前記決済処理サーバに確保された
与信枠を解放するよう要求するか否かを判断する第２の
判断部をさらに含み、前記解放要求送信部は、 前記第２の判断部が要求すると
判断したときに、前記決済処理サーバに、確保された与
信枠を解放するよう要求することを特徴とする請求項１
４または１５に記載の決済支援システム。 - 【請求項１７】 前記決済支援サーバは、前記第３の時
間が経過しても前記受信状況取得部が前記受信状況を受
信しなかった決済の情報を出力する出力部をさらに備え
ることを特徴とする請求項１４から１６のいずれかに記
載の決済支援システム。 - 【請求項１８】 前記解放要求送信部は、前記第３の時
間が経過しても前記受信状況取得部が前記受信状況を受
信しなかった決済について、与信枠を確保できたにも関
わらず、前記購入受付サーバが前記応答情報を受信して
いなかったことを示す確認情報を取得したときに、前記
決済処理サーバに、確保された与信枠を解放するよう要
求することを特徴とする請求項１７に記載の決済支援シ
ステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001328283A JP3410087B2 (ja) | 2001-10-25 | 2001-10-25 | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001328283A JP3410087B2 (ja) | 2001-10-25 | 2001-10-25 | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002377641A Division JP2003203192A (ja) | 2002-12-26 | 2002-12-26 | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003132285A JP2003132285A (ja) | 2003-05-09 |
| JP3410087B2 true JP3410087B2 (ja) | 2003-05-26 |
Family
ID=19144374
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001328283A Expired - Lifetime JP3410087B2 (ja) | 2001-10-25 | 2001-10-25 | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3410087B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5611610B2 (ja) * | 2010-02-10 | 2014-10-22 | Ｊｒ東日本メカトロニクス株式会社 | 制御装置、サービス提供装置、読書装置、制御方法、サービス提供方法、読書方法、及びプログラム |
-
2001
- 2001-10-25 JP JP2001328283A patent/JP3410087B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003132285A (ja) | 2003-05-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6246996B1 (en) | Computerized system for facilitating transactions between parties on the internet using e-mail | |
| US10157375B2 (en) | Alternative payment implementation for electronic retailers | |
| US8762210B2 (en) | Alternative payment implementation for electronic retailers | |
| JP3970869B2 (ja) | 取引を容易にする方法 | |
| WO2018006716A1 (zh) | 订单信息处理方法、装置及系统 | |
| JP2001344548A (ja) | オンライン決済システム、その方法及び記録媒体 | |
| AU2006228895B2 (en) | Self-owned resources interactive method and processing method of electronic trade information and system | |
| JP2015535365A (ja) | 電子支払取引の紛争解決を提供するためのシステム及び方法 | |
| JP2001273453A (ja) | ポイント管理方法、ポイント管理システム、中央装置、及び記録媒体 | |
| WO2019204123A1 (en) | Method and system for pre-authorizing a delivery transaction | |
| US20080228655A1 (en) | Secure Payment Method and System on Network and Route Server | |
| JP2000357155A (ja) | メッセージ検索システム | |
| CN112633954B (zh) | 基于区块链的权益处理方法及装置 | |
| JP3410087B2 (ja) | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム | |
| TW200405189A (en) | Payment escrow system and payment escrow method | |
| JP2000331227A (ja) | 決済システム、決済方法、プリペイド管理サーバおよびプリペイド管理方法 | |
| TW200527247A (en) | Request for quote system and method | |
| JP2003203192A (ja) | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム | |
| JP2005050379A (ja) | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム | |
| JP2005050378A (ja) | 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム | |
| JP2003076885A (ja) | 取引仲介システム及び仲介方法 | |
| WO2001097122A1 (en) | Online exchange method using exchange matter and payment insurance and management system thereof | |
| TW466430B (en) | Method and apparatus of assisting and expediting the negotiation processes of business transactions | |
| CN113487413A (zh) | 一种账务处理方法、装置、电子设备及计算机可读介质 | |
| CN116911999A (zh) | 一种资金交易方法、装置、设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3410087 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090320 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100320 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110320 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110320 Year of fee payment: 8 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110320 Year of fee payment: 8 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120320 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120320 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130320 Year of fee payment: 10 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140320 Year of fee payment: 11 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |