JP2002042003A - 注文代金請求処理システム及び方法 - Google Patents

Abstract

(57)【要約】 【課題】商品等のオンライン販売において必要とされる
決済処理を行うコンピュータにおいて顧客認証から注文
代金請求までを実施する。 【解決手段】顧客認証要求を店舗コンピュータから受信
すると第１キーを生成して顧客端末に送信する。顧客端
末から第１キー及び当該顧客の認証用情報を受信すると
キーの正当性確認及び認証処理を実施し、両方の処理結
果が肯定的である場合に第２キーを生成して、店舗コン
ピュータに注文識別番号と共に送信する。店舗コンピュ
ータから第２キーと店舗の認証用情報と注文の内容とを
受信した場合、キーの正当性確認と店舗の認証処理と顧
客の与信処理とを実施し、上記３つの処理の結果が肯定
的であれば注文の内容を登録し、店舗コンピュータに注
文の登録を示す情報等を送信する。その後店舗コンピュ
ータから注文代金請求依頼を受信した場合には、当該注
文に対して売上確定を登録し且つ注文代金請求処理を実
施する。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、商品などのオンラ
イン販売において必要とされる顧客認証から注文代金請
求までを実施するための技術に関する。

【０００２】

【従来の技術】インターネット上には商品等の販売を行
っている店舗の様々なホームページが開設されている。
このようなオンライン販売において商品等の代金の支払
いは、例えば銀行振込や郵便振替、若しくは代金引換に
よる支払いの他、クレジットカード支払いという場合も
ある。通常、クレジットカード支払いの場合には店舗の
サーバと顧客の端末の通信はＳＳＬ（Secure Socket La
yer）等により暗号化されるため他人に盗み見られるこ
とはないはずであるが、一般消費者はクレジットカード
番号を商品等の注文毎に入力するのを好まない。かとい
って、いちいち銀行振込や郵便振替を行わなければなら
ないのでは、手間がかかり且つ送金手数料を負担しなけ
ればならないという問題がある。特に代金引換払いの場
合代引手数料は割高である。

【０００３】そこで注文毎にクレジットカード番号をイ
ンターネット上で送信しなくともよいようにするための
仕組みが用いられている。例えば、顧客が、郵送などで
予めクレジットカード番号を決済業務を行う会社に登録
しておき、当該決済業務を行う会社と提携している店舗
のホームページで商品等を購入する場合には、店舗と決
済業務を行う会社とを連携させ且つ決済業務を行う会社
が顧客に対して顧客認証及び与信処理を行うことにより
注文代金の決済処理を行う。

【０００４】

【発明が解決しようとする課題】このように、決済業務
を行う会社のコンピュータと店舗側のコンピュータとの
連携及び決済業務を行う会社のサーバによる処理は非常
に重要である。

【０００５】本発明の目的は、決済業務を行う会社のコ
ンピュータ等において顧客認証から注文代金請求処理等
を行うための新規な技術を提供することである。

【０００６】

【課題を解決するための手段】本発明の第１の態様に係
るコンピュータ・システムは、顧客認証要求に係る、顧
客の端末の情報（例えば顧客端末のアドレス）と店舗情
報（例えば店舗識別情報又は店舗サーバのアドレス）と
少なくとも当該顧客による注文の識別情報（例えば実施
の形態における管理番号）とを、例えば顧客の端末又は
店舗のコンピュータから受信した場合に、第１のキー
（例えば実施の形態における動作キーＫＥＹ０１）を生
成して当該第１のキーを顧客の端末に送信する認証確認
手段と、顧客の端末から第１のキーを受信すると当該第
１のキーの正当性確認処理（例えば、送信した第１のキ
ーと同じかどうかの検査処理や第１のキーの有効期限を
経過したかという検査処理）を実施し、顧客の端末から
当該顧客の認証用情報（例えば、顧客ＩＤ及びパスワー
ド）を受信すると顧客に対する認証処理を実施し、第１
のキーの正当性確認処理結果及び顧客に対する認証処理
結果が肯定的である場合に第２のキー（例えば実施の形
態における動作キーＫＥＹ０２）を生成して、店舗のコ
ンピュータ（例えば店舗サーバ）に当該第２のキー及び
顧客による注文の識別情報を送信する顧客認証手段と、
店舗のコンピュータから第２のキーと店舗の認証用情報
（例えば店舗ＩＤ及びパスワード）と顧客による注文の
内容情報とを受信した場合、第２のキーの正当性確認処
理（例えば、送信した第２のキーと同じかどうかの検査
処理や第２のキーの有効期限を経過したかという検査処
理）と、店舗に対する認証処理と、予め登録されている
顧客の情報を用いた顧客の与信処理とを実施し、第２の
キーの正当性確認処理、店舗に対する認証処理及び顧客
の与信処理の結果が肯定的である場合に顧客による注文
の内容情報を登録し、上の処理が肯定的であっても否定
的であっても店舗のコンピュータに顧客による注文の内
容情報の登録可否を示す情報及び顧客による注文の識別
情報（例えば実施の形態における管理番号）とを送信す
る与信処理手段と、店舗のコンピュータから注文代金請
求依頼に係る顧客による注文の識別情報を受信した場合
に、顧客による注文の識別情報の正当性を確認し、正当
性が確認された場合には当該顧客による注文に対して売
上確定を記憶装置に登録し且つ注文代金請求処理を実施
する請求処理手段とを有する。

【０００７】本発明の第２の態様に係るコンピュータ・
システムは、顧客認証要求に係る、顧客の端末の情報と
店舗情報と少なくとも当該顧客による注文の識別情報と
を受信した場合に、第１のキーを生成して当該第１のキ
ーを前記顧客の端末に送信する認証確認手段と、顧客の
端末から第１のキーを受信すると当該第１のキーの正当
性確認処理を実施し、顧客の端末から当該顧客の認証用
情報を受信すると顧客に対する認証処理を実施し、第１
のキーの正当性確認処理結果及び顧客に対する認証処理
結果が肯定的である場合に第２のキーを生成して、店舗
のコンピュータに当該第２のキー及び顧客による注文の
識別情報を送信する顧客認証手段と、店舗のコンピュー
タから第２のキーと店舗の認証用情報と顧客による注文
の内容情報とを受信した場合、第２のキーの正当性確認
処理と、店舗に対する認証処理と、予め登録されている
顧客の情報を用いた顧客の与信処理とを実施し、第２の
キーの正当性確認処理、店舗に対する認証処理及び顧客
の与信処理の結果が肯定的である場合に顧客による注文
の内容情報を記憶装置に登録し、店舗のコンピュータに
顧客による注文の内容情報に対する登録識別情報（例え
ば実施の形態における受付番号）を送信する与信処理手
段と、店舗のコンピュータから注文代金請求依頼に係る
登録識別情報を受信した場合に、登録識別情報の正当性
を確認し、正当性が確認された場合には当該顧客による
注文に対して売上確定を記憶装置に登録し且つ注文代金
請求処理を実施する請求処理手段とを有する。

【０００８】本発明に係るコンピュータ・システムが、
顧客認証要求に係る、顧客の端末の情報と店舗情報と少
なくとも当該顧客による注文の識別情報とを受信した場
合に、例えば顧客の認証用情報の入力を促すメッセージ
などと共に隠しパラメータとして第１のキーを顧客の端
末に送信して、顧客に認証用情報の入力を求める。よっ
て、顧客は注文の入力・送信から時間を空けずに当該注
文の入力・送信と顧客認証とをひと括りの処理として進
めることができるようになる。また、第１及び第２のキ
ーを用いることにより処理フローの途中から割り込むよ
うなことを防止できる。

【０００９】さらに、本発明のコンピュータ・システム
は、顧客認証処理に連続して、店舗のコンピュータから
店舗の認証用情報等を受信して店舗の認証処理を済ませ
てから、与信処理を実施するような構成となっている。
よって、顧客及び店舗が信頼できるものであることが確
認できた上で与信処理を実施し、与信処理の結果が肯定
的である場合に注文内容が受注として登録される。本発
明のコンピュータ・システムは、与信処理の結果を店舗
のコンピュータにも通知するので、店舗のコンピュータ
でも与信処理の結果により、受注を登録したり、処理結
果を顧客に通知したりすることができるようになる。

【００１０】本発明の第１又は第２の態様における請求
処理手段を、注文代金請求依頼に係る店舗の認証用情報
を受信して、店舗に対する認証処理を行うような構成と
することも可能である。これにより注文代金請求時に
も、店舗の認証ができるようになる。

【００１１】さらに、上で述べた請求処理手段を、店舗
のコンピュータに、顧客による注文の識別情報又は登録
識別情報の正当性が確認されない場合、注文代金請求に
失敗した旨の通知を送信し、注文代金請求処理に成功し
た場合には、注文代金請求に成功した旨の通知を送信す
るような構成も可能である。

【００１２】本発明の第３の態様における注文代金請求
処理方法は、顧客認証要求に係る、顧客の端末の情報と
店舗情報と少なくとも当該顧客による注文の識別情報と
を受信した場合に、第１のキーを生成して当該第１のキ
ーを前記顧客の端末に送信するステップと、顧客の端末
から第１のキーを受信すると当該第１のキーの正当性確
認処理を実施し、顧客の端末から当該顧客の認証用情報
を受信すると顧客に対する認証処理を実施し、第１のキ
ーの正当性確認処理結果及び顧客に対する認証処理結果
が肯定的である場合に第２のキーを生成して、店舗のコ
ンピュータに当該第２のキー及び顧客による注文の識別
情報を送信するステップと、店舗のコンピュータから第
２のキーと店舗の認証用情報と顧客による注文の内容情
報とを受信した場合、第２のキーの正当性確認処理と、
店舗に対する認証処理と、予め登録されている顧客の情
報を用いた顧客の与信処理とを実施し、第２のキーの正
当性確認処理、店舗に対する認証処理及び顧客の与信処
理の結果が肯定的である場合に顧客による注文の内容情
報を記憶装置に登録し、店舗のコンピュータに顧客によ
る注文の内容情報の登録可否を示す情報及び顧客による
注文の識別情報とを送信するステップと、店舗のコンピ
ュータから注文代金請求依頼に係る顧客による注文の識
別情報を受信した場合に、顧客による注文の識別情報の
正当性を確認し、正当性が確認された場合には当該顧客
による注文に対して売上確定を記憶装置に登録し且つ注
文代金請求処理を実施するステップとを含む。

【００１３】本発明の第４の態様における注文代金請求
処理は、顧客認証要求に係る、顧客の端末の情報と店舗
情報と少なくとも当該顧客による注文の識別情報とを受
信した場合に、第１のキーを生成して当該第１のキーを
前記顧客の端末に送信するステップと、顧客の端末から
第１のキーを受信すると当該第１のキーの正当性確認処
理を実施し、顧客の端末から当該顧客の認証用情報を受
信すると顧客に対する認証処理を実施し、第１のキーの
正当性確認処理結果及び顧客に対する認証処理結果が肯
定的である場合に第２のキーを生成して、店舗のコンピ
ュータに当該第２のキー及び顧客による注文の識別情報
を送信するステップと、店舗のコンピュータから第２の
キーと店舗の認証用情報と顧客による注文の内容情報と
を受信した場合、第２のキーの正当性確認処理と、店舗
に対する認証処理と、予め登録されている顧客の情報を
用いた顧客の与信処理とを実施し、第２のキーの正当性
確認処理、店舗に対する認証処理及び顧客の与信処理の
結果が肯定的である場合に顧客による注文の内容情報を
記憶装置に登録し、店舗のコンピュータに顧客による注
文の内容情報に対する登録識別情報を送信するステップ
と、店舗のコンピュータから注文代金請求依頼に係る登
録識別情報を受信した場合に、登録識別情報の正当性を
確認し、正当性が確認された場合には当該顧客による注
文に対して売上確定を記憶装置に登録し且つ注文代金請
求処理を実施するステップとを含む。

【００１４】本発明の第１の態様に係る変形を、本発明
の第３の態様に係る変形に適用することも可能である。
また、本発明の第２の態様に係る変形を、本発明の第４
の態様に係る変形に適用することも可能である。

【００１５】また、このような方法をコンピュータに実
行させるプログラムを作成することも可能であって、当
該プログラムは、例えばフレキシブルディスク、ＣＤ−
ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディス
ク等の記憶媒体又は記憶装置に格納される。なお、中間
的な処理結果はメモリに一時保管される。

【００１６】

【発明の実施の形態】図１に本発明の一実施例における
システム概要を示す。例えばインターネットであるネッ
トワーク１には、ウェブ（Ｗｅｂ）ブラウザを含む１又
は複数の顧客端末３と、商品などのオンライン販売を行
うＷｅｂサーバである店舗サーバ５と、本発明の一実施
例に係る注文代金の決済処理を行う決済サーバ７とが接
続されている。

【００１７】店舗サーバ５は、例えば決済サーバ７の管
理者から配布される決済サーバ用コマンドインターフェ
ース（ＩＦ）プログラム５３と、店舗サーバ５における
他の処理のための店舗側処理部５５とを含む。また、店
舗サーバ５には、販売している商品などのデータベース
や、顧客から受けた注文に関する情報を格納する注文情
報データベース（ＤＢ）５１等が備えられ、店舗のスタ
ッフが操作する店舗端末１１が接続されている。さら
に、店舗サーバ５には例えば在庫管理システム１３や、
その他商品などの出荷のための処理を行うサーバ（図示
せず）が接続されている場合もある。これらの在庫管理
システム１３や商品などの出荷のための処理を行うサー
バの機能を店舗サーバ５自身が備えている場合もある。
さらに、店舗サーバ５において、プログラムやコンテン
ツ・データをネットワーク１を介して顧客端末３にダウ
ンロードさせることにより対価を得るというビジネスを
行っている場合には、例えばプログラムやコンテンツ・
データを格納したダウンロード用のサーバ１７をネット
ワーク１に接続し、店舗サーバ５と連携させるような場
合もある。ダウンロード用サーバ１７の機能を店舗サー
バ５が備えている場合もある。

【００１８】ネットワーク１には例えば運送会社又は店
舗サーバ５を運営する会社の物流部門の物流システム１
５が接続されている。この物流システム１５は他のネッ
トワークや専用線等により店舗サーバ５に接続されてい
ることもある。その他ネットワーク１には多数のサーバ
等が接続されている。

【００１９】決済サーバ７は、本実施例では所定のイン
ターネット・サービス・プロバイダ（ＩＳＰ：Internet
Service Provider）の会員であって、クレジットカー
ド情報を予め登録している顧客のために、当該顧客によ
る商品などの購入代金の決済処理を行うものである。よ
って、決済サーバ７は、会員のＩＤ及びパスワードの情
報、クレジットカードの情報を格納した会員情報データ
ベース７１を参照できるようになっている。また、本実
施例では予め所定の条件を満たしていると判断された店
舗サーバ７に決済サーバ７の利用を許可するような構成
となっている。よって、決済サーバ７は、各店舗又は各
店舗サーバ５のＩＤ及びパスワードを含む店舗の情報を
格納した店舗情報データベース７３を参照できるように
なっている。本実施例ではクレジットカードによる決済
を行うため、決済サーバ７は、クレジット・オンライン
・システムであるＣＡＦＩＳ（Credit And Finance Inf
ormation switching System）９に接続しており、クレ
ジットカード会社のコンピュータとの通信が行えるよう
になっている。決済サーバ７でも、例えばクレジットカ
ード会社に対する処理が必要であるため、店舗サーバ５
から注文情報を受け取り、当該注文情報を蓄積しておく
必要がある。よって決済サーバ７は、注文情報等を登録
する決済注文情報データベース（ＤＢ）７５を使用す
る。さらに、決済サーバ７はクレジット会社に対する請
求を行うための情報を格納した請求ファイル７７も使用
する。

【００２０】図１に示したシステムにおける処理につい
て簡単に説明しておく。顧客は顧客端末３を操作して店
舗サーバ５にネットワーク１を介してアクセスし、購入
する商品等を検索する。購入したい商品等が見つかる
と、顧客は顧客端末３から店舗サーバ５に商品等の注文
を送信する。この時顧客は、決済には本実施例に係る決
済システムを利用することを指示するものとする。店舗
サーバ５は、顧客端末３から受信した注文情報を注文情
報ＤＢ５１に登録し、当該注文情報、店舗サーバ５の情
報（例えば店舗認証用情報又は店舗識別情報若しくは店
舗サーバ５のアドレス等）及び顧客端末３のアドレス等
を追加して決済サーバ７に転送する。決済サーバ７は、
店舗サーバ５の情報を用いて店舗の確認／認証を行い、
注文情報を仮登録する。決済サーバ７は、店舗サーバ５
の情報及び注文情報に問題がなければ、動作キーＫＥＹ
０１を生成して、顧客端末３に顧客（会員）のＩＤ及び
パスワードを入力するように促す画面情報及び隠しパラ
メータとして動作キーＫＥＹ０１を送信する。

【００２１】顧客端末３はＩＤ及びパスワードを入力す
るように促す画面を顧客に対し表示する。そして、顧客
は顧客（会員）のＩＤ及びパスワードを入力し、顧客端
末３はＩＤ及びパスワード並びに隠しパラメータの動作
キーＫＥＹ０１を決済サーバ７に送信する。決済サーバ
７においては、動作キーＫＥＹ０１が正当な動作キーで
あるか、ＩＤ及びパスワードの対が正しいか、受信した
顧客（会員）ＩＤの顧客がＩＳＰにおける正常な会員で
あるか、本実施例に係る決済システムを使用する資格が
あるかを検査する。全ての検査が正常に終了すれば、決
済サーバ７は、動作キーＫＥＹ０２を生成する。そし
て、決済サーバ７は、全ての検査が正常に終了していれ
ば、隠しパラメータとして動作キーＫＥＹ０２と、検査
結果と、注文情報に含まれる又は注文情報とは別途決済
サーバ７に送られてきた、店舗サーバ５における当該注
文の識別情報（以下、管理番号と呼ぶ。但し、番号だけ
でなく記号の場合もある。）とを店舗サーバ５に送信す
る。もし、いずれかの検査でエラーが生じた場合には、
動作キーＫＥＹ０２は生成されず、店舗サーバ５には、
いずれかの検査でエラーが生じたことが通知される。Ｉ
Ｄ及びパスワードの対が正しくない場合には、顧客端末
３にも通知される。例えば、ＩＤ及びパスワードの対の
入力は２回まで再試行が許される。ここまでで顧客認証
処理及びシステム利用資格確認処理が終了する。

【００２２】店舗サーバ５は、検査結果が検査の成功を
示していれば、受信した管理番号を用いて注文情報ＤＢ
５１から注文情報を取り出し、当該注文情報と、管理番
号と、動作キーＫＥＹ０２とを、店舗サーバ５で実行さ
れている決済サーバ用コマンドインターフェース（コマ
ンドＩＦ）プログラム５３に出力する。決済サーバ用コ
マンドＩＦプログラム５３は、決済サーバ７と店舗サー
バ５がやり取りするためのインターフェースを提供する
プログラムであり、例えば決済サーバ７の管理者が店舗
に提供するものである。もし、顧客ＩＤがＩＳＰにおけ
る正常な会員であるか又は本実施例に係る決済システム
を使用する資格があるかという検査でエラーを生じた場
合には、店舗サーバ５から顧客端末３に対して、本実施
例に係る決済システムが使えない旨の通知を行う。

【００２３】注文情報と管理番号と動作キーＫＥＹ０２
とを受け取った決済サーバ用コマンドＩＦプログラム５
３は、店舗認証用情報と共にこれらの情報を決済サーバ
７に送信する。決済サーバ７は、店舗に対する認証処理
を実施し、仮登録された注文情報と今回受信した注文情
報を照合し、受信した動作キーＫＥＹ０２の正当性を確
認する。そして、これらの処理結果が肯定的である場合
には与信処理を実施する。与信処理は、決済サーバ７に
予め登録されている当該顧客のクレジットカード番号を
用いてＣＡＦＩＳ９に対して与信照会を行う処理であ
る。ＣＡＦＩＳ９から当該顧客のクレジットカードで決
済可能な旨の情報を得ると、決済サーバ７は、注文情報
を決済サーバ７内の決済注文情報データベース（ＤＢ）
７５に登録し、決済サーバ７における注文情報の識別情
報である受付番号（番号でなく記号を用いてもよい）を
生成する。そして、注文情報が決済サーバ７の決済注文
情報ＤＢ７５に登録された場合、顧客に対して、注文が
登録されたことを通知するための注文登録通知メールを
送信する。

【００２４】決済サーバ７は、決済サーバ用コマンドＩ
Ｆプログラム５３に対して、注文情報の登録可否を示す
情報、登録された場合には受付番号、及び管理番号を送
信する。決済サーバ用コマンドＩＦプログラム５３は、
受信した情報を店舗サーバ５の注文管理を行う処理部に
出力する。そして、店舗サーバ５は顧客端末３に対して
注文が決済システムに受け付けられたことを示す画面情
報を送信する。顧客端末３は、注文が決済システムに受
け付けられたことを示す画面を表示する。また、店舗サ
ーバ５は受注を示す情報を注文情報ＤＢ５１に登録す
る。一方、店舗認証処理、動作キーＫＥＹ０２の正当性
確認処理及び与信処理の処理結果のいずれかが否定的な
ものである場合には、店舗サーバ５は顧客端末３に対し
て注文が決済システムに受け付けられなかったことを示
す画面情報を送信する。また、店舗認証処理以外の処理
結果が否定的である場合には注文情報ＤＢ５１に受注不
可が登録される。そして顧客端末３に受注できない旨の
通知を送信する。ここまでで受注処理が終了する。

【００２５】店舗サーバ５に接続された店舗端末１１を
操作する店舗のスタッフは、例えば店舗サーバ５の注文
情報ＤＢ５１の受注を示す情報が登録された注文を参照
して、商品の出荷のための作業を行う。なお、注文情報
が決済サーバ７のデータベースに登録された場合に、店
舗サーバ５が当該注文情報を受注情報として注文情報Ｄ
Ｂ５１から受注情報ＤＢに移動又はコピーし、当該受注
情報ＤＢを参照するような構成も可能である。又、受注
を示す情報を注文情報ＤＢ５１に登録した場合に、店舗
サーバ５が物流システム１５に自動的に集荷依頼を出力
するような構成も可能である。また、プログラムやコン
テンツ・データのダウンロードを行わせる場合には、受
注を示す情報を注文情報ＤＢ５１に登録した場合に、店
舗サーバ５からダウンロード用サーバ１７にダウンロー
ド許可を出力するような構成も可能である。さらに、他
の商品出荷に関連するシステムが存在する場合には、注
文情報ＤＢ５１に受注を示す情報が登録された後に店舗
サーバ５から自動的に当該システムに処理依頼を出力す
るような構成も可能である。いずれにせよ注文を行った
顧客に対して、商品などの出荷のための処理を行う。な
お、出荷／配送の完了についても注文情報ＤＢ５１に登
録しておく。

【００２６】出荷／配送が完了し注文代金の請求を行う
段階になると、例えば店舗端末１１を操作する店舗のス
タッフは、注文情報ＤＢ５１を参照して、注文代金請求
の対象となる注文の管理番号又は受付番号を抽出する。
なお、物流システム１５と店舗サーバ５が連携している
場合には、物流システム１５から配送完了通知を店舗サ
ーバ５が受信する。この配送完了通知から管理番号又は
受付番号を抽出する。さらに、ダウンロード用サーバ１
７と店舗サーバ５が連携する場合には、ダウンロード用
サーバ１７からダウンロード完了通知を店舗サーバ５が
受信する。そして、ダウンロード完了通知から管理番号
又は受付番号を抽出する。注文代金請求の対象となる注
文の管理番号又は受付番号を注文代金請求依頼として、
店舗サーバ５の決済サーバ用コマンドＩＦプログラム５
３に出力すると、決済サーバ用コマンドＩＦプログラム
５３は店舗の認証用情報と共に管理番号又は受付番号を
決済サーバ７に送信する。

【００２７】決済サーバ７は、店舗の認証用情報を用い
て店舗に対する認証処理を行う。認証処理の結果が肯定
的であれば、決済サーバ７に登録されている受付番号又
は管理番号に対応する注文に売上確定を示す情報を登録
し、注文代金請求処理を実施する。注文代金請求処理と
は、当該顧客が登録しているクレジットカードのクレジ
ットカード会社に対する代金請求のための情報に、当該
注文代金の請求情報を追加するものである。この代金請
求のための情報は、例えば月に一度クレジットカード会
社に渡される。クレジットカード会社はこれらの情報を
元に各顧客に対して代金請求を行う。注文代金請求処理
が終了すれば、処理結果が決済サーバ用コマンドＩＦプ
ログラム５３に送信され、決済サーバ用コマンドＩＦプ
ログラム５３は処理結果を店舗サーバ５の売上確定処理
部に出力する。店舗サーバ５では、注文代金請求処理の
結果が肯定的である場合には、例えば注文情報ＤＢ５１
内の管理番号又は受付番号に対応する注文について売上
確定又は請求済みを登録する。一方、注文代金請求処理
の結果が否定的である場合には、管理番号又は受付番号
等が正しくない場合等であるから、それらの確認を行う
ように促す通知を店舗端末１１に出力する。以上で決済
が終了する。

【００２８】以下、本実施例におけるシステム動作の詳
細を図２乃至図８を用いて説明する。

【００２９】１．顧客認証処理及びシステム利用資格確
認処理 ［実施例１］図２に実施例１に係る顧客認証処理及びシ
ステム利用資格確認処理のフローを示す。例えば顧客は
顧客端末３を操作して店舗サーバ５にアクセスする（ス
テップＳ１）。例えば店舗サーバ５は、商品情報及び注
文フォームを顧客端末３に送信する（ステップＳ３）。
ステップＳ１及びＳ３の処理には様々な形態があり、こ
こでは単純な場合のみを示している。顧客端末３はＷｅ
ｂブラウザにて商品情報及び注文フォームを表示する。
顧客は、Ｗｅｂブラウザに注文内容を入力し、注文フォ
ームに含まれる送信ボタンを押し、注文情報を店舗サー
バ５に送信する（ステップＳ５）。注文情報には、商品
名、商品番号、数量、金額、住所、氏名、電話番号、電
子メール・アドレスなどを含む。また、注文情報には本
実施例に係る決済システムが決済方法として選択された
という情報を含むようにすることも可能である。さら
に、本実施例に係る決済システムに関連するＩＳＰの顧
客（会員）ＩＤを含むような場合もある。なお、店舗サ
ーバ５及び顧客端末３は互いのアドレスを認識している
ものとする。

【００３０】店舗サーバ５は顧客端末３から注文情報を
受信すると、注文情報のフォーマット等を確認の上、当
該注文情報を注文情報ＤＢ５１に登録する（ステップＳ
７）。なお、登録する前に、例えば在庫管理システム１
３に在庫の問い合わせを行うようにすることも可能であ
る。そして、店舗サーバ５は、受信した注文情報と店舗
サーバ５内の顧客認証などの結果を受け取る処理部（例
えばＣＧＩ（Common Gateway Interface））のアドレス
情報（例えばＵＲＬ（Uniform Resource Locator））と
店舗識別情報（例えば店子コード）と当該顧客の注文の
識別情報（管理番号）とを含み、当該注文情報について
決済のための認証手続きなどを行うように依頼する決済
依頼の画面情報を顧客端末３に送信する（ステップＳ
９）。ここで送信される画面情報において本実施例に係
る決済システムを決済手段として選択するか尋ねるよう
にすることも可能である。顧客端末３は受信した画面情
報をＷｅｂブラウザ内に表示し、顧客は、本実施例に係
る決済システムを用いた決済のための認証手続きなどを
行うことを了承する場合には「ＯＫ」ボタンを押す。そ
うすると、顧客端末３から決済依頼が店舗サーバ５に送
信される（ステップＳ１１）。

【００３１】店舗サーバ５は、決済依頼を受信すると、
当該決済依頼を決済サーバ７に転送する（ステップＳ１
３）。また、転送する際には、顧客端末３のアドレス情
報を、決済依頼と共に決済サーバ７に転送する。なお、
店舗識別情報とは別に又は店舗識別情報の代わりに店舗
の認証用情報（例えば店舗のＩＤ及びパスワード）を併
せて転送する場合もある。決済依頼を受信した決済サー
バ７は、少なくとも店舗識別情報が実在するコードであ
るか等の店舗の確認を行う。もし店舗の認証用情報を受
信した場合には、店舗のＩＤ及びパスワードの対が正し
いか否かを検査する。これらにより店舗の確認が取れる
と、一旦受信した決済依頼に含まれる注文情報、店舗サ
ーバ５のアドレス情報、店舗識別情報、及び管理番号等
を、注文仮受付ファイル等に仮登録しておく。そして、
決済サーバ７は動作キーＫＥＹ０１を生成し、顧客端末
３に、当該動作キーＫＥＹ０１を隠しパラメータとし
て、これから決済サーバ７との通信において顧客認証を
行うことを顧客に確認させるための認証確認画面情報を
送信する（ステップＳ１５）。動作キーＫＥＹ０１を用
いるのは、この処理ステップを必ず通過していることを
後に確認できるようにするためである。

【００３２】顧客端末３は認証確認画面をＷｅｂブラウ
ザ内に表示し、顧客は認証確認画面に含まれる「ＯＫ」
ボタンを押す。そうすると、顧客端末３から認証確認が
隠しパラメータである動作キーＫＥＹ０１と共に決済サ
ーバ７に送信される（ステップＳ１７）。決済サーバ７
は、受信した動作キーＫＥＹ０１の正当性を確認する。
正当性が確認された場合には、決済サーバ７は、顧客の
ＩＤ及びパスワードの入力を促す画面情報を顧客端末３
に送信する（ステップＳ１９）。なお、動作キーＫＥＹ
０１の正当性が確認されなかった場合には、このまま処
理を続けると問題が生じえるので、例えば店舗サーバ５
及び顧客端末３にエラーが生じたことを通知する。

【００３３】顧客端末３は、Ｗｅｂブラウザ内に顧客Ｉ
Ｄ及びパスワードの入力を促す画面を表示する。少なく
ともこれ以下の通信においては、例えばＳＳＬ（Secure
Socket Layer）技術を用いて通信の秘密を守る必要が
ある。これ以前の通信においてもＳＳＬを用いてもよ
い。顧客は、要求に応じて、顧客ＩＤ及びパスワードを
Ｗｅｂブラウザ内に入力し、Ｗｅｂブラウザ内の画面に
設けられた送信ボタンを押す。そうすると顧客端末３は
入力された顧客ＩＤ及びパスワードを決済サーバ７に送
信する（ステップＳ２１）。なお、ここでは顧客に対す
る認証処理のために、顧客ＩＤ及びパスワードを使用し
ているが、他の方法にて顧客認証を行う場合には、それ
に必要な情報を顧客端末３から決済サーバ７に送信す
る。このような形にて顧客ＩＤ及びパスワードを決済サ
ーバ７に出力すれば、店舗サーバ５には顧客ＩＤとパス
ワードの対は送信されず、悪意ある又は悪意を持つよう
になった店舗に顧客ＩＤ及びパスワードを悪用されるの
を防止することができる。

【００３４】決済サーバ７は、顧客ＩＤ及びパスワード
を受信すると、まず顧客ＩＤ及びパスワードの対が予め
会員情報ＤＢ７１に登録されている顧客情報と同一か否
か判断する。もし、同一でなければ、再度入力を行うよ
うにステップＳ２１に戻る。例えば３回、顧客ＩＤ及び
パスワードの確認を行っても同一であると判断できなか
った場合には、決済サーバ７は顧客端末３に認証エラー
画面情報を送信する。また、決済サーバ７は、店舗サー
バ５に認証エラーを通知する場合もある。

【００３５】もし、受信した顧客ＩＤ及びパスワードの
対が予め登録されている顧客情報と同一である場合に
は、当該顧客の認証が完了することになる。但し、本実
施例では顧客の認証だけでは本実施例に係る決済システ
ムで決済できるわけではない。次に決済サーバ７は、シ
ステム利用資格の確認を行う。本実施例ではシステム利
用資格の確認は２段階で行われる。まず、所定のＩＳＰ
における正常な会員であるか否かが確認される。すなわ
ち、ＩＳＰの会員であっても、ＩＳＰの使用料金などの
支払いが滞っている場合には正常な会員であるとは言え
ない。次に、本実施例に係る決済システムが使用できる
ということで登録されているかという点が確認される。
本実施例ではクレジットカードにより決済されることを
前提としているので、予めクレジットカード番号が登録
されていなければならない。また、別途基準を設けて、
当該基準を満たす者のみ本実施例に係る決済システムを
使用できるように設定することも可能である。このよう
な顧客認証処理及びシステム利用資格確認処理の結果が
肯定的である場合には、決済サーバ７は動作キーＫＥＹ
０２（セッションキーと呼ばれる場合もある）を生成す
る（ステップＳ２３）。また、動作キーＫＥＹ０２、注
文情報、管理番号等をセッションファイルとして保管し
ておき、後の処理に使用するような構成も可能である。

【００３６】そして、決済サーバ７は、顧客認証処理及
びシステム利用資格確認処理の処理結果と、処理結果が
肯定的である場合には動作キーＫＥＹ０２と、管理番号
とを店舗サーバ５に送信する（ステップＳ２５）。店舗
サーバ５は、決済サーバ７からそれらの情報を受信する
（ステップＳ２７）。そして、システム利用資格確認処
理にてエラーが存在する場合には、店舗サーバ５は、顧
客端末３にシステム利用資格がないことを通知し、顧客
端末３はシステム利用資格がない旨の表示を行う（ステ
ップＳ２９）。また、注文情報ＤＢ５１内における当該
管理番号の注文に対し決済できないことを登録する。

【００３７】ここまでで与信処理の前段階である顧客認
証及びシステム利用資格確認処理が終了する。なお、図
２に示した処理フローは様々に変形可能である。例え
ば、ステップＳ１３において店舗サーバ５が決済依頼を
転送する構成ではなく、顧客端末３から直接決済サーバ
７に決済依頼を送信するような構成も可能である。この
場合には店舗サーバ５は顧客端末３のアドレス情報を決
済依頼に付加する必要がない。また、顧客端末３に送信
される決済依頼の画面表示には、決済サーバ７のアドレ
スを埋め込んでおく。

【００３８】また、上の説明ではシステム利用資格をも
確認するような処理フローとなっているが、システム利
用資格を別途規定しない場合もある。その場合には、本
処理フローは顧客認証処理フローとなる。単純な顧客認
証処理フローとする場合には、注文情報や注文情報の識
別情報である管理番号等を決済サーバ７に送信しないよ
うな形態も可能である。

【００３９】なお、動作キーＫＥＹ０１及びＫＥＹ０２
については、有効期限を設けて有効期限内に決済サーバ
７に戻ってこないようであれば、動作キーの確認処理で
エラーとみなすようにすることも可能である。

【００４０】［実施例２］次に図３を用いて顧客認証処
理及びシステム利用資格確認処理の第２の実施例を説明
する。例えば顧客は顧客端末３を操作して店舗サーバ５
にアクセスする（ステップＳ３１）。例えば店舗サーバ
５は、商品情報及び注文フォームを顧客端末３に送信す
る（ステップＳ３３）。ステップＳ１及びＳ３の処理に
は様々な形態があり、ここでは単純な場合のみを示して
いる。顧客端末３はＷｅｂブラウザにて商品情報及び注
文フォームを表示する。顧客は、Ｗｅｂブラウザに注文
内容を入力し、注文フォームに含まれる送信ボタンを押
し、注文情報を店舗サーバ５に送信する（ステップＳ３
５）。注文情報には、商品名、商品番号、数量、金額、
住所、氏名、電話番号、電子メール・アドレスなどを含
む。また、注文情報には本実施例に係る決済システムが
決済方法として選択されたという情報を含むようにする
ことも可能である。さらに、本実施例に係る決済システ
ムに関連するＩＳＰの顧客（会員）ＩＤを含むような場
合もある。店舗サーバ５は顧客端末３から注文情報を受
信すると、注文情報のフォーマット等を確認の上、当該
注文情報を注文情報ＤＢ５１に登録する（ステップＳ３
７）。なお、登録する前に、例えば在庫管理システム１
３に在庫の問い合わせを行うようにすることも可能であ
る。そして、店舗サーバ５は、受信した注文情報と店舗
サーバ５内の顧客認証などの結果を受け取る処理部（例
えばＣＧＩ）のアドレス情報（例えばＵＲＬ）と店舗識
別情報（例えば店子コード）と注文の管理番号とを含
み、当該注文情報について決済のための認証手続きなど
を行うように依頼する決済依頼の画面情報を顧客端末３
に送信する（ステップＳ３９）。ここで送信される画面
情報において本実施例に係る決済システムを決済手段と
して選択するか尋ねるようにすることも可能である。顧
客端末３は受信した画面情報をＷｅｂブラウザ内に表示
し、顧客は、本実施例に係る決済システムを用いた決済
のための認証手続きなどを行うことを了承する場合には
「ＯＫ」ボタンを押す。そうすると、顧客端末３から決
済依頼が店舗サーバ５に送信される（ステップＳ４
１）。

【００４１】店舗サーバ５は、決済依頼を受信すると、
当該決済依頼を決済サーバ７に転送する（ステップＳ４
３）。また、転送する際には、顧客端末３のアドレス情
報を、決済依頼と共に決済サーバ７に転送する。なお、
店舗識別情報とは別に又は店舗識別情報の代わりに店舗
の認証用情報（例えば店舗のＩＤ及びパスワード）を併
せて転送する場合もある。決済依頼を受信した決済サー
バ７は、少なくとも店舗識別情報が実在するコードであ
るか等の店舗の確認を行う。もし店舗の認証用情報を受
信した場合には、店舗のＩＤ及びパスワードの対が正し
いか否かを検査する。これらにより店舗の確認が取れる
と、一旦受信した決済依頼に含まれる注文情報、店舗サ
ーバ５のアドレス情報、店舗識別情報、及び管理番号等
を、注文仮受付ファイル等に仮登録しておく。そして、
決済サーバ７は、動作キーＫＥＹ０１を生成し、顧客端
末３に、当該動作キーＫＥＹ０１を隠しパラメータとし
て、顧客のＩＤ及びパスワードの入力を促す画面情報を
顧客端末３に送信する（ステップＳ４５）。動作キーＫ
ＥＹ０１を用いるのは、この処理ステップを必ず通過し
ていることを後に確認できるようにするためである。

【００４２】顧客端末３は、Ｗｅｂブラウザ内に顧客Ｉ
Ｄ及びパスワードの入力を促す画面を表示する。少なく
ともこれ以下の通信においては、例えばＳＳＬ（Secure
Socket Layer）技術を用いて通信の秘密を守る必要が
ある。これ以前の通信においてもＳＳＬを用いてもよ
い。顧客は、要求に応じて、顧客ＩＤ及びパスワードを
Ｗｅｂブラウザ内に入力し、Ｗｅｂブラウザ内の画面に
設けられた送信ボタンを押す。そうすると顧客端末３は
入力された顧客ＩＤ及びパスワードを決済サーバ７に送
信する（ステップＳ４７）。このような形にて顧客ＩＤ
及びパスワードを決済サーバ７に出力すれば、店舗サー
バ５には顧客ＩＤとパスワードの対は送信されず、悪意
ある又は悪意を持つようになった店舗に顧客ＩＤ及びパ
スワードを悪用されるのを防止することができる。又、
顧客端末３は動作キーＫＥＹ０１を決済サーバ７に送信
する。

【００４３】決済サーバ７は、受信した動作キーＫＥＹ
０１の正当性を確認する。もし、正当性が確認されなか
った場合には、このまま処理を続けると問題を生じ得る
ので、例えば店舗サーバ５及び顧客端末３にエラーを生
じたことを通知する。さらに、決済サーバ７は、受信し
た顧客ＩＤ及びパスワードの対が予め登録されている顧
客情報と同一か否か判断する。もし、同一でなければ、
再度入力を行うようにステップＳ４７に戻る。例えば３
回、顧客ＩＤ及びパスワードの確認を行っても同一であ
ると判断できなかった場合には、決済サーバ７は顧客端
末３に認証エラー画面情報を送信する。また、決済サー
バ７は、店舗サーバ５に認証エラーを通知する場合もあ
る。

【００４４】もし、受信した顧客ＩＤ及びパスワードの
対が予め登録されている顧客情報と同一である場合に
は、当該顧客の認証が完了することになる。但し、本実
施例では顧客の認証だけでは本実施例に係る決済システ
ムで決済できるわけではない。次に決済サーバ７は、シ
ステム利用資格の確認を行う。本実施例でもシステム利
用資格の確認は２段階で行われる。まず、所定のＩＳＰ
における正常な会員であるか否かが確認される。すなわ
ち、ＩＳＰの会員であっても、ＩＳＰの使用料金などの
支払いが滞っている場合には正常な会員であるとは言え
ない。次に、本実施例に係る決済システムが使用できる
ということで登録されているかという点が確認される。
本実施例でもクレジットカードにより決済されることを
前提としているので、予めクレジットカードが登録され
ていなければならない。また、別途基準を設けて、当該
基準を満たす者のみ本実施例に係る決済システムを使用
できるように設定することも可能である。このような顧
客認証処理及びシステム利用資格確認処理の結果が肯定
的である場合には、決済サーバ７は動作キーＫＥＹ０２
（セッションキーとも呼ばれる）を生成する（ステップ
Ｓ４９）。動作キーＫＥＹ０２、注文情報、管理番号等
をセッションファイルとして保管しておき、後の処理に
使用するような構成も可能である

【００４５】そして、決済サーバ７は、顧客認証処理及
びシステム利用資格確認処理の処理結果と、処理結果が
肯定的である場合には動作キーＫＥＹ０２と、管理番号
とを店舗サーバ５に送信する（ステップＳ５１）。店舗
サーバ５は、決済サーバ７からそれらの情報を受信する
（ステップＳ５３）。そして、システム利用資格確認処
理にてエラーが存在する場合には、店舗サーバ５は、顧
客端末３にシステム利用資格がないことを通知し、顧客
端末３はその旨の表示を行う（ステップＳ５５）。ま
た、注文情報ＤＢ５１内における当該管理番号の注文に
対し決済できないことを登録する。

【００４６】ここまでで与信処理の前段階である顧客認
証及びシステム利用資格確認処理が終了する。なお、図
３に示した処理フローは様々に変形可能である。例え
ば、ステップＳ４３において店舗サーバ５が決済依頼を
転送する構成ではなく、顧客端末３から直接決済サーバ
７に決済依頼を送信するような構成も可能である。この
場合には店舗サーバ５は顧客端末３のアドレス情報を決
済依頼に付加する必要がない。また、顧客端末３に送信
される決済依頼の画面表示には、決済サーバ７のアドレ
スを埋め込んでおく。

【００４７】また、実施例１でも述べたように、システ
ム利用資格をも確認するような処理フローとなっている
が、システム利用資格を別途規定しない場合もある。そ
の場合には、本処理フローは顧客認証処理フローとな
る。単純な顧客認証処理フローとする場合には、注文情
報や注文情報の識別情報である管理番号等を決済サーバ
７に送信しないような形態も可能である。

【００４８】なお、動作キーＫＥＹ０１及びＫＥＹ０２
については、有効期限を設けて有効期限内に決済サーバ
７に戻ってこないようであれば、動作キーの確認処理で
エラーとみなすようにすることも可能である。

【００４９】２．与信処理 図４に、顧客認証処理及びシステム利用資格確認処理に
おいてエラーが生じなかった顧客に対する与信処理のフ
ローを示す。図１に関連して既に説明したが、店舗サー
バ５には、店舗側が用意する店舗サーバ５の機能部分
（以下店舗側処理部５５（例えばＣＧＩ）と呼ぶ。）
と、決済サーバ７に対する処理を行う決済サーバ用コマ
ンド・インターフェース（ＩＦ）プログラム５３とが設
けられている。本実施例ではこれらを分けて説明するこ
ととする。

【００５０】まず店舗サーバ５の店舗側処理部５５は、
決済サーバ７から受信した管理番号（ステップＳ２７又
はＳ５３）で注文情報ＤＢ５１を検索し、管理番号に係
る注文情報を抽出する（ステップＳ６１）。例えばこの
時点において店舗側処理部５５は在庫管理システム１３
に対して、注文に係る商品の在庫確認を行うようにする
ことも可能である（ステップＳ６３）。在庫管理システ
ム１３との連携が可能であれば本ステップを実施すれば
よいので、本ステップＳ６３は図４において点線囲みと
している。もし、ここで在庫切れであると判断された場
合には、店舗側処理部５５は顧客端末５に在庫切れを通
知し、顧客端末３は在庫切れ通知を表示する（ステップ
Ｓ６５）。

【００５１】在庫管理システム１３と連携しない場合又
は在庫の確認が取れた場合に、店舗側処理部５５は決済
サーバ７から受信した動作キーＫＥＹ０２と管理番号と
注文情報とを決済サーバ用コマンドＩＦプログラム５３
に出力する（ステップＳ６７）。なお、別途顧客から得
たクレジットカード有効期限の情報を併せて出力するよ
うな構成とすることも可能である。決済サーバ用コマン
ドＩＦプログラム５３は、店舗側処理部５５から受け取
った情報に加え、店舗認証用情報を、決済サーバ７に送
信する（ステップＳ６９）。

【００５２】決済サーバ７は、受信した動作キーＫＥＹ
０２の正当性を、例えば送信した動作キーＫＥＹ０２を
格納したセッションファイルを用いて確認する。動作キ
ーに有効期限が設けられている場合には、有効期限内に
受信したか否かも検査する。また、セッションファイル
に格納された注文情報及び管理番号と、今回受信した注
文情報及び管理番号と比較することにより処理の連続性
及びこれらの情報の正当性を確認する。これらの確認で
エラーが検出されれば以降の処理は行われず、ステップ
Ｓ７７の処理に移行する。また、決済サーバ７は、受信
した店舗認証用情報、すなわち店舗ＩＤとパスワードの
対を用いて店舗認証処理を行う（ステップＳ７１）。店
舗の認証が失敗した場合もステップＳ７７に移行する。
店舗の認証が成功すると、顧客認証処理及びシステム利
用資格確認処理において正当な顧客であると判断された
顧客のクレジットカード番号を顧客情報を格納したデー
タベースから取り出し、ＣＡＦＩＳ９を用いて当該クレ
ジットカードが適正なものであるか確認する与信処理を
実施する（ステップＳ７３）。例えば、適正なクレジッ
トカードであると確認できれば、ＣＡＦＩＳ９からは承
認番号が得られる。ここで与信処理に失敗する、すなわ
ちクレジットカードの与信限度額や有効期限などに問題
がある場合には、ステップＳ７７に移行する。

【００５３】もしステップＳ７３において与信処理に成
功すると、受信した注文情報を決済サーバ７の決済注文
情報ＤＢ７５に登録する。そして、決済サーバ７におけ
る当該注文情報の識別情報である受付番号（番号でなく
記号である場合もある）を発行する（ステップＳ７
５）。これにて、決済サーバ７において注文が受注とし
て確定される。決済サーバ７においては、受付番号と管
理番号と注文情報が対応付けられて決済注文情報ＤＢ７
５に記憶される。

【００５４】そして決済サーバ７は、ステップＳ７１及
びＳ７３までの処理結果と、注文情報が登録できた場合
には受付番号と、管理番号とを店舗サーバ５の決済サー
バ用コマンドＩＦプログラム５３に送信する（ステップ
Ｓ７７）。決済サーバ用コマンドＩＦプログラム５３
は、受信した情報を店舗側処理部５５に出力する（ステ
ップＳ７９）。店舗側処理部５５では、受信した処理結
果がステップＳ７１及びＳ７３までの処理が成功してい
ることを示している場合には、注文情報ＤＢ５１に、受
信した受付番号及び管理番号と、対応する注文情報とが
対応付けられて登録される。受付番号が登録されれば、
受注が確定したことになる。なお、別途受注確定を登録
することも可能である。また、受注が確定した注文に関
する情報（注文情報、受付番号及び管理番号）を別の受
注情報データベース（ＤＢ）に移動又はコピーして、後
の処理に利用するような構成も可能である。もし、受信
した処理結果がいずれかの処理にて失敗したことを示し
ている場合には、注文情報ＤＢ５１に受信した管理番号
の注文について決済不可能を登録する。成功又は失敗の
いずれの場合についても、店舗側処理部５５は顧客端末
３に受信した処理結果のうち顧客に開示可能な部分を送
信する（ステップＳ８１）。例えば「決済登録が完了し
ました。別途決済サーバから注文登録完了通知がメール
にて送信されます」又は「クレジットカードの有効期限
が切れていますので決済登録できませんでした」といっ
た情報が送信される。顧客端末３は、受信した処理結果
をＷｅｂブラウザ内に表示する（ステップＳ８３）。な
お、店舗認証処理にてエラーが発生した場合には、再度
店舗サーバ５が与信処理を決済サーバ７に依頼するよう
にしてもよい。

【００５５】また、決済サーバ７は、顧客に対して、注
文情報が決済サーバ７に登録されたことを通知するため
の注文登録通知メールを送信する（ステップＳ８５）。
これに対して顧客端末３では、注文登録通知メールを受
信する（ステップＳ９１）。注文登録通知メールは顧客
に対する確認のために送信される。なお、顧客端末３に
おけるメールの受信は送信後直ぐでなくともよい。

【００５６】また店舗サーバ５の店舗側処理部５５は、
次に行わなければならない商品等の出荷のために、在庫
管理システム１３に対して注文に係る商品の在庫確認を
行うようにすることも可能である（ステップＳ８７）。
在庫確認を行うか否かは任意である。もし、この段階に
て在庫確認を行って、在庫切れが判明した場合には、店
舗サーバ５の店舗側処理部５５は、例えば顧客に対して
在庫切れのメールを送信し、後に説明する受注取消し処
理を実施する。顧客端末３は、在庫切れのメールを受信
する（ステップＳ８９）。また、店舗側処理部５５は注
文情報ＤＢ５１に受注取消しを登録する。

【００５７】在庫管理システム１３に対する在庫確認処
理を行って在庫が存在した場合も在庫確認処理を行わな
い場合も、予め定められた出荷のための処理を他のシス
テムに依頼又は実行し、又は物流システム１５に対して
集荷依頼を送信したり、又はダウンロード用サーバ１７
に対してプログラムやコンテンツデータのダウンロード
の顧客端末３に対する許可を出力する（ステップＳ９
３）。なお、ステップＳ９３についても実行するか否か
は店舗サーバ５を含む店舗システムの構成に依存する。
よってステップＳ９３を全く実施しない場合もある。

【００５８】このような処理を行うことにより与信処理
及び受注確定処理が実施される。

【００５９】３．受注取消し／返品処理 図５に、例えば上で述べたように在庫切れで受注を取り
消す場合や、顧客から商品が返品された場合、又は顧客
が注文を注文登録通知メール受信後に取り消した場合等
に実施する処理について説明する。

【００６０】店舗サーバ５の店舗側処理部５５は、まず
受注取消し又は返品の対象となった注文の受付番号又は
管理番号の特定を行う（ステップＳ１０１）。これは例
えば店舗端末１１を店舗のスタッフが操作して、注文情
報ＤＢ５１を検索することにより行われる。例えば、店
舗のスタッフが、特定された受付番号又は管理番号を用
いて取消し処理を実施するように店舗端末１１を用いて
指示した場合には、当該指示を顧客端末３から受けた店
舗側処理部５５は、取消依頼と受付番号又は管理番号と
を決済サーバ用コマンドＩＦプログラム５３に出力する
（ステップＳ１０３）。なお、取消しの理由などを併せ
て送るようにすることも可能である。

【００６１】決済サーバ用コマンドＩＦプログラム５３
は、店舗認証用情報と、受付番号又は管理番号とを、決
済サーバ７の受注取消しを行う処理部に送信する（ステ
ップＳ１０５）。同じく取消しの理由などを併せて送る
ようにすることも可能である。決済サーバ７は、受信し
た店舗認証用情報にて店舗に対する認証処理を実施する
（ステップＳ１０７）。もし、認証処理においてエラー
が発生するとステップＳ１１７に移行する。店舗認証が
成功すると、次に与信取消処理を実施する（ステップＳ
１０９）。与信取消処理は、例えばＣＡＦＩＳ９から承
認番号を得ている場合には、当該承認番号についての取
消し処理を例えばＣＡＦＩＳ９に対して行う。何らかの
理由で与信取消処理に失敗する場合もある。この場合に
はステップＳ１１７に移行する。

【００６２】与信取消処理に成功した場合には、決済サ
ーバ７の決済注文情報ＤＢ７５において登録されてい
る、管理番号又受付番号に対応する注文情報について与
信取消を登録する（ステップＳ１１１）。これにて取消
しに係る注文に対し後に請求処理を行わないようにする
ことができる。そして、与信取消が登録されたことを通
知するための与信取消登録通知メールを与信取消しされ
た注文を行った顧客に対して送信する（ステップＳ１１
３）。顧客は顧客端末３において当該与信取消登録通知
メールを受信する（ステップＳ１１５）。これにより、
顧客も決済サーバ７において注文が正式に取り消された
ことを確認することができる。

【００６３】その後決済サーバ７は、処理結果を店舗サ
ーバ５の決済サーバ用コマンドＩＦプログラム５３に送
信する（ステップＳ１１７）。決済サーバ用コマンドＩ
Ｆプログラム５３は処理結果を受信して、店舗側処理部
５５に出力する（ステップＳ１１９）。店舗側処理部５
５は、例えば処理結果を注文情報ＤＢ５１に登録する
（ステップＳ１２１）。また、店舗端末１１に処理結果
を通知するような構成も可能である。なお、与信取消に
失敗している場合には、取消しができるまで与信取消処
理を実施しなければならない。

【００６４】４．検索処理 店舗サーバ５の注文情報ＤＢ５１に格納された注文情報
と、決済サーバ７の決済注文情報ＤＢ７５に格納された
注文情報の照合などのために、店舗サーバ５から決済サ
ーバ７に注文情報の検索を依頼する場合がある。図６を
用いて検索処理について説明する。検索処理には、受注
状況一覧参照処理と、受注状況詳細参照処理とが含まれ
る。受注状況一覧参照処理においては、受付番号、管理
番号、処理状態、顧客ＩＤ、期間の検索条件等を指定し
て、該当する注文情報を列挙するような出力を得ること
ができる。一方、受注状況詳細参照処理においては、受
付番号又は管理番号を検索条件として入力すると、対応
する注文情報の詳細を取得することができるようにな
る。

【００６５】例えば、店舗端末１１を操作する店舗のス
タッフが検索条件を決定して入力し、検索実行を店舗端
末１１に命ずると、店舗端末１１は検索条件を含む検索
命令を店舗サーバ５に送信する。検索命令を受信した店
舗サーバ５の店舗側処理部５５は、検索依頼及び入力さ
れた検索条件を決済サーバ用コマンドＩＦプログラム５
３に出力する（ステップＳ１３１）。決済サーバ用コマ
ンドＩＦプログラム５３は、店舗認証用情報及び受け取
った検索条件を、決済サーバ７の検索処理を行う処理部
に送信する（ステップＳ１３３）。決済サーバ７は、受
信した店舗認証用情報を用いて、店舗認証処理を実施す
る（ステップＳ１３５）。認証処理にてエラーが発生し
た場合にはステップＳ１３９に移行する。認証処理にて
店舗が認証されると、決済サーバ７の決済注文情報ＤＢ
７５に登録されている注文情報について、受信した検索
条件にて検索を実施する。そして、検索条件に合致する
注文情報を抽出する（ステップＳ１３７）。

【００６６】決済サーバ７は、ステップＳ１３７におい
て抽出した注文情報を店舗サーバ５の決済サーバ用コマ
ンドＩＦプログラム５３に送信する（ステップＳ１３
９）。なお、店舗認証に失敗した場合には失敗した旨の
情報を抽出情報の代わりに送信する。決済サーバ用コマ
ンドＩＦプログラム５３は、抽出された注文情報等を受
信して、店舗側処理部５５に出力する（ステップＳ１４
１）。店舗側処理部５５は、受信した注文情報等を店舗
端末１１に出力する（ステップＳ１４３）。店舗端末１
１は、受信した注文情報等を店舗のスタッフに対して表
示する。

【００６７】これにより、店舗サーバ５の注文情報ＤＢ
５１だけでなく、決済システム７の決済注文情報ＤＢ７
５に登録された注文情報にて注文情報及び処理状況等を
確認できるようになる。

【００６８】５．顧客確認処理 顧客認証処理及びシステム利用資格確認処理とは別に、
本実施例に係る決済システムのシステム利用資格のみ、
又はＩＳＰの会員資格のみを、例えば注文を受ける前に
確認したり、本実施例に係る決済システムのシステム利
用資格等を有している者のみに特別のサービスなどを提
供するなどの場合に、顧客確認を簡単に行えると便利で
ある。図７は、顧客確認のための処理フローを示す。

【００６９】まず、店舗サーバ５の店舗側処理部５５
は、何らかの処理の後に、顧客ＩＤを入力するように促
す画面情報を顧客端末３に出力する（ステップＳ１５
１）。顧客端末３は、受信した画面情報をＷｅｂブラウ
ザ内に表示して、顧客ＩＤ入力の要求に応じて、顧客は
顧客ＩＤを入力して、Ｗｅｂブラウザ内の「送信」ボタ
ンを押す。そうすると、顧客端末３は店舗サーバ５に顧
客ＩＤを送信する（ステップＳ１５３）。

【００７０】店舗サーバ５の店舗側処理部５５は、顧客
端末３から顧客ＩＤを受信すると、当該顧客ＩＤを決済
サーバ用コマンドＩＦプログラム５３に出力する（ステ
ップＳ１５５）。決済サーバ用コマンドＩＦプログラム
５３は、決済サーバ７の顧客確認処理部に店舗認証用情
報と受信した顧客ＩＤを送信する（ステップＳ１５
７）。決済サーバ７は、受信した店舗認証用情報を用い
て店舗認証処理を実施する。店舗認証が失敗すればステ
ップＳ１６３に移行する。店舗認証が成功すれば、決済
サーバ７は顧客ＩＤを用いて顧客確認処理を実施する
（ステップＳ１６１）。ここで顧客確認処理は、上で説
明したのと同じように、所定のＩＳＰの正常な会員であ
るか、加えて本実施例に係る決済システムを使用できる
かを確認する。なお、所定のＩＳＰの正常な会員である
かのみを確認するような構成とすることも可能である。

【００７１】いずれにしても、決済サーバ７は、顧客確
認処理の処理結果を決済サーバ用コマンドＩＦプログラ
ム５３に送信する（ステップＳ１６３）。店舗認証処理
でエラーが発生した場合には、店舗認証処理でエラーが
生じたという結果を決済サーバ用コマンドＩＦプログラ
ム５３に送信する。決済サーバ用コマンドＩＦプログラ
ム５３は処理結果を受信し、店舗側処理部５５に出力す
る（ステップＳ１６５）。店舗側処理部５５では受信し
た処理結果を参照して、次の所定の処理を実施する。例
えば、顧客確認できた場合には、顧客端末３に、注文情
報の入力を行うよう促したり、特別な商品の提示を行う
ための画面情報を出力する（ステップＳ１６７）。ま
た、顧客確認できなかった場合には、もう一度顧客ＩＤ
を入力しなおすように促したり、注文は受けられない旨
の表示を含む画面情報を顧客端末３に送信する。また、
店舗認証で失敗している場合には、再度顧客確認処理を
実施するように決済用コマンドＩＦプログラム５３に命
令する場合もある。

【００７２】以上のようにして、顧客認証処理及びシス
テム利用資格確認処理とは別に顧客確認を決済サーバ７
に行わせることができる。

【００７３】６．売上確定処理 顧客の注文に対応して、例えば商品の配送又はサービス
の提供を行い、又はプログラムやコンテンツ・データの
ダウンロードを行わせた後には、売上を確定するための
処理を実施しなければならない。図８に売上確定処理の
フローを示す。

【００７４】まず、店舗サーバ５の店舗側処理部５５
は、例えば物流システム１５から配送完了通知を受けた
場合、例えば店舗端末１１から配送完了入力がなされた
場合、例えばダウンロード用サーバ１７からのダウンロ
ード完了通知を受けた場合、それらの通知又は入力か
ら、売上確定の対象となる受付番号又は管理番号を特定
する。例えば、注文情報ＤＢ５１に配送に関する情報、
例えば配送依頼番号等が入力されていれば、配送完了通
知に含まれる配送依頼番号で注文が特定できるため、管
理番号又は受付番号を注文情報ＤＢ５１から抽出でき
る。また、配送完了通知等に必ず受付番号又は管理番号
を含めるようにすることも可能である。いずれにせよ、
売上確定の対象となる注文の受付番号又は管理番号は、
店舗側処理部５５から決済サーバ用コマンドＩＦプログ
ラム５３に出力される（ステップＳ１７１）。

【００７５】決済サーバ用コマンドＩＦプログラム５３
は、店舗認証用情報及び受付番号又は管理番号を決済サ
ーバ７の売上確定処理部に送信する（ステップＳ１７
３）。決済サーバ７は、店舗認証用情報を用いて店舗認
証処理を実施する（ステップＳ１７４）。店舗認証用情
報は、例えば店舗ＩＤ及びパスワードであって、決済サ
ーバ７は、予め店舗情報ＤＢ７３に登録されている店舗
情報の店舗ＩＤ及びパスワードと同一か否かを判定す
る。店舗認証に失敗した場合にはステップＳ１７９に移
行する。一方、店舗認証に成功した場合には、決済サー
バ７は受信した受付番号又は管理番号から決済サーバ７
における注文情報を特定し、その注文情報に対して売上
確定を登録する（ステップＳ１７５）。なお、管理番号
又は受付番号が誤って入力される場合もあるので、決済
サーバ７において注文情報を特定できない場合もある。
この場合には、ステップＳ１７９に移行する。

【００７６】次に、決済サーバ７は注文代金請求処理を
実施する（ステップＳ１７７）。注文代金請求処理は、
例えば注文情報をその注文の決済を行うクレジットカー
ド会社に対する請求ファイル７７に書き込む処理であ
る。例えば請求ファイル７７は月に一度クレジットカー
ド会社に送られる。クレジットカード会社は顧客に代金
の請求を行う。また、決済サーバ７は、決済注文情報Ｄ
Ｂ７５の当該注文に対して請求済みを示す情報を登録す
る。

【００７７】ここまで実施すると、決済サーバ７はステ
ップＳ１７４乃至Ｓ１７７の処理結果を決済サーバ用コ
マンドＩＦプログラム５３に送信する（ステップＳ１７
９）。決済サーバ用コマンドＩＦプログラム５３は、処
理結果を決済サーバ７から受信して、店舗側処理部５５
に出力する（ステップＳ１８１）。店舗側処理部５５
は、処理結果が成功を示している場合には、請求済み又
は売上確定を注文情報ＤＢ５１内の送信した管理情報又
は受付情報の注文情報に対して登録する（ステップＳ１
８３）。もし、処理結果が失敗を示している場合には、
例えば店舗端末１１に処理結果を出力し、受付番号又は
管理番号の確認を求めたり、自動的に再試行を行うよう
にすることができる。

【００７８】これにて売上確定処理が終了する。売上確
定がなされた注文の代金は、クレジットカード会社から
店舗に支払われ、クレジットカード会社は顧客に対して
請求を行って、顧客から代金を受け取る。

【００７９】以上本発明の一実施例を説明した。上では
顧客がＩＳＰの会員であることを前提として説明した
が、他の集団の会員であることを条件とすることも可能
である。

【００８０】また、本実施例では店舗サーバ５に店舗側
処理部５５と決済サーバ用コマンドＩＦプログラム５３
を設けるような構成としているが、このような機能の分
割を行うか否かは任意である。決済サーバ用コマンドＩ
Ｆプログラム５３についても、複数の機能モジュールに
分けることも可能である。

【００８１】さらに店舗サーバ５の店舗側処理部５５、
及び決済サーバ７については、上で述べた１乃至６の処
理毎に別個の処理部（例えばＣＧＩ）を設けることも可
能であるし、また同一の処理部（例えばＣＧＩ）が処理
を行うような構成とすることも可能である。上で述べた
１乃至６の各処理内において複数の処理部を設けて処理
させることも可能である。

【００８２】更に加えて店舗サーバ５は物理的に一台の
コンピュータにて実装される場合もあるし、複数台のコ
ンピュータにて実装される場合もある、決済サーバ７に
ついても同様である

【００８３】

【発明の効果】以上本発明により、決済業務を行う会社
のコンピュータ等において顧客認証から注文代金請求処
理等を行うための新規な技術を提供することができた。

【図面の簡単な説明】

【図１】本発明におけるシステム全体の概要を示すブロ
ック図である。

【図２】実施例１に係る顧客認証処理及びシステム利用
資格確認処理のフローチャートである。

【図３】実施例２に係る顧客認証処理及びシステム利用
資格確認処理のフローチャートである。

【図４】与信処理のフローチャートである。

【図５】受注取消し／返品処理のフローチャートであ
る。

【図６】検索処理のフローチャートである。

【図７】顧客確認処理のフローチャートである。

【図８】売上確定処理のフローチャートである。

【符号の説明】

１ ネットワーク ３ 顧客端末 ５ 店舗サーバ ７ 決済サーバ ９ ＣＡＦＩＳ １１ 店舗端末 １３ 在庫管理システム １５ 物流システム １７ ダウンロード用サーバ

Claims (8)

【特許請求の範囲】
1. 【請求項１】顧客認証要求に係る、顧客の端末の情報と
   店舗情報と少なくとも当該顧客による注文の識別情報と
   を受信した場合に、第１のキーを生成して当該第１のキ
   ーを前記顧客の端末に送信する認証確認手段と、 前記顧客の端末から前記第１のキーを受信すると当該第
   １のキーの正当性確認処理を実施し、前記顧客の端末か
   ら当該顧客の認証用情報を受信すると前記顧客に対する
   認証処理を実施し、前記第１のキーの正当性確認処理結
   果及び前記顧客に対する認証処理結果が肯定的である場
   合に第２のキーを生成して、前記店舗のコンピュータに
   当該第２のキー及び前記顧客による注文の識別情報を送
   信する顧客認証手段と、 前記店舗のコンピュータから前記第２のキーと前記店舗
   の認証用情報と前記顧客による注文の内容情報とを受信
   した場合、前記第２のキーの正当性確認処理と、前記店
   舗に対する認証処理と、予め登録されている前記顧客の
   情報を用いた前記顧客の与信処理とを実施し、前記第２
   のキーの正当性確認処理、前記店舗に対する認証処理及
   び前記顧客の与信処理の結果が肯定的である場合に前記
   顧客による注文の内容情報を記憶装置に登録し、前記店
   舗のコンピュータに前記顧客による注文の内容情報の登
   録可否を示す情報及び前記顧客による注文の識別情報と
   を送信する与信処理手段と、 前記店舗のコンピュータから注文代金請求依頼に係る前
   記顧客による注文の識別情報を受信した場合に、前記顧
   客による注文の識別情報の正当性を確認し、正当性が確
   認された場合には当該顧客による注文に対して売上確定
   を前記記憶装置に登録し且つ注文代金請求処理を実施す
   る請求処理手段と、を有するコンピュータ・システム。
2. 【請求項２】顧客認証要求に係る、顧客の端末の情報と
   店舗情報と少なくとも当該顧客による注文の識別情報と
   を受信した場合に、第１のキーを生成して当該第１のキ
   ーを前記顧客の端末に送信する認証確認手段と、 前記顧客の端末から前記第１のキーを受信すると当該第
   １のキーの正当性確認処理を実施し、前記顧客の端末か
   ら当該顧客の認証用情報を受信すると前記顧客に対する
   認証処理を実施し、前記第１のキーの正当性確認処理結
   果及び前記顧客に対する認証処理結果が肯定的である場
   合に第２のキーを生成して、前記店舗のコンピュータに
   当該第２のキー及び前記顧客による注文の識別情報を送
   信する顧客認証手段と、 前記店舗のコンピュータから前記第２のキーと前記店舗
   の認証用情報と前記顧客による注文の内容情報とを受信
   した場合、前記第２のキーの正当性確認処理と、前記店
   舗に対する認証処理と、予め登録されている前記顧客の
   情報を用いた前記顧客の与信処理とを実施し、前記第２
   のキーの正当性確認処理、前記店舗に対する認証処理及
   び前記顧客の与信処理の結果が肯定的である場合に前記
   顧客による注文の内容情報を記憶装置に登録し、前記店
   舗のコンピュータに前記顧客による注文の内容情報に対
   する登録識別情報を送信する与信処理手段と、 前記店舗のコンピュータから注文代金請求依頼に係る前
   記登録識別情報を受信した場合に、前記登録識別情報の
   正当性を確認し、正当性が確認された場合には当該顧客
   による注文に対して売上確定を前記記憶装置に登録し且
   つ注文代金請求処理を実施する請求処理手段と、 を有するコンピュータ・システム。
3. 【請求項３】前記請求処理手段が、前記注文代金請求依
   頼に係る前記店舗の認証用情報を受信して、前記店舗に
   対する認証処理を行うことを特徴とする請求項１又は２
   記載のコンピュータ・システム。
4. 【請求項４】前記請求処理手段は、前記店舗のコンピュ
   ータに、 前記顧客による注文の識別情報又は前記登録識別情報の
   正当性が確認されない場合、注文代金請求に失敗した旨
   の通知を送信し、 前記注文代金請求処理に成功した場合には、注文代金請
   求に成功した旨の通知を送信することを特徴とする請求
   項１又は２記載のコンピュータ・システム。
5. 【請求項５】顧客認証要求に係る、顧客の端末の情報と
   店舗情報と少なくとも当該顧客による注文の識別情報と
   を受信した場合に、第１のキーを生成して当該第１のキ
   ーを前記顧客の端末に送信するステップと、 前記顧客の端末から前記第１のキーを受信すると当該第
   １のキーの正当性確認処理を実施し、前記顧客の端末か
   ら当該顧客の認証用情報を受信すると前記顧客に対する
   認証処理を実施し、前記第１のキーの正当性確認処理結
   果及び前記顧客に対する認証処理結果が肯定的である場
   合に第２のキーを生成して、前記店舗のコンピュータに
   当該第２のキー及び前記顧客による注文の識別情報を送
   信するステップと、 前記店舗のコンピュータから前記第２のキーと前記店舗
   の認証用情報と前記顧客による注文の内容情報とを受信
   した場合、前記第２のキーの正当性確認処理と、前記店
   舗に対する認証処理と、予め登録されている前記顧客の
   情報を用いた前記顧客の与信処理とを実施し、前記第２
   のキーの正当性確認処理、前記店舗に対する認証処理及
   び前記顧客の与信処理の結果が肯定的である場合に前記
   顧客による注文の内容情報を記憶装置に登録し、前記店
   舗のコンピュータに前記顧客による注文の内容情報の登
   録可否を示す情報及び前記顧客による注文の識別情報と
   を送信するステップと、 前記店舗のコンピュータから注文代金請求依頼に係る前
   記顧客による注文の識別情報を受信した場合に、前記顧
   客による注文の識別情報の正当性を確認し、正当性が確
   認された場合には当該顧客による注文に対して売上確定
   を前記記憶装置に登録し且つ注文代金請求処理を実施す
   るステップと、 を含む注文代金請求処理方法。
6. 【請求項６】顧客認証要求に係る、顧客の端末の情報と
   店舗情報と少なくとも当該顧客による注文の識別情報と
   を受信した場合に、第１のキーを生成して当該第１のキ
   ーを前記顧客の端末に送信するステップと、 前記顧客の端末から前記第１のキーを受信すると当該第
   １のキーの正当性確認処理を実施し、前記顧客の端末か
   ら当該顧客の認証用情報を受信すると前記顧客に対する
   認証処理を実施し、前記第１のキーの正当性確認処理結
   果及び前記顧客に対する認証処理結果が肯定的である場
   合に第２のキーを生成して、前記店舗のコンピュータに
   当該第２のキー及び前記顧客による注文の識別情報を送
   信するステップと、 前記店舗のコンピュータから前記第２のキーと前記店舗
   の認証用情報と前記顧客による注文の内容情報とを受信
   した場合、前記第２のキーの正当性確認処理と、前記店
   舗に対する認証処理と、予め登録されている前記顧客の
   情報を用いた前記顧客の与信処理とを実施し、前記第２
   のキーの正当性確認処理、前記店舗に対する認証処理及
   び前記顧客の与信処理の結果が肯定的である場合に前記
   顧客による注文の内容情報を記憶装置に登録し、前記店
   舗のコンピュータに前記顧客による注文の内容情報に対
   する登録識別情報を送信するステップと、 前記店舗のコンピュータから注文代金請求依頼に係る前
   記登録識別情報を受信した場合に、前記登録識別情報の
   正当性を確認し、正当性が確認された場合には当該顧客
   による注文に対して売上確定を前記記憶装置に登録し且
   つ注文代金請求処理を実施するステップと、 を含む注文代金請求処理方法。
7. 【請求項７】顧客認証要求に係る、顧客の端末の情報と
   店舗情報と少なくとも当該顧客による注文の識別情報と
   を受信した場合に、第１のキーを生成して当該第１のキ
   ーを前記顧客の端末に送信するステップと、 前記顧客の端末から前記第１のキーを受信すると当該第
   １のキーの正当性確認処理を実施し、前記顧客の端末か
   ら当該顧客の認証用情報を受信すると前記顧客に対する
   認証処理を実施し、前記第１のキーの正当性確認処理結
   果及び前記顧客に対する認証処理結果が肯定的である場
   合に第２のキーを生成して、前記店舗のコンピュータに
   当該第２のキー及び前記顧客による注文の識別情報を送
   信するステップと、 前記店舗のコンピュータから前記第２のキーと前記店舗
   の認証用情報と前記顧客による注文の内容情報とを受信
   した場合、前記第２のキーの正当性確認処理と、前記店
   舗に対する認証処理と、予め登録されている前記顧客の
   情報を用いた前記顧客の与信処理とを実施し、前記第２
   のキーの正当性確認処理、前記店舗に対する認証処理及
   び前記顧客の与信処理の結果が肯定的である場合に前記
   顧客による注文の内容情報を記憶装置に登録し、前記店
   舗のコンピュータに前記顧客による注文の内容情報の登
   録可否を示す情報及び前記顧客による注文の識別情報と
   を送信するステップと、 前記店舗のコンピュータから注文代金請求依頼に係る前
   記顧客による注文の識別情報を受信した場合に、前記顧
   客による注文の識別情報の正当性を確認し、正当性が確
   認された場合には当該顧客による注文に対して売上確定
   を前記記憶装置に登録し且つ注文代金請求処理を実施す
   るステップと、 をコンピュータに実行させるためのプログラム。
8. 【請求項８】顧客認証要求に係る、顧客の端末の情報と
   店舗情報と少なくとも当該顧客による注文の識別情報と
   を受信した場合に、第１のキーを生成して当該第１のキ
   ーを前記顧客の端末に送信するステップと、 前記顧客の端末から前記第１のキーを受信すると当該第
   １のキーの正当性確認処理を実施し、前記顧客の端末か
   ら当該顧客の認証用情報を受信すると前記顧客に対する
   認証処理を実施し、前記第１のキーの正当性確認処理結
   果及び前記顧客に対する認証処理結果が肯定的である場
   合に第２のキーを生成して、前記店舗のコンピュータに
   当該第２のキー及び前記顧客による注文の識別情報を送
   信するステップと、 前記店舗のコンピュータから前記第２のキーと前記店舗
   の認証用情報と前記顧客による注文の内容情報とを受信
   した場合、前記第２のキーの正当性確認処理と、前記店
   舗に対する認証処理と、予め登録されている前記顧客の
   情報を用いた前記顧客の与信処理とを実施し、前記第２
   のキーの正当性確認処理、前記店舗に対する認証処理及
   び前記顧客の与信処理の結果が肯定的である場合に前記
   顧客による注文の内容情報を記憶装置に登録し、前記店
   舗のコンピュータに前記顧客による注文の内容情報に対
   する登録識別情報を送信するステップと、 前記店舗のコンピュータから注文代金請求依頼に係る前
   記登録識別情報を受信した場合に、前記登録識別情報の
   正当性を確認し、正当性が確認された場合には当該顧客
   による注文に対して売上確定を前記記憶装置に登録し且
   つ注文代金請求処理を実施するステップと、 をコンピュータに実行させるためのプログラム。