Event prediction using artificial intelligence

Provided techniques manage and predict future events. For example, in a payment implementation, a supplier, at any given point in time, has multiple customer debtors that may owe payments (e.g., have outstanding invoices). Utilizing historical attributes for a given customer debtor payment predictions may be determined. By analyzing outstanding debts associated with this debtor customer an amount owed may be calculated and a predicted payment (e.g., a payment that has not yet been indicated by that debtor customer) created. Events may be provided to a second system to correlate predictions across multiple debtor collectors. Correlated information may be used to predict cash flow needs of an organization. Alternatively, optimization of help desk systems may be provided based on predictions from analysis of multiple events in an Event-driven feed back system. Provided techniques may be generalized to other applications as well.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of Indian Appl. No. 201941006159, filed Feb. 15, 2019. This application is incorporated herein by reference in its entirety to the extent consistent with the present application.

BACKGROUND

An event in a computer system may be used to represent an identifiable occurrence which could be significant for a particular computer application executing on one or more computing systems. Computer systems include hardware, software or both. In most instances, events may be generated algorithmically via the operation of a mechanical process or computing system, or intuitively via direct and/or indirect interaction with a user. An event-driven system is one example category of computing system. Other categories may include queue-based systems or batch processing systems. In an Event-driven system, events (or messages) may be used by one or more component(s) of hardware and/or software to indicate that an action may be expected on the part of a computer process (e.g., a process executing on a computer system as controlled by an operating system).

Some event-driven systems may be one-way channels for the generation of events that are sometimes acted upon without feedback. Other event-driven systems may be interactive, with the generation of events initiating generation of additional but corresponding events that may be sent back to the original event source (e.g., a feedback to an original event) for handling (e.g., as a response message via an event). Event-driven systems of different possible types may be built for immediate event handling. Alternatively, an event-driven system may be built with an expectation of time for the handling of an event (other implementations are also possible). With respect to a two-way event-driven system (e.g., a system with responsive feedback), events may arrive prior to being ready to be handled by the receiving system. Sometimes an unexpected arrival of an event response may result in undesired effects in event handling.

Disclosed systems and techniques address the above problems and others, in part, by utilizing historical information, machine learning, and artificial intelligence to address feedback timing with respect to automated event loops for expected response times and abnormal response events.

DETAILED DESCRIPTION

What is needed to address the above-mentioned problems is a system which can record information on the timeliness of event responses. For example, a system that may use information about timeliness of response and extrapolate, over a period of time, to form a prediction of when the generation of response events may result in a more reliable outcome. Additionally, such a system might incorporate a capability to create recommendations on the appropriate timeliness of events. For example, recommendations based on feedback information obtained or derived from historical event processing. Such recommendations may further be delivered for consideration and conditional use by users acting as system administrators, or algorithmically employed by the responding computer system in an automated fashion.

One example of a computer system that may be implemented using event generation and response techniques is an accounting system. In an accounting system, accounts receivable (A/R) represents the dollar value of business that a company has transacted for which it has not yet received payment. This expected cash flow appears on the “assets” side of a balance sheet. However, it is not uncommon for mismanaged cash by an entity to create a cash flow issue for that entity. Thus, a poorly managed A/R system may provide impediments to an organization that manages complex financial situations. This disclosure introduces techniques to use an event generation/response computer system, augmented with artificial intelligence (AI) techniques, to address one or more problems of an A/R system. For example, some implementations of this disclosure assist in reducing outstanding receivables through improved collections strategies. Disclosed techniques further illustrate how Machine Learning (ML) and AI, using historical data from accounts receivable transactions, may be used with respect to A/R financials to make predictions that are more accurate than traditional estimation metrics, such as Average Days Delinquent (ADD). In short, disclosed techniques improve and enhance the collections process and other aspects of computer implemented accounting systems, in part, by improving the functioning of the computer system tasked to support an A/R function.

In today's corporate credit environment, a supplier sells goods to a buyer; however, the buyer does not always pay upfront and instead may use some sort of credit-based payment system. In many cases, there are contracts in place for a buyer to pay an invoiced amount after a stipulated period. In collection's terminology, this is sometimes referenced as “due date.” For example, sales where the payment is not done as soon as the invoice is generated may be referred to as “credit sales.” A single supplier will likely have multiple buyers that are associated with multiple invoices that may be generated on a daily basis or multiple times in a given month. This disclosure presents techniques to implement a computer-based system to assist a collector (and therefore the seller) in managing payments with respect to one or more outstanding (e.g., not yet paid or reconciled) invoices. Disclosed techniques may also utilize AI techniques to provide predictions (i.e., future guesses) of possible payment at a per user (buyer also referred to as a customer debtor) level.

A seller that generates many invoices may have a dedicated team to manage collectibles in the form of Accounts Receivable (AR) that are managed by collectors (i.e., the team). Each of the collectors and the team in general, have a goal of collecting as much money as possible and as soon as possible. In general, an efficient collections process assists a business with managing cash flow and protecting the business from unexpected events such as a buyer filing bankruptcy (or the like).

Historically, collections processes have been largely reactive and manually intensive. Further, traditional systems may react to due dates as the pivot to initiate dunning activity (e.g., demands or follow up requests for payments). Accordingly, traditional systems are not as efficient and reliable as may be possible. This disclosure presents an improvement to the function of a computer system with respect to A/R processing. Further, disclosed techniques are not limited to A/R processing. Disclosed techniques may be generally applicable to any system that utilizes an event feedback loop where timing of a response event (e.g., the response event to close the loop based on an originally generated event) may have a variable response. The variability of the response may be based on, for example, activities outside the scope of the event-based system. Specifically, response events that rely on an action taken by a user in a help-desk scenario or a customer with respect to paying an outstanding invoice. In the help-desk scenario, it may not be possible to close a trouble ticket until a user provides feedback with respect to a previously applied update to their system. That is, the user may have to execute a diagnostic (or otherwise become satisfied that their issue is solved) before the trouble ticket may be closed. In this situation, the help desk attendant relies upon the user to complete an action and respond with information regarding the results of that action for the help desk attendant's “outstanding tickets” queue to be reduced.

In the context of an A/R system, an initiating event for an event loop may be considered to be generated when an invoice is sent to a consumer. Alternatively, an initiating event may be based on an invoice due date (or a due date being shifted into a larger aging bucket as described in more detail below with reference toFIG. 5). In any case, initiating events in a two-way event system may be closed when a corresponding response event is provided.

The majority of collections operations, including account prioritization, correspondence strategies, and customer collaboration, are typically based on static parameters such as aging bucket and invoice value. As a result, a cluttered collections worklist (e.g., collection tasks) may be presented to a collections analyst. Inefficient identification of delinquent accounts and wasted collections efforts may result from such improperly prioritized set of tasks for the collections analyst. Further, due to the absence of a scalable collections process of previous systems, which may fail to consider dynamic parameters, the collections team may focus only past due A/R. Thus, overall team productivity may be reduced due to labor-intensive, time-consuming, low-value tasks. Tasks performed by a collections analyst, using a system without the benefits of this disclosure, may include enterprise resource processing (ERP) data extraction, manual worklist creation, and correspondence with non-critical customers. The key fallouts of an inefficient workflow may include a slower cash conversion cycle, increasing Days Sales Outstanding (DSO), inefficient processes and higher operational costs.

Disclosed systems may allow transition from a reactive to a proactive collections process. Specifically, using ML “under the hood,” the collections team may be able to leverage high-impact predictions to enhance collections output and key performance indicators (KPIs) such as DSO and Collection Effectiveness Index (CEI). Predicting payment date and delay, using a system of this disclosure, may further consider dynamic changes in customer behavior when formulating dunning rules and strategies. Further, customer collaboration could be tailored and personalized by analyzing customer preferences in terms of time, day of the week, and mode preferred for communication and with insights on identifying which dunning letters work best for each customer.

In some disclosed implementations, one or more ML algorithms may be used to identify relevant variables and analyze valuable patterns in the collections cycle to make an educated guess on the payment date for each customer. ML techniques may be used, in conjunction with AI, to process, analyze, and identify patterns discernable from within a potentially large volume of historical data available for each customer. As a result, disclosed techniques may be able to predict the payment date at an invoice level for all customers and help the collections teams become proactive through improved dunning strategies.

Referring toFIG. 1A, an example path100to follow with respect to an event resolution life-cycle is illustrated, according to one or more disclosed implementations. The life-cycle of this generic event represents actions taken from initial event generation until ultimate resolution. Actions may include generating one or more sub-events that each may have their own (possibly independent) life-cycle. Example path100represents a general event life-cycle that may be used for any two-way event processing system that relies on external events for ultimate resolution. As mentioned above, one example of such a system may be a help-desk where a trouble ticket represents initial event105. After the event is generated, the help-desk attendant may apply a patch to correct a computer defect. Application of the patch, in this example, may result in flow to resolved block107and an attribute of this resolution may reflect that the resolution was supplied either in an acceptable amount of time (e.g., ON-TIME block115) or may have been outside of a service level agreement (SLA) and thus reflect a delayed status (e.g., DELAYED block116).

Alternatively, the trouble ticket may require an action on the part of a user for which the patch is being applied. Thus, the user may provide the help-desk attendant with a commitment to resolve as illustrated in block109. In this example, the commitment to resolve may be an action such as a test that the user must perform to validate the patch by a promised date/time. Flow in this path may continue to either block117where the user “kept” their commitment to resolve (i.e., completed the test as promised) or may continue to block118where the user failed to perform their action as promised (i.e., a broken promise). In yet another example, block111indicates that an exception may be raised. In this example, the user may be out of the office unexpectedly (e.g., they did not take this absence into account when the commitment was provided, or some other factor may cause the exception). In any case, after exception at block111, flow may still continue to block119where the original event is resolved on-time or flow may continue to block120to represent a delay in resolution.

Referring toFIG. 1B, an example path150to follow with respect to event a resolution life-cycle for an invoice of an A/R system is illustrated, according to one or more disclosed embodiments. The life-cycle of this invoice event represents actions taken from initial invoice generation until ultimate resolution (e.g., in the form of a payment or deduction). In a similar manner to example path100, example path150indicates that actions may include generating one or more sub-events that each may have their own (possibly independent) life-cycle. Example path150represents an invoice event life-cycle may be implemented using a two-way event processing system that relies on external events (e.g., payment or further information from a customer) for ultimate resolution. In the context of the invoice life-cycle of example path150, after the invoice is generated, the customer may simply pay the invoice. This payment may result in flow to PAID block157and an attribute of this resolution may reflect that the payment was supplied either in an acceptable amount of time (e.g., ON-TIME block165) or may have been outside of a payment period (sometimes referred to as grace period) and thus reflect a delayed status (e.g., DELAYED block166).

In general, an invoice event requires an action on the part of a customer to which the invoice is provided. Sometimes, automated payment systems may automatically pay invoices and in other cases an interactive action may be required on the part of the customer to cause payment to happen. In one simple example, a customer may have an automatic payment system that habitually provides payment after the due date but within the grace period. Accordingly, having a collections analyst contact that customer on the due date would likely be a waste of effort on the part of the collections analyst. Thus, historical analysis may be used for this customer (as discussed in more detail below) to lower the priority of required action on the part of the collections analyst for this customer. However, if the system recognizes that this customer “always” pays5business days after the due date and the outstanding debt is 7 days delinquent, a contact for this customer may rise to a very high priority. In general, abnormal interactions with different customers may be taken into account (e.g., using ML and AI) to set proper priorities for a collections analyst to achieve efficient results.

Continuing with example path150, the user may provide the collections analyst with a commitment to resolve, which for an invoice may be a promise to pay on a certain date, as illustrated in block159. Flow in this path may continue to either block167where the customer “kept” their commitment to resolve (i.e., paid the invoice as promised) or may continue to block168where the user failed to perform their action as promised (i.e., a broken promise to pay). In yet another example, block161indicates that an exception may be raised. In this example, exception may be a dispute in the invoice amount or a failure of delivery for services/goods expected on the part of the customer. In any case, after exception at block161, flow may still continue to block169where the invoice payment is received on-time or flow may continue to block120to represent a delay in payment of the invoice.

Referring now toFIG. 2A, a timeline200is illustrated as an example of actual payment date based on historical customer payment pattern. In this example an invoice is generated on February 20 at the start of timeline200. In this example the term of payment is 30 days (e.g., net30) and the invoice is initially due on March 22 as indicated. March 22 also indicates the start of time periods205and206. In this example, there is an ADD estimated delay of 7 days (illustrated by time period206) from the due date of March 22 to receive payment on March 29. Also, in this example, there is an actual delay of 12 days to receive actual payment on April 3 (illustrated by time period205). These metrics may be stored and associated with a particular customer as an indication of their historical payment behavior.

Referring now toFIG. 2B, a timeline250is illustrated as another example of an invoice life-cycle with payment being received having actual delay (indicated by time period210) of less than ADD estimated delay (indicated by time period211). This example may represent a reduction in a delay to collect invoice payment and correspondingly reduce time to obtain a response event to close the two-way event cycle of this example A/R system. This reduction may result from proactive notification to a customer as described in more detail below (SeeFIGS. 6 and 7).

Referring now toFIG. 3A, timeline300illustrates an event cycle that begins with an event being dispatched and ends with an event being resolved. This timeline may be representative of a generic two-way event system implementation. Time period305represents the delay in resolution from resolution due date till event is resolved and includes an escalation occurring after the due date is missed in an effort to get the event resolved. The escalation may be a follow-up to an entity (or computer process) that is being waited on for the response event.

Timeline320illustrates a second event cycle that begins with an event being scheduled for resolution and again ends with the event being resolved. However, in this case, a follow-up for event resolution may take place prior to that event's scheduled resolution. This follow-up may be based on a prediction that the proposed schedule will not be met. For example, if an action associated with a response event is further associated with an actor that is historically delinquent, a prediction of tardiness may be provided to cause proactive escalation to query about the response event. As a result, delay in resolution as indicated by time period325may be reduced. That is, the resolution is not on-time, but it is not as delayed as it might have been without proactive escalation.

Referring now toFIG. 3B, timeline340illustrates a sequence of events beginning with an event being generated and dispatched and ending with an event resolution. Time period345illustrates a delay in event resolution based on a system that detects that an exception has been entered (e.g., reactive system). In contrast, timeline360illustrates a possible reduction in delay in event resolution (indicated by time period365) by using a system that proactively predicts that an exception is going to be entered. By initiating research and resolution of a predicted exception ahead of the event due for resolution-time, overall delay to event resolution may be reduced.

Referring now toFIGS. 4A-4C, different timelines with respect to invoice processing are presented.FIG. 4Aincludes timeline400where a follow-up is initiated in a reactive manner based on missed due date and reflects a delay in payment as indicated by time period405. Timeline420ofFIG. 4Aillustrates an example where a follow up on a broken promise to pay results in a delay in payment as indicated by time period425.FIG. 4Bincludes timeline440where a collector discovers a dispute after an invoice due date resulting in delay in payment as represented by time period445. In contrast, timeline460illustrates a proactive research activity by a collector (ahead of invoice due date) that results in a delay in payment as indicated by time period465. Note that proactive research may be initiated using AI/ML prediction techniques of this disclosure based on historical events having similar attributes to an event in an active life-cycle.FIG. 4Cincludes timeline480that illustrates proactive follow-up on a promise to pay date that has not yet arrived resulting in a delay in payment as indicated by time period485. Finally, timeline490illustrates a proactive prediction of dispute for an invoice (again based on AI/ML techniques using historical data that aligns with this event in some manner) prior to the invoice due date and results in a delay in payment as indicated by time period495.

Referring now toFIG. 5, histogram500indicates that different events (e.g., invoice events) may be grouped together in different aging buckets. In the context of an A/R system, these different aging buckets may be used for prediction and escalation for collection activity. Specifically, many invoice payment schedules are based on a 30 day time period, such that, if an invoice payment is missed by a consumer (or purchaser business) it is likely that the business or consumer will not pay anything until the next 30 day cycle. Thus, the older the bucket that invoices are grouped into (particularly past 60 days), the more likely that customer will require an assertive collection action to be persuaded to resolve the outstanding debt. In the context of a help-desk system, aging buckets may be used to automatically close outstanding tickets, in part, because the longer a ticket remains open the less likely that the user originating the ticket is still interested in a resolution (or the previously applied solution corrected the issue).

Referring now toFIG. 6, a flow diagram is illustrated as an example method600for utilizing AI/ML techniques and historical information to form a proactive and predictive A/R system in accordance with disclosed techniques. Example method600further illustrates possible functional modules and interaction between those modules. Note that each illustrated functional module may internally utilize methods and techniques (not shown) to perform their part of the overall method600.

Example method600begins with historical behavior605. Historical behavior605may be collected as data representative of many different customers and many different invoice events. This data may be correlated and aggregated to form a repository of information for ML/AI processing. One or more ML algorithms610may process one or more ML models615to provide predictions of payment dates625. New invoices620with scheduled payment dates may be included within predictions of payment dates625. For example, with their initial due date as the initial prediction date. Flow from prediction of payment dates625continues to one of three outputs.

A first of the three outputs or events is represented by predicted on-time payment631, a second is predicted delayed payment632(e.g., delay of under 60 days of due date), and the third is predicted very delayed payment633(e.g., delay of over 60 days past due date). Also, a suggestion of action may be made for each invoice. These suggested actions may be based on the correlation and analysis provided as part of example method600. Specifically, some invoices may be processed with mild actions636, other invoices that are at a slightly higher risk may be processed with general actions637, and a final grouping of invoices may be processed with strict actions638.

Each action is selected from a set of suggested actions having different severities. The suggested action is associated with a lower severity when the predicted payment time is nearer a current date and a higher severity when the predicted payment time is further from the current date. The different severities range from mild actions to general actions to strict actions with the mild actions being less severe than the general actions and the general actions being less severe than the strict actions. In general, these actions may overlap in their suggestions with higher risk and higher priority actions being more intrusive on a customer debtor. For example, a mild action may be to send an email reminder that the customer will likely see when they are sitting at their work computer. A general action could be a text messages delivered at a particular time of day to the customer's cell phone (e.g., an interruption message). A strict action may be an actual phone call to a customer or even initiation of a demand later requiring “payment or risk legal action.”

Each of these types of actions are variable and there may be more than three levels in an actual implementation. In any case, the prediction engine (not shown) may be a functional module that uses prediction of payment dates625and other customer centric (or invoice centric) information to determine a proper proactive escalation for a particular invoice.

Actual payments640represent resolutions to invoice generation events and (as illustrated by a feedback loop) may contain information that may be utilized to retrain models for future use. The method might further include calculating a total amount outstanding in debts relative to the first debtor customer and providing the total amount outstanding to a collections analyst. Additionally, the method might include performing a roll-up calculation across a set of debtor customers, including the first debtor customer and one or more additional debtor customers, as part of a cash flow analysis for a supplier or a collector.

Referring now toFIG. 7, another example method700is illustrated to show functional modules and process flows for a prediction with respect to promises to resolve responses (e.g., from previous escalations), according to one or more disclosed implementations. Example method700begins at historical information705which may, in this example, be a previous commitment made by this customer (or a customer in a similar situation as determined by historical trends). ML algorithms710represent ML/AI techniques that may be used to process data and act on ML models715(using historical info705as input). Prediction of promises725may have as input the historical information705already described and may receive input of new commitments720. Flow from prediction of promises725may arrive, in this example, at one of two outcomes. Namely, the promise may be expected to be reliably kept731or determined to be likely broken732. This indication may result from a reliability factor associated with the customer or invoice type being processed. For example, invoices with larger amounts of money may have a higher (or lower) likelihood of being honored by different customers. As illustrated, a promise that is likely to be kept may have a lower priority736than suspect promises. A promise that is unlikely to be kept732may require proactive actions and be designated with a grouping of higher priority737. In either case, flow continues to an actual result of kept or broken740. Finally, as illustrated, a feedback loop from actual result740to ML models715represents that information associated with each invoice may be collected and utilized for future processing and possible alteration of (retraining) ML models715.

FIG. 8is an example computing device800, with a hardware processor801, and accessible machine-readable instructions stored on a machine-readable medium802that may be used to support the above discussed development and execution of an A/R system using prediction techniques, according to one or more disclosed example implementations.FIG. 8illustrates computing device800configured to perform the flow of method600or700as an example. However, computing device800may also be configured to perform the flow of other methods, techniques, functions, or processes described in this disclosure. In this example ofFIG. 8, machine-readable storage medium802includes instructions to cause hardware processor801to perform blocks605-640and/or705-740discussed above with reference toFIGS. 6 and 7respectively.

A machine-readable storage medium, such as802ofFIG. 8, may include both volatile and nonvolatile, removable and non-removable media, and may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions, data structures, program module, or other data accessible to a processor, for example firmware, erasable programmable read-only memory (EPROM), random access memory (RAM), non-volatile random access memory (NVRAM), optical disk, solid state drive (SSD), flash memory chips, and the like. The machine-readable storage medium may be a non-transitory storage medium, where the term “non-transitory” does not encompass transitory propagating signals.

FIG. 9represents a computer network infrastructure900that may be used to implement all or part of the disclosed techniques of this disclosure. For example, an event prediction system901may be implemented on compute resource906B and interact with other devices of network infrastructure900. As illustrated, network infrastructure900includes a set of networks where embodiments of the present disclosure may operate (e.g., components shown may execute a resultant enhanced A/R system). Network infrastructure900comprises a customer network902, network908, cellular network903, and a cloud service provider network910. In one embodiment, the customer network902may be a local private network, such as local area network (LAN) that includes a variety of network devices that include, but are not limited to switches, servers, and routers.

Each of these networks can contain wired or wireless programmable devices and operate using any number of network protocols (e.g., TCP/IP) and connection technologies (e.g., WiFi® networks, or Bluetooth®. In another embodiment, customer network902represents an enterprise network that could include or be communicatively coupled to one or more local area networks (LANs), virtual networks, data centers and/or other remote networks (e.g.,908,910). In the context of the present disclosure, customer network902may include multiple devices configured with the disclosed prediction processing techniques such as those described above. Also, one of the many computer storage resources in customer network902(or other networks shown) may be configured to store the historical information and models as discussed above.

As shown inFIG. 9, customer network902may be connected to one or more client devices904A-E and allow the client devices904A-E to communicate with each other and/or with cloud service provider network910, via network908(e.g., Internet). Client devices904A-E may be computing systems such as desktop computer904B, tablet computer904C, mobile phone904D, laptop computer (shown as wireless)904E, and/or other types of computing systems generically shown as client device904A.

Network infrastructure900may also include other types of devices generally referred to as Internet of Things (IoT) (e.g., edge IOT device905) that may be configured to send and receive information via a network to access cloud computing services or interact with a remote web browser application (e.g., to receive information from a user).

FIG. 9also illustrates that customer network902includes local compute resources906A-C that may include a server, access point, router, or other device configured to provide for local computational resources and/or facilitate communication amongst networks and devices. For example, local compute resources906A-C may be one or more physical local hardware devices, such as the different configurations of AI/ML processing systems outlined above. Local compute resources906A-C may also facilitate communication between other external applications, data sources (e.g.,907A and907B), and services, and customer network902. Local compute resource906C illustrates a possible processing system cluster with three nodes. Of course, any number of nodes is possible, but three are shown in this example for illustrative purposes.

Network infrastructure900also includes cellular network903for use with mobile communication devices. Mobile cellular networks support mobile phones and many other types of mobile devices such as laptops etc. Mobile devices in network infrastructure900are illustrated as mobile phone904D, laptop computer904E, and tablet computer904C. A mobile device such as mobile phone904D may interact with one or more mobile provider networks as the mobile device moves, typically interacting with a plurality of mobile network towers920,930, and940for connecting to the cellular network903. In the context of the current monitoring and event ingestion management, user alerts as to initiating of throttling actions may be configured to provide an end-user notification. In some implementations, this notification may be provided through network infrastructure900directly to a system administrators cellular phone.

Although referred to as a cellular network inFIG. 9, a mobile device may interact with towers of more than one provider network, as well as with multiple non-cellular devices such as wireless access points and routers (e.g., local compute resources906A-C). In addition, the mobile devices may interact with other mobile devices or with non-mobile devices such as desktop computer904B and various types of client device904A for desired services.

FIG. 9illustrates that customer network902is coupled to a network908. Network908may include one or more computing networks available today, such as other LANs, wide area networks (WAN), the Internet, and/or other remote networks, in order to transfer data between client devices904A-D and cloud service provider network910. Each of the computing networks within network908may contain wired and/or wireless programmable devices that operate in the electrical and/or optical domain.

InFIG. 9, cloud service provider network910is illustrated as a remote network (e.g., a cloud network) that is able to communicate with client devices904A-E via customer network902and network908. The cloud service provider network910acts as a platform that provides additional computing resources to the client devices904A-E and/or customer network902. In one embodiment, cloud service provider network910includes one or more data centers912with one or more server instances914. Each of these resources may work together with non-cloud resources to provide execution of or interface to deployed A/R system and ML models as discussed herein.

FIG. 10illustrates a computer processing device1000that may be used to implement the functions, modules, processing platforms, execution platforms, communication devices, and other methods and processes of this disclosure. For example, computing device1000illustrated inFIG. 10could represent a client device or a physical server device and include either hardware or virtual processor(s) depending on the level of abstraction of the computing device. In some instances (without abstraction), computing device1000and its elements, as shown inFIG. 10, each relate to physical hardware. Alternatively, in some instances one, more, or all of the elements could be implemented using emulators or virtual machines as levels of abstraction. In any case, no matter how many levels of abstraction away from the physical hardware, computing device1000at its lowest level may be implemented on physical hardware.

Computing device1000may be used to implement any of the devices that are used by developers to create an enhanced event processing system in accordance with one or more techniques of this disclosure. As also shown inFIG. 10, computing device1000may include one or more input devices1030, such as a keyboard, mouse, touchpad, or sensor readout (e.g., biometric scanner) and one or more output devices1015, such as displays, speakers for audio, or printers. Some devices may be configured as input/output devices also (e.g., a network interface or touchscreen display).

Computing device1000may also include communications interfaces1025, such as a network communication unit that could include a wired communication component and/or a wireless communications component, which may be communicatively coupled to processor1005. The network communication unit may utilize any of a variety of proprietary or standardized network protocols, such as Ethernet, TCP/IP, to name a few of many protocols, to effect communications between devices. Network communication units may also comprise one or more transceiver(s) that utilize the Ethernet, power line communication (PLC), WiFi, cellular, and/or other communication methods.

As illustrated inFIG. 10, computing device1000includes a processing element such as processor1005that contains one or more hardware processors, where each hardware processor may have a single or multiple processor core. In one embodiment, the processor1005may include at least one shared cache that stores data (e.g., computing instructions) that are utilized by one or more other components of processor1005. For example, the shared cache may be a locally cached data stored in a memory for faster access by components of the processing elements that make up processor1005. In one or more embodiments, the shared cache may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), or combinations thereof. Examples of processors include but are not limited to a central processing unit (CPU) a microprocessor. Although not illustrated inFIG. 10, the processing elements that make up processor1005may also include one or more of other types of hardware processing components, such as graphics processing units (GPU), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or digital signal processors (DSPs).

FIG. 10illustrates that memory1010may be operatively and communicatively coupled to processor1005. Memory1010may be a non-transitory medium configured to store various types of data. For example, memory1010may include one or more storage devices1020that comprise a non-volatile storage device and/or volatile memory. Volatile memory, such as random-access memory (RAM), can be any suitable non-permanent storage device. The non-volatile storage devices1020can include one or more disk drives, optical drives, solid-state drives (SSDs), tap drives, flash memory, read only memory (ROM), and/or any other type of memory designed to maintain data for a duration of time after a power loss or shut down operation. In certain instances, the non-volatile storage devices1020may be used to store overflow data if allocated RAM is not large enough to hold all working data. The non-volatile storage devices1020may also be used to store programs that are loaded into the RAM when such programs are selected for execution.

Persons of ordinary skill in the art are aware that software programs may be developed, encoded, and compiled in a variety of computing languages for a variety of software platforms and/or operating systems and subsequently loaded and executed by processor1005. In one embodiment, the compiling process of the software program may transform program code written in a programming language to another computer language such that the processor1005is able to execute the programming code. For example, the compiling process of the software program may generate an executable program that provides encoded instructions (e.g., machine code instructions) for processor1005to accomplish specific, non-generic, particular computing functions.

After the compiling process, the encoded instructions may then be loaded as computer executable instructions or process steps to processor1005from storage device1020, from memory1010, and/or embedded within processor1005(e.g., via a cache or on-board ROM). Processor1005may be configured to execute the stored instructions or process steps in order to perform instructions or process steps to transform the computing device into a non-generic, particular, specially programmed machine or apparatus. Stored data, e.g., data stored by a storage device1020, may be accessed by processor1005during the execution of computer executable instructions or process steps to instruct one or more components within the computing device1000.

A user interface (e.g., output devices1015and input devices1030) can include a display, positional input device (such as a mouse, touchpad, touchscreen, or the like), keyboard, or other forms of user input and output devices. The user interface components may be communicatively coupled to processor1005. When the output device is or includes a display, the display can be implemented in various ways, including by a liquid crystal display (LCD) or a cathode-ray tube (CRT) or light emitting diode (LED) display, such as an organic light emitting diode (OLED) display. Persons of ordinary skill in the art are aware that the computing device1000may comprise other components well known in the art, such as sensors, powers sources, and/or analog-to-digital converters, not explicitly shown inFIG. 10.