JP2024016272A - イベントを企画する方法及びシステム - Google Patents

Abstract

【課題】種々の産業の問題に適応されうるイベントを計画する方法及びシステムを提供する。
【解決手段】方法は、入手可能なセッション及び施設の情報を収集し、プレビューセッションに基づくランカーの選択情報を収集し、セッションのユーティリティランキングを決定し、コンピュータにより少なくともセッションのユーティリティランキング及び後続の施設ランキングに基づきイベントスケジュールを生成し、出席者及び他の興味ある団体にイベントスケジュールを電子的に送信する。イベントスケジュールは、新たな又は変更されたセッション、施設、ランカー情報及び／又は出席者情報に応じて変更することができる。
【選択図】図１

Description

本開示は、イベントの企画の分野に関し、特に、イベントを企画するためのコンピュータ実装方法及びシステムに関する。

この出願は、２０１８年１１月１日に出願された米国出願番号６２／７５４３２８の、米国特許法第１１９条（ｅ）に基づく優先的な利益を主張し、その全部を参照により本明細書に援用する。

イベント産業は、大きく、多くの人々に影響を与える。プライスウォーターハウスクーパースによる最近の調査では、米国においてだけで、２０１２年に２７５，０００以上の人がカンファレンス及びイベントに参加した（また、２８００億ドルがこれらのイベントで費やされた）と調べられた。ミーティング及びイベント産業は、米国のＧＤＰに航空輸送及び映画産業よりも大きく影響すると推定される。専門の会員及びライセンス機関は、たびたび、各年の最低の学習時間を求め、それはカンファレンスへの出席で満たすことができる。追加として、特定の分野及び専門のイベントは、有益な人脈作りの機会を供給する。これらのイベントに参加する人々は、彼らの資金に対し最高の価値を得ることを保証することを望み、運営する人々は、経済的価値を提供することを望む。

これまでの数十年、イベント計画の複雑なタスクでプランナーを支援する多数の電子化されたツールをみてきた。しかしながら、これらの解決策は、イベントがどのように機能するかのダイナミクスを根本的に変えるのではなく、主に、既存の及び基礎のプロセスのスピードを向上させるように設計されている。特に、既知の計画ツールは、イベントのスケジュール、及び、セッション及び部屋の配置をイベントの前に設定する必要があることを前提とする。

イベントの計画を支援する最近の方法は、イベントの前にイベントのスケジュール、予算、スピーカーリスト、及び他の情報を設定することに重点をおいている。イベントの前のスケジュールの設定には、必然的に、イベントの前のスケジュールの対応するセッションのために部屋も予約する必要があり、効率を向上させるために、カンファレンスのアクティビティにより占めるスペースは調べられない。カンファレンスが始まるよりも前にスペースが選択されるため、各セッションにどれだけのスペースが必要とされるかは通常、群衆の「ベストの推測」の予測に基づく。しかしながら、広く参加するカンファレンスのために借りられるスペースは、会議の最大の費用の１つである。

カンファレンスの出席が、予期せずセッションを選択する可能性があり、これらのセッションの部屋がいっぱいにならないようにするため、事前に部屋を予約することによる不確実な本質的な要求に対する対応として、イベントの計画においてスペースのオーバーブッキングを行う。例えば、カンファレンスが最大で３００のチケットを販売し、同時に発生する３つの分科会がある場合、それぞれ収容人数が１５０人である３室を予約するかもしれない。これは、出席者がどのセッションに参加することを選択したとしても、最低で合計１５０席が空席となるが、レンタルされ料金も維持される。

室内スペースのオーバーブッキングの問題に対するために設計されたある解決策に、カンファレンスの日のかなり前に、出席者の分科会の選択を確認しようとする試みある。しかしながら、出席者の回答は、例えば、いずれも少ない数の応答であったり、スペースの予約が過ぎてからの回答である等、通常、事前のスペースのオーバーブッキングの標準の手順を修正するのに不十分である。

加えて、問題は、個々が、継続教育の要件を満たす為にカンファレンスを申し込んだが、セッション又は講演者を毛嫌いしたためにセッションをスキップ又は早めに離れることがある。

そのため、イベントを計画する際の効率性及び有効性の向上が必要である。

施設の使用方法と効率性及び有効性を向上するため、様々な他の産業でも同様のニーズがある。例えば、ヘルスケア産業では、先進国の多くの病院及びヘルスケア施設で、手動入力、コミュニケーション及びスタッフによる見積を含むペン及び紙又はスプレッドシート形式のスケジューリングを依然として使用している。これは、リアルタイムの情報が含まれないこと、救急医療を促進し、過誤訴訟から保護するために、スペースとリソースのバッファを維持する必要があること、及び、スケジューリング情報のソースが一元化されていないことを意味する。これは、十分に活用されていない、医療事故及び人命の損失につながる可能性がある。２０１６年、米国の平均的な病院の利用率は６５．５％に過ぎず、それは、いつでも施設の３４．５％が未使用のままであったことを意味する。これは、一般人が受けている医療の緊急の必要性にもかかわらず。毎年、米国での医療過誤の被害を防ぎ、かつ最小限にするため、５５６億ドルが費やされる。そのため、迅速、効率的、かつダイナミックに、リアルタイムの情報に基づいて患者のスケジューリングを割り当て、統一されたシステム内の全てのユーザに患者のスケジュールを通知できるシステムが必要である。

これは、スペースをリース又は賃貸したい企業の場合も同様である。モール又は小売店及び商業施設等の開発は、たびたび、それらのスペースを早急に賃貸し、長い期間空室にしないことを望む１つの開発会社によって開発される。現在、これらの不動産の保有及び／又は管理会社は、数千社ある。それらは、しばしば、経営範囲において、広大な土地及び財産を管理しているため、さまざまなスペースに効率的及び迅速にテナントを適合させる必要がある。同様に、チェーン又はフランチャイズ会社は、しばしば、参入する新しい地域市場を特定し、特定の要求に適合するその市場のスペースを探す。これは、しばしば、「遠方の」本社からであり、彼らにとってなじみのない町のスペースを誰かにみてもらうにはコストがかかることがある。オーナー及びテナントの両者のゴールは、全ての要求を考慮し、オーナーの土地及び／又は財産の合計とそれらのリスケジュールを考慮して、リースをリスケジュールすることにより、より少ない全費用でより効率的に達成できる。したがって、また、テナントをスペースに効率的かつ迅速にマッチさせる必要がある。

航空業界では、航空会社は、オフシーズンに大幅な未使用容量を運ぶことが多い。航空会社の運営費が高いため、これは大きな利益損失を引き起こす。これまでの１０年だけでも、航空会社の記録破りの破産が複数発生しており（例えば、トーマスクック）、容量と発券を一致させることができないことが最も強く関係している。相殺のため、航空会社は、しばしば「オンシーズン」でのキャンセル率及びダブルブッキングを予測し、予測が間違っていた場合、リスケジュール及びカスタマーサービスアクションのコストがさらに高くなる。

現在、航空件は、顧客によって直接予約され、その顧客は直接、先着順で、フライト、航空会社、及び、座席までも選択する。これは、数千ものオプションを比較する際には、一般的な顧客に混乱及びストレスを発生させる。複雑なプロセスを相殺するため、多くの航空会社及び発券サービスは、複雑な金融アルゴリズムを用いて、常に需要に基づいて、チケットの価格を変更することにより、実際にはユーザエクスペリエンスをさらに複雑にする。これは、本質的に危険な航空業界の、収入減の相殺の試みようとするものであるが、スケジュール、容量、及び真の需要に関する情報を曇らせることで、ユーザエクスペリエンスをさらに複雑化し、ダブルブッキング、キャンセル、過剰定員及び定員割れを継続させる。これの全過程は、航空会社及び顧客のコストを増加させ、また、顧客のフラストレーションをもたらす。したがって、航空券の販売のより簡略化された方法の提供が必要であり、それは、限られた選択で容量を需要にさらに効果的にマッチさせることができ、かつ、顧客に必要な労力を削減する。

学校のシステムに関し、それが高校又は大学であろうが、利用される登録システムは、しばしば、特定のクラスの需要の予測に基づく。多くの学校は、未だに、主に手動入力され、職員による手動計算によって動作される登録システムが利用される。これらの要因により、意味のある規模のほぼ全ての学校は、学期の最初の数週間に大きな負担を経験し、学生が最小プログラム要件を満たし、時間通りに卒業することを保証するために、緊急変更の大規模な複合体を手動でスケジュールに加える必要がある。現在のシステムによってこれらの要求が満たされないことが多いだけでなく、このプロセスの後でさえ、かなりの人数の学生及び職員が次の学期のスケジュールに不満を持つ。したがって、スケジュールを再調整し、学生が卒業するために必要なコースを持っていない状況に対処するというコスト及び時間の係る作業を回避するため、学校の管理者によって利用され、学生により大きな満足を与え、最低卒業要件を満たすスケジュールを学校の初日より前に、効率的かつ効果的に提供することのできるシステムを供給する必要がある。

様々な産業で生じるスケジューリング方法又は施設とセッションのリンクは、複雑、コスト及び時間がかかる、かつ、非効率的で、また、しばしば、最終的にそれを使用する人にとって不十分なスケジュールを提供する。現在の方法は、通常、ユーザの特定の要望やニーズの予測に基づいて、スケジュールが特定のパラメータ内に完全に収まるようにすることに重点をおいている。しかしながら、これは解決するのが非常に複雑な問題であり、また、規定及び予測のみに基づくとき、大きな追加の努力と比較して、ほとんど付加価値が得られないことがよくある。したがって、スケジュールを効率的、効果的及びタイムリーに生成し、また、エンドユーザ及びイベントコーディネーターをより満足させ、情報やパラメータの変更に応じて更新できるシステムが必要である。

イベントを計画するための方法とシステムがここに提供される。いくつかの実施形態では、以下を含む、イベントを計画するためのコンピュータ実装方法が提供される。少なくとも２のセッション及び施設の、セッション及び施設の情報を収集する。
少なくとも１のプレビューセッションに基づいて、ランカーからランキング情報を受信する。
少なくとも一部は、ランキング情報に基づく、少なくとも２のセッションのユーティリティランキングを決定する。
スケジューリングのためのセッションを選択する。
選択したセッションにリンクするための施設を仮に選択する。
仮に選択した施設に選択したセッションをリンクする。
リンクされたセッションと施設を利用可能なイベント時間帯にスケジューリングする。
すべてのセッションが施設にリンクされ、イベント時間帯にスケジューリングされるまで、セッションを選択するステップを繰り返す。
イベントスケジュールを生成する。
少なくとも１の出席者または主催者にイベントスケジュールを送信する。

いくつかの実施形態では、以下を含む、イベントを計画するコンピュータ実装方法が提供される。
少なくとも２のセッション及び施設の、セッション及び施設の情報を収集する。
少なくとも１のプレビューセッションに基づいて、ランカーからランキング情報を受信する。
少なくとも一部はランキング情報に基づく、少なくとも２のセッションのユーティリティランキングを決定する。
スケジューリングのためのセッションを選択する。
選択したセッションにリンクするための施設を仮に選択する。
仮に選択した施設に選択したセッションをリンクする。
リンクされたセッションと施設を利用可能なイベント時間帯にスケジュールリングする。
スケジューリングされていない同時時間帯があるかどうかを判断し、そうであるとき、スケジュール用の同時セッションを選択する。
スケジュールされていない同時時間帯がなくなるまで、施設を仮に選択して、スケジュールされていない同時時間帯があるかどうかを判断するステップを繰り返す。
すべてのセッションが施設にリンクされ、イベント時間帯にスケジュールされるまで、以降のスケジューリングのためにセッションを選択するステップを繰り返す。
イベントスケジュールを生成する。
少なくとも１の出席者または主催者にイベントスケジュールを送信する。

いくつかの実施形態では、以下のステップを実行するように構成された少なくとも１のプロセッサを含むシステムが提供される。
少なくとも２のセッション及び施設の、セッション及び施設の情報を収集する。
少なくとも１のプレビューセッションに基づいて、ランカーからランキング情報を受信する。
ランキング情報に少なくとも部分的に基づく、少なくとも２のセッションのユーティリティランキングを決定する。
スケジューリングのためのセッションを選択する。
選択したセッションにリンクするための施設を仮に選択する。
仮に選択した施設に選択したセッションをリンクする。
リンクされたセッションと施設を利用可能なイベント時間帯にスケジューリングする。
すべてのセッションが施設にリンクされ、イベント時間帯にスケジューリングされるまで、セッションを選択するステップを繰り返す。
イベントスケジュールを生成する。
少なくとも１の出席者または主催者にイベント スケジュールを送信する。

いくつかの実施形態では、以下のステップを実行するように構成された少なくとも１のプロセッサを含むシステムが提供される。
少なくとも２のセッション及び施設の、セッション及び施設情報を収集する。
少なくとも１のプレビューセッションに基づいて、ランカーからランキング情報を受信する。
少なくとも一部はランキング情報に基づく、少なくとも２のセッションのユーティリティランキングを決定する。
スケジューリングのためのセッションを選択する。
選択したセッションにリンクするための施設を仮に選択する。
選択したセッションを仮に選択した施設にリンクする。
リンクされたセッションと施設を利用可能なイベント時間帯にスケジュールする。
スケジュールされていない同時時間帯があるかどうかを判断し、スケジュールされている場合はスケジュール用の同時セッションを選択する。
スケジュールされていない同時時間帯がなくなるまで、施設を仮に選択して、スケジュールされていない同時時間帯があるかどうかを判断するステップを繰り返す。
すべてのセッションが施設にリンクされ、イベント時間帯にスケジュールされるまで、以降のスケジュールリングのためにセッションを選択するステップを繰り返す。
イベントスケジュールを生成する。
少なくとも１の出席者または主催者にイベント スケジュールを送信する。

いくつかの実施形態では、スケジュールされた同時セッションに参加することが予測されたセッションの最低ランキングを有するセッションのサブセットが識別され、選択された同時セッションは、ユーティリティランキングが最も高いこのサブセット内のセッションであり得る。

いくつかの実施形態では、選択されたセッションは、残りのうちで最高のユーティリティランキングのセッションである。

いくつかの実施形態では、ユーティリティランキングは、ランキング情報に適用される変更係数にも基づく。

いくつかの実施形態では、変更係数は少なくとも次数の変更を含み、他の実施形態では変更は少なくとも前提条件の変更を含む。

いくつかの実施形態では、仮に選択された施設は、残りの最高ランクの施設であり、セッション要件ランキング、施設ランキング、またはその両方に基づいて決定できる。

いくつかの実施形態は、選択されたセッションを仮に選択された施設にリンクする前に、コンフリクトを解決することをさらに含む。

いくつかの実施形態は、セッション、施設、またはランキング情報への追加または変更に基づいて生成されたスケジュールを修正すること、および修正されたスケジュールを少なくとも１人の出席者又は主催者に送信することをさらに含む。

いくつかの実施形態では、スケジュールに選択できるセッションを変更するためにバッファ定数が適用される。

いくつかの実施形態は、少なくとも１人の出席者にスケジュールされたイベントを送信する前に、生成されたイベントスケジュールを承認することをさらに含む。

いくつかの実施形態において、イベントスケジュールは、少なくとも１人の出席者または主催者に電子的に送信される。

いくつかの実施形態は、講演者をランク付けする出席者またはランカーを含むことができる、少なくとも１人のランカーまたは出席者からセッション後のフィードバックを受信することをさらに含む。いくつかの実施形態では、セッション後のフィードバックは、講演者の金銭的報酬を決定するための基礎の一部として利用できる。

いくつかの実施形態では、本明細書に記載の方法のいずれかの実行中に収集された情報の一部またはすべてが、別のイベントを開発するために使用される。

いくつかの実施形態では、１のセッションが最大の施設の収容人数を超えると予想されるイベントを計画する、以下を含むコンピュータ実装方法が提供される。
少なくとも２のセッション及び施設の、セッション及び施設の情報を収集する。
少なくとも１のプレビューセッションに基づいて、ランカーからランキング情報を受信する。
少なくとも一部はランキング情報に基づく、少なくとも２のセッションのユーティリティランキングを決定する。
スケジューリングのためのセッションを選択する。
選択したセッションの出席者数を予測する。
選択したセッションにリンクするための施設を仮に選択する。
選択したセッションを仮に選択した施設にリンクする。
リンクされたセッションと施設を利用可能なイベント時間帯にスケジュールする。
選択されたセッションの出席者の超過が予測されるかどうかを判定する。
スケジュールされていない同時時間帯があるかどうか判定し、スケジュールするための同時セッションを選択する。このとき、以前に選択されたセッションに出席者数の超過が予測されているとき、予測された超過の出席者数と同等の推定プルアウェイ数を持つ同時セッションが選択される。
選択されたセッションでの出席者数を予測するステップを繰り返して、スケジュールされていない同時時間帯を判定し、スケジュールされていない同時時間帯がなくなるまで、同時セッションを選択する。
すべてのセッションが施設にリンクされ、イベントの時間帯にスケジュールされるまで、以降のスケジュールを設定するためのセッションを選択するステップを繰り返す。
イベントスケジュールを生成する。
少なくとも１人の出席者または主催者にイベント スケジュールを送信する。

大まかに言うと、いくつかの実施形態では、イベントを計画するためのシステムが提供される。システムは、少なくとも１のプロセッサ、少なくとも１のプロセッサに接続され、少なくともセッション情報および施設情報を含むイベント情報を受信および記憶し、プロセッサによって実行されると、少なくともユーティリティランキング、セッション情報及び施設情報であるイベント情報に基づいてプロセッサにイベントスケジュールを生成させる命令を格納するデータベース、及び、イベントスケジュールを公開する機能を備えるデータベースと通信するネットワークインターフェースを含む。

本方法およびシステムのいくつかの潜在的利点は、それが全体的なイベントの満足度を向上することである。

大まかに言うと、いくつかの実施形態では、イベントを計画する方法がここに提供される。方法は、少なくとも１のイベント情報の収集、イベント情報のデータベースへの記憶、関心のあるイベント情報の選択、及び、関心のある選択されたイベント情報に少なくとも一部に基づく、第２のイベントの開発を含む。

他のイベントの開発でイベント情報のデータベースを使用する利点の１つは、フィードバック及び／又は出席に基づいて出席者をグループ化することに基づき、これらの新しいイベントがさまざまな出席者グループに対応できることである。他の利点は、これらの新しいイベントが、イベント情報に基づいてより魅力的な方法で構成されることである。イベント情報のレビューに基づいて将来のイベントでセッションを選択すると、出席者にとってより魅力的なセッションのリストが作成される可能性がある。

図１は、一般的なイベントを計画する方法の実施形態の図である。 図２は、イベントの計画の方法にどちらが最適化を決定する方法の図である。 図３は、イベント実施形態に係るイベントスケジュールを生成する方法の図である。 図４は、図３の詳細図であり、コンフリクトを解決する第１の方法を示す。 図５は、図３の詳細図であり、コンフリクトを解決する第２の方法を示す。 図６は、１のセッションが最大の施設の収容人数を上回る出席者数が予想された、イベントスケジュールの生成する実施形態を示す図である。 図６は、１のセッションが最大の施設の収容人数を上回る出席者数が予想された、イベントスケジュールの生成する実施形態を示す図である。 図７Ａは、セッションの出席者数の予想の方法を示す。 図７Ｂは、セッションの出席者数の予想の方法を示す。 図８は、イベントを計画する方法を実行するコンピュータシステムの図である。 図９は、イベントスケジュールの生成及び方法の簡素化された方法を示す図である。 図１０は、セッションのユーティリティランキングを決定する際にセッションのランキングを変更する際の変更係数の使用の一例である。

以下の説明において、開示された主題の様々な側面の十分な理解を提供するため、特定の具体的詳細を説明する。しかしながら、開示された主題は、これらの具体的詳細がなくても実施しうる。

文脈上の他の意味に解釈すべき場合を除き、後述の明細書及び請求の範囲を通して、「含む」及び「含んでいる」等の変形の用語は、広義で、包括的な意味で、すなわち、「含むが、これに限定されない」と解釈されるべきである。

明細書の全体を通して、「一実施形態」又は「いくつかの実施形態」への言及は、実施形態に関連して説明される特定の特徴、構造、または特性が少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書中の様々な箇所における「一実施形態において」又は「いくつかの実施形態において」の表現は、必ずしも全てが同じ側面を示すとは限らない。さらに、本開示の１又は複数の態様において、特定の特徴、構造または特性を任意の適切な方法で組み合わせることができる。

本説明及び添付の特許請求の範囲の目的のため、特に明記されていない限り、量、数量、時間帯、パーセンテージなどの全ての数字は、いかなる場合も、「約」というという用語により修飾されていると理解されるべきである。また、全ての範囲は、開示される最大点及び最小点の任意の組み合わせを含み、本明細書に具体的に列挙される又はされない中間の範囲を含みうる。

本説明及び添付の特許請求の範囲の目的のため、「１の」の用語は、１又は少なくとも１を含むと解釈されるべきであり、他の意味があることが明らかでない限り、単数形は、複数形も含む。これは、単に便宜上、また、本発明の一般的な意味を与えるために行われる。

１又は複数の施設を１又は複数のセッションとリンクしてイベントスケジュールを生成し、最適なモデルを用いてそれらを時間帯にスケジューリングする方法及びシステムが開示される。一般的な方法及びシステムを以下に詳細に説明し、続いて、種々の実施形態と、方法及びシステムをどのように実施できるかの例をさらに説明する。

ここで開示される一般的な方法は、少なくとも２つのセッションに関する情報に基づいて、「セッションの集計されたランキング」（ここでは、多くは「ユーティリティランキング」といわれる）の判定及び利用に依存する。いくつかの実施形態では、個々のランキングへの変更係数の適用は、集計の前に発生することができ、別の実施形態では、個々のランキングへの変更係数は、集計の後に生じ得る。いくつかの実施形態では、セッションの出席者は１人のみであり、したがって、ユーティリティランキングは直接その出席者にリンクする。

ユーティリティランキングは、例えば、最も多くの出席者に最大の満足をもたらすことによって、イベント全体に対するセッションの重要性又は有用性を示すことを目的とする。単に出席者の全体的な好みを示すものではなく、単にセッションに参加したい人の人数又はセッションの人気ランキングを示すことを目的とするのではない。むしろ、ユーティリティランキングは、イベント全体での要求と必要性を示し、また、最も価値のある出席者の最大数を最も満足させる主催者の要求を示すことを目的とする。例えば、方法及びシステムは、できるだけ多くの出席者に理想的な（上位にランク付けされたセッションにできるだけ多く参加できるような）スケジュールを提供することを目的とする。より具体的には、理想のスケジュールは、各出席者に対して最も高くランク付けされたセッションのリストを指し（彼らのランキング及び彼らのために行われた又は彼らのために行われたランキングの変更の両方を考慮する）、前記セッションの数は、それらセッションの時間に関係なく、各出席者がイベントのコースで出席可能な時間帯の数と同一であり、セッションの性質の要求がある場合を除き、相対的順序であり、したがって、出席者がイベントに参加する意思を暗示し又は伝えたことを除く。

図１を参照すると、ステップ１０１において、施設の情報は、コンピュータに記憶される。いくつかの実施形態では、情報は、収容人数、サイズ、タイプ及び施設の機能性等の複数の施設の特性を含みうる。ここで、施設は、出席者が特定の時間にスケジュールされる場所を意味するのに対し、会場の用語は、イベントでリンクすることのできる全ての施設を含む又は包含する。例えば、医療の例では、施設は治療が行われる部屋であり、会場は施設がある全ての病院及び他の医療の場所を含む。

いくつかの実施形態では、スケジューリングに利用可能なイベントの時間帯も、ステップ１０１でコンピュータに記憶されうる。いくつかの実施形態では、イベントの時間帯は、例えば、固定の継続時間を有するカンファレンス、又は、学期の開始及び終了のある学校に利用されるとき、固定のスケジュールでありうる。いくつかの実施形態では、例えば、病院、航空会社、及びテーマパーク等の継続的に運営される産業で使用されるとき、イベントの時間帯は、無期限である。

ステップ１０１で、また、セッション情報が記憶されうる。例えば、主催者は、また、例えば、特定の施設の要件及び／又は施設の好みを含む特定のセッションの設定パラメータを意味する、セッション情報、を入力しうる。このセッション情報は、ランキングのセットを通じて定義され、ここでは「要件ランキング」とする。

スケジュールの生成に先立ち、利用可能な各セッションに関するプレビュー情報とともに、ランカーに提供するプレビューがある。プレビューを見た後、ランカーは、利用可能なセッションのランキングを送信することができる。ランカーは、主催者であっても、出席者であっても、又はプレビューを見る他の関係者であっても良い。ステップＳ１０２において、コンピュータは、ランカーの選択情報を受信する。

いくつかの実施形態で、ランカーから提供されるランキングは、ランカーに関連する特定の変数にしたがって、例えば、特定の会員の保有、保有する特定のステータス、又は他の同等の特性等に基づいて、変更されてもよい。

ランカーからのランキング情報と、変更係数を組み合わせて、ここではユーティリティランキング１０９といわれる、全体的なセッションランキングを決定する。例えば、航空会社及びテーマパークのアプリケーションで、別の例として、１人の出席者が１のセッションに出席可能であるとき、ランカーにより提供されたランキングは、変更を条件として、ユーティリティランキング１０９であるランキングと等しい。また別の例として、複数の出席者が１のセッションに出席可能であるとき、各ランカーに送信されたランキングを合計して、変更を条件としてユーティリティランキング１０９を決定する。セッションのユーティリティランキングは、次にスケジュールするべきセッションの決定に利用することができる。

全てのランキング、施設及びセッションの情報が記憶及び受信されると、ステップ１０３において、イベントスケジュールが生成される。

スケジュールを設定するため、セッション及び施設をリンクさせ、かつ、時間帯又は時間ブロックに割り当てる必要がある。複数の時間帯又は時間ブロックが同時にあり、ここでは、同時時間帯又は時間ブロック、又は、連続した時間帯又は時間ブロックという。

施設とセッションのリンクに利用するプロセスは、「最良適合」方法といわれる。いくつかの実施形態では、最良適合方法は、「ベストトゥーベスト」として表すことができ、いくつかの実施形態では、最良適合方法は、「ベストトゥーザベストオブザワーストオブベスト」と表すことができる。

図２を参照すると、利用可能なイベントの時間帯毎の出席者の選択肢の数に基づいて、使用する最適適合方法を決定するプロセスの例が提供される。システムは、出席者がイベントの間に出席可能な全てのセッションの数（または、イベントの時間列の数）（Ａ）１４０及びセッションの合計数（Ｂ）１４２を決定する。Ｂ／Ａの割合が決定され、各出席者が１の時間列で参加しなければならないオプションの数を表す。例えば、６の時間列及び合計１８のセッションがあるとき、各出席者は、そのイベントに参加すると仮定し、各時間列に３のセッションを選択する。

各出席者の時間列毎の数の選択肢の数が少ない場合、ベストトゥーベストの方法を利用して最も望ましいセッションに参加できる可能性は低い。代わりに、行毎のセッションの数が多いとき、出席者は、彼らが関心あるセッションを特定し、出席できる可能性が高くなる。

図２において、Ｘは、方法が適用される特定の状況又は業界に基づいて決定される定数を表す。例えば、その方法が学校で利用されるとき、出席者（学生）が３のクラス（セッション）を有するとき、それらから選択できるのは、ベストトゥーベストの方法を使用して多数の学生を満足させるには少ない可能性があるのに対し、４のクラスの選択肢があれば、ベストトゥーベストの方法から選択するので十分となりうる。したがって、このケースＸでは、ベストは４に設定するのが好ましい。Ｂ／Ａの割合がＸの値より大きいとき１４４、ベストトゥーベストの方法１４６を使用しうる。Ｂ／Ａの割合がＸの値より大きくないとき１４８、ベストトゥーベストオブワーストオブベストの方法が使用されうる１５０。

一般に、時間列毎のセッションの数が大きいほど、優先されるベストトゥーベストの方法である可能性が高くなる。対照に、時間列毎のセッションの数が１に近いほど、好ましい最良適合方法がベストトゥーザベストオブザワーストオブベストである可能性が高くなる。いくつかの実施形態では、両方の最良適合方法が実行されるべきであり、最終的なスケジュールは主催者によって決定されるべきだろう。いくつかの実施形態では、全体的な方法が、連続して複数回実行され、１回は、ベストトゥーベストの方法を利用し、別のときは、ベストトゥーベストオブワーストオブベストを利用する。

ユーティリティランキングからスケジュールを生成するため、いくつかの実施形態では、施設にリンクさせる第１のセッションは、ユーティリティランキングが最も高いものである。セッション及び施設に関してリンクする用語は、セッション及び施設を合わせてスケジューリング又は組み合わせるプロセスに関する。リンクは、イベントの全体的なスケジュール内で発生し、セッション及び施設は、特定の時間帯にリンクされる。ここで、時間帯は、時間ブロック、期間等の用語に置き換えうる。

施設も同様にランクされることができるが、施設のランキングは、最もユーティリティが高いセッションの要件ランキングに基づく。要件ランキングは、セッションをそのセッションに最も適した施設に一致させるために利用される。参照されたセッションに関して、最も高い施設のランキングの施設が選択される。セッション及び施設の第１のリンクでは、同時セッションが存在しないため、したがって、出席者のコンフリクトはなく、したがって、ユーティリティランキングが最も高いセッションが最高のランクの施設にリンクされ、時間帯にスケジュールされる。

スケジュールすべき他のセッションがあるとき、方法は、ａ）ベストトゥーベストの方法を使用するとき、残りの全てのスケジュールされていないセッション、または、ｂ）ベストトゥーベストオブザワーストオブベストの方法を使用するとき、スケジュールされていないセッションの特定のサブセット、の最も高いユーティリティランキングを持つセッションの識別を続ける。このプロセスについては、図３～７を参照して、以下でさらに説明する。

一度全てのセッションがスケジュールされると、コンピュータは、ドラフトイベントスケジュール生成することができる１０３。ステップ１０４でドラフトイベントスケジュールの承認がない場合、最終的なイベントスケジュールが公開される１０８。

ステップ１０４で承認が要求されたとき、コンピュータで生成されたイベントスケジュールはイベント主催者に送信され１０５、出席者又は相手方に送信される前にレビューされる。いくつかの実施形態では、ステップ１０６でドラフトイベントスケジュールの承認がされない場合があり、最終的なイベントスケジュールを出席者及び相手方に送信する前に、ドラフトイベントスケジュールが変更されてもよい。変更は、イベント主催者により、前に考慮された情報を提供、削除又は修正し、又は考慮すべき追加の要素を選択し１０７、選択された全ての要素を考慮した新しいイベントスケジュールをコンピュータに生成させることにより、手動でしてもよい

いくつかの実施形態では、ステップ１０６でドラフトスケジュールの承認がされ、その後、最終的なイベントスケジュールが公開される１０８。

ここでは、最終的なイベントスケジュールは、出席者及び相手方に送信されるイベントスケジュールである。イベントスケジュールの他のバージョンは、ドラフトイベントスケジュールといわれることがある。加えて、「イベントスケジュール」は、一般的に最終的なイベントスケジュール又はドラフトイベントスケジュールといわれることがある。

一度イベントスケジュールが生成されると、又は、承認の要求があり、イベント主催者によって承認されると、最終的なイベントスケジュールが公開される１０８。いくつかの実施形態では、公開１０８は、出席者及び相手方への最終的なイベントスケジュールの送信でありうる。これは、例えば、イベントアプリケーション、イベントウェブサイト又はイベント電子メールコミュニケーションを介してワイアレスにイベントスケジュールが送信されることで成しうる。いくつかの実施形態では、イベントスケジュールは、例えば、ホスト、講演者、主催者、建物マネージャ、スタッフマネージャ、イベントコーディネーター、スポンサー、ボランティア及び／又はサービス提供者、又は、これらの人々の組み合わせからなるグループ等、イベントに関与する他の個人、イベントスケジュールを求める者又は必要な者に送信される。

イベントスケジュールを生成するために評価された係数を再考することが適切な方法に任意のステップで、それらの係数を変更することができる。例えば、追加の検討を受信した後１０７、又は、最終的なイベントスケジュールが公開された後１０８、イベント主催者は、イベントスケジュールを生成されるために考慮された係数を修正することができ、修正されたイベントスケジュールが生成される。

いくつかの実施形態では、イベントの間に情報が追加され、更新され又は変更されることでイベントスケジュールを修正するため、有用又は必要である１１０。いくつかの実施形態では、関係者全員に新しく、更新されたスケジュールを提供するため、例えば、新しい出席者及びランキング情報が保存され、及び／又は、新しいセッションのスケジュールが必要である等により、情報が変更又は追加されると、スケジュールは定期的又は不定期的な間隔で、又はリアルタイムで更新される。したがって、最終的なイベントスケジュールは、イベント中に、講演者がイベントに出席できなくなった、施設が使用できなくなった、出席者から新しいランキング情報を受信した（例えば、イベントに遅れた出席者又は出席者の選択情報がテクニカルエラーによってもともと送信されない）、リソースの予定外の減少の発生（すなわち、コンピュータリソース）、会場又はスタッフが正常に機能することを妨げる緊急事態、追加のセッションの要求、事前にスケジュールされたセッション、セッション、出席者（又は予測される出席者）及び／又は施設、又はそれらの組み合わせに関する新たな又は更新された情報、等の複数の要因に基づいて適合しうる又は変更されうると考えられる。

イベント中にイベントスケジュールを変更する必要があるとき、新たな又は変更された要因を追加又は変更することができ、コンピュータで生成された変更された最終的なイベントスケジュールは、前述した方法と同一の方法を使用して生成することができる。この変更された最終的なイベントスケジュールは、ワイヤレスで出席者及び／又は関係する他の個人、又は、イベントスケジュールを知りたい又は知る必要がある者に送信することができる。

情報が追加され、更新され又は変更されないとき、スケジュールは変更されない１１２。

いくつかの実施形態では、最終的なスケジュールが公開された後に情報が追加され、変更され又は更新されると１１０、スケジュールの変更について出席者及び相手方に知らせるための十分な時間のため、バッファ定数を組み込むことができる。より具体的には、バッファ定数は、スケジュールの変更が行われるまえに、現在時刻から開始して、スケジュールで経過しなければならない時間を反映する可能性がある、又は、反映される可能性のある数値である。いくつかの実施形態では、バッファ定数は、全てのセッションで同一でありうる。いくつかの実施形態では、バッファ定数は、セッション毎又は異なるタイプのセッション毎に、異なる値であり得る。例えば、情報を受信した、ユーティリティランキングの高い新たなセッションがあるとき、現在のスケジュールが変更される可能性がある。しかしながら、新たなセッションは、直ちに調整されない。新たなセッションが調整されるまでの、バッファ定数で表される最小の期間がある。一例では、バッファ定数が１時間に設定され、最も高いユーティリティランキングの新たなリクエストが午前１０時に入力されたとき、セッションは午前１１時よりも早くはスケジュールで施設にリンクされない。

これらの計算は、コンピュータープログラム及びシステムによって行われると期待される。これは、特に、より複雑でかつ、より多くの出席者、施設、セッション、プレビュー及びランキングがかかわるイベントを扱う場合に重要である。タイムリーかつ使用可能なスケジュールを生成及び配布し、変数のいずれかに変更が加えられた場合に更新するため、この方法はコンピュータシステムで実行されうる。

図３を参照し、セッションのプレビューの後５１０、セッションはランカーによってランク付けされる５２０。いくつかの実施形態では、これらのランキングは、ユーティリティランキング５３０と同一である。いくつかの実施形態では、セッションランキング５１０は、ユーティリティセッションランキング５３０の決定の前に、変更される。設定された可能性のあるバッファ変数５５０を考慮して、残りの最高ランキングのセッション５４０が選択される。次に、セッション要件ランキング５７０及び施設ランキング５８０を考慮し、選択されたセッションに関して最高のランクの施設が識別される５６０。施設が仮に特定されると、システムは可能性のあるコンフリクトを特定する５９０。コンフリクトがないとき、セッションはスケジュールされ、又は、施設にリンクされる６００。コンフリクトがあると特定されると、セッションがスケジュールされる、又は、特定の時間帯で施設６００にリンクされる前に、それらは解決される６１０。ステップ６２０でスケジュールすべきセッションがなくなると、必要な承認を条件として（図示せず）、スケジュールが公開される６３０。一方、セッションが残っているとき、ステップ５４０のプロセスに戻る。

ベストトゥーベストの方法では、５４０で選択された第１のセッションは、全体として最もランクの高いセッションである。全体として最もランクの高いセッションがスケジュールされると６００、５４０でリンクされる又はスケジュールされるために選択される次のセッションは、全体として２番目にランクの高いセッション（残りの全体的に最も高いランクのセッションともいわれる）である。ベストトゥーベストの方法では、５４０で選択された次のセッションが、常に、残りの全体的に最も高いランクのセッションである。

図４及び５は、図３の詳細図であり、ステップ６１０におけるコンフリクトがどのように解決されるかの例を示す。図３乃至５を参照して後述するように、残りの施設はリンクされるセッションのランキング要件に基づいてランク付けされ、最も高いランクの施設が決定される。このセッション及び施設の組み合わせは、時間帯の中で仮にリンクされ、又は、スケジュールされる。次に、仮にリンクされたセッションと同時に実行される、又は、重なるセッションがあるセッションがあるか判定される。あるアプリケーションでは、出席者が出席可能な少なくとも１の同時セッションがあると予想される（例えば、カンファレンスでは、出席者が理論的に出席できる特定の時間列に複数のセッションがスケジュールされている可能性がある）。出席者が同時セッションを利用することが可能であるとき、ランキングに基づいて出席者の理論的なコンフリクトの可能性の分析が判定される。より具体的には、コンフリクトは、出席者が同時に行われる２つのセッションへの出席の希望が予想されるときに発生しうる。

コンフリクトが検出されたとき、仮のリンクは考慮されず、同じセッションが次に上位の施設に仮にリンクされる。これは、セッションと施設の組み合わせと、仮のセッションと施設とリンクの間でコンフリクトがなくなるまで発生し、その時点でリンクは仮でなくなり、セッションはその施設のスケジュールとなる。または、コンフリクトすることなく同時セッションをスケジュールすることができないとき、コンフリクトが最も少ないセッションをスケジュールしうる。

例えば、次にランキングの高いセッションが選択されて施設にリンクされるとき、システムは、その施設が利用可能な残りの時間ブロックでセッションを仮にスケジュールしうる。この時間ブロック内で前述のセッションが他の既にスケジュールされているセッションと同時に実行されることがわかったとき、システムは、コンフリクトをチェックする。いくつかの実施形態では、コンフリクトをチェックするための１の方法は、スケジュールされる特定のセッションを識別することで、すでにスケジュールされていて、現在のセッションで考慮されている仮の時間ブロックまで同時に実行されるセッションと同様に、ランカーおよび/または出席者の理想的なスケジュールを参照して、これらのセッションの２以上が、１の出席者／ランカーの理想的なスケジュールに表示されるかを判定する。理想的なスケジュールに複数のセッションが表示される出席者／ランカーの数は、特定のセッションをこの時間ブロック及び施設に配置するとコンフリクトが発生する出席者／ランカーの数である。これは、例えば、コンフリクト番号が指定された施設と時間ブロックで指定されたセッションであるとして記録しうる。いくつかの実施形態では、コンフリクトについて、前記組み合わせがチェックされる毎に、施設、セッション及び時間ブロックの各仮のリンクに対してコンフリクト番号を記録しうる。コンフリクトが発生しない状況を満たすことができないいくつかの実施形態では、記録されたコンフリクト番号を利用して、仮のリンク処理の間に、最も小さい数のコンフリクト番号を生成したセッションへの時間ブロックのリンクを決定し、これを選択し、時間ブロック、施設、セッションの組み合わせ、及び、完全なプロセスを完了する前にスケジュールを設定する。

特定の実施形態では、システムは、リンクされた施設で利用可能な時間ブロックをチェックするように設定でき、コンフリクトを生成しない時間ブロックがなかったとき、この時点でコンフリクト番号が最も小さい時間ブロック、施設及びセッションのリンクを選択するように設定しうる。他の実施形態では、システムは、この時点でリンクされた施設を破棄し６５０、セッションに関して次に高いランクの施設を選択し５６０、前記施設の利用可能な全ての時間ブロックにおけるコンフリクトをチェックするように指示することができる。他の実施形態では、システムは、考慮されたオプションのコンフリクトが最も少ないリンクされたセッション、施設、および時間ブロックのスケジュールに進む前に、これらのオプションのいずれかがコンフリクトを生じないシナリオを生成するかどうかを判定するために、リンクされたセッションを破棄し６７０、前記セッションの最高ランクの施設にリンクし、この施設との利用可能な時間ブロックのすべてのコンフリクトをチェックする等のために、次に最も高いランキングのセッションを判定する５４０。

いくつかの実施形態では、仮にスケジュールされた同時セッションと、以前にスケジュールされたセッションと施設の組との間でコンフリクトがステップ５９０で特定されたとき、次に、ステップ５６０で以前に特定された仮にスケジュールされた施設であって、５９０でコンフリクトが特定されたものとは異なる時間列の他の時間帯に対してチェックされる。コンフリクトしない時間帯があるとき、仮にリンクされたセッションと施設は、その時間帯にスケジュールされる（図示せず）。しかしながら、コンフリクトしない時間帯がない場合、システムは、スケジュールに空きがある他の施設があるか否かを特定する。ある場合、仮に選択された施設は破棄され６５０、５６０で、次に高いランクの施設が選択される。ステップ５９０でコンフリクトがないとき、その施設に対して、セッションがスケジュールされる６００。

いくつかの実施形態では、例えば、図５で示すように、スケジュールのその時間帯で利用可能な他の施設がないとき、システムは、スケジュールする必要があるその時間帯にセッションが残っているか判定する６６０。セッションが残っているとき、ステップ５４０で前に選択されたセッションは破棄され６７０、次にランキングの高い残りのセッション５４０が選択される。ステップ６００でこれ以上セッションが残っていないとき、コンフリクトが最も少ない最高ランクのセッションが選択され６８０、スケジュールされる６００。

ベストトゥーベストの方法は、例えば、不動産、航空会社、及び多くの医療の状況等、セッション毎に１人の出席者がいる場合、又は、大学等の特定の時間に１人の出席者が出席できるよりもはるかに多くのセッション数がある場合のアプリケーションに好ましい。このような場合、コンフリクトが生じた場合、コンフリクトのある出席者は、自分のコンフリクトと同時に参加したいセッションをさらに多く持つ可能性がある。この事実と、ベストトゥーベストのスケジュールが最も重要なセッションの全体を（コンフリクトを考慮して）、２番目に重要なセッションの全体にスケジュールしたという事実と組み合わせて、スケジュール全体にとって最も重要なセッションの全体は常に最良のスペース及び時間を提供する。

ベストトゥーザベストオブザワーストオブベストの方法に関して、全体として最も高いランキングのセッションが選択され、スケジュールされた後、同時セッションがスケジュールされる。これを行うため、ランクの最も高いセッションに出席すると予想される全ての出席者のサブセットが判定され、このサブセット内でランクの最も低いセッションが判定される。セッションの識別されたランキングの低いグループのユーティリティランキングが決定され、このサブセットのグループ内でランクが全体のランクが最も高いセッションが選択され（したがって、ベストオブザワーストオブベスト）、最初のスケジュールされたセッションと同時にスケジュールされる。

通常、ベストトゥーザベストオブザワーストオブベストの方法は、特定の時間に少数のセッションがスケジュールされていて、出席者が特定の時間列の中にセッションの選択肢が少ないときに好ましい。

場合によっては、高いランキングのセッションの予想の出席者は、利用可能な最大の施設の収容人数を超える場合があると予想される。この場合、全体的な満足度を向上させるためには、同時セッションは、ザベストオブザワーストオブザベストであるべきではない。しかしながら、いくつかの実施形態では、定員超過の変更は、ベストトゥーザベストオブワーストオブベスト方法に適用される。定員超過の変更では、高いランキングの定員超過セッションを最大の施設でスケジュールすることができる（ただし、高い関心を示した全ての出席者が、最高のランキングのセッションに参加できるとは限らない）。施設の収容人数の数は、予定の出席者数からささしひかれ、その結果、目標数が得られ、これは予測定員超過数ともいわれる。同時セッションは、少なくとも目標の出席者数（定員超過のセッションへの出席に関心を示した出席者のサブセットからの）が出席希望としてランク付けされたセッションである可能性がある。いくつかの実施形態では、少なくとも目標人数の人を引きつけるために、複数のセッションが予測される場合がある。これらの実施形態では、全体のランキングが最も高いセッションが同時セッションとしてスケジュールされる。いくつかの実施形態では、組み合わされたときに、目標数にできるだけ近く引き込むために、利用可能な複数の同時時間帯が存在する可能性がある。いくつかの実施形態では、組み合わされたときに、少なくとも目標数を引き込むために利用可能な複数の同時時間帯が存在する可能性がある。

定員超過の変更の例を図６に示す。図７に関し、後述するように、最も高い残りのセッションが選択され７１０、そのセッションのへの出席が予測７２０され、推定される。

ステップ７３０では、７２０で識別された出席者数よりも大きな収容人数を持つ利用可能な時間帯を有する施設があるか判定される。そうであるとき、利用可能な最高のランクの時間帯が決定され、その施設にセッションがスケジュールされる７４０。ステップ７５０で、時間列が埋まっているか判定される。そうであるとき、その方法はステップ８２０に進み、全てのセッションがスケジュールされたか判定される。そうでないとき、プロセスは、ステップ７１０に戻る。時間列が埋まっていない時、同時の非競合セッションは、ベストトゥーザベストオブザワーストベスト方法を使用して選択される必要がある７６０。

ステップ７７０でシステムは、ステップ７４０で以前にスケジュールされたセッションに出席すると予測された出席者が残りのスケジュールされてないセッションをどのようにランク付けしたか考慮し、そのサブセット内のどのセッションが最低ランクであるか判定する７８０。サブセットに最低ランクのセッションが１以上あるとき７９０、システムは、どれが最高のユーティリティランキングを持つか判定する８００。そのセッションが選択される８１０。ステップ７９０で識別されたセッションが１以上ないとき、最低ランクのセッションが選択される８１０。ステップ７２０，７３０，７４０及び７５０が繰り返され、参照しやすいように、７２０ａ，７３０ａ，７４０ａ及び７５０ａとラベル付けされる。７５０ａで時間列が埋まっていないとき、プロセスはステップ７６０に戻る。７５０ａで時間列が埋まっているとき、システムは、全てのセッションがスケジュールされているか判定する８２０。全てのセッションがスケジュールされているとき８２０、スケジュールが生成され９００、前述したように、全ての出席者及び他の関係者に送信することができる。全てのセッションがスケジュールされていないとき８２０、プロセスはステップ７１０に戻る。

ステップ７３０で予測出席者数よりも収容人数が大きい空き時間帯を有する利用可能な施設がないとき、収容人数と空き時間帯が最も近い施設が選択される８３０。時間列が埋まっているとき８４０、プロセスはステップ８２０に移動し、全てのセッションがスケジュールされたか判定する。されていないとき、方法はステップ７１０に戻る。時間列が埋まっていないとき、同時競合セッションを選択する必要がある８５０。７２０で予測又は推定された出席者数から施設の収容人数を引いた数が、推定プルアウェイ数を決定する８６０。ステップ８７０で、プルアウェイ数に最も近い別のセッションに参加すると予想される出席者の数が判定され、ステップ８８０で選択される。上述したように、選択されたセッションへの出席が予測される７２０ａ。出席者数以上の収容人数の時間列に利用可能な施設がないとき７３０ａ、所定の列の収容人数に関して最も一致する施設が判定され８３０ａ、選択される８３１ａ。上述したように、列がその後、埋まっているか否か判定される８４０ａ。そうであり、全てのセッションがスケジュールされているとき８２０、スケジュールが生成され９００、上述したように、出席者及び他の関係者に送信することができる。全てのセッションがスケジュールされていないとき、方法は、ステップ７１０に戻る。

いくつかの実施形態では、ランカー及び出席者は、同じ人であってもよく、また、いくつかの実施形態では、ランカー及び出席者は、異なる人であってもよい。いくつかの実施形態では、出席者は、ランキングを提供しなくてもよい。また、ランカーは、社会的又はその他の理由により、出席したいセッションを変更する、又は、別のセッションに出席することが予想される。したがって、場合によっては、ランキングに基づいて、ランカーが出席することを示したセッションと、そのセッションへの出席との間に正確な相関関係がないことが予想される。

いくつかの実施形態では、この方法は、セッションへの出席を予測するさらなるステップを含むことができ、その例を図７ａに示す。ランカーの数および出席者の数の比較１２０が異なるとき、出席者の予測が生じうる。いくつかの実施形態では、主催者は、予想出席者数が推定される前に、必要とされる可能性のあるパーセンテージの差を設定しうる。

特に、出席者の少なくとも１０％がランキング情報を提供しているとき、ランキングを投票とみなし、推定によって出席者の何％がランカーであるかを決定することが好ましい１２２。このパーセンテージが分かれば、システムは、パーセンテージが一定であると仮定し、出席者の合計数を推定する１２４。例えば、１０００人がイベントに出席し、ランカーが１００人であり、３０人がセッションＡを理想的なセッションとしてランク付けしているイベントに出席した場合、セッションＡの推定出席者は、全ての出席者の３０％（又は３００人）となる。

ランカーの数が出席者の数以上であるとき、システムは、選択肢が与えられると、ランカーが各時間帯でより高くランク付けされたセッションに参加することを選択すると想定する。

いくつかの実施形態では、セッションへの出席は、図７ｂに示すように推定することができる。出席者数を見積もるために、システムは、１人の出席者が出席することができるイベント中に利用可能な時間帯の長さを判定する１２８。いくつかの実施形態では、時間帯の数が指定される。いくつかの実施形態では、時間帯の数は指定されない。時間帯の数が指定されないとき、出席者が参加することができるセッションの最大数は、イベントで予定されている時間帯の最大数と等しいと想定される場合がある。次に、システムは、各出席者の理論上の理想的なスケジュールを決定する１３０。各出席者の理想的なスケジュールが決定されると、システムは、セッションが出席者の全ての理想的なスケジュールに現れる回数をカウントする１３２。これにより、各セッションの推定出席者数が提供される。

ここでは、予測出席者数又は出席者は、推定出席者数又は出席者ということができる。

いくつかの実施形態では、出席者選択のフィードバックを受信する前に、イベントの前のスケジュールを生成することができないが、他の実施形態では、仮のイベントの前のスケジュールを生成することができる。

いくつかの実施形態では、主催者は出席者及び／又はランカーからセッションに関するセッション後のフィードバックを受信することができる。例えば、セッション後のフィードバックは、講演されたトピック、講演者（また、インストラクター又は他の同様の者）、セッションの経験、セッションに出席した後の出席者の満足度又は出席者にとって役立つ可能性のある他のコメントについてのフィードバックを含むことができる。

いくつかの実施形態では、イベントの主催者は、セッション及び／又は講演者の選択情報、セッション及び／又は講演者のフィードバック情報、出席者情報、セッション後のフィードック及び、イベント又はイベントの講演者（又はインストラクター又は他の同様な者）に関して、イベントの前、間又は後に収集された、又は、ここで開示する方法を通して収集された、他のフィードバック又は情報の任意の組み合わせ又は全てを含むデータベースを生成することができる。この「イベント情報」は、コンピュータシステムのデータベースに保存することができる。

イベントの主催者又は他の関係者は、イベントの開発に関連するイベント情報を選択し、データベースに記憶される選択されたイベント情報を用いて他のイベントを生成することができる。例えば、イベントの主催者が、以前、又は、第１のイベントのサブトピックに対応するイベントを生成したいとき、イベントの主催者は、そのサブトピックに関連するイベント情報を確認でき、そのサブトピック内又はサブトピック外に、出席者が関心を持つ共通のテーマや又は分野があるか確認でき、また、そのサブグループの出席者の関心に特化したイベントを生成する。別の例として、イベントの主催者は、イベント情報を確認し、特定のタイプのセッションが人気又は不人気であるか、又は、大量の肯定的又は否定的なフィードバックを受け取ったことを特定し、イベント主催者は次のイベントを構成して、セッションのタイプを最大化することができ、その後、イベントの主催者は、好評であってセッションのタイプを最大化するために、次のイベントを構成することができる。同様に、イベント情報を用いて、セッション後のより肯定的なフィードバックを受信したトレンド又は講演者の可能性があるトピックを選択することができる。イベントの主催者は、イベント情報を確認して別のイベントを生成する際に、これらの要素又は他の関心のある要素のいずれか又は全てを考慮することができる。

いくつかの実施形態では、イベント情報は、会員プログラムとして利用しうる。他の実施形態では、イベント情報を利用して、イベントで収集された情報の分析を向上し、そのようなイベントに関連する全ての関係者の満足度を継続して向上することができる。

いくつかの実施形態では、「イベント情報」は、後のイベントの生成に用いるために収集され、かつ、データベース記憶された複数のイベントからの情報を含むことができる。

図８を参照すると、本明細書に開示されるイベントを計画する方法を実行するために使用できるシステムが提供される。システム３００は、データベース３０２、少なくとも１つのプロセッサ３０４、ユーザーインターフェース３０６、およびネットワークインターフェース３１２を含むことができる。データベース３０２は、プロセッサ３０４によって処理される情報を受け取り、保存する。例えば、データベース３０２は、施設情報、セッションおよび／または講演者選択フィードバック、セッションおよび/またはスピーカーフィードバック情報、セッション後フィードバック情報、ランカー情報、セッション情報、出席者情報、イベントスケジュールを生成する際に考慮されるとみなされる他の要因に関する情報、イベントスケジュール、および/または、将来の分析で使用される可能性のあるイベントおよびイベントスケジュールに関連するその他の情報等の、イベント情報（又は要因）を受信及び記憶することができる。システム３００は、ネットワークインターフェースを介してイベント主催者３１４または出席者アプリケーション３０８から、またはユーザーインターフェース３０６を介してイベント主催者３１４から情報をワイアレスで受信しうる。

データベース３０２は、少なくとも１つのプロセッサに接続され、その中に命令が記憶された、少なくとも１つのプロセッサによって実行されると、イベント情報に基づいてプロセッサにイベントスケジュールを生成させる。イベント情報は少なくともセッションおよび／または講演者の選択に関するフィードバック及び施設情報である。

ユーザーインターフェース３０６は、イベント主催者３１４によって（例えば、マウス、キーボードまたはタッチスクリーン等のユーザー入力デバイス、およびシステム３００に接続されたディスプレイを介して）使用され、データベース３０２に記憶されるイベント情報を入力することができる。ユーザーインターフェース３０６および／またはネットワークインターフェース３１２を使用して、イベントスケジュールを生成するときに考慮される要因（イベント情報）を選択、追加、削除、又は、修正又は他の変更をすることもできる。

少なくとも１つのプロセッサ３０４は、少なくともセッションおよび／または講演者の選択フィードバックおよび施設情報を収集し、イベントスケジュールを生成するために、ここに記載の方法を実行する。イベントスケジュールが生成されると、必要に応じて、承認のために有線接続（図示せず）又はワイヤレスで、ネットワークインターフェース３１２を介して、イベント主催者３１４に電子的に送信することができ、またはイベント主催者３１４は、ユーザーインターフェース ３０６を介して、イベントスケジュールを承認することができる。

最終的なイベントスケジュールを公開または再公開するために、システム３００は、イベントスケジュールを少なくとも１人の出席者または主催者に電子的に送信することができる。いくつかの実施形態では、イベントスケジュールは、少なくとも１人の出席者または主催者に、ネットワークインターフェース３１２ を介して、席者、主催者、および／
またはイベントスケジュールに関連する他の関係者が形態型電子デバイスまたはコンピュータでアクセスできるアプリケーション３０８にワイヤレスで送信することができる。他の実施形態では、生成されたイベントスケジュールをイベント主催者３１４に送信してイベントおよび/またはイベントのウェブサイトまたはフォーラムに投稿し、イベントのウェブサイト、フォーラム、またはネットワークインターフェース３１２を介してイベントで使用される出席者との他の通信手段を通じて直接公開することにより３１６、最終的なイベントスケジュールをさらにまたは代わりに公開することができる３１６。

この方法およびシステムを様々な業界でどのように使用できるかの非限定的な例を以下に提供する。

＜カンファレンス＞
図９は、カンファレンスに適用できる開示された方法の実施形態を提供する。さらに、以下の表１は、一般的な方法で説明されている役割を果たすことができる当事者の例を示す。

イベントを計画するための方法およびシステムがここに提供される。いくつかの実施形態では、主催者は、イベントで利用可能な部屋のリストをその仕様とともに収集し、プレビュー セッションを通じて、イベント出席者を各セッションの講演者に公開し、参加予定のセッションに関する出席者からの情報を収集し、少なくとも一部は、出席者と利用可能な部屋から提供された選択のフィードバックに基づくスケジュールを作成する。

図１をステップ１０１で参照すると、イベント主催者は、例えば、サイズ、デザイン、電子機能、および様々なレイアウトでの出席者の収容人数等の利用可能な部屋に関する情報を収集し、その情報を電子形式で記憶しうる。イベント主催者は、登録済みまたは出席予定の出席者数に基づいて、ホストサイトからイベント用の会議室をリクエストしうる。

いくつかの実施形態では、主催者は、スケジューリングのタイプを固定スケジュールとして識別することもできる。いくつかの実施形態では、固定スケジュールは、会議の長さ、または状況に適した他の任意の期間である。

イベントセッションが始まる前に、出席者はプレビューセッションにおいてイベントスピーカーに公開される。一般的に、プレビューセッションは、講演者がセッションで取り上げる予定の主要なアイデアについての短いスピーチを出席者に提供するように設計されている。これは、たとえば、各講演者がイベントのオープニングまたはプレビューセッションに出席し、出席者にトピックまたはプレゼンテーションの短い要約を続けて提供することによって行われる。代替の実施形態では、プレビューセッションでは、イベントへの到着前に、又は、イベント自体にアクセスすることにより、イベントの開始前に、各スピーカーが作成したビデオへのアクセスを介して、出席者がイベントスピーカーに公開される場合がある。あるいは、プレビューセッションには、イベントの前に利用可能な直接プレゼンテーションとビデオクリップの組み合わせを含みうる。

「イベントに先立って」発生する活動に関して、これは、以下に定義されるように、最終的なイベントスケジュールにおける最初のセッションの開始までの任意の時間を含むことが意図されている。本発明の目的のために、イベント主催者によって計画または提供されるプレビューセッションは、イベントの前に行われると見なされる。さらに、1つのカンファレンス内に複数のプレビューセッションが存在する場合があり、プレビューセッションの各グループとその結果の最終的なイベントスケジュールは、まとめて「イベント」と呼ばれる。したがって、カンファレンス、シンポジウム、会議などに、たとえば各日に１回等の複数のプレビューセッションと複数の最終スケジュールがあるとき、そのカンファレンス、シンポジウム、会議などは複数のイベントを含むという。

ここで使用される「スピーカー」または「講演者」という用語は、ここでは交換可能に使用され、イベントでプレゼンテーションを行う、パネルを主導または参加する、またはその他の方法で実行する、又は、イベントの特定のセッションで資料を発表することに関与する者を指すことを意図する。たとえば、スピーカーまたは講演者には、セッションの議長、ホスト、ワークショップのファシリテーター、コーチ、アクティビティガイド、アクティビティ コーディネーター、エンターテイメント コーディネーター、パフォーマンスアーティスト、インタビュイー、ジャーナリスト、又は類似の者などが含まれうる。

ステップ１０２において、イベント主催者は、出席者が参加したいセッションについての入力を出席者から電子的に受信する。出席者は、この選択情報または選択フィードバックを、イベントで提供される投票ブースで、イベントアプリケーションまたはイベントWebサイトを介したオンラインで、イベント主催者から送信されたアンケートに記入することによって、またはその他の電子メールによる方法など、さまざまな方法で提供することができ、有線又は無線のいずれであっても、少なくとも一部のプレビューセッションに基づいて、出席者がどのセッションに参加することに関心を持っていたか、イベント主催者にタイムリーに通知される。

いくつかの実施形態では、出席者は、プレビュー セッションで説明されているプレゼンテーションまたはセッションを、好みの順序で評価したり、完全なプレゼンテーションまたはセッションに参加することへの関心のレベルを示したりすることもできる。いくつかの実施形態では、出席者は、イベントへの参加または特定のセッションへの参加に対するクレジットを受け取るために、選択のフィードバックをイベント主催者に提供する必要がある。

選択のフィードバック情報は、コンピュータによって受信され、まとめて収集され、コンピュータが生成するイベントスケジュールを生成するために利用される。ステップ１０３において、出席者の選択のフィードバックおよび空室状況を考慮した最良適合モデルに少なくとも部分的に基づいて、イベントのスケジュールがコンピュータによって生成される。これには、予約済みのイベントスペースの効率的な使用を考慮しながら、最大数の出席者が、彼らにとって最も関心のあるセッションの最大数に参加できるという利点がある。

いくつかの実施形態では、スケジュールに関連する他の要因も、例えば、出席者によって提供されるセッションランキング、優先出席者のセッション選択へ与えられた追加の重み、講演者のスケジュール、セッションの一般的なトピック、一部のセッションが特定の順序で行われる必要があるかどうか、部屋間の距離、特定の個人がセッション時間または休憩時間を同時にまたは重複して持つことの許可、イベント出席者またはそのサブセットアクセス可能性、または、スポンサー付きコンテンツ又はスポンサーまたは他のグループによるデモンストレーションへの参加等のいずれか又は組み合わせ等のスケジュールに関する他の要因を考慮しうる。いくつかの実施形態では、ランカーによって提供されるランキングを変更することができる１０９。カンファレンスの場合、変更は出席者のステータスに関連することができ、ＶＩＰタイプのステータスを持つ出席者は、ランキングに所定の係数を掛けることができる。

いくつかの実施形態では、セッションの要件ランキングには、例えば、施設がワークショップの手配でセットアップされなければならない、またはプロジェクターがなければならないなどの厳しい要件が含まれうる。

この情報が提供されると、各セッションの個々のユーティリティランキングが決定され、最も高いユーティリティランキングセッションがスケジューリング用に選択される。要件ランキングによって提供されるパラメータに適合する最高ランクの施設が識別される。たとえば、セッションにプロジェクターが必要な場合、プロジェクターのある施設のみが考慮される。

最高ランクの適切な施設を特定すると、セッションと施設がリンクされる。その後、すべてのセッションと施設がスケジュールされるまで、プロセスは前述のように続行さる。

いくつかの実施形態では、イベント主催者によって最終決定される前に、フィードバックのためにドラフトイベントスケジュールがスピーカーに送信されてもよい。

いくつかの実施形態では、この方法は、セッションの終了後に出席者にスピーカーの評価を促す、または要求することを含みうる。イベント主催者は、例えば出席者選択フィードバックの収集に関連して上述したような、任意の既知のコンピュータ実装方法によって、この講演者フィードバックを収集することができる。いくつかの実施形態では、講演者フィードバック応答オプションが利用可能である（または「オン」になっている）場合、イベント主催者は、この講演者フィードバックを使用して、講演者が受け取る支払い金額を決定することができる。いくつかの実施形態では、スピーカーのフィードバック応答オプションが利用できない (または「オフ」になっている) 場合、イベント主催者は、スピーカーによって交渉された定額料金または特定の料金をスピーカーに支払うことができる。

いくつかの実施形態では、出席者は、セッションに参加するためのクレジットまたは追加のクレジットを受け取るために、イベント主催者に講演者のフィードバックを提供する必要がある。

スピーカーフィードバック応答オプションをオンにすることの考えられる利点の1つは、スピーカーがイベントに参加することを自己選択し、出席者とより深くつながり、それによって出席者の満足度及びエンゲージメントが高まるようにメッセージと配信を調整するようにスピーカーをインセンティブにすることです。

さらなる実施形態では、出席者選択フィードバックおよび／またはスピーカーフィードバックを使用して、様々なイベントからの情報を収集するデータベースを生成することができる。いくつかの実施形態では、集約情報を、例えば、発表者が遅刻する確率を予測し、イベントスケジュールを作成するときにこの情報を組み込む、追加の機能と利点を実現する；評価と出席データによって決定された、共通の関心と見解を持つグループのリストをまとめて出力として生成する；広告の対象となる個人またはグループに、今後のイベント、セッション、製品またはサービスを広告する；たとえば、特定された聴衆グループと、これらおよびその他の要因に対する彼らの受容性と満足度を示すデータに基づいて、場所、コンテンツ、スピーカーを推奨するなど、イベントを「ゼロから」予約する；データによって決定されるように、志を同じくする個人が会うことを奨励するために、スケジュールに時差のある休憩をスケジュールする：収集した情報を使用して、イベントでのフリップチャート、オーディオ機器、ビデオプロジェクターなどの他のイベント リソースを割り当てる；等に利用しうる。

いくつかの実施形態では、出席者は会員プログラムを利用でき、出席者は様々な特典を獲得または獲得することができ、特定の出席者に「優先出席者」ステータスを付与することができる。たとえば、定期的かつ詳細なフィードバックを提供する出席者、および/またはシステムを定期的に使用する出席者、および/またはシステムを定期的に使用するイベントに出席する出席者は、自分の興味に関連すると見なされるイベントへの優先登録アクセスを許可するアカウントを持つことがあり、スケジュールのコンピュータ生成中に高い優先度を評価し、イベントを「ゼロから」作成または提案するときに、関心と場所をより高くランク付けし、物理的または電子的手段を介してスピーカーと直接接触することを許可し、早期登録へのアクセスし、および/または、登録率を削減し、およびそれらの任意を組み合わせる。

いくつかの実施形態では、スピーカーフィードバック情報を提供する出席者が利用できる追加の特典は、出席者がフィードバックを提供したスピーカーに関連する、またはスピーカーによって提供される追加コンテンツに出席者がアクセスできるようにすることを含みうる。

いくつかの実施形態では、出席者は、スピーカーにデジタルで質問し、スピーカーにそれらの質問に直接またはデジタルフォーラムで答えさせることができる場合がある。セッションの前に提出された質問は、講演者がワークショップなどのガイド付きセッション中に出席者を案内するのに役立つ場合がある。質問のデータベースがあると、スピーカーがその後のセッションを調整するのにさらに役立つ。イベントのために作成され、イベント後に維持されるフォーラムは、講演者が聴衆とつながるように促すのにさらに役立ち、講演者がシステムに参加するインセンティブを提供する可能性がある。このようなコミュニティを生成することは、コミュニティのサブセットが特定され、アイデアの提案やプロトタイプ作成のためにアクセスできるようになるため、聴衆、主催者、スピーカーが「ゼロから」イベントを作成するのにさらに役立つ可能性がある。

＜例１＞
例として、この方法は、１００人の出席者と合計４つのセッション（Ａ、Ｂ、Ｃ、およびＤ）を有する会議を含み、２つの時間帯で２つの部屋に分割される。この例では、１番目の部屋 (施設) の収容人数が９０人、２番目の部屋 (施設) の収容人数が３０人である。

１００人の出席者は、それぞれ、セッションＡ、Ｂ、Ｃ及びＤをブレビューするカンファレンスの前に、プレビューセッション２００に出席する。出席者は、セッション２０４を好みの順に評価するように求められ、「１」は最も気に入ったセッションであり、「４」は最も気に入らないセッションである。応答が受信され２０６また、この例を表２に示す。

出席者の応答に基づいて、最も関心のある出席者がいるセッションが決定され、最も多くの出席者がアクセスできるセッションがカンファレンスの満足度を高める可能性が高いため、イベントスケジュールのアンカーとなる。

各セッションのランキングは、最初に総合スコアを計算することによって決定される２８０。これは、セッションごとに、その特定のセッションに１、２、３又は４のランキングを付けた人の数にランク値を掛け、それらの数値をすべて加算することで実行できる。たとえば、セッションＡの講演者の総合スコアは、（６０×３）＋（２０×３）＋（１５×２）＋（５×２）＝２８０のように計算できる。

したがって、この場合、セッションは次のように採点される。
セッションＡ － ２８０；
セッションＢ － ２３０；
セッションＣ － １６５；
セッションＤ － ３２５。
この情報から、セッションをランク付けすることができ、最も高くランク付けされたセッションが識別される２１０。「１」が最高ランクであるため、最低スコアが最高ランクのセッションになりうる。これらのランキングに変更を加えることができ、ユーティリティランキングを決定する際に他の要因を考慮することができると考えられるが、この例では、ランキングはユーティリティランキングと同等である。

スケジュールには４人の発表者と２つのセッションが同時に実行されているため、カンファレンス全体に出席している１人のカンファレンス出席者は、最大２つの完全なセッションに参加できる。これは、個々の出席者が最も高く評価した２つのセッションが、理想的なスケジュールがあれば、出席者が暗示するものであることを意味する。

この情報を使用して、セッションＣに参加する予定の出席者の数は、ランキングの上位半分 (この場合は１または２) にランク付けされた出席者の数を合計することによって予測できる２１２。表２の情報を参照し、この数は８０人であると決定する。

セッションＣの施設２１４を予約するために、次に、予想される出席者数を部屋のサイズ情報と比較しうる。セッションＣは最初の部屋 (大きな施設) に割り当てる必要があることがわかる。現在、セッションＣは、最初の施設で行われる最初のセッションとして仮にスケジュールに入れられている。

会議は同時セッションを持つようにスケジュールされているため、この例では、ザベストトゥーザベストオブザワーストオブザベストの方法を使用する。

時間ブロック１の間、セッションＣは、仮に識別される必要がある第２のセッションと同時に実行される２１６。セッションＣは２つの部屋のうち大きい方の部屋で実行されるため、この同時セッションは２番目の部屋 (小さい部屋) に収まる必要がある。さらに、理想的にはセッションCに参加したい人は誰でも参加できるであろう。したがって、セッションＣと並行して予定されているセッションは、セッションＣを高く評価しなかった人によって高く評価されたセッションであろう。

追加の考慮事項は、セッションＣに参加する人が他のお気に入りのセッションに参加できる。

したがって、Ｃを１または２としてランク付けした人々は、彼らが３または４としてランク付けしたものを見るために識別される。上位２つのランキングに参加できるように、出席者の数を最大にすることが望ましい。表２から、セッションＢは６０人で２位、セッションＤは２０人で１位であることがわかる。また、サブセット内のこれらの８０人全員（講演者Ｃを「１」または「２」にランク付けした人）によってＡが「３」にランク付けされていることもわかる。

したがって、セッションＡは、セッションＣと同時にスケジュールするのに最良である。セッションＡの出席者数２１８を予測するために、セッションＡを「１」または「２」のいずれかにランク付けした人の数が決定される。表２では、２０人が「２」と評価し、「１」と評価した人はいないため、出席者数は２０人が予想される。次に、仮の組の結果としてコンフリクトが発生したかどうかを判断する１１９。
コンフリクトがないとき１１９、特定されたセッションはセッションＣと並行してスケジュールできるが、第２の部屋２２０である。コンフリクトがあるとき、施設を予約する前に２２０、前述したようにコンフリクトを解決できる２２１。

次に、列のすべての時間帯がスケジュールされているかどうか判定される２２３。そうでないとき、プロセスはステップ２１６に戻る。列のすべてのスロットがスケジュールされているとき、すべてのセッションがスケジュールされているかどうか判定される。
ここで、答えが「いいえ」であるとき、次のステップは、残りの最も高いランクのセッションを決定し２１０、後続のステップを繰り返す。この場合、２回目のブロックの残りのセッション（Ｂ及びＤ）でステップが繰り返される。残りの２つのオプションのうち、セッションＢが最もランクが高いため、出席者数の予測を決定し、それを部屋、この場合、第１の部屋、に割り当てる。これは、セッションＤが同時に実行されることを意味し、表２から、その予測出席者数により、第２の部屋に適合することができます。

すべてのセッションが施設にリンクされているため、コンピュータ生成イベントスケジュールが作成され２２４、この場合は表３に示される。このイベントスケジュールは、必要に応じて、承認のためにイベント主催者に送信しうる２２６。承認されると、必要に応じて、最終的なイベント スケジュールを公開し２２８、出席者にワイヤレスで送信することができる。

たった４つのセッションのこの単純化した例からでも、利点を特定することができる。表２にまとめられた情報は、６０人がセッションＣとＢへの参加を最も希望する；２０人がセッションＤとＣへの参加を最も希望する；１５人がセッションＢとＡへの参加を最も希望する；５人がセッションＤ及びＡへの参加を最も希望することを示す。

いくつかの実施形態では、追加、更新、または変更される情報の結果としてスケジュールに変更が生じる可能性があることが予想される。システム内のイベント情報が追加または変更された場合、ステップ２０２または２１０に戻ってスケジュールを修正しうる。

１００人のカンファレンス出席者のうち、プロセスの例示的な実施形態は、時間とスペースの要件を採用し、すべての出席者が、理想的なカンファレンスに参加し、スペースまたは時間とコンフリクトすることなく、従来イベントで、可能な限り効率的にスペースを利用した。

より複雑なシナリオでは、すべての出席者が理想的なイベントに参加できるとは限りませんが、この方法を使用すると、より多くの出席者が好みのイベントに参加できるようになる。より複雑な状況では、追加の要因が、すでにスケジュールされたサブセットからの最も有利なランキングスコアとともに、またはそれに代えて考慮される場合があります。イベント主催者の全体的な目標は、全体的なスケジュール生成の計算にどの要因がどの程度の重みを与えるかを指示する。

＜医療＞
一実施形態では、開示された方法を医療に適用しうる。以下の表４は、一般的な方法で説明されている役割を果たすことができる当事者の例を示しています。

ステップ１０１で、主催者によって入力された施設情報は、利用可能な施設の収容人数およびタイプを含みうる。いくつかの実施形態では、主催者はバッファ定数を設定することもできる。いくつかの実施形態において、バッファ定数は、約１時間、５時間、１０時間、２４時間、４８時間、または状況において適切であるこれらの例の間の任意の分数または時間数であり得る。

医療の設定における「プレビューセッション」は、自動化されたプロセスおよび／または医療専門家（この場合はランカー）によって実行されるトリアージチェックインセッションのいずれかによって実行できる診断トリアージプレビューセッションである。ランカーは、診断観察および／またはトリアージセッションおよび／または患者の健康データに基づいて、利用可能な治療をランク付けする。

いくつかの実施形態では、ランキング情報を変更することができ、例えば、いくつかの実施形態では、より緊急にケアを必要とする患者は、ランキングに所定の緊急度係数を掛けることができ、又は、患者が長期間待っているとき、ランキングに係数を掛けて、同様の緊急度をもつ他の患者よりも優先することができる。たとえば、すべての患者が同様の緊急性を持っている場合に、待っている患者のキューを維持し、特定の期間後にリクエストのランキングを増やすことができる。いくつ、かの実施形態では、ランキングは、毎時増やすことができる。

いくつかの実施形態では、医療業界におけるセッションの要件ランキングには、手術治療（「セッション」）を行うために施設が手術室である必要があるなどの厳格な要件、または感染者がいる場所から離れた施設で特定の治療を受けるなどの優先傾向を含めることができる。

この情報が提供されると、各セッションの個々のランキングが決定され、最も高いユーティリティランキングのセッションがスケジューリングのために選択される。要件ランキングによって提供されるパラメータに適合する最高ランクの施設が識別される。たとえば、セッション（この場合は治療） に手術室で行わなければならない手術が含まれる場合、手術室である施設のみが可能な施設として考慮される。最高ランクの適切な施設を特定すると、セッションと施設がリンクされる。その後、すべてのセッションと施設がリンクまたはスケジュールされるまで、プロセスは前述のように続行される。特定の期間のスケジュールが完了すると、そのスケジュールは、セッションの施設を準備するために、出席者、スタッフおよび/または施設の管理者に送信することができる。

＜例２＞
この非限定的な例では、病院または医療センター（イベント）は、４種類の治療を提供する（患者に対する個々の治療はそれぞれ異なるセッションと見なされる）。それらは、例えば、透析（Ａ）、薬理学相談（Ｂ）、手術（Ｃ）および回復（Ｄ）である。センターには、手術室（ＯＲ：Operating room）とスタンダードルーム（ＳＲ：Standard room）の２種類の部屋（施設）がある。厳密な要件としては、治療ＡとＣは手術室（ＯＲ）で行う必要があるのに対し、Ｂ及びＤはすべてのスタンダードルーム（ＳＲ）で行うことができる。センターは、別のトリアージセンターとは離れて、２つの手術室と２つのスタンダードルームがある。Ａ、Ｂ、Ｃ又はＤのいずれも、全ての治療の時間は１時間である。

治療の長さと部屋間で患者を移動させるために必要な追加の時間を考慮すると、この例では、センターは１室あたり１日１０回の治療を行うことができ、したがって、各日のスケジュールで記入する時間帯は最大４０である。２つがスタンダードルームで、２つが手術室であるので、Ａ及びＣが合計２０件、Ｂ及びＤが合計２０件発生する可能性があります。ただし、毎日の各治療の正確な数は変動する可能性がある。たとえば、ある日には、１８人の患者が治療Ａを受け、２人の患者が治療Ｃを受ける場合がある。別の日には１０人の患者が治療Ａを受け、１０人の患者が治療Ｃを受ける場合がある。

この例では、合計で８０人が病院からの治療を必要としている（患者）。病院に運ばれた人もいれば、他所から紹介された人もいる。各患者には、最初のトリアージプレビューがあり、トリアージ医師または看護師が患者の状態をインデックス化し、必要な治療と緊急度を評価する。

このトリアージプレビュー中に、トリアージ医師または看護師（ランカー）は、患者のニーズに関する情報、いくつかの実施形態では、患者が受けるべき治療及び治療の緊急性の両方を反映する彼らのニーズの評価であり得る情報、を入力する。たとえば、患者が透析を必要とし、他の治療は必要ないと判断された場合、ランカーは透析治療（Ａ） の評価を「はい」と入力します。

いくつかの実施形態では、治療が必要な場合、ランカーは、治療の緊急度評価、変更係数の例を入力するように促される。いくつかの実施形態では、緊急度評価は、１から３のスケールであり、１は「緊急ではない」、２は「中程度の緊急」、３は「非常に緊急」を意味する。

「はい」には値１が割り当てられ、変更係数が掛けられる。患者が他の治療を必要としない場合、他のすべての治療に関して評価は０（「いいえ」）とみなされる。この例では、ランカーが特定の患者に関連する治療をゼロ以上にランク付けすると、これにより、特定の患者を出席者とする特定の治療のセッションが生成される。したがって、患者１は、次のように決定されるユーティリティランキング２を持つ１つの治療セッションＡを要求した。

この例では、患者２も透析（Ａ）のみを必要とするが、より緊急を要する。さらに、トリアージの医師および／または看護師も、薬理学相談が必要であると判断するが（Ｂ）、相談は透析（Ａ）ほど緊急の必要性はない。この例では、患者２が２つのセッションを要求する。最初のセッションは治療Ａで構成され、有用性ランキングが３であり、２番目のセッションは治療Ｂで構成され、有用性ランキングが２である。これは、次のように決定される。

上記の方法で治療を必要とする残りの患者について、さらなるランキングデータが受信する。この例では、患者の個々の治療はそれぞれのセッションと見なされる。

いくつかの実施形態では、任意の日の最も理想的な時間帯は、手術室で予定されている最も早い治療である。手術室施設の最初の時間帯は、最高ランクの施設の最高ランクの時間帯として識別されます。いくつかの実施形態では、時間帯が後になればなるほど、ランクが下がる。いくつかの実施形態では、手術室以外の施設にも、手術室よりも低いランクが割り当てられる。

医療の状況では、通常、セッション（治療）ごとに１人の出席者がいて、たとえば１人だけが手術を受けるが、たとえば理学療法のクラスを扱う場合は複数の出席者がいる可能性がある。したがって、いくつかの実施形態では、セッションのランキングは、特定の治療に対する出席者（患者）のランキングに直接関係しているが、他の実施形態では、セッションのランキングは出席者のランキングの総計である。この例では、識別された各セッションのセッションごとに１人の出席者のみである。

一実施形態では、セッション（治療）ランキングのデータベースがコンピュータによって検索され、最も高いランキング、この場合は治療ＡおよびＣ（いずれかでゼロより高い評価を有する）を有するセッションにフィルタリングされる。次に、ＡまたはＣのいずれかでユーティリティランキングが最も高いセッションが特定される。選択されたセッションに関連する患者は、その日の最初の時間ブロックで手術室１にスケジュールされる。この患者が治療Ｃに関連する評価が最も高い場合、手術室に入った直後に回復室Ｄが必要になる。したがって、プロセスの要件として、患者は手術室に入る予定の直後の時間帯に回復室に入れるようにスケジュールされる。

プロセスが繰り返され、番号２の手術室のＡまたはＣに関して次に高いランクの治療がスケジュールされる。

いくつかの実施形態では、最も重要な施設タイプをスケジュールした後にスケジュールする必要のある施設を除いて、他の施設タイプのスケジュールを開始する前に、最も重要な施設タイプが完全にスケジュールされる。この例では、上記のプロセスが繰り返され、番号２の手術室のＡまたはＣの次に高いランクの患者をスケジュールし、現在のスケジュールの期間中、各手術室が埋まるまで繰り返される。

この例では、両方の手術室が予定された後、スタンダードルームが予定されうる。

この例では、スタンダードルームを回復（Ｄ）と薬理学相談（Ｂ）の両方に使用することができる。シーケンシングの要件では、回復（Ｄ）は手術（Ｃ）後に行わなければならないものとして事前に定義されていた。その日の最初の時間帯には手術が行われていないため、最も早い時間帯にスタンダードルームに入れることができる唯一の治療法は、薬理学相談（Ｂ）である。

すでに予定されているセッションを除いて、薬理学相談に関して最も高いランキングを持つセッションは、第１のスタンダードルームで予定されている。このプロセスが繰り返され、第２のスタンダードルームの第１の時間帯に予定されている薬理学相談の次に高いランキングのセッションが行われる。

いくつかの実施形態では、第１の時間帯で手術室施設で予定されたセッションは、両方とも、第２の時間帯でそれらの患者のためにスタンダードルーム施設が予約されることを必要とする。たとえば、１日の最初の時間ブロックで両方の手術室で予定されている治療が両方とも手術である場合、両方のスタンダードルーム２番目の時間ブロックで予定されている治療は両方とも回復（Ｄ）になる。この場合、スタンダードルームで次に割り当てられる時間帯は、次に利用可能な時間帯となり、３番目以降となる場合がある。すべての部屋と時間ブロックが治療セッションでスケジュールされたら、スケジュールを患者、施設の管理者、およびスケジュールを知る必要のある他の人（たとえば、患者を担当する医師）に直接送信できる。

バッファ定数を考慮してスケジュールを作成することができ、これは、新しい情報または変更された情報が追加されてから一定の時間が経過する前に、新しい情報または変更された情報に基づいてスケジュールに変更が加えられないことを意味する。

いくつかの実施形態では、最終スケジュールは、進行中のリアルタイムデータによって変更されてもよく、その結果、最新の利用可能なデータに従ってスケジュールが継続的に再計算される。いくつかの実施形態では、タイムブロックがリアルタイムで開始すると、そのタイムブロックは再スケジュールに利用できなくなる。たとえば、緊急に透析が必要な患者が病院に急いでいる場合、システムに存在するどの患者よりも透析セッションの順位が高いため、この情報を受け取るとすぐにスケジュールが再実行される。前述の方法で、まだリアルタイムで開始されていない最も古い時間ブロックから開始する。これは、他の治療の緊急性を考慮して、患者ができるだけ早く治療を受けるように自動的にスケジュールが設定されることを意味し、スケジュールが変更され、統一されたシステムからすべての医師、施術者、患者、およびその他の同様の人々にスケジュール変更が通知される。

いくつかの実施形態では、新しい患者に関する情報がシステムに追加された後、特定の期間内に患者を再スケジュールできないように、システムにバッファ定数が設定されてもよい。たとえば、施設管理者が次のセッションのために施設を準備するために１時間を必要とする場合、新しい患者情報がシステムに追加されてから１時間以内に時間ブロックのスケジュールを修正することはできない。治療（セッション）のタイプが異なると、バッファ定数が異なる場合があることが予想される。

この方法を使用して生成されたスケジュールは、最も緊急の治療を受ける患者を治療の最前列に置き、各患者が必要とする治療に照らして、利用可能なスペースをより公平かつ効率的に使用する。

＜不動産＞
一実施形態において、開示された方法は、不動産業界に適用することができる。以下の表７は、一般的な方法で説明されている役割を果たすことができる当事者の例を示す。

ステップ１０１で、主催者が入力する施設情報には、賃貸借、ゾーニング（例えば、小売スペース、オフィス使用、レストラン使用など）に利用可能なさまざまな施設の平方フィート、およびより主観的な基準に関するスケールランキングを含めることができる。施設の近代性や最近の改装などの特徴で、最近の改装やアップグレードに高いランクが与えられる。

いくつかの実施形態では、主催者はバッファ定数を設定することもできる。いくつかの実施形態において、バッファ定数は、例えば、賃借人が入居するための時間、または状況において適切な任意の時間量を与えるために、約１ヶ月であり得る。

不動産設定における「プレビューセッション」は、賃貸可能な施設のタイプ（セッション）をプレビューする見込みのテナント（ランカー）である。利用可能な施設のタイプには、商業スペース、居住スペース、レストランスペース、産業スペースなどが含まれる。いくつかの実施形態では、ランカーは施設のタイプを選択する。いくつかの実施形態では、ランカーは特定の個々の施設をランク付けする。いくつかの実施形態では、ランカーは施設のタイプを選択し、特定された特定の施設をランク付けする。

いくつかの実施形態では、ランキング情報を変更できる。たとえば、いくつかの実施形態では、平方フィートあたりのリース料が高いゾーニングカテゴリを要求するテナント（たとえば、小売スペースはオフィス スペースよりも高価な場合が多い）は、価値の高いクライアントと彼らが最も好むスペースをマッチングすることにより、収益を最大化するための努力の中で、与えられた係数によって、ランキングを乗算することができる。

いくつかの実施形態では、不動産業界におけるセッションの要件ランキングは、例えばレストランなどの特定の目的のためにゾーニングされ設備が整った施設で発生する必要があるリースセッションのような、厳格な要件を含むことができる。

この情報が提供されると、各セッションの個々のランキングが決定され、最も高いユーティリティランキングのセッションがスケジューリングのために選択される。要件ランキングによって提供されるパラメータに適合する最高ランクの施設が識別される。
たとえば、セッション（この場合はリース）が特定のタイプの施設（たとえば、レストラン用にゾーニングされ、設備が整っている施設）に対してのみ実行できる場合、その特定のタイプの施設のみが考慮される。
いくつかの実施形態では、出席者（テナント候補）が施設の特定の特性を好ましいものとしてランク付けした場合、例えばテナントはプラザではなくショッピングモール内のスペースをリースすることを好む。特定されたサブセット内のショッピングモールにある全ての施設には、考慮する特定のセッションに関するランキングにさらに乗数又はアドオンを与えることができる。

最高ランクの適切な施設を特定すると、セッションと施設がリンクされる。プロセスは、すべてのセッションと施設がリンクされるまで、前述のように続行される。

＜例３＞
いくつかの実施形態では、企業は特定の場所にフランチャイズ店をオープンしようとしている。例えば、フランチャイズ店はファストフード店であってもよい。レストランには、リースしようとしているスペースに関する一連の要件、リース自体の一連のパラメータ（たとえば、リースの長さ）、および他の関連する要件（たとえば、他の類似のビジネスからの距離および/またはスペースを最小限に抑えたい複合施設のタイプ）がある場合がある。

いくつかの実施形態では、賃貸人は、スペースに関する重要な情報を含む、リースに利用可能なスペース（施設）をリストすることができる。たとえば、賃貸人は、１０００平方フィートのオフィススペースとなりうる「スペース１」、２階の医療スペースとなりうる「スペース２」、１階にあり、小売スペースとなりうる「スペース３」及び１階にあり、レストラン用に未完成である「スペース４」がある複数のフロアを持つ開発されたコンプレックスを所有しうる。賃貸人は、また、２階に２０００平方フィートの２つのオフィススペース「スペース ５」と１５００平方フィートの「スペース ６」があり、また、１階に２つのレストランスペース「スペース７」と「スペース８」がある別の建物を所有しうる。いくつかの実施形態では、賃貸人もランカーと見なされ、その施設の特徴、例えば施設がどの程度近代的であるかに関するランク付け情報を提供することができる。

いくつかの実施形態では、賃借人（ランカー）は、一般的な好感度でスペースをランク付けし、例えば、より近代的な施設は、より高い評価を受けることができる。

賃貸人は、複数の潜在的賃借人から利益を受け取ることができる。たとえば、テナント「Ａ」はファストフードのハンバーガーチェーン、テナント「Ｂ」は歯科医、テナント「Ｃ」は化粧品店、テナント「Ｄ」はアジア料理レストラン、テナント「Ｅ」は別のハンバーガー チェーンである場合、テナント「F」は新興の広告会社であり、テナント「Ｇ」はタバコの販売業者であり、テナント「Ｈ」は定評のある建築会社でありうる。

賃貸人は、賃借人に、彼らの事業の性質および他の施設関連の好みに関する情報を入力できるコンピュータ・インターフェースを提供する。いくつかの実施形態では、賃貸人は、テナントからの推定収入に基づいてテナントのユーティリティ評価を変更することができる。たとえば、小売スペースは通常、オフィススペースよりも１平方フィートあたりの賃料が高くなる。これを考慮して、小売業タイプの企業の格付けには、選択を乗算してランキングでより価値のあるものにする修飾子があり、それにより、リースが最初にスケジュールされ、そうでない場合よりも高い優先度でスケジュールされる可能性がある。

この例では、テナント「Ａ」は、彼らが消費者向けのレストランであるという彼らのインターフェイスに入ることができる。選択したカテゴリから、さらに「バーガーズ」に特化した「アメリカン／カジュアル」ダイニングであることを選択する。

各潜在的賃借人のユーティリティランキングは、賃貸人による変更を含め、賃貸人が提供した情報およびランク付けに基づいて計算される。例は次のとおりである。

テナント ユーティリティランキング ＝ （要求された平方フィート × カテゴリリース率） ＋ （ブランド認知度） ＋ （要求されたリースの長さ）

いくつかの実施形態では、賃借人は、施設およびリースに関連する彼ら自身の好みを入力することができる。たとえば、テナントは特定の地域で施設を探している場合があるつる。この情報を保存して、賃借人の好みに応じて利用可能な施設のランキングを変更することができる。

この例では、テナント「Ｂ」は、自分のビジネスが歯科であると入力し、専門的な設定になりたいことを示すことができるインターフェイス上のボックスをチェックする。

潜在的なテナントによって提供されたランキング情報を含む提供された情報に基づいて、ユーティリティスコアが各テナントのリースセッションに割り当てられる。
この例で提供される情報に基づいて、レストランスペースのリースは、賃貸人に１平方フィートあたり最も高いリース料が支払われるという仮定を含み、賃貸人のシステムでは、最も重要なテナント、及びブランド認知度などの他の要因で、テナント「Ａ」が最も高いユーティリティ評価を持つことがわかる。

したがって、システムは、このテナントにスケジュールする。

設定された施設タイプパラメータを満たす施設は、利用可能なすべての施設のサブセットとして識別される。この場合、パラメータはレストラン施設が必要であることを示す。

いくつかの実施形態では、施設のサブセットは、テナントによって提供された情報に基づいてランク付けされ得る。いくつかの実施形態では、施設の特定の要素に関する賃貸人による元のランク付けは、賃借人の好みを反映するように変更できる。たとえば、建物２は、賃貸人によって近代性について１のスコア（当初のランキング）しか与えられていない可能性があるが、テナントが希望することを示した近隣に近い可能性がある。したがって、これにより、施設のランキング１に２のスコアが与えられ、そのテナントに関してランキングが３に変更されうる。

さまざまな場所のランキングに基づいて、テナント「Ａ」が２番目の建物の適切な施設にいることを最も強く望んでいることがわかる。スペース８が最も好みとランキングに一致する。したがって、テナントＡのリースは、スペース８で仮にスケジュールされる。

前述のように、スケジュールされる次のリースは、コンフリクトを発生させないスペースに配置された最高のユーティリティランキングを備えた同時リースであり得る。いくつかの実施形態では、この方法は、同じカテゴリ内の小売店またはレストランのスペースが可能な限り離れていることを保証する要因を含むことができる。たとえば、この要素は、スペース７の選択プロセスからテナント「Ｅ」を考慮しないことになる。したがって、残りのレストランであるテナントＤは、スペース７をリースすることになる。残りのレストラン（２番目のハンバーガーチェーン）、テナント「Ｅ」のリースはスペース４に予定されている。

小売賃貸の賃貸料に関して賃貸人にしたがって次に高いランクの賃借人は、この例では、テナント「Ｃ」である。これは、残りの小売スペースであるスペース３に割り当てられる。次に順位の高いテナントは歯科医院であるテナントＢであり、これは唯一の医療スペースであるスペース２にスケジュールされる。残りのすべてのテナントと施設は、オフィスのテナントと施設である。この例で想定している次に高いランクのテナントは、タバコの販売業者であるテナントＧである。これは、スペース１と最も理想的に一致する。ただし、ビジネスの性質上、それはテナントＢの専門家の設定を求める要求とコンフリクトする。上位のテナントＢを既にスケジュールしているため、テナントＧは、２番目の建物の最も一致するオフィススペースであるスペース５に移動される。

特定のテナントの残りのリースは、ユーティリティランキングの順にスケジュールされ、以前の好みの入力に基づいて使用可能なスペースのサブセットが変更される。結果として生じる仮のリーススケジュールが作成され、承認のために賃貸人に送信される。

システムの潜在的な利点は、重要なクライアントが、より重要なクライアントの好みとコンフリクトするスペース、又は同様に重要なクライアントを異なる方法で処理するのに役立つスペースに時期尚早に予定されているため、利用可能なすべてのスペースでリースをスケジュールし、スペースを無駄にしない間、将来の賃借人の要件と好みを満たすという点で明らかである。施設やテナントの数が増えると、システムの考えられる利点は複雑化する。

いくつかの実施形態では、ビジネスカテゴリのランキングは、それらの賃借人の業界またはスペースタイプにおける一般的な１平方フィートあたりのリース率に関連する賃借人のタイプの賃貸人のコンp身を反映するため、次のようになり得る。
レストランに割り当てられた値４
小売に割り当てられた値３
医療スペースに割り当てられた値２
オフィススペースに割り当てられた１。

＜オフィス＞
一実施形態では、開示された方法をオフィスに適用できる。以下の表８は、一般的な方法で説明されている役割を果たすことができる当事者の例の概要を示している。

ステップ１０１において、主催者が入力する施設情報には、オフィスまたは作業環境、例えば会議室または作業室で利用可能な様々な施設の収容人数およびレイアウトを含めることができる。

いくつかの実施形態では、主催者はバッファ定数を設定することもできる。いくつかの実施形態において、バッファ定数は、約３０分、または状況において適切な任意の時間であり得る。

オフィス環境での「プレビュー セッション」では、ランカーが会議またはワークセッションで利用できる施設のタイプをレビューする。利用可能な施設の種類には、会議室、役員室、作業スペース、スタジオ、またはその他の作業環境が含まれる。いくつかの実施形態では、ランカーがランク付けするために、様々な会議およびプログラムが利用可能であり得る。いくつかの実施形態では、ランカーは、プライベートスペースでの単独作業時間を選択でき、これにより、唯一の予測出席者である要求を行ったその出席者との単独作業時間セッションが生成される。

いくつかの実施形態では、ランキング情報を変更でき、たとえば、いくつかの実施形態では、管理者は、従業員によって与えられたランキングに所定の係数を掛けたセッションのランキングを持ってもよい。

いくつかの実施形態では、オフィスアプリケーションにおけるセッションの要件ランキングは、利用可能な座席数が一定の施設または部屋の収容人数が一定であるなど、厳しい要件を含むことができる。

この情報が提供されると、各セッションのランキングが決定され、最も高いユーティリティランキングのセッションがスケジューリングのために選択される。要件ランキングによって提供されるパラメータに適合する最高ランクの施設が識別される。たとえば、セッションに特定の座席数の施設で発生する必要があることを示す要件ランキングがある場合、少なくともその座席数がある施設のみが考慮される。

最高ランクの適切な施設を特定すると、セッションと施設がリンクされ、特定の時間帯にスケジュールされる。その後、すべてのセッションと施設がスケジュールされるまで、プロセスは前述のように続行される。

＜例４＞
いくつかの実施形態において、一般的な方法は、オフィス、オフィスのグループ、または別の共同作業スペースに適用される。この非限定的な例では、この方法には、１００人の出席者がいるオフィスまたは共同作業スペースが含まれ、合計４つのセッション (Ａ、Ｂ、Ｃ、Ｄ) があり、２つの時間帯で２つの部屋に分割される。セッションは、単独作業時間、会議、およびその他の活動に対応する。第１の部屋は一般ワークルームで９０人の収容人数、第２の部屋は会議室で３０人の収容人数である。この情報は、ステップ１０１でコンピュータに保存される。

１００人の出席者はそれぞれ、その日の仕事とタスクを要約し、セッションＡ、Ｂ、Ｃ及びＤ をプレビューするプレビューセッション２０２を見る。出席者は、セッション２０４を優先順に評価するよう促され、「１」は今日最も取り組みたいセッションであり、「４」は今日取り組みたい程度の低いセッションである。マネージャーは、出席者のランキングを増やしたり変更したりできる独自のランキングを追加できる別のインターフェイスを持っている場合がある。たとえば、マネージャーが特定のタスクがより重要であると指定した場合、これは、そのセッションのユーザの好みのランキングに、さらに－１(１が最も重要) または＋１(４が最も重要) として変換される可能性がある。応答が受信され２６０、この例について表９に示す。

いくつかの実施形態では、出席者のイベントの応答は、最も重要な作業セッションを決定するための基礎を形成し、イベントスケジュールを固定する。

各セッションの重要性は、最初に総合スコア２８０を計算することによって決定される。これは、各セッションについて、その特定のセッションに、たとえば１、２、３、または４のランキングを付けた人の数にランク値を掛け、それらの数値をすべて加算することで実行しうる。あるいは、セッションのユーティリティのランキングを決定するために、集計の前に個々のランキングを変更することもできる。たとえば、(変更係数なしで)、 セッションＡの総合スコアは次のように計算できる。
（６０×３）（２０×３）（１５×２）（５×２）＝２８０

上記と同じアプローチで、セッションは次のように採点される。
セッションＡ－２８０；
セッションＢ－２３０；
セッションＣ－１６５；
セッションＤ－３２５；
この情報から、最も人気のあるセッションを決定できる２１０。「１」が最高ランクだったので、最低スコアが最高ランクのセッションである。したがって、セッションＣは、最も多くの人がそれを最高にランク付けしたという点で、最も重要であった。

この例では、２つの部屋があるため、スケジュールで２つのセッションが同時に実行される。つまり、１日中出席している１人の作業者は、最大２つの完全なセッションに出席できる。これは、個々の作業者が最も高く評価した２つのセッションのうち、最大の満足度と生産性が満たされる場合、つまり理想的なスケジュールがある場合に作業者が参加するセッションであることを意味する。

この情報を使用して、セッションＣに参加する予定の作業者２１２の数は、ランキングの上位半分 (この場合、１又は２) にランク付けされた出席者の数を合計することによって予測される。表９の情報を参照すると、この数は８０人であると判断する。

セッションＣのために部屋（施設）を予約するため２１４、作業者（出席者）の予測または予測数を、部屋（施設）のサイズ情報と比較できる。セッションＣは、第１の部屋 (大きい部屋) に割り当てられるべきであることがわかる。セッションＣは、第１の部屋で行われる最初のセッションとして、現在、仮にスケジュールに入れられている。

時間ブロック１の間、セッションＣは第２のセッションと同時に実行されるが、これは判定する必要がある２１６。セッションＣが２つの部屋のうち大きい方で実行されることがわかっているため、この同時セッションは第２の部屋（小さい部屋）に適合できる必要がある。さらに、セッションＣに出席したい出席者は、理想的には出席できるはずである。したがって、セッションＣを高く評価しなかった人々によって高く評価されたセッションを、セッションＣと同時にスケジュールしたいと考えている。

追加の考慮事項は、セッションＣに参加する人が、他の気に入るセッションに参加できることである。

したがって、Ｃを１または２としてランク付けした人を識別して、どのランクが３または４であるかを確認する。上位２つのランキングに参加できるように、出席者の数を最大にすることが望ましい。表９から、セッションＢは６０人に２位とされ、セッションＤは２０人に１位とされたことがわかる。また、Ａが私たちのサブセット（講演者Ｃを「１」または「２」にランク付けした人）のこれらすべての８０人によってランク付けされていることの証拠でもある。

したがって、セッションＡは、セッションＣと同時にスケジュールするのに最適である。セッションＡの出席者を予測するため２１８、セッションＡを「１」または「２」のいずれかにランク付けした人の数が決定される。表９によると、２０人が「２」とランク付けし、誰も「１」とランク付けしなかったので、予想出席者数は２０人である。次に、予想出席者数２１８が利用可能な部屋のサイズとコンフリクトするかどうかが判定される２１９。コンフリクトがない場合、プログラムは、識別されたセッションをセッションＣと同時のスケジュールに配置するが、第２の部屋２２０になる。部屋のサイズとコンフリクトする場合、そのセッションは除かれ、プログラムはステップ２１６に戻り、残りのセッションに基づいて同時セッションを決定する。

次に、すべてのセッションが部屋に予約されているかどうかが判定される２２２。この場合、答えは「いいえ」であり、次のステップでは、残りのオプション（Ｂ及びＤ）を使用して、２回目のブロックの手順を繰り返す。残りの２つのオプションのうち、セッションＢが最も人気があるため、スピーカーＢとのセッションへの予想出席者数が決定され、部屋（この場合は最初の部屋）に割り当てられる。これは、セッションＤがセッションＢと同時に実行されることを意味し、表９から、その予測出席者数により、第２の部屋に割り当てられる。

すべてのセッションが部屋に予約されると、コンピュータで生成されたイベントスケジュールが作成され２２４、このケースが表１０に示される。このイベントスケジュールは、承認のため、イベントの主催者（この場合はオフィスマネージャ）に送信される２６６。承認されると、最終スケジュールが公開され２２８、作業者にワイアレスで送信できる。

この方法のステップは、特に複雑でより多くの労働者が関与するイベントを処理する場合に、公開されたスケジュールを出席者と主催者が使用できるように、コンピュータープログラムを介して発生することが予想される。

この４つのセッションだけの単純な例のみからも、考えられる利点を特定できる。表９にまとめられた情報は、６０人がセッションＣとＢへの参加を最も希望し、２０人がセッションＤとＣへの参加を最も希望し、１５人がセッションＢとＡへの参加を最も希望し、５人がセッションＤとＡへの参加を最も希望したことを示す。

１００人の作業者のうち、プロセスの例示的な実施形態は、すべての作業者が重要度の高い順に彼らの「理想的な」会議や活動の日に参加するように、時間とスペースの要件を採用しており、スペースや時間のコンフリクトなく、従来の組織化されたオフィスや職場で可能なよりも効率的にスペースを利用できる。

より複雑なシナリオでは、すべての作業者が自分の「理想的な」スケジュールに参加できるとは限らないが、この方法を使用すると、従来のスケジュール方法を使用するよりも多くの作業者が希望するスケジュールに参加できることが予想される。より複雑な状況では、追加の要因が、すでにスケジュールされたサブセットからの最も有利なランキング スコアとともに、またはそれに代えて考慮される場合がある。イベント主催者の全体的な目標によって、スケジュール生成全体の計算にどの要因を加重できるかが指示される場合がある。

＜航空会社＞
一実施形態では、開示された方法を航空会社に適用でき、イベントは、１のフライトの飛行機の全ての座席である。したがって、この例では、１のプレビュー セッションで複数のイベントのプレビューを提供できる。以下の表１１は、上記の一般的な方法で説明されている役割を果たすことができる当事者の例の概要を示している。

ステップ 101 で、主催者が入力する施設情報には、飛行機の数、施設の数（この場合は座席）、および施設のタイプ（座席のクラス、たとえば、ファースト クラス、ビジネス クラス、エコノミー クラスなど）を含めることができる。

いくつかの実施形態では、主催者はバッファ定数を設定しうる。いくつかの実施形態では、バッファ定数は、約１日または状況に適した任意の時間であり得る。

航空会社設定の「プレビュー セッション」は、出発および到着が可能な空港のセットである。いくつかの実施形態では、出発地、到着地、および希望日は、プレビュー セッション（この場合はプレビュー リスト）から選択される。より具体的には、出発地を選択することにより、ランカーは選択された場所を「１」としてランク付けし、選択されていない場所を「０」としてランク付けする。いくつかの実施形態において、セッションは、出発および到着属性がプレビューされ、ランカーによって選択された状態で生成される。

いくつかの実施形態では、ランキング情報を変更でき、たとえば、いくつかの実施形態では、ロイヤルティプログラムのメンバー、またはチケットにより多く支払った者、である出席者（この場合、乗客）は、ランキングに所定の係数を掛けることができる。

いくつかの実施形態では、セッションの要件ランキングは、施設のクラス(この場合は座席)のような厳しい要件を含むことができる。いくつかの実施形態では、セッションの要件ランキングは、施設が窓側の席であるなどの好みを含むことができる。一部の出席者にとっては、一部の厳格な要件が他の出席者の好みであると考えられ、逆もまた同様である。いくつかの実施形態では、セッションの要件ランキングは、厳格な要件と好みの両方を含むことができる。

この情報が提供されると、各セッションの個別のランキングが決定され、最も高いユーティリティランキングのセッションがスケジューリングのために選択される。要件ランキングによって提供されるパラメータに適合する最高ランクの施設が識別される。たとえば、出席者 (航空会社のゲストまたは乗客) が施設 (飛行機の座席) の特定の特性を優先するものとしてランク付けした場合、たとえば乗客 (出席者) が窓側の座席を好む場合、識別されたサブセット内の窓側の座席である全ての施設には、検討されている特定のセッションに関して、それらのランキングにさらに乗数またはアドオンを与えることができる。

最高ランクの適切な施設を特定すると、セッションと施設がリンクされる。プロセスは、すべてのセッションと施設がリンクされるまで、前述のように続行される。

＜例５＞
この例では、飛行機の１の座席が施設に相当し、セッション（フライト）に１人の出席者がいる。したがって、ランク付けされているのはセッション（フライト）であるが、セッションには出席者が１人しかいないため、セッションランキングはその出席者に直接リンクされ、したがって、セッションのユーティリティランキングは、たとえば、報酬のステータスや選択した座席のタイプ等の出席者の特性に基づいて変更しうる。

いくつかの実施形態では、ランカーは、発券オプションを提示したウェブサイトを確認し、フライトの目的地や日付などの基本的なフライト情報を選択する。いくつかの実施形態では、ランカーには、座席のさまざまなタイプのオプションが提示される。たとえば、フライトの座席は、「良い」、「より良い」又は「最高」のように分類される。いくつかの実施形態では、出席者の座席タイプの選択が、「よい」のクラスでは、フライトセッションの低いユーティリティ評価とリンクされ（変更要素を通じて）、「より良い」のクラスでは、より高いユーティリティ評価となり、「最高」のクラスでは、最も高価であり、最も高いユーティリティ評価となる。

いくつかの実施形態では、ランカーは、彼らの好みに関する他の情報、または例えば窓側の席が好ましいかどうかなどの出席者の好みを提供できる。はいの場合、そのフライト セッションに関するすべての窓側の座席施設の値は＋１を受け取る。いくつかの実施形態では、ランキングは、ランカーが航空会社の会員プログラムの一部である結果として変更される。

ユーティリティランキングが最も高いフライトセッションを選択できる。いくつかの実施形態では、最高ランクのフライト セッションが複数ある場合、スケジュールされる最初のフライト セッション (したがって出席者) をランダムに選択できる。

選択したフライト セッションの目的地と日付の要件を満たすすべての利用可能なフライトのサブセットが識別される。

施設にも値が割り当てられます。いくつかの実施形態では、座席のタイプに望ましさの値が割り当てられる。たとえば、ビジネスクラスの座席には「４」の値、ファーストクラスの座席には「３」の値、エコノミーの座席には「１」の値、追加のスペースがあるエコノミーの座席（非常口に隣接する座席など）には「２」の値が割り当てられる。これらの座席（施設）の値は、他の望ましさの要因によってさらに調整されうる。たとえば、飛行時間が最短および／または乗り継ぎ回数が最も少ないフライトの座席が優先されうる。
乗り継ぎのないフライトの座席には追加の「＋３」の値、乗り継ぎが１回あるフライトの座席には追加の「＋２」の値、乗り継ぎが２回あるフライトの座席には追加の「＋１」の値が割り当てられる場合がある。

いくつかの実施形態では、選択された出席者の好みまたは要件に基づいて座席を調整することができる。たとえば、乗客が窓側の席を希望する場合、すべての窓側の席は、その乗客（出席者）のフライトセッションに関してさらに＋１を受け取る。

最上位の席（施設）が特定される。選択されたフライト セッション（および関連する出席者）は、空席のある最高ランクの座席にスケジュールされる。

次に順位の高いフライトセッション（フライトの個々のスポット）が識別され、その特定のフライト（イベント）の飛行機で利用可能な潜在的な出席者および／または座席がなくなるまで、プロセスが繰り返される。

＜映画館＞
一実施形態において、開示された方法は、映画館に適用できる。以下の表 12 は、一般的な方法で説明されている役割を果たすことができる当事者の例の概要を示している。

ステップ１０１において、主催者が入力する施設情報には、映画館複合施設内の様々な施設（個々の劇場）の座席数を含めることができる。いくつかの実施形態では、主催者は、施設の特定の特徴、例えば、３Ｄ映画などを上映するために装備されているものを含みうる。

いくつかの実施形態では、主催者はバッファ定数を設定することもできる。いくつかの実施形態において、バッファ定数は、約２時間、または状況において適切な任意の時間であり得る。

映画館設定の「プレビューセッション」は、施設（映画館または複合映画館）で利用できる各セッション（この場合は映画）に関連付けられた映画の予告編である。いくつかの実施形態では、ランカーは見たいセッションを選択する。いくつかの実施形態では、例えば、映画館がフェスティバルまたはムービーマラソンを開催している場合、ランカーは、最も見たいと思うセッションに基づいて、さまざまなセッションを評価できる。

いくつかの実施形態では、ランキング情報を変更でき、たとえば、いくつかの実施形態では、より高いチケット価格を支払うランカー／出席者は、ランキングに所定の係数を掛けるか、または別の方法で変更できる。

いくつかの実施形態では、セッションの要件ランキングには、３Ｄ映画を上映できる施設で３Ｄ映画を上映しなければならないなど、厳格な要件を含めることができる。いくつかの実施形態では、セッションの要件ランキングは好みを含むことができ、例えば、より新しいリリース日の映画を特集するセッションは、より近代的なまたは最近改装された施設で提示されることが好ましい場合がある。

この情報が提供されると、各セッションの個別のランキングが決定され、最も高いユーティリティランキングのセッションがスケジューリングのために選択される。要件ランキングによって提供されるパラメータに適合する最高ランクの施設が識別される。たとえば、セッション（この場合は映画）が３Ｄプロジェクターでしか表示できない場合、３Ｄプロジェクターを備えた施設のみが考慮される。

最高ランクの適切な施設を特定すると、セッションと施設がリンクされる。プロセスは、すべてのセッションと施設がリンクされるまで、前述のように続行される。

＜テーマパーク＞
一実施形態では、開示された方法をテーマパークに適用できる。以下の表１３は、一般的な方法で説明されている役割を果たすことができる当事者の例の概要を示す。

ステップ１０１において、主催者によって入力された施設情報は、各セッション、例えば各アトラクション、ショー、または乗り物に対する入場を含みうる。いくつかの実施形態では、主催者は、各セッションで利用可能な施設 (この例では座席) の数に関する情報を入力することもできる。いくつかの実施形態では、主催者は、たとえば、障害者がアクセスできるかどうか等の施設に関する関連情報を提供しうる。

いくつかの実施形態では、主催者はバッファ定数を設定することもできる。いくつかの実施形態では、バッファ定数は、約１日または状況に適した任意の時間であり得る。

テーマパーク設定の「プレビューセッション」は、出席者が利用できるセッションのリストがランカーに提供されたときに発生する。ランカーは、最も参加したいセッションをランク付けする。

いくつかの実施形態では、たとえば、いくつかの実施形態では、テーマパークにいる日数が少ない出席者は、彼らが利用可能なより短い時間で、確実に自分の最高の体験を体験できるようにするため、ランキングに所定の係数を掛ける等でランキング情報を変更したり、別の方法で変更したりする。出席者がテーマパークにいる日数は、チケットの長さによって示される場合がある。

いくつかの実施形態では、セッションの要件ランキングも厳格な要件に設定される。たとえば、テーマ パークの場合、すべてのセッションは対応する施設内で発生する可能性がある。つまり、セッションＡ（ログライド アトラクションの乗り物など）に参加する出席者は、セッションＡで利用可能な施設（例えば、上記のログライドアトラクションの座席）にリンクされている必要がある。

この情報が提供されると、各セッションの個別のランキングが決定され、最も高いユーティリティランキングのセッションがスケジューリングのために選択される。要件ランキングによって提供されるパラメータに適合する最高ランクの施設が識別される。たとえば、出席者が、例えば障害者用アクセスなど特定の要件を示した場合、利用可能として識別されたすべての施設はこの要件を満たす必要がある。

最高ランクの適切な施設を特定すると、セッションと施設がリンクされる。プロセスは、すべてのセッションと施設がリンクされるまで、前述のように続行される。

＜学校＞
一実施形態では、開示された方法を学校に適用できる。大規模なスケジュールシステムでは、学生、教授、その他のすべての個人が理想的なスケジュールに参加できることを保証することは困難である。ここに記載された方法およびシステムを使用すると、生成されたスケジュールは、従来の組織化された学校で可能であったよりも少ないリソースを使用しながら、学生、スタッフ、および管理者により大きな満足を提供できることが期待される。以下の表１４は、一般的な方法で説明されている役割を果たすことができる当事者の例の概要を示している。

ステップ１０１で、主催者が入力する施設情報には、施設の収容人数とタイプ、たとえば講堂、講義室、科学実験室、教室などを含めることができる。

いくつかの実施形態では、主催者は固定スケジュールを設定することもできる。いくつかの実施形態では、一定のターンオーバースケジュールは、その状況において適切である期間または任意の期間の長さであり得る。

学校設定の「プレビューセッション」は、コースガイドをプレビューして、所定の期間内に利用できるセッション（この場合はクラス）を特定する予定の学生（「ランカー」）である。ランカーは、コースガイドの情報に基づいて、参加を希望するセッションをランク付けする。

この例では、数値が大きいほど、このクラスは学生にとってより重要である。学生のランキングは、ユーザプロファイルの一部として保存される。学生は、バックグラウンドに関連するプレビュー情報を表示した後、またはその人物との以前の経験の形で、さまざまな教員、教授、インストラクター、講師、またはその他の同様の人物をランク付けすることもできる。

いくつかの実施形態では、ランキング情報を変更でき、たとえば、いくつかの実施形態では、プログラムの最終学年にある学生は、ランキングに所定の係数を掛けることができる。

いくつかの実施形態では、特定の出席者に関して受信されたランキング情報は、彼らの認識された最善の利益の観点から変更することができる。たとえば、学生が歴史のクラスを「４」とランク付けしているが、システムがその専攻が歴史にあり、卒業するためにさらに多くの歴史単位が必要であることを示している場合、システムはランキングにさらに「＋２」を割り当て、クラスの学生の変更されたランキングを全体で「６」にすることがある。

いくつかの実施形態では、個々の学生の過去の学業出席または成績記録に関する情報を使用して、ランキングの変更を決定できる。たとえば、全体的なパフォーマンスが優れている学生には、ランキングにより高い重みが与えられる場合がある。

いくつかの実施形態では、前提条件クラスに関係するスケジュールのコンフリクトが識別されてもよい。たとえば、学生がクラスのランキングを提出するとき、システムは「このクラスには前提条件はありますか？」と尋ねる場合がある。答えが「は」であるとき、システムは、１又は複数の前提条件を識別する。利用可能な以前の学期の出席と成績データと照合して、システムは「学生は前提条件を取得して合格しましたか？」と尋ねる場合がある。変更または追加される場合がある。答えが「はい」であるとき、前記前提条件を満たしたクラスの学生のオリジナルのランキングは、変更されないか、追加される可能性がある。答えが「いいえ」であるとき、学生が次の学期のためにそのようなクラスを希望することに誤りがあることが判明したため、その前提条件を有するクラスのオリジナルのランキングを下げる場合がある。

このタイプの変更係数の一例を図１０に示す。この例では、学生（出席者）がクラス（セッション）のランキング情報を提供する３２０。この例では、セッションが出席者の学位、証明書、認定、又は卒業の前提条件であるか否かに基づく次数の変更、及び、出席者がセッションに出席するために必要な前提条件を完了したか否かに基づく前提条件の変更、の両方が含まれる。

より具体的には、学位変更に関して、ランク付けされたクラスは、学生の学位３２２に関する情報と比較され、そのクラスが学生の学位３２４の前提条件であるかどうかが判定される。それが前提条件であるとき、学生がコースを受講し、合格したかどうかが判定される３２６。クラスを実際に受講および合格した場合、ランキングはゼロに設定され３２８、クラスの学生のランキングは変更される３３０。合格していない場合は、ランキングに、例えば＋５等の係数を追加できる３３２。

前提条件の変更に関しては、ランク付けされたクラス自体が前提条件クラスを持っているか判定される３３４。前提条件がなければ、ランキングにそれ以上の変更はなく、変更されたクラスランキングが設定される３３０。ランク付けされたクラスに前提条件がある場合、学生が前提条件クラスを受講して合格したか否か判定される３３６。そうでない場合、ランキングはゼロに設定される３３８（(学生は、前提条件を満たしていない場合、ランク付けされたクラスを受講できない）。学生が前提条件のクラスを受講して合格した場合、変更は行われない。ステップ３２４で、ランク付けされたクラスが学生の学位の前提条件でない場合、ランキングを変更せず３４２、方法はステップ３３４を継続する。

いくつかの実施形態では、学生が教育スタッフのランキングを自動的にまたは手動でシステムによって変更できる。たとえば、システムが過去の出席データをチェックし、その学生が以前にインストラクターのスポーツクラスに参加し、所定のしきい値を下回る点数を獲得したことがわかった場合、システムは、その学生とそのインストラクターがうまくパフォーマンスを上げられないという仮定に基づいて、そのインストラクターの学生の所定のランキングを下げることができる。

いくつかの実施形態では、セッションが科学実験室で行われなければならないなど、セッションの要件ランキングに厳格な要件を含めることができる。いくつかの実施形態では、セッションの要件ランキングは、例えば、セッションが学校のキャンパス内の特定の建物にある施設にあるというような優先傾向を含むことができる。

この情報が提供されると、各セッションの個別のランキングが決定され、最も高いユーティリティランキングのセッションがスケジューリングのために選択される。たとえば、セッションが科学実験室でのみ発生する等の要件ランキングによって提供されるパラメータに適合し、科学実験室である施設のみが考慮され、コンフリクトを最小限に抑えながら、予測出席者数に最も適合する最高ランクの施設が識別される。

最高ランクの適切な施設を特定すると、セッションと施設がリンクされ、特定の時間帯にスケジュールされる。その後、すべてのセッションと施設がリンクされ、すべてのセッションのスケジュールが完了するまで、前述のようにプロセスが続行される。

さらなる実施形態では、スケジュールを作成するときに、クラスおよび教授／教師／インストラクター／講師の両方の学生のランキングを考慮に入れることができる。いくつかの実施形態では、この情報を使用して登録プロセスを自動化できる。

いくつかの実施形態では、セッションを部屋および時間帯に割り当てるスケジュールが作成された後、教育スタッフがセッションに割り当てられてもよい。たとえば、スケジュールの中で最も高い総合ランキングのセッションは、最もランクの高い施設ですでにスケジュールされている可能性のある化学のクラスである可能性がある。化学を教えるのに利用できるすべてのスタッフをリストした教育スタッフのリストを特定できる。各スタッフメンバーには、すべての学生がランク付けするための集計ランキングが与えられ、変更されたランキングが合計される。特定されたサブセット（化学を教えることができる）から最高ランクの教育スタッフメンバーが、最高ランクのセッションを教えるように割り当てられる。

一部の実施形態では、すべてのセッションにインストラクターが割り当てられるまで、プロセスを繰り返すことができる。

いくつかの実施形態では、学生は予定されたクラスに自動的に登録されてもよい。各クラスと各インストラクターの独立した評価を以前に提出した学生に基づいて、割り当てられたインストラクターとの最終的なスケジュールを考慮して、更新されたクラスとインストラクターの組み合わせランキングを各学生に対して計算できる。一例では、その生徒のクラスのランキングと、クラスに割り当てられた教師のランキングを一緒にすることにより、全体で最も高いランキングのセッションを識別し、次に、このクラス セッションに参加する予定の学生のサブセットを識別できる。このサブセットのうち、システムは、新しく割り当てられたインストラクターを考慮して、このクラスの各生徒のランキングを計算できる。

いくつかの実施形態では、クラスが割り当てられた部屋の収容人数に基づいたクラスの座席数を決定でき、出席が予測されたサブセットからシステムによって生成された最高ランクのクラスインストラクター番号を持つ学生が、最初にクラスの座席が割り当てられ、部屋の収容人数の座席がなくなるまで、または出席予定のサブセットに生徒が残らなくなるまで、次の座席が割り当てられた学生に対して２番目に大きい番号が決定される。

いくつかの実施形態では、全体で２番目に高いランキングのセッションが識別され、プロセスが繰り返され、クラスとインストラクターの組み合わせ毎に、座席の収容人数が学生に割り当てられるか、出席予定の学生のサブセットがなくなるまで、新しく形成されたクラスと講師の組み合わせ内の座席に学生を割り当て続ける。この時点で、登録プロセスの自動部分は完了する。

上記に限定されることなく、本システムおよび方法は、以下の例によってさらに説明される。

＜例６＞
いくつかの実施形態では、この方法は、その学期（イベント）をスケジュールする学校を対象としうる。たとえば、学校には学期中に出席する予定の１００人の学生がいるとする。学校は合計４つのクラス（Ａ、Ｂ、Ｃ、Ｄ）を提供し、２つの時間帯で２つの部屋に分けられる。第１の部屋の収容人数は９０人であり、第２の部屋の収容人数は３０人である。

図９に概説されるように、１００人の学生はそれぞれ、学期の開始前に、クラスＡ、Ｂ、Ｃ、Ｄのプレビュー情報２０２を受信する。学生は、彼らが最も好きで最も必要なクラスを「４」とし、彼らが最も好きでなく、最も必要としないクラスを「１」として、重要度と好みの順にクラス２０４を評価するように求められる。応答が受信され２６０、この例について、表１５に示す。

多くの学生がアクセスできる最も人気があり重要なクラスは、学校の満足度を高め、プログラムの目標を達成するための学校の有用性を高める可能性が高いため、出席者の反応に基づいて、最も人気があり重要なクラスが決定され、学校の授業の学期スケジュールのアンカーとなる。

各クラスの有用性 (ここでは、人気と重要性の組み合わせを意味する) は、最初に総合スコア２８０を計算することで決定しうる。これは、各クラスに対して、その特定のクラスに１、２、３、または４のランキングを付けた人の数にランク値を掛け、それらの数値を全て加算することで行うことができる。たとえば、クラスＡの総合スコアは次のように計算できる：（６０×２）（２０×２）（１５×３）（５×３）＝２２０。

したがって、この場合、クラス（セッション）は次のように採点される。
クラスＡ － ２２０；
クラスＢ － ２７０；
クラスＣ － ３５５；
この情報から、最も人気のあるセッションを決定できる２１０。「４」が最高ランクであるので、最高スコアが最高ランクのクラスである。したがって、クラス Ｃは最もユーティリティが高く、最も多くの人がそれを必要としているか、最も好んでいる。

１日４クラス、また、２クラス同時開講で、全日同じスケジュールなので、全学期の各学生は最大２のフルクラスを受講できる。これは、個々の学生が最も高く評価した２つのクラスが、学生が出席することを示唆したものであり、理想的なスケジュールがあれば出席することが予測されることを意味する。

この情報を使用して、クラスＣに出席すると予測される学生数２１２は、ランキングの上位半分（この場合は４または３）にランク付けした学生の数を合計することで決定できる。表１５の情報を参照すると、この数は８０人であると決定される。

クラスＣの部屋を予約するため２１４、予測された学生数を部屋のサイズ情報と比較されうる。クラスＣは第１の部屋（大きい部屋）に割り当てられるべきであることがわかる。クラスＣは、第１の時間帯の第１の部屋で発生する最初のセッションとして、現在、仮にスケジュールに入れられている。

ここに記載の「ベストツーベスト」方法に従って、システムは次に、全体で２番目に高いランキングのセッション、つまり、スケジュールされておらず、したがってまだ残っている、ユーティリティランキングが最も高いセッションを特定することに進むことができる。

前述の情報を参照すると、ユーティリティランキングが最も高い残りのセッションはクラスＢである。クラスＢの部屋を予約するために、セッションに参加する学生の予測または予測数を部屋のサイズ情報と比較できる。この情報に関して、クラスＢは第１の部屋（(大きな施設）に割り当てられるべきであり、第１の部屋の利用可能な時間ブロックが識別されうる。第１の部屋の第１の時間ブロックはすでにクラスＣに割り当てられているため、第１の部屋で次に利用可能な時間ブロックは２番目の時間ブロックであり、クラスＢは第１の部屋の２番目の時間ブロック中にスケジュールできる。

システムは次に、残りの最も高いユーティリティランキングである、全体で３番目に高いランキングのセッションを特定できる。

前述の情報を参照すると、ユーティリティランキングが最も高い残りのセッションはクラスＡである。クラスＡの部屋を予約するために、予測された学生数を部屋のサイズ情報と比較できる。予想される生徒数は、２０人がクラスＡを「３」にランク付けし、誰も「４」にランク付けしていないことを考慮して、後述のように決定しうる。したがって、２０人の出席者が可能な場合、クラスＡに出席することが予測される。

施設の規模と比較した予想出席者数により、クラスＡは２つの部屋の小さい方でスケジュールする必要がある。両方の時間帯が利用可能であるため、クラスＡは２番目の部屋の第１の利用可能な時間帯に仮にリンクできる。

同時セッションがスケジュールされているため、コンフリクトが発生する可能性がある。この例の目的のために、コンフリクトは、仮に同時にスケジュールされたセッションに同じ出席者が出席したいと予測されるときはいつでも定義される。クラスＡを第２の部屋の第１の時間ブロックに配置することでコンフリクトが発生するか判定するため、クラスＡ（この場合はクラスＣ）と同時に実行されるセッションが識別され、出席者が両方のセッションに行くことが識別できる。

この例では、表１１の情報を参照すると、クラスＡとクラスＣの両方を理想的なスケジュールとしてランク付けした人はいない。クラスＡは、コンフリクトが特定されないため、第２の部屋の第１の時間ブロックにスケジュールできる。システムがコンフリクトの存在を発見した場合、図４で提案された方法に従って、クラスＡとクラスＣの両方が理想的なスケジュールにあることを示した１人または複数の人を識別した場合、第１の時間ブロックこの施設は破棄され、施設に利用可能な残りの時間ブロックが識別され、仮に選択され、結果として生じる組み合わせ自体のコンフリクトについてチェックされる。

システムは次に、残りの最も高いランクのセッション、この場合はクラスＤに進むことができる。クラスＤの出席者数を予測し、利用可能な施設のキャパシティと比較して、小さい部屋（第２の部屋）に適合するように決定される。クラスＤは、小規模な施設に仮にリンクされ、唯一の残りの時間ブロックに仮にスケジュールされる。この仮のスケジュールでコンフリクトは特定されないため、クラスＤは第２の時間帯の小さい施設でスケジュールされる。

次に、すべてのクラス（セッション）が部屋（施設）に予約されている（リンクされている）か尋ねられる２２２。この場合、答えは「いいえ」であり、方法はステップ２１０に戻り、第２の時間ブロックの残りのオプション（クラスＢ及びＤ）を使用して、後述のステップを繰り返す。この場合、残りの２つのオプションのうち、クラスＢが最上位にランク付けされているため、その出席予測者数が決定され、部屋、この場合は第１の部屋に割り当てられる。これは、クラスＤが同時に実行されることを意味し、表１５から、その予想出席者数により、クラスＤは第２の部屋に適合できる。

より複雑なシナリオでは、すべての学生が理想的な学期に出席できるとは限らないが、この方法を使用すると、より多くの学生が希望する学期に出席できるようになる。より複雑な状況では、この例で考慮されるものに加えて、またはその代わりに、追加の要因も考慮される場合がある。いくつかの実施形態では、学校管理者の全体的な目標は、どの要因が全体的なスケジュール生成計算にどの程度の重みを与えるかを指示する。

より複雑なシナリオでは、すべての学生が理想的な学期に出席できるとは限らないが、この方法を使用すると、より多くの学生が希望する学期に出席できるようになる。より複雑な状況では、追加の要因が、すでにスケジュールされたサブセットからの最も不利なランキングスコアとともに、またはそれに代えて考慮される場合がある。いくつかの実施形態では、学校管理者の全体的な目標は、どの要因が全体的なスケジュール生成計算にどの程度の重みを与えるかを指示する。

本開示の実施形態および例の前述の説明は、例示および説明を目的として提示された。網羅的であること、または開示を記載された形式に限定することを意図するものではない。上記の教示に照らして、多くの変更が可能である。それらの変更のいくつかは議論されており、他の変更は当業者によって理解されるであろう。

実施形態は、本開示の原理および企図される特定の使用に適した様々な実施形態を最もよく説明するために選択され、説明された。本発明の実施形態の上記の説明は、網羅的であること、または本発明を上記で開示された正確な形態または本開示で言及された特定の使用分野に限定することを意図するものではない。上記のさまざまな実施形態の要素および動作を組み合わせて、さらなる実施形態を提供できる。

本開示の範囲は、当然、本明細書に記載の例または実施形態に限定されるものではなく、当業者であれば、任意の数のアプリケーションおよび同等のデバイスに採用できる。むしろ、本発明の範囲は、添付の特許請求の範囲によって定義されることが意図されている。また、請求および／または説明されている方法については、その方法がフロー図と関連して説明されているかどうかに関係なく、文脈によって特に指定または要求されない限り、次の実行で実行されるステップの明示的または暗黙的な順序付けは、そのステップが提示された順序で実行される必要があることを意味するものではなく、異なる順序で実行されるか、並行して実行される可能性があることを理解すべきであろう。

いくつかの実施形態を示し説明したが、当業者は、本発明の範囲から逸脱することなく、様々な変更および修正を行うことができることを理解するであろう。前述の明細書で使用されている用語および表現は、ここでは、限定ではなく説明の用語として使用し、また、そのような用語および表現を使用して、示され説明されている機能またはその一部に相当するものを除外する意図はなく、本発明は、後述の特許請求の範囲によってのみ定義および制限されることを認識する。

本発明の特定の特徴または側面を説明する際に使用される特定の用語は、その用語が関連する本発明の特定の特性、特徴、または側面に限定されるように本明細書で再定義されていることを意味すると解釈すべきではない。一般に、後述の特許請求の範囲で使用される用語は、本発明を本明細書に開示された特定の実施形態に限定するものと解釈すべきではない。したがって、本発明の実際の範囲は、開示された実施形態だけでなく、本発明を実施または実装するすべての同等の方法を包含する。

Claims (35)

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. イベントを計画するコンピュータ実装方法であって、
    少なくとも１のイベントの、イベント情報を収集し、
    前記イベント情報をデータベースに記憶し、
    興味のあるイベント情報を選択し、
    前記興味のある選択されたイベント情報の少なくとも一部に基づいて、第２のイベントを開発する
    方法。

Images