Abstract: A data streaming environment provides a summary of streaming data. An input interface receives streaming data from a sensor or an input device. The input device includes a user interface. The sensor is an Internet of Things (IOT) device. A processor is communicatively coupled to the input interface for processing the streaming data. A histogram update application is executed with the received data to provide a limited-size summary of the streaming data by fading outdated data by storing distance data and bin data. The processed data includes a plurality of records and variables that describe a characteristic of a physical object. An output interface is communicatively coupled to the processor to provide the processed data to be visually presented in one or more data graphs on a display device.

Abstract: A method of acknowledging receipt of an event block object is provided. First connection information for connecting to an event stream processing (ESP) engine executing at a first computing device is received. A first connection to the ESP engine is established using the received first connection information. Second connection information for connecting to a publishing client executing at a second computing device is received. A second connection to the publishing client is established using the received second connection information, wherein the first connection differs from the second connection. An event block object is received from the ESP engine using the established first connection, wherein the event block object includes a unique identifier for the event block object. Successful processing of the event block object is determined.

Abstract: In a system, a first status of a first ESP engine (ESPE) executing at a first computing device is determined as newly active; a last published event block object identifier is determined as an identifier uniquely identifying a last event block object published to an out-messaging network device; a next event block object having an event block object identifier greater than the determined last published event block object identifier is selected from a first computer-readable medium; and the selected next event block object is published to the out-messaging network device. A first event block object is received from a second ESPE executing at a second computing device. A first status of the second ESPE is determined as standby by the second computing device. The received first event block object is stored by the second computing device in a second non-transitory computer-readable medium.

Abstract: A computing device is provided that supports receipt and processing of blocks of streamed data associated with an event and provision of pre-rendered and compressed events to event client systems with a high-throughput. The computing device includes a compression optimizer module that determines how to make new compressed blocks of the right level of compression as the blocks of streamed data are received from an event publishing system. The compression optimizer module utilizes a tree map and unique identifiers to selectively compress, read, and recompress the blocks of streamed data associated with each event. To prevent duplicate work in compressing the streamed data, compressed blocks are re-used where possible to support requests from the event client systems. Each new block includes a unique identifier defined by the event publishing system that generated the event, so that a previous version of the event in a compressed block can be replaced.

Abstract: A computer-readable medium is provided that causes a computing device to serve data resources. A received block is compressed with previously compressed blocks to create a new compressed block stored in a pre-allocated block of memory. A reference to the selected pre-allocated block of memory is stored in a tree map using a unique identifier. A second block is received. The pre-allocated block of memory is identified from the tree map using the unique identifier. The received block and at least one of the previously compressed blocks is read from the block of memory. The received second block is compressed with the at least one of the one or more previously compressed blocks to create a second new compressed block stored in the selected second pre-allocated block of memory. A reference to the selected second pre-allocated block of memory is stored in the tree map based on the unique identifier.

Abstract: A computer-readable medium is provided that causes a computing device to serve data resources. A nozzle is instantiated for a resource based on a media type associated with both the nozzle and the resource and starts a subscriber thread and a rendering thread. The subscriber thread receives a block of streamed data from a publishing device, stores the block in a queue, and receives a request to drain the queue. The block includes a unique identifier of an event associated with the media type. The rendering thread reads the block from the queue, renders the block, and stores the rendered block in a pre-allocated block of memory based on the unique identifier. A reference to the pre-allocated block of memory is stored in a tree map based on the unique identifier. The instantiated nozzle sends the rendered block to a requesting event client system.

Abstract: A computer-readable medium is provided that causes a computing device to serve data resources. A nozzle is instantiated for a resource based on a media type associated with both the nozzle and the resource and starts a subscriber thread and a rendering thread. The subscriber thread receives a block of streamed data from a publishing device, stores the block in a queue, and receives a request to drain the queue. The block includes a unique identifier of an event associated with the media type. The rendering thread reads the block from the queue, renders the block, and stores the rendered block in a pre-allocated block of memory based on the unique identifier. A reference to the pre-allocated block of memory is stored in a tree map based on the unique identifier. The instantiated nozzle sends the rendered block to a requesting event client system.

Abstract: In a system, a first status of a first ESP engine (ESPE) executing at a first computing device is determined as newly active; a last published event block object identifier is determined as an identifier uniquely identifying a last event block object published to an out-messaging network device; a next event block object having an event block object identifier greater than the determined last published event block object identifier is selected from a first computer-readable medium; and the selected next event block object is published to the out-messaging network device. A first event block object is received from a second ESPE executing at a second computing device. A first status of the second ESPE is determined as standby by the second computing device. The received first event block object is stored by the second computing device in a second non-transitory computer-readable medium.

Abstract: In a computing device supporting a failover in an event stream processing (ESP) system, an event block object is received. A first status of the computing device as active or standby is determined. When the first status is active, a second status of the computing device as newly active or not newly active is determined. Newly active is determined when the computing device is switched from a standby to an active status. When the second status is newly active, a last published event block object identifier that uniquely identifies a last published event block object is determined. A next event block object is selected from a non-transitory computer-readable medium accessible by the computing device. The next event block object has an event block object identifier that is greater than the determined last published event block object identifier. The selected next event block object is published to an out-messaging network device.

Abstract: A method of acknowledging receipt of an event block object is provided. First connection information for connecting to an event stream processing (ESP) engine executing at a first computing device is received. A first connection to the ESP engine is established using the received first connection information. Second connection information for connecting to a publishing client executing at a second computing device is received. A second connection to the publishing client is established using the received second connection information, wherein the first connection differs from the second connection. An event block object is received from the ESP engine using the established first connection, wherein the event block object includes a unique identifier for the event block object. Successful processing of the event block object is determined.

Abstract: Fraud losses in a communication network are substantially reduced by automatically generating fraud management recommendations in response to suspected fraud and by deriving the recommendations as a function of selected attributes of the fraudulent activity. More specifically, a programmable rules engine automatically generates recommendations based on call-by-call fraud scoring so that the recommendations correspond directly to the type and amount of suspected fraudulent activity. Using telecommunications fraud as an example, an automated fraud management system receives call detail records that have been previously scored to identify potentially fraudulent calls. Fraud scoring estimates the probability of fraud for each call based on the learned behavior of an individual subscriber as well as that of fraud perpetrators. Scoring also provides an indication of the contribution of various elements of the call detail record to the fraud score for that call.

Abstract: Fraud losses in a communication network are substantially reduced by automatically and selectively invoking one or more authentication measures based on a fraud score that indicates the likelihood of fraud for that particular call or previously scored calls. By selectively invoking authentication on only those calls that are suspected or confirmed to be fraudulent, fraud prevention can be achieved in a way that both reduces fraud losses and minimizes disruptions to legitimate subscribers. Using telecommunication fraud as an example, a subscriber is registered in a system by collecting data on that subscriber based on the particular authentication method being used, such as shared knowledge (e.g., passwords), biometric validation (e.g., voice verification), and the like. Once registered, the authentication function for the subscriber's account is activated and subsequent calls are then scored for the likelihood of fraud during the call setup request phase.