throbber
Case IPR2023-00554
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket