Cisco Systems, Inc.v.Bockstar Technologies LLC

Patent Trial and Appeal Board

Feb 3, 2015

09408380 (P.T.A.B. Feb. 3, 2015)

Trials@uspto.gov Paper 8
Tel: 571-272-7822 Entered: February 3, 2015

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD

CISCO SYSTEMS, INC.,
Petitioner,
v.
BOCKSTAR TECHNOLOGIES LLC,
Patent Owner.

Case IPR2014-01193
Patent 6,684,241 B1

Before BEVERLY M. BUNTING, BARBARA A. PARVIS, and
MATTHEW R. CLEMENTS, Administrative Patent Judges.
BUNTING, Administrative Patent Judge.

DECISION
Denying Institution of Inter Partes Review
37 C.F.R. § 42.108

IPR2014-01193
Patent 6,684,241 B1
2
I. INTRODUCTION
Cisco Systems, Inc. (“Petitioner”) filed a Petition

requesting inter
partes review of claims 1–39 (the “challenged claims”) of U.S. Patent No.
6,684,241 B1 (Exhibit 1001, “the ’241 patent”) pursuant to 35 U.S.C.
§§ 311–319. Paper 1 (“Pet.”). Patent Owner, Bockstar Technologies LLC,
(“Patent Owner”) timely filed a Preliminary Response to the Petition. Paper
6 (“Prelim. Resp.”). We have jurisdiction under 35 U.S.C. § 314, which
provides that an inter partes review may not be instituted “unless . . . there is
a reasonable likelihood that the petitioner would prevail with respect to at
least 1 of the claims challenged in the petition.”
Upon consideration of the information presented in the Petition and
Preliminary Response, we determine that Petitioner has not demonstrated
that there is a reasonable likelihood that Petitioner would prevail with
respect to at least one challenged claim. Accordingly, we deny the petition
and decline to institute an inter partes review of claims 1–39 of the ’241
patent based on the asserted ground.

II. BACKGROUND
A. Related Proceedings
Petitioner and Patent Owner indicate that the ’241 patent is the subject
of the following judicial matter: Bockstar Technologies LLC v. Cisco
Systems, Inc. et al., No. 1:13-cv-2020 (D. Del., filed December 11, 2013).
Pet. 3; Paper 4, 1.

IPR2014-01193
Patent 6,684,241 B1
3
B. The ’241 Patent (Ex. 1001)
The ’241 patent is directed to an apparatus and method for
configuring a first network device that is a member of a subnet. Ex. 1001,
1:20–21. In a preferred embodiment, the first network device is an
unconfigured router 14 capable of monitoring traffic in its local subnet 12
transmitted by an already configured router, and based on the monitored
traffic, configuring itself to communicate with other routers. Id. at 3:29–32,
41–45. The configured router includes memory 17 for storing subnet related
configuration data. Id. Unconfigured router 14 includes “a configuration
database 22 for storing configuration data parsed and processed from
monitored packets, a configuration module 24 for configuring the router 14
in accord with the data in the configuration database 22, and a plurality of
inter-router protocol modules 26 for communicating with other routers 14.”
Id. at 3:51–58. Data packets transmitted within the subnet include “message
data (e.g., data packets), control data (e.g., control packets), or any other
type of data transported by packets.” Id. at 3:48–51.
Figure 3, reproduced below, further illustrates the process for
configuring a router to be added to a subnet.
IPR2014-01193
Patent 6,684,241 B1
4

Figure 3 shows a process for
configuring a router added to a subnet.
In step 300, the router to be configured passively retrieves packets having
configuration data by monitoring traffic on the subnet, as shown in Figure 4.
Id. at 4:5–27. The retrieved packets are parsed to determine the
configuration data, and the parsed configuration data is stored in the
configuration database for subsequent use in configuring the router. Id.
Additionally, in step 302, unconfigured router 14 can actively retrieve
configuration data from another network device in the subnet, as shown in
Figure 5. Id. at 4:67–5:3. In one embodiment, unconfigured router 14 may
receive an advertisement from another router that is preconfigured to
transmit specified data via the advertisement. Id. at 5:8–12. In another
embodiment, unconfigured router 14 accesses the server and generates a data
request message containing the Internet Protocol address of each router in
the subnet. Id. at 5:33–37. The server generates a reply message containing
the relevant information that is transmitted back to unconfigured router 14.
Id. at 5:39–49.
IPR2014-01193
Patent 6,684,241 B1
5
As shown in step 304, the retrieved data is “utilized (i.e., processed in
many cases) to determine additional configuration data” and “[a]ny
necessary data may be calculated.” Id. at 5:56–58. After the configuration
data “is parsed and/or generated from all sources,” in step 306 the
configuration data is stored in the configuration database, and in step 308 the
unconfigured router to be added is configured using the data in the database.
Id. at 6:12–22.

C. Illustrative Claim
Of challenged claims 1–39 of the ’241 patent, claims 1, 11, 21, 30, 34,
and 39 are independent. Claim 1 is illustrative of the challenged claims and
is reproduced below:
1. A method of configuring an unconfigured first
network device that is a part of a subnet, the subnet
having a second network device, the method
comprising:
retrieving packets having configuration data at the
unconfigured first network device, the retrieved
packets being transmitted by the second network
device;
parsing the retrieved packets to ascertain the
configuration data;
storing at least a portion of the configuration data
parsed from the retrieved packets in a configuration
database associated with the unconfigured first
network device;
utilizing at least one datum of the configuration
data to produce additional configuration data; and
storing the additional configuration data in the
configuration database, the first network device
operating in accord with the data in the configuration
database.
IPR2014-01193
Patent 6,684,241 B1
6

D. The Prior Art
Petitioner relies on the following prior art references (Pet. 4) and the
Declaration of Dr. Paul Clark (Ex. 1005):
Reference Patent/Printed Publication No. Date Exhibit
RFC 1812 Baker, Fred, Network Working
Group RFC 1812, Cisco Systems
June 1995 1003
AutoInstall Internet Archive,
http://www.cisco.com/warp/public
/417/12.html
Dec. 27,
1996
1004

E. Asserted Grounds
Petitioner asserts that claims 1–39 of the ’241 patent are unpatentable
under 35 U.S.C. § 103(a) as obvious over AutoInstall and RFC 1812. Pet. 4.

III. ANALYSIS
A. Claim Interpretation
In an inter partes review, “[a] claim in an unexpired patent shall be
given its broadest reasonable construction in light of the specification of the
patent in which it appears.” 37 C.F.R. § 42.100(b); see Office Patent Trial
Practice Guide, 77 Fed. Reg. 48,756, 48,764 (Aug. 14, 2012) (Claim
Construction); In re Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364 (Fed.
Cir. 2004). Under the broadest reasonable interpretation standard, claim
terms generally are given their ordinary and customary meaning, as would
be understood by one of ordinary skill in the art in the context of the entire
disclosure. See In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
2007). Any special definition for a claim term must be set forth in the
IPR2014-01193
Patent 6,684,241 B1
7
specification “with reasonable clarity, deliberateness, and precision.” In re
Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). In the absence of such a
definition, limitations are not to be read from the specification into the
claims. See In re Van Geuns, 988 F.2d 1241, 1184 (Fed. Cir. 1993).
Petitioner proposes a claim construction for each of the following
claim terms: “configuration database”; “produce additional configuration
data”; “control packets”; and “inter-router protocol.” Pet. 8–11. Patent
Owner disputes Petitioner’s proposed constructions of “produce additional
configuration data,” “control packets,” and “configuration database,” and in
turn proposes a claim construction for these claim terms. Prelim. Resp. 13–
25. For purposes of this decision, we see no need to construe expressly the
claim terms “configuration database,” “control packets,” and “inter-router
protocol” in the challenged claims. The claim term “produce additional
configuration data” is addressed below within the context of construing the
claim phrase “utilizing at least one datum of the configuration data to
produce additional configuration data.”
“utilizing at least one datum of the configuration
data to produce additional configuration data”
Directing us to the Specification (Ex. 1001, 5:54–60) and relying on
the testimony of its declarant, Dr. Clark, Petitioner takes the position that
“one of ordinary skill in the art would understand that utilizing the
configuration data to ‘produce additional configuration data’ can be
performed by utilizing the configuration data to ‘determine additional
configuration data.’” Pet. 10 (citing Ex. 1005 ¶¶ 30–32). Patent Owner
counters that Petitioner’s construction of the claim term “produce additional
configuration data” is unreasonably broad when taken in context with the
entirety of the “utilizing at least one datum of the configuration data to
IPR2014-01193
Patent 6,684,241 B1
8
produce additional configuration data” claim limitation. Prelim. Resp. 13.
In support of its position, Patent Owner alleges that the claim term
“produce” does not encompass the steps of “requesting” or “retrieving”
because “[t]he ordinary meaning of ‘produce’ requires generating something
new, while ‘request’ and ‘retrieve’ seek something that already exists.” Id.
at 14. Relying on Figure 3 for support, Patent Owner further contends that it
is the already-retrieved and parsed configuration data that is then
‘“utiliz[ed]’… to “produce additional configuration data.” Id. at 16. Patent
Owner notes that the Specification describes requesting and receiving
configuration data from another device on the network as “active retrieval”
(Id. at 19) and “produce additional configuration data” as a “derivation or
calculation that follows retrieval.” Id. at 19–20 (citing Ex. 1001, 5:53–58).
Based on this disclosure, Patent Owner asserts that the claim term ‘“produce
additional configuration data’ refers to processing that is distinct from the
mere parsing of packets that are retrieved either passively or actively.” Id. at
20.
We first address Petitioner’s proposed replacement of the term
“produce” with the term “determine” in the context of the claim phrase
“utilizing at least one datum of the configuration data to produce additional
configuration data.” Both parties’ arguments rely on the following teaching
in the Specification:
once the configuration data is actively retrieved, then the
process continues to step 304 in which selected data retrieved in
either or both of steps 300 and 302 are utilized (i.e., processed
in many cases) to determine additional configuration data. Any
necessary data may be calculated.
Ex. 1001, 5:53–58 (emphasis added). We note that the particular example
provided involves calculating data.
IPR2014-01193
Patent 6,684,241 B1
9
Based on our review, the Specification of the ’241 patent does not
explicitly define the term “produce” in connection with “additional
configuration data.” For example, the Specification discloses “[i]n addition
at least one datum from the configuration data is processed to produce
additional configuration data that also is stored in the configuration
database.” Ex. 1001, Abstract; (see also 2:8, 2:44, 7:63) (emphasis added).
Supporting that interpretation, Figure 3 also uses the term “process.” Id. at
Fig. 3.
In other contexts, we find that the Specification uses the term
“produce” in accordance with its usual and customary meaning.
1
Any
special definition for a claim term must be set forth in the specification “with
reasonable clarity, deliberateness, and precision.” In re Paulsen, 30 F.3d
1475, 1480 (Fed. Cir. 1994). In the absence of such a definition, limitations
are not to be read from the specification into the claims. See In re Van
Geuns, 988 F.2d 1241, 1184 (Fed. Cir. 1993). Because the Specification
does not set forth a special definition for “produce” with “reasonable clarity,
deliberateness, and precision,” we construe it to have its ordinary and
customary meaning as would be understood by one of ordinary skill in the
art in the context of the entire disclosure. Translogic, 504 F.3d at 1257.
We, therefore, decline to adopt Petitioner’s proposed construction in light of
the ordinary and customary meaning of the term “produce.”

1
The Merriam-Webster Dictionary defines “produce” as “to make
(something) especially by using machines”; “to make or create (something
by a natural process”; and “to cause (something) to exist or happen: to cause
(a particular result or effect).” Merriam-Webster.com, http://www.merriam-
webster.com/dictionary/produce (last viewed on January 22, 2015).

IPR2014-01193
Patent 6,684,241 B1
10
To the extent Patent Owner argues that the claim phrase “utilizing at
least one datum of the configuration data to produce additional configuration
data” should be considered in its entirety, we agree. See Prelim. Resp. 13.
Patent Owner’s further argument, characterizing the step of “retrieving” as
described in Figure 3, and in further detail in Figures 4–5, as a separate step
from the step of “utilizing,” is also persuasive. See Id. at 13–21. Therefore,
based on the current record, and for purposes of this proceeding, we
determine that the broadest reasonable interpretation of the claim phrase
“utilizing at least one datum of the configuration data to produce additional
configuration data” is “utilizing at least one datum of the retrieved and
parsed configuration data, by the unconfigured first network device, to
create additional configuration data.”
For purposes of this decision, we need not construe expressly any of
the other terms in the challenged claims at this time.

B. Obviousness Based on AutoInstall and RFC 1812
We now turn to Petitioner’s asserted grounds of unpatentability and
Patent Owner’s arguments in its Preliminary Response. Petitioner contends
that clams 1–39 are unpatentable under 35 U.S.C. § 103(a) as obvious over
AutoInstall and RFC 1812. Pet. 17–57. The Declaration of Dr. Clark is
cited by the Petitioner to support the analysis advocated in the Petition. Ex.
1005. Patent Owner counters that the cited references fail to disclose
“utilizing at least one datum of the configuration data to produce additional
configuration data.” Prelim. Resp. 31–39. Having considered the
explanations and supporting evidence presented, we are not persuaded that
AutoInstall and RFC 1812 teach “utilizing at least one datum of the
IPR2014-01193
Patent 6,684,241 B1
11
configuration data to produce additional configuration data.” A detailed
analysis of our determination follows after a brief overview of AutoInstall
and RFC 1812.
1. Overview of AutoInstall (Ex. 1004)
AutoInstall is a product bulletin describing how to make Cisco’s
access routers plug and play by “offloading the software configuration task
from the installer” and controlling it “directly from the central network
operations center.” Ex. 1004, 1. AutoInstall describes three steps to
configure a new router (referred to as “newrouter”): 1) learn IP address; 2)
learn name; and 3) download full configuration. Id. at 2. In particular, the
step of learning the IP address involves newrouter sending out an IP address
request packet that is received by an existing router, which replies with the
IP address of the newrouter. Id. After newrouter acquires its IP address, it
learns its host name by either broadcasting a request for the global
configuration file “network-confg,” or by broadcasting a reverse domain
name server request over the network. Id. Once newrouter receives its
name, newrouter broadcasts for its full configuration file, newrouter-confg,
which is “automatically downloaded to newrouter’s running memory,
thereby configuring it for full operation.” Id.
2. Overview of RFC 1812 (Ex. 1003)
RFC 1812 is a document prepared by the Internet Engineering Task
Force’s Network Working Group, and is an updated version of RFC 1716,
the Historical Router Requirements document. RFC 1812 describes use of
the Bootstrap Protocol (BOOTP), which allows a booting host to configure
itself dynamically and without user supervision. Ex. 1003, 120. BOOTP is
utilized “to notify a host of its assigned IP address, the IP address of a boot
IPR2014-01193
Patent 6,684,241 B1
12
server host, and the name of a file to be loaded into memory and executed,”
as well as other configuration information. Id. at 121. RFC 1812 notes that
some routers boot from the network using the TFTP protocol, and that
“[t]here is no reason that BOOTP could not be used for locating the server
that the boot image should be loaded from.” Id. at 125. To locate the
current boot host, the router to be configured would send a “BOOTP
Request” with its hardware address, and TFTP could then be used to retrieve
the image in the BOOTP reply. Id. RFC 1812 suggests that the router
should have the ability to store parameters learned through BOOTP. Id.
3. Discussion
A patent claim is unpatentable, under 35 U.S.C. § 103(a), if the
differences between the claimed subject matter and the prior art are such that
the subject matter, as a whole, would have been obvious at the time the
invention was made to a person having ordinary skill in the art to which said
subject matter pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
(2007). The question of obviousness is resolved on the basis of underlying
factual determinations, including: (1) the scope and content of the prior art,
(2) any differences between the claimed subject matter and the prior art, (3)
the level of skill in the art, and (4) where in evidence, so-called secondary
considerations. Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966).
Against this backdrop, we consider Petitioner’s argument that AutoInstall
discloses each of the limitations of claims 1–39, and “to the extent any
limitation is not disclosed by AutoInstall, the limitation is obvious in view of
the AutoInstall-RFC 1812 combination.” Pet. 15. To demonstrate which
teachings in AutoInstall satisfy the limitations of the claims, Petitioner
provides a brief summary of the AutoInstall reference, and claim charts
IPR2014-01193
Patent 6,684,241 B1
13
identifying quotations in the reference that correspond with claim elements.
Pet. 17–57.
a. Claim 1
Petitioner argues that AutoInstall discloses the claim limitation of
“utilizing at least one datum of the configuration data to produce additional
configuration data.” Pet. 21. In particular, Petitioner argues that
“AutoInstall discloses that the hostname of the unconfigured router
(corresponding to the “additional configuration data” of claim 1) can be
determined using the IP address ascertained from the received packets.” Id.
(citing Ex. 1004, 2–3). Petitioner also argues that AutoInstall discloses how
data from the global configuration file (ascertained by parsing received
packets) can be used to obtain a second file (newrouter-confg), which
corresponds to the “additional configuration data’ portion” of the limitation.
Id. (citing Ex. 1004, 2–3).
In its Preliminary Response, Patent Owner advances a number of
arguments challenging Petitioner’s contention that AutoInstall discloses the
claim 1 limitation of “utilizing at least one datum of the configuration data to
produce additional configuration data.” Prelim. Resp. 31–34. According to
Patent Owner, the disclosure in AutoInstall regarding using the IP address to
extract the hostname from another device on the network is not “utilizing . . .
to produce;” it is merely a second instance of “actively retrieving” and
“parsing.” Id. at 32. Specifically, the processes of requesting and receiving
packets responsive to a TFTP request or reverse DNS lookup are “an
additional iteration of retrieving and parsing packets to extract configuration
data,” according to Patent Owner. Id. at 33. Patent Owner further argues
that the description in AutoInstall of downloading a full configuration file
IPR2014-01193
Patent 6,684,241 B1
14
likewise “discloses obtaining (e.g., through TFTP) configuration data by
retrieving further packets that include the alleged additional configuration
data, which is ascertained by again parsing the retrieved packets.” Id. at 34
(citing Ex. 1004, 2). In response to Petitioner’s argument that the
newrouter-confg file in AutoInstall corresponds to the “additional
configuration data” of claim 1 (Pet. 21 (citing Ex. 1004, 2–3)), Patent
Owner contends that “AutoInstall’s disclosure of using either TFTP or
Reverse DNS to retrieve a hostname does not teach a router using the IP
address to itself produce additional data.” Prelim. Resp. 33 (emphasis
added).
We are not persuaded Petitioner’s arguments and evidence
demonstrate sufficiently that the cited portions of AutoInstall disclose
“utilizing at least one datum of the configuration data to produce additional
configuration data,” as recited in claim 1. As noted above, we interpret the
steps of “retrieving packets” and “parsing the retrieved packets to ascertain
configuration data” as separate from the step of “utilizing at least one datum
of the configuration data to produce additional configuration data.” For the
reasons provided supra, we construe “utilizing at least one datum of the
configuration data to produce additional configuration data” as requiring
more than just retrieving data and parsing the retrieved data; additional
configuration data must be created by the unconfigured first network device.
Patent Owner argues persuasively that the claims and Specification “clearly
distinguish active retrieval and parsing from ‘utilizing . . . to produce
additional configuration data.’” Id. at 33. Indeed, the Specification
describes how the packets “first are retrieved and then parsed to ascertain the
configuration data” and that “at least one datum from the configuration data
IPR2014-01193
Patent 6,684,241 B1
15
is processed to produce additional configuration data.” Ex. 1001, Abstract.
Additional support for Patent Owner’s position can be found in the
description of steps 300, 302, and 304 of the Specification described above,
as well as the following passage from the Specification:
Once the configuration data is parsed and/or generated
from all sources (i.e. steps 300, 302 and 304 above), then the
process continues to step 306 in which the configuration data is
stored in the configuration database 22 on the given router 14.
. . . The process then continues to step 308 in which the given
router 14 is configured with the data in the database 22, thus
ending the process.
Ex. 1001, 6:13–22.
Thus, Patent Owner argues persuasively that the newrouter-confg file
is not “produced” because it is merely retrieved from a configured router in
the network. Prelim Resp. 32–33. Patent Owner also argues persuasively
that the description in AutoInstall of how the unconfigured router either
“TFTP broadcasts for its full configuration file newrouter-confg” or
“broadcasts a reverse domain name server (DNS) request over the network”
(Ex. 1004, 2) retrieves, but does not “produce,” additional configuration
data. Id. On this record, Petitioner does not demonstrate sufficiently that
the description in AutoInstall concerning the unconfigured router learning its
IP address or learning its name teaches “utilizing at least one datum of the
configuration data to produce additional configuration data.”
Having determined that AutoInstall does not disclose this limitation,
we next consider Petitioner’s arguments regarding RFC 1812. Petitioner
contends that RFC 1812 discloses that the unconfigured router can obtain its
IP address and other configuration parameters using BOOTP (Pet. 19 (citing
Ex. 1003, 120–121, 124–125)) and then uses the received parameters to
IPR2014-01193
Patent 6,684,241 B1
16
configure itself. Id. at 20 (citing Ex. 1003, 124–125). Patent Owner
counters that RFC 1812’s teaching to use data from received BOOTP
packets to obtain a second configuration file does not teach “utilizing at least
one datum of the configuration data to produce additional configuration
data.” Prelim. Resp. 34. Instead, Patent Owner contends that RFC 1812,
like AutoInstall, teaches only to retrieve and parse, but not to “produce,”
additional configuration data. Id. at 34 (citing Ex. 1003, 120–21, 124–125).
We are not persuaded, on this record, that Petitioner’s arguments and
evidence demonstrate sufficiently that RFC 1812 teaches “utilizing at least
one datum of the configuration data to produce additional configuration
data.” Petitioner’s contention that “the unconfigured router uses its IP
address, the name of the configuration file, and the address of the server
hosting the configuration file (all in the BOOTP response packets) to obtain
the configuration file” (Pet. 22 (citing Ex. 1003, 120–121, 124–125; Ex.
1005 ¶ 60)) fails to identify any configuration data that is “created” by the
unconfigured first network device (i.e. router) as the result of processing the
configuration data.
After considering fully the parties’ arguments and evidence with
regards to independent claim 1, we are not persuaded sufficiently by
Petitioner’s arguments that the teachings of AutoInstall and RFC 1812 each
disclose the limitation of “utilizing at least one datum of the configuration
data to produce additional configuration data,” as recited by independent
claim 1. Because we are not persuaded that AutoInstall and RFC 1812
disclose this limitation, we need not address arguments advanced by
Petitioner concerning motivations to combine these references. Pet. 15–17.
IPR2014-01193
Patent 6,684,241 B1
17
b. Dependent Claims 2–10
Petitioner provides separate arguments and claim charts for claims 2–
10 that depend from claim 1. Pet. 32–48. By virtue of their dependency,
claims 2–10 incorporate the same limitations as their underlying base claim.
For the same reasons discussed above, our determination concerning the
insufficiency of Petitioner’s evidence with respect to the “utilizing at least
one datum of the configuration data to produce additional configuration
data” limitation of independent claim 1, applies equally to the claims that
depend from claim 1.
c. Independent Claims 11, 21, 30, 34, and 39
Petitioner further argues that independent claims 11, 21, 30, 34 and 39
are unpatentable under 35 U.S.C. § 103(a) as obvious based on AutoInstall
and RFC 1812 “for reasons analogous to those discussed above with respect
to Claim 1.” Pet. 48–49; 53–57. Having considered Petitioner’s arguments
concerning the prior art references of AutoInstall and RFC 1812, we are not
persuaded that Petitioner has demonstrated a reasonable likelihood that it
would prevail in demonstrating the obviousness of challenged claims 11, 21,
30, 34 and 39 for the same reasons discussed above for claim 1.
d. Dependent Claims 12–20; 22–29; 31–33; and 35–38
Petitioner provides separate arguments and claim charts for claims
12–20 that depend from claim 11; claims 22–29 that depend from claim 21;
claims 31–33 that depend from claim 30; and claims 35–38 that depend from
claim 34. Pet. 49–56. Again, by virtue of their dependency, each of these
dependent claims incorporate the same limitations as their respective
underlying base claim. For the same reasons discussed above, our
determination concerning the insufficiency of Petitioner’s evidence with
IPR2014-01193
Patent 6,684,241 B1
18
respect to the “utilizing at least one datum of the configuration data to
produce additional configuration data” limitation of independent claim 1,
also applies to the claims that depend from independent claims 11, 21, 30,
and 34, respectively.
e. Summary
On this record, Petitioner has not demonstrated a reasonable
likelihood that it would prevail with respect to its contention that claims 1–
39 of the ’241 patent are obvious over AutoInstall and RFC 1812.

IV. CONCLUSION
For the foregoing reasons, we conclude that Petitioner has not
demonstrated a reasonable likelihood that at least one of challenged claims
1–39 of the ’241 patent is unpatentable based on the asserted grounds.

V. ORDER
In consideration of the foregoing, it is hereby:
ORDERED that the Petition for inter partes review of the ’241 patent
is DENIED.

IPR2014-01193
Patent 6,684,241 B1
19
PETITIONER:
Barton E. Showalter
Chad C. Walters
Douglas M. Kubehl
BAKER BOTTS L.L.P.
bart.showalter@bakerbotts.com
chad.walters@bakerbotts.com
doug.kubehl@bakerbotts.com

PATENT OWNER:
Andrea G. Reister
Gregory S. Discher
Jay I. Alexander
COVINGTON & BURLING LLP
areister@cov.com
gdischer@cov.com
jalexander@cov.com