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 .
This Office Action is in response to Application filed on 05/28/2026. Claims 1, 11, and 20 are independent claims. Claims 1-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
The claim 20 under 35 U.S.C. § 112(f), Applicant respectfully disagrees but holds further discussion of the interpretation under§ 112(f) in abeyance unless necessary to determine the patentability of any claim.
Applicant’s arguments in the application, filed on 05/28/2026, with respect to the prior-art rejections to claims 1, 11, and 20, and limitation listed below, have been fully considered but they are not persuasive.
As to independent claims 1, 11, and 20, Applicant submits that Franco fails to disclose "a second image of the software system including a second code level layout different than the first code level layout" as recited in claim 1. (Applicant Arguments/Remarks, 05/28/2026, pages 11-14).
The Examiner disagrees with the Applicants. The Examiner respectfully that the combination of Franco and Tabone do disclose the cited limitations. For example, Franco discloses a second image of the software system including a second code level layout different than the first code level layout and configured to output a second system level output equal to the first system level output based on a second system level input equal to the first system level input (Franco: Col 5, lines 13-21; a measurement log for a disk image associated with a virtual machine [] the measurement log also be signed by the management entity [i.e., the disk image can be signed/write (first code level layout) and the clone of the disk image read-only (second code level layout)]; Col 6, lines 40-44; generate a clone of the disk image. The clone of the disk image may be a read-only copy of the disk image [i.e., read-only vs signed/write; second code level layout different than the first code level layout], which ensures that no changes can be made to the clone of the disk image during the integrity verification process [i.e., the code level layout would be different and the second system level output equal to the first system level output])
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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-4, 11-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Franco et al. (“Franco,” US 11,334,670, published on 05/17/2022) in view of Tabone et al. (“Tabone,” US 20120131365, published on 05/24/2012).
Regarding Claim 1;
Franco discloses a method for mitigating a cyberattack, the method comprising (Col 1, lines 45-47; a security solution that is capable of detecting a compromised software stack or any compromised part of a software stack executing):
automatically creating, via a software image generation tool, a first image of a software system including a first code level layout and configured to output a first system level output based on a first system level input (Col 3, lines 45-46; a plurality of virtual disks or disk images corresponding to VMs hosted on the host machines; Col 6, line 66 – Col 7, line 2; a file system of the disk image is scanned by the management entity to generate measurements of the files of the disk image; Col 7, lines 15-18; generated, based on the measurements of the files of the cloned disk image or the original disk image, where appropriate. The measurement log contain, for example, file paths and hashes for each of the measured files),
automatically creating, via the software image generation tool, a second image of the software system including a second code level layout different than the first code level layout and configured to output a second system level output equal to the first system level output based on a second system level input equal to the first system level input (Col 5, lines 13-21; a measurement log for a disk image associated with a virtual machine [] the measurement log also be signed by the management entity [i.e., the disk image can be signed/write (first code level layout) and the clone of the disk image read-only (second code level layout)]; Col 6, lines 40-44; generate a clone of the disk image. The clone of the disk image may be a read-only copy of the disk image [i.e., read-only vs signed/write; second code level layout different than the first code level layout], which ensures that no changes can be made to the clone of the disk image during the integrity verification process [i.e., the code level layout would be different and the second system level output equal to the first system level output]),
verifying and validating, via a software verification and validation tool, the first and second images of the software system so as to produce first verification and validation data indicative of the verification and validation of the first and second images (Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing the generated measurement log with a reference measurement of a verification profile previously assigned by the verifier entity to the software stack or the part of a software stack to verify the software stack or the part of a software stack; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image). The management entity configured with scan policy rules which govern which files are measured),
certifying the first and second images based on the first verification and validation data (Col 5, line 60 – Col 6, line5; the verifier entity compare the file path and/or the hash of a measurement of the retrieved measurement log for a particular file of the VM of interest to a file path and/or hash of a corresponding measurement of the verification profile. If the file paths and/or hashes of the file of the VM of interest and the corresponding measurements of the verification profile correspond to one another sufficiently (e.g. are identical) the verifier entity verify the particular file of the VM of interest. This process may be repeated by the verifier entity for all of the files of the VM of interest, or alternatively may be repeated for a subset of the files of the VM of interest, until either all of the files of the VM of interest have been successfully verified),
deploying, via a software deployment management subsystem, the first image of the software system on a first operating system (Col 2, lines 37-43; deployed by service providers to verify the integrity of a software stack, or part of a software stack, that is resident on a host machine, such as a virtual machine, an operating system or an application image that is resident on a host machine),
automatically detecting, via an attack detection tool, a first cyberattack being executed on the first image of the software system operating in the first operating system (Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing the generated measurement log with a reference measurement of a verification profile previously assigned by the verifier entity; Col 6, lines 6-15; verifier entity may determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch [i.e., cyberattack] between a measurement of the measurement log and a corresponding measurement of the verification profile, in which case the verifier entity may a determine that the measurement log does not correspond to the reference measurement), and
in response to detecting the first cyberattack being executed on the first image of the software system operating on the first operating system (Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing; Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log; Col 6, lines 19-28; if the verifier entity determines that the measurement log does not correspond to, or does not sufficiently correspond to, the reference measurement(s) then the verifier entity may generate events that may be presented, e.g. via a user interface or API to a user as verification results to notify the user of the discrepancy between the measurement log and the reference measurement(s). The user, or a user specific orchestration tool, may then take appropriate investigative and/or remedial action).
Franco discloses in response to detecting the first cyberattack being executed on the first image of the software system operating on the first operating system as recited above, but do not explicitly disclose deploying, via the software deployment management subsystem, the second image of the software system on the first operating system in order to disrupt the first cyberattack on the first image of the software system.
However, in an analogous art, Tabone discloses delayed shut down system/method that includes:
deploying, via the software deployment management subsystem, the second image of the software system on the first operating system in order to disrupt the first cyberattack on the first image of the software system (Tabone: par 0086; to verify that the image on each of the devices is still accurate [] if the hashes do not match, indicate that the core components for the operating system on the device have been compromised; par 0093; build a new image for the device 604 and transfer the new image to device. Device 604 may then replace the potentially corrupted image with the new image, and operate with the new image, including by completing the compromised image).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Tabone with the method/system of Franco to include deploying, via the software deployment management subsystem, the second image of the software system on the first operating system in order to disrupt the first cyberattack on the first image of the software system. One would have been motivated to information include an image of a mapped area determined by the application, that automatically integrated into the document that is being managed by process (Tabone: par 0073).
Regarding Claim 2;
The combination of Franco and Tabone disclose the method of claim 1,
Franco discloses wherein the automatic verification and validation of the first image of the software system includes receiving initial software specifications and automatically determining whether the first image of the software system meets the initial software specifications (Franco: Col 6, line 66 – Col 7, line 2; a file system of the disk image is scanned by the management entity to generate measurements of the files of the disk image; Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log).
Regarding Claim 3;
The combination of Franco and Tabone disclose the method of claim 2,
Franco discloses wherein the automatic creation of the second image is carried out after the automatic determination of whether the first image of the software system meets the initial software specifications, and wherein the automatic verification and validation of the second image of the software system includes determining whether the second image of the software system meets the initial software specifications (Franco: Col 7, lines 15-18; generated, based on the measurements of the files of the cloned disk image or the original disk image, where appropriate. The measurement log may contain, for example, file paths and hashes for each of the measured files; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image); Col 5, line 60 – Col 6, line5; the verifier entity compare the file path and/or the hash of a measurement of the retrieved measurement log for a particular file of the VM of interest to a file path and/or hash of a corresponding measurement of the verification profile [] this process may be repeated by the verifier entity for all of the files of the VM of interest, or alternatively may be repeated for a subset of the files of the VM of interest, until either all of the files of the VM of interest have been successfully verified).
Regarding Claim 4;
The combination of Franco and Tabone disclose the method of claim 3,
Franco discloses wherein the initial software specifications include requirement metrics and target values that the first and second images must meet, and wherein the determination of whether the first and second images meet the initial software specifications includes executing testing of the first and second images and comparing results of the testing to the requirement metrics and target values in order to determine whether the first and second images meet the requirement metrics and target values (Franco: Col 6, lines 40-44; generate a clone of the disk image. The clone of the disk image may be a read-only copy of the disk image, which ensures that no changes can be made to the clone of the disk image during the integrity verification process; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image). The management entity configured with scan policy rules which govern which files are measured; Col 5, line 60 – Col 6, line 19; the verifier entity compare the file path and/or the hash of a measurement of the retrieved measurement log for a particular file of the VM of interest to a file path and/or hash of a corresponding measurement of the verification profile [] this process may be repeated by the verifier entity for all of the files of the VM of interest, or alternatively may be repeated for a subset of the files of the VM of interest, until either all of the files of the VM of interest have been successfully verified [] if the verifier entity determines that the measurement log corresponds to (e.g. matches) or sufficiently corresponds to the reference measurement(s) then the verifier entity verify the VM).
Regarding Claim 11;
This Claim recites a method that perform the same steps as method of Claim 1, and has limitations that are similar to Claim 1, thus are rejected with the same rationale applied against claim 1.
Regarding Claim 12;
The combination of Franco and Tabone disclose the method of claim 11,
Franco discloses wherein the receiving of the indication that the first cyberattack is being executed includes receiving an alert from a customer managing the first operating system that the first cyberattack will be executed on the first image of the software system (Franco: Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log; Col 6, lines 19-28; if the verifier entity determines that the measurement log does not correspond to, or does not sufficiently correspond to, the reference measurement(s) then the verifier entity may generate events that may be presented, e.g. via a user interface or API to a user as verification results to notify the user of the discrepancy between the measurement log and the reference measurement(s). The user, or a user specific orchestration tool, may then take appropriate investigative and/or remedial action).
Regarding Claim 13;
The combination of Franco and Tabone disclose the method of claim 11,
Franco discloses wherein the receiving of the indication that the first cyberattack is being executed includes detecting that the first cyberattack is being executed on the first image of the software system (Franco: Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing; Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log).
Regarding Claim 14;
The combination of Franco and Tabone disclose the method of claim 13,
Franco discloses wherein the creation of the first image of the software system includes creating a first code level layout configured to output a first system level output based on a first system level input (Franco: Col 3, lines 45-46; a plurality of virtual disks or disk images corresponding to VMs hosted on the host machines; Col 6, line 66 – Col 7, line 2; a file system of the disk image is scanned by the management entity to generate measurements of the files of the disk image; Col 7, lines 15-18; generated, based on the measurements of the files of the cloned disk image or the original disk image, where appropriate. The measurement log contain, for example, file paths and hashes for each of the measured files), and wherein the creation of the second image of the software system includes creating a second code level layout different than the first code level layout configured to output a second system level output equal to the first system level output based on a second system level input equal to the first system level input (Franco: Col 6, lines 40-44; generate a clone of the disk image. The clone of the disk image may be a read-only copy of the disk image, which ensures that no changes can be made to the clone of the disk image during the integrity verification process).
Regarding Claim 15;
The combination of Franco and Tabone disclose the method of claim 14,
Franco discloses wherein the automatic verification and validation of the first image of the software system includes receiving initial software specifications and automatically determining whether the first image of the software system meets the initial software specifications (Franco: Col 6, line 66 – Col 7, line 2; a file system of the disk image is scanned by the management entity to generate measurements of the files of the disk image; Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log), wherein the creation of the second image is carried out after the automatic determination of whether the first image of the software system meets the initial software specifications, and wherein the automatic verification and validation of the second image of the software system includes determining whether the second image of the software system meets the initial software specifications (Franco: Col 7, lines 15-18; generated, based on the measurements of the files of the cloned disk image or the original disk image, where appropriate. The measurement log may contain, for example, file paths and hashes for each of the measured files; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image); Col 5, line 60 – Col 6, line5; the verifier entity compare the file path and/or the hash of a measurement of the retrieved measurement log for a particular file of the VM of interest to a file path and/or hash of a corresponding measurement of the verification profile [] this process may be repeated by the verifier entity for all of the files of the VM of interest, or alternatively may be repeated for a subset of the files of the VM of interest, until either all of the files of the VM of interest have been successfully verified).
Regarding Claim 16;
The combination of Franco and Tabone disclose the method of claim 15,
Franco discloses wherein the initial software specifications include requirement metrics and target values that the first and second images must meet (Franco: Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing the generated measurement log with a reference measurement of a verification profile previously assigned by the verifier entity to the software stack or the part of a software stack to verify the software stack or the part of a software stack; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image). The management entity configured with scan policy rules which govern which files are measured), and wherein the determination of whether the first and second images meet the initial software specifications includes executing testing of the first and second images and comparing results of the testing to the requirement metrics and target values in order to determine whether the first and second images meet the requirement metrics and target values (Franco: Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing the generated measurement log with a reference measurement of a verification profile previously assigned by the verifier entity to the software stack or the part of a software stack to verify the software stack or the part of a software stack; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image). The management entity configured with scan policy rules which govern which files are measured; Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log)
Regarding Claim 20;
This Claim recites a system that perform the same steps as method of Claim 1, and has limitations that are similar to Claim 1, thus are rejected with the same rationale applied against claim 1.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Franco et al. (US 11,334,670) in view of Tabone et al. (US 20120131365), and further in view of LIU et al. (“LIU,” CN 115706828 A, published on 02/17/2023).
Regarding Claim 5;
The combination of Franco and Tabone disclose the method of claim 4, further comprising:
Franco discloses storing, via the software deployment management subsystem, the first verification and validation data in a data store, the first verification and validation data being indicative of the first and second images meeting the requirement metrics and target values of the initial software specifications (Franco: Col 7, lines 15-18; generated, based on the measurements of the files of the cloned disk image or the original disk image, where appropriate. The measurement log may contain, for example, file paths and hashes for each of the measured files; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image); Col 5, line 60 – Col 6, line5; the verifier entity compare the file path and/or the hash of a measurement of the retrieved measurement log for a particular file of the VM of interest to a file path and/or hash of a corresponding measurement of the verification profile [] this process may be repeated by the verifier entity for all of the files of the VM of interest, or alternatively may be repeated for a subset of the files of the VM of interest, until either all of the files of the VM of interest have been successfully verified); compiling, via the software deployment management subsystem, the first verification and validation data (Franco: Col 7, lines 15-18; generated, based on the measurements of the files of the cloned disk image or the original disk image, where appropriate. The measurement log may contain, for example, file paths and hashes for each of the measured files; Col 6, lines 49-56; the cloned disk image is scanned by the management entity to generate measurements of the files of the cloned disk image (or a subset of the files of the cloned disk image); Col 5, line 60 – Col 6, line5; the verifier entity compare the file path and/or the hash of a measurement of the retrieved measurement log for a particular file of the VM of interest to a file path and/or hash of a corresponding measurement of the verification profile [] this process may be repeated by the verifier entity for all of the files of the VM of interest, or alternatively may be repeated for a subset of the files of the VM of interest, until either all of the files of the VM of interest have been successfully verified); and transmitting, via the software deployment management subsystem, the compiled first verification and validation data to an external certifier to have the first and second images certified (Franco: Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing; Col 6, lines 19-28; if the verifier entity determines that the measurement log does not correspond to, or does not sufficiently correspond to, the reference measurement(s) then the verifier entity may generate events that may be presented, e.g. via a user interface or API to a user as verification results to notify the user of the discrepancy between the measurement log and the reference measurement(s). The user, or a user specific orchestration tool, may then take appropriate investigative and/or remedial action).
The combination of Franco and Tabone disclose compiling, via the software deployment management subsystem, the first verification and validation data as recited above, but do not explicitly disclose data in a packaged format.
However, in an analogous art, LIU discloses data processing system/method that includes:
data in a packaged format (LIU: page 6, par 1; the second packaging format corresponding to the coding mode)
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of LIU with the method/system of Franco and Tabone to include data in a packaged format. One would have been motivated to perform quality improving processing to the data to be played, obtaining the target enhanced data; outputting the target enhanced data (LIU: abstract).
Claims 6-10 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Franco et al. (US 11,334,670) in view of Tabone et al. (US 20120131365), and further in view of MITANI et al. (“MITANI,” US 20240259375, filed on 05/20/2021).
Regarding Claim 6;
The combination of Franco and Tabone disclose the method of claim 1, further comprising:
Franco discloses in response to detecting that a first cyberattack being executed on the first image of the software system operating in the first operating system, automatically assigning, via the software deployment management subsystem, a value to the first cyberattack (Franco: Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log; Col 6, lines 19-28; if the verifier entity determines that the measurement log does not correspond to, or does not sufficiently correspond to, the reference measurement(s) then the verifier entity may generate events that may be presented, e.g. via a user interface or API to a user as verification results to notify the user of the discrepancy between the measurement log and the reference measurement(s). The user, or a user specific orchestration tool, may then take appropriate investigative and/or remedial action).
The combination of Franco and Tabone disclose automatically assigning, via the software deployment management subsystem, a value to the first cyberattack as recited above, but do not explicitly disclose a severity value.
However, in an analogous art, MITANI discloses policy generation system/method that includes:
a severity value (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of MITANI with the method/system of Franco and Tabone to include a severity value. One would have been motivated to score data that defines at least one of a score which is based on a viewpoint of risk of access or a score which is based on a viewpoint of a need for access (MITANI: abstract).
Regarding Claim 7;
The combination of Franco, Tabone, and MITANI disclose the method of claim 6,
MITANI discloses wherein the severity value is based on a number of a plurality of severity factors present in the first cyberattack, wherein the severity value is a binary number in a specified range of numbers, and wherein the severity value is proportional to the number of the plurality of severity factors present in the first cyberattack (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3).
The motivation is the same that of claim 6 above.
Regarding Claim 8;
The combination of Franco, Tabone, and MITANI disclose the method of claim 7, further comprising:
Franco discloses in response to detecting that a first cyberattack being executed on the first image of the software system operating in the first operating system, automatically assigning, via the software deployment management subsystem, a value of deploying the second image of the software system (Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing; Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log).
MITANI further discloses a risk value (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3).
The motivation is the same that of claim 6 above.
Regarding Claim 9;
The combination of Franco, Tabone, and MITANI disclose the method of claim 8,
Franco discloses wherein the risk value is based on a number of a plurality of risk factors of deploying the second image of the software system (Col 2, lines 27-34; generate a measurement log for a disk image associated with a software stack or the part of a software stack and make the measurement log available to a verifier entity for comparing; Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log).
MITANI further discloses wherein the risk value is a binary number in a specified range of numbers, and wherein the risk value is proportional to the number of the plurality of risk factors of deploying the second image of the software system (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3).
The motivation is the same that of claim 6 above.
Regarding Claim 10;
The combination of Franco, Tabone, and MITANI disclose the method of claim 9, further comprising:
MITANI further automatically comparing, via the software deployment management subsystem, the severity value with the risk value and, in response to the severity value being greater than the risk value, deploying the second image of the software system (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats).
The motivation is the same that of claim 6 above.
Regarding Claim 17;
The combination of Franco and Tabone disclose the method of claim 13, further comprising:
Franco discloses in response to detecting that a first cyberattack being executed on the first image of the software system operating in the first operating system, automatically assigning a value to the first cyberattack (Franco: Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log; Col 6, lines 19-28; if the verifier entity determines that the measurement log does not correspond to, or does not sufficiently correspond to, the reference measurement(s) then the verifier entity may generate events that may be presented, e.g. via a user interface or API to a user as verification results to notify the user of the discrepancy between the measurement log and the reference measurement(s). The user, or a user specific orchestration tool, may then take appropriate investigative and/or remedial action).
The combination of Franco and Tabone disclose automatically assigning a severity value to the first cyberattack as recited above, but do not explicitly disclose a severity value; wherein the severity value is based on a number of a plurality of severity factors present in the first cyberattack, wherein the severity value is a binary number in a specified range of numbers, and wherein the severity value is proportional to the number of the plurality of severity factors present in the first cyberattack.
However, in an analogous art, MITANI discloses policy generation system/method that includes:
a severity value (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3); wherein the severity value is based on a number of a plurality of severity factors present in the first cyberattack, wherein the severity value is a binary number in a specified range of numbers (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3), and wherein the severity value is proportional to the number of the plurality of severity factors present in the first cyberattack (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of MITANI with the method/system of Franco and Tabone to include a severity value; wherein the severity value is based on a number of a plurality of severity factors present in the first cyberattack, wherein the severity value is a binary number in a specified range of numbers, and wherein the severity value is proportional to the number of the plurality of severity factors present in the first cyberattack. One would have been motivated to score data that defines at least one of a score which is based on a viewpoint of risk of access or a score which is based on a viewpoint of a need for access (MITANI: abstract).
Regarding Claim 18;
The combination of Franco, Tabone, and MITANI disclose the method of claim 17, further comprising:
Franco discloses in response to detecting that a first cyberattack being executed on the first image of the software system operating in the first operating system, automatically assigning a value of deploying the second image of the software system (Franco: Col 6, lines 6-15; verifier entity determine that the measurement log corresponds to the reference measurements, or the verifier entity is unable to verify a file due to a mismatch between a measurement of the measurement log; Col 6, lines 19-28; if the verifier entity determines that the measurement log does not correspond to, or does not sufficiently correspond to, the reference measurement(s) then the verifier entity may generate events that may be presented, e.g. via a user interface or API to a user as verification results to notify the user of the discrepancy between the measurement log and the reference measurement(s).
MITANI further discloses a risk value (MITANI: par 0043; the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3); wherein the risk value is based on a number of a plurality of risk factors of deploying the second image of the software system (MITANI: par 0043; the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3), wherein the risk value is a binary number in a specified range of numbers, and wherein the risk value is proportional to the number of the plurality of risk factors of deploying the second image of the software system (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value, such as “-1” for threats and “0” for non-threats. Alternatively, depending on the threat level, the score indicating the threat level can be set as three or more values, such as 0, -1, -2, -3).
The motivation is the same that of claim 17 above.
Regarding Claim 19;
The combination of Franco, Tabone, and MITANI disclose the method of claim 18, further comprising:
MITANI discloses automatically comparing the severity value with the risk value and, in response to the severity value being greater than the risk value (MITANI: par 0043; when the output from the information source is discrete information such as the presence or absence of threats, the value of the score may be set as a fixed binary value [] “0” for non-threats [] the score indicating the threat level can be set as three or more values, such as -1, -2, -3).
The motivation is the same that of claim 17 above.
Tabone further discloses deploying the second image of the software system (Tabone: par 0086; to verify that the image on each of the devices is still accurate [] if the hashes do not match, indicate that the core components for the operating system on the device have been compromised; par 0093; build a new image for the device 604 and transfer the new image to device. Device 604 may then replace the potentially corrupted image with the new image, and operate with the new image, including by completing the compromised image).
The motivation is the same that of claim 11 above.
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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAO WANG whose telephone number is (313)446-6644. The examiner can normally be reached on Monday-Friday 7:30-4:30PM 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, Luu Pham can be reached at (571)270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.W./
Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights