JP2005050379A - 決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラム - Google Patents

Abstract

【課題】利便性の高い決済支援技術を提供する。
【解決手段】決済支援システム１０において、ユーザから商品の購入に伴う決済要求を受け付けた購入受付サーバ１００は、そのユーザに対する与信の可否を決済処理サーバ３００に照会するための照会情報を生成し、照会情報に付与するための符号情報を複数格納したテーブルから、使用中でない符号情報を読み出して照会情報に付与し、符号情報を付与した照会情報を決済支援サーバ２００に送信する。決済支援サーバ２００は、照会情報を決済処理サーバ３００に送信して与信照会を行い、決済処理サーバ３００からの応答情報を購入受付サーバ１００へ送信する。複数の符号情報を利用して、同時に複数の与信照会を並列して行う。
【選択図】図１

Description

本発明は、決済支援技術に関し、とくに、商品又は役務の購入に伴う決済を支援する決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラムに関する。

近年、パーソナルコンピュータなどの端末が広く普及するとともに、ネットワークインフラの整備が急速に進み、インターネット、とくに、ＷＷＷ（World Wide Web）の利用者が激増している。対面、非対面を問わず、会社でも、自宅でも、携帯端末や携帯電話などの移動端末を利用して移動中でもアクセスできるというＷＷＷの特徴を生かし、ＷＷＷを利用して商品又は役務の提供、販売を行うオンラインショッピングサイトが数多く開設されている。このような消費者向け（ＢｔｏＣ）の電子商取引技術は、消費者には、自宅や会社にいながらにしてさまざまな商品を購入できるという利点をもたらし、販売主体には、宣伝広告費や運営費などの経費を削減でき、さらに、世界中の消費者をターゲットにできるという利点をもたらした。

電子商取引が広く利用されるようになり、クレジットカードなどを利用した電子決済技術も注目を集めるようになっている。電子商取引においてクレジットカードによる決済を行う場合、ユーザに対する与信の可否の照会及び与信枠の確保の要求（以下、「オーソリ要求」ともいう。）をリアルタイムに行おうとすると、現実の店舗におけるＣＡＴ（Credit Authorization Terminal）端末の機能を、オンラインショッピングサイトを提供するサーバに持たせる必要があるが、このような機能を実現するシステムを導入し、決済業務の一部を代行する業者の出現により、クレジットカードによる決済を扱うオンラインショッピングサイトが増加し、電子決済技術が広く浸透してきている。

クレジットカードによる決済業務を実現する金融ネットワークでは、店舗からクレジットカード会社に与信照会要求を送信するためのＰＯＳ（Point-Of-Sale）端末、ＣＡＴ（Credit Authorization Terminal）端末、ＡＴＭ（Automated Teller Machine）端末などの照会端末のそれぞれに端末識別番号を一意的に割り当て、端末識別番号を用いて与信照会の送信元を識別している。このため、一つの端末から同時に複数の与信照会要求を送信することは想定されておらず、ある端末識別番号の端末からの与信照会の処理中に、それと同一の端末識別番号により与信照会を要求することは許されない。電子商取引における仮想店舗の場合、同時に複数のユーザがアクセスして決済を要求する可能性があるが、与信照会は一度に一人ずつしか行えないため、ユーザを長時間待たせることになる恐れがあった。従来は、オンラインショッピングサイトを提供するサーバの処理能力の問題で、一度に多くのユーザを扱いきれなかったが、サーバの処理能力の向上に伴い同時に多くのユーザがオンラインショッピングサイトにアクセス可能となった現在、与信照会の際の待ち時間の問題はより顕著となり、迅速さが求められる電子商取引においては致命的な問題となりかねない。

また、決済処理に関する情報を、ネットワークを利用して送受信する以上、通信障害により生じる処理結果の認識の不整合は、完全には排除しきれない問題である。たとえば、店舗がクレジットカード会社にユーザの与信枠の確保を要求したとき、クレジットカード会社は与信枠の確保に成功して応答情報を送信したにも関わらず、その応答情報が何らかの通信障害により店舗側に届かなかった場合、クレジットカード会社側では与信枠の確保に成功したと認識され、店舗側では与信枠の確保に失敗したと認識されるため、両者に不整合が生じる。このような不整合の発生を最小限に抑えるとともに、不整合が発生したときに的確に検知し、適切に対処する技術が求められる。

さらに、クレジットカード会社と店舗との契約上の制限により、店舗側に無用な負担を強いている場合があった。たとえば、一度要求した決済の金額を変更する場合、契約上は一部を返品する処理が認められていなかったため、いったん元の決済について返品処理を要求したあと、つづいて、変更後の金額による新たな決済を要求する必要がある。より多くの店舗にクレジットカードを利用した電子決済サービスを導入させ、電子決済サービスを一般に広く浸透させるためには、決済代行業者がこのような店舗側の負担をできる限り吸収し、より利便性の高い決済支援技術を提供していく必要がある。

そこで、本発明は、上記の課題を解決することのできる決済支援システム、決済支援サーバ、決済支援方法、及び決済支援機能をコンピュータに実現させるプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組合せにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記目的を達成するために、本発明の第１の形態に係る決済支援システムは、ユーザから商品又は役務の購入要求を受け付ける購入受付サーバと、購入に伴う決済を支援する決済支援サーバと、を備え、前記購入受付サーバは、既に要求した決済の金額を変更するよう要求するための金額変更要求情報を生成して前記決済支援サーバへ送信する金額変更要求送信部と、前記金額変更要求情報に対する金額変更応答情報を前記決済支援サーバから受信する金額変更応答受信部と、含み、前記決済支援サーバは、前記購入受付サーバから、前記既に要求した決済の識別情報と、変更後の金額とを含む前記金額変更要求情報を受け付ける金額変更要求受信部と、前記既に要求した決済について返品処理を行うよう、決済処理を行う決済処理サーバへ要求する返品処理要求部と、前記返品処理に対する返品処理応答情報を前記決済処理サーバから受信する返品処理応答受信部と、前記返品処理が成功したときに、つづいて、金額が変更された新たな決済を前記決済処理サーバへ要求する再売上要求部と、前記新たな決済の要求に対する再売上応答情報を前記決済処理サーバから受信する再売上応答受信部と、前記返品処理応答情報および前記再売上応答情報に基づいて、前記金額変更応答情報を生成して前記購入受付サーバへ送信する金額変更応答送信部と、を含み、前記購入受付サーバは、既に要求した決済の金額を変更する際に、返品処理と再売上を要求することなく、１回だけ金額変更を要求することを特徴とする。

金額変更に必要な、返品処理及び再売上の要求を、決済支援サーバが代行するので、購入受付サーバは、金額変更を決済支援サーバに１回要求するだけでよい。これにより、加盟店側の負担を軽減することができる。

金額変更要求情報は、既に要求した決済の識別情報と、新たな決済の識別情報と、変更後の金額とを含んでもよい。決済支援サーバは、決済の履歴情報を格納する履歴データベースをさらに含み、金額変更要求受信部は、既に要求した決済の識別情報をもとに、履歴データベースを参照し、既に要求した決済の金額を取得してもよい。返品処理応答受信部が返品処理に失敗した旨の返品処理応答情報を受信したときに、その旨を金額変更応答送信部により購入受付サーバへ送信してもよい。再売上応答受信部が再売上処理に失敗した旨の再売上応答情報を受信したときに、その旨を金額変更応答送信部により購入受付サーバへ送信するとともに、返品処理要求取消部により返品処理を取り消すよう決済処理サーバへ要求してもよい。

本発明の第２の形態に係る決済支援方法は、商品又は役務の購入要求を受け付ける購入受付サーバが、既に要求した決済の金額を変更するよう要求するために、前記既に要求した決済の識別情報と、変更後の金額とを含む金額変更要求情報を生成して、決済を支援する決済支援サーバへ送信する工程と、前記決済支援サーバが、前記購入受付サーバから前記金額変更要求情報を受信し、前記金額変更要求情報をもとに、前記既に要求した決済について返品処理を行うよう、決済処理を行う決済処理サーバへ要求する工程と、前記決済処理サーバが、前記返品処理を行い、その返品処理に対する返品処理応答情報を生成して、前記決済支援サーバに送信する工程と、前記決済支援サーバが、前記決済処理サーバから前記返品処理応答情報を受信し、前記返品処理が成功していたときに、つづいて、金額が変更された新たな決済を前記決済処理サーバへ要求する工程と、前記決済処理サーバが、前記新たな決済処理を行い、その決済処理に対する再売上応答情報を生成して、前記決済支援サーバへ送信する工程と、前記決済支援サーバが、前記決済処理サーバから前記再売上応答情報を受信し、前記返品処理応答情報および前記再売上応答情報に基づいて、前記金額変更要求に対する金額変更応答情報を生成して前記購入受付サーバへ送信する工程と、を含み、前記購入受付サーバは、既に要求した決済の金額を変更する際に、返品処理と再売上を要求することなく、１回だけ金額変更を要求することを特徴とする。

本発明の第３の形態に係る決済支援サーバは、ユーザから商品又は役務の購入要求を受け付ける購入受付サーバから、前記購入受付サーバが既に要求した決済の金額を変更するよう要求するための金額変更要求情報を受け付ける金額変更要求受信部と、前記既に要求した決済について返品処理を行うよう、決済処理を行う決済処理サーバへ要求する返品処理要求部と、前記返品処理に対する返品処理応答情報を前記決済処理サーバから受信する返品処理応答受信部と、前記返品処理が成功したときに、つづいて、前記購入受付サーバから再売上要求を受信せずとも、金額が変更された新たな決済を前記決済処理サーバへ要求する再売上要求部と、前記新たな決済の要求に対する再売上応答情報を前記決済処理サーバから受信する再売上応答受信部と、前記返品処理応答情報および前記再売上応答情報に基づいて、前記金額変更要求情報に対する金額変更応答情報を生成して前記購入受付サーバへ送信する金額変更応答送信部と、を含み、前記金額変更要求情報は、前記既に要求した決済の識別情報と、変更後の金額とを含み、前記購入受付サーバが既に要求した決済の金額を変更する際に、前記購入受付サーバから返品処理と再売上を受け付けることなく、１回だけ金額変更を受け付けることを特徴とする。

本発明の第４の形態に係るプログラムは、コンピュータに、ユーザから商品又は役務の購入要求を受け付ける購入受付サーバから、前記購入受付サーバが既に要求した決済の金額を変更するよう要求するための金額変更要求情報を受け付ける機能と、前記既に要求した決済について返品処理を行うよう、決済処理を行う決済処理サーバへ要求する機能と、前記返品処理に対する返品処理応答情報を前記決済処理サーバから受信する機能と、前記返品処理が成功したときに、つづいて、金額が変更された新たな決済を前記決済処理サーバへ要求する機能と、前記新たな決済の要求に対する再売上応答情報を前記決済処理サーバから受信する機能と、前記返品処理応答情報および前記再売上応答情報に基づいて、前記金額変更要求情報に対する金額変更応答情報を生成して前記購入受付サーバへ送信する機能と、を実現させ、前記金額変更要求情報は、前記既に要求した決済の識別情報と、変更後の金額とを含み、前記購入受付サーバが既に要求した決済の金額を変更する際に、前記購入受付サーバから返品処理と再売上を受け付けることなく、１回だけ金額変更を受け付けることを特徴とする。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴の組合せも又発明となりうる。また、本発明の表現を装置、方法、システム、コンピュータプログラムの間で置換したものもまた、本発明の態様として有効である。

本発明によれば、利便性の高い決済支援技術を提供することができる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施の形態は特許請求の範囲に係る発明を限定するものではなく、又実施の形態の中で説明されている特徴の組合せの全てが発明の解決手段に必須であるとは限らない。

（第１の実施の形態）
図１は、第１の実施の形態に係る決済支援システム１０の全体構成を示す。決済支援システム１０において、ユーザの端末２０、購入受付サーバ１００、及び決済支援サーバ２００は、それぞれネットワークの一例としてのインターネット３０に接続されている。また、決済支援サーバ２００及び決済処理サーバ３００は、ネットワークの一例としての専用線４０に接続されている。ネットワークとして、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、その他、有線又は無線の任意の通信手段を利用してもよい。本実施の形態では、高い安全性及び機密性を確保するために、決済支援サーバ２００と決済処理サーバ３００とを専用線４０により接続している。

購入受付サーバ１００は、ユーザ端末２０から商品又は役務（以下、簡便のため「商品」で代表させる。）の購入要求を受け付ける。本実施の形態では、購入受付サーバ１００はウェブサーバとしての機能を有しており、インターネット３０を介して、自身が提供する商品に関する情報を含むウェブページをユーザ端末２０に配信し、ユーザ端末２０から商品の購入要求及び購入に伴う決済要求を受け付ける。すなわち、購入受付サーバ１００は、インターネット３０を介した電子商取引を実現する仮想的な店舗を提供する。

決済処理サーバ３００は、商品の購入に伴う代金の決済処理を行う。決済処理サーバ３００は、クレジットカード会社などの消費者与信業者が運営してもよいし、クレジットカード会社などから決済業務を委託された業者が運営してもよいし、金融機関が運営してもよい。本実施の形態では、簡便のため、決済処理サーバ３００をクレジットカード会社が運営しているものとして説明する。決済処理サーバ３００は、決済支援サーバ２００を介して各購入受付サーバ１００から決済要求を受け付け、ユーザに対する与信が可能か否かの判断や、ユーザの与信枠の確保、解放などの処理を行う。

決済支援サーバ２００は、購入受付サーバ１００から与信照会や与信枠確保などの要求を受け付け、決済処理サーバ３００との間で必要な処理を代行し、その結果を購入受付サーバ１００に送信する。決済処理サーバ３００との間の通信は、上述のＣＡＦＩＳを利用して行われてもよい。決済支援サーバ２００は、購入受付サーバ１００と決済処理サーバ３００との間で、決済に関する処理を仲介するだけでなく、決済に付随するさまざまなサービスを購入受付サーバ１００または店舗の運営主体に提供する。

以下、「ユーザ」というとき、ユーザ自身とユーザの端末をとくに区別しない。また、「店舗」という語を用いるとき、現実の店舗を意味するときもあり、購入受付サーバ１００が提供する仮想的な店舗を意味するときもあり、双方を区別せずに用いるときもある。また、「店舗」という語を、その店舗の運営主体と同義に用いることもあり、その店舗で扱われる商品又は役務の提供主体と同義に用いることもある。

図２は、本実施の形態の決済支援システム１０における一連の処理の流れを概略的に示す。ユーザが購入受付サーバ１００に商品の購入を要求し（Ｓ１００）、その商品の購入に伴う決済の方法として、クレジットカードなど、与信照会が必要な決済を要求した場合（Ｓ１０２）、購入受付サーバ１００は、ユーザからクレジットカードの番号や有効期限など、与信の照会に必要な情報を受け付けて照会情報を生成する（Ｓ１０４）。つづいて、購入受付サーバ１００は、照会情報に付与すべき符号情報を複数格納したテーブルから、使用中でない符号情報を読み出して照会情報に付与する（Ｓ１０６）。このとき、付与した符号情報の使用状況を「使用中」に設定しておき、以降、その符号情報を利用できないようにロックする。購入受付サーバ１００は、符号情報を付与した照会情報を決済支援サーバ２００に送信する（Ｓ１０８）。決済支援サーバ２００は、購入受付サーバ１００から受け付けた照会情報を決済処理サーバ３００へ送信する（Ｓ１１０）。

決済処理サーバ３００は、決済支援サーバ２００から受け付けた照会情報に基づいて、ユーザに対する与信の可否を判断し（Ｓ１１２）、その判断結果を含む応答情報を生成し（Ｓ１１４）、決済支援サーバ２００に送信する（Ｓ１１６）。決済支援サーバ２００は、決済処理サーバ３００から受け付けた応答情報を購入受付サーバ１００へ送信する（Ｓ１１８）。このとき、符号情報を参照して、どの購入受付サーバ１００へ送信すべきかを判断する。購入受付サーバ１００は、決済支援サーバ２００から応答情報を受信すると、その応答情報に対応する照会情報に付与されていた符号情報の使用状況を「非使用中」に設定し、以降、その符号情報を利用できるよう解放する（Ｓ１２０）。購入受付サーバ１００は、決済を要求したユーザに応答情報を提示する（Ｓ１２２）。以上の手順により、ユーザ及び購入受付サーバ１００は、クレジットカードによる決済の可否を知ることができる。

図３は、購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成を示す。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

購入受付サーバ１００は、購入要求受付部１１０、決済要求受付部１１２、応答情報提示部１１４、照会情報生成部１３０、符号情報付与部１３２、符号情報格納部１３４、符号情報管理部１３６、照会情報送信部１５０、及び応答情報受信部１６０を含む。購入要求受付部１１０は、ユーザ端末２０から商品の購入要求を受け付ける。決済要求受付部１１２は、ユーザ端末２０から商品の購入に伴う決済の要求を受け付ける。購入要求受付部１１０及び決済要求受付部１１２は、購入又は決済の要求を受け付けるためのウェブページをユーザ端末２０に提示し、ＣＧＩ（Common Gateway Interface）、ＳＳＩ（Server Side Include）などの機能により要求を受け付けてもよい。このとき、ユーザのクレジットカード番号、有効期限、連絡先など、必要な情報をユーザから取得する。照会情報生成部１３０は、決済要求受付部１１２が受け付けた情報をもとに、ユーザに対する与信の可否を決済処理サーバ３００に照会するための照会情報を生成する。

符号情報格納部１３４は、照会情報に付与するための符号情報を複数格納する。図４はその構成例であり、符号情報欄５００及び使用状況欄５０２が設けられている。一例として、符号情報「０００１」及び「０００２」は現在「使用中」であり、符号情報「０００３」及び「０００４」は現在「非使用中」であることが記録されている。符号情報は、照会情報の送信元を識別するための端末識別番号であってもよい。符号情報格納部１３４に格納される符号情報は、商品の提供主体が契約したクレジットカード会社又は決済支援サーバの運営主体により、予め割り当てられてもよい。割り当てられる符号情報の数は、その店舗から要求される与信照会の頻度に応じて定められてもよい。

店舗が利用する符号情報を予めクレジットカード会社に登録しておく必要がある場合は、登録した符号情報を符号情報格納部１３４に格納する。登録の必要がない場合は、照会要求の頻度などの状況に応じて、割り当てる符号情報の数を動的に変更してもよい。たとえば、１ヶ月ごとに照会要求の頻度を集計し、頻度の高い店舗に多くの符号情報を割り当て、頻度の低い店舗に少ない符号情報を割り当ててもよい。符号情報格納部１３４の更新は、購入受付サーバ１００の図示しない入力インターフェイスにより運営主体が行ってもよいし、ネットワークを介して決済支援サーバ２００又は決済処理サーバ３００が行ってもよい。更新の時間間隔を短くとって、与信照会要求の発生状況をリアルタイムに反映させてもよい。たとえば、タイムセールの実施などの要因により、一時的に多くのユーザがアクセスして与信照会処理が集中している店舗に、一時的に多くの符号情報を割り当てて迅速に与信照会処理が実行できるようにしてもよい。

符号情報付与部１３２は、符号情報格納部１３４に格納された符号情報のうち、使用中でない符号情報を読み出して照会情報に付与する。符号情報付与部１３２は、符号情報格納部１３４に格納された全ての符号情報が使用中であった場合は、いずれかの符号情報が非使用中になるまで待機し、非使用中となった符号情報を順次読み出して照会情報に付与する。このとき、ユーザ端末２０のウェブブラウザがタイムアウト処理を行う前に、ユーザ端末２０に応答情報を送信する必要があるので、ウェブブラウザのタイムアウト時間よりも短いタイムアウト時間を設定しておき、そのタイムアウト時間が経過すると、他のユーザが与信照会中のため、与信照会が行えなかった旨の応答情報を、応答情報提示部１１４を介してユーザ端末２０に提示する。

照会情報送信部１５０は、符号情報が付与された照会情報を決済支援サーバ２００に送信する。応答情報受信部１６０は、決済支援サーバ２００から応答情報を受信する。応答情報提示部１１４は、応答情報をユーザ端末２０に提示する。応答情報受信部１６０は、照会情報送信部１５０が照会情報を送信してから所定の時間が経過しても応答情報を受信しなかったときに、決済支援サーバ２００に応答情報の送信を要求してもよい。それでも応答情報を受信できず、所定のタイムアウト時間が経過したときは、応答情報が得られなかった旨の応答情報を、応答情報提示部１１４を介してユーザ端末２０に提示する。

符号情報管理部１３６は、符号情報格納部１３４に格納された符号情報の使用状況を管理する。符号情報管理部１３６は、符号情報付与部１３２により照会情報に付与された符号情報の使用状況を「使用中」に設定し、他の与信照会に利用できないように制限する。また、応答情報受信部１６０が受信した応答情報に対応する照会情報に付与されていた符号情報の使用状況を「非使用中」に設定し、新たな与信照会に利用できるように解放する。これにより、ある符号情報が付与された照会情報の処理中に、それと同一の符号情報が付与された照会情報を送信することを防ぐことができる。上述のように、所定のタイムアウト時間が経過しても応答情報が得られなかったときに、その応答情報に対応する照会情報に付与されていた符号情報の使用状況を「非使用中」に設定してもよい。これにより、応答情報が返ってこない照会情報に付与されていた符号情報の使用制限を適切に解放することができ、限られた符合情報を効率よく使い回すことができる。

決済支援サーバ２００は、照会情報受信部２１０、照会情報送信部２５０、応答情報受信部２６０、及び応答情報送信部２７０を含む。照会情報受信部２１０は、購入受付サーバ１００から照会情報を受信する。照会情報送信部２５０は、照会情報受信部２１０が受信した照会情報を、決済処理サーバ３００へ送信する。応答情報受信部２６０は、決済処理サーバ３００から応答情報を受信する。応答情報送信部２７０は、応答情報受信部２６０が受信した応答情報を購入受付サーバ１００へ送信する。このように、決済支援サーバ２００は、購入受付サーバ１００から与信照会の依頼を受け付け、決済処理サーバ３００への与信照会処理を代行し、その結果を購入受付サーバ１００へ通知する。

決済処理サーバ３００は、照会情報受付部３１０、与信可否判断部３２０、ユーザデータベース３３０、応答情報生成部３４０、及び応答情報送信部３５０を含む。照会情報受付部３１０は、決済支援サーバ２００から照会情報を受け付ける。照会情報受付部３１０は、購入受付サーバ１００又は店舗の端末から直接照会情報を受け付けてもよい。本実施の形態の照会情報受付部３１０は、照会情報に付与された符号情報により照会情報の送信元を識別し、ある符号情報が付与された照会情報の処理中に、それと同一の符号情報が付与された照会情報を受信したとき、後に受信した照会情報の受け付けを拒否する。与信可否判断部３２０は、照会情報受付部３１０にて受け付けた照会情報をもとに、ユーザデータベース３３０を参照して、ユーザに対する与信が可能か否かを判断する。与信可否判断部３２０は、与信が可能であったときに、そのユーザの与信枠を確保してもよい。ユーザデータベース３３０は、ユーザのクレジットカードの番号、有効期限、与信枠、利用可否情報などを格納する。応答情報生成部３４０は、与信可否判断部３２０による判断結果を含む応答情報を生成する。応答情報送信部３５０は、応答情報生成部３４０にて生成された応答情報を決済支援サーバ２００に送信する。

図５は、本実施の形態の決済支援システム１０の機能を現実の店舗にたとえて表現した図である。購入受付サーバ１００は、電子商取引を実現する仮想店舗を提供する。購入要求受付部１１０は、商品の情報をウェブページによりユーザに提示し、商品の購入要求を受け付ける仮想の売り場１８０に相当し、決済要求受付部１１２は、決済要求を受け付ける仮想の決済受付窓口１８２に相当する。さらに、符号情報格納部１３４に格納された符号情報の数だけ、仮想のＣＡＴ端末１８４が実現される。それぞれの仮想ＣＡＴ端末１８４には、符号情報の一例としての端末識別番号が割り当てられており、現実のＣＡＴ端末と同様に、一度に一つの与信照会要求を送信することができる。符号情報付与部１３２の機能は、空いている仮想ＣＡＴ端末１８４を選択して与信照会を依頼することに相当する。与信照会を行うユーザの数が、仮想ＣＡＴ端末１８４の数、すなわち符号情報格納部１３４に格納された端末識別番号の数を超えたときは、仮想決済受付窓口１８２にてユーザを待機させ、空いた仮想ＣＡＴ端末１８４を順次使用して与信照会を行う。

上記の通り、本実施の形態の決済支援システム１０では、符号情報格納部１３４に複数の符号情報を格納しておき、それらのうち使用中でないものを順次照会情報に付与して送信することで、同時に複数の与信照会要求を並列に処理することができる。これにより、与信照会を迅速に行うことができ、与信照会の際のユーザの待ち時間を減らすことができる。また、与信照会の頻度に合わせて符号情報を割り当てることにより、限られた数の符号情報を効率よく利用することができる。さらに、購入受付サーバ１００側が符号情報の付与を担当し、購入受付サーバ１００ごとに同時並行処理を実現することができるので、必要な処理を分散させ、決済支援サーバ２００側の負担を軽減することができる。

（第２の実施の形態）
つづいて、第２の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０では、ユーザが購入する商品の種類や、ユーザの属性情報に応じて定められた符号情報を照会情報に付与する。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。また、決済支援サーバ２００及び決済処理サーバ３００の内部構成も、図３に示した第１の実施の形態の決済支援サーバ２００及び決済処理サーバ３００と同様である。購入受付サーバ１００の内部構成のうち、図３に示した第１の実施の形態の購入受付サーバ１００と異なる点について説明する。

図６は、本実施の形態の符号情報格納部１３４の構成例であり、符号情報欄５００、使用状況欄５０２、商品種別欄５０４、及びユーザ属性欄５０６が設けられている。一例として、符号情報「０００１」は、現在「使用中」であり、商品種別が「本」でユーザ属性が「男性」である照会情報に付与されることが記録されている。

符号情報付与部１３２は、照会情報生成部１３０が生成した照会情報を参照し、商品種別とユーザ属性情報に基づいて、その照会情報に付与すべき符号情報を決定する。たとえば、図６の例では、商品種別が「家具」である照会情報には、符号情報「０００４」を付与するが、これは現在「非使用中」であるから、符号情報付与部１３２は照会情報に符号情報「０００４」を付与して照会情報送信部１５０に送る。また、商品種別が「本」であり、ユーザ属性情報が「女性」である照会情報には、符号情報「０００３」を付与するが、これは現在「使用中」であるから、その照会が終了して符号情報「０００３」が「非使用中」になるまで待機する。その他の構成及び動作は、第１の実施の形態と同様である。

再び図５を用いて、本実施の形態の決済支援システム１０を現実の店舗と対比して説明すると、商品種類ごとに付与する符号情報を変えることは、商品種類により分別された売り場ごとにＣＡＴ端末を設けることに相当する。また、ユーザの属性情報ごとに付与する符号情報を変えることは、ユーザの属性情報ごとに専用のＣＡＴ端末を設けることに相当する。これにより、符号情報、すなわち仮想端末ごとに売上を集計することで、商品別の売上状況や、ユーザ属性別の売上状況を把握することができ、売上の管理が容易となる。また、これらの情報をマーケティングに利用することもできる。符号情報と、商品種類又はユーザ属性情報との対応は、予め固定的に定められてもよいし、与信照会の頻度に応じて動的に変更されてもよい。たとえば、「本」の購入に伴う決済要求の頻度が高い場合は、商品種類「本」に対応する符号情報の数を多くしてもよい。これは、現実の店舗でいうと、「本」の売り場のＣＡＴ端末を増やすことに相当する。

上記の通り、本実施の形態の決済支援システム１０によれば、同時に複数の与信照会を並列に処理できるとともに、主に店舗側における決済データの管理の効率を向上させることができる。

（第３の実施の形態）
つづいて、第３の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０では、一つの購入受付サーバ１００内に複数の仮想店舗が設けられている。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。

図７は、第３の実施の形態に係る購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成を示す。本実施の形態の決済支援サーバ２００及び決済処理サーバ３００の内部構成は、図３に示した第１の実施の形態の決済支援サーバ２００及び決済処理サーバ３００と同様である。購入受付サーバ１００の内部構成のうち、図３に示した第１の実施の形態の購入受付サーバ１００と異なる点について説明する。

本実施の形態では、購入要求受付部１１０が複数設けられている。それぞれの購入要求受付部１１０は、独立した仮想店舗の売り場として機能する。たとえば、購入要求受付部１１０ａは、店舗Ａの扱う商品の情報を提示して、その商品の購入要求を受け付け、購入要求受付部１１０ｂは、店舗Ｂの扱う商品の情報を提示して、その商品の購入要求を受け付ける。それぞれの仮想店舗においてクレジットカードによる決済を希望するユーザがいれば、決済要求受付部１１２にて必要な情報を受け付ける。本実施の形態では、各仮想店舗が共通して利用する一つの決済要求受付部１１２を設けているが、別の例においては、決済要求受付部１１２も仮想店舗ごとに複数設けられてもよい。

図８は、符号情報格納部１３４の構成例であり、符号情報欄５００、使用状況欄５０２、店舗識別情報欄５０８、及びユーザ識別情報欄５１０が設けられている。一例として、符号情報「０００１」は、店舗「Ａ」のユーザ「ａ」が「使用中」であり、符号情報「０００２」は、店舗「Ｂ」のユーザ「ｃ」が「使用中」であることが記録されている。

符号情報付与部１３２は、各仮想店舗において生成された照会情報に、非使用中の符号情報を順次付与する。これにより、購入受付サーバ１００が予め確保して符号情報格納部１３４に格納した符号情報を、各仮想店舗に動的に割り当てて与信照会を行うことができる。符号情報管理部１３６は、符号情報付与部１３２が照会情報に符号情報を付与したときに、その符号情報の使用状況欄５０２を「使用中」に設定するとともに、店舗識別情報欄５０８に照会情報の送信元の店舗の識別情報を、ユーザ識別情報欄５１０に照会を要求したユーザの識別情報を格納する。応答情報受信部１６０は、店舗識別情報欄５０８及びユーザ識別情報欄５１０を参照して、応答情報を提示すべき相手を判断する。符号情報格納部１３４に、ユーザとのＨＴＴＰ（Hyper Text Transfer Protocol）セッションのセッションＩＤを格納してもよい。

図９は、本実施の形態の決済支援システム１０の機能を現実の店舗にたとえて表現した図である。購入受付サーバ１００は、電子商取引を実現する複数の仮想店舗１８０を提供する。各仮想店舗は、仮想決済受付窓口１８２を介して与信照会を依頼する。符号情報付与部１３２は、依頼された与信照会を、依頼元の仮想店舗に関係なく、空いている仮想ＣＡＴ端末１８４に順次処理させる。

本実施の形態の決済支援システム１０では、各仮想店舗が送信する照会情報に付与される符号情報は決まっておらず、随時、非使用中の符号情報が付与される。そのため、クレジットカード会社からは照会情報を実際に送信した販売主体を識別することができないので、購入受付サーバ１００の運営主体が、自身のサーバを利用して仮想店舗を出店している販売主体を統括して管理し、クレジットカード会社に対する取引の窓口となってもよい。すなわち、購入受付サーバ１００の運営主体がクレジットカード会社からの入金を一括して受け入れ、各販売主体に分配するような仕組みであってもよい。

上記の通り、本実施の形態の決済支援システム１０によれば、同一のサーバ上に複数の仮想店舗が出店している、いわゆるショッピングモール型の電子商取引においても、同時に複数の与信照会を並列に処理することができる。

（第４の実施の形態）
つづいて、第４の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０においても、一つの購入受付サーバ１００内に複数の仮想店舗が設けられているが、第３の実施の形態とは異なり、各仮想店舗が利用可能な符号情報が予め定められている。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様であり、決済支援サーバ２００及び決済処理サーバ３００の内部構成は、図７に示した第３の実施の形態の構成と同様である。購入受付サーバ１００の内部構成のうち、図７に示した第３の実施の形態の購入受付サーバ１００と異なる点について説明する。

図１０は、符号情報格納部１３４の構成例であり、符号情報欄５００、使用状況欄５０２、店舗識別情報欄５０８、及びユーザ識別情報欄５１０が設けられている。本実施の形態では、店舗識別情報欄５０８の内容は符号情報が照会情報に付与されるたびに格納されるのではなく、予め格納されている。すなわち、それぞれの符号情報は、利用できる店舗が予め決まっており、その店舗以外の店舗は利用できない。一例として、符号情報「０００１」から「０００８」までは、店舗「Ａ」に割り当てられた符号情報であり、そのうち、符号情報「０００１」はユーザ「ａ」により「使用中」であり、符号情報「０００２」はユーザ「ｂ」により「使用中」であり、符号情報「０００８」は「非使用中」であることが記録されている。符号情報付与部１３２は、各仮想店舗において生成された照会情報に、その仮想店舗が利用可能な符号情報のうち、非使用中のものを順次付与する。

図１１は、本実施の形態の決済支援システム１０の機能を現実の店舗にたとえて表現した図である。購入受付サーバ１００は、電子商取引を実現する複数の仮想店舗１８０を提供する。各仮想店舗は、仮想決済受付窓口１８２を介して与信照会を依頼する。符号情報付与部１３２は、依頼された与信照会を、その仮想店舗が利用可能な仮想ＣＡＴ端末１８４のうち、空いている仮想ＣＡＴ端末１８４に順次処理させる。

本実施の形態の決済支援システム１０では、販売主体ごとに符号情報が予め決められているので、これをクレジットカード会社に登録しておくこともできる。すなわち、販売主体が直接クレジットカード会社と契約して取引することができる。所定の期間における与信照会の頻度を仮想店舗ごとに集計し、頻度に応じて符号情報の数を割り当て、符号情報格納部１３４を更新してもよい。このとき、必要であれば、クレジットカード会社に登録した符号情報も変更しておく。

（第５の実施の形態）
つづいて、第５の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０では、購入受付サーバ１００ではなく、決済支援サーバ２００が照会情報に符号情報を付与する。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。

図１２は、本実施の形態の決済支援システム１０における一連の処理の流れを概略的に示す。ユーザが購入受付サーバ１００に商品の購入を要求し（Ｓ１３０）、その商品の購入に伴う決済の方法として、クレジットカードなど、与信照会が必要な決済を要求した場合（Ｓ１３２）、購入受付サーバ１００は、ユーザからクレジットカードの番号や有効期限など、与信の照会に必要な情報を受け付けて照会情報を生成する（Ｓ１３４）。つづいて、購入受付サーバ１００は、商品の提供主体又は購入受付サーバ１００の識別情報とともに、照会情報を決済支援サーバ２００に送信する（Ｓ１３６）。決済支援サーバ２００は、照会情報に付与すべき符号情報を複数格納したテーブルから、使用中でない符号情報を読み出して照会情報に付与する（Ｓ１３８）。このとき、付与した符号情報の使用状況を「使用中」に設定しておき、以降、その符号情報を利用できないようにロックする。決済支援サーバ２００は、符号情報を付与した照会情報を決済処理サーバ３００に送信する（Ｓ１４０）。

決済処理サーバ３００は、決済支援サーバ２００から受け付けた照会情報に基づいて、ユーザに対する与信の可否を判断し（Ｓ１４２）、その判断結果を含む応答情報を生成し（Ｓ１４４）、決済支援サーバ２００に送信する（Ｓ１４６）。決済支援サーバ２００は、決済処理サーバ３００から応答情報を受信すると、その応答情報に対応する照会情報に付与されていた符号情報の使用状況を「非使用中」に設定し、以降、その符号情報を利用できるよう解放する（Ｓ１４８）。決済支援サーバ２００は、応答情報を購入受付サーバ１００に送信する（Ｓ１５０）。購入受付サーバ１００は、決済を要求したユーザに応答情報を提示する（Ｓ１５２）。

図１３は、本実施の形態に係る購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成を示す。本実施の形態の決済処理サーバ３００の内部構成は、図３に示した第１の実施の形態の構成と同様である。本実施の形態の購入受付サーバ１００では、図３に示した第１の実施の形態の購入受付サーバ１００から、符号情報付与部１３２、符号情報格納部１３４、及び符号情報管理部１３６が除かれている。また、本実施の形態の決済支援サーバ２００には、図３に示した第１の実施の形態の決済支援サーバ２００の構成に加えて、符号情報付与部２３２、符号情報格納部２３４、及び符号情報管理部２３６が設けられている。以下、第１の実施の形態と異なる点について説明する。

照会情報送信部１５０は、照会情報の送信元である販売主体又は購入受付サーバ１００の識別情報とともに、照会情報を決済支援サーバ２００に送信する。符号情報付与部２３２、符号情報格納部２３４、及び符号情報管理部２３６の構成及び動作は、それぞれ、第３の実施の形態の符号情報付与部１３２、符号情報格納部２３４、及び符号情報管理部２３６と同様である。符号情報格納部２３４は、図８に示した第３の実施の形態の符号情報格納部１３４と同様に、複数の符号情報を格納する。符号情報付与部２３２は、複数の販売主体又は購入受付サーバ１００から与信照会要求を受け付け、照会情報の送信元に関係なく、符号情報格納部２３４に格納された複数の符号情報のうち、使用中でないものを読み出して付与する。符号情報管理部２３６は、符号情報付与部２３２が符号情報を照会情報に付与したときに、その符号情報の使用状況を「使用中」に設定し、応答情報受信部２６０が応答情報を受信したとき、又は、応答情報受信部２６０が応答情報を受信しないまま所定のタイムアウト時間が経過したときに、その符号情報を「非使用中」に設定する。なお、応答情報受信部２６０のタイムアウト時間は、決済支援サーバ２００と購入受付サーバ１００との間の通信に要する時間を考慮して、応答情報受信部１６０のタイムアウト時間よりも短く設定されるのが好ましい。

図１４は、本実施の形態の決済支援システム１０の機能を現実の店舗にたとえて表現した図である。購入受付サーバ１００ａ及び１００ｂは、それぞれ、電子商取引を実現する仮想店舗１８０ａ及び１８０ｂを提供する。各仮想店舗は、決済支援サーバ２００の仮想決済受付窓口２８２を介して与信照会を依頼する。符号情報付与部２３２は、依頼された与信照会を、依頼元の仮想店舗に関係なく、空いている仮想ＣＡＴ端末２８４に順次処理させる。購入受付サーバ１００が複数の仮想店舗を含む場合も同様である。

上記の通り、本実施の形態の決済支援システム１０によっても、複数の購入受付サーバ１００から送信された与信照会要求を、同時に並列処理することができる。本決済支援システム１０では、決済代行業者の決済支援サーバ２００が一括して符号情報を管理するので、比較的大量の符号情報を扱うことができ、全ての符号情報が使用中となってユーザが与信照会の順番を待たなければならない機会を大幅に軽減することができる。

（第６の実施の形態）
つづいて、第６の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０でも、決済支援サーバ２００が照会情報に符号情報を付与するが、第５の実施の形態とは異なり、各仮想店舗が利用可能な符号情報が定められている。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。

図１５は、本実施の形態の購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成を示す。本実施の形態の購入受付サーバ１００及び決済処理サーバ３００の内部構成は、図１３に示した第５の実施の形態の構成と同様である。本実施の形態の決済支援サーバ２００は、図１３に示した第５の実施の形態の決済支援サーバ２００の構成に加えて、符号情報変更部２３８が設けられている。

本実施の形態の符号情報付与部２３２、符号情報格納部２３４、及び符号情報管理部２３６の構成及び動作は、それぞれ、第４の実施の形態の符号情報付与部１３２、符号情報格納部１３４、及び符号情報管理部２３６と同様である。すなわち、符号情報格納部２３４に格納された符号情報は、利用可能な主体が予め定められており、符号情報付与部２３２は、照会情報とともに取得した識別情報を参照して照会情報の送信元を識別し、その送信元が利用可能な符号情報のうち、使用中でないものを付与する。

図１６は、本実施の形態の決済支援システム１０の機能を現実の店舗にたとえて表現した図である。購入受付サーバ１００ａ及び１００ｂは、それぞれ、電子商取引を実現する仮想店舗１８０ａ及び１８０ｂを提供する。各仮想店舗は、決済支援サーバ２００の仮想決済受付窓口２８２を介して与信照会を依頼する。符号情報付与部２３２は、依頼された与信照会を、その仮想店舗が利用可能な仮想ＣＡＴ端末２８４のうち、空いている仮想ＣＡＴ端末２８４に順次処理させる。購入受付サーバ１００が複数の仮想店舗を含む場合も同様である。

符号情報変更部２３８は、符号情報の利用状況、すなわち、与信照会の頻度に応じて、それぞれの主体に割り当てる符号情報を変更し、符号情報格納部２３４を更新する。図１７は、符号情報変更部２３８により、符号情報の割り当て状況が変更された様子を示す。仮想店舗Ａに割り当てられた符号情報は、図１６では「０００１」から「０００８」までであったが、図１７では「０００１」から「００１０」までに増加している。また、仮想店舗Ｂに割り当てられた符号情報は、図１６では「０００９」から「００１８」までであったが、図１７では「００１１」から「００１５」までに減少している。各店舗が利用する符号情報を予めクレジットカード会社に登録している場合は、符号情報を変更したことをクレジットカード会社にも通知しておく。

上記の通り、本実施の形態の決済支援システム１０によれば、複数の購入受付サーバ１００を介して、複数の販売主体から与信照会の依頼を受け付け、依頼元の販売主体を明確に識別しつつ、同時に複数の与信照会を並列に処理することができる。

（第７の実施の形態）
つづいて、第７の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０では、複数の購入受付サーバ１００を統括的に管理する管理サーバ４００が新たに設けられている。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０に加えて、管理サーバ４００がインターネット３０に接続されている。

図１８は、本実施の形態の購入受付サーバ１００、決済支援サーバ２００、決済処理サーバ３００、及び管理サーバ４００の内部構成を示す。本実施の形態の購入受付サーバ１００及び決済処理サーバ３００の内部構成は、図１３に示した第５の実施の形態の構成と同様である。本実施の形態の決済支援サーバ２００は、図３に示した第１の実施の形態の決済支援サーバ２００と同様である。本実施の形態の管理サーバ４００の内部構成は、図１３に示した第５の実施の形態の決済支援サーバ２００の内部構成と同様である。

本実施の形態の決済支援システム１０は、大型店舗において複数の購入受付サーバ１００を設けている場合や、複数の購入受付サーバ１００にわたるショッピングモール型の電子商取引サイトなどに利用される。本決済支援システム１０では、それぞれの購入受付サーバ１００から送信される照会情報に、管理サーバ４００が符号情報を付与して決済支援サーバ２００に送信する。管理サーバ４００の符号情報付与部４３２及び符号情報格納部４３４の構成及び動作は、第５の実施の形態と同様に、照会情報の送信元に関係なく符号情報を付与するようになっていてもよいし、第６の実施の形態と同様に、照会情報の送信元ごとに利用可能な符号情報が定められていてもよい。

（第８の実施の形態）
つづいて、第８の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０は、ユーザから決済要求を受け付けたときに、ただちに与信照会を行ってその結果をユーザに提示するのではなく、照会情報を蓄積しておき、所定のタイミングでバッチ処理を行う。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。

図１９は、本実施の形態の決済支援システム１０における一連の処理の流れを概略的に示す。ユーザが購入受付サーバ１００に商品の購入を要求し（Ｓ１６０）、その商品の購入に伴う決済の方法として、クレジットカードなど、与信照会が必要な決済を要求した場合（Ｓ１６２）、購入受付サーバ１００は、ユーザからクレジットカードの番号や有効期限など、与信の照会に必要な情報を受け付けて照会情報を生成する（Ｓ１６４）。生成された照会情報は、いったん保持され（Ｓ１６６）、バッチ処理開始の時期が到来するまで蓄積される。バッチ処理開始のタイミングが到来すると（Ｓ１６８のＹ）、与信照会の量と、バッチ処理を終了すべき日時とを考慮して、必要な数だけ符号情報を割り当てる（Ｓ１７０）。つづいて、購入受付サーバ１００は、蓄積された照会情報を順次読み出し（Ｓ１７２）、Ｓ１７０で割り当てられた複数の符号情報のうち、使用中でない符号情報を読み出して照会情報に付与する（Ｓ１７４）。このとき、付与した符号情報の使用状況を「使用中」に設定しておき、以降、その符号情報を利用できないようにロックする。購入受付サーバ１００は、符号情報を付与した照会情報を決済支援サーバ２００に送信する（Ｓ１７６）。決済支援サーバ２００は、購入受付サーバ１００から受け付けた照会情報を決済処理サーバ３００へ送信する（Ｓ１７８）。

決済処理サーバ３００は、決済支援サーバ２００から受け付けた照会情報に基づいて、ユーザに対する与信の可否を判断し（Ｓ１８０）、その判断結果を含む応答情報を生成し（Ｓ１８２）、決済支援サーバ２００に送信する（Ｓ１８４）。決済支援サーバ２００は、決済処理サーバ３００から受け付けた応答情報を購入受付サーバ１００へ送信する（Ｓ１８６）。このとき、符号情報を参照して、どの購入受付サーバ１００へ送信すべきかを判断する。購入受付サーバ１００は、決済支援サーバ２００から応答情報を受信すると、その応答情報に対応する照会情報に付与されていた符号情報の使用状況を「非使用中」に設定し、以降、その符号情報を利用できるよう解放する（Ｓ１８８）。バッチ処理が終了していないときは（Ｓ１９０のＮ）、Ｓ１７２に戻りバッチ処理を続行する。バッチ処理が終了すると（Ｓ１９０のＹ）、購入受付サーバ１００は、決済を要求したユーザに応答情報を提示する（Ｓ１９２）。ユーザに対する応答情報の提示は、応答情報を受信するたびに随時行ってもよいし、バッチ処理が終了してからまとめて行ってもよい。

図２０は、本実施の形態の購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成を示す。本実施の形態の決済支援サーバ２００及び決済処理サーバ３００の内部構成は、図３に示した第１の実施の形態の構成と同様である。本実施の形態の購入受付サーバ１００は、図３に示した第１の実施の形態の購入受付サーバ１００の構成に加えて、照会情報保持部１４０、バッチ処理部１４２が設けられている。

照会情報保持部１４０は、照会情報生成部１３０にて生成された照会情報を、所定の時期が到来するまで蓄積する。バッチ処理部１４２は、所定の時期が到来したときに、与信照会のためのバッチ処理を開始する。バッチ処理の開始に先立って、与信照会の量と、バッチ処理を終了すべき日時とを考慮して、必要な数だけ符号情報を割り当ててもよい。バッチ処理部１４２は、照会情報保持部１４０から順次照会情報を読み出し、符号情報付与部１３２に送る。符号情報付与部１３２は、符号情報格納部１３４に格納された、バッチ処理用に割り当てられた符号情報のうち、使用中でないものを読み出して照会情報に付与する。符号情報付与部１３２は、利用可能な全ての符号情報が使用中になると、いずれかの符号情報が非使用中になるまで待機し、非使用中になった符号情報から順次、再び照会情報に付与する。その他の構成及び動作は、第１の実施の形態と同様である。

本実施の形態の決済支援システム１０は、逐次与信照会を実行するのではなく、所定の量、または所定の期間ごとに、まとめて与信照会を実行したい場合に利用できる。商品又は役務の種類や、ユーザの属性情報などに応じて、リアルタイムに与信照会を実行する場合と、まとめて与信照会を実行する場合を使い分けてもよい。

上記の通り、本実施の形態の決済支援システム１０によれば、所定のタイミングで与信照会をまとめて実行することができる。また、必要な数の符号情報を割り当て、使い終わった符合情報を順次使い回すので、迅速かつ効率良く与信照会を実行することができる。

（第９の実施の形態）
つづいて、第９の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０においても、与信照会をまとめてバッチ処理するが、第８の実施の形態とは異なり、購入受付サーバ１００ではなく決済支援サーバ２００によりバッチ処理が実行される。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。

図２１は、本実施の形態の決済支援システム１０における一連の処理の流れを概略的に示す。決済支援サーバ２００は、商品を提供する店舗から、バッチ処理の依頼を受け（Ｓ２００）、照会情報をまとめて取得する（Ｓ２０２）。決済支援サーバ２００は、取得した照会情報をいったん格納し（Ｓ２０４）、与信照会の量と、バッチ処理を終了すべき日時とを考慮して、必要な数だけ符号情報を割り当てる（Ｓ２０６）。つづいて、決済支援サーバ２００は、保持された照会情報を順次読み出し（Ｓ２０８）、Ｓ２０６で割り当てられた複数の符号情報のうち、使用中でない符号情報を読み出して照会情報に付与する（Ｓ２１０）。このとき、付与した符号情報の使用状況を「使用中」に設定しておき、以降、その符号情報を利用できないようにロックする。決済支援サーバ２００は、符号情報を付与した照会情報を決済処理サーバ３００に送信する（Ｓ２１２）。

決済処理サーバ３００は、決済支援サーバ２００から受け付けた照会情報に基づいて、ユーザに対する与信の可否を判断し（Ｓ２１４）、その判断結果を含む応答情報を生成し（Ｓ２１６）、決済支援サーバ２００に送信する（Ｓ２１８）。決済支援サーバ２００は、決済処理サーバ３００から応答情報を受信すると、その応答情報に対応する照会情報に付与されていた符号情報の使用状況を「非使用中」に設定し、以降、その符号情報を利用できるよう解放する（Ｓ２２０）。バッチ処理が終了していないときは（Ｓ２２２のＮ）、Ｓ２０８に戻りバッチ処理を続行する。バッチ処理が終了すると（Ｓ２２２のＹ）、決済支援サーバ２００は、応答情報を所定の出力形式に変換し（Ｓ２２４）、決済を要求した店舗に応答情報を提示する（Ｓ２２６）。店舗に対する応答情報の提示は、応答情報を受信するたびに随時行ってもよいし、バッチ処理が終了してからまとめて行ってもよい。

図２２は、本実施の形態の決済支援サーバ２００及び決済処理サーバ３００の内部構成を示す。本実施の形態の決済処理サーバ３００の内部構成は、図３に示した第１の実施の形態の構成と同様である。本実施の形態の決済支援サーバ２００は、図１３に示した第５の実施の形態の決済支援サーバ２００の構成に加えて、照会情報保持部２４０、バッチ処理部２４２が設けられており、照会情報受信部２１０に代えて照会情報受付部２２０が、応答情報送信部２７０に代えて応答情報変換部２８０が設けられている。

照会情報受付部２２０は、店舗から照会情報をまとめて受け付ける。照会情報は、オンラインにて受け付けてもよいし、オフラインにて受け付けてもよい。既に入力され所定のフォーマットに変換されたデータを受け付けてもよいし、店舗から電話、ファックス、その他任意の手段で入手した情報を図示しない入力インターフェイスを介して入力してもよい。照会情報保持部２４０は、照会情報受付部２２０にて受け付けた照会情報を、一時保持する。バッチ処理部２４２は、与信照会のためのバッチ処理を実行する。バッチ処理の開始に先立って、与信照会の量と、バッチ処理を終了すべき日時とを考慮して、必要な数だけ符号情報を割り当ててもよい。バッチ処理部２４２は、照会情報保持部２４０から順次照会情報を読み出し、符号情報付与部２３２に送る。符号情報付与部２３２は、符号情報格納部２３４に格納された、バッチ処理用に割り当てられた符号情報のうち、使用中でないものを読み出して照会情報に付与する。符号情報付与部２３２は、利用可能な全ての符号情報が使用中になると、いずれかの符号情報が非使用中になるまで待機し、非使用中になった符号情報から順次、再び照会情報に付与する。応答情報変換部２８０は、応答情報受信部２６０が受信した応答情報を、所定の出力形式に変換する。変換された応答情報は、オンライン又はオフラインにて店舗へ提供される。その他の構成及び動作は、第５の実施の形態と同様である。

上記の通り、本実施の形態の決済支援システム１０によれば、第８の実施の形態と同様に、所定のタイミングで与信照会をまとめて実行することができる。また、必要な数の符号情報を割り当て、使い終わった符合情報を順次使い回すので、迅速かつ効率良く与信照会を実行することができる。また、商品の提供主体は、決済に必要なシステム等を自身の店舗に導入することなく、決済業務をアウトソーシングすることができるので、費用の面からも有用性が高い。

（第１０の実施の形態）
つづいて、第１０の実施の形態に係る決済支援システムについて説明する。本実施の形態の決済支援システム１０は、ユーザに対する与信の可否の照会及び与信枠の確保の要求（以下、「オーソリ要求」ともいう。）を行ったときに、通信障害などに起因して発生する処理結果の認識の不整合を的確に検知するために、購入受付サーバ１００から決済支援サーバ２００へ、応答情報の受信状況を通知する。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。

図２３は、本実施の形態の決済支援システム１０における一連の処理の流れを概略的に示す。ユーザが購入受付サーバ１００に商品の購入を要求し（Ｓ３００）、その商品の購入に伴う決済の方法として、クレジットカードなど、与信照会が必要な決済を要求した場合（Ｓ３０２）、購入受付サーバ１００は、ユーザからクレジットカードの番号や有効期限など、与信の照会に必要な情報を受け付けてオーソリ要求情報を生成し（Ｓ３０４）、決済支援サーバ２００に送信する（Ｓ３０６）。決済支援サーバ２００は、購入受付サーバ１００から受け付けたオーソリ要求情報を決済処理サーバ３００へ送信する（Ｓ３０８）。

決済処理サーバ３００は、決済支援サーバ２００から受け付けたオーソリ要求情報に基づいて、ユーザに対する与信の可否を判断し（Ｓ３１０）、与信が可能であれば（Ｓ３１０のＹ）、与信枠を確保する（Ｓ３１２）。与信が不可能であれば（Ｓ３１０のＮ）、Ｓ３１２をスキップする。決済処理サーバ３００は、オーソリ要求に対する応答情報を生成し（Ｓ３１４）、決済支援サーバ２００に送信する（Ｓ３１６）。決済支援サーバ２００は、決済処理サーバ３００から受け付けた応答情報を購入受付サーバ１００へ送信する（Ｓ３１８）。このとき、決済支援サーバ２００は、この決済の受信確認フラグを「保留」に設定しておく。購入受付サーバ１００は、決済支援サーバ２００から応答情報を受信すると、決済を要求したユーザに応答情報を提示し（Ｓ３２０）、決済支援サーバ２００に応答情報を受信した旨を通知する（Ｓ３２２）。決済支援サーバ２００がこの受信確認を受け取れた場合は、その決済の受信確認フラグを「受信済み」に設定する。決済支援サーバ２００から購入受付サーバ１００への応答情報の送信（Ｓ３１８）又は購入受付サーバ１００から決済支援サーバ２００への受信状況の通知（Ｓ３２０）の際に通信障害が発生した場合は、両者の間で処理結果の認識に不整合が生じる恐れがある。本実施の形態では、購入受付サーバ１００が、応答情報を受信したときには受信確認を決済支援サーバ２００に送信し、応答情報を受信しなかったときには何も送信しない。すなわち、受信確認フラグが「保留」のままである決済については、整合性が確認されていないことが分かる。これにより、決済支援サーバ２００側で、不整合の生じた可能性のある決済を的確に検知することができる。

図２４は、決済支援サーバ２００から購入受付サーバ１００への応答情報送信の際に通信障害が発生したときの処理の手順を示す。購入受付サーバ１００は、決済支援サーバ２００から応答情報を受信できなかったとき、第１の時間が経過するまで待機する（Ｓ３５０のＮ）。第１の時間は、購入受付サーバ１００がオーソリ要求を送信してから応答情報を受信するまでに通常要する時間よりも少し長めに設定されてもよく、たとえば、数十秒程度であってもよい。第１の時間が経過すると（Ｓ３５０のＹ）、購入受付サーバ１００は、決済支援サーバ２００に応答情報の送信を要求する（Ｓ３５２）。これにより、通信障害などの理由で応答情報が受信できなかった場合であっても、応答情報を受信することができる。決済支援サーバ２００が応答情報送信要求を受け取って、応答情報を購入受付サーバ１００へ送信したときに、通信障害などの理由で購入受付サーバ１００が応答情報を受信できなかった場合、購入受付サーバ１００は第２の時間が経過するまで待機する（Ｓ３５６のＮ）。第２の時間は、ユーザ端末２０のウェブブラウザがタイムアウト処理を行うまでの時間よりも短く設定されるのが好ましく、たとえば、２００秒から２７０秒程度であってもよい。第２の時間が経過すると（Ｓ３５６のＹ）、購入受付サーバ１００は、応答情報が受信できなかった旨をユーザ端末２０に伝達する（Ｓ３５８）。上記の処理の過程で、購入受付サーバ１００が応答情報を受信できたときは、購入受付サーバ１００は決済支援サーバ２００に受信確認を送信する。

図２５は、購入受付サーバ１００から決済支援サーバ２００への受信状況通知の際に通信障害が発生したときの処理の手順を示す。購入受付サーバ１００は、決済支援サーバ２００から応答情報を受信すると（Ｓ３１８）、ユーザ端末２０に応答情報を提示し（Ｓ３２０）、決済支援サーバ２００に受信確認を送信するが（Ｓ３２２）、この受信確認が通信障害などの原因で決済支援サーバ２００に到着しなかったとする。このとき、決済支援サーバ２００は、第３の時間が経過するまで待機する（Ｓ３２４のＮ）。第３の時間は、ユーザ端末２０のウェブブラウザのタイムアウト時間よりも少し長めに設定されてもよく、たとえば、３００秒程度であってもよい。購入受付サーバ１００は、ユーザ端末２０のウェブブラウザがタイムアウト処理を行う前に、ユーザ端末２０に何らかの応答情報を送信しているはずであるから、それよりも少し長い時間待機しても受信状況が通知されなかった場合は、購入受付サーバ１００が受信状況を通知していないか、通知していても通信障害により決済支援サーバ２００に到着しなかった可能性が高いので、ブラウザのタイムアウト時間よりも少し長い時間待機すれば十分である。または、決済支援サーバ２００が処理結果の認識の整合性を購入受付サーバ１００との間で確認する時間間隔を第３の時間としてもよく、たとえば、１日に１回整合性を確認したい場合には、第３の時間は１日であってもよい。

第３の時間が経過すると（Ｓ３２４のＹ）、決済支援サーバ２００は、決済処理サーバ３００から与信枠の確保に成功した旨の応答情報を受信していた決済について、所定の判断基準に基づいて、確保された与信枠を解放するか否かを判断する（Ｓ３２６）。与信枠を解放すると判断したときには（Ｓ３２６のＹ）、決済支援サーバ２００が保持しているその決済の情報を削除するとともに、与信枠の解放を決済処理サーバ３００に要求する（Ｓ３４２）。与信枠を解放しないと判断したときには（Ｓ３２６のＮ）、受信状況を取得できなかった決済情報を出力する（Ｓ３２８）。決済支援サーバ２００は、出力された決済情報について、購入受付サーバ１００との間で整合性がとれているか否かを確認する（Ｓ３３０）。決済支援サーバ２００は、購入受付サーバ１００からの回答を受けて（Ｓ３３２）、不整合が生じているか否かを判断する（Ｓ３３４）。

購入受付サーバ１００が応答情報を受信して受信確認を送信したにも関わらず、何らかの原因で決済支援サーバ２００に到着しなかったことが確認された場合は、両者に処理結果の認識に不整合がないので（Ｓ３３４のＮ）、処理を終了する。購入受付サーバ１００が応答情報を受信できず、受信状況を通知しなかったことが確認された場合は、両者に不整合が生じている可能性がある（Ｓ３３４のＹ）。与信枠の確保に失敗していた場合は、その旨を通知するだけでよいが、与信枠の確保に成功していた場合は、その与信枠を解放すべきか否かを購入受付サーバ１００に問い合わせる（Ｓ３３６）。決済支援サーバ２００は、購入受付サーバ１００からの回答を受けて（Ｓ３３８）、与信枠を解放する場合は（Ｓ３４０のＹ）、決済支援サーバ２００が保持しているその決済の情報を削除するとともに、与信枠の解放を決済処理サーバ３００に要求し（Ｓ３４２）、与信枠を解放しない場合は（Ｓ３４０のＮ）、その決済が成功していたものとして処理する。決済処理サーバ３００は、決済支援サーバ２００から与信枠の解放を要求された場合は、与信枠を解放する（Ｓ３４４）。

図２６は、本実施の形態の購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成を示す。図３に示した第１の実施の形態の購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の構成と同様の構成には、同一の符号を付している。以下、主に、第１の実施の形態の構成及び動作と異なる点に重点をおいて説明する。

購入要求受付部１１０は、ユーザ端末２０から商品の購入要求を受け付ける。決済要求受付部１１２は、商品の購入に伴う決済要求を受け付ける。このとき、クレジットカードの番号、有効期限など、必要な情報を取得する。要求情報生成部１３１は、決済を要求したユーザの与信枠を確保するためのオーソリ要求情報を生成する。要求情報送信部１５１は、要求情報生成部により生成されたオーソリ情報を決済支援サーバ２００に送信する。要求情報受信部２１１は、購入受付サーバ１００からオーソリ要求を受信する。要求情報送信部２５１は、要求情報受信部２１１が受信したオーソリ要求を決済処理サーバ３００へ送信する。

要求情報受付部３１１は、決済支援サーバ２００からオーソリ要求を受け付ける。オーソリ処理部３２１は、要求情報受付部３１１にて受け付けたオーソリ要求情報をもとに、ユーザデータベース３３０を参照して、ユーザに対する与信の可否を判断し、与信が可能であれば、与信枠を確保する。応答情報生成部３４０は、オーソリ要求に対する応答情報を生成する。応答情報送信部３５０は、応答情報生成部３４０にて生成された応答情報を決済支援サーバ２００に送信する。応答情報受信部２６０は、決済処理サーバ３００から応答情報を受信する。応答情報送信部２７０は、応答情報受信部２６０が受信した応答情報を購入受付サーバ１００に送信する。応答情報受信部１６０は、決済支援サーバ２００から応答情報を受信する。応答情報受信部１６０は、第１の時間待機しても決済支援サーバ２００から応答情報を受信しなかったときには、決済支援サーバ２００に応答情報の送信を要求してもよい。応答情報提示部１１４は、応答情報をユーザに提示する。

受信状況通知部１７０は、応答情報の受信状況を決済支援サーバ２００に通知する。受信状況通知部１７０は、応答情報受信部１６０が応答情報を受信したときには、その旨を決済支援サーバ２００に通知する。受信状況通知部１７０は、応答情報受信部１６０が第２の時間待機しても応答情報を受信しなかったときには、決済支援サーバ２００に受信状況を通知しない。これにより、決済支援サーバ２００は、購入受付サーバ１００からの受信状況の通知の有無で、購入受付サーバ１００が応答情報を受信したか否かを把握することができる。判断部１７２は、応答情報受信部１６０が第２の時間待機しても応答情報を受信しなかったとき、与信枠が確保されていた場合にその解放を要求するか否かを判断する。

受信状況取得部２７２は、受信状況通知部１７０から受信状況を取得する。出力部２７６は、第３の時間が経過しても受信状況取得部２７２が受信状況を取得しなかった決済の情報を出力する。出力された決済情報は、購入受付サーバ１００に保持された決済情報と比較され、不整合の有無が確認される。判断部２７４は、第３の時間が経過しても受信状況取得部２７２が受信状況を取得しなかったときに、与信枠の確保に成功していた場合には、その与信枠を解放するよう要求するか否かを判断する。判断部２７４は、所定の判断基準を保持してもよい。判断基準は、たとえば、受信状況を取得しなかったときには必ず与信枠を解放する、必ず与信枠を解放しない、などであってもよい。ユーザの属性情報や商品の種類に応じて与信枠の解放を要求するか否かを判断してもよい。解放要求送信部２７８は、判断部２７４が与信枠の解放を要求すると判断したときに、決済処理サーバ３００に与信枠の解放を要求する。このとき、決済支援サーバ２００が保持している決済の履歴情報から、その決済の情報を削除する。決済処理サーバ３００は、与信枠の解放を要求されたときは、確保していた与信枠を解放する。

上記の通り、本実施の形態の決済支援システム１０によれば、通信障害などに起因する処理結果の認識の不整合を的確に検知し、不整合が生じたときに適切に処置することができる。従来は、購入受付サーバ１００側と決済支援サーバ２００側の整合性のチェックを加盟店に任せるケースが多かったが、本システムによれば、決済代行業者側で不整合の発生を検知して加盟店に問い合わせるので、加盟店側の負担を大幅に軽減することができる。また、決済代行業者は、通信障害の発生確率などシステムの保守に必要な情報を的確に把握することができる。

（第１１の実施の形態）
つづいて、第１１の実施の形態に係る決済支援システムについて説明する。第１０の実施の形態の決済支援システム１０では、購入受付サーバ１００が応答情報を受信しなかったときに受信状況を通知しなかったが、本実施の形態の決済支援システム１０では、購入受付サーバ１００が応答情報を受信しなかったときに、未受信確認を決済支援サーバ２００に通知する。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様であり、購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成は、図２６に示した第１０の実施の形態と同様である。

応答情報受信部１６０が応答情報を受信したときは、図２３の手順と同様に、受信状況通知部１７０は、受信確認を決済支援サーバ２００に送信する。決済支援サーバ２００から購入受付サーバ１００への応答情報送信の際に通信障害が発生したときは、図２４の手順につづいて、図２７の手順が実行される。購入受付サーバ１００は、第２の時間が経過しても応答情報受信部１６０が応答情報を受信しなかったとき、未受信確認を決済支援サーバ２００に送信する（Ｓ３６０）。決済支援サーバ２００は、決済処理サーバ３００から与信枠の確保に成功した旨の応答情報を受信していた場合には、所定の判断基準に基づいて、確保された与信枠を解放するか否かを判断する（Ｓ３６２）。与信枠を解放すると判断したときには（Ｓ３６２のＹ）、決済支援サーバ２００が保持しているその決済の情報を削除するとともに、与信枠の解放を決済処理サーバ３００に要求する（Ｓ３７０）。与信枠を解放しないと判断したときには（Ｓ３６２のＮ）、購入受付サーバ１００との不整合を解消すべく、与信枠を解放すべきか否かを購入受付サーバ１００に問い合わせる（Ｓ３６４）。決済支援サーバ２００は、購入受付サーバ１００からの回答を受けて（Ｓ３６６）、与信枠を解放する場合は（Ｓ３６８のＹ）、決済支援サーバ２００が保持しているその決済の情報を削除するとともに、与信枠の解放を決済処理サーバ３００に要求し（Ｓ３７０）、与信枠を解放しない場合は（Ｓ３６８のＮ）、その決済が成功していたものとして処理する。決済処理サーバ３００は、決済支援サーバ２００から与信枠の解放を要求された場合は、与信枠を解放する（Ｓ３７２）。

第３の時間が経過しても受信状況取得部２７２が受信状況を取得しなかったときは、受信状況通知部１７０が受信確認を送信していたのか、未受信確認を送信していたのか、決済支援サーバ２００側では知ることができない。このときの処理の手順は、図２５に示した第１０の実施の形態と同様である。

上記の通り、本実施の形態の決済支援システム１０によっても、通信障害などに起因する処理結果の認識の不整合を的確に検知することができる。本実施の形態では、購入受付サーバ１００が応答情報を受信しなかったときに、未受信確認を送信するので、決済支援サーバ２００は、より的確に受信状況を把握することができる。

（第１２の実施の形態）
つづいて、第１２の実施の形態に係る決済支援システムについて説明する。第１０の実施の形態の決済支援システム１０では、購入受付サーバ１００が応答情報を受信しなかったときに受信状況を通知しなかったが、本実施の形態の決済支援システム１０では、購入受付サーバ１００が応答情報を受信しなかったときに、自動取消要求を決済支援サーバ２００に通知する。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様であり、購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成は、図２６に示した第１０の実施の形態と同様である。

応答情報受信部１６０が応答情報を受信したときは、図２３の手順と同様に、受信状況通知部１７０は、受信確認を決済支援サーバ２００に送信する。決済支援サーバ２００から購入受付サーバ１００への応答情報送信の際に通信障害が発生したときは、図２４の手順につづいて、図２８の手順が実行される。購入受付サーバ１００の判断部１７２は、第２の時間が経過しても応答情報受信部１６０が応答情報を受信しなかった決済について、その決済を自動的に取り消すよう要求するか否かを判断する（Ｓ３８０）。要求しないと判断されたときは（Ｓ３８０のＮ）、処理を終了してもよいし、第１１の実施の形態と同様に、未受信確認を決済支援サーバ２００に送信してもよい。要求すると判断されたときは（Ｓ３８０のＹ）、受信状況通知部１７０は、決済支援サーバ２００に自動取消要求を送信する（Ｓ３８２）。受信状況取得部２７２が自動取消要求を受信すると、解放要求送信部２７８は、決済支援サーバ２００が保持しているその決済の情報を削除するとともに、決済処理サーバ３００に確保された与信枠の解放を要求する（Ｓ３８４）。決済処理サーバ３００は、与信枠の解放要求を受けて、そのユーザの与信枠を解放する（Ｓ３８６）。

第３の時間が経過しても受信状況取得部２７２が受信状況を取得しなかったときは、受信状況通知部１７０が受信確認を送信していたのか、自動取消要求を送信していたのか、何も送信しなかったのか、決済支援サーバ２００側では知ることができない。このときの処理の手順は、図２５に示した第１０の実施の形態と同様である。

上記の通り、本実施の形態の決済支援システム１０によっても、通信障害などに起因する処理結果の認識の不整合を的確に検知することができる。本実施の形態では、購入受付サーバ１００が応答情報を受信しなかったときに、その決済要求を取り消すか否かを判断して、自動取消要求を送信するので、決済支援サーバ２００はより的確に販売主体の意向に沿った処理を行うことができる。

（第１３の実施の形態）
つづいて、第１３の実施の形態に係る決済支援システムについて説明する。第１３の実施の形態の決済支援システム１０では、購入受付サーバ１００が決済支援サーバ２００に、既に要求した決済の金額を変更するよう要求すると、決済支援サーバ２００は、決済処理サーバ３００に元の決済の返品処理を要求し、つづいて、新たな金額の決済を要求する。本実施の形態の決済支援システム１０の全体構成は、図１に示した第１の実施の形態の決済支援システム１０と同様である。

図２９は、本実施の形態に係る決済支援システム１０における処理の流れを概略的に示す図である。購入受付サーバ１００は、ユーザから既に要求した決済の金額を変更するよう要求されると（Ｓ４００）、既に要求した元の決済の伝票番号と、金額変更後の新たな決済の伝票番号と、変更後の金額とを含む金額変更要求情報を決済支援サーバ２００に送信する（Ｓ４０２）。決済支援サーバ２００は、金額変更要求情報を受け付けると、元の決済の伝票番号をもとに、決済の履歴を格納した決済履歴データベースを検索し、元の決済の金額を取得する（Ｓ４０４）。決済支援サーバ２００は、決済処理サーバ３００に、元の決済の金額を通知しつつ返品処理要求を送信する（Ｓ４０６）。決済処理サーバ３００は、返品処理を行い（Ｓ４０８）、その返品処理要求に対する返品処理応答情報を生成して（Ｓ４１０）、決済支援サーバ２００に送信する（Ｓ４１２）。決済支援サーバ２００は、返品処理応答情報を参照して、返品処理に失敗していれば（Ｓ４１４のＮ）、その旨を通知するための金額変更応答情報を生成する（Ｓ４３０）。

返品処理に成功していれば（Ｓ４１４のＹ）、つづいて、決済処理サーバ３００に、金額が変更された新たな決済を要求する（Ｓ４１６）。決済処理サーバ３００は、再売上処理を行い（Ｓ４１８）、その再売上要求に対する再売上応答情報を生成して（Ｓ４２０）、決済支援サーバ２００に送信する（Ｓ４２２）。決済支援サーバ２００は、再売上応答情報を参照して、再売上に失敗していれば（Ｓ４２４のＮ）、決済処理サーバ３００に返品処理の取消を要求し（Ｓ４２６）、決済処理サーバ３００は返品処理を取り消す（Ｓ４２８）。決済支援サーバ２００は、返品処理応答情報及び再売上応答情報に基づいて、金額変更要求に対する金額変更応答情報を生成して（Ｓ４３０）、購入受付サーバ１００に送信する（Ｓ４３２）。購入受付サーバ１００は、決済支援サーバ２００から受信した金額変更応答情報をユーザに提示する（Ｓ４３４）。

図３０は、本実施の形態に係る購入受付サーバ１００、決済支援サーバ２００、及び決済処理サーバ３００の内部構成を示す。金額変更要求受付部１１６は、ユーザから金額変更要求を受け付ける。このとき、既に要求した元の決済の識別情報、たとえば伝票番号を取得してもよい。金額変更要求送信部１１８は、決済支援サーバ２００に金額変更要求情報を送信する。金額変更要求情報は、元の決済及び新たな決済の識別情報と、変更後の金額とを含む。決済の識別情報は、たとえば、伝票番号であってもよい。金額変更応答受信部１６２は、決済支援サーバ２００から、金額変更要求に対する応答情報を受信する。応答情報提示部１１４は、金額変更応答受信部１６２が受信した応答情報をユーザに提示する。

金額変更要求受信部２１２は、購入受付サーバ１００から金額変更要求を受け付ける。決済履歴データベース２２２は、決済支援サーバ２００が取り扱った決済の履歴情報を格納する。金額変更要求受付部２１２は、金額変更要求を受け付けると、元の決済の伝票番号をもとに、決済履歴データベース２２２を検索して、元の決済の金額を取得する。返品処理要求部２１４は、決済処理サーバ３００に元の決済についての返品処理要求を送信する。返品処理応答受信部２１６は、決済処理サーバ３００から、返品処理要求に対する返品処理応答情報を受信する。返品処理が失敗していたときは、応答情報送信部２７０が、返品処理に失敗した旨を示す金額変更応答情報を生成して、購入受付サーバ１００へ送信する。返品処理が成功していたときは、つづいて、再売上要求部２１８が、決済処理サーバ３００に金額が変更された新たな決済を要求する。再売上応答受信部２２１は、決済処理サーバ３００から、再売上要求に対する再売上応答情報を受信する。再売上が失敗していたときは、返品処理要求取消部２２４が、決済処理サーバ３００に返品処理の取消を要求するとともに、応答情報送信部２７０が、再売上に失敗した旨を示す金額変更応答情報を生成して、購入受付サーバ１００に送信する。返品処理だけが成功した状態のままにしておくと、金額の変更を要求されたにも関わらず、元の決済を取り消してしまうことになるので、返品処理だけが成功して再売上に失敗したときは、返品処理を取り消して、金額変更を要求される前の状態に戻しておく。再売上に成功していたときは、応答情報送信部２７０が、金額変更に失敗した旨を示す金額変更応答情報を生成して、購入受付サーバ１００に送信する。

要求情報受付部３１１は、決済支援サーバ２００から、決済の要求を受け付ける。オーソリ処理部３２１は、決済要求の内容に応じて、ユーザの与信枠の確保や解放などの処理を実行する。ユーザデータベース３３０は、ユーザのクレジットカードの番号、有効期限、暗証番号などの情報を格納する。応答情報生成部３４０は、決済要求に対する応答情報を生成する。応答情報送信部３５０は、応答情報生成部３４０が生成した応答情報を、決済支援サーバ２００に送信する。

上記の通り、本実施の形態の決済支援システム１０によれば、既に要求した決済の金額を変更する際に、購入受付サーバ１００は、返品処理と再売上を要求する必要はなく、１回だけ金額変更を要求すればよいので、店舗側の負担を軽減することができる。

図３１は、購入受付サーバ１００、決済支援サーバ２００、決済処理サーバ３００、及び管理サーバ４００のハードウェアコンポーネントを示す。購入受付サーバ１００、決済支援サーバ２００、決済処理サーバ３００、及び管理サーバ４００は、それぞれ、ＣＰＵ６２０、入力装置６２２、表示装置６２４、ＲＡＭ（ランダムアクセスメモリ）６３０、ハードディスク６３２、およびドライブ装置６２８を備える。これらの構成は、バス６２６などの信号伝送路により電気的に接続されている。

ハードディスク６３２は、大容量の磁気記憶装置であり、各種データベースなどを記憶する。記録媒体６４０は、実施の形態に関連して説明した購入受付サーバ１００、決済支援サーバ２００、決済処理サーバ３００、及び管理サーバ４００の機能を、ＣＰＵ１２０に実現させるためのプログラムを記録する。記録媒体６４０がドライブ装置６２８に挿入されると、そのプログラムは、ＲＡＭ６３０またはハードディスク６３２に読み出され、ＣＰＵ６２０は、読み出されたプログラムにより決済支援処理を行う。この記録媒体６４０は、ＣＤ−ＲＯＭ、ＤＶＤ、ＦＤなどのコンピュータ読み取り可能な媒体である。

ここでは、決済支援用のプログラムが記録媒体６４０に記録されている例について説明したが、別の例においては、このプログラムは、無線、有線を問わず、外部のサーバから送信されてもよい。図３１に示したハードウェア構成において、プログラムは、コンピュータに決済支援機能を実現させればよいのであって、外部から供給される場合だけでなく、予めハードディスク６３２に格納されていてよいことも当業者には理解されるところである。

以上、本発明を実施の形態をもとに説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態は例示であり、各構成要素や各処理プロセスの組合せに、さらにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

そのような変形例の一例として、本実施の形態の決済支援システム１０は、購入受付サーバ１００、決済支援サーバ２００、決済処理サーバ３００、及び管理サーバ４００を備えていたが、このような構成は必須ではなく、これらが１つのサーバとして設けられていてもよいし、それぞれのサーバの構成部材の一部または全部が他のサーバに設けられていてもよく、その構成の自由度が非常に高いことは当業者に理解されるところである。

各サーバの運営主体についても、実施の形態では、購入受付サーバ１００を商品の提供主体が、決済支援サーバ２００を決済代行業者が、決済処理サーバ３００をクレジットカード会社が運営する例を中心に説明したが、これら全てを一つの運営主体が運営してもよいし、一つのサーバを複数の運営主体が共同して運営してもよい。

実施の形態では、購入受付サーバ１００は、インターネット３０を介してユーザ端末２０に仮想的な店舗を提供するウェブサーバであったが、もちろん、購入受付サーバ１００は、現実の店舗に設けられて購入及び決済の要求を受け付けてもよいし、通信販売などユーザと対面しない販売形態の店舗に設けられてユーザからの購入及び決済の要求を間接的に受け付けてもよい。また、購入受付サーバ１００として、ＰＯＳ端末、ＣＡＴ端末、ＡＴＭ端末などの端末を利用することもできる。

第１の実施の形態に係る決済支援システムの全体構成を示す図である。 第１の実施の形態に係る決済支援システムにおける処理の流れを概略的に示す図である。 第１の実施の形態に係る購入受付サーバ、決済支援サーバ、及び決済処理サーバの内部構成を示す図である。 第１の実施の形態に係る購入受付サーバの符号情報格納部の内部データを示す図である。 第１の実施の形態に係る決済支援システムの機能を現実の店舗にたとえて表現した図である。 第２の実施の形態に係る購入受付サーバの符号情報格納部の内部データを示す図である。 第３の実施の形態に係る購入受付サーバ、決済支援サーバ、及び決済処理サーバの内部構成を示す図である。 第３の実施の形態に係る購入受付サーバの符号情報格納部の内部データを示す図である。 第３の実施の形態に係る決済支援システムの機能を現実の店舗にたとえて表現した図である。 第４の実施の形態に係る購入受付サーバの符号情報格納部の内部データを示す図である。 第４の実施の形態に係る決済支援システムの機能を現実の店舗にたとえて表現した図である。 第５の実施の形態に係る決済支援システムにおける処理の流れを概略的に示す図である。 第５の実施の形態に係る購入受付サーバ、決済支援サーバ、及び決済処理サーバの内部構成を示す図である。 第５の実施の形態に係る決済支援システムの機能を現実の店舗にたとえて表現した図である。 第６の実施の形態に係る購入受付サーバ、決済支援サーバ、及び決済処理サーバの内部構成を示す図である。 第６の実施の形態に係る決済支援システムの機能を現実の店舗にたとえて表現した図である。 第６の実施の形態に係る決済支援システムにおいて、符号情報変更部により、符号情報の割り当て状況が変更された様子を示す図である。 第７の実施の形態に係る購入受付サーバ、決済支援サーバ、決済処理サーバ、及び管理サーバの内部構成を示す図である。 第８の実施の形態に係る決済支援システムにおける処理の流れを概略的に示す図である。 第８の実施の形態に係る購入受付サーバ、決済支援サーバ、及び決済処理サーバの内部構成を示す図である。 第９の実施の形態に係る決済支援システムにおける処理の流れを概略的に示す図である。 第９の実施の形態に係る決済支援サーバ及び決済処理サーバの内部構成を示す図である。 第１０の実施の形態に係る決済支援システムにおける処理の流れを概略的に示す図である。 第１０の実施の形態に係る決済支援システムにおいて、決済支援サーバから購入受付サーバへの応答情報送信の際に通信障害が発生したときの処理の手順を示す図である。 第１０の実施の形態に係る決済支援システムにおいて、購入受付サーバから決済支援サーバへの受信状況通知の際に通信障害が発生したときの処理の手順を示す図である。 第１０の実施の形態に係る購入受付サーバ、決済支援サーバ、及び決済処理サーバの内部構成を示す図である。 第１１の実施の形態に係る決済支援システムにおいて、決済支援サーバから購入受付サーバへの応答情報送信の際に通信障害が発生したときの処理の手順を示す図である。 第１２の実施の形態に係る決済支援システムにおいて、決済支援サーバから購入受付サーバへの応答情報送信の際に通信障害が発生したときの処理の手順を示す図である。 第１３の実施の形態に係る決済支援システムにおける処理の流れを概略的に示す図である。 第１３の実施の形態に係る購入受付サーバ、決済支援サーバ、及び決済処理サーバの内部構成を示す図である。 実施の形態に係る購入受付サーバ、決済支援サーバ、決済処理サーバ、及び管理サーバのハードウェアコンポーネントを示す図である。

符号の説明

１０・・・決済支援システム、１００・・・購入受付サーバ、１１４・・・応答情報提示部、１１６・・・金額変更要求受付部、１１８・・・金額変更要求送信部、１３０・・・照会情報生成部、１３１・・・要求情報生成部、１３２・・・符号情報付与部、１３４・・・符号情報格納部、１３６・・・符号情報管理部、１４０・・・照会情報保持部、１４２・・・バッチ処理部、１５０・・・照会情報送信部、１５１・・・要求情報送信部、１６０・・・応答情報受信部、１６２・・・金額変更応答受信部、１７０・・・受信状況通知部、１７２・・・判断部、２００・・・決済支援サーバ、２１０・・・照会情報受信部、２１１・・・要求情報受信部、２１２・・・金額変更要求受信部、２１４・・・返品処理要求部、２１６・・・返品処理応答受信部、２１８・・・再売上要求部、２２０・・・照会情報受付部、２２１・・・再売上応答受信部、２２２・・・決済履歴データベース、２２４・・・返品処理要求取消部、２３２・・・符号情報付与部、２３４・・・符号情報格納部、２３６・・・符号情報管理部、２３８・・・符号情報変更部、２４０・・・照会情報保持部、２４２・・・バッチ処理部、２５０・・・照会情報送信部、２５１・・・要求情報送信部、２６０・・・応答情報受信部、２７０・・・応答情報送信部、２７２・・・受信状況取得部、２７４・・・判断部、２７６・・・出力部、２７８・・・解放要求送信部、２８０・・・応答情報変換部、３００・・・決済処理サーバ、３１０・・・照会情報受付部、３１１・・・要求情報受付部、３２０・・・与信可否判断部、３２１・・・オーソリ処理部、３３０・・・ユーザデータベース、３４０・・・応答情報生成部、３５０・・・応答情報送信部、４００・・・管理サーバ、４３２・・・符号情報付与部、４３４・・・符号情報格納部

Claims (7)

1. ユーザから商品又は役務の購入要求を受け付ける購入受付サーバと、
   購入に伴う決済を支援する決済支援サーバと、
   を備え、
   前記購入受付サーバは、
   ユーザから購入に伴う決済要求を受け付けたときに、そのユーザに対する与信の可否を、決済処理を行う決済処理サーバに照会するための照会情報を生成する生成部と、
   前記照会情報に付与するための符号情報を複数格納する格納部と、
   前記格納部に格納された複数の前記符号情報のうち、使用中でない符号情報を読み出して、前記照会情報に付与する付与部と、
   前記照会情報を前記決済支援サーバに送信する第１の照会情報送信部と、
   前記照会に対する応答情報を前記決済支援サーバから受信する応答情報受信部と、
   を含み、
   前記決済支援サーバは、
   前記購入受付サーバから前記照会情報を受け付けて前記決済処理サーバへ送信する第２の照会情報送信部と、
   前記決済処理サーバから前記応答情報を受け付けて前記購入受付サーバへ送信する応答情報送信部と、
   を含むことを特徴とする決済支援システム。
2. 前記購入受付サーバは、前記商品又は役務の複数の提供主体に対する購入要求を受け付け、
   前記格納部は、前記提供主体ごとに、その提供主体が利用可能な複数の符号情報を格納し、
   前記付与部は、提供主体が利用可能な複数の符号情報のうち、使用中でない符号情報を読み出して、前記照会情報に付与することを特徴とする請求項１に記載の決済支援システム。
3. 前記購入受付サーバは、前記符号情報の使用状況を管理する管理部をさらに含み、
   前記管理部は、前記符号情報が前記付与部により前記照会情報に付与されたときに、その符号情報の使用状況を使用中とし、前記応答情報受信部が前記応答情報を受信したときに、その応答情報に対応する照会情報に付与された符号情報の使用状況を非使用中とすることを特徴とする請求項１または２に記載の決済支援システム。
4. 前記管理部は、所定の時間が経過しても前記応答情報受信部が前記応答情報を受信しなかったときに、その応答情報に対応する照会情報に付与された符号情報の使用状況を非使用中とすることを特徴とする請求項３に記載の決済支援システム。
5. 前記格納部は、前記購入受付サーバまたは前記提供主体による照会の頻度に応じて予め割り当てられた前記符号情報を格納することを特徴とする請求項１から４のいずれかに記載の決済支援システム。
6. 前記付与部は、前記ユーザが購入する商品又は役務の種類に基づいて、前記照会情報に付与すべき前記符号情報を決定することを特徴とする請求項１から５のいずれかに記載の決済支援システム。
7. 前記付与部は、前記ユーザの属性情報に基づいて、前記照会情報に付与すべき前記符号情報を決定することを特徴とする請求項１から６のいずれかに記載の決済支援システム。

Images