(57)【要約】【課題】本発明では、居住者の予算に合わせた優良なリフォーム案を提案し、全面改装をする居住者の負担を軽減するためのプログラムを提供することを目的とする。【解決手段】リフォームの見積に必要な情報を、ユーザ側端末およびリフォーム提供会社側サーバとで相互に送受信するステップと、リフォーム提供側会社が受信した情報を解析装置によって解析するステップと、前記解析に基づいたリフォーム情報をユーザ側端末に送信するステップと、ユーザの希望リフォーム内容を基に逆オークションサーバを介して逆オークションが実施されるステップと、前記逆オークションの結果によりインターネットを介して大量発注を実施するステップとからなるプログラムが前記リフォーム提供会社側のサーバの記憶装置に格納されてなるリフォーム受発注プログラム。【選択図】図５
2010027019.tif 000002
【特許請求の範囲】
【請求項１】
インターネットを介して、複数のユーザ側の端末および複数の協力会社側サーバと、リフォーム提供会社側のサーバとが接続されたリフォーム受発注システムであって、
前記複数の協力会社側サーバが、それぞれ前記インターネットとは別の公衆回線または専用回線を介して当該協力会社の顧客が有する複数のユーザ側端末と接続されており、
前記インターネットを介して逆オークションサーバと、リフォーム提供会社側サーバおよび協力会社側サーバとが接続されており、
（Ａ）ユーザ側端末からインターネットを介してリフォーム提供会社のサーバにリフォームの見積のリクエスト情報を送信するステップと、
（Ｂ）リフォームの見積をリクエストされたリフォーム提供会社が、リフォーム提供会社側サーバ中で、リフォームの内容、予算、工期、およびリフォーム工事中の仮住まいの希望の有無についての質問情報を作成し、該質問情報をインターネットを介して当該ユーザ側端末に送信するステップと、
（Ｃ）前記ユーザ側端末によって受信された前記ステップ（Ｂ）の質問情報に対して、ユーザ側端末によって回答情報が作成され、リフォーム提供会社側のサーバに該回答情報を送信するステップと、
（Ｄ）前記リフォーム提供会社側のサーバによって受信された前記ステップ（Ｃ）の回答情報を該リフォーム提供会社側のサーバに組み込まれた解析装置によって解析するステップと、
（Ｅ）前記ステップ（Ｄ）における解析に基づいて、前記ユーザ側端末に対してリフォームにかかる費用と、リフォームの内容と、工期と、仮住まいとともに、モデルルームの静止画像および／または動画像に関して作成した情報を送信するステップと、
（Ｆ）ユーザの希望リフォーム価格、該リフォームの規模および内容を基に、前記逆オークションサーバを介して前記リフォーム提供会社側サーバから入札条件が該複数の協力会社側サーバに送信され、該協力会社側サーバが該入札条件に基づいて入札するかを決定する逆オークションが実施されるステップと、
（Ｇ）前記ステップ（Ｆ）において、入札結果により、ユーザの希望リフォーム価格よりも高い価格になった場合に、複数のユーザに同一内容のリフォーム案を提案するステップと
からなるプログラムが前記リフォーム提供会社側のサーバの記憶装置に格納されてなるリフォーム受発注プログラム。
【請求項２】
前記ユーザ側の端末が、１または２以上の端末からなり、前記端末が、アパートまたはマンションの居住者の端末と、商業用ビルのユーザ端末と、戸建の住民の端末からなる請求項１記載のリフォーム受発注プログラム。
【請求項３】
前記インターネットを介して、銀行またはコンビニエンスストアの端末と接続されてなる請求項１または２記載のリフォーム受発注プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リフォーム受発注システムおよびリフォーム受発注プログラムに関する。さらに詳しくは、リフォーム提供会社側サーバとユーザ側の端末をインターネットで接続し、リフォームの受発注サービスを提供するリフォーム受発注システム、およびリフォーム受発注プログラムに関する。
【背景技術】
【０００２】
一般に、住宅等のリフォームを行う場合、住居の所有者（以下、「居住者」という）は予算、リフォームの内容、工期等について施工業者と打ち合わせながらリフォームに使用する材料等を選定し、順次作業を進めていく。また、リフォームを希望する居住者は、ホームページやその他広告から知り得た情報を基に、リフォーム内容を決定する。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、一般的な居住者はリフォームに関する知識が充分ではないため、自己の要望を満たすリフォーム内容を事前に把握することが困難であった。
【０００４】
そこで、本発明は、居住者の要望に即応できるリフォーム受発注システムおよびプログラムを提供することを目的とするものである。
【課題を解決するための手段】
【０００５】
上記問題を解決するために、本発明にかかわるリフォーム受発注プログラムは、第１の回線を介して、少なくともユーザ側の端末と、リフォーム提供会社側のサーバとが接続されたリフォーム受発注システムを、コンピュータによって実行せしめるリフォーム受発注プログラムであって、（Ａ）ユーザ側端末から第１の回線を介してリフォーム提供会社のサーバにリフォームの見積をリクエストするステップと、（Ｂ）リフォームの見積をリクエストされたリフォーム提供会社が、当該ユーザ側端末に対して、リフォームの内容、予算、工期、およびリフォーム工事中の仮住まいの希望の有無についての質問を送信するステップと、（Ｃ）前記ユーザ側端末によって受信された前記ステップ（Ｂ）の質問に対して、リフォーム提供会社側のサーバに回答を送信するステップと、（Ｄ）前記リフォーム提供会社側のサーバによって受信された前記ステップ（Ｃ）の回答を解析するステップと、（Ｅ）前記ステップ（Ｄ）における解析に基づいて、前記ユーザ側端末に対してリフォームにかかる費用と、リフォームの内容と、工期と、仮住まいとともに、モデルルームの静止画像および／または動画像を送信するステップとからなるプログラムが前記リフォーム提供会社側のサーバの記憶装置に格納されてなることを特徴とする。
【０００６】
前記ユーザ側の端末が１または２以上の端末からなり、前記端末がアパートまたはマンションの居住者の端末と、商業用ビルのユーザ端末と、戸建の住民の端末からなることが好ましい。
【０００７】
前記第１の回線を介して、銀行またはコンビニエンスストアの端末と接続されてなることが好ましい。
【発明の効果】
【０００８】
本発明によれば、リフォームの見積情報を受信したリフォーム会社が、ユーザ側端末に対して種々の質問を送付し、データベースに蓄積された過去のリフォーム情報を当該質問に対する回答に照らし合わせることによりリフォーム内容が提案されるので、居住者の要望に適合したリフォーム内容を提案することができる。また、過去にリフォームした住宅で発生した問題点（湿気、カビ、水周りの不具合など）を考慮に入れ、該問題点を改善したリフォーム内容を提案することができる。
【０００９】
さらに、全面改装を希望する居住者の場合、モデルルームを仮住まいとして提供することで、居住者にかかる負担が大幅に軽減できる。なお、従来のモデルルームとは異なり、仮住まいを前提としたモデルルームであるので、実際行われていないリフォーム内容を実施することができ、以降のリフォーム案の基礎として活用することができる。
【発明を実施するための最良の形態】
【００１０】
本発明の実施の形態にかかわるリフォーム受発注システムおよびリフォーム受発注プログラムについて、添付図面に沿って、以下に詳細に説明する。
【００１１】
図１は本発明の実施の形態１のリフォーム受発注システムを示すブロック図、図２は本発明の実施の形態１のリフォーム受発注の流れを示すフローチャート、図３は本発明における着手金の課金手順を示すフローチャート、図４は本発明におけるリフォーム代金の課金手順を示すフローチャート、図５は本発明の実施の形態２における逆オークション制度を利用したリフォーム受発注システムを示すブロック図、図６は本発明のリフォーム提供会社側サーバの基本的構造を示すブロック図、図７は本発明の実施の形態２のリフォーム受発注の流れを示すフローチャートである。
【００１２】
実施の形態１
図１に示されるように、実施の形態１におけるリフォーム受発注システムは、第１の回線１を介して接続された１または２以上のユーザ側端末２−１〜２−ｎと、リフォーム提供会社側サーバ３と、銀行側端末４とから構成されている。前記リフォーム提供会社側サーバ３は、１または２以上のユーザ側端末から送信される情報を分析する分析装置５、過去のリフォーム情報、モデルルーム情報、管理情報等を蓄積している記憶装置６、および該分析装置５で分析された分析情報と該リフォーム提供会社側サーバ３に第１の回線１とは異なる通信回線を介して接続されたリフォーム情報データベース３１で蓄積されている蓄積情報を読み出して、ユーザ側端末２−１〜２−ｎの要望に適合したリフォーム内容を提案する制御装置７を有する。該通信回線は、該リフォーム情報データベース３１と該リフォーム提供会社側サーバ３の間でのみ通信可能な専用回線であることが好ましい。その場合、リフォーム情報が、外部に漏れることないので、情報の漏洩を防止できる。
【００１３】
前記ユーザ側端末２−１〜２−ｎ、リフォーム提供会社側サーバ３、リフォーム情報データベース３１および銀行側端末４としては、十分なメモリーと処理能力を有する従来のパーソナルコンピュータまたはコンピュータワークステーションを用いることができる。
【００１４】
なお、実施の形態１では、課金システムとして銀行側端末４をリフォーム受発注システムに組み込んでいる（図３および図４参照）が、これに限定されるものではなく、コンビニエンスストアや他の課金システムを用いてもよい。
【００１５】
図２は、本発明の実施の形態におけるリフォーム受発注システムの動作を示している。
【００１６】
まず、ステップＳ１０１において、１または２以上のユーザ側端末２−１〜２−ｎからリフォーム提供会社側サーバ３へ、リフォームの見積要求情報が送信される。該操作が検出されると、処理はステップＳ１０２に移行する。
【００１７】
ステップＳ１０２において、見積要求情報を受信したリフォーム提供会社側サーバ３が、リフォームの内容、予算、工期、およびリフォーム工事中の仮住まいの希望の有無について作成した質問フォームが、ユーザ側端末２−１〜２−ｎへ送信される。この後、処理はステップＳ１０３に移行する。
【００１８】
ステップＳ１０３において、ユーザ側端末２−１〜２−ｎ−１〜２−ｎによって受信されたステップＳ１０２の質問フォームに対する回答がユーザ側端末２−１〜２−ｎ内で回答情報として作成され、前記ユーザ側端末２−１〜２−ｎからリフォーム提供会社側サーバ３へ回答情報が送信される。この後、処理はステップＳ１０４に移行する。なお、ユーザ側端末２−１〜２−ｎ内では、既知のパーソナルコンピュータの技術が用いられ、入力媒体（図示せず）によってユーザが作成した回答が、メモリ（図示せず）に記憶され、該記憶された回答がＣＰＵ（図示せず）内で送信情報に変換され、第１の回線１を介してリフォーム提供会社側サーバ３に送信される。なお、ステップＳ１０３における回答情報が受信されない場合には処理を終了する。
【００１９】
ステップＳ１０４において、リフォーム提供会社側サーバ３によって受信された回答情報が解析装置５によって解析され、解析情報が記憶装置６に格納される。前記記憶装置６は、過去のリフォーム実施例の情報を記憶したリフォーム情報データベース３１と通信回線を介して接続されており、前記解析情報と、前記リフォーム情報データベース３１内に記憶された過去のリフォーム情報とを利用して、制御装置７によってユーザ側端末２−１〜２−ｎの要望に適合したリフォーム案が作成される。たとえば、年齢、性別、家族構成、住所等酷似した状況のユーザの情報が記憶されていた場合、それらを参考にしてリフォーム内容が提案できる。その後、処理はステップＳ１０５に移行する。
【００２０】
ステップＳ１０５において、ユーザ側端末２−１〜２−ｎに対して、リフォームにかかる費用と、それに基づいたリフォーム案の内容、リフォームにかかる工期、および仮住まいの詳細についての情報を有するリフォーム案、およびモデルルームの静止画像および／または動画像等のモデルルーム情報がユーザ側端末へ送信される。その後、処理はステップＳ１０６に移行する。
【００２１】
ステップＳ１０６において、解析情報およびモデルルームの静止画像および／または動画像を参考にして、ユーザ側端末２−１〜２−ｎで詳細なリフォーム案が決定され、詳細なリフォーム案およびユーザ情報がリフォーム提供会社側サーバ３に送信される。ステップＳ１０６の動作を待って、処理はステップＳ１０７に移行する。
【００２２】
ステップＳ１０７において、リフォームの詳細を決定するための調査用の着手金がユーザ側端末２−１〜２−ｎに要求され、ユーザ側端末２−１〜２−ｎから銀行側端末４（以下、課金システムという（図３参照））を介して着手金が支払われる。この後、処理はステップＳ１０８に移行される。なお、ステップＳ１０７はユーザ側端末２−１〜２−ｎによって着手金が支払われるまで繰り返される。
【００２３】
ステップＳ１０８において、着手金の入金が課金システムによって確認されると、リフォーム提供会社側サーバ３により調査開始命令が発せられ調査が開始される。調査が完了すると、処理はステップＳ１０９に移行する。
【００２４】
ステップＳ１０９において、ステップＳ１０８で得られた調査情報を考慮して作成された最終的なリフォーム情報が、リフォーム提供会社側サーバ３からユーザ側端末２−１〜２−ｎへ送信される。この後、処理はステップＳ１１０に移行する。
【００２５】
ステップＳ１１０において、リフォームを開始するためのリフォーム代金がリフォーム提供側サーバ３からユーザ側端末２−１〜２−ｎに要求され、ユーザ側端末２−１〜２−ｎから課金システムを介してリフォーム代金がリフォーム提供会社側サーバ３へ支払われる。この後、処理はステップＳ１１１に移行する。なお、ステップＳ１１０はユーザ側端末２−１〜２−ｎがリフォーム代金を支払うまで繰り返される。
【００２６】
ステップＳ１１１において、ステップＳ１１０によってリフォーム代金がユーザ側端末により支払われると、リフォームが開始される。リフォームが完了すると、処理はステップＳ１１２へ移行する。
【００２７】
リフォームが完了すると、ステップＳ１１２おいて、リフォーム内容、費用、保証書等の引渡しフォームがリフォーム提供会社側サーバ３からユーザ側端末２−１〜２−ｎへ送信される。この後、処理はステップＳ１１３に移行する。
【００２８】
ステップＳ１１３では、保証書等で定められた期間に合わせて、リフォーム後のアパート、マンション等の住居、商業用ビル、戸建の建造物などが管理される。また、少なくとも年に一度最新の年刊リフォーム情報がユーザ側端末２−１〜２−ｎへ送信される。その後、処理はステップＳ１１４に移行する。
【００２９】
ステップＳ１１４では、前記年刊リフォーム情報を受信したユーザ側端末２−１〜２−ｎから回答があると、処理はステップＳ１０２に戻りリフォーム受発注処理が繰り返される。なお、回答がない場合にはステップＳ１１３に戻る。
【００３０】
図３および図４は、本発明における課金システムの動作を示している。
【００３１】
図３の課金システムは、図２におけるステップＳ１０７に対応している。
【００３２】
ステップＳ２０１では、リフォーム提供会社側サーバ３からユーザ側端末２−１〜２−ｎに着手金要求情報が送信される。この後、処理はステップＳ２０２に移行する。
【００３３】
ステップＳ２０２では、ユーザ側端末２−１〜２−ｎから銀行側端末４を介してリフォーム提供会社側サーバ３に入金される。入金情報受信後、処理はステップＳ２０３に移行する。なお、入金情報が受信されないとステップＳ２０１の動作に戻る。
【００３４】
ステップＳ２０３では、入金情報がリフォーム提供会社側サーバ３に送信される。入金情報がリフォーム提供会社側サーバ３に送信されることで、調査開始命令が発せられ、図２のステップＳ１０８に移行する。
【００３５】
図４の課金システムは、図２におけるステップＳ１１０に対応している。
【００３６】
ステップＳ３０１では、リフォーム提供会社側サーバ３からユーザ側端末２−１〜２−ｎにリフォーム代金要求情報が送信される。この後、処理はステップＳ３０２に移行する。
【００３７】
ステップＳ３０２では、ユーザ側端末２−１〜２−ｎから銀行側端末４を介してリフォーム提供会社側サーバ３に入金される。入金情報受信後、処理はステップＳ３０３に移行する。なお、入金情報が受信されるまでステップＳ３０２の動作は継続される。
【００３８】
ステップＳ３０３では、入金情報がリフォーム提供会社側サーバ３に送信される。入金情報がリフォーム提供会社側サーバ３に送信され、リフォーム提供会社側サーバ３が入金情報を確認することで、リフォームが開始され、図２のステップＳ１１１に移行する。
【００３９】
実施の形態２
図５に示されるように、実施の形態２におけるリフォーム受発注システムでは、第１の回線１を介してリフォーム提供側サーバ３と、１または２以上の協力会社側サーバ８−１〜８−ｎと、逆オークションサーバ１１とが接続される。該協力会社側サーバ８−１〜８−ｎは、該第１の回線１とは異なる第２の回線９を介して、１または２以上の該協力会社の顧客が有するユーザ側端末１０−１〜１０−ｎと接続される。該１または２以上の協力会社８−１〜８−ｎは、それぞれが顧客を有しているので、各協力会社８−１〜８−ｎには別途のユーザ１０−１〜１０−ｎが回線を介して接続される。
【００４０】
また、前記逆オークションサーバ１１は、逆オークションを実施するためのサーバであり、インターネットなどの第１の回線１を介してリフォーム発注者（リフォーム提供会社側サーバ３）および入札者（協力会社側サーバ１１）と接続される。
【００４１】
実施の形態２の逆オークションサーバ１１は、入札者が提示する入札情報を記憶する入札データベース１２と、リフォーム発注者および入札者に入札状況等を公開するためのＷｅｂデータを記憶するＷｅｂデータベース１３とを備えている。
【００４２】
リフォーム提供会社側サーバ３の基本的構成を図６に示す。該リフォーム提供会社側サーバ３は、中央処理装置（ＣＰＵ）３２と、ユーザからのリフォーム要求情報を記憶するＲＡＭ３３と、各種リフォームに関するリフォーム提供会社のマージンの額が記憶されたＲＯＭ３４と、外部に接続するための通信ポート３５と、該リフォーム提供会社側サーバと第１の回線１とを連結するモデム３６とからなる。図６は、基本的な構造であり、これに既知の機能（たとえば高速演算機能や検索機能等）を盛り込むこともできる。その他のサーバおよび端末に関しても、従来のパーソナルコンピュータの機能を用いて構成され得るので、本発明では説明を省略する。
【００４３】
次に、図７を用いて実施の形態２のリフォーム受発注システムについて説明する。
【００４４】
まず、ステップＳ４０２において、該リフォーム提供会社側サーバ３が、ユーザ側端末２−１〜２−ｎのいずれかからリフォーム要求情報を受信する。Ｓ４０３に示すように、リフォーム要求情報としては、少なくともリフォームの規模、リフォームの内容および希望予算が含まれる。ステップＳ４０２が終了すると、ステップＳ４０４に移行する。
【００４５】
ステップＳ４０４において、リフォーム提供会社側サーバ３は、該リフォーム要求情報の実現可能性について、ユーザと話し合う。この場合、実際に会って話し合うのではなく、リフォームの規模や内容で、価格の所定値Ｔを決定しておき、ユーザの希望価格ＰnがＴを超過する場合には、自動的にその旨をユーザに向けて送信するようにするのが好ましい。これにより、手間がかからず、ユーザも即座にリフォーム内容を再考する必要があることが分かるので、貴重な時間の削減につながる。ステップＳ４０４が終了すると、ステップＳ４０６に移行する。
【００４６】
ステップＳ４０６において、ステップＳ４０４における話し合いで決定したユーザのリフォーム要求に合致する過去のリフォーム情報があるか、前記リフォーム情報データベース３１内を検索する。ステップ４０６が終了すると、次にステップ４０８に移行する。
【００４７】
ステップ４０８においては、過去のリフォーム情報に該リフォーム要求情報に合致するリフォーム情報（特にリフォームの規模および内容）があるかないかを検索する。合致するリフォーム情報があった場合、工費Ｐrとリフォーム提供会社のマージンＭを足し合わせた価格が、ユーザの希望価格Ｐnよりも安いかどうかを算出する。安い場合、ステップＳ４２２のリフォームの着工にかかるが、その他の場合には、ステップＳ４１０に移行する。なお、マージンＭは固定額とし、希望価格Ｐnおよび工費Ｐrのみ変動するものであることが好ましい。これによって、マージンＭを削ってまでリフォームをすることがなくなり、リフォーム提供会社への負担が軽減される。
【００４８】
ステップＳ４１０においては、ステップＳ４０４の話し合いで決定したユーザのリフォーム要求情報に基づいて、リフォーム提供会社が、各種協力会社毎に入札条件を設定する。Ｓ４１１に示すように、入札条件は、少なくともリフォームの規模、内容および工費Ｐrを含むものとする。ステップＳ４１０の設定が終わると、ステップＳ４１２に移行する。
【００４９】
ステップＳ４１２においては、ステップＳ４１０で設定した入札条件を逆オークションサーバ１１に送信して、逆オークションを開始する（入札条件をＷｅｂデータとして第１の回線１を介して協力会社側サーバに公開する）。ステップＳ４１２によって逆オークションが開始されると、ステップＳ４１４に移行する。
【００５０】
ステップＳ４１４では、該入札条件に対して入札者があるかないかを確認する。入札者があるとステップＳ４１６に移行し、入札者がない場合にはステップＳ４１４を繰り返す。
【００５１】
ステップＳ４１６においては、入札者があった場合に、工費ＰrとマージンＭを足した額がユーザの希望価格Ｐnよりも安いか高いかを確認する。
【００５２】
安い場合、ステップＳ４１７に移行して、入札情報が入札データベース１２に格納され、ステップＳ４１９において入札されたという状況がＷｅｂデータとしてＷｅｂデータベースに格納され、該Ｗｅｂデータが、第１の回線１を介してリフォーム提供会社側サーバ３および協力会社側サーバ８−１〜８−ｎに備えられたディスプレイ（図示せず）を介して公開される。それにより、ステップＳ４２１で示すように入札の受付が終了する。
【００５３】
ステップＳ４１６において、工費ＰrとマージンＭを足した額が希望価格Ｐnよりも高い場合、ステップＳ４１８に移行する。
【００５４】
ステップＳ４１８では、よりコストを低下させるために、使用する協力会社の商品（リフォーム内容）を、第１の回線１を介してユーザ側端末２−１〜２−ｎに送信する。複数のユーザが、該リフォーム内容を申し込んできた場合、大量発注をすることにより、単価を５割〜３割ぐらいまで低下させることができ、申し込んできた人数に合わせて工費Ｐrがかなり低廉になる。大量発注の手続が終了すると、ステップＳ４２０に移行する。ここで、大量発注の申し込みを誘導するのは、第１の回線１に接続されたユーザだけではなく、当然に、協力会社側サーバ８−１〜８−ｎと、第２の回線９で接続された１または２以上のユーザ１０−１〜１０−ｎに送信することもできる。これによって、大量発注できる可能性が大幅に上昇することが見込まれる。
【００５５】
ステップＳ４２０では、大量発注をした後に、再度工費ＰrとマージンＭを足した額がユーザの希望価格Ｐnよりも安いか高いかを確認する。安い場合、ステップＳ４２２に進み、リフォームに着工する。高い場合、ステップＳ４０４の話し合いのステップに戻り、再度リフォーム内容について検討される。
【００５６】
実施の形態２では、逆オークションを実施した後に、希望価格に達していなければ大量発注を実施しているが、本発明はこれに限られるものではなく、大量発注だけを実施してもよく、また、大量発注を実施した後に、希望価格に達しない場合に、さらに逆オークションを行ってもよい。これは、ユーザがあるコンセプトを基にリフォームを要求してきた場合には、逆オークションによって高い効果が望めるが、特定の製品を指定してきた場合には、逆オークションでは効果が望めず、大量発注によってのみ高い効果が得られうるので、状況に応じて使い分けることができるのがより好ましい。
【００５７】
実施の形態３
たとえば、リフォーム情報データベース３１会員登録されたユーザの情報がさらに記憶されている場合には、記憶された過去のリフォーム情報を活用することにより、リフォーム提供会社からユーザに適したリフォームを提案することができ、能動的なリフォーム受発注を実施することができる。この場合、既存のリフォームパターン（たとえば５０種類）から複数パターンを選択して提案してもよく、新たに考え出したリフォーム内容を提案してもよい。既存のリフォームパターンを提案する場合には、コストが安くてすみ、新たに考え出したリフォーム内容を提案する場合には、ユーザ独自のリフォームになり、ユーザを満足させるリフォーム案が提供できるので、さらなる集客効果が期待できる。
【００５８】
また、部分的に実施済の住まいをさらに全面リフォームを希望する場合には、該実施済の部分を活かしたリフォーム内容を提案することができる。また、パターン集を作成しておき、ユーザにパターン集を配布しておくことで、ユーザが自由にリフォーム案を練ることができる。これによって、ユーザは、自分で考えたリフォーム案であるという実感を得るとともに、負担が軽減されるので、リフォームに取り掛かりやすい。
【００５９】
なお、本発明におけるユーザ側端末２−１〜２−ｎとは、アパートまたはマンションの居住者の端末と、商業用ビルのユーザ端末と、戸建の住民の端末とからなり、各端末の長所を他の端末のリフォームの際に利用することができる。たとえば、商業用ビルに関しては、収納が発達しているので、収納が小さいことが問題であるアパート、マンションに適応することが考えられる。
【００６０】
また、ユーザは、個人に限定されるものではなく、企業や学校法人なども含むものである。企業や学校法人であった場合、ユーザの先にもユーザ同士のネットワークが広がっており、本発明のリフォーム受発注システムの有効範囲が拡大し得る。
【００６１】
以上、本発明について詳細に説明してきたが、上記の実施の形態は本発明の一例に過ぎず、本発明はこれに限定されるものではない。本発明を逸脱しない範囲で変形可能であることは明らかである。
【図面の簡単な説明】
【００６２】
【図１】本発明の実施の形態のリフォーム受発注システムを示すブロック図である。
【図２】本発明の実施の形態のリフォーム受発注の流れを示すフローチャートである。
【図３】本発明の実施の形態における着手金の課金手順を示すフローチャートである。
【図４】本発明の実施の形態におけるリフォーム代金の課金手順を示すフローチャートである。
【図５】本発明の実施の形態２における逆オークション制度を利用したリフォーム受発注システムを示すブロック図である。
【図６】本発明のリフォーム提供会社側サーバの基本的構造を示すブロック図である。
【図７】本発明の実施の形態２のリフォーム受発注の流れを示すフローチャートである。
【符号の説明】
【００６３】
１  第１の回線
２−１〜２−ｎ、１０−１〜１０−ｎ  ユーザ側端末
３  リフォーム提供会社側サーバ
４  銀行側端末
５  分析装置
６  記憶装置
７  制御装置
８−１〜８−ｎ  協力会社側サーバ
９  第２の回線
１１  逆オークションサーバ
１２  入札データベース
１３  Ｗｅｂデータベース
３１  リフォーム情報データベース
３２  ＣＰＵ
３３  ＲＡＭ
３４  ＲＯＭ
３５  通信ポート
３６  モデム
【図１】
2010027019.tif 000003
【図２】
2010027019.tif 000004
【図３】
2010027019.tif 000005
【図４】
2010027019.tif 000006
【図５】
2010027019.tif 000007
【図６】
2010027019.tif 000008
【図７】
2010027019.tif 000009