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 .
Status of Claims
The amendment filed 12/4/2025 has been entered. Claims 1-6, 8, 10, 21-27 are currently amended. Claims 28-30 are added. Claims 1-30 are pending in the application.
Response to Amendments
The objection to claims 1-2, 8, 10 has been withdrawn in light of applicant’s amendment to the claims.
The rejection of claims 21-22 under 35 USC 112(b) has been withdrawn in light of applicant’s amendment to claims.
Response to Arguments
Applicant’s argument, see pages 7-8 of the Remarks filed 12/4/2025 with respect to claims rejected under 35 USC 102 over prior arts of record has been fully considered but asserted not persuasive due to following reason.
Regarding to independent claims 1, 26-27, applicant argued Sanghavi fails to disclose or render obvious “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.”. See page 8 of the Remarks. Applicant further argued,
“Sanghavi describes a traditional, coarse-grained DNS sinkholing system in which traffic destined for blacklisted domains is redirected via HTTP redirect or destination NAT to one or more generic sinkhole servers that perform no domain-specific processing. See paragraphs of [0015], [0026], [0032], [0101], [0134] of Sanghavi. Sanghavi's sinkhole servers are intentionally simple and shared among all blacklisted domains; they do not employ name-based or IP-based virtual hosting on the sinkhole side, do not inspect TLS SNI or HTTP Host headers after redirection to differentiate intended domains, and do not provide customized, domain-specific honeypot responses. See paragraphs [0013], [0026], [0034], [0135] of Sanghavi”.
Examiner acknowledges applicant’s perspective, however, asserts applicant’s argument is not convincing.
The claims are interpreted under the broadest reasonable interpretation in light applicant’s Specification and cannot import from the Specification (see MPEP 2111.01 I/II). The claim(s) 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”, which can be interpreted as: perform a sinkholing of the network traffic, or perform a 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, or 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 (in this case the name-based virtual hosting or IP-based virtual hosting is referring to the automated analysis. In this case, the limitation above is interpretated as “perform a sinkholing of the network traffic”, which Sanghavi’s teachings as shown in the Office action (mailed 9/5/2025) and this Office action satisfies the limitation required in the claim(s).
Applicant’s further argument regarding dependent claims is moot since it is based on assumption that the independent claim(s) is patentable.
For the above reasons, the claim rejections under 35 USC 102/103 are maintained. See the updated Claim Rejections under 35 USC 103 below for details in response to applicant’s amendment.
Applicant is encouraged to include innovative features into claims to advance the case.
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.
Claim 30 is 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 30 line 5 recites “the intended domain”. There is insufficient antecedent basis for this limitation in the claim.
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, Sanghavi teaches:
A system 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 (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 26, claim 26 is a method claim that encompasses limitations similar to those limitations of the system claim 1. Therefore, claim 26 is rejected with the same rationale as applied against claim 1 (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).
Regarding claim 27, claim 27 is a computer program product claim that encompasses limitations similar to those limitations of the system claim 1. Therefore, claim 27 is rejected with the same rationale as applied against claim 1 (Sanghavi, discloses devices and method for blocking, detecting and/or preventing malicious traffic, see [Title]/[Abstract]. And [0081] Controller 420 may perform one or more processes described herein. Controller 420 may perform these processes in response to executing software instructions stored by a non-transitory computer-readable medium).
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
Claims 29-30 are 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 any outstanding informalities and concerns under 35 USC 112(b) presented in this office action.
The following is a statement of reasons for the indication of allowable subject matter:
Claim 29 depends on claim 1, further specifies “wherein the name-based virtual hosting is performed at a sinkhole server and comprises inspecting, at the sinkhole 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 domain-specific honeypot response”.
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 the 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”.
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:
Xie et al (US20160381065A1) discloses techniques for sinkholing bad network domains by registering the bad network domains on the Internet.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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