JP2002324174A - 売買仲介サーバシステム - Google Patents

Abstract

(57)【要約】 【課題】 ネットワークでの売買においてユーザの個人
情報を保護しつつ、販売者に対して確実な課金ができる
売買仲介サーバシステムを提供すること。 【解決手段】 本発明の売買仲介サーバシステムは、自
動車を販売する販売者が予め登録され（ＳＢ２）、販売
者は予めチケットを購入する（ＳＢ４）。ユーザは、欲
しい自動車の条件と価格を匿名で購入条件登録し、必要
な場合は仲介者サーバからアドバイスを受ける（ＳＢ
６）、販売者はユーザが入力した欲しい自動車の条件と
価格のリストを閲覧し（ＳＢ８）、商談を進めたいユー
ザがいた場合は、販売者はそのユーザを特定し仲介者サ
ーバに見積書の送信を依頼する（ＳＢ１０）。このとき
仲介者サーバは、販売者のチケットを消去して課金す
る。見積が送付されたユーザは商談を進める場合は、自
ら販売者にコンタクトを取る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は売買仲介サーバシス
テムに係り、詳しくはネットワークにおいて行われる売
買においてユーザの個人情報を保護しつつ、かつ販売者
に対して確実な課金をおこなうことができ、ユーザの価
格設定も容易な売買仲介サーバシステムに関する。

【０００２】

【従来の技術】例えば中古自動車を売買するには、従来
は、中古自動車店が商品を実際に展示し、ユーザが店頭
や雑誌の広告などでこの商品を見て購入するかどうかを
決定していた。また、インターネット等を利用した中古
車オークションなどインターネットを利用して中古自動
車を販売するようなものがあった。さらに近年はインタ
ーネットを用いてユーザが購入条件を提示して、これを
見た業者が販売の申し出をする、いわゆる逆オークショ
ン等も行われるようになった。この逆オークションのよ
うな販売方法であれば、商品を購入するユーザが主導権
をもって価格を設定し、これに対して販売者は提供でき
る価格を提示して販売の申し出を行うことで迅速に商品
を購入・販売することができる。

【０００３】

【発明が解決しようとする課題】しかしながら、商品を
購入したいユーザは、欲しい商品の車種・価格等の条件
をインターネット上で公開するとともに、自分のメール
アドレス等の個人情報を公開して商品提供者（販売者）
からの販売の申し出を待つ必要があるが、このようにメ
ールアドレス等の個人情報を開示すると、プライバシー
が保護されず、望まないダイレクトメールが送りつけら
れたり、セールスの対象にされるという問題があった。
また、販売の仲介者としては収入を得る必要があるが、
ユーザを多数参加させて商談を盛んにするためにはユー
ザに課金しないで販売者に課金することが望ましい。こ
のときユーザのメールアドレスを販売者に開示してしま
うと、販売者が仲介者を介さずに直接ユーザに商談を申
し込み、仲介者が課金の機会を失ってしまうという問題
があった。さらに、ユーザに価格の主導権があっても、
ユーザが実際の取引価格の相場がわからず価格の設定が
難しいという問題もあった。そこで本発明は、ネットワ
ークにおいて行われる売買においてユーザの個人情報を
保護しつつ、かつ販売者に対して確実な課金をおこなう
ことができ、ユーザの価格設定も容易な売買仲介サーバ
システムを提供することを目的をする。

【０００４】

【課題を解決するための手段】上記課題を達成するため
請求項１に記載の売買仲介サーバシステムでは、ネット
ワークに接続可能なコンピュータを備えた売買仲介サー
バシステムであって、クライアントコンピュータである
販売者端末の要求に応じて発行する金銭的価値を示す象
徴であるチケットに関し、そのチケット毎に付与される
チケット番号と、その販売者毎に付与される販売者番号
とを含むチケット発行データを記憶するチケット発行デ
ータ記憶手段と、クライアントコンピュータであるユー
ザ端末から送信される購入を希望する商品に関する条件
を含む購入データを前記販売者に閲覧可能に記憶する購
入データ記憶手段と、前記購入データを閲覧した前記販
売者により送信される前記購入データの商品に対応する
見積データと、当該見積データと共に送信される前記チ
ケット番号及び販売者番号とを含むオファーデータを受
信するオファーデータ受信手段と、前記オファーデータ
に含まれる販売者番号とチケット番号とのいずれもが、
前記チケット発行データ記憶手段に記憶されている販売
者番号とこの販売者番号に対応するチケット番号とに一
致するか否かを照合するチケット番号照合手段と、当該
チケット番号照合手段により、前記オファーデータに含
まれる販売者番号とチケット番号の何れもが照合できた
場合に、照合できたチケット番号を前記チケット発行デ
ータ記憶手段から消去することで当該販売者に対して課
金する課金手段と、前記課金手段により課金された場合
に、前記購入データに含まれたユーザのメールアドレス
に前記見積データを送信する見積りデータ送信手段とを
備えたことを要旨とする。

【０００５】このように構成された売買仲介サーバシス
テムでは、購入データ記憶手段の内容を販売者端末から
の要求に応じて閲覧させ、販売者からのオファーデータ
を、予めチケット発行データ記憶手段に記憶されたチケ
ットにより確実に課金を行なった場合のみユーザに見積
データを送信し、その一方で、ユーザ自身の意思による
連絡がない限り、ユーザの個人情報を販売者に伝えない
ことでユーザの個人情報を保護することができるという
作用がある。

【０００６】請求項２に記載の売買仲介サーバシステム
では、請求項１に記載の売買仲介サーバシステムに構成
に加え、前記見積りデータ送信手段は、前記課金手段に
より課金された場合に、前記購入データに含まれたユー
ザのメールアドレスにより前記見積データを前記ユーザ
端末に送信し、加えて前記販売者のメールアドレスと、
個人データフォームに関するデータを前記ユーザ端末に
送信し、ユーザの個人情報が付加された前記個人データ
フォームに関するデータが当該ユーザ端末から返送され
た場合に、当該個人データフォームに関するデータを前
記販売者端末に転送するとともに、前記商品データ受信
手段により受信した販売者番号に基づいて販売者端末か
ら提供され記憶された企業の内容に関する企業情報を前
記ユーザに送信する個人データ・企業情報送信手段とを
備えたことを要旨とする。

【０００７】このように構成された売買仲介サーバシス
テムでは、請求項１に記載の売買仲介サーバシステムの
作用に加え、ユーザが商談を望んだ場合のみ、より詳し
い情報を販売者及びユーザ双方に送信することができる
という作用がある。

【０００８】請求項３に記載の売買仲介システムでは、
請求項１又は請求項２に記載の売買仲介サーバシステム
の構成に加え、売買される商品についての条件と取引価
格とが予め記憶された相場情報記憶手段と、前記ユーザ
端末から送信された購入を希望する商品に関する条件に
対して、同一又は一部が一致する条件の商品を前記相場
情報記憶手段において検索・抽出する条件検索手段と、
この検索結果に基づいた情報をユーザ端末に送信する検
索結果回答手段とを備えたことを要旨とする。

【０００９】このように構成された売買仲介システムで
は、請求項１又は請求項２に記載の売買仲介サーバシス
テムの作用に加え、ユーザが購入する商品の条件に対し
て適切な価格を設定するための参考となる情報を得るこ
とが可能になるという作用がある。

【００１０】請求項４に記載の売買仲介サーバシステム
では、請求項３に記載の売買仲介サーバシステムの構成
に加え、前記検索結果回答手段は、検索が成功した場合
にはユーザ端末から送信された条件で前記購入データ記
憶手段に記憶し、検索に失敗した場合には最も条件が近
い商品相場についての情報と、ユーザ端末に条件の変更
を促す表示を含む画面をユーザ端末に表示させることを
要旨とする。

【００１１】このように構成された売買仲介サーバシス
テムでは、請求項３に記載の売買仲介サーバシステムの
作用に加え、その購入条件において相場に近い価格設定
の場合は、そのまま登録され、相場と異なる場合のみ価
格を含む購入条件の変更をユーザに促すことができると
いう作用がある。

【００１２】請求項５に記載の売買仲介サーバシステム
では、請求項１乃至請求項４のいずれかに記載の売買仲
介サーバシステムの構成に加え、前記購入を希望する商
品に関する条件には、ユーザの下取商品に関するデータ
を含み、前記見積データには、当該下取商品の下取価格
の見積も含むことを要旨とする。

【００１３】このように構成された売買仲介サーバシス
テムでは、請求項１乃至請求項４のいずれかに記載の売
買仲介サーバシステムの作用に加え、ユーザは自己の情
報を販売者に知られることなく、実際に商談に入る前に
匿名で自己の下取商品の下取価格を知ることができるた
め、販売者を気にせず購入について決定することができ
るという作用がある。

【００１４】請求項６に記載の売買仲介サーバシステム
では、請求項１乃至請求項５のいずれかに記載の売買仲
介サーバシステムの構成に加え、前記購入データには、
ユーザがローンを利用可能か否かの判断に必要なローン
判断情報を含み、前記ユーザ端末から送信された当該購
入データを受信してローン判断情報のみを抽出して所定
のローン会社に送信し、当該ローン会社から返信された
前記ユーザのローンの利用の可否に関する情報を、前記
見積データの送信までに前記ユーザ端末に送信すること
を要旨とする。

【００１５】このように構成された売買仲介サーバシス
テムでは、請求項１乃至請求項５のいずれかに記載の売
買仲介サーバシステムの作用に加え、商品の購入に必要
なローンについての情報を早い段階で得られるため、ユ
ーザ、販売者ともに商品の売買の成立を早めることがで
きるという作用がある。

【００１６】

【発明の実施の形態】（第１の実施形態）以下、本発明
を具体化した売買仲介サーバシステムを備えた売買仲介
システムの一の実施の形態を説明する。図１は売買仲介
サーバシステムを備えた売買仲介システムの構成と手続
の流れの概略を示す図である。まず、本システムの説明
に先立って本システムにより実現されるサービスの概略
について図１に沿って説明する。ここでは商品の一例と
して中古自動車の売買を例に説明をする。まず、複数の
ユーザ端末Ｃ（Ｃ−０１、Ｃ−０２、…）は中古自動車
の購入を希望するユーザの端末である。販売者端末Ａ
（Ａ−０１、Ａ―０２、…）は中古自動車を販売する者
の端末である。なお、特に区別しないときは、以下ユー
ザ端末Ｃ、販売者端末Ａという。仲介者サーバＢは、ユ
ーザ端末Ｃと販売者端末Ａとの取引の仲介を行うもので
ある。まず、販売者端末Ａから仲介者サーバＢにアクセ
スして販売者の企業情報を送信して販売者登録を行う。
販売者登録が完了したら、次にチケット発行依頼を行う
（図１：１）。チケットはプリペイドの仲介手数料であ
り、所定の料金の支払いを条件に発行される。なお、発
行されたチケットは仲介者サーバＢのチケットＤＢ（図
２参照）に電子的な記録として存在し、販売者番号であ
る販売者ＩＤ（Ａ−０１、Ａ−０１、…）毎にチケット
番号により管理される。

【００１７】一方、ユーザ端末Ｃは、購入したい中古車
の車種や仕様、年式、価格などの条件である購入条件を
仲介者サーバＢに送信する（図１：２）。中古車の購入
条件登録においては、仲介者サーバＢの相場ＤＢ（図２
参照）が参照される。相場ＤＢは、オークション等の実
際の商取引の実績に基づいて中古車の各種条件とその条
件での取引価格などが記憶されている。ユーザ端末Ｃか
ら購入したい自動車の条件が送信されると、その内容が
相場ＤＢで検索され、検索結果に応じてアドバイス若し
くは登録完了通知がユーザ端末Ａに返される（図１：
３）。

【００１８】このように仲介者サーバＢに購入条件登録
された内容は、販売者端末Ａから自由に閲覧ができる
（図１：４）。但し、ユーザの名前やメールアドレスに
関しては公表されておらず、たとえ販売者端末Ａが手持
ちに購入条件にあった販売用の自動車を所有していたと
しても、直接商談を行うことができない。ここで、商談
を進めたいユーザを発見したら、その販売者端末Ａから
仲介者端末Ｂに、見積登録の依頼を送信する（図１：
５）。このとき販売者端末Ａは、自己のＩＤとパスワー
ドを用いて仲介者サーバＢにアクセスするとともに、既
に発行されたチケット番号を通知する。仲介者サーバＢ
では、これらの番号等を照合し、そのＩＤの販売者端末
Ａに有効なチケットが存在すれば見積の依頼を受任する
とともに、通知されたチケット番号を消去することで課
金する（図１：５）。

【００１９】仲介者サーバＢはユーザ端末Ｃに見積を個
人データフォームとともに送信する（図１：６）。この
段階でもユーザ端末Ｃと販売者端末Ａは互いに名前やメ
ールアドレスを知り得ない。従ってユーザ端末Ｃでは、
望まない販売の申し出を受ける心配がない。その一方、
見積内容に合意した場合はユーザ自らの意思で個人デー
タフォームに本名等のデータを記入して送付すること
で、その自動車を販売している販売者に仲介者サーバＢ
を介して通知される。販売者もいわゆる冷やかしの客が
排除でき、かつ個人データフォームの内容が通知され販
売の可能性の高いユーザと直接商談に入ることができる
（図１：５）。

【００２０】次に、このようなサービスを実現させる本
発明を具体化した売買仲介サーバシステムを備えた売買
仲介システムの一実施形態を図１〜図２２に従って説明
する。図１に示すように、売買仲介システムは、売買仲
介サーバシステムの一例である仲介者サーバＢと、ここ
にインターネット２を介して接続されたクライアントコ
ンピュータシステムである販売者端末Ａと、同じくクラ
イアントコンピュータシステムであるユーザ端末Ｃとを
備える。

【００２１】ここで図２は仲介者サーバＢの構成の一例
を示す図である。仲介者サーバＢは、ＣＰＵ（Ｃｅｎｔ
ｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０、ＲＯ
Ｍ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１１、ＲＡＭ
（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２、
Ｉ／Ｆ（ＩｎｔｅｒＦａｃｅ）１４、 ＣＤ−ＲＯＭＤ
（Ｃｏｍｐａｃｔ Ｄｉｓｃ ＲＯＭ Ｄｒｉｖｅ）１
６、ＦＤＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｃ Ｄｒｉｖ
ｅ）１７、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ
）１８、表示手段１９であるＬＣＤ、ＣＲＴからなる
ディスプレー、入力手段２０として例えばキーボード、
マウスがバスを介して装着されている。またモデム（Ｍ
ＯＤＥＭ）１５がＩ／Ｆ１４を介してインターネット２
（図１参照）に通信可能に接続されている。もちろんデ
ジタル回線においてＴＡ、ＤＳＵにより接続されたり、
他のネットワークにおいてゲートウェイにより接続され
るようなものであってもよい。

【００２２】このように構成された仲介者サーバＢは、
ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバとして
ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）としてマ
イクロソフト社のウインドウズＮＴ（登録商標）がイン
ストールされ、ＨＴＴＰのプロトコルにより、ユーザ端
末Ｃや販売者端末Ａ等のクライアントＰＣから指定され
たＵＲＬのＨＴＭＬ形式の情報をＨ送信する。なおＯＳ
は、ウインドウズＮＴに限定されるものではなく、ウイ
ンドウズ２０００サーバ、Ｕｎｉｘ、Ｌｉｎｕｘ、Ｎｅ
ｔｗａｒｅ、ＢｅＯＳ等（以上登録商標）がインストー
ルされたサーバコンピュータにより構成されていてもよ
い。

【００２３】仲介者サーバＢは、インターネット２（図
１参照）を介して、ユーザ端末Ｃや販売者端末Ａと通信
可能に接続されている。本発明においてはデータの通信
が可能であればインターネット２に限らず如何なる構成
のものであってもよいが、ここでは一例としてインター
ネット２を用いたネットワークとして説明する。もちろ
ん、ピアトゥピアによる１対１の接続や、Ｅｔｈｅｒｎ
ｅｔ（登録商標）による閉鎖的なＬＡＮ（Ｌｏｃａｌ
Ａｒｅａ Ｎｅｔｗｏｒｋ）や、あるいは他のＷＡＮ
（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、公衆回線な
どでもよい。仲介者Ｂは、ＷＷＷサーバとしてクライア
ントＰＣとＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ
Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ
Ｐｒｏｔｏｃｏｌ）のプロトコルにより通信可能に構
成され、ユーザ端末Ｃや販売者端末Ａからの要求で、指
定されたＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ
Ｌｏｃａｔｏｒ）の情報を端末に送信する。

【００２４】さらに、仲介者サーバＢは、ＣＧＩ（Ｃｏ
ｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）の機
能を備えている。ユーザ端末Ｃや販売者端末Ａから仲介
者サーバＢにＣＧＩの起動要求があった場合は、ユーザ
端末Ｃや販売者端末Ａからの要求に応じ、特定のプログ
ラムを呼び出すようにＰｅｒｌ等の言語で記述されたス
クリプトによりプログラムされており、各データベース
の起動・検索などを行う。さらに、必要に応じてさらに
他のコンピュータに格納された各種のプログラムを呼び
出して起動させてユーザ端末Ｃや販売者端末Ａからの各
種の要求に応える。なお実施形態では仲介者サーバＢは
ウインドウズＮＴサーバとＣＧＩにより構成されている
が、ＣＧＩのほか、ＡＳＰ（Ａｃｔｉｖｅ Ｓｅｒｖｅ
ｒ Ｐａｇｅｓ）等を用いて構成することもできる。

【００２５】次にＨＤＤ１８に格納されたＤＢ（データ
ベース）等について説明する。ＨＤＤ１８には、上記Ｏ
Ｓ１８ａの外、仲介者サーバＢにおいて本発明を実行す
る後述のアプリケーション１８ｂが格納されている。ま
た、その他のプログラム１８ｃが格納される。ＤＢとし
ては、相場ＤＢ１８ｄ、購入条件ＤＢ１８ｅ、企業情報
ＤＢ１８ｆ、販売者ＤＢ１８ｇ、チケットＤＢ１８ｈが
備えられる。

【００２６】相場ＤＢ１８ｄは、予め他で実施されたオ
ークションの相場実績や雑誌等の販売価格が、車種、グ
レード、形状、色、ミッションなどの条件とともに記憶
され、ここを参照してユーザ端末Ｃから送信された購入
を希望する自動車の条件とマッチングをみて最も一致率
の高いデータを抽出する。この相場ＤＢ１８ｄが本発明
の相場情報記憶手段に相当する。

【００２７】購入条件ＤＢ１８ｅは、ユーザ端末Ｃから
送信された購入を希望する自動車の条件とユーザのメー
ルアドレスを地域別に蓄積しておき、購入を希望する自
動車の条件のみを販売者端末Ａに対して閲覧可能に記憶
しておく。この購入条件ＤＢ１８ｅが本発明の購入デー
タ記憶手段に相当する。

【００２８】企業情報ＤＢ１８ｆは、販売者登録のとき
にその販売者の名称、所在地等を販売者ＩＤと関連づけ
て記憶しておく。

【００２９】販売者ＤＢ１８ｇは、販売者のＩＤと、Ｐ
Ｗ（パスワード）を関連付けて記憶しておき、販売者端
末１８ｇからのアクセスの認証を行うために用いる。

【００３０】チケットＤＢ１８ｈは、販売者のＩＤと、
発行済みのチケット番号を記憶しておき、見積の送付依
頼時に課金のために消去し、プリペイドされた残金の管
理を行う。このチケットＤＢ１８ｈは、本発明のチケッ
ト発行データ記憶手段に相当する。

【００３１】以上のように構成された仲介者サーバＢで
は、格納されたプログラムにより以下のような手順を実
行する。ここで、図３は、仲介者サーバＢにおいて実行
されるメインルーチンの概略を示すフローチャートであ
る。まず処理が開始されると（開始）、モデム１５、Ｉ
／Ｆ１４から入力されたデータが解析される。そして、
そのデータが販売者登録のためのデータか否かが判断さ
れる（ＳＢ１）。販売者登録のためのデータと判断され
れば（ＳＢ１：ＹＥＳ）、販売者登録の処理が行われる
（ＳＢ２）。そのデータが販売者登録のためのデータで
ないと判断されれば（ＳＢ１：ＮＯ）、チケット発行の
ためのデータか否かが判断される（ＳＢ３）。

【００３２】チケット発行のためのデータと判断されれ
ば（ＳＢ３：ＹＥＳ）、チケット発行の処理が行われる
（ＳＢ４）。そのデータがチケット発行のためのデータ
でないと判断されれば（ＳＢ３：ＮＯ）、購入条件登録
のためのデータか否かが判断される（ＳＢ５）。

【００３３】購入条件登録のためのデータと判断されれ
ば（ＳＢ５：ＹＥＳ）、購入条件登録の処理が行われる
（ＳＢ６）。そのデータが購入条件登録のためのデータ
でないと判断されれば（ＳＢ５：ＮＯ）、販売者閲覧の
ためのデータか否かが判断される（ＳＢ７）。

【００３４】販売者閲覧のためのデータと判断されれば
（ＳＢ７：ＹＥＳ）、販売者閲覧の処理が行われる（Ｓ
Ｂ８）。そのデータが販売者閲覧のためのデータでない
と判断されれば（ＳＢ７：ＮＯ）、見積申出のためのデ
ータか否かが判断される（ＳＢ９）。

【００３５】見積申出のためのデータと判断されれば
（ＳＢ９：ＹＥＳ）、見積申出の処理が行われる（ＳＢ
１０）。そのデータが見積申出のためのデータでないと
判断されれば（ＳＢ９：ＮＯ）、処理が終了されるか否
かが判断される（ＳＢ１１）。

【００３６】処理が終了と判断されると（ＳＢ１１：Ｙ
ＥＳ）、処理が終了され（終了）、処理が終了でないと
判断されれば（ＳＢ１１：ＮＯ）、再びＳＢ１からの処
理が繰り返される。

【００３７】次に、販売者登録及びチケット発行の処理
の手順について説明する。図４は、図３におけるＳＢ１
からＳＢ４に示す販売者登録及びチケット発行の処理の
手順を詳細に示す仲介者サーバＢにおけるフローチャー
トと、これに対応する販売者端末Ａにおけるフローチャ
ートである。

【００３８】まず、販売者端末Ａからチケット発行ペー
ジの要求を仲介者サーバＢに送信する（ＳＡ２０）。こ
のチケット発行ページの要求を受信した仲介者サーバＢ
は、販売者端末Ａにチケット発行ページを送信する（Ｓ
Ｂ２１）。チケット発行ページが受信され（ＳＡ２
１）、図示しないチケット発行ページが表示された販売
者端末Ａの画面において販売者が登録を選択した場合は
（ＳＡ２２：ＹＥＳ）、販売者登録画面が表示される。

【００３９】ここで、図５は販売者登録画面の一例を示
す図である。販売者登録画面には、申込日、地域、会社
名、担当者名前、郵便番号、住所、電話番号、ｆａｘ番
号、ｅ−ｍａｉｌ、購入枚数を記入する欄が表示され
る。なお、記入を容易にするために適宜プルダウンメニ
ューを準備する。必要な事項を入力したら送信ボタンを
操作することで、データが仲介者サーバＢに送信される
（ＳＡ２３）。また、このときに併せてチケット発行依
頼をすることもできる。なお、フローチャートには記載
していないが、登録データを受信した仲介者サーバＢは
内容に不備があった場合はこれを修正するように販売者
端末Ａに修正画面を送信する。登録データを受信した仲
介者サーバＢは（ＳＢ２３）、販売者ＤＢ１８ｇに販売
者のＩＤとＰＷを関連づけて記憶するとともに（図８参
照）、販売者のＩＤと企業情報を関連づけて企業情報Ｄ
Ｂ１８ｆに記憶することで販売者の登録・保存行い、登
録が完了した旨のメッセージを販売者端末Ａに送信する
（ＳＢ２４）。このメッセージを販売者端末Ａが受信す
ると（ＳＡ２４）、登録処理が完了する。

【００４０】販売者端末Ａがチケットの発行を望んだ場
合は（ＳＡ２５：ＹＥＳ）、ＩＤとＰＷにより仲介者サ
ーバＢにアクセスして、チケット枚数を含むチケット発
行依頼を送信する（ＳＡ２６）。一方、仲介者サーバＢ
は、チケット発行の場合は（ＳＢ２５：ＹＥＳ）、チケ
ット枚数を含むチケット発行依頼を受信する（ＳＢ２
６）。ここで、図８は、販売者ＤＢ１８ｇの記憶内容を
概念的に示す図である。販売者ＤＢ１８ｇには、販売者
のＩＤとＰＷが関連づけられて記憶されており、例え
ば、ＩＤが「Ａ−０１」であれば、ＰＷが「ＧＯＭＡ０
１」のときに正しい販売者として認証するためのテーブ
ルデータである。チケット発行依頼を受信した仲介者サ
ーバＢは、この販売者ＤＢ１８ｇにより、販売者の認証
を行い（ＳＢ２７）、正しく認証された場合は（ＳＢ２
７：ＹＥＳ）、要求された枚数、固有の連番を付与して
チケットを発行する。

【００４１】ここで、図７は、チケットＤＢ１８ｈの記
憶内容を概念的に示す図である。例えば、正しく認証さ
れた販売者のＩＤがＡ−０１であり、購入枚数が１００
であった場合、例えば「０００００１」から「０００１
００」までの１００枚のチケット番号を付与して、この
チケットＤＢ１８ｈに記憶する。また、このときの枚数
に応じた料金の請求を指定のクレジット会社や金融機関
におこなう（不図示）。図６は、仲介者サーバＢから販
売者端末Ａに送信するチケット番号を概念的に示す図で
ある。仲介者サーバＢで発行されたチケット番号が販売
者端末Ａに送信され（ＳＢ２８）、販売者端末Ａは認証
がされた場合は（ＳＡ２７：ＹＥＳ）、これを受信して
所定の記憶手段に記憶する（ＳＡ２８）。

【００４２】なお、チケット発行でない場合（ＳＡ２
５：ＮＯ、ＳＢ２５：ＮＯ）や、チケット発行依頼をし
たが認証に失敗したときは（ＳＡ２７：ＮＯ、ＳＡ２
７：ＮＯ）、チケット番号の送信（ＳＢ２８）・受信
（ＳＡ２８）はされず、ＳＡ２９、ＳＢ２９に移行す
る。更に販売者登録やチケット発行を行いたい場合には
（ＳＡ２９：ＮＯ、ＳＢ２９：ＮＯ）、ＳＡ２２、ＳＢ
２２に戻り、処理が続行される。続行すべき手続がなけ
れば（ＳＡ２９：ＹＥＳ、ＳＢ２９：ＹＥＳ）、処理を
終了する（終了）。

【００４３】次に、図９は、図３におけるＳＢ６に示す
購入条件登録の処理の手順を詳細に示す仲介者サーバＢ
におけるフローチャートとこれに対応するユーザ端末Ｃ
におけるフローチャートである。

【００４４】まずユーザ端末Ｃから仲介サーバＢのホー
ムページにアクセスして、ホームページの購入条件登録
ページの要求を送信し（ＳＣ３０）、仲介サーバＢはこ
の購入条件登録ページの要求を受信する（ＳＢ３０）。
購入条件登録ページの要求を受信した仲介サーバＢは、
要求された購入条件登録ページを送信し（ＳＢ３１）、
ユーザ端末Ｃは、この購入条件登録ページを受信する
（ＳＣ３１）。ここで図１０は、ユーザ端末Ｃに表示さ
れる購入条件登録ページの一例を示す。図１０に示す購
入条件登録ページは、名前、Ｅ−ｍａｉｌ、地域、年齢
を含む個人情報と、車名、グレード、希望価格、年式、
走行距離、第１希望の色、第２希望の色、ミッション、
形状、その他の希望事項、お支払い方法のご予定、下取
り車の有無を含む車両情報を入力するように構成されて
いるが、これらの項目はその取引形態に合わせて追加や
削除が可能である。

【００４５】ユーザ端末Ｃにより購入条件登録ページに
必要な事項が入力されると（ＳＣ３２）、購入条件登録
ページの送信ボタンを操作することで、入力済みの購入
条件登録ページが仲介サーバＢに送信される（ＳＣ３
３）。仲介サーバＢは入力済みの購入条件登録ページを
受信すると（ＳＢ３３）、その内容から、特定の事項を
抽出し、ユーザが入力した条件と同じ条件のデータがな
いか相場ＤＢ１８ｄを検索をする（ＳＢ３４）。このＳ
Ｂ３４の手順が仲介者サーバＢを本発明の購入条件検索
手段として機能させる。相場ＤＢ１８ｄは、各地のオー
クションの実績価格や中古車販売店などの販売価格を、
車名、グレード、年式、走行距離、第１希望の色、第２
希望の色、ミッション、形状、その他の情報とともに入
力し蓄積したデータベースである。

【００４６】検索は、仲介サーバＢに送信された入力済
みの購入条件登録ページからデータを抽出し、このデー
タを相場ＤＢ１８ｄに入力されたデータを参照してマッ
チングを見て、最も条件に近いデータを抽出する。この
判断には、データ毎に優先順位を付けて、例えば車種は
最も高い優先順位とし、次に形状、グレードの順に優先
順位を付け、走行距離・価格は低い優先順位とする。若
しくは優先順位から外す。或いは、各項目毎に重みを付
けてポイントを計算するようにしてもよい。例えば、車
種の重みが１０、形状は５のようにして重みを設定し、
一致した場合にはこのポイントを加算し、その合計で最
も一致率の高いものを選択する。このようにすることで
ユーザの希望する車両と同一か、最も近い条件の車両が
抽出できる。

【００４７】ここで、相場ＤＢ１８ｄから所定の条件を
満たすデータが検索できたら（ＳＢ３５：ＹＥＳ）、入
力された購入条件が妥当であるとして、購入条件の変更
を促すメッセージなしに直ちに購入条件登録を行う（Ｓ
Ｂ４０）。ユーザー端末Ｃにおいては、入力済みの購入
条件登録ページを送信した後（ＳＣ３３）、仲介サーバ
Ｂで検索に成功した場合は（ＳＣ３５：ＹＥＳ）、登録
完了ページが表示される（ＳＣ４０）。ここで、図１３
は、仲介サーバＢからユーザ端末Ｃに送信され表示され
る登録完了ページの一例を示す図である。

【００４８】一方、完全に一致するデータが検索できな
かった場合は、検索が成功しなかったとして（ＳＢ３
５：ＮＯ）、さらにこの場合、ユーザの入力したデータ
と相場ＤＢに入力されたデータとが、価格のみの不一致
かどうかを判断し（ＳＢ３６）、価格のみの不一致であ
れば（ＳＢ３６：ＹＥＳ）、価格のみの変更を促すペー
ジを送信する（ＳＢ３７）。ここで図１１は、抽出した
データがユーザの希望する条件と価格のみが一致しなか
った場合に、仲介者サーバＢからユーザ端末Ｃに送信す
るページの一例を示す図である。ユーザ端末Ｃでは、検
索が成功せず（ＳＣ３５：ＮＯ）、それが価格のみ不一
致である場合（ＳＣ３６：ＹＥＳ）、この価格の変更を
促すページが表示される（ＳＣ３７）。

【００４９】このときユーザは価格を変更して購入条件
登録したいときは、「変更」のボタンを操作すると、購
入条件変更であるとして（ＳＣ３９：ＹＥＳ）、再び購
入条件登録の入力画面に戻る（ＳＣ３２）。ユーザ端末
Ｃでは、購入条件登録ページ入力画面において、価格を
変更することができる。なお、その価格で購入を希望し
ている場合は、他の条件を変更することもできる。

【００５０】一方、ユーザはその購入条件を変えないま
ま売り手を探したいと思ったときは、画面に表示された
「決定」のボタンを操作すると購入条件を変更しないと
して（ＳＣ３９：ＮＯ）、データ入力が完了したことが
仲介サーバＢに送信され（ＳＣ４０）、仲介サーバＢは
最初の購入条件のまま購入条件登録を行う（ＳＢ４
０）。

【００５１】価格以外の条件が異なる場合は（ＳＢ３
６：ＮＯ）、仲介サーバＢは、価格以外の購入条件の変
更を促すページをユーザ端末Ｃに送信する（ＳＢ３
８）。ユーザ端末Ｃでは、価格以外の購入条件が異なる
場合は、価格以外の購入条件の変更を促すページが表示
される（ＳＣ３７）。ここで図１２は、抽出したデータ
がユーザの希望する購入条件と価格以外も一致しなかっ
た場合に、仲介者サーバＢからユーザ端末Ｃに送信する
ページの一例を示す図である。このときユーザは購入条
件を変更して購入条件登録したいときは、「変更」のボ
タンを操作すると、購入条件変更として、再び購入条件
登録の入力画面に戻る（ＳＣ３９：ＹＥＳ）。また、ユ
ーザはその条件で売り手を探したいと思ったときは、画
面に表示された「決定」のボタンを操作すると購入条件
を変更しないとして（ＳＣ３９：ＮＯ）、その旨が仲介
サーバＢに送信され（ＳＣ４０）、仲介サーバＢは購入
条件登録を行う（ＳＢ４０）。購入条件登録は、仲介サ
ーバＢの購入条件ＤＢ１８ｅに、ユーザ端末Ｃからの条
件が閲覧可能に記憶されることでおこなわれる。なお、
ＳＢ３７，ＳＢ３８の手順が仲介者サーバＢを本発明の
検索結果回答手段として機能させる。

【００５２】仲介サーバＢで購入条件登録が完了したら
（ＳＢ４０）、仲介サーバＢは、登録完了ページをユー
ザ端末Ｃに送信し（ＳＢ４１）、ユーザ端末Ｃにこのペ
ージが表示され（ＳＣ４１）、処理が完了する（終
了）。

【００５３】次に、図１４は、図３におけるＳＢ８に示
す販売者閲覧の処理の手順を詳細に示す仲介者サーバＢ
におけるフローチャートとこれに対応する販売者端末Ａ
におけるフローチャートである。販売者閲覧の処理で
は、まず購入条件登録された内容の購入条件閲覧要求
が、販売者端末Ａから仲介者サーバＢに送信される（Ｓ
Ａ５０）。そうすると閲覧のトップページが仲介者サー
バＢから販売者端末Ａに送信される（ＳＢ５１）。販売
者端末Ａにはこうして送信された閲覧トップページが表
示される（ＳＡ５２）。

【００５４】ここで、図１５は、仲介者サーバＢから販
売者端末Ａに送信され表示される見積依頼リストの閲覧
トップページの一例を示す図である。ここでは、ユーザ
端末Ｃから送信された購入条件から地域情報を抽出し
て、この地域情報毎にユーザの購入条件が分類されてい
る。ここでは希望の地域の表示をマウスクリックなどの
方法で特定すれば閲覧条件が販売者端末Ａから仲介者サ
ーバＢに送信され（ＳＡ５３）、仲介者サーバＢで閲覧
条件を受信すると、その条件に合致した該当ページを販
売者端末Ａに送信する（ＳＢ５４）。

【００５５】ここで図１６は、例えば図１５に示すトッ
プページにおいて、閲覧条件として「中国」が指定され
た場合に販売者端末Ａに表示される見積依頼リストの画
面の一例を示す図である。このように、図１５におい
て、例えば「中国」を指定すれば、購入条件登録された
時に付与される固有のユーザ登録番号、登録の受付日、
さらに詳細な地域、購入希望価格、車種等が一覧表示さ
れる。このように地域別に表示することで、販売者が実
際に販売可能なエリアと一致させることができる。もち
ろん、ここでの閲覧は必ずしも地域別に限らず、任意の
分類が可能である。例えば、車種別などであってもよ
い。さらに販売する商品の特性により様々な属性での分
類による閲覧が考えられる。

【００５６】さらに、詳細な購入条件を見たい場合は、
（ＳＡ５６：ＮＯ）、詳細データを表示させるためのボ
タンを操作することで、詳細データを閲覧するという閲
覧条件が再度仲介者サーバＢに送信され（ＳＡ５３）、
これを受信した仲介者サーバＢから、詳細なデータを表
示するページが送信され（ＳＢ５４）、販売者端末Ａは
該当ページを受信して（ＳＡ５５）、販売者端末Ａの画
面に表示される。ここで、図１７は、仲介者サーバＢか
ら販売者端末Ａに送信される詳細なデータを示す画面の
一例を示す図である。図１７に示すように、この詳細情
報では、ユーザによる条件登録された受付日、ユーザ登
録番号、車種、価格、年式、走行距離、グレード、形
状、色、下取り有無、地域、ミッション、支払予定等が
表示される。但し、この段階ではユーザの名前、ｅ−ｍ
ａｉｌ等は公表されない。従って、このデータを見ても
販売者は見積を送付したり、商談を進めることは不可能
になっている。販売者がこのデータをみて商品の提供が
可能なユーザを発見した場合は、ユーザ登録番号（図１
６参照）によりユーザを特定しておく。このようにし
て、ユーザ登録番号のリストアップが終了したら（ＳＡ
５６：ＹＥＳ）、図示しない終了ボタンを操作して、処
理を終了する（終了）。また、仲介者サーバＢも終了す
る旨を受信して処理を終了させる（ＳＢ５７、終了）。

【００５７】次に、図１８及び図１９は、図３における
ＳＢ１０に示す見積送信依頼の処理の手順を詳細に示す
仲介者サーバＢにおけるフローチャートとこれに対応す
る販売者端末Ａ、ユーザ端末Ｃにおけるフローチャート
である。見積送信依頼の処理は、まず、フローチャート
には示していないが、販売者端末Ａは、予め仲介者サー
バＢにＩＤ、ＰＷでアクセスをして、所定のオファーデ
ータ入力ページを受信する。ここで、図２０は、販売者
端末Ａから仲介者サーバＢに送信されるオファーデータ
入力ページの一例を示す図である。このオファーデータ
入力ページに、見積データである車種、グレード、年
式、走行距離、色、ミッション、形状、車検の有無、そ
の他詳細データ及びセールスポイント、参照写真、諸費
用込み販売価格等の情報の外、見積を送付したいユーザ
のユーザ登録番号と、登録済みのチケット番号と、販売
店の会社名（又はＩＤ）と、担当者の名前が入力され
る。そしてこのオファーデータ入力ページに入力が完了
したら送信ボタンを操作してオファーデータを送信する
（ＳＡ６０）。

【００５８】仲介者サーバＢは、このオファーデータを
受信すると、受信したオファーデータのＩＤとチケット
番号を、チケットＤＢ１８ｈ（図７参照）で照合する
（ＳＢ６０）。このＳＢ６０の手順が仲介者サーバＢを
本発明のオファーデータ受信手段として機能させる。こ
こで、指定のチケット番号が、指定されたＩＤに対して
発行されていなければ、認証が失敗として（ＳＢ６１：
ＮＯ）、エラーメッセージを販売者端末Ａに送信して
（ＳＢ６２）、処理を終了する（終了）。

【００５９】一方、認証が成功した場合は（ＳＢ６１：
ＹＥＳ）、販売者端末Ａから送信されたチケット番号を
チケットＤＢ１８ｈから消去し（ＳＢ６３）、この番号
での認証をできなくする。つまり、販売者端末Ａにより
プリペイドされチケット番号により管理されたオファー
（見積送信）を行う金銭的権利が消滅する。このＳＢ６
０〜ＳＢ６１の手順が仲介者サーバＢを本発明のチケッ
ト番号照合手段として機能させる。また、 ＳＢ６３の
手順が仲介者サーバＢを本発明の課金手段として機能さ
せる。

【００６０】仲介者サーバＢは、見積データと個人デー
タフォームをユーザ登録番号で特定されるｅ−ｍａｉｌ
アドレスのユーザに送信する（ＳＢ６４）。このＳＢ６
４の手順が仲介者サーバＢを本発明の見積データ送信手
段として機能させる。ユーザ端末Ｃは、見積データ及び
個人データフォームをメールサーバを介して電子メール
で受信する（ＳＣ６４）。ここで、図２１は、仲介者サ
ーバＢから、ユーザ端末Ｃに送信される見積データの一
例を示す図である。ここには、車両に関するデータの
外、受付番号、受付日、見積発行日、ユーザのｅ−ｍａ
ｉｌ、ユーザの名前、有効期間が記載される。また、図
２２は、仲介者サーバＢから送信され、ユーザ端末Ｃに
おいて記入、返送される個人データフォームの一例を示
す図である。ここで、図１７は、それぞれ接続子α、
β、γ、δを介して図１８のフローチャートに続く。

【００６１】「有効期間」は、ユーザが販売者に対して
返信をする期限で、この期限内に返信がなければこのオ
ファーは不成立に終わったことになる（ＳＣ６５：Ｎ
Ｏ、ＳＢ６５：ＮＯ、ＳＡ６５：ＮＯ）。そしてこの処
理は終了される（終了）。また、フローチャートでは記
載を省略しているが、有効期限内であっても、ユーザが
図２１に示す「見送る」ボタンを操作した場合は、仲介
者サーバＢにその旨の通知がなされ、さらに販売者端末
Ａにも、仲介者サーバＢを介して通知され、同様に処理
が終了される。なお、この段階では、販売者に関するデ
ータはユーザ端末に連絡されないため、ユーザが仲介者
サーバＢを省いて直接商談することはできない。

【００６２】ユーザは、この見積データを見て、実際に
商談を進めたいと考えた場合は、有効期限内に、仲介者
サーバＢに返信を行う（ＳＣ６５：ＹＥＳ）。この場
合、「実際に見てみる」のボタンを操作すると、ユーザ
端末Ｃに個人データフォーム入力画面が表示され、ここ
にユーザに連絡ができるようにユーザの氏名、住所、Ｔ
ＥＬ、ｆａｘ番号、ｅ−ｍａｉｌの入力を促す。また、
販売者に要望がある場合などは、「その他要望」とし
て、入力することができる。さらに、下取り車がある場
合は、「下取り車見積」のボタンを操作すると、図示を
省略した図２０に示すような画面と類似した下取り車の
詳細なデータを入力する画面が表示される。但し、図２
０に示す画面と異なりユーザ登録番号、チケット番号、
会社名（ＩＤ）、担当者氏名、諸費用込み販売価格など
の項目はない。また、送信ボタンに変えて完了ボタンが
あり、入力完了後このボタンを操作すると個人データフ
ォームの入力画面に戻る。また、ユーザがオートローン
の予備審査若しくは申し込みをしたい場合は、オートロ
ーン申込みのボタンを操作すると、図示を省略したロー
ン入力フォームが表示される。ここにユーザの勤務先、
収入、金融機関などのデータを入力し、完了ボタンを操
作すると個人データフォーム入力画面に戻る。

【００６３】以上入力が完了したら送信ボタンを操作す
ることで、ユーザ端末Ｃから仲介者サーバＢに個人デー
タフォームが送信される（ＳＣ６６）。仲介者サーバＢ
は、個人データフォームを受信すると（ＳＢ６６）、こ
の個人データフォームを販売者に送信する（ＳＢ６
７）。このＳＢ６６、ＳＢ６７の手順が仲介者サーバＢ
を本発明の個人データ・企業情報送信手段として機能さ
せる。販売者端末Ａでは、仲介者サーバから送信された
個人データフォームを受信して（ＳＡ６７）、このデー
タに基づいて、直接ユーザとの商談を進行させたり、下
取り車の見積を送付したり、オートローンの審査結果を
連絡したりする。また、実車をユーザに直接見せたりし
てもよい。

【００６４】一方、仲介者サーバでは販売者登録（図
３：ＳＢ２）の手順で登録された販売者の企業データを
ユーザに送信する（ＳＢ６８）。ユーザ端末Ｃでは、こ
の企業データを受信し（ＳＣ６８）、商談の参考資料と
して使用する。

【００６５】以上で、仲介者サーバＢによる商品売買の
仲介は終了する（終了）。以後の商談に関しては、本発
明に直接関係しないため、詳細な説明は省略する。もち
ろん仲介者サーバＢが関与することを妨げるものではな
いが、この段階では、既に課金が終了しており、商談を
開始するまでのユーザのプライバシーを保護できたので
仲介者サーバＢの役割が終了する。以後は、販売者とユ
ーザにより商談を行う。

【００６６】上記実施の形態の売買仲介システムの売買
仲介サーバシステムによれば、以下のような効果があ
る。 ○ 購入データ記憶手段である購入条件ＤＢ１８ｅの内
容を販売者端末Ａからの要求に応じて閲覧させ、予めチ
ケットＤＢ１８ｈに記憶されたチケットにより課金を行
なった場合のみ販売者からのオファーデータをユーザに
見積データとして送信し、そのときから初めて商談が可
能になるため、課金の漏れが生じないという効果があ
る。 ○ また、ユーザ自身の意思による連絡がない限り商談
が開始できず、ユーザの個人情報を商談開始まで販売者
に伝えないことでユーザの個人情報を保護することがで
きるという効果がある。また、ユーザは販売者に気兼ね
せずにじっくり内容を検討することができる。また、望
まないダイレクトメールなどに利用されることがない。 ○ ユーザが購入したい商品の購入条件の登録に際し
て、ユーザの設定する価格が、相場から外れた場合、相
場ＤＢ１８ｄから抽出された市場における相場の実績を
表示して適切な価格を設定させるため、ユーザが早く車
を入手したい場合は相場に近い金額を提示し、時間がか
かっても安く入手したい場合は相場に比較して安い金額
を提示すれば希望通りの車を探すことができる。 ○ 検索結果回答手段であるＳＢ３４〜ＳＢ３８により
実行されるコンピュータは、検索が成功した場合には
（ＳＢ３５：ＹＥＳ）、ユーザからの購入条件で購入デ
ータ記憶手段に記憶し（ＳＢ４０）、検索に失敗した場
合には最も条件が近い商品相場についての情報と、ユー
ザに条件の変更を促す表示を含む画面を表示させる（Ｓ
Ｂ３７、ＳＢ３８）ため、相場にあった購入条件の登録
がという効果がある。 ○ 仲介者サーバＢは、見積を送付する販売者から確実
に課金できるという効果がある。またチケット番号の誤
用の場合は、正しく認証されないため（図１８：ＳＢ６
１）、誤用が防止される。さらに、他人のチケット番号
を利用して、関係のない他人が盗用することが防止され
るので、極めて安全な方法となる。つまり、もし販売者
Ａ−０１が正規にチケットの発行を受けた場合、これを
販売者Ａ−０２が販売者Ａ−０１のＩＤとＰＷ、チケッ
ト番号を盗用して、不正にユーザ端末Ｃに見積を送付し
たとしても、見積に対する商談の申し込みは、販売者Ａ
−０１の企業データがユーザ端末Ｃに送付されているた
め（図１９：ＳＢ６８）、販売者Ａ−０１にされてしま
う。従って、販売者Ａ−０１以外のものが、いくらＩＤ
・ＰＷ・チケット番号を盗んで販売者Ａ−０１のチケッ
トを盗用しようとしても不可能である。そのため効果的
に盗用を防止できるという効果がある。

【００６７】なお、上記実施形態は以下のように変更し
てもよい。 ○ 上記説明のフローチャートは本発明を実施するため
の一例に過ぎず、処理の順序を始め、例えばイベントに
よる割り込みを発生させるような処理を行うようなもの
であってもよく、要は、発明が実施可能であればよい。 ○ 本実施の形態のサーバの構成は、１つのコンピュー
タの１つのＨＤＤ１８に全てのデータが記憶されている
が、もちろんウエブサーバ、データベースサーバ、ＤＮ
Ｓ等に分けて構成されてもよい。また、記憶媒体はＨＤ
Ｄに限定されるものではなく、各種の磁気記録媒体、光
磁気記憶媒体、半導体記憶媒体等データの記憶ができれ
ばその方法は問わない。 ○ また、ソフトウエア、データベースは説明の便宜上
分けて説明しているが、これらが一体化したり、逆に分
散した形態でもよく、要は本発明が実施可能であればよ
い。 ○ ネットワークへの接続は、その情報電送媒体も光フ
ァイバー・メタル、アナログ・デジタル、またこれらを
制御する機器もモデム、ＴＡ、ＤＳＵ等種々あるが、い
ずれの方法であってもよい。 ○ また、見積などは、説明の便宜上一人の販売者から
のみ見積の提示があった場合を説明したが、もちろん複
数人から見積の提示があった場合でもよい。

【００６８】（第２の実施の形態）以下、本発明を具体
化した売買仲介サーバシステムの第２の実施の形態を説
明する。なお、第２の実施形態は、第１の実施形態の下
取り車見積のタイミングを変更したのみの構成であるた
め図示は省略し、同様の部分についてはその詳細な説明
を省略する。

【００６９】第２の実施の形態では、下取り車の見積に
必要な情報を、ユーザ端末Ｃの個人データフォームの返
送時に仲介者サーバＢに返送していたが、この下取り車
の見積に必要な情報を、ユーザの購入条件登録時（図
９：ＳＣ３３、ＳＢ３３）に行うようにしてもよい。つ
まり、この場合、下取り車の査定に必要な情報がユーザ
の購入条件登録とともに記憶され（ＳＢ４０）、販売者
端末Ａによるユーザの購入条件閲覧（図１４：ＳＢ５
４、ＳＡ５４）において、この下取り車の見積が可能な
情報を得ることができる。そのため、販売者による見積
登録の際（図１８：ＳＡ６０）には、販売者がユーザに
販売する車両の見積とともに、下取り車の査定価格の提
示も行い、最終的な差額がいくらになるかという取引の
条件をユーザに提示することができる（図１８：ＳＣ６
４）。

【００７０】このように構成された第２の実施の形態で
は、下取り価格も商談前に明らかになれば、ユーザは購
入する車両の価格のみならず、下取り車の引き取り価格
をあわせた総合的な条件を早い段階で検討することがで
きる。また、この段階では、ユーザの情報は未だ販売者
端末Ａには送信されていないので、ユーザは、気兼ねな
く情報を収集して商談を進めるか止めるかを決定するこ
とができる。つまり、通常下取り査定をしてもらうため
には自己の氏名等を明らかにする必要があり、下取り査
定をしてもらった場合、その業者に気兼ねをしたり、し
つこい販売を受ける可能性があるが、本実施の形態では
そのような心配がない。

【００７１】（第３の実施の形態）以下、本発明を具体
化した売買仲介サーバシステムの第３の実施の形態を説
明する。なお、第３の実施形態は、第１の実施の形態の
オートローンの予備審査の申し出の手続を変更したのみ
の構成であるため図示は省略し、同様の部分については
その詳細な説明を省略する。

【００７２】第３の実施の形態では、第１の実施の形態
において、仲介者サーバＢからユーザ端末Ｃに送信され
る購入条件登録ページ（図９：ＳＢ３１、ＳＣ３１）に
は、ユーザがローン（信用販売）のための信用調査に必
要なデータ、例えば、正しい住所、氏名、生年月日、勤
務先、勤務年数、保証人、取引金融機関、利用している
クレジットカード、年収、利用金額等のデータの記入欄
が設けられ、ユーザはユーザ端末Ｃにおいて入力してか
ら、入力済み購入条件登録購入ページとともに送信され
る（ＳＣ３３、ＳＢ３３）。これを受信した仲介サーバ
Ｃは、その後これをローン会社の端末に転送する（不図
示）。これを受け取ったローン会社の端末では、ローン
の利用の可否を予備審査し、ローン利用の可否に関する
情報を仲介者サーバＣに送信する（不図示）。仲介者サ
ーバＣは、当該ローン会社の端末から送信されたユーザ
のローンの利用の可否に関する情報を、遅くとも見積デ
ータとともに前記ユーザ端末Ｃに送信する（図１８：Ｓ
Ｂ６４、ＳＣ６４）。なお、このデータは販売者端末Ａ
には送信されず、ユーザの個人情報は、ローン会社と仲
介者サーバ以外は知り得ない。

【００７３】このように構成された第３の実施の形態で
は、商品の購入に必要なローンについての情報を早い段
階で得られるため、ユーザ、販売者ともに商品の売買の
成立を早めることができるという効果がある。

【００７４】（定義） ○ 本出願において「チケット」とは、販売者端末Ａに
よりプリペイドされチケット番号により管理されたオフ
ァー（見積送信）を行う債権的権利の象徴であり、「チ
ケットの発行」とは、そのような債権状態を是認するこ
とで、現実に紙媒体による印刷や画面表示がなされるわ
けではない。 ○ 本出願において「送信」とは、オンラインの状態で
送信側が受信側に直接データを送信するだけでなく、受
信側が電子メールを取得可能なメールサーバに送信側が
電子メールを送信するような態様も含むものとする。

【００７５】以上、本発明を実施の形態により説明した
が、本発明は上記実施の形態に限定されるものではな
く、特許請求の範囲の記載を逸脱しない範囲で当業者に
より変形され、改良されて実施されうる。例えば、商品
は中古自動車に限定されるものではなく、他の中古機械
などのほか、旅行のパッケージや建築請負など種々の業
種において実施できるものである。

【００７６】

【発明の効果】以上詳述したように、売買仲介サーバシ
ステムでは、ネットワークにおいて行われる売買におい
てユーザの個人情報を保護しつつ、かつ販売者に対して
確実な課金をおこなうことができ、ユーザの価格設定も
容易になるという効果がある。

【図面の簡単な説明】

【図１】 本システムにより実現されるサービスの概略
について示す図。

【図２】 仲介者サーバＢの構成の一例を示す図。

【図３】 仲介者サーバＢにおいて実行されるメインル
ーチンの概略を示すフローチャート。

【図４】 図３におけるＳＢ１からＳＢ４に示す販売者
登録及びチケット発行の処理の手順を詳細に示す仲介者
サーバＢにおけるフローチャートと、これに対応する販
売者端末Ａにおけるフローチャート。

【図５】 販売者登録画面の一例を示す図。

【図６】 仲介者サーバＢから販売者端末Ａに送信する
チケット番号を概念的に示す図。

【図７】 チケットＤＢ１８ｈの記憶内容を概念的に示
す図。

【図８】 販売者ＤＢ１８ｇの記憶内容を概念的に示す
図。

【図９】 図３におけるＳＢ６に示す購入条件登録の処
理の手順を詳細に示す仲介者サーバＢにおけるフローチ
ャートとこれに対応するユーザ端末Ｃにおけるフローチ
ャート。

【図１０】 ユーザ端末Ｃに表示される購入条件登録ペ
ージの一例を示す図。

【図１１】 抽出したデータがユーザの希望する購入条
件と価格のみが一致しなかった場合に、仲介者サーバＢ
からユーザ端末Ｃに送信するページの一例を示す図。

【図１２】 抽出したデータがユーザの希望する購入条
件と価格以外も一致しなかった場合に、仲介者サーバＢ
からユーザ端末Ｃに送信するページの一例を示す図。

【図１３】 仲介サーバＢからユーザ端末Ｃに送信され
表示される登録完了ページの一例を示す図。

【図１４】 図３におけるＳＢ８に示す販売者閲覧の処
理の手順を詳細に示す仲介者サーバＢにおけるフローチ
ャートとこれに対応する販売者端末Ａにおけるフローチ
ャート。

【図１５】 仲介者サーバＢから販売者端末Ａに送信さ
れ表示される見積依頼リストの閲覧トップページの一例
を示す図。

【図１６】 例えば図１５に示すトップページにおい
て、閲覧条件として「中国」が指定された場合に販売者
端末Ａに表示される見積依頼リストの画面の一例を示す
図。

【図１７】 仲介者サーバＢから販売者端末Ａに送信さ
れる詳細なデータを示す画面の一例を示す図。

【図１８】 図１９とともに、図３におけるＳＢ１０に
示す見積送信依頼の処理の手順を詳細に示す仲介者サー
バＢにおけるフローチャートとこれに対応する販売者端
末Ａ、ユーザ端末Ｃにおけるフローチャート。

【図１９】 図１８とともに、図３におけるＳＢ１０に
示す見積送信依頼の処理の手順を詳細に示す仲介者サー
バＢにおけるフローチャートとこれに対応する販売者端
末Ａ、ユーザ端末Ｃにおけるフローチャート。

【図２０】 販売者端末Ａから仲介者サーバＢに送信さ
れるオファーデータ入力ページの一例を示す図。

【図２１】 仲介者サーバＢから、ユーザ端末Ｃに送信
される見積データの一例を示す図。

【図２２】 仲介者サーバＢから送信され、ユーザ端末
Ｃにおいて記入、返送される個人データフォームの一例
を示す図。

【符号の説明】 Ａ…販売者端末、Ｂ…仲介者サーバ、Ｃ…ユーザ端末

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ５１２ Ｇ０６Ｆ 17/60 ５１２ ＺＥＣ ＺＥＣ

Claims (6)

【特許請求の範囲】
1. 【請求項１】 ネットワークに接続可能なコンピュータ
   を備えた売買仲介サーバシステムであって、 クライアントコンピュータである販売者端末の要求に応
   じて発行する金銭的価値を示す象徴であるチケットに関
   し、そのチケット毎に付与されるチケット番号と、その
   販売者毎に付与される販売者番号とを含むチケット発行
   データを記憶するチケット発行データ記憶手段と、 クライアントコンピュータであるユーザ端末から送信さ
   れる購入を希望する商品に関する条件を含む購入データ
   を前記販売者に閲覧可能に記憶する購入データ記憶手段
   と、 前期購入データを閲覧した前記販売者により送信される
   前記購入データの商品に対応する見積データと、当該見
   積データと共に送信される前記チケット番号及び販売者
   番号とを含むオファーデータを受信するオファーデータ
   受信手段と、 前記オファーデータに含まれる販売者番号とチケット番
   号とのいずれもが、前記チケット発行データ記憶手段に
   記憶されている販売者番号とこの販売者番号に対応する
   チケット番号とに一致するか否かを照合するチケット番
   号照合手段と、当該チケット番号照合手段により、前記
   オファーデータに含まれる販売者番号とチケット番号の
   何れもが照合できた場合に、照合できたチケット番号を
   前記チケット発行データ記憶手段から消去することで当
   該販売者に対して課金する課金手段と、 前記課金手段により課金された場合に、前記購入データ
   に含まれたユーザのメールアドレスに前記見積データを
   送信する見積りデータ送信手段とを備えたことを特徴と
   する売買仲介サーバシステム。
2. 【請求項２】 前記見積りデータ送信手段は、前記課金
   手段により課金された場合に、前記購入データに含まれ
   たユーザのメールアドレスにより前記見積データを前記
   ユーザ端末に送信し、加えて前記販売者のメールアドレ
   スと、個人データフォームに関するデータを前記ユーザ
   端末に送信し、 ユーザの個人情報が付加された前記個人データフォーム
   に関するデータが当該ユーザ端末から返送された場合
   に、当該個人データフォームに関するデータを前記販売
   者端末に転送するとともに、前記商品データ受信手段に
   より受信した販売者番号に基づいて販売者端末から提供
   され記憶された企業の内容に関する企業情報を前記ユー
   ザに送信する個人データ・企業情報送信手段とを備えた
   ことを特徴とする請求項１に記載の売買仲介サーバシス
   テム。
3. 【請求項３】 売買される商品についての条件と取引価
   格とが予め記憶された相場情報記憶手段と、 前記ユーザ端末から送信された購入を希望する商品に関
   する条件に対して、同一又は一部が一致する条件の商品
   を前記相場情報記憶手段において検索・抽出する条件検
   索手段と、 この検索結果に基づいた情報をユーザ端末に送信する検
   索結果回答手段とを備えたことを特徴とする請求項１又
   は請求項２に記載の売買仲介サーバシステム。
4. 【請求項４】 前記検索結果回答手段は、検索が成功し
   た場合にはユーザ端末から送信された条件で前記購入デ
   ータ記憶手段に記憶し、検索に失敗した場合には最も条
   件が近い商品相場についての情報と、ユーザに条件の変
   更を促す表示を含む画面をユーザ端末に表示させること
   を特徴とする請求項３に記載の売買仲介サーバシステ
   ム。
5. 【請求項５】 前記購入を希望する商品に関する条件に
   は、ユーザの下取商品に関するデータを含み、 前記見積データには、当該下取商品の下取価格の見積も
   含むことを特徴とする請求項１乃至請求項４のいずれか
   に記載の売買仲介サーバシステム。
6. 【請求項６】 前記購入データには、ユーザがローンを
   利用可能か否かの判断に必要なローン判断情報を含み、 前記ユーザ端末から送信された当該購入データを受信し
   てローン判断情報のみを抽出して所定のローン会社に送
   信し、当該ローン会社から返信された前記ユーザのロー
   ンの利用の可否に関する情報を、前記見積データの送信
   までに前記ユーザ端末に送信することを特徴とする請求
   項１乃至請求項５のいずれかに記載の売買仲介サーバシ
   ステム。