Centripetal Networks, Inc.,

Patent Trials and Appeals Board

Feb 16, 2022

IPR2021-01151 (P.T.A.B. Feb. 16, 2022)

Trials@uspto.gov Paper 10 571-272-7822 Entered: February 16, 2022 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD PALO ALTO NETWORKS, INC., Petitioner, v. CENTRIPETAL NETWORKS, INC., Patent Owner. IPR2021-01151 Patent 10,659,573 B2 Before BRYAN F. MOORE, STACEY G. WHITE, and AARON W. MOORE, Administrative Patent Judges. WHITE, Administrative Patent Judge. DECISION Denying Institution of Inter Partes Review 35 U.S.C. § 314 IPR2021-01151 Patent 10,659,573 B2 2 I. INTRODUCTION Palo Alto Networks, Inc. (“Petitioner”) filed a Petition requesting an inter partes review of claims 1-24 (“the challenged claims”) of U.S. Patent No. 10,659,573 B2 (Ex. 1001, “the ’573 patent”). Paper 2 (“Pet.”). Centripetal Networks, Inc. (“Patent Owner”) filed a Preliminary Response. Paper 6 (“Preliminary Response” or “Prelim. Resp.”). With Board authorization (see Ex. 2016), Petitioner filed a Preliminary Reply (Paper 7, “Prelim. Reply”), and Patent Owner filed a Preliminary Sur-Reply (Paper 8 (“Prelim. Sur-Reply”). Under 35 U.S.C. § 314(a), an inter partes review may not be instituted unless the information presented in the petition “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.” The following findings of fact and conclusions of law are not final, but are made for the sole purpose of determining whether Petitioner meets the threshold for initiating review. For the reasons stated below, we determine that Petitioner has not established a reasonable likelihood that it would prevail with respect to at least one claim. We hereby do not institute an inter partes review as to the challenged claims of the ’573 patent. A. Real Parties-in-Interest Petitioner identifies itself as the sole real party-in-interest. Pet. 2. Patent Owner identifies itself as the sole real party-in-interest. Paper 3, 1. B. Related Matters The parties indicate that the ’573 patent is involved in Centripetal Networks, Inc. v. Palo Alto Networks, Inc., No. 2:21-cv-00137 (E.D. Va., filed Mar. 12, 2021). Pet. 2; Paper 3, 1. IPR2021-01151 Patent 10,659,573 B2 3 C. The ’573 Patent The ’573 patent is titled “Correlating Packets in Communications Networks.” Ex. 1001, code (54). The ’573 patent describes that network devices may alter packets and this alteration “may potentially obfuscate the flow with which a particular packet is associated from other network devices.” Id. at 1:27-31. The ’573 patent explains that its methods and systems determine packets associated with particular flows between networks-including flows that may have been obfuscated “without malice,” or “with malicious intent” by “a malicious entity . . . attempt[ing] to obfuscate, spoof, or proxy for the identity or location of [a] host [] (e.g., network device(s) [] may be employed as part of a man-in-the-middle attack).” Id. at 1:58-63, 6:7-12. As such, there is a need to be able to correlate the sent and received packets. Id. at 1:31-32. Figure 1 of the ’573 patent is reproduced below. Figure 1 illustrates environment 100 for correlating packets in communications networks. Id. at 2:11-13, 2:40-44. Environment 100 IPR2021-01151 Patent 10,659,573 B2 4 includes networks 102, 104, and 106, and hosts, network devices, and tap devices included in the networks. Id. at 2:43-3:5. For example, network 102 includes hosts 108, 110, and 112, and network 104 includes hosts 114, 116, and 118. Id. at 2:53-56. The hosts may be one or more computing or network devices, or a communication interface. Id. at 2:56-61. Network 102 also includes network device(s) 120 (e.g., servers, routers, gateways, switches, access points), and network 104 includes network device(s) 122. Id. at 2:61-67. Network device(s) 120 interface hosts 108, 110, and 112 with network 106, and network device(s) 122 interface hosts 114, 116, and 118 with network 106. Id. at 2:66-3:2. Network 104 further includes tap devices 124 and 126, and packet correlator 128. Id. at 3:3-4. Packet correlator 128 includes a memory 130 that comprises program module(s) 138, rule(s) 140, and log(s) 142. Id. at 3:9-17. Rule(s) 140 may be generated by packet correlator 128 and are configured to cause tap device(s) 124 and 126 to identify packets meeting criteria specified by the rule(s) 140 and to perform one or more functions specified by the rule(s) 140 on the identified packets (e.g., forward or route the packets toward their respective destinations, drop the packets, log information associated with or contained in the packets, or copy the packets). Id. at 3:21-29. Tap devices 124 and 126 may include one or more packet-filtering devices and may be provisioned with the rule(s) 140, which configure tap device(s) 124 and 126 to identify packets meeting criteria specified by rule(s) 140 and to communicate data associated with the identified packets to packet correlator 128, which utilizes the data to generate one or more log entries corresponding to the identified packets in log(s) 142. Id. at 3:29-37. IPR2021-01151 Patent 10,659,573 B2 5 Figure 4 of the ’573 patent is reproduced below. Figure 4 illustrates steps of the method for correlating packets in the communications networks shown in Figure 1. Id. at 14:1-3. Specifically, at step 402, a computing system (e.g., tap device 126) identifies packets (e.g., packets P1, P2, and P3, generated by host 114 and destined for host 108) received by a network device (e.g., network device 122 in Figure 1) from host 114 located in a first network. Id. at 3:55-58, 14:3-6. Tap device 126 may identify the packets P1, P2, and P3 by determining that the packets are destined for a network address associated with host 108 (e.g., based on network-layer information contained in their headers) and determining that the network address associated with host 108 is in the set of destination IPR2021-01151 Patent 10,659,573 B2 6 network addresses specified by the criteria included in rule(s) 140. Id. at 3:66-4:6. At step 404, packet correlator 128 generates log entries (e.g., log entries 306, 308, and 310) corresponding to the packets received by the network device. Id. at 14: 7-10. At step 406, tap device 124 identifies packets (e.g., packets P1', P2', and P3' generated by network device 122 to correspond to the packets P1, P2, and P3 received from host 114) transmitted by network device 122 to host 108 located in the second network. Id. at 5:6-24, 6:13-16, 14:10-13. Packets P1', P2', and P3' are generated by network device 122 by altering one or more aspects of packets P1, P2, and P3 in a way that obfuscates the association of the packets received from host 114 (P1, P2, and P3) with the corresponding packets generated by network device 122 (i.e., P1', P2', and P3'). Id. at 5:6-24. For example, network device 122 may be configured to perform network address translation (NAT) for network addresses associated with network 104 (e.g., network addresses associated with hosts 114, 116, and 118), when generating packets P1', P2', and P3'. Id. at 5:25-39. At step 408 in Figure 4, packet correlator 128 generates log entries (e.g., log entries 312, 314, and 316) corresponding to the packets (P1', P2', and P3') transmitted by network device 122. Id. at 6:36-49, 14:13-16. At step 410, packet correlator 128 correlates, based on the log entries (306, 308, 310) corresponding to the packets received by the network device (P1, P2, and P3) and the log entries (312, 314, and 316) corresponding to the packets transmitted by the network device (P1', P2', and P3'), the packets transmitted by the network device (P1', P2', and P3') with the packets received by the network device (P1, P2, P3), i.e., correlates P1' with P1, P2' with P2, and P3' with P3. Id. at 14:17-24. Packet correlation may be particularly performed IPR2021-01151 Patent 10,659,573 B2 7 for packets associated with specific hosts (e.g., a host associated with a malicious entity). Id. at 10:1-16. For example, the ’573 patent explains, packet correlator 128 may be configured to correlate packets destined for the network address associated with host 108 but not packets destined for the network address associated with host 110, and rule(s) 140 may be configured to cause tap devices 124 and 126 to generate log data for packets destined for the network address associated with host 108 but not for packets destined for the network address associated with host 110 (e.g., host 108 may be associated with a malicious entity or host 110 may be associated with a trusted entity). Id. at 10:7-16. Responsive to correlating packets transmitted by network device 122 with packets received by network device 122, packet correlator 128 determines a network address associated with a host (e.g., host 114) located in network 104 that is associated with a packet transmitted by network device 122. Id. at 12:59-13:1, Fig. 2C. Upon identifying host 114, packet correlator 128 may determine that host 114 has communicated with host 108, which is a malicious entity (or is associated with a malicious entity). Id. Packet correlator 128 then communicates message(s) to host 114, e.g., to notify a user of host 114 of the communication with the malicious entity. Id. Packet correlator 128 may also communicate one or more message(s) to host 116 (associated with an administrator of network 104), to notify the administrator of the communication of host 114 with the malicious entity. Id. Packet correlator 128 then generates or updates rule(s) 140 (e.g., generates one or more new rules or updates one or more existing rules) to configure tap devices 124 and 126 to identify and drop packets received from host 114. Id. at 13:19-23, Fig. 2D. Packet correlator 128 then IPR2021-01151 Patent 10,659,573 B2 8 provisions tap devices 124 and 126 with the rule(s) 140. Id. at 13:23-26. When host 114 next communicates one or more packets to other hosts (e.g., host 112 or host 118), tap device 126 identifies and drops the packets communicated by host 114. Id. at 13:25-32. In this way, spread of malware may be prevented. Id. at 13:37-38. More particularly, one or more of the communications between host 108 and 114 . . . may be indicative of malware installed by a computing device associated with host 108 (e.g., the malicious entity) on a computing device associated with host 114, and rule(s) 140 may be configured to prevent the spread of the malware. Id. at 13:32-39. D. Illustrative Claims Claims 1-24 are challenged in this Petition. Challenged claims 1, 9, and 17 are independent. Claims 2-8 depend from claim 1, claims 10-16 depend from claim 9, and claims 18-24 depend from claim 17. Claim 1 is illustrative of the claimed subject matter. 1. A method comprising: identifying, by a computing system, a plurality of packets received by a network device from a host located in a first network; generating, by the computing system, a first plurality of log entries corresponding to the plurality of packets received by the network device; identifying, by the computing system, a plurality of encrypted packets transmitted by the network device to a host located in a second network; generating, by the computing system, a second plurality of log entries corresponding to the plurality of encrypted packets transmitted by the network device; correlating, by the computing system and based on the first plurality of log entries corresponding to the plurality of packets received by the network device and the second IPR2021-01151 Patent 10,659,573 B2 9 plurality of log entries corresponding to the plurality of encrypted packets transmitted by the network device, the plurality of encrypted packets transmitted by the network device with the plurality of packets received by the network device; and responsive to the correlating of the plurality of encrypted packets transmitted by the network device with the plurality of packets received by the network device: generating, by the computing system and based on the correlating, one or more rules configured to identify packets received from the host located in the first network; and provisioning a packet-filtering device with the one or more rules configured to identify packets received from the host located in the first network. Ex. 1001, 15:25-55. E. Asserted Grounds of Unpatentability Petitioner asserts the following grounds of unpatentability (Pet. 5): Claims Challenged 35 U.S.C. § Reference(s)/Basis 1, 7-9, 15-17, 23-24 103 Paxton,1 Sutton,2 Deschênes 3 2, 10, 18 103 Paxton, Sutton, Deschênes, McDonald4 3-6, 11-14, 19-22 103 Paxton, Sutton, Deschênes, Ivershen5 1 U.S. Pat. Application Publication No. 2014/0280778 A1 (published Sept. 18, 2014) (Ex. 1004). 2 U.S. Patent No. 8,413,238 B1 (issued Apr. 2, 2013) (Ex. 1007). 3 U.S. Patent Application Publication No. 2013/0262655 A1 (published Oct. 3, 2013) (Ex. 1008). 4 European Patent Application Publication EP 2 482 522 A1 (published Aug. 1, 2012) (Ex. 1009). 5 U.S. Patent No. 8,219,675 B2 (issued July 10, 2012) (Ex. 1005). IPR2021-01151 Patent 10,659,573 B2 10 Petitioner’s challenges are supported by the Declaration of Dr. Robert Akl (Ex. 1003). II. ANALYSIS A. Level of Ordinary Skill in the Art In order to determine whether an invention would have been obvious at the time the application was filed, we consider the level of ordinary skill in the pertinent art at critical time. Graham v. John Deere Co., 383 U.S. 1, 17 (1966); 35 U.S.C. § 103 (“claimed invention as a whole would have been obvious before the effective filing date of the claimed invention). The resolution of this question is important because it allows us to “maintain[] objectivity in the obviousness inquiry.” Ryko Mfg. Co. v. Nu-Star, Inc., 950 F.2d 714, 718 (Fed. Cir. 1991). In assessing the level of ordinary skill in the art, various factors may be considered, including the “type of problems encountered in the art; prior art solutions to those problems; rapidity with which innovations are made; sophistication of the technology; and educational level of active workers in the field.” In re GPAC, Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995) (quotation omitted). Generally, it is easier to establish obviousness under a higher level of ordinary skill in the art. Innovention Toys, LLC v. MGA Entm’t, Inc., 637 F.3d 1314, 1323 (Fed. Cir. 2011) (“A less sophisticated level of skill generally favors a determination of nonobviousness . . . while a higher level of skill favors the reverse.”). Petitioner asserts that a person of ordinary skill in the art had a bachelor’s degree in electrical engineering, computer engineering, computer science, or a related field, and approximately 2-3 years of experience in the design or development of telecommunication systems, or the equivalent. IPR2021-01151 Patent 10,659,573 B2 11 Additional graduate education could substitute for professional experience, or significant experience in the field could substitute for formal education. Pet. 13 (citing Ex. 1003 ¶¶ 18-20). At this time, Patent Owner does not offer an alternative definition for the person of ordinary skill in the art (see generally Prelim. Resp.). Based on this record, we adopt Petitioner’s articulation of the level of skill in the art, which is consistent with the ’573 patent and the asserted prior art, and we apply it in our obviousness evaluations below. B. Claim Construction In an inter partes review based on a petition filed on or after November 13, 2018, a patent claim shall be construed using the same claim construction standard that would be used in a civil action under 35 U.S.C. § 282(b). 37 C.F.R. § 42.100(b) (as amended Oct. 11, 2018).6 This rule adopts the same claim construction standard used by Article III federal courts, which follow Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc), and its progeny. Under this standard, claim language generally is given its “ordinary and customary meaning,” which is the meaning the term would have to a person of ordinary skill at the time of the invention, in the context of the entire patent including the specification. See Phillips, 415 F.3d at 1312-13. Petitioner “believes no terms require construction.” Pet. 13-14. Patent Owner submits that, at this stage, “no express construction of any term is required to resolve any controversy in this proceeding.” Prelim. 6 See Changes to the Claim Construction Standard for Interpreting Claims in Trial Proceedings Before the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018) (final rule). IPR2021-01151 Patent 10,659,573 B2 12 Resp. 14. Only terms that are in controversy need to be construed, and construction is required only to the extent necessary to resolve the controversy. Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999). For purposes of this Decision, we determine that no claim terms require an express construction at this time. C. Overview of the Asserted Prior Art 1. Paxton (Exhibit 1004) Paxton is titled “Tracking Network Packets Across Translational Boundaries,” and “relates generally to identifying network packets, and more particularly, to determining the identity of network packets as they traverse boundaries that perform Network Address Translation (NAT).” Ex. 1004, code (54), ¶ 2. Paxton’s method for tracking network packets (i) calculates a first hash of a packet application layer payload at an inside sensor before a boundary located between a client and a server, (ii) stores a first hash data record at a device that has direct access to the inside sensor, (iii) calculates a second hash of the packet application layer payload at an outside sensor after the boundary, (iv) stores a second hash data record at a device that has direct access to the outside sensor, (v) transmits the packet from the client to the server, or from the server to the client, and (vi) determines whether the first hash data record and the second hash data record match. Id., code (57). The first hash data record and second hash data record may include a hash value, an IP address, and a timestamp. Id. Paxton explains that the ability to identify the true source of a packet transmission through a boundary can provide significant benefits to network security-e.g., by enabling identification of nodes that are infected with IPR2021-01151 Patent 10,659,573 B2 13 malicious content, and by enabling attribution of malicious activity sensed at the edge of a network back to its original source. Id. ¶ 30. Figure 1 of Paxton is reproduced below. Figure 1, reproduced above, shows system diagram 100 for tracking packets across translation boundaries. Id. ¶¶ 11, 15. Packets are sent from client 105 across boundary 110 to server 115. Id. ¶ 16. When a packet is transmitted from client 105, inside sensor 120 calculates a hash, e.g., an MD5 algorithm hash, of the application layer payload, and stores it along with the network layer header. Id. ¶ 17. After the packet traverses boundary 110, outside sensor 125 calculates a hash of the payload along with the header data of the packet. Id. Inside sensor 120 and outside sensor 125 can be two commodity servers running full packet capture, with inside sensor 120 passively recording traffic on client 105 network before the contents are altered by the boundary, and outside sensor 125 passively recording traffic externally after it has been modified by the boundary. Id. ¶ 18. Paxton explains that payloads can be matched based on at least three criteria (hash, time, and IP address), such that when an identical hash is observed on outside sensor 125 and inside sensor 120, there is a high probability that the hashes belong to the same payload. Id. ¶ 21. Hashes from inside sensor 120 and outside sensor 125 can be matched via a first-in-first-out queue based on IPR2021-01151 Patent 10,659,573 B2 14 recorded timestamps in the first hash data record and second hash data record. Id. ¶ 22. For example, after a hash is observed on the outside, the closest matching hash (with respect to the timestamp) on the inside can be identified as the corresponding match, and the combination of identifiable inside and outside header data can serve as the identity of the packet. Id. Figure 3 of Paxton, reproduced below, is a diagram illustrating a first-in- first-out matching approach. Id. ¶¶ 13, 24. Figure 3, reproduced above, shows four packets that have been hashed by both inside sensor 120 and outside sensor 125, including two packets, 1 and 2, sent from both IP A and IP B (for a total of four packets). Id. ¶ 24. Figure 3 shows what happens when packets are sensed in a different order across boundaries. Id. In Figure 3, each of IP A and IP B sends two messages that are the same (IPA:Hash 1 and IPA:Hash 2 are equal, and IPB:Hash 1 and IPB:Hash 2 are equal). Id. The initial order of which the packets were sent from the original source was IP A:Hash 1, IP A:Hash 2, IP B:Hash 1, and IP B:Hash 2. Id. However, the order of which the packets were sensed by inside sensor 120 was IP B:Hash 2, IP A:Hash 2, IP A:Hash 1, and IP B:Hash 1, while the order of which the packets were sensed at outside sensor 125 was IP B:Hash 2, IP A:Hash 2, IP B:Hash 1, IP A:Hash 1. Id. Therefore, IP B:Hash 2 was the first message recorded in both inside IPR2021-01151 Patent 10,659,573 B2 15 sensor 120 and outside sensor 125, and even though this packet has the same hash value of IP B:Hash 1, since it was sensed first on both sides, the sensed packets can be matched together first. Id. ¶ 25. However, next packets IP A:Hash 1 and IP B: Hash 1 were sensed in a different order across inside sensor 120 and outside sensor 125. Id. ¶ 25. Since IP A:Hash 1 and IP B:Hash 1 have different hash values, the matching module does not consider them for matching; instead, the matching module finds the match at the next available matching hash, which was IP A:Hash 1. Id. The matching module can then conclude with the final match IP B:Hash 1. Id. Paxton explains that the system for matching cryptographically hashed payloads as described so far, assumes that the payloads sensed both inside and outside are identical. Id. ¶ 28. According to Paxton, if either payload has been altered (e.g., by non-transparent proxies that can make slight modifications to the payload to perform a media type transformation, protocol reduction, or anonymity filtering), the computed hash will not be the same, and therefore will not match. Id. Paxton explains that different classes of hashing techniques could be leveraged in order to account for slight variations in payload alterations. For example, fuzzy hashing may be able to match payloads that have been slightly altered, as in the case of non-transparent proxies or deep packet inspection platforms. Fuzzy hashing is similar to traditional cryptographic hashing; with the exception that it produces a result value that is reflective of how similar the original data is to the altered data. Id. ¶ 29. 2. Sutton (Exhibit 1007) Sutton is titled “Monitoring Darknet Access to Identify Malicious Activity,” and “relates to identification of potentially malicious activity IPR2021-01151 Patent 10,659,573 B2 16 based upon access attempts to darknet addresses.” Ex. 1007, code (57), 2:7- 10. Sutton discloses a technique of monitoring darknet access by: identifying a list of darknet addresses; monitoring communications originating from a protected network; comparing destination addresses of the monitored communications originating from the protected network to the list of darknet addresses; and, if a match is found between the destination addresses and the list of darknet addresses, providing notification of potential malicious activity originating from the protected network. Id. at 2:10-19. Figure 2 of Sutton is reproduced below. IPR2021-01151 Patent 10,659,573 B2 17 Figure 2, reproduced above, is a block diagram of distributed security system 100. Id. at 2:29-31, 2:42-43. Distributed security system 100 includes: one or more component processing nodes 110; an authority node 120; logging node 140; external systems 200 (an enterprise), 220 (a computer device), and 230 (a mobile device); and wide area network (WAN) 101, such as the Internet, connecting the nodes and the external systems. Id. at 5:6-43. Each processing node 110 stores: security policies 113 received from authority node 120; detection process filter 112 and/or threat data 114 to facilitate a decision of whether a content item should be processed for threat detection; processing node manager 118 that can manage each content item in accordance with security policy data 113, detection process filter 112, and/or threat data 114; and data inspection engines 116. Id. at 5:45- 6:17. Each processing node 110 monitors content items requested by or sent from external systems 200, 220 and 230. Id. at 5:47-50. Each data inspection engine 116 can be configured to perform a threat detection process to classify content items according to a threat classification for a corresponding threat. Id. at 6:3-22. For example, the data inspection engines can include: a virus scanner engine 116A that can classify a content item as infected or clean; a network URL filter 1168 that can classify a URL address as allowed or restricted; a data leakage protection (DLP) engine 116C that can identify a content item as secure or leaking; a dynamic content categorization (DCC) engine 116D that can classify a content item as passed or failed; and a PN darknet processing 116E operable to identify darknet addresses. Id. PN darknet processing 116E identifies darknet addresses of darknets (that malicious code, such as code performing automated scanning, IPR2021-01151 Patent 10,659,573 B2 18 attempts to access) and store the darknet addresses in a darknet address database 115. Id. at 1:51-57, 6:14-22. PN darknet processing 116E can also interrogate communications to determine whether the communication is associated with (e.g., destined to, or originating from) an address in the darknet address database 115. Id. at 6:18-22. Authority node (AN) 120 includes AN darknet processing 121 that identifies darknet address space and store a list of darknet addresses in darknet address store 125. Id. at 7:28-35. AN darknet processing 121 also can distribute the list of darknet addresses to processing node(s) 110. Id. Figure 4 of Sutton is reproduced below. Figure 4 of Sutton, reproduced above, illustrates a method for identifying malicious activity based upon darknet access. Id. at 2:34-35. A list of darknet addresses is compiled in step 410 by one or more authority nodes in conjunction with one or more processing nodes. Id. at 11:37-41. Once a list of darknet addresses is received from an authority node, processing node 110 can begin monitoring communications. Id. at 10:39-41. Processing IPR2021-01151 Patent 10,659,573 B2 19 node 110 inspects all or some communications for inclusion of a destination address that is included in the list of darknet addresses, and can identify communications that purport to originate from the darknet address space. Id. at 10:41-45. Communications are monitored in step 420 by one or more processing nodes. Id. at 12:25-35. The addresses associated with monitored communications in step 430 are compared to compiled darknet addresses, and if there is a match between destination addresses and the list of darknet addresses, the communication can be inferred to be indicative of malicious activity. Id. at 12:36-45. Optionally in step 440, the identified destination address from step 430 can be confirmed to be a darknet address by, for example, using a scanner associated with the processing node to send a connection request to that identified the destination address. Id. at 12:45-56. If a device responds to the connection request then the address is removed from the list of darknet address, but if no device responds then the address is identified as malicious. Id. Notification of potential malicious activity can be provided in step 450 by one or more processing nodes and/or by an authority node. Id. at 12:57-13:9. This notification can be provided to (i) an administrator of a protected enterprise network, (ii) a special purpose application operable to inspect a device for malicious program code and to remove malicious program code from the device, if found, or (iii) other processing nodes with instructions to provide filtering or detailed inspection of communications identified as similar (e.g., based upon an origination address). Id. The communication can be also flagged as potentially malicious. Id. Additionally, traffic may be automatically blocked, redirected or filtered based on predefined rules. Id. IPR2021-01151 Patent 10,659,573 B2 20 3. Deschênes (Exhibit 1008) Deschênes is titled “Monitoring Network Performance of Encrypted Communications,” and “relates to network performance, and more specifically to monitoring and analyzing the performance of communication between two network devices.” Ex. 1008, code (54), ¶ 1. Deschênes monitors encrypted communications sessions between a first computing device and a second computing device, derives, by a first probing device, timing information regarding an encrypted communications session, and transmits, from the first probing device to a second probing device, the derived timing information. Id., code (57). Deschênes explains that an encrypted communications session includes transmission of encrypted data objects between the first and second computing devices (e.g., a client computing device and a server computing device), with each of the respective encrypted portions including their respective encryption keys or security credentials. Id. ¶ 27, code (57). For example, communication between a server and a client may be encrypted via the Hypertext Transfer Protocol Secure (HTTPS) protocol which makes use of the Secure Sockets Layer and/or Transport Layer Security protocols to provide encrypted communication and secure identification between two networked devices. Id. ¶ 28. A probing device described by Deschênes is configured to monitor and analyze encrypted and unencrypted network communication, and generate metrics regarding the performance of the network communication between the client and the server. Id. ¶ 35. The probing device may include a traffic analyzer configured to analyze the monitored network communication and generate the metrics. Id. ¶ 41. The traffic analyzer may be configured “to match or correlate, as best it can, the IPR2021-01151 Patent 10,659,573 B2 21 two portions (e.g., server-side and client-side) of the network communication” using timing information. Id. ¶¶ 42, 46, 73. Other information, such as headers and portions of HTTPS transactions, or other definable portions of the encrypted traffic, may be used to examine the network communication. Id. ¶¶ 63, 66-67. 4. McDonald (Exhibit 1009) McDonald is titled “A Method and Apparatus for Identifier Correlation.” Ex. 1009, code (54). McDonald’s method of identifier correlation is performed in a communications network that includes an identifier translator for translating communications packet(s), wherein a packet that has passed through the identifier translator includes translated and untranslated identifiers. Ex. 1009, code (57). McDonald’s method includes: selecting a first packet prior to transmission through the identifier translator; selecting a second packet after transmission through the identifier translator which has at least one identifier that is the same as a corresponding identifier of the first packet; and correlating at least one identifier from the first packet, to a corresponding identifier of the second packet. Id. 5. Ivershen (Exhibit 1005) Ivershen is titled “System and Method for Correlating IP Flows Across Network Address Translation Firewalls.” Ex. 1005, code (54). Ivershen relates to “correlating packets in a telecommunications network and, more specifically, to correlating packets with address information that has been modified by a Network Address Translation (NAT) firewall.” Id. at 1:8-12. In Ivershen’s method, data packets are captured from a first interface using a monitor probe coupled to the first interface, and are IPR2021-01151 Patent 10,659,573 B2 22 correlated into a first group of session records, and for each of the first group of session records, a correlation key is created using data in one of the packets in the session record. Id., code (57). Data packets also are captured from a second interface using a monitor probe coupled to the second interface, and are correlated into a second group of session records, and for each of the second group of session records, a correlation key is created using data in one of the packets in the session record. Id. The correlation key for one of the first group is compared to the correlation keys for each of the second group of session records to identify session records with matching correlation keys. Id. D. Obviousness over Paxton, Sutton, and Deschênes Petitioner asserts that claims 1, 7-9, 15-17, 23, and 24 are unpatentable under § 103 as obvious over Paxton, Sutton, and Deschênes, citing the Declaration of Dr. Robert Akl for support. Pet. 5-6, 14-77 (citing Ex. 1003). For the reasons described below, we are not persuaded by Petitioner’s argument and evidence. 1. Independent Claims 1, 9, and 17 In relevant part, independent claim 1 recites “generating, by the computing system and based on the correlating, one or more rules configured to identify packets received from the host located in the first network” and “provisioning a packet-filtering device with the one or more rules configured to identify packets received from the host located in the first network” that are “responsive to the correlating of the plurality of encrypted packets transmitted by the network device with the plurality of packets received by the network device.” Ex. 1001, 15:46-55. Petitioner contends the combination of Paxton with Sutton teaches this step. Pet. 32- IPR2021-01151 Patent 10,659,573 B2 23 38 (citing Ex. 1004 ¶ 30; Ex. 1007, 3:1-27, 3:38-4:4, 10:60-11:18, 12:57- 13:14, 13:26-42, 14:29-57, 15:67-16:5, code (57), Fig. 2; Ex. 1003 ¶¶ 116- 124). Independent claims 9 and 17 recite substantially identical language7 and Petitioner relies on the same arguments and evidence for this portion of claims 1, 9, and 17. See id. at 49-50 (claim chart for limitation 9[g] directing us to claim chart for limitation 1[f]); id. at 54-55 (claim chart for claim 17[f] directing us to the claim chart for limitation 1[f]); see also Ex. 1003 ¶¶ 143, 153 (Dr. Akl’s testimony that limitations 9[g] and 17[f] are “substantially similar to limitation [1f]” and are obvious for “substantially the same reasons.”). Specifically, Petitioner asserts that Sutton discloses generating, by the computing system and based on the correlating, one or more rules configured to identify packets received from the host located in the first network (based on communications to a darknet address and identifying potential malicious code, filtering or blocking further communications from the host; preventing communications using rules; taking action to make such rules available) Pet. 34. Petitioner directs us to Sutton’s disclosure of “corrective action” that can be taken in the event of “potentially malicious activity.” Id. (quoting Ex. 1007, code (57)). Petitioner cites several examples of corrective action in Sutton including a disclosure of sending notifications to indicate that a device on the network is potentially infected with malicious code and “implement[ing] a rule preventing such devices from 7 Petitioner refers to these substantially identical claim terms as [1f], [9g], [17f]. See, e.g., Pet. 32-33, 49-50, 54-55. IPR2021-01151 Patent 10,659,573 B2 24 communicating with devices within the protected enterprise network.” See e.g., id. at 34-35 (citing Ex. 1007, 10:60-11:3). Sutton also describes that In some implementations, the threat classification can be reduced to a subset of categories e.g., violating, nonviolating, neutral, unknown. Based on the subset classification, a processing node 110 may allow distribution of the content item, preclude distribution of the content item, allow distribution of the content item after a cleaning process, or perform threat detection on the content item. Id. at 36 (quoting Ex. 1007, 3:1-23) (emphasis added). Petitioner further argues that one of ordinary skill in the art would have been motivated to modify Paxton’s computing system to, after the correlating, notify administrators of devices involved with the malicious activity . . . and generate rules to be provisioned to a packet-filtering device . . . and used for identifying, filtering, and/or blocking host devices’ future packet communications (e.g., as in claims [1f], [9g], [17f], 7, 15, 23), as taught by Sutton. Id. at 21. As such, Petitioner relies on Paxton’s teaching of a correlation that “is useful for network security,” but argues that “Paxton leaves, to a POSITA, remedial steps (e.g., uses of the correlation results), which are taught by Sutton.” Id. 22, 23. Patent Owner argues that Petitioner has failed to meet its burden with respect to this limitation for several reasons including that Petitioner’s “alleged rule generation and provisioning is responsive to detecting malicious activity, not ‘responsive to the correlating.’” Prelim. Resp. 27-28. On this record, we agree with Patent Owner. The claims require that “responsive to the correlating of . . . packets transmitted by the network device with . . . packets received by the network device: generating . . . based on the correlating, one or more rules.” We do not have sufficient IPR2021-01151 Patent 10,659,573 B2 25 argument or evidence to show that one of ordinary skill in the art would have found it obvious to generate these rules “based on” and “responsive to” the correlation of packets. Patent Owner directs us to an example in the ’573 specification in which a host obscures received packets before transmitting them on to the destination. Prelim. Resp. 29. According to Patent Owner, in this circumstance “correlating the packets received and transmitted by a network device can permit the discovery that a particular first host is communicating with a particular second host, a fact that may otherwise be obscured by an interposed network device.” Id. “Accordingly, the ’573 Patent discloses de- obfuscating the fact that two hosts are communicating with one another by correlating packets received and transmitted by a network device and then, responsive to the correlating, generating rules to identify packets received from one of the hosts, and provisioning a packet-filtering device with the rule(s).” Id. at 30. This example shows one way in which the generation of rules may be responsive to and based on the recited packet correlation. Petitioner’s arguments, however, do not persuade us that the proposed combination would have this relationship or any other relationship in which the rules would be generated responsive to and based on the correlation. Petitioner argues that Sutton describes “filtering or blocking further communications from the host” is done “based on communications to a darknet address and identifying potential malicious code.” Pet. 34. What is missing from Petitioner’s argument and evidence is how the relationship between Paxton’s asserted correlation and Sutton’s asserted rule generation would have been the same as the relationship contemplated by the claims. Sutton describes IPR2021-01151 Patent 10,659,573 B2 26 implementing rules to prevent certain malicious devices from communicating within a network (Ex. 1007, 11:1-3) and it discusses “filter[ing] based on predefined rules” (id. at 13:5-9). It is unclear why one of ordinary skill in the art would have based such rules on Paxton’s correlation rather than on Sutton’s list of darknet addresses. Dr. Akl’s testimony is insufficient to remedy this deficiency. Dr. Akl opines that A person of ordinary skill in the art would have recognized, based on Sutton’s disclosure, that for a computing system to block future communications from a device (e.g., blocking a device within a network from communicating to an outside darknet address), when the device had not been previously identified as having malicious communications and/or not previously blocked, data/rules would have been generated and provisioned on a boundary or other monitoring device to identify those communications from the blocked device[.] Ex. 1003 ¶ 123. This testimony, however, is insufficient to establish that the rules would have been generated based on the correlation. We understand Dr. Akl’s testimony to be that rules are generated because a device is communicating with an outside darknet address. Here again, the relationship between the correlation and the rule generation is not sufficiently explained. Dr. Akl testifies that “Paxton discloses that, as a result of a successful correlation, the identity of a packet (e.g., a source address) is determined.” Id. ¶ 119. As noted by Dr. Akl, Paxton discloses that finding the identity of a node “can provide a way to quickly identify nodes that are infected with malicious content.” Id. (quoting Ex. 1004 ¶ 30). Dr. Akl agrees with Petitioner’s assertion that Paxton does not describe “specific usage or remedial steps with respect to those correlations.” Id. ¶ 120. Dr. Akl attempts to combine the teachings of Paxton with Sutton by IPR2021-01151 Patent 10,659,573 B2 27 opining that an ordinarily skilled artisan “would have been motivated to use Paxton’s correlation functions with Sutton’s functions related to malicious activities, including Sutton’s generating one or more rules.” Id. We are left, however, with the question of what use would one of ordinary skill in the art have for Paxton’s correlation in Sutton’s rule generation. Based on Petitioner’s arguments and evidence we are presented with a scenario in which Paxton identifies the relationship between certain packets and Sutton develops rules for certain addresses. As pointed out by Patent Owner, the ’573 patent explains that in the case where a packet’s path may be obscured by a device a particular correlation may give rise to the need for a particular rule. As described by Petitioner, the combination before us does not explain why or how Paxton’s correlation would be the basis for any particular rule that may be created by Sutton. See Prelim. Resp. 29-30. Petitioner and Dr. Akl do not specifically address the claims’ requirement that the rule generation be “based on the correlating.” As such, they have not provided us with sufficient argument or evidence to demonstrate that Sutton’s rules would be based on the correlation and not on the detection of malicious activity. See, e.g., Ex. 1007, 3:1-23 (discussing taking corrective actions based on threat classifications such as violating, nonviolating, neutral, and unknown). Thus, for the reasons stated above we are not persuaded that Petitioner has shown sufficiently that the teachings of Paxton and Sutton would have taught or at least suggested the disputed limitation. Therefore, on the current record, Petitioner has not made a sufficient showing that the combination of Paxton, Sutton, and Deschênes would have rendered obvious independent claims 1, 9, and 17. IPR2021-01151 Patent 10,659,573 B2 28 2. Dependent Claims 7, 8, 15, 16, 23, and 24 Petitioner further contends that dependent claims 7, 8, 15, 16, 23, and 24 would have been obvious over Paxton, Sutton, and Deschênes. Pet. 38- 57. We have reviewed Petitioner’s assertions and supporting evidence for these claims, and we find them to be unpersuasive for the same reasons discussed above as to the independent claims. E. Obviousness over Paxton, Sutton, Deschênes, and McDonald Petitioner asserts that dependent claims 2, 10, and 18 are unpatentable under § 103 as obvious over Paxton, Sutton, Deschênes, and McDonald. Pet. 57-62. Petitioner does not assert that McDonald addresses any of the deficiencies discussed above in regards to the independent claims. Thus, for the reasons discussed with respect to claims 1, 9, and 17, we determine that Petitioner has not established a reasonable likelihood of prevailing in its contention that claims 2, 10, and 18 would have been rendered obvious by Paxton, Sutton, Deschênes, and McDonald. F. Obviousness over Paxton, Sutton, Deschênes, and Ivershen Petitioner asserts that dependent claims 3-6, 11-14, and 19-22 are unpatentable under § 103 as obvious over Paxton, Sutton, Deschênes, and Ivershen. Pet. 62-77. Petitioner does not assert that Ivershen addresses any of the deficiencies discussed above in regards to the independent claims. Thus, for the reasons discussed with respect to claims 1, 9, and 17, we determine that Petitioner has not established a reasonable likelihood of prevailing in its contention that claims 3-6, 11-14, and 19-22 would have been rendered obvious by Paxton, Sutton, Deschênes, and Ivershen. IPR2021-01151 Patent 10,659,573 B2 29 G. Discretionary Denial Because we deny institution upon consideration of the merits of Petitioner’s challenges, Patent Owner’s arguments that we should exercise our discretion under 35 U.S.C. § 314(a) or § 325(d) to deny institution are moot. See Pet. 6-9; Prelim. Resp. 3-11, 15-26. III. CONCLUSION For the foregoing reasons, we do not institute an inter partes review. IV. ORDER In consideration of the foregoing, it is hereby: ORDERED that the Petition is denied and no inter partes review is instituted in this proceeding. IPR2021-01151 Patent 10,659,573 B2 30 PETITIONER: Scott A. McKeown Mark D. Rowland Victor Cheung ROPES & GRAY LLP scott.mckeown@ropesgray.com mark.rowland@ropesgray.com victor.cheung@ropesgray.com PATENT OWNER: James Hannah Jeffrey H. Price KRAMER LEVIN NAFTALIS & FRANKEL LLP jhannah@kramerlevin.com jprice@kramerlevin.com Bradley C. Wright Scott M. Kelly Blair A. Silver BANNER & WITCOFF, LTD. bwright@bannerwitcoff.com skelly@bannerwitcoff.com bsilver@bannerwitcoff.com