TITLE OF THE INVENTION
METHODS FOR BUILDING APPLICATION INTELLIGENCE INTO EVENT DRIVEN
APPLICATIONS THROUGH USAGE LEARNING, AND SYSTEMS SUPPORTING
SUCH APPLICATIONS
TECHNICAL FIELD
[0001] 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's intended actions, generate inference documents that capture the user'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
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] Another aspect of certain example embodiments relates to using application
intelligence to equip an application with knowledge about different users' usage patterns,
e.g., so that the application can present different workflows tailored for different users for the
same application.
[0011] 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'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.
[0012] 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'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.
[0013] 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'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.
[0014] 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
[0015] 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:
[0016] Figure 1 provides a high-level overview of an approach for usage learning that
may be used in connection with certain example embodiments;

[0017] Figure 2 is an ATM system example that is used to illustrate the techniques of
certain example embodiments;
[0018] Figure 3 helps explain how inference documents may be generated, according
to certain example embodiments;
[0019] Figures 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;
[0020] Figures 7-9 show how the example ATM workflows may be transformed to
filter out mandatory steps, in accordance with certain example embodiments;
[0021] Figure 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
[0022] Figure 13 is a flowchart illustrating the user's preferred workflow, generated
using the example techniques set forth herein, for the ATM example.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE INVENTION
[0023] 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'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.
[0024] 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.
[0025] In a related vein, certain example embodiments provide systems and/or
methods that have the ability to reason about and/or understand the user'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.
[0026J 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 S102. The Event Tracker preferably is
configured to effectively record events that happen in the system, e.g., in step S104. The
recording may include captaring 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' 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).
[0027] 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'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-a-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 -> Select Denomination -> 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.
[0028] 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 S110, 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.
[0029] Inference documents may be generated in step S112, e.g., to help capture the
"intentions" behind the user'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 S114, 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 S116.
[0030] 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 S118. The custom workflows can also be used to determine the
application hotspots in the system in step S120 and, as alluded to above, these hotspots and
their related heat maps that can help in application maintenance and/or performance tuning.
Example Implementation
[0031] 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.
[0032] 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 S202 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 S204, the process returns to step S202 so that a PIN can be re-entered. Otherwise, the
user is presented with a menu screen in S206, 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 S208, a PIN change being processed in step
S210, and/or a balance being displayed in step S212, the user is presented with an option to
print a receipt or the like. If a determination is made in step S216 that no receipt should be
printed, then the process returns to the main menu. Otherwise, a record of the transaction is
printed in step S218 and then the process returns to the main menu. If the user instead selects
an amount to withdraw via step S214, the denomination of the cash to be dispensed may be
specified or automatically calculated in step S220. The user may be presented with an option
to confirm the withdrawal and/or denomination request and, if it is determined in step S222
that the request should be aborted, then the process returns to the main menu. On the other
hand, if it is determined in step S222 that the request should be processed, then an attempt to
dispense the cash is made in step S224. If there are no problems with the dispensing of the
cash (e.g., as determined in step S226), 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 S226), 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 S228. 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.

[0033] 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
[0034] 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.
[0035] 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 January, 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:

[0037] These records will then be picked up by the parser to analyze interaction
patterns.
Analyzing Interaction Patterns
[0038] 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.
[0039] 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.
[0040] 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).
[0041] 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.
[0042] 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.

[0043] This report, along with the recordings, will now be parsed to generate
inference documents.
Generating Inference Documents
[0044] Inference Documents help capture the intentions behind users' actions in the
states in an application workflow. This is done by reasoning about the users' 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.
[0045] 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 S302, 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 S304, 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 S304a; (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 S304b; (c)
process input data, e.g., generated by processing the decision data to infer the user's
intentions behind an action in step S304c; and (d) inference documents, e.g., generated using
the above-described and/or other data in step S304d.
[0046] The inference document that is generated may include information indicating
whether a state/event is mandatory, and the user'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
[0047] 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 January 2013, 11 January 2013, and 21 January 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
[0048] Custom workflows may be generated for some or all transactions between the
user and the system. The custom workflow may help capture the user'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.
[0049] 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 January 2013, 11 January 2013, and 21 January 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.
[0050] 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).
[0051] 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's most preferred workflow.
Ranking Custom Workflows
[0052] As indicated above, it is possible in certain example embodiments to rank
custom workflows in order to identify a user'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.


[0053] Based on these rankings, a user's preferred application workflow may be
generated. Fig. 13 is a flowchart illustrating the user'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's
preferred workflow of Fig. 13.
[0054] 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.
[0055] Annotating the workflows may be performed to help identify users' 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.
[0056] 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

[0057] 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
[0058] 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
[0059] In addition to generating the user'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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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's preferred workflow may extend beyond a specific
application's context.
[0064] 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's choice.
[0065] 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's actions by identifying data (that helps in decision-
making and/or other tasks) and by generating inference documents for building self-evolving
systems.
[0066] 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.
[0067] 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.

WHAT IS CLAIMED IS:
1. An application intelligence gathering method for use with an application
hosted by a computer system, the method comprising:
receiving 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;
identifying, using a computer processor, interaction patterns associated with the
events;
generating inference documents in connection with the identified interaction patterns
using the computer processor, 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's intentions for that event; and
generating, using the computer processor, at least one custom application workflow
based on the generated inference documents,
wherein the at least one custom application is transformable into a new application
workflow that is deployable into the application.
2. The method of claim 1, wherein the data gathered during execution of the
application is event transition data captured from the application and/or the computer system
for each of the events that involves a human-computer interaction.
3. The method of claim 2, wherein the event transition data captured is
annotated.
4. The method of claim 2, wherein 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/or how the event was triggered.
5. The method of claim 4, wherein the data gathered during execution of the
application specifies whether each captured event was performed based on human input.

6. The method of claim 4, wherein the data gathered during execution of the
application specifies one or more application methods associated with each said event.
7. The method of claim 1, wherein the identifying of the interaction patterns
associated with the received events includes associating each event with an interaction pattern
type selected from the group consisting of assertion, information solicitation, and actionable
patterns.
8. The method of claim 1, further comprising generating a decision data set for
each said event, the decision data set including data presented to and retrieved from the user
in connection with the respective event.
9. The method of claim 8, further comprising:
determining that an event is mandatory when the event is manual and decision data
exists, when the event is automatic and decision data exists, and when the event is automatic
and no decision data exists; and
determining that the event is mandatory when the event is manual and no decision
data exists.
10. The method of claim 1, wherein the at least one custom application workflow
is generated by at least filtering for any mandatory steps and identifying any primary steps,
the primary steps being those steps where user input is required and those steps where the
system can perform all prior steps without user interference.
11. The method of claim 1, further comprising:
identifying assertion-type interaction pattern steps as primary steps with manual
action types;
forming one or more action groups, each said action group grouping together one
primary step and all steps prior to that primary step that are not themselves primary steps;
assigning each information solicitation assertion-type interaction pattern step to one
said action group as an automatic action type step; and
generating the at least one custom application workflow in connection with the one or
more action groups.

12. The method of claim 11, further comprising receiving input from an
authorized party specifying that a particular event is a mandatory event.
13. The method of claim 1, wherein a plurality of custom application workflows is
generated, and further comprising ranking the custom application workflows.
14. The method of claim 13, wherein the ranking of the custom application
workflows comprises calculating frequencies for each state and/or at least some data values,
in connection with each said custom application workflow.
15. The method of claim 14, further comprising generating a user-preferred
workflow based on the ranking, the user-preferred workflow including a new arrangement of
process steps and/or default data parameters based on prior usage.
16. The method of claim 15, wherein the user-preferred workflow is based on
input from a plurality of different users.
17. The method of claim 1, wherein the data gathered during execution of the
application is event transition data captured from the application and the computer system,
and includes event related data for events from within and external to the application.
18. The method of claim 1, further comprising identifying user-based critical
paths in connection with an assessment of which steps are most often used.
19. 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'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,
wherein the at least one custom application is transformable into a new application
workflow that is deployable into the application.
20. A computer system for gathering application intelligence on an application,
comprising:
processing resources including at least one processor and a memory; and
a computer readable storage medium tangibly storing data gathered during execution
of the application and relating to events that occur during the execution;
wherein 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's intentions for that event; and
generate at least one custom application workflow based on the generated
inference documents;
wherein the at least one custom application is transformable into a new application
workflow that is deployable into the application; and
wherein 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.
21. The system of claim 20, wherein the identifying of the interaction patterns
associated with the events includes associating each event with an interaction pattern type

selected from the group consisting of assertion, information solicitation, and actionable
patterns.
22. The system of claim 20, wherein at least some of the processing resources are
configured to at least generate a decision data set for each said event, the decision data set
including data presented to and retrieved from the user in connection with the respective
event
23. The system of claim 22, wherein at least some of the processing resources are
further configured to at least:
determine that an event is mandatory when the event has a manual action type and
decision data exists, when the event has an automatic action type and decision data exists,
and when the event has an automatic action type and no decision data exists; and
determining that the event is mandatory when the event has a manual action type and
no decision data exists.
24. The system of claim 20, wherein the at least one custom application workflow
is generated in connection with at least some of the processing resources filtering for any
mandatory steps and identifying any primary steps, the primary steps being those steps where
user input is required and those steps where the system can perform all prior steps without
user interference.
25. The system of claim 24, wherein at least some of the processing resources are
further configured to at least:
identify assertion-type interaction pattern steps as primary steps with manual action
types;
form one or more action groups, each said action group grouping together one
primary step and all steps prior to that primary step that are not themselves primary steps;
assign each information solicitation assertion-type interaction pattern step to one said
action group as an automatic action type step; and
generate the at least one custom application workflow in connection with the one or
more action groups.

ABSTRACT

Certain example embodiments relate to application intelligence gathering systems
and/or methods, e.g., in connection with Event Driven Applications and/or the like. More
particularly, certain example embodiments relate to the effective recording of application
evolution and usage information 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. Application intelligence optionally may be used in
determining application "hotspots" or commonly used features that could help in areas such
as application maintenance, performance tuning, and/or the like.