(57)【要約】  【課題】介業者に効率の良い業務環境を提供すると同時に、賃貸入居希望者にも物件購入の機会を与え、投資家にも比較的簡単かつ安心して投資できる魅力ある物件を提供して、これらによりサブリース市場の活性化を図れる不動産取引支援システムを提供する。  【解決手段】サーバ１と、このサーバ１に電子通信手段ＮＷを介して接続される複数の申込端末２とを具備し、サーバ１に登録されている分譲賃貸物件に対して少なくとも申込端末２から売買や賃貸のための申込手続を行う。その際、前記サーバ１が、登録された分譲賃貸物件に対して、サブリースを前提とした分譲の申込を受け付ける売買申込受付手段１３と、入居申込を受け付ける入退去申込受付手段１４とを有し、一の物件に対して申込端末２から分譲、入居の何れの申込が先にあってもその申込の受付を行い、受け付けた内容を記憶し得るようにした。  【選択図】図３
2009129129.tif 000002
【特許請求の範囲】
【請求項１】
サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入および入居のための申込手続を受け付けるシステムであって、
前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段と、入居の申込手続を受け付ける入居申込受付手段とを有し、
これらの受付手段は一の物件識別で特定される物件に対する購入、入居の両申込手続を並列に受け付けて、申込に係る情報の少なくとも一部を物件識別と関連づけて記憶手段に記憶し得るようにしたことを特徴とする不動産取引支援システム。
【請求項２】
サーバは申込端末から閲覧可能なＷｅｂサイトにおいて、購入申込のために利用可能な操作部と入居申込のために利用可能な操作部とを、それらの物件購入情報および物件入居情報とともに同一画面上、又は相互に関連づけられた画面上に表示するようにしている請求項１記載の不動産取引支援システム。
【請求項３】
サーバは、購入申込及び入居申込に係る状況が把握できるデータを前記画面上に表示して所定のタイミングで更新するようにしている請求項１又は２何れか記載の不動産取引支援システム。
【請求項４】
サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入および入居のための申込手続を受け付けるシステムであって、
前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段と、入居の申込手続を受け付ける入居申込受付手段とを有し、
これらの受付手段が一の物件識別で特定される物件に対する購入申込と入居申込とを同時に又は相前後して受け付ける場合に、少なくとも購入申込に係る情報のうちの申込者情報と入居申込に係る情報のうちの申込者情報とが一致しているか否かによらずに申込を受け付けて、一致している場合にその旨が判断できる状態で申込に係る情報の少なくとも一部を記憶手段に記憶し得るようにしたことを特徴とする不動産取引支援システム。
【請求項５】
サーバは申込端末から閲覧可能なＷｅｂサイト上において、申込者情報の入力とともに、購入か入居か何れか一方の種別を選択しまたは両種別を同時に選択できる入力フォームを表示して、その選択した種別の申込を申込者情報と関連づけて受け付け得るようにしている請求項４記載の不動産取引支援システム。
【請求項６】
サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入のための申込手続を受け付けるシステムであって、
前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段を有し、
購入申込受付手段が、一戸を分割して一又は複数口の分割分譲の購入申込を受け付け、これに伴い一の物件識別に複数の申込者情報を関連づけて記憶し、さらに、一の申込者情報に分割申込口数を関連づけて記憶し得るようにしていることを特徴とする不動産取引支援システム。
【請求項７】
サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入のための申込手続を受け付けるシステムであって、
前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段を有し、
サーバが、物件識別に関連づけて、サブリース条件に基づき家賃収入額を計算するための情報、ローン条件に基づいて返済額を計算するための情報、入居に必要な家賃支払額の情報を記憶しており、申込端末から物件を特定してサブリース条件やローン条件、入居の有無など上記計算に必要なデータを提示した収支シミュレーションの要求があった場合に、サーバは前記情報の全部又は一部を取り出して家賃収入額、ローン返済額、家賃支払額のうちの対応する額とともにこれらの収支額からなる収支シミュレーションデータを生成、表示可能としていることを特徴とする不動産取引支援システム。
【請求項８】
サブリース条件は、入居率に基づき家賃収入額が変動するように規定されたものであり、サーバは想定入居率とともに収支シミュレーションデータを生成、表示可能としている請求項７記載の不動産取引支援システム。
【請求項９】
サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備するものであって、
前記サーバが、サブリース条件に基づき家賃収入額を計算するための情報、ローン条件に基づいて返済額を計算するための情報、入居に必要な家賃支払額の情報を記憶し、さらに、物件識別、サブリース条件、ローン条件、入居の有無など上記計算に必要なデータが含まれたオーナー情報を記憶しており、サーバに電子通信手段を介して接続したオーナー等の使用に係る照会端末からオーナー情報に基づいた実収支の要求があった場合に、サーバは、前記各情報の全部又は一部を取り出して家賃収入額、返済額、家賃支払額のうちの対応する額とともにこれらの収支額からなる実収支データを生成、表示可能としていることを特徴とする不動産取引支援システム。
【請求項１０】
サブリース条件は、物件識別で特定される物件に含まれる戸の全部又は一部にわたる平均入居率に基づき家賃収入額が変動するように規定されたものであって、サーバは、物件識別と関連づけて入退去情報を記憶しており、照会端末から要求があった際に、この入退去情報に基づき予め定めた期間ごとの平均入居率を算出して、期間ごとの実収支データを生成、表示可能としている請求項９記載の不動産取引支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仲介業者に効率の良い業務環境を提供すると同時に、賃貸入居希望者にも物件購入の機会を与え、投資家にも比較的簡単かつ安心して投資できる魅力ある物件を提供して、これらによりサブリース市場の活性化を図れるようにした不動産取引支援システムに関するものである。
【背景技術】
【０００２】
昨今において、賃貸のサブリースを取り扱うものとして、例えば特許文献１、２に示すものが知られている。
【０００３】
特許文献１に示すものは、アパートやマンションなどの不動産を既に取得しているオーナーに対して、一棟を一括で借り上げ（マスターリース）、これを借家人にサブリースして、その賃料の一部をオーナーに家賃として支払うとともに、残りを管理者が管理料として収益するシステムが記載されている。その際、賃料を家賃保証分と入居率に応じた成果分とから構成し、保証料率の異なる複数のサブリースパターンを用意して、オーナーに保証と利回りの兼ね合いを選択できる機会を与えている。
【０００４】
一方、特許文献２に示すものは、不動産を投資物件と考えている投資家に対して、不動産購入後の運用に関する不安を払拭するために、保証年数や保証利率に基づいて物件に応じたサブリース保証額の算出、提示を行い、これを受けて投資家が不動産の購入を決定できるようにしている。
【特許文献１】特開２００４−６２２７８号公報
【特許文献２】特開２００２−１６３４５５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
以上のように、特許文献１のものは、既に不動産を所有するオーナーが管理を委託し易く投資意欲を喚起させ易くすることを目的としたものであって、あくまで一棟所有のオーナーと管理者との関係に終始しており、一般投資家の投資意欲を新たに引き起こすことや、借家人に光を当てるものではない。また、一棟借りは大掛かりである上に、既に立ち上がった物件（主として中古物件）がマスターリースやサブリースの対象となるため、オーナーを探す業務と入居者を募集する業務とが全く分断していて仲介業者や管理業者に多大の負荷が掛かるという不具合もある。
【０００６】
一方、特許文献２のものは、これから不動産物件を購入しようとする者を対象とする点、投資対象に一室のみの場合を含む点などで特許文献１とは事情が異なるが、資金が一戸購入に満たない投資家などは対象外となる点で規模の違いはあるにせよ特許文献１と同様に投資市場の制限になり、また同じく借家人に持家のチャンスを与えるものではない。また、戸単位で個々にリース契約を結ぶ限りにおいては、入居の有無によって家賃収入が満額か０かで大きく変動するため、適切な家賃保証も難しい。さらに、特許文献１と同様に既に立ち上がっている物件（主として中古物件）がサブリースの対象となるため、オーナーを探す業務と入居者を募集する業務とが全く分断していて仲介業者や管理業者に多大の負荷が掛かる点でも上記と同様である。
【０００７】
本発明は、これらの課題をことごとく解消することを目的としている。
【課題を解決するための手段】
【０００８】
本発明は、かかる目的を達成するために、次のような手段を講じたものである。
【０００９】
すなわち、本発明の不動産取引支援システムは、サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入および入居のための申込手続を受け付けるシステムであって、前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段と、入居の申込手続を受け付ける入居申込受付手段とを有し、これらの受付手段は一の物件識別で特定される物件に対する購入、入居の両申込手続を並列に受け付けて、申込に係る情報の少なくとも一部を物件識別と関連づけて記憶手段に記憶し得るようにしたことを特徴とする。
【００１０】
このようなシステム構成にすれば、申込端末から分譲、入居の何れの申込が先にあってもその申込の受付を行い得るので、分譲賃貸の売買と賃貸の双方の業務を１本化して同じ網で同時進行することができ、仲介業者の業務効率が格段に向上することになる。
なお、ここでは購入申込人と入居申込人とが全て完全不一致である態様等も含まれる。「並列に」とは、購入申込人と入居申込人のどちらが先でも受け付け処理を行う意である。「仲介業者等の使用に係る申込端末」は、仲介業者が端末を使って販売、入居の仲介を行うことを主に想定しているが、これ以外に、一般の個人端末などもこの申込端末に含まれ、大規模の売買サイトに個人がアクセスして購入申込や入居申込を行う態様も含まれる。
【００１１】
この場合、サーバは申込端末から閲覧可能なＷｅｂサイトにおいて、購入申込のために利用可能な操作部と入居申込のために利用可能な操作部とを、それらの物件購入情報および物件入居情報とともに同一画面上、又は相互に関連づけられた画面上に表示するようにしていることが望ましい。一の申込端末からのアクセスに対して、購入、入居何れの情報をも閲覧可能、また購入、入居何れの操作部による申込に対してもその受け付けを行い得るので、並列的な処理が簡単に行え、顧客も不動産を購入するか賃貸で借りるかの選択の機会に恵まれ易くなる。
【００１２】
特に、サーバは、購入申込及び入居申込に係る状況が把握できるデータを前記画面上に表示して所定のタイミングで更新するようにしていれば、その不動産物件の客観的な評価材料を得て、購入や入居の申込の判断に利用することができる。
【００１３】
或いは、他の構成からなる本発明の不動産取引支援システムは、サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入および入居のための申込手続を受け付けるシステムであって、前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段と、入居の申込手続を受け付ける入居申込受付手段とを有し、これらの受付手段が一の物件識別で特定される物件に対する購入申込と入居申込とを同時に又は相前後して受け付ける場合に、少なくとも購入申込に係る情報のうちの申込者情報と入居申込に係る情報のうちの申込者情報とが一致しているか否かによらずに申込を受け付けて、一致している場合にその旨が判断できる状態で申込に係る情報の少なくとも一部を記憶手段に記憶し得るようにしたことを特徴とする。
【００１４】
このようなシステム構築にすれば、顧客も不動産を購入するか賃貸で借りるか、更にはオーナーとなって自ら賃貸人として入居するかの選択が可能となり、かつ、サーバ上でこれらを適切に管理することができる。
【００１５】
なお、ここでは購入申込と入居申込を同時に受け付ける場合以外に、先に購入申込を受け付け、後で入居申込を受け付ける態様等も含まれる。そしてここでも、「仲介業者等の使用に係る申込端末」は、仲介業者が端末を使って販売、入居の仲介を行うことを主に想定しているが、これ以外に、一般の個人端末も含まれ、大規模売買サイトに個人がアクセスして購入申込や入居申込を行う態様等が含まれる。
【００１６】
この場合サーバは、申込端末から閲覧可能なＷｅｂサイト上において、申込者情報の入力とともに、購入か入居か何れか一方の種別を選択しまたは両種別を同時に選択できる入力フォームを表示して、その選択した種別の申込を申込者情報と関連づけて受け付け得るようにしていることが望ましい。この場合にも、顧客が不動産を購入するか賃貸で借りるかの選択の機会に恵まれ易くなり、購入と同時に入居するという本発明特有の態様によって借家人に持家となる機会も与え易くなる。
【００１７】
さらに、上記以外の構成からなる本発明の不動産取引支援システムは、サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入のための申込手続を受け付けるシステムであって、前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段を有し、購入申込受付手段が、一戸を分割して一又は複数口の分割分譲の購入申込を受け付け、これに伴い一の物件識別に複数の申込者情報を関連づけて記憶し、さらに、一の申込者情報に分割申込口数を関連づけて記憶し得るようにしていることを特徴とする。
【００１８】
このようなシステム構成を有すれば、投資家にも投資し易い額になり、不動産売買の活性化が図れるとともに、入居者が一部オーナーとなって少しでも借家人の地位を返上する機会を与え易くなる。
【００１９】
この場合、販売申込と入居申込の両方を取り扱う態様に限られず、購入のみを取り扱う態様も含まれる。
【００２０】
また、上記以外の構成からなる本発明の不動産取引支援システムは、サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備し、サーバに登録されている分譲賃貸物件に関する情報を閲覧に供して申込端末から少なくとも購入のための申込手続を受け付けるシステムであって、前記サーバが、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段を有し、サーバが、物件識別に関連づけて、サブリース条件に基づき家賃収入額を計算するための情報、ローン条件に基づいて返済額を計算するための情報、入居に必要な家賃支払額の情報を記憶しており、申込端末から物件を特定してサブリース条件やローン条件、入居の有無など上記計算に必要なデータを提示した収支シミュレーションの要求があった場合に、サーバは前記情報の全部又は一部を取り出して家賃収入額、ローン返済額、家賃支払額のうちの対応する額とともにこれらの収支額からなる収支シミュレーションデータを生成、表示可能としていることを特徴とする。
【００２１】
このようなシステム構成を有すれば、不動産投資に際して、同時に借家人となる態様を含めた購入時の判断に資する判断材料をより的確に与えることができる。
【００２２】
この場合も、販売申込と入居申込の両方を取り扱う態様に限られず、購入のみを取り扱う態様も含まれる。
【００２３】
この場合、サブリース条件が、入居率に基づき家賃収入額が変動するように規定されたものであり、サーバは想定入居率とともに収支シミュレーションデータを生成、表示可能としていれば、利回りや安定性などの判断に資する判断材料をより的確に与えることができる。
【００２４】
さらにまた、上記以外の構成からなる本発明の不動産取引支援システムは、サーバと、前記サーバに電子通信手段を介して接続される仲介業者等の使用に係る複数の申込端末とを具備するものであって、前記サーバが、サブリース条件に基づき家賃収入額を計算するための情報、ローン条件に基づいて返済額を計算するための情報、入居に必要な家賃支払額の情報を記憶し、さらに、物件識別、サブリース条件、ローン条件、入居の有無など上記計算に必要なデータが含まれたオーナー情報を記憶しており、サーバに電子通信手段を介して接続したオーナー等の使用に係る照会端末からオーナー情報に基づいた実収支の要求があった場合に、サーバは、前記各情報の全部又は一部を取り出して家賃収入額、返済額、家賃支払額のうちの対応する額とともにこれらの収支額からなる実収支データを生成、表示可能としていることを特徴とする。
【００２５】
このようなシステム構成を有すれば、オーナーとなった後の財産管理等に有効に資することができる。
【００２６】
この場合、どのように購入申込や入居申込が行われ、それを受け付けたかを問わず、結果的に物件を購入したオーナーが自身で入居する場合を含めていつでも収支を確認できるようにしていればよい。
【００２７】
この場合、サブリース条件が、物件識別で特定される物件に含まれる戸の全部又は一部にわたる平均入居率に基づき家賃収入額が変動するように規定されたものであって、サーバは、物件識別と関連づけて入退去情報を記憶しており、照会端末から要求があった際に、この入退去情報に基づき予め定めた期間ごとの平均入居率を算出して、期間ごとの実収支データを生成、表示可能としていれば、利回りや安定性などの運用実績に関する情報をより適切に提供することが可能となる。
【発明の効果】
【００２８】
本発明は、以上説明した構成であるから、物件の立ち上げと並行してオーナー募集や入居人の募集を効率的に行うことができ、仲介業者等の業務効率を大幅に改善すると同時に収益の機会を拡大できる魅力ある業務を提供できるとともに、借家人には入居とともに物件購入のチャンスを与え、一般投資家にはより簡易な投資対象を提供して、サーバを運用する管理者も利益を得る機会に恵まれるようにした、新規有用な不動産取引支援システムを提供することが可能となる。
【発明を実施するための最良の形態】
【００２９】
以下、本発明の一実施形態を、図面を参照して説明する。
【００３０】
本実施形態で取り扱う分譲物件は、基本的に新築のマンションやアパート等であり、販売者であり管理者である不動産会社は、仲介業者を通じて分譲販売を実施し、販売と同時に不動産会社が個々のオーナーから部屋を借り上げる（マスターリース）一方、仲介業者を通じ入居者を募集してこれらに賃貸（サブリース）することにより家賃収入を得て、その一部を各オーナーに安定的に分配する運営を行うものである。
【００３１】
システム構成は、図１に示すように、全体を一括管理するサーバ１と、サーバ１に電子通信手段ＮＷを介して接続されて仲介業者により使用される複数の仲介端末（申込端末）２とが基本であり、これに分譲賃貸物件を所有するオーナーの使用に係るオーナー端末（照会端末）３、更には、不動産会社と予め契約した保証会社の使用する保証会社情報処理装置４や金融機関の使用する金融機関情報処理装置５、損害保険会社の使用する損保会社情報処理装置６なども接続される。勿論、サーバ１に対しては当該サーバ１に接続された管理者端末１ａから種々のデータ等の入出力を行うことができる。
【００３２】
サーバ１は、図２に示すように、ＣＰＵ１１ａ、メモリ１１ｂ及びインターフェース１１ｃを備えた通常のハードウェア構成を有し、メモリ１１ｂには、各種の演算や表示、端末２，３，４，５，６等との間のデータ送受信を行うためのプログラム（モジュールやスクリプト、アルゴリズムなど、所定のデータの授受や演算に関わる手順を記述してＣＰＵに実行されるものを広く含む。以下同様。）が格納してある。そして、ＣＰＵ１１ａは逐次これらのプログラムを読み出し、周辺ハードウェア資源と協働して所定の演算その他の処理を実行し、図３に示す閲覧受付手段１２、購入申込と売却申込を兼ねた売買申込受付手段１３、入居申込と退去申込を兼ねた入退去申込受付手段１４、シミュレーション受付手段１５、収支照会手段１６などとしての役割を果たす。これらの役割については後述する。また、仲介端末２、オーナー端末３、保証会社情報処理装置４、金融機関情報処理装置５、損保会社情報処理装置６などのハードウェア構成も基本的には上記サーバ１のそれとほぼ同様である。
【００３３】
サーバ１にはデータベースとして、図３に示すように、物件情報データベースＤＢ１、サブリース情報データベースＤＢ２、ローン情報データベースＤＢ３、収支情報データベースＤＢ４、保証情報データベースＤＢ５、オーナー情報データベースＤＢ６、入退去情報データベースＤＢ７などが構築してある。なお、ここに言うデータベースには、狭義には単なるデータファイルやテーブル等も含まれる。
＜データベースの概要＞
【００３４】
図３の物件情報データベースＤＢ１には、図４に示すような物件情報をＷｅｂ上に公開するための表示フォームやデータ等が記憶されている。図示例における物件情報は、サブリース対象となる不動産物件に関する物件識別（Ａ０７０３６など物件に固有の値）、物件名、立地、構造、販売価格（一戸価格、分割価格）、家賃額等とともに、募集戸数、募集オーナー数、現購入申込（登録）数、残り数、募集入居数、現入居申込（登録）数、残り数、適用可能なサブリースパターンなどの表示欄からなっており、これらに対応するデータが物件識別と関連づけて物件単位の物件レコード等として記憶されている。
【００３５】
図３のサブリース情報データベースＤＢ２には、図５に示すようなサブリースパターンを表示するための表示フォームやデータ等が記憶してある。図示例における表示フォームは、保証料率（８０％、７０％など）、分配比率（０．５−０．５、０．７５−０．２５など）、入居率（１００％、９０％、８０％…などのモデル数値）からなるサブリースメニューをパターン識別（１，２…など）によって複数パターン表示するようになっている。保証料率とは、満室時家賃収入の一定率を保証するものであり、実際の家賃収入がその一定率よりも下回った場合でも最低家賃収入をその保証料率によって担保するものである。また、分配比率とは、満室時家賃収入と保証率とにより算出される賃料との差益につき、オーナーと管理者（不動産管理会社）とが成果分を分配する際の比率である。保証料率が高いほど、オーナーには保証が厚い分、入居率に基づいたリターンが少なくなるように設定される。このようなサブリースパターン自体は既に特許文献１で示されているところであるが、この実施形態では特に入居率の取り扱い方に特異性を有するとともに、他のパターンでも基本的なシステム運営の成立性には問題がないため、詳細については後述する。
【００３６】
図３のローン情報データベースＤＢ３には、図６に示すようなローン情報を表示するための表示フォームやデータ等が記憶してある。図示例では、借入金および金利の各データのほかに、借入期間に応じた月々の返済額、ローン併用型にあってはボーナス時の返済額、更にはトータルの総返済額もデータとして含まれている。例えば、借入金８００万、金利２．５％、２５年の均等返済で、月々返済額が３５，８８９という具合である。
【００３７】
図３の収支情報データベースＤＢ４には、図７に示すような収支のシミュレーションを表示するための表示フォームやデータ等が記憶してある。この表示フォームは、物件を購入した場合の家賃収入（見込み）、ローンを組んだ場合のローン返済額、オーナー自らが入居して家賃を支払う場合の家賃支払額、これらの収支額の各欄が、入居率に関連づけて表示される。勿論、後述のように、入居していなければ家賃支払の欄は空欄であり、ローンを組んでいなければローン返済の欄は空欄である。
【００３８】
図３の保証情報データベースＤＢ５には、管理者の家賃保証を得るための保障会社情報処理装置４や損保会社情報処理装置６との間で行った保証契約、保険契約内容等が記憶されている（図示省略）。また、このデータベースＤＢ５には、買取保証に関するデータも記憶されている。買取保証とは、売買申込受付手段１３が仲介端末２から物件の売却申込を受け付けたとき、予め定めた算出方法によりその時点において算出される物件査定額から所定額を減じた額を買取額として保証するものであり、仲介端末２等からその情報の内容を閲覧可能なように、また、後述する売却申立時に対応できるようなデータ等として記憶されている。
【００３９】
図３のオーナー情報データベースＤＢ６には、図８に示すようなオーナー情報を表示するためのフォームやデータ等が記憶してある。このオーナー情報は、不動産購入の申込又は登録をした者に関する氏名、ＩＤ（システム上、一人に１つ与えられる固有の識別）、ステータス（購入申込、オーナー登録、売却申込など現在の状態を表わすもの）、物件識別（Ａ０７０３６など）、一戸購入か分割購入かの種別などからなり、分割購入の場合は口数／分割数で表示される。また、サブリースパターン、ローンがある場合には個別ローン識別、オーナーが同時に入居しているか否などが記憶してある。
【００４０】
図３の入退去情報データベースＤＢ７には、図９に示すような入退去者に関する情報を表示するためのフォームやデータ等が記憶してある。この入退去情報は、物件識別とともに、入居者の氏名、ＩＤ，ステータス（入居申込、入居者登録、退出申込など）、入居日、退去日、オーナー登録の有無などの情報などからなり、当該物件に関する全戸数、入居数、入居率などが、物件識別に対応した物件データレコードや上記の入退去情報などに基づいて自動計算されている。
＜各機能手段の概要＞
【００４１】
次いで、図３に示すサーバ１の機能手段１２，１３，１４，１５，１６の果たす役割について説明する。これらは、例えばＷｅｂ上に公開された不動産業者のホームページに仲介端末２がアクセスして、そこに用意されているアイコンをクリックするなど所要の操作部に対する操作をすることによって起動する。
【００４２】
図３の閲覧受付手段１２は、仲介端末２からのアクセスにより閲覧要求があると、物件情報データベースＤＢ１から物件名データ、立地データ、価格データなどの予め定められた物件情報を取り出してＷｅｂページ上に所定のリスト形式で物件情報を表示する（図示省略）。リストには特定の物件を選択する操作部が付帯しており、その操作部を介してリストから特定の不動産物件を選択すると、サーバ１はその選択された物件の物件識別に基づき、前記物件情報データベースＤＢ１からより詳細なデータを取り出し、必要に応じ更に演算、加工を施して、図４の物件情報画面を所定欄への値の出力とともに表示する。図示例の場合、物件識別Ａ０７０３６に関連づけられたデータとして、販売価格データに基づく一戸価格は８００万、分割分譲価格は所定の分割数データの値で販売価格データの値を除した値、すなわちここでは１／８単位で一口１００万、家賃データに基づく家賃は６万、募集戸数データに基づく募集戸数は２０戸、募集オーナー数データに基づく募集オーナー数は２０〜１６０名である。つまり、この物件は分割数データが８に設定され、一戸を最大８人で共有できる取り扱いを可能にしている。これらのデータは、管理者端末１ａから事前に入力されている。
【００４３】
また、現購入申込（登録）数データは１４、分割口数データは１と３／８、残り戸数は４戸、残り分割口数は５／８である。また、募集入居数は２０、現入居申込（登録）数は１２で、残り８である。これらのデータは、後述する売買申込受付手段１３や入退去申込受付手段１４が購入や入居の申込を受け付けた際にインクリメント／デクリメントされるものである。さらに、適用サブリースパターンが表示されている。このサブリースパターンデータは、この物件を購入するにあたって選択可能なサブリースパターンを表示しているもので、管理者端末１ａにおいて物件ごとに設定される。詳細については後述する。
【００４４】
下段に配置してあるのはそれぞれ購入申込操作部ａ、入居申込操作部ｂ、収支シミュレーション照会に係る操作部ｃ、ローン情報照会に係る操作部ｄ、サブリース情報照会に係る操作部ｅである。これらの操作部が操作されると、各操作部に関連づけられた所定のプログラムが起動して、後述する種々の演算や表示が実行される。
【００４５】
図４の物件閲覧画面において仲介端末２から操作部ｄを操作してローン情報の照会があれば、閲覧受付手段１２はローン情報データベースＤＢ３から対応するデータを取り出して、図６のローン情報に関するフォームを表示するとともに、標準借入期間である１０年、１５年、２０年、２５年ごとに、所定の手順に沿って月々の返済予定額と返済総額、ボーナス月併用の場合にはボーナス月分を併せて算出し、算出結果を対応する欄に出力する。図示例では、借入金８００万、金利２．５％でローンを組んだ場合の借入期間２５年の場合の月々均等払とした返済額（３５，８８９）が例示してある。借入金の欄は仲介端末２から入力可能である。このようなローン情報の閲覧のための表示やそのための算出は、仲介端末２から外部の銀行などの金融機関情報処理装置５（図１参照）に接続してそのデータベースを利用することも有効である。少なくとも金利については刻々変化するため、この実施形態では所定のタイミングで金融機関の保有するデータを金融機関情報処理装置５からルックアップあるいはフェッチ等して金利の欄に現在の金利として表示する機能が備わる。
【００４６】
図４において仲介端末２から操作部eを操作してサブリース情報の照会があれば、サーバ１はサブリース情報データベースＤＢ２から図５のサブリースパターンを取り出して表示する。
【００４７】
この実施形態では、家賃の値をｘ、保証料率をα、オーナー分配比率をβ、入居率をｋとしたときに、オーナーの家賃収入額を、ｘ・｛α＋（ｋ−α）×β｝、管理者の収益をｘ・（ｋ−α）×（１−β）とする家賃算出プログラムが前記サブリース情報データベースＤＢ２等に記憶してある。０＜α＜１、０＜β＜１の間で設定され、またここで記憶されているサブリースパターンは、パターン１で（α、β）＝（０．８、０．５）、パターン２で（α、β）＝（０．７、０．２５）である。この場合、ｋ≧αで家賃収入率の実効値が算出され、ｋ＜αとなる場合にはｋ＝αで計算して家賃収入率を保証料率αとする手順が前記プログラムに含まれており、最低の保証料率αが常に保証される。管理者の収益は、ｘ・｛（ｋ−α）×（１−β）｝として算出される。
【００４８】
入居率が下がり、或いは何らかの設備投資が発生すると、家賃で上記を補えなくなるが、これは保証会社や損保会社との間の別途の契約によって補填される仕組みになっており、ｋ＜αとなったことを判断して実行される別異の保証処理ルーチンが備わる。
【００４９】
このような保険会社や損保会社の契約内容は保証情報データベースＤＢ５に記憶されて、アクセスした仲介端末２等から閲覧手段を介して閲覧可能とされており、物件購入の判断時に安心材料となる有効な情報を提供することができる。
【００５０】
この保証料率＋入居率に応じた利益分配の基本的な考え方自体は、特許文献１に既に示されているのは既述したところである。但し、本実施形態で取り扱いの対象となる物件は、オーナーが戸単位あるいは分割口数単位で物件を所有する点に特質があり、オーナー所有の物件単位で考えれば入居率は１か０になって、実質的に大きく変動する入居率に準拠することは困難になる。そこで、この実施形態では、入居率ｋをオーナーの所有対象に限定せず、棟あたりの入居率、すなわち、そのオーナーの所有に係る物件識別で表わされる物件の棟全体の入居戸数データの値／販売戸数データの値で算出される。つまり、図９の入退去情報から得られる入居率がここでは用いられる。
【００５１】
勿論、サブリースパターンはこれに限定されるものではなく、単に保証料率のみを適用するパターン等も適宜採用することができる。例えば分配比率をなくして保証料率のみで計算する場合でも、本実施形態の基本的な作用効果は変わらない。
【００５２】
図３の売買申込受付手段１３は、仲介端末２から図４のように特定の物件情報（図では物件識別Ａ０７０３６）を表示した状態で操作部ａが操作されることにより起動する。そして、物件情報データベースＤＢ１の購入申込の残り戸数を参照して、残り戸数ありと判断すれば図１０に示すような入力フォームを物件情報データベースＤＢ１から取り出して表示する。この入力フォームは、物件識別、申込者氏名入力欄、ＩＤ入力欄（若しくは新規選択欄）によって物件と申込者とを関連づけた上で、購入のための入力欄として、一戸購入か分割購入かの種別の選択欄（分割購入の場合にはその口数入力欄）、物件価格、サブリースパターンの選択欄、ローンを利用するかしないかの選択欄からなる。ローン利用を選択した場合には、借入金入力欄および借入期間入力欄への入力を求め、金利が付帯表示されている。この金利は前述したルックアップあるいはフェッチ機能による。また、このフォームには入居のための入力欄が付帯していて、入居を希望するか否かの選択欄が用意されており、後に述べる入退居申込受付手段１４の入居申込フォームを兼ねている。
【００５３】
なお、ここにおいてもローン情報やサブリース情報を紹介できるように、ローン情報照会操作部ｄやサブリース情報照会操作部ｅが設けられている。
【００５４】
仲介端末２から入力フォームのうち購入に関する所定欄に入力がされて下段の申込に係る操作部ｆが操作され、サーバ１が入力情報を受信すると、その内容の一部は図３及び図８に示すオーナー情報データベースＤＢ６のオーナー情報に記憶される。このオーナー情報は、前述したように氏名、ＩＤ，ステータス、物件識別、種別、サブリースパターン、個別ローン識別、入居有無のレコードからなり、入力情報のうちの氏名、ＩＤ、物件識別などは入力フォームの値がそのまま反映され、新規の場合にはＩＤが発行される。申込時のステータスは「購入申込」であり、図３及び図４に示す物件情報データベースＤＢ１の現購入申込数（登録数）データがインクリメントされ、残り数がデクリメントされる。ローン申込の内容は購入申込に伴って或いは事前に、サーバ１から図１の金融機関情報処理装置５に送信され、審査結果が金融機関情報処理装置５からサーバ１に送信され、承認のあったものについてはその内容（借入額、返済期間、金利など少なくとも月々の返済額を算出するために必要なデータ）がオーナー情報データベースＤＢ６に設けたオーナー情報の個別ローン識別欄に入力される。詳細はこの個別ローン識別に関連づけられたローン情報データベースＤＢ３の個別ローンレコード等に記憶される。
【００５５】
売買契約が完了し、管理者端末１ａからの入力によりオーナー情報データベースＤＢ６のステータス（図８参照）が「オーナー登録」に切り替えられると、システム上において申込者は正式なオーナとなる。申込から一定期間内に管理者端末１ａから「オーナー登録」への切替手続が行われない場合には、申込はキャンセルされ、図３及び図４に示す物件情報データベースＤＢ１の現購入申込数（登録数）データがデクリメントされ、残り数がインクリメントされる。これには、申込ごとに申込識別を付しておき、キャンセル処理のルーチンとして実行するようにしてもよい。
【００５６】
図１２は、売買申込受付手段１３において実行される一手順を示すフローであって、予め定めた戸数に対する分譲を１戸単位で受け付ける場合と分割分譲を受け付ける場合とを処理するルーチンである。一の物件識別で表わされる物件について、一戸購入か否かを判断し（Ｓ１）、一戸購入の申込に対しては残り戸数があるか否かについて残りデータを判断し（Ｓ２）、残り戸数があると判断した場合には申込を受け付けて図８のオーナー情報に記憶し（Ｓ３）、図４の現購入申込（登録）戸数をインクリメントし、残り戸数をデクリメントして処理を終える（Ｓ４）。Ｓ２で残り戸数がないと判断すれば申込受付終了の旨等を返して終了する。一方、一戸購入でない場合は、分割購入申込か否かを判断し（Ｓ５）、分割購入の申込に対しては残り口数が要求口数を充足するか否かを判断し（Ｓ６）、残り口数があると判断した場合には申込を受け付けて図８のオーナー情報に記憶し（Ｓ７）、図４の現申込（口数）口数を口数分だけインクリメントし、残り口数をデクリメントして処理を終える（Ｓ８）。Ｓ６で残り口数がないと判断した場合には、更に、戸売に残りがあるか否かを参照し（Ｓ９）、残りがあると判断すれば申込を受け付けて図８のオーナー情報に記憶（Ｓ１０）するとともに、図４の残り戸数をデクリメントして残り分割口数をインクリメントし（つまり、この実施形態では戸売の１戸を減じて分割売りの残り口数に８／８を加え）（Ｓ１１）、更にその現申込（登録）口数を口数分だけインクリメントし残り口数をデクリメントして処理を終える（Ｓ１２）。Ｓ９で残り口数がないと判断すれば申込受付終了の旨を返して終了する。
【００５７】
なお、物件の売却の場合には、物件識別または入居者ＩＤを用いて仲介端末２から売却の申込をするための図示しないフォームがオーナー情報データベースＤＢ６に記憶されており、仲介端末２から売却申込を受信すると、売買申込受付手段１３はオーナー情報データベースＤＢ６から図８のレコードにおいて一致するデータを取り出して表示した上で、売却をするか否かの決定のための入力又は選択を求める。仲介端末２においてかかる入力又は選択がされると、オーナー情報データベースＤＢ６のオーナー情報に売却申込のステータスが記憶される。申込後に売却契約が完了し、管理者端末１ａからの入力によりオーナー情報データベースＤＢ６のステータス（図８参照）が売却登録に切り替えられると、システム上において申込者は正式にオーナーの資格を喪失し、物件情報データベースＤＢ１の現申込（登録）数（図３及び図４参照）がデクリメントされる。申込から一定期間内に管理者端末１ａから「登録」への切替手続が行われない場合の取り扱いは前記と同様である。
【００５８】
なお、本実施形態では、売却申込に際して買取保証額Ｚ（例えば１００万）が設定されており、オーナー情報や物件情報等から必要なデータを取り出して物件の査定を行うプログラムと、個別ローンレコードからローン残高を取り出して査定額−Ｚ≧ローン残高となる場合に上記売却申込を受け付けるプログラムとが備わっている。勿論、ローンがなければ、査定額−Ｚ≧０である。これにより、売却がスムーズに行われ、購入時も安心して物件を購入できるようになる。上記の条件を満たさない場合には、個別的に入金等によって条件を満たす旨の返答をサーバ１から申込端末２に返すようにしてもよい。
【００５９】
一方、図３の入退去申込受付手段１４は、仲介端末２から図４のように特定の物件を表示した状態で操作部ｂが操作されることにより起動する。そして、物件情報データベースＤＢ１の入居申込の残り戸数を参照して、残り戸数ありと判断すれば図１０の入力フォームを表示する。この入力フォームは前述したように購入申込のための入力フォームを兼ねている。申込のみの入力をする場合には、物件識別、申込者氏名入力欄、ＩＤ入力欄（若しくは新規選択欄）によって物件と申込者とを関連づけた上で、入居のための入力欄において所定の選択をなす。入居のみの申込の場合には購入に関する欄は空欄でよい。
【００６０】
仲介端末２から申込に係る操作部ｆを操作し、サーバ１が入力フォームの申込情報を受信すると、その内容の一部は図３及び図９に示す入退去情報データベースＤＢ７の入退去情報として記憶される。この入退去情報は、前述したように、氏名、ＩＤ（ＩＤを有していない場合には新規を選択），ステータス、物件識別、入居日、退去日、オーナー登録有無のレコードからなり、入力情報のうちの氏名、ＩＤ、物件識別などは入力フォームの値がそのまま反映され、新規の場合にはＩＤが発行される。申込時のステータスは「入居申込」であり、物件情報データベースＤＢ１の現入居申込（登録）数データ（図３及び図４参照）がインクリメントされ、残り数がデクリメントされる。申込後に入居契約が完了し、管理者端末１ａからの入力により入退去情報データベースＤＢ７のステータス（図９参照）が「入居者登録」に切り替えられると、システム上において申込者は正式に入居者となる。
【００６１】
退去の場合は、図示しないフォームにおいて物件識別または入居者（ＩＤなど）を特定して退去申込があると、入退去申込受付手段１４はオーナー情報データベースＤＢから該当レコードを取り出して表示し、退去申込をするか否かの決定のための入力又は選択を求める。仲介端末２においてかかる入力又は選択がされると、物件情報データベースＤＢ１とオーナー情報データベースＤＢ６にそのステータス「退去申込」が記憶される（図９参照）。申込後に退去契約が完了し、管理者端末１ａからの入力により入退去情報データベースＤＢ７のステータスが登録に切り替えられると、システム上において申込者は正式に退去者となる。
【００６２】
これらにおいて、申込から一定期間内に管理者端末１ａから「入居者登録」への切替手続が行われない場合の取り扱いは、購入や売却時の申込におけると同様である。
【００６３】
つまり、このシステムは、一旦完売し満室となった後においても、引き続き売買や入退去に関する取引を支援すべく稼動することができるものとなっている。
【００６４】
なお、一の物件識別に対して、一の申込者（ＩＤ）が購入申込と入居申込とをした場合には、売買申込受付手段１３による図８のオーナー情報に対するレコード生成と、入退去申込手段１４による図９の入退去情報に対するレコード生成とが並存する状態となる。このとき、図８のオーナー情報の入居の欄に「有」等を表わすフラグを立て、図９の入退去情報のオーナー登録の欄にも「有」等を表わすフラグを立てる処理が行われる。また、別々のアクセスによって同一の申込者が同一の物件に対して購入申込と入居申込をする場合に備えて、申込受付手段１３、１４は申込の受付時に一の物件（物件識別）に対して氏名やＩＤを手掛かりに既に登録された情報が無いかを検索し、一致するレコードがあれば、入退去情報やオーナー情報における該当レコードの入居やオーナー登録の欄に「有」を表わすフラグを立てる。勿論、先に氏名やＩＤを入力して検索を実行し、これにより一致するレコードの入力情報を含む申込時のフォームを再表示させて、そこに購入申込や入居申込のための入力を加えるようにしてもよい。
【００６５】
図１１は以上の処理手順の概略を示したフローである。申込があると、サーバは購入申込か否を判断し（Ｓａ）、また入居か否を判断して（Ｓｂ）、双方ともＹＥＳであれば購入申込と入居申込を受け付けて、オーナー情報と入退去情報の新しいレコードに入力情報を記憶し対応箇所に上述したフラグを立てるフラグ処理をして終了する（Ｓｃ）。購入申込のみであると判断した場合（Ｓｂ）には、オーナー情報の新しいレコードに入力情報を記憶するとともに、既に同一物件識別に対して同一ＩＤで入退去情報にレコードが存在しないかを検索し、存在すればオーナー情報と入退去情報の対応箇所に既述したフラグを立てるフラグ処理を施して終了する（Ｓｄ）。また、入居申込のみであると判断した場合（Ｓｅ）場合には、入居申込を受け付けて、入退去情報の新しいレコードに入力情報を記憶するとともに、既に同一物件識別に対して同一ＩＤでオーナー情報にレコードが存在しないかを検索し、ＹＥＳであればオーナー情報と入退去情報の対応箇所に既述したフラグを立てるフラグ処理を施して終了する（Ｓｆ）。以上の何れでもないと判断した場合（Ｓｅ）には、そのまま終了する。
【００６６】
なお、購入申込者と入居申込者の一致・不一致が判断できる状態にある限り、申込の受付時には前記フラグは立てず、正式に契約が成立してオーナー登録や入居者登録がされる時点で上記フラグを立てるようにしてもよい。
【００６７】
図３のシミュレーション受付手段１５は、仲介端末２から図１０の入力フォーム上に設けてある操作部ｃを操作して収支シミュレーションの照会があると起動する。そして、収支情報データベースＤＢから図７に示すフォームを取り出してＷｅｂページ上に表示する。このフォームが呼び出されるとき、図１０のフォームに入力されている当該物件識別の家賃額、サブリースパターン、借入額、借入期間、金利等に関するデータが反映され、また、ローン利用の場合にはローン情報データベースＤＢ３から返済額等の値を取り出して表示する。家賃収入は入居率に応じて変動し、入居率には想定入居率としてサンプル値が用いられ、入居率ごとの家賃収入をサブリース情報データベースＤＢ２から得て、これら家賃収入、ローン返済、家賃支払並びにこれらの収支額を入居率ごとに表示する。
【００６８】
図示例は購入と同時に入居を選択した場合のシミュレーションであり、入居しない場合には家賃支払は０である。また、ローンを利用していない場合には、ローン返済額は０である。分譲分割の場合は分割数で家賃収入を除した値が割り当てられる。例えば１／８の場合には、家賃収入は単純に考えれば１／８になる。図においては、家賃６万、金利２．５％、２５年ローンで借入額８００万であり、サブリースパターンが１であるため、例えば入居率が７０％のところでは、家賃収入が４．２万、ローン返済額が３．６万、家賃支払が６万で、収支が−５．４万となり、入居率が１００％のところでは、家賃収入が５．２万、ローン返済額が３．６万、家賃支払が６万で、収支が−４．１万となり、何れも単に物件を借りて家賃５．４万を払って住むよりも、オーナーになってローンを返済しながら尚且つ家賃を払って入居する方が、０．６万〜１．９万程度得策であることが読み取れる。
【００６９】
これは、オーナーが自ら入居する場合を想定したシステム構築上の特徴と、家賃収入及び家賃支払を同時に含む収支計算を即時に行うというシステム上の特徴とが相俟って得られる効果である。しかも、２５年間払い終えれば、物件は完全に自分のものになる仕組みが明確に理解される。勿論、入居しなければ家賃支払の欄が空欄となり、全体として＋０．６万〜１．９万の利益が出て、年６％前後の投資利回りが見込める計算となっている。さらにローンを組まなければ、４．２万〜５．５万が丸々収益となる。この図７の画面は、図４において収支シミュレーション操作部ｃを操作した際にも表示される。図１０の入力フォームを経由しない場合、借入額や借入期間、サブリースパターンなどはこの図７で入力することとなる。逆に、この図１０の入力フォームにも、ローン情報を参照するための操作部ｄ、サブリース情報を参照するための操作部ｅが設けてある。
【００７０】
図３の収支照会手段１６は、オーナー登録後に、仲介端末２を介して或いは自身のオーナー端末３からサーバ１にアクセスして、ＩＤ等の提示とともに適宜箇所に設けられたメニューや操作部等を通じて収支照会をなすことにより、起動する。そして、オーナー情報データベースＤＢ６から図８に示すオーナー情報を取り出し、これに含まれる物件識別から家賃額の値（分割所有の場合には、（所有口数／分割数）を乗じた値）を得て、入居のフラグが立っている場合にはこれを家賃支払額にするとともに、サブリースパターンに基づきサブリース情報データベースから取り出した算出式に入退出情報データベースＤＢ７から取り出した期間ごとの入居率をあてはめて家賃収入額を算出し、さらにローンがある場合には個別ローンレコードから返済額を取り出して、これらの収支を期間ごとに図１４に示す実収支データとして出力する。図においては、月ごとの入居率と、それに基づく収支の履歴が表示されており、入居率が高くなるにつれて収支が変動していることが一目瞭然である。このようなプログラムは、適宜のデータベース等に予め記憶されている。かかる収支データによれば、過去の収支は勿論のこと、直近の基準時の入居率に基づく最も近い将来の決済時（例えば翌月）の収支データも得ることができる。
【００７１】
図１３は、同システム全体の流れを示す図である。物件検索から、物件閲覧、収支シュミレーション、ローン情報、サブリース情報を随意に閲覧することができ、売買申込や入退去申込を経て、オーナー情報や入退去情報が記憶され、物件情報ひいては物件閲覧に反映される。
【００７２】
以上のように、本実施形態の不動産取引支援システムは、サーバ１と、サーバ１に電子通信手段ＮＷを介して接続される複数の仲介端末２とを具備し、サーバ１に登録されている分譲賃貸物件に関する情報を閲覧に供して仲介端末２から少なくとも購入および入居のための申込手続を受け付けるシステムを構築するものである。そして、サーバ１が、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける購入申込受付手段たる売買申込受付手段１３と、入居の申込手続を受け付ける入居申込受付手段たる入退去申込受付手段１４とを有し、これらの受付手段１３，１４は一の物件識別で特定される物件に対する購入、入居の両申込手続を並列に受け付けて、申込に係る情報の少なくとも一部を物件識別と関連づけて記憶手段であるオーナー情報データベースＤＢ６や入退去情報データベースＤＢ７に記憶し得るようにしたものである。
【００７３】
このように、仲介端末２から分譲、入居の何れの申込が先にあってもその申込の受付を行い得るので、分譲賃貸の売買取引と賃貸取引の双方の業務を１本化して、先に購入申込が先行しても逆に入居申込が先行しても同じ網で同時進行することができ、これにより仲介業者の業務効率を格段に向上させるとともに、売買や賃貸借の促進を通じて不動産取引の活性化を図ることができる。
【００７４】
この場合、サーバ１の閲覧受付手段１２は、仲介端末２から閲覧可能なＷｅｂサイトにおいて、図４に示すように購入申込のために利用可能な操作部ａと入居申込のために利用可能な操作部ｂとを、それらの物件購入情報および物件入居情報とともに同一画面上に表示して、一の仲介端末２からのアクセスに対して、購入、入居何れの情報をも閲覧可能、また購入、入居何れの操作部ａ、ｂによる申込に対してもその受け付けを行い得るようにしているので、並列的な処理が簡単に行え、また顧客に両情報を同時に提供することができることにより、顧客にとっても不動産を購入するか賃貸で借りるかの選択の機会に恵まれ易くなる。
【００７５】
特に、サーバ１の閲覧受付手段１２は、購入申込及び入居申込に係る状況が把握できるデータを図４のような画面上に表示して所定のタイミングで更新するようにしているので、急速に販売残り戸数が減って人気物件であるといった状況や、入居が先行して安心して投資できる物件であるといった状況など、その不動産物件に関する客観的な評価材料を得て、購入や入居の申込の判断に利用することができる。
【００７６】
一方、本実施形態の不動産取引支援システムは、登録された分譲賃貸物件に対して、サブリースを前提とした購入の申込手続を受け付ける売買申込受付手段１３と、入居の申込手続を受け付ける入退去申込受付手段１４とが一の物件識別で特定される物件に対する購入申込と入居申込とを同時に又は相前後して受け付ける場合に、少なくとも購入申込に係る情報のうちの申込者情報と入居申込に係る情報のうちの申込者情報とが一致しているか否かによらずに申込を受け付けて、一致している場合にその旨が判断できる状態で申込に係る情報の少なくとも一部を記憶手段であるオーナー情報データベースＤＢ６や入退去情報データベースＤ７に記憶し得るようにしたものである。
【００７７】
このように、本システムはオーナー自らが賃借人として入居するという新しい態様をも可能にするものであり、顧客も不動産を購入するか賃貸で借りるか、更にはオーナーとなって自ら賃貸人として入居するかの選択の幅が広がり、賃借人がオーナーとなる機会を有効に創出することができる上に、オーナー自らが入居する場合にも単に賃借を続ける場合に比して有利な収支決済が期待でき、また退去してもオーナーの地位は維持されて物件はそのまま賃貸物件として利用に供されるため、転居の多い者にとっては煩わしい手続が不要になり、非常に便利なシステムとして利用に供することができる。そして、本システムによれば、サーバ１上でこれらを適切に管理することができるものである。
【００７８】
この場合サーバ１は、仲介端末２から閲覧可能なＷｅｂサイト上において、申込者情報の入力とともに、購入か入居か何れか一方の種別を選択しまたは両種別を同時に選択できる図１０の入力フォームを表示して、その選択した種別の申込を申込者情報と関連づけて受け付け得るようにしているので、これによっても顧客が不動産を購入するか賃貸で借りるかの選択の機会に恵まれ易くなり、購入と同時に入居するという本発明特有の態様によって借家人に持家となる機会もより一層与え易くなる。
【００７９】
そして、サーバ１の売買申込受付手段１３が、一戸を分割して一又は複数口の分割分譲の購入申込を受け付け、これに伴い一の物件識別に複数の申込者情報を関連づけてオーナー情報に記憶し、さらに、一の申込者情報に分割申込口数を関連づけてオーナー情報に記憶し得るようにしている。すなわち、一戸を分割して一又は複数口の分割分譲の購入申込を受け付け得るものであるので、上記の例では一口１００万円という小額になり、ローン限度額に応じた口数の申込なども可能になるため、一般投資家が投資し易い額になり、不動産売買の活性化が図れるとともに、本来なら物件購入が難しい層にも一部オーナーとなって少しでも借家人の地位を返上する機会を与え易くなる。
【００８０】
この場合、戸数や口数管理をネット上でほぼリアルタイムに行い、予め定めた戸数を分割募集と一戸単位募集でとりあっていくので、何れか一方が先に満杯になり他方が売れ残るといった不都合もなく、効率の良い申込の受付を行うことが可能になる。
【００８１】
さらに、サーバ１が、物件識別に関連づけて、サブリース条件に基づき家賃収入額を計算するための情報、ローン条件に基づいて返済額を計算するための情報、入居に必要な家賃支払額の情報をサブリース情報データベースＤＢ２やローン情報データベースＤＢ３、物件情報データベースＤＢ１などに記憶しており、仲介端末２から物件を特定してサブリース条件やローン条件、入居の有無など上記計算に必要なデータを提示した収支シミュレーションの要求があった場合に、サーバ１は前記情報の全部又は一部を取り出して図７に示すように家賃収入額、ローン返済額、家賃支払額のうちの対応する額とともにこれらの収支額からなる収支シミュレーションデータを生成、表示可能としているので、不動産投資をする場合や、購入するか借家するか、或いは購入して借家するかなどの選択、決定に役立つ情報を的確に得ることができる。
【００８２】
この場合、サブリース条件が、入居率に基づき家賃収入額が変動するように規定されており、サーバ１は想定入居率とともに収支シミュレーションデータを生成、表示可能としているので、利回りや安定性などの判断に資する判断材料をより的確に与えることができ、購入者はそれを見ながら適切にサブリース契約を結ぶことができる。特に、ここでは複数のサブリースパターンが備わり、そのパターンごとのシミュレーションが可能であるため、より目的に沿った適切なサブリース契約を選択することが可能となる。
【００８３】
さらにまた、サーバ１が、サブリース条件に基づき家賃収入額を計算するための情報、ローン条件に基づいて返済額を計算するための情報、入居に必要な家賃支払額の情報をサブリース情報データベースＤＢ２やローン情報データベースＤＢ３、物件情報データベースＤＢ１などに記憶し、さらに、物件識別、サブリース条件、ローン条件、入居の有無など上記計算に必要な実際のデータが含まれたオーナー情報をオーナー情報データベースＤＢ６記憶しており、サーバ１に電子通信手段ＮＷを介して接続したオーナー端末３からオーナー情報に基づいた実収支の要求があった場合に、サーバ１は、前記各情報の全部又は一部を取り出して図１４に示すように家賃収入額、返済額、家賃支払額のうちの対応する額とともにこれらの収支額からなる実収支データを生成、表示可能としているので、オーナーとなった後の財産管理を、上記システムにおいて適切に行うことができる。
【００８４】
この場合、サブリース条件が、物件識別で特定される物件に含まれる戸の全部又は一部にわたる平均入居率に基づき家賃収入額が変動するように規定されたものであり、サーバ１は、物件識別と関連づけて入退去情報を入退去情報データベースＤＢ７に記憶していて、オーナー端末３から要求があった際に、この入退去情報に基づき予め定めた期間ごとの平均入居率を算出して、期間ごとの実収支データを生成、表示可能としているので、収支の推移を的確に把握して、その後の収益処分の判断に利用することができる。
【００８５】
より具体的には、サーバ１が、登録後にも図７の場合と同様に購入価格の情報、家賃収入額を計算するための情報、ローン返済額を計算するための情報、家賃支払額を計算するための情報、またはこれらの履歴情報を蓄積しており、仲介端末２又はオーナー端末３からの入力情報に基づいて、サーバ１がこれらの情報の全部又は一部を取り出して収支予測データ又は収支履歴データを表示可能としているので、利回りや安定性などの運用実績に関する情報をより適切に提供することが可能となる。
【００８６】
以上を総括すると、このシステムの仲介端末は、全国に事業展開している既存の賃貸仲介業者等の店舗に設置されることが有効であり、何れの仲介端末２からも管理システムのサーバ１へ自由にアクセスすることができる。そして、登録されている分譲サブリース物件に関する家賃の照会、それが販売中物件である場合の販売価格や収支シミュレーションの照会、分割分譲や入居・退去の申込、ローン照会のほか、正式に登録された後は、オーナー情報の照会・登録・変更・削除、入居状況（入居率）照会などを行うことができる。
【００８７】
そして、賃貸物件探しに訪れた顧客に対して、賃貸物件の紹介もできるし、それが販売中の物件である場合には物件購入の情報も顧客に同時に提供することができる。この実施形態では、部屋を借りて入居する場合と、その部屋を購入し自身で住んで家賃支払とともに家賃収入を得る場合とを表示させて、両者の利害得失を比較可能とし、入居申込または購入申込を比較考量して最適のパターンを選択できるようにしている。前者よりも後者の方が収支としてプラスになり、安い家賃で住んで払い終われば物件が自分のものになるプランが用意されれば、借家人からオーナーに切り替えるものも多数出てくるものと考えられる。逆に、不動産投資に訪れた顧客は、入居が先行していれば安心してサブリース契約ができるし、小口の分割分譲も前向きに検討することができる。
【００８８】
また、このシステムは、オーナー端末３から管理システムのサーバ１へのアクセスも一部において可能であり、（契約後の）オーナー情報の照会、入居状況（入居率）照会、収支照会などを行うことができる。
【００８９】
或いは、契約したサブリースパターンの確認や、現在又は過去の入居状況の照会、収支がどのようになっているかの確認を行うことができる。
【００９０】
さらに、分譲希望者や入居希望者などは、サーバ１と電子通信手段ＮＷを介して接続されている一般端末を利用して、登録されている分譲サブリース物件に関する家賃の照会、それが販売中物件である場合の販売価格や収支シミュレーションの照会、入居状況（入居率）照会などを行うことができる。勿論、オーナー端末３は一般端末としても使用可能である。
【００９１】
そして、以上のシステムにおいて、投資家のメリットとしては、家賃保証による投資の安全性が確保され、分割分譲も購入可能であるため少ない自己資金での投資も可能となり、分割分譲の場合にはローンも通り易いというメリットがあり、物件管理をサーバ１を運営する管理者が行えばオーナーとなった者は管理の必要がなく、買取保証が付いているため物件の処分もし易いというメリットを享受することができる。
【００９２】
また、仲介業者にとっては、サブリースを前提とした新築分譲物件がサーバにアップされている場合に、オーナーと入居者の募集を同時に開始することができ、賃貸の入居希望者が収支のシミュレーションなどを参考にして物件購入に切り替われば、仲介手数料は賃貸契約から売買契約へと跳ね上がり、ローン申込をその場で可能とすれば手続きもより迅速となり、分割分譲の場合にローンが通り易くなる点もメリットとなる。
【００９３】
さらに、サーバ１を運営する管理者にとっては、広域に展開している既存の不動産業者を仲介者とすることで新たな販路や店舗を設ける必要がなく、管理による管理費が期待でき、土地を購入して物件を立てて販売するまでを自らが行えば、それによる利益も追求できることになる。
【００９４】
以上、本発明の一実施形態について説明したが、各部の具体的な構成は、上述した実施形態のみに限定されるものではない。
【００９５】
例えば、サーバが購入募集と入居募集とを並行して同時進行で行えるという観点のみからすれば、必ずしも同一人に購入申込と入居申込の双方を認める態様を含む必要はなく、オーナーと入居者は完全に別であってもよい。
【００９６】
また、同一人に購入申込と入居申込の双方を認めるという観点のみからすれば、必ずしも購入募集と入居募集とを並行して同時進行で行わなくてもよく、購入募集が終わってから入居募集を開始すること等を妨げない。
【００９７】
さらに、一戸単位あるいは分割した口数単位の分譲後の家賃計算において、入居率を棟全体から算出するという観点のみからすれば、購入募集と入居募集とを並行して行うか否か、或いは、同一人に購入と入居を認めるか否かは問題とならない。
【００９８】
さらにまた、サブリースを前提とした分譲の申込に際し、一戸を分割して一又は複数口の分割分譲の購入申込を受け付ける観点のみからすれば、購入募集と入居募集とを並行して行うか否か、同一人に購入と入居を認めるか否か、或いは入居率をどのように算出するかは問わない。この場合、一戸単位の購入と分割した口ごとの購入とを同時進行させるために、図１２に示したように購入申込に対して分割口数の残りがない場合に一戸を逐次分解していく手法に限らず、一戸販売個数ｍと分割販売個数ｎを同時にカウントしていってトータルで総販売戸数ｍ＋ｎ／ｄ（ｄは分割数）が予定個数を超えたか否かを判断する手法や、予めｍとｎを固定にする手法などを採用することも可能である。
【００９９】
１つの物件において、１棟を構成する戸（部屋）に幾つかの異なるタイプ（販売価格帯や入居価格帯が異なるタイプ）が存在する場合には、タイプ別に物件識別（例えばＡ０７０３６−１、Ａ０７０３６−２など）を付して、タイプごとに購入募集戸数や入居募集戸数などを表示して選択、申込受付できるようにしてもよい。この場合、オーナー情報や入退去情報は、タイプ別の物件識別と関連づけて記憶すればよい。勿論、この場合にも入居率を棟全体で算出する場合には、上記のように棟全体を表わす上位の物件識別（Ａ０７０３６）が関連づけられていることが望ましい。このようにしても、購入申込と入居申込とを同時進行で受け付ける態様や、オーナーと入居者が同一人となる申込を受け付ける態様等は、前記実施形態と全く同様に行うことができる。極端な場合、１棟を構成する戸（部屋）の販売価格帯や入居価格帯が個々に異なる場合であっても本発明を適用することはできる。この場合にも、入居率は平均値である。ただし、入居率は常に１棟に含まれる全戸数に対して入居数／全戸数とする必要はなく、例外的に入居率に基づかない戸があれば、それを除いて入居数／戸数とすべく、予め入居率の算定の対象となる物件識別を特定しておいてもよい。或いは、複数の棟にまたがって入居数／戸数を計算する態様の場合には、更に上位の物件識別（例えばＡ０７など）に基づくこと等も可能である。
【０１００】
本発明に言う物件識別は、広義には棟全体を、狭義には戸を、中間的にはタイプ別の各タイプを指称する。
【０１０１】
仲介業者等の使用に係る申込端末は、必ずしも仲介業者の使用に係るものに限定されるものではなく、広域に端末が存在していれば他の端末であってもよい。例えば、管理会社自身が広域に端末を有している場合には、管理会社の使用に係る端末を使用することもできる。或いは、大規模の売買サイトにおいて上記の購入申込や入居申込を受け付ける場合には、サーバはそのようなサイトの使用に係るものであってよく、この場合の仲介端末は、Ｗｅｂを介して接続可能な端末であれば全てこれに該当し得る。ただし、会員制などにして、アクセスを取引に信憑性の得られる者に制限すること等が有効であるのは勿論である。この場合、申込を受け付けた後の登録は、申込者が仲介業者を介して不動産会社と、或いは直接に不動産会社と契約することによりサーバに反映させればよい。
【０１０２】
その他、上記の取引支援システムを中古物件に適用するなど、本発明の趣旨を逸脱しない範囲で種々変形が可能である。
【０１０３】
例えば、購入申込や入居申込を並列的に受け付け、或いは同一人であっても受け付けるという場合に、所要の要件を満たさない申込を拒否する等の対応を排除するものではない。
【０１０４】
また、購入申込受付手段と入居申込受付手段は、機能的に分けているだけであって、これらを総括して受け付ける受付手段としてもよいのは勿論である。
【０１０５】
更に、データベースの構成なども、例えばオーナー情報データベースと入退去情報データベースを統合して顧客データベース等とするなど、種々の態様で実施することができる。
【図面の簡単な説明】
【０１０６】
【図１】本発明の一実施形態に係る不動産取引支援システムのシステム構成図。
【図２】図１におけるサーバのハードウェア構成図。
【図３】同サーバが有する機能手段を示す図。
【図４】同サーバが提示する物件情報の内容を示す図。
【図５】同サーバが提示するサブリースパターンの内容を示す図。
【図６】同サーバが提示するローン情報の内容を示す図。
【図７】同サーバが提示する収支シミュレーションの内容を示す図。
【図８】同サーバが記憶するオーナー情報の内容を示す図。
【図９】同サーバが記憶する入退去情報の内容を示す図。
【図１０】同サーバが提示する入力フォームの内容を示す図。
【図１１】同サーバが購入申込と入居申込を処理する際の手順の概要を示すフローチャート。
【図１２】同サーバが一戸購入の申込と分割購入の申込とを処理する際の手順の概要を示すフローチャート。
【図１３】同システム全体の流れを示す図。
【図１４】同サーバが提示する実収支の内容を示す図。
【符号の説明】
【０１０７】
１…サーバ
２…申込端末（仲介端末）
３…紹介端末（オーナー端末）
１３…購入申込受付手段（売買申込受付手段）
１４…入居申込受付手段（入退去申込受付手段）
ＮＷ…電子通信手段
【図１】
2009129129.tif 000003
【図２】
2009129129.tif 000004
【図３】
2009129129.tif 000005
【図４】
2009129129.tif 000006
【図５】
2009129129.tif 000007
【図６】
2009129129.tif 000008
【図７】
2009129129.tif 000009
【図８】
2009129129.tif 000010
【図９】
2009129129.tif 000011
【図１０】
2009129129.tif 000012
【図１１】
2009129129.tif 000013
【図１２】
2009129129.tif 000014
【図１３】
2009129129.tif 000015
【図１４】
2009129129.tif 000016