System and method for aggregating and generating single event portraits of event features

Abstract

A computer-implemented method for aggregating and mapping event features into a daily profile. The method includes receiving a set of historical data objects, the set of historical data objects indicating occurrences of a set of events, each event being associated with a set of configurable items; determining a single event profile for each historical data object; determining an integrated single event profile for each historical data object; aggregating the integrated single event profiles by day dimension; and outputting the integrated single event profiles by day dimension.

Description

[0001] Cross-references to related applications

[0002] This patent application claims the benefit of priority to U.S. nonprovisional patent application No. 18 / 499,178, filed October 31, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] Various embodiments of this disclosure generally relate to processing event data, and more specifically, to aggregating and generating single event profiles. Background Technology

[0004] Any change to any type of system carries the risk of the system failing to function as expected. Furthermore, even if system performance is not immediately affected, changes can lead to subsequent problems and may waste time determining the cause of the performance change.

[0005] For example, in software, deploying, refactoring, or releasing software code carries different types of associated risks, depending on the code being changed. A lack of clear understanding of the vulnerabilities or risk levels of a particular code deployment increases the risk of system downtime. Deploying code always introduces risk to a company, and platform modernization is an ongoing process. Technological shifts are significant for any product and present both substantial risks and opportunities for software companies.

[0006] Downtime and / or incidents incur financial losses for the company due to service level agreement (SLA) reimbursements, but more importantly, they waste personnel time through rework and can negatively impact the company's reputation with customers. The highest costs are attributed to defects entering the production environment, including the ripple effects and direct costs on all downstream teams. Furthermore, after deployment modifications, incident teams may waste time determining the cause of the system performance changes.

[0007] Change requests across the entire IT environment can carry varying levels of risk and impact. In large IT organizations, change-related incidents can account for 70-80% of critical incidents, placing a significant burden on IT teams. Modern IT architectures have become increasingly complex. Resolving recurring incidents across the entire IT environment in large systems often involves dispersed people and systems, as well as separate work orders and time-disjointed solutions, leading to significant inefficiencies in large IT organizations. Understanding different types of incidents within the system from different perspectives, either daily or in groups, can help in resolving incidents.

[0008] This disclosure aims to overcome one or more of the challenges mentioned above. Summary of the Invention

[0009] In some respects, the techniques described herein relate to a method for aggregating and mapping event features to daily profiles, the method comprising: receiving a set of historical data objects indicating the occurrence of a set of events, each event being associated with a set of configurable items; determining a single event profile for each historical data object; determining an integrated single event profile for each historical data object; aggregating the integrated single event profiles by day; and outputting the integrated single event profiles by day.

[0010] In some respects, the techniques described in this paper involve a method in which a set of historical data objects represents the occurrence of a set of events over at least one month.

[0011] In some respects, the techniques described in this paper involve a method in which determining a single event profile for each historical data object includes: determining features from the textual description of the historical data object; performing a clustering algorithm on the features; and determining a cluster for each historical data object.

[0012] In some respects, the techniques described herein relate to a method that further includes: determining a first set of features using word frequency-inverse document frequency vectorization; determining a second set of features using noun phrase extraction; and determining a third set of features using verb phrase extraction.

[0013] In some respects, the techniques described in this paper involve a method in which clustering algorithms are applied to a first set of features, a second set of features, and a third set of features, respectively.

[0014] In some respects, the techniques described in this paper involve a method in which determining an integrated single-event profile for each historical data object further includes: applying a clustering algorithm to the integrated single-event profile; and storing a single-event cluster for each historical data object.

[0015] In some respects, the techniques described in this paper involve a method in which the aggregated single event profile on a daily dimension further includes performing a clustering algorithm on the aggregated single event profile, wherein the daily single event profile has the aggregated result of all single event clusters for each historical data object within a day.

[0016] In some respects, the techniques described in this paper involve a method in which the integrated single event profile is output on a daily basis, including: the number of events received over a period of time, and the number of identified single event profiles.

[0017] In some respects, the techniques described in this paper involve a method in which the integrated single event profile is output on a daily basis, including: compiling and outputting the total number of events received on a specific day, and outputting a corresponding single event profile for each event.

[0018] In some aspects, the techniques described herein relate to a system for aggregating and mapping event features to daily profiles, the system comprising: a memory storing processor-readable instructions; and at least one processor configured to access the memory and execute the processor-readable instructions to perform operations including: receiving a set of historical data objects indicating the occurrence of a set of events, each event associated with a set of configurable items; determining a single event profile for each historical data object; determining an integrated single event profile for each historical data object; aggregating the integrated single event profiles by daily dimension; and outputting the integrated single event profiles by daily dimension.

[0019] In some respects, the techniques described in this paper relate to a system in which a set of historical data objects represents the occurrence of a set of events over at least one month.

[0020] In some respects, the techniques described in this paper relate to a system in which determining a single event profile for each historical data object includes: determining features from the textual description of the historical data object; performing a clustering algorithm on the features; and determining a cluster for each historical data object.

[0021] In some respects, the techniques described herein relate to a system that further includes: determining a first set of features using word frequency-inverse document frequency vectorization; determining a second set of features using noun phrase extraction; and determining a third set of features using verb phrase extraction.

[0022] In some respects, the techniques described in this paper relate to a system in which clustering algorithms are applied to a first set of features, a second set of features, and a third set of features, respectively.

[0023] In some respects, the techniques described in this paper relate to a system in which determining an integrated single-event profile for each historical data object further includes: applying a clustering algorithm to the integrated single-event profile; and storing a single-event cluster for each historical data object.

[0024] In some respects, the techniques described in this paper relate to a system in which a single event profile aggregated and integrated on a daily dimension further includes: performing a clustering algorithm on the integrated single event profile, wherein the single event profile on a daily dimension has the aggregated result of all single event clusters for each historical data object within a day.

[0025] In some respects, the techniques described in this paper relate to a system in which the integrated single event profile is output on a daily basis, including the number of events received over a period of time and the number of identified single event profiles.

[0026] In some respects, the techniques described in this paper relate to a system in which the output of an integrated single event profile on a daily basis includes: compiling and outputting the total number of events received on a specific day, and outputting a corresponding single event profile for each event.

[0027] In some aspects, the techniques described herein relate to a non-transitory computer-readable medium storing processor-readable instructions that, when executed by at least one processor, cause the at least one processor to perform an operation comprising: receiving a set of historical data objects indicating the occurrence of a set of events, each event being associated with a set of configurable items; determining a single event profile for each historical data object; determining an integrated single event profile for each historical data object; aggregating the integrated single event profile by day; and outputting the integrated single event profile by day.

[0028] In some respects, the techniques described herein relate to a non-transitory computer-readable medium in which a set of historical data objects represents the occurrence of a set of events over at least one month. Attached Figure Description

[0029] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and, together with the description, serve to explain the principles of the disclosed embodiments.

[0030] Figure 1 An exemplary system overview is provided, according to one or more embodiments, for transmitting data to an artificial intelligence model to aggregate and map events in the system.

[0031] Figure 2 An exemplary flowchart for aggregating and generating a single event profile, according to one or more embodiments, can be depicted.

[0032] Figure 3 An exemplary method for determining a single event profile according to one or more embodiments is described.

[0033] Figure 4A An exemplary graph depicts features determined using term frequency-inverse document frequency (TF-IDF) vectorization for a single event profile according to one or more embodiments.

[0034] Figure 4B An exemplary diagram is depicted illustrating features identified using noun phrase extraction for a single event profile according to one or more embodiments.

[0035] Figure 4CAn exemplary diagram is depicted illustrating the use of verb phrases to extract identified features for a single event profile according to one or more embodiments.

[0036] Figure 4D An exemplary graph depicts clustering features determined using term frequency-inverse document frequency (TF-IDF) vectorization for a single event profile according to one or more embodiments.

[0037] Figure 4E An exemplary diagram is depicted illustrating clustering features determined using noun phrase extraction for a single event profile according to one or more embodiments.

[0038] Figure 4F An exemplary diagram is depicted illustrating the use of verb phrases to extract determined clustering features for a single event profile according to one or more embodiments.

[0039] Figure 5A An exemplary flowchart for creating an integrated single event profile is depicted according to one or more embodiments.

[0040] Figure 5B An exemplary diagram depicts an integrated single event profile according to one or more embodiments.

[0041] Figure 6A An exemplary flowchart is depicted for a single event profile aggregated and integrated on a daily dimension, according to one or more embodiments.

[0042] Figure 6B An exemplary diagram depicts an integrated single event profile aggregated according to one or more embodiments on a daily dimension.

[0043] Figure 7 An exemplary graph output depicts the recurring events of a specific configurable item during an exemplary day according to one or more embodiments.

[0044] Figure 8 An exemplary chart output depicts a repeating work order for an exemplary day according to one or more embodiments.

[0045] Figure 9 An exemplary chart output depicts the main contributing alarms for events in an exemplary day according to one or more embodiments.

[0046] Figure 10 An exemplary graph output depicts the minimum time interval between events of the same configurable item according to one or more embodiments.

[0047] Figure 11 An exemplary chart output depicts frequently occurring events in an exemplary day according to one or more embodiments.

[0048] Figure 12 This is a flowchart of a method for aggregating and generating single event profiles.

[0049] Figure 13 A computer system 1300 for performing the technology described herein is illustrated according to one or more embodiments of the present disclosure. Detailed Implementation

[0050] Various embodiments of this disclosure generally relate to processing event data, and more specifically, to aggregating and mapping event features into daily event profiles using feature engineering and multi-level clustering.

[0051] The subject matter of this disclosure will now be described more fully with reference to the accompanying drawings, which illustrate specific exemplary embodiments by way of illustration. The embodiments or specific implementations described herein as “exemplary” should not be construed as preferred or advantageous over other embodiments or specific implementations; rather, they are intended to reflect or represent that one or more embodiments are “example” embodiments. The subject matter can be embodied in many different forms, and therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the exemplary embodiments set forth herein; the exemplary embodiments are provided merely for illustrative purposes. Similarly, the subject matter intended to be claimed or covered has a reasonably broad scope. Among other things, for example, the subject matter can be embodied as a method, apparatus, component, or system. Therefore, embodiments can take the form, for example, hardware, software, firmware, or any combination thereof (other than software itself). Therefore, the following detailed description is not intended to be understood in a limiting sense.

[0052] Throughout the specification and claims, terms may have implied or subtle meanings in the context beyond their expressly stated meanings. Similarly, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment" as used herein does not necessarily refer to different embodiments. For example, the subject matter intended to be claimed includes combinations of exemplary embodiments, either wholly or partially.

[0053] The terms used below may be interpreted in their broadest and most reasonable manner, even when used in conjunction with a detailed description of certain specific examples of this disclosure. In fact, some terms may even be emphasized below; however, any term intended to be interpreted in any limited manner will be explicitly and specifically defined in this Detailed Description section.

[0054] Software companies strive to avoid downtime caused by events such as software or hardware component upgrades or team member changes. The system described herein can be configured to analyze and / or process event data from IT systems. The system described herein can, for example, receive a stream of event data over a period of time. This event data can be further described as information technology (IT) event data. Event data may include, but is not limited to: (1) events, (2) alarms, (3) change data, (4) problems; and / or (5) anomalies.

[0055] An event may be an event that could disrupt or cause loss of system operation, service, or functionality. Events may be manually reported by customers or personnel, automatically logged by internal systems, or otherwise captured. Events may be caused by factors such as hardware failure, software failure, software defect, human error, and / or cyberattacks. For example, deploying, refactoring, or releasing software code may cause an event. For example, an event may be detected during downtime or performance changes. Events may include characteristics, where event characteristics may refer to qualities or features associated with the event. For example, event characteristics may include, but are not limited to, the severity of the event, the urgency of the event, the complexity of the event, the scope of the event, the cause of the event, and / or what configurables correspond to the event (e.g., which systems / platforms / products are affected by the event), how it is described in free-form text, which business units are affected, which categories / subcategories are affected, and / or which allocation group the event is assigned to.

[0056] Understanding the different types of events that occur within a system each day from various perspectives can help in resolving issues. For example, defining, characterizing, or grouping specific events or groups of events received by the system can be useful. Grouping and defining all events received by the system on a particular day can be even more valuable. This can be a complex task because events may include many inherently heterogeneous and different types of characteristics. For instance, events may include metadata such as fields like a brief description, free-form text fields, affected CIs, start time, event cause code, priority, etc. Comparing, grouping, or mapping events based on individual aspects / fields may fail to capture the complexity of accurately grouping related events.

[0057] One or more embodiments may include systems and methods configured to group and define events at both the single event profile level and daily profile levels. These profiles may be based on multidimensional characteristics of the events, and they can provide insights for event management. Daily profiles can be compared and grouped with previously defined daily profiles. Groups of daily profiles can, for example, help define a baseline for defining a daily profile as a normal operating day. The system may also be configured to match a specific daily profile with one or more historical daily profiles. The daily profiles and single event profiles, as well as the matching of daily profiles, can provide valuable information to event management procedures, whose task is to respond to and resolve events.

[0058] One or more embodiments of the systems and methods described herein may alleviate the burden on companies of identifying, aggregating, mapping, and ultimately resolving events. One or more embodiments can process daily event data to create daily event profiles. Daily event profiles can help IT management systems better understand the events received throughout the day at a more comprehensive level.

[0059] Figure 1 An exemplary system overview is provided for a data pipeline for events in an artificial intelligence model prediction and troubleshooting system, according to one or more embodiments. For example, data pipeline system 100 may aggregate event data and send it to artificial intelligence model 180, wherein artificial intelligence model 180 is configured to aggregate and map event features to daily event profiles using feature engineering and / or multi-level clustering. Data pipeline system 100 may be a platform with multiple interconnected components. Data pipeline system 100 may include one or more servers, intelligent network devices, computing devices, components, and corresponding software for aggregating and processing data.

[0060] like Figure 1 As shown, the data pipeline system 100 may include a data source 101, a collection point 120, a secondary collection point 110, a front-end gateway processor 140, a data storage device 150, a processing platform 160, a data receiving layer 170, a data receiving layer 171, and an artificial intelligence module 180.

[0061] Data source 101 may include internal data 103 and third-party data 199. Internal data 103 may be a data source directly linked to data pipeline system 100. Third-party data 199 may be an external data source connected to data pipeline system 100, as will be described in more detail below.

[0062] Both internal data 103 and third-party data 199 of data source 101 can include event data 102. Event data 102 can include event reports that provide one or more of the following information for each event: event number, closure date / time, category, closure code, closure notes, long description, short description, root cause, or assignment group. Event data 102 can include event reports that provide one or more of the following information for each event: issue key, description, summary, tag, issue type, fix version, environment, author, or comment. Event data 102 can include event reports that provide one or more of the following information for each event: filename, script name, script type, script description, display identifier, message, submitter type, submitter link, attributes, file changes, or branch information. Event data 102 can include one or more of the following data: real-time data, market data, performance data, historical data, utilization data, infrastructure data, or security data. These are merely examples of information that can be used as data, and this disclosure is not limited to these examples.

[0063] Event data 102 can be automatically generated by monitoring tools that generate alerts and event data to provide notifications of high-risk operations and IT environment failures, and may be generated as work orders. Event data may include metadata such as text fields, identifiers, and timestamps.

[0064] Internal data 103 can be stored in a relational database that includes event tables. Event tables can be provided as one or more tables and can include one or more of, for example, issues, tasks, risk conditions, events, or changes. The relational database can be stored in the cloud. The relational database can be encrypted and connected to a gateway. The relational database can send periodic updates to and receive periodic updates from the cloud. The cloud can be a remote cloud service, a local service, or any combination thereof. The cloud may include a gateway connected to a processing API configured to transmit data to collection point 120 or secondary collection point 110. Event tables can include event data 102.

[0065] The data pipeline system 100 may include third-party data 199 generated and maintained by third-party data producers. Third-party data producers may generate event data 102 from IoT devices, desktop devices, and sensors. Third-party data producers may include, but are not limited to, Tryambak, Appneta, Oracle, Prognosis, ThousandEyes, Zabbix, ServiceNow, Density, Dynatrace, etc. Event data 102 may include metadata indicating that the data belongs to a specific client or associated system.

[0066] Data pipeline system 100 may include a secondary acquisition point 110 for acquiring and preprocessing event data 102 from data source 101. The secondary acquisition point 110 may be used before data is transmitted to acquisition point 120. The secondary acquisition point 110 may be, for example, Apache Minifi software. In one example, the secondary acquisition point 110 may run on the microprocessor of a third-party data producer. Each third-party data producer may have an instance of the secondary acquisition point 110 running on its microprocessor. The secondary acquisition point 110 may support data formats, including but not limited to JSON, CSV, Avro, ORC, HTML, XML, and Parquet. The secondary acquisition point 110 may encrypt the event data 102 acquired from the third-party data producer. The encryption methods include, but are not limited to, Mutual Authentication Transport Layer Security (mTLS), HTTPS, SSH, PGP, IPsec, and SSL. The secondary acquisition point 110 may perform initial transformations or processing of the event data 102. Secondary acquisition point 110 can be configured to acquire data from multiple protocols, immediately generate data traceability, apply transformation and encryption to the data, and prioritize the data.

[0067] Data pipeline system 100 may include collection point 120. Collection point 120 may be a system configured to provide a security framework for routing, transforming, and delivering data from data source 101 to downstream processing devices (e.g., front-end gateway processor 140). Collection point 120 may be software such as Apache NiFi. Collection point 120 may receive raw data along with corresponding fields of the data, such as source name and ingestion time. Collection point 120 may run on a Linux virtual machine (VM) on a remote server. Collection point 120 may include one or more nodes. For example, collection point 120 may receive event data 102 directly from data source 101. In another example, collection point 120 may receive event data 102 from a secondary collection point 110. The secondary collection point 110 may use, for example, a site-to-site protocol to deliver event data 102 to collection point 120. Collection point 120 may include streaming algorithms. Streaming algorithms may connect different processors (as described herein) to transfer and modify data from one source to another. For each third-party data producer, collection point 120 can have a separate streaming algorithm. Each streaming algorithm can include a processing group. A processing group can include one or more processors. One or more processors can, for example, retrieve event data 102 from a relational database. One or more processors can utilize the processing API of internal data 103 to make API calls to the relational database to retrieve event data 102 from the event table. One or more processors can further transmit event data 102 to a target system, such as front-end gateway processor 140. Collection point 120 can encrypt data via HTTPS, mutual authentication transport layer security (mTLS), SSH, PGP, IPsec, and / or SSL. Collection point 120 can support data formats including, but not limited to, JSON, CSV, Avro, ORC, HTML, XML, and Parquet. Collection point 120 can be configured to write messages to and communicate with the cluster of front-end gateway processors 140.

[0068] Data pipeline system 100 may include a distributed event streaming platform, such as front-end gateway processor 140. Front-end gateway processor 140 may connect to and be configured to receive data from collection point 120. Front-end gateway processor 140 may be implemented in an Apache Kafka cluster software system. Front-end gateway processor 140 may include one or more message brokers and corresponding nodes. Message brokers may be, for example, intermediate computer program modules that translate messages from the sender's formal message protocol to the receiver's formal message protocol. Message brokers may reside on a single node within front-end gateway processor 140. The message brokers of front-end gateway processor 140 may run on virtual machines (VMs) on a remote server. Collection point 120 may send event data 102 to one or more message brokers of front-end gateway processor 140. Each message broker may include a topic for storing event data 102 of similar categories. Topics may be ordered event logs. Each topic may include one or more subtopics. For example, one subtopic may store event data 102 related to network problems, and another topic may store event data 102 related to security vulnerabilities from third-party data producers. Each topic may further include one or more partitions. Partitioning can be a systematic way of breaking down a topic log file into many logs, each of which can be hosted on a separate server. Each partition can be configured to store up to one byte of event data 102. Each topic can be evenly partitioned across one or more message brokers for load balancing and scalability. The front-end gateway processor 140 can be configured to classify received data into multiple customer categories, thereby forming multiple datasets associated with the corresponding customer categories. These datasets can be stored separately in storage devices, as described in more detail below. The front-end gateway processor 140 can further transfer the data to storage and processors for further processing.

[0069] For example, the front-end gateway processor 140 can be configured to assign specific data to corresponding topics. Alarm sources can be assigned to alarm topics, event data can be assigned to event topics, change data can be assigned to change topics, and problem data can be assigned to problem topics.

[0070] Data pipeline system 100 may include a software framework for data storage 150. Data storage 150 can be configured for long-term storage and distributed processing. Data storage 150 can be implemented using, for example, Apache Hadoop. Data storage 150 can store event data 102 transmitted from front-end gateway processor 140. Specifically, data storage 150 can be used for distributed processing of event data 102, and the Hadoop Distributed File System (HDFS) within the data storage can be used to organize the communication and storage of event data 102. For example, HDFS can replicate from any node of front-end gateway processor 140. This replication can prevent hardware or software failures of front-end gateway processor 140. Processing can be executed concurrently on multiple servers.

[0071] Data store 150 may include an HDFS configured to receive metadata (e.g., event data). Data store 150 may further utilize MapReduce algorithms to process data. MapReduce algorithms allow for parallel processing of large datasets. Data store 150 may further utilize a YARN resource coordinator to aggregate and store data. YARN can be used for cluster resource management and planning tasks related to storing data. For example, a cluster computing framework (such as processing platform 160) may be deployed to further utilize the HDFS of data store 150. For example, if data source 101 stops providing data, processing platform 160 may be configured to retrieve data directly from data store 150 or via front-end gateway processor 140. Data store 150 may allow distributed processing of large datasets across a computer cluster using programming models. Data store 150 may include master nodes and an HDFS for distributed processing across multiple data nodes. Master nodes may store metadata, such as the number and location of data blocks. Master nodes may maintain file system namespaces and regulate client access to said files. Master nodes may include files and directories and perform file system operations such as naming, closing, and opening files. Data storage 150 can scale horizontally from a single server to thousands of machines, each providing local compute and storage. Data storage 150 can be configured to store event data in unstructured, semi-structured, or structured formats. In one example, multiple datasets associated with corresponding customer categories can be stored separately. The master node can store metadata, such as the location of individual datasets.

[0072] Data pipeline system 100 may include a real-time processing framework, such as processing platform 160. In one example, processing platform 160 may be a distributed data stream engine that does not have its own storage layer. For example, this could be the software platform Apache Flink. In another example, the software platform Apache Spark could be used. Processing platform 160 may support both stream processing and batch processing. Stream processing can be a type of data processing that performs continuous real-time analysis on received data. Batch processing may involve receiving discrete datasets for batch processing. Processing platform 160 may include one or more nodes. Processing platform 160 may aggregate event data 102 received from front-end gateway processor 140 (e.g., event data 102 that has already been processed by front-end gateway processor 140). Processing platform 160 may include one or more operators to transform and process the received data. For example, a single operator may filter event data 102 and then connect to another operator to perform further data transformation. Processing platform 160 may process event data 102 in parallel. A single operator may reside on a single node within processing platform 160. Processing platform 160 may be configured to filter and send only specifically processed data to a specific data receiving layer. For example, depending on the data source of event data 102 (e.g., whether the data is internal data 103 or third-party data 199), the data may be transmitted to a separate data receiving layer (e.g., data receiving layer 170 or data receiving layer 171). Furthermore, additional data that is not needed by downstream modules (e.g., at artificial intelligence module 180) may be filtered and excluded before being transmitted to the data receiving layer.

[0073] Processing platform 160 can perform three functions. First, processing platform 160 can perform data validation. The values, structure, and / or format of the data can be matched with the target schema (e.g., data receiving layer 170). Second, processing platform 160 can perform data transformation. For example, source fields, target fields, functions, and parameters can be extracted from the data. Based on the functions extracted from the data, specific transformations can be applied. This transformation can reformat the data for a specific downstream purpose. Users may be able to select a specific format to use downstream. Third, processing platform 160 can perform data routing. For example, processing platform 160 can select the shortest and / or most reliable path to send data to the appropriate receiving layer (e.g., receiving layer 170 and / or receiving layer 171).

[0074] In one example, processing platform 160 can be configured to transmit a specific dataset to the data receiving layer. For example, processing platform 160 can receive input variables from a specific artificial intelligence module 180. Processing platform 160 can then filter the data received from front-end gateway processor 140 and transmit only the data relevant to the input variables of artificial intelligence module 180 to the data receiving layer.

[0075] Data pipeline system 100 may include one or more data receiving layers (e.g., data receiving layer 170 and data receiving layer 171). Event data 102 processed from processing platform 160 may be sent to and stored in data receiving layer 170. In one example, data receiving layer 171 may be externally stored on a server of a specific client. Data receiving layers 170 and 171 may be implemented using software such as, but not limited to, PostgreSQL, HIVE, Kafka, OpenSearch, and Neo4j. Data receiving layer 170 may receive internal data 103 that has been processed by and received from processing platform 160. Data receiving layer 171 may receive third-party data 199 that has been processed by processing platform 160 and received from it. Data receiving layers may be configured to deliver event data 102 to artificial intelligence module 180. Data receiving layers may be data lakes, data warehouses, or cloud storage systems. Each data receiving layer may be configured to store event data 102 in structured or unstructured formats. Data receiving layer 170 may store event data 102 in a variety of different formats. For example, data receiving layer 170 can support data formats such as JavaScript Object Notation (JSON), comma-separated value (CSV), Avro, Optimized Row Columnar (ORC), Hypertext Markup Language (HTML), Extensible Markup Language (XML), or Parquet. The data receiving layer (e.g., data receiving layer 170 or data receiving layer 171) can be accessed by one or more individual components. For example, the data receiving layer can be accessed by a Non-structured Query Language ("NoSQL") database management system (e.g., a Cassandra cluster), a graph database management system (e.g., a Neo4j cluster), further processing programs (e.g., a Kafka + Flink program), and a relational database management system (e.g., a Postgres cluster). Therefore, further processing can be performed before the processed data is received by the artificial intelligence module 180.

[0076] Data pipeline system 100 may include artificial intelligence module 180. Artificial intelligence module 180 may include machine learning components. Artificial intelligence module 180 may use received data to train and / or use machine learning models. Machine learning models may be, for example, neural networks. However, it should be noted that artificial intelligence module 180 may use other machine learning techniques and frameworks to perform the methods contemplated in this disclosure. For example, the system and methods may be implemented using other types of supervised and unsupervised machine learning techniques, such as regression problems, random forests, clustering algorithms, principal component analysis (PCA), reinforcement learning, or combinations thereof. Artificial intelligence module 180 may be configured to extract and receive data from data receiving layer 170.

[0077] Figure 2 An exemplary flowchart 200 for aggregating and generating a single event profile can be depicted according to one or more embodiments. Figure 2 The process / method described in the document can be derived from... Figure 1 Data pipeline system 100 and / or Figure 13 This is achieved using the 1300 computer system.

[0078] In step 202, event data may be received and filtered. Event data may include event reports that provide one or more of the following information for each event: event number, closure date / time, category, closure code, closure notes, long description, short description, root cause, or assignment group. Event data may include event reports that provide one or more of the following information for each event: issue key, description, summary, tags, issue type, fix version, environment, author, or comment. Event data may further include the event cause code, priority, waiting information, and / or assignment group within the text description. Event data may include event reports that provide one or more of the following information for each event: filename, script name, script type, script description, display identifier, message, submitter type, submitter link, attributes, file changes, or branch information. Event data may include one or more of the following data: real-time data, market data, performance data, historical data, utilization data, infrastructure data, or security data. These are merely examples of information that can be used as data, and this disclosure is not limited to these examples. Event data, such as within a brief description, can include all of the aforementioned characteristic information. This can include the severity of the event, the urgency of the event, the complexity of the event, the scope of the event, the cause of the event, and / or what configurable item corresponds to the event (e.g., which systems / platforms / products are affected by the event), how it is described in free-form text, which business units are affected, which categories / subcategories are affected, and / or which allocation group the event is assigned to. For example, characteristic data of the event data can be extracted from the event description in this step for further processing. In one example, the event data can be filtered to provide an identifier number, the date and time of the event, the configurable item (CI) affected by the event, a brief description of the event, and the priority level of the event. These can all be saved for further analysis. A configurable item (CI) can refer to: (1) a product; (2) an allocation component of a product, or (3) a system that meets end-use functions, has explicit requirements, has functional and / or product relationships, and / or is designated for explicit control in a configuration management system. When an event occurs, it may occur for a specific configurable item.

[0079] The data may have been further filtered to provide events and their corresponding external systems (e.g., their configurable components). In another example, event data may be received via an electronic network (such as the Internet) through one or more computers, servers, and / or handheld mobile devices. The electronic network can be connected to provide automatically generated event data from external systems through monitoring tools that generate alarms and event data, providing notifications of high-risk operations, IT environment failures, and potentially generating work orders.

[0080] For example, clustering algorithms can be applied by artificial intelligence models. A clustering algorithm can be an unsupervised machine learning algorithm that groups data points (e.g., groups by day) based on grouped data points (e.g., based on daily features). Clustering can calculate the similarity between data points and assign them to clusters based on this similarity. Clustering can include algorithms that perform operations, including but not limited to affinity propagation, agglomerative hierarchical clustering, Balanced Iterative Reducing and Clustering using Hierarchies BIRCH, Density-Based Spatial Clustering of Applications with Noise DBSCAN, Gaussian Mixture Models (GMM), K-means, mean-shift clustering, mini-batch K-means, OPTICS, or spectral clustering.

[0081] After receiving the event data in step 202, the system can further create a single event profile in step 206. Figure 3 The flowchart can depict step 206 in more detail.

[0082] Figure 3 An exemplary method for determining a single event profile according to one or more embodiments is described. For example, in step 302, a system (e.g., system 100) may receive the event and corresponding data. This may include, for example, any data received in step 202. In particular, the event data may include a number of individual events and characteristics corresponding to each event. Event characteristics may include, but are not limited to, event number, date and time of the event, a brief description of the event, and priority information. The brief description may be free-form text containing additional information about the event, such as configurable items (“CI”), which services are affected by the event, what type of category, subcategory, and which allocation group the particular event is assigned to.

[0083] In step 304, the system may, for example, identify one or more sets of event features for each received event. This may be referred to as feature creation for a single event. Event features may, for example, be key aspects of information about a particular event. The system can determine features by analyzing the textual description of each received event. The system may utilize machine learning techniques, such as a natural language processing module, to determine and extract a set of event features for one or more events. The system may utilize natural language processing (NLP) techniques or processes to determine a set of event features. For example, NLP techniques may include using linear discriminant analysis and / or a Gibbs-Sampling Dirichlet mixture model to determine features.

[0084] In one example, the system can use three different techniques to determine three distinct sets of event features. The first set of event features can be extracted from the textual description of the event using the Term Frequency-Inverse Document Frequency (TD-IDF) algorithm. TD-IDF can, for example, calculate the relevance of words within a series of texts. TD-IDF can output an array of terms along with TD-IDF values ​​and return a list of feature names. The second set of event features can be extracted using noun phrase extraction. The third set of features can be extracted using verb phrase extraction. Noun phrase extraction and verb phrase extraction can be performed, for example, using natural language processing techniques (e.g., performed by an AI model 180). This can include using previously trained models, such as through supervised or unsupervised learning, to determine verb phrases and noun phrases. In one example, the system can determine the first set of features, the second set of features, and the third set of features.

[0085] Figure 4A An exemplary graph 450 depicts features determined using term frequency-inverse document frequency (TF-IDF) vectorization for a single event profile according to one or more embodiments. Figure 4B An exemplary diagram 455 depicts features identified using noun phrase extraction for a single event profile according to one or more embodiments. Figure 4C An exemplary diagram 460 is depicted illustrating the extraction of determined features from a single event profile using verb phrases according to one or more embodiments. The top row of diagrams 450, 455, and 460 may correspond to the extracted event features. The leftmost column may list the identifier names of the received events. Diagrams 450, 455, and 460 may, for example, depict the number of times the event text description includes the identified features from the features determined in step 304.

[0086] Figure 4B-4F as well as Figure 5B and Figure 6BThe exemplary charts may correspond to the output of a single set of exemplary event data received by system 100 over forty days. The outputs of these charts may be exemplary outputs that the system described herein may create during method 200 to determine one or more individual event profiles.

[0087] Figures 450, 455, and 460 can depict the locations where exemplary events possess specific characteristics within their brief descriptions. For example, Figure 4A Exemplary features determined using TD-IDF vectorization can be displayed. Figure 4B It can be shown that exemplary features identified by extracting noun phrases can be displayed. Figure 4C Exemplary features identified using verb phrases can be displayed.

[0088] After determining the event features included in each event (e.g., by extracting this information from the textual description of each event using the techniques discussed in step 304), the system can proceed to step 306. In step 306, the system can perform a clustering algorithm on the events and their corresponding features. For example, the clustering algorithm can be applied by an artificial intelligence model 180. The clustering algorithm can be an unsupervised machine learning algorithm that groups data points (e.g., feature days) based on groups of data points (e.g., based on one or more received events). Clustering can calculate the similarity between data points and assign data points to clusters based on the similarity of the data points. Clustering can include performing algorithms, including but not limited to affinity propagation, agglomerative hierarchical clustering, balanced iterative reduction and hierarchical clustering (BIRCH), density-based noise applied spatial clustering (DBSCAN), Gaussian mixture model (GMM), K-means, mean-shift clustering, mini-batch K-means, OPTICS, or spectral clustering.

[0089] Clustering algorithms can be applied to assign each event to a specific cluster based on the extracted daily features. This can be performed for each set of features identified. For example, if three sets of features are identified in step 304, three clusters can be assigned to each event analyzed. Therefore, clustering algorithms can be applied to: (1) events and corresponding features determined by TD-IDF vectorization; (2) events and corresponding features determined by noun phrase extraction; and / or (3) events and corresponding features determined by verb phrase extraction. Figure 4D-4F It can be displayed Figures 4A-4C An exemplary output of the clustering algorithm applied at step 406 of the three sets of features shown.

[0090] Figure 4D An exemplary graph 465 depicts clustering features determined using term frequency-inverse document frequency (TF-IDF) vectorization for a single event profile according to one or more embodiments. Figure 4EAn exemplary diagram 470 depicts clustering features determined using noun phrase extraction for a single event profile according to one or more embodiments. Figure 4F An exemplary diagram 475 depicts clustering features determined using verb phrases for a single event profile according to one or more embodiments. Figure 4D It can display an exemplary single event cluster determined based on event features extracted via TD-IDF vectorization. Figure 4E An exemplary single-event cluster can be displayed based on features extracted through noun phrase extraction. Figure 4F It can display an exemplary single-event cluster determined based on features extracted through verb phrase extraction.

[0091] In step 308, each cluster determined for a specific event can be saved and recorded. Each event can then include three saved clusters. One cluster can be based on event features determined from TD-IDF vectorization, one cluster can be based on event features extracted from noun phrases, and one cluster can be based on event features extracted from verb phrases.

[0092] A single event profile can be created for each event. The single event profile can store the clusters determined in step 306, along with event identifiers and additional data received from step 202, for further analysis.

[0093] After step 308 (and corresponding step 206) is completed, the system can continue execution. Figure 2 The step 208 is shown. In step 210, the system can create... Figure 5A The integrated single event profile shown.

[0094] Figure 5A An exemplary flowchart for creating an integrated single event profile is depicted according to one or more embodiments.

[0095] In step 502, the system may first receive the clustering clusters assigned to each event, along with the event identifier and corresponding event data, from step 206. The system may then filter the additional event data to extract the following metadata: event cause code, priority, waiting information, and / or assignment group. The event cause code may be, for example, a code used to track the cause of the event. This can be extracted from the text description of the event or stored as separate metadata for each event. For example, the received events may include cause codes such as: configuration, data, environment, hardware, human error, integration, software, and / or third party, where the cause code identifies the cause of the event. Priority may refer to a score defining the relative importance of the event. Priority may be assigned based on the impact or urgency of the event. The priority of an event may be assigned, for example, based on the urgency and priority level of a specific event. "Waiting information" may indicate whether the event is awaiting additional information (e.g., from a customer, a third party, or another team). This may be stored in the event's metadata. If no additional information is to be received, the waiting information may be assigned a score of 0; if the event is awaiting information, it may be assigned a score of 1. The assignment group may refer to the team responsible for resolving a specific event. This can be pre-assigned based on configurable items affected by the event. At the end of step 502, the clusters from step 206, along with the event cause code, priority, waiting information, and / or assignment groups, can be grouped for each received event and assigned to the integrated single event profile. The integrated single event profile can then be further analyzed.

[0096] In step 504, a clustering algorithm can be applied to each event based on the integrated single event profile. The clustering algorithm can group days based on their integrated single event profile (e.g., based on similar clusters from step 206 and similar event cause codes, priorities, waiting information, and / or assignment groups). This can be done as follows: Figure 5B As shown, Figure 5B An exemplary diagram 550 shows an integrated single event profile according to one or more embodiments. Figure 5B As shown, each integrated single event profile can be clustered into a specific cluster based on that integrated single event profile. The determined cluster can be referred to as the integrated single event profile cluster. An exemplary integrated single event profile cluster can be shown, for example, in the rightmost column of Figure 550. Any clustering algorithm described in this application can be applied in step 504. The integrated single event profile cluster can group events with similar integrated single event profiles.

[0097] In step 506, the integrated single event profile cluster can be saved for further analysis.

[0098] After step 506 (and corresponding step 208) is completed, the system can continue execution. Figure 2 Step 210 is shown. In step 210, the system can perform as follows: Figure 6A The image shown is a single event profile aggregated and integrated by day.

[0099] Figure 6A An exemplary flowchart is depicted for a single event profile aggregated and integrated on a daily dimension, according to one or more embodiments.

[0100] In step 602, the system can receive all the integrated single event profile clusters from step 208. At this point in the analysis, each received event can have an assigned integrated single event profile cluster.

[0101] In step 604, using the time and date stamps of the events, all events for a specific day can be grouped together. Next, for each day, the system can identify how many events belong to each cluster of the integrated single event profile from step 208. These can be recorded for each day. The daily counts can then be stored in memory for potential further analysis and processing.

[0102] In a sample scenario, the system can determine that 160 events were received on the first day. Of these 160 events, 12 events belong to cluster 0 (integrated single-event profile), 35 events belong to cluster 1 (integrated single-event profile), 2 events belong to cluster 2 (integrated single-event profile), 0 events belong to cluster 3 (integrated single-event profile), 5 events belong to cluster 4 (integrated single-event profile), 78 events belong to cluster 5 (integrated single-event profile), 5 events belong to cluster 6 (integrated single-event profile), and 2 events belong to cluster 78 (integrated single-event profile), 5 events belong to cluster 6 (integrated single-event profile), and 2 events belong to cluster 78 (integrated single-event profile), 5 events belong to cluster 78 (integrated single-event profile), and 2 events belong to cluster 8 (integrated single-event profile). Cluster 7: 1 event with integrated single event profile; Cluster 8: 5 events with integrated single event profile; Cluster 9: 1 event with integrated single event profile; Cluster 10: 0 events with integrated single event profile; Cluster 11 or 12: 1 event with integrated single event profile; Cluster 13: 0 events with integrated single event profile; Cluster 14: 14 events with integrated single event profile; Cluster 15: 0 events with integrated single event profile; Cluster 16: 0 events with integrated single event profile. This can be executed for a set number of days (e.g., one week, one month, three months, 100 days, one year, twenty-two days, etc.). In this example, it may have been executed for 22 days (e.g., ...). Figure 6B (As shown).

[0103] Figure 6BAn exemplary chart 650 depicts the aggregated single event profile aggregated along a daily dimension, as shown in the example of step 604. This can depict the aggregated single event profile mapped to a set time period of days. This information can be further grouped and analyzed.

[0104] After step 604 (and corresponding step 210) is completed, the system can continue execution. Figure 2 Step 212 is shown. In step 212, the system can output the aggregated and integrated single event profile by day. The output can refer to storing or sending the profile for further analysis. For example, Figure 6B The chart shows how profiles are aggregated based on assigned clusters over a period of time within a day. This allows for comparison and contrast across days based on the number of profiles belonging to a specific cluster on a particular day.

[0105] In step 212, each received event can be assigned to a defined single event profile. The system can be configured to output all events and their corresponding single event profiles within a specific time period (e.g., a day or a week). Furthermore, the system can be configured to output the number of events received within a time period and the number of types of single event profiles identified within that time period (e.g., clusters from the assignment in step 206). The output can allow additional systems or users to further analyze the extracted data and provide additional insights into trends or received events within that time period.

[0106] Figures 7 to 11 Exemplary diagrams are depicted that can be output from the systems and methods described herein.

[0107] Figure 7 An exemplary chart output depicts recurring events of a specific configurable item throughout an exemplary day, according to one or more embodiments. For example, chart 700 may be the output of the systems and methods described herein. For instance, when creating a daily profile (e.g., at step 204 or 210), the system may be configured to output chart 900 detailing all configurable items affected by events during a particular day. This can, for example, allow a user to quickly see which configurable items are most and least affected during a particular day using the techniques and methods described herein. The Y column of chart 700 may, for example, depict the names of exemplary configurable items.

[0108] Figure 8An exemplary graph output depicts duplicate work orders for events in an exemplary day according to one or more embodiments. The systems and methods described herein can be configured to compile events that have been reported multiple times. For example, duplicate work orders (e.g., work orders reporting events) can be received. The daily profile can be configured to identify and output the number of duplicate work orders with closure codes. For example, duplicate work orders may be created because multiple work orders were created for the same issue, for a previously resolved issue, or for an issue outside the scope of IT service management.

[0109] Chart 800 can depict how many recurring work orders are created for a given configurable item in a day. Chart 800 can include a given closure code on the x-axis. The closure code for a configurable item can be the code indicating why a particular configurable item event has been resolved. This can depict events that might be overlooked on a daily scale when reported multiple times (e.g., with their corresponding work order reports). Therefore, the information generated from the daily profile can be useful for reviewing IT management systems.

[0110] Figure 9 An exemplary chart output depicts the main contributing alarms for events in an exemplary day according to one or more embodiments. Figure 9 This can include all event data for a day compiled by the system described in this paper, including received alarms. Alarms can refer to notifications generated by monitoring systems that report events. The system described in this paper can compile the types of alarms sent. The system can aggregate all types of alarms received on a specific day and plot / output this information as shown in Figure 900.

[0111] Figure 10 An exemplary graph output depicts the minimum time interval between events of the same configurable item according to one or more embodiments. The minimum time interval may be identified, for example, in step 204. This time may be recorded and plotted as a graph for users to examine and analyze event data received throughout the day.

[0112] Figure 11 An exemplary graph 1100 output depicts frequently occurring events throughout an exemplary day according to one or more embodiments. For example, a summary may correspond to the features extracted in step 206. Features that repeat throughout the day may be plotted and displayed as shown in graph 1100.

[0113] Figure 12 This is a flowchart 1200 for a method of aggregating and mapping event features into daily profiles.

[0114] In step 1202, a set of historical data objects may be received, which indicates the occurrence of a set of events, each event being associated with a set of configurable items.

[0115] In step 1204, a single event profile can be determined for each historical data object.

[0116] In step 1206, an integrated single event profile can be determined for each historical data object.

[0117] In step 1208, a single event profile can be aggregated and integrated by day dimension.

[0118] In step 1210, a single event profile can be output on a daily basis.

[0119] Figure 13 A computer system 1300 for performing the technology described herein is illustrated according to one or more embodiments of the present disclosure.

[0120] In addition to standard desktop computers or servers, any computer system capable of meeting the required storage and processing needs is suitable for implementing embodiments of this disclosure, entirely within the scope of this disclosure. This can include tablet devices, smartphones, password input devices, and any other computer devices, whether mobile or even distributed across a network (i.e., cloud-based).

[0121] Unless otherwise expressly stated, it will be apparent from the following discussion that throughout the discussion of this specification, the use of terms such as “processing,” “calculation,” “operation,” “determine,” “analysis,” etc., refers to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulates and / or converts data represented as physical (e.g., electronic) quantities into other data similarly represented as physical quantities.

[0122] In a similar manner, the term "processor" can refer to any device or part of a device that processes electronic data, for example, from registers and / or memory, to convert that electronic data into other electronic data that can be stored, for example, in registers and / or memory. "Computer," "computing machine," "computing platform," "computing device," or "server" can include one or more processors.

[0123] Figure 13 A computer system designated 1300 is illustrated. Computer system 1300 may include a set of instructions that can be executed to cause computer system 1300 to perform any one or more methods or computer-based functions disclosed herein. Computer system 1300 may operate as a stand-alone device or may be connected to other computer systems or peripheral devices, for example, via a network.

[0124] In a networked deployment, computer system 1300 can operate as a server, a client computer in a server-client network environment, or a peer-to-peer computer system in a point-to-point (or distributed) network environment. Computer system 1300 can also be implemented as or incorporated into various devices, such as personal computers (PCs), tablet PCs, set-top boxes (STBs), personal digital assistants (PDAs), mobile devices, handheld computers, laptops, desktop computers, communication equipment, cordless phones, landline phones, control systems, cameras, scanners, fax machines, printers, pagers, personal trusted devices, network devices, network routers, switches or bridges, or any other machine capable of executing a set of instructions (sequentially or otherwise) specifying the actions the machine should take. In a particular implementation, computer system 1300 can be implemented using electronic devices that provide voice, video, or data communication. Furthermore, although a single computer system 1300 is illustrated, the term "system" should also be understood to include any system or collection of subsystems that individually or jointly execute one or more sets of instructions to perform one or more computer functions.

[0125] like Figure 13 As illustrated, computer system 1300 may include processor 1302, such as a central processing unit (CPU), graphics processing unit (GPU), or both. Processor 1302 can be a component in various systems. For example, processor 1302 may be part of a standard personal computer or workstation. Processor 1302 may be one or more general-purpose processors, digital signal processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), servers, networks, digital circuits, analog circuits, combinations thereof, or other devices now known or hereafter developed for analyzing and processing data. Processor 1302 may implement software programs, such as manually generated (i.e., programmed) code.

[0126] Computer system 1300 may include memory 1304 communicatable via bus 1308. Memory 1304 may be main memory, static memory, or dynamic memory. Memory 1304 may include, but is not limited to, computer-readable storage media, such as various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media, etc. In one embodiment, memory 1304 includes a cache or random access memory for processor 1302. In alternative embodiments, memory 1304 is separate from processor 1302, such as processor cache memory, system memory, or other memory. Memory 1304 may be an external storage device or database for storing data. Examples include hard disk drives, optical discs (“compact disc CD”), digital video discs (“digital video disc DVD”), memory cards, memory sticks, floppy disks, universal serial bus (“universal serial bus USB”) memory devices, or any other device operable to store data. Memory 1304 is operable to store instructions executable by processor 1302. Functions, actions, or tasks illustrated in the figures or described herein can be performed by a programmed processor 1302 that executes the instructions stored in memory 1304. Functions, actions, or tasks are independent of a particular type of instruction set, storage medium, processor, or processing strategy, and can be performed individually or in combination by software, hardware, integrated circuits, firmware, microcode, etc. Similarly, processing strategies can include multiprocessing, multitasking, parallel processing, etc.

[0127] As shown in the figure, the computer system 1300 may further include a display unit 1310, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid-state display, a cathode ray tube (CRT), a projector, a printer, or other display devices now known or later developed for outputting specific information. The display 1310 may serve as an interface for a user to view the functions of the processor 1302, or specifically as an interface with software stored in the memory 1304 or the driver unit 1306.

[0128] Additionally or alternatively, computer system 1300 may include input device 1312, which is configured to allow a user to interact with any component of system 1300. Input device 1312 may be a numeric keypad, keyboard, or cursor control device, such as a mouse or joystick, touchscreen display, remote control, or any other device operable to interact with computer system 1300.

[0129] Computer system 1300 may also, or alternatively, include a disk or optical disk drive unit 1306. Disk drive unit 1306 may include computer-readable medium 1322 in which one or more sets of instructions 1324, such as software, may be embedded. Furthermore, the instructions 1324 may embody one or more methods or logic described herein. The instructions 1324 may reside wholly or partially in memory 1304 and / or processor 1302 during execution of computer system 1300. Memory 1304 and processor 1302 may also include computer-readable media as discussed above.

[0130] In some systems, computer-readable medium 1322 includes instructions 1324 or instructions 1324 received and executed in response to a propagation signal, enabling devices connected to network 1370 to transmit voice, video, audio, images, or any other data through network 1370. Furthermore, instructions 1324 can be sent or received on network 1370 via communication port or interface 1320 and / or bus 1308. Communication port or interface 1320 may be part of processor 1302 or may be a separate component. Communication port 1320 may be created in software or may be a physical connection in hardware. Communication port 1320 may be configured to connect to network 1370, external media, display 1310, or any other component or combination thereof in system 1300. Connection to network 1370 may be a physical connection, such as a wired Ethernet connection, or may be a wireless connection as discussed below. Similarly, additional connections to other components of system 1300 may be physical connections or wireless connections. Network 1370 may alternatively be directly connected to bus 1308.

[0131] Although computer-readable medium 1322 is shown as a single medium, the term "computer-readable medium" can include a single medium or multiple media, such as a centralized or distributed database, and / or an associated cache and server storing one or more sets of instructions. The term "computer-readable medium" can also include any medium capable of storing, encoding, or carrying a set of instructions executable by a processor or causing a computer system to perform any one or more methods or operations disclosed herein. Computer-readable medium 1322 can be non-transitory and can be tangible.

[0132] Computer-readable medium 1322 may include solid-state memory, such as a memory card or other package housing one or more non-volatile read-only memories. Computer-readable medium 1322 may be random access memory or other volatile rewritable memory. Additionally or alternatively, computer-readable medium 1322 may include magneto-optical or optical media, such as disks or magnetic tapes or other storage devices, to capture carrier signals, such as signals communicated via a transmission medium. Digital file attachments to emails or other independent electronic information archives or sets of archives can be considered distribution media, which are tangible storage media. Therefore, this disclosure is considered to include any one or more computer-readable media or distribution media, as well as other equivalents and subsequent media, in which data or instructions may be stored.

[0133] In alternative implementations, specialized hardware implementations, such as application-specific integrated circuits (ASICs), programmable logic arrays (PLA), and other hardware devices, can be constructed to implement one or more methods described herein. Applications that can include various implementations of the apparatus and systems can broadly encompass a wide range of electronic and computer systems. One or more implementations described herein may use two or more specific interconnected hardware modules or devices to implement functionality, having associated control and data signals that can communicate between and through modules, or as part of an ASIC. Therefore, this system encompasses software, firmware, and hardware implementations.

[0134] Computer system 1300 can connect to one or more networks 1370. Network 1370 can define one or more networks, including wired or wireless networks. Wireless networks can be cellular telephone networks, 802.11, 802.16, 802.20, or WiMAX networks. Furthermore, such networks can include public networks (such as the Internet), private networks (such as intranets), or combinations thereof, and can utilize various network protocols now available or developed in the future, including but not limited to TCP / IP-based network protocols. Network 1370 can include wide area networks (WANs) (such as the Internet), local area networks (LANs), campus networks, metropolitan area networks, direct connections (such as via a Universal Serial Bus (USB) port), or any other network that allows data communication. Network 1370 can be configured to couple one computing device to another to enable data communication between devices. Network 1370 can generally be enabled to use any form of machine-readable medium to transfer information from one device to another. Network 1370 can include communication methods that allow information to be transferred between computing devices. Network 1370 can be divided into subnets. A subnet can allow access to all other components connected to it, or a subnet can restrict access between components. Network 1370 can be considered a public or private network connection and can include, for example, a virtual private network or encryption or other security mechanisms employed over the public Internet.

[0135] According to various embodiments of this disclosure, the methods described herein can be implemented by computer system executable software programs. Furthermore, in exemplary, non-limiting embodiments, implementations may include distributed processing, component / object distributed processing, and parallel processing. Alternatively, virtual computer systems may be constructed to implement one or more of the methods or functions described herein.

[0136] Although this specification describes components and functions that can be implemented in a particular specific implementation with reference to specific standards and protocols, this disclosure is not limited to such standards and protocols. For example, standards for transmission on the Internet and other packet-switched networks (e.g., TCP / IP, UDP / IP, HTML, HTTP, etc.) represent examples of prior art. These standards are regularly superseded by faster or more efficient equivalents with substantially the same functionality. Therefore, alternative standards and protocols with the same or similar functionality as those disclosed herein are considered their equivalents.

[0137] It will be understood that, in one embodiment, the steps of the discussed method are performed by a suitable processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in a storage device. It will also be understood that the disclosed embodiments are not limited to any particular specific implementation or programming technique, and that the disclosed embodiments can be implemented using any suitable technique for achieving the functionality described herein. The disclosed embodiments are not limited to any particular programming language or operating system.

[0138] It should be understood that in the foregoing description of exemplary embodiments, features of various embodiments are sometimes combined in a single embodiment, drawing, or description therein in order to simplify this disclosure and aid in understanding one or more of the various inventive aspects. However, this approach to disclosure should not be construed as reflecting an intention that the claimed embodiment requires more features than expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are expressly incorporated herein, each claim being a separate embodiment in itself.

[0139] Furthermore, while some embodiments described herein include features included in other embodiments but not others, combinations of features from different embodiments are intended to fall within the scope of this disclosure and form different embodiments, as will be understood by those skilled in the art. For example, in the appended claims, any claimed embodiment may be used in any combination.

[0140] Furthermore, some embodiments herein are described as methods or combinations of method elements that can be implemented by a processor of a computer system or by other means of performing functions. Thus, a processor having the instructions necessary to perform such methods or method elements forms a means for performing such methods or method elements. Moreover, the elements of the apparatus embodiments described herein are examples of means for performing the functions executed by those elements to achieve those functions.

[0141] Numerous specific details are set forth in the description provided herein. However, it should be understood that embodiments of this disclosure can be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description.

[0142] Similarly, it should be noted that the term "coupling" when used in claims should not be construed as limited to direct connections. The terms "coupling" and "connection," and their derivatives, may be used. It should be understood that these terms are not intended to be synonyms with each other. Therefore, the scope of the statement "device A coupled to device B" should not be limited to devices or systems in which the output of device A is directly connected to the input of device B. This implies the existence of a path between the output of A and the input of B, which can be a path that includes other devices or means. "Coupling" may mean two or more elements in direct physical or electrical contact, or two or more elements that are not in direct contact with each other but still cooperate or interact with each other.

[0143] Therefore, although what is considered a preferred embodiment of this disclosure has been described, those skilled in the art will recognize that other and further modifications can be made thereto without departing from the spirit of this disclosure, and all such changes and modifications falling within the scope of this disclosure are intended to be claimed. For example, any formulas given above are merely representative processes that can be used. Functions can be added or removed from the block diagrams, and operations can be interchanged between functional blocks. Steps can be added or removed from the methods described within the scope of this disclosure.

[0144] The subject matter disclosed above should be considered illustrative rather than restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other implementations falling within the true spirit and scope of this disclosure. Therefore, to the maximum extent permitted by law, the scope of this disclosure should be determined by the broadest permissible interpretation of the following claims and their equivalents, and should not be limited or constrained by the foregoing detailed description. Although various implementations of this disclosure have been described, it will be apparent to those skilled in the art that further implementations are possible within the scope of this disclosure. Therefore, this disclosure is not limited except as provided in the appended claims and their equivalents.

Claims

1. A computer-implemented method for aggregating and mapping event features to daily profiles, the method comprising: Receive a set of historical data objects, which indicate the occurrence of a set of events, each event being associated with a set of configurable items; Determine a single event profile for each of the historical data objects; Determine an integrated single event profile for each of the historical data objects; The integrated single event profile is aggregated by day. as well as Output the integrated single event profile according to the stated day dimension.

2. The method according to claim 1, wherein the set of historical data objects represents the occurrence of the set of events within at least one month.

3. The method according to claim 1, wherein determining a single event profile for each of the historical data objects comprises: Features are determined from the textual description of the historical data objects; Perform a clustering algorithm on the features; as well as A cluster is determined for each of the historical data objects.

4. The method according to claim 3, further comprising: The first set of features is determined using term frequency-inverse document frequency vectorization; The second set of features was determined using noun phrase extraction. as well as The third set of features was determined by extracting verb phrases.

5. The method according to claim 4, wherein the clustering algorithm is applied to the first group of features, the second group of features, and the third group of features, respectively.

6. The method according to claim 1, wherein determining the integrated single event profile for each of the historical data objects further comprises: A clustering algorithm is applied to the integrated single event profile; as well as Save a single event cluster for each historical data object.

7. The method according to claim 6, wherein aggregating the integrated single event profile by day dimension further includes: A clustering algorithm is performed on the integrated single event profile, wherein the single event profile by day dimension has the aggregated result of all single event clusters for each historical data object within a day.

8. The method according to claim 1, wherein outputting the integrated single event profile according to the daily dimension includes: Output the number of events received within a certain period of time, as well as the number of individual event profiles identified.

9. The method according to claim 1, wherein outputting the integrated single event profile according to the daily dimension includes: Compile and output the total number of events received on a specific day, as well as a corresponding single event profile for each event.

10. A system for aggregating and mapping event features to daily profiles, the system comprising: Memory, wherein the memory stores processor-readable instructions; as well as At least one processor, configured to access the memory and execute processor-readable instructions to perform operations, said operations including: Receive a set of historical data objects, which indicate the occurrence of a set of events, each event being associated with a set of configurable items; Determine a single event profile for each of the historical data objects; Determine an integrated single event profile for each of the historical data objects; The integrated single event profile is aggregated by day; and Output the integrated single event profile according to the stated day dimension.

11. The system of claim 10, wherein the set of historical data objects represents the occurrence of the set of events within at least one month.

12. The system of claim 10, wherein determining a single event profile for each of the historical data objects comprises: Features are determined from the textual description of the historical data objects; Perform a clustering algorithm on the features; as well as A cluster is determined for each of the historical data objects.

13. The system of claim 12, further comprising: The first set of features is determined using term frequency-inverse document frequency vectorization; The second set of features was determined using noun phrase extraction. as well as The third set of features was determined by extracting verb phrases.

14. The system of claim 13, wherein the clustering algorithm is applied to the first set of features, the second set of features, and the third set of features, respectively.

15. The system of claim 10, wherein determining the integrated single event profile for each of the historical data objects further comprises: A clustering algorithm is applied to the integrated single event profile; as well as Save a single event cluster for each historical data object.

16. The system of claim 15, wherein the aggregated single event profile by day dimension further includes: A clustering algorithm is performed on the integrated single event profile, wherein the single event profile by day dimension has the aggregated result of all single event clusters for each historical data object within a day.

17. The system of claim 10, wherein outputting the integrated single event profile according to the daily dimension includes: Output the number of events received within a certain period of time, as well as the number of individual event profiles identified.

18. The system of claim 10, wherein outputting the integrated single event profile according to the daily dimension includes: Compile and output the total number of events received on a specific day, as well as a corresponding single event profile for each event.

19. A non-transitory computer-readable medium storing processor-readable instructions, which, when executed by at least one processor, cause the at least one processor to perform an operation, the operation comprising: Receive a set of historical data objects, which indicate the occurrence of a set of events, each event being associated with a set of configurable items; Determine a single event profile for each of the historical data objects; Determine an integrated single event profile for each of the historical data objects; The integrated single event profile is aggregated by day. as well as Output the integrated single event profile according to the stated day dimension.

20. The non-transitory computer-readable medium of claim 19, wherein the set of historical data objects represents the occurrence of the set of events within at least one month.

Images