Trials@uspto.gov
`571-272-7822
`
`
`
`Paper No. 12
`Entered: September 11, 2015
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SERVICENOW, INC.,
`Petitioner,
`
`v.
`
`BMC SOFTWARE, INC.,
`Patent Owner.
`____________
`
`Case CBM2015-00107
`Patent 7,062,683 B2
`____________
`
`
`
`Before JUSTIN T. ARBES, JENNIFER MEYER CHAGNON, and
`TIMOTHY J. GOODSON, Administrative Patent Judges.
`
`GOODSON, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Covered Business Method Patent Review
`37 C.F.R. § 42.208
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`I.
`
`INTRODUCTION
`
`Petitioner ServiceNow, Inc. filed a Corrected Petition (Paper 4,
`
`“Pet.”) requesting covered business method patent review of claims 1–3, 12,
`
`14, 21, 22, 24–26, 35, 37, 44, 45, 56–58, 67, 69, 76, 77, 79, 80, 83, 85, and
`
`88–90 of U.S. Patent No. 7,062,683 B2 (Ex. 1001, “the ’683 patent”).
`
`Patent Owner BMC Software, Inc. filed a Preliminary Response (Paper 11,
`
`“Prelim. Resp.”).
`
`We have jurisdiction under 35 U.S.C. § 324. Pursuant to 35 U.S.C.
`
`§ 324(a), the Director may not authorize a covered business method patent
`
`review unless the information in the petition, if unrebutted, “would
`
`demonstrate that it is more likely than not that at least 1 of the claims
`
`challenged in the petition is unpatentable.” As explained below, we do not
`
`institute a covered business method patent review because the information
`
`presented in the Petition does not establish that the ’683 patent qualifies as a
`
`covered business method patent.
`
`A. The ’683 Patent
`
`The ’683 patent relates to a method of using fault models to analyze
`
`error conditions in an enterprise computing system. Ex. 1001, 1:5–10.
`
`The ’683 patent explains that the reliability of complex enterprises
`
`depends in large part on detecting and managing operational problems, such
`
`as hardware or software failures. Id. at 1:21–27. As an enterprise
`
`incorporates more monitored components, the occurrence of observable
`
`events greatly increases. Id. at 1:30–35. Many of these are “sympathetic
`
`events” that are generated as a result of the underlying problem. Id. at 1:35–
`
`38. The ’683 patent explains:
`
`For example, a router failure may generate a “router down”
`event and a large number of “lost connectivity” events for
`
`2
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`components that communicate through the failed router. In this
`scenario, the router failure is the fundamental or “root cause” of
`the problem and the lost connectivity events are “sympathetic”
`events.
`
`Id. at 1:42–47. These sympathetic events complicate the task of identifying
`
`the cause of a problem. Id. at 1:35–38. According to the ’683 patent, “up to
`
`80% of a network’s down-time is spent analyzing event data to identify the
`
`underlying problem(s).” Id. at 1:48–50.
`
`The approach described in the ’683 patent uses a combination of
`
`up-stream analysis and down-stream analysis on an impact graph to identify
`
`root cause faults separately from other notifications, many of which may be
`
`sympathetic. Id. at 4:33–40. Figure 1 is reproduced below:
`
`Figure 1 is a flowchart showing the steps of model based reasoning
`
`(MBR) approach 100. Id. at 3:12–14, 4:31–33. As depicted by block 105 in
`
`Figure 1, the process begins when an alarm is received that provides
`
`
`
`notification of an event. Id. at 4:40–41.
`
`3
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`In block 110, an up-stream analysis of the impact graph is performed
`
`beginning with the node that received the event notification, the effect of
`
`which may be to modify the “status value” of up-stream nodes. Id. at 4:43–
`
`46. Up-stream analysis
`
`proceeds, in an iterative fashion, up the graph until (1) there are
`no more up-stream nodes; or (2) a node’s status value does not
`change as a result of the node’s inference policy; or (3) the
`inferred status value for a node is different from the node’s
`measured status value.
`
`Id. at 6:3–7.
`
`Next, in block 115, down-stream analysis is performed beginning with
`
`the furthest up-stream node whose status value was modified in the up-
`
`stream analysis. Id. at 4:46–50. The effect of the down-stream analysis may
`
`be to modify the “impact value” of nodes down-stream of the starting node.
`
`Id. at 4:50–53. In the down-stream analysis, the “starting node’s impact
`
`policy, and each successive immediately down-stream node’s impact
`
`policy[,] are then evaluated until (1) there are no more down-stream nodes or
`
`(2) a down-stream node’s impact value does not change as a result of the
`
`evaluation.” Id. at 6:56–60.
`
`In block 120, identification of root-cause failures and sympathetic
`
`event notifications can be reported. Id. at 4:60–63. Generally, the root-
`
`causes are the furthest up-stream nodes having a status value indicative of
`
`failure. Id. at 4:63–67. Nodes down-stream from the root cause and whose
`
`impact values indicate that they were impacted by the root-cause failure can
`
`also be shown, but it may be beneficial for these event notifications of
`
`impacted nodes to be masked or displayed in a different manner than the
`
`root causes. Id. at 5:3–8.
`
`4
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`The ’683 patent illustrates the method of Figure 1 by applying it to an
`
`exemplary enterprise. See id. at 9:7–11. In particular, Figure 7, which is
`
`reproduced below, depicts an impact graph for an enterprise consisting of
`
`automatic teller machines (ATMs) coupled to a central banking facility
`
`through a satellite communications system. Id. at 7:31–34, 8:43–45.
`
`
`
`The illustrative example begins when, in accordance with block 105
`
`of Figure 1, an alarm event associated with node 715 is received. Id. at
`
`9:10–11. The event notification causes the status value of node 715 to be
`
`measured “true,” which indicates a failed status. Id. at 9:50–54.
`
`In the up-stream processing of block 110, the inference policies of
`
`nodes 705, 710 are evaluated. Id. at 9:12–45. In this example, the status
`
`values of nodes 705, 710 are inferred to be “true” because the immediately
`
`5
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`downstream node, node 715, has a status indicative of a “NO_MONEY”
`
`condition. Id. at 9:29–54.
`
`Next, down-stream processing is performed, as in block 115. “To
`
`begin, a starting node is selected that (1) has had its status value changed
`
`during the up-stream analysis of block 110 and (2) is maximally up-stream
`
`from the node receiving the original event notification (that is, node 715).”
`
`Id. at 9:56–60. Because both nodes 705, 710 meet those criteria, one of
`
`those is selected arbitrarily as the starting node. Id. at 9:61–62. During
`
`down-stream processing, the impact policies of down-stream nodes 715 and
`
`755 are evaluated and, applying the results of those evaluations, the impact
`
`values of nodes 715 and 755 are modified to “true” to indicate that they are
`
`impacted. Id. at 10:1–31. The impact values of nodes 705 and 710 are also
`
`modified to “true.” Id. at 10:29–31.
`
`In accordance with block 120, the results are then reported. Id. at
`
`10:32–34. Nodes 705 and 710 are identified as the root cause because they
`
`are the most up-stream nodes having a status value indicative of failure. Id.
`
`at 10:34–40. Nodes 715 and 755 are indicated as impacted. Id. at 10:40–41.
`
`Thus, while node 715 was initially in alarm, enterprise analysis
`in accordance with FIG. 1 allows nodes 705 and 710 to be
`identified as the true culprits behind the alarm while also
`allowing other alarms (e.g., those associated with nodes 715
`and 755) to be masked, thereby reducing or eliminating the
`effect of alarm storms in highly interconnected enterprises.
`
`Id. at 10:46–52.
`
`6
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`Claim 79, reproduced below, is illustrative of the challenged claims
`
`for the purposes of this Decision:
`
`79. A fault analysis method, wherein at least a portion of
`a system is represented by a fault model having a plurality of
`nodes, comprising:
`receiving an event notification associated with a first
`node in the fault model;
`performing an up-stream analysis of the fault model
`beginning at the first node;
`identifying a second node having a status value that was
`modified during the up-stream analysis to indicate a failed
`status;
`performing a down-stream analysis of the fault model
`beginning at the second node;
`identifying nodes in a contiguous path between the
`second node and the first node in the fault model whose impact
`values
`indicate an
`impacted performance condition
`in
`accordance with the down-stream analysis;
`indicating the second node as a root cause of the received
`event notification.
`
`
`
`B. Challenges
`
`Petitioner challenges claims 1–3, 12, 14, 21, 22, 24–26, 35, 37, 44, 45,
`
`56–58, 67, 69, 76, 77, 79, 80, 83, 85, and 88–90 as reciting patent-ineligible
`
`subject matter under 35 U.S.C. § 101. Pet. 23, 52–78.
`
`C. Related Proceedings
`
`The ’683 patent has been asserted against Petitioner in BMC Software,
`
`Inc. v. ServiceNow, Inc., Case No. 2:14-cv-903 (E.D. Tex.). Ex. 1007
`
`¶¶ 46–50; Pet. 3; Paper 5, 1.
`
`7
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`II. ANALYSIS
`
`Section 18 of the AIA1 governs the transitional program for covered
`
`business method patent reviews. A “covered business method patent” is “a
`
`patent that claims a method or corresponding apparatus for performing data
`
`processing or other operations used in the practice, administration, or
`
`management of a financial product or service, except that the term does not
`
`include patents for technological inventions.” AIA § 18(d)(1) (emphasis
`
`added); see 37 C.F.R. § 42.301(a). To determine whether a patent is eligible
`
`for a covered business method patent review, the focus is on “what the
`
`patent claims.” See Transitional Program for Covered Business Method
`
`Patents—Definitions of Covered Business Method Patent and Technological
`
`Invention, 77 Fed. Reg. 48,734, 48,736 (Aug. 14, 2012) (Final Rule). A
`
`patent need have only one claim directed to a covered business method to be
`
`eligible for review. Id.; see Versata Dev. Grp., Inc. v. SAP Am., Inc., No.
`
`2014-1194, 2015 WL 4113722, at *18 (Fed. Cir. July 9, 2015) (accepting the
`
`Board’s use of a single claim to determine whether a patent is eligible for
`
`covered business method patent review). Petitioner bears the burden of
`
`demonstrating that the ’683 patent is a covered business method patent. See
`
`37 C.F.R. § 42.304(a).
`
`Petitioner argues that the ’683 patent is a covered business method
`
`patent because “the claimed invention is directed at a technique for
`
`managing a financial product or service—in particular, diagnosing and
`
`identifying error conditions associated with a bank’s automatic teller
`
`machines (ATMs).” Pet. 4. Petitioner asserts that the claims “generally
`
`
`1 Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”).
`
`8
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`relate to a technique for identifying the ‘root cause’ of a failure and its
`
`impacts,” and that the sole embodiment in the Specification uses the claimed
`
`invention to diagnose problems with a bank’s ATMs. Id. at 5.
`
`Focusing on claim 79 as a representative claim, Petitioner explains
`
`how claim 79 covers the ATM embodiment in the Specification. Id. at 9–13.
`
`Petitioner also describes how other challenged claims cover the ATM
`
`embodiment. Id. at 13–16. According to Petitioner, “because the
`
`specification makes clear that the techniques covered by [the challenged
`
`claims] encompass management of a financial product or service, or claim
`
`activities that are incidental and complementary to a financial activity,” the
`
`’683 patent is a covered business method patent. Id. at 16 (citing
`
`Salesforce.com v. VirtualAgility, Inc., Case CBM2013-00024, slip op. at 9
`
`(PTAB Sept. 16, 2014) (Paper 47)).
`
`Patent Owner responds that Petitioner “does not identify a single
`
`claim limitation that requires, or is particular to, a ‘financial product or
`
`service.’” Prelim. Resp. 5–6. According to Patent Owner, the ’683 patent is
`
`not financial in nature, as is demonstrated by its classification in Class 714
`
`covering processes “for detecting and recovering from faults in electrical
`
`computers and digital data processing systems, as well as logic level based
`
`systems.” Id. at 6 (quoting Class Definition for Class 714,
`
`http://www.uspto.gov/web/patents/classification/uspc714/defs714.htm
`
`(Ex. 2001)). Patent Owner contends that, although the ’683 patent
`
`“discloses an embodiment with ATMs, the claimed invention is not directed
`
`to ATMs or any particular system for that matter.” Id. at 6–7.
`
`Patent Owner analogizes the ’683 patent to other cases in which the
`
`Board denied CBM review when the claims were directed to computer
`
`9
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`systems or methods of general utility. Id. at 7–9 (citing Par Pharm., Inc. v.
`
`Jazz Pharm., Inc., Case CBM2014-00149, slip op. at 9 (PTAB Jan. 13,
`
`2015) (Paper 12) (“Par Pharmaceutical”); Salesforce.com v. Applications in
`
`Internet Time LLC, Case CBM2014-00162, slip op. at 7 (PTAB Feb. 2,
`
`2015) (Paper 11) (“Internet Time”); PNC Fin. Servs. Grp., Inc. v.
`
`Intellectual Ventures I LLC, Case CBM2014-00032, slip op. at 5 (PTAB
`
`May 22, 2014) (Paper 13)).
`
`We agree with Patent Owner that Petitioner has not shown that the
`
`’683 patent claims a method or apparatus for performing data processing or
`
`other operations used in the practice, administration, or management of a
`
`financial product or service. As noted above, the statutory test for whether a
`
`patent is a covered business method patent focuses on the claims. AIA
`
`§ 18(d)(1); 37 C.F.R. § 42.301(a). Thus, we begin our analysis by
`
`considering the language of the claims of the ’683 patent. The claims recite
`
`methods or devices for fault analysis. For example, claim 79 recites a fault
`
`analysis method that uses a fault model having a plurality of nodes, and that
`
`includes steps of receiving an event notification associated with a first node,
`
`performing an up-stream analysis of the fault model, identifying a second
`
`node up-stream of the first node with a failed status, performing a down-
`
`stream analysis, identifying nodes with an impacted performance condition,
`
`and indicating the second node as a root cause of the received event
`
`notification. Ex. 1001, 17:28–45. In considering this claim, we note that
`
`none of these steps involve a financial activity. We also note that no claim
`
`limitation is tied specifically to a financial product or service. Although
`
`Petitioner explains how claim 79 encompasses the ATM embodiment
`
`described in the Specification, Petitioner does not identify any limitation of
`
`10
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`claim 79 that is specific to ATMs or any other financial product or service.
`
`We agree with Patent Owner that claim 79 is not specific to any particular
`
`type of network, but is instead a method of general applicability for fault
`
`analysis. Likewise, none of the other claims of the ’683 patent are specific
`
`to ATMs or any other finance-related product, service, or activity.
`
`Looking beyond the language of the claims themselves, the
`
`Specification also describes the invention as a technique of general utility for
`
`enterprises.2 The problem with which the ’683 patent is concerned is the
`
`diagnosis of error conditions in computing systems. Ex. 1001, 1:5–10. The
`
`patent describes this as a problem facing large and complex enterprises
`
`generally:
`
`As enterprises have become larger and more complex, their
`reliability has become ever more dependent upon the successful
`detection and management of problems that arise during their
`operation. . . . It has been observed that as an enterprise grows
`(i.e., incorporates more monitored components—hardware and
`software), the rate at which observable events occur increases
`dramatically. . . . Quickly and decisively identifying the cause
`of any given problem can be further complicated because of the
`large number of sympathetic events that may be generated . . . .
`Studies have estimated that up to 80% of a network’s down-
`time is spent analyzing event data to identify the underlying
`problem(s). This down-time represents enormous operational
`losses for organizations that rely on their enterprises to deliver
`products and services.
`
`
`2 The Specification explains that “[c]ontemporary corporate computer
`networks comprise a plurality of different computer platforms and software
`applications interconnected through a number of different paths and various
`hardware devices such as routers, gateways and switches, workstations,
`dedicated file, application and mail servers and mainframe computer
`systems.” Ex. 1001, 1:11–16. “The collection of such entities—hardware
`and software—is often referred to as an ‘enterprise.’” Id. at 1:18–20.
`
`11
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`Id. at 1:21–52.
`
`The first half of the Detailed Description provides a step-by-step
`
`discussion of the method, including a description of the flow charts in
`
`Figures 2 and 3, which illustrate the up-stream and down-stream analysis.
`
`See id. at 3:34–7:30, Figs. 1–3.
`
`Next, the Detailed Description applies the method to an exemplary
`
`enterprise of ATMs coupled to a bank. See id. at 7:31–10:52, Figs. 4–7.
`
`The Specification repeatedly emphasizes that the ATM enterprise of Figures
`
`4–7 is simply an illustration of how the method of Figure 1 is applied. See
`
`id. at 9:7–10 (“For the purpose of illustrating how enterprise fault
`
`monitoring and analysis in accordance with FIG. 1 may be applied to the
`
`illustrative enterprise represented by Impact Graph 700, consider an alarm
`
`event associated with ATM A1 NO_MONEY condition node 715”); id. at
`
`11:11–14 (“[T]he enterprise illustrated in FIGS. 4–7 was introduced merely
`
`for explanatory purposes and is not intended to limit, in any way, the
`
`generality of the method of FIG. 1.”); id. at 7:31–34 (“By way of example,
`
`consider an enterprise consisting of a plurality of Automatic Teller Machines
`
`(ATMs) that are coupled to a central banking facility via a satellite
`
`communications system[].”); id. at 11:41–46 (“the invention has been
`
`disclosed with respect to a limited number of embodiments”).
`
`As a further indication of the invention’s general utility, the
`
`Specification also discloses that the technique has applications outside of
`
`computer networks:
`
`For example, a mechanical system comprising pumps, valves
`and motors may benefit from the claimed fault analysis method.
`One of ordinary skill in the art will recognize that if a “system”
`comprises at least some components that are monitored and
`these monitored components communicate (in any desired
`
`12
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`fashion) to a module that performs the analysis, such a system
`can benefit from the claimed invention.
`
`Id. at 11:33–40.
`
`Notably, the Specification does not attribute any significance to the
`
`choice of an ATM network as the illustrative enterprise. For example, the
`
`Specification does not suggest that the method is particularly suited to ATM
`
`networks, or that ATM networks are more vulnerable to the problem with
`
`which the invention is concerned. Petitioner does not point to, and we do
`
`not find, any indication in the Specification that the invention has particular
`
`usefulness in financial products, services, or activities. Rather, as outlined
`
`above, the description in the Specification indicates that the invention is a
`
`technique of general utility for quickly diagnosing problems in complex
`
`enterprises.
`
`The Board previously has denied institution of covered business
`
`method patent review for patents claiming methods of general utility,
`
`notwithstanding the presence of some exemplary disclosure in the
`
`Specification of finance-related activity. For example, in Par
`
`Pharmaceutical, the patent claimed a method of distributing a prescription
`
`drug. Slip op. at 10. The specification included figures showing steps of
`
`verifying insurance coverage and ability to pay, but the petition did not show
`
`“why the claimed method steps recite or require verifying insurance
`
`coverage or a patient’s ability to pay.” Id. at 13. After determining that
`
`“[t]he claimed method . . . has no particular relation to the financial services
`
`industry and does not relate to just a financial product or service rather than
`
`to an enterprise, i.e., a conventional business organization,” the Board
`
`concluded that the patent was not a CBM patent under AIA § 18(d)(1). Id.
`
`13
`
`at 19–20.
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`The patent in Internet Time was directed to a system for managing
`
`changes in regulatory and non-regulatory requirements for business
`
`activities. Slip op. at 3. The Board determined that “the claims on their face
`
`are directed to technology ‘common in business environments across
`
`sectors’ with ‘no particular relation to the financial services sector,’ which
`
`the legislative history [of AIA § 18(d)(1)] indicates is outside the scope of
`
`covered business method patent review.” Id. at 9 (quoting 157 Cong. Rec.
`
`S5441 (daily ed. Sept. 8, 2011) (statement of Sen. Leahy)). The Board noted
`
`that, although the written description included references to financial
`
`activities, these passages were merely exemplary of uses that could benefit
`
`from the invention, and the petitioner had not demonstrated a relationship
`
`between the references to finance in the written description and the claimed
`
`system. Id. at 9–10.
`
`In Google Inc. v. SimpleAir, Inc., the Board concluded that a patent
`
`claiming a system for transmitting “data” was not shown to be a CBM
`
`patent, despite disclosure in the specification that data feeds could include
`
`stock quotes, because the claim recited only generic, context-neutral “data,”
`
`without any language relating to a financial product or service. Case
`
`CBM2015-00019, slip op. at 11–12 (PTAB May 19, 2015) (Paper 11). See
`
`also FedEx Corp. v. Ronald A. Katz Tech. Licensing, L.P., Case CBM2015-
`
`00053, slip op. at 9–11 (PTAB June 29, 2015) (Paper 9) (claims on their face
`
`were directed to technology common in business environments across
`
`sectors and disclosure from specification relating to use of system to
`
`automate mail-order operation was insufficient to show that any claim was
`
`directed to an activity that is financial in nature).
`
`14
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`
`We recognize that the description of the exemplary ATM embodiment
`
`in the ’683 patent is more extensive than the finance-related disclosures in
`
`these earlier decisions, making this a closer case for CBM eligibility. Yet,
`
`ultimately, the focus of the analysis must remain on the claims. Here, the
`
`absence of any finance-related limitation in the claims is the primary driver
`
`of our determination that the ’683 patent is not a covered business method
`
`patent under AIA § 18(d)(1). Additionally weighing in favor of that
`
`determination is the overarching message of the Specification that the
`
`technique is one of general applicability, with no particular applicability to
`
`financial products or services. As detailed above, the Specification
`
`describes the problem being solved as one of general utility for diagnosing
`
`errors in enterprises, and provides a lengthy description of the overall
`
`method before turning to an exemplary ATM network. The Specification
`
`repeatedly states that the ATM network of Figures 4–7 is offered as an
`
`example to illustrate how the method of Figure 1 may be applied, and does
`
`not suggest that the invention is particularly suited to ATM networks or any
`
`other financial product or service. Against this backdrop, Petitioner’s
`
`reliance on the Specification’s exemplary ATM embodiment does not
`
`persuade us that the patent claims a method used in the practice,
`
`administration, or management of a financial product or service.
`
`III. CONCLUSION
`
`For the foregoing reasons, based on the present record and particular
`
`facts of this proceeding, we determine that the information presented in the
`
`Petition does not establish that the ’683 patent qualifies as a “covered
`
`business method patent” under § 18(d)(1) of the AIA. Therefore, we do not
`
`15
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`institute a covered business method patent review as to any of the challenged
`
`claims.
`
`In consideration of the foregoing, it is hereby:
`
`IV. ORDER
`
`ORDERED that the Petition is denied as to all challenged claims of
`
`the ’683 patent.
`
`
`
`16
`
`
`
`
`
`

`
`CBM2015-00107
`Patent 7,062,683 B2
`
`PETITIONER:
`
`Heidi L. Keefe
`Phillip E. Morton
`Andrew C. Mace
`Mark Weinstein
`COOLEY LLP
`hkeefe@cooley.com
`pmorton@cooley.com
`amace@cooley.com
`zpatdcdocketing@cooley.com
`mweinstein@cooley.com
`
`
`
`PATENT OWNER:
`
`Robert A. Cote
`Pierre Hubert
`Robert Auchter
`Kevin Schubert
`McKOOL SMITH, P.C.
`rcote@mckoolsmith.com
`phubert@mckoolsmith.com
`rauchter@mckoolsmith.com
`kschubert@mckoolsmith.com
`
`
`17