JP5122715B2 - 決済仲介方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、購入者から商品販売者に注文依頼があった後の与信処理、商品発送確認、購入者への代金請求、販売者に対する支払処理を行う決済仲介システム及び決済方法に関し、具体的には、商品運送に関する荷物追跡情報と、注文情報などを含む取引情報とを連携させて円滑で確実な商取引を提供する決済仲介システム及び決済仲介方法に関する。
【０００２】
【従来の技術】
インターネット上で行う電子商取引（ネットビジネス）では、取引相手の特定及び信用判断が困難であるため、商品の受け渡しや支払に関するトラブルが続発している。そこで、このようなトラブルを解消し、安心して電子商取引を実現するための “仲介ビジネス”が最近続々と提案されている。
【０００３】
その一つに “エスクロー”と呼ばれるサービスがある。そもそも “エスクロー”は、ネットビジネスにおける安全性を保証する仲介サービスのことであり、例えば図６に示すように、エスクローサービス事業者が販売者と購入者の間に入り、購入者から購入代金を預かり（▲１▼）、購入者に商品が配達されたことを確認し（▲２▼）、その後購入代金を販売者に送金する（▲３▼）サービスである。購入者にとっては、販売者から商品が届かなかったり、届いた商品が取引内容と異なったりする場合には取引契約を破棄してエスクローサービス事業者から返金を受けることができる。また、販売者にとっては、購入者がエスクローサービス事業者に入金したことを確認してから運送できるため代金を取り損ねることがないといったメリットがある。
【０００４】
また、決済仲介事業者が販売者と購入者との間に入り、クレジットカード番号の入力によって互いの与信処理を行い、互いの信用を確保するというクレジットカード決済仲介サービスも提案されている。例えば、図７に示すように、購入者から販売者（ＥＣ店舗）に商品の注文がなされ（▲１▼）、購入者から販売者（ＥＣ店舗）へクレジットカード情報が送信されると（▲２▼）、そのクレジットカード情報は決済サービスサーバを介してクレジットカード会社に送られる（▲３▼）。クレジットカード会社は与信処理した後、その与信処理結果を決済サービスサーバを介して販売者（ＥＣ店舗）に通知する（▲４▼）。販売者はこの通知を見て「支払可能」であれば購入者に対して購入完了通知を送信し（▲５▼）、購入者に対して商品の発送を行う（▲６▼）と共に、この取引の売上げ請求データを決済サービスサーバに送信する（▲７▼）。決済サービスサーバでは、この売上げ請求データをクレジットカード会社に送信し（▲８▼）、後日クレジットカード会社が販売者（ＥＣ店舗）の指定する金融機関の口座に入金する。というものである。
【０００５】
さらにまた、商品の運送と集金とを運送業者が仲介し、商品配達時に商品との引き換えにより、その場で代金の集金を行うサービス（例えば「ヤマトコレクトサービス」）も行われている。 電子商取引ではクレジットカード番号の送受信を嫌うユーザーも多いため、現在開設されている電子商取引サイト（Ｗｅｂ上の電子商店（仮想店舗）や電子商店街（サイバーモール））などでは、決済手段としてクレジットカード決済と、「ヤマトコレクトサービス」のような代金引換決済とを購入者が選択できるようにシステム設計しているサイトも多くみられる。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記のような現在行われている、或いは提案されている決済仲介システムにはまだまだ課題が残されている。
例えば、上記の如きエスクローについて言えば、商品が届いたか否かの確認が購入者の意志に委ねられるため、商品の配達・未配達の情報が真実であるかを確かめる手段はない。また、エスクローサービス事業者が購入者からの購入代金の入金を確認し、入金されたことを販売者に通知し、この通知を確認した販売者が商品の発送を行い、商品配達の完了を確認し、その後やっと購入代金が販売者に支払われる工程を経なければならず、処理が煩雑で時間がかかり、折角の電子商取引の長所が失われてしまうといった課題も抱えていた。
【０００７】
これに対して“クレジットカード決済仲介サービス”の場合は、即座に与信処理を行うことができ、円滑な商取引を進めることができる。しかしその反面、次のような課題を抱えていた。
・「画面上での購入操作」から「与信処理」、「商品発送」までの商品注文から代金決済までの取引情報の流れと、商品の梱包から配達までの実際の商品物流の流れとが互いに連携なく別々に進行するため、上記エスクローとは逆に、商品が届いていないのにその代金の請求が購入者に対してなされる可能性があった。
・ クレジットカード決済の場合、クレジットカード会社所定の期日に購入者の口座から支払額が引き落とされ、その後、クレジットカード会社の期日に販売者の口座に入金されるため、販売者にとっては、債権回収までの期間が長くなるばかりか、クレジットカード会社毎に入金日及び精算書が異なるため、売掛金の入金予定データと振込入金データとを照合して消し込む“入金消込処理”に手間がかかるという問題があった。
・ 決済手段として「クレジットカード決済」を選択すると、クレジットカード情報など与信処理に必要な情報の入力を促され、送信ボタンを押すと、そのまま与信処理が開始されてしまい、購入者が運送料金など商品代金以外の諸料金を含めた決済総額を確認しないままに、与信が完了してしまうという不都合があった。その一方、販売者側からすると、自らが開設するＷｅｂ上の電子商店において、注文時に運送料金などの商品代金以外の諸費用を含めた決済総額を算出するシステムを構築することはシステム開発力及び開発費用の面から極めて困難なことであった。
・ 複数のクレジットカード会社と契約するとなると、クレジットカード会社毎に与信処理システムを組み込む必要が生じ、与信処理手続き自体煩雑となる上、費用的にかなりの負担を強いられることになった。
・ 購入者側、すなわち与信処理を取られる側からすると、クレジットカード情報などの個人情報が販売者側に残るため、個人情報の漏洩や悪用される心配があった。
【０００８】
また、上述のようにクレジットカード決済と代金引換決済とを購入者が選択できるようにしている商品取引サイトでは、販売者は、複数のクレジットカード会社からそれぞれ支払明細書を受け取ると同時に、代金回収を行った運送業者からも支払明細書を受け取ることとなるため、経理処理、特に入金消込処理が極めて煩雑となっていた。
【０００９】
【課題を解決するための手段】
かかる課題を解決するため、本発明は、通信ネットワークを通じて、外部システムである購入者システム及び販売者システムと接続し得る決済仲介システムであって、
・ 購入者システムを識別する購入者システム識別情報と、運送料金など商品代金以外の諸料金を含む決済総額情報とを包含する注文情報を販売者システムから受信し、これを注文案件毎の取引情報として蓄積する機能、
・ 販売者システムから前記注文情報を受信したら、当該注文情報中の購入者システム識別情報に基づいてその購入者システムに対し、与信処理開始の依頼と決済仲介システムへのアクセス情報とを送信する機能、
・ 上記購入者システムからアクセス要求があったら、蓄積している取引情報のうち少なくとも決済総額情報を含む注文情報と、クレジットカード情報など与信処理に必要な情報の要求とを購入者システムに送信する機能、
・ 当該購入者システムから与信処理に必要な情報を受信したら、その与信処理に必要な情報を与信処理センターサーバに送信する機能、
・ 当該与信処理センターサーバから与信処理結果を受信したら、自動的或いは要求に応じて、購入者システム又は販売者システム或いは両システムに対して当該与信処理結果を送信する機能、
を備えた決済仲介システムを提案する。
なお、本明細書において、「購入者システム」とは購入者側が管理するコンピュータ端末や携帯端末などのコンピュータシステムを意味し、「販売者システム」とは販売者側が管理するコンピュータ端末や携帯端末等のコンピュータシステムを意味し、「購入者システム識別情報」とはｅメールアドレスや携帯電話番号など購入者システムを識別し得る識別情報を意味するものである。
【００１０】
かかる決済仲介システムによれば、
・ 決済仲介システムが、購入者システム識別情報と運送料金など商品代金以外の諸料金を含む決済総額情報とを包含する注文情報を、販売者システムから受信し、これを注文案件毎の取引情報として蓄積するステップ、
・ 決済仲介システムが、上記ステップにて注文情報を受信したら、当該注文情報中の購入者システム識別情報に基づいてその購入者システムに対し、与信処理開始の依頼と決済仲介システムへのアクセス情報とを送信するステップ、
・ 決済仲介システムが、上記購入者システムからアクセス要求があったら、蓄積している取引情報のうち少なくとも決済総額情報を含む注文情報と、クレジットカード情報など与信処理に必要な情報の要求とを購入者システムに送信するステップ、
・ 決済仲介システムが、当該購入者システムから与信処理に必要な情報を受信したら、その与信処理に必要な情報を与信処理センターサーバに送信するステップ、
・ 決済仲介システムが、当該与信処理センターサーバから与信処理結果を受信したら、自動的或いは要求に応じて、購入者システム又は販売者システム或いは両システムに対して当該与信処理結果を送信するステップ、
を包含してなる決済仲介方法を提供することができる。
【００１１】
上記決済仲介システム及び決済仲介方法において、購入者システムからアクセス要求があったら、蓄積している取引情報のうち少なくとも決済総額情報を含む注文情報と、購買確認の問い合わせ或いは与信処理開始了承の問い合わせとを購入者システムに送信し、購入者システムから購買確認或いは与信処理開始了承の旨を受信したら、クレジットカード情報など与信処理に必要な情報の要求を購入者システムに送信するようにすることができる。
【００１２】
上記の如き決済仲介システム及び決済仲介方法によれば、商品発注のシステム（工程）と与信処理のシステム（工程）とが分離されるから、商品発注の工程終了後に販売者が運送料金など商品代金以外の諸料金を別途計算し、これらを含む決済総額情報を購入者に提示し、購入者自らの意志により購買意志を確認するか或いは与信処理開始を了承した上で与信処理を進めることができる。よって、システム開発力が不足している中小の企業であっても、購入者が安心して商取引を行うことができる与信処理サービスを提供することができる。しかも、販売者にとっては、自らの電子商店サイト内に与信処理のためのシステムを組み込む必要がなく、複数のクレジットカード会社のクレジットカード決済を利用する場合でも与信処理窓口を本決済仲介システムに一本化することができ、システム及び手続の両面を簡素化することができる。
一方、購入者にとっても、クレジットカード情報などの個人情報が販売者側に残ることがないので、安心してクレジットカード決済を利用することができる。
【００１３】
本発明はまた、通信ネットワークを通じて、外部システムである購入者システム及び販売者システムと接続し得ると共に、商品運送に関する荷物追跡情報のうち少なくとも集荷済情報又は配達完了情報を収集し蓄積する荷物追跡情報管理サーバと接続し得る決済仲介システムであって、
・ 各注文案件を識別する取引識別情報を含む注文情報を販売者システムから受信し、これを注文案件毎の取引情報として蓄積する機能、
・ 蓄積している取引情報と、荷物追跡情報管理サーバが蓄積している集荷済情報又は配達完了情報とを照合する機能、
・ 照合の結果新たに集荷済み又は配達完了となった取引情報を抽出し、抽出された取引情報については、その後自動的に、販売者への支払処理、購入者或いは購入者からの商品代金の回収業務を委託した会社に対する請求処理のいずれかの処理、又はそれら両方の処理を進行させる機能、
を備えた決済仲介システムを提案する。
なお、本明細書において「集荷済情報」とは、運送業者が荷送人（本発明の販売者）から荷物を実際に預かった旨の確認情報を意味する。言い換えれば、運送業者の運送責任の始期を示す確認情報であり、例えば運送業者（宅配業者含む。以下同様）が荷送人の所に集荷に行って荷物を実際に預かった旨の確認情報、荷送人がコンビニエンスストアなど運送業者から荷物の引受け委託されている取次店に荷物を預け、運送業者が当該取次店にて荷物を実際に預かった旨の確認情報、並びに、荷送人が荷物を運送業者の事業所に直接持ち込み、運送業者が当該荷物を実際に預かった旨の確認情報を全て包含する意である。また、「配達完了情報」とは、運送業者が荷受人（本発明の購入者）に荷物を引き渡した旨の確認情報を意味する。また、「集荷済情報又は配達完了情報」の表現は、運送業者が荷送人（本発明の販売者）から荷物を預かってから当該荷物を荷受人（本発明の購入者）に配達するまでの各段階の完了をそれぞれ示す確認情報をも包含する意図を有している。
さらにまた、購入者からの商品代金の回収業務を委託した会社とは、クレジットカード会社は勿論、その他の仲介業者も包含する意であり、以下「代金回収委託会社」という。
【００１４】
かかる決済仲介システムによれば、
・ 販売者に対して代金支払処理を行う場合、或いは、購入者或いは代金回収委託会社に対して代金請求処理を行う場合に、決済仲介システムが、各注文案件を識別する取引識別情報を含む注文情報を販売者システムから受信し、これを注文案件毎の取引情報として蓄積するステップ、
・ 決済仲介システムが、蓄積している取引情報と荷物追跡情報管理サーバが蓄積している集荷済情報又は配達完了情報とを照合するステップ、
・ 決済仲介システムが、照合の結果新たに集荷済み又は配達完了となった取引情報を抽出し、抽出された取引情報については、その後自動的に、購入者或いは代金回収委託会社に対して代金請求処理を進行させるステップ、又は、決済仲介システムが、照合の結果新たに集荷済み又は配達完了となった取引情報を抽出し、抽出された取引情報については、その後自動的に、販売者への代金支払処理を進行させるステップ、
を包含する決済仲介方法を提供することができる。
【００１５】
このような構成の決済仲介システム及び決済仲介方法によれば、荷物追跡情報管理サーバから集荷済情報又は配達完了情報を取得した時点で売上を確定し、その後速やかに「販売者に対する代金支払処理」及び「購入者或いは代金回収委託会社に対する代金請求処理」を進行させることができるから、商品が届かないのに代金請求がなされるという問題を解消することができる。また、購入者でも販売者でもない第三者が確認し入力した客観的な集荷済情報又は配達完了情報を基礎として売上確定を決定するから、互いの決済処理を公平かつ正確に行うことができる。しかも、集荷済情報であれば、商品が購入者に配達される前に取得することができ、より早い段階から決済処理を進めることができる。そればかりか、従来のように配達完了などの各運送段階の完了確認を人為的に行う必要もないから、各運送段階の完了確認手続きを簡素化することができる。
また、本決済仲介システム及び本決済仲介方法の場合、代金回収委託会社への代金請求は決済仲介システムが一括して行うため、販売者が複数の代金回収委託会社を利用する場合でも販売者の負担が増えることがない。しかも、本決済仲介システムが立替払いすることによって、本決済仲介システム所定の期日に一括して販売者に入金することができる。これによって、代金回収委託会社毎に入金期日が異なったり、精算書が異なったりするなどの不都合を無くすことができ、販売者側の経理処理、特に入金消込処理の手間を大幅に軽減することができる。
【００１６】
なお、上記の決済仲介システム及び決済仲介方法において、取引情報と集荷済情報又は配達完了情報とを照合する前に、決済仲介システムが、販売者システムから、少なくとも発送予定日と、送り状番号などの運送荷物識別情報とを含む発送予定情報を受信し、蓄積している取引情報に当該発送予定情報を追加更新し、そして、取引情報中の発送予定情報が追加された取引情報と、荷物追跡情報管理サーバが蓄積している集荷済情報又は配達完了情報とを照合するようにすることができる。
このようにすれば、発送予定情報内の運送荷物識別情報と、運送荷物識別情報単位で管理されている集荷済情報又は配達完了情報とを照合することにより、取引情報と集荷済情報又は配達完了情報とを照合することができる。また、取引情報全てではなく、発送予定情報が追加された取引情報のみ照合すればよいから、システムの負担を軽減することができる。
なお、本明細書において「運送荷物識別情報」とは、例えば送り状番号など、各運送案件一件一件を識別し得る情報のことを意味し、「運送」とは、集荷から、運行及び配達までの一連の物流作業を包括的に示す意である。
【００１７】
さらに、販売者と複数の購入者との間の決済処理を決済仲介システムにより仲介し、販売者に対しては決済仲介システムを通じて代金の立替払いを行う一方、購入者に対しては二種類以上の決済方法によって選択的に購入代金を請求し得る決済仲介方法であって、
・決済仲介システムが、一種類の決済方法による取引案件の支払額を販売者毎に連結するステップ、
・決済仲介システムが、その他の一種類の決済方法による取引案件の支払額を販売者毎に連結するステップ、
・決済仲介システムが、上記ステップにて連結した支払額を販売者毎に更に連結し、一種類の決済方法による支払額とその他の一種類の決済方法による支払額とをとりまとめて支払明細書に表示するステップ、
を包含する決済仲介方法を提案する（請求項１）。
例えば、一部の購入者に対しては、決済仲介システムを通じて、クレジット会社から購入代金を請求するクレジットカード決済を行い、その他の一部の購入者に対しては商品との引き換えにより購入代金を集金する代金引換決済を行う決済仲介方法において、決済仲介システムが、クレジットカード決済による取引案件の支払額を販売者毎に連結する一方、代金引換決済による取引案件の支払額を販売者毎に連結し、連結した２つの支払額を販売者毎に更に連結し、クレジットカード決済による支払額と代金引換決済による支払額とをとりまとめて支払明細書に表示するようにすることができる。
【００１８】
このような決済仲介方法によれば、販売者が、複数の購入者との間で、クレジットカード決済や代金引換決済などの異なる決済方法を購入者の自由意志によって任意に選択する場合でも、更に言えば、購入者の自由意志によって複数のクレジットカード会社から特定のクレジットカード会社を選択する場合でも、本発明の決済仲介システムは、全ての決済方法の支払額を販売者毎にとりまとめて一つの支払明細書に表示することができるから、販売者にとっては、決済方法に関係なく入金内容を一元的に管理できるようになり、経理処理、特に入金消込処理の負担を大幅に軽減することができる。
【００１９】
なお、上記決済仲介方法において、販売者毎に支払額を連結するには、例えば、決済方法に関わりなく、販売者を識別する番号（以下「識別親番号」と言う。）を取引案件毎に付与すると共に、当該識別親番号には適宜番号を追加してなる複数の識別子番号を付与し得る設定とすることにより、異なる識別子番号が付与されている取引案件であっても、識別親番号が共通する全ての取引案件の支払額を連結するようにすることができる（請求項２）。
このようにすれば、識別親番号に適宜番号を追加してなる複数の識別子番号を付与し得る設定となっているがゆえに、同一販売者に対して複数の識別子番号を付与することができ、例えば、同一販売者が業態の異なる複数の店舗を所有しているような場合、決済仲介システムは、店舗毎に異なる識別子番号を付与することができ、しかも、識別親番号をキーとして店舗毎の支払額をとりまとめて販売者に支払うことができる。更に、識別親番号及び識別子番号の管理を極めて容易に行うことができるようになる。
【００２０】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００２１】
本実施形態の決済仲介システム１は、商品注文の際に購入者がクレジットカードによる支払方法（すなわち「クレジットカード決済」）を選択した場合に、購入者、販売者及びクレジットカード会社間を仲介し、円滑かつ確実に決済処理を仲介するシステムであり、サブシステムとして、購入意思確認システム、与信処理システム、荷物追跡情報連携商品代金請求システム及び荷物追跡情報連携商品代金支払システムを包含している。
なお、本発明の決済仲介システムの対象は、商品の有体・無体を問わず、代金の請求及び支払を伴う全ての商取引に適用可能である。
【００２２】
図１は、決済仲介システム１を実現するためのシステム構成の一例を示したブロック図である。
この図１に示されるように、決済仲介システム１は、狭義には、Ｗｅｂサーバ２と、販売者情報データベース１３、取引情報データベース１４及び業務システムサーバ１５を備えた業務システム３と、クレジットカード会社連携システム４とを備えてなり、広義には、更に支払処理サーバ５及び荷物追跡情報管理サーバ６を備えてなるシステムである。
この決済仲介システム１は、クレジットカード会社連携システム４を介して、外部システムであるクレジットカード会社管理システム７及び与信処理センターシステム８とそれぞれ接続する一方、インターネット１０を介して、販売者システム１１、購入者システム１２及び仮想店舗管理サーバ１６と接続している。
なお、詳しくは後述するが、上記支払処理サーバ５は、クレジットカード決済とは異なる決済方法である代金引換決済を管理する代金引換決済システム２０とも接続しており、上記荷物追跡情報管理サーバ６は、運送業者営業所内の端末２１Ａ及び運送業者のドライバーの携帯端末２１Ｂ（これらをまとめて「運送業者端末２１」という。）などと有線乃至無線で接続し、これら運送業者端末２１から荷物追跡情報を定期的又はリアルタイムで収集し蓄積・管理する機能を備えている。
【００２３】
なお、上記各サーバ（２，５、６、１５、１６）、上記各システム（３，４，７，８、１１、１２）及び上記各データベース（１３，１４）の実体はいずれもアプリケーションプログラム（ソフトウェア）であり、それぞれのプログラムの実効環境を有する１台若しくは複数台（分散型及び負担分散型含む）のコンピュータシステムに格納されている。これらコンピュータシステムは、ＣＰＵ及びＲＡＭを含み、その他オペレーティングシステム、通信インタフェース、ＣＲＴ等の表示装置、キーボードやマウスなどの入力装置、プリンタなどの出力装置などが、各サーバ、各システム及び各データベースの機能に沿って付加されている。
各サーバ間、各システム間及び各サーバ・システム間の接続は、専用回線、ＬＡＮ或いはＷＡＮなどのコンピュータネットワーク、無線などの情報の授受を行い得る任意の手段で接続することが可能であり、情報の送受信に関しては現在公知の暗号化技術（例えばＳＳＬなど）を利用することができる。また、当業者であれば当然理解できるから特に説明はしないが、本決済仲介システム１内の適宜箇所にファイアウオールなどの現在公知のセキュリティ対策手段を付加することは任意である。
また、例えばＷｅｂサーバ内に販売者情報データベース１３、取引情報データベース１４及び業務システムサーバ１５を配置する、すなわち業務システム３の機能とｗｅｂサーバ２の機能とをまとめて一つのサーバ内に配置するなど、本決済仲介システム１において各システム、各サーバ及び各データベースをどのように配置するかは任意に設計変更可能である。
【００２４】
次に、本決済仲介システム１の備えている機能実現手段について説明する。
【００２５】
本決済仲介システム１は、次のＡ〜Ｐの機能を実現するための手段を備えている（図２及び図３参照）。
なお、本決済仲介システム１は、購入者の購入意思を確認する手段として「メール確認方式」と「リンクボタン方式」とを備えているが、先ずは前者の「メール確認方式」による場合の機能実現手段について説明する。
【００２６】
Ａ．販売者システム１１からインターネット１０を介して送られて来た「注文情報」を受信し、この「注文情報」を各注文案件毎に関連付けて「取引情報レコード」として取引情報データベース１４に逐次蓄積する機能。
この際、「注文情報」は、例えばｅメールアドレスなどの購入者システム１２を識別し得る情報（以下「購入者システム識別情報」という）、「商品名」、運送料金など商品代金以外の諸料金を含む「決済総額」、注文番号など各取引案件を識別し得る情報（以下「取引識別情報」という。）などを含むのが好ましい。
なお、決済総額には、商品代金以外に、梱包料、決済手数料、運送料金、冷却保存料、消費税などが含まれる可能性がある。
【００２７】
Ｂ．「注文情報」を販売者システム１１から受信したら、この「注文情報」から「購入者システム識別情報（例えばｅメールアドレス）」を抽出し、その購入者システム識別情報の購入者システム１２に対して「与信処理開始を依頼する旨の情報」と「本決済仲介システム１へのアクセス情報」とをインターネット１０を介して送信する機能。
【００２８】
Ｃ．上記の購入者システム１２から「本決済仲介システム１へのアクセス要求」があったら、そのアクセス要求などから購入者システム識別情報を読み取り、この購入者システム識別情報と関連付けられている「取引情報」を取引情報データベース１４に問い合わせ、該当した「取引情報レコード」の中から抽出した少なくとも「決済総額」を含む「注文情報」と共に、購入意思を問い合わせる旨の「購入意思問い合わせ」、或いは、与信処理開始の了承を問い合わせる旨の「与信処理開始了承問い合わせ」を当該購入者システム１２にインターネット１０を介して送信する機能。
この際、「購入意思問い合わせ」「与信処理開始了承問い合わせ」は、いずれか一方或いは両方を送信すればよく、例えば、Ｗｅｂ画面内に、クリックすると購入意思確認或いは与信処理開始了承とみなす旨の説明文を付記した「確認・実効ボタン」を設け、その「確認・実効ボタン」をクリックすると「本決済仲介システム１」へアクセスするように設定することができる。
【００２９】
Ｄ．購入者システム１２から「購入意思確認の情報」或いは「与信処理開始了承の情報」を受信したら、当該購入者システム１２に対して、与信処理に必要な情報として「利用するクレジットカード会社の種類、クレジットカード番号及び有効期限（以下これらをまとめて「クレジットカード情報」という。）」の入力を要求する「クレジットカード情報入力依頼情報」をインターネット１０を介して送信する機能。
なお、上記Ｃの機能とＤの機能をまとめて、「決済総額」を含む「取引情報」と、「購入意思問い合わせ」或いは「与信処理開始了承問い合わせ」と、「クレジットカード情報入力依頼情報」とを同時に送信するようにしてもよい。
【００３０】
Ｅ．購入者システム１２から「クレジットカード情報」を受信したら、この「クレジットカード情報」と共に「与信処理の問い合わせ」を与信処理センターシステム８に送信する機能。
【００３１】
Ｆ．与信処理センターシステム８から「与信処理結果」を受信したら、この「与信処理結果」を取引情報データベース１４に随時蓄積し、その取引案件の「取引情報レコード」に「与信処理結果」を追加更新する機能。
Ｇ．与信処理センターシステム８から「与信処理結果」を受信したら、この「与信処理結果」に関連付けられた「購入者システム識別情報（例えばｅメールアドレス）」を取引情報データベース１４に問い合わせ、該当の購入者システム１２に対してインターネット１０を介して「与信処理結果」を送信する機能。
Ｈ．与信処理センターシステム８から「与信処理結果」を受信したら、この与信処理結果に関連する販売者システム識別情報（例えばｅメールアドレスや携帯電話番号等）を、販売者情報データベース１３及び取引情報データベース１４に問い合わせ、該当の販売者システム１１に対して「与信処理結果」或いは「与信処理結果が出ている旨」をインターネット１０を介して送信する機能。
【００３２】
Ｉ．販売者システム１１からの「取引識別情報（注文番号など）」を伴う要求に応じ、当該「取引識別情報」に関連付けられた「取引情報」を取引情報データベース１４に問い合わせ、該当した「与信処理結果付きの取引情報」を当該販売者システム１１に送信する機能。
【００３３】
Ｊ．販売者システム１１から「取引識別情報（注文番号）」と共に、「少なくとも「発送予定日」と送り状番号などの運送案件一件一件を識別し得る「運送荷物識別情報」とを含む情報（以下「発送予定情報」という。）」を受信したら、取引情報データベース１４に随時蓄積し、その「取引識別情報」に関連付けられた「取引情報レコード」に「発送予定情報」を追加更新し、取引識別情報と運送荷物識別情報とを紐付けする機能。
Ｋ．販売者でも購入者でもない第三者（例えば運送業者のドライバー或いは事務員など）が入力した商品の集荷済情報（以下「集荷済情報」という。）を、送り状番号等の「運送荷物識別情報」と共に荷物追跡情報管理サーバ６で随時受信し、当該「集荷済情報」を「運送荷物識別情報」及びその他の「運送荷物識別情報を含む荷物追跡情報」と関連付けて、運送案件毎に一つのレコード単位として（各単位を「荷物追跡情報レコード」という。）随時蓄積する機能。
【００３４】
Ｌ．取引情報データベース１４内の「取引情報」と、上記荷物追跡情報管理サーバ６内の「荷物追跡情報」とを、送り状番号等の「運送荷物識別情報」をキーとして、定期的或いは随時に照合する機能。
この際、「発送予定情報」が追加された「取引情報レコード」のみを、「荷物追跡情報」とバッチ処理によって照合するようにすれば、照合作業の効率化を図ることができると共に、システムの負担を軽減することができる。
Ｍ．上記照合によって新たに「集荷済み」となった取引案件を抽出し、抽出された取引案件と関連付けられた取引情報データベース１４内の「取引情報レコード」に「集荷済情報」を追加更新する機能。
Ｎ．上記照合によって新たに「集荷済み」となった取引案件を抽出し、抽出された取引案件については「集荷済情報」と照合された時点で「売上確定」とみなし、その取引案件の「取引情報」を取引情報データベース１４に問い合わせ、該当の「取引情報」に基づいてクレジットカード会社管理サーバ７に対する売上請求処理を自動的に進行させる機能。
Ｏ．上記照合によって新たに「集荷済み」となった取引案件を抽出し、抽出された取引案件については「集荷済情報」と照合された時点で「売上確定」とみなし、その取引案件の「取引情報」を取引情報データベース１４に問い合わせ、該当の「取引情報」に基づいて販売者に対する立替払い処理（支払処理）を自動的に進行させる機能。
【００３５】
Ｐ．クレジットカード決済による取引案件の支払額を販売者毎に連結すると共に、代金引換決済による取引案件の支払額を販売者毎に連結し、連結した２つの支払額を販売者毎に更に連結し、クレジットカード決済による支払額と代金引換決済による支払額とをとりまとめて支払明細書に表示する機能。
【００３６】
なお、「リンクボタン方式」の場合には、上記Ａ及びＢの機能実現手段は必要なく、上記Ｃ〜Ｐの機能を備えていればよい。詳しくは下記に別途説明する。
【００３７】
次に、決済仲介システム１を構成するサブシステムとしてのサーバ及びシステム等の構成及び機能を、より具体的な実施例をもって説明する。
【００３８】
Ｗｅｂサーバ２は、インターネット１０と接続し（ＨＴＴＰやＳＳＬなどのインターネット標準プロトコルにより通信可能となっている。）、Ｗｅｂ上に「決済サイト」（ホームページ）を開設し、この「決済サイト」を通じて販売者システム１１及び購入者システム１２と情報の授受を行うことができる。その一方、本決済仲介システム１内においては業務システム３及びクレジットカード会社連携システム４ともそれぞれ接続し、本決済仲介システム１と販売者システム１１及び購入者システム１２とのインタフェースとして機能する。
【００３９】
「決済サイト」は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）で記述してあり、図４に示すように、Ｗｅｂページとしての「販売者用ページ」と「購入者用ページ」とを備え、当該「販売者用ページ」は、注文情報の入力欄を含む「注文情報入力ページ」、取引情報及び荷物追跡情報の一覧を示す「取引情報確認ページ」、商品の発送予定日時の入力欄を含む「発送予定情報入力ページ」及び「支払精算情報確認ページ」を備え、「購入者用ページ」はクレジットカード情報の入力欄を含む「与信処理依頼ページ」を備えている。
なお、「決済サイト」の定義形式をＨＴＭＬ形式に限定するものではなく、ＸＭＬ（eXtensible Markup Language）などその他の定義形式（言語）を採用することもできる。また、本実施形態での「販売者用ページ」及び「購入者用ページ」は各取引案件毎に形成してあるが、例えば各個人毎に形成することもできる。
【００４０】
Ｗｅｂサーバ２は、「メール確認方式」としての購入意思確認手段として、次に示す(1)〜(8)の機能を実現するための手段を備えている（図５参照）。
【００４１】
(1) 販売者システム１１からインターネット１０を介して送信されてきた「決済サイトへのアクセス要求（ＵＲＬ）」を受信したら、「販売者識別情報（例えば販売者識別番号及びパスワード）を要求する情報」を返信する機能。
この際、「注文情報入力ページ画面情報」は、Ｗｅｂページ画面内に必要な注文情報の入力を促す「注文情報入力欄」を表示するように設定するのが好ましい。
なお、「注文情報入力ページへのアクセス要求」等の「Ｗｅｂページへのアクセス要求」は、通常、ＵＲＬを指定してＨＴＭＬドキュメント転送要求の形式で送られてくるが、このような形式に限定されるものではない（以下の「Ｗｅｂページ送信要求」についても同様）。また、この要求に応えて送信される「Ｗｅｂページ画面情報」は、通常、テキスト、グラフィックス、コントロール及びその他の機能を表示する様々なタグを含むＨＴＭＬドキュメントとして送られるが、この形式に限定するものでもない（以下の「Ｗｅｂページ画面情報」についても同様）。
【００４２】
(2) 販売者システム１１から「販売者識別情報（例えば販売者識別番号及びパスワード）」を受信したら、販売者情報データベース１３に対し、送られてきた「販売者識別情報（例えば販売者識別番号及びパスワード）」と蓄積されている「販売者識別情報（例えば販売者識別番号及びパスワード）」と照合させ、認証されたら当該「販売者識別情報」と関連付けられた「販売者用ページ画面情報」を当該販売者システム１１に送信する機能。
なお、本実施形態では、販売者用ページへのアクセスは、先ず「決済サイト」へのアクセスを必要とし、いきなり「注文情報入力ページ」「取引情報確認ページ」「発送予定情報入力情報ページ」「支払精算情報確認ページ」などのサブページへアクセスできない設定としてあるが、直接アクセス可能とすることもできる。
【００４３】
(3) 販売者システム１１からインターネット１０を介して送信されてきた「注文情報（注文日、取引識別情報（注文番号など）、ｅメールアドレスなどの購入者システム１２を識別する購入者システム識別情報、決済総額（運送料金など商品代金以外の諸料金を含む）、その他必要に応じて商品概要及び通信文などを含む）」を受信したら、この「注文情報」を取引情報データベース１４に送信する機能。
【００４４】
(4) 販売者システム１１からインターネット１０を介して送信されてきた「注文情報」を受信したら、その「注文情報」からｅメールアドレスなどの購入者システム識別情報を抽出し、この購入者システム識別情報宛に、与信処理開始を依頼する旨の「与信処理開始依頼情報」と共に決済サイト内の「購入者用ページへのアクセス情報(ＵＲＬ)」をインターネット１０を介して送信する機能。
この際、「与信処理開始依頼情報」は、例えばｅメールの形式で送信し、「購入者用ページへのアクセス情報」は当該購入者用ページのＵＲＬを当該ｅメール内にリンクボタン形式で埋め込み、当該リンクボタンをクリックすると購入者用ページに直接アクセスできるように設定するのが好ましい。具体的には、例えば、挨拶文と共に「与信処理開始を了承いただけましたら下記「確認・実効ボタン」をクリックしてください。」などのテキスト文を付けて、この「確認・実効ボタン」に購入者用ページとリンクを張るように設定することができる。
【００４５】
(5) 購入者システム１２から「購入者用ページへのアクセス要求」があったら、このアクセス要求等からｅメールアドレスなどの購入者システム識別情報を抽出し、この「購入者システム識別情報」と関連付けられている「取引情報（店名、注文日、取引識別情報（注文番号など）、決済総額（運送料金など商品代金以外の諸料金を含む）、商品概要及び通信文など）」を取引情報データベース１４に問い合わせ、該当した「取引情報レコード」の中から所定の「注文情報（注文日、取引識別情報（注文番号など）、ｅメールアドレスなどの購入者システム識別情報、決済総額（運送料金など商品代金以外の諸料金を含む）、商品概要などを含む）」を抽出し、この「注文情報」と共に、購入意思を確認する「購入意思問い合わせ情報」或いは与信処理開始了承を問い合わせる「与信処理開始了承問い合わせ情報」或いはこれらの両方をインターネット１０を介して当該購入者システム１２に送信する機能。
この際、「購入意思問い合わせ情報」及び「与信処理開始了承問い合わせ情報」は、例えば与信処理依頼ページ画面内に「取引情報」を表示すると共に、「上記注文内容につき、購入及び与信処理開始をご了承いただけましたら下記「確認・実効ボタン」をクリックください。」などのテキスト文を表示し、この「確認・実効ボタン」を下記「クレジットカード情報入力ページ」とリンクさせると共に、この「確認・実効ボタン」のクリックを「購入意思確認」或いは「与信処理開始了承」の返信とみなすことができるように設定することができる。
【００４６】
(6) 購入者システム１２から「購入意思確認」或いは「与信処理開始了承」の旨を含む情報を受信したら、クレジットカード情報の入力を依頼する「クレジットカード情報入力依頼情報」を当該購入者システム１２にインターネット１０を介して送信する機能。
この際、「クレジットカード情報入力依頼情報」は、購入者用ページの第２ページとなるクレジットカード情報入力ページの画面内に「クレジットカード情報」の入力を促す「クレジットカード情報入力欄」と「確認・実効ボタン」とを表示する内容の情報とすることができる。
なお、与信処理依頼ページ画面とクレジットカード情報入力ページとを一つのページにまとめることも可能である。その場合には、例えば同一画面内に「取引情報」「クレジットカード情報入力欄」及び「確認・実効ボタン」を表示するようにすればよい。
【００４７】
(7) 購入者システム１２からインターネット１０を介して「クレジットカード情報」を受信したら、この「クレジットカード情報」と共に、ｅメールアドレス等の「購入者システム識別情報」及び注文番号などの「取引識別情報」をクレジットカード会社連携システム４に送信し、クレジットカード会社連携システム４から送信されてきた「与信処理結果」を前記「購入者システム識別情報」と関連付けられた購入者システム１２にインターネット１０を介して送信する機能。
この際、「クレジットカード情報入力ページ」の画面内に「与信処理結果」を表示させ、購入者がクレジットカード情報を入力したまましばらく待てば「与信処理結果」が表示されるようにするのが好ましい。
【００４８】
なお、「リンクボタン方式」による購入意思確認手段では、上記(1)〜(4)の機能実現手段は不要である。すなわち、「リンクボタン方式」による購入意思確認手段の場合には、例えばＷｅｂ上に設けられた仮想店舗の画面内に「与信処理依頼ページ」とリンクした「クレジットカード決済ボタン」を設けることで、いきなり上記(5)の購入者システム１２からの「購入者用ページへのアクセス要求」を受けることができるからであり、後は「メール確認方式」の場合と同様の機能実現手段を備えていればよい。
【００４９】
Ｗｅｂサーバ２は、次に示す(8)の機能を実現するための手段も備えている。
【００５０】
(8) 販売者システム１１からインターネット１０を介して送信されてきた「取引情報確認ページへのアクセス要求(ＵＲＬ)」及び「取引識別情報（注文番号など）」を受信したら、当該「取引識別情報」と関連付けられている「取引情報」を取引情報データベース１４に問い合わせ、抽出された「取引情報」を「販売者用ページ画面情報」と共に販売者システム１１に送信する機能。
この際、既に与信処理結果が出ていれば、上記「取引情報」には「与信処理結果」を付加することができる。
【００５１】
Ｗｅｂサーバ２は、次に示す(9)〜(10)の機能を実現するための手段も備えている（図５参照）。
【００５２】
(9) 販売者システム１１からインターネット１０を介して送信されてきた「発送予定情報入力ページへのアクセス要求（ＵＲＬ）」を受信したら、当該販売者システム１１に「発送予定情報入力ページ画面情報」を送信する機能。
この際、発送予定情報入力ページ画面には、与信処理結果が追加された取引情報のうち、発送予定情報の入力が未だなされていない取引情報レコードだけを抽出して一覧表示するように設計することができる。
(10) そして、販売者システム１１から「発送予定情報（発送日及び送り状番号などの運送荷物識別情報含む）」と「取引識別情報（注文番号など）」を受信したら、これら「取引識別情報」及び「発送予定情報」を取引情報データベース１４に送信する機能。
【００５３】
Ｗｅｂサーバ２は更に、次に示す(11)及び(12)の機能を実現するための手段も備えている。
【００５４】
(11) 販売者システム１１からインターネット１０を介して送信されてきた「支払精算情報確認ページへのアクセス要求（ＵＲＬ）」を受信したら、「支払精算情報確認ページ画面情報」と共に、「取引識別情報の記入を促す情報」を当該販売者システム１１に送信する機能。
(12) そして、販売者システム１１から「取引識別情報」の返信を受けたら、「取引識別情報」と関連付けられている「決済情報」を支払処理サーバ５に問い合わせ、抽出された「決済情報」を「支払精算情報確認ページ画面情報」と共に当該販売者システム１１に送信する機能。
この際、支払精算情報確認ページ画面では、後日紙で送付される支払精算書のイメージが確認できるように設計することもできる。
【００５５】
次に、業務システム３の構成及び機能について具体的に説明する。
業務システム３は、販売者情報データベース１３、取引情報データベース１４及び業務システムサーバ１５を備えている。
【００５６】
販売者情報データベース１３は、ＤＢＭＳ（データベース管理システム）を備え、販売者情報を販売者毎に一つのレコード単位を作成するようにデータベース化して蓄積し、情報の検索、検索結果の提供及び訂正・変更を逐次行い得る機能を備えている。例えば、本システム内で販売者を識別するための「販売者識別番号」、クレジットカード会社連携システム４がそのシステム上販売者を識別するための「端末識別番号」、ｅメールアドレス等の販売者システム識別情報、各クレジットカード会社が精算上販売者を識別するために付与する「加盟店番号」、屋号、パスワード、手数料テーブル及び利用クレジットカード会社などを、前記「販売者識別番号」に関連付けて蓄積し、「販売者識別番号」は勿論、「販売者識別番号」と紐付けられた「端末識別番号」及び「加盟店番号」からも容易に目的の販売者情報を検索できるように設計してある。
ここで、上記の「販売者識別番号」は、「販売者識別親番号」＋「所定桁の適宜番号」（これを「販売者識別子番号」という。）という番号体系で構成してある。すなわち、販売者毎に「販売者識別親番号」を付与すると共に、同一販売者に対して複数の「販売者識別子番号」を付与できるように構成してある。このような番号体系とすることにより、同一販売者が業態の異なる店舗を運営しているような場合、それぞれの店舗ごとに「端末識別番号」及び「加盟店番号」を付与することができる。しかも、「販売者識別子番号」から「販売者識別親番号」を容易に抽出することができるから、例えば、異なる「販売者識別番号（販売者識別子番号）」が付与された取引情報、売上請求情報、支払精算情報などであっても、「販売者識別親番号」をキーとして、言い換えれば販売者毎に容易に連結し、とりまとめることができる。
さらに、「販売者識別親番号」は、代金引換決済システム２０が販売者毎に付与する番号と一致させてあり、代金引換決済システム２０が管理する情報（例えば取引情報、支払情報など）と、本クレジットカード決済仲介システム１が管理する情報（例えば取引情報、支払情報など）とを、「販売者識別親番号」をキーとして販売者毎に連結し、とりまとめることができるようになっている。
【００５７】
取引情報データベース１４は、ＤＢＭＳ（データベース管理システム）を備え、取引情報を取引案件毎（言い換えれば注文番号毎）に一つのレコード単位を作成するようにデータベース化して蓄積し、情報の検索、検索結果の提供及び訂正・変更を逐次行い得る機能を備えている。例えば、販売者識別情報、ｅメールアドレス等の購入者システム識別情報、注文日、注文番号、決済金額、商品概要、与信処理結果（与信承認番号を含む与信承認情報（与信結果が「良」である旨の情報）又は与信ＮＧ情報（与信結果が「否」である旨の情報）を含む）、発送予定情報（送り状番号、発送日及び通信文を含む）、集荷済情報、売上請求情報、支払精算情報などの取引情報をそれぞれ取引案件毎に関連付けて蓄積し、購入者システム識別情報、注文番号、与信承認番号、送り状番号などのいずれの取引識別コードからでも検索できるように設計してある。
【００５８】
業務システムサーバ１５は、Ｗｅｂアプリケーションサーバとしての機能を有し、業務システム３内外のインタフェースとしての機能実現手段を備えており、具体的には、次に示す(13)〜(21)の機能を実現するための手段を備えている（図５参照）。
【００５９】
(13) Ｗｅｂサーバ２から送られてきた「注文情報（注文日、取引識別情報（注文番号など）、購入者ｅメールアドレス、決済金額、その他必要に応じて商品概要及び通信文などを含む）」を受信したら、この「注文情報」を取引情報データベース１４に取引案件（取引識別情報）毎に関連づけて一つの取引情報レコードとして随時蓄積させる機能。
【００６０】
(14) Ｗｅｂサーバ２から送られてきた「取引情報の問い合わせ（検索要求）」と購入者ｅメールアドレスなどの「購入者システム識別情報」とを受信したら、取引情報データベース１４にその「購入者システム識別情報」と関連付けられた「取引情報」を検索させ、抽出された「取引情報レコード」の中から所定の「取引情報」をＷｅｂサーバ２に返信する機能。
【００６１】
(15) クレジットカード会社連携システム４から送られてきた「与信処理結果情報（与信承認番号を含む与信承認情報又は与信ＮＧ情報）」を取引情報データベース１４に送り、その取引識別情報（注文番号など）と関連付けられた「取引情報レコード」に「与信処理結果情報」を追加更新させて、注文番号等の取引識別情報と与信承認番号とを紐付けする機能。
(16) クレジットカード会社連携システム４から送られてきた「与信処理結果情報」を受けて、その取引識別情報（注文番号など）に基づき、販売者システム１１のｅメールアドレスを取引情報データベース１４及び販売者情報データベース１３に検索させ、該当の販売者システム１１に対して「与信処理通知メール（取引識別情報及び与信処理結果が出た旨を含むｅメール）」をインターネット１０を介して送信する機能。
具体的には、クレジットカード会社連携システム４から送られてきた「与信処理結果情報」を受けたら、その取引識別情報（注文番号など）に関連した販売者識別情報（例えば販売者識別番号）を取引情報データベース１４に検索させ、その販売者識別情報に関連した販売者システム１１のｅメールアドレスを販売者情報データベース１３に検索させ、該当の販売者システム１１に対して「与信処理通知メール」をインターネット１０を介して送信するように設計することができる。また、販売者情報データベース１３に販売者システム１１のｅメールアドレスを蓄積させておき、取引識別情報に基づいて販売者情報データベース１３に直接、販売者システム１１のｅメールアドレスを検索させることができるように設計することもできる。
【００６２】
(17) Ｗｅｂサーバ２から送られてきた「取引識別情報（注文番号など）」及び「発送予定情報（発送日及び送り状番号などの運送荷物識別情報を含む）」を受信したら、当該「発送予定情報」を取引情報データベース１４に送り、その取引識別情報と関連付けられている「取引情報レコード」に「発送予定情報」を追加更新させ、注文番号等の「取引識別情報」と送り状番号等の「運送荷物識別情報」とを紐付けすると共に当該「取引情報レコード」を「集荷確認待ち」のステータスとする機能。
(18) Ｗｅｂサーバ２から送られてきた「発送予定情報」及び「取引識別情報」を受けて、その取引識別情報に基づいて、購入者システム１２の購入者システム識別情報（例えばｅメールアドレス）を取引情報データベース１４に問い合わせ、該当の購入者システム１２に対して「発送通知メール」をインターネット１０を介して送信する機能。
この際、「発送通知メール」には、送り状番号などの運送荷物識別情報と共に、荷物追跡情報管理サーバ６が開設する「購入者別荷物追跡サイト」へのアクセス情報（ＵＲＬ）を埋め込んでおき、「発送通知メール」を受信した購入者が、そのアクセス情報部分をクリックすれば「購入者別荷物追跡サイト」にジャンプして即座に自分宛の荷物の運送状態を確認できるようにするのが好ましい。
【００６３】
(19) 随時或いは所定時間毎に、荷物追跡情報管理サーバ６に対して「運送状態の問い合わせ要求」を送り、取引情報データベース１４内の「取引情報」（好ましくは「集荷確認待ち」のステータスの取引情報レコードのみ）と、荷物追跡情報管理サーバ６内の「荷物追跡情報」（好ましくは新たに「集荷済み」となった荷物追跡情報レコードのみ）とを、送り状番号等の「運送荷物識別情報」をキーとしてバッチ処理により照合し、新たに「集荷済み」となった取引案件を抽出し、取引情報データベース１４に対し、当該抽出された取引案件と関連付けられた「取引情報レコード」に「集荷済情報（その旨及び集荷日時を含む）」を追加更新し、当該「取引情報レコード」を「売上確定」のステータスとする機能。
【００６４】
(20)(21) 上記照合作業で新たに「集荷済み」となった取引案件を抽出し、抽出された取引案件については「売上確定」とみなし、自動的に、当該取引案件の取引情報の一部である「支払精算情報」とその「取引識別情報」とを支払処理サーバ５に送信すると共に、その取引案件の取引情報の一部である「売上請求情報」とその「取引識別情報」とをクレジットカード会社連携システム４に送信する機能。
【００６５】
クレジットカード会社連携システム４は、次に示す(22)〜(25)の機能を実現するための手段を備えている。
【００６６】
(22) Ｗｅｂサーバ２から、「クレジットカード情報」、ｅメールアドレス等の「購入者システム識別情報」及び「取引識別情報（注文番号など）」などを受信したら、当該「クレジットカード情報」を与信処理センターシステム８に送信する機能、及び、与信処理センターシステム８からその「与信処理結果情報（与信承認番号を含む与信承認情報又は与信ＮＧ情報）」を受信する機能。
(23) 与信処理センターシステム８から「与信処理結果情報」を受けたら、「取引識別情報（注文番号など）」と共に「与信処理結果情報」を業務システム３に送信する機能。
(24) 与信処理センターシステム８から「与信処理結果情報」を受けたら、前記購入者システム１２に対して「与信処理完了メール（与信処理が完了した旨の情報）」を送信する機能。
(25) 業務システムサーバ１５から「売上請求情報」及び「取引識別情報」を受信したら、随時或いは所定締め日に、各クレジットカード会社管理システム７に必要な「売上請求情報」を送信する機能。
【００６７】
支払処理サーバ５は、商品配達時にその場で代金の集金を行う代金引換サービスの支払精算情報を収集・管理する代金引換決済システム２０とも接続しており、次に示す(26)〜(28)の機能を実現するための手段を備えている（図５参照）。
【００６８】
(26) 業務システムサーバ１５から「取引識別情報」及び「支払精算情報」を受け取ると、随時或いは所定時期に、自動的に販売者毎に「支払精算情報」を連結する機能。
(27) 代金引換決済システム２０から「取引識別情報」及び「支払精算情報」を受け取ると、随時或いは所定時期に、自動的に販売者毎「支払精算情報」を連結する機能。
(28) (26)で連結したクレジットカード決済支払精算情報と、(27)で連結した代金引換決済支払精算情報とを、自動的に販売者毎に連結して「支払精算書」を作成する機能。
【００６９】
上記支払処理サーバ５の機能において、販売者毎に「支払精算情報」を連結する場合、各「支払精算情報」に販売者識別番号（「販売者識別親番号」＋「所定桁の適宜番号」）を関連付けておくことにより、「販売者識別親番号」をキーとして連結しとりまとめることができる。言い換えれば、同一販売者が業態の異なる複数の店舗を所有している場合であっても、販売者毎に「支払精算情報」を容易に連結してとりまとめることができる。
【００７０】
荷物追跡情報管理サーバ６は、運送業者の営業所内に配置された端末２１Ａや運送業者のドライバーが携帯する携帯端末２１Ｂなどの運送業者端末２１と有線乃至無線で接続し、集荷依頼情報、配達場所、配達予定日時、担当ドライバー名乃至その識別番号、更には荷物の集荷済情報や配達完了情報など荷物を預かってから当該荷物を荷受人に配達するまでの各段階の完了をそれぞれ示す確認情報などの「荷物追跡情報」を定期的又はリアルタイムに収集し、運送案件毎に関連付けて一つのレコード単位として蓄積・管理する機能を備えている（各レコード単位を「荷物追跡情報レコード」という。）。例えば、運送業者のドライバーが荷物（商品）を集荷したら、当該ドライバーがその場で携帯端末２１Ｂを利用して「集荷済情報」を荷物追跡情報管理サーバ６に送信し、これを受けた荷物追跡情報管理サーバ６はその運送案件の「荷物追跡情報レコード」に「集荷済情報」を追加更新し、「集荷済み」のステータスとする機能を備えている。
また、業務システムサーバ１５から「運送状態の問い合わせ要求」があると、「集荷済み」ステータスの荷物追跡情報を業務システムサーバ１５に送信する機能を備えている。
【００７１】
クレジットカード会社管理システム７及び与信処理センターシステム８は、それぞれ各クレジットカード会社及び与信処理センターが管理するコンピュータシステムであり、各社のサービス業務を行う機能実現手段を備えている。
与信処理センターシステム８では、本システム１のクレジットカード会社連携システム４からの「与信処理問い合わせ」に対して、送られてきた「クレジットカード情報」に基づいてその購入者が支払可能であるかの審査（与信処理）を行い、与信結果が「良」の場合の与信承認番号を含む与信承認情報又は与信結果が「否」である場合の与信ＮＧ情報（これらを「与信処理結果情報」という。）を返信する機能を備えている。
なお、与信処理センターシステム８は、各クレジットカード会社が保有するか或いは各クレジットカード会社と専属的な与信処理契約を結び、クレジットカード会社内に設置されていても、或いは専用回線を通じて各クレジットカード会社のクレジットカード会社管理システム７と接続されていてもよい。
【００７２】
インターネット１０は、通信ネットワーク手段の一例であり、その他の公衆アクセス通信ネットワーク或いは専用回線通信ネットワークにより、本システム１、販売者システム１１、購入者システム１２、仮想店舗管理サーバ１６間を接続することもできる。
【００７３】
販売者システム１１は、本決済仲介システム１に対して決済処理を委託する、言い換えれば本決済仲介システム１の決済仲介サービスを受ける旨の販売店登録（契約）をしているクライアントが管理するシステムである。
購入者システム１２は、上記の販売者（販売店登録済）に対して商品購入注文を出した者の中で、商品注文の際にクレジットカード決済を選択した購入者（本システム１側から見れば本決済仲介システム１の与信処理サービスを受けるクライアント）が管理するシステムである。
上記いずれのシステムも、インターネット１０と接続し、ＨＴＴＰやＳＳＬなどのインターネット標準プロトコルにより通信可能となっており、一台若しくは複数台のコンピュータ或いは携帯電話などの携帯端末を備え、更にはＷｅｂサーバ２から送られてくるＷｅｂページを表示できるブラウザ（例えばネットスケープ社のNetscape navigatorやマイクロソフト社のInternet Explorerなど）を備えているのが好ましい。
【００７４】
仮想店舗管理サーバ１６は、本決済仲介システム１のクライアントである販売者が、購入意思確認手段として「リンクボタン方式」を選択した場合に本決済仲介システム１と接続するものであり、インターネット（Ｗｅｂ）上に「仮想店舗（Ｗｅｂ上の電子商店）」を開設し、この「仮想店舗」を通じて購入者システム１２と情報の授受を行うことができる。
「仮想店舗」内には、「与信処理依頼ページ」とリンクした「クレジットカード決済ボタン」を設け、この「クレジットカード決済ボタン」をクリックすると「与信処理依頼ページ」にジャンプするように設定するのが好ましい。
但し、「仮想店舗」は、販売者自身が開設した仮想店舗であっても、他社が管理するサイバーモールなどの複数の店舗が軒を連ねる電子商店街の形式のものであってもよい。
【００７５】
以下、上記決済仲介システム１で実現することができるクレジットカード決済仲介サービス（クレジットカード決済仲介方法）の一例について具体例をもって説明する。
なお、本クレジットカード決済仲介サービス（クレジットカード決済仲介方法）は、購入意思確認サービス（方法）、与信処理サービス（方法）、集荷済情報と連携した代金請求サービス（方法）及び同じく集荷済情報と連携した代金立替払いサービス（方法）を包含している。
【００７６】
（販売店登録）
本決済仲介システム１（以下「本システム１」という）によるサービスを受けるためには、販売者は、予め本システム１に対して販売店登録をする必要がある。
この販売店登録は、通常、所定の審査を行った上、販売者に対して「販売者識別番号」を割り当てると共に所定の「パスワード」を与える一方、販売者識別番号、端末識別番号、加盟店番号、販売者システムのｅメールアドレス、屋号、手数料テーブル、利用クレジットカード会社、商品代金支払先の金融機関口座番号などの販売者情報を販売者毎に関連付けて販売者情報データベース１３に蓄積（登録）することにより行われる。
【００７７】
販売者は、販売店登録の際に、購入者に対する購入意思確認手段（与信処理開始依頼手段とも言える。）として「メール確認方式」及び「リンクボタン方式」のいずれか或いは両方を選択することができる。「リンクボタン方式」を選択した場合には、上述のように、仮想店舗管理サーバ１６内の当該販売者の「仮想店舗」内に、「与信処理依頼ページ」と直接リンクした「クレジットカード決済ボタン」を設け、この「クレジットカード決済ボタン」をクリックすると「与信処理依頼ページへのアクセス要求（ＵＲＬ）」と共に、ｅメールアドレス等の購入者システム識別情報、注文日、注文番号及び決済金額等の注文情報がインターネット１０を介してＷｅｂサーバ２に送信されるように設定する。
【００７８】
先ずは、「メール確認方式」を採用した場合の購入意思確認〜与信処理、代金請求・代金立替払いまでの一連の流れについて説明する。
【００７９】
「メール確認方式」の場合には、購入者は、販売者に対して任意の方法で商品の「注文情報」（商品、注文番号、ｅメールアドレスなどの購入者システム識別情報、届け先情報、決済方法を含む）を送信すればよい。例えば、販売者がＷｅｂ上に開設している「仮想店舗」に購入者がアクセスし、電子カタログからあるアイテムを選択してＷｅｂ上で「注文依頼」を送信してもよいし、ｅメール、電話、ｆａｘ、郵便その他の通信手段によって「注文情報」を販売者に送り、販売者がこれを取得するような方法でもよい。
そして、購入者が決済方法としてクレジットカード決済を選択した場合、以下に説明するような本システム１のサービスを受けることができる。
【００８０】
販売者は、先ず、販売者システム１１により「決済サイト」のＵＲＬを指定して「決済サイト（販売者用ページ）へのアクセス要求」を本システム１（Ｗｅｂサーバ２）に送信する。
このアクセス要求を受けた本システム１（Ｗｅｂサーバ２）は、販売者識別番号及びパスワードの記入を要求するダイアログボックス付Ｗｅｂページを販売者システム１１に送信する。
販売者が、所定の「販売者識別番号及びパスワード」を入力して返信すると、本システム１は、販売者情報データベース１３にて蓄積している販売登録時に割り当てた「販売者識別番号及びパスワード」と認証した後、認証されたら「販売者用ページのフロント画面情報」を販売者システム１１に送信する。この際、販売者システム１１のモニターには、「販売者用ページのフロント画面」が表示され、この画面内には「注文情報入力ページ」「取引情報確認ページ」「発送予定情報入力ページ」及び「支払精算情報確認ページ」への各遷移ボタンが表示される。
【００８１】
販売者が、「注文情報入力ページ」への遷移ボタンをクリックすると、販売者システム１１のモニターには、商品名、注文日、注文番号、ｅメールアドレスなどの購入者システム識別情報、運送料金など商品代金以外の諸料金を含んだ決済総額、届け先情報、決済方法などの「注文情報」の入力を促すダイアログボックス形式の「入力欄」と「確認・実効ボタン」とが表示される。
販売者が、必要な全ての「入力欄」に所定事項を記入し、「確認・実効ボタン」をクリックすると、「注文情報」は本システム１（Ｗｅｂサーバ２）に送られる。
【００８２】
この「注文情報」を受け取った本システム１は、本システム１内の取引情報データベース１４に注文案件毎に関連付けて逐次蓄積する共に、その「注文情報」から購入者システム１２に関連するｅメールアドレスなどの購入者システム識別情報を抽出し、この購入者システム識別情報（ｅメールアドレス）宛に、例えば「この度は、○○（商品）のご注文ありがとうございます。つきましては、クレジットカード決済に与信処理が必要ですので、与信処理開始をご了承いただけましたら下記「確認・実効ボタン」をクリックしてください。」などのテキスト文と共に、「与信処理依頼ページ」と直接リンクした「確認・実効ボタン」を埋め込んだ「与信処理開始依頼メール」をインターネット１０を介して送信する。
【００８３】
この「与信処理開始依頼メール」を受けた購入者が、メール内の「確認・実効ボタン」をクリックすると、与信処理依頼ページへのアクセス要求（ＵＲＬ）が本システム１に送られる。
そして、このアクセス要求を受けた本システム１は、アクセス要求からｅメールアドレス等の購入者システム識別情報を抽出し、この購入者システム識別情報と関連付けられた取引情報を取引情報データベース１４に問い合わせ、その中から抽出した注文情報と共に「与信処理依頼ページ画面情報」を購入者システム１２に送信する。
すると、購入者システム１２のモニターには、「店名」「注文日」「注文番号」「決済総額（運送料金など商品代金以外の諸料金を含む）」などの注文情報と共に、「購入意思或いは与信処理開始の了承を確認する旨」、例えば「上記注文内容につきご確認いただき、与信処理開始をご了承いただけましたら、下記「確認・実効ボタン」をクリックください。」などのテキスト文と共に、クリックすると「クレジットカード情報入力ページ」へ遷移する「確認・実効ボタン」も表示される。
【００８４】
この「確認・実効ボタン」をクリックすると、「クレジットカード情報入力ページ」に遷移し、このページには、クレジットカード情報の入力を促す「クレジットカード情報入力欄」と「確認・実効ボタン」とが表示される。
購入者が、「クレジットカード情報入力欄」の必要項目全てに記入して「確認・実効ボタン」をクリックすると、本システム１を介して「クレジットカード情報」が該当するクレジットカード会社の与信処理センターシステム８にリアルタイムに送信され、当該送信後若干の時間（数秒〜数分）をおいて、与信処理センターシステム８から「与信処理結果情報（与信承認番号を含む与信承認情報又は与信ＮＧ情報）」が本システム１に返信されてくる。
本決済仲介システム１は、与信処理センターシステム８からの「与信処理結果情報」を受信すると同時に、「与信処理結果情報」を購入者システム１２に送信し、前記「クレジットカード情報入力ページ」の画面内に「与信処理結果情報」を表示する。また同時に、「与信処理結果情報」を取引情報データベース１４に送り、その注文案件の「取引情報レコード」に「与信処理結果情報」を追加更新すると共に、注文番号などの取引識別情報に関連付けられた販売者識別情報（例えば販売者識別番号）を取引情報データベース１４に検索させ、その販売者識別情報に関連した販売者システム１１のｅメールアドレスなどの販売者システム識別情報を販売者情報データベース１３に検索させ、該当の販売者システム１１に対して「与信処理通知メール（注文番号及び与信処理結果が出た旨を含むｅメール）」をインターネット１０を介して送信する。
さらに、購入者システム１２に対して「与信処理完了メール（与信の結果が「良」ならば注文が完了した旨を含むメール）」をインターネット１０を介して送信する。
【００８５】
上記の「与信処理通知メール」を受けた販売者が、決済サイト内の「取引情報確認ページ」へアクセスし、「取引識別情報（注文番号や注文日、購入者名など）」を入力して「取引情報」を問い合わせると、取引情報確認ページ画面内に当該「取引識別情報」と関連付けられている「取引情報」が表示され、与信処理結果の欄には「良」若しくは「否（ＮＧ）」の旨が表示される。
【００８６】
この結果を見て販売者は、商品発送の是非を判断し、良好な与信処理結果が得られれば、出荷準備を進めて送り状（配送伝票）を作成し、販売者は注文番号などの取引識別情報を入力して決済サイト内の「発送予定情報入力ページ」へアクセスする。すると、発送予定情報入力ページ画面内には、当該注文番号などの取引識別情報に関連づけられた取引情報（与信処理結果含む）が一覧表示されると共に、「送り状番号記入欄」及び「確認・実効ボタン」が表示される。
販売者が送り状番号を記入して「確認・実効ボタン」をクリックすると、本システム１（Ｗｅｂサーバ２）はこれらを受信し、「発送予定情報」を取引情報データベース１４に送り、注文番号と関連する「取引情報レコード」に「発送予定情報」を追加更新し、注文番号と送り状番号とを紐付けると共に、このレコードを「集荷確認待ち」のステータスとする。と同時に、その注文番号に関連したｅメールアドレス等の購入者システム識別情報を取引情報データベース１４に問い合わせ、該当の購入者システム識別情報（ｅメールアドレス）宛に、挨拶文と共に注文日、注文番号、送り状番号、商品概要、発送日などを含み、かつ荷物追跡情報管理サーバ６が開設する「購入者別荷物追跡サイト」へのアクセス情報（ＵＲＬ）を埋め込んだ「発送通知メール」をインターネット１０を介して送信する。
【００８７】
この「発送通知メール」を受信した購入者が、「購入者別荷物追跡サイト」へのアクセス情報（ＵＲＬ）部分をクリックすると、「購入者別荷物追跡サイト」にジャンプし、その画面内で本件の送り状番号部分をクリックすれば即座に本運送案件の運送状態を確認することができ、更には、配達日の指定、配達先変更などを行うことができる。
【００８８】
その後、販売者が、所定の運送業者、例えば本システム１（荷物追跡情報管理サーバ６）と接続し得る運送業者端末２１を有する運送業者に商品（荷物）の集荷を依頼し、運送業者がこの荷物を受け取り、集荷を完了した時点で、運送業者の営業所内等の端末２１Ａ或いは運送業者のドライバーの携帯端末２１Ｂから定期的又はリアルタイムに集荷済情報が荷物追跡情報管理サーバ６に送られる。そして、この荷物追跡情報管理サーバ６はその運送案件の荷物追跡情報レコードに「集荷済情報」を逐次追加更新し、その荷物追跡情報レコードを集荷済みステータスとする。
【００８９】
本システム１の業務システム３は、所定時間毎（例えば毎日決められた時間に）、荷物追跡情報管理サーバ６に対して運送状態の問い合わせ要求を送り、取引情報データベース１４内の「集荷確認待ち」ステータスの「取引情報レコード」と、荷物追跡情報管理サーバ６内の「集荷済み」ステータスの「荷物追跡情報レコード」とを、例えば「送り状番号（運送荷物識別情報）」をキーとしてバッチ処理により照合させる作業を繰り返し行う。そして、本システム１の業務システム３は、この照合作業により、新たに「集荷済み」となった取引案件を抽出し、この取引案件と関連付けられた取引情報レコードに「集荷済情報（その旨及び出荷日時を含む）」を追加更新し、この時点でこの取引案件を「売上確定」ステータスとし、同時に販売者に対する立替払処理と各クレジットカード会社に対する売上請求処理とを自動的に進行させる。
【００９０】
販売者に対する立替払処理については、業務システム３から「支払精算情報」を支払処理サーバ５が受信し、随時或いは所定時期に自動的に販売者（販売者識別親番号）毎に「支払精算情報」を連結する一方、代金引換決済システム２０からも「支払精算情報」を受信して、随時或いは所定時期に自動的に販売者（販売者識別親番号）毎に「支払精算情報」を連結し、更に、随時或いは所定時期に自動的に両方の決済手段による「支払精算情報」を連結し、両方の決済手段からの支払精算をとりまとめて「支払精算書」を作成する。
これより、クレジットカード決済による支払精算書と代金引換決済による支払精算書とが一つにとりまとめられると共に、販売者が複数のクレジットカード会社を利用している場合であっても、複数のクレジットカード会社からの「支払精算書」が一つにとりまとめられる。したがって、販売者としては、本システム１を介した支払決済を一元的に管理（具体的には入金消込処理）することができる。しかも、販売者への支払（入金）についても、本システム１は「売上確定」後、自動的かつ速やかに立替払い処理するようになっているから、販売者が「決済サイト」に「注文情報」を入力してから例えば５日後には入金を行うことが可能となり、販売者にとっての債権回収期間が短縮される。
【００９１】
次に、販売者が「リンクボタン方式」を選択した場合について説明する。
この場合、上述のように、仮想店舗管理サーバ１６内の当該販売者の「仮想店舗」内に、「与信処理依頼ページ」と直接リンクした「クレジットカード決済ボタン」を設けると共に、「クレジットカード決済ボタン」をクリックすると「与信処理依頼ページへのアクセス要求」と共に、ｅメールアドレス等の購入者システム識別情報、注文日、注文番号及び決済金額等の注文情報がＷｅｂサーバ２に送信されるように設定しておく。
【００９２】
販売者が、上記「仮想店舗」に販売者がアクセスし、電子カタログからあるアイテムを選択し、上記の「クレジットカード決済ボタン」をクリックすると「与信処理依頼ページ」へ直接ジャンプするから、後は、上記「メール確認方式」と同様、「クレジットカード情報入力ページ」へ遷移して、このページ内で「クレジットカード情報入力欄」に必要項目全てに記入し「確認・実効ボタン」をクリックすれば与信処理に進むことができる。
【図面の簡単な説明】
【図１】 本発明の決済仲介システムを実現するためのシステム構成の一例を示したブロック図である。
【図２】 本発明の決済仲介システム及び決済仲介方法における処理の流れを例示した模式図である。
【図３】 本発明の決済仲介システム及び決済仲介方法における処理の流れを例示したフローチャートである。
【図４】 本発明の決済仲介システムがＷｅｂ上で開設する「決済サイト」の構造を示した図である。
【図５】 本発明の決済仲介システムを構成するＷｅｂサーバ、業務システム及び支払処理サーバにおける与信処理〜発送済確認〜決済処理までの主な流れを示したフローチャートである。
【図６】 従来の決済仲介モデルの構成の一例を示した模式図である。
【図７】 同じく、従来の決済仲介モデルの構成の一例を示した模式図である。
【符号の説明】
１ クレジットカード決済仲介システム
２ Ｗｅｂサーバ
３ 業務システム
４ クレジットカード会社連携システム
５ 支払処理サーバ
６ 荷物追跡情報管理サーバ
７ クレジットカード会社管理システム
８ 与信処理センターシステム
１０ インターネット
１１ 販売者システム
１２ 購入者システム
１３ 販売者情報データベース
１４ 取引情報データベース
１５ 業務システムサーバ
１６ 仮想店舗管理サーバ
２０ 代金引換決済システム
２１Ａ、２１Ｂ 運送業者端末

Claims (1)

1. 販売者情報データベース、取引情報データベース、支払処理サーバ、代金引換決済システム及びクレジットカード会社管理システムを備え、商品販売者のコンピュータである販売者システムおよび商品購入者のコンピュータである購入者システムとインターネットを介して接続することができる１台若しくは複数台のコンピュータからなる決済仲介システムを利用した決済仲介方法であって、
   販売者情報データベースが備えるデータベース管理システムが、販売者毎に販売者を識別する識別親番号を付与すると共に、同一販売者における当該識別親番号には適宜番号を追加してなる異なる識別子番号を当該同一販売者が運営している店舗毎に付与することにより販売者識別番号を作成し、販売者情報データベースがこの販売者識別番号と所定の販売者情報とを関連付けて蓄積するステップ、
   支払処理サーバが、代金引換決済システムから、取引案件の支払額を、取引情報毎に販売者識別番号がそれぞれ関連付けられた状態で受信し、識別親番号をキーとして販売者毎に連結するステップ、
   支払処理サーバが、クレジットカード会社管理システムから、取引案件の支払額を、取引情報毎に販売者識別番号がそれぞれ関連付けられた状態で受信し、識別親番号をキーとして販売者毎に連結するステップ、
   支払処理サーバが、上記２つのステップにて連結した支払額を、識別親番号をキーとして販売者毎に更に連結してとりまとめて支払明細書に表示するステップ、を包含する決済仲介方法。

Images