Patent Application
20190306009
The present disclosure relates generally to configuration management databases (CMDBs) and, more particularly, to managing alerts in CMDBs.
This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Cloud computing relates to the sharing of computing resources that are generally accessed via the Internet. In particular, a cloud computing infrastructure allows users, such as individuals and/or enterprises, to access a shared pool of computing resources, such as servers, storage devices, networks, applications, and/or other computing based services. By doing so, users are able to access computing resources on demand that are located at remote locations, which resources may be used to perform a variety computing functions (e.g., storing and/or processing large quantities of computing data). For enterprise and other organization users, cloud computing provides flexibility in accessing cloud computing resources without accruing large up-front costs, such as purchasing expensive network equipment or investing large amounts of time in establishing a private network infrastructure. Instead, by utilizing cloud computing resources, users are able redirect their resources to focus on their enterprise's core functions.
In modern communication networks, examples of cloud computing services a user may utilize include so-called software as a service (SaaS) and platform as a service (PaaS) technologies. SaaS is a delivery model that provides software as a service rather than an end product. Instead of utilizing a local network or individual software installations, software is typically licensed on a subscription basis, hosted on a remote machine, and accessed by client customers as needed. For example, users are generally able to access a variety of enterprise and/or information technology (IT)-related software via a web browser. PaaS acts an extension of SaaS that goes beyond providing software services by offering customizability and expandability features to meet a user's needs. For example, PaaS can provide a cloud-based developmental platform for users to develop, modify, and/or customize applications and/or automating enterprise operations without maintaining network infrastructure and/or allocating computing resources normally associated with these functions.
Within the context of cloud computing solutions for CMDBs, users may be asked to deal with ever increasing amounts of data, e.g., with respect to the number of Configuration Items (CIs) stored in the CMDB (including such CIs' relevant metadata, such as manufacturer, vendor, location, etc.), as well as the alerts, service metrics, and maintenance status information related to such CIs. In fact, the amount of data collected and stored in today's cloud computing solutions, such as CMDBs, may be orders of magnitude greater than what was historically collected and stored. Users tasked with automating and/or troubleshooting enterprise, IT, and/or other organization-related functions (e.g., incident tracking and/or help desk-related functions) navigate ever increasing amounts of data to properly and efficiently perform their job functions. In particular, CMDBs may generate hundreds or thousands of alerts in a brief period of time, and users may want to define complex, automatic responses to these alerts. With this in mind, the following embodiments are directed to improving the manner in which alerts are managed within the CMDB, as well as the manner in which the user interfaces with the alert management system, in order to provide an enhanced user experience.
A summary of certain embodiments disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects that may not be set forth below.
Present embodiments are directed toward a context-based alert management system for use in a CMDB platform. Present embodiments enable users to create and implement customized alert rules in which substantially all alert context is available throughout execution of the alert rules. For example, user can design an alert rule that references substantially any information relating to alerts, to configuration items (CIs) associated with alerts, events related to alerts, or any other suitable data stored by the client instance, which together comprise alert context. As such, the presently disclosed technique generally makes alert management more intuitive, flexible, structured, and process driven, and provides an improved interface for creating and visualizing alert rules.
In an example embodiment, a client instance that is associated with a CMDB platform includes database tables related to the disclosed alert management system. For example, the database tables may include an alert table, an alert rules table, and a configuration items (CI) table. The alert management system also includes an alert rules engine that is configured to execute the alert rules in the alert rule table against the alerts in the alert table. This may include applying one or more filters of an alert rule to the alert table, and then evaluating one or more conditions of the alert rule using the results of the one or more filters. When the one or more conditions are satisfied, the alert rules engine further executes one or more actions of the alert rule. Substantially all of the alert context is available and can be accessed by the alert rule during execution of any portion (e.g., filters, conditions, and actions) of the alert rule. For example, an alert rule may include filters, conditions, and actions that each reference the context of one or more alerts in the alert table. In certain embodiments, the alert rule include or reference alert field values, time conditions, CI conditions, escalation conditions, among others, as discussed herein.
Various aspects of this disclosure may be better understood upon reading the following detailed description and upon reference to the drawings in which:
One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and enterprise-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
As used herein, the term “computing system” refers to a single electronic computing device that includes, but is not limited to a single computer, virtual machine, virtual container, host, server, laptop, and/or mobile device, or to a plurality of electronic computing devices working together to perform the function described as being performed on or by the computing system. As used herein, the term “medium” refers to one or more non-transitory physical media that together store the contents described as being stored thereon. Embodiments may include non-volatile secondary storage, read-only memory (ROM), and/or random-access memory (RAM). As used herein, the term “application” refers to one or more computing modules, programs, processes, workloads, threads and/or a set of computing instructions executed by a computing system. Example embodiments of an application include software modules, software objects, software instances and/or other types of executable code. As used herein, the term “configuration item” or “CI” refers to a record for any component (e.g., computer, device, piece of software, database table, script, webpage, piece of metadata, etc.) in an enterprise network, for which all relevant data, such as manufacturer, vendor, location, or similar data, is stored in a CMDB.
The term “context” as used herein with respect to an alert may include substantially any information stored in the CMDB that is related to the alert. For example, alert context may include all suitable fields of the alert, all CI fields for CIs associated with the alert, as well as any field of a related alert and any field of an event associated with the alert. By way of more specific example, the context of an alert may include a severity of the alert, a time of the alert, a CI that generated the alert, information regarding related CIs, relationships to other alerts, and so forth.
Present embodiments are directed toward a context-based alert management system for a CMDB. Present embodiments enable the creation and implementation of alert rules that can access substantially any alert context as variables during execution to provide customized alert management. As discussed, an alert rule may be generally described as a “if . . . then” conditional statement, wherein at least one associated action is executed when a defined set of filters and conditions are satisfied. The “if” portion of the alert rule can include any suitable number of filters and conditions that are combined to identify and evaluate alerts based on particular alert context. Additionally, since substantially all alert context is exposed and available during execution of the alert rules, this enables the design and implementation of complex and powerful alert rules based on any suitable aspect of the alert context. As such, the presently disclosed technique generally makes alert rules more intuitive, flexible, structured, and process driven, and provides an improved interface for creating and visualizing alert rules.
Turning now to
For the illustrated embodiment,
In
To utilize computing resources within the CMDB platform 20, network operators may choose to configure the data centers 22 using a variety of computing infrastructures. In one embodiment, one or more of the data centers 22 are configured using a multi-tenant cloud architecture, such that one of the server instances 24 handles requests and serves multiple customers. In other words, data centers with multi-tenant cloud architecture commingle and store data from multiple customers, where multiple customer instances are assigned to one of the server instances 24. In a multi-tenant cloud architecture, the particular server instance of the server instances 24 distinguishes between and segregates data and other information of the various customers. For example, a multi-tenant cloud architecture could assign a particular identifier for each customer in order to identify and segregate the data from each customer. Generally, implementing a multi-tenant cloud architecture may suffer from various drawbacks, such as a failure to a particular one of the server instances 24 causing outages for all customers allocated to the particular server instance.
In another embodiment, one or more of the data centers 22 are configured using a multi-instance cloud architecture to provide every customer its own unique customer instance. For example, a multi-instance cloud architecture could provide each customer instance with its own dedicated application server and dedicated database server. In other examples, the multi-instance cloud architecture could deploy a single server instance and/or other combinations of server instances 24, such as one or more dedicated web server instances, one or more dedicated application server instances, and one or more database server instances, for each customer instance. In a multi-instance cloud architecture, multiple customer instances could be installed on a single physical hardware server, where each customer instance is allocated certain portions of the physical server resources, such as computing memory, storage, and processing power. By doing so, each customer instance has its own unique software stack that provides the benefit of data isolation, relatively less downtime for customers to access the CMDB platform 20, and customer-driven upgrade schedules. An example of implementing a customer instance within a multi-instance cloud architecture will be discussed in more detail below with reference to
To facilitate higher availability of the client instance 42, the application server instances 24A-24D and database server instances 44A and 44B are allocated to two different data centers 22A and 22B, where one of the data centers 22 acts as a backup data center. In reference to
As shown in
Although
As mentioned, present embodiments are directed to a CMDB alert management system, such as the alert management system 60 illustrated in
For the embodiment of the alert management system 60 illustrated in
Additionally, as illustrated in
As such, the client instance 42 receives (block 84) at least one filter of the new alert rule from the client device 14D. The client instance 42 also receives (block 86) at least one condition of the new alert rule from the client device 14D. Additionally, the client instance 42 receives (block 88) at least one action of the new alert rule. Then, the client instance 42 defines (block 90) a new row or entry in the one or more alert rules tables 66 based on the received one or more filters, conditions, and actions received in the proceeding steps. The alert context-based filters, conditions, and actions of the disclosed alert rules are discussed in greater detail below.
As mentioned, the disclosed alert management system 60 enables the creation and execution of complex alert context-based rules. More specifically, the disclosed system enables an authorized user to create an alert rule according to the general pattern, “If alert A (defined filter 1) (and or) alert B (defined filter 2) . . . and if (defined condition 1) (and or) (defined condition 2) . . . Then Do (defined action 1) (and or) (defined action 2) . . . ” As such, an alert rule may be generally described as an “If . . . then” statement that having an “if” portion including one or more filters and one or more conditions, and having a “then” portion including one or more actions (e.g., action 1, action 2) that are executed when the “if” portion of the statement is satisfied (e.g., evaluated as true). The “if” portion of the alert rule may contain any suitable Boolean combination of alert filters and alert conditions based on any suitable alert context, such as alerts having a severity of critical, alerts occurring on weekends, or recurrent alerts having a frequency greater than a predetermined threshold value. Since the entire context of each the alerts is exposed and available throughout execution of the alert rule (e.g., filters, conditions, and actions) this enables the construction of complex alert rules, as discussed.
As mentioned, the disclosed alert rule includes an “if” portion having any suitable number of alert filters and alert conditions, each specifying criteria for alerts based on alert context, wherein the output of each of the alert filters and alert conditions may be combined via an AND or an OR Boolean operator. In certain embodiments, a filter may specify an alert field or attribute (e.g., alert severity, alert class, alert condition, alert time) as having a value that is equal to a particular value, as well as greater than/less than a particular value (e.g., minimum/maximum threshold values) for numeric alert attributes.
In certain embodiments, a filter may be based on the alert source and include any suitable attribute of the CI that generated the alert (e.g., a class of the CI, a location of the CI). For example, a filter may specify alerts that are generated by the same CI or by related CIs in the CMDB platform 20. In certain embodiments, a filter may specify any query condition of the CMDB, such as the presence of a particular record in a particular table of the CMDB. For example, a filter may include a query to any suitable alert related table of the CMDB, such as an impact services table, a groups table, an events table, or another table storing related incidents (INT), changes (CHG), or problems (PRB) related to alerts in the CMDB. In certain embodiments, a filter may specify alerts that are primary, alerts that are secondary, or alerts that are neither.
In certain embodiments, one or more of the filters may be based on a time component and/or a frequency component of the alerts. For example, a filter may specify alerts generated during a particular calendar setting (e.g., work day, weekend, holiday). In certain embodiments, a filter may specify limitations regarding the respective alert history of each of the alerts. For example, the filter may indicate that if alert A is repeated more than a predetermined number of times, then do perform a particular action. In certain embodiments, a filter may specify alerts or other events having a particular frequency (e.g., once per hour, once per day). For example, to implement an escalation strategy, a filter may specify an alert that is present in an alert queue more than a predetermined number of times and that has not been acknowledged more than a second predetermined number of times.
As mentioned, an alert rule may also include one or more alert conditions that are also based on alert context. In general, alert filters generally filter (e.g., identify, select) alerts based on alert context, while alert conditions determine whether the “if” portion of the alert rule is satisfied by the filtered alert(s). For example, when an alert rule only includes a single filter, then the alert condition may compare the context of the filtered alert to particular values to determine whether the “if” portion of the alert rule is satisfied. When multiple alert filters are used, alert rule conditions may compare the alert context of a first alert (filtered by filter A) to the alert context of a second alert (filtered by filter B) to determine whether the “if” portion of the alert rule is satisfied.
For example, within an alert rule, a first filter defines alert A, and a second filter defines alert B, and an alert condition may then compare particular context of the first alert to particular context of the second alert to determine whether or not the “if” portion of the alert rule is satisfied. By way of specific example, an alert rule condition may specify that if alert A has the same alert type as alert B, or if alert A has higher severity than alert B, then perform a particular action. In certain embodiments, an alert rule condition may include a time component with respect to multiple alerts. For example, a condition of an alert rule may specify that an action be taken if alert A (defined by filter A) has a timestamp that is within a threshold time window (e.g., within 2 hours of) alert B (defined by filter B). In certain embodiments, an alert rule condition may specify relationships between the filtered alerts. For example, an alert rule condition may specify an action be performed if an alert A is a child of alert B, or if alert B is a parent of alert A.
As mentioned, an alert rule includes one or more actions that are executed when the “if” portion of the alert rule is determined to be true. Additionally, as mentioned, substantially all fields associated with the alerts and CIs of the CMDB platform 20 are available for use during the execution of the actions of an alert rule, enabling sophisticated, customized responses to manage alerts. In certain cases, the alert rule actions may be relatively simple. For example, an action may include acknowledging or closing one or more alerts. In certain embodiments, the actions may include adjusting an attribute associated with one or more alerts. For example, an alert rule action can involve changing, modifying, or overriding information regarding alert severity, acknowledgement, maintenance, or any other suitable alert information. Alert rule actions may also include associating a knowledge base document or assigning an alert template with one or more alerts. Additionally, in certain embodiments, the actions of an alert rule may include defined delays (e.g., wait a predetermined number of seconds before executing), as well as define escalating actions (e.g., for recurring or unacknowledged alerts).
In certain embodiments, the alert rule actions include actions that define (e.g., create, modify) relationships between alerts. For example, in certain embodiments, alert rule actions may include adding one or more alerts to an alert group. By way of specific example, a hierarchy alert group includes a primary alert that is associated with any suitable number of secondary alerts. A peer-to-peer alert group may include a master alert as the primary alert of the group, or enable a user-defined primary alert, wherein closing the primary alert removes/closes the entire group. With this in mind, the presently disclosed alert rule actions can create and define new primary alerts for hierarchy alert groups, as well as modify the role (e.g., primary, secondary) of one or more alerts. Additionally, an alert rule action may add one or more alerts to, or remove one or more alerts from, a group, as well as define new alert groups.
In certain embodiments, the one or more alert rule actions of an alert rule include external alert rule actions. As used herein, “external” refers to actions of the client instance that are outside of the alert portion of the system. In certain embodiments, these external actions include launching one or more application(s), such as an interactive user interface or launcher. The external actions may include running one or more remediations, which may be interactive or may execute in the background. In certain embodiments, the external action can include opening a new incident (INT), change (CHG), or problem (PRB) in the CMDB, immediately or with a predetermined delay. The external action may include conditionally updating an existing INT/CHG/PRB, such as assigning it to a group. For example, the external actions may include escalating, merging, or conditionally auto-closing INTs/CHGs/PRBs based on alert context. External actions may also include sending an email, creating an alert task, executing a script or workflow, updating a service level agreement (SLA), creating outage records, or running a discovery operation (e.g., horizontal, top down). In certain embodiments, external actions include changing a service status, opening a chat dialog in a messaging tool, and updating CI attributes. External actions may also include making Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) calls that are not associated with the GUI, as well as updating data source (e.g., update system center operation manager (SCOM) with a parameter from the alert).
As such, the disclosed design enables the design of complex alert rules. For example, the present technique enables the creation of alert rules that define whether to execute an action once (e.g., only on new alert, or on updated alerts) or every time the alert is generated until a certain threshold (e.g. run remediation only 3 times). Additionally, the present technique enables the creation of an alert rule that indicates, for example, if a secondary alert is added to a primary alert, then update the related INTs, and if the primary alert is not group membered, and an INT is opened and the alert becomes a secondary alert, merge the INTs together. By way of further example, the disclosed alert rules enable an INT to be updated (e.g., change description, priority, or assignment group), in response to a change in severity of an alert.
In certain embodiments, a single alert rule can be a combination of multiple “if . . . then” statements. For example, a single alert rule may specify, “If alert.field1 is X, then perform action A, and if alert.field2 is Y, then perform action B.” As such, for this example, action A and/or B may be performed based on the values of the indicated alert fields. In another example, an alert rule may dictate that if a particular CI generated an alert, then a first INT is opened, and if the particular CI generated the alert and the alert has a severity of critical, then an second INT is opened and a notification is generated. In certain cases, the first and second INTs may be the same, while in other cases, the first and the second incidents may have a different category, a different assignment group, a different service level agreement (SLA).
Below are examples of alert rules, in accordance with present embodiments. In certain cases, an alert rule may be relatively simple. For example, an example alert rule may indicate, “If alert.source is X then open incident.” Accordingly, a new incident is opened if an alert can be located indicating that X is the alert source. In another example, an alert rule may indicate, “If alert.type is X and if alert. description contains Y, and alert.severity is critical, then open incident, send email, and mark alert as acknowledged.” As such, only if an alert can be located having the specified alert type, description, and severity will an incident be opened, an email sent, and the alert marked as acknowledged. Another example alert rule may indicate, “If alert.type is X, and if alert.description contains Y, and alert.time is in ‘working hours’, then open incident (different assignment group), send email, and mark alert as acknowledged.” Accordingly, only if an alert can be located having the specified alert type, description, and calendar setting will an incident be opened that is assigned to a different group relative to the alert, an email sent, and the alert marked as acknowledged.
In certain cases, an alert rule may be more complex. For example, an alert rule may indicate, “If alert.type is X, and alert. description contains Y, and alert.severity is critical, and CI is member in ‘Service ABC’, then open incident (different INT category, assignment group), send email, and mark alert as acknowledged.” For this example, only if an alert can be located having the specified alert type, description, severity, and that is generated by a CI that is a member of the specified service, will an incident will be opened in a different INT category and assigned to a different group relative to the alert, an email sent, and the alert marked as acknowledged. By way of further example, an alert rule may indicate, “If alert.severity is higher than major, and service.priority is critical, then open a major INT.” For this example, if an alert can be located having a severity that is above major and that is associated with a service having a critical priority, then a major incident is opened. In another example, an alert rule may indicate, “If count (alert.secondaries) is higher than 10, then increase alert.severity.” For this example, if an alert can be located having a secondary alert count greater than 10, then the severity of the alert is increased.
In certain cases, an alert rule may involve or define relationships between alerts. For example, an alert rule may indicate, “If alert.a.type is processor, and alert.b.type is memory, and alert.a.CI is the same as alert.b.CI, then set alert.a as parent and alert.b as child.” In this example, if a first alert (alert.a) can be located having the specified type, and a second alert (alert.b) can be located having the specified type, and both of the alerts are generated by the same CI, then set the first alert as the parent of the second alert. In another example, an alert rule may indicate, “If alert.a.severity is critical, and alert.b.severity is the same as alert.a.severity, and alert.a.CI is the same as alert.b.CI, and alert.a.createdtime diff from alert.b.createdtime by 120 sec or less, then set alert.a as parent and alert.b as child.” In this example, if a first alert (alert.a) and a second alert (alert.b) both have a severity of critical, are generated by the same CI, and are generated within two minutes of one another, then the first alert is set as the parent of the second alert.
In yet another example, an alert rule may indicate, “If alert.a.severity is critical and alert.b.severity is the same as alert.a.severity and alert.a.CI runs on alert.b.CI and alert.a.createdtime diff from alert.b.createdtime by 120 sec, then set alert.a as parent and alert.b as child.” For this example, if a first alert (alert.a) and a second alert (alert.b) both have a severity of critical, are generated within two minutes of one another, and the CI that generated the first alert runs on (e.g., is hosted by) the CI that generated the second alert, then the first alert is set as the parent of the second alert. In still another example, an alert rule may indicate, “If alert.a.severity is critical, and alert.b.severity is the same as alert.a.severity, and alert.a.CI runs on alert.b.CI and alert.a.createdtime diff from alert.b.createdtime by 120 sec, then create alert.c (new) set alert.c as parent and alert.a and alert.b as child.” For this example, if a first alert (alert.a) and a second alert (alert.b) both have a severity of critical, are generated less than two minutes of one another, and the CI that generated the first alert runs on (e.g., is hosted by) the CI that generated the second alert, then create a new alert (alert.c) and make the first and second alerts children of the new alert.
Additionally, as mentioned, alert rules can be created to define how alerts may be escalated. For example, an alert rule may indicate, “If alert is opened and not acknowledge more than X min and alert.a.CI is member in service A, then send email.” For this example, if an open alert can be locate that has not been acknowledged in more than X minutes, wherein the CI that generated the alert is a member of the indicated service, then an email is sent.
For the illustrated embodiment, the first row 126 includes user input mechanisms for combining different subconditions to define the first filter of the new alert rule. These include a remove subcondition button 136A, an “OR” button 138A, and an “AND” button 140A. In response to receiving a selection of the “OR” button 138A or the “AND” button 140A, the second row 128 is presented as part of the first set of user input mechanisms 124 to enable the user to define a second subcondition of the first filter. In the illustrated example, the second subcondition was initiated using the “AND” button 140A, resulting in the “AND” indicator 142 positioned between the first row 126 and second row 128 of the first set of user input mechanisms 124. The second row 128 includes a respective first drop-down list 130B, second drop-down list 132B, third drop-down list 134B, remove subcondition button 136B, “OR” button 138B, and “AND” button 140B, which function as described above for the user input mechanisms of the first row 126. In response to receiving a user selection of the remove subcondition button 136A, the second row 128 may be removed from the second screen 120. In other embodiments, other features may be included on the second screen 120, including options to define the alert rule using a character string in lieu of the illustrated drop-down lists. Accordingly, the second screen 120 generally enables the user to define and combine any suitable number of subconditions to define the first filter of the alert rule.
Additionally, the illustrated second screen 120 also includes an add correlated alerts button 144 that enables the user to define and combine multiple filters when creating the alert rule. For example, in response to receiving a user selection of the add correlated alerts button 144, the user may be presented with an updated second screen 150, as illustrated in
When a single filter is defined for the alert rule (e.g., in
The illustrated third screen 160 includes a second set of user input mechanisms 182 that enable the user to define a count condition of an alert rule. The second set of user input mechanisms 182 includes a first row 184 and a second row 186 of input mechanisms. The first row 184 and the second row 186 include respective first drop-down lists 188A and 188B that include options involving total occurrences of filtered alerts. For example, when the alert rule includes only one filter, then the first drop down lists 188A and 188B may be populated with selectable options, such as a total number of primary events, or a total number of secondary events, returned by the sole filter. By way of further example, when the alert rule includes two filters, one defining alert A and another defining alert B, then the first drop-down list 188A may be populated with selectable options, including “alert A total events”, “alert B total events”, and “all alerts total events”. Second drop-down lists 190A and 190B of the first and second rows 184 and 186, respectively, include options similar to the second drop down list 132A discussed above. Third text boxes 192A and 192B of the first and second rows 184 and 186, respectively, enable entry of positive integer values. Additionally, row 186 and 186 include respective remove subcondition buttons 194A and 194B, “OR” buttons 196A and 196B, and “AND” buttons 198A and 198B, which generally function as discussed above for adding and removing additional subconditions to the count condition of the alert rule.
The illustrated fifth screen 220 illustrated in
The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.
The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . . ” or “step for [perform]ing [a function] . . . ”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).
