ServiceNow, Inc.v.BMC Software, Inc.

Patent Trial and Appeal Board

Sep 11, 2015

10420174 (P.T.A.B. Sep. 11, 2015)

Trials@uspto.gov Paper No. 12
571-272-7822 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

2
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
CBM2015-00107
Patent 7,062,683 B2

3
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.
CBM2015-00107
Patent 7,062,683 B2

4
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.
CBM2015-00107
Patent 7,062,683 B2

5
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
CBM2015-00107
Patent 7,062,683 B2

6
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.
CBM2015-00107
Patent 7,062,683 B2

7
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.
CBM2015-00107
Patent 7,062,683 B2

8
II. ANALYSIS
Section 18 of the AIA
1
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”).
CBM2015-00107
Patent 7,062,683 B2

9
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
CBM2015-00107
Patent 7,062,683 B2

10
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
CBM2015-00107
Patent 7,062,683 B2

11
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.
CBM2015-00107
Patent 7,062,683 B2

12
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
CBM2015-00107
Patent 7,062,683 B2

13
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.
at 19–20.
CBM2015-00107
Patent 7,062,683 B2

14
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).
CBM2015-00107
Patent 7,062,683 B2

15
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
CBM2015-00107
Patent 7,062,683 B2

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

CBM2015-00107
Patent 7,062,683 B2

17
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