Trials@uspto.gov
`571-272-7822
`
`
`
`Paper 10
`Entered: January 26, 2016
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SERVICENOW, INC.,
`Petitioner,
`
`v.
`
`BMC SOFTWARE, INC.,
`Patent Owner.
`____________
`
`Case IPR2015-01601
`Patent 6,816,898 B1
`____________
`
`Before JUSTIN T. ARBES, BRIAN P. MURPHY, and
`JOHN A. HUDALLA, Administrative Patent Judges.
`
`ARBES, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`Petitioner ServiceNow, Inc. filed a Petition (Paper 1, “Pet.”)
`requesting inter partes review of claims 1–12 of U.S. Patent No. 6,816,898
`B1 (Ex. 1001, “the ’898 patent”) pursuant to 35 U.S.C. § 311(a). Patent
`Owner BMC Software, Inc. filed a Preliminary Response (Paper 9, “Prelim.
`Resp.”) pursuant to 35 U.S.C. § 313. We have jurisdiction under 35 U.S.C.
`§ 314 and 37 C.F.R. § 42.4(a). Pursuant to 35 U.S.C. § 314(a), the Director
`may not authorize an inter partes review unless the information in the
`petition and preliminary response “shows that there is a reasonable
`likelihood that the petitioner would prevail with respect to at least 1 of the
`claims challenged in the petition.” For the reasons that follow, we have
`decided not to institute an inter partes review.
`
`I. BACKGROUND
`A. The ’898 Patent
`The ’898 patent describes a system for “interfacing with network
`management.” Ex. 1001, col. 1, ll. 6–8. According to the ’898 patent,
`“[t]ypical network management systems collect information regarding the
`operation and performance of the network and analyze the collected
`information to detect problems in the network,” such as the network or a
`particular device “approaching an overloaded condition.” Id. at col. 1,
`ll. 38–44. Prior art systems required new software to be written for each
`new application and only collected typical infrastructure information and
`network parameters (e.g., number of packets transmitted, number of packets
`lost), not “specific business-oriented data useful in commercial applications”
`(e.g., number of tickets sold on an airline’s web site). Id. at col. 1,
`l. 50–col. 2, l. 9. The disclosed system attempts to solve these problems by
`
`
`
`2
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`collecting performance data along with meta data that defines the
`performance data and indicates operations to be performed on the
`performance data. Id. at col. 2, ll. 22–29, col. 4, ll. 11–36. The system then
`displays collected performance data according to the meta data. Id.
`Figure 3 of the ’898 patent is reproduced below.
`
`
`
`As shown in Figure 3, a user provides to meta application programming
`interface (API) 130 (1) script-based program 110 containing instructions for
`monitoring some aspect of the network, and (2) information 120 about how
`such monitoring should take place, such as the rate at which network
`components should be polled for information. Id. at col. 7, ll. 13–27. Based
`on information 120, script-based program 110 is integrated into the system
`as service monitor 140, which is registered and activated. Id. at col. 8,
`ll. 17–19, 44–46, col. 9, ll. 31–32. Network monitor 150 then runs service
`monitor 140 periodically to collect meta data and user-defined data 170 from
`components on network 160. Id. at col. 7, ll. 28–30. Network monitor 150
`analyzes the data according to the received meta data, and generates
`
`
`
`3
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`customized graphs 181, customized reports 182, and alarm 183 for display to
`a user. Id. at col. 7, ll. 30–34, col. 10, l. 67–col. 11, l. 6.
`
`
`B. Illustrative Claims
`Claims 1 and 6 of the ’898 patent recite:
`1. A method comprising:
`collecting performance management data having
`accompanying meta data, the meta data including information
`defining the performance management data and information
`indicating operations to be performed on the performance
`management data; and
`generating output data for display using the collected
`performance management data according to the information
`indicating the operations to be performed on the performance
`management data.
`6. A method for providing an interface between a user
`and a performance management system, the performance
`management system being connected with a network, the
`network including a plurality of components coupled by a
`plurality of connections, the performance management system
`collecting data of the components, the method comprising:
`receiving at least one script-based program from the user,
`the script-based programs defining data types not provided by
`the performance management system;
`integrating the program to the performance management
`system as a service monitor, the performance management
`system using the service monitor to periodically collect data of
`the defined data types from the components.
`
`C. The Prior Art
`Petitioner relies on the following prior art:
`Brian W. Kernighan & Dennis M. Ritchie, THE C
`PROGRAMMING LANGUAGE (1988) (Ex. 1004, “Kernighan”);
`
`
`
`4
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`Todd Miller, Christopher Stirlen, & Evi Nemeth,
`satool—A System Administrator’s Cockpit, An Implementation,
`USENIX Association, Proceedings of the Seventh Systems
`Administration Conference (LISA VII), Nov. 1–5, 1993
`(Ex. 1003, “Miller”); and
`Tim O’Reilly, Troy Mott, & Walter Glenn, WINDOWS 98
`IN A NUTSHELL: A DESKTOP QUICK REFERENCE (1999)
`(Ex. 1005, “O’Reilly”).1
`
`
`D. The Asserted Grounds
`Petitioner challenges claims 1–12 of the ’898 patent on the following
`grounds:
`Reference(s)
`
`Basis
`
`Claim(s)
`Challenged
`1–7 and 9–12
`
`Miller
`
`35 U.S.C. § 103(a)2
`
`Miller, Kernighan,
`and O’Reilly
`
`35 U.S.C. § 103(a)
`
`8
`
`
`E. Claim Interpretation
`The Board interprets claims using the “broadest reasonable
`construction in light of the specification of the patent in which [they]
`appear[].” 37 C.F.R. § 42.100(b); see Office Patent Trial Practice Guide,
`77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012); In re Cuozzo Speed Techs.,
`
`
`1 When citing Miller, Kernighan, and O’Reilly, we refer to the page numbers
`added by Petitioner at the bottom of each page. See 37 C.F.R. § 42.63(d)(2).
`
` The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. § 103. Because the ’898 patent has an
`effective filing date before the effective date of the applicable AIA
`amendment, we refer to the pre-AIA version of 35 U.S.C. § 103.
`
` 2
`
`
`
`5
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`LLC, 793 F.3d 1268, 1278–79 (Fed. Cir. 2015). Under this standard, we
`interpret claim terms using “the broadest reasonable meaning of the words in
`their ordinary usage as they would be understood by one of ordinary skill in
`the art, taking into account whatever enlightenment by way of definitions or
`otherwise that may be afforded by the written description contained in the
`applicant’s specification.” In re Morris, 127 F.3d 1048, 1054 (Fed. Cir.
`1997). We presume that claim terms have their ordinary and customary
`meaning. See In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007) (“The ordinary and customary meaning is the meaning that the term
`would have to a person of ordinary skill in the art in question.” (internal
`quotation marks omitted)). A patentee, however, may rebut this
`presumption by acting as his own lexicographer, providing a definition of
`the term in the specification with “reasonable clarity, deliberateness, and
`precision.” In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). The parties
`provide proposed interpretations for various limitations of the claims. See
`Pet. 10–16; Prelim. Resp. 10–13. For purposes of this Decision, however,
`we conclude that only the term “accompanying” requires interpretation.
`Petitioner argues that the term “accompanying” should be interpreted
`to mean “associated.” Pet. 12–14. As support, Petitioner cites a dictionary
`definition of “accompany” as “to go along or in company with,” “to exist or
`occur in association with,” or “to cause to be associated with or attended
`by.” Id. at 12 (citing Ex. 1011, 4). According to Petitioner, although the
`first definition “implies physical togetherness,” the term should be
`interpreted according to the latter two definitions because “nothing in the
`[S]pecification” of the ’898 patent indicates that “accompanying” requires
`the performance management data and meta data to accompany each other
`
`
`
`6
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`physically or travel together with each other. Id. at 13–14. Petitioner relies
`on the testimony of Tal Lavian, Ph.D., regarding how a person of ordinary
`skill in the art would have understood the term. Id. (citing Ex. 1002 ¶ 51).
`Dr. Lavian’s analysis mirrors Petitioner’s arguments in the Petition. Patent
`Owner does not dispute Petitioner’s proposed interpretation. See Prelim.
`Resp. 12–13.
`Based on the record presented, we do not agree with Petitioner’s
`proposed interpretation. The dictionary definitions submitted by Petitioner
`indicate that “accompanying” may have two potential meanings: physically
`going along with or being associated with. See Ex. 1011, 4. The term’s
`usage in claim 1 and the written description of the ’898 patent, however,
`indicate that the term was meant to mean the former. See ACTV, Inc. v.
`Walt Disney Co., 346 F.3d 1082, 1088 (Fed. Cir. 2003) (“the context of the
`surrounding words of the claim . . . must be considered in determining the
`ordinary and customary meaning of those terms”); Renishaw PLC v.
`Marposs Societa’ Per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998) (“where
`there are several common meanings for a claim term, the patent disclosure
`serves to point away from the improper meanings and toward the proper
`meaning”).
`First, claim 1 recites “collecting performance management data
`having accompanying meta data, the meta data including . . . information
`indicating operations to be performed on the performance management
`data,” and “generating output data for display using the collected
`performance management data according to the information indicating the
`operations to be performed on the performance management data.” Thus,
`the performance management data is collected, and that data has
`
`
`
`7
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`accompanying meta data. Reading the claim language in context, the phrase
`“collecting performance management data having accompanying meta data”
`suggests that the meta data accompanies the performance management data
`when the step of collecting is performed (i.e., the meta data travels together
`with the performance management data being collected). Both the
`performance management data and the accompanying meta data are
`collected together in the first claim step, and then output data is generated
`based on the performance management data “according to” a portion of the
`meta data in the second step. Interpreting claim 1 to mean that the meta data
`physically goes along with the performance management data when the
`performance management data is collected is consistent with the surrounding
`language of the claim.
`Second, we disagree with Petitioner’s assertion that there is nothing in
`the Specification indicating that “accompanying” means physically going
`along with. See Pet. 13. To the contrary, the Specification provides:
`In the present invention, generic modules, as well as the
`data storage, receive data and are able to process the data
`using information that accompanies the data. Thus, the data is
`fed
`into [a] module, regardless of
`its
`type,
`from
`the
`environment
`that created
`it.
` A meta data definition
`accompanies the data and indicates what it is that is being
`collected and what is to be done with the data being collected.
`For example, the meta data may indicate that an alarm is to be
`associated with the data or may indicate how to administer.
`Thus, in order to enable or add a new application to monitor a
`new element, the module that obtains the data [] returns a value
`and define[s] what is to be done with the data. Then, the other[]
`modules, such as the stage module, the analysis module and the
`presentation module understand what is defined in the data to
`take the corresponding operations or actions, based on the meta
`
`
`
`8
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`data that indicates what operations or actions to perform on or
`with the data.
`Ex. 1001, col. 4, ll. 11–27 (emphasis added). The above excerpt indicates
`that in “the present invention,” the system receives the data and meta data
`together and processes the data using the meta data that accompanies the
`data. Id. Other portions of the Specification include similar language. See,
`e.g., id. at col. 7, ll. 28–31 (“Network monitor 150 collects meta data and
`data defined by the script-based programs from the network 160 using
`service monitor 140. The returned data 170 is then processed by network
`monitor 150.”), col. 4, ll. 28–32 (“receipt of new data with different meta
`data”), 32–36 (“collect data and the meta data”), Fig. 3 (depicting step 170
`labeled “Meta Data & User-defined Data Collected by the Service
`Monitor”). Importantly, the Specification also states that the system behaves
`differently when it receives different meta data. See id. at col. 4, ll. 28–32
`(the user interface shown to the user “may change by what is in the meta
`data,” such that “while one application may show 4 variables, the receipt of
`new data with different meta data may result in the display of 19 variables”).
`This demonstrates that meta data is not merely associated with the data, but
`instead is collected with the data and impacts how that specific data
`(as opposed to previously collected data) is treated by the system. Like the
`language of claim 1 itself, the Specification supports interpreting claim 1 to
`mean that the meta data physically goes along with the performance
`management data when the performance management data is collected.
`See Pet. 9 (acknowledging that “[t]he performance management system . . .
`uses ‘meta data’ accompanying the data collected from the network
`components”).
`
`
`
`9
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`Further, we are not persuaded by Petitioner’s argument that the
`Specification supports its proposed interpretation. See Pet. 13. Petitioner
`contends that performance management data is collected and analyzed
`“using associated meta data that was already present in the performance
`management system,” id., citing the following from the Specification:
`Once
`the
`[service] monitor
`is activated,
`the network
`perform[ance] monitoring and management system runs it
`periodically to collect the type of data defined in the service
`monitor. Network monitor also analyzes the data with meta
`data, which has already been defined within performance
`monitoring and management system.
`Ex. 1001, col. 10, l. 67–col. 11, l. 6 (emphasis added). The fact that meta
`data may be “defined” at the point when the data is being analyzed,
`however, does not mean that it was not collected along with the performance
`management data. Indeed, this excerpt is consistent with the other portions
`of the Specification cited above because if the data and meta data are
`collected together, the meta data would be “already . . . defined” when the
`network monitor uses it to analyze the data. Petitioner’s proposed reading of
`“accompanying” as reflecting merely an association between the data and
`meta data is not reasonable given the surrounding language of the claim and
`the Specification.
`On this record, applying the broadest reasonable interpretation of the
`claims in light of the Specification, we interpret “accompanying” to mean
`physically going along with.
`
`
`
`
`10
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`II. DISCUSSION
`A. Obviousness Ground Based on Miller
`(Claims 1–7 and 9–12)
`Petitioner contends that claims 1–7 and 9–12 are unpatentable over
`Miller under 35 U.S.C. § 103(a), relying on the supporting testimony of
`Dr. Lavian. Pet. 20–47 (citing Ex. 1002). We are not persuaded that
`Petitioner has established a reasonable likelihood of prevailing on its
`asserted ground for the reasons explained below.
`
`
`1. Miller
`Miller describes a system called “satool” for monitoring a large
`number of distributed network devices. Ex. 1003, 10. The system has three
`components: a Simple Network Management Protocol (SNMP) agent that
`“runs on each machine being monitored,” a data collecting server that polls
`the SNMP agents periodically and stores collected data in a database, and a
`display system that provides a graphical user interface (GUI) to the user for
`viewing the data. Id. at 10–11. The user can provide configuration
`parameters such that, for example, an alarm occurs when a particular
`variable for a machine exceeds a threshold. Id. The SNMP agents use
`“helper scripts” containing standard UNIX commands to collect data. Id. at
`11–12.
`Miller describes a process for adding a new variable to monitor, and
`provides as an example “a new variable that does a traceroute(8)3 to an
`
`
`3 In general, a traceroute utility specifies the route data packets travel
`between a local system and a remote system. See Ex. 1005, 13–14.
`
`
`
`11
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`outside machine to make sure gatewaying is working correctly.” Id. at 16.
`Miller discloses:
`The first step is to write a helper script that the SNMP
`agent will call. In this case, it is a perl(1) script called
`traceroute-helper. The script simply does a traceroute(8) to the
`machine enss.ucar.edu and prints 1 if it was successful and 0 if
`there was a problem (routing loop or host unreachable).
`Id. Next, the new variable is added to the data collecting server’s
`management information base (MIB), the SNMP agent’s software is
`modified to run the traceroute-helper script when appropriate, the data
`collecting server’s software is modified to collect the new variable from the
`SNMP agent, and the display system’s software is modified to display the
`new variable. Id. at 16–17.
`
`
`2. Independent Claim 1
`Petitioner argues that Miller discloses4 all of the limitations of
`claim 1. Pet. 20–28. For example, Petitioner identifies the data provided by
`the traceroute-helper script (i.e., a 1 if the gateway is working or a 0 if not)
`in Miller as “performance management data.” Id. at 20–21 (citing Ex. 1003,
`10, 16–17).
`
`4 Although Petitioner’s asserted ground as to independent claims 1 and 6 is
`based on obviousness under 35 U.S.C. § 103(a), Petitioner argues in its
`Petition that Miller discloses every limitation of the claims, then includes a
`single sentence stating that Miller “discloses or suggests” every limitation.
`Pet. 28, 43. Patent Owner contends that the Petition should be denied
`because Petitioner fails to identify differences between the claimed invention
`and the prior art under Graham v. John Deere Co., 383 U.S. 1 (1966), and
`fails to provide any reason why a person of ordinary skill in the art would
`have modified Miller. Prelim. Resp. 1–9. We need not reach these issues,
`however, as Petitioner’s asserted ground fails for other reasons explained
`herein.
`
`
`
`12
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`Claim 1 further recites “meta data” having two components:
`“information defining the performance management data” and “information
`indicating operations to be performed on the performance management
`data.” Petitioner identifies three instances of information defining
`performance management data in Miller: (1) the “satoolGatewayOk” object
`added to the MIB, which defines the object as an integer (e.g., 1, 0),
`(2) the formatted string “gateway_ok %d” created by the data collecting
`server’s software, where the “%d” string is replaced with 1 or 0 depending
`on the output of traceroute-helper, and (3) the data string “%d” that is part of
`the source code added to the SNMP agent’s software, which instructs the
`software to read an integer from traceroute-helper. Id. at 23–25 (citing
`Ex. 1003, 12–13, 16–17). With respect to information indicating operations
`to be performed on performance management data, Petitioner identifies the
`“gateway_ok 0 X” variable definition added to the display system’s
`software, where “gateway_ok” is the name of the variable that will store the
`output of traceroute-helper, “0” instructs the system to trigger an alarm if
`traceroute-helper outputs a 0 (indicating that there was a connection
`problem), and “X” specifies that the variable is a text object. Id. at 25–27
`(citing Ex. 1003, 16–17).
`Petitioner has not shown sufficiently that Miller teaches “collecting
`performance management data having accompanying meta data,” as recited
`in claim 1. Petitioner’s arguments are premised on its proposed
`interpretation of “accompanying” as merely being associated with. As
`explained above, we disagree and interpret “accompanying” to mean
`physically going along with. See supra Section I.E. The various pieces of
`information identified by Petitioner as “meta data” do not physically go
`
`
`
`13
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`along with the 1 or 0 outputted by the traceroute-helper script (i.e., the
`alleged “performance management data” in Miller). Rather, they are
`portions of source code added to the various systems’ software to enable
`those systems to act on the traceroute-helper output. For example, the
`“gateway_ok 0 X” string added to the display system’s software merely
`defines a variable that tells the system how to display the output of
`traceroute-helper. See Pet. 26; Ex. 1003, 17 (“The final step is to add the
`new variable to the GUI. It must be added to the default list in procedure
`BuildList, file IO.tcl.”). The string does not physically go along with the
`1 or 0 output from traceroute-helper when that value is collected. See
`Pet. 21–22. Petitioner does not explain how Miller teaches the collection of
`performance management data with meta data that physically goes along
`with the performance management data, and does not explain why doing so
`would have been obvious based on Miller. Accordingly, Petitioner has not
`demonstrated a reasonable likelihood of prevailing on its assertion that
`claim 1, as well as claims 2–5 depending therefrom, are unpatentable over
`Miller.
`
`
`3. Independent Claim 6
`Petitioner argues that Miller discloses all of the limitations of claim 6.
`Pet. 37–43. For example, Petitioner identifies the satool system in Miller as
`a “performance management system,” the satool system’s GUI as an
`“interface between a user and a performance management system,” and
`Miller’s helper scripts, such as traceroute-helper, as “script-based programs”
`that are integrated to the system as “service monitor[s].” Id. at 37–41.
`
`
`
`14
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`Claim 6 further recites “the performance management system using
`the service monitor to periodically collect data of the defined data types
`from the components.” The dispositive issue with respect to this limitation
`is Petitioner’s identification of “data” that allegedly is collected in Miller.
`Petitioner appears to advance two theories. First, Petitioner refers to its
`analysis of dependent claim 3 and argues as follows:
`[T]he helper scripts collect data from the client computers, the
`type of data collected being defined by the helper script itself.
`For example, Miller describes an exemplary “traceroute-
`helper” script that collects data regarding whether a computer
`can reach other networked computers via a network gateway,
`and returns data of an integer type to indicate the result. As
`fully explained in connection with claim 3, helper scripts can
`collect data from multiple client computers. The helper scripts
`in Miller therefore are used by the “performance management
`data” to “collect data of the defined data types from the
`components.”
`Id. at 42 (citations omitted, emphasis added). In its analysis of claim 3,
`Petitioner refers to its analysis of claim 25 and argues that traceroute-helper
`“collects performance data indicating whether or not a network gateway is
`operational.” Id. at 34. In its analysis of claim 2, Petitioner argues that
`traceroute-helper collects “performance management data” (i.e., a 1 or 0)
`“indicating whether a network gateway is down.” Id. at 20–21, 30. Thus,
`Petitioner appears to be arguing that the 1 or 0 returned by traceroute-helper
`is the “data” that allegedly is collected in claim 6. Claim 6, however,
`
`5 Claim 2 recites “running the script-based program via the performance
`management system to periodically collect the performance management
`data from components in a network.” Claim 3, which depends from claim 2,
`recites “integrating the at least one script-based program into the
`performance management system as a service monitor” and “using the
`service monitor to periodically collect the performance data.”
`
`
`
`15
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`requires that the data be collected “from the components.” The 1 or 0 in
`Miller is a value determined by the traceroute-helper script based on whether
`it successfully reached another machine, not a value collected from another
`machine. See Ex. 1003, 16 (“The script simply does a traceroute(8) to the
`machine enss.ucar.edu and prints 1 if it was successful and 0 if there was a
`problem (routing loop or host unreachable).” (second emphasis added)).
`Therefore, to the extent Petitioner is relying on the 1 or 0 as the “data” in
`claim 6, Petitioner’s argument fails. See Prelim. Resp. 16, 25–26.
`Second, in the context of claim 2, Petitioner argues that because
`traceroute-helper “performs a traceroute to another computer,” it is
`“collecting data from the other networked computer in determining whether
`or not it is reachable, and returning that data to the SNMP agent.”
`Pet. 32–33. Petitioner points to O’Reilly as “confirming that [a traceroute
`operation] receives a response message from the target machine and
`components along the connection path to the target machine.” Id. (citing
`Ex. 1005, 14). To the extent Petitioner is relying on a “response message”
`returned to the SNMP agent running traceroute-helper as the “data” in claim
`6, we likewise are not persuaded. Claim 6 recites “the script-based
`programs defining data types not provided by the performance management
`system” and “using the service monitor to periodically collect data of the
`defined data types from the components.” Petitioner does not explain
`sufficiently how any response message would constitute data “of the . . . data
`types” defined by the traceroute-helper script.
`Thus, under either theory, we are not persuaded that Miller teaches
`“using the service monitor to periodically collect data of the defined data
`types from the components,” as recited in claim 6. Accordingly, Petitioner
`
`
`
`16
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`has not demonstrated a reasonable likelihood of prevailing on its assertion
`that claim 6, as well as claims 7 and 9–12 depending therefrom, are
`unpatentable over Miller.
`
`
`4. Conclusion
`Upon review of Petitioner’s analysis and the testimony of Dr. Lavian,
`we are not persuaded that Petitioner has shown a reasonable likelihood of
`prevailing on its assertion that independent claims 1 and 6, as well as claims
`2–5, 7, and 9–12 depending therefrom, are unpatentable over Miller.
`
`B. Obviousness Ground Based on Miller, Kernighan, and O’Reilly
`(Claim 8)
`Petitioner contends that claim 8 is unpatentable over Miller,
`Kernighan, and O’Reilly under 35 U.S.C. § 103(a). Pet. 47–55. Claim 8
`depends from claim 6, and Petitioner does not rely on Kernighan or O’Reilly
`for the “using the service monitor to periodically collect data of the defined
`data types from the components” limitation of claim 6. We are not
`persuaded that Petitioner has established a reasonable likelihood of
`prevailing on its asserted ground for the reasons explained above with
`respect to claim 6. See supra Section II.A.3.
`
`
`C. Conclusion
`We conclude that Petitioner has not demonstrated a reasonable
`likelihood of prevailing with respect to at least one claim of the ’898 patent
`challenged in the Petition. Therefore, we do not institute an inter partes
`review on any of the asserted grounds as to any of the challenged claims.
`
`
`
`17
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`
`III. ORDER
`In consideration of the foregoing, it is hereby:
`ORDERED that the Petition is denied as to all challenged claims of
`the ’898 patent.
`
`
`
`18
`
`

`
`IPR2015-01601
`Patent 6,816,898 B1
`
`PETITIONER:
`
`Heidi L. Keefe
`Phillip E. Morton
`Andrew C. Mace
`COOLEY LLP
`hkeefe@cooley.com
`pmorton@cooley.com
`amace@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
`
`
`
`
`19