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 18392907 filed on 12/21/2023. Claims 1, 11, and 20 are independent claims. Claims 1-20 have been examined and are pending in this application. This Office Action is made Non-Final.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/21/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “a software image generation tool [] automatically create;” “software verification and validation tool [] automatically verify;” “attack detection tool [] detect a first cyberattack;” recited in claim 20.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 6, lines 40-44; generate a clone of the disk image. The clone of the disk image may be a read-only [i.e., different] copy of the disk image, which ensures that no changes [i.e., output a second system level output equal to the first system level output] can be made to the clone of the disk image during the integrity verification process),
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
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 on (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