JP2022136527A - 物件取引支援システム - Google Patents

Abstract

【課題】元付け業者（物件オーナーも含む）と客付け業者との間で、取引が円滑となるように支援する。【解決手段】物件取引支援システムは、元付け業者の扱っている物件に関する情報を登録する登録部と、客付け業者に物件に関する情報を表示するとともに、客付け業者から問い合わせ要求として当該物件の詳細情報の要求を受け付けた場合、当該詳細情報を通知するとともに、元付け業者に客付け業者に関する情報を通知し、問い合わせ要求として当該物件の広告掲載承諾依頼を受け付けた場合、元付け業者と客付け業者との双方に相手方に関する情報を通知し、問い合わせ要求として当該物件の内見依頼を受け付けた場合、元付け業者と客付け業者との双方に相手方に関する情報を通知するとともに、客付け業者に物件の鍵の取り扱いに関する情報、内見お役立ち情報の少なくともいずれかを通知する処理部を有することを特徴とする。【選択図】図１

Description

特許法第３０条第２項適用申請有り 令和２年１０月３０日に株式会社バンブーインターナショナルのウェブサイト（ｈｔｔｐｓ：／／ｒｅｃｘｉｖ．ｃｏｍ／）で掲載。

本発明は、不動産関連の物件のオーナーもしくはオーナーから仲介依頼を受けた元付け業者と、物件を所望する希望者から仲介依頼を受けた客付け業者との間の物件取引を支援する技術に関する。

区分マンション、戸建て、土地などの物件のオーナーもしくはオーナーから仲介依頼を受けた元付け業者（以下、オーナーおよび元付け業者を含めて「元付け業者」と称する）と、物件を所望する希望者（以下、エンドユーザと称する）から仲介依頼を受ける客付け業者との間では、在庫の確認、広告掲載承諾依頼、物件の内見依頼、詳細資料依頼、およびこれに対する応答などの連絡業務が日々行われている。

関連のある技術として、物件を所望するエンドユーザに物件情報を提供するシステムが開示されている（例えば特許文献１）。

特開２０１９－２００６５２号公報

特許文献１のような、実際に使用することを目的として物件を探しているエンドユーザに対し、物件を紹介するサイトは数多く存在する。しかしながら、元付け業者と客付け業者との間の業者間取引においては、未だに電話、ＦＡＸによる連絡が主要なものとなっている。

また特許文献１においては、Ｅメールやチャット等を用いてコミュニケーションを図る旨の記載が認められるが、その処理動作の詳細については何ら示されておらず、具体性に欠けている。

本実施形態の目的は、元付け業者と客付け業者との間での物件取引が円滑となるように支援し、双方にとって利便性の高くなるシステムを提供することを目的とする。

上記課題を解決するため、本発明の物件取引支援システムは、物件のオーナーまたは物件のオーナーから依頼を受ける元付け業者である第１業者と、物件を所望する希望者を見つけて当該希望者から依頼を受ける客付け業者との間の物件取引を支援する、１または複数のコンピュータを含んだ物件取引支援システムであって、第１業者の扱っている物件に関する情報を記憶部に登録する登録部と、客付け業者の使用する端末に物件に関する情報を表示するとともに、第１業者または客付け業者のいずれか若しくは両方に、客付け業者の端末から送信される、物件に対する問い合わせ要求に応じた通知を行う物件閲覧／通知処理部と、を有し、物件閲覧／通知処理部は、問い合わせ要求として、客付け業者から当該物件の詳細情報の提示要求を受け付けた場合、当該詳細情報を客付け業者の端末に通知するとともに、第１業者に客付け業者に関する情報を通知し、問い合わせ要求として、客付け業者から当該物件の広告掲載承諾依頼を受け付けた場合、第１業者と客付け業者との双方に、相手方に関する情報をそれぞれ通知し、問い合わせ要求として、客付け業者から当該物件の内見依頼を受け付けた場合、第１業者と客付け業者との双方に、相手方に関する情報をそれぞれ通知するとともに、客付け業者に物件の鍵の取り扱いに関する情報および鍵の取り扱い以外の物件を内見する際に役立つ内見お役立ち情報の少なくともいずれかを通知する、ことを特徴とする。

本発明により、物件のオーナーまたは元付け業者と、客付け業者との間の物件取引が円滑となるように支援するシステムを提供することができる。

第１実施形態に係るシステムの構成例を示す図である。 ＤＢサーバに保持されているユーザテーブル、役割管理テーブル、調整テーブルの内容を例示する図である。 ＤＢサーバに保持されている物件テーブル、物件ファイルテーブルの内容を例示する図である。 ＤＢサーバに保持されている問い合わせテーブルの内容を例示する図である。 第１実施形態のユーザ情報管理処理を例示するフローチャートである。 ＴＯＰ画面（ログイン画面）を例示する図である。 システムに関する問い合わせを受け付ける画面を例示する図である。 ユーザ一覧画面を例示する図である。 ユーザの新規登録画面を例示する図である。 第１実施形態の物件情報管理処理を例示するフローチャートである。 物件一覧画面を例示する図である。 物件の新規登録画面を例示する図である。 物件の更新（編集）画面を例示する図である。 物件に対する問い合わせ一覧画面を例示する図である。 第１実施形態の物件閲覧／問い合わせ処理を例示するフローチャートである。 元付け業者（ユーザ）検索画面および当該元付業者の扱っている物件の一覧画面を例示する図である。 物件の詳細画面および詳細資料のダウンロード画面を例示する図である。 広告掲載承諾依頼画面および内見・下見依頼画面を例示する図である。 システムにより送信されるメールの内容を例示する図である。 第２実施形態に係るシステムの構成例を示す図である。 不動産購入申込書の一例を示す図である。 連携先のポータルサイトに掲載する際に必要となるデータ項目を例示する図である。 帯画像を例示する図である。 第３実施形態に係るシステムの構成例を示す図である。 第３実施形態の条件登録処理を例示するフローチャートである。 第３実施形態の提案物件送信処理を例示するフローチャートである。 コンピュータの一例として、実施形態のＷｅｂサーバのハードウェア構成例を示す図である。

＜第１実施形態＞
以下、図面を参照しつつ本実施形態の物件取引支援システムの詳細について説明する。図１は、第１実施形態の物件取引支援システムの構成例を示す図である。物件取引支援システム１００は、Ｗｅｂサーバ１１０、Ｍａｉｌサーバ１２０、ＤＢサーバ１３０の各サーバ（コンピュータ）を有する。

Ｗｅｂサーバ１１０は、Ｗｅｂサーバプログラムが導入されており、８０番ポート（ＨＴＴＰ）、４４３番ポート（ＨＴＴＰＳ）などの規定のポート番号で待ち受け、管理用端末１５０、ユーザ端末１６０、客付け業者端末１７０からリクエスト情報（ＨＴＴＰ ＧＥＴ）を受信すると、これに応じてレスポンス（コンテンツ）を返信する。

またＷｅｂサーバ１１０は、ユーザ管理部３１０、物件管理部３２０（登録部）、物件閲覧／通知処理部３３０の各機能部を有しており、物件取引支援システム１００の全体を統括的に制御するサーバとしても機能する。すなわちＷｅｂサーバ１１０は、ウェブページの表示を行うとともに、Ｍａｉｌサーバ１２０にメールの送信を指示し、ＤＢサーバ１３０にデータの管理（＝登録、検索、更新、削除）を行わせる。尚、ユーザ管理部３１０、物件管理部３２０、物件閲覧／通知処理部３３０に相当する機能部を備えさせた、システム全体を統括的に制御するアプリケーションサーバを別途用意してもよい。この場合、アプリケーションサーバからの指令に従い、Ｗｅｂサーバ１１０、Ｍａｉｌサーバ１２０、ＤＢサーバ１３０が動作することとなる。

ユーザ管理部３１０、物件管理部３２０、物件閲覧／通知処理部３３０の各機能部の動作については後述する。尚、これらの機能部および後述する各機能部は、事前に導入されているプログラムが、Ｗｅｂサーバ１１０内のハードウェアリソースと協働することで実現される。

Ｍａｉｌサーバ１２０は、例えば２５番ポート（ＳＭＴＰ）で待ち受けるＭＴＡ（Mail Transfer Agent）であり、Ｅ－Ｍａｉｌ（以下、「メール」と称する）の配送を担う。Ｍａｉｌサーバ１２０は、Ｗｅｂサーバ１１０からＳＭＴＰプロトコルを用いて送信指示を受けると、これに従い、メールをユーザ端末１６０、客付け業者端末１７０宛てに送る。尚、Ｍａｉｌサーバ１２０に所定のメールボックスを用意し、ＰＯＰ３、ＩＭＡＰ４などのプロトコルを実装することで、Ｍａｉｌサーバ１２０は、メールボックス内に蓄積された受信メールをクライアント（ＭＵＡ）に出力することができる。

ＤＢサーバ１３０は、情報を体系づけて記憶するＲＤＢ（Relational Database）が構築されているサーバである。ＤＢサーバ１３０は、Ｗｅｂサーバ１１０の指示に従い、構築された各種テーブルに対して登録、更新、参照、削除などの管理を行う。本実施形態においては、ＤＢサーバ１３０は、ユーザテーブル２１０、役割管理テーブル２２０、調整テーブル２３０、物件テーブル２４０、物件ファイルテーブル２５０、問い合わせテーブル２６０の各テーブルを管理している。

物件取引支援システム１００は、スマートフォン、パーソナルコンピュータ、携帯電話機などの各種通信端末との間でインターネット１８０を介して通信可能となっている。図１では、通信端末として管理用端末１５０、ユーザ端末１６０、客付け業者端末１７０を図示している。

管理用端末１５０は、物件取引支援システム１００のシステム管理者が保持する端末であり、例えば元付け業者（ユーザ）の登録、データ更新、削除などの物件取引支援システム１００の保守を行う。ここでは、管理用端末１５０はインターネット１８０を介して物件取引支援システム１００と通信するものとするが、同じ敷地内や同じセグメント（同一ＬＡＮ内）に配置されていてもよい。

ユーザ端末１６０は、本システムに物件を掲載しているユーザが保持する端末である。ここで「ユーザ」とは、物件取引支援システム１００の運営者にとっての顧客を意味し、物件取引支援システム１００の運営者に使用料などの対価を支払うことで、本システムに物件を掲載するオーナーまたはオーナーから仲介依頼を受けた元付け業者である。尚、本実施形態においては、オーナーと元付け業者とを含めて「元付け業者」（＝第１業者）と称呼する。

客付け業者端末１７０は、客付け業者が保持する端末である。ここで「客付け業者」とは、物件を所望する買主や希望者（以下、エンドユーザと称する）を見つけ出し、エンドユーザに物件の情報を提供して紹介する仲介業者である。客付け業者は、本システムを介して物件を閲覧し、好適な物件があれば、これをエンドユーザに提示したり、もしくはエンドユーザが閲覧可能なポータルサイトに広告したりする。

尚、物件取引支援システム１００は、元付け業者と客付け業者とに利用されることを前提としている。すなわち、物件取引支援システム１００は、元付け業者が所有もしくは取り扱っている物件を掲載し、この掲載物件を客付け業者に提供して、取引のきっかけを作るためのものである。このような前提となっているが、エンドユーザが物件取引支援システム１００の使用を妨げるものではない。

引き続き、ＤＢサーバ１３０に構築されている各テーブルについて、図２～図４を用いて説明する。

図２（Ａ）は、ユーザテーブル２１０のデータ構成を例示する図である。ユーザテーブル２１０は、元付け業者（＝ユーザ）の属性情報を管理して元付け業者を定義付けるためのテーブルである。ユーザテーブル２１０では、元付け業者を一意に特定するための「ＩＤ」（自動採番）、「メールアドレス」、「会社名」（元付け業者の担当者名も含む）、「パスワード」、「ユーザのページ用ＩＤ」、本レコードの「登録日」、「更新日」、および「登録上限」の各属性データが管理される。

図２（Ｂ）に示す役割管理テーブル２２０は、システム内の役割（権限）を定義付けるものであり、役割を一意に特定するための「ＩＤ」、管理の名称である「名前」、管理者の識別名である「スラッグ」、本レコードの「登録日」、「更新日」の各属性データを管理する。

図２（Ｃ）に示す調整テーブル２３０は、ユーザがどのような役割を有しているかを定義付けるために、ユーザと役割（権限）とを関連付けたテーブルである。調整テーブル２３０は、「役割ＩＤ」、「ユーザＩＤ」、「登録日」、「更新日」の各属性データを管理する。ここで「役割ＩＤ」は役割管理テーブル２２０で管理される「ＩＤ」の外部キーであり、「ユーザＩＤ」はユーザテーブル２１０で管理される「ＩＤ」の外部キーである。すなわち、「役割ＩＤ」および「ユーザＩＤ」によりテーブル間でリレーション（リンクと称する）が形成されている。

図３（Ａ）に示す物件テーブル２４０は、元付け業者が取り扱っている物件を定義付けるものであり、元付け業者が各種情報を登録するものである。物件テーブル２４０は、物件を一意に特定するための「ＩＤ」（自動採番）、当該物件の「物件名」、物件の代表画像の格納パスである「物件画像」、物件の詳細説明である「詳細」を有する。物件テーブル２４０は、当該物件の住所である「所在地」、物件までのアクセス手段を示す「交通」、当該物件の「金額」、「間取り／面積」、および物件の種類を示す「物件タイプ」を有する。ここで「物件タイプ」は、「区分マンション」、「戸建て」、「土地」、「収益物件」、「その他」の各値となる。

加えて物件テーブル２４０は、当該物件の「築年月」、および「状態」を有する。「状態」は、システム内における当該物件の状態を示すものであり、「公開中」、「申込みあり」、「契約済」、「非公開」の値をとり、「公開中」、「申込みあり」、「契約済」となっている物件が客付け業者に公開される。尚、客付け業者の気にしていた物件が契約済となってしまったなど、物件の状態が変わったこと客付け業者に知らせるため、「公開中」のみならず、「申し込みあり」、「契約済」も公開するものとする。また物件テーブル２４０は「作成者のＩＤ」を有し、この「作成者のＩＤ」がユーザテーブル２１０の「ＩＤ」の外部キーとなることで、ユーザテーブル２１０と物件テーブル２４０との間でリンクが形成される。

物件テーブル２４０は、後述する詳細資料ダウンロード画面、広告掲載承諾依頼画面、内見・下見依頼画面の各画面を表示するか否かを定義付ける「ダウンロードボタン表示」、「広告ボタン表示」、「内見・下見依頼ボタン表示」を有する。そして物件テーブル２４０は、元付け業者側で設定することができる、物件を一意に特定するための「物件番号」を有する。

物件テーブル２４０は、「鍵の受け渡し方法」、「鍵の空け方」を有する。ここで「鍵の受け渡し方法」は、内見・下見依頼のあった際の鍵の受け渡し方法を定義付けるためのものである。「鍵の受け渡し方法」として、例えば、鍵をキーボックスに入れて現地に配置しておき、このキーボックスを介して鍵を受け渡す「現地対応」や、元付け業者の店舗に来店してもらい、直接手渡しを行う「直接渡し」などの値をとる。また「鍵の空け方」には、「鍵の受け渡し方法」に応じた鍵の取り扱い方法を記したテキストが入る。例えば「現地対応」の場合、「鍵の空け方」には、キーボックスの配置場所、キーボックスの暗証番号や、内見／下見が終わった後の鍵の処置など、元付け業者が客付け業者へ連絡すべき事項を記したテキストが入る。この「鍵の受け渡し方法」は、元付け業者の物件担当者が直接手入力するフリーテキストであり、物件ごとに異なる内容とすることができる。

そして物件テーブル２４０は、「広告掲載用のテキスト」を有する。この「広告掲載用のテキスト」は、広告掲載を認めない「広告不可」や、客付け業者自らで運用するサイトのみ掲載を許可し、他社サイトでの掲載は禁止することを意味する「自社サイトのみ」の値をとる。

加えて物件テーブル２４０は、当該物件についての元付け業者の連絡先である「担当者メールアドレス」、「内見お役立ち情報」、本レコードの「登録日」、「更新日」を有する。「内見お役立ち情報」は、内見・下見対象の物件の近くにコインパーキングが存在するか否かの情報や、駐車料金の安くなるお勧めの時間帯など、鍵の開け方以外の内見・下見の際に役立つ情報をテキストで記したものである。この「内見お役立ち情報」は、元付け業者の物件担当者が直接手入力するフリーテキストであり、物件ごとに異なる内容とすることができる

図３（Ｂ）は、物件ファイルテーブル２５０で管理するデータを図示している。Ｗｅｂ上で物件を表示する際、当該物件の外観や各部屋の写真画像、間取り図などを表示することがあるが、物件ファイルテーブル２５０は、この表示する画像を定義付けるものである。尚、ここでの「画像」とは、ＪＰＥＧ形式、ＰＮＧ形式などのファイルのみならず、ＰＤＦ形式のファイル（間取り図、謄本等は一般的にＰＤＦファイルとなる）も含まれる。

物件ファイルテーブル２５０は、当該レコードを一意に特定するための「ＩＤ」（自動採番）、該当ファイルの「ファイル名」、格納場所を示す「ファイルパス」を有する。また物件ファイルテーブル２５０は、物件テーブル２４０の「ＩＤ」とリンクが形成された外部キーである「物件ＩＤ」、表示の順を規定する「ファイルの順番」を有し、加えて本レコードの「登録日」、「更新日」を有する。

図４は、問い合わせテーブル２６０で管理するデータを図示している。本実施形態の物件取引支援システム１００は、後述のとおり、物件についての詳細資料のダウンロード、広告掲載承諾依頼、内見・下見依頼を客付け業者から受け付ける。問い合わせテーブル２６０は、これら各問い合わせがあった場合の問い合わせ内容や、問い合わせをしてきた客付け業者の会社名や連絡先などの属性情報を蓄積する。

問い合わせテーブル２６０は、問い合わせ毎に一意に自動採番される「ＩＤ」、「会社名」、「担当者名」、「メールアドレス」、「電話番号」などの属性情報を有する。これらは、問い合わせを行った側の情報、すなわち客付け業者の情報となる。

また問い合わせテーブル２６０は、客付け業者が入力した質問内容のテキストを格納する「その他質問」、内見・下見依頼における「内見希望日」、「内見希望時間」、内見または下見のいずれかであるかを示す「タイプ」を有する。問い合わせテーブル２６０は、当該問い合わせが詳細資料のダウンロード、広告掲載承諾依頼、内見・下見依頼のいずれであるかを示す「種類」、「不動産会社ＩＤ」、「物件ＩＤ」、および本レコードの「登録日」、「更新日」を有する。「不動産会社ＩＤ」は、ユーザテーブル２１０の「ＩＤ」とリンクを形成する外部キーであり、「物件ＩＤ」は、物件テーブル２４０の「ＩＤ」とリンクを形成する外部キーである。

引き続き、本実施形態の動作について、フローチャートおよび画面イメージを参照しながら説明する。

図５は、元付け業者（ユーザ）の情報を登録、更新、削除する際の動作例を示すフローチャートである。この処理は、システムの運営側であるシステム管理者やオペレータが、管理用端末１５０を用いて行う。

Ｗｅｂサーバ１１０のユーザ管理部３１０は、管理用端末１５０からのアクセスを受け付けると、図６に示すＴＯＰ画面を表示して（Ｓ１０１）、ログイン情報を受け付ける（Ｓ１０２）。ここでの「表示」とは、Ｗｅｂサーバ１１０がＨＴＭＬデータを端末（ここでは管理用端末１５０）に送信し、当該端末がＨＴＭＬの規約に従いブラウザを介して表示する動作となる（以下、このような動作を「表示」と称する）。

ユーザＩＤ（メールアドレス）およびパスワードを用いた認証が成功するまで、ユーザ管理部３１０は、認証処理を規定回数分くり返し行う（Ｓ１０３：不適合のループ）。もしくはユーザ管理部３１０は、図６に示すリンク６０１の選択を検知すると（Ｓ１０３：忘却）、図７に示す問い合わせ画面を表示する。そして、図７を介して入力される問い合わせ内容に従い、パスワードの再発行を行う再登録処理が行われる（Ｓ１４１）。

ユーザＩＤ、パスワードによる認証が成功すると（Ｓ１０３：適合）、ユーザ管理部３１０は、管理用の画面および元付け業者（ユーザ）の一覧画面を表示する（Ｓ１０４、Ｓ１０５）。

図８は、登録済みの元付け業者の一覧画面を例示したものである。ユーザ管理部３１０は、元付け業者の識別ＩＤ（＝ユーザテーブル２１０の「ＩＤ」）、メールアドレス（＝ユーザテーブル２１０の「メールアドレス」）、名前（＝ユーザテーブル２１０の「会社名」）、物件登録制限数（＝物件テーブル２４０の「登録上限」）、役割（＝役割管理テーブル２２０の「名前」）、登録日、更新日（＝ユーザテーブル２１０の「登録日」「更新日」）の情報を横一列に表示する。加えて、住所、担当者名、電話番号、（担当者の）メールアドレス、プラン、支払方法、登録方法なども、ユーザテーブル２１０の内部もしくは他のテーブルで管理される場合には表示される。

尚、図８に図示する新規ボタン８０１は元付け業者の情報を新規に登録するためのボタンであり、詳細８０２、編集８０３、削除８０４の各アンカーテキストは、それぞれ元付け業者の詳細情報の表示、情報の編集、削除を行うためのものである。また出力ボタン８０５を押下することで、ユーザ管理部３１０は、一覧表示された情報を、ＣＳＶ形式のテキストファイルもしくは表計算ソフト用のファイルに出力する。フィルタボタン８０６は、条件に該当する情報のみを表示させたり、またはソート表示させたりするボタンである。

図５のフローチャートの説明に戻る。ユーザ管理部３１０は、図８に示す新規ボタン８０１、編集８０３、削除８０４のいずれの処理（業務）が選択されたかを判定する（Ｓ１０６）。ここで新規ボタン８０１が押下される場合（Ｓ１０６：新規登録）、ユーザ管理部３１０は、図９に示す登録画面を表示して（Ｓ１１１）、元付け業者（ユーザ）の情報が入力されるのを待ち受ける（Ｓ１１２）。

図９の画面を介して、運営側のシステム管理者やオペレータにより新規登録を行う元付け業者の情報が入力され、登録ボタン９０１が押下された場合、ユーザ管理部３１０は、これら情報に「ＩＤ」、「登録日」、「更新日」などの必要な情報を加えてユーザテーブル２１０および調整テーブル２３０に登録する（Ｓ１１３）。また、Ｗｅｂサーバ１１０は、登録された元付け業者用の管理画面や物件を格納するためのフォルダを作成し、外部から当該フォルダにアクセス可能となるようにする。

本実施形態においては、システム使用料に応じて、登録できる物件数の上限値が設けられている。図８や図９の画面で登録される物件登録上限数（＝ユーザテーブル２１０の「登録上限」）はこの上限値のことである。

図５のフローチャートの説明に戻る。Ｓ１０６において編集８０３が押下される場合（Ｓ１０６：編集）、Ｗｅｂサーバ１１０は、元付け業者（ユーザ）の情報を編集するための画面を表示する（Ｓ１２１）。ユーザ管理部３１０は、図９に示す登録画面と同様の画面であり、各項目に既存値が付されたものを編集用画面として表示して、入力を待ち受ける（Ｓ１２２）。そしてユーザ管理部３１０は、編集された後の情報でユーザテーブル２１０や調整テーブル２３０を更新する（Ｓ１２３）。

Ｓ１０６において削除８０４が押下される場合（Ｓ１０６：削除）、ユーザ管理部３１０は、削除してもよいかの確認ダイアログを表示し（Ｓ１３１）、確認が取れ次第、該当の元付け業者（ユーザ）の情報を削除する（Ｓ１３２）。

このようにしてシステム内に登録された元付け業者は、取り扱っている物件の情報を登録し、客付け業者に情報提供することができる。引き続き、物件の登録、更新、削除の管理について、図１０のフローチャートに基づき説明する。この処理は、元付け業者の使用端末であるユーザ端末１６０がＷｅｂサーバ１１０にアクセスすることで開始される。

Ｓ２０１～Ｓ２０３、Ｓ２６１は、図５のＳ１０１～Ｓ１０３、Ｓ１４１と同様であるため説明を省略する。ログインＩＤ、パスワードによる認証が適合である場合（Ｓ２０３：適合）、Ｗｅｂサーバ１１０の物件管理部３２０は、図１１に示す管理メニュー１１１０を、要求元であるユーザ端末１６０に表示する（Ｓ２０４）。

管理メニュー１１１０の中から「物件一覧」が選択されると（Ｓ２０５：物件一覧）、同じく図１１に示す物件一覧が表示される（Ｓ２０６）。図１１においては、ＩＤ（＝物件テーブル２４０の「ＩＤ」）、物件番号（＝物件テーブル２４０の「物件番号」）、物件名（＝物件テーブル２４０の「物件名」）、詳細資料のダウンロードが行われた回数、広告掲載承諾依頼を受け付けた回数、内見・下見依頼を受け付けた回数が、横一列に表示される。また、リンク（当該物件に割り振られたＵＲＬ）、登録日、更新日の情報が横一列に表示される。ここでリンクは、当該物件を表示するためのリンク先として割り当てられたＵＲＬであり、本実施形態では、Ｗｅｂサーバ１１０用として登録されているドメイン名に、ユーザテーブル２１０の「ＩＤ」と物件テーブル２４０の「ＩＤ」とを組み合わせた文字列を付記することで形成される。

ここで新規ボタン１１０１が押下される場合（Ｓ２１１：新規登録）、物件管理部３２０は、図１２に示す物件登録画面を表示して（Ｓ２１１）、物件の詳細情報の入力を待ち受ける（Ｓ２１２）。また図１２に示すファイルタブ１２０３が選択されると、写真画像や間取り図など、各種ファイルをアップロードする画面に切り替わる。元付け業者は、このアップロード画面を介して写真画像や間取り図をＷｅｂサーバ１１０に送信するとともに、表示順を規定するための各画像の順位付けを行うことができる（Ｓ２１３）。尚、物件詳細タブ１２０２が選択されると、再び図１２に示す画面に戻る。

図１２の画面を介して物件の詳細情報の入力が行われ、登録ボタン１２０１が押下されると、物件管理部３２０は、入力された情報を物件テーブル２４０に登録する。そして物件管理部３２０は、写真画像がアップロードされている場合は、これを規定フォルダに格納し、ファイル名やファイルパスの情報を物件ファイルテーブル２５０に登録する（Ｓ２０４）。

Ｓ２０７において、編集１１０２が押下される場合（Ｓ２０７：編集）、物件管理部３２０は、物件の詳細情報を編集する画面を表示し（Ｓ２２１）、詳細情報の編集を受け付ける（Ｓ２２２）。図１３はこの編集画面を例示しているが、図１２の物件登録画面と大きく異なる点は、一斉送信チェックボックス１３０２が画面内に配置されることである。

この一斉送信チェックボックス１３０２にチェックが付されることで、物件管理部３２０は、以前に当該物件について広告掲載承諾依頼や内見・下見依頼を行った客付け業者に対し、変更があったことを通知する。

すなわち、一斉送信チェックボックス１３０２にチェックが付されていない状態で更新ボタン１３０１が押下された場合（Ｓ２２３：Ｎｏ）、物件管理部３２０は、そのままＤＢサーバ１３０の該当テーブルに対し、更新処理を行う（Ｓ２２４）。一方、一斉送信チェックボックス１３０２にチェックが付された状態で更新ボタン１３０１が押下された場合（Ｓ２２３：Ｎｏ）、物件管理部３２０は、過去に当該物件の広告掲載承諾依頼や内見／下見依頼を行った履歴者の一覧を、問い合わせテーブル２６０から抽出し、メール送信を行う（Ｓ２３２）。この物件情報変更の通知メールには、物件に変更があった旨の定型文、当該する物件の名称やＵＲＬなどの物件を指し示す情報、可能な場合は変更のあった箇所の変更前後の値が記される。

このように、一斉送信チェックボックス１３０２のチェックにより、以前に当該物件について広告掲載承諾依頼や内見・下見依頼を行った客付け業者に対し、変更があったことを通知することで、当該物件に興味があるエンドユーザをもつ客付け業者に対して、当該物件の変更内容を効率良く伝達することができ、当該物件の販売を促進することができる。

尚、ここでは広告掲載承諾依頼や内見／下見依頼を行った客付け業者のみを対象にして変更のあった旨のメール通知を行っているが、詳細情報のダウンロードを行った客付け業者に対してメール通知を行ってもよい。

Ｓ２０７において削除１１０３が押下される場合（Ｓ２０７：削除）、物件管理部３２０は、確認ダイアログを表示し（Ｓ２４１）、確認が取れ次第、該当の物件情報を削除する（Ｓ２４２）。

Ｓ２０５のメニュー選択の判定に説明を戻し、管理メニュー１１１０の中から「お問い合わせ一覧」が選択されると（Ｓ２０５：問い合わせ一覧）、物件管理部３２０は、問い合わせ一覧の画面を表示する（Ｓ２５１）。この問い合わせ一覧は、これまでに発生した詳細情報のダウンロード、広告掲載承諾依頼、内見・下見依頼を一覧にした履歴情報である。

この問い合わせ一覧画面を図１４に示す。問い合わせ一覧は、ＩＤ（＝問い合わせテーブル２６０の「ＩＤ」）、種別（＝問い合わせテーブル２６０の「種類」）、物件名（＝物件テーブル２４０の「物件名」）、会社名、担当者名、メールアドレス、電話番号（＝問い合わせテーブル２６０の「会社名」、「担当者名」、「メールアドレス」、「電話番号」）、その他ご質問など（＝問い合わせテーブル２６０の「その他質問」）、内見希望日、内見希望時間（＝問い合わせテーブル２６０の「内見希望日」、「内見希望時間」）、内見／下見（＝問い合わせテーブル２６０の「タイプ」）、登録日、更新日（＝問い合わせテーブル２６０の「登録日」、「更新日」）の各項目を有している。

フィルタボタン１４０１が操作されることで（Ｓ２５２：画面参照、Ｓ２５３）、物件管理部３２０は、フィルタ条件に合致する問い合わせのみを表示したり、または並び順を変更するソート処理を行ったりする（Ｓ２５４）。そして出力ボタン１４０２が操作されることで（Ｓ２５２：ファイルＤＬ、Ｓ２５５）、物件管理部３２０は、一覧表示された情報をＣＳＶ形式のテキストファイルもしくは表計算ソフト用のファイル形式に出力し、ユーザ端末１６０に送信する（Ｓ２５６）。

次に、このようにして登録された物件を客付け業者が参照し、各種問い合わせ（詳細資料のダウンロード、広告掲載承諾依頼、内見・下見依頼）を行う手法について、図１５のフローチャートを参照しつつ説明する。尚、上記図１４の問い合わせ一覧は、この手法によって得られた情報をもとに表示される。

Ｗｅｂサーバ１１０の物件閲覧／通知処理部３３０は、客付け業者端末１７０から所定のＵＲＬのアクセスを受け付けると、図１６（Ａ）に示すトップ画面を表示し（Ｓ３０１）、閲覧を希望する元付け業者のＩＤが入力されるのを待ち受ける（Ｓ３０２）。客付け業者が検索欄１６０１に元付け業者のＩＤを入力し、検索ボタンを押下すると、物件閲覧／通知処理部３３０は、該当する元付け業者（ユーザ）のトップ画面を表示する（Ｓ３０３）。尚、ここでは元付け業者のＩＤを入力するものとしているが、その他にも会社名など、元付け業者を特定できる情報が入力された場合に、該当する元付け業者（ユーザ）のトップ画面を表示する実装であってもよい。

物件閲覧／通知処理部３３０は、物件テーブル２４０を検索し、入力された元付け業者のＩＤと「作成者のＩＤ」とが合致するレコードの中で、「状態」のカラムが「公開中」となっているレコードがあるか否かを判定する（Ｓ３０４）。ここで公開中となっているレコードが一つもない場合（Ｓ３０４：申込み有、契約済、非公開）、処理は終了する。公開中のものがある場合（Ｓ３０４：公開中）、物件閲覧／通知処理部３３０は、これらを抽出して概要画面を表示する（Ｓ３０５）。尚、「申し込み有」、「契約済」の場合、当該物件についての表示（Ｓ３０５の表示）はなされるものとする。この場合、客付け業者は、エンドユーザに当該物件の紹介を諦めるか、または元付け業者に直接連絡することになり、システムの使用からは外れることになる。

図１６（Ｂ）は、この概要画面を例示する図である。この概要画面では、物件検索欄１６０２とともに、当該元付け業者が公開中、申込みあり、契約済としている全ての物件の概要情報が表示される。物件閲覧／通知処理部３３０は、物件の代表写真１６０３、公開中、申込みあり、契約済などを示すラベル１６０４、および物件情報１６０５を概要情報として少なくとも表示する。物件閲覧／通知処理部３３０は、物件テーブル２４０に格納されている各データを取得し、物件情報１６０５内に表示するデータ、すなわち物件ＩＤ（＝物件テーブル２４０の「ＩＤ」または「物件番号」）、「所在地」、「交通」、「金額」、「物件タイプ」、「築年月」のそれぞれを表示する。また代表写真１６０３としては、物件ファイルテーブル２５０の「ファイルの順番」で、第１位の写真画像が選定される。

物件閲覧／通知処理部３３０は、いずれかの物件が選択されるのを待ち受け（Ｓ３０６）、いずれかの物件の詳細ボタン１６０６が押下されると、当該物件の詳細画面を表示する（Ｓ３０７）。

図１７は、物件の詳細画面を例示する図である。物件詳細情報１７０５は、上記の物件情報１６０５に加え、鍵の受け渡し方法の各項目が少なくとも追加で表示される。広告掲載、鍵の受け渡し方法は、物件テーブル２４０内で管理されている「広告掲載用のテキスト」、「鍵の受け渡し方法」の各値となる。また図１７に示す写真描画領域１７０４は、左右の矢印１７０１が操作されることで、物件ファイルテーブル２５０の「ファイルの順番」で指定されている順序に従い切り替わる。

図１７に示す詳細画面では、タブ１７０２を操作することで、詳細資料ダウンロード画面、広告掲載承諾依頼画面、内見・下見依頼画面の各画面に切り替わる。詳細資料ダウンロードが選択されると（Ｓ３１１：Ｙｅｓ）、詳細資料ダウンロード画面に切り替わる（図１７の状態）。そして物件閲覧／通知処理部３３０は、問い合わせ者（客付け業者）の情報が入力されるのを待ち受け（Ｓ３１２）、入力後に送信ボタン１７０３が押下されると、詳細資料のデータがダウンロードできる画面に遷移する（Ｓ３１３）。そして物件閲覧／通知処理部３３０は、Ｍａｉｌサーバ１２０を介して、詳細資料のダウンロード要求があったことを元付け業者にメール送信する（Ｓ３１４）。尚、ここでの送信先メールアドレスは、物件テーブル２４０の「担当者メールアドレス」である。

タブ１７０２内の広告掲載承諾依頼が選択されると（Ｓ３２１：Ｙｅｓ）、図１８（Ａ）に示す広告掲載承諾依頼画面に切り替わる。そして物件閲覧／通知処理部３３０は、問い合わせ者（客付け業者）の情報が入力されるのを待ち受け（Ｓ３２２）、入力後に送信ボタン１７０３が押下されると、規定の画面（サンキューページ）を表示して（Ｓ３２３）、Ｍａｉｌサーバ１２０を介して元付け業者および問い合わせた客付け業者宛てに、それぞれメールを送信する（Ｓ３２４、Ｓ３２５）。

タブ１７０２内の内見・下見依頼が選択されると（Ｓ３３１：Ｙｅｓ）、図１８（Ｂ）に示す内見・下見依頼画面に切り替わる。そして物件閲覧／通知処理部３３０は、問い合わせ者（客付け業者）の情報、内見希望日時、内見か下見かの別が入力されるのを待ち受ける（Ｓ３３２）。入力後に送信ボタン１７０３が押下されると、物件閲覧／通知処理部３３０は、規定の画面（サンキューページ）を表示して（Ｓ３３３）、Ｍａｉｌサーバ１２０を介して元付け業者および問い合わせた客付け業者宛てに、それぞれメールを送信する（Ｓ３３４、Ｓ３３５）。

図１９は、客付け業者から問い合わせ要求があった際にステップＳ３１４、Ｓ３２４、Ｓ３２５、Ｓ３３４、Ｓ３３５で送信される、元付け業者および客付け業者宛てのメール通知の内容を例示している。

物件閲覧／通知処理部３３０は、客付け業者から詳細資料のダウンロード要求があった場合、客付け業者に詳細資料のＰＤＦファイルを通知するとともに、元付け業者に図１９（Ａ）に示すメールを送信する。このメールの本文には、ダウンロードの要求のあった物件の情報（物件名、ＵＲＬ）、図１７の画面を介して得られた客付け業者を特定する情報（会社名、担当者名、メールアドレス、電話番号）、問い合わせの内容が記されている。

客付け業者から広告掲載承諾依頼があった場合、物件閲覧／通知処理部３３０は、元付け業者に対して図１９（Ｂ）に示すメールを送信するとともに、客付け業者の担当者に対して図１９（Ｃ）に示すメールを送信する。具体的には、物件閲覧／通知処理部３３０は、物件の情報（物件名、ＵＲＬ）、相手方を特定する情報（相手側の会社名、担当者名、メールアドレス、電話番号）、および問い合わせ内容１９０１を、元付け業者、客付け業者の双方にメール送信する。

客付け業者から内見・下見依頼があった場合、物件閲覧／通知処理部３３０は、元付け業者に対して図１９（Ｄ）に示すメールを送信するとともに、客付け業者に対して図１９（Ｅ）に示すメールを送信する。内見・下見依頼があった場合、物件閲覧／通知処理部３３０は、上記の広告掲載承諾依頼と同様に物件の情報、相手方を特定する情報、および問い合わせ内容１９０１を、元付け業者および客付け業者の双方に送信する。これに加えて、物件閲覧／通知処理部３３０は、図３に示す物件テーブル２４０の「鍵の空け方」、「内見お役立ち情報」のテキスト情報をそれぞれ取得し、これらをメール本文に付してから（鍵の空け方の情報１９０２、お役立ち情報１９０３）、Ｍａｉｌサーバ１２０を介して送信する。

鍵の空け方の情報１９０２、お役立ち情報１９０３を付してメール送信を行うことで、内見・下見の際、客付け業者の担当者にとって必要な情報や、事前に通知しておいた方がよい情報を知らせることができ、特に客付け業者にとっての利便性を向上させることができる。

この鍵の空け方の情報１９０２、お役立ち情報１９０３については、物件閲覧／通知処理部３３０は、容易にアクセス可能な図１７に示す画面には表示せず、自らの個人情報を開示した客付け業者にのみメール送信している。すなわち、不特定多数の者に公開すべきでない情報については、個別に通知することができる。

尚、ここでは、鍵の空け方の情報１９０２、お役立ち情報１９０３の両方を客付け業者に通知しているが、少なくともいずれかを通知すればよい。

また一方で、カレンダー機能を設け、内見日程をカレンダーに自動追加し、時間になったら元付け業者の物件担当者宛てにメールを送ってもよい。物件担当者は、いつ誰が内見するのかを思い出すことができる。尚、このカレンダー機能については、他のクラウドシステムを活用してもよく、この場合、元付け業者ごとに１アカウントを登録し、内見依頼があったタイミングで同カレンダーに予定を追加する実装でもよい。

加えて、内見予定時間の１時間後に、「どうでしたか？」などの感想を伺うメールを、客付け業者の担当者宛てにメール送信してもよい。

これまでは、物件取引に際して電話、ＦＡＸによる依頼や回答が主要なものとなっていた。これに対し、第１実施形態によって業者間の物件取引が円滑となるように支援するシステムを提供することができる。

より具体的には、従来では、物件に関する詳細情報を取得する場合には、客付け業者が元付け業者に電話またはＦＡＸして、元付け業者から客付け業者に物件に関する詳細情報をＦＡＸする必要があり、物件の広告掲載依頼を行う場合も客付け業者が元付け業者に電話またはＦＡＸする必要がある。加えて、客付け業者から物件の内見依頼を受け付けた場合にも、客付け業者から元付け業者へ電話またはＦＡＸして、元付け業者から客付け業者に対して物件の鍵の取り扱いに関する情報などをＦＡＸまたはメールする必要があった。本実施形態の支援システムを用いることで、これらの物件に関する詳細情報の取得時、物件の広告掲載依頼時および物件の内見を受け付け時の元付け業者と客付け業者間のやり取りを、客付け業者からの各種要求に応じてメールベースにより自動で行うことで、従来に比べて、物件取引を円滑にすることができる。

＜第２実施形態＞
第２実施形態では、物件取引支援システム１００内で保持している情報を用いて、取引上で交わされる書面の作成を支援したり、他のポータルサイトと連携したり、宣伝広告用の帯画像を作成したりする態様について説明する。

図２０は、第２実施形態に係る物件取引支援システム１００の構成を例示する図である。第２実施形態のＷｅｂサーバ１１０は、書面出力部２００１、システム連携部２００２、帯画像作成部２００３の各機能部を有する。尚、ここではＷｅｂサーバ１１０にこれら各機能部を実装しているが、Ｗｅｂサーバ１１０以外のサーバを別途設け、当該サーバに実装させてもよい。

以下、書面出力部２００１、システム連携部２００２、帯画像作成部２００３の各機能部について説明する。

（書面出力部２００１の動作説明）
書面出力部２００１は、元付け業者と客付け業者との間で受け渡しされる書面を作成する。図２１は、当該書面の規定書式として不動産売買契約書の一部を例示している。この不動産売買契約書において、物件の所在、名称、面積に関するデータ、金額など、主に網掛け表示された箇所については、物件取引支援システム１００側で保有している情報を用いることができる。よって、これら項目を記入済みにした不動産売買契約書を作成することができる。

Ｗｅｂサーバ１１０の書面出力部２００１は、要求元であるユーザ端末１６０もしくは客付け業者端末１７０に、書面の作成を行うための所定画面を表示し、対象となる物件を選択してもらう。

対象となる物件が選択されると、書面出力部２００１は、当該物件に対応した情報を物件テーブル２４０から抽出する。そして書面出力部２００１は、事前に用意されたテンプレートの該当箇所に抽出した値を埋め込むことで、部分的に記入済みとなっている不動産売買契約書を作成することができる。ここでは、表計算ソフト用のデータ形式やＰＤＦデータの書面が作成される。そして書面出力部２００１は、要求元の端末に対しこの書面データを送信する。

送信された書面データは、必要となる項目の一部が既に記入されている状態であることから、書面作成の手間を緩和することができる。尚、ここでは不動産売買契約書を例示したが、これ以外の書面、例えば不動産購入申込書や重要事項説明書などにも適用させることができる。

（システム連携部２００２の動作説明）
システム連携部２００２は、物件取引支援システム１００と、主にエンドユーザに対して物件を紹介する他サイト（ここでは連携先ポータルサイトと称する）との間でデータ連携を行う機能部であり、客付け業者が連携先ポータルサイトに物件を掲載する際の作業手間を低減させるものとなる。

図２２は、大手の不動産紹介サイトで物件を掲載する際に必要となる項目例を一覧にしたものである。この項目の中で、入力者が「システム」となっている項目、すなわち、物件種別、物件名称、物件所在地、交通、物件価格、専有面積、間取りタイプ、築年数については、物件取引支援システム１００側でデータを保有している。よって、これら各データを客付け業者に提供することで、客付け業者は、これら以外の情報を入力するのみで必要な項目をまとめることができる。

Ｗｅｂサーバ１１０のシステム連携部２００２は、客付け業者端末１７０に対して所定画面を表示し、対象となる物件を選択してもらう。これによりシステム連携部２００２は、当該物件に対応した必要項目を、ＤＢサーバ１３０の物件テーブル２４０から抽出し、記入できる項目（図２２の例では入力者が「システム」となっている項目）に値を埋め込んで、一覧データを作成する。ここで作成される一覧データは、例えば表計算ソフトで編集可能なデータ形式である。そしてシステム連携部２００２は、要求元の客付け業者端末１７０に当該一覧データを送信する。

客付け業者は、一覧表データで未入力となっている情報（図２２の例では入力者が「担当者」となっている項目）に対し、手作業で入力を行う。そして客付け業者は、入力後の一覧表データを基にして連携先ポータルサイトの物件登録フォームにデータの入力（コピーアンドペースト）を行う。

このように、送信された一覧表データは、必要となる項目の一部が既に記入されている状態であることから、データの入力手間を緩和することができる。尚、ここでは客付け業者の手作業（コピーアンドペースト）により、連携先ポータルサイトの物件登録フォームに入力するものとするが、連携先ポータルサイトの提供するＡＰＩを用いて、物件取引支援システム１００が直接的に連携先ポータルサイトにデータの入力を行ってもよい。この場合、システム連携部２００２は、物件取引支援システム１００で保持していない情報については客付け業者から入力してもらい、一覧表データを完成させる。そしてシステム連携部２００２は、この一覧データに記される値を、直接的に連携先ポータルサイトに入力する。

（帯画像作成部２００３の動作説明）
帯画像作成部２００３は、例えば広告用の帯画像を生成する機能部である。

ここで、帯画像が付された広告紙を図２３に例示する。図２３の広告紙において、伝達すべき主要な内容（コンテンツ）については領域２３５０に記されるが、その下側に記されるのが帯画像２３６０である。

不動産会社では、他社で取り扱っている物件を自社の顧客に紹介する際、通常、帯画像を他社のものから自社のものに上書きする。この上書きの方法として、現状では、切り貼りなどして自社用の新たな帯を作成し、広告紙の上に、既存の帯を隠すように新たな帯を貼ってコピーするか、もしくはペイントツールなどを用いてＰＣ上で作業する。ＰＣ上で帯画像を作成する場合においても、手打ちで物件の情報などの文字列を入力する必要があり、少なからず作業手間が発生している。帯画像作成部２００３はこのような作業手間を低減させることができる。

帯画像作成部２００３による動作について説明する。尚、ここでは元付け業者用の帯画像を作成するものとして説明する。

帯画像作成部２００３は、所定の操作が行われると、ＤＢサーバ１３０のユーザテーブル２１０から「会社名」を抽出して、これを描画した画像パーツ２３０１を作成する。尚、元付け業者の住所、電話番号、ＦＡＸ番号もユーザテーブル２１０に登録されていれば、これらも抽出して画像パーツ２３０１に含めることができる。

また帯画像作成部２００３は、ユーザテーブル２１０の「ＩＤ」と物件テーブル２４０の「ＩＤ」とを組み合わせて当該物件のＵＲＬを作成し、これを描画した画像パーツ２３０２を作成する。帯画像作成部２００３は、物件テーブル２４０から「物件番号」を抽出し、これを描画した画像パーツ２３０３を作成する。

加えて、帯画像作成部２００３は、当該物件のＵＲＬをあらわす二次元バーコードの画像パーツ２３０４を作成する。帯画像作成部２００３は、サードパーティ製のＡＰＩを用いて二次元バーコードの画像パーツ２３０４を作成してもよい。

このようにして作成された各画像パーツは、テンプレートとなる帯画像に配置され、加えて規定文２３０５も配置されることで、最終的な帯画像が完成する。ここでは、帯画像作成部２００３は、各画像パーツとテンプレート帯画像とをユーザ端末１６０に送信し、元付け業者の担当者が、手作業で各画像パーツをテンプレート帯画像に配置をするものとする。尚、各画像パーツの配置位置が事前に決まっている場合は、この配置位置が定義付けられたデータを事前に作成しておき、帯画像作成部２００３が、このデータに基づき各画像パーツをテンプレート帯画像に配置してもよい。この場合、帯画像作成部２００３は、完成後の帯画像（ＪＰＥＧ形式、ＰＮＧ形式、もしくはＰＤＦ形式）をユーザ端末１６０に送信する。

このような帯画像作成部２００３を設けることで、帯画像の一部もしくは全てを構成に含む帯画像を作成することができ、帯画像の作成手間を低減させることができる。

尚、ここでは元付け業者用の帯画像を作成するものとしたが、エンドユーザに対する物件の取り扱い業者を、元付け業者から客付け業者に切り替えるため、客付け業者用の帯画像を作成するケースの方が多いものと想定される。本実施形態では、客付け業者用の帯画像を作成することも可能であり、このようなケースにも当然適用させることができる。この場合、帯画像作成部２００３は、問い合わせのあった該当物件に関する「会社名」、「担当者名」を、問い合わせテーブル２６０から取得して、会社名および担当者名の画像パーツを作成する。これ以外は、上記と同様の手法となる。また、問い合わせテーブル２６０に住所、電話番号、ＦＡＸ番号などを格納することができる場合、これらの画像パーツも作成することができる。

このように、帯画像作成部は、物件に関する情報、および客付け業者に関する情報をＤＢサーバ１３０から取得し、当該物件が当該客付け業者の扱っている物件であるものと広告するための帯画像を作成することができる。尚、ここでの「作成」は、帯画像を構成する各画像パーツの作成も含む。

ここでは、紙面ベースの広告を作成するものとして説明したが、公益財団法人不動産流通機構の運営しているシステムであるＲＥＩＮＳ（登録商標）に帯画像を掲載することもできる。この場合、ＲＥＩＮＳに物件の情報とともに帯画像をアップロードする。この操作により、ＲＥＩＮＳの登録物件のページに、当該物件の紹介用の帯画像を付すこともできる。

帯画像作成部２００３は、さらに、物件の外観を写した広告掲載の写真中に写り込む特徴ある近隣の建物や番地など示す表示板などにモザイクやぼかしなどの画像処理を施す機能を有していてもよい。一般に、エンドユーザにとって馴染みのある地域の物件が広告に出されている場合、広告中の写真に特徴ある近隣の建物や表示板などが写り込むことで、帯画像に表示された元付け業者に問い合わせなくても、エンドユーザに物件が特定される可能性がある。この場合、エンドユーザは、その広告を掲載している不動産会社ではなく、自らと懇意のある不動産会社に当該物件に関する仲介を依頼することが想定される。よって、このようになることを防止する観点で、帯画像作成部２００３は、帯画像の作成処理に合わせて、広告掲載の写真に対して物件が特定されないように画像処理を施してもよい。

＜第３実施形態＞
第３実施形態の物件取引支援システム１００は、客付け業者の希望する条件と合致する物件が新規で登録されたら、当該物件を客付け業者へ提案する機能を有する。

図２４は、第３実施形態における物件取引支援システム１００の構成を例示する図である。第３実施形態において、Ｗｅｂサーバ１１０は条件登録部２４０１、提案物件送信部２４０２を有し、ＤＢサーバ１３０は物件提案テーブル２４０３を有する。

物件提案テーブル２４０３には、客付け業者が希望する物件の条件（以下、物件希望条件）が管理されており、ここでは、「物件種別」（区分マンション／戸建て／土地など）、「エリア」（市区町村名）、「交通」（最寄り駅／駅徒歩）、「価格帯」（上限金額および下限金額）、専有面積（上限および下限）、間取り（１ＤＫ、２ＬＤＫなど）、築年月（上限および下限）の各種情報、および客付け業者のメールアドレスが登録される。この物件希望条件と合致する物件が見つかった場合、客付け業者宛てにメールで通知する。

図２５、図２６は、第３実施形態に係る動作例を示すフローチャートである。まずは図２５を用いて、物件希望条件の登録動作を説明する。

物件希望条件の登録には、大別して２つの手法があり、一つ目は客付け業者が条件を直接入力して物件希望条件を作成する方法である。もう一つは、広告掲載承諾依頼や内見・下見依頼が行われた物件の「所在地」、「金額」、「面積」などに基づき、物件取引支援システム１００が自らで物件希望条件を作成する方法である。

Ｗｅｂサーバ１１０の条件登録部２４０１は、客付け業者から所定の操作を受け付けると、条件入力画面を表示して（Ｓ４０１）、物件希望条件の入力を待ち受ける（Ｓ４０２）。次いで、客付け業者の担当者メールアドレスを待ち受け（Ｓ４０３）、これらの入力が完了すると、条件登録部２４０１は、入力された物件希望条件およびメールアドレスを物件提案テーブル２４０３に登録する（Ｓ４０４）。

また一方で、Ｗｅｂサーバ１１０の条件登録部２４０１は、上記のＳ４０１～Ｓ４０３とは非同期に次の動作を行う。

条件登録部２４０１は、所定ファイルに書き込まれた、前回の実行日時に関する情報を取得する（このファイルを第１実施日時ファイルとする）。そして条件登録部２４０１は、問い合わせテーブル２６０を参照し（Ｓ４１１）、当該実行日時以降に広告掲載承諾依頼もしくは内見・下見依頼があったか否かを判定する（Ｓ４１２）。ここで該当するレコードが問い合わせテーブル２６０に無い場合（Ｓ４１２：無し）、処理は終了する。一方、該当するレコードがある場合（Ｓ４１２：あり）、条件登録部２４０１は、このレコード内の「物件ＩＤ」を抽出し、これを検索キーとして物件テーブル２４０を参照し、該当物件に基づく物件希望条件を導出する（Ｓ４１３）。例えば「価格帯」など範囲を指定するものについては、条件登録部２４０１は、該当物件の「金額」の値を中心値とした上限金額、下限金額を算出し、「エリア」の場合、「所在地」から市区町村名を抽出する。

そして条件登録部２４０１は、客付け業者の担当者メールアドレスを問い合わせテーブル２６０から抽出し（Ｓ４１４）、物件希望条件とメールアドレスを物件提案テーブル２４０３に登録する（Ｓ４０４）。登録が完了すると、条件登録部２４０１は、今回の実行日時を上記の第１実施日時ファイルに上書きして終了となる。

引き続き提案物件送信部２４０２の動作について、図２６を参照しつつ説明する。尚、図２６に示す動作は、一日一回などの規定周期（バッチ処理）で行われる。

提案物件送信部２４０２は、新規に登録された新着物件が客付け業者の物件希望条件に合致するかを判定する（Ｓ５０１）。提案物件送信部２４０２は、所定ファイル（ここでは第２実施日時ファイルと称する）に書き込まれた、前回の実行日時に関する情報を取得し、この日時以降に登録された物件の情報で、且つ「状態」が公開中となっているものを、物件テーブル２４０より取得する。もしくは、この第２実施日時ファイルに書き込まれている日時以降に「状態」が公開中へと更新された物件の情報を取得する。

ここで取得される情報には、少なくとも「物件タイプ」、「所在地」、「金額」、「間取り／面積」、「築年」の各値が含まれており、提案物件送信部２４０２は、これらが物件提案テーブル２４０３に登録されている物件種別、エリア、交通、価格帯、専有面積、間取り、築年月に合致するかを総当たりで判定する。

合致する新着物件が無ければ（Ｓ５０１：ヒット無し）、今回処理した日時の情報を第２実施日時ファイルに上書きして終了となる。

一方、合致する新着物件がある場合（Ｓ５０１：ヒットあり）、提案物件送信部２４０２は、客付け業者の担当者メールアドレスに当該物件に関する上記の物件種別、エリア、交通、価格帯、専有面積、間取り、築年月を送信する（Ｓ５０２）。この際、提案物件送信部２４０２は、事前設定された定型文および当該物件のＵＲＬもメール本文に付して送信する。送信すべき提案メールを全て送信し終わったら、提案物件送信部２４０２は、今回処理した日時の情報を第２実施日時ファイルに上書きする。

ここで客付け業者より配信停止依頼を受け付けた場合（Ｓ５０３：Ｙｅｓ）、提案物件送信部２４０２は、該当する物件希望条件を物件提案テーブル２４０３から削除して終了となる。配信停止依頼が無い場合（Ｓ５０３：Ｎｏ）、処理はそのまま終了となり、次回、希望の物件が登録された場合に当該物件の情報がメール送信される。

最後に、本実施形態に係るコンピュータの一例として、Ｗｅｂサーバ１１０のハードウェア構成例を図２７に示す。尚、Ｍａｉｌサーバ１２０、ＤＢサーバ１３０や各端末（１５０、１６０、１７０）も、図２７に示すものと同じ構成を有している。

Ｗｅｂサーバ１１０は、一般的なコンピュータと同等のハードウェア資源を備えている。したがって、ＣＰＵ２７１０、ＲＡＭ２７２０、ＲＯＭ２７３０、ストレージ２７４０、および通信Ｉ／Ｆ２７５０がバス２７６０を介して接続されている。通信Ｉ／Ｆ２７５０は、有線または無線で機器間を通信するためのインタフェースを構成し、Ｗｅｂサーバ１１０以外の外部機器と接続する。

ＣＰＵ２７１０は演算処理装置であり、Ｗｅｂサーバ１１０全体の動作を制御する。ＲＡＭ２７２０は揮発性記憶装置であり、ＲＯＭ２７３０は不揮発性記憶装置である。そしてストレージ２７４０は、ＨＤＤやＳＳＤなどの大容量記憶装置（補助記憶装置、記憶部）である。

このハードウェア構成において、ＲＯＭ２７３０やストレージ２７４０に格納されたプログラム２７４１は、ＲＡＭ２７２０にロードされ、ＣＰＵ２７１０がこれを演算実行する。この実行により、種々の機能モジュールを含むソフトウェア制御部が構成される。このようにして構成されたソフトウェア制御部と、上記の構成を含むハードウェア資源との組み合わせによって、各図面に示される機能ブロックが構成される。

本実施形態の物件取引支援システム１００は、上記のように複数のサーバにより構成されているが、１つのサーバに集約させてもよい。また、第１～第３実施形態の態様を相互に組み合わせてもよい。

本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施形態はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、なんら拘束されない。さらに、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、すべて本発明の範囲内のものである。

１００：物件取引支援システム、１１０：Ｗｅｂサーバ、１２０：Ｍａｉｌサーバ、
１３０：ＤＢサーバ、１５０：管理用端末、１６０：ユーザ端末、
１７０：客付け業者端末、１８０：インターネット、
２１０：ユーザテーブル、２２０：役割管理テーブル、２３０：調整テーブル、
２４０：物件テーブル、２５０：物件ファイルテーブル、２６０：合わせテーブル
３１０：ユーザ管理部、３２０：物件管理部、３３０：通知処理部、
２００１：書面出力部、２００２：システム連携部、２００３：帯画像作成部
２４０１：条件登録部、２４０２：提案物件送信部、２４０３ ：物件提案テーブル。

上記課題を解決するため、本発明の物件取引支援システムは、物件のオーナーまたは物件のオーナーから依頼を受ける元付け業者である第１業者と、物件を所望する希望者を見つけて当該希望者から依頼を受ける客付け業者との間の物件取引を支援する、１または複数のコンピュータを含んだ物件取引支援システムであって、第１業者の扱っている物件に関する情報を記憶部に登録する登録部と、客付け業者の使用する端末に物件に関する情報を表示するとともに、第１業者または客付け業者のいずれか若しくは両方に、客付け業者の端末から送信される、物件に対する問い合わせ要求に応じた通知を行う物件閲覧／通知処理部と、を有し、物件閲覧／通知処理部は、問い合わせ要求として、客付け業者から当該物件の詳細情報の提示要求を受け付けた場合、当該詳細情報を客付け業者の端末に通知するとともに、第１業者に客付け業者に関する情報を通知し、問い合わせ要求として、客付け業者から当該物件の広告掲載承諾依頼を受け付けた場合、第１業者に客付け業者および広告掲載承諾依頼を受け付けた物件に関する情報を、客付け業者に第１業者に関する情報を、それぞれ通知し、問い合わせ要求として、客付け業者から当該物件の内見依頼を受け付けた場合、第１業者に客付け業者および内見依頼を受け付けた物件に関する情報を、客付け業者に第１業者に関する情報を、それぞれ通知するとともに、客付け業者に物件の鍵の取り扱いに関する情報および鍵の取り扱い以外の物件を内見する際に役立つ内見お役立ち情報の少なくともいずれかを通知する、ことを特徴とする。

上記課題を解決するため、本発明の物件取引支援システムは、物件のオーナーまたは物件のオーナーから依頼を受ける元付け業者である第１業者が使用するユーザ端末と、物件を所望する希望者を見つけて当該希望者から依頼を受ける客付け業者が使用する客付け業者端末とに少なくとも通信し、第１業者と客付け業者との間の物件取引を支援する、１または複数のコンピュータを含んだ物件取引支援システムであって、第１業者に関する情報と、第１業者の扱っている物件に関する情報と、第１業者の取り扱っている物件における、詳細情報、詳細資料ダウンロードの提示要求に関する情報、広告掲載承諾依頼に関する情報、内見・下見依頼に関する情報、鍵の取り扱いに関する情報および鍵の取り扱い以外の物件を内見する際に役立つ内見お役立ち情報と、を物件テーブルに登録する登録部と、客付け業者端末から第１業者に関する情報を受け付けると、登録部で登録された物件テーブルから受け付けた第１業者が取り扱っている物件に関する情報を取得して、一覧表示した概要情報の一覧を、客付け業者端末に表示して、客付業者端末より概要情報の一覧からの選択情報を受け付け、客付け業者端末より概要情報の一覧からの選択情報を受け付けると、当該選択された物件に関する詳細情報を物件テーブルから取得して、当該取得した物件に関する情報を客付け業者端末に送信するとともに、ユーザ端末または客付け業者端末のいずれか若しくは両方に、客付け業者端末から送信される、物件に対する問い合わせ要求に応じた通知を行う物件閲覧／通知処理部と、を有し、物件閲覧／通知処理部は、取得した物件に関する詳細情報を客付け業者端末に送信する際に、物件テーブルから詳細資料ダウンロードの提示要求に関する情報、広告掲載承諾依頼に関する情報および内見・下見依頼に関する情報も取得し、これらの取得内容に応じて、客付け業者端末に、詳細資料ダウンロードの提示要求に関する情報、広告掲載承諾依頼に関する情報および内見・下見依頼に関する情報、の問い合わせ要求も、客付け業者端末に送信し、客付業者端末から、問い合わせ要求として取得した物件の詳細資料ダウンロードの提示要求に関する情報を受け付けた場合、取得した物件に関する詳細情報を客付け業者端末にダウンロード可能となるように通知するとともに、ユーザ端末に客付け業者に関する情報を通知し、客付業者端末から、問い合わせ要求として取得した物件の広告掲載承諾依頼に関する情報の提示要求を受け付けた場合、物件テーブルから第１業者に関する情報も取得し、ユーザ端末に客付け業者および取得した物件に関する情報を、客付け業者端末に第１業者に関する情報を、それぞれ通知し、客付業者端末から、問い合わせ要求として取得した物件の内見・下見依頼に関する情報の提示要求を受け付けた場合、物件テーブルから、第１業者に関する情報、鍵の取り扱いに関する情報および内見・下見に関する情報も取得し、ユーザ端末に客付け業者および取得した物件に関する情報を、客付け業者端末に第１業者に関する情報を、それぞれ通知するとともに、客付け業者端末には、物件の鍵の取り扱いに関する情報および内見お役立ち情報の少なくともいずれかを通知する、ことを特徴とする。

Claims (3)

1. 物件のオーナーまたは物件のオーナーから依頼を受ける元付け業者である第１業者と、物件を所望する希望者を見つけて当該希望者から依頼を受ける客付け業者との間の物件取引を支援する、１または複数のコンピュータを含んだ物件取引支援システムであって、
   前記第１業者の扱っている物件に関する情報を記憶部に登録する登録部と、
   前記客付け業者の使用する端末に前記物件に関する情報を表示するとともに、前記第１業者または前記客付け業者のいずれか若しくは両方に、前記客付け業者の前記端末から送信される、物件に対する問い合わせ要求に応じた通知を行う物件閲覧／通知処理部と、
   を有し、
   前記物件閲覧／通知処理部は、
   前記問い合わせ要求として、前記客付け業者から当該物件の詳細情報の提示要求を受け付けた場合、当該詳細情報を前記客付け業者の端末に通知するとともに、前記第１業者に前記客付け業者に関する情報を通知し、
   前記問い合わせ要求として、前記客付け業者から当該物件の広告掲載承諾依頼を受け付けた場合、前記第１業者と前記客付け業者との双方に、相手方に関する情報をそれぞれ通知し、
   前記問い合わせ要求として、前記客付け業者から当該物件の内見依頼を受け付けた場合、前記第１業者と前記客付け業者との双方に、相手方に関する情報をそれぞれ通知するとともに、前記客付け業者に前記物件の鍵の取り扱いに関する情報および前記鍵の取り扱い以外の前記物件を内見する際に役立つ内見お役立ち情報の少なくともいずれかを通知する、
   ことを特徴とする物件取引支援システム。
2. 前記物件閲覧／通知処理部は、前記第１業者が問い合わせ要求のあった物件に関する情報に変更を発生させた場合、当該物件に対し以前に問い合わせ要求を行った前記客付け業者に対し、当該物件に関する情報を一斉配信することを特徴とする、請求項１に記載の物件取引支援システム。
3. 前記物件閲覧／通知処理部は、さらに、問い合わせ要求のあった際、当該問い合わせを行った前記客付け業者に関する情報を前記記憶部に記憶させ、
   前記物件取引支援システムは、さらに、前記物件に関する情報、および前記客付け業者に関する情報を前記記憶部から取得し、当該物件が当該客付け業者の扱っている物件であるものと広告するための帯画像を作成する帯画像作成部を有することを特徴とする、請求項１または２に記載の物件取引支援システム。

Images