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 4/12/26.
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 (page 19, page 26, lines 20-35 of page 41, page 47 – the medium is described for bootstrapping) that facilitates 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) on the device (lines 20-28 of col 41 – 102 acts as an AP; the DIEE (i.e., bootstrapping network) is on the device 102); 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 on the device (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; page 47; lines 20-25 of page 18) :
accessing a bootable medium that facilitates 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) on the device (lines 20-28 of col 41 – 102 acts as an AP; the DIEE (i.e., bootstrapping network) is on the device 102); 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 on the device (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, 5, 7, 9, 10, 12, 14, 16, 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 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 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 regarding claims 1, 9 and 15 have been fully considered but they are not persuasive.
Argument A: Applicant argues that the bootstrapping network is not a DIEE because the DIEE is an environment that exists on and runs on the device being provision and therefore, DIEE not a network between devices. According to the applicant, DIEE contains functionality to provision the device, install the ROE and perform the DI so as to a software execution environment. Further, applicant argues that “execution environment” operating on the device is different from the network (Argument A on page 8).
Examiner disagrees. The specification or claim does not require that DIEE must exclude the network. In Tamrakar, the device 102 creates, generates and operates the bootstrapping network as a restricted network to perform initialization. According to Tamrakar, lines 20-35 of page 41:
Referring to FIG. 7, illustrated is a flow diagram of a message flow sequence of a zero-touch bootstrapping process 700 via Wi-Fi technology, wherein the loT device 102 is configured to generate the bootstrapping network 110, in accordance with one or more embodiments of the present disclosure In the process 700, the loT device 102 is configured to create and operate a bootstrapping network 110. Notably, the loT device 102 acts an access point (AP) for the bootstrapping network 110 instead of the bootstrapping device 108. As shown at sub-step 7.1.1 of step 7.1, the loT device 102, in a non-operation mode, is configured to initiate as a Wi-Fi AP during power up. The loT device 102 uses the parameters from the unique bootstrapping parameters (Dl_S0) to configure the AP for the bootstrapping operation. At sub-step 7.1.2, the loT device 102 is configured to utilize the AP to create the bootstrapping network 110.
According to Tamrakar, page 26 and page 47, method provides software-based initialization execution environment:
At a step 206, the method 200 further comprises embedding the unique bootstrapping parameters in a memory 112 of the loT device 102. Typically, upon generating the unique bootstrapping parameters, the unique bootstrapping parameters are stored in the memory 112 of the loT device 102. This enables further bootstrapping operations via the unique bootstrapping parameters directly from the memory 112 of the loT device
The present disclosure also provides a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method 200 for managing bootstrapping of the intemet-of-things (loT) device 102.
Thus, the DIEE (or, the bootstrapping network 110) is created on the device via booting.
Argument B: Applicant further argues that the nonce is not the device key. According to applicant the device key is cryptographic key and ordinary skill would not equate a nonce with a key (Argument B on Page 9).
Examiner disagrees. Claim does not require device key must be a cryptographic key. Additionally, nonce is signed by the key (lines 30-34 of page 39) and therefore, the challenge comprises key. For further clarification Examiner cites few references (cited in PTO-892) that mention “nonce” and “key” interchangeably: Ash et al (US Patent Application Publication 2023/0011785 – [0027] – nonce is key), Choukir et al (US Patent Application Publication 2023/0262798 – [0041] “stored “key-value” include none/key/cookie), Uzun et al (US Patent Application Publication 2016/0224799 - refer nonce as a key [0157] [0071] – random nonce key). Therefore, the term “nonce” often referred as “key” in the art by the ordinary skill in the art.
Argument C: Applicant further argues that attestation Evidence is not an “ownership voucher” because ownership voucher used to allow an owner to take ownership of the device and provides “a digital proof of ownership” of the device to identify in the onboarding process. According to applicant, Tamrakar’s attestation evidence is a verification mechanism that confirms an ownership mechanism that is already established, which cant be equated with “ownership voucher” (Argument C on Page 10)
Examiner disagreed. Tamrakar’s attestation Evidence can be equated with ownership voucher because it identifies the owner of the device. In addition to the cited section mentioned before, the following passages confirm that the attestation evidence is the ownership voucher of the device:
According to page 33, lines 7-10 of Tamraker, the attestation evidence provides ownership status:
Thus, during every re-bootstrapping operation with the first owner, the user must provide an attestation evidence using a fresh challenge from the loT device 102 to prove the ownership status of the first owner.
According to page 41, lines 17-20 of Tamraker:
Thus, during every re-bootstrapping operation with the first owner (Ul), the user must provide an attestation evidence (AttEvidence) using a fresh challenge from the loT device 102 to prove the ownership status of the first owner.
According to page 31, lines 19-28 of Tamraker:
network generates the attestation evidence in such a way that it includes the latest relevant block which contains information about the real current owner and not about the attacker or previous owners. Alternatively stated, the server 101 or the trusted nodes in server 101 are configured to create the attestation evidence i.e., a signed message containing information of all the relevant blocks 104A-D or a signed statement assuring that the second owner is the rightful owner of the loT device 102 device and the block ID is associated with the latest block containing ownership transfer information to the second owner. Notably, the attestation evidence is signed using an attestation key of the blockchain server 101 or the trusted nodes.
Therefore, Tamrakar’s “attestation evidence” is the “ownership voucher.”
Argument D: Applicant further argues that Tamrakar does not teach any “bootable medium” or “booting” step. The claim recites “accessing a bootable medium” and “booting using the bootable medium to create DIEE on the device, which requires a specific sequence – accessing software to create the DIEE. According to applicant, Tamrakar does not describe any bootable medium from which the device boots to create an environment on the device because bootstrapping process in Tamrakar involves device 102 using parameters to join the wireless network (Argument D on Page 10).
Examiner disagrees. Tamrakar, upon powering on the device, creates, generates and operates the bootstrapping network where device 102 acts as an access point for the network 110 by using the parameters to configure the AP for the bootstrapping operation (lines 20-35 of page 41). Such a configuration is performed using bootable medium. As mentioned in lines 20-21 of page 18, lines 4-16 of page 19, lines 1-11 of page 47, Tamrakar teaches memory 112 stores bootstrapping parameters and computer readable storage media, which causes the computer to carry out the steps of method 200 for manageing the bootstrapping of the IoT device 102.
According to Tamrakar, page 19, page 26, lines 20-35 of page 41, page 47, the loT device 102 is configured to create and operate a bootstrapping network 110, where memory 112 of device 102 provides the parameters and instructions.
The memory 112 may be implemented using non-transitory computer-readable media, such as computer storage media. Computer storage media includes, medium that can be used to store information for access by a computing device (page 19)
As shown at sub-step 7.1.1 of step 7.1, the loT device 102, in a non-operation mode, is configured to initiate as a Wi-Fi AP during power up. The loT device 102 uses the parameters from the unique bootstrapping parameters (Dl_S0) to configure the AP for the bootstrapping operation. At sub-step 7.1.2, the loT device 102 is configured to utilize the AP to create the bootstrapping network 110 (lines 20-35 of page 41).
At a step 206, the method 200 further comprises embedding the unique bootstrapping parameters in a memory 112 of the loT device 102. Typically, upon generating the unique bootstrapping parameters, the unique bootstrapping parameters are stored in the memory 112 of the loT device 102. This enables further bootstrapping operations via the unique bootstrapping parameters directly from the memory 112 of the loT device (Page 26)
The present disclosure also provides a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method 200 for managing bootstrapping of the intemet-of-things (loT) device 102.(page 47)
Therefore, the memory 112 of IoT device stores the necessary software and parameters for the bootstrapping operation of IoT device to generate the bootstrapping network (or DIEE) on the device 102.
Applicant’s arguments regarding 4, 13 and 17 are persuasive. Examiner agreed that the cited art does not teach “Encryption-at-rest” to generate the DIEE image to prevent further modification. Therefore, the rejection is withdrawn.
Allowable Subject Matter
Claims 4, 8, 13, 17 and 20 would be allowable if rewritten to include all of the limitations of the base claim and any intervening claims.
Conclusion
THIS ACTION IS MADE FINAL. 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 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
Prosecution Insights