Prosecution Insights
Last updated: July 17, 2026
Application No. 18/620,606

SCALABLE DOMAIN-LEVEL SINKHOLING AND INTERACTION OF NETWORK TRAFFIC

Non-Final OA §102§103§112
Filed
Mar 28, 2024
Examiner
LEE, MICHAEL M
Art Unit
2436
Tech Center
2400 — Computer Networks
Assignee
Palo Alto Networks Inc.
OA Round
3 (Non-Final)
84%
Grant Probability
Favorable
3-4
OA Rounds
5m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 84% — above average
84%
Career Allowance Rate
226 granted / 270 resolved
+25.7% vs TC avg
Strong +42% interview lift
Without
With
+42.5%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
25 currently pending
Career history
292
Total Applications
across all art units

Statute-Specific Performance

§101
3.1%
-36.9% vs TC avg
§103
86.7%
+46.7% vs TC avg
§102
0.7%
-39.3% vs TC avg
§112
9.3%
-30.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 270 resolved cases

Office Action

§102 §103 §112
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Status of Claims The amendment filed 5/4/2026 has been entered. Claims 1, 26-27, 30 are currently amended. Claim 29 is cancelled. Claims 31-32 are newly added. Claims 1-28, 30-32 are pending in the application. Response to Amendments The rejection of claim 30 under 35 USC 112(b) has been withdrawn in light of applicant’s amendment to claim. See the updated Claim Rejections under 35 USC 112(b) below. Response to Arguments Applicant’s argument, see pages 8-9 of the Remarks filed 5/4/2026 with respect to claims rejected under 35 USC 102/103 over prior arts of record has been fully considered but asserted not fully persuasive due to following reason. Examiner acknowledges that applicant has included portion of allowable subject matter from previous claim 29 into claim 1 (similarly for claims 26 and 27). However, the amendment fails to make those claims allowable. See the Claim Rejection under 35 USC 112(b) below. Further, examiner notes, the claim (1, 26, 27) recites, “perform(ing) … using one or more of a name-based virtual hosting or an IP-based virtual hosting, wherein the name-based virtual hosting …”. Under the broadest reasonable interpretation in light of applicant’s specification, the use of “or” may suggest the “perform(ing)” may using an IP-based virtual hosting. In this case, the included “wherein the name-based virtual hosting …” in the amendment may be irrelevant and not effective to further limit the claim. For this reason, the claim rejection under 35 USC 102 is maintained. For the above reason, examiner suggests applicant to change “or” to “and”, or remove “or an IP-based virtual hosting”. The newly added claims 31 and 32 recite system and method with features of previous claim 1 (or claim 26), and further including allowable subject matters from claim 30. Therefore claims 31-32 are allowable. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 1-28, 30 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1 lines 10-15 recites “perform a sinkholing of the network traffic or traffic handling for automated analysis of vulnerable or malicious network traffic using one or more of a name-based virtual hosting or an IP-based virtual hosting, wherein the name-based virtual hosting is performed at a server and comprises inspecting, at the server, a TLS Server Name Indication (SNI) extension or an HTTP Host header of an incoming connection to map the connection to a particular intended domain and to provide a honeypot response”. Under the broadest reasonable interpretation in light of applicant’s specification, the underlined above may read as, using an IP-based virtual hosting. In this case, there is insufficient antecedent basis for limitation, “the name-based virtual hosting” in the claim. Applicant is suggested to replace “or” with “and” or remove “or an IP-based virtual hosting”. Similarly for claims 26 and 27. Claims 2-25, 28, 30 depend on claim 1, therefore are also rejected for the same reason set forth above. Examiner Notes Examiner cites particular paragraphs, columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention. Claims 1, 3, 6-9, 26-28 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sanghavi et al (US20200007548A1, hereinafter, “Sanghavi”). Regarding claim 1, similarly claim 26, claim 27, Sanghavi teaches: A system for domain-level sinkholing of network traffic/A method for domain-level sinkholing of network traffic/A computer program product embodied in a non-transitory computer readable medium for domain-level sinkholing of network traffic (Sanghavi, discloses devices and method for blocking, detecting and/or preventing malicious traffic, see [Title]/[Abstract]. And [0001] DNS sinkholing may be used to provide incorrect DNS resolution, by which the path of Internet traffic may be directed to different resources (e.g., a sinkhole server) instead of allowing access to malicious or inaccessible content. DNS sinkholing is a method of redirecting malicious Internet traffic so that the malicious Internet traffic may be captured and analyzed), comprising: one or more processors (Fig. 4B, Processor); and a memory coupled to the one or more processors and configured to provide the one or more processors with instructions, with instructions, that when executed by the one or more processors, (Fig. 4B, Processor 435 and Memory 440, [0085] Memory 440 includes a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and/or an optical memory) that stores information and/or instructions for use by Processor 435) to: obtain network traffic (Refer to Fig. 5, or Fig. 6, Fig. 7. e.g., Fig. 5 at 540, and [0096] As further shown in FIG. 5, process 500 may include receiving traffic destined for a destination device associated with a destination network address (block 540)); determine a client system associated with the network traffic ([0003] The method may include receiving, by the processor, a domain name system (DNS) request or query, wherein the DNS request includes a request to access a destination domain associated with a destination domain identifier, and a source network address corresponding to a device from which the DNS request was received (i.e., client system). Also Fig. 5 at 550 and Fig. 7 at 750); determine a domain for which the client system is attempting to access in connection with the network traffic (Refer to Fig. 7, and [0127] As further shown in FIG. 7, process 700 may include comparing the packet source network address and/or the packet destination network address (i.e., determine a domain) to the match criteria (block 750). For example, the security device (e.g., using controller 420, processor 435, memory 440, storage component 445, and/or the like) may compare the packet source network address and/or the packet destination network address to the match criteria); and perform a sinkholing of the network traffic or traffic handling for automated analysis of vulnerable or malicious network traffic using one or more of a name-based virtual hosting or an IP-based virtual hosting, wherein the name-based virtual hosting is performed at a server and comprises inspecting, at the server, a TLS Server Name Indication (SNI) extension or an HTTP Host header of an incoming connection to map the connection to a particular intended domain and to provide a honeypot response (Fig. 5 at 560, [0098] As further shown in FIG. 5, process 500 may include performing an action based on a result of comparing the destination network address and the network addresses (block 560). And [0101] the action may include determining that the destination network address corresponds to a network address of the network addresses, … obtaining a plurality of sinkhole server identifiers associated with the blacklisted domain identifier, selecting a sinkhole server identifier from the plurality of sinkhole server identifiers associated with the blacklisted domain identifier, and HTTP redirecting the HTTP traffic towards a sinkhole server associated with the sinkhole server identifier (i.e., perform a sinkholing of the network traffic). See also e.g., Fig. 7 at 760 and [0130-0132, 0134]). Regarding claim 3, Sanghavi teaches the system of claim 1, Sanghavi further teaches: wherein the analysis of the vulnerable or malicious network traffic comprises determining a remediation for the network traffic (Sanghavi, [0135] Where the source device is identified as an attacker, the security device may notify a cloud-based security platform so that the attacker may be globally blocked. In this way, security across one or more networks may be improved as attackers may be elegantly identified and prevented from reaching backend devices in the one or more networks). Regarding claim 6, Sanghavi teaches the system of claim 1, Sanghavi further teaches: wherein performing the sinkholing or traffic handling comprises determining a particular domain to which the network traffic is to be redirected, and redirecting the network traffic to the particular domain (Sanghavi, [0023] As further shown in FIG. 1A, and by reference number 108, the security device may send the network addresses for the blacklisted domains to the routing device. The network addresses for the blacklisted domains may be used in filtering and/or redirecting traffic destined for the blacklisted domains. And [0134] For example, security devices 350 may block traffic destined to network addresses associated with webservers hosting the blacklisted domains, and redirect the traffic towards a sinkhole server device 310). Regarding claim 7, Sanghavi teaches the system of claim 6, Sanghavi further teaches: wherein the particular domain is determined based on the name-based virtual hosting (Sanghavi, [0032] Additionally, or alternatively, where the security device determines that the source network address or the destination network address does correspond to a network address contained in the data structure, the traffic may be parsed to identify a domain name, for example, where the traffic is HTTP or HTTPS traffic. In some implementations, where the domain name matches a blacklisted domain name identifier, the traffic may be redirected to a sinkhole server associated with the blacklisted domain name identifier). Regarding claim 8, Sanghavi teaches the system of claim 1, Sanghavi further teaches: wherein performing the sinkholing or traffic handling comprises redirecting network traffic for a compromised client to one or more servers running the name-based virtual hosting (Sanghavi, [0032] Additionally, or alternatively, where the security device determines that the source network address or the destination network address does correspond to a network address contained in the data structure, the traffic may be parsed to identify a domain name, for example, where the traffic is HTTP or HTTPS traffic. In some implementations, where the domain name matches a blacklisted domain name identifier, the traffic may be redirected to a sinkhole server associated with the blacklisted domain name identifier). Regarding claim 9, Sanghavi teaches the system of claim 8, Sanghavi further teaches: wherein the redirecting of the network traffic is performed by a dedicated sinkhole nameserver(s) (Sanghavi, [0015] For example, the security devices (i.e., dedicated sinkhole nameserver(s)) may block traffic destined to network addresses associated with webservers hosting the blacklisted domains, and redirect the traffic towards a sinkhole server). Regarding claim 28, Sanghavi teaches the system of claim 1, Sanghavi further teaches: wherein performing the sinkholing or traffic handling comprises using a dedicated sinkhole nameserver configured to return a different redirect address for each different intended domain, the redirect address being selected from one of: a name-based virtual hosting address, a unique IPv6 address assigned to the intended domain, or an IPv4-based address assigned via a unique combination of IPv4 addresses or a reserved time slot ([0023] As further shown in FIG. 1A, and by reference number 108, the security device may send the network addresses for the blacklisted domains to the routing device. The network addresses for the blacklisted domains may be used in filtering and/or redirecting traffic destined for the blacklisted domains... In some implementations, the data stored by the routing device may additionally include the blacklisted domain identifiers obtained from the security platform, the network addresses associated with the blacklisted domain identifiers as resolved by the security device, the list of sinkhole server device identifiers (e.g., sinkhole IPv4 addresses, sinkhole IPv6 addresses, etc.) associated with the blacklisted domain identifiers obtained from the security platform, suspect source network addresses obtained from the security platform, suspect source network address prefixes obtained from the security platform, and/or the like). Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Yeh et al (US20200267124A1, hereinafter, “Yeh”). Regarding claim 2, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the same field of endeavor Yeh teaches: wherein the analysis of the vulnerable or malicious network traffic comprises determining one or more patterns associated with the vulnerable or malicious network traffic (Yeh, discloses method for deterring malicious network traffic, see [Abstract] The packet of the inline network traffic is transferred to the data center if the network traffic-related graphic does not match any of the model-related graphics. And [0016] Thus, the analyzer 20 executes deep packet inspection (‘DPI’) on packets of the network traffic heading for the data center 60 via the routers 65. On finding any of the packets of network traffic to contain any malicious pattern, the analyzer server 20 immediately provides a warning and/or blocks the network traffic). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Yeh in the blocking, detecting and/or preventing malicious traffic of Sanghavi by detecting malicious traffic based on traffic pattern. This would have been obvious because the person having ordinary skill in the art would have been motivated to using model-related graphics derived from malicious patterns of the malicious packets for deterring malicious traffic based on malicious patterns (Yeh, [Abstract]). Claims 4-5, 11 are rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Xu (US20170163603A1, hereinafter, “Xu”). Regarding claim 4, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the same field of endeavor Xu teaches: wherein the analysis of the vulnerable or malicious traffic comprises monitoring visited domains (Xu, discloses system and method for discovering and selecting candidates for sinkholing of network domains, see [Abstract]. And [0043] The cloud security service provider can thereby monitor and log attempts by clients to connect to the sinkholed bad network domain. Accordingly, this approach allows the cloud security service provider to identify clients that are infected with identified malware based on the logged attempts by such clients). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Xu in the blocking, detecting and/or preventing malicious traffic of Sanghavi by monitoring and logging attempts to the sinkholed bad network domain. This would have been obvious because the person having ordinary skill in the art would have been motivated to discover and select candidates for sinkholing of network domains (Xu, [Abstract]). Regarding claim 5, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the same field of endeavor Xu teaches: wherein performing the sinkholing or traffic handling comprises determining one or more behaviors for malware associated with the network traffic (Xu, discloses system and method for discovering and selecting candidates for sinkholing of network domains, see [Abstract]. And [0044] As another example, malware can be automatically analyzed using DNS network traffic emulation techniques to determine that the malware is associated (e.g., uniquely associated) with a bad network domain, such as an NXDOMAIN). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Xu in the blocking, detecting and/or preventing malicious traffic of Sanghavi by analyzing malware associated with the network traffic. This would have been obvious because the person having ordinary skill in the art would have been motivated to determine the malware is associated with bad network domain (Xu, [Abstract], [0040, 0043]). Regarding claim 11, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the same field of endeavor Xu teaches: wherein the network traffic is encrypted (Xu, discloses system and method for discovering and selecting candidates for sinkholing of network domains, see [Abstract]. And [0065] if the monitored traffic is encrypted (e.g., encrypted using SSL, SSH, or another known encryption protocol), then the monitored traffic can be decrypted using a decrypt engine 310 (e.g., applying man in the middle techniques using a self-signed certificate)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Xu in the blocking, detecting and/or preventing malicious traffic of Sanghavi by monitoring and logging attempts to the sinkholed bad network domain. This would have been obvious because the person having ordinary skill in the art would have been motivated to discover and select candidates for sinkholing of network domains (Xu, [Abstract]). Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Wu (US8117325B1, hereinafter, “Wu”). Regarding claim 10, Sanghavi teaches the system of claim 1, wherein a name-based virtual hosting server uses an HTTP/S host header or TLS SNI inspection to map a connection request to different domains for the name-based virtual hosting (Wu, discloses method that includes generating a request that includes a host domain associated with a multiple-domain-to-one domain mapping, see [Abstract]. And [Claim 1] generating, by the client device, a hypertext transfer protocol (HTTP) request to connect to the device through the SSL VPN connection, where the HTTP request is associated with a multiple-domain-to-one domain mapping, and where the HTTP request includes a reference to a default host domain and a Uniform Resource Identifier (URI) related to the device for the SSL VPN connection). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Wu in the blocking, detecting and/or preventing malicious traffic of Sanghavi by having a host domain associated with multi-domain-to-one domain mapping. This would have been obvious because the person having ordinary skill in the art would have been motivated to generate a request that includes a host domain associated with a multiple-domain-to-one domain mapping for policy-based cross-domain access control (Wu, [Abstract]). Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Xie et al (US20190190948A1, hereinafter, “Xie”). Regarding claim 12, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the same field of endeavor Xie teaches: wherein a honeypot service is implemented for a particular domain to which the network traffic is redirected (Xie, discloses system and method for selective sinkholing of malware domains via DNS poisoning, see [Abstract]. And [0035] selective sinkholing of malware domains by a security device via DNS poisoning includes intercepting a DNS query for a network domain from a local DNS server at the security device, in which the network domain was determined to be a bad network domain and the bad network domain was determined to be associated with malware… In other cases, the designated sinkholed IP address can be a predetermined, reserved IP address that can be used to provide a network device that is configured with the reserved IP address that can also be configured as a honeypot or sandbox for monitoring network activities of the malware executing on the infected host). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Xie in the blocking, detecting and/or preventing malicious traffic of Sanghavi by designating sinkholed IP address configured as honeypot. This would have been obvious because the person having ordinary skill in the art would have been motivated to monitor network activities of the malware executing on infected host (Xie, [Abstract]). Regarding claim 13, Sanghavi-Xie combination teaches the system of claim 12, Xie further teaches: wherein the one or more processors are further configured to configure the honeypot service for the domain (Xie, [0035] In some embodiments, selective sinkholing of malware domains by a security device via DNS poisoning includes intercepting a DNS query for a network domain from a local DNS server at the security device, in which the network domain was determined to be a bad network domain and the bad network domain was determined to be associated with malware… In other cases, the designated sinkholed IP address can be a predetermined, reserved IP address that can be used to provide a network device that is configured with the reserved IP address that can also be configured as a honeypot or sandbox for monitoring network activities of the malware executing on the infected host). Same motivation as presented in claim 12 would apply. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi-Xie as applied above in claim 12, further in view of Zeitlin et al (US20150358338A1, hereinafter, “Zeitlin”), and further in view of Wicker et al (US20200169580A1, hereinafter, “Wicker”). Regarding claim 14, Sanghavi-Xie combination teaches the system of claim 12, The combination of Sanghavi-Xie does not specifically teach the following, in the same field of endeavor Zeitlin teaches: wherein the honeypot service provides a server authentication (Zeitlin, discloses method of monitoring communication traffic for network-based detection of authentication failures, see [Abstract]. And [0027] Processor 28 of unit 25 may initiate any suitable action in response to detecting a suspected hostile activity…, processor 28 may redirect a suspected session to a honeypot 44 for subsequent analysis. In another embodiment, processor 28 may redirect subsequent traffic of the suspicious client to honeypot 44 (additionally or alternatively to redirecting the authentication session itself)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Zeitlin in the blocking, detecting and/or preventing malicious traffic of Sanghavi-Xie by redirecting suspected session to a honeypot for analysis and authentication. This would have been obvious because the person having ordinary skill in the art would have been motivated to detect authentication failures by analyzing failed authentication attempts (Zeitlin, [Abstract]). The combination of Sanghavi-Xie-Zeitlin does not specifically teach, in the same field of endeavor Wicker teaches: and a dummy response for a request(s) comprised in the network traffic redirected to the particular domain (Wicker, discloses system and method for identifying and circumventing a security scanner includes monitoring incoming traffic to a web application, see [Abstract]. And [0051] Accordingly, instead of providing response 170, dummy response 172 may be provided to the security scanner 110, for example, through the network 107. Dummy response 172 may be any response that does not provide the information requested by the security scanner request 162, for example static content, sanitized content, or honeypot content as discussed above). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Wicker in the blocking, detecting and/or preventing malicious traffic of Sanghavi-Xie-Zeitlin by providing response with dummy response to incoming traffic to web application. This would have been obvious because the person having ordinary skill in the art would have been motivated to circumventing security scanner traffic for web application by providing dummy response (Wicker, [Abstract]). Claims 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Buruganahalli et al (US20170302703A1, hereinafter, “Buruganahalli”). Regarding claim 15, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the similar field of endeavor Buruganahalli teaches: wherein one or more of a HTTP/S or a TLS SNI is used to map names to different domains (Buruganahalli, discloses system and method for destination domain extraction for secure protocols, see [Abstract]. And [0028] Thus, SNI is an extension to the TLS protocol that indicates what hostname (e.g., destination domain) that the client is attempting to connect to at the start of the handshaking process for setting a secure TLS communication channel/ session between a client and a remote server. This standard extension for SNI was developed to allow a server to present multiple certificates on the same IP address and port number and, as a result, allows multiple secure (HTTPS) websites (e.g., and/or any other service over TLS) to be served using the same IP address without requiring all those sites to use the same certificate... Therefore, with clients and servers that support SNI, a single IP address can be used to serve a group of domain names for which it is impractical to get a common certificate). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Buruganahalli in the blocking, detecting and/or preventing malicious traffic of Sanghavi by using single IP address with TLS SNI serve a group of domain names. This would have been obvious because the person having ordinary skill in the art would have been motivated to allows multiple secure (HTTPS) websites to be served using the same IP address without requiring all those sites to use the same certificate (Buruganahalli, [Abstract], [0028]). Regarding claim 16, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the similar field of endeavor Buruganahalli teaches: wherein the name-based virtual hosting is implemented to provide a scalable number of domains mapped to a single IP address (Buruganahalli, discloses system and method for destination domain extraction for secure protocols, see [Abstract]. And [0028] Thus, SNI is an extension to the TLS protocol that indicates what hostname (e.g., destination domain) that the client is attempting to connect to at the start of the handshaking process for setting a secure TLS communication channel/session between a client and a remote server. This standard extension for SNI was developed to allow a server to present multiple certificates on the same IP address and port number and, as a result, allows multiple secure (HTTPS) websites (e.g., and/or any other service over TLS) (i.e., name-based virtual hosting) to be served using the same IP address without requiring all those sites to use the same certificate... Therefore, with clients and servers that support SNI, a single IP address can be used to serve a group of domain names for which it is impractical to get a common certificate (i.e., a scalable number of domains mapped to a single IP address)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Buruganahalli in the blocking, detecting and/or preventing malicious traffic of Sanghavi by using single IP address with TLS SNI serve a group of domain names. This would have been obvious because the person having ordinary skill in the art would have been motivated to allows multiple secure (HTTPS) websites to be served using the same IP address without requiring all those sites to use the same certificate (Buruganahalli, [Abstract], [0028]). Regarding claim 17, Sanghavi-Buruganahalli combination teaches the system of claim 16, Buruganahalli further teaches: wherein the scalable number of domains mapped to the single IP address is substantially an unlimited number of domains (Buruganahalli’s teaching of claim 16 suggests with TLS SNI, a group of domain names can be mapped to a single IP address where there is no limit to the size of the group suggesting unlimited number of domains). Same motivation as presented in claim 16 would apply. Claims 18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Hayes et al (US20230036680A1, hereinafter, “Hayes”). Regarding claim 18, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the similar field of endeavor Hayes teaches: wherein the IP-based virtual hosting comprises an IPv6 virtual hosting (Hayes, discloses systems and methods for determining security posture of an application, see [Abstract]. And [0020] The server 106 may include a host ID type identifier 112. The host ID type identifier 112 may be configured to determine the type of host ID that the host ID extractor 108 identified. Some of the different types may include a host name or an IP address. The host ID type identifier 112 may identify the type of host ID by identifying characteristics of the different types of host IDs. The host ID type identifier 112 may determine that the host ID is an IP address if the host ID includes an address in the internet protocol (IP) version 4 format or the internet protocol (IP) version 6 format). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Hayes in the blocking, detecting and/or preventing malicious traffic of Sanghavi by having host identifier configured as IP address in IPv6 format. This would have been obvious because the person having ordinary skill in the art would have been motivated to determine a security posture of an application (Hayes, [Abstract]). Regarding claim 20, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the similar field of endeavor Hayes teaches: wherein the IP-based virtual hosting comprises an IPv4 virtual hosting (Hayes, discloses systems and methods for determining security posture of an application, see [Abstract]. And [0020] The server 106 may include a host ID type identifier 112. The host ID type identifier 112 may be configured to determine the type of host ID that the host ID extractor 108 identified. Some of the different types may include a host name or an IP address. The host ID type identifier 112 may identify the type of host ID by identifying characteristics of the different types of host IDs. The host ID type identifier 112 may determine that the host ID is an IP address if the host ID includes an address in the internet protocol (IP) version 4 format or the internet protocol (IP) version 6 format). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Hayes in the blocking, detecting and/or preventing malicious traffic of Sanghavi by having host identifier configured as IP address in IPv4 format. This would have been obvious because the person having ordinary skill in the art would have been motivated to determine a security posture of an application (Hayes, [Abstract]). Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Hong et al (US20190140951A1, hereinafter, “Hong”). Regarding claim 19, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the similar field of endeavor Hong teaches: wherein a unique IPv6 address is assigned for each domain to which network traffic is to be redirected (Hong, discloses routing network traffic with hybrid routing table, see [Abstract]. And [0022] For example, a packet received by logical router 101 from an element within subnet domain 131 (e.g., a computer, server, switch, etc.) may be directed to an IPv6 network address having a prefix assigned to subnet domain 134. logical router 101 uses hybrid routing table 121 to determine that packets having the prefix assigned to subnet domain 134 should be routed to logical router 104 and transfers the packet over logical communication link 113 to logical router 104 accordingly). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Hong in the blocking, detecting and/or preventing malicious traffic of Sanghavi by routing network traffic with IPv6 address based on network prefix information. This would have been obvious because the person having ordinary skill in the art would have been motivated to route network traffic with hybrid routing table (Hong, [Abstract]). Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi-Hayes combination as applied above in claim 20, further in view of Prince et al (US20130080574A1, hereinafter, “Prince”). Regarding claim 21, Sanghavi-Hayes combination teaches the system of claim 20, While the combination of Sanghavi-Hayes does not specifically teach, in the similar field of endeavor Prince teaches: wherein using the IP-based virtual hosting comprises mapping a particular combination of a plurality of IPv4 addresses to a particular domain to which the network traffic is to be redirected (Prince, discloses method in proxy server for transitioning DNS request between different incompatible networks, see [Abstract] A first packet of a first protocol version type that includes an incoming request for an action to be performed on an identified resource is received from a client at a proxy server as a result of a DNS request resolving to a network address of the proxy server. And In one embodiment, the origin server parameter data structure 230 includes a set of one or more IPv4 addresses mapped to a customer's domain (i.e., a particular domain) …). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Prince in the blocking, detecting and/or preventing malicious traffic of Sanghavi-Hayes by mapping IPv4 addresses to customer’s domain. This would have been obvious because the person having ordinary skill in the art would have been motivated to allow proxy server to transit DNS request in incompatible networks (Prince, [Abstract]). Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi-Hayes combination as applied above in claim 20, further in view of Barger et al (US10044736B1, hereinafter, “Barger”). Regarding claim 22, Sanghavi-Hayes combination teaches the system of claim 20, While the combination of Sanghavi-Hayes does not specifically teach, in the similar field of endeavor Barger teaches: wherein using the IP-based virtual hosting comprises reserving unique time frame(s) for IPv4 addresses for a particular domain (Barger, discloses apparatus and method for identifying network infrastructure involved in malicious activity, see [Title]/[Abstract]. And [Col. 1 lines 45-52] The processor is configured to receive, from a domain name system sensor, a set of domain name resolutions associated with a domain within a time period. Each domain name resolution from the set of domain name resolutions includes a mapping between a domain name and an Internet Protocol (IP) address (e.g., IPv4 or IPv6) from a set of IP addresses at a time stamp within the time period (i.e., unique time frame)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Barger in the blocking, detecting and/or preventing malicious traffic of Sanghavi-Hayes by mapping a domain name and an IPv4 address. This would have been obvious because the person having ordinary skill in the art would have been motivated to have a set of domain name resolution associated with a domain within a time period (Barger, [Abstract]). Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Gundamaraju et al (US20170272470A1, hereinafter, “Gundamaraju”). Regarding claim 23, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the similar field of endeavor Gundamaraju teaches: wherein one or more of the client system associated with the network traffic or the domain for which the client system is attempting to access is determined based at least in part on an HTTP/S header (Gundamaraju, discloses systems and methods for detecting a domain name in mobile network session from user equipment, [Abstract]. And [0003] With Hypertext Transfer Protocol (HTTP) traffic, access gateways … can determine the destination network domain name by parsing the HTTP host headers and applying different policy enforcement charging and quality of service (QoS) semantics for different domains). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Gundamaraju in the blocking, detecting and/or preventing malicious traffic of Sanghavi by determining the destination network domain name by parsing the HTTP host headers as known in the arts. This would have been obvious because the person having ordinary skill in the art would have been motivated to determine domain name based on traffic type and determine service to apply to the received packet based on domain name (Gundamaraju, [Abstract]). Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Jin et al (CN114531271A, hereinafter, “Jin”). Regarding claim 24, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the same field of endeavor Jin teaches: wherein one or more of the client system associated with the network traffic or the domain for which the client system is attempting to access is determined based at least in part on an TLS SNI inspection (Jin, discloses method and device for malicious traffic detection, see [Abstract] establishing a domain name database containing a list of servers forbidden to access; the method comprises the following steps: in encrypted traffic from a client, obtaining a Client Hello packet sent by the client (i.e., client system), and extracting SNI information in the Hello packet; comparing a first server name in the SNI (i.e., TLS SNI) with the domain name database; and blocking the link between the client and the first server in response to the fact that the name of the first server is the same as any domain name in the domain name database). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Jin in the blocking, detecting and/or preventing malicious traffic of Sanghavi by determining the destination network domain name based on extracting SNI information and comparing with domain name database. This would have been obvious because the person having ordinary skill in the art would have been motivated to block the link between the client and the first server for malicious traffic (Jin, [Abstract]). Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Sanghavi as applied above in claim 1, in view of Golan et al (US20060075492A1, hereinafter, “Golan”). Regarding claim 25, Sanghavi teaches the system of claim 1, While Sanghavi does not specifically teach, in the same field of endeavor Golan teaches: wherein the analysis of the vulnerable or malicious network traffic comprises determining a pattern and a particular protocol intended by the network traffic (Golan, discloses system and method for providing access authorization with anomaly detection, see [Abstract]. And [0020] The anomaly detection module may detect or identify anomalies by, for example: analyzing network traffic flowing into the computer system, and identifying anomalies based on abnormal packet patterns, protocol analyses, or known attack signatures). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Golan in the blocking, detecting and/or preventing malicious traffic of Sanghavi by identifying anomalies based on abnormal packet patterns and protocol analyses. This would have been obvious because the person having ordinary skill in the art would have been motivated to enforce restriction policy in making access control decision (Golan, [Abstract]). Allowable Subject Matter Claim 30 is objected to as being dependent upon a rejected base claim(s), but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims as well as resolving of concerns under 35 USC 112(b) presented in this office action. Claim 30 depends on claim 1, further specifies “wherein performing the sinkholing or traffic handling comprises a multi-tier fallback mechanism that: first attempts redirection using name-based virtual hosting with a first TTL value, then, upon TTL expiration and if the domain has not been marked as analyzed, attempts redirection using a unique IPv6 address assigned to an intended domain with a second TTL value, and then, upon further TTL expiration and if the domain has not been marked as analyzed, attempts redirection using an IPv4-based virtual hosting address with a third TTL value”. Claims 31, 32 are allowable. As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a). The following is a statement of reasons for the indication of allowable subject matter: Claim 31 (similarly claim 32) recites unique features “performing a sinkholing of the network traffic or traffic handling for automated analysis of vulnerable or malicious network traffic using one or more of a name-based virtual hosting or an IP-based virtual hosting, wherein performing the sinkholing or traffic handling comprise a multi-tier fallback mechanism that: first attempts redirection using name-based virtual hosting with a first TTL value; then, upon TTL expiration and if the domain has not been marked as analyzed, attempts redirection using a unique IPv6 address assigned to an intended domain with a second TTL value; and then, upon further TTL expiration and if the domain has not been marked as analyzed, attempts redirection using an IPv4-based virtual hosting address with a third TTL value”, in combination with all other limitations in the claims as defined by applicant. The prior arts identified, Sanghavi, Yeh, Xu, Wu, Xie, Buruganahalli, Hayes, Hong, Prince , Barger, Golan, Jin, Gundamaraju, either singularly or in combination fails to anticipate or render obvious the claimed limitations of claims shown above. Citation of References The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references are cited but not been replied upon for this office action: Vissamsetty et al (US20230065321A1) discloses system and method of BotMagnets module with virtual machines hosting operating systems in which malicious code may be installed and executed without exposing sensitive data or other parts of a network. In particular, outbound traffic may be transmitted to a Sinkhole module that implements a service requested by the outbound traffic and transmits responses to the malicious code executing within the BotMagnet. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL M LEE whose telephone number is (571)272-1975. The examiner can normally be reached on M-F: 8:30AM - 5:30PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on (571) 272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /MICHAEL M LEE/Primary Examiner, Art Unit 2436
Read full office action

Prosecution Timeline

Mar 28, 2024
Application Filed
Sep 05, 2025
Non-Final Rejection mailed — §102, §103, §112
Dec 04, 2025
Response Filed
Feb 02, 2026
Final Rejection mailed — §102, §103, §112
May 04, 2026
Request for Continued Examination
May 12, 2026
Response after Non-Final Action
May 28, 2026
Non-Final Rejection mailed — §102, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12676884
Spoofed UDP Packet Detection
2y 2m to grant Granted Jul 07, 2026
Patent 12671994
INTEGRITY PROTECTION FAILURE HANDLING METHOD AND APPARATUS, AND USER EQUIPMENT
3y 7m to grant Granted Jun 30, 2026
Patent 12665914
VEHICLE SECURITY ANALYSIS APPARATUS, AND METHOD AND PROGRAM STORAGE MEDIUM
2y 4m to grant Granted Jun 23, 2026
Patent 12659728
DATA TRANSMISSION SYSTEM WITH HIGH TRANSMISSION SECURITY
3y 9m to grant Granted Jun 16, 2026
Patent 12659347
TECHNIQUES FOR PROTECTING WEB-BROWSERS AGAINST CROSS-SITE SCRIPTING EXPLOITATION ATTACKS
3y 5m to grant Granted Jun 16, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
84%
Grant Probability
99%
With Interview (+42.5%)
2y 9m (~5m remaining)
Median Time to Grant
High
PTA Risk
Based on 270 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month