特許 7109804 出力プログラム、出力方法及び出力装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-07-22

(45)【発行日】2022-08-01

(54)【発明の名称】出力プログラム、出力方法及び出力装置

(51)【国際特許分類】

   G06Q 50/16 20120101AFI20220725BHJP

   G06Q 30/02 20120101ALI20220725BHJP

【ＦＩ】

G06Q50/16

G06Q30/02 398

【請求項の数】 11

(21)【出願番号】P 2020171370

(22)【出願日】2020-10-09

(65)【公開番号】P2021068437

(43)【公開日】2021-04-30

【審査請求日】2021-09-30

(31)【優先権主張番号】P 2019190507

(32)【優先日】2019-10-17

(33)【優先権主張国・地域又は機関】JP

【早期審査対象出願】

(73)【特許権者】

【識別番号】518189367

【氏名又は名称】株式会社ウチダレック

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野 英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野 登夫

(72)【発明者】

【氏名】内田 光治

【審査官】永野 一郎

(56)【参考文献】

【文献】特開２０１７－０１６３２１（ＪＰ，Ａ）

【文献】中国特許出願公開第１０９６１５１２８（ＣＮ，Ａ）

【文献】特開２００１－１７５６８６（ＪＰ，Ａ）

【文献】特開２０１７－１３４６２１（ＪＰ，Ａ）

【文献】中国特許出願公開第１０８２３００３９（ＣＮ，Ａ）

【文献】特開２０１７－０９１４３９（ＪＰ，Ａ）

【文献】特開２０１６－１８１１９６（ＪＰ，Ａ）

【文献】特開２０１９－１４５１００（ＪＰ，Ａ）

【文献】特開２００２－１３２８９３（ＪＰ，Ａ）

【文献】特開２０１７－１８７９３７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１８／０２５３７８０（ＵＳ，Ａ１）

【文献】小林 直樹，「刺さる」を工学的に解明 曖昧な魅力をＡＩで予測し候補を推薦，最新 マーケティングの教科書 ２０１９ ，日経ＢＰ社 ，2019年01月09日，p.42-43

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

借主の物件に対する希望条件を取得し、
取得した前記希望条件の少なくとも一部に合致する物件の物件情報を取得し、
前記借主の属性及び取得した前記希望条件、並びに取得した前記物件情報を、借主の属性、及び前記借主の物件に対する希望条件、並びに物件情報を説明変数とし、前記物件の成約確率を目的変数とする決定木へ、入力して前記物件の成約確率を取得し、
取得した成約確率を出力する
処理をコンピュータに行わせる
ことを特徴とする出力プログラム。

【請求項2】

前記借主の属性は、年齢、性別又は分類を含む
ことを特徴とする請求項１に記載の出力プログラム。

【請求項3】

上位所定数の前記成約確率に対応する前記物件情報を出力する
ことを特徴とする請求項１又は請求項２に記載の出力プログラム。

【請求項4】

コンピュータが、
借主の物件に対する希望条件を取得し、
取得した前記希望条件の少なくとも一部に合致する物件の物件情報を取得し、
前記借主の属性及び取得した前記希望条件、並びに取得した前記物件情報を、借主の属性、及び前記借主の物件に対する希望条件、並びに物件情報を説明変数とし、前記物件の成約確率を目的変数とする決定木へ、入力して前記物件の成約確率を取得し、
取得した成約確率を出力する
ことを特徴とする出力方法。

【請求項5】

借主の物件に対する希望条件を取得する第１取得部と、
取得した前記希望条件の少なくとも一部に合致する物件の物件情報を取得する第２取得部と、
前記借主の属性及び取得した前記希望条件、並びに取得した前記物件情報を、借主の属性、及び前記借主の物件に対する希望条件、並びに物件情報を説明変数とし、前記物件の成約確率を目的変数とする決定木へ、入力して前記物件の成約確率を取得する第３取得部と、
取得した成約確率を出力する出力部と
を備えることを特徴とする出力装置。

【請求項6】

不動産物件に関する質問に対する回答情報、個人情報、及び成約物件情報を含む教師データで学習した学習済みモデルに、回答情報、個人情報を含む入力データを入力し、物件情報を取得し、
取得した物件情報に適合する物件情報を取得し、
前記適合する物件情報に係る成約履歴を取得し、
取得した前記成約履歴に基づき、成約した物件と共に内覧したものの成約に至らなかった物件の情報を取得し、
前記適合する物件情報、及び、内覧したものの成約に至らなかった物件の情報を出力する
処理をコンピュータに行わせること
を特徴とする出力プログラム。

【請求項7】

前記教師データ及び前記入力データは、物件周辺の環境情報を含む追加情報を含んでいること
を特徴とする請求項６に記載の出力プログラム。

【請求項8】

前記物件情報は、借主に適合する複数の物件情報を含むこと
を特徴とする請求項７に記載の出力プログラム。

【請求項9】

前記物件情報は物件が自社管理か否かを示す管理種別を含み、該管理種別が自社管理である前記物件情報を出力すること
を特徴とする請求項６から請求項８の何れか１項に記載の出力プログラム。

【請求項10】

コンピュータが、不動産に関する質問に対する回答情報、個人情報、及び成約物件情報を含む教師データで学習した学習済みモデルに、回答情報、個人情報を含む入力データを入力し、物件情報を取得し、
取得した物件情報に適合する物件情報を取得し、
前記適合する物件情報に係る成約履歴を取得し、
取得した前記成約履歴に基づき、成約した物件と共に内覧したものの成約に至らなかった物件の情報を取得し、
前記適合する物件情報、及び、内覧したものの成約に至らなかった物件の情報を出力する
ことを特徴とする出力方法。

【請求項11】

不動産に関する質問に対する回答情報、個人情報、及び成約物件情報を含む教師データで学習した学習済みモデルに、回答情報、個人情報を含む入力データを入力し、物件情報を取得する第１の取得部と、
取得した物件情報に適合する物件情報を取得する第２の取得部と、
前記適合する物件情報に係る成約履歴を取得する第３の取得部と、
取得した前記成約履歴に基づき、成約した物件と共に内覧したものの成約に至らなかった物件の情報を取得する第４の取得部と、
前記適合する物件情報、及び、内覧したものの成約に至らなかった物件の情報を出力する出力部と
を備えることを特徴とする出力装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、不動産の物件情報を出力する出力プログラム等に関する。

【背景技術】

【0002】

不動産を借りたい借主に適した物件情報（住宅情報）を提供するシステムが提案されている（例えば特許文献１）。しかし、借主が自らの希望を的確な検索条件として入力しなければ、検索にヒットする物件には適合しないものが含まれてしまう可能性がある。

【0003】

一方、成約実績を用いることにより、適合する不動産を紹介するシステムが提案されている（例えば特許文献２）。特許文献２に記載のシステムは、ユーザを複数のクラスタのいずれかに紐づけ、紐づけたクラスタに分類される成約実績に含まれる成約不動産を出力する。出力される不動産はクラスタに対応するものであるため、ユーザの細かい希望は考慮されない。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２００３－２８１１７５号公報

【文献】特開２０１６－２０６７８３号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

本発明はこのような状況に鑑みてなされたものである。その目的は、借主に適した不動産の物件情報を選択するために、物件の成約確率を出力する出力プログラム等を提供することである。

【課題を解決するための手段】

【0006】

本発明に係る出力プログラムは、借主の物件に対する希望条件を取得し、取得した前記希望条件の少なくとも一部に合致する物件の物件情報を取得し、前記借主の属性及び取得した前記希望条件、並びに取得した前記物件情報を、借主の属性、及び前記借主の物件に対する希望条件、並びに物件情報を説明変数とし、前記物件の成約確率を目的変数とする決定木へ、入力して前記物件の成約確率を取得し、取得した成約確率を出力する処理をコンピュータに行わせることを特徴とする。

【発明の効果】

【0007】

本発明にあっては、借主に適した不動産の物件情報を選択するために、物件の成約確率出力することが可能となる。

【図面の簡単な説明】

【0008】

【図1】提供システムの構成例を示す説明図である。

【図2】提供サーバのハードウェア構成例を示すブロック図である。

【図3】物件ＤＢの例を示す説明図である。

【図4】部屋基本ＤＢの例を示す説明図である。

【図5】基本設備ＤＢの例を示す説明図である。

【図6】付加情報ＤＢの例を示す説明図である。

【図7】契約条件ＤＢの例を示す説明図である。

【図8】周辺ＤＢの例を示す説明図である。

【図9】特記ＤＢの例を示す説明図である。

【図10】施設ＤＢの例を示す説明図である。

【図11】回答ＤＢの例を示す説明図である。

【図12】見込み顧客ＤＢの例を示す説明図である。

【図13】履歴ＤＢの例を示す説明図である。

【図14】追加情報ＤＢの例を示す説明図である。

【図15】部屋選定モデルの生成処理に関する説明図である。

【図16】部屋選定処理に関する説明図である。

【図17】部屋選定モデル生成処理の手順例を示すフローチャートである。

【図18】部屋選定処理の手順例を示すフローチャートである。

【図19】部屋選定結果表示画面の例を示す説明図である。

【図20】内覧部屋選定処理の手順例を示すフローチャートである。

【図21】内覧部屋選定結果表示画面の例を示す説明図である。

【図22】実績データＤＢの例を示す説明図である。

【図23】決定木生成処理の手順例を示すフローチャートである。

【図24】実績データ作成処理の手順例を示すフローチャートである。

【図25】決定木分析処理の手順を示すフローチャートである。

【図26】決定木の例を示す説明図である。

【図27】部屋選定処理の他の手順例を示すフローチャートである。

【図28】部屋選定処理の他の手順例を示すフローチャートである。

【図29】部屋選定処理の他の手順例を示すフローチャートである。

【図30】部屋検索処理の手順例を示すフローチャートである。

【図31】検索結果表示画面の例を示す説明図である。

【図32】部屋検索処理の手順例を示すフローチャートである。

【発明を実施するための形態】

【0009】

（実施の形態１）
以下実施の形態を、図面を参照して説明する。図１は提供システムの構成例を示す説明図である。提供システム１００は、提供サーバ１、営業端末２及びユーザ端末３を含む。提供サーバ１、営業端末２及びユーザ端末３はネットワークＮにより、互いに通信可能に接続されている。提供サーバ１は主として不動産の賃貸物件の情報を提供する。営業端末２は不動産業者の営業員が使用する端末である。営業端末２は物件の条件を取得し、取得した物件の情報を提供サーバ１に送信し、物件情報を提供サーバ１から受信する。ユーザ端末３は不動産物件を探している一般ユーザが使用する端末である。図１には、営業端末２及びユーザ端末３はそれぞれ３台を示しているが、それに限らない。営業端末２は１台以上であればよい。ユーザ端末３も１台以上であればよい。但し、提供サーバ１が一般ユーザに情報提供を行わない場合、ユーザ端末３は提供システム１００には含まれない。

【0010】

図２は提供サーバのハードウェア構成例を示すブロック図である。提供サーバ１はワークステーション、サーバコンピュータ、ブレードサーバー等で構成する。提供サーバ１（）は制御部１１、主記憶部１２、補助記憶部１３、通信部１５及び読み取り部１６を含む。各部はバスＢにより接続されている。なお、提供サーバ１の機能をクラウドサービスで実現してもよい。また、制御装置を複数のコンピュータからなるマルチコンピュータ、ソフトウェアによって仮想的に構築された仮想マシン又は量子コンピュータで構成しても良い。

【0011】

制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有する。制御部１１は、補助記憶部１３に記憶された制御プログラム１Ｐ（出力プログラム）を読み出して実行することにより、提供サーバ１に係る種々の情報処理、制御処理等を行う。制御部１１は制御プログラム１Ｐの実行により、取得部又は出力部等の機能部として動作する。

【0012】

主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等である。主記憶部１２は主として制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。

【0013】

補助記憶部１３はハードディスク又はＳＳＤ（Solid State Drive）等であり、制御部１１が処理を実行するために必要な制御プログラム１Ｐや各種ＤＢ（Database）を記憶する。補助記憶部１３は、物件ＤＢ１３１、部屋基本ＤＢ１３２、基本設備ＤＢ１３３、付加情報ＤＢ１３４、契約条件ＤＢ１３５、周辺ＤＢ１３６、特記ＤＢ１３７、施設ＤＢ１３８、回答ＤＢ１３９、見込み顧客ＤＢ１３Ａ、履歴ＤＢ１３Ｂ、及び追加情報ＤＢ１３Ｃを記憶する。また、補助記憶部１３は部屋選定モデル１４１を記憶する。補助記憶部１３は提供サーバ１に接続された外部記憶装置であってもよい。補助記憶部１３に記憶する各種ＤＢ等を、クラウドストレージに記憶してもよい。

【0014】

通信部１５はネットワークＮを介して、営業端末２及びユーザ端末３と通信を行う。また、制御部１１が通信部１５を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、補助記憶部１３に記憶してもよい。

【0015】

読み取り部１６はＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ及びＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読み取り部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、補助記憶部１３に記憶してもよい。また、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでもよい。

【0016】

図３は物件ＤＢの例を示す説明図である。物件ＤＢ１３１は物件建物に関する情報を記憶する。物件ＤＢ１３１は、賃貸物件が集合住宅に属する場合、集合住宅の情報を記憶する。物件ＤＢ１３１は、賃貸物件が一戸建ての場合、一戸建ての情報を記憶する。物件ＤＢ１３１は、物件ＩＤ列、物件名列、物件住所列、エリア列、最寄駅列、校区列、管理種別列、構造列、築年数列、及び共用部列を含む。物件ＩＤ列は建物を一意に特定可能な物件ＩＤを記憶する。物件ＩＤは新たなレコードが登録される際に、発行する。物件名列は建物の名称を記憶する。物件住所列は建物の所在地を記憶する。エリア列は所在地のエリアを記憶する。エリアは営業員が判断して入力してもよいが、町丁目とエリアとの対応表を作成しておき、対応表に基づいて一律的に決定してもよい。最寄駅列は建物の最寄駅及び最寄駅から交通手段を記憶する。校区列は、建物の所在地に対応する公立小学校の校区、及び公立中学校の校区を記憶する。具体的には小学校及び中学校の名称を記憶する。管理種別列は建物の管理種別を記憶する。管理種別は、例えば、自社保有、自社管理、一括借上、又は一般である。自社保有は不動産会社が保有している建物を自らが管理していることを示す。自社管理は委託を受けて、不動産会社が管理していることを示す。一括借上は建物全体を建物のオーナから一括で借り上げて管理していることを示す。構造列は建物の構造を記憶する。建物の構造は、例えば、木造、鉄骨造、軽量鉄骨造、又はＲＣ造である。木造は、建物の主要構造部である柱や梁、壁、床などに木材を使用する構造をいう。鉄骨造は建物の骨組みに鉄骨を用いる構造をいう。鉄骨造は重量鉄骨造ともいう。軽量鉄骨造は鉄骨造のうち、厚さが６ｍｍ未満の鋼材を用いる構造をいう。ＲＣ造は鉄筋コンクリート造ともいう。ＲＣ造はコンクリートに鉄筋を埋め込んだ構造をいう。築年数列は建物の築年数を記憶する。築年数は建物が完成した後の経過年数をいう。共用部列は建物が集合住宅である場合、入居者が共用する設備を記憶する。物件建物に関する情報を物件建物情報ともいう。

【0017】

図４は部屋基本ＤＢの例を示す説明図である。部屋基本ＤＢ１３２は部屋の基本的な情報（部屋基本情報）を記憶する。建物が集合住宅である場合、部屋基本ＤＢ１３２は各住戸の基本的な情報を記憶する。建物が一戸建ての場合、部屋基本ＤＢ１３２は物件ＤＢ１３１には含まれない建物の情報を記憶する。部屋基本ＤＢ１３２は部屋ＩＤ列、住戸番号列、間取り列、物件ＩＤ列、保証区分列、家賃列、管理費列、空室期間列、及び状況列を含む。部屋ＩＤ列は部屋を一意に特定可能な部屋ＩＤを記憶する。部屋ＩＤは新たなレコードが登録される際に、発行する。住戸番号列は住戸番号を記憶する。住戸番号は部屋番号ともいう。建物が一戸建ての場合、住戸番号は記憶されない。間取り列は間取りを表す文字列を記憶する。間取りは、例えば、２ＬＤＫ、３ＤＫなどである。物件ＩＤ列は対応する建物の物件ＩＤを記憶する。保証区分列は家賃保証会社に加入し、家賃保証契約を結ぶ必要があるか否かを記憶する。加入が必要な場合、保証区分列は加入を記憶する。加入が不要の場合、保証区分列は不要を記憶する。家賃保証会社は賃貸保証会社ともいう。家賃列は部屋の月極の家賃を記憶する。管理費列は部屋の月極の管理費を記憶する。空室期間列は部屋が空室である場合、空室の期間を記憶する。状況列は部屋の入居に関する情報を記憶する。例えば次の値を、状況列は記憶する。部屋に入居者がいる場合、状況列は入居中を記憶する。部屋に入居者がいるが退去する予定となっている場合、状況列は退去予定を記憶する。

【0018】

図５は基本設備ＤＢの例を示す説明図である。基本設備ＤＢ１３３は部屋の基本な設備に関する情報（基本設備情報）記憶する。基本設備ＤＢ１３３は、部屋ＩＤ列、間取り内訳列、玄関列、及び水回り列を含む。部屋ＩＤ列は部屋ＩＤを記憶する。間取り内訳列は部屋の間取りの詳細を記憶する。図５は間取り２ＤＫの詳細例を示す。ＤＫ６．４は、ダイニングキッチンは６．４帖の広さであること示す。洋室６は、２部屋のうち一部屋は６帖の洋室であることを示す。和室７はもう一部屋は７帖の和室であることを示す。玄関列は玄関の設備を記憶する。玄関列は、広さ列、オートロック列、ＴＶ付列、及び下駄箱列を含む。広さ列は玄関の広さを記憶する。オートロック列は共用の建物玄関がオートロックであるか否かを記憶する。建物玄関がオートロックである場合、オートロック列はありを記憶する。建物玄関がオートロックでない場合、オートロック列はなしを記憶する。ＴＶ付列は部屋の玄関にテレビモニタ付きインターホンがついているか否かを記憶する。テレビモニタ付きインターホンがついている場合、ＴＶ付列はありを、テレビモニタ付きインターホンがついていない場合ＴＶ付列はなしを記憶する。下駄箱列は玄関に下駄箱が備え付けられているか否かを記憶する。下駄箱が備え付けられている場合、下駄箱列はありを、下駄箱が備え付けられていない場合、下駄箱列はなしを記憶する。水回り列は水回りの設備について記憶する。水回り列は、ガス列、洗濯パン列、追い焚き列、サーモ水栓列、シャワートイレ列、浴室乾燥機列、キッチン給湯列、及びＢＴ列を含む。ガス列は部屋に供給されているガスについて記憶する。都市ガスが供給されている場合、ガス列は都市ガスを記憶する。プロパンガスが供給されている場合、ガス列はプロパンガスを記憶する。洗濯パン列は洗濯パンの大きさを記憶する。例えば、洗濯パンの大きさが幅６４０ｍｍ×奥行６４０ｍｍである場合、洗濯パン列は６４０を記憶する。洗濯パンの大きさが幅７４０ｍｍ×奥行６４０ｍｍの場合、洗濯パン列は７４０を記憶する。洗濯パンの大きさが幅８００ｍｍ×奥行６４０ｍｍの場合、洗濯パン列は８００サイズを記憶する。追い焚き列は風呂釜に追い焚き機能がある否かを記憶する。追い焚き機能がある場合、追い焚き列はありを記憶する。追い焚き機能がない場合、追い焚き列はなしを記憶する。サーモ水栓列は浴室の水栓がサーモスタット式水栓であるか否かを記憶する。浴室の水栓がサーモスタット式水栓である場合、サーモ水栓列はありを記憶する。浴室の水栓がサーモスタット式水栓でない場合、サーモ水栓列はなしを記憶する。サーモスタット式水栓は、お湯と水とを混合して出すもので、温調ハンドルで温度を設定すれば、サーモスタットカートリッジの働きで湯水の混合量を自動調節するものである。それにより、お湯が熱くなったり冷たくなったりすることなく、安定した温度のお湯を出すことが可能となるものである。シャワートイレ列はトイレにシャワートイレ機能がついているか否かを記憶する。シャワートイレ機能がついている場合、シャワートイレ列はありを記憶する。シャワートイレ機能がついていない場合、シャワートイレ列はなしを記憶する。浴室乾燥機列は、浴室に衣類乾燥機が備え付けられているか否かを記憶する。衣類乾燥機が備え付けられている場合、浴室乾燥機列はありを記憶する。衣類乾燥機が備え付けられていない場合、浴室乾燥機列はなしを記憶する。キッチン給湯列はキッチンでお湯が出るか否かを記憶する。キッチンでお湯が出る場合、キッチン給湯列はありを記憶する。キッチンでお湯が出ない場合、キッチン給湯列はなしを記憶する。ＢＴ列は浴室とトイレとが別室か否かを記憶する。浴室とトイレとが別の部屋となっている場合、ＢＴ列は別を記憶する。浴室とトイレとが一体化した３点式ユニットバスの場合、ＢＴ列は一体を記憶する。

【0019】

図６は付加情報ＤＢの例を示す説明図である。付加情報ＤＢ１３４は部屋に関する付加情報を記憶する。集合住宅の場合、付加情報には建物に関するものも含む。付加情報ＤＢ１３４は部屋ＩＤ列、ＥＬ列、ペット列、楽器列、ネット列、収納列、室外倉庫列、駐車場列、及び駐輪場列を含む。部屋ＩＤ列は部屋ＩＤを記憶する。ＥＬ列は集合住宅の場合にエレベータがあるか否かを記憶する。エレベータがある場合、ＥＬ列はありを記憶する。エレベータがない場合、ＥＬ列はなしを記憶する。ペット列は犬や猫などのペットを飼ってよいか否かを記憶する。ペットを飼ってよい場合、ペット列は可を記憶する。ペットを飼うことが禁止されている場合、ペット列は不可を記憶する。楽器列は部屋で楽器演奏が許可されているか否かを記憶する。部屋で楽器演奏が許可されている場合、楽器列は可を記憶する。部屋で楽器演奏が許可されていない場合、楽器列は不可を記憶する。ネット列はインターネット回線が引かれているか否かを記憶する。インターネット回線が引かれている場合、ネット列はありを記憶する。インターネット回線が引かれている場合で利用量が別途発生しない場合、ネット列は無料を記憶する。インターネット回線が引かれていない場合、ネット列はなしを記憶する。収納列は押入れやクローゼットなどの収納スペースの数を記憶する。収納が全く無い場合、収納列は０又はなしを記憶する。室外倉庫列は入居者が利用できる室外倉庫があるか否かを記憶する。室外倉庫がある場合、室外倉庫列はありを記憶する。室外倉庫がない場合、室外倉庫列はなしを記憶する。駐車場列は駐車場を同時に借りる場合の条件を記憶する。例えば、月極の料金が３０００円の場合、駐車場列は３０００円（１台）を記憶する。家賃に２台分の駐車料金が含まれている場合、駐車場列は２台込みを記憶する。駐輪場列は駐輪場の有無等を記憶する。家賃に利用料が含まれている場合、駐輪場列は込みを記憶する。駐輪場の利用料が月極２５０円の場合、駐輪場列は２５０円を記憶する。駐輪場がない場合、駐輪場列はなしを記憶する。

【0020】

図７は契約条件ＤＢの例を示す説明図である。契約条件ＤＢ１３５は入居契約の主な条件（契約条件）を記憶する。契約条件ＤＢ１３５は部屋ＩＤ列、フリーレント列、即入居列、敷金列、礼金列、及び保証人列を含む。部屋ＩＤ列は部屋ＩＤを記憶する。フリーレント列は家賃が一定期間無料となるフリーレントが含まれているか否かを記憶する。フリーレントが含まれている場合、フリーレント列はフリーレントの期間を記憶する。即入居列は即入居か否かを記憶する。即入居が可能な場合、即入居列は可を記憶する。即入居は出来ない場合、即入居列は不可を記憶する。敷金列は入居時に支払う敷金を記憶する。例えば、敷金が家賃１ヶ月分の場合、敷金列は１ヶ月を記憶する。敷金が家賃単位でない場合、敷金列は具体的な金額を記憶する。礼金列は入居時に支払う礼金を記憶する。礼金列が記憶する内容は敷金列と同様である。保証人列は契約時に連帯保証人を立てる必要がある否かを記憶する。連帯保証人を立てる必要がある場合、保証人列は必要を記憶する。連帯保証人を立てる必要がない場合、保証人列は不要を記憶する。

【0021】

図８は周辺ＤＢの例を示す説明図である。周辺ＤＢ１３６は物件周辺の施設等の情報（環境情報）を記憶する。周辺ＤＢ１３６は物件ＩＤ列、コンビニ列、幹線道路列、駅列、病院列、及びスーパー列を含む。物件ＩＤ列は物件ＩＤを記憶する。コンビニ列は物件の最寄りにあるコンビニエンスストア（以下、コンビニと略記する。）の情報を記憶する。コンビニ列は距離列、及び店舗列を含む。距離列は物件から最寄りにあるコンビニまでの距離を記憶する。店舗列はコンビニチェーンの名称と店舗ＩＤとを記憶する。幹線道路列は物件の最寄りにある幹線道路の情報を記憶する。幹線道路列は距離列、及び道路名列を含む。距離列は物件から最寄りにある幹線道路までの距離を記憶する。道路名列は幹線道路の名称を記憶する。駅列は物件の最寄りにある駅の情報を記憶する。駅列は距離列、及び駅名列を含む。距離列は物件から最寄り駅までの距離を記憶する。駅名列は路線名と駅名とを記憶する。病院列は物件の最寄りにある病院の情報を記憶する。病院列は距離列、及び名称列を含む。距離列は物件から最寄りの病院までの距離を記憶する。名称列は病院名を記憶する。スーパー列は物件の最寄りにスーパーについての情報を記憶する。スーパー列は距離列、及び店舗列を含む。距離列は物件から最寄りのスーパーまでの距離を記憶する。店舗列は、スーパーの名称と店舗ＩＤとを記憶する。上記距離列に記憶する距離は直線距離ではなく路程であることが望ましい。距離列に路程と直線距離との両方を記憶してもよい。コンビニ等が最寄りにあるか否かの判定は、閾値を決めて行う。徒歩での所要時間で判定する場合には、例えば歩く速度を８０ｍ/分として、距離から所要時間を計算し判定する。また、車での所要時間で、最寄りにコンビニ等の施設があるか否かを判定してもよい。車の場合の速度は例えば、４００ｍ/分とする。判定の閾値は既定値を定めておく。例えば、徒歩の所要時間が１０分以内を徒歩圏内とする。

【0022】

図９は特記ＤＢの例を示す説明図である。特記ＤＢ１３７は物件に関して、不動産業者が特に記憶しておくべきと考える事項（特記事項）を記憶する。特記ＤＢ１３７は部屋ＩＤ列、自社管理列、リフォーム列、長期空室列、初期費用減額列、及び客層列を含む。部屋ＩＤ列は部屋ＩＤを記憶する。自社管理列は不動産業者が保有している物件か否かを記憶する。不動産業者が保有している部屋（自社保有物件）の場合、自社管理列は○を記憶する。不動産業者が保有していないが管理委託を受けている部屋の場合（自社管理物件）、自社管理列は△を記憶する。不動産業者が仲介のみをしている部屋（不動産業者が管理委託も受けておらず、保有もしていない物件）の場合、自社管理列は×を記憶する。リフォーム列は部屋をリフォームしたか否かを記憶する。部屋をリフォームした場合、リフォーム列は○又は該当を記憶する。部屋をリフォームしていない場合、リフォーム列は×又は非該当を記憶する。長期空室列は長期間空室であるか否かを記憶する。部屋が長期間空室である場合、長期空室列は○又は該当を記憶する。部屋が長期間空室ではない場合、長期間空室列は×又は非該当を記憶する。長期間空室である否かの判断基準は不動産業者が適宜、定める。初期費用減額列は、部屋が初期費用減額対象であるか否かを記憶する。部屋が初期費用減額対象である場合、初期費用減額列は○又は該当を記憶する。部屋が初期費用減額対象ではない場合、初期費用減額列は×又は非該当を記憶する。初期費用減額とは、例えば、月々の家賃を少し、例えば１５００円程度、上乗せすることにより、入居時に支払う敷金、礼金、鍵交換代、及び仲介手数料、並びに退去時に支払うハウスクリーニング代を不要とするものである。客層列は部屋に適した客層、又は部屋のオーナが望む客層を記憶する。なお、心理的瑕疵物件の情報を特記ＤＢ１３７に記憶してもよい。

【0023】

図１０は施設ＤＢの例を示す説明図である。施設ＤＢ１３８は、上述した周辺ＤＢ１３６に記憶している施設の詳細情報（施設情報）を記憶する。施設ＤＢ１３８は、番号列、種別列、チェーン名列、店番列、店名列、営業時間列、定休日列、及びポイント列を含む。番号列は主キーとなる順番号を記憶する。番号はレコードを追加する際に発行する。種別列は施設の種別を記憶する。例えば、種別は、コンビニ、スーパー、ドラックストア、ファミレス（ファミリーレストランを意味する）、ファストフード等である。チェーン名列は施設がチェーンストアの店舗や複数店舗を展開している企業の店舗の場合、チェーン名や共通の店舗名を記憶する。店番列は同一チェーンにおいて各店舗を特定可能な番号を記憶する。店名列は各店舗の固有名称を記憶する。営業時間列は店舗の営業時間を記憶する。定休日列は店舗の定休日を記憶する。コンビニの場合、営業時間列は２４Ｈを記憶し、定休日列は無休を記憶する。ポイント列は店舗で利用できるポイントの名称を記憶する。なお、施設ＤＢ１３８に店舗で利用可能な電子マネーの情報を記憶してもよい。

【0024】

図１１は回答ＤＢの例を示す説明図である。回答ＤＢ１３９は不動産業者が用意したアンケートに対して、見込み顧客が回答した内容（回答情報）を記憶する。アンケートの回答は用紙に記入されたものを営業員が営業端末２を用いて入力してもよいし、見込み顧客がユーザ端末３を用いて入力してもよい。回答ＤＢ１３９は、ケースＩＤ列、賃料下限列、賃料上限列、エリア列、間取り列、最寄駅列、学区列、オートロック列、ＴＶ付列、ＢＴ別列、ペット可列、楽器可列、ネット無料列、及び倉庫付き列を含む。ケースＩＤ列はケースを一意に特定可能なケースＩＤ列を記憶する。ケースＩＤは新たなレコードを追加するときに発行する。賃料下限列は見込み顧客が希望する家賃の下限を記憶する。下限金額は５千円毎の金額帯に分け、金額帯毎に数値を付す。例えば、０:下限なし、１:２万円以上、２:２．５万円以上、３：３万円以上、…、１３：８万円以上とする。図１１では３となっているから、括弧付き表示したように３万円以上が顧客の希望である。賃料上限列は見込み顧客が希望する家賃の上限を記憶する。下限と同様に金額帯毎に数値を付す。例えば、１：２万円以下、２：２．５万円以下、…、１３：８万円以下、１４：上限なしとする。図１１では７となっているから、括弧付き表示したように５万円以下が顧客の希望である。エリア列はエリアに対する顧客の希望を記憶する。エリアは不動産業者が適宜定める。図１１では６つのエリアに分けた例である。○は希望するエリアを示す。×は希望しないエリアを示す。△は他の条件によっては許容するエリアを示す。間取り列は希望する間取りを記憶する。間取りをグループ分けし、グループ毎に数値を付す。例えば、１:１Ｒ・１Ｋ・１ＤＫ、２:１ＬＤＫ、３:２Ｋ・２ＤＫ、４:２ＬＤＫ、５:３ＤＫ・３ＬＤＫ、６：４ＤＫ以上、７:その他とする。図１１に示す例では４であるので、２ＬＤＫを見込み顧客は希望していることを示す。最寄駅列は希望する最寄駅を記憶する。図１１では駅名を記憶しているが、駅名ではなく駅を特定する番号、記号等でもよい。学区列は小学校区、中学校区を記憶する。小学校区、中学校区それぞれは、例えば該当する小学校名、中学校名を記憶する。オートロック列は希望する物件が集合住宅の部屋である場合に、共用玄関がオートロック付きであることを希望しているか否かを示す。オートロック付きを希望している場合、オートロック列は○を記憶する。オートロック付きが望ましい場合、オートロック列は△を記憶する。オートロック付きを特に希望していない場合、オートロック列は×を記憶する。ＴＶ付列はテレビモニタ付きインターホンが備え付けられていることを希望するか否かを記憶する。ＴＶ付列が記憶する内容は、オートロック列と同様である。ＢＴ別列は浴室とトイレとが別の部屋となっていることを希望しているか否かを記憶する。ＢＴ別列が記憶する内容は、オートロック列と同様である。ペット可列は犬や猫などのペットを飼うことが許可されている物件を希望するか否かを記憶する。ペットを飼うことが許可されている物件を希望する場合、ペット可列は○を記憶する。ペットを飼うことが許可されている否かについて、特に希望していない場合、ペット可列は△を記憶する。ペットを飼うことが許可されていない物件を希望する場合、ペット可列は×を記憶する。楽器可列は部屋で楽器演奏が許可されている物件を希望するか否かを記憶する。楽器可列が記憶する内容は、ペット可列と同様である。ネット無料列は、インターネット回線が引かれ、かつ利用量が別途発生しない物件を希望するか否かを記憶する。ネット無料列が記憶する内容は、オートロック列と同様である。倉庫付き列は、入居者が利用できる室外倉庫がある物件を希望するか否かを記憶する。倉庫付き列が記憶する内容は、オートロック列と同様である。なお、上述のケースは、不動産物件を探している見込み顧客が不動産業者を訪れ、アンケートに回答した際に開始する。又は見込み顧客が不動産業者のＷｅｂページにアクセスし、アンケート画面においてアンケートに回答し、回答を送信した際に開始する。ケースが終了するのは、見込み顧客が申込みをした場合、見込み顧客が他の不動産業者と契約したなど引き合いがなくなった場合などである。

【0025】

図１２は見込み顧客ＤＢの例を示す説明図である。見込み顧客ＤＢ１３Ａは見込み顧客についての情報（個人情報）を記憶する。見込み顧客ＤＢ１３Ａは、見込み顧客ＩＤ列、氏名列、ふりがな列、年齢列、性別列、職業区分列、メール列、電話列、ＦＡＸ列、郵便番号列、住所列、連絡方法列、学部列、契約予定者列、顧客区分列、入居人数列、家族形態列、外国籍列及び日本語列を含む。見込み顧客ＩＤ列は見込み顧客を一意に特定可能な見込み顧客ＩＤを記憶する。見込み顧客ＩＤは新たなレコードを追加する際に発行する。氏名列は見込み顧客の氏名を記憶する。ふりがな列は氏名のふりがなを記憶する。年齢列は見込み顧客の年齢を記憶する。性別列は見込み顧客の性別を記憶する。職業区分列は見込み顧客の職業区分を記憶する。職業区分は例えば、正社員、アルバイト・パート、学生、その他である。メール列は見込み顧客の連絡先電子メールアドレスを記憶する。電話列は見込み顧客の連絡先電話番号を記憶する。ＦＡＸ列は見込み顧客の連絡先ファクシミリ番号を記憶する。郵便番号列は見込み顧客の現住所の郵便番号を記憶する。住所列は見込み顧客の現住所を記憶する。連絡方法列は見込み顧客が希望する連絡方法を記憶する。連絡方法列は例えば、電話、電子メール、ＦＡＸを記憶する。連絡方法列は優先順位を付した複数の連絡方法を記憶してもよい。学部列は見込み顧客が大学生である場合に所属の学部を記憶する。契約予定者列は契約を結ぶのが見込みは顧客以外となる場合に、契約予定者の情報を記憶する。例えば見込み顧客が大学生で、契約者がその保護者の場合である。契約予定者列は職業列及び年収列を含む。職業列は契約予定者の職業を記憶する。年収列は契約予定者の直近の年収を記憶する。顧客区分は顧客の区分を記憶する。法人が契約者となる場合、顧客区分は「法人」を記憶する。入居者が学生である場合、顧客区分は「学生」を記憶する。社会人が契約し入居する場合は「一般」を記憶する。入居人数列は入居予定の人数を記憶する。家族形態列は入居する予定の家族形態を記憶する。家族形態列は世帯列、子供列、及び乳幼児列を含む。世帯列は世帯形態を記憶する。世帯形態とは、単身世帯、夫婦のみ世帯、夫婦+子供世帯等である。子供列は子供の人数を記憶する。乳幼児列は子供の中に乳幼児を含むか否かを記憶する。乳幼児を含む場合、乳幼児列は○、該当又は１などを記憶する。乳幼児を含まない場合、乳幼児列は×、非該当又は０などを記憶する。外国籍列は見込み顧客が外国籍であるか否かを記憶する。見込み顧客が外国籍である場合、外国籍列は１や○を記憶する。見込み顧客が日本籍である場合、外国籍列は０や×を記憶するか、値を記憶しない。外国籍列に国籍を有する国を記憶してもよい。例えば、見込み顧客が中国国籍を有していれば、外国籍列には中国を示すＣＮを記憶する。日本語列は見込み顧客が日本語でのコミュニケーション能力を記憶する。例えば、コミュニケーション能力の程度に応じて、３段階（○、△、×）に分類する。さらに、見込み顧客ＤＢ１３Ａに見込み顧客の信心する宗教や信条、民族や人種を記憶してもよい。しかしこれらの情報は機微情報であるため、取り扱いに注意が必要である。見込み顧客についての情報は、以下、顧客情報とも言う。

【0026】

図１３は履歴ＤＢの例を示す説明図である。履歴ＤＢ１３Ｂは見込み顧客に対する活動を記憶する。履歴ＤＢ１３Ｂは、ケースＩＤ列、見込み顧客ＩＤ列、参照物件列、内覧物件列、状況列、結果列を含む。ケースＩＤ列はケースＩＤを記憶する。見込み顧客ＩＤ列は見込み顧客ＩＤを記憶する。参照物件列は見込み顧客が参照した部屋の部屋ＩＤを記憶する。営業員が店頭で見込み顧客へ提示した物件シートに掲載した部屋の部屋ＩＤを記憶する。また、不動産業者が提供する物件紹介のＷｅｂページを見込み顧客が参照した履歴から参照した部屋の部屋ＩＤを取得し、記憶してもよい。内覧物件列は見込み顧客が内覧した部屋の部屋ＩＤを記憶する。内覧物件列は内覧１列、内覧２列、内覧３列、及びその他列を含む。多くの場合、営業員は内覧する物件を３件提示するので、内覧１列、内覧２列、及び内覧３列に、３件の部屋ＩＤを記憶する。３件を超えて内覧した場合、残りの部屋ＩＤはその他列に記憶する。内覧とは、不動産物件を実地に見学・調査することをいい、内見ともいう。状況列はケースの状況を記憶する。例えば状況は仕掛中、内覧済、追客、終了、失注である。仕掛中は内覧の前段階を示す。内覧済は内覧したものの申込みには至っていない状況を示す。追客は内覧したものの申込みには至っていない見込み顧客に対して、電話やメールで連絡を入れた後の段階である。終了は申込みに至ったことを示す。失注は申込みには至らないことが確定したことを示す。結果列は終了したケースについての状況又は結果を記憶する。結果列は契約列、部屋ＩＤ列、及び契約家賃列を含む。契約列は契約の状況を示す。例えば状況は審査中、入金待ち、成約である。審査中は入居審査を行っていることを示す。入金待ちは、顧客が敷金、礼金、初回家賃等を入金するのを待っている状況を示す。成約は契約の締結が完了したことを示す。部屋ＩＤ列は申込み又は成約された部屋の部屋ＩＤを記憶する。契約家賃列は契約した家賃を記憶する。

【0027】

図１４は追加情報ＤＢの例を示す説明図である。追加情報ＤＢ１３Ｃは、営業員が得た見込み顧客に関する追加情報を記憶する。追加情報ＤＢ１３Ｃは、ケースＩＤ列、現住居構造列、勤務時間列、自炊列、所有物列、休日列、及び入浴時間列を示す。ケースＩＤ列はケースＩＤを記憶する。現住居構造列は見込み顧客が現在住んでいる住居の構造を記憶する。勤務時間列は見込み顧客が勤務している時間を記憶する。勤務時間列は開始列及び終了列を含む。開始列は勤務開始時刻を記憶する。終了列は勤務終了時刻を記憶する。見込み顧客が学生等の場合は、学校等に居る時間帯を記憶する。自炊列は自炊をするか否か、自炊をする場合は、自炊する曜日、時間帯等を記憶する。所有物列は、部屋を選定する際に考慮が必要なものを見込み顧客が所有している場合、当該所有物を記憶する。例えば、所有物列はドラム式洗濯機を記憶する。休日列は見込み顧客の休日を記憶する。見込み顧客が働いていない場合、休日列は空文字列又は空白等を記憶する。入浴時間列は見込み顧客が入浴する時間を記憶する。以上のように、追加情報ＤＢ１３Ｃに記憶する情報は、部屋の選定条件とは関係の薄い情報も含むが、見込み顧客の生活スタイル等を営業員が把握するために得た追加情報を記憶する。

【0028】

図１５は部屋選定モデルの生成処理に関する説明図である。図１５では、機械学習を行って部屋選定モデル１４１を生成する処理を概念的に図示している。図１５に基づき、部屋選定モデル１４１の生成処理について説明する。

【0029】

提供サーバ１は、部屋選定モデル１４１として、過去の成約情報に基づき、成約した部屋に関する情報（成約物件情報）と、成約した顧客に関する情報（個人情報）と、回答情報とを教師データとして、ディープラーニングを行う。成約物件情報は、物件ＤＢ１３１に記憶してある物件建物情報、部屋基本ＤＢ１３２に記憶してある部屋基本情報、及び基本設備ＤＢ１３３に記憶してある基本設備情報を含む。付加情報ＤＢ１３４に記憶してある付加情報、契約条件ＤＢ１３５に記憶してある契約条件、周辺ＤＢ１３６に記憶してある周辺情報、特記ＤＢ１３７に記憶してある特記事項、施設ＤＢに記憶してある施設情報（但し、周辺情報に含まれる施設に関するものに限る）を成約物件情報に含めてもよい。個人情報は、見込み顧客ＤＢ１３Ａに記憶した顧客情報を含む。個人情報に、追加情報ＤＢ１３Ｃが記憶している追加情報を含めてもよい。学習により、顧客に関する情報を入力とし、顧客に適する部屋に関する情報を出力とするニューラルネットワークを生成する。

【0030】

ニューラルネットワークは例えばＣＮＮ（Convolution Neural Network）であり、部屋に関する情報と顧客に関する情報との入力を受け付ける入力層と、顧客に適する部屋に関する情報を出力する出力層と、部屋に関する情報と顧客に関する情報とを関係付ける中間層とを有する。

【0031】

入力層は、顧客に関する情報に含まれる複数のデータ項目の値を入力として受け付ける複数のニューロンを有し、入力された項目値を中間層に受け渡す。例えば部屋選定モデル１４１がＣＮＮである場合、中間層は、入力層から入力された各データ項目の値を畳み込むコンボリューション層と、コンボリューション層で畳み込んだ値をマッピングするプーリング層とが交互に連結された構成を有し、入力された情報を圧縮しながら最終的に特徴量を抽出する。出力層は顧客に適する部屋についての各項目の値を出力する複数のニューロンを有し、中間層から出力された特徴量に基づいて顧客に適する部屋についての項目値を出力する。

【0032】

なお、本実施の形態では部屋選定モデル１４１がＣＮＮであるものとして説明するが、部屋選定モデル１４１はＣＮＮに限定されず、ＣＮＮ以外のニューラルネットワーク、ベイジアンネットワーク、決定木など、他の学習アルゴリズムで構築された学習済みモデルであってよい。

【0033】

提供サーバ１は教師データを用いて学習を行う。教師データは、成約物件情報と、顧客情報と、回答情報とが対応付けられたデータ（成約履歴）である。教師データは履歴ＤＢ１３Ｂに記憶してある成約に至った履歴データを基づいて作成する。

【0034】

提供サーバ１は、教師データに含む顧客情報と回答情報とを入力層に入力し、中間層での演算処理を経て、出力層から顧客に適した部屋に関する情報を取得する。部屋に関する情報は複数のデータ項目を含むから、各データ項目についての値が組み合わされた値の集合を各出力ノードから取得する。各集合には確率値が付されている。当該確率値は、入力データに対して出力された部屋の情報の確からしさを示す。確率値の合計は１である。出力層から出力される値の集合の各要素は離散的な値（例えば、部屋の間取りは、１Ｋ、１ＤＫ、２ＤＫ、２ＬＤＫ、…）であってもよく、連続的な値（例えば、家賃は０円から２０万円までの範囲の値）であってもよい。出力される部屋に関する情報は、物件建物情報、部屋基本情報、及び基本設備情報に相当するものである。

【0035】

提供サーバ１は、出力層から出力された部屋に関する情報を、教師データに含む成約物件情報、すなわち正解値と比較し、出力層からの出力値が正解値に近づくように、中間層での演算処理に用いるパラメータを最適化する。当該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最適化の方法は特に限定されないが、例えば提供サーバ１は誤差逆伝播法を用いて各種パラメータの最適化を行う。

【0036】

提供サーバ１は、全ての教師データを用いて上記の学習処理を行い、学習済みの部屋選定モデル１４１を生成する。提供システム１００構築時の部屋選定モデル１４１は、学習処理を経て、学習済みの部屋選定モデル１４１となる。なお、部屋選定モデル１４１の出力層は図１５に示したもの限らない。例えば、出力層のノード毎に異なる項目の情報を出力してもよい。ある出力ノードは間取りを出力し、ある出力ノードは家賃を出力する。各出力ノードは値と確率とが組になったデータを各複数出力してもよい。間取りであれば、（２ＬＤＫ，０．８５）、（２ＤＫ，０．０９）、（３Ｋ，０．０６）などの出力となる。教師データに含まれる正解の間取りが２ＬＤＫであれば、２ＬＤＫの確率が大きくなるように学習を行う。

【0037】

営業員が提供システム１００を用いて、見込み顧客に対して提案する部屋を決定する業務について説明する。営業員は来店した見込み顧客から、氏名、住所、職業等の顧客情報を取得する。営業員は営業端末２を用いて、顧客情報を見込み顧客ＤＢ１３Ａに登録する。また、見込み顧客に対して、アンケートへの回答を依頼し、回答情報を取得する。営業員は営業端末２を用いて、回答情報を回答ＤＢ１３９に登録する。なお、タブレット端末等を用意しておき、顧客情報及び回答情報を顧客が自ら入力可能としてもよい。営業員は営業端末２を介して、顧客情報及び回答情報を指定し、提供サーバ１へ提案すべき部屋の選定を依頼する。営業端末２から依頼を受け付けたことを契機として、提供サーバ１は部屋選定処理を行う。

【0038】

図１６は部屋選定処理に関する説明図である。図１６では処理の内容を概略的に記載している。提供サーバ１は、指定された顧客情報を見込み顧客ＤＢ１３Ａから、指定された回答情報を回答ＤＢ１３９から取得する。提供サーバ１は取得した顧客情報と回答情報とを入力データとして、部屋選定モデル１４１に入力する。部屋選定モデル１４１は出力として、提案すべき部屋に関する情報（提案部屋情報、物件情報）を出力する。提案部屋情報は、物件建物情報、部屋基本情報、基本設備情報を含む。提供サーバ１は、部屋選定モデル１４１より出力された提案部屋情報と、物件ＤＢ１３１に記憶してある物件建物情報、部屋基本ＤＢ１３２に記憶してある部屋基本情報、及び基本設備ＤＢ１３３に記憶してある基本設備情報とを参照し、提案部屋情報に最も類似する部屋を特定する。特定した部屋が入居不可の場合は、次点の部屋とする。提供サーバ１は特定した部屋の部屋ＩＤを用いて、部屋基本ＤＢ１３２から部屋基本情報（物件情報）を取得する。提供サーバ１は部屋ＩＤ、部屋基本情報、及び類似度を営業端末２へ送信する。ここでの類似度はベクトルの類似度と同様な手法で求めることが可能である。例えば、コサイン類似度、ピアソンの相関係数、又は偏差パターン類似度を類似度として用いる。類似度の算出は公知であるので、説明を省略する。

【0039】

営業端末２に表示された部屋選定結果に基づき、見込み顧客に対して提案を行う。提案の結果、成約となった場合、当該新たな成約の情報（成約履歴）は、部屋選定モデル１４１を再学習させるための教師データとなる。部屋選定モデル１４１の再学習は、新たな成約が出る度に行ってもよいし、バッチ処理にして所定の期間ごとに行ってもよいし、ある程度数の成約履歴が蓄積されてからでもよい。

【0040】

次に部屋選定モデル１４１の生成処理について、フローチャートを用いて再度説明する。図１７は部屋選定モデル生成処理の手順例を示すフローチャートである。提供サーバ１の制御部１１は履歴ＤＢ１３Ｂから成約履歴を取得する（ステップＳ１）。制御部１１は成約履歴に含まれる部屋ＩＤを用いて、成約物件情報（物件建物情報、部屋基本情報、基本設備情報）を取得する（ステップＳ２）。制御部１１は成約履歴に含まれる見込み顧客ＩＤを用いて、顧客情報を取得する（ステップＳ３）。制御部１１は成約履歴に含まれるケースＩＤを用いて、回答情報を取得する（ステップＳ４）。制御部１１は、成約物件情報、顧客情報、及び回答情報を含む教師データを生成する（ステップＳ５）。制御部１１は教師データを用いて、顧客情報及び回答情報を入力した場合に提案部屋情報を出力する部屋選定モデル１４１（学習済みモデル）を生成する（ステップＳ６）。具体的には、制御部１１は、教師データに含む顧客情報及び回答情報をニューラルネットワークの入力層に入力し、提案部屋情報を出力層から取得する。制御部１１は、取得した提案部屋情報を教師データの正解値（成約物件情報）と比較し、出力層から出力される情報が正解値に近づくよう、中間層での演算処理に用いるパラメータ（重み等）を最適化する。制御部１１は、生成した部屋選定モデル１４１を補助記憶部１３に格納する。部屋選定モデル１４１の初期構築の段階では、ステップＳ１で取得した成約履歴毎にステップＳ２からステップＳ６を繰り返し、一連の処理を終了する。

【0041】

続いて、部屋選定処理について、フローチャートを用いて再度説明する。図１８は部屋選定処理の手順例を示すフローチャートである。営業端末２は顧客情報を取得する（ステップＳ１１）。営業端末２は回答情報を取得する（ステップＳ１２）。営業端末２は顧客情報及び回答情報を提供サーバ１へ送信する（ステップＳ１３）。営業端末２は顧客情報と回答情報とを取得次第、個々に提供サーバ１へ送信してもよい。提供サーバ１の制御部１１は顧客情報及び回答情報を受信し、顧客情報を見込み顧客ＤＢ１３Ａに、回答情報を回答ＤＢ１３９に記憶する（ステップＳ１４）。制御部１１は、顧客情報及び回答情報を部屋選定モデル１４１に入力し、部屋選定モデル１４１が出力した提案部屋情報を取得する（ステップＳ１５）。制御部１１は、提案部屋情報と物件ＤＢ１３１に記憶してある物件建物情報、部屋基本ＤＢ１３２に記憶してある部屋基本情報、及び基本設備ＤＢ１３３に記憶してある基本設備情報とを参照し、提案部屋情報と各部屋情報との類似度を算出する（ステップＳ１６）。制御部１１は提案部屋情報に最も類似する部屋を特定する（ステップＳ１７）。制御部１１は特定した部屋についての部屋基本情報を営業端末２へ送信する（ステップＳ１８）。営業端末２は部屋基本情報を受信し、表示する（ステップＳ１９）。

【0042】

なお、ステップＳ１７で特定した部屋が入居不可の場合は、次点の部屋とする。また、特定した部屋が他の不動産業者が管理する部屋である場合、次点以降に、自社が管理する部屋であって、特定した部屋との類似度の差が所定の範囲内であるときは、自社が管理する物件としてもよい。

【0043】

図１９は部屋選定結果表示画面の例を示す説明図である。部屋選定結果表示画面ｄ０１は、見込み顧客名表示ｄ０１１、物件名表示ｄ０１２、部屋情報表示欄ｄ０１３、次ボタンｄ０１４、前ボタンｄ０１５、内覧おすすめボタンｄ０１６を含む。見込み顧客名表示ｄ０１１は見込み顧客の氏名を表示する。物件名表示ｄ０１２は建物の名称等を表示する。部屋情報表示欄ｄ０１３は部屋の情報を表示する。次ボタンｄ０１４は表示している部屋の次順位の部屋へ表示を切り替えるボタンである。前ボタンｄ０１５は、表示している部屋が２位以下の場合、前順位の部屋へ表示を切り替えるボタンである。内覧おすすめボタンｄ０１６は、おすすめの部屋と共に内覧することが適した部屋を表示するためのボタンである。

【0044】

本実施の形態は次の効果を奏する。成約履歴で学習した部屋選定モデル１４１を用いて、顧客へ提案すべき部屋を決定するので、業務経験の浅い営業員であっても、熟練の営業員と同様に顧客に適した部屋を提案可能となる。

【0045】

類似度を算出する場合に、各データ項目に重み付けをしてもよい。例えば、顧客にアンケートで特に重視したい事項を回答して貰う。顧客が指定した項目については、重みを大きくして類似度を算出する。また、提案部屋情報は複数であってもよく、類似度にしたがった順位付けして、営業端末２に表示するようにしてもよい。

【0046】

部屋選定処理において部屋選定モデル１４１に入力する個人情報は、顧客情報及び回答情報としたが、それに限らない。入力する個人情報に、追加情報ＤＢ１３Ｃが記憶している追加情報を含めてもよい。この場合、部屋選定モデル１４１を生成する際に、教師データに追加情報を含め、部屋選定モデル１４１への入力データの１つとする。

【0047】

また、部屋選定モデル１４１に出力する提案部屋情報は物件建物情報、部屋基本情報、及び基本設備情報を含むとしたが、それに限らない。提案部屋情報として、付加情報、契約条件、周辺情報、特記事項、施設情報を含めてもよい。この場合、部屋を選定するために類似度を算出する際には、提案部屋情報に含む付加情報、契約条件、周辺情報、特記事項、施設情報それぞれを、付加情報ＤＢ１３４に記憶してある付加情報、契約条件ＤＢ１３５に記憶してある契約条件、周辺ＤＢ１３６に記憶してある周辺情報、特記ＤＢ１３７に記憶してある特記事項、施設ＤＢ１３８に記憶してある施設情報（但し、周辺情報に含まれる施設に関するものに限る）と対照する。さらに、部屋選定モデル１４１を生成する際の用いる成約物件情報に付加情報、契約条件、周辺情報、特記事項、及び施設情報を含める。

【0048】

部屋選定モデル１４１への入力データの種類、出力するデータの種類を増やすことにより、部屋選定処理より選定される部屋は見込み顧客の希望に沿ったものに近づき、成約率の向上が期待できる。

【0049】

顧客情報及び回答情報を営業端末２が取得するとしたがそれに限らない。ユーザ端末３がネットワークＮを介して、顧客情報及び回答情報を提供サーバ１へ送信してもよい。さらに、ユーザ端末３に部屋選定処理の実行を許可してもよい。提供サーバ１は、ユーザ端末３から送信された顧客情報及び回答情報を部屋選定モデル１４１に入力し、部屋選定モデル１４１が出力した提案部屋情報に基づく部屋基本情報をユーザ端末３へ送信する。

【0050】

また、部屋選定モデル１４１は見込み顧客の属性に合わせて複数設けてもよい。医学部生向けの部屋を選定する医学生用部屋選定モデルや、外国籍向けの部屋を選定する外国籍用選定モデルを設けてもよい。

【0051】

（実施の形態２）
本実施の形態は、実施の形態１において、選定された部屋と共に内覧（内見ともいう）の適した部屋を提案する機能をさらに備える。部屋を探している顧客は最も希望に則した部屋を１件のみ紹介されても、契約すべきか否か迷うのが通常である。そのため、不動産業者の営業員は、顧客に最も勧めたい部屋に加えて、さらに２つの部屋を勧めるのが通常である。そして、営業員は３つの部屋を顧客に内覧してもらい、最も勧めたい部屋を選択するように顧客を誘導する。ここで追加する２つの部屋は最も勧めたい部屋と類似しすぎると、却って顧客は迷ってしまうため、最も勧めたい部屋との良さを顧客が感じる部屋がよい。しかし、どのような部屋が最適かについては、従来、営業員に経験に依っていた。本実施の形態は、最も勧めたい部屋と共に内覧すべき部屋の提案を行う機能を有する。以下の説明において、顧客に最も勧めたい部屋を推奨部屋、推奨部屋と共に内覧に適する部屋を内覧部屋という。

【0052】

図２０は、内覧部屋選定処理の手順例を示すフローチャートである。営業員は営業端末２に推奨部屋の部屋ＩＤを入力する。営業員が実施の形態１における部屋選定処理により推奨部屋を決定した場合、営業端末２に表示された推奨部屋を選択すれば、部屋ＩＤの入力は不要である。営業端末２は部屋ＩＤを提供サーバ１へ送信する（ステップＳ３１）。提供サーバ１の制御部１１は、部屋ＩＤを受信する（ステップＳ３２）。制御部１１は、履歴ＤＢ１３Ｂから部屋ＩＤを用いて推奨部屋が契約された成約履歴を取得する（ステップＳ３３）。制御部１１は、取得した成約履歴を分析する（ステップＳ３４）。例えば、アソシエーション分析、又はマーケット・バスケット分析である。当該分析は、商品Ａが売れるときは、商品Ｂが一緒に売れるケースが多いなどのルールを見つけ出す分析手法である。これを応用して、過去の成約履歴において、推奨部屋と共に内覧された回数の多い部屋を求める。制御部１１は推奨部屋と共に内覧された回数の多い部屋の上位２つを内覧部屋として選定する（ステップＳ３５）。制御部１１は選定した内覧部屋に関する部屋基本情報を営業端末２へ送信する（ステップＳ３６）。営業端末２は部屋基本情報を受信し、表示する（ステップＳ３７）。営業端末２は処理を終了する。

【0053】

図２１は、内覧部屋選定結果表示画面の例を示す説明図である。内覧部屋選定結果表示画面ｄ０２は、見込み顧客名表示ｄ０２１、おすすめ物件名表示ｄ０２２、内覧部屋情報表示欄ｄ０２３、決定ボタンｄ０２４、追加ボタンｄ０２５、編集リンクｄ０２６を含む。見込み顧客名表示ｄ０２１は見込み顧客の氏名を表示する。おすすめ物件名表示ｄ０２２は見込み顧客におすすめる部屋を含む建物の名称等を表示する。内覧部屋情報表示欄ｄ０２３は、おすすめする部屋と共に内覧することを推奨する部屋の情報を表示する。決定ボタンｄ０２４は表示している部屋の内覧を決定したことを入力するためのボタンである。決定ボタンｄ０２４を操作することにより、内覧する部屋の組み合わせが、履歴ＤＢ１３Ｂに記憶される。追加ボタンｄ０２５は、内覧する物件を追加する場合に選択する。編集リンクｄ０２６は表示している部屋に操作メニューを表示するハイパーリンクである。編集リンクｄ０２６を表示するプルダウンメニューが表示される。プルダウンメニューは、例えば、詳細参照、削除、入替等を含む。詳細参照は部屋についての詳細情報（見取り図、周辺地図等）を表示するためのメニューである。削除は表示している部屋を内覧する部屋から削除するためのメニューである。入替は表示している部屋を内覧する部屋から削除し、他の部屋を追加するためのメニューである。

【0054】

本実施の形態においては、営業端末が顧客に最も勧めたい部屋と共に内覧すべき部屋の提案を行う。営業員は提案に従って、顧客に内覧を行ってもらうことで、最も勧めたい部屋の成約率を高めることが可能となる。また、営業員の経験の多寡に関わらず、内覧すべき部屋を選定可能となる。

【0055】

成約部屋の選定は、マーケット・バスケット分析を用いるとしたが、当該分析から得られるルールと同様な学習済みモデルで行ってもよい。学習済みモデルは推奨部屋の情報を入力すると、内覧部屋の情報を出力する。学習済みモデルの教師データは、成約履歴から取得した成約した部屋の情報、共に内覧された部屋の情報の組み合わせである。教師データに含む成約した部屋の情報をニューラルネットワークの入力層に入力し、共に内覧すべき部屋の情報を出力層から取得する。取得した共に内覧すべき部屋情報を教師データの正解値（内覧部屋の情報）と比較し、出力層から出力される結果が正解値に近づくよう、中間層での演算処理に用いるパラメータ（重み等）を最適化する。このような学習を行うことにより、ニューラルネットワークから学習済みモデルが生成される。

【0056】

（実施の形態３）
本実施の形態は、決定木を用いて、顧客に対して提案する部屋を決定する形態に関する。決定木は、分類問題と回帰問題を解く教師あり学習のアルゴリズムの一つである。与えられたデータに対して、次々に条件を設けて、データを段階的に分類していく手法である。本実施の形態においては、顧客の属性と、顧客の不動産物件に対する希望条件と、不動産物件の情報とを説明変数とし、成約に至る確率を目的変数とする決定木を生成する。顧客の属性は、例えば年齢、性別、職業、契約主体（個人／法人）、入居人数、保証人の有無等である。希望条件は家賃の範囲、間取り、エリア等である。不動産物件の情報は、例えば家賃、間取り、エリア等である。

【0057】

本実施の形態では、学習段階として過去の見込み顧客に対する活動の情報（以下、「活動情報」ともいう。）に基づき決定木の作成を行い、運用段階では作成した決定木を用いて、顧客に提案する不動産物件を決定する。以下の決定木の作成ではＣＡＲＴ（Classification And Regression Trees）を用いる。まず、履歴ＤＢ１３Ｂに記憶している過去の活動情報に基づく、顧客の属性と不動産物件の情報と営業結果（成約に至った、又は、成約に至らなかった）とを組み合わせた実績データ群を、顧客の属性、顧客の不動産物件に対する希望条件又は不動産物件の情報に含まれる１つの値（特徴量）に応じて、二つの実績データ群に分割する。このとき、分割後の一方の実績データ群には成約に至ったデータが偏り、他方の実績データ群には成約に至らなかったデータが偏るように、特徴量を選択する。分割前に比べて分割後に偏りが大きくなるほど、営業結果に対する特徴量の影響が大きい。まず、実績データ群を、営業結果に対する影響が最大となる特徴量に応じて、二つの実績データ群に分割し、次に、分割後の夫々の実績データ群を同様に分割し、実績データ群の分割を繰り返す。このようにして、実績データを樹木状に分類するモデルである決定木が生成される。

【0058】

営業結果に対する特徴量の影響は、特徴量の値に応じて実績データ群を分割したときの情報利得を計算することにより判定する。実績データ群を第１の分類群と第２の分類群とに分割することとする。分割前の実績データ群に含まれるデータ総数をＮ_０とし、第１の分類群に含まれるデータの数をＮ_１とし、第２の分類群に含まれるデータの数をＮ_２とする。Ｎ_０＝Ｎ_１＋Ｎ_２である。情報利得をＩＧとする。情報利得ＩＧは、下記の式（１）で表される。
ＩＧ＝（分割前の実績データ群の不純度）－｛（Ｎ_１／Ｎ_０）×（第１の分類群の不純度）＋（Ｎ_２／Ｎ_０）×（第２の分類群の不純度）｝…（１）

【0059】

不純度は、実績データ群に含まれるデータの偏りを数値化したものである。具体的には、不純度としてジニ不純度を用いる。実績データ群に含まれるデータの総数をｎ_０とし、成約となったデータの数をｎ_１とし、成約に至らなかったデータの数をｎ_２とする。ｎ_０＝ｎ_１＋ｎ_２である。ジニ不純度をＧｉとする。ジニ不純度Ｇｉは下記の式（２）で表される。
Ｇｉ＝１－｛（ｎ_１／ｎ_０）^２＋（ｎ_２／ｎ_０）^２｝…（２）

【0060】

ジニ不純度は、実績データ群に含まれるデータが成約となったデータ又は成約とならなかったデータの一方に偏る偏りが小さいほど、値が大きくなる。情報利得は、分割前の不純度と、分割後の不純度の加重平均との差を示す。情報利得は、分割前の偏りが小さく、分割後の偏りが大きいほど、値が大きくなる。このため、情報利得が大きいほど、営業結果に対する特徴量の影響が大きい。情報利得が大きくなる特徴量を選択することにより、営業結果に対する影響の大きい特徴量を選択することができる。

【0061】

なお、情報利得の代わりに、情報利得の値にＮ_０を乗じた値であるｉｍｐｒｏｖｅ値を計算してもよい。情報利得と同様に、ｉｍｐｒｏｖｅ値が大きいほど、営業結果に対する特徴量の影響が大きい。ｉｍｐｒｏｖｅ値をＩｍｐとすると、ｉｍｐｒｏｖｅ値Ｉｍｐは下記の（３）式で表される。
Ｉｍｐ＝Ｎ_１×｛（分割前の実績データ群の不純度）－（第１の分類群の不純度）｝＋Ｎ_２×｛（分割前の実績データ群の不純度）－（第２の分類群の不純度）｝…（３）

【0062】

決定木分析に用いるアルゴリズムとしてＣＡＲＴを用いたが、それに限らず、不純度としてエントロピーを用いるＩＤ３（Iterative Dichotomiser 3）、Ｃ４．５、若しくはＣ５．０、又はカイ２乗値を用いるＣＨＡＩＤ（Chi-squared Automatic Interaction Detection）等を用いてもよい。

【0063】

決定木を生成する際に用いる実績データについて、説明する。図２２は実績データＤＢの例を示す説明図である。実績データＤＢ１３Ｄは決定木分析の対象となる実績データを記憶する。実績データＤＢ１３Ｄは例えば、補助記憶部１３に記憶する。実績データを分析することにより、決定木が生成される。実績データＤＢ１３Ｄは、ＩＤ列、枝番列、営業結果列、性別列、年代列、希望間取り列、希望家賃列、希望エリア列、部屋ＩＤ列、契約家賃列、間取り列、エリア列を含む。ＩＤ列は実績データを特定するＩＤを記憶する。枝番列は枝番を記憶する。ＩＤ及び枝番により、実績データは一意に特定可能である。営業結果列は提案した部屋についての契約が成立したか否かを記憶する。契約が成立した場合、営業結果列は「成約」を記憶する。契約が成立しなかった場合、営業結果列は「失注」を記憶する。見込み顧客に部屋を提案する場合、複数の部屋を提案することが通常であるので、成約に至ったケースであっても、実績データは複数作成される。ＩＤが同一の実績データ同士は、同一ケースから作成された実績データであることを示す。ＩＤが同一の実績データのうち、１つの実績データは営業結果が成約であり、その他の実績データは営業結果が失注となる。性別列は見込み顧客の性別を記憶する。年代列は見込み顧客の年齢層を記憶する。見込み顧客の年齢が２０歳から２９歳の間であれば、年代列は「２０代」を記憶する。希望間取り列は見込み顧客が希望した間取りを記憶する。希望家賃列は見込み顧客が希望した家賃を記憶する。希望する家賃の下限、上限を指定した賃料帯を、希望家賃列に記憶してもよい。希望エリア列は見込み顧客が希望したエリアを記憶する。部屋ＩＤ列は見込み顧客へ提案した部屋の部屋ＩＤを記憶する。契約家賃列は部屋の契約家賃を記憶する。間取り列は部屋の間取りを記憶する。エリア列は部屋が位置するエリアを記憶する。

【0064】

実績データにおいて、性別及び年代は見込み顧客（借主）の属性の例である。属性として、見込み顧客ＤＢ１３Ａが記憶する職業、年収、入居人数などを含んでもよい。希望間取り及び希望家賃は希望条件の例である。希望条件として、回答ＤＢ１３９が記憶する最寄駅、学区、オートロック有無の希望などを含んでもよい。契約家賃及び間取りは物件情報の例である。物件情報として、物件ＤＢ１３１が記憶する建物の構造や築年数、基本設備ＤＢ１３３が記憶する玄関や水回りの設備等の情報、周辺ＤＢ１３６が記憶する最寄りのコンビニや最寄りの幹線道路などの周辺環境情報、特記ＤＢ１３７が記憶する特記事項、施設ＤＢ１３８が記憶する施設情報を含んでもよい。

【0065】

次に、決定木を生成する処理について説明する。図２３は決定木生成処理の手順例を示すフローチャートである。提供サーバ１の制御部１１は実績データの作成を行なう（ステップＳ５１）。制御部１１は作成した実績データを用いて、決定木分析を行い（ステップＳ５２）、決定木を生成する。

【0066】

図２４は実績データ作成処理の手順例を示すフローチャートである。図２４に示す処理は図２３のステップＳ５１に対応する。提供サーバ１の制御部１１は履歴ＤＢ１３Ｂから活動情報を取得する（ステップＳ６１）。取得する活動情報は仕掛りのものは除外し、結果が確定しているもの、状況列の値が終了又は失注であるものを取得する。制御部１１は取得した活動情報から処理対象とするものを１つ選択する（ステップＳ６２）。

【0067】

制御部１１は顧客情報を取得する（ステップＳ６３）。制御部１１は、活動情報に含まれる見込み顧客ＩＤをキーにして、見込み顧客ＤＢ１３Ａを検索し、顧客情報を取得する。制御部１１は回答情報を取得する（ステップＳ６４）。制御部１１は、活動情報に含まれるケースＩＤをキーにして、回答ＤＢ１３９を検索し、回答情報を取得する。制御部１１は物件情報を取得する（ステップＳ６５）。制御部１１は、活動情報に含まれる内覧物件列の各列、結果列の部屋ＩＤ列に記憶している部屋ＩＤをキーにして、部屋基本ＤＢ１３２を検索し、部屋基本情報を取得する。制御部１１は、部屋基本情報に含まれる物件ＩＤをキーにして、物件ＤＢ１３１を検索し、物件建物に関する情報を取得する。

【0068】

制御部１１はその他情報を取得する（ステップＳ６６）。制御部１１は、部屋ＩＤをキーにして、基本設備ＤＢ１３３を検索して基本設備情報を、付加情報ＤＢ１３４を検索して部屋に関する付加情報を、契約条件ＤＢ１３５を検索して契約条件を、特記ＤＢ１３７を検索して特記事項を取得する。また、制御部１１は、物件ＩＤをキーにして周辺ＤＢ１３６を検索して環境情報を取得する。さらに、制御部１１はケースＩＤをキーにして、追加情報ＤＢ１３Ｃ検索し、追加情報を取得する。その他情報として、何れの情報を取得するかについては、実績データに含めるデータ項目により決定される。

【0069】

制御部１１は処理対象としている活動情報、取得した顧客情報、回答情報、及び物件・部屋情報、並びに基本設備情報、付加情報、契約条件、特記事項、環境情報及び追加情報
に基づき、実績データを生成し、実績データＤＢ１３Ｄに記憶する（ステップＳ６７）。

【0070】

実績データに含まれる見込み顧客の属性は、顧客情報より得られる。実績データに含まれる希望条件は、回答情報、追加情報より得られる。実績データに含まれる物件情報は、部屋基本情報、物件建物に関する情報、基本設備情報、契約条件、特記事項、環境情報より得られる。

【0071】

制御部１１は未処理の活動情報があるか否かを判定する（ステップＳ６８）。制御部１１は未処理の活動情報があると判定した場合（ステップＳ６８でＹＥＳ）、処理をステップＳ６２へ戻し、未処理の活動情報についての処理を行なう。未処理の活動情報がないと判定した場合（ステップＳ６８でＮＯ）、実績データ作成処理を終了する。

【0072】

図２５は決定木分析処理の手順を示すフローチャートである。図２５に示す処理は図２３のステップＳ５２に対応する。提供サーバ１の制御部１１は実績データＤＢ１３Ｄに記憶してある実績データ群について、情報利得を総当たりで計算する（ステップＳ８１）。制御部１１は、実績データに含まれる全項目について情報利得を計算する。制御部１１は、実績データに含まれる項目の夫々の内容に応じて実績データ群を分割したときの情報利得を個別に計算する。

【0073】

また、実績データに含まれる項目の内容に応じて、実績データは複数通りの分類が可能である場合、制御部１１は、複数通りの分類方法の夫々について情報利得を計算する。情報利得を計算すべき複数通りの分類方法は、項目の夫々について予め定められていてもよい。なお、制御部１１は、情報利得の代わりにｉｍｐｒｏｖｅ値を計算してもよい。

【0074】

制御部１１は、次に、実績データに含む項目に中から、実績データの分類に用いるための一つの項目の値（特徴量）を選択する（ステップＳ８２）。制御部１１は、計算した情報利得の中で最大の情報利得が得られる項目を選択する。なお、制御部１１は、情報利得の代わりにｉｍｐｒｏｖｅ値を利用して選択を行ってもよい。制御部１１は、次に、選択した特徴量に応じて、実績データ群を二つの実績データ群に分割することにより、複数の実績データを分類する（ステップＳ８３）。制御部１１は、ステップＳ８２で選択した分類方法に従って実績データを分類する。情報利得が最大になる項目の値に応じて実績データを分類することにより、営業結果に対する影響の大きい項目の順に、項目の値に応じて実績データを分類する。

【0075】

制御部１１は、次に、複数の実績データ群の中に分類の終了条件を満たさない実績データ群があるか否かを判定する（ステップＳ８４）。分類の終了条件は、予め定められており、補助記憶部１３に予め記憶されているか、又は制御プログラム１Ｐに含まれている。分類の終了条件の一例は、分類回数が所定の回数に達したことである。分類の終了条件の他の例は、実績データ群の中で営業結果が成約であるデータ又は営業結果が失注であるデータの割合が所定の割合を超過していることである。分類の終了条件の他の例は、実績データ群に含まれる実績データの数が所定数を下回っていることである。分類の終了条件の他の例は、実績データ群の数が所定の上限を超過していることである。

【0076】

制御部１１は、分類の終了条件を満たさない実績データ群があると判定した場合（ステップＳ８４でＹＥＳ）、分類の終了条件を満たさない一つの良否データ群を選択する（Ｓ８５）。制御部１１は処理をステップＳ８１へ戻して、選択した実績データ群に対してステップＳ８１～Ｓ８３の処理を実行する。このように、制御部１１は、ステップＳ８１～Ｓ８５の処理を再帰的に繰り返すことにより、営業結果に対する影響が大きい項目の順に、段階的に、実績データを項目の値に応じて分類する。

【0077】

分類の終了条件を満たさない実績データ群が無い場合（ステップＳ８４でＮＯ）、制御部１１は、複数の実績データを段階的に分類した決定木を作成し、作成した決定木を補助記憶部１３に記憶する（ステップＳ８６）。制御部１１は決定木分析処理を終了し、処理を呼び出し元に戻す。

【0078】

図２６は決定木の例を示す説明図である。図２６に示す決定木は、希望家賃と物件家賃との２つの項目で、実績データを分類した例である。顧客の希望家賃が５万円を越え、紹介した物件家賃が５万円を越えている場合、失注確率８０％、成約確率２０％であることを示している。顧客の希望家賃が５万円を越え、紹介した物件家賃が５万円以下の場合、失注確率２０％、成約確率８０％であることを示している。顧客の希望家賃が５万円以下で、紹介した物件家賃が５万円を越えている場合、失注確率８０％、成約確率２０％であることを示している。顧客の希望家賃が５万円以下で、紹介した物件家賃が５万円以下の場合、失注確率２０％、成約確率８０％であることを示している。図２６では２つの項目で分類している例であるが、実績データに含まれる他の項目による分類結果を、決定木に反映してもよい。例えば、希望間取りと紹介した物件の間取りによる分類である。

【0079】

生成した決定木を用いて新たな見込み顧客に対して提案する部屋を選定する処理について説明する。以下の説明においては、新たな見込み顧客についての顧客情報、回答情報、及び追加情報が取得され、それぞれ見込み顧客ＤＢ１３Ａ、回答ＤＢ１３９、及び追加情報ＤＢ１３Ｃに既に記憶されているものとする。図２７は部屋選定処理の他の手順例を示すフローチャートである。提供サーバ１の制御部１１は顧客情報を見込み顧客ＤＢ１３Ａから取得する（ステップＳ９１）。制御部１１は希望情報を回答ＤＢ１３９及び追加情報ＤＢ１３Ｃから取得する（ステップＳ９２）。制御部１１は部屋基本ＤＢ１３２を参照して、処理対象とする部屋を選択する（ステップＳ９３）。制御部１１は選択する部屋は、状況列の値が空室、退去見込み等の部屋とし、状況列の値が入居中、申込み済等である部屋は除く。制御部１１は物件ＤＢ１３１、部屋基本ＤＢ１３２から、物件情報を取得する（ステップＳ９４）。制御部１１は基本設備ＤＢ１３３、付加情報ＤＢ１３４、契約条件ＤＢ１３５、周辺ＤＢ１３６、特記ＤＢ１３７、追加情報ＤＢ１３Ｃ等からその他情報を取得する（ステップＳ９５）。制御部１１はステップＳ９１からＳ９５で取得した情報に基づき、決定木を探索して成約確率を取得する（ステップＳ９６）。取得した成約確率は主記憶部１２、補助記憶部１３等に設けた一時記憶領域に、物件ＩＤ、部屋ＩＤと対応付けて記憶する。制御部１１は未処理の部屋があるか否かを判定する（ステップＳ９７）。制御部１１は未処理の部屋があると判定した場合（ステップＳ９７でＹＥＳ）、処理をステップＳ９３へ戻し、未処理の部屋についての処理を行なう。制御部１１は未処理の部屋がないと判定した場合（ステップＳ９７でＮＯ）、制御部１１は成約確率に基づき部屋を絞り込む（ステップＳ９８）。例えば、制御部１１は成約確率の高い上位３つの部屋に絞り込む。制御部１１は絞り込んだ部屋についての情報を出力し（ステップＳ９９）、処理を終了する。制御部１１が出力した部屋情報は営業端末２に表示されるので、営業員はそれに従い、見込み顧客に部屋を提案する。

【0080】

本実施の形態においては、次の効果を奏する。過去の営業活動に基づいて生成した決定木を用いて、顧客へ提案すべき部屋を決定するので、業務経験の浅い営業員であっても、見込み顧客に対して、成約確率の高いと予測される部屋を提案可能となる。

【0081】

本実施の形態では決定木は１つ生成する前提で説明したが、それに限らない。実績データに含まれる一部の項目により、実績データを分割し、分割した実績データ群毎に決定木を生成してもよい。例えば、顧客の職業が学生、会社員、事業主、その他の場合の４つに場合に分割し、分割した実績データ毎に決定木を生成してもよい。部屋選定処理においては、見込み顧客の属性等により使用する決定木を選択し、選択した決定木を用いて処理を行なう。

【0082】

（実施の形態４）
本実施の形態は、成約確率を算出する部屋を絞り込む形態に関する。図２８は部屋選定処理の他の手順例を示すフローチャートである。本実施の形態おける部屋選定処理は、図２７に示した実施の形態３における部屋選定処理に変更を加えたものである。図２８は当該変更部分を示している。提供サーバ１の制御部１１は図２７のステップＳ９２を実行後、絞り込み用情報を抽出する（ステップＳ１００）。絞り込み用情報は、例えば希望情報に含まれる希望間取り、希望家賃、希望エリアである。制御部１１は絞り込む用情報を用いて、処理対象とする部屋を絞り込む（ステップＳ１０１）。制御部１１は絞り込んだ部屋を処理対象として、図２７のステップＳ９３以降を実行する。

【0083】

本実施の形態は、処理対象とする部屋を絞り込むので、部屋選定処理の処理量を低減することが可能となる。

【0084】

（実施の形態５）
本実施の形態は、実施の形態４と同様に処理対象とする部屋を絞り込むと共に、複数の決定木を使い分ける形態に関する。図２９は部屋選定処理の他の手順例を示すフローチャートである。本実施の形態おける部屋選定処理は、図２７に示した実施の形態３における部屋選定処理に変更を加えたものである。図２９は当該変更部分を示している。図２９において、ステップＳ１００、ステップＳ１０１における処理は実施の形態４と同様であるから説明を省略する。制御部１１はステップＳ１０１の実行後、決定木を選択するための選択用情報を抽出する（ステップＳ１０２）。選択用情報は、例えば、見込み顧客の職業や家族形態等である。制御部１１は選択用情報を用いて、使用する決定木を選択する（ステップＳ１０３）。制御部１１は選択した決定木を用い、絞り込んだ部屋を処理対象として、図２７のステップＳ９３以降を実行する。

【0085】

本実施の形態は、処理対象とする物件・部屋を絞り込むので、部屋選定処理の処理量を低減することが可能となるとともに、複数の決定木を使い分けることにより、成約確率の高いと予測される部屋を選定することが可能となる。

【0086】

（実施の形態６）
本実施の形態は、見込み顧客がネットワークを介して提供サーバ１へアクセスし、物件・部屋情報を検索・参照する形態に関する。従来の不動作情報サイトと同様に、提供サーバ１は、検索条件に合致した物件・部屋情報を見込み顧客へ提供する。その際に、決定木を用いて判定したおすすめの部屋情報を提示する。以下の説明においては、見込み顧客が使用する顧客端末と提供サーバ１とが通信を行うものとして説明するが、それに限らない。顧客端末と提供サーバ１との間を仲介するＷｅｂサーバを設けてもよい。

【0087】

図３０は部屋検索処理の手順例を示すフローチャートである。提供サーバ１の制御部１１は、顧客端末から希望情報を取得する（ステップＳ１１１）。制御部１１は希望情報に適合する部屋の検索を行なう（ステップＳ１１２）。制御部１１は希望情報に含まれる条件に応じて、物件ＤＢ１３１及び部屋基本ＤＢ１３２の他、基本設備ＤＢ１３３、付加情報ＤＢ１３４、契約条件ＤＢ１３５、周辺ＤＢ１３６、特記ＤＢ１３７又は施設ＤＢ１３８を検索する。なお、希望情報に条件が含まれていない場合、制御部１１は、即入居が可能な部屋についての検索を行なう。制御部１１は検索にヒットしたか否かを判定する（ステップＳ１１３）。制御部１１は検索にヒットしていないと判定した場合（ステップＳ１１３でＮＯ）、処理をステップＳ１２１へ移す。制御部１１は検索にヒットしたと判定した場合（ステップＳ１１３でＹＥＳ）、見込み顧客についての情報（顧客情報）が得られているか否かを判定する（ステップＳ１１４）。顧客情報は、見込み顧客自身が顧客端末へ入力したものを、希望情報と共に顧客端末から受信し取得する。また、顧客端末において、見込み顧客のインターネットでの行動履歴をクッキー等で保存し、当該行動履歴より顧客情報（年齢、性別等）を推測してもよい。制御部１１は、顧客情報が得られていないと判定した場合（ステップＳ１１４でＮＯ）、処理をステップＳ１１６へ移す。制御部１１は、顧客情報が得られていると判定した場合（ステップＳ１１４でＹＥＳ）、顧客情報の中から、決定木による判定に用いる情報を抽出する（ステップＳ１１５）。制御部１１は、検索にヒットした部屋の中で処理対象とする部屋を選択する（ステップＳ１１６）。制御部１１は選択した部屋に関する情報の中で、決定木による判定に用いる情報を取得する（ステップＳ１１７）。制御部１１は決定木を用いて、選択した部屋の成約確率を取得する（ステップＳ１１８）。制御部１１は未処理の部屋があるか否かを判定する（ステップＳ１１９）。制御部１１は未処理の部屋があると判定した場合（ステップＳ１１９でＹＥＳ）、処理をステップＳ１１６へ戻し、未処理の部屋についての処理を行なう。制御部１１は未処理の部屋がないと判定した場合（ステップＳ１１９でＮＯ）、ステップＳ１１１でヒットした部屋の情報をソートする（ステップＳ１２０）。制御部１１は顧客端末へ送信する画面を生成する（ステップＳ１２１）。ステップＳ１１３から遷移した場合、送信する画面は検索のヒット件数が０であることを知らせる画面を生成する（ステップＳ１２１）。ステップＳ１２０から遷移した場合、成約確率が上位の数件については、一覧とは別に目立つように表示する画面を生成する。制御部１１は生成した画面を顧客端末へ出力し（ステップＳ１２２）、処理を終了する。

【0088】

図３１は検索結果表示画面の例を示す説明図である。検索結果表示画面ｄ０３は表示領域ｄ０３１、推奨領域ｄ０３２、条件設定領域ｄ０３３、及び検索ボタンｄ０３４を含む。表示領域ｄ０３１は検索にヒットした部屋の情報を表示する。推奨領域ｄ０３２は決定木により成約確率が高いと判定した部屋の情報を表示する。条件設定領域ｄ０３３は検索条件を設定する領域である。検索ボタンｄ０３４は条件設定領域ｄ０３３で設定した検索条件で再検索を指示するボタンである。推奨領域ｄ０３２は例えば、表示領域ｄ０３１とは異なる枠とする。図３１では影付きの枠としてある。また、推奨領域ｄ０３２には推奨メッセージｄ０３２１を含めている。このように、推奨領域ｄ０３２は、視覚的に表示領域ｄ０３１とは異なる表示態様を含めることにより、見込み顧客の目が止まることが期待される。

【0089】

検索結果表示画面ｄ０３において、推奨領域ｄ０３２を設ける数は任意である。決定木により判定した成約確率により決定する。例えば、成約確率が７５％以上の部屋を最大３件表示すると設定した場合、成約確率７５%以上の物件が一つもなければ、推奨領域ｄ０３２は表示しない。成約確率７５%以上の物件が４以上あっても、推奨領域ｄ０３２は３つしか表示しない。また、表示領域ｄ０３１と推奨領域ｄ０３２とをどのような配置で表示するかについて特に制限はないが、推奨領域ｄ０３２はなるべく上位に表示することが望ましい。

【0090】

本実施の形態は以下の効果を奏する。検索結果表示画面ｄ０３において、決定木により成約確率が高いと判定した部屋の情報を表示するので、成約率の向上が見込まれる。

【0091】

なお、成約確率が所定値以上の物件が一つもなければ、推奨領域ｄ０３２は表示しないとしたが、それに限らない。成約確率が所定値以上の物件が一つもない場合は、希望情報に含まれる複数の条件のうち、いくつかを削除する、または値の範囲を広げるなどをして、該当する部屋の数を増やす。そして、増えた部屋について、決定木により成約確率を判定し、成約確率が高いと判定したものを、推奨領域ｄ０３２に表示してもよい。この場合、求めている部屋の条件を見込み顧客自身が思い違いをしている場合であっても、成約率の向上が期待される。なお、推奨領域ｄ０３２には検索にヒットしていない部屋の情報を表示することになるため、その旨を見込み顧客に伝えるため、推奨メッセージｄ０３２１の内容を「類似するこんな部屋は如何でしょうか？」等にすることが望ましい。

【0092】

上述の実施の形態においては、部屋選定処理において使用する決定木は１つであることを前提としたが複数の決定木を用いてもよい。例えば、実績データに含む全項目の中から、任意に選択した複数項目により決定木を複数作成するランダムフォレストを採用する。部屋選定処理においては、ランダムフォレストを用いて各部屋の成約確率を求める。

【0093】

（変形例）
本変形例は実施の形態６に示した部屋検索処理の他の例を含むものである。図３２は部屋検索処理の手順例を示すフローチャートである。見込み顧客の操作により顧客端末を提供サーバ１へ情報要求を送信する（ステップＳ１３１）。提供サーバ１の制御部１１は要求を受信する（ステップＳ１３２）。制御部１１は送信された要求からクッキーを取得する（ステップＳ１３３）。なお、顧客端末からクッキーが送信されていない場合、制御部１１は取得したクッキーは空となる。制御部１１は部屋の条件があるか否かを判定する（ステップＳ１３４）。ここで、条件があると制御部１１が判定するのは、次の場合である。検索結果表示画面ｄ０３において、条件設定領域ｄ０３３に条件が設定された後、検索ボタンｄ０３４が選択され、部屋の希望情報が顧客端末から送信された場合である。なお、条件設定領域ｄ０３３と同様な条件が設定可能であれば、検索結果表示画面ｄ０３以外のＷｅｂフォームから送信されてもよい。また、フォームにより部屋の希望情報が顧客端末へ送信されたのではなく、クッキーに設定されている場合である。条件があると制御部１１が判定するのは、部屋の希望情報を含むフォームが送信されていない場合、クッキーが空、又は、空ではないが部屋の希望情報が含まれていない場合である。制御部１１は部屋の条件があると判定した場合（ステップＳ１３４でＹＥＳ）、フォーム、クッキーから条件を取得する（ステップＳ１３５）。なお、ステップＳ１３４の判定を行う際に取得済みであれば、再取得は不要である。制御部１１は条件に適合する部屋を検索する（ステップＳ１３６）。制御部１１は検索にヒットした各部屋について、決定木を用いて、成約確率を取得する（ステップＳ１３７）。なお、クッキーに見込み顧客の類推属性、例えば性別、年齢層、職業、居住エリアなどが含まれている場合、これに基づき複数の決定木を使い分けてもよい。例えば、学生と思われる見込み顧客には学生用の決定木を用いる。制御部１１は成約確率により部屋の情報を降順にソートする（ステップＳ１３８）。制御部１１は顧客端末へ送信する画面を生成する（ステップＳ１３９）。制御部１１は生成した画面を顧客端末へ送信する（ステップＳ１４０）。顧客端末は画面を受信し表示する（ステップＳ１４１）。顧客端末が表示する画面は検索結果表示画面ｄ０３である。制御部１１は処理を終了する。上述したように、検索結果表示画面ｄ０３において、見込み顧客が検索ボタンｄ０３４を選択すると、部屋検索処理が起動され、ステップＳ１３１から実行される。

【0094】

制御部１１は部屋の条件がないと判定した場合（ステップＳ１３４でＮＯ）、見込み顧客の閲覧した部屋がｋ件以上であるか否かを判定する（ステップＳ１４３）。ｋには予め自然数を設定する。当該判定は見込み顧客の閲覧履歴より行う。閲覧履歴は顧客端末が送信したクッキーに含まれている。または、見込み顧客のＩＤと対応付けた閲覧履歴が補助記憶部１３に記憶してあり、顧客端末が送信したクッキーより提供サーバ１が付与したＩＤを取得し、閲覧履歴を取得してもよい。なお、ここでいう閲覧履歴は、履歴ＤＢ１３Ｂが記憶する履歴とは異なるものである。見込み顧客の閲覧した部屋がｋ件以上であると判定した場合（ステップＳ１４３でＹＥＳ）、閲覧履歴に基づく部屋の情報を取得する（ステップＳ１４４）。制御部１１はステップＳ１３９以降を実行する。見込み顧客の閲覧した部屋がｋ件以上でないと判定した場合（ステップＳ１４３でＮＯ）、人気の部屋がｋ件以上あるか否かを判定する（ステップＳ１４５）。判定にステップＳ１４３と同じｋを用いているが、ｋに変えて他の自然数でもよい。人気の部屋とは、例えば、最もページビューが多い部屋である。見込み顧客がお気に入り登録した数が最多の部屋でもよい。制御部１１は、人気の部屋がｋ件以上あると判定した場合（ステップＳ１４５でＹＥＳ）、人気の部屋に関する情報を取得する（ステップＳ１４６）。制御部１１はステップＳ１３９以降を実行する。制御部１１は、人気の部屋がｋ件以上ないと判定した場合（ステップＳ１４５でＮＯ）、所定の部屋に関する情報を取得する（ステップＳ１４７）。所定の部屋とは、例えば、予め設定したおすすめの部屋である。制御部１１はステップＳ１３９以降を実行する。

【0095】

本変形例においては、見込み顧客が部屋の条件（部屋の希望情報）を設定しない場合においても、部屋の一覧を得ることが可能である。見込み顧客は少ない操作により部屋の情報を得られるので、条件の設定の煩雑さにより検索を断念する可能性が低くなる。一覧表示した後に、改めて条件設定を見込み顧客に行わせることにより、自らが希望する部屋の情報はないと、見込み顧客に感じさせることを防止可能となる。

【0096】

なお、部屋の条件を取得していない場合（ステップＳ１３４でＮＯ）の処理については、あくまで例示であり、他の処理を行ってもよい。例えば、全ての部屋を所定の条件、賃料の安い順、築年数順、情報の新しい順（新着順）等で並べ替えた一覧を作成し、表示してもよい。また、部屋の条件を取得していないが、見込み顧客の類推属性が得られている場合は、属性に則した部屋の一覧、例えば、学生にお勧めの部屋一覧、２０代会社員にお勧めの部屋一覧を表示してもよい。当該部屋一覧は予め作成してもよいし、特記ＤＢ１３７の客層列の値を用いて、都度作成してもよい。

【0097】

各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

【符号の説明】

【0098】

１００ 提供システム
１ 提供サーバ
１１ 制御部
１２ 主記憶部
１３ 補助記憶部
１３１ 物件ＤＢ
１３２ 部屋基本ＤＢ
１３３ 基本設備ＤＢ
１３４ 付加情報ＤＢ
１３５ 契約条件ＤＢ
１３６ 周辺ＤＢ
１３７ 特記ＤＢ
１３８ 施設ＤＢ
１３９ 回答ＤＢ
１３Ａ 見込み顧客ＤＢ
１３Ｂ 履歴ＤＢ
１３Ｃ 追加情報ＤＢ
１４１ 部屋選定モデル
１５ 通信部
１Ｐ 制御プログラム
２ 営業端末
３ ユーザ端末

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】