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 filed November 11, 2025 have been fully considered but they are not persuasive.
In page 1 of the remarks, Applicant states that the Office Action (“OA”) rejected claim 5 under 35 U.S.C. 112(b) (“112(b)”) for the term “triplicate” being a relative term rendering the claim indefinite, as it could either mean to store it in three separate locations, or store three bits in one table. Applicant states that the term is clear, as in paragraph [0015] of the Specification, to store bits in triplicate means to store each of one or more bits three times, as three bit values, and is depicted in Fig. 3, and covers whether three bits are stored into a table, or if the bit is stored in three separate locations.
Examiner states that the rejection under 112(b) is maintained, as although the Specification does describe the term “triplicate” in paragraph [0015], the claims do not further clarify the term “triplicate” as defined by the Specification of the Applicant, as to whether it means storing a bit in three locations, or three bit values in one location. Examiner maintains the 112(b) rejection for claim 5 for insufficient description of the term “triplicate”.
In pages 2-4 of the remarks, Applicant states that the OA rejected claim 1 under 35 U.S.C. 103 (“103 rejection”) over Poeluev (US PGPub No. 20130086385) in view of Yamaoka (US PGPub No. 20220091839). Applicant amended claim 1 to clarify the structure and usage of the SOC configuration table of the hardware security engine (HSE), including claim 1 stating that each entry of the SOC configuration table is configured to include a corresponding configuration field to indicate a corresponding configuration of the SOC and […] each corresponding record type is selected from a group consisting of a current and valid record type, a previous and valid record type, a blank record type, and an invalid record type, and claim 1 clarifies that updating any entry of the SOC configuration table comprises updating the corresponding record type […], storing the new configuration data in the corresponding configuration field in the second entry […], and updating a current and valid configuration record in the first entry to be a previous and valid configuration record by updating the corresponding status field of the first entry […]. Applicant states that references, in any combination or alone, fail to teach each and every element of claim 1. Applicant states that page 3 of the OA states that a feature feature register 112 of the access control core (ACC) of Poeluev teaches the SOC config table of claim 1, but merely keeps track of which resources each costumer can use, and that claim 1 does not simply direct to the concept of decrypting an encrypted file, but also does so to obtain new configuration data, with [0032] of Poeluev not teaching or suggesting this element, only decrypting/encrypting messages between the ACC 110 and an applicance 218 of an asset management system 200. The elements of “update to be the current and valid configuration record”, the OA utilized paragraph [0080] and Fig. 7 of Yamaoka (erroneously labeled as “Poeluev” in the previous OA) to refere to a priority field (F) and a validity field (V), but Applicant states that neither of the fields of Yamaoka suggest the specific record types of the SOC configuration table as claimed. Furthermore, Applicant states that the priority bit provides the order of firmware updates but does not indicate a current and valid configuration, and updating of priority field is irrelevant as to which is a current SOC configuration. Applicant states that the OA is correct in that Poeluev does not teach the remaining elements of claim 1, citing Yamaoka, in particular paragraphs [0087], [0089], and Fig. 4 and steps X05-X07 of Fig. 8, for teaching “wherein the SOC configuration table is configured to store, in a first entry […]”, “to obtain new configuration data”, “update a blank record in a second entry […]”, and “update a blank record in a second entry of the SOC configuration table”, and “in the first entry to be a previous and valid configuration record”, and argues that Yamaoka only teaches the partial excerpts of the claim language. Even if a firmware updating is considered “new configuration data”, Yamaoka does not suggest an SOC configuration table in which a blank record in a second entry of the SOC table is updating by storing the new configuration data in the corresponding configuration field of the second entry […]. Furthermore, Applicant states that the writable region of storage region 631 of Yamaoka is the storage region where the new firmware itself is stored, but is not a blank record in an SOC configuration table having a corresponding status field indicating a record type, and states that neither a valid field or priority field correspond to a status field indicating a record type of the storage region 631 as current and valid, previous and valid, blank, or invalid. Applicant states that Yamaoka fails to suggest updating a blank record of a second entry of the SOC table, and that there is no suggesting of updating the corresponding status field when updating a corresponding entry of an SOC configuration table, as claimed.
Examiner disagrees with the arguments of the Applicant regarding the independent claim 1, and the feature register 112 of ACC 110 of Poeluev contains configurations, as paragraph [0014] of Poeluev states that the feature register 112 includes segments 116 that store CIDs (customer identifiers) and settings associated with the resources of the system-on-a-chip (SOC) 106. Although it is correctly stated by the Applicant that the invention of Poeluev keeps track of which resources each costumer can use, the feature registers also store settings that are associated with resources of the SOC 106, with paragraph [0015] expanding on this limitation, where the stored information may be replaced is overwritten with data stored in the protected area 118 when the device is rebooted. The settings in particular are in the segments 116 inside the feature register 112, one for each customer, but the segments correspond to a configuration of the SOC. Next, Examiner states that the decryption of an encrypted file is stated in paragraph [0032] of Poeluev, and while the obtaining of new configuration data is not stated in Poeluev, the reference of Yamaoka teaches the obtaining new config, where Fig. 8 of step X05, stated in [0089] of Yamaoka, as firmware updates can be sent as messages to the invention of Yamaoka, obtaining the new firmware FW3, and store it in the FW storage 630, where the FW3 corresponds to the new configuration data for the SOC, and in step X06, firmware FW1 starts up in an update mode to acquire the new firmware FW3, and stores FW3 in storage region 630. The combination of the decryption of messages of Poeluev and the obtaining of the new firmware FW3 of Yamaoka teaches the limitation of “decrypt an encrypted file to obtain new configuration data”. Finally, the priority bit F in the priority field 657 and the valid bit V in flag field 656 (shown in Fig. 7) of Yamaoka teach the record types of the Applicant, as the combination of the priority fields (F) and validity fields (V) stated in paragraph [0080] of Fig. 7, validity field (V) determines if a record is valid or invalid, and priority field 657 (F) determines boot order, and based on the combinations of the priority and validity bits set for each of the firmware, correspond to the current and valid record type, a previous and valid record type, and an invalid record type. Meanwhile, Yamaoka [0089] Fig. 4, writable region of storage region 631 corresponds to a blank record of the Applicant, where the writable region is a blank region reserved for future firmware to be added to the SOC. The updating of firmware, such as in step X06 described in paragraph [0090] of Yamaoka can also be evaluated to update the corresponding status field of the firmware present in each of the storage regions 631. As a result, Examiner maintains the 103 rejection for claim 1 over Poeluev in view of Yamaoka.
In page 5 of the remarks, Applicant states that the OA rejected claim 3 under 35 U.S.C. 103, and is dependent from claim 1, but has been amended to clarify corresponding status fields for each entry of the SOC configuration table, and states that the V field does not suggest record types, and that the hash value 712 of Fig. 14 of Yamaoka teaches the “configuration bits”, and states that claim 1 only claims he configuration field being configured to indicate corresponding configuration of the SOC, and that the hash value does not suggest the configuration bits, and that claim 3 is allowable over the references.
Examiner states that while the hash value is used to verify that a particular firmware is stored in the storage region, as stated in paragraph [0091] of Yamaoka, step X07 of Fig. 8, it is used for updating the firmware that is present in the storage. Furthermore, the limitation of “the corresponding status field of each entry [… includes …] the corresponding configuration field of each entry is configured to include a plurality of configuration bits” is taught by Yamaoka [0080] Fig. 7, validity field (V) contains one bit, corresponding to a status field of one or more status bits of the corresponding configuration field of each entry including a plurality of configuration bits, and the hash value 712 of Fig. 14 is used for an update to the firmware is part of an update notification 701 of Fig. 5, which is also the update notification 658 included in the FW table along with the validity bit (V) and priority bit (F) in Fig. 7, and as the hash value 712 contains a plurality of bits, the hash value in the update notification corresponds to the each entry in the configuration table including a plurality of bits. As a result, Examiner maintains the 103 rejection for claim 3 over Poeluev in view of Yamaoka.
In page 5 of the remarks, Applicant states that the OA rejected claim 4 under 35 U.S.C. 103, and is dependent from claim 1, but has been amended to include the HSE being configured to update the corresponding status field of the selected entry to indicate the invalid record type upon a failure in updating a corresponding configuration field of a selected entry of the SOC configuration table.
Examiner states that the amended limitations of claim 4, which has been amended to update a firmware as invalid based on a failure on updating is stated in Yamaoka [0144] When an update FW (firmware) is detected, and fails to determine validity, corresponding to an error of updating, operation continues with an older FW. As a result, Examiner maintains the 103 rejection for claim 4 over Poeluev in view of Yamaoka.
In pages 5-6 of the remarks, Applicant states that the OA rejected claim 14 under 35 U.S.C. 103, and is dependent from claim 1, and that claim 14 includes that the HSE copies the new config data from an SOC configuration table into a general purpose register (GPR) of the user space in response to the decryption and updating in response to the update service request. Applicant states that the claim 14 requires both an SOC config table and a GPR, where the new config data is copied to the GPR.
Examiner states that the limitations of claim 14, which has not been amended to recite the copying from an SOC configuration table, will have its rejections maintained. Even if the claim were to be amended to recite the arguments mentioned above, the feature register 112 contains the segments that have FEAT bits from an NVM when firmware is loaded, the FEAT bits are copied into the feature register 112. Examiner maintains the 103 rejection for claim 14 over Poeluev in view of Yamaoka.
In page 6 of the remarks, Applicant states that the OA rejected claims 2 and 5-13 were rejection under 35 U.S.C. 103, which are claims dependent on independent claim 1 above.
Examiner maintains the 103 rejection of claims 2 and 5-13 based on the rejections of independent claim 1 above.
In page 6 of the remarks, Applicant states that the OA rejected claim 15 under 35 U.S.C. 103, which contains arguments that have been recited in independent claims 1 and 14 that were recited above.
Examiner maintains the 103 rejection of claims 15 for the reasons cited above for claims 1 and 14 over Poeluev in view of Yamaoka.
Finally, in page 6 of the remarks, Applicant states that the OA rejected claims 16-20 were rejection under 35 U.S.C. 103, which are claims dependent on independent claim 15 above.
Examiner maintains the 103 rejection of claims 16-20 based on the rejections of independent claim 15 above.
Claim Objections
Claim 1 objected to because of the following informalities:
A comma is missing between claim 1, line 11 on “indicated by the corresponding status field” and “wherein the SOC configuration” on claim 1, line 12.
Appropriate correction is required.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 5 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “triplicate” in claim 5, line 2 is a relative term which renders the claim indefinite. The term “triplicate” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. It is unknown what the term is supposed to mean based on the claim language alone, whether it means three bits stored into a table, or if it means a bit stored in three separate locations.
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.
Claims 1-4, and 6-20 are rejected under 35 U.S.C. 103 as being unpatentable over Poeluev (US 20130086385 A1), in view of Yamaoka et al. (US 20220091839 A1), hereinafter Yamaoka.
Regarding claim 1, Poeluev discloses ‘A system on a chip (SOC) comprising: a user space having one or more cores’ ([0026] Fig. 1, device corresponds to a system on a chip (SOC) claimed. System on a chip with various hardware modules 108 also corresponds to a user space. Claim 13 describes a system on a chip of Poeluev as having one or more processors in their respective SOC.),
‘and a hardware security engine (HSE) which includes storage circuitry configured to store an SOC configuration table, and the HSE is configured to, in response to an update service request from a core of the user space’ (Paragraph [0014] of Poeluev, Fig. 1, Access Control Core (ACC) corresponds to a hardware security engine (HSE) of the Applicant. Feature register 112 corresponds to a configuration table storing configurations, with segments 116 corresponding to the configurations. Paragraph [0015] of Poeluev states that a customer/client 102 can send a request to the ACC 110 to update, and in paragraph [0017] of Poeluev also describes that one or more hardware modules 108 can be configured by a costumer 102, corresponding to the invention being responsive to an update service request from a core of the user space of the Applicant.),
‘decrypt an encrypted file’ (Paragraph [0032] of Poeluev has decrypting of messages takes place in the ACC 110.),
Poeluev does not appear to fully disclose, but Yamaoka also teaches the limitations of ‘wherein each entry of the SOC configuration table is configured to include a corresponding configuration field to indicate a corresponding configuration of the SOC and a corresponding status field to indicate a corresponding record type, wherein each corresponding record type is selected from a group consisting of a current and valid record type, a previous and valid record type, a blank record type, and an invalid record type’ (Yamaoka [0080] Fig. 7, validity field (V) determines if a record is valid or invalid, and priority field 657 (F) determines boot order, corresponding to a record being considered 'previous' or 'current' of the Applicant, along with valid or invalid record types, based on the combinations of the validity field (V) and the priority bit (F) set for each of the firmware present. Fig. 7 contains bits that are stored, corresponding to status bits. Yamaoka [0152] Fig. 14, update notification contains a hash value 712, corresponding to a configuration field having a plurality of configuration bits of the Applicant. Yamaoka [0089] Fig. 4, writable region of storage region 631 corresponds to a blank record of the Applicant.),
‘wherein updating any entry of the SOC configuration table comprises updating the corresponding record type indicated by the corresponding status field’ (Paragraph [0080] of Yamaoka, Fig. 7, priority field (F) updates based on updates to firmware being installed. Updating firmware is also a function of Yamaoka, and priority field (F) changes the boot order of firmware based on updates.)
‘wherein the SOC configuration table is configured to store, in a first entry, a current and valid configuration record corresponding to a current configuration of the SOC by storing the current configuration in the corresponding configuration field of the first entry and updating the corresponding status field of the first entry to indicate the current and valid record type’ (Yamaoka [0087] recognizes that by starting with firmware FW1 and having it operate as normal, corresponding to a current and valid configuration of the Applicant. As firmware FW1 could be the only firmware that can be stored at a certain point in time, can also correspond to a first entry of an SOC configuration table of the Applicant as well. [0271] Update notifications can contain information on how to apply the update, which can also contains features that may be enabled, as taught by the Applicant. [0299] Example of different method of performing a similar function is stated with versions E and F of the firmware.);
‘to obtain new configuration data’ (Fig. 8, step X05, firmware updates of Yamaoka described in paragraph [0089] correspond to new configuration data of the Applicant.),
‘update a blank record in a second entry of the SOC configuration table to be the current and valid configuration record by storing the new configuration data in the corresponding configuration field of the second entry and updating the corresponding status field of the second entry to indicate the current and valid record type’ (Paragraph [0089] of Yamaoka in Fig. 4, writable region of storage region 631 to store a new firmware corresponds to updating a blank record in a second entry to store new configuration data of the Applicant. Paragraph [0080] of Yamaoka, Fig. 7, priority field (F) updates based on updates to firmware being installed. Updating firmware is also a function of Yamaoka. Paragraph [0089] of Yamaoka in Fig. 4, writable region of storage region 631 to store a new firmware corresponds to updating a blank record in a second entry to store new configuration data of the Applicant, and Yamaoka [0080] Fig. 7, validity field (V) determines if a record is valid or invalid, and priority field 657 (F) determines boot order, corresponding to a record being considered 'previous' or 'current' of the Applicant, and Fig. 7 contains bits that are stored, corresponding to status bits of the Applicant.),
‘and update the current and valid configuration record in the first entry to be a previous and valid configuration record by updating the corresponding status field of the first entry to indicate the previous and valid record type’ (Paragraph [0080] of Yamaoka, Fig. 7, priority field (F) changes the boot order of firmware based on updates. Fig. 8, steps X05-X07, previous firmware FW1 of Yamaoka corresponds is determined to be previous and valid configuration record when a new FW3 firmware is installed in step X05.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein the SOC configuration table is configured to store, in a first entry, a current and valid configuration record corresponding to a current configuration of the SOC’, ‘to obtain new configuration data’, ‘update a blank record in a second entry of the SOC configuration table’, and ‘in the first entry to be a previous and valid configuration record’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by utilizing a table to keep track of firmware versions, along with other properties of the firmware such as validity and priority order, as stated by Yamaoka [0080]. Furthermore, one would be motivated to combine Yamaoka’s ‘in a first entry’ limitation to increase efficiency by determining a validity of a first firmware (FW) to verify that the first FW can executes its functions, and when it is confirmed to operate normally, can then utilize a FW update notification to acquire and store an update of a FW in a second storage by the first FW to more efficiently update a system, as stated by Yamaoka [0141].
Regarding claim 2, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev also discloses ‘wherein the user space can only interact with the HSE through service calls wherein the service calls include service requests’ ([0017] Hardware modules 108 can communicate with aspects of an access control core (ACC) via means of encrypted communication, which can include providing services to the device 104.);
Regarding claim 3, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘wherein the corresponding status field of each entry of the SOC configuration table is configured to include one or more status bits and the corresponding configuration field of each entry is configured to include a plurality of configuration bits’ ([0080] Fig. 7, validity field (V) contains one bit, corresponding to a status field of one or more status bits of the corresponding configuration field of each entry including a plurality of configuration bits. [0152] Fig. 14, hash value 712 of Fig. 14 is used for an update to the firmware is part of an update notification 701 of Fig. 5, which is also the update notification 658 included in the FW table along with the validity bit (V) and priority bit (F) in Fig. 7, and as the hash value 712 contains a plurality of bits, corresponding to a configuration field having a plurality of configuration bits.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein the corresponding status field of each entry of the SOC configuration table is configured to include one or more status bits and the corresponding configuration field of each entry is configured to include a plurality of configuration bits’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by utilizing a table to keep track of validity of a firmware version, along with identifying separate firmware versions by a hash value, consisting of values to track the various versions, as stated by Yamaoka [0080] and [0152].
Regarding claim 4, Poeluev in view of Yamaoka teach the limitations of claims 1 and 3 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches “wherein the HSE is configured to, upon a failure in updating a corresponding configuration field of a selected entry of the SOC configuration table corresponding to a next available blank record with an updated configuration, update the corresponding status field of the selected entry to indicate the invalid record type” ([0144] When an update FW (firmware) is detected, and fails to determine validity, corresponding to an error of updating, operation continues with an older FW. This also occurs when an update FW contains a defect, and is marked as invalid, avoiding execution of a counterfeit FW, and can be marked as invalid in valid bit in Fig. 7.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein the HSE is configured to, upon a failure in updating a corresponding configuration field of a selected entry of the SOC configuration table corresponding to a next available blank record with an updated configuration, update the corresponding status field of the selected entry to indicate the invalid record type" in a system on a chip for securing SOC configurations and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to utilizing a table to keep track of firmware versions, as well as maintaining an order of booting up firmware versions based on what the latest updates were installed into the device (Yamaoka [0080]).
Regarding claim 6, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev also discloses ‘wherein the encrypted file cannot be decrypted by the user space and wherein the user space has no read, no write, and no modify access to the SOC configuration table’ ([0014] Hardware modules 108 provide services to device 104 and access control core (ACC) to control access to feature register 112. Hardware modules 108 cannot change the feature register 112 directly, corresponding to no read, no write, and no modify access to the SOC configuration table of the Applicant.);
Regarding claim 7, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘wherein the new configuration data in the second entry provides information as to which features of the SOC are enabled for an updated configuration of the SOC’ ([0271] Update notifications can contain information on how to apply the update, which can also contains features that may be enabled, as taught by the Applicant.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein the new configuration data in the second entry provides information as to which features of the SOC are enabled for an updated configuration of the SOC’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by allowing an operator to determine intermediate steps to seamlessly allow a device to transition from one firmware version or another, as stated by Yamaoka [0270].
Regarding claim 8, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘wherein the updated configuration of the SOC enables different features of the SOC than those which were enabled by configuration data of the previous and valid configuration record in the first entry’ ([0299] Example of different method of performing a similar function is stated with versions E and F of the firmware.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein the updated configuration of the SOC enables different features of the SOC than those which were enabled by configuration data of the previous and valid configuration record in the first entry’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by having a trial mode in the new firmware that has been updated, and this allows a firmware to be tested for compatibility to determine that new functions work, as stated by Yamaoka [0298].
Regarding claim 9, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev discloses ‘encrypted file’ (Poeluev's paragraph [0040], describing encrypted FCTs (feature control tickets), which can contain configurations for a device. Paragraph [0032] of Poeluev has decrypting of messages takes place in the ACC 110.);
Poeluev does not appear to fully disclose, but Yamaoka also teaches ‘wherein a memory of the user space is configured to receive the file with the new configuration data as an over-the-air (OTA) update’ (Paragraph [0048] of Yamaoka, in Fig. 1, terminal devices 100 connect to a wireless access point 10, which is connected to a control network 1, corresponding to an OTA update of the Applicant. Fig. 8, step X05, firmware updates of Yamaoka described in paragraph [0089] correspond to receiving a file with new configuration data of the Applicant .);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein a memory of the user space is configured to receive the file with the new configuration data as an over-the-air (OTA) update’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by allowing a convenient way to update firmware via a wireless network connected to network servers, as stated by Yamaoka [0048].
Regarding claim 10, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘wherein the HSE is configured to, in response to an error occurring during the decrypting or updating, update the current and valid configuration record storing the new configuration data in the second entry to be an invalid record’ ([0144] When an update FW (firmware) is detected, and fails to determine validity, corresponding to an error of updating of the Applicant, operation continues with an older FW. This also occurs when an update FW contains a defect, and is marked as invalid, avoiding execution of a counterfeit FW, and can be marked as invalid in valid bit in Fig. 7.),
‘and roll back a previous and valid record in a third entry of the SOC configuration table to be the current and valid configuration record’ ([0144] Older4 firmware is executed, corresponding to rolling back a previous valid record to a current valid record of the Applicant.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein the HSE is configured to, in response to an error occurring during the decrypting or updating, update the current and valid configuration record storing the new configuration data in the second entry to be an invalid record’ and ‘and roll back a previous and valid record in a third entry of the SOC configuration table to be the current and valid configuration record’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by determining if verification fails for the latest firmware, to allow the previous firmware to start, but also allows the latest firmware to be flagged, as stated by Yamaoka [0110].
Regarding claim 11, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘wherein the previous and valid record in the third entry is an initial default record of the SOC configuration record which includes a default configuration programmed when the SOC is manufactured’ ([0256] Version A firmware is referred to as an initial state, corresponding to an initial state of the Applicant, which can be stored in an entry equivalent to a third entry in a table as well.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein the previous and valid record in the third entry is an initial default record of the SOC configuration record which includes a default configuration programmed when the SOC is manufactured’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by having a firmware version be installed when the device is newly operated, and to act as a rollback candidate for if future updates fail on the device, as stated by Yamaoka [0256].
Regarding claim 12, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev discloses ‘wherein the HSE is configured to perform the decrypting in response to the update service request, after the SOC has been manufactured and deployed in the field’ (Paragraph [0015] of Poeluev states that a customer/client 102 can send a request to the ACC 110 to update, and in paragraph [0017] of Poeluev also describes that one or more hardware modules 108 can be configured by a costumer 102, corresponding to the invention being responsive to an update service request from a core of the user space of the Applicant. Paragraph [0014] of Poeluev contains ACC 110 which corresponds to the HSE of the Applicant, as it allows control of the SOC, including updating segments. Paragraph [0032] of Poeluev further teaches decryption of messages. [0018] Device is activated, or brought into a functional state, the ACC can then perform other functions described in Poeluev, including updating the SOC device, corresponding to the SOC being deployed in the field after manufacturing, Manufacturing is described in paragraph [0027] of Poeluev.);
Poeluev does not appear to fully disclose, but Yamaoka also teaches ‘the updates’ (Updates of Yamaoka, primarily in Fig. 8, steps X05-X07.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘the updates’ in Poeluev’s system on a chip (SOC) performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by allowing updates for a device to take the form of firmware, as well as maintaining older versions to act as rollback candidates, as stated by Yamaoka [0246].
Regarding claim 13, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev also discloses ‘wherein the storage circuitry is implemented as a non-volatile memory’ ([0029] Access control core (ACC) 110 uses NVM 114 to store various aspects including keys and certificates.);
Regarding claim 14, Poeluev in view of Yamaoka teach the limitations of claim 1 as recited above. Poeluev also discloses ‘wherein the HSE is configured to, in response to successfully decrypting and updating in response to the update service request, copy the new configuration data into a general purpose register (GPR) of the user space’ ([0014] Feature register 112 of Poeluev corresponds to a general purpose register (GPR) of the Applicant.);
Regarding claim 15, Poeluev discloses ‘a method for updating a hardware configuration in an SOC having a user space and a hardware encryption engine (HSE), the HSE including an SOC configuration table, the method comprising: providing an update service request by the user space to the HSE;’ (Paragraph [0026] of Poeluev, Fig. 1, device corresponds to a system on a chip (SOC) of the Applicant. System on a chip with various hardware modules also corresponds to a user space of the Applicant. Claim 13 of Poeluev describes a system on a chip of Poeluev as having one or more processors in their respective SOC. Paragraph [0014] of Poeluev, Fig. 1, Access Control Core (ACC) corresponds to a hardware security engine (HSE) of the Applicant. Feature register 112 corresponds to a configuration table storing configurations, with segments 116 corresponding to the configurations. Paragraph [0015] of Poeluev states that a customer/client 102 can send a request to the ACC 110 to update, and in paragraph [0017] of Poeluev also describes that one or more hardware modules 108 can be configured by a costumer 102, corresponding to the invention being responsive to an update service request from a core of the user space of the Applicant.);
‘in response to the update service request, decrypting, by the HSE, an encrypted file’ (Paragraph [0032] of Poeluev has decrypting of messages takes place in the ACC 110. Paragraph [0014] of Poeluev describes messages that are sent to an ACC that are encrypted.);
‘updating, by the HSE, to be the current and valid configuration record storing the new configuration data’ (Paragraph [0080] of Poeluev, Fig. 7, priority field (F) updates based on updates to firmware being installed. Updating firmware is also a function of Poeluev.);
‘updating, by the HSE, the current and valid configuration record’ (Paragraph [0080] of Poeluev Fig. 7, priority field (F) changes the boot order of firmware based on updates.);
‘and storing information corresponding to the current and valid configuration record in the second entry into a general purpose register of the user space’ ([0014] Feature register 112 of Poeluev corresponds to a general purpose register (GPR) of the Applicant.).
Poeluev does not appear to fully disclose, but Yamaoka also teaches the limitations of ‘SOC configuration table configured to store, in a first entry, a current and valid configuration record’ (Yamaoka [0087] recognizes that by starting with firmware FW1 and having it operate as normal, corresponding to a current and valid configuration of the Applicant. As firmware FW1 could be the only firmware that can be stored at a certain point in time, can also correspond to a first entry of an SOC configuration table of the Applicant as well.);
‘to obtain new configuration data’ (Fig. 8, step X05, firmware updates in paragraph [0089] of Yamaoka.);
‘updating a blank record in a second entry of the SOC configuration table’ (Paragraph [0089] of Yamaoka in Fig. 4, writable region of storage region 631 to store a new firmware corresponds to updating a blank record in a second entry to store new configuration data of the Applicant);
‘in the first entry to be a previous and valid configuration record’ (Fig. 8, steps X05-X07, previous firmware FW1 of Yamaoka corresponds is determined to be previous and valid configuration record when a new FW3 firmware is installed.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘SOC configuration table configured to store, in a first entry, a current and valid configuration record’, ‘to obtain new configuration data’, ‘updating a blank record in a second entry of the SOC configuration table’, and ‘in the first entry to be a previous and valid configuration record’ in Poeluev’s method of performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by utilizing a table to keep track of firmware versions, along with other properties of the firmware such as validity and priority order, as stated by Yamaoka [0080]. Furthermore, one would be motivated to combine Yamaoka’s ‘in a first entry’ limitation to increase efficiency by determining a validity of a first firmware (FW) to verify that the first FW can executes its functions, and when it is confirmed to operate normally, can then utilize a FW update notification to acquire and store an update of a FW in a second storage by the first FW to more efficiently update a system, as stated by Yamaoka [0141].
Regarding claim 16, Poeluev in view of Yamaoka teach the limitations of claim 15 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘wherein updating any entry of the SOC configuration further comprises updating a set of status bits which identify a type of record stored in the entry’ ([0299] Example of different method of performing a similar function is stated with versions E and F of the firmware.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein updating any entry of the SOC configuration further comprises updating a set of status bits which identify a type of record stored in the entry’ in Poeluev’s method of performing updating firmware on the system on a chip. One would have been motivated to make such a combination to
Regarding claim 17, Poeluev in view of Yamaoka teach the limitations of claim 15 as recited above. Poeluev also discloses ‘wherein the encrypted file cannot be decrypted by the user space and wherein the user space has no read, no write, and no modify access to the SOC configuration table’ ([0014] Hardware modules 108 provide services to device 104 and access control core (ACC) to control access to feature register 112. Hardware modules 108 cannot change the feature register 112 directly, corresponding to no read, no write, and no modify access to the SOC configuration table of the Applicant.);
Regarding claim 18, Poeluev in view of Yamaoka teach the limitations of claim 15 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘wherein the previous and valid configuration record in the first entry provides information as to which features of the SOC were enabled prior to the HSE receiving the update service request, and the new configuration data in the second entry provides information as to which features of the SOC are enabled after rebooting with the new configuration data in the second entry marked as the current and valid record’ ([0271] Update notifications can contain information on how to apply the update, which can also contains features that may be enabled, as taught by the Applicant. [0299] Example of different method of performing a similar function is stated with versions E and F of the firmware.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘wherein the previous and valid configuration record in the first entry provides information as to which features of the SOC were enabled prior to the HSE receiving the update service request, and the new configuration data in the second entry provides information as to which features of the SOC are enabled after rebooting with the new configuration data in the second entry marked as the current and valid record’ in Poeluev’s method of performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by allowing an operator to determine intermediate steps to seamlessly allow a device to transition from one firmware version or another, as stated by Yamaoka [0270], and by having a trial mode in the new firmware that has been updated, and this allows a firmware to be tested for compatibility to determine that new functions work, as stated by Yamaoka [0298].
Regarding claim 19, Poeluev in view of Yamaoka teach the limitations of claim 15 as recited above. Poeluev does not appear to disclose, but Yamaoka teaches ‘detecting an error by the HSE’ ([0144] When an update FW (firmware) is detected, and fails to determine validity, corresponding to an error of updating of the Applicant);
‘and in response to the error, updating, by the HSE, the current and valid configuration record storing the new configuration data in the second entry to be an invalid record, and updating, by the HSE, a previous and valid record in a third entry of the SOC configuration table to be the current and valid configuration record’ ([0144] When an update FW (firmware) is detected, and fails to determine validity, corresponding to an error of updating of the Applicant, operation continues with an older FW. This also occurs when an update FW contains a defect, and is marked as invalid, avoiding execution of a counterfeit FW, and can be marked as invalid in valid bit in Fig. 7.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s ‘detecting an error by the HSE’ and ‘in response to the error, updating, by the HSE, the current and valid configuration record storing the new configuration data in the second entry to be an invalid record, and updating, by the HSE, a previous and valid record in a third entry of the SOC configuration table to be the current and valid configuration record’ in Poeluev’s method of performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by determining if verification fails for the latest firmware, to allow the previous firmware to start, but also allows the latest firmware to be flagged, as stated by Yamaoka [0110].
Regarding claim 20, Poeluev in view of Yamaoka teach the limitations of claim 15 as recited above. Poeluev discloses ‘wherein providing the update service request by the user space to the HSE is performed after deploying the SOC in the field’ (Paragraph [0014] of Poeluev contains ACC 110 which corresponds to the HSE of the Applicant, as it allows control of the SOC, including updating segments. Paragraph [0032] of Poeluev further teaches decryption of messages, and updates of Yamaoka can correspond to messages of Poeluev, and corresponding to updates of update service requests of the Applicant. Poeluev's paragraph [0040], describing encrypted FCTs (feature control tickets), which can contain configurations for a device. [0018] Device is activated, or brought into a functional state, the ACC can then perform other functions described in Poeluev, including updating the SOC device, corresponding to the SOC being deployed in the field after manufacturing, Manufacturing is described in paragraph [0027] of Poeluev.);
Poeluev does not appear to fully disclose, but Yamaoka also teaches ‘and after transmitting the encrypted file with the new configuration data to the SOC’ (Updates of Yamaoka, primarily in Fig. 8, steps X05-X07. Paragraph [0048] of Yamaoka, in Fig. 1, terminal devices 100 connect to a wireless access point 10, which is connected to a control network 1, corresponding to an OTA update of the Applicant. Paragraph [0048] of Yamaoka, in Fig. 1, terminal devices 100 connect to a wireless access point 10, which is connected to a control network 1, corresponding to an OTA update of the Applicant. Combined with Poeluev's paragraph [0040], describing encrypted FCTs (feature control tickets), which can contain configurations for a device. Fig. 8, step X05, firmware updates in paragraph [0089] of Yamaoka, this teaches the limitations of new configuration data.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev and Yamaoka before them, to include Yamaoka’s and after transmitting the encrypted file with the new configuration data to the SOC’ in Poeluev’s method of performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by allowing a convenient way to update firmware via a wireless network connected to network servers, as stated by Yamaoka [0048].
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Poeluev in view of Yamaoka as applied to claims 1-4, and 6-20 above, and further in view of Boehm et al. (US 20210191660 A1), hereinafter Boehm.
Regarding claim 5, Poeluev in view of Yamaoka teach the limitations of claim 1 and 3 as recited above. Poeluev also discloses ‘wherein the HSE is configured to store each of the one or more status bits in each status field’ ([0080] Fig. 7 of Yamaoka, contains bits that are stored, corresponding to status bits of the Applicant.);
Poeluev does not appear to fully disclose, but Boehm also teaches the limitation of ‘in triplicate’ (Paragraph [0069] of Boehm states that DED bit can be stored in portion 380 of Fig. 3 in triplicate.);
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Poeluev, Yamaoka, and Boehm before them, to include Yamaoka’s ‘wherein the HSE is configured to store each of the one or more status bits in each status field’ and Boehm’s ‘in triplicate’ in Poeluev’s system on a chip (SOC) of performing updating firmware on the system on a chip. One would have been motivated to make such a combination to increase efficiency by allowing for up to three bits of errors in order to improve redundancy of the configurations, as taught by Boehm [0068] and [0069], and by utilizing a table to keep track of firmware versions, as well as maintaining an order of booting up firmware versions based on what the latest updates were installed into the device, as stated by Yamaoka [0080].
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 TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached Monday thru Friday 8AM-4PM ET.
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 L. Ortiz-Criado can be reached at (571) 272-7624 on Monday thru Friday, 7AM-7PM ET. 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.
/T.M./Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496