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

限られたリソースを適応的に最適化する方法及び装置 Download PDF

Info

Publication number
JP2021177379A
JP2021177379A JP2021075051A JP2021075051A JP2021177379A JP 2021177379 A JP2021177379 A JP 2021177379A JP 2021075051 A JP2021075051 A JP 2021075051A JP 2021075051 A JP2021075051 A JP 2021075051A JP 2021177379 A JP2021177379 A JP 2021177379A
Authority
JP
Japan
Prior art keywords
user
selection
limited
resource
recommended
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021075051A
Other languages
English (en)
Inventor
アルバート ハーディ タヌタマ
Albert Hardy TANUTAMA
ルー メング
Meng Lu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to SG10202004134W priority Critical
Priority to SG10202004134WA priority patent/SG10202004134WA/en
Application filed by NEC Corp filed Critical NEC Corp
Publication of JP2021177379A publication Critical patent/JP2021177379A/ja
Pending legal-status Critical Current

Links

Images

Abstract

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

Description

本発明は、限られたリソースを適応的に最適化する方法に関するが、これに限定されるものではない。
レコメンドシステム(recommender systems)は、複数のユーザにリソースを選択するための「適切な」おすすめ(recommendation)を提供する機械学習アルゴリズムの重要なクラスである。このようなおすすめでは、リソースがその関連性に従ってランク付けされ、最も関連性の高いリソースが選択肢として複数のユーザのそれぞれに示される。おすすめのアプローチは、一般に、協調フィルタリング(collaborative filtering)のシステムとコンテンツベース(content-based)のシステムの2つの主なカテゴリに分けられる。近年、2つ以上のおすすめの戦略を組み合わせ、それらの利点を強化し、それらの欠点又は制限を低減することを目的とするハイブリッドレコメンドシステムがますます一般的になっている。
現在、機械学習技術は、YouTube(登録商標)、Netflix(登録商標)、Amazon(登録商標)等のビジネスに広く適用されているが、おすすめの技術及び処理は、例えば、飛行機のチケット、客室、パフォーマンスシート、EV充電ポイントを予約する場合等、限定されたリソース(bounded resource)として知られる限られたリソース(limited resource)、又はリソースにおける他の制約及び制限が存在する現実世界の状況において利用される場合には、それほど有効かつ効率的ではない。リソース不足は、複数のユーザの選択の間の競争及び競合を生じさせるが、多くのレコメンドシステムは、このような状況を扱うように設計されていない。
その結果、レコメンドシステムはユーザエクスペリエンスを低下させる。ユーザに、アイテムを見逃さないために、不必要な不安やプレッシャーをかける。また、先着順(First Come First Serve)のアプローチにより、おすすめされる限られたリソースを選択しようとすると、頻繁にエラーが発生する場合がある。一方、サービス・プロバイダ(service providers)は、予約/仮予約を取り込むことができる。しかし、これは、限られたリソースの利用を最適化したり、収益を最大化したりする際に、機会費用(opportunity cost)の発生をもたらす可能性がある。
したがって、上記の問題の1つ又は複数に対処する、限られたリソースを適応的に最適化する方法を提供する必要性が存在する。
さらに、他の望ましい特徴及び性質は、添付の図面及びこの開示の背景に関連して、以下の詳細な説明及び添付の特許請求の範囲から明らかになるであろう。
第1の態様において、本開示は、第1のユーザ及び第2のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化する方法を提供し、この方法は、第1のユーザから、限られたリソースの第1の選択であって、第1のユーザが限られたリソースをどのように使用したいかを示す第1の選択を受け取り;第1の選択と、第2のユーザからの第2の選択であって、第2のユーザが限られたリソースをどのように使用したいかを示す第2の選択とを比較して;第1の選択と第2の選択との比較に基づいて、限られたリソースのおすすめの選択であって、限られたリソースがどのように最もよく利用されるかを示すおすすめの選択を決定する。
第2の態様において、本開示は、第1のユーザ及び第2のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化するための装置を提供し、この装置は、少なくとも1つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも1つのメモリとを備え;少なくとも1つのプロセッサを用いて、少なくとも1つのメモリとコンピュータ・プログラム・コードとは、装置に、第1のユーザから、限られたリソースの第1の選択であって、第1のユーザが限られたリソースをどのように使用したいかを示す第1の選択を受け取ること;第1の選択と、第2のユーザからの第2の選択であって、第2のユーザが限られたリソースをどのように使用したいかを示す第2の選択とを比較すること;第1の選択と第2の選択との比較に基づいて、限られたリソースのおすすめの選択であって、限られたリソースがどのように最もよく利用されるかを示すおすすめの選択を決定すること;を実行させる。
本発明の実施の形態は、以下の書面による説明から、実施の形態のみにより、及び図面とともに、当業者にはさらに理解され、容易に明らかになるであろう。
図1(A)は、1つの実施の形態に係る、限られたリソースがどのように利用され得るかを示す概略図を示し、図1(B)及び図1(C)は、それぞれ、1つの実施の形態に係る2つのタイプの顧客から、図1(A)に示される限られたリソースの選択を示す概略図を示す。 図2は、限られたリソースを利用する、関連するレコメンドシステムのプロセスを示すフローチャートである。 図3は、1つの実施の形態に係る、限られたリソースを適応的に最適化するためのシステムを示す。 図4は、1つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。 図5は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートである。 図6は、さらに別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。 図7(A)〜7(D)は、限られたリソースを適応的に最適化するためのユーザ・インターフェースの例を示す。 図8(E)〜8(G)は、限られたリソースを適応的に最適化するためのユーザ・インターフェースの例を示す。 図9(H)〜9(I)は、限られたリソースを適応的に最適化するためのユーザ・インターフェースの例を示す。 図10(A)及び10(B)は、1つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。 図11(A)及び11(B)は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。 図12は、図3に示されるシステムを実施するための使用に適したコンピュータシステムの概略図を示す。
以下、本発明の実施の形態について図面を参照して説明する。図面中の同じ符号及び文字は、同じ要素又は等価物を指す。
以下の説明のいくつかの部分は、コンピュータメモリ内のデータに対する演算のアルゴリズム及び機能的又は記号的表現に関して明示的又は暗示的に提示される。これらのアルゴリズム記述及び機能的又は記号的表現は、データ処理技術の当業者が、その仕事の内容を当業者に最も効果的に伝えるために使用する手段である。アルゴリズムは、ここでは、一般に、所望の結果を導く自己無撞着なステップのシーケンスであると考えられる。ステップは、記憶、転送、結合、比較、及び他の方法で操作することができる電気、磁気、又は光学信号等の物理量の物理的操作を必要とするものである。
特に明記しない限り、また以下から明らかなように、本明細書において、「受け取る」、「計算する」、「決定する」、「更新する」、「生成する」、「初期化する」、「出力する」、「受信する」、「検索する」、「識別する」、「分散する」、「認証する」等の用語を使用する議論は、コンピュータシステム内の物理量として表されるデータを、コンピュータシステム内の物理量として表される他のデータを、他の情報記憶装置、送信装置、又は表示装置内の物理量として表される他のデータに操作及び変換する、コンピュータシステム又は類似の電子装置の動作及びプロセスを指すことが理解されるであろう。
本明細書では、これらの方法の動作を実行するための装置も開示する。このような装置は、必要な目的のために特別に構成されてもよく、又はコンピュータに記憶されたコンピュータプログラムによって選択的に起動又は再構成されるコンピュータ又は他の装置を含んでもよい。本明細書に提示されるアルゴリズム及びディスプレイは、いかなる特定のコンピュータ又は他の装置にも本質的に関連しない。様々な機械を、本明細書の教示によるプログラムと共に使用することができる。あるいは、必要な方法ステップを実行するためのより特殊化された装置の構成が適切であり得る。コンピュータの構造は、以下の説明から明らかになる。
さらに、本明細書は、本明細書に記載された方法の個々のステップがコンピュータコードによって実行されてもよいことが当業者には明らかであろうという点で、コンピュータプログラムも暗に開示している。コンピュータプログラムは、特定のプログラミング言語及びその実装に限定されるものではない。種々のプログラミング言語及びそのコーディングを用いて、本明細書に含まれる開示の教示を実施することができることが理解されよう。また、コンピュータプログラムは、特定の制御フローに限定されるものではない。本発明の精神又は範囲から逸脱することなく異なる制御フローを使用することができるコンピュータプログラムの多くの他の変形がある。
さらに、コンピュータプログラムのステップのうちの1つ以上は、順次にではなく並列に実行されてもよい。このようなコンピュータプログラムは、任意のコンピュータ可読媒体に格納することができる。コンピュータ可読媒体は、磁気又は光ディスク、メモリチップ、又はコンピュータとインターフェースするのに適した他の記憶装置等の記憶装置を含むことができる。コンピュータ可読媒体はまた、インターネットシステムに例示されるようなハードワイヤード媒体、又はGSM移動電話システムに例示されるようなワイヤレス媒体を含むことができる。このようなコンピュータ上にロードされて実行されるコンピュータプログラムは、好ましい方法のステップを実行する装置を効果的にもたらす。
本発明の様々な実施の形態は、限られたリソースを適応的に最適化する方法及び装置に関する。以下の様々な実施の形態では、用語「リソース(resource)」は、用語「アイテム(item)」を参照するか、又は用語「アイテム」と交換可能に使用することができる。「限られた(limited)」という用語は、「限定された(bounded)」という用語と同じ意味で参照又は使用することができ、「ユーザ」という用語は、「顧客(customer)」、「消費者(consumer)」、又は「買い手(buyer)」という用語と同じ意味で参照又は使用することができる。図1(A)は、1つの実施の形態に係る、限られたリソースがどのように利用され得るかを示す概略図を示す。単純化のために、限られたリソースとは、5つのスロット、すなわちスロット100a、スロット100b、スロット100c、スロット100d及びスロット100eの利用可能な容量を指す。このような5つのスロットは、例えば、午後5時に出発するシャトルバスサービスのための5つの座席、共通の部屋のための5つの予約時間スロット等、時間、空間及び/又は量の制約を有するオブジェクト又はアイテムであり得る。慣例的に、協調的で個別化されたアクティビティ(personalized activity)のレコメンド方法及びレコメンドシステムは、位置(location)、時間、グループ、好み(preference)及びユーザが選択したアイテムリストに基づいて、おすすめのアイテムを提供する。限定されたアイテム(例えば、航空券、客室、パフォーマンスシート、EV充電ポイント)をおすすめする際に使用されるこのような関連する方法又はシステムは、先着順のアプローチにより、アイテム(例えば、ユーザによる取得、在庫切れ)を見落としてしまうという不安や虞を引き起こす可能性がある。一方、例えば、サービス・プロバイダがユーザのために予約や仮予約を取り込む一方、ユーザが最終的な選択を先延ばしにする可能性があり、限定されたアイテムを提供するサービス・プロバイダは、利用率及び転換率が低くなる可能性がある。しかし、アクションを促すために、「見落としの虞(FOMO;Fear of Missing Out)」を取り込むことは、非倫理的であると考えられる。
図1(B)は、1つの実施の形態に係る2つのタイプの顧客からの、図1(A)に示される限られたリソース100a〜100eの選択を示す概略図を示す。この実施の形態では、限られたリソースの選択、すなわち、サービス・プロバイダ(劇場経営者)によって提供されるスロット100a〜100e(例えば、映画の上映会のために一度に5枚のチケット)は、2つのタイプの顧客、すなわち、信頼のある顧客及びリスクのある顧客によって受け取られる。1つの実施の形態では、信頼のある顧客は、サービス・プロバイダがアクセス可能なリストに登録されているか、サービス・プロバイダが知っているか、又はサービス・プロバイダが認識している選択パターンに基づいて登録されている顧客を参照することができ、リスクの高い顧客は、新規であるか、サービス・プロバイダが知らないか、又は限られたリソースを提供するサービス・プロバイダが認識していない顧客を参照することができる。アレンジメントでは、リスクのある顧客は選択を尊重していないかもしれない。この実施の形態では、リスクの高い顧客は、3つのスロット、例えばスロット100a、100b及び100cをリクエスト又は選択することができる。リスクのある顧客からのスロット100a、100b及び100cのこのようなリクエスト又は選択は、サービス・プロバイダによって受信され、サービス・プロバイダは、リスクのある顧客のために3つのスロット100a、100b、100cを一時的に予約することができる。その後、3つを超えるスロット(例えば、スロット100a、100b、100c及び100d)をリクエスト又は選択しようとする信頼のある顧客は、スロット100a、100b及び100cがリスクのある顧客のために一時的に予約されているため、そのようなリクエスト又は選択を実行することができない。このような状況では、リスクの高い顧客がリクエストをキャンセルした場合、サービス・プロバイダは、信頼のある顧客にサービスを提供しないことによる機会費用を負担することになる。これは、限られたリソースの競合が存在する現実世界の状況において利用される関連するレコメンドシステムにおける機会費用リスクを示している。
図1(C)は、1つの実施の形態に係る、図1(A)に示された限られたリソース100a〜100eの2つのタイプの顧客からの選択を示す概略図を示す。この実施の形態では、限られたリソース、すなわちサービス・プロバイダによって提供されるスロット100a〜100e(例えば、特定の時間に出発するA市からB市への航空便の座席の5枚のチケット)の選択は、2つのタイプの顧客、すなわち融通の利く顧客(flexible customer)及び制約のある顧客(例えば、航空会社)によって受け取られる。1つの実施の形態では、融通の利く顧客は、限られたリソースの選択が、選択されたリソースの量が少ないために、又は顧客によって与えられた同意によって、比較的変更されやすい顧客を意味してもよい。制約のある顧客とは、限られたリソースの選択が、おそらく選択の大部分に起因し、又は、顧客の好み(例えば、同じフライトで旅行する、お互いの隣に座りたいカップルによって購入される2枚のチケット)に起因する、比較的変更しにくい顧客を意味してもよい。この実施の形態では、3人の融通の利く顧客が3つのスロット100a、100c、100eをそれぞれ予約することができる。3人の融通の利く顧客からのスロット100a、100b、100cのこのようなリクエスト又は選択は、サービス・プロバイダによって受信され、サービス・プロバイダは3人の融通の利く顧客のためにそれぞれ3つのスロット100a、100c、100eを予約することができる。次に、制約のある顧客は、互いに隣接する2つのスロット(例えば、100d、100e)をリクエスト又は選択することを望むかもしれないが、スロット100eは3人の融通の利く顧客のうちの1人のためにすでに一時的に予約されている。このような状況では、サービス・プロバイダは、容量の割り当てを最適化することによって、両方のタイプのお客様にサービスを提供することによって使用率を最大化することができない。これは、限られたリソースの競合が存在する現実世界の状況において利用される関連するレコメンドシステムにおける非効率的利用リスクを示している。
図2は、限られたリソースを利用する関連するレコメンドシステムのプロセスを示すフローチャートである。本開示の様々な実施の形態によれば、リソースは、座席、客室、駐車場等の限定された(又は限られた)リソース202と、映画、音楽や記事等の限定されないリソース204とに分類することができる。慣例的に、ステップ206において、ユーザは、限定されたリソース202をリクエスト又は選択することができる。サービス・プロバイダは、このようなリクエスト又は選択をユーザから受け取り、リソースが利用可能であるか、予約されていないかをチェックすることができる。リソースが利用可能である場合、ステップ208aにおいて、サービス・プロバイダは、ユーザからの限定されたリソース202の選択を確認することができる。リソースが利用可能でないか、又は予約されている場合、サービス・プロバイダは、ユーザからの限定されたリソース202の選択を拒否し、ステップ206に戻ることができる。一方、ステップ210において、サービス・プロバイダは、ユーザに限定されたリソース202の選択をおすすめし、その選択をユーザのために予約することができる。続いて、ステップ212aにおいて、ユーザは、限定されたリソース202のおすすめされた選択を受け入れるか、又はステップ212bにおいて、おすすめされた選択を拒否することができる。このような関連するレコメンドシステムは、限定された(又は限られた)リソース202を適応的に最適化しないことに留意されたい。
本開示の様々な実施の形態によれば、「選択(pick)、入札(bid)、コミット(commit)」技術と同様のスマートショッピングカートが導入され実装されて、おすすめの選択を決定し、複数のユーザに対して限られたリソースを適応的に最適化する。様々な実施の形態において、複数のユーザに対して限られたリソースを適応的に最適化する方法は、選択プロセス(picking process)、入札プロセス(bidding process)、及びコミットプロセス(committing process)を含むことができる。ピッキングプロセスにより、ユーザは、限られたリソースの中から、ユーザが関心を示すおすすめアイテムを選択することができる。このようなプロセスを使用して、ユーザに対する後続の補完的及び関するアイテムのおすすめをさらに改善することができる。また、限られたリソースのアイテムを他のユーザが選択できるようにすることで、柔軟性を向上する。好ましくは、これは、予約を回避し、先着順のアプローチをとることができる。引き続いて、制約の変更(例えば、リソースが使用できなくなった)、競合(例えば、他のユーザも関心があり、同じアイテムを選択している)、又はより最適化された状況(例えば、より利用可能なリソース)が発生したときに、入札プロセスが開始されてもよい。入札プロセスの間、スマートな競合解決プロセスが、影響を受けるユーザ(例えば、ユーザと、同じアイテムに興味を持ち、選択した他のユーザ)の間で調整され、実行される。特に、入札プロセスでは、影響を受けるユーザに選択オプションが提示され、ユーザの選択、決定、及び好みに基づいてリソースをより有効に活用できるようになる。好ましくは、これは、ユーザ満足度を改善する可能性が高い、適応的かつ対話的なリソース最適化プロセスを提供する。引き続いて、ユーザが選択プロセスにおける選択又は入札プロセスにおける提案された選択をコミットすることができるコミットプロセスが実行されてもよい。その結果、発生する可能性のある競合を早期に緩和及び管理することで、成功率が向上し、影響を受けるユーザによる混乱(churn)又はカート放棄の可能性をコミットプロセス中に最小限に抑えることができる。好ましくは、これにより、リソース利用を適応的に最適化及び最大化し、従って、複数のユーザのユーザ満足度を改善する。
図3は、1つの実施の形態に係る、複数のユーザに対して限られたリソースを適応的に最適化するためのシステム304を示す。1つの実施例では、システムは、限られたリソースを適応的に最適化するように構成される限定されたハイブリッドレコメンドシステムとして説明されてもよい。システム304は、制約監視ユニット306、競合/非競合監視ユニット308、ハイブリッドレコメンド結合ユニット310、及び最適化ユニット312を備えてもよい。システム304は、限定されたリソースデータベース302に接続され、リソースデータベース302は、限られたリソースのリスト、それらの可用性(availability)、及びおすすめを提示するときにユーザに提供される情報を記憶する。また、システム304は、複数のユーザのそれぞれに対して、リソースデータベース又は限られたリソースのリストの4つのそれぞれのサブセットを記憶する4つの記憶モジュール、すなわち、限定されたおすすめリストモジュール314、選択リストモジュール316、入札リストモジュール318、及びコミットリストモジュール320にも接続される。このようなリストモジュールは、例えば、限られたリソースが現在利用可能であるか、選択(ステージング(staged))されているか、入札されているか(割り当てられているか)、又はコミットされている場合に、システム304が限られたリソースの状態を追跡し更新するのに有用である。
様々な実施の形態では、限定されたおすすめリストモジュール314は、各ユーザにおすすめされた、又は各ユーザに個別化された(personalized)、限られたリソースのリストを格納することができる。このような限定されたおすすめリストモジュール314は、協調フィルタとコンテンツベースのアルゴリズムの組み合わせ、又は任意の他のレコメンドアルゴリズムを使用して、ハイブリッドレコメンド結合ユニット310によって生成することができる。おすすめの限られたリソースのリストは、(a)限られたリソースデータベース302から得られた限られたリソースの人気、利用可能性、及び/又は量、(b)時間情報及び位置情報等の現在のトランザクションの詳細、(c)ユーザの行動(behavior)、示された好み(indicated preference)、サービス・プロバイダ(例えば、サービスの権威のあるメンバー(prestigious member))との関係、及び/又は限られたリソースに関するトランザクションの履歴情報等のユーザのプロファイル情報等、限られたリソースの利用に関する少なくとも1つのパラメータに基づくことができる。1つの実施の形態に係ると、システム304は、ユーザにおすすめされる限られたリソースの個別化されたリスト(personalized list)と、限られたリソースの利用に関する関連パラメータ(限られた時間、量、地域(area)等の制約)とを生成する。このようなパラメータは、制約監視ユニット306によって検索されてもよい。別の実施の形態では、システム304は、ユーザが利用可能なすべての限られたリソースを含む限られたリソースのリストを生成する。さらに別の実施の形態では、システム304は、限られたリソースの同じリストを生成し、特定のタイプのユーザ又はすべてのユーザに送信する。以下の実施の形態では、説明を簡単にするために、第1のユーザと第2のユーザの2人のユーザを含むものとする。このようなシステムは、2人を超えるユーザを含む複数のユーザに適用することができることは明らかである。
1つの実施の形態では、第1のユーザは、限定されたおすすめリストモジュール314からおすすめされた限られたリソースの個別化されたリスト(以下、「個別化リスト」と称する)にアクセスし、個別化リストから限られたリソースの少なくとも1つを選択(以下、「第1の選択」と称する)することができ、そのような選択は、第1のユーザが限られたリソースをどのように使用したいかを示す。1つの実施の形態では、特定の制約(例えば、限られた時間、量又は位置)が、おすすめの限られたリソースの個別化リストに付与されてもよく、第1のユーザは、制約の範囲内で自分の選択を行うように提案されてもよい。システムは、限られたリソースの第1の選択を第1のユーザから受け取ることができる。1つの実施の形態では、システム304は、第1の選択があったことを通知する通知を受信することができる。1つの実施の形態では、第1のユーザから第1の選択を受信すると、第1の選択が選択リストモジュール316にステージングされる。
次に、第2のユーザは、限定されたおすすめリストモジュール314からおすすめされた限られたリソースの個別化リストにアクセスし、個別化リストから限られたリソースの少なくとも1つの選択(以下、「第2の選択」と称する)を行うことができ、そのような選択は、第2のユーザが限られたリソースをどのように使用したいかを示す。1つの実施の形態では、特定の制約(例えば、限られた時間、量又は位置)が、おすすめの限られたリソースの個別化リストに付与されてもよく、第2のユーザは、制約の範囲内で自分の選択を行うように提案されてもよい。システムは、限られたリソースの第2の選択を第2のユーザから受け取ることができる。1つの実施の形態では、システム304は、第2の選択があったことを通知する通知を受信することができる。
1つの実施の形態では、第2のユーザから第2の選択を受信すると、システム304によって、例えば、システム304の制約監視ユニット306、競合/非競合監視ユニット308、及び最適化ユニット312等によって、第1の選択と第2の選択とが比較され、制約違反(例えば、第1のユーザがリソースを選択する際に時間制限を超えた、等)、競合(例えば、限られたリソースのいずれかが2つ以上の選択に存在する、等)、及び/又は、追加の最適化(例えば、利用可能な、より優れた、より安価なリソース、等)の可能性があるかどうかが判断される。様々な実施の形態において、システム304は、任意の状況のそのような比較及び判断のために、数量、時間情報、及び位置情報等の限られたリソースに関する1つ以上のパラメータ(制約)を検索してもよい。
様々な実施の形態では、競合のような状況が決定された場合、システム304は、その状況が解決された場合に限られたリソースが最もよく利用されることを示すおすすめの選択を決定する。そのようなおすすめの選択は、決定された状況によって影響を受ける1人以上のユーザに提示されてもよい。影響を受けるユーザのうちの1人に対してそのようなおすすめの選択を決定すると、システムは、影響を受けるユーザのそれぞれに対して可能な選択のリストをさらに決定することができる。1つの実施の形態では、可能な選択は、限られたリソースがより良く利用されること、及び、影響を受けるユーザが入札することを可能にするリソースの割り当ての提案、又はオプションであり得る。影響を受ける各ユーザに対する可能な選択のリストは、状況が解決されるまで、入札リストモジュール318に格納されてもよい。可能な選択のリストは、影響を受けるユーザの1人以上、例えば、第1のユーザ及び/又は第2のユーザに提示され提案されてもよい。
1つの実施の形態では、システム304、例えば、システム304の最適化ユニット312は、ユーザに関するプロファイル情報、おすすめの選択を決定するためのリソース制約及び限られたリソースの利用可能性、並びに、ユーザにとって可能な選択のリスト等のパラメータを検索することができる。プロファイル情報は、例えば、限られたリソースを選択するユーザ又は限られたリソースを提供するサービス・プロバイダのトランザクション履歴情報の少なくとも1つを含み得る。1つの実施の形態では、システム304の最適化ユニット312は、限られたリソース及びプロファイル情報に関する検索されたパラメータ(制約)の少なくとも1つに基づいて、おすすめの選択及び1つ以上の最適化されたリソース割当てオプションを決定及び最適化する。
1つの実施の形態では、システム304は、おすすめの選択に関するイベント・タイプを検索することができ、そのようなイベント・タイプは、おすすめの選択が使用されるイベントの重要度を示す。様々な実施の形態では、特定の種類のイベントは、限られたリソースをより大きく、より効率的に利用することを可能にするため、及び/又は、上顧客(loyal customer)を失う等の機会コストを低減するために重要であるとみなされる。イベント・タイプの例には、選択の受信時間、選択のサイズ/ボリューム、トランザクション履歴、ユーザによって行われたトランザクションの累積数、ユーザのロイヤルティ、示された好み等が含まれる。図1(B)では、システム304は、顧客プロファイル内のイベント及び/又は信頼のあるユーザとの過去のトランザクション(イベント)に基づいて、リスクのある顧客がより高い優先度及び重要度レベルであると判断することができ、その場合、リスクのある顧客がその選択に変更を加えると、おすすめの選択がよりよく利用され(例えば、信頼のある顧客を失うことによる機会費用の低減、等)、したがって、システム304は、信頼のある顧客ではなく、リスクのある顧客に最初におすすめの選択を提示することができる。別の実施例として、図1(C)では、システム304は、顧客の選択のボリュームの小ささ及び/又は再割り当てについて顧客が示した好みに基づいて、融通の利く顧客がより高い優先度及び重要度レベルであり、融通の利く顧客がその選択に変更を加えると、おすすめの選択がよりよく利用されることを決定することができる。したがって、システム304は、最初に融通の利く顧客におすすめの選択を提示することができる。このような実施の形態では、システム304の最適化ユニット312は、検索されたパラメータ、プロファイル情報及びイベント・タイプの少なくとも1つに基づいて、おすすめの選択及び1つ以上の最適化されたリソースの割当てオプションを決定及び最適化する。
1つの実施の形態では、予測されるリソースの需要又は予測されるユーザの選択等の予測入札(forecast bid)を使用して、おすすめの選択を決定及び最適化することができ、予測入札は、ユーザ又はあるタイプのユーザから受信される可能性の高い選択である。このような予測入札は、限られたリソースに関する過去のトランザクション情報に基づいて決定することができる。例えば、レストラン経営者は、毎週末のランチ時間前後に観察される同様の需要に基づいて、レストランZにおける4人用の2つのテーブルに対する予測入札を決定することができる。したがって、その期間にレストランZで2人分のテーブルをリクエストするユーザのためのおすすめの選択を決定する際に、システムは、ユーザのためのおすすめの選択を決定及び最適化する際に、このような予測入札を考慮することができ、例えば、4人分のテーブルは、ユーザに提示されるリソースの割り当てオプションとして提示されない。好ましくは、予測入札に基づくおすすめの選択のこのような決定は、予測可能な競合を回避し、リソース最適化の円滑な処理を保証し、ユーザ満足度を改善するのに有用であり得る。
本開示によれば、可能な選択のリスト(1つ以上のリソースの割り当てオプション)を決定するとき、ユーザに提示された可能な選択のそれぞれ又はリソース割当オプションは、ユーザにそのような選択又はオプションを行うようにインセンティブを与えるためにシステムによって決定される対応するインセンティブ及びトレードオフを有する。1つの実施の形態では、ユーザの現在の選択(例えば、第1の選択)は、ユーザ(例えば第1のユーザ)に対する可能な選択のリストに含まれる。このような可能な選択は、いかなるインセンティブとも関するものではなく、ユーザが現在の選択に変更を加えることを望まず、現在の選択に従って限られたリソースを使用することを望むイベントに対応するために提供される。
1つの実施の形態では、ユーザ、すなわち第1のユーザ又は第2のユーザ、あるいはその両方のそれぞれが、おすすめの選択を受信することができ、可能な選択のリストがユーザに提示される。ユーザは、提示されたおすすめの選択及び可能な選択のリストに基づいて、さらなる選択を行うことを望むことができる。1つの実施の形態では、さらなる選択は、可能な選択のリスト内の1つであり得る。システム304は、第1のユーザからシステム304に、第1のユーザがさらなる選択を行ったことをシステム304に通知する応答メッセージを受け取ることができる。例えば、さらなる選択が、限られたリソースのさらなる選択を含む場合、システム304は、選択リストモジュール316に記憶された第1のユーザの第1の選択を、それに応じてさらなる選択に対応するように更新してもよい。一方、システム304は、第2のユーザからの応答メッセージを受信せず、第2のユーザが現在の選択、すなわち第2の選択を変更したと判断してもよい。したがって、システム304は、選択リストモジュール316に記憶された第2のユーザの第2の選択を維持してもよい。
様々な実施の形態では、さらなる選択を受信すると、システム304は、さらなる選択とおすすめの選択とを比較して、競合があるかどうかを決定するように構成されてもよい。このような比較において、システム304は、例えば、第1のユーザによって行われた限られたリソースのさらなる選択が、第1のユーザに提示された可能な選択において割り当てられた限られたリソースに対応するかどうかを決定することによって、ユーザに提示されたそれぞれの可能な選択に対してさらなる選択を比較するように構成されてもよい。システム304は、第1のユーザから受信したさらなる選択が、第1のユーザに提示された可能な選択のリストのいずれとも一致しないかどうかを判断することができ、一致しない場合、システム304は、その後、さらなる選択が、おすすめの選択に従って行われなかったことを検出する。次に、システム304は、さらなる選択とおすすめの選択との間に何らかの競合があるかどうかをチェックすることができる。競合がある場合、リソースの割り当てプロセス及び最適化プロセスがさらなる選択に基づいて再度実行されてもよく、更新されたおすすめの選択が生成され、第1のユーザ及び/又は第2のユーザに提示されてもよい。第1のユーザから受信したさらなる選択が、第1のユーザに提示された可能な選択のリストの1つに一致すると判断された場合、第1のユーザがおすすめの選択を受け入れることが検出される。
別の実施の形態では、第1のユーザ及び/又は第2のユーザに対するおすすめの選択を決定すると、又は決定した後に、第1のユーザ及び第2のユーザとは異なる別のユーザ、例えば第3のユーザからさらなる選択を受信することもできる。このような第3のユーザからのさらなる選択(第3の選択)は、選択リストモジュール316に記憶され、おすすめの選択をさらに最適化するために検索されてもよい。様々な実施の形態では、システム304は、さらなる選択とおすすめの選択を比較して、競合があるかどうかを判断することができる。このような比較において、システム304は、ユーザに提示された可能な選択のそれぞれに対して当該さらなる選択を比較するように構成されてもよい。さらなる選択とおすすめの選択(例えば、第1のユーザに提示されたリソース割当オプションの提案)との間に競合が検出された場合、おすすめの選択は更に最適化され、さらなる選択に基づいて更新されてもよい。更新されたおすすめの選択及び可能な選択の更新されたリストが決定され、第1のユーザ、第2のユーザ、及び第3のユーザの少なくとも1人に提示されてもよい。一実施例として、第1のユーザに提示される可能な選択の更新されたリストにおいて、競合が検出されたオプションは除外されてもよい。
様々な実施の形態において、影響を受けるユーザのうちの少なくとも1人が、おすすめの選択に従ってリソースの割り当てオプションを選択又は入札すると、影響を受けるユーザの選択の間における競合が解決されてもよい。限られたリソースの制約違反(constraint violation)、競合及び他の最適化がないと判断した場合、ユーザは、選択リストモジュールに記憶された限られたリソースの現在の選択をコミットするようにリクエストすることができる。例えば、第1のユーザは、おすすめの選択に関する更新された第1の選択で限られたリソースをコミットすることをリクエストし、第2のユーザは、第2の選択でコミットすることをリクエストすることができる。システム304は、コミットリクエストを受信し、選択リストモジュール316からユーザの選択リストを検索し、それをコミットリストモジュール320に格納する。
1つの実施の形態では、第1のユーザがおすすめの選択でコミットすることをリクエストすると、システム304は、第1のユーザに対して、第1のユーザによって選択されたリソースの割り当てオプションの提案に対応するおすすめの選択を受け入れるインセンティブを生成することができる。限られたリソースがユーザによってコミットされると、システム304は、限られたリソースデータベース302又は限られたリソースの状態を、コミットされたリソースが利用可能になるまでおすすめ又は割り当てられないように更新してもよい。このようなシステムは、複数のユーザに対して限られたリソースを適応的に最適化することを可能にする。
図4は、1つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。様々な実施の形態では、装置は、イベント・プロセッサ422等の少なくとも1つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも1つのメモリ(不図示)とを備えてもよく、少なくとも1つのメモリとプログラム・コードは、少なくとも1つのプロセッサ422によって、装置に、少なくとも限られたリソースを適応的に最適化する方法を実行させるように構成される。イベント・プロセッサ422は、おすすめユニット424と、最適化ユニット426と、リソースデータベース402と、おすすめリストモジュール406、選択リストモジュール408、入札リストモジュール410、及びコミットリストモジュール412をそれぞれ格納する4つの記憶モジュールと接続されている。おすすめユニット424、最適化ユニット426、リソースデータベース402、おすすめリストモジュール406、選択リストモジュール408、入札リストモジュール410、及びコミットリストモジュール412の機能は、それぞれ、図3に示すハイブリッドレコメンド結合ユニット310、最適化ユニット312、限定されたリソースデータベース302、限定されたおすすめリストモジュール314、選択リストモジュール316、入札リストモジュール318、及びコミットリストモジュール320の機能と類似してもよい。イベント・プロセッサ422の機能は、おすすめ、リソースの割り当て、最適化、競合の解消処理(選択、ステージ、入札のコミット)、マイクロバッチ処理、ユーザとの通信等のシステムに関するすべてのイベントと、オペレーションを円滑に行うためのすべてのオペレーション機能とを管理することである。1つの実施の形態では、おすすめリストモジュール406は、おすすめユニット424によって生成されたおすすめリストをユーザのそれぞれについて記憶及び追跡してもよく;選択リストモジュール408は、ユーザによる限られたリソースの選択を記憶し追跡してもよく;入札リストモジュール410は、最適化ユニット426によって生成されたリソースの割当てを記憶し、追跡してもよく;コミットリストモジュール412は、限られたリソースに対するユーザのコミットを記憶し、追跡してもよい。
プロセスは、第1のユーザのようなユーザがアプリケーションを起動することにより開始されてもよい。ステップ414において、限られたリソースのおすすめのリクエストを第1のユーザから受信してもよい。ステップ430において、「おすすめの提示」機能が、イベント・プロセッサ422によって起動され、当該リクエストがおすすめユニット424に送られてもよい。限られたリソース及びプロファイル情報のパラメータ(制約)等のデータは、リソースデータベース402及び他の関連するデータベース(ユーザプロフィールやアクティビティデータベース等)から検索されてもよい。限られたリソース及びそれらの関連する制約(例えば、限られた時間、量、地域)の個別化リストは、ユーザとアイテムのサブセットをコンテンツの特徴(content features)の潜在因子(latent factor)の線形結合として表す、修正されたハイブリッド行列因数分解モデル(modified hybrid matrix factorization model)を使用して生成され、おすすめリストモジュール406に格納され、第1のユーザに提示されてもよい。一方、第2のユーザ等の他のユーザがアプリケーションを起動し、限られたリソースのおすすめリクエストを第2のユーザから受信してもよい。したがって、ステップ430は、限られたリソース及びそれらの関連する制約の個別化リストを生成し、おすすめリストモジュール406に格納し、同様の方法で第2のユーザに提示するために実行されてもよい。
ステップ416において、第1のユーザは、限られたリソースの個別化リストからリソースを選択してもよく、ステップ432において、当該第1の選択を第1のユーザから受信してもよい。ステップ432において、「リクエストのステージング」機能が起動され、第1の選択がリクエストと共に選択リストモジュール408に記憶される。一方、第2のユーザは、自分の限られたリソースの個別化リストからリソースを選択してもよく、同様に、ステップ432において、第2のユーザによってなされた第2の選択は、選択リストモジュール408に記憶される。最適化ユニット426は、イベント・プロセッサ422によって起動されて、リソース情報、限られたリソースの利用可能性、時間情報、位置情報等のパラメータ及び制約を検索し、選択リストモジュール408に記憶された選択における限られたリソースを比較及び監視してもよい。最適化ユニット426は、当該選択において、制約違反、競合、及び追加の最適化があるかどうかを決定するための条件付き演算(conditional operation)を実行するように構成されてもよい。ステップ434では、第1の選択及び第2の選択のいずれにもそのような状況がないか否かを判断する。そのような状況又は競合がない場合、ステージングは成功である。最適化ユニット426は、空の結果(empty result)を返してもよく、ステップ442が実行され、第1のユーザ及び第2のユーザによる、それぞれ、第1の選択及び第2の選択のコミットの準備が整えられる。第1の選択と第2の選択との間に競合等の状況がある場合、ステップ436が実行される。
ステップ436において、「リソースの割り当て」機能が起動され、最適化ユニット426によって、第1のユーザ及び第2のユーザのような影響を受けるユーザの各々に対して、リソース割当て及び最適化が実行されてもよい。第1のユーザ及び/又は第2のユーザに対するおすすめの選択及び可能な選択のリストは、ユーザによるリクエスト、限られたリソースの利用可能なパラメータ、時間情報、位置情報、プロファイル情報、イベント・タイプ(又はおすすめの選択が利用されるイベントの重要度)及び/又は予測入札(又は、他のユーザによって選択され、他のユーザから受け取られる可能性が高い予測選択(predicted selection))に基づいて、最適化ユニット426による最適化アルゴリズムによって決定されてもよい。第1のユーザ及び/又は第2のユーザに対する可能な選択のリストは、入札リストモジュール410に記憶されてもよい。
1つの実施の形態では、ステップ438において、「入札の実行」機能が起動されてもよく、システム404によってメッセージが送信されて、第1のユーザ及び/又は第2のユーザにおすすめの選択について通知してもよい。可能な選択のリストは、第1のユーザ及び/又は第2のユーザに提示され、これらのユーザは、それぞれの可能な選択のリストのいずれかに入札することができる。1つの実施の形態では、当該リストにおける可能な選択はリソースの割り当てオプションであってもよく、当該リソースの割り当てオプションは対応するインセンティブ及びトレードオフを有し、これらはまた、第1のユーザ及び/又は第2のユーザにリストと共に提示されて、そのような選択又はリソースの割り当てオプションを行うようにインセンティブを与えてもよい。
ステップ418において、第1のユーザは、可能な選択のリストの中のリソースの割り当てオプションの提案の1つに従って、自分の選択を再度割り当ててもらうために、割り当てられた入札等のさらなる選択を選択してもよい。ステップ438において、リソースの割り当てオプションのための入札に関する応答メッセージを第1のユーザから受信してもよい。このような実施の形態では、選択リストモジュール316に記憶された第1のユーザの第1の選択は、割り当てられた入札に関する限られたリソースに対応するように更新されてもよい。
ステップ440において、最適化ユニット426は、おすすめの選択に反して、第1のユーザによってなされたさらなる選択において、制約違反、競合、及び追加の最適化があるかどうかを決定するための条件付き演算を実行するように構成されてもよい。さらなる選択とおすすめの選択との間に競合のような状況がある場合、プロセスは、ステップ436に戻り、さらなる選択に基づいておすすめの選択を更に最適化し、更新されたおすすめの選択を生成する。さらなる選択とおすすめの選択との間に競合が検出されない場合には、割り当ては受け入れられてもよい。次いで、プロセスは、ステップ442においてコミットステップに進み、さらなる選択が、第1のユーザによるコミットの準備が整えられる。
ステップ420において、第1のユーザ及び/又は第2のユーザは、選択リストモジュール408に記憶された選択をコミットすることをリクエストする。ステップ442において、コミットのリクエストを第1のユーザ及び/又は第2のユーザから受信してもよい。ユーザによるリクエストに基づいて、選択リストモジュール408から選択を検索し、コミットリストモジュール412に格納してもよい。例えば、第1のユーザは、割り当てられたリソースを用いて更新された選択をコミットすることを望み、第2のユーザは、第2の選択をコミットすることを望む。1つの実施の形態では、時間及びリソースの制約が満たされていることを保証するステップは、イベント・プロセッサ422によって実行される。ステップ444では、コミットが成功したか否かを判断し、例えば、第1のユーザと第2のユーザから支払いを受け取り、限られたリソースのトランザクションがトランザクションを完了し、ステップ446を実行する。ステップ446において、リソースデータベース402内のコミットされたリソースの状態を更新するステップが実行され、プロセスは終了してもよい。
ステップ440において、入札がないか、又は入札が受け入れられないと判断された場合、あるいは、第1のユーザ及び/又は第2のユーザが、提案されたリソース割当てオプションに対応しないさらなる選択を行った場合、プロセスはステップ436に戻ってもよい。
ステップ442において、コミットが不成功であると判断された場合、例えば、支払いが受信されていないか、又はユーザがコミットをキャンセルすることをリクエストした場合、プロセスはステップ432のリクエストのステージングに戻り、複数のユーザから選択を受信し、当該選択の間における競合を判断する。
図5は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートである。おすすめリストモジュール406に記憶された、ユーザに対するおすすめの限られたリソース個別化リストは、例えば、ユーザがおすすめをリクエストしたときに「おすすめの提示」機能が起動されるときに、検索されてもよい。ユーザに対するおすすめの限られたリソースの個別化リストは、当該おすすめがイベント・プロセッサ422によって提供される制約又はパラメータの範囲内である場合に決定されてもよい。このような制約又はパラメータは、制限されたリソースの利用可能性に基づいてもよい。当該おすすめが制約又はパラメータ内にないと判断された場合、ステップ450において、イベント・プロセッサ422に、制約違反に関して通知するステップを実行してもよい。
選択リストモジュール408に記憶されたユーザから受け取った選択は、例えば、ユーザがおすすめの限られたリソースの個別化リストからリソースを選択した後に「リクエストのステージング」機能432が起動されたときに、検索されてもよい。ユーザから受信した選択は、ステップ448において、選択されたリソースが制約の範囲内にあるかどうか、ステップ452において、他のユーザからの別の選択とリソースの競合があるかどうか、及び/又は、ステップ456において最適化が可能かどうか(例えば、より安価で、より良いリソースが利用可能であるかどうか)について、判断されてもよい。選択されたリソースが制約の範囲内にない場合、ステップ450において、イベント・プロセッサ422に、制約違反を通知してもよい。他のユーザから受信したさらなる選択との競合が判断された場合、ステップ462において、イベント・プロセッサ422に、ユーザの選択と他のユーザの選択とが競合することを通知してもよい。可能な最適化が決定された場合、ステップ458において、最適化ユニット426から最適化されたおすすめの情報が取得され、ステップ460において、イベント・プロセッサ422に、利用可能な最適化を通知してもよい。
ユーザが入札することを可能にするおすすめの選択及び可能な選択のリストは、例えば、「入札の実行」機能438が起動されたときに、入札リストモジュール410から検索されてもよい。選択リストモジュール408からのものと同様に、可能な選択のリスト内の提案された最適化されたリソースの割り当てオプションは、ステップ448において、提案された最適化されたリソースの割り当てにおける割り当てられたリソースが制約の範囲内にあるかどうか、ステップ452において、任意のユーザからの選択とリソースの競合があるどうか、及び/又は、ステップ456において、最適化が可能かどうかについて、判断されてもよい。割り当てられたリソースが制約の範囲内にない場合、ステップ450において、ユーザに、制約違反について通知してもよい。他のユーザから受信したさらなる選択との競合が判断された場合、ステップ454において、イベント・プロセッサ422に、ユーザの選択と他のユーザの選択とが競合することを通知してもよい。可能な最適化が決定された場合、ステップ458において、最適化ユニット426から最適化されたおすすめの情報が取得され、ステップ460において、イベント・プロセッサ422に、利用可能な最適化を通知してもよい。
ユーザは、選択されたリソースのリストが他のいずれのユーザの限られたリソースのリストとも競合しないと判断されたとき、選択リストモジュール408又は入札リスト410に格納された限られたリソースのリストをコミットすることをリクエストすることができ、したがって「コミットの実行」機能442が起動される。ユーザが限られたリソースにコミットする前に、ステップ448において、リソースが時間及びリソース制約の範囲内にあるかどうかが判断される。リソースが時間及びリソース制約の範囲内にない場合、ステップ450において、イベント・プロセッサ422に、制約違反に関して通知されてもよい。
様々な実施の形態では、ステップ450、454、及び460においてイベント・プロセッサ422へ通知した後、イベント・プロセッサ422によってマイクロバッチ処理ステップ462が実行されてもよい。ステップ428において、統合された通知又はメッセージが、影響を受けるユーザに送信されてもよい。1つの実施の形態では、通知又はメッセージの送信に続いて、「おすすめの提示」機能430、「リクエストのステージング」機能432、「入札の実行」機能438、及び「コミットの実行」機能442のうちの少なくとも1つを非アクティブにしてもよい。
図6は、さらに別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示すフローチャートを示す。図6には、「おすすめの提示」430、「リクエストのステージング」432、「リソースの割り当て」436、「入札の実行」438、「コミットの実行」442、「ユーザの更新」463のような六つの列があり、それぞれが限られたリソースを適応的に最適化するための機能を意味している。各列のブロックは、その列に対応する機能を起動するステップに対応する。この実施の形態では、「ユーザの更新」463機能は、限られたリソースを適応的に最適化するように構成されたイベント・プロセッサ422によって、ユーザの選択を処理し、ユーザ・プロファイルを更新する機能を意味してもよい。このプロセスは、ステップ464において、ユーザAがアプリケーションを介して限られたリソースのおすすめをリクエストしたときに開始されてもよい。ステップ465において、「おすすめの提示」機能430を起動してもよい。ステップ466において、ユーザAに対して、限られたリソース及び/又は制約(例えば、限られた時間、量)の個別化リストを生成してもよい。ステップ467において、システムは、限られたリソースの個別化リストをユーザAに提示してもよく、例えば、この場合、リソース1〜5のリストがユーザAにおすすめされる。ステップ468において、ユーザBは、アプリケーションを介して限られたリソースのおすすめをリクエストしてもよい。ステップ469において、「おすすめの提示」機能が起動されてもよい。ステップ470において、ユーザBに対して、限られたリソースの個別化リストが生成されてもよい。ステップ471において、システムは、限られたリソース(例えば、限られた時間、量)の個別化リストをユーザBに提示してもよく、例えば、この場合、リソース1〜5の同じリストが、ユーザAに提示された制約と併せて、ユーザBに提示される。
続いて、ステップ468において、ユーザAは、個別化リストからリソース2及びリソース3を選択してもよい。ユーザAからリソース2及びリソース3の選択を受信し、ステップ473において、ユーザAから受信した選択を記憶し、ステージングする。ステップ474において、当該選択が、可能性のある制約違反、競合、及び可能性のある最適化について分析され、監視されてもよい。ステップ475において、ユーザAの選択は、更新されてもよいし、選択リストモジュール内に維持されてもよい。ステップ476において、ユーザBは、個別化リストからリソース3、リソース4、及びリソース5を選択してもよい。ユーザBからリソース3、リソース4、及びリソース5の選択を受信し、ステップ477において、ユーザBから受信した選択を記憶し、ステージングする。ステップ478において、当該選択が、可能性のある制約違反、競合、及び可能性のある最適化について分析され、監視されてもよい。システムは、ユーザAとユーザBの選択を比較して、リソース3が競合すると判断することができる。ステップ479において、システムは、そのような競合が解決される場合に、リソース1〜5がよりよく利用されるであろうというおすすめの選択を決定することができる。システムは、ユーザA及び/又はユーザBに、それぞれの選択に関する競合状態を通知することができる。ステップ480において、システムは、リソースの量(resource quantity)、時間情報、位置情報、他の制約、及び/又は、プロファイル情報等の限られたリソースの利用に関するパラメータをデータベースから検索し、検索されたパラメータに基づく最適化アルゴリズムを使用して、1つ又は複数のリソースの割り当てオプションの提案を生成することができる。ステップ463において、システムは、ユーザAがユーザBよりも小さい選択サイズを有し、ユーザAがおすすめの選択を受け入れる可能性が高いことを考慮して、おすすめの選択に関するイベント・タイプ、例えば、ユーザAに提案されるおすすめの選択が、限られたリソースのより良い利用を生成するか、又は限られたリソースに関する機会費用リスクを低減する可能性があることを示すイベント・タイプを検索してもよい。ステップ482において、システムは、ユーザAにおすすめの選択を提示することができ、例えば、この場合、割り当てられたリソース1及びリソース2のリストがユーザAに提示される。
ステップ483において、ユーザAは、例えば、割り当てられたリソース1及びリソース2を受け入れることによって、さらなる選択を行ってもよい。ステップ484において、ユーザAから、そのようなさらなる選択を通知する応答メッセージを受信してもよく、ステップ485において、さらなる選択をユーザAに提示されたおすすめの選択と比較して、それらが一致しているか、又は競合が存在するかを判断してもよい。ステップ486において、ユーザAとの交渉状態が終了され、リソース3上の競合が解決され、競合状態が終了される。
ステップ487において、ユーザAは、割り当てられたリソース1及びリソース2へのコミットをリクエストすることができる。ステップ488において、リクエストがユーザAから受信される。ステップ489において、コミットが成功したかどうか、例えば、割り当てられたリソース1及びリソース2に対する支払いが受信されたかどうかが判断される。そうである場合、ステップ490において、システムは、ユーザAにコミットの成功を通知することができ、リソース1及びリソース2を除去するか、又はリソース1及びリソース2の状態(status)をリソースデータベースにおいて更新することができる。ステップ491において、ユーザBは、選択されたリソース3、リソース4、及びリソース5へのコミットをリクエストすることができる。ステップ492では、リクエストがユーザBから受信される。ステップ492では、コミットが成功したかどうかが判断され、例えば、選択されたリソース3、リソース4、及びリソース5に対する支払いが受信された場合、ステップ494で、システムはユーザBにコミットの成功を通知することができ、リソース3、リソース4、及びリソース5は削除されるか、又はリソース3、リソース4、及びリソース5の状態がリソースデータベースで更新される。
図7(A)〜7(D)、図8(E)〜8(G)、図9(H)〜9(I)は、限られたリソースを適応的に最適化するためのユーザインターフェース(UI)の例を示す。図7(A)は、ユーザのプロファイル、現在位置、グループのサイズ(又は人数)、及び好ましい出発時刻に基づいて、おすすめの旅行先のリストを提示する例示的なUI500を示す。一実施例では、それぞれのおすすめが無効化又はリフレッシュされ得るカウントダウンタイマー503、505が表示されてもよい。この例では、ユーザは、迎え時刻が午前11時から午後12時までの間で、4人のワン・ラッフルズ・プレイスから出発する旅行をリクエストしたいと考えている。おすすめの旅行先502、504、506、508のリストが提示される。
図7(B)は、選択可能な旅行のリストを示すUI510の例を示す。この例では、ユーザが目的地としてマリーナベイサンドを選択すると、利用可能な出発時刻512のリストが提示され、そのうちのいくつかはスケジュールされており(scheduled)、いくつかはまだスケジュールされていない。図7(C)は、選択された旅行(出発地がマリーナベイサンド)に基づき得る、おすすめの追加の位置516、518、520を提示する例示的なUI514を示す。図7(D)は、ユーザの選択リストを提示する例示的なUI522を示す。この例では、ユーザによって選択され、ユーザの選択リストに格納された選択された旅行524、526、528、530のリストが提示される。UI522は、コミットの準備が可能な旅行524、競合すると判断された旅行526、528、及び確認のために保留中の旅行530を示している。
図8(E)は、ユーザがリソースの追加の入札(incoming bid)等のおすすめの選択を受け取ったときの例示的なUI532を示す。ユーザは、まだコミットされていないアイテムの追加の入札を受け取ってもよい。このような追加の入札は、ユーザの現在の選択と他の1人のユーザの選択との間で競合が検出されたときに生成されてもよい。この入札において、ユーザは、現在選択されている旅行526から3つの座席を取り消す(release)ようにリクエストされる。さらに、おすすめの代替案534を提示してもよい。ユーザは、現在の選択526を保持し続けることを選択してもよく、又は、現在の選択を、ユーザの要件及び/又は好み(例えば、近くの出発地、及びスケジュールされた時間内)に適合するおすすめの代替案534の1つに変更することを選択してもよい。他の可能性としては、ポイント又は報酬システムが入札プロセスの一部であり、ユーザに提示されてもよい(不図示)。例えば、現在の選択を変更することを選択したユーザには、ロイヤルティポイント等のインセンティブが付与される。
図8(F)は、ユーザが現在利用できないリソースに対してリクエストを行った場合に、現在利用できないリソースに対して、おすすめから外される予定の入札(outgoing bid)を生成する場合のUI536の例を示す。この例では、ユーザは、旅行528内のさらに2つの座席を入札又はリクエストすることを選択することができる。システムは、関連するユーザを識別し、関連するユーザに対するおすすめの選択を決定する。また、システムは、現在利用できない旅行528のユーザへのおすすめの代替案や、例えば、旅行528内の2つの座席を取り消すための関連ユーザへのおすすめの代替案等を生成して、成功率を高めてもよい。同様に、他の可能性としては、ポイント又は報酬システムが入札プロセスの一部としてもよい。例えば、現在の選択を変更することを選択したユーザには、ロイヤルティポイント等のインセンティブが付与される。
図8(G)は、ユーザの選択が制約を満たさない場合のUI540の例を示す。状況によっては、例えば、バスはまだ予定されていない等、制約が満たされていないために旅行530が確認されなくてもよい。システムは、リクエストされたすべての旅行を継続的に監視し、十分な又は最適化された要望が満たされた後、バスが旅行530に割り当てられると、システムは関連するユーザに通知する。そうでなければ、システムは、予定された出発時刻に近いおすすめの代替案542を生成し、提示することができる。
図9(H)は、ユーザの更新された選択リストを提示する例示的なUI542を示す。この例では、旅行526内の3つの座席をリクエストした他の1人のユーザが、システムによっておすすめされる代替の旅行を選択することができるため、受信したリクエストに対する、おすすめから外される予定の入札を取り消すことができる。他の1人のユーザが、旅行528における2つの座席の自分の選択に変更を加えることを望んでいないので、おすすめから外される予定の入札は失敗する可能性がある。旅行530は、十分な需要が満たされている場合に確認され得る。競合/入札/制約が解決され、他の制約違反又は競合が決定されない場合に、各旅行526、528、530の状態は、それに応じてUI542内で更新される。UI542は、これらの旅行524、526、530がコミットする準備ができたことを示す。
図9(I)は、コミットされたリソースの詳細を示すUI544の例を示す。この例では、ユーザは、旅行524へのコミットをリクエストし、コミット及び支払プロセスを進めることができる。一旦支払いが受け取られると、確認が送られ、旅行524の詳細が544のようなUIでユーザに提示される。コミットすると、他のユーザがリソースを選択できなくなる。
図10(A)及び10(B)は、1つの実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。この実施例では、映画館Xで19:00開始の映画のための5つの座席が利用可能である。3人家族のユーザAは、映画館Xで19:00に映画のための3つの座席をリクエストしたい。システムは、5つの空席があることをおすすめし、提示することができる。ユーザAは、図10(A)に示されているように、例えば、座席600a、600b、600cのような、自分の好ましい座席の組み合わせを選択することができる。このような選択は、選択リストモジュールにおいて受け取られ、ステージングされてもよい。4分後、家族4人のユーザBは、映画館で19:00開始の映画のための4つの座席をリクエストすることができる。システムは、5つの座席がまだ利用可能であることをおすすめし、提示することができる(そのうちの3つはステージングされている)。ユーザBは、依然として、図10(A)に示すように、例えば、座席600b、600c、600d、600eのような、自分の好みの座席の組み合わせを選択することができる。このような選択は、選択リストモジュールにおいて受信され、ステージングされてもよい。
両方の選択をチェックして、制約違反又は競合がないかどうかを判断してもよい。この実施の形態では、座席600bと座席600cに2つの重複する座席優先度があるため、座席600bと座席600cの競合が検出される。1つの実施の形態では、ユーザA及びユーザBについて、おすすめの選択及び可能な選択/アクションを決定することができる。例えば、ユーザAが最初に来て、5分間の時間制約に違反していない場合、システムは、ユーザBが、重複する座席がユーザAによって取り消されて利用可能になるかどうかをチェックするために、さらに1分間待機するオプション、又はユーザBに対する、映画の開始時間を20:00に変更するオプションを生成してもよい。ユーザBは、1分間待つというおすすめの選択を受け入れることを示すことができる。ユーザBが次に利用できるようになった場合に、ユーザBに対する座席割り当ての優先順位を上げることができる。
ユーザAは、自身の優先座席の組み合わせにおいて競合が検出されたことを示す通知を受け取ることができる。この通知には、ユーザAに対して、次の1分以内に座席のリクエストをコミットすること、又は20:00の別の座席を検討することを促すリマインダを含めることができる。その後、ユーザAは、さらに選択して、20:00に変更する映画の開始時間を選択し、座席602a、602b、602cを選択する。その後、ユーザBは、自分の優先座席が利用可能であるという通知を受け取ることができる。その後、ユーザAとユーザBの選択リストは、図10(B)に示すように、座席のそれぞれの選択で更新され、ユーザAとユーザBは、必要な支払いを行うことによって、それらの選択と購入をコミットすることができる。
代替的に、別の実施の形態では、そのようなおすすめの選択及び可能な選択/アクションは、映画オペレータがどちらのイベント・タイプをより重要視するかに応じて、異なって提示されてもよい。例えば、ユーザAが最初に来たにもかかわらず、さらに1分間待つようにユーザAにおすすめの選択を提示してもよい。これは、ユーザBがムービーオペレータの特権ユーザ(privileged user)であるためである。同様に、ユーザBが過去に同様の座席の選択/再配置を受け入れたか、又はコミットしたことがあるため、20:00の座席のおすすめの選択をユーザBに提示してもよい。
このようなリソース最適化プロセスは、上述の実施の形態に限定されず、シャトルバス予約サービスのような他のサービスに適用することができることは理解され得る。
図11(A)及び11(B)は、別の実施の形態に係る、限られたリソースを適応的に最適化するためのプロセスを示す概略図である。この実施の形態では、共有ワークスペース(co-working space)に5つのホットデスクが利用可能である。メンバーA、B及びCは、それぞれ共有ワークスペースのデスクを予約することができる。メンバーA、B及びCには、メンバーの特典や好みに応じて適切なデスクがおすすめされてもよい。メンバーA、B及びCは、図11(A)に示すように、それぞれの好ましいデスクを選択することができ、その選択は、選択リストモジュールにステージングされる。すべての選択をチェックして、制約違反又は競合がないかどうかを判断してもよい。この例では、3つの選択の間に競合は検出されなかった。支払いによって予約を確保するため、各メンバーに5分の猶予期間が与えられてもよい。1分後、メンバーDは、同僚と一緒に仕事をするために、より大きなホットデスクスペースを受け取りたいことを示す。メンバーA、B、C、及びDの選択リストに基づいて、ステージングされたデスクのリクエストにおいて競合が検出される。
1つの実施の形態では、メンバーA、B、及びCが最初に来ているため、5分の時間制約に違反しておらず、可能な選択/アクションを決定し、メンバーDに提示して、メンバーDに、より低い価格の2つの別個のデスクを考慮するか、又は4分間待って、新しいスペースが利用可能かどうかを確認するように依頼してもよい。ただし、メンバーDには個別に作業するという制約があり、待機を選択してもよい。同時に、メンバーA、B、及びCに対して、潜在的な収益(potential revenue)を最大化し、リソース使用率を最適化するために、低価格の代替デスクに移動するインセンティブ付きオプションが提示されてもよい。魅力的な低価格により、メンバーB及びCは、移動してもよいと考え、座席700b及び700c等の代替机をそれぞれ選択する。メンバーB及びCの更新された選択を通知する応答メッセージを送信してもよく、次いで、メンバーDに、より大きなホットデスクスペースが利用可能であることを通知し、その後、メンバーDは、座席700d及び700eを選択することができる。メンバーA、B、C、及びDの選択リストは、図11(B)に示すように適宜更新されてもよい。その後、メンバーA、B、C、及びDは、必要な支払を行うことで、選択及び購入をコミットすることができる。
別の実施の形態では、メンバーA、B及びCの選択を受信し、メンバーDの選択を受信する前に、サービス・プロバイダが、より大きなホットデスクのスペースをリクエストする可能性のあるメンバーDのような次のメンバーのために、残りのデスク配置が供給されることを期待又は希望し、2つの連続するデスクの予測需要のような予測入札を決定してもよい。このような予測入札は、デスクの過去のトランザクション(例えば、先月の同じ時間帯のデスク)に基づいて決定することができる。おすすめの選択が、メンバーA、B及びCの予測入札及びプロファイル情報に基づいて、決定及び最適化されてもよい。この例では、代替デスクに移動するオプションをメンバーA、B及びCに提示してもよい。そして、メンバーB及びCが代替デスクに移動し、メンバーD等の次のメンバーのためにより大きなホットデスクのスペースを作成し、リクエストに応じて2つの連続するデスクが利用可能であることを即座に提示してもよい。これにより、ユーザの満足度が向上し、より効率的なリソース利用オペレーションが可能となる。
図12は、図3に示されるシステムを実施するための使用に適したコンピュータシステムの概略図を示す。図12に示すように、例示的なコンピューティングデバイス800は、ソフトウェアルーチンを実行するためのプロセッサ804を備える。明確にするために単一のプロセッサが示されているが、コンピューティングデバイス800はマルチプロセッサシステムを備えてもよい。プロセッサ804は、通信インフラストラクチャ806に接続され、コンピューティングデバイス800の他の構成要素と通信する。通信インフラストラクチャ806は、例えば、通信バス、クロスバー、又はネットワークを含むことができる。
コンピューティングデバイス800は、ランダムアクセスメモリ(RAM)等のメインメモリ808と、二次メモリ810とをさらに含む。二次メモリ810は、例えば、ハードディスクドライブ、ソリッドステートドライブ、又はハイブリッドドライブであり得るストレージ・ドライブ812、及び/又は、磁気テープ・ドライブ、光ディスク・ドライブ、ソリッドステート・ストレージ・ドライブ(USBフラッシュドライブ、フラッシュメモリデバイス、ソリッドステートドライブ、メモリカード等)等を含み得るリムーバブル・ストレージ・ドライブ814を備えてもよい。リムーバブル・ストレージ・ドライブ814は、周知の順序で、リムーバブル記憶媒体818の読み取り及び/又は書き込みを行う。リムーバブル記憶媒体818は、磁気テープ、光ディスク、不揮発性メモリ記憶媒体等を備えてもよく、リムーバブル・ストレージ・ドライブ814によって読み取られ、書き込まれる。当業者には理解されるように、リムーバブル記憶媒体818は、コンピュータ実行可能プログラム・コードの命令及び/又はデータを記憶したコンピュータ読み取り可能記憶媒体を含む。
代替の実施の形態では、二次メモリ810は、コンピュータプログラム又は他の命令をコンピューティングデバイス800にロードすることを可能にする他の同様の手段を追加的又は代替的に含んでもよい。このような手段は、例えば、リムーバル・ストレージ・ユニット822及びインターフェース820を備えてもよい。リムーバル・ストレージ・ユニット822及びインターフェース820の例は、ビデオゲーム機に見られるようなプログラムカートリッジ及びカートリッジインターフェース、リムーバブル・メモリチップ(EPROMやPROM等)及び関連するソケット、リムーバブル・ソリッドステート・ストレージ・ドライブ(USBフラッシュドライブ、フラッシュメモリデバイス、ソリッドステートドライブ、メモリカード等)、並びに、ソフトウェア及びデータがリムーバル・ストレージ・ユニット822からコンピュータシステム800に転送されることを可能にする他のリムーバル・ストレージ・ユニット822及びインターフェース820を含んでもよい。
また、コンピューティングデバイス800は、少なくとも1つの通信インターフェース824を含む。通信インターフェース824は、コンピューティングデバイス800と外部デバイスとの間で通信経路826を介してソフトウェア及びデータを転送することを可能にする。本発明の様々な実施の形態では、通信インターフェース824は、コンピューティングデバイス800と、パブリックデータ(public data)又はプライベートデータ(private data)通信ネットワーク等のデータ通信ネットワークとの間でデータを転送することを可能にする。通信インターフェース824は、異なるコンピューティングデバイス800間でデータを交換するために使用されてもよく、このようなコンピューティングデバイス800は、相互接続されたコンピュータネットワークの一部を形成する。通信インターフェース824の例は、モデム、ネットワークインターフェース(イーサネットカード等)、通信ポート(シリアル、パラレル、プリンタ、GPIB、IEEE 1394、RJ 45、USB等)、関連する回路を有するアンテナ等を含むことができる。通信インターフェース824は、有線であっても無線であってもよい。通信インターフェース824を介して転送されるソフトウェア及びデータは、電子的、電磁的、光学的、又は通信インターフェース824によって受信可能な他の信号であり得る信号の形態である。これらの信号は、通信経路826を介して通信インターフェースに供給される。
図12に示すように、コンピューティングデバイス800は、さらに、関連するディスプレイ830に画像をレンダリングするための動作を実行するディスプレイインターフェース802と、関連するスピーカ834を介してオーディオコンテンツを再生するための動作を実行するオーディオインターフェース832とを含む。
本明細書で使用される場合、「コンピュータプログラム製品」という用語は、部分的に、リムーバブル記憶媒体818、リムーバル・ストレージ・ユニット822、ストレージ・ドライブ812に取り付けられたハードディスク、又は通信経路826(ワイヤレスリンク又はケーブル)を介して通信インターフェース824にソフトウェアを運ぶ搬送波(carrier wave)を意味してもよい。コンピュータ読み取り可能な記憶媒体とは、記録された命令及び/又はデータを実行及び/又は処理のためにコンピューティングデバイス800に提供する任意の非一時的な不揮発性の有形の記憶媒体を指す。このような記憶媒体の例には、磁気テープ、CD−ROM、DVD、Blu−ray(登録商標)ディスク、ハードディスクドライブ、ROM、若しくは集積回路、ソリッドステート・ストレージ・ドライブ(USBフラッシュドライブ、フラッシュメモリデバイス、ソリッドステートドライブ、メモリカード等)、ハイブリッドドライブ、光磁気ディスク、又はPCMCIAカード等のようなコンピュータ読取可能カードが含まれ、これらのデバイスがコンピューティングデバイス800の内部又は外部であるか否かを問わない。コンピューティングデバイス800へソフトウェア、アプリケーション・プログラム、命令及び/又はデータの提供可能な一時的な又は非有形のコンピュータ読み取り可能な伝送媒体の例には、無線又は赤外線伝送チャネル、並びに他のコンピュータ又はネットワーク・デバイスへのネットワーク接続、及び電子メール伝送及びウェブサイト等に記録された情報を含むインターネット又はイントラネットが含まれる。
コンピュータプログラム(「コンピュータ・プログラム・コード」とも称する)は、メインメモリ808及び/又は二次メモリ810に格納される。また、通信インターフェース824を介してコンピュータプログラムを受信することもできる。このようなコンピュータプログラムを実行することにより、コンピューティングデバイス800は、本明細書で説明する実施の形態の1つ以上の特徴を実行することができる。様々な実施の形態において、コンピュータプログラムを実行することにより、プロセッサ804が上述の実施の形態の特徴を実行することを可能にする。したがって、そのようなコンピュータプログラムは、コンピュータシステム800のコントローラを表す。
ソフトウェアは、コンピュータプログラム製品に格納され、コンピュータデバイス800に、リムーバブル・ストレージ・ドライブ814、ストレージ・ドライブ812、又はインターフェース820を使用してロードされてもよい。コンピュータプログラム製品は、非一時的なコンピュータ可読媒体であってもよい。あるいは、コンピュータプログラム製品は、コンピュータシステム800に通信経路826を介してダウンロードされてもよい。ソフトウェアは、プロセッサ804によって実行されると、コンピューティングデバイス800に、図3に示される方法を実行するために必要な動作を実行させる。
図12の実施の形態は、単に例として、システム800の動作及び構造を説明するために提示されることを理解されたい。したがって、いくつかの実施の形態では、コンピューティングデバイス800の1つ以上の特徴を省略することができる。また、いくつかの実施の形態では、コンピューティングデバイス800の1つ又は複数の特徴を一緒に組み合わせることができる。さらに、一部の実施の形態では、コンピューティングデバイス800の1つ以上の特徴は、1つ以上の構成要素の部分に分割されてもよい。
図12に示された要素は、上述の実施の形態で説明したように、サーバの様々な機能及び動作を実行するための手段を提供するように機能することが理解されるであろう。
コンピューティングデバイス800が輸送プロバイダの効率を最適化するように構成されている場合、コンピューティングデバイス800は、実行時にコンピューティングシステム800に、以下のステップを実行させるアプリケーションを格納した非一時的なコンピュータ読み取り可能な媒体を有する:輸送プロバイダによって第1の位置において管理される車両の第1の出発時刻を受信するステップ;第1の位置の後に位置する第2の位置における車両の第2の出発時間を受け取るステップ;第1の出発時刻と第2の出発時刻との差を測定するステップ;その差分の決定に応答して、現在のスケジュールを更新し、第2の位置の後の位置における車両の更新された推定到着時間を示す更新されたスケジュールを提供するステップ。
多岐にわたり説明された本発明の精神又は範囲から逸脱することなく、特定の実施の形態に示されるように、本発明に多数の変形及び/又は修正を行うことができることは、当業者には理解されるであろう。したがって、本実施の形態は、全ての点で例示的であり、限定的ではないと考えるべきである。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
(付記1)
第1のユーザ及び第2のユーザを含む複数のユーザに対して、限られたリソースを適応的に最適化する方法であって、
前記第1のユーザから、前記限られたリソースの第1の選択であって、前記第1のユーザが前記限られたリソースをどのように使用したいかを示す前記第1の選択を受け取るステップと、
前記第1の選択と、前記第2のユーザからの第2の選択であって、前記第2のユーザが前記限られたリソースをどのように使用したいかを示す前記第2の選択とを比較するステップと、及び
前記第1の選択と前記第2の選択との比較に基づいて、前記限られたリソースのおすすめの選択であって、前記限られたリソースがどのように最もよく利用されるかを示す前記おすすめの選択を決定するステップと、
を備える、方法。
(付記2)
前記限られたリソースの前記おすすめの選択を決定するステップは、
前記限られたリソースの利用に関する少なくとも1つのパラメータであって、前記限られたリソースの量、時間情報、及び位置情報を含む前記少なくとも1つのパラメータを検索するステップと、及び
前記少なくとも1つのパラメータに基づいて選択するリソースを決定するステップと、
を備える、付記1に記載の方法。
(付記3)
前記限られたリソースの前記おすすめの選択を決定するステップは、さらに、
前記限られたリソースに関するさらなる選択であって、複数のユーザのうちの1人によってなされる前記さらなる選択を受信するステップと、及び
前記さらなる選択と前記おすすめの選択を比較して、競合があるかどうかを判断するステップと、
を備える、付記1又は2に記載の方法。
(付記4)
前記第1の選択を受け取ることに応答して、可能な選択であって、対応するインセンティブ及びトレードオフをそれぞれ有する前記可能な選択のリストを決定するステップと、及び
前記第1の選択を含む前記可能な選択のリストを前記第1のユーザに提示するステップと、
をさらに備える、付記1〜3のいずれか1つに記載の方法。
(付記5)
前記おすすめの選択に関するイベント・タイプであって、前記おすすめの選択が使用されるイベントの重要度を示す前記イベント・タイプを検索するステップをさらに備える、付記1〜4のいずれか1つに記載の方法。
(付記6)
前記第1のユーザ及び前記第2のユーザのそれぞれに関するプロファイル情報であって、トランザクション履歴情報の1つを含むプロファイル情報を検索するステップをさらに備える、付記1〜5のいずれか1つに記載の方法。
(付記7)
前記限られたリソースの前記おすすめの選択を決定するステップは、前記少なくとも1つのパラメータ、イベント・タイプ、プロファイル情報、及び前記複数のユーザのうちの少なくとも1人から受信される可能性が高い予測入札(forecast bid)のうちの少なくとも1つに基づいて、前記おすすめの選択を最適化するステップをさらに含む、付記2〜6のいずれか1つに記載の方法。
(付記8)
前記第1のユーザ及び前記第2のユーザの少なくとも一方に前記おすすめの選択を提示するステップと、及び
前記第1のユーザ及び前記第2のユーザの少なくとも一方から、前記おすすめの選択の提示に応答する応答メッセージを受信するステップと、
をさらに備える、付記7に記載の方法。
(付記9)
前記限られたリソースの前記おすすめの選択を決定するステップは、前記応答メッセージに基づいて前記おすすめの選択を更新するステップを含む、付記8に記載の方法。
(付記10)
前記限られたリソースの利用に応じて、前記限られたリソースの利用可能性に関するデータベースを更新するステップをさらに備える、付記1〜9のいずれか1つに記載の方法。
(付記11)
第1のユーザと第2のユーザとを含む複数のユーザに対して、限られたリソースを適応的に最適化する装置であって、
少なくとも1つのプロセッサと、及び
コンピュータ・プログラム・コードを含む少なくとも1つのメモリと、
を備え、
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第1のユーザから、前記限られたリソースの第1の選択であって、前記第1のユーザが前記限られたリソースをどのように使用したいかを示す前記第1の選択を受け取ること、
前記第1の選択と、前記第2のユーザからの第2の選択であって、前記第2のユーザが前記限られたリソースをどのように使用したいかを示す前記第2の選択とを比較することと、及び
前記第1の選択と前記第2の選択との比較に基づいて、前記限られたリソースのおすすめの選択であって、前記限られたリソースがどのように最もよく利用されるかを示す前記おすすめの選択を決定すること、
を少なくとも実行させるように構成されている、装置。
(付記12)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記限られたリソースの利用に関する少なくとも1つのパラメータであって、前記限られたリソースの量、時間情報、及び位置情報を含む前記少なくとも1つのパラメータを検索すること、及び
前記少なくとも1つのパラメータに基づいて選択するリソースを決定すること、
を実行させるようにさらに構成されている、付記11に記載の装置。
(付記13)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記限られたリソースに関するさらなる選択であって、複数のユーザのうちの1人によってなされる前記さらなる選択を受信すること、及び
前記さらなる選択と前記おすすめの選択を比較して、競合があるかどうかを判断すること、
を実行させるようにさらに構成されている、付記11又は12に記載の装置。
(付記14)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第1の選択を受け取ることに応答して、可能な選択であって、対応するインセンティブ及びトレードオフをそれぞれ有する前記可能な選択のリストを決定すること、及び
前記第1の選択を含む前記可能な選択のリストを前記第1のユーザに提示すること、
を実行させるようにさらに構成されている、付記11〜13のいずれか1つに記載の装置。
(付記15)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記おすすめの選択に関するイベント・タイプであって、前記おすすめの選択が使用されるイベントの重要度を示す前記イベント・タイプを検索すること、
を実行させるようにさらに構成されている、付記11〜14のいずれか1つに記載の装置。
(付記16)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第1のユーザ及び前記第2のユーザのそれぞれに関するプロファイル情報であって、トランザクション履歴情報の1つを含むプロファイル情報を検索すること、
を実行させるようにさらに構成されている、付記11〜15のいずれか1つに記載の装置。
(付記17)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記少なくとも1つのパラメータ、イベント・タイプ、プロファイル情報、及び前記複数のユーザのうちの少なくとも1人から受信される可能性が高い予測入札(forecast bid)のうちの少なくとも1つに基づいて、前記おすすめの選択を最適化すること、
を実行させるようにさらに構成されている、付記12〜16のいずれか1つに記載の装置。
(付記18)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記第1のユーザ及び前記第2のユーザの少なくとも一方に前記おすすめの選択を提示すること、及び
前記第1のユーザ及び前記第2のユーザの少なくとも一方から、前記おすすめの選択の提示に応答する応答メッセージを受信すること、
を実行させるようにさらに構成されている、付記17に記載の装置。
(付記19)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記応答メッセージに基づいて前記おすすめの選択を更新すること、
を実行させるようにさらに構成されている、付記18に記載の装置。
(付記20)
少なくとも1つの前記プロセッサを用いて、少なくとも1つの前記メモリと前記コンピュータ・プログラム・コードとは、前記装置に、
前記限られたリソースの利用に応じて、前記限られたリソースの利用可能性に関するデータベースを更新すること、
を実行させるようにさらに構成されている、付記11〜19のいずれか1つに記載の装置。

Claims (10)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
SG10202004134W 2020-05-05
SG10202004134WA SG10202004134WA (en) 2020-05-05 2020-05-05 Method and apparatus for adaptively optimizing a limited resource

Publications (1)

Publication Number Publication Date
JP2021177379A true JP2021177379A (ja) 2021-11-11

Family

ID=78409533

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021075051A Pending JP2021177379A (ja) 2020-05-05 2021-04-27 限られたリソースを適応的に最適化する方法及び装置

Country Status (2)

Country Link
JP (1) JP2021177379A (ja)
SG (1) SG10202004134WA (ja)

Also Published As

Publication number Publication date
SG10202004134WA (en) 2021-12-30

Similar Documents

Publication Publication Date Title
CN101404624B (zh) 对媒体项目的下载进行优先级排序的系统和方法
US8744919B1 (en) Systems and methods for retail networking
US20170098197A1 (en) Systems and Methods for Automatically Collecting User Data and Making a Real-World Action for a User
US10567521B2 (en) System and method for cloud computing on-demand dynamic service management engine
US7356481B2 (en) Delivery management method and device, and delivery information service method
US20170220957A1 (en) Restaurant reservation and table management system and method
US8484244B2 (en) Forecasting an availability of a media content item
US20180336611A1 (en) Network system with scheduled breaks
US20120150683A1 (en) Automatic selection at a self-service dispensing device
CN109684092A (zh) 资源分配方法及装置
US20170186112A1 (en) End to end user device platform
US10803419B2 (en) Stock management for electronic transactions
JP2021177379A (ja) 限られたリソースを適応的に最適化する方法及び装置
US10762550B2 (en) Contextual service systems and methods
CN111562991A (zh) 用于基于网络的服务的情景通知
US20140156320A1 (en) Pricing and managing access rights in a venue
JP5726949B2 (ja) 予約システム
JP6829670B2 (ja) リソース管理サーバ、および、リソース管理方法
US20210174295A1 (en) Systems and methods for user selection of wearable items for next shipment in electronic clothing subscription platform
US20210398238A1 (en) Systems and Methods for Destination Shipment Consolidation
US11089440B1 (en) Management of geographically and temporarily distributed services
JP5296301B2 (ja) 予約システム
He Service-level based response by assignment and order processing for warehouse automation
JP2019021012A (ja) 車用部品提供システム
KR20150003952A (ko) 컨텐츠 추천 시스템 및 방법