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 .
DETAILED ACTION
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), filed on 9/30/2025 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. Applicant's submission filed on 9/30/2025 has been entered. Claims 1-20 are pending.
Response to Arguments
2. Applicant's arguments are moot in light of the new ground of rejections set forth below.
Claim Rejections - 35 USC § 103
3. 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.
4. 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 of this title, 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.
5. 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.
6. Claims 1-4, 7-10, 13-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Levin (US 2019/0190931) in view of Hu et al (US 2019/0052650).
As to claim 1, Levin discloses a method for operating a container-based architecture, the method comprising:
executing, using one or more processors, instructions stored on memory to provide a plurality of Domain Name Service (DNS) proxy services, wherein each DNS proxy service of the plurality of DNS proxy services is executed in a separate server of a container cluster (see [0052], “a cluster configuration for a cluster of host devices including the host device executing the APP container”, wherein each host device such as illustrated in Figure 3 comprises a detector container 315 equivalent to a DNS proxy service, executed in a separate server/host of the container cluster. See [0034], “the detector container 315 is configured to detect botnets implemented using bots (not shown) executed via APP containers 311 of the host device 310, and to block malicious traffic from the bot-containing APP containers 311. Accordingly, malicious traffic such as communications between bots and their control servers may be blocked or otherwise mitigated, thereby protecting the host device 310 from bot commands. To detect botnets, the detector container 315 is configured to create, for each APP container 311 at runtime, a DNS policy defining a whitelist of allowed domain names for each APP container 311”. Here, the detector container is equivalent to a DNS proxy service, executed in a container-based architecture that comprises at least the detector container and various APP containers);
receiving at a DNS proxy service selected from the plurality of DNS proxy services a domain name service (DNS) request ([0017], “DNS query” received by the detector container on a selected host device in the cluster, see citation in limitation 1 above), wherein:
the DNS request is received from an application service executing in the container cluster as the selected DNS proxy service ([0017], The DNS request is received from a software container, which executes on the same host device with the detector container and are in the same cluster); and
the DNS request is directed to a DNS server being executed in the same container cluster as the selected DNS proxy service (Figure 3; [0017] and [0034], wherein the software/APP containers and the detector container are on the same host device, only allowed to send queries to other entities in the same cluster, see [0040], “abnormal behavior may include…queries directed to entities outside of a cluster (entities that only communicate locally with other entities in the same cluster)”; [0052], “a rule that the container should only resolve DNS queries to other services in the same cluster)”),
wherein the selected DNS proxy service is positioned to receive the DNS request before the DNS request reaches the DNS server (see citation above, wherein the detector container is positioned to receive the DNS request before the DNS request reaches the DNS server. Also see [0035], “Traffic is inspected, and traffic that does not meet the DNS policy is determined to be malicious traffic. When traffic is determined to be malicious, a botnet is detected. In some implementations, mitigation actions such as blocking malicious DNS queries may be performed.”; [0039], “…usual or unusual destinations for DNS queries”; [0028], “The disclosed embodiments provide techniques for cyber security in containerized environments that do not require predetermined signatures of known malware.” It is to be noted that the claim does not require that the DNS server be part of the same container, or even part of a container, but merely requires that the DNS server be executed in a same container-based architecture, which can be reasonably interpreted as any system/architecture or environment that includes at least one container);
analyzing, at the DNS proxy service, the received DNS request using at least one machine learning model ([0041], “the DNS policy is created during a learning phase. The learning phase for each APP container 311 occurs during runtime of the APP container”; [0049], “At S510, during a learning phase, traffic from an APP container is intercepted and inspected to create a DNS policy for the APP container. The traffic includes DNS queries. Based on the intercepted traffic, a DNS policy is created. The DNS policy defines a whitelist of allowed domain names for the APP container. The DNS policy may further define previously resolved domain names”;[0052]-[0053]);
assigning a classification to the DNS request using the DNS proxy service, wherein the assigned classification is based on the analysis of the received DNS request and indicates whether the DNS request should be allowed or blocked ([0055]-[0059], “when a botnet is detected, one or more mitigation actions is performed and execution continues with S520. The mitigation actions may include, but are not limited to, blocking at least a portion of traffic from the APP container. Specifically, communications between the APP container and the entity having the requested domain name are blocked”); and
resolving the DNS request to a network location based on the assigned classification of the DNS request ([0060], “when one or more DNS queries are resolved (i.e., the DNS queries are not blocked as part of the mitigation actions at S550), DNS spoofing attacks may be detected based on IP addresses of the resolved DNS queries”).
Levin further teaches
a categorization module in the container cluster that is configured to apply at least one categorization rule to the DNS request to assign the DNS request to a category (Levin, [0017]; [0034]);
a domain analysis engine in the container cluster that is configured to compare the DNS request to a plurality of labeled domain names (Levin, [0017]; [0034]); and
a policy server in the container cluster storing one or more policies, wherein the assigned classification is based on output from at least one of the categorization module, the domain analysis engine, and the policy server (Levin, [0017]; [0034]), but does not expressly disclose that
the domain analysis engine is a domain generation algorithm (DGA) behavioral analysis engine executing one or more machine learning procedures to analyze the DNS request to identify whether the DNS request shares characteristics with a particular family of malware or that that policy server to determine how the DNS proxy service should process an output from the DGA behavioral analysis engine and an output from the categorization module.
Hu discloses a domain generation algorithm (DGA) behavioral analysis engine executing one or more machine learning procedures to analyze the DNS request to identify whether the DNS request shares characteristics with a particular family of malware (figure 5, “Determine one or more attributes of the Name, Determine a set of additional Names (NAMES2) that share a particular attribute”, “Determine whether additional name clusters with the set of failed lookup names (nxnames)”. Here, the Name is determined to share characteristics with the set of additional Names being a particular family of malware as being clustered with the failed lookup names),
a categorization module to assign a category to the received DNS request based on one or more characteristics associated with the DNS request (figure 5, see citation above, wherein “Determine one or more attributes of the Name, Determine a set of additional Names (NAMES2) that share a particular attribute” indicates assigning a category to the received DNS request/Name, as being in the category of having shared particular attribute with the additional names), and
a policy server to determine how the DNS proxy service should process an output from the DGA behavioral analysis engine and an output from the categorization module (Figure 5, step 512 is based on the output of the categorization module whether the Name is categorized as being in the category of having shared particular attributed with the additional names, and also the output of the DGA behavior analysis engine regarding whether the additional name clusters with the set of failed lookup names, to produce a confidence score);
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Levin with Hu. The suggestion/motivation of the combination would have been to detect a DGA name (Hu, figure 5, last step).
As to claim 10, see similar rejection to claim 1, except for the last limitation, which is also taught by Levin, i.e., denying the first DNS request upon determining the first DNS request is intended for the
malign network location (see Levin, [0026], “The botnet is mitigated by at least blocking DNS queries to domain names that are not whitelisted”; see also [0034]-[0037]).
As to claim 15, see similar rejection to claim 1.
As to claim 2, Levin-Hu discloses the method of claim 1, wherein the DNS proxy service executing in the container cluster is positioned in the container cluster to intercept DNS requests from reaching the DNS server without requiring further configuration (Levin, figure 3, wherein the detector container 315 co-reside with software containers 311 in the host device to achieve the mitigation as cited in rejection to claim 1. The disclosure does not require modifying a DNS server. The mitigation steps are before the DNS query reaches a DNS server is implied otherwise the mitigation would not have been achieved).
As to claim 3, Levin-Hu discloses the method of claim 1, wherein the assigned classification indicates the DNS request is associated with a threat (Levin, [0017] [0034]-[0-037], disclosing that the DNS request is associated with botnet; [0028], “botnet-based threat”).
As to claim 4, Levin-Hu discloses the method of claim 1, wherein the assigned classification indicates the DNS request is to a command-and-control server external to the container cluster or to a network location that violates a policy (Levin, [0037]. “DNS queries to domain names associated with domain names that were not resolved by previous DNS queries may be determined to be malicious such that botnets are detected and such DNS queries to unresolved domain names may be blocked”; see [0059], “communications between the APP container and the entity having the requested domain name are blocked, for example, by blocking the malicious DNS queries. Accordingly, bot activity such as requesting commands from a command and control server may be mitigated.”).
As to claim 17, see similar rejection to claim 4.
As to claim 7, Levin-Hu discloses the method of claim 1, wherein the assigned classification indicates the DNS request is to a benign network location, and resolving the DNS request to the network location includes allowing the DNS request to access the benign network location (Levin, [0060]-[0061], “when one or more DNS queries are resolved (i.e., the DNS queries are not blocked as part of the mitigation actions at S550)… when one or more DNS queries are resolved (i.e., the DNS queries are not blocked as part of the mitigation actions at S550), DNS spoofing attacks may be detected based on IP addresses of the resolved DNS queries. In an embodiment, S560 includes determining whether any of the IP addresses resulting from the resolved DNS queries are inapplicable to the APP container. [0061] An IP address may be inapplicable to the APP container when the IP address is not among previous IP address results in the DNS policy for the APP container and the IP address is associated with an unknown entity”. Here, it is disclosed that when the DNS query are classified as benign when not blocked then resolving the DNS request and allow access if applicable to the APP container).
As to claim 14, Levin-Hu discloses the method of claim 10, further comprising:
receiving at the DNS proxy service a second DNS request transmitted from a second application service executing in the container cluster, wherein the second DNS request is directed to the DNS server being executed in the same container cluster as the DNS proxy service (Levin, figure 3, multiple APP containers 311, and wherein the detector container is on the same host device and therefore the same container cluster. See [0052], “(e.g., a rule that the container should only resolve DNS queries to other services in the same cluster)”; [0034], “the detector container 315 is configured to detect botnets implemented using bots (not shown) executed via APP containers 311 of the host device 310, and to block malicious traffic from the bot-containing APP containers 311. Accordingly, malicious traffic such as communications between bots and their control servers may be blocked or otherwise mitigated, thereby protecting the host device 310 from bot commands. To detect botnets, the detector container 315 is configured to create, for each APP container 311 at runtime, a DNS policy defining a whitelist of allowed domain names for each APP container 311”);
analyzing, at the DNS proxy service, the second DNS request using the at least one machine learning model (see citation in rejection to claim 1, performed for each DNS request);
assigning a classification to the second DNS request using the DNS proxy service, wherein the assigned classification is based on the analysis of the second DNS request and indicates the second DNS request is intended for a benign network location (see similar rejection to claim 1, last two limitations and claim 7); and
allowing the second DNS request to access the benign network location (see similar rejection to claim 7).
As to claim 19, Levin-Hu discloses the system of claim 15, wherein the assigned classification indicates the DNS request is intended for a benign network location, and the resolved network location is the benign network location (see similar rejection to claim 7).
As to claim 8, Levin-Hu discloses the method of claim 1, further comprising receiving a plurality of domain names associated with malware (Levin, [0027]).
As to claim 9, Levin-Hu discloses the method of claim 8, wherein analyzing the received DNS request includes comparing the DNS request to the received plurality of domain names associated with malware (Levin, [0040], “query results matching a known blacklist of IP addresses)”).
As to claim 20, Levin-Hu discloses the system of claim 15, wherein the DNS proxy service analyzes the DNS request by comparing the DNS request to a plurality of domain names (Levin, [0017]; [0034]).
As to claim 13, Levin-Hu discloses the method of claim 10, wherein denying the first DNS request includes ignoring the first DNS request (Levin, [0017]; [0034], blocking is a type of ignoring).
As to claim 16, Levin-Hu discloses the system of claim 15, wherein the categorization module is
configured to apply at least one categorization rule to the DNS request to assign the DNS request to a category (Hu, see citation and explanation in rejection to claim 1).
7. Claims 5, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Levin-Hu, as applied to claim 1 above, and further in view of Thompson et al (US 20140283063).
As to claim 5, Levin-Hu discloses the claimed invention substantially as discussed in claim 1, but does not expressly disclose wherein the resolved network location is a sinkhole computing location. Thompson discloses a concept of resolving to a network location which is a sinkhole computing location ([0006])
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Levin-Hu with Thompson. The suggestion/motivation of the combination would have been for gaining control of one or more of the C2 DNS names by a friendly party (Thompson, [0006]).
As to claim 11, see similar rejection to claim 5.
As to claim 18, see similar rejection to claim 5.
8. Claims 6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Levin-Hu, as applied to claim 1 above, and further in view of Joshi et al (US 20210385230).
As to claim 6, Levin-Hu discloses the claimed invention substantially as discussed in claim 1 but does not expressly disclose wherein the resolved network location is a block page service. Joshi discloses a concept of resolving/redirecting a DNS request to a block page service ([0142]).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Levin with Joshi. The suggestion/motivation of the combination would have been to provide intelligence threat handling (Joshi, [0142]).
As to claim 12, see similar rejection to claim 6.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037. 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.
/HUA FAN/Primary Examiner, Art Unit 2458