特開 2024-74256 自動化されたスケジューリングを改善するための方法、自動化されたスケジューリングのためのスケジューリングサーバ、およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024074256

(43)【公開日】2024-05-30

(54)【発明の名称】自動化されたスケジューリングを改善するための方法、自動化されたスケジューリングのためのスケジューリングサーバ、およびシステム

(51)【国際特許分類】

   G06Q 10/109 20230101AFI20240523BHJP

【ＦＩ】

G06Q10/109

【審査請求】有

【請求項の数】12

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2023189885

(22)【出願日】2023-11-07

(31)【優先権主張番号】22208335.4

(32)【優先日】2022-11-18

(33)【優先権主張国・地域又は機関】EP

(71)【出願人】

【識別番号】503113186

【氏名又は名称】ホンダ リサーチ インスティテュート ヨーロッパ ゲーエムベーハー

【氏名又は名称原語表記】Ｈｏｎｄａ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ Ｅｕｒｏｐｅ ＧｍｂＨ

(74)【代理人】

【識別番号】110001081

【氏名又は名称】弁理士法人クシブチ国際特許事務所

(72)【発明者】

【氏名】ローデマン，トビアス

(57)【要約】      （修正有）

【課題】自動化されたスケジューリングを改善するための方法、自動化されたスケジューリングのためのスケジューリングサーバ及びシステムを提供する。
【解決手段】自動化されたスケジューリングは、設定がそれぞれのユーザのユーザ選好および個人的な制約を定義する取得するステップと、スケジュール目標から導き出されたシステム境界条件および決定されるべきスケジュールを適用することによって実現されることになる所望の目標を実現するために関与した技術的機器の技術的条件を取得するステップと、ユーザ固有の設定とシステム境界条件との組合せから特定されたスケジューリング問題を解決することによって、スケジュールを計算するステップと、を含む。
【選択図】図２

【特許請求の範囲】

【請求項1】

複数のユーザによって入力されたユーザ設定に少なくとも部分的に基づいた自動化されたスケジューリングを改善するための方法であって、
複数のユーザについてのユーザ設定を取得するステップであって、前記設定がそれぞれのユーザのユーザ選好および個人的な制約を定義する、取得するステップと、
スケジュール目標から導き出されたシステム境界条件、および決定されるべきスケジュールを適用することによって実現されることになる所望の目標を実現するために関与した技術的機器の技術的条件を取得するステップと、
ユーザ固有の設定と前記システム境界条件との組合せから特定されたスケジューリング問題を解決することによって、スケジュールを計算するステップと
を含み、
前記取得されたユーザ設定とは異なる設定である代替ユーザ設定についての受け入れ確率を予測するステップと、
少なくとも１つの代替ユーザ設定を選択して、それぞれの選択された代替設定についての代替スケジュールを計算するステップと、
代替スケジュールごとに改善か改悪かを判定するために、前記計算された代替スケジュールおよび初期に計算されたスケジュールを品質尺度に関して評価するステップと、
前記評価の結果および前記予測された受け入れ確率に基づいて、その設定が代替設定によって影響されるユーザに提案されることになる前記代替設定を決定するステップと、
前記提案された代替設定に対する前記ユーザの応答を読み込むステップ、および前記ユーザが断った場合に別の代替設定を選択するステップ、または、前記代替設定を取得されたユーザ固有の設定として受け入れることを続行するステップ、およびスケジュールの計算、代替設定の選択、代替スケジュールの計算、代替設定の評価および選択および提案、ならびに前記ユーザ応答の読み込みを、停止基準が満たされるまで繰り返すステップと、
最後に計算されたスケジュールを適用するステップと
によって特徴付けられる、
自動化されたスケジューリングを改善するための方法。

【請求項2】

受け入れ確率の前記予測が、前記ユーザの挙動履歴、以前の受け入れ率、ユーザ入力情報、および一般的な領域知識のうちの少なくとも１つに基づく、請求項１に記載の方法。

【請求項3】

前記方法が、設定された閾値を上回る受け入れ確率を有する前記代替ユーザ設定から、最も大きい品質尺度改善を有するものを決定する、請求項１または２に記載の方法。

【請求項4】

前記方法が、前記ユーザについての不都合尺度を推定し、提案されることになる前記代替ユーザ設定の決定のために前記不都合尺度を考慮に入れる、請求項１から３のいずれか一項に記載の方法。

【請求項5】

前記選択が、より低い不都合尺度を有するユーザの代替ユーザ設定を提案するための優先順位を決める、請求項３に記載の方法。

【請求項6】

前記不都合尺度が経時的に累積される、請求項４または５に記載の方法。

【請求項7】

請求項１から６のいずれか一項に記載の方法を実行するように構成されたスケジューリングサーバ。

【請求項8】

請求項７に記載のスケジューリングサーバと、
前記スケジューリングサーバによって生成され、かつ代替ユーザ設定に関する要求を、ユーザに出力するためのユーザ通信インターフェースと
を含む、自動化されたスケジューリングを改善するためのシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、最終的に出力されるスケジュールの改善された品質によりスケジューリングを自動化する問題に関し、詳細には、自動化されたスケジューリングを改善するための方法、本発明の自動化されたスケジューリングを実行する、自動化されたスケジューリングのためのスケジューリングサーバ、およびシステムに関する。

【背景技術】

【0002】

複数の個人的な選好および制約、システム性能、ならびに取り組まれる対象の要件が同時に考慮される必要がある、かなりの数の異なる適用分野が存在している。それほど複雑ではない問題の場合、これは、関与する人々の異なる選好、技術的機器の利用可能性、および最後にスケジュールの対象または目標として行われる必要がある作業を承知しているオペレータによって行われてもよい。しかしながら、ますますより複雑で多様になるワーキングスタイルに伴い、個々の要件は、より複雑になる傾向にある。モバイルワーキングに向かう動向を念頭に置くと、一定の従業員は、週のうちのごく一部しか対応できない可能性があり、およびさらには、月の最大時間限度が低く制限されている可能性があることは明らかである。このようにして、個人的な、ならびに技術的な、規制上の、およびビジネス側からの両方から、すべての選好および制約を満足させる最適なスケジュールを見つけることは、難易度の高いタスクである。幸いにも、データ処理における改善されたパフォーマンスおよび最適化問題を解決する増加した数のアルゴリズムが、そのようなスケジューリング問題を解決する自動化において、より高い段階を可能にしている。

【0003】

にもかかわらず、すべての関与する人について満足がいくように思われる解決策を見つけることは、なおも十分に難しい。当然ながら、たとえばサービスレベルであり得る品質スコアもしくは品質インデックス、所望のサービスレベルに到達するために追加で費やされなければならない金額、またはそれぞれのスケジュールを実践することから生じるサービスレベルにおける低減に関して、たとえば、複数の異なるスケジュールを互いに関して評価することが可能である。

【0004】

過去において、スケジュールを最適化しようともっぱら試みるかなりの数のアプローチが開発されており、それらのアプローチは、関与する人の選好を定義することができるそれらの人の入力から開始して、スケジューリングがそのために実施されることになるタスクもしくは目標、または必要とされる技術的機器によってもたらされる、制約についての知識もまた取得する。

【0005】

たとえば、Ｂｅｒｒｙ，Ｐ．Ｍ．，Ｇｅｒｖａｓｉｏ，Ｍ．，Ｐｅｉｎｔｎｅｒ，Ｂ．，およびＹｏｒｋｅ－Ｓｍｉｔｈ、Ｎ．２０１１．ＰＴＩＭＥ：「ｐｅｒｓｏｎａｌｉｚｅｄ ａｓｓｉｓｔａｎｃｅ ｆｏｒ ｃａｌｅｎｄａｒｉｎｇ」（ＡＣＭ Ｔｒａｎｓ．Ｉｎｔｅｌｌ．Ｓｙｓｔ．Ｔｅｃｈｎｏｌ．２，４，Ａｒｔｉｃｌｅ ４０（２０１１年７月））は、ユーザ選好を学習して、ミーティングを自動的に同期するために使用される機械学習アプローチを開示している。このモデルは、ユーザインターフェースを使用して、ユーザ選好が特定されることを想定している。しかしながら、これらの選好は、不完全である、または矛盾している。より正確なユーザ設定を学習するためには、ユーザとの経時的な対話が提案される。この情報は、ミーティングのすべての参加者に選択肢を持ちかけるためだけに使用され、参加者は次いで、ミーティングの特定の日付および時間を協議し、同意しなければならない。ミーティングのための日付および時間を見出すための最終決断は、関与する人々の直接協力を伴うので、提案されたアプローチは、より大きなグループの人々では機能する見込みが低い。

【0006】

さらに、人々の充電要件などのタスクの彼らの定義において、それらの人々を適応させるように誘引するシステムが知られている。そのような１つのアプローチは、Ｓ．Ｌｉｍｍｅｒ．「Ｄｙｎａｍｉｃ ｐｒｉｃｉｎｇ ｆｏｒ ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ ｃｈａｒｇｉｎｇ－ａ ｌｉｔｅｒａｔｕｒｅ ｒｅｖｉｅｗ」（Ｅｎｅｒｇｉｅｓ，１２（１８）：３５７４，２０１９）において見出すことができる。ここでは、価格インセンティブを使用して、ユーザの充電要件に適応させるように、ユーザを動機付けることが試行される。

【0007】

米国特許出願公開第２００７０２８２４７６（Ａ１）号は、複雑なスケジューリング環境においてタスクを調整およびスケジュールするために使用される、コンピュータシステムなどの、ワークフロースケジューリングシステムを開示している。システムは、注文のために必要とされるリソースの制約、および注文それ自体のあらゆる制約に従って、入ってくる注文を受け入れ、それらを動的にスケジュールする。提案されたシステムは、なんらかの品質尺度に従って、多数のスケジュールをコンピュータ計算し、ランク付けする。異なるスケジュールは、同じスキルを持つ異なる看護師、または異なるＸ線スキャナのような、代替リソースの異なる組合せを採用する。したがって、代替スケジュールは、あらかじめ知られているシステムの柔軟性に基づく。

【0008】

経時的にユーザ選好を学習するための別の例が、Ｍａｋｏｔｏ Ｏｈａｒａ，Ｈｏｓａｓｈｉ Ｔａｍａｋｉ：「Ｐａｒａｍｅｔｅｒ Ａｄｊｕｓｔｍｅｎｔ Ａｐｐｒｏａｃｈ Ｂａｓｅｄ ｏｎ Ｄｉｓｔｒｉｂｕｔｉｏｎ ｏｆ Ｓｃｈｅｄｕｌｅｓ ｉｎ ｔｈｅ Ｐａｓｔ ｆｏｒ Ｓｔａｆｆ Ｓｃｈｅｄｕｌｉｎｇ Ｐｒｏｂｌｅｍｓ」に記述されている。

【0009】

しかしながら、知られているシステムは、前もって収集された情報に依拠する、または、実際のユーザの挙動から開始して選好は経時的に決定されるという問題がなおも存在している。そのため、ユーザが、自分自身の柔軟性に関する情報、またはより厳密な要件およびそれほど厳密ではない要件についての情報を入力することによって、そのことを自分自身で認識するのではない場合、システムは、収集または学習された設定からの逸脱を必要とする潜在的な改善を、決して識別することはできないであろう。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】米国特許出願公開第２００７０２８２４７６（Ａ１）号

【非特許文献】

【0011】

【非特許文献1】Ｂｅｒｒｙ，Ｐ．Ｍ．，Ｇｅｒｖａｓｉｏ，Ｍ．，Ｐｅｉｎｔｎｅｒ，Ｂ．，およびＹｏｒｋｅ－Ｓｍｉｔｈ、Ｎ．２０１１．ＰＴＩＭＥ：「ｐｅｒｓｏｎａｌｉｚｅｄ ａｓｓｉｓｔａｎｃｅ ｆｏｒ ｃａｌｅｎｄａｒｉｎｇ」（ＡＣＭ Ｔｒａｎｓ．Ｉｎｔｅｌｌ．Ｓｙｓｔ．Ｔｅｃｈｎｏｌ．２，４，Ａｒｔｉｃｌｅ ４０（２０１１年７月））

【非特許文献2】Ｓ．Ｌｉｍｍｅｒ．「Ｄｙｎａｍｉｃ ｐｒｉｃｉｎｇ ｆｏｒ ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ ｃｈａｒｇｉｎｇ－ａ ｌｉｔｅｒａｔｕｒｅ ｒｅｖｉｅｗ」（Ｅｎｅｒｇｉｅｓ，１２（１８）：３５７４，２０１９）

【非特許文献3】Ｍａｋｏｔｏ Ｏｈａｒａ，Ｈｏｓａｓｈｉ Ｔａｍａｋｉ：「Ｐａｒａｍｅｔｅｒ Ａｄｊｕｓｔｍｅｎｔ Ａｐｐｒｏａｃｈ Ｂａｓｅｄ ｏｎ Ｄｉｓｔｒｉｂｕｔｉｏｎ ｏｆ Ｓｃｈｅｄｕｌｅｓ ｉｎ ｔｈｅ Ｐａｓｔ ｆｏｒ Ｓｔａｆｆ Ｓｃｈｅｄｕｌｉｎｇ Ｐｒｏｂｌｅｍｓ」

【発明の概要】

【発明が解決しようとする課題】

【0012】

本発明の目的は、知られているスケジューリングアルゴリズムを改善することである。本問題は、独立請求項において特許請求される主題によって解決される。従属請求項は、本発明の有利な態様を定義する。

【課題を解決するための手段】

【0013】

本発明は、自動化されたスケジューリングを改善するための方法、方法のステップを実行するスケジューリングサーバ、ならびに、スケジューリングサーバおよび関与する人と通信するための手段を含むスケジューリングシステムに関する。方法によれば、自動化されたスケジューリングは、複数のユーザによって入力されたユーザ設定に少なくとも部分的に基づく。まず、初期のスケジュールが計算される前に、複数のユーザについてのユーザ設定が取得される。これらの設定は、個々のユーザ選好およびそれぞれのユーザの個人的な制約を定義する。そのようなユーザ選好および制約（通例、「ユーザ設定」と呼ばれる）を入力するために、ユーザによって入力された情報をサーバに伝達する能力のある任意の種類の通信方法が使用されてよく、サーバにおいて、収集された情報は次いで、さらに処理される。したがって、所望のユーザ設定についての情報を入力するために、ユーザが中央サーバ（またはさらには分散型サーバシステム）と通信するのを可能にする、ユーザによる選好および制約を入力するための、たとえばスマートフォンのようなモバイルデバイスを考えることができ、そこではそれぞれのアプリケーションが稼働する。さらに、システム境界条件が取得される。そのようなシステム境界条件は、スケジュール目標に取り組むためのスケジュールを首尾よく実践するために、満足させる必要がある外部要件を含む。

【0014】

そのような外部要件は、履行されることが所望されるタスク、または実現されるべき目標のいずれかによってもたらされることがあり、あるいは、そのような目標の実現に技術的なシステムが関与する場合には、技術的なシステムによってもたらされるツールなどの利用可能性のような制限もまたもたらされることがある。

【0015】

これまでのところ、提案された方法およびシステムは、当技術分野において知られているシステムに対応している。システム境界条件、ならびにユーザ選好および制約（ユーザ設定）によって定義される取得された設定から開始して、スケジューリング問題が公式化され、このスケジューリング問題に対する初期の解決策が計算される。この計算されたスケジュールは、初期のスケジュールを意味し、参照スケジュールとして、この参照スケジュールに対する代替案を分析するために後で使用される。公式化されたスケジューリング問題を解決するために、たとえば、線形プログラミング（ＬＰ）のような標準アプローチ、ローカル近隣検索（ＬＮＳ）のような発見的アプローチ、または進化的アルゴリズム（ＥＡ）などを使用することができる。

【0016】

現実のシナリオの場合、計算されることになるスケジュールに関与する人々が、ありとあらゆる選好または制約に対する彼らの柔軟性に関して、常にすべての情報を提供することをいとわない、または提供することができる、というわけではないことは明らかである。本発明によれば、方法はこれより、ユーザによって入力された設定とは異なる設定である代替ユーザ設定についての受け入れ確率を予測する。ユーザの初期の入力によってユーザにより定義される選好から開始して、そのような代替設定が考慮され、これらの代替設定について、ユーザの入力した選好または制約からのそのような逸脱をユーザが受け入れる可能性がある確率が、受け入れ確率として計算される。それぞれの代替設定について、受け入れ確率が予測される。一旦代替設定についての受け入れ確率が予測されると、これらの代替ユーザ設定のうちの少なくとも１つが選択され、これらの選択された代替設定のそれぞれについて、代替スケジュールが計算される。このようにして、複数の代替ユーザ設定が選択された場合、複数の代替スケジュールもまた計算される。これらの代替スケジュールは次いで、初期に取得されたユーザ設定から選択された代替設定にユーザ設定を変えることによって改善または改悪が実現されたかどうかを判定するために、初期のスケジュールに関して比較されて評価される。選択のためにそれらの代替ユーザ設定を選択する１つの可能性である、ユーザの個々の受け入れ確率は、たとえば、一定の閾値を上回る受け入れ確率を有するすべての代替ユーザ設定を選ぶことによって、または最も高い受け入れ確率を有する一定の合計数の代替ユーザ設定を選ぶことによって、考慮される可能性がある。

【0017】

この評価の結果および予測された受け入れ確率に基づいて、代替設定が決定され、代替設定は次いで、代替設定によって、およびしたがって、それぞれに評価された代替スケジュールによって、その設定が影響されるユーザに提案される。提案は、たとえば、ユーザがそれを通じて自分の選好および制約を初期に入力したアプリを使用して行うことができる。このアプリを使用して、代替設定についての提案がユーザに対して行われ、システムは、スケジューリングサーバによって読み込まれたユーザの反応に応じて続行する。

【0018】

ユーザは、提案された代替設定を断る可能性がある。その場合、システムは、別の代替設定を選択することによって続行する。ユーザが提案が行われたことを認識していない、またはユーザが協力する気がない、またはユーザが予測されるよりも柔軟性に欠けているという理由で、ユーザがまったく反応しない場合、そのユーザは提案された代替設定を断ったと想定される可能性がある。

【0019】

あるいは、ユーザが提案された代替設定を受け入れた場合、この代替設定が、新しいユーザ設定であるとみなされ、この新しいユーザ設定に基づいて、手順が繰り返される。これは、新しい参照スケジュールが決定され、さらなる代替ユーザ設定に基づいて、新しい参照スケジュールに関して上で言及されたように、代替スケジュールが計算され、評価されることを意味する。代替ユーザ設定および計算された代替スケジュールの識別は、停止基準が満たされるまで繰り返される。そのような停止基準とは、たとえば、すべての残りの代替設定について、最終スケジュールのさらなる改善を実現することができない（もしくは十分にできない）こと、または、最小閾値を上回った状態にある受け入れ確率を有するさらなる代替ユーザ設定を識別することができないことであってよい。最終的に実現されるスケジュールは次いで、さらなる処理のために適用または出力される。技術的なシステムのみが関与する場合、スケジュールは、システムを制御するために直接使用されてもよい。人々が関与する場合、最終スケジュールは、ユーザが最終的に実現されるスケジュールについての知識を有し、それに応じて行動することができるように、ユーザに出力される。

【0020】

本発明の一態様によれば、受け入れ確率の予測は、ユーザの挙動履歴、提案された代替ユーザ設定の以前の受け入れ率、ユーザ入力情報、および一般的な領域知識のうちの少なくとも１つに基づく。一定の選好または制約についての受け入れ確率を予測するためにユーザの挙動履歴が分析されることになる場合、過去における実際のユーザ挙動についての情報を観察し、ログすることが必要である。特定のユーザの受け入れ率が分析されることになる場合、ユーザに対して行われた提案およびユーザの反応を記録することが必要である。ユーザの柔軟性に関してユーザによって入力された情報を、受け入れ確率の予測の中に含めることもまた可能である。たとえば、ユーザは、自分の一般的な柔軟性を時々入力する可能性があり、次いでそれが、ユーザの定義した選好および制約のそれぞれについての受け入れ確率を予測するために使用される。さらに、一般的な領域知識がまた、ユーザの柔軟性を決定するために使用されてもよい。たとえば、システムのオペレータの経験によれば、ほとんどの場合、ユーザは充電セッションの開始時間の遅延を最長３０分まで受け入れる可能性があると言うことがある。そのような一般的な領域知識は、オペレータの経験および過去における観察から得られることがあり、システムのオペレータによって手動で入力されてもよい。

【0021】

スケジュールの全体的な改善を実現するために、ユーザが自分の設定における変更を受け入れるかどうかをユーザに通信要求するために第一に使用される代替設定の決定は、どの代替設定が一定の閾値を上回る受け入れ確率を有するのかを最初に決定することができる。次いで、一定の閾値を上回る受け入れ確率を有するこれらの代替設定から、最も大きい品質尺度改善を実現する設定が決定される。あるいは、代替ユーザ設定は、それらのそれぞれの受け入れ確率によってランク付けされてもよく、あらかじめ定義された数の上位ランク付けされた代替ユーザ設定が選択される。

【0022】

一般に、品質尺度改善として、任意の種類の主観的または客観的な尺度が考慮されてよく、これは、参照としての初期のスケジュールおよび代替スケジュールに関与するメトリックから計算することができる。上に記したように、基礎をなす代替設定の受け入れ確率が一定の閾値を超える代替スケジュールのみが考慮される。識別され得る代替設定の数を考慮して、閾値を適応させることさえも考慮されてよい。たとえば、代替設定の数が別の閾値を下回る場合、考慮することができる増加した数の代替設定を取得するために、受け入れ確率についての閾値が適応されてもよく、与えられた事例では、たとえば引き下げされてもよい。

【0023】

さらに、代替設定を受け入れるように要求されることによってユーザが煩わされることを回避するために、ユーザとの通信がそのために開始される代替設定の決定において、ユーザにとっての不都合尺度が考慮されてもよい。そのような不都合尺度は、一定の要求によるユーザの迷惑または煩わしさについての指標である。指標として使用されてもよい１つの例は、一定のユーザへの要求の数がカウントされること、および時間当たりの要求の数が要求率閾値を超えた場合、さらなる要求が、潜在的な改善とは無関係にブロックされること、またはそのような改善で重み付けされることである。これは、改善が大きくなるほど、あらゆる不都合尺度に対する閾値が高くなる可能性があり、それにより、この特定の代替ユーザ設定に対する要求の却下につながることを意味する。

【0024】

そのような場合、不都合尺度が経時的に累積されるとすれば、とりわけ有利である。これにより、より長い対象期間の間にさえ、設定の考え得る適応についてシステムによって問われることによってユーザが煩わされることになり、その結果、最後にはそのようなユーザがシステムに参加するのをやめてさえしまう可能性が、回避されることを保証する。つまり、不都合尺度は２つの態様に及んでよく、まずそれは、単一のイベントについて、ユーザに対するインパクトがどのくらい大きいかを指し示すことである。たとえば、開始時間を週のうちの別の曜日にずらすことは、開始時間を３０分間だけずらすことよりも、ユーザにとっては意味が大きいことがある（より高い不都合尺度）。さらに、既に上で言及されたように、同じユーザに繰り返し要求することは、単一のイベントに対する不都合さが低い場合でさえ、ユーザにとってはうっとうしいことがある。このようにして、特定のユーザに対するそれぞれのさらなる要求は、このユーザに対する全体的な不都合尺度を増加させる結果を生じることになる。

【0025】

本発明はこれより、付属の図面を参照して記述されることになり、図面においては、システム、そのサーバ、および方法についての好ましい例が、とりわけ好ましい適用範囲を参照して例証される。以下で与えられる説明は、特許請求される主題を限定することなく、システムおよび方法の実践をさらに説明するのみであることに留意されたい。本発明は、添付の特許請求の範囲において定義され、従属請求項は、特定の改善および好ましい実施形態の態様に関する。

【図面の簡単な説明】

【0026】

【図1】充電システムを例として使用する、本発明によるサーバを含むシステムのブロック図である。

【図2】図１に例証された充電システムを使用する、本発明の方法の全体的な構造を示す図である。

【発明を実施するための形態】

【0027】

上で言及されたように、本発明はこれより、充電システムを参照して説明されることになる。当然ながら、これは、本発明を実践し、適用するための１つの好ましい実施形態のみとして理解されなければならない。さらなる例は、従来の個人的なスケジューリング、または従業員用の機器の使用をスケジュールすることのような同様の問題であってもよい。後者の場合、参加する人々によって左右され得ない、システムについての境界条件が存在することがとりわけ明らかである。たとえば、開発プロセスにおいてソフトまたはハードの最終期限もしくはマイルストーンに適合するように求められることがある一定のアクティビティのタイミングだけでなく、たとえば、最終的に実現されるスケジュールを実践するために必要とされる利用可能なツールおよび機械の数も、外部要件（システム境界条件）である。さらに、充電システム、およびしたがって充電アクティビティの例の代わりに、ユーザ（顧客）があらかじめ予約をすることができる燃料補給アクティビティでも、同じ問題が持ち上がる。顧客からの先行予約を使用する充電または燃料補給システムの場合、これらのアクティビティは、顧客の選好に最適に適合するようにだけでなく、ピーク電力負荷、メンテナンス需要、または燃料の利用可能性のような技術的制限もまた考慮するように、スケジュールされる必要がある。加えて、そのようなアクティビティのタイミングは、朝の時間における大きな騒音、ピークコスト時間の間に増加したエネルギーコスト、その他のさらなる悪影響を有することがあり、たとえば、朝の時間における騒音について低減した閾値などのそれぞれのさらなる外部要件（システム境界条件）を定義することによって、これらの影響を考慮に入れることができる。

【0028】

図１は、本発明の方法を適用し、最適されたスケジュールを最終的に出力するために、すべての必要な情報を収集する単一のスケジューリングサーバを備えるシステム１を示している。当然ながら、本発明の理解を容易にするために例証されている単一のサーバを使用する代わりに、クラウドコンピューティングまたは複数の接続されたサーバを使用することもまた可能である。ユーザ入力選好および制約のセット（ユーザ選好および制約だけでなく外部要件もまた）から開始するスケジュールの基本計算は、一般に本技術分野において知られていることに再度留意されたい。このようにして、それぞれのシステムは、説明および例証の完全さのためだけに、例として示されている。本発明は、システムに前もって入力された、少なくとも１つの、またはさらには複数のユーザの設定に関して、一定のユーザの柔軟性を推定すること（予測すること）についてであることが重要である。この柔軟性は、不完全である、または少なくとも所望通りに正確ではない可能性のある、ユーザによって入力された情報に、もはや拘束されないように推定される。

【0029】

概して、システムに参加するユーザは、自分の選好および制約をユーザ設定として、インターフェース３を介して、スケジューリングサーバ２に入力する。スケジューリングサーバ２は、それぞれのユーザまたはそれぞれのユーザアカウントについて入力ユーザ設定が記憶されるメモリ７を含む。ユーザインターフェース３は、プロセッサ８を介して、不揮発性メモリであるメモリ７に接続される。プロセッサ８は、通例知られているやり方で、たとえば、ユーザのスマートフォン１０上で稼働するアプリケーションを使用して、ユーザインターフェース３を介したユーザとの通信を編成し、実行するように構成される。

【0030】

システムインターフェース４は、外部要件としてのシステム境界条件についての情報を取得するために使用され、外部要件は、本事例において、充電システム１１によってもたらされてよい。図１に例証されているように、利用可能な充電ステーションの数は、自分の電気車両を時々充電することを必要とする可能性のある参加するユーザの数よりも大幅に少ない。このようにして、関与する充電システム１１によってもたらされるすべての技術的制限は、システムインターフェース４を使用して、システムに入力される。

【0031】

本事例においては、単一のプロセッサ８が例証されている。しかしながら、必要な計算を通例実行する複数のプロセッサが使用されてもよい。ユーザまたは充電システム１１などの外部パーティとの通信を編成し、実行するために、そのような複数のプロセッサのそれぞれが、インターフェース３、４のうちの１つに接続されることもまた可能である。さらなるインターフェース５は、サーバ２をオペレータに接続するために使用され、オペレータは、例証される実施形態において、コンピュータシステム６として示されている。そのようなコンピュータシステム６を介して、システム１のオペレータは、システム１によって行われる選択に、または自動化された選択および代替設定もしくは代替スケジュールの決定のための閾値を定義することに、手動で干渉することができてよい。後で説明されることになるように、コンピュータシステム６は、特定のユーザ設定についての受け入れ確率を予測するために、領域知識を入力するためにとりわけ使用されてよい。

【0032】

最終的に、必要であれば、結果、すなわち最終スケジュールを、さらなるパーティに配信するために、出力インターフェース９がプロセッサ８に接続される。通常、最終スケジュールは、ユーザインターフェース３を介してスマートフォン１０に出力され、充電システム１１の適応が（たとえば、充電パラメータを制御するために）必要な場合は、充電システム１１のバックボーンにもまた出力されることになる。

【0033】

図１に例証されたシステム１の動作が、これより図２を参照して説明されることになる。

【0034】

上で説明されたように、あらゆるスケジュールの計算が可能になる前に、ユーザは、アプリがそこで稼働している自分のスマートフォン１０を使用して、自分の選好および制約をユーザ設定として入力する。選好および制約は、メモリ７に記憶される。さらには、（システム境界条件の少なくとも一部を定義する）ビジネス需要が、システムインターフェース４を介して入力され、それぞれの設定もまたメモリ７に記憶される。次のステップにおいて、スケジュールがそのために計算されることになる目標に関してスケジュールのあらゆる計算が実施され得る前に、すべての設定（ユーザ選好、ユーザ制約、および外部制約）が、メモリ７から、プロセッサ８によって取得される。この情報に基づいて、ユーザによって提供され、システムによって取得された設定を、固定された入力として取って、初期スケジュールが計算される。この初期スケジュールはまた、代替案の評価のために後で使用されるために、「参照スケジュール」と呼ばれる。

【0035】

通例知られているシステムにおいては、この初期スケジュールが、いわゆるアクティビティスケジュールとして出力されることになる。このようにして、最初の、初期スケジュールまたは参照スケジュールの計算は、最新技術から知られているように実行されてよい。これは、通例知られているシステムに対応する上半分と、本発明による、知られているシステムの拡張に関する下半分とを分離している一点鎖線によって例証されている。

【0036】

本発明の中心的な態様は、ユーザ選好および制約（すなわちユーザ設定）が、固定されているとみなされないことである。既に上で言及された通り、設定は、しばしば不正確または不完全なやり方でユーザによって入力される。これは、異なる値を有することがある入力パラメータに基づいた初期スケジュール（最新技術において計算される唯一のスケジュール）の計算につながり、この異なる値が、劇的に改善されるスケジュール品質につながる可能性がある。そこで本発明の概念は、ユーザが自分の設定の変更を受け入れた場合に、最終スケジュールの改善が実現され得るかどうかを判定するために、ユーザ設定の一定の柔軟性を考慮することである。

【0037】

上で説明されたように、こうして一旦初期スケジュールまたは参照スケジュールが計算されると、ユーザ設定へのバリエーションが実施される。概して、あらゆるユーザ設定は、それに基づいて代替スケジュールを計算するために、変化する可能性がある。しかしながら、これは、計算を必要とすることになる途方もない量の潜在的な代替スケジュールにつながることになる。したがって、ユーザ設定におけるどの変更が、ユーザによって受け入れられる可能性があるかが最初に推定される。したがって、ユーザの挙動を学習するために、ユーザ挙動が最初に調べられ、それが、設定のどの変更またはどの代替案がそれぞれのユーザによって受け入れられる可能性があるのかという結論につながることがある。学習された挙動から、人の柔軟性のモデルが計算され、モデルに基づいて、代替スケジュールの計算のための基礎を形成する代替設定が選択される。

【0038】

潜在的に変更される可能性のあるユーザ設定ごとに、受け入れ確率が予測される。この受け入れ確率は、ユーザが最初に入力した設定を変更するように要求された場合に、ユーザがそのような変更を受け入れる可能性がどのくらいの見込みであるかの尺度である。したがって、それは、特定の設定に関するユーザの柔軟性の推定である。この推定は、たとえば、過去の時間期間（たとえば、ユーザは、過去における何度かの機会に、たとえば火曜日の充電セッションを受け入れている）に基づくことができる、または、通常システムのオペレータが有する一般的な領域知識に基づくことができる。たとえば、システムのオペレータは、遅延が３日未満であれば、ほとんどの場合、異なる平日の充電は受け入れ可能であるということを観察していることがある。そのような知識は、たとえば、オペレータインターフェース５およびコンピュータ６を介して入力されてよい。柔軟性はまた、ユーザが柔軟性についての追加の情報を直接提供する場合には、ユーザ入力から直接導き出されてもよい。たとえば、ユーザは、普段は日曜日もまた大丈夫であるものの最適ではない、という情報をシステムに入力する可能性がある。そのため、ユーザがまた、自分の電気車両を土曜日に再充電することを望むという選好を入力した場合、システムは、日曜日の代替予約はユーザによって受け入れられる見込みがあるだろうという知識を有する。

【0039】

さらに、たとえば、開始時間のような設定についてはすべてのユーザが柔軟である（確率＝１００％）と初期に想定され、ユーザが変更への要求を拒否するごとに、そのようなタイプの変更要求について予測される受け入れ確率が半分にされることもまた可能である。いくつかの等しく見込みのある要求の場合、ランダムな選択が行われてもよい。システムは次いで、最も高い確率を有する一定のあらかじめ定義された数の代替ユーザ設定を選択し、代替スケジュールを計算するために、それぞれの代替設定についてスケジュール最適化を再計算することになる。ユーザ設定（代替ユーザ設定）についての他の値に基づいた代替設定の再計算は、参照スケジュールの初期の計算とまさしく同じやり方で行われ、ユーザ設定のバリエーション、すなわち、代替設定を単に使用するにすぎないことに留意されたい。

【0040】

一旦代替スケジュールが計算されると、参照スケジュールに関して改善が実現されることが認識され得る、特定の代替スケジュールまたは複数の代替スケジュールを識別するために、評価が遂行される。この評価は、参照スケジュールを参照して代替スケジュールのそれぞれについて計算され得る任意の指標であってよい品質尺度に基づいて行われる。たとえば、２つの項からなる、問い合わせについてのコスト関数をコンピュータ計算することができる。Ｃ＿ｅｎｑｕｉｒｙ＝Ｃ＿ｕｓｅｒ－ｗ×Ｃ＿ｓｙｓｔｅｍ、ここで、Ｃ＿ｕｓｅｒは、ユーザに対するコスト、たとえば、要求を拒否する確率Ｐ＿ｒｅｊｅｃｔであり、Ｃ＿ｓｙｓｔｅｍは、修正された要求により実現可能な、低減された全体的なシステムコストである（たとえば、ユーロにおけるコスト節減）。重み係数ｗは、ユーザおよびシステムオペレータの利益のバランスを取るために手動で選択され、コンピュータシステム６およびオペレータインターフェース５を介して設定されてよい。Ｃ＿ｅｎｑｕｉｒｙがあらかじめ定義された閾値を上回る場合、プロセスは停止され、接触されるユーザはいないことになる。

【0041】

どの代替ユーザ設定がそれぞれのユーザに提案されるかの決定は、参照スケジュールに対する代替スケジュールの品質尺度の比較に基づいて行われるだけでなく、予測される受け入れ確率もまた考慮に入れて行われる。これは、最初に、たとえば、最も大幅な改善を有する代替スケジュールにつながる代替設定が識別されることを意味する。次いで、この代替設定について、受け入れ確率が、最小閾値を上回った状態にあるかどうかをチェックされる。受け入れ確率についてのそのような最小閾値を使用することにより、ユーザへの不必要な要求が回避されることを保証する。最終スケジュールが実現され得るまでの全体的な時間を低減することを別としても、これはまた、ユーザにとってうっとうしい可能性のある、ユーザに転送される要求を低減する。代替ユーザ設定を決定するためのシーケンスが逆になってもよいことは明らかである。つまり、最初に、最小閾値を上回った状態にある受け入れ確率を有するすべてのユーザ設定が識別され、次いで、改善が最も大きな影響を有する代替ユーザ設定が決定される。

【0042】

さらに、ユーザにもたらされる不都合を推定することができる。これは、たとえば、代替ユーザ設定を受け入れるようにユーザが既にどのくらい頻繁に要求されているかをカウントすることによって行われてよい。そのような場合、一定のユーザ設定の一般的な受け入れ確率が高かったとしても、特定のユーザを煩わせるのを停止するために、そのような要求をユーザに転送することが回避される。これは、たとえば、代替ユーザ設定を、ユーザの不都合尺度で重み付けされたそれらの受け入れ確率によってランク付けすることによって実現されてもよい。この不都合尺度は、同じユーザに関連付けられた複数の設定について同じであってもよい。不都合尺度は、たとえば、受信された要求の頻度に、または特定のユーザに対する要求率に基づいて決定されてもよい。

【0043】

上の条件が履行された特定の代替ユーザ設定が一旦識別されると、そのような代替ユーザ設定についての提案が、ユーザインターフェース３を介して、ユーザのスマートフォン１０に転送される。ユーザはなおも、そのような改正されたユーザ設定を受け入れることを断る選択肢を有する。その場合、システムは、この特定のユーザ設定を却下し、次に最善な解決策につながる代替使用設定がユーザに転送および提案され得るかどうかを判定することによって続行することになる。これは、前と同じユーザであっても、または別のユーザであってもよい。

【0044】

ユーザが受け入れた場合、参照スケジュールは、それに応じて更新されることになる。これは、受け入れられた代替ユーザ設定が次いで、ユーザ設定を表すものとみなされ、新しい参照スケジュールを計算するために、初期に実施された通りにスケジュールの計算が繰り返されることを意味する。それ以降、上で説明されたのと同じ手順が繰り返されることになる。これは、再度、複数の代替ユーザ設定が識別され、さらなる改善が実現される可能性があるかどうかを判定するために、代替スケジュールが新しい参照スケジュールと比較されることを意味する。その場合、さらなる代替ユーザ設定が、上で説明されたのとまさに同じやり方で識別され、（当然ながら、再度、上で説明されたように、そのような要求を決定し、ユーザに転送するための他の条件が履行された場合にのみ）ゆくゆくはユーザに提案される。

【0045】

この手順は、停止基準が満たされるまで繰り返される。そのような停止基準は、たとえば、実現される改善が閾値を下回っており、それがユーザを煩わせるに値しないこと、受け入れ確率が一定の閾値を上回った状態にある代替ユーザ設定をこれ以上識別することができないこと、または、ユーザについて推定された不都合が一定の閾値を超え、その結果、最終スケジュールの可能な改善とは関係なく、ユーザを煩わせるに値しないとみなされることであってよい。他の停止基準、または言及された基準の組合せが考えられてもよい。

【0046】

一旦停止基準に到達すると、最後に計算された参照スケジュールが、最終スケジュールとして使用され、ユーザに、または、関与する技術的機器のさらなる処理もしくは制御のためにスケジュールを必要とする任意の他の外部エンティティに出力される。

【0047】

最終的に出力され、適用可能であるスケジュールの品質を大幅に改善する提案された方法は、提案された代替使用設定と共に、インセンティブシグナルをユーザに提供することによって、さらに一層改善されてもよい。たとえば、ユーザは、初期に提供されたユーザ選好および制約からの変更を行うことによって、予期される節減分のうちの所与の割り当てを受け取ることが可能である。そのようなインセンティブはまた、過去において既に貢献したユーザに対して強化されてもよい。ユーザの貢献が大きかったほど、強化が大きくてもよい。

【0048】

自分の設定を適応させるように、または代替設定に従って実際に行動するように問われることによるユーザの不都合尺度は、一般的な人の心理モデルに基づいていても、社内で協議されても、または要求の後に収集されたフィードバックに応じて、それぞれのユーザについて学習されてもよい。

【図1】

【図2】

【手続補正書】

【提出日】2024-04-03

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

複数のユーザによって入力されたユーザ設定に少なくとも部分的に基づいた自動化されたスケジューリングを改善するための方法であって、
複数のユーザについてのユーザ設定を取得するステップであって、前記設定がそれぞれのユーザのユーザ選好および個人的な制約を定義する、取得するステップと、
スケジュール目標から導き出されたシステム境界条件、および決定されるべきスケジュールを適用することによって実現されることになる所望の目標を実現するために関与した技術的機器の技術的条件を取得するステップと、
ユーザ固有の設定と前記システム境界条件との組合せから特定されたスケジューリング問題を解決することによって、スケジュールを計算するステップと
を含み、
前記取得されたユーザ設定とは異なる設定である代替ユーザ設定についての受け入れ確率を予測するステップと、
少なくとも１つの代替ユーザ設定を選択して、それぞれの選択された代替設定についての代替スケジュールを計算するステップと、
代替スケジュールごとに改善か改悪かを判定するために、前記計算された代替スケジュールおよび初期に計算されたスケジュールを品質尺度に関して評価するステップと、
前記評価の結果および前記予測された受け入れ確率に基づいて、その設定が代替設定によって影響されるユーザに提案されることになる前記代替設定を決定するステップと、
前記提案された代替設定に対する前記ユーザの応答を読み込むステップ、および前記ユーザが断った場合に別の代替設定を選択するステップ、または、前記代替設定を取得されたユーザ固有の設定として受け入れることを続行するステップ、およびスケジュールの計算、代替設定の選択、代替スケジュールの計算、代替設定の評価および選択および提案、ならびに前記ユーザ応答の読み込みを、停止基準が満たされるまで繰り返すステップと、
最後に計算されたスケジュールを適用するステップと
によって特徴付けられる、
自動化されたスケジューリングを改善するための方法。

【請求項2】

受け入れ確率の前記予測が、前記ユーザの挙動履歴、以前の受け入れ率、ユーザ入力情報、および一般的な領域知識のうちの少なくとも１つに基づく、請求項１に記載の方法。

【請求項3】

前記方法が、設定された閾値を上回る受け入れ確率を有する前記代替ユーザ設定から、最も大きい品質尺度改善を有するものを決定する、請求項１に記載の方法。

【請求項4】

前記方法が、設定された閾値を上回る受け入れ確率を有する前記代替ユーザ設定から、最も大きい品質尺度改善を有するものを決定する、請求項２に記載の方法。

【請求項5】

前記方法が、前記ユーザについての不都合尺度を推定し、提案されることになる前記代替ユーザ設定の決定のために前記不都合尺度を考慮に入れる、請求項１に記載の方法。

【請求項6】

前記方法が、前記ユーザについての不都合尺度を推定し、提案されることになる前記代替ユーザ設定の決定のために前記不都合尺度を考慮に入れる、請求項２に記載の方法。

【請求項7】

前記方法が、前記ユーザについての不都合尺度を推定し、提案されることになる前記代替ユーザ設定の決定のために前記不都合尺度を考慮に入れる、請求項３に記載の方法。

【請求項8】

前記選択が、より低い不都合尺度を有するユーザの代替ユーザ設定を提案するための優先順位を決める、請求項３に記載の方法。

【請求項9】

前記不都合尺度が経時的に累積される、請求項５に記載の方法。

【請求項10】

前記不都合尺度が経時的に累積される、請求項８に記載の方法。

【請求項11】

請求項１から１０のいずれか一項に記載の方法を実行するように構成されたスケジューリングサーバ。

【請求項12】

請求項１１に記載のスケジューリングサーバと、
前記スケジューリングサーバによって生成され、かつ代替ユーザ設定に関する要求を、ユーザに出力するためのユーザ通信インターフェースと
を含む、自動化されたスケジューリングを改善するためのシステム。

【外国語明細書】