Abstract: A genetic algorithm (GA) in combination with a random decision forest can be used to identify a feature subset related to an observed incident. The GA is used to select feature subsets for which data samples are obtained to train and test random decision forests per individual feature subset (“individual”) with respect to an observed incident. For each generation of a GA run, fitness values of the individuals are determined based on the testing of the corresponding random decision forest. At termination of the GA run, an individual representing a feature subset is identified as likely most related to the observed incident. The trained random decision forest corresponding to the individual or a subset of the trained random decision forest is used to predict or classify whether live values of the fittest feature subset indicate the observed incident.

Abstract: An apparatus includes a sensor circuit and a wireless communication interface. The sensor circuit may periodically sense a value for a particular environmental variable. The wireless communication interface may update a dynamic address for the apparatus based on the periodically sensed value, and receive a query from a base station. The query may include a conditional address corresponding to the particular environmental variable. In response to a first comparison of the conditional address to a current dynamic address, the wireless communication interface may send a reply to the base station indicating whether the query has matched for the apparatus. The reply to the query may be performed without requesting a reading of the particular environmental variable from the sensor circuit.

Abstract: Techniques are disclosed relating to serving an electronic search warrant. In some embodiments, a computer system accesses a blockchain including an electronic warrant that authorizes access to a controlled device having confidential data. The computer system sends a request for the confidential data to the controlled device, the request identifying the electronic warrant. The computer system receives the confidential data from the controlled device and appends a first record to a second record in blockchain. The first record includes the confidential data, a first digital signature generated from the contents of the first record, and a second digital signature obtained from the second record. In some embodiments, the computer system sends a request for the electronic warrant to a second computer system associated with a court. The request identifies a public key for inclusion in the electronic warrant and having a private key to generate the first digital signature.

Abstract: Techniques are disclosed relating to a computer system receiving recordings of meetings between individuals, encrypting the recording, storing the encrypted recording, and determining whether to decrypt the encrypted recording based on decryption information indicative of ones of the individuals have assented to the decryption of the encrypted recording and a cryptographic policy. The computer system may also perform semantic analysis of the audio of the meeting to identify decision statements made at the meeting and factor statements made at the meeting upon which the decision statement is based. The computer system may also store meeting metadata associated with the meeting that is indicative of the decision statement and factor statements.

Abstract: A system for managing application performance performs a learning phase and a monitoring phase. One embodiment of the learning phase comprises monitoring performance of multiple components of a software system to create first monitored component data for the multiple components and automatically identifying correlation between the components and a performance metric based on the first monitored data. The monitoring phase comprises monitoring performance of the multiple components of the software system to create second monitored component data for the multiple components, using the identified correlation to predict the performance metric, calculating the actual performance metric based on the second monitored component data, and reporting a performance problem if the actual performance metric differs from the predicted performance metric by more than a threshold.

Abstract: For each event detected during execution of a monitored application comprising a plurality of application components, a determination is made of which of the plurality of application components corresponds to the detected event. Also, a dependency subgroup that includes the application component that corresponds to the detected event is identified, wherein a dependency subgroup indicates dependencies among a subgroup of the plurality of application components. A location within the dependency subgroup of the application component corresponding to the detected event is determined. An order of correction for the application components determined to correspond to detected events are determined based, at least in part, on the determined location. Correction of the application components determined to correspond to detected events are initiated according to the determined order of correction.

Abstract: For each event detected during execution of a monitored application comprising a plurality of application components, a determination is made of which of the plurality of application components corresponds to the detected event. Also, a dependency subgroup that includes the application component that corresponds to the detected event is identified, wherein a dependency subgroup indicates dependencies among a subgroup of the plurality of application components. A location within the dependency subgroup of the application component corresponding to the detected event is determined. An order of correction for the application components determined to correspond to detected events are determined based, at least in part, on the determined location. Correction of the application components determined to correspond to detected events are initiated according to the determined order of correction.

Abstract: A dependency graph is created that indicates dependencies among a plurality of components of an application based, at least in part, on interactions among the plurality of components determined from at least one execution of the application. In response to selection of a first attribute of a plurality of attributes, the plurality of components are differentiated into a first plurality of sets of the plurality of components based, at least in part, on having values in common for the first attribute. Dependencies among the first plurality of sets of components are determined based, at least in part, on the dependency graph. A first attribute based perspective of the application is determined, wherein the first attribute based perspective comprises a graphical container for each of the first plurality of sets of components and graphical connections between the graphical containers corresponding to the dependencies among the first plurality of sets of components.

Abstract: An application performance monitoring system monitors a system having multiple components, automatically calculates a performance metric for the system, and determines a relationship between components of the software system that effect the performance metric. The system is configured to automatically generate a model of behavior of the performance metric using a genetic search process that randomly creates a set of functions and evolves those functions over multiple generations with evolution being skewed by a rule based on the determined relationship between components.

Abstract: A system for managing application performance performs a learning phase and a monitoring phase. One embodiment of the learning phase comprises monitoring performance of multiple components of a software system to create first monitored component data for the multiple components and automatically identifying correlation between the components and a performance metric based on the first monitored data. The monitoring phase comprises monitoring performance of the multiple components of the software system to create second monitored component data for the multiple components, using the identified correlation to predict the performance metric, calculating the actual performance metric based on the second monitored component data, and reporting a performance problem if the actual performance metric differs from the predicted performance metric by more than a threshold.

Abstract: An application performance monitoring system monitors a system having multiple components, automatically calculates a performance metric for the system, and determines a relationship between components of the software system that effect the performance metric. The system is configured to automatically generate a model of behavior of the performance metric using a genetic search process that randomly creates a set of functions and evolves those functions over multiple generations with evolution being skewed by a rule based on the determined relationship between components.

Abstract: A two-pass technique for instrumenting an application is disclosed. One pass may be performed statically by analyzing the application and inserting probes while the application is not running. Another pass may be performed dynamically by analyzing data collected by the probes while the application runs to derive metrics for the probes. One or more metrics for each probe may be analyzed to determine whether to dynamically modify the probe. By dynamically modifying the probe, the application does not need to be shut down. Dynamically modifying the probe could include removing the probe from the application or moving the probe to another component (e.g., method) in the application, as examples. For example, the probe might be moved to a component that is either up or down the call graph from the component that the probe is presently in.

Abstract: A benchmark response time is determined for a browser application request sent to a network server over a network. The response time is determined by performance monitoring code that is loaded into and monitors the browser application from the client. The performance monitoring code automatically sends a request to a network server; the request is not sent in response to user input. The network server receives the request, generates a response and provides the response to the browser application. The response includes a fixed amount of randomly generated data. The browser application receives and processes the response, but does not display the bytes or change the content displayed in the browser application as a result of the response. The browser application sends the times at which the browser application sends the request and the browser application completes processing the response data to the network server for further processing.

Abstract: Capacity planning is performed based on expected transaction load and the resource utilization for each expected transaction. Resource usage is determined for one or more transactions or URLs based on transaction specific and non-transaction specific resource usage. Once the resource usage for each transaction is known, the expected resource usage may be determined for an expected quantity of each transaction. The actual resources needed to meet the expected resource usage are then determined. Resources may include hardware or software, such as a central processing unit, memory, hard disk bandwidth, network bandwidth, and other computing system components. The expected resource usage for a transaction may based on the usage directly related to the transaction and usage not directly related to the transaction but part of a process associated with the performed transactions.

Abstract: Capacity planning based on resource utilization as a function of workload is disclosed. The workload may include different types of requests such as login requests, requests to visit web pages, requests to purchase an item on an online shopping site, etc. In one embodiment, data is determined for each of a plurality of workloads. The data includes characteristics of a workload and resource utilization due at least in part processing that workload. Based on the data, utilization of each of the resources as a function of workload characteristics is estimated. Further, based on the estimated resource utilization, workload characteristics that are expected to cause each respective resource to reach a certain level are predicted. That level could be 100 percent utilization, but could be another level. Capacity planning is performed based on the workload characteristics that are expected to cause each respective resource to reach a certain level.

Abstract: Network performance is monitored using timing information retrieved from a client device, server in communication with the client, or both. Client side timing information is retrieved using performance monitoring code provided by the server. The code may be provided to the client as part of a content response. Once content in the provided content response is loaded, the code sends the timing information to the server. The server may then process the timing information to calculate response time and other time information metrics.

Abstract: A two-pass technique for instrumenting an application is disclosed. One pass may be performed statically by analyzing the application and inserting probes while the application is not running. Another pass may be performed dynamically by analyzing data collected by the probes while the application runs to derive metrics for the probes. One or more metrics for each probe may be analyzed to determine whether to dynamically modify the probe. By dynamically modifying the probe, the application does not need to be shut down. Dynamically modifying the probe could include removing the probe from the application or moving the probe to another component (e.g., method) in the application, as examples. For example, the probe might be moved to a component that is either up or down the call graph from the component that the probe is presently in.

Abstract: Network performance is monitored using timing information retrieved from a client device, server in communication with the client, or both. Client side timing information is retrieved using performance monitoring code provided by the server. The code may be provided to the client as part of a content response. Once content in the provided content response is loaded, the code sends the timing information to the server. The server may then process the timing information to calculate response time and other time information metrics.

Abstract: Network performance is monitored using timing information retrieved from a client device, server in communication with the client, or both. Client side timing information is retrieved using performance monitoring code provided by the server. The code may be provided to the client as part of a content response. Once content in the provided content response is loaded, the code sends the timing information to the server. The server may then process the timing information to calculate response time and other time information metrics.

Abstract: Deviation of expected response times is used to characterize the health of one or more backend machines invoked by an application to process a request. Performance data generated in response to monitoring application execution is processed to select backend response time data. The selected data is processed to predict future values of a time series associated with backend response time. The predicted response time values are compared to actual response time values in the time series to determine a deviation from the predicted value. Deviation information for the time series data of response times is then reported to a user through an interface in a simple manner.