JP2003085146A - 情報処理装置、情報処理用プログラムを格納する記憶媒体および情報処理用コンピュータプログラム - Google Patents

Abstract

(57)【要約】 【課題】 登録しているオンラインショッピングモール
以外のモールについても、簡単な手続で、同一の決済処
理により利用できような、オンラインショッピングシス
テムを提供する。 【解決手段】 ユーザ２００は、予め設定されている仮
のＩＤを用いて、登録していない他のオンラインショッ
プ４００をアクセスする。商品を購入した場合には、オ
ンラインショップ４００がマネーゲート５００に受注デ
ータを送信し、マネーゲート５００からの要求に応じて
ユーザが登録しているモール事業者３００が決済に係わ
るクレジット番号などの情報をマネーゲート５００に送
信し、これらがマネーゲート５００で合わされて最終的
な受注データが生成され、これによりカード会社６００
に対して決済処理が行なわれる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、たとえばオンライ
ンショッピングなどのインターネットを介した商取引に
関する決済仲介処理装置、決済仲介処理用の処理プログ
ラムを格納する記憶媒体、決済仲介用のコンピュータプ
ログラム、オンラインショップ装置、オンラインショッ
ピング方法およびオンラインショッピングシステムに関
する。

【０００２】

【従来の技術】これまでのオンラインショッピングの処
理の流れを図３６に示す。

【０００３】いずれかのオンラインモールに登録してい
る会員（ユーザ）が、そのモールのホームページにアク
セスすると、通常はそこにナビゲーションページがあ
り、モールから各加盟店のホームページにリンクされて
いる。

【０００４】この各加盟店のホームページでユーザが、
商品の申込みを行なうと（１）、この注文データは加盟
店に届く（２）。加盟店では、伝票を作成し、仮想モー
ルのデベロッパたるモール事業者に通知する（３）。

【０００５】モール事業者は、会員に確認メールを発信
し、会員が購入の申込みをしたことの確認をとる
（４）。そして、会員が、購入の確認の信号を送信する
と（５）、ＩＤ、パスワードで対応が付けられたクレジ
ットカード番号がモール事業者サーバの中に格納されて
いて、このカード番号が決済機関の決済システムに入力
され、このシステムを介してカード会社に通知され、カ
ード会社では、オーソリゼイションされる（６）。

【０００６】オーソリゼイションがＯＫならば、与信結
果がモール事業者に返信され（６）、その結果が会員に
与信結果として（７）、および、加盟店に売上承認連絡
（８）として、各々通知される。

【０００７】加盟店は、商品を会員に発送するとともに
（９）、売上データをモール事業者サーバにアップロー
ドすることにより、売上確定処理を行ない（１０）、モ
ール事業者は、各加盟店から入力される売上データをま
とめて、決済機関の決済システムに入力する（１１）。

【０００８】そして、決済システムは、この売上データ
に基づいて各カード会社ごとにクレジットデータを渡
し、各カード会社では、これに基づいて各会員に商品代
金を請求するとともに（１２）、商品代金を決済システ
ムを介してモール事業者に渡す（１１）。

【０００９】これにより各加盟店に対して売上代金が入
金され、資金決済が行われる（１３）。

【００１０】

【発明が解決しようとする課題】ところで、このような
これまでの電子商取引きシステムにおいては、各オンラ
インショップやモールにより決済手段が多種多様であり
各々独立している。そして、あるモールで発行されたＩ
Ｄとパスワードは、そのモール内でしか使用できない。
そのため、いろいろなオンラインショップやモールを利
用したいユーザは、複数のショップやモールに何度も個
人情報、カード番号などを入力しユーザ登録をしなけれ
ばならない。

【００１１】そして、その結果、手続きが面倒である上
に、管理すべきＩＤやパスワードが増加するという問題
が発生している。

【００１２】また、このような手続きを何度も繰り返す
ことにより、カード情報の漏洩の危険性が増大するとい
う問題も生じている。

【００１３】したがって本発明の目的は、複数のシステ
ムで商取引きを行なう場合においても、手続きが容易で
管理すべきＩＤやパスワードが増えることなく決済に係
わる秘密情報の漏洩の危険性が少なくなるような決済シ
ステムを実現する決済仲介処理装置を提供することにあ
る。

【００１４】また、本発明の他の目的は、自分が登録し
ているオンラインショップやモール以外のショップやモ
ールも、簡単な手続きで利用でき、管理すべきＩＤやパ
スワードが増えることなく決済に係わる秘密情報の漏洩
の危険性も少なくなるようなオンラインショッピングシ
ステムを提供するためのオンラインショップ装置を提供
することにある。

【００１５】さらに本発明の他の目的は、そのようなオ
ンラインショッピング方法およびオンラインシステムを
提供することにある。

【００１６】

【課題を解決するための手段】前記課題を解決するため
に、本発明の決済仲介処理装置は、ユーザからのネット
ワークを介した要求に応じて対価の支払いを伴う所定の
行為を行なう第１の装置より、前記所定の行為の要求に
係わる受注情報を受け付ける受注情報受付け手段と、前
記受け付けた受注情報に基づいて、ユーザが所定の方法
による金銭の支払いに係わる契約を行なっている第２の
装置より、当該ユーザが要求した前記所定の行為の対価
の支払いを当該ユーザより受けるための支払情報を獲得
する支払い情報獲得手段と、前記受け付けた受注情報お
よび前記獲得した支払情報に基づいて、前記ユーザが要
求した前記所定の行為の前記対価の決済を行なう決済処
理手段とを有する。

【００１７】好適には、前記ネットワークを介した要求
に応じて対価の支払いを伴う所定の行為は、任意の商品
の販売であり、前記受注情報受付け手段は、ネットワー
クを介して任意の商品を販売する第１の装置より、商品
の注文に係わる受注情報を受け付け、前記支払い情報獲
得手段は、前記受け付けた受注情報に基づいて、前記第
２の装置より、ユーザが注文した商品の対価の支払いを
当該ユーザより受けるための支払情報を獲得し、前記決
済処理手段は、受け付けた受注情報および前記獲得した
支払情報に基づいてユーザが購入した商品の対価の決済
を行なう。

【００１８】一例として、前記第１の装置および前記第
２の装置は、各々ユーザが所定の方法による金銭の支払
いに係わる契約を含む登録を行なっており、少なくとも
前記登録を行なっているユーザに対してネットワークを
介したアクセスを許可し、当該アクセスにより任意の商
品を販売する複数の商品販売手段の、各々いずれかであ
り、前記受注情報受付け手段は、複数の前記商品販売手
段のいずれかより、少なくとも当該商品販売手段以外の
前記商品販売手段に前記登録をしているユーザからの商
品の注文に係わる受注情報を受け付け、前記支払い情報
獲得手段は、前記受け付けた受注情報に基づいて、当該
ユーザが前記登録をしている前記商品販売手段より、当
該ユーザが注文した商品の対価の支払いを当該ユーザよ
り受けるための支払情報を獲得する。

【００１９】別の一例として、前記第１の装置と前記第
２の装置とは、それぞれ、前記ネットワークを介したア
クセスにより商品を販売するオンラインショップ手段
と、前記オンラインショップ手段に対する前記ネットワ
ークを介したアクセスを制御するオンラインショップ管
理手段との、いずれか一方である。

【００２０】別の面から見た本発明の決済仲介処理装置
は、第１のサイトで商品の購入を行なおうとするユーザ
から、そのユーザ自身が会員登録をしている別の第２の
サイトでのそのユーザの個人特定情報の入力を受け付け
る手段と、入力された前記個人特定情報を前記第２のサ
イトに送信し、個人特定の結果および決済に必要な情報
をその第２のサイトから入手する手段と、を具備する。

【００２１】さらに別の面から見た本発明の決済仲介処
理装置は、第１のサイトで商品の購入を行なおうとする
ユーザから、そのユーザ自身が会員登録をしている別の
第２のサイトでのそのユーザの個人特定情報および決済
に必要な情報の入力を受け付ける手段と、入力された前
記個人特定情報を前記第２のサイトに送信し、個人特定
の結果をその第２のサイトから入手する手段と、を具備
する。

【００２２】さらに別の面から見た本発明の決済仲介処
理装置は、第１のサイトで商品の購入を行なおうとする
ユーザから、そのユーザ自身の個人特定を行ないうる第
２のサイトの選択入力を受け付ける手段と、選択された
前記第２のサイトに対してそのユーザの個人特定結果の
返信を要求し、返信された個人特定結果に基づいて決済
処理を行なう手段と、を具備する。

【００２３】このような別の面から見た本発明の決済仲
介処理装置において、前記第２のサイトは、一例とし
て、前記ネットワークを介したアクセスにより商品を販
売するオンラインショップのサイト、あるいは、前記オ
ンラインショップのサイトに対する前記ネットワークを
介したアクセスを制御するオンラインショップの管理サ
イトである。

【００２４】ここで、本発明の決済仲介処理装置におい
て、前記第２の装置（第２のサイト）の運営者および当
該決済仲介処理装置の運営者を含む当該商品の販売に係
わる運営者に対して、手数料を支払う処理を行なう手数
料支払い処理手段をさらに有しても良く、この場合、一
例として、前記手数料支払い処理手段は、前記決済を行
なった商品の対価の一部を前記手数料に充当する。

【００２５】また、前記第１の装置（第１のサイト）ご
とに、前記第２の装置（第２のサイト）に前記登録を行
なっているユーザによる前記第１の装置（第１のサイ
ト）へのアクセスを可能にするための実際とは異なるユ
ーザ情報を前記第２の装置（第２のサイト）ごとに記憶
しておき、その実際とは異なるユーザ情報のユーザ入力
に応じて前記第１の装置（第１のサイト）へのアクセス
を可能にするアクセス情報提供手段をさらに有しても良
い。この場合、一例として、前記実際とは異なるユーザ
情報は、当該決済仲介処理装置のユーザＩＤを含む。

【００２６】また、前記支払い情報獲得手段は、前記受
け付けた受注情報に基づいて、前記第２の装置（第２の
サイト）より、ユーザが注文した商品の対価の支払いを
当該ユーザのクレジットカードにより決済をするため
の、クレジットカード番号を含む前記支払情報を獲得
し、前記決済処理手段は、前記受注情報および前記支払
情報に基づいて、当該ユーザのクレジットカードに係わ
るクレジットカード会社より、前記ユーザが購入した商
品の対価の支払いを受けるための処理を実行するように
しても良い。

【００２７】また、一例として、前記支払い情報獲得手
段（個人特定の結果および決済に必要な情報をその第２
のサイトから入手する手段）は、前記受け付けた受注情
報に含まれる受注番号と、前記獲得した支払情報に含ま
れる受注番号とに基づいて、これらの情報を対応付け
る。

【００２８】さらに、前記第１の装置（第１のサイト）
に支払方法の選択入力を許容する支払方法選択画面を提
供する支払方法入力表示手段と、この支払方法入力表示
手段によって当該決済仲介処理装置による決済が選択入
力された場合にのみ当該決済仲介処理装置の機能を実行
させる決済仲介実行手段と、を設けても良い。

【００２９】別の一例として、前記ネットワークを介し
てアクセスする前記ユーザの装置に対して、当該決済仲
介処理装置によって決済仲介処理が可能である前記商品
販売手段（第１のサイト）のリストを選択可能に表示さ
せるリスト表示手段と、選択された前記商品販売手段
（第１のサイト）に前記ユーザの装置をアクセスさせる
自動アクセス手段と、を設けても良い。

【００３０】さらに別の一例として、当該決済仲介処理
装置によって決済仲介処理が可能である前記商品販売手
段（第１のサイト）が販売する商品に１又は２以上の検
索キーワードを対応させて記憶する検索キーワード記憶
手段と、前記ネットワークを介してアクセスする前記ユ
ーザの装置に検索キーワード入力用のダイアログボック
スを表示させる検索キーワード入力手段と、この検索キ
ーワード入力手段によって入力された検索キーワードに
基づいて前記検索キーワード記憶手段から対応する前記
商品販売手段（第１のサイト）を検索し、検索された前
記商品販売手段（第１のサイト）に前記ユーザの装置を
アクセス可能とさせる第２の自動アクセス手段と、を設
けても良い。

【００３１】ここで、本発明の決済仲介処理装置は、実
質的にはネットワークを介してアクセス可能なコンピュ
ータである。そこで、本発明の決済仲介処理装置が奏す
る機能を実行するコンピュータプログラムを格納する記
憶媒体またはコンピュータプログラムとして規定するこ
ともできる。

【００３２】また、本発明のオンラインショップ装置
は、ネットワークを介したアクセスにより任意の商品を
販売するオンラインショップを登録し管理するショップ
管理手段と、ユーザとの間で金銭の支払いに係わる契約
を含む登録処理を行ない、当該登録されたユーザに対し
て前記登録したオンラインショップヘのアクセスを許可
するユーザ管理手段とを有するオンラインショップ装置
であって、前記ユーザ管理手段は、他のオンラインショ
ップ管理装置に前記登録を行なっているユーザが、当該
ユーザが購入した商品の対価の支払いを当該ユーザが登
録している前記他のオンラインショップ装置より当該ユ
ーザの所定の支払情報を獲得し決済を行なう決済仲介処
理装置を介してアクセスしてきた場合に、当該ユーザか
らの前記登録したオンラインショップヘのアクセスを許
可する。

【００３３】また、本発明の他のオンラインショップ装
置は、ネットワークを介したアクセスにより任意の商品
を販売するオンラインショップを登録し管理するショッ
プ管理手段と、ユーザとの間で金銭の支払いに係わる契
約を含む登録処理を行ない、当該登録されたユーザに対
して前記登録したオンラインショップヘのアクセスを許
可するユーザ管理手段とを有するオンラインショップ装
置であって、前記ユーザ管理手段は、前記登録されたユ
ーザが他の前記オンラインショップ装置により管理され
ているオンラインショップで商品を購入した場合で、当
該ユーザが購入した商品の対価の決済を仲介して行なう
決済仲介処理装置より要求があった場合には、当該ユー
ザの前記金銭の支払いに係わる契約に基づく当該ユーザ
が決済を行なうための所定の支払い情報を前記決済仲介
処理装置に提供する。

【００３４】また、本発明のオンラインショッピング方
法は、ネットワーク上に設けられた任意のオンラインシ
ョップにおいて、ネットワークを介してアクセスしてき
た任意のユーザが出した商品の注文に基づいて、受注情
報を生成し、該生成した受注情報を決済仲介処理装置に
送信し、前記決済仲介処理装置において、当該商品の注
文を行なったユーザが登録しているオンラインショップ
装置より、当該ユーザから支払いを受けるための所定の
支払い情報を獲得し、前記獲得した支払い情報に基づい
て前記ユーザに対して決済を行ない、前記決済を行なっ
た当該商品の対価に対する所定の手数料を、少なくとも
前記オンラインショップおよび前記決済仲介処理装置に
支払い、該手数料を支払った残りを前記オンラインショ
ップに支払う。

【００３５】また、本発明のオンラインショッピングシ
ステムは、ネットワークを介したアクセスにより任意の
商品を販売する複数のオンラインショップと、前記オン
ラインショップを登録し管理するショップ管理手段と、
ユーザとの間で金銭の支払いに係わる契約を含む登録処
理を行ない、当該登録されたユーザに対して前記登録し
たオンラインショップヘのアクセスを許可するユーザ管
理手段とを有するオンラインショップ装置であって、他
のオンラインショップ管理装置に前記登録を行なってい
るユーザが、決済仲介処理装置を介してアクセスしてき
た場合に、当該ユーザからの前記登録したオンラインシ
ョップヘのアクセスを許し、前記登録されたユーザが他
の前記オンラインショップ装置により管理されているオ
ンラインショップで商品を購入した場合に当該ユーザが
決済を行なうための所定の支払い情報を前記決済仲介処
理装置に提供する、複数のオンラインショップ装置と、
任意の前記オンラインショップ装置より受注情報を受付
ける受注情報受付け手段と、前記受け付けた受注情報に
基づいてユーザが登録を行なっている前記オンラインシ
ョップ装置より対価の支払いを当該ユーザより受けるた
めの支払情報を獲得する支払い情報獲得手段と、前記受
け付けた受注情報および前記獲得した支払情報に基づい
て、前記ユーザが要求した前記所定の行為の前記対価の
決済を行なう決済処理手段とを有する決済仲介処理装置
とを有する。

【００３６】

【発明の実施の形態】本発明の一実施の形態について、
図１〜図２６を参照して説明する。

【００３７】本実施の形態においては、複数のオンライ
ンショッピングモール（以後、単にモールという）が通
信ネットワーク上に展開されており、いずれかのモール
の会員であれば他のモールに新たに登録しなくとも他の
モールでオンラインショッピングができるようなオンラ
インショッピングシステムについて説明する。

【００３８】最初に、本実施の形態では、複数の項目毎
にオンラインショッピングシステムを説明する。そこ
で、これらの項目の目次を次に列挙する。

【００３９】−目次− Ａ．概要説明 （１）基本的な構成 （２）基本的な動作 ．商品購入時の動作 ．売上・決済処理 Ｂ．詳細説明 （１）構成例 （２）動作、処理の流れ ．物品の販売 ．デジタルコンテンツの販売 ａ）認証サイトがユーザのクレジットカード番号を認識
していない場合 ｂ）認証サイトがユーザのクレジットカード番号を認識
している場合 （３）各サイト間の通信 ．マネーゲートの基本形態において登録事業者サイト
と販売サイトとが同一である場合のサイト間通信 ．マネーゲートの基本形態において登録事業者サイト
と販売サイトとが異なる場合のサイト間通信 ．ショッピングスイッチ受付サービス利用形態におい
て登録事業者サイトと販売サイトとが同一である場合の
サイト間通信 ．ショッピングスイッチ受付サービス利用形態におい
て登録事業者サイトと販売サイトとが異なる場合のサイ
ト間通信 （４）まとめ 以上列挙したような項目に沿って、以下、本実施の形態
について説明する。

【００４０】Ａ．概要説明 （１）基本的な構成 まず、本実施の形態のオンラインショッピングシステム
の基本的な構成について図１〜図４を参照して説明す
る。

【００４１】図１は、そのようなオンラインショッピン
グシステムの基本的な構成を示す図である。

【００４２】オンラインショッピングシステム１００
は、ユーザ２００、モール事業者３００（第１の装置、
第１のサイト、第２の装置、第２のサイト、商品販売装
置、オンラインショップ手段、オンラインショップ管理
手段）、オンラインショップ４００（第１の装置、第１
のサイト、第２の装置、第２のサイト、商品販売装置、
オンラインショップ手段、オンラインショップ管理手
段）、マネーゲート５００（決済仲介処理装置）、カー
ド会社６００および通信ネットワーク７００、７１０、
７２０を、その基本的な構成として有する。

【００４３】ここで、ユーザ２００、モール事業者３０
０、オンラインショップ４００、マネーゲート５００お
よびカード会社６００は、少なくとも文言上その一部が
自然人や法人等として表現されているが、これらは、商
取引の場面においては自然人や法人等を意味し、その機
能が実行される場面においてはそれらの自然人や法人等
が所有し操作したりするコンピュータを意味している。
つまり、それらのユーザ２００、モール事業者３００、
オンラインショップ４００、マネーゲート５００および
カード会社６００は、その機能が実行される場面におい
ては、記憶媒体としての記憶装置に格納された動作プロ
グラム等に基づいてプロセッサがデータ処理を実行する
コンピュータである。そこで、後述する各種の手段は、
記憶装置に格納された動作プログラム等に基づくプロセ
ッサにより実行される各種の機能によって実行される。
なお、動作プログラムであるコンピュータプロラムを格
納する記憶媒体としては、コンピュータの記憶装置に限
らず、例えば、ＣＤ−ＲＯＭを典型とする可搬性を有す
る記憶媒体にパッケージングされていても良い。

【００４４】ユーザ２００は、商取引の場面において
は、通信ネットワーク７００を介して実際にオンライン
ショップ４００において商品を購入する主に一般個人の
ユーザである。

【００４５】ユーザ２００は、商取引の場面において
は、通信ネットワーク７００を介してモール事業者３０
０が開設しているモールあるいはオンラインショップ４
００が開設しているショップをアクセスすることが可能
な環境を有し、複数のモール事業者３００の少なくとも
いずれか１つのモールに登録した会員であって、モール
事業者３００が料金の支払いに対して保証しているユー
ザである。

【００４６】通常、ユーザ２００は、その機能が実行さ
れる場面においては、通信ネットワーク７００の任意の
ノードに接続されたパーソナルコンピュータなどにより
構成される。

【００４７】モール事業者３００は、商取引の場面にお
いては、ローカルな個々のインターネット・サービス・
プロバイダ（ＩＳＰ）、換言すれば個々のオンラインシ
ョッピングモールの開設者であり、オンラインショッピ
ングのプラットフォームであるモールなどをインターネ
ット７００上に展開し、オンラインショップの開設希望
者およびオンラインショップのユーザ双方に、オンライ
ンショップサービスを提供する。

【００４８】具体的には、モール事業者３００は、その
機能が実行される場面においては、開設したモールヘ出
店するオンラインショップ４００の管理を行なう（ショ
ップ管理手段）。

【００４９】また、モール事業者３００は、その機能が
実行される場面において、会員登録したユーザ２００
を、利用者データベースの形で記憶し管理する（ユーザ
管理手段）。

【００５０】また、その機能が実行される場面におい
て、モール事業者３００によっては、開設するモール内
のオンラインショップ４００における受注を管理する場
合もある。そのような場合には、モール事業者３００
は、たとえば受注データベースによる全受注データの管
理、ユーザ２００への注文の確認、決済機関へのオーソ
リ要求など、オンラインショッピング全般に渡る種々の
処理を行なう。

【００５１】また、オンラインショッピングシステム１
００においては、各モールに登録しているユーザ２００
は、後述するマネーゲート５００を介することにより、
登録をしていない他のモールにおいても買い物ができる
ようになっており、そのようなシステムを実現するため
に、各モール事業者３００は次のような処理を行なう。
ここでの処理は、いうまでもなくコンピュータによる処
理である。

【００５２】まず、マネーゲート５００を介したショッ
ピングを認める他のモールの会員用に、その会員を自分
のモールの会員として扱うためのＩＤなどの情報を他の
モールごとに発行し、利用者マスタに登録しておく。

【００５３】具体的に図２を参照して説明する。

【００５４】今、相互にマネーゲート５００を介したシ
ョッピングを求める３つのモールＡ〜モールＣがあった
とすると、各モールのモール事業者３００は、自分以外
の他のモールに対してＩＤ、パスワードおよびダミーの
クレジットカード番号を設定しておく。

【００５５】たとえば、モールＡのモール事業者３００
ａは、モールＢの会員用に、「mlb＠mg2」というＩＤ、
「12345678」というパスワード、「111100000002」とい
うダミーのクレジット番号を、また、モールＣの会員用
に、「mlc＠mg2」というＩＤ、「12345678」というパス
ワード、「111100000003」というダミーのクレジット番
号を各々発行し、自らの会員ＩＤに記憶しておく。これ
らのＩＤ、パスワードおよびクレジット番号は、仮のま
たは実際とは異なるＩＤ、パスワードおよびクレジット
番号となる。

【００５６】なお、マネーゲート５００を介したアクセ
スのためのこれらのＩＤを、マネーゲートＩＤというも
のとする。

【００５７】また、これら各モール事業者３００で発行
された情報は、後述するマネーゲート５００の、各モー
ル事業者の属性情報へリンクを張ったＷｅｂ画面の登録
管理を行なうためのコレットサーバ５１０（図１参照）
においても、図４に示すような事業者マスタの形態で登
録される。つまり、マネーゲート５００のコレットサー
バ５１０においては、各ユーザ２００について、モール
事業者毎に、仮のまたは実際とは異なるＩＤ、パスワー
ドおよびクレジット番号を記憶しておく。これにより、
各モール事業者３００からＩＤ、パスワードおよびクレ
ジット番号がコレットサーバ５１０に送信された場合、
それらのＩＤ、パスワードおよびクレジット番号という
属性情報が仮のまたは実際とは異なるものであるとして
も、コレットサーバ５１０においては、それらの属性情
報がどのユーザ２００の属性情報であるかを認識するこ
とができる。

【００５８】また、モール事業者３００は、そのような
他のモール会員用のＩＤを用いた、当該他のモールの会
員からのモールヘのアクセスを受け付け、モール内のオ
ンラインショップ４００でのショッピングを可能にす
る。

【００５９】そして、そのような他のモールの会員から
モール内のショップが受注を受けた場合には、モール事
業者３００は、ユーザ２００に対する注文の確認を行な
った後、これをマネーゲート５００に通知する。そし
て、マネーゲート５００より受注の承認が得られた場合
に、受注処理を行ない、オンラインショップ４００に対
する出荷依頼などを行なう。

【００６０】さらに、モール事業者３００が管理する会
員が他のモールでショッピングを行なった場合には、マ
ネーゲート５００より本人認証リクエストが送られるの
で、それに基づいて認証を行ない、クレジットカード番
号などの決済に係わる情報をマネーゲート５００に送信
する。

【００６１】そのため、モール事業者３００は、たとえ
ば図３に示すようなポップアップ画面をウェブサーバに
格納しておき、マネーゲート５００よりリクエストが送
られてきた時には、このポップアップ画面をユーザ２０
０の画面上に立ち上げる。

【００６２】なお、モール事業者３００とマネーゲート
５００との間の通信路７１０は、セキュアな通信が行な
える必要があり、専用線か、ＳＳＬ（Ｓｅｃｕｒｅ Ｓ
ｏｃｋｅｔ Ｌａｙｅｒ）でデータを送る仕組みを持つ
ことが必要である。

【００６３】モール事業者３００は、このように、ショ
ップ４００とユーザ２００およびマネーゲート５００の
間で、オンラインショッピングが適切に行なえるように
種々の処理を行なう。

【００６４】オンラインショップ４００は、モール事業
者３００が提供する環境上にショップを開設し、通信ネ
ットワーク７００を介して、ユーザ２００に対して、物
品やデジタルコンテンツなどの任意の商品をオンライン
販売する。

【００６５】そしてオンラインショップ４００は、実質
的にマネーゲート５００に対してオーソリ要求や資金決
済などの処理を行なう。この時モールの形態によって
は、モール事業者３００が仲介して一旦受注データを管
理した後、マネーゲート５００に対して処理するように
する場合もある。

【００６６】なお、このオンラインショップ４００自体
が、１つのモールを形成していてもよい。

【００６７】マネーゲート５００は、複数のモール事業
者３００による決済を統合して行なうための決済処理統
合機関である。

【００６８】まず、マネーゲート５００は、各モール事
業者３００に割り振った事業者の属性情報へのリンクを
張ったＷｅｂ画面（以後、これをコレットあるいはコレ
ットオブジェクトという）の登録管理を行なうコレット
サーバ５１０を有しており、ユーザ２００が、自分が登
録しているモール以外のモールにおいても容易に商品を
注文できるようにしている。つまり、コレットは、ユー
ザ２００のコンピュータにおいては、そのユーザ２００
の属性情報を含む独自のコレットとして自らのコンピュ
ータ内に保有されており、コレットオブジェクトとして
ユーザ２００の画面上に出現させることができる。この
コレットオブジェクトには、アクセス可能なモール事業
者３００やオンラインショップ４００ごとに仮のまたは
実際とは異なるＩＤについての情報がリンク付けられて
いる。

【００６９】コレットサーバ５１０には、前述したよう
に、各モール事業者３００が発行した他のモールに対す
るＩＤなどの情報、すなわち、図４に示すような、各モ
ールの会員ごとに、名前、ダミークレジットカード番
号、パスワード、および、モール事業者３００ごとの使
用ＩＤおよびＵＲＬが記録されている事業者マスタが記
憶されている。モール事業者３００ごとのコレットは、
この事業者マスタを参照しながら、他のモールにおいて
注文を行なう場合に、所望の情報を所望のフィールドに
書き込む。

【００７０】具体的には、まず、ユーザ２００におい
て、ＵＲＬに基づいて事業者を判別し、使用するＩＤを
決定し、ユーザ２００によるコレットオブジェクトをド
ロップする操作などに基づいて、そのユーザ２００がア
クセスしているモール事業者３００やオンラインショッ
プ４００ではＩＤ、パスワードおよびクレジットカード
番号などを書き込むフィールドを検出し、書き込む。こ
れは、モール事業者３００やオンラインショップ４００
にアクセスしているユーザ２００の画面上に表示される
認証用のユーザ属性入力画面（図３参照）に対するユー
ザ２００の入力操作によって実行される。この場合、コ
ンピュータとしてのユーザ２００は、そのモール事業者
３００やオンラインショップ４００である事業者のＵＲ
Ｌを認識していることから、事業者を特定することがで
きる。そこで、そのような認証用のユーザ属性入力画面
中へのコレットオブジェクトのドロップ操作などによっ
て、ユーザ２００が保有するコレットは、特定された事
業者に応じて仮のまたは実際とは異なるＩＤ、パスワー
ドおよびクレジットカード番号を選択することができ、
この選択結果としての仮のまたは実際とは異なるＩＤ、
パスワードおよびクレジットカード番号をモール事業者
３００やオンラインショップ４００に送信するわけであ
る。そこで、ユーザ２００がアクセスしているモール事
業者３００やオンラインショップ４００は、そのような
仮のまたは実際とは異なるＩＤ、パスワードおよびクレ
ジットカード番号をコレットサーバ５１０に送信するこ
とになる。ここに、受注情報受付け手段の機能が実行さ
れる。

【００７１】コレットサーバ５１０は、他のモールで買
い物をしたユーザ２００個人のＩＤを得る処理の中で、
マネーゲート５００の受注管理サーバ５２０からの指示
に基づいて、ユーザ２００が登録しているモール事業者
３００を検出し、そのモール事業者３００に対して、ユ
ーザ２００に対してＩＤ・パスワード入力画面を提供し
個人特定および決済に必要なデータを獲得すべき旨の指
示を出す処理も行なう。ここに、アクセス情報提供手
段、支払い情報獲得手段の機能が実行される。

【００７２】もっとも、別の実施の形態として、ユーザ
２００がアクセスするモール事業者３００やオンライン
ショップ４００が提供する認証用のユーザ属性入力画面
には、そのユーザ２００が登録しているモール事業者３
００やオンラインショップ４００における個人特定情報
としてのユーザＩＤを入力するようにしても良い。入力
方法は、コレットオブジェクトのドラックや値数入力
等、その種類を問わない。この場合、コレットサーバ５
１０は、各ユーザ２００についてのユーザＩＤのリスト
を参照可能となっている。そのユーザＩＤのリストに
は、少なくとも、ユーザ２００とそのユーザ２００が登
録しているモール事業者３００やオンラインショップ４
００等の事業者を特定し得る情報とが対応付けられて含
まれている。そこで、ユーザ２００がアクセスしている
モール事業者３００やオンラインショップ４００は、そ
のユーザのユーザＩＤをコレットサーバ５１０に送信す
ることになる。ここに、受注情報受付け手段の機能が実
行される。そして、ユーザＩＤの送信を受けたコレット
サーバ５１０は、そのユーザ２００がどのモール事業者
３００やオンラインショップ４００に登録しているのか
をユーザＩＤのリストを参照して検索し、そのモール事
業者３００等に対して、ＩＤ・パスワード入力画面をユ
ーザ２００に提供して個人特定および決済に必要なデー
タを獲得すべき旨の指示を出す処理も行なう。ここに、
アクセス情報提供手段、支払い情報獲得手段の機能が実
行される。

【００７３】マネーゲート５００は、注文情報の管理を
行なう受注管理サーバ５２０を有しており、ユーザ２０
０、モール事業者３００およびオンラインショップ４０
０間の全ての決済処理を行なう（決済処理手段）。

【００７４】より具体的には、まず、この受注管理サー
バ５２０において、モール事業者３００より送信された
新たな注文情報より、新規に受注データを生成して登録
する。

【００７５】この受注データには、その注文がマネーゲ
ート５００を介して行なわれた場合、すなわち、ユーザ
２００が自分が登録しているモール以外のモールのショ
ップで行なった注文だった場合、ユーザ２００が登録し
ているモールのＩＤが記載されているのみでユーザ２０
０個人のＩＤやクレジットカード番号は記載されていな
い。そこで、受注管理サーバ５２０は、コレットサーバ
５１０に対して、前述したようにユーザ２００個人のＩ
Ｄを得るように指示を行なう。

【００７６】あるいは、別の実施の形態として、ユーザ
２００が自分が登録しているモール以外のモールのショ
ップで注文を行なった場合の受注データに、ユーザ２０
０が登録しているモール等でのユーザＩＤが記載されて
いる場合を想定する。この場合には、受注データに、ユ
ーザ２００が登録しているモール等でのユーザＩＤが記
録されているだけであり、ユーザ２００個人のクレジッ
トカード番号は記載されていない。そこで、この場合に
も、受注管理サーバ５２０は、コレットサーバ５１０に
対して、前述したようにユーザ２００個人のクレジット
カード番号を得るように指示を行なう。

【００７７】もっとも、さらに別の実施の形態として、
ユーザ２００がアクセスするモール事業者３００やオン
ラインショップ４００が提供する認証用のユーザ属性入
力画面には、そのユーザ２００が登録しているモール事
業者３００やオンラインショップ４００におけるユーザ
ＩＤに加えて、決済に必要な情報としてクレジットカー
ド番号を入力するようにしても良い。入力方法は、コレ
ットオブジェクトのドラックや値数入力等、その種類を
問わない。この場合、コレットサーバ５１０は、前述し
たような各ユーザ２００についてのユーザＩＤのリスト
を参照可能となっている。そこで、ユーザ２００がアク
セスしているモール事業者３００やオンラインショップ
４００は、そのユーザのユーザＩＤおよびクレジットカ
ード番号をコレットサーバ５１０に送信することにな
る。ここに、受注情報受付け手段の機能が実行される。
そして、ユーザＩＤおよびクレジットカード番号の送信
を受けたコレットサーバ５１０は、そのユーザ２００が
どのモール事業者３００やオンラインショップ４００に
登録しているのかをユーザＩＤのリストを参照して検索
し、そのモール事業者３００等に対して、ＩＤ入力画面
をユーザ２００に提供して個人特定に必要なデータを獲
得すべき旨の指示を出す処理も行なう。ここに、アクセ
ス情報提供手段、支払い情報獲得手段の機能が実行され
る。

【００７８】受注管理サーバ５２０は、最終的に、その
ユーザ２００が会員登録をしているモール事業者３００
より送信されるユーザ２００のＩＤ、クレジットカード
番号などの情報を、登録してある受注データに書き込
む。このようなユーザ２００が会員登録をしているモー
ル事業者３００への問い合わせ過程においては、ユーザ
に向けて、ユーザ特定情報および決済必要情報の入力を
促すダイアログを表示させても良い。この場合には、そ
のダイアログにおいて、ユーザ２００自らがユーザＩＤ
やパスワード、クレジットカード番号等の情報を入力
し、その情報をそのユーザ２００が登録しているモール
事業者３００等に問い合わせ、そのモール事業者３００
等においてユーザ確認を実行させ、これを受注管理サー
バ５２０に返信させる。あるいは、各ユーザに対応する
クレジットカード番号を各ユーザが会員登録しているモ
ール事業者３００等において認識している場合には、ユ
ーザ２００に対して、上述したようなダイアログにユー
ザＩＤやパスワード等のようなユーザ特定情報のみを入
力させ、その情報をそのユーザ２００が登録しているモ
ール事業者３００等に問い合わせ、そのモール事業者３
００等においてユーザ確認の実行とクレジットカード番
号の検索とを実行させるようにしても良い。その後、そ
のモール事業者３００からユーザ確認と決済に必要な情
報としてのクレジットカード番号との返信を受注管理サ
ーバ５２０に行なわせるようにする。

【００７９】このような処理を経た後、受注管理サーバ
５２０は、正規にクレジットカード番号などが書き込ま
れた受注データをカード会社６００に送信して、オーソ
リ要求を行なうとともに、オーソリ承認を受け取り、シ
ョップ４００側に注文了承、あるいは、キャンセルなど
の情報を送信する。

【００８０】なお、このオーソリ処理に関しては、受注
管理サーバ５２０は、モール事業者３００よりオーソリ
要求がある前に予めオーソリ要求を行ない、得られたオ
ーソリ結果を蓄積しておく。そして、後から来たモール
事業者３００のオーソリ要求に対しては、その受注番号
より対応するオーソリ結果を検出し、これを返信する。

【００８１】そして受注管理サーバ５２０は、販売した
代金の利益分配の処理を行なう（手数料支払い処理手
段）。

【００８２】たとえば、マネーゲート５００を介した販
売の場合には、カード会社６００より商品売上代金より
所定の割合の手数料が差し引かれた額の支払いが行なわ
れる。この支払いに対してマネーゲート５００は、ユー
ザ２００が登録しているモール事業者３００に、ユーザ
２００の紹介手数料として売上の所定の割合を支払い、
さらにオンラインショップ４００が開設されていたモー
ル事業者３００に対して売上の所定の割合の手数料を支
払い、また、自らも所定の割合の手数料を徴収し、残り
をオンラインショップ４００に支払う。

【００８３】カード会社６００は、マネーゲート５００
からの情報に基づいて、実際に決済処理を行なうもので
あり、これまでの構成と同じである。

【００８４】通信ネットワーク７００は、オンラインシ
ョッピングシステム１００のモールやショップ、購入者
などのノードが設けられ、オンラインショッピングシス
テム１００を展開する広域な通信ネットワークシステム
であって、本実施の形態においては、インターネットで
ある。以後、通信ネットワーク７００はインターネット
７００という。

【００８５】また、通信路７１０および通信路７２０
は、モール事業者３００とマネーゲート５００、およ
び、マネーゲート５００とカード会社６００との間の通
信ネットワークであって、各々セキュアな通信を行ない
得るような環境整備が必要である。

【００８６】したがって、専用線か、ＳＳＬ（Ｓｅｃｕ
ｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）でデータを送る仕組み
を持つことが必要である。

【００８７】前述したように、本発明の決済仲介処理に
おいては、あるモール事業者３００やオンラインショッ
プ４００に登録していないユーザ２００について、その
ユーザ２００が登録しているモール事業者３００等（第
２のサイト、認証サイト）からそのユーザ２００の認証
情報や決済に必要な情報を獲得し、そのユーザ２００に
登録していないモール事業者３００等（第１のサイト、
販売サイト）でのオンラインショッピングを可能にする
というものである。そこで、このような処理を可能にす
るためには、少なくとも、ユーザ２００個人を特定する
情報、そのユーザ２００が登録しているモール事業者３
００等を特定する情報、および、そのユーザ２００が決
済するのに必要な情報の獲得が必須となる。そこで、実
施に際しては、それらの各種の情報をどの段階で獲得す
るように構成するかを適宜設定することが可能である。
上述した本実施の形態の説明においても、その一部の組
み合わせを紹介したが、実施に際しては、そのような紹
介した組み合わせに限らず、各種の組み合わせが可能で
ある。

【００８８】ここで、上述したオンラインショッピング
の過程において、決済するのに必要な情報、例えばクレ
ジットカード番号の取り扱いに関しては、各種の形態が
実現可能である。一例として、モール事業者３００に対
するユーザ２００の登録に際し、あるいは登録後に、そ
のモール事業者３００に対するクレジットカード番号等
の通知が必要である場合には、そのモール事業者３００
は登録しているユーザ２００のクレジットカード番号等
の決済に必要な情報を予め獲得していることになる。そ
こで、このようなモール事業者３００が第２のサイトで
ある認証サイトとなる場合には、上述したオンラインシ
ョッピングの過程においてユーザ２００によるクレジッ
トカード番号等の入力が不要である。これに対し、登録
に際してあるいはその後にもユーザ２００からクレジッ
トカード番号等を要求しないモール事業者３００の場合
には、そのモール事業者３００が第２のサイトである認
証サイトとなるとすると、上述したオンラインショッピ
ングの過程においてユーザ２００によるクレジットカー
ド番号等の入力が必須となる。 （２）基本的な動作 次に、このような構成のオンラインショッピングシステ
ム１００の基本的な動作について、図５および図６を参
照して説明する。

【００８９】．商品購入時の動作 まず、ユーザ２００が商品を購入した際の動作につい
て、図５を参照して説明する。

【００９０】まず、ユーザ２００がオンラインショップ
４００の提供するＷｅｂページなどから商品を購入す
る、すなわち、商品の注文をオンラインショップ４００
に出すと（１）、オンラインショップ４００は、金額な
ど、カード会社６００に対するオーソリに必要なデータ
を有する受注データを生成し、その受注データをマネー
ゲート５００に送信する（２）。

【００９１】マネーゲート５００は、その受注データを
マネーゲート５００内の受注サーバに保持するととも
に、その受注データに付加されているＩＰアドレスおよ
びモール事業者３００のＩＤに基づいて、ユーザ２００
を特定し、そのユーザ２００に対して、ＩＤとパスワー
ドを要求する（３）。

【００９２】ユーザ２００がその要求に応えてＩＤとパ
スワードを入力することにより、その入力されたＩＤと
パスワードは、モール事業者３００に送信される
（４）。

【００９３】このＩＤとパスワードに基づいて、モール
事業者３００において認証処理が行われて適正なユーザ
２００であることが確認されたら、モール事業者３００
は、そのＩＤとパスワードからクレジットデータを求め
て、そのクレジットデータをマネーゲート５００に送信
する（５）。この時のモール事業者３００からマネーゲ
ート５００へのクレジットデータの送信は、インターネ
ットを介さずに専用線を介して行なう。

【００９４】マネーゲート５００は、モール事業者３０
０より入力されたクレジットデータを、受注サーバに記
憶されているオンラインショップ４００より入力された
受注データに書き込み、カード会社６００に対してオー
ソリ要求を行なう（６）。

【００９５】カード会社６００は、その要求に基づいて
オーソリを行ない、オーソリ結果をマネーゲート５００
に返信する（７）。

【００９６】マネーゲート５００は、返信されたオーソ
リ結果に基づく受注処理を行なうか否かの決定を、一旦
オンラインショップ４００に送信し（８）、オンライン
ショップ４００は、その結果を見て、最終的にマネーゲ
ート５００に対してオーソリ要求を行なう（９）。この
オーソリ要求に対しては、マネーゲート５００は、これ
をカード会社６００まで飛ばすことをせず、既にマネー
ゲート５００が保持しているオーソリ結果をオンライン
ショップ４００に対して返信する（１０）。

【００９７】そして、このオーソリ結果に基づいて、オ
ンラインショップ４００はユーザ２００に注文が完了し
た旨の結果を通知し、商品を発送する（１１）。

【００９８】．売上・決済処理 次に、締め日などに行なう売上・決済処理の動作につい
て、図６を参照して説明する。

【００９９】まず、各オンラインショップ４００は、売
上データをマネーゲート５００に送信する（１）。

【０１００】マネーゲート５００においては、受注サー
バに保持している受注データと送信された売上データと
を照合して、売上データにクレジット番号を入れ、クレ
ジット番号を入れた売上データをカード会社６００に送
信し、代金請求を行なう（２）。

【０１０１】これによりカード会社６００は、ユーザ２
００に対して代金を請求し（３）、支払いを受ける
（４）。

【０１０２】そして、カード会社６００は、所定の手数
料を差し引いてマネーゲート５００に代金を支払う
（５）。

【０１０３】マネーゲート５００は、モール事業者３０
０に対して顧客紹介手数料として所定の歩合を支払い
（６）、また、自分の手数料ｂ％をさらに差し引いて、
オンラインショップ４００に対して代金を支払う
（７）。

【０１０４】Ｂ．詳細説明 次に、このように基本的な構成および動作として示すこ
とのできるのオンラインショッピングシステムの、実際
の構成例およびその動作、処理の流れの例について図７
〜図２６を参照して具体的に説明する。

【０１０５】（１）構成例 図７は、実際のネットワークに適用されたオンラインシ
ョッピングシステム１００の構成を示す図である。

【０１０６】図７に示すように、実際のオンラインショ
ッピングシステム１００においては、ユーザ２００、モ
ール事業者３００およびカード会社６００はいずれも複
数存在し、さらに、これらは常時その構成がダイナミッ
クに変化しているものである。

【０１０７】ユーザ２００は、ネットワーク７００に接
続される任意のノードであって、複数のモール事業者３
００の中のいずれかに登録することにより、オンライン
ショッピングシステム１００のユーザ２００となり得
る。すなわち、いずれかのモール事業者３００に登録す
ることにより、オンラインショッピングシステム１００
のその他のモールからも、そのモールの会員と同様の処
理により、買い物を行なうことができる。

【０１０８】モール事業者３００は、決済処理手段とし
てマネーゲート５００を利用することを前提とし、オン
ラインショッピングシステム１００内の他のモール事業
者が開設したモールに対して自らの会員ユーザが買い物
にアクセスすること、逆に、他のモール事業者に登録し
ているユーザが自らが開設しているモールに買い物にア
クセスしてくることを認めれば、任意のモール事業者が
オンラインショッピングシステム１００のモール事業者
３００として登録可能である。

【０１０９】そして、後述するように、そのような会員
ユーザ２００の相互のアクセスにより商品の売買が成立
した場合に、会員の登録を受付管理しているモール事業
者３００および商品を販売したオンラインショップ４０
０を管理しているモール事業者３００の双方が所定の手
数料を受け取ることができるようにすることにより、こ
のようなモール事業者３００にも利益がもたらされる。

【０１１０】マネーゲート５００は、このようなオンラ
インショッピングシステム１００において、前述したよ
うなコレットサーバ５１０および受注管理サーバ５２０
により、ユーザ２００、モール事業者３００およびオン
ラインショップ４００間のアクセスおよび決済処理を一
元管理する。これにより、それら相互のアクセスおよび
ショッピングが可能となる。

【０１１１】（２）動作、処理の流れ 以下、図７に示すような実際のオンラインショッピング
システム１００の動作、換言すればこのようなオンライ
ンショッピングシステム１００における処理の流れにつ
いて、具体的に説明する。

【０１１２】なお、以下の説明は、前述した基本的なオ
ンラインショッピングシステムの動作を実際のシステム
に適用した形態の説明である。したがって、前述した流
れとは多少の相違があるが、実質的なデータの流れ、動
作が異なるものではない。

【０１１３】本実施の形態では、図７に示すようなオン
ラインショッピングシステム１００において、モール
Ａ、Ｂ、Ｃを開設しているモール事業者３００のいずれ
かに対して会員登録を行なっているユーザ２００が、会
員登録をしていないモールＡ、Ｂ、Ｃに開設されている
ショップ４００においてオンラインショッピングを行な
う場合の処理を考える。

【０１１４】この場合、ユーザ２００は、少なくとも１
つのモール事業者３００またはオンラインショップ４０
０の会員である必要がある。その態様としては、各種の
態様が考えられる。まず、ユーザ２００が、物品の販売
やデジタルコンテンツの販売を行なうオンラインショッ
プ４００の会員であることが考えられる。この場合、そ
のオンラインショップ４００の会員であることにより、
そのオンラインショップ４００が加盟しているモール事
業者３００の会員となる場合も想定される。そして、モ
ール事業者３００に着目すると、このモール事業者３０
０は、自分に登録しているオンラインショップ４００へ
のユーザアクセスを管理制御するような例えばインター
ネット・サービス・プロバイダ（ＩＳＰ）のようなもの
であっても、そのモール事業者３００自体が物品の販売
やデジタルコンテンツの販売等を行なうオンラインショ
ップ機能を有するものであっても良い。さらに、モール
事業者３００は、図７中に見られるように、複数のオン
ラインショップ４００を管理するモール事業者自体を管
理するような構成であっても良い。しかも、モール事業
者３００のモール運営形態としては、モール事業者３０
０自体がカード会社６００と契約をしているような運営
形態も許容される（図７中のモール事業者３００ａ参
照）。つまり、モール事業者３００ａは、複数のカード
会社６００と契約をしており、加盟店となるオンライン
ショップ４００やモール事業者３００に対して、それら
のオンラインショップ４００やモール事業者３００が独
自にカード会社６００と契約を結ぶことなく、契約して
いるカード会社６００による決済を可能とするという運
営を提供するものである。

【０１１５】ユーザ２００は、インターネットである通
信ネットワーク７００を介して、モール事業者３００に
も、オンラインショップ４００にも、マネーゲート５０
０にも接続可能である。この場合、後述するように、ユ
ーザ２００は、自分が会員となっているモール事業者３
００ではないモール事業者３００に対しても接続可能で
ある。

【０１１６】ここで、ユーザ２００がマネーゲート５０
０に接続した場合の処理を説明する。マネーゲート５０
０は、ユーザ接続用のホームページをユーザ２００に提
供する。この場合のユーザ２００は、オンラインショッ
ピングシステム１００のいずれかのモール事業者３００
またはオンラインショップ４００の会員である。

【０１１７】マネーゲート５００がユーザ２００に提供
するホームページは、例えば、図８および図９に例示す
るような検索ページ５５０を有している。この検索ペー
ジ５５０は、ある物品やデジタルコンテンツの購入予定
があるユーザ２００に対し、その物品やデジタルコンテ
ンツを購入するためのオンラインショップ４００（以
下、モール事業者３００も含む場合を想定する）をオン
ラインショッピングシステム１００中から検索するため
のページである。この目的を実現するために、マネーゲ
ート５００は、検索ページ５５０を表示するための画像
イメージデータや表示プログラム、検索エンジンの他、
検索キーワード記憶手段を備えている。この検索キーワ
ード記憶手段は、マネーゲート５００によって決済仲介
処理が可能である商品販売手段、つまり、オンラインシ
ョッピングシステム１００中のオンラインショップ４０
０が販売する商品に１又は２以上の検索キーワードを対
応させて記憶するファイル構造を備えている。

【０１１８】ここで、検索ページ５５０は、マネーゲー
ト５００にインストールされた表示プログラムに従い、
オンラインショッピングシステム１００中の全てのオン
ラインショップ４００についてのリストをショップ表示
欄５５１に表示する（リスト表示手段）。このショップ
表示欄５５１には、オンラインショップ４００の名称５
５２とリンク情報５５３とが表示されている。表示され
るリンク情報５５３は、いわゆるＵＲＬ（Ｕｎｉｆｏｒ
ｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）であり、マネー
ゲート５００が備える検索エンジンは、このリンク情報
５５３にカーソルを合わせてクリックすることにより、
対応するオンラインショップ４００のページに移行する
ことができるようなプログラムを有している（自動アク
セス手段）。

【０１１９】マネーゲート５００にインストールされた
表示プログラムは、検索ページ５５０にそのようなショ
ップ表示欄５５１ばかりでなく、検索キーワード入力用
のダイアログボックス５５４も表示する（検索キーワー
ド入力手段）。このダイアログボックス５５４は、図８
および図９に示すように、検索キーワード入力用の入力
領域５５５と、検索実行を指定するための命令ボタン５
５６とを有している。そして、マネーゲート５００にイ
ンストールされた検索エンジンプログラムは、ダイアロ
グボックス５５４の入力領域５５５に所定のキーワード
が入力された後に命令ボタン５５６がクリックされた場
合に、入力された検索キーワードに基づいて前述した検
索キーワード記憶手段から対応するオンラインショップ
４００を検索し、検索されたオンラインショップ４００
のページにユーザ２００をリンク可能な状態にさせる
（第２の自動アクセス手段）。ここで、リンク可能な状
態の一例としては、図９に例示するように、検索された
オンラインショップ４００のリストをショップ表示欄５
５１に表示させ、このショップ表示欄５５１に、検索さ
れたオンラインショップ４００の名称５５２とリンク情
報５５３とを表示する。リンク可能な状態の別の一例と
しては、例えば、検索されたオンラインショップ４００
が一つだけであれば、そのオンラインショップ４００の
ページにユーザ２００を自動的にリンク付けるというこ
とも実施可能である。この場合、ユーザ２００が能動的
あるいは受動的に所定のオンラインショップ４００のペ
ージにアクセスするに際し、そのオンラインショップ４
００はそのユーザ２００が登録していないモール事業者
３００である可能性がある。この場合には、後述するコ
レットサーバ５１０にアクセスする方法によって、ユー
ザ２００は、登録していないモール事業者３００が管理
するオンラインショップ４００のページを閲覧し、その
ページにおいてショッピングをすることが可能となる。
このような処理の詳細については後述する。

【０１２０】以下、物品の販売とデジタルコンテンツの
販売とに分けて説明する。

【０１２１】．物品の販売 たとえば、図７に示すようなオンラインショッピングシ
ステム１００において、モールＢを開設しているモール
事業者３００ｂに対して会員登録を行なっているユーザ
２００ｂｊが、モールＡに開設されているショップ４０
０ａｉにおいて物品のショッピングを行なう場合の処理
の流れについて、図７〜図１８を参照して説明する。こ
の場合、モールＢを開設しているモール事業者３００ｂ
は、ユーザ２００ｂｊのクレジットカード番号等の決済
に必要な情報を知らないものとする。

【０１２２】モールＢの会員であるユーザ２００ｂｊが
モールＡのオンラインショップ４００ａｉ（第１のサイ
ト、販売サイト）にネット上で買い物に行き、購入した
い所望の商品を発見した場合、ユーザ２００ｂｊは、た
とえば図１２に示すような買い物かごオブエクト８０１
をクリックすることによりオーダーシート８０２を開
き、これに順次記入をすることによりオーダを行なう。
この時、ユーザ２００ｂｊはモールＡの会員ではない
が、自分が会員となっているモールＢに対して登録され
ている所定のＩＤを指定することにより、モールＡの会
員と同様に、換言すれば自分がモールＢのショップで商
品を購入するのと同様に、モールＢのモール事業者３０
０ｂ（第２のサイト、認証サイト）に対して登録してあ
るクレジットカードを用いて支払いを行なうことができ
る。

【０１２３】一例として、その所定のＩＤを指定するた
めに、ユーザ２００ｂｊは、マネーゲート５００のコレ
ットサーバ５１０にアクセスし、モールＢの会員用のコ
レットを利用してオーダを行なう（処理Ｐ１）。具体的
には、たとえば図１２にオブジェクト８０３で示すよう
なオブジェクトを立ち上げ、このオブジェクトをオーダ
ーシート８０２の代金支払い用のモ一ルＡの会員ＩＤを
記載する箇所にドロップする。ここで、オブジェクト８
０３には、そのユーザｂｊのモールＩＤ等に関する情報
がリンク付けられている。そこで、そのオブジェクト８
０３をオーダーシート８０２の代金支払い用のモールＡ
の会員ＩＤを記載する箇所にドロップするという操作に
よって、その個所にユーザｂｊのモールＩＤが入力され
ることになる。

【０１２４】コレットサーバ５１０には、図４に示した
ように、各モールの会員に対応して、他のモールのＵＲ
Ｌおよびそのモールを利用する際のＩＤ（マネーゲート
ＩＤ）などの情報が記載されているので、この操作によ
り、オーダーシート８０２の代金支払い者のＩＤの項目
には、モールＢのマネーゲートＩＤが書き込まれること
になる。

【０１２５】所定のＩＤを入力するための別の一例とし
ては、ユーザ２００が登録しているモール事業者３００
等のユーザＩＤをユーザ２００に入力させるようにして
も良い。このような構成にする場合には、コレットサー
バ５１０等に、ユーザＩＤとそのユーザＩＤを登録して
いるモール事業者３００等とを対応付けたリストを記憶
させておく必要がある。

【０１２６】そして、最後に、たとえばユーザ２００ｂ
ｊが注文ボタンを押下するなどすることにより、ショッ
プ４００ａｉに対して注文がなされる。

【０１２７】このような商品の注文を受け付けたモール
Ａのショップ４００ａｉは、購入者のＩＤやメールアド
レスおよび金額などの注文情報を有する受注データを生
成し、ショップを開設しているモールＡのモール事業者
３００ａに送信する（処理Ｐ２）。なお、モールＢの会
員がマネーゲート５００を介してモールＡのショップ４
００ａｉで買い物をした本実施の形態においては、この
受注データ中のＩＤは、図２に示したマネーゲート利用
者登録情報としてマネーゲート５００のコレットサーバ
５１０に設定されている、モールＢ会員用のマネーゲー
トＩＤとなる。

【０１２８】ショップ４００ａｉからの受注データを受
信したモールＡのモール事業者３００ａは、データベー
スに受注情報を登録し、受注番号を採番する（処理Ｐ
３）。そして、特に物品の販売の場合には、図１３に示
すような、注文情報、受注番号（受付番号）、確認ＵＲ
Ｌなどを記載した確認メール８０４をユーザ２００ｂｊ
に送信する（処理Ｐ４：ユーザ管理手段）。

【０１２９】確認メールを受信したユーザ２００ｂｊ
は、指定された確認ＵＲＬにアクセスする（処理Ｐ
５）。

【０１３０】この確認ＵＲＬへのアクセス処理Ｐ５時
も、一例として、ユーザ２００ｂｊはマネーゲート５０
０のコレットサーバ５１０にアクセスし、モールＢの会
員用のコレットを利用してオーダを行なう。すなわち、
図１４に示すようなアクセス受付画面８０５によりユー
ザＩＤの入力が求められている時に、コレットオブジェ
クト８０６を立ち上げ、このオブジェクトをＩＤを記載
する箇所にドロップすることにより、モールＢ会員用の
マネーゲートＩＤを書き込む。あるいは、別の一例とし
て、モールＢでの会員用のユーザＩＤを値数入力等の手
法で入力する。

【０１３１】確認ＵＲＬにアクセスしたユーザ２００ｂ
ｊは、さらに、たとえば図１５に示すような画面８０７
より受付番号（受注番号）を入力し、図１６に示すよう
な画面８０８により、自らの注文内容を確認する。そし
て、問題がなければ購入する旨のボタン８０９を選択し
て確認を行なう（処理Ｐ６）。

【０１３２】ユーザ２００ｂｊからの注文の確認を得た
モールＡのモール事業者３００ａは、ＩＤ、受注番号、
ユーザ２００ｂｊのＩＰアドレスおよび注文情報などの
受注データをマネーゲート５００に送信する（処理Ｐ
７）。

【０１３３】受注データを受信したマネーゲート５００
は、受信した受注データを受注管理サーバ５２０に登録
する（処理Ｐ８）。なお、この登録は、受注データをカ
ード会社などとオーソリ要求を行なう際のデータ形式で
記録する。そのためにはユーザ２００ｂｊのクレジット
カード番号が必要であるが、この時点では、図２に示し
たマネーゲート利用者登録情報に設定されているダミー
のクレジットカード番号を記録しておく。

【０１３４】受注データを記録したマネーゲート５００
は、ユーザ２００ｂｊが会員登録をしているモールＢの
モール事業者３００ｂに、ユーザ２００ｂｊに対してモ
ールＢにおけるＩＤおよびクレジットカード番号の入力
を得るようなウェブ画面を立ち上げ、ＩＤおよびクレジ
ットカード番号を得るように指示する（処理Ｐ９）。な
お、この時マネーゲート５００は、得られるユーザ２０
０ｂｊの情報と受注データを対応付けるために、受注番
号（受付番号）の情報をモールＢのモール事業者３００
ｂに送信しておく。これに基づいて、モールＢのモール
事業者３００ｂは、ユーザ２００ｂｊに対して、図１７
に示すような、ＩＤおよびクレジットカード番号を要求
する画面８１０を立ち上げる（処理Ｐ１０）、その結
果、ユーザ２００ｂｊにおいては、画面８０８と画面８
１０を立ち上げているモール事業者が異なることが一見
気づかないような状態で、注文内容を確認する画面８０
８上にＩＤおよびクレジットカード番号の入力を要求す
るオブジェクト８１０が表示される。このように、オブ
ジェクト８１０においてクレジットカード番号の入力を
ユーザ２００ｂｊに求める理由は、そのユーザ２００ｂ
ｊが会員登録をしているモールＢを開設しているモール
事業者３００ｂは、ユーザ２００ｂｊのクレジットカー
ド番号等の決済に必要な情報を知らないからである。

【０１３５】ユーザ２００ｂｊが、画面８１０を介し
て、ＩＤ、パスワードなどの入力および確認などの作業
を行なうと、その結果が画面８１０を立ち上げているモ
ールＢのモール事業者３００ｂに通知される（処理Ｐ１
１）。

【０１３６】これに基づいてモールＢのモール事業者３
００ｂは、マネーゲート５００に対して、ユーザ２００
ｂｊのクレジットカード番号、有効期限および入会状態
などのカード会社とのオーソリに用いる情報、モールＢ
におけるＩＤ、ＩＰアドレスおよび先にマネーゲート５
００より送信されていた受注番号の情報を、マネーゲー
ト５００に送信する（処理Ｐ１２）。

【０１３７】そして、マネーゲート５００においては、
モールＢのモール事業者３００ｂより入力された受注番
号に基づいて、先に受注管理サーバ５２０に記録されて
いる受注データを検索して対応する受注データを抽出
し、その受注データに設定されているダミーのクレジッ
トカード番号をモールＢのモール事業者３００ｂより受
信したユーザ２００ｂｊの正規のクレジットカード番号
に書き換えることにより、モールＢのモール事業者３０
０ｂからのデータをデータベースに登録する（処理Ｐ１
３：支払い情報獲得手段）。

【０１３８】次にマネーゲート５００は、正規のクレジ
ットカード番号が設定された受注データを用いて、カー
ド会社６００に対してオーソリ要求を行なう（処理Ｐ１
４）カード会社６００は、その要求に基づいてオーソリ
を行ない、適正であればオーソリ承認をマネーゲート５
００に返信する（処理Ｐ１５）。

【０１３９】マネーゲート５００は、返信されたオーソ
リ結果に基づいて、注文を承認する旨のデータをモール
Ａのモール事業者３００ａに送信する（処理Ｐ１６）。

【０１４０】以上の処理により、決済処理手段の機能が
実行される。

【０１４１】この受信された情報に基づいて、モールＡ
のモール事業者３００ａは、マネーゲートを用いない他
の受注と同一の処理となる受注処理を今一度行ない（処
理Ｐ１７）、その受注処理に基づいて、マネーゲート５
００に対して再度オーソリ要求を行なう（処理Ｐ１
８）。

【０１４２】マネーゲート５００は、モールＡのモール
事業者３００ａからのこのオーソリ要求に対して、既に
カード会社６００より受信していたオーソリ承認を返信
する（処理Ｐ１９)。

【０１４３】マネーゲート５００よりオーソリ承認を受
けたモールＡのモール事業者３００ａは、受注が完了し
たものとして、ユーザ２００ｂｊに対して与信結果およ
び処理完了の報告を、たとえば図１８に示すようなオブ
ジェクト形態で行なうと同時に（処理Ｐ２０）、ショッ
プ４００ａｉに対して、売上承認および出荷依頼を行な
う（処理Ｐ２１）。

【０１４４】このように、本システムでは、マネーゲー
ト５００がカード会社６００に対してオーソリ要求をす
るタイミング（処理Ｐ１４）と、モール事業者３００ｂ
からの要求に基づいてオーソリ承認を返信するタイミン
グ（処理Ｐ１９）との間にずれを生じさせている。これ
は、マネーゲート５００を介することなくモールＡの会
員がモールＡにおいてオンラインショッピングを行なう
場合、ユーザからの注文内容確認を待ってモールＡはカ
ード会社６００にオーソリ要求を行なっているので、こ
れとの整合を取る意味で、カード会社６００からのオー
ソリ承認に基づいて注文承認通知をモールＡに行ない
（処理Ｐ１６）、この注文承認通知に基づいてモールＡ
からオーソリ要求があって（処理Ｐ１８）からオーソリ
承認を返信している。

【０１４５】ユーザからの注文内容確認を待ってオーソ
リ要求をしているのは、ユーザの誤操作による誤発注や
なりすまし注文に基づく誤発送対策のためであり（本出
願人による出願、特開平１０−２８９２６７号公報参
照）、オンラインショッピングに必須の構成ではないの
で、モールＡが上述のような注文内容確認システムを採
用しない場合は、ユーザ２００ｂｊのクレジットカード
番号が判明次第オーソリをカード会社６００に要求し、
モールＡからのオーソリ要求に応答してオーソリ結果を
通知しても良い。

【０１４６】出荷依頼を受けたショップ４００ａｉは、
ユーザ２００ｂｊに商品を発送し（処理Ｐ２２）、さら
にモールＡのモール事業者３００ａに対して出荷情報を
送信する（処理Ｐ２３）。

【０１４７】モールＡのモール事業者３００ａは、ショ
ップ４００ａｉから受信した出荷情報を蓄積しておき、
たとえば月末などの締め日に合わせて、ダミークレジッ
トカード番号、売上金額およびオーソリ番号を有する売
上データ、および、受注番号、商品名および金額の情報
を有する売上利用明細データを生成し（処理Ｐ２４）、
各々マネーゲート５００に送信する（処理Ｐ２５）。

【０１４８】マネーゲート５００においては、受信した
売上データ中のダミークレジットカード番号データを実
際のクレジットカード番号データに変換し（処理Ｐ２
６）、カード会社６００に対して、クレジットカード番
号、商品名および金額の情報を有する請求データを送信
する（処理Ｐ２７）。

【０１４９】この請求データに基づいて、カード会社６
００は月ごとの所定の期日にユーザ２００ｂｊに対して
一括してカード使用料金の請求を行ない（処理Ｐ２
８）、指定日の銀行引き落としなどの処理により支払い
を受ける（処理Ｐ２９）。

【０１５０】ユーザ２００ｂｊより支払いを受けたカー
ド会社６００は、支払われた金銭より所定の手数料を差
し引いて（処理Ｐ３０）、残額をマネーゲート５００に
支払う（処理Ｐ３１）。

【０１５１】マネーゲート５００は、カード会社６００
より支払われた金額よりさらに自らの手数料を差し引き
（処理Ｐ３２）、モールＡのモール事業者３００ａに対
してモール事業者としての所定の手数料を支払い（処理
Ｐ３３）、モールＢのモール事業者３００ｂに対して会
員の紹介手数料として所定の割合の手数料を支払い（処
理Ｐ３４）、残った金銭をモールＡのショップ４００ａ
ｉに支払う（処理Ｐ３５）。

【０１５２】以上のような処理により、ユーザ２００ｂ
ｊは、自分が登録していないモールＡのショップ４００
ａｉより、所望の物品を購入する。

【０１５３】．デジタルコンテンツの販売 次に、同じく例えば図７に示すようなオンラインショッ
ピングシステム１００において、モールＢを開設してい
るモール事業者３００ｂに対して会員登録を行なってい
るユーザ２００ｂｊが、モールＡに開設されているショ
ップ４００ａｉにおいてショッピングを行なう場合であ
って、特に、デジタルコンテンツを購入する場合の処理
の流れについて、図１９を参照して説明する。

【０１５４】ａ）認証サイトがユーザのクレジットカー
ド番号を認識していない場合 まず、認証サイト（第２のサイト）となるモールＢを開
設しているモール事業者３００ｂが、ユーザ２００ｂｊ
のクレジットカード番号等の決済に必要な情報を知らな
い場合について説明する。

【０１５５】デジタルコンテンツを購入する場合も、基
本的には、前述した物品を購入する場合と同じ処理であ
る。しかし、物品の場合と異なリ、デジタルコンテンツ
をネットワーク７００を介して配信することにより販売
する場合には、受注の確認をメールにより行なう必要が
なくなる。すなわち、図１３〜図１５に示したような画
面などを用いた、確認メールのユーザ２００ｂｊへの送
信（処理Ｐ４)、これに対するユーザ２００ｂｊからの
アクセス（処理Ｐ５)が不要となる。

【０１５６】したがって、図１９に示すように、ユーザ
２００ｂｊがマネーゲート５００のコレットサーバ５１
０のモールＢの会員用のコレットを利用して、あるい
は、モールＢの会員用のユーザＩＤを入力してショップ
４００ａｉに対してオーダを行ない（処理Ｐ１）、商品
の注文を受け付けたモールＡのショップ４００ａｉが購
入者のＩＤやメールアドレスおよび注文情報（あるいは
ユーザＩＤ）をモール事業者３００ａに送信し（処理Ｐ
２）、モールＡのモール事業者３００ａが受注情報の登
録および受注番号の採番を行なったら（処理Ｐ３）、直
ちに図１６に示すような注文確認の画面８０８がユーザ
２００ｂｊに提示される（処理Ｐ５’）。

【０１５７】ユーザ２００ｂｊは、これを見て自らの注
文内容を確認し、問題がなければ購入する旨のボタン８
０９を選択して注文の了承を行なう（処理Ｐ６’）。

【０１５８】以下の、ユーザ２００ｂｊからの注文の確
認を得たモールＡのモール事業者３００ａが注文情報な
どの受注データをマネーゲート５００に送信する（処理
Ｐ７）処理以降の処理は、図１０〜図１８を参照して前
述した物品を購入する場合の処理と同じである。

【０１５９】ユーザ２００ｂｊが自分が登録していない
モールＡのショップ４００ａｉよりデジタルコンテンツ
を購入する場合には、このような処理が好適である。

【０１６０】ｂ）認証サイトがユーザのクレジットカー
ド番号を認識している場合次に、モールＡを開設してい
るモール事業者３００ａに対して会員登録を行なってい
るユーザ２００ａｉが、直接決済処理を行なうショップ
４００ｃｋにおいて物品のショッピングを行なう場合の
処理の流れについて、図７および図２０〜図２６を参照
して説明する。この場合、認証サイト（第２のサイト）
となるモールＡを開設しているモール事業者３００ａ
は、ユーザ２００ａｉのクレジットカード番号等の決済
に必要な情報を知っている。また、モールＡを開設して
いるモール事業者３００ａは、独自にカード会社６００
と決済契約を結んでいる。

【０１６１】なお、図７に示すようにショップ４００ｃ
ｋはモールＣのモール事業者３００ｃにショップを開設
しているものとするが、このモールＣのモール事業者３
００ｃは、モール内の各ショップにおける受注や決裁に
何ら係わらず、単にインターネット７００上におけるサ
イトをショップに提供するのみの事業者ということとな
る。

【０１６２】このような形態のオンラインショッピング
においても、基本的には前述した各例と同様の手順で処
理は進められる。

【０１６３】まず、モールＡの会員であるユーザ２００
ａｉは、マネーゲート５００のコレットサーバ５１０の
モールＡの会員用のコレットを利用し、ショップ４００
ｃｋのサイトに入る（処理Ｐ１）。

【０１６４】具体的には、たとえば図２１に示すような
オブジェクト８１４を立ち上げ、このオブジェクトを、
たとえばショップ４００ｃｋのホームページ８１２に設
けられているＩＤおよびパスワードを記載する箇所８１
３にドロップする。コレットサーバ５１０には、図４に
示したように、各モールの会員に対応して、他のモール
のＵＲＬおよびそのモールを利用する際のＩＤ（マネー
ゲートＩＤ）などの情報が記載されているので、この操
作により、ホームページ８１２のＩＤおよびパスワード
の項目８１３には、モールＡのマネーゲートＩＤおよび
パスワードが書き込まれ、これによりユーザ２００ａｉ
はショップ４００ｃｋのサイトにアクセス可能となる。

【０１６５】別の一例として、モールＡの会員であるユ
ーザ２００ａｉは、そのモールＡでの会員用のユーザＩ
Ｄを利用してショップ４００ｃｋのサイトに入るように
しても良い（処理Ｐ１）。

【０１６６】ショップ４００ｃｋのサイトに入ったら、
ユーザ２００ａｉは、ホームページで紹介されている商
品を順次閲覧しながら、たとえば図２２に示すようない
わゆる買い物かご８１５と言われるような機能を用いて
順次買い物を行なう。そして最終的に、たとえば図２３
に示すようなオーダーシート８１６を立ち上げ、これに
より注文を行なう（処理Ｐ２’’）。その際、たとえば
図２３に示すような注文方法および支払方法を選択する
ウィンドウ８１７が表示される（支払方法入力表示手
段）。そこで、マネーゲート５００を介した支払いを選
択する場合には、そのウィンドウ８１７において、「Ｓ
ｈｏｐｐｉｎｇ Ｓｗｉｔｃｈ」の項を選択し、これよ
りマネーゲート５００を介した支払いを選択しておく。
このようなマネーゲート５００の選択により、以下の処
理が実行される。

【０１６７】ショップ４００ｃｋは、このような受注を
受け付けたら、受注データを生成し、これをデータベー
ス登録するとともに受注番号を採番する（処理Ｐ
３’’）。

【０１６８】そして、特に物品の販売の場合には、図２
４に示すような注文書確認画面８１８を直ちにユーザ２
００ａｉに提示し、注文の確認を求める（処理Ｐ
５’’）。

【０１６９】ユーザ２００ａｉは、これを見て自らの注
文内容を確認し問題がなければ、このサイトに入ったの
と同じようにコレットオブジェクト８１４を呼び出し、
これをＩＤ記載箇所８１９にドロップしてＩＤを入力
し、さらに、注文を送信する旨のボタン８２０を選択し
て注文の了承を行なう（処理Ｐ６’’）。

【０１７０】ユーザ２００ａｉからの注文の確認を得た
ショップ４００ｃｋは、ＩＤ、受注番号、ユーザ２００
ａｉのＩＤアドレスおよび注文情報などの受注データを
マネーゲート５００に送信する（処理Ｐ７’’）。

【０１７１】マネーゲート５００は、受信した受注デー
タを受注管理サーバ５２０に登録し、（処理Ｐ８）、ユ
ーザ２００ａｉが会員登録をしているモールＡのモール
事業者３００ａに、ユーザ２００ａｉに対してモールＡ
におけるＩＤおよびパスワードの入力を得るようなウェ
ブ画面８２１を立ち上げ、ＩＤおよびパスワードを得る
ように指示する（処理Ｐ９’）。なお、この時マネーゲ
ート５００は、得られるユーザ２００ａｉの情報と受注
データを対応付けるために、受注番号（受付番号）の情
報をモールＡのモール事業者３００ａに送信しておく。

【０１７２】ここで、ユーザ２００ａｉに対してクレジ
ットカード番号等のような決済に必要な情報の入力を求
めないのは、モールＡのモール事業者３００ａにおいて
そのユーザ２００ａｉのクレジットカード番号等を認識
可能だからである。

【０１７３】これに基づいて、モールＡのモール事業者
３００ａは、ユーザ２００ａｉに対して、図２５に示す
ような、ＩＤおよびパスワードを要求する画面８２１を
立ち上げる（処理Ｐ１０’’）。その結果、ユーザ２０
０ａｉにおいては、画面８１８と画面８２１を立ち上げ
ているモール事業者が異なることが一見気づかないよう
な状態で、注文内容を確認する画面８１８上にＩＤおよ
びパスワードの入力を要求するオブジェクト８２１が表
示される。

【０１７４】ユーザ２００ａｉが、画面８２１を介し
て、ＩＤ、パスワードの入力を行なうと、その結果がモ
ールＡのモール事業者３００ａに通知され（処理Ｐ１
１’’）、これに基づいてモールＡのモール事業者３０
０ａは、マネーゲート５００に対して、ユーザ２００ａ
ｉのクレジットカード番号、有効期限および入会状態な
どのカード会社とのオーソリに用いる情報、モールＡに
おけるＩＤ、ＩＰアドレスおよび先にマネーゲート５０
０より送信されていた受注番号の情報を、マネーゲート
５００に送信する（処理Ｐ１２)。

【０１７５】そして、マネーゲート５００においては、
モールＡのモール事業者３００ａより入力された受注番
号に基づいて、先に受注管理サーバ５２０に記録されて
いる受注データを検索して対応する受注データを抽出
し、その受注データに設定されているダミーのクレジッ
トカード番号をモールＡのモール事業者３００ａより受
信したユーザ２００ａｉの正規のクレジットカード番号
に書き換えることにより、モールＡのモール事業者３０
０ａからのデータをデータベースに登録する（処理Ｐ１
３）。

【０１７６】次にマネーゲート５００は、カード会社６
００に対してオーソリ要求を行ない（処理Ｐ１４)、こ
れに基づいてカード会社６００はオーソリを行ない、適
正であればオーソリ承認をマネーゲート５００に返信す
る（処理Ｐ１５）。

【０１７７】ここで、別の一例として、モールＡを開設
しているモール事業者３００ａは、独自にカード会社６
００と決済契約を結んでいることから、このようなモー
ルＡを開設しているモール事業者３００ａが契約を結ん
でいるカード会社６００との間で決済を行なうようにし
ても良い。この場合、マネーゲート５００がカード会社
６００に対してオーソリ要求を行ない（処理Ｐ１４）、
これに基づいてカード会社６００がオーソリを行ない、
適正であればオーソリ承認をマネーゲート５００に返信
する（処理Ｐ１５）という処理は実行されない。つま
り、モールＡを開設しているモール事業者３００ａの側
でオーソリ要求処理およびオーソリ承認の受信処理を実
行する。一例として、モール事業者３００ａは、ユーザ
２００ａｉが画面８２１を介してＩＤ、パスワードの入
力を行ない、その結果がモールＡのモール事業者３００
ａに通知された後のタイミングで（処理Ｐ１１’’）、
カード会社６００に対してオーソリ要求を行なうように
すれば良い。その結果、カード会社６００がオーソリを
行ない、適正であればオーソリ承認をモール事業者３０
０ａに返信することになる。そこで、モール事業者３０
０ａは、マネーゲート５００に対して、ユーザ２００ａ
ｉについてクレジット承認が得られたこと、つまりオー
ソリ承認を伝達する。

【０１７８】マネーゲート５００は、返信されたオーソ
リ結果に基づいて注文を承認する旨のデータをショップ
４００ｃｋに送信し（処理Ｐ１６）、この受信された情
報に基づいて、ショップ４００ｃｋは、マネーゲートを
用いない他の受注と同一の処理となる受注処理を今一度
行ない（処理Ｐ１７’’）、その受注処理に基づいて、
マネーゲート５００に対して再度オーソリ要求を行なう
（処理Ｐ１８’’）。

【０１７９】マネーゲート５００は、ショップ４００ｃ
ｋからのこのオーソリ要求に対して、既にカード会社６
００より受信していたオーソリ承認を返信する（処理Ｐ
１９）。

【０１８０】これによりショップ４００ｃｋは、受注が
完了したものとして、ユーザ２００ａｉに対して与信結
果および処理完了の報告を、たとえば図２６に示すよう
なオブジェクト８２２により行なうと同時に（処理Ｐ２
０’’）、自ら売上承認および出荷処理を行なう（処理
Ｐ２１’’)。

【０１８１】以下、商品発送（Ｐ２２）以降の処理も、
モール事業者における処理をショップ４００ｃｋが行な
うことにより、図１１を参照して前述した場合と同様に
行なわれる。なお、これにともなって、モールＣのモー
ル事業者３００ｃへの手数料分配の処理Ｐ３３に対応す
る処理は不要となる。

【０１８２】以上のような処理により、ユーザ２００ａ
ｉは、モールではなく直接決済処理を行なう形態のショ
ップ４００ｃｋについても、登録をしていなくとも物品
を購入することができる。

【０１８３】ここで、上述の例の場合において、決済を
どこで行なうか、つまり、ショップ４００ｃｋで行なう
か、マネーゲート５００が行なうか、あるいは、モール
事業者３００ａが行なうかということについては、ユー
ザ２００ａｉに選択権を与えることが望ましい。ユーザ
２００ａｉに選択権を与える手法としては、一例とし
て、図２３に示すような注文方法および支払方法を選択
するウィンドウ８１７においてユーザ２００ａｉに選択
許容性を付与することが実施可能である。

【０１８４】（３）各サイト間の通信 次いで、各サイト間の通信処理について図７〜図３５を
用いて説明する。

【０１８５】まず、各サイト間のインターフェースの利
用態様を表１に例示する。その態様は、表１に説明する
通り、マネーゲート５００の基本形態と、ショッピング
スイッチ受付サービス利用形態と、メールオーダー形態
との３態様がある。その概要については表１で説明する
通りである。

【０１８６】

【表１】 これらの３態様のうち、メールオーダー形態は、受注確
認をメールで実施するが、決済処理を通信上で実行しな
い形態であるため、その説明は省略する。これに対し、
マネーゲート５００の基本形態とショッピングスイッチ
受付サービス利用形態とについては、図２７ないし図３
５に基づいて以下に述べる。

【０１８７】次いで、受注処理におけるサイト間インタ
ーフェースは、受注サイトであるモール事業者３００や
オンラインショップ４００ごとに異なる。具体的には、
マネーゲート５００に登録している登録事業者サイト
（例えば、モール事業者３００）と実際のショッピング
をユーザ２００に提供する販売サイト（例えば、オンラ
インショップ４００）とが同一である場合と異なる場合
とがある。後者の典型的な例としては、登録事業者サイ
トがインターネット・サービス・プロバイダ（ＩＳＰ）
である場合である。そこで、マネーゲート５００の基本
形態とショッピングスイッチ受付サービス利用形態との
それぞれについて、登録事業者サイトと販売サイトとが
同一である場合と異なる場合とについて、それぞれ説明
する。つまり、以後の説明は、４態様となる。

【０１８８】ここで、図２７はマネーゲート５００の基
本形態において登録事業者サイトと販売サイトとが同一
である場合のサイト間通信の流れを示すフローチャー
ト、図２８はマネーゲート５００の基本形態において登
録事業者サイトと販売サイトとが異なる場合のサイト間
通信の流れを示すフローチャート、図２９はショッピン
グスイッチ受付サービス利用形態において登録事業者サ
イトと販売サイトとが同一である場合のサイト間通信の
流れを示すフローチャート、図３０はショッピングスイ
ッチ受付サービス利用形態において登録事業者サイトと
販売サイトとが異なる場合のサイト間通信の流れを示す
フローチャートである。そして、図３１〜図３５には、
サイト間通信によってサイト間を送受信される電文フォ
ーマットを示す。

【０１８９】．マネーゲートの基本形態において登録
事業者サイトと販売サイトとが同一である場合のサイト
間通信 まず、図２７に示すように、実際のシステムとしては、
共にモール事業者３００やオンラインショップ４００で
あるショッピングサイト（第１のサイト、販売サイト）
４５０と認証サイト（第２のサイト）３５０とには、そ
れぞれに本来の機能をもたらすための受注サイト４５１
とウェブサーバ３５１とが設けられるばかりでなく、そ
れぞれ、マネーゲート５００と連携するショッピングス
イッチ連携サーバ４５２、３５２が設けられている。そ
して、これらの各態様において、図７に例示したモール
事業者３００ａに相当するシステム３００ａが連携して
いる。前述したように、このモール事業者３００ａは、
自分自身が複数のカード会社６００と契約をしており、
加盟店となるオンラインショップ４００やモール事業者
３００に対して、それらのオンラインショップ４００や
モール事業者３００が独自にカード会社６００と契約を
結ぶことなく、契約しているカード会社６００による決
済を可能とするという運営を提供する。具体的には、モ
ール事業者３００ａは、加盟店となるオンラインショッ
プ４００やモール事業者３００においてユーザ２００が
クレジットカード取引を指定した場合、そのクレジット
カード取引に対するオーソリ要求を受け付け、カード会
社６００に対してオーソリ要求をしてその結果を受け取
り、オンラインショップ４００などに結果を通知するこ
と、及び、例えば月単位のオンラインショップ４００な
どの売上をまとめて各々のカード会社６００に請求する
作業を行なう。

【０１９０】以下、サイト間通信について詳しく述べ
る。

【０１９１】前提として、ユーザ２００がインターネッ
トである通信ネットワーク７００を介してショッピング
サイト４５０の受注サイト４５１にアクセスするには、
そのユーザ２００が会員登録をしている認証サイト３５
０を特定する情報が必要となる。そこで、このような認
証サイト３５０を特定する情報を入力してショッピング
サイト４５０の受注サイト４５１にアクセスしているユ
ーザ２００から注文書要求が送信されると（１）、受注
サイト４５１はそのユーザ２００に対して注文書を送信
する（２）。その際の電文内容は図３１に示す通りであ
る。これにより、ユーザ２００にオーダ画面が提供され
る。

【０１９２】ユーザ２００は、そのオーダ画面から発注
をする。この際、コレット入力等を実行すると、コレッ
トサーバ５１０に認証サイト情報要求が出される
（３）。つまり、認証サイト３５０は、そのユーザ２０
０が会員登録をしているサイトであるが、そのサイトは
１つとは限らないため、認証サイト３５０が複数ある場
合、ユーザ２００に選択の余地が与えられるわけであ
る。認証サイト情報要求がなされたコレットサーバ５１
０は、認証サイト選択画面をユーザ２００に提供し
（４）、ユーザ２００に任意の認証サイト３５０を選択
する機会を与える。

【０１９３】その認証サイト選択画面で所望の認証サイ
ト３５０をユーザ２００が選択すると、受注サイト４５
１に注文要求がなされる（５）。この注文要求には、ユ
ーザ２００が指定した認証登録事業者取引先コードが含
まれている。すると、ショッピングサイト４５０では、
そのショッピングスイッチ連携サーバ４５２に注文登録
要求が発信され（７）、その後、ショッピングスイッチ
連携サーバ４５２は、マネーゲート５００の受注管理サ
ーバ５２０に向けて注文登録要求を発信する（８）。以
上の処理に際しての電文内容は、図３１に示す通りであ
る。

【０１９４】その後に続く処理としては、受注管理サー
バ５２０からショッピングスイッチ連携サーバ４５２へ
の注文登録応答（９）、ショッピングスイッチ連携サー
バ４５２から受注サイト４５１への注文登録応答がなさ
れ（１０）、受注サイト４５１からユーザ２００にコレ
ットリダイヤル要求（受注）がなされる（１７）。この
コレットリダイヤル要求（受注）には、マネーゲートＩ
Ｄが含まれているが、このマネーゲートＩＤは、取引単
位でコレットサーバ５１０が生成するＩＤであり、この
時点では、マネーゲートＩＤによってユーザ２００の同
一性が識別されることはない。

【０１９５】そこで、ユーザ２００がコレットリダイヤ
ル（受注）をすると、その際の電文はコレットサーバ５
１０に送信される（１８）。コレットリダイヤル（受
注）の電文を受けたコレットサーバ５１０は、認証サイ
トリダイレクト要求をユーザ２００に返送する（１
９）。図３２に示すように、この認証サイトリダイレク
ト要求には、前述した（５）の処理でユーザ２００が指
定した認証登録事業者のＵＲＬが含まれている。そこ
で、この認証登録事業者ＵＲＬを利用し、ユーザ２００
から、対応するＵＲＬを有する認証登録事業者である認
証サイト３５０のウェブサーバ３５１にログオン要求が
なされる（２０）。これを受けた認証サイト３５０のウ
ェブサーバ３５１は、そのユーザ２００にログオン画面
を提供する（２１）。

【０１９６】ログオン画面の提供を受けたユーザ２００
は、ログオン画面中に認証ユーザＩＤやクレジットカー
ド番号等の自己同一性を識別し得る情報を入力した上
で、認証サイト３５０のウェブサーバ３５１に対してロ
グオン要求をし（２２）、これにより、そのウェブサー
バ３５１での認証が実行される。つまり、ここで初め
て、そのユーザの秘密性が高い情報である認証ＩＤやク
レジットカード番号等の情報がオンライン送信されるわ
けである。もっとも、前述した通り、認証サイト３５０
におけるウェブサーバ３５１において、認証ＩＤ等をキ
ーとしてそのユーザ２００のクレジットカード番号を検
索可能であれば、ログオン要求時にクレジットカード番
号の送信が不要であり、一層の安全性が図られる。

【０１９７】こうして、認証処理を実行したウェブサー
バ３５１は、認証サイト３５０のショッピングスイッチ
連携サーバ３５２に認証結果通知を行ない（２３）、こ
れに応じて認証サイト３５０のショッピングスイッチ連
携サーバ３５２は受注管理サーバ５２０に認証結果通知
を行なう（２４）。

【０１９８】この後、受注管理サーバ５２０は、モール
事業者３００ａのシステム（ｅ−ＳＣＯＴＴ）に対して
オーソリ要求を送信する（２５）。これに応じて、モー
ル事業者３００ａは、ユーザ２００毎に決定されるクレ
ジットカードのカード会社６００にオーソリ要求を行な
い、カード会社６００からその結果であるオーソリ結果
を受信する。そして、そのオーソリ結果を受注管理サー
バ５２０に返信する（２５）。

【０１９９】モール事業者３００ａのシステム（ｅ−Ｓ
ＣＯＴＴ）からクレジットカードのオーソリ結果を受け
た受注管理サーバ５２０は、ショッピングサイト４５０
に設置されたショッピングスイッチ連携サーバ４５２に
対してオーソリ結果を含む認証結果報告を行なう（２
６）。これにより、ショッピングスイッチ連携サーバ４
５２は、オーソリされたかどうかを知ることができる。
そこで、オーソリ結果を含む認証結果報告を受けたショ
ッピングサイト４５０のショッピングスイッチ連携サー
バ４５２は、受注管理サーバ５２０にオーソリ結果に応
じた結果についての結果コードを含む認証結果報告を送
信し（２７）、売買取引成立の有無を受注管理サーバ５
２０に連絡する。これに応じて、受注管理サーバ５２０
は、認証サイトのショッピングスイッチ連携サーバ３５
２へオーソリ結果および結果コードを含む認証結果通知
応答（２８）をし、そのショッピングスイッチ連携サー
バ３５２は認証サイト３５０のウェブサーバ３５１へオ
ーソリ結果および結果コードを含む認証結果通知応答
（２９）を行なう。これにより、認証サイト３５０は、
オーソリ結果および売買取引成立の有無を知ることがで
きる。

【０２００】その後、認証サイト３５０のウェブサーバ
３５１からユーザ２００へのコレットリダイレクト要求
（認証）がなされ（３０）、これに応じてユーザ２００
からコレットサーバ５１０へのコレットリダイレクト
（認証）がなされる（３１）。そして、これに応じてコ
レットサーバ５１０からユーザ２００へ受注サイトリダ
イレクト要求がなされ（３２）、ユーザ２００から受注
サイト４５０へのリダイレクトがなされる（３３）。

【０２０１】その結果、ショッピングサイト４５０にお
いて、受注サイト４５１とショッピングスイッチ連携サ
ーバ４５２との間でのオーソリ結果要求（ＡＰＩ）（３
５）、オーソリ結果応答（ＡＰＩ）（３６）、オーソリ
要求（ＡＰＩ）（４０）がそれぞれなされ、オーソリ要
求（ＡＰＩ）を受けたショッピングスイッチ連携サーバ
４５２と受注管理サーバ５２０との間でのオーソリ要求
（４１）とオーソリ応答（４２）とがそれぞれなされ
る。そして、オーソリ応答を受けたショッピングサイト
４５０のショッピングスイッチ連携サーバ４５２は受注
サイト４５１にオーソリ応答（ＡＰＩ）を送信し、受注
サイト４５１はユーザ２００に完了画面を提供する（４
５）。

【０２０２】このような一連の処理によって、ショッピ
ングサイト４５０では会員登録していないユーザ２００
でも、認証サイト３５０で会員登録をしていれば、ショ
ッピングサイト４５０でのオンラインショッピングが可
能となる。

【０２０３】．マネーゲートの基本形態において登録
事業者サイトと販売サイトとが異なる場合のサイト間通
信 まず、図２８に示すように、実際のシステムとしては、
モール事業者３００やオンラインショップ４００である
ショッピングサイト（第１のサイト、販売サイト）４５
０の他に、受注登録事業者サイト３６０（第１のサイ
ト）と認証サイト（第２のサイト）３５０とが設けられ
ている。受注登録事業者サイト３６０は、ショッピング
サイト４５０である受注サイト４５１に対して、この受
注サイト４５１を管理するオンラインショップ管理手段
として機能する。そして、それらの受注登録事業者サイ
ト３６０と認証サイト３５０とには、それぞれに本来の
機能をもたらすための受注既存システムサイト３６１と
ウェブサーバ３５１とが設けられるばかりでなく、それ
ぞれ、マネーゲート５００と連携するショッピングスイ
ッチ連携サーバ３６２、３５２が設けられている。そし
て、これらの各態様において、図７に例示したモール事
業者３００ａに相当するシステム３００ａが連携してい
る。

【０２０４】以下、サイト間通信について詳しく述べ
る。

【０２０５】前提として、ユーザ２００がインターネッ
トである通信ネットワーク７００を介してショッピング
サイト４５０の受注サイト４５１にアクセスするには、
そのユーザ２００が会員登録をしている認証サイト３５
０を特定する情報が必要となる。そこで、このような認
証サイト３５０を特定する情報を入力してショッピング
サイト４５０の受注サイト４５１にアクセスしているユ
ーザ２００から注文書要求が送信されると（１）、受注
サイト４５１はそのユーザ２００に対して注文書を送信
する（２）。その際の電文内容は図３１に示す通りであ
る。これにより、ユーザ２００にオーダ画面が提供され
る。

【０２０６】ユーザ２００は、そのオーダ画面から発注
をする。この際、コレット入力等を実行すると、コレッ
トサーバ５１０に認証サイト情報要求が出される
（３）。つまり、認証サイト３５０は、そのユーザ２０
０が会員登録をしているサイトであるが、そのサイトは
１つとは限らないため、認証サイト３５０が複数ある場
合、ユーザ２００に選択の余地が与えられるわけであ
る。認証サイト情報要求がなされたコレットサーバ５１
０は、認証サイト選択画面をユーザ２００に提供し
（４）、ユーザ２００に任意の認証サイト３５０を選択
する機会を与える。

【０２０７】その認証サイト選択画面で所望の認証サイ
ト３５０をユーザ２００が選択すると、受注サイト４５
１に注文要求がなされる（５）。この注文要求には、ユ
ーザ２００が指定した認証登録事業者取引先コードが含
まれている。すると、受注サイト４５１は、受注登録事
業者サイト３６０の受注既存システム３６１に対して受
注要求を行ない（６）、すると、その受注既存システム
３６１は受注登録事業者サイト３６０のショッピングス
イッチ連携サーバ３６２に注文登録要求を発信する
（７）。その後、ショッピングスイッチ連携サーバ３６
２は、マネーゲート５００の受注管理サーバ５２０に向
けて注文登録要求を発信する（８）。以上の処理に際し
ての電文内容は、図３１に示す通りである。

【０２０８】その後に続く処理としては、受注管理サー
バ５２０からショッピングスイッチ連携サーバ３６２へ
の注文登録応答（９）、ショッピングスイッチ連携サー
バ３６２から受注既存システム３６１への注文登録応答
がなされ（１０）、受注既存システム３６１から受注サ
イト４５１への受注応答を介して（１１）、ユーザ２０
０にコレットリダイヤル要求（受注）がなされる（１
７）。このコレットリダイヤル要求（受注）には、マネ
ーゲートＩＤが含まれているが、このマネーゲートＩＤ
は、取引単位でコレットサーバ５１０が生成するＩＤで
あり、この時点では、マネーゲートＩＤによってユーザ
２００の同一性が識別されることはない。

【０２０９】そこで、ユーザ２００がコレットリダイヤ
ル（受注）をすると、その際の電文はコレットサーバ５
１０に送信される（１８）。コレットリダイヤル（受
注）の電文を受けたコレットサーバ５１０は、認証サイ
トリダイレクト要求をユーザ２００に返送する（１
９）。図３２に示すように、この認証サイトリダイレク
ト要求には、前述した（５）の処理でユーザ２００が指
定した認証登録事業者のＵＲＬが含まれている。そこ
で、この認証登録事業者ＵＲＬを利用し、ユーザ２００
から、対応するＵＲＬを有する認証登録事業者である認
証サイト３５０のウェブサーバ３５１にログオン要求が
なされる（２０）。これを受けた認証サイト３５０のウ
ェブサーバ３５１は、そのユーザ２００にログオン画面
を提供する（２１）。

【０２１０】ログオン画面の提供を受けたユーザ２００
は、ログオン画面中に認証ユーザＩＤやクレジットカー
ド番号等の自己同一性を識別し得る情報を入力した上
で、認証サイト３５０のウェブサーバ３５１に対してロ
グオン要求をし（２２）、これにより、そのウェブサー
バ３５１での認証が実行される。つまり、ここで初め
て、そのユーザの秘密性が高い情報である認証ＩＤやク
レジットカード番号等の情報がオンライン送信されるわ
けである。もっとも、前述した通り、認証サイト３５０
におけるウェブサーバ３５１において、認証ＩＤ等をキ
ーとしてそのユーザ２００のクレジットカード番号を検
索可能であれば、ログオン要求時にクレジットカード番
号の送信が不要であり、一層の安全性が図られる。

【０２１１】こうして、認証処理を実行したウェブサー
バ３５１は、認証サイト３５０のショッピングスイッチ
連携サーバ３５２に認証結果通知を行ない（２３）、こ
れに応じて認証サイト３５０のショッピングスイッチ連
携サーバ３５２は受注管理サーバ５２０に認証結果通知
を行なう（２４）。

【０２１２】この後、受注管理サーバ５２０は、モール
事業者３００ａのシステム（ｅ−ＳＣＯＴＴ）に対して
オーソリ要求を送信する（２５）。これに応じて、モー
ル事業者３００ａは、ユーザ２００毎に決定されるクレ
ジットカードのカード会社６００にオーソリ要求を行な
い、カード会社６００からその結果であるオーソリ結果
を受信する。そして、そのオーソリ結果を受注管理サー
バ５２０に返信する（２５）。

【０２１３】モール事業者３００ａのシステム（ｅ−Ｓ
ＣＯＴＴ）からクレジットカードのオーソリ結果を受け
た受注管理サーバ５２０は、受注登録事業者サイト３６
０に設置されたショッピングスイッチ連携サーバ３６２
に対してオーソリ結果を含む認証結果報告を行なう（２
６）。これにより、ショッピングスイッチ連携サーバ３
６２は、オーソリされたかどうかを知ることができる。
そこで、オーソリ結果を含む認証結果報告を受けた受注
登録事業者サイト３６０のショッピングスイッチ連携サ
ーバ３６２は、受注管理サーバ５２０にオーソリ結果に
応じた結果についての結果コードを含む認証結果報告を
送信し（２７）、売買取引成立の有無を受注管理サーバ
５２０に連絡する。これに応じて、受注管理サーバ５２
０は、認証サイトのショッピングスイッチ連携サーバ３
５２へオーソリ結果および結果コードを含む認証結果通
知応答（２８）をし、そのショッピングスイッチ連携サ
ーバ３５２は認証サイト３５０のウェブサーバ３５１へ
オーソリ結果および結果コードを含む認証結果通知応答
（２９）を行なう。これにより、認証サイト３５０は、
オーソリ結果および売買取引成立の有無を知ることがで
きる。

【０２１４】その後、認証サイト３５０のウェブサーバ
３５１からユーザ２００へのコレットリダイレクト要求
（認証）がなされ（３０）、これに応じてユーザ２００
からコレットサーバ５１０へのコレットリダイレクト
（認証）がなされる（３１）。そして、これに応じてコ
レットサーバ５１０からユーザ２００へ受注サイトリダ
イレクト要求がなされ（３２）、ユーザ２００から受注
サイト４５０へのリダイレクトがなされる（３３）。

【０２１５】その結果、ショッピングサイト４５０の受
注サイト４５１から受注登録事業者サイト３６０の受注
既存システム３６１へのオーソリ要求（３４）、受注登
録事業者サイト３６０における受注既存システム３６１
とショッピングスイッチ連携サーバ３６２との間でのオ
ーソリ結果要求（ＡＰＩ）（３５）、オーソリ結果応答
（ＡＰＩ）（３６）、オーソリ要求（ＡＰＩ）（４０）
がそれぞれなされ、オーソリ要求（ＡＰＩ）を受けたシ
ョッピングスイッチ連携サーバ３６２と受注管理サーバ
５２０との間でのオーソリ要求（４１）とオーソリ応答
（４２）とがそれぞれなされる。そして、オーソリ応答
を受けた受注登録事業者サイト３６０のショッピングス
イッチ連携サーバ３６２は受注既存システム３６１にオ
ーソリ応答（ＡＰＩ）を送信し、受注既存システム３６
１はショッピングサイト４５０の受注サーバ４５１にオ
ーソリ応答を送信し、受注サイト４５１はユーザ２００
に完了画面を提供する（４５）。

【０２１６】このような一連の処理によって、ショッピ
ングサイト４５０では会員登録していないユーザ２００
でも、認証サイト３５０で会員登録をしていれば、ショ
ッピングサイト４５０でのオンラインショッピングが可
能となる。

【０２１７】．ショッピングスイッチ受付サービス利
用形態において登録事業者サイトと販売サイトとが同一
である場合のサイト間通信 まず、図２９に示すように、実際のシステムとしては、
共にモール事業者３００やオンラインショップ４００で
あるショッピングサイト（第１のサイト、販売サイト）
４５０と認証サイト（第２のサイト）３５０とには、そ
れぞれに本来の機能をもたらすための受注サイト４５１
とウェブサーバ３５１とが設けられるばかりでなく、そ
れぞれ、マネーゲート５００と連携するショッピングス
イッチ連携サーバ４５２、３５２が設けられている。ま
た、ショッピングサイト４５０に、ショッピングスイッ
チ受付サーバ４５３も設けられている。このショッピン
グスイッチ受付サーバ４５３は、ユーザ２００からの発
注先となるサーバであり、ショッピングサイト４５０
は、そのショッピングスイッチ受付サーバ４５３を設け
ることで、マネーゲート５００のシステムに組み込まれ
た場合であっても、既存の受注サイト４５１での受注処
理に対する影響を最小限に留めることが可能となる。そ
して、これらの各態様において、図７に例示したモール
事業者３００ａに相当するシステム３００ａが連携して
いる。

【０２１８】以下、サイト間通信について詳しく述べ
る。

【０２１９】前提として、ユーザ２００がインターネッ
トである通信ネットワーク７００を介してショッピング
サイト４５０の受注サイト４５１にアクセスするには、
そのユーザ２００が会員登録をしている認証サイト３５
０を特定する情報が必要となる。そこで、このような認
証サイト３５０を特定する情報を入力してショッピング
サイト４５０の受注サイト４５１にアクセスしているユ
ーザ２００から注文書要求が送信されると（１）、受注
サイト４５１はそのユーザ２００に対して注文書を送信
する（２）。その際の電文内容は図３１に示す通りであ
る。これにより、ユーザ２００にオーダ画面が提供され
る。

【０２２０】ユーザ２００は、そのオーダ画面から発注
をする。この際、コレット入力等を実行すると、コレッ
トサーバ５１０に認証サイト情報要求が出される
（３）。つまり、認証サイト３５０は、そのユーザ２０
０が会員登録をしているサイトであるが、そのサイトは
１つとは限らないため、認証サイト３５０が複数ある場
合、ユーザ２００に選択の余地が与えられるわけであ
る。認証サイト情報要求がなされたコレットサーバ５１
０は、認証サイト選択画面をユーザ２００に提供し
（４）、ユーザ２００に任意の認証サイト３５０を選択
する機会を与える。

【０２２１】その認証サイト選択画面で所望の認証サイ
ト３５０をユーザ２００が選択すると、ショッピングス
イッチ受付サーバ４５３に注文要求がなされる（５）。
この注文要求には、ユーザ２００が指定した認証登録事
業者取引先コードが含まれている。すると、ショッピン
グサイト４５０では、そのショッピングスイッチ連携サ
ーバ４５２に注文登録要求が発信され（７）、その後、
ショッピングスイッチ連携サーバ４５２は、マネーゲー
ト５００の受注管理サーバ５２０に向けて注文登録要求
を発信する（８）。以上の処理に際しての電文内容は、
図３１に示す通りである。

【０２２２】その後に続く処理としては、受注管理サー
バ５２０からショッピングスイッチ連携サーバ４５２へ
の注文登録応答（９）、ショッピングスイッチ連携サー
バ４５２から受注サイト４５１への注文登録応答がなさ
れ（１０）、受注サイト４５１からユーザ２００にコレ
ットリダイヤル要求（受注）がなされる（１７）。この
コレットリダイヤル要求（受注）には、マネーゲートＩ
Ｄが含まれているが、このマネーゲートＩＤは、取引単
位でコレットサーバ５１０が生成するＩＤであり、この
時点では、マネーゲートＩＤによってユーザ２００の同
一性が識別されることはない。

【０２２３】そこで、ユーザ２００がコレットリダイヤ
ル（受注）をすると、その際の電文はコレットサーバ５
１０に送信される（１８）。コレットリダイヤル（受
注）の電文を受けたコレットサーバ５１０は、認証サイ
トリダイレクト要求をユーザ２００に返送する（１
９）。図３２に示すように、この認証サイトリダイレク
ト要求には、前述した（５）の処理でユーザ２００が指
定した認証登録事業者のＵＲＬが含まれている。そこ
で、この認証登録事業者ＵＲＬを利用し、ユーザ２００
から、対応するＵＲＬを有する認証登録事業者である認
証サイト３５０のウェブサーバ３５１にログオン要求が
なされる（２０）。これを受けた認証サイト３５０のウ
ェブサーバ３５１は、そのユーザ２００にログオン画面
を提供する（２１）。

【０２２４】ログオン画面の提供を受けたユーザ２００
は、ログオン画面中に認証ユーザＩＤやクレジットカー
ド番号等の自己同一性を識別し得る情報を入力した上
で、認証サイト３５０のウェブサーバ３５１に対してロ
グオン要求をし（２２）、これにより、そのウェブサー
バ３５１での認証が実行される。つまり、ここで初め
て、そのユーザの秘密性が高い情報である認証ＩＤやク
レジットカード番号等の情報がオンライン送信されるわ
けである。もっとも、前述した通り、認証サイト３５０
におけるウェブサーバ３５１において、認証ＩＤ等をキ
ーとしてそのユーザ２００のクレジットカード番号を検
索可能であれば、ログオン要求時にクレジットカード番
号の送信が不要であり、一層の安全性が図られる。

【０２２５】こうして、認証処理を実行したウェブサー
バ３５１は、認証サイト３５０のショッピングスイッチ
連携サーバ３５２に認証結果通知を行ない（２３）、こ
れに応じて認証サイト３５０のショッピングスイッチ連
携サーバ３５２は受注管理サーバ５２０に認証結果通知
を行なう（２４）。

【０２２６】この後、受注管理サーバ５２０は、モール
事業者３００ａのシステム（ｅ−ＳＣＯＴＴ）に対して
オーソリ要求を送信する（２５）。これに応じて、モー
ル事業者３００ａは、ユーザ２００毎に決定されるクレ
ジットカードのカード会社６００にオーソリ要求を行な
い、カード会社６００からその結果であるオーソリ結果
を受信する。そして、そのオーソリ結果を受注管理サー
バ５２０に返信する（２５）。

【０２２７】モール事業者３００ａのシステム（ｅ−Ｓ
ＣＯＴＴ）からクレジットカードのオーソリ結果を受け
た受注管理サーバ５２０は、ショッピングサイト４５０
に設置されたショッピングスイッチ連携サーバ４５２に
対してオーソリ結果を含む認証結果報告を行なう（２
６）。これにより、ショッピングスイッチ連携サーバ４
５２は、オーソリされたかどうかを知ることができる。
そこで、オーソリ結果を含む認証結果報告を受けたショ
ッピングサイト４５０のショッピングスイッチ連携サー
バ４５２は、受注管理サーバ５２０にオーソリ結果に応
じた結果についての結果コードを含む認証結果報告を送
信し（２７）、売買取引成立の有無を受注管理サーバ５
２０に連絡する。これに応じて、受注管理サーバ５２０
は、認証サイトのショッピングスイッチ連携サーバ３５
２へオーソリ結果および結果コードを含む認証結果通知
応答（２８）をし、そのショッピングスイッチ連携サー
バ３５２は認証サイト３５０のウェブサーバ３５１へオ
ーソリ結果および結果コードを含む認証結果通知応答
（２９）を行なう。これにより、認証サイト３５０は、
オーソリ結果および売買取引成立の有無を知ることがで
きる。

【０２２８】その後、認証サイト３５０のウェブサーバ
３５１からユーザ２００へのコレットリダイレクト要求
（認証）がなされ（３０）、これに応じてユーザ２００
からコレットサーバ５１０へのコレットリダイレクト
（認証）がなされる（３１）。そして、これに応じてコ
レットサーバ５１０からユーザ２００へ受注サイトリダ
イレクト要求がなされ（３２）、ユーザ２００からショ
ッピングスイッチ受付サーバ４５３へのリダイレクトが
なされる（３３）。

【０２２９】その結果、ショッピングサイト４５０にお
いて、ショッピングスイッチ受付サーバ４５３とショッ
ピングスイッチ連携サーバ４５２との間でのオーソリ結
果要求（ＡＰＩ）（３５）、オーソリ結果応答（ＡＰ
Ｉ）（３６）がそれぞれなされ、オーソリ結果応答（Ａ
ＰＩ）を受けたショッピングスイッチ受付サーバ４５３
は、ユーザ２００に対して既存ＣＧＩリダイレクト要求
を行ない（３７）、これを受けたユーザ２００は受注サ
イト４５１に既存ＣＧＩリダイレクトを行なう（３
８）。これに応じて受注サイト４５１は、ショッピング
サイト４５０のショッピングスイッチ連携サーバ４５２
に向けてオーソリ要求（ＡＰＩ）を行ない（４０）、オ
ーソリ要求（ＡＰＩ）を受けたショッピングスイッチ連
携サーバ４５２と受注管理サーバ５２０との間でのオー
ソリ要求（４１）とオーソリ応答（４２）とがそれぞれ
なされる。そして、オーソリ応答を受けたショッピング
サイト４５０のショッピングスイッチ連携サーバ４５２
は受注サイト４５１にオーソリ応答（ＡＰＩ）を送信
し、受注サイト４５１はユーザ２００に完了画面を提供
する（４５）。

【０２３０】このような一連の処理によって、ショッピ
ングサイト４５０では会員登録していないユーザ２００
でも、認証サイト３５０で会員登録をしていれば、ショ
ッピングサイト４５０でのオンラインショッピングが可
能となる。

【０２３１】また、比較対象となる図２７の処理に比
べ、ショッピングスイッチ受付サーバ４５３を設けるこ
とで、このショッピングスイッチ受付サーバ４５３が
（７）、（１０）、（３５）および（３６）の処理を実
行するため、この点で受注サイト４５１の負担が軽減さ
れる。よって、マネーゲート５００のシステムに組み込
まれた場合であっても、既存の受注サイト４５１での受
注処理に対する影響を最小限に留めることが可能とな
る。

【０２３２】．ショッピングスイッチ受付サービス利
用形態において登録事業者サイトと販売サイトとが異な
る場合のサイト間通信 まず、図３０に示すように、実際のシステムとしては、
モール事業者３００やオンラインショップ４００である
ショッピングサイト（第１のサイト、販売サイト）４５
０の他に、受注登録事業者サイト３６０（第１のサイ
ト）と認証サイト（第２のサイト）３５０とが設けられ
ている。受注登録事業者サイト３６０は、ショッピング
サイト４５０である受注サイト４５１に対して、この受
注サイト４５１を管理するオンラインショップ管理手段
として機能する。そして、それらの受注登録事業者サイ
ト３６０と認証サイト３５０とには、それぞれに本来の
機能をもたらすための受注既存システムサイト３６１と
ウェブサーバ３５１とが設けられるばかりでなく、それ
ぞれ、マネーゲート５００と連携するショッピングスイ
ッチ連携サーバ３６２、３５２が設けられている。そし
て、これらの各態様において、図７に例示したモール事
業者３００ａに相当するシステム３００ａが連携してい
る。

【０２３３】以下、サイト間通信について詳しく述べ
る。

【０２３４】前提として、ユーザ２００がインターネッ
トである通信ネットワーク７００を介してショッピング
サイト４５０の受注サイト４５１にアクセスするには、
そのユーザ２００が会員登録をしている認証サイト３５
０を特定する情報が必要となる。そこで、このような認
証サイト３５０を特定する情報を入力してショッピング
サイト４５０の受注サイト４５１にアクセスしているユ
ーザ２００から注文書要求が送信されると（１）、受注
サイト４５１はそのユーザ２００に対して注文書を送信
する（２）。その際の電文内容は図３１に示す通りであ
る。これにより、ユーザ２００にオーダ画面が提供され
る。

【０２３５】ユーザ２００は、そのオーダ画面から発注
をする。この際、コレット入力等を実行すると、コレッ
トサーバ５１０に認証サイト情報要求が出される
（３）。つまり、認証サイト３５０は、そのユーザ２０
０が会員登録をしているサイトであるが、そのサイトは
１つとは限らないため、認証サイト３５０が複数ある場
合、ユーザ２００に選択の余地が与えられるわけであ
る。認証サイト情報要求がなされたコレットサーバ５１
０は、認証サイト選択画面をユーザ２００に提供し
（４）、ユーザ２００に任意の認証サイト３５０を選択
する機会を与える。

【０２３６】その認証サイト選択画面で所望の認証サイ
ト３５０をユーザ２００が選択すると、受注サイト４５
１に注文要求がなされる（５）。この注文要求には、ユ
ーザ２００が指定した認証登録事業者取引先コードが含
まれている。すると、受注サイト４５１は、受注登録事
業者サイト３６０の受注既存システム３６１に対して受
注要求を行ない（６）、すると、その受注既存システム
３６１は受注登録事業者サイト３６０のショッピングス
イッチ連携サーバ３６２に注文登録要求を発信する
（７）。その後、ショッピングスイッチ連携サーバ３６
２は、マネーゲート５００の受注管理サーバ５２０に向
けて注文登録要求を発信する（８）。以上の処理に際し
ての電文内容は、図３１に示す通りである。

【０２３７】その後に続く処理としては、受注管理サー
バ５２０から受注登録事業者サイト３６０のショッピン
グスイッチ連携サーバ３６２への注文登録応答（９）、
ショッピングスイッチ連携サーバ３６２から受注既存シ
ステム３６１への注文登録応答がなされ（１０）、受注
既存システム３６１からショッピングサイト４５０の受
注サイト４５１への受注応答を介して（１１）、ユーザ
２００にオーダ受信報告画面が提供される（１２）。そ
して、その直後に、受注登録事業者サイト３６０の受注
既存システム３６１からユーザ２００に確認メールが送
信される（１３）。そこで、ユーザ２００は、確認メー
ルを確認した後、受注既存システム３６１に受注確認書
要求を発信し（１４）、これを受けた受注既存システム
３６１は、ユーザ２００に受注確認画面を提供する（１
５）。これを確認したユーザ２００は、受注既存システ
ム３６１に注文確認要求を送信し（１６）、これに応じ
て受注既存システム３６１よりユーザ２００にコレット
リダイヤル要求（受注）がなされる（１７）。このコレ
ットリダイヤル要求（受注）には、マネーゲートＩＤが
含まれているが、このマネーゲートＩＤは、取引単位で
コレットサーバ５１０が生成するＩＤであり、この時点
では、マネーゲートＩＤによってユーザ２００の同一性
が識別されることはない。

【０２３８】そこで、ユーザ２００がコレットリダイヤ
ル（受注）をすると、その際の電文はコレットサーバ５
１０に送信される（１８）。コレットリダイヤル（受
注）の電文を受けたコレットサーバ５１０は、認証サイ
トリダイレクト要求をユーザ２００に返送する（１
９）。図３２に示すように、この認証サイトリダイレク
ト要求には、前述した（５）の処理でユーザ２００が指
定した認証登録事業者のＵＲＬが含まれている。そこ
で、この認証登録事業者ＵＲＬを利用し、ユーザ２００
から、対応するＵＲＬを有する認証登録事業者である認
証サイト３５０のウェブサーバ３５１にログオン要求が
なされる（２０）。これを受けた認証サイト３５０のウ
ェブサーバ３５１は、そのユーザ２００にログオン画面
を提供する（２１）。

【０２３９】ログオン画面の提供を受けたユーザ２００
は、ログオン画面中に認証ユーザＩＤやクレジットカー
ド番号等の自己同一性を識別し得る情報を入力した上
で、認証サイト３５０のウェブサーバ３５１に対してロ
グオン要求をし（２２）、これにより、そのウェブサー
バ３５１での認証が実行される。つまり、ここで初め
て、そのユーザの秘密性が高い情報である認証ＩＤやク
レジットカード番号等の情報がオンライン送信されるわ
けである。もっとも、前述した通り、認証サイト３５０
におけるウェブサーバ３５１において、認証ＩＤ等をキ
ーとしてそのユーザ２００のクレジットカード番号を検
索可能であれば、ログオン要求時にクレジットカード番
号の送信が不要であり、一層の安全性が図られる。

【０２４０】こうして、認証処理を実行したウェブサー
バ３５１は、認証サイト３５０のショッピングスイッチ
連携サーバ３５２に認証結果通知を行ない（２３）、こ
れに応じて認証サイト３５０のショッピングスイッチ連
携サーバ３５２は受注管理サーバ５２０に認証結果通知
を行なう（２４）。

【０２４１】この後、受注管理サーバ５２０は、モール
事業者３００ａのシステム（ｅ−ＳＣＯＴＴ）に対して
オーソリ要求を送信する（２５）。これに応じて、モー
ル事業者３００ａは、ユーザ２００毎に決定されるクレ
ジットカードのカード会社６００にオーソリ要求を行な
い、カード会社６００からその結果であるオーソリ結果
を受信する。そして、そのオーソリ結果を受注管理サー
バ５２０に返信する（２５）。

【０２４２】モール事業者３００ａのシステム（ｅ−Ｓ
ＣＯＴＴ）からクレジットカードのオーソリ結果を受け
た受注管理サーバ５２０は、受注登録事業者サイト３６
０に設置されたショッピングスイッチ連携サーバ３６２
に対してオーソリ結果を含む認証結果報告を行なう（２
６）。これにより、ショッピングスイッチ連携サーバ３
６２は、オーソリされたかどうかを知ることができる。
そこで、オーソリ結果を含む認証結果報告を受けた受注
登録事業者サイト３６０のショッピングスイッチ連携サ
ーバ３６２は、受注管理サーバ５２０にオーソリ結果に
応じた結果についての結果コードを含む認証結果報告を
送信し（２７）、売買取引成立の有無を受注管理サーバ
５２０に連絡する。これに応じて、受注管理サーバ５２
０は、認証サイトのショッピングスイッチ連携サーバ３
５２へオーソリ結果および結果コードを含む認証結果通
知応答（２８）をし、そのショッピングスイッチ連携サ
ーバ３５２は認証サイト３５０のウェブサーバ３５１へ
オーソリ結果および結果コードを含む認証結果通知応答
（２９）を行なう。これにより、認証サイト３５０は、
オーソリ結果および売買取引成立の有無を知ることがで
きる。

【０２４３】その後、認証サイト３５０のウェブサーバ
３５１からユーザ２００へのコレットリダイレクト要求
（認証）がなされ（３０）、これに応じてユーザ２００
からコレットサーバ５１０へのコレットリダイレクト
（認証）がなされる（３１）。そして、これに応じてコ
レットサーバ５１０からユーザ２００へ受注サイトリダ
イレクト要求がなされ（３２）、ユーザ２００から受注
登録事業者サイト３６０の受注既存システム３６１への
リダイレクトがなされる（３３）。

【０２４４】その結果、受注登録事業者サイト３６０に
おいて、受注既存システム３６１とショッピングスイッ
チ連携サーバ３６２との間でのオーソリ結果要求（ＡＰ
Ｉ）（３５）、オーソリ結果応答（ＡＰＩ）（３６）、
オーソリ要求（ＡＰＩ）（４０）がそれぞれなされ、オ
ーソリ要求（ＡＰＩ）を受けたショッピングスイッチ連
携サーバ３６２と受注管理サーバ５２０との間でのオー
ソリ要求（４１）とオーソリ応答（４２）とがそれぞれ
なされる。そして、オーソリ応答を受けた受注登録事業
者サイト３６０のショッピングスイッチ連携サーバ３６
２は受注既存システム３６１にオーソリ応答（ＡＰＩ）
を送信し、受注既存システム３６１はショッピングサイ
ト４５０の受注サーバ４５１にオーソリ応答を送信し、
受注サイト４５１はユーザ２００に完了画面を提供する
（４５）。

【０２４５】このような一連の処理によって、ショッピ
ングサイト４５０では会員登録していないユーザ２００
でも、認証サイト３５０で会員登録をしていれば、ショ
ッピングサイト４５０でのオンラインショッピングが可
能となる。

【０２４６】また、比較対象となる図２８の処理に比
べ、受注登録事業者サイト３６０における受注既存シス
テム３６１とユーザ２００との間でのデータ送受信処理
が増加している（例えば、（１３）〜（１６）および
（３３）等）。これは、マネーゲート５００のシステム
に組み込まれる以前から、受注登録事業者サイト３６０
における受注既存システム３６１が通常処理として実行
していた処理であり、その意味で、マネーゲート５００
のシステムに組み込まれた場合であっても、既存の受注
登録事業者サイト３６０における受注既存システム３６
１での受注処理に対する影響を最小限に留めることが可
能となる。

【０２４７】（４）まとめ このように、本実施の形態のオンラインショッピングシ
ステムにおいては、いずれかの会員制のモールおよびシ
ョップの会員となっているユーザは、自分が登録してい
ない他のモールおよびショップからも、何ら新たな登録
処理などを行なう必要なく商品を購入することができ
る。したがって、ユーザが会員登録すべきモールやショ
ップの数の増加を抑制でき、ユーザが管理すべきＩＤや
パスワードが増えることなく決済に係る秘密情報の漏洩
の危険性を少なくすることができる。またその際の処理
は、自らが登録しているモールやショップからショッピ
ングを行なうのと同等の容易な処理でよい。したがっ
て、ユーザの利便性が著しく向上する。その結果、オン
ラインショッピングシステムの環境が向上し、オンライ
ンショッピングシステムの利用者の増加や、より活発な
取り引きが期待できる。

【０２４８】また、ユーザが会員登録をしていないモー
ル事業者、オンラインショップ等に対しては、本当のユ
ーザＩＤ、パスワード、クレジットカード番号といった
実際にそのユーザを特定し認証し得る情報を渡さず、ユ
ーザＩＤやクレジットカード番号についてはダミーのも
のを渡しているので、この面からも決済に係る秘密情報
の漏洩の危険性を少なくすることができる。

【０２４９】また、各モール事業者においては、登録会
員に対して、その登録ＩＤで様々なモールおよびショッ
プで買い物ができるという会員への付加価値を提供する
ことができ、より会員を広く募ることができる。

【０２５０】また、自らの会員が他のモールでショッピ
ングを行なった場合には手数料を得ることができるの
で、顧客紹介料というような新たな手数料収入が見込め
る。

【０２５１】さらに、各ショップにおいても、自らがシ
ョップを開設しているモールの会員以外からも広くユー
ザが買い物に来るので、売上高の増加が期待できる。

【０２５２】なお、本発明は本実施の形態に限られるも
のではなく、種々の改変が可能である。

【０２５３】たとえば、前述した各処理における、自ら
が登録しているモールおよびショップ以外の他のモール
やショップのサイトヘの入り方、そこでのショッピング
の形態、そこでの受注の方法、受注確認の方法、受注デ
ータの管理の方法、オーソリ方法、手順およびタイミン
グ、出荷方法、売上データの集計方法、利益分配率およ
び利益分配方法などは、任意好適な種々の方法で行なっ
てよい。

【０２５４】また、ショップでの受注情報と、ユーザが
登録しているモール事業者のクレジット番号などの情報
との対応付けは、前述した実施の形態では受注番号によ
り行なうものとした。しかしこれは、ＩＰアドレスによ
り行なってもよいし、Ｃｏｏｋｉｅの機能を利用して行
なうようにしてもよい。

【０２５５】また、オンラインショッピングシステム１
００が構成されるネットワークはインターネットに限ら
れるものではなく、任意のネットワークシステムでよ
い。

【０２５６】さらに、上述の各実施の形態ではモール事
業者がオンラインショップの管理をする構成を採用して
いたが、ユーザが会員登録をして決済に必要なデータを
渡していれば、モール事業者の代わりにオンラインショ
ップを管理しないインターネット・サービス・プロバイ
ダ（ＩＳＰ）がオンラインショップの管理をする構成で
あっても良い。

【０２５７】加えて、決済の手法としては、クレジット
カードによるクレジット決済に限らず、電子マネー、Ｊ
−Ｄｅｂｉｔ、ｅ−Ｗａｌｌｅｔ等のような、例えば各
種の電子決済に馴染むような各種の決済手法を採用する
ことができる。この場合、決済に必要な情報は、それら
の電子決済に必要な情報ということになる。

【０２５８】

【発明の効果】このように、本発明によれば、複数のシ
ステムで商取引きを行なう場合においても、手続きが容
易で管理すべきＩＤやパスワードが増えることなく決済
に係わる秘密情報の漏洩の危険性が少なくなるような決
済システムを実現する決済仲介処理装置を提供すること
ができる。

【０２５９】また、自分が登録しているオンラインショ
ップやモール以外のショップやモールも、簡単な手続き
で利用でき、管理すべきＩＤやパスワードが増えること
なく決済に係わる秘密情報の漏洩の危険性も少なくなる
オンラインショッピングシステムを提供するためのオン
ラインショップ装置を提供することができる。

【０２６０】さらに、そのようなオンラインショッピン
グ方法およびオンラインシステムを提供することができ
る。

【図面の簡単な説明】

【図１】図１は、本発明の一実施の形態のオンラインシ
ョッピングシステムの基本構成を示すブロック図であ
る。

【図２】図２は、図１に示したオンラインショッピング
システムのモール事業者の利用者マスタに記録されてい
る、他のモールの会員用の登録内容を示す模式図であ
る。

【図３】図３は、図１に示したオンラインショッピング
システムのモール事業者において、他のモールでショッ
ピングを行なった会員に対して行なう認証処理のポップ
アップ画面を示す模式図である。

【図４】図４は、図１に示したオンラインショッピング
システムのマネーゲートの事業者マスタに記録されてい
る、モール事業者ごとの他のモールをアクセスするため
の情報を示す模式図である。

【図５】図５は、図１に示したオンラインショッピング
システムにおける、ユーザが商品を購入した際の処理の
流れを説明するための模式図である。

【図６】図６は、図１に示したオンラインショッピング
システムにおいて締め日などに行なう売上・決済処理の
処理の流れを説明するための模式図である。

【図７】図７は、本実施の形態のオンラインショッピン
グシステムの実際の構成を示す模式図である。

【図８】図８は、マネーゲートが開設するオンラインシ
ョップ検索用のホームページにアクセスしたユーザに提
供される検索用ページを例示する模式図である。

【図９】図９は、入力された検索キーワードが検索され
た後の画面例を示す模式図である。

【図１０】図１０は、図７に示したオンラインショッピ
ングシステムにおいて、ユーザが他のモールの他のショ
ップより物品を購入した場合の処理の流れを示す第１の
模式図である。

【図１１】図１１は、図７に示したオンラインショッピ
ングシステムにおいて、ユーザが他のモールの他のショ
ップより物品を購入した場合の処理の流れを示す第２の
模式図である。

【図１２】図１２は、図１０および図１１に示した処理
において用いられるユーザの端末上の画面を説明するた
めの第１の模式図である。

【図１３】図１３は、図１０および図１１に示した処理
において用いられるユーザの端末上の画面を説明するた
めの第２の模式図である。

【図１４】図１４は、図１０および図１１に示した処理
において用いられるユーザの端末上の画面を説明するた
めの第３の模式図である。

【図１５】図１５は、図１０および図１１に示した処理
において用いられるユーザの端末上の画面を説明するた
めの第４の模式図である。

【図１６】図１６は、図１０および図１１に示した処理
において用いられるユーザの端末上の画面を説明するた
めの第５の模式図である。

【図１７】図１７は、図１０および図１１に示した処理
において用いられるユーザの端末上の画面を説明するた
めの第６の模式図である。

【図１８】図１８は、図１０および図１１に示した処理
において用いられるユーザの端末上の画面を説明するた
めの第７の模式図である。

【図１９】図１９は、図７に示したオンラインショッピ
ングシステムにおいて、ユーザが他のモールの他のショ
ップよりデジタルコンテンツを購入した場合の処理の流
れを示す模式図である。

【図２０】図２０は、図７に示したオンラインショッピ
ングシステムにおいて、ユーザが独立して決裁処理など
を行なう他のショップより物品を購入した場合の処理の
流れを示す模式図である。

【図２１】図２１は、図２０に示した処理において用い
られるユーザの端末上の画面を説明するための第１の模
式図である。

【図２２】図２２は、図２０に示した処理において用い
られるユーザの端末上の画面を説明するための第２の模
式図である。

【図２３】図２３は、図２０に示した処理において用い
られるユーザの端末上の面面を説明するための第３の模
式図である。

【図２４】図２４は、図２０に示した処理において用い
られるユーザの端末上の画面を説明するための第４の模
式図である。

【図２５】図２５は、図２０に示した処理において用い
られるユーザの端末上の画面を説明するための第５の模
式図である。

【図２６】図２６は、図２０に示した処理において用い
られるユーザの端末上の画面を説明するための第６の模
式図である。

【図２７】図２７は、マネーゲートの基本形態において
登録事業者サイトと販売サイトとが同一である場合のサ
イト間通信の流れを示すフローチャートである。

【図２８】図２８は、マネーゲートの基本形態において
登録事業者サイトと販売サイトとが異なる場合のサイト
間通信の流れを示すフローチャートである。

【図２９】図２９は、ショッピングスイッチ受付サービ
ス利用形態において登録事業者サイトと販売サイトとが
同一である場合のサイト間通信の流れを示すフローチャ
ートである。

【図３０】図３０は、ショッピングスイッチ受付サービ
ス利用形態において登録事業者サイトと販売サイトとが
異なる場合のサイト間通信の流れを示すフローチャート
である。

【図３１】図３１は、サイト間通信によってサイト間を
送受信される電文フォーマット（１〜８）を示す模式図
である。

【図３２】図３２は、サイト間通信によってサイト間を
送受信される電文フォーマット（９〜２３）を示す模式
図である。

【図３３】図３３は、サイト間通信によってサイト間を
送受信される電文フォーマット（２４〜２９）を示す模
式図である。

【図３４】図３４は、サイト間通信によってサイト間を
送受信される電文フォーマット（３０〜３５）を示す模
式図である。

【図３５】図３５は、サイト間通信によってサイト間を
送受信される電文フォーマット（３６〜４５）を示す模
式図である。

【図３６】図３６は、従来のオンラインショッピングシ
ステムにおける、処理の流れを説明するための模式図で
ある。

【符号の説明】

１００…オンラインショッピングシステム ２００…ユーザ ３００…モール事業者、第１の装置、第２の装置、第１
のサイト、第２のサイト ４００…オンラインショップ、第１の装置、第２の装
置、第１のサイト、第２のサイト ５００…マネーゲート ６００…カード会社 ７００，７１０，７２０…通信ネットワーク ８０１〜８２２…オブジェクト

───────────────────────────────────────────────────── フロントページの続き (72)発明者 柿沼 英彦 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 塩谷 啓二 東京都港区南青山１丁目１番１号 株式会 社ソニーファイナンスインターナショナル 内 (72)発明者 蓮水 ▲恵▼継 東京都港区南青山１丁目１番１号 株式会 社ソニーファイナンスインターナショナル 内 Ｆターム(参考） 5B085 AE02 AE23 BC02 BG02 BG07 CA02 CA04 CA06

Claims (4)

【特許請求の範囲】
1. 【請求項１】 第１のサイトにアクセスしようとするユ
   ーザから、そのユーザ自身の個人特定を行ないうる第２
   のサイトの選択入力を受け付ける手段と、 選択された前記第２のサイトに対してそのユーザの個人
   特定結果の返信を要求し、返信された個人特定結果に基
   づいてサービスを行なう手段と、を具備する情報処理装
   置。
2. 【請求項２】 前記第１のサイトは、ユーザからのアク
   セスに応じて対価の支払いを伴う所定の行為を行うもの
   であり、前記サービスを行う手段は、前記ユーザが要求
   した前記所定の行為の前記対価の決済を行うことを特徴
   とする請求項１に記載の情報処理装置。
3. 【請求項３】 情報処理用のコンピュータにインストー
   ルされ、このコンピュータに、 第１のサイトにアクセスしようとするユーザから、その
   ユーザ自身の個人特定を行ないうる第２のサイトの選択
   入力を受け付ける機能と、 選択された前記第２のサイトに対してそのユーザの個人
   特定結果の返信を要求し、返信された個人特定結果に基
   づいてサービスを行なう機能と、を実行させるプログラ
   ムを格納する記憶媒体。
4. 【請求項４】 情報処理用のコンピュータにインストー
   ルされ、このコンピュータに、 第１のサイトにアクセスしようとするユーザから、その
   ユーザ自身の個人特定を行ないうる第２のサイトの選択
   入力を受け付ける機能と、 選択された前記第２のサイトに対してそのユーザの個人
   特定結果の返信を要求し、返信された個人特定結果に基
   づいてサービスを行なう機能と、を実行させるコンピュ
   ータプログラム。