JP2023548044A - 車両予約プラットフォーム - Google Patents

Abstract

本開示の態様は、車両予約プラットフォーム（ＶＲＰ）に関する。例では、１つ又は複数の在庫パートナが、ＶＲＰを介して車両を予約できるようにする。したがって、車両予約プラットフォームの顧客は、利用可能な車両の予約をスケジュールすることができる。ＶＲＰは、異なる申込階層を提供することができ、各申込階層は、所与の期間にわたり、場合によっては定期的に、所定数のクレジットに関連付けられている。したがって、顧客は、車両予約を直接購入するのではなく、ＶＲＰを介して、車両予約のために自分のユーザアカウントに関連付けられたクレジットを交換することができる。ユーザアカウントが、十分なクレジット残高を有していない場合、顧客は、不足分に対処するために追加のクレジットを購入することができる。例において、車両予約のクレジット費用は静的であるか、又は様々な要因に基づいて動的に判定され得る。【選択図】 図１

Description

［関連出願の相互参照］
[0001]本出願は、２０２０年１０月２８日に出願された「Ｖｅｈｉｃｌｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｌａｔｆｏｒｍ」という名称の米国仮特許出願第６３／１０６，６２７号に対する優先権を主張し、その開示内容全体は、参照により本明細書に組み込まれる。

[0002]特殊用途車両へのアクセスは、従来、所有費用、メンテナンス費用、潜在的に複雑な車両輸送ロジスティクス、保管スペース要件、及び／又は保管費用を伴う可能性がある車両所有の形態をとる場合がある。したがって、それがなければ特殊用途車両を使用する可能性があるユーザが、そのような障壁によって、アクセスを思いとどまる可能性がある。

[0003]実施形態は、これら及び他の一般的な考察に関して説明されている。また、比較的具体的な問題が論じられているが、実施形態は、背景技術で特定された特定の問題を解決することに限定されるべきではないことが認識されるであろう。

[0004]本開示の態様は、車両予約プラットフォームに関する。例では、１つ又は複数の在庫パートナが、車両予約プラットフォームを介して車両を予約できるようにする。したがって、車両予約プラットフォームの顧客は、利用可能な車両の予約をスケジュールすることができる。複数の予約タイプ、たとえば受取予約タイプ、配送予約タイプ、ガイド付き予約タイプ、又はセルフガイド付き予約タイプを提供することができる。顧客が車両予約プラットフォームを介して予約をスケジュールすると、車両予約プラットフォームは、予約の履行を容易にするために、関連する在庫パートナと自動的に調整することができる。

[0005]例では、顧客は、車両予約プラットフォームに申し込む。車両予約プラットフォームは、異なる申込階層を提供することができ、各申込階層は、所与の期間にわたり、場合によっては定期的に、所定数のクレジットに関連付けられている。したがって、顧客は、車両予約を直接購入するのではなく、車両予約プラットフォームを介して、車両予約のために、自分のユーザアカウントに関連付けられたクレジットを交換することができる。ユーザアカウントが、十分なクレジット残高を有していない場合、顧客は、不足分に対処するために追加のクレジットを購入することができる。例では、車両予約のクレジット費用は静的であるか、又は様々な要因に基づいて動的に判定され得る。

[0006]この概要は、以下の詳細な説明でさらに説明されている概念の選択を、簡略化された形態で紹介するために提供される。この概要は、主張された主題の主要な特徴又は本質的な特徴を特定することを意図したものではなく、主張された主題の範囲を限定するために使用されることを意図したものでもない。

[0007]以下の図を参照して、非限定的且つ非網羅的な例が説明される。

車両予約プラットフォームのための例示的なシステムの概要図である。 本明細書で説明されている車両予約プラットフォームの態様を使用して車両予約が実行される例示的な地域の概要図である。 顧客デバイスによる車両予約のための例示的な方法の概要図である。 車両予約プラットフォームによって車両予約を生成するための例示的な方法の概要図である。 車両予約プラットフォームの在庫パートナによる予約を履行するための例示的な方法の概要図である。 本開示の態様による車両予約プラットフォームの例示的なユーザインターフェース態様を示す図である。 本開示の態様による車両予約プラットフォームの例示的なユーザインターフェース態様を示す図である。 本開示の態様による車両予約プラットフォームの例示的なユーザインターフェース態様を示す図である。 ユーザアカウントに関連付けられたクレジットを生成するための例示的な方法の概要図である。 は、本明細書で説明されている態様による、クレジットを適用するためのインジケーションを処理するための例示的な方法の概要図である。 車両予約プラットフォームを実施するためのコンピューティングシステムの図である。

[0017]以下の詳細な説明では、本明細書の一部を形成し、特定の実施形態又は例を例示するために示される添付の図面を参照する。本開示から逸脱することなく、これらの態様を組み合わせることができ、他の態様を利用することができ、構造上の変更を行うことができる。実施形態は、方法、システム、又はデバイスとして実施することができる。したがって、実施形態は、ハードウェア実施、完全なソフトウェア実施、又はソフトウェアとハードウェアの態様を組み合わせた実施の形態をとることができる。したがって、以下の詳細な説明は、限定的な意味で解釈されるべきではなく、本開示の範囲は、添付の特許請求の範囲及びそれらの均等物によって定義される。

[0018]例では、様々な障壁が、特殊用途車両へのユーザのアクセスを複雑にするか、又はその他の形で阻止することがある。障壁の例は、所有費用、メンテナンス費用、潜在的に複雑な車両輸送ロジスティクス、保管スペース要件、及び／又は保管費用を含むが、これらに限定されない。そのような障壁の結果として、ユーザは、車両の所有を回避したり、関連するパワースポーツ活動に参加する頻度を減らしたり、パワースポーツ活動を完全にやめたりすることさえある。特殊用途車両の例は、多目的車両及びレクリエーション車両を含む。たとえば、多目的車両は、低速車両（たとえば、ゴルフカート）、芝刈り機、又はフリート車両であり得る。別の例として、レクリエーション車両は、全地形万能車両（ＡＴＶ）、サイドバイサイド（ＳｘＳ）車両、多目的車両、オートバイ、スリングショット（ＳＬＧ）、三輪車、スノーモビル、又は船舶であってもよい。

[0019]したがって、本開示の態様は、車両予約プラットフォームに関する。例では、予約プラットフォームは１つ又は複数の申込階層を提供する。申込階層は、所与の期間にわたり、場合によっては定期的に、所定数のクレジットに関連付けられている。たとえば、第１の階層は、毎月３クレジットを提供し得る一方、第２の階層は、３か月ごとに６クレジットを提供し得る。申込階層は、所定期間（たとえば、１か月の場合は毎週、６か月の場合は毎月、１年間の場合は四半期ごと）を有する。ユーザは、車両予約プラットフォーム用のユーザアカウントを有することができ、ユーザアカウントは、車両予約プラットフォームによって提供される申込階層に関連付けられている。所与の期間に使用されなかったクレジットは、ユーザのアカウントによって保持されるため、後で使用できるようになる。たとえば、ユーザが１か月あたり３クレジットを提供する申込階層に申し込み、ユーザが１クレジットしか使用しない場合、２クレジットは、ユーザアカウントに関連付けられたままとなり、将来の使用のために利用することができる。他の例では、（たとえば、所与の期間後、又は別の所定期間後）クレジットが期限切れになる場合があることが認識されるであろう。

[0020]本明細書で使用される「クレジット」は、申込会費（たとえば、後払い又は前払いベース）と、車両予約プラットフォームを介して車両を予約する能力との間の仲介として機能する。さらに、開示された態様の代替例は、代わりにポイント又はトークンを使用することができ、又は別の例として、車両予約（たとえば、１か月あたり１回の終日予約、又は四半期ごとに１回の２日間予約）と、より直接的に関連付けられることができることが認識されるであろう。１つ又は複数のクレジットに関して例が説明されているが、クレジットは整数である必要はなく、代わりに分数であってもよい（たとえば、ユーザは０．２５クレジットを受け取るか、又は１．５クレジットを使うことができる）ことが認識されるであろう。

[0021]車両予約プラットフォームは、予約可能な車両の在庫を有する。在庫は、１つ又は複数のタイプの特殊用途車両を含むことができる。したがって、車両予約プラットフォームのユーザは、ユーザアカウントに関連付けられたクレジットを使用して在庫から車両を予約することができる。車両予約に関連付けられたクレジット額が、ユーザアカウントに関連付けられたクレジット額よりも多い場合、ユーザは追加のクレジットを購入することができる。申込階層によって提供されるものとは別にクレジットを購入するオプションは、車両予約プラットフォームに申し込むユーザに制限される場合があり、そのため、非申込者は、それぞれのユーザアカウントのクレジットを直接購入できない場合がある。他の例では、クレジットは定期的に取得され、次の期間に「繰り越す」ことができるため、ユーザは、最終的に車両予約を行うために、クレジットを保存することを選択できる。

[0022]例において、車両の在庫の少なくとも一部は、車両予約プラットフォームによって、及び／又は、本明細書で「在庫パートナ」と呼ばれる１つ又は複数のサードパーティによって提供される。たとえば、在庫パートナは、車両予約プラットフォームを介して車両を利用可能にすることができる車両販売業者（たとえば、特殊用途車両を販売するサードパーティ）であり得る。在庫パートナの別の例は、車両予約プラットフォームを介して車両を利用可能にする車両仕入業者（たとえば、特殊用途車両を使用したガイド付き／セルフガイド付きツアーを提供するサードパーティ）である。在庫パートナは、車両予約プラットフォームに在庫を提供した結果として、料金又は予約収益の一部を受け取る場合がある。

[0023]車両予約プラットフォームは、異なる予約タイプを提供することができる。たとえば、受取予約タイプ、配送予約タイプ、ガイド付き予約タイプ、又はセルフガイド付き予約タイプである。在庫パートナは、利用可能な予約タイプのサブセットを提供する場合があり、予約プラットフォームを介して利用可能なすべての予約タイプの予約を提供する必要はない。たとえば、車両販売業者は、１セットの予約タイプ（たとえば、受取及び配送）を提供し、車両仕入業者は、別のセットの予約タイプ（たとえば、ガイド付きツアー及びセルフガイド付きツアー）を提供する場合がある。本明細書では在庫パートナの例が説明されているが、車両予約プラットフォームを介して利用可能な在庫は、他の様々なサードパーティのいずれかによって提供され得ることが認識されるであろう。たとえば、個人は、車両予約プラットフォームを介して在庫を提供し、関連する車両予約を提供することができる。

[0024]車両に関連付けられたクレジット費用は、様々な技法のいずれかに従って判定することができる。たとえば、クレジット費用は、車両の種類（たとえば、メーカ、モデル、乗客定員、貨物容量、又は能力）、車両場所（たとえば、場所が都市部か地方かなど）、又は車両の年数に応じて判定され得る。別の例として、クレジット費用は、特定の車両タイプ、季節又は休日の需要、予約タイプ、又はユーザに利用可能な車両の近さに対する需要を含むがこれらに限定されない、様々な履歴及び／又は予測要因のいずれかに従って動的に生成され得る。一部の例では、申込階層ごとに異なる価格設定技法が使用される。たとえば、ある階層に関連付けられた価格は、静的な技法に従って判定され、別の階層の価格は動的に判定される。別の例として、申込階層は、割引価格を受け取る場合がある。

[0025]ユーザは、車両予約プラットフォームへの申込以外の機構を介してクレジットを受け取ることができる。例では、ユーザは、特殊用途車両を所有することができ、特殊用途車両がメンテナンスを受けている間、１つ又は複数のクレジットを受け取ることができる。したがって、ユーザは、特殊用途車両が整備されている間、車両予約プラットフォームを介してパワースポーツ活動に従事し続けることができる。他の例では、ユーザは後で使用するためにクレジットを保持することができる。別の例として、ユーザは、種々の例のうちでも特に、別のユーザを車両予約プラットフォームに紹介することと引き換えに、イベントに参加することと引き換えに、又は試用メンバシップ又はロイヤリティプログラムの一部として、１つ又は複数のクレジットを受け取ることができる。

[0026]いくつかの事例では、ユーザは、車両予約プラットフォームへの申込のキャンセルを要求することができる。申込期間の満了前（たとえば、６か月の申込の４か月目）にキャンセルが要求された場合、キャンセル料金がユーザに課される場合がある。他の例では、キャンセル料金は車両の所有権に適用され、それにより、ユーザは、車両予約プラットフォームへの申込メンバシップを、車両の所有権に有効に「変換」することができる。同様に、ユーザのアカウントに関連付けられたクレジットが、車両の所有権に適用される場合がある。したがって、キャンセル料金、比例配分された申込費用、及び／又はユーザのアカウントに関連付けられた残りのクレジットを使用して、それに応じて、車両に関連付けられた購入価格を引き下げることができる。

[0027]本明細書の例は、クレジットの残高と、１つ又は複数のそのようなクレジットの適用に関して説明されているが、各クレジットは代替可能である必要はなく、代わりに一意に識別可能であってもよいことが認識されるであろう。たとえば、クレジットには、シリアル番号、又は一意の識別子が関連付けられている場合がある。そのようなクレジットは、値、起点の日付及び／又は時間、クレジットの作成の結果を示すソース、及び／又は有効期限及び／又は時間を含むが、これらに限定されない、クレジット属性のセットを有することができる。２つのクレジットは、関連付けられたシリアル番号又は一意の識別子に従って一意に識別可能であるが、２つのクレジットが、異なるセットのクレジット属性を有する必要がないことが認識されるであろう。

[0028]本明細書で使用される「一意に識別可能なクレジット」は、関連付けられたシリアル番号又は他の識別子を有するクレジットである。そのような一意に識別可能なクレジットは、ユーザの観点から一意に識別可能である必要はなく、代わりに、ユーザアカウントに関連付けられた他のクレジットと同じ又は類似しているように見えてもよいことが認識されるであろう。それに加えて、一意に識別可能なクレジットは、グローバルに一意である必要はなく、代わりに、種々の例のうちでも特に、同じユーザアカウントに関連付けられた１つ又は複数の他のクレジットと比較して一意に識別可能である場合がある。

[0029]値クレジット属性は、クレジットが生成されたコンテキストに関連付けられた情報を提供することができる。たとえば、値クレジット属性は、種々の例のうちでも特に、クレジットを取得するために（たとえば、ユーザによって）発生した費用を、たとえば、申込、試用メンバシップ、ロイヤリティプログラム、イベントへの参加、又は別のユーザの紹介の結果として、クレジットを取得できることを示すことができる。したがって、２つのクレジットは、本明細書で説明されている態様に従って同様に引き換えることができるが、おのおの異なる値クレジット属性を有することができ、以て、１つ又は複数の関連付けられたクレジット属性に基づいて、他の様々な判定のいずれかから、トランザクションに関連付けられた実際のクレジット値に関する関連付けられた判定をすることができる。

[0030]例として、第１のクレジットは、それが（たとえば、名目関連の値を有する）販促クレジットであることを示す値クレジット属性を有することができる一方、第２のクレジットは、（たとえば、メンバシップ階層に関連付けられた値を有する）申込の結果として、ユーザアカウントに関連して生成されたクレジットであることを示す値クレジット属性を有することができる。例では、（たとえば、２つ以上のクレジットの費用がかかる予約又は他のアイテム／サービスのために）両方のクレジットをともに適用することも、又は（たとえば、２つのそのようなアイテム又はサービスのために）別々に適用することもできる。ユーザがクレジット残高を適用すると、クレジットのセットが（たとえば、種々の例のうちでも特に、少なくとも部分的にユーザ選択に基づいて、自動的に、又はそれらの組合せで）判定され、それに応じて適用され得る。

[0031]各クレジットに関連付けられた値クレジット属性は、たとえば、クレジットのセットが適用されるとき、又はユーザアカウントのクレジット残高を判定するとき、１つ又は複数の判定基準に関する判定を可能にすることができる。たとえば、実現判定基準は、適用されたクレジットのセットの各クレジットの値クレジット属性を合計し、その合計値を、クレジットのセットが適用された１つ又は複数のアイテム／サービスの費用と比較することに基づいて判定することができる。同様に、合計値は、種々の例のうちでも特に、本明細書で説明されている態様に従って、ユーザが、車両所有権に対してクレジットのセットを適用する場合のように、（たとえば、ユーザが十分なクレジットを有していない）アイテム／サービスに対してクレジットのセットをより正確に適用するために使用される場合がある。したがって、平均クレジット値を使用することができる残高ベースの評価と比較して、本明細書で説明されている態様は、各クレジットの関連する値クレジット属性に基づいて、クレジットのセットの合計値をより正確に判定することができる。

[0032]いくつかの例では、所与のクレジットが有効期限を過ぎた場合や、非プロモーションクレジットを使用してのみアイテム／サービスを取得できる場合のように、関連付けられたクレジット属性に基づいて、所与のアイテム又はサービスに対して、クレジットのサブセットのみを適用できると判定され得る。別の例として、クレジットの合計値が、クレジットのセットが引き換えられるアイテム／サービスの費用を下回ると判定される場合がある。そのような事例では、異なるセットのクレジットを（たとえば、費用に近いか、又は少なくとも費用に等しい合計値を有する）トランザクションに適用できるか、又はそのようなトランザクションをユーザ選択のために利用できないようにすることができるかを判定することができる。

[0033]本明細書で説明されている態様によるクレジット属性は、他の様々な処理のいずれにも使用することができる。たとえば、有効期限クレジット属性を使用して、ユーザアカウントに関連付けられたクレジットを期限切れにするか削除するかを判定することができる。別の例では、有効期限クレジット属性によって、有効期限クレジットによって示される日付／時間が経過した結果として、値クレジット属性が更新される場合がある。

[0034]ユーザは、自分のクレジット残高の少なくとも一部を、あるユーザアカウントから別のユーザアカウントに送金することができる。ユーザは、送金のために、一意に識別可能なクレジットのセットを選択できる場合があり、別の例として、クレジットのセットは、様々な技法のいずれかを使用して自動的に判定される場合があり、その例が以下で論じられている。いくつかの事例では、送金の結果として、１つ又は複数のクレジット属性が更新されることがある。たとえば、クレジット属性は、クレジットが送金されたユーザを示すように設定される場合がある。別の例として、送金の結果として、値クレジット属性が減額されるか、又は、そうでなければ、変更される可能性がある。いくつかの事例では、クレジットは所定回数送金され、その後は送金されないことがある。そのような事例では、関連するクレジット属性を更新して、残りの送金額を減額させることができる。クレジット属性の例が説明されているが、他の例では、追加の、代替の、又はより少ないクレジット属性を使用できることが認識されるであろう。

[0035]したがって、より単純な残高ベースのクレジット処理と比較して、本明細書で説明されている態様は、他の方法では達成が困難又は不可能なレベルの粒度及び関連する判定基準の生成を可能にすることができる。さらに、クレジットが生成されるコンテキストが、（たとえば、地域又はロケールに従って、メンバシップオプションの変更に基づいて、又は他の様々な要因のいずれかに基づいて）時間の経過とともに変化する可能性があることを考えると、各クレジットのクレジット属性のセットを維持することは、そのような要因に基づいて追加の処理を有効にする場合がある。たとえば、第１のコンテキストに対して（たとえば、ある地域において、又は第１の時点で）生成されたクレジットは、第２のコンテキストに対して（たとえば、異なる地域において、又は第２の時点において）生成されたクレジットよりも低い関連値を有する場合があり、トランザクションが、同じ又は類似のアイテム／サービスに関するものであっても、第１の地域におけるトランザクションの実現判定基準は、第２の地域におけるトランザクションにおける実現判定基準とは異なる場合がある。

[0036]申込車両予約プラットフォーム及び関連する特殊用途車両のコンテキストで例が説明されているが、本明細書で説明されている態様は、他の様々なコンテキストのいずれにも適用できることが認識されるであろう。たとえば、クレジットのセットは、種々の例のうちでも特に、様々な申込（たとえば、ソフトウェア及び／又は物理的なアイテム）のために、ソフトウェア又はハードウェア機能をロック解除するために、１つ又は複数のアクセサリのために、及び／又は車両メンテナンスとの引き換えのために適用できる。

[0037]別の例として、クレジット残高は、種々の例のうちでも特に、ホスピタリティシナリオにおいて、又は（たとえば、本明細書で説明されているように、ユーザがインタラクションの結果としてクレジットを獲得するか、及び／又は、時間が経過すると、クレジットが期限切れになるか、又は、値を減少させる可能性がある）ロイヤリティプログラムの一部として、本明細書で説明されている態様に従って管理され得る。したがって、ユーザは、同様に、宿泊、食事、及び／又は他の様々なアメニティのいずれかを含む経験の様々な態様にクレジットを適用することができる。いくつかの例では、ユーザのクレジット残高は、たとえば、特に食事や１つ又は複数のアメニティに適用できるように、様々なタイプの一意に識別可能なクレジットを含むことができる。他の例では、ユーザのクレジット残高は、アイテム／サービスの所与のセットに特に適用可能である必要がないことが認識されるであろう。代わりに、各経験にクレジット額が関連付けられている場合がある。ユーザは、そのような例では、種々の例のうちでも特に、ロイヤリティプログラム、申込、及び／又は紹介の結果として、クレジットを取得することができる。

[0038]このように、本明細書で説明されている車両予約プラットフォームは、申込モデルに従って、簡単且つ便利な車両予約を容易にする。ユーザは、（たとえば、関連付けられた申込階層に従って取得された）ユーザアカウントに関連付けられたクレジットを使用して、特殊用途車両を予約する。これに応じて、車両予約プラットフォームは、車両予約に関連付けられたロジスティクスを（たとえば、ファーストパーティ又はサードパーティのいずれかと）プログラム的に調整する。そのような態様は、従来、特殊用途車両及び関連付けられたパワースポーツ活動へのアクセスに関連付けられていた障壁を軽減又は解決し、それにより、より多くのユーザが、開示された車両予約プラットフォームを介してそのような活動に参加し、特殊用途車両を利用できるようになる。

[0039]図１は、車両予約プラットフォームのための例示的なシステム１００の概要を示している。図示されているように、システム１００は、顧客デバイス１０２、仕入業者デバイス１０４、販売業者デバイス１０６、ネットワーク１０８、及び予約プラットフォーム１１０を備えている。例では、顧客デバイス１０２、仕入業者デバイス１０４、販売業者デバイス１０６、及び予約プラットフォーム１１０は、種々の例のうちでも特に、ローカルエリアネットワーク、ワイヤレスネットワーク、又はインターネット、又はそれらの任意の組合せを含むことができるネットワーク１０８を介して通信する。

[0040]予約プラットフォーム１１０は、サーバコンピューティングデバイスであってもよいし、分散コンピューティングデバイスを形成するコンピューティングデバイスのセットであってもよい。顧客デバイス１０２、仕入業者デバイス１０４、及び販売業者デバイス１０６はそれぞれ、モバイルコンピューティングデバイス、ラップトップコンピューティングデバイス、タブレットコンピューティングデバイス、又はデスクトップコンピューティングデバイスを含むがこれらに限定されない、様々なコンピューティングデバイスのいずれかであり得る。システム１００は、１つの予約プラットフォーム１１０と、３つのデバイス１０２、１０４及び１０６とを備えているように示されているが、他の例では、任意の数のそのような要素が使用され得ることが認識されるであろう。さらに、予約プラットフォーム１１０及びデバイス１０２、１０４及び１０６に関して本明細書で説明されている機能は、他の例では、他の様々な構成のいずれかで、任意の数の異なるコンピューティングデバイス間で分散されるか、又は任意の数の異なるコンピューティングデバイスに実装され得る。

[0041]予約プラットフォーム１１０は、要求プロセッサ１１８、スケジューリングエンジン１２０、在庫マネジャ１２２、価格設定エンジン１２４、予約データストア１２６、及びユーザデータストア１２８を備えるものとして示されている。例では、要求プロセッサ１１８は、１つ又は複数の他のデバイス（たとえば、それぞれデバイス１０２、１０４及び１０６のアプリケーション１１２、１１４及び１１６）と通信して、本明細書で説明されている車両予約プラットフォームの態様を提供する。要求プロセッサ１１８は、種々の機能のうちでも特に、利用可能な在庫に関するインジケーション（及び、いくつかの例では、価格設定エンジン１２４によって判定され得るような、車両のための、関連するクレジット費用）を提供し、利用可能な在庫に関連付けられた予約要求を受け取り、在庫パートナから在庫及び予約の更新を受け取り、予約更新を提供する。たとえば、要求プロセッサ１１８は、種々の例のうちでも特に、メンバシップを管理し、車両を予約し、在庫を予約可能にし、及び／又は予約履行を管理する（たとえば、アプリケーション１１２、１１４及び／又は１１６によってアクセスされ得る）ウェブサイトを生成し得る。他の例では、要求プロセッサ１１８は、（たとえば、アプリケーション１１２、１１４及び／又は１１６によって使用され得る）アプリケーションプログラミングインターフェース（ＡＰＩ）を提供して、ウェブサイトの代替又は追加などの態様を実行する。したがって、予約プラットフォーム１１０と通信するために、様々な技法のいずれかを使用できることが認識されるであろう。

[0042]スケジューリングエンジン１２０は、予約プラットフォーム１１０の車両予約を生成、修正、削除、追跡、又はさもなければ管理する。例では、車両予約は、予約データストア１２６に記憶される。予約を示すインジケーションは、顧客デバイス１０２のクライアントアプリケーション１１２から受信され得る。車両予約は、（たとえば、ユーザデータストア１２８の）ユーザアカウントに関連付けることができ、１つ又は複数の関連付けられた車両、（たとえば、時間範囲又は１つ又は複数の日を含む）予約時間、及び／又は予約タイプ（たとえば、受取、配送、ガイド付きツアー、又はセルフガイド付きツアー）を有することができる。いくつかの事例では、車両予約が複数のユーザアカウントに関連付けられているため、複数のユーザが１つ又は複数の車両をともに予約できるようになる。それに応じて、ユーザのアカウントに関連付けられたクレジット残高が減額され、いくつかの事例では、追加のクレジットを購入するためのインジケーションがそれに応じて処理される。

[0043]いくつかの事例では、スケジューリングエンジン１２０は（要求プロセッサ１１８と連携して）、仕入業者デバイス１０４の予約アプリケーション１１４、又は販売業者デバイス１０６の在庫アプリケーション１１６に予約インジケーションを提供し、以て、予約プラットフォーム１１０のユーザからの予約要求を、仕入業者又は販売業者に警告する。他の例では、スケジューリングエンジン１２０は、ユーザの予約に関連付けられた仕入業者デバイス１０４又は販売業者デバイス１０６から更新インジケーションを受信する。それに応じて、スケジューリングエンジン１２０は、予約データストア１２６における予約を更新することができ、及び／又は、顧客デバイス１０２に提供されるインジケーションを生成することができる。

[0044]在庫マネジャ１２２は、予約プラットフォーム１１０を介して利用可能な在庫を管理する。上記の例に戻って説明するように、在庫マネジャ１２２は、クライアントアプリケーション１１２からの車両予約に関連付けられている在庫から、１つ又は複数の車両を削除することができ、それにより、別のユーザが、同じセットの車両を同時に予約しないようにすることができる。それに加えて、又はその代わりに、在庫マネジャ１２２は、サービス中の在庫から１つ又は複数の車両を削除することができる。それに加えて、又はその代わりに、在庫マネジャ１２２は、顧客によって返品され、及び／又は仕入業者によって購入され、及び／又は販売業者によって製造された１つ又は複数の車両を、在庫に追加することができる。在庫マネジャ１２２はまた、予約アプリケーション１１４及び／又は在庫アプリケーション１１６からのインジケーションを処理することができる。たとえば、予約アプリケーション１１４は、車両が特定の日付及び時間に予約プラットフォーム１１０を介して利用できないように、仕入業者デバイス１０４に関連付けられた仕入業者が車両の予約を独自に処理したことを示すことができる。別の例として、在庫アプリケーション１１６は、販売業者デバイス１０６に関連付けられた販売業者が、車両を販売したことを示すことができ、その結果、車両の予約はもはや行われないようになる。したがって、在庫マネジャ１２２は、予約可能な車両の正確な在庫を維持するために、（たとえば、予約プラットフォーム１１０のユーザに関連付けられた、又は様々な在庫パートナのいずれかからの）様々なインジケーションをいずれでも処理できることが認識されるであろう。

[0045]価格設定エンジン１２４は、予約プラットフォーム１１０の車両予約のためのクレジット費用を生成することができる。例において、価格設定エンジン１２４は、たとえば、車両のタイプ（たとえば、メーカ、モデル、乗客定員、貨物容量、又は能力）、車両場所（たとえば、その場所が都市であるか又は地方であるかなど）、又は車両年齢に基づいて、車両予約のための静的クレジット費用を生成する。他の例では、価格設定エンジン１２４は、特定の車両タイプの需要、季節的又は休日の需要、予約タイプ、又は利用可能な車両のユーザへの近さを含むがこれらに限定されない、様々な履歴及び／又は予測要因のいずれかに従って、車両予約の動的クレジット費用を生成する。したがって、価格設定エンジン１２４は、スケジュールに従って、又は様々な任意のイベントに応じて、車両の在庫に関連付けられた車両予約のクレジット費用を生成することができる。たとえば、クレジット費用は、種々の例のうちでも特に、車両が車両の在庫に追加されるとき、及び／又は（たとえば、顧客デバイス１０２のクライアントアプリケーション１１２から要求プロセッサ１１８によって受信され得るような）現在利用可能な在庫に対する要求に応じて、価格設定エンジン１２４によって生成され得る。

[0046]例では、価格設定エンジン１２４は、たとえば、関連する値クレジット属性及び／又は他の様々なクレジット属性のいずれかに基づいて、ユーザアカウントに関連付けられたクレジットのセットに従って、動的なクレジット費用を生成することができる。同様に、価格設定エンジン１２４は、たとえば、ユーザインジケーションに少なくとも部分的に基づいて、自動的に、又はそれらの組合せで、ユーザインジケーションに応じて、ユーザのクレジット残高から、適用するクレジットのセットを判定し得る。

[0047]ユーザデータストア１２８は、予約プラットフォーム１１０のユーザアカウントを記憶する。上記で論じられたように、要求プロセッサ１１８は、予約プラットフォーム１１０へのメンバシップに関連付けられた要求を処理する。たとえば、予約プラットフォーム１１０に申し込むための要求は、申込階層を示すことができる、登録プロセスの一部として受け取られてもよい。したがって、ユーザが選択した申込階層を示すユーザアカウントが、ユーザデータストア１２８に生成される。ユーザアカウントは、請求情報（たとえば、クレジットカード情報及び請求先住所）、連絡先情報（たとえば、電子メールアドレス、電話番号、及び／又は郵送先住所）、及び／又は更新プリファレンス（たとえば、申込は、自動的に更新する必要があるか否か、又は更新前に更新通知を送信する必要があるか否か）をさらに備えることができる。

[0048]予約プラットフォーム１１０は、ユーザデータストア１２８のユーザアカウントにクレジットを定期的に追加することができる。上記で論じられたように、申込階層は、所与の期間にわたり所定数のクレジットを提供することができる。したがって、所定期間よりも長い時間が経過した場合、予約プラットフォーム１１０は、（ユーザアカウントに関連付けられた申込階層によって示され得るような）ユーザの申込階層の所定数のクレジットに従って、ユーザアカウントのクレジット残高を増額させる。他の例では、予約プラットフォーム１１０は、一意に識別可能なクレジットを生成し、生成されたクレジットをユーザアカウントに関連付け、その例は、図６Ａに関して以下でより詳細に議論される。たとえば、第１のユーザは、１か月あたり１クレジットを受け取る階層に申し込み、第２のユーザは、１か月あたり３クレジットを受け取る第２の階層に申し込み、第３のユーザは、１か月あたり９クレジットを受け取る第３の階層に申し込むことができる。各階層は、第１の階層及び第２の階層では１２か月の期間、第３の階層では、６か月の期間など、関連する期間を有し得る。階層及び関連する費用、クレジット額、期間、及び期限は、例示を目的として提供されており、他の例では、他の階層を使用できることが認識されるであろう。

[0049]階層は、線形的又は非線形的にスケーリングできることが認識されるであろう。たとえば、第１の階層は、１クレジットで月額９９ドル（クレジットあたり９９ドル）の費用がかかり、第２の階層は、３クレジットで月額２４９ドル（クレジットあたり８３ドル）の費用がかかる場合がある。したがって、第２のユーザは、第１の階層のクレジットあたりの費用と比較して、３クレジット階層で月額５０ドルの割引を受ける。同様に、第３のユーザが、第２の階層の３倍のクレジットを受け取るが、３倍未満のクレジットを使用できるように、第３の階層は、９クレジットに対して月額６９９ドル（クレジットあたり７７．６７ドル）の費用がかかる場合がある。車両を予約するためにクレジットが使用されるとき、ユーザアカウントのクレジット残高は、本明細書で説明されている態様に従って、予約された車両のクレジット費用に従って減額される。ユーザは、クレジットを受け取った期間にクレジットを使用することも、後で使用するためにクレジットを保持することもできる。たとえば、第３のユーザは、毎月９クレジットすべてを使用することができる。別の例として、第２のユーザは３か月分のクレジット（たとえば、第２の申込階層に応じて、１か月あたり３クレジット）を保持して、最終的に第３のユーザが１か月に行うのと同等の（たとえば、９クレジットの費用がかかる）セットを予約することができる。

[0050]いくつかの事例では、クレジットは、ユーザアカウント間で送金可能である場合がある。たとえば、第１のユーザは、クレジット残高の少なくとも一部を第２のユーザに送って、第１のユーザのユーザアカウントのクレジット残高が、第２のユーザのユーザアカウントのクレジット残高の対応する増加と同様の額だけ減少させることができる。いくつかの事例では、すべてのクレジット残高が第１のユーザから第２のユーザに送金されないように、送金された額から料金を（たとえば、絶対値又はパーセンテージで）差し引くことができる。他の事例では、２人のユーザがそれぞれのクレジット残高を「プール」して、複数のユーザアカウントのクレジット残高を利用して予約を行うことができる。そのようなグループ予約の１つ又は複数の車両に関連するクレジット費用は、複数のユーザアカウント間で均等に分割されるか、又はユーザによって判定されるような、他の任意の区分に従って分割することができる。

[0051]上述したように、ユーザアカウント間のクレジット送金の結果として、１つ又は複数のクレジット属性を追加、削除、又は変更することができる。さらに、クレジット費用が複数のユーザアカウント間で分割される例では、一意に識別可能なクレジットに関して上記で論じられた処理は、各ユーザによって提供されたクレジットのセットに基づいて実行され得る。たとえば、実現判定基準は、クレジットのセットが適用された１つ又は複数のアイテム／サービス（たとえば、１つ又は複数の特殊用途車両のグループ予約）の費用を考慮して、各ユーザからのクレジットのセットの合計値に基づいて判定され得る。他の例では、グループ実現判定基準（及び／又は他の判定基準）以外の実現判定基準が、個人ベースで、又は他の様々なグループ分け（たとえば、地域別、姓別、又はメンバシップ期間）のいずれかに従って計算され得る。

[0052]ユーザアカウントは、単一の個人に関連付けられる必要はなく、いくつかの例では、代わりに、個人のグループ（たとえば、カップル、家族など）に関連付けることができることが認識されるであろう。登録プロセスの一部として、実行された権利放棄が、１人又は複数の個人に対して受け取られ、その後、それに応じてユーザアカウントに関連付けられている。種々の情報のうちでも特に、緊急連絡先情報及び／又は保険情報もまた、ユーザアカウントの一部として記憶され得る。例では、ユーザアカウントは、本明細書で説明されている態様に従って車両を予約するために利用可能なクレジットの額をさらに含んでいる。この額は、ユーザアカウントに関連付けられた申込階層に基づいて判定されるように、定期的に増額される場合がある。いくつかの例では、既存のユーザアカウントが使用される場合がある。たとえば、別のプラットフォーム又はサービスは、車両予約プラットフォームのユーザアカウントにコピーされるか、又は組み込まれるように、通常はユーザから要求される情報の少なくとも一部をすでに有している場合がある。

[0053]顧客デバイス１０２は、クライアントアプリケーション１１２を備えるものとして例示されている。例では、クライアントアプリケーション１１２は、ウェブブラウザ、ネイティブアプリケーション、又はそれらの組合せである。上記で論じられたように、クライアントアプリケーション１１２は、予約プラットフォーム１１０と通信して、本明細書で説明されている車両予約の態様を実行する。たとえば、クライアントアプリケーション１１２は、利用可能な申込階層のセットがユーザに提示される登録プロセスを容易にし、以て、ユーザが申込階層を選択し、それに応じてユーザアカウントを作成できるようにする。同様に、クライアントアプリケーション１１２は、権利放棄を提示し、（たとえば、請求情報、連絡先情報、及び／又は緊急連絡先情報のような）種々の情報のうちでも特に、ユーザの電子署名を収集することができる。

[0054]クライアントアプリケーション１１２は、利用可能な車両の表示を生成し、以て、ユーザが車両を予約できるようにする。例では、クライアントアプリケーション１１２は、（たとえば、スケジューリングエンジン１２０、在庫マネジャ１２２、及び／又は価格設定エンジン１２４と連携した要求プロセッサ１１８によって生成され得るような）予約プラットフォーム１１０の在庫から、利用可能な車両のセットを受け取る。利用可能な車両のセットは、フィルタ基準のセットに少なくとも部分的に基づいて（たとえば、顧客デバイス１０２で、又は予約プラットフォーム１１０によって）フィルタリングされ得る。フィルタ基準のセットは、予約プラットフォーム１１０で判定されてもよく、及び／又は顧客デバイス１０２のユーザによって提供されてもよい。フィルタ基準の例は、（たとえば、メーカ、モデル、乗客定員、貨物容量、又は能力のような）車両のタイプ、（たとえば、地理的場所、又は地理的場所の所定範囲に位置する）車両場所、（たとえば、特定の日付及び／又は時間、又は車両が指定された日数の間利用可能であるか否かのような）空室情報、及び／又は（たとえば、十分なクレジットがユーザアカウントに関連付けられているか否か、又は制限が特定の季節の特定の車両又は利用可能性に影響を与えるか否かのような）ユーザアカウント情報を含んでいるがこれらに限定されない。本明細書では例示的なフィルタが論じられているが、他の例では、追加の、代替の、又はより少ないフィルタを使用できることが認識されるであろう。

[0055]ユーザは、クライアントアプリケーション１１２を使用して車両を予約する。したがって、クライアントアプリケーション１１２は、説明されている態様に従って、予約プラットフォーム１１０と通信して、予約データストア１２６に予約を生成する。それに応じて、ユーザアカウントに関連付けられたクレジットの額が減少する場合がある。予約された車両が在庫パートナによって提供される例では、それに応じてパートナに（たとえば、仕入業者デバイス１０４又は販売業者デバイス１０６に）、インジケーションを提供することができる。クライアントアプリケーション１１２及び予約プラットフォーム１１０は、ユーザが（たとえば、終日の予約から一晩の予約へ）予約を延長することを、さらに可能にすることができる。ユーザアカウントに関連付けられたクレジット残高は、それに応じて減額される場合もあり、又は他の例では、ユーザは、本明細書で説明されているように、追加のクレジットを購入することができる。

[0056]いくつかの例では、ユーザアカウントのクレジット残高を減額させることは、本明細書で説明されている態様に従って、ユーザアカウントのクレジット残高から、一意に識別可能なクレジットの特定のセットを適用することを含み得る。たとえば、ユーザは、適用する１つ又は複数のクレジットを示すインジケーションを提供し、示されたクレジットがそれに応じて適用されるようにすることができる。インジケーションの例は、（たとえば、申込、トライアルメンバシップ、ロイヤリティプログラム、イベントへの参加、又は別のユーザの紹介のためなど）特定のクレジットを示すインジケーション、まもなく期限切れになるクレジットを適用するためのインジケーション、又は特定のコンテキストで取得されたクレジットを適用するためのインジケーションを含むが、これらに限定されない。

[0057]そのような事例では、ユーザのアカウントに関連付けられたクレジットの少なくとも一部を提示するユーザインターフェースを表示して、ユーザが、提示されたクレジットの１つ又は複数を選択できるようにする。他の例では、ユーザが、期限切れに近づいている１つ又は複数のクレジットを有していることを示すユーザインターフェース要素を提示して、ユーザがユーザインターフェース要素を作動させて、そのようなクレジットが、ユーザアカウントに関連付けられた他のクレジットよりも先に適用されるべきであることを示すことができる。例示的なユーザインターフェースの態様及び関連する振舞いが開示されているが、他の様々なユーザ経験パラダイムのいずれかを使用できることが認識されるであろう。

[0058]他の例では、たとえば、様々な基準のいずれかを使用して１つ又は複数のクレジット属性を評価した結果として、１つ又は複数のクレジットを自動的に判定することができる。例として、クレジットは、先入れ先出し（ＦＩＦＯ）方法論に従って自動的に適用されており、ユーザのクレジット残高を減額させることは、１つ又は複数の最も古いクレジットを識別することを含んでいる。別の例として、クレジットは、関連付けられた値クレジット属性に従って判定され、最低又は最高のいずれかの値クレジット属性を有するクレジットが、ユーザのクレジット残高の他のクレジットの前に適用される。いくつかの事例では、手動選択と自動クレジット判定との組合せが使用される場合がある。したがって、本明細書で説明されている態様に従って適用するクレジットのセットを判定するために、様々な技法のいずれかを使用できることが認識されるであろう。

[0059]システム１００は、予約プラットフォーム１１０の在庫パートナによって使用され、予約プラットフォームを介して在庫を利用可能にし、関連する予約を別の方法で管理する、仕入業者デバイス１０４及び販売業者デバイス１０６をさらに備えている。例では、予約アプリケーション１１４及び在庫アプリケーション１１６は、予約プラットフォーム１１０の要求プロセッサ１１８と通信して、それぞれの各在庫パートナを介して利用可能な車両の在庫を管理する。たとえば、予約アプリケーション１１４及び在庫アプリケーション１１６は、（たとえば、予約プラットフォーム１１０とは無関係の予約、又は販売された在庫の結果として）もはや利用可能ではない在庫に関するインジケーションを提供することができる。それに加えて、予約アプリケーション１１４及び在庫アプリケーションは、予約プラットフォーム１１０を介して行われる予約のインジケーションを受信することができ、それにより、それぞれの各在庫パートナが、予約を履行できるようになる。たとえば、予約アプリケーション１１４は、その後、ガイド付き予約タイプを有する予約にガイドを割り当てることができるか、又は別の例として、在庫アプリケーション１１６は、配送予約タイプを有する予約に関連付けられた配送ロジスティクスを編成することができる。本明細書では例示的な在庫パートナのインタラクションが説明されているが、他の技法を使用することもできる。たとえば、予約を在庫パートナに自動的に割り当てるのではなく、在庫パートナは、スケジュールされた予約のリストにアクセスして、履行する１つ又は複数の予約を選択することができる。

[0060]いくつかの例では、予約アプリケーション１１４及び在庫アプリケーション１１６は、顧客デバイス１０２に伝達され、及び／又は監査目的で記憶され得る予約更新を提供することを可能にする。いくつかの例では、販売業者デバイス１０６は、モバイルデバイスであるか、そうでなければ配送ドライバのモバイルデバイスと通信し、以て、顧客デバイス１０２が、ユーザの車両配送予約の場所の実質的にリアルタイムのビューを提供できるようにする。予約アプリケーション１１４及び在庫アプリケーション１１６は、同様の機能を提供する必要はなく、代わりに、おのおのが上記の特徴のサブセットを提供するか、追加又は代替の特徴をさらに提供し得ることが認識されるであろう。それに加えて、予約アプリケーション１１４及び在庫アプリケーション１１６は、スタンドアロンアプリケーションである必要はない。むしろ、そのような機能は、他の例では、代わりに、他のソフトウェアに統合されてもよい。

[0061]図２は、本明細書で説明されている車両予約プラットフォームの態様を使用して車両予約が実行される例示的な地域２００の概要を示している。図示されているように、地域２００は、ユーザ場所２０２、都市２０４、サービスエリア２０６、在庫パートナ２０８、２１０及び２１２、並びにトレイルヘッド２１４、２１６、２１８及び２２０を含んでいる。いくつかの事例では、顧客アプリケーション（たとえば、図１における顧客デバイス１０２のクライアントアプリケーション１１２）は、地域２００のものと同様の表示を生成する。

[0062]例では、車両予約プラットフォーム（たとえば、図１における予約プラットフォーム１１０）は、ユーザが、サービスエリアで車両予約を行うことを可能にする。たとえば、サービスエリア２０６は、都市２０４から車で２時間かかることを表している。したがって、ユーザは、サービスエリア２０６における任意の場所のために車両配送予約を行うことができる。サービスエリア２０６は、都市２０４を中心とする円として示されているが、サービスエリアは、様々な制約のいずれかに従って、様々な形状のいずれかを採用できることが認識されるであろう。別の例として、それぞれの各在庫パートナは、関連するサービスエリアを有することができる。それに加えて、ユーザがユーザ場所２０２にいる間、ユーザは、サービスエリア２０６における予約に制限される必要がないことが認識されるであろう。むしろ、ユーザは、他の様々な場所及び関連するサービスエリアのいずれかで車両予約を行うことができる。たとえば、ユーザは、異なる州又は別の都市のサービスエリアにある車両の車両予約を行うことができる。

[0063]在庫パートナ２０８、２１０及び２１２は、種々の例のうちでも特に、販売業者及び／又は仕入業者であってもよい。在庫パートナ２０８、２１０及び２１２の車両は、本明細書で説明されている予約プラットフォームを介して予約可能である。たとえば、ユーザは、在庫パートナ２０８で受取予約を行い、ユーザは、車両予約の期間に車両を引き取るために、ユーザ場所２０２から在庫パートナ２０８まで車を運転する。別の例として、ユーザは、在庫パートナ２１０から配送予約を行うことができ、これにより、在庫パートナ２１０は、車両をユーザ場所２０２又はユーザが選択した別の場所に配送するためのインジケーションを受信する。

[0064]いくつかの事例では、ユーザは代わりに、トレイルヘッド２１４、２１６、２１８又は２２０を選択して、それに応じて車両をトレイルヘッドに配送するためのインジケーションを在庫パートナが受信できる。そのような事例では、予約プラットフォームは、選択されたトレイルヘッドに近く、予約を履行するために、要求された車両の在庫（そして、いくつかの事例では、利用可能なガイド）を有している在庫パートナを特定することができる。たとえば、在庫パートナ２１２は、車両をトレイルヘッド２１８に配送するために選択され、在庫パートナ２１０は、車両をトレイルヘッド２１４に配送するために選択され得る。いくつかの事例では、在庫パートナは（たとえば、トレイルヘッド２２０に対する在庫パートナ２１０、２１２のように）、トレイルヘッドまで等距離にある場合がある。そのような事例では、予約プラットフォームは、各在庫パートナの在庫を評価して、どの在庫パートナが最も多くの利用可能な在庫を有しているかを判定する場合がある。過去の又は予測された需要、並びに車両配送に関連付けられた推定運転時間など、様々な追加又は代替の要因のいずれかを評価できることが認識されるであろう。

[0065]いくつかの事例では、車両予約に関連付けられたクレジット費用が（たとえば、図１における価格設定エンジン１２４などの価格設定エンジンによって）動的に判定される。たとえば、在庫パートナ２１２はトレイルヘッド２２０よりもトレイルヘッド２１８に近いので、トレイルヘッド２１８への車両配送に関連付けられたクレジット費用は、トレイルヘッド２２０への車両配送に関連付けられたクレジット費用よりも少なくてもよい。別の例として、所与の日付におけるトレイルヘッド２２０への車両配送に関連付けられたクレジット費用は、利用可能な在庫が減少するにつれて増加する可能性がある。たとえば、（トレイルヘッド２２０に最も近い）在庫パートナ２１０、２１２には在庫が残っていない可能性があり、在庫パートナ２０８からの配送のクレジット費用は、トレイルヘッド２２０からの距離の結果として比較的より高くなる可能性がある。

[0066]図３Ａは、図１における顧客デバイス１０２などの顧客デバイスによる車両予約のための例示的な方法３００の概要を示している。方法３００の態様は、図１におけるクライアントアプリケーション１１２などのクライアントアプリケーションによって実行され得る。方法３００は動作３０２で開始し、利用可能な車両の表示が生成される。この表示は、種々の例のうちでも特に、ウェブサイト又はモバイルアプリケーションの一部である場合がある。車両は、本明細書で説明されている態様に従って静的又は動的に判定され得るように、それぞれの車両を予約するためのクレジット費用に関連して表示され得る。利用可能な車両は、図１における予約プラットフォーム１１０などの予約プラットフォームから受け取ることができる。

[0067]いくつかの事例では、利用可能な車両のセットは、顧客デバイスによる要求に応じて受け取られる。たとえば、要求は、ユーザ場所、フィルタ基準のセット（たとえば、車両タイプ、日付／時刻、乗客／貨物容量、及び／又は能力）、及び／又はユーザアカウントに関連付けられたセッション識別子を含むことができる。例では、利用可能な車両のサブセットのみが表示される。たとえば、利用可能な車両は、様々な基準のいずれかに従ってフィルタリングすることができる。他の例では、利用可能な車両は、顧客デバイスによって実行されるフィルタリングの代わりに、又はそれに加えて、予約プラットフォームによってフィルタリングされる。いくつかの事例では、利用可能な車両の表示は、図２における地域２００と同様であり、他の例では、表示は、地図の代替又は追加として、リストを含むことができる。リストは、種々の例のうちでも特に、クレジット費用、ユーザへの近さ、又は人気に従ってソートすることができる。

[0068]動作３０４において、利用可能な車両の選択が、ユーザから受信される。ユーザは、動作３０２で表示された車両の１つをクリック又はタップすることによって、車両を選択することができる。他の例では、音声入力又はソフトウェア又はハードウェアキーボードを使用するなど、他の様々なユーザ入力技法のいずれかを使用できることが認識されるであろう。いくつかの事例では、希望する配送場所、受取時間枠、又は予約の日数などの追加情報がユーザから要求される。ユーザのアカウントに権利放棄が関連付けられていない場合、又はユーザアカウントに関連付けられている権利放棄が、期限切れになっている場合である事例では、ユーザは、権利放棄を再実行するように求められる場合がある。動作３０４において、様々な追加又は代替の情報のいずれかをユーザから要求することができ、ユーザの車両選択に少なくとも部分的に基づくことができることが認識されるであろう。

[0069]フローは動作３０６に進み、選択された車両を示すインジケーションが、予約プラットフォームに提供される。たとえば、インジケーションは、車両の選択、予約に関連付けられた日付／時間、及び／又は動作３０４においてユーザから要求された追加情報を含んでいる。いくつかの事例では、種々の例のうちでも特に、ウェブサイトでフォームを発行したり、ＡＰＩを使用したりして、インジケーションが提供される。インジケーションは、選択された車両の一時的な予約を作成するために提供され、以て、別のユーザが、現在のユーザより前に車両予約プロセスを完了しないことを保証する。例では、予約プラットフォームは、予約を完了するのに十分なクレジットを、ユーザのアカウントが有していないことを示す場合がある。

[0070]例では、動作３０２で生成された表示は、本明細書で説明されている態様に従ってユーザによって（たとえば、動作３０４で）選択され得るような、１つ又は複数の一意に識別可能なクレジットを示すインジケーションをさらに含み得る。他の例では、ユーザが１つ又は複数のクレジットを選択できるようにするプロンプト、又は別の例として、まもなく期限切れになる１つ又は複数のクレジットを適用するためのインジケーションを提供するプロンプトを（たとえば、動作３０４において、受信された選択の結果として）生成することができる。したがって、動作３０６は、そのようなユーザ入力に関連付けられたインジケーション（たとえば、選択されたクレジットを示すインジケーション、又は他の例のうちでも、まもなく期限切れになる１つ又は複数のクレジットを適用するインジケーション）を提供することをさらに含み得る。そのような表示又はプロンプトは、たとえば、ユーザが期限切れに近い（たとえば、所定のしきい日数未満の）クレジットを有している場合に、選択的に提示され得る。他の例では、まもなく期限切れになるクレジットがないこと、又はユーザアカウントに関連付けられた各クレジットが、同じ又は類似のクレジット属性を有していることを判定して、そのようなインジケーションを提供する能力がユーザに与えられないようにすることができる。

[0071]したがって、判定３０８において、ユーザのアカウントが、選択された車両を予約するのに十分なクレジットを有するか否かが判定される。例では、判定は、追加のクレジットが必要であることを示し得る、動作３０６で提供されたインジケーションに対して受信された応答を評価することを含んでいる。他の例では、判定は、動作３０４で受信された車両選択を、（たとえば、予約プラットフォームから要求されるように、又は顧客デバイスにキャッシュされるように）ユーザアカウントと比較して評価することを含んでいる。

[0072]ユーザが十分なクレジットを有していないと判定された場合、フローは「いいえ」に分岐して動作３１０に進み、クレジットオプションの表示が生成される。表示は、ユーザアカウントに関連付けられたクレジット残高を補うための１つ又は複数のオプションを含むことができる。例では、表示は、予約プラットフォームから受け取ったクレジットオプションのセットに基づいている。例として、生成された表示は、ユーザアカウントに関連付けられたクレジットと、選択された車両のクレジット費用との間のクレジットの差額を購入するオプションを含んでいる。

[0073]判定３１２において、追加のクレジットを購入する選択が受信されたか否かが判定される。ユーザが、追加のクレジットを購入することを選択しなかったと判定された場合、フローは「いいえ」に分岐して動作３０２に進み、利用可能な車両の表示が再びユーザに提示され、以て、（たとえば、ユーザアカウントのクレジット残高と同じかそれ以下のクレジット費用を有する）異なる車両の選択が可能となる。しかしながら、ユーザが、追加のクレジットを購入することを選択したと判定された場合、フローは、代わりに「はい」に分岐して動作３１４に進み、購入選択を示すインジケーションが、予約プラットフォームに提供される。例では、インジケーションは、請求情報を含むことができ、他の例では、ユーザの請求情報が、ユーザアカウントに記憶される。したがって、予約プラットフォームは、トランザクションを処理し、フローは、以下に論じられている動作３１６に進む。

[0074]判定３０８に戻って、ユーザが十分なクレジットを有していると判定された場合、フローは代わりに「はい」に分岐し、判定３０８から動作３１６に移動し、確認された予約を示すインジケーションが受信される。例では、インジケーションは、確認番号、予約インジケーション（たとえば、受取指示、配送指示、ガイド付き／セルフガイド付きツアー指示）、利用可能性の推定（たとえば、推定配送時間、又は、その後車両が、受取のために利用可能になる推定受取時間）、及び／又はユーザアカウントに関連付けられた残りのクレジット残高を含んでいる。

[0075]フローは動作３１８に進み、確認された予約の表示が生成される。表示は、動作３１６で受信された様々な情報のいずれかを含み得る。たとえば、表示は、確認番号、予約指示の少なくとも一部、利用可能性の推定、及び／又は残りのクレジット残高を含むことができる。例では、表示は、（たとえば、在庫パートナの）受取場所、トレイルヘッドの場所、又は配送場所に関連付けられた地図をさらに含んでいる。動作３２０は、いくつかの事例では、方法３００が動作３１８で終了することを示すためにダッシュボックスを使用して示されている。

[0076]他の事例では、フローは動作３２０に進み、予約更新の表示が生成される。たとえば、予約プラットフォームは、種々の例のうちでも特に、動作３２０で生成された表示がそれに応じて予約の更新を反映するように、配送ドライバの場所に関するインジケーション、又は車両受取予約が受け取りの準備をできているというインジケーションを提供することができる。別の例として、更新された表示を生成する代わりに、又はそれに加えて、通知を生成することができる。動作３２０は何回でも実行できることが認識されるであろう。さらに、例示的なユーザインターフェース及びユーザ経験の態様が説明されているが、本開示の態様に従って、様々な同様の技法のいずれかを使用して、ユーザが予約を行い、追加のクレジットを購入し、車両予約プラットフォームの予約ステータスを閲覧することができる。フローは最終的に動作３２０で終了する。

[0077]図３Ｂは、車両予約プラットフォームによって車両予約を生成する例示的な方法３５０の概要を示している。例では、方法３５０の態様は、図１における予約プラットフォーム１１０などの予約プラットフォームによって実行される。方法３５０は動作３５２で開始し、利用可能な車両のセットが生成される。動作３５２の態様は、図１におけるスケジューリングエンジン１２０などのスケジューリングエンジンによって実行され得る。いくつかの事例では、顧客デバイス（たとえば、図１における顧客デバイス１０２）からの要求の一部として受信された情報に基づいて、利用可能な車両のセットが生成される。たとえば、要求は、ユーザ場所、フィルタ基準（たとえば、車両タイプ、日付／時間、乗客／貨物容量、及び／又は能力）のセット、及び／又はユーザアカウントに関連付けられたセッション識別子を含むことができる。生成された利用可能な車両のセットは、様々な基準のいずれかに従ってフィルタリングすることができる。他の例では、利用可能な車両は、予約プラットフォームによって実行されるフィルタリングの代わりに、又はそれに加えて、顧客デバイスによってフィルタリングされる。

[0078]フローは動作３５４に進み、利用可能な車両を示すインジケーションが、顧客デバイスに提供される。例では、インジケーションは、（たとえば、図１における価格設定エンジン１２４などの価格設定エンジンによって生成され得るような）利用可能な車両ごとのクレジット費用を含む。他の例では、インジケーションは、利用可能な車両のサブセットのみを含んでいる。たとえば、利用可能な車両のセットは、ウェブサイトの複数のページとして提供されてもよいし、（たとえば、図２における地域２００と同様に）地図のコンテキストで提供されてもよく、種々の例のうちでも特に、ユーザの場所に対する近さに少なくとも部分的に基づいてフィルタリングされてもよい。他の例では、生成された利用可能な車両のセットは、種々の技法のうちでも特に、ＡＰＩを介して提供される。

[0079]動作３５６において、車両選択を示すインジケーションが受信される。インジケーションは、図１における要求プロセッサ１１８などの要求プロセッサを介して受信され得る。例では、インジケーションは、顧客デバイスが図３Ａにおける方法３００の動作３０６の態様を実行した結果として受信される。インジケーションは、予約のために関連付けられた日付／時間、及び／又は、ユーザに関連付けられた追加情報をさらに含むことができる。いくつかの事例では、種々の例のうちでも特に、ウェブサイトで、又はＡＰＩを介して、フォームを発行した結果として、インジケーションが受信される。

[0080]上述したように、ユーザ入力は、本明細書で説明されている態様に従って、１つ又は複数の一意に識別可能なクレジットに関連して受信され得る。したがって、動作３５６で受信されるインジケーションは、そのようなユーザ入力を示すインジケーションをさらに含むことができる。同様に、以下で論じられている判定３５８は、車両予約に適用されるユーザアカウントに関連付けられたクレジットのセットを判定することを含むことができる。クレジットのセットは、本明細書で説明されている態様に従って、ユーザ入力に基づいて（たとえば、動作３５６で受信できるユーザ入力を示すインジケーションに基づいて）及び／又は自動的に、又はそれらの任意の組合せで判定することができる。

[0081]判定３５８では、動作３５６で示された車両の予約を行うのに十分なクレジットがユーザアカウントに関連付けられているか否かが判定される。例では、判定は、ユーザアカウントに関連付けられたクレジット残高と、（たとえば、図１における価格設定エンジン１２４などの価格設定エンジンによって生成され得るような）車両のクレジット費用とを比較することを含んでいる。

[0082]ユーザが十分なクレジットを有していないと判定された場合、フローは「いいえ」に分岐して動作３６０に進み、（たとえば、図３Ａにおける方法３００の動作３１０の態様を実行する顧客デバイスによって表示され得るように）追加のクレジットオプションを示すインジケーションが提供される。例として、追加のクレジットオプションは、ユーザのアカウントのクレジットと、選択された車両のクレジット費用との間のクレジットの差額を購入するオプションを含むことができる。いくつかの事例では、追加のオプションが提供される場合がある。

[0083]判定３６２において、ユーザが追加のクレジットを購入することを選択したか否かが判定される。ユーザが追加のクレジットを購入することを選択しなかったと判定された場合、フローは「いいえ」に分岐して動作３５２に進み、利用可能な車両のセットが生成される。いくつかの例では、フローは、代わりに「いいえ」に分岐して動作３５６に進み、車両選択を示す新しいインジケーションが受信される。たとえば、顧客デバイスは、フローが代わりに動作３５６に分岐するように、動作３５４において以前に提供された、利用可能な車両のセットをキャッシュすることができる。

[0084]いくつかの事例では、判定３６２は、（たとえば、図３Ａにおける方法３００の動作３１４の態様を実行する顧客デバイスによって提供されるような）購入選択を示すインジケーションを受信することを含んでいる。インジケーションは、請求情報を含むことができるか、又は、他の例では、請求情報は、（たとえば、図１におけるユーザデータストア１２８などのユーザデータストアによって記憶され得るように）ユーザアカウントからアクセスすることができる。したがって、フローは「はい」に分岐して動作３６４に進み、ユーザアカウントは、ユーザによって購入されたクレジットを反映するように更新される。例では、ユーザアカウントを更新することは、本明細書で説明されている態様に従って、ユーザアカウントに関連付けられた１つ又は複数の一意に識別可能なクレジットを生成することを含むことができる。いくつかの事例では、動作３６４の態様は、種々の例のうちでも特に、インジケーションの一部として受信された、又はユーザアカウントの一部として記憶された、支払情報に従って処理され得るように、クレジットの購入に関連付けられた支払いを処理することをさらに含んでいる。次に、フローは、以下で論じられている動作３６６に進む。

[0085]動作３５８に戻って、ユーザが十分なクレジットを有していると判定された場合、フローは代わりに「はい」に分岐して動作３６６に進み、予約が生成され、ユーザアカウントに関連付けられている。したがって、ユーザアカウントに関連付けられたクレジットの結果として、車両予約の支払いを処理する必要はない。実際、ユーザが十分なクレジットを有している例では、支払いをまったく処理する必要はない。それに加えて、追加のクレジットが購入される事例では、ユーザアカウントのクレジット残高は、クレジット購入に応じて増額され、その後減額されて、車両予約を完了することができる。したがって、前述したように、ユーザアカウントのクレジット残高は、申込メンバシップ（及び追加のクレジット購入）に関連付けられた金銭的費用と、車両予約プラットフォームを介して車両を予約するユーザの能力との間の仲介役として機能する場合がある。例では、ユーザアカウントを更新することは、（たとえば、手動で選択及び／又は自動的に判定されたような）一意に識別可能なクレジットのセットを適用することを含み、クレジットがユーザアカウントに関連付けられなくなったり、及び／又は、クレジットが適用されたことを示すように更新され、将来、使用できなくなる。動作３６６の態様は、図１におけるスケジューリングエンジン１２０などのスケジューリングエンジンによって実行され得る。たとえば、予約は、予約データストア（たとえば、図１における予約データストア１２６）で生成され、ユーザデータストア（たとえば、ユーザデータストア１２８）のユーザアカウントに関連付けられている。

[0086]フローは動作３６８に進み、確認された予約を示すインジケーションが顧客デバイスに提供される。インジケーションは、確認番号、予約指示（たとえば、受取指示、配送指示、ガイド付き／セルフガイド付きツアー指示）、利用可能性の推定（たとえば、配送予定時刻又は車両が受取のために利用可能になるまでの予定受取時間）、及び／又はユーザアカウントに関連付けられている残りのクレジット残高を含むことができる。いくつかの事例では、インジケーションは、図１における仕入業者デバイス１０４又は販売業者デバイス１０６などの仕入業者デバイス又は販売業者デバイスによって受信され得るように、在庫パートナ（たとえば、仕入業者又は販売業者）に提供される。このインジケーションにより、在庫パートナは、予約の履行に関連付けられたアクションを実行できるようになる場合がある。動作３７０及び動作３７２は、いくつかの例では、方法３５０が動作３６８で終了することを示すために破線のボックスを使用して示されている。

[0087]しかしながら、他の例では、フローは動作３７０に進み、（たとえば、動作３６８でインジケーションが提供された）在庫パートナから予約更新を示すインジケーションが受信される。たとえば、インジケーションは、配送予約（たとえば、配送ドライバの場所）に関連することができ、又は、種々の例のうちでも特に、車両受取予約が、受け取りの準備ができているというインジケーションを含むことができる。したがって、動作３７２で、予約更新を示すインジケーションが顧客デバイスに提供される。いくつかの事例では、動作３７２は、予約更新に基づいて予約データストアにおける予約を更新することをさらに含んでいる。動作３７０及び動作３７２は、在庫パートナから更新が受信されるごとに何度でも実行することができる。フローは最終的に動作３７２で終了する。

[0088]図４は、車両予約プラットフォームの在庫パートナによる予約を履行するための例示的な方法４００の概要を示している。例では、方法４００の態様は、図１における仕入業者デバイス１０４又は販売業者デバイス１０６のような、仕入業者デバイス又は販売業者デバイスによってそれぞれ実行され得る。方法４００は動作４０２で開始し、確認された予約を示すインジケーションが受信される。例では、インジケーションは、図１における予約プラットフォーム１１０などの予約プラットフォームから受信される。予約プラットフォームは、図３Ｂにおける方法３００の動作３６８の態様を実行している可能性がある。

[0089]フローは動作４０４に進み、確認された予約に基づいて在庫が割り当てられる。例では、動作４０４は、別個の予約及び／又は在庫システムと通信して、別個のシステムにおける車両を、確認された予約によって示される車両と関連付けることを含んでいる。他の例では、動作４０４は、予約が在庫パートナによって受諾されたというインジケーションを、車両予約プラットフォームに提供することを含むことができる。

[0090]方法４００は、予約タイプに応じて判定４０６で分岐する。予約が、配送予約である場合、フローは、「配送」に分岐して動作４０８に進み、在庫の配送がスケジュールされる。たとえば、配送車両（及び、いくつかの事例では、関連付けられたドライバ）を識別し、確認済みの予約に関連付けることができる。それに応じて、配送ドライバのモバイルデバイスにインジケーションを提供することができる。

[0091]フローは動作４１０に進み、配送更新が予約プラットフォームに提供される。例では、動作４１０を複数回実行することができ、以て、顧客は、車両予約に関連付けられた配送車両を追跡できるようになる。配送更新は、たとえば図３Ｂにおける方法３５０の動作３７０において、予約プラットフォームによって、予約更新として受信され得る。最終的に、フローは動作４１２に進み、配送完了を示すインジケーションが提供される。インジケーションは、（たとえば、動作３７０で）再び予約プラットフォームに提供されてもよい。フローは動作４１２で終了する。

[0092]他の例では、予約がガイド付き予約である場合、フローは代わりに、判定４０６から「ガイド付き」へ分岐して、動作４１４に進み、ガイドが予約に割り当てられる。ガイドは、種々の例のうちでも特に、利用可能なガイドのカレンダに基づいて、又は別の予約システムを介して割り当てることができる。フローは動作４１６に進み、スケジューリングインジケーションが（たとえば、テキストメッセージ、電子メールとして、又はスケジューリングポータルを介して）ガイドに提供される。例示的なスケジューリング技法が説明されているが、そのような機能を提供するために、他の様々な態様のいずれかを利用できることが認識されるであろう。たとえば、予約プラットフォームは、ガイドスケジューリング機能をさらに提供することができ、又は別の例として、動作４０８に関して上記で論じられた配送機能を提供することができる。フローは動作４１６で終了する。

[0093]最後に、判定４０６において、予約が受取予約である場合、フローは「受取」に分岐して動作４１８に進み、受取のために車両を準備するインジケーションが生成される。たとえば、インジケーションは、待ち行列又は他の注文追跡システムで生成され、以て、在庫パートナの個人がそれに応じて受取注文を履行できるようになる。最終的に、フローは動作４２０に進み、受取の利用可能性を示すインジケーションが、予約プラットフォームに提供される。たとえば、デバイス（たとえば、図１における仕入業者デバイス１０４又は販売業者デバイス１０６）は、それに従ってインジケーションを提供するために個人によって使用され得る。フローは動作４２０で終了する。

[0094]方法４００は、３つの注文タイプに関して示されているが、より少ない注文タイプ、追加の注文タイプ、又は代替の注文タイプを使用できることが認識されるであろう。それに加えて、方法４００に示されている３つの注文タイプすべてを実施する必要はない。たとえば、図１における仕入業者デバイス１０４の予約アプリケーション１１４は、動作４０２～４０６及び４１４～４２０を実施することができ、販売業者デバイス１０６の在庫アプリケーション１１６は、動作４０２～４１２を実施することができる。

[0095]図５Ａ～図５Ｃは、車両予約プラットフォームの例示的なユーザインターフェースの態様を示している。図５Ａ～図５Ｃは、同様の要素及び関連付けられた参照番号を含むため、後続の図に関して必ずしも詳細に再説明される訳ではない。図５Ａを参照して示すように、ユーザインターフェース５００は、在庫パートナ列５０２、提供タイプ列５０４、提供列５０６、クレジット費用列５０８、予約期間列５１０、及び距離列５１２を含んでいる。ユーザインターフェース５００は、顧客デバイスが図３Ａにおける方法３００の動作３０２の態様を実行した結果として生成されたものであってもよい。ユーザインターフェース５００にリストされた車両は、予約プラットフォームが図３Ｂにおける方法３５０の動作３５２の態様を実行した結果として判定されたものであり得る。

[0096]ユーザインターフェース５００は、提供タイプ列５０４（たとえば、「カスタム配送」、「カスタム受取」、及び「オントレイル仕入業者」）によって示されるように、予約タイプに従ってソートされる。予約タイプの例が開示されているが、他の例では、追加の、より少ない、又は代替のタイプを使用できることが認識されるであろう。在庫パートナ列５０２は、利用可能な車両に関連付けられた在庫パートナ（たとえば、図２における在庫パートナ２０８、２１０及び２１２）に関するインジケーションを含んでいる。提供列５０６は、車両タイプ（たとえば、「スポーツマン５７０」、「スリングショット」、「ＲＺＲ」、「ＳＬＧ」など）を示し、いくつかの例では、車両予約に関連付けられているトレイルヘッド（たとえば、図２におけるトレイルヘッド２１４、２１６、２１８及び２２０）を示している。クレジット列５０８は、車両予約に関連付けられたクレジット費用を示している。上記で論じられたように、クレジット列５０８は、図１における価格設定エンジン１２４などの価格設定エンジンによって判定され得るような、車両予約の静的クレジット費用及び／又は動的クレジット費用を含み得る。

[0097]予約期間列５１０は、車両予約に関連付けられた時間長さを示している。上記で論じられたように、ユーザは、車両が利用可能な日数に基づいて、利用可能な車両をフィルタリングすることができる。たとえば、ユーザインターフェース５００は、「終日」利用可能な車両のフィルタリングされたリストを表示することができる一方、他の車両は、種々の例のうちでも特に、数日又は半日利用可能であり得る。距離列５１２は、ユーザ（たとえば、図２における在庫パートナ２０８、２１０又は２１２、又はトレイルヘッド２１４、２１６、２１８又は２２０のうちの１つまでの距離と比較したユーザ場所２０２）からの距離を示す。ユーザがそのような予約タイプの場所を指定できるため、「カスタム配送」又は「カスタム受取」タイプの場合、距離は表示されない。

[0098]図５Ｂは、ポインタ５２２が車両予約５２６にホバリングしている例示的なユーザインターフェース５２０を示している。その結果、予約ボタン５２４が表示される。したがって、ユーザは、ポインタ５２２を使用して予約ボタン５２４をクリックし、図３Ａに関して上記で論じられた方法３００の態様を含む予約プロセスを開始することができる。例示的な態様は、ポインタ５２２の使用に関して説明されているが、タッチ入力又はキーボード入力などの代替入力方法が利用可能な場合に、たとえば、同様の技法を使用できることが認識されるであろう。他の例では、ユーザが、関連付けられた番号を使用して予約を識別できるように、図示されたリストに番号を付けることができる。別の例として、音声ユーザインターフェースを使用することができ、ユーザは、車両予約に関連付けられた（たとえば、「ハッピートレイルズが提供するオントレイルオプション」又は「ＲＳ１のカスタム受取予約」と言う）言葉に基づいて車両予約を選択することができる。

[0099]ユーザインターフェース５４０は、車両を予約するのに十分なクレジットをユーザが有していない例を示している。したがって、予約ボタン５２４を表示するのではなく、クレジット購入ボタン５４２が代わりに表示される。その結果、ユーザはボタンをクリックして、本明細書で説明されている態様に従って追加のクレジットを購入することができ、以て、ユーザは、追加のクレジットを購入した後に予約プロセスを完了することができる。図５Ｂと同様に、別の入力技法を使用することができる。たとえば、ユーザは「カスタムＲＳ１受取の追加クレジットを購入してください」と言うか、追加のクレジットを購入するオプションが提示される、オプションの関連メニューにアクセスするために、車両予約をタップ及びホールドすることができる。

[0100]したがって、例示的なユーザインターフェース及びユーザ経験技法が本明細書で説明されているが、本明細書で説明されている態様に従って、他の様々な技法のいずれかを使用できることが認識されるであろう。たとえば、ユーザインターフェース５００、５２０及び５４０は、車両のリストを有するものとして示されているが、他の例では、ユーザインターフェースは、図２における地域２００のものと同様の地図をさらに含み得ることが認識されるであろう。他の例では、ユーザインターフェースは、示された車両のリストの代わりに、そのような地図を含むことができる。

[0101]図６Ａは、ユーザアカウントに関連付けられたクレジットを生成するための例示的な方法６００の概要を示している。例では、方法６００の態様は、図１に関して上記で論じられた予約プラットフォーム１１０などの予約プラットフォームによって実行される。

[0102]方法６００は動作６０２で開始し、ユーザアカウントに関連付けられたクレジットを生成するためのインジケーションが受信される。例では、ユーザアカウントが申込に関連付けられている場合のように、所定期間が経過したときにインジケーションが受信される。別の例では、インジケーションは、種々の例のうちでも特に、ユーザから受信した支払情報を処理した結果として（たとえば、図３Ａ及び図３Ｂのそれぞれの動作３１４及び／又は動作３６４に関して上記で論じられた態様と同様に）、又はイベントへのユーザの出席の結果として受信され得る。方法６００の態様は、単一のクレジットを生成することに関して説明されているが、同様の技法を使用して複数のクレジットを生成できることが認識されるであろう。

[0103]動作６０４において、クレジット属性のセットが判定される。たとえば、クレジット属性のセットは、（たとえば、クレジットが生成されているコンテキストに関連付けられている）値、起点の日付及び／又は時間、何がクレジットの作成をもたらしたかを示すソース、及び／又は有効期限及び／又は時間を含むことができる。上記で論じられたように、値クレジット属性は、クレジットを取得するためにたとえば、種々の例のうちでも特に、申込、トライアルメンバシップ、ロイヤリティプログラム、イベントへの参加、又は別のユーザの紹介のように、（たとえば、ユーザによって）発生した費用を示すことができる。例示的なクレジット属性が説明されているが、他の例では、動作６０４において、他の様々なクレジット属性のいずれかが判定され得ることが認識されるであろう。

[0104]フローは動作６０６に進み、生成された属性のセットに基づいて、ユーザアカウントに関連してクレジットが生成される。たとえば、クレジットは、図１に関して上記で論じられたユーザデータストア１２８などのデータストアで生成され得る。クレジットは、ユーザアカウントの一部として記憶されてもよいし、又は別の例として、（たとえば、種々の例のうちでも特に、シリアル番号又は一意の識別子に従って）生成されたクレジットへの参照を含むようにユーザアカウントが更新されてもよい。例示的な生成及び記憶技法が説明されているが、たとえば、ユーザデバイスによる記憶のためにクレジット又はそれに関連付けられた情報を提供するなど、他の様々な技法のいずれかが使用され得ることが認識されるであろう。

[0105]動作６０８において、生成されたクレジットを示すインジケーションが提供される。たとえば、インジケーションは、種々の例のうちでも特に、シリアル番号又は一意の識別子、及び／又は、１つ又は複数のクレジット属性を含むことができる。いくつかの事例では、このインジケーションにより、（たとえば、予約を完了するのに十分なクレジットをユーザアカウントが有していない場合のように）予約プラットフォームによる処理が続行される場合があるか、又は、種々の例のうちでも特に、（たとえば、ユーザが追加のクレジットを取得する場合のように）顧客デバイスに提供することができる。方法６００は動作６０８で終了する。

[0106]図６Ｂは、本明細書で説明されている態様に従って、クレジットを適用するためのインジケーションを処理するための例示的な方法６５０の概要を示している。例では、方法６５０の態様は、図１に関して上記で論じられた予約プラットフォーム１１０などの予約プラットフォームによって実行される。

[0107]方法６５０は、動作６５２で開始し、クレジットを適用するためのインジケーションが受信される。たとえば、インジケーションは、図３Ａにおける方法３００の動作３０６～３１４に関して上記で論じられたように、ユーザによって選択された車両を示すインジケーションの結果として受信され得る。別の例として、インジケーションは、そのようなインジケーションを処理した結果として受信されてもよく、その例は、図３Ｂにおける方法３５０の動作３５６～３６６に関して上記で論じられた。例は、予約プラットフォームのコンテキストで論じられているが、同様の技法が、他の様々なコンテキストのいずれでも使用できることが理解されるであろう。

[0108]フローは動作６５４に進み、クレジットのセットが識別される。例では、動作６５４で識別されたクレジットのセットの少なくとも一部が、そのようなユーザ選択されたクレジットを含むように、１つ又は複数のクレジットのユーザ選択を示すインジケーションが動作６５２で受信される。他の例では、識別されたクレジットのセットの少なくとも一部が、たとえば有効期限及び／又は関連付けられた値クレジット属性に基づいて、自動的に判定される。別の例として、クレジットのセットは、たとえば期限切れに近づいているクレジットを適用するために、ユーザ選択を示すインジケーションに基づいて自動的に判定され得る。クレジットのセットを識別するための例示的な技法が説明されているが、追加又は代替の基準及び／又は処理が、他の例で使用され得ることが認識されるであろう。

[0109]動作６５６では、識別されたクレジットのセットについて判定基準が判定される。たとえば、実現判定基準は、識別されたクレジットのセットの各クレジットに関連付けられた値クレジット属性に従って生成され得る。他の例では、動作６５６は、識別されたクレジットのセットの各クレジットに関連付けられた追加又は代替のクレジット属性を処理することを含み、適用されるクレジットに関連して追加又は代替の判定基準を判定することができる。

[0110]動作６５８において、判定された判定基準を示すインジケーションが提供される。たとえば、インジケーションはデータストアに提供され、その後の評価のために（たとえば、種々の例のうちでも特に、顧客デバイスに関連付けられたユーザによって、又は予約プラットフォームに関連付けられたユーザによって）判定基準が記憶されてもよい。例では、インジケーションは、動作６５６で判定された判定基準に少なくとも部分的に基づいて生成されるレポートの一部として提供され得る。

[0111]動作６６０に移って、識別されたクレジットのセットが適用される。たとえば、クレジットのセットは、ユーザアカウントとの関連付けを解除することができ、一部の例では削除することができる。別の例として、クレジットのセットは、ユーザアカウントに関連付けられたままにすることができるが、各クレジットのクレジット属性を更新して、それが適用されたことを示すことができる。いくつかの事例では、クレジット属性が追加されて、クレジットが１つ又は複数のアイテム及び／又はサービスに適用されたことを示す場合がある。方法６５０は動作６６０で終了する。方法６５０は、（たとえば、動作６５６及び／又は動作６５８に関して上記で論じられた）そのような処理が、クレジットの適用の一部として発生する例で説明されているが、他の例では、クレジットが適用される前又は後に、同様の処理が実行され得ることが認識されるであろう。

[0112]図７は、特殊用途車両サービスをスケジュールするためのシステムを実施するためのコンピューティングシステム７００の図を示している。たとえば、（たとえば、要求プロセッサ１１８、スケジューリングエンジン１２０、在庫マネジャ１２２、価格設定エンジン１２４、予約データストア１２６、及びユーザデータストア１２８を含む）予約プラットフォーム１１０、顧客デバイス１０２、仕入業者デバイス１０４、及び／又は、販売業者デバイス１０６の機能の一部又はすべては、コンピューティングシステム７００と同様の構成要素を有するコンピューティングシステムによって実行され得る。この図は一例にすぎず、特許請求の範囲を不当に制限するものではない。当業者は、多くの変形、代替、及び修正を認識するであろう。

[0113]コンピューティングシステム７００は、プロセッサ７０４、ディスプレイ７０６、カーソル制御構成要素７０８、入力デバイス７１０、メインメモリ７１２、読取専用メモリ（ＲＯＭ）７１４、記憶ユニット７１６、及び／又はネットワークインターフェース７１８の間で情報を通信するためのバス７０２又は他の通信機構を含んでいる。いくつかの例では、バス７０２は、プロセッサ７０４、ディスプレイ７０６、カーソル制御構成要素７０８、入力デバイス７１０、メインメモリ７１２、読取専用メモリ（ＲＯＭ）７１４、記憶ユニット７１６、及び／又はネットワークインターフェース７１８に結合されている。そして、特定の例では、ネットワークインターフェース７１８は、ネットワーク７２０（たとえば、ネットワーク１０８）に結合されている。

[0114]いくつかの例では、プロセッサ７０４は、１つ又は複数の汎用マイクロプロセッサを含んでいる。いくつかの例では、メインメモリ７１２（たとえば、ランダムアクセスメモリ（ＲＡＭ）、キャッシュ、及び／又は他の動的記憶デバイス）は、プロセッサ７０４によって実行される情報及び命令を記憶するように構成される。特定の例では、メインメモリ７１２は、プロセッサ７０４によって実行される命令の実行中に一時変数又は他の中間情報を記憶するように構成される。たとえば、命令は、プロセッサ７０４にアクセス可能な記憶ユニット７１６に記憶されると、コンピューティングシステム７００を、命令で指定された動作を実行するようにカスタマイズされた専用マシン（たとえば、構成要素１１２～１２８）にする。いくつかの例では、ＲＯＭ７１４は、プロセッサ７０４のための静的情報及び命令を記憶するように構成される。特定の例では、記憶ユニット７１６（たとえば、磁気ディスク、光ディスク、又はフラッシュドライブ）は、情報及び命令を記憶するように構成される。

[0115]したがって、コンピューティングシステム７００は、少なくとも何らかの形態のコンピュータ可読媒体を含むことができる。コンピュータ可読媒体は、プロセッサ７０４又は他のデバイスによってアクセスできる任意の利用可能な媒体であってもよい。たとえば、コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を含み得る。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータなどの情報を記憶するための任意の方法又は技術で実施される揮発性及び不揮発性、取外し可能及び取外し不可能な媒体を含み得る。コンピュータ記憶媒体は、通信媒体を含まなくてもよい。

[0116]いくつかの実施形態では、ディスプレイ７０６（たとえば、陰極線管（ＣＲＴ）、ＬＣＤディスプレイ、又はタッチスクリーン）は、コンピューティングシステム７００のユーザに情報を表示するように構成される。いくつかの例では、入力デバイス７１０（たとえば、英数字及び他のキー）は、情報及びコマンドをプロセッサ７０４に通信するように構成される。たとえば、カーソル制御７０８（たとえば、マウス、トラックボール、又はカーソル方向キー）は、追加の情報及びコマンドを（たとえば、ディスプレイ７０６のカーソルの動きを制御するために）プロセッサ７０４に通信するように構成される。

[0117]以下の条項は、開示された主題の例示的な態様として提供される。

[0118]１．システムであって、少なくとも１つのプロセッサと、少なくとも１つのプロセッサによって実行されると、システムに動作のセットを実行させる命令を記憶しているメモリとを備え、動作のセットが、顧客デバイスから、特殊用途車両を予約するためのインジケーションを受信することであり、特殊用途車両が、クレジット費用に関連付けられている、受信することと、顧客デバイスに関連付けられたユーザアカウントのクレジット残高を判定することと、特殊用途車両に関連付けられたクレジット費用が、ユーザアカウントのクレジット残高を超えていない場合、特殊用途車両に関連付けられたクレジット費用に基づいて、ユーザアカウントのクレジット残高を更新することと、特殊用途車両の予約を生成することであり、予約はユーザアカウントに関連付けられている、生成することとを含んでいる。

[0119]２．条項１のシステムであって、動作のセットが、特殊用途車両に関連付けられたクレジット費用が、ユーザアカウントのクレジット残高を超えた場合、ユーザアカウントのクレジット残高が、特殊用途車両を予約するのに十分ではないことを示すインジケーションを提供することと、追加のクレジットを購入するためのインジケーションを受信することと、追加のクレジットをユーザアカウントに関連付けることと、特殊用途車両に関連付けられたクレジット費用に基づいて、ユーザアカウントのクレジット残高を更新することと、特殊用途車両の予約を生成することであり、予約が、ユーザアカウントに関連付けられている、生成することとをさらに含んでいる。

[0120]３．条項２のシステムであって、追加のクレジットをユーザアカウントに関連付けることが、追加のクレジットを購入するためのインジケーションに関連付けられたコンテキストに基づいて、追加のクレジットに関連付けられたクレジット属性のセットを判定することと、判定されたクレジット属性のセットと、識別子とを有する、追加のクレジットを生成することと、識別子に基づいて、生成されたクレジットをユーザアカウントに関連付けることとを含んでいる。

[0121]４．条項１～３のいずれかのシステムであって、特殊用途車両に関連付けられたクレジット費用が、特殊用途車両に関連付けられた車両タイプの過去の需要、車両タイプの予測される需要、過去の季節的な需要、予測される季節的な需要、過去の休日需要、予測される休日需要、特殊用途車両を予約するためのインジケーションに関連付けられている予約タイプ、又は、利用可能な特殊用途車両の近さのうちの１つ又は複数に少なくとも部分的に基づいて動的に判定される。

[0122]５．条項１～４のいずれかのシステムであって、動作のセットが、生成された予約を示すインジケーションを、特殊用途車両に関連付けられた在庫パートナに提供することをさらに含んでいる。

[0123]６．条項５のシステムであって、動作のセットが、在庫パートナから、予約更新を示すインジケーションを受信することと、予約更新を示すインジケーションを顧客デバイスに提供することとをさらに含んでいる。

[0124]７．条項５～６のいずれかのシステムであって、動作のセットが、特殊用途車両の在庫を有する在庫パートナのセットから在庫パートナを判定することをさらに含んでいる。

[0125]８．条項１～７のいずれかのシステムであって、ユーザアカウントが、所与の期間にわたり、所定数のクレジットを提供する申込階層に関連付けられており、動作のセットが、所与の期間よりも長い時間が経過したことを判定することに基づいて、所定数のクレジットだけユーザアカウントのクレジット残高を増やすことをさらに含んでいる。

[0126]９．条項８のシステムであって、ユーザアカウントのクレジット残高を増やすことが、申込階層に関連付けられたコンテキストに基づいて、所定数のクレジットのおのおのに関連付けられたクレジット属性のセットを判定することと、判定されたクレジット属性のセット及び関連付けられた識別子を有する所定数のクレジットの各クレジットを生成することと、識別子に基づいて、生成された各クレジットをユーザアカウントに関連付けることとを含む。

[0127]１０．条項１～９のいずれかのシステムであって、ユーザアカウントのクレジット残高を更新することが、ユーザアカウントのクレジット残高からクレジットのセットを判定することと、判定されたクレジットのセットを適用することとを含んでいる。

[0128]１１．条項１０のシステムであって、ユーザアカウントのクレジット残高を更新することが、判定されたクレジットのセットの各クレジットの値クレジット属性に基づいて合計値を生成することと、生成された合計値と、特殊用途車両の予約に関連付けられた費用とに基づいて実現判定基準を生成することと、生成された実現判定基準を示すインジケーションを提供すること、及び生成された実現判定基準を記憶することのうちの少なくとも１つとをさらに含んでいる。

[0129]１２．条項１０～１１のいずれかのシステムであって、クレジットのセットが、顧客デバイスから受信したユーザ選択を示すインジケーションに部分的に基づいて判定される。

[0130]１３．条項１０～１１のいずれかのシステムであって、クレジットのセットが、クレジットのセットのうちのクレジットのクレジット属性の評価に基づいて自動的に判定される。

[0131]１４．条項１０～１３のいずれかのシステムであって、判定されたクレジットのセットを適用することが、判定されたクレジットのセットの各クレジットのクレジット属性を更新して、クレジットが適用されたことを示すこと、又は、判定されたクレジットのセットの各クレジットを、ユーザアカウントから関連付け解除することを含んでいる。

[0132]１５．車両予約プラットフォームを介して特殊用途車両を予約するための方法であって、車両予約プラットフォームから特殊用途車両のセットを要求することと、車両予約プラットフォームから特殊用途車両のセットを受信することと、受信された特殊用途車両のセットの少なくとも一部に基づいて、特殊用途車両の表示を生成することであり、表示が、ユーザアカウントのクレジット残高をさらに含んでいる、生成することと、特殊用途車両の選択を受信することであり、選択された特殊用途車両が、クレジット費用に関連付けられている、受信することと、車両予約プラットフォームに、選択された特殊用途車両を予約するためのインジケーションを提供することと、車両予約プラットフォームから、ユーザアカウントの残りのクレジット残高と、選択された特殊用途車両の予約確認とを受信することとを含んでいる。

[0133]１６．条項１５の方法であって、選択された特殊用途車両を予約するためのインジケーションに応じて、選択された特殊用途車両を予約するのに十分なクレジットをユーザアカウントが有していないというインジケーションを受信することと、ユーザアカウントのクレジット残高を増やすためのクレジットオプションのセットの表示を生成することと、クレジットオプションのセットからのクレジットオプションの選択を受信することと、選択されたクレジットオプションを示すインジケーションを、車両予約プラットフォームに提供することとをさらに含んでいる。

[0134]１７．条項１５～１６のいずれかの方法であって、車両予約プラットフォームに、選択された特殊用途車両を予約するためのインジケーションを提供する前に、特殊用途車両に関連付けられたクレジット費用が、ユーザアカウントのクレジット残高を超えていると判定することと、ユーザアカウントのクレジット残高を増やすためのクレジットオプションのセットの表示を生成することと、クレジットオプションのセットからのクレジットオプションの選択を受信することと、選択されたクレジットオプションを示すインジケーションを、車両予約プラットフォームに提供することとをさらに含んでいる。

[0135]１８．条項１５～１７のいずれかの方法であって、車両予約プラットフォームから、選択された特殊用途車両の予約確認に関連付けられた予約更新を受信することと、予約更新に少なくとも部分的に基づく表示を生成することとをさらに含んでいる。

[0136]１９．条項１８の方法であって、予約更新に基づく生成された表示が、配送車両の場所を示す地図を含んでいる。

[0137]２０．条項１５～１９のいずれかの方法であって、受信された特殊用途車両の選択が、予約タイプの選択をさらに含んでおり、選択された特殊用途車両を予約するための、車両予約プラットフォームへのインジケーションが、選択された予約タイプをさらに示す。

[0138]２１．条項１５～２０のいずれかの方法であって、選択された特殊用途車両の予約を延長する選択を受信することと、車両予約プラットフォームに、選択された特殊用途車両の予約を延長するためのインジケーションを提供することと、車両予約プラットフォームから、ユーザアカウントの更新された残りのクレジット残高と、選択された特殊用途車両の延長された予約確認とを受信することとさらに含んでいる。

[0139]２２．条項１５～２１のいずれかの方法であって、表示が、ユーザアカウントのクレジット残高の少なくとも１つのクレジットに関連付けられた情報をさらに含んでおり、方法が、ユーザのクレジット残高に関連付けられたユーザ入力を受信することをさらに含んでおり、選択された特殊用途車両を予約するための、提供されたインジケーションが、受信されたユーザ入力を示すインジケーションをさらに含んでいる。

[0140]２３．条項２２の方法であって、ユーザ入力が、ユーザのクレジット残高の特定のクレジットの選択、及び有効期限が近づいているクレジットを適用するためのインジケーションのうちの少なくとも１つを含んでいる。

[0141]２４．在庫パートナによって、車両予約プラットフォームの車両予約を処理するための方法であって、車両予約プラットフォームから、特殊用途車両の予約を示すインジケーションを受信することであり、特殊用途車両が、在庫パートナに関連付けられており、予約が、日付及び時間を示している、受信することと、在庫パートナの在庫を更新して、予約の日付及び時間に特殊用途車両が利用できないことを示すことと、車両予約プラットフォームに、特殊用途車両の予約が履行されたことを示す予約更新を提供することとを含んでいる。

[0142]２５．条項２４の方法であって、予約更新が、顧客が特殊用途車両を受け取ったこと、特殊用途車両が顧客に配送されたこと、ガイドが顧客に会い、特殊用途車両を用いたツアーを開始したことのうちの１つを示す。

[0143]２６．条項２４～２５のいずれかの方法であって、予約が、配送予約であり、方法が、特殊用途車両の配送に関連付けられた配送ドライバのデバイスから、デバイスの場所を受信することと、車両予約プラットフォームに、デバイスの場所を示すインジケーションを提供することとをさらに含んでいる。

[0144]２７．条項２６の方法であって、車両予約プラットフォームに、特殊用途車両の推定配送時間を含む予約更新を提供することをさらに含んでいる。

[0145]２８．条項２４～２７のいずれかの方法であって、車両予約プラットフォームに、特殊用途車両の推定受取時間を含む予約更新を提供することをさらに含んでいる。

[0146]２９．条項２４～２７のいずれかの方法であって、車両予約プラットフォームに、予約によって示された日付以降に特殊用途車両を予約できないことを示すインジケーションを提供することをさらに含んでいる。

[0147]３０．ユーザに関連付けられたユーザアカウントを維持するための方法であって、ユーザアカウントのクレジット残高に関するクレジットを生成するとの判定に基づいて、クレジットに関連付けられたクレジット属性のセットを生成することと、判定されたクレジット属性のセットと、識別子とを有するクレジットを生成することと、識別子に基づいて、生成されたクレジットをユーザアカウントに関連付けることと、ユーザアカウントのクレジット残高を適用するためのインジケーションを受信することと、ユーザアカウントのクレジット残高を適用するためのインジケーションに応じて、ユーザアカウントのクレジット残高から、クレジットのセットを判定することと、判定されたクレジットのセットを適用することとを含んでいる。

[0148]３１．条項３０の方法であって、所定時間長さが経過した後、クレジットを生成すると判定される。

[0149]３２．条項３０の方法であって、ユーザアカウントに関連付けられたユーザインタラクションの結果として、クレジットを生成すると判定される。

[0150]３３．条項３０～３２のいずれかの方法であって、判定されたクレジットのセットを適用することが、判定されたクレジットのセットの各クレジットのクレジット属性を更新して、クレジットが適用されたことを示すこと、又は、判定されたクレジットのセットの各クレジットを、ユーザアカウントから関連付け解除することを含んでいる。

[0151]３４．条項３０～３３のいずれかの方法であって、ユーザアカウントのクレジット残高を適用するためのインジケーションに応じて、判定されたクレジットのセットの各クレジットの値クレジット属性に基づいて合計値を生成することと、生成された合計値と、クレジット残高を適用するためのインジケーションに関連付けられた費用とに基づいて、実現判定基準を生成することと、生成された実現判定基準を示すインジケーションを提供すること、及び、生成された実現判定基準を記憶することのうちの少なくとも１つとをさらに含んでいる。

[0152]３５．条項３０～３４のいずれかの方法であって、クレジットのセットが、ユーザアカウントのクレジット残高を適用するための受信されたインジケーションに部分的に基づいて判定される。

[0153]３６．条項３０～３５のいずれかの方法であって、クレジットのセットが、クレジット残高の１つ又は複数のクレジットのクレジット属性の評価に基づいて自動的に判定される。

[0154]本開示の態様は、たとえば、本開示の態様による方法、システム、及びコンピュータプログラム製品のブロック図及び／又は動作図を参照して上記で説明された。ブロックで述べられている機能／動作は、フローチャートに示されている順序とは異なる場合がある。たとえば、関連する機能／動作に応じて、連続して示される２つのブロックが、実際には、実質的に同時に実行されるか、又は、ブロックが、逆の順序で実行される場合がある。

[0155]本出願で提供される１つ又は複数の態様の説明及び図解は、いずれにせよ特許請求される開示の範囲を限定又は制限することを意図するものではない。本願で提供される態様、例、及び詳細は、所有権を伝えるとともに、主張された開示の最良のモードを他人が作成及び使用できるようにするのに十分であると見なされる。特許請求された開示は、本願で提供されるいかなる態様、例、又は詳細にも限定されると解釈されるべきではない。組み合わされて、又は、個別に示され説明されるかに関係なく、様々な特徴は（構造的及び方法論的の両方とも）、特定の特徴のセットを備えた実施形態を生成するために選択的に含まれるか、又は省略されるように意図されている。本願の説明及び図解が提供されたので、当業者は、特許請求された開示のより広い範囲から逸脱しない、本願で具現化された一般的な発明概念の、より広い態様の精神に含まれる変形、修正、及び代替の態様を想定することができる。

Claims (36)

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. ユーザに関連付けられたユーザアカウントを維持するための方法であって、
    前記ユーザアカウントのクレジット残高に関するクレジットを生成するとの判定に基づいて、
    前記クレジットに関連付けられたクレジット属性のセットを生成するステップと、
    判定された前記クレジット属性のセットと、識別子とを有する前記クレジットを生成するステップと、
    前記識別子に基づいて、前記生成されたクレジットを前記ユーザアカウントに関連付けるステップと、及び、
    前記ユーザアカウントの前記クレジット残高を適用するためのインジケーションを受信するステップと、並びに、
    前記ユーザアカウントの前記クレジット残高を適用するための前記インジケーションに応じて、
    前記ユーザアカウントの前記クレジット残高から、クレジットのセットを判定するステップと、及び、
    前記判定されたクレジットのセットを適用するステップと、を含む、方法。
31. 所定時間長さが経過した後、前記クレジットを生成すると判定される、請求項３０に記載の方法。
32. 前記ユーザアカウントに関連付けられたユーザインタラクションの結果として、前記クレジットを生成すると判定される、請求項３０に記載の方法。
33. 前記判定されたクレジットのセットを適用するステップが、
    前記判定されたクレジットのセットの各クレジットのクレジット属性を更新して、前記クレジットが適用されたことを示すステップ、又は
    前記判定されたクレジットのセットの各クレジットを、前記ユーザアカウントから関連付け解除するステップを含む、請求項３０～３２のいずれか一項に記載の方法。
34. 前記ユーザアカウントの前記クレジット残高を適用するための前記インジケーションに応じて、
    前記判定されたクレジットのセットの各クレジットの値クレジット属性に基づいて合計値を生成するステップと、
    前記生成された合計値と、前記クレジット残高を適用するための前記インジケーションに関連付けられた費用とに基づいて、実現判定基準を生成するステップと、
    前記生成された実現判定基準を示すインジケーションを提供するステップ、及び、前記生成された実現判定基準を記憶するステップのうちの少なくとも１つと、
    をさらに含む、請求項３０～３３のいずれか一項に記載の方法。
35. 前記クレジットのセットが、前記ユーザアカウントの前記クレジット残高を適用するための前記受信されたインジケーションに部分的に基づいて判定される、請求項３０～３４のいずれか一項に記載の方法。
36. 前記クレジットのセットが、前記クレジット残高の１つ又は複数のクレジットに対するクレジット属性の評価に基づいて自動的に判定される、請求項３０～３５のいずれか一項に記載の方法。

Images