(57)【要約】本開示は、時限付き在庫における利用予測のための回帰木で変更された特徴ベクトル機械学習モデルのためのシステムを含む。オンライン計算システムが、リスティングに関する特徴ベクトルを受信し、その特徴ベクトルと、変更された特徴ベクトルとを需要関数に入力して、需要推定を生成する。システムは、尤度モデルに需要推定を入力して、要求尤度のセットを生成し、各要求尤度は、時限付き在庫が試験価格および期限切れまでの試験時間のセットのそれぞれで取引要求を受信する尤度を表す。システムはさらに、訓練データのセットに基づいて回帰木モデルを訓練し、そのセットは、そのセットからの要求尤度と、その要求尤度を生成するために使用された需要推定を生成するために使用される試験価格および期限切れまでの試験時間期間とのそれぞれを備える。
2019516184.tif 000002
【特許請求の範囲】
【請求項１】
オンライン計算システムにおいて、対象のリスティングに関する特徴ベクトルを受信するステップであって、前記対象のリスティングは、前記オンライン計算システムの複数のクライアントのうちの１つによって予約されるのに使用可能な時限付き在庫を備え、前記特徴ベクトルは、前記時限付き在庫の現在の価格を示す価格特徴と、前記時限付き在庫が期限切れになるまでの期間を示す期限切れまでの現在の時間期間特徴とを含む前記リスティングの複数の特徴を備える、ステップと、
需要関数に前記特徴ベクトルを入力して、前記時限付き在庫が期限切れになる前に前記時限付き在庫が前記クライアントのうちの１つから取引要求を受信する尤度の表現である需要推定を生成するステップと、
期限切れまでの試験時間のセットのそれぞれにおける前記時限付き在庫の前記現在の価格よりも大きいまたは小さい試験価格のセットを生成するステップと、
前記試験価格および期限切れまでの試験時間の各組合せに関して、前記現在の価格を前記試験価格に、および前記期限切れまでの現在の時間期間を前記期限切れまでの試験時間に置き換える前記特徴ベクトルの変更されたバージョンを前記需要関数に入力して、試験需要推定を生成するステップと、
前記試験価格および期限切れまでの試験時間に基づいて生成された前記試験需要推定と、前記現在の価格および期限切れまでの現在の時間期間に基づいて生成された前記需要推定とを備える需要推定のセットを生成するステップと、
尤度モデルに需要推定の前記セットを入力して、要求尤度のセットを生成するステップであって、各要求尤度は、前記時限付き在庫が前記試験価格および期限切れまでの試験時間のそれぞれで取引要求を受信する尤度を表す、ステップと、
訓練データのセットに基づいて回帰木モデルを訓練するステップであって、前記セット内の各訓練データポイントは、前記セットからの前記要求尤度と、前記要求尤度を生成するために使用された前記需要推定を生成するために使用される前記試験価格および期限切れまでの試験時間期間とのうちの１つを備える、ステップと
を備えるコンピュータ実行方法。
【請求項２】
期限切れまでの時間の外挿セットを生成するステップであって、期限切れまでの時間の前記外挿セットは、期限切れまでの試験時間の前記セット内の期限切れまでの時間期間よりも大きい期限切れまでの時間期間を含む、ステップと、
期限切れまでの時間の前記外挿セットを前記回帰木モデルに入力して、前記時限付き在庫が期限切れまでの時間の前記外挿セットのそれぞれにおいて取引要求を受信する尤度を判定するステップと
を備える、請求項１のコンピュータ実行方法。
【請求項３】
前記回帰木モデルを訓練した後に前記リスティングに影響を与える変化の表示を受信するステップと、
前記変化の前記表示に基づいて、前記時限付き在庫が期限切れまでの時間の前記外挿セットのそれぞれにおいて取引要求を受信する前記尤度を調整するステップと
を備える、請求項２のコンピュータ実行方法。
【請求項４】
前記時限付き在庫が取引要求を受信するターゲット尤度を受信するステップと、
前記ターゲット尤度に基づいて価格提示を前記回帰木モデルから判定するステップと
を備える、請求項１のコンピュータ実行方法。
【請求項５】
前記セット内の各訓練データポイントは曜日を備える、請求項１のコンピュータ実行方法。
【請求項６】
前記回帰木モデルに基づいて前記時限付き在庫または前記リスティングに関する価格提示を判定するステップを備える、請求項１のコンピュータ実行方法。
【請求項７】
前記価格提示を判定するステップは、前記回帰木モデルに基づいて前記時限付き在庫の価格に要求尤度をかけた積を最大化する新しい価格を選択するステップを備える、請求項６のコンピュータ実行方法。
【請求項８】
前記需要関数は、需要訓練データ上で訓練されたものであり、前記需要訓練データからの各サンプルは、２進数ラベルと、訓練時限付き在庫の訓練特徴ベクトルとを備え、前記２進数ラベルは、訓練時限付き在庫が前記訓練時限付き在庫の前記期限切れの前に取引要求を受信したかどうかを表し、前記訓練特徴ベクトルは、前記訓練時限付き在庫に関連付けられた訓練リスティングの複数の特徴を表す、請求項１のコンピュータ実行方法。
【請求項９】
前記需要訓練データは、複数の訓練時限付き在庫を備え、前記訓練時限付き在庫の少なくとも１つは、複数のサンプルに関連付けられており、前記サンプルのそれぞれは、前記時限付き在庫の前記期限切れの前の異なる時間期間に関連付けられている、請求項８のコンピュータ実行方法。
【請求項１０】
前記訓練時限付き在庫の１つは、前記時限付き在庫の前記期限切れの前に取引要求を受信せず、前記１つの訓練時限付き在庫に関連付けられた前記サンプルのそれぞれは、マイナスのラベルを有する、請求項９のコンピュータ実行方法。
【請求項１１】
前記訓練時限付き在庫の１つは、前記時限付き在庫の前記期限切れの前に取引要求を受信し、
前記取引要求よりも早い時間に発生する前記１つの訓練時限付き在庫に関連付けられた前記サンプルのそれぞれは、プラスのラベルを有する、請求項９のコンピュータ実行方法。
【請求項１２】
オンライン計算システムにおける非一時的コンピュータ可読媒体であって、
対象のリスティングに関する特徴ベクトルを受信するステップであって、前記対象のリスティングは、前記オンライン計算システムの複数のクライアントのうちの１つによって予約されるのに使用可能な時限付き在庫を備え、前記特徴ベクトルは、前記時限付き在庫の現在の価格を示す価格特徴と、前記時限付き在庫が期限切れになるまでの期間を示す期限切れまでの現在の時間期間特徴とを含む前記リスティングの複数の特徴を備える、ステップと、
需要関数に前記特徴ベクトルを入力して、前記時限付き在庫が期限切れになる前に前記時限付き在庫が前記クライアントのうちの１つから取引要求を受信する尤度の表現である需要推定を生成するステップと、
期限切れまでの試験時間のセットのそれぞれにおける前記時限付き在庫の前記現在の価格よりも大きいまたは小さい試験価格のセットを生成するステップと、
前記試験価格および期限切れまでの試験時間の各組合せに関して、前記現在の価格を前記試験価格に、および前記期限切れまでの現在の時間期間を前記期限切れまでの試験時間に置き換える前記特徴ベクトルの変更されたバージョンを前記需要関数に入力して、試験需要推定を生成するステップと、
前記試験価格および期限切れまでの試験時間に基づいて生成された前記試験需要推定と、前記現在の価格および期限切れまでの現在の時間期間に基づいて生成された前記需要推定とを備える需要推定のセットを生成するステップと、
尤度モデルに需要推定の前記セットを入力して、要求尤度のセットを生成するステップであって、各要求尤度は、前記時限付き在庫が前記試験価格および期限切れまでの試験時間のそれぞれで取引要求を受信する尤度を表す、ステップと、
訓練データのセットに基づいて回帰木モデルを訓練するステップであって、前記セット内の各訓練データポイントは、前記セットからの前記要求尤度と、前記要求尤度を生成するために使用された前記需要推定を生成するために使用される前記試験価格および期限切れまでの試験時間期間とのうちの１つを備える、ステップと
を行うためにプロセッサによって実行可能な命令をエンコードしている非一時的コンピュータ可読媒体。
【請求項１３】
期限切れまでの時間の外挿セットを生成するステップであって、期限切れまでの時間の前記外挿セットは、期限切れまでの試験時間の前記セット内の期限切れまでの時間期間よりも大きい期限切れまでの時間期間を含む、ステップと、期限切れまでの時間の前記外挿セットを前記回帰木モデルに入力して、前記時限付き在庫が期限切れまでの時間の前記外挿セットのそれぞれにおいて取引要求を受信する尤度を判定するステップとを行うために前記プロセッサによって実行可能な命令をエンコードしている、請求項１２の非一時的コンピュータ可読媒体。
【請求項１４】
前記非一時的コンピュータ可読媒体は、
前記回帰木モデルを訓練した後に前記リスティングに影響を与える変化の表示を受信するステップと、
前記変化の前記表示に基づいて、前記時限付き在庫が期限切れまでの時間の前記外挿セットのそれぞれにおいて取引要求を受信する前記尤度を調整するステップとを行うために前記プロセッサによって実行可能な命令をエンコードしている、請求項１３の非一時的コンピュータ可読媒体。
【請求項１５】
前記時限付き在庫が取引要求を受信するターゲット尤度を受信するステップと、
前記ターゲット尤度に基づいて価格提示を前記回帰木モデルから判定するステップと
を行うために前記プロセッサによって実行可能な命令をエンコードしている、請求項１２の非一時的コンピュータ可読媒体。
【請求項１６】
前記セット内の各訓練データポイントは曜日を備える、請求項１２の非一時的コンピュータ可読媒体。
【請求項１７】
前記回帰木モデルに基づいて前記時限付き在庫または前記リスティングに関する価格提示を判定するステップを行うために前記プロセッサによって実行可能な命令をエンコードしている、請求項１２の非一時的コンピュータ可読媒体。
【請求項１８】
前記価格提示を判定するステップは、前記回帰木モデルに基づいて前記時限付き在庫の価格に要求尤度をかけた積を最大化する新しい価格を選択するステップを備える、請求項１７の非一時的コンピュータ可読媒体。
【請求項１９】
前記需要関数は、需要訓練データ上で訓練されたものであり、前記需要訓練データからの各サンプルは、２進数ラベルと、訓練時限付き在庫の訓練特徴ベクトルとを備え、前記２進数ラベルは、訓練時限付き在庫が前記訓練時限付き在庫の前記期限切れの前に取引要求を受信したかどうかを表し、前記訓練特徴ベクトルは、前記訓練時限付き在庫に関連付けられた訓練リスティングの複数の特徴を表す、請求項１２の非一時的コンピュータ可読媒体。
【請求項２０】
前記需要訓練データは、複数の訓練時限付き在庫を備え、前記訓練時限付き在庫の少なくとも１つは、複数のサンプルに関連付けられており、前記サンプルのそれぞれは、前記時限付き在庫の前記期限切れの前の異なる時間期間に関連付けられている、請求項１９の非一時的コンピュータ可読媒体。
【請求項２１】
前記訓練時限付き在庫の１つは、前記時限付き在庫の前記期限切れの前に取引要求を受信せず、前記１つの訓練時限付き在庫に関連付けられた前記サンプルのそれぞれは、マイナスのラベルを有する、請求項２０の非一時的コンピュータ可読媒体。
【請求項２２】
前記訓練時限付き在庫の１つは、前記時限付き在庫の前記期限切れの前に取引要求を受信し、
前記取引要求よりも早い時間に発生する前記１つの訓練時限付き在庫に関連付けられた前記サンプルのそれぞれは、プラスのラベルを有する
請求項２０の非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、2016年4月20日に出願された米国特許仮出願第62/325,006号明細書、および2017年4月7日に出願された米国特許出願第15/482,453号明細書の利益を主張し、それらの全体が、参照により組み込まれる。
【０００２】
本出願は、一般には、時限付き在庫（time expiring inventory）の文脈における特徴ベクトル機械学習モデル（feature vector machine learning models）およびデータ分析に関し、詳細には、時限付き在庫に関連する利用予測のために特徴ベクトル機械出力に回帰木を適用することに関する。
【背景技術】
【０００３】
商品またはサービスの典型的な取引において、商品を管理するまたは所有するマネージャは、商品の価格を設定し、関心のある者が、提案された価格を支払うことに合意するのを待つ。マネージャは、商品の価格を正しく決定できないことが多いが、市場の不完全な情報および他の経済的要因により、最終的に価格を支払うことに合意する人もいる。しかしながら、時限付き在庫の価格決定は、在庫が期限切れになる前に売れなければまたは利用されなければ、在庫が無駄になり、マネージャが収入を得られないので、より困難な試みである。従って、時限付き在庫のマネージャは、それらの在庫の価格決定が高すぎて、期限切れによって収入を失う危険を冒すこと、またはそれらの在庫の価格決定が低すぎて、良好な利用度を伴う一方で最適とは言えない収入を得ることのいずれかに陥りやすい。さらに、時限付き在庫の理想的なまたは望ましい需給均衡価格は、在庫の期限日が近づくにつれて変化し得る。この要因の組合せにより、時限付き在庫のマネージャがそれらの在庫の価格を最適に決定することが困難になる。
【発明の概要】
【０００４】
オンラインシステムは、マネージャが時限付き在庫のリスティングを作成できるようにし、クライアントがリスト化された時限付き在庫を予約指定し、借り、または買うための取引要求を提出できるようにする。オンラインシステムは、時限付き在庫のリスティングの需要を推定する。オンラインシステムは、時限付き在庫、関連付けられたリスティング、および時限付き在庫の市場を記述する特徴のセットを定義する。これらの記述特徴のセットは、リスティングの特徴ベクトルである。オンラインシステムは、リスティングの需要を、そのリスティングの特徴ベクトルを需要関数に入力することによって推定する。
【０００５】
需要関数は、特徴ベクトルの特徴毎の特徴モデルで構成されることが可能であり、特徴ベクトルの各特徴は、特徴モデルに関連付けられる。需要関数は、特徴モデルを合計して需要推定を生成する一般化加法モデルであることが可能である。オンラインシステムは、訓練データを使用して需要関数を訓練することができ、訓練データからの各サンプルは、在庫が期限切れになる前にリスティングの時限付き在庫がクライアントからの取引要求を受信したかどうかを記述する２進数ラベル並びにサンプル時間毎に時限付き在庫のリスティングを記述する特徴ベクトルを備える。オンラインシステムは、単一のリスティングの複数のサンプルを収集することができ、各サンプルは、時限付き在庫の期限が切れる前の時間期間中に時限付き在庫のリスティングの特徴と一致する。
【０００６】
オンラインシステムは次に、需要推定を、クライアントから取引要求を受信する尤度に変換する尤度モデルを使用することができる。オンラインシステムは、期限切れまでのピボット時間（例えば、期限切れまでの現在の時間）よりも大きいまたは小さい期限切れまでの試験時間のセットのそれぞれにおける時限付き在庫のピボット価格（例えば、現在の価格）よりも大きいまたは小さい試験価格のセットを生成する。オンラインシステムは次に、各変更された特徴ベクトルが、異なる試験価格および期限切れまでの試験時間の組合せを有する、時限付き在庫のリスティングの変更された特徴ベクトルを需要関数に入力する。需要関数は、オンラインシステムが尤度モデルを使用して試験尤度のセットに変換する、試験需要推定のセットを生成する。
【０００７】
オンラインシステムは次に、試験尤度のセット上で回帰木を適合させることおよび訓練することが可能である。試験尤度と、試験尤度をもたらした対応する試験価格および期限切れまでの試験時間との特徴ベクトル機械出力の回帰木圧縮が、時限付き在庫の利用を予測するために使用されることが可能である。
【図面の簡単な説明】
【０００８】
【図１】一実施形態に係る、予約する時限付き在庫を使用可能にするオンラインシステムを含む計算環境のブロック図である。
【図２】一実施形態に係る、オンラインシステムの論理コンポーネントのブロック図である。
【図３Ａ】一実施形態に係る、需要モジュールのコンポーネントおよび動作を示す図である。
【図３Ｂ】一実施形態に係る、需要モジュールのコンポーネントおよび動作を示す図である。
【図４Ａ】一実施形態に係る、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。
【図４Ｂ】一実施形態に係る、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。
【図４Ｃ】一実施形態に係る、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。
【図４Ｄ】一実施形態に係る、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。
【図５】一実施形態に係る、需要モジュールによって使用される訓練データを格納する例示的なストアを示す図である。
【図６】一実施形態に係る、特徴モデルを示す図である。
【図７Ａ】一実施形態に係る、例示的な特徴モデルを示す図である。
【図７Ｂ】一実施形態に係る、例示的な特徴モデルを示す図である。
【図８】一実施形態に係る、需要モジュールによって使用される尤度モデルを示す図である。
【図９Ａ】リスティングの価格決定モデルを作成する処理を示す図である。
【図９Ｂ】リスティングの価格決定モデルを作成する処理を示す図である。
【図９Ｃ】リスティングの価格決定モデルを作成する処理を示す図である。
【図１０】一実施形態に係る、１つのリスティングのモデルに関する例示的な回帰木の部分を示す図である。
【図１１】一実施形態に係る、別々の量のリードデイでの例示的なリスティングに関する予約要求を受信する生の尤度および圧縮された尤度を示す図である。
【図１２】一実施形態に係る、各誤差値範囲内での試験セットにおけるリスティングの数の累積頻度のプロットを示す図である。
【図１３Ａ】ワイブル価格曲線における誤差の源の例を示す図である。
【図１３Ｂ】ワイブル価格曲線における誤差の源の例を示す図である。
【図１４】一実施形態に係る、例示的なリスティングに関して、生の尤度、回帰木の尤度、およびワイブル尤度について時空間における価格予測における誤差を示す図である。
【図１５】一実施形態に係る、０日から１８０日のリードタイム間隔でのサンプルリスティングに関する生の技術、ワイブル技術、および回帰木技術についての尤度曲線および提示された価格を示す図である。
【発明を実施するための形態】
【０００９】
図は、例示のみを目的として様々な実施形態を示す。本明細書に示された構造および方法の代替的実施形態が、本明細書に記述された本発明の原理から逸脱せずに採用されることが可能であるということを以下の論考から当業者は容易に理解するであろう。
【００１０】
Ｉ．システムの概要
図１は、一実施形態に係る、購入、貸出し、借受け、予約指定などのために時限付き在庫を提供するオンラインシステムを含む計算環境のブロック図である。ネットワーク１０９は、本明細書ではクライアント１０２Ａと呼ばれる、取引の一方の当事者と、本明細書ではマネージャ１０２Ｂと呼ばれる、取引の他方の当事者との間の通信経路を表す。
【００１１】
説明を明確にするため、クライアントは、価値の潜在的な買い手、賃貸人、借受人、予約指定を保持しているクライアント、またはいかなる形式であれ、時限付き在庫に対するアクセスと引き換えに対価を提供するその他の任意の者を含む。説明を明確にするため、マネージャは、時限付き在庫の項目の売り手、地主および地主の代わりに不動産を管理する不動産所有者、貸出人、チケット販売員またはレストランもしくはホテルの予約係など、予約指定在庫を管理する者、または（いかなる形式であれ）時限付き在庫に対するアクセスの提供と引き換えに対価を受け取るその他の任意の者を含む。取引されている時限付き在庫のタイプに応じて、時限付き在庫は、売られている、借りられている、予約指定されているなどの場合がある。説明を明確にするために、これらの異なるタイプの取引は、本明細書では、可能なタイプの取引のセット全体を表す１つの便利な用語を提供するために「予約（booking）」と呼ばれる。
【００１２】
オンラインシステム１１１は、クライアントに関連付けられた計算装置１０１と、マネージャに関連付けられた計算装置１０１とをネットワーク１０９を介して結合してクライアントとマネージャとがネットワーク１０９上で実質的に対話できるようにする、１つまたは複数の計算装置を含む。一実施形態において、ネットワークはインターネットである。ネットワークはまた、必ずしもインターネットの一部ではない専用またはプライベート通信リンク（例えば、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、またはローカルエリアネットワーク（ＬＡＮ））も利用することができる。ネットワークは、標準の通信技術および／またはプロトコルを使用する。
【００１３】
計算装置１０１は、オンラインシステム１１１と対話するためにクライアントおよびマネージャによって使用される。計算装置１０１は、オペレーティングシステム、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）互換のオペレーティングシステム（ＯＳ）、Ａｐｐｌｅ（登録商標）ＯＳ  ＸもしくはｉＯＳ（登録商標）、Ｌｉｎｕｘ（登録商標）ディストリビューション、またはＧｏｏｇｌｅ（登録商標）のＡｎｄｒｏｉｄ（登録商標）ＯＳを実行する。いくつかの実施形態において、クライアント装置１０１は、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）、Ｍｏｚｉｌｌａ（登録商標）Ｆｉｒｅｆｏｘ（登録商標）、Ｇｏｏｇｌｅ  Ｃｈｒｏｍｅ（登録商標）、Ａｐｐｌｅ  Ｓａｆａｒｉ（登録商標）および／またはＯｐｅｒａ（登録商標）などのウェブブラウザ１１３を、オンラインシステム１１１と対話するために用いるユーザフレンドリーなグラフィカルインタフェースとして使用することができる。他の実施形態において、計算装置１０１は、オンラインシステム１１１にアクセスするための専用ソフトウェアアプリケーションを実行できる。オンラインシステム１１１は、クライアントとマネージャが時限付き在庫を取引するためにそれらの計算装置１０１経由で対話するための計算プラットフォームを提供する。オンラインシステム１１１は、例えば、レストランでの食事のオンラインシステム（または飛行機もしくは列車の座席オンラインシステム、ホテルのオンラインシステム、またはデイスパのオンラインシステムなど、その他の任意の種類のオンラインシステム）、相乗り（カープール）のオンラインシステム、宿泊施設のオンラインシステムその他をサポートすることができる。
【００１４】
オンラインシステム１１１は、時限付き在庫のリスティングを作成する能力をマネージャに提供する。リスティングは、航空券オンラインシステムによって申し出されるフライト毎の各飛行機の各座席など、時限付き在庫の個々のインスタンスに対して作成されることが可能である。あるいは、リスティングは、特定の在庫に関して時間に関係なく作成されることが可能であり、次にリスティングは、単位時間にわたって取引されることが可能であり、それらの単位時間は、それらの単位時間がすでに経過した時点で期限切れになる。この場合、リスティングは、時限付き在庫のセットに共通であり、そのセットの時限付き在庫の各項目は、取引されている時間／日付範囲においてのみ、他とは異なる。例えば、不動産賃貸システムの場合、リスティングは、特定のアパートまたはマンション用であることが可能であり、クライアントおよびマネージャは、そのアパートまたはマンションに関連付けられた異なる単位時間（例えば、日付）に取引することができる。
【００１５】
一般的に、必須ではないが、各リスティングは、関連する現実世界の地理的位置をそのリスティングに関連付けられることになる。これは、賃貸する不動産の位置、または予約指定するレストランの位置、および場合により、予約指定される特定のテーブルであり得る。オンラインシステム１１１は、マネージャが、リスティングの実際のおよび予測される需要の情報、並びにマネージャが特定のリスティングの利用および／または収入を改善する上で使用することを選択できる情報の権限をマネージャに与える内部情報を提供することを含む、マネージャのリスティングを管理するのに役立つオンラインソフトウェアツールをマネージャにさらに提供する。
【００１６】
オンラインシステムは、リスティングを探索し、可能な取引に関してマネージャと通信し、取引が行われることを公式または非公式に要求し（例えば、申し出る）、および実際にリスティングに関する取引を遂行する（例えば、買う、借りる、予約指定する）能力をクライアントに提供する。オンラインシステム１１１は、以下に記述されている付加的なコンポーネントおよびモジュールを備える。
【００１７】
ＩＩ．オンラインシステム
図２は、一実施形態に係る、オンラインシステム１１１の論理コンポーネントのブロック図である。オンラインシステム１１１は、フロントエンドサーバ２０１、クライアントモジュール２０３、マネージャモジュール２０５、リスティングモジュール２０７、探索モジュール２０９、取引モジュール２１１、需要モジュール２１３、およびデータベース２５０を備える。オンラインシステム１１１はまた、本明細書に記述されていない、異なるおよび他のモジュールも包含できることを当業者はさらに認識するであろう。さらに、ファイアウォール、認証システム、支払い処理システム、ネットワーク管理ツール、負荷分散装置など、従来の要素は、本明細書に記述された主題にとって直接に重要ではないので、示されていない。
【００１８】
オンラインシステム１１１は、単一の計算装置、またはクラウドベースのコンピュータ実装を含む、計算装置のネットワークを使用して実装されることが可能である。計算装置は好適には、１つまたは複数の高性能コンピュータプロセッサおよびランダムアクセスメモリを含み、およびＬｉｎｕｘまたはその変型などのオペレーティングシステムを実行するサーバクラスのコンピュータである。本明細書に記述されるオンラインシステム１１１の動作は、ハードウェアを介して、またはソリッドステートドライブもしくは磁気記憶装置など、非一時的コンピュータ可読記憶装置にインストールされたコンピュータプログラムを介して制御され、本明細書に記載された機能を遂行するためにプロセッサによって実行されることが可能である。データベース２５０は、非一時的コンピュータ可読記憶装置と、データアクセスおよび検索に適したデータベース管理システムとを使用して実装される。オンラインシステム１１１は、ネットワークインタフェースおよびプロトコル、データエントリ用の入力装置、並びに表示、印刷、またはデータの他のプレゼンテーション用の出力装置を含む、本明細書に記述された動作に必要な他のハードウェア要素を含む。さらに、ここにリスト化された動作は必然的に、商業的に有益な時間量で遂行されるためにコンピュータによって遂行されなければならない頻度およびデータの大規模なセットにわたって遂行され、従って人間の心の精神的処理段階によるいかなる有用な実施形態においても遂行されることは不可能である。
【００１９】
データベース２５０は、クライアントデータストア２５１、マネージャデータストア２５２、リスティングデータストア２５３、クエリデータストア２５４、取引データストア２５５、および訓練データストア２５６を含む。これらのデータストアが汎用データベースのコンポーネントではないこと、およびデータベース２５０が、ここでは明示的に言及されていない他のデータストアを包含できることを当業者は認識するであろう。データベースは、ＭｙＳＱＬ（登録商標）、ＰｏｓｔｇｒｅＳＱＬ、Ｍｉｃｒｏｓｏｆｔ  ＳＱＬ  Ｓｅｒｖｅｒ、Ｏｒａｃｌｅ（登録商標）、ＳＡＰ（登録商標）、ＩＢＭ（登録商標）ＤＢ２（登録商標）など、任意の適したデータベース管理システムを使用して実装されることが可能である。
【００２０】
フロントエンドサーバ２０１は、クライアントおよびマネージャの計算装置１０１がオンラインシステム１１１と通信することを可能にするプログラムコードを含み、それを行うための１つの手段である。フロントエンドサーバ２０１は、計算装置１０１にインストールされることが可能であるウェブブラウザソフトウェアアプリケーションなどのユーザエージェントがコマンドを送信してオンラインシステムからデータを受信することができるように、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）経由でアクセス可能な１つまたは複数のウェブサイトをホストするウェブサーバを含むことができる。フロントエンドサーバ２０１はまた、計算装置１０１上にインストールされたソフトウェアアプリケーションがＡＰＩを呼び出してコマンドを送信してオンラインシステムからデータを受信することを可能にするアプリケーションプログラミングインタフェース（ＡＰＩ）も使用可能にすることができる。フロントエンドサーバ２０１は、コマンドおよびデータをオンラインシステム１１１の他のコンポーネントにルートして、本明細書に記述された処理を実施し、それに従って計算装置１０１に応答するプログラムコードをさらに含む。
【００２１】
ＩＩ．Ａ  クライアントおよびマネージャ
クライアントモジュール２０３は、クライアントがそれらとオンラインシステム１１１との対話を管理することを可能にし、オンラインシステム１１１の他のコンポーネントによって要求され得るクライアント関連の情報の処理論理を実行するプログラムコードを備え、それを行うための１つの手段である。各クライアントは、オンラインシステム１１１において、固有のクライアントＩＤとクライアントプロファイルを有し、その両方がクライアントストア２５１に格納されている個々のクライアントオブジェクトで表される。クライアントプロファイルは、プロファイルピクチャおよび／または他の識別情報、地理的位置、並びにクライアントカレンダーを含むことができる、いくつかのクライアント関連の属性フィールドを含む。クライアントモジュール２０３は、クライアントがそれらのクライアントプロファイルを設定および変更するためのコードを提供する。オンラインシステム１１１は、各クライアントが複数のマネージャと通信することを可能にする。オンラインシステム１１１は、クライアントがマネージャとの間で通信、取引の要求、および取引をやり取りすることを可能にする。
【００２２】
クライアントの地理的位置は、クライアントの現在の位置（例えば、それらの計算装置１０１によって提供される情報に基づく）、またはそれらが手動で入力した居住地の自宅住所、近隣、都市、州、もしくは国のいずれかである。クライアントの位置は、特定のクライアントに関連する時限付き在庫の探索基準をフィルタにかけるために、またはデフォルト言語選択を割り当てるために使用され得る。
【００２３】
マネージャモジュール２０５は、マネージャがそれらとオンラインシステム１１１との対話およびリスティングを管理することを可能にするユーザインタフェースを提供し、オンラインシステム１１１の他のコンポーネントによって要求され得るマネージャ関連の情報の処理論理を実行するプログラムコードを備え、それを行うための１つの手段である。各マネージャは、オンラインシステム１１１において、固有のマネージャＩＤとマネージャプロファイルを有し、その両方がマネージャストア２５２に格納されている個々のマネージャオブジェクトで表される。マネージャプロファイルは、マネージャによって所有されるまたは管理される１つまたは複数のリスティングに関連付けられ、マネージャによって管理されるリスティングのそれぞれの取引要求およびリスティングカレンダーのセットを含む、いくつかのマネージャ属性を含む。マネージャモジュール２０５は、マネージャがそれらのマネージャプロファイルおよびリスティングを設定および変更するためのコードを提供する。オンラインシステム１１１のユーザは、マネージャとクライアントの両方であることが可能である。この場合、ユーザは、クライアントストア２５１とマネージャストア２５２の両方における、かつクライアントオブジェクトとマネージャオブジェクトの両方で表されるプロファイルエントリを有することになる。オンラインシステム１１１は、マネージャがマネージャとの間で通信、取引の要求に対する応答、および取引をやり取りすることを可能にする。
【００２４】
クライアントもしくはマネージャのプロファイルの一部として含まれる、または取引を実施するために送信される任意の個人識別情報は、ユーザのプライバシーおよび保護のために暗号化される。例えば、マネージャが宿泊施設へのアクセスを許可してクライアントがそのアクセスの代金を支払う取引が完了すると、取引情報が暗号化されて取引の履歴情報としてデータベース２５０に格納される。
【００２５】
ＩＩ．Ｂ  リスティング
リスティングモジュール２０７は、マネージャがクライアントによる予約のための時限付き在庫をリスト化するためのプログラムコードを備え、それを行うための１つの手段である。リスティングモジュール２０７は、申し出されている在庫を記述するマネージャからのリスティング、開始日、終了日、開始時間および終了時間のうちの１つまたは複数を含むその可用性の時間フレーム、価格、地理的位置、在庫を特徴付ける画像および記述、並びにその他の任意の関連情報を受信するように構成される。例えば、宿泊施設のオンラインシステムの場合、リスティングは、宿泊施設のタイプ（例えば、家、アパート、部屋、睡眠場所他）、そのサイズの表現（例えば、面積、または部屋数）、宿泊施設が使用可能な日付、および価格（例えば、１泊当たり、１週間当たり、１月当たりなど）を含む。リスティングモジュール２０７は、ユーザがビデオ、写真、および他の媒体など、在庫についての付加的な情報を含むことを可能にする。
【００２６】
各リスティングは、オンラインシステムにおいて、マネージャによって提供されるリスティングの情報と固有のリスティングＩＤを含み、その両方がリスティングストア２５３に格納されているリスティングオブジェクトで表される。各リスティングオブジェクトはまた、リスティングを提供するマネージャのマネージャオブジェクトに関連付けられる。
【００２７】
具体的にリスティングの地理的位置に関して、リスティングに関連付けられた位置は、申し出されたリスティングの完全な住所、近隣、都市、および／または国を識別する。リスティングモジュール２０７はまた、外部で使用可能な地理的地図情報を使用して、あるタイプの位置情報（例えば、郵送先住所）を別のタイプの位置情報（例えば、国、州、都市、および近隣）に変換する能力もある。
【００２８】
具体的にリスティングの価格に関して、価格は、在庫の取引を完了するためにクライアントが支払う必要がある金額である。価格は、１日当たり、１週間当たり、１月当たり、および／もしくは１シーズン当たりの金額として指定されてもよく、または他の時間間隔がマネージャによって指定されてもよい。さらに、価格は、宿泊施設の在庫の場合、クリーニング料金、ペット料金、サービス料金、および税金など、付加的な使用料を含むことができる。
【００２９】
各リスティングオブジェクトは、関連付けられたリスティングカレンダーを有する。リスティングカレンダーは、マネージャによって指定された、または（例えば、カレンダーのインポート処理を介して）自動的に判定された、（それぞれが時限付き在庫の独立した項目と考えられ得る）時間期間における時間間隔毎のリスティングの可用性を格納する。つまり、マネージャは、リスティングのリスティングカレンダーにアクセスして、どの時間間隔にリスティングがクライアントによる取引に使用可能であるか、どの時間間隔がマネージャによって利用不可として遮断されているか、およびどの時間間隔がクライアントによってすでに取引されているかを手動で示す。さらに、リスティングカレンダーは、過去のどの時間間隔がクライアントによって予約されたか、遮断されたか、または使用可能であったかを識別することによって、リスティングの可用性に関する履歴情報の格納を継続する。さらに、リスティングカレンダーは、カレンダールール、例えば、在庫に許容される宿泊の最小日数および最大日数を含むことができる。各リスティングカレンダーからの情報は、リスティングテーブル２５３に格納される。
【００３０】
ＩＩ．Ｃ  探索、要求、および取引
探索モジュール２０９は、クライアントから入力探索クエリを受信して、入力クエリにマッチする時限付き在庫および／またはリスティングのセットを返すように構成されているプログラムコードを備え、この機能を遂行するための１つの手段である。探索クエリは、クエリストア２５４にオンラインシステム１１１によって格納されるクエリオブジェクトとして保存される。クエリは、探索位置、所望の開始時間／日付、所望の期間、所望のリスティングタイプ、および所望の価格帯を包含することができ、リスティングの他の所望の属性を含むこともできる。潜在的なクライアントは、探索モジュール２０９から結果を受信するために上記のクエリの全てのパラメータを提供しなくてもよい。探索モジュール２０９は、提出されたクエリのパラメータを満たす、提出されたクエリに応答する時限付き在庫および／またはリスティングのセットを提供する。オンラインシステム１１１はまた、クライアントが探索クエリを提出せずにリスティングをブラウズできるようにすることもでき、この場合、記録される閲覧データは、提出される探索クエリからのいかなるさらなる詳細も伴わずに、クライアントが特定のリスティングを閲覧したことを示すだけとなる。クライアントが、可能な取引を探してさらに入念に見直すために時限付き在庫／リスティングを選択する入力を提供すると、探索モジュール２０９は、どの在庫／リスティングをクライアントが閲覧したかを示す選択／閲覧データを記録する。この情報もまたクエリデータストア２５４に格納される。
【００３１】
取引モジュール２１１は、時限付き在庫を取引する取引契約要求（公式な要求とも呼ばれる）をクライアントが提出できるようにするように構成されているプログラムコードを備え、この機能を遂行するための１つの手段である。動作において、取引モジュール２１１は、特定のマネージャによって申し出されたリスティングの特定の日付範囲など、時限付き在庫の項目を取引する取引要求をクライアントから受信する。取引要求は、クライアントによって送信される標準化された要求書式であることが可能であり、要求へのマネージャによる応答、すなわち、受信された要求書式を受け入れることまたは拒否することのいずれかによって変更されることが可能であり、それによって、合意可能な条件がマネージャとクライアントとの間で達せられる。受信された要求の変更は、例えば、日付、価格、または時間／日付範囲（従って、実際上、どの時限付き在庫が取引されているか）を変えることを含むことができる。標準化された書式は、開始時間／日付、期間（もしくは終了時間）、または、それ以上やり取りをせずに受け入れが拘束力を持つためには含まれなければならないその他のあらゆる詳細をクライアントが記録することを必要とし得る。
【００３２】
取引モジュール２１１は、記入された書式をクライアントから受信して、予約パラメータを含む完成された要求書式を、リスティングに関連付けられたマネージャに提示する。マネージャは、要求を受け入れること、要求を拒否すること、またはパラメータのうちの１つもしくは複数を変更する提案される選択肢を提供することができる。マネージャが要求を受け入れると（またはクライアントが、提案された選択肢を受け入れると）、取引モジュール２１１は、要求が受け入れられたことを示すために、要求および時限付き在庫に関連付けられた受け入れ状況を更新する。クライアントカレンダーとリスティングカレンダーもまた、時限付き在庫が特定の時間間隔で取引されたことを反映するために更新される。本明細書に具体的に記述されていない他のモジュールが次に、クライアントが支払いを完了すること、およびマネージャが支払いを受け取ることを可能にする。
【００３３】
取引ストア２５４は、クライアントによって行われた要求を格納し、この機能を遂行するための１つの手段である。各要求は、要求オブジェクトで表される。要求は、タイムスタンプ、要求された開始時間、および要求された期間または予約指定終了時間を含むことができる。マネージャによる予約の受け入れは、マネージャが時限付き在庫を指定の時間にクライアントに提供するというクライアントとの契約上拘束力を持つ合意であるため、マネージャがそのような合意を承認する必要がある全ての情報が、要求に含まれる。要求に対するマネージャの応答は、受け入れまたは拒否を示す値とタイムスタンプで構成される。
【００３４】
取引モジュール２１１はまた、取引する非公式な要求を交換する能力をマネージャとクライアントに提供することもできる。非公式な要求は、受け入れられた場合にクライアントまたはマネージャを拘束するのに十分なものではなく、内容に関しては、在庫の可用性に関する単なるやり取りおよび一般的な問合せから、オンラインシステム１１１が公式な取引要求に関して記載しているどのような固有の要件にもわずかに及ばない要求まで、様々である場合がある。取引モジュール２１１はまた、非公式と公式の両方の要求が時限付き在庫の需要についての有益な情報を提供するので、非公式な要求を取引ストア２５４に格納することもできる。
【００３５】
需要モジュール２１３は、次に図３に関連して記述される。
【００３６】
ＩＩＩ．需要予測
ＩＩＩ．Ａ  概要
図３Ａは、一実施形態に係る、需要モジュールのコンポーネントおよび動作を示すフロー図である。オンラインシステム１１１において時限付き在庫の需要を予測するために、需要モジュール２１３は、複数の特徴モデル３０５、需要関数３００、尤度モデル３１０、および価格決定モデル３２０を含む一連のモデルおよび関数を使用する。
【００３７】
需要モジュール２１３は、訓練ストア２５６から検索される訓練データのセットを使用して特徴モデル３０５を訓練する。特徴モデル３０５は、リスティングストア２２３のリスティングに関連付けられた時限付き在庫の需要推定を判定するために需要関数３００の一部として使用される。需要推定は、実際には無単位の数値であり得るが、尤度モデル３１０は、所与の時限付き在庫が期限切れの前に取引要求を受信する尤度を判定するために需要推定を使用することができる。価格決定モデル３２０は、モデル３１０によって生成された尤度を利用して、時限付き在庫が多数の異なる試験価格で取引要求を受信する尤度を予測し、従って価格（または特徴モデル３０５からのその他の任意の特徴）の変化により、時限付き在庫が期限切れの前に取引要求を受信する尤度がどのように変わることが予想されるかに関する情報を提供することができる。
【００３８】
需要モジュール２１３は、リスティングがリスティングストア２２３においていくつかの特徴で表される、関連付けられたリスティングからの個々の時限付き在庫に関するデータ上で動作する。需要を予測するために、需要モジュール２１３は、そのような在庫の多くを集約して分析し、需要分析の集約レベルは、実装によって異なることが可能である。例えば、需要予測は、オンラインシステム１１１の全てのリスティングにわたる全てのデータが分析されるように、システムワイドであることが可能である。あるいは、より小さくグループ化されたデータが別々に分析されることが可能である。例えば、オンラインの宿泊施設システムは、シカゴの大都市圏の全ての予約指定リスティング、ケンタッキー州の全ての予約指定リスティング、または国立公園から特定の近さの範囲内にある全てのリスティングの予想される需要を別々に分析することができる。需要のこれらの局所的な推定は次に、それらの特定の地域の需要を予測するために使用される。
【００３９】
特徴を論じる場合、ｍはリスティングを記述する特徴の数を表し、個々の特徴は、ｆ1、ｆ2、ｆ3、．．．、ｆmと表され、リスティングの全ての特徴のセットは、特徴ベクトルｆで表される。所与のリスティングの任意の所与の特徴の値は、整数、浮動小数点数、もしくは２進値などの数値であることが可能であり、または分類別であることが可能である。共通の特徴は、リスティングの価格と、在庫が期限切れになるまでの残り時間を含む。需要モジュール２１３の様々な関数およびモデルを訓練するために使用されるサンプル訓練データの個々のインスタンスの構造についてのさらに多くの情報に関しては、そしてまた、需要モジュール２１３を使用して時限付き在庫についての有益な情報を取得するためには、以下の節ＩＩＩ．Ｃを参照されたい。
【００４０】
価格特徴は、リスティングがマネージャによって申し出される価格である。例えば、オンラインの宿泊施設システムの場合、価格特徴の値は、クライアントが特定の日に宿泊施設を予約するためのリスト化された価格であろう。リスティングのマネージャは、リスティングの期限時間の前に価格を変える場合があり、従ってリスティングは、それが期限切れになる前に複数の価格を有していた可能性がある。
【００４１】
期限切れまでの時間特徴は、時限付き在庫の期限切れの前の時間間隔または時間期間の数として定義される。実装に応じて、これは、日数、時間数、分数などであり得る。オンラインの宿泊施設システムの例を再度使用すると、個々の時限付き在庫の「期限切れ」は、リスティングが予約されようとされる日となる。例えば、１２月２０日の宿泊施設を予約指定するリスティングは、１２月２０日に期限切れになり、従って、期限切れまでの時間特徴の値は、現在の日付から１２月２０日までの日数となる。この場合、オンラインの宿泊施設システムの予約が、典型的には日ベースで行われるため、使用される時間間隔は１日である。しかしながら、オンラインのレストラン予約システムの場合、レストランの予約がより高い頻度でより狭い時間窓において発生するため、時間間隔は１時間であることが好ましいかもしれない。本明細書における例は、期限切れまでの日数を例として使用しているが、他の単位（例えば、時間、分など）が代替として使用されることが可能である。
【００４２】
オンラインシステム１１１の時限付き在庫のリスティングは、価格および期限切れまでの時間特徴に加え、任意の数の特徴を有することができる。これらの付加的な特徴は、オンラインシステム１１１の実装に依存し、時限付き在庫またはリスティングを記述する。例えば、オンラインの宿泊施設システムにおいて、リスティングは、リスト化された宿泊施設の平均的クライアント格付け、リスト化された宿泊施設の地理的位置、リスト化された宿泊施設のベッド数、リスト化された宿泊施設が無線ルータを有するかどうか、またはリスト化された宿泊施設のその他の関連属性を表す特徴を有する場合もある。さらに、特徴は、リスティング自体の品質、例えば、リスティングが受けた閲覧の数、リスティングの宿泊施設の記述の長さ、リスティングを予約したいという要求が、受け入れられる前にリスティングのマネージャによって見直されるかどうか、またはオンラインリスティングのその他の任意の品質を含むことができる。
【００４３】
特徴はまた、リスティングに関連するが個々のリスティングには直接関連してない特徴を含むこともできる。これらの特徴は、例えば、在庫が有効であった（すなわち、まだ期限切れではなかった、または期限切れになる時間に近かった）間のその在庫の所与の項目に関連するリスティングの市場の状況についての情報を提供する。そのような特徴の例は、その在庫と同じ市場における他の在庫を探してその市場においてオンラインシステム１１１上でクライアントによって遂行される探索数である。例えば、オンラインの宿泊施設システムの場合、特徴は、サンフランシスコのノイバレー近隣においてその近隣に位置する在庫の項目と関連する宿泊日の探索数であることが可能である。別の可能な特徴は、注目すべき出来事（例えば、スーパーボウル）が在庫の時間および地理的位置に十分近接して発生するかどうかを示す２進特徴であり得る。
【００４４】
さらに、特徴は、複数の他の特徴間の対話を記述すること、または他の特徴の派生物であることが可能である。例えば、リスティングに関して、それが予約された時間と、それがリスト化された時間との間の平均価格が算出されることが可能である。あるいは、特徴は、２つの他の特徴の値間の相関値を含む場合もある。
【００４５】
需要関数３００は、リスティングの特徴値を使用して需要推定を作り出す任意の関数または統計モデルであることが可能である。一実装において、需要関数は、特徴の特徴モデルを共に適合させて需要推定に対するその特徴の寄与を判定することによって作成される一般化加法モデルである。一般化加法モデルを使用する需要関数３００は、Ｄ（ｆ）＝ｗ1（ｆ1）＋ｗ2（ｆ2）＋．．．＋ｗm（ｆm）の式から成る。ここにＤ（ｆ）は、需要関数３００であり、また出力需要推定でもあり、ｗ1、ｗ2、．．．ｗmは、Ｄ（ｆ）に対する各特徴値ｆ1、ｆ2、．．．、ｆmそれぞれの寄与を判定する特徴モデル３０５のそれぞれの重み関数である。一般化加法モデルの適合は、確率的勾配降下法、ｋｄ木、ベイズ、またはバックフィッティングアルゴリズムを含むいくつかのフィッティングアルゴリズムを使用して完了されることが可能である。これらのアルゴリズムは、特徴モデル３０５と、前の時限付き在庫の訓練データのラベルとの間の部分残差の何らかの損失関数を削減する目的で特徴モデル３０５を反復的に適合させるために使用される。
【００４６】
特徴モデル３０５は、需要推定Ｄ（ｆ）に関連する、時限付き在庫が期限切れの前に取引要求を受信する尤度上での特徴の影響を示す重みに特徴値を関連させる任意のノンパラメトリック統計モデルであることが可能である。各特徴の特性に応じて、異なる統計モデルが、その特徴の可能な値に関する訓練データに基づいて各特徴に適合されることが可能である。例えば、Ｂ−スプライン、３次スプライン、線形フィット、二変量平面フィット、区分定数関数などが全て使用されることが可能である。特徴自体を定義するために、教師ありと教師なしの両方の機械学習技術が使用されて、一般化加法モデルの訓練の前に最初に特徴を判定することが可能である。教師あり学習技術の場合、訓練は、訓練データのラベル以外の他の何らかの信号に基づくことができる。なぜなら、それは、一般化加法モデルを訓練するために代わりに使用されるからである。
【００４７】
プラスのラベルは、期限切れの前にクライアントから取引要求を受信した前の時限付き在庫（ここでは訓練時限付き在庫と呼ばれる）に割り当てられ、マイナスのラベルは、取引要求を受信せずに期限切れになった訓練時限付き在庫に割り当てられる。訓練データ構造と特徴モデル３０５の訓練のさらなる考察が、それぞれ節ＩＩＩ．Ｃと節ＩＩＩ．Ｄにおいて図４Ｂ〜図７Ｂを参照しながら提供される。
【００４８】
需要推定Ｄ（ｆ）に戻ると、需要推定は、訓練データを使用した検証がなければ作動できない無単位の評価基準である。例えば、特定の特徴ベクトルｆAのＤ（ｆA）の値は、０．７３５であり得る。この情報単独では、需要関数３００のどの値が、時限付き在庫の取引要求をその期限切れの前にクライアントから受信する尤度と一致するかを判定しなければ役立たない。尤度モデル３１０は、特徴ベクトルｆを有するリスティングを所与として、需要推定Ｄ（ｆ）を、取引要求を受信する尤度Ｐ（Ｄ（ｆ））にマッピングすることによってこの問題を解く統計モデルである。尤度モデル３１０は、需要Ｄ（ｆ）を推定するために使用される各特徴ベクトルｆに関して同じプラスのおよびマイナスの訓練ラベルを使用することによって訓練される。尤度モデル３１０のさらなる考察が、図８を参照しながら節ＩＩＩ．Ｅで記述される。
【００４９】
価格決定モデル３２０は、リスティングの現在の価格に近い様々な試験価格（または要求に応じたその他のいずれかの任意に選ばれたピボット価格）でのリスティングの取引要求を受信する尤度をモデル化する。需要モジュール２１３は、リスティングのピボット価格での取引要求を受信する尤度を表す開始データポイント周辺の試験データを生成する価格決定モデル３２０を生成する反復処理を使用する。この処理は、以下の節ＩＩＩ．Ｂで概要が説明され、図９を参照しながら節ＩＩＩ．Ｆでさらに記述される。
【００５０】
ＩＩＩ．Ｂ  例示的な処理フロー
図３Ａは、図面のモデル、関数、およびデータストアのそれぞれの間の矢印に従って時限付き在庫の需要関数３００と尤度モデル３１０を訓練するための処理フローを示す。需要モジュール２１３は、訓練ストア２５６からの訓練データを使用して特徴モデル３０５を３３０で訓練する。需要モジュール２１３は次に、訓練データの各サンプルの特徴ベクトル毎の需要関数３００を評価して、各サンプルの特徴ベクトル毎のラベルに基づいて尤度モデル３１０を３４０で訓練する。
【００５１】
図３Ｂは、需要モジュール２１３が需要関数３００と尤度モデル３１０を訓練した後にリスティングを価格決定する処理を示す。対象のリスティングの需要を予測する命令をオンラインシステム１１１から受信すると、需要モジュール２１３は、対象のリスティングに対応する特徴ベクトルｆsをリスティングテーブル２２３から３５０で検索し、それを需要関数３００への入力として使用する。需要モジュール２１３は次に、結果として生じた需要推定Ｄ（ｆs）を、期限切れの前に取引要求を受信する尤度への変換のために尤度モデル３１０に３６０で送信する。需要モジュール２１３は次に、結果として生じた尤度Ｐ（Ｄ（ｆs））を、リスティングの価格決定の変化がリスティングの需要をどのように変え得るかをモデル化する際に使用する価格決定モデル３２０に３７０で転送することができる。
【００５２】
価格決定モデル３２０を生成するために、需要モジュール２１３は、価格特徴をプラスの方向とマイナスの方向の両方で価格間隔だけインクリメントして、期限切れまでの試験時間のセットのそれぞれにおける試験価格を作成することによって、特徴ベクトルｆsの価格特徴の値を３８０で変更し、それにより、試験価格のそれぞれに等しい価格特徴値と、期限切れまでの試験時間のそれぞれに等しい期限切れまでの時間特徴値とを包含する、変更された特徴ベクトル
【００５３】
【数１】
2019516184.tif 000003
【００５４】
と
【００５５】
【数２】
2019516184.tif 000004
【００５６】
を作成する。変更された特徴ベクトルにおいて、価格および期限切れまでの時間以外の他の全ての特徴値は、変更されないままである。新しい特徴ベクトルのそれぞれに関して取引要求を受信する尤度
【００５７】
【数３】
2019516184.tif 000005
【００５８】
と
【００５９】
【数４】
2019516184.tif 000006
【００６０】
が次に、需要関数３００と尤度モデル３１０によって算出され、リスティングの元の尤度Ｐ（Ｄ（ｆs））と共にグループ化される。需要モジュール２１３は次に、特徴ベクトル
【００６１】
【数５】
2019516184.tif 000007
【００６２】
と
【００６３】
【数６】
2019516184.tif 000008
【００６４】
の付加的な試験価格および期限切れまでの試験時間を作成するために、価格特徴を価格間隔だけ、および期限切れまでの時間を時間間隔だけインクリメントし続け、十分なデータポイントが作成されるまで処理が反復される。
【００６５】
価格決定ポイントおよび期限切れまでの時間ポイントの閾値数に達すると、需要モジュール２１３は、試験価格、期限切れまでの試験時間、および取引要求を受信する対応する尤度を処理して、情報のマネージャまたは要求者の目標を達成する価格を識別する。一実施形態において、これは、訓練された回帰木を用いて、試験価格、期限切れまでの試験時間、および尤度を適合させることによって実現され、その回帰木は、入力された（１）期限切れまでのリードタイム、（２）曜日、および／または（３）価格を取り入れて、出力される利用尤度を生成する。どのようにリスティングを価格決定するかに関する新しい価格を識別するために、および／またはある予約尤度を達成するために、適合関数が使用されることが可能である。より一般的には、需要に基づいて尤度推定を生成する需要モジュール２１３の能力は、時限付き在庫のマネージャに、そのマネージャが時限付き在庫の価格を選択する時に考慮することができる情報を提供する。
【００６６】
ＩＩＩ．Ｃ  訓練データラベル
図４Ａ〜図４Ｄは、一実施形態に係る、需要モジュールによって使用される訓練データのラベル付け論理を示している。図４Ａにおいて、１日の時間間隔を有するリスティングカレンダーが示されている。これは、リスティングが日ベースでのクライアントによる予約のために申し出されるだけであることを意味する（クライアントは、隣接する複数日でリスティングの予約を要求する場合もあるが）。図４Ａは、取引ストア２５５から検索されて訓練データとして使用するために別個にストア２５６に転送されることが可能である予約履歴データから訓練データがどのようにサンプリングされるかを示す。図４Ａに示されているタイムラインは、単一のリスティングから取られたデータを表す。リスティングは、１０月２４日の期限時間（または期限日）４００、１０月２日の開始リスティング時間（または開始リスティング日）４１０、および１０月１５日の要求が受信されて受け入れられた時間（または日）４２０を有する。
【００６７】
リスティングの期限時間４００は、時限付き在庫がもはや使用できないまたはオンラインシステム１１１によってクライアントに提示されない時間である。オンライン予約指定システムにおいて、期限時間４００は典型的には、予約指定が始まる時間である。
【００６８】
開始リスティング時間４１０は、リスティングが最初にクライアントにとって使用可能にされる時間および／またはリスティングがマネージャによってオンラインシステム１１１に提供された最初の日である。
【００６９】
要求が受信されて受け入れられた時間４２０は、クライアントからの取引要求がマネージャによって受信されることおよび（公式に）受け入れられることの両方が行われた時間であり、一般的に取引を、双方の当事者を契約上拘束するものにする。
【００７０】
図４Ａの例において、訓練データの個別のサンプルが、開始リスティング日４１０と、要求が受信されて受け入れられた日４２０との間の日ごとに訓練ストア２５６に４３０で記録される。各サンプルは、リスティングが記録された日のそのリスティングの特徴ベクトルｆで構成される。サンプルのラベルは、リスティングの最終結果が分かるまで適用されない。図４Ａの例において、１０月２日から１０月１５日までのそれぞれに関するサンプルは、受け入れられた要求に対応するプラスのラベルが与えられる。なぜなら、リスティングの最終結果が、要求と、その後の、要求が受信されて受け入れられた日４２０におけるその要求の受け入れとであったからである。
【００７１】
いくつかの実施形態において、４２０と期限日４００との間の日に関しては、リスティングがすでに受け入れられて、もはやオンラインシステム１１１でクライアントに提示されていないので、どのサンプルも収集されない。これは、例えば、時限付き在庫が固有であれば発生し得る。時限付き在庫が固有でない（例えば、フライトでの複数のほぼ同一の座席である）場合、システムは、リスティングが持続することを可能にすることができ、従って、時限付き在庫が使い果たされるかまたは期限切れになるまでの時間中、より多くのデータが収集されることが可能である。いくつかの実施形態において、システムは、同じ価格を共有し、各固有でないリスティングを、いくつかの同一の特徴を有する固有のリスティングとして扱う複数のリスティングを定義する。リスティングのグループのメンバの予約は、グループのリスティングのうちの１つに適用されて、残りのリスティングは、持続が許可される。
【００７２】
リスティングが使用可能である間に時間間隔毎の訓練データのサンプルを記録することは、可用性の全期間にわたって全体で、受け入れられる取引要求毎に１つのみのデータポイントを収集することに比べると、分析のために需要モジュール２１３にとって使用可能なデータポイントの数を大幅に増加させる。
【００７３】
図４Ｂは、予約履歴データからの訓練データのラベル付けサンプルの第２の例示的な結果を示す。図４Ｂに示されている例では、期限日４００と開始リスティング日は、図４Ａと同じものである。しかしながら、図４Ｂにおいて、リスティングが開始リスティング日４１０から期限日４００まで使用可能であったにもかかわらず、リスティングのどの取引要求も受信されなかった。その結果、リスティングが使用可能であった日に取得された全てのサンプル４４０は、時限付き在庫が期限切れになる前にリスティングの取引要求が受信されなかったことを示すマイナスの訓練ラベルでラベル付けされる。
【００７４】
取引要求を受信したリスティング、そしてまた取引要求を受信していないリスティングの両方の訓練データのサンプルを取得して、それらを別々にラベル付けすることは、取引要求を受信したリスティングを考慮するだけであるモデルに比べると、需要モジュール２１３にとって使用可能なデータ量をさらに増加させる。
【００７５】
図４Ｃは、予約履歴データから訓練データのサンプルを取得してラベル付けすることに関する第３のさらに複雑な例示的な結果を示す。図４Ｃにおいて、期限日４００と開始リスティング日４１０は、前の２つの例と同じものである。しかしながら、図４Ｃにおいて、リスティングのマネージャは、１０月１５日に取引要求を受信しているが、その後に４５０でその要求を拒否している。これは、さらなる取引要求を受信するためにリスティングを使用可能なままにする。取引要求はそれ以上、要求拒否日４５０と期限切れ日との間に受信されていない。
【００７６】
この状況においては、リスティングの取引要求が受信されてその後に４５０で拒否された日より前の日のサンプルに４３０でプラスのラベルが適用される。なぜなら、要求は、マネージャが受け入れていれば、結果として上手く取引できたはずだからである。リスティングがそれ以上、要求拒否日４５０の後に取引要求を受信しなかったので、第１の要求の後の日のサンプルは、４４０でマイナスのラベルでラベル付けされる。なぜなら、その時間期間中に受信された取引要求がないことは、それより早い時間に受信された取引要求と無関係であり、従ってその時間期間中のリスティングの特徴が、取引要求を引き付けるのに十分な需要を生成することができなかったからである。いくつかの実施形態において、要求拒否日４５０は、拒否された取引要求が受信された日であることが可能である。他の実施形態において、要求拒否日４５０は、取引要求が拒否された日である。あるいは、（図示されていないが）第１の要求が４５０で拒否された後に第２の取引要求が受信されるならば、残りのサンプルは、代わりにプラスのラベルでラベル付けされるであろう。
【００７７】
図４Ｄは、予約履歴データから訓練データのサンプルを取得してラベル付けすることに関する第４の例示的な結果を示す。図４Ｄにおいて、期限日４００と開始リスティング日４１０は、やはり前の例と同じものである。図４Ａにおけるように、取引要求が１０月１５日に４２０で受信されて受け入れられているが、図４Ｄにおいて、リスティングを要求したクライアントが取引要求を取り消して、リスティングがオンラインシステム１１１上で他のクライアントにとって再度アクセス可能になることを可能にしている。取り消された後、リスティングはそれ以上、取引要求を受信していない。図４Ｃと同様の状況において、開始リスティング日４１０から取引要求の受け入れ日４２０までの日数のサンプルは、プラスのラベルで４３０でラベル付けされ、取り消し日４６０にリスティングがクライアントにとって使用可能にされた後、訓練データは、マイナスのラベルで４４０でラベル付けされる。この場合、取り消し日４６０と取引要求の受け入れ日４２０との間の日には、どのサンプルも生成されていない。なぜなら、リスティングがその時間中にクライアントにとって使用可能でないためである。やはり（図示されていないが）、取り消し日４６０の後にリスティングが取引要求を受信したのであれば、取り消し日の後のサンプルは、代わりにプラスのラベルを受けるであろう。
【００７８】
上記のように、個々の訓練データのサンプルは、時間期間４３０と４４０によって示された各日に取得されているが、サンプル４７０Ａ〜４７０Ｄは、具体的には、図５を参照する以下の考察において使用するためにラベル付けされる。
【００７９】
図５は、一実施形態に係る、需要モジュール２１３によって使用される訓練データを格納するための例示的な表を示す。図５は、訓練データの表５００と表５１０という格納されたサンプルに関する２つの例示的な表を示す。表５００は、特徴ベクトルに含まれることが可能である様々な特徴を示す一般的な例であり、その一方で表５１０は、宿泊施設システムにおいて使用されることが可能である単一のリスティングからのサンプル４７０の具体的な例である。
【００８０】
表５００において、各行は、予約履歴データからの、特定の日に関して記録された訓練データの単一のサンプルを表す。各行は、特徴ベクトル（ｆ1からｆmまで）の各特徴の特徴値と、（図４Ａ〜図４Ｄを参照して記述されたように）訓練サンプルが記録された元であるリスティングの最終結果に対応する訓練ラベルとを包含する。この実施形態においては、リスティングに関して取引要求が受信されたことを表すために１という訓練ラベルが使用されており、時限付き在庫が期限切れになる前にどの取引要求も受信されなかった状況を表すために−１という訓練ラベルが使用されている。
【００８１】
表５００の列は、いくつかの例示的な特徴タイプを示し、特徴１と特徴２は量的であり、特徴３は分類別であり、特徴ｍは２進数である。表５００は、特徴ベクトル毎にｍ個の特徴と訓練ラベルとに対応するｍ＋１個の列（その一部は、例示目的のために削除されている）を含む。表５００は、訓練データサンプルの総数Ｎに対応するＮ個の行を含む。
【００８２】
表５１０は、図４Ｄに示されている例示的なリスティングのタイムラインからのデータサンプルの選択を示す。サンプルは、開始リスティング日４１０から要求受け入れ日まで、そしてまた取り消し日４６０から期限日４００までの各日に関して記録されるであろうが、考察の目的で、および説明を容易にするために、サンプル４７０Ａ〜４７０Ｄのみが表に示されている。
【００８３】
表５１０において、列は、価格、期限切れまでの日数、リスト化された宿泊施設の都市、およびリスト化された宿泊施設が無線ルータ（ＷｉＦｉ）を含むかどうかを含めて、オンラインの宿泊施設システムのリスティングに関する例示的な特徴でラベル付けされている。サンプル４７０Ａ〜４７０Ｄは全て、同じリスティングからのサンプルであるので、都市特徴とＷｉＦｉ特徴は、全てのサンプルにわたって同じままであり、その一方で、期限切れまでの日数特徴と価格特徴は、サンプリング期間にわたって変化する。
【００８４】
サンプル４７０Ａは、取引要求が４２０で受信されて受け入れられたのよりも前に記録されたので、１という訓練ラベルが適用される。サンプル４７０Ａは、期限日４００の２０日前の１０月４日に記録されたので、期限切れまでの日数特徴は、２０という値を有する。この例において、１０月４日のリスティングの価格が＄１２０であったので、価格特徴は、１２０という値を有する。サンプル４７０Ｂにおいて、マネージャは価格を＄１００に減じ、サンプル４７０Ａが記録されて以来１週間が経過した。従って、期限切れまでの日数特徴と価格特徴の値が変化して、リスティングの特徴の変化を反映している。＄１００という価格は、サンプル４７０Ｂとサンプル４７０Ｃとの間の日において一定のままである。サンプル４７０Ｃは、要求が受信されて受け入れられた日４２０に記録されたものであり、要求が受信された際の価格が＄１００であったことを示している。この価格が、サンプル４７０Ａの元の価格＄１２０とは異なることに留意されたい。
【００８５】
価格（および潜在的には他の特徴）のこの差は、因果関係の問題をもたらす。なぜなら、価格を下げることが、リスティングの取引要求を提出するようにクライアントを誘導することにおける原因因子であったかどうかが分からないからである。例えば、取引要求が＄１２０という価格では受信されなかったであろうが、後で価格が＄８０に下げられた時に受信されたならば、価格が＄１２０であった日の訓練データサンプルの１という訓練ラベルは、価格が期限切れまで＄１２０のままであったならば取引要求の受信をもたらさなかったかもしれない特徴値（例えば、価格＄１２０）のプラスの結果を示す。
【００８６】
需要モジュール２１３は、これらのタイプの因果関係に、実施形態に応じて異なって対処することができる。いくつかの実施形態において、サンプルが、取引要求の受信日４２０に記録されたサンプルとは（サンプル間の異なる特徴の数、最大差閾値、または別の測定基準に基づいて）本質的に異なる場合、そのサンプルは捨てられる。別の実施形態において、サンプルは、要求が受信された日に記録されたサンプルとどれくらい異なるかに基づいて、より少ない重みが与えられる（例えば、０．５というラベルが与えられることもある）。さらなる別の実施形態において、「要求までの日数」または「クライアント要求が受信された際の価格」特徴などの付加的な特徴が特徴ベクトルに付加されて、需要関数３００へのサンプルの寄与の差を反映することが可能である。一部の例では、異なる特徴を有するこれらのサンプルは、データのラベル付け処理を簡素化する目的で、またはそれらが需要予測モデル上に最小の影響を及ぼすと考えられるため、全重みが与えられる。別の実施形態において、開始リスティング日４１０と、要求が受信された日４２０との間における価格の分布の平均値、中央値、または他の測定値は、別個の特徴である。
【００８７】
ＩＩＩ．Ｄ  特徴モデル
図６は、一実施形態に係る、特徴モデルｗ（ｆ）を示す。図６は、特徴１の値を需要関数３００の重みに関連付ける特徴モデル３０５を示す。統計モデル６００は、需要モデル３００の出力Ｄ（ｆ）と、個々のサンプルの対応する特徴値ｆとの間の部分残差である訓練データポイント６１０への適合である。訓練処理の各反復により残差が変化して、統計モデル６００がデータに適合される。確率的勾配降下法およびバックフィッティングアルゴリズムなどのアルゴリズムは、需要モデル３００の全ての特徴の統計モデル６００間の部分残差を最小にしようとする。訓練データセットを反復処理した後、統計モデル６００は、所与の特徴値毎に重みを出力する特徴モデル３０５に収束する。データを適合させるために、Ｂ−スプライン、３次スプライン、任意のタイプの回帰、（分類データおよび２進データのための）ディラックのデルタ関数、またはこれらの方法の任意の組合せを含む多くの統計方法が使用されることが可能である。オンラインシステム１１１の管理者は、データを最もよく表すために特徴モデル３０５を構成することができる。適合した後に、特徴モデル３０５は、特徴値の最大範囲にわたって−１と１との間の荷重値を有することになる。いくつかの実施形態において、特徴値は、範囲を０と１との間に制限するように標準化される。特徴が分類別または２進であれば、統計モデル６００は単純に、特徴分類から荷重値へのマッピングであるか、または重みの判定に使用するために設計されたスケールに分類データを変換することに基づくことが可能である。
【００８８】
図７Ａ〜図７Ｂは、一実施形態に係る、例示的な特徴モデル３０５を示す。図７Ａは、訓練データの典型的なセットを用いると価格特徴の特徴モデル３０５がどのようになり得るかの例を示す。この場合、統計モデル７００は、価格データに関するスプラインフィットの典型である。この統計モデルに基づくと、価格は、非常に安いリスティングの需要にマイナスの影響を及ぼし（恐らくはクライアントが、だまされることを懸念するため）、安いが手頃な価格レベルでは、価格は、リスティングの需要にプラスの影響を及ぼす。価格が上がるにつれて、需要に対する影響は、その価格レベルのクライアントがより融通性のある消費性向を有し、価格特徴が需要にさほどマイナスの影響を及ぼさないあるポイントまで、ますますマイナスになる。
【００８９】
図７Ｂは、訓練データの典型的なセットを有する「期限切れになる前の日数」特徴の典型的な特徴モデル３０５を示す。この例に使用されている統計モデル７１０は、リスティングがその期限日の前にポストされるのが早ければ早いほど、そのリスティングの需要が高くなる可能性が高いことを示している。これらの例示的な特徴モデル３０５のいずれも、典型的な結果とは異なる場合があり、本明細書では、オンラインシステム１１１の文脈において特徴モデル３０５の機能性を説明する例としてのみ使用される。
【００９０】
ＩＩＩ．Ｅ  尤度モデル
図８は、一実施形態に係る、需要モジュール２１３によって使用される尤度モデル３１０を示す。需要モジュール２１３が特徴モデル３０５を訓練すると、需要モジュール２１３は、訓練データのいくつかのサンプルの特徴ベクトルｆのセットを使用し、需要関数３００を使用してサンプル毎の推定された需要Ｄ（ｆ）を出力することができる。尤度モデル３１０を訓練するために、需要モジュール２１３は、推定された需要Ｄ（ｆ）のラベル付けされた値に尤度関数８００を適合する。尤度関数８００は、プラスのラベルを与えられたＤ（ｆ）を特徴ベクトルｆが有する尤度、その他の言い方をされるならば、所与のサンプルが時限付き在庫の期限切れの前に取引要求を受信した尤度を判定する二進分類の問題を解く関数である。図８において、マイナスのラベルは、白丸８１０で表されており、その一方でプラスのラベルは、黒丸８２０によって表されている。尤度関数８００は、点が黒である尤度をサンプルの推定された需要に基づいて近似する。
【００９１】
いくつかの実施形態においては、プラットスケーリングアルゴリズムが、尤度関数８００として使用される。需要関数に適用されるプラットスケーリングアルゴリズムは、下記の形式のものとなる。  
Ｐ（Ｄ（ｆ））＝（１＋ｅｘｐ（αＤ（ｆ）＋β））-1
ここにαとβは、学習定数である。最大尤度法を使用してプラットスケーリングアルゴリズムを訓練し、それがこの２進分類の問題を最適に解けるようにするために、ヒンジ損失関数などの損失関数または別の同様の技術が使用される。
【００９２】
需要モジュール２１３が尤度関数８００を訓練すると、尤度モジュール３１０は、推定された需要Ｄ（ｆ）を入力として受信し、時限付き在庫が期限切れの前に取引要求を受信する尤度Ｐ（Ｄ（ｆ））を出力することができる。
【００９３】
ＩＩＩ．Ｆ  価格決定モデル
図９Ａ〜図９Ｃは、リスティングの価格決定モデル３２０を作成する処理を示す。需要モデル３００（特徴モデル３０５を含む）と、尤度モデル３１０（尤度関数８００を含む）との両方が、訓練データのサンプルを使用して訓練された後、需要モジュール２１３は、任意の特徴ベクトルｆを、取引要求を受信する尤度Ｐ（Ｄ（ｆ））に変換する能力を有する。
【００９４】
試験価格の範囲内で取引要求を受信する尤度を提供するために、需要モジュール２１３は、試験価格のセット（リスティングのピボット価格を含む）に等しい価格特徴の値と、変化しないままの残りの特徴の値とを用いて、変更された特徴ベクトルを作成する。需要モジュール２１３は次に、試験需要推定と、変更された特徴ベクトル毎の取引要求を受信する対応する試験尤度とを判定する。
【００９５】
需要モジュール２１３は次に、試験価格と、取引要求を受信する対応する試験尤度とを処理して、情報のマネージャまたは要求者の目標を達成する価格を識別する。これは、試験価格および尤度データポイントを適合することによって実現されることが可能である。例えば、モデルが試験価格および尤度データポイントに適合されて、滑らかな単調に減少する価格決定モデル３２０を作成することが可能である。この処理は、図９Ａ〜図９Ｂに示されている。
【００９６】
図９Ａにおいては、価格特徴の値と、時限付き在庫の取引要求を受信する尤度とが描かれている。データポイント９００は、対象のリスティングがそのピボット価格（例えば、現在の価格）で取引要求を受信する現在の尤度を表す。需要モジュール２１３は次に、価格特徴の値を価格間隔９２０だけプラスにおよび／またはマイナスにインクリメントすることによって試験データポイント９１０を作成する。価格間隔９２０は、対象のリスティングの価格特徴の元の値のうちのある量または比率であることが可能である。いくつかの例においては、異なるプラスの価格間隔およびマイナスの価格間隔がある。
【００９７】
需要モジュール２１３は、元の価格のいずれかの方向の価格間隔で価格特徴の値のインクリメントを継続する。この処理は、試験価格の閾値範囲がカバーされるまで、または閾値数のデータポイントが生成されるまで継続する。これらの試験価格は、例えば、現在の価格の２倍／半分と同じくらい高い／低い、またはより高い／より低い場合もある。十分な試験価格が生成されると、データポイントは、図９Ｃに示されているように価格関数９３０で適合される。生成された価格と、尤度データとを適合するために任意の関数が使用されることが可能である。価格関数９３０は、ワイブル分布であることが可能である。
【００９８】
価格関数９３０を試験価格と、結果として生成された尤度とに適合した後、需要モジュール２１３は、価格関数９３０をマネージャに提示して、対象のリスティングの価格設定に役立てることができる。あるいは、需要モジュール２１３は、価格内部情報をマネージャに提供することができる。一例において、価格内部情報は、閾値尤度に基づくことができる（取引要求を受信する閾値尤度をもたらす最高価格）。例えば、閾値尤度が尤度９４０に設定されるならば、結果として生じる価格提示は、価格９５０であろう。他の例において、価格は、価格と尤度をかけた値が最大になるように選ばれることが可能である。例えば、価格９７０と尤度９６０をかけて価格関数９３０が最大になれば、価格９７０は、ユーザのための価格提示であり得る。いくつかの例においては、より良い価格内部情報をもたらす、価格と、取引要求を受信する尤度との間の関係を判定するために、収入関数が学習される。例えば、学習定数ａとｂに基づく価格関数９３０に関して、収入関数は、
【００９９】
【数７】
2019516184.tif 000009
【０１００】
であることが可能である（ここにｐsは、対象のリスティングの仮の価格である）。この場合、この収入関数の訓練データは、様々なリスティングに関する前の価格予測と、それらの価格予測の対応する尤度値になる。さらに、他の測定基準が、ユーザへの価格内部情報として提供するために使用されることが可能である。
【０１０１】
ＩＩＩ．Ｇ．  回帰木で圧縮された特徴ベクトル機械モデル
上述されているように、図９Ａ〜図９Ｃは、リスティングに関する価格曲線および価格決定モデル３２０を作成する処理を示している。あるいは、記述されているシステムは、リスティング毎の回帰木を使用して、リスティングに関する一般化モデルおよび価格曲線を生成することができる。システムは、ある数（Ｅｒ）の期限切れまでの時間（例えば、リスティングの期限切れまでの１日から６０日）においてある数（Ｎ）の価格（例えば、現在の価格の１０％から２００％）で尤度モデルを（例えば、それぞれのリスティングおよび期限切れまでの日数毎に）使用して、各価格および期限切れまでの各時間で取引要求を受信する尤度を算出する。次にシステムは、生成されたデータポイント（Ｎ×Ｅｒ個のデータポイント）のそれぞれを取り出し、回帰木を訓練してＮ×Ｅｒ個のデータポイントを一般化モデルに「圧縮」する。例えば、システムが１泊当たり１０個の価格で１２０泊の範囲を使用する場合には、システムは、１２００個（１０個の価格／１泊×１２０泊）のデータポイントを使用して回帰木を訓練して、一般化モデルを作成する。このアプローチは、前述されている価格決定モデルに勝る少なくとも２つの利点を有している。第１に、それは、複数の独立した、１泊毎の曲線とは対照的に、全ての宿泊数にわたる各リスティングに関する単一のモデルを作り出す。従って、任意の長さのリードタイム、または期限切れまでの時間にわたる回帰木で圧縮された価格曲線での外挿のさらに大きな可能性がある。第２に、以降で記述されている実験結果を通じて示されているように、回帰木で圧縮された曲線は、生の（raw）価格と尤度とのマッピングをより忠実に再現する。
【０１０２】
回帰木を実装するために、需要モジュール２１３は、（１）期限切れまでのリードタイム、（２）曜日、および／または（３）価格を、取引要求を受信する尤度にマップするリスティング毎の回帰木を訓練することができる。需要モジュール２１３は、正規化された機械学習モデル出力の結果である較正された尤度を使用して、現実世界の予約確率を反映することもできる。一例においては、尤度は、ロジット関数を使用して較正される。望ましくないおよび／または不十分に価格決定されたリスティングにおいて発生する可能性がある非常に低い尤度を分離するのに役立つように、ラベルに関してロジット変換が選ばれることが可能である。一実施形態においては、モデルは、分岐毎に多くとも９つのレベルおよび少なくとも２つのリーフを含む。代替的実施形態は、最大深度を７または８まで減らして、スペースを節約する。他の実施形態は、分岐毎に他の数のレベルまたはリーフを有することができる。モデルは、所与のリスティングに関する価格内部情報を判定する際に使用するために訓練ストア２５６内に格納される。
【０１０３】
図１０は、一実施形態に係る、１つのリスティングのモデルに関する例示的な木の部分１０００を示している。このイラストにおいて、モデルの特徴は、リードタイム１００１、価格１００２、および曜日１００３である。リーフ値１０２０（例えば）は、例えば木においてそのポイントで終わる尤度である。リーフ値１０２０は、例えばロジット尤度であることが可能である。各ノードは、リスト化された特徴の値に基づいて分岐する。例えば、特徴１００１に関するノードにおいて、リードタイムが２０以下である場合には、回帰木は、上の分岐１０１０を辿る（ノードからノードへの、および木におけるリーフへの経路は、１０１０および１０１１のような破線によって示されている）。あるいは、特徴１００１に関するノードにおいて、リードタイムが２０超である場合には、回帰木は、下の分岐１０１１を辿る。この処理は、各ノードにおける回帰木モデルへの各入力に関して、リーフ値１０２０が到達されるまで継続する。
【０１０４】
図１１は、一実施形態に係る、３つの異なる価格比での別々の量のリードデイ（lead day）での２つの例示的なリスティングに関する予約要求を受信する生の尤度１１０１、１１０２、１１０３および回帰木で圧縮された尤度１１１１、１１１２、１１１３を示している。価格比は、ピボット価格または現在の価格に対する試験価格の比率である。回帰木モデルによって提供された、回帰木で圧縮された尤度１１１１、１１１２、１１１３は、生の曲線１１０１、１１０２、１１０３から、より鋭い山および谷のうちのいくつかをフラットにしているということに留意されたい。
【０１０５】
回帰木モデルは、上述の価格決定（例えば、ワイブル）モデルと比較されることが可能である。１つの例示的な比較が、オンライン予約システムにおいておよそ１，９００個のランダムに選択されたリスティングに関して遂行された。各リスティングおよび期限切れまでの今後の時間に関して、需要モジュール２１３は、１）生のモデル出力、２）ワイブル近似、３）回帰木近似という３つの尤度源（likelihood source）から価格内部情報を計算した。方法１と比較した方法２および方法３に関する誤差が、下記の式に従って各リスティングに関して計算された。
【０１０６】
【数８】
2019516184.tif 000010
【０１０７】
ここにｌは、リードタイム指標であり、Ｌは、リードタイムの数であり、ｐは、生の（ｒ）またはおよその（ａ）価格であり、
【０１０８】
【数９】
2019516184.tif 000011
【０１０９】
は、全ての生の価格にわたる平均である。これは、評価ウィンドウ（例えば、１２０泊）にわたる特定の近似の正規化された「パーセント誤差」と解釈されることが可能である。
【０１１０】
図１２は、一実施形態に係る、生のモデル出力に対するワイブル近似および回帰木近似に関する各誤差値範囲内での試験セットにおけるリスティングの数の累積頻度のプロットを示している。ワイブル近似（白い棒、全般的に短い棒）は、分布の末尾において著しく多くのまとまりを有しており、とりわけ、試験セットにおけるリスティングのうちの約２５％が、１０％以上のワイブル誤差レベルを有していた。１）多くの場合における生の価格の曲線／尤度の曲線は、「Ｓ字」形状であり、ワイブル近似は、それらの現在の形式において、より低い価格ポイントに関するフラットな領域を失うこと、および２）全ての尤度が低い場合には（例えば、リスティングが非常に過剰に価格決定されている場合においては）、提示される価格は、曲線における小さな誤差に対してきわめて敏感になり、非常に小さなワイブル誤差（とりわけ、高い価格ポイントにおける）が、出力における大きな誤差をもたらし得ることという少なくとも２つの源から誤差が生じる。
【０１１１】
図１３Ａおよび図１３Ｂは、一実施形態に係る、誤差の第１の源の例を示している。図１３Ａは、単一のリスティングに関する生の価格の曲線と尤度の曲線とを期限切れまでのリードタイムの関数として時間と共に示している。図１３Ｂは、同じ曲線のワイブル近似を示している。図においては、リードタイムは、最も上の曲線１３００、１３１０から最も下の曲線１３０３、１３１３へ減少する。図１３Ａおよび図１３Ｂにおいて示されているように、この例における生の価格の曲線／尤度の曲線は、「Ｓ字」形状であるが、ワイブル近似は、より低い価格ポイントに関するフラットな領域を失っている。
【０１１２】
図１４は、一実施形態に係る、例示的なリスティングに関して、生の尤度、圧縮された（回帰木の）尤度、およびワイブル尤度についてリードタイムに対してプロットされた価格における誤差を示している。最も下のライン１４０２（ワイブルで導き出された価格を表している）は、生のライン１４０１および回帰木で圧縮されたライン１４０３の両方よりも著しく下にあるということに留意されたい。
【０１１３】
回帰木モデルの利点は、それらが価格の外挿のための基準として使用されることが可能であるということである。図１５は、一実施形態に係る、０日から１８０日までのリードタイム間隔でのサンプルリスティングに関する生の技術１５０１、ワイブル技術１５０２、および回帰木モデル技術１５０３についての提示された価格を示している。１２０日のリードタイムを超える全ての値が外挿され、従って生の曲線およびワイブル曲線は、１２０日で止まっている。他の例と同様に、回帰木モデルは、価格の外挿のための基準を提供することに加えて、生の価格のデータをより近く近似する。回帰木モデルによって生成された予約の圧縮された尤度上で付加的処理が遂行されることが可能である。例えば、一実施形態においては、訓練ウィンドウの終わりの後に発生する高いレベルの、価格に影響を与える変化を取り込む目的で、モデルによって生成された圧縮された尤度を調整するために他の特徴（例えば、外部需要）が使用される。システムは、回帰木モデルを訓練した後にリスティングに影響を与える変化の表示を受信する場合がある。例えば、環境における出来事または変化が、リスティングに関する需要を変える場合がある。システムは、変化の表示に基づいて、時限付き在庫が期限切れまでの時間の外挿セットのそれぞれにおいて取引要求を受信する尤度を調整することができる。
【０１１４】
回帰木で圧縮された曲線１４０３を判定すると、需要モジュール２１３は、曲線１４０３からの一部分またはデータをマネージャに提示して、対象のリスティングの価格設定に役立てることができる。あるいは、需要モジュール２１３は、価格内部情報をマネージャに提供することができる。例えば、価格内部情報は、閾値尤度に基づくことができる（取引要求を受信する閾値尤度をもたらす最高価格）。他の例において、価格は、上述したように、価格と尤度をかけた値が最大になるように選ばれることが可能である。
【０１１５】
Ｖ．閾値化技術
Ｖ．Ａ．  閾値化およびアンカー価格
一実施形態においては、需要モジュール２１３が価格を出力した後に、１つの付加的閾値化ステップが適用されることが可能である。このステップにおいては、アンカー価格（例えば、閾値価格）が確立され、それは、例えば、（以前の予約を伴うリスティングに関する）予約価格の中央値、またはそのリスティングに関する市場価格およびモデルの価格のパーセンタイルの最大値（例えば、１０パーセンタイル）であることが可能である。市場は、リスティングの地理的位置およびタイプに基づいてなど、リスティングに関して格納されている特徴データのセットに従って定義されることが可能である（例えば、宿泊施設予約指定システムにおいて、１ベッドルームアパートメントなど）。需要モジュール２１３は、例えば、マネージャに示される価格提示がアンカー価格の７０％を下回らないように、およびアンカー価格の１２０％を上回らないように、価格提示を限度設定する。
【０１１６】
Ｖ．Ｂ．  マルチセグメント閾値
この技術は、いつ上限閾値を下げるべきか、または下限閾値を上げるべきかを判定するために、予約要求を受信するモデル出力尤度を使用する。取引要求を受信する高い尤度をマネージャが有する場合には、より低い価格をモデルが提示しないことを確実にするために下限閾値が上げられることが可能である。取引要求を受信する低い尤度をマネージャが有する場合には、より高い価格をモデルが提示しないことを確実にするために上限閾値が下げられることが可能である。例示的な一実施形態においては、下限閾値は、アンカー価格（もしくは閾値価格）のおよそ７０％から始まるか、またはアンカー価格（もしくは閾値価格）のおよそ７０％に至り、上限閾値は、アンカー価格（もしくは閾値価格）の１２０％から始まるか、またはアンカー価格（もしくは閾値価格）の１２０％に至る。
【０１１７】
一実施形態において、モデル出力尤度は、下記のようなシグモイド関数に等しいことが可能である。  
尤度＝シグモイド（傾き×ｓ＋オフセット）
【０１１８】
上記の方程式において、ｓは生のモデル出力であり、傾きおよびオフセットは、例えばプラットスケーリングからの、学習されたパラメータである。ｓが非常に大きいか、または非常に小さい場合には、算出された尤度は、シグモイド関数のフラットな領域に入る。従って、取引要求を受信する予測される尤度は、価格変化に対してあまり敏感ではなくなり、モデルは、価格が上がった場合に予約尤度を過大に推定する可能性がある。
【０１１９】
同じまたは異なる実施形態において、時間の大部分（例えば、８０％）での予約されるリスティング宿泊の価格を下げる提示がマネージャに対して行われることが可能である。これに対処するために、リスティング宿泊が、モデルに従ってその現在の価格で予約されることになる高い尤度を有する場合には、システムは、より低い価格を価格内部情報として申し出ないことが可能である。あるいは、リスティング宿泊が、モデルに従ってその現在の価格で予約されることになる非常に低い尤度を有する場合には、システムは、より高い価格を内部情報として申し出ないことが可能である。
【０１２０】
上記の閾値を実装するために、下記の条件が使用されることが可能である。
（１）尤度（ＰＲ）≦ＣｕｔｏｆｆLowの場合には（ここにＰＲは、価格比（例えば、乗数×閾値価格）であり、尤度（ＰＲ）は、ＰＲでの予約要求をマネージャが受信する尤度を指しており、ＣｕｔｏｆｆLowは、予約尤度に関する下限閾値である）、価格比に関する上限をＰＲに変え、
（２）尤度（ＰＲ）≧ＣｕｔｏｆｆHighの場合には、価格比の下限をＰＲに変える。
【０１２１】
提案されている方法による例示的な提示されるカットオフは、システムまたはマネージャ自身が価格内部情報をどれぐらい控えめまたは積極的であるように設定するかに応じて、控えめな値、ＣｕｔｏｆｆLow＝０．１、ＣｕｔｏｆｆHigh＝０．８と、積極的な値、ＣｕｔｏｆｆLow＝０．２、ＣｕｔｏｆｆHigh＝０．３５との間において変わり得る。悪い提示をよりよく訂正するために、システムは、ＣｕｔｏｆｆHighの値をより低く設定し得る。モデルが、予約される宿泊に関して低い予約尤度を予測し、例えば、予約される宿泊のおよそ半分が、０．５未満の予約の尤度を有するということを分析が示しているという理由で、システムは、それらの宿泊に関してさらに低い価格を提示し得る。
【０１２２】
一実施形態において、尤度（ＰＲ）≧ＣｕｔｏｆｆHighである場合、および尤度（１．８×ＰＲ）＜０．１である場合には、システムは、上限の価格閾値を１．１×ＰＲに変える。この特定の実施形態は、提案される価格内部情報をより控えめに増大させる。なぜなら、モデルが、外挿される価格に関する尤度を必ずしも予測することができるとは限らないからである。この例示的な実施形態は、著しく異なる価格の内部情報を提示することになる特別な出来事（例えば、リスティングの近くでの週末の間の町におけるスーパーボウル、または他の任意の珍しいもしくは予期せぬ現実世界の出来事）の状況を考慮に入れない。このような特別な出来事に対処するために、このような特別な出来事が検知された場合には、上限閾値が引き上げられる。
【０１２３】
Ｖ．Ｃ．  出来事（event）の検知
この技術は、リスティングに関するクライアント需要の履歴におけるスパイクを、今後発生するであろう（通常は周期的な）現実世界の出来事の再発生の前に使用して、それらの出来事と、それらの出来事に関する需要との両方を、それらの発生または再発生の前に検知する。システムは、それらの出来事が発生するであろうという判定された知識を使用して、予想された需要に基づいて、マネージャに提案される価格内部情報に関する閾値を引き上げ、それによってマネージャは、そのような出来事の前後の時間期間中のさらに高い価格のさらに適切な範囲を知らされる。
【０１２４】
一実施形態において、システムは、今後のそれぞれのＤＳCheckin（契約された時限付き在庫へチェックインされた日）日に関して需要スコアを生成することができる。高い需要スコアは、出来事を示す。システムは、在庫に関する履歴をグループ化するために、ＤＳNight（期限切れまでの日数）の代わりにＤＳCheckinを使用すること、および／またはＤＳLead（時限付き在庫の予約と、予約された日との間における日数）を使用することも可能である。
【０１２５】
出来事を検知するために、システムは、様々な時間期間にわたる需要を判定することができる。需要は、リスティングを予約したいという要求のカウントに基づいて、ＤＳCheckinコンタクト（契約された時限付き在庫をクライアントが使用しているという肯定的なサーバ表示）またはＤＳNightコンタクトの関数として判定されることが可能である。需要は、予約したいという要求のカウントを、ＤＳCheckinもしくはＤＳNightによって、リスティングのグループによって、例えば、近隣、都市によって、もしくは時間のウィンドウ内で、例えば、３日間の期間にわたる需要、週末にわたる需要、もしくは１週間もしくは２週間の期間にわたる需要、または他の集約でグループすることなど、集約された測定に基づくことも可能である。
【０１２６】
一実施形態において、システムは、取引される時限付き在庫へのクライアントによるチェックインの日（ＤＳCheckin）におけるコンタクトを集約することによって需要を判定する。一例において、ＤＳCheckinにおけるコンタクトの数のカウントに関するデータは、一実施形態によれば、週末が平日よりも高いＤＳCheckinを有するという平日効果、およびいくつかの季節が他の季節よりも平均して高いＤＳCheckinを有するという季節効果を示す。別の実施形態においては、ＭNight（リスティングに関して契約された宿泊数／日数）がＤＳCheckinの代わりに使用されることが可能である。ＤＳCheckinに基づく需要の例は、出来事のほとんどの参加者（クライアント）が、出来事の最初の日にではなくともその非常に近くで、取引される時限付き在庫へのチェックインに参加することになるという観察に基づく。対照的に、予約および予約要求（ＤＳNight）は、出来事の前のさらにいっそう長い時間期間にわたって分散され得る。
【０１２７】
一実施形態においては、ＤＳCheckinのカウントによる日の最も高い閾値パーセンテージが、出来事としてフラグ設定される。このＤＳCheckinおよびコンタクトデータは履歴データであるが、それらは、毎年同じ日にまたは同じ日の近くで発生する今後の出来事を予測するために使用されることが可能である。例えば、郡が毎年同じ日または週末にチーズフェスティバルを有する場合には、以前の年からその位置におけるリスティングを探して以前のコンタクト／ＤＳCheckin情報を見ることによって需要を予測するためにコンタクトおよびＤＳCheckin情報が使用されることが可能である。
【０１２８】
検知された出来事の付近の需要は、リードデイの需要（例えば、３０日、６０日）を使用してさらに特徴付けられることができる。ここでは、システムは、ＤＳCheckinの日の周辺のリードデイ内の全ての日からのコンタクトのカウントを集約することができる。出来事の周辺のリードデイの全期間にわたるコンタクトのこの集約カウントは、出来事の周辺の需要がどのようなものであるかの実態を、ＤＳCheckin上のみでのコンタクトのカウントが提供できるよりも十分に提供することができる。一実施形態においては、ＤＳCheckinの日の周辺のリードデイの期間にわたるコンタクトのカウントによってその日の最大パーセンテージ（例えば、５％）を選択することにより、出来事が識別される。
【０１２９】
出来事が検知されると、システムは、価格内部情報を提示するために使用されることが可能である任意の最小価格比および最大価格比が、出来事のない時間期間中に通常なら提示されることになるよりも著しく高い価格の内部情報の可能性を可能にするために変えられること（例えば、引き上げられること）が可能であるということを需要モジュール２１３に指示するために出来事の日付を使用することができる。一実施形態においては、価格比上での特定の新しい上限および下限が、需要モジュール２１３に提供される。これは、リスティングまたは特定の時限付き在庫に関して普段なら提示されることになるよりも著しく高い価格の内部情報の作成を必ずしも保証しないが、出来事中の（上述のように測定された）需要履歴は、これが当てはまる可能性をさらに高める。
【０１３０】
上述の記述は、出来事を単一の日としてマークすることを示しているが、実際には、多くの出来事が複数の日にわたるであろう。従って、システムにおいては、出来事であるとして検知された複数の日が、出来事としてマークされることが可能である。システムは、出来事としてマークされたこれらの日を、知られているまたは見つけられた現実世界の出来事と相関付けて、この情報を、価格内部情報を提供する際にマネージャに提供することができる。なぜなら、これは、通常の価格から著しく外れた内部情報がなぜ提供されているかをマネージャに知らせる上で役立つことができるからである。さらに、出来事であるとしてシステムによってマークされた日は、現実世界の出来事のスケジュールされた日と厳密には相関しない場合がある。これは、時限付き在庫に関して人々がどのように取引するかと、実際の出来事がいつ起こるかとの間における差に起因する場合がある。例えば、宿泊施設の予約指定に関して取引するクライアントは、出来事の日についてだけでなく、出来事の前または後の日についても宿泊施設に関して取引する場合がある。
【０１３１】
Ｖ．付加的な考慮
本記述の一部は、情報上での動作のアルゴリズムおよび記号表現の点から本発明の実施形態を記述している。これらのアルゴリズムの記述および表現は、データ処理の当業者によって、自分達の仕事の内容を他の当業者に効率的に伝えるために広く使用される。これらの動作は、機能的、計算的、または論理的に記述されているが、コンピュータプログラムまたは等価の電気回路、マイクロコード他によって実装されるものと理解される。さらに、一般性を失うことなく、動作のこれらの配置をモジュールと呼ぶことが時には便利であることも分かっている。記述された動作およびそれらの関連付けられたモジュールは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組合せにおいて具現化されることが可能である。一実施形態において、ソフトウェアモジュールは、記述された一部または全てのステップ、動作、または処理を遂行するためにコンピュータプロセッサによって実行されることが可能であるコンピュータプログラムコードを包含する持続的コンピュータ可読媒体を備えるコンピュータプログラム製品で実装される。
【０１３２】
最後に、本明細書に使用されている言語は主に、可読性および教育目的で選択されており、本発明の主題を叙述するまたは制限するために選択されたものではない場合がある。従って、本発明の範囲は、この詳細な説明によってではなく、むしろ本明細書に基づく出願上で生じるあらゆる特許請求の範囲によって限定されることを意図されている。従って、本発明の実施形態の開示は、本発明の範囲を例示するものであり、限定するものではないことを意図されており、本発明の範囲の例は、以下の特許請求の範囲に記載される。
【図１】
2019516184.tif 000012
【図２】
2019516184.tif 000013
【図３Ａ】
2019516184.tif 000014
【図３Ｂ】
2019516184.tif 000015
【図４Ａ】
2019516184.tif 000016
【図４Ｂ】
2019516184.tif 000017
【図４Ｃ】
2019516184.tif 000018
【図４Ｄ】
2019516184.tif 000019
【図５】
2019516184.tif 000020
【図６】
2019516184.tif 000021
【図７Ａ】
2019516184.tif 000022
【図７Ｂ】
2019516184.tif 000023
【図８】
2019516184.tif 000024
【図９Ａ】
2019516184.tif 000025
【図９Ｂ】
2019516184.tif 000026
【図９Ｃ】
2019516184.tif 000027
【図１０】
2019516184.tif 000028
【図１１】
2019516184.tif 000029
【図１２】
2019516184.tif 000030
【図１３Ａ】
2019516184.tif 000031
【図１３Ｂ】
2019516184.tif 000032
【図１４】
2019516184.tif 000033
【図１５】
2019516184.tif 000034
【国際調査報告】
2019516184.tif 000035
2019516184.tif 000036
2019516184.tif 000037