Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`ServiceNow, Inc.
`Petitioner
`
`v.
`
`BMC Software, Inc.
`Patent Owner
`
`U.S. Patent No. 7,062,683
`Filing Date: April 22, 2003
`Issue Date: June 13, 2006
`
`TITLE: TWO-PHASE ROOT CAUSE ANALYSIS
`
`DECLARATION OF ARTHUR T. BRODY, PH.D.
`
`Covered Business Method Review No. 2015-__
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`001
`
`

`
`Table of Contents
`
`Page
`
`I.
`II.
`
`III.
`IV.
`
`V.
`
`BRIEF SUMMARY OF MY OPINIONS .............................................................1
`INTRODUCTION AND QUALIFICATIONS........................................................2
`A.
`Qualifications and Experience............................................................2
`B.
`Materials Considered.........................................................................3
`PERSON OF ORDINARY SKILL IN THE ART .....................................................4
`STATE OF THE ART AT THE TIME OF THE ALLEGED INVENTION....................6
`A.
`Cause-and-Effect Relationships and Problem Solving ........................6
`B.
`Root Cause Analysis Using Cause-and-Effect Models.........................7
`C.
`“Upstream Analysis” and “Downstream Analysis” .............................9
`THE ’683 PATENT’S TECHNIQUE FOR FAULT ANALYSIS ..............................16
`A.
`The Specification of the ’683 Patent ................................................16
`1.
`Understanding the “Fault Model” of the ’683 Patent ............16
`2.
`The “Two-Phase” Root Cause Analysis in the ’683 Patent......21
`The Claims of the ’683 Patent ..........................................................23
`Claim Construction ..........................................................................27
`1.
`“enterprise”...........................................................................28
`2.
`“fault model” .........................................................................30
`3.
`“node” ...................................................................................31
`4.
`“up-stream analysis”..............................................................32
`5.
`“down-stream analysis”.........................................................32
`6.
`“status value” ........................................................................33
`7.
`“impact value” .......................................................................33
`8.
`“inference policy/policies”.....................................................34
`9.
`“impact policy” ......................................................................35
`10.
`“Impact Graph”......................................................................36
`
`B.
`C.
`
`-i-
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`002
`
`

`
`Table of Contents
`(continued)
`
`Page
`
`VI.
`
`VII.
`
`OPINIONS REGARDING PATENT-ELIGIBLE SUBJECT MATTER......................36
`A.
`Are the Claims Directed to an Abstract Idea?...................................38
`1.
`Claim 1...................................................................................38
`2.
`Claim 2...................................................................................45
`3.
`Claim 3...................................................................................45
`4.
`Claim 12.................................................................................46
`5.
`Claim 14.................................................................................47
`6.
`Claim 21.................................................................................48
`7.
`Claim 22.................................................................................48
`8.
`Claims 24-26, 35, 37, 44, and 45 ............................................49
`9.
`Claims 56-58, 67, 69, 76, and 77 ............................................53
`10.
`Claims 79, 80, 83, 85, 88, and 89............................................53
`11.
`Claim 90.................................................................................54
`Do the Claims Provide Meaningful Limitations?...............................55
`B.
`CONCLUSION .............................................................................................57
`
`-ii-
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`003
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`I, Arthur T. Brody, Ph.D., declare as follows:
`
`1.
`
`I have personal knowledge of the facts stated in this Declaration, and
`
`could and would testify to these facts under oath if called upon to do so.
`
`2.
`
`I have been retained by counsel for ServiceNow, Inc. (Petitioner) in
`
`this case as an expert in the relevant art.
`
`3.
`
`I have been asked to provide my opinions relating to claims 1, 2, 3,
`
`12, 14, 21, 22, 24, 25, 26, 35, 37, 44, 45, 56, 57, 58, 67, 69, 76, 77, 79, 80, 83, 85,
`
`88, 89, and 90 of U.S. Patent No. 7,062,683 to Michael R. Warpenburg, et al. (“the
`
`’683 patent”), which I understand is owned by BMC Software, Inc. (“Patent
`
`Owner” or “BMC”).
`
`I.
`
`BRIEF SUMMARY OF MY OPINIONS
`
`4.
`
`Claims 1, 2, 3, 12, 14, 21, 22, 24, 25, 26, 35, 37, 44, 45, 56, 57, 58, 67,
`
`69, 76, 77, 79, 80, 83, 85, 88, 89, and 90 of the ’683 patent purport to disclose a
`
`method of root cause analysis. They do not describe anything that was new or
`
`non-obvious by the time the application for the ’683 patent was filed in April
`
`2003. As explained in detail in Part VI, claims 1, 2, 3, 12, 14, 21, 22, 24, 25, 26, 35,
`
`37, 44, 45, 56, 57, 58, 67, 69, 76, 77, 79, 80, 83, 85, 88, 89, and 90 of the ’683
`
`patent are directed to an abstract idea and fail to provide meaningful additional
`
`1
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`004
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`elements that transform them into something more than the abstract idea itself.
`
`II.
`
`INTRODUCTION AND QUALIFICATIONS
`
`A.
`
`5.
`
`Qualifications and Experience
`
`I possess the knowledge, skills, experience,
`
`training and the
`
`education to form an expert opinion and testimony in this case.
`
`6.
`
`I have more than thirty (30) years of experience in the networking
`
`and telecommunications
`
`industries.
`
`This experience includes network
`
`engineering, operations
`
`support
`
`systems,
`
`call
`
`center
`
`systems, workflow
`
`automation and other engineering and technical functions. Additional details of
`
`my background are set forth in my curriculum vitae, attached as Exhibit A to this
`
`Declaration, which provides a more complete description of my educational
`
`background and work experience. Starting at Bell Laboratories, continuing at
`
`Technicom Systems and in my consulting practice at A. T. Brody & Associates, Inc.,
`
`I have worked on workflow automation projects.
`
`These projects included
`
`automation of sectionalization and isolation of problems on special service
`
`circuits, automation of trouble ticket processing and problem analysis on
`
`customer loops, workflow automation within service provider call centers with
`
`respect to provisioning and repair including the scheduling of dispatch (i.e., truck
`
`2
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`005
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`rolls), and the automation of workflows for provisioning, maintenance and repair
`
`of service provider central office equipment.
`
`7.
`
`Additional details of my background are set forth in my curriculum
`
`vitae, attached as Exhibit A to this Declaration, which provides a more complete
`
`description of my educational background and work experience.
`
`I am being
`
`compensated for the time I have spent on this matter. My compensation does
`
`not depend in any way upon the outcome of this proceeding. I hold no interest in
`
`the Petitioner (ServiceNow, Inc.) or the Patent Owner (BMC Software, Inc.).
`
`B. Materials Considered
`
`8.
`
`The analysis that I provide in this Declaration is based on my
`
`education and experience in the field of computer systems, as well as the
`
`documents I have considered including the ’683 patent (Ex. 1001) which states on
`
`its face that it issued from an application filed on April 22, 2003.
`
`I reviewed
`
`various documents describing the state of the art at the time of the alleged
`
`invention of the ’683 patent. This Declaration cites the following documents for
`
`purposes of describing the relevant technology, including the relevant state of the
`
`art at the time of the alleged invention of the ’683 patent:
`
`3
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`006
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`Exhibit No.
`1003
`1004
`
`1005
`
`1006
`
`Description of Document
`Excerpts from Dean L. Gano, Apollo Root Cause Analysis (1999)
`Jane T. Malin et al., Making Intelligent Systems Team Players:
`Additional Case Studies, NASA Technical Memo. 104786 (1993)
`Ginger L. Pack, Failure Environment Analysis Tool Applications
`(1992)
`Excerpts from Paula Martin et al., Getting Started in Project
`Management (2001)
`
`III.
`
`PERSON OF ORDINARY SKILL IN THE ART
`
`9.
`
`I understand that an assessment of claims of the ’683 patent should
`
`be undertaken from the perspective of a person of ordinary skill in the art as of
`
`the earliest claimed priority date, which I understand is April 2003.
`
`10.
`
`In ascertaining the level of ordinary skill in the art for purposes of the
`
`’683 patent, it is important to note that the claims addressed in this Declaration
`
`generally fall into two categories. The first category of claims recite a fault-
`
`analysis method that does not appear to require the use of a computer or any
`
`other technology. These claims include claims 1-3, 12, 14, 21, 22, 56, 57, 58, 67,
`
`69, 76, 77, 79, 80, 83, 85, 88 and 89, and their steps could be carried out by a
`
`human being using pen and paper. One of ordinary skill in the art for purposes of
`
`these claims, as of April 2003, would not have required education or experience in
`
`computers. A person of ordinary skill in the art for purposes of these claims could
`4
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`007
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`have possessed a bachelor’s degree in any one of a wide variety of fields requiring
`
`analytic ability including physics, mathematics, engineering, economics, statistics,
`
`or simply had equivalent experience in a field involving analytical thinking and
`
`problem-solving.
`
`11.
`
`The other claims addressed in this Declaration recite a “program
`
`storage device” comprising instructions executed by “programmable control
`
`device,” to carry out the same steps as the method claims. These include claims
`
`24, 25, 26, 35, 37, 44, 45 and 90. As I will explain in Part VI.B below, however,
`
`these claims do not require anything beyond use of generic computer technology
`
`and equipment. For purposes of these claims, therefore, a person of ordinary skill
`
`in the art as of April 2003 would have possessed at least a bachelor’s degree in
`
`electrical engineering or computer science (or equivalent degree or experience)
`
`with at least two years of computer programming experience.
`
`12. My opinions regarding the level of ordinary skill in the art are based
`
`on, among other things, my experience in the field as described in Part I above,
`
`and my understanding of the basic qualifications that would be relevant to
`
`investigate the methods and systems in the relevant area, and my familiarity with
`
`the backgrounds of colleagues and co-workers, both past and present.
`
`5
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`008
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`13.
`
`Although my qualifications and experience exceed those of the
`
`hypothetical person having ordinary skill in the art defined above, my analysis and
`
`opinions regarding the ’683 patent have been based on the perspective of a
`
`person of ordinary skill in the art as of April 2003.
`
`IV.
`
`STATE OF THE ART AT THE TIME OF THE ALLEGED INVENTION
`
`14.
`
`The ’683 patent generally discloses methods and systems for using a
`
`fault diagnosis model to determine a “root case” of a problem and identify the
`
`impacts of that problem. In this section, I provide a brief background of the state
`
`of fault diagnosis methods prior to April 2003 pertinent to the ’683 patent.
`
`A.
`
`15.
`
`Cause-and-Effect Relationships and Problem Solving
`
`The term “root cause analysis” generally refers to an analytical
`
`process of determining the cause of a particular problem or failure. The basic
`
`ideas behind “root cause analysis” likely date back to the earliest days in which
`
`human beings were capable of understanding cause-and-effect relationships, one
`
`of the basic components of rational thinking and problem-solving. As early as 350
`
`B.C.E., ancient Grecian philosopher Aristotle developed his own theories of cause
`
`and effect. (See, Aristotle, Physics II, 3; see also, Aristotle, Metaphysics V, 2.) The
`
`basic components of root cause analysis were likely critical to early human
`
`6
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`009
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`problem-solving, thought, and reasoning.
`
`16.
`
`Given that cause-and-effect analysis is a fundamental aspect of
`
`human cognition and problem-solving, it is no surprise that the examination of
`
`cause-and-effect relationships has continued since the days of Aristotle and has
`
`since extended to the fields of science and mathematics. As I explain in more
`
`detail below, researchers have developed various analytical tools to study cause-
`
`and-effect
`
`relationships,
`
`including
`
`tools
`
`for modeling
`
`cause-and-effect
`
`relationships for particular applications.
`
`B.
`
`17.
`
`Root Cause Analysis Using Cause-and-Effect Models
`
`By the time the application of the ’683 patent had been filed, a large
`
`volume of literature had been devoted to creating models of cause-and-effect
`
`relationships, and then using those models to ascertain the cause of a particular
`
`failure. One of the well-known ways of modeling cause-and-effect relationships
`
`was through an abstract representation identifying a series of connected cause-
`
`and-effect relationships. The ’683 patent refers to this abstraction as a “fault
`
`model,” which is typically represented as a “directed graph” or a “digraph.” (’683,
`
`Ex. 1001, 3:59-62.) An example of a rudimentary cause-and-effect graph is
`
`provided in Dean L. Gano, Apollo Root Cause Analysis (1999) [Ex. 1003]:
`
`7
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`010
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`(Gano, Ex. 1003, at 39 (Fig. 2.2).)
`
`18.
`
`The model shown in Figure 2.2 in Gano above includes a series of
`
`circled nodes. Each node has two characteristics relevant to our discussion here:
`
`(1) each node represents a particular status or condition, and (2) each node may
`
`be linked to another node with which the status has a cause-and-effect
`
`relationship (represented in Figure 2.2 as the lines between the nodes labeled
`
`“CB” for “Caused By”).
`
`For example, the node on the far left of the graph
`
`represents a status or condition of “Injury,” which is caused by another node to
`
`the right representing a “Fall” status or condition. The “Fall” status node, in turn,
`
`is caused by a “Wet Surface” node, and so forth. (Id.)
`
`19.
`
`The cause-and-effect diagram in Figure 2.2, although extremely
`
`rudimentary, is useful for illustrating how such a model can be used to determine
`
`the cause of a particular failure. For example, if it is determined that the “Injury”
`
`node has a condition of “TRUE,” we can move in a contiguous path through the
`
`nodes in the model to determine the cause of the injury. For example, by moving
`
`8
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`011
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`through the nodes, we may find a failure status for “Injury,” “Fall,” “Wet
`
`Surface,” but not for “Leaky Valve” or any other node. This scenario is illustrated
`
`by the following version of Figure 2.2 from Gano, which I have annotated:
`
`(Gano, Ex. 1003, at 39 (Fig. 2.2) (colored annotations added).)
`
`In the example
`
`above, we can identify “Wet Surface” as the “root cause” of the “Injury” status or
`
`condition in the model. This is because “Wet Surface” is the furthest node in the
`
`path that reports a failure (“TRUE”) condition. As shown by the model above,
`
`once it is determined that the “Leaky Valve” is “FALSE,” there is no need to check
`
`the two further nodes in the causal chain (i.e., “Seal Failure,” “Not Maintained”).
`
`C.
`
`20.
`
`“Upstream Analysis” and “Downstream Analysis”
`
`Cause-and-effect models, in practice, tend to be far more complex
`
`than the rudimentary example from Gano provided above. For example, Jane T.
`
`Malin et al., Making Intelligent Systems Team Players: Additional Case Studies,
`
`NASA Technical Memorandum 104786 (1993) [Ex. 1004], describes use of fault
`
`9
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`012
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`models that can be used by ground flight controllers at NASA. (Malin, Ex. 1004, at
`
`p. 4-1 (§ 4.1).) Malin provides a brief background of fault modeling systems using
`
`the example of the following light bulb circuit to illustrate how fault models work:
`
`(Malin, Ex. 1004, at p. 4-2 (top half of Fig. 4-1).)
`
`21.
`
`As shown above, the light bulb circuit includes two power sources
`
`(“Power Source A” and “Power Source B”) and corresponding switches (“Switch
`
`A” and “Switch B”), as well as two ground connections. Malin provides a fault
`
`digraph in order to identify the possible reasons why the light bulb might fail to
`
`illuminate:
`
`10
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`013
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`(Malin, Ex. 1004, at p. 4-2 (bottom half of Fig. 4-1).)
`
`22.
`
`Although the digraph above has 13 nodes and is more complex than
`
`the one from Gano shown above, it is still comparatively rudimentary. As Malin
`
`explains, “[f]or complex space systems, failure digraphs are considerably more
`
`complex than the digraph in this example, often containing hundreds of nodes.”
`
`(Id. at p. 4-1.) The nodes in the digraph above represent “failure sources (circles)
`
`[that] are connected by edges (arrows) indicating causal relationships (arrows
`
`point from cause to effect).” (Id. at p. 4-1, § 4.2.) Those nodes illustrate the
`
`possible causes of the light bulb failing to illuminate. “Failure of the bulb to light
`
`can be caused by (1) a bad bulb, (2) a bad switch, or (3) a power problem (ground
`
`11
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`014
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`or power source failure).” (Id. at p. 4-1.) Malin explains that a node in a digraph
`
`can be “upstream” and/or “downstream” from another node.
`
`23. Upstream Nodes: The “upstream node” concept is straightforward.
`
`Using the exemplary digraph from Malin shown in Figure
`
`4-1 above, which I have excerpted in part at the right, we
`
`see the node for “Light Fails” is surrounded by three
`
`causally connected nodes that point to it – “Bulb Failure,”
`
`“Power at Light Fails,” and “Light Ground Failure.”
`
`Because each of these has an arrow “coming into” the
`
`“Light Fails” node, these nodes are considered “upstream” from the “Light Fails”
`
`node. (Id., footnote 20 (“Similarly, nodes upstream from Node A are connected to
`
`paths coming into Node A (i.e., to the left of Node A).”) (italics in original).)
`
`24.
`
`Downstream Nodes: A “downstream” node, as its name indicates, is
`
`the reverse of an “upstream” node – it is a node in a digraph that is “pointed to”
`
`by an upstream node.
`
`(Id. (“Nodes downstream from Node A are nodes
`
`connected to paths coming out of Node A . . . .”) (italics in original).) Using the
`
`excerpt of Figure 4-1 above, the “Light Fails” node is “downstream” from the
`
`three surrounding nodes.
`
`Each “downstream” node represents a potential
`
`12
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`015
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`“effect” of its “upstream” node. The downstream node “Light Fails” in Figure 4-1,
`
`for example, is a possible “effect” of “Power at Light Fails,” one of its upstream
`
`nodes.
`
`Although my simplified example above describes “upstream” and
`
`“downstream” nodes in relationship to the single terminal “Light Fails” node, the
`
`“upstream” and “downstream” concept extends to all portions of the digraph.
`
`Further up the causal chain (moving to the left) in Figure 4-1, for example, reveals
`
`other nodes that are “upstream” and “downstream” from each other.
`
`25. Malin describes two processes that can be performed using a failure
`
`model or digraph: (1) “upstream analysis” to identify the “root cause” of a
`
`particular failure; and (2) “downstream analysis” to identify the nodes that are
`
`impacted or affected by that failure. (Id. at 4-1 (§ 4.2) (“ERF performs two types
`
`of functions, identification of the root cause of a failure and prediction of the
`
`consequences (or impacts) of a failure.”); id. at 4-8 (first and second bullet points
`
`describing “downstream analysis” and “upstream analysis,” respectively).)
`
`26. Upstream analysis, as its name implies, involves starting from a node
`
`indicating a failed status and moving upstream through the nodes in the fault
`
`model or digraph until the system encounters a node that does not indicate a
`
`failed status. (Id. at p. 4-8.) An “upstream analysis” can be seen using Figure 4-1
`
`13
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`016
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`below, which I have simplified and annotated for more clearly illustrating how an
`
`upstream analysis may take place:
`
`(Malin, Ex. 1004, at p. 4-2 (Fig. 4-1) (modified figure; color annotations added).)
`
`27.
`
`In the example above, I have removed from Figure 4-1 the nodes
`
`relating to “Power Source A” and “Switch A” in order to focus and simplify the
`
`discussion of upstream analysis. Malin provides the following description of
`
`upstream analysis: “Mark a target node as failed and identify all node failures
`
`that could have caused the target node to fail (called an upstream analysis, or
`
`14
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`017
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`target propagation).” (Id. at p. 4-8 (emphasis added).) As applied here, we start
`
`at the “Light Fails” node that I have marked as failed (i.e., “TRUE”), and move
`
`upstream until the root cause is located – in this case, a node indicating “Switch B
`
`Fails Open,” which means that the switch is in the off (“open”) position.
`
`28.
`
`A similar analysis, but in the other direction, is called “downstream
`
`analysis.” The purpose of “downstream analysis” is not to identify the cause of a
`
`failure, but its impacts or effects. This analysis starts with a failed node and then
`
`moves through the “downstream” nodes to identify those that are affected by the
`
`failure. (Id. at p. 4-8 (“Mark a specific node (called the source node) as failed and
`
`propagate the failure through the digraph to examine the effects of failing this
`
`node (called a downstream analysis, or source propagation).”) (emphasis added).)
`
`“A failure,” as explained by Malin, “impacts all nodes directly in the downstream
`
`path.” (Id. at p. 4-3.) Using the example above, if the “Switch B Fails Open” node
`
`has a status of “TRUE,” its impacts include the three nodes downstream from it –
`
`“Switch B Output Fails,” “Power at Light Fails,” and “Light Fails.” (Id.)
`
`29.
`
`The fault analysis methods discussed above could be customized to
`
`the particular enterprise and could be made more detailed or simplified
`
`depending on the specific enterprise or desires of the person using the fault
`
`15
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`018
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`analysis method.
`
`Accordingly, root cause and impact analyses,
`
`including
`
`upstream and downstream analyses, were not an invention of the ’683 patent.
`
`V.
`
`THE ’683 PATENT’S TECHNIQUE FOR FAULT ANALYSIS
`
`A.
`
`30.
`
`The Specification of the ’683 Patent
`
`The patent describes a two-phase method of utilizing a fault model
`
`to identify the root cause of a problem and its impacts. (’683, Ex. 1001, Abstract.)
`
`The embodiment described in the specification involves diagnosing error
`
`conditions for devices in a computer network, such as Automatic Teller Machines
`
`(ATMs) that are coupled to a central banking system over a network.
`
`(’683, Ex.
`
`1001, 7:31-34.)
`
`The specification makes clear, however, that the alleged
`
`invention is not limited to computer-based systems or networks. (’683, Ex. 1001,
`
`11:32-41.)
`
`“For example, a mechanical system comprising pumps, valves and
`
`motors may benefit from the claimed fault analysis method.” (’683, Ex. 1001
`
`11:33-35.)
`
`1.
`
`Understanding the “Fault Model” of the ’683 Patent
`
`31.
`
`In order to understand the alleged invention of the ’683 patent, it is
`
`important to understand the concept of a “fault model.” (’683, Ex. 1001, 3:59-
`
`67.) As I explained above, the term “fault model” generally refers to a description
`
`16
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`019
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`of the cause-and-effect relationships of a particular component that is being
`
`monitored.
`
`(Id.) Figure 6A provides an exemplary “fault model” describing the
`
`various cause-and-effect relationships affecting the operation of an automatic
`
`teller machine (ATM) device:
`
`(’683, Ex. 1001, Fig. 6A.)
`
`32.
`
`Each box in the fault model (600) in Figure 6A above is called a
`
`“node.” These “nodes” are not the same thing as a computing device on a
`
`network.
`
`Each “node” instead represents an abstract concept—a particular
`
`condition or state associated with the component being monitored, in this case
`
`an automatic teller machine (ATM). Node 640 on the bottom of Figure 6A (“ATM
`
`PAPER_JAM”), for example, represents a condition in which the ATM has a paper
`
`17
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`020
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`jam. Node 635 above it (“ATM NO_MONEY”) represents the condition in which
`
`the ATM has run out of money. (’683,Ex. 1001, 8:36-39.)
`
`33.
`
`The connections between the nodes
`
`in the fault model, as shown by the connecting
`
`arrows, represent cause-and-effect impacts. For
`
`example, as shown in the excerpt of Figure 6
`
`shown at the right, the ATM NO_MONEY (635) and ATM PAPER_JAM (640) nodes
`
`are both pointing to the ATM SRVC DEGRADED (625) node, which represents the
`
`condition in which the ATM service has been degraded. As indicated by the
`
`arrows, the “ATM SRVC DEGRADED” (625) node is “downstream” from the “ATM
`
`NO_MONEY” (635) and “ATM PAPER_JAM” (640) nodes. This means that the
`
`condition of having no money left in the ATM, and/or having a paper jam in the
`
`ATM, might influence whether the ATM also exhibits the service degraded (ATM
`
`SRVC DEGRADED) condition.
`
`34.
`
`The specification further explains that each node in the fault model
`
`can implement two policies to determine the current condition of the node: (1) an
`
`“inference policy” and (2) an “impact policy.” As I explain in more detail below,
`
`these two policies are used in performing upstream and downstream analysis,
`
`18
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`021
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`respectively, of a fault model.
`
`35.
`
`The “inference policy” of a node is “a
`
`rule, or set of rules, for inferring the status or
`
`condition of a fault model node based on the
`
`status or condition of the node’s immediately
`
`down-stream neighboring nodes . . . .” (’683, Ex. 1001, 4:12-15.) For example,
`
`again referring to the example in Figure 6A, the inference policy of the “ATM
`
`NO_MONEY” (635) node can infer its status based on the status of the
`
`downstream “ATM SRVC DEGRADED” (625) node.
`
`36.
`
`An “impact policy” is conceptually similar to an “inference policy,”
`
`but it works in the opposite direction. An impact policy “is a rule, or set of rules,
`
`for assessing the impact on a fault model node based on the status or condition of
`
`the node’s immediately up-stream neighboring nodes. . . .” (’683, Ex. 1001, 4:17-
`
`20.) Using the Figure 6A above, the specification describes an impact policy for
`
`the “ATM SRVC DEGRADED” (625) node that ascertains the node’s status based
`
`on the status of its immediate upstream neighboring nodes:
`
`Service DEGRADED condition node 625 will yield a true value,
`indicating an ATM service degraded condition, if 30% or more of the
`immediately up-stream ATM nodes have a status of DOWN, or 50%
`19
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`022
`
`

`
`Declaration of Arthur T. Brody, Ph.D. in Support of
`Petition for Covered Business Method Review of
`U.S. Patent No. 7,062,683
`
`or more of the immediately up-stream ATM nodes’ NO_MONEY
`impact values are true, or 50% or more of the immediately up-stream
`ATM nodes’ PAPER_JAM impact values are true.
`
`(’683, Ex. 1001, 8:27-33.)
`
`37.
`
`The inference and impact policies can be used to generate,
`
`respectively, a “status value” or “impact value.” The status and impact values
`
`can be as simple as a Boolean value (e.g., “failed” or “not failed” condition), or a
`
`more complex floating point (decimal) number.
`
`(’683, Ex. 1001, 4:22-30
`
`(“Typically, nodes in a fault model . . . utilize a status value (e.g., a Boolean value
`
`to indicate whether a node is failed or not-failed, or a real number such as 0.0 to
`
`1.0) to record a node’s status or condition and an impact value (e.g., a Boolean
`
`value to indicate whether a node is impacted or not-impacted by its up-stream
`
`neighbors, or a real number such as 0.0 to 1.0) to record the node’s impact
`
`value.”) (emphasis added); 5:13-16 (“In one embodiment, status values are
`
`restricted to the Boolean values of FAILURE and NO-FAILURE and impact values
`
`are restricted to the Boolean values of IMPACTED and NOT-IMPACTED.”).) Having
`
`explained the basic concepts of a “fault model” as described in the ’683 patent, I
`
`will now explain how the patent describes the claimed root cause analysis.
`
`20
`
`ServiceNow, Inc.'s Exhibit No. 1002
`
`023
`
`

`
`
`Declaration of Arthur T. Brody, Ph.D. inDeclaration of Arthur T. Brody, Ph.D. in Support of
`
`Petition for Covered Business MethodCovered Business Method Review of
`U.S. Patent No. 7,062,683
`
`2.
`
`
`
`
`
`The “TwoThe “Two-Phase” Root Cause Analysis in the ’683 Patent’683 Patent
`
`38.
`
`
`
`Figure 1 (at right)(at right) illustrates the basic
`
`
`
`process of the two-phase root causeroot cause analysis recited
`
`
`
`in the claims. The process begins with the receipt ofin the claims. The process begins with the receipt of
`
`
`
`an event notification (stepan event notification (step 105) by a particular node
`
`
`
`in the fault model (or Impact Graph)in the fault model (or Impact Graph). (’683, Ex. 1001,
`
`
`
`4:40-43.) The method then performs43.) The method then performs the first phase
`
`
`
`of the analysis, known as “upup-stream analysis” (step
`
`
`
`110). (’683, Ex. 1001, 4:42--46.) As its name implies,
`
`
`
`“up-stream analysis” travels up thestream analysis” travels up the nodes of the fault
`
`
`
`
`
`model until it locates what is believed to bewhat is believed to be a “root cause” of the fault has beenof the fault has been
`
`
`
`detected. As explained in the specification:detected. As explained in the specification:
`
`
`
`Generally speaking, upup-stream analysis of an Impact Graph begins atstream analysis of an Impact Graph begins at
`
`
`