JP2018503172A - 時限付き在庫の需要予測 - Google Patents

Abstract

本開示は、時限付き在庫の価格に基づいて需要を予測するための方法を含む。オンラインシステムは、時限付き在庫のマネージャと複数のクライアントとの間の接続を提供する。オンラインシステムは、マネージャの時限付き在庫のリスティングをオンラインシステムのクライアントに提供する。マネージャは、リスティングの時限付き在庫の価格を指定する。需要関数は、リスティングと時限付き在庫の特徴に基づいて時限付き在庫の需要を予測する。オンラインシステムは、予測された需要に基づいてオンラインシステムのクライアントから時限付き在庫の要求を受信する尤度を判定する。オンラインシステムは、判定された尤度を使用してリスティングの価格の変化がどの程度時限付き在庫の需要に影響を与えるかについての情報をマネージャに提供することができる。

Description

（関連出願の相互参照）
本出願は、２０１４年１１月２６日に出願された米国特許仮出願第６２／０８５，０４９号明細書、２０１５年２月５日に出願された第６２／１１２，５６７号明細書、および２０１５年５月２６日に出願された第６２／１６６，４４０号明細書の利益を主張し、それぞれの開示内容は、そのすべてが参照により本明細書に組み込まれる。

本出願は、一般には、機械学習モデルおよびデータ分析を時限付き在庫(time-expiring inventory)の文脈において使用することに関し、詳細には、時限付き在庫に関連する機械学習のサンプルデータに訓練ラベルを割り当てることに関する。

商品またはサービスの典型的な取引において、商品を管理するまたは所有するマネージャ(manager)は、商品の価格を設定し、提案された価格を支払うことに合意する関係者(interested party)を待つ。マネージャは、商品の価格を正しく決定できないことが多いが、市場の不完全な情報および他の経済的要因により、最終的に価格を支払うことに合意する人もいる。しかしながら、時限付き在庫の価格決定は、在庫が期限切れになる前に売れなければ、在庫が無駄になり、マネージャが収入を得られないのでより困難な試みである。従って、時限付き在庫のマネージャは、在庫の価格決定が高すぎて期限切れによって収入を失う危険を冒すか、在庫の価格決定が低すぎて次善であるが良い利用の収入を得るいずれかの影響を受けやすい。さらに、時限付き在庫の理想的または所望の市場清算価格は、在庫の期限日が近づくにつれて変化し得る。この要因の組み合わせにより、時限付き在庫のマネージャが在庫の価格を最適に決定することを困難にする。

オンラインシステムは、マネージャが時限付き在庫のリスティングを作成できるようにし、クライアントがリスト化された時限付き在庫を予約指定する、借りる、または買うことを要求する取引を提出できるようにする。オンラインシステムは、時限付き在庫のリスティングの需要を推定する。オンラインシステムは、時限付き在庫、関連付けられたリスティング、および時限付き在庫の市場を記述する特徴のセットを定義する。これらの記述特徴のセットは、リスティングの特徴ベクトルである。オンラインシステムは、そのリスティングの特徴ベクトルを需要関数に入力することによってリスティングの需要を推定する。

需要関数は、特徴ベクトルの各特徴が特徴モデルと関連付けられる、特徴ベクトルの特徴毎の特徴モデルで構成することができる。需要関数は、特徴モデルを合計して需要推定を生成する一般化加法モデルとなる。オンラインシステムは、訓練データからの各サンプルが、在庫が期限切れになる前にリスティングの時限付き在庫がクライアントからの取引要求を受信したかどうかを記述する２進数ラベルならびにサンプル時間毎に時限付き在庫のリスティングを記述する特徴ベクトルを備える、訓練データを使用して需要関数を訓練することができる。オンラインシステムは、各サンプルが時限付き在庫の期限が切れる前の時間期間中に時限付き在庫のリスティングの特徴と一致する、単一のリスティングの複数のサンプルを収集することができる。

オンラインシステムは次に、需要推定をクライアントから取引要求を受信する尤度に変換する尤度モデルを使用することができる。オンラインシステムは次に、時限付き在庫のマネージャの価格内部情報(price tip)を作成することができる。オンラインシステムは、時限付き在庫の現在の価格よりも大きいまたは小さい試験価格(test price)のセットを生成することによって価格内部情報を算出する。オンラインシステムは次に、各変更された特徴ベクトルが異なる試験価格を有する、時限付き在庫のリスティングの変更された特徴ベクトルを需要関数に入力する。需要関数は、オンラインシステムが尤度モデルを使用して試験尤度(test likelihood)のセットに変換する、試験需要推定のセットを生成する。

オンラインシステムは次に、試験尤度のセットに基づいて価格内部情報を判定することができる。オンラインシステムは、各データポイントが試験尤度と、結果として試験尤度となる対応する試験価格で構成された、データポイントに基づく関数を適合することができる。関数は、価格帯と、取引要求を受信した結果から予測される尤度を表す。オンラインシステムは、価格の積と関数のポイントの要求尤度を最大にする新しい価格を選択することができる。

一実施形態にかかる、予約する時限付き在庫を使用可能にするオンラインシステムを含む計算環境のブロック図である。 一実施形態にかかる、オンラインシステムの論理コンポーネントのブロック図である。 一実施形態にかかる、需要モジュールのコンポーネントおよび動作を示す図である。 一実施形態にかかる、需要モジュールのコンポーネントおよび動作を示す図である。 一実施形態にかかる、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。 一実施形態にかかる、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。 一実施形態にかかる、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。 一実施形態にかかる、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。 一実施形態にかかる、需要モジュールによって使用される訓練データを格納する例示的なストアを示す図である。 一実施形態にかかる、特徴モデルを示す図である。 一実施形態にかかる、例示的な特徴モデルを示す図である。 一実施形態にかかる、例示的な特徴モデルを示す図である。 一実施形態にかかる、需要モジュールによって使用される尤度モデルを示す図である。 一実施形態にかかる、リスティングの価格決定モデルを作成する処理を示す図である。 一実施形態にかかる、リスティングの価格決定モデルを作成する処理を示す図である。 一実施形態にかかる、リスティングの価格決定モデルを作成する処理を示す図である。

本発明のさまざまな実施形態を示す図面は、例示のみを目的とする。本明細書に記載された構造および方法の代替的実施形態を本明細書に記載された発明の原理から逸脱しない限り用いることができる以下の論考を当業者は容易に理解するであろう。

Ｉ．システムの概要
図１は、一実施形態にかかる、時限付き在庫に購入、貸出し、借受け、予約指定などを与えるオンラインシステムを含む計算環境のブロック図である。ネットワーク１０９は、本明細書ではクライアント１０２Ａと呼ばれる、取引の一方の当事者と、本明細書ではマネージャ１０２Ｂと呼ばれる、取引の他方の当事者との間の通信経路を表す。

説明を明確にするため、クライアントは、価値の潜在的な買い手を含み、賃貸人、借受人、予約指定を保持しているクライアント、またはその他の第三者は、いかなる形式であれ、アクセスと引き換えに時限付き在庫に対する考慮を提供する。説明を明確にするため、マネージャは、時限付き在庫の項目の売り手を含み、地主および地主の代わりに資産を管理する不動産所有者、チケット販売員またはレストランもしくはホテルの予約係りなど、予約指定在庫を管理する貸出人、またはその他の第三者は、（いかなる形式であれ）アクセスの提供と引き換えに時限付き在庫に対する考慮を受け取る。取引される時限付き在庫のタイプに応じて、時限付き在庫を売り、借り、予約指定するなどができる。説明を明確にするために、こうした異なるタイプの取引を本明細書では、可能なタイプの取引を丸ごと１つの便利な用語で提供するために「予約(booking)」と呼ぶ。

オンラインシステム１１１は、ネットワーク１０９を介してクライアントとマネージャとに関連付けられた計算装置１０１に結合してクライアントとマネージャがネットワーク１０９上で実質的に対話できるようにする、１または複数の計算装置を含む。一実施形態において、ネットワークは、インターネットである。ネットワークはまた、必ずしもインターネットの一部ではない専用またはプライベート通信リンク（例えば、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、またはローカルエリアネットワーク（ＬＡＮ））も利用することができる。ネットワークは、標準の通信技術および／またはプロトコルを使用する。

計算装置１０１は、オンラインシステム１１３と対話するクライアントおよびマネージャによって使用される。計算装置１０１は、オペレーティングシステム、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｎｄｏｗｓ互換のオペレーティングシステム（ＯＳ）、ＡｐｐｌｅＯＳＸまたはｉＯＳ、Ｌｉｎｕｘディストリビューション、またはＧｏｏｇｌｅのＡｎｄｒｏｉｄＯＳを実行する。ある実施形態において、クライアント装置１０１は、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ、Ａｐｐｌｅ Ｓａｆａｒｉおよび／またはＯｐｅｒａなどのウェブブラウザ１１３を、オンラインシステム１１１と対話するユーザが使いやすい(user-friendly)グラフィカルインタフェースとして使用することができる。他の実施形態において、計算装置１０１は、オンラインシステム１１１にアクセスするための専用ソフトウェアアプリケーションを実行できる。

オンラインシステム１１１は、クライアントとマネージャが時限付き在庫を取引するそれらの計算装置１０１経由で対話する計算プラットフォームを提供する。オンラインシステム１１１は、例えば、レストランでの食事のオンラインシステム（または飛行機または列車の座席オンラインシステム、ホテルのオンラインシステムまたはデイスパのオンラインシステムなど、その他の種類のオンラインシステム）、相乗り（カープール）のオンラインシステム、宿泊施設のオンラインシステムその他をサポートすることができる。

オンラインシステム１１１は、マネージャに時限付き在庫のリスティングを作成する能力を提供する。リスティングは、航空券オンラインシステムによって申し出されるフライト毎の各飛行機の各座席など、時限付き在庫の個々のインスタンスに対して作成することができる。あるいは、リスティングは、特定の在庫を時間に関係なく作成することができ、次にリスティングを、それらの単位時間が既に経過した場合に期限切れになる単位時間に取引することができる。この場合、リスティングは、時限付き在庫のセットに共通し、セットの時限付き在庫の各項目は、取引される時間／日付範囲に限り他とは異なる。例えば、不動産賃貸システムの場合、リスティングを特定のアパートまたはマンション(condominium)用にすることができ、クライアントおよびマネージャは、そのアパートまたはマンションと関連付けられた異なる単位時間（例えば、日付）に取引することができる。

一般的に、必ずしもそうではないが、各リスティングは、関連する現実世界の地理的位置をリスティングと関連付ける。これは、賃貸する不動産の位置または予約指定するレストランの位置および場合により予約指定される固有のテーブルとなり得る。オンラインシステム１１１は、マネージャが、リスティングの実際のおよび予測される需要の情報、ならびにマネージャが特定のリスティングの利用および／または収入を改善する選択をすることができる情報の権限をマネージャに与える内部情報(tip)を与えることを含む、マネージャのリスティングを管理するのに役立つオンラインソフトウェアツールをマネージャにさらに提供する。

オンラインシステムは、リスティングを探索し、可能な取引に関して運営者と通信し、取引が行われることを公式または非公式に要求し（例えば、申し出る）、および実際にリスティングに関する取引を遂行する（例えば、買う、借りる、予約指定する）能力をクライアントに提供する。オンラインシステム１１１は、以下に記載されている付加的なコンポーネントおよびモジュールを備える。

ＩＩ．オンラインシステム
図２は、一実施形態にかかる、オンラインシステム１１１の論理コンポーネントのブロック図である。オンラインシステム１１１は、フロントエンドサーバ２０１、クライアントモジュール２０３、マネージャモジュール２０５、リスティングモジュール２０７、探索モジュール２０９、取引モジュール２１１、需要モジュール２１３、およびデータベース２５０を備える。オンラインシステム１１１はまた、本明細書に記載されていない、異なるおよび他のモジュールも包含できることが当業者にはさらに認識されよう。さらに、ファイアウォール、認証システム、支払い処理システム、ネットワーク管理ツール、負荷分散装置など、従来の要素は、本明細書に記載された発明の内容と直接関係あるものではないので、図示されていない。

オンラインシステム１１１は、単一の計算装置、またはクラウドベースのコンピュータ実装を含む、計算装置のネットワークを使用して実装できる。計算装置は好適には、１または複数の高性能コンピュータプロセッサおよびランダムアクセスメモリを含み、およびＬＩＮＵＸ（登録商標）またはその変型などのオペレーティングシステムを実行するサーバクラスのコンピュータである。本明細書に記載されるように、オンラインシステム１１１の動作は、ハードウェアか、あるいはソリッドステートドライブまたは磁気記憶装置など、一時的でないコンピュータ可読記憶装置にインストールされたコンピュータプログラムのいずれかを介して制御され、本明細書に記載された関数を遂行するプロセッサによって実行される。データベース２５０は、一時的でないコンピュータ可読記憶装置と、データアクセスおよび読み込みに適したデータベース管理システムを使用して実装される。オンラインシステム１１１は、ネットワークインタフェースおよびプロトコル、データエントリの入力装置、表示用の出力装置、印刷、またはデータの他のプレゼンテーションを含む、本明細書に記載された動作に必要な他のハードウェア要素を含む。さらに、ここにリスト化された動作は必然的に、商業的に有益な時間量で遂行するためにコンピュータによって遂行されなければならない頻度およびデータの大規模なセットを通じて遂行され、従ってどの有用な実施形態も人間の心の精神的処理段階によって遂行することができない。

データベース２５０は、クライアントデータストア２５１、マネージャデータストア２５２、リスティングデータストア２５３、クエリデータストア２５４、取引データストア２５５、および訓練データストア２５６を含む。これらのデータストアが汎用データベースのコンポーネントではないこと、およびデータベース２５０がここでは明示的に言及されてない他のデータストアを包含できることが当業者には認識されよう。データベースは、ＭｙＳＱＬ、ＰｏｓｔｇｒｅＳＱＬ、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ、Ｏｒａｃｌｅ、ＳＡＰ、ＩＢＭ ＤＢ２など、任意の適したデータベース管理システムを使用して実装することができる。

フロントエンドサーバ２０１は、クライアントおよびマネージャの計算装置１０１がオンラインシステム１１１と通信するプログラムコードを含み、それを行うための１つの手段である。フロントエンドサーバ２０１は、計算装置１０１にインストールされたウェブブラウザソフトウェアアプリケーションなどのユーザエージェントがコマンドを送信してオンラインシステムからデータを受信することができるように、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）経由でアクセス可能な１または複数のウェブサイトをホストするウェブサーバを含むことができる。フロントエンドサーバ２０１はまた、計算装置１０１がインストールされたソフトウェアアプリケーションがＡＰＩを呼び出してコマンドを送信してオンラインシステムからデータを受信するようにさせるアプリケーションプログラミングインタフェース（ＡＰＩ）も使用可能にする。フロントエンドサーバ２０１はさらに、コマンドおよびデータをオンラインシステム１１１の他のコンポーネントにルートして本明細書に記載された処理を実施して、それにより計算装置１０１に応答するプログラムコードを含む。

ＩＩ．Ａ クライアントおよびマネージャ
クライアントモジュール２０３は、クライアントにそれらとオンラインシステム１１１との対話を管理させ、オンラインシステム１１１の他のコンポーネントによって要求され得るクライアントに関連する情報の処理論理を実行させ、それを行うための１つの手段である、プログラムコードを備える。各クライアントは、オンラインシステム１１１において、固有のクライアントＩＤとクライアントプロファイルを有し、その両方がクライアントストア２５１に格納された個々のクライアントオブジェクトで表される。クライアントプロファイルは、プロファイルピクチャおよび／または他の識別情報(identifying information)、地理的位置、およびクライアントカレンダーを含むことができる、いくつかのクライアントに関連する属性フィールドを含む。クライアントモジュール２０３は、クライアントにそれらのクライアントプロファイルを設定して変更するコードを提供する。オンラインシステム１１１は、各クライアントに複数のマネージャと通信させる。オンラインシステム１１１は、クライアントにマネージャと交信、取引の要求、および取引をさせる。

クライアントの地理的位置は、それらが手動で入力した居住地の自宅住所、近隣、都市、州、または国のいずれかの、（例えば、それらの計算装置１０１によって提供される情報に基づいた）クライアントの現在の位置である。クライアントの位置は、特定のクライアントに関連する時限付き在庫の探索基準をフィルタにかけるまたはデフォルト言語選択を割り当てるために使用され得る。

マネージャモジュール２０５は、マネージャにオンラインシステム１１１との対話およびリスティングを管理させ、オンラインシステム１１１の他のコンポーネントによって要求され得るマネージャに関連する情報の処理論理を実行させるユーザインタフェースを提供し、それを行うための１つの手段である、プログラムコードを備える。各マネージャは、オンラインシステム１１１において、固有のマネージャＩＤとマネージャプロファイルを有し、その両方がマネージャストア２５２に格納された個々のマネージャオブジェクトで表される。マネージャプロファイルは、マネージャによって所有されるまたは管理される１または複数のリスティングと関連付けられ、マネージャによって管理されるリスティングのそれぞれの取引要求およびリスティングカレンダーのセットを含む、いくつかのマネージャ属性を含む。マネージャモジュール２０５は、マネージャにそれらのマネージャプロファイルおよびリスティングを設定して変更するコードを提供する。オンラインシステム１１１は、マネージャとクライアントの両方になる。この場合、ユーザは、クライアントストア２５１とマネージャストア２５２の両方のプロファイルエントリを有し、クライアントオブジェクトとマネージャオブジェクトの両方で表される。オンラインシステム１１１は、マネージャにマネージャと交信、取引の要求の応答、および取引をさせる。

クライアントまたはマネージャのプロファイルの一部として含まれる、または取引を実施するために送信される任意の個人識別情報は、ユーザのプライバシーおよび保護のために暗号化される。例えば、マネージャが宿泊施設(accommodation)へのアクセスを許可してクライアントがそのアクセスの代金を支払う取引が完了すると、取引情報が暗号化されて取引の履歴情報としてデータベース２５０に格納される。

ＩＩ．Ｂ リスティング
リスティングモジュール２０７は、マネージャがクライアントによって予約される時限付き在庫をリスト化し、それを行うための１つの手段である、プログラムコードを備える。リスティングモジュール２０７は、申し出される在庫を記述するマネージャからのリスティング、開始日、終了日、開始時間、および終了時間、価格、地理的位置、在庫を特徴付ける画像および記述、およびその他の関連情報を含むその可用性(availability)の時間フレームを受信するように構成される。例えば、宿泊施設のオンラインシステムの場合、リスティングは、宿泊施設（例えば、家、アパート、部屋、睡眠場所他）のタイプ、そのサイズの表現（例えば、面積(square footage)、または部屋数）、宿泊施設が使用可能な日付、および価格（例えば、一泊、週泊、月泊など）を含む。リスティングモジュール２０７は、ユーザがビデオ、写真、および他の媒体など、在庫についての付加的な情報を含むことを可能にさせる。

各リスティングは、オンラインシステムにおいて、マネージャによって提供される時のリスティングの情報と固有のリスティングＩＤを含み、その両方がリスティングストア２５３に格納される、リスティングオブジェクトで表される。各リスティングオブジェクトはまた、リスティングを提供するマネージャのマネージャオブジェクトと関連付けられる。

具体的なリスティングの地理的位置に関して、リスティングと関連付けられた位置は、申し出されたリスティングの完全な住所、近隣、都市、および／または国を特定する。リスティングモジュール２０７はまた、外部で使用可能な地理的地図情報を使用してあるタイプの位置情報（例えば、郵送先住所）を別のタイプの位置情報（例えば、国、州、都市、および近隣）に変換する能力もある。

具体的なリスティングの価格に関して、価格は、在庫の取引を完了するためにクライアントが支払う必要がある金額である。価格は、１日当たり、１週間当たり、１月当たり、および／または１シーズン当たりの金額として指定されるか、またはマネージャによって他の時間間隔にしてもよい。さらに、価格は、宿泊施設の在庫、クリーニング料金、ペット料金、および税金など、付加的な使用料を含むことができる。

各リスティングオブジェクトは、関連付けられたリスティングカレンダーを有する。リスティングカレンダーは、マネージャによって指定されるまたは（例えば、カレンダーのインポート処理を介して）自動的に判定される時に、（それぞれが時限付き在庫の独立した項目と考えられる）時間期間の時間間隔毎のリスティングの可用性を格納する。つまり、マネージャは、リスティングのリスティングカレンダーにアクセスして、リスティングがクライアントによる取引に使用可能である時間間隔、マネージャによって利用不可として遮断された時間間隔、およびクライアントによってすでに取引された時間間隔を手動で示す。さらに、リスティングカレンダーは、クライアントによって予約された、遮断された、または使用可能な過去の時間間隔を特定することによってリスティングの可用性に関する履歴情報の格納を継続する。さらに、リスティングカレンダーは、カレンダールール、例えば、在庫に許容される宿泊の最小日数および最大日数を含むことができる。各リスティングカレンダーからの情報は、リスティングテーブル２５３に格納される。

ＩＩ．Ｃ 探索、要求および取引
探索モジュール２０９は、クライアントから入力探索クエリを受信して入力クエリにマッチする時限付き在庫および／またはリスティングのセットを返すように構成され、この関数を遂行するための１つの手段であるプログラムコードを備える。探索クエリは、オンラインシステム１１１によってクエリストア２５４に格納されるクエリオブジェクトとして保存される。クエリは、探索位置、所望の開始時間／日付、所望の期間、所望のリスティングタイプ、および所望の価格帯を包含することができ、さらにリスティングの他の所望の属性を含むことができる。潜在的なクライアントは、探索モジュール２０９から結果を受信するために上記のクエリのすべてのパラメータを提供しなくてもよい。探索モジュール２０９は、提出されたクエリのパラメータを満たす提出されたクエリに応答して時限付き在庫および／またはリスティングのセットを提供する。オンラインシステム１１１はまた、クライアントが探索クエリを提出せずにリスティングをブラウズできるようにし、この場合、記録される一覧データは、クライアントが、提出された探索クエリ以上に詳細にならない特定のリスティングを一覧したことのみを示す。可能な取引をより入念に見直した時限付き在庫／リスティングを選択する入力を提供すると、探索モジュール２０９は、クライアントが一覧した在庫／リスティングを示す選択／一覧データを記録する。この情報もまたクエリデータストア２５４に格納される。

取引モジュール２１１は、クライアントが時限付き在庫を取引する取引契約要求（公式な要求とも呼ばれる）を提出できるように構成され、この関数を遂行するための１つの手段であるプログラムコードを備える。動作において、取引モジュール２１１は、特定のマネージャによって申し出されたリスティングの特定の日付範囲など、時限付き在庫の項目を取引する取引要求をクライアントから受信する。取引要求は、クライアントによって送信される標準化された要求書式(request form)にすることができ、マネージャによる要求への応答によって受信した要求書式を受け入れるまたは拒否するいずれかに変更され、マネージャとクライアント間の合意条件に達するようにできる。受信した要求の変更は、例えば、日付、価格、または時間／日付範囲を変化させる（従って、効果的に、時限付き在庫が取引される）ことを含むことができる。標準化された形式は、クライアントが開始時間／日付、期間（または終了時間）、またはそれ以上やりとりをせずに拘束力を持つ受諾に含めなければならないその他の詳細を記録することを必要とする。

取引モジュール２１１は、クライアントから記入書を受信して、予約パラメータを含む完了した要求書式をリスティングと関連付けられたマネージャに提示する。マネージャは、要求を受け入れ、要求を拒否し、またはパラメータのうちの１または複数を変更することが提案された選択肢を提供することができる。マネージャが要求を受け入れると（またはクライアントが提案された選択肢を受け入れると）、取引モジュール２１１は、要求が受け入れられたことを示すために要求および時限付き在庫と関連付けられた受け入れ状況を更新する。クライアントカレンダーとリスティングカレンダーもまた、時限付き在庫が特定の時間間隔で取引されたことを反映するために更新される。本明細書に具体的に記載されてない他のモジュールは次に、クライアントに支払いを完了させて、マネージャに支払いを受け取らせる。

トランザクションストア２５４は、クライアントによって行われた要求を格納し、この関数を遂行するための１つの手段である。各要求は、要求オブジェクトで表される。要求は、タイムスタンプ、要求された開始時間、および要求された期間または予約指定終了時間を含むことができる。マネージャによる予約の受け入れが、マネージャが時限付き在庫を指定された時間にクライアントに提供するという契約上拘束力を持つクライアントとの合意であるため、マネージャがそのような合意を承認する必要があるすべての情報は、要求に含まれる。要求に応答するマネージャは、受諾または拒否を示す値とタイムスタンプで構成される。

取引モジュール２１１はまた、取引する非公式な要求を交換する能力をマネージャとクライアントに提供することもできる。非公式な要求は、クライアントまたはマネージャが受け入れても十分な拘束力を持たず、内容(content)に関して、単なるやりとりおよび在庫の可用性に関する一般的な問い合わせから、オンラインシステム１１１が公式な取引要求に記載しているどのような固有の要件からもわずかに及ばない要求までさまざまな場合がある。取引モジュール２１１はまた、非公式と公式の両方の要求が時限付き在庫の需要についての有益な情報を提供するので、非公式な要求をクエリストア２５４に格納する。

需要モジュール２１３を真下の図３に関連して説明する。

ＩＩＩ．需要予測
ＩＩＩ．Ａ概要
図３Ａは、一実施形態にかかる、需要モジュールのコンポーネントおよび動作を示すフロー図である。オンラインシステム１１１の時限付き在庫の需要を予測するために、需要モジュール２１３は、複数の特徴モデル３０５、需要関数３００、尤度モデル３１０、および価格決定モデル３２０を含むモデルと関数のシーケンスを使用する。

需要モジュール２１３は、訓練ストア２５６から読み込まれる訓練データのセットを使用して特徴モデル３０５を訓練する。特徴モデル３０５は、リスティングストア２２３のリスティングと関連付けられた時限付き在庫の需要推定を判定する需要関数３００の一部として使用される。需要推定は実際には、無単位の数値になり得るが、尤度モデル３１０は、所与の時限付き在庫が、期限切れになる前に取引要求を受信する尤度を判定する需要推定を使用することができる。価格決定モデル３２０は、モデル３１０によって生成された尤度を利用して、時限付き在庫が多数の異なる試験価格で取引要求を受信する尤度を予測し、従って価格（または特徴モデル３０５からのその他の特徴）の変化により、期限が切れる前に時限付き在庫が取引要求を受信する尤度がどのように変わることが期待されるかに関する情報を与えることができる。

需要モジュール２１３は、リスティングがリスティングストア２２３のいくつかの特徴で表される、関連付けられたリスティングからの個々の時限付き在庫に関するデータで動作する。需要を予測するために、需要モジュール２１３は、そのような在庫の多くを集約して分析し、需要分析の集約レベルは、実装によって異なる。例えば、需要予測は、オンラインシステム１１１のすべてのリスティングにわたるすべてのデータが分析されるように、システムワイドにすることができる。あるいは、より小さくグループ化されたデータを別個に分析することができる。例えば、オンラインの宿泊施設システムは、シカゴの大都市圏のすべての予約指定リスティング、ケンタッキー州のすべての予約指定リスティング、または国立公園に近接するある範囲内のすべてのリスティングの期待される需要を別個に分析することができる。これらの局所的な需要の推定は次に、そのような固有の地域の需要を予測するために使用される。

特徴を論じる場合、ｍは、リスティングを記述する特徴の数を表し、個々の特徴は、ｆ₁，ｆ₂，ｆ₃，…ｆ_mと表され、リスティングの特徴のすべてのセットは、特徴ベクトルｆで表される。所与のリスティングの任意の所与の特徴の値は、整数、浮動小数点数、または２進値などの数値にすることができ、または分類別にすることができる。共通の特徴は、リスティングの価格と、在庫が期限切れになるまでの残り時間を含む。さまざまな関数およびモデルの需要モジュール２１３を訓練するために使用され、さらに時限付き在庫についての有益な情報を取得するために使用されるサンプル訓練データの個々のインスタンスの構造についてのより多くの情報は、以下の節ＩＩＩ．Ｃを参照されたい。

価格特徴は、リスティングがマネージャによって申し出される価格である。例えば、オンラインの宿泊施設システムの場合、価格特徴の値は、特定の日に宿泊施設を予約するクライアント用にリスト化された価格となり得る。リスティングのマネージャは、リスティングの期限時間の前に価格を変化させることができ、従ってリスティングは、それが期限切れになる前に複数の価格を有することになる。

期限切れまでの時間特徴は、時限付き在庫の期限切れの前の、時間間隔または時間期間の数として定義される。実装に応じて、これは、日数、時間数、分数などになり得る。オンラインの宿泊施設システムの例を再度使用すると、個々の時限付き在庫の「期限切れ」は、リスティングが予約されようとする日となる。例えば、１２月２０日に宿泊施設を予約指定するリスティングは、１２月２０日に期限切れになり、従って、期限切れまでの時間特徴の値は、現在の日付から１２月２０日までの日数となる。この場合、オンラインの宿泊施設システムの予約が典型的には、日ベースで行われるため、使用される時間間隔は１日である。しかしながら、オンラインのレストラン予約システムの場合、レストランの予約がより高い頻度でより狭い時間窓において発生するため、時間間隔を１時間にすることが好ましいであろう。

オンラインシステム１１１の時限付き在庫のリスティングは、価格および期限切れまでの時間特徴に加え、任意の数の特徴を有することができる。これらの付加的な特徴は、オンラインシステム１１１の実装に依存し、時限付き在庫またはリスティングを記述する。例えば、オンラインの宿泊施設システムにおいて、リスティングは、リスト化された宿泊施設の平均的クライアントの格付け、リスト化された宿泊施設の地理的位置、リスト化された宿泊施設のベッド数、リスト化された宿泊施設が無線ルータを有するかどうか、またはリスト化された宿泊施設のその他の関連属性を表す特徴を有する場合もある。さらに、特徴は、リスティング自体の品質、例えば、リスティングが受信した一覧の数、リスティングの宿泊施設の記述の長さ、予約の要求が受け入れられる前に、リスティングがリスティングのマネージャによって見直されるかどうか、またはオンラインリスティングのその他の品質を含むことができる。

特徴はまた、リスティングに関連するが、個々のリスティングには直接関連してない特徴を含むこともできる。これらの特徴は、例えば、在庫の所与の項目に関連するリスティングの市場の状況についての情報を提供するが、その間その在庫はアクティブであった（即ち、まだ期限切れではなかったまたは期限切れになる時間に近かった）。そのような特徴の例は、その在庫と同じ市場の他の在庫のオンラインシステム１１１のクライアントによって遂行される探索数である。例えば、オンラインの宿泊施設システムの場合、特徴は、サンフランシスコのノイバレー近隣においてその近隣に位置する在庫の項目と関連する宿泊日の探索数にすることができる。別の可能な特徴は、注目すべき出来事（例えば、スーパーボウル）が在庫の時間および地理的位置に十分近接して発生するかどうかを示す２進特徴になり得る。

さらに、特徴は、複数の他の特徴間の対話または他の特徴の導関数を記述することができる。例えば、予約された時間とリスト化された時間との間のリスティングの平均価格を算出することができる。あるいは、特徴は、２つの他の特徴の値間の相関値を含む場合もある。

需要関数３００は、需要推定を作り出すための任意の関数またはリスティングの特徴値を使用する統計モデルにすることができる。一実装において、需要関数は、特徴の特徴モデルを組み合わせてその特徴の需要推定に対する寄与を判定することによって作成される一般化加法モデルである。一般化加法モデルを使用する需要関数３００は、Ｄ（ｆ）＝ｗ₁（ｆ₁）＋ｗ₂（ｆ₂）＋…＋ｗ_m（ｆ_m）の式から成る。ここにＤ（ｆ）は、需要関数３００であり、また出力需要推定でもあり、ｗ₁，ｗ₂，…ｗ_mは、各特徴値ｆ₁，ｆ₂，…，ｆ_mのそれぞれのＤ（ｆ）に対する寄与を判定する特徴モデル３０５のそれぞれの重み関数である。一般化加法モデルの適合は、確率的勾配降下法、ｋｄ木、ベイズまたはバックフィッティングアルゴリズムを含むいくつかのフィッティングアルゴリズムを使用して完了することができる。これらのアルゴリズムは、特徴モデル３０５と時限付き在庫の前の訓練データのラベルとの間の部分残差のいくつかの損失関数を削減するために、特徴モデル３０５を反復的に適合するために使用される。

特徴モデル３０５は、期限切れの前に取引要求を受信する時限付き在庫の尤度で特徴の効果を示す重みを特徴値に関連させる任意のノンパラメトリック統計モデルにすることができ、そのモデルは、需要推定Ｄ（ｆ）に関連する。各特徴の特性に応じて、その特徴の可能な値に関する訓練データに基づいて、異なる統計モデルを各特徴に適合することができる。例えば、Ｂ−スプライン、３次スプライン、線形フィット、二変量平面フィット、区分定数関数などをすべて使用できる。特徴自体を定義するために、教師ありと教師なしの両方の機械学習技術を使用して、一般化加法モデルを訓練する前に最初に特徴を判定することができる。教師あり学習技術の場合、訓練は、一般化加法モデルを訓練するために代わりに使用されるような、訓練データのラベル以外の他のいくつかの信号に基づくことができる。

肯定ラベルは、期限切れの前にクライアントから取引要求が受信される時限付き在庫（ここでは訓練時限付き在庫と呼ばれる）の前に割り当てられ、否定ラベルは、取引要求を受信せずに期限切れになる訓練時限付き在庫に割り当てられる。さらに、訓練データ構造と特徴モデル３０５の訓練の考察はそれぞれ、節ＩＩＩ．Ｃと節ＩＩＩ．Ｄにおいて提供され、図４Ｂ−図７Ｂを参照する。

需要推定Ｄ（ｆ）に戻ると、需要推定は、訓練データを使用した検証でなければ作動できない無単位の測定である。例えば、特定の特徴ベクトルｆ_AのＤ（ｆ_A）の値は、０．７３５となる。この情報単独では、需要関数３００のどの値が、クライアントから時限付き在庫の取引要求をそれが期限切れになる前に受信する尤度と一致するかを判定しなければ役立たない。尤度モデル３１０は、特徴ベクトルｆを有するリスティングを所与として、需要推定Ｄ（ｆ）を、取引要求を受信する尤度Ｐ（Ｄ（ｆ））にマッピングすることによってこの問題を解く統計モデルである。尤度モデル３１０は、需要Ｄ（ｆ）を推定するために使用される各特徴ベクトルｆの同じ肯定および否定訓練ラベルを使用することによって訓練される。尤度モデル３１０のさらなる考察は、図８を参照する節ＩＩＩ．Ｅで説明される。

価格決定モデル３２０は、リスティングの現在の価格に近いさまざまな試験価格（またはその他の任意に選ばれる要求価格）のリスティングの取引要求を受信する尤度をモデル化する。需要モジュール２１３は、リスティングの現在の価格で取引要求を受信する尤度を表す開始データポイント周辺の試験データを生成する価格決定モデル３２０を生成する反復処理を使用する。この処理は、以下の節ＩＩＩ．Ｂで概要が説明され、図９を参照する節ＩＩＩ．Ｆでさらに説明される。

ＩＩＩ．Ｂ 例示的な処理フロー
図３Ａはまた、図面のモデル、関数、およびデータストアのそれぞれの間の矢印に従って時限付き在庫の需要関数３００と尤度モデル３１０を訓練するための処理フローも示す。需要モジュール２１３は、訓練ストア２５６からの訓練データを使用して特徴モデル３０５の訓練３３０を行う。需要モジュール２１３は次に、訓練データの各サンプルの特徴ベクトル毎の需要関数３００を評価して、各サンプルの特徴ベクトル毎のラベルに基づいて尤度モデル３１０の訓練３４０を行う。

図３Ｂは、需要モジュール２１３が需要関数３００と尤度モデル３１０を訓練した後にリスティングを価格決定する処理を示す。オンラインシステム１１１から目的のリスティングの需要を予測する命令を受信すると、需要モジュール２１３は、目的のリスティングに対応する特徴ベクトルｆ_sをリスティングテーブル２２３から読み込み３５０を行い、それを入力として需要関数３００に使用する。需要モジュール２１３は次に、結果として生じた需要推定Ｄ（ｆ_s）を期限切れの前に取引要求を受信する尤度に変換するための尤度モデル３１０に送信３６０を行う。需要モジュール２１３は次に、結果として生じた尤度Ｐ（Ｄ（ｆ_s））を、リスティングの価格決定の変化がリスティングの需要をどのように変えるかをモデル化することに使用される価格決定モデル３２０に転送する３７０ことができる。

価格決定モデル３２０を生成するために、需要モジュール２１３は次に、特徴ベクトルｆ_sの価格特徴の値を肯定方向と否定方向の両方で作成する試験価格の価格間隔で価格特徴をインクリメントすることによって変更３８０を行い、それによりそれぞれの試験価格に等しい価格特徴の値を包含する、変更された特徴ベクトルｆ_s ⁽¹⁾とｆ_s ^(-1)を作成する。変更された特徴ベクトルにおいて、価格以外の他のすべての特徴の値は変更されないままである。新しい特徴ベクトルのそれぞれの取引要求を受信する尤度Ｐ（Ｄ（ｆ_s ⁽¹⁾））とＰ（Ｄ（ｆ_s ^(-1)））は次に、需要関数３００と尤度モデル３１０によって算出され、リスティングの元の尤度Ｐ（Ｄ（ｆ_s））を用いてグループ化される。需要モジュール２１３は次に、特徴ベクトルｆ_s ⁽²⁾とｆ_s ^(-2)の付加的な試験価格を作成するために価格間隔で価格特徴のインクリメントを継続し、十分なデータポイントが作成されるまで処理が反復される。

価格決定ポイントの閾値数に達すると、需要モジュール２１３は、試験価格と取引要求を受信する対応する尤度とを処理してマネージャまたは情報の要求者の目標を達成する価格を特定する。一実施形態において、これは、入力価格を取り入れて出力尤度を生成する、単調に減少する尤度関数で試験価格と尤度を適合させることによって実現される。適合関数を使用して、リスティングに価格を付けるおよび／または予約するある尤度を獲得するやり方の新しい内部情報を特定することができる。

より一般的には、需要に基づいて尤度推定を生成する需要モジュール２１３の能力は、時限付き在庫の価格を選択する時にマネージャが考慮することができる情報を、時限付き在庫のマネージャに提供する。

ＩＩＩ．Ｃ 訓練データラベル
図４Ａ−図４Ｄは、一実施形態にかかる、需要モジュールによって使用される訓練データのラベル付け論理を示す図である。図４Ａにおいて、１日の時間間隔を有するリスティングカレンダーが示されている。これは、リスティングが日ベースで（クライアントは、隣接する複数日でリスティングの予約を要求する場合もあるが）クライアントによって予約が申し出されることのみを意味する。図４Ａは、取引ストア２５５から読み込まれて訓練データとして使用するために別個にストア２５６に転送される、予約履歴データから訓練データがサンプリングされる方法を示す。図４Ａに示したタイムラインは、単一のリスティングから取られたデータを表す。リスティングは、１０月２４日の期限時間（または期限日）４００、１０月２日の開始リスティング時間（開始リスティング日）４１０、および１０月１５日の要求が受信されて受け入れられる時間（または日）を有する。

リスティングの期限時間４００は、時限付き在庫がオンラインシステム１１１によってもはや使用できないまたはクライアントに提示されない時間である。オンライン予約指定システムにおいて、期限時間４００は典型的には、予約指定が始まる時間である。

開始リスティング時間４１０は、リスティングが最初にクライアントに使用可能になる時間および／またはリスティングがマネージャによってオンラインシステム１１１に提供された最初の日である。

要求が受信されて受け入れられた時間４２０は、クライアントからの取引要求が共にマネージャによって受信されて（公式に）受け入れられた時間であり、一般的に双方の当事者が契約上拘束力を持つ取引を行う。

図４Ａの例において、訓練データの別個のサンプルは、開始リスティング日４１０と要求が受信されて受け入れられた日４２０との間の日ごとに訓練ストア２５６に記録４３０される。各サンプルは、リスティングが記録された日のリスティングの特徴ベクトルｆで構成される。サンプルのラベルは、リスティングの最終結果が分かるまで適用されない。図４Ａの例において、１０月２日から１０月１５日までのそれぞれのサンプルは、リスティングの最終結果が、要求が受信されて受け入れられた日４２０の要求である、要求およびその後の受諾であった理由で受け入れられる要求に対応する肯定ラベルが与えられる。

いくつかの実施形態において、リスティングがすでに受け入れられてもはやオンラインシステム１１１でクライアントに提示されていないので、４２０と期限日４００との間の日のどのサンプルも収集されない。これは、例えば、時限付き在庫が固有であれば発生する。時限付き在庫が固有でない（例えば、複数のほぼ同一のフライトの座席）場合、システムはリスティングを持続させ、従って時限付き在庫を使い果たすまたは期限切れになるまでの時間中、より多くのデータが収集される。いくつかの実施形態において、システムは、同じ価格を共有し、各固有でないリスティングをいくつかの同一の特徴を有する固有のリスティングとして扱う複数のリスティングを定義する。リスティングのグループのメンバの予約は、グループのリスティングのうちの１つに適用されて、残りのリスティングは、持続が許可される。

リスティングが使用可能である間に時間間隔毎の訓練データのサンプルを記録することにより、可用性の全期間にわたって集約される受け入れられる取引要求毎に１つのみのデータポイントを収集することに比べると、分析のために需要モジュール２１３に使用可能なデータポイントの数が大幅に増加する。

図４Ｂは、予約履歴データからの訓練データのラベル付けサンプルの第２の例示的な結果を示す。図４Ｂに示した例では、期限日４００と開始リスティング日は、図４Ａと同じものである。しかしながら、図４Ｂにおいて、リスティングが開始リスティング日４１０から期限日４００まで使用可能であったにもかかわらず、リスティングのどの取引要求も受信されなかった。その結果、リスティングが使用可能であった日に取得されたすべてのサンプル４４０は、時限付き在庫が期限切れになる前にリスティングの取引要求が受信されなかったことを示す否定ラベルでラベル付けされる。

取引要求を受信したリスティングと、さらに取引要求を受信してないリスティングの両方の訓練データのサンプルの取得およびそれらの異なるラベル付けにより、取引要求を受信したリスティングのみを考慮するモデルに比べると、需要モジュール２１３に使用可能なデータ量がさらに増加する。

図４Ｃは、予約履歴データからの訓練データのサンプルの取得およびラベル付けのより複雑な第３の例示的な結果を示す。図４Ｃにおいて、期限日４００と開始リスティング日４１０は、前の２つの例と同じものである。しかしながら、図４Ｃにおいて、リスティングのマネージャは、１０月１５日の取引要求を受信するがその後、要求の拒否４５０を行う。これは、さらに取引要求を受信するためにリスティングを使用可能なままにする。取引要求はこれ以上、要求拒否日４５０と期限切れ日との間に受信されない。

この状況において、肯定ラベルは、マネージャが受け入れていれば、要求が結果として上手く取引できたはずなので、リスティングの取引要求が受信されてその後拒否４５０された日より前の日のサンプルに適用４３０される。リスティングがこれ以上、要求拒否日４５０の後に取引要求を受信しなかった理由で、第１の要求の後の日のサンプルが否定ラベルでラベル付け４４０され、その時間期間中に受信される取引要求の欠如が、それより早い時間に受信された取引要求と無関係であるので、従ってその時間期間中のリスティングの特徴が取引要求を引き付けるのに十分な需要を生成することができなかった。いくつかの実施形態において、要求拒否日４５０は、拒否された取引要求が受信された日にすることができる。他の実施形態において、要求拒否日４５０は、取引要求が拒否された日である。あるいは第１の要求が拒否４５０された後に第２の取引要求が受信されると（図示せず）、残りのサンプルは代わりに、肯定ラベルでラベル付けされる。

図４Ｄは、予約履歴データからの訓練データのサンプルの取得およびラベル付けの第４の例示的な結果を示す。図４Ｄにおいて、期限日４００と開始リスティング日４１０は再度、前の例と同じものである。図４Ａに見られるように、取引要求は、１０月１５日に受信されて受け入れられた４２０が、図４Ｄにおいて、リスティングを要求したクライアントが取引要求を取り消すことによって、リスティングをオンラインシステム１１１の他のクライアントに再度アクセス可能にする。取り消された後、リスティングはこれ以上、取引要求を受信しない。図４Ｃの同様の状況において、開始リスティング日４１０から取引要求の受諾日４２０までの日数のサンプルは、肯定ラベルでラベル付け４３０され、リスティングが取り消し日４６０にクライアントに使用可能になった後、訓練データは、否定ラベルでラベル付け４４０される。この場合、取り消し日４６０と取引要求の受諾日４２０との間の日には、リスティングがその時間中、クライアントに使用可能でないため、どのサンプルも作成されない。再度（図示せず）、取り消し日４６０の後にリスティングが取引要求を受信したのであれば、取り消し日の後のサンプルは代わりに、肯定ラベルを受信する。

上記のように、個々の訓練データのサンプルは、時間期間４３０と４４０によって示された各日に取得されるが、サンプル４７０Ａ−４７０Ｄは、具体的には以下の図５を参照する以下の考察において使用するためにラベル付けされる。

図５は、一実施形態にかかる、需要モジュール２１３によって使用される訓練データを格納するための例示的な表を示す。図５は、訓練データの表５００と５１０のサンプルが格納された２つの例示的な表を示す。表５００は、特徴ベクトルに含むことができるさまざまな特徴を示す一般的な例である一方、表５１０は、宿泊施設システムに使用することができる単一のリスティングからの固有のサンプルの例である。

表５００において、各行は、特定の日に記録された予約履歴データからの訓練データの単一のサンプルを表す。各行は、特徴ベクトル（ｆ₁からｆ_mまで）の各特徴の特徴値と、訓練サンプルが（図４Ａ−図４Ｄを参照して説明されたように）記録されたリスティングの最終結果に対応する訓練ラベルを包含する。この実施形態において、訓練ラベル１を使用してリスティングの取引要求が受信されたことを表し、訓練ラベル−１を使用して、時限付き在庫が期限切れになる前にどの取引要求も受信されなかった状況を表す。

表５００の列は、いくつかの例示的な特徴タイプを示す：特徴１と特徴２は、量的であり、特徴３は、分類別であり、特徴ｍは、２進数である。表５００は、特徴ｍに対応するｍ＋１列（その一部は、例示目的のため削除される）と、特徴ベクトル毎の訓練ラベルを包含する。表５００は、訓練データサンプルの総数Ｎに対応するＮ行を包含する。

表５１０は、図４Ｄに示した例示的なリスティングのタイムラインからのデータサンプルの選択を示す。サンプルは、開始リスティング日４１０から要求受諾日まで、また取り消し日４６０から期限日４００までの各日に記録されるであろうが、説明を容易にする目的で４７０Ａ−４７０Ｄのみのサンプルが表に示されている。

表５１０において、列は、価格、期限切れまでの日数、リスト化された宿泊施設の都市、およびリスト化された宿泊施設が無線ルータ（ＷｉＦｉ）を含むかどうかを含むオンラインの宿泊施設システムの例示的な特徴でラベル付けされる。サンプル４７０Ａ−４７０Ｄがすべて同じリスティングからのサンプルであり、都市特徴とＷｉＦｉ特徴は、すべてのサンプルにわたって同じままである一方、期限切れ特徴と価格特徴は、サンプリング期間にわたって変化する。

サンプル４７０Ａは、取引要求が受信されて受け入れられた４２０前に記録されたので、訓練ラベル１が適用される。サンプル４７０Ａは、期限日４００の２０日前の１０月４日に記録されたので、期限切れまでの日数特徴は、値２０を有する。この例において、１０月４日のリスティングの価格が＄１２０であったので、価格特徴は、値１２０を有する。サンプル４７０Ｂにおいて、マネージャは、価格を＄１００に減じて、サンプル４７０Ａが記録されて以来１週間が経過した。従って、期限切れまでの日数特徴と価格特徴の値は、リスティングの特徴の変化を反映するために変化した。価格＄１００は、サンプル４７０Ｂとサンプル４７０Ｃとの間の日において一定のままである。サンプル４７０Ｃは、要求が受信された価格が＄１００であったことを示す、要求が受信されて受け入れられた日４２０に記録された。この価格が、サンプル４７０Ａの元の価格＄１２０とは異なることに留意されたい。

この価格（および潜在的には他の特徴）の差は、価格を下げることが、クライアントがリスティングの取引要求を提出するように誘導する原因因子であったかどうか分からないので、因果関係の問題を持ち込む。例えば、取引要求が価格＄１２０で受信されなかったが、後で価格が＄８０に下がった時に受信されていれば、価格が＄１２０であった日の訓練データサンプルの訓練ラベル１は、価格が期限切れになるまで＄１２０のままであったならば、取引要求の受信が生じなかったかもしれない特徴値（例えば、価格＄１２０）の肯定結果を示す。

需要モジュール２１３は、これらのタイプの因果関係を実施形態に応じて異なって対処することができる。いくつかの実施形態において、サンプルが取引要求の受信日４２０に記録されたサンプルとは（サンプル間の異なる特徴の数、最大差閾値、または別の測定基準に基づいて）本質的に異なる場合、サンプルは、捨てられる。別の実施形態において、サンプルは、要求が受信された日に記録されたサンプルとどれくらい異なるかに基づいてより少ない重み（例えば、ラベル０．５が与えられることもある）が与えられる。さらなる別の実施形態において、「要求までの日」または「クライアント要求が受信された価格」特徴などの付加的な特徴は、サンプルの寄与の差を需要関数３００に反映する特徴ベクトルに付加され得る。一部の例では、異なる特徴を有するこれらのサンプルは、データのラベル付け処理を簡素化する目的またはサンプルが需要予測モデルの最小効果があると考えられるため全重みが与えられる。別の実施形態において、開始リスティング日４１０と要求が受信された日４２０との間の価格の平均、中央値、または他の測定の分布は、別個の特徴である。

ＩＩＩ．Ｄ 特徴モデル
図６は、一実施形態にかかる、特徴モデルｗ（ｆ）を示す。図６は、特徴値１を需要関数３００の重みに関連付ける特徴モデル３０５を示す。統計モデル６００は、需要モデル３００の出力Ｄ（ｆ）と個々のサンプルの対応する特徴値ｆとの間の部分残差である、訓練データポイント６１０の適合である。訓練処理の各反復により残差が変化して、統計モデル６００がデータに適合される。確率的勾配降下法およびバックフィッティングアルゴリズムなどのアルゴリズムは、需要モデル３００のすべての特徴の統計モデル６００間の部分残差を最小にすることを求める。訓練データセットを反復処理した後、統計モデル６００は、所与の特徴値毎に重みを出力する特徴モデル３０５に収束する。Ｂ−スプライン、３次スプライン、任意のタイプの回帰、（分類および２進データの）ディラックのデルタ関数、またはこれらの方法の任意の組み合わせを含む、データに適合する多くの統計方法を使用することができる。オンラインシステム１１１の管理者は、データの最適表現のために特徴モデル３０５を構成することができる。適合した後、特徴モデル３０５は、特徴値の最大範囲の−１と１との間の荷重値を有する。いくつかの実施形態において、特徴値を０と１との間の範囲に制限するように標準化される。特徴が分類別または２進であれば、統計モデル６００は単純に、特徴分類から荷重値へのマッピングであるか、または重みの判定に使用するために設計されたスケールに分類データを変換することに基づく。

図７Ａ−図７Ｂは、一実施形態にかかる、例示的な特徴モデル３０５を示す。図７Ａは、価格特徴の特徴モデル３０５が訓練データの典型的なセットを用いてどのようになるかを例示的に示す。この場合、統計モデル７００は、価格データに適合するスプラインの典型である。統計モデルに基づいて、価格は、非常に安いリスティングの需要に否定的影響を与え（恐らくクライアントが詐欺に遭うことを懸念するため）、安いが手頃な価格レベルでは、価格は、リスティングの需要に肯定的影響を与える。価格が上がるにつれ、需要の影響は、その価格レベルのクライアントがより融通性のある消費性向を有し、価格特徴が需要にあまり否定的影響を与えないあるポイントまでますます否定的になる。

図７Ｂは、訓練データの典型的なセットを有する「期限切れになる前の日数」特徴の典型的な特徴モデル３０５を示す。この例に使用される統計モデル７１０は、リスティングがその期限日の前にポストされるのが早ければ早いほど、そのリスティングの需要が高くなりやすいことを示す。これらの例示的な特徴モデル３０５のいずれも典型的な結果とは異なり、本明細書ではオンラインシステム１１１の文脈において特徴モデル３０５の機能性を説明する例としてのみ使用される。

ＩＩＩ．Ｅ 尤度モデル
図８は、一実施形態にかかる、需要モジュール２１３によって使用される尤度モデル３１０を示す。需要モジュール２１３が特徴モデル３０５を訓練した後直ちに、需要モジュール２１３は、訓練データのいくつかのサンプルの特徴ベクトルｆのセットを使用して、需要関数３００を使用してサンプル毎に推定された需要Ｄ（ｆ）を出力する。尤度モデル３１０を訓練するために、需要モジュール２１３は、推定された需要Ｄ（ｆ）のラベル付けされた値に尤度関数８００を適合する。尤度関数８００は、特徴ベクトルｆが需要Ｄ（ｆ）に与えられた肯定ラベルを有する尤度を判定し、そうでなければ、尤度を、時限付き在庫の期限切れの前に取引要求を受信した所与のサンプルとして定める二進分類の問題を解く関数である。図８において、否定ラベルは、白丸８１０で表される一方、肯定ラベルは、黒丸８２０で表される。尤度関数８００は、サンプルの推定された需要に基づいて黒い点に尤度を近似する。

いくつかの実施形態において、プラットスケーリング（Platt scaling）アルゴリズムを尤度関数８００として使用する。需要関数に適用されるプラットスケーリングアルゴリズムは、式：
Ｐ（Ｄ（ｆ））＝（１＋ｅｘｐ（αＤ（ｆ）＋β））^-1
となる。ここにαとβは、学習定数である。ヒンジ損失関数などの損失関数または別の同様の技術を使用して、最大尤度法を使用するプラットスケーリングアルゴリズムを訓練し、この２進分類の問題を最適に解けるようにする。

需要モジュール２１３が尤度関数８００を訓練した後直ちに、尤度モジュール３１０は、推定需要Ｄ（ｆ）を入力として受信し、期限切れの前に時限付き在庫が取引要求を受信する尤度Ｐ（Ｄ（ｆ））を出力することができる。

ＩＩＩ．Ｆ 価格決定モデル
図９Ａ−図９Ｃは、一実施形態にかかる、リスティングの価格決定モデル３２０を作成する処理を示す。需要モデル３００（特徴モデル３０５を含む）と尤度モデル３１０（尤度関数８００を含む）との両方が訓練データのサンプルを使用して訓練された後、需要モジュール２１３は、任意の特徴ベクトルｆを、取引要求を受信する尤度Ｐ（Ｄ（ｆ））に変換する能力を有する。

上記で導入されたように、試験価格の範囲内で取引要求を受信する尤度を提供するために、需要モジュール２１３は、試験価格のセット（リスティングの現在の価格を含む）に等しい価格特徴の値と変化しないままの残りの特徴の値とを用いて変更される特徴ベクトルを作成する。需要モジュール２１３は次に、試験需要推定と、変更された特徴ベクトル毎の取引要求を受信する対応する試験尤度とを判定する。

需要モジュール２１３は次に、試験価格と取引要求を受信する対応する試験尤度とを処理してマネージャまたは情報の要求者の目標を達成する価格を特定する。一実施形態において、これは、試験価格と、入力価格を取り入れて出力尤度を生成する、滑らかに単調に減少する価格決定モデル３２０を作成する関数を試験価格と尤度データポイントに適合することによって実現される。この処理は、図９Ａ−図９Ｂに示されている。

図９Ａにおいて、価格特徴の値と時限付き在庫の取引要求を受信する尤度とが描かれている。データポイント９００は、現在の価格で取引要求を受信する目的のリスティングの現在の尤度を表す。需要モジュール２１３は次に、価格特徴の値を価格間隔９２０で肯定的および／または否定的にインクリメントすることによって試験データポイント９１０を作成する。価格間隔９２０は、目的のリスティングの価格特徴の元の値の量または比率にすることができる。いくつかの実施形態において、異なる肯定的および否定的価格間隔がある。

需要モジュール２１３は、元の価格のいずれかの方向の価格間隔で価格特徴の値のインクリメントを継続する。この処理は、試験価格の閾値範囲に広がるまたはデータポイントの閾値数が生成されるまで継続し、実施形態に応じて異なる。これらの試験価格は、例えば、現在の価格の２倍／半分と同じくらい高い／低いまたはより高い／より低い場合もある。十分な試験価格が生成された後直ちに、データポイントは、図９Ｃに示すように価格関数９３０で適合される。任意の関数を使用して生成された価格対尤度データを適合することができる。一実施形態において、価格関数９３０は、ワイブル分布である。

価格関数９３０を試験価格と結果として生成された尤度に適合した後、需要モジュール２１３は、価格関数９３０をマネージャに提示して目的のリスティングの価格設定に役立てる。あるいは、需要モジュール２１３は、価格内部情報をマネージャに提供することができる。一実施形態において、価格内部情報は、閾値尤度（取引要求を受信する閾値尤度となる最高価格）に基づくことができる。例えば、閾値尤度が尤度９４０に設定されると、結果として生じる価格内部情報は、価格９５０になる。他の実施形態において、価格は、価格と尤度をかけた値が最大になるように選ぶことができる。例えば、価格９７０と尤度９６０をかけて価格関数９３０が最大になれば、価格９７０は、ユーザの価格内部情報になる。いくつかの実施形態において、収入関数を学習させて価格と取引要求を受信する尤度との間の関係を判定し、結果としてより良い価格内部情報になる。例えば、学習定数ａとｂに基づく価格関数９３０の収入関数は、
Ｒ（ｐ_s，Ｐ（Ｄ（ｆ_s）））＝ｐ_s ^a・Ｐ（Ｄ（ｆ_s））^b
となる（ここにｐ_sは目的のリスティングの仮の価格である）。この場合、この収入関数の訓練データは、前の価格予測とさまざまなリスティングのこれらの価格予測の対応する尤度値になる。さらに他の測定基準を価格内部情報として使用してユーザに提供することができる。

ＩＶ．付加的な考慮
本説明の一部は、情報の操作のアルゴリズムおよび記号表現に関する発明の実施形態を説明している。これらのアルゴリズムの記述および表現は、データ処理の当業者が自分達の仕事の内容を他の当業者に効率的に伝えるために広く使用される。これらの動作は、機能的、計算的、または論理的に説明されているが、コンピュータプログラムまたは等価の電気回路、マイクロコード他によって実装され得る。さらに、これらの動作の配置を、一般性を失うことなく、モジュールと呼ぶことが時には便利であることも証明している。記載された動作およびそれらに関連付けられたモジュールをソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせにおいて具現化することができる。一実施形態において、ソフトウェアモジュールは、記載された一部またはすべてのステップ、動作、または処理を遂行するコンピュータプロセッサによって実行される、コンピュータプログラムコードを包含する持続的コンピュータ可読媒体を備えるコンピュータプログラム製品に実装される。

最後に、明細書に使用される言語は主に、可読性および教育目的で選択されており、本発明の主題を叙述するまたは制限するために選択され得るものではない。従って、発明の範囲が本詳細な説明によってではなく、むしろ本明細書に基づいて出願される特許請求の範囲によって限定されることを意図する。従って、本発明の実施形態の開示は、本発明の範囲が例証的であるが、限定的でないことを意図し、その例は、以下の特許請求の範囲に記載される。

Claims (17)

1. オンライン計算システムで目的のリスティングの特徴ベクトルを受信するステップであって、前記目的のリスティングは、前記オンライン計算システムの複数のクライアントのうちの１つによって予約可能となる時限付き在庫を備え、前記特徴ベクトルは、前記時限付き在庫の現在の価格を示す価格特徴を含む前記リスティングの複数の特徴を備える、ステップと、
   前記時限付き在庫が期限切れになる前に、前記時限付き在庫が前記クライアントのうちの１つから取引要求を受信する尤度の数値表現である需要推定を生成する需要関数に、前記特徴ベクトルを入力するステップと、
   前記需要推定を格納するステップ
   を備える、コンピュータ実行方法。
2. 前記需要関数は、複数の特徴モデルを備え、前記特徴ベクトルの各特徴が前記特徴モデルのうちの１つと関連付けられる、請求項１に記載のコンピュータ実行方法。
3. 前記需要関数は、前記特徴モデルを含む一般化加法モデルを備える、請求項２に記載のコンピュータ実行方法。
4. 前記需要関数は、訓練データからの各サンプルが２進数ラベルと訓練時限付き在庫の訓練特徴ベクトルとを備える前記訓練データで訓練され、前記２進数ラベルは、訓練時限付き在庫が前記訓練時限付き在庫の前記期限切れの前に取引要求を受信したかどうかを表し、前記訓練リスティングの前記訓練特徴ベクトルの複数の特徴が前記訓練時限付き在庫と関連付けられる、請求項１に記載のコンピュータ実行方法。
5. 訓練データは複数の訓練時限付き在庫を備え、および前記訓練時限付き在庫の少なくとも１つは複数のサンプルと関連付けられ、それぞれの前記サンプルは、前記時限付き在庫の前記期限切れの前に、異なる時間期間と関連付けられる、請求項４に記載のコンピュータ実行方法。
6. 前記訓練時限付き在庫のうちの１つは、前記時限付き在庫の前記期限切れの前に取引要求も受信せず、
   前記１つの訓練時限付き在庫と関連付けられたそれぞれの前記サンプルが否定ラベルを有する、請求項５に記載のコンピュータ実行方法。
7. 前記訓練時限付き在庫のうちの１つは、前記時限付き在庫の前記期限切れの前に取引要求を受信し、
   前記取引要求よりも早い時間に発生する前記１つの訓練時限付き在庫と関連付けられたそれぞれの前記サンプルが肯定ラベルを有する、請求項５に記載のコンピュータ実行方法。
8. 前記訓練時限付き在庫のうちの１つは、前記時限付き在庫の前記期限切れの前の第１の時間に取引要求を受信し、前記時限付き在庫のマネージャが前記時間の後の第２の時間に前記取引要求を断るか、または、前記マネージャは受け入れるが、前記クライアントが前記第２の時間に前記取引を取り消すかのいずれかであり、前記第１の時間よりも早い時間に発生する前記１つの訓練時限付き在庫と関連付けられたそれぞれの前記サンプルが肯定ラベルを有する、請求項５に記載のコンピュータ実行方法。
9. 前記第２の時間にまたはそれよりも遅い時間に発生する前記１つの訓練時限付き在庫と関連付けられたそれぞれの前記サンプルは、前記時限付き在庫の前記期限切れの前に別の取引要求が受信されない限り、否定ラベルを有する、請求項５に記載のコンピュータ実行方法。
10. 前記特徴ベクトルは、前記時限付き在庫が期限切れになるまでの期間を示す期限切れまでの時間期間特徴をさらに備える、請求項２に記載のコンピュータ実行方法。
11. リスティングは複数の時間期間にわたって予約でき、各時間期間は、別個に予約可能な期限切れ在庫の別個の項目を表す、請求項１に記載のコンピュータ実行方法。
12. 前記時限付き在庫の前記価格よりも大きいまたは小さい試験価格のセットを生成するステップと、
    前記セットの前記試験価格ごとに、試験需要推定を生成するために前記現在の価格を前記試験価格に置き換える前記特徴ベクトルの変更されたバージョンを前記需要関数に入力するステップと、
    前記試験価格に基づいて生成された前記試験需要推定および前記現在の価格に基づいて生成された前記需要推定で構成された需要推定のセットを生成するステップ
    をさらに備える、請求項１に記載のコンピュータ実行方法。
13. 要求尤度のセットを生成する尤度モデルに需要推定の前記セットを入力するステップであって、各要求尤度は、前記需要推定のうちの１つと関連付けられた前記時限付き在庫がそれぞれの前記試験価格で取引要求を受信する尤度を表す、ステップ
    をさらに備える、請求項２に記載のコンピュータ実行方法。
14. 要求尤度の前記セットに基づいて前記時限付き在庫または前記リスティングの価格内部情報を判定するステップをさらに備える、請求項１３に記載のコンピュータ実行方法。
15. 前記価格内部情報を判定する前記ステップは、
    データポイントのセットに基づいて関数を適合するステップであって、前記セットの各データポイントは、前記セットからの前記要求尤度のうちの１つおよび前記要求尤度を生成するために使用された前記需要推定を生成するために使用される前記試験価格を備え、前記関数は、異なる要求尤度で前記時限付き在庫の価格範囲を表す、ステップを備える、請求項１４に記載のコンピュータ実行方法。
16. 前記価格内部情報を判定する前記ステップは、前記時限付き在庫の価格を前記関数に基づく要求尤度で乗じた積を最大にする新しい価格を選択するステップをさらに備える、請求項１５に記載のコンピュータ実行方法。
17. 前記価格内部情報を判定する前記ステップは、
    式Ｒ（ｐ_s，Ｐ（Ｄ（ｆ_s）））＝ｐ_s ^a・Ｐ（Ｄ（ｆ_s））^bの収入関数を最大にするステップであって、ｐ_sは前記目的のリスティングの仮の価格であり、ｆ_sはｐ_sに等しい価格を用いた前記目的のリスティングの前記特徴ベクトルであり、ａとｂは学習定数である、ステップ
    をさらに備える、請求項１５に記載のコンピュータ実行方法。

Images