Patent Description:
In particular, but not exclusively, the present disclosure relates to measures (for example methods, systems, servers, and computer programs) to perform data retrieval control.

Various measures exist in the art for controlling data retrieval.

For example, a firewall may control incoming requests for data based on preconfigured security rules. A firewall can help to protect a computing resource behind the firewall, such as a server and/or data store, against denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks, as well as other types of malicious activity. A DoS attack is also known as a flood attack.

Artificial intelligence (Al) may be used to calculate a variable associated with an incoming request. Such a variable will generally be referred to herein as a "request-based variable" accordingly. An example of a request-based variable is a risk score associated with the request. A request-based variable may be used, in-turn, to automate a decision such as whether the incoming request should be accepted or declined. Accuracy of such automated decisions generally increases as the amount of data used by the Al increases.

Prior art document <CIT> discloses a method for utilizing neural network model to determine risk, involving causing new application programming interface request to be blocked or permitted based on risk associated with new application programming interface request.

According to a first aspect, there is provided a data retrieval control method, the method comprising:.

According to a second aspect, there is provided a decisioning server comprising:.

According to a third aspect, there is provided a system, server and/or computer program configured to perform a method in accordance with the first aspect of the present disclosure.

Certain embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which:.

Without loss of generality, the present disclosure relates to data retrieval control and optimised data retrieval.

The term "data retrieval" is used herein to mean retrieving, using any mechanism, data of any type and not to be limited to data recovery, i.e. recovering data that may have been lost, corrupted or the like.

As explained above, existing Al-based decision automation systems are based on the premise that more data is better because it improves accuracy. This is generally true.

However, using more data is not an inconsequential decision. For example, using further data creates several trade-offs.

One example trade-off is data privacy. Using further data can increase the likelihood of incurring risks around individual privacy, i.e. data privacy of individuals. Using further data can also place additional requirements to adhere to local privacy regulation.

Another example trade-off is data security. Transmitting and/or storing unnecessary data increases the exposure if security of a decisioning system and/or associated networks is breached.

Another example trade-off is resiliency. Capturing or requesting further data adds complexity to the decision-making process. This increases the surface error for failures in obtaining the data and/or errors within the data. This can result in failures and/or inaccuracies when generating, e.g. calculating, a request-based variable. The lower the computational complexity, the more resilient the system may be.

Another example trade-off is latency. Retrieving data from third party or local systems is not instantaneous. This is particularly the case when the data is sourced from outside of a local network. This therefore has an impact on the amount of time taken to generate a request-based variable, such as a risk score, and to communicate a decision to one or more entities, such as a requesting system. In time-critical, low-latency systems, this is particularly relevant.

Another example trade-off is downstream computing resource impact. Retrieving further data may increase computing resource requirements for downstream systems, for example where the further data requires additional processing by the downstream system. While such additional processing may be tolerable, or even beneficial, in some scenarios, it may be undesirable in other situations. For example, if the downstream system is operating at a near-capacity level, additional processing requests may result in instability or even failure of the downstream system.

Again, without loss of generality, examples described herein optimise trade-offs such as these, on a request-by-request basis, while maintaining accuracy.

Making such decisions on a request-by-request enables highly tuned optimisation. In contrast, existing systems that acquire data to make automated decisions are managed as an optimisation over the entire population of requests rather than for individual requests.

With the increased adoption of Al to make automated decisions, the loss or potential loss in generating these decisions is not insignificant.

Such losses may be related to data privacy, data sectary, resiliency, latency, or otherwise.

Such losses may be related to consequences of inaccurate decisions. For example, the consequence of rejecting a legitimate request may be more significant for a premium user or subscriber than for a non-premium user or subscriber.

Such losses may be dependent on an attribute of the request. For example, it may be more important to make an accurate decision (in other words, the losses may be more significant) on a high-priority request compared to a low-priority request, where priority is an attribute of the request. Another example attribute of a request is a requesting user device type. For example, the losses may vary depending on whether the requesting user device is a desktop computing device or a mobile computing device. As another example, data retrieval loss may depend on a country of origin of the request, which may be indicated by an attribute of the request. In particular, a given country may have low quality data for a preferred provider, meaning that a secondary provider would need to be accessed for higher quality data. This comes with losses, for example in terms of latency. As another example, certain brands of user device may provide limited tracking data in connection with their users. It may therefore be more complex to validate user activity on such user devices than on another brand of user device.

Examples described herein can maintain accuracy, while being more precise in terms of inputs used to arrive at the decision and therefore mitigating the losses and/or risks associated with a range of data practices.

Examples described herein are compatible with high-volume requests, such as many thousands of requests per second. Request volumes may also vary over time, e.g. unexpectedly.

As will be explained in more detail below, in examples, a decisioning server can make a series of calculations and comparisons to decide whether to accept (or "authorise" or "allow") a request or whether to decline (or "refuse" or "reject") the request. The decisioning server can select which (if any) data is to be retrieved and/or data stores are to be accessed to obtain input needed to maintain accuracy of the decisions whilst optimising trade-offs such as data privacy, data security, resiliency, and latency. Such data stores may be internal and/or external as will be described in more detail below.

Referring to <FIG>, there is shown an example system <NUM>. The system <NUM> implements data retrieval control and may be referred to as a data retrieval control system accordingly.

The system <NUM> comprises first and second user devices <NUM>, <NUM>. The term "user device" is used herein to mean any device that can be used by a user of the system <NUM>. User devices may take various forms. Example forms include, but are not limited to, desktop computers, laptop computers, tablet computing devices and smartphones.

Although the system <NUM> comprises two user devices <NUM>, <NUM> in this specific example, other example systems can include a different number of user devices.

In particular, in some examples, the system <NUM> comprises no user devices or comprises one user device. Other elements of the system <NUM> may be modified or omitted accordingly. For example, the system <NUM> may have a service-to-service type architecture and may not comprise any user devices. Examples of such architectures include, but are not limited to, application programming interface (API)-based architectures and file sharing architectures.

In this example, the first user device <NUM> is an originating user device and is associated with an originating entity (not shown). The originating user device may belong to the originating entity or may merely be being used by the originating entity. The originating entity originates a request in the system <NUM>.

In this example, the second user device <NUM> is a destination user device and is associated with a destination entity (not shown). The destination entity is an intended destination of a request and/or something associated with the request. As will be explained in more detail below, a request intended for a destination entity may not, in fact, reach the destination entity.

The originating entity and/or the destination entity may take various different forms. Example forms include, but are not limited to, legal persons and natural persons. A natural person may be a user of the system <NUM>.

The originating user device <NUM> is communicatively coupled to a first network <NUM> via a first communicative coupling <NUM>.

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

The term "communicative coupling" is used herein to mean any type of coupling that enables communication between entities. The coupling may be wired and/or wireless. The coupling may be direct or indirect.

The destination user device <NUM> is communicatively coupled to a second network <NUM> via a second communicative coupling <NUM>.

A first server <NUM>, which in this example is an originating server, is communicatively coupled to the first network <NUM> via a third communicative coupling <NUM>.

The term "server" is used herein to mean a computing entity that provides services to another computing entity. A server may be implemented in hardware and/or software. A server may comprise one or more server components. Server components may be co-located or may be geographically distributed.

The originating server <NUM> handles requests associated with the originating user device <NUM>. For example, the originating server <NUM> may handle requests to and/or from the originating user device <NUM>.

A second server <NUM>, which in this example is a destination server, is communicatively coupled to the second network <NUM> via a fourth communicative coupling <NUM>.

The destination server <NUM> handles requests associated with the destination user device <NUM>. For example, the destination server <NUM> may handle requests to and/or from the destination user device <NUM>.

Although only a single originating server <NUM> and a single destination server <NUM> are shown in <FIG>, multiple originating servers <NUM> and/or multiple destination servers <NUM> may be provided in other example systems.

The originating server <NUM> is communicatively coupled to a third network <NUM> via a fifth communicative coupling <NUM>.

The destination server <NUM> is communicatively coupled to a fourth network <NUM> via a sixth communicative coupling <NUM>.

A decisioning server <NUM> is communicatively coupled to the third network <NUM> via a seventh communicative coupling <NUM>. The decisioning server <NUM> is also communicatively coupled to the fourth network <NUM> via an eighth communicative coupling <NUM>.

The decisioning server <NUM> makes decisions associated with requests communicated in the system <NUM>.

Such requests may ask that the decisioning server <NUM> make a decision associated with another request. For example, an initial request may be received by an entity in the system <NUM> and that entity may send a decisioning request, based on the initial request, to the decisioning server <NUM>.

As such, references to an "originating entity" should be understood to refer to an entity that originates a particular request in the system <NUM> and that such a request may be based on a request that originates from another entity.

Although only a single decisioning server <NUM> is shown in <FIG>, multiple decisioning servers <NUM> may be provided in other example systems.

The decisioning server <NUM> is communicatively coupled to a fifth network <NUM> via a ninth communicative coupling <NUM>.

A data store <NUM> is communicatively coupled to the fifth network <NUM> via a tenth communicative coupling <NUM>.

The term "data store" is used herein to mean any entity that can store data. The data store may comprise 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, solid-state storage, and flash memory. Combinations of one or more of these may also be used for the storage of data, as technically appropriate (e.g. using faster access volatile memory for frequently accessed data).

The data store may store data in various different ways, for example in one or more databases. A data store may comprise one or more data store components. Data store components may be co-located or may be geographically distributed.

The data store <NUM> stores data. The data may comprise a signal (which may also be referred to as "signal data").

Although only a single data store <NUM> is shown in <FIG>, multiple data stores <NUM> may be provided in other examples. Some or all of the data stores <NUM> may be of the same type as each other. Some or all of the data stores <NUM> may be of different types from each other.

In some examples, such as is shown in <FIG>, the data store <NUM> is external to the decisioning server <NUM>. However, in other examples, the data store <NUM> is internal (or "local") to the decisioning server <NUM>. Where the system comprises multiple data stores <NUM>, the data stores <NUM> may comprise a mix of internal and external data stores. Retrieving data from multiple data stores <NUM> may increase data privacy, data security, resiliency and latency risks, for example. The resources involved in retrieving data from an external data store <NUM> may be greater than the resources involved in retrieving data from an internal data store <NUM>.

The first to fifth networks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may take various different forms. Some or all of the first to fifth networks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may take the same form as each other. Some or all of the first to fifth networks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may take different forms from each other.

In some examples, one or more of the first to fifth networks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> comprises a public network. An example of such a public network is the Internet.

In some examples, one or more of the first to fifth networks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> comprises a private network. An example of such a public network is a local area network (LAN).

Although, in the example system <NUM>, networks and multiple communicative couplings are provided between the various system entities (the user devices <NUM>, <NUM>, servers <NUM>, <NUM>, <NUM> and data store <NUM>), some or all of the networks may be replaced by direct couplings in other examples.

The first to tenth communicative couplings <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may take various different forms. Some or all of the first to tenth communicative couplings <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may take the same form as each other. Some or all of the first to tenth communicative couplings <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may take different forms from each other.

In some examples, one or more of the first to tenth communicative couplings <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> comprises a wireless coupling. An example of such a wireless coupling is a Wi-Fi™ coupling.

In some examples, one or more of the first to tenth communicative couplings <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> comprises a wired coupling. An example of such a wired coupling is an Ethernet cable.

In a specific example, the system <NUM> may be used to make decisions in relation to telephony requests. For example, the originating user device <NUM> may transmit a telephone call setup request to the originating server <NUM>. The originating server <NUM> may then forward the telephone call setup request to the decisioning server <NUM>. The decisioning server <NUM> may decide that the telephone call setup request is legitimate and forward the telephone call setup request to the destination user device <NUM> via the destination server <NUM> accordingly. Alternatively, the decisioning server <NUM> may decide that the telephone call setup request is not legitimate and may refuse the telephone call setup request accordingly.

Referring to <FIG>, there is shown a part <NUM> of the example system <NUM> described above with reference to <FIG>.

<FIG> shows, schematically, how the amount of data communicated between the decisioning server <NUM> and the data store <NUM> via the tenth communicative coupling <NUM> varies with and without the data retrieval control measures described herein.

As shown schematically by the width of the representation of the tenth communicative coupling <NUM> in <FIG>, the amount of data communicated between the decisioning server <NUM> and the data store <NUM> is greater without the data retrieval control measures (to the left of the broken line <NUM> in <FIG>) than with the data retrieval control measures (to the right of the broken line <NUM> in <FIG>).

As such, the data retrieval control measures described herein can control, i.e. reduce, the amount of data communicated between the decisioning server <NUM> and the data store <NUM>.

Referring to <FIG> and <FIG>, there is shown an example data retrieval control method <NUM>.

In this example, the data retrieval control method <NUM> is performed by the decisioning server <NUM>. However, one or more of the actions shown in <FIG> and <FIG> may be performed at one or more other entities in other examples.

At item <NUM>, the decisioning server <NUM> receives a request. The request may be received in various different ways. For example, the request may be received over a communicative coupling, such as the fifth communicative coupling <NUM> described above.

The decisioning server <NUM> may have received the request from the originating user device <NUM> via the originating server <NUM>, or otherwise. In particular, the originating server <NUM> may have transmitted the request to the decisioning server <NUM> to be subject to request-related decisioning.

Various different types of request trigger may have caused the request to be received by the decisioning server <NUM>. For example, user interaction with the originating user device <NUM> may have triggered the request. Alternatively, an automated process on the originating user device <NUM> may have triggered the request, for example if the originating user device <NUM> is compromised and being used as part of an attack or other non-legitimate (or "malicious") activity.

At item <NUM>, the decisioning server <NUM> generates a request-based variable associated with the request. The request-based variable may be referred to as a "primary" request-based variable.

The term "variable" is used herein to mean anything that can change. A variable may, for example, comprise a value, number, amount, or otherwise. As used herein, a variable may comprise one or more variable components, i.e. components of the variable. For example, a variable, v , may comprise variable components v<NUM>, v<NUM>,.

The term "request-based variable" is used herein to mean a variable that is generated using data associated with a request. Such generation may comprise derivation, calculation, look-up, or otherwise. The data associated with the request may include data comprised in the request and/or data not comprised in, but otherwise associated with, the request.

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

The term "score" is used herein in a general sense to mean an evaluative measure.

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

Generating the request-based variable comprises using data associated with the request as input to a request-based variable generation model, i.e. a model that generates a request-based variable.

The term "model" is used herein generally to encompass both machine leaning (ML) models and rule-based models. The request-based variable generation model may map one or more inputs to one or more outputs, with the one or more outputs comprising the request-based variable.

The data associated with the request may comprise request data comprised in the request and/or other data not comprised in, but otherwise associated with, the request. In particular, it may be possible to generate the request-based variable without using any request data comprised in the request. For example, the request-based variable may be generated based on a time of receipt of the request, a communication channel on which the request is received (e.g. where the decisioning server <NUM> can receive requests via multiple communication channels), etc. The time of receipt of the request and the communication channel on which the request is received may be stored in data that is not comprised in, but is otherwise associated with, the request.

For convenience and brevity, in specific examples described below, the request-based variable comprises a request score. However, as explained above, the request-based variable may comprise one or more additional request-based variable components and/or one or more alternative request-based variable components in other examples. As such, examples herein concerning request scores should be understood to be applicable to other types of request-based variable unless the context requires otherwise. For example, references below to a "request score generation model" should be understood to encompass another type of request-based variable generation model, for example where a request-based variable other than a request score is being generated.

A request score may comprise a numerical value. Where the request score comprises a numerical value, the request score may be in the range from <NUM> to <NUM>. However, the request score may be in a different numerical range in other examples.

A low request score within the relevant numerical range (e.g. a score of <NUM> in a range from <NUM> to <NUM>) may correspond to a low level of risk and a high level of legitimacy. A high request score within the relevant numerical range (e.g. a score of <NUM> in a range from <NUM> to <NUM>) may correspond to a high level of risk and a low level of legitimacy.

However, the request score may take another form in other examples. For example, the request score may comprise a letter from a predetermined set of letters, such as "A", "B", "C", and "D". The request score may comprise a label from a predetermined set of labels, such as "legitimate", "non-legitimate" and "uncertain".

In this example, the decisioning server <NUM> generates the request score by calculating the request score. However, the decisioning server <NUM> may generate the request score in another manner in other examples. For example, the decisioning server <NUM> may look up the request score. For example, the decisioning server <NUM> may look up the request score in a table based on request data comprised in the request without performing calculations. In this regard, references herein to calculating the request score also apply to other techniques to generate the request score unless the context requires otherwise.

At item <NUM>, the decisioning server <NUM> compares the request score to a decline threshold. The term "decline threshold" is used herein to mean a threshold against which the request score can be compared and which indicates whether or not the request is to be declined. If the request score is greater than the decline threshold then, at item <NUM>, the request is declined. The request score being greater than the decline threshold means, in this example, that the request is high-risk, low-legitimacy and should therefore be declined.

If, at item <NUM>, the request score is not greater than the decline threshold then, at item <NUM>, the decisioning server <NUM> compares the request score to an accept threshold. The term "accept threshold" is used herein to mean a threshold against which the request score can be compared and which indicates whether or not the request is to be accepted.

If the request score is less than the accept threshold then, at item <NUM>, the request is accepted. The request score being less than the accept threshold means, in this example, that the request is low-risk, high-legitimacy and should therefore be accepted.

If, at item <NUM>, the request score is not less than the accept threshold then, at item <NUM>, the decisioning server <NUM> determines whether further data may change the request score.

The term "further data" is used herein to mean any data that can be used in generating a request score. For example, the further data may be useable to regenerate the primary request score.

The term "may" as used in the context of determining whether further data may change the request score, indicates that the further data might result in the request score changing but not that the request score will necessarily change. This is because the request score is only regenerated when the further data has actually been retrieved.

The decisioning server <NUM> may perform the determination of item <NUM> in various different ways.

For example, the decisioning server <NUM> may identify, for a certain type of request, that legitimate requests from a given originating entity should use a source Internet Protocol (IP) address that has been used in previous requests from that given originating entity. When such types of request are received, retrieving historic IP address usage information (listing previously used IP addresses for that given originating entity) can therefore influence the request score. However, historic IP address usage information may not be relevant to other types of request and/or other types of further data may not influence request scores for all types of request.

If the decisioning server <NUM> determines that the further data would not likely change the request score then, at item <NUM>, the request score is used as a determinative request score. The term "determinative request score" is used herein to mean the request score that is used to determine what decision to make in connection with the request, for example to accept or decline the request.

At item <NUM>, the request score is not above the decline threshold (see item <NUM>) and is not below the accept threshold (see item <NUM>), and so the request score does not indicate whether the request is (likely) legitimate or non-legitimate. One or more predetermined actions may be taken in such situations. For example, the request may be subject to analyst review.

If the decisioning server <NUM> determines that the further data would likely change the request score then, at item <NUM>, the decisioning server <NUM> determines whether a data retrieval loss associated with retrieving the further data would outweigh a data non-retrieval loss associated with not retrieving the further data.

The term "data retrieval loss" is used herein to mean a loss associated with retrieving (further) data. The term "data non-retrieval loss" is used herein to mean a loss associated with not retrieving (further) data.

The term "loss" is used herein to mean something undesirable, unwanted or negative, for example in contrast to a desirable, wanted or positive gain.

The term "outweigh" is used herein to mean more significant than. A number may be considered to outweigh another number if it is greater than the other number. However, in some implementations, a lower number could be indicative of a greater significance of what the number represents.

For example, a data retrieval loss indicator, I<NUM>, may be defined as <MAT>, where Pi is one of n parameters used to derive the data retrieval loss indicator, I<NUM>.

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

Similarly, a data non-retrieval loss indicator, I<NUM>, may be defined as <MAT>, where Qj is one of m parameters used to derive the data non-retrieval loss indicator, I<NUM>. Examples of such parameters include, but are not limited to, a data privacy parameter, a data security parameter, a resiliency parameter, a latency parameter, an inaccurate decision consequence parameter, a request attribute parameter, an uncertainty parameter, and a request-score-change parameter.

In a specific example, each of the above-mentioned parameters Pi and Qj may take a value, for example in a range from <NUM> to <NUM>. The data retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>, may then be the sum of their respective parameter values.

The values of the parameters Pi and Qj may be set by an operator of the system and/or may be derived in another manner. For example, a latency value may be observed and/or measured.

An inaccurate decision consequence parameter may indicate a measure of loss as a consequence of incorrectly classifying the request. This parameter may, in effect, weight in favour of retrieval or non-retrieval of the further data, for example based on whether the further data is likely to increase accuracy and the magnitude of the consequence.

A request attribute parameter may indicate a measure of loss based on an attribute of the request. For example, a loss may be more significant for certain types of request, user, originating user device, etc. If, for example, retrieving certain further data for a certain type of request has historically increased accuracy of decision for that type of request, the request attribute parameter may be weighted in favour of retrieval. On the other hand, if retrieving that same further data (and/or other further data) for another type of request has historically resulted in negligible changes in accuracy, the request attribute parameter may be weighted in favour of non-retrieval.

An uncertainty parameter may indicate a measure of uncertainty associated with the generated request score of item <NUM>. For example, an IP address comprised in a request may have reduced the confidence (and so increased the uncertainty) of the generated request score by either a large amount or by a small amount. In such a situation, the uncertainty parameter may be weighted towards retrieval in the expectation that it may increase confidence.

A request-score-change parameter may indicate a measure of likeliness of further data changing the generated request score. In one specific example, a request-score-change parameter may indicate a likelihood of the further data comprising IP address history information. In another specific example, a request-score-change parameter may indicate an accuracy of the further data. For example, data from certain countries may have relatively low accuracies. The request-score-change parameter may be derived as a result of item <NUM>, or otherwise.

The data retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>, may then be compared to each other to determine whether or not the data retrieval loss would outweigh the data non-retrieval loss.

By way of a specific numerical example, the (potential) data privacy loss in not retrieving further data may be high, for example <NUM> (in the range from <NUM> to <NUM>). For example, if a non-legitimate login request is incorrectly classified as a legitimate login request, a malicious actor might be able to access account data.

The (potential) data privacy loss in retrieving the further data may, however, be low, for example <NUM> (in the range from <NUM> to <NUM>). For example, data retrieval may be subject to authentication, encryption and/or other data security measures such that communicated data is highly secure.

However, the (potential) latency loss in retrieving the further data may be very high, for example <NUM> (in the range from <NUM> to <NUM>) and the (potential) latency loss in not retrieving the further data may be zero, for example <NUM> (in the range from <NUM> to <NUM>). The latency loss in retrieving the further data may be high for various reasons. For example, there may be a significant amount of further data to retrieve, the further data retrieval connection may have a low bandwidth, the further data may be stored across multiple data stores, and so on.

The data retrieval loss indicator, I<NUM>, may be calculated as I<NUM> = <NUM> + <NUM> = <NUM> and the data non-retrieval loss indicator, I<NUM>, may be calculated as I<NUM> = <NUM> + <NUM> = <NUM>.

Since I<NUM> = <NUM> > <NUM> = I<NUM>, the determination may be that the data retrieval loss would outweigh the data non-retrieval loss, even though there is potentially a significant data privacy loss in not retrieving the further data.

The above-mentioned parameters may be weighted and/or different parameter ranges may be used for the different parameters. For example, the data retrieval loss indicator, I<NUM>, may be defined as <MAT>, where ai is a parameter weight. The parameter weight, αi, may be a numerical value in the range from <NUM> to <NUM> for example. The data non-retrieval loss indicator, I<NUM>, may be defined accordingly.

Different weights may be used in different scenarios. For example, in some scenarios such as voice communication applications, latency may be heavily weighted. In some scenarios such as where personal data of an individual is involved, data privacy may be heavily weighted.

In the above specific numerical example, the same parameters are used for both the retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>. However, different parameters may be used in other examples.

For example, the data non-retrieval loss indicator, I<NUM>, may be based on a downstream server operating load parameter. The downstream server operating parameter may be indicative of an operating load of the downstream server.

In the above specific numerical example, multiple parameters are used for both the retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>. However, one or both may use a single parameter in other examples.

Additionally, in this specific example, the retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>, are calculated based on respective parameters Pi and Qj.

In other examples, one of the retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>, is a predetermined threshold value. For example, in the above specific numerical example, the data retrieval loss indicator, I<NUM>, may be defined as <MAT>, and the data non-retrieval loss indicator, I<NUM>, may be a predetermined threshold value, for example <NUM>. In such other examples, the data retrieval loss indicator, I<NUM>, may still be calculated as <NUM>, but would be compared to the threshold value of <NUM> rather than being compared to the calculated value of <NUM>. A predetermined threshold value may be static or may be dynamic. In this specific example, the data non-retrieval loss indicator, I<NUM>, is still indicative of a loss associated with not retrieving the further data even though it is a predetermined threshold value. In particular, the predetermined threshold value is indicative of a value at which the loss associated with not retrieving the further data matches the loss associated with retrieving the further data.

In other examples, both the retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>, are compared to one or more predetermined threshold values. Such a comparison involves both the retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>, in addition to the one or more predetermined threshold values.

In another example, the data retrieval loss indicator, I<NUM>, may be defined as I<NUM> = max{Pi}, the data non-retrieval loss indicator, I<NUM>, may be defined as I<NUM> = max{Qj}, and I<NUM> may be compared to I<NUM> in a similar manner to that described above.

Although, in examples described above, the retrieval loss indicator, I<NUM>, and the data non-retrieval loss indicator, I<NUM>, are numerical values, they may take different forms in other examples. For example, they may be "high", "medium" and "low". A ranking rule may be configured such that "high" outweighs "medium" and "low", and "medium" outweighs "low".

If the decisioning server <NUM> determines that the data retrieval loss would outweigh the data non-retrieval loss, then the method proceeds to item <NUM>, where the request score is used as the determinative request score.

If the decisioning server <NUM> determines that the data retrieval loss would not outweigh the data non-retrieval loss then, at item <NUM>, the decisioning server <NUM> retrieves the further data.

In a specific example, the decisioning server <NUM> may identify that an originating entity is using a different originating user device from their usual originating user device. For example, the originating entity may be using a user device of a family member. The decisioning server <NUM> may, accordingly, perform a device check. This may, for example, involve sending a one-time password (OTP) to a known user device of the originating entity and prompting the originating entity to enter the OTP into the new user device. The result of the device check may correspond to the further data used to regenerate the request score.

Processing then proceeds to item <NUM>, where the decisioning server <NUM> regenerates the request score. Such regeneration uses at least some of the further data. The regeneration will likely result in a different request score compared to the primary request score. However, in some situations, 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.

As explained above, the decisioning server <NUM> may not, at item <NUM>, retrieve all data that could be used to regenerate the request score. For example, if there were additional data that could be used to regenerate the request score, but which would not, or would not be likely to, change the request score, such additional data may not be retrieved.

This can optimise the amount of data transferred in the system <NUM>, since data that is not likely to change the request score and, ultimately, the eventual decision is not communicated.

In the context of facial recognition, the decisioning server <NUM> may be able to identify that certain pixels and/or regions of an image (e.g. in the centre of the image) are most influential on the request score. The decisioning server <NUM> may retrieve reference image data for only those pixels and/or regions and not retrieve reference image data for other pixels and/or regions (e.g. at the edge of the image).

Processing then proceeds to item <NUM>, where the decisioning server <NUM> uses the regenerated request score as the determinative request score.

Some or all of the actions shown in <FIG> and <FIG> may be omitted, varied or replaced in other examples.

Actions may take place in a different order from the order shown in <FIG> and <FIG>. For example, item <NUM> could be performed prior to item <NUM>. This may be particularly effective where the further data could change a primary request score that is above the decline threshold or below the accept threshold.

Actions shown in <FIG> and <FIG> may be divided or combined.

One or more actions shown in <FIG> and <FIG> may be performed again as part of a recursive procedure. For example, as indicated by item <NUM>, instead of being used as the determinative request score (at item <NUM>), the regenerated request score of item <NUM> may be compared to the decline threshold at item <NUM>. If the regenerated request score is not above the decline threshold, the regenerated request score may be compared to the accept threshold at item <NUM>. If the regenerated request score is not below the accept threshold, then items <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be repeated as appropriate.

The recursive procedure may be performed one or multiple times.

The recursive procedure may be repeated until a predetermined condition is met. An example of such a predetermined condition is the recursive procedure having been performed a predetermined number of times. Another example of such a predetermined condition is the regenerated request score exceeding the decline threshold or being below the accept threshold.

In this connection, it should be understood that references to generating a request score, for example as is performed at item <NUM>, 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. In addition, it should be understood that a regenerated request score may result from a single request score regeneration procedure, or from multiple recursions of a request score regeneration procedure.

Referring to <FIG>, there is shown an example graph <NUM> of request score versus density.

<FIG> shows example request score versus density for legitimate requests (solid line) and for non-legitimate requests (broken line).

<FIG> also shows a request score region <NUM> in which all requests are decisioned as non-legitimate requests.

In this example, the upper request score value <NUM> of the request score region <NUM> is <NUM>.

In this example, the lower request score value <NUM> of the request score region <NUM> is around <NUM>. The lower request score value <NUM> may correspond to the decline threshold described above.

Although most of the requests with request scores in the request score region <NUM> are non-legitimate requests (broken line), a small number of legitimate requests (solid line) with request scores in the request score region <NUM> have incorrectly been decisioned as non-legitimate. The latter represent a small number of false positives.

Referring to <FIG>, there is shown an example graph <NUM> of request score versus density. The example graph <NUM> corresponds generally to the example graph <NUM>.

However, <FIG> shows a request score region <NUM> in which all requests are decisioned as legitimate requests.

In this example, the lower request score value <NUM> of the request score region <NUM> is <NUM>.

In this example, the upper request score value <NUM> of the request score region <NUM> is around <NUM>. The upper request score value <NUM> may correspond to the accept threshold described above.

Although most of the requests with request scores in the request score region <NUM> are legitimate requests (solid line), a small number of non-legitimate requests (broken line) with request scores in the request score region <NUM> have incorrectly been decisioned as legitimate.

The example graph <NUM> corresponds generally to the example graphs <NUM>, <NUM>.

However, <FIG> shows a request score region <NUM> with roughly similar densities of legitimate and non-legitimate requests across the request score region <NUM>.

In this example, the lower request score value <NUM> of the request score region <NUM> is around <NUM> and corresponds to the upper value <NUM> of the request score region <NUM> shown in <FIG>.

In this example, the upper request score value <NUM> of the request score region <NUM> is around <NUM> and corresponds to the lower value <NUM> of the request score region <NUM> shown in <FIG>.

Referring to <FIG>, there is shown schematically a representation of a data retrieval control procedure <NUM>.

In this example, a request <NUM> is received. The request <NUM> comprises request data <NUM>. A request score generation model <NUM> calculates a determinative request score <NUM> based on the request data <NUM> comprised in the request <NUM>.

In some examples, and as indicated by the use of broken lines, the request score generation model <NUM> also uses further data <NUM> to calculate the determinative request score <NUM>. When used, the further data <NUM> is retrieved from a data store <NUM>. The data store <NUM> may correspond to the data store <NUM> described above.

Referring to <FIG>, there is shown schematically a representation of a decisioning server <NUM>.

The decisioning server <NUM> may correspond to the decisioning server <NUM> described above.

The decisioning server <NUM> is depicted as comprising various components. These should be understood to be logical components. Functionality of multiple components may be combined together. Some components shown in <FIG> may be omitted, replaced or divided into smaller components in other examples. The components may be implemented in hardware and/or software.

In this example, the decisioning server <NUM> comprises a request processor <NUM>. In this example, the request processor <NUM> receives and processes requests. In this example, processing a request comprises extracting request data from the request.

In this example, the decisioning server <NUM> comprises a request score generator <NUM>.

In this example, the request processor <NUM> provides extracted request data to the request score generator <NUM>.

In this example, the request score generator <NUM> uses the extracted request data as input to a primary request score generation model <NUM>.

In this example, the primary request score generation model <NUM> outputs a primary request score.

In this example, the request score generator <NUM> provides the primary request score to a decisioning component <NUM>.

In this example, the decisioning component <NUM> uses a comparator <NUM> to compare the primary request score to one or more threshold scores.

The decisioning component <NUM> may use the primary request score as the determinative request score.

However, the decisioning component <NUM> may instead use a data retrieval controller <NUM> to retrieve further data.

The data retrieval controller <NUM> may provide the further data to the request score generator <NUM> directly and/or via the decisioning component <NUM> to regenerate the request score.

The request score generator <NUM> uses a request score regeneration model <NUM> to regenerate the request score.

Although the primary request score generation model <NUM> and the regenerated request score generation model <NUM> are depicted as separate components of the decisioning server <NUM>, this separation should be understood to be logical.

In some examples, the primary request score generation model <NUM> is the same as the regenerated request score generation model <NUM>.

In other examples, the primary request score generation model <NUM> is different from the regenerated request score generation model <NUM>. For example, the regenerated request score generation model <NUM> may be able to process the further data as an input whereas the primary request score generation model <NUM> may not be able to process the further data as an input.

More generally, the request score generator <NUM> may use a request score generation model <NUM> to generate and/or regenerate a request score. The request score generator <NUM> may comprise a primary request score generation model <NUM> logical component and a regenerated request score generation model <NUM> logical component. The primary request score generation model <NUM> and the regenerated request score generation model <NUM> may be the same model as each other or may be different models.

The regenerated request score is then used as the determinative request score.

Referring to <FIG>, there is shown a representation of an example data retrieval control method <NUM>.

At item <NUM>, a request-based variable is generated using data associated with the request as input to a request-based variable generation model.

The request-based variable may comprise a request score, an instruction, a predication and/or a risk score. A risk score is indicative of a level of risk associated with the request. However, the request score may comprise another type of request score, such as a priority score. For example, in times of high server load, high priority requests may be accepted, low priority requests may be rejected, and intermediate priority requests may be subject to further analysis, e.g. priority classification, to determine whether they should be accepted or rejected.

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

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

At item <NUM>, in response to determining that using further data as further input to the request-based variable generation model may alter (or "change") the request-based variable, it is determined whether or not to retrieve the further data based on a comparison involving a data retrieval loss indicator and/or a data non-retrieval loss indicator.

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

The comparison involving the data retrieval loss indicator and the data non-retrieval loss indicator may, for example, comprise determining whether the data retrieval loss indicator is greater than, less than, or the same as the data non-retrieval loss indicator. In such examples, the data retrieval loss indicator and the data non-retrieval loss indicator are compared to each other. However, the data retrieval loss indicator and the data non-retrieval loss indicator may be compared to one or more other indicators, such as predetermined threshold values, in other examples.

The data retrieval loss indicator may be indicative of a loss associated with retrieving the further data and/or the data non-retrieval loss indicator may be indicative of a loss associated with not retrieving the further data.

The data retrieval loss indicator and/or the data non-retrieval loss indicator may be based on a data privacy parameter, a data security parameter, a resiliency parameter and/or a latency parameter. However, other parameters may be used, for example depending on the application.

Retrieval of the further data may comprise retrieving the further data from local storage, retrieving the further data from external storage, and/or requesting and receiving the further data from an originating entity, where the originating entity originated the request. However, the further data may be retrieved in another manner in other examples.

At item <NUM>, a decision associated with the request is made based on a determinative request-based variable.

At item <NUM>, when the comparison indicates that the data retrieval loss outweighs the data non-retrieval loss, the determination is not to retrieve the further data, and the request-based variable is used as the determinative request-based variable.

At item <NUM>, when the comparison indicates that the data non-retrieval loss outweighs the data retrieval loss, the determination is to retrieve the further data, the further data is retrieved, the request-based variable is regenerated using the request data and the further data as inputs to the request-based variable generation model to generate a regenerated request-based variable, and the regenerated request-based variable is used as the determinative request-based variable.

The method <NUM> may be performed on a request-by-request basis. However, the method could be performed for groups of requests, for example for groups of two or more requests, in other examples. Requests may be grouped together based on content similarity, time of receipt, or otherwise.

The method <NUM> may be performed in an anomalous behaviour detection system. However, the method may be performed in other types of systems, i.e. systems that do not detect anomalous behaviour.

The further data may be retrieved for one of (i) the request and (ii) a subsequent request, and the further data may not be retrieved for the other of (i) the request and (ii) the subsequent request. As such, further data may be retrieved for some but not all requests. In some situations, for example where both the request and the subsequent request are neither clearly legitimate nor clearly non-legitimate, the further data may be retrieved for both the request and the subsequent request. In other situations, for example where both the request and the subsequent request are clearly legitimate or clearly non-legitimate, the further data may be retrieved for neither the request nor the subsequent request.

In some examples, when the request-based variable and/or the regenerated request-based variable is indicative of the request being high-risk, the decision of item <NUM> comprises performing an action associated with a high-risk request. A high-risk request may be a request having a request score above (or below, depending on implementation) a threshold, such as the above-described decline threshold.

The action associated with the high-risk request may comprise refusing the request. Refusing the request may or may not involve communicating the refusal to a requestor. However, another possible action associated with the high-risk request is to process the request, but as a high-risk request.

In some examples, when the request-based variable and/or the regenerated request-based variable is indicative of the request being low-risk, the decision of item <NUM> comprises performing an action associated with a low-risk request. A low-risk request may be a request having a request score below (or above, depending on implementation) a threshold, such as the above-described accept threshold.

The action associated with the low-risk request may comprise accepting the request. Accepting the request may or may not involve communicating the acceptance to a requestor. However, a different action associated with the low-risk request may be performed in other examples. For example, the request may be forwarded to another entity for processing without a decision being made on whether the request should ultimately be accepted or declined.

In some examples, when the request-based variable and/or the regenerated request-based variable is indicative of the request being medium-risk, an action associated with a medium-risk request is performed. A medium-risk request may be a request having a request score between two thresholds, such as the above-described decline and accept thresholds.

The action associated with the medium-risk request may comprise determining whether using the further data as further input to the request-based variable generation model may alter the request-based variable. In response to determining that retrieving the further data would not alter the request-based variable, the request-based variable may be used as the determinative request-based variable.

In some examples, in response to determining that using additional data as additional input to the request-based variable generation model would not alter the request-based variable, the additional data is not retrieved. As such, data can selectively be retrieved which influences the request-based variable.

Measures (such as systems, servers, computer programs) described herein may implement the method <NUM>.

In particular, a system configured to perform the method <NUM> may be provided.

A decisioning server configured to perform the method <NUM> may be provided.

A computer program comprising instructions which, when executed by a processor, cause the processor to perform the method <NUM> may be provided.

Referring to <FIG>, there is shown another example system <NUM>.

The example system <NUM> has many features in common with the example system <NUM> as will now be explained.

The example system <NUM> comprises a user device <NUM>, which may correspond to the first and/or second user device <NUM>, <NUM>. The user device <NUM> is communicatively coupled to a first network <NUM> via a first communicative coupling <NUM>. The first network <NUM> may correspond to the first and/or second network <NUM>, <NUM>. The first communicative coupling <NUM> may correspond to the first and/or second communicative coupling <NUM>, <NUM>.

The example system <NUM> comprises a server <NUM>, which may correspond to the first and/or second server <NUM>, <NUM>. The server <NUM> is communicatively coupled to the first network <NUM> via a second communicative coupling <NUM>. The second communicative coupling <NUM> may correspond to the third and/or fourth communicative coupling <NUM>, <NUM>.

The server <NUM> is communicatively coupled to a second network <NUM> via a third communicative coupling <NUM>. The second network <NUM> may correspond to the third and/or fourth network <NUM>, <NUM>. The third communicative coupling <NUM> may correspond to the fifth and/or sixth communicative coupling <NUM>, <NUM>.

The example system <NUM> comprises a decisioning server <NUM>, which may correspond to the decisioning server <NUM>. The decisioning server <NUM> is communicatively coupled to the second network <NUM> via a fourth communicative coupling <NUM>. The fourth communicative coupling <NUM> may correspond to the seventh and/or eighth communicative coupling <NUM>, <NUM>.

The decisioning server <NUM> is communicatively coupled to a third network <NUM> via a fifth communicative coupling <NUM>. The third network <NUM> may correspond to the fifth network <NUM> and the fifth communicative coupling <NUM> may correspond to the ninth communicative coupling <NUM>.

The example system <NUM> comprises a data store <NUM>, which may correspond to the data store <NUM>. The data store <NUM> is communicatively coupled to the third network <NUM> via a sixth communicative coupling <NUM>. The sixth communicative coupling <NUM> may correspond to the tenth communicative coupling <NUM>.

As indicated by item <NUM>, the server <NUM> may communicate a request to the decisioning server <NUM>. The decisioning server <NUM> may perform data retrieval control as described herein in response to the request from the decisioning server <NUM>.

As indicated by item <NUM>, the user device <NUM> may communicate a request to the decisioning server <NUM>. The decisioning server <NUM> may perform data retrieval control as described herein in response to the request from the user device <NUM>.

In some examples, the user device <NUM> communicates such a request to the decisioning server <NUM> via the server <NUM>. In other examples, the user device <NUM> may be able to communicate such a request to the decisioning server <NUM> directly, i.e. without the request passing via the server <NUM>. For example, the system <NUM> may not include the server <NUM> in some deployments and the user device <NUM> may be able to communicate directly with the decisioning server <NUM>.

Various decisioning request triggers may prompt the communication of the request to the decisioning server <NUM>. An example of such a decisioning request trigger is receiving another request in relation to which a decision is to be made.

With reference to an earlier specific example, the system <NUM> may be used to make decisions in relation to telephony requests. For example, the server <NUM> may correspond to the destination server <NUM> and the user device <NUM> may correspond to the destination user device <NUM>. The server <NUM> may receive an incoming telephone call setup request destined for the user device <NUM>. The server <NUM> may invoke the decisioning server <NUM>, as indicated by item <NUM>, to decide whether or not the incoming telephone call setup request should be forwarded to the user device <NUM>. The decisioning server <NUM> may be performing data retrieval control in connection with such decisioning. The data retrieval control measures described herein have various applications.

The data retrieval control measures may be applied in connection with DoS and/or DDoS attack management. For example, the data retrieval control may be relatively relaxed when downstream systems are not operating near capacity. However, when an increase in computing resource usage by downstream systems is detected, the data retrieval control may be tightened to protect the downstream system from being overwhelmed by non-legitimate requests.

The data retrieval control measures may be used to provide load management in respect of downstream systems.

Another application is in connection with anomalous behaviour detection. For example, the data retrieval control measures may enable accurate anomalous behaviour detection to be performed, while trading off other considerations such as data privacy.

While specific embodiments of the present invention have been described in detail, it will be appreciated by those skilled in the art that the embodiments described in detail are not limiting on the scope of the claimed invention.

It will also be appreciated that optional features described hereinabove in respect of aspects, embodiments and examples apply equally, where technically appropriate, to other aspects, embodiments and examples. Where technically appropriate, aspects, embodiments and examples may be combined.

Methods described herein may be computer-implemented.

The aspects, embodiments and examples described herein each extend to a non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to carry out any method described herein.

The aspects, embodiments and examples described herein each further extend to a computer software product comprising instructions that, when executed by a processor, cause the processor to carry out any method described herein.

Claim 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 may alter the request-based variable, determining whether or not to retrieve the further data based on a comparison involving a data retrieval loss indicator and a data non-retrieval loss indicator, the data retrieval loss indicator being indicative of a loss associated with retrieving the further data and the data non-retrieval loss indicator being indicative of a loss associated with not retrieving the further data; and
making a decision associated with the request based on a determinative request-based variable,
wherein, when the comparison indicates that the data retrieval loss outweighs the data non-retrieval loss:
the determination is not to retrieve the further data; and
the request-based variable is used as the determinative request-based variable, and
wherein, when the comparison indicates that the data non-retrieval loss outweighs the data retrieval loss:
the determination is to retrieve the further data;
the further data is retrieved;
the request-based variable is regenerated using the request data and the further data as inputs to the request-based variable generation model to generate a regenerated request-based variable; and
the regenerated request-based variable is used as the determinative request-based variable.