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 application has been examined. Claims 1-20 are pending.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-11, 14-18, 20 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Naggar et al. (“Naggar”) (US Pub No. 2014/0122329) in view of Shriver (“Shriver”) (US NO. 8,566,574).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Naggar and Shriver references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 1, Naggar discloses a method comprising: operating a field system using a first partition as an active partition and a second partition as a passive partition (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Naggar discloses a computer-implemented method of maintaining software components in an electronic device 3 (a field-deployable, portable computing device); Fig. 3. For each pair of partitions, an active partition 40A stores an existing version of one or more software components and an associated inactive partition 40B stores a backup or new version of the respective software components.”); Fig. 3 (first active partition 40A-2 storing current boot loader/kernel code 41, paired with second [inactive/passive] partition 40B-2). See ¶ 29-30);
PNG
media_image1.png
913
733
media_image1.png
Greyscale
responsive to receipt of a system update, changing a bootloader configuration from the first partition to the second partition (in Naggar, steps S4-23–S4-25: an update to boot loader and kernel code 41 is installed to the (second) inactive partition 40B-2; the electronic device then “makes the inactive partition 40B for that software component the active partition” while “the previously active partition 40A is made inactive” - i.e., the boot configuration (which partition boots) is changed from the first (formerly active) to the second partition responsive to the received update. ¶[0038] further discloses that “the electronic device 3 can store data identifying which ones of the partitions 40A, 40B are active, for example as respective pointers to the active partitions 40A and/or as an active partition table” which the changed pointer/table entry is the changed “bootloader configuration.” See ¶ 38, Fig. 4A/4B);
and rebooting the field system using the second partition as an active partition and the first partition as a passive partition for a system rollback responsive to detection of a system update issue (in Naggar, “after all the updates for the identified software components have been installed, the electronic device 3 is rebooted at step S4-29” which reboot into the newly-active second partition); (“if the electronic device 3 is not able to boot successfully using the kernel installed on the active partition 40A-2, the electronic device 3 can attempt to boot from the inactive kernel partition 40B-2. If this is successful, the electronic device 3 will swap the active/inactive kernel partitions 40-2”); (microcontroller 53 failover logic: on a threshold number of failed boots, “it will do a switch over to the inactive partition before rebooting”) - i.e., the first (passive) partition stands ready as the rollback target responsive to detection of a system update issue. See ¶ 40, 49-50). Naggar does not expressly teach performing root of trust measurements for the update where the measurements account at least for the change in the bootloader configuration; responsive to establishing trust via the measurements, accessing an encryption key; decrypting, using the encryption key, at least the second partition for use by the system. In the same field of endeavor, Shriver teaches performing root of trust measurements for the update where the measurements account at least for the change in the bootloader configuration (as shown in Fig. 3-4, which is reproduced below for ease of reference and convenience, Shriver discloses: col. 5:18-28: “the boot process performs a TPM secure hash of the boot configuration from Master Boot Record (MBR) 320…and stores the value into one or more PCRs…’boot configuration’ can include both the configuration of the information handling system as well as the code executed during the boot process.”; col. 5:66-6:6: (secure hash of files loaded during the boot process, and of the cleartext boot files, stored to PCRs); col. 5:26-43: (“if the boot configuration has been altered (e.g., boot files updated, etc.), then the PCR values will not match and the TPM will not release the secret value”). Fig. 3 (elements 300–380); Fig. 4 (elements 400–415);
PNG
media_image2.png
1033
786
media_image2.png
Greyscale
responsive to establishing trust via the measurements, accessing an encryption key (in Shriver, col. 5:45-57: (decision 415: if the TPM releases the secret value (i.e., trust is established because the measured configuration matches the sealed value) and “the secret value is used to decrypt an encrypted copy of the disk encryption key” at step 420); alternatively, on the update path, col. 5:58-6:14: (steps 430-445: an update encryption key is retrieved and used to decrypt the update copy of the disk encryption key, responsive to the boot-configuration change being accounted for by the (non-release determination).
decrypting, using the encryption key, at least the second partition for use by the system (in Shriver, col. 5:1-56: (“the decrypted disk encryption key is used to unlock encrypted partition 340…by providing the disk encryption key to crypto engine software application 460 (e.g., LUKS, etc.)”).
It would have been obvious to a person of ordinary skill in the art, seeking to upgrade Naggar's existing but comparatively coarse (counter-based) key-protection scheme with the more rigorous, standardized TPM-based measured-boot/sealed-key mechanism already in widespread use for exactly this purpose, would have been motivated to substitute or supplement Naggar's microcontroller-gated key release with Shriver's TPM-gated, boot-configuration-measurement-based key release, applying it to whichever partition is being activated by Naggar's update process.
In regard to claim 2, Naggar discloses responsive to a system update issue, changing the bootloader configuration from the second partition to the first partition (in Naggar: “the electronic device 3 will swap the active/inactive kernel partitions 40-2” responsive to a failed boot on the active partition; “it will do a switch over to the inactive partition before rebooting”, i.e., changing the boot configuration back from the second (now-failed) partition to the first partition. See ¶ 49-50).
In regard to claim 3, Shriver discloses wherein performing root of trust measurements comprises using a trusted platform module (in Shriver: Fig. 1 (element 195); col. 3:2-22: “the LPC bus also connects Southbridge 135 to Trusted Platform Module (TPM) 195”; Abstract: “a security module, such as a TPM…”). It would have been obvious to a person of ordinary skill in the art, seeking to upgrade Naggar's existing but comparatively coarse (counter-based) key-protection scheme with the more rigorous, standardized TPM-based measured-boot/sealed-key mechanism already in widespread use for exactly this purpose, would have been motivated to substitute or supplement Naggar's microcontroller-gated key release with Shriver's TPM-gated, boot-configuration-measurement-based key release, applying it to whichever partition is being activated by Naggar's update process.
In regard to claim 4, Naggar discloses wherein the field system comprises a data partition (in Naggar: “one or more additional partitions 40-n may be provided, such as, a user data partition for storing non-secured user data used by the software components…”). See ¶ 31).
In regard to claim 53, Naggar discloses wherein the field system comprises a boot partition that stores at least the bootloader (in Naggar: ¶[0027], ¶[0030], Fig. 3 (second active/inactive partition pair 40A-2/40B-2 stores “boot loader and kernel code 41”).
In regard to claim 6, Naggar discloses wherein the system update comprises an update for one or more of BIOS, a bootloader, an operating system kernel, an initial file, and an application (in Naggar: ¶[0038] (updated “boot loader and kernel code 41,” “operating system code 43,” and “browser application code 28” [application] are each installed to a respective inactive partition); ¶[0008] (“software components may include one or more of a boot loader, a root file system, a kernel…”).
In regard to claim 7, Naggar discloses extracting one or more of a kernel, an initial file and a root file system image from the system update, and optionally comprising applying the root file system image to the second partition and/or storing a backup of an existing kernel to a boot partition and saving the kernel of the system update to the boot partition (in Naggar: ¶[0038] (update package extracted from archive partition 40-4 and applied component-by-component: “updated boot loader and kernel code 41 can be stored in the second inactive partition 40B-2, and updated operating system code 43 and root file system files can be stored in the third inactive partition 40B-3”); ¶[0048] (“a back up copy of the current installed kernel is first stored on the inactive partition 40B-2 and the new version of the kernel is installed directly on the active partition 40A-2”) which teaches both extracting the kernel/root-file-system content from the update and the optional backup-and-save sequence recited in the claim.
In regard to claim 8, Naggar discloses wherein the bootloader configuration comprises a variable that specifies a boot partition or boot device (in Naggar: ¶[0038] (“the electronic device 3 can store data identifying which ones of the partitions 40A, 40B are active, for example as respective pointers to the active partitions 40A and/or as an active partition table” — a variable specifying the boot partition); ¶[0050] (microcontroller 53 “controls the boot mode, i.e. whether it boots the image on the portable USB flash memory device 3 or boots via USB (from host computer 5)” — a variable specifying the boot device).
In regard to claim 9, Shriver discloses comprising responsive to a lack of trust, operating the field system using the first partition as the active partition (in Shriver: col. 5:58-6:39: (if the update encryption key cannot be retrieved or fails to decrypt, “an error occurs and the boot process fails”, consistent with declining to proceed absent established trust). The combined teaching of Naggar and Shriver would render obvious falling back to operation on the first/known-good partition when trust in the update is not established.
In regard to claim 10, Shriver discloses wherein accessing the encryption key accesses the encryption key from a trusted platform module or accesses the encryption key from a bin file (in Shriver: col. 5:27-44: (secret/key released “from” the TPM 195). Naggar ¶[0032] (encryption key data 61 stored in “protected non-volatile memory 57” and loaded by microcontroller 53 during boot) additionally corroborates a stored-key-file arrangement analogous to the second (“bin file”) alternative). It would have been obvious to a person of ordinary skill in the art, seeking to upgrade Naggar's existing but comparatively coarse (counter-based) key-protection scheme with the more rigorous, standardized TPM-based measured-boot/sealed-key mechanism already in widespread use for exactly this purpose, would have been motivated to substitute or supplement Naggar's microcontroller-gated key release with Shriver's TPM-gated, boot-configuration-measurement-based key release, applying it to whichever partition is being activated by Naggar's update process.
In regard to claim 11, Shriver discloses enabling a trusted boot feature after rebooting the field system (in Shriver: col. 7:45-59: (steps 575–590: after a successful update-path decrypt, the kernel boot process “deletes the existing secret value stored in TPM 195,” “generates a new secret value,” and “seal[s] [it] with the PCR values that resulted from the new (updated) configuration being booted”) (approximate col./line; verify) that would re-establishing/re-enabling the measured/trusted-boot binding for the field system following the reboot into the updated configuration. It would have been obvious to a person of ordinary skill in the art, seeking to upgrade Naggar's existing but comparatively coarse (counter-based) key-protection scheme with the more rigorous, standardized TPM-based measured-boot/sealed-key mechanism already in widespread use for exactly this purpose, would have been motivated to substitute or supplement Naggar's microcontroller-gated key release with Shriver's TPM-gated, boot-configuration-measurement-based key release, applying it to whichever partition is being activated by Naggar's update process.
Independent claim 14 (system) and 20 (non-transitory computer-readable medium) recite the same operative limitations as method claim 1 in system and medium form respectively. Naggar's electronic device 3 inherently comprises a processor 27 and memory (¶[0026]: “the processor 27 is also coupled for access to volatile Random Access Memory (RAM) 37 and non-volatile memory 39”) executing stored program instructions (¶[0027]: “the non-volatile memory 39 stores code for the various software components…including boot loader and kernel code 41…”), and Shriver's information handling system 100 likewise recites processor(s) 110 and memory 120 (figure 1) executing the disclosed TPM-gated boot/update logic. The method/system/medium distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114.
Therefore, claims 14 and 20 are rejected on the same basis and mapping as claim 1 above.
Dependent claims 15-16 and 17-18 (system) recite the same operative limitations as method claims 2-3, 6-7 in system form respectively. The method/system distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114. Therefore, claims 15-18 are rejected on the same basis and mapping as claims 2-3 and 6-7 above.
Claims 12-13, 19 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Naggar et al. (“Naggar”) in view of Shriver (“Shriver”) and further in view of Crawford et al. (“Crawford”) (WO 01/23705).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Naggar and Shriver and Crawford references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claims 12, 19, Naggar and Shriver disclose the claimed subject matter as discussed above rejection except the teaching of wherein the field system comprises satellite communication circuitry and optionally comprising receiving the system update via the satellite communication circuitry. In the same field of endeavor, Crawford discloses the field system comprises satellite communication circuitry and optionally comprising receiving the system update via the satellite communication circuitry (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Crawford discloses Abstract; p. 1 (“a surface control and data acquisition system disposed in communication by satellite, for example, with the downhole control/monitor module, and a remote control system disposed in communication by satellite…with the surface control and data acquisition system”); p. 11 (Fig. 2 description: “a remote control system 230 disposed in communication with the surface control and data acquisition system 220 via a satellite transceiver component and an antenna”); claim 25 (communication device “selected from…a satellite system”); claim 36 (“the remote controller is adapted to send a command to the downhole sensor module via satellite communications”).
PNG
media_image3.png
532
385
media_image3.png
Greyscale
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine Crawford's field-based control/data-acquisition system, in combination with Naggar/Shriver's remotely-updatable field device, renders obvious equipping the combined field system with satellite communication circuitry and using it as the update-delivery channel.
In regard to claim 13, Crawford discloses wherein the field system is operatively coupled to one or more pieces of equipment at a wellsite, optionally wherein the system update comprises instructions for control of at least one of the one or more pieces of equipment at the wellsite (in Crawford, Claim 1 (“one or more downhole devices disposed in communication with the one or more control and data acquisition systems”); p. 3-4 (surface control and data acquisition system 220 issues commands “to actuate…a sliding sleeve, packer seal or other type flow or pressure control valve” in response to instructions received from the remote controller); claim 32 (“the remote controller sends commands to the control and data acquisition system to modify operation of a downhole pump or to change parameters”) (page numbers approximate; verify against certified publication). This teaches a field controller coupled to wellsite equipment and receiving remotely-delivered instructions for controlling that equipment. It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine Crawford's field-based control/data-acquisition system, in combination with Naggar/Shriver's remotely-updatable field device, renders obvious equipping the combined field system with satellite communication circuitry and using it as the update-delivery channel.
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Conclusion
All claims are rejected.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Shriver et al. (US 8,566,574)- family member: US 2012/0151199 A1: same disclosure as Shriver, pre-grant publication; may be cited in the alternative depending on the applicable prior-art date analysis.
Hiremath et al. US 12,340,229 B1, explicitly recites a first partition/second partition pair designated “Active OS”/“Standby OS,” with boot-order partition-designation changes and chainloading to the standby partition's bootloader (e.g., GRUB) on repeated boot failure
Leach et al. US 9,899,053 B1, teach protecting against unauthorized firmware updates using induced servo errors” relevant to the anti-rollback/trust-verification aspect of firmware updates in embedded/field devices.
Goldman, US 10,541,816, teaches controlling execution of software by combining secure boot and trusted boot features - relevant to claim 11 (“enabling a trusted boot feature after rebooting”) as an alternative/cumulative reference to Shriver's re-sealing step.
Thom et al., US 8,127,146, teach “Transparent trust validation of an unknown platform” - cited as a reference within Shriver's own prosecution history; relevant to RoT measurement of platform/boot configuration and may be useful if the RoT-measurement limitation is narrowed on amendment.
Guo et al., US Pub No. 2022/0027476/US 11,748,486, teach “Computing devices with secure boot operations” i.e. relevant to measured-boot architectures for embedded/field-deployed devices generally.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see hop://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights