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 is the initial Office action based on the application filed on February 24, 2025.
Claims 1-17, 20, and 24-25 are presently pending in the application have been examined below, of which, claims 1, 9, and 20 are presented in independent form.
Claims 18-19 and 21-23 were canceled in the preliminary amendment filed on February 24, 2025.
Allowable Subject Matter
Claim 17 is 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.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8, 20 and 24-25 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception.
Under Prong 1 Step 2A of MPEP Revised Patentable Subject Matter Analysis: claim 1 “determining an anomaly impact index corresponding to each anomaly type of a target SDK according to the SDK information, the host information, and the SDK anomaly information of each anomaly type, wherein the target SDK corresponds to a host program indicated by the host information and an SDK version indicated by the SDK information” as drafted, recites functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitations encompass a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas under Prong 1 Step 2A of MPEP Revised Patentable Subject Matter Analysis.
Under Prong 2 Step 2A of MPEP Revised Patentable Subject Matter Analysis, this judicial exception is not integrated into a practical application. The claim recites the following additional elements “a repair platform” and “user terminal”. The elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
The additional elements “obtaining SDK information, host information and SDK anomaly information of different anomaly types”, “obtaining a target SDK repair policy according to the anomaly impact index corresponding to each anomaly type of the target SDK and a preset anomaly grading processing rule, wherein the target SDK repair policy includes an SDK repair policy, in the anomaly grading processing rule, with an anomaly level corresponding to an anomaly impact index” and “delivering the target SDK repair policy to a user terminal, so that the user terminal executes the target SDK repair policy to repair the target SDK” are merely insignificant extra solution activity of gathering data and transmitting data, which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g).
Under Step 2B of MPEP Revised Patentable Subject Matter Analysis, The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements “a repair platform” and “user terminal” are the mere use of generic computer to implement the abstract idea, as discussed above, which does not amount to significantly more, thus, not an inventive concept, and the additional elements “obtaining SDK information, host information and SDK anomaly information of different anomaly types”, “obtaining a target SDK repair policy according to the anomaly impact index corresponding to each anomaly type of the target SDK and a preset anomaly grading processing rule, wherein the target SDK repair policy includes an SDK repair policy, in the anomaly grading processing rule, with an anomaly level corresponding to an anomaly impact index” and “delivering the target SDK repair policy to a user terminal, so that the user terminal executes the target SDK repair policy to repair the target SDK” are merely insignificant extra solution activity of gathering data, and transmitting data. The courts have identified gathering data and transmitting data as well- understood, routine and conventional activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368, 125 USPQ2d 1649, 1654 (Fed. Cir. 2018)), thus, cannot amount to an inventive concept. Accordingly, the claim does not appear to be patent eligible under 35 USC 101. See MPEP 2106.05 (d).
Claims 2-8 are dependent on claim 1 and includes all the limitations of claim 1. The claim 2 adds an additional mental process of “calculating an anomaly impact factor corresponding to each anomaly type of the target SDK according to the feature information and the weights of the feature information; calculating an output ratio corresponding to each anomaly type of the target SDK according to a number of the SDK anomaly information of each anomaly type of the target SDK and a total number of the SDK anomaly information; and calculating the anomaly impact index corresponding to each anomaly type of the target SDK by using the anomaly impact factor and the output ratio corresponding to each anomaly type of the target SDK”.
Claim 3 adds an additional mental process of “determining a target anomaly type according to the anomaly impact index corresponding to each anomaly type, wherein the target anomaly type is an anomaly type corresponding to an anomaly impact index having a largest value; and according to the anomaly grading processing rule, determining an anomaly level corresponding to the target anomaly type and the anomaly impact index of the target anomaly type, and determining the target SDK repair policy according to the anomaly level”.
Claim 7 adds additional obtaining and transmitting data processes, which are insignificant extra solution activity of gathering data, and transmitting data.
Claims 4-6 and 8 merely add more text descriptions of the target SDK repair policy. Therefore, claim 2-18 recite the same abstract idea without any additional limitation that would amount to significantly more than the abstract idea defined in independent claim 1.
Therefore, claim 2-8 recite the same abstract idea without any additional limitation that would amount to significantly more than the abstract idea defined in independent claim 1.
Claims 20 and 24-25 are electronic device claims corresponding to method claims 1-3. The claims merely recite additional elements “electronic device” and “a processor and a memory storing computer program instructions”. These additional elements again merely use a generic computer or computer components as a tool to perform the abstract idea, thus is not integrated into a practical application under Prong 2, or amount to significantly more than the judicial exception under Step 2B.
Therefore, claims 20 and 24-25 are rejected under the same rational set forth in the rejection of claim 1.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 8-9, 11, 16, and 20-25 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0097733 (hereinafter "Nelson”), in view of in view of CN 113961226 A (hereinafter “Wei”), and further in view US 2021/0273968 (hereinafter “Shaieb”).
In the following claim analysis, Applicant’s claim limitations are presented in bold text, the Examiner’s explanations, notes, and remarks are enclosed in square brackets; and emphasized portions are underlined.
As to claim 1, Nelson discloses A software repair method (Nelson, ¶ 8. methods and systems that may be implemented to identify and roll out needed software and firmware fixes automatically), firmware fixes automatically), applied to a repair platform (Nelson, ¶ 8, identification of a given third party software or firmware component (e.g., given third party software or firmware library) vulnerability and the roll out (e.g., distribution) of a corresponding fix to address the identified vulnerability to all the different affected software and firmware applications that are affected by the identified third party component vulnerability, e.g., including tools and applications provided by original equipment manufacturers (OEMs) of endpoint information handling systems), comprising:
obtaining [software] information (Nelson, ¶ 10, producing a catalog including current versions of one or more software or firmware components used by a software or firmware application together with information that specifies that the identity of at least one software or firmware application that uses the one or more software or firmware components), host information (Nelson, ¶ 38, enhanced inventory collector agent 105 executing on endpoint client system 100 (and executing on any other endpoint client systems 159) may produce an inventory that identifies individual installed applications (e.g., individual vendor certified applications) on the endpoint client system/s 100/159) and [software] anomaly information of different anomaly types (Nelson, Fig. 2, ¶ 29, automatically capture notifications from the library scanning tools executing on servers 145, 149 and 151 whenever a new vulnerability is confirmed by any of these library scanning tools executing on servers 145, 149 and 151. Such a software or firmware vulnerability may be a security flaw or weakness in a software or firmware component that may be, for example, exploited by a bad actor to interfere with and/or negatively impact operation of the software or firmware in such a way as to compromise its integrity and/or confidentiality, and/or to render it inoperable or unavailable);
determining an anomaly impact index corresponding to each anomaly type of a target [software] according to the [software] information (Nelson, Fig. 2, ¶ 30, vulnerability information such as a common vulnerability scoring system (CVSS) score and/or common vulnerabilities and exposures (CVE) details that have been determined for each new discovered vulnerability. … a CVSS score indicates a qualitative measure of vulnerability severity (based on metrics of exploitability and impact)), the host information (Nelson, ¶ 38), and the [software] anomaly information of each anomaly type (Nelson, ¶ 9, automatically identify types and status of vulnerabilities in identified software or firmware components (e.g., libraries), and then seamlessly and automatically deploy security vulnerability fixes (e.g., patches or updates) in these identified components across different affected software or firmware applications; Fig. 2, ¶ 29), wherein the target [software] corresponds to a host program indicated by the host information (Nelson, ¶ 10, producing an inventory that identifies installed software or firmware applications on an endpoint client system; ¶ 11, install the new version of the first software or firmware component onto the endpoint client system for use by the at least one installed software or firmware application) and an [software] version indicated by the [software] information (Nelson, Fig. 2, ¶ 37, the IT administrator/s may view the vulnerability information (e.g., CVSS score, CVE details, etc.) and affected applications … and use this information to select particular available software and/or firmware library fix/es to prioritize and deploy first in a custom catalog (e.g., according to severity of vulnerability addressed by the fixes, importance of applications affected, etc.); ¶ 10, producing a catalog including current versions of one or more software or firmware components used by a software or firmware application together with information that specifies that the identity of at least one software or firmware application that uses the one or more software or firmware components; ¶ 26, automatically deploy vulnerability fixes for software and firmware components executing on endpoint client system 100).
Nelson discloses software repairing, but does not appear to explicitly disclose that software can be SDK and SDK information is obtained (Wei, pg. 3, para. 1, based on the local patch of each SDK and the plurality of repair patches in the terminal, determining the latest patch for each SDK; pg. 5, the last paragraph, the local patch is the patch of the old version, needs to be repaired). However, in an analogous art to the claimed invention in the field of software repairment, Wei teaches software can be SDK (Wei, Abstract a tool bag repairing method of the software development of the tool packet (Software Development Kit, SDK; the last paragraph of pg. 2, obtaining the repairing patch generated by the server aiming at each SDK in multiple SDKs) and SDK information is obtained (Wei, pg. 3, para. 1, based on the local patch of each SDK and the plurality of repair patches in the terminal, determining the latest patch for each SDK; pg. 5, the last paragraph, the local patch is the patch of the old version, needs to be repaired).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nelson’s teaching with the teaching taught by Wei. The modification would be obvious because one of ordinary skill in the art would be motivated to detect whether the repairing patch is consistent with the corresponding local patch and determine if the repair patch and the corresponding local patch are not consistent, determining the repair patch is the latest patch of the corresponding SDK to ensure a successful patch process.
Nelson as modified discloses SDK as software target SDK repair, but does not appear to explicitly disclose obtaining a target SDK repair policy according to the anomaly impact index corresponding to each anomaly type of the target SDK and a preset anomaly grading processing rule, wherein the target SDK repair policy includes an SDK repair policy, in the anomaly grading processing rule, with an anomaly level corresponding to an anomaly impact index; and delivering the target SDK repair policy to a user terminal, so that the user terminal executes the target SDK repair policy to repair the target SDK. However, in an analogous art to the claimed invention in the field of software update, Shaieb teaches disclose obtaining a target SDK repair policy according to the anomaly impact index corresponding to each anomaly type of the target SDK (Shaieb, ¶ 6 describes a repair policy and ¶ 52, a repair policy in: A vulnerability risk management service that implements VRC risk scoring may provide a pre-scan vulnerability ranking and complexity score for a piece of software and its associated vulnerabilities … the information presented may include: … a CVSS severity ranking, a highest CVSS score found in collection of identified CVEs (Common Vulnerability Enumerations), other scores (e.g., a count of Qualys® identifiers), etc.) and a preset anomaly grading processing rule (Shaieb, claim 1, for each of one or more patches in a set of patches, computing a score that quantifies a remediation cost of a patching operation to install the patch; determining a priority order of applying the set of patches based at least in part on the scores), wherein the target SDK repair policy includes an SDK repair policy (Shaieb, Fig. 4, ¶ 40, the report 412 is a prioritized list of which vulnerabilities should be focused on first … each vulnerability identified on the list includes a title, severity ranking, category, associated threat, proposed solution and remediation schedule), in the anomaly grading processing rule, with an anomaly level corresponding to an anomaly impact index (Shaieb, Fig. 4, ¶ 40, each vulnerability identified on the list includes a title, severity ranking, category, associated threat, proposed solution and remediation schedule. Vulnerabilities with a low CVSS (Common Vulnerability Scoring System) score may be at the top of the list for remediation if they affect a high-value asset and are being weaponized); and delivering the target SDK repair policy to a user terminal (Shaieb, ¶ 57, a vulnerability remediation complexity (VRC) risk score … may also be associated with a confidence value or level (e.g., high) … For any particular vulnerability that needs remediation, an appropriate VRC is computed and output [including the report 412] either to a remediator (for manual remediation) [in the remediator’s terminal]… ), so that the user terminal executes the target SDK repair policy to repair the target SDK (Shaieb,Fig. 5, ¶ 47, the VRC scoring augments the vulnerability scoring, typically resulting in adjusting the patch order by prioritizing at least one high severity vulnerability with smaller remediation cost (lower VRC) over a similar high severity vulnerability with higher remediation cost (higher VRC) or other lower severity or high remediation cost patches; ¶ 48, the patches are then applied by a patch tool 514).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nelson’s teaching as modified with the teaching taught by Shaieb. The modification would be obvious because one of ordinary skill in the art would be motivated to provide software patch management that ranks patches at least in part according to a score indicative of a complexity (e.g., cost) of remediating a vulnerability. This score is sometimes referred to herein as a vulnerability remediation complexity (VRC) score. A VRC score provides an objective measure by which an organization can determine which patches are most likely to be successfully applied, thus enabling implementation of a patching strategy that preferentially applies most critical, but less impact (in terms of remediation cost) patches first to remediate as must risk as possible as quickly as possible. Thus, for example, the approach herein enables the patching to focus on vulnerabilities of highest severity and small remediation cost over those, for example, representing lower severity and higher remediation cost (Shaieb, Abstract).
As to claim 2, the rejection of claim 1 is incorporated. Nelson as modified further discloses The method according to claim 1, wherein determining the anomaly impact index corresponding to each anomaly type of the target SDK according to the SDK information, the host information and the SDK anomaly information of each anomaly type comprises: determining the target SDK according to the SDK information (Wei, pg. 4, para. 9, determining a latest patch for each SDK based on the local patch of each SDK and the plurality of repair patches in the terminal) and the host information (Wei, pg. 8, the last paragraph, sending the generated plurality of repair patches and the management information corresponding to each repair patch to the terminal after receiving a patch request of the terminal), and obtaining feature information in the SDK anomaly information of each anomaly type of the target SDK as well as weights of the feature information (Shaieb, ¶ 47, The patches in the patch queue address vulnerabilities that have been identified for patching (by other systems), and in effect these vulnerabilities are scored by both the vulnerability scoring system 510 (for severity [a weight]));
calculating an anomaly impact factor corresponding to each anomaly type of the target SDK according to the feature information and the weights of the feature information (Shaieb, claim 1, receiving a set of patches for install in a set of computer systems in the computer network; for each of one or more patches in a set of patches, computing a score that quantifies a remediation cost of a patching operation to install the patch; determining a priority order [a impact factor] of applying the set of patches based at least in part on the scores);
calculating an output ratio corresponding to each anomaly type of the target SDK according to a number of the SDK anomaly information of each anomaly type of the target SDK and a total number of the SDK anomaly information (Shaieb, claim 2, the priority order prioritizes for install at least one patch in the set of patches that is associated with a high severity vulnerability but that has a low remediation cost); and
calculating the anomaly impact index corresponding to each anomaly type of the target SDK by using the anomaly impact factor and the output ratio corresponding to each anomaly type of the target SDK (Shaieb, claim 1 and 5-6, the remediation cost for a given patch is determined at least in part by an impact to an availability of the computer system that is a target of the patching operation for the given patch … the remediation cost for a given patch is determined at least in part by a criticality of the computer system that is a target of the patching operation for the given patch).
The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 3, the rejection of claim 1 is incorporated. Nelson as modified further discloses The method according to claim 1, wherein obtaining the target SDK repair policy according to the anomaly impact index corresponding to each anomaly type of the target SDK and the preset anomaly grading processing rule comprises:
determining a target anomaly type according to the anomaly impact index corresponding to each anomaly type (Nelson, ¶ 9, identify types and status of vulnerabilities in identified software or firmware components (e.g., libraries); ¶ 30, vulnerability information such as a common vulnerability scoring system (CVSS) score and/or common vulnerabilities and exposures (CVE) details that have been determined for each new discovered vulnerability. … a CVSS score indicates a qualitative measure of vulnerability severity (based on metrics of exploitability and impact)), wherein the target anomaly type is an anomaly type corresponding to an anomaly impact index having a largest value (Shaieb, ¶ 40, providing remediators with manageable lists of the most critical vulnerabilities to fix first); and
according to the anomaly grading processing rule, determining an anomaly level corresponding to the target anomaly type and the anomaly impact index of the target anomaly type (Shaieb, Fig. 4, ¶ 40, each vulnerability identified on the list includes a title, severity ranking, category, associated threat, proposed solution and remediation schedule), and determining the target SDK repair policy according to the anomaly level (Shaieb, claims 1-6).
The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 4, the rejection of claim 1 is incorporated. Nelson as modified further discloses The method according to claim 1, wherein the target SDK repair policy includes one or more of the following:
a first file, wherein the first file includes a cache data clearing instruction, and the cache data clearing instruction is used to instruct to clear data in at least one cache folder corresponding to the target SDK (Wei, pg. 7, para. 1-2, after determining that the repair patch is the latest patch of the corresponding SDK if the repair patch is inconsistent with the corresponding local patch, the method includes: deleting the local patch corresponding to the repair patch; pg. 8, para. 17, clearing the historical patch information);
a second file, wherein the second file includes an anomaly source blocking instruction, and the anomaly source blocking instruction is used to instruct to set an on/off state of at least one service function and/or sub-service function of the target SDK to an off state (Shaieb, ¶ 32, The agent continuously assesses the state of the endpoint against a stated policy, whether connected to the network or not. As soon as the agent notices that a target is out [off] of compliance with a policy or checklist, it informs the server 306) ; and
a third file, wherein the third file includes a patch file, and the patch file is used to upgrade and repair the target SDK (Wei, pg. 9, para. 3, a plurality of generated repair patches and management type information corresponding to each repair patch are sent to the terminal, the terminal determines the latest patch aiming at each SDK through acquiring the repair patch generated by a server aiming at each SDK in a plurality of software development kit SDKs, based on the local patch aiming at each SDK in the terminal and the plurality of repair patches, the determined latest patches aiming at each SDK are fused to obtain a fused patch package aiming at the plurality of SDKs, and the plurality of SDKs are repaired by using the fused patch package). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 8, the rejection of claim 1 is incorporated. Nelson as modified further discloses The method according to claim 1, wherein the target SDK repair policy is executed by a repair process established by the user terminal (Nelson, Fig. 2, ¶ 37, In block 216, the IT administrator/s may view the vulnerability information (e.g., CVSS score, CVE details, etc.) and affected applications for each available software and/or firmware library fix (e.g., on a display device of tech portal server 146), and use this information to select particular available software and/or firmware library fix/es to prioritize and deploy first in a custom catalog), and the repair process is independent of a target SDK processing (Nelson, Fig. 2, ¶ 39, in block 222 [independent of block 216], update agent 103 and/or other catalog server 152 installs the identified software and/or firmware library fixes from block 220 on to endpoint information handling system/s 100/159, e.g., by patching or updating the particular application/s identified in the inventory of metadata on system/s 100/159).
As to claim 9, the claim is a method claim with similar obtaining/providing, transmitting, and executing target SDK repair policy claim limitations as in claim 1, and the claim does not require to determine an anomaly impact index corresponding to each anomaly type of a target SDK according to the SDK information. Therefore, the claim is rejected under the same rational set forth in the rejection of claim 1.
As to claim 11, the rejection of claim 9 is incorporated. Nelson as modified does not appear to explicitly disclose The method according to claim 9, wherein the anomaly level corresponding to the target SDK repair policy is obtained (Shaieb, Fig. 4, ¶ 40 ) according to the anomaly grading processing rule (Shaieb, claim 1, for each of one or more patches in a set of patches, computing a score that quantifies a remediation cost of a patching operation to install the patch; determining a priority order of applying the set of patches based at least in part on the scores), a target anomaly type and an anomaly impact index of the target anomaly type (Nelson, ¶¶ 9 and 30), and the target anomaly type is an anomaly type corresponding to an anomaly impact index with a largest value (Shaieb, ¶ 40). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 12, the rejection of claim 9 is incorporated. The claim limitations are corresponding to claim 4. Therefore, it is ejected under the same rational set forth in the rejection of claim 4.
As to claim 16, the rejection of claim 9 is incorporated. Nelson as modified further discloses The method according to claim 9, wherein obtaining the target SDK repair policy from the repair platform and executing the target SDK repair policy to repair the target SDK comprises: establishing a repair process (Nelson, Fig. 2, ¶ 37), wherein the repair process is independent of a target SDK processing (Nelson, Fig. 2, ¶ 39); and obtaining the target SDK repair policy (Shaieb, ¶ 6 describes a repair policy and ¶ 52 ) from the repair platform through the repair process (Nelson, Fig. 2, ¶ 37), and executing the target SDK repair policy to repair the target SDK (Shaieb, Fig. 5, ¶¶ 47-48).
The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 20, 24-25, the claims are device claims corresponding to method claims 1-3. Therefore, they are rejected under the same rational set forth in the rejections of claims 1-3.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0097733 (hereinafter "Nelson”), in view of in view of CN 113961226 A (hereinafter “Wei”), in view US 2021/0273968 (hereinafter “Shaieb”), and further in view of US 10,579,803 (hereinafter “Mueller”).
As to claim 5, the rejection of claim 4 is incorporated. Nelson as modified further discloses The method according to claim 4, wherein the target SDK repair policy includes the third file (Wei, pg. 9, para. 3), but does not appear to explicitly disclose the method further includes: obtaining a pre-repair SDK archive file and a post-repair SDK archive file of the target SDK; obtaining a first class file and a second class file, wherein the first class file includes a class file in the pre-repair SDK archive file, and the second class file includes a class file in the post-repair SDK archive file; using a comparison algorithm to compare the first class file and the second class file to obtain a third class file, wherein the third class file includes a class file indicating a difference between the second class file and the first class file; and converting the third class file into the patch file.
However, in an analogous art to the claimed invention in the field of software update Mueller teaches the method further includes: obtaining a pre-repair SDK archive file (Mueller, col. 2, ln. 10-12, generating a list of deltas indicating whether the delta is a new issue found in the current load, the absence of an issue found in a previous load, or a modified issue) and a post-repair SDK archive file of the target SDK (Mueller, col. 2, ln. 26-29, The system can automatically establish the changes across all issues from various scanning and issue tracking tools and consolidate the results in one comprehensive list); obtaining a first class file (Mueller, col. 9, ln. 7-9, a delta can be caused by the change in a set of data fields from the previous load) and a second class file (Mueller, col. 9, ln. 9-12, a delta can be caused by the change in a set of data fields from the previous load, as shown in block 416. The delta is then stored in a delta table), wherein the first class file includes a class file in the pre-repair SDK archive file (Mueller, col. 2, ln. 10-12, generating a list of deltas indicating whether the delta is a new issue found in the current load), and the second class file includes a class file in the post-repair SDK archive file (Mueller, col. 9, ln. 9-12, a delta can be caused by the change in a set of data fields from the previous load, as shown in block 416); using a comparison algorithm to compare the first class file and the second class file to obtain a third class file (Mueller, col. 8, ln. 54-55, very data load is compared against the previous load to find the delta (change) involved), wherein the third class file includes a class file indicating a difference between the second class file and the first class file (Mueller, claim 3, store in table of deltas an indication of whether the delta is a new software vulnerability found in the current load).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nelson’s teaching as modified with the teaching taught by Mueller. The modification would be obvious because one of ordinary skill in the art would be motivated to implement an issue table maintained by AVMS combines all unique issues from all the different issue systems such as a static code scan system or open source code scan system to identify if there are any necessary updates to that issue table. Such updates consist of issues that need to be added, issues where some attributes need to be updated, and issues where the status needs to change to “Deleted” because they are no longer present in the latest scan. Because the system implements the delta logic and updates the issue table, the work that has been performed with existing issues is preserved (Mueller, col. 9, ln. 13-30).
Therefore, Nelson as modified teaches converting the third class file into the patch file (Wei, pg. 9, para. 3).
As to claim 13, the rejection of claim 12 is incorporated. Nelson as modified discloses The method according to claim 12, wherein: the target SDK repair policy includes the third file (Wei, pg. 9, para. 3,), the patch file is converted from a third class file (Wei, pg. 9, para. 3, based on the local patch aiming at each SDK in the terminal and the plurality of repair patches, the determined latest patches aiming at each SDK are fused to obtain a fused patch package aiming at the plurality of SDKs, and the plurality of SDKs are repaired by using the fused patch package), but does not appear to explicitly disclose the third class file includes a class file indicating a difference between a second class file and a first class file, the first class file includes a class file in a pre-repair SDK archive file of the target SDK, and the second class file includes a class file in a post-repair SDK archive file of the target SDK. However, in an analogous art to the claimed invention in the field of software update, Mueller teaches the third class file includes a class file indicating a difference between a second class file and a first class file (Mueller, col. 8, ln. 54-55, very data load is compared against the previous load to find the delta (change) involved), the first class file includes a class file in a pre-repair SDK archive file of the target SDK (Mueller, col. 9, ln. 7-9, a delta can be caused by the change in a set of data fields from the previous load), and the second class file includes a class file in a post-repair SDK archive file of the target SDK (Mueller, col. 9, ln. 9-12, a delta can be caused by the change in a set of data fields from the previous load, as shown in block 416. The delta is then stored in a delta table).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nelson’s teaching as modified with the teaching taught by Mueller. The modification would be obvious because one of ordinary skill in the art would be motivated to implement an issue table maintained by AVMS combines all unique issues from all the different issue systems such as a static code scan system or open source code scan system to identify if there are any necessary updates to that issue table. Such updates consist of issues that need to be added, issues where some attributes need to be updated, and issues where the status needs to change to “Deleted” because they are no longer present in the latest scan. Because the system implements the delta logic and updates the issue table, the work that has been performed with existing issues is preserved (Mueller, col. 9, ln. 13-30).
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0097733 (hereinafter "Nelson”), in view of in view of CN 113961226 A (hereinafter “Wei”), in view US 2021/0273968 (hereinafter “Shaieb”), and further in view of US 2022/0012044 (hereinafter “Renke”).
As to claim 6, the rejection of claim 1 is incorporated. Nelson as modified does not appear to explicitly disclose The method according to claim 1, wherein the target SDK repair policy further includes a first signature file, and the method further includes: generating a first signature according to the host information; and generating a first signature file according to the first signature, wherein the first signature fil includes the first signature. However, in an analogous art to the claimed invention in the field of software update, Renke teaches The method according to claim 1, wherein the target SDK repair policy further includes a first signature file (Renke, ¶ 17, one or more of the coldpatched binaries 114 and/or the hotpatch binaries 115 is associated with a corresponding digital signature), and the method further includes: generating a first signature according to the host information (Renke, ¶ 19, the loader 113 and/or hotpatch engine 110 will check policies 109 and load the hotpatch binaries 115 instances according to policy … computer system [a host]101a/101b may not have cold patches; ¶ 31. an operating environment is considered to be in a known compliance state if it meets certain secure boot requirements and/or if there is an appropriate digital signature [a first signature according to the host in the environment] audit trail); and generating a first signature file according to the first signature, wherein the first signature fil includes the first signature (Renke, claim 10, each of the one or more coldpatched binary files and the one or more hotpatch binary files are associated with a corresponding digital signature).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nelson’s teaching as modified with the teaching taught by Renke. The modification would be obvious because one of ordinary skill in the art would be motivated to determine the patching state of the particular software component including verifying, from the patch log, validity of a chain of two or more of corresponding digital signatures to ensure secure patching process (Renke, ¶ 45).
As to claim 14, the rejection of claim 9 is incorporated. Nelson as modified discloses The method according to claim 9, wherein: the target SDK repair policy further includes a first signature file, the first signature file includes a first signature (Renke, ¶ 17), and the first signature is generated by the repair platform according to the host information (Renke, ¶ 19); after obtaining the target SDK repair policy from the repair platform (Shaieb, Fig. 4, ¶ 40), the method further includes: calling the host program indicated by the host information to verify the first signature (Renke, ¶ 45, one or more of the coldpatched binaries 114 and/or the hotpatch binaries 115 are associated with a digital signature … the patch state determination component 121 may verify from the patch log 111 that a proper sequence of cold and hot patches has been applied based on these signatures); and executing the target SDK repair policy to repair the target SDK includes: executing the target SDK repair policy to repair the target SDK (Shaieb,Fig. 5, ¶ ¶ 47-48) when the host program indicated by the host information successfully verifies the first signature (Renke, ¶ 45).
The motivation to combine the references is the same as set forth in the rejection of claim 6.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0097733 (hereinafter "Nelson”), in view of in view of CN 113961226 A (hereinafter “Wei”), in view US 2021/0273968 (hereinafter “Shaieb”), and further in view of US 2021/0119858 (hereinafter “De Smet”).
As to claim 7, the rejection of claim 1 is incorporated. Nelson as modified further discloses The method according to claim 1, wherein, after obtaining the target SDK repair policy according to the anomaly impact index corresponding to each anomaly type of the target SDK and the preset anomaly grading processing rule, the method further includes:
delivering the target SDK repair policy to a provider platform (Nelson, Fig. 2, ¶ ¶ 36-37, repository manager 142 may provide vulnerability information (e.g., CVSS score, CVE details, etc.) through tech portal server 146 [a provider platform] to IT administrator server 153 for each given available software and/or firmware library fix together with the identity of software and/or firmware applications that employ the software and/or firmware library that is addressed by the given available software and/or firmware library fix. In block 216, the IT administrator/s may view the vulnerability information (e.g., CVSS score, CVE details, etc.) and affected applications for each available software and/or firmware library fix); and
receiving a target SDK repair policy fed back by the provider platform (Nelson, ¶ 37, the IT administrator/s may view the vulnerability information (e.g., CVSS score, CVE details, etc.) and affected applications for each available software and/or firmware library fix (e.g., on a display device of tech portal server 146), and use this information to select particular available software and/or firmware library fix/es ), wherein the fed back target SDK repair policy includes a [custom catalog] (Nelson, ¶ 37, the IT administrator/s may view the vulnerability information (e.g., CVSS score, CVE details, etc.) and affected applications for each available software and/or firmware library fix (e.g., on a display device of tech portal server 146), and use this information to select particular available software and/or firmware library fix/es to prioritize and deploy first in a custom catalog), and [custom catalog] is generated by the provider platform according to the host information after scanning the target SDK repair policy (Nelson, ¶ 37, the IT administrator/s may view the vulnerability information (e.g., CVSS score, CVE details, etc.) and affected applications for each available software and/or firmware library fix (e.g., on a display device of tech portal server 146), and use this information to select particular available software and/or firmware library fix/es to prioritize and deploy first in a custom catalog (e.g., according to severity of vulnerability addressed by the fixes, importance of applications affected, etc.)
Nelson does not appear to explicitly disclose a second signature file, the second signature file includes a second signature and the second signature is generated according to authorizing the target SDK repair policy, wherein delivering the target SDK repair policy to the user terminal includes: authenticate delivering the target SDK repair policy fed back by the provider platform to the user terminal. However, in an analogous art to the claimed invention in the field of software update, De Smet teaches a second signature file (De Smet, ¶ 47, The OTA data file 300 may have two signatures), the second signature file includes a second signature (De Smet, ¶ 47, The OTA data file 300 may have two signatures) and the second signature is generated according to authorizing the target SDK repair policy (De Smet, ¶ 47, One signature authenticates the whole file 300 [e.g., the target SDK repair policy]. The second signature authenticates the compatibility only so that the client node only processes compatibility information from trusted devices), wherein delivering the target SDK repair policy to the user terminal includes: authenticate delivering the target SDK repair policy fed back by the provider platform to the user terminal (De Smet, ¶ 47, The second signature authenticates the compatibility only so that the client node only processes compatibility information [e.g., policy fed back] from trusted devices).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nelson’s teaching as modified with the teaching taught by De Smet. The modification would be obvious because one of ordinary skill in the art would be motivated to include two signatures in a data file. One signature authenticates the whole file 300. The second signature authenticates the compatibility only so that the client node only processes compatibility information from trusted devices. If the verification of the signature fails, the OTA file download should be aborted (De Smet ¶ 47).
As to claim 15, the rejection of claim 9 is incorporated. Nelson as modified further discloses The method according to claim 9, wherein: the target SDK repair policy further includes a second signature file (De Smet, ¶ 47), the second signature file includes a second signature (De Smet, ¶ 47), and the second signature is generated by the provider platform according to the host information after scanning the target SDK repair policy (De Smet, ¶ 47, One signature authenticates the whole file 300 [e.g., the target SDK repair policy]. The second signature authenticates the compatibility only so that the client node only processes compatibility information from trusted devices) and granting authorization (De Smet, ¶ 47); after obtaining the target SDK repair policy from the repair platform (Shaieb, Fig. 4, ¶ 40), the method further includes: calling the host program indicated by the host information to verify the second signature (De Smet, ¶ 47, The second signature authenticates the compatibility only so that the client node only processes compatibility information from trusted devices); and executing the target SDK repair policy to repair the target SDK includes: executing the target SDK repair policy to repair the target SDK (Shaieb,Fig. 5, ¶ ¶ 47-48) when the host program indicated by the host information successfully verifies the second signature (De Smet, ¶ 47).
The motivation to combine the references is the same as set forth in the rejection of claim 7.
Claims 10 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0097733 (hereinafter "Nelson”), in view of in view of CN 113961226 A (hereinafter “Wei”), in view US 2021/0273968 (hereinafter “Shaieb”), and further in view of US 2018/0011700 (hereinafter “Plate”).
As to claim 10, the rejection of claim 10 is incorporated. Nelson as modified further discloses The method according to claim 9, wherein: calculating the anomaly impact index corresponding to each type of anomaly of the target SDK (Nelson, Fig. 2, ¶ 30) using an anomaly impact factor (Shaieb, claim 1) and an output ratio corresponding to each anomaly type of the target SDK (Shaieb, claim 2, the priority order prioritizes for install at least one patch in the set of patches that is associated with a high severity vulnerability but that has a low remediation cost), wherein the output ratio (Shaieb, claim 20 corresponding to each anomaly type of the target SDK is calculated (Shaieb, ¶ 57, vulnerabilities are classified by type or sub-type) according to a number of SDK anomaly information of each anomaly type of the target SDK (Shaieb, ¶ 57, there may be a single VRC score associated with all vulnerabilities within a specified type or sub-type, although preferably a VRC is associated to each vulnerability or, more generally, to each remediation task associated with remediating a vulnerability) and a total number of the SDK anomaly information (Shaieb, claim 2, the priority order prioritizes for install at least one patch in the set of patches [a total number] that is associated with a high severity vulnerability but that has a low remediation cost).
Nelson as modified discloses the anomaly impact factor corresponding to each anomaly type of the target SDK is calculated (Shaieb, claim 1), but does not appear to explicitly disclose the anomaly impact factor corresponding to each anomaly type of the target SDK is calculated according to feature information in the SDK anomaly information of each anomaly type of the target SDK and weights of the feature information. However, in an analogous art to the claimed invention in the field of software update, Shaieb teaches the anomaly impact factor corresponding to each anomaly type of the target SDK is calculated according to feature information in the SDK anomaly information of each anomaly type of the target SDK and weights of the feature information (Plate, ¶ 29, priorities of the software patches corresponding to the identified instances of bug fix patterns [features] are determined based on the classification and pre-defined policy. In one example, the pre-defined policy includes priorities (e.g., low, medium and high) and/or actions (e.g., update, ignore) corresponding to the software).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nelson’s teaching as modified with the teaching taught by Plate. The modification would be obvious because one of ordinary skill in the art would be motivated to identify one or more instances of bug fix patterns in determined code changes; classify the software patches based on the identified bug fix patterns; determine priorities of the software patches corresponding to the identified instances of the bug fix patterns based on the classification and a pre-defined policy; and install the software patches based on the determined priorities (Plate, claim 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2023/0099153 teaches generating remediation plans with respective probabilities of success.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAXIN WU whose telephone number is (571) 270-7721. The examiner can normally be reached on M-F (7 am - 11:30 am; 1:30- 5 pm).
If attempts to reach the examiner by telephone are unsuccessful, the examiner' s supervisor, Wei Mui can be reached at (571) 272-3708. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/DAXIN WU/
Primary Examiner, Art Unit 2191