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, see page 9, filed 08/25/2026, with respect to the previous rejection of claims 1-20 under 35 U.S.C. § 112(b) have been fully considered. The rejection of claims 1-20 under 35 U.S.C. § 112(b) has been withdrawn.
Applicant’s arguments, see pages 9-11, filed 08/25/2026, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. § 103 have been fully considered. The previous rejection has been withdrawn in response to Applicant’s amended claims. However, upon further consideration, a new ground(s) of rejection is made in view of newly discovered prior art in response to the amended claims reciting “wherein making the third determination comprises: obtaining verification data for the blueprint; and comparing a first hash in the verification data to a second hash of the blueprint for each object in the blueprint to make the third determination”.
Since applicant does not give any further explanation as to how the previously cited art differentiates from the claimed invention other than alleging that the previously presented Terpstra and Hui references do not contain the newly amended limitations and the alleged benefits of the amended limitations, the examiner defers to the rejection below as a response to this argument.
Applicant further argues on page 11 that new claims 21-22 are allowable for being dependent upon an allegedly allowable claim. Since applicant does not give any further explanation as to how the previously recited art differentiates from the claimed invention other than dependence upon an allegedly allowable claim, the examiner defers to the rejection below as a response to this argument.
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-6, 8-13, 15-22 are rejected under 35 U.S.C. 103 as being unpatentable over Terpstra et. al. (US Publication No. US 2023/0229779 A1) hereinafter Terpstra in view of Hui et. al. (US Publication No. US 2015/0365238 A1) hereinafter Hui, further in view of Landman; Yoav (US Publication No. US 2022/0164452 A1) hereinafter Landman.
Regarding Claims 1, 8, and 15:
Claim 8. Terpstra discloses a non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations for managing operation of endpoint devices of a deployment, the operations comprising (Terpstra [0228-0231] computer readable media contemplated): … obtaining, by an endpoint device of the endpoint devices, a blueprint token that indicates that the endpoint device is to implement a blueprint (Terpstra [0114] “The digitally signed package will contain metadata that describes its content (e.g., a singlet containing an ‘action’ component, or one or more tuples each including a ‘binary payload’ and an ‘action’ component)”), … and the blueprint token indicates the modification to the endpoint device (Terpstra [0062-0064]); in response to obtaining the blueprint token, performing by the endpoint device: making a first determination regarding whether a blueprint specified by the blueprint token is trusted (Terpstra [0114] “Upon receipt by the target computing device, the package will be digitally attested using its private key (e.g., a TPM-based private certificate)”); in a first instance of the first determination where the blueprint is trusted: making a second determination regarding whether the blueprint is authorized for use by the endpoint device (Terpstra [0113-0117]); in a first instance of the second determination where the blueprint is authorized for use by the endpoint device: making a third determination regarding whether integrity of the blueprint can be verified (Terpstra [0113-0117] hashing checks integrity), wherein making the third determination comprises: obtaining verification data for the blueprint (Terpstra [0113-0117] hashing checks integrity); … in a first instance of the third determination where the integrity of the blueprint can be verified: implementing a portion of objects specified by the blueprint that can be verified (Terpstra [0117] action component of the package is executed), the objects being implemented in an order specified by the blueprint (Terpstra [0117] action component of the package is executed; [0120] control plane may implement or utilize a tool chain to “implement hypervisor virtualization infrastructure 1110-1 and/or a container orchestration system 1110-2 (e.g., Kubernetes) to implement various tools (e.g., as virtual computing resources such as VMs or containers in a cloud infrastructure) Such tools illustratively include an edge device onboarding provisioning system 1112 having a rendezvous server 1114 and an onboarding/provisioning server 1116, a partner and application onboarding system 1118 including a partner database 1120 and application database 1122, a device registry 1124, and an application registry 1126”; [0121] action packages may be executed in serial execution as ordered), and implementation of the portion of the objects conforming the operation of the endpoint device to the blueprint (Terpstra [0117], [0120-0121]); and providing computer implemented services using at least the portion of objects (Terpstra [0117-0121] once completed the device goes “live” and provides the service after being configured).
Terpstra does not explicitly disclose verifying that a user has a privilege to initiate a modification; receiving, from the user, a selection of a blueprint; receiving, from the user, a limit of use of the blueprint specifying where and when the blueprint may be used; … wherein the blueprint token comprises a timestamp that is replay attack resistant… and comparing a first hash in the verification data to a second hash of the blueprint for each object in the blueprint to make the third determination.
Hui teaches verifying that a user has a privilege to initiate a modification (Hui [0040-0041] “Role 340 is used to limit a class of configurations/commands to a particular user role, providing a degree of flexibility that the operator or technician has with regard to configuring or interacting with the endpoint device. In some cases, the user role may establish a range of values (e.g., a subset of all possible values) for configurations that a technician may be allowed to implement. Alternatively, a technician may not be allowed to alter certain configurations at all. Example user roles may include: (i) an administrative role encompassing all configuration/management commands, (ii) a technician role, including all commands except configuration and reboot commands, and (iii) a viewer role with limited access, etc. Username 350 may be used by the endpoint device to log interactions with other devices”); receiving, from the user, a selection of a blueprint (Hui [0039-0042] “The work order may also contain configuration information or values 360 dictated by the NMS that includes LLN device configuration parameters to be updated, via the work order generated by the NMS, as well as acceptable values or valid ranges for each device configuration parameter. Configuration information may comprise a series of commands to be executed by the endpoint device”); receiving, from the user, a limit of use of the blueprint specifying where and when the blueprint may be used (Hui Figure 3 time window, [0034-0042] “Time window 330 determines the window of time during which the work order is valid. In some embodiments, the time window may be determined by a start date, e.g., a time stamp indicating the beginning of a valid time period for the work order, and an end date indicating a future point in time specifying the end of the valid time period” the window of time which the work order is valid limits the use); …wherein the blueprint token comprises a timestamp that is replay attack resistant (Hui Figure 3 time window, [0039-0042]).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the context-aware device provisioning disclosed by Terpstra with the privilege check, timestamp, and sequence number taught by Hui. The motivation for this combination would be to improve security of the system by preventing unauthorized user roles from making modifications and preventing replay attacks.
The combination of Terpstra and Hui does not explicitly teach and comparing a first hash in the verification data to a second hash of the blueprint for each object in the blueprint to make the third determination.
However, Landman teaches that such a technique of comparing a first hash in the verification data to a second hash of the blueprint for each object in the blueprint to make the third determination (Landman [0027-0029] “Based on verifying that the one or more files have completed the multiple development stages/development process and that the data components are validated, the node device may process the one or more files. For example, the node device may transfer the one or more files from a transaction directory to another memory location for execution and setting a flag to indicate that the one or more files have completed the multiple development stages/development process. If the node device is unable to verify that the one or more files have completed the multiple development stages/development process and validate the data components, the node device may send a notification to the server and/or delete (or otherwise discard) the one or more files from the transaction directory. Thus, the node device may advantageously verify whether a software release has completed the multiple development stages of the development process and validate the data components before processing the software, thereby preventing the node device from processing unverified software, which may open the node device to vulnerabilities”, [0073] ordered list of hashes “Completed development information 323 (e.g., run component data) includes a completion time and references to each of the other data components/run components, such as an ordered list of hashes of head data 318 and stage data 319”, [0096] further software validation enumerated). It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the context-aware device provisioning disclosed by Terpstra with the privilege check, timestamp, and sequence number taught by Hui, further with the known technique of validating each file/data component of a software release as explicitly taught by Landman. The motivation for this combination would be to improve the security of the context-aware device provisioning including an overall hashing of the package already taught by Terpstra, by ensuring each data component of the package is validated and that the data as received has not been altered by a malicious actor as explicitly taught by Landman. The results would have been predictable to one of ordinary skill in the art as Landman teaches that verifying each data component of a software release results in an improved system where the components are each verified to ensure that they are valid and have not been tampered with by a malicious actor (Landman [0028] “Transmission of the validation information enables the one or more node devices to verify that the software release (e.g., the one or more files) has successfully completed the multiple development stages of the development process and to validate that the data components are accurate and have not been tampered with after completion of the development process. For example, the server may deploy the software release by transmitting the one or more files (or the files that are not already stored at the one or more node devices) together with the validation information, and other metadata. Based on receipt of the validation information, the one or more node devices may validate the one or more files and the data components. For example, a node device may generate a first validation signature based on a first data component and the public key, and the node device may compare the first validation signature to a first digital signature stored in the secure data structure. If the first validation signature matches the first digital signature, the node device may validate that the first data component is accurate. Validating each of the data components in this manner verifies that the one or more files completed the respective development stages of the development process and validates that the received data components are accurate and have not been altered by a malicious actor”).
Claims 1 and 15 recite substantially the same content and are therefore rejected under the same rationales. Terpstra further discloses a method for managing operation of endpoint devices of a deployment (Terpstra [0225-0226]); and Terpstra further discloses an endpoint device, comprising: a processor; and a memory coupled to the processor to store instructions, which when executed by the processor, cause the processor to perform operations for managing operation of the endpoint device as a member of a deployment (Terpstra [0046-0048]).
Regarding Claims 2, 9, and 16:
Claim 9. The combination of Terpstra, Hui, and Landman further teaches the non-transitory machine-readable medium of claim 8 (Terpstra [0228-0231] computer readable media contemplated), wherein the operations further comprise: in the first instance of the third determination where the integrity of the blueprint can be verified: while the objects are being implemented, logging activity of the endpoint device to obtain an auditable implementation trail for the endpoint device (Terpstra [0118] “Upon completion of handling of the ‘action’ component, the target computing device will send to the control plane a signed package containing the confirmation of completion. This signed package may include any log information that was specified/requested within the ‘action’ package metadata”; [0127] all communication information and transactions are logged, “the various actions, in some embodiments, are made auditable”).
Claims 2 and 16 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claims 3, 10, and 17:
Claim 10. The combination of Terpstra, Hui, and Landman further teaches the non-transitory machine-readable medium of claim 8 (Terpstra [0228-0231] computer readable media contemplated), wherein making the first determination comprises: obtaining verification data for the blueprint (Terpstra [0113-0115] “Upon receipt by the target computing device, the package will be digitally attested using its private key (e.g., a TPM-based private certificate). The digitally signed package will contain metadata that describes its content (e.g., a singlet containing an “action” component, or one or more tuples each including a “binary payload” and an “action” component); 3. Upon successful validation, the target computing device will calculate an acceptable Hash-based Message Authentication Code (HMAC) checksum (e.g., an MD5 hash) of the entire package or bundle. The target computing device will send a signed package containing the HMAC checksum data to the control plane for confirmation.”); and attempting to verify trust in the blueprint using the verification data to make the first determination (Terpstra [0113-0117]).
Claims 3 and 17 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claims 4, 11, and 18:
Claim 11. The combination of Terpstra, Hui, and Landman further teaches the non-transitory machine-readable medium of claim 10 (Terpstra [0228-0231] computer readable media contemplated), wherein the verification data comprises a hash of the blueprint that is signed (Terpstra [0113-0115] hashing explicitly disclosed), and attempting to verify the trust in the blueprint comprises using a public key to check a signature applied to the hash (Terpstra [0113] signed using the public key).
Claims 4 and 18 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claims 5, 12, and 19:
Claim 12. The combination of Terpstra, Hui, and Landman further teaches the non-transitory machine-readable medium of claim 8 (Terpstra [0228-0231] computer readable media contemplated), wherein making the second determination comprises: obtaining at least one assignment for a plurality of blueprints to the endpoint device (Terpstra [0113-0117] and [0125-0127] application registry or repository is used to track which bundles need to be implemented by which target device serial numbers or other IDs and may maintain a queue of required actions to be implemented); and comparing the blueprint to the plurality of blueprints to ascertain whether the blueprint is one of the plurality of blueprints to make the second determination (Terpstra [0113-0117] and [0125-0127] registry and acknowledgements of received particular bundles required).
Claims 5 and 19 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claims 6, 13, and 20:
Claim 13. The combination of Terpstra, Hui, and Landman further teaches the non-transitory machine-readable medium of claim 12 (Terpstra [0228-0231] computer readable media contemplated), wherein each of the at least one assignment attests an assignment of at least one of the plurality of blueprints for use by the endpoint device (Terpstra [0113-0117], [0121] edge device attests blob received, and [0125-0127]), the at least one assignment being made by an administrator (Terpstra [0126] “This bundle preparation service provides various functionality, including but not limited to: preparing the bundle metadata (e.g., with a configurable data structure and key)… digitally signing the bundle with the edge device's ownership token; and adding the resulting bundle to the transmission queue.”; [0122] ownership token belongs to a manufacturer, vendor, or owner), and the at least one assignment being cryptographically verifiable by the endpoint device (Terpstra [0126] “digitally signing the bundle with the edge device's ownership token; and adding the resulting bundle to the transmission queue.”).
Claims 6 and 20 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claims 21 and 22:
Claim 22. The combination of Terpstra, Hui, and Landman further teaches the non-transitory machine-readable medium of claim 12 (Terpstra [0228-0231] computer readable media contemplated), wherein providing computer implemented services using at least the portion of objects omits objects in which the second hash is not verified by the first hash in the third determination (Landman [0029] “If the node device is unable to verify that the one or more files have completed the multiple development stages/development process and validate the data components, the node device may send a notification to the server and/or delete (or otherwise discard) the one or more files from the transaction directory” removing files that do not validate explicitly taught; Fig. 3 [0072-0073], [0087] “As another example, server 310 may add a second entry that includes second digital signature 336 and that is based at least in part on the first entry to secure data structure 332. To further illustrate, the second entry (that includes second digital signature 336) may include a cryptographic hash value, or other value, that is based on the first entry (that includes first digital signature 334). In some implementations, each entry in secure data structure 332 may include a digital signature for a respective data component and at least a portion of the data component. For example, the first entry of secure data structure 332 may include first digital signature 334 and at least a portion of head data 318. As another example, the second entry of secure data structure 332 may include second digital signature 336, a hash value based on the first entry, and at least a portion of first stage data 320. Additionally or alternatively, one or more entries in secure data structure 332 may be based on previous entries”, [0094] “After generating validation signatures 366, node device 360 (e.g., validator 363) compares validation signatures 366 to the digital signatures stored in secure data structure 332 to validate data components 317 and/or software 316. To illustrate, validator 363 may compare a validation signature associated with a particular data component to a digital signature stored in secure data structure 332 that is associated with the particular data component to perform the validation”, [0096] “Alternatively, if validator 363 fails validation, node device 360 may discard (e.g., delete) software 316 from transaction directory 370 and transmit a notification to server 310, the notification indicating that software 316 is rejected.”).
Claim 21 recites substantially the same content and is therefore rejected under the same rationales.
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
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 MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8:00AM-5:00PM.
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 on 5712727624. 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.
/M.A.L./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights