Trials@uspto.gov
`571-272-7822
`
`
`Paper 7
`Entered: October 6, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`ARISTA NETWORKS, INC.,
`Petitioner,
`
`v.
`
`CISCO SYSTEMS, INC.,
`Patent Owner.
`
`Case IPR2015-00974
`Patent 7,224,668 B1
`
`
`
`
`
`Before BRYAN F. MOORE, MATTHEW R. CLEMENTS, and
`PETER P. CHEN, Administrative Patent Judges.
`
`CLEMENTS, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`I.
`INTRODUCTION
`Arista Networks, Inc. (“Petitioner”) filed a Petition requesting inter
`partes review of claims of claims 1–10, 12, 13, 15–28, 30, 31, 33–43, 45–
`49, 51–64, 66, 67, and 69–72 (“the challenged claims”) of U.S. Patent No.
`7,224,668 B1 (Ex. 1001, “the ’668 patent”). Paper 2 (“Pet.”). Cisco
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`Systems, Inc. (“Patent Owner”) filed a Preliminary Response. Paper 6
`(“Prelim. Resp.”). We have jurisdiction under 35 U.S.C. § 314, which
`provides that an inter partes review may be authorized only if “the
`information presented in the petition . . . and any [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.” 35 U.S.C.
`§ 314(a); 37 C.F.R. § 42.4(a). Upon consideration of the Petition and the
`Preliminary Response, we determine that the information presented by
`Petitioner does not establish that there is a reasonable likelihood that
`Petitioner would prevail in showing the unpatentability of any of the
`challenged claims 1–10, 12, 13, 15–28, 30, 31, 33–43, 45–49, 51–64, 66, 67,
`and 69–72 of the ’668 patent. Accordingly, pursuant to 35 U.S.C. § 314, we
`do not institute an inter partes review of claims 1–10, 12, 13, 15–28, 30, 31,
`33–43, 45–49, 51–64, 66, 67, and 69–72 of the ’668 patent.
`
`A. Related Proceedings
`The ’668 patent is involved in Cisco Systems, Inc. v. Arista Networks,
`Inc., Case No. 4:14-cv-05343 (N.D. Cal.) and Cisco Systems, Inc. v. Arista
`Networks, Inc., Network Devices, Related Software and Components Thereof
`(II), ITC Inv. No. 337-TA-945. Pet. 1; Paper 4, 1. Petitioner has also filed
`petitions requesting inter partes review of other patents owned by Patent
`Owner: IPR2015-00973 (U.S. Patent No. 6,377,577), IPR2015-00975 (U.S.
`Patent No. 8,051,211), IPR2015-00976 (U.S. Patent No. 7,023,853),
`IPR2015-00978 (U.S. Patent No. 7,340,597), IPR2015-01049 (U.S. Patent
`No. 6,377,577), and IPR2015-01050 (U.S. Patent No. 7,023,853).
`
`2
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`
`B. The ’668 patent
`The ’668 patent relates generally to an internetworking device, such
`as a router, with improved immunity to Denial of Service (“DoS”) attacks.
`Ex. 1001, Abstract. At the time, a router typically separated its functionality
`into a data plane, responsible for accepting transit packets at input ports and
`routing or switching them to output ports, and a control plane, responsible
`for higher layer functions, such as establishing routing tables. Id. at 1:52–
`59. Denial of Service attacks were commonly directed at the control plane.
`Id. at 1:59–67. Attempts to solve such problems were difficult to administer
`and could result in poor performance when control-plane policies were
`applied not only to control plane packets, but also to transit packets. Id. at
`2:24–3:2.
`To address these and other issues, the ’668 patent discloses an
`internetworking device whose control plane processes are collectively
`arranged as a single addressable port such that all packets intended for the
`control plane always pass through this designated port, which thereby
`provides the ability to better manage control plane traffic. Id. at 3:42–50. A
`set of port services unique to the control plane may be applied to the
`aggregate control plane port. Id. at 3:54–56.
`Figure 1 is reproduced below.
`
`3
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`
`
`
`Figure 1 is a block diagram of internetworking device 100, such as a router,
`comprising control plane port 140, which defines a single access path
`between switch engine 130 and control plane 150. Id. at 4:47–67. Line
`cards 110 and central switch engine 130 accept packets received on a given
`port 120 and route them through to another output port 120. Id. at 5:5–7.
`Because all packets destined to control plane 150 pass through central switch
`engine 130 prior to being routed to functions 155, central switch engine 130
`can be used to implement aggregate control plane protection. Id. at 5:36–42.
`Control plane port services determine if a given packet is destined to a
`control plane process 150. Id. at 5:56–58. Control plane port 140 may be a
`single physical port or may be a virtual address, but either way, it can be
`treated as a traditional hardware port to which a full range of traditional port
`
`4
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`control features—e.g., rate limiting, access lists, hierarchical queues based
`on priority—can be applied to help protect control plane 150 from a DoS
`attack, or to provide other QoS (quality of service). Id. at 5:1–4, 5:66–6:44.
`
`C. Illustrative Claim
`Of the challenged claims, claims 1, 9, and 11 are independent. Claim
`1 is reproduced below:
`1.
`An internetworking device comprising:
`a.
`a plurality of physical network interface ports,
`each for providing a physical connection point to a network for
`the internetworking device, the ports being configurable by
`control plane processes;
`b.
`port services, for operating on packets entering and
`exiting the physical network interface ports, the port services
`providing an ability to control and monitor packet flows, as
`defined by control plane configurations;
`c.
`a control plane, comprising a plurality of
`internetworking control plane processes, the control plane
`processes for providing high-level control and configuration of
`the ports and the port services;
`d. wherein:
`i.
`a control plane port entity provides access to
`the collection of control plane processes, so that a set of
`control plane port services can be applied thereto; and
`ii.
`the control plane port services operate on
`packets received from specific, predetermined physical
`ports and destined to the collection of control plane
`processes in a way that is independent of the physical
`port interfaces and services applied thereto.
`Ex. 1001, 9:17–40.
`
`5
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`
`D. Evidence Relied Upon
`Petitioner relies upon the following references:
`Amara
`US 6,674,743 B1
`Jan. 6, 2004
`Moberg
`US 6,460,146 B1
`Oct. 1, 2002
`Subramanian
`US 6,970,943 B1
`Nov. 29, 2005
`Hendel
`US 6,115,378
`Sept. 5, 2000
`Joe Habraken, PRACTICAL CISCO ROUTERS, Que Corp. (1999)
`(hereinafter “Habraken”).
`
`Ex. 1004
`Ex. 1005
`Ex. 1006
`Ex. 1007
`Ex. 1010
`
`Pet. 3–4. Petitioner also relies upon the Declaration of Dr. Bill Lin (“Lin
`Decl.”) (Ex. 1002).
`
`E. The Asserted Grounds of Unpatentability
`Petitioner argues that the challenged claims are unpatentable based on
`the following grounds:
`References
`Amara
`Amara & Habraken
`
`Basis Claims challenged
`§ 102 1–6, 8, 9, 15–22, 24–27,
`33–40, 42, 45–47, 51–
`§ 103
`58, 60–63, and 69–72
`§ 103 7, 23, 41, and 59
`Amara & Moberg
`§ 103
`Amara, Habraken, & Moberg
`§ 103 10, 12, 13, 28, 30, 31,
`Amara & Subramanian
`43,48, 49, 64, 66, and 67
`Amara, Habraken, & Subramanian § 103
`Amara & Hendel
`§ 103
`Amara, Habraken, & Hendel
`§ 103
`
`II. ANALYSIS
`
`A. Claim Construction
`In an inter partes review, claim terms in an unexpired patent are
`interpreted according to their “broadest reasonable construction in light of
`the specification of the patent” in which they appear. 37 C.F.R. § 42.100(b);
`see also In re Cuozzo Speed Techs., LLC, 793 F.3d 1268, 1278–79 (Fed. Cir.
`
`6
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`2015). Applying that standard, we interpret the claim terms according to
`their ordinary and customary meaning in the context of the patent’s written
`description. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007). Petitioner proposes constructions for ten terms. Pet. 9–14. Patent
`Owner disputes some of those constructions and proposes an additional term
`for construction. Prelim. Resp. 9–19.
`For purposes of this Decision, we determine that we need not
`expressly construe any of the terms for which the parties have proposed
`constructions.
`
`B. Claims 1–6, 8, 9, 15–22, 24–27, 33–40, 42,
`45–47, 51–58, 60–63, and 69–72 – Asserted Anticipation by Amara
`Petitioner argues that claims 1–6, 8, 9, 15–22, 24–27, 33–40, 42,
`45–47, 51–58, 60–63, and 69–72 are unpatentable under 35 U.S.C. § 102(e)
`as anticipated by Amara. Pet. 4, 15–38.
`Amara (Exhibit 1004)
`Amara describes a packet-forwarding device that provides policy-
`based services for internal applications. Ex. 1004, Title, Abstract.
`Figure 3 is reproduced below.
`
`
`
`7
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`
`Figure 3, above, is a block diagram of packet forwarding device 200.
`Device 200 includes interfaces 202–206 that are able to transmit packets to
`and to receive packets from nodes 208–212, respectively. Id. at 5:51–55.
`Packet classifiers 214–218 classify the packets received by nodes interfaces
`202–206, respectively, as either internally-destined packets or external
`packets, based on the packets’ destination addresses. Id. at 5:55–58. Packet
`classifiers 214–218 forward the internally-destined packets to internal
`interface 220, and packet classifiers 214–218 forward the external packets to
`packet forwarder 222 via policy engines 224–228, respectively. Id. at 5:58–
`62. Internal interface 220 forwards the internally-destined packets from
`packet classifiers 214–218 to internal applications 230 and forwards the
`internally-generated packets from internal applications 230 to packet
`forwarder 222. Id. at 5:63–6:2. Packet forwarder 222 forwards the external
`packets from packet classifiers 214–218 and the internally-generated packets
`from internal interface 220 to one or more of interfaces 202–206, via policy
`engines 224–228, based on the destination addresses of the packets. Id. at
`6:3–8.
`Device 200 applies policies to the internal packets and to the external
`packets. Specifically, policy engine 232 applies a policy to the internally-
`destined packets used by internal applications 230 and to the internally-
`generated packets generated by internal applications 230. Id. at 6:9–12.
`Policy engines 224–228 apply policies to the external packets forwarded by
`packet classifiers 214–218, respectively, and typically also apply policies to
`the external packets forwarded by packet forwarder 222. Id. at 12–16. The
`policies applied to internal packets may differ from those applied to external
`packets. Id. at 6:17–19.
`
`8
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`
`Analysis
`In light of the arguments and evidence, Petitioner has not established a
`reasonable likelihood that claims 1–6, 8, 9, 15–22, 24–27, 33–40, 42, 45–47,
`51–58, 60–63, and 69–72 are unpatentable as anticipated by Amara.
`1. “a plurality of physical network interface ports . . . the ports being
`configurable by control plane processes.”
`Independent claims 1, 19, 37, and 55 recite “a plurality of physical
`network interface ports . . . the ports being configurable by control plane
`processes.” Petitioner relies upon Amara’s disclosure that its “internal
`applications,” which Petitioner identifies as corresponding to the recited
`“control plane processes,” “typically serve to control or configure device
`100.” Pet. 21 (quoting Ex. 1004, 4:34–35). Petitioner contends that:
`A POSITA would have read these aspects of Amara as
`disclosing that internal applications 230 configure interface
`ports 202, 204, and 206 in appropriate circumstances. Ex.
`1002, ¶ 46. In particular, a POSITA would have understood
`that the internal applications of a router that provide control and
`configuration were designed to configure the status of the
`router’s ports, for example, as either enabled or disabled, and
`other characteristics of the ports. Id. Accordingly, a POSITA
`would have understood that Amara describes the interface ports
`202-06 being configurable by internal applications 230 and,
`when appropriate, internal applications 230 configuring ports
`202-06.
`Pet. 21–22. In the testimony cited by Petitioner, Dr. Lin elaborates:
`In particular, a POSITA would have understood that the
`internal applications 230 would be able to enable or disable any
`given physical interface port, set a protocol for any given
`physical interface port, or set the address of any given physical
`interface port. See, e.g., Habraken, page 132-134. The
`capability to disable a certain physical interface port, for
`example, would have been necessary to handle a situation in
`
`9
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`
`which the link connected to the port became unreliable.
`Further, a POSITA would have understood that the internal
`applications 230 would, for example, need to be able to
`configure whether a port operates in 10 Mb Ethernet mode, 100
`Mb Ethernet mode, or 10/100 Mb Ethernet mode, or whether a
`port operates in half-duplex or full-duplex mode, or whether
`auto-negotiation is enabled. Because routers as of the Critical
`Date operated in these different modes, it was critical for
`networking devices
`to be configurable by
`the
`internal
`applications in the manner described. Accordingly, a POSITA
`would have understood that Amara describes the interface ports
`202-208 being configurable by the internal applications 230
`and, when appropriate, the internal applications 230 configuring
`the ports 202-206.
`Ex. 1002 ¶ 46.
`Patent Owner argues that Petitioner fails to establish that Amara
`discloses this limitation expressly or inherently. Prelim. Resp. 22. As to the
`express disclosure in Amara, Patent Owner argues that it does not disclose
`that (1) Amara’s interface ports—as opposed to “the device” generally—are
`configurable; or (2) that it Amara’s internal applications actually configure
`these interface ports. Id. As to Petitioner’s assertions about how a person of
`ordinary skill in the art would understand Amara, Patent Owner
`characterizes those statements as an inherency argument, and disputes
`whether Dr. Lin’s testimony establishes that internal applications necessarily
`are able to configure the interface ports. Id. at 22–25.
`We agree with Patent Owner that Amara’s express disclosure is not
`sufficient. Amara’s disclosure that internal applications control or configure
`the device only “typically” suggests that they do not necessarily serve that
`purpose and, therefore, that another component of device 100 may serve that
`purpose. Moreover, Amara’s disclosure that internal applications control or
`
`10
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`configure the “device” is not sufficiently specific as to whether the interface
`ports are an aspect of the device being controlled or configured by the
`internal applications.
`Our reviewing court has held that a prior art reference that does not
`expressly disclose a limitation, may nevertheless anticipate if a person of
`ordinary skill in the art would understand the prior art to disclose the
`limitation and could combine the prior art description with his own
`knowledge to make the claimed invention. See Helifix Ltd. v. Blok-Lok,
`Ltd., 208 F.3d 1339, 1347 (Fed. Cir. 2000). After reviewing the arguments
`of the parties and the testimony of Dr. Lin, however, we are not persuaded
`that a person of ordinary skill in the art1 would understand the cited sentence
`in Amara as necessarily disclosing that the network interface ports of
`Amara’s internetworking device are configurable by its internal applications.
`Dr. Lin relies on pages 132 to 134 of Habraken, which is a textbook
`that describes, inter alia, configuring the interfaces of a Cisco router through
`a Setup dialog. While this passage describes configuring a port, it is not
`clear what aspect of the Cisco router is providing the Setup dialog. Nothing,
`for example, attributes the Setup dialog to “control plane processes” or
`“internal applications” or the like of the Cisco router. Even assuming that
`the Setup dialog is provided by an “internal application” of the Cisco router,
`
`1 Petitioner asserts, and Patent Owner does not dispute, that a person of
`ordinary skill as of the critical date would have had a Master of Science
`Degree in an academic area emphasizing computer networking or,
`alternatively, a Bachelor Degree in an academic area emphasizing the design
`of electrical, computer, or software engineering and several years of
`experience in computer network engineering and the design of computer
`networks. Pet. 7.
`
`11
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`nothing in Habraken supports the determination that the network interface
`ports of all routers, such as the 3Com router described in Amara, are
`configurable by “internal applications” of that router. At best, Habraken
`establishes that a person of ordinary skill in the art at the time would have
`known that Cisco routers include a Setup dialog for configuring router
`interfaces. This is not sufficient, however, to persuade us that a person of
`ordinary skill in the art would have read Amara as necessarily disclosing that
`the network interface ports of the “device” are configurable by the internal
`applications.
`2. “port services . . . as defined by control plane configurations”
`Independent claims 1, 19, 37, and 55 recite “port services . . . as
`defined by control plane configurations.” Petitioner contends that:
`[A] POSITA would have understood Amara as describing the
`policies applied by the policy engines 224-28 being configured
`by internal applications 230 based, for example, on inputs by
`administrators. Ex. 1002, ¶ 37.
`Pet. 24. In the testimony cited by Petitioner, Dr. Lin elaborates:
`A POSITA would have understood that Amara describes the
`policies applied by the policy engines 224-228 and 232 as being
`controlled and configured by the internal applications 230
`based, for example, on inputs from administrator. In describing
`prior policy engines, Amara notes that policy engines are
`configurable and, in fact, multiple policy engines in a device
`may be separately configurable so as to apply different policies.
`Id. at 2:53-57. A POSITA would have understood that such
`policies are typically set in devices such as routers by a network
`administrator. See, e.g., Habraken, 144-145; 244-258. In fact,
`even the ’668 patent, in its discussion of FIG. 5, notes that such
`configuration commands for rate limiting are “familiar to
`network administrators.” The ’668 Patent, 7:23-26. To set
`such policies, administrators would often use a remote access
`application, for example Telnet, to instruct the internal
`
`12
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`
`applications running on the router to appropriately configure
`the router to enforce the policies. See, e.g., Habraken, 144-145;
`244-258. Accordingly, based on Amara’s combined description
`of (1) the policy engines 224-228 and 232 with associated
`policies, (2) the internal applications serving to configure or
`control the device, and (3) the internal applications being
`remotely accessed using, for example, Telnet, a POSITA would
`have understood Amara as disclosing the policies being set by
`administrators remotely accessing the internal applications and
`sending commands to the internal applications, and the internal
`applications as a result configuring the device appropriately so
`that the policy engines 224-228 and 232 apply the policies.
`See, e.g., id.
`Ex. 1002 ¶ 37.
`Patent Owner argues that Petitioner fails to establish that Amara
`discloses this limitation expressly or inherently. Prelim. Resp. 28. Patent
`Owner argues that Amara does not disclose that (1) Amara’s interface
`ports—as opposed to “the device” generally—are configurable; or (2) that it
`Amara’s internal applications actually configure these interface ports. Id. at
`28–29. As to Petitioner’s assertions about how a person of ordinary skill in
`the art would understand Amara, Patent Owner characterizes those
`statements as an inherency argument, and disputes whether Dr. Lin’s
`testimony establishes that internal applications necessarily are able to
`configure the interface ports. Id. at 29–31.
`We agree with Patent Owner that Amara does not adequately disclose
`this limitation expressly or inherently. Petitioner cites only to the
`Declaration of Dr. Lin for support. Pet. 24 (citing Ex. 1002 ¶ 37). Dr. Lin’s
`testimony as to what a person of ordinary skill in the art would understand
`about Amara’s “internal applications” and their role in configuring the
`policies enforced by policy engines 224–28 does not adequately tie the
`
`13
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`policies enforced by policy engines 224–28 to the “internal applications.”
`Dr. Lin relies on Habraken’s disclosure of the use of Telnet to configure
`Cisco routers, but does not establish that the port services of all routers, such
`as the 3Com router described in Amara, were necessarily configurable by
`“internal applications” of the router.
`Conclusion
`On this record, we are not persuaded that Petitioner has established a
`reasonable likelihood that it would prevail in showing that claims 1–6, 8, 9,
`15–22, 24–27, 33–40, 42, 45–47, 51–58, 60–63, and 69–72 are unpatentable
`as anticipated by Amara.
`
`C. Assserted Obviousness over Amara and Moberg, over
`Amara and Subramanian, and over Amara and Hendel
`Petitioner argues that (1) dependent claims 7, 23, 41, and 59 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over Amara and Moberg;
`(2) dependent claims 10, 12, 13, 28, 30, 31, 43, 48, 49, 64, 66, and 67 are
`obvious over either Amara and Subramanian, or Amara and Hendel. Pet.
`38–58. In each ground, Petitioner relies upon its analysis of Amara with
`respect to the independent claims from which these claims depend, and
`alleges that the additional reference—Moberg, Subramanian, or Hendel—
`teaches the additional limitation(s) recited in the dependent claim. Id.
`As discussed above, we are not persuaded that Amara discloses “a
`plurality of physical network interface ports . . . the ports being configurable
`by control plane processes,” as recited in each of the respective independent
`claims from which these claims depend. Petitioner does not allege that the
`additional references—Moberg, Subramanian, or Hendel—teach this
`limitation. Pet. 38–58. Accordingly, we are not persuaded, on this record,
`
`14
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`that the underlying independent claims would have been obvious in view of
`either Amara and Moberg, or Amara and Subramanian, or Amara and
`Hendel. Because we are not persuaded that the underlying independent
`claims are unpatentable, we also are not persuaded that the dependent claims
`challenged in these grounds are unpatentable.
`
`D. Claims 1–10, 12, 13, 15–28, 30, 31, 33–43, 45–49,
`51–64, 66, 67, and 69–72 – Obviousness Based on Habraken
`Petitioner argues that (1) claims 1–6, 8, 9, 15–22, 24–27, 33–40, 42,
`45–47, 51–58, 60–63, and 69–72 are unpatentable under 35 U.S.C. § 103(a)
`as obvious over Amara and Habraken; (2) claims 7, 23, 41, and 59 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over Amara, Habraken,
`and Moberg; and (3) claims 10, 12, 13, 28, 30, 31, 43, 48, 49, 64, 66, and 67
`are obvious over either Amara, Habraken, and Subramanian, or Amara,
`Habraken, and Hendel. Pet. 58–60.
`Patent Owner accurately observes that “Petitioner presents four
`additional obviousness grounds in the final two pages of the Petition”
`(Prelim. Resp. 49) and faults Petitioner’s analysis for (1) providing no
`reason to combine Habraken with any of Moberg, Subramanian, or Hendel;
`(2) summarily citing nearly 50 pages of Habraken without explanation; (3)
`not identifying claim features missing from Amara; and (4) “shift[ing] the
`burden to the Board and to Patent Owner to ‘sift through’ Habraken to
`synthesize and speculate as to the specific unpatentability arguments
`intended by Petitioner.” Prelim. Resp. 49–52.
`We agree with Patent Owner that the Petition does not identify with
`sufficient particularity the ground on which the challenge to the independent
`
`15
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`claims is based. For example, the Petition identifies two limitations of
`independent claim 1 for which we could rely on either Amara or Habraken:
`As described above with respect to Ground 1A, Amara
`describes (1) the internal applications configuring the interface
`ports 202-06, (2) the internal applications configuring policies
`applied by the policy engines 224-28, and (3) the addresses of
`the device being specified in the configuration of the device
`200. Supra, [1.1], [1.2], [3.0]. However, even if one were to
`conclude that this is not the case, it would have been obvious in
`view of Habraken to modify Amara’s device to include any or
`all of (1), (2), and (3).
`Pet. 58 (emphasis added). The Petition then blanket cites 46 pages of
`Habraken to support its contention that Habraken teaches these features. Id.
`at 58–59. This analysis addresses explicitly limitations [1.1] and [1.2], but it
`applies equally to independent claims 19, 37, and 55, which recite similar
`limitations. Moreover, for independent claims 37 and 55, the Petition
`identifies a third limitation for which we could rely on either Amara or
`Habraken:
`Similarly, as described above, Amara describes (4) the internal
`applications being executed by a processor and (5) the device
`including a computer readable medium, such as a memory, to
`store instructions that configure the router, and all of its
`components, to operate as expected. Supra, [55.0], [37.3].
`However, even if one were to conclude that is not the case, it
`would have been obvious in view of Habraken to modify
`Amara’s device to include any or all of (4) and (5).
`Pet. 59. As a result, this ground presents three possible combinations of
`Amara and Habraken for claims 1 and 19,2 and seven possible combinations
`
`
`2 For claim 1, for example, the three possible combinations are: (1) Amara
`for [1.1] and Habraken for [1.2]; (2) Habraken for [1.1] and Amara for [1.2];
`
`
`16
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`of Amara and Habraken for claims 37 and 55. Each of the possible
`combinations serves as a separate basis for considering the obviousness of
`the claimed invention as a whole, yet it is uncertain which of the different
`combinations is relied upon to support that conclusion. The Petition
`nowhere indicates, sufficiently, which one of the 3 or 7 potential sets of
`differences underlies the obviousness conclusion. The Petition, therefore,
`fails to identify with sufficient specificity the differences between the
`claimed invention and the prior art.
`Petitoner’s assertions with respect to dependent claims 2–10, 12, 13,
`15–18, 20–28, 30, 31, 33–36, 38–43, 45–49, 51–54, 56–64, 66, 67, and 69–
`72 are undermined by the above-discussed deficiencies with respect to
`independent claims 1, 19, 37, and 55. Petitioner’s sole conclusory sentence
`addressing the dependent claims (Pet. 60) does not cure the deficiencies
`stemming from the independent claims on which the dependent claims
`depend.
`Accordingly, on this record, we are not persuaded that Petitioner has
`established a reasonable likelihood that it would prevail in establishing the
`unpatentability of claims 1–10, 12, 13, 15–28, 30, 31, 33–43, 45–49, 51–64,
`66, 67, and 69–72 over any combination based on Habraken.
`
`III. CONCLUSION
`For the foregoing reasons, we determine that Petitioner has not
`established that there is a reasonable likelihood that Petitioner would prevail
`
`
`and (3) Habraken for [1.1] and Habraken for [1.2].
`
`17
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`in establishing the unpatentability of claims 1–10, 12, 13, 15–28, 30, 31, 33–
`43, 45–49, 51–64, 66, 67, and 69–72 of the ’668 patent.
`
`IV. ORDER
`
`Accordingly, it is
`ORDERED that the Petition is denied as to all challenged claims of
`the ’668 patent; and
`FURTHER ORDERED no inter partes review is instituted.
`
`
`
`18
`
`

`
`IPR2015-00974
`Patent 7,224,668 B1
`
`For PETITIONER:
`
`W. Karl Renner
`Kevin E. Greene
`FISH & RICHARDSON P.C.
`axf@fr.com
`IPR40963-006IP1@fr.com
`
`
`
`For PATENT OWNER:
`
`Lori A. Gordon
`Daniel Block
`Robert G. Sterne
`Jon E. Wright
`STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C.
`lgordon-PTAB@skgf.com
`dblock-PTAB@skgf.com
`rsterne-PTAB@skgf.com
`jwright-PTAB@skgf.com
`
`
`19