Patent ID: 12223056

DETAILED DESCRIPTION

In the following description, reference is made to the accompanying drawings that illustrate several examples of the present invention. It is understood that other examples may be utilized and various operational changes may be made without departing from the spirit and scope of the present disclosure. The following detailed description is not to be taken in a limiting sense, and the scope of the embodiments of the present invention is defined only by the claims of the issued patent.

Perpetrators of transactional fraud and other cyber-attacks continually attempt to modify their behavior and/or the characteristics of their attacks and/or fraudulent transactions in order to avoid detection by automated filters and/or machine learning models used to distinguish between potentially fraudulent transactions and non-fraudulent transactions. As a result, technologies are continuously developed by fraud prevention and cyber-security teams to attempt to detect and prevent such attacks in an ever-evolving climate. Accordingly, the actions of perpetrators of fraud and other cyber attacks and cyber security teams are adversarial in nature, as a change in attack detection techniques results in evolving attack methodologies, and vice versa.

In various examples, attackers modify network identifiers in order to mask the identity of the attacker and/or to make the attacks appear as though they are legitimate service requests. For example, attackers may modify phone numbers, internet protocol (IP) addresses, geo-location data, and/or other hierarchical data representations associated with attacks and/or fraudulent transactions in order to cyber attack prevention measures. In other examples, attackers may modify data associated with their account in order to avoid detection by automated detection systems and/or filters.

However, even such automated detection systems suffer shortcomings. For example, a typical automated network anomaly detection system may be a Boolean detection system indicating that action X has been performed Y (or more) times within Z timeframe. However, such linear detection systems require careful planning and/or empirical testing to determine the appropriate actions to measure and the appropriate thresholds for such actions. If thresholds are set too low (e.g., for a read action on sensitive data, for example) high false positives (low precision) can result, where legitimate actions are flagged and/or prevented, ultimately wasting resources to investigate such false positives. Conversely, if thresholds are set too high, anomalous actions and/or network attacks may slip through undetected (low recall). Abusive computational nodes may modify their behavior and/or their data to avoid detection by such automated detections systems.

Some common strategies for dealing with automated abuse detection include selection of a set of potentially abusive computational nodes for human investigation based on automated detection system results. After the investigations have occurred, known abusive computational nodes (e.g., computational nodes confirmed as abusive) are selected for enforcement actions (e.g., account suspension, termination of service and/or network access, etc.). However, while such techniques may be useful, they limit the coverage of computational node abuse detection for several reasons. First, there is a limited capacity for human investigation (e.g., time constraints) which means that all potentially-abusive computational nodes cannot be investigated in a meaningful time span. As such, conducted investigations generate a small number of confirmed abusive computational nodes (e.g., label data) and a large set of uninvestigated, potentially abusive computational nodes. Second, existing automated detection systems (e.g., machine learning classifiers and/or heuristic filters) typically operate at the individual entity level (e.g., determining whether a single computational node is risky or not based on the attributes of that computational node). However, described herein are graph-based techniques that consider risk evaluation of computational nodes at multiple levels of computational nodes and/or their actions, such as account holder ID, data generated by the account (e.g., web page data and/or form data), create, read, update, delete actions, unauthorized or unusual data access, exfiltration, unusual port usage, unauthorized and/or unusual scripting, etc. Human investigators are not only unable to determine such relationships at scale due to the large volume of information to be considered, but are also unable to determine relative levels of risk based on distant and/or multi-tiered relationships. Accordingly, the graph-based abusive computational node detection systems and techniques described herein are able to model high dimensional data to determine relationships between known good computational nodes and/or known abusive computational nodes and potentially risky nodes (e.g., computational nodes under evaluation). Upon determining that a particular computational node is abusive (with a high degree of confidence) an automated, programmatic action may be taken (e.g., terminating access of the computational node). Detection of abusive computational nodes can prevent network-based attacks on compute systems, networks, and services to prevent service disruption, data theft, and/or other malicious activity.

As used herein, computational nodes refers to entities having access to a compute service, a network accounts, data generated by such entities (e.g., data generated for hosting on an account generated for the computational node by a monitored service), actions taken by such entities (e.g., Create, Read, Update, and Delete (CRUD) operations), and/or attributes of such entities (e.g., account name, account actions, IP address, various identifier data, etc.).

FIG.1is a block diagram illustrating example components of a graph-based abusive computational node detection system102, according to various embodiments of the present disclosure. In various examples, one or more computing devices may implement the graph-based abusive computational node detection system102. In examples where more than one computing device implements the graph-based abusive computational node detection system102, the different computing devices may communicate with one another over a network105. In various examples, each of the one or more computing devices used to implement graph-based abusive computational node detection system102may comprise one or more processors. The one or more computing devices used to implement graph-based abusive computational node detection system102may be configured in communication with at least one non-transitory computer readable memory103(“memory103”). In at least some examples, the one or more computing devices used to implement graph-based abusive computational node detection system102may communicate with memory103over network105. The memory103may store computer-readable instructions that, when executed by at least one processor of the one or more computing devices implementing graph-based abusive computational node detection system102, may be effective to program the one or more processors to perform the various techniques described herein.

In various examples, network105is a wide area network, such as the Internet, while in other embodiments, the network105is a local area network (LAN) over which requests may be received. In some further embodiments network105is a combination of the Internet and a LAN.

Risky Candidate Computational Node Detection Component

In various examples, the graph-based abusive computational node detection system102may implement a risky candidate computational node detection component104. The risky candidate computational node detection component104may include an interface effective to receive input data (e.g., a comma-separated values (CSV) file) describing various computational nodes and their attributes. The attributes may have a plurality of dimensions. For example, attributes for a given computational node may include IP addresses and/or physical addresses associated with the computational node, account identifier data, uniform resource locators (URLs) associated with the computational node, data identifying data generated by the computational node using various compute services, type information describing a type of the computational node (e.g., a website, a particular account, a group of accounts, etc.). The risky candidate computational node detection component104may include logic effective to generate an input graph106of the computational nodes141connected by edges (e.g., connections between the computational nodes141) using the input data (e.g., a CSV file and/or other structured data representing the computational nodes and their respective attributes). As discussed above, computational nodes may represent multiple types of entities which may vary according to the enterprise implementing the graph-based abusive computational node detection system102. The edges indicate the shared and/or similar attribute among nodes. Computational nodes that have shared and/or sufficiently similar attribute values (as determined using a similarity matching algorithm) may be described as corresponding to one another (in the input graph106). Similarly, values that are shared and/or similar for computational nodes along a selected dimension may be described as corresponding values for the selected dimension(s). In general, the input data may be parsed along any desired dimension and/or set of dimensions to generate the input graph106. For example, in a particular implementation, an edge connecting two computational nodes in the input graph106may indicate that the two computational nodes share both a common IP address (and/or have a similar IP address) and/or account identifier data. Fuzzy matching may be used to determine similar values. Various approximate string matching/fuzzy matching techniques may be used (e.g., to determine a similarity between a computational node account name “JohnDoe123” and the computational node account name “JohnDo123”). Algorithms such as Levenshtein distance, Fuzzywuzzy, Soundex, Metaphone (for phonetic similarity), etc., may be used to determine similarity between attributes when constructing the input graph106. The input graph106may include some seed nodes that have known labels. These labeled computational nodes are a list of confirmed abusive entities (e.g., known malicious computational nodes) and/or confirmed non-abusive entities. Labeled computational nodes may be so labeled based on historic data (e.g., data indicating that a particular computational node is associated with unauthorized scripting, uploading of malicious code, etc.).

The risky candidate computational node detection component104may be effective to perform label propagation to propagate risk scores from the labeled computational nodes to non-labeled computational nodes based on their relationships and/or proximity in the input graph106. For example, using graph-based label propagation techniques (described in further detail below in reference toFIG.2) known risk labels (e.g., risk scores) may be propagated from labeled computational nodes to non-labeled computational nodes. A computational node that is closer to a labeled computational node (e.g., in terms of a number of hops) may have a propagated risk score that is more similar to the labeled abusive computational nodes relative to unlabeled computational nodes that are further away from the labeled abusive computational nodes, indicating a higher degree of risk that the unlabeled computational node is abusive.

As described in further detail below in reference toFIG.2, graph-based label propagation initializes the risky score of labelled abuse nodes as 1.0 and propagates their labels through the graph.FIG.2illustrates a single iteration; however, it should be noted that any number of iterations may be used to propagate labels through input graph106. The result of the graph-based label propagation is the generation of likely risk labels for all unlabeled nodes based on their similarity to and distances from seed nodes (e.g., the labeled nodes). After propagating the labels, the risky candidate computational node detection component104includes instructions effective to select candidate nodes from the unlabeled nodes with risk scores that are greater than (or equal to) certain pre-defined threshold risk scores. In some examples, the computational nodes with propagated risk scores greater than the predefined (e.g., F1 optimized) threshold risk score may be subject to an automated action such as account suspension, network access termination, account termination, removal of data from a server, etc.

The risky candidate computational node detection component104may include one or more machine learning models that may evaluate the input graph106to determine high risk candidates (e.g., after label propagation) at action108. For example, a subgraph may be extracted from input graph106for one or more candidate computational nodes of interest (e.g., all computational nodes representing accounts for a particular service in a bi-partite graph with account computational nodes and data computational nodes representing data generated by the accounts). The subgraph may include the candidate computational nodes of interest and their neighbors (e.g., all computational nodes within 1-hop) and may condense such graph neighborhood connectivity patterns into low-dimensional embeddings (e.g., numerical representations of the graph neighborhood connectivity patterns and/or graph nodes) for abuse detection using the machine learning architecture depicted and described in reference toFIG.3. Action108may compute updated risk scores of unlabeled computational nodes based on the embeddings of subgraphs for labeled nodes and unlabeled nodes of interest.

Interpretation Component

Interpretation component110may include instructions that may be used to generate interpretation information for risky candidates output by the risky candidate computational node detection component104. Interpretation information enables the graph-based abusive computational node detection system102to interpret how the risky candidates are selected by the risky candidate computational node detection component104and to rank different risky candidates in a prioritized order for remedial actions. Two sub-components are included in this module: the rank candidates component112and the update interpretation component114.

A subgraph inducing method is used by the interpretation component110to interpret why a computational node in the input graph106has been detected as risky candidate (e.g., the output of the risky candidate computational node detection component104after label propagation. The induced subgraph data (discussed in further detail below in reference toFIG.4) represents the paths in the input graph106that highlight how the risk score is propagated from confirmed abusive computational nodes to each newly-found potentially abusive candidate computational node. Typically, the subgraph tells which confirmed abusive computational nodes are vital to each risky candidate computational node and illustrates their interaction.

Before discussing how to generate the above-described induced subgraph data, the way in which the risky candidate computational nodes are selected after graph-based label propagation is first discussed. For label propagation graph models, the risky candidate computational nodes for investigation are selected from unlabeled entities i that satisfy the following condition:
risky score of nodei≥τwhere τ is the pre-defined threshold risk score.

Intuitively, for any risky candidate computational node, there should be some neighbors in the input graph106where the neighbor nodes are either confirmed abusive or highly risky (e.g., risky score≥τ). These neighbors are an essential one last hop in the risk propagation paths from some confirmed abusive computational nodes to this candidate computational nodes. For each of these neighbors, this process may be repeated to find its own neighbor with risky score≥τ to reconstruct the path. This process is repeated until a labeled node (e.g., a known abusive computational node) is found and the complete path is built. Note that this path describes how the labels of confirmed abusive computational nodes (labeled computational nodes) are propagated to the newly found candidate computational nodes (risky score≥τ), which therefore interprets the propagation process. Also, the paths support efficient investigation because only the nodes along the path should be examined to decide if the candidate is truly abusive or not. A theoretical proof for the induced subgraph is provided below in reference toFIG.4. The induced subgraph reduces the size of the input graph by more than 90% while preserving the risky propagation paths for every candidate abusive node.

The rank candidates component112may be used to prioritize investigation for candidate abusive nodes. For example, candidates with higher likelihood of being abusive may be prioritized for investigation and/or automated remedial actions. For example, the rank candidates component112may execute the graph-based label propagation method over the current induced subgraph and may re-rank all remaining candidate abusive nodes based on their updated risk score after label propagation. As the size of the induced subgraph is considerably reduced relative to the input graph106, online and low-latency label propagation may be completed in an efficient manner using the computer-implemented techniques described herein.

Update interpretation component114may be used to improve the accuracy of the interpretation information for ranking candidate computational nodes. The update interpretation component114may feed the investigation results into interpretation information generation. Typically, whenever the investigation for a batch of candidates (the size of batch is configurable in the system) is completed, the system updates the interpretation information in the induced subgraph. For example, for any computational node that is confirmed as being abusive, the risk score for the computational node may be updated to 1.0 in the induced subgraph. Otherwise, if a candidate is determined as non-abusive, the known non-abusive candidate may be removed from the induced subgraph together with all edges associated with the non-abusive computational node. Graph-based label propagation may be repeated for the updated induced subgraph to update the risk scores. Additionally, as described in further detail below, the graph-based abusive computational node detection system102adds the new ground truth labels into the labeled dataset used to train an improved classification model (discussed in further detail inFIG.4).

User Interface Visualization/Investigation Component

User interface visualization/investigation component116may provide various data visualizations and/or other tools that may be used to investigate potentially abusive computational nodes identified as candidates using the risky candidate computational node detection component104and the interpretation component110. For a given candidate computational node, the system allows different types of data to be queried and shows the query results as a plot. For example,

For example, user interface visualization/investigation component116may provide a node distribution plot. The node distribution plot (FIG.8) illustrates the locations of different type of nodes (e.g., candidate computational nodes, confirmed abusive computational nodes, confirmed non-abusive computational nodes). As the plot highlights the areas of candidate computational nodes that are more likely to be truly abusive investigation tools may use this density information for prioritization.

In another example, user interface visualization/investigation component116may provide a plot for k-hop neighbors of the candidate nodes (FIG.9). The plot for k-hop neighbors shows the connections between a candidate computational node and its neighbors. This plot helps the investigation when the investigation result of a candidate computational node (e.g., the “To be audited” node902) is determined by its neighbors (e.g., a computational node may be enforced only if the computational node contributes more than certain number of other computational nodes representing abusive data generated by that computational node). User interface visualization/investigation component116may provide a plot of the shortest path between the candidate computational node and a confirmed abusive computational node. The plot of shortest path between the candidate computational node and some confirmed abusive computational node (FIG.10) shows the interactions and risk propagation paths between them. This plot can help to verify the abuse propagation along the path.

In addition, the user interface visualization/investigation component116may provide access to external tools and/or data sources. For example, hyperlinks may be provided in a UI to link to the various data associated with a particular candidate abusive computational node and/or to external tools that may be used to provide information about the candidate abusive computational node. For example, external tools may be used to determine particular attribute values for data associated with a particular candidate abusive computational node.

FIG.2is a diagram illustrating an example of graph-based label propagation, in accordance with various embodiments of the present disclosure. Given a multi-partite input graph106, graph-based label propagation is used to propagate risk score from labeled computational nodes to related computational nodes in the input graph106.

The graph-based label propagation model generates risk scores for entities based on their relational linkages in a multi-partite graph. It can be considered as a belief propagation and implemented under a recursive matrix-vector multiplication formulation. In spite of the simplicity and computational efficiency, the multipartite label propagation model is highly scalable.

One fundamental difference between the multi-partite risk propagation and the classic single-partite lies in the propagation logic. Single-partite graph propagates the risk score label along shared attributes. In input graph106, each attribute serves as an edge in the graph. Though simple and clear, it can only support one class of entity node connected with single attribute type. Accordingly, the nodes in a single-partite graph represent a single entity type of computational node (e.g., webpage Uniform Resource Locators (URLs), IP addresses, city, account, etc.). Edges may represent an attribute along which the computational nodes are parsed (e.g., shared fingerprint, IP address, account, etc.).

Multi-partite graphs contain two types of nodes: entity node and attribute node. The risk score propagates between the connection between entity node and attribute node. The edge is a connecting relation between attribute and entity, instead of attribute itself. Accordingly, two entity nodes are only associated through the shared attribute nodes. As shown inFIG.2, entity computational nodes are never directly connected with an edge and are instead connected via attribute computational nodes. For example, entity computational nodes may be accounts and attribute computational nodes may be IP addresses.

The graph-based label propagation begins with a list of labeled abusive and/or non-abusive computational nodes, such as known bad actors that have taken non-permitted actions. These confirmed abuse computational nodes initialize the corresponding nodes' risk score as 1.0. The risk vectors for each node are then iteratively updated category by category.

Algorithm 1: Risk Propagation in Multipartite Graphfor t in 1, 2, ..., T:for q in ε:// update attribute risk vectors from entity risk vectors for p inand q ≠ p:{tilde over (ϕ)}p= Apq· ϕq// update current entity risk vector with all attribute vectors For pin:ϕq+= αt· wp· Aqp· {tilde over (ϕ)}p

Algorithm 1 summarizes the graph-based label propagation workflow. Here ε denotes the entity computational node set;denotes the attribute computational node set; {tilde over (ϕ)}p, ϕqare the risk vector of attribute computational nodes and entity computational nodes, respectively. wpis the weight for entity computational node p. α is an attenuation factor.

At each iteration, the risk vector of each entity computational node is updated concurrently. For each entity computational node, the associated risk vectors of attribute nodes are first updated with the entity risk vectors obtained from previous iteration. The entity risk vectors are then updated from related attribute risk vectors.

A major difference between the risk vector for attribute computational nodes and entity computational nodes is that the attribute risk vector is associated to particular entity computational node. It is not an intrinsic property of the attribute computational node. Even in the same iteration t, the updated attribute risk vector {tilde over (ϕ)}pvaries across different entity computational node q. On the contrary, the entity risk vector ϕqis only updated along the iteration steps. It is an intrinsic property of the entity computational node q.

FIG.3is a block diagram illustrating an example machine learning architecture for determining similarity at a computational node and graph level, in accordance with various aspects of the present disclosure. It should be noted that the architecture shown inFIG.3is but one example implementation of a machine learning architecture that may be used to determine similarity at both a computational node and a graph level. The architecture ofFIG.3may be varied in several respects according to the desired implementation. In various input graphs106there may be entity computational nodes (e.g., accounts) and attribute computational nodes (e.g., URLs representing data generated for a given account, IP addresses, etc.) and connections between the two. Abusive computational nodes may be identified based on their graph relationships to known abusive entities. In various examples, subgraph patterns may be used to identify such relationships and/or similarities.

The general methodology may include two steps, the subgraph embedding (both node and graph level) and graph-graph interactions.

First, because a particular computational node may be characterized by its data (with attributes of the data being represented by feature values), the first step may be to do a computational node-level and graph-level feature embedding. Graph Convolutional Networks (GCN) model is capable of encoding both graph structure and computational node features in a way useful for semi-supervised classification. A graph-level embedding is computed and node-level embeddings are aggregated using attention. The pairwise node comparison for two graphs may also be computed based on node-level embeddings.

Another goal of the architecture shown inFIG.3is to consider graph-graph interactions in order to calculate the similarity score between two graphs. Then an unlabeled graph may be labeled based on its similarity scores to a group labeled as abusive graphs and/or labeled as non-abusive graphs. This approach may be referred to herein as SimGNN (similarity graph neural network), which combines two strategies. First, a learnable embedding function is described that maps every graph into an embedding vector, which provides a global summary of a graph. A novel attention mechanism is proposed to emphasize the important nodes with respect to a specific similarity metric. Second, a pairwise node comparison method is used to supplement the graph-level embeddings with fine-grained node-level information. This model has a better generalization on unseen graphs, and in the worst case runs in quadratic time with respect to the number of nodes in two graphs.

The details for each step is as follows:

Graph Convolutional Networks (GCN). A multi-layer Graph Convolutional Network (GCN) is used with the following layer-wise propagation rule:

H(l+1)=σ⁡(D~-12⁢A~⁢D~-12⁢H(l)⁢W(l)).(3.1)

Here, Ã=A+INis the adjacency matrix of the undirected graph G with added self-connections. INis the identity matrix, {tilde over (D)}ii=ΣjÃijand W(l)is a layer-specific trainable weight matrix. σ(⋅) denotes an activation function, such as the ReLU(⋅)=max(0, ⋅). H(l)∈N×Dis the matrix of activations in the lthlayer; H(0)=X.

The graph convolution, which operates on the representation of a node and denoted as un∈D, may be formulated as:

conv⁢(un)=f1(∑m∈𝒩⁡(n)1dn⁢dm⁢um⁢W1(l)+b1(l))(3.2)where(n) is the set of the first-order neighbors of node n plus n itself, dnis the degree of node n plus 1, W1(l)∈Dl×Dl+1is the weight matrix associated with the l-th GCN layer, b1(l)∈Dl+1is the bias, and ƒ1(⋅) is an activation function such as ReLU(x)=max(0, x). Intuitively, the graph convolution operation aggregates the features from the first-order neighbors of the node.

SimGNN. The SimGNN is an end-to-end neural network based approach that attempts to learn a function to map a pair of graphs into a similarity score. The SimGNN is illustrated inFIG.3. First, the SimGNN transforms the computational node of each graph into a vector, encoding the features and structural properties around each node. Then, two strategies are proposed to model the similarity between the two graphs, one based on the interaction between two graph-level embeddings, the other based on comparing two sets of node-level embeddings. Finally, two strategies are combined together to feed into a fully connected neural network to get the final similarity score. The two strategies are described in additional detail below.

Graph-Level Embedding Interaction. This strategy is based on the assumption that a good graph-level embedding can encode the structural and feature information of a graph, and by interacting the two graph-level embeddings, the similarity between two graphs can be predicted. It involves the following stages: (1) the node embedding stage, which transforms each node of a graph into a vector, encoding its features and structural properties; (2) the graph embedding stage, which produces one embedding for each graph by attention-based aggregation of node embeddings generated in the previous stage; (3) the graph-graph interaction stage, which receives two graph-level embeddings and returns the interaction scores representing the graph-graph similarity; and (4) the final graph similarity score computation stage, which further reduces the interaction scores into one final similarity score. It will be compared against the ground-truth similarity score to update parameters involved in the 4 stages.

Stage I: Node Embedding. GCN learns an aggregation function (Eq. 3.2) that are representation-invariant and can be applied to unseen nodes. InFIG.3, different shading patterns represent different computational node types, and the original computational node representations are feature vector encoded. Notice that the feature vector encoding is based on computational node itself, so even if the node IDs are permuted, the aggregation results are the same. After multiple layers of GCNs (e.g., 3 layers inFIG.3), the computational node embeddings U are ready to be fed into the Attention module (Att), which is described as follows.

Stage II: Graph Embedding: Global Context-Aware Attention. To generate one embedding per graph using a set of computational node embeddings, the following attention mechanism is used to allow the model to learn weights guided by a selected similarity metric.

Denote the input node embeddings as U∈N×D, where the n-th row, un∈Dis the embedding of node n. First, a global graph context c∈Dis computed, which may be a simple average of node embeddings followed by a nonlinear transformation:

c=tanh⁡(1N⁢W2⁢∑n=1Nun)(3.3)where W2∈D×Dis a learnable weight matrix. The context c provides the global structural and feature information of the graph that is adaptive to the given similarity metric, via learning the weight matrix. Based on c, one attention weight for each node is computed. For node n, to make its attention anaware of the global context, the inner product between c and its node embedding is determined. The intuition is that, nodes similar to the global context should receive higher attention weights. A sigmoid function

σ⁡(x)=11+exp⁡(-x)
is applied to the result to ensure the attention weights is in the range (0, 1). The weights may not be normalized into length 1, since it is desirable to let the embedding norm reflect the graph size, which is essential for the task of graph similarity computation. Finally, the graph embedding h∈Dis the weighted sum of node embeddings, h=Σn=1Nanun. The following equation summarizes the proposed node attentive mechanism:

h=∑n=1Nf2(unT⁢c)⁢un=∑n=1Nf2(unT⁢tan⁢h⁡(1N⁢W2⁢∑m=1Num))⁢un(3.4)where ƒ2(⋅) is the sigmoid function σ(⋅).

Stage III: Graph-Graph Interaction: Neural Tensor Network. Neural Tensor Networks (NTN) may be used to model the relation between two graph-level embeddings:

g⁡(hi,hj)=f3(hiT⁢W3[1:K]⁢hj+V[ih]+b3)(3.5)where W3[1:K]∈D×D×Kis a weight tensor, [ ] denotes the concatenation operation, V∈K×2Dis a weight vector, b3∈Kis a bias vector, and ƒ3(⋅) is an activation function. K is a hyperparameter controlling the number of interaction (similarity) scores produced by the model for each graph embedding pair.

Stage IV: Graph Similarity Score Computation. After obtaining a list of similarity scores, a standard multi-layer fully-connected neural network is applied to gradually reduce the dimension of the similarity score vector. In the end, one score, s{circumflex over (i)}j∈, is predicted, and it is compared against the ground-truth similarity score using the following cross-entropy loss function:

ℒ=1❘"\[LeftBracketingBar]"𝒟❘"\[RightBracketingBar]"⁢∑(i,j)∈𝒟-(si,j⁢log⁡(s^i,j)+(si,j)⁢log⁢(1-s^i,j))(3.6)whereis the set of training graph pairs, and si,jis the ground-truth similarity betweeniandj.

Pairwise Node Comparison. To better use the node-level information, an additional step may be added in the graph-graph interactions by by-passing the NTN module, and using the node-level embeddings directly. This step may be used to supplement the graph-level features (graph features), which may lead to extra performance gain for the model.

As illustrated in the flow ofFIG.3, ifihas Ni nodes andjhas Njnodes, there would be NiNjpairwise interaction scores, obtained by S=σ(UiUjT), where Ui∈Ni×Dand Uj∈Nj×Dare the node embeddings ofiandj, respectively. Since the node-level embeddings are not normalized, the sigmoid function may be applied to ensure the similarities scores are in the range of (0, 1). For two graphs of different sizes, to emphasize their size difference, fake nodes may be padded to the smaller graph. As shown inFIG.3, two fake nodes with zero embedding are padded to the bottom graph, resulting in two extra columns with zeros in S (e.g., columns312). Denote N=max(N1, N2). The pairwise node similarity matrix S∈N×Nis a useful source of information, since it encodes fine-grained pairwise node similarity scores. Tts histogram features: hist(S)∈Bmay be extracted, where B is a hyperparameter that controls the number of bins in the histogram. In the case ofFIG.3, seven bins are used for the histogram (although other numbers of bins may be used in accordance with desired implementation). The histogram feature vector is normalized and concatenated with the graph-level interaction scores g(hi, hj), and fed to the fully connected layers to obtain a final similarity score for the graph pair.

Initial labeled training sets and testing sets may be used to generate an initial model for the architecture ofFIG.3. However, in some cases, the output detected results may be sent to investigators that may generate additional label annotations. As more confirmed true abusive computational nodes and/or non-abusive computational nodes, the new datasets may be returned to the model pipeline and used to update the parameters, improving model performance.

FIG.4is a block diagram illustrating a recursive graph-based method for detection of abusive computational nodes, in accordance with various aspects of the present disclosure. Risky candidate computational node detection component104may output candidate abusive computational nodes306. The candidate abusive computational nodes306may be determined using the machine learning architecture described above in reference toFIG.3.

To interpret why a computational node in the input graph106is detected as a risky candidate computational node when the label propagation is adopted for risky candidate generation, an induced subgraph is generated (induced subgraph generation302) to find the paths that highlight how the risk is propagated from confirmed abusive computational nodes to each newly found abusive candidate computational node. Typically, this subgraph tells which confirmed abusive computational nodes are vital to each risky candidate and illustrates their interaction.

Intuitively, for any risky candidate (e.g., a potentially abusive computational node), there should be some neighbors (e.g., URLs and/or other attributes associated with an abusive account) where the neighbor computational nodes are either confirmed abusive or highly risky (i.e., risk score≥τ). These neighbors are essential one last hop in the risk propagation paths from some confirmed abusive computational nodes to the candidate. For each of these neighbors, this process is repeated to find its own neighbor with risk score≥τ, to reconstruct the path. This process is repeated until a labeled computational node is found (e.g., a computational node with risk score=1) and the complete path is built. Note that this path describes how the labels of confirmed abuse entities (labeled computational nodes) are propagated to the newly found candidates (risky score≥τ), which therefore interprets the propagation process. Also, the paths provide the clue for support efficient investigation because only the nodes along the path may be examined to determine if the candidate computational node is truly abusive or not.

[Theorem] For any node i with risky score≥τ, there is at least one path that starts from a labeled computational node (i.e., risk score=1.0) and ends with the computational node i, where the risk scores of all other computational nodes j in the path are not less than the threshold τ.

Proof: Assuming the input graph is a bi-partite graph with two types of nodes (e.g., accounts and IP addresses). Initially, some computational nodes are labeled (e.g., a list of confirmed abusive accounts) and initialized with risk score 1.0, while all other unlabeled computational nodes are initialized with risk score 0.0. Then, the propagation method repeats the following process for updating risk scores until coverage:
θ=ARΦ;
Φ=λACθ+(1−λ)Φwhere A=aijis the m×n adjacency matrix, with m rows (e.g., accounts) and n column (e.g., IP addresses)AR: Row-normalized adjacency matrix (m×n)AC: Column-normalized adjacency matrix and transposed (n×m)Φ: The vector of risky scores for the first type of nodes (i.e., n×1 ASIN risky score vector)θ: The vector of risky scores for the second type of nodes (i.e., m×1 Seller risky score vector)λ: Blending weight (0≤λ≤1)

Case 1: If computational node i belongs to the second type of computational nodes, its risk score is computed by the equationθ=ARΦ. Typically, the risk score of computational node i is the dot product of the i-row of ARand the vectorΦ. Considering ARis the row-normalized adjacency matrix with all values being [0, 1], there is at least one item inΦwith score≥τ when the dot product is ≥τ. In other words, there is at least one neighbor node for computational node i has risk score≥τ.

Case 2: If computational node i belongs to the first type of computational nodes, its risk score is computed by the equationΦ=λACθ+(1−λ)Φ. It can be reformulated asΦ=λACθ. Therefore, the risk score of node i is the dot product of the i-row of Acand the vectorθ, followed by the multiplication of a factor λ. Considering that 0≤λ≤1, the dot product of the i-row of Acand the vectorθmust be ≥τ if the risk score of computational node i≥τ. Considering all values of ACbeing [0, 1], there is at least one item inθwith score≥τ when the dot product is ≥τ. In other words, there is at least one neighbor computational node of node i has risky score≥τ. This proof also holds for label propagation over uni-partite graph, multi-partite graph, and directed graph.

After generating the induced subgraph, label propagation over the induced subgraph304may be performed and may rank all remaining candidate computational nodes based on their updated risk scores after label propagation. As the size of the induced subgraph is significantly reduced, such on-line label propagation may be efficiently completed. In various examples, a classifier may be trained to perform classification over graph features308.

For every candidate computational node to be investigated, the interpretation component110may extract various graph features (e.g., Degree Centrality, Eigenvector Centrality, Local Clustering Coefficient, Shortest Distances from Confirmed Abusive Nodes, Number of Confirmed Abusive Nodes within k-hop, etc.) and may leverage historical investigation results to train a supervised classification model. The model predicts the probability of a candidate to be abusive. The system ranks all candidate computational nodes based on their classification result.

Investigation results included in investigation data316(e.g., investigation results of investigations of highly-ranked candidate computational nodes) may be used to update induced subgraph labels (action310) and may also be used to provide additional labeled training data for training the classifiers (e.g., as updated ground truth data). For example, whenever the investigation for a batch of candidate computational nodes (the size of batch is configurable in the system) is completed, the system may updates the interpretation information (adopted in candidate ranking). For example, for label propagation over the induced subgraph, for every computational node in the batch, if the candidate computational node is confirmed as abusive (e.g., during investigation), the system updates its label to 1.0 in the induced subgraph; otherwise, the system removes this computational node from the induced subgraph and deletes all edges associated with it. In this way, the system utilizes the real-time investigation results to update the induced subgraph for better ranking of remaining candidates.

Additionally, for classification over graph features308, the system adds the batch of investigated nodes into the labelled dataset collected from historical investigation. The augmented dataset enables the training of an improved classification model.

FIG.5is a block diagram showing an example architecture500of a computing device that may be configured to perform graph-based detection of abusive computational nodes, in accordance with various aspects of the present disclosure. It will be appreciated that not all devices will include all of the components of the architecture500and some user devices may include additional components not shown in the architecture500. The architecture500may include one or more processing elements504for executing instructions and retrieving data stored in a storage element502. The processing element504may comprise at least one processor. Any suitable processor or processors may be used. For example, the processing element504may comprise one or more digital signal processors (DSPs). The storage element502can include one or more different types of memory, data storage, or computer-readable memory devoted to different purposes within the architecture500. For example, the storage element502may comprise flash memory, random-access memory, disk-based storage, etc. Different portions of the storage element502, for example, may be used for program instructions for execution by the processing element504, storage of images or other digital works, and/or a removable storage for transferring data to other devices, etc. Additionally, storage element502may store machine learned models, parameters thereof, and/or hierarchical data representations.

The storage element502may also store software for execution by the processing element504. An operating system522may provide the user with an interface for operating the computing device and may facilitate communications and commands between applications executing on the architecture500and various hardware thereof. A transfer application524may be configured to receive images, audio, and/or video from another device (e.g., a mobile device, image capture device, and/or display device) or from an image sensor and/or microphone570included in the architecture500.

When implemented in some user devices, the architecture500may also comprise a display component506and/or be configured in communication with one or more external display components506. The display component506may comprise one or more light-emitting diodes (LEDs) or other suitable display lamps. Also, in some examples, the display component506may comprise, for example, one or more devices such as cathode ray tubes (CRTs), liquid-crystal display (LCD) screens, gas plasma-based flat panel displays, LCD projectors, raster projectors, infrared projectors or other types of display devices, etc.

The architecture500may also include one or more input devices508operable to receive inputs from a user. The input devices508can include, for example, a push button, touch pad, touch screen, wheel, joystick, keyboard, mouse, trackball, keypad, light gun, game controller, or any other such device or element whereby a user can provide inputs to the architecture500. These input devices508may be incorporated into the architecture500or operably coupled to the architecture500via wired or wireless interface. In some examples, architecture500may include a microphone or an array of microphones for capturing sounds, such as voice requests and/or natural language inputs.

When the display component506includes a touch-sensitive display, the input devices508can include a touch sensor that operates in conjunction with the display component506to permit users to interact with the image displayed by the display component506using touch inputs (e.g., with a finger or stylus). The architecture500may also include a power supply514, such as a wired alternating current (AC) converter, a rechargeable battery operable to be recharged through conventional plug-in approaches, or through other approaches such as capacitive or inductive charging.

The communication interface512may comprise one or more wired or wireless components operable to communicate with one or more other computing devices. For example, the communication interface512may comprise a wireless communication module536configured to communicate on a network, such as the network105, according to any suitable wireless protocol, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 or another suitable wireless local area network (WLAN) protocol. A short range interface534may be configured to communicate using one or more short range wireless protocols such as, for example, near field communications (NFC), Bluetooth, Bluetooth LE, etc. A mobile interface540may be configured to communicate utilizing a cellular or other mobile protocol. A Global Positioning System (GPS) interface538may be in communication with one or more earth-orbiting satellites or other suitable position-determining systems to identify a position of the architecture500. A wired communication module542may be configured to communicate according to the universal serial bus (USB) protocol or any other suitable protocol.

The architecture500may also include one or more sensors530such as, for example, one or more position sensors, image sensors, and/or motion sensors. As noted above, multiple devices may be employed in a single system. In such a multi-device system, each of the devices may include different components for performing different aspects of the system's processing. The multiple devices may include overlapping components.

An example system for sending and providing data and performing graph-based detection of abusive computational nodes will now be described in detail. In particular,FIG.6illustrates an example computing environment in which the embodiments described herein may be implemented. For example, the computing environment ofFIG.6may be configured to perform graph-based detection of abusive computational nodes as a service over a network wherein one or more of the techniques described herein may be requested by a first computing device and may be performed by a different computing device configured in communication with the first computing device over a network.FIG.6is a diagram schematically illustrating an example of a data center65that can provide computing resources to users60aand60b(which may be referred herein singularly as user60or in the plural as users60) via user computers62aand62b(which may be referred herein singularly as user computer62or in the plural as user computers62) via network105. Data center65may be configured to provide computing resources for executing applications on a permanent or an as-needed basis. The computing resources provided by data center65may include various types of resources, such as gateway resources, load balancing resources, routing resources, networking resources, computing resources, volatile and non-volatile memory resources, content delivery resources, data processing resources, data storage resources, data communication resources, and the like. Each type of computing resource may be available in a number of specific configurations. For example, data processing resources may be available as virtual machine instances that may be configured to provide various web services. In addition, combinations of resources may be made available via a network and may be configured as one or more web services. The instances may be configured to execute applications, including web services, such as application services, media services, database services, processing services, gateway services, storage services, routing services, security services, encryption services, load balancing services, application services, and the like. In various examples, the instances may be configured to execute one or more of the various graph-based detection of abusive computational node techniques described herein.

These services may be configurable with set or custom applications and may be configurable in size, execution, cost, latency, type, duration, accessibility, and in any other dimension. These web services may be configured as available infrastructure for one or more clients and can include one or more applications configured as a platform or as software for one or more clients. These web services may be made available via one or more communications protocols. These communications protocols may include, for example, hypertext transfer protocol (HTTP) or non-HTTP protocols. These communications protocols may also include, for example, more reliable transport layer protocols, such as transmission control protocol (TCP), and less reliable transport layer protocols, such as user datagram protocol (UDP). Data storage resources may include file storage devices, block storage devices, and the like.

Each type or configuration of computing resource may be available in different sizes, such as large resources—consisting of many processors, large amounts of memory and/or large storage capacity—and small resources—consisting of fewer processors, smaller amounts of memory, and/or smaller storage capacity. Customers may choose to allocate a number of small processing resources as web servers and/or one large processing resource as a database server, for example.

Data center65may include servers66aand66b(which may be referred herein singularly as server66or in the plural as servers66) that provide computing resources. These resources may be available as bare metal resources or as virtual machine instances68a-d(which may be referred herein singularly as virtual machine instance68or in the plural as virtual machine instances68). In at least some examples, server manager67may control operation of and/or maintain servers66. Virtual machine instances68cand68dare rendition switching virtual machine (“RSVM”) instances. The RSVM virtual machine instances68cand68dmay be configured to perform all, or any portion, of the techniques for improved rendition switching and/or any other of the disclosed techniques in accordance with the present disclosure and described in detail above. As should be appreciated, while the particular example illustrated inFIG.6includes one RSVM virtual machine in each server, this is merely an example. A server may include more than one RSVM virtual machine or may not include any RSVM virtual machines.

The availability of virtualization technologies for computing hardware has afforded benefits for providing large scale computing resources for customers and allowing computing resources to be efficiently and securely shared between multiple customers. For example, virtualization technologies may allow a physical computing device to be shared among multiple users by providing each user with one or more virtual machine instances hosted by the physical computing device. A virtual machine instance may be a software emulation of a particular physical computing system that acts as a distinct logical computing system. Such a virtual machine instance provides isolation among multiple operating systems sharing a given physical computing resource. Furthermore, some virtualization technologies may provide virtual resources that span one or more physical resources, such as a single virtual machine instance with multiple virtual processors that span multiple distinct physical computing systems.

Referring toFIG.6, network105may, for example, be a publicly accessible network of linked networks and possibly operated by various distinct parties, such as the Internet. In other embodiments, network105may be a private network, such as a corporate or university network that is wholly or partially inaccessible to non-privileged users. In still other embodiments, network105may include one or more private networks with access to and/or from the Internet.

Network105may provide access to user computers62. User computers62may be computers utilized by users60or other customers of data center65. For instance, user computer62aor62bmay be a server, a desktop or laptop personal computer, a tablet computer, a wireless telephone, a personal digital assistant (PDA), an e-book reader, a game console, a set-top box, or any other computing device capable of accessing data center65. User computer62aor62bmay connect directly to the Internet (e.g., via a cable modem or a Digital Subscriber Line (DSL)). Although only two user computers62aand62bare depicted, it should be appreciated that there may be multiple user computers.

User computers62may also be utilized to configure aspects of the computing resources provided by data center65. In this regard, data center65might provide a gateway or web interface through which aspects of its operation may be configured through the use of a web browser application program executing on user computer62. Alternately, a stand-alone application program executing on user computer62might access an application programming interface (API) exposed by data center65for performing the configuration operations. Other mechanisms for configuring the operation of various web services available at data center65might also be utilized.

Servers66shown inFIG.6may be servers configured appropriately for providing the computing resources described above and may provide computing resources for executing one or more web services and/or applications. In one embodiment, the computing resources may be virtual machine instances68. In the example of virtual machine instances, each of the servers66may be configured to execute an instance manager63aor63b(which may be referred herein singularly as instance manager63or in the plural as instance managers63) capable of executing the virtual machine instances68. The instance managers63may be a virtual machine monitor (VMM) or another type of program configured to enable the execution of virtual machine instances68on server66, for example. As discussed above, each of the virtual machine instances68may be configured to execute all or a portion of an application.

It should be appreciated that although the embodiments disclosed above discuss the context of virtual machine instances, other types of implementations can be utilized with the concepts and technologies disclosed herein. For example, the embodiments disclosed herein might also be utilized with computing systems that do not utilize virtual machine instances.

In the example data center65shown inFIG.6, a router61may be utilized to interconnect the servers66aand66b. Router61may also be connected to gateway64, which is connected to network105. Router61may be connected to one or more load balancers, and may, alone or in combination, manage communications within networks in data center65, for example, by forwarding packets or other data communications as appropriate based on characteristics of such communications (e.g., header information including source and/or destination addresses, protocol identifiers, size, processing requirements, etc.), and/or the characteristics of the private network (e.g., routes based on network topology, etc.). It will be appreciated that, for the sake of simplicity, various aspects of the computing systems and other devices of this example are illustrated without showing certain conventional details. Additional computing systems and other devices may be interconnected in other embodiments and may be interconnected in different ways.

In the example data center65shown inFIG.6, a data center65is also employed to at least in part direct various communications to, from and/or between servers66aand66b. WhileFIG.6depicts router61positioned between gateway64and data center65, this is merely an exemplary configuration. In some cases, for example, data center65may be positioned between gateway64and router61. Data center65may, in some cases, examine portions of incoming communications from user computers62to determine one or more appropriate servers66to receive and/or process the incoming communications. Data center65may determine appropriate servers to receive and/or process the incoming communications based on factors such as an identity, location, or other attributes associated with user computers62, a nature of a task with which the communications are associated, a priority of a task with which the communications are associated, a duration of a task with which the communications are associated, a size and/or estimated resource usage of a task with which the communications are associated, and many other factors. Data center65may, for example, collect or otherwise have access to state information and other information associated with various tasks in order to, for example, assist in managing communications and other operations associated with such tasks.

It should be appreciated that the network topology illustrated inFIG.6has been greatly simplified and that many more networks and networking devices may be utilized to interconnect the various computing systems disclosed herein. These network topologies and devices should be apparent to those skilled in the art.

It should also be appreciated that data center65described inFIG.6is merely illustrative and that other implementations might be utilized. It should also be appreciated that a server, gateway or other computing device may comprise any combination of hardware or software that can interact and perform the described types of functionality, including without limitation: desktop or other computers, database servers, network storage devices and other network devices, PDAs, tablets, cellphones, wireless phones, pagers, electronic organizers, Internet appliances, television-based systems (e.g., using set top boxes and/or personal/digital video recorders), and various other consumer products that include appropriate communication capabilities.

A network set up by an entity, such as a company or a public sector organization, to provide one or more web services (such as various types of cloud-based computing or storage) accessible via the Internet and/or other networks to a distributed set of clients may be termed a provider network. Such a provider network may include numerous data centers hosting various resource pools, such as collections of physical and/or virtualized computer servers, storage devices, networking equipment and the like, configured to implement and distribute the infrastructure, and web services offered by the provider network. The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services, and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of central processing unit (CPU), the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor).

A number of different types of computing devices may be used singly or in combination to implement the resources of the provider network in different embodiments, for example, computer servers, storage devices, network devices, and the like. In some embodiments, a client or user may be provided direct access to a resource instance, e.g., by giving a user an administrator login and password. In other embodiments, the provider network operator may allow clients to specify execution requirements for specified client applications and schedule execution of the applications on behalf of the client on execution platforms (such as application server instances, Java™ virtual machines (JVMs), general-purpose or special-purpose operating systems, platforms that support various interpreted or compiled programming languages such as Ruby, Perl, Python, C, C++, and the like, or high-performance computing platforms) suitable for the applications, without, for example, requiring the client to access an instance or an execution platform directly. A given execution platform may utilize one or more resource instances in some implementations; in other implementations, multiple execution platforms may be mapped to a single resource instance.

In many environments, operators of provider networks that implement different types of virtualized computing, storage and/or other network-accessible functionality may allow customers to reserve or purchase access to resources in various resource acquisition modes. The computing resource provider may provide facilities for customers to select and launch the desired computing resources, deploy application components to the computing resources and maintain an application executing in the environment. In addition, the computing resource provider may provide further facilities for the customer to quickly and easily scale up or scale down the numbers and types of resources allocated to the application, either manually or through automatic scaling, as demand for or capacity requirements of the application change. The computing resources provided by the computing resource provider may be made available in discrete units, which may be referred to as instances. An instance may represent a physical server hardware platform, a virtual machine instance executing on a server or some combination of the two. Various types and configurations of instances may be made available, including different sizes of resources executing different operating systems (OS) and/or hypervisors, and with various installed software applications, runtimes and the like. Instances may further be available in specific availability zones, representing a logical region, a fault tolerant region, a data center or other geographic location of the underlying computing hardware, for example. Instances may be copied within an availability zone or across availability zones to improve the redundancy of the instance, and instances may be migrated within a particular availability zone or across availability zones. As one example, the latency for client communications with a particular server in an availability zone may be less than the latency for client communications with a different server. As such, an instance may be migrated from the higher latency server to the lower latency server to improve the overall client experience.

In some embodiments, the provider network may be organized into a plurality of geographical regions, and each region may include one or more availability zones. An availability zone (which may also be referred to as an availability container) in turn may comprise one or more distinct locations or data centers, configured in such a way that the resources in a given availability zone may be isolated or insulated from failures in other availability zones. That is, a failure in one availability zone may not be expected to result in a failure in any other availability zone. Thus, the availability profile of a resource instance is intended to be independent of the availability profile of a resource instance in a different availability zone. Clients may be able to protect their applications from failures at a single location by launching multiple application instances in respective availability zones. At the same time, in some implementations inexpensive and low latency network connectivity may be provided between resource instances that reside within the same geographical region (and network transmissions between resources of the same availability zone may be even faster).

FIG.7is a flow diagram illustrating another example process700for graph-based abusive computational node detection, in accordance with various aspects of the present disclosure. The process700ofFIG.7may be executed by one or more computing devices. The actions of process700may represent a series of instructions comprising computer-readable machine code executable by a processing unit of a computing device. In various examples, the computer-readable machine code may be comprised of instructions selected from a native instruction set of the computing device and/or an operating system of the computing device. Various actions in process700may be described above with reference to elements ofFIGS.1-6.

Process700may being at action702, at which first input data describing a first plurality of computational nodes may be received. Additionally, first data identifying one or more dimensions along which to parse the first plurality of computational nodes may be received. For example, the first data may instruct a graph-building algorithm to generate a graph in which each computational node sharing a first attribute (e.g., IP address) may be connected in the graph. In some examples, multiple attributes may be used to parse the first plurality of computational nodes. For example, the first data may instruct that nodes sharing data associating the computational node with a first city and a first IP address be connected in the graph.

Processing may continue at action704, at which a first computing device may generate input graph data representing the first plurality of computational nodes. The nodes that share the same or a similar value for the dimension may be connected to one another in the input graph data. At action706, computational nodes having a known risk label indicating past abuse may be determined. For example, a first compute node having a known risk label indicating past abuse (e.g., a labeled computational node) may be determined. At action708, risk scores for unlabeled computational nodes of the first plurality of computational nodes may be determined using graph-based label propagation. For example, a first risk score for an unlabeled computational node of the first plurality of computational nodes may be determined using graph-based label propagation as described above. Although not shown inFIG.7, a subgraph embedding (e.g., embedding data) may be extracted for the first computational node and may be used to determine a similarity between the first computational node and a labeled known that is known to be abusive.

At action710, induced subgraphs may be determined. For example, an induced subgraph for the first computational node may be determined by connecting a path to a labeled known abusive node from the first computational node. At action712, updated risk scores may be determined for the induced subgraphs. For example, graph-based label propagation may be performed on the induced subgraph to generate updated risk scores for the computational nodes of the induced subgraph. At action714, computational nodes of the induced subgraph may be ranked according to the updated risk scores. At action716, a remedial action may be determined for a computational node of the induced subgraph based at least in part on the updated risk scores. Investigation and/or other remedial action results may be used to update risk scores and/or training data used to train classifier models.

Although the flowcharts and methods described herein may describe a specific order of execution, it is understood that the order of execution may differ from that which is described. For example, the order of execution of two or more blocks or steps may be scrambled relative to the order described. Also, two or more blocks or steps may be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks or steps may be skipped or omitted. It is understood that all such variations are within the scope of the present disclosure.

Also, any logic or application described herein that comprises software or code can be embodied in any non-transitory computer-readable medium or memory for use by or in connection with an instruction execution system such as a processing component in a computer system. In this sense, the logic may comprise, for example, statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system. The computer-readable medium can comprise any one of many physical media such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable media include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium may be a random access memory (RAM) including, for example, static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.

It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications may be made to the above-described example(s) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.