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
This office action is in response to the listing of claims filed on April 29, 2025. Claims 1-19 are currently pending.
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.
Claims 1-19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-25 of U.S. Patent No. 12,321,464. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are substantially similar in their claimed approach to providing cyber attribution of software containers. These similarities are illustrated in the table below comparing an independent claim of the present application against one from the patent.
Present Application
Claim 1
Patent 12,321,464
Claim 1
A method for software containers attribution, comprising: de-compiling a configuration file of a container image of a software container in order to obtain a de-compiled configuration file, wherein the de-compiled configuration file includes a first plurality of commands;
A method for software containers attribution, comprising: de-compiling a configuration file of a first container image of a software container, wherein the first container image is among a plurality of container images, wherein the de-compiled configuration file includes a plurality of commands;
identifying a candidate build file in the de-compiled configuration file, wherein the candidate build file contains a second plurality of commands;
identifying at least one candidate build file in the de-compiled configuration file, wherein each candidate build file contains a plurality of commands executed to create a respective container image among the plurality of container images;
and matching the configuration file to the candidate build file based on the first plurality of commands and the second plurality of commands.
determining if at least one matching condition is satisfied between each of the at least one candidate build file and the de-compiled configuration file based on the plurality of commands of the de-compiled configuration file and the plurality of commands of each of the at least one candidate build file;
associating the configuration file with each candidate build file satisfying the at least one matching condition;
As can be seen above, both sets of claims match commands between the de-compiled configuration file and the candidate build file. The present application’s independent claim is simply silent with respect to the patent’s claimed updating of the inventory after the matching. This updating feature however is present within the dependent claims. In other words, the present independent claims are simply broader by omitting a step/limitation that are later presented in dependent claims. It would have been obvious to one skilled in the art, before the effective filing date, to have incorporated dependent claim 2 into it’s independent claim 1 to update an inventory after finding a match, to ensure up to date information is available.
Claims 2-19 are similarly rejected for being substantially similar to patented claims 2-25.
Claims 1-19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-25 of U.S. Patent No. 12,204,651. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are substantially similar in their claimed approach to providing cyber attribution of software containers. These similarities are illustrated in the table below comparing an independent claim of the present application against one from the patent.
Present Application
Claim 1
Patent 12,204,651
Claim 1
A method for software containers attribution, comprising: de-compiling a configuration file of a container image of a software container in order to obtain a de-compiled configuration file, wherein the de-compiled configuration file includes a first plurality of commands;
A method for software containers attribution, comprising: de-compiling a configuration file of a container image of a software container;
identifying a candidate build file in the de-compiled configuration file, wherein the candidate build file contains a second plurality of commands;
identifying at least one candidate build file in the de-compiled configuration file;
and matching the configuration file to the candidate build file based on the first plurality of commands and the second plurality of commands.
determining if at least one matching condition is satisfied between each of the at least one candidate build file and the de-compiled configuration file; wherein determining if the at least one matching condition is satisfied further comprises, when there is more than one candidate build file, matching each of the candidate build files to the de-compiled configuration file based on a matching condition, wherein the matching condition includes any one of: similarity, a creation time, a number of commands, and a hierarchical matching;
As can be seen above, both sets of claims support matching commands between the de-compiled configuration file and the candidate build file. The present application’s independent claim is simply silent with respect to the patent’s claimed updating of the inventory after the matching. This updating feature however is present within the dependent claims. In other words, the present independent claims are simply broader by omitting a step/limitation that are later presented in dependent claims. It would have been obvious to one skilled in the art, before the effective filing date, to have incorporated dependent claim 2 into it’s independent claim 1 to update an inventory after finding a match, to ensure up to date information is available.
Claims 2-19 are similarly rejected for being substantially similar to patented claims 2-25.
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.
Claims 1-6, 9-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Khan et al (US PGPub No: 2021/0311855) in view of Kim et al (US Patent No: 11,893,106), hereafter referred to as Khan and Kim, respectively.
With regard to claims 1, 10, and 11, Khan teaches through Kim, a method for software containers attribution, comprising: de-compiling (see below) a configuration file of a container image of a software container in order to obtain a de-compiled configuration file (Khan teaches the generation of a container image configuration file; see paragraph 4, Khan),
wherein the de-compiled configuration file includes a first plurality of commands (Khan teaches the configuration file can have executable commands; see paragraphs 4-5, Khan);
identifying a candidate build file in the de-compiled configuration file (Khan teaches the configuration file having one or more build configuration parameters associated with the building of the application; see paragraph 4, Khan),
wherein the candidate build file contains a second plurality of commands (Khan teaches the use of build configuration parameters associated with the building of the application; see paragraphs 4, Khan. Build files contain code (parameters are part of the code) which are commands for building the application);
and matching the configuration file to the candidate build file based on the first plurality of commands and the second plurality of commands (Khan teaches how the build configuration parameters are associated with the building of the application; see paragraphs 4 and 16, Khan. Khan explains how relevant code can be pulled for application development or testing. The relevant code can be checked for quality and tested by the container prior to being deployed; see paragraphs 51, and 53-54, Khan. When the container image configuration file’s contents are executed, container images are pulled and provided; see paragraph 54 and Figure 6, Khan).
While Khan teaches a network that supports the use of containers and reading configuration files of a container image, Khan does not explicitly cite decompiling a file. In the same field of endeavor, Kim also teaches a network that supports the use of containers; see column 1, lines 18-20, Kim. In particular, Kim teaches how script code, extracted by the container configuration analysis module, is converted into machine code (decompiling a file). An example is provided where bytecode is decompiled into source code; see column 7, lines 16-27, Kim.
By decompiling code, a system can determine if a container is based on machine code or non-machine code and can whitelist an application; accordingly, see column 1, line 65 – column 2, line 17, Kim. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Kim with those of Khan, to ensure only whitelisted applications are run, providing greater security; see column 2, lines 7-17 and column 10, lines 23-27, Kim.
With regard to claims 2 and 12, Khan teaches through Kim, the method further comprising: updating an inventory with an association between the configuration file and the candidate build file when the configuration file is matched to the candidate build file (Khan teaches using association data from developmental code within a container to retrieve the proper code with which to build; see paragraph 55 and Figures 6 and 7, Khan).
With regard to claims 3 and 13, Khan teaches through Kim, the method wherein the association provides a mapping between the container image and the candidate build file (Khan explains how dependencies/mappings associated with containers can be ached, including build automation images; see paragraphs 7-8, Khan).
With regard to claims 4 and 14, Khan teaches through Kim, the method wherein identifying the candidate build file further comprises: searching among a plurality of build files with respect to the first plurality of commands, wherein the candidate build file is identified such that at least one command of the second plurality of commands matches at least one command of the first plurality of commands (Khan teaches an image finder that can find container and build images; see paragraph 54 and Figure 6, Khan. The finder can pull container images and use the container image configuration file of a particular build to load and pull code relevant for the build; see paragraph 54, Khan).
With regard to claims 5 and 15, Khan teaches through Kim, the method wherein matching the configuration file to the candidate build file further comprises: matching the candidate build file to the de-compiled configuration file based on a matching condition, wherein the matching condition is defined with respect to at least one of: similarity; creation time; number of commands; and hierarchical matching
Khan teaches an image finder that can find container and build images; see paragraph 54 and Figure 6, Khan. The finder can pull container images and use the container image configuration file of a particular build to load and pull code relevant (i.e. similarity) for the build; see paragraph 54, Khan.
However Khan does not explicitly cite decompiling a file. In the same field of endeavor, Kim also teaches a network that supports the use of containers; see column 1, lines 18-20, Kim. In particular, Kim teaches how script code, extracted by the container configuration analysis module, is converted into machine code (decompiling a file). An example is provided where bytecode is decompiled into source code; see column 7, lines 16-27, Kim.
By decompiling code, a system can determine if a container is based on machine code or non-machine code and can whitelist an application; accordingly, see column 1, line 65 – column 2, line 17, Kim. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Kim with those of Khan, to ensure only whitelisted applications are run, providing greater security; see column 2, lines 7-17 and column 10, lines 23-27, Kim.
With regard to claims 6 and 16, Khan teaches through Kim, the method wherein the candidate build file is a first candidate build file among a plurality of candidate build files, wherein the first candidate build file is matched to the de-compiled configuration file when all candidate build files among the plurality of candidate build files match the de-compiled configuration file
Khan teaches an image finder that can find container and build images; see paragraph 54 and Figure 6, Khan. The finder can pull container images and use the container image configuration file of a particular build to load and pull code relevant for the build; see paragraph 54, Khan. Khan further provides multi-version concurrency control to manage the relational stores (i.e. can provide the most recent (i.e. first) match); see paragraph 42, Khan.
However Khan does not explicitly cite decompiling a file. In the same field of endeavor, Kim also teaches a network that supports the use of containers; see column 1, lines 18-20, Kim. In particular, Kim teaches how script code, extracted by the container configuration analysis module, is converted into machine code (decompiling a file). An example is provided where bytecode is decompiled into source code; see column 7, lines 16-27, Kim.
By decompiling code, a system can determine if a container is based on machine code or non-machine code and can whitelist an application; accordingly, see column 1, line 65 – column 2, line 17, Kim. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Kim with those of Khan, to ensure only whitelisted applications are run, providing greater security; see column 2, lines 7-17 and column 10, lines 23-27, Kim.
With regard to claims 9 and 19, Khan teaches through Kim, the method wherein the container image is formed from a plurality of build files, further comprising: generating a hierarchical representation of the container image, wherein the hierarchical representation includes a plurality of nodes arranged in a hierarchy; and associating each build file of the plurality of build files with a respective node of the plurality of nodes, wherein the candidate build file is identified based on the association between each build file of the plurality of build files and a respective node of the plurality of nodes (Khan supports storing container data with topology information; see paragraph 25, Khan. Furthermore, Khan explain how such data can be stored in graph-structured data; see paragraph 43, Khan).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AZIZUL Q CHOUDHURY whose telephone number is (571)272-3909. The examiner can normally be reached M-F.
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, EMMANUEL MOISE can be reached at (571) 272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AZIZUL CHOUDHURY/Primary Examiner, Art Unit 2455
Prosecution Insights