JP4439136B2 - 与信処理システム及び方法 - Google Patents

Description

【０００１】
【発明が属する技術分野】
本発明は、商品などのオンライン販売において必要とされる顧客に対する与信処理を行うための技術に関する。
【０００２】
【従来の技術】
インターネット上には商品等の販売を行っている店舗の様々なホームページが開設されている。このようなオンライン販売において商品等の代金の支払いは、例えば銀行振込や郵便振替、若しくは代金引換による支払いの他、クレジットカード支払いという場合もある。通常、クレジットカード支払いの場合には店舗のサーバと顧客の端末の通信はＳＳＬ（Secure Socket Layer）等により暗号化されるため他人に盗み見られることはないはずであるが、一般消費者はクレジットカード番号を商品等の注文毎に入力するのを好まない。かといって、いちいち銀行振込や郵便振替を行わなければならないのでは、手間がかかり且つ送金手数料を負担しなければならないという問題がある。特に代金引換払いの場合代引手数料は割高である。
【０００３】
そこで注文毎にクレジットカード番号をインターネット上で送信しなくともよいようにするための仕組みが用いられている。例えば、顧客が、郵送などで予めクレジットカード番号を決済業務を行う会社に登録しておき、当該決済業務を行う会社と提携している店舗のホームページで商品等を購入する場合には、店舗と決済業務を行う会社とを連携させ且つ決済業務を行う会社が顧客に対して顧客認証及び与信処理を行うことにより注文代金の決済処理を行う。
【０００４】
【発明が解決しようとする課題】
このように、決済業務を行う会社のコンピュータと店舗側のコンピュータとの連携及び決済業務を行う会社のコンピュータによる顧客認証及び与信処理は非常に重要である。
【０００５】
本発明の目的は、決済業務を行う会社のコンピュータ等において顧客認証及び与信処理等を行うための新規な技術を提供することである。
【０００６】
【課題を解決するための手段】
本発明の第１の態様に係るコンピュータ・システムは、顧客認証要求に係る、顧客の端末の情報（例えば顧客端末のアドレス）と店舗情報（例えば店舗識別情報又は店舗サーバのアドレス）と少なくとも当該顧客による注文の識別情報（例えば実施の形態における管理番号）とを、例えば顧客の端末又は店舗のコンピュータから受信した場合に、第１のキー（例えば実施の形態における動作キーＫＥＹ０１）を生成して当該第１のキーを顧客の端末に送信する認証確認手段と、顧客の端末から第１のキーを受信すると当該第１のキーの正当性確認処理（例えば、送信した第１のキーと同じかどうかの検査処理や第１のキーの有効期限を経過したかという検査処理）を実施し、顧客の端末から当該顧客の認証用情報（例えば、顧客ＩＤ及びパスワード）を受信すると顧客に対する認証処理を実施し、第１のキーの正当性確認処理結果及び顧客に対する認証処理結果が肯定的である場合に第２のキー（例えば実施の形態における動作キーＫＥＹ０２）を生成して、店舗のコンピュータ（例えば店舗サーバ）に当該第２のキー及び顧客による注文の識別情報を送信する顧客認証手段と、店舗のコンピュータから第２のキーと店舗の認証用情報（例えば店舗ＩＤ及びパスワード）と顧客による注文の内容情報とを受信した場合、第２のキーの正当性確認処理（例えば、送信した第２のキーと同じかどうかの検査処理や第２のキーの有効期限を経過したかという検査処理）と、店舗に対する認証処理と、予め登録されている顧客の情報を用いた顧客の与信処理とを実施し、第２のキーの正当性確認処理、店舗に対する認証処理及び顧客の与信処理の結果が肯定的である場合に顧客による注文の内容情報を登録する与信処理手段とを有する。
【０００７】
本発明に係るコンピュータ・システムが、顧客認証要求に係る、顧客の端末の情報と店舗情報と少なくとも当該顧客による注文の識別情報とを受信した場合に、例えば顧客の認証用情報の入力を促すメッセージなどと共に隠しパラメータとして第１のキーを顧客の端末に送信して、顧客に認証用情報の入力を求める。よって、顧客は注文の入力・送信から時間を空けずに当該注文の入力・送信と顧客認証とをひと括りの処理として進めることができるようになる。また、第１及び第２のキーを用いることにより処理フローの途中から割り込むようなことを防止できる。
【０００８】
さらに、本発明のコンピュータ・システムは、顧客認証処理に連続して、店舗のコンピュータから店舗の認証用情報等を受信して店舗の認証処理を済ませてから、与信処理を実施するような構成となっている。よって、顧客及び店舗が信頼できるものであることが確認できた上で与信処理を実施し、与信処理の結果が肯定的である場合に注文内容が受注として登録される。顧客認証処理と連続して与信処理を実施するため、顧客による注文キャンセルが減少することが期待できる。
【０００９】
なお、上で述べた与信処理手段を、店舗のコンピュータに、顧客による注文の内容情報の登録可否を示す情報と、顧客による注文の識別情報とを送信するような構成とすることも可能である。これにより店舗のコンピュータでも注文を受注確定に変更できるか判断できるようになる。
【００１０】
また、上で述べた与信処理手段を、第２のキーの正当性確認処理、店舗に対する認証処理及び顧客の与信処理の結果が肯定的である場合に与信処理手段における受付識別情報（例えば実施の形態における受付番号）を店舗のコンピュータに送信するような構成とすることも可能である。店舗のコンピュータでも本発明に係るコンピュータ・システム（与信処理手段）における受付識別情報を記憶しておくと、後に照会などに用いることができるようになる。
【００１１】
また上で述べた与信処理手段を、第２のキーの正当性確認処理、店舗に対する認証処理及び顧客の与信処理の結果が肯定的である場合に顧客による注文の内容情報の少なくとも一部を含む電子メールを顧客に対して送信するような構成も可能である。これにより、顧客も注文が完了したか否かを知ることができる。電子メールであるから、実際に商品などの配送が確認されるまで保管しておくのも簡単である。
【００１２】
さらに、上で述べた認証確認手段を、顧客による注文の内容情報をさらに受信し、当該顧客による注文の内容情報を仮登録するような構成とし、与信処理手段を、店舗のコンピュータから受信した顧客による注文の内容の情報を仮登録された情報と比較確認する処理を実施するような構成とすることも可能である。これにより、より信頼性が向上する。
【００１３】
本発明の第２の態様に係る与信処理方法は、顧客認証要求に係る、顧客の端末の情報と店舗情報と少なくとも当該顧客による注文の識別情報とを受信した場合に、第１のキーを生成して当該第１のキーを前記顧客の端末に送信するステップと、顧客の端末から第１のキーを受信すると当該第１のキーの正当性確認処理を実施し、顧客の端末から当該顧客の認証用情報を受信すると顧客に対する認証処理を実施し、第１のキーの正当性確認処理結果及び顧客に対する認証処理結果が肯定的である場合に第２のキーを生成して、店舗のコンピュータに当該第２のキー及び顧客による注文の識別情報を送信するステップと、店舗のコンピュータから第２のキーと店舗の認証用情報と顧客による注文の内容情報とを受信した場合、第２のキーの正当性確認処理と、店舗に対する認証処理と、予め登録されている顧客の情報を用いた顧客の与信処理とを実施し、第２のキーの正当性確認処理、店舗に対する認証処理及び顧客の与信処理の結果が肯定的である場合に顧客による注文の内容情報を登録するステップとを含む。
【００１４】
本発明の第１の態様に係る変形を、本発明の第２の態様に係る変形に適用することも可能である。
【００１５】
また、このような方法をコンピュータに実行させるプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。なお、中間的な処理結果はメモリに一時保管される。
【００１６】
【発明の実施の形態】
図１に本発明の一実施例におけるシステム概要を示す。例えばインターネットであるネットワーク１には、ウェブ（Ｗｅｂ）ブラウザを含む１又は複数の顧客端末３と、商品などのオンライン販売を行うＷｅｂサーバである店舗サーバ５と、本発明の一実施例に係る注文代金の決済処理を行う決済サーバ７とが接続されている。
【００１７】
店舗サーバ５は、例えば決済サーバ７の管理者から配布される決済サーバ用コマンドインターフェース（ＩＦ）プログラム５３と、店舗サーバ５における他の処理のための店舗側処理部５５とを含む。また、店舗サーバ５には、販売している商品などのデータベースや、顧客から受けた注文に関する情報を格納する注文情報データベース（ＤＢ）５１等が備えられ、店舗のスタッフが操作する店舗端末１１が接続されている。さらに、店舗サーバ５には例えば在庫管理システム１３や、その他商品などの出荷のための処理を行うサーバ（図示せず）が接続されている場合もある。これらの在庫管理システム１３や商品などの出荷のための処理を行うサーバの機能を店舗サーバ５自身が備えている場合もある。さらに、店舗サーバ５において、プログラムやコンテンツ・データをネットワーク１を介して顧客端末３にダウンロードさせることにより対価を得るというビジネスを行っている場合には、例えばプログラムやコンテンツ・データを格納したダウンロード用のサーバ１７をネットワーク１に接続し、店舗サーバ５と連携させるような場合もある。ダウンロード用サーバ１７の機能を店舗サーバ５が備えている場合もある。
【００１８】
ネットワーク１には例えば運送会社又は店舗サーバ５を運営する会社の物流部門の物流システム１５が接続されている。この物流システム１５は他のネットワークや専用線等により店舗サーバ５に接続されていることもある。その他ネットワーク１には多数のサーバ等が接続されている。
【００１９】
決済サーバ７は、本実施例では所定のインターネット・サービス・プロバイダ（ＩＳＰ：Internet Service Provider）の会員であって、クレジットカード情報を予め登録している顧客のために、当該顧客による商品などの購入代金の決済処理を行うものである。よって、決済サーバ７は、会員のＩＤ及びパスワードの情報、クレジットカードの情報を格納した会員情報データベース（ＤＢ）７１を参照できるようになっている。また、本実施例では予め所定の条件を満たしていると判断された店舗サーバ５に決済サーバ７の利用を許可するような構成となっている。よって、決済サーバ７は、各店舗又は各店舗サーバ５のＩＤ及びパスワードを含む店舗の情報を格納した店舗情報データベース（ＤＢ）７３を参照できるようになっている。本実施例ではクレジットカードによる決済を行うため、決済サーバ７は、クレジット・オンライン・システムであるＣＡＦＩＳ（Credit And Finance Information Switching system）９に接続しており、クレジットカード会社のコンピュータとの通信が行えるようになっている。決済サーバ７でも、例えばクレジットカード会社に対する処理が必要であるため、店舗サーバ５から注文情報を受け取り、当該注文情報を蓄積しておく必要がある。よって決済サーバ７は、注文情報等を登録する決済注文情報データベース（ＤＢ）７５を使用する。さらに、決済サーバ７はクレジット会社に対する請求を行うための情報を格納した請求ファイル７７も使用する。
【００２０】
図１に示したシステムにおける処理について簡単に説明しておく。顧客は顧客端末３を操作して店舗サーバ５にネットワーク１を介してアクセスし、購入する商品等を検索する。購入したい商品等が見つかると、顧客は顧客端末３から店舗サーバ５に商品等の注文を送信する。この時顧客は、決済には本実施例に係る決済システムを利用することを指示するものとする。店舗サーバ５は、顧客端末３から受信した注文情報を注文情報ＤＢ５１に登録し、当該注文情報、店舗サーバ５の情報（例えば店舗認証用情報又は店舗識別情報若しくは店舗サーバ５のアドレス等）及び顧客端末３のアドレス等を追加して決済サーバ７に転送する。決済サーバ７は、店舗サーバ５の情報を用いて店舗の確認／認証を行い、注文情報を仮登録する。決済サーバ７は、店舗サーバ５の情報及び注文情報に問題がなければ、動作キーＫＥＹ０１を生成して、顧客端末３に顧客（会員）のＩＤ及びパスワードを入力するように促す画面情報及び隠しパラメータとして動作キーＫＥＹ０１を送信する。
【００２１】
顧客端末３はＩＤ及びパスワードを入力するように促す画面を顧客に対し表示する。そして、顧客は顧客（会員）のＩＤ及びパスワードを入力し、顧客端末３はＩＤ及びパスワード並びに隠しパラメータの動作キーＫＥＹ０１を決済サーバ７に送信する。決済サーバ７においては、動作キーＫＥＹ０１が正当な動作キーであるか、ＩＤ及びパスワードの対が正しいか、受信した顧客（会員）ＩＤの顧客がＩＳＰにおける正常な会員であるか、本実施例に係る決済システムを使用する資格があるかを検査する。全ての検査が正常に終了すれば、決済サーバ７は、動作キーＫＥＹ０２を生成する。そして、決済サーバ７は、全ての検査が正常に終了していれば、隠しパラメータとして動作キーＫＥＹ０２と、検査結果と、注文情報に含まれる又は注文情報とは別途決済サーバ７に送られてきた、店舗サーバ５における当該注文の識別情報（以下、管理番号と呼ぶ。但し、番号だけでなく記号の場合もある。）とを店舗サーバ５に送信する。もし、いずれかの検査でエラーが生じた場合には、動作キーＫＥＹ０２は生成されず、店舗サーバ５には、いずれかの検査でエラーが生じたことが通知される。ＩＤ及びパスワードの対が正しくない場合には、顧客端末３にも通知される。例えば、ＩＤ及びパスワードの対の入力は２回まで再試行が許される。ここまでで顧客認証処理及びシステム利用資格確認処理が終了する。
【００２２】
店舗サーバ５は、検査結果が検査の成功を示していれば、受信した管理番号を用いて注文情報ＤＢ５１から注文情報を取り出し、当該注文情報と、管理番号と、動作キーＫＥＹ０２とを、店舗サーバ５で実行されている決済サーバ用コマンドインターフェース（ＩＦ）プログラム５３に出力する。決済サーバ用コマンドＩＦプログラム５３は、決済サーバ７と店舗サーバ５がやり取りするためのインターフェースを提供するプログラムであり、例えば決済サーバ７の管理者が店舗に提供するものである。もし、顧客ＩＤがＩＳＰにおける正常な会員であるか又は本実施例に係る決済システムを使用する資格があるかという検査でエラーを生じた場合には、店舗サーバ５から顧客端末３に対して、本実施例に係る決済システムが使えない旨の通知を行う。
【００２３】
注文情報と管理番号と動作キーＫＥＹ０２とを受け取った決済サーバ用コマンドＩＦプログラム５３は、店舗認証用情報と共にこれらの情報を決済サーバ７に送信する。決済サーバ７は、店舗に対する認証処理を実施し、仮登録された注文情報と今回受信した注文情報を照合し、受信した動作キーＫＥＹ０２の正当性を確認する。そして、これらの処理結果が肯定的である場合には与信処理を実施する。与信処理は、決済サーバ７に予め登録されている当該顧客のクレジットカード番号を用いてＣＡＦＩＳ９に対して与信照会を行う処理である。ＣＡＦＩＳ９から当該顧客のクレジットカードで決済可能な旨の情報を得ると、決済サーバ７は、注文情報を決済サーバ７内の決済注文情報データベース（ＤＢ）７５に登録し、決済サーバ７における注文情報の識別情報である受付番号（番号でなく記号を用いてもよい）を生成する。そして、注文情報が決済サーバ７の決済注文情報ＤＢ７５に登録された場合、顧客に対して、注文が登録されたことを通知するための注文登録通知メールを送信する。
【００２４】
決済サーバ７は、決済サーバ用コマンドＩＦプログラム５３に対して、注文情報の登録可否を示す情報、登録された場合には受付番号、及び管理番号を送信する。決済サーバ用コマンドＩＦプログラム５３は、受信した情報を店舗サーバ５の注文管理を行う処理部に出力する。そして、店舗サーバ５は顧客端末３に対して注文が決済システムに受け付けられたことを示す画面情報を送信する。顧客端末３は、注文が決済システムに受け付けられたことを示す画面を表示する。また、店舗サーバ５は受注を示す情報を注文情報ＤＢ５１に登録する。一方、店舗認証処理、動作キーＫＥＹ０２の正当性確認処理及び与信処理の処理結果のいずれかが否定的なものである場合には、店舗サーバ５は顧客端末３に対して注文が決済システムに受け付けられなかったことを示す画面情報を送信する。また、店舗認証処理以外の処理結果が否定的である場合には注文情報ＤＢ５１に受注不可が登録される。そして顧客端末３に受注できない旨の通知を送信する。ここまでで受注処理が終了する。
【００２５】
店舗サーバ５に接続された店舗端末１１を操作する店舗のスタッフは、例えば店舗サーバ５の注文情報ＤＢ５１の受注を示す情報が登録された注文を参照して、商品の出荷のための作業を行う。なお、注文情報が決済サーバ７のデータベースに登録された場合に、店舗サーバ５が当該注文情報を受注情報として注文情報ＤＢ５１から受注情報ＤＢに移動又はコピーし、当該受注情報ＤＢを参照するような構成も可能である。又、受注を示す情報を注文情報ＤＢ５１に登録した場合に、店舗サーバ５が物流システム１５に自動的に集荷依頼を出力するような構成も可能である。また、プログラムやコンテンツ・データのダウンロードを行わせる場合には、受注を示す情報を注文情報ＤＢ５１に登録した場合に、店舗サーバ５からダウンロード用サーバ１７にダウンロード許可を出力するような構成も可能である。さらに、他の商品出荷に関連するシステムが存在する場合には、注文情報ＤＢ５１に受注を示す情報が登録された後に店舗サーバ５から自動的に当該システムに処理依頼を出力するような構成も可能である。いずれにせよ注文を行った顧客に対して、商品などの出荷のための処理を行う。なお、出荷／配送の完了についても注文情報ＤＢ５１に登録しておく。
【００２６】
出荷／配送が完了し注文代金の請求を行う段階になると、例えば店舗端末１１を操作する店舗のスタッフは、注文情報ＤＢ５１を参照して、注文代金請求の対象となる注文の管理番号又は受付番号を抽出する。なお、物流システム１５と店舗サーバ５が連携している場合には、物流システム１５から配送完了通知を店舗サーバ５が受信する。この配送完了通知から管理番号又は受付番号を抽出する。さらに、ダウンロード用サーバ１７と店舗サーバ５が連携する場合には、ダウンロード用サーバ１７からダウンロード完了通知を店舗サーバ５が受信する。そして、ダウンロード完了通知から管理番号又は受付番号を抽出する。注文代金請求の対象となる注文の管理番号又は受付番号を注文代金請求依頼として、店舗サーバ５の決済サーバ用コマンドＩＦプログラム５３に出力すると、決済サーバ用コマンドＩＦプログラム５３は店舗の認証用情報と共に管理番号又は受付番号を決済サーバ７に送信する。
【００２７】
決済サーバ７は、店舗の認証用情報を用いて店舗に対する認証処理を行う。認証処理の結果が肯定的であれば、決済サーバ７に登録されている受付番号又は管理番号に対応する注文に売上確定を示す情報を登録し、注文代金請求処理を実施する。注文代金請求処理とは、当該顧客が登録しているクレジットカードのクレジットカード会社に対する代金請求のための情報に、当該注文代金の請求情報を追加するものである。この代金請求のための情報は、例えば月に一度クレジットカード会社に渡される。クレジットカード会社はこれらの情報を元に各顧客に対して代金請求を行う。注文代金請求処理が終了すれば、処理結果が決済サーバ用コマンドＩＦプログラム５３に送信され、決済サーバ用コマンドＩＦプログラム５３は処理結果を店舗サーバ５の売上確定処理部に出力する。店舗サーバ５では、注文代金請求処理の結果が肯定的である場合には、例えば注文情報ＤＢ５１内の管理番号又は受付番号に対応する注文について売上確定又は請求済みを登録する。一方、注文代金請求処理の結果が否定的である場合には、管理番号又は受付番号等が正しくない場合等であるから、それらの確認を行うように促す通知を店舗端末１１に出力する。以上で決済が終了する。
【００２８】
以下、本実施例におけるシステム動作の詳細を図２乃至図８を用いて説明する。
【００２９】
１．顧客認証処理及びシステム利用資格確認処理
［実施例１］
図２に実施例１に係る顧客認証処理及びシステム利用資格確認処理のフローを示す。例えば顧客は顧客端末３を操作して店舗サーバ５にアクセスする（ステップＳ１）。例えば店舗サーバ５は、商品情報及び注文フォームを顧客端末３に送信する（ステップＳ３）。ステップＳ１及びＳ３の処理には様々な形態があり、ここでは単純な場合のみを示している。顧客端末３はＷｅｂブラウザにて商品情報及び注文フォームを表示する。顧客は、Ｗｅｂブラウザに注文内容を入力し、注文フォームに含まれる送信ボタンを押し、注文情報を店舗サーバ５に送信する（ステップＳ５）。注文情報には、商品名、商品番号、数量、金額、住所、氏名、電話番号、電子メール・アドレスなどを含む。また、注文情報には本実施例に係る決済システムが決済方法として選択されたという情報を含むようにすることも可能である。さらに、本実施例に係る決済システムに関連するＩＳＰの顧客（会員）ＩＤを含むような場合もある。なお、店舗サーバ５及び顧客端末３は互いのアドレスを認識しているものとする。
【００３０】
店舗サーバ５は顧客端末３から注文情報を受信すると、注文情報のフォーマット等を確認の上、当該注文情報を注文情報ＤＢ５１に登録する（ステップＳ７）。なお、登録する前に、例えば在庫管理システム１３に在庫の問い合わせを行うようにすることも可能である。そして、店舗サーバ５は、受信した注文情報と店舗サーバ５内の顧客認証などの結果を受け取る処理部（例えばＣＧＩ（Common Gateway Interface））のアドレス情報（例えばＵＲＬ（Uniform Resource Locator））と店舗識別情報（例えば店子コード）と当該顧客の注文の識別情報（管理番号）とを含み、当該注文情報について決済のための認証手続きなどを行うように依頼する決済依頼の画面情報を顧客端末３に送信する（ステップＳ９）。ここで送信される画面情報において本実施例に係る決済システムを決済手段として選択するか尋ねるようにすることも可能である。顧客端末３は受信した画面情報をＷｅｂブラウザ内に表示し、顧客は、本実施例に係る決済システムを用いた決済のための認証手続きなどを行うことを了承する場合には「ＯＫ」ボタンを押す。そうすると、顧客端末３から決済依頼が店舗サーバ５に送信される（ステップＳ１１）。
【００３１】
店舗サーバ５は、決済依頼を受信すると、当該決済依頼を決済サーバ７に転送する（ステップＳ１３）。また、転送する際には、顧客端末３のアドレス情報を、決済依頼と共に決済サーバ７に転送する。なお、店舗識別情報とは別に又は店舗識別情報の代わりに店舗の認証用情報（例えば店舗のＩＤ及びパスワード）を併せて転送する場合もある。決済依頼を受信した決済サーバ７は、少なくとも店舗識別情報が実在するコードであるか等の店舗の確認を行う。もし店舗の認証用情報を受信した場合には、店舗のＩＤ及びパスワードの対が正しいか否かを検査する。これらにより店舗の確認が取れると、一旦受信した決済依頼に含まれる注文情報、店舗サーバ５のアドレス情報、店舗識別情報、及び管理番号等を、注文仮受付ファイル等に仮登録しておく。そして、決済サーバ７は動作キーＫＥＹ０１を生成し、顧客端末３に、当該動作キーＫＥＹ０１を隠しパラメータとして、これから決済サーバ７との通信において顧客認証を行うことを顧客に確認させるための認証確認画面情報を送信する（ステップＳ１５）。動作キーＫＥＹ０１を用いるのは、この処理ステップを必ず通過していることを後に確認できるようにするためである。
【００３２】
顧客端末３は認証確認画面をＷｅｂブラウザ内に表示し、顧客は認証確認画面に含まれる「ＯＫ」ボタンを押す。そうすると、顧客端末３から認証確認が隠しパラメータである動作キーＫＥＹ０１と共に決済サーバ７に送信される（ステップＳ１７）。決済サーバ７は、受信した動作キーＫＥＹ０１の正当性を確認する。正当性が確認された場合には、決済サーバ７は、顧客のＩＤ及びパスワードの入力を促す画面情報を顧客端末３に送信する（ステップＳ１９）。なお、動作キーＫＥＹ０１の正当性が確認されなかった場合には、このまま処理を続けると問題が生じ得るので、例えば店舗サーバ５及び顧客端末３にエラーが生じたことを通知する。
【００３３】
顧客端末３は、Ｗｅｂブラウザ内に顧客ＩＤ及びパスワードの入力を促す画面を表示する。少なくともこれ以下の通信においては、例えばＳＳＬ（Secure Socket Layer）技術を用いて通信の秘密を守る必要がある。これ以前の通信においてもＳＳＬを用いてもよい。顧客は、要求に応じて、顧客ＩＤ及びパスワードをＷｅｂブラウザ内に入力し、Ｗｅｂブラウザ内の画面に設けられた送信ボタンを押す。そうすると顧客端末３は入力された顧客ＩＤ及びパスワードを決済サーバ７に送信する（ステップＳ２１）。なお、ここでは顧客に対する認証処理のために、顧客ＩＤ及びパスワードを使用しているが、他の方法にて顧客認証を行う場合には、それに必要な情報を顧客端末３から決済サーバ７に送信する。このような形にて顧客ＩＤ及びパスワードを決済サーバ７に出力すれば、店舗サーバ５には顧客ＩＤとパスワードの対は送信されず、悪意ある又は悪意を持つようになった店舗に顧客ＩＤ及びパスワードを悪用されるのを防止することができる。
【００３４】
決済サーバ７は、顧客ＩＤ及びパスワードを受信すると、まず顧客ＩＤ及びパスワードの対が予め会員情報ＤＢ７１に登録されている顧客情報と同一か否か判断する。もし、同一でなければ、再度入力を行うようにステップＳ２１に戻る。例えば３回、顧客ＩＤ及びパスワードの確認を行っても同一であると判断できなかった場合には、決済サーバ７は顧客端末３に認証エラー画面情報を送信する。また、決済サーバ７は、店舗サーバ５に認証エラーを通知する場合もある。
【００３５】
もし、受信した顧客ＩＤ及びパスワードの対が予め登録されている顧客情報と同一である場合には、当該顧客の認証が完了することになる。但し、本実施例では顧客の認証だけでは本実施例に係る決済システムで決済できるわけではない。次に決済サーバ７は、システム利用資格の確認を行う。本実施例ではシステム利用資格の確認は２段階で行われる。まず、所定のＩＳＰにおける正常な会員であるか否かが確認される。すなわち、ＩＳＰの会員であっても、ＩＳＰの使用料金などの支払いが滞っている場合には正常な会員であるとは言えない。次に、本実施例に係る決済システムが使用できるということで登録されているかという点が確認される。本実施例ではクレジットカードにより決済されることを前提としているので、予めクレジットカード番号が登録されていなければならない。また、別途基準を設けて、当該基準を満たす者のみ本実施例に係る決済システムを使用できるように設定することも可能である。このような顧客認証処理及びシステム利用資格確認処理の結果が肯定的である場合には、決済サーバ７は動作キーＫＥＹ０２（セッションキーと呼ばれる場合もある）を生成する（ステップＳ２３）。また、動作キーＫＥＹ０２、注文情報、管理番号等をセッションファイルとして保管しておき、後の処理に使用するような構成も可能である。
【００３６】
そして、決済サーバ７は、顧客認証処理及びシステム利用資格確認処理の処理結果と、処理結果が肯定的である場合には動作キーＫＥＹ０２と、管理番号とを店舗サーバ５に送信する（ステップＳ２５）。店舗サーバ５は、決済サーバ７からそれらの情報を受信する（ステップＳ２７）。そして、システム利用資格確認処理にてエラーが存在する場合には、店舗サーバ５は、顧客端末３にシステム利用資格がないことを通知し、顧客端末３はシステム利用資格がない旨の表示を行う（ステップＳ２９）。また、注文情報ＤＢ５１内における当該管理番号の注文に対し決済できないことを登録する。
【００３７】
ここまでで与信処理の前段階である顧客認証及びシステム利用資格確認処理が終了する。なお、図２に示した処理フローは様々に変形可能である。例えば、ステップＳ１３において店舗サーバ５が決済依頼を転送する構成ではなく、顧客端末３から直接決済サーバ７に決済依頼を送信するような構成も可能である。この場合には店舗サーバ５は顧客端末３のアドレス情報を決済依頼に付加する必要がない。また、顧客端末３に送信される決済依頼の画面表示には、決済サーバ７のアドレスを埋め込んでおく。
【００３８】
また、上の説明ではシステム利用資格をも確認するような処理フローとなっているが、システム利用資格を別途規定しない場合もある。その場合には、本処理フローは顧客認証処理フローとなる。単純な顧客認証処理フローとする場合には、注文情報や注文情報の識別情報である管理番号等を決済サーバ７に送信しないような形態も可能である。
【００３９】
なお、動作キーＫＥＹ０１及びＫＥＹ０２については、有効期限を設けて有効期限内に決済サーバ７に戻ってこないようであれば、動作キーの確認処理でエラーとみなすようにすることも可能である。
【００４０】
［実施例２］
次に図３を用いて顧客認証処理及びシステム利用資格確認処理の第２の実施例を説明する。例えば顧客は顧客端末３を操作して店舗サーバ５にアクセスする（ステップＳ３１）。例えば店舗サーバ５は、商品情報及び注文フォームを顧客端末３に送信する（ステップＳ３３）。ステップＳ１及びＳ３の処理には様々な形態があり、ここでは単純な場合のみを示している。顧客端末３はＷｅｂブラウザにて商品情報及び注文フォームを表示する。顧客は、Ｗｅｂブラウザに注文内容を入力し、注文フォームに含まれる送信ボタンを押し、注文情報を店舗サーバ５に送信する（ステップＳ３５）。注文情報には、商品名、商品番号、数量、金額、住所、氏名、電話番号、電子メール・アドレスなどを含む。また、注文情報には本実施例に係る決済システムが決済方法として選択されたという情報を含むようにすることも可能である。さらに、本実施例に係る決済システムに関連するＩＳＰの顧客（会員）ＩＤを含むような場合もある。店舗サーバ５は顧客端末３から注文情報を受信すると、注文情報のフォーマット等を確認の上、当該注文情報を注文情報ＤＢ５１に登録する（ステップＳ３７）。なお、登録する前に、例えば在庫管理システム１３に在庫の問い合わせを行うようにすることも可能である。そして、店舗サーバ５は、受信した注文情報と店舗サーバ５内の顧客認証などの結果を受け取る処理部（例えばＣＧＩ）のアドレス情報（例えばＵＲＬ）と店舗識別情報（例えば店子コード）と注文の管理番号とを含み、当該注文情報について決済のための認証手続きなどを行うように依頼する決済依頼の画面情報を顧客端末３に送信する（ステップＳ３９）。ここで送信される画面情報において本実施例に係る決済システムを決済手段として選択するか尋ねるようにすることも可能である。顧客端末３は受信した画面情報をＷｅｂブラウザ内に表示し、顧客は、本実施例に係る決済システムを用いた決済のための認証手続きなどを行うことを了承する場合には「ＯＫ」ボタンを押す。そうすると、顧客端末３から決済依頼が店舗サーバ５に送信される（ステップＳ４１）。
【００４１】
店舗サーバ５は、決済依頼を受信すると、当該決済依頼を決済サーバ７に転送する（ステップＳ４３）。また、転送する際には、顧客端末３のアドレス情報を、決済依頼と共に決済サーバ７に転送する。なお、店舗識別情報とは別に又は店舗識別情報の代わりに店舗の認証用情報（例えば店舗のＩＤ及びパスワード）を併せて転送する場合もある。決済依頼を受信した決済サーバ７は、少なくとも店舗識別情報が実在するコードであるか等の店舗の確認を行う。もし店舗の認証用情報を受信した場合には、店舗のＩＤ及びパスワードの対が正しいか否かを検査する。これらにより店舗の確認が取れると、一旦受信した決済依頼に含まれる注文情報、店舗サーバ５のアドレス情報、店舗識別情報、及び管理番号等を、注文仮受付ファイル等に仮登録しておく。そして、決済サーバ７は、動作キーＫＥＹ０１を生成し、顧客端末３に、当該動作キーＫＥＹ０１を隠しパラメータとして、顧客のＩＤ及びパスワードの入力を促す画面情報を顧客端末３に送信する（ステップＳ４５）。動作キーＫＥＹ０１を用いるのは、この処理ステップを必ず通過していることを後に確認できるようにするためである。
【００４２】
顧客端末３は、Ｗｅｂブラウザ内に顧客ＩＤ及びパスワードの入力を促す画面を表示する。少なくともこれ以下の通信においては、例えばＳＳＬ（Secure Socket Layer）技術を用いて通信の秘密を守る必要がある。これ以前の通信においてもＳＳＬを用いてもよい。顧客は、要求に応じて、顧客ＩＤ及びパスワードをＷｅｂブラウザ内に入力し、Ｗｅｂブラウザ内の画面に設けられた送信ボタンを押す。そうすると顧客端末３は入力された顧客ＩＤ及びパスワードを決済サーバ７に送信する（ステップＳ４７）。このような形にて顧客ＩＤ及びパスワードを決済サーバ７に出力すれば、店舗サーバ５には顧客ＩＤとパスワードの対は送信されず、悪意ある又は悪意を持つようになった店舗に顧客ＩＤ及びパスワードを悪用されるのを防止することができる。又、顧客端末３は動作キーＫＥＹ０１を決済サーバ７に送信する。
【００４３】
決済サーバ７は、受信した動作キーＫＥＹ０１の正当性を確認する。もし、正当性が確認されなかった場合には、このまま処理を続けると問題を生じ得るので、例えば店舗サーバ５及び顧客端末３にエラーを生じたことを通知する。さらに、決済サーバ７は、受信した顧客ＩＤ及びパスワードの対が予め登録されている顧客情報と同一か否か判断する。もし、同一でなければ、再度入力を行うようにステップＳ４７に戻る。例えば３回、顧客ＩＤ及びパスワードの確認を行っても同一であると判断できなかった場合には、決済サーバ７は顧客端末３に認証エラー画面情報を送信する。また、決済サーバ７は、店舗サーバ５に認証エラーを通知する場合もある。
【００４４】
もし、受信した顧客ＩＤ及びパスワードの対が予め登録されている顧客情報と同一である場合には、当該顧客の認証が完了することになる。但し、本実施例では顧客の認証だけでは本実施例に係る決済システムで決済できるわけではない。次に決済サーバ７は、システム利用資格の確認を行う。本実施例でもシステム利用資格の確認は２段階で行われる。まず、所定のＩＳＰにおける正常な会員であるか否かが確認される。すなわち、ＩＳＰの会員であっても、ＩＳＰの使用料金などの支払いが滞っている場合には正常な会員であるとは言えない。次に、本実施例に係る決済システムが使用できるということで登録されているかという点が確認される。本実施例でもクレジットカードにより決済されることを前提としているので、予めクレジットカードが登録されていなければならない。また、別途基準を設けて、当該基準を満たす者のみ本実施例に係る決済システムを使用できるように設定することも可能である。このような顧客認証処理及びシステム利用資格確認処理の結果が肯定的である場合には、決済サーバ７は動作キーＫＥＹ０２（セッションキーとも呼ばれる）を生成する（ステップＳ４９）。動作キーＫＥＹ０２、注文情報、管理番号等をセッションファイルとして保管しておき、後の処理に使用するような構成も可能である。
【００４５】
そして、決済サーバ７は、顧客認証処理及びシステム利用資格確認処理の処理結果と、処理結果が肯定的である場合には動作キーＫＥＹ０２と、管理番号とを店舗サーバ５に送信する（ステップＳ５１）。店舗サーバ５は、決済サーバ７からそれらの情報を受信する（ステップＳ５３）。そして、システム利用資格確認処理にてエラーが存在する場合には、店舗サーバ５は、顧客端末３にシステム利用資格がないことを通知し、顧客端末３はその旨の表示を行う（ステップＳ５５）。また、注文情報ＤＢ５１内における当該管理番号の注文に対し決済できないことを登録する。
【００４６】
ここまでで与信処理の前段階である顧客認証及びシステム利用資格確認処理が終了する。なお、図３に示した処理フローは様々に変形可能である。例えば、ステップＳ４３において店舗サーバ５が決済依頼を転送する構成ではなく、顧客端末３から直接決済サーバ７に決済依頼を送信するような構成も可能である。この場合には店舗サーバ５は顧客端末３のアドレス情報を決済依頼に付加する必要がない。また、顧客端末３に送信される決済依頼の画面表示には、決済サーバ７のアドレスを埋め込んでおく。
【００４７】
また、実施例１でも述べたように、システム利用資格をも確認するような処理フローとなっているが、システム利用資格を別途規定しない場合もある。その場合には、本処理フローは顧客認証処理フローとなる。単純な顧客認証処理フローとする場合には、注文情報や注文情報の識別情報である管理番号等を決済サーバ７に送信しないような形態も可能である。
【００４８】
なお、動作キーＫＥＹ０１及びＫＥＹ０２については、有効期限を設けて有効期限内に決済サーバ７に戻ってこないようであれば、動作キーの確認処理でエラーとみなすようにすることも可能である。
【００４９】
２．与信処理
図４に、顧客認証処理及びシステム利用資格確認処理においてエラーが生じなかった顧客に対する与信処理のフローを示す。図１に関連して既に説明したが、店舗サーバ５には、店舗側が用意する店舗サーバ５の機能部分（以下店舗側処理部５５（例えばＣＧＩ）と呼ぶ。）と、決済サーバ７に対する処理を行う決済サーバ用コマンド・インターフェース（ＩＦ）プログラム５３とが設けられている。本実施例ではこれらを分けて説明することとする。
【００５０】
まず店舗サーバ５の店舗側処理部５５は、決済サーバ７から受信した管理番号（ステップＳ２７又はＳ５３）で注文情報ＤＢ５１を検索し、管理番号に係る注文情報を抽出する（ステップＳ６１）。例えばこの時点において店舗側処理部５５は在庫管理システム１３に対して、注文に係る商品の在庫確認を行うようにすることも可能である（ステップＳ６３）。在庫管理システム１３との連携が可能であれば本ステップを実施すればよいので、本ステップＳ６３は図４において点線囲みとしている。もし、ここで在庫切れであると判断された場合には、店舗側処理部５５は顧客端末３に在庫切れを通知し、顧客端末３は在庫切れ通知を表示する（ステップＳ６５）。
【００５１】
在庫管理システム１３と連携しない場合又は在庫の確認が取れた場合に、店舗側処理部５５は決済サーバ７から受信した動作キーＫＥＹ０２と管理番号と注文情報とを決済サーバ用コマンドＩＦプログラム５３に出力する（ステップＳ６７）。なお、別途顧客から得たクレジットカード有効期限の情報を併せて出力するような構成とすることも可能である。決済サーバ用コマンドＩＦプログラム５３は、店舗側処理部５５から受け取った情報に加え、店舗認証用情報を、決済サーバ７に送信する（ステップＳ６９）。
【００５２】
決済サーバ７は、受信した動作キーＫＥＹ０２の正当性を、例えば送信した動作キーＫＥＹ０２を格納したセッションファイルを用いて確認する。動作キーに有効期限が設けられている場合には、有効期限内に受信したか否かも検査する。また、セッションファイルに格納された注文情報及び管理番号と、今回受信した注文情報及び管理番号と比較することにより処理の連続性及びこれらの情報の正当性を確認する。これらの確認でエラーが検出されれば以降の処理は行われず、ステップＳ７７の処理に移行する。また、決済サーバ７は、受信した店舗認証用情報、すなわち店舗ＩＤとパスワードの対を用いて店舗認証処理を行う（ステップＳ７１）。店舗の認証が失敗した場合もステップＳ７７に移行する。店舗の認証が成功すると、顧客認証処理及びシステム利用資格確認処理において正当な顧客であると判断された顧客のクレジットカード番号を顧客情報を格納したデータベースから取り出し、ＣＡＦＩＳ９を用いて当該クレジットカードが適正なものであるか確認する与信処理を実施する（ステップＳ７３）。例えば、適正なクレジットカードであると確認できれば、ＣＡＦＩＳ９からは承認番号が得られる。ここで与信処理に失敗する、すなわちクレジットカードの与信限度額や有効期限などに問題がある場合には、ステップＳ７７に移行する。
【００５３】
もしステップＳ７３において与信処理に成功すると、受信した注文情報を決済サーバ７の決済注文情報ＤＢ７５に登録する。そして、決済サーバ７における当該注文情報の識別情報である受付番号（番号でなく記号である場合もある）を発行する（ステップＳ７５）。これにて、決済サーバ７において注文が受注として確定される。決済サーバ７においては、受付番号と管理番号と注文情報が対応付けられて決済注文情報ＤＢ７５に記憶される。
【００５４】
そして決済サーバ７は、ステップＳ７１及びＳ７３までの処理結果と、注文情報が登録できた場合には受付番号と、管理番号とを店舗サーバ５の決済サーバ用コマンドＩＦプログラム５３に送信する（ステップＳ７７）。決済サーバ用コマンドＩＦプログラム５３は、受信した情報を店舗側処理部５５に出力する（ステップＳ７９）。店舗側処理部５５では、受信した処理結果がステップＳ７１及びＳ７３までの処理が成功していることを示している場合には、注文情報ＤＢ５１に、受信した受付番号及び管理番号と、対応する注文情報とが対応付けられて登録される。受付番号が登録されれば、受注が確定したことになる。なお、別途受注確定を登録することも可能である。また、受注が確定した注文に関する情報（注文情報、受付番号及び管理番号）を別の受注情報データベース（ＤＢ）に移動又はコピーして、後の処理に利用するような構成も可能である。もし、受信した処理結果がいずれかの処理にて失敗したことを示している場合には、注文情報ＤＢ５１に受信した管理番号の注文について決済不可能を登録する。成功又は失敗のいずれの場合についても、店舗側処理部５５は顧客端末３に受信した処理結果のうち顧客に開示可能な部分を送信する（ステップＳ８１）。例えば「決済登録が完了しました。別途決済サーバから注文登録完了通知がメールにて送信されます」又は「クレジットカードの有効期限が切れていますので決済登録できませんでした」といった情報が送信される。顧客端末３は、受信した処理結果をＷｅｂブラウザ内に表示する（ステップＳ８３）。なお、店舗認証処理にてエラーが発生した場合には、再度店舗サーバ５が与信処理を決済サーバ７に依頼するようにしてもよい。
【００５５】
また、決済サーバ７は、顧客に対して、注文情報が決済サーバ７に登録されたことを通知するための注文登録通知メールを送信する（ステップＳ８５）。これに対して顧客端末３では、注文登録通知メールを受信する（ステップＳ９１）。注文登録通知メールは顧客に対する確認のために送信される。なお、顧客端末３におけるメールの受信は送信後直ぐでなくともよい。
【００５６】
また店舗サーバ５の店舗側処理部５５は、次に行わなければならない商品等の出荷のために、在庫管理システム１３に対して注文に係る商品の在庫確認を行うようにすることも可能である（ステップＳ８７）。在庫確認を行うか否かは任意である。もし、この段階にて在庫確認を行って、在庫切れが判明した場合には、店舗サーバ５の店舗側処理部５５は、例えば顧客に対して在庫切れのメールを送信し、後に説明する受注取消し処理を実施する。顧客端末３は、在庫切れのメールを受信する（ステップＳ８９）。また、店舗側処理部５５は注文情報ＤＢ５１に受注取消しを登録する。
【００５７】
在庫管理システム１３に対する在庫確認処理を行って在庫が存在した場合も在庫確認処理を行わない場合も、予め定められた出荷のための処理を他のシステムに依頼又は実行し、又は物流システム１５に対して集荷依頼を送信したり、又はダウンロード用サーバ１７に対してプログラムやコンテンツデータのダウンロードの顧客端末３に対する許可を出力する（ステップＳ９３）。なお、ステップＳ９３についても実行するか否かは店舗サーバ５を含む店舗システムの構成に依存する。よってステップＳ９３を全く実施しない場合もある。
【００５８】
このような処理を行うことにより与信処理及び受注確定処理が実施される。
【００５９】
３．受注取消し／返品処理
図５に、例えば上で述べたように在庫切れで受注を取り消す場合や、顧客から商品が返品された場合、又は顧客が注文を注文登録通知メール受信後に取り消した場合等に実施する処理について説明する。
【００６０】
店舗サーバ５の店舗側処理部５５は、まず受注取消し又は返品の対象となった注文の受付番号又は管理番号の特定を行う（ステップＳ１０１）。これは例えば店舗端末１１を店舗のスタッフが操作して、注文情報ＤＢ５１を検索することにより行われる。例えば、店舗のスタッフが、特定された受付番号又は管理番号を用いて取消し処理を実施するように店舗端末１１を用いて指示した場合には、当該指示を顧客端末３から受けた店舗側処理部５５は、取消依頼と受付番号又は管理番号とを決済サーバ用コマンドＩＦプログラム５３に出力する（ステップＳ１０３）。なお、取消しの理由などを併せて送るようにすることも可能である。
【００６１】
決済サーバ用コマンドＩＦプログラム５３は、店舗認証用情報と、受付番号又は管理番号とを、決済サーバ７の受注取消しを行う処理部に送信する（ステップＳ１０５）。同じく取消しの理由などを併せて送るようにすることも可能である。決済サーバ７は、受信した店舗認証用情報にて店舗に対する認証処理を実施する（ステップＳ１０７）。もし、認証処理においてエラーが発生するとステップＳ１１７に移行する。店舗認証が成功すると、次に与信取消処理を実施する（ステップＳ１０９）。与信取消処理は、例えばＣＡＦＩＳ９から承認番号を得ている場合には、当該承認番号についての取消し処理を例えばＣＡＦＩＳ９に対して行う。何らかの理由で与信取消処理に失敗する場合もある。この場合にはステップＳ１１７に移行する。
【００６２】
与信取消処理に成功した場合には、決済サーバ７の決済注文情報ＤＢ７５において登録されている、管理番号又は受付番号に対応する注文情報について与信取消を登録する（ステップＳ１１１）。これにて取消しに係る注文に対し後に請求処理を行わないようにすることができる。そして、与信取消が登録されたことを通知するための与信取消登録通知メールを与信取消しされた注文を行った顧客に対して送信する（ステップＳ１１３）。顧客は顧客端末３において当該与信取消登録通知メールを受信する（ステップＳ１１５）。これにより、顧客も決済サーバ７において注文が正式に取り消されたことを確認することができる。
【００６３】
その後決済サーバ７は、処理結果を店舗サーバ５の決済サーバ用コマンドＩＦプログラム５３に送信する（ステップＳ１１７）。決済サーバ用コマンドＩＦプログラム５３は処理結果を受信して、店舗側処理部５５に出力する（ステップＳ１１９）。店舗側処理部５５は、例えば処理結果を注文情報ＤＢ５１に登録する（ステップＳ１２１）。また、店舗端末１１に処理結果を通知するような構成も可能である。なお、与信取消に失敗している場合には、取消しができるまで与信取消処理を実施しなければならない。
【００６４】
４．検索処理
店舗サーバ５の注文情報ＤＢ５１に格納された注文情報と、決済サーバ７の決済注文情報ＤＢ７５に格納された注文情報の照合などのために、店舗サーバ５から決済サーバ７に注文情報の検索を依頼する場合がある。図６を用いて検索処理について説明する。検索処理には、受注状況一覧参照処理と、受注状況詳細参照処理とが含まれる。受注状況一覧参照処理においては、受付番号、管理番号、処理状態、顧客ＩＤ、期間の検索条件等を指定して、該当する注文情報を列挙するような出力を得ることができる。一方、受注状況詳細参照処理においては、受付番号又は管理番号を検索条件として入力すると、対応する注文情報の詳細を取得することができるようになる。
【００６５】
例えば、店舗端末１１を操作する店舗のスタッフが検索条件を決定して入力し、検索実行を店舗端末１１に命ずると、店舗端末１１は検索条件を含む検索命令を店舗サーバ５に送信する。検索命令を受信した店舗サーバ５の店舗側処理部５５は、検索依頼及び入力された検索条件を決済サーバ用コマンドＩＦプログラム５３に出力する（ステップＳ１３１）。決済サーバ用コマンドＩＦプログラム５３は、店舗認証用情報及び受け取った検索条件を、決済サーバ７の検索処理を行う処理部に送信する（ステップＳ１３３）。決済サーバ７は、受信した店舗認証用情報を用いて、店舗認証処理を実施する（ステップＳ１３５）。認証処理にてエラーが発生した場合にはステップＳ１３９に移行する。認証処理にて店舗が認証されると、決済サーバ７の決済注文情報ＤＢ７５に登録されている注文情報について、受信した検索条件にて検索を実施する。そして、検索条件に合致する注文情報を抽出する（ステップＳ１３７）。
【００６６】
決済サーバ７は、ステップＳ１３７において抽出した注文情報を店舗サーバ５の決済サーバ用コマンドＩＦプログラム５３に送信する（ステップＳ１３９）。なお、店舗認証に失敗した場合には失敗した旨の情報を抽出情報の代わりに送信する。決済サーバ用コマンドＩＦプログラム５３は、抽出された注文情報等を受信して、店舗側処理部５５に出力する（ステップＳ１４１）。店舗側処理部５５は、受信した注文情報等を店舗端末１１に出力する（ステップＳ１４３）。店舗端末１１は、受信した注文情報等を店舗のスタッフに対して表示する。
【００６７】
これにより、店舗サーバ５の注文情報ＤＢ５１だけでなく、決済システム７の決済注文情報ＤＢ７５に登録された注文情報にて注文情報及び処理状況等を確認できるようになる。
【００６８】
５．顧客確認処理
顧客認証処理及びシステム利用資格確認処理とは別に、本実施例に係る決済システムのシステム利用資格のみ、又はＩＳＰの会員資格のみを、例えば注文を受ける前に確認したり、本実施例に係る決済システムのシステム利用資格等を有している者のみに特別のサービスなどを提供するなどの場合に、顧客確認を簡単に行えると便利である。図７は、顧客確認のための処理フローを示す。
【００６９】
まず、店舗サーバ５の店舗側処理部５５は、何らかの処理の後に、顧客ＩＤを入力するように促す画面情報を顧客端末３に出力する（ステップＳ１５１）。顧客端末３は、受信した画面情報をＷｅｂブラウザ内に表示して、顧客ＩＤ入力の要求に応じて、顧客は顧客ＩＤを入力して、Ｗｅｂブラウザ内の「送信」ボタンを押す。そうすると、顧客端末３は店舗サーバ５に顧客ＩＤを送信する（ステップＳ１５３）。
【００７０】
店舗サーバ５の店舗側処理部５５は、顧客端末３から顧客ＩＤを受信すると、当該顧客ＩＤを決済サーバ用コマンドＩＦプログラム５３に出力する（ステップＳ１５５）。決済サーバ用コマンドＩＦプログラム５３は、決済サーバ７の顧客確認処理部に店舗認証用情報と受信した顧客ＩＤを送信する（ステップＳ１５７）。決済サーバ７は、受信した店舗認証用情報を用いて店舗認証処理を実施する（ステップＳ１５９）。店舗認証が失敗すればステップＳ１６３に移行する。店舗認証が成功すれば、決済サーバ７は顧客ＩＤを用いて顧客確認処理を実施する（ステップＳ１６１）。ここで顧客確認処理は、上で説明したのと同じように、所定のＩＳＰの正常な会員であるか、加えて本実施例に係る決済システムを使用できるかを確認する。なお、所定のＩＳＰの正常な会員であるかのみを確認するような構成とすることも可能である。
【００７１】
いずれにしても、決済サーバ７は、顧客確認処理の処理結果を決済サーバ用コマンドＩＦプログラム５３に送信する（ステップＳ１６３）。店舗認証処理でエラーが発生した場合には、店舗認証処理でエラーが生じたという結果を決済サーバ用コマンドＩＦプログラム５３に送信する。決済サーバ用コマンドＩＦプログラム５３は処理結果を受信し、店舗側処理部５５に出力する（ステップＳ１６５）。店舗側処理部５５では受信した処理結果を参照して、次の所定の処理を実施する。例えば、顧客確認できた場合には、顧客端末３に、注文情報の入力を行うよう促したり、特別な商品の提示を行うための画面情報を出力する（ステップＳ１６７）。また、顧客確認できなかった場合には、もう一度顧客ＩＤを入力しなおすように促したり、注文は受けられない旨の表示を含む画面情報を顧客端末３に送信する。また、店舗認証で失敗している場合には、再度顧客確認処理を実施するように決済用コマンドＩＦプログラム５３に命令する場合もある。
【００７２】
以上のようにして、顧客認証処理及びシステム利用資格確認処理とは別に顧客確認を決済サーバ７に行わせることができる。
【００７３】
６．売上確定処理
顧客の注文に対応して、例えば商品の配送又はサービスの提供を行い、又はプログラムやコンテンツ・データのダウンロードを行わせた後には、売上を確定するための処理を実施しなければならない。図８に売上確定処理のフローを示す。
【００７４】
まず、店舗サーバ５の店舗側処理部５５は、例えば物流システム１５から配送完了通知を受けた場合、例えば店舗端末１１から配送完了入力がなされた場合、例えばダウンロード用サーバ１７からのダウンロード完了通知を受けた場合、それらの通知又は入力から、売上確定の対象となる受付番号又は管理番号を特定する。例えば、注文情報ＤＢ５１に配送に関する情報、例えば配送依頼番号等が入力されていれば、配送完了通知に含まれる配送依頼番号で注文が特定できるため、管理番号又は受付番号を注文情報ＤＢ５１から抽出できる。また、配送完了通知等に必ず受付番号又は管理番号を含めるようにすることも可能である。いずれにせよ、売上確定の対象となる注文の受付番号又は管理番号は、店舗側処理部５５から決済サーバ用コマンドＩＦプログラム５３に出力される（ステップＳ１７１）。
【００７５】
決済サーバ用コマンドＩＦプログラム５３は、店舗認証用情報及び受付番号又は管理番号を決済サーバ７の売上確定処理部に送信する（ステップＳ１７３）。決済サーバ７は、店舗認証用情報を用いて店舗認証処理を実施する（ステップＳ１７４）。店舗認証用情報は、例えば店舗ＩＤ及びパスワードであって、決済サーバ７は、予め店舗情報ＤＢ７３に登録されている店舗情報の店舗ＩＤ及びパスワードと同一か否かを判定する。店舗認証に失敗した場合にはステップＳ１７９に移行する。一方、店舗認証に成功した場合には、決済サーバ７は受信した受付番号又は管理番号から決済サーバ７における注文情報を特定し、その注文情報に対して売上確定を登録する（ステップＳ１７５）。なお、管理番号又は受付番号が誤って入力される場合もあるので、決済サーバ７において注文情報を特定できない場合もある。この場合には、ステップＳ１７９に移行する。
【００７６】
次に、決済サーバ７は注文代金請求処理を実施する（ステップＳ１７７）。注文代金請求処理は、例えば注文情報をその注文の決済を行うクレジットカード会社に対する請求ファイル７７に書き込む処理である。例えば請求ファイル７７は月に一度クレジットカード会社に送られる。クレジットカード会社は顧客に代金の請求を行う。また、決済サーバ７は、決済注文情報ＤＢ７５の当該注文に対して請求済みを示す情報を登録する。
【００７７】
ここまで実施すると、決済サーバ７はステップＳ１７４乃至Ｓ１７７の処理結果を決済サーバ用コマンドＩＦプログラム５３に送信する（ステップＳ１７９）。決済サーバ用コマンドＩＦプログラム５３は、処理結果を決済サーバ７から受信して、店舗側処理部５５に出力する（ステップＳ１８１）。店舗側処理部５５は、処理結果が成功を示している場合には、請求済み又は売上確定を注文情報ＤＢ５１内の送信した管理情報又は受付情報の注文情報に対して登録する（ステップＳ１８３）。もし、処理結果が失敗を示している場合には、例えば店舗端末１１に処理結果を出力し、受付番号又は管理番号の確認を求めたり、自動的に再試行を行うようにすることができる。
【００７８】
これにて売上確定処理が終了する。売上確定がなされた注文の代金は、クレジットカード会社から店舗に支払われ、クレジットカード会社は顧客に対して請求を行って、顧客から代金を受け取る。
【００７９】
以上本発明の一実施例を説明した。上では顧客がＩＳＰの会員であることを前提として説明したが、他の集団の会員であることを条件とすることも可能である。
【００８０】
また、本実施例では店舗サーバ５に店舗側処理部５５と決済サーバ用コマンドＩＦプログラム５３を設けるような構成としているが、このような機能の分割を行うか否かは任意である。決済サーバ用コマンドＩＦプログラム５３についても、複数の機能モジュールに分けることも可能である。
【００８１】
さらに店舗サーバ５の店舗側処理部５５、及び決済サーバ７については、上で述べた１乃至６の処理毎に別個の処理部（例えばＣＧＩ）を設けることも可能であるし、また同一の処理部（例えばＣＧＩ）が処理を行うような構成とすることも可能である。上で述べた１乃至６の各処理内において複数の処理部を設けて処理させることも可能である。
【００８２】
更に加えて店舗サーバ５は物理的に一台のコンピュータにて実装される場合もあるし、複数台のコンピュータにて実装される場合もある、決済サーバ７についても同様である
【００８３】
【発明の効果】
本発明により、決済業務を行う会社のコンピュータ等において顧客認証及び与信処理等を行うための新規な技術を提供することができた。
【図面の簡単な説明】
【図１】本発明におけるシステム全体の概要を示すブロック図である。
【図２】実施例１に係る顧客認証処理及びシステム利用資格確認処理のフローチャートである。
【図３】実施例２に係る顧客認証処理及びシステム利用資格確認処理のフローチャートである。
【図４】与信処理のフローチャートである。
【図５】受注取消し／返品処理のフローチャートである。
【図６】検索処理のフローチャートである。
【図７】顧客確認処理のフローチャートである。
【図８】売上確定処理のフローチャートである。
【符号の説明】
１ ネットワーク ３ 顧客端末 ５ 店舗サーバ
７ 決済サーバ ９ ＣＡＦＩＳ １１ 店舗端末
１３ 在庫管理システム １５ 物流システム
１７ ダウンロード用サーバ

Claims (7)

1. 顧客の端末及び店舗のコンピュータとの間での通信を行うコンピュータ・システムであって、
   前記店舗のコンピュータ又は前記顧客の端末から、前記店舗のコンピュータにアクセスした顧客に対する認証処理を依頼するための顧客認証要求に係る、顧客の端末のアドレスと当該店舗の識別情報と少なくとも当該顧客による注文の識別情報とを受信した場合に、前記店舗の識別情報に基づく当該店舗に対する認証処理又は前記店舗の識別情報が予め登録されたものであるかを確認する処理である当該店舗の確認処理を実施する認証要求受信手段と、
   前記店舗に対する認証処理又は前記店舗の確認処理の結果が肯定的である場合に、前記店舗に対する認証処理又は前記店舗の確認処理が正常に完了した場合に発行され、前記顧客認証要求に係る顧客の端末からの応答であることを確かめるための第１のキーを生成して当該第１のキーを前記顧客の端末に送信する認証確認手段と、
   前記顧客の端末から前記第１のキーを受信すると前記第１のキーの正当性確認処理を実施し、前記顧客の端末から当該顧客の認証用情報を受信すると前記顧客に対する認証処理を実施し、前記第１のキーの正当性確認処理結果及び前記顧客に対する認証処理結果が肯定的である場合には、前記顧客認証要求に係る前記顧客に対する認証処理が正常に完了した場合に発行される第２のキーを生成して、前記店舗のコンピュータに当該第２のキー及び前記顧客による注文の識別情報を送信する顧客認証手段と、
   前記店舗のコンピュータから前記第２のキーと前記店舗の認証用情報と前記顧客による注文の内容情報とを受信した場合、前記第２のキーの正当性確認処理と、前記店舗に対する認証処理と、予め登録されている前記顧客の情報を用いた前記顧客の与信処理とを実施し、前記第２のキーの正当性確認処理、前記店舗に対する認証処理及び前記顧客の与信処理の結果が肯定的である場合に前記顧客による注文の内容情報を記憶装置に登録する与信処理手段と
   を有し、
   前記第１のキーの正当性確認処理が、前記顧客の端末から受信した第１のキーが前記認証確認手段によって生成された第１のキーと同一であることを確認する処理を含み、
   前記第２のキーの正当性確認処理が、前記店舗のコンピュータから受信した第２のキーが前記顧客認証手段によって生成された第２のキーと同一であることを確認する処理を含む
   コンピュータ・システム。
2. 前記与信処理手段は、前記店舗のコンピュータに、前記顧客による注文の内容情報の登録可否を示す情報と、前記顧客による注文の識別情報とを送信することを特徴とする請求項１記載のコンピュータ・システム。
3. 前記与信処理手段が、前記第２のキーの正当性確認処理、前記店舗に対する認証処理及び前記顧客の与信処理の結果が肯定的である場合に前記与信処理手段における受付識別情報を前記店舗のコンピュータに送信することを特徴とする請求項１又は２記載のコンピュータ・システム。
4. 前記与信処理手段は、前記第２のキーの正当性確認処理、前記店舗に対する認証処理及び前記顧客の与信処理の結果が肯定的である場合に前記顧客による注文の内容情報の少なくとも一部を含む電子メールを前記顧客に対して送信することを特徴とする請求項１乃至３のいずれか１つに記載のコンピュータ・システム。
5. 前記認証要求受信手段が、前記顧客による注文の内容情報をさらに受信し、当該顧客による注文の内容情報を仮登録し、
   前記与信処理手段が、前記店舗のコンピュータから受信した前記顧客による注文の内容の情報を仮登録された情報と比較確認する処理を実施する
   ことを特徴とする請求項１記載のコンピュータ・システム。
6. 顧客の端末及び店舗のコンピュータと通信を行うコンピュータによって実行される与信処理方法であって、
   前記店舗のコンピュータ又は前記顧客の端末から、前記店舗のコンピュータにアクセスした顧客に対する認証処理を依頼するための顧客認証要求に係る、顧客の端末のアドレスと当該店舗の識別情報と少なくとも当該顧客による注文の識別情報とを受信した場合に、前記店舗の識別情報に基づく当該店舗に対する認証処理又は前記店舗の識別情報が予め登録されたものであるかを確認する処理である当該店舗の確認処理を実施する認証要求受信ステップと、
   前記店舗に対する認証処理又は前記店舗の確認処理の結果が肯定的である場合に、前記店舗に対する認証処理又は前記店舗の確認処理が正常に完了した場合に発行され、前記顧客認証要求に係る顧客の端末からの応答であることを確かめるための第１のキーを生成して当該第１のキーを前記顧客の端末に送信する認証確認ステップと、
   前記顧客の端末から前記第１のキーを受信すると前記第１のキーの正当性確認処理を実施し、前記顧客の端末から当該顧客の認証用情報を受信すると前記顧客に対する認証処理を実施し、前記第１のキーの正当性確認処理結果及び前記顧客に対する認証処理結果が肯定的である場合には、前記顧客認証要求に係る前記顧客に対する認証処理が正常に完了した場合に発行される第２のキーを生成して、前記店舗のコンピュータに当該第２のキー及び前記顧客による注文の識別情報を送信する顧客認証ステップと、
   前記店舗のコンピュータから前記第２のキーと前記店舗の認証用情報と前記顧客による注文の内容情報とを受信した場合、前記第２のキーの正当性確認処理と、前記店舗に対する認証処理と、予め登録されている前記顧客の情報を用いた前記顧客の与信処理とを実施し、前記第２のキーの正当性確認処理、前記店舗に対する認証処理及び前記顧客の与信処理の結果が肯定的である場合に前記顧客による注文の内容情報を記憶装置に登録する与信処理ステップと
   を含み、
   前記第１のキーの正当性確認処理が、前記顧客の端末から受信した第１のキーが前記認証確認ステップによって生成された第１のキーと同一であることを確認する処理を含み、
   前記第２のキーの正当性確認処理が、前記店舗のコンピュータから受信した第２のキーが前記顧客認証ステップによって生成された第２のキーと同一であることを確認する処理を含む
   を含む与信処理方法。
7. 顧客の端末及び店舗のコンピュータと通信を行うコンピュータに命令を実行させるためのプログラムであって、
   前記店舗のコンピュータ又は前記顧客の端末から、前記店舗のコンピュータにアクセスした顧客に対する認証処理を依頼するための顧客認証要求に係る、顧客の端末のアドレスと当該店舗の識別情報と少なくとも当該顧客による注文の識別情報とを受信した場合に、前記店舗の識別情報に基づく当該店舗に対する認証処理又は前記店舗の識別情報が予め登録されたものであるかを確認する処理である当該店舗の確認処理を実施する認証要求受信ステップと、
   前記店舗に対する認証処理又は前記店舗の確認処理の結果が肯定的である場合に、前記店舗に対する認証処理又は前記店舗の確認処理が正常に完了した場合に発行され、前記顧客認証要求に係る顧客の端末からの応答であることを確かめるための第１のキーを生成して当該第１のキーを前記顧客の端末に送信する認証確認ステップと、
   前記顧客の端末から前記第１のキーを受信すると前記第１のキーの正当性確認処理を実施し、前記顧客の端末から当該顧客の認証用情報を受信すると前記顧客に対する認証処理を実施し、前記第１のキーの正当性確認処理結果及び前記顧客に対する認証処理結果が肯定的である場合には、前記顧客認証要求に係る前記顧客に対する認証処理が正常に完了した場合に発行される第２のキーを生成して、前記店舗のコンピュータに当該第２のキー及び前記顧客による注文の識別情報を送信する顧客認証ステップと、
   前記店舗のコンピュータから前記第２のキーと前記店舗の認証用情報と前記顧客による注文の内容情報とを受信した場合、前記第２のキーの正当性確認処理と、前記店舗に対する認証処理と、予め登録されている前記顧客の情報を用いた前記顧客の与信処理とを実施し、前記第２のキーの正当性確認処理、前記店舗に対する認証処理及び前記顧客の与信処理の結果が肯定的である場合に前記顧客による注文の内容情報を記憶装置に登録する与信処理ステップと
   をコンピュータに実行させ、
   前記第１のキーの正当性確認処理が、前記顧客の端末から受信した第１のキーが前記認証確認ステップによって生成された第１のキーと同一であることを確認する処理を含み、
   前記第２のキーの正当性確認処理が、前記店舗のコンピュータから受信した第２のキーが前記顧客認証ステップによって生成された第２のキーと同一であることを確認する処理を含む
   プログラム。

Images