DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Claims 22, 66 and 91-114 are pending in this application.
Applicant's arguments on claim rejections 35 U.S.C. 103, filed 2/5/2026 have been carefully and respectfully considered, and some are persuasive, while others are not. Therefore, some claims are indicated as allowance. In addition, the examiner respectfully traverses applicant’s arguments and made this action Final.
Response to Arguments
Applicant argues that Zeng discloses the code segment hash is calculated for each executable file for the single text segment of the executable file, because each of the executable files includes only a single .text segment. Thus, Zeng teaches that each hash includes a single section specified by the file format (a single text section), rather than "some of and fewer than all of the sections specified by the file format," as recited in independent claims 22 and 66 (Remarks, page 11).
Examiner respectfully submits that in formal logic, mathematics, and tests like the LSAT, "some" means at least one. It signifies a quantity greater than zero, which can include the possibility of "all". While conversational English often implies "some" means "not all," logically it only confirms one or more exist. Examiner interprets that "some of and fewer than all of the sections specified by the file format," means for at least one of the sections specified by the file format. Therefore, Zeng’s single .text segment in an executable file teaches the limitation "some of and fewer than all of the sections specified by the file format".
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 22, 66, 91-92, 95, 102-103 and 106 are rejected under 35 U.S.C. 103 as being unpatentable over Vijayvargiya et al. (US 12,086,234, hereinafter “Vijayvargiya”) in view of Zeng et al. (US 2020/0106775, hereinafter “Zeng”).
Regarding claim 22, Vijayvargiya teaches A computer-implemented method for use with a package repository including software packages that include source portable and linkable executable files (column 5 lines 24-38: discussing about computing a hash value of an executable file in a software installer package), the method comprising:
populating a mapping database by, for each of a plurality of the source portable and linkable executable files having a file format: calculating a hash value of a pre-defined subset of sections of the source portable and linkable executable file (column 5 lines 24-38: In an embodiment, when an executable file is being processed, the file integrity checker 330 computes a hash of the executable file using a hashing algorithm, such as the secure hash algorithm 256 (SHA-256). The computed hash of the executable file is then compared to a stored hash of the executable file, which may be included in a file hash database 334. In some embodiments, the file hash database 334 may be included in a database of a package manager running in the VM endpoint device, such as an RPM Package Manager (RPM) database, which may be stored locally in the storage of the host computer (e.g., in a virtual disk of the VM endpoint device 222) on which the VM endpoint device is being hosted. The stored hash of the executable file may be included in a software installer package that included the executable file. Examiner interprets that computing a hash value of an executable file in a software installer package using a hashing algorithm as claimed calculating a hash value of a pre-defined subset of sections of the source portable and linkable executable file…); and
storing, in the mapping database, the calculated hash value in association with (a) an identifier of the source portable and linkable executable file and (b) an identifier of the software package of the source portable and linkable executable file (column 2 lines 50-55: The digital signature key for a specific executable file may be a key used only for that executable file or may be used for a software installer package that included that specific executable file, such as a Pretty Good Privacy (PGP) signature key used to sign a software package. Column 5 lines 28-36: The computed hash of the executable file is then compared to a stored hash of the executable file, which may be included in a file hash database 334. In some embodiments, the file hash database 334 may be included in a database of a package manager running in the VM endpoint device, such as an RPM Package Manager (RPM) database, which may be stored locally in the storage of the host computer (e.g., in a virtual disk of the VM endpoint device 222) on which the VM endpoint device is being hosted. Column 6 lines 6-12: In other cases, the digital signature key for the executable file is a digital signature key exclusively for the executable file, which is stored locally when the executable file is installed or loaded in the VM endpoint device. In some embodiments, the digital signature key for the executable file may be stored in a package manager database, such as an RPM database. Examiner interprets that RPM database stores the computed hash of the executable file, the digital signature key for the executable file and the signature key of a software package as claimed storing, in the mapping database, the calculated hash value in association with an identifier of the source portable and linkable executable file and an identifier of the software package of the source portable and linkable executable file.).
Vijayvargiya does not explicitly teach calculating a hash value of a pre-defined subset of sections of the source portable and linkable executable file, the pre-defined subset defined for the file format and including some of and fewer than all of the sections specified by the file format.
Zeng teaches calculating a hash value of a pre-defined subset of sections of the source portable and linkable executable file, the pre-defined subset defined for the file format and including some of and fewer than all of the sections specified by the file format ([0049]: In the embodiment of the present disclosure, the code segment hash can be obtained by program, for example, obtained by calculating using a hash algorithm for .text segments of all executable files.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the computing a hash value of an executable file of Vijayvargiya with the teaching about the code segment hash of Zeng because the terminal operation information is detected by using a preset matching strategy, the legitimacy of the terminal can be detected in various aspects, which has pertinence, the reliability is higher, and data leakage risk can be avoided (Zeng, [0025]).
Claim 66 is rejected under the same rationale as claim 22. Vijayvargiya also teaches A computing system for use with a package repository including software packages that include source portable and linkable executable files (column 5 lines 24-38: discussing about computing a hash value of an executable file in a software installer package), the computing system comprising: a mapping database (column 5 lines 28-36: The computed hash of the executable file is then compared to a stored hash of the executable file, which may be included in a file hash database 334. In some embodiments, the file hash database 334 may be included in a database of a package manager running in the VM endpoint device, such as an RPM Package Manager (RPM) database, which may be stored locally in the storage of the host computer (e.g., in a virtual disk of the VM endpoint device 222) on which the VM endpoint device is being hosted.); one or more hardware processors; and one or more storage devices having stored computer-executable instructions that are executable by the one or more hardware processors for configuring the computing system to perform the following… (column 3 lines 39-47: As shown in FIG. 2, the host computer 200 includes a physical hardware platform 210, which includes at least one or more processors 212, one or more system memories 214, a network interface 216 and a storage 218. Each processor 212 can be any type of a processor, such as a central processing unit (CPU) commonly found in a server computer. Each system memory 214, which may be random access memory (RAM), is the volatile memory of the host computer.).
Regarding claim 91, Vijayvargiya in view of Zeng teaches wherein the pre-defined subset of the sections includes a code segment (Zeng, [0049]: In the embodiment of the present disclosure, the code segment hash can be obtained by program, for example, obtained by calculating using a hash algorithm for .text segments of all executable files.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the computing a hash value of an executable file of Vijayvargiya with the teaching about the code segment hash of Zeng because the terminal operation information is detected by using a preset matching strategy, the legitimacy of the terminal can be detected in various aspects, which has pertinence, the reliability is higher, and data leakage risk can be avoided (Zeng, [0025]).
Regarding claim 92, Vijayvargiya in view of Zeng teaches wherein the pre-defined subset of the sections does not include a resource section (Zeng, [0009]: obtaining pre-stored terminal operation information, and matching the terminal operation information with the pre-stored terminal operation information according to a preset matching strategy).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the computing a hash value of an executable file of Vijayvargiya with the teaching about the code segment hash of Zeng because the terminal operation information is detected by using a preset matching strategy, the legitimacy of the terminal can be detected in various aspects, which has pertinence, the reliability is higher, and data leakage risk can be avoided (Zeng, [0025]).
Regarding claim 95, Vijayvargiya in view of Zeng teaches for at least a portion of deployed portable and linkable executable files that are included in a deployment package and have the file format: calculating a hash value of the pre-defined subset of the sections of the deployed portable and linkable executable file, looking up the calculated hash value of the deployed portable and linkable executable file in the mapping database, if the calculated hash value is found in the mapping database, triggering a rule associated with a status of the software package containing the source portable and linkable executable file corresponding, based on the calculated hash value, to the deployed portable and linkable executable file, and if the calculated hash value is not found in the mapping database, triggering a not-found rule (Vijayvargiya, column 4 lines 43-54: The digital signature key for the executable file is a key used to sign the executable file or a software installer package that included the executable file by the vendor of the executable file or an agent of the vendor. Thus, the digital signature key of the executable file can be viewed as a vendor identifier. If the digital signature key for the executable file matches one of the approved digital signature keys, then the executable file is deemed to be from an approved source, i.e., a trusted vendor, and thus, can be considered to have an approved reputation. In such a case, the executable file is considered to be safe. Otherwise, the reputation of the executable file is deemed to be unknown.).
Claim 102 is rejected under the same rationale as claim 91.
Claim 103 is rejected under the same rationale as claim 92.
Claim 106 is rejected under the same rationale as claim 95.
Claims 93-94 and 104-105 are rejected under 35 U.S.C. 103 as being unpatentable over Vijayvargiya in view of Zeng, and further in view of Xie et al. (US 2015/0020203, hereinafter “Xie”).
Regarding claim 93, Vijayvargiya in view of Zeng teaches the method of claim 22 as discussed above. Vijayvargiya in view of Zeng does not explicitly teach wherein the pre-defined subset of the sections includes all sections specified by the file format other than sections included in a pre-defined blacklist that specifies sections for exclusion from the pre-defined subset.
Xie teaches wherein the pre-defined subset of the sections includes all sections specified by the file format other than sections included in a pre-defined blacklist that specifies sections for exclusion from the pre-defined subset ([0073]: At step 305: scan the PE type file in other file through a black-list saved in the QVM engine to filter a malicious file matched with the blacklist. [0074]: The QVM engine may store the blacklist in advance, and the blacklist includes a confirmed malicious PE type file.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the computing a hash value of an executable file of Vijayvargiya and Zeng with the teaching about the blacklist/whitelist of Xie because it would increase the clearing speed to improve the effective use of system resources (Xie, [0049]).
Regarding claim 94, Vijayvargiya in view of Zeng teaches the method of claim 22 as discussed above. Vijayvargiya in view of Zeng does not explicitly teach defining a manifest specifying the sections of the pre-defined subset for the file format, wherein the manifest is a whitelisting manifest that lists the sections of the pre-defined subset.
Xie teaches defining a manifest specifying the sections of the pre-defined subset for the file format, wherein the manifest is a whitelisting manifest that lists the sections of the pre-defined subset ([0126]: discussing about when scanning through a pre-saved whitelist, the filename of each file in other file may be compared with the filename pre-saved in the whitelist, and when a filename of a certain file is matched with a pre-saved filename, it can be determined that the file belongs to a non-malicious file of the second target file).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the computing a hash value of an executable file of Vijayvargiya and Zeng with the teaching about the blacklist/whitelist of Xie because it would increase the clearing speed to improve the effective use of system resources (Xie, [0049]).
Claim 104 is rejected under the same rationale as claim 93.
Claim 105 is rejected under the same rationale as claim 94.
Allowable Subject Matter
Claims 96-101 and 107-114 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.
Regarding claim 96 and 107, the prior arts of made record fail to teach populating a status indication data structure with respective status indicators for the software packages, each of the status indicators selected from a prespecified list of status indicators, and associating respective rules with the status indicators, and wherein, for each of the deployed portable and linkable executable files for which the hash value was found in the mapping database, triggering the rule comprises triggering the rule associated with the status indicator of the software package containing the source portable and linkable executable file corresponding, based on the calculated hash value, to the deployed portable and linkable executable file.
Regarding claim 99 and 110, the prior arts of made record fail to teach generating a software bill of materials (SBOM) for a deployment package that includes deployed portable and linkable executable files, by, for at least a portion of the deployed portable and linkable executable files having the file format: calculating a hash value of the pre-defined subset of the sections of the deployed portable and linkable executable file, looking up the calculated hash value of the deployed portable and linkable executable file in the mapping database, if the calculated hash value is found in the mapping database, creating an entry in the SBOM that includes at least:
(a) an identifier of the deployed portable and linkable executable file, (b) an identifier of the source portable and linkable executable file corresponding, based on the calculated hash value, to the deployed portable and linkable executable file, and (c) an identifier of the software package containing the source portable and linkable executable file, and if the calculated hash value is not found in the mapping database, creating an entry in the SBOM that includes at least: (a) an identifier of the deployed portable and linkable executable file, and (b) an indicator that the deployed portable and linkable executable file is not associated with any of the software packages contained in the package repository.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Choyi et al. (US 2021/0314171) discloses that XNF database 510 may include a data structure to store certificate policies, a CRT, and/or calculated hash values for xNFs software package 130, each of which may be provided by management function 110. As shown in FIG. 5, DB 510 may include, for each xNF 130, an xNF identifier 512, a hash value 514 of the xNF software package, a CAL 516, and a certificate issue flag 518. XNF identifier 512 may include a unique identifier for a VNF or CNF (e.g., “xNF_ID_1”).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHONG H NGUYEN whose telephone number is (571)270-1766. The examiner can normally be reached Monday-Friday, 8:30am-5pm 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, Ajay Bhatia can be reached at (571) 272-3906. 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.
/PHONG H NGUYEN/ Primary Examiner, Art Unit 2156
March 24, 2026