`Patent No. 10,652,111
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`CISCO SYSTEMS, INC. AND JUNIPER NETWORKS, INC.,
`Petitioners,
`
`v.
`
`ORCKIT CORPORATION,
`Patent Owner.
`____________
`
`Case IPR2023-005541
`U.S. Patent No. 10,652,111
`____________
`
`PATENT OWNER’S SUR-REPLY
`
`
`
`1 IPR2024-00037 (Juniper Networks, Inc) has been joined with this proceeding.
`
`
`
`TABLE OF CONTENTS
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`
`Page
`
`I.
`
`INTRODUCTION ......................................................................................... 1
`
`II. CLAIM CONSTRUCTION .......................................................................... 2
`
`III. THE CHALLENGED CLAIMS ARE PATENTABLE ............................ 2
`
`A. Ground 1: Lin and Swenson do not render the claims
`obvious. ................................................................................................. 2
`
`1.
`
`2.
`
`3.
`
`4.
`
`Lin does not teach the claimed controller. .............................. 2
`
`Swenson discloses deep flow inspection, not deep
`packet inspection or the claimed controller. .......................... 7
`
`A POSITA would not combine/adapt Lin and
`Swenson to practice the claimed controller. ......................... 11
`
`Lin does not teach sending the packet to the second
`entity or a different entity responsive to a single
`criterion. ................................................................................... 16
`
`B. Ground 2: Shieh and Swenson do not render the claims
`obvious ................................................................................................ 20
`
`C. Claims 3-5 ........................................................................................... 22
`
`D. Claim 6 ................................................................................................ 23
`
`E.
`
`Claim 7 ................................................................................................ 25
`
`F.
`
`Claim 16 .............................................................................................. 26
`
`G. Claim 30 .............................................................................................. 27
`
`IV. CONCLUSION ............................................................................................28
`
`i
`
`
`
`TABLE OF AUTHORITIES
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`
`Page(s)
`
`Cases
`
`Arendi v. Apple,
`832 F.3d 1355 (Fed. Cir. 2016) .................................................................... 12, 27
`
`Ariosa Diagnostics v. Verinata Health, Inc.,
`805 F.3d 1359 (Fed. Cir. 2015) .............................................................. 19, 20, 24
`
`Aspex Eyewear, Inc. v. Marchon Eyewear, Inc.,
`672 F.3d 1335 (Fed. Cir. 2012) ...........................................................................25
`
`Cutsforth v. MotivePower,
`636 Fed.Appx. 575 (Fed. Cir. 2016) ....................................................................12
`
`DSS Tech. Mgmt. Inc. v. Apple Inc.,
`885 F.3d 1367 (Fed. Cir. 2018) ...........................................................................27
`
`In re Lee,
`277 F.3d 1338 (Fed. Cir. 2002) ...........................................................................12
`
`Innovention Toys LLC v. MGA Entertainment, Inc.,
`611 Fed.Appx. 693 (Fed. Cir. 2015) ....................................................................12
`
`Intelligent Bio-Sys., Inc. v. Illumina Cambridge Ltd.,
`821 F.3d 1359 (Fed. Cir. 2016) .......................................................... 9, 19, 20, 24
`
`International Seaway Trading Corp. v. Walgreens Corp.,
`528 F.3d 1233 (Fed. Cir. 2009) ...........................................................................10
`
`Medtronic, Inc. v. Teleflex Life Sci. Ltd. No.
`2022-1605, 2024 WL 1208642 (Fed. Cir. 2024) .................................................23
`
`Mformation Tech. v. Research in Motion Ltd.,
`764 F.3d 1392 (Fed. Cir. 2014) ...........................................................................22
`
`SAS Institute Inc. v. Iancu,
`138 S.Ct. 1348 (2018) ............................................................................................ 6
`
`ii
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`
`
`
`EXHIBIT LIST
`
`2001 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 46 (E.D. Tex., Jan. 15, 2023), First Amended Docket Control Order
`(“First Amended Docket Control Order”)
`2002 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 28 (E.D. Tex., Nov. 4, 2022), Notice of Compliance (“11-4-2022
`Notice of Compliance”)
`2003 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 47 (E.D. Tex., Jan. 19, 2023), Notice of Compliance (“1-19-2023
`Notice of Compliance”)
`2004 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 55 (E.D. Tex., Mar. 23, 2023), Defendant’s Motion To Stay
`2005 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 56 (E.D. Tex., Mar. 29, 2023), Order Denying Motion to Stay
`2006 United States District Courts National Judicial Caseload Profile For the
`12 Months Ending March 31, 2023 (available at
`https://www.uscourts.gov/sites/default/files/data_tables/fcms_na_distprof
`ile0331.2023.pdf) (“Judicial Caseload Statistics”)
`2007 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 50 (E.D. Tex., Feb. 3, 2023), Notice of Compliance (“2-3-2023
`Notice of Compliance”)
`2008 Reserved
`
`2010
`
`2009 December 11, 2008 Final Rejection (U.S. Appl. No. 11/123,801) (“’801
`Application Final Rejection”)
`July 28, 2008 Claim Amendments (U.S. Appl. No. 11/123,801) (“’801
`Application Pending Claims”)
`2011 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 59 (E.D. Tex., Mar. 30, 2023), Order Granting Motion To Amend
`Invalidity Contentions
`2012 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, Dkt.
`No. 61 (E.D. Tex., April 13, 2023), Order Granting Motion To Amend
`Invalidity Contentions
`“About Orckit-Corrigent: Executive Summary,” 2011
`
`2013
`
`iii
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`2014 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, (E.D.
`Tex., April 13, 2023), Defendant’s First Amended Invalidity Contentions
`(Cover Pleading)
`2015 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, (E.D.
`Tex., April 13, 2023), Defendant’s First Amended Invalidity Contentions
`(Exhibit A - ’904 Patent Charts)
`2016 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, (E.D.
`Tex., April 13, 2023), Defendant’s First Amended Invalidity Contentions
`(Exhibit B - ’821 Patent Charts)
`2017 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, (E.D.
`Tex., April 13, 2023), Defendant’s First Amended Invalidity Contentions
`(Exhibit C - ’740 Patent Charts)
`2018 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, (E.D.
`Tex., April 13, 2023), Defendant’s First Amended Invalidity Contentions
`(Exhibit D - ’111 Patent Charts)
`2019 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, (E.D.
`Tex., April 13, 2023), Defendant’s First Amended Invalidity Contentions
`(Exhibit E - Combination Charts)
`2020 Orckit Corporation v. Cisco Systems, Inc., Case No. 2:22-cv-00276, (E.D.
`Tex., April 13, 2023), Defendant’s First Amended Invalidity Contentions
`(SME Contentions)
`2021 United States District Courts National Judicial Caseload Profile For the
`12 Months Ending December 31, 2022 (available at
`https://www.uscourts.gov/sites/default/files/data_tables/fcms_na_distprof
`ile1231.2022.pdf) (“December 22 Judicial Caseload Statistics”)
`2022 Declaration of George Stamatopoulos in support of Patent Owner’s
`Motion for Pro Hac Vic Admission
`2023 Declaration of Michael Ng in support of Patent Owner’s Motion for Pro
`Hac Vice Admission
`2024 Stipulation of Dismissal
`
`2025 Declaration of Miguel Gomez
`
`2026 CV of Michael Gomez
`
`2027
`
`“DPI & DFI: A Malicious Behavior Detection Method Combining Deep
`Packet Inspection and Deep Flow Inspection” by Guo et al., Procedia
`Engineering 174, 1309-1314 (2017)
`
`
`
`iv
`
`
`
`Case IPR2023-00554
`Patent No. 10,652,111
`
`I.
`
`INTRODUCTION
`
`Petitioner asserts the challenged claims are obvious in view of Lin and
`
`Swenson (“Ground 1”), and Shieh and Swenson (“Ground 2”). The Board should
`
`reject both grounds.
`
`Lin and Swenson do not teach the claimed controller, which the Parties agree
`
`must at least be capable of controlling deep packet inspection (“DPI”): Lin
`
`outsources DPI, and its controller does not support it; Swenson does not disclose
`
`DPI (but teaches “deep flow inspection” (DFI)); and there is no evidence that a
`
`POSITA would combine the two references and adapt their combination to practice
`
`the claimed controller with a reasonable expectation of success. Further, Lin uses
`
`two criteria for claimed steps that Petitioner admits require a single criterion. The
`
`Board should discard Petitioner’s misleading assertions (e.g., that DFI amounts to
`
`DPI because flows are series of packets; and flow rules using different criteria
`
`operate “in tandem” to produce a single criterion) and reject Ground 1.
`
`The Board should also stand by the Institution Decision’s (Paper 8, “ID”)
`
`findings, which the Reply fails to address, and reject Ground 2.
`
`Lastly, because the prior art fails to render obvious the limitations in the
`
`dependent claims, the Board should confirm patentability of all challenged claims.
`
`
`
`II. CLAIM CONSTRUCTION
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`
`The Parties agree that the Board’s analysis remains the same under either
`
`proposed construction of “controller.” Paper 31 (“Reply”), 2. The Board thus need
`
`not construe “controller” for purposes of a final written decision so long as
`
`“controller” is understood to be capable of controlling DPI as required by both
`
`constructions. Paper 22 (“POR”), 17.
`
`III. THE CHALLENGED CLAIMS ARE PATENTABLE
`
`A. Ground 1: Lin and Swenson do not render the claims obvious.
`
`As explained below, Lin’s controller does not support DPI, Swenson does not
`
`disclose DPI, and there is no support that a POSITA would combine Lin and
`
`Swenson to practice the claimed controller.
`
`1.
`
`Lin does not teach the claimed controller.
`
`As Petitioner concedes, “Lin discusses a separate security service” for DPI
`
`(Reply, 4) and thus does not disclose the claimed controller.
`
`The record also disproves Petitioner’s assertion that a POSITA would have
`
`implemented Lin’s security service in the controller as “one of the limited number
`
`of design options.” Reply, 4, 7.
`
`First, Lin teaches using its controller exclusively for network administration
`
`and expressly outsources security (e.g., firewalls, “DPI”) to external “security
`
`
`
`2
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`vendors.” Ex1005, 3:11-24. The controller and security service are separate in all
`
`of Lin’s embodiments:
`
`
`
`Using the controller for security is thus not an “option” in Lin, which is directed to
`
`creating a “pipe” connecting a switch to a security service. Id., Title, Abstract.
`
`Second, as taught in the ’111 Patent, the only controller disclosed in Lin (the
`
`“OpenFlow” controller) (Ex1005, 3:45-52) does not support DPI:
`
`[T]he OpenFlow protocol allows addition of programmability to
`
`network nodes for … packets-processing operations under the
`
`control of the central controller, [but] OpenFlow does not
`
`support any mechanism to allow DPI of packets through the
`
`various networking layers as defined by the OSI model.
`
`Specifically, the current OpenFlow specification defines a
`
`
`
`3
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`
`mechanism to parse and extract only packet headers, in layer-2
`
`through layer-4, from packets flowing via the network nodes.
`
`The OpenFlow specification does not define or suggest any
`
`mechanism
`
`to extract non-generic, uncommon, and/or
`
`arbitrary data patterns contained in layer-4 to layer 7 fields. In
`
`addition, the OpenFlow specification does not define or suggest
`
`any mechanism to inspect or to extract content from packets
`
`belonging to a specific flow or session. This is a major limitation
`
`as it would not require inspection of the packet for the purpose
`
`of identification of, for example, security threats detection.
`
`Ex1001, 1:50-67.2 A POSITA would thus need a separate security service for DPI
`
`and could not opt to use Lin’s controller. See Ex2025, ¶¶52-55.3
`
`Third, Petitioner incorrectly asserts that Mr. Gomez’s opinion that “security
`
`services were not normally combined with a controller” and that doing so “would be
`
`
`
`2 Unless otherwise noted all emphases are added.
`
`3 Petitioner argues that the security service “may share certain common technical
`
`characteristics with the controller” (e.g., connections, etc.), and packets must be
`
`routed to the security service. Reply, 4-6. These commonplace characteristics do
`
`not show that a POSITA could support DPI in a controller, particularly since
`
`controllers like Lin’s did not support DPI. Ex2025, ¶54-55.
`
`
`
`4
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`prohibitively expensive to implement as part of the controller” is unsupported.
`
`Ex2025, ¶55; Reply, 6-7. For example, the ’111 patent explains that using the
`
`controller for DPI was known to be inefficient, costly, and problematic, as of the
`
`priority date:
`
`The straightforward approach of routing all traffic … to the
`
`central controller introduces some significant drawbacks, such
`
`as increased end-to-end traffic delays between the client and
`
`the server; overflowing the controller capability to perform
`
`other networking functions; and a single point of failure for
`
`the re-routed traffic. Therefore, it would be advantageous to
`
`provide a solution that overcomes the deficiencies noted above
`
`and allow efficient DPI in SDNs.
`
`Ex1001, 2:1-10. Accordingly, contrary to Petitioner’s assertion that there is no such
`
`evidence (Reply, 6-7)—and consistent with Mr. Gomez’s testimony—the record is
`
`clear that controllers did not support DPI as of the priority date and using them for
`
`DPI against the conventional wisdom was inefficient and costly. The record,
`
`including Lin (which discloses no rationale for adapting its controller to support
`
`DPI), thus contradicts Petitioner’s contentions that using the controller for DPI was
`
`straightforward or obvious.
`
`Petitioner asserts that a POSITA would find it trivial to integrate Lin’s security
`
`service in the controller as “one component” because Swenson uses conventional
`
`
`
`5
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`components for security. Reply, 6-7. To the extent that Petitioner is attempting to
`
`construe “controller” as “one component” for performing DPI and controlling a
`
`network, the Board should reject such a construction as untimely because it was not
`
`raised in the Petition. SAS Institute Inc. v. Iancu, 138 S.Ct. 1348, 1351 (2018).
`
`Further, as discussed below, Swenson does not disclose DPI, let alone in a controller
`
`with conventional components.
`
`Petitioner also incorrectly asserts that the problems disclosed in the ’111
`
`patent with respect to using the controller for DPI did not plague Lin because it
`
`routed only “specific packets to the security device.” Reply, 5-6. Lin expressly
`
`discloses (i) that “[r]e-injecting packets that pass inspection consume[s] bandwidth”
`
`and (ii) mitigation techniques for this issue. Ex1005, 7:10-23. A POSITA would
`
`thus understand that Lin faced the same constraints and impediments to using the
`
`controller for DPI as disclosed in the ’111 patent. Further, a POSITA would
`
`understand that skipping DPI with Lin’s “bypass flow rules” was the exception to
`
`redirecting packets for inspection, not the default rule, as Petitioner asserts. Id.,
`
`7:23-27. In any event, Lin does not disclose that the “bypass flow rules” make it
`
`possible, let alone efficient, to use the controller for DPI. Nor does Lin disclose the
`
`use of only one security device, such that the security device would be a “single
`
`point of failure” just like the controller as Petitioner asserts. Reply, 6. The record
`
`
`
`6
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`thus contradicts Petitioner’s assertion that a POSITA would not expect Lin to face
`
`the problems described in the ’111 patent.
`
`Accordingly, (including for reasons pertaining to Swenson infra) Lin does not
`
`teach or render obvious the claimed controller.
`
`2.
`
`Swenson discloses deep flow inspection, not deep packet
`inspection or the claimed controller.
`
`Petitioner’s contention that Swenson teaches the claimed controller boils
`
`down to whether Deep Packet Inspection (DPI)— i.e., the well-known technique in
`
`the ’111 patent that Swenson nowhere mentions—is the same as Deep Flow
`
`Inspection (DFI), a different data monitoring technique discussed in Swenson. It is
`
`not.
`
`The record contradicts Petitioner’s assertion that DFI is the same as DPI
`
`because a “flow” is a series of packets, and Swenson discloses inspecting the
`
`“response payload of a HTTP packet.” Reply, 7-8.
`
`As a threshold matter, though a flow is a series of packets, inspecting a flow
`
`is not the same as inspecting individual packets. Petitioner does not dispute Mr.
`
`Gomez’s testimony that DPI was a well-known technique for performing a
`
`“thorough inspection process” directed to the payload of a packet, “capable of
`
`looking at Layer 2 and beyond Layer 3 of the OSI model .. up to Layer 7,” and
`
`“offer[ing] control of network traffic that goes beyond classification of packets.”
`
`
`
`7
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`Owing to its thoroughness, the fine-grain DPI had limitations, including “less
`
`visibility into the overall traffic patterns of networks” and higher processing power
`
`requirements. Ex2025, ¶¶57-59.
`
`Mr. Gomez also testified that: (i) DFI is used to inspect flows (rather than
`
`individual packets) to glean network information (including IP addresses, ports,
`
`protocol types, traffic metrics, and state information) that is not conveyed by or
`
`ascertainable by inspecting individual packets, (ii) the two techniques have different
`
`capabilities and technical challenges, and (iii) Swenson’s disclosure of DFI for
`
`among other things “collection of statistic information” and bandwidth monitoring
`
`reinforced a POSITA’s understanding that DFI was used to inspect flows, not
`
`individual packets. Id. ¶60-65.
`
`His testimony that DPI and DFI are different is further supported by at least
`
`one academic article discussing combining the “fine-grain DPI with the coarse-grain
`
`DFI” in a single method for “malicious behavior detection,” thus demonstrating that
`
`the two are different. Ex1016, 106; Ex2027 (discussing DFI and DPI as two
`
`different techniques).
`
`Mr. Gomez’s testimony is thus supported by: (i) the different terms of art used
`
`for the two techniques, (ii) Swenson’s disclosure of DFI functionalities that are not
`
`performed with DPI, (iii) Lin’s disclosure of outsourcing DPI to a dedicated security
`
`
`
`8
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`service, (iv) extrinsic evidence distinguishing between DPI and DFI, and (iv) his
`
`own experience.
`
`In contrast, Petitioner asserts (incorrectly and transparently oversimplifying
`
`things) that a “flow is a series of packets,” and Swenson’s DFI includes inspection
`
`of a HTTP request/response payload. Reply, 7-11. The Board should reject this
`
`assertion.
`
`First, that a flow is a series of packets only proves that a POSITA would know
`
`that (i) a flow is not an individual packet and (ii) Swenson’s use of coarse-grained
`
`DFI, as opposed to fine-grained DPI, is directed to high-level information about
`
`traffic metrics, not deep packet inspection.
`
`Second, Swenson nowhere teaches that a HTTP request/response payload is
`
`an individual packet payload. The Board should reject Petitioner’s assertion that
`
`such a request can be embodied in a single packet. Reply at 11. As a threshold
`
`matter, the Petition did not raise this argument, and it is thus untimely. Reply, 13
`
`(raising argument for first time). Intelligent Bio-Sys., Inc. v. Illumina Cambridge
`
`Ltd., 821 F.3d 1359, 1367 (Fed. Cir. 2016) (declining to address new reply
`
`arguments and emphasizing “importance that petitioners … adhere to the
`
`requirement that the initial petition identify ‘with particularity’ the ‘evidence that
`
`supports the grounds for the challenge to each claim”). Moreover, Swenson does
`
`
`
`9
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`not teach such an embodiment; and Petitioner has failed to argue—let alone provide
`
`evidence showing—that a POSITA would understand such a single-packet HTTP
`
`response/request embodiment is possible. Obviousness is determined from the
`
`perspective of a POSITA. E.g., International Seaway Trading Corp. v. Walgreens
`
`Corp., 528 F.3d 1233, 1244 (Fed. Cir. 2009) (“Obviousness, like anticipation,
`
`requires courts to consider the perspective of the ordinary observer.”). Swenson
`
`does not disclose a single-packet embodiment, and there is no evidence that a
`
`POSITA would understand Swenson to disclose one. The Board should thus reject
`
`Petitioner’s assertion. In any event, a POSITA would understand HTTP
`
`requests/responses to refer to flows, not individual packets. Ex2025, ¶69.
`
`Third, even assuming a POSITA understood a HTTP request/response could
`
`be embodied in a single packet, Swenson’s inspection still would not amount to DPI.
`
`Mr. Gomez testified and the ’111 patent teaches that DPI has a number of
`
`characteristics and capabilities beyond inspecting a single packet payload. Id. ¶¶58-
`
`59; Ex1001, 1:21-29. In contrast, Swenson discloses inspecting an HTTP
`
`request/response as a limited precursor step for performing DFI. Ex1007, ¶[0065]
`
`(describing “send[ing] … ICAP request message … comprising the HTTP GET
`
`request header and a portion of the response payload to the network controller 140,
`
`which inspects the message to determine whether to monitor the flow or optimize
`
`
`
`10
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`the video.”). Thus, even if Swenson disclosed inspecting a single packet payload (it
`
`does not), a POSITA understand this is not DPI.4
`
`Fourth, Swenson consistently uses “payload” in connection with flows, not
`
`single packets and teaches “selectively inspect[ing] user flows of interest” in contrast
`
`to “conventional inline TCP throughput monitoring devices that monitor every
`
`single data packet transmitted and received[.]” Ex1007, ¶¶[0028], [0061], [0064],
`
`[0078]. A POSITA would thus understand that Swenson’s DFI inspects flow
`
`information, not individual packets.
`
`Accordingly, Swenson does not teach or render obvious the claimed
`
`controller.
`
`3.
`
`A POSITA would not combine/adapt Lin and Swenson to
`practice the claimed controller.
`
`The Federal Circuit has held that proving obviousness requires articulating a
`
`motivation for which a POSITA would combine prior art references, supported by
`
`adequate evidence, and an express and rational connection of the POSITA’s
`
`
`
`4 Petitioner has not proposed construing DPI, let alone construing it as simply
`
`inspecting a packet payload, nor contended that a POSITA would understand DPI as
`
`the inspection of a packet payload.
`
`
`
`11
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`motivation with the evidence presented. See, In re Lee, 277 F.3d 1338, 1343-45
`
`(Fed. Cir. 2002) (conclusory statements are insufficient); Cutsforth v. MotivePower,
`
`636 Fed.Appx. 575, 578 (Fed. Cir. 2016) (must positively explain motivation); and
`
`Arendi v. Apple, 832 F.3d 1355, 1361-62 (Fed. Cir. 2016) (“common knowledge or
`
`common sense” insufficient to find motivation). Petitioner’s contention that a POSA
`
`would combine Lin and Swenson to increase efficiency and conservation in
`
`operating network systems fails to meet this standard. Reply, 11.
`
`Petitioner asserts that the Lin/Swenson combination would have made
`
`“common sense” to a POSITA because of these purported benefits but fails to
`
`articulate or provide evidence showing why a POSITA would (i) understand that
`
`combining Lin and Swenson would increase efficiency and resource conservation
`
`and (ii) reasonably expect that it could successfully combine Lin and Swenson to
`
`practice the claimed controller. Innovention Toys LLC v. MGA Entertainment, Inc.,
`
`611 Fed.Appx. 693, 698 (Fed. Cir. 2015) (“the testimony gives little reason that a
`
`person of ordinary skill in the art—with [the prior art references] hanging
`
`somewhere on the figurative wall of pertinent art, as we previously held—would
`
`have defined a problem to be solved in such a way as to provide a motivation to pick
`
`out those references for combination.”)
`
`
`
`12
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`The crux of Petitioner’s argument is that a POSITA would have found it
`
`obvious to implement security processing in Lin’s controller in light of Swenson
`
`because (a) Lin and Swenson share generic similarities (e.g., a central controller,
`
`packet routing, and different forms of data inspection) and (b) determining “which
`
`packets to redirect … increases the efficient operation of a computer network.”
`
`Reply, 11 (citing Paper 1 (“Petition”), 20-25). There are several problems with this
`
`argument.
`
`First, even assuming that Swenson taught DPI (it does not), there is no
`
`evidence (including in Swenson) that using the controller for DPI is efficient.
`
`Swenson teaches against sending packets to the controller and instead discloses
`
`selective flow monitoring. Ex1007, ¶[0028] (“In contrast to conventional inline TCP
`
`throughput monitoring devices that monitor every single data packets transmitted
`
`and received, the network controller 140 is an “out-of-band” computer server that
`
`interfaces with the steering device 130 to selectively inspect user flows of
`
`interest.”). Likewise, Lin teaches outsourcing DPI. Supra, III.A.1. Petitioner’s
`
`argument that combining Lin/Swenson would produce efficiency thus lacks
`
`evidentiary support (including as to why a POSITA would believe that this specific
`
`combination would be efficient) and fails for this reason.
`
`
`
`13
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`Second, Lin teaches (i) a controller that does not support DPI, (ii) outsourcing
`
`DPI, (iii) that transmitting packets for inspection consumes bandwidth, and (iv)
`
`using optimization techniques to avoid burdening the network with packet inspection
`
`(e.g., locally copying packets and sending only an index of inspection results).
`
`Supra, III.A.1; Ex1005, 7:10-22. Contrary to Petitioner’s assertion, a POSITA
`
`would thus understand that sending packets to the controller or using the controller
`
`for DPI is inefficient.
`
`Third, Swenson does not disclose DPI (or the claimed controller), and Lin’s
`
`controller does not support DPI. Supra III.A.1-2. A POSITA would thus understand
`
`that practicing the claimed controller would require adapting the combined
`
`Lin/Swenson controller to include functionalities beyond those found in prior art
`
`controllers. There is no evidence that a POSITA would be motivated to make or
`
`adapt such a combination or could reasonably expect to do so successfully.
`
`The remainder of Petitioner’s assertions (Reply, 12-13) likewise fail.
`
`First, “certain network flows” are not “directed to the controller for DPI”
`
`(Reply, 12), since Swenson teaches DFI—not DPI—and more broadly against
`
`monitoring individual packets. Supra, 12; Ex1007, ¶[0028]. Second, there is no
`
`basis the assertion that “a POSA would have understood that Swenson could analyze
`
`packets for a security function” (Reply, 12) because Swenson teaches against
`
`
`
`14
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`individual packet monitoring and in its sole mention of security functions (which
`
`Swenson does not describe Ex1007, ¶[0039]), Swenson mentions only
`
`“conventional components” that—as discussed with respect to Lin—did not support
`
`DPI in the controller. Ex1007, ¶[0039]; supra at III.A.1-2. Third, contrary to
`
`Petitioner’s assertion that there is no evidence DPI is more taxing than DFI (Reply,
`
`12), Mr. Gomez explained why DFI is less taxing on the controller (e.g., Ex2025,
`
`¶¶59, 62 (DPI is a detailed inspection technique that “requires significant processing
`
`power and may struggle with high-bandwidth networks or encrypted traffic” while
`
`DFI “focuses on broader patterns”)), consistent with Lin’s teaching about bandwidth
`
`consumption (Ex1005, 7:10-22) and Swenson’s teaching that the controller
`
`“selectively inspect[s] user flows” rather than individual packets. Ex1007, ¶[0028].
`
`Further, Swenson and Lin do not compare DPI and DFI with respect to the controller
`
`(Reply, 12) because neither performs DPI at the controller, and there is no evidence
`
`that Swenson’s DFI (unlike DPI) is “taxing” on the controller. Fourth, Petitioner’s
`
`untimely assertion that a HTTP request/response can be embodied in a single packet
`
`is addressed supra at III.A.2. Fifth, Petitioner’s assertion that Swenson’s
`
`conventional security components are part of the controller (Reply, 13) fails because
`
`conventional controllers at the time of the invention (e.g., Lin) could not support
`
`DPI (supra, III.A.1); thus, Swenson’s mention of “conventional components” in a
`
`
`
`15
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`controller does not teach the claimed controller. Sixth, Petitioner’s assertion that
`
`prior art “drawbacks” did not apply to Lin is addressed supra at III.A.1. And,
`
`seventh, Petitioner’s assertion that a POSITA could expect to successfully place “the
`
`security service in the controller just as if it was a separate module” fails because,
`
`as discussed supra at III.A.1, it is predicated upon an untimely new construction and,
`
`in any event, contrary to the record (e.g., Swenson does not perform DPI, Lin’s
`
`controller does not support DPI, and the ’111 patent teaches that state-of-the-art
`
`OpenFlow controllers did not support DPI, supra, III.A.1-2).
`
`Accordingly, the Board should reject Petitioner’s contention that a POSITA
`
`would be motivated to combine Lin and Swenson with a reasonable expectation of
`
`success.
`
`4.
`
`Lin does not teach sending the packet to the second entity or
`a different entity responsive to a single criterion.
`
`Claim 1 recites: “responsive to the packet not satisfying the criterion,
`
`sending…the packet to the second entity” [1.5], and “responsive to the packet
`
`satisfying the criterion, sending the packet … to an entity … other than the second
`
`entity” [1.6]. Petition, 30-32. Petitioner does not dispute that both claimed steps are
`
`responsive to the same criterion.
`
`In contrast, Lin on its face teaches two criteria: one criterion for sending a
`
`packet to a second entity, and a different criterion for sending a packet to another
`
`
`
`16
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`entity. POR, 39-42. Petitioner admits that Lin’s Table 3 a “bypass flow rule” and a
`
`“redirect flow rule” for performing two functions: bypassing the security service or
`
`redirecting to the security service. The POR does not assert that these rules are
`
`themselves criteria (Reply, 15) but explains that each rule uses a different criterion.
`
`Petitioner admits that Lin’s two rules contain packet-applicable criteria. Id.
`
`(“instead the flow rules contain packet-applicable criterion [sic]”). The criteria in
`
`Lin’s two rules are shown in Petitioner’s annotated Table 3:
`
`
`
`
`
`
`
`17
`
`
`
`
`Case IPR2023-00554
`Patent 10,652,111
`
`The top two rows redirect packets to the security service if a first criterion is satisfied
`
`(port 80 is the destination/source port); and the bottom two rows bypass the security
`
`service if a second criterion is satisfied (no TCP source or destination port indicated).
`
`There is no evidence that a POSITA would understand these two criteria are one and
`
`the same criterion. Indeed, as discussed in the POR (and not addressed in the
`
`Reply), Lin does not teach how a packet is sent if either the bypass or redirect flow
`
`rule criteria are both not satisfied. POR, 41.
`
`In any event, Petitioner admits that Lin uses more than one condition to route
`
`its packets. Reply, 15-16 (“these conditions determine whether or not the packet is
`
`forwarded to the se