JP2006126951A - 電子商取引支援方法及び装置 - Google Patents

Abstract

【課題】 電子商取引形態による注文住宅の建築または既築住宅の増改築等に関する支援において、契約業者が、応札にあたり、顧客の要求に十分に答えられる応札メッセージを作成することができる電子商取引支援方法を提供する。
【解決手段】 発注条件を見て応札して来た契約業者の当該応札を受け付ける応札受付工程に、応札受付業者数が前記制限に達するまで、応札の受け付け順に応札枠を付与する応札枠付与工程と、前記応札枠を付与された前記契約業者により作成される応札メッセージを受け付ける応札メッセージ受付工程とを含むものとする。
【選択図】 図１５

Description

本発明は、注文住宅の建築または既築住宅の増改築の受注を支援するための電子商取引支援方法及び装置に関する。

インターネットを利用した所謂電子商取引が隆盛を極めているが、発明者らは、特許文献１において、以下に示す工程を経て電子商取引を行うことを提案している。この特許文献に記載の方法にあっては、発明者らが、サンプルデータベース、スクラップブック手段と呼ぶ機器構成を備え、顧客の利便性を図っている。

さて、この種の注文住宅の建築または既築住宅の増改築の受注を支援するための電子商取引の基本的なステップ構造（工程構造）は、以下のように整理される。前記先行技術１の図１２（本願にあっては、図６が対応する）は、この基本的なステップ構造を示したものである。

電子商取引は、
（１）顧客側端末から入力された発注条件を受信する発注条件受信工程と、
（２）この発注条件受信工程で受信した発注条件を契約業者に提供する発注条件提供工程と、
（３）発注条件を見て応札して来た契約業者の当該応札を受け付ける応札受付工程と、
（４）応札受付工程で受け付けた契約業者を前記顧客に紹介する紹介工程とを含む。
従って、電子商取引は、注文住宅の建築又は既築住宅の増改築を行いたい顧客と、これら施工業務を請負いたい契約業者と、顧客、契約業者間に介在するサイト管理者間で成立する。

このシステムを利用する場合は、所定の発注を行おうとする顧客は、発注条件を決めて、この発注条件をサイト管理者に送る（発注条件受信工程）。
一方、サイト管理者側では、受信した発注条件を契約業者に提供する。この時、顧客又は発注条件に従って、契約業者の選別が行われる（発注条件提供工程）。
そして、契約業者は、送られてきた発注条件を見て、応札したい場合は応札する（応札受付工程）。
サイト管理者側では、応札受付工程で受け付けた契約業者を顧客に紹介する（紹介工程）。

このシステムにあっては、前記一連の工程において、発注条件を契約業者に提示する段階では、顧客に関する情報は秘匿されており、発注条件等が満たされるまで、顧客側で契約業者からの直接連絡に煩せられることなく、検討が行えるという大きな利便性がある。

従って、この種の注文住宅の建築または既築住宅の増改築の受注を支援するための電子商取引支援装置には、顧客側端末から入力された発注条件を受信し、受信した発注条件を契約業者に提供するとともに、発注条件を見て応札して来た契約業者の当該応札を受け付け、受け付けた契約業者を顧客に紹介するサーバが備えられ、これがサイト管理者により管理される。サイト管理者は、契約業者からサイトへの登録料、成約時の成約手数料等を徴収することで、サイトを良好に運営できる。

さて、応札受付工程において受け付けられる応札受付業者数には、従来、最大５契約業者あるいは８契約業者といった数的制限が設けられ、特定の発注条件（特定の発注条件の案件）に対して、制限された数の契約業者のみが応札でき、顧客側に紹介される構成が採用されている。この数的制限は、不要な競合を避け、顧客側における煩雑な作業を低減すると共に、上記契約業者の迅速な応札を惹起するという目的がある。

さらに応札に際しては、契約業者は、応札メッセージを作成することを条件付けられている。これは、サイト管理者側に送られた応札メッセージを、サイト管理者から発注条件を出した顧客側に送って、その発注条件に対する遣り取りを繰り返して、発注内容を煮詰める目的である。

この種の「発注条件」及びそれに対する『応札メッセージ』の例を以下に示す。
顧客から入力される「発注条件」の例
「 室内の説明 六畳の畳部屋が一部屋 絨毯敷の部屋は四畳と三畳半と八畳位が各一部屋ずつ、クロス張替えは全室と一畳半位の玄関 絨毯張替えは三部屋共 床鳴りは八畳位の絨毯部屋です。トイレにはコンセントあります。
以上おおよその費用見積もりが知りたいです、宜しくお願いします。」

契約業者からの『応札メッセージ』の例
『○○リフォーム 株式会社 本社／○支店／×営業所 担当者：△△ △△
初めまして、○○リフォーム株式会社と申します。
この度は、ホームプロをご利用いただきましてありがとうございます。
弊社はリフォームを専業として丸１４年を経過致しました。
本社は◇市、○支店、×営業所、△出張所があります。
ホームプロご紹介の工事も数多く実績がございますので、お役に立つご提案が出来ると確信致しております。
弊社のホームページもご覧いただき、又「お客様の声」の欄も参考にして下さい。
http://www.××−××××．co.jp
お客様のご要望の件ですが、リフォーム内容が多岐に渡っておりますので、一度現状を拝見させていただきたいと思います。
お客様のご要望を詳しくお聞きしまして、見積りを提出させていただきます。
事前に何か質問などございましたら、このメールの欄をご利用いただきお問い合わせ下さい。回答致します。
現場の下見、ご相談、見積りは契約の成否に関わらず、全て無料でございますので活用下さい。
私共の提案、見積りもぜひご検討材料に加えていただきたいと存じます。
ご返事をお待ち致しております。』

さて、従来、後に本件と対照して図２４で説明するように、契約業者が応札しようとする場合、契約業者は、顧客の発注条件を確認し、応札メッセージを入力したうえで応札することとなるが、応札業者数が所定数（現在８社）に達するまでは、単純に先着順で、応札に対応するものとしていた。

特開２００２−１３２８６３号公報（図１２）

上記システムでは、顧客側に紹介される契約業者は、応札の順（先着順）とされるため、契約業者が応札メッセージを丁寧に入力していると応札枠数が埋まってしまうという事象が発生する。結果、契約業者は、先ず応札枠数に入ることを優先し、簡単なメッセージや紋切り型のメッセージをコピーするだけで応札することとなり、結果的に早押しクイズと同様な状況が現出する。結果、応札メッセージに含まれる情報が発注条件からみて不足し、顧客の満足度が低下してしまうという問題が発生する。

先に従来技術の項で示した『応札メッセージ』の例は、その種の例であり、『自社のホームページを含む自社の紹介、一度現場を見せていただきたいとの依頼、その他形式的な内容』となっており、何ら、顧客のニーズを満たしていない。さらに、現場を見たい旨の記載があることからして、本来、このシステムが目的とする、『ある程度のレベルまで顧客名等を秘匿したままで発注条件を詰めるとともに、顧客の要求を満足できる見積りを得る』といった要請に対して、全く、逆の利用形態を採っている。従って、この状況では、本願に係る電子商取引支援手法の利点を十分に生かすことができない。

本発明は、上述の問題点に鑑みてなされたものであり、その目的は、電子商取引形態による注文住宅の建築または既築住宅の増改築等に関する支援において、契約業者が、応札にあたり、顧客の要求に十分に答えられる応札メッセージを作成することができる電子商取引支援方法を得るとともに、そのような方法を実行できる装置を得る点にある。

上記目的を達成するための電子商取引支援方法は、
顧客側端末から入力された発注条件を受信する発注条件受信工程と、
前記発注条件受信工程で受信した発注条件を契約業者に提供する発注条件提供工程と、
前記発注条件を見て応札して来た契約業者の当該応札を受け付ける応札受付工程と、
前記応札受付工程で受け付けた契約業者を前記顧客に紹介する紹介工程とを含み、
前記応札受付工程における応札受付業者数に制限が設けられ、
前記契約業者により作成されるとともに前記顧客に送られる応札メッセージの受け付けを条件として前記契約業者からの応札を受け付け完了する、
注文住宅の建築または既築住宅の増改築の受注を支援するための電子商取引支援方法を構成するに、
前記応札受付工程に、応札受付業者数が前記制限に達するまで、応札の受け付け順に応札枠を付与する応札枠付与工程と、前記応札枠を付与された前記契約業者により作成される応札メッセージを受け付ける応札メッセージ受付工程とを含むものとすることにある。

この電子商取引支援方法では、応札受付工程に応札枠付与工程と応札メッセージ受付工程とが含まれ、応札の受け付けが、２工程に分かれる。そして、前者の工程では、先着順に応札枠数が満たされるまで単に応札枠の確保が成される。一方、後者の工程においては、一旦、応札枠を確保できた契約業者が応札メッセージを作成し、これをサイト管理者側（実際はサーバ側）に送る。
従って、応札メッセージの作成にあっては、ある程度の余裕を持ってこれを作成でき、結果的に、この種の電子商取引の特性を十分に活用できるようになる。

この電子商取引支援方法を実現する装置としては、これを下記のように構成できる。
顧客側端末から入力された発注条件を受信し、前記受信した発注条件を契約業者に提供するとともに、前記発注条件を見て応札して来た契約業者の当該応札を受け付け、前記受け付けた契約業者を前記顧客に紹介するサーバを備え、
応札を受け付ける応札受付業者数に制限が設けられ、
前記契約業者により作成されるとともに前記顧客に送られる応札メッセージの受け付けを条件として、前記契約業者からの応札の受け付けを完了する、注文住宅の建築または既築住宅の増改築の受注を支援するための電子商取引支援装置を構成するに、
前記サーバに、応札受付業者数が前記制限に達するまで、応札の受け付け順に応札枠を付与する応札枠付与手段と、前記応札枠を付与された前記契約業者により作成される応札メッセージを受け付ける応札メッセージ受付手段とを備えたものとするのである。

この電子商取引支援装置では、応札枠付与手段が前述の応札枠付与工程を実行し、前記応札メッセージ受付手段が前述の応札メッセージ受付工程を実行する。

さて、先に説明した電子商取引支援方法において、前記応札メッセージ受付工程に関して、前記応札枠の付与から前記応札メッセージの受け付けまでに時間制限が設けられていることが好ましい。
このようにしておくと、応札枠の確保から応札メッセージの受け付けまでの時間を一定時間とすることで、特定の発注条件に関して、その処理をシステマティク且つ所定の時間内での処理とできる。

この方法を使用する装置としては、これを、前記応札メッセージ受付手段による応答メッセージに関して、前記応札枠の付与から前記応札メッセージの受け付けまでに時間制限が設けられているものとしておけばよい。

さらに、前記時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者にペナルティーが課される構成を採用することも好ましい。
応札メッセージの作成を必須とする本願のような電子商取引では、契約業者が所定の定められたシーケンスに沿って処理を進めることで、初めて良好な運用状態を確保できる。
従って、所定時間内にメッセージを作成して送らない等の問題のある場合は、ペナルティーを課すことで、契約業者における的確な作業を促すとともに、不要な応札、応札枠の確保を避けることができる。

この処理を実行するには、装置を、時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者にペナルティーが課される構成としておけばよい。

このようなペナルティーの例としては、前記時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者とは異なった他の契約業者に、当該応札枠が開放するものとしておくと、有効に応札枠を他の契約業者に開放して、より多くの契約業者に応札の機会を与えることができる。あるいは、ペナルティーとして、前記契約業者の応札枠を一定期間少なくしたり、応札自体を一定期間できなくしたりする等して、他の契約業者に応札の機会を与えてもよい。

この方法を実現する装置は、前記時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者とは異なった他の契約業者に、当該応札枠が開放される構成を有することとなる。

さらに、前記発注条件提供工程において、顧客又は前記発注条件からみた所定の条件を満足する契約業者にのみ、前記発注条件が提供される構成とすることが好ましい。提供段階においてある程度の絞りを掛けて、有効に処理を行うことができる。
このような所定の条件としては、発注条件が特定の地域にある建築物を対象としている場合に、その地域にある契約業者に限る等が考えられる。

装置としては、前記発注条件の提供において、顧客又は前記発注条件からみた所定の条件を満足する契約業者にのみ、前記発注条件が提供される構成を採用することとなる。

さらに、複数の前記発注条件の取り扱いに関して、各契約業者が応札できる前記発注条件の数が制限されていることが好ましい。
特定の契約業者が確保できる発注条件の数が無制限であると、特定の契約業者が発注条件の数（特定の契約業者に関して確保されている応札枠の数）のみを確保しておき、応札メッセージの作成段階で、応札の選別を行う等の問題が発生し、システムが有効に利用されない状況も起こりうる。
しかしながら、発注条件の数に制限を設けることで、結果的に応札枠の確保自体を的確且つ慎重なものとでき、的確な運用を確保できる。

装置としては、複数の前記発注条件の取り扱いに関して、各契約業者が応札できる前記発注条件の数が制限されているものとすることとなる。

本発明に係る電子商取引支援装置（以下、単に「本発明装置」という。）の実施の形態を、電子商取引形態による注文住宅の建築または既築住宅の増改築の受注を支援する場合について、図面に基づいて説明する。

図１に示すように、本発明装置１は、インターネット２に接続し、同じくインターネット２に接続する顧客側端末３からのインターネット２を介したアクセスに対して、電子商取引対象である注文住宅の建築または既築住宅の増改築に関する情報の授受を行うサーバ４と、前記電子商取引対象に関する顧客の嗜好を判断可能な複数のサンプルデータが予め登録格納され、顧客側端末３から検索可能にサーバ４と接続してなるサンプルデータベース５と、顧客側端末３からの検索によって前記複数のサンプルデータの中から選択されたサンプルデータを特定可能な情報である当該サンプルデータへのリンクを、その選択した顧客を識別可能に記録するスクラップブック手段６と、サーバ４に対して入出力操作を行う管理者端末７とを備えて構成されている。また、顧客と契約業者を仲介するシステムをも提供することから、契約業者の業者側端末８がサーバ４にアクセス可能なようにインターネット２に接続されている。このサーバ４には、後に詳述する応札枠付与手段４ａ及び応札メッセージ受付手段４ｂが備えられ、この手段はＣＰＵにより実現されている。

電子商取引支援装置１は、顧客が、前記スクラップブック手段６にスクラップブック９を作成する場合に使用されるとともに、このスクラップブック９に記録されている情報に 従って、もしくは、その参照を伴って、顧客―サイト管理者―契約業者間で特定の発注条件に対して遣り取りを行う場合（サイト管理者側から見ると仲介ビジネスを行うこととなる）に使用される。以下の説明では、先ず、スクラップブック９の作成に関して説明し、その後、仲介ビジネスに関して説明する。

〔スクラップブック作成〕
この作業に使用されるサンプルデータベース５とスクラップブック手段６は、サーバ４から読み出し及び書き込み自在なハードディスクドライブ等の不揮発性の記憶手段を用いて構成されており、夫々が独立した記憶手段であっても、同じ記憶手段の記憶領域を分割して構成されていても、或いは、サーバ４に内蔵の記憶手段を用いて構成されていても構わない。

スクラップブック手段６は、サーバ４にアクセスしてくる顧客毎に区切られた記憶領域を有しており、各顧客に対応した記憶領域をスクラップブック９と称する。

次に、顧客側端末３と本発明装置１間で行われる「スクラップ」に関する基本的な動作について、簡単に、既築住宅の増改築に関する電子商取引サイト（以下、リフォームサイトと称す）を例に、図２〜図４に基づいて説明する。

顧客は顧客側端末３からサーバ４が管理するリフォームサイトにアクセスする。
ここで、サーバ４がインターネット２を介して顧客側端末３の表示画面３ａ上に、図２に例示するようなリフォームサイトのトップメニュー画面１００を出力することにより、顧客は、当画面から、サンプルデータの検索、スクラップブックの閲覧、或いは、仲介依頼等の複数種のサービスが選択できる。

顧客は、当該リフォームサイトにおいて、施工事例の検索、商品・建材情報の検索、或いは、リフォームに関する蘊蓄集（お役立ち情報）の検索等のサンプルデータ検索を行なう場合は、トップメニュー画面１００上から、何れかのサンプルデータ検索ボタン１０１をクリックする。サーバ４は、サンプルデータの検索（例えば、リフォーム事例の検索）が選択されると、図３に例示するように、表示画面３ａ上にリフォーム事例検索画面１０２を出力する。

顧客は、家屋形態、施工部位、予算、リフォームテーマ等の検索キーワードを設定し、検索を実行する。サーバ４は、設定された検索キーワードに基づいてサンプルデータベース５から検索した施工事例の画像データを読み出し、図４に例示するように検索した施工事例の検索リスト画面１０３を表示画面３ａ上に出力する。

顧客は、検索リスト画面１０３に表示された検索事例の中に気に入った事例がある場合は、その画面の詳細１０４を検討し、その施工事例をリフォームの参考事例にしたい場合、サーバ４は、当該施工事例を特定可能なリンク情報をスクラップブック手段６内の自己のスクラップブック９に指定された記憶領域に記憶保存する。

〔スクラップブック閲覧〕
後日、例えば、発注を行おうとして、スクラップブック９の閲覧を選択する場合は、図２に示すように顧客はスクラップブック閲覧ボタン１０８をクリックする。サーバ４は、図５に例示するように、顧客に対しユーザＩＤとパスワードの入力を促すＩＤパスワード入力画面１０９を、インターネット２を介して顧客側端末３の表示画面３ａ上に出力する。

顧客は、ＩＤパスワード入力画面１０９上で、ユーザＩＤとパスワードを入力すると、サーバ４は、入力されたユーザＩＤとパスワードを受信するとともにそれらを照合し、本人確認が取れれば、顧客別のスクラップブック画面を表示画面３ａ上に表示する。顧客別のスクラップブック画面は、施工事例、商品・建材情報、リフォームに関する蘊蓄集（お役立ち情報）等のスクラップ種別の選択メニュー欄と、選択されたスクラップ種別のスクラップリスト画面（サンプルデータ検索時の検索リスト画面に類似）や、任意のスクラップの詳細画面（サンプルデータ検索時の詳細画面に相当）を表示するスクラップ表示欄とで構成される。

〔仲介ビジネス〕
以下、本発明に係る電子商取引支援方法により、本発明装置１を介して顧客と施工業者間の仲介ビジネスを行なう方法を図面に基づいて説明する。

図６に示すように、本実施形態のリフォームサイト（本発明装置１）に対する顧客（顧客側端末３）からの情報検索・検討（＃２０）は、上記のサンプルデータ検索、スクラップブック９の閲覧を適宜行って実行される。

〔発注条件受信工程〕
顧客は、上記情報検索の結果に基づいて、或いは、情報検索と並行して、或いは、情報検索は行なわずに、施工業者の紹介依頼を行なう（＃２１）。

この依頼は、以下の手順で実行される。
サーバ４がインターネット２を介して顧客側端末３の表示画面３ａ上に、図２に例示するようなリフォームサイトのトップメニュー画面１００を表示し、顧客がそのトップメニュー画面１００上の仲介依頼（施工会社紹介申込み）ボタン１１７をクリックすると、サーバ４が、図５に例示したＩＤパスワード入力画面１０９を表示画面３ａ上に出力する。顧客がＩＤパスワード入力画面１０９上で、ユーザＩＤとパスワードを入力すると、サーバ４は、入力されたユーザＩＤとパスワードを受信するとともにそれらを照合し、本人確認が取れれば、図７に例示するように、顧客別の仲介依頼画面１１８が表示画面３ａ上に表示される。

顧客が仲介依頼画面１１８上に示された施工部位、着工時期、予算、着工場所等の見積条件（発注条件）、さらにはコメントを入力して次画面に移行すると、図８に例示するような見積申込み内容確認画面１１９が表示画面３ａ上に表示される。この時、顧客は前述のスクラップブック９の内容も参照しながら、作業を進める。
顧客はその見積申込み内容に問題なければ発注条件登録ボタン１２０をクリックする。ここで、サーバ４が顧客側端末３から入力される上記発注条件を受信するステップが本発明方法における発注条件受信工程に相当する。

〔発注条件提供工程〕
次に、サーバ４は、施工業者用のリフォーム仲介サイトに予め登録された施工業者の中から受信した発注条件に所定の基準で合致した施工業者に対してのみ、前記発注条件を提供する（＃２２）。このステップ＃２２は本発明方法における発注条件提供工程に相当する。

ところで、前記発注条件は、施工業者が自己の業者側端末８からインターネット２を介してサーバ４で管理されている前記リフォーム仲介サイトにアクセスすることにより提供される。また、かかる発注があったことの通知は、電子メール、電話、ＦＡＸ等によってリフォーム仲介サイト管理者（リフォームサイト管理者に同じ）から当該施工業者になされる。施工業者はかかる顧客紹介に応じる意志があれば、前記発注条件を見て応募（応札）する（＃２３）。尚、この通知及び発注条件には、顧客名や住所・電話番号等の顧客特定の手掛かりとなる顧客属性は一切明らかにされず匿名扱いとされる。具体的手順は以下の通りである。

施工業者は業者側端末８からインターネット２を介してリフォーム仲介サイトにアクセスすると、サーバ４は、図９に例示するように、業者側端末８の表示画面８ａ上にリフォーム仲介サイトのトップメニュー画面２００を表示する。施工業者は、そのトップメニュー画面２００上で、ログインボタン２０１をクリックして、図１０に例示するログイン画面２０２上へ移行する。そこで、施工業者がユーザＩＤとパスワードを入力すると、サーバ４は、入力されたユーザＩＤとパスワードを受信するとともにそれらを照合し、本人確認が取れれば、図１１に例示するように、施工業者別のトップページ画面２０３を表示画面８ａ上に表示する。ここで、トップページ画面２０３は、選択メニュー欄２０４と表示欄２０５で構成される。

施工業者が選択メニュー欄２０４内のリフォーム工事に対する応札用に設けられている案件リスト２０６をクリックすると、サーバ４は、図１２に例示するように、応札用リフォーム案件リスト２０７を表示欄２０５に表示する。応札用リフォーム案件リスト２０７には、紹介依頼をした複数の顧客で、当該施工業者がそれらの発注条件に合致している顧客のみが紹介される。また、応札用リフォーム案件リスト２０７には、顧客から提供された発注条件の内、顧客名や住所・電話番号等は掲載されない。

〔応札受付工程〕
施工業者は、応札用リフォーム案件リスト２０７に掲載された案件の中で応札したい案件があれば、その案件に応札することとなる。この応札手順は、応札枠の確保の後、最終的に、施工業者は、図２２に示す応札ページ画面２０９内の応札メッセージ記載欄２１０ａに見積り額やリフォーム提案等を記載し、サーバ４に当該記載内容を送信し、サーバ４が当該記載内容を受信してその施工業者からの応札手続きが完了することとなる（＃２３）。
この応札工程においては、本願独特の構造が採用されているため、後に詳細に説明する。

〔紹介工程〕
サーバ４は、各施工業者の業者側端末８から応札（応札メッセージを受け付け、応札を受け付け完了した後）があれば、発注した顧客別に応札業者を整理し、先着８社を各顧客に対して紹介する（＃２４）。尚、このステップ＃２４は本発明方法の紹介工程に相当する。また、各応札業者に対して、先着８社に入ったか否かの当落通知を行なう（＃２５）。

〔施工業者との連絡〕
顧客は、紹介依頼（＃２１）に対して応札業者があったか否かの確認を、自己のスクラップブック９の閲覧手順の途中で行なうことができる。つまり、図１３に例示するように、サーバ４が、スクラップ表示欄１１２に顧客が依頼した施工部位毎の応札回答数を示す応札状況リスト２１２を表示する。又、紹介記録を参照するには紹介記録ボタン２１１を操作して、記録を参照できる。

顧客が、その応札回答数をクリックすると、図１４に例示するように、当該応札に対する施工業者の情報を示す応札情報画面２１３がスクラップ表示欄１１２に表示される。
顧客は、応札情報画面２１３に表示された各施工業者の応札メッセージ欄２１０ａの記載内容を検討することにより（この応札メッセージは、顧客側端末３では、図１４に示す回答欄２１０のコメント欄２１０ｂに表示される）、その施工業者と連絡をとるか断るかを選択する。従って、ここで、顧客に断られた施工業者に対しては上記ステップ＃２５の落選通知が、また、連絡を取ると判定された施工業者には上記ステップ＃２５の当選通知が、遅れて実行される。

上記ステップ＃２３の応札時に施工業者が応札メッセージ欄２１０ａに自社のホームページのアドレス（ＵＲＬ）等のリンク情報を記載しておくことで、顧客が施工業者のホームページにアクセスすることができ、各施工業者は自社のＰＲを顧客に対して直接行なうことができる。従って、これらの内容を含む自社ＰＲを顧客に対して直接行なうことができる（＃２６）。

前記８社の施工業者は、或いは、ステップ＃２５で当選通知を受領した施工業者は、リフォーム仲介サイト管理者に、予め決められた支払い方法（例えば、クレジットカード払い等）で紹介手数料を支払う（＃２７）。

〔直接商談〕
後は、顧客と顧客が選択した施工業者間で、直接或いはリフォームサイト及びリフォーム仲介サイトを介して、商談を進めて、最終的に顧客が施工業者を１社に絞り込み受発注条件に両者合意して、顧客が当該１社に発注する（＃２８）。

施工業者は、受注後、顧客に対してリフォーム工事のサービスを提供し（＃２９）、顧客はその対価を支払う（＃３０）。また、施工業者はリフォーム仲介サイト管理者に、予め決められた支払い方法（例えば、クレジットカード払い等）で成約手数料を支払う（＃３１）。更に、リフォームサイト管理者は、サービスに対する顧客満足度評価等のフォローを実行する（＃３２）。これにより、施工業者の施工内容や能力等を確認し、今後の仲介業務で施工業者選別の資料とする。

さらに、図６に示すように、契約業者８はサイト管理者に初期登録料として加入基本料金を納付する（＃１０）とともに、発注があった場合（＃２８）は、成約後３営業日以内にサイト管理者に報告するとともに、代金支払い（＃３０）があった場合は、完了後３営業日以内に報告することが義務づけられている。

以上が、本願に係る、注文住宅の建築又は既設住宅の改築の受注を支援するための電子商取引支援の基本的な流れである。
以下に本願に係る発明の特徴構成に関して、図１５〜図２３に基づいて説明する。
ここで説明する工程は、サーバ４が顧客からの発注条件を受け付け、各発注条件に対して、サーバ４が各契約者からの応札を受け付ける（各契約業者が応札を行う）工程である。
本願にあっては、この応札受付工程には、応札受付業者数が前記制限（８社）に達するまで、応札の受け付け順に応札枠を付与する応札枠付与工程と、応札枠を付与された契約業者により作成される応札メッセージを受け付ける応札メッセージ受付工程とが含まれる。

図１５は、この応札受付工程の処理フローを示す画面であり、図１６、１７、１８，１９は、この処理時に契約業者にある業者側端末３の表示画面３ａに表示される、各ステータスでの案件リストの表示画面を示している。以下の説明では、その最上段に表示されている案件が、説明の対象となっている案件である。

以下、図１５に示す応札受付工程の処理フローに従って説明する。
同フローにおいて、案件発注とは、図１２に示した応札案件リストが契約業者に渡る、サーバ４から所定の条件を満たす各契約業者に、特定された発注条件の提供が行われた段階を示す（＃１５０）。この段階では、図１６に示すようにその案件は「応札募集」と表示される。
この段階で、業者側端末３には図２０に示すような発注条件の詳細を示す情報が各案件に対して表示可能とされる。図示するように、この画面で、発注条件の詳細を知ることができ、応札するか否かの判断の用に供することができる。

応札募集ステータス
先ず、この処理フローにあっては、応札枠が埋まっているか否かが、サーバ４側で判断される（＃１５１）。実施例に示す例では、特定の発注条件の案件１件に対して８の応札枠が確保されている例が示されている。応札枠が満たされている場合（＃１５１：ｎｏ）は、これ以上の応札枠が契約業者に開放されることはなく、契約業者側の端末では図２１に示すような表示がされ、募集終了となる（＃１４０）。一方、応札枠に余裕がある場合（＃１５１：ｙｅｓ）は、応札募集ステータスは維持され、契約業者による応札枠の確保が可能となる（＃１５２）。

契約業者は、発注条件の内容を図２０に示されるような画面で見て、その案件に関して応札枠を確保するか否かを決定する（＃１５３）。興味がなく、応札の予定もない場合は、そのままフローは終了することとなる（＃１５３：ｎｏ、＃１３０）。一方、応札の予定がある場合は、応札枠を確保すべく、同画面に表示されている応札枠確保ボタン３００を押す（＃１５３：ｙｅｓ、＃１５４）。
この操作に従って、サーバ４は、今対象としている発注条件に対して確保されている応札枠の数を確認する（＃１５５）。この数が今回の応札枠確保操作も含めて８以内の場合（＃１５５：ｙｅｓ）は、応札枠を確保しようとする契約業者自体の、現在の応札枠確保数を確認にいく（＃１５６）。当該契約業者自体に関して応札枠がすでに無い（５を超えている）場合（＃１５５：ｎｏ）は、当該契約業者の応札枠確保不可との処理を行う（＃１４５）。
一方、今対象としている発注条件に対して確保されている応札枠の数が８を超えている場合（応札してきた業者の発注枠を加えると９となる場合で、＃１５５：ｎｏ）は応募終了との処理を行う（＃１４０）。
このような応札枠確保処理においてサーバ側で働くのが、図１に示す応札枠付与手段４ａである。
応札枠確保ステータス
当該契約業者の応札枠確保数が５以内である場合は、サーバはその契約業者に応札枠を付与し、契約業者側の処理は応札枠確保ステータスの作業に移る（＃１５７）。この状態で、業者側端末における案件リスト表示は、図１７に示すように、その特定の発注条件に対して『応札枠確保』となる。
応札枠確保ステータスにおける作業は、応札枠を確保した契約業者が、これまで説明してきた応札メッセージの作成・入力作業を行うステップである。

応札枠確保ステータスにおいては、発注条件の記載欄に対応して設けられているメーセージ記載欄２１０ａに、契約業者が応札メッセージを作成し（＃１５８）、確認の後、サーバへ送る（＃１５９）。図２２に、先に説明した特定の発注条件の案件について、応札メッセージの記載欄２１０ａ、確認ボタン３０１を設けた例を示した。この確認ボタン３０１は応札メッセージの作成の後、サーバ側の送信の確認を行うために設けられているボタンであり、確認ボタン３０１の操作の後、図２３に示す送信ボタン３０２が応札メッセージとともに表示され、誤りがなければ、業者側からサーバ４に応札メッセージ、その他の情報が送られる。この送信ボタン３０２が実質的には応札ボタンとなる。

このようなメッセージとして好ましい例を以下に示した。この例は、先に発明が解決しようとする課題の項で示した、「発注条件」に対応するものである。

『○○リフォーム 株式会社 本社／○支店／×営業所 担当者：△△ △△
はじめまして。
○○リフォーム株式会社と申します。よろしくお願い致します。
本社は◇市、○○店、××店、△店がございます。
リフォーム専門会社として丸１４年、多くのホームプロ様のお客様のお手伝いもさせて頂いております。
ホームページも是非ご覧頂き、参考にして下さい。
http://www.××−××××．co．jp
さて、お客様のご要望につきまして何点か、教えて頂けますでしょうか？
１）床鳴りのする床はフローリングでしょうか、ジュータンでしょうか。
２）トイレ内にコンセントはございますか。
３）クロスを張替える部屋の広さを教えて頂けますか。
天井も張替えますか。
上記が判りますと、概算でお見積もり金額をご連絡申し上げられますので、お手数ですが、よろしくお願い致します。
数多くの工事実績と経験から適切なアドバイスをさせて頂きます。どのような事でもお気軽にご相談下さい。
ご返信、お待ち致しております。』
この例にあっては、メッセージが単なる自社の紹介に終わることなく、発注条件に対応した内容となっているとともに、さらに追加的な工事内容も質問することとなっている。

さて、特定の契約業者に対する応札枠の付与（＃１５７）から、その業者が応札メッセージを作成し（＃１５８）、送信ボタン３０２を操作する（＃１５９）までの時間には一定の制限が設けられている。実施例にあっては、この制限時間は３時間とされている。よって、サーバ４は、特定の発注条件に関して、特定の契約業者に対して、応札枠確保から送信ボタン３０２の操作までの時間が、この時間を超えていないかどうかを判断する（＃１６０）。超えている場合（＃１６０：ｎｏ）、サーバ４はその契約業者に関してペナルティーとして応札枠を失効させるとともに、この案件に対する再応札禁止とする（＃１６５）。
このような応札メッセージの受付は、サーバ側では応札メッセージ受付手段４ｂがこれを行う。

この状態で、その契約業者の端末における表示は、図１９に示されるように、『応札失効』とされる。一方、他の契約業者に対しては、当該発注条件の案件が開放され、再度、応札募集ステータス（応札枠の確保を行うステータス）に戻ることとなる。

応札済ステータス
一方、制限時間内に応札メッセージを作成して送信ボタン３０２を操作した契約業者に関しては応札済ステータスとなる（＃１７０）。このステータスにおける業者側端末３における案件リスト表示は、図１８に示すように、その特定の案件に対して『応札済』となる。このステータスへの移行は、その契約業者に関しては応札数が一増加し、その発注条件の案件に関しては応札中の契約業者の数が一増加することとなる。
そして、契約業者側から受け入れた応札メッセージを顧客側へ送り（＃１８０）、応札工程を完了する（＃２００）。

以上、説明してきたように、本願構成にあっては、先ず先着順に応札枠を確保して、その後所定の時間内に応札メッセージを作成して応札を完了する。この構成にあっては、応札メッセージの作成が応札枠の確保に絡まないため、応札メッセージの作成に十分時間を確保できる。結果、本願のような電子商取引支援システムにおいて、良好にその機能を発揮することができる。

本件の特徴を明確にするため、図１５に対して従来型の応札フローを図２４に示した。
図２４からも判明するように、従来型の応札工程にあっては、応札枠の確保を実行する工程はなく、さらに応札を望む契約業者は（＃２００３：ｙｅｓ）、応札メッセージの作成の後（＃２００４）、応札ボタンを操作し（＃２００５）、応札を完了することとなる。特定の発注条件案件に対して応札できる業者数が限定されており（＃２００１、＃２００６）その数に制限がかかることとなる。さらに、従来手法では、業者側端末８ａには、応札時に、図１６または１８に示す画面が表示され、図１７、１９に示す画面が表示されることはない。即ち、業者側端末に表示される特定の発注条件の案件に関する表示は、「応札募集」か「応札完了」かの択一表示となる。

以下に別実施形態を説明する。
１．上記の実施の形態にあっては、特定の発注条件の案件について、その案件に許容する応札枠数が８である場合を示したが、これは任意の数であってもかまわない。但し、運用上は、例えば３から１０程度が適当である。さらに、応札メッセージの受け付け時間も３時間に限らず、任意に設定可能である。
２．上記の実施の形態にあっては、特定の契約業者が確保できる発注条件の数（特定の業者から見た応札枠の数）を５に制限するものとしたが、この数に関しても任意である。但し、運用上は、例えば４から８程度が適当である。
３．上記の実施の形態にあっては、発注条件提供工程において、発注条件を提供する場合に、その提供先として、顧客又は発注条件に適合した（例えば、顧客と同一又は隣接する郵便番号内に営業所、事業所がある、府、県を同一とする）契約業者に提供を行うものとしている。これに代えて、最初から全国の契約業者に提供するものとしてもよいし、最初に顧客、発注条件から見て限定された条件を満たす契約業者に提供をし、その後、応札枠に余裕がある場合は、全国又はさらに緩い条件を満たす契約業者に提供するものとしてもよい。
４．さらに、応札メッセージの受け付けが遅れた案件については、その業者に関してペナルティーとしてその案件に関する権利失効とするものとしたが、ペナルティーとして、発注条件の提供に制限を設けるものとしてもよい。
５．上記実施の形態において、顧客と施工業者を仲介するビジネス形態を例示したが、本発明装置１を使用するに当って、リフォームサイト管理者自体が、施工業者であっても構わない。従って、この場合は、上記第一実施形態で説明した本発明装置１を介して顧客と施工業者間の仲介ビジネスを行なう方法は適用されない。
６．上記実施の形態において、例えば顧客のスクラップブックの閲覧を応札した施工業者の中の先着８社に限定できるが、この数は任意であり、また、募集を通知した全ての施工業者に閲覧許可を与えるようにしても構わない。
７．上記実施形態で図をもって例示した、顧客側端末３及び業者側端末８の表示画面３ａ，８ａ上に表示される各種画面の画面レイアウトは一例であって、任意に変更可能である。また、必要に応じて表示する画面数を増減しても構わない。

電子商取引形態による注文住宅の建築または既築住宅の増改築等に関する支援において、契約業者が、応札にあたり、顧客の要求に十分に答えられる応札メッセージを作成することができる電子商取引支援方法を提供することができた。

本発明に係る電子商取引支援装置の第一実施形態を示すブロック構成図 リフォームサイトのトップメニュー画面の一例を示す説明図 施工事例検索画面の一例を示す説明図 リフォーム事例検索の一例を示す図 ＩＤパスワード入力画面の一例を示す説明図 本発明に係る電子商取引支援方法の一実施形態を示す業務流れ図 顧客別の仲介依頼画面の一例を示す説明図 見積申込み内容確認画面の一例を示す説明図 リフォーム仲介サイトのトップメニュー画面の一例を示す説明図 ログイン画面の一例を示す説明図 施工業者別のトップページ画面の一例を示す説明図 応札用リフォーム案件リストの表示例を示す説明図 応札状況リストの表示例を示す説明図 本願における応札情報画面の一例を示す説明図 応札処理時の処理フローを示す図 応札募集中の案件リストの表示例を示す図 応札枠確保の案件リストの表示例を示す図 応札済の案件リストの表示例を示す図 応札失効の案件リストの表示例を示す図 応札枠確保画面の一例を示す説明図 登録エラー画面の一例を示す説明図 応札メッセージ入力画面の一例を示す説明図 応札メッセージの送信を伴った応札ボタン操作画面の一例を示す説明図 従来の応札処理時の処理フローを示す図

符号の説明

１： 電子商取引支援装置
２： インターネット
３： 顧客側端末
３ａ： 表示画面
４： サーバ
４ａ：応札枠付与手段
４ｂ：応札メッセージ受付手段
５： サンプルデータベース
６： スクラップブック手段
７： 管理者端末
７ａ： 表示画面
８： 業者側端末
８ａ： 表示画面
９： スクラップブック

Claims (12)

1. 顧客側端末から入力された発注条件を受信する発注条件受信工程と、
   前記発注条件受信工程で受信した発注条件を契約業者に提供する発注条件提供工程と、
   前記発注条件を見て応札して来た契約業者の当該応札を受け付ける応札受付工程と、
   前記応札受付工程で受け付けた契約業者を前記顧客に紹介する紹介工程とを含み、
   前記応札受付工程における応札受付業者数に制限が設けられ、
   前記契約業者により作成されるとともに前記顧客に送られる応札メッセージの受け付けを条件として前記契約業者からの応札を受け付け完了する、
   注文住宅の建築または既築住宅の増改築の受注を支援するための電子商取引支援方法であって、
   前記応札受付工程に、応札受付業者数が前記制限に達するまで、応札の受け付け順に応札枠を付与する応札枠付与工程と、前記応札枠を付与された前記契約業者により作成される応札メッセージを受け付ける応札メッセージ受付工程とを含む電子商取引支援方法。
2. 前記応札メッセージ受付工程に関して、前記応札枠の付与から前記応札メッセージの受け付けまでに時間制限が設けられている請求項１記載の電子商取引支援方法。
3. 前記時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者にペナルティーが課される請求項２記載の電子商取引支援方法。
4. 前記時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者とは異なった他の契約業者に、当該応札枠が開放される請求項２記載の電子商取引支援方法。
5. 前記発注条件提供工程において、顧客又は前記発注条件からみた所定の条件を満足する契約業者にのみ、前記発注条件が提供される請求項１〜４のいずれか１項記載の電子商取引支援方法。
6. 複数の前記発注条件の取り扱いに関して、各契約業者が応札できる前記発注条件の数が制限されている請求項１〜５のいずれか１項記載の電子商取引支援方法。
7. 顧客側端末から入力された発注条件を受信し、前記受信した発注条件を契約業者に提供するとともに、前記発注条件を見て応札して来た契約業者の当該応札を受け付け、前記受け付けた契約業者を前記顧客に紹介するサーバを備え、
   応札を受け付ける応札受付業者数に制限が設けられ、
   前記契約業者により作成されるとともに前記顧客に送られる応札メッセージの受け付けを条件として、前記契約業者からの応札の受け付けを完了する、注文住宅の建築または既築住宅の増改築の受注を支援するための電子商取引支援装置であって、
   前記サーバに、応札受付業者数が前記制限に達するまで、応札の受け付け順に応札枠を付与する応札枠付与手段と、前記応札枠を付与された前記契約業者により作成される応札メッセージを受け付ける応札メッセージ受付手段とを備えた電子商取引支援装置。
8. 前記応札メッセージ受付手段による応答メッセージの受け付けに関して、前記応札枠の付与から前記応札メッセージの受け付けまでに時間制限が設けられている請求項７記載の電子商取引支援装置。
9. 前記時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者にペナルティーが課される請求項８記載の電子商取引支援装置。
10. 前記時間制限内に、前記応札枠が付与された前記契約業者から前記応札メッセージを受け付けなかった場合に、前記応札枠が付与された前記契約業者とは異なった他の契約業者に、当該応札枠が開放される請求項８記載の電子商取引支援装置。
11. 前記発注条件の提供において、顧客又は前記発注条件からみた所定の条件を満足する契約業者にのみ、前記発注条件が提供される請求項７〜１０のいずれか１項記載の電子商取引支援装置。
12. 複数の前記発注条件の取り扱いに関して、各契約業者が応札できる前記発注条件の数が制限されている請求項７〜１１のいずれか１項記載の電子商取引支援装置。

Images