JP2021177379A - 限られたリソースを適応的に最適化する方法及び装置 - Google Patents

Abstract

【課題】第１のユーザ及び第２のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化する方法及び装置を提供する。【解決手段】方法は、第１のユーザから、限られたリソースの第１の選択であって、第１のユーザが限られたリソースをどのように使用したいかを示す第１の選択を受け取り、第１の選択と、第２のユーザからの第２の選択であって、第２のユーザが限られたリソースをどのように使用したいかを示す第２の選択とを比較し、第１の選択と第２の選択との比較に基づいて、限られたリソースのおすすめの選択であって、限られたリソースがどのように最もよく利用されるかを示すおすすめの選択を決定する。【選択図】図３

Description

本発明は、限られたリソースを適応的に最適化する方法に関するが、これに限定されるものではない。

レコメンドシステム（recommender systems）は、複数のユーザにリソースを選択するための「適切な」おすすめ（recommendation）を提供する機械学習アルゴリズムの重要なクラスである。このようなおすすめでは、リソースがその関連性に従ってランク付けされ、最も関連性の高いリソースが選択肢として複数のユーザのそれぞれに示される。おすすめのアプローチは、一般に、協調フィルタリング（collaborative filtering）のシステムとコンテンツベース（content-based）のシステムの２つの主なカテゴリに分けられる。近年、２つ以上のおすすめの戦略を組み合わせ、それらの利点を強化し、それらの欠点又は制限を低減することを目的とするハイブリッドレコメンドシステムがますます一般的になっている。

現在、機械学習技術は、YouTube（登録商標）、Netflix（登録商標）、Amazon（登録商標）等のビジネスに広く適用されているが、おすすめの技術及び処理は、例えば、飛行機のチケット、客室、パフォーマンスシート、ＥＶ充電ポイントを予約する場合等、限定されたリソース（bounded resource）として知られる限られたリソース（limited resource）、又はリソースにおける他の制約及び制限が存在する現実世界の状況において利用される場合には、それほど有効かつ効率的ではない。リソース不足は、複数のユーザの選択の間の競争及び競合を生じさせるが、多くのレコメンドシステムは、このような状況を扱うように設計されていない。

その結果、レコメンドシステムはユーザエクスペリエンスを低下させる。ユーザに、アイテムを見逃さないために、不必要な不安やプレッシャーをかける。また、先着順（First Come First Serve）のアプローチにより、おすすめされる限られたリソースを選択しようとすると、頻繁にエラーが発生する場合がある。一方、サービス・プロバイダ（service providers）は、予約／仮予約を取り込むことができる。しかし、これは、限られたリソースの利用を最適化したり、収益を最大化したりする際に、機会費用（opportunity cost）の発生をもたらす可能性がある。

したがって、上記の問題の１つ又は複数に対処する、限られたリソースを適応的に最適化する方法を提供する必要性が存在する。

さらに、他の望ましい特徴及び性質は、添付の図面及びこの開示の背景に関連して、以下の詳細な説明及び添付の特許請求の範囲から明らかになるであろう。

第１の態様において、本開示は、第１のユーザ及び第２のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化する方法を提供し、この方法は、第１のユーザから、限られたリソースの第１の選択であって、第１のユーザが限られたリソースをどのように使用したいかを示す第１の選択を受け取り；第１の選択と、第２のユーザからの第２の選択であって、第２のユーザが限られたリソースをどのように使用したいかを示す第２の選択とを比較して；第１の選択と第２の選択との比較に基づいて、限られたリソースのおすすめの選択であって、限られたリソースがどのように最もよく利用されるかを示すおすすめの選択を決定する。

第２の態様において、本開示は、第１のユーザ及び第２のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化するための装置を提供し、この装置は、少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリとを備え；少なくとも１つのプロセッサを用いて、少なくとも１つのメモリとコンピュータ・プログラム・コードとは、装置に、第１のユーザから、限られたリソースの第１の選択であって、第１のユーザが限られたリソースをどのように使用したいかを示す第１の選択を受け取ること；第１の選択と、第２のユーザからの第２の選択であって、第２のユーザが限られたリソースをどのように使用したいかを示す第２の選択とを比較すること；第１の選択と第２の選択との比較に基づいて、限られたリソースのおすすめの選択であって、限られたリソースがどのように最もよく利用されるかを示すおすすめの選択を決定すること；を実行させる。

本発明の実施の形態は、以下の書面による説明から、実施の形態のみにより、及び図面とともに、当業者にはさらに理解され、容易に明らかになるであろう。
図１（Ａ）は、１つの実施の形態に係る、限られたリソースがどのように利用され得るかを示す概略図を示し、図１（Ｂ）及び図１（Ｃ）は、それぞれ、１つの実施の形態に係る２つのタイプの顧客から、図１（Ａ）に示される限られたリソースの選択を示す概略図を示す。 図２は、限られたリソースを利用する、関連するレコメンドシステムのプロセスを示すフローチャートである。 図３は、１つの実施の形態に係る、限られたリソースを適応的に最適化するためのシステムを示す。 図４は、１つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。 図５は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートである。 図６は、さらに別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。 図７（Ａ）〜７（Ｄ）は、限られたリソースを適応的に最適化するためのユーザ・インターフェースの例を示す。 図８（Ｅ）〜８（Ｇ）は、限られたリソースを適応的に最適化するためのユーザ・インターフェースの例を示す。 図９（Ｈ）〜９（Ｉ）は、限られたリソースを適応的に最適化するためのユーザ・インターフェースの例を示す。 図１０（Ａ）及び１０（Ｂ）は、１つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。 図１１（Ａ）及び１１（Ｂ）は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。 図１２は、図３に示されるシステムを実施するための使用に適したコンピュータシステムの概略図を示す。

以下、本発明の実施の形態について図面を参照して説明する。図面中の同じ符号及び文字は、同じ要素又は等価物を指す。

以下の説明のいくつかの部分は、コンピュータメモリ内のデータに対する演算のアルゴリズム及び機能的又は記号的表現に関して明示的又は暗示的に提示される。これらのアルゴリズム記述及び機能的又は記号的表現は、データ処理技術の当業者が、その仕事の内容を当業者に最も効果的に伝えるために使用する手段である。アルゴリズムは、ここでは、一般に、所望の結果を導く自己無撞着なステップのシーケンスであると考えられる。ステップは、記憶、転送、結合、比較、及び他の方法で操作することができる電気、磁気、又は光学信号等の物理量の物理的操作を必要とするものである。

特に明記しない限り、また以下から明らかなように、本明細書において、「受け取る」、「計算する」、「決定する」、「更新する」、「生成する」、「初期化する」、「出力する」、「受信する」、「検索する」、「識別する」、「分散する」、「認証する」等の用語を使用する議論は、コンピュータシステム内の物理量として表されるデータを、コンピュータシステム内の物理量として表される他のデータを、他の情報記憶装置、送信装置、又は表示装置内の物理量として表される他のデータに操作及び変換する、コンピュータシステム又は類似の電子装置の動作及びプロセスを指すことが理解されるであろう。

本明細書では、これらの方法の動作を実行するための装置も開示する。このような装置は、必要な目的のために特別に構成されてもよく、又はコンピュータに記憶されたコンピュータプログラムによって選択的に起動又は再構成されるコンピュータ又は他の装置を含んでもよい。本明細書に提示されるアルゴリズム及びディスプレイは、いかなる特定のコンピュータ又は他の装置にも本質的に関連しない。様々な機械を、本明細書の教示によるプログラムと共に使用することができる。あるいは、必要な方法ステップを実行するためのより特殊化された装置の構成が適切であり得る。コンピュータの構造は、以下の説明から明らかになる。

さらに、本明細書は、本明細書に記載された方法の個々のステップがコンピュータコードによって実行されてもよいことが当業者には明らかであろうという点で、コンピュータプログラムも暗に開示している。コンピュータプログラムは、特定のプログラミング言語及びその実装に限定されるものではない。種々のプログラミング言語及びそのコーディングを用いて、本明細書に含まれる開示の教示を実施することができることが理解されよう。また、コンピュータプログラムは、特定の制御フローに限定されるものではない。本発明の精神又は範囲から逸脱することなく異なる制御フローを使用することができるコンピュータプログラムの多くの他の変形がある。

さらに、コンピュータプログラムのステップのうちの１つ以上は、順次にではなく並列に実行されてもよい。このようなコンピュータプログラムは、任意のコンピュータ可読媒体に格納することができる。コンピュータ可読媒体は、磁気又は光ディスク、メモリチップ、又はコンピュータとインターフェースするのに適した他の記憶装置等の記憶装置を含むことができる。コンピュータ可読媒体はまた、インターネットシステムに例示されるようなハードワイヤード媒体、又はＧＳＭ移動電話システムに例示されるようなワイヤレス媒体を含むことができる。このようなコンピュータ上にロードされて実行されるコンピュータプログラムは、好ましい方法のステップを実行する装置を効果的にもたらす。

本発明の様々な実施の形態は、限られたリソースを適応的に最適化する方法及び装置に関する。以下の様々な実施の形態では、用語「リソース（resource）」は、用語「アイテム（item）」を参照するか、又は用語「アイテム」と交換可能に使用することができる。「限られた（limited）」という用語は、「限定された（bounded）」という用語と同じ意味で参照又は使用することができ、「ユーザ」という用語は、「顧客（customer）」、「消費者（consumer）」、又は「買い手（buyer）」という用語と同じ意味で参照又は使用することができる。図１（Ａ）は、１つの実施の形態に係る、限られたリソースがどのように利用され得るかを示す概略図を示す。単純化のために、限られたリソースとは、５つのスロット、すなわちスロット１００ａ、スロット１００ｂ、スロット１００ｃ、スロット１００ｄ及びスロット１００ｅの利用可能な容量を指す。このような５つのスロットは、例えば、午後５時に出発するシャトルバスサービスのための５つの座席、共通の部屋のための５つの予約時間スロット等、時間、空間及び／又は量の制約を有するオブジェクト又はアイテムであり得る。慣例的に、協調的で個別化されたアクティビティ（personalized activity）のレコメンド方法及びレコメンドシステムは、位置（location）、時間、グループ、好み（preference）及びユーザが選択したアイテムリストに基づいて、おすすめのアイテムを提供する。限定されたアイテム（例えば、航空券、客室、パフォーマンスシート、ＥＶ充電ポイント）をおすすめする際に使用されるこのような関連する方法又はシステムは、先着順のアプローチにより、アイテム（例えば、ユーザによる取得、在庫切れ）を見落としてしまうという不安や虞を引き起こす可能性がある。一方、例えば、サービス・プロバイダがユーザのために予約や仮予約を取り込む一方、ユーザが最終的な選択を先延ばしにする可能性があり、限定されたアイテムを提供するサービス・プロバイダは、利用率及び転換率が低くなる可能性がある。しかし、アクションを促すために、「見落としの虞（ＦＯＭＯ；Fear of Missing Out）」を取り込むことは、非倫理的であると考えられる。

図１（Ｂ）は、１つの実施の形態に係る２つのタイプの顧客からの、図１（Ａ）に示される限られたリソース１００ａ〜１００ｅの選択を示す概略図を示す。この実施の形態では、限られたリソースの選択、すなわち、サービス・プロバイダ（劇場経営者）によって提供されるスロット１００ａ〜１００ｅ（例えば、映画の上映会のために一度に５枚のチケット）は、２つのタイプの顧客、すなわち、信頼のある顧客及びリスクのある顧客によって受け取られる。１つの実施の形態では、信頼のある顧客は、サービス・プロバイダがアクセス可能なリストに登録されているか、サービス・プロバイダが知っているか、又はサービス・プロバイダが認識している選択パターンに基づいて登録されている顧客を参照することができ、リスクの高い顧客は、新規であるか、サービス・プロバイダが知らないか、又は限られたリソースを提供するサービス・プロバイダが認識していない顧客を参照することができる。アレンジメントでは、リスクのある顧客は選択を尊重していないかもしれない。この実施の形態では、リスクの高い顧客は、３つのスロット、例えばスロット１００ａ、１００ｂ及び１００ｃをリクエスト又は選択することができる。リスクのある顧客からのスロット１００ａ、１００ｂ及び１００ｃのこのようなリクエスト又は選択は、サービス・プロバイダによって受信され、サービス・プロバイダは、リスクのある顧客のために３つのスロット１００ａ、１００ｂ、１００ｃを一時的に予約することができる。その後、３つを超えるスロット（例えば、スロット１００ａ、１００ｂ、１００ｃ及び１００ｄ）をリクエスト又は選択しようとする信頼のある顧客は、スロット１００ａ、１００ｂ及び１００ｃがリスクのある顧客のために一時的に予約されているため、そのようなリクエスト又は選択を実行することができない。このような状況では、リスクの高い顧客がリクエストをキャンセルした場合、サービス・プロバイダは、信頼のある顧客にサービスを提供しないことによる機会費用を負担することになる。これは、限られたリソースの競合が存在する現実世界の状況において利用される関連するレコメンドシステムにおける機会費用リスクを示している。

図１（Ｃ）は、１つの実施の形態に係る、図１（Ａ）に示された限られたリソース１００ａ〜１００ｅの２つのタイプの顧客からの選択を示す概略図を示す。この実施の形態では、限られたリソース、すなわちサービス・プロバイダによって提供されるスロット１００ａ〜１００ｅ（例えば、特定の時間に出発するＡ市からＢ市への航空便の座席の５枚のチケット）の選択は、２つのタイプの顧客、すなわち融通の利く顧客（flexible customer）及び制約のある顧客（例えば、航空会社）によって受け取られる。１つの実施の形態では、融通の利く顧客は、限られたリソースの選択が、選択されたリソースの量が少ないために、又は顧客によって与えられた同意によって、比較的変更されやすい顧客を意味してもよい。制約のある顧客とは、限られたリソースの選択が、おそらく選択の大部分に起因し、又は、顧客の好み（例えば、同じフライトで旅行する、お互いの隣に座りたいカップルによって購入される２枚のチケット）に起因する、比較的変更しにくい顧客を意味してもよい。この実施の形態では、３人の融通の利く顧客が３つのスロット１００ａ、１００ｃ、１００ｅをそれぞれ予約することができる。３人の融通の利く顧客からのスロット１００ａ、１００ｂ、１００ｃのこのようなリクエスト又は選択は、サービス・プロバイダによって受信され、サービス・プロバイダは３人の融通の利く顧客のためにそれぞれ３つのスロット１００ａ、１００ｃ、１００ｅを予約することができる。次に、制約のある顧客は、互いに隣接する２つのスロット（例えば、１００ｄ、１００ｅ）をリクエスト又は選択することを望むかもしれないが、スロット１００ｅは３人の融通の利く顧客のうちの１人のためにすでに一時的に予約されている。このような状況では、サービス・プロバイダは、容量の割り当てを最適化することによって、両方のタイプのお客様にサービスを提供することによって使用率を最大化することができない。これは、限られたリソースの競合が存在する現実世界の状況において利用される関連するレコメンドシステムにおける非効率的利用リスクを示している。

図２は、限られたリソースを利用する関連するレコメンドシステムのプロセスを示すフローチャートである。本開示の様々な実施の形態によれば、リソースは、座席、客室、駐車場等の限定された（又は限られた）リソース２０２と、映画、音楽や記事等の限定されないリソース２０４とに分類することができる。慣例的に、ステップ２０６において、ユーザは、限定されたリソース２０２をリクエスト又は選択することができる。サービス・プロバイダは、このようなリクエスト又は選択をユーザから受け取り、リソースが利用可能であるか、予約されていないかをチェックすることができる。リソースが利用可能である場合、ステップ２０８ａにおいて、サービス・プロバイダは、ユーザからの限定されたリソース２０２の選択を確認することができる。リソースが利用可能でないか、又は予約されている場合、サービス・プロバイダは、ユーザからの限定されたリソース２０２の選択を拒否し、ステップ２０６に戻ることができる。一方、ステップ２１０において、サービス・プロバイダは、ユーザに限定されたリソース２０２の選択をおすすめし、その選択をユーザのために予約することができる。続いて、ステップ２１２ａにおいて、ユーザは、限定されたリソース２０２のおすすめされた選択を受け入れるか、又はステップ２１２ｂにおいて、おすすめされた選択を拒否することができる。このような関連するレコメンドシステムは、限定された（又は限られた）リソース２０２を適応的に最適化しないことに留意されたい。

本開示の様々な実施の形態によれば、「選択（pick）、入札（bid）、コミット（commit）」技術と同様のスマートショッピングカートが導入され実装されて、おすすめの選択を決定し、複数のユーザに対して限られたリソースを適応的に最適化する。様々な実施の形態において、複数のユーザに対して限られたリソースを適応的に最適化する方法は、選択プロセス（picking process）、入札プロセス（bidding process）、及びコミットプロセス（committing process）を含むことができる。ピッキングプロセスにより、ユーザは、限られたリソースの中から、ユーザが関心を示すおすすめアイテムを選択することができる。このようなプロセスを使用して、ユーザに対する後続の補完的及び関するアイテムのおすすめをさらに改善することができる。また、限られたリソースのアイテムを他のユーザが選択できるようにすることで、柔軟性を向上する。好ましくは、これは、予約を回避し、先着順のアプローチをとることができる。引き続いて、制約の変更（例えば、リソースが使用できなくなった）、競合（例えば、他のユーザも関心があり、同じアイテムを選択している）、又はより最適化された状況（例えば、より利用可能なリソース）が発生したときに、入札プロセスが開始されてもよい。入札プロセスの間、スマートな競合解決プロセスが、影響を受けるユーザ（例えば、ユーザと、同じアイテムに興味を持ち、選択した他のユーザ）の間で調整され、実行される。特に、入札プロセスでは、影響を受けるユーザに選択オプションが提示され、ユーザの選択、決定、及び好みに基づいてリソースをより有効に活用できるようになる。好ましくは、これは、ユーザ満足度を改善する可能性が高い、適応的かつ対話的なリソース最適化プロセスを提供する。引き続いて、ユーザが選択プロセスにおける選択又は入札プロセスにおける提案された選択をコミットすることができるコミットプロセスが実行されてもよい。その結果、発生する可能性のある競合を早期に緩和及び管理することで、成功率が向上し、影響を受けるユーザによる混乱（churn）又はカート放棄の可能性をコミットプロセス中に最小限に抑えることができる。好ましくは、これにより、リソース利用を適応的に最適化及び最大化し、従って、複数のユーザのユーザ満足度を改善する。

図３は、１つの実施の形態に係る、複数のユーザに対して限られたリソースを適応的に最適化するためのシステム３０４を示す。１つの実施例では、システムは、限られたリソースを適応的に最適化するように構成される限定されたハイブリッドレコメンドシステムとして説明されてもよい。システム３０４は、制約監視ユニット３０６、競合／非競合監視ユニット３０８、ハイブリッドレコメンド結合ユニット３１０、及び最適化ユニット３１２を備えてもよい。システム３０４は、限定されたリソースデータベース３０２に接続され、リソースデータベース３０２は、限られたリソースのリスト、それらの可用性（availability）、及びおすすめを提示するときにユーザに提供される情報を記憶する。また、システム３０４は、複数のユーザのそれぞれに対して、リソースデータベース又は限られたリソースのリストの４つのそれぞれのサブセットを記憶する４つの記憶モジュール、すなわち、限定されたおすすめリストモジュール３１４、選択リストモジュール３１６、入札リストモジュール３１８、及びコミットリストモジュール３２０にも接続される。このようなリストモジュールは、例えば、限られたリソースが現在利用可能であるか、選択（ステージング（staged））されているか、入札されているか（割り当てられているか）、又はコミットされている場合に、システム３０４が限られたリソースの状態を追跡し更新するのに有用である。

様々な実施の形態では、限定されたおすすめリストモジュール３１４は、各ユーザにおすすめされた、又は各ユーザに個別化された（personalized）、限られたリソースのリストを格納することができる。このような限定されたおすすめリストモジュール３１４は、協調フィルタとコンテンツベースのアルゴリズムの組み合わせ、又は任意の他のレコメンドアルゴリズムを使用して、ハイブリッドレコメンド結合ユニット３１０によって生成することができる。おすすめの限られたリソースのリストは、（ａ）限られたリソースデータベース３０２から得られた限られたリソースの人気、利用可能性、及び／又は量、（ｂ）時間情報及び位置情報等の現在のトランザクションの詳細、（ｃ）ユーザの行動（behavior）、示された好み（indicated preference）、サービス・プロバイダ（例えば、サービスの権威のあるメンバー（prestigious member））との関係、及び／又は限られたリソースに関するトランザクションの履歴情報等のユーザのプロファイル情報等、限られたリソースの利用に関する少なくとも１つのパラメータに基づくことができる。１つの実施の形態に係ると、システム３０４は、ユーザにおすすめされる限られたリソースの個別化されたリスト（personalized list）と、限られたリソースの利用に関する関連パラメータ（限られた時間、量、地域（area）等の制約）とを生成する。このようなパラメータは、制約監視ユニット３０６によって検索されてもよい。別の実施の形態では、システム３０４は、ユーザが利用可能なすべての限られたリソースを含む限られたリソースのリストを生成する。さらに別の実施の形態では、システム３０４は、限られたリソースの同じリストを生成し、特定のタイプのユーザ又はすべてのユーザに送信する。以下の実施の形態では、説明を簡単にするために、第１のユーザと第２のユーザの２人のユーザを含むものとする。このようなシステムは、２人を超えるユーザを含む複数のユーザに適用することができることは明らかである。

１つの実施の形態では、第１のユーザは、限定されたおすすめリストモジュール３１４からおすすめされた限られたリソースの個別化されたリスト（以下、「個別化リスト」と称する）にアクセスし、個別化リストから限られたリソースの少なくとも１つを選択（以下、「第１の選択」と称する）することができ、そのような選択は、第１のユーザが限られたリソースをどのように使用したいかを示す。１つの実施の形態では、特定の制約（例えば、限られた時間、量又は位置）が、おすすめの限られたリソースの個別化リストに付与されてもよく、第１のユーザは、制約の範囲内で自分の選択を行うように提案されてもよい。システムは、限られたリソースの第１の選択を第１のユーザから受け取ることができる。１つの実施の形態では、システム３０４は、第１の選択があったことを通知する通知を受信することができる。１つの実施の形態では、第１のユーザから第１の選択を受信すると、第１の選択が選択リストモジュール３１６にステージングされる。

次に、第２のユーザは、限定されたおすすめリストモジュール３１４からおすすめされた限られたリソースの個別化リストにアクセスし、個別化リストから限られたリソースの少なくとも１つの選択（以下、「第２の選択」と称する）を行うことができ、そのような選択は、第２のユーザが限られたリソースをどのように使用したいかを示す。１つの実施の形態では、特定の制約（例えば、限られた時間、量又は位置）が、おすすめの限られたリソースの個別化リストに付与されてもよく、第２のユーザは、制約の範囲内で自分の選択を行うように提案されてもよい。システムは、限られたリソースの第２の選択を第２のユーザから受け取ることができる。１つの実施の形態では、システム３０４は、第２の選択があったことを通知する通知を受信することができる。

１つの実施の形態では、第２のユーザから第２の選択を受信すると、システム３０４によって、例えば、システム３０４の制約監視ユニット３０６、競合／非競合監視ユニット３０８、及び最適化ユニット３１２等によって、第１の選択と第２の選択とが比較され、制約違反（例えば、第１のユーザがリソースを選択する際に時間制限を超えた、等）、競合（例えば、限られたリソースのいずれかが２つ以上の選択に存在する、等）、及び／又は、追加の最適化（例えば、利用可能な、より優れた、より安価なリソース、等）の可能性があるかどうかが判断される。様々な実施の形態において、システム３０４は、任意の状況のそのような比較及び判断のために、数量、時間情報、及び位置情報等の限られたリソースに関する１つ以上のパラメータ（制約）を検索してもよい。

様々な実施の形態では、競合のような状況が決定された場合、システム３０４は、その状況が解決された場合に限られたリソースが最もよく利用されることを示すおすすめの選択を決定する。そのようなおすすめの選択は、決定された状況によって影響を受ける１人以上のユーザに提示されてもよい。影響を受けるユーザのうちの１人に対してそのようなおすすめの選択を決定すると、システムは、影響を受けるユーザのそれぞれに対して可能な選択のリストをさらに決定することができる。１つの実施の形態では、可能な選択は、限られたリソースがより良く利用されること、及び、影響を受けるユーザが入札することを可能にするリソースの割り当ての提案、又はオプションであり得る。影響を受ける各ユーザに対する可能な選択のリストは、状況が解決されるまで、入札リストモジュール３１８に格納されてもよい。可能な選択のリストは、影響を受けるユーザの１人以上、例えば、第１のユーザ及び／又は第２のユーザに提示され提案されてもよい。

１つの実施の形態では、システム３０４、例えば、システム３０４の最適化ユニット３１２は、ユーザに関するプロファイル情報、おすすめの選択を決定するためのリソース制約及び限られたリソースの利用可能性、並びに、ユーザにとって可能な選択のリスト等のパラメータを検索することができる。プロファイル情報は、例えば、限られたリソースを選択するユーザ又は限られたリソースを提供するサービス・プロバイダのトランザクション履歴情報の少なくとも１つを含み得る。１つの実施の形態では、システム３０４の最適化ユニット３１２は、限られたリソース及びプロファイル情報に関する検索されたパラメータ（制約）の少なくとも１つに基づいて、おすすめの選択及び１つ以上の最適化されたリソース割当てオプションを決定及び最適化する。

１つの実施の形態では、システム３０４は、おすすめの選択に関するイベント・タイプを検索することができ、そのようなイベント・タイプは、おすすめの選択が使用されるイベントの重要度を示す。様々な実施の形態では、特定の種類のイベントは、限られたリソースをより大きく、より効率的に利用することを可能にするため、及び／又は、上顧客（loyal customer）を失う等の機会コストを低減するために重要であるとみなされる。イベント・タイプの例には、選択の受信時間、選択のサイズ／ボリューム、トランザクション履歴、ユーザによって行われたトランザクションの累積数、ユーザのロイヤルティ、示された好み等が含まれる。図１（Ｂ）では、システム３０４は、顧客プロファイル内のイベント及び／又は信頼のあるユーザとの過去のトランザクション（イベント）に基づいて、リスクのある顧客がより高い優先度及び重要度レベルであると判断することができ、その場合、リスクのある顧客がその選択に変更を加えると、おすすめの選択がよりよく利用され（例えば、信頼のある顧客を失うことによる機会費用の低減、等）、したがって、システム３０４は、信頼のある顧客ではなく、リスクのある顧客に最初におすすめの選択を提示することができる。別の実施例として、図１（Ｃ）では、システム３０４は、顧客の選択のボリュームの小ささ及び／又は再割り当てについて顧客が示した好みに基づいて、融通の利く顧客がより高い優先度及び重要度レベルであり、融通の利く顧客がその選択に変更を加えると、おすすめの選択がよりよく利用されることを決定することができる。したがって、システム３０４は、最初に融通の利く顧客におすすめの選択を提示することができる。このような実施の形態では、システム３０４の最適化ユニット３１２は、検索されたパラメータ、プロファイル情報及びイベント・タイプの少なくとも１つに基づいて、おすすめの選択及び１つ以上の最適化されたリソースの割当てオプションを決定及び最適化する。

１つの実施の形態では、予測されるリソースの需要又は予測されるユーザの選択等の予測入札（forecast bid）を使用して、おすすめの選択を決定及び最適化することができ、予測入札は、ユーザ又はあるタイプのユーザから受信される可能性の高い選択である。このような予測入札は、限られたリソースに関する過去のトランザクション情報に基づいて決定することができる。例えば、レストラン経営者は、毎週末のランチ時間前後に観察される同様の需要に基づいて、レストランＺにおける４人用の２つのテーブルに対する予測入札を決定することができる。したがって、その期間にレストランＺで２人分のテーブルをリクエストするユーザのためのおすすめの選択を決定する際に、システムは、ユーザのためのおすすめの選択を決定及び最適化する際に、このような予測入札を考慮することができ、例えば、４人分のテーブルは、ユーザに提示されるリソースの割り当てオプションとして提示されない。好ましくは、予測入札に基づくおすすめの選択のこのような決定は、予測可能な競合を回避し、リソース最適化の円滑な処理を保証し、ユーザ満足度を改善するのに有用であり得る。

本開示によれば、可能な選択のリスト（１つ以上のリソースの割り当てオプション）を決定するとき、ユーザに提示された可能な選択のそれぞれ又はリソース割当オプションは、ユーザにそのような選択又はオプションを行うようにインセンティブを与えるためにシステムによって決定される対応するインセンティブ及びトレードオフを有する。１つの実施の形態では、ユーザの現在の選択（例えば、第１の選択）は、ユーザ（例えば第１のユーザ）に対する可能な選択のリストに含まれる。このような可能な選択は、いかなるインセンティブとも関するものではなく、ユーザが現在の選択に変更を加えることを望まず、現在の選択に従って限られたリソースを使用することを望むイベントに対応するために提供される。

１つの実施の形態では、ユーザ、すなわち第１のユーザ又は第２のユーザ、あるいはその両方のそれぞれが、おすすめの選択を受信することができ、可能な選択のリストがユーザに提示される。ユーザは、提示されたおすすめの選択及び可能な選択のリストに基づいて、さらなる選択を行うことを望むことができる。１つの実施の形態では、さらなる選択は、可能な選択のリスト内の１つであり得る。システム３０４は、第１のユーザからシステム３０４に、第１のユーザがさらなる選択を行ったことをシステム３０４に通知する応答メッセージを受け取ることができる。例えば、さらなる選択が、限られたリソースのさらなる選択を含む場合、システム３０４は、選択リストモジュール３１６に記憶された第１のユーザの第１の選択を、それに応じてさらなる選択に対応するように更新してもよい。一方、システム３０４は、第２のユーザからの応答メッセージを受信せず、第２のユーザが現在の選択、すなわち第２の選択を変更したと判断してもよい。したがって、システム３０４は、選択リストモジュール３１６に記憶された第２のユーザの第２の選択を維持してもよい。

様々な実施の形態では、さらなる選択を受信すると、システム３０４は、さらなる選択とおすすめの選択とを比較して、競合があるかどうかを決定するように構成されてもよい。このような比較において、システム３０４は、例えば、第１のユーザによって行われた限られたリソースのさらなる選択が、第１のユーザに提示された可能な選択において割り当てられた限られたリソースに対応するかどうかを決定することによって、ユーザに提示されたそれぞれの可能な選択に対してさらなる選択を比較するように構成されてもよい。システム３０４は、第１のユーザから受信したさらなる選択が、第１のユーザに提示された可能な選択のリストのいずれとも一致しないかどうかを判断することができ、一致しない場合、システム３０４は、その後、さらなる選択が、おすすめの選択に従って行われなかったことを検出する。次に、システム３０４は、さらなる選択とおすすめの選択との間に何らかの競合があるかどうかをチェックすることができる。競合がある場合、リソースの割り当てプロセス及び最適化プロセスがさらなる選択に基づいて再度実行されてもよく、更新されたおすすめの選択が生成され、第１のユーザ及び／又は第２のユーザに提示されてもよい。第１のユーザから受信したさらなる選択が、第１のユーザに提示された可能な選択のリストの１つに一致すると判断された場合、第１のユーザがおすすめの選択を受け入れることが検出される。

別の実施の形態では、第１のユーザ及び／又は第２のユーザに対するおすすめの選択を決定すると、又は決定した後に、第１のユーザ及び第２のユーザとは異なる別のユーザ、例えば第３のユーザからさらなる選択を受信することもできる。このような第３のユーザからのさらなる選択（第３の選択）は、選択リストモジュール３１６に記憶され、おすすめの選択をさらに最適化するために検索されてもよい。様々な実施の形態では、システム３０４は、さらなる選択とおすすめの選択を比較して、競合があるかどうかを判断することができる。このような比較において、システム３０４は、ユーザに提示された可能な選択のそれぞれに対して当該さらなる選択を比較するように構成されてもよい。さらなる選択とおすすめの選択（例えば、第１のユーザに提示されたリソース割当オプションの提案）との間に競合が検出された場合、おすすめの選択は更に最適化され、さらなる選択に基づいて更新されてもよい。更新されたおすすめの選択及び可能な選択の更新されたリストが決定され、第１のユーザ、第２のユーザ、及び第３のユーザの少なくとも１人に提示されてもよい。一実施例として、第１のユーザに提示される可能な選択の更新されたリストにおいて、競合が検出されたオプションは除外されてもよい。

様々な実施の形態において、影響を受けるユーザのうちの少なくとも１人が、おすすめの選択に従ってリソースの割り当てオプションを選択又は入札すると、影響を受けるユーザの選択の間における競合が解決されてもよい。限られたリソースの制約違反（constraint violation）、競合及び他の最適化がないと判断した場合、ユーザは、選択リストモジュールに記憶された限られたリソースの現在の選択をコミットするようにリクエストすることができる。例えば、第１のユーザは、おすすめの選択に関する更新された第１の選択で限られたリソースをコミットすることをリクエストし、第２のユーザは、第２の選択でコミットすることをリクエストすることができる。システム３０４は、コミットリクエストを受信し、選択リストモジュール３１６からユーザの選択リストを検索し、それをコミットリストモジュール３２０に格納する。

１つの実施の形態では、第１のユーザがおすすめの選択でコミットすることをリクエストすると、システム３０４は、第１のユーザに対して、第１のユーザによって選択されたリソースの割り当てオプションの提案に対応するおすすめの選択を受け入れるインセンティブを生成することができる。限られたリソースがユーザによってコミットされると、システム３０４は、限られたリソースデータベース３０２又は限られたリソースの状態を、コミットされたリソースが利用可能になるまでおすすめ又は割り当てられないように更新してもよい。このようなシステムは、複数のユーザに対して限られたリソースを適応的に最適化することを可能にする。

図４は、１つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。様々な実施の形態では、装置は、イベント・プロセッサ４２２等の少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリ（不図示）とを備えてもよく、少なくとも１つのメモリとプログラム・コードは、少なくとも１つのプロセッサ４２２によって、装置に、少なくとも限られたリソースを適応的に最適化する方法を実行させるように構成される。イベント・プロセッサ４２２は、おすすめユニット４２４と、最適化ユニット４２６と、リソースデータベース４０２と、おすすめリストモジュール４０６、選択リストモジュール４０８、入札リストモジュール４１０、及びコミットリストモジュール４１２をそれぞれ格納する４つの記憶モジュールと接続されている。おすすめユニット４２４、最適化ユニット４２６、リソースデータベース４０２、おすすめリストモジュール４０６、選択リストモジュール４０８、入札リストモジュール４１０、及びコミットリストモジュール４１２の機能は、それぞれ、図３に示すハイブリッドレコメンド結合ユニット３１０、最適化ユニット３１２、限定されたリソースデータベース３０２、限定されたおすすめリストモジュール３１４、選択リストモジュール３１６、入札リストモジュール３１８、及びコミットリストモジュール３２０の機能と類似してもよい。イベント・プロセッサ４２２の機能は、おすすめ、リソースの割り当て、最適化、競合の解消処理（選択、ステージ、入札のコミット）、マイクロバッチ処理、ユーザとの通信等のシステムに関するすべてのイベントと、オペレーションを円滑に行うためのすべてのオペレーション機能とを管理することである。１つの実施の形態では、おすすめリストモジュール４０６は、おすすめユニット４２４によって生成されたおすすめリストをユーザのそれぞれについて記憶及び追跡してもよく；選択リストモジュール４０８は、ユーザによる限られたリソースの選択を記憶し追跡してもよく；入札リストモジュール４１０は、最適化ユニット４２６によって生成されたリソースの割当てを記憶し、追跡してもよく；コミットリストモジュール４１２は、限られたリソースに対するユーザのコミットを記憶し、追跡してもよい。

プロセスは、第１のユーザのようなユーザがアプリケーションを起動することにより開始されてもよい。ステップ４１４において、限られたリソースのおすすめのリクエストを第１のユーザから受信してもよい。ステップ４３０において、「おすすめの提示」機能が、イベント・プロセッサ４２２によって起動され、当該リクエストがおすすめユニット４２４に送られてもよい。限られたリソース及びプロファイル情報のパラメータ（制約）等のデータは、リソースデータベース４０２及び他の関連するデータベース（ユーザプロフィールやアクティビティデータベース等）から検索されてもよい。限られたリソース及びそれらの関連する制約（例えば、限られた時間、量、地域）の個別化リストは、ユーザとアイテムのサブセットをコンテンツの特徴（content features）の潜在因子（latent factor）の線形結合として表す、修正されたハイブリッド行列因数分解モデル（modified hybrid matrix factorization model）を使用して生成され、おすすめリストモジュール４０６に格納され、第１のユーザに提示されてもよい。一方、第２のユーザ等の他のユーザがアプリケーションを起動し、限られたリソースのおすすめリクエストを第２のユーザから受信してもよい。したがって、ステップ４３０は、限られたリソース及びそれらの関連する制約の個別化リストを生成し、おすすめリストモジュール４０６に格納し、同様の方法で第２のユーザに提示するために実行されてもよい。

ステップ４１６において、第１のユーザは、限られたリソースの個別化リストからリソースを選択してもよく、ステップ４３２において、当該第１の選択を第１のユーザから受信してもよい。ステップ４３２において、「リクエストのステージング」機能が起動され、第１の選択がリクエストと共に選択リストモジュール４０８に記憶される。一方、第２のユーザは、自分の限られたリソースの個別化リストからリソースを選択してもよく、同様に、ステップ４３２において、第２のユーザによってなされた第２の選択は、選択リストモジュール４０８に記憶される。最適化ユニット４２６は、イベント・プロセッサ４２２によって起動されて、リソース情報、限られたリソースの利用可能性、時間情報、位置情報等のパラメータ及び制約を検索し、選択リストモジュール４０８に記憶された選択における限られたリソースを比較及び監視してもよい。最適化ユニット４２６は、当該選択において、制約違反、競合、及び追加の最適化があるかどうかを決定するための条件付き演算（conditional operation）を実行するように構成されてもよい。ステップ４３４では、第１の選択及び第２の選択のいずれにもそのような状況がないか否かを判断する。そのような状況又は競合がない場合、ステージングは成功である。最適化ユニット４２６は、空の結果（empty result）を返してもよく、ステップ４４２が実行され、第１のユーザ及び第２のユーザによる、それぞれ、第１の選択及び第２の選択のコミットの準備が整えられる。第１の選択と第２の選択との間に競合等の状況がある場合、ステップ４３６が実行される。

ステップ４３６において、「リソースの割り当て」機能が起動され、最適化ユニット４２６によって、第１のユーザ及び第２のユーザのような影響を受けるユーザの各々に対して、リソース割当て及び最適化が実行されてもよい。第１のユーザ及び／又は第２のユーザに対するおすすめの選択及び可能な選択のリストは、ユーザによるリクエスト、限られたリソースの利用可能なパラメータ、時間情報、位置情報、プロファイル情報、イベント・タイプ（又はおすすめの選択が利用されるイベントの重要度）及び／又は予測入札（又は、他のユーザによって選択され、他のユーザから受け取られる可能性が高い予測選択（predicted selection））に基づいて、最適化ユニット４２６による最適化アルゴリズムによって決定されてもよい。第１のユーザ及び／又は第２のユーザに対する可能な選択のリストは、入札リストモジュール４１０に記憶されてもよい。

１つの実施の形態では、ステップ４３８において、「入札の実行」機能が起動されてもよく、システム４０４によってメッセージが送信されて、第１のユーザ及び／又は第２のユーザにおすすめの選択について通知してもよい。可能な選択のリストは、第１のユーザ及び／又は第２のユーザに提示され、これらのユーザは、それぞれの可能な選択のリストのいずれかに入札することができる。１つの実施の形態では、当該リストにおける可能な選択はリソースの割り当てオプションであってもよく、当該リソースの割り当てオプションは対応するインセンティブ及びトレードオフを有し、これらはまた、第１のユーザ及び／又は第２のユーザにリストと共に提示されて、そのような選択又はリソースの割り当てオプションを行うようにインセンティブを与えてもよい。

ステップ４１８において、第１のユーザは、可能な選択のリストの中のリソースの割り当てオプションの提案の１つに従って、自分の選択を再度割り当ててもらうために、割り当てられた入札等のさらなる選択を選択してもよい。ステップ４３８において、リソースの割り当てオプションのための入札に関する応答メッセージを第１のユーザから受信してもよい。このような実施の形態では、選択リストモジュール３１６に記憶された第１のユーザの第１の選択は、割り当てられた入札に関する限られたリソースに対応するように更新されてもよい。

ステップ４４０において、最適化ユニット４２６は、おすすめの選択に反して、第１のユーザによってなされたさらなる選択において、制約違反、競合、及び追加の最適化があるかどうかを決定するための条件付き演算を実行するように構成されてもよい。さらなる選択とおすすめの選択との間に競合のような状況がある場合、プロセスは、ステップ４３６に戻り、さらなる選択に基づいておすすめの選択を更に最適化し、更新されたおすすめの選択を生成する。さらなる選択とおすすめの選択との間に競合が検出されない場合には、割り当ては受け入れられてもよい。次いで、プロセスは、ステップ４４２においてコミットステップに進み、さらなる選択が、第１のユーザによるコミットの準備が整えられる。

ステップ４２０において、第１のユーザ及び／又は第２のユーザは、選択リストモジュール４０８に記憶された選択をコミットすることをリクエストする。ステップ４４２において、コミットのリクエストを第１のユーザ及び／又は第２のユーザから受信してもよい。ユーザによるリクエストに基づいて、選択リストモジュール４０８から選択を検索し、コミットリストモジュール４１２に格納してもよい。例えば、第１のユーザは、割り当てられたリソースを用いて更新された選択をコミットすることを望み、第２のユーザは、第２の選択をコミットすることを望む。１つの実施の形態では、時間及びリソースの制約が満たされていることを保証するステップは、イベント・プロセッサ４２２によって実行される。ステップ４４４では、コミットが成功したか否かを判断し、例えば、第１のユーザと第２のユーザから支払いを受け取り、限られたリソースのトランザクションがトランザクションを完了し、ステップ４４６を実行する。ステップ４４６において、リソースデータベース４０２内のコミットされたリソースの状態を更新するステップが実行され、プロセスは終了してもよい。

ステップ４４０において、入札がないか、又は入札が受け入れられないと判断された場合、あるいは、第１のユーザ及び／又は第２のユーザが、提案されたリソース割当てオプションに対応しないさらなる選択を行った場合、プロセスはステップ４３６に戻ってもよい。

ステップ４４２において、コミットが不成功であると判断された場合、例えば、支払いが受信されていないか、又はユーザがコミットをキャンセルすることをリクエストした場合、プロセスはステップ４３２のリクエストのステージングに戻り、複数のユーザから選択を受信し、当該選択の間における競合を判断する。

図５は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートである。おすすめリストモジュール４０６に記憶された、ユーザに対するおすすめの限られたリソース個別化リストは、例えば、ユーザがおすすめをリクエストしたときに「おすすめの提示」機能が起動されるときに、検索されてもよい。ユーザに対するおすすめの限られたリソースの個別化リストは、当該おすすめがイベント・プロセッサ４２２によって提供される制約又はパラメータの範囲内である場合に決定されてもよい。このような制約又はパラメータは、制限されたリソースの利用可能性に基づいてもよい。当該おすすめが制約又はパラメータ内にないと判断された場合、ステップ４５０において、イベント・プロセッサ４２２に、制約違反に関して通知するステップを実行してもよい。

選択リストモジュール４０８に記憶されたユーザから受け取った選択は、例えば、ユーザがおすすめの限られたリソースの個別化リストからリソースを選択した後に「リクエストのステージング」機能４３２が起動されたときに、検索されてもよい。ユーザから受信した選択は、ステップ４４８において、選択されたリソースが制約の範囲内にあるかどうか、ステップ４５２において、他のユーザからの別の選択とリソースの競合があるかどうか、及び／又は、ステップ４５６において最適化が可能かどうか（例えば、より安価で、より良いリソースが利用可能であるかどうか）について、判断されてもよい。選択されたリソースが制約の範囲内にない場合、ステップ４５０において、イベント・プロセッサ４２２に、制約違反を通知してもよい。他のユーザから受信したさらなる選択との競合が判断された場合、ステップ４６２において、イベント・プロセッサ４２２に、ユーザの選択と他のユーザの選択とが競合することを通知してもよい。可能な最適化が決定された場合、ステップ４５８において、最適化ユニット４２６から最適化されたおすすめの情報が取得され、ステップ４６０において、イベント・プロセッサ４２２に、利用可能な最適化を通知してもよい。

ユーザが入札することを可能にするおすすめの選択及び可能な選択のリストは、例えば、「入札の実行」機能４３８が起動されたときに、入札リストモジュール４１０から検索されてもよい。選択リストモジュール４０８からのものと同様に、可能な選択のリスト内の提案された最適化されたリソースの割り当てオプションは、ステップ４４８において、提案された最適化されたリソースの割り当てにおける割り当てられたリソースが制約の範囲内にあるかどうか、ステップ４５２において、任意のユーザからの選択とリソースの競合があるどうか、及び／又は、ステップ４５６において、最適化が可能かどうかについて、判断されてもよい。割り当てられたリソースが制約の範囲内にない場合、ステップ４５０において、ユーザに、制約違反について通知してもよい。他のユーザから受信したさらなる選択との競合が判断された場合、ステップ４５４において、イベント・プロセッサ４２２に、ユーザの選択と他のユーザの選択とが競合することを通知してもよい。可能な最適化が決定された場合、ステップ４５８において、最適化ユニット４２６から最適化されたおすすめの情報が取得され、ステップ４６０において、イベント・プロセッサ４２２に、利用可能な最適化を通知してもよい。

ユーザは、選択されたリソースのリストが他のいずれのユーザの限られたリソースのリストとも競合しないと判断されたとき、選択リストモジュール４０８又は入札リスト４１０に格納された限られたリソースのリストをコミットすることをリクエストすることができ、したがって「コミットの実行」機能４４２が起動される。ユーザが限られたリソースにコミットする前に、ステップ４４８において、リソースが時間及びリソース制約の範囲内にあるかどうかが判断される。リソースが時間及びリソース制約の範囲内にない場合、ステップ４５０において、イベント・プロセッサ４２２に、制約違反に関して通知されてもよい。

様々な実施の形態では、ステップ４５０、４５４、及び４６０においてイベント・プロセッサ４２２へ通知した後、イベント・プロセッサ４２２によってマイクロバッチ処理ステップ４６２が実行されてもよい。ステップ４２８において、統合された通知又はメッセージが、影響を受けるユーザに送信されてもよい。１つの実施の形態では、通知又はメッセージの送信に続いて、「おすすめの提示」機能４３０、「リクエストのステージング」機能４３２、「入札の実行」機能４３８、及び「コミットの実行」機能４４２のうちの少なくとも１つを非アクティブにしてもよい。

図６は、さらに別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。図６には、「おすすめの提示」４３０、「リクエストのステージング」４３２、「リソースの割り当て」４３６、「入札の実行」４３８、「コミットの実行」４４２、「ユーザの更新」４６３のような六つの列があり、それぞれが限られたリソースを適応的に最適化するための機能を意味している。各列のブロックは、その列に対応する機能を起動するステップに対応する。この実施の形態では、「ユーザの更新」４６３機能は、限られたリソースを適応的に最適化するように構成されたイベント・プロセッサ４２２によって、ユーザの選択を処理し、ユーザ・プロファイルを更新する機能を意味してもよい。このプロセスは、ステップ４６４において、ユーザＡがアプリケーションを介して限られたリソースのおすすめをリクエストしたときに開始されてもよい。ステップ４６５において、「おすすめの提示」機能４３０を起動してもよい。ステップ４６６において、ユーザＡに対して、限られたリソース及び／又は制約（例えば、限られた時間、量）の個別化リストを生成してもよい。ステップ４６７において、システムは、限られたリソースの個別化リストをユーザＡに提示してもよく、例えば、この場合、リソース１〜５のリストがユーザＡにおすすめされる。ステップ４６８において、ユーザＢは、アプリケーションを介して限られたリソースのおすすめをリクエストしてもよい。ステップ４６９において、「おすすめの提示」機能が起動されてもよい。ステップ４７０において、ユーザＢに対して、限られたリソースの個別化リストが生成されてもよい。ステップ４７１において、システムは、限られたリソース（例えば、限られた時間、量）の個別化リストをユーザＢに提示してもよく、例えば、この場合、リソース１〜５の同じリストが、ユーザＡに提示された制約と併せて、ユーザＢに提示される。

続いて、ステップ４６８において、ユーザＡは、個別化リストからリソース２及びリソース３を選択してもよい。ユーザＡからリソース２及びリソース３の選択を受信し、ステップ４７３において、ユーザＡから受信した選択を記憶し、ステージングする。ステップ４７４において、当該選択が、可能性のある制約違反、競合、及び可能性のある最適化について分析され、監視されてもよい。ステップ４７５において、ユーザＡの選択は、更新されてもよいし、選択リストモジュール内に維持されてもよい。ステップ４７６において、ユーザＢは、個別化リストからリソース３、リソース４、及びリソース５を選択してもよい。ユーザＢからリソース３、リソース４、及びリソース５の選択を受信し、ステップ４７７において、ユーザＢから受信した選択を記憶し、ステージングする。ステップ４７８において、当該選択が、可能性のある制約違反、競合、及び可能性のある最適化について分析され、監視されてもよい。システムは、ユーザＡとユーザＢの選択を比較して、リソース３が競合すると判断することができる。ステップ４７９において、システムは、そのような競合が解決される場合に、リソース１〜５がよりよく利用されるであろうというおすすめの選択を決定することができる。システムは、ユーザＡ及び／又はユーザＢに、それぞれの選択に関する競合状態を通知することができる。ステップ４８０において、システムは、リソースの量（resource quantity）、時間情報、位置情報、他の制約、及び／又は、プロファイル情報等の限られたリソースの利用に関するパラメータをデータベースから検索し、検索されたパラメータに基づく最適化アルゴリズムを使用して、１つ又は複数のリソースの割り当てオプションの提案を生成することができる。ステップ４６３において、システムは、ユーザＡがユーザＢよりも小さい選択サイズを有し、ユーザＡがおすすめの選択を受け入れる可能性が高いことを考慮して、おすすめの選択に関するイベント・タイプ、例えば、ユーザＡに提案されるおすすめの選択が、限られたリソースのより良い利用を生成するか、又は限られたリソースに関する機会費用リスクを低減する可能性があることを示すイベント・タイプを検索してもよい。ステップ４８２において、システムは、ユーザＡにおすすめの選択を提示することができ、例えば、この場合、割り当てられたリソース１及びリソース２のリストがユーザＡに提示される。

ステップ４８３において、ユーザＡは、例えば、割り当てられたリソース１及びリソース２を受け入れることによって、さらなる選択を行ってもよい。ステップ４８４において、ユーザＡから、そのようなさらなる選択を通知する応答メッセージを受信してもよく、ステップ４８５において、さらなる選択をユーザＡに提示されたおすすめの選択と比較して、それらが一致しているか、又は競合が存在するかを判断してもよい。ステップ４８６において、ユーザＡとの交渉状態が終了され、リソース３上の競合が解決され、競合状態が終了される。

ステップ４８７において、ユーザＡは、割り当てられたリソース１及びリソース２へのコミットをリクエストすることができる。ステップ４８８において、リクエストがユーザＡから受信される。ステップ４８９において、コミットが成功したかどうか、例えば、割り当てられたリソース１及びリソース２に対する支払いが受信されたかどうかが判断される。そうである場合、ステップ４９０において、システムは、ユーザＡにコミットの成功を通知することができ、リソース１及びリソース２を除去するか、又はリソース１及びリソース２の状態（status）をリソースデータベースにおいて更新することができる。ステップ４９１において、ユーザＢは、選択されたリソース３、リソース４、及びリソース５へのコミットをリクエストすることができる。ステップ４９２では、リクエストがユーザＢから受信される。ステップ４９２では、コミットが成功したかどうかが判断され、例えば、選択されたリソース３、リソース４、及びリソース５に対する支払いが受信された場合、ステップ４９４で、システムはユーザＢにコミットの成功を通知することができ、リソース３、リソース４、及びリソース５は削除されるか、又はリソース３、リソース４、及びリソース５の状態がリソースデータベースで更新される。

図７（Ａ）〜７（Ｄ）、図８（Ｅ）〜８（Ｇ）、図９（Ｈ）〜９（Ｉ）は、限られたリソースを適応的に最適化するためのユーザインターフェース（ＵＩ）の例を示す。図７（Ａ）は、ユーザのプロファイル、現在位置、グループのサイズ（又は人数）、及び好ましい出発時刻に基づいて、おすすめの旅行先のリストを提示する例示的なＵＩ５００を示す。一実施例では、それぞれのおすすめが無効化又はリフレッシュされ得るカウントダウンタイマー５０３、５０５が表示されてもよい。この例では、ユーザは、迎え時刻が午前１１時から午後１２時までの間で、４人のワン・ラッフルズ・プレイスから出発する旅行をリクエストしたいと考えている。おすすめの旅行先５０２、５０４、５０６、５０８のリストが提示される。

図７（Ｂ）は、選択可能な旅行のリストを示すＵＩ５１０の例を示す。この例では、ユーザが目的地としてマリーナベイサンドを選択すると、利用可能な出発時刻５１２のリストが提示され、そのうちのいくつかはスケジュールされており（scheduled）、いくつかはまだスケジュールされていない。図７（Ｃ）は、選択された旅行（出発地がマリーナベイサンド）に基づき得る、おすすめの追加の位置５１６、５１８、５２０を提示する例示的なＵＩ５１４を示す。図７（Ｄ）は、ユーザの選択リストを提示する例示的なＵＩ５２２を示す。この例では、ユーザによって選択され、ユーザの選択リストに格納された選択された旅行５２４、５２６、５２８、５３０のリストが提示される。ＵＩ５２２は、コミットの準備が可能な旅行５２４、競合すると判断された旅行５２６、５２８、及び確認のために保留中の旅行５３０を示している。

図８（Ｅ）は、ユーザがリソースの追加の入札（incoming bid）等のおすすめの選択を受け取ったときの例示的なＵＩ５３２を示す。ユーザは、まだコミットされていないアイテムの追加の入札を受け取ってもよい。このような追加の入札は、ユーザの現在の選択と他の１人のユーザの選択との間で競合が検出されたときに生成されてもよい。この入札において、ユーザは、現在選択されている旅行５２６から３つの座席を取り消す（release）ようにリクエストされる。さらに、おすすめの代替案５３４を提示してもよい。ユーザは、現在の選択５２６を保持し続けることを選択してもよく、又は、現在の選択を、ユーザの要件及び／又は好み（例えば、近くの出発地、及びスケジュールされた時間内）に適合するおすすめの代替案５３４の１つに変更することを選択してもよい。他の可能性としては、ポイント又は報酬システムが入札プロセスの一部であり、ユーザに提示されてもよい（不図示）。例えば、現在の選択を変更することを選択したユーザには、ロイヤルティポイント等のインセンティブが付与される。

図８（Ｆ）は、ユーザが現在利用できないリソースに対してリクエストを行った場合に、現在利用できないリソースに対して、おすすめから外される予定の入札（outgoing bid）を生成する場合のＵＩ５３６の例を示す。この例では、ユーザは、旅行５２８内のさらに２つの座席を入札又はリクエストすることを選択することができる。システムは、関連するユーザを識別し、関連するユーザに対するおすすめの選択を決定する。また、システムは、現在利用できない旅行５２８のユーザへのおすすめの代替案や、例えば、旅行５２８内の２つの座席を取り消すための関連ユーザへのおすすめの代替案等を生成して、成功率を高めてもよい。同様に、他の可能性としては、ポイント又は報酬システムが入札プロセスの一部としてもよい。例えば、現在の選択を変更することを選択したユーザには、ロイヤルティポイント等のインセンティブが付与される。

図８（Ｇ）は、ユーザの選択が制約を満たさない場合のＵＩ５４０の例を示す。状況によっては、例えば、バスはまだ予定されていない等、制約が満たされていないために旅行５３０が確認されなくてもよい。システムは、リクエストされたすべての旅行を継続的に監視し、十分な又は最適化された要望が満たされた後、バスが旅行５３０に割り当てられると、システムは関連するユーザに通知する。そうでなければ、システムは、予定された出発時刻に近いおすすめの代替案５４２を生成し、提示することができる。

図９（Ｈ）は、ユーザの更新された選択リストを提示する例示的なＵＩ５４２を示す。この例では、旅行５２６内の３つの座席をリクエストした他の１人のユーザが、システムによっておすすめされる代替の旅行を選択することができるため、受信したリクエストに対する、おすすめから外される予定の入札を取り消すことができる。他の１人のユーザが、旅行５２８における２つの座席の自分の選択に変更を加えることを望んでいないので、おすすめから外される予定の入札は失敗する可能性がある。旅行５３０は、十分な需要が満たされている場合に確認され得る。競合／入札／制約が解決され、他の制約違反又は競合が決定されない場合に、各旅行５２６、５２８、５３０の状態は、それに応じてＵＩ５４２内で更新される。ＵＩ５４２は、これらの旅行５２４、５２６、５３０がコミットする準備ができたことを示す。

図９（Ｉ）は、コミットされたリソースの詳細を示すＵＩ５４４の例を示す。この例では、ユーザは、旅行５２４へのコミットをリクエストし、コミット及び支払プロセスを進めることができる。一旦支払いが受け取られると、確認が送られ、旅行５２４の詳細が５４４のようなＵＩでユーザに提示される。コミットすると、他のユーザがリソースを選択できなくなる。

図１０（Ａ）及び１０（Ｂ）は、１つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。この実施例では、映画館Ｘで１９：００開始の映画のための５つの座席が利用可能である。３人家族のユーザＡは、映画館Ｘで１９：００に映画のための３つの座席をリクエストしたい。システムは、５つの空席があることをおすすめし、提示することができる。ユーザＡは、図１０（Ａ）に示されているように、例えば、座席６００ａ、６００ｂ、６００ｃのような、自分の好ましい座席の組み合わせを選択することができる。このような選択は、選択リストモジュールにおいて受け取られ、ステージングされてもよい。４分後、家族４人のユーザＢは、映画館で１９：００開始の映画のための４つの座席をリクエストすることができる。システムは、５つの座席がまだ利用可能であることをおすすめし、提示することができる（そのうちの３つはステージングされている）。ユーザＢは、依然として、図１０（Ａ）に示すように、例えば、座席６００ｂ、６００ｃ、６００ｄ、６００ｅのような、自分の好みの座席の組み合わせを選択することができる。このような選択は、選択リストモジュールにおいて受信され、ステージングされてもよい。

両方の選択をチェックして、制約違反又は競合がないかどうかを判断してもよい。この実施の形態では、座席６００ｂと座席６００ｃに２つの重複する座席優先度があるため、座席６００ｂと座席６００ｃの競合が検出される。１つの実施の形態では、ユーザＡ及びユーザＢについて、おすすめの選択及び可能な選択／アクションを決定することができる。例えば、ユーザＡが最初に来て、５分間の時間制約に違反していない場合、システムは、ユーザＢが、重複する座席がユーザＡによって取り消されて利用可能になるかどうかをチェックするために、さらに1分間待機するオプション、又はユーザＢに対する、映画の開始時間を２０：００に変更するオプションを生成してもよい。ユーザＢは、１分間待つというおすすめの選択を受け入れることを示すことができる。ユーザＢが次に利用できるようになった場合に、ユーザＢに対する座席割り当ての優先順位を上げることができる。

ユーザＡは、自身の優先座席の組み合わせにおいて競合が検出されたことを示す通知を受け取ることができる。この通知には、ユーザＡに対して、次の１分以内に座席のリクエストをコミットすること、又は２０：００の別の座席を検討することを促すリマインダを含めることができる。その後、ユーザＡは、さらに選択して、２０：００に変更する映画の開始時間を選択し、座席６０２ａ、６０２ｂ、６０２ｃを選択する。その後、ユーザＢは、自分の優先座席が利用可能であるという通知を受け取ることができる。その後、ユーザＡとユーザＢの選択リストは、図１０（Ｂ）に示すように、座席のそれぞれの選択で更新され、ユーザＡとユーザＢは、必要な支払いを行うことによって、それらの選択と購入をコミットすることができる。

代替的に、別の実施の形態では、そのようなおすすめの選択及び可能な選択／アクションは、映画オペレータがどちらのイベント・タイプをより重要視するかに応じて、異なって提示されてもよい。例えば、ユーザＡが最初に来たにもかかわらず、さらに１分間待つようにユーザＡにおすすめの選択を提示してもよい。これは、ユーザＢがムービーオペレータの特権ユーザ（privileged user）であるためである。同様に、ユーザＢが過去に同様の座席の選択／再配置を受け入れたか、又はコミットしたことがあるため、２０：００の座席のおすすめの選択をユーザＢに提示してもよい。

このようなリソース最適化プロセスは、上述の実施の形態に限定されず、シャトルバス予約サービスのような他のサービスに適用することができることは理解され得る。

図１１（Ａ）及び１１（Ｂ）は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。この実施の形態では、共有ワークスペース（co-working space）に５つのホットデスクが利用可能である。メンバーＡ、Ｂ及びＣは、それぞれ共有ワークスペースのデスクを予約することができる。メンバーＡ、Ｂ及びＣには、メンバーの特典や好みに応じて適切なデスクがおすすめされてもよい。メンバーＡ、Ｂ及びＣは、図１１（Ａ）に示すように、それぞれの好ましいデスクを選択することができ、その選択は、選択リストモジュールにステージングされる。すべての選択をチェックして、制約違反又は競合がないかどうかを判断してもよい。この例では、３つの選択の間に競合は検出されなかった。支払いによって予約を確保するため、各メンバーに５分の猶予期間が与えられてもよい。１分後、メンバーＤは、同僚と一緒に仕事をするために、より大きなホットデスクスペースを受け取りたいことを示す。メンバーＡ、Ｂ、Ｃ、及びＤの選択リストに基づいて、ステージングされたデスクのリクエストにおいて競合が検出される。

１つの実施の形態では、メンバーＡ、Ｂ、及びＣが最初に来ているため、５分の時間制約に違反しておらず、可能な選択／アクションを決定し、メンバーＤに提示して、メンバーＤに、より低い価格の２つの別個のデスクを考慮するか、又は４分間待って、新しいスペースが利用可能かどうかを確認するように依頼してもよい。ただし、メンバーＤには個別に作業するという制約があり、待機を選択してもよい。同時に、メンバーＡ、Ｂ、及びＣに対して、潜在的な収益（potential revenue）を最大化し、リソース使用率を最適化するために、低価格の代替デスクに移動するインセンティブ付きオプションが提示されてもよい。魅力的な低価格により、メンバーＢ及びＣは、移動してもよいと考え、座席７００ｂ及び７００ｃ等の代替机をそれぞれ選択する。メンバーＢ及びＣの更新された選択を通知する応答メッセージを送信してもよく、次いで、メンバーＤに、より大きなホットデスクスペースが利用可能であることを通知し、その後、メンバーＤは、座席７００ｄ及び７００ｅを選択することができる。メンバーＡ、Ｂ、Ｃ、及びＤの選択リストは、図１１（Ｂ）に示すように適宜更新されてもよい。その後、メンバーＡ、Ｂ、Ｃ、及びＤは、必要な支払を行うことで、選択及び購入をコミットすることができる。

別の実施の形態では、メンバーＡ、Ｂ及びＣの選択を受信し、メンバーＤの選択を受信する前に、サービス・プロバイダが、より大きなホットデスクのスペースをリクエストする可能性のあるメンバーＤのような次のメンバーのために、残りのデスク配置が供給されることを期待又は希望し、２つの連続するデスクの予測需要のような予測入札を決定してもよい。このような予測入札は、デスクの過去のトランザクション（例えば、先月の同じ時間帯のデスク）に基づいて決定することができる。おすすめの選択が、メンバーＡ、Ｂ及びＣの予測入札及びプロファイル情報に基づいて、決定及び最適化されてもよい。この例では、代替デスクに移動するオプションをメンバーＡ、Ｂ及びＣに提示してもよい。そして、メンバーＢ及びＣが代替デスクに移動し、メンバーＤ等の次のメンバーのためにより大きなホットデスクのスペースを作成し、リクエストに応じて２つの連続するデスクが利用可能であることを即座に提示してもよい。これにより、ユーザの満足度が向上し、より効率的なリソース利用オペレーションが可能となる。

図１２は、図３に示されるシステムを実施するための使用に適したコンピュータシステムの概略図を示す。図１２に示すように、例示的なコンピューティングデバイス８００は、ソフトウェアルーチンを実行するためのプロセッサ８０４を備える。明確にするために単一のプロセッサが示されているが、コンピューティングデバイス８００はマルチプロセッサシステムを備えてもよい。プロセッサ８０４は、通信インフラストラクチャ８０６に接続され、コンピューティングデバイス８００の他の構成要素と通信する。通信インフラストラクチャ８０６は、例えば、通信バス、クロスバー、又はネットワークを含むことができる。

コンピューティングデバイス８００は、ランダムアクセスメモリ（ＲＡＭ）等のメインメモリ８０８と、二次メモリ８１０とをさらに含む。二次メモリ８１０は、例えば、ハードディスクドライブ、ソリッドステートドライブ、又はハイブリッドドライブであり得るストレージ・ドライブ８１２、及び／又は、磁気テープ・ドライブ、光ディスク・ドライブ、ソリッドステート・ストレージ・ドライブ（ＵＳＢフラッシュドライブ、フラッシュメモリデバイス、ソリッドステートドライブ、メモリカード等）等を含み得るリムーバブル・ストレージ・ドライブ８１４を備えてもよい。リムーバブル・ストレージ・ドライブ８１４は、周知の順序で、リムーバブル記憶媒体８１８の読み取り及び／又は書き込みを行う。リムーバブル記憶媒体８１８は、磁気テープ、光ディスク、不揮発性メモリ記憶媒体等を備えてもよく、リムーバブル・ストレージ・ドライブ８１４によって読み取られ、書き込まれる。当業者には理解されるように、リムーバブル記憶媒体８１８は、コンピュータ実行可能プログラム・コードの命令及び／又はデータを記憶したコンピュータ読み取り可能記憶媒体を含む。

代替の実施の形態では、二次メモリ８１０は、コンピュータプログラム又は他の命令をコンピューティングデバイス８００にロードすることを可能にする他の同様の手段を追加的又は代替的に含んでもよい。このような手段は、例えば、リムーバル・ストレージ・ユニット８２２及びインターフェース８２０を備えてもよい。リムーバル・ストレージ・ユニット８２２及びインターフェース８２０の例は、ビデオゲーム機に見られるようなプログラムカートリッジ及びカートリッジインターフェース、リムーバブル・メモリチップ（ＥＰＲＯＭやＰＲＯＭ等）及び関連するソケット、リムーバブル・ソリッドステート・ストレージ・ドライブ（ＵＳＢフラッシュドライブ、フラッシュメモリデバイス、ソリッドステートドライブ、メモリカード等）、並びに、ソフトウェア及びデータがリムーバル・ストレージ・ユニット８２２からコンピュータシステム８００に転送されることを可能にする他のリムーバル・ストレージ・ユニット８２２及びインターフェース８２０を含んでもよい。

また、コンピューティングデバイス８００は、少なくとも１つの通信インターフェース８２４を含む。通信インターフェース８２４は、コンピューティングデバイス８００と外部デバイスとの間で通信経路８２６を介してソフトウェア及びデータを転送することを可能にする。本発明の様々な実施の形態では、通信インターフェース８２４は、コンピューティングデバイス８００と、パブリックデータ（public data）又はプライベートデータ（private data）通信ネットワーク等のデータ通信ネットワークとの間でデータを転送することを可能にする。通信インターフェース８２４は、異なるコンピューティングデバイス８００間でデータを交換するために使用されてもよく、このようなコンピューティングデバイス８００は、相互接続されたコンピュータネットワークの一部を形成する。通信インターフェース８２４の例は、モデム、ネットワークインターフェース（イーサネットカード等）、通信ポート（シリアル、パラレル、プリンタ、ＧＰＩＢ、ＩＥＥＥ １３９４、ＲＪ ４５、ＵＳＢ等）、関連する回路を有するアンテナ等を含むことができる。通信インターフェース８２４は、有線であっても無線であってもよい。通信インターフェース８２４を介して転送されるソフトウェア及びデータは、電子的、電磁的、光学的、又は通信インターフェース８２４によって受信可能な他の信号であり得る信号の形態である。これらの信号は、通信経路８２６を介して通信インターフェースに供給される。

図１２に示すように、コンピューティングデバイス８００は、さらに、関連するディスプレイ８３０に画像をレンダリングするための動作を実行するディスプレイインターフェース８０２と、関連するスピーカ８３４を介してオーディオコンテンツを再生するための動作を実行するオーディオインターフェース８３２とを含む。

本明細書で使用される場合、「コンピュータプログラム製品」という用語は、部分的に、リムーバブル記憶媒体８１８、リムーバル・ストレージ・ユニット８２２、ストレージ・ドライブ８１２に取り付けられたハードディスク、又は通信経路８２６（ワイヤレスリンク又はケーブル）を介して通信インターフェース８２４にソフトウェアを運ぶ搬送波（carrier wave）を意味してもよい。コンピュータ読み取り可能な記憶媒体とは、記録された命令及び／又はデータを実行及び／又は処理のためにコンピューティングデバイス８００に提供する任意の非一時的な不揮発性の有形の記憶媒体を指す。このような記憶媒体の例には、磁気テープ、ＣＤ−ＲＯＭ、ＤＶＤ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ハードディスクドライブ、ＲＯＭ、若しくは集積回路、ソリッドステート・ストレージ・ドライブ（ＵＳＢフラッシュドライブ、フラッシュメモリデバイス、ソリッドステートドライブ、メモリカード等）、ハイブリッドドライブ、光磁気ディスク、又はＰＣＭＣＩＡカード等のようなコンピュータ読取可能カードが含まれ、これらのデバイスがコンピューティングデバイス８００の内部又は外部であるか否かを問わない。コンピューティングデバイス８００へソフトウェア、アプリケーション・プログラム、命令及び／又はデータの提供可能な一時的な又は非有形のコンピュータ読み取り可能な伝送媒体の例には、無線又は赤外線伝送チャネル、並びに他のコンピュータ又はネットワーク・デバイスへのネットワーク接続、及び電子メール伝送及びウェブサイト等に記録された情報を含むインターネット又はイントラネットが含まれる。

コンピュータプログラム（「コンピュータ・プログラム・コード」とも称する）は、メインメモリ８０８及び／又は二次メモリ８１０に格納される。また、通信インターフェース８２４を介してコンピュータプログラムを受信することもできる。このようなコンピュータプログラムを実行することにより、コンピューティングデバイス８００は、本明細書で説明する実施の形態の１つ以上の特徴を実行することができる。様々な実施の形態において、コンピュータプログラムを実行することにより、プロセッサ８０４が上述の実施の形態の特徴を実行することを可能にする。したがって、そのようなコンピュータプログラムは、コンピュータシステム８００のコントローラを表す。

ソフトウェアは、コンピュータプログラム製品に格納され、コンピュータデバイス８００に、リムーバブル・ストレージ・ドライブ８１４、ストレージ・ドライブ８１２、又はインターフェース８２０を使用してロードされてもよい。コンピュータプログラム製品は、非一時的なコンピュータ可読媒体であってもよい。あるいは、コンピュータプログラム製品は、コンピュータシステム８００に通信経路８２６を介してダウンロードされてもよい。ソフトウェアは、プロセッサ８０４によって実行されると、コンピューティングデバイス８００に、図３に示される方法を実行するために必要な動作を実行させる。

図１２の実施の形態は、単に例として、システム８００の動作及び構造を説明するために提示されることを理解されたい。したがって、いくつかの実施の形態では、コンピューティングデバイス８００の１つ以上の特徴を省略することができる。また、いくつかの実施の形態では、コンピューティングデバイス８００の１つ又は複数の特徴を一緒に組み合わせることができる。さらに、一部の実施の形態では、コンピューティングデバイス８００の１つ以上の特徴は、１つ以上の構成要素の部分に分割されてもよい。

図１２に示された要素は、上述の実施の形態で説明したように、サーバの様々な機能及び動作を実行するための手段を提供するように機能することが理解されるであろう。

コンピューティングデバイス８００が輸送プロバイダの効率を最適化するように構成されている場合、コンピューティングデバイス８００は、実行時にコンピューティングシステム８００に、以下のステップを実行させるアプリケーションを格納した非一時的なコンピュータ読み取り可能な媒体を有する：輸送プロバイダによって第１の位置において管理される車両の第１の出発時刻を受信するステップ；第１の位置の後に位置する第２の位置における車両の第２の出発時間を受け取るステップ；第１の出発時刻と第２の出発時刻との差を測定するステップ；その差分の決定に応答して、現在のスケジュールを更新し、第２の位置の後の位置における車両の更新された推定到着時間を示す更新されたスケジュールを提供するステップ。

多岐にわたり説明された本発明の精神又は範囲から逸脱することなく、特定の実施の形態に示されるように、本発明に多数の変形及び／又は修正を行うことができることは、当業者には理解されるであろう。したがって、本実施の形態は、全ての点で例示的であり、限定的ではないと考えるべきである。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
第１のユーザ及び第２のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化する方法であって、
前記第１のユーザから、前記限られたリソースの第１の選択であって、前記第１のユーザが前記限られたリソースをどのように使用したいかを示す前記第１の選択を受け取るステップと、
前記第１の選択と、前記第２のユーザからの第２の選択であって、前記第２のユーザが前記限られたリソースをどのように使用したいかを示す前記第２の選択とを比較するステップと、及び
前記第１の選択と前記第２の選択との比較に基づいて、前記限られたリソースのおすすめの選択であって、前記限られたリソースがどのように最もよく利用されるかを示す前記おすすめの選択を決定するステップと、
を備える、方法。
（付記２）
前記限られたリソースの前記おすすめの選択を決定するステップは、
前記限られたリソースの利用に関する少なくとも１つのパラメータであって、前記限られたリソースの量、時間情報、及び位置情報を含む前記少なくとも１つのパラメータを検索するステップと、及び
前記少なくとも１つのパラメータに基づいて選択するリソースを決定するステップと、
を備える、付記１に記載の方法。
（付記３）
前記限られたリソースの前記おすすめの選択を決定するステップは、さらに、
前記限られたリソースに関するさらなる選択であって、複数のユーザのうちの１人によってなされる前記さらなる選択を受信するステップと、及び
前記さらなる選択と前記おすすめの選択を比較して、競合があるかどうかを判断するステップと、
を備える、付記１又は２に記載の方法。
（付記４）
前記第１の選択を受け取ることに応答して、可能な選択であって、対応するインセンティブ及びトレードオフをそれぞれ有する前記可能な選択のリストを決定するステップと、及び
前記第１の選択を含む前記可能な選択のリストを前記第１のユーザに提示するステップと、
をさらに備える、付記１〜３のいずれか１つに記載の方法。
（付記５）
前記おすすめの選択に関するイベント・タイプであって、前記おすすめの選択が使用されるイベントの重要度を示す前記イベント・タイプを検索するステップをさらに備える、付記１〜４のいずれか１つに記載の方法。
（付記６）
前記第１のユーザ及び前記第２のユーザのそれぞれに関するプロファイル情報であって、トランザクション履歴情報の１つを含むプロファイル情報を検索するステップをさらに備える、付記１〜５のいずれか１つに記載の方法。
（付記７）
前記限られたリソースの前記おすすめの選択を決定するステップは、前記少なくとも１つのパラメータ、イベント・タイプ、プロファイル情報、及び前記複数のユーザのうちの少なくとも１人から受信される可能性が高い予測入札（forecast bid）のうちの少なくとも１つに基づいて、前記おすすめの選択を最適化するステップをさらに含む、付記２〜６のいずれか１つに記載の方法。
（付記８）
前記第１のユーザ及び前記第２のユーザの少なくとも一方に前記おすすめの選択を提示するステップと、及び
前記第１のユーザ及び前記第２のユーザの少なくとも一方から、前記おすすめの選択の提示に応答する応答メッセージを受信するステップと、
をさらに備える、付記７に記載の方法。
（付記９）
前記限られたリソースの前記おすすめの選択を決定するステップは、前記応答メッセージに基づいて前記おすすめの選択を更新するステップを含む、付記８に記載の方法。
（付記１０）
前記限られたリソースの利用に応じて、前記限られたリソースの利用可能性に関するデータベースを更新するステップをさらに備える、付記１〜９のいずれか１つに記載の方法。
（付記１１）
第１のユーザと第２のユーザとを含む複数のユーザに対して、限られたリソースを適応的に最適化する装置であって、
少なくとも１つのプロセッサと、及び
コンピュータ・プログラム・コードを含む少なくとも１つのメモリと、
を備え、
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第１のユーザから、前記限られたリソースの第１の選択であって、前記第１のユーザが前記限られたリソースをどのように使用したいかを示す前記第１の選択を受け取ること、
前記第１の選択と、前記第２のユーザからの第２の選択であって、前記第２のユーザが前記限られたリソースをどのように使用したいかを示す前記第２の選択とを比較することと、及び
前記第１の選択と前記第２の選択との比較に基づいて、前記限られたリソースのおすすめの選択であって、前記限られたリソースがどのように最もよく利用されるかを示す前記おすすめの選択を決定すること、
を少なくとも実行させるように構成されている、装置。
（付記１２）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記限られたリソースの利用に関する少なくとも１つのパラメータであって、前記限られたリソースの量、時間情報、及び位置情報を含む前記少なくとも１つのパラメータを検索すること、及び
前記少なくとも１つのパラメータに基づいて選択するリソースを決定すること、
を実行させるようにさらに構成されている、付記１１に記載の装置。
（付記１３）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記限られたリソースに関するさらなる選択であって、複数のユーザのうちの１人によってなされる前記さらなる選択を受信すること、及び
前記さらなる選択と前記おすすめの選択を比較して、競合があるかどうかを判断すること、
を実行させるようにさらに構成されている、付記１１又は１２に記載の装置。
（付記１４）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第１の選択を受け取ることに応答して、可能な選択であって、対応するインセンティブ及びトレードオフをそれぞれ有する前記可能な選択のリストを決定すること、及び
前記第１の選択を含む前記可能な選択のリストを前記第１のユーザに提示すること、
を実行させるようにさらに構成されている、付記１１〜１３のいずれか１つに記載の装置。
（付記１５）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記おすすめの選択に関するイベント・タイプであって、前記おすすめの選択が使用されるイベントの重要度を示す前記イベント・タイプを検索すること、
を実行させるようにさらに構成されている、付記１１〜１４のいずれか１つに記載の装置。
（付記１６）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第１のユーザ及び前記第２のユーザのそれぞれに関するプロファイル情報であって、トランザクション履歴情報の１つを含むプロファイル情報を検索すること、
を実行させるようにさらに構成されている、付記１１〜１５のいずれか１つに記載の装置。
（付記１７）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記少なくとも１つのパラメータ、イベント・タイプ、プロファイル情報、及び前記複数のユーザのうちの少なくとも１人から受信される可能性が高い予測入札（forecast bid）のうちの少なくとも１つに基づいて、前記おすすめの選択を最適化すること、
を実行させるようにさらに構成されている、付記１２〜１６のいずれか１つに記載の装置。
（付記１８）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第１のユーザ及び前記第２のユーザの少なくとも一方に前記おすすめの選択を提示すること、及び
前記第１のユーザ及び前記第２のユーザの少なくとも一方から、前記おすすめの選択の提示に応答する応答メッセージを受信すること、
を実行させるようにさらに構成されている、付記１７に記載の装置。
（付記１９）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記応答メッセージに基づいて前記おすすめの選択を更新すること、
を実行させるようにさらに構成されている、付記１８に記載の装置。
（付記２０）
少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記限られたリソースの利用に応じて、前記限られたリソースの利用可能性に関するデータベースを更新すること、
を実行させるようにさらに構成されている、付記１１〜１９のいずれか１つに記載の装置。

Claims (10)

1. 第１のユーザ及び第２のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化する方法であって、
   前記第１のユーザから、前記限られたリソースの第１の選択であって、前記第１のユーザが前記限られたリソースをどのように使用したいかを示す前記第１の選択を受け取るステップと、
   前記第１の選択と、前記第２のユーザからの第２の選択であって、前記第２のユーザが前記限られたリソースをどのように使用したいかを示す前記第２の選択とを比較するステップと、及び
   前記第１の選択と前記第２の選択との比較に基づいて、前記限られたリソースのおすすめの選択であって、前記限られたリソースがどのように最もよく利用されるかを示す前記おすすめの選択を決定するステップと、
   を備える、方法。
2. 前記限られたリソースの前記おすすめの選択を決定するステップは、
   前記限られたリソースの利用に関する少なくとも１つのパラメータであって、前記限られたリソースの量、時間情報、及び位置情報を含む前記少なくとも１つのパラメータを検索するステップと、及び
   前記少なくとも１つのパラメータに基づいて選択するリソースを決定するステップと、
   を備える、請求項１に記載の方法。
3. 前記限られたリソースの前記おすすめの選択を決定するステップは、さらに、
   前記限られたリソースに関するさらなる選択であって、複数のユーザのうちの１人によってなされる前記さらなる選択を受信するステップと、及び
   前記さらなる選択と前記おすすめの選択を比較して、競合があるかどうかを判断するステップと、
   を備える、請求項１又は２に記載の方法。
4. 前記第１の選択を受け取ることに応答して、可能な選択であって、対応するインセンティブ及びトレードオフをそれぞれ有する前記可能な選択のリストを決定するステップと、及び
   前記第１の選択を含む前記可能な選択のリストを前記第１のユーザに提示するステップと、
   をさらに備える、請求項１〜３のいずれか一項に記載の方法。
5. 前記おすすめの選択に関するイベント・タイプであって、前記おすすめの選択が使用されるイベントの重要度を示す前記イベント・タイプを検索するステップをさらに備える、請求項１〜４のいずれか一項に記載の方法。
6. 前記第１のユーザ及び前記第２のユーザのそれぞれに関するプロファイル情報であって、トランザクション履歴情報の１つを含むプロファイル情報を検索するステップをさらに備える、請求項１〜５のいずれか一項に記載の方法。
7. 前記限られたリソースの前記おすすめの選択を決定するステップは、前記少なくとも１つのパラメータ、イベント・タイプ、プロファイル情報、及び前記複数のユーザのうちの少なくとも１人から受信される可能性が高い予測入札（forecast bid）のうちの少なくとも１つに基づいて、前記おすすめの選択を最適化するステップをさらに含む、請求項２〜６のいずれか一項に記載の方法。
8. 前記第１のユーザ及び前記第２のユーザの少なくとも一方に前記おすすめの選択を提示するステップと、及び
   前記第１のユーザ及び前記第２のユーザの少なくとも一方から、前記おすすめの選択の提示に応答する応答メッセージを受信するステップと、
   をさらに備える、請求項７に記載の方法。
9. 前記限られたリソースの前記おすすめの選択を決定するステップは、前記応答メッセージに基づいて前記おすすめの選択を更新するステップを含む、請求項８に記載の方法。
10. 第１のユーザと第２のユーザとを含む複数のユーザに対して、限られたリソースを適応的に最適化する装置であって、
    少なくとも１つのプロセッサと、及び
    コンピュータ・プログラム・コードを含む少なくとも１つのメモリと、
    を備え、
    少なくとも１つの前記プロセッサを用いて、少なくとも１つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
    前記第１のユーザから、前記限られたリソースの第１の選択であって、前記第１のユーザが前記限られたリソースをどのように使用したいかを示す前記第１の選択を受け取ること、
    前記第１の選択と、前記第２のユーザからの第２の選択であって、前記第２のユーザが前記限られたリソースをどのように使用したいかを示す前記第２の選択とを比較することと、及び
    前記第１の選択と前記第２の選択との比較に基づいて、前記限られたリソースのおすすめの選択であって、前記限られたリソースがどのように最もよく利用されるかを示す前記おすすめの選択を決定すること、
    を少なくとも実行させるように構成されている、装置。

Images