DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 35 USC 103(a) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued in the remark that Naqvi does not disclose measuring the memory area occupied by the baseline data itself to obtain a digest value. In contrast, the claimed method recognizes that the baseline data in memory could be tampered with. Therefore, Claim 1 explicitly recites calculating a hash of the "memory area occupied by the target baseline data." This verification of the integrity of the reference standard (the baseline) is neither taught nor suggested by Naqvi.
Examiner respectfully disagrees. Villegas US 2022/0237290 discloses 0020, the program code analyzer 104 can be configured to execute a hash function on the instruction data 112 at the first set of memory locations within the memory, and compare the hash to an expected hash, i.e. baseline data hash. The expected hash can correspond to a baseline hash for the first set of memory locations within the memory. The baseline hash can be associated with a version of the instruction data 112, i.e. baseline data, at the first set of memory locations during runtime of the computer program, that has not been affected by the malware. For example, the baseline hash can be a hash of a set of instructions of the instruction data 112 that does not include one or more instructions embedded by the malware, i.e. not tampered. The program code analyzer 104 can be configured to generate malware alert data 114 in response to determining that the hash of the instruction data 112 at the first set of memory locations within the memory is not equal to the expected hash. Because the malware can embed unwanted instructions into the instruction data 112, the hash of the instruction data 112 will be different from the hash of the instruction data 112 without the embedded, i.e. not tampered , unwanted instructions. The malware alert data 114 can provide an alert that the first set of memory locations have been compromised by the malware, i.e. performing an unseal operation is successful.
Naqvi does not measure "the memory area occupied by the target baseline data,"Naqvi cannot and does not determine whether "the target baseline data is not tampered with. It has no mechanism to determine if the baseline has been modified in memory. The claimed method provides a mechanism to distinguish and verify both the code segment and the baseline data.
Examiner respectfully disagrees. Villegas ‘s 0033 discloses FIG. 1. Thus, during the runtime of the computer program, the analyzer manager 226 can be programmed to cause each of the analyzers 228, 230, and 232 to be executed periodically or a-periodically and thus at different instances in time to evaluate the memory regions 208, 210, 212, 220, 222, and 224. Par 0034 /0041 the program code analyzer 228 can be programmed to evaluate the instruction data, i.e. baseline data, stored at the first memory region 208 within the non-volatile memory 204 to determine whether the instruction data stored therein has been compromised by the malware , par 0034 the program code analyzer 228 can be programmed to invoke a hash function 234 to execute a hash on the instruction data at the first memory region 208, and compare the hash of the instruction data at the first memory region 208 to an expected hash for the instruction data at the first memory region 208. Thus, the expected hash database 236 can include expected hash values for each memory region the memory regions 208, 210, 212, 220, 222, and 224 for different instances of time during the runtime of the computer program. Because data in at least some memory regions can change (e.g., in size and/or value) during the runtime of the computer program (e.g., the memory regions 208, 210, 212, 220, 222, and 224), the expected hash database 236 can include different expected hash values for times at which the at least some memory regions is evaluated by the malware detector module 214 for the malware. As described herein, an expect hash for a memory region corresponding to a set of memory locations in memory can correspond to a baseline has for the memory region that is free, i.e. not tampered of embedded , instructions and/or data by the malware.
In view of Abgrall et al US 2003/0037237, par discloses par 0014, fig.5, discloses a CryptoEngine, an application container data structure that contains a cryptographically sealed form of the data that the application wants to access, a CryptoGate function that intercepts all access between application-level programs and the CryptoEngine, includes a means to examine a portion of the bytes of an executable in-memory image of a program that is attempting to access cryptographic services or data, and computes a cryptographic digest of a portion of the bytes of in-memory image of the calling application to compute the AppCodeDigest of the application, and an integrity-check method performed by the CryptoEngine that examines the AppContainer and AppCodeDigest, and the master key to determine if the application is allowed to unseal the data in the given AppContainer, or when sealing the data modifies it to add the integrity check information. Where the cryptoEngine examine a portion of the bytes form the memory, Applicant computes a cryptographic digest of a portion of the bytes of in-memory image and the Applicant is allowed to unseal, 0013 controlling read and write access to data to an application by restricting the availability of a cryptographic key to an application that has a given AppCodeDigest. The method comprises a key, an AppContainer that holds a sealed or unsealed form of the data that the application wants to access, a CryptoGate module that performs a cryptographic digest of a portion of the bytes that make up the calling application to compute the AppCodeDigest, and a CryptoEngine module that includes integrity-checking that examines the AppContainer and AppCodeDigest, and the master key to determine if the application is allowed to unseal the data in the given AppContainer, or when sealing the data modifies it to add the integrity check information.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2,11-12, 15 -16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Villegas US 2022/0237290 in view of Abgrall et al US 2003/0037237.
As per claim 11. Villegas discloses A dynamic code segment measurement apparatus, comprising: at least one non-transitory computer readable medium, configured to store a program; and at least one processor (fig.2, processor 202), configured to execute the program stored in the non-transitory computer readable medium, and when the program stored in the non-transitory computer readable medium is executed (memory 216) , the at least one processor is configured to perform operations comprising:
measuring integrity of a code segment in a memory of at least one of a user- mode process or a kernel, to obtain first measurement data (0007 a method can include executing a hash function on instruction data for executing a computer program and comparing the hash of the instruction data to an expected hash for the instruction data to determine whether instruction data has been compromised by malware. The instruction data can be stored at a first set of memory locations within memory. During a second period of time, the method can include executing a hash function on static data for use by the computer program and comparing the hash of the static data to an expected hash for the static data to determine whether the static data has been compromised by the malware. The static data can be stored at a second set of memory locations with the memory. During a third period of time, the method can include executing a hash function on null data indicative of unused memory locations within the memory and comparing the hash of the null data to an expected hash for the null data to determine whether the null data has been compromised by the malware. The null data can be stored at a third set of memory locations with the memory. );
determining whether the first measurement data is consistent with target
baseline data (0018 the malware detector 100 can be executed by the processor of the weapon system to monitor and detect for malware on-board the weapon system. The malware detector 100 can include an analyzer manager 102. The analyzer manager 102 can be configured to select one of a program code analyzer 104, a static data analyzer 106, and an unused memory location analyzer 108 based on analyzer execution data 110. The analyzer execution data 110 can identify or determine when each of the program code analyzer 104, the static data analyzer 106, and the unused memory location analyzer 108 are executed during the runtime of the computer program. Thus, the analyzer execution data 110 can characterize a schedule for execution of the program code analyzer 104, the static data analyzer 106, and the unused memory region analyzer 108. In some examples, the analyzer manager 102 can be configured to select the program code analyzer 104 based on the schedule. For example, the schedule can identify instances in time at which the program code analyzer 104 is to cause one of the analyzers 104, 106, and 108 to be executed. In some examples, each of the analyzers 104, 106, and 108 can be executed periodically or a-periodically at different instances in time during the runtime of the computer program.);
when the first measurement data is consistent with the target baseline data,
performing hash calculation on a memory area occupied by the target baseline
data to obtain a first digest value( 0020 The program code analyzer 104 can be configured to generate malware alert data 114 in response to determining that the hash of the instruction data 112 at the first set of memory locations within the memory is not equal to the expected hash. Because the malware can embed unwanted instructions into the instruction data 112, the hash of the instruction data 112 will be different from the hash of the instruction data 112 without the embedded unwanted instructions. The malware alert data 114 can provide an alert that the first set of memory locations have been compromised by the malware.);
performing an operation using the first digest value to determine
whether the operation is successful (0022 the analyzer manager 102 , i.e. performing an operation, can be configured to select the static data analyzer 106 based on the analyzer execution data 110. For example, the schedule of the analyzer execution data 110 can indicate that the static data analyzer 106 is to be executed during the runtime of the computer program. In some examples, the analyzer execution data 110 can identify a second set of address locations for a second set of memory locations within the memory. The second set of memory locations within the memory can be configured to store at least some of static data 116 that may be used by the program code. The static data 116 stored at the second set of memory locations within the memory can include data that does not change during execution of the program code. Thus, the static data 116 can be representative of a collection of data in the memory that can be fixed in size. For example, the static data 116 can include one or more arrays. The analyzer manager 102 can be configured to provide the second set of address locations for the second set of memory locations within the memory from the analyzer execution data 110 to the static data analyzer 106 for malware evaluation of the static data 116 stored at the second set of memory locations within the memory); and
if the operation is successful, determining that the code segment
in the memory of the at least one of the user-mode process or the kernel is not
tampered with, and that the target baseline data is not tampered with ( 0020, the program code analyzer 104 can be configured to execute a hash function on the instruction data 112 at the first set of memory locations within the memory, and compare the hash to an expected hash, i.e. baseline data hash. The expected hash can correspond to a baseline hash for the first set of memory locations within the memory. The baseline hash can be associated with a version of the instruction data 112, i.e. baseline data, at the first set of memory locations during runtime of the computer program, that has not been affected by the malware. For example, the baseline hash can be a hash of a set of instructions of the instruction data 112 that does not include one or more instructions embedded by the malware, i.e. not tampered. The program code analyzer 104 can be configured to generate malware alert data 114 in response to determining that the hash of the instruction data 112 at the first set of memory locations within the memory is not equal to the expected hash. Because the malware can embed unwanted instructions into the instruction data 112, the hash of the instruction data 112 will be different from the hash of the instruction data 112 without the embedded, i.e. not tampered , unwanted instructions. The malware alert data 114 can provide an alert that the first set of memory locations have been compromised by the malware, i.e. performing an unseal operation is successful); or
if the unseal operation is not successful, determining that the target baseline
data is tampered with (0020, the program code analyzer 104 can be configured to execute a hash function on the instruction data 112 at the first set of memory locations within the memory, and compare the hash to an expected hash, i.e. baseline data hash. The expected hash can correspond to a baseline hash for the first set of memory locations within the memory. The baseline hash can be associated with a version of the instruction data 112, i.e. baseline data, at the first set of memory locations during runtime of the computer program, that has not been affected by the malware. For example, the baseline hash can be a hash of a set of instructions of the instruction data 112 that does not include one or more instructions embedded by the malware, i.e. not tampered. The program code analyzer 104 can be configured to generate malware alert data 114 in response to determining that the hash of the instruction data 112 at the first set of memory locations within the memory is not equal to the expected hash. Because the malware can embed unwanted instructions into the instruction data 112, the hash of the instruction data 112 will be different from the hash of the instruction data 112 without the embedded, i.e. not tampered , unwanted instructions. The malware alert data 114 can provide an alert that the first set of memory locations have been compromised by the malware, i.e. performing an unseal operation is successful).
Villegas does not explicitly disclose performing an unseal operation using the first digest value to determine whether the unseal operation is successful, if the operation is successful, determining that the code segment.
However, Abgrall et al US 2003/0037237, par discloses par 0014, fig.5, discloses performing an unseal operation using the first digest value to determine whether the unseal operation is successful, if the operation is successful, determining that the code segment ( a CryptoEngine, an application container data structure that contains a cryptographically sealed form of the data that the application wants to access, a CryptoGate function that intercepts all access between application-level programs and the CryptoEngine, includes a means to examine a portion of the bytes of an executable in-memory image of a program that is attempting to access cryptographic services or data, and computes a cryptographic digest of a portion of the bytes of in-memory image of the calling application to compute the AppCodeDigest of the application, and an integrity-check method performed by the CryptoEngine that examines the AppContainer and AppCodeDigest, and the master key to determine if the application is allowed to unseal the data in the given AppContainer, or when sealing the data modifies it to add the integrity check information. Where the cryptoEngine examine a portion of the bytes form the memory, Applicant computes a cryptographic digest of a portion of the bytes of in-memory image and the Applicant is allowed to unseal, 0013 controlling read and write access to data to an application by restricting the availability of a cryptographic key to an application that has a given AppCodeDigest. The method comprises a key, an AppContainer that holds a sealed or unsealed form of the data that the application wants to access, a CryptoGate module that performs a cryptographic digest of a portion of the bytes that make up the calling application to compute the AppCodeDigest, and a CryptoEngine module that includes integrity-checking that examines the AppContainer and AppCodeDigest, and the master key to determine if the application is allowed to unseal the data in the given AppContainer, or when sealing the data modifies it to add the integrity check information.
Villegas and Avgrall are both considered to be analogous to the claimed invention because they are in the same field of encryption of the memory portion.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villegas to incorporate the teachings of Abgrall and provide encryption of the portion of the memory data.
Doing so would provide the integrity check information, thereby increasing the data protection.
As per claim 12. Villegas and Abgrall discloses the method according to claim 1, Abgrall discloses wherein the method further comprises: when the first measurement data is inconsistent with the target baseline data, and the first digest value is capable of completing unseal, determining that the code segment in the at least one of the memory of the user-mode process or the kernel is tampered with, and that the target baseline data is not tampered with; or when the first measurement data is inconsistent with the target baseline data, and the first digest value is not capable of completing unseal, determining that the target baseline data is tampered with ( par discloses par 0014, fig.5, a CryptoEngine, an application container data structure that contains a cryptographically sealed form of the data that the application wants to access, a CryptoGate function that intercepts all access between application-level programs and the CryptoEngine, includes a means to examine a portion of the bytes of an executable in-memory image of a program that is attempting to access cryptographic services or data, and computes a cryptographic digest of a portion of the bytes of in-memory image of the calling application to compute the AppCodeDigest of the application, and an integrity-check method performed by the CryptoEngine that examines the AppContainer and AppCodeDigest, and the master key to determine if the application is allowed to unseal the data in the given AppContainer, or when sealing the data modifies it to add the integrity check information. Where the cryptoEngine examine a portion of the bytes form the memory, Applicant computes a cryptographic digest of a portion of the bytes of in-memory image and the Applicant is allowed to unseal, 0013 controlling read and write access to data to an application by restricting the availability of a cryptographic key to an application that has a given AppCodeDigest. The method comprises a key, an AppContainer that holds a sealed or unsealed form of the data that the application wants to access, a CryptoGate module that performs a cryptographic digest of a portion of the bytes that make up the calling application to compute the AppCodeDigest, and a CryptoEngine module that includes integrity-checking that examines the AppContainer and AppCodeDigest, and the master key to determine if the application is allowed to unseal the data in the given AppContainer, or when sealing the data modifies it to add the integrity check information).
As per claims 1-2,15 -16, and 19-20, those claims are rejected based on the same rational set forth the claims 11 and 12 respectively for set.
Claim(s) 3-7,13-14, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Villegas US 2022/0237290 in view of Abgrall et al US 2003/0037237in view of Bade et al US 2006/0075223.
As per claim 3. Villegas and Abgrall discloses the method according to claim 1, the combination fails to disclose wherein the method further comprises: when the first measurement data is inconsistent with the target baseline data, generating a first measurement log; performing hash calculation on the first measurement log to obtain a digest value of the first measurement log; and updating a reference extension value based on the reference extension value and the digest value of the first measurement log.
However, Bade discloses when the first measurement data is inconsistent with the target baseline data, generating a first measurement log; performing hash calculation on the first measurement log to obtain a digest value of the first measurement log ( 0031] In one embodiment, the TSS 302 generates a measurement digest and a measurement log upon measuring code. The measurement digest may be stored in a PCR on the TPM; however, in one embodiment the measurement digest is encrypted and stored in memory external to the TPM. Storage 120 from FIG. 1 is an example of external memory for storing encrypted measurement digests. In a TCG compliant system, data or code to be measured is appended to the end of a measurement digest and the combination is hashed. and updating a reference extension value based on the reference extension value and the digest value of the first measurement log( 0031 Algebraically, in a TCG compliant system, updates to a PCR are represented as follows: PCR[n]=SHA-1 (PCR[n]+measured data). Such a procedure may be referred to as "extending the digest." Extending the digest allows for the same value to reside in a measurement digest (PCR) during a given platform state, assuming no person or software has tampered with the measured code or data. The PCRs, shown as item 218 (FIG. 2), may contain the measurement digests. Verification of measurement events could require recreation of the measurement digest and a simple compare of measurement log values (using the PCR value as one of the comparators) and [0032] Referring to FIG. 4, FIG. 4 is a flow diagram of method 400 for managing PCR blocks in accordance with an embodiment of the present invention. In step 404, software receives a function which requires a specific PCR value. In one embodiment, the software that receives the function requiring the specific PVR value is a PCR manager such as TSS 302 from FIG. 3. For example, software could send a TPM_Extend function requesting PCR 0.times.3004000. In step 406, the software determines whether the PCR value is already loaded into the TPM. If the PCR value is not loaded into the TPM as determined by step 406, the TPM requests that the software send the PCR value to the TPM as shown in item 418. In one embodiment, the TSS 302 sends the PCR value to the TPM 306, as depicted in FIG. 3. In turn, the software finds the correct PCR value and sends it to the TPM. In step 420, the software receives a PCR block including the requested PCR value. In step 422, the TPM decrypts the PCR block values and stores the requested PCR values on the TPM. In step 408, the TPM_Extend function is performed ).
Villegas and Abgrall and Bade are both considered to be analogous to the claimed invention because they are in the same field of digest of the code.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villegas and Abgrall to incorporate the teachings of Bade and provide a code to be measured( par 0031).
Doing so would identify the software has tampered with the measured code or data, thus to improve the code tamper resistant capability, thereby increasing the protection of the software code.
As per claim 4. Villegas and Abgrall and Bade discloses the method according to claim 3, Bade discloses wherein the method further comprises: responding to an obtained first instruction, wherein the first instruction indicates to perform integrity check on the first measurement log; calculating a hash value for the first measurement log one by one, and performing extension calculation on the calculated hash value to obtain a second extension value; determining whether the second extension value is consistent with the reference extension value ( [0031] In one embodiment, the TSS 302 generates a measurement digest and a measurement log upon measuring code. The measurement digest may be stored in a PCR on the TPM; however, in one embodiment the measurement digest is encrypted and stored in memory external to the TPM. Storage 120 from FIG. 1 is an example of external memory for storing encrypted measurement digests. In a TCG compliant system, data or code to be measured is appended to the end of a measurement digest and the combination is hashed. Algebraically, in a TCG compliant system, updates to a PCR are represented as follows: PCR[n]=SHA-1 (PCR[n]+measured data). Such a procedure may be referred to as "extending the digest." Extending the digest allows for the same value to reside in a measurement digest (PCR) during a given platform state, assuming no person or software has tampered with the measured code or data. The PCRs, shown as item 218 (FIG. 2), may contain the measurement digests. Verification of measurement events could require recreation of the measurement digest and a simple compare of measurement log values (using the PCR value as one of the comparators).); and if the second extension value is inconsistent with the reference extension value, determining that the first measurement log is tampered with; or if the second extension value is consistent with the reference extension value, determining that the first measurement log is not tampered with (0007] The TPM stores hash results in Platform Configuration Registers (PCRs) and a corresponding measurement log in memory external to the TPM. The PCRs contain values representing the sequence of measurements and the measurement log contains a full history of all measurements. The log and PCR values can be used to validate one another. In an example of this process, the CRTM creates a hash of the software about to run and then reports a description of the measured software and the measurement itself to the TPM. The TPM stores the description and measurement in a log. Next the TPM appends the measurement to the value already stored in the appropriate PCR, hashes this new value, and replaces the existing value in the PCR with the new hashed value. A platform's specification may dictate to which PCR a measurement is stored.).
As per claim 5 Villegas and Abgrall disclose the method according to claim 1,
The combination does not explicitly disclose wherein, before the determining whether the first measurement data is consistent with target baseline data, the method further comprises: measuring the code segment in the at least one of the memory of the user-mode process or the kernel to obtain the target baseline data; performing hash calculation on the memory area occupied by the target baseline data to obtain a second digest value; and performing a seal operation based on the second digest value.
However, Bade discloses wherein, before the determining whether the first measurement data is consistent with target baseline data, the method further comprises: measuring the code segment in the at least one of the memory of the user-mode process or the kernel to obtain the target baseline data; performing hash calculation on the memory area occupied by the target baseline data to obtain a second digest value; and performing a seal operation based on the second digest value([0031] In one embodiment, the TSS 302 generates a measurement digest and a measurement log upon measuring code. The measurement digest may be stored in a PCR on the TPM; however, in one embodiment the measurement digest is encrypted and stored in memory external to the TPM. Storage 120 from FIG. 1 is an example of external memory for storing encrypted measurement digests. In a TCG compliant system, data or code to be measured is appended to the end of a measurement digest and the combination is hashed. Algebraically, in a TCG compliant system, updates to a PCR are represented as follows: PCR[n]=SHA-1 (PCR[n]+measured data). Such a procedure may be referred to as "extending the digest." Extending the digest allows for the same value to reside in a measurement digest (PCR) during a given platform state, assuming no person or software has tampered with the measured code or data. The PCRs, shown as item 218 (FIG. 2), may contain the measurement digests. Verification of measurement events could require recreation of the measurement digest and a simple compare of measurement log values (using the PCR value as one of the comparators). ).
Villegas and Abgrall and Bade are both considered to be analogous to the claimed invention because they are in the same field of digest of the code.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villegas and Abgrall to incorporate the teachings of Bade and provide a code to be measured( par 0031).
Doing so would identify the software has tampered with the measured code or data, thus to improve the code tamper resistant capability, thereby increasing the protection of the software code.
As per claim 6. Villegas and Abgrall and Bade discloses the method according to claim 5, Bade discloses further comprising: obtaining static baseline data of the user-mode process; and when the target baseline data is inconsistent with the static baseline data: determining that the code segment in the memory of the user-mode process is tampered with; and generating a second measurement log ( [0007] The TPM stores hash results in Platform Configuration Registers (PCRs) and a corresponding measurement log in memory external to the TPM. The PCRs contain values representing the sequence of measurements and the measurement log contains a full history of all measurements. The log and PCR values can be used to validate one another. In an example of this process, the CRTM creates a hash of the software about to run and then reports a description of the measured software and the measurement itself to the TPM. The TPM stores the description and measurement in a log. Next the TPM appends the measurement to the value already stored in the appropriate PCR, hashes this new value, and replaces the existing value in the PCR with the new hashed value. A platform's specification may dictate to which PCR a measurement is stored.).
As per claim 7. Villegas and Abgrall and Bade discloses the method according to claim 6, Bade discloses wherein the obtaining static baseline data of the user-mode process comprises: obtaining an executable file corresponding to the user-mode process; obtaining header information of the executable file, and obtaining, based on the header information, a target segment that comprises a code segment and that is in the executable file; obtaining, based on the header information and in the executable file, a relocation target address list; and performing hash calculation on the target segment that comprises the code segment and that is in the executable file, and removing, in a calculation process, data corresponding to the relocation address in the target address list to obtain the static baseline data ( [0031] In one embodiment, the TSS 302 generates a measurement digest and a measurement log upon measuring code. The measurement digest may be stored in a PCR on the TPM; however, in one embodiment the measurement digest is encrypted and stored in memory external to the TPM. Storage 120 from FIG. 1 is an example of external memory for storing encrypted measurement digests. In a TCG compliant system, data or code to be measured is appended to the end of a measurement digest and the combination is hashed. Algebraically, in a TCG compliant system, updates to a PCR are represented as follows: PCR[n]=SHA-1 (PCR[n]+measured data). Such a procedure may be referred to as "extending the digest." Extending the digest allows for the same value to reside in a measurement digest (PCR) during a given platform state, assuming no person or software has tampered with the measured code or data. The PCRs, shown as item 218 (FIG. 2), may contain the measurement digests. Verification of measurement events could require recreation of the measurement digest and a simple compare of measurement log values (using the PCR value as one of the comparators).).
As per claims 13-14, those claims are rejected based on the same rational set forth in the claims 3-4 respectively.
As per claims 17-18, those claims are rejected based on the same rational set forth in the claims 3-4 respectively.
Claim(s) 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Villegas in view of Abgrall in view of Noy et al US 2004/0163079.
As per claim 8, Villegas in view of Abgrall discloses the method according to claim 1, does not explicitly disclose wherein the measuring a code segment in a memory of a user-mode process comprises: obtaining a target segment that comprises the code segment and that is in the memory of the user-mode process; obtaining, in the target segment, a relocation target address list; and performing hash calculation on the target segment, and removing, in a calculation process, data corresponding to the address in the target address list, to obtain a measurement result.
However, Noy discloses wherein the measuring a code segment in a memory of a user-mode process comprises: obtaining a target segment that comprises the code segment and that is in the memory of the user-mode process; obtaining, in the target segment, a relocation target address list; and performing hash calculation on the target segment, and removing, in a calculation process, data corresponding to the address in the target address list, to obtain a measurement result ( 0069 measuring a code segment from several different perspectives. By combining these perspectives, a baseline of the code segment can be generated. Each of these perspectives is handled by a separate examiner. One examiner measures how long it takes a code segment to run (responsiveness). Another examiner measures how many code segments are running, how frequently they are being called, and generally how busy the target software is (throughput). In other words, examiners are software that generates real-time values that provide adequate information for pattern matching, and that transmits those values to a central server for additional processing. Par 0078 the calculation of block 726 is performed separately for each examiner type, and a separate examiner list is maintained for each examiner type. Note that examiner values according to embodiments of the present invention may be scalar (a single value) or vector (multiple values). In one embodiment of the present invention, average code segment values are computed by adding up the measurements from the active code segments, and dividing the sum by the number of active code segments. For example, because the throughput examiner measures the execution time of each code segment, the average code segment value will be the sum of the code segment execution times divided by the count of active code segments. Note that other algorithms may also be employed to yield different and possibly more representative of the behavior of the application. For example, in some cases the sensor measurements used to derive the examiner value may be longer than the sampling cycle (e.g., the sensor measurements used may reflect the last 10 seconds, even though the sampling loop and examiner calculation cycle is only 5 seconds)).
Villegas in view of Abgrall and Noy are both considered to be analogous to the claimed invention because they are in the same field of digest of the code.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villegas in view of Abgrall to incorporate the teachings of Noy and provide a code to be measured(par 0069).
Doing so would identify the software has tampered with the measured code or data, thus to improve the code tamper resistant capability, thereby increasing the protection of the software code.
As per claim 9. Villegas in view of Abgrall discloses the method according to claim 1, Naqvi does not explicitly discloses wherein the measuring a code segment in a kernel comprises: obtaining a first start and end address of code segment data in the kernel, and obtaining a second address of a changed code segment in the kernel; and performing hash calculation on code segment data within a range of the first start and end address, and removing, in a calculation process, data corresponding to the second address, to obtain a measurement result.
However, Noy discloses wherein the measuring a code segment in a kernel comprises: obtaining a first start and end address of code segment data in the kernel, and obtaining a second address of a changed code segment in the kernel; and performing hash calculation on code segment data within a range of the first start and end address, and removing, in a calculation process, data corresponding to the second address, to obtain a measurement result ( 0079 he computation of average code segment values, a deviant list (data far outside normal distributions) may be maintained separately (not averaged) so that the deviant values do not corrupt the normal data. For example, applications have a cleanup thread that may be executed once a day with a long execution time, and thus the cleanup thread will always appear at the top of a run time list. If these methods are added to the average code segment value, tit will be come unusable (in a graphical sense the examiner gauge will go to red for no reason). In order to deal with this issue, such deviant code segments could be detected, kept off the normal list, and added to the deviant list. The deviant list would become a part of the examiner value and would be parsed separately by the central server. Items that appear on the deviant list could be treated similar to other pattern items (i.e. if a code segment has been recorded several times as a deviant, the feedback will be less severe). Code segments in the deviant list may are only occasionally observed to ensure they are behaving as expected).
Villegas in view of Abgrall and Noy are both considered to be analogous to the claimed invention because they are in the same field of digest of the code.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villegas in view of Abgrall to incorporate the teachings of Noy and provide a code to be measured(par 0069).
Doing so would identify the software has tampered with the measured code or data, thus to improve the code tamper resistant capability, thereby increasing the protection of the software code.
Allowable Subject Matter
Claim 10 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims such as the include the claim 10 into all the independent claims respectfully.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABU S SHOLEMAN/ Primary Examiner, Art Unit 2496
Prosecution Insights