JP2016512645A - ユーザソース宿泊施設のための予約の有効性の自動決定 - Google Patents

Abstract

宿泊施設リストに関するカレンダーエントリーを更新するための方法およびシステムが開示される。一実施形態では、該方法は、宿泊施設予約システム内の宿泊施設リストに関する利用可能性モデルおよび受託モデルを生成することと、これらのモデルに基づき宿泊施設リストが予約されるであろうという確率を決定することとを含む。さらに、その決定された予約の確率を用いて宿泊施設検索クエリの結果をフィルターしおよび／またはソートすることができる。

Description

本発明は、宿泊施設予約システムに関し、特に、以前の予約履歴に関する宿泊施設の予約の有効性を予測することに関する。

いくつかの既存の宿泊施設予約システム、例えば、ベッドおよび朝食予約システム又は他の宿泊予約システムは、ユーザに、該ユーザ自身が所有している又は借りている宿泊のための宿泊施設の提供を投稿させている。アパートのシングルルームからお城全体に至るまで、例えばＡｉｒｂｎｂ（登録商標）またはＨｏｍｅＡｗａｙ（登録商標）といったウェブサービスでは、ユーザが、何百万の閲覧者に対して彼らの宿泊およびショーケースを提供している。ほとんどの場合、宿泊施設予約システムのユーザは、プロのホテル経営者ではなく、またその宿泊施設予約システムを介して得た収入を副収入として使用している。

宿泊施設予約システムはまた、宿泊施設を探している他のユーザに対して型破りなタイプの宿泊を提供することによって、ユニークな旅行体験をもさせることができる。宿泊予約システムは、短期的な宿泊施設のニーズを求めているユーザと、それら宿を借りたいと探している他のユーザとをマッチさせる。

それら宿泊施設を提供するユーザは他のユーザに対して、宿泊施設に関する情報のみならず、様々な日付に関する宿泊施設の利用可能性に関する情報をも入力させている。提供された情報は通常の場合正確ではあるが、いくつかの情報、例えば利用可能性などは周期的に更新させる必要がある。ほとんどの場合、宿泊施設の提供を投稿するユーザは、利用可能性情報を、宿泊施設が利用可能である又は利用可能でない日付を示す最新のものに維持しておく責任がある。しかし、既存システムは、ユーザが実際に利用可能性情報を現状で維持しているとする保障は何も提示されていない。ほとんどのユーザにとって、宿泊施設予約システムは、主要な収入源ではないことから、彼らはそれのリスト情報を散発的に更新する。このことは、所望の期間利用可能と思われても現実的には利用可能ではないリスティングを取得するために宿泊施設をユーザに探させることになる。これにより、彼らのニーズにマッチしないリスティングをレビューする無駄な時間を費やすことになる。また、ユーザは、そのリスティングから宿泊施設をリクエストしたり、および／または追加的情報をリクエストするメッセージをそのリスティングを投稿するユーザに送る場合がある。このようなことは、宿泊施設予約システムで宿泊施設をリクエストするユーザの信頼を損ない、また宿泊施設予約システムを介して宿泊施設を取得するユーザの可能性を減らすことになる。

そこで、本発明は、改善された宿泊施設予約システムを提供する。

宿泊施設予約システムは、宿泊施設の現在のリストにされた利用可能性と、宿泊施設についての利用可能性の情報の更新時における宿泊施設のホストの過去の行動とに基づいて、所与期間に関する宿泊施設の利用可能性を予測することができる。一実施形態では、宿泊施設予約システムは、ここでは利用可能性モデルと呼ばれる、学習予測モデルのマシンを使用して、宿泊施設の利用可能性を予測する。

宿泊施設予約システムは、宿泊施設が有効という条件で、宿泊施設に関するゲストのリクエストがホストによって受け入れられることができるであろうという確率を推測することもできる。一実施形態では、一実施形態では、宿泊施設予約システムは、ここでは受容モデルと呼ばれる、学習予測モデルの他のマシンを使用して、ゲストについての情報、旅行についての情報、および宿泊施設のリクエストを受け入れる又は断ることにおけるホストの過去の行動に基づいて、受け入れの可能性を予測することができる。

本発明の実施形態は、利用可能性モデルおよび受容モデルを使用して、検索クエリに応答して返答されるリストのランク付けも行うことができる。宿泊施設に関してユーザのリクエストを満足させるセットの宿泊施設が与えられると、利用可能性モデルおよび受容モデルの出力の関数を使用して、ゲストが最も取得又は予約できる全ての宿泊施設についてより高いランク付けを行う。他の実施形態では、それらのモデルを使用して、検索結果をフィルタリングし、ある閾値よりも大きな利用可能性確率および／または受容確率を伴ったリストのみを表示することができる。

特徴および利点はこの要約において記述されており、および下記の詳細な記載は全てを含んでいる。多くの付随的な特徴および利点は、図面、明細書、請求の範囲という観点から当業者には明らかとなるであろう。

本発明の実施形態に従った、宿泊施設予約システムのステム図である。 本発明の実施形態に従った、宿泊施設予約システム内の異なるモジュールを示すブロック図である。 本発明の実施形態に従った、宿泊施設予約システムのクラスの説明図である。 本発明の実施形態に従った、宿泊施設予約システムのカレンダ情報を更新するための例示的方法のフローチャートである。 宿泊施設予約システムの利用可能な宿泊施設を検索するための例示的なユーザインターフェースである。 宿泊施設予約システムにおいて宿泊施設リストの詳細を閲覧するための例示的なユーザインターフェースである。 宿泊施設予約システムにおいてリストされた宿泊施設の利用可能性を閲覧するための例示的なユーザインターフェースである。 宿泊施設予約システムにおいてリストされた宿泊施設のカレンダ情報を更新するための例示的なユーザインターフェースである。

図面は、説明の目的のためのみに本発明の様々な実施形態を描く。当業者であれば、ここで説明される構成および方法の別の実施形態がここに記述される本発明の原理から逸脱することなしに含まれるという、以下の議論から容易に認識できるであろう。

システム概要
ここで図１を参照すると、本発明の一実施形態をサポートするように適合されたシステムアーキテクチャが示されている。図１および他の図は、同様の要素を識別するために同様の参照番号を使用する。「１１３Ａ」など、参照番号の後の文字は、本文が、その特定の参照番号を有する要素に特に言及していることを示す。「１１３」など、後続する文字を伴わない本文中の参照番号は、その参照番号を有する図中のいずれかの要素またはすべての要素に言及している（例えば、本文中の「１１３」は、図中の参照番号「１１３Ａ」および／または「１１３Ｂ」に言及している）。

ネットワーク１０５は、ゲスト１０１とホスト１０３と宿泊施設予約システム１１１との間の通信経路を表す。一実施形態では、ネットワークは、インターネットである。ネットワークは、必ずしもインターネットの一部であるとは限らない、専用または私設リンク（例えば、ＷＡＮ、ＭＡＮ、またはＬＡＮ）も利用することができる。ネットワークは、標準的な通信技術および／またはプロトコルを使用する。

ウェブサーバ１０９は、ゲストクライアント１０１およびホストクライアント１０３に対する基本インターフェースを形成する、ウェブページまたは他のウェブコンテンツを提示する。ゲストおよびホストは、それぞれのクライアントデバイス１０１、１０３を使用して、１または複数のウェブページにアクセスし、データを宿泊施設予約システム１１１に提供する。本出願の文脈においては、「データ」は、宿泊施設についての情報、旅行についての情報、ホスト、およびゲストなどを含むと理解される。例えば、宿泊施設に関する情報の場合、データは、価格、部屋タイプ、ベッドタイプ、ベッドルームの数、バスルームの数、クリーニング料金、チェックイン時間、チェックアウト時間、所在地、大きさ、キャンセルに関する規定、アメニティ、および宿泊所の規則などの情報を含むことができる。また、旅行についての情報の場合、データは、場所、チェックイン日付、チェックアウト日付、ゲストの数、部屋タイプの好み、価格範囲、および望まれるアメニティなどの情報を含むことができる。

ゲストは、宿泊施設予約システム１１１のユーザの１つの種類である。ゲストは、ゲストクライアントデバイス１０１を使用して、旅行パラメータのセットに基づいて、宿泊施設予約システム１１１に宿泊施設をリクエストする。その後、宿泊施設予約システム１１１は、ゲストによって提供された旅行パラメータに最も良くマッチする潜在的な宿泊施設のリストを提供する。

ホストは、宿泊施設予約システム１１１のユーザの別の種類である。ホストは、ホストクライアントデバイス１０３を使用して、宿泊施設パラメータのセットに基づいて、宿泊施設予約システム１１１を通して宿泊施設を提供する。宿泊施設予約システム１１１は、ホストによって提供された宿泊施設パラメータとともに宿泊施設をリストアップする。その後、宿泊施設予約システム１１１は、リストアップされた宿泊施設を、リストアップされた宿泊施設を自分のリクエストに適したものと識別する１または複数のゲストにマッチさせようと試みる。

一実施形態では、クライアントデバイス１０１、１０３は、宿泊施設予約システム１１１と対話するために、ゲストおよびホストによって使用される。クライアントデバイスは、パーソナルコンピュータ（ＰＣ）、デスクトップコンピュータ、ラップトップコンピュータ、ノートブック、またはスマートフォンなどのコンピュータである、またはコンピュータを含む、任意のデバイスとすることができる。コンピュータは、１または複数の汎用または専用プロセッサ、メモリ、ストレージ、およびネットワーキングコンポーネント（有線または無線）を有するデバイスである。デバイスは、オペレーティングシステム、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ互換オペレーティングシステム（ＯＳ）、Ａｐｐｌｅ ＯＳ ＸもしくはｉＯＳ、Ｌｉｎｕｘディストリビューション、またはＧｏｏｇｌｅのＡｎｄｒｏｉｄ ＯＳを実行する。いくつかの実施形態では、クライアントデバイス１０１、１０３は、宿泊施設予約システム１１１と対話するためのインターフェースとして、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ、Ａｐｐｌｅ Ｓａｆａｒｉ、および／またはＯｐｅｒａなどの、ウェブブラウザ１１３を使用する。

宿泊施設予約システム１１１は、ホストが宿泊施設リスティングを掲載すること、およびゲストが宿泊施設を検索し、予約することを可能にする。宿泊施設予約システム１１１は、以下で説明されるような追加のコンポーネントおよびモジュールを備える。

宿泊施設予約システム
図２および図３を参照すると、一実施形態では、宿泊施設予約システム１１１は、ゲストストア２０１と、ホストストア２０３と、リスティングストア２０５と、リクエストストア２１３と、予約ストア２０７と、メッセージストア２０９と、カレンダ２１１と、予約モジュール２１５と、検索モジュール２１７と、検索ログ２１９と、受諾モジュール２２１と、利用可能性モジュール２２３と、カレンダ管理モジュール２２５と、メッセージングモジュール２２７とを備える。当業者は、宿泊施設予約システム１１１が、本明細書で説明されない他のモジュールを含むことを理解されよう。加えて、ファイアウォール、認証システム、支払処理システム、ネットワーク管理ツール、およびロードバランサなどの従来の要素は、本発明にとって重要ではないので、示されていない。システム１１１は、単一のコンピュータを使用して、またはクラウドベースのコンピュータ実施を含む、コンピュータのネットワークを使用して、実施される。コンピュータは、好ましくは、１または複数の高性能ＣＰＵと、１Ｇ以上のメインメモリとを含み、ＬＩＮＵＸ（登録商標）またはその変形などのオペレーティングシステムを実行する、サーバクラスコンピュータである。本明細書で説明されるようなシステム１１１の動作は、ハードウェアを通して、または非一時的なコンピュータストレージにインストールされ、本明細書で説明される機能を実行するためにプロセッサによって実行されるコンピュータプログラムを通して、制御されることができる。様々なストア（例えば、ゲストストア２０１、ホストストア２０３など）は、非一時的なコンピュータ可読ストレージデバイス、ならびにデータアクセスおよび取り出しのために適したデータベース管理システムを使用して、実施される。システム１００は、ネットワークインターフェースおよびプロトコル、データ入力のための入力デバイス、ならびにデータの表示、印刷、または他の提示のための出力デバイスを含む、本明細書で説明される動作に必要な他のハードウェア要素を含む。

ゲストストア２０１は、宿泊施設予約システム１１１において宿泊施設をリクエストしたユーザ（すなわち、ゲスト）を記述するデータを持続的に記憶し、この機能を実行するための１つの手段である。各ゲストは、ゲストプロファイルとも呼ばれるゲストオブジェクト３０１によって表される。ゲストについての情報は、名前、ユーザ名、電子メールアドレス、所在地、電話番号、性別、生年月日、当人についての説明、学歴、職業、他のユーザからのレビュー、および写真などの、ゲスト個人情報を含む。さらに、ゲストストア２０１は、ゲストスコア３１１および常連フラグ３１５などの、追加情報を記憶する。各ゲストは、一意的なＩＤを割り当てられる。ゲストスコア３１１は、ユーザのゲストとしての以前の行動についての数値表現を提供する。いくつかの実施形態では、ゲストスコアは、ゲストの以前の予約からホストによって割り当てられたスコアに基づいている。常連フラグ３１５は、ゲストが宿泊施設予約システム１１１の頻繁なユーザであるかどうかを示し、例えば、ゲストが宿泊施設予約システム１１１を通して宿泊施設を予約した総回数、ゲストが過去最近に宿泊施設予約システム１１１を使用した回数（例えば、ゲストが過去６０日に予約した宿泊施設の数）、ゲストが宿泊施設予約システム１１１を使用した時間の長さ、またはそれらの組合せに基づくことができる。

ホストストア２０３は、宿泊施設予約システム１１１の他のユーザに宿泊施設を提供した、または提供する意思のあるユーザを記述するデータを持続的に記憶し、この機能を実行するための１つの手段である。各ホストは、ホストプロファイルとも呼ばれるホストオブジェクト３０３によって表される。ホストについての情報は、名前、ユーザ名、電子メールアドレス、所在地、電話番号、性別、生年月日、当人についての説明、学歴、職業、他のユーザからのレビュー、および写真などの、ホスト個人情報を含む。さらに、ホストストア２０３は、ホストスコア３３１、保留中メッセージ３３３、過去のゲスト３３５、謝絶回数３３７、および時間の長さ３３９などの、追加情報を記憶する。各ホストオブジェクト３０３は、１または複数のリスティング３０５および１または複数のゲストオブジェクト３０１に関連付けられる。各ホストは、一意的なホストＩＤを割り当てられる。

ホストスコア３３１は、ユーザのホストとしての以前の行動についての数値表現を提供する。ホストスコアは、ホストの以前の予約からゲストによって割り当てられたレーティングに基づかせることができる。一般に、毎回、ホストの宿泊施設を予約したゲストは、宿泊施設ばかりでなく、ホストについてのレーティングも提供することができる。レーティングは、その後、ホストスコアに集約される。レーティングは、レーティングの古さ（すなわち、レーティングがどのくらい以前のものか）に基づいて減弱されるばかりでなく、ゲスト自身のスコア３１１に従って加重されることができる。

宿泊施設予約システム１１１は、メッセージングモジュール２２７を介して、ゲストとホストが、宿泊施設に関して互いにメッセージを送信することを可能にする。保留中メッセージ３３３は、ホストが応答していないゲストからのメッセージの数（すなわち、応答を待っているメッセージの数）をカウントする。保留中メッセージ３３３は、ゲストの問い合わせに対するホストの応答性を測定する。

過去のゲスト３３５は、ホストが宿泊させたことがあるゲストの数をカウントする。一実施形態は、ホストが宿泊施設予約システム１１１を使用し始めてから、ホストが宿泊させたことがあるゲストの総数をカウントする。別の実施形態は、過去最近に（例えば、過去３０日に）ホストが宿泊させたことがあるゲストの数のみを考える。

謝絶回数３３７は、潜在的なゲストからの宿泊施設リクエストをホストが拒否した回数をカウントする。ホストは、数々の理由で宿泊施設リクエストを謝絶する。例えば、以下でさらに説明されるように、ゲストからのリクエストが最少日数を満たしていなかったり、または宿泊施設が実際には利用可能ではなく、ホストがリスティングのカレンダを更新していなかったりする。

時間の長さ３３９は、宿泊施設予約システム１１１を通してホストが宿泊施設を提供している時間量を測定する。

ホストも、宿泊施設予約システムを使用して、他のホストの宿泊施設をリクエストすること、したがって、ゲストになることができる。このケースでは、ユーザは、ゲストストア２０１とホストストア２０３の両方にプロファイルエントリを有する。宿泊施設予約システム１１１の実施形態は、ゲストストア２０１とホストストア２０３を組み合わせて、単一のユーザプロファイルストアにする。ユーザプロファイルストアは、その後、妥当な場合は、任意のゲスト関連情報およびホスト関連情報ばかりでなく、個人情報も記憶する。このスキームは、ユーザが、宿泊施設予約システムを利用して、宿泊施設の提供と宿泊施設のリクエストの両方を行う場合、ゲストストア２０１とホストストア２０３の間で重複する情報の量を減少させる。

リスティングストア２０５は、ホストによって提供された宿泊施設についての情報を記憶し、この機能を実行するための１つの手段である。与えられた宿泊施設の各提供は、リスティングオブジェクト３０５によって表される。リスティングについての情報は、所在地３５１と、価格３５３と、ユニットタイプ３５５と、アメニティ３５７と、カレンダ３５９とを含む。リスティングストア２０５は、宿泊施設についての短い説明、宿泊所の規則のリスト、写真などの、追加情報を含む。各リスティング３０５は、一意的なリスティングＩＤを割り当てられる。各リスティング３０５は、単一のホストオブジェクト３０３に関連付けられる。

所在地３５１は、提供される宿泊施設の完全な住所、地域、市、および／または国などの、宿泊施設の地理的な所在地を識別する。

価格３５３は、リストアップされた宿泊施設を獲得するためにゲストが支払う必要がある金額である。価格３５３は、日、週、および／もしくは月、またはホストによって指定された他の時間の期間当たりの金額として指定される。加えて、価格３５３は、クリーニング料金、ペット料金、およびサービス料金などの、追加料金を含む。

ユニットタイプ３５５は、ホストによって提供されている宿泊施設の種類を記述する。実施形態は、ユニットタイプを２つのグループ、部屋タイプと所有財タイプとに分類する。部屋のタイプは、家またはアパートメント全体、個室、および共有ルームを含む。所有財のタイプは、アパートメント、家、朝食付き民宿、山小屋、別荘、城、ドミトリ、ツリーハウス、船、飛行機、駐車スペース、自動車、ワゴン車、キャンピングカーまたはレクリエーションビークル、イグル、灯台、ユルト、ティピ、洞窟、島、シャレ、土造りの家、小屋、列車、テント、および屋根裏部屋などを含む。

アメニティ３５７は、宿泊施設が提供する追加の特徴をリストアップする。アメニティは、喫煙可能、ペット同伴可能、ＴＶ、ケーブルＴＶ、インターネット、無線インターネット、空調施設、暖房、エレベータ、身体障害者対応、プール、キッチン、敷地内の無料パーキング、ドアマン、ジム、ホットタブ、屋内暖炉、ブザーまたは無線インターホン、朝食、友好的な家族または子供、イベント向き、洗濯機、および乾燥機などを含む。

一実施形態では、各リスティング３０５は、２種類のカレンダ、ホストカレンダ３５９および予測カレンダ３５９’に関連付けられ、その各々は、宿泊施設の利用可能性についての情報を記憶する。予測カレンダ３５９’は、ホストによって指定された日付期間における各日付について、宿泊施設の利用可能性を記憶する。すなわち、ホストは、リスティングのためのホストカレンダ３５９にアクセスし、リスティングが利用可能な日付、または利用可能でない日付を手入力で示す。ホストによって指定されるカレンダは、ゲストによってすでに予約されているために、宿泊施設が利用可能ではない日付についての情報も含む。第２に、予測カレンダ３５９’は、日付期間における各日付について、利用可能性モジュール２２３によって決定された、宿泊施設が利用可能である確率を記憶する。日付期間は、例えば、将来６０日または１８０日とすることができる。加えて、宿泊施設が予約された後も、ホストカレンダ３５９は、宿泊施設が実際に予約された日付または利用可能であった日付に関する（例えば、過去１８０日間の）履歴情報を記憶し続ける。

リクエストストア２１３は、ゲストによって行われた宿泊施設リクエストを記憶し、この機能を実行するための１つの手段である。各リクエストは、リクエストオブジェクト３０７によって表される。リクエストについての記憶される情報は、リクエスト日付３７１と、開始日付３７３と、日数３７５と、チェックインの曜日３７７と、チェックアウトの曜日３７９と、休日３８１と、ゲストの数３８３とを含む。各リクエスト３０７は、一意的なリクエストＩＤを割り当てられる。与えられたリクエスト３０７は、個々のゲスト３０１およびリスティング３０５に関連付けられる。

リクエスト日付３７１は、リクエストが行われた日付を指定する。開始日付３７３は、リクエストゲストによって宿泊施設が必要とされる最初の日である。日数３７５は、ゲストによって宿泊施設が必要とされる日数を指定する。チェックイン日３７７およびチェックアウト日３７９は、チェックインまたはチェックアウトが必要とされる曜日（すなわち、月曜、火曜、水曜など）を指定する。この情報は、開始日付３７３および日数３７５から推論されることができるので、ゲストによって提供される必要はない。一部のホストは、特定の曜日にしか（例えば、平日にしか、または週末にしか）チェックインおよび／またはチェックアウトを許可しないので、この情報は、重要である。休日３８１は、宿泊施設がリクエストされた期間内の休日の日付を（存在する場合に）示す。ゲストの数３８３は、宿泊施設に滞在する人たちの総数を明記する。

いくつかの実施形態では、リクエスト３０７は、リクエスト３０７が関連付けられたリスティング３０５のホストによって受諾されること、または拒否されることができる。さらに、リクエスト３０７は、閾値時間量以内に、リクエスト３０７が関連付けられたリスティング３０５のホストによって受諾されない場合、失効することもできる。いくつかの実施形態では、リクエスト３０７の失効時間は、宿泊施設予約システム１１１によって設定される（例えば、リクエスト３０７は、リクエスト３０７が提出された時間から２４時間以内に受諾されない場合に失効する）。他の実施形態では、リクエスト３０７の失効時間は、ホスト３０３によって指定されることができる。また他の実施形態では、リクエスト３０７は、宿泊施設がリクエストされている日付３７３よりも閾値時間量前に受諾されない場合に失効する（例えば、リクエスト３０７は、開始日付３７３の日よりも２日前に受諾されない場合に失効する）。

メッセージストア２０９は、メッセージングモジュール２２７を介して交換された、ホスト１０３とゲスト１０１との間のすべての通信を記憶し、この機能を実行するための１つの手段である。各メッセージは、ゲスト１０１、ホスト１０３、およびリスティング３０５に関連付けられる。ゲストは、１または複数のホストと連絡を取って、それぞれのリスティングについて、より多くの情報を獲得する。一部のゲストは、ホストについて、また一部のホストは、ゲストについて、より多くの情報を獲得するための手段としてもメッセージを使用する。

加えて、宿泊施設予約システムは、ホストおよびゲストに、着信メッセージに対する彼らの応答性に基づいて、スコアを割り当てる。どのホストおよびゲストも、彼らが応答したメッセージのパーセンテージに基づいて、応答レートスコアを割り当てられる。また、ユーザは、彼らが着信メッセージに応答するのにかかった時間の平均時間に基づいて、応答時間スコアを割り当てられる。

マスタカレンダ２１１は、リスティングストア２０５内の各リスティングの利用可能性を示す情報を記憶し、この機能を実行するための１つの手段である。各ホストは、宿泊施設予約システム１１１において彼らが掲載した各リスティングについてのリスティングカレンダ３５９を更新する責任を負っている。この情報は、マスタカレンダ２１１を形成するために使用される。いくつかの実施形態では、宿泊施設予約システムは、宿泊施設が利用可能になる確率を記憶する予測されるカレンダも含む。一実施形態では、カレンダ２１１および予測されるカレンダは、組み合わされて、利用不可能であるとホストによって明示的に印づけられた日付に対しては０の確率を、またホストによって利用不可能であるように利用不可能である日付に対しては０よりも大きい（および１以下の）確率を記憶する、単一のカレンダになる。別の実施形態では、利用不可能であるとホストによって明示的に印づけられた日付に対しては、負の値が記憶されることができる。

予約モジュール２１５は、提供された宿泊施設をゲスト１０１が予約することを可能にし、この機能を実行するための１つの手段である。予約モジュール２１５は、予約ストア２０７を更新し、ホストがゲストの宿泊施設リクエストを受諾したときに、リスティングが利用不可能である旨のフラグを予約された日に立てるようにカレンダ管理モジュール２２５に命令する。予約ストア２０７は、宿泊施設リクエストが受諾されたすべての予約についての情報を記憶する。予約ストア２０７内の各エントリは、ホスト、ゲスト、およびリスティングに関連付けられる。予約ストア２０７における入力は、ホストがリスティングに対するゲストのリクエストをひとたび受諾すると、予約モジュールによって行われる。

検索モジュール２１７は、ゲストから入力問い合わせを受信し、入力問い合わせに最も良くマッチする宿泊施設リスティングのリストを返し、この機能を実行するための１つの手段である。検索問い合わせは、所在地（例えば、郵便番号、都市名、国）、チェックイン日付、チェックアウト日付、およびゲストの数などのゲストの旅行と、部屋タイプ、価格範囲、およびアメニティなどのゲストの宿泊施設の好みとに関する検索パラメータを含む。検索モジュールは、その後、検索問い合わせにマッチするすべてのリスティングを取り出す。一実施形態では、所在地と日付、部屋タイプと価格範囲などのパラメータに対して、ブールマッチングが使用され、結果にさらなるフィルタリングを施すために、追加のパラメータが使用される。

いくつかの実施形態では、検索モジュール２１７は、ランキングスコアに基づいて、返された検索結果にランク付けを施す。ランキングスコアは、価格、ホストレーティング、好ましい所在地からの距離、リスティング、またはそれらの組合せなど、数々の因子の関数である。ランキング関数は、個々の因子の線形結合として実施されることができ、各因子は、マッチの程度を示すスケーリングされた変数として表され（例えば、元となる検索パラメータと正確にマッチする場合は１、部分的またはほぼマッチする場合は０．５）、因子の重要性を反映する重みを用いて加重される。一般に、所在地および日付は、大きい重みで加重され、アメニティは、より小さい重みで加重されるが、特定の重みは、システム管理者の設計上の決断である。一実施形態では、ランキング因子は、利用可能性モジュール２２３および受諾モジュール２２１によって提供される情報を含む。

検索ログ２１９は、宿泊施設予約システム１１１において実行されたすべての検索ログの記録を保持し、この機能を実行するための１つの手段である。実施形態は、データベースまたは他の種類のデータリポジトリ内に情報を維持する。どの検索クエリ（問い合わせ）も、ゲストに関連付けられ、検索パラメータについての情報と、クエリ（問い合わせ）にマッチする検索モジュールによって獲得されたリスティングのセットとを含む。検索ログ２１９のいくつかの実施形態は、可能な宿泊施設のリストを受信した後で、ゲストによって取られたアクションに関する情報も記憶する。例えば、検索ログは、ユーザがどのリスティングをチェックまたは閲覧したか、およびゲストがどのリスティングについて宿泊施設をリクエストしたかについての情報を維持する。

利用可能性モジュール２２３は、与えられた日付または日付期間についての与えられたリスティングの利用可能性の確率（ＰＡ）を計算し、この機能を実行するための１つの手段である。利用可能性モジュール２２３の実施形態は、機械学習された予測モデルを使用する。一実施形態では、予測モデルを構成するために、サポートベクトルマシンなどの、管理された機械学習アルゴリズムが使用される。他の実施形態では、予測モデルを構築するために、ニューラルネットワーク、ランダムフォレスト、または他の任意の管理された学習アルゴリズムなどの、他の機械学習アルゴリズムが使用される。定期的に（例えば、１日１回）、利用可能性モジュール２２３は、現在の各リスティング３０５についての将来数日間の利用可能性の確率を計算し、そのリスティングの予測カレンダ３５９’を更新する。例えば、リスティング３０５の予測カレンダ３５９’が将来１８０日間にわたると仮定すると、利用可能性モジュール２２３は、そのような将来の各日付について、リスティング３０５が利用可能である確率を決定し、この値をリスティング３０５のための予測カレンダ３５９’内に記憶する。この予測された利用可能性情報は、検索問い合わせに応答してリスティングにランク付けを施すときに、ランキング因子として検索モジュール２１７によって使用されることができる。一般に、検索モジュール２１７は、リクエストされた期間中に利用可能である確率が高いリスティングをより高くランク付けし、利用可能である確率が低いリスティングをより低くランク付けする。いくつかの実施形態は、ゲストがそれをリクエストした場合に限って、利用可能性モジュールによって提供された情報をランキング因子として使用するにすぎない。他の実施形態は、ゲストによって違った指定が行われない限り、利用可能性モジュールによって提供された情報をデフォルトで使用する。一実施形態では、宿泊施設予約システム１１１は、利用可能性の確率が事前に決定された閾値を下回る場合、宿泊施設が利用不可能であると指定する。他の実施形態は、ユーザが、独自の閾値を指定することを可能にする。利用可能性モデルの構成は、以下でさらに説明される。

受諾モジュール２２１は、特定のリスティングについての特定のゲストによる宿泊施設リクエストに対するホストによる受諾の確率（ＰＣ）を計算し、この機能を実行するための１つの手段である。受諾モジュール２２１の実施形態は、リスティングについてホストが過去に受諾したリクエストおよび拒否したリクエストに基づいて、各ホストのための受諾モデルを使用する。ゲストがある所在地のリスティングを検索する場合、受諾モジュール２２１は、与えられたリスティングについてのリクエストがそのゲストによって行われた場合に、ホストがそのリクエストを受諾する確率を計算する。検索モジュール２１７は、検索結果にランク付けを施す場合に、または閾値スコアよりも低い受諾の確率を有するリスティングを除外するために、受諾の確率をランキング因子として使用することができる。一般に、検索モジュール２１７は、ホストによって受諾される確率が高いリスティングをより高くランク付けし、受諾される確率が低いリスティングをより低くランク付けする。

カレンダ管理モジュール２２５は、ホストおよび予約モジュール２１５によって提供された情報に基づいて、各リスティングのためのカレンダ３５９を更新し、この機能を実行するための１つの手段である。いくつかの実施形態は、利用可能性モジュール２２３によって提供された情報に基づいて、各リスティングのためのカレンダも更新する。一実施形態では、カレンダ管理モジュール２２５は、ホストがホストカレンダ３５９を更新する頻度に応じて、リスティング３０５のためのホストカレンダ３５９を利用可能性モジュール２２３に基づいて更新すべきかどうかを決定する。一方で、ホスト１０３が自らのカレンダを頻繁に更新する（例えば、更新間の平均時間量が閾値を下回る）場合、宿泊施設予約システム１１１が利用可能な情報は、最新である可能性がきわめて高い。他方で、ホスト１０３が自らのカレンダを頻繁には更新しない場合、宿泊施設予約システム１１１が利用可能な情報は、古いものである可能性がきわめて高く、利用可能性モジュールは、ホストの利用可能性履歴に基づいて、リストアップされた宿泊施設の本当の利用可能性を推定することができる。

利用可能性モデル
利用可能性モジュール２２３は、リクエストされた日付に宿泊施設が利用可能である確率を推定するための利用可能性モデルを生成し、使用する。一実施形態では、モジュール２２３は、宿泊施設を提供するホスト毎に利用可能性モデルを生成する。ホスト固有のモデルは、ホストの特定の行動をモデル化ことができ、ホストが宿泊施設を提供した十分な履歴を有する場合に有益である。他の実施形態では、モジュール２２３は、地理的な領域内（例えば、全国、州全体、都市全体など）のほとんどのホストの行動を捉えるために、全国または地域モデルを生成する。地域モデルは、与えられたエリア内のホストの行動全体をモデル化し、地元の休日および祭りが、ゲストが利用可能な宿泊施設をホストに保有させる可能性が高くまたは低くなる傾向にあるのがいつであるかなど、地域的慣習および慣例を反映するために有益である。地域モデルは、ホスト固有のモデルを生成するには不十分な履歴情報しか存在しないホストについてのデフォルトモデルを提供するためにも有益である。

利用可能性モデルは、何らかの時間期間にわたる過去のリクエスト３０８から抽出されたトレーニングデータのセット上でトレーニングされる。時間期間は、すべての過去のリクエスト、または時間の限られた期間内（例えば、過去６か月）のリクエストのみをカバーすることができる。ホスト固有のモデルの場合、トレーニングセットは、そのホストのリスティングに対して行われたリクエスト３０８のみである。地域モデルの場合、トレーニングセットは、その地域の地理的エリア内のすべてのリスティング３０５に対する（各リスティングの所在地３５１を使用した）リクエスト３０８である。

各リスティングに対して、時間期間内の特定の日付について、利用可能性モデルは、その日付に対して行われた宿泊施設に対するすべてのリクエストを検討する。各リクエストについて、モデルは、そのリクエストがホストによって受諾されたかどうかに基づいて、宿泊施設が利用可能であったか、それとも利用不可能であったかを決定する。

与えられた日付に対する与えられたリクエストに対して、ホストがそのリクエストを受諾した場合、利用可能性モデルは、宿泊施設が確率１で利用可能であった（すなわち、宿泊施設が確率０で利用不可能であった）と決定する。数日にわたって受諾されたリクエストに対して、利用可能性モジュールは、リクエストに含まれるすべての日が確率１で利用可能であったと決定する。

ある日について、リクエストが行われなかった場合、利用可能性モデルは、トレーニングを行うためのいかなるデータまたは情報も有さない。このケースでは、利用可能性モデルは、宿泊施設が利用可能であった確率の正確な推定を提供することが可能ではない。いくつかの実施形態は、リクエストがなかった日付に対して、０．５の利用可能性の確率を割り当てる（すなわち、宿泊施設は確率０．５で利用不可能であった）。他の実施形態は、ホストが利用不可能である旨の印を明示的に日付に付けなかった場合、他の確率値を割り当てる。

ある日付について、すべてのリクエストが拒否または失効した場合、利用可能性モジュールは、宿泊施設が利用不可能であった確率を計算することができる。いくつかの実施形態では、すべてのリクエストが拒否された場合、利用可能性モジュールは、０の利用可能性の確率を割り当てる。他の実施形態では、その日付は宿泊施設が利用不可能であったと利用可能性モデルが決定するためには、閾値数のリクエストが拒否される必要がある。他の実施形態では、宿泊施設が利用不可能である確率は、拒否されたリクエストまたは失効したリクエストの数に基づいて決定される。

いくつかの実施形態では、利用可能性モジュール２２３は、ホスト３０３がゲスト３０１に送信したメッセージに対する応答を使用して、利用可能性モデルをトレーニングする。しばしば、ゲスト３０１は、宿泊施設に対するリクエストを提出する前に、リスティングについてのさらなる詳細を求め、望まれる日付が利用可能であることを確認するためのメッセージを、ホスト３０３に送信する。ホスト３０３は、日付が利用可能であるかどうかを示すメッセージを返送し、ホスト３０３がどの日付も利用不可能であることを示した場合、ゲスト３０１は、宿泊施設に対するリクエストを提出しない。これは、利用可能性モデルのトレーニングセットを減らす。ホスト３０３によって送信されたメッセージは、ゲスト３０１が求めたどの日付も利用不可能であることを示す何らかのインジケーションをそれらが含むかどうかを決定するために分析されることができる。いくつかの実施形態では、ホスト３０３からのメッセージ内に宿泊施設が利用不可能であることを示すインジケーションが存在する場合、利用可能性モジュールは、ホストのクエリ（問い合わせ）を拒否されたリクエストと見なす。

利用可能性モデルの実施形態は、異なる曜日、月、および／または休日についてのモデルを構成することもできる。例えば、利用可能性モデルは、土曜日における宿泊施設に対する受諾されたリクエストの数と、土曜日における宿泊施設に対する拒否されたリクエストまたは失効したリクエストの数との比に基づいて、すべての土曜日がある利用可能性の確率を有すると決定することができる。同様に、利用可能性モデルは、これまでの年の１２月の日における宿泊施設に対するすべてのリクエストに基づいて、１２月の日についての利用可能性の確率を決定することができる。

実施形態は、リクエストが行われた日付の、宿泊施設がリクエストされている日付に対する近さに基づいて、利用可能性の確率を決定することもできる。例えば、ホストは、リクエストが少なくとも２日前に行われた場合にのみ、宿泊施設を提供する。利用可能性モデルは、宿泊施設がリクエストされている日付よりも「ｎ」日前に行われたこれまでのすべてのリクエストに基づいて、宿泊施設が「ｎ」日未来に利用可能である確率を決定することができる。

実施形態は、宿泊施設の利用可能性を予想するために、上述された基準のいくつかまたはすべてを考慮したモデルを開発する。後で互いに掛け合わせることによって組み合わされることができる独立の確率を決定するために、異なる基準（例えば、曜日、月、事前の日数など）が使用されることができる。他の実施形態では、すべての基準を考慮した単一の確率が決定される。

一実施形態では、利用可能性モジュールは、日付の１または複数の特徴（例えば、曜日、月、休日かどうか、現在の日付に近いかどうかなど）を入力として取る確率関数を生成し、宿泊施設が利用可能になる尤度を測定する値を生成する。例えば、利用可能性モジュールは、曜日に応じて宿泊施設が利用可能になる尤度を計算する確率関数（Ｐ（利用可能｜曜日））を生成することができる。利用可能性モジュールは、日付がどの月であるかに応じて宿泊施設が利用可能になる尤度を計算する確率関数（Ｐ（利用可能｜月））も生成することができる。同様に、日付の他の特徴のための関数（例えば、Ｐ（利用可能｜休日）、Ｐ（利用可能｜現在日付との近さ）など）が生成されることができる。

利用可能性モジュールが、利用可能性モデルを構成した後、それは、将来の日についての宿泊施設の利用可能性を計算するために使用されることができる。利用可能性モジュールは、与えられた日付と関連付けられた異なる確率を計算し、以下のようにして全体的な確率を決定することができる。

ＰＡ＝Ｐ（利用可能｜曜日）×Ｐ（利用可能｜月）×Ｐ（利用可能｜休日）×Ｐ（利用可能｜日付との近さ）×．．．

例えば、利用可能性モジュールは、２０１４年２月１４日についての利用可能性の確率を計算している場合、与えられたリスティングがその日付の間に利用可能になるかどうかを決定するために、以前に分析された履歴情報を使用することができる。例えば、２０１４年２月１４日は、金曜日である。履歴データから、利用可能性モジュールは、日付が金曜日である場合、そのリスティングについての利用可能性の確率がどうなるかを決定することができる。また、利用可能性モジュールは、日付が２月である場合、そのリスティングについての利用可能性がどうなるかを決定することができる。さらに、２０１４年２月１４日は、バレンタインデーである。したがって、履歴情報から、利用可能性モジュールは、日付がバレンタインデーである場合、リスティングの利用可能性がどうなるかを決定することができる。加えて、利用可能性モジュールは、２０１４年２月１４日までに残されている日数に基づいて、宿泊施設の利用可能性の確率を決定することができる。その後、利用可能性モジュールは、それらの確率を組み合わせ、上述されたすべての因子を考慮した集約確率を生成することができる。したがって、宿泊施設についての利用可能性の確率は、以下の通りである。

ＰＡ＝Ｐ（利用可能｜金曜）×Ｐ（利用可能｜２月）×Ｐ（利用可能｜バレンタインデー）×Ｐ（利用可能｜日付との近さ）

利用可能性モジュールは、有益なことに、宿泊施設予約システムが、宿泊施設検索問い合わせの結果をフィルタリングすること、またはソートすることを可能にする。フィルタリングおよび／またはソートされていない検索結果が、ゲストに提示された場合、ゲストは、利用可能なリスティングばかりでなく、利用不可能リスティングも閲覧して、時間を費やすことになる。さらに、ホストは、利用不可能な日付について宿泊施設をリクエストするメッセージをゲストから取得する。したがって、ゲストに与えられる検索結果が、利用可能性に従ってフィルタリングおよび／またはソートされていれば、ゲストとホストの両方にとって、より生産的であり便利である。

受諾モデル
受諾モジュール２２１は、ゲストによって行われた宿泊施設に対するリクエストをホストが受諾する確率を推定するための受諾モデルを生成し、使用する。受諾モデルの実施形態は、閾値よりも高い利用可能性の確率を有する日付に対して行われた過去のリクエスト上でトレーニングされる。

受諾モデルの実施形態は、ゲストについての情報（例えば、性別、ゲストスコア３１１、ゲスト所在地３１３、および／もしくはゲスト常連フラグ３１５）と、ホストについての情報と、リクエストについての情報（例えば、開始日付３７３、日数３７５、チェックイン日３７７、チェックアウト日３７９、および／もしくはゲストの数３８３）、ゲストによってホストに送信されたメッセージについての情報（例えば、メッセージの言語）、リスティングについての情報（例えば、ゲストの最大数、拒否のレート、および／もしくは適合した問い合わせの数）、ならびに／または市場についての情報（例えば、市場占有率、および／もしくは市場需要）を考慮することができる。

宿泊施設予約システム１１１は、特定の地理的所在地における宿泊施設のステータスを分析することによって、市場についての情報を獲得する。例えば、市場占有率を決定するために、宿泊施設予約システム１１１は、特定の日に対して予約されたリスティング３０５のパーセンテージを決定する。加えて、市場需要を決定するために、宿泊施設予約システムは、特定の時間の期間における宿泊施設に対するリクエストを行ったゲスト３０１の数を決定する（例えば、２０１３年２月についての市場需要は、２０１３年の２月における宿泊施設に対するリクエストを行ったゲスト３０１の数をカウントすることによって決定される）。一実施形態では、市場占有率は、特定の地理的所在地、特定の時間の期間でリスティングを検索したゲスト３０１の数（例えば、ローマ、２０１３年２月におけるリスティングを検索したゲスト３０１の数）によって決定される。

実施形態は、宿泊施設予約システム１１１を通して宿泊施設を提供する各ホストについて受諾モデルを開発する。他の実施形態は、宿泊施設予約システム１１１における各リスティングについて受諾モデルを開発する。

いくつかの実施形態では、与えられたリスティングのための受諾モデルを開発するために、受諾モジュール２２１は、利用可能な日に対して行われた各リクエストからすべてのトレーニングパラメータを計算し、リクエストが受諾されたか、それとも拒否されたかを決定する。一実施形態では、各トレーニングパラメータについて、確率関数が構成され、個々の確率を掛け合わせることによって、全体的な受諾の確率が計算される。

例えば、受諾モジュール２２１は、ゲスト３０１の性別に応じてホスト３０３が宿泊施設に対するリクエストを受諾する尤度を計算する確率関数を生成する（例えば、Ｐ（受諾｜男性ゲスト）、Ｐ（受諾｜女性ゲスト）、またはＰ（受諾｜性別不明ゲスト））。受諾モジュール２２１は、他のゲストパラメータに応じてホスト３０３がリクエストを受諾する尤度を計算する確率関数（例えば、Ｐ（受諾｜ゲスト所在地）、Ｐ（受諾｜ゲストスコア）、Ｐ（受諾｜常連ゲスト）など）も生成する。さらに、受諾モジュール２２１は、リクエストパラメータ（例えば、Ｐ（受諾｜開始日付）、Ｐ（受諾｜日数）、Ｐ（受諾｜チェックイン日）、Ｐ（受諾｜チェックアウト日）、Ｐ（受諾｜ゲストの数）など）、メッセージパラメータ（例えば、Ｐ（受諾｜メッセージ言語））、リスティングについての情報（例えば、Ｐ（受諾｜拒否のレート）、Ｐ（受諾｜適合したクエリの数）など）、および市場についての情報（例えば、Ｐ（受諾｜市場占有率）、Ｐ（受諾｜市場需要）など）などにも基づいて、確率関数を生成する。

受諾モジュール２２１が受諾モデルを構成した後、それは、宿泊施設に対するリクエストをホストが受諾する確率を計算するために使用されることができる。受諾モジュールは、与えられたリクエストに関連付けられた異なる確率を計算し、以下のようにして全体的な確率を決定することができる。

ＰＡ＝Ｐ（受諾｜性別）×Ｐ（受諾｜ゲスト所在地）×．．．×
Ｐ（受諾｜開始日付）×Ｐ（受諾｜日数）×．．．×
Ｐ（受諾｜メッセージ言語）×Ｐ（受諾｜拒否のレート）×．．．×

例えば、米国に居住する男性ゲストが、２０１３年３月１５日から２０１３年３月１７日までのロンドンの特定の宿泊施設に対するリクエストを行った場合、受諾モジュール２２１は、そのようなリクエストが受諾される確率を決定することができる。受諾モジュールは、利用可能な情報に基づいて、個々の確率を計算し、それらを組み合わせて、リクエストが受諾される全体的な尤度を推定することができる。

ＰＡ＝Ｐ（受諾｜男性ゲスト）×Ｐ（受諾｜米国からのゲスト）×．．．×
Ｐ（受諾｜開始：０３／１５／２０１３）×Ｐ（受諾｜３日）×．．．

一実施形態では、受諾モジュール２２１は、受諾モデルを定期的に（例えば、毎夜）更新する。いくつかの実施形態では、受諾モジュール２２１は、少なくとも閾値時間量にわたって宿泊施設予約システム１１１を通して宿泊施設を提供してきたホスト（例えば、少なくとも３か月にわたって宿泊施設を提供してきたホスト）のための、または少なくとも閾値数のリクエストを有するホスト（例えば、宿泊施設予約システム１１１を通した宿泊施設に対する少なくとも５０のリクエストを有するホスト）のための受諾モデルのみを生成する。

受諾モジュールは、有益なことに、宿泊施設予約システム１１１が、宿泊施設検索問い合わせの結果をフィルタリングすること、またはソートすることを可能にする。例えば、宿泊施設予約システム１１１は、特定のホストが他国のホストからの宿泊施設に対するリクエストを受諾しないと決定する。したがって、このホストのリスティングは、外国のゲストの検索結果から除外されることができる。

スコアリング
地理的所在地および日付範囲を含む検索問い合わせを受信すると、宿泊施設予約システム１１１は、検索問い合わせにマッチする宿泊施設に対する予約の確率を計算する。いくつかの実施形態では、宿泊施設が利用可能になる確率が計算され、確率が閾値よりも高い場合に限って、宿泊施設がさらに処理される。検索問い合わせにマッチした各宿泊施設について、利用可能性モジュール２２３は、リクエストされた各日付について、宿泊施設が利用可能である確率を取り出し、各日付についての確率を掛け合わせることによって、集約確率を計算する。

ここで、Ｐ（ａｖａｉｌａｂｌｅ＠１）は、リクエストされた日付の第１日目に宿泊施設が利用可能である確率であり、Ｐ（ａｖａｉｌａｂｌｅ＠ｎ）は、リクエストされた日付の最終日に宿泊施設が利用可能である確率である。

利用可能性モジュール２２３が、宿泊施設が利用可能になる確率が閾値よりも高いと決定した後、受諾モジュール２２１は、検索問い合わせにおいて指定された日付に対して行われたリクエストを、宿泊施設と関連付けられたホストが受諾する確率（ＰＣ）を計算する。その後、宿泊施設予約システムは、宿泊施設が利用可能である確率とホストがリクエストを受諾する確率とを掛け合わせることによって、ゲストが宿泊施設を予約することが可能な確率（ＰＢ）を計算することができる。

ＰＢ＝ＰＡ×ＰＣ

いくつかの実施形態では、予約の確率（ＰＢ）は、検索結果をゲストに提示する前に、宿泊施設にランク付けを施すために使用される。他の実施形態では、予約の確率に加えて、宿泊施設の品質スコア、ホストレーティングなどの他のメトリックが、検索結果をゲストに提示する前に、宿泊施設にランク付けを施すために使用されることができる。

図４は、本発明の実施形態による、宿泊施設予約システムのカレンダ情報を更新するためのプロセスのフローチャートを示している。宿泊施設予約システム１１１は、特定の地理的所在地におけるリスティングに対するリクエストを受信する（４０１）。受信されたリクエストに基づいて、宿泊施設予約システム１１１は、リクエストされた地理的所在地にあるすべてのリスティングを取り出す（４０３）。取り出された各リスティングについて、受諾モジュール２２１は、リスティングホストの受諾モデルから、リクエストゲストに対する受諾の確率（ＰＣ）を決定する（４０５）。また、取り出された各リスティングについて、利用可能性モジュール２２３は、リスティングホストの利用可能性モデルから、利用可能性の確率（ＰＡ）を決定する（４０７）。その後、利用可能性の確率（ＰＡ）と受諾の確率（ＰＣ）とに基づいて、宿泊施設予約システムは、予約の確率（ＰＢ）を決定する。最後に、予約の確率（ＰＢ）に基づいて、リスティングがランク付けされる（４１１）。

図５は、ゲストが検索問い合わせを入力し、検索モジュール２１７によって提供される検索結果を閲覧するためのユーザインターフェースの例示的な実施形態を示している。例示的なユーザインターフェースは、ゲストが検索問い合わせを入力するための手段を含む。最も重要なパラメータは、所在地テキストボックス５０１に入力される所在地である。実施形態は、所在地のみを必須パラメータとして扱い、（チェックイン、チェックアウトなどの）他のパラメータをオプションとして扱う。所在地は、所在地テキストボックス５０１において指定されることができる。例えば、ゲストは、テキストボックス５０１に所在地「Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ」を入力した。結果として、検索モジュールは、カリフォルニア州サンフランシスコ近辺のすべてのリスティングを取り出す。加えて、ゲストは、テキストボックス５０３においてチェックイン日付が２０１２年９月２９日であることを、テキストボックス５０５においてチェックアウト日付が２０１２年９月３０日であることを、ドロップダウンリスト５０７においてゲストがただ１人であることを指定した。

検索モジュール２１７は、指定されたパラメータに基づいて、検索結果をフィルタリングし、上位の結果５２１Ａないし５２１Ｅを表示する。表示された各検索結果は、リスティング名称５２３と、リスティング価格５２５と、レビューの数５２７と、写真５２９とから成る。検索結果をランク付けし、ソートするために使用される基準は、ドロップダウンリスト５１９において選択されることができる。検索結果をランク付けし、ソートするために利用可能な基準は、推薦（すなわち、利用可能性モデルおよび受諾モデルに基づいて、どれがゲストに最適なリスティングであるかを宿泊施設予約システムが決定する）、距離、価格の昇順、価格の降順、および新しさ（すなわち、リスティングが掲載されてからの時間量）を含む。

加えて、ゲストは、検索問い合わせにおいて、部屋タイプ５１１、価格範囲５１３、地域５１５、およびアメニティ５１７などの他のパラメータを指定することができる。ゲストは、検索される所在地をより緻密にするために、地図５０９において特定の所在地を指し示すこともできる。

図６は、宿泊施設予約システム１１１におけるリスティングについてのページ説明の例示的な実施形態である。説明ページは、検索結果ページにおいて利用可能でない追加の情報を含む。説明ページでは、ゲストは、所有財の写真のリスト６０７、リスティングホストによって提供される詳細な説明６０９、一泊の価格６１１および旅行全体での合計価格、ならびにリスティングホストの情報６１３を識別することができる。

写真のリスト６０７は、リストアップされた宿泊施設の内装、外装、および環境がどのように見えるかについての知識を、関心のあるゲストに提供する。一実施形態では、写真は、リスティングホストによって提供される。別の実施形態では、宿泊施設予約システムは、リストアップされた所有財の内装、外装、および環境の写真を撮影するためにプロの写真家を提供する。

詳細な説明６０９は、リストアップされた所有財がゲストのリクエストを満たすかどうかを決定するためにゲストが必要とする情報のほとんどを提供する。詳細な説明６０９は、短い宣伝文句の段落、アメニティのリスト、および宿泊所の規則のリストを含む。いくつかの実施形態では、宿泊施設予約システムが、詳細な説明において提供される情報の真実性を検証する。他の実施形態は、過去のゲストが、ゲストフィードバックまたはコメントを介して、詳細な説明の正確性を検証することを可能にする。

価格６１１は、ゲストに単価（すなわち、一泊の価格、週当たりの価格、および／または月当りの価格）を示す。また、宿泊施設予約システム１１１は、一泊の価格、チェックイン日付、チェックアウト日付、ゲストの数、クリーニング料金、およびサービス料金などに少なくとも基づいて、宿泊施設の合計コストを計算する。さらに、実施形態は、ゲストが宿泊施設をリクエストし、ホストがリクエストを受諾した後、その支払いを行うことを可能にする「ｂｏｏｋ ｉｔ」ボタンを提供する。

ホスト情報６１３は、リスティングホストについての関連する事実を含む。提供される情報は、応答レート、応答時間、および／またはカレンダ更新頻度を含む。実施形態は、ホストの写真、および／またはホストについて説明する短い段落も含む。いくつかの実施形態は、ゲストがリスティングホストと連絡を取ることを可能にする「ｃｏｎｔａｃｔ ｍｅ」ボタンも含む。

図７は、宿泊施設予約システム１１１においてリストアップされた宿泊施設の利用可能性をカレンダとともに示すページの例示的な実施形態である。カレンダ７０１内の日は、利用可能、利用不可能、または過去として印付けされることができる。いくつかの実施形態では、ゲストは、利用可能として印付けされた日に対してのみ、宿泊施設に対するリクエストを行うことができる。他の実施形態では、ゲストは、利用不可能な日に対する宿泊施設をリクエストすることを許可され、ホストは、リスティングの真の利用可能性に基づいて、宿泊施設リクエストを受諾するかどうかを決定することができる。

いくつかの実施形態では、事前に決定された日数（例えば、３０日）分のみの利用可能性が、カレンダに示される。他の実施形態では、宿泊施設予約システムは、リスティングホストが、何日前から予約が行われることができるかを決定することを可能にする。実施形態は、ホストが、異なる日に対して異なる価格を指定することも可能にする。例えば、ホストは、週末および休日にわずかに高い価格を割り当てる。

図８は、宿泊施設予約システム１１１においてリストアップされた宿泊施設の利用可能性を更新するためのユーザインターフェースの例示的な実施形態である。ホストは、利用不可能８０１または利用可能８０３として日に印付けを施すことができる。インターフェースは、カレンダが最後に更新された日付を示す日付フィールド８０５と、ホストがカレンダの更新を終えたことを示すためのボタン８０７も含むことができる。一実施形態では、ホストは、どの日付が利用不可能であるかのみを指定することができ、他のすべての日付は、宿泊施設予約システムによって潜在的に利用可能であると見なされる。他の実施形態では、ホストは、日付が利用可能であることを明示的に示す必要がある。一実施形態では、このインターフェースは、計算された利用可能性の確率についての情報もホストに提供する。

代替的アプリケーション
本明細書で説明された特徴および利点は、必ずしもすべてを包含しているわけではなく、特に、多くの追加の特徴および利点が、図面、明細書、および特許請求の範囲に鑑みて、当業者には明らかであろう。さらに、本明細書で使用される言葉は、主として可読性および説明の目的で選択されたものであり、本発明を詳述するため、または制限するために選択されたものではないことに留意されたい。

本発明の実施形態についての上述の説明は、説明の目的で提示されたものであり、網羅的であること、または開示された通りの形態に本発明を限定することは意図されていない。上述の開示に鑑みて、多くの変更および変形が可能であることを当業者は理解することができる。

本説明のいくつかの部分は、情報に対する操作のアルゴリズムおよびシンボル表現の観点から、本発明の実施形態を説明している。これらのアルゴリズム記述および表現は、自らの仕事の内容を他の当業者に効果的に伝えるために、データ処理分野の当業者によって一般に使用されている。これらの操作は、機能的、計算的、または論理的のいずれで説明されているとしても、コンピュータプログラムによって、または等価の電子回路もしくはマイクロコードなどによって実施されることが理解される。さらに、一般性を失うことなく、これらの操作の配列をモジュールと呼ぶことが、時に便利であることも分かっている。説明された操作および関連付けられたモジュールは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組合せで具体化される。

本明細書で説明されたステップ、操作、またはプロセスのいずれもが、１または複数のハードウェアモジュールまたはソフトウェアモジュールを、単独で用いて、または他のデバイスと組み合わせて、実行または実施される。一実施形態では、ソフトウェアモジュールは、説明されたステップ、操作、またはプロセスのいずれかまたはすべてを実行するために、コンピュータプロセッサによって実行されることができるコンピュータプログラムコードを含むコンピュータ可読媒体を備えるコンピュータプログラム製品とともに実施される。

本発明の実施形態は、本明細書の操作を実行するための装置にも関する。この装置は、必要とされる目的のために特に構成され、および／またはコンピュータ内に記憶されたコンピュータプログラムによって選択的にアクティブ化され、もしくは再構成される汎用コンピューティングデバイスを含む。そのようなコンピュータプログラムは、有形なコンピュータ可読記憶媒体内、または電子命令を記憶するのに適した任意の種類の媒体内に記憶され、コンピュータシステムバスに結合される。さらに、本明細書において言及される任意のコンピューティングシステムは、単一のプロセッサを含み、または増大されたコンピューティング能力のために複数のプロセッサ設計を利用するアーキテクチャである。

最後に、本明細書で使用される言葉は、主として可読性および説明の目的で選択されたものであり、本発明を詳述するため、または制限するために選択されたものではない。したがって、本発明の範囲は、詳細な本説明によっては限定されず、代わりに、本明細書に基づいた出願において現れるいずれかの請求項によって限定されることが意図されている。したがって、本発明の実施形態の開示は、以下の特許請求の範囲において説明される本発明の範囲を説明するものではあるが、限定はしないことが意図されている。

Claims (30)

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. 前記予測モデルによって決定された前記受付の確率は、前記宿泊施設に関連付けられた前記ホストの１以上のプロパティの属性によって決定されることを特徴とする請求項２６記載のコンピュータプログラム製品。