Patent Publication Number: US-8972567-B2

Title: Selectively triggering execution of services in a computing environment

Description:
BACKGROUND 
     In computing, Electronic Performance Support Systems (EPSS) attempt to provide assistance to users of a computer system based on the way the user performs tasks in a software application. For instance, a user may drag an image off of a printable area of a viewable page, and, in response, the EPSS may cause a message to appear alerting the user that the picture will not be printed when printing the viewable page unless the image appears within the margin of the page. In more sophisticated implementations of an EPSS, the message may offer to move the picture back into the printable area of the page. 
     Traditional performance support systems have been indistinguishable from the applications in which they provide assistance. That is, the program code that causes provision of user assistance (i.e., a help message or a prompt to do something in the application) was incorporated into the program code of the application, and for use with only that particular application. In other words, the support system was compiled and/or coded into the application to which it applied. 
     What is needed is a more robust and dynamic support system applicable across a range of software application products without a requirement that the support system be hard-coded into each of the software application products. 
     BRIEF SUMMARY 
     The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method for selectively triggering execution of services in a computing environment. The method includes, for instance, providing an advisor program, the advisor program to execute on a processor and to perform a method comprising: responsive to an event associated with an application of the computing environment, identifying at least one application attribute associated with the application, the at least one application attribute being specified as at least one element of a logical expression of a rule, the rule being defined separate from the application using at least one identifier, the at least one identifier employed, at least in part, by the application in identifying application attributes thereof and the at least one identifier for specifying the at least one application attribute in the logical expression, responsive to identifying the at least one application attribute, obtaining data about the at least one application attribute, evaluating the logical expression based on the obtained data to determine whether the logical expression is true, and responsive to determining that the logical expression is true, triggering execution of one or more services specified in the rule. 
     Additionally, a computer system for selectively triggering execution of services in a computing environment is provided. The computer system includes a memory and a processor in communication with the memory, wherein the computer system is configured to perform a method comprising: providing an advisor program, the advisor program performing a method comprising: responsive to an event associated with an application of the computing environment, identifying at least one application attribute associated with the application, the at least one application attribute being specified as at least one element of a logical expression of a rule, the rule being defined separate from the application using at least one identifier, the at least one identifier employed, at least in part, by the application in identifying application attributes thereof and the at least one identifier for specifying the at least one application attribute in the logical expression, responsive to identifying the at least one application attribute, obtaining data about the at least one application attribute, evaluating the logical expression based on the obtained data to determine whether the logical expression is true, and responsive to determining that the logical expression is true, triggering execution of one or more services specified in the rule. 
     Further, a computer program product for triggering of execution of services in a computing environment is provided. The computer program product includes at least one tangible storage medium readable by a processor and storing instructions for execution by the processor to perform a method comprising: providing an advisor program, the advisor program performing a method comprising: responsive to an event associated with an application of the computing environment, identifying at least one application attribute associated with the application, the at least one application attribute being specified as at least one element of a logical expression of a rule, the rule being defined separate from the application using at least one identifier, the at least one identifier employed, at least in part, by the application in identifying application attributes thereof and the at least one identifier for specifying the at least one application attribute in the logical expression, responsive to identifying the at least one application attribute, obtaining data about the at least one application attribute, evaluating the logical expression based on the obtained data to determine whether the logical expression is true, and responsive to determining that the logical expression is true, triggering execution of one or more services specified in the rule. 
     Additional features and advantages are realized through the concepts of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       One or more aspects of the present invention are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which: 
         FIG. 1  depicts a block diagram of a computing environment to incorporate and use one or more aspects of the present invention; 
         FIG. 2  depicts further details of a customer workstation and hosting product company activities in association with an advisor program, in accordance with one or more aspect of the present invention; 
         FIG. 3  depicts one example of a process for rule-based triggering of services by an advisor program, in accordance with one or more aspects of the present invention; 
         FIG. 4  depicts advisor program activities in association with a specific example of rule-based triggering of services, in accordance with one or more aspects of the present invention; 
         FIG. 5  depicts a tree diagram graphically illustrating example rule criteria of a rule, in accordance with one or more aspects of the present invention; 
         FIG. 6  depicts an example of an XML-based rule format using descriptive data elements, in accordance with one or more aspects of the present invention; and 
         FIG. 7  depicts one embodiment of a computer program product to incorporate one or more aspects of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     An advisor program and related features are described herein. The advisor program is provided for selectively triggering execution of services in a computing environment. The advisor program can determine, responsive to an event associated with an application of the computing environment, attribute(s) associated with the application about which data, for instance data about user behavior with respect to the application attribute(s), is to be obtained. The application attribute(s) are specified elements of a logical expression of a rule, which is defined separate from the application. The rule definition use identifiers which are, in part, employed by the application in identifying the attributes of the application. After determining the application attribute(s) and obtained data about them, the advisor program evaluates the logical expression based on the obtained data to determine whether the logical expression is true, and, if so, execution of one or more services specified in the rule is triggered. 
     In one particular example, the advisor program monitors user behavior with respect to the application attribute(s) and builds a user behavior state based at least partially on the monitored user behavior. The logical expression of the rule is then evaluated based on the built user behavior state to determine whether the logical expression is true, and execution of one or more services specified in the rule is triggered if the logical expression is evaluated to be true. Services triggered in connection with this particular example can provide coaching to users of the application based on the way the users use and interact with the application. 
     More specifically, the advisor program ‘listens’ to system activity from an application (an application “hosting” the advisor program) in the computing environment to determine whether and when to trigger one or more rules. A rule contains a specification of any combination of user behavior/actions, system variables of a computer system on which the application is installed, or application properties, such as application configuration information or user data stored by the application. This specification is in the form of triggering criteria for causing the triggering of services, such as an advice message to be displayed to the user. In one example, advice messages are displayed in a configurable, bubble-like message box near a place or portion of the application user interface where the user is working, to ensure that the user associates the advice message with the activity that the user was engaging in at the time of, or just prior to, providing the advice message to the user. 
     A rule engine (also referred to herein as an advisor processing engine) is a component of the advisor program. The rule engine accepts rule data, that is, the defined rules that describe the triggering criteria and indicate the services to be triggered in the computing environment if that criteria is satisfied, and, in one example, obtains data about observed user behavior and/or other system variables, application configuration information, or application user data. Triggering of the services indicated in a rule can be based solely or partially on usage and control of the application by the user. The rule engine is generic in the sense that, in one example, it is not tied to any particular software application, but instead can be shipped alongside and provide heuristics-based user advice to any computer application into which the rule engine hooks, as described below. The advisor program is therefore a reusable, generic component that can be used across or instantiated by multiple different software products. Because it listens to activity at the system level, rather than being hard-coded into a particular software application, any existing application can utilize the advisor program disclosed herein. 
     The advisor program advantageously enables invocation of desired services. These include any service desired to run on a computer system responsive to occurrence of a specific set of triggering criteria. Example services include provision of targeted messages to users, based on, for instance, use and/or configuration of the hosting application, and triggered via one or more rules of a dynamic set of rules that can be pushed-out to a user&#39;s workstation on-demand. Rules can be data archives that, in one example, do not have compiled aspects to their deployment. Alternatively, the rules can have compiled aspects to their deployment, which compiled aspects are separate form compiled program code of the software application. The rules can be files specified using descriptive data elements separate from the hosting application, rather than, for instance, program code incorporated into the hosting application. The rules can, in one example, be developed and pushed to the advisor program over a communications link without requiring additional installation by the users. This facilitates continuous and on-demand addition and modification of deployed rules, which enables the application developer to rapidly address unforeseen customer support issues. 
     The advisor program can trigger services responsive to occurrence of any desired set of triggering criteria. In one particular embodiment, the services are triggered to provide coaching to users of an application in order to assist the users in learning about and utilizing features and services of the application, based on how the user presently uses the product. Additionally, it can help new users become acquainted with the application by providing them with guidance on how to begin using the product and core features thereof. Further, it can assist users in establishing a customer support session, and facilitate collection and feedback of detailed data about how users interact with the application and respond to services triggered by other rules, to enable the application developer make future improvements to the computer product. Additional features and advantages of the advisor program are enabled as will be apparent from the detailed description to follow. 
       FIG. 1  depicts a block diagram of one example of a computing environment to incorporate and use one or more aspects of the present invention. A set of components referred to herein as a computing environment  100  comprises a client workstation  110  which is a user (e.g. customer) computer system. Workstation  110  includes a processor (in this example a central processing unit (CPU))  102  for performing computations. CPU  102  is coupled to a bus bridge  106  by way of a CPU bus  104 . Bus bridge  106  includes a memory controller (not shown) integrated therein, though the memory controller may be external to bus bridge  106 . The memory controller provides an interface for access by CPU  102  or other devices to system memory  108 . System memory  108  can include any of a variety of types of memory device or memory circuitry for storing data. Bus bridge  106  is coupled to graphics circuitry  109  for controlling display device  112 . Graphics circuitry  109  includes, in one example, a video controller, video memory for storing display data to be displayed on display device  112 , and a video BIOS that includes code and video services for controlling the video controller, as is well known in the art. In another embodiment, graphics circuitry  109  is coupled to CPU  102  through an Advanced Graphics Port (AGP) bus. 
     Display device  112  includes a display screen that may be a CRT or LCD monitor, a television which is connected to a set top box, a laptop display, or the like. Navigation through a graphical user interface provided by an operating system may be provided through the use of control buttons on a remote control unit, or by other means known in the art. 
     Bus bridge  106  is also coupled to a system bus  114  that may be a peripheral component interconnect (PCI) bus, Industry Standard Architecture (ISA) bus, etc., and combinations thereof, as examples. Coupled to system bus  114  are communication device  116 , mouse  118 , keyboard  120 , non-volatile memory  122 , and mass storage  124 . One or more other input/output (I/O) devices (not shown) may also be coupled to system bus  114 . 
     Mass storage device  124  can be any of numerous different types of such devices including a hard disk, floppy disk, CD-ROM, DVD-ROM, tape, high density floppy, high capacity removable media, low capacity removable media, solid state memory device, etc., and combinations thereof. Non-volatile memory  122  may be a read-only memory (ROM), flash memory, etc., and can include a system BIOS for controlling, among other things, hardware devices in workstation  110 . 
     Communication device  116  includes a network card, a modem interface, etc. for accessing a network cloud  140  via a communications link  130 . Communications link  130  links workstation  110  to a network cloud  140 , and further to a communications link  150  linking a service center  160  to network cloud  140 . In one embodiment, network cloud  140  includes the Internet, and computing environment  100  includes many other user computer systems as well as many other service centers (not pictured). Alternatively or additionally, network cloud  140  may include a local area network (LAN), wide area network (WAN), Intranet, etc., and/or combinations thereof. 
     As is familiar to those having ordinary skill in the art, workstation  110  further includes an operating system  126 , which is loaded into system memory  108  from mass storage device  124 , for instance, and launched after a power-on self-test (POST). Operating system  126  includes a set of one or more programs that control computer system  110 &#39;s operation and the allocation of resources thereof, among other things. Example operating systems include, but are not limited or restricted to, DOS, Unix, Linux, the Windows® line of operating systems offered by Microsoft Corporation, Redmond, Wash., and the “OS” line of operating systems (such as OS X®) offered by Apple Inc., Cupertino, Calif., etc. Also loaded into memory  108  of the computer system  110  is an advisor program  128  hosted by a hosting application  129 . Advisor program  128  comprises, in one embodiment, program code. Advisor program  128 , in accordance with one or more aspects of the present invention, utilizes one or more rules (for instance rules stored in system memory  108  and/or mass storage  124 , or stored remotely, such as with an application developer, and accessible to the workstation) for rule-based triggering of execution of one or more services, as is explained in further detail below with reference to  FIGS. 2-6 . 
     Service center  160  includes one or more update servers  162   a - 162   n  that are coupled to each other via a LAN or other arrangement. Update servers  162   a - 162   n  each include a processor, memory, communication circuitry, and software running thereon. Specifically, update server  162   a  includes an operating system  164 , one or more programs  166   a - 166   n , and one or more rules database(s)  168 . 
     Application program  166   a  is, in one example, responsible for execution to communicate with workstation  110 , and more specifically, to assist workstation  110  in providing rule-based triggering of execution of services. In one example, application program  166   a  executes on update server  162   a  and provides rule(s) and/or rule updates from rules database  168  to workstation  110 . Workstation  110 , and more specifically advisor program  128  thereof, uses the rules provided by update server  162   a  to facilitate rule-based service triggering, in accordance with aspects of the present invention. Service center  160  and/or one or more update servers  162  thereof are operated in one example by a developer of one or more software products (not pictured) executing on workstation  110 . The developer may install/maintain/update the one or more software products that host advisor program  128  and/or install/maintain/update aspects of advisor program  128  on workstation  110 , such as rules utilized by advisor program  128  in providing rule-based triggering of execution of one or more services. 
     Although advisor program  128  is depicted on workstation  110 , those having ordinary skill in the art will recognize that the advisor program and/or facilities thereof as described herein could instead reside on a remote system, such as on a server of service center  160 , in one example, and provide advisor program facilities described herein across a web-based interface, such as communications links  130  and  150 . Similarly, aspects of update server  162   a , such as rules database  168  thereof, need not reside on a remote system such as the update server  162 , but could instead be implemented on workstation  110 , for instance in mass storage  124  thereof. Computer environment  100  is therefore just one example of a computing environment to incorporate and use one or more aspects of the present invention. 
       FIG. 2  depicts further details of a customer workstation and hosting product company activities in association with an advisor program and in accordance with one or more aspects of the present invention. In  FIG. 2 , a user  202  interacts with a product (computer application)  204  of workstation  210 , which application is ‘hosting’ an advisor program. The advisor program is depicted within workstation  210  in  FIG. 2 , but those having ordinary skill in the art will recognize that the advisor program could instead reside remotely from the workstation, such as on a remote server maintained by the application developer or a third party. ‘Hosting’ in this context refers to the fact that advisor program code has been loaded by a hosting application (e.g.  129  of  FIG. 1 ) and is executing within the executable(s) of the hosting application. The advisor program is, in this example, not a stand-alone application that monitors the hosting application, but instead runs as part of the hosting application. The hosting application (for instance an “.exe” file) executes and loads one or more advisor program files, such as a set of libraries (All files in one example), and the advisor program files can be loaded by multiple applications. Alternatively, there can be a separate copy of advisor program files for each application which is to host the advisor program, in which case each hosting program would have its own running ‘instance’ of the advisor program. In another example, advisor program comprises executable code and executes alongside the hosting application, either on the workstation  210  or remotely, but remains separate from the compiled code of the application. In yet a further example, advisor program is actually part of the compiled aspects of the application, rather than being a separate executing application, or being instantiated by the hosting application. 
     Data can be obtained about various attributes of hosting application  204 . For instance, user interaction and other behavior with respect to the attributes of hosting application  204  causes data and information about various user interface (UI) activity and other events  206  to be provided to advisor system  212  (e.g. advisor program  128  of  FIG. 1 ), and more specifically to a heuristic relevance engine  214  (also referred to herein as a rule engine or processing engine) of advisor system  212 . Heuristic relevance engine  214  monitors UI activity and custom events  206  of application  204 , and can store this information as product usage data  216  in a database or other storage. Additionally, heuristic relevance engine  214  evaluates a set of rules  218 , for instance rules deployed to the workstation by the hosting product&#39;s company/developer, based on the received UI and event activity  206 , as well as other application properties such as configuration information and user data, to determine whether rule criteria of one or more rules of the set of rules  218  is met or true. As noted above, each rule includes one or more criteria which, when satisfied, cause the rule to be triggered and, more specifically, causes one or more services indicated by one or more service requests to be invoked (for instance, executed), should the one or more criteria be satisfied. Thus, when a rule is triggered, an arbitrary number of services can be executed in the computing environment. The services specified by the rule can include services  220  associated with application  204  which are to be executed. In one example, services  220  associated with the application include one or more services for changing or updating a product database and configuration component  222 , which is used for specifying configuration information/settings about the hosting application, and for containing application user data (such as databases containing data entered or imported by the user, including customer lists, invoices, inventory databases, etc, or accounting transaction information in the case where hosting application is an accounting product, or any other kind of user-originated data). In another example, a service  220  specified in a rule can indicate that usage advice  224  is to be provided to user  202 . Usage advice  224  can be displayed for a specific desired reason, such as to advertise a related application feature, market new products, respond to error conditions, and/or guide the user through complex tasks within the application. While some services may be indicated as targets for execution should rule criteria be satisfied, other service(s) of the rule can be used as part of the evaluation of the rule to determine whether to trigger the target services. Rule criteria for triggering the target service(s) specified in the rule can encompass results of running one or more services that are specified in the rule, or one or more remote services that are referenced in the rule criteria. This enables, for instance, product database and configuration information  222  to be obtained via execution of one or more services specified in the rule itself (or services specified outside of the rule, but referenced by in the rule criteria rule), and can facilitate not only determination of whether to trigger a rule, but also determination of whether a rule is relevant and deserving of additional attention, for instance further monitoring of application attributes specified in the rule, as an example. 
     Usage advice  224  can be used to display a message to the user that is in alignment with the impetus for the rule&#39;s creation, for instance to guide a user through a process which has been found to be difficult for other users to perform. Other services to be executed could support rule feedback, enable other rules, perform some analysis of the product database and/or configuration  222 , or execute call(s) to web-based service(s), as examples. These are just examples of services that may be triggered by a rule. Those having ordinary skill in the art will recognize that any desirable function or operation capable of being performed by a computer system in the computing environment could be triggered responsive to triggering of a rule. 
     In one embodiment, it is the application developer of the hosting product (i.e. the hosting product&#39;s company  208 ) that determines the set of rules  218  deployed to and/or employed by client workstation  210 . Rule authorship  226  occurs as part of the product company&#39;s activities  208 . Rules and message-related content thereof (such as usage advice messages  224  displayed to user  202 ), can be updated on-demand via communications link  228   a . In one example, an automatic or user-initiated update causes workstation  210  to download data that includes new and/or updated rules, while, in another example, the product company deploys the rules to workstation  210  without involvement by user  202 . Additionally or alternatively, an automatic or user-initiated process can enable rules already stored on workstation  210 . 
     Further, feedback is provided from workstation  210  across communications link  228   b  to rule feedback and analysis component  230  of the hosting product&#39;s company. Rule feedback and analysis component  230  includes in one example database(s) for storing received feedback from workstation  210 . This feedback may be provided by way of one or more of the services which are indicated in a rule and that are to be executed when the rule is triggered. Alternatively, the feedback may be provided by way of one or more services specified in another rule designed to monitor a user&#39;s behavior after providing the user with advice. An example service invoked upon triggering a rule might report (as part of this feedback) both the triggering of the rule as well as the effectiveness of the rule by examining changes to user behavior in response to, for instance, advice given to the user, and reporting that to product company  208 . Alternatively, the service might enable another rule on the workstation that monitors the change in user behavior and provides feedback as to the effectiveness of the provided user advice. Reporting of triggering and the effectiveness of the rules, as well as product support, marketing, and sales activities  232 , can drive changes  234  to the rules, wherein existing rules are modified or deleted, and/or additional rules are specified, pushed-to, downloaded, and/or enabled by workstation  210 . The impetus for a rule, therefore, can originate based on a variety of needs of either the user, the developer, or both, for instance to advertise a related product feature, market new products, gather user data, or for self-service support, as examples. 
     As depicted in  FIG. 2 , advisor system  212 , including heuristic relevance engine  214  is designed to be independent of the product(s)  204  hosting the advisor system  212 . Unlike previous approaches in which support is provided to different programs via a support system integrated into each of those programs, advisor system  212  is not, for instance, part of the compiled code of any hosting application. Instead, advisor system  212  is reusable in the sense that it can be hosted by a variety of other products/applications, and can be expanded by way of changes, additions and deletions to the set of rules  218 . Rules  218  can be updated on-demand based on feedback from the client machine and analysis of that feedback, as discussed above. In one particular embodiment, the advisor program comprises one or more files shipped along with a product which is to host the advisor program. The files, in one example data link library (.dll) files, run within the context of the program, meaning that the .dll files run as part of the hosting application and not, for instance, as a separate process having its own memory, threads, hardware resources, etc. Alternative, the advisor program could comprise executable program code which executes as a separate process. In either case, the advisor program is not part of the compiled code of the hosting application. 
     An example sequence of events in a rule-based approach for triggering execution of services by an advisor program is described and depicted with reference to  FIG. 3 . The process begins with a user interacting with a hosting application ( 302 ). In one example, the user interaction is simply launching the program to commence execution thereof. In another example, the user interaction is interaction with one or more attributes of the application, such as user interface elements of the application. 
     Thereafter, an advisor program application interface observes that user interaction ( 304 ). Interaction is observed via, for instance, a message passing facility, provided by the operating system and/or another framework installed on the user&#39;s workstation, such as the .NET Framework offered by Microsoft Corporation. In one example, when a user interacts with one or more attributes of an application executing on an operating system, events are created responsive to that interaction and channeled on a dispatch loop maintained by the operating system. Some operating systems, such as the Windows® line of operating systems offered by Microsoft, use a window manager. A common need within window managers is a means to react to user interaction with the mouse, keyboard, or other input device. A dispatch loop provides a common location where these interaction events can be queued, which enables program(s) to process the events. Thus, these events provide, in one example, information about various aspects of a user&#39;s behavior and other interaction with respect to the application, including interaction with user interface elements and other attributes of application. The advisor program application interface can hook to this dispatch loop and thereby receive or observe the events, including properties thereof, such as window and/or control identifiers specified therein indicating the particular attributes of the hosting application that are being interacted with. 
     The advisor program rule engine (advisor processing engine in  FIG. 3 ) identifies the particular elements or attributes that are being interacted with to find rules pertinent to those user interface elements or attributes ( 306 ). For instance, the processing engine identifies whether any of those elements (or sub-elements thereof) are specified in the criteria portion of one or more of the rules that have been applied to the client workstation. As previously discussed, user behavior with respect to an application element or sub-elements thereof is one example of a building block of triggering criteria specified in a rule. Other example building blocks include system properties, application configuration data, and application user data, which are accessible, in one example, via execution of one or more services specified in a rule, as described above. 
     The specification of an application element in a criteria portion of a rule indicates an interest in obtaining data about that element. In one example, obtaining data about an element includes monitoring the element and/or user behavior with respect to that element. Consequently, the processing engine, in response to finding rule(s) pertinent to an application element that was interacted with (such as a rule that is interested in interactions with a sub-element of the element being interacted with), provides one or more notification channels for detecting when further interactions occur ( 308 ). If one or more of the rules are interested in user behavior with respect to an application attribute that is a sub-element of an element that was just interacted with, the advisor program creates a channel such that new user interactions with this attribute are piped directly to the rule engine. In one example, this is facilitated through the provision by the operating system of a way for advisor program application interface to register a return hook (in one example, code provided by the advisor program) with the dispatch loop. Some operating systems provide a manner in which additional program code can participate in an application&#39;s dispatch loop by routing, e.g., user input events (e.g. interaction with a mouse, keyboard, or other input devices) to program code installed dynamically (e.g. at runtime), which is enabled by the application making system calls to routines provided by operating system libraries. A parameter to these routines contains a reference (such as a function pointer or address in memory to set the program counter register), to the program code to be called, thus causing a call of the return hook should a particular event (for instance one which is interesting to one or more of the rules) be processed from the dispatch loop. In this manner, the advisor program application interface begins to monitor relevant area(s) of the application for, e.g., future user interactions therewith ( 310 ). 
     Only if there is a pertinent rule will further information and/or statistics be gathered and delivered, and more specifically with respect to this example will information about user behavior with respect to a particular attribute of the application be gathered/delivered. For instance, a rule may specify as part of its triggering criteria that repeated user interaction with a particular selection box on a particular worksheet in the application is to cause triggering of an advice service that displays advice to the user in order to eliminate the inefficiency in the user repeatedly selecting the same value for that selection box. Using this example, upon an event indicating interaction with the worksheet by the user, for instance when the user selects the worksheet for display on the screen, the rule is deemed pertinent because there is a possibility, by virtue of the worksheet being made active on the user&#39;s screen, for the user to interact with the selection box on that worksheet. The processing engine, responsive to the event of opening the worksheet, provides a notification channel that monitors for interaction with the selection box, and the advisor program application interface begins to monitor the selection box for future interactions by the user. It can be seen that the monitoring of user activity focuses on only particular attributes of the product about which rules have been created and implemented on the client workstation, in order to limit the scope of what is being observed. Instead of arbitrarily examining all of the user&#39;s behaviors with all attributes of the entire application, only those areas of the application about which a rule criterion is directed are examined, so that there is minimal impact on the user from a system performance standpoint. Furthermore, this enables services provided responsive to triggering of a rule (described below) to be targeted to exactly what the user is doing, ensuring that any advice provided is relevant to the user in both timing and substance, rather than an alternative broadcast approach whereby usage advice is provided in the form of randomized tips or other generalized user advice. 
     One example of hooking to the dispatch loop to learn of specific events is to utilize a subclass hook in order to effectuate preemptive or post-facto control of a system component, such as the CPU, after a specific event is processed. If the user opens a particular screen and a rule exists which, as part of its triggering criteria, is interested in a ‘grid’ on the screen, the advisor system can listen to the screen (by way of events on the dispatch loop) and wait for observed interaction with the grid. Upon interaction with the grid, the grid can be subclassed to obtain a direct channel into all interactions with that particular control. Subclassing, as those having ordinary skill in the art will recognize, allows additional code to react to a subset of user inputs directed at, e.g., a single window or control of the application. This can be achieved through the ‘WndProc’ function created following standard practice for application running on the Windows® line of operating systems offered by Microsoft. When another body of code needs to process user interactions, an alternative means of listening to further user interactions is via subclassing which, in the case of Windows®-based application, replaces the ‘WndProc’ address used by the operating system with a substitute—i.e. the address of the additional body of code. The old address of the ‘WndProc’ can still be used by the additional body of code in a chained call. One advantage of subclassing a control of interest is that it notifies of only relevant events, thereby eliminating the need to filter each message occurring within the application to identify messages associated with just the control of interest. 
     The hosting application, as part of its coding, uses discrete identifiers for identifying attributes of the application. These discrete identifiers are used in building information of an event passed to the dispatch loop. The discrete identifiers include attribute names, and attributes in the software can be identified using an attribute name from this set of identifiers, and can include either a customized or conventional name for the application attribute. The identifier can be used in rule specification to accurately identify application attributes in a manner that is consistent with the way the hosting application identifies the application attributes. This enables the advisor program to, for instance, use the identifiers in obtaining data about the application attributes. When a user interacts with the attribute, for instance toggles a dialog control causing an event to be reported, that interaction can be identified based on the attribute name provided in the event. This facilitates identifying the user behavior (e.g. toggling) with respect to the particular attribute (e.g. dialog control) of the application, in that reported events can be examined for the particular discrete identifier of a relevant application attribute. An event which reports that a window was opened might provide as part of the event information the title (name) of the window (attribute), the title being a discrete identifier used by the application. According to aspects of the present invention, specification of the rules is therefore made by way of these discrete identifiers, in order for the criteria of the rules to be understandable in the context of the application. When multiple applications host the advisor program, different rule sets can be applied using the respective identifiers of each hosting application. Alternatively, a single rule set can be applied for all hosting applications, or the hosting applications may employ a common set of identifiers. 
     Returning to  FIG. 3 , responsive to the user interacting with a relevant area or application attribute ( 312 ), such as one that is deemed relevant by virtue of it being specified in the criteria of one or more rules, the advisor program application interface receives and distributes interaction data ( 314 ) to the advisor processing engine of the advisor program. The interaction data includes information provided in the event reporting the interaction, such as the discrete identifier of the attribute that was being interacted with (e.g. “DialogControl 1 ”) and the nature of that interaction (e.g. ‘toggles on’ or ‘toggled off’). The processing engine builds a user behavior state by accumulating this interaction data within the context of the present application session ( 316 ). The behavior of the user with respect to the relevant attributes of the application is accumulated over a period of time to form a behavior state based on what is indicated in the rules as being relevant user behavior for monitoring. By way of example, if the triggering criteria of a rule is interested user interaction with a quantity input control in a particular area of the application three or more times without changing the entity on which the user operates (i.e. value in that quantity control), then the user behavior of selecting the control the first time, a second time, and a third time will be accumulated, each time building-up the behavior state with respect to that control based on the repeated interaction. Not only can interaction data be accumulated within the present application session, but additionally, the accumulated interaction data can be stored over multiple prior sessions with the application ( 318 ). A session is, in one example, some period of time during which the user interacts with the application and attributes thereof. In one example, a session extends from the time of opening or launching the application or an individual module until that application or module is exited or navigated away-from by the user. A built application state can therefore include data obtained across multiple sessions, and a built user behavior state of the application state can include user interaction data across the multiple sessions. In this manner, the buildup of user behavior state incorporates interaction data from previous and present interactions, enabling triggering of rule criteria based on non-serialized (i.e. out-of-sequence and/or out-of-order) interaction, if so desired. 
     More generally, the user behavior state can be part of an broader application state that is built from data obtained after identifying the relevant application attributes. relevant application attributes identified in the rule can include system properties (such as the browser installed on the workstation, particular hardware resources present, etc.), application configuration information, and/or application user data. Similar to the above, obtaining the data about these attributes could include monitoring the attributes over a period of time and building an application state based on the monitoring and including the obtained data in the built application state. 
     In addition to accumulating usage data, the advisor processing engine of the advisor program will evaluate affected rule(s) to determine whether the triggering criteria for those rule(s) is met based on the application state ( 320 ). In one example, the triggering criteria are specified in the form of one or more logical expressions, and the one or more logical expressions are evaluated to be either true or false. Triggering criteria is met when the logical expression(s) specified in the rule evaluates to true, meaning the criteria necessary for triggering the services specified by the rule are present. This is explained in further detail below with reference to  FIGS. 5 and 6 . Additionally, as noted above, a service specified in a rule can contribute to rule evaluation ( 330 ). For instance, a service specified in a rule might cause information such as system property information, application configuration information, or application user data to be obtained and used as part of the triggering criteria for the rule. If the triggering criteria of a rule is met, the advisor processing engine commences execution of the service request(s) made in that rule. This includes looking up each target (requested) service ( 322 ) specified in the rule, and executing the service ( 324 ), optionally using data parameters provided as part of the specification of the rule. In the example of  FIG. 3 , two types of advisor services are illustrated. The first executes to present a user interface to the user ( 326 ), for instance by highlighting a particular application attribute or portion of the screen, or displaying usage advice. In the latter example, a data parameter provided as part of the specification of the rule could be the advice message string that is to be presented to the user. The second service illustrated in  FIG. 3  executes to evaluate one or more SQL queries ( 328 ), for instance from an advisor database. Queries that can be run might lookup information about the configuration of the application or user data stored by the application, to enable execution of services to be based on the specific application configuration information and/or user data stored in a database. 
     While the example of  FIG. 3  illustrates two services triggered in response to the triggering criteria being satisfied, any number and type of services could be triggered. Below are just some examples of what activity execution of a service in the computing environment might perform: 
     Display a Message or Other Content, Such as Usage Advice: 
     The message could comprise a preformed set of presentation content, defined in the specification of the rule, and for display to the user as a result of that user performing certain behaviors in/to the product, as specified in the criteria for the rule. 
     Put More Data into the Feedback Channel ( 228   b  of  FIG. 2 ): 
     A service could comprise a feedback component that rules can leverage in order to provide feedback to the hosting product&#39;s company about how the rule was received by the end user. This can in turn enable the company to consume and analyze that feedback in order to further refine existing rules, tailor additional rules for deployment, etc. based how the rule was received by the user. In one example, feedback provides additional data that indicates whether the services specified in the rule are accomplishing the purpose for which the rule was initially deployed, for instance to eliminate an inefficiency in user behavior with respect to navigation or feature-use within the application. 
     Callout to a Backend Web Service: 
     A service may be executed to call to a backend service, such as a web service to perform an update or deletion to a module of the application, to download and install other modules of the application, and/or to perform a data fix-up of application configuration information or application user data. In one example, a rule can be implemented where, when it is indicated based on user behavior that the user may benefit from an additional piece of software available from the hosting product&#39;s company, the rule invokes a service to automatically download and/or install the piece of software. 
     Enable/Disable Other Rules: 
     A service can actuate (toggle) a rule on or off, which enables observation of particular behavior for a specifiable window of time, for instance two weeks. In another example, a service can enable another rule specifically defined to provide targeted feedback to the application developer, rather than the service itself providing the feedback. 
     Query the Product Database/Configuration: 
     A service can query application configuration information and/or user data by querying a database, in one example, having data about the configuration options for the application or user data stored by the application. 
       FIG. 4  depicts advisor program activities in association with a specific example of rule-based triggering of services, in accordance with one or more aspects of the present invention. In this example, the rule criteria of a rule specifies that the user changes a selection control, titled “Listbox”, five or more times. An application  402  hosting the advisor program displays a screen  402   a  with user interface (UI) elements, e.g. button  402   b  and Listbox  402   c . An advisor-application information interface  404  listens to events, e.g. from a dispatch loop, for initial pertinent user-behavior related information (for instance opening up screen  402   a  having button  402   b  and Listbox  402   c ). Since Rule  1  ( 410 ) is interested in user behavior with respect to Listbox  402   c , advisor-application information interface  404  creates, in one example responsive to an event such as the opening of screen  402   a , an advisor-control information interface  406  in order to obtain data about control  402   c , i.e. to directly observe any user interaction occurring on control  402   c . The user interaction data on both advisor-application information interface  404  and advisor-control information interface  406  is provided to rule engine  408 . Rule engine evaluates Rule  1  ( 410 ) and other installed rules on the workstation based on buildup of application state (in this example, the built-up user behavior state). In  FIG. 4 , Rule  1  ( 410 ) specifies triggering criteria (behavior expression  410   a ) of ‘changing the value in Listbox  402   c  five or more times’. Thus, as the user changes the value of Listbox  402   c , these interactions are observed on advisor-control information interface  406  and the behavior state is built-up over time with each successive user interaction to change the value of Listbox  402   c . The rule is evaluated based on this buildup of behavior state and may be triggered if the criteria evaluates to true. Assuming that the user changes the value of Listbox  402   c  five or more times, services specified by service requests  410   b  are looked up in a service registry  412 . In one example, service registry contains a list of service names mapped to executable code and is configured by the advisor program and/or hosting application. Each service specified in service requests  410   b , assuming the respective service is found in service registry  412 , is executed, optionally using data contained inside the rule or obtained responsive to executing a service specified in the rule to obtain the data. In  FIG. 4 , one service requested is a user message bubble service  414  which executes to display user message  416  having a message specified in service requests  410   b  of Rule  1  ( 410 ). Rule  1  ( 410 ) also requests an SQL query service  418  and other services  420 , which are also executed upon triggering of Rule  1  ( 410 ). 
     The scope of possibilities in the triggering criteria employed and services requested in the deployed rules is virtually infinite. Rules can be based on any combination of user behavior with respect to attributes of the application, system properties and other workstation variables (such as what web browser is installed on the system), application configuration information, and application user data stored by the application, as examples. Additional examples of rules, specified in plain English but readily implementable as triggering criteria and service requests within a rule include:
         (i) A user has never opened a particular screen within the application but he/she has used a feature, located somewhere else in the product, which is related to that screen. In this case, it might be beneficial to trigger one or more services that alert the user to the presence of that screen in the product, so that the user can more directly access the feature and/or related features.   (ii) A user has entered on multiple occasions a screen housing a particular control but has never entered data in that control. This can indicate that the user may not be aware of the presence of the control or what it does, in which case a service could be triggered to apprise the user of the control and its function. In this regard, the user behavior relevant to triggering the rule is based at least partially on the user&#39;s non-action (lack of interaction with the control).   (iii) A user who has run reports related to a single customer multiple times has never used a particular list box that might provide that same information in a different way. It might be beneficial to draw the user&#39;s attention to the list box and its function.   (iv) A user opens any of a number of list views a threshold number of times within a defined time period, has never used a management center module of the application (directed to providing the user with the list view information in an easier and more streamlined manner), and has version N or above of the application. An advice message could be provided indicating that the management center modules allow the user to obtain detailed information about the user&#39;s customers, vendors, and items at a glance. Also, from the developer&#39;s perspective, feedback-based success measurement/criteria for this rule could be the percentage of customers who, after receiving the message, open one or more management center modules a particular number of times within a particular time frame, and a service to enable a separate rule for obtaining and reporting this feedback could be executed.   (v) A user views a Customer Transaction History Report but has never opened the View Related Transactions list. An advice message could be displayed indicating to the user that related transactions (such as a purchase order being turned into a purchase or a quote being turned into an invoice) can be found using the View Related Transactions feature. Success measurement/criteria for this rule could be that the user opens the Related Transactions link at least X number of times within a particular time frame.   (vi) User opens an Aged Receivables report and has transactions in the last aging bracket with an unpaid status, but has no receipt transactions with a reference number of “WO” (to indicate a write-off of an unpaid transaction). An advice message could be displayed indicating that if a user knows that a customer is not going to pay, the invoice can be written-off without deleting it, in order to keep a record of the invoice and account for the user&#39;s loss. Success measurement/criteria for this rule could be that an invoice was paid off using the “WO” indicator in the invoice&#39;s reference number field within X number of days after the message was displayed for the user.       

     In one embodiment, rule criteria are specified through one or more logical expressions and may include nested logical expressions. Logical expressions include specification of expression elements, such as ‘constant’ values or application attributes for which related user behavior is examined in evaluating the rule triggering criteria. One example of a logical expression is described with reference to  FIG. 5 , which depicts a tree diagram graphically illustrating example rule criteria of a rule, in accordance with one or more aspects of the present invention. The rule criteria implemented in the illustrated tree diagram is: For version N or higher of the hosting application, user selected drop ship on a Sales Invoice screen today and has at least 5 purchase orders which occurred 10 times in a month. 
     In  FIG. 5 , tree  500  is rooted at node  502 , which is a logical AND expression having a left expression  502   a  and right expression  502   b . Since AND expression  502  is the root of tree  500 , the evaluation of root  502  (which encompasses an evaluation of the left expression  502   a  and right expression  502   b ) constitutes an evaluation of the entire rule criteria. 
     Beginning with right expression  502   b  (for description purposes, and without implicating an order in which the expression is evaluated), expression  504  is an “IN” expression in which an application query  506  is made in order to determine the current version of the hosting application. In one example, the product database and configuration information ( 222  in  FIG. 2 ) is queried to make this determination. Expression  504  implements the, “For version N or higher of the hosting application” constraint of the rule criteria recited above. The “IN” expression compares the current version of the application, returned responsive to the application query, with a list of constants  508  comprising a list of qualified versions of the application. The qualified versions of the application would list, in this case, versions N and above. In one example, the list of qualified versions is provided as data within the rule criteria, but the list could alternatively be provided elsewhere and referenced by the rule criteria. If the queried version number is N or above, “IN” expression  504  will evaluate to true, and therefore right expression  502   b  of AND expression  502  will evaluate to true. If the current version of the application is not in the list of qualified versions, i.e. is it below version N, then IN expression  504  and consequently AND expression  502  will evaluate to false, and the rule criteria will not be met for triggering the rule. 
     Left expression  502   a  itself comprises an AND expression  510  having left expression  510   a  and right expression  510   b . Additionally, a time constraint  512  is associated with AND expression  510 . Time constraint  512  requires that the actions specified in expression  510  be performed at least 10 times in a month period, and thus implements the, “which occurred 10 times in a month” constraint in the rule criteria recited above. Time constraint  512  is a threshold which must be met for left expression  502   a  to evaluate to true; if expression  510  is satisfied only 9 times within the past month, left expression  502   a  will not evaluate to true because time constraint  512  has not (yet) been satisfied. In this manner, the time constraint can correspond to a period of time during which application state is to be build via monitoring relevant application attributes and/or user interaction with the relevant application attributes. For purposes of example only, other time constraints might specify ‘that an action has never been taken’, ‘that the action has happened 5 times’ (ever, or since install of the application, for instance), ‘that the action has happened 5 times in the last 2 months’, or ‘that the action which comprises an action having occurred 5 times in an hour has happened 3 times in the last week’, as examples. 
     Left expression  510   a  of expression  510  implements the “has at least 5 purchase orders” constraint in the rule criteria recited above. A “GREATER THAN OR EQUAL TO” expression  514  is evaluated in which a number of purchase orders is queried  516  (for instance via a service specified in the rule itself, or via a remote service referenced by the logical expression, to query the application user data which indicates the number of purchase orders) and compared to a specified constant  518 , which is 5 in this example. Expression  514  evaluates to true if the queried number of purchase orders is 5 or more. 
     Right expression  510   b  includes another AND expression  520 . This expression implements the “user selected drop ship on a Sales Invoice screen today” aspect of the rule criteria. Left expression  520   a  of expression  520  includes an EQUAL expression  522  to determine whether an auto-create purchase order flag (which is application configuration information that is queried)  524  is equal to a constant, “0”  526 . This aspect of the expression is interested in whether the user has configured the application to automatically create purchase orders. If the user has not configured the application in this way, then the advisor program may, in one example as part of a triggered service, advise the user to enable the automatic creation of purchase orders. Right expression  520   b  includes an AND expression  528 , which has a left expression  528   a  indicating true if the drop ship checkbox control value changed  530 , and false otherwise. In implementing the detection of this change in value, user behavior with respect to this control value attribute of the application is monitored. In one example, a change event is listened-for on the drop ship checkbox control on the Sales Invoice screen. Receipt of the event indicates that the drop ship checkbox was changed, i.e. from being checked to unchecked, or from being unchecked to checked. Right expression  528   b  of AND expression  528  checks to determine which of the two—checked or unchecked—the user has changed the drop ship checkbox to indicate. Right expression  528   b  includes an EQUAL expression  532  which returns true if the value of the drop ship checkbox  534 , after being changed, is equal to constant “1” (indicating it is checked)  536 , and false otherwise. Expression  528  therefore determines whether (i) the drop ship checkbox control value changed and (ii) if it did change, whether it was changed to “1” which corresponds to being checked. 
     Additionally, time constraint  538  is associated with expression  528  in that the action by the user to change the drop ship checkbox control value must have been performed today in order for expression  528  to evaluate to true. In this manner, multiple time constraints can be placed on differing rule criteria, and the time constraints can be applied to nested expressions (e.g.  528  and  510 ). 
     Those having ordinary skill in the art will appreciate that there are many valid supported expression terms that can be used in a logical expression of a rule. A logical expression of a rule can include any logical expression term including AND, OR, NOT, NAND, NOR, XOR, etc. Similarly, usable comparison expressions include EQUAL (=) and GREATER THAN OR EQUAL TO (&gt;=) (as depicted in  FIG. 5 ), as well as NOT EQUAL TO (!=), GREATER THAN (&gt;) and LESS THAN (&lt;), and LESS THAN OR EQUAL TO (&lt;=), among others. 
     In one embodiment, the logic to implement a rule, including the criteria and service requests thereof, is html/xml based, i.e. written in an Extensible Markup Language (XML) format or variant thereof. This approach is advantageously different from an approach in which the rule is programmed using strict logic, such as compilable/compiled program code. Separation of the defined rules and the rule engine itself, which in one example is executable code on the workstation, advantageously enables the application developer to describe a rule to a user&#39;s system, which then implements the rule on the system apart from any modifications to the programming code of the application. The developer can cause messages to be provided to targeted users at any time. This is useful in a situation where a developer&#39;s application support center experiences a spike in a particular kind of support request for the application. In such a case, the developer can quickly define rule(s) that will target the users who experience, or who may experience, the subject support issue, i.e. those customers experiencing the kinds of problems driving the support call, and deploy the rule(s) to the workstations of those users, without requiring, for instance, a program code update to the application which could take a significantly longer amount of time to both develop and deploy. 
     Use of the above approach enables flexibility in rule creation, modification, and design. For instance, the application developer can receive indications based on observed user behavior, user feedback, etc. of a problem that affects users of the application, and can then react to those indications by specifying and/or modifying rule(s) to vet-out a target audience for receiving a rule to address the problem. The developer can create rule(s) that will observe and report which users are, or may be, experiencing the problem. Additionally during this process, the developer will identify one or more aspects of the users&#39; usage of the application where a solution to the problem (for instance provision of advice or guidance) would be useful, and can respond by developing and deploying rules that directly address and most accurately align with the needs of users who experience, or may potentially experience, the problem. 
     As described above, rules can be constructed based on identified problems. Additionally or alternatively, rules can be constructed based on any other desired reason including, but not limited to: the way in which a marketing department of the product developer wishes to present new and/or additional features to the users, the way in which customer support &amp; sales departments wish to impact the customer users in order to leverage additional business opportunities between the users and developer, to draw attention to aspects of the application that are specifically designed and targeted for particular customers&#39; use cases, and to identify the use cases where particular advice would be welcome. 
       FIG. 6  depicts an example of an XML-based rule format using descriptive data elements, in accordance with one or more aspects of the present invention. Rules deployed to customers can be written in XML code in the format depicted, and deployed as a package to the customer workstations, in one example. In  FIG. 6 , rule  602  includes description  604 , version indication  606 , enabled flag  608 , criteria portion  610 , and actions portion  612 . Description  604  includes a description of the rule, which can be provided for clarity and explanation as to the rule&#39;s purpose and direction. Version indication  606  indicates a version of the rule, since a rule may undergo revisions over time as feedback is received about how the rule is being received by customers (e.g. whether the rule is working for its intended purpose). Enabled flag  608  is used to either enable or disable a rule. A rule can optionally be enabled or disabled depending on whether the rule is to be enforced at a particular time. Additionally, in one example, rules can enable other rules. This helps to ensure that only behavior which is relevant and necessary for observation at the current time is being observed, and that further behavior, for instance behavior specified in other related rules, is not being observed presently. 
     Criteria portion  610  includes one or more criteria. In  FIG. 6 , criteria portion includes a single criterion which is an AND expression having an associated description, and a left expression (which is an IN expression and which code thereof has been omitted by collapsing the left expression) and a right expression (which is AND expression and which code thereof has been omitted by collapsing the left expression). Further details of the left and right expressions (i.e. code thereof) has been omitted in  FIG. 6 . 
     Actions portion  612  includes one or more service requests, specified, in this example, as action data containers. In the example of  FIG. 6 , action data containers have associated with them a type (e.g. “SignalActionDataContainer”) and, in the case of a signal service, signal type (e.g. “Action Passed” or “Action Failed”) indicating for the signal service functional activity to perform depending on whether the action is passed or failed. Further details of the action data containers has been omitted (i.e. code thereof has been omitted by collapsing the Action data containers) from  FIG. 6 . 
     Five further example XML-implemented rules in accordance with aspects of the present invention are provided below. The rules below are subject to copyright protection. The copyright owner, Sage Software, Inc., has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records of any country, but otherwise reserves all rights whatsoever. 

 
     As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. 
     Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. 
     Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. 
     Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user&#39;s computer, partly on the user&#39;s computer, as a stand-alone software package, partly on the user&#39;s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user&#39;s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). 
     Referring now to  FIG. 7 , in one example, a computer program product  700  includes, for instance, one or more computer readable media  702  to store computer readable program code means or logic  704  thereon to provide and facilitate one or more aspects of the present invention. 
     Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. 
     These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. 
     These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks. 
     The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. 
     The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. 
     Further, a data processing system suitable for storing and/or executing program code is usable that includes at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memory which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. 
     Input/Output or I/O devices (including, but not limited to, keyboards, displays, pointing devices, DASD, tape, CDs, DVDs, thumb drives and other memory media, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters. 
     The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprise” (and any form of comprise, such as “comprises” and “comprising”), “have” (and any form of have, such as “has” and “having”), “include” (and any form of include, such as “includes” and “including”), and “contain” (and any form contain, such as “contains” and “containing”) are open-ended linking verbs. As a result, a method or device that “comprises”, “has”, “includes” or “contains” one or more steps or elements possesses those one or more steps or elements, but is not limited to possessing only those one or more steps or elements. Likewise, a step of a method or an element of a device that “comprises”, “has”, “includes” or “contains” one or more features possesses those one or more features, but is not limited to possessing only those one or more features. Furthermore, a device or structure that is configured in a certain way is configured in at least that way, but may also be configured in ways that are not listed. 
     The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiment with various modifications as are suited to the particular use contemplated.