Data pick-up control

Abstract

A request-based variable is generated using data associated with the received request as input to a request-based variable generation model. In response to determining that the request-based variable can be altered using additional data as additional input to the model, it is determined whether to retrieve the additional data based on a comparison involving a data retrieve loss indicator and a data non-retrieve loss indicator. A decision associated with the request is made based on a deterministic request-based variable. When the comparison indicates that the data check loss exceeds the data non-check loss, the determination is that the further data is not to be checked, and the request-based variable is used as the deterministic request-based variable. When the comparison indicates that the data non-fetch loss exceeds the data fetch loss, a regenerated request-based variable is used as the deterministic request-based variable.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to data retrieval control.

[0002] In particular, but not exclusively, the present disclosure relates to measures (e.g. methods, systems, servers and computer programs) to perform data retrieval control. BACKGROUND

[0003] There are various measures in the art for controlling data retrieval.

[0004] For example, a firewall can control incoming requests for data based on preconfigured security rules. The firewall can help protect computing resources (e.g. servers and / or data stores) behind the firewall from denial of service (DoS) and distributed denial of service (DDoS) attacks as well as other types of malicious activity. DoS attacks are also known as flood attacks.

[0005] Artificial intelligence (AI) can be used to compute a variable associated with an incoming request. Accordingly, this variable will generally be referred to herein as a “request-based variable”. An example of a request-based variable is a risk score associated with a request. The request-based variable can in turn be used to automate decisions such as whether an incoming request should be accepted or rejected. The accuracy of such automated decisions generally increases with the amount of data used by the AI. SUMMARY

[0006] According to a first aspect, there is provided a data retrieval control method, the method comprising: receiving a request; generating a request-based variable using data associated with the request, wherein the data is input to a request-based variable generation model to generate the request-based variable; determining whether to retrieve further data based on a comparison involving a data retrieval loss indicator and a data non-retrieval loss indicator, the data retrieval loss indicator indicating a loss associated with retrieving the further data, and the data non-retrieval loss indicator indicating a loss associated with not retrieving the further data, in response to determining that the request-based variable can be altered using the further data as further input to the request-based variable generation model; and formulating a decision associated with the request based on the deterministic request-based variable, wherein when the comparison indicates that the data retrieval loss exceeds the data non-retrieval loss: the determination is not to retrieve the further data; and the request-based variable is used as the deterministic request-based variable, and wherein, when the comparison indicates that the data non-retrieval loss exceeds the data retrieval loss: the determination is to retrieve the further data; retrieving the further data; re-generating the request-based variable using the request data and the further data as input to the request-based variable generation model to generate a re-generated request-based variable; and the re-generated request-based variable is used as the deterministic request-based variable.

[0007] According to a second aspect, there is provided a decision server comprising: a request processor; a request-based variable generator; a request-based variable generation model; a decision component; a comparator; and a data retrieval controller, wherein the decision server is configured to perform the method according to the first aspect of the disclosure.

[0008] According to a third aspect, there is provided a system, server and / or computer program configured to perform the method according to the first aspect of the disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0009] Certain embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings, in which:

[0010] Figure 1 is a schematic diagram illustrating an example of a data retrieval control system.

[0011] Figure 2 is a schematic diagram illustrating a request-based variable with and without data retrieval control. Figure 1 is a schematic diagram illustrating part of the system shown.

[0012] Figure 3A and 3B are flow diagrams illustrating examples of a data retrieval control method.

[0013] Figure 4 is an example plot of request score versus density, and illustrates a first example request score zone.

[0014] Figure 5 is another example plot of request score versus density, and illustrates a second example request score zone.

[0015] Figure 6 is another example plot of request score versus density, and illustrates a third example request score zone.

[0016] Figure 7 is a schematic diagram illustrating an example of a data retrieval control program.

[0017] Figure 8 is a schematic block diagram illustrating an example of a decision server.

[0018] Figure 9 is a process flow diagram illustrating an example of a data retrieval control method.

[0019] Figure 10 is a schematic diagram illustrating another example of a data retrieval control system. DETAILED DESCRIPTION

[0020] Without loss of generality, the present disclosure relates to data retrieval control and optimized data retrieval.

[0021] The term“data retrieval” is used herein to mean the retrieval of any type of data using any mechanism, and is not limited to data recovery, i.e., the recovery of data that can have been lost, corrupted, etc.

[0022] As explained above, existing AI-based decision automation systems are based on the premise that more data is better, as this improves accuracy. This is generally the case.

[0023] However, using more data is not a decision that is made in isolation. For example, using additional data creates several trade-offs.

[0024] One example trade-off is data privacy. Using additional data can increase the likelihood of raising risks with respect to personal privacy, i.e., the privacy of an individual’s data. Using additional data can also present additional requirements to comply with local privacy regulations.

[0025] Another example trade-off is data security. If the security of the decision system and / or associated network is compromised, transmitting and / or storing unnecessary data increases exposure.

[0026] Another example trade-off is resilience. Capturing or requesting additional data increases the complexity of the decision-making process. This increases the surface error of faults in the process of obtaining the data and / or errors within the data. This can lead to faults and / or inaccuracies when generating (e.g., computing) variables based on the request. The lower the computational complexity, the more resilient the system can be.

[0027] Another example tradeoff is latency. Retrieving data from a third party or local system is not instantaneous. This is especially true when the data originates outside of the local network. As a result, this has an impact on the amount of time it takes to generate a request-based variable (e.g., a risk score) and communicate the decision to one or more entities (e.g., the requesting system). This is particularly relevant in time-critical, low-latency systems.

[0028] Another example tradeoff is downstream computing resource impact. For example, where additional data is required for additional processing by a downstream system, retrieving the additional data can increase the computing resource requirements for the downstream system. While such additional processing can be tolerable or even beneficial in some scenarios, it can be undesirable in other situations. For example, if the downstream system is operating at near capacity levels, an additional processing request can cause instability or even failure of the downstream system.

[0029] Also, without loss of generality, the examples described herein optimize, for example, these tradeoffs on a request-by-request basis while maintaining accuracy.

[0030] Making such decisions on a request-by-request basis enables highly-tailored optimization. In contrast, existing systems that acquire data to make automated decisions are managed as optimizations for a population of requests as a whole, rather than for individual requests.

[0031] As AI is increasingly employed to make automated decisions, losses or potential losses in the process of generating these decisions cannot be ignored.

[0032] Such losses can relate to data privacy, data security, resilience, latency, or other factors.

[0033] Such losses can relate to the consequences of inaccurate decisions. For example, the consequences of rejecting a legitimate request can be more significant for a premium user or subscriber than for a non-premium user or subscriber.

[0034] Such losses can depend on attributes of the request. For example, where priority is an attribute of the request, it can be more important to make an accurate decision for a high-priority request than for a low-priority request (in other words, the loss can be more significant). Another example attribute of a request is the type of requesting user device. For example, the loss can vary depending on whether the requesting user device is a desktop computing device or a mobile computing device. As another example, the data retrieval loss can depend on the country of origin of the request, which can be indicated by an attribute of the request. Specifically, a given country can have low-quality data for a preferred provider, meaning that secondary providers need to be accessed to obtain higher-quality data. This incurs a loss in terms of, for example, latency. As another example, certain brands of user devices can provide limited tracking data related to their users. Thus, verifying user activity on such user devices can be more complex than on user devices of another brand.

[0035] Examples described herein can maintain accuracy while being more precise in the inputs used to reach decisions, and thus mitigating losses and / or risks associated with a range of data practices.

[0036] Examples described herein are compatible with a large number of requests, e.g., thousands of requests per second. The number of requests can also vary over time, e.g., unexpectedly.

[0037] As will be explained in more detail below, in examples, a decision server can make a series of calculations and comparisons to determine whether to accept (or "authorize" or "permit") a request or to reject (or "deny" or "reject") a request. The decision server can select which, if any, data to retrieve and / or which data stores to access to obtain the inputs needed to maintain the accuracy of the decision, while optimizing tradeoffs such as data privacy, data security, resilience, and latency. Such data stores can be internal and / or external, as will be described in more detail below.

[0038] Reference is made to Figure 1 , which shows an example system 100. System 100 implements data retrieval control, and can accordingly be referred to as a data retrieval control system.

[0039] System 100 includes a first user device 102 and a second user device 104. The term "user device" is used herein to mean any device that can be used by a user of system 100. User devices can take various forms. Example forms include, but are not limited to, desktop computers, laptop computers, tablet computing devices, and smartphones.

[0040] Although system 100 includes two user devices 102, 104 in this particular example, other example systems can include different numbers of user devices.

[0041] In particular, in some examples, the system 100 does not include a user device or includes one user device. Other elements of the system 100 can be modified or omitted accordingly. For example, the system 100 can have a service-to-service type architecture and can not include any user devices. Examples of such architectures include, but are not limited to, application programming interface (API) based architectures and file sharing architectures.

[0042] In this example, the first user device 102 is an initiator user device and is associated with an initiator entity (not shown). The initiator user device can belong to the initiator entity or can simply be used by the initiator entity. The initiator entity initiates requests in the system 100.

[0043] In this example, the second user device 104 is a destination user device and is associated with a destination entity (not shown). The destination entity is the intended destination of a request and / or things associated with a request. As will be explained in greater detail below, a request intended for the destination entity can not actually reach the destination entity.

[0044] The initiator entity and / or the destination entity can take a variety of different forms. Example forms include, but are not limited to, legal persons and natural persons. A natural person can be a user of the system 100.

[0045] The initiator user device 102 is communicatively coupled to the first network 106 via a first communication coupling 108.

[0046] The term "network" is used herein to mean a computer network, i.e., a group of computers that share resources.

[0047] The term "communicatively coupled" is used herein to mean any type of coupling that enables communication between entities. The coupling can be wired and / or wireless. The coupling can be direct or indirect.

[0048] The destination user device 104 is communicatively coupled to the second network 110 via a second communication coupling 112.

[0049] The first server 114 (which is an initiator server in this example) is communicatively coupled to the first network 106 via a third communication coupling 116.

[0050] The term "server" is used herein to mean a computing entity that provides a service to another computing entity. A server can be implemented in hardware and / or software. A server can include one or more server components. Server components can be co-located or can be geographically dispersed.

[0051] The initiator server 114 processes requests associated with the initiator user device 102. For example, the initiator server 114 can process requests to and / or from the initiator user device 102.

[0052] The second server 118 (in this example, a destination server) is communicatively coupled to the second network 110 via a fourth communication coupling 120.

[0053] The destination server 118 processes requests associated with the destination user device 104. For example, the destination server 118 can process requests to and / or from the destination user device 104.

[0054] Although only a single initiator server 114 and a single destination server 118 are shown in Figure 1 other example systems can provide multiple initiator servers 114 and / or multiple destination servers 118.

[0055] The initiator server 114 is communicatively coupled to a third network 122 via a fifth communication coupling 124.

[0056] The destination server 118 is communicatively coupled to a fourth network 126 via a sixth communication coupling 128.

[0057] The decision server 130 is communicatively coupled to the third network 122 via a seventh communication coupling 132. The decision server 130 is also communicatively coupled to the fourth network 126 via an eighth communication coupling 134.

[0058] The decision server 130 formulates decisions associated with requests transmitted in the system 100.

[0059] Such a request can require the decision server 130 to formulate a decision associated with another request. For example, an initial request can be received by an entity in the system 100, and the entity can send a decision request to the decision server 130 based on the initial request.

[0060] Accordingly, references to an "initiator entity" should be understood to refer to an entity that initiates a particular request in the system 100, and this request can be based on a request originating from another entity.

[0061] Although only a single decision server 130 is shown in Figure 1 other example systems can provide multiple decision servers 130.

[0062] The decision server 130 is communicatively coupled to a fifth network 136 via a ninth communication coupling 138.

[0063] Data storage area 140 is communicatively coupled to fifth network 136 via tenth communication coupling 142.

[0064] The term "data storage area" is used herein to refer to any entity that can store data. Data storage areas can include volatile and / or non-volatile memory. This includes, but is not limited to, random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), magnetic storage devices, solid-state storage devices, and flash memory. Combinations of one or more of these may also be used for data storage when technically appropriate (e.g., using faster-access volatile memory for frequently accessed data).

[0065] Data storage areas can store data in various ways, such as storing data in one or more databases. A data storage area may include one or more data storage area components. Data storage area components may be located collaboratively or may be geographically distributed.

[0066] Data storage area 140 stores data. The data may include signals (which may also be referred to as "signal data").

[0067] Despite Figure 1 Only a single data storage area 140 is shown in the example, but multiple data storage areas 140 may be provided in other examples. Some or all of the data storage areas 140 may be of the same type. Some or all of the data storage areas 140 may be of different types.

[0068] In some examples, for example Figure 1 As shown, data storage area 140 is external to decision server 130. However, in other examples, data storage area 140 is internal (or "local") to decision server 130. In systems comprising multiple data storage areas 140, data storage areas 140 may include a mixture of internal and external data storage areas. For example, retrieving data from multiple data storage areas 140 may increase risks to data privacy, data security, resilience, and latency. The resources involved in retrieving data from external data storage areas 140 may be greater than the resources involved in retrieving data from internal data storage areas 140.

[0069] Networks 106, 110, 122, 126, and 136 from the first to the fifth can take various different forms. Some or all of networks 106, 110, 122, 126, and 136 from the first to the fifth can take the same form as each other. Some or all of networks 106, 110, 122, 126, and 136 from the first to the fifth can take different forms from each other.

[0070] In some examples, one or more of the first through fifth networks 106, 110, 122, 126, 136 comprise a public network. An example of such a public network is the Internet.

[0071] In some examples, one or more of the first through fifth networks 106, 110, 122, 126, 136 comprise a private network. An example of such a private network is a local area network (LAN).

[0072] Although in the example system 100, networks and multiple communication couplings are provided between various system entities (the user devices 102, 104, the servers 114, 118, 130, and the data store 140), in other examples, some or all of the networks can be replaced by direct couplings.

[0073] The first through tenth communication couplings 108, 112, 124, 128, 132, 134, 138, 142 can take a variety of different forms. Some or all of the first through tenth communication couplings 108, 112, 124, 128, 132, 134, 138, 142 can take the same form as one another. Some or all of the first through tenth communication couplings 108, 112, 124, 128, 132, 134, 138, 142 can take different forms from one another.

[0074] In some examples, one or more of the first through tenth communication couplings 108, 112, 124, 128, 132, 134, 138, 142 comprise a wireless coupling. An example of such a wireless coupling is a Wi-Fi TM coupling.

[0075] In some examples, one or more of the first through tenth communication couplings 108, 112, 124, 128, 132, 134, 138, 142 comprise a wired coupling. An example of such a wired coupling is an Ethernet cable.

[0076] In a particular example, the system 100 can be used to formulate decisions related to telephone requests. For example, the initiator user device 102 can transmit a telephone call setup request to the initiator server 114. The initiator server 114 can then forward the telephone call setup request to the decision server 130. The decision server 130 can determine that the telephone call setup request is legitimate, and accordingly forward the telephone call setup request to the destination user device 104 via the destination server 118. Alternatively, the decision server 130 can determine that the telephone call setup request is not legitimate, and can accordingly reject the telephone call setup request.

[0077] Reference is made to Figure 2 , which shows the above-referenced Figure 1Part 200 of the described example system 100.

[0078] Figure 2 The width of the representation of the tenth communicative coupling 142 in schematically illustrates how the amount of data communicated between the decision server 130 and the data store 140 varies with and without the data retrieval control measures described herein.

[0079] As Figure 2 the width of the representation of the tenth communicative coupling 142 in Figure 2 schematically illustrates that the amount of data communicated between the decision server 130 and the data store 140 is greater without the data retrieval control measures (to the left of the dashed line 202 in Figure 2 schematically illustrates that the amount of data communicated between the decision server 130 and the data store 140 is greater with the data retrieval control measures (to the right of the dashed line 202 in

[0080] As such, the data retrieval control measures described herein can control (i.e., reduce) the amount of data communicated between the decision server 130 and the data store 140.

[0081] Referring to Figure 3A and 3B , an example data retrieval control method 300 is shown.

[0082] In this example, the data retrieval control method 300 is performed by the decision server 130. However, in other examples, one or more of the actions shown in Figure 3A and 3B may be performed at one or more other entities.

[0083] At item 302, the decision server 130 receives a request. The request can be received in a variety of different ways. For example, the request can be received through a communicative coupling such as the fifth communicative coupling 132 described above.

[0084] The decision server 130 can have received the request via the initiator server 114 or otherwise from the initiator user device 102. In particular, the initiator server 114 can have transmitted the request to the decision server 130 to be subject to a request-related decision.

[0085] A variety of different types of request triggers can have caused the decision server 130 to receive the request. For example, a user interaction with the initiator user device 102 can have triggered the request. Alternatively, an automated process on the initiator user device 102 can have triggered the request, for example, if the initiator user device 102 is compromised and being used as part of an attack or other non-legitimate (or “malicious”) activity.

[0086] At item 304, the decision server 130 generates a request-based variable associated with the request. The request-based variable can be referred to as a "primary" request-based variable.

[0087] The term "variable" is used herein to mean anything that can change. A variable can include, for example, a value, a number, a quantity, or other. As used herein, a variable can include one or more variable components, i.e., components of the variable. For example, a variable may include variable components .

[0088] The term "request-based variable" is used herein to mean a variable that is generated using data associated with a request. This generation can include deriving, calculating, looking up, or other. The data associated with the request can include data included in the request and / or other data that is not included in the request but is otherwise associated with the request.

[0089] Examples of request-based variables include, but are not limited to, scores, instructions, predictions, and confidence levels. For example, a request-based variable can include a score component and a confidence level component. The confidence level component can indicate a confidence level in the score component.

[0090] The term "score" is used herein in a general sense to mean an evaluation measure.

[0091] The term "request score" is used herein to mean a score that is generated using data associated with a request.

[0092] Generating a request-based variable includes using data associated with a request as input to a request-based variable generation model (i.e., a model that generates a request-based variable).

[0093] The term "model" is used herein generally to encompass both machine learning (ML) models and rule-based models. A request-based variable generation model can map one or more inputs to one or more outputs, where the one or more outputs include a request-based variable.

[0094] The data associated with the request can include request data included in the request and / or other data that is not included in the request but is otherwise associated with the request. In particular, a request-based variable can be generated without using any request data included in the request. For example, a request-based variable can be generated based on a time of receipt of the request, a communication channel on which the request is received (e.g., where the decision server 130 can receive requests via multiple communication channels), and / or the like. The time of receipt of the request and the communication channel on which the request is received can be stored in data that is not included in the request but is otherwise associated with the request.

[0095] For convenience and brevity, in the specific examples described below, the request-based variable includes a request score. However, as explained above, in other examples, the request-based variable can include one or more additional request-based variable components and / or one or more alternative request-based variable components. As such, unless the context otherwise requires, examples herein with respect to request scores should be understood to apply to other types of request-based variables. For example, references below to a "request score generation model" should be understood to encompass another type of request-based variable generation model, e.g., where a request-based variable other than a request score is being generated.

[0096] The request score can include a numerical value. In the case where the request score includes a numerical value, the request score can be in the range of 0 to 1. However, in other examples, the request score can be in a different range of numerical values.

[0097] A low request score in a relevant numerical range (e.g., a score of 0.1 in the range of 0 to 1) can correspond to a low level of risk and a high level of legitimacy. A high request score in a relevant numerical range (e.g., a score of 0.9 in the range of 0 to 1) can correspond to a high level of risk and a low level of legitimacy.

[0098] However, in other examples, the request score can take another form. For example, the request score can include a letter from a predetermined set of letters, e.g., "A," "B," "C," and "D." The request score can include a label from a predetermined set of labels, e.g., "legitimate," "illegitimate," and "undetermined."

[0099] In this example, the decision server 130 generates the request score by computing the request score. However, in other examples, the decision server 130 can generate the request score in another way. For example, the decision server 130 can look up the request score. For example, the decision server 130 can look up the request score in a table based on the request data included in the request without performing a computation. In this regard, unless the context otherwise requires, references herein to computing a request score also apply to other techniques to generate a request score.

[0100] At item 306, the decision server 130 compares the request score to a rejection threshold. The term "rejection threshold" is used herein to mean a threshold to which a request score can be compared and which indicates whether a request should be rejected. If the request score is greater than the rejection threshold, then at item 308, the request is rejected. In this example, the request score being greater than the rejection threshold means that the request is high risk, low legitimacy, and therefore should be rejected.

[0101] If the request score is not greater than the rejection threshold at item 306, then at item 310 the decision server 130 compares the request score to an acceptance threshold. The term "acceptance threshold" is used herein to mean a threshold to which a request score can be compared and which indicates whether a request will be accepted.

[0102] If the request score is less than the acceptance threshold, then at item 312 the request is accepted. In this example, the request score being less than the acceptance threshold means that the request is low risk, high legitimacy, and so should be accepted.

[0103] If the request score is not less than the acceptance threshold at item 310, then at item 314 the decision server 130 determines whether additional data can change the request score.

[0104] The term "additional data" is used herein to mean any data that can be used to generate a request score. For example, the additional data can be used to regenerate a primary request score.

[0105] The term "can" used in the context of determining whether additional data can change the request score indicates that the additional data can result in the request score changing, but the request score does not necessarily change. This is because the request score is only regenerated when the additional data has actually been retrieved.

[0106] The decision server 130 can perform the determination of item 314 in a variety of different ways.

[0107] For example, for a certain type of request, the decision server 130 can identify that legitimate requests from a given originating entity should use a source Internet Protocol (IP) address that has been used in previous requests from the given originating entity. When a request of this type is received, retrieving historical IP address usage information (listing previously used IP addresses for the given originating entity) can therefore influence the request score. However, the historical IP address usage information can be irrelevant for other types of requests, and / or other types of additional data can not influence the request score for all types of requests.

[0108] If the decision server 130 determines that the additional data will be unlikely to change the request score, then at item 316 the request score is used as the definitive request score. The term "definitive request score" is used herein to mean a request score that is used to determine what decision to make in connection with a request (e.g. to accept or reject the request).

[0109] At item 316, the request score is not higher than the rejection threshold (see item 306) and is not lower than the acceptance threshold (see item 310), and thus the request score does not indicate whether the request is (probably) legitimate or non-legitimate. One or more predetermined actions can be taken in such cases. For example, the request can be subject to analyst review.

[0110] If the decision server 130 determines that additional data would likely change the request score, at item 318 the decision server 130 determines whether a data retrieval loss associated with retrieving the additional data would exceed a data non-retrieval loss associated with not retrieving the additional data.

[0111] The term“data retrieval loss” is used herein to mean a loss associated with retrieving (additional) data. The term“data non-retrieval loss” is used herein to mean a loss associated with not retrieving (additional) data.

[0112] The term“loss” is used herein to mean something undesirable, unwanted, or negative, e.g., as opposed to a desirable, wanted, or positive gain.

[0113] The term“exceed” is used herein to mean more significant than. If one number is greater than another number, then the number can be said to exceed the other number. However, in some embodiments, a lower number can indicate that the number represents a greater importance.

[0114] The decision server 130 can perform the determination of item 318 in a variety of different ways.

[0115] For example, a data retrieval loss metric may be defined as where is one of parameters used to derive the data retrieval loss metric .

[0116] Examples of such parameters include, but are not limited to, a data privacy parameter, a data security parameter, a resilience parameter, a latency parameter, an inaccurate decision consequence parameter, a request attribute parameter, an uncertainty parameter, and a request score change parameter.

[0117] Similarly, a data non-retrieval loss metric may be defined as where is one of parameters used to derive the data non-retrieval loss metric one of the parameters. Examples of such parameters include, but are not limited to, a data privacy parameter, a data security parameter, a resilience parameter, a latency parameter, an inaccurate decision consequence parameter, a request attribute parameter, an uncertainty parameter, and a request score change parameter.

[0118] In a particular example, each of the parameters mentioned above and may take a value, for example, in the range of 0 to 1. Thus, the data retrieval loss metric and the data non-retrieval loss metric may be the sum of their respective parameter values.

[0119] The values of the parameters and may be set by an operator of the system and / or can be derived in another manner. For example, the latency value can be observed and / or measured.

[0120] The inaccurate decision consequence parameter can indicate a measure of loss due to incorrectly classifying a request. In effect, this parameter can weight the support for retrieving or not retrieving additional data, for example, based on whether the additional data can increase accuracy and the magnitude of the consequences.

[0121] The request attribute parameter can indicate a measure of loss based on attributes of the request. For example, for certain types of requests, users, initiating user devices, etc., the loss can be more significant. For example, if retrieving certain additional data for one type of request has historically increased the accuracy of the decision for that type of request, then the retrieval can be weighted in favor of retrieving the request attribute parameter. On the other hand, if retrieving the same additional data (and / or other additional data) for another type of request has historically resulted in negligible changes in accuracy, then the non-retrieval can be weighted in favor of not retrieving the request attribute parameter.

[0122] The uncertainty parameter can indicate a measure of uncertainty associated with the generated request score for item 304. For example, an IP address included in the request can have substantially or slightly reduced the confidence in the generated request score (and thus increased the uncertainty). In this case, the uncertainty parameter can be weighted in favor of retrieval, expecting that it can increase the confidence.

[0123] The request score change parameter can indicate a measure of the likelihood that the additional data changes the generated request score. In one particular example, the request score change parameter can indicate a likelihood that the additional data includes IP address history information. In another particular example, the request score change parameter can indicate an accuracy of the additional data. For example, data from certain countries can have a relatively low accuracy. The request score change parameter can be derived as a result of item 314 or otherwise.

[0124] The data retrieval loss metric and the data non-retrieval loss metric can then be compared to each other to determine whether the data retrieval loss will exceed the data non-retrieval loss.

[0125] As a particular numerical example, the (potential) data privacy loss in the process of not retrieving the additional data can be high, e.g., 0.8 (on a scale of 0 to 1). For example, if a non-legitimate login request is incorrectly classified as a legitimate login request, a malicious actor can be able to access account data.

[0126] However, the (potential) data privacy loss in the process of retrieving the additional data can be low, e.g., 0.2 (on a scale of 0 to 1). For example, the data retrieval can be subject to authentication, encryption, and / or other data security measures such that the transmitted data is highly secure.

[0127] However, the (potential) latency loss in the process of retrieving the additional data can be very high, e.g., 0.9 (on a scale of 0 to 1), and the (potential) latency loss in the process of not retrieving the additional data can be zero, e.g., 0 (on a scale of 0 to 1). The latency loss in the process of retrieving the additional data can be high for various reasons. For example, there can be a large amount of additional data to retrieve, the additional data retrieval connection can have a low bandwidth, the additional data can be stored across multiple data stores, etc.

[0128] The data retrieval loss metric can be computed as and the data non-retrieval loss metric can be computed as .

[0129] As a result of , it can be determined that the data retrieval loss will exceed the data non-retrieval loss, but there can be a significant data privacy loss in the process of not retrieving the additional data.

[0130] The above-mentioned parameters can be weighted and / or different parameter ranges can be used for different parameters. For example, the data retrieval loss metric can be defined as where is a parameter weight. The parameter weight may be, for example, a numerical value in the range of 0 to 1. The data non-retrieval loss metric may be defined accordingly.

[0131] Different weights can be used in different scenarios. For example, in some scenarios such as voice communication applications, latency can be re-weighted. In some scenarios involving personal data of individuals, data privacy can be re-weighted.

[0132] In the above particular numerical example, the same parameter is used for both the retrieval loss metric and the data non-retrieval loss metric . However, different parameters can be used in other examples.

[0133] For example, the data non-retrieval loss metric may be based on a downstream server operation load parameter. The downstream server operation parameter can indicate an operation load of the downstream server.

[0134] In the above particular numerical example, multiple parameters are used for both the retrieval loss metric and the data non-retrieval loss metric . However, in other examples, one or both can use a single parameter.

[0135] In addition, in this particular example, the retrieval loss metric and the data non-retrieval loss metric are computed based on respective parameters and .

[0136] In other examples, one of the retrieval loss metric and the data non-retrieval loss metric is a predetermined threshold. For example, in the above particular numerical example, the data retrieval loss metric may be defined as and the data non-retrieval loss metric may be a predetermined threshold, such as 0.7. In such other examples, the data retrieval loss metric may still be computed as 1.1, but will be compared against the threshold 0.7 instead of the computed value 0.8. The predetermined threshold can be static or can be dynamic. In this particular example, the data non-retrieval loss metric Still indicates a loss associated with not retrieving further data, but is a predetermined threshold. In particular, the predetermined threshold indicates a value at which the loss associated with not retrieving further data matches the loss associated with retrieving further data.

[0137] In other examples, the retrieval loss indicator and the data non-retrieval loss indicator are both compared to one or more predetermined thresholds. In addition to the one or more predetermined thresholds, this comparison also involves comparing the retrieval loss indicator and the data non-retrieval loss indicator .

[0138] In another example, the data retrieval loss indicator may be defined as the data non-retrieval loss indicator may be defined as and may be compared to in a similar manner to that described above.

[0139] Although in the examples described above, the retrieval loss indicator and the data non-retrieval loss indicator are numerical values, in other examples they can take different forms. For example, they can be“high”,“medium” and“low”. The rating rules can be configured such that“high” exceeds“medium” and“low”, and“medium” exceeds“low”.

[0140] If the decision server 130 determines that the data retrieval loss will exceed the data non-retrieval loss, the method proceeds to item 316, at which the request score is used as the deterministic request score.

[0141] If the decision server 130 determines that the data retrieval loss will not exceed the data non-retrieval loss, at item 320 the decision server 130 retrieves further data.

[0142] In a particular example, the decision server 130 can identify that the initiator entity is using a different initiator user device to that which it normally uses. For example, the initiator entity can be using a user device of a family member. Accordingly, the decision server 130 can perform a device check. For example, this can involve sending a one-time password (OTP) to a known user device of the initiator entity and prompting the initiator entity to enter the OTP into the new user device. The result of the device check can correspond to further data used to regenerate the request score.

[0143] The process then proceeds to item 322, at which the decision server 130 regenerates the request score. This regeneration uses at least some of the further data. The regenerated request score will likely be different to the primary request score. However, in some cases, the regenerated risk score is the same as the primary request score, for example where the further data does not in fact change the request score.

[0144] As explained above, at item 320 the decision server 130 can not retrieve all data that can be used to regenerate the request score. For example, if there is additional data that can be used to regenerate the request score but will not or cannot change the request score, this additional data can not be retrieved.

[0145] This can optimise the amount of data transferred in the system 100, as data that is not likely to change the request score and ultimately the final decision is not transferred.

[0146] In the context of facial recognition, the decision server 130 can be able to identify certain pixels and / or regions of the image (for example, in the centre of the image) that have the most influence on the request score. The decision server 130 can only retrieve reference image data for those pixels and / or regions, and not reference image data for other pixels and / or regions (for example, at the edges of the image).

[0147] The process then proceeds to item 324, at which the decision server 130 uses the regenerated request score as the definitive request score.

[0148] In other examples, some or all of the actions shown in Figure 3A and 3B may be omitted, changed or replaced.

[0149] The actions can occur in a different order to that shown in Figure 3A and 3B . For example, item 314 can be performed before item 306. This can be particularly effective where the further data can change the primary request score above the rejection threshold or below the acceptance threshold.

[0150] Figure 3A and 3B The actions shown in

[0151] Figure 3A and 3BOne or more of the actions shown in FIG. 6 can be performed again as part of a recursive procedure. For example, instead of being used as the definitive request score (at item 604), the regenerated request score of item 602 can be compared to the rejection threshold at item 606. If the regenerated request score is not higher than the rejection threshold, then the regenerated request score can be compared to the acceptance threshold at item 608. If the regenerated request score is not lower than the acceptance threshold, then items 612, 614, 616, 618, 620, 622, and 624 can be repeated as appropriate.

[0152] The recursive procedure can be performed one or more times.

[0153] The recursive procedure can be repeated until a predetermined condition is met. An example of such a predetermined condition is that the recursive procedure has been performed a predetermined number of times. Another example of such a predetermined condition is that the regenerated request score exceeds the rejection threshold or is lower than the acceptance threshold.

[0154] In this regard, it should be understood that references to generating a request score (e.g., as performed at item 604) encompass both generating a primary request score (i.e., a request score that is not a regenerated request score) and generating a regenerated request score. Additionally, it should be understood that a regenerated request score can be produced by a single request score regeneration procedure, or by multiple recursions of a request score regeneration procedure.

[0155] Referring to Figure 4 FIG. 4 shows an example plot 400 of request scores versus density.

[0156] Figure 4 An example request score versus density is shown for legitimate requests (solid line) and for non-legitimate requests (dashed line).

[0157] Figure 4 A request score zone 402 is also shown, in which all requests are determined to be non-legitimate requests.

[0158] In this example, an upper request score value 404 of the request score zone 402 is 1.00.

[0159] In this example, a lower request score value 406 of the request score zone 402 is about 0.85. The lower request score value 406 can correspond to the rejection threshold described above.

[0160] Although the majority of requests having request scores in the request score zone 402 are non-legitimate requests (dashed line), a small number of legitimate requests (solid line) having request scores in the request score zone 402 have been incorrectly determined to be non-legitimate. The latter represents a small number of false positives.

[0161] See Figure 5 The example graph 500 shows the request score compared to density.

[0162] Example graph 500 roughly corresponds to example graph 400.

[0163] However, Figure 5 The request resulted in a 502 error, indicating that all requests were deemed valid.

[0164] In this example, the lower bound request score value 504 for request score partition 502 is 0.00.

[0165] In this example, the maximum request score value 506 for the requested partition 502 is approximately 0.15. The maximum request score value 506 can correspond to the acceptance threshold described above.

[0166] Although most requests with a request score in request partition 502 are valid (solid line), a small number of invalid requests with a request score in request partition 502 (dashed line) have been incorrectly judged as valid.

[0167] See Figure 6 The example graph 600 shows the request score compared to density.

[0168] Example curve 600 roughly corresponds to example curves 400 and 500.

[0169] However, Figure 6 The request partition 602 is shown, which has a roughly similar density of legitimate and illegitimate requests across request partition 602.

[0170] In this example, the lower bound request score value of request score 604 for request score partition 602 is approximately 0.15, and corresponds to Figure 5 The requested partition 502 is set to an upper limit of 506.

[0171] In this example, the upper limit of the requested score value for partition 602, 606, is approximately 0.85, and corresponds to Figure 4 The requested partition 402 is set to a lower limit of 406.

[0172] refer to Figure 7 This schematically illustrates the representation of the data retrieval control program 700.

[0173] In this example, request 702 is received. Request 702 includes request data 704.

[0174] The request score generation model 706 calculates a deterministic request score 708 based on the request data 704 included in request 702.

[0175] In some examples, and as indicated by the use of dashed lines, the request score generation model 706 also uses further data 710 to calculate the deterministic request score 708. When used, the further data 710 is retrieved from a data store 712. The data store 712 can correspond to the data store 140 described above.

[0176] Referring to Figure 8 A representation of a decision server 800 is shown schematically.

[0177] The decision server 800 can correspond to the decision server 130 described above.

[0178] The decision server 800 is depicted as comprising various components. These should be understood as logical components. The functionality of a number of components can be combined together. In other examples, Figure 8 Some components shown in FIG. 8 can be omitted, replaced or divided into smaller components. Components can be implemented in hardware and / or software.

[0179] In this example, the decision server 800 comprises a request processor 802. In this example, the request processor 802 receives and processes requests. In this example, processing a request comprises extracting request data from the request.

[0180] In this example, the decision server 800 comprises a request score generator 804.

[0181] In this example, the request processor 802 provides the extracted request data to the request score generator 804.

[0182] In this example, the request score generator 804 uses the extracted request data as input to a primary request score generation model 806.

[0183] In this example, the primary request score generation model 806 outputs a primary request score.

[0184] In this example, the request score generator 804 provides the primary request score to a decision component 808.

[0185] In this example, the decision component 808 uses a comparator 810 to compare the primary request score to one or more threshold scores.

[0186] The decision component 808 can use the primary request score as the deterministic request score.

[0187] However, the decision component 808 can actually use a data retrieval controller 812 to retrieve further data.

[0188] The data retrieval controller 812 can provide additional data to the request score generator 804 directly and / or via the decision component 808 to regenerate the request score.

[0189] The request score generator 804 uses the request score regeneration model 814 to regenerate the request score.

[0190] Although the primary request score generation model 806 and the regenerated request score generation model 814 are depicted as separate components of the decision server 800, such separation should be understood to be logical.

[0191] In some examples, the primary request score generation model 806 is the same as the regenerated request score generation model 814.

[0192] In other examples, the primary request score generation model 806 is different from the regenerated request score generation model 814. For example, the regenerated request score generation model 814 can be able to process additional data as input, while the primary request score generation model 806 can not be able to process the additional data as input.

[0193] More generally, the request score generator 804 can use a request score generation model 816 to generate and / or regenerate request scores. The request score generator 804 can include a primary request score generation model 806 logical component and a regenerated request score generation model 814 logical component. The primary request score generation model 806 and the regenerated request score generation model 814 can be the same model as each other, or can be different models.

[0194] The regenerated request score is then used as the deterministic request score.

[0195] Referring to Figure 9 , a representation of an example data retrieval control method 900 is shown.

[0196] At item 902, a request is received.

[0197] At item 904, a request-based variable is generated using data associated with the request as input to a request-based variable generation model.

[0198] The request-based variable can include a request score, an instruction, a prediction, and / or a risk score. The risk score indicates a risk level associated with the request. However, the request score can include another type of request score, such as a priority score. For example, at high server load, high priority requests can be accepted, low priority requests can be rejected, and intermediate priority requests can be further analyzed (e.g., priority classification) to determine whether they should be accepted or rejected.

[0199] The request-based variable generation model can comprise an ML model. The ML model can be trained using training data. However, the request-based variable generation model can be a rule-based model that does not use ML.

[0200] Generating the request-based variable can comprise using request data comprised in the request. However, as explained above, the request-based variable can be generated in other ways, for example by looking up the request-based variable.

[0201] At item 906, it is determined whether to retrieve further data based on a comparison involving the data retrieval loss metric and / or the data non-retrieval loss metric, in response to determining that using the further data as further input to the request-based variable generation model can change (or "alter") the request-based variable.

[0202] In an example, the data associated with the request is initially used as input to the request-based variable generation model to generate a primary request-based variable. Subsequently, both the further data associated with the request and the data are used as input to the request-based variable generation model to generate a regenerated request-based variable.

[0203] The comparison involving the data retrieval loss metric and the data non-retrieval loss metric can for example comprise determining whether the data retrieval loss metric is greater than, less than, or the same as the data non-retrieval loss metric. In such examples, the data retrieval loss metric and the data non-retrieval loss metric are compared to each other. However, in other examples, the data retrieval loss metric and the data non-retrieval loss metric can be compared to one or more other metrics, for example a predetermined threshold.

[0204] The data retrieval loss metric can be indicative of a loss associated with retrieving the further data, and / or the data non-retrieval loss metric can be indicative of a loss associated with not retrieving the further data.

[0205] The data retrieval loss metric and / or the data non-retrieval loss metric can be based on a data privacy parameter, a data security parameter, a resilience parameter, and / or a latency parameter. However, other parameters can be used, for example depending on the application.

[0206] Retrieving the further data can comprise retrieving the further data from a local storage, retrieving the further data from an external storage, and / or requesting and receiving the further data from an initiator entity, wherein the initiator entity initiated the request. However, in other examples, the further data can be retrieved in another way.

[0207] At item 908, a decision associated with the request is made based on the deterministic request-based variable.

[0208] At item 910, when the comparison indicates that the data non-retrieval loss exceeds the data retrieval loss, the determination is to not retrieve additional data, and the requested variable is used as the deterministic requested variable.

[0209] At item 912, when the comparison indicates that the data non-retrieval loss exceeds the data retrieval loss, the determination is to retrieve additional data, the additional data is retrieved, the requested data and the additional data are used as inputs to a requested variable generation model to regenerate the requested variable to generate a regenerated requested variable, and the regenerated requested variable is used as the deterministic requested variable.

[0210] The method 900 can be performed on a request-by-request basis. However, in other examples, the method can be performed for a group of requests, e.g., for a group of two or more requests. The requests can be grouped together based on content similarity, time of receipt, or other factors.

[0211] The method 900 can be performed in an anomaly behavior detection system. However, the method can be performed in other types of systems, i.e., systems that do not detect anomaly behavior.

[0212] Additional data can be retrieved for one of (i) the request and (ii) a subsequent request, and additional data can not be retrieved for the other of (i) the request and (ii) the subsequent request. As such, additional data can be retrieved for some, but not all, requests. In some situations, e.g., where neither the request nor the subsequent request is clearly legitimate nor clearly illegitimate, additional data can be retrieved for both the request and the subsequent request. In other situations, e.g., where both the request and the subsequent request are clearly legitimate or clearly illegitimate, additional data can not be retrieved for either the request or the subsequent request.

[0213] In some examples, when the requested variable and / or the regenerated requested variable indicates that the request is high risk, the decision of item 908 includes performing an action associated with the high risk request. A high risk request can be a request that has a request score that is above (or below, depending on the implementation) a threshold, e.g., the rejection threshold described above.

[0214] The action associated with the high risk request can include rejecting the request. Rejecting the request can or can not involve communicating a rejection to the requestor. However, another possible action associated with the high risk request is to process the request, but as a high risk request.

[0215] In some examples, when the request-based variable and / or the regenerated request-based variable indicates that the request is low risk, the decision of item 908 includes performing an action associated with a low risk request. A low risk request can be a request that has a request score that is below (or above, depending on the implementation) a threshold (e.g., the acceptance threshold described above).

[0216] The action associated with a low risk request can include accepting the request. Accepting the request can or can not involve communicating an acceptance to the requestor. However, in other examples, a different action associated with a low risk request can be performed. For example, the request can be forwarded to another entity for processing without making a decision as to whether the request should ultimately be accepted or rejected.

[0217] In some examples, when the request-based variable and / or the regenerated request-based variable indicates that the request is medium risk, an action associated with a medium risk request is performed. A medium risk request can be a request that has a request score that is between two thresholds (e.g., the rejection threshold and the acceptance threshold described above).

[0218] The action associated with a medium risk request can include determining whether using additional data as additional input to the request-based variable generation model can change the request-based variable. In response to determining that retrieving additional data would not change the request-based variable, the request-based variable can be used as a deterministic request-based variable.

[0219] In some examples, in response to determining that using additional data as additional input to the request-based variable generation model would not change the request-based variable, the additional data is not retrieved. As such, data that affects the request-based variable can be selectively retrieved.

[0220] The measures (e.g., systems, servers, computer programs) described herein can implement the method 900.

[0221] In particular, a system configured to perform the method 900 can be provided.

[0222] A decision server configured to perform the method 900 can be provided.

[0223] A computer program comprising instructions which, when executed by a processor, cause the processor to perform the method 900 can be provided.

[0224] With reference to Figure 10 , another example system 1000 is shown.

[0225] The example system 1000 has many features in common with the example system 100, as will now be explained.

[0226] The example system 1000 includes a user device 1002, which can correspond to the first user device 102 and / or the second user device 104. The user device 1002 is communicatively coupled to a first network 1004 via a first communication coupling 1006. The first network 1004 can correspond to the first network 106 and / or the second network 110. The first communication coupling 1006 can correspond to the first communication coupling 108 and / or the second communication coupling 112.

[0227] The example system 1000 includes a server 1008, which can correspond to the first server 114 and / or the second server 118. The server 1008 is communicatively coupled to the first network 1004 via a second communication coupling 1010. The second communication coupling 1010 can correspond to the third communication coupling 116 and / or the fourth communication coupling 120.

[0228] The server 1008 is communicatively coupled to a second network 1012 via a third communication coupling 1014. The second network 1012 can correspond to the third network 122 and / or the fourth network 126. The third communication coupling 1014 can correspond to the fifth communication coupling 124 and / or the sixth communication coupling 128.

[0229] The example system 1000 includes a decision server 1016, which can correspond to the decision server 130. The decision server 1016 is communicatively coupled to the second network 1012 via a fourth communication coupling 1018. The fourth communication coupling 1018 can correspond to the seventh communication coupling 132 and / or the eighth communication coupling 134.

[0230] The decision server 1016 is communicatively coupled to a third network 1020 via a fifth communication coupling 1022. The third network 1020 can correspond to the fifth network 136, and the fifth communication coupling 1022 can correspond to the ninth communication coupling 138.

[0231] The example system 1000 includes a data store 1024, which can correspond to the data store 140. The data store 1024 is communicatively coupled to the third network 1020 via a sixth communication coupling 1026. The sixth communication coupling 1026 can correspond to the tenth communication coupling 142.

[0232] As indicated by item 1028, the server 1008 can transmit a request to the decision server 1016. The decision server 1016 can perform data retrieval control as described herein in response to the request from the decision server 1016.

[0233] As indicated by item 1030, the user device 1002 can transmit a request to the decision server 1016. The decision server 1016 can perform data fetch control as described herein in response to the request from the user device 1002.

[0234] In some examples, the user device 1002 transmits this request to the decision server 1016 via the server 1008. In other examples, the user device 1002 can be able to transmit this request directly to the decision server 1016, i.e., without passing the request via the server 1008. For example, in some deployments, the system 1000 can not include the server 1008, and the user device 1002 can be able to communicate directly with the decision server 1016.

[0235] Various decision request triggers can prompt transmission of a request to the decision server 1016. An example of such a decision request trigger is receipt of another request for which a decision is made.

[0236] With reference to the previous specific example, the system 1000 can be used to make decisions related to phone requests. For example, the server 1008 can correspond to the destination server 118, and the user device 1002 can correspond to the destination user device 104. The server 1008 can receive an incoming phone call setup request to the user device 1002. The server 1008 can invoke the decision server 1016, as indicated by item 1028, to decide whether the incoming phone call setup request should be forwarded to the user device 1002. The decision server 1016 can be performing data fetch control in connection with this decision.

[0237] The data fetch control measures described herein have various applications.

[0238] The data fetch control measures can be applied in connection with DoS and / or DDoS attack management. For example, when a downstream system is not operating near capacity, the data fetch control can be relatively relaxed. However, when an increase in the use of computing resources of the downstream system is detected, the data fetch control can be tightened to protect the downstream system from being overwhelmed by non-legitimate requests.

[0239] The data fetch control measures can be used to provide load management with respect to a downstream system.

[0240] Another application relates to anomaly behavior detection. For example, the data fetch control measures can enable accurate anomaly behavior detection while balancing other considerations such as data privacy.

[0241] While specific embodiments of the application have been described in detail, it will be appreciated by those skilled in the art that the embodiments described herein are not limiting of the application as claimed.

[0242] It will also be appreciated that, where appropriate, optional features described above in relation to one aspect, embodiment, or example can also be applicable to other aspects, embodiments, or examples, as appropriate. Various aspects, embodiments and examples can be combined, as appropriate.

[0243] The methods described herein can be computer implemented.

[0244] The aspects, embodiments and examples described herein each expand to include a non-transitory computer readable medium comprising instructions that, when executed by a processor, cause the processor to perform any of the methods described herein.

[0245] The aspects, embodiments and examples described herein each further expand to include a computer software product comprising instructions that, when executed by a processor, cause the processor to perform any of the methods described herein.

[0246] In the context of the present specification, "comprise" is to be interpreted as "include".

Claims

1. A data retrieval control method, the method comprising: receiving a request; generating a request-based variable using data associated with the request, wherein the data is input to a request-based variable generation model to generate the request-based variable; in response to determining that using further data as further input to the request-based variable generation model is able to alter the request-based variable, determining whether to retrieve the further data based on a comparison involving a data retrieval loss metric and a data non-retrieval loss metric, the data retrieval loss metric indicating a loss associated with retrieving the further data, and the data non-retrieval loss metric indicating a loss associated with not retrieving the further data; and formulating a decision associated with the request based on the deterministic request-based variable, wherein when the comparison indicates that the data retrieval loss exceeds the data non-retrieval loss: the determination is not to retrieve the further data; and the request-based variable is used as the deterministic request-based variable, and wherein when the comparison indicates that the data non-retrieval loss exceeds the data retrieval loss: the determination is to retrieve the further data; retrieving the further data; regenerating the request-based variable using the request data and the further data as input to the request-based variable generation model to generate a regenerated request-based variable; and the regenerated request-based variable is used as the deterministic request-based variable.

2. The method of claim 1, wherein the data retrieval loss metric and / or the data non-retrieval loss metric is based on a data privacy parameter.

3. The method of claim 1 or 2, wherein the data retrieval loss metric and / or the data non-retrieval loss metric is based on a data security parameter.

4. The method of any one of claims 1 to 3, wherein the data retrieval loss metric and / or the data non-retrieval loss metric is based on a resilience parameter.

5. The method of any one of claims 1 to 4, wherein the data retrieval loss metric and / or the data non-retrieval loss metric is based on a latency parameter.

6. The method of any one of claims 1 to 5, wherein the method is performed on a request-by-request basis.

7. The method of any one of claims 1 to 6, wherein the further data is retrieved for one of the request and a subsequent request, and wherein the further data is not retrieved for the other of the request and the subsequent request.

8. The method of any one of claims 1 to 7, wherein the request-based variable comprises a request score, an instruction, a prediction, and / or a risk score.

9. The method of any one of claims 1 to 8, wherein, The decision comprises performing an action associated with a high-risk request when the request-based variable and / or the regenerated request-based variable indicates that the request is a high-risk request.

10. The method of claim 9, wherein the action associated with the high-risk request comprises rejecting the request.

11. The method of any one of claims 1 to 10, wherein, When the request-based variable and / or the regenerated request-based variable indicates that the request is low risk, the decision includes performing an action associated with a low risk request.

12. The method of claim 11, wherein the action associated with the low risk request includes accepting the request.

13. The method of any one of claims 1 to 12, wherein, When the request-based variable and / or the regenerated request-based variable indicates that the request is medium risk, an action associated with a medium risk request is performed.

14. The method of claim 13, wherein the action associated with the medium risk request includes determining whether using the additional data as additional input to the request-based variable generation model can alter the request-based variable.

15. The method of claim 14, wherein, In response to determining that retrieving the additional data does not alter the request-based variable, the request-based variable is used as the deterministic request-based variable.

16. The method of any one of claims 1 to 15, wherein the request-based variable generation model includes a machine learning model.

17. The method of any one of claims 1 to 16, wherein retrieving the additional data includes retrieving the additional data from a local storage.

18. The method of any one of claims 1 to 17, wherein retrieving the additional data includes retrieving the additional data from an external storage.

19. The method of any one of claims 1 to 18, wherein retrieving the additional data includes requesting and receiving the additional data from an initiator entity that has initiated the request.

20. The method of any one of claims 1 to 19, wherein in response to determining that using additional data as additional input to the request-based variable generation model does not alter the request-based variable, the additional data is not retrieved.

21. The method of any one of claims 1 to 20, wherein generating the request-based variable includes using request data included in the request.

22. The method of any one of claims 1 to 21, wherein the method is performed by a decision server.

23. The method of any one of claims 1 to 22, wherein the method is performed in an anomaly detection system.

24. A decision server comprising: a request processor; a request-based variable generator; a request-based variable generation model; a decision component; a comparator; and a data retrieval controller, wherein the decision server is configured to perform the method of any one of claims 1 to 23.

25. A system, server and / or computer program configured to perform the method of any one of claims 1 to 23.

Images