知財求人 - 知財ポータルサイト「IP Force」
▶ ソシアス テクノロジーズ （アイピー） リミテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-07-25
(54)【発明の名称】電子リソース割り当て制御のための方法及びシステム
(51)【国際特許分類】
G06F 11/30 20060101AFI20240718BHJP
G06F 9/50 20060101ALI20240718BHJP
【ＦＩ】
G06F11/30 151
G06F9/50 120Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023557100
(86)(22)【出願日】2022-06-21
(85)【翻訳文提出日】2023-09-14
(86)【国際出願番号】 EP2022066822
(87)【国際公開番号】W WO2022268774
(87)【国際公開日】2022-12-29
(31)【優先権主張番号】21180627.8
(32)【優先日】2021-06-21
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】523351818
【氏名又は名称】ソシアス テクノロジーズ （アイピー） リミテッド
(74)【代理人】
【識別番号】100094569
【弁理士】
【氏名又は名称】田中 伸一郎
(74)【代理人】
【識別番号】100103610
【弁理士】
【氏名又は名称】▲吉▼田 和彦
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【氏名又は名称】上杉 浩
(74)【代理人】
【識別番号】100120525
【弁理士】
【氏名又は名称】近藤 直樹
(74)【代理人】
【識別番号】100139712
【弁理士】
【氏名又は名称】那須 威夫
(74)【代理人】
【識別番号】100141553
【弁理士】
【氏名又は名称】鈴木 信彦
(74)【代理人】
【識別番号】100158551
【弁理士】
【氏名又は名称】山崎 貴明
(72)【発明者】
【氏名】ジャクソン アレックス
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042JJ16
5B042KK01
5B042MA05
5B042MA08
5B042MC22
(57)【要約】
受け取ったデータモデル、受け取った履歴データ及び受け取ったエラーデータに基づいて、コンピュータ化リソースリポジトリの目標状態を計算する。データモデルは、複数のコンピュータ化リソースリポジトリの各コンピュータ化リソースリポジトリの状態を１又は２以上の入力に基づいて更新するためのルールを含む。各コンピュータ化リソースリポジトリの状態は、これらの各コンピュータ化リソースリポジトリ内のリソースの量を含む。履歴データは、データモデルへの複数の以前の入力を含む。エラーデータは、履歴データの以前の入力のうちの１つにエラーがあることを示す。その後、受け取られたデータによって示されるコンピュータ化リソースリポジトリ内の現在のリソースの量と、コンピュータ化リソースリポジトリの目標状態におけるリソースの量との間の差分を決定する。最後に、差分を修正するために、決定された差分に等しい量のリソースを制御用コンピュータ化リソースリポジトリからコンピュータ化リソースリポジトリに割り当てる。
【選択図】 図６
【選択図】 図６
【特許請求の範囲】
【請求項1】
リソース割り当てシステム内の複数のコンピュータ化リソースリポジトリを制御するためのコンピュータ実装方法であって、前記複数のコンピュータ化リソースリポジトリの、各コンピュータ化リソースリポジトリ内のリソースの量を含む前記各コンピュータ化リソースリポジトリの状態を１又は２以上の入力に基づいて更新するためのルールを含むリソースのデータモデルと、
前記データモデルへの複数の以前の入力を含む履歴データと、
前記複数のコンピュータ化リソースリポジトリのうちの第１のコンピュータ化リソースリポジトリにおける現在のリソースの量を示すデータと、
前記履歴データの前記以前の入力のうちの１つにおけるエラーを示すエラーデータと、
を受け取ることと、
前記データモデル、前記履歴データ及び前記エラーデータに基づいて、前記第１のコンピュータ化リソースリポジトリの目標状態を計算することと、
前記第１のコンピュータ化リソースリポジトリ内の前記現在のリソースの量と、前記第１のコンピュータ化リソースリポジトリの前記目標状態におけるリソースの量との差分を決定することと、
前記差分を修正するために、前記決定された差分に等しい量のリソースを制御用コンピュータ化リソースリポジトリから前記第１のコンピュータ化リソースリポジトリに又はこの逆に割り当てることと、
を含むことを特徴とするコンピュータ実装方法。
【請求項2】
１又は２以上のデータモデル入力を受け取ることと、前記データモデル及び前記１又は２以上の受け取られたデータモデル入力に基づいて、前記複数のコンピュータ化リソースリポジトリのうちの１又は２以上のコンピュータ化リソースリポジトリの状態を更新することと、
をさらに含む、請求項１に記載のコンピュータ実装方法。
【請求項3】
前記制御用コンピュータ化リソースリポジトリ内の現在のリソースの量が閾値範囲外にあるかどうかを判定することと、前記判定に従って、前記制御用コンピュータ化リソースリポジトリの状態を更新して前記量を閾値範囲内に収めることと、
をさらに含む、請求項１又は請求項２に記載のコンピュータ実装方法。
【請求項4】
前記コンピュータ化リソースリポジトリの状態を更新することは、前記コンピュータ化リソースリポジトリ内のリソースの量を増加又は減少させることを含む、請求項２又は請求項３に記載のコンピュータ実装方法。
【請求項5】
前記コンピュータ化リソースリポジトリのリソースの量を増加又は減少させることは、前記実装するコンピュータの外部ソースからのリソースの量を増加又は減少させることによって更新することを含む、請求項４に記載のコンピュータ実装方法。
【請求項6】
前記増加又は減少は第１の機械的遅延に関連する、請求項５に記載のコンピュータ実装方法。
【請求項7】
前記第１の機械的遅延は、前記外部ソースから発生した遅延によって生じる、請求項６に記載のコンピュータ実装方法。
【請求項8】
前記決定された差分に等しい量のリソースを割り当てることは第２の機械的遅延に関連し、該第２の機械的遅延は前記第１の機械的遅延よりも短い、請求項６又は請求項７に記載のコンピュータ実装方法。
【請求項9】
前記第１の機械的遅延は、１時間～７２時間の範囲内、又は１２時間～４８時間の範囲内であり、前記第２の機械的遅延は、１２時間未満、１時間未満、１分未満、１秒未満、１０ミリ秒未満、又は０．１ミリ秒未満である、請求項８に記載のコンピュータ実装方法。
【請求項10】
前記決定された差分に等しい量のリソースを割り当てることは瞬時に行われる、請求項１から請求項９のいずれかに記載のコンピュータ実装方法。
【請求項11】
前記第１のコンピュータ化リソースリポジトリの前記目標状態は、前記エラーが発生しなかったと仮定した場合に前記データモデル及び履歴データに従って想定される前記第１のコンピュータ化リソースリポジトリの現在の状態に対応する、請求項１に記載のコンピュータ実装方法。
【請求項12】
前記複数のコンピュータ化リソースリポジトリのうちの第２のコンピュータ化リソースリポジトリにおける現在のリソースの量を示すデータを受け取ることと、前記データモデル、前記履歴データ及び前記エラーデータに基づいて、前記第２のコンピュータ化リソースリポジトリの目標状態を計算することと、
前記第２のコンピュータ化リソースリポジトリ内の前記現在のリソースの量と、前記第２のコンピュータ化リソースリポジトリの前記目標状態におけるリソースの量との差分を決定することと、
前記差分を修正するために、前記決定された差分に等しい量のリソースを前記制御用コンピュータ化リソースリポジトリから前記第２のコンピュータ化リソースリポジトリに又はこの逆に割り当てることと、
をさらに含む、請求項１から請求項１１のいずれかに記載のコンピュータ実装方法。
【請求項13】
各データモデル入力は、複数の入力プロバイダのうちのある入力プロバイダから受け取られ、前記制御用コンピュータ化リソースリポジトリは複数の制御用コンピュータ化リソースリポジトリのうちの１つであり、各制御用コンピュータ化リソースリポジトリは入力プロバイダに関連し、
前記差分を修正するために選択される前記制御用コンピュータ化リソースリポジトリは、前記エラーの原因である入力プロバイダに関連する、
請求項１から請求項１２のいずれかに記載のコンピュータ実装方法。
【請求項14】
命令を含むメモリと、プロセッサとを含む装置であって、前記命令は、前記プロセッサによって実行された時に、請求項１から請求項１３のいずれか１項に記載の方法を前記プロセッサに実行させるように構成される、ことを特徴とする装置。
【請求項15】
コンピュータ可読命令を含むコンピュータプログラムであって、前記コンピュータ可読命令は、プロセッサによって実行された時に、請求項１から請求項１３のいずれか１項に記載の方法を前記プロセッサに実行させるように構成される、ことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、リソース割り当てシステム内の複数のコンピュータ化リソースリポジトリ（ｃｏｍｐｕｔｅｒｉｓｅｄ ｒｅｓｏｕｒｃｅ ｒｅｐｏｓｉｔｏｒｉｅｓ）を制御するための、具体的には１又は２以上のコンピュータ化リソースリポジトリの実際の状態とデータモデルに従う目標状態との間の差分を修正するためのコンピュータ実装方法及びシステムに関する。
【背景技術】
【0002】
現在では、電子的に保存されたリソースのコンピュータ実装制御のための幅広い様々な用途においてコンピュータ化データリポジトリが使用されている。多くの場合、これらのリソースは、これらを保存するために使用されるコンピュータシステムの外部に「物理的」存在を有しておらず、或いは少なくとも、（限定するわけではないが）プロセッサレジスタ、ランダムアクセスメモリ（ＲＡＭ）ハードウェア、メモリカード、フラッシュドライブ及びソリッドステートドライブなどのフラッシュメモリデバイス、又はハードディスクドライブなどの長期記憶装置を含むことができるコンピュータハードウェアの内部に存在する、１又は２以上の（場合によってはネットワーク化された）コンピュータシステム内のリソースとしてのみ存在することができる。これに加えて又は代えて、これらのリソースは、コンピュータシステムの内部又は外部のリソース又は資産の電子デジタル表現であるという意味で、「論理的」又は「仮想的」リソースであるとも考えられる。例えば、多くの現代のコンピュータシステムは、オペレーティングシステムによって知覚される「論理的」メモリアドレスと、コンピュータハードウェア内の実際の「物理的」アドレスとを区別している（これらは実質的に異なるように配置することができる）。
【0003】
多くの場合は、複数のコンピュータ化リソースリポジトリを制御するためにコンピュータシステムを使用することができ、各リポジトリは任意の瞬間に何らかの「状態」にあり、この状態は何らかの特定量のリソースを含み、又はこのような特定量のリソースに関連する。さらに、リポジトリを制御するコンピュータシステムは、複数のリポジトリのうちの少なくとも１つのリポジトリに保持されている又は関連するリソースの量を調整することによって特定の入力に応答することが望ましく又は必要であると考えられる。これらの入力は、ユーザ生成によるもの又は機械生成によるものであることができ、ソースから直接的に、又は間接的に制御に到着することができる。さらに、リソースの量を調整する決定、この調整の方向（量を増加させるかそれとも減少させるか）、及び調整の大きさは、入力だけでなく調整すべきリポジトリ（又は複数のリポジトリ）の現在の状態にも依存することができる。
【0004】
このため、コンピュータシステムは、入力を処理する際に、到着した入力に応答してリポジトリを１つの特定の状態から次の状態にどのように「進める」べきであるかを正確に指定する一連のルールを含む「データモデル」に従うことができる。
【0005】
任意のリポジトリの状態は、そのリポジトリ内に保持されている又はそのリポジトリに関連するリソースの量に関連することができるので、実際に入力に応答してデータモデルによって決定された通りにリポジトリの状態更新を実行すると、そのリポジトリに物理的又は論理的に保持されているリソースの量／数量／総量の重大な変更が必要になる場合がある。通常、既知の既存のリソース割り当てシステムは、データモデルに従って、リソース割り当てシステムの外部ソースから必要なさらなる量のリソースを獲得することによって、或いは検出された余分な量のリソースをこのような外部ソースに逆に放棄することによってリポジトリの状態を更新することができる。
【発明の概要】
【発明が解決しようとする課題】
【0006】
このような外部ソースは、様々な技術的理由で不完全な場合がある。例えば、いくつかの状況では、例えばネットワークを介してリソースプロバイダからの又はリソースプロバイダへの特定量のリソースの獲得又は放棄に関する電子要求を送信することによってコンピュータ化リソースリポジトリにリソースを獲得する（又はコンピュータ化リソースリポジトリからリソースを放棄する）ことができる。この結果、このリポジトリのリソースの量は、例えばリソースプロバイダが再び可能性として同じネットワークを介して又は別のネットワークを介してリポジトリへの（又はリポジトリからの）リソースの量を直接割り当てることによって増加（又は減少）することができる。しかしながら、多くの文脈では、リソースプロバイダが、要求内で指定された量のリソースを正確にリポジトリに提供する（又はリポジトリから取り去る）ことによって確実に電子要求に応答できない場合がある。すなわち、リポジトリ（又はリポジトリの代わりにコントローラ）が獲得又は放棄するように最初に要求したリソースの量と、リポジトリに保持されているリソースの量がその後に実際に増加／減少する量（及び／又はリソースプロバイダとリポジトリとの間で転送される量）とが異なる場合がある。例えば、外部ソースの性質は、何らかの所与のリソースを１０「単位」獲得する要求に応答して実際にはリポジトリに１２単位をクレジットするようなものであると考えることができる。
【0007】
或いは、いくつかの文脈では、コントローラが、少量のリソースを獲得／放棄する要求、中程度の量のリソースを獲得／放棄する要求及び大量のリソースを獲得／放棄する要求などの様々な大きさの量のリソースを獲得（又は放棄）する要求をリソースプロバイダに送信することはできるものの、獲得又は放棄すべきリソースの正確な単位数を具体的に要求できない場合がある。このような場合、実際に獲得又は放棄されるリソースの単位数は要求内で指定された大きさに密接に対応することができるが、それにもかかわらず任意の大きさの量を求める要求に応答して何単位が獲得／放棄される予定であるかを予め決定しておくことは困難又は不可能な場合がある。
【0008】
なお、当業者であれば、上記の非限定的な説明例（及び本開示全体を通じて示す他の説明例）は整数量で転送可能及び／又は記憶可能な離散的リソースに関するものであるが、本発明は決してこのような離散的リソースタイプ（例えば、メモリ内の論理ビット）への応用に限定されるものではなく、非整数量（例えば、非限定的な例として、メモリデバイス内の読み込み／プログラム電圧などの有理数又は実数によって表現できる量）で転送及び／又は保存できる連続的リソースに関するリソース割り当てシステムの制御にも同様に適用可能であると理解するであろう。
【0009】
また、外部ソースは、一方ではコンピュータ化リソースリポジトリに一定量のリソースを獲得する（又はリソースリポジトリから放棄する）要求と、他方ではそのリポジトリに保存された又は関連する総リソース量のその後の変化との間に機械的遅延（ｌａｔｅｎｃｙ ｄｅｌａｙ）をもたらすという点でも不完全と考えられる。この機械的遅延は、ネットワーク上の待ち時間／遅延／輻輳、リソースプロバイダにおける要求の処理の機械的遅延、又は別の要因、或いはこれらの要因の組み合わせが原因となり得る。いずれにせよ、このような遅延（１つでも存在する場合）は、更新ルールに従って外部ソースとの間でリソースを獲得又は放棄することによって複数のコンピュータ化リソースリポジトリ内の各コンピュータ化リソースリポジトリのリソースの量を管理するデータモデルを正常に日常的に使用するという目的のためには不可避及び／又は容認可能と判断される場合がある。
【0010】
しかしながら、一連の入力に応答してコントローラがこのように正常にデータモデルを使用してリポジトリとの間でリソースの獲得又は放棄を行うことが続いた後に、モデルへの以前の入力のうちの１つが誤っていたと判定されることにより、少なくとも１つのリポジトリの現在の状態に含まれるリソースが、（データモデルの更新ルールに照らして「修正された」以前の入力に基づいて）少なくとも１つのリポジトリが現在有していなければならない量と比べて多すぎる又は少なすぎるようになった状況では、これらの問題がはるかに大きくなる。
【0011】
コンピュータ実装されたリソースコントローラがこれらのエラーを「修正」する１つの方法は、データモデルと、各リポジトリを時間と共に１つの状態から次の状態に繰り返し進めるために以前に使用されていた過去の入力データと、エラー及びその修正の詳細とに基づいて目標とするリポジトリの状態（すなわち、「あるべき」状態であり、エラーが発生しなければそうであったと思われる状態）を計算した後に、この目標状態をリポジトリの実際の現在の状態（エラーの影響を受けた）と比較してリソースの量の差分を決定することであると思われる。例えば、エラーを含む入力から最新のモデル入力までのモデルへの全ての入力をこのようにして再生し、これに応じて各リポジトリの状態の進化をシミュレートすることにより、リポジトリに含まれるリソースの量が多すぎる又は少なすぎると判定することができる。この時、コントローラは、この単純な解決策では、現在リポジトリに保持されている又は関連しているリソースの量を増加又は減少させようと試みることにより、目標状態と実際の状態との間の不一致を修正しようと試みることができる。この試みは、例えばリソースプロバイダなどの外部ソースに（決定された不一致に等しい量のリソースを獲得／放棄する）要求を送信することによって行うことができる。
【0012】
この手法の問題点は、エラーの修正自体も外部ソースによって導入される同じ機械的遅延を受け、すなわち入力のエラーが検出され、その修正値が受け取られ、更新ルールに従ってリポジトリ状態の進化を再生し、従って目標状態を計算するためにこの修正値が他の以前の入力と共に使用され、実際の状態／目標状態の差分が決定され、外部ソースに対するリソースの獲得又は放棄を要求することによってエラーを修正する試みが行われた後であっても、リポジトリの状態が無期限に、すなわち永久に又は任意の長期にわたって依然として不正確な（すなわち、データモデル及び以前の入力によって決定される「目標」状態と比べて異なる量のリソースを有する）場合がある点である。
【0013】
さらに悪いことには、機械的遅延の期間中（従って、１又は２以上のリポジトリ内のリソースの量の不一致が決定された後であって不一致を修正するためにリソースの量が増加又は減少される前）にコントローラが新たなデータモデル入力を受け取ってしまっていることもある。従ってこのような例では、コントローラが、外部ソースから一定量のリソースを獲得し又は外部ソースに一定量のリソースを放棄することによってエラーが完全に解決されるまでリポジトリ状態の更新を延期／停止するか（この方法は恐らくは受け入れられないであろう）、或いはリソースの獲得／放棄を待っている間にいずれかの新たな入力を受け取った時に関連する状態の更新を全て適用し、最終的に要求したリソースが入って来た（又は出て行った）時には、その間にもリポジトリの独自の状態は新たな１又は複数の入力に応答して移行してしまっているので、もはやこのリソースは不一致の修正に必要な正確な量ではないという事実に対処することを必要とせざるを得ない。
【0014】
簡潔に上述したように、上記の問題は、コントローラによって要求された正確な量のリポジトリリソース量を増加及び／又は減少させるために外部ソースを信頼できない場合にはさらに複雑化する。例えば、リソースプロバイダは、要求された正確な量のリソースをコンピュータ化リソースリポジトリに常に割り当てることができる（又はその意思がある）とは限らない。これに加えて又は代えて、リソースプロバイダは、コンピュータ化リソースリポジトリから指定量のリソースを常に取り除くことができる（又はその意思がある）とも限らない。この結果、多くの状況では、計算された不一致を修正するためにリソースリポジトリに／から一定量のリソースを獲得又は放棄しようと試みると、電子的に割り当てられる量が多すぎる又は少なすぎることによってさらに「誤った」量が保存され、従ってエラーが（完全に）解決されるのではなく、ある段階で１つの時点から後の時点に単純にエラーが（部分的に）伝播する可能性が高いため、上述した手法を使用してエラーを修正することは非常に困難であることが分かる。
【0015】
本発明の目的は、一群のコンピュータ化リソースリポジトリ内のリソース割り当ての制御に関連する上述の及びその他の問題を解決することである。
【課題を解決するための手段】
【0016】
本発明の第１の態様では、リソース割り当てシステム内の複数のコンピュータ化リソースリポジトリを制御するためのコンピュータ実装方法であって、複数のコンピュータ化リソースリポジトリの、各コンピュータ化リソースリポジトリ内のリソースの量を含む各コンピュータ化リソースリポジトリの状態を１又は２以上の入力に基づいて更新するためのルールを含むリソースのデータモデルと、データモデルへの複数の以前の入力を含む履歴データと、複数のコンピュータ化リソースリポジトリのうちの第１のコンピュータ化リソースリポジトリにおける現在のリソースの量を示すデータと、履歴データの以前の入力のうちの１つにおけるエラーを示すエラーデータとを受け取ることと、データモデル、履歴データ及びエラーデータに基づいて、第１のコンピュータ化リソースリポジトリの目標状態を計算することと、第１のコンピュータ化リソースリポジトリ内の現在のリソースの量と、第１のコンピュータ化リソースリポジトリの目標状態におけるリソースの量との差分を決定することと、差分を修正するために、決定された差分に等しい量のリソースを制御用コンピュータ化リソースリポジトリから第１のコンピュータ化リソースリポジトリに又はこの逆に割り当てることと、を含むコンピュータ実装方法を提供する。
【0017】
一連のリポジトリ間でリソースがどのように分配されているかを綿密に管理し、及び／又はシステム内への、システムからの、及びシステム内部でのリソースの流れを管理することが必要な又は望ましい状況では、しばしばリソース割り当てのためのデータモデルが上手く採用されている。このようなモデルは、化学処理、製造、水処理又は燃料ベース発電などの、シミュレーション又はモデルによって決定されるリポジトリ状態の変化又は更新と実際の物理的リソースの獲得又は放棄との間に「ラグ」又は「遅延」の要素が存在し得る業界において、入力に応じた推定される又は理想的なリソース量の割り当てをモデル化するために使用することができる。同様に、このような機械的遅延は、計算及びデータ処理などの電子的な形でのみ又は主に電子的な形で存在するリソースを伴うデータモデルの分野でも感じられることがある。
【0018】
制御用コンピュータ化リソースリポジトリを使用することにより、リポジトリコントローラは、現在の量と目標量との間に生じた不一致を１回のリソース量の割り当てで修正できるようになり、もはや（例えば、何らかの量のリソースを獲得又は放棄するためにリソースプロバイダなどの外部ソースに要求を送信する）より低速な及び／又は信頼度の低い解決策に依拠する必要がなくなる。このことは、以前の入力データにおけるエラーに起因して第１のリポジトリが誤った状態にあるという問題を、さらなるデータモデル入力によってモデルが後続の処理段階に進んでリポジトリの次の一連の状態更新を計算することによって潜在的に第１のリポジトリの状態にも影響を与えてしまう前に（単に伝播させ及び／又は部分的に解決するのではなく）完全かつ正確に解決できることを意味する。従って、誤った入力データの影響が（制御用リポジトリが存在しない場合のように）悪化するのではなく、直接排除される。
【0019】
任意に、方法は、１又は２以上のデータモデル入力を受け取ることと、データモデル及び１又は２以上の受け取られたデータモデル入力に基づいて、複数のコンピュータ化リソースリポジトリのうちの１又は２以上のコンピュータ化リソースリポジトリの状態を更新することと、をさらに含むことができる。
【0020】
これに加えて又は代えて、任意に、方法は、制御用コンピュータ化リソースリポジトリ内の現在のリソースの量が閾値範囲外にあるかどうかを判定することと、この判定に従って、制御コンピュータ化リソースリポジトリの状態を更新して量を閾値範囲内に収めることと、をさらに含むことができる。これにより、制御用リポジトリがリソースの量を所定の「許容」範囲内に維持することが確実になるため、（産業用リソース制御システムなどでしばしば見られるような）制御用リポジトリに蓄積されるリソースの余剰、及び／又は制御用リポジトリに蓄積されるリソースの不足又は欠損を防ぐことが望ましい場合に有益である。
【0021】
コンピュータ化リソースリポジトリの状態を更新することは、コンピュータ化リソースリポジトリ内のリソースの量を増加又は減少させることを含むことができる。コンピュータ化リソースリポジトリのリソースの量を増加又は減少させることは、実装するコンピュータの外部ソースからのリソースの量を増加又は減少させることによって更新することを含むことができる。
【0022】
増加又は減少は第１の機械的遅延に関連することができる。例えば、第１の機械的遅延は、外部ソースから発生した遅延によって生じることがある。決定された差分に等しい量のリソースを割り当てることは第２の機械的遅延に関連することができ、第２の機械的遅延は第１の機械的遅延よりも短い。
【0023】
第１の機械的遅延は、１分～１週間、１０分～１週間、３０分～１週間、１時間～１週間、６時間～１週間、１２時間～１週間、又は１日～１週間の範囲内であることができる。第１の機械的遅延は、１分～５日、１０分～５日、３０分～５日、１時間～５日、６時間～５日、１２時間～５日、又は１日～５日の範囲内であることができる。第１の機械的遅延は、１分～３日、１０分～３日、３０分～３日、１時間～３日、６時間～３日、１２時間～３日、又は１日～３日の範囲内であることができる。第１の機械的遅延は、１分～１日、１０分～１日、３０分～１日、１時間～１日、６時間～１日、又は１２時間～１日の範囲内であることができる。上記の例では、「１日」は２４時間を意味し、「１週間」は１６８時間を意味する。
【0024】
第１の機械的遅延は、０．１ミリ秒～１０分、０．１ミリ秒～５分、０．１ミリ秒～２分、０．１ミリ秒～１分、０．１ミリ秒～３０秒、０．１ミリ秒～１０秒、０．１ミリ秒～１秒、０．１ミリ秒～１００ミリ秒、０．１ミリ秒～１０ミリ秒、又は０．１ミリ秒～１ミリ秒の範囲内であることができる。第１の機械的遅延は、１０ミリ秒～１０分、１０ミリ秒～５分、１０ミリ秒～２分、１０ミリ秒～１分、１０ミリ秒～３０秒、１０ミリ秒～１０秒、１０ミリ秒～１秒、又は１０ミリ秒～１００ミリ秒の範囲内であることができる。第１の機械的遅延は、１秒～１０分、１秒～５分、１秒～２分、１秒～１分、１秒～３０秒、又は１秒～１０秒の範囲内であることができる。
【0025】
第２の機械的遅延は、１２時間未満、６時間未満、３時間未満、１時間未満、３０分未満、１０分未満、５分未満、２分未満、１分未満、３０秒未満、１０秒未満、１秒未満、１０ミリ秒未満、又は０．１ミリ秒未満であることができる。決定された差分に等しい量のリソースを割り当てることは、瞬時に行うことができる。わずかな第２の機械的遅延を有し、又は瞬時に量を割り当てることで、第１の機械的遅延の経過を待つ必要がなくなるので、第１のコンピュータ化リソースリポジトリの現在の量のエラーを修正できる速度の改善が可能になる。
【0026】
第１のコンピュータ化リソースリポジトリの目標状態は、エラーが発生しなかったと仮定した場合にデータモデル及び履歴データに従って想定される第１のコンピュータ化リソースリポジトリの現在の状態に対応することができる。
【0027】
いくつかの任意の実施形態では、方法が、複数のコンピュータ化リソースリポジトリのうちの第２のコンピュータ化リソースリポジトリにおける現在のリソースの量を示すデータを受け取ることと、データモデル、履歴データ及びエラーデータに基づいて、第２のコンピュータ化リソースリポジトリの目標状態を計算することと、第２のコンピュータ化リソースリポジトリ内の現在のリソースの量と、第２のコンピュータ化リソースリポジトリの目標状態におけるリソースの量との差分を決定することと、差分を修正するために、決定された差分に等しい量のリソースを制御用コンピュータ化リソースリポジトリから第２のコンピュータ化リソースリポジトリに又はこの逆に割り当てることと、をさらに含むことができる。このように、１つの制御用コンピュータ化リソースリポジトリを使用して、同じリソース及びデータモデルについて同じ誤った入力データの項目によって影響を受けた複数のコンピュータ化リソースリポジトリにおけるリソースの量を是正することができる。
【0028】
任意に、各データモデル入力は複数の入力プロバイダのうちのある入力プロバイダから受け取ることができ、制御用コンピュータ化リソースリポジトリは複数の制御用コンピュータ化リソースリポジトリのうちの１つであり、各制御用コンピュータ化リソースリポジトリは入力プロバイダに関連することができ、差分を修正するために選択される制御用コンピュータ化リソースリポジトリは、エラーの原因である入力プロバイダに関連することができる。
【0029】
本発明のさらなる態様では、命令を含むメモリと、プロセッサとを含む装置であって、命令が、プロセッサによって実行された時に上記の方法をプロセッサに実行させるように構成された、装置を提供する。本発明のさらなる態様では、コンピュータ可読命令を含むコンピュータプログラムであって、コンピュータ可読命令が、プロセッサによって実行された時に上記の方法をプロセッサに実行させるように構成された、コンピュータプログラムを提供する。
【0030】
以下、添付図面を参照しながら本発明をほんの一例として説明する。
【図面の簡単な説明】
【0031】
【図1】本発明が実装されるリソース割り当てシステム全体のコンポーネント図である。
【図3A】例示的なデータモデル（の少なくとも一部）を示す図である。
【図4】一連のリポジトリのエラー修正のための例示的な「単純な」閉ループ手法を示す図である。
【図5A】本発明の実施形態による、制御用リポジトリを使用して、決定された差分に等しい量のリソースを割り当てることを伴う改善された手法を示す図である。
【図5B】本発明の実施形態による、制御用リポジトリを使用して、決定された差分に等しい量のリソースを割り当てることを伴う改善された手法を示す図である。
【図6】本発明の実施形態による、リソース割り当てシステム内の複数のコンピュータ化リソースリポジトリを制御するコンピュータ実装方法のフローチャートである。
【発明を実施するための形態】
【0032】
図１に、コンピュータ化リソースリポジトリを伴うリソース割り当てのためのシステム１０を示す。システム１０は、リポジトリコントローラ１００、リソースプロバイダ１０２、入力ソース１０４、及び任意のさらなる入力ソース１０６…を含む。リポジトリコントローラ１００、リソースプロバイダ１０２及び（単複の）入力ソース１０４、１０６…の各々はインターネット１０８を介して互いに通信することができ、図１ではそのように示しているが、当業者であれば、リポジトリコントローラ１００、リソースプロバイダ１０２及び（単複の）入力ソース１０４、１０６…の他のネットワーク構成も可能であると認識するであろう。例えば、入力ソース及びリソースプロバイダは、何らかの方法でリポジトリコントローラに接続されている限り、直接的な接続を共有し又はインターネットによって接続される必要はない。リポジトリコントローラ１００は、入力ソース１０４から受け取った入力を本明細書で説明するプロセスに従って処理するように構成される。
【0033】
図２には、プロセッサ２０２、メモリ２０４及び通信インターフェイス２０６を含む、リポジトリコントローラ１００のさらなるコンポーネントを示す。プロセッサ２０２は、メモリ２０４からコンピュータ実行可能コードを取得し、このコンピュータ実行可能コードを実行して本明細書で説明するプロセスを実行するように構成される。また、リソースプロバイダ１０２、入力ソース１０４及び任意のさらなる入力ソース１０６…も、それぞれ図２に示すものと同じ形で同じタイプのコンポーネントを有するように構成することができる。いくつかの実施形態では、リポジトリコントローラ１００、リソースプロバイダ１０２及び（単複の）入力ソース１０４、１０６…のうちのいずれか１つ又は２つ以上を、ディスプレイ、及び／又はプロセッサ２０２へのユーザ入力を受け取るように構成されたユーザ入力装置などの、ユーザインタラクションのためのコンポーネントを有するようにさらに構成することができる。しかしながら、このようなユーザに便利な特徴は、本発明に関連する利点を実現するために決して必須ではないと認識されるであろう。
【0034】
いくつかの実施形態では、リポジトリコントローラ１００が、（ここには図示していない）複数のコンピュータ化リソースリポジトリをメモリ２０４内に記憶する。複数のリポジトリは、ＲＡＭなどのメモリ２０４内の短期タイプのメモリハードウェアに記憶することができる。これに加えて又は代えて、リポジトリは、ハードディスクドライブなどのより大きな容量を有するメモリ２０４内の長期デバイスに記憶することもできる。いくつかの実施形態では、リポジトリ及びそのデータを、インターネット１０８などのネットワークを介してリポジトリコントローラ１００に接続された別のコンピュータ装置のデータベース内などの、リポジトリコントローラ１００の外部に記憶することもできる。いずれの場合にも、リポジトリ及び／又は（各リポジトリに保持されている又は関連するリソースの量などの）リポジトリに関するデータには、リポジトリコントローラ１００が容易かつ迅速にアクセスできることが好ましい。
【0035】
いくつかの実施形態では、リポジトリが物理的にリソースを含むことができる。しかしながら、他の実施形態では、各リポジトリがリソース自体の電子表現を保持する「論理的」ストアとして機能することができ、例えば空のメモリページがリソースであり、１つの空のメモリページが（機能的内容に関して）別のメモリページと異ならない場合、各リポジトリは、この一連の空のページをリソースコントローラ１００のコンピュータハードウェア内に物理的に含むのではなく、この特定のリポジトリに関連する空のメモリページの数の数値表現を単純に含むことができる。本発明は、このように「一様」なリソース、すなわちリソースのいずれか２つの所与の不連続単位が機能的に類似しているリソースに適用された時にとりわけ効果的であることができる。
【0036】
データモデルは、リポジトリコントローラ１００のプロセッサ２０２が容易にアクセスできるメモリ２０４などのハードウェアに記憶される。データモデルは、ＲＯＭ又はＲＡＭに保持することも、或いはソリッドステートドライブ又はハードディスクドライブに保持してそこから読み出すことも、或いはリポジトリコントローラ１００の外部に記憶し、通信インターフェイス２０６を使用してインターネット１０８などのネットワークを介して読み出すこともできる。当業者には、プロセッサ２０２が使用できるようにデータモデルを記憶して読み出す他の技術的手段が明らかであろう。
【0037】
プロセッサ２０２は、インターネット１０８及び通信インターフェイス２０６を介して入力ソース１０４からデータモデル入力を受け取るように構成される。入力ソース１０４は、人間ユーザによって入力ソース１０４に提供されるアクション、コマンド又はその他の入力に応答してこれらの入力を提供することができる。これらの入力は、入力ソース１０４に接続された周辺装置上でユーザがマウスを動かしてクリックし、又はキーストロークを入力することなどの直接的な性質のもの、或いは入力ソース１０４に通信可能に結合された別のコンピュータ装置（図示せず）から受け取ることなどの間接的な性質のものであることができる。これに代えて又は加えて、入力ソースから受け取られる入力は、例えば（入力ソース１０４自体であることもできる）サーバの処理コンポーネントによって計算されたデータなどの、機械生成された入力であることもできる。任意に、さらなる入力をリポジトリコントローラに送信し、及び／又は１又は２以上のさらなる入力ソース１０６…において生成することもできる。本発明の想定される実施形態の多くでは、各入力ソース１０４、１０６…がリポジトリコントローラ１００にユーザ入力及びコマンドを提供し、又は機械生成データの形態で入力を提供するが、任意の入力ソース１０４、１０６…がいずれかのタイプのデータモデル入力をリポジトリコントローラ１００に提供することも、又は複数の異なるタイプの入力の混合を提供することもできると理解されるであろう。
【0038】
入力ソース１０４（及び／又は任意のさらなるソース）からリポジトリコントローラ１００へのデータモデル入力の送信、また実際にリソース割り当てシステム１０のコンポーネント間のいずれかのデータ転送は様々な具体的方法で行うことができ、元来これらの多くは本発明の目的にとって機能的に同等であると理解されるであろう。例えば、データは、転送コンポーネントによる「プッシュ」スタイルの積極的送信ステップを通じて、或いは新たなデータが利用可能であって転送準備ができているかどうかを判定するために転送コンポーネントに繰り返しポーリングすることなどの、受信コンポーネントのプロセッサ上で実行される「プル」スタイルのステップを通じて、インターネット１０８などのネットワークを介して１つの計算コンポーネントから別の計算コンポーネントに転送することができる。当業者には周知のように、ネットワーキングは、いずれかの好適な選択されたアプリケーション層プロトコル、トランスポート層プロトコル、インターネット層プロトコル及びデータリンク層プロトコルの組に従って、ＴＣＰ／ＩＰモデルなどの階層化モデルを使用して実装することができる。
【0039】
以下の図３Ａ～図３Ｃを参照しながらさらに詳細に説明するように、リポジトリコントローラ１００のプロセッサ２０２は、受け取ったデータモデル入力をデータモデルと共に使用して複数のリポジトリの状態更新を計算するように構成される。各後続の処理段階では、プロセッサ２０２が、複数のリポジトリの各リポジトリ内のリソースの「現在の」量（すなわち、データモデルに従って更新される前の現在の状態に関連する量）を計算された更新後の状態の量と比較して、データモデルによって決定された更新を効果的に行うために必要なリソース量の増加又は減少を決定し、従って各リポジトリの状態を入力に従って決定された「次の」又は「更新後の」状態に一致するように変更するよう構成される。後でさらに詳細に説明するように、この各リポジトリのリソース量の増加／減少は、その後に一定量のリソースをリソースプロバイダ１０２から獲得する（又はリソースプロバイダ１０２に放棄する）ことによって達成することができる。
【0040】
リポジトリコントローラ１００は、プロセッサ２０２を使用して、上述したような１つの処理段階から別の処理段階へのリポジトリの状態更新を計算し及び／又は成立させるように構成することができる。いくつかの実施形態では、「処理段階」が、例えば所定の間隔によって均一に分離された時点などの連続時点を意味することができる。このような例では、入力が受け取られたかどうかにかかわらず（例えば）１００分の１秒毎に更新を計算することができる。しかしながら、いくつかの実施形態では、恐らくは入力プロバイダ１０４から次の入力が受け取られるまで更新後のリポジトリ状態を計算する必要がなく、従って計算リソースが無駄にならないであろうという理由で、「処理段階」が、新たなデータモデル入力の到着を参照することによって定められるイベントベースの段階であることもできる。
【0041】
リポジトリコントローラは、コンピュータ化リソースリポジトリの計算された状態更新を計算と同時に又はその直後に成立させる必要は全くない。実際には、現在想定される実施形態の多くでは、リポジトリコントローラ１００が、対象のリポジトリ量を実際に増加又は減少させることなく複数の状態更新を連続して計算することができるが、実質的に低い頻度で状態更新を成立させるように実際にリソースプロバイダ１０２からリソースを獲得すること又はリソースプロバイダ１０２にリソースを放棄することを選択することもできる。換言すれば、リポジトリコントローラ１００は、その制御下にあるリポジトリの複数の更新後の状態をリポジトリ状態に変更を加えることなく計算した後に、必要に応じてリソースプロバイダ１０２に／からリソースを一度に獲得又は放棄することによってリポジトリを「バッチで（ｉｎ ｂａｔｃｈ）」効果的に最新状態にすることができる。このような「バッチ」での獲得又は放棄は、任意の期間にわたってリポジトリコントローラ１００からリソースプロバイダ１０２に送信しなければならない総要求数を減少させることができ、従ってリソース割り当てシステム１０の計算リソース及びネットワークリソースを節約できるという点で有利と考えられる。
【0042】
リポジトリコントローラ１００は、各リポジトリがその状態をデータモデル及び（単複の）入力によって決定された更新後の状態に一致させるために獲得又は放棄しなければならないリソースの量を計算し終えると、１又は複数のリポジトリに一定量のリソースを追加する（又はリポジトリから削除する）ためにリソースプロバイダ１０２に電子要求の形態でデータを送信する。上述したように、この要求の送信と実際のリポジトリのリソース量の変化との間には機械的遅延が存在することがある。いくつかの実施形態では、リソースプロバイダ１０２が、要求の受信後しばらくしてから、又は少なくともリポジトリコントローラ１００による要求の提出後しばらくしてからリソースの電子的な獲得又は放棄を成立させることによって遅延の原因になることがある。
【0043】
リポジトリコントローラ１００は、以前に受け取った過去のデータモデル入力の記録をデータベースなどの好適なデータ構造でメモリ２０４内に記憶することができる。これに加えて又は代えて、データモデルの過去の入力を表す記録データをリポジトリコントローラ１００に通信可能に結合された別のコンピュータシステムに記憶し、又は複数のこのようなシステムに分散させ、リポジトリコントローラ１００を、必要時にこの別のコンピュータシステムに問い合わせてデータを要求することによってこのデータを「オンザフライ」で獲得するように構成することもできる。このデータは、その後にバッチでリポジトリコントローラ１００に転送することができる。いくつかの実施形態では、入力プロバイダ１０４及び／又はリソースプロバイダ１０２の一方又は両方が、過去のデータモデル入力記録を記憶する「他の」コンピュータシステムとして機能することができる。
【0044】
リポジトリコントローラは、入力プロバイダ１０４及び任意にさらなる入力プロバイダ１０６…から過去の入力のエラーを示すエラーデータを受け取るようにも構成される。エラーデータのさらなる詳細については図３Ｃで後述する。
【0045】
次に、図３Ａ～３Ｃに、例示的なデータモデル３００又は少なくともその一部を示す。データモデル３００は、連続処理段階において受け取られた入力３５２、３５４、３５６の様々な組み合わせに基づいて考えられる複数のリポジトリ状態３１０～３４６のための更新ルール３５０を含む。図示の（限定を意図するものではない）図３Ａの例には１２個の更新ルール３５０を示しており、これらは３つの可能な入力３５２、３５４、３５６に応答した連続段階における１３個の状態３１０～３４６間の遷移を一意的に定める。しかしながら、当業者であれば、実際にはリポジトリの状態空間はこれよりもはるかに多くの状態を含むことができ（実際には無限であることができ）、可能なデータモデル入力の空間はこれよりもはるかに大きなものであることができ（無限であることができ）、実際のデータモデルは図３Ａに示すよりも多くの更新ルールを定めることができる（無限に多くのこのようなルールを定めることができる）と認識するであろう。可能な入力の空間が大きく、データモデル入力の正確な反復が決して又は非常にまれにしか発生しない事例では、例えば図３Ａに示す例示的なデータモデル３００には、最初の処理段階ｔn及び後続の処理段階ｔn+1の両方において同じ入力ａ、ｂ及びｃ（３５２、３５４、３５６）のための更新ルール３５０を示しているが、実際には段階ｔn+1において以前には見られなかった何らかの新たな入力ａ’、ｂ’又はｃ’（図示せず）が受け取られる場合もある。
【0046】
データモデル３００は、入力の到着に応答してリポジトリを１つの特定の状態から次の状態にどのように「進める」べきであるかを指定する。一般に、データモデル３００の更新ルール３５０は、「現在の」状態と入力又は入力の集合｛ｉ1，ｉ2…ｉn｝とを取り込んでリポジトリの「次の」又は「更新後の」状態ｓ∈Ｓを出力する、状態空間Ｓ及び入力空間Ｉの部分関数又は全域関数ｆ：Ｓ×Ｉ→Ｓとして定められる。多くの例では、データモデル３００が、複数のリポジトリにわたって適用すべき単一の共通の更新ルールセットを定めることができる。すなわち、所与の複数のリポジトリＲに属する２つのリポジトリｒ1及びｒ2の現在の状態が同一である場合、データモデル３００は、ｒ1及びｒ2の両方に同じ入力が適用されるとｒ1、ｒ2の両方が同じ同一の後続の状態に更新されるという特性を有することができ、すなわち明確に定められる。
【0047】
図３Ａを参照すると、更新ルール３５０は、リポジトリコントローラ１００がいずれかの入力３５２、３５４、３５６を受け取る前の時点ｔnにおける何らかの具体的にマークされた「現在」又は「初期」の瞬間に状態３１０を有するリポジトリに対する効果を参照することによって理解することができる。初期段階ｔnでは、入力プロバイダ１０４からリポジトリコントローラ１００に入力が送信されておらず、リポジトリは１００単位のリソース（又は少なくともその論理表現）を保持している。データモデル３００は、（図３Ａ～図３Ｃでは「ａ」と表記する）第１の入力３５２、（「ｂ」と表記する）第２の入力３５４又は（「ｃ」と表記する）第３の入力３５６であることができる入力をリポジトリコントローラ１００が受け取った後の後続の段階ｔn+1において、受け取った入力がそれぞれ第１の入力３５２、第２の入力３５４又は第３の入力３５６のいずれであったかに応じて状態３２０、３２２又は３２４のうちのいずれか１つになる新たな状態にリポジトリを更新すべきであると決定する。第１の入力３５２の到着によって初期状態３１０から到達する状態３２０は、１０５単位のリソースを保持する。第２の入力３５４の到着によって初期状態３１０から到達する状態３２２は、１１０単位のリソースを保持する。第３の入力３５６の到着によって初期状態３１０から到達する状態３２４は、８５単位のリソースを保持する。
【0048】
リポジトリコントローラ１００は、この後続の処理段階ｔn+1において、別の入力３５２、３５４、３５６を受け取った時のさらなる更新後の状態を計算することができる。例えば、リポジトリが状態３２０にあって第１の入力３５２が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３３０であると決定する。リポジトリが状態３２０にあって第２の入力３５４が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３３２であると決定する。リポジトリが状態３２０にあって第３の入力３５６が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３３４であると決定する。
【0049】
同様に、リポジトリが状態３２２にあって第１の入力３５２が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３３６であると決定する。リポジトリが状態３２２にあって第２の入力３５４が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３３８であると決定する。リポジトリが状態３２２にあって第３の入力３５６が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３４０であると決定する。
【0050】
最後に、リポジトリが状態３２４にあって第１の入力３５２が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３４２であると決定する。リポジトリが状態３２４にあって第２の入力３５４が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３４４であると決定する。リポジトリが状態３２４にあって第３の入力３５６が受け取られた場合、データモデル３００の更新ルールは、リポジトリの次の状態が状態３４６であると決定する。
【0051】
その後、データモデル３００は、この次の入力がリポジトリコントローラ１００によって受け取られた後に（すなわち、処理段階ｔn+2において）リポジトリの新たな状態をもたらし、この状態は、受け取られた入力の組み合わせに応じて状態３３０、３３２、３３４、３３６、３３８、３４０、３４２、３４４又は３４６のうちの１つになる。２つの連続する第１の入力３５２のインスタンスの到着によって初期状態３１０から到達する状態３３０は、９５単位のリソースを保持する。第１の入力３５２のインスタンスの後に第２の入力３５４のインスタンスが到着することによって初期状態３１０から到達する状態３３２は、１２０単位のリソースを保持する。第１の入力３５２のインスタンスの後に第３の入力３５６のインスタンスが到着することによって初期状態３１０から到達する状態３３４は、１１５単位のリソースを保持する。第２の入力３５４のインスタンスの後に第１の入力３５２のインスタンスが到着することによって初期状態３１０から到達する状態３３６は、１００単位のリソースを保持する。２つの連続する第２の入力３５４のインスタンスの到着によって初期状態３１０から到達する状態３３８は、７０単位のリソースを保持する。第２の入力３５４のインスタンスの後に第３の入力３５６のインスタンスが到着することによって初期状態３１０から到達する状態３４０は、６０単位のリソースを保持する。第３の入力３５６のインスタンスの後に第１の入力３５２のインスタンスが到着することによって初期状態３１０から到達する状態３４２は、８５単位のリソースを保持する。第３の入力３５６のインスタンスの後に第２の入力３５４のインスタンスが到着することによって初期状態３１０から到達する状態３４４は、１０５単位のリソースを保持する。２つの連続する第３の入力３５６のインスタンスの到着によって初期状態３１０から到達する状態３４６は、６５単位のリソースを保持する。
【0052】
図３Ｂには、所与のコンピュータ化リソースリポジトリについてリポジトリコントローラ１００が実際に取ることができる、データモデル３００の更新ルール３５０に従って状態を経由する１つの可能な「経路」の例を示す。図示の例では、リポジトリコントローラ１００が、入力プロバイダ１０４から２つの連続する入力を受け取ったことに応答して（最初は処理段階ｔnにおいて状態３１０にある）リポジトリの２つの状態更新を計算する。最初に、リポジトリコントローラ１００は、入力プロバイダ１０４から第２の入力３５４を受け取り、データモデル３００を使用して、初期状態３１０よりも１０個多い１１０個のリソースを保持する状態３２２にリポジトリを更新すべきであると決定する。その後に、リポジトリコントローラ１００は、段階ｔn+1において入力プロバイダ１０４から第３の入力３５６を受け取り、データモデル３００を使用して、初期状態３１０よりも４０個少ない（中間状態３２２よりも５０個少ない）６０個のリソースを保持する状態３４０にリポジトリを更新すべきであると決定する。
【0053】
この例では、リポジトリコントローラ１００が、各入力が受け取られて更新後の状態が計算された時に、リソースプロバイダ１０２からの又はリソースプロバイダ１０２へのリソースの獲得又は放棄を要求することができる。すなわち、リポジトリコントローラ１００は、第２の入力３５４に応答して状態３１０から状態３２２への更新を計算した後に、例えばリソースプロバイダ１０２から１０単位のリソースを獲得するように要求することによってリポジトリ内のリソースの量を１１０単位に増加させようと試みることができる。次に、リポジトリコントローラ１００は、第３の入力３５６に応答して状態３２２から状態３４０への更新を計算した後に、例えばリソースプロバイダ１０２に適切な数のリソースを放棄するように要求することによってリポジトリ内のリソースの量を６０単位に減少させようと試みることができる。他の例では、リポジトリコントローラ１００が、データモデル３００及び第２の入力３５４に基づいて状態３２２を計算する際にリソースの割り当てに関して何もアクションを行わず、後でコンピュータ化リソースリポジトリの状態更新を成立させることのみを選択することができる。いずれにせよ、上述したように、リソースの獲得／放棄要求が機械的遅延の経過後にしかリソースプロバイダによって満たされず、また実際に獲得又は放棄されたリソースの量がリポジトリコントローラ１００の要求した量と異なる場合がある。
【0054】
次に、エラーデータ３６０に応答する再生イベントを示す図３Ｃを参照する。本発明の実施形態では、入力プロバイダ１０４（及び任意のさらなる入力プロバイダ１０６…、以下この言及については簡潔さのみを目的として省略する）が、リポジトリコントローラ１００に著しく大量の入力データが送信される原因であることがあり、大幅に長い期間にわたってこれを行い続けることがある。このような規模及び時間枠では、この入力データ間にエラーが見られることはほぼ避けられず、従ってリポジトリコントローラ１００は、複数のコンピュータ化リソースリポジトリ内の各リポジトリの状態及び内容に対するこのようなエラーの影響を緩和又は排除できることが望ましい。理想的には、リポジトリコントローラ１００は、以前の入力において発生したエラーの（誤った入力の「真の」又は「修正された」値を含む）詳細を所与として、エラーの影響を受けた１又は２以上のリポジトリに対して補償的状態更新を実行し、最終的に全てのリポジトリをエラーが発生しなかった場合の状態にできるべきである。このように、リポジトリコントローラ１００は、データモデル３００のために受け取られた過去の入力を所与として、入力エラーの存在によってデータモデルから逸脱又は乖離してしまったリポジトリをあるべき状態に戻すために、これらのリポジトリに状態更新を適用することができる。
【0055】
リポジトリコントローラ１００は、ＸＭＬ、ＪａｖａＳｃｒｉｐｔオブジェクトノーテーション（ＪＳＯＮ）、或いは当業者が認識するような他のいずれかの適切なデータ構造又はフォーマットなどの何らかの好適な形態で入力プロバイダ１０４からエラーデータ３６０を受け取るように構成される。図３Ｃに示す例では、エラーデータ３６０が、過去の処理段階ｔnにおいてリポジトリコントローラ１００が入力プロバイダ１０４から受け取った入力３６２が誤って送信されたものである旨の指示を含む。この例では、エラーデータ３６０が、過去の処理段階ｔnにおいて入力プロバイダがリポジトリコントローラ１００に送信すべきであった「修正済みの」、「目標である」又は「真の」値の指示も含む。当然ながら、当業者であれば、エラーデータ３６０はこのような特定の値の組み合わせを含み又はこのような値の組み合わせから成る必要はなく、後述するような目標リポジトリ状態の計算を可能にするにはｔnにおける「修正済みの」値を示す指示３６４で十分であるため、例えばエラーデータ３６０はこのような指示３６４のみを含んでいればよいと認識するであろう（とは言うものの、指示３６２は検証又は簿記の目的で何らかの利益をもたらすことができる）。これに加えて又は代えて、エラーデータは、誤ったデータが受け取られた処理段階ｔnを特定する必要はなく、他のいずれかの好適な一意の識別子の参照を通じて誤った入力（及びその修正）を特定することもできる。
【0056】
リポジトリコントローラ１００は、エラーデータ３６０を受け取った後に、エラーの影響を受けた１又は複数のリポジトリの目標状態を計算するために、エラーデータ３６０をデータモデル３００及び既知の以前の入力と組み合わせて使用する。目標状態は、エラーが発生しなかったと仮定した場合にデータモデル及び以前の入力データに従って１つの／複数のリポジトリが到達すると想定される現在の状態に対応することができる。
【0057】
例えば、図３Ｂ及び図３Ｃにわたって示す例では、関連する過去の入力の組が、段階ｔnにおける第２の入力３５４の発生及び段階ｔn+1における第３の入力３５６の発生を含み、これらの組み合わせがリポジトリを初期状態３１０から６０単位のリソースを有する現在の状態３４０に導いている。その後、リポジトリコントローラ１００は、段階ｔnにおける第２の入力３５４の発生が実際にはエラーであり、代わりにこの処理段階の意図される「正しい」入力は第１の入力３５２のインスタンスであったことを示すエラーデータ３６０を受け取る。これとは逆にエラーデータが存在しない場合、リポジトリコントローラ１００は、残っている以前の入力（この事例では、段階ｔn+1において受け取られた第２の入力３５４のインスタンス）が正しいと仮定することができる。
【0058】
リポジトリコントローラのプロセッサ２００は、エラーがない場合の「意図される」状態を決定するために、任意のリポジトリの現在の状態を誤った入力の直前の時点に「ロールバック」することによって到達状態を計算し、この事例ではプロセッサ２００がｔnにロールバックすることによって初期状態３１０に到達する。次に、プロセッサ２００は、修正された入力値３６４をデータモデル３００と組み合わせて使用し、エラーがなければｔn+1段階においてリポジトリが進むはずであった中間状態３２０を計算する。最後に、プロセッサ２００は、残りの過去の入力データ及びデータモデル３００を使用して、状態３２０から状態３３４へのリポジトリの最終的な状態更新、すなわちエラーが発生しなければ処理ｔn+2においてリポジトリが落ち着くはずであった意図される「最終」状態を計算し、この目標状態３３４では、リポジトリが物理的又は論理的に１１５単位のリソースを保持していたと思われる。
【0059】
方法のこの時点で、リポジトリコントローラ１００は、コンピュータ化リソースリポジトリ内の現在のリソースの量（リポジトリは状態３４０にあるので６０単位のリソース）と、コンピュータ化リソースリポジトリの目標状態におけるリソースの量（１１５単位）との間の差分を（プロセッサ２００を使用して）決定する。図３Ｂ及び図３Ｃに示す例では、リポジトリコントローラ１００が、プロセッサ２００を使用して１１５から６０を減算することによって５５単位という差分を決定する。この差分は「不一致」又は「誤差項」と呼ぶことができ、エラーの影響を打ち消してデータモデル３００に従って目標状態に収束するために、影響を受けたリポジトリが獲得しなければならない（又は影響を受けたリポジトリから放棄されなければならない）リソースの量を表すという点でリポジトリコントローラにとって有用である。
【0060】
上記の説明例では、データモデル３００の最初の処理段階における１つの入力エラーが、意図されるリソースの量とリポジトリ内の実際のリソースの量との間の実質的な不一致を最終的に招いたことが観察される。この段階ｔn+1におけるエラーのリソース量に対する影響は比較的小さなものであったが、リポジトリコントローラ１００が入力プロバイダ１０４からさらなる入力を受け取って処理するにつれ、その影響はさらに悪化している。換言すれば、データモデルは、リポジトリに影響を及ぼす入力の１つの潜在的に小さな過去のエラーが長期的にはリポジトリの状態に著しく大きな影響を及ぼす恐れがあり、エラーを修正することによってエラーの発生時点から入力を再生した後に各処理段階を理論的に再計算し、最終的にはリポジトリの状態の変化を決定することが必要になるという意味で高度に経路依存的である。本発明は、このような経路依存データモデルとの関連で適用した場合にとりわけ効果的であることができる。
【0061】
次に、複数のコンピュータ化リソースリポジトリ４００のための上述したような単純なエラー補償方法を示す図４を参照する。単純化の目的で、また入力エラーの影響を受けたリポジトリを「目標状態」に向けて誘導するプロセスをより良く説明するために、共通の「正しい」状態Ｓ1にある複数のリポジトリ４０２と「誤った」状態Ｓ’1にあるリポジトリ４０４とを含む複数のリポジトリ４００を示しており、リポジトリコントローラ１００は、リポジトリ４０２及びリポジトリ４０４の全てに同一の影響を及ぼすデータモデル入力（図示せず）に応答してこれらの全てのリポジトリを管理する。しかしながら、当業者であれば理解するように、実際の複数のコンピュータ化リソースリポジトリ４００は複数の異なる個別の状態にあるリポジトリを含むことができ、従ってデータモデル入力は、これらのリポジトリの多くの計算された状態に異なる形で影響を与えることができる。いくつかの実施形態では、複数のリポジトリ４００のうちの１つのリポジトリのみの状態に影響を与えて他のリポジトリの状態を変化させないデータモデル入力を提供することができる。
【0062】
図４に示す例では、最初の処理段階ｔmにおいてリポジトリ４０２がそれぞれ状態Ｓ1にあり、従ってそれぞれ１１５単位のリソースを含む（又はこのようなリソースに別様に関連する）。この同じ処理段階において、影響を受けたリポジトリ４０４は「誤った」状態Ｓ’1にあり、従って６０単位のリソースしか含んでいない（又はこのようなリソースにしか関連しない）。従って、この処理段階では、リポジトリ４０４の状態と（ここでは説明目的で事前エラーがない場合のリポジトリ４０４の目標状態を表す）状態Ｓ1との間に５５単位の差分が存在し、リポジトリコントローラは上述したような再生イベントを介してこの差分を決定している。複数のリポジトリ４００では、データモデル入力の受信及びその後の必要な状態更新の頻度が高く、またリポジトリコントローラ１００が（この場合は）５５個の不足しているリソース単位を獲得しようと試みているウィンドウ中に新たな入力及び更新の受信及び生成が行われることもあり、すなわちリソースが獲得されるまでに「正しい」状態が異なってしまい、新たな状態が直ぐに古くなるため、リポジトリコントローラ１００がこの不一致を直ちに修正することは困難であり、非現実的であり、又は不可能な場合もある。
【0063】
この問題を防ぐために、リポジトリコントローラは、影響を受けたリポジトリ４０４の代わりに、リソースプロバイダ１０２に行われる要求を状態間の不一致を補う形で修正しようと試みることができる。図４の例では、リポジトリコントローラ１００が、受け取った入力（図示せず）に従って、データモデル３００を使用して、コンピュータ化リソースリポジトリ４０２内のリソースの量を１０単位だけ増加させるべきであるとの決定を行い、これに応じてリソースプロバイダ１０２に要求を送信する。同時に（又はほぼ同時に）、リポジトリコントローラ１００は、影響を受けたリポジトリ４０４のために６５単位のリソースを獲得しようと（従って、目標状態及びデータモデル３００に従ってリポジトリの状態を進めながら不一致を補償しようと）試みる要求をリソースプロバイダ１０２に送信する。
【0064】
リソースプロバイダ１０２側の信頼度が予測できないため、各リポジトリは、リポジトリコントローラ１００が要求した量よりもわずかに多い量のリソースを獲得する。状態Ｓ1から開始した各リポジトリ４０２は、実際には１０単位ではなく１２単位のリソースを獲得し、従ってその後の処理段階ｔm+1では１２７単位のリソースを有する新たな状態Ｓ2にある。一方で、影響を受けたリポジトリ４０４は、実際には６５単位ではなく７８単位のリソースを獲得し、従って状態Ｓ’1からその後の処理段階ｔm+1では１３８単位のリソースを有する新たな状態Ｓ’2に進み、すなわちエラーは修正されていない。
【0065】
リポジトリコントローラ１００は再び入力（図示せず）を受け取り、従ってデータモデル３００を使用して、コンピュータ化リソースリポジトリ４０２内のリソースの量を５単位だけ減少させるべきであるとの決定を行い、関連する要求（又は一連の要求）をリソースプロバイダ１０２に送信する。同時に（又はほぼ同時に）、リポジトリコントローラ１００は、影響を受けたリポジトリ４０４の１６単位のリソースを放棄して不一致を修正しようと試みる要求をリソースプロバイダ１０２に送信する。
【0066】
リソースプロバイダ１０２側の信頼度が予測できないため、各リポジトリは、リポジトリコントローラ１００が要求した量よりもわずかに少ない量のリソースを放棄する。これまで状態Ｓ2にあった各リポジトリ４０２は、実際には５単位ではなく４単位のリソースを放棄し、従ってその後の処理段階ｔm+2では１２３単位のリソースを有する新たな状態Ｓ3にある。一方で、影響を受けたリポジトリ４０４は、実際には１６単位ではなく１２単位のリソースを放棄し、従って状態Ｓ’2からその後の処理段階ｔm+2では１２６単位のリソースを有する新たな状態Ｓ’3に進み、すなわち依然としてエラーは修正されていない。
【0067】
従って、このように再生イベントを介して状態の不一致が決定された後にその不一致を修正するこのような手法は最適とは言えず、この例のように不一致の大きさを小さくすることはできるが、複数のさらなる処理段階にわたって不一致が存続し続ける可能性があることが分かる。実際には、リポジトリコントローラ１００及びその複数のリポジトリ４００との間で外部的にリソースを獲得及び／又は放棄するリソースプロバイダの特性が信頼できないため、（少なくとも原理上は）不一致が無制限に存続し、決して解決されない可能性がある。この問題をどのように合理的に解決できるかは（本開示の恩恵がなければ）すぐには分からない。
【0068】
図５Ａ及び図５Ｂに、本発明の実施形態による上記問題の解決策を示す。図５Ａには、状態Ｓ1にある複数のリポジトリ５０２と、以前の誤った入力によって処理段階ｔmにおいて目標状態Ｓ1ではなく状態Ｓ’1になったリポジトリ５０４とを含む複数のコンピュータ化リソースリポジトリ５００を示す。リポジトリ５０２はリポジトリ４０２と同様のものであることができ、影響を受けたリポジトリ５０４は影響を受けたリポジトリ４０４と同様のものであるという意味で、複数のリポジトリ５００は上述した複数のリポジトリ４００と同様のものであることができる。しかしながら、図５Ａ及び図５Ｂに示す実施形態では、図４の例とは異なり、リポジトリコントローラ１００が、以下でさらに詳細に説明するようなエラー修正プロセスの一部として、（図５Ａ及び図５Ｂでは、右下隅に「Ｃ」の記号を示す）（少なくとも１つの）特別な「制御用」コンピュータ化リソースリポジトリ５０６を利用する。
【0069】
図５Ａには、リポジトリコントローラ１００がエラーデータ３６０を受け取り、これをデータモデル３００及び以前のデータモデル入力を含む履歴データと組み合わせて使用して本明細書で上述したように影響を受けたリポジトリ５０４の目標状態を計算した後の処理段階ｔmにおける複数のリポジトリ５００及び制御用リポジトリ５０６を示す。リポジトリコントローラ１００は、影響を受けたリポジトリ５０４内のリソースの量と、計算された目標状態におけるリソースの量との間の、この事例では５５単位のリソースである差分５０８を決定する。
【0070】
リポジトリコントローラ１００は、例えばリソースプロバイダ１０２との間で「外部的に」リソースの量を獲得又は放棄することによって差分５０８を修正しようと試みるのではなく、代わりに制御用リポジトリ５０６から影響を受けたリポジトリ５０４に又はこの逆に、決定された差分５０８に等しい量のリソースを直接割り当てることにより、影響を受けたリポジトリ５０４を補償して差分を修正する。すなわち、決定された差分が、影響を受けたリポジトリ５０４におけるリソースがその目標状態と比べて過剰であることを示す場合には、影響を受けたリポジトリ５０４から制御用リポジトリ５０６に適切な量のリソースを転送することによって差分を修正し、決定された差分が、影響を受けたリポジトリ５０４におけるリソースがその目標状態と比べて不足していることを示す場合には、制御用リポジトリ５０６から影響を受けたリポジトリ５０４に適切な量のリソースを転送することによって差分を修正する。例えば、図５Ａの実施形態では、リポジトリコントローラ１００が、決定された差分５０８を修正するために、制御用リポジトリ５０６から影響を受けたリポジトリ５０４に５５単位のリソースを割り当てるべきであると決定する。
【0071】
図５Ｂには、制御用リポジトリ５０６から影響を受けたリポジトリ５０４への直接的な割り当ての直後の複数のリポジトリ５００及び制御用リポジトリ５０６を示す。この図で分かるように、リポジトリ５０４は、リポジトリコントローラ１００がリソースプロバイダ１０２と相互作用する必要なく目標状態Ｓ1に戻り、データモデル３００に従って「正しい」リソース量、すなわち１１５単位を保持している（又は別様にこのようなリソース量に関連する）。図示の実施形態では、この量の転送後に制御用リポジトリ５０６に９４５単位のリソースが残っている。図示の実施形態では、この処理が、時間の経過及び／又は（リポジトリコントローラ１００が１又は２以上のデータモデル入力を受け取ることなどの）イベントの発生によって後続の処理段階ｔm+1が生じる前に全て処理段階ｔm「内」で発生している。
【0072】
いくつかの実施形態では、リポジトリ５０４から制御用リポジトリ５０６への又はこの逆への直接的な割り当てが瞬時に行われる。いくつかの実施形態では、この直接的な割り当てが実質的に瞬時に行われる。いくつかの実施形態では、リポジトリコントローラ１００からリソースプロバイダ１０２への要求の送信とその後の所与のリポジトリへの状態更新との間に機械的遅延が存在する場合、直接的な割り当てがこの機械的遅延よりも短い時間ウィンドウ内に行われる。
【0073】
本発明の好ましい実施形態では、制御用リポジトリ５０６が複数のリポジトリ５００のメンバーではない。すなわち、制御用リポジトリ５０６の状態更新は、リポジトリ５０２及び影響を受けたリポジトリ５０４などの「通常の」コンピュータ化リソースリポジトリの状態更新を計算するために使用される同じ更新ルールに基づいて計算されない。いくつかの実施形態では、リポジトリコントローラ１００が、所与のインスタンスにおける制御用リポジトリ５０６内のリソースの量が閾値範囲外にあるかどうかを判定し、そうである場合にはその状態を更新してこの量を閾値範囲内に収めるように構成される。例えば、制御用リポジトリ５０６は、所定の「下限」又は所定の「上限」、或いは好ましくは所定の下限及び所定の上限の両方を伴うことができる。
【0074】
制御用リポジトリ５０６の状態を更新してその量を閾値範囲内に収めることは、リソースプロバイダ１０２などの外部ソースを使用して適切な量のリソースを獲得又は放棄することを含むことが好ましい。量を閾値範囲内に収めることは、この量を閾値範囲の中間点などの閾値範囲内の特定の所定値に至らせるように一定量のリソースを獲得／放棄することを含むことができる。非限定的な例として、図５Ｂを参照すると、制御用リポジトリ５０６は、５００単位のリソースという下限、及び１，５００単位のリソースという上限を有し、リポジトリコントローラ１００は、これらの限界のいずれかを超えたと判定すると、制御用リポジトリ５０６内のリソースの量を１，０００単位に戻すのに十分な量のリソースをリソースプロバイダ１０２との間で獲得又は放棄する（又は獲得／放棄しようと試みる）ように構成することができる。いくつかの実施形態では、制御用リポジトリ５０６の量が閾値範囲外にあるとの判定のみに従って制御用リポジトリ５０６の状態が更新される。
【0075】
当業者であれば、このような閾値範囲の使用は本発明の本質的特徴ではなく、誤った以前の入力データによって生じた不一致を修正するために（リポジトリ５０４などの）複数のリポジトリ５００のメンバーに及び／又はメンバーからリソースを割り当てることが制御用リポジトリ５０６の唯一の状態変化である実施形態が存在することもできると認識するであろう。
【0076】
本発明の好ましい実施形態では、制御用リポジトリ５０６の状態が、負の、すなわちゼロ未満の量のリソースを含み、又はこのような量のリソースに別様に関連することができる。例えば、リソースが非物理的なものである場合、及び／又はリソースが論理表現として保存されている場合、制御用リポジトリ５０６は、リソースプロバイダ１０２を使用して後で充填できるリソースの不足分を含み又は表すことができる仮想リポジトリとして存在することができる。
【0077】
１又は２以上の制御用リポジトリ５０６は、リポジトリコントローラ１００の、例えば上述したようなメモリ２０４に物理的に、論理的に及び／又は仮想的に記憶することができる。これに加えて及び／又は代えて、１又は２以上の制御用リポジトリ５０６は、リポジトリコントローラ１００に通信可能に結合されてリポジトリコントローラ１００がアクセスできる別のシステムに記憶することもできる。１又は２以上の制御用リポジトリ５０６は、複数のリポジトリ５００との間のリソースの量の高速転送を容易にするように、リポジトリコントローラ１００が素早くアクセスできるような構成で記憶されることが好ましい。複数の制御用リポジトリ５０６を使用する実施形態では、制御用リポジトリ５０６の一部をリポジトリコントローラ１００に記憶し、他の制御用リポジトリ５０６を、リポジトリコントローラ１００に通信可能に結合されてリポジトリコントローラ１００がアクセスできる別のシステムに記憶することもできる。
【0078】
いくつかの実施形態では、リポジトリコントローラが、複数の入力プロバイダからの異なる入力プロバイダによってそれぞれが提供されるデータモデル入力を複数の入力プロバイダ１０４、１０６、…から受け取る。例示的かつ非限定的な例として、図３Ａ～図３Ｃの例の処理段階ｔnにおける（元々は第２の入力３５４又は「ｂ」のインスタンスであり、第１の入力３５２又は「ａ」のインスタンスに修正された）入力は入力プロバイダ１０４から受け取られたものであることができ、後続の処理段階ｔn+1における入力（第３の入力３５６又は「ｃ」のインスタンス）はさらなる入力ソース１０６から受け取られたものであることができる。
【0079】
さらに、リポジトリコントローラ１００によって使用される各制御リソースリポジトリは異なる入力プロバイダに関連することができ、リポジトリコントローラ１００は、どの入力プロバイダが誤った入力を供給したかに基づいて、不一致を修正するためにどの制御用リポジトリを使用してリソースの量を割り当てるべきであるかを選択するように構成することができる。図を参照しながら上記の例を続けると、リポジトリコントローラ１００は、リポジトリ５０６が（ｔnにおいて誤った入力を提供した）入力プロバイダ１０４に関連しているとの判定に基づいて、エラーの原因ではなかった入力プロバイダ１０６の制御用リポジトリ（図示せず）を使用するのではなく制御用リポジトリ５０６を選択して５５単位のリソースを割り当てることができる。この意味で、誤った入力によって生じた不一致はこの誤った入力のプロバイダによって「所有」される。
【0080】
次に、図６に、本発明の実施形態による、リソース割り当てシステム１０内の複数のコンピュータ化リソースリポジトリを制御するためのコンピュータ実装方法を示す。
【0081】
ステップ６０４において、データモデル、履歴データ、現在の量データ及びエラーデータを受け取る。データモデルは、１又は２以上の入力に基づいて複数のリソースリポジトリの各コンピュータ化リソースリポジトリの状態を更新するためのルールを含む。各コンピュータ化リソースリポジトリの状態は、これらの各コンピュータ化リソースリポジトリ内のリソースの量を含む。履歴データは、データモデルへの複数の過去の入力を含む。現在の量データは、複数のコンピュータ化リソースリポジトリのうちの第１のコンピュータ化リソースリポジトリにおける現在のリソースの量を示すデータを含む。エラーデータは、履歴データの以前の入力のうちの１つにおけるエラーを示す。
【0082】
任意に、履歴データはさらなる履歴データを含むこともできる。例えば、履歴データは、第１のコンピュータ化リソースリポジトリのかつての状態を示すデータを含むことができる。これに加えて又は代えて、履歴データは、これらのかつての状態の各々に関連するリソースの量を示すデータを含むこともできる。かつての状態は、第１のコンピュータ化リソースリポジトリが経験した、エラーが発生した処理段階から「現在の」状態（すなわち、コンピュータ装置上で方法が実行されるようになった時点での状態）に至るまでの一連の状態のうちの一部又は全部を含むことができる。いくつかの実施形態では、履歴データが、誤った入力の直前の第１のコンピュータ化リソースリポジトリの状態を含む。
【0083】
ステップ６０６において、データモデル、履歴データ及びエラーデータに基づいて第１のコンピュータ化リソースリポジトリの目標状態を計算する。目標状態は、エラーが発生しなかったと仮定した場合にデータモデル及び履歴データに従って想定される第１のコンピュータ化リソースリポジトリの現在の状態に対応することができる。
【0084】
ステップ６０８において、第１のコンピュータ化リソースリポジトリにおける現在のリソースの量と、第１のコンピュータ化リソースリポジトリの目標状態におけるリソースの量との間の差分を決定する。
【0085】
ステップ６１０において、差分を修正するために、制御用コンピュータ化リソースリポジトリから第１のコンピュータ化リソースリポジトリに又はその逆に、決定された差分に等しい量のリソースを割り当てる。
【0086】
「～を含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、「～を含む（ｉｎｃｌｕｄｉｎｇ）」だけでなく「～からなる（ｃｏｎｓｉｓｔｉｎｇ）」も網羅する。Ｘは、Ｘのみから成ることも、又はＸ＋Ｙなどのさらなる何かを含むこともできる。
【0087】
別途指示していない限り、本明細書で説明した各実施形態は、本明細書で説明した別の実施形態と組み合わせることができる。
【0088】
本明細書で説明した方法は、例えばコンピュータ上で実行された時に本明細書で説明したいずれかの方法の全てのステップを実行するように適合されたコンピュータプログラムコード手段を含むコンピュータプログラムなどの形態の、有形の記憶媒体上の機械可読形態のソフトウェアによって実行することができ、コンピュータプログラムはコンピュータ可読媒体上に具現化することができる。有形の（又は非一時的）記憶媒体の例としては、ディスク、ハードドライブ、サムドライブ、メモリカードなどが挙げられ、伝搬信号は含まれない。ソフトウェアは、方法ステップをいずれかの好適な順序で又は同時に実行できるように、パラレルプロセッサ又はシリアルプロセッサ上での実行に適する。このことは、ファームウェア及びソフトウェアが価値ある個別に取引可能な製品であり得ることを認めるものである。ソフトウェアは、所望の機能を実行するために「ダム（ｄｕｍｂ）」ハードウェア又は標準的ハードウェア上で動作する又はこれらのハードウェアを制御するソフトウェアを含むように意図される。ソフトウェアは、所望の機能を実行するために、シリコンチップの設計又は汎用プログラマブルチップの構成に使用されるような、ハードウェアの構成を「記述」する又は定めるＨＤＬ（ハードウェア記述言語）ソフトウェアなどのソフトウェアを含むようにも意図される。
【0089】
当業者であれば、プログラム命令を記憶するために利用される記憶装置はネットワークを介して分散させることができると理解するであろう。例えば、リモートコンピュータは、ソフトウェアとして記述されるプロセスの例を記憶することができる。ローカルコンピュータ又はターミナルコンピュータは、プログラムを実行するためにリモートコンピュータにアクセスしてソフトウェアの一部又は全部をダウンロードすることができる。或いは、ローカルコンピュータは、必要に応じてソフトウェアをダウンロードし、或いは一部のソフトウェア命令をローカル端末において実行して一部のソフトウェア命令をリモートコンピュータ（又はコンピュータネットワーク）において実行することもできる。当業者であれば、当業者に周知の従来技術を利用することにより、ソフトウェア命令の全部又は一部をＤＳＰ（デジタルシグナルプロセッサ）又はプログラマブルロジックアレイなどの専用回路によって実行することもできると理解するであろう。
【0090】
上述した恩恵及び利点は、１つの実施形態に関連することも、或いは複数の実施形態に関連することもできると理解されるであろう。実施形態は、記載した問題点の一部又は全部を解決するもの、又は記載した恩恵及び利点の一部又は全部を有するものに限定されるものではない。
【0091】
本明細書で説明した方法のステップは、いずれかの好適な順序で、或いは適切な場合には同時に実行することができる。また、本明細書で説明した主題の趣旨及び範囲から逸脱することなく、いずれかの方法から個々のステップを削除することもできる。上述したいずれかの実施例の態様を上述した他のいずれかの実施例の態様と組み合わせて、探求する効果を失うことなくさらなる実施例を形成することもできる。上述したステップ又はプロセスは、いずれもハードウェア又はソフトウェアで実装することができる。
【0092】
上記の好ましい実施形態に関する説明は一例として示したものにすぎず、添付の特許請求の範囲内で様々な修正が可能であり、当業者が実行できるものであると理解されるであろう。上記では特定の詳細度で、或いは１又は２以上の個々の実施形態を参照しながら様々な実施形態を説明したが、当業者であれば、本発明の範囲から逸脱することなく、開示した実施形態に数多くの変更を加えることができる。
【0093】
本明細書で上述した「エラー」、「エラーデータ」、「入力エラー」、「誤った入力／データ／入力データ」は様々な形態をとることができ、様々な種類のエラーのうちのいずれか１つ（又は２つ以上）の指示を含む。異なる種類のエラーは異なる種類の修正に関連することができる。いくつかの事例では、所与の入力におけるエラーが、入力内に誤った値を含むことであることができる。例えば、入力は、エラーがなければ入力ソース１０４から受け取られたであろう「正しい」又は「意図される」値とは異なる誤った数値を含むことがある。このような値の例示的かつ非限定的な例は、コンピュータリソース値（ＣＰＵ利用率及び／又はクロック速度、プロセス数、スレッド数、ハンドル数、ソケット数及び／又はコア数、キャッシュサイズ、ＲＡＭ使用量、ページ、ハードディスクアクティビティ、及びネットワーク送信／受信速度など）であることができる。このような値のさらなる例示的かつ非限定的な例は、センサ測定値（電圧、電流、抵抗、コンダクタンス、インピーダンス、光（又は輝度）、温度、音、運動（並進又は回転など）、力など）であることができる。このような値のさらなる例示的かつ非限定的な例は、電子ネットワークの受信値（暗号データ、電子証書価格データ（株式／株／ファンドユニット／商品／資産／債券／デリバティブデータ）を含む電子マーケットデータ、公開鍵／秘密鍵／対称鍵値、暗号ノンス値、鍵交換値（例えば、Ｄｉｆｆｉｅ－Ｈｅｌｍａｎ鍵交換値）、ハッシュ値、デジタル署名、及びＡＰＩ又はＲＥＳＴｆｕｌサービスから受け取られた値など）であることができる。このような値のさらなる例示的かつ非限定的な例は、周辺入力値（例えば、マウス、キーボード、タッチ画面、トラックパッド又はトラックボール、ジョイスティック、マイク及びカメラなどを介したユーザによる入力）であることができる。
【0094】
このような場合、エラーの修正は修正値を含むことができる。修正値は、誤った値の代わりに入力データ内に、入力データとして、又は入力データと共に含まれるように意図された値であることができる。このような場合、データモデルに従って目標状態を計算することは、誤った入力データに誤った値ではなく正しい値が含まれていたと仮定した場合にリポジトリが現在あると思われる状態をデータモデルに従って決定することを含む。（エラーの直前の）初期状態が進むはずであった状態を計算することは、誤った入力データに誤った値ではなく正しい値が含まれていたと仮定した場合に初期状態が進むはずであった状態をデータモデルに従って決定することを含むことができる。
【0095】
他の事例では、入力自体が受け取られたという事実がエラーであった可能性もある。例えば、入力ソース１０４から偶然に又は間違えて入力が提供された可能性がある。意図せずに入力が提供された可能性もある。入力が他の誤ったデータに基づいて（及び／又は応答して）提供された可能性もあり、この場合は正しい「他の」データがデータソース１０４に提供されていれば、入力ソース１０４によって入力が提供されることはなかったであろう。このような入力は、例えばコンピュータ化リソースリポジトリに関連するアクション（例えば、１又は２以上のリポジトリからのリソースの状態更新、転送、獲得及び／又は放棄）を実行するコマンドを含むことができる。入力ソース１０４は、入力が誤って提供された（すなわち、提供されるべきではなかった）時にこれを検出するように構成されたハードウェア又はソフトウェアを含むことができ、及び／又は入力が誤って提供されたものであることをユーザが手動で識別するためのインターフェイスを含むことができる。
【0096】
このような場合、エラーの修正はいずれかの「修正後の値」を含む必要はなく、（例えば、タイムスタンプ、一意の数値識別子、又はその他の好適な手段に基づいて）どの入力が誤った入力であったかを識別するだけで十分である。このような場合、データモデルに従って目標状態を計算することは、入力が一度も受け取られなかった（又は少なくとも受け取られなかった）と仮定した場合にリポジトリが現在あると思われる状態をデータモデルに従って決定することを含むことができる。（エラーの直前の）初期状態が進むはずであった状態を計算することは、入力が一度も（又は少なくとも）受け取られなかったと仮定した場合に初期状態が進むはずであった状態をデータモデルに従って決定することを含むことができる。
【0097】
いくつかの事例では、以前の入力におけるエラーが、入力ソース１０４から入力が受け取られなかったことである可能性もあり、すなわちエラーは、データ又はコンテンツが現れるはずであった又は期待されるはずであった過去の時点にデータ又はコンテンツが存在しなかったものである可能性もある。例えば、履歴データの以前の入力のうちの１つが（例えば、リポジトリコントローラ１００のためのいずれかのデータ、値、コマンド又は命令が存在しないことを示す）「空」の又は「ヌル」入力であったが、データモデルに従って何らかの状態更新を引き起こすために入力ソース１０４がリポジトリコントローラに（例えば、何らかのデータ、値、コマンド又は命令を含む）「真」の入力を提供すべきであったことが考えられる。「空」の又は「ヌル」入力は、データモデルに影響を与えないことができる。データモデル及び／又はデータモデルのルールは、「空」の又は「ヌル」入力に応答していずれのコンピュータ化リソースリポジトリの状態にも変更を加えないように構成することができる。データモデル及び／又はそのルールは、このような入力を無視し、又は単純に解析しないことができる。
【0098】
このような場合、エラーの修正は、受け取られるべきであった（が、受け取られなかった）入力の指示を含むことができる。このような場合、データモデルに従って目標状態を計算することは、入力が受け取られたと仮定した場合にリポジトリが現在あると思われる状態をデータモデルに従って決定することを含むことができる。（エラーの直前の）初期状態が進むはずであった状態を計算することは、入力が受け取られたと仮定した場合に初期状態が進むはずであった状態をデータモデルに従って決定することを含むことができる。
【0099】
上述した入力データエラーの種類及び対応する修正の例は、完全なリストを構成するように意図したものではなく、一例として役立つように意図したものにすぎない。
【符号の説明】
【0100】
６００ 方法
６０２ 開始
６０４ データモデル、履歴データ、リソースの現在の量及びエラーデータを受信
６０６ １又は２以上のリポジトリの目標状態を計算
６０８ １又は２以上のリソース量の差分を決定
６１０ 修正のために制御用リポジトリとの間でリソースを割り当て
６１２ 終了
６０２ 開始
６０４ データモデル、履歴データ、リソースの現在の量及びエラーデータを受信
６０６ １又は２以上のリポジトリの目標状態を計算
６０８ １又は２以上のリソース量の差分を決定
６１０ 修正のために制御用リポジトリとの間でリソースを割り当て
６１２ 終了
【図1】
【図2】
【図3A】
【図3B】
【図3C】
【図4】
【図5A】
【図5B】
【図6】
【国際調査報告】