Patent Publication Number: US-9405531-B2

Title: Methods for building application intelligence into event driven applications through usage learning, and systems supporting such applications

Description:
CROSS-REFERENCE TO PRIORITY APPLICATION 
     This application claims priority to Indian patent application no. 846/KOL/2013, filed on 16 Jul. 2013, the entire contents of which are herein incorporated herein by reference. 
     TECHNICAL FIELD 
     Certain example embodiments described herein relate to techniques for leveraging application intelligence. More particularly, certain example embodiments described herein relate to gathering information about an application, e.g., to generate interaction patterns that may help to identify data relevant to decision-making, reason about a user&#39;s intended actions, generate inference documents that capture the user&#39;s intentions, etc. Certain example embodiments additionally or alternatively apply a “who”, “what”, “when”, “where”, “how”, and/or “why” approach to event auditing. 
     BACKGROUND AND SUMMARY OF EXAMPLE EMBODIMENTS OF THE INVENTION 
     A simple Event Driven Application is one that responds to actions generated by the user or the system. Event Driven Applications can perform a predetermined sequence of actions depending, for example, on a sequence of actions and/or events with which they are presented. Simple examples of Event Driven Applications include vending machines that dispense products when the proper combination of coins is deposited, combination locks that require the input of combination numbers in the proper order, etc. Although these examples are simple, it is known that Event Driven Applications can model a large number of potentially complex problems such as, for example, electronic design automation, communication protocol design, language parsing, engineering applications, and/or the like. 
     It will be appreciated that in a good Service-Oriented Architecture (SOA) Governance solution, the careful development of services/applications may help to determine the value it adds to the business. Unfortunately, however, the development and evolution of the services are determined by a series of lifecycle states and events that are difficult to track and/or monitor, thus making it difficult to provide useful information to application/service developers and/or other interested stakeholders. 
     For example, recording of the evolution of applications and what happens as such applications go through multiple states/events during development and as they are used when actually deployed, can impose potentially significant requirements, e.g., when it comes to gathering data relevant to analyzing and understanding the important design decisions made throughout its evolution, as well as for application maintenance and anomaly resolution during development and deployed use. 
     The inventors have also realized that additional or alternative benefits could be derived from careful recording of the interactions with the aforementioned applications, e.g., based on observed and/or adduced interaction patterns. Interaction patterns can, for example, be studied to build intelligent applications that can automatically or at least semi-automatically determine new application workflows based on previous interactions that it had with the particular user. Examples of such changed flows may include, for example, dynamically changing a GUI according to analysis of human interaction patterns. Building a dynamic system, e.g., where less frequently used parts of an application filtered and user-preferred flows are at least initially shown, may reduce the number of “clicks” performed on a GUI and thus may improve the efficiency of the interactions, while creating a more natural feeling and easier to use application. Unfortunately, however, it oftentimes is difficult to gather this information, as well, and it therefore is difficult to enable solutions of these sorts. 
     Although some current attempts to have been made to use event driven auditing to build “audit logs” or the like, such techniques stop short of actually interpreting those logs to build intelligent systems. And although some tools have been developed for processing audit logs to collect and analyze the events so as to determine further courses of actions (e.g., like raising an alarm in monitoring systems, etc.), such approaches likewise stop short of actually instilling intelligence into applications, e.g., based on the events and logs. 
     Thus, it will be appreciated by those skilled in the art that it would be desirable to overcome these and/or other problems. For example, it will be appreciated that it would be desirable to build application intelligence on Event Driven Applications by effective recording of application evolution and usage. 
     One aspect of certain example embodiments relates to effective recording of application evolution and usage for usage learning and/or event auditing purposes. With respect to usage learning, certain example embodiments may help to capture data on the usage patterns and/or apply learning algorithms that work on the captured data to provide required intelligence to the application. With respect to event auditing, certain example embodiments may help to identify the “who”, “what”, “when”, “where”, “how”, and/or “why” of particular operations, e.g., to respectively identify for a given operation or combination of operations the user who is performing the particular operation on the application; what operation is being performed by the user on the application; the time at which the operation is being performed; the physical location at which the operation is performed; how the operation is performed (e.g., manually, automatically, some combination thereof, etc.); and the reason(s) behind the operation. 
     Another aspect of certain example embodiments relates to using application intelligence to determine application “hotspots” or commonly used features (including those that are most common) that help in areas such as application maintenance, performance tuning, and/or the like. 
     Another aspect of certain example embodiments relates to using application intelligence to equip an application with knowledge about different users&#39; usage patterns, e.g., so that the application can present different workflows tailored for different users for the same application. 
     In certain example embodiments, an application intelligence gathering method for use with an application hosted by a computer system is provided. Artifacts are received from a computer readable storage medium, with the artifacts representing data gathered during execution of the application and relating to events that occur during the execution. Using a computer processor, interaction patterns associated with the events are identified. Inference documents are generated in connection with the identified interaction patterns using the computer processor. The inference documents include, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user&#39;s intentions for that event. Using the computer processor, at least one custom application workflow is generated based on the generated inference documents. The at least one custom application is transformable into a new application workflow that is deployable into the application. 
     In certain example embodiments, there is provided a non-transitory computer readable storage medium tangible storing instructions that, when performed, gather application intelligence on an application hosted by a computer system, by executing instructions to at least: receive artifacts from a computer readable storage medium, the artifacts representing data gathered during execution of the application and relating to events that occur during the execution; identify interaction patterns associated with the events; generate inference documents in connection with the identified interaction patterns, the inference documents including, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user&#39;s intentions for that event; and generate at least one custom application workflow based on the generated inference documents, the at least one custom application workflow being different from default application workflows. The at least one custom application is transformable into a new application workflow that is deployable into the application. 
     In certain example embodiments, a computer system for gathering application intelligence on an application is provided. Processing resources include at least one processor and a memory. A computer readable storage medium tangibly stores data gathered during execution of the application and relating to events that occur during the execution. At least some of the processing resources are configured to at least: identify interaction patterns associated with the events, using the computer readable storage medium; generate inference documents in connection with the identified interaction patterns, the inference documents including, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user&#39;s intentions for that event; and generate at least one custom application workflow based on the generated inference documents, the at least one custom application workflow potentially being different from default application workflows. The at least one custom application is transformable into a new application workflow that is deployable into the application. The data gathered during execution of the application indicates, for each said event, what kind of event was performed, why the event happened, who was responsible for triggering the event, when the event happened, where the event happened, and how the event was triggered, as appropriate for the respective event. 
     These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations and sub-combinations to achieve yet further embodiments of this invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       These and other features and advantages may be better and more completely understood by reference to the following detailed description of exemplary illustrative embodiments in conjunction with the drawings, of which: 
         FIG. 1  provides a high-level overview of an approach for usage learning that may be used in connection with certain example embodiments; 
         FIG. 2  is an ATM system example that is used to illustrate the techniques of certain example embodiments; 
         FIG. 3  helps explain how inference documents may be generated, according to certain example embodiments; 
         FIGS. 4-6  are tables that help explain how inference documents in accordance with certain example embodiments may be generated for the ATM example discussed herein; 
         FIGS. 7-9  show how the example ATM workflows may be transformed to filter out mandatory steps, in accordance with certain example embodiments; 
         FIG. 10-12  are versions of the workflows from  FIGS. 7-9  that have been transformed to reflect action group groupings, in accordance with certain example embodiments; and 
         FIG. 13  is a flowchart illustrating the user&#39;s preferred workflow, generated using the example techniques set forth herein, for the ATM example. 
     
    
    
     DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE INVENTION 
     Certain example embodiments relate to use effective logging as a means for building application intelligence into systems. As explained in greater detail below, interaction patterns may be analyzed and/or inference documents may be generated, e.g., to aid in identifying data that helps in decision-making and to reason about a user&#39;s intended actions, and to build self-evolving systems, respectively. In certain example embodiments, heat maps may be generated to determine “hotspots” (e.g., within a critical path) in the system that can be performance-tuned when applying changes. Heat maps additionally or alternatively can be generated to facilitate the development of custom workflows and primary step identification to determine critical paths for testing changes to a system. 
     Certain example embodiments work on the principle that, in a computer interaction, a next set of actions undertaken by a human user and/or the computer system itself generally will be based at least in part on the interactions that happened in the previous step(s) and data collected from the previous step(s). This relationship implies that the data is key to the decision-making 
     In a related vein, certain example embodiments provide systems and/or methods that have the ability to reason about and/or understand the user&#39;s actions in the current state in relation to the “decision data” collected from one or more previous steps and thus can infer the rationale behind such actions. This ability of certain example embodiments helps to drive the learning that enables applications and/or their systems to evolve on their own. 
     Referring now more particularly to the drawings,  FIG. 1  provides a high-level overview of an approach for usage learning that may be used in connection with certain example embodiments. Because Event Driven Applications perform a predetermined sequence of actions depending on a sequence of actions/events they are presented with, an Event Tracker can be built into such systems in step S 102 . The Event Tracker preferably is configured to effectively record events that happen in the system, e.g., in step S 104 . The recording may include capturing event transition data indicating, for example, what kind of event was performed, why it happened, who was responsible for triggering the event, when the event happened, where it happened, how the event was triggered, and/or the like. An Event Tracker in certain example embodiments may act as a listener to all the events that happen in the system. For example, a Balance Enquiry action (discussed in greater detail below) is performed on the system by a user, and this triggers an event in the system. At this point, the tracker will receive this event and along with the knowledge on the current state of the system, it will deduce the information on the what (Balance Enquiry), when (event trigger time), who (current user), how (manual and/or automatic transition from earlier state), why (deducible in further steps of parsing), etc., of the event. Also at the initial stages of parsing, events&#39; relationships may be derived based (potentially solely) on the combination of the user actions and the time at which the action is performed, in some example instances. At later stages in parsing, an event relationship may be deduced based on the algorithms discussed later on in this disclosure (e.g., a user intended to perform a Balance Enquiry before a cash withdrawal in the ATM example below). 
     When events are captured, annotations can be added, e.g., to identify general transitions (e.g., common or repeated transitions or workflows), to associate comments with the events and/or event transition data, etc. For example, annotations can be added to identify the user&#39;s common workflows (e.g., preferred workflows) in certain example embodiments. These annotated workflows can also be presented to the user as “favorites.” Example annotations vis-à-vis the ATM example provided below may include, for example, Cash_Withdrawal_2000_With_PrintBalance and Cash_Withdrawal_With_PrintBalance. In addition to the workflows, logical groups (e.g., like 1000_Withdrawl (e.g., an action that involves Selecting Cash Withdrawl-&gt;Select Denomination-&gt;Confirmation) explained in greater detail below) can also be annotated for reuse, which can be directly integrated into custom generated workflows. The artifacts may be stored to a suitable storage location  106  (e.g., a non-transitory computer readable storage medium that is local to the system, accessible over the network, etc.). Any annotations also can be stored to the storage location  106 , and the artifacts may be associated with annotations, when and as appropriate. 
     With the “Recorded Artifacts” in the storage location  106 , the parser  108  will analyze these recordings to identify the interaction patterns between the user and the system in step S 110 , e.g., in cooperation with processing resources such as a processor and a memory. The interaction patterns analysis process my help to form logical groupings of sequences of events. These groupings may be based on parameters such as, for example, why the event was triggered, when it happened, and/or the like. Additional or alternative parameters outside of the “who”, “what”, “when”, “where”, “how”, and/or “why” paradigm may be used, in certain example embodiments. 
     Inference documents may be generated in step S 112 , e.g., to help capture the “intentions” behind the user&#39;s actions in each and every state in an application workflow. Using the interference documents, the parser  108  may generate a draft workflow of the recorded scenario in step S 114 , with these logical groupings being the steps/states in the workflow. This workflow will then be annotated to generalize the transactions. The resulting annotated workflow may be thought or as representing the “User Preferred” application flow. When multiple workflows are generated, they may be ranked and annotated in step S 116 . 
     When a certain threshold is met (e.g., when a given workflow is generated a predetermined number of times for the same or different users, etc.) and optionally when manually approved, a new application workflow may be generated and optionally deployed into the application in step S 118 . The custom workflows can also be used to determine the application hotspots in the system in step S 120  and, as alluded to above, these hotspots and their related heat maps that can help in application maintenance and/or performance tuning 
     EXAMPLE IMPLEMENTATION 
     The following sections help elaborate on the description provided above in connection with  FIG. 1 , using an illustrative ATM system example. That is, the following ATM system example shown in and discussed in connection with  FIG. 2  helps to explain the process of generating customized workflows and autobiographies. Of course, it will be appreciated that the example techniques described herein have applicability to other Event Driven Applications outside of the ATM and banking contexts and, thus, this example implementation is provided for explanatory purposes and without limitation on the scope of what ultimately is claimed. 
     As indicated above,  FIG. 2  is an ATM system example that is used to illustrate the techniques of certain example embodiments, and a brief description of the familiar process will now be provided. In step S 202  of  FIG. 2 , a personal identification number or PIN is entered by a user (e.g., after a credit card, debit card, or the like is inserted into the ATM). An attempt is made to authenticate the PIN and, if the authentication fails as determined in step S 204 , the process returns to step S 202  so that a PIN can be re-entered. Otherwise, the user is presented with a menu screen in S 206 , allowing the user to select options for displaying an account summary, processing a PIN change, displaying an account balance, initiating a withdrawal, and exiting the session. Based on the selection, the appropriate screens are displayed and further actions from the user may be received. In response to one of the account summary being displayed in step S 208 , a PIN change being processed in step S 210 , and/or a balance being displayed in step S 212 , the user is presented with an option to print a receipt or the like. If a determination is made in step S 216  that no receipt should be printed, then the process returns to the main menu. Otherwise, a record of the transaction is printed in step S 218  and then the process returns to the main menu. If the user instead selects an amount to withdraw via step S 214 , the denomination of the cash to be dispensed may be specified or automatically calculated in step S 220 . The user may be presented with an option to confirm the withdrawal and/or denomination request and, if it is determined in step S 222  that the request should be aborted, then the process returns to the main menu. On the other hand, if it is determined in step S 222  that the request should be processed, then an attempt to dispense the cash is made in step S 224 . If there are no problems with the dispensing of the cash (e.g., as determined in step S 226 ), the user has the option to print a record of the transaction (e.g., as described above) and return to the main menu. On the other hand, if a problem is encountered with the dispensing of the cash (e.g., as determined in step S 226 ), the reason for the error (e.g., insufficient funds in the account, insufficient funds or incorrect denominations in the ATM, etc.) is displayed in step S 228 . As above, the user has the option to print a record of the failed transaction (e.g., as described above) and return to the main menu. 
     Having described the initial  FIG. 2  example in detail, further detail concerning how the  FIG. 1  approach may operate in certain example instances will now be provided. 
     Generating Effective Recordings 
     As discussed above, the effective recording attempts to log possible interactions (e.g., each and every possible interaction) between the user and the application. This may involve capturing event transition data that answers questions such as, for example, “What kind of event was performed”, “Why did it happen”, “Who is responsible for triggering the event”, “When did the event happen”, “Where did it happen”, “What data was passed between the user and the system”, “How was the event triggered”, etc. 
     Assume for the purposes of this ATM example that a customer named John goes to the ATM and withdraws money on the 1st, 11th, and 21st of Jan. 2013. Each of these transactions may be slightly different from the earlier ones. Assume further that each transaction is performed in accordance with the illustrative scenarios in Table 1, below: 
     
       
         
           
               
             
               
                 TABLE 1 
               
             
            
               
                   
               
               
                 Illustrative ATM Withdrawal Scenarios 
               
            
           
           
               
               
               
            
               
                 1 January 2013 
                 11 January 2013 
                 21 January 2013 
               
               
                   
               
               
                 In this case, John 
                 In this case, John 
                 In this case, John  
               
               
                 wants to withdraw 
                 wants to withdraw 
                 wants to withdraw 
               
               
                 $2,000. 
                 $2,000. 
                 $2,000. 
               
               
                 He wants to ensure 
                 He wants to ensure 
                 He wants to ensure 
               
               
                 that he has a 
                 that he has a 
                 that he has a 
               
               
                 balance sufficient 
                 balance sufficient 
                 balance sufficient 
               
               
                 to perform the 
                 to perform the 
                 to perform the 
               
               
                 withdrawal. Thus, he 
                 withdrawal. Thus, he 
                 withdrawal. Thus, he 
               
               
                 checks the balance 
                 checks the balance 
                 checks the balance 
               
               
                 first and finds 
                 first and finds  
                 first and finds 
               
               
                 that there is a 
                 that there is a 
                 that there is a 
               
               
                 sufficient balance. 
                 sufficient balance. 
                 sufficient balance. 
               
               
                 He does not print the 
                 He does not print the 
                 He does not print the 
               
               
                 balance, as he only 
                 balance, as he only 
                 balance, as he only 
               
               
                 intended to know it. 
                 intended to know it. 
                 intended to know it. 
               
               
                 Now that he knows 
                 Now that he knows 
                 Now that he knows 
               
               
                 that there is a sufficient 
                 that there is a 
                 that there is a shortage 
               
               
                 balance, John 
                 sufficient balance, 
                 in the balance, he 
               
               
                 decides to 
                 John decides to 
                 decides to withdraw 
               
               
                 withdraw $2,000. 
                 withdraw $2,000. 
                 $1,000 instead of 
               
               
                 The system chooses the 
                 The system chooses 
                 $2,000. 
               
               
                 denomination 
                 the denomination 
                 The system chooses 
               
               
                 automatically and 
                 automatically and 
                 the denomination 
               
               
                 dispenses the cash. 
                 dispenses the cash. 
                 automatically and 
               
               
                 Now, John wants to 
                 John does not intend to 
                 dispenses the cash. 
               
               
                 confirm that the 
                 check the balance, and 
                 Now, John wants to 
               
               
                 remaining balance of 
                 he simply exits the 
                 confirm that the 
               
               
                 $5,500 is intact. 
                 ATM session. 
                 remaining balance of 
               
               
                 John initiates a balance 
                   
                 $500 is intact. 
               
               
                 enquiry and prints a 
                   
                 John initiates a balance 
               
               
                 receipt for future 
                   
                 enquiry and prints a 
               
               
                 reference. 
                   
                 receipt for future 
               
               
                   
                   
                 reference. 
               
               
                   
               
            
           
         
       
     
     Tables 2-4 below respectively show the details recorded for the three transactions. 
     
       
         
           
               
             
               
                 TABLE 2 
               
             
            
               
                   
               
               
                 Example Record Details for 1 January 2013 Illustrative Scenario 
               
            
           
           
               
               
               
               
               
               
            
               
                 Who 
                 What 
                 When 
                 How 
                 Data Log 
                 Method 
               
               
                   
               
               
                 John 
                 LoggedIn 
                 2013-01-01 
                 Manual 
                 START_OF_EVENT 
                 login(string:user, string 
               
               
                   
                   
                 10:30:24 am 
                   
                   
                 pwd) : Boolean 
               
               
                 John 
                 Check 
                 2013-01-01 
                 Manual 
                 BalanceAmount: 5500 
                 displayBalance( ) : long 
               
               
                   
                 Balance 
                 10:30:29 am 
               
               
                 John 
                 Withdraw 
                 2013-01-01 
                 Manual 
                 $2000 
                 withdraw(long:amount) 
               
               
                   
                   
                 10:30:37 am 
               
               
                 John 
                 Choose 
                 2013-01-01 
                 Auto. 
                 100 * 14 + 50 * 12 
                 findDenomination( ) : 
               
               
                   
                 Denomination 
                 10:30:38 am 
                   
                   
                 Map&lt;long, long&gt; 
               
               
                 John 
                 Withdraw 
                 2013-01-01 
                 Auto. 
                   
                 dispenseCash ( ) : long 
               
               
                   
                 cash 
                 10:30:51 am 
               
               
                 John 
                 Check 
                 2013-01-01 
                 Manual 
                 Balance: 3500 
                 displayBalance( ) : long 
               
               
                   
                 Balance 
                 10:30:57 am 
               
               
                 John 
                 Print 
                 2013-01-01 
                 Manual 
                 Print 
                 printBalance( ) : long 
               
               
                   
                   
                 10:30:57 am 
               
               
                 John 
                 Exit 
                 2013-01-01 
                 Manual 
                 END_OF_EVENT 
                 logout( ) 
               
               
                   
                   
                 10:30:58 am 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                 TABLE 3 
               
             
            
               
                   
               
               
                 Example Record Details for 11 January 2013 Illustrative Scenario 
               
            
           
           
               
               
               
               
               
               
            
               
                 Who 
                 What 
                 When 
                 How 
                 Data Log 
                 Method 
               
               
                   
               
               
                 John 
                 LoggedIn 
                 2013-01-11 
                 Manual 
                 START_OF_EVENT 
                 login(string:user, string 
               
               
                   
                   
                 5:30:24 pm 
                   
                   
                 pwd) : Boolean 
               
               
                 John 
                 Check 
                 2013-01-11 
                 Manual 
                 BalanceAmount: 3500 
                 displayBalance( ) : long 
               
               
                   
                 Balance 
                 5:30:29 pm 
               
               
                 John 
                 Withdraw 
                 2013-01-11 
                 Manual 
                 $2000 
                 withdraw(long:amount) 
               
               
                   
                   
                 5:30:37 pm 
               
               
                 John 
                 Choose 
                 2013-01-11 
                 Auto. 
                 100 * 14 + 50 * 12 
                 findDenomination( ) : 
               
               
                   
                 Denomination 
                 5:30:38 pm 
                   
                   
                 Map&lt;long, long&gt; 
               
               
                 John 
                 Withdraw 
                 2013-01-11 
                 Auto. 
                   
                 dispenseCash ( ) : long 
               
               
                   
                 cash 
                 5:30:51 pm 
               
               
                 John 
                 Exit 
                 2013-01-11 
                 Manual 
                 END_OF_EVENT 
                 logout( ) 
               
               
                   
                   
                 5:30:57 pm 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                 TABLE 4 
               
             
            
               
                   
               
               
                 Example Record Details for 21 January 2013 Illustrative Scenario 
               
            
           
           
               
               
               
               
               
               
            
               
                 Who 
                 What 
                 When 
                 How 
                 Data Log 
                 Method 
               
               
                   
               
               
                 John 
                 LoggedIn 
                 2013-01-21 
                 Manual 
                 START_OF_EVENT 
                 login(string:user, string 
               
               
                   
                   
                 12:30:24 pm 
                   
                   
                 pwd) : Boolean 
               
               
                 John 
                 Check 
                 2013-01-21 
                 Manual 
                 BalanceAmount: 1500 
                 displayBalance( ) : long 
               
               
                   
                 Balance 
                 12:30:29 pm 
               
               
                 John 
                 Withdraw 
                 2013-01-21 
                 Manual 
                 $1000 
                 withdraw(long:amount) 
               
               
                   
                   
                 12:30:37 pm 
               
               
                 John 
                 Choose 
                 2013-01-21 
                 Auto. 
                 100 * 8 + 50 * 4 
                 findDenomination( ) : 
               
               
                   
                 Denomination 
                 12:30:38 pm 
                   
                   
                 Map&lt;long, long&gt; 
               
               
                 John 
                 Withdraw 
                 2013-01-21 
                 Auto. 
                   
                 dispenseCash ( ) : void 
               
               
                   
                 cash 
                 12:30:51 pm 
               
               
                 John 
                 Check 
                 2013-01-21 
                 Manual 
                 Balance: $500 
                 displayBalance( ) : void 
               
               
                   
                 Balance 
                 12:30:57 pm 
               
               
                 John 
                 Print 
                 2013-01-21 
                 Manual 
                 Print 
                 printBalance( ) : long 
               
               
                   
                   
                 12:30:57 pm 
               
               
                 John 
                 Exit 
                 2013-01-21 
                 Manual 
                 END_OF_EVENT 
                 logout( ) 
               
               
                   
                   
                 12:30:58 pm 
               
               
                   
               
            
           
         
       
     
     These records will then be picked up by the parser to analyze interaction patterns. 
     Analyzing Interaction Patterns 
     As discussed above, usage learning involves gathering that aids in decision-making Thus, certain example embodiments strive to effectively collect the “critical data” during application/system execution. Execution may in general comprise a set of executable steps, and each executable step may involve an interaction with the user or other system. Thus, it may in some case be useful to understand interaction patterns. 
     In human-computer interactions, or in two-way conversations in general, the type of interactions could be broadly classified as one party providing information to the other, one party seeking information from the other, and one party asking the other party to perform an action. These interactions may be referred to as assertion patterns, information solicitation, and actionable patterns, respectively. 
     Certain example embodiments involve combining these interactions in a particular order. For example, a very simple calculator service that helps performing the addition of two integers could be defined as, for example:
     int add(int a, int b);
 
A user invoking this operation essentially asks the system to perform addition (an actionable pattern) by providing two inputs (an assertion) and requests the result (an information solicitation).
   

     The resultant data may then serve any purpose such as, for example, assisting with or even controlling decision-making, providing input to a next set of actions, etc. Thus, it will be appreciated that it would be desirable to analyze interaction patterns based on the recordings and knowledge about the system, e.g., to obtain decision-making related data and reason about an intended action. 
     Referring once again to the ATM example and the scenarios contemplated above, an analysis of the logs may result in the generation of the following report shown in Table 5, below. 
     
       
         
           
               
             
               
                 TABLE 5 
               
             
            
               
                   
               
               
                 Interaction Pattern Report 
               
            
           
           
               
               
               
            
               
                   
                 Method 
                 Interaction Pattern 
               
               
                   
                   
               
               
                   
                 login(string:user, string pwd) 
                 Assertion 
               
               
                   
                 displayBalance( ) : long 
                 Information Solicitation 
               
               
                   
                 withdraw(long:amount) 
                 Assertion 
               
               
                   
                 findDenomination( ) : Map&lt;long, long&gt; 
                 Information Solicitation 
               
               
                   
                 dispenseCash( ) : void 
                 Actionable 
               
               
                   
                 printBalance ( ) : long 
                 Information Solicitation 
               
               
                   
                 logout( ) 
                 Actionable 
               
               
                   
                   
               
            
           
         
       
     
     This report, along with the recordings, will now be parsed to generate inference documents. 
     Generating Inference Documents 
     Inference Documents help capture the intentions behind users&#39; actions in the states in an application workflow. This is done by reasoning about the users&#39; actions in connection with a decision data set. The inference documents may be generated for every single transaction between the user and the system in certain example embodiments. 
       FIG. 3  helps explain how inference documents may be generated, according to certain example embodiments.  FIG. 3  assumes that the logs discussed above are received and that the interaction patterns have been identified. Thus, in step S 302 , for each transaction, the recording obtained after analyzing the interactions patterns are sorted based on the time when the event occurred. Once the sorting of the recordings is complete, in step S 304 , a variety of data may be generated for the states in a transaction. This data may include, for example, (a) data about the current state(s) with associated event types and/or action types, e.g., as obtained from the recordings in step S 304   a ; (b) a decision data set, e.g., generated by collecting the data presented to the user in a state (which may include, for example, data returned by the actions that confirm to the Information Solicitation Pattern) in step S 304   b ; (c) process input data, e.g., generated by processing the decision data to infer the user&#39;s intentions behind an action in step S 304   c ; and (d) inference documents, e.g., generated using the above-described and/or other data in step S 304   d.    
     The inference document that is generated may include information indicating whether a state/event is mandatory, and the user&#39;s intentions behind an action. With respect to the former, an indication that a state/event is mandatory may mean that the user performed the related action because of the application flow and not because the user actually wanted to do so. Reasoning about whether an event/action type is mandatory or optional may be based on the following and/or other rules:
         If Event Type is Manual and Decision Data exists→Mandatory   If Event Type is Manual and no Decision Data exists→Optional   If Event Type is Automatic and Decision Data exists→Mandatory   If Event Type is Automatic and no Decision Data exists→Mandatory       

     The tables in  FIGS. 4-6  help explain how inference documents in accordance with certain example embodiments may be generated for the ATM example discussed herein.  FIGS. 4-6  are for the 1 Jan. 2013, 11 Jan. 2013, and 21 Jan. 2013 transactions, respectively. It is noted that the right-most column lists the inferences that may be drawn, e.g., whether steps seem to be mandatory or optional, the apparent temporal order of steps, conditions placed on certain inputs, etc. These inference documents may help in generating the custom application workflows as described in greater detail below. Although not considered in the example above, in the case of an ATM network, a physical location parameter might also be considered as a factor recorded in the inference document, providing an additional input for the custom application workflow (e.g., for security reasons, the user only retrieves smaller cash amounts in specific locations). 
     Generating Custom Workflows 
     Custom workflows may be generated for some or all transactions between the user and the system. The custom workflow may help capture the user&#39;s preferred application workflow, rather than the default application flow, and they may be generated based at least in part on the inference documents discussed above. 
     Custom workflow generation may involve filtering out mandatory steps and identifying primary steps.  FIGS. 7-9  show how the example ATM workflows may be transformed to filter out mandatory steps, in accordance with certain example embodiments.  FIGS. 7-9  are for the 1 Jan. 2013, 11 Jan. 2013, and 21 Jan. 2013 transactions, respectively. Each block represents a step and shows the action type, as well as any relevant values from the decision data set and conditional inferences. As should be apparent from the foregoing, optional steps are excluded from these flows, and the apparent temporal order of events is reflected in the overall organization of the various flows. 
     In  FIGS. 7-9 , the blocks with dashed borders are primary steps, or those states in the application workflow where user input is required. It is assumed that the system can automatically perform all the steps that happened prior to the state without user interference, although this is not necessarily required for all embodiments of the invention. Certain example embodiments may identify which steps are primary steps using the following and/or other guidelines:
         Assertions will become primary steps and will remain manual;   Information Solicitation steps will become part of an action group (discussed in greater detail below) and will become an automatic step; and   The application developers can also explicitly flag some of the states as mandatory (e.g., Login and Exit in the ATM example).       

     The primary steps may be used to form an action group, with each action group grouping together a primary step and all of the states prior to that primary step. In the above example, Cash Withdrawal will become the first primary step and, thus, all of the steps executed before that will become a subset of the Cash Withdrawal step. The custom workflows shown in  FIGS. 7-9  thus will be transformed based on action group groupings, thereby resulting in the flows shown in  FIGS. 10-12 . These custom workflows may be ranked for generating a user&#39;s most preferred workflow. 
     Ranking Custom Workflows 
     As indicated above, it is possible in certain example embodiments to rank custom workflows in order to identify a user&#39;s most preferred application workflow. This may be performed in certain example embodiments by calculating the execution frequency of each of the states in the custom workflows. Table 6 below shows the ranking for the example transactions discussed above. A ranking may also be performed for the actions/data for a given state itself. For example, Table 7 below ranks the actions in the Cash Withdrawal state. 
     
       
         
           
               
             
               
                 TABLE 6 
               
             
            
               
                   
               
               
                 Ranking for Example ATM Transactions 
               
            
           
           
               
               
               
            
               
                   
                 States 
                 Execution Frequency 
               
               
                   
                   
               
               
                   
                 Login 
                 3 
               
               
                   
                 Cash Withdrawal 
                 3 
               
               
                   
                 Print Balance 
                 2 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                 TABLE 7 
               
             
            
               
                   
               
               
                 Ranking for Example Cash Withdrawal State 
               
            
           
           
               
               
               
               
            
               
                   
                 Event 
                 Value 
                 Execution Frequency 
               
               
                   
                   
               
               
                   
                 Select Amount 
                 2000 
                 2 
               
               
                   
                 Select Amount 
                 1000 
                 1 
               
               
                   
                   
               
            
           
         
       
     
     Based on these rankings, a user&#39;s preferred application workflow may be generated.  FIG. 13  is a flowchart illustrating the user&#39;s preferred workflow, generated using the example techniques set forth herein, for the ATM example. As will be appreciated, the  FIG. 13  flowchart is the same as that shown in  FIGS. 10 and 12 , except that the added intelligence that the favorite withdrawal amount seems to be $2000 is reflected in the user&#39;s preferred workflow of  FIG. 13 . 
     As alluded to above, a physical location parameter could analogously aid in presenting a most preferred workflow, depending on geographical location. Other parameters may similarly be used. 
     Annotating the workflows may be performed to help identify users&#39; common workflows Annotated workflows in certain example embodiments can also be presented to the user as favorites and may be accessible wherever the application is used in some instances. For instance, for the ATM example discussed above, annotated workflows may be stored such that these favorites are available to the user from any ATM (and not just the ATM of the bank they bank with), e.g., by being stored on the ATM card or being accessible from a central store when an authenticated session is started. 
     Different possible annotations for the above transactions may include, for example:
         Cash Withdrawal 2000 With Print Balance [User Preferred workflow]   Cash Withdrawal 1000 With Print Balance   Cash Withdrawal With Print Balance       

     A sample execution flow for the Cash Withdrawal 2000 With Print Balance annotation is as follows:
     1) Login
       a. [System]: Prompts Authentication   b. [User]: Enters PIN   
       2) Cash Withdrawal
       a. [System]: Your Available Balance is $5500   b. [System]: Withdraw $2000. Confirm?   c. [User]: Confirms   
       3) Print Balance
       a. [System]: Your Available Balance is $3500   b. [System]: Prints the Balance   
       4) Exit   

     A sample execution flow for the Cash Withdrawal With Print Balance annotation is as follows:
     1) Login
       a. [System]: Prompts Authentication   b. [User]: Enters PIN   
       2) Cash Withdrawal
       a. [System]: Your Available Balance is $5500   b. [System]: Select Amount for Withdrawal   c. [User]: Enters $1000   d. [System]: Confirm?   e. [User]: Confirms   
       3) Print Balance
       a. [System]: Your Available Balance is $4500   b. [System]: Prints the Balance   
       4) Exit   

     In addition to generating the user&#39;s most preferred workflow, the custom workflow generation and/or primary step identification techniques can be performed over time anonymously and/or in a non-user specific manner to help build a “heat map.” The heat map may help to identify details regarding the steps most often used (e.g., revealing user-based critical paths) in the production system. Reports can be generated based on these details and, when provided to the application developers, the reports can help in maintaining applications over multiple versions and also in resolving anomalies. More particularly, heat maps may help to identify narrower hotspots, e.g., to aid in performance-tuning hotspots within a critical path, ensuring performance of the critical paths is at least as good as previous versions (even after changes are made to the system), prioritizing the tests to take advantage of the critical paths collected to help guard against “fixes” causing regressions, etc. 
     In the ATM example, based on the primary steps identified and the execution frequencies provided above, it may be determined that the steps such as Cash Withdrawal and Print Balance are “hotspots” in the application. These hotspots will be collected, and reported to the application developers. 
     It will be appreciated that the various documents, workflows, etc., may be stored to a non-transitory computer readable storage medium in certain example embodiments, e.g., to facilitate processing, provide authorized persons (e.g., developers) a chance to review such items prior to proceeding with the next steps (such as, for example, new workflow deployment), etc. 
     Although certain example embodiments have been described as relating to applying inference techniques to application events, it is noted that the example techniques described herein may be used to take into account system and/or external events in addition to, or in place of, application events. As alluded to above, it may be advantageous to take into account geospatial events (e.g., location information identifying where an interaction is originating from and/or interacting to). Similarly, the collection of device and network level events alone and/or combined with human-to-application interaction sets may be taken into account in certain example embodiments. 
     As a further example, more user behavior may be taken into account by examining locations where the application is used, the time of day used, the frequency the same user interacts with the system and/or application, the device or device type the user uses to interact with the system, a browser or browser type, etc. For instance, in the ATM interaction scenarios described above, it may be desirable to infer patterns based on the locations of ATM machines used, the time of day used, the frequency the same user interacts with a banking system from a mobile device and/or a web browser, etc. It thus will be appreciated that determining a user&#39;s preferred workflow may extend beyond a specific application&#39;s context. 
     The example techniques set forth herein may be use to build a system that can generate an “autobiography” based on the recordings. That is, certain example embodiments can help generate an application autobiography that is, in essence, a form of enhanced and well-formatted logging. These autobiographies can be customized in terms of what content is gathered and how it is processed and subsequently presented based on, for example, the target audience. This also may help to in a way redefine the way logging is performed, e.g., by providing techniques that in certain example instances enable the capturing of a complete or “360 degree” perspective of logging wherein all the aspects (e.g., what, why, how, when, who, etc.) of the log are captured and meaningful content is derived, as opposed to traditional logging where the logs are basically stale content generated out of events. Similarly, in certain example embodiments, the conventional approach of looking at a log as being static content with a predefined formatted structure can be changed, and a more human readable system generated autobiography of the logs can be presented in a template of user&#39;s choice. 
     Although certain example embodiments have been described in connection with Event Driven Applications and, thus, Event Driven Architectures or EDA, it will be appreciated that the example techniques set forth herein are not limited to such applications and/or architectures. For instance, the example techniques associated with the building of inference documents for generating “self-evolving” systems has broader implications and can be used in different types of applications and/or computer architectures. More particularly, although the example embodiments described above discuss instilling self-learning capabilities to Event Driven Application, it will be appreciated that the example techniques described herein may be generalized and applied to any kind of applications and/or systems that could benefit from logging as a means to building application intelligence into such systems and/or inferring intended user&#39;s actions by identifying data (that helps in decision-making and/or other tasks) and by generating inference documents for building self-evolving systems. 
     It will be appreciated that as used herein, the terms system, subsystem, service, engine, module, programmed logic circuitry, and the like may be implemented as any suitable combination of software, hardware, firmware, and/or the like. It also will be appreciated that the storage locations herein may be any suitable combination of disk drive devices, memory locations, solid state drives, CD-ROMs, DVDs, tape backups, storage area network (SAN) systems, and/or any other appropriate tangible non-transitory computer readable storage medium. Cloud and/or distributed storage (e.g., using file sharing means), for instance, also may be used in certain example embodiments. It also will be appreciated that the techniques described herein may be accomplished by having at least one processor execute instructions that may be tangibly stored on a non-transitory computer readable storage medium. 
     While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.