DETAILED ACTION
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 Amendment filed on 5/1/2026, wherein claims 1, 3-7, 9-13, 15-20 are pending.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3-4, 6-7, 9-11, 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US PGPUB 2016/0366185).
As for claim 1, Lee teaches an apparatus comprising: a processor and a memory on which is stored machine readable instructions that when executed by the processor (paragraph 18, “…system for security health monitoring and attestation…random access memory, a central processing unit…”), cause the processor to:
send, to a first measurements manager (FIRST MM) [attestation server 46] outside of an attestation chain (paragraph 41 and 39. Because the monitor module 44 is the entity that generates the measurements. Thus, the attestation server that perform the measurement collection and does not measure the actual values themselves are understood as outside of the attestation chain. see, also, Fig. 2. Paragraph 39 teaches the attestation collects data from hardware, from VM, and from processor, thus, they are understood as the attestation chain of collection of attestation data from different entities for attestation), a first measurement for the processor [necessary information, the first measurement being for attestation of the processor (paragraph 59, “monitor module 44 …collect the necessary information...use…trust evidence registers 64 to count the occurrence of each cpu usage interval experienced by the …VM…sent as the security health measurements…” in view of paragraph 44, “…the data collected ….is stored in the trust evidence registers 64, the trust module 46…sign these measurements….forwards the data from the trust module 46 to the attestation client 66 which sends the data to the attestation server 16….” Here, the measurement is obtained by the monitor module 44, and the purpose of it, as taught in paragraph 44, is to subsequently be used for attestation where the data is send to the attestation client and then to the attestation server for attestation), wherein the FIRST MM is outside the data collection such that the FIRST MM does not participate in the generation of measurements during a secure boot sequence and is configured to receive, but not generate or modify, measurements from entities within the data collection (paragraph 44, “…the data collected ….is stored in the trust evidence registers 64, the trust module 46…sign these measurements….forwards the data from the trust module 46 to the attestation client 66 which sends the data to the attestation server 16….” In view of paragraph 41, “invokes monitor module 44 in step 70 to collect ….set of measurements…” teaches the FIRST MM is outside of the data collection because it is separate and distinct from the monitor module generating the measurements, and the forwarding of the measurements. Moreover, the FIRST MM signs the data, with no teaching of modifying the data, the signing of the data clearly requires it to receive the data to sign before forwarding the data and the signature to the attestation client which sends it to the attestation server. Therefore, it receives, but not generate nor modify the measurements themselves, because it neither generates data collected nor change the value of the data collected. the data collected values are not changed. Significantly, Examiner note current application specification explicitly teaches “…the MM210 to sign the accumulated measurements 222, for instance, using a cryptographic key…the signed accumulated measurements 222 may not be modified…” (Specification, paragraph 40), which clearly discloses the FIRST MM of the current art performs signing of the measured data similar to the prior art. Thus, the claim is understood as the signature can be used to check if the data is modified or not, and the signing of the data is not modifying the data itself same as the Prior art teaching. Finally, because the trust module doesn’t modify the data and the prior art measurement can be performed during a secure boot sequence (See, e.g., paragraph 55, “…during the cloud server bootup……before the VM 42 launch…”), the FIRST MM does not participate in the generation of measurement nor modify the measurement during a secure boot sequence. );
cause a hardware and/or a software entity [monitor module 44] participating in the attestation chain during the secure boot sequence to send a second measurement to the FIRST MM, the second measurement being for attestation of the hardware and/or the software (paragraph 41, “…invokes the monitor module 44 …to collect …set of measurements…the data collected from the monitor module 44 is stored…trust module 46…sign these measurements…which send the data to the attestation server 16” teaching monitor module generating second measurement,. Paragraph 55, “…check the integrity of both the host platform 41 and the VM 42 before launching the VM 42…measured during the cloud server bootup….the VM image can be measured before VM 42 launch…” teaches the measurement can be performed during a secure boot sequence for the server and/or the VM.);
cause a virtual machine (VM) participating in the attestation chain to send a third measurement to the FIRST MM, the third measurement being for attestation of the VM (paragraph 39, “the monitor module 44 can contain different types of monitors to provide comprehensive and rich security measures…collects the information inside the specific VM…and….dynamic information about the VM’s 41 activities and the guest VMs’ 42 and 43 activities…”…” is understood as measurement for attestation of the VM. in view of paragraph 41, “…the data collected ….is stored in the trust evidence registers 64, the trust module 46…sign these measurements….forwards the data from the trust module 46 to the attestation client 66 which sends the data to the attestation server 16….”);
cause the FIRST MM to execute instructions:
receive, from each of the processor, the hardware and/or software entity, and the VM, a respective measurement generated by the processor, the hardware and/or software entity and the VM (paragraph 39, “…hardware performance monitor unit 48 …collect runtime measurements of the VMs activities and the cloud server’s activities….VMI introspection tool ….collect the information inside the specified VM….VMM profile tool …collect dynamic information about the VMs activities and the guest VMs…”, Paragraph 41, “…the monitor module….to collect ….set of measurements…forwards the data …..sends the data to the attestation server 16…”” teaches in a first embodiment, the data received at the attestation can clearly include all the attested data from the different monitoring agents. Here, Examiner note, while prior art does not explicitly use the word “receive”, the prior art teaches the data can include multiple forms of data generated by different monitoring agents and send to the attestation server. Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing of the invention that the collection of the set of measurements is received because doing so, allows for improved security health monitoring of a virtual machine deployment environment utilizing multiple measurements directed to multiple aspects/components in the deployment environment. In addition, examiner note the claim limitation merely claims “receiving” the measurements from the components, the specification does not define either the connection required to receive the data, nor whether any intervening, or how many intervening components, network, or otherwise, are limited to before the MM receives the measurement data from the components.); and
accumulate the first measurement, the second measurement, and the third measurement received from the processor, the hardware and/or software entity and the VM (Paragraph 41, “…the trust module…sign these measurements…forward the data from the trust module to the attestation client 66…which sends the data to the attestation server 16” teaches in a first embodiment, the data received at the attestation can clearly include all the attested data from the different monitoring agents. Here, Examiner note, while prior art does not explicitly use the word “accumulate”, the prior art teaches the data can include multiple forms of data generated by different monitoring agents and stored at the attestation server. Thus, it would have been obvious to a person of ordinary skill in the art the that the collection of the set of measurements is a form of accumulating the set of measurements because doing so, allows for improved security health monitoring of a virtual machine deployment environment utilizing multiple measurements directed to multiple aspects/components in the deployment environment); and
cause the FIRST MM to output the accumulated measurements to a relying party (RP) [cloud customer 12] for attestation of the processor, the hardware and/or the software, the VM, or a combination thereof (paragraph 34, “cloud customer 12 can request the attestation…the attestation server…sends back the result…attestation server 16 accumulates and interprets the measurements…cloud customer 12 receives the one-time attestation report or for periodic attestation…” thus, the first MM can clearly output the accumulated measurements (or the interpretation thereof) to a relying party such as cloud customer that requested it.); and
a second MM in a data center [higher level attestation server], wherein the second MM is configured to collect the accumulated measurements from the first VM [attestation servers 16] along with accumulated measurements from a plurality of other MMs [other attestation servers 16] to generate a consolidated view of attestation data across the first MM and the plurality of other MMs (paragraph 37, “……if serves only a fraction (cluster) of the cloud servers, it can be connected to other attestation servers either hierarchically…to interpret the security health of the entire data center of the cloud computing system…” and paragraph 42, “…attestation servers 16 can be arranged hierarchically: each attestation server 16 can collect measurements from a plurality of cloud servers 18, and send these measurements, or interpretations of these measurements to a higher level attestation server (not shown in Fig. 2, but as will be clear to one versed in the art….thus, security properties can be interpreted for …across the whole data center of the cloud computing facility…” Thus, it is clear that the higher level attestation server of paragraph 42 collects the data from the plurality of lower level attestation servers 16.)
As for claim 3, Lee teaches where the attestation includes a plurality of entities including the processor, a basic input/output system (BIOS), a virtual machine manager (VMM) loader, a VMM, a plurality of VMs executing in the VMM including the VM, the hardware and/or the software, or a combination thereof (paragraph 39 and 59).
wherein the instructions cause the processor to cause the FIRST MM to separately receive, outside of the secure boot sequence, respective measurements from the plurality of entities (paragraph 39, the attestation server is clearly outside of the secure boot sequence itself, and receives it from a monitor module/trust module, and this measurement obtaining (attestation request), can be triggered at any time, and any stage, thus, clearly is not inside of the secure boot sequence process itself.).
As for claim 4, Lee also teaches cause the FIRST MM to accumulate the first measurement, the second measurement, and/or the third measurement after a secure boot sequence has completed (paragraph 34, “…the attestation server 16 accumulates and interprets the measurements…”).
As for claim 6, Lee also teaches in response to receipt of a request for attestation at the VM from the RP (paragraph 34), cause the FIRST MM to output the accumulated measurements, the RP to access the outputted accumulated measurements for attestation of the VM (paragraph 34), wherein the FIRST MM signed the accumulated measurements [attestation certificate] (paragraph 12, “verifies the signature and hash values…”, and paragraph 53, “…attestation server 16 is able to verify the measurements and auxiliary information…” and paragraph 36, “issue an attestation certificate…”), wherein the VM or a virtual machine manager (VMM) for the VM is not able to modify the signed accumulated measurements (Fig. 2 shows attestation server receiving the data can be outside of the Guest VM and the hypervisor hosting the VM. Thus, it would be clear that VMM and VM cannot touch the signed accumulated measurements.).
As for claim 7, Lee also teaches in response to receipt of a request for attestation at the VM from the RP, cause the FIRST MM to output the accumulated measurements to the RP via the VM or cause the FIRST MM to output accumulated measurements directly to the RP (paragraph 34).
As for claim 9, Lee also teaches based on the collected accumulated measurements at the second MM from the plurality of other MMs, determine a predefined set of measurements [pre-calculated hash values of its executable files] to be used as a reference for the attestation of the VM (paragraph 42 and 55); and
based on a determination that the accumulated measurements from the FIRST MM are within a range of the predefined set of measurements, cause the VM to execute a workload for a relying party (RP) (paragraph 55, “measured before VM 42 launch….the attestation server can have….the correct pre-calculated hash values of its executable files… use these correct values to check the hash measurements…and issue the integrity property attestation if the hash values match…”).
As for claim 10, Lee also teaches cause the FIRST MM to send the accumulated measurements to a global measurements collection center (GMCC), wherein the GMCC is to collect accumulated measurements from a plurality of data centers, the plurality of data centers including the data center (paragraph 37, “…attestation server serves only a fraction of the cloud servers….connected to other attestation servers…hierarchically…to interpret the security health of the entire data center of the cloud computing system…” teaches the top level of the attestation server hierarchy interpret the security health of the entire data center. Examiner note, the claimed datacenter can be understood as any collection of plurality of computing nodes (see, Specification, paragraph 44, “data centers…may include …racks…plurality of servers…” with no specific inherent basis for determining the met and bound of a data center. Thus, under the BRI is understood as a group of definable server nodes. Here, because the attestation servers can each serve a set of (fraction of) servers of the cloud servers, each is understood as a data center); and
based on the collected accumulated measurements from the GMCC, determine a predefined set of measurements to be used as a reference for the attestation of the VM, the predefined set of measurements to be generated based on a predefined group of servers having a predefined configuration among the plurality of data centers (paragraph 55).
As for claim 11, Lee teaches causing, by a processor, a first measurements manager (FIRST MM) to execute instructions to:
Receive, from entities within an attestation chain, respective measurements generated by the entities ((paragraph 39, “…hardware performance monitor unit 48 …collect runtime measurements of the VMs activities and the cloud server’s activities….VMI introspection tool ….collect the information inside the specified VM….VMM profile tool …collect dynamic information about the VMs activities and the guest VMs…”, Paragraph 41, “…the monitor module….to collect ….set of measurements…forwards the data …..sends the data to the attestation server 16…”” teaches in a first embodiment, the data received at the attestation can clearly include all the attested data from the different monitoring agents. Here, Examiner note, while prior art does not explicitly use the word “receive”, the prior art teaches the data can include multiple forms of data generated by different monitoring agents and send to the attestation server. Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing of the invention that the collection of the set of measurements is received because doing so, allows for improved security health monitoring of a virtual machine deployment environment utilizing multiple measurements directed to multiple aspects/components in the deployment environment. In addition, examiner note the claim limitation merely claims “receiving” the measurements from the components, the specification does not define either the connection required to receive the data, nor whether any intervening, or how many intervening components, network, or otherwise, are limited to before the MM receives the measurement data from the components.);
accumulate the measurements received from entities, wherein the entities comprise a processor, a hardware and/or software, and a virtual machine (VM) for attestation of the entities during a secure boot sequence, and the FIRST MM is outside of the attestation chain and the FIRST MM is outside of the attestation chain such that the FIRST MM does not participate in the generation of measurements and is configured to receive, but not generate, or modify, the measurements from the entities within the attestation chain (paragraph 41 and 39. Because the monitor module 44 is the entity that generates the measurements. Thus, the attestation server that perform the measurement collection and does not measure the actual values themselves are understood as outside of the attestation chain. see, also, Fig. 2. Paragraph 39 teaches the attestation collects data from hardware, from VM, and from processor, thus, they are understood as the attestation chain of collection of attestation data from different entities for attestation. paragraph 12, “verifies the signature and hash values…”, and paragraph 53, “…attestation server 16 is able to verify the measurements and auxiliary information…” teaches verifying information but no modification or generation of the data itself.);
causing, by the processor, a virtual machine (VM) to receive a request for attestation from a relying party (RP) accessing the virtual machine (VM) (paragraph 34); and
in response to the request for attestation from the RP, causing, by the processor, the FIRST MM to cryptographically sign and output the accumulated measurements for attestation of the VM (paragraph 12, “verifies the signature and hash values…”, and paragraph 53, “…attestation server 16 is able to verify the measurements and auxiliary information…” and paragraph 36, “issue an attestation certificate…”).
As for claim 14, Lee also teaches causing the FIRST MM to send the accumulated measurements to a second MM, the second MM to collect accumulated measurements from a plurality of MMs correlated to a plurality of servers in a data center (paragraph 37, “……if serves only a fraction (cluster) of the cloud servers, it can be connected to other attestation servers either hierarchically…to interpret the security health of the entire data center of the cloud computing system…” and paragraph 42).
As for claim 15, Lee also teaches based on the collected accumulated measurements at the second MM from the plurality of MMs, determining a predefined set of measurements that are reference measurements for the attestation (paragraph 55 in view of paragraph 42).
As for claim 16, Lee also teaches based on a determination that the accumulated measurements from the FIRST MM are within a range of the predefined set of measurements, causing the VM to execute a workload for the RP (paragraph 55, “measured before VM 42 launch….the attestation server can have….the correct pre-calculated hash values of its executable files… use these correct values to check the hash measurements…and issue the integrity property attestation if the hash values match…” ).
Claim(s) 5, 12-13, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lee, and further in view of Doshi et al. (US PGPUB 2021/0117249).
As for claim 5, Lee also teaches cause the FIRST MM to send a request for a second measurement from the hardware and/or the software (paragraph 41, “…collect another set of measurements…”, in view of paragraph 39, “….collect runtime measurements of the VM’s activities and the cloud server’s activities…”).
While Lee also teaches re-attestation at any stage of workload/deployment life cycles and teaches detecting an update (change) to the hardware and/or the software, (paragraph 41 in view of paragraphs 11, 35, and 65, where suspicious activity by software is understood as a change in the software. In addition, the prior art teaches detecting changes to other hardware or software operations, see, e.g., paragraphs 42-59). However, in the interest of compact prosecution, Examiner note Lee do not explicitly teach the re-attestation is directly in response to an update to the hardware and/or software.
However, Doshi teaches a known method of management of safe virtualized infrastructure workload execution with attestation including in response to an update to the hardware and/or the software, generate second measurement, the second measurement being based on the update to the hardware and/or the software (paragraph 226, “…if a device changes software or device property….changes the amount of memory, changed amount of storage, hot added device, or hot removed device….halt active sessions and re-attest or re-authenticate device with changed properties before allowing use of the device…” teaches re-attest subsequent to detecting a device change in software and/or hardware. In view of paragraphs 229, 230, 253, 330 teaches the measurement for security attestation) This known technique is applicable to the system of Lee as they both share characteristics and capabilities, namely, they are directed to attestation of components of a virtualized execution hosting environment.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Doshi would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Doshi to the teachings of Lee would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such component attestation features into similar systems. Further, applying in response to an update to the hardware and/or the software, request and generate the second measurement being based on the update to the hardware and/or the software with Lee generating plurality of attestation of the components and to detect an update/change to the hardware and/or the software accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow better management of massive execution environments at local levels for error monitoring (Doshi, paragraph 50).
As for claim 12, Lee also teaches causing the FIRST MM to request an updated measurement from the device (paragraph 34, “…periodical…”); and causing the FIRST MM to update the accumulated measurements based on the updated measurement from the device (paragraph 34).
Doshi teaches determining whether a device upon which the VM executes is updated, and based on a determination that the device is updated, request an updated measurement from the updated device (paragraph 226, “…if a device changes software or device property….changes the amount of memory, changed amount of storage, hot added device, or hot removed device….halt active sessions and re-attest or re-authenticate device with changed properties before allowing use of the device…” teaches re-attest subsequent to detecting a device change in software and/or hardware. In view of paragraphs 229, 230, 253, 330 teaches the measurement for security attestation). Refer to claim 5 for the motivation to combine.
As for claim 13, Lee also teaches causing the FIRST MM to update the accumulated measurements based on a device among the entities after the secure boot sequence has completed (paragraph 34 and 41, in view of paragraph 39 teaching different monitoring of components including devices, in view of paragraph 62 teaching it can be done after secure bootup and check during runtime).
In addition, Doshi also teaches update the measurements based on an update to a device (paragraph 226). The method of claim 11, further comprising: causing the FIRST MM to update the accumulated measurements based on an update to a device among the entities after the secure boot sequence has completed. It would have been recognized by those of ordinary skill in the art to incorporate Doshi’s teaching to Lee because they are directed toward attestation of components in virtualized execution hosting environments and because doing so allows better management of massive execution environments at local levels for error monitoring (Doshi, paragraph 50). Refer to claim 5 for the motivation to combine.
As for claim 17, Lee also teaches a computer-readable medium on which is stored machine-readable instructions that when executed by a processor (paragraph 34-37), cause the processor to:
cause a first measurements manager (FIRST MM) to execute instructions to: receive, from each of a processor, a hardware and/or software entity and a virtual machine (VM), respective measurements generated by the processor, the hardware ahd/or software entity and the VM (paragraph 39, “…hardware performance monitor unit 48 …collect runtime measurements of the VMs activities and the cloud server’s activities….VMI introspection tool ….collect the information inside the specified VM….VMM profile tool …collect dynamic information about the VMs activities and the guest VMs…”, Paragraph 41, “…the monitor module….to collect ….set of measurements…forwards the data …..sends the data to the attestation server 16…”” teaches in a first embodiment, the data received at the attestation can clearly include all the attested data from the different monitoring agents. Here, Examiner note, while prior art does not explicitly use the word “receive”, the prior art teaches the data can include multiple forms of data generated by different monitoring agents and send to the attestation server. Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing of the invention that the collection of the set of measurements is received because doing so, allows for improved security health monitoring of a virtual machine deployment environment utilizing multiple measurements directed to multiple aspects/components in the deployment environment. In addition, examiner note the claim limitation merely claims “receiving” the measurements from the components, the specification does not define either the connection required to receive the data, nor whether any intervening, or how many intervening components, network, or otherwise, are limited to before the MM receives the measurement data from the components.); and
accumulate the measurements received from the processor, the hardware and/or software entity, and the VM for attestation, wherein the FIRST MM is outside of an attestation chain such that the FIRST MM does not participate in the generation of measurements and is configured to receive, but not generate or modify, the measurements from entities within the attestation chain (paragraph 41 and 39. Because the monitor module 44 is the entity that generates the measurements. Thus, the attestation server that perform the measurement collection and does not measure the actual values themselves are understood as outside of the attestation chain. see, also, Fig. 2. Paragraph 39 teaches the attestation collects data from hardware, from VM, and from processor, thus, they are understood as the attestation chain of collection of attestation data from different entities for attestation. paragraph 12, “verifies the signature and hash values…”, and paragraph 53, “…attestation server 16 is able to verify the measurements and auxiliary information…” teaches verifying information but no modification or generation of the data itself.);
a device accessible to the VM (paragraph 39);
the VM and the device are within the attestation chain (paragraph 39 teaching both hardware monitor and VM monitoring can be part of the attestation measurement);
cause the FIRST MM to request an updated measurement from the updated device (paragraph 34 and 41 in view of paragraph 39, “…hardware performance monitor unit…”);
cause the FIRST MM to update the accumulated measurements based on the updated measurement from the device (paragraph 34 and 41 in view of paragraph 62 teaching attestation at any phase of a VM’s life cycle. Thus, the second measurement is understood as update the accumulated measurements.); and
in response to a request for attestation of the VM from a relying party (RP) accessing the VM, cause the FIRST MM to cryptographically sign and output the updated accumulated measurements for attestation of the VM (paragraph 34 and 41 in view of paragraph 62 teaching the request for attestation can come at any phase of a VM’s life cycle. The attestation server can also be read on as the relying party).
While Lee clearly teaches re-attestation at any stage of workload/deployment life cycles and teaches detecting an update (change) to the hardware and/or the software, (paragraph 41 in view of paragraphs 11, 35, and 65, where suspicious activity by software is understood as a change in the software. In addition, the prior art teaches detecting changes to other hardware or software operations, see, e.g., paragraphs 42-59). However, in the interest of compact prosecution, Examiner note Lee does not explicitly teach determine whether a device is updated and based on a determination that the device is updated, causes the re-attestation of the updated device.
However, Doshi teaches a known method of management of safe virtualized infrastructure workload execution with attestation including determine whether a device is updated and based on a determination that the device is updated, causes the re-attestation of the updated device (paragraph 226, “…if a device changes software or device property….changes the amount of memory, changed amount of storage, hot added device, or hot removed device….halt active sessions and re-attest or re-authenticate device with changed properties before allowing use of the device…” teaches re-attest subsequent to detecting a device change in software and/or hardware. In view of paragraphs 229, 230, 253, 330 teaches the measurement for security attestation) This known technique is applicable to the system of Lee as they both share characteristics and capabilities, namely, they are directed to attestation of components of a virtualized execution hosting environment.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Doshi would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Doshi to the teachings of Lee would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such component attestation features into similar systems. Further, applying in response to an update to a component running virtualized workloads, request and generate the second measurement on the updated device with Lee generating plurality of attestation of the components and to detect an update/change to the hardware and/or the software accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow better management of massive execution environments at local levels for error monitoring (Doshi, paragraph 50).
As for claim 18, Lee teaches the VM and the device are in an attestation chain for generating measurements for attestation during a secure boot sequence (paragraph 39-41 and 59).
As for claim 19, Lee also teaches cause the FIRST MM to update the accumulated measurements based on the updated measurement from the device after the secure boot sequence has completed (paragraph 34 and 41, in view of paragraph 39 teaching different monitoring of components including devices, in view of paragraph 62 teaching it can be done after secure bootup and check during runtime).
In addition, Doshi also teaches update the measurements based on the updated device (paragraph 226). The method of claim 11, further comprising: causing the FIRST MM to update the accumulated measurements based on an update to a device among the entities after the secure boot sequence has completed. It would have been recognized by those of ordinary skill in the art to incorporate Doshi’s teaching to Lee because they are directed toward attestation of components in virtualized execution hosting environments and because doing so allows better management of massive execution environments at local levels for error monitoring (Doshi, paragraph 50).
As for claim 20, Lee teaches based on a determination that the updated accumulated measurements from the FIRST MM are within a range of the predefined set of measurements, causing the VM to execute a workload for the RP (paragraph 55, “measured ….the attestation server can have….the correct pre-calculated hash values of its executable files… use these correct values to check the hash measurements…and issue the integrity property attestation if the hash values match…” in view of paragraph 41 and 62).
In addition, Doshi teaches determining an updated measurement of the updated device (paragraph 226). It would have been recognized by those of ordinary skill in the art to incorporate Doshi’s teaching to Lee because they are directed toward attestation of components in virtualized execution hosting environments and because doing so allows better management of massive execution environments at local levels for error monitoring (Doshi, paragraph 50).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 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.
In addition, Applicant's arguments filed on 12/2/2025 have been fully considered but they are not persuasive.
Applicant argues in the remark dated 12/2/2025:
Argument I: “….Lee implements…in which measurement data flows from the monitor module to….ultimately to the attestation server. In this arrangement the attestation server is a downstream component that receives measurement data only after it has already been collected upstream by the monitor module ….in contrast, amended claim 1 requires that the MM itself executes instructions to receive measurements from each of the processor, hardware/software entity, and VM…MM is the intake point for measurements from multiple entities rather than a downstream recipient of already-collected data…”, “…the attestation server therefore does not perform accumulation of measurements from multiple entities, by instead operates on data that has already been collected elsewhere…MM itself executes instructions to both receive measurements from each of the multiple entities and accumulate those measurements…does not disclose any component that receives measurements from each of the processor, hardware/software entity, and VM prior to any intermediate collection…” “…claimed invention each entity generates its own measurement and provides that measurement directly to the MM which receives and aggregates those measurements…” (App. Arg. 11-12).
Examiner respectfully disagrees for the following reasons:
With respect to Argument I, see paragraph 7 above. In addition, Examiner note applicant’s argument and assertion is not consistent the existing claim language. In particular, Applicant argues that the claim language requires providing the measurement directly to the MM, which is nowhere found in the claim language at all. Such assertion is not supported by the claim limitations themselves. Indeed, the claim merely states “…the first MM…receive, from each of the processor, the hardware and/or software entity, and the VM, a respective measurement generated…” nowhere does the claim require directly receiving the data from each of the individual components. Not only is “directly” not claimed, the specification does not have any definition or requirement for how they are received, with no description of how they are received from the components. Indeed, it does not appear to preclude any intervening components (network proxy devices, additional connections or otherwise). Moreover, the MM receiving is described in the context of outside of the sequential generation of measurements during an attestation chain (Paragraphs 31-32), and the MM received data can also be a hash of actual data generated (paragraph 32). Thus, it can clearly include modification of the raw data before being received by the MM, contradicting applicant’s suggested reason for why prior art does not qualify. Thus, the only unclaimed, and not required characteristic maybe that the measurement should not be sequentially generated between multiple components of a start-up process, which these measurements of the prior art clearly are not.
In addition, Examiner note dependent claim 3 teaches an attestation chain includes a subset of a number of different components (claim 3). In view of what can be part of the attestation chain, an alternative mapping of the prior art also teaches the claimed invention where the MM’s Monitor Kernel can be understood as the MM receiving from VM introspection tool, VMM profile tool, integrity measurement unit, performance monitor unit generating the measurement data. The Monitor kernel of the prior art (Fig. 2) is clearly not contemplated as part of the attestation chain components claimed by the applicant such as the processor, the VM, the VMM, BIOS, etc. Thus, such mapping would also read upon the claimed invention.
For the reasons above, applicant’s arguments are not persuasive.
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 KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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, Lewis Bullock can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights