JP6989725B1 - 住戸販売用抽選プログラムおよび住戸販売用抽選方法 - Google Patents

Abstract

【課題】購入希望者が住戸物件の応募をしやすくすると共に、物件販売者が煩雑な手続きを回避できる住戸販売用抽選プログラム等を提供する。【解決手段】住戸販売用抽選プログラムは、販売対象となる住戸に関する住戸情報を提供する住戸情報提供ステップと、住戸の購入を希望する申請を受け付ける申請受付ステップと、申請が受け付けられた応募者の中から購入候補者を抽選する抽選ステップと、購入候補者が入力した審査情報を取得する審査情報取得ステップと、審査情報に基づいて購入候補者へ購入権を付与するか否かの審査を行う審査ステップと、審査ステップで購入権を付与すると決定した場合に、購入候補者へ購入手続に関する案内を通知する通知ステップと、審査ステップで購入権を付与しないと決定した場合に、購入候補者を除いた応募者を対象として抽選ステップから再度実行させる制御ステップとをコンピュータに実行させる。【選択図】図１４

Description

本発明は、住戸販売用抽選プログラムおよび住戸販売用抽選方法に関する。

住戸販売の分野にもコンピュータによる処理やインターネットを活用したサービス提供が拡がりつつある。例えば、特許文献１によれば、住宅ローンの借入希望者に関する情報を入力すると、商品抽出システムが商品候補を決定して提供してくれる。

特許第６８３２０２６号公報

ある住戸物件を販売する場合に、期限を区切って購入希望を受け付け、抽選を実施して購入者を決定するプロセスを経る場合がある。これまでは、購入希望者は、まず物件を確認し、資金面等における審査を受け、購入能力が確認された後に抽選への応募が認められていた。このような手順は、購入希望者にとっても物件販売者にとっても手間や時間がかかる。すなわち、購入希望者からすれば、煩雑な審査を通過したにもかかわらず落選してしまう場合もあり、また、物件販売者からすれば、購入希望者全員の審査を行わなければならなかった。

本発明は、このような問題を解決するためになされたものであり、購入希望者が住戸物件の応募をしやすくすると共に、物件販売者が煩雑な手続きを回避できる住戸販売用抽選プログラム等を提供するものである。

本発明の第１の態様における住戸販売用抽選プログラムは、販売対象となる住戸に関する住戸情報を提供する住戸情報提供ステップと、住戸の購入を希望する申請を受け付ける申請受付ステップと、申請が受け付けられた応募者の中から購入候補者を抽選する抽選ステップと、購入候補者が入力した審査情報を取得する審査情報取得ステップと、審査情報に基づいて購入候補者へ購入権を付与するか否かの審査を行う審査ステップと、審査ステップで購入権を付与すると決定した場合に、購入候補者へ購入手続に関する案内を通知する通知ステップと、審査ステップで購入権を付与しないと決定した場合に、購入候補者を除いた応募者を対象として抽選ステップから再度実行させる制御ステップとをコンピュータに実行させる。

本発明の第２の態様における住戸販売用抽選方法は、コンピュータが、販売対象となる住戸に関する住戸情報を提供する住戸情報提供ステップと、コンピュータが、住戸の購入を希望する申請を受け付ける申請受付ステップと、コンピュータが、申請が受け付けられた応募者の中から購入候補者を抽選する抽選ステップと、コンピュータが、購入候補者が入力した審査情報を取得する審査情報取得ステップと、コンピュータが、審査情報に基づいて購入候補者へ購入権を付与するか否かの審査を行う審査ステップと、審査ステップで購入権を付与すると決定した場合に、コンピュータが、購入候補者へ購入手続に関する案内を通知する通知ステップと、審査ステップで購入権を付与しないと決定した場合に、コンピュータが、購入候補者を除いた応募者を対象として抽選ステップから再度実行させる制御ステップとを有する。

本発明により、購入希望者が住戸物件の応募をしやすくすると共に、物件販売者が煩雑な手続きを回避できる住戸販売用抽選プログラム等を提供することができる。

本実施形態に係る住戸販売用抽選プログラムが利用される環境を示す図である。 アプリサーバのハードウェア構成図である。 住戸情報を提供する提供画面の一例である。 購入希望を受け付ける受付画面の一例である。 個人情報の入力を受け付ける受付画面の一例である。 ユーザ登録情報から開示情報を選択する選択画面の一例である。 応募受付の確認画面の一例である。 応募者情報テーブルを模式的に示す図である。 当選を通知する結果通知画面の一例である。 落選を通知する結果通知画面の一例である。 再抽選に関する情報を通知する通知画面の一例である。 再募集に対する応募を受け付ける受付画面の一例である。 キャンセル待ち住戸の住戸情報を提供する提供画面の一例である。 アプリサーバによって処理される処理手順を示すフロー図である。

以下、発明の実施の形態を通じて本発明を説明するが、特許請求の範囲に係る発明を以下の実施形態に限定するものではない。また、実施形態で説明する構成の全てが課題を解決するための手段として必須であるとは限らない。

図１は、本実施形態に係る住戸販売用抽選プログラムが利用される環境を示す図である。本実施形態に係る住戸販売抽選プログラムは、住戸販売を行う販売会社のサーバであるアプリサーバ１００で実行される。アプリサーバ１００は、インターネット９００に接続され、インターネット９００を介して、アプリ利用者のスマートフォン等であるユーザ端末３００や外部サーバ２１０、２２０と情報の授受を行う。

ユーザは、自身のユーザ端末３００へインストールした物件購入アプリを介して、物件購入に関する様々なサービスの提供を受けることができる。アプリサーバ１００は、住戸販売抽選プログラムを含むサービス提供プログラムを実行することにより、ユーザ端末３００で実行される物件購入アプリと連携して、ユーザへ当該サービスを提供する。また、サービス提供プログラムの処理に応じて、アプリサーバ１００は、住戸物件の売主が管理する外部サーバ２１０や、住宅ローン会社が管理する外部サーバ２２０との間で情報の授受を行う。

なお、本実施形態においては、ユーザがスマートフォンにインストールした物件購入アプリを介してサービスの提供を受ける場合を想定するが、ユーザ端末３００は、スマートフォンに限らず、タブレット端末やＰＣなど他の情報端末であっても構わない。また、本実施形態においては、アプリサーバ１００から提供されるサービスを、アプリケーションプログラムである物件購入アプリを介して受ける場合を想定するが、ユーザ端末３００で実行されるプログラムは、アプリケーションプログラムの形式に限らず、ＷＥＢブラウザ上で実行されるプログラム等などであっても構わない。いずれにおいても、アプリサーバ１００で実行されるサービス提供プログラムは、ユーザ端末３００側で実行されるプログラムと連携することにより、ユーザに物件購入に関するサービスを提供する。なお、以下の説明においてはスマートフォンに表示される表示画面の例を用いるが、表示態様は、利用される情報端末や実行されるプログラムによって適宜変更される。

図２は、アプリサーバ１００のハードウェア構成図である。アプリサーバ１００は、主に、処理部１１０、記憶部１３０、通信部１４０、および入出力インタフェース１５０によって構成される。処理部１１０は、アプリサーバ１００の制御とプログラムの実行処理を行うプロセッサ（ＣＰＵ：Central Processing Unit）である。プロセッサは、ＡＳＩＣやＧＰＵ等の演算処理チップと連携する構成であってもよい。処理部１１０は、記憶部１３０に記憶された住戸販売用抽選プログラムを読み出して、住戸販売の抽選に関する様々な処理を実行する。

記憶部１３０は、不揮発性の記憶媒体であり、例えばＨＤＤ（Hard Disk Drive）によって構成されている。記憶部１３０は、アプリサーバ１００の制御や処理を実行するプログラムの他にも、制御や演算に用いられる種々のパラメータ等も記憶する。記憶部１３０は、特に、物件情報データベース１３１（以下、「物件情報ＤＢ１３１」と称する）、ユーザ情報データベース１３２（以下、「ユーザ情報ＤＢ１３２」と称する）、審査情報データベース１３３（以下、「審査情報ＤＢ１３３」と称する）を含む。

物件情報ＤＢ１３１には、売主が用意した販売住戸物件に関する物件情報（テキスト情報や画像情報等）が蓄積されている。物件情報は、売主が管理する外部サーバ２１０等から、通信部１４０を介して収集される。ユーザ情報ＤＢ１３２には、ユーザ端末３００で収集されるユーザ情報、個々のユーザにおける過去の抽選申込や物件売買の履歴情報等が蓄積されている。審査情報ＤＢ１３３には、後述する審査を行う場合に判断材料や基準となる審査情報が蓄積されている。例えば、住宅ローン会社が定める貸出基準を審査の一部として利用する場合には、当該貸出基準は、外部サーバ２２０から通信部１４０を介して収集される。

通信部１４０は、インターネット９００への接続およびユーザ端末３００、外部サーバ２１０、２２０との情報の授受を担い、例えばＬＡＮによって構成されている。通信部１４０は、処理部１１０の制御に従って、インターネット９００との間で指示コマンドや情報の授受を行う。入出力インタフェース１５０（以下、「入出力ＩＦ１５０」と称する）は、例えばキーボードやマウス等の入力デバイスや表示モニタ等の出力デバイスを含む。入出力ＩＦ１５０は、管理者が情報提供する住戸物件を更新したり、ユーザへ告知する内容を調整したりする場合に利用される。

次に、アプリサーバ１００で実行されるサービス提供プログラムによって提供される物件購入に関するサービスのうち、特に住戸販売用抽選プログラムによって提供される一連のサービスを、ユーザ端末３００に表示される表示画面の例を用いて順次説明する。表示画面には、ユーザの指示を受け付ける入力デバイスとしてタッチパネルが重畳されており、ユーザは、表示画面に対してタップ、スワイプ、ピンチ等の操作を行うことにより、選択や入力を行うことができる。

図３は、住戸情報を提供する提供画面の一例である。住戸販売用抽選プログラムは、各ユーザ端末３００からの要求に従って、販売対象となる住戸に関する住戸情報を提供する。ユーザ端末３００は、そのように提供された住戸情報を視認性良く配列して表示部に表示する。いずれの表示画面もおよそ、アプリロゴ３１０、表示タイトル３２０、告知情報３３０を含む。

アプリロゴ３１０は、サービスを提供するアプリを示すロゴである。ユーザはこのアプリロゴ３１０を視認することにより、住戸販売に関して一貫するサービスを受けられることを認識できる。表示タイトル３２０は、現在の表示画面がいずれのサービスに係る表示であるかを端的に示す文字情報である。ここでは、表示タイトル３２０は「部屋選択」であり、販売住戸としてのマンションの各部屋の中から閲覧する部屋を選択できる旨を表している。

告知情報３３０は、表示タイトル３２０に関してユーザに告知すべき情報であり、文字情報に限らず、イラスト、写真、音声、動画を含む場合もある。ここでは、告知情報３３０は、対象物件のマンション名である「リビオ東京」と共に、選択された物件の情報を表示する物件ウィンドウ３２２を含む。物件ウィンドウ３２２は、物件選択ボックス３２３で選択された「６０４号室」の情報を表示している。具体的には、６０４号室の間取図と、「１ＬＤＫ」等の部屋情報、販売価格を表示している。ユーザは、物件ウィンドウ３２２内をスワイプさせることにより、下方に配置された情報を表示させることができる。また、予め用意されたコンテンツに応じて、例えば間取図中の「洋室」をタップすると、洋室の写真や動画等を表示させることもできる。

ユーザは、タップ等により物件選択ボックス３２３を操作することにより、他の部屋を選択することができる。他の部屋が選択されたら、物件購入アプリは選択された部屋に関する住戸情報をアプリサーバ１００へ要求する。アプリサーバ１００の処理部１１０は、当該要求に応じて選択された住戸情報を物件情報ＤＢ１３１から読み出して送り返す。物件購入アプリは、アプリサーバ１００から送られてきた住戸情報を用いて物件ウィンドウ３２２を更新する。

物件ウィンドウ３２２内には、表示された物件（図においては「６０４号室」）の購入手続きへ移るための購入希望ボタン３２４が配置されている。ユーザが購入希望ボタン３２４をタップすると、住戸情報を提供する提供画面から購入希望を受け付ける受付画面へ表示が遷移する。

図４は、購入希望を受け付ける受付画面の一例である。特に対象物件が、期限を区切って購入希望を受け付けて抽選を実施する物件である場合に表示される受付画面である。対象物件が抽選を実施する物件でなく、例えば先着順の物件である場合には、購入手続きに関する案内を告知する受付画面が表示される。本実施形態においては、販売対象となる住戸物件が抽選を実施する物件である場合について説明する。

購入希望を受け付ける受付画面は、「購入希望」の表示タイトル３２０と、対象物件が抽選対象物件であること等を告知する告知情報３３０を含む。また、抽選に応募する意思表示を示すための応募ボタン３３１と、抽選に応募しない意思表示を示すためのキャンセルボタン３３２が配置されている。ユーザが、応募ボタン３３１をタップすると応募受付の確認画面へ遷移し、キャンセルボタン３３２をタップすると住戸情報の提供画面へ戻る。

従来の物件販売において、抽選を実施して購入者を決定するプロセスを経る場合には、物件販売者は、抽選希望者から購入希望と審査に関する書類を集め、抽選希望者の意思を確認し、資金面等における審査を行ってから抽選を実施していた。すなわち、イベント的に実施する抽選会を一度で済ませるために、抽選を受けられる対象者を購入能力が確認された購入希望者に限っていた。しかし、このようなプロセスを必要とする場合には、購入希望者からすれば、煩雑で手間のかかる審査を通過したにもかかわらず落選してしまう場合もあり、また、物件販売者からすれば、購入希望者全員の審査を行わなければならず、やはり煩雑な作業を強いられていた。

コンピュータ上で抽選を実施する場合には、従来のような抽選会のような手間がかからず、抽選を一度で済ませることに対しての要求度合いが低い。そうすると、抽選希望者についてはその購入能力の如何にかかわらず抽選を受けられる応募者として受け入れ、そのような応募者から購入候補者を抽選し、抽選された購入候補者に購入能力があれば購入権を付与し、購入能力がなければ再度抽選を繰り返せばよいと言える。すなわち、応募者の中から購入能力があると判断される購入候補者が現れるまで、何度でも抽選を繰り返せばよい。本実施形態における住戸販売用抽選プログラムは、このようなプロセスによって販売物件に対する購入権を付与する購入候補者を決定する。

さて、このように審査前に抽選を実施する場合には、できるだけ購入意思の強い応募者、審査を通過する可能性の高い応募者が購入候補者に選ばれる方が、販売物件の購入契約ひいては引き渡しまで円滑に進めることが期待できる。そこで、本実施形態においては、そのような応募者が購入候補者に選ばれやすくするために、応募者間の当選確率を調整する。ここで、「当選確率」は、購入候補者に選ばれる抽選確率をいう。例えば、５人の応募者が存在する場合には、調整しない場合の当選確率は一律に２０％である。ここで、ある応募者に対して＋２０％の調整を行う場合には、当該応募者の当選確率は２４％になり、他の４人の応募者の当選確率はそれぞれ１９％に調整される。

本実施形態においては、当選確率の調整は、公平を期する観点から事前に告知される。すなわち、いかなる項目が当選確率を上昇させるものであるかが告知される。当選確率を上昇させる項目は、管理者等によって事前に住戸販売用抽選プログラムに対して設定されており、物件購入アプリは、当選確率の調整に係る当該設定をアプリサーバ１００から取得する。物件購入アプリは、取得した当該設定に従って、当選確率を上昇させる項目を受付画面に表示する。

図４の例では、「物件をブックマークする」を満たす場合には５％、「１時間以上の物件情報閲覧」を満たす場合には５％、「購入に関する個人情報の開示」を満たす場合には５％から３０％の範囲でそれぞれ当選確率を上昇させることを告知している。例えば、物件購入アプリは、物件情報を提供するＵＲＬがブックマークに登録されていることを確認してその旨をアプリサーバ１００へ送信する。住戸販売用抽選プログラムは、そのような情報を取得すると、当該応募者の当選確率を５％上昇させる。

応募者は、「購入に関する個人情報の開示」しようとする場合には、情報入力ボタン３３３をタップする。物件購入アプリは、当該タップを検知すると、個人情報の入力を受け付ける受付画面を表示する。図５は、個人情報の入力を受け付ける受付画面の一例である。個人情報の入力を受け付ける受付画面は、「個人情報の入力」の表示タイトル３２０と、個人情報を入力する入力項目の表示を含む。

図の例では、名前や年収をそれぞれ入力するテキストボックス３３５や、現在の住まいの種類や過去の応募履歴の有無をチェックするチェックボタン３３６が設けられている。なお、送り指標３３８は、下方に更に入力項目が存在することを示している。応募者は、これらの項目に対して任意に自らの個人情報を入力することができる。例えば、名前を入力すれば＋２％、現在の住まいの種類を入力すれば＋２％のように、応募者は、入力する個人情報の多寡によって当選確率に加算される加算率を変化させることができる。

加算率は、設定された項目の個人情報を応募者が開示するか否かによる固定値として設定する場合に限らず、設定された項目に入力された内容によって増減させる可変値として設定することもできる。例えば、年収の項目は、入力された値が大きいほど加算率が増加するように設定してもよい。また、過去の応募履歴が「あり」の場合に、その応募に係る選択ボックス３３７で選択された間取りと、今回の販売物件の間取りとが一致する場合には、一定の加算率を上乗せするように設定してもよい。

ところで、物件購入アプリの利用者は、利用開始時に個人情報を任意に登録する登録作業を行っている。すなわち、住戸販売用抽選プログラムは、住戸情報の提供に先立ち、利用者が物件購入アプリの利用を開始しようとする時点において、住戸情報の閲覧者予定者である利用者の個人情報の登録をユーザ登録情報として受け付ける。したがって、物件購入アプリの利用開始時に登録されたユーザ登録情報はアプリサーバ１００のユーザ情報ＤＢ１３２に蓄積されている。

販売物件に応募しようとする応募者は、ユーザ登録情報をユーザ情報ＤＢ１３２から呼び出すことにより、開示しようとする個人情報の入力の手間を省くことができる。具体的には、情報利用ボタン３３９をタップすることにより、登録時に入力したユーザ登録情報を呼び出すことができる。

図６は、ユーザ登録情報から開示情報を選択する選択画面の一例である。開示情報を選択する選択画面は、「ユーザ登録情報」の表示タイトル３２０と、開示する情報の選択を促す旨を告知する告知情報３３０と、登録情報３４０を含む。登録情報３４０の各項目の先頭にはチェックボックス３４１が配置されており、応募者は、開示しようとする情報のチェックボックス３４１をタップすることにより、当該情報を選択することができる。図の例では、名前と現在の住まいの種類が選択されている。住戸販売用抽選プログラムは、登録された応募者自身の個人情報から応募者が選択した特定の情報を開示する個人情報として取得する。そして、これらの開示する個人情報に応じて当該応募者の当選確率を調整する。

応募者は、このような抽選確率を上昇させるための入力作業を終了したら、図４に示す購入希望を受け付ける受付画面へ戻り、応募ボタン３３１をタップする。物件購入アプリは、応募ボタン３３１がタップされたことを検知すると、応募受付の確認画面を表示する。

図７は、応募受付の確認画面の一例である。応募受付の確認画面は、「抽選応募を受け付けました」の表示タイトル３２０と、応募物件情報、当選確率の調整結果、抽選に係る告知事項を告知する告知情報３３０を含む。当選確率の調整結果は、住戸販売用抽選プログラムによって算出された加算率であり、抽選に係る告知事項は、例えば抽選日や抽選結果の通知方法である。

ここで、住戸販売用抽選プログラムが実行する当選確率を調整について説明する。図８は、当選確率の調整に用いる応募者情報テーブルを模式的に示す図である。上述のように、物件購入アプリは、それぞれのユーザのユーザ端末３００にインストールされ、物件購入に関する様々なサービスを多くのユーザに提供する。それぞれのユーザ端末３００にインストールされた物件購入アプリは、アプリサーバ１００で実行される住戸販売用抽選プログラム含むサービス提供プログラムと連携する。サービス提供プログラムは、それぞれのユーザ端末３００の物件購入アプリからの要求に従って情報を送信したり、物件購入アプリを介してユーザ端末３００へ入力された情報を取得したりする。

住戸販売用抽選プログラムは、販売物件のそれぞれに対して購入を希望する応募者に関する応募者情報テーブルを作成する。応募者情報テーブルは、販売対象の物件一つ一つに対応付けられる。図示する応募者情報テーブルは、「リビオ東京６０４号室」の販売物件に対応付けられている。そして、それぞれの応募者情報テーブルは、応募者名と、各応募者に関連付けられる閲覧評価、属性情報、調整確率が記述されている。

閲覧評価は、対象となる販売物件の住戸情報に対する応募者の閲覧状況を評価するものであり、販売物件の物件情報を提供するＵＲＬがブックマークに登録されているかについてと、当該物件情報を１時間以上閲覧したかについてが、評価対象として含まれる。閲覧状況の評価対象は、これらに限らず、他の対象に変更したり加えたりしてもよい。

属性情報は、応募者の属性に関する情報であり、応募者の個人情報を含む情報である。個人情報としては図５や図６を用いて説明したように収集される。図５や図６の例では個人情報を入力する例を説明したが、個人情報の範疇に含まれない属性情報を入力できるようにしてもよい。なお、応募者が氏名を開示しない場合には、住戸販売用抽選プログラムが生成するＩＤ番号で応募者を管理し、図示するように例えば「ａ００２ｂ３５」のようにＩＤ番号を与えて当該応募者を抽選の対象とする。

住戸販売用抽選プログラムは、このように収集した応募者それぞれに対して、当選確率に加算される加算率を算出する。具体的には、閲覧評価の各項目と属性情報の各項目について開示に対する加算率が規定された規定テーブルを参照し、それぞれの項目の開示に対する加算率を積算して応募者ごとの加算率を算出する。このように計算された加算率は、上述のように、応募受付の確認画面にも表示される。

そして、住戸販売用抽選プログラムは、抽選段階において、応募者の人数と、それぞれの応募者に与えられる加算率に基づいて、各応募者の当選確率を調整する。具体的には、上述のように５人の応募者が存在する場合に一人だけ加算率が＋２０％であり他の応募者の加算率が０％であれば、＋２０％された応募者の当選確率は２４％に調整し、他の応募者の当選確率はそれぞれ１９％に調整して抽選を実行する。また、５人の応募者の加算率がいずれも＋５％であれば、応募者間の加算率に差がないことになるので、いずれの応募者の当選確率も２０％として抽選を実行する。

住戸販売用抽選プログラムは、定められた抽選日の抽選時間に、応募者の中から対象物件の購入候補者を抽選する抽選処理を実行する。そして、購入候補者に決定した応募者には当選通知を、その他の応募者には落選通知を各ユーザ端末３００へ送信する。図９は、決定した購入候補者に当選を通知する結果通知画面の一例である。当選を通知する結果通知画面は、「抽選結果」の表示タイトル３２０と、当選の旨を告知する告知情報３３０を含む。また、当選を受け入れて物件購入の審査手続きへ進むための受入ボタン３４３と、当選を辞退する辞退ボタン３４４が配置されている。

購入候補者が受入ボタン３４３をタップすると、物件購入に課される審査のための審査情報を入力する入力画面へ遷移する。入力画面は、販売会社、売主会社、住宅ローン会社等が定める各審査項目を入力できるように構成され、図５に示す個人情報の入力を受け付ける受付画面のようにテキストボックス３３５やチェックボタン３３６、チェックボックス３４１などが配置されている。住戸販売用抽選プログラムは、物件購入アプリを通じて入力されたこれらの審査情報を取得する。そして、当該審査情報が予め設定された審査基準を満たすか否かを審査する。住戸販売用抽選プログラムは、販売会社、売主会社、住宅ローン会社等が定める審査に関する情報や規定を収集して審査情報ＤＢ１３３に蓄積しており、これらを用いて審査基準を策定している。審査基準を満たす場合には、購入候補者に対して対象物件を購入する購入権を付与すると決定する。審査基準を満たさない場合には、購入権を付与しない決定をする。

購入権を付与すると決定した場合には、当該購入候補者のユーザ端末３００へ審査通過の旨と購入手続に関する案内を通知する。購入候補者が購入手続きを進めると、当該物件の売買契約が完了する。

購入候補者が辞退ボタン３４４をタップした場合、また、審査段階で住戸販売用抽選プログラムが購入候補者に購入権を付与しない決定をした場合には、住戸販売用抽選プログラムは、当該購入候補者を除く応募者、すなわち抽選で落選した応募者を対象として再抽選を実施する。

住戸販売用抽選プログラムは、上述のように、落選者には落選通知をそれぞれのユーザ端末３００へ送信する。図１０は、落選した応募者へ落選を通知する結果通知画面の一例である。落選を通知する結果通知画面は、「抽選結果」の表示タイトル３２０と、落選の旨を告知する告知情報３３０を含む。

落選の旨を告知する告知情報は、当選者が辞退した場合または審査に不通過の場合に再抽選を行う旨の情報を含む。落選者は、再抽選が実施される場合に応募するか否かを決めることができる。具体的には、結果通知画面には応募ボタン３４５と辞退ボタン３４６が配置されており、落選者は応募ボタン３４５をタップすると再抽選の応募者として登録され、辞退ボタン３４６をタップすると、再抽選の応募者から除外される。これらの情報は、アプリサーバ１００へ送信され、住戸販売用抽選プログラムは、再抽選実施時の応募者情報として記憶部１３０に登録する。

図１１は、再抽選に関する情報を通知する通知画面の一例である。図１１（Ａ）は、再抽選を実施する場合の通知画面の一例であり、図１１（Ｂ）は、再抽選を実施しない場合の通知画面の一例である。

再抽選を実施する場合の通知画面は、図１１（Ａ）に示すように、「再抽選実施のお知らせ」の表示タイトル３２０と、再抽選物件の情報、再抽選に係る告知事項を告知する告知情報３３０を含む。住戸販売用抽選プログラムは、再抽選の実施時刻を、例えば再抽選への応募者が確定してから所定時間経過後や、購入候補者に購入権を付与しないと決定してから所定時間経過後など、予め設定された条件に従って設定することができる。

住戸販売用抽選プログラムは、設定した実施時刻に、再抽選への応募者を対象として抽選処理を再度実行する。このとき、少なくとも前回の購入候補者（当選者）は応募者から除外されるので、再抽選への応募者間で当選確率の再調整を実施する。そして、新たな購入候補者が抽選されたら、上述のように、新たな購入候補者に対する審査を開始する。このようにして、購入者が確定するまで、上述の処理を繰り返す。

再抽選を実施しない場合は、購入権が付与された購入候補者が確定した場合であり、再抽選を実施しない場合の通知画面は、図１１（Ｂ）に示すように、「購入者確定のお知らせ」の表示タイトル３２０と、確定物件の情報、再募集に係る告知事項を告知する告知情報３３０を含む。ここで、再募集は、購入権を付与された購入候補者が購入契約後に当該購入契約をキャンセルした場合に実施される募集である。再募集は、購入候補者を除いた応募者に対して実施される。

図１２は、再募集に対する応募を受け付ける受付画面の一例である。再募集の受付画面は、「再募集のお知らせ」の表示タイトル３２０と、再募集を抽選方式で実施する旨を告知する告知情報３３０を含む。落選者は、再募集に応募するか否かを決めることができる。具体的には、再募集の受付画面には応募ボタン３５１と辞退ボタン３５２が配置されており、落選者は応募ボタン３５１をタップすると再募集の応募者として登録され、辞退ボタン３５２をタップすると、再募集の応募者から除外される。これらの情報は、アプリサーバ１００へ送信され、住戸販売用抽選プログラムは、再募集の応募者情報として記憶部１３０に登録する。

上述のように、再抽選の場合は、設定された募集期間に応募した応募者に限って実施した。これは、抽選から再抽選に至る一連の処理が、当初の応募者の中から購入権を付与する購入候補者を決定すること、かつ、購入能力についての審査をできる限り少ない人数に留めることを目的とするからである。しかし、再募集の場合には、仕切り直しの性質が強く、抽選の対象者を当初の応募者に限らなくてもよい。

そこで、住戸販売用抽選プログラムは、購入権を付与する購入候補者が決定した後も、さらには購入契約後も、キャンセル待ちであることを示して対象物件の住戸情報の提供を継続する。そして、キャンセル待ちとして当該物件の購入を希望する新たな申請を受け付ける。

図１３は、キャンセル待ち住戸の住戸情報を提供する提供画面の一例である。具体的には図３の提供画面に対して、表示タイトル３２０を「キャンセル待ち物件」に変更し、購入希望ボタン３２４を応募ボタン３５３に変更した画面である。キャンセル待ちでも応募したいと考える応募者は、応募ボタン３５３をタップする。応募ボタン３５３がタップされると、住戸販売用抽選プログラムは、当該応募者をキャンセル待ちの応募者として記憶部１３０に登録する。

住戸販売用抽選プログラムは、購入権を付与された購入候補者が対象物件の購入をキャンセルした場合に、再募集に係る抽選を実施する。再募集に係る抽選も、当初の抽選と同様に処理すればよい。

以上の説明においては主にユーザ端末３００で表示される表示画面の例に従って抽選処理の流れを説明したが、ここで、住戸販売用抽選プログラムがアプリサーバ１００で実行する処理フローを整理する。図１４は、アプリサーバ１００によって処理される処理手順を示すフロー図である。なお、以下のフローにおいては、これまで説明したすべての処理を説明するものではなく、主要な処理に限って説明するものである。

処理部１１０は、ステップＳ１０１で、各ユーザ端末３００にインストールされた物件購入アプリからの要求に従って、販売対象となる住戸に関する住戸情報を提供する。処理部１１０は、ステップＳ１０２で、アプリ登録を受け付ける。具体的には、新規のユーザが物件購入アプリの利用を開始するにあたり入力した登録情報を、ユーザ端末３００から取得し、ユーザ情報ＤＢ１３２へ登録する。新規のユーザは、登録情報がユーザ情報ＤＢ１３２へ登録された後に、住戸情報の閲覧が可能となる。

処理部１１０は、ステップＳ１０３で、閲覧者から購入の申請を受け付ける。処理部１１０は、購入の申請を行った閲覧者を応募者として受け付け、応募者情報テーブルに応募者情報を記述する。なお、このとき、当選確率の調整に関する閲覧評価や属性情報も併せて取得して、応募者情報テーブルに記述する。

処理部１１０は、ステップＳ１０４で、応募期間が終了したか否かを確認する。応募期間が終了していなければステップＳ１０１へ戻る。応募期間が終了したらステップＳ１０５へ進み、応募者の中から購入候補者を抽選する抽選処理を実行する。そして、その抽選結果を応募者へ通知する。

抽選処理を実行するにあたり、処理部１１０は、当選確率を上昇させるために応募者が開示した情報を対象物件の売主が管理する外部サーバ２１０へ送信する。送信先は、売主が管理するサーバでなくてもよく、売主が指定する外部サーバであればよい。売主は、自身の物件を販売するにあたり得られた情報を、後のマーケティング等に活用することができる。

処理部１１０は、ステップＳ１０７へ進み、物件購入アプリが購入候補者に入力させた審査情報を取得する。そして、審査基準と照らし合わせて、購入候補者へ対象物件の購入権を付与するか否かの審査を行う。ステップＳ１０８へ進み、購入候補者へ購入権を付与しないと決定した場合には、購入候補者を除いた応募者を対象としてステップＳ１０５の抽選ステップから再度実行する。なお、上述のように、購入候補者でない応募者は、再抽選を辞退することもできる。購入候補者へ購入権を付与すると決定した場合には、ステップＳ１０９へ進む。

処理部１１０は、ステップＳ１０９で、購入候補者へ購入手続に関する案内を通知する。そして、購入手続きを受け付けて購入契約を締結する。処理部１１０は、ステップＳ１１０へ進み、対象物件の引き渡し前に購入者からのキャンセルが発生したか否かを確認する。キャンセルが発生していなければ、一連の処理を終了する。

キャンセルが発生していれば、処理部１１０は、ステップＳ１１１へ進み、再募集に係る購入申請の受付けを行う。さらにステップＳ１１２で、応募期間が終了したか否かを確認する。応募期間が終了していなければステップＳ１１１へ戻って再募集を継続する。応募期間が終了したらステップＳ１０５へ進み、再募集への応募者の中から購入候補者を抽選する抽選処理を実行する。

なお、処理部１１０は、住戸販売用抽選プログラムの処理を実行する以外にも、サービス提供プログラムの処理も実行する。したがって、上述の処理の各ステップの間に住戸販売用抽選プログラムの処理を補助する処理が追加されたり、住戸販売用抽選プログラムの処理とは無関係の処理が実行されたりする場合もある。

以上、本実施形態を説明したが、説明したすべての処理が必須であるわけではない。対象物件の性質や売主の意向等に応じて、適宜機能を加えたり外したりすることもできる。例えば、当選確率の調整に関する処理を行わず、応募者は一律の当選確率とすることもできる。また、当選確率の調整に属性情報は用いるが、閲覧評価は用いないとすることもできる。

また、上記の実施形態において当選確率を調整する場合には、属性情報は応募者が記入したり選択したりすることを前提としたが、住戸販売用抽選プログラムが自動的に取得した応募者の属性情報を当選確率の調整に利用することもできる。例えば、過去に物件購入アプリを介して物件購入に応募した履歴情報がユーザ情報ＤＢ１３２に蓄積されているのであれば、住戸販売用抽選プログラムは、その情報を参照して自動的に一定の加算率を上乗せしてもよい。

また、購入権を付与されなかった応募者に対しては、住戸販売用抽選プログラムは、当該物件のキャンセル待ちを受け付けるのではなく、あるいはキャンセル待ちを受け付けるのに加えて、類似する他の物件の住戸情報を積極的に通知する処理を行ってもよい。具体的には、落選した応募者が応募した住戸に関する情報と、当選確率の調整に利用した当該応募者に関する情報を参照して、類似する販売物件を物件情報ＤＢ１３１から抽出する。例えば、同じ価格帯、同じ地域の物件、同様の間取りなどの観点において類似する物件を抽出することができる。そして、その住戸情報をお勧め物件として落選者のユーザ端末３００へ送信する。このような処理により、ユーザの物件探しに資することができる。

また、以上説明した本実施形態においては具体的な表示画面の例を示して説明したが、表示画面のレイアウトやデザインはこれらの具体例に限られるものではない。アニメーションや写真、動画映像を採用してもよいし、ＶＲやＡＲの技術を採用してもよい。

１００…アプリサーバ、１１０…処理部、１３０…記憶部、１３１…物件情報データベース、１３２…ユーザ情報データベース、１３３…審査情報データベース、１４０…通信部、１５０…入出力インタフェース、２１０…外部サーバ、２２０…外部サーバ、３００…ユーザ端末、３１０…アプリロゴ、３２０…表示タイトル、３２２…物件ウィンドウ、３２３…物件選択ボックス、３２４…購入希望ボタン、３３０…告知情報、３３１…応募ボタン、３３２…キャンセルボタン、３３３…情報入力ボタン、３３５…テキストボックス、３３６…チェックボタン、３３７…選択ボックス、３３８…送り指標、３３９…情報利用ボタン、３４０…登録情報、３４１…チェックボックス、３４２…開示ボタン、３４３…受入れボタン、３４４…辞退ボタン、３４５…応募ボタン、３４６…辞退ボタン、３５１…応募ボタン、３５２…辞退ボタン、３５３…応募ボタン、９００…インターネット

Claims (10)

1. 販売対象となる住戸に関する住戸情報を提供する住戸情報提供ステップと、
   前記住戸の購入を希望する申請を受け付ける申請受付ステップと、
   申請が受け付けられた応募者の中から購入候補者を抽選する抽選ステップと、
   前記購入候補者が入力した審査情報を取得する審査情報取得ステップと、
   前記審査情報に基づいて前記購入候補者へ購入権を付与するか否かの審査を行う審査ステップと、
   前記審査ステップで前記購入権を付与すると決定した場合に、前記購入候補者へ購入手続に関する案内を通知する通知ステップと、
   前記審査ステップで前記購入権を付与しないと決定した場合に、前記購入候補者を除いた前記応募者を対象として前記抽選ステップから再度実行させる制御ステップと
   をコンピュータに実行させる住戸販売用抽選プログラム。
2. 前記住戸情報提供ステップにおいて提供された前記住戸情報を前記応募者が閲覧する閲覧状況を評価する評価ステップをコンピュータに実行させ、
   前記抽選ステップは、評価された前記閲覧状況に基づいて、前記応募者が前記購入候補者に選ばれる抽選確率を調整する請求項１に記載の住戸販売用抽選プログラム。
3. 前記住戸情報提供ステップは、前記購入候補者に選ばれる抽選確率を上昇させる項目としての前記応募者が提供可能な属性情報を告知し、
   前記申請受付ステップは、前記応募者が入力した前記属性情報を取得し、
   前記抽選ステップは、入力された前記属性情報に基づいて、前記応募者が前記購入候補者に選ばれる抽選確率を調整する請求項１または２に記載の住戸販売用抽選プログラム。
4. 前記住戸情報提供ステップの実行に先立って、閲覧者予定者から個人情報の登録を受け付ける登録受付ステップをコンピュータに実行させ、
   前記申請受付ステップは、登録された自身の前記個人情報から前記応募者が選択した特定の情報を前記属性情報として取得する請求項３に記載の住戸販売用抽選プログラム。
5. データベースに蓄積された前記応募者の過去の応募に関する履歴情報を参照する参照ステップをコンピュータに実行させ、
   前記抽選ステップは、参照した前記履歴情報に基づいて、前記応募者が前記購入候補者に選ばれる抽選確率を調整する請求項１から４のいずれか１項に記載の住戸販売用抽選プログラム。
6. 前記抽選ステップにおいて前記購入候補者を抽選するために利用した前記応募者に関する情報を外部サーバへ送信する送信ステップをコンピュータに実行させる請求項１から５のいずれか１項に記載の住戸販売用抽選プログラム。
7. 前記制御ステップは、前記案内を通知された前記購入候補者が購入契約の後に該購入契約をキャンセルした場合に、前記購入候補者を除いた前記応募者から前記住戸の購入を希望する申請を受け付ける前記申請受付ステップから再度実行させる請求項１から６のいずれか１項に記載の住戸販売用抽選プログラム。
8. 前記住戸情報提供ステップは、キャンセル待ちであることを示して前記購入契約後も前記住戸情報を提供し、
   前記申請受付ステップは、前記購入契約後も、キャンセル待ちとして前記住戸の購入を希望する新たな申請を受け付ける請求項７に記載の住戸販売用抽選プログラム。
9. 前記購入権を付与されなかった前記応募者に対して、前記住戸に関する情報と、前記抽選ステップにおいて前記購入候補者を抽選するために利用した前記応募者に関する情報とに基づいて抽出された、販売対象となる他の住戸の住戸情報を提供する関連情報提供ステップをコンピュータに実行させる請求項１から８のいずれか１項に記載の住戸販売用抽選プログラム。
10. コンピュータが、販売対象となる住戸に関する住戸情報を提供する住戸情報提供ステップと、
    コンピュータが、前記住戸の購入を希望する申請を受け付ける申請受付ステップと、
    コンピュータが、申請が受け付けられた応募者の中から購入候補者を抽選する抽選ステップと、
    コンピュータが、前記購入候補者が入力した審査情報を取得する審査情報取得ステップと、
    コンピュータが、前記審査情報に基づいて前記購入候補者へ購入権を付与するか否かの審査を行う審査ステップと、
    前記審査ステップで前記購入権を付与すると決定した場合に、コンピュータが、前記購入候補者へ購入手続に関する案内を通知する通知ステップと、
    前記審査ステップで前記購入権を付与しないと決定した場合に、コンピュータが、前記購入候補者を除いた前記応募者を対象として前記抽選ステップから再度実行させる制御ステップと
    を有する住戸販売用抽選方法。

Images