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 .
This is in reply to papers filed on 04/2/2026. Claims 1-20 are pending. Claims 1, 11, and 19 is/are independent.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 6/16/2025, 12/12/2025, and 04/2/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
U.S. Patent No. 12,265,616
Claims 1, 3-4, 6-7, 10-11, 13-14, 16, and 18 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-14 of U.S. Patent No. 12,265,616 in view of Krylov et al. U.S. Publication 20190243972 (hereinafter “Krylov”) in view of Stopel et al. U.S. Publication 20170116415 (hereinafter “Stopel”). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of U.S. Patent No. 12,265,616 render obvious the claims of the present application. Claims 1-14 of U.S. Patent No. 12,265,616 contain most elements of claim 1 of the instant application, except the features of
one or more deployment configurations of a container image via a container orchestration service;
for an ID of the container image;
generate an allow list that includes container images and their respective IDs that have one or more deployment configurations that are not anomalous.
Krylov at para. 41-42, 43, 92-94, and Figure 1 teaches extracting parameters of objects obtained from containers, and the containers are obtained from a system for teaching a model for detection of malicious containers. Furthermore, Krylov at para. 108 teaches generating a white list of containers that are safe. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the computing system recited in claim 1 of U.S. Patent No. 12,265,616 to include
one or more deployment configurations of a container image via a container orchestration service;
generate an allow list that includes container images that have one or more deployment configurations that are not anomalous.
, as taught by Krylov, in order to improve training of a machine learning model based on deployment configurations, and to record a list of the safe containers.
Claims 1-14 of U.S. Patent No. 12,265,616 in view of Krylov does not disclose the ID of the container image.
Stopel at para. 8 and 86 teaches identifiers for container images.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of the computing system recited in claim 1 of U.S. Patent No. 12,265,616 with Krylov to include
for an ID of the container image;
generate an allow list that includes container images and their respective IDs that have one or more deployment configurations that are not anomalous.
, as taught by Krylov, in order to improve identification of containers.
Claim 11 recites limitations analogous to limitations of claim 1 and is similarly rejected with respect to claim 8 of U.S. Patent No. 12,265,616.
U.S. Patent No. 12,353,547
Claims 1-5, 7-8, 10-12, 14-16, and 18 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. Patent No. 12,353,547. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-15 of U.S. Patent No. 12,353,547 anticipate the claims of the present application.
Allowable Subject Matter
Claim 9-10 and 17-18 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 20 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as indicated below. However, Claim 20 would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action.
The following is a statement of reasons for the indication of allowable subject matter:
The prior art of record (in particular, Krylov et al. U.S. Publication 20190243972 (hereinafter “Krylov”) in view of Stopel et al. U.S. Publication 20170116415 (hereinafter “Stopel”), Dotan et al. U.S. Publication 20050223239 (hereinafter “Dotan”), Fang et al. U.S. Publication 20190190771 (hereinafter “Fang”), Wolkov et al. U.S. Publication 20180234443 (hereinafter “Wolkov”), Barthur et al. U.S. Publication 20200250477 (hereinafter “Barthur”)) does not expressly disclose all the limitations recited in independent claims and the combination of their features thereon. With respect to dependent claims 9 and 20 the closest prior art does not disclose at least the following limitations in the recited context:
CLAIM 9
the computing system further
configured to:
generate a first probability score based on the plurality of features, using a first
machine learning model trained on a first set of historical data associated with an ID of a
specific version of the container image;
generate a second probability score based on the plurality of features, using a
second machine learning model trained on a second set of historical data associated with an ID of all versions of the container image;
generate an overall consistency score based on the first probability score and the
second probability score; and
in response to determining that the consistency overall score is greater than a
predetermined threshold, perform at least one of perform at least one of (1) add the
container image to the allow list or (2) generate a security alert.
CLAIM 20
wherein the training data associated
with the historical deployment configurations of a container image includes first data
associated with a first plurality of historical deployment configurations of a specific
version of the container image and second data associated with a second plurality of
historical deployment configurations of all versions of the container image,
wherein the computing system is further configured to:
train a first anomaly detection model based on the first data;
train a second anomaly detection model based on the second data;
generate a combined model configured to generate an overall consistency score,
wherein in response to receiving a dataset associated with deployment configurations of a container image,
the first anomaly detection model is configured to generate a first probability score, indicating a first probability that the deployment configurations of the specific version of the container image is anomalous compared to the first plurality of historical deployment configurations,
the second anomaly detection model is configured to generate a second probability score, indicating a second probability that the deployment configurations of all versions of the container image are anomalous compared to the second plurality of historical deployment configurations, and
the combined model is configured to generate a combined score based on the first probability score and the second probability score.
Rather, Krylov discloses a model for detection of malicious containers. Objects from containers are selected, and then parameters are determined for the objects. The system determines a degree of harmfulness characterizing the probability of maliciousness based on the parameters [Krylov para. 84, 92-95].
However, Krylov does not disclose at least the features of claims 9 and 20 quoted above.
To this, Stopel adds identifiers for container images [Stopel, para. 86]. Dotan adds removing an object subsequently detected to be high risk from a white list [Dotan, para.110]. Fang adds providing an account parameter for applications executing in a container [Fang, para. 29-31]. Wolkov adds computing a total score from multiple individual scores [Wolkov, para. 46, 49-51]. Barthur adds training a machine learning model based on a subset of features [Barthur, para. 50].
However, the combination of Krylov, Stopel, Dotan, Fang, Wolkov, and Barthur does not teach at least the features of claims 9 and 20 quoted above.
Dependent claim 10 would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, in view of its dependence from dependent claim 9. Claim 17 and 18 recite limitations analogous to limitations of claims 9 and 10 and for the same reasons would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims as indicated above.
For the reasons described above, the prior art of record does not disclose, with respect to dependent claims 9-10 and 17-18, features corresponding to those of dependent claims 9-10 and 17-18 in their respective contexts. Therefore, the dependent claims 9-10 and 17-18 would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims as indicated above.
Claim 20 would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action.
None of the prior art of record, either taken by itself or in any combination, would have anticipated or made obvious the claimed embodiments of the allowable claims at or before the time it was filed.
Claim Objections
Claim 9 is objected to because of the following informalities: claim 9 recites “perform at least one of perform at least one of”, which should be changed to remove the extra “perform at least one of”. Appropriate correction is required.
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 4-5, 14-15, and 20 is/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 pre-AIA the applicant regards as the invention.
Claim 4 recites “the deployment of the container image” However, claim 1 recites one or more deployment configurations, and one or more historical deployment configurations, and it is not clear which deployment is referred to by this claim limitation.
Claim 5 recites “in storage of a host system” However, it is not clear whether this storage is the computer-readable hardware storage devices recited in the preamble of claim 1 or some other storage. Claim 5 recites “service accounts that the underlying application of container image” However, it is not clear whether this refers to the previously introduced container image or introducing a new container image.
Claim 14 recites limitations analogous to limitations of claim 4 and is rejected for the same reasons.
Claim 15 recites limitations analogous to limitations of claim 5 and is rejected for the same reasons.
Claim 20 recites “the historical deployment configurations of a container image includes first data” on the 2nd line and “a dataset associated with deployment configurations of a container image” in lines 11-12. However, it is not clear whether container image is referring to the container image already introduced in Claim 19 or introducing a new container image.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-4, 8, 11, 13-14, 16 Is/are rejected under 35 U.S.C. 103 as being unpatentable over Krylov et al. U.S. Publication 20190243972 (hereinafter “Krylov”) in view of Stopel et al. U.S. Publication 20170116415 (hereinafter “Stopel”).
As per claim 1, Krylov discloses
A computing system [systems, para. 128, 129] comprising:
one or more processors; [module may be executed on processor, para. 129] and one or more computer-readable hardware storage devices [non-transitory computer readable medium, RAM ROM, para. 128] having stored thereon computer-executable instructions [methods may be stored as one or more instructions, para. 128; program code accessed by processor, para. 120] that are structured such that, when executed by the one or more processors, [execute on processor, para. 129] the computer-executable instructions cause the computing system to perform at least: [functions of module facilitated by software, para. 129]
Krylov [0128] In various aspects, the systems and methods described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the methods may be stored as one or more instructions or code on a non-transitory computer-readable medium. 1
Computer-readable medium includes data storage. By way of example, and not limitation, such computer-readable medium can comprise RAM, ROM, EEPROM, CD-ROM, Flash memory or other types of electric, magnetic, or optical storage medium, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processor of a general purpose computer.
Krylov [0129] In various aspects, the systems and methods described in the present disclosure can be addressed in terms of modules. The term “module” as used herein refers to a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or field-programmable gate array (FPGA), for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module may also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module may be executed on the processor of a general purpose computer (such as the one described in greater detail in FIG. 5, above). Accordingly, each module may be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.
collect one or more datasets[objects from containers are selected, para. 92, 94] associated with one or more deployment configurations[parameters of each container, para. 94] of a container image [each container, para. 94; a container 100 may be a software distro (such as a Windows installer formatted as a Microsoft Installer or “MSI”) containing objects that are logically separate software components; or a file archive para. 43] via a container orchestration service; [container orchestration service = system of teaching a model for detection of malicious containers, Para. 41]
Krylov [0041] FIG. 1 shows an example of the structural diagram of the system of teaching a model for detection of malicious containers. The system for teaching a model for detection of malicious containers includes a container 100 being analyzed, objects of the container 105, parameter determination module 110,
Krylov [0092] In step 210 the parameter determination module 110 is used to determine the parameters of objects 105 selected from at least one safe container 100.1 and one malicious container 100.2,
Krylov [0094] In step 220 the convolution generation module 120 is used to form convolutions separately for each container 100 on the basis of the determined parameters of objects 105 selected from said container 100. The convolution may be represented as a multidimensional vector, each element of which corresponds to its own unique parameter from the determined parameters,
extract a plurality of features [features disclosed by the parameters of objects of containers para. 84, 94, 95; form convolutions (feature vectors) for each container based on the determined parameters of objects from the container, para. 94; the Krylov convolutions store the extracted feature data as feature vectors (convolutions)] based on the one or more datasets; [convolutions (feature vectors) are created based on the selected objects, para. 94]
generate a probability score [degree of harmfulness characterizing the probability of maliciousness, para. 84, 95 ] based on the plurality of features, [on the basis of the determined parameters of objects 105 selected from said container 100, para. 94; on the basis of the formed convolutions, para. 95 ]using one or more machine-learning models trained [perform machine learning for the model, para. 84, 95] on datasets associated with one or more historical deployment configurations [determined parameters of objects selected from container, para. 94; the parameters disclose the configurations] of the container image that have been performed via the container orchestration service, [container orchestration service = system of teaching a model for detection of malicious containers, Para. 41]
the probability score indicating a probability of whether the one or more deployment configurations of the container image are anomalous [detection of malicious containers… degree of harmfulness from guaranteed safe to definitely malicious, para. 84; probability score = degree of harmfulness] or not anomalous when compared to the one or more historical deployment configurations of the container image; and
[the application of the trained machine learning models to unknown containers would disclose comparing the one or more deployment configurations of the container image to one or more historical deployment configurations of the container image, para. 84, 93-95]
Krylov [0084] The model training module 130 is configured for machine learning of the model for detection of malicious containers 131 on the basis of at least one convolution, formed for a (predetermined) safe container, and one convolution formed for a (predetermined) malicious container, said detection model 131 being an algorithm for calculating the degree of harmfulness of a container 100, while the degree of harmfulness of a container 100 is a numerical value characterizing the probability that said container 100 is malicious. For example, the degree of harmfulness may be a real numerical value in the range of 0.0 to 1.0, where the value 0.0 means that the container being analyzed is guaranteed safe, and 1.0 that it is definitely malicious (i.e., malicious activity will occur if it is used on a computer).
Krylov [0095]
In step 230 the model training module 130 is used to perform machine learning for the model for detection of malicious containers 131 on the basis of the formed convolutions, said detection model 131 being an algorithm for calculating the degree of harmfulness of the container 100, while the degree of harmfulness of the container 100 is a numerical value characterizing the probability that said container 100 is malicious.
generate an allow list [white list, para. 108] that includes container images that have one or more deployment configurations that are not anomalous.
Krylov [0108] In yet another exemplary aspect, some of the containers from the group of containers 300 may be excluded from the queue to perform the antivirus scan. For example, if the check sum calculated on the basis of a container (for example, MD5) is on a “white list” (a database of check sums calculated on the basis of safe containers), then that container is excluded from the queue to perform the antivirus scan and is considered to be safe.
However, Krylov does not expressly disclose
identifiers for the container images
Stopel discloses
identifiers for the container images
[0086] As discussed above, the enforcement action may be determined based on a security policy, the type of the detected violation, or both. The endorsement action may include, for example, generating an alert (or security event), halting the operation of the APP container, quarantining the APP container or the infected file, and so on. The alert may include APP container identifier, a name of the infected process, information of the detected violation, and so on. The enforcement of the security policy is performed at runtime.
[0008] As demonstrated in FIG. 1, a number of software containers (i.e., the app containers 110-1 through 110-n, hereinafter referred to individually as a container 110,
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Krylov with the technique for providing each container image with an identifier of Stopel to include
extract a plurality of features based on the one or more datasets for an ID of the container image;
generate an allow list that includes container images and their respective IDs that have one or more deployment configurations that are not anomalous.
One of ordinary skill in the art would have made this modification to improve the ability of the system to uniquely identify each container image. The system of the primary reference can be modified to include an identifier for each container image to facilitate identification of unique containers.
As per claim 3, the rejection of claim 1 is incorporated herein.
Krylov discloses wherein the computing system is further configured to: compare [guaranteed safe or definitely malicious, para. 84; deemed to be malicious, para. 86; detection of malicious containers… degree of harmfulness from guaranteed safe to definitely malicious, para. 84] the probability score [degree of harmfulness characterizing the probability of maliciousness, para. 84, 95 ] to a predetermined threshold [1.0 indicating “definitely malicious” (para. 84), or a “threshold value of 0.82” or 0.815 (para. 86) ] that is indicative of whether the one or more deployment configurations of the container image are anomalous or not anomalous [detection of malicious containers… degree of harmfulness from guaranteed safe to definitely malicious, para. 84; probability score = degree of harmfulness; guaranteed safe or definitely malicious, para. 84; deemed to be malicious, para. 86] when compared to the one or more historical deployment configurations [ predetermined safe container and predetermined malicious container (para. 83); in Krylov these are older, historical, containers that have been determined to be safe or malicious and is used for training the model. Because the model is trained using historical container information, there is comparing to the historical deployment configurations when the trained model is applied to a container for which maliciousness has yet to be determined] of the container image.
[As another example, the predetermined threshold can be the sigmoid function used for binary classification of the harmfulness of containers being analyzed. Binary classification in para. 84 means there are 2 possible outcomes for classifying the container, and this binary classification is referring to determining whether the container being analyzed is definitely malicious or guaranteed safe.
The historical deployment configurations of claim 3 are disclosed by the predetermined safe container and predetermined malicious container (para. 83). The Krylov convolution is basically a multidimensional vector representing properties of the container and objects contained within the container (Krylov para. 94). The convolution is generated to represent the container properties for purposes of determining maliciousness using a trained model (para. 83). Applying the trained model to the convolution representing the container properties determines whether the container is classified as malicious or not (para. 84).
the application of the trained machine learning models to unknown containers would disclose comparing, para. 84, 93-95]
Krylov [0084] The model training module 130 is configured for machine learning of the model for detection of malicious containers 131 on the basis of at least one convolution, formed for a (predetermined) safe container, and one convolution formed for a (predetermined) malicious container, said detection model 131 being an algorithm for calculating the degree of harmfulness of a container 100, while the degree of harmfulness of a container 100 is a numerical value characterizing the probability that said container 100 is malicious. For example, the degree of harmfulness may be a real numerical value in the range of 0.0 to 1.0, where the value 0.0 means that the container being analyzed is guaranteed safe, and 1.0 that it is definitely malicious (i.e., malicious activity will occur if it is used on a computer).
[0086] For example, if the degree of harmfulness of the container is in the range [0.80 . . . 0.85] (for example, 0.805), while a container 100 is deemed to be malicious starting with a threshold value of 0.82, the model for detection of malicious containers 131 is retrained such that the degree of harmfulness as calculated with the aid of the retrained model for detection of malicious containers 131 is greater than the mentioned value of 0.805 (such as 0.815).
Krylov [0095]
In step 230 the model training module 130 is used to perform machine learning for the model for detection of malicious containers 131 on the basis of the formed convolutions, said detection model 131 being an algorithm for calculating the degree of harmfulness of the container 100, while the degree of harmfulness of the container 100 is a numerical value characterizing the probability that said container 100 is malicious.
As per claim 4, the rejection of claim 1 is incorporated herein.
Krylov discloses wherein collecting one or more datasets includes collecting a dataset from at least one of (1) a client device,[the computer system 20 can be a personal computer para. 122; computer system 20 may operate using remote connection to one or more remote computers, the remote computer may be a server, para. 126, and therefore computer system 20, which trains a machine learning model at para. 121, can be a client device; system, para. 18; real-world device, microprocessor system, or general purpose computer, para. 129; ] (2) a manifest file, (3) an audit log [logs, para. 5] that records different events associated with the deployment of the container image, or (4) a registry[storage device storing group of container files, para. 18] that stores the container image.
[0018] In another exemplary aspect, a system for training a machine learning model for detecting malicious container files is provided. The system includes a storage device configured to store a group of container files, and a hardware processor. The processor is configured to select a plurality of objects from a malicious container file, and determine at least one parameter for each object selected from the malicious container file.
[0129] In various aspects, the systems and methods described in the present disclosure can be addressed in terms of modules. The term “module” as used herein refers to a real-world device, …, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. …and in some cases, all, of a module may be executed on the processor of a general purpose computer (such as the one described in greater detail in FIG. 5, above).
As per claim 8, the rejection of claim 1 is incorporated herein.
Krylov discloses wherein the one or more deployment
configurations of the container image are anomalous when the probability score is greater than a threshold.[ is deemed to be malicious starting with a threshold value of 0.82, para. 86, range is 0 to 1.0, 1.0 is definitely malicious, para. 84]
Para. 84 The model training module 130 is configured for machine learning of the model for detection of malicious containers 131 … said detection model 131 being an algorithm for calculating the degree of harmfulness of a container 100, while the degree of harmfulness of a container 100 is a numerical value characterizing the probability that said container 100 is malicious. For example, the degree of harmfulness may be a real numerical value in the range of 0.0 to 1.0, where the value 0.0 means that the container being analyzed is guaranteed safe, and 1.0 that it is definitely malicious (i.e., malicious activity will occur if it is used on a computer).
Para. 86 For example, if the degree of harmfulness of the container is in the range [0.80 . . . 0.85] (for example, 0.805), while a container 100 is deemed to be malicious starting with a threshold value of 0.82, the model for detection of malicious containers 131 is retrained such that the degree of harmfulness as calculated with the aid of the retrained model for detection of malicious containers 131 is greater than the mentioned value of 0.805 (such as 0.815).
As per claim 11, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1.
Claim 11 also recites, and Krylov discloses A method [method of teaching a model for detection of malicious containers, para. 36] implemented at a computing system[systems, para. 128, 129] for detecting anomalies [detection of malicious containers, para. 41] in deployment configurations [parameters of each container, para. 94] of container images[software distro, para. 43] at a container network [group of containers, para. 93], the method comprising:
[ the containers are broadly defined (para. 42-46) in the Krylov reference, Krylov container can be a file archive (para. 43) and containing any type of data, including software distribution (“’a software distro (such as a Windows installer formatted as a Microsoft Installer or “MSI”) containing objects that are logically separate software components; or a file archive” para. 43), image data (para. 63 and 64)]
As per claim 14, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 4, and is/are rejected for the reasons detailed with respect to claim 4.
As per claim 16, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 8, and is/are rejected for the reasons detailed with respect to claim 8.
Claims 2 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krylov in view of Stopel, further in view of Dotan et al. U.S. Publication 20050223239 (hereinafter “Dotan”).
As per claim 2, the rejection of claim 1 is incorporated herein.
However, the combination of Krylov and Stopel does not expressly disclose
remove a container image and its respective ID that were previously included on the allow list when it is determined that the container image subsequently has one or more deployment configurations that are anomalous.
Dotan discloses removing an object subsequently detected to be high risk from a white list
[0110] If the technician determines that the program presents a high risk to the users computers, the client servers may remove the program from the white list and may disable the program or have it run in an untrusted mode. In this manner, the client server helps monitor the users computers for malicious code that the user may not be able to detect independently.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Krylov and Stopel with the technique for removing an object subsequently detected to be high risk from a white list of Dotan to include
remove a container image and its respective ID that were previously included on the allow list when it is determined that the container image subsequently has one or more deployment configurations that are anomalous.
One of ordinary skill in the art would have made this modification to improve the ability of the system to remove a container image that is subsequently detected to be high risk (anomalous). The system of the primary reference can be modified to remove a container image and its ID from a white list if the container image is subsequently determined to be high risk.
As per claim 12, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
As per claim 13, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 3, and is/are rejected for the reasons detailed with respect to claim 3.
Claims 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krylov in view of Stopel, further in view of Fang et al. U.S. Publication 20190190771 (hereinafter “Fang”).
As per claim 5, the rejection of claim 1 is incorporated herein.
However, the combination of Krylov and Stopel does not expressly disclose
wherein the one or more deployment
configurations of the container image include at least one of (1) one or more mounting
points for the container image in storage of a host system, (2) permissions for an
underlying application of the container image in a host system, (3) service accounts that
the underlying application of container image will be associated with, or ( 4) whether the
underlying application of the container image will be privileged or not in the system.
Fang discloses wherein the one or more deployment
configurations of the container image [the Fang container can have installed and executing applications so the container is an image of an executable environment, para. 29-31 ]include at least one of (1) one or more mounting
points for the container image in storage of a host system, (2) permissions for an
underlying application of the container image in a host system, (3) service accounts that the underlying application[management tools or management applications or aging applications or cloud service operating, in the container, para. 30-31, of container image will be associated with, or ( 4) whether the
underlying application of the container image will be privileged or not in the system.
Para. 29 a container is established in the cloud platform 1 for providing a webpage used in the front-end service element….virtual machine and sets up the corresponding parameter group; the cloud service template parser 100 also installs configuration tool agent program in the configurable container and sets up the corresponding parameter group
0030] In the conventional cloud service technology, after the cloud service has been established, the user has to enter each virtual machine or each container to dispose the management tools (including the management applications and the agent applications) and set up the corresponding parameter groups, whereby the user can manage the cloud service operating in the virtual machine or container in the future… multitudinous implementation parameters and environment parameters must be set up in all the compute nodes.
[0031] Generally to speak, the abovementioned parameters include many different parameters, such as the link parameter, the firewall parameter, the setting-up parameter, the monitoring parameter, and the account parameter.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Krylov and Stopel with the technique for providing an account parameter for applications executing in a container of Fang to include
wherein the one or more deployment
configurations of the container image include at least one of (1) one or more mounting
points for the container image in storage of a host system, (2) permissions for an
underlying application of the container image in a host system, (3) service accounts that
the underlying application of container image will be associated with, or ( 4) whether the
underlying application of the container image will be privileged or not in the system.
One of ordinary skill in the art would have made this modification to improve the ability of the system to associate accounts with the applications executing within the container. The system of the primary reference can be modified to facilitate association of accounts with applications executing within the container.
As per claim 15, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 5, and is/are rejected for the reasons detailed with respect to claim 5.
Claims 6 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krylov in view of Stopel, further in view of Wolkov et al. U.S. Publication 20180234443 (hereinafter “Wolkov”).
As per claim 6, the rejection of claim 1 is incorporated herein.
Krylov discloses
group the plurality of features into a plurality of collections of features;
[see para. 54 parameters divided into 2 groups; para. 51 table 1.1 and table 1.2 in which the parameter column is the features, and the type, size, and index can be said to be a 1st collection of features and the type, total size, number of objects can be 2nd collection of features in table 1.2]
for each of the plurality of collections of features, [this is interpreted as applied to a single plurality, and not interpreted as applied to each collection, and so the same disclosure cited in claim 1 applies here for generating a probability score] generate a probability score, [degree of harmfulness characterizing the probability of maliciousness, para. 84, 95 ] using a machine-learning model trained [perform machine learning for the model, para. 84, 95] on the one or more datasets associated with the historical deployment configurations [determined parameters of objects selected from container, para. 94; the parameters disclose the configurations] of the container image that have been performed via the container orchestration service, the probability score indicating a probability that the deployment configurations are an anomaly; [detection of malicious containers… degree of harmfulness from guaranteed safe to definitely malicious, para. 84; probability score = degree of harmfulness]
However, the combination of Krylov and Stopel does not expressly disclose
generate an overall consistency score based on the plurality of probability scores; and
in response to determining the overall score is greater than a predetermined threshold, perform at least one of (1) add the container image to the allow list or (2) generate a security alert.
Wolkov discloses calculating individual scores for each parameter, computing a total score from multiple individual scores and generating an alert
Wolkov [0046] At 220, the security application 42 via the second scoring code 56 (i) calculates individual scores for each parameter and/or risk factor for the selected user/client computer, and/or (ii) determines a total score for the selected user/client computer. In an embodiment, the total score is generated based on the individual scores. The total score may be equal to a sum, product and/or average of the individual scores. The total score may be equal to a weighted average of the individual scores, where each individual score is multiplied by a corresponding weight value and then summed to provide the total score.
[0049] At 226, the security application 42 via the risk code 60 determines risk values for the anomalies based on the anomaly data. This may include determining probabilities that the anomalies are to occur based on the baselines, scores of the anomaly data, the total scores,
[0050] At 228, the security application 42 via the countermeasure code 62 determines whether the one or more risk values are greater than corresponding predetermined thresholds and/or outside corresponding predetermined ranges. If the one or more risk values are greater than corresponding predetermined thresholds and/or outside corresponding predetermined ranges, operation 230 is performed, otherwise operation 232 may be performed.
Wolkov [0051] At 230, the security application 42 via the countermeasure code 62 performs one or more countermeasures. As a first countermeasure, statistics are reported, which may include reporting the selected parameters and/or risk factors, identified anomalies, determined aggregated anomalies, risk values, user identifier, client computer identifier and/or address, cloud application identifier, type of cloud application, organization identifier, identifier of predetermined group, and/or other related statistic information. This information may be reported to corresponding users, client computers, owners and/or representatives of an organization, owners of VMs and/or PMs of cloud applications, and/or representatives of a service provider of the security application 42 and/or the cloud applications. As another countermeasure, the security application 42 may alert a user,
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Krylov and Stopel with the technique for computing a total score from multiple individual scores of Wolkov to include
generate an overall consistency score based on the plurality of probability scores; and
in response to determining the overall score is greater than a predetermined threshold, perform at least one of (1) add the container image to the allow list or (2) generate a security alert.
One of ordinary skill in the art would have made this modification to improve the ability of the system to generate an overall score to determine the probability of maliciousness, and to be able to account for the different parameters that make up the total score. As taught in the Wolkov reference at para. 46, the system can calculate an individual score for each parameter used to calculate the total score, and generate an alert to notify user.
As per claim 7, the rejection of claim 6 is incorporated herein.
However, the combination of Krylov and Stopel does not expressly disclose, but
Wolkov discloses wherein generating an overall
consistency score based on the plurality of probability scores includes:
assigning a weight to each of the plurality of probability scores; and
generating a weighted overall score based on the plurality of probability scores
and the corresponding weights.
[Wolkov discloses generating the weighted overall score based on multiple weighted individual scores in the portions of the reference cited with respect to claim 6]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Krylov and Stopel with the technique for computing a weighted total score from weighted multiple individual scores of Wolkov to include
wherein generating an overall
consistency score based on the plurality of probability scores includes:
assigning a weight to each of the plurality of probability scores; and
generating a weighted overall score based on the plurality of probability scores
and the corresponding weights.
One of ordinary skill in the art would have made this modification to improve the ability of the system to generate an overall score to determine the probability of maliciousness, and to allow for weighting the different parameters separately based on the degree of importance of the parameters when calculating the overall score. Also, as taught in the Wolkov reference at para. 46, the system can calculate an individual score for each parameter used to calculate the total score.
Claims 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krylov in view of Barthur et al. U.S. Publication 20200250477 (hereinafter “Barthur”).
As per claim 19, Krylov discloses
A computing system [systems, para. 128, 129] comprising:
one or more processors; and
one or more computer-readable hardware storage devices [non-transitory computer readable medium, RAM ROM, para. 128] having stored thereon computer-executable instructions[methods may be stored as one or more instructions, para. 128; program code accessed by processor, para. 120] that are structured such that, when executed by the one or more processors[execute on processor, para. 129], the computer-executable instructions cause the computing system to
perform at least: [functions of module facilitated by software, para. 129]
obtain training data [objects from containers are selected, para. 92, 94] associated with historical deployment configurations [parameters of each container, para. 94] of a container image [each container, para. 94; a container 100 may be a software distro (such as a Windows installer formatted as a Microsoft Installer or “MSI”) containing objects that are logically separate software components; or a file archive para. 43] via a container orchestration service; [container orchestration service = system of teaching a model for detection of malicious containers, Para. 41]
[ the containers are broadly defined (para. 42-46) in the Krylov reference, Krylov container can be a file archive (para. 43) and containing any type of data, including software distribution (“’a software distro (such as a Windows installer formatted as a Microsoft Installer or “MSI”) containing objects that are logically separate software components; or a file archive” para. 43), image data (para. 63 and 64)]
Krylov [0041] FIG. 1 shows an example of the structural diagram of the system of teaching a model for detection of malicious containers. The system for teaching a model for detection of malicious containers includes a container 100 being analyzed, objects of the container 105, parameter determination module 110,
Krylov [0092] In step 210 the parameter determination module 110 is used to determine the parameters of objects 105 selected from at least one safe container 100.1 and one malicious container 100.2,
Krylov [0094] In step 220 the convolution generation module 120 is used to form convolutions separately for each container 100 on the basis of the determined parameters of objects 105 selected from said container 100. The convolution may be represented as a multidimensional vector, each element of which corresponds to its own unique parameter from the determined parameters,
extract a plurality of features[features disclosed by the parameters of objects of containers para. 84, 94, 95 ] for the historical deployment configurations [parameters of each container, para. 94] of container images based on the training data; convolutions are created based on the selected objects on the select objects, para. 94]
train an anomaly detection model using machine learning, [perform machine learning for the model, para. 84, 95] such that the anomaly detection model is configured to generate a probability score [degree of harmfulness characterizing the probability of maliciousness, para. 84, 95 ] for a given dataset associated with one or more deployment configurations [determined parameters of objects selected from container, para. 94; the parameters disclose the configurations] of the container image via the container orchestration service, [container orchestration service = system of teaching a model for detection of malicious containers, Para. 41] indicating a probability that the one or more deployment configurations of the container image are anomalous [detection of malicious containers… degree of harmfulness from guaranteed safe to definitely malicious, para. 84; probability score = degree of harmfulness] compared to the historical deployment configurations.
[the application of the trained machine learning models to unknown containers would disclose comparing the one or more deployment configurations of the container image to historical deployment configurations, para. 84, 93-95]
However, Krylov does not expressly disclose
select one or more collections of features among the plurality of features;
and
for each of the one or more collections of features, train an anomaly detection model Barthur discloses training a machine learning model based on a subset of features
[0050] The set of features X.sub.1, Y.sub.1 . . . Z.sub.1 may be filtered to include a set of representative features (i.e., a subset of the initial set of features). A machine learning model may be trained using the set of features X.sub.1, Y.sub.1 . . . Z.sub.1 or a set of filtered features.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Krylov with the technique for training a machine learning model based on a subset of features of Barthur to include select one or more collections of features among the plurality of features;
and
for each of the one or more collections of features, train an anomaly detection model
One of ordinary skill in the art would have made this modification to improve the ability of the system to select a specific set of subset of features for training a model. The system the primary reference can be modified to select a specific subset of features for training a model, in order to generate a model to match specific requirements according to the features.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOWARD H LOUIE whose telephone number is 571-272-0036. The examiner can normally be reached on Monday-Friday 9 AM-5 PM EST.
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, Jung W. Kim can be reached on 571-272-3804. 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.
/HOWARD H. LOUIE/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494
1 Emphasis is additional throughout.
