Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is in response to communications filed on 12/8/25.
Claims 1-20 are pending.
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 15 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tamrakar (WO 2024074207).
For claim 1, Tamrakar teaches the following limitations: A processor-implemented method (page 19 mention that memory 112 is a computer readable media to store instructions for access by a computing device; thus the method is a processor-implemented method) for provisioning a device (device 102 shown in Fig 1 and Fig 3; page 2 mention about bootstrapping and ownership change of the IoT device shown in Fig 3 102) comprising: accessing a bootable medium comprising a device initialization execution environment (DIEE) (Fig 2 lines 15-20 of page 25; Fig 6 lines 1-9 of page 39; Fig 7 lines 20-28 of col 41; Fig 8, lines 4-10 of col 44 mention about bootstrapping process where IoT device 102 configured to generate bootstrapping network; Fig 2, Fig 6- Fig 8 provide DIEE); booting, using the bootable medium, to create the DIEE on the device (Fig 6 lines 1-9 of page 39; Fig 7 lines 20-28 of col 41; Fig 8, lines 4-10 of col 44 mention about bootstrapping process where IoT device 102 configured to generate bootstrapping network 110): and responsive to the DIEE being booted on the device (lines 23-35 of page 39; page 18 lines 1-26 explain the bootstrapping of the devices including device 102): generating on the device one or more device keys for the device (nonce1 mentioned in line 32 of page 39; nonce1 is used as a key for communication; thus the attestation evidence generation uses nonce1; lines 14-21 of page 42; lines 30-34 of page 31); generating on the device (lines 23-28 of col 31 mention creating attestation evidence by server 101; line 28, page 13 through line 12 of page 14 mention that server 101 is a part of device 102 and a program; in such a case, when server 101 is part of device 102, generating evidence of 101 is equivalent to generating evidence on device 102), using at least one of the device keys (nonce1 mentioned in line 32 of page 39; nonce1 is used as a key for communication; thus the attestation evidence generation uses nonce1; lines 14-21 of page 42; lines 30-34 of page 31) and a provisioning entity's credential (lines 15-25 of page 40 mentions how the attestation evidence is generated – including information about blocks and blocks include bootstrapping information, ownership information, including information about latest owner of device 102; thus the provisioning entity’s credential is used) that is accessed by a service operating within the DIEE (server 101 accesses the credential as explained in lines 15-25 of page 40; lines 23-28 of page 31; line 30, page 23 through line 30, page 24; server 101 is a service operating within DIEE as lines 9-11 of page 14 and lines 4-30 of page 44 mentions that 102 creates the bootstrapping network and server 101 is the service operating within DIEE) , an ownership voucher that is used to allow an owner to take ownership of the device (lines 23-28 of page 31 mention that server 101 creates the attestation evidence that or a signed message assuring that the second owner is the rightful owner; thus, the attestation evidence is the ownership voucher).
For the limitations “storing the ownership voucher on a storage system that is accessible by an external user”, the attestation evidence is received by the IoT device (lines 30-32 of page 40), which is used by users (lines 10-15 of page 1). Tamrakar’s Fig 2, Fig 6 – Fig 8 embodiments do not explicitly mention that the storage system storing the voucher (i.e., attestation evidence), where the storage system is accessible by external user. However, in Tamrakar, the database 104 is configured to generate (i.e., include storing) the attestation evidence in an alternative embodiment (lines 10-23 of page 31). The database 104 is a public database (lines 8-13 of page 12).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to store the voucher (i.e., attestation evidence) in the database 104 of the system so that the evidence can be accessed whenever necessary by the external entity. Such an access will allow user to check whether the attestation evidence exists for the device. The management of the evidences will be flexible.
For claim 6, the environment is restricted (line 17, page 18 – 110 is device specific network). And nonce is generated in 110 (lines 8-15 of page 45).
For claim 15, Tamrakar teaches the following limitations: A device (device 102 shown in Fig 1 and Fig 3; page 2 mention about bootstrapping and ownership change of the IoT device shown in Fig 3 102) comprising: one or more processors; and a non-transitory computer-readable medium or media comprising one or more sets of instructions which, when executed by at least one of the one or more processors, causes steps to be performed comprising: (page 19 mention that memory 112 is a computer readable media to store instructions for access by a computing device) comprising: accessing a bootable medium comprising a device initialization execution environment (DIEE) (Fig 2 lines 15-20 of page 25; Fig 6 lines 1-9 of page 39; Fig 7 lines 20-28 of col 41; Fig 8, lines 4-10 of col 44 mention about bootstrapping process where IoT device 102 configured to generate bootstrapping network; Fig 2, Fig 6- Fig 8 provide DIEE); booting, using the bootable medium, to create the DIEE on the device (Fig 6 lines 1-9 of page 39; Fig 7 lines 20-28 of col 41; Fig 8, lines 4-10 of col 44 mention about bootstrapping process where IoT device 102 configured to generate bootstrapping network 110): and responsive to the DIEE being booted on the device (lines 23-35 of page 39; page 18 lines 1-26 explain the bootstrapping of the devices including device 102): generating on the device one or more device keys for the device (nonce1 mentioned in line 32 of page 39; nonce1 is used as a key for communication; thus the attestation evidence generation uses nonce1; lines 14-21 of page 42; lines 30-34 of page 31); generating on the device (lines 23-28 of col 31 mention creating attestation evidence by server 101; line 28, page 13 through line 12 of page 14 mention that server 101 is a part of device 102 and a program; in such a case, when server 101 is part of device 102, generating evidence of 101 is equivalent to generating evidence on device 102), using at least one of the device keys (nonce1 mentioned in line 32 of page 39; nonce1 is used as a key for communication; thus the attestation evidence generation uses nonce1; lines 14-21 of page 42; lines 30-34 of page 31) and a provisioning entity's credential (lines 15-25 of page 40 mentions how the attestation evidence is generated – including information about blocks and blocks include bootstrapping information, ownership information, including information about latest owner of device 102; thus the provisioning entity’s credential is used) that is accessed by a service operating within the DIEE (server 101 accesses the credential as explained in lines 15-25 of page 40; lines 23-28 of page 31; line 30, page 23 through line 30, page 24; server 101 is a service operating within DIEE as lines 9-11 of page 14 and lines 4-30 of page 44 mentions that 102 creates the bootstrapping network and server 101 is the service operating within DIEE) , an ownership voucher that is used to allow an owner to take ownership of the device (lines 23-28 of page 31 mention that server 101 creates the attestation evidence that or a signed message assuring that the second owner is the rightful owner; thus, the attestation evidence is the ownership voucher); storing at least a subset of the ownership voucher on the device (lines 30-32 of page 40; IoT has the attestation evidence).
For the limitations “storing the ownership voucher on a storage system that is accessible by an external user”, the attestation evidence is received by the IoT device (lines 30-32 of page 40), which is used by users (lines 10-15 of page 1). Tamrakar’s Fig 2, Fig 6 – Fig 8 embodiments do not explicitly mention that the storage system storing the voucher (i.e., attestation evidence), where the storage system is accessible by external user. However, in Tamrakar, the database 104 is configured to generate (i.e., include storing) the attestation evidence in an alternative embodiment (lines 10-23 of page 31). The database 104 is a public database (lines 8-13 of page 12).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to store the voucher (i.e., attestation evidence) in the database 104 of the system so that the evidence can be accessed whenever necessary by the external entity. Such an access will allow user to check whether the attestation evidence exists for the device. The management of the evidences will be flexible.
For claim 18, the environment is restricted (line 17, page 18 – 110 is device specific network). And nonce is generated in 110 (lines 8-15 of page 45).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tamrakar (WO 2024074207), further in view of Mudivarthy et al (US patent Application Publication 2023/0325848).
For claim 2, Tamrakar stores the attestation evidence on the device ((lines 30-32 of page 40), but does not mention storing after termination of DIEE. In Tamrakar, the database 104 is configured to generate (i.e., include storing) the attestation evidence (lines 10-23 of page 31). For further clarification, Examiner cites Mudivarthy that teaches a system where voucher is installed on the hardware and thus retained (Fig 9; Fig 11; [0083]-[0084] – device off and on – the voucher is obtained for new module; thus non new hardware modules’ voucher are stored persistently). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to store the voucher in a non-volatile storage, since this saves time for downloading the voucher every time.
Claim(s) 3, 4, 5, 7, 9, 10, 12, 13-14, 16-17, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tamrakar (WO 2024074207) in view of Watsen (US Patent Application Publication 20200213191)
For claims 3 and 16, Tarmakar line 30, page 25 through line 10, page 26 mention various bootstrapping parameters but does not mention about any image. Watsen teaches wherein the bootable medium comprises an image of the device initialization execution environment (DIEE) (boot image [0018] [0044]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide an image so that boot image can accurately provide the bootstrapping environment. Image is fixed and same image can be used by the system every time.
For claims 4 and 17, Watson teaches wherein the image of the DIEE was generated using an encryption-at-rest implementation to prevent modifications of the image ([0046] – VPN is encrypted communication; thus, image is also sent via encryption).
For claim 5, Tarmakar teaches multiple users as multiple owners (Fig 3-Fi4 and Fig 5), which includes supplying the credential. However, Tarmakar does not explicitly mention valid/invalid user credential. Watsen teaches providing a prompt to a user to supply a user credential as part of provisioning the device; responsive to receiving the user credential, verifying the user credential ([0075] operator credential is verified); responsive to the user credential being valid, proceeding with provisioning the device; and responsive to the user credential not being valid, not proceeding with provisioning the device (responsive to authentication, voucher is issued [0075]; [0048]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to verify the credential before provisioning the device, since this ensures further security.
For claims 7 and 19, Tarmakar teaches server 101 is a service (line 10, page 14), but does not mention that device onboarding manufacturing service. Tarmakar mentions that the ownership is changed to second owner from first owner and Fig 4 shows the change is from manufacturer to user. Thus, it is likely that the service is a device onboarding service. For further clarification, Examiner cites Watsen teaches the following limitations: wherein the step of generating an ownership voucher for the device comprises the step of: creating a device onboarding manufacturing service on the device that communicates with the restricted operating environment to generate the ownership voucher for the device (Fig 4 shows the device communicating with the operating environment via onboarding service received by step 412 – step 418 so that it communicates with server 20; [0044] [0047-[0049] [0075][0081] mention that ownership is verified via trusted by manufacturer; thus the onboarding manufacturing service is created within the environment shown in Fig 4, which further used to provide the voucher). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide the device onboarding service as the service operating within DIEE on server 101. Such a operation improves the onboarding service and Tarmakar’s system prefer to scale the onboarding service (line 26, page 1).
For claim 9, Tamrakar teaches the following limitations: A non-transitory computer-readable medium or media comprising one or more sequences of instructions which, when executed by at least one processor of a device, causes steps for provisioning or initializing the device comprising (page 19 mention that memory 112 is a computer readable media to store instructions for access by a computing device; (device 102 shown in Fig 1 and Fig 3; page 2 mention about bootstrapping and ownership change of the IoT device shown in Fig 3 102): creating a restricted operating environment on the device (Fig 2 lines 15-20 of page 25; Fig 6 lines 1-9 of page 39; Fig 7 lines 20-28 of col 41; Fig 8, lines 4-10 of col 44 mention about bootstrapping process where IoT device 102 configured to generate bootstrapping network; Fig 2, Fig 6- Fig 8; line 17, page 18 – 110 is device specific network or restricted network); generating one or more device keys for the device using the restricted operating environment (nonce1 mentioned in line 32 of page 39; nonce1 is used as a key for communication; thus the attestation evidence generation uses nonce1; lines 14-21 of page 42; lines 30-34 of page 31); creating a (server 101 accesses the credential as explained in lines 15-25 of page 40; lines 23-28 of page 31; line 30, page 23 through line 30, page 24; server 101 is a service operating with restricted environment as lines 9-11 of page 14 and lines 4-30 of page 44 mentions that 102 creates the bootstrapping network and server 101 is the service operating and communicating with restricted environment); generating on the device (lines 23-28 of col 31 mention creating attestation evidence by server 101; line 28, page 13 through line 12 of page 14 mention that server 101 is a part of device 102 and a program; in such a case, when server 101 is part of device 102, generating evidence of 101 is equivalent to generating evidence on device 102), using at least one of the device keys ((nonce1 mentioned in line 32 of page 39; nonce1 is used as a key for communication; thus the attestation evidence generation uses nonce1; lines 14-21 of page 42; lines 30-34 of page 31)) and a provisioning entity's credential (lines 15-25 of page 40 mentions how the attestation evidence is generated – including information about blocks and blocks include bootstrapping information, ownership information, including information about latest owner of device 102; thus the provisioning entity’s credential is used) that is accessed by theserver 101 accesses the credential as explained in lines 15-25 of page 40; lines 23-28 of page 31; line 30, page 23 through line 30, page 24; server 101 is a service operating with the restricted environment of network 110 as lines 9-11 of page 14 and lines 4-30 of page 44 mentions that 102 creates the bootstrapping network and server 101 is the service operating), an ownership voucher that is used to allow an owner to take ownership of the device (lines 23-28 of page 31 mention that server 101 creates the attestation evidence that or a signed message assuring that the second owner is the rightful owner; thus, the attestation evidence is the ownership voucher)
For the limitations “storing the ownership voucher on a storage system that is accessible by an external user”, the attestation evidence is received by the IoT device (lines 30-32 of page 40), which is used by users (lines 10-15 of page 1). Tamrakar’s Fig 2, Fig 6 – Fig 8 embodiments do not explicitly mention that the storage system storing the voucher (i.e., attestation evidence), where the storage system is accessible by external user. However, in Tamrakar, the database 104 is configured to generate (i.e., include storing) the attestation evidence in an alternative embodiment (lines 10-23 of page 31). The database 104 is a public database (lines 8-13 of page 12).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to store the voucher (i.e., attestation evidence) in the database 104 of the system so that the evidence can be accessed whenever necessary by the external entity. Such an access will allow user to check whether the attestation evidence exists for the device. The management of the evidences will be flexible.
Tamrakar does not mention about device onboarding manufacturing service on the device. Tarmakar mentions that the ownership is changed to second owner from first owner and Fig 4 shows the change is from manufacturer to user. Thus, it is likely that the service is a device onboarding service.
Watson teaches the following limitations:
creating a device onboarding manufacturing service on the device that communicates with the restricted operating environment (Fig 4 shows the device communicating with the operating environment via onboarding service received by step 412 – step 418 so that it communicates with server 20; [0044] [0047-[0049] [0075][0081] mention that ownership is verified via trusted by manufacturer; thus the onboarding manufacturing service is created within the environment shown in Fig 4);
generating, using at least one of the device keys and a provisioning entity’s credential that is accessed by the device onboarding manufacturing service (30 is the provisioning entity Fig 1;[0075] [0048] – whether 14 owns by 30 is verified; this requires both 14 and 30’s credential), an ownership voucher that is used to allow an owner to take ownership of the device ([0048]-[0049] – ownership voucher is generated for 14 authorizing access to customer network 30)
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide the device onboarding service as the service operating on server 101. Such an operation improves the onboarding service and Tarmakar’s system prefer to scale the onboarding service (line 26, page 1). As server 101 in Tamrakar is an flexible entity, this can accommodate the device onboarding service to perform the desired service for generation of the voucher.
For claim 10, Watsen teaches the following limitations: storing at least a subset of the ownership voucher on the device, in which the at least a subset of the ownership voucher persists on the device ([0048]- network device checks the voucher; thus, device has the voucher).
For claim 12, Watsen teaches wherein the one or more sequences of instructions for provisioning the device are contained in a bootable image on the non-transitory computer-readable medium or media ([0085] [0018] [0044] mentions image and CRM; the image is stored on a media).
For claim 13, Watsen teaches wherein the bootable image was generated using an encryption-at-rest implementation to prevent modifications of the bootable image ([0046] – VPN is encrypted communication; thus, image is also sent via encryption).
For claim 14, Watsen teaches the following limitations: comprising one or more sequences of instructions which, when executed by at least one processor, causes steps to be performed comprising: providing a prompt to a user to supply user credential as part of provisioning the device; responsive to receiving the user credential, verifying, using an authentication service, the user credential ([0075] operator credential is verified); responsive to the user credential being valid, proceeding with provisioning the device; and responsive to the user credential not being valid, not proceeding with provisioning the device (responsive to authentication, provisioning and voucher is issued [0075]; [0048]).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tamrakar (WO 2024074207) in view of Watsen (US Patent Application Publication 20200213191), further in view of Mudivarthy et al (US patent Application Publication 2023/0325848).
For claim 11, Watsen teaches following provisioning of the device ([0049]-[0050] touchless provisioning) including configuring the device to remove the onboarding manufacturing service ([0063] – loss of power and rebooting causes configuration not retained), the device retains a device credential comprising at least one of the device keys ([0062] password stored in non-volatile) but does not retain at least the device onboarding manufacturing service on the device ([0063] – loss of power and rebooting causes configuration not retained). Watsen teaches storing voucher ([0048]), but does not mention storing after termination of the DIEE and rebooting. Tamrakar teaches storing in database 104 in alternate embodiment ((lines 10-23 of page 31) and on device ((lines 30-32 of page 40). For further clarification, Mudivarthy teaches a system where voucher is installed on the hardware and thus retained (Fig 9; Fig 11; [0083]-[0084] – device off and on – the voucher is obtained for new module; thus non new hardware modules’ voucher are stored persistently). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to store the voucher in a non-volatile storage, since this saves time for downloading the voucher every time.
Response to Arguments
Applicant's arguments have been fully considered but they are moot in view of new ground of rejection.
Allowable Subject Matter
Claims 8 and 20 would be allowable if rewritten to include all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAHMIDA RAHMAN whose telephone number is (571)272-8159. The examiner can normally be reached Monday - Friday 10 AM - 7 PM. 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, Andrew Jung can be reached at 571-270-3779. 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.
/FAHMIDA RAHMAN/Primary Examiner, Art Unit 2175