Method and system for electronic resource allocation control - Patents.com

Abstract

A target state of the computerized resource repository is calculated based on the received data model, the received historical data, and the received error data. The data model includes rules for updating a state of each computerized resource repository of the plurality of computerized resource repositories based on one or more inputs. The state of each computerized resource repository includes an amount of resources in each of these computerized resource repositories. The historical data includes a plurality of prior inputs to the data model. The error data indicates an error in one of the prior inputs of the historical data. Then, a difference is determined between a current amount of resources in the computerized resource repository as indicated by the received data and an amount of resources in a target state of the computerized resource repository. Finally, an amount of resources equal to the determined difference is allocated from the controlling computerized resource repository to the computerized resource repository to correct the difference.

Description

[Technical field]

[0001] The present invention relates to a computer-implemented method and system for controlling multiple computerised resource repositories in a resource allocation system, in particular for correcting differences between an actual state of one or more computerised resource repositories and a target state according to a data model. [Background technology]

[0002] Computerized data repositories are currently used in a wide variety of applications for computer-implemented control of electronically stored resources. In many cases, these resources have no "physical" existence outside the computer system used to store them, or at least may only exist as resources within one or more (possibly networked) computer systems, residing within the computer hardware, which may include (but is not limited to) processor registers, random access memory (RAM) hardware, memory cards, flash memory devices such as flash drives and solid state drives, or long-term storage devices such as hard disk drives. Additionally or alternatively, these resources may also be considered to be "logical" or "virtual" resources, in the sense that they are electronic digital representations of resources or assets within or outside the computer system. For example, many modern computer systems distinguish between "logical" memory addresses as perceived by the operating system and actual "physical" addresses within the computer hardware, which may be arranged substantially differently.

[0003] In many cases, a computer system may be used to control multiple computerized resource repositories, each of which at any instant in time is in some "state," which includes or is associated with some particular amount of resources. Furthermore, it may be desirable or necessary for the computer system controlling the repositories to respond to certain inputs by adjusting the amount of resources held in or associated with at least one of the multiple repositories. These inputs may be user-generated or machine-generated, and may arrive at the control directly or indirectly from a source. Furthermore, the decision to adjust the amount of a resource, the direction of this adjustment (whether to increase or decrease the amount), and the magnitude of the adjustment may depend not only on the inputs but also on the current state of the repository (or repositories) to be adjusted.

[0004] For this reason, when processing input, a computer system may follow a "data model" that contains a set of rules that specify exactly how the repository should "progress" from one particular state to the next in response to the arriving input.

[0005] Since the state of any repository may relate to the amount of resources held in or associated with that repository, actually performing a repository state update in response to an input as determined by the data model may require significant changes to the amount / quantity / total amount of resources physically or logically held in that repository. Typically, known existing resource allocation systems may update the state of the repository in accordance with the data model by obtaining a required additional amount of resources from sources external to the resource allocation system, or by relinquishing detected excess amounts of resources back to such external sources. Summary of the Invention [Problem to be solved by the invention]

[0006] Such external sources may be imperfect for various technical reasons. For example, in some situations, resources may be acquired from (or released from) a computerized resource repository by, for example, transmitting an electronic request over a network to acquire or release a specific amount of resources from or to the resource provider. As a result, the amount of resources in this repository may be increased (or decreased), for example, by the resource provider directly allocating the amount of resources to (or from) the repository, again possibly over the same network or over a different network. However, in many contexts, the resource provider may not be able to reliably respond to an electronic request by providing (or taking away) to (or from) the repository exactly the amount of resources specified in the request. That is, the amount of resources that the repository (or a controller on behalf of the repository) initially requested to acquire or release may differ from the amount by which the amount of resources held in the repository is subsequently actually increased / decreased (and / or transferred between the resource provider and the repository). For example, the nature of the external sources may be considered to be such that in response to a request to acquire 10 "units" of some given resource, the repository is actually credited with 12 units.

[0007] Alternatively, in some contexts, a controller may be able to send requests to a resource provider to acquire (or relinquish) various amounts of a resource, such as requests to acquire / relinquish small amounts of a resource, requests to acquire / relinquish medium amounts of a resource, and requests to acquire / relinquish large amounts of a resource, but may not be able to specifically request an exact number of units of the resource to be acquired or relinquished. In such cases, the number of units of the resource actually acquired or relinquished may correspond closely to the amount specified in the request, but it may nevertheless be difficult or impossible to determine in advance how many units will be acquired / relinquished in response to a request for an arbitrary amount.

[0008] It will be appreciated by those skilled in the art that while the above non-limiting illustrative examples (and other illustrative examples provided throughout this disclosure) relate to discrete resources that can be transferred and / or stored in integer quantities, the present invention is by no means limited to application to such discrete resource types (e.g., logical bits in a memory) but is equally applicable to controlling a resource allocation system for continuous resources that can be transferred and / or stored in non-integer quantities (e.g., quantities that can be expressed by rational or real numbers, such as, as a non-limiting example, load / program voltages in a memory device).

[0009] External sources may also be considered imperfect in that they introduce a latency delay between a request to acquire (or relinquish) a certain amount of resources from a computerized resource repository on the one hand, and a subsequent change in the total amount of resources stored or associated with that repository on the other hand. This latency delay may be due to network latency / delay / congestion, a latency in processing the request at the resource provider, or another factor, or a combination of these factors. In any event, such a latency (if any exists) may be determined to be unavoidable and / or acceptable for the purposes of normal routine use of a data model that manages the amount of resources of each computerized resource repository in a plurality of computerized resource repositories by acquiring or relinquishing resources from external sources according to update rules.

[0010] However, these problems become much more pronounced in situations where the controller continues to use the data model successfully in this manner to acquire or relinquish resources to the repositories in response to a series of inputs, and then one of the previous inputs to the model is determined to be erroneous, such that the current state of at least one repository contains more or less resources than at least one repository should currently have (based on the previous inputs as "corrected" in light of the update rules of the data model).

[0011] One way for a computer-implemented resource controller to "correct" these errors would be to calculate a target repository state (i.e., the state that "should" be and would have been if the error had not occurred) based on the data model, the historical input data previously used to iteratively advance each repository from one state to the next over time, and the details of the errors and their correction, and then compare this target state with the actual current state of the repository (affected by the errors) to determine the difference in the amount of resources. For example, by replaying all inputs to the model in this manner from the erroneous input to the latest model input, and simulating the evolution of the state of each repository accordingly, it may be determined that the repository contains too many or too few resources. The controller may then attempt to correct the discrepancy between the target state and the actual state by attempting, in this simple solution, to increase or decrease the amount of resources currently held in or associated with the repository. This may be done, for example, by sending a request to an external source, such as a resource provider, to acquire / relinquish an amount of resources equal to the determined discrepancy.

[0012] The problem with this approach is that the correction of the error itself is subject to the same mechanical delay introduced by the external source, i.e., an error in the input is detected, a corrected value is received, this corrected value is used together with other previous inputs to replay the evolution of the repository state according to the update rules and thus calculate the target state, an actual state / target state difference is determined, and an attempt has been made to correct the error by requesting the external source to acquire or relinquish resources, and the state of the repository may still be inaccurate (i.e. have a different amount of resources compared to the "target" state determined by the data model and previous inputs) indefinitely, i.e. forever or for any long period of time.

[0013] Even worse, the controller may have received new data model input during the mechanical delay (i.e., after a mismatch in the amount of resources in one or more repositories has been determined, but before the amount of resources has been increased or decreased to correct the mismatch), so in such an instance the controller would either have to postpone / stop updating the repository state until the error is fully resolved by acquiring / releasing an amount of resources from / to an external source (which would likely be unacceptable), or, while waiting to acquire / releasing the resources, apply all of the relevant state updates when any new input is received, and then deal with the fact that when the requested resource finally comes in (or goes out), the repository's own state has meanwhile transitioned in response to the new input or inputs, and so the resource is no longer the exact amount required to correct the mismatch.

[0014] As briefly mentioned above, the above problems are further complicated when external sources cannot be trusted to increase and / or decrease the exact amount of repository resources requested by the controller. For example, a resource provider may not always be able (or willing) to allocate the exact amount of resources requested to a computerized resource repository. Additionally or alternatively, a resource provider may not always be able (or willing) to remove a specified amount of resources from a computerized resource repository. As a result, in many situations, it proves very difficult to correct errors using the techniques mentioned above, since attempts to acquire or relinquish a certain amount of resources to / from a resource repository to correct a calculated discrepancy are likely to result in a further "wrong" amount being saved by electronically allocating too much or too little, thus simply propagating the error (partially) from one point in time to a later point in time at some stage, rather than (fully) resolving the error.

[0015] SUMMARY OF THE PRESENT EMBODIMENT It is an object of the present invention to solve the above-mentioned and other problems associated with controlling resource allocation within a collection of computerized resource repositories. [Means for solving the problem]

[0016] In a first aspect of the present invention, there is provided a computer-implemented method for controlling a plurality of computerized resource repositories in a resource allocation system, the computer-implemented method comprising: receiving a data model of resources including rules for updating a state of each of the plurality of computerized resource repositories including an amount of resources in each computerized resource repository based on one or more inputs; historical data including a plurality of previous inputs into the data model; data indicative of a current amount of resources in a first computerized resource repository of the plurality of computerized resource repositories; and error data indicative of an error in one of the previous inputs of the historical data; calculating a target state of the first computerized resource repository based on the data model, the historical data and the error data; determining a difference between the current amount of resources in the first computerized resource repository and the amount of resources in the target state of the first computerized resource repository; and allocating an amount of resources equal to the determined difference from the controlling computerized resource repository to the first computerized resource repository or vice versa to correct the difference.

[0017] In situations where it is necessary or desirable to closely manage how resources are distributed among a set of repositories and / or to manage the flow of resources into, out of, and within a system, data models for resource allocation are often successfully employed. Such models can be used to model the allocation of estimated or ideal resource amounts as a function of inputs in industries where there may be an element of "lag" or "delay" between changes or updates to repository states determined by simulations or models and the acquisition or relinquishment of actual physical resources, such as chemical processing, manufacturing, water treatment, or fuel-based power generation. Similarly, such mechanical delays may also be felt in areas of data models that involve resources that exist only or primarily in electronic form, such as calculations and data processing.

[0018] The use of a controlling computerized resource repository allows the repository controller to correct discrepancies between current and target amounts with a single resource amount allocation, and no longer has to rely on slower and / or less reliable solutions (e.g. sending requests to external sources such as resource providers to acquire or relinquish some amount of resources). This means that a problem of a first repository being in an incorrect state due to an error in previous input data can be fully and accurately resolved (rather than simply propagated and / or partially resolved) before further data model inputs cause the model to proceed to subsequent processing stages to calculate the next set of state updates for the repository, potentially affecting the state of the first repository as well. Thus, the effects of the incorrect input data are directly eliminated, rather than being compounded (as would be the case in the absence of a controlling repository).

[0019] Optionally, the method may further include receiving one or more data model inputs and updating a state of one or more computerized resource repositories of the plurality of computerized resource repositories based on the data model and the one or more received data model inputs.

[0020] Additionally or alternatively, the method may optionally further include determining whether a current amount of resources in the controlling computerized resource repository is outside a threshold range and, in accordance with the determination, updating the state of the controlling computerized resource repository to bring the amount within the threshold range. This ensures that the controlling repository maintains the amount of resources within a predefined "tolerance" range, which may be beneficial when it is desirable to prevent an excess of resources stored in the controlling repository (such as is often the case in industrial resource control systems) and / or a shortage or loss of resources stored in the controlling repository.

[0021] Updating the state of the computerized resource repository can include increasing or decreasing the amount of a resource in the computerized resource repository, which can include updating by increasing or decreasing the amount of a resource from a source external to the implementing computer.

[0022] The increase or decrease can be associated with a first mechanical delay, for example, the first mechanical delay can be caused by a delay incurred from an external source, and the allocating an amount of resources equal to the determined difference can be associated with a second mechanical delay, the second mechanical delay being shorter than the first mechanical delay.

[0023] The first mechanical delay can be in the range of 1 minute to 1 week, 10 minutes to 1 week, 30 minutes to 1 week, 1 hour to 1 week, 6 hours to 1 week, 12 hours to 1 week, or 1 day to 1 week. The first mechanical delay can be in the range of 1 minute to 5 days, 10 minutes to 5 days, 30 minutes to 5 days, 1 hour to 5 days, 6 hours to 5 days, 12 hours to 5 days, or 1 day to 5 days. The first mechanical delay can be in the range of 1 minute to 3 days, 10 minutes to 3 days, 30 minutes to 3 days, 1 hour to 3 days, 6 hours to 3 days, 12 hours to 3 days, or 1 day to 3 days. The first mechanical delay can be in the range of 1 minute to 1 day, 10 minutes to 1 day, 30 minutes to 1 day, 1 hour to 1 day, 6 hours to 1 day, or 12 hours to 1 day. In the above example, "1 day" means 24 hours and "1 week" means 168 hours.

[0024] The first mechanical delay can be in the range of 0.1 ms to 10 min, 0.1 ms to 5 min, 0.1 ms to 2 min, 0.1 ms to 1 min, 0.1 ms to 30 sec, 0.1 ms to 10 sec, 0.1 ms to 1 sec, 0.1 ms to 100 ms, 0.1 ms to 10 ms, or 0.1 ms to 1 ms. The first mechanical delay can be in the range of 10 ms to 10 min, 10 ms to 5 min, 10 ms to 2 min, 10 ms to 1 min, 10 ms to 30 sec, 10 ms to 10 sec, 10 ms to 1 sec, or 10 ms to 100 ms. The first mechanical delay can be in the range of 1 sec to 10 min, 1 sec to 5 min, 1 sec to 2 min, 1 sec to 1 min, 1 sec to 30 sec, or 1 sec to 10 sec.

[0025] The second mechanical delay can be less than 12 hours, less than 6 hours, less than 3 hours, less than 1 hour, less than 30 minutes, less than 10 minutes, less than 5 minutes, less than 2 minutes, less than 1 minute, less than 30 seconds, less than 10 seconds, less than 1 second, less than 10 milliseconds, or less than 0.1 milliseconds. Allocating an amount of resources equal to the determined difference can occur instantaneously. Having a small second mechanical delay or allocating the amount instantaneously allows for an improvement in the speed with which errors in the current amount of the first computerized resource repository can be corrected since there is no need to wait for the first mechanical delay to elapse.

[0026] The target state of the first computerized resource repository may correspond to a current state of the first computerized resource repository that would be assumed according to the data model and the historical data if no error had occurred.

[0027] In some optional embodiments, the method may further include receiving data indicative of a current amount of a resource in a second computerized resource repository of the plurality of computerized resource repositories, calculating a target state of the second computerized resource repository based on the data model, the historical data and the error data, determining a difference between the current amount of the resource in the second computerized resource repository and the amount of the resource in the target state of the second computerized resource repository, and allocating an amount of the resource from the controlling computerized resource repository to the second computerized resource repository or vice versa to correct the difference. In this manner, one controlling computerized resource repository may be used to correct amounts of resources in multiple computerized resource repositories affected by the same item of erroneous input data for the same resource and data model.

[0028] Optionally, each data model input may be received from an input provider of a plurality of input providers, the controlling computerized resource repository being one of the plurality of controlling computerized resource repositories, each controlling computerized resource repository may be associated with an input provider, and the controlling computerized resource repository selected to correct the difference may be associated with the input provider that is the source of the error.

[0029] In a further aspect of the invention there is provided an apparatus comprising a memory containing instructions and a processor, the instructions being configured, when executed by the processor, to cause the processor to perform the above method.In a further aspect of the invention there is provided a computer program comprising computer readable instructions, the computer readable instructions being configured, when executed by the processor, to cause the processor to perform the above method.

[0030] The invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0031] [Figure 1] FIG. 1 is a component diagram of an overall resource allocation system in which the present invention is implemented. [Diagram 2] FIG. 2 is a component diagram of the repository controller (and other computing devices) of FIG. 1. [Figure 3A] FIG. 2 illustrates (at least a portion of) an exemplary data model. [Figure 3B] FIG. 3B illustrates the evolution of a computerized resource repository according to the data model of FIG. 3A based on a combination of various inputs at successive times. [Figure 3C] FIG. 3B illustrates a regeneration event in the data model of FIG. 3A in response to error data. [Figure 4] FIG. 1 illustrates an exemplary “simple” closed-loop approach to error correction for a set of repositories. [Figure 5A] FIG. 13 illustrates an improved approach that involves using a controlling repository to allocate an amount of resources equal to the determined difference, according to an embodiment of the present invention. [Figure 5B] FIG. 13 illustrates an improved approach that involves using a controlling repository to allocate an amount of resources equal to the determined difference, according to an embodiment of the present invention. [Figure 6]1 is a flowchart of a computer-implemented method for controlling multiple computerized resource repositories in a resource allocation system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] FIG. 1 illustrates a system 10 for resource allocation involving a computerized resource repository. The system 10 includes a repository controller 100, a resource provider 102, an input source 104, and any further input source 106... Each of the repository controller 100, the resource provider 102, and the input source(s) 104, 106... may communicate with each other via the Internet 108, and is illustrated as such in FIG. 1, but one skilled in the art will recognize that other network configurations of the repository controller 100, the resource provider 102, and the input source(s) 104, 106... are possible. For example, the input sources and the resource providers need not share a direct connection or be connected by the Internet, as long as they are connected to the repository controller in some way. The repository controller 100 is configured to process input received from the input source 104 according to the processes described herein.

[0033] 2 illustrates further components of the repository controller 100, including a processor 202, a memory 204 and a communication interface 206. The processor 202 is configured to retrieve computer executable code from the memory 204 and execute the computer executable code to perform the processes described herein. The resource providers 102, the input sources 104 and any further input sources 106... may also each be configured to have the same shape and types of components as shown in FIG. 2. In some embodiments, any one or more of the repository controller 100, the resource providers 102 and the input source(s) 104, 106... may further be configured to have components for user interaction, such as a display and / or a user input device configured to receive user input to the processor 202. However, it will be appreciated that such user convenience features are by no means necessary to realize the advantages associated with the present invention.

[0034] In some embodiments, the repository controller 100 stores multiple computerized resource repositories (not shown here) in memory 204. The multiple repositories may be stored in short-term type memory hardware in memory 204, such as RAM. Additionally or alternatively, the repositories may be stored in longer-term devices in memory 204 having larger capacity, such as a hard disk drive. In some embodiments, the repositories and their data may be stored external to the repository controller 100, such as in a database of another computing device connected to the repository controller 100 via a network, such as the Internet 108. In either case, the repositories and / or data about the repositories (such as the amount of resources held in or associated with each repository) are preferably easily and quickly accessible by the repository controller 100.

[0035] In some embodiments, the repository may physically contain the resource. However, in other embodiments, each repository may function as a "logical" store that holds an electronic representation of the resource itself; for example, if an empty memory page is a resource and one empty memory page does not differ (in terms of functional content) from another memory page, then each repository may simply contain a numerical representation of the number of empty memory pages associated with this particular repository, rather than physically containing this set of empty pages within the computer hardware of the resource controller 100. The present invention may be particularly effective when applied to such "uniform" resources, i.e. resources where any two given discontinuous units of the resource are functionally similar.

[0036] The data model is stored in hardware such as memory 204 that is easily accessible to the processor 202 of the repository controller 100. The data model may be held in ROM or RAM, or may be held on and read from a solid state drive or hard disk drive, or may be stored external to the repository controller 100 and read over a network such as the Internet 108 using the communications interface 206. Other technical means for storing and retrieving the data model for use by the processor 202 will be apparent to those skilled in the art.

[0037] The processor 202 is configured to receive data model inputs from the input sources 104 via the Internet 108 and the communication interface 206. The input sources 104 may provide these inputs in response to actions, commands or other inputs provided to the input sources 104 by a human user. These inputs may be direct in nature, such as a user moving a mouse and clicking or entering keystrokes on a peripheral device connected to the input sources 104, or indirect in nature, such as received from another computing device (not shown) communicatively coupled to the input sources 104. Alternatively or additionally, the inputs received from the input sources may be machine-generated inputs, e.g. data calculated by a processing component of a server (which may be the input source 104 itself). Optionally, further inputs may be sent to the repository controller and / or generated in one or more further input sources 106... In many of the contemplated embodiments of the present invention, each input source 104, 106... provides user inputs and commands to the repository controller 100, or provides input in the form of machine-generated data, although it will be appreciated that any input source 104, 106... can provide any type of data model input to the repository controller 100, or can provide a mix of multiple different types of inputs.

[0038] The transmission of data model inputs from the input source 104 (and / or any further sources) to the repository controller 100, and indeed any data transfer between components of the resource allocation system 10, may be accomplished in a variety of specific ways, many of which will inherently be understood to be functionally equivalent for purposes of the present invention. For example, data may be transferred from one computing component to another over a network such as the Internet 108 through a "push" style proactive transmission step by the transferring component, or through a "pull" style step performed on the processor of the receiving component, such as repeatedly polling the transferring component to determine whether new data is available and ready to be transferred. As known to those skilled in the art, networking may be implemented using a layered model, such as the TCP / IP model, according to any suitable selected set of application layer protocols, transport layer protocols, internet layer protocols, and data link layer protocols.

[0039] As will be explained in more detail with reference to Figures 3A-3C below, the processor 202 of the repository controller 100 is configured to use the received data model input together with the data model to calculate state updates for the multiple repositories. At each subsequent processing stage, the processor 202 is configured to compare the "current" amount of resources in each of the multiple repositories (i.e. the amount relating to the current state before being updated according to the data model) with the amount in the calculated updated state to determine an increase or decrease in the amount of resources required to effect the update determined by the data model, and to change the state of each repository accordingly to match the "next" or "updated" state determined according to the input. As will be explained in more detail below, this increase / decrease in the amount of resources for each repository can be achieved by subsequently acquiring from (or relinquishing to) a certain amount of resources from the resource provider 102.

[0040] The repository controller 100 may be configured to use the processor 202 to compute and / or establish repository state updates from one processing stage to another as described above. In some embodiments, a "processing stage" may refer to successive points in time, e.g., points in time uniformly separated by a predefined interval. In such an example, updates may be computed (for example) every hundredth of a second, regardless of whether an input has been received. However, in some embodiments, a "processing stage" may also be an event-based stage defined by reference to the arrival of a new data model input, perhaps because an updated repository state does not need to be computed until the next input is received from the input provider 104, and thus computational resources would not be wasted.

[0041] The repository controller need not at all effect the computed state updates of the computerized resource repository simultaneously or immediately after the computation. In fact, in many currently contemplated embodiments, the repository controller 100 may compute multiple state updates consecutively without actually increasing or decreasing the repository volume of interest, but may choose to actually acquire or relinquish resources from or to the resource providers 102 to effect the state updates substantially less frequently. In other words, the repository controller 100 may compute multiple updated states of the repositories under its control without making any changes to the repository state, and then effectively bring the repository up to date "in batches" by acquiring or relinquishing resources to / from the resource providers 102 at once as needed. Such "batch" acquisitions or relinquishes are believed to be advantageous in that they may reduce the total number of requests that must be sent from the repository controller 100 to the resource providers 102 over any period of time, thus conserving computational and network resources of the resource allocation system 10.

[0042] Once the repository controller 100 has calculated the amount of resources each repository must acquire or relinquish to bring its state into line with the updated state determined by the data model and input(s), it sends the data in the form of an electronic request to the resource providers 102 to add (or remove) a certain amount of resources to (or from) one or more repositories. As mentioned above, there may be a mechanical delay between the sending of this request and the actual change in the amount of resources in the repository. In some embodiments, the resource provider 102 may cause the delay by finalizing the electronic acquisition or relinquishment of the resources some time after receiving the request, or at least some time after the submission of the request by the repository controller 100.

[0043] The repository controller 100 may store records of previously received past data model inputs in a suitable data structure, such as a database, in the memory 204. Additionally or alternatively, the record data representing past inputs of the data model may be stored in another computer system communicatively coupled to the repository controller 100, or distributed across multiple such systems, and the repository controller 100 may be configured to obtain this data "on the fly" when needed by querying the other computer system and requesting the data. This data may then be transferred in batches to the repository controller 100. In some embodiments, one or both of the input providers 104 and / or the resource providers 102 may function as the "other" computer system that stores the past data model input records.

[0044] The repository controller is also configured to receive error data indicating errors in the previous inputs from the input providers 104 and optionally from the further input providers 106.... Further details of the error data are described below in Figure 3C.

[0045] 3A-3C, an exemplary data model 300, or at least a portion thereof, is illustrated. The data model 300 includes update rules 350 for a number of possible repository states 310-346 based on various combinations of inputs 352, 354, 356 received in successive processing stages. The illustrated (non-limiting) example of FIG. 3A shows twelve update rules 350 that uniquely define transitions between thirteen states 310-346 in successive stages in response to three possible inputs 352, 354, 356. However, one skilled in the art will recognize that in practice the state space of a repository may include many more states (and may in fact be infinite), the space of possible data model inputs may be much larger (and may be infinite), and a real data model may define many more update rules than are shown in FIG. 3A (and may define an infinite number of such rules). In cases where the space of possible inputs is large and exact repetition of data model inputs never or very rarely occurs, e.g., the exemplary data model 300 shown in FIG. 3A includes an initial processing step t n and the subsequent processing step t n+1 Although the update rule 350 is shown for the same inputs a, b and c (352, 354, 356) in both steps t n+1 In some cases, new input a', b', or c' (not shown) not previously seen in may be received.

[0046] The data model 300 specifies how the repository should "progress" from one particular state to the next in response to the arrival of an input. In general, the update rules 350 of the data model 300 define a "current" state and an input or set of inputs {i1, i2...i n} and output a "next" or "updated" state s∈S of the repository. In many instances, the data model 300 may define a single common set of update rules to apply across multiple repositories. That is, given multiple repositories R, if two repositories r1 and r2 have the same current state, the data model 300 may have, or is well-defined, the property that applying the same input to both r1 and r2 will update both r1, r2 to the same identical subsequent state.

[0047] Referring to FIG. 3A, the update rule 350 is set to a value that is equal to or greater than the time t before the repository controller 100 receives any of the inputs 352, 354, 356. n The initial stage t can be understood by reference to the effect on a repository having a state 310 at some specifically marked "current" or "initial" moment in time. n In FIG. 3A-3C , no input has been sent from the input provider 104 to the repository controller 100, and the repository holds 100 resources (or at least a logical representation thereof). The data model 300 continues to operate at a subsequent stage t after the repository controller 100 receives an input, which can be a first input 352 (denoted as “a” in FIG. 3A-3C ), a second input 354 (denoted as “b”), or a third input 356 (denoted as “c”). n+1 3 determines that the repository should be updated to a new state which will be one of states 320, 322 or 324 depending on whether the input received was a first input 352, a second input 354 or a third input 356, respectively. State 320 reached from initial state 310 by the arrival of first input 352 holds 105 units of the resource. State 322 reached from initial state 310 by the arrival of second input 354 holds 110 units of the resource. State 324 reached from initial state 310 by the arrival of third input 356 holds 85 units of the resource.

[0048] The repository controller 100 performs this subsequent processing step t n+1 , further updated states can be calculated when another input 352, 354, 356 is received. For example, if the repository is in state 320 and a first input 352 is received, the update rules of the data model 300 determine that the next state of the repository is state 330. If the repository is in state 320 and a second input 354 is received, the update rules of the data model 300 determine that the next state of the repository is state 332. If the repository is in state 320 and a third input 356 is received, the update rules of the data model 300 determine that the next state of the repository is state 334.

[0049] Similarly, if the repository is in state 322 and a first input 352 is received, the update rules of data model 300 determine that the next state of the repository is state 336. If the repository is in state 322 and a second input 354 is received, the update rules of data model 300 determine that the next state of the repository is state 338. If the repository is in state 322 and a third input 356 is received, the update rules of data model 300 determine that the next state of the repository is state 340.

[0050] Finally, if the repository is in state 324 and a first input 352 is received, the update rules of data model 300 determine that the next state of the repository is state 342. If the repository is in state 324 and a second input 354 is received, the update rules of data model 300 determine that the next state of the repository is state 344. If the repository is in state 324 and a third input 356 is received, the update rules of data model 300 determine that the next state of the repository is state 346.

[0051] The data model 300 is then updated after this next input is received by the repository controller 100 (i.e., processing stage t n+23) results in a new state of the repository, which can be one of states 330, 332, 334, 336, 338, 340, 342, 344 or 346 depending on the combination of inputs received. State 330, reached from initial state 310 by the arrival of two successive instances of the first input 352, holds 95 units of resources. State 332, reached from initial state 310 by the arrival of an instance of the second input 354 after an instance of the first input 352, holds 120 units of resources. State 334, reached from initial state 310 by the arrival of an instance of the third input 356 after an instance of the first input 352, holds 115 units of resources. State 336, reached from initial state 310 by the arrival of an instance of the first input 352 after an instance of the second input 354, holds 100 units of resources. State 338, reached from the initial state 310 by the arrival of two successive instances of the second input 354, holds 70 units of resources. State 340, reached from the initial state 310 by the arrival of an instance of the third input 356 after an instance of the second input 354, holds 60 units of resources. State 342, reached from the initial state 310 by the arrival of an instance of the first input 352 after an instance of the third input 356, holds 85 units of resources. State 344, reached from the initial state 310 by the arrival of an instance of the second input 354 after an instance of the third input 356, holds 105 units of resources. State 346, reached from the initial state 310 by the arrival of two successive instances of the third input 356, holds 65 units of resources.

[0052] 3B illustrates an example of one possible "path" through states according to the update rules 350 of the data model 300 that the repository controller 100 may actually take for a given computerized resource repository. In the illustrated example, the repository controller 100 may update the state of the data model 300 in response to receiving two successive inputs from the input provider 104 (first at processing stage t nFirst, the repository controller 100 receives a second input 354 from the input provider 104 and determines, using the data model 300, that the repository should be updated to a state 322 that holds 110 resources, 10 more than the initial state 310. The repository controller 100 then calculates two state updates for the repository (which is in state 310 at step t n+1 receives a third input 356 from the input provider 104 and determines, using the data model 300, that the repository should be updated to a state 340 holding 60 resources, which is 40 fewer than the initial state 310 (and 50 fewer than the intermediate state 322).

[0053] In this example, the repository controller 100 may request acquisition or relinquishment of resources from or to the resource provider 102 as each input is received and the updated state is calculated. That is, the repository controller 100 may attempt to increase the amount of resources in the repository to 110 units, for example by requesting to acquire 10 units of resources from the resource provider 102, after calculating the update from state 310 to state 322 in response to the second input 354. The repository controller 100 may then attempt to decrease the amount of resources in the repository to 60 units, for example by requesting the resource provider 102 to relinquish the appropriate number of resources, after calculating the update from state 322 to state 340 in response to the third input 356. In another example, the repository controller 100 may choose not to take any action regarding resource allocation when calculating the state 322 based on the data model 300 and the second input 354, and only to enact the state update of the computerized resource repository at a later time. In any case, as mentioned above, a resource acquisition / relinquishment request may only be fulfilled by the resource provider after a mechanical delay, and the amount of resource actually acquired or relinquished may differ from the amount requested by the repository controller 100.

[0054] Reference is now made to FIG. 3C, which illustrates a replay event in response to error data 360. In an embodiment of the present invention, the input provider 104 (and any further input provider 106..., the reference of which is omitted hereafter for the sake of brevity only) may be responsible for sending a significantly large amount of input data to the repository controller 100, and may continue to do so for a significantly long period of time. At this scale and time frame, it is almost inevitable that errors will be found among this input data, and therefore it is desirable for the repository controller 100 to be able to mitigate or eliminate the impact of such errors on the state and content of each repository in the multiple computerized resource repositories. Ideally, given details of errors that occurred in previous inputs (including the "true" or "corrected" values ​​of the erroneous inputs), the repository controller 100 should be able to perform compensatory state updates to one or more repositories affected by the errors, ultimately bringing all repositories to the state they would have been in if the errors had not occurred. In this way, given past inputs received for the data model 300, the repository controller 100 can apply state updates to repositories that have deviated or strayed from the data model due to the presence of input errors, in order to return those repositories to the state they should have been in.

[0055] The repository controller 100 is configured to receive error data 360 from the input provider 104 in any suitable form, such as XML, JavaScript Object Notation (JSON), or any other suitable data structure or format as will be appreciated by those skilled in the art. In the example shown in FIG. 3C, the error data 360 is received from a previous processing stage t n In this example, the error data 360 includes an indication that the input 362 received by the repository controller 100 from the input provider 104 at the previous processing stage t nOf course, those skilled in the art will appreciate that the error data 360 need not include or consist of any particular combination of values, but may include any combination of values ​​necessary to enable calculation of the target repository state as described below. n One will appreciate that, for example, error data 360 need only include such an indication 364, since an indication 364 indicating a "corrected" value at t is sufficient (although indication 362 may provide some benefit for validation or bookkeeping purposes). Additionally or alternatively, error data may be provided at a processing stage t where erroneous data was received. n It is not necessary to identify the erroneous input (and its correction) through reference to any other suitable unique identifier.

[0056] After receiving the error data 360, the repository controller 100 uses the error data 360 in combination with the data model 300 and known previous inputs to calculate a goal state of the repository or repositories affected by the error. The goal state may correspond to a current state that the repository / repositories would have reached according to the data model and previous input data if the error had not occurred.

[0057] For example, in the example shown across FIGS. 3B and 3C, the set of related past inputs is n The occurrence of the second input 354 at stage t n+1 The combination of these has led the repository from the initial state 310 to the current state 340 having 60 units of resources. The repository controller 100 then performs a step t nRepository controller 100 receives error data 360 indicating that the occurrence of second input 354 in step t was in fact an error, and that the intended "correct" input for this processing step was instead an instance of first input 352. Conversely, if no error data is present, repository controller 100 may select the remaining previous input (in this case, step t n+1 It can be assumed that the instance of the second input 354 received at

[0058] To determine the “intended” state in the absence of errors, the repository controller’s processor 200 computes the destination state by “rolling back” the current state of any repository to a point just before the erroneous input; in this case, the processor 200 computes the destination state at t n The processor 200 then uses the corrected input values ​​364 in combination with the data model 300 and, if there are no errors, rolls back to t n+1 Finally, the processor 200 uses the remaining past input data and the data model 300 to perform a final state update of the repository from state 320 to state 334, i.e., the final update of the repository from state 320 to state 334 if no errors occurred during process t. n+2 3. The repository then calculates the intended "final" state that it was to end up in, and in this goal state 334, it would have had 115 units of physical or logical resources.

[0059] At this point in the method, the repository controller 100 determines (using the processor 200) the difference between the current amount of resource in the computerized resource repository (60 units of resource since the repository is in state 340) and the amount of resource in the target state of the computerized resource repository (115 units). In the example shown in Figures 3B and 3C, the repository controller 100 determines a difference of 55 units by subtracting 60 from 115 using the processor 200. This difference can be called the "discrepancy" or "error term" and is useful to the repository controller in that it represents the amount of resource that must be acquired by (or relinquished from) the affected repository to counteract the effect of the error and converge to the target state according to the data model 300.

[0060] In the above illustrated example, it is observed that a single input error in the initial processing stage of the data model 300 ultimately led to a substantial discrepancy between the amount of intended resources and the actual amount of resources in the repository. n+1 While the impact of the error on the resource budget was relatively small, the impact becomes more exacerbated as the repository controller 100 receives and processes further inputs from the input providers 104. In other words, the data model is highly path-dependent in the sense that one potentially small past error in an input affecting the repository can have a significantly larger impact on the state of the repository in the long run, making it necessary to theoretically recalculate each processing step after regenerating the input from the point of the error by correcting the error, and ultimately determining the change in the state of the repository. The present invention can be particularly effective when applied in the context of such a path-dependent data model.

[0061] Reference is now made to FIG. 4, which illustrates a simple error compensation method as described above for a plurality of computerized resource repositories 400. For simplicity and to better illustrate the process of guiding repositories affected by input errors towards a "goal state", the plurality of repositories 400 are shown to include a plurality of repositories 402 in a common "correct" state S1 and a repository 404 in an "incorrect" state S'1, with the repository controller 100 managing all of these repositories in response to data model inputs (not shown) that have the same effect on all of the repositories 402 and 404. However, as will be appreciated by those skilled in the art, an actual plurality of computerized resource repositories 400 may include repositories in a number of different individual states, and thus a data model input may affect the computed state of many of these repositories in different ways. In some embodiments, a data model input may be provided that affects the state of only one repository of the plurality of repositories 400, leaving the state of the other repositories unchanged.

[0062] In the example shown in FIG. mAt this same stage of processing, repositories 402 are each in state S1 and therefore each contain (or are otherwise associated with) 115 units of resources. At this same stage of processing, affected repository 404 is in an "incorrect" state S'1 and therefore contains (or is otherwise associated with) only 60 units of resources. Thus, at this stage of processing, there is a difference of 55 units between the state of repository 404 and state S1 (which for purposes of illustration represents the target state of repository 404 in the absence of prior errors), which the repository controller has determined via a replay event as described above. It may be difficult, impractical or impossible for repository controller 100 to immediately correct this discrepancy, since the frequency of receipt of data model inputs and subsequent required state updates is high for multiple repositories 400, and new inputs and updates may be received and generated during the window in which repository controller 100 is attempting to acquire (in this case) the 55 missing resource units, i.e., by the time the resources are acquired the "correct" state will be different and the new state will quickly become out of date.

[0063] To prevent this problem, the repository controller can attempt to modify requests made to the resource provider 102 on behalf of the affected repository 404 in a manner that compensates for the discrepancy between states. In the example of Fig. 4, the repository controller 100, according to inputs received (not shown), makes a determination using the data model 300 that the amount of the resource in the computerized resource repository 402 should be increased by 10 units, and sends a request to the resource provider 102 accordingly. At the same time (or nearly the same time), the repository controller 100 sends a request to the resource provider 102 that attempts to acquire 65 units of the resource for the affected repository 404 (thus compensating for the discrepancy while advancing the state of the repository according to the target state and the data model 300).

[0064] Due to the unpredictability of the trustworthiness of the resource providers 102, each repository acquires a slightly larger amount of resources than the repository controller 100 requested. Starting from state S1, each repository 402 actually acquires 12 units of resources instead of 10 units, and thus in the subsequent processing stage t m+1 In the new state S2, the repository 404 has 127 units of resources. On the other hand, the affected repository 404 actually acquires 78 units of resources instead of 65 units, and therefore moves from state S′1 to the subsequent processing stage t m+1 Then we proceed to a new state S'2 with 138 units of resources, i.e. the error has not been corrected.

[0065] The repository controller 100 again receives input (not shown) and therefore, using the data model 300, makes a determination that the amount of the resource in the computerized resource repository 402 should be reduced by 5 units, and sends the associated request (or series of requests) to the resource provider 102. At the same time (or nearly the same time), the repository controller 100 sends a request to the resource provider 102 to relinquish 16 units of the resource in the affected repository 404 in an attempt to correct the discrepancy.

[0066] Due to the unpredictability of the trustworthiness of the resource providers 102, each repository relinquishes a slightly smaller amount of resources than the repository controller 100 requested. Each repository 402 that was previously in state S2 actually relinquishes 4 units of resources instead of 5 units, and therefore in the subsequent processing step t m+2 In the new state S3, the repository has 123 units of resources. On the other hand, the affected repository 404 actually gave up 12 units of resources instead of 16 units, and therefore has a new state S3 from state S'2 to the subsequent processing stage t m+2 Then we proceed to a new state S'3 with 126 units of resources, ie the error is still not corrected.

[0067] It can therefore be seen that such an approach of correcting state inconsistencies after they have been determined via replay events is suboptimal and, although it may reduce the magnitude of the inconsistency in this example, the inconsistency may continue to persist for multiple further processing stages. In practice, due to the unreliable nature of the resource provider's external acquisition and / or relinquishment of resources between the repository controller 100 and its multiple repositories 400, the inconsistency may (at least in principle) persist indefinitely and never be resolved. It is not immediately clear (without the benefit of this disclosure) how this problem could be reasonably solved.

[0068] 5A and 5B show a solution to the above problem according to an embodiment of the present invention. FIG. 5A shows a number of repositories 502 in state S1 and a processing stage t m 5A and 5B show a plurality of computerized resource repositories 500 including a repository 502 that has reached state S'1 in step S1 and a repository 504 that has reached state S'2 in step S1 instead of the target state S1. The plurality of repositories 500 can be similar to the plurality of repositories 400 described above, in the sense that the repository 502 can be similar to the repository 402 and the affected repository 504 is similar to the affected repository 404. However, in the embodiment shown in Figures 5A and 5B, unlike the example of Figure 4, the repository controller 100 utilizes (at least one) special "control" computerized resource repository 506 (indicated by a "C" symbol in the lower right corner in Figures 5A and 5B) as part of an error correction process as will be described in more detail below.

[0069] FIG. 5A illustrates a processing step t after the repository controller 100 receives the error data 360 and uses it in combination with the data model 300 and historical data including previous data model inputs to calculate a target state for the affected repository 504 as described herein above. m5 shows multiple repositories 500 and a controlling repository 506. The repository controller 100 determines a difference 508 between the amount of resource in the affected repository 504 and the amount of resource in the calculated target state, in this case 55 units of resource.

[0070] The repository controller 100 does not attempt to correct the difference 508 by, for example, acquiring or relinquishing an amount of resources “externally” from or to the resource provider 102, but instead compensates the affected repository 504 to correct the difference by directly allocating an amount of resources from the controlling repository 506 to the affected repository 504 or vice versa, equal to the determined difference 508. That is, if the determined difference indicates that the affected repository 504 has an excess of resources compared to its target state, the difference is corrected by transferring an appropriate amount of resources from the affected repository 504 to the controlling repository 506, and if the determined difference indicates that the affected repository 504 has a shortage of resources compared to its target state, the difference is corrected by transferring an appropriate amount of resources from the controlling repository 506 to the affected repository 504. For example, in the embodiment of FIG. 5A, the repository controller 100 determines that 55 units of resources should be allocated from the controlling repository 506 to the affected repository 504 to correct the determined difference 508.

[0071] 5B illustrates the multiple repositories 500 and the controlling repository 506 immediately following a direct allocation from the controlling repository 506 to the affected repository 504. As can be seen in this figure, the repository 504 has returned to the target state S1 without the need for the repository controller 100 to interact with the resource provider 102, and retains (or is otherwise associated with) the "correct" amount of resource according to the data model 300, namely 115 units. In the illustrated embodiment, after the transfer of this amount, 945 units of resource remain in the controlling repository 506. In the illustrated embodiment, this process may progress to a subsequent processing stage t m+1 All processing steps before t m It is occurring "inside".

[0072] In some embodiments, direct allocation from the repository 504 to the controlling repository 506 or vice versa occurs instantaneously. In some embodiments, this direct allocation occurs substantially instantaneously. In some embodiments, if there is a mechanical delay between the transmission of a request from the repository controller 100 to the resource provider 102 and the subsequent status update to a given repository, the direct allocation occurs within a time window that is shorter than the mechanical delay.

[0073] In a preferred embodiment of the invention, the controlling repository 506 is not a member of multiple repositories 500. That is, state updates for the controlling repository 506 are not calculated based on the same update rules used to calculate state updates for "normal" computerized resource repositories such as repository 502 and affected repository 504. In some embodiments, the repository controller 100 is configured to determine whether the amount of resources in the controlling repository 506 at a given instance is outside a threshold range, and if so, update its state to bring this amount within the threshold range. For example, the controlling repository 506 can be accompanied by a predefined "lower limit" or a predefined "upper limit", or preferably both a predefined lower limit and a predefined upper limit.

[0074] Updating the state of the controlling repository 506 to bring the amount within a threshold range preferably involves acquiring or relinquishing an appropriate amount of resources using an external source, such as the resource provider 102. Bringing the amount within a threshold range may include acquiring / relinquishing an amount of resources to bring the amount to a particular predefined value within the threshold range, such as the midpoint of the threshold range. As a non-limiting example, with reference to FIG. 5B, the controlling repository 506 may have a lower limit of 500 units of resources and an upper limit of 1,500 units of resources, and upon determining that either of these limits have been exceeded, the repository controller 100 may be configured to acquire or relinquish (or attempt to acquire / relinquish) a sufficient amount of resources from the resource provider 102 to bring the amount of resources in the controlling repository 506 back to 1,000 units. In some embodiments, the state of the controlling repository 506 is updated solely pursuant to a determination that the amount of the controlling repository 506 is outside the threshold range.

[0075] Those skilled in the art will recognize that the use of such threshold ranges is not an essential feature of the present invention, and that there may be embodiments in which the only state change in the controlling repository 506 is the allocation of resources to and / or from members of multiple repositories 500 (such as repository 504) to correct inconsistencies caused by erroneous prior input data.

[0076] In a preferred embodiment of the present invention, the state of the controlling repository 506 may include or otherwise relate to negative, i.e., less than zero, amounts of resources. For example, if the resources are non-physical and / or are stored as logical representations, the controlling repository 506 may exist as a virtual repository that may contain or represent resource shortfalls that can be filled later using the resource providers 102.

[0077] The one or more controlling repositories 506 may be physically, logically and / or virtually stored in the repository controller 100, for example in the memory 204 as described above. Additionally and / or alternatively, the one or more controlling repositories 506 may be stored in another system communicatively coupled to and accessible by the repository controller 100. The one or more controlling repositories 506 are preferably stored in a configuration that allows for quick access by the repository controller 100 to facilitate rapid transfer of amounts of resources between the multiple repositories 500. In embodiments using multiple controlling repositories 506, some of the controlling repositories 506 may be stored in the repository controller 100 and other controlling repositories 506 may be stored in another system communicatively coupled to and accessible by the repository controller 100.

[0078] In some embodiments, the repository controller receives data model inputs from multiple input providers 104, 106, ..., each provided by a different input provider from the multiple input providers. As an illustrative and non-limiting example, the processing stage t of the example of Figures 3A-3C n The input in (originally the second input 354 or an instance of “b” and modified to the first input 352 or an instance of “a”) may have been received from the input provider 104 and may be processed in a subsequent processing step t n+1 The input in (the third input 356 or an instance of “c”) may be received from a further input source 106 .

[0079] Additionally, each controlling resource repository used by the repository controller 100 may be associated with a different input provider, and the repository controller 100 may be configured to select which controlling repository should be used to allocate an amount of resources to correct the discrepancy based on which input provider provided the erroneous input. Continuing with the above example with reference to the figure, the repository controller 100 may select whether the repository 506 is (t n Based on a determination that the input provider 106 that provided the erroneous input in is associated with the input provider 104 that was not the source of the error, the controlling repository 506 may be selected to allocate 55 units of resources rather than using the controlling repository (not shown) of the input provider 106 that was not the source of the error. In this sense, the discrepancy caused by the erroneous input is "owned" by the provider of the erroneous input.

[0080] 6, a computer-implemented method for controlling multiple computerized resource repositories in resource allocation system 10 is shown in accordance with an embodiment of the present invention.

[0081] At step 604, a data model, historical data, current quantity data, and error data are received. The data model includes rules for updating a state of each computerized resource repository of the multiple resource repositories based on one or more inputs. The state of each computerized resource repository includes a quantity of resources in each of these computerized resource repositories. The historical data includes a plurality of past inputs into the data model. The current quantity data includes data indicative of a current quantity of resources in a first computerized resource repository of the multiple computerized resource repositories. The error data indicates an error in one of the previous inputs of the historical data.

[0082] Optionally, the historical data may also include further historical data. For example, the historical data may include data indicative of previous states of the first computerized resource repository. Additionally or alternatively, the historical data may include data indicative of the amount of resources associated with each of these previous states. The previous states may include some or all of the sequence of states that the first computerized resource repository has been through from the processing stage in which the error occurred to the "current" state (i.e. the state at the time the method became executed on the computing device). In some embodiments, the historical data includes a state of the first computerized resource repository immediately prior to the erroneous input.

[0083] At step 606, a goal state of the first computerized resource repository is calculated based on the data model, the historical data, and the error data. The goal state may correspond to a current state of the first computerized resource repository that would be assumed according to the data model and the historical data if the error had not occurred.

[0084] In step 608, a difference is determined between the current amount of the resource in the first computerized resource repository and the amount of the resource in the target state of the first computerized resource repository.

[0085] In step 610, an amount of resources equal to the determined difference is allocated from the controlling computerized resource repository to the first computerized resource repository, or vice versa, to correct the difference.

[0086] The term "comprising" encompasses not only "including" but also "consisting of." X can consist of only X or can include something more, such as X+Y.

[0087] Unless otherwise indicated, each embodiment described herein can be combined with any other embodiment described herein.

[0088] The methods described herein may be performed by software in machine-readable form on a tangible storage medium, such as in the form of a computer program including computer program code means adapted to perform all steps of any of the methods described herein when executed on a computer, and the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, hard drives, thumb drives, memory cards, and the like, but do not include propagated signals. The software is suitable for execution on a parallel or serial processor such that the method steps may be performed in any suitable order or simultaneously. This acknowledges that firmware and software may be valuable separately tradable products. Software is intended to include software that operates on or controls "dumb" or standard hardware to perform a desired function. Software is also intended to include software such as HDL (Hardware Description Language) software that "describes" or defines the configuration of hardware, such as used in designing silicon chips or configuring general purpose programmable chips, to perform a desired function.

[0089] Those skilled in the art will appreciate that storage devices used to store program instructions can be distributed across a network. For example, a remote computer can store an example of a process written as software. A local or terminal computer can access a remote computer to download some or all of the software to execute the program. Alternatively, a local computer can download software as needed, or execute some software instructions at a local terminal and some software instructions at a remote computer (or computer network). Those skilled in the art will appreciate that all or some of the software instructions can also be executed by dedicated circuitry such as a DSP (digital signal processor) or programmable logic array, using conventional techniques known to those skilled in the art.

[0090] It will be understood that the benefits and advantages described above may relate to a single embodiment or to multiple embodiments, and the embodiments are not limited to those that solve some or all of the stated problems or have some or all of the stated benefits and advantages.

[0091] The steps of the methods described herein may be performed in any suitable order, or simultaneously where appropriate. Also, individual steps may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the embodiments described above may be combined with aspects of any other of the embodiments described above to form further embodiments without losing the intended effect. Any of the steps or processes described above may be implemented in hardware or software.

[0092] It will be understood that the above description of the preferred embodiment is given by way of example only, and that various modifications are possible and can be made by those skilled in the art within the scope of the appended claims. Although various embodiments have been described above with particular detail or with reference to one or more specific embodiments, those skilled in the art may make numerous modifications to the disclosed embodiments without departing from the scope of the present invention.

[0093] The terms "error", "error data", "input error", "incorrect input / data / input data" as described above in this specification can take various forms and include indications of any one (or more) of various types of errors. Different types of errors can be associated with different types of corrections. In some cases, an error in a given input can be the inclusion of an erroneous value in the input. For example, the input can include an erroneous numerical value that differs from the "correct" or "intended" value that would have been received from the input source 104 in the absence of the error. Illustrative and non-limiting examples of such values ​​can be computer resource values ​​(such as CPU utilization and / or clock speed, number of processes, number of threads, number of handles, number of sockets and / or cores, cache size, RAM usage, pages, hard disk activity, and network send / receive rates). Further illustrative and non-limiting examples of such values ​​can be sensor measurements (such as voltage, current, resistance, conductance, impedance, light (or brightness), temperature, sound, motion (such as translation or rotation), force, etc.). Further illustrative and non-limiting examples of such values ​​can be received values ​​of an electronic network (such as cryptographic data, electronic market data including electronic certificate price data (stocks / shares / fund units / commodity / asset / bonds / derivatives data), public / private / symmetric key values, cryptographic nonce values, key exchange values ​​(e.g., Diffie-Helman key exchange values), hash values, digital signatures, and values ​​received from an API or RESTful service). Further illustrative and non-limiting examples of such values ​​can be peripheral input values ​​(such as user input via a mouse, keyboard, touch screen, trackpad or trackball, joystick, microphone, camera, etc.).

[0094] In such cases, correcting the error may include a correction value. The correction value may be a value that was intended to be included in, as, or with the input data instead of the erroneous value. In such cases, calculating the target state according to the data model includes determining, according to the data model, the state that the repository would currently be in if the erroneous input data had included the correct value instead of the erroneous value. Calculating the state to which the initial state (immediately before the error) would have progressed may include determining, according to the data model, the state to which the initial state would have progressed if the erroneous input data had included the correct value instead of the erroneous value.

[0095] In other cases, the fact that the input was received at all may have been an error. For example, the input may have been accidentally or erroneously provided by the input source 104. The input may have been provided unintentionally. The input may have been provided based on (and / or in response to) other erroneous data, in which case the input would not have been provided by the input source 104 if the correct "other" data had been provided to the data source 104. Such input may include, for example, commands to perform actions related to the computerized resource repository (e.g., updating the status of, transferring, acquiring, and / or relinquishing resources from one or more repositories). The input source 104 may include hardware or software configured to detect when an input has been provided in error (i.e., should not have been provided) and / or may include an interface for a user to manually identify that the input was provided in error.

[0096] In such cases, correcting the error need not include any "corrected value"; it is sufficient to identify which input was the erroneous input (e.g., based on a timestamp, a unique numeric identifier, or other suitable means). In such cases, calculating the target state according to the data model may include determining the state that the repository would currently be in if the input had never been received (or at least had not been received) according to the data model. Calculating the state that the initial state (immediately before the error) would have progressed to may include determining the state that the initial state would have progressed to if the input had never been received (or at least had not been received) according to the data model.

[0097] In some cases, the error in the previous input may be that no input was received from the input source 104, i.e., the error may be that the data or content was not present at a past time when the data or content should have appeared or was expected. For example, it may be that one of the previous inputs of the historical data was an "empty" or "null" input (e.g., indicating the absence of any data, value, command or instruction for the repository controller 100), but the input source 104 should have provided a "true" input (e.g., including any data, value, command or instruction) to the repository controller to trigger any state update according to the data model. The "empty" or "null" input may have no effect on the data model. The data model and / or the rules of the data model may be configured to make no changes to the state of any computerized resource repository in response to an "empty" or "null" input. The data model and / or its rules may ignore or simply not parse such input.

[0098] In such cases, correcting the error may include indicating an input that should have been received (but was not received). In such cases, calculating the goal state according to the data model may include determining the state that the repository would currently be in if the input had been received according to the data model. Calculating the state that the initial state (immediately before the error) would have progressed to may include determining the state that the initial state would have progressed to if the input had been received according to the data model.

[0099] The above examples of types of input data errors and corresponding corrections are not intended to constitute an exhaustive list, but rather to serve as examples only. [Explanation of symbols]

[0100] 600 ways 602 start 604 Receive data model, historical data, current amount of resources and error data 606 Calculate the target state of one or more repositories 608 Determine the difference in the amount of one or more resources 610 Allocate resources between the control repository for modifications 612 End

Claims

1. A computer-implemented method for controlling a plurality of computerized resource repositories within a resource allocation system, comprising: a data model of resources including rules for updating the state of each of the plurality of computerized resource repositories based on one or more inputs, the state including the amount of resources within each computerized resource repository; historical data including a plurality of previous inputs to the data model; data indicating the current amount of resources in a first computerized resource repository among the plurality of computerized resource repositories; error data indicating an error in one of the previous inputs of the historical data; receiving; calculating a target state of the first computerized resource repository based on the data model, the historical data, and the error data; determining a difference between the current amount of resources in the first computerized resource repository and the amount of resources in the target state of the first computerized resource repository; allocating an amount of resources equal to the determined difference from a control computerized resource repository to the first computerized resource repository or vice versa to correct the difference; A computer-implemented method characterized by comprising the above.

2. receiving one or more data model inputs; updating the state of one or more of the plurality of computerized resource repositories based on the data model and the one or more received data model inputs; The computer-implemented method according to claim 1, further comprising the above.

3. determining whether the current amount of resources in the control computerized resource repository is outside a threshold range; updating the state of the control computerized resource repository according to the determination to bring the amount within the threshold range; The computer-implemented method according to claim 1, further comprising the above.

4. Updating the state of the computerized resource repository includes increasing or decreasing the amount of resources in the computerized resource repository. The computer-implemented method according to claim 2.

5. Increasing or decreasing the amount of resources in the computerized resource repository includes updating by increasing or decreasing the amount of resources from an external source of the computer implementing the same. The computer implementation method according to claim 4.

6. The increase or decrease is related to a first mechanical delay. The computer implementation method according to claim 5.

7. The first mechanical delay is caused by a delay generated from the external source. The computer implementation method according to claim 6.

8. Allocating an amount of resources equal to the determined difference is related to a second mechanical delay, and the second mechanical delay is shorter than the first mechanical delay. The computer implementation method according to claim 6.

9. The first mechanical delay is within the range of 1 hour to 72 hours, or within the range of 12 hours to 48 hours, and the second mechanical delay is less than 12 hours, less than 1 hour, less than 1 minute, less than 1 second, less than 10 milliseconds, or less than 0.1 millisecond. The computer implementation method according to claim 8.

10. Allocating an amount of resources equal to the determined difference is performed instantaneously. The computer implementation method according to claim 1.

11. The target state of the first computerized resource repository corresponds to the current state of the first computerized resource repository assumed according to the data model and the history data when it is assumed that the error has not occurred. The computer implementation method according to claim 1.

12. Receiving data indicating the current amount of resources in a second computerized resource repository among the plurality of computerized resource repositories; Calculating a target state of the second computerized resource repository based on the data model, the history data, and the error data; Determining a difference between the current amount of resources in the second computerized resource repository and the amount of resources in the target state of the second computerized resource repository; Allocating an amount of resources equal to the determined difference from the control computerized resource repository to the second computerized resource repository or vice versa to correct the difference; The computer implementation method according to claim 1, further comprising.

13. Each data model input is received from one of a plurality of input providers, The control computerized resource repository is one of a plurality of control computerized resource repositories, and each control computerized resource repository is associated with an input provider, The control computerized resource repository selected to correct the difference is associated with the input provider that is the cause of the error, The computer-implemented method according to claim 1.

14. An apparatus including a memory containing instructions and a processor, the instructions being configured to cause the processor to execute the method according to any one of claims 1 to 13 when executed by the processor, An apparatus characterized by this.

15. A computer program including computer-readable instructions, the computer-readable instructions being configured to cause a processor to execute the method according to any one of claims 1 to 13 when executed by the processor, A computer program characterized by this.

Images