DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in Republic of Korea on 02/08/2024. It is noted, however, that applicant has not filed a certified copy of the KR10-2024-0019839 application as required by 37 CFR 1.55.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Agrawal et al. US Patent Application Publication No. 2021/0096621 (herein after referred to as Agrawal) in view of Rudraprakash et al. US Patent Application Publication No. 2025/0244991 (herein after referred to as Rudraprakash).
Regarding claim 1, Agrawal describes a storage device comprising: a volatile memory device configured to load main firmware (…memory module 24 including different types of memory devices 26… one or more volatile memory devices 34… the volatile memory devices 34 may be implemented as dynamic random-access memory (DRAM) and/or static random-access memory (SRAM)… (page 3, paragraph [0027]). …the memory controller 30 may load the firmware image 58 into execution memory 54 (page 5, paragraph [0042]). …store the firmware image 58 in execution memory 54 of the volatile memory device 34 (page 5, paragraph [0041])); and a storage controller configured to (…memory controller 30 (page 5, paragraph [0041])), receive a module loading request and a module from outside the storage device (…a firmware download command may initiate a transfer of data of the firmware image 58 from the client device 12 to the first buffer of the volatile memory device 34 (page 5, paragraph [0041]). The firmware image activation operation… in response to a firmware image activation command generated to update… an activation time of the firmware image 58 (e.g., a time duration between transmission of an update command to runtime of the updated firmware image 58) may be reduced (page 4, paragraph [0039]). Generally, the process 80 includes a memory controller receiving a firmware commit request (block 82), transmitting an updated image from a host image buffer to a volatile memory device (block 84)… (page 5, paragraph [0044])), perform a first signature verification operation verifying a first signature included in the module or a second signature verification operation verifying the first signature and a second signature included in the module based on information on a signature to be verified (A firmware commit (e.g., activation) command instructs the memory controller 30 to verify a signature of the firmware image 58 stored in the volatile memory device 34 (e.g., a buffer of the volatile memory 34) (page 5, paragraph [0041])), and load the module received from outside the storage device to the volatile memory device based on a result of performing the first signature verification operation or the second signature verification operation (After verification of the signature of the firmware image 58, the memory controller 30 may use a file system storage area (FSA) to store the firmware image 58 in execution memory 54 of the volatile memory device 34 (page 5, paragraph [0041])). Agrawal discloses transmitting an updated firmware image (paragraphs [0039], [0044], and [0046]), which would be distinct from the previously existing firmware image. However, Agrawal does not specifically describe wherein the module includes additional codes, the additional codes comprising at least one of debugging codes configured to correct errors, test codes configured to test the storage device, or user-specified operation codes.
Rudraprakash describes a processor environment architecture agnostic firmware update management operation. Specifically, a system, method, and computer-readable medium are disclosed for performing a firmware management operation. Various aspects of the invention reflect an appreciation that it is not uncommon for certain firmware components of a Basic Input/Output System (BIOS) associated with an information handling system (IHS) to be added, deleted, updated, revised, replaced, or restored over time. Likewise, various aspects of the invention reflect an appreciation that such BIOS firmware components are often added, deleted, updated, revised, replaced, or restored to provide security updates, fix known software bugs, improve performance, add new features and functionalities, and so forth (page 1, paragraph [0015]). Rudraprakash further discloses in step 850, the processor environment agnostic platform firmware update management operation 800 provides and installs a new firmware update package to the information handling system and execution completes at step 835. In certain embodiments, the new firmware update is provided via a latest fixed firmware package. In certain embodiments, the latest fixed firmware package includes a fully interpolated firmware module update array (page 11, paragraph [0095]). Rudraprakash suggests specific types of changes to the firmware including, providing security updates, fixing known software bugs, and adding new features and functionalities.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Rudraprakash teachings in the Agrawal system. Skilled artisan would have been motivated to incorporate the specific types of firmware changes provided by an update as taught by Rudraprakash in the Agrawal system for effectively providing security updates, fixing known software bugs, and adding new features and functionalities (Rudraprakash, page 1, paragraph [0015]). In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware update. This close relation between both of the references highly suggests an expectation of success.
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, further in view of Jeansonne et al. US Patent Application Publication No. 2025/0068715 (herein after referred to as Jeansonne).
Regarding claim 2, Agrawal in view of Rudraprakash describe the storage device of claim 1 (see above). Agrawal discloses that the memory controller 30, to verify written firmware image 58, may compare the memory slot 52 storing the firmware image 58 to a memory slot parameter of the firmware commit request. If the memory slot parameter matches the memory slot 52 that stores the firmware image 58, the memory controller 30 may continue on a verify the image header and signature of the firmware image 58, cryptographic hash or a digital signature (page 5, paragraph [0047]). However, Agrawal does not explicitly suggest wherein the storage controller includes a one-time programmable (OTP) memory configured to store information of the signature to be verified, and the information of the signature to be verified contains first verification target information corresponding to the first signature verification operation.
Jeansonne discloses a system for firmware authentication. Specifically, the computing device 1000 may comprise an update flag in the OTP memory portion. When the update flag is set to a first value (e.g. zero), the computing device 1000 is to perform the first authentication of the control instructions using the first key (page 3, paragraph [0026]). Authentication of the control instructions is performed using the first key and associated first signing process (page 3, paragraph [0030]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Jeansonne teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of storing a first key for a first signing process in an OTP memory as taught by Jeansonne in the Agrawal in view of Rudraprakash system for effectively storing authentication information in a secure manner. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 3, Agrawal in view of Rudraprakash and Jeansonne describe the storage device of claim 2 (see above), wherein the storage controller is configured to receive a verification information update request from outside the storage device and update the first verification target information stored in the OTP memory with second verification target information corresponding to the second signature verification operation in response to the verification information update request (In response to verifying the second authentication, the computing device 1000 may be to allow write access to the memory to allow the second key to be added to the one-time programmable portion of the memory. In this way the memory 1004 is protected and the second key may be written to the memory 1004 following verification that the second authentication is trusted, by way of the signature made using the first key (Jeansonne, page 3, paragraph [0027]). That is, once the second key is immutably added to the OTP memory portion… (Jeansonne, page 3, paragraph [0030])).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, further in view of Luciani, Jr. et al. US Patent Application Publication No. 2023/0106491 (herein after referred to as Luciani).
Regarding claim 4, Agrawal in view of Rudraprakash describe the storage device of claim 1 (see above). Agrawal does not specifically disclose wherein the storage controller is configured to: transmit a first nonce to outside the storage device in response to the module loading request, receive a third signature by signing the first nonce with a private key of a user, and compare the first nonce with a second nonce generated by decoding the third signature with a public key of the user.
Luciani discloses a system of security dominion of a computing device. Specifically, the use of tokens is described. In one example, the tokens can include an “Owner token.” As used herein, an owner token is a token that is based on a physical owner’s private key. The private key is used to encrypt the grantee’s public key and a NONCE. The physical owner’s transfer token can be stored in a secure storage of the computing device. The secure storage may be implemented inside of the management controller (e.g., via an internal secure storage or secure enclave) or as part of an external secure storage (page 1, paragraph [0015]). Once the physical owner is authenticated, a private key of the security dominion owner token can be used to encrypt a public key of the second entity and a nonce to create a transfer token. A grantee token associated with the second entity is received and includes a proof of an ability to recover the nonce from the transfer token. A second security dominion owner token can be included in the grantee token and be used to replace the original security dominion owner token. As noted above, the security dominion owner token can include an identifier of the security dominion owner (page 4, paragraph [0043]). At 506, the transfer token To is provided to the second entity. The second entity can encrypt the transfer token To with its private key. In some example, providing to the second entity can be to provide the token to a delegate of the second entity (e.g., an employee with a laptop, an administrator of a data center, etc.). In some examples, the physical owner is the second entity and would like to assume security domain ownership, for example, because the physical owner would like to put custom or open source firmware on the computing device. As such, physical access can be provided to the second entity. The second entity can then perform a cryptographic function on the transfer token To to create a security grantee token Te. The second entity can provide and the management controller can receive a grantee token including a proof of ability to recover the nonce from the transfer token 602 (508). Thus, a new security dominion owner token can be created. Transfer tokens can include a certificate with additional data, such as a public key of the security dominion owner token, information describing the security dominion owner, etc. (page 6, paragraph [0067]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Luciani teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of providing proof of ability to recover the nonce from a transfer token as taught by Luciani in the Agrawal in view of Rudraprakash system for effectively establishing security dominion. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Claims 5 – 7 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, further in view of Chandra et al. US Patent Application Publication No. 2023/0315913 (herein after referred to as Chandra).
Regarding claim 5, Agrawal in view of Rudraprakash describe the storage device of claim 1 (see above). Agrawal discloses that the memory controller 30, to verify written firmware image 58, may compare the memory slot 52 storing the firmware image 58 to a memory slot parameter of the firmware commit request. If the memory slot parameter matches the memory slot 52 that stores the firmware image 58, the memory controller 30 may continue on a verify the image header and signature of the firmware image 58, cryptographic hash or a digital signature (page 5, paragraph [0047]). However, Agrawal does not explicitly suggest wherein the first signature is a manufacturer signature in which module data included in the module are signed with a private key of a manufacturer, and the storage controller is configured to verify the manufacturer signature based on a result of comparing data obtained from decoding the manufacturer signature with a public key of the manufacturer and the module data included in the module.
Chandra discloses a programmable logic device capable of authentication a configuration image. Specifically, in various embodiments, an authentication engine may be implemented by and/or within the configuration engine 440, the security engine 420, and/or a combination of those and/or including other IC modules 480. An authentication engine may be configured to authenticate the configuration image, such as where the configuration image is signed using a private key associated with the secure PLD customer 510 for the secure PLD 410 or secure PLD manufacturer 520 of the secure PLD 410, a corresponding public key is stored in the NVM 450, and where the authenticating includes using the public key to verify that the configuration image is signed using the private key associated with the secure PLD customer 510 or secure PLD manufacturer 520. An authentication engine may be configured to determine the configuration image includes a complete configuration image for the secure PLD 410, such as by comparing a size of the configuration image to a corresponding expected size or checksum, for example. An authentication engine may be configured to validate the configuration image with respect to the secure PLD 410, which may include design version comparisons to rollback protection rulesets and/or other configuration images, functionality comparisons, serial number, device ID, and/or other comparisons, for example. In such embodiments, the authentication engine may be configured to provide a pass result when all such checks are passed, for example, and to provide a fail result when any of such checks fail. In general, such design version comparisons and/or validation may be performed by an authentication engine or may be performed as part of a pre-authentication process (page 13, paragraph [0100])).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Chandra teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of using manufacturer or customer private/public key pairs as taught by Chandra in the Agrawal in view of Rudraprakash system for effectively authenticating configuration information. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 6, Agrawal in view of Rudraprakash describe the storage device of claim 1 (see above). Agrawal discloses that the memory controller 30, to verify written firmware image 58, may compare the memory slot 52 storing the firmware image 58 to a memory slot parameter of the firmware commit request. If the memory slot parameter matches the memory slot 52 that stores the firmware image 58, the memory controller 30 may continue on a verify the image header and signature of the firmware image 58, cryptographic hash or a digital signature (page 5, paragraph [0047]). However, Agrawal does not explicitly suggest wherein the second signature is a user signature in which module data and the first signature included in the module are signed with a private key of a user, and the storage controller is configured to verify the user signature based on a result of comparing data obtained from decoding the user signature with a public key of the user with the module data and the first signature included in the module.
Chandra discloses a programmable logic device capable of authentication a configuration image. Specifically, in various embodiments, an authentication engine may be implemented by and/or within the configuration engine 440, the security engine 420, and/or a combination of those and/or including other IC modules 480. An authentication engine may be configured to authenticate the configuration image, such as where the configuration image is signed using a private key associated with the secure PLD customer 510 for the secure PLD 410 or secure PLD manufacturer 520 of the secure PLD 410, a corresponding public key is stored in the NVM 450, and where the authenticating includes using the public key to verify that the configuration image is signed using the private key associated with the secure PLD customer 510 or secure PLD manufacturer 520. An authentication engine may be configured to determine the configuration image includes a complete configuration image for the secure PLD 410, such as by comparing a size of the configuration image to a corresponding expected size or checksum, for example. An authentication engine may be configured to validate the configuration image with respect to the secure PLD 410, which may include design version comparisons to rollback protection rulesets and/or other configuration images, functionality comparisons, serial number, device ID, and/or other comparisons, for example. In such embodiments, the authentication engine may be configured to provide a pass result when all such checks are passed, for example, and to provide a fail result when any of such checks fail. In general, such design version comparisons and/or validation may be performed by an authentication engine or may be performed as part of a pre-authentication process (page 13, paragraph [0100])).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Chandra teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of using manufacturer or customer private/public key pairs as taught by Chandra in the Agrawal in view of Rudraprakash system for effectively authenticating configuration information. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 7, Agrawal in view of Rudraprakash describe the storage device of claim 1 (see above). Agrawal discloses that the memory controller 30, to verify written firmware image 58, may compare the memory slot 52 storing the firmware image 58 to a memory slot parameter of the firmware commit request. If the memory slot parameter matches the memory slot 52 that stores the firmware image 58, the memory controller 30 may continue on a verify the image header and signature of the firmware image 58, cryptographic hash or a digital signature (page 5, paragraph [0047]). However, Agrawal does not explicitly suggest wherein the storage controller is configured to: obtain a decryption key in which an encryption key included in the module is decoded by a private key of a manufacturer, and control the volatile memory device to load a code in which at least one of the additional codes included in the module is decoded by the decryption key to the volatile memory device.
Chandra discloses a programmable logic device capable of authentication a configuration image. Specifically, in various embodiments, an authentication engine may be implemented by and/or within the configuration engine 440, the security engine 420, and/or a combination of those and/or including other IC modules 480. An authentication engine may be configured to authenticate the configuration image, such as where the configuration image is signed using a private key associated with the secure PLD customer 510 for the secure PLD 410 or secure PLD manufacturer 520 of the secure PLD 410, a corresponding public key is stored in the NVM 450, and where the authenticating includes using the public key to verify that the configuration image is signed using the private key associated with the secure PLD customer 510 or secure PLD manufacturer 520. An authentication engine may be configured to determine the configuration image includes a complete configuration image for the secure PLD 410, such as by comparing a size of the configuration image to a corresponding expected size or checksum, for example. An authentication engine may be configured to validate the configuration image with respect to the secure PLD 410, which may include design version comparisons to rollback protection rulesets and/or other configuration images, functionality comparisons, serial number, device ID, and/or other comparisons, for example. In such embodiments, the authentication engine may be configured to provide a pass result when all such checks are passed, for example, and to provide a fail result when any of such checks fail. In general, such design version comparisons and/or validation may be performed by an authentication engine or may be performed as part of a pre-authentication process (page 13, paragraph [0100])).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Chandra teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of using manufacturer or customer private/public key pairs as taught by Chandra in the Agrawal in view of Rudraprakash system for effectively authenticating configuration information. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Claims 8 – 10 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, further in view of Savage et al. US Patent Application Publication No. 2019/0332775 (herein after referred to as Savage) and “Towards Automated Dynamic Analysis for Linux-based Embedded Firmware” by Daming D. Chen et al. (herein after referred to as NPL1).
Regarding claim 8, Agrawal in view of Rudraprakash describe the storage device of claim 1 (see above). Agrawal discloses that the memory controller 30, to verify written firmware image 58, may compare the memory slot 52 storing the firmware image 58 to a memory slot parameter of the firmware commit request. If the memory slot parameter matches the memory slot 52 that stores the firmware image 58, the memory controller 30 may continue on a verify the image header and signature of the firmware image 58, cryptographic hash or a digital signature (page 5, paragraph [0047]). However, Agrawal does not explicitly suggest wherein the storage controller includes a symbol resolution module configured to generate application programming interface (API) access information indicating whether access to APIs included in the main firmware is allowed based on API information included in the module.
Savage discloses a system that receives a digital signature, signed by a signing authority, for a request for utilization of an information handling system firmware application programming interface (API) of the information handling system firmware. Specifically, for example, access of the APIs may be controlled, managed, and/or regulated via the one or more authorization systems, methods and/or processes and/or the one or more authentication systems, methods and/or processes. In one or more embodiments, multiple authorizations may be utilized to invoke the APIs. For example, the APIs may be or include one or more manufacturing APIs. For instance, the one or more manufacturing APIs may be utilized during one or more manufacturing processes of building and/or configuring an information handling system. In one or more embodiments, dual authorization may be utilized to invoke APIs of information handling system firmware in a manufacturing process. For example, a manufacturing facility may access, via dual authorization, one or more APIs of information handling system firmware in a manufacturing process. For instance, the manufacturing facility may utilize dual authorization to access the APIs of the information handling system firmware to configure one or more systems and/or subsystems of the information handling systems (page 2, paragraph [0018]). In one or more embodiments, a first level authorization may include utilizing one or more digital certificates and/or one or more digital signatures. In one example, a request to utilize one or more APIs may be signed by a digital signature. For instance, the one or more APIs may be signed by the digital signature may be or include one or more manufacturing APIs signed by a digital signature. In another example, a digital certificate may be utilized in authenticating one or more digital signatures. In one or more embodiments, a second level authorization may include utilizing one or more user credentials. For example, the one or more user credentials may include a user name and a password combination (page 2, paragraph [0019]). Turning now to FIG. 5, an example of a method of configuring an information handling system is illustrated, according to one or more embodiments. At 510, remote access module firmware with a root CA public key and scope qualifiers may be installed. For example, remote access module firmware with a root CA public key and scope qualifiers may be installed on a remote access module. In one or more embodiments, scope qualifiers may include one or more permissions that may permit, allow, and/or enable one or more actions and/or one or more of the APIs of the information handling system firmware to be utilized. In one example, the scope qualifiers may include one or more permissions that permit, allow, and/or enable a factory to configure a MAC address of an information handling system. In a second example, the scope qualifiers may include one or more permissions that permit, allow, and/or enable a factory to configure a PPID of a component of an information handling system. In a third example, the scope qualifiers may include one or more permissions that permit, allow, and/or enable one or more types of manufacturing. In one instance, the scope qualifiers may include one or more permissions that permit, allow, and/or enable granting a factory to access one or more APIs of a first model of information handling system. In another instance, the scope qualifiers may include one or more permissions that may not permit, allow, and/or enable granting a factory to access one or more APIs of a second model of information handling system, different from the first model of information handling system. In a fourth example, the scope qualifiers may include one or more hardware identifiers, that may be utilized to identify hardware with which access of one or more APIs may be granted. In one instance, a hard identifier may identify a make and/or a model of a piece of hardware or a hardware component. In another instance, a hard identifier may uniquely identify a piece of hardware or a hardware component. In another example, the scope qualifiers may include one or more permissions that permit, allow, and/or enable a factory “root”, “administrator”, and/or “super user” access of the information handling system firmware. In one or more embodiments, the remote access module firmware may be compiled, built, and/or configured and then provided to a manufacturer of one or more components of an information handling system. For example, the manufacturer of the one or more components of the information handling system may produce one or more of a remote access module, a motherboard, a printed circuit board (PCB), and an assembled PCB (e.g., a PCB with components soldered to the PCB), among others (page 6, paragraph [0053]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Savage teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of including scope qualifiers including permissions that permit, allow, and/or enable granting a factory to access one or more APIs of a first model of information handling system as taught by Savage in the Agrawal in view of Rudraprakash system for effectively authenticating API access in firmware. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
NPL1 proposes a system that attempts to accurately identify vulnerabilities in embedded firmware. Specifically, it discloses that due to limited write cycles on primary storage device, many firmware images mount a temporary memory-backed filesystem at boot for volatile data. This filesystem is mounted and generated dynamically. As a result, the directories /dev/ and /etc/ may be symbolic links to subdirectories within the temporary filesystem, thus appearing broken when examined statically (page marked 4, left column, lines 17 – 20). Fortunately, ELF dynamic loaders for Linux systems support lazy linking, which allows the resolution of external function symbols to be delayed until usage (page marked 7, left column, lines 10 – 12). Since the ELF loader uses a global symbol lookup scope during resolution, we were able to compile our NVRAM library with the -nostdlib compiler flag, delaying resolution of external symbols until after the calling process had already loaded the system C runtime library (page marked 7, left column, lines 17 – 21). Symbol resolution is the process of converting symbolic names for functions and variables into the actual memory addresses where they are located.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the NPL1 teachings in the Agrawal in view of Rudraprakash and Savage system. Skilled artisan would have been motivated to incorporate the method of symbol resolution as taught by NPL1 in the Agrawal in view of Rudraprakash and Savage system for effectively converting human readable code into computer readable addresses and code. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 9, Agrawal in view of Rudraprakash, Savage and NPL1 describe the storage device of claim 8 (see above), wherein the storage controller includes a processor configured to execute the additional codes included in the module in response to a module execution request received from outside the storage device (During operation of the computing system, the processing circuitry may perform various operations (e.g., tasks) by executing corresponding instructions (Agrawal, page 1, paragraph [0010]). …updated firmware image… (Agrawal, page 4, paragraph [0039]). …such BIOS firmware components are often added, deleted, updated, revised, replaced, or restored to provide security updates, fix known software bugs, improve performance, add new features and functionalities, and so forth (Rudraprakash, page 1, paragraph [0039]). Using the updated firmware would result in accessing the additional codes of the updated firmware), the processor configured to transmit an API request (For instance, the one or more manufacturing APIs may be utilized during one or more manufacturing processes of building and/or configuring an information handling system. In one or more embodiments, dual authorization may be utilized to invoke APIs of information handling system firmware in a manufacturing process. For example, a manufacturing facility may access, via dual authorization, one or more APIs of information handling system firmware in a manufacturing process. For instance, the manufacturing facility may utilize dual authorization to access the APIs of the information handling system firmware to configure one or more systems and/or subsystems of the information handling systems (Savage, page 2, paragraph [0018])) that requests an API corresponding to a symbol code among the additional codes in response to execution of the symbol code to the symbol resolution module (symbol resolution (NPL1, page marked 7, left column, lines 17 – 21)).
Regarding claim 10, Agrawal in view of Rudraprakash, Savage and NPL1 describe the storage device of claim 9 (see above), wherein the symbol resolution module (symbol resolution (NPL1, page marked 7, left column, lines 17 – 21)) is configured to obtain an API corresponding to the symbol code among the APIs included in the main firmware based on API access information in response to the API request (For instance, the one or more manufacturing APIs may be utilized during one or more manufacturing processes of building and/or configuring an information handling system. In one or more embodiments, dual authorization may be utilized to invoke APIs of information handling system firmware in a manufacturing process. For example, a manufacturing facility may access, via dual authorization, one or more APIs of information handling system firmware in a manufacturing process. For instance, the manufacturing facility may utilize dual authorization to access the APIs of the information handling system firmware to configure one or more systems and/or subsystems of the information handling systems (Savage, page 2, paragraph [0018])), the symbol resolution module configured to provide a result of execution of the API corresponding to the symbol code (During operation of the computing system, the processing circuitry may perform various operations (e.g., tasks) by executing corresponding instructions (Agrawal, page 1, paragraph [0010])).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, further in view of Xie et al. US Patent Application Publication No. 2022/0156377 (herein after referred to as Xie).
Regarding claim 11, Agrawal in view of Rudraprakash describe the storage device of claim 1 (see above). Agrawal discloses that the memory controller 30, to verify written firmware image 58, may compare the memory slot 52 storing the firmware image 58 to a memory slot parameter of the firmware commit request. If the memory slot parameter matches the memory slot 52 that stores the firmware image 58, the memory controller 30 may continue on a verify the image header and signature of the firmware image 58, cryptographic hash or a digital signature (page 5, paragraph [0047]). However, Agrawal does not explicitly suggest wherein the storage controller is configured to modify a code corresponding to a target address included in the module among main codes included in the main firmware into a code that executes a patch code included in the module based on the target address, the storage controller configured to modify the code in response to operation mode information included in the module including patch mode information.
Xie discloses a secure firmware update patch release process. Specifically, a method is disclosed for performing hardware verification testing of a firmware update patch. The method includes receiving the firmware update patch. The firmware update patch includes code for modifying firmware and a platform signature. The platform signature was generated using a platform private key. The firmware includes a standard mode and a test mode. The method further includes enabling the test mode of the firmware in a setup menu of the firmware. The method further includes authenticating, while the firmware operates in the test mode, the firmware update patch using a platform public key and the platform signature. The platform signature is not sufficient to authenticate the firmware update patch when the firmware operates in the standard mode. The method further includes modifying the firmware based on the firmware update patch to generate modified firmware. The method further includes performing the hardware verification testing on the modified firmware (page 1, paragraph [0018]). A variety of methods exist for a computing device to authenticate code before allowing the code to execute on the computing device. One way to protect the computing device from unauthorized code is through signing. Signing is a method for verifying that a package is authentic (i.e., is what it purports to be or comes from a trusted source) and has integrity (i.e., has not been changed). Signing may involve the use of two keys or certificates. The first key may be a private key that is not shared publicly. Access to the private key may be limited and strictly controlled. The private key may be used to generate a signature that is added to a firmware update patch. In some cases, a developer of the firmware update patch may possess the private key and may sign the firmware update patch using the private key. In other cases, an operator of a system on which the firmware update patch is to be installed may possess the private key and sign the firmware update patch using the private key. In other cases, a manufacturer of hardware managed by firmware that is to be updated with the firmware update patch may possess the private key and sign the firmware update patch using the private key (page 3, paragraph [0040]). The patch 320 may be a firmware update patch (such as the test patch 120 or the test capsule 220). The patch 320 may include code (which may be included in a payload such as the payload 206b) for modifying the firmware 316. A developer (such as the developer 102) may have created the code and built the code for inclusion in the patch 320. The patch 320 may include a platform public key 310a and a platform signature 322a. A computing system operator (such as the computing system operator 150) may have added the platform public key 310a and the platform signature 322a to the patch 320 without re-building or modifying the code (page 7, paragraph [0082]). Data, such as the firmware data, is conventionally stored at addresses of the memory devices in which they are stored.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Xie teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of providing a firmware update patch signed by a private key as taught by Xie in the Agrawal in view of Rudraprakash system for effectively authenticating a firmware patch for modifying existing firmware. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Claims 12 – 16 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, Chandra and Xie.
Regarding claim 12, Agrawal describes a storage device comprising: a volatile memory device configured to load main firmware including main codes (…memory module 24 including different types of memory devices 26… one or more volatile memory devices 34… the volatile memory devices 34 may be implemented as dynamic random-access memory (DRAM) and/or static random-access memory (SRAM)… (page 3, paragraph [0027]). …the memory controller 30 may load the firmware image 58 into execution memory 54 (page 5, paragraph [0042]). …store the firmware image 58 in execution memory 54 of the volatile memory device 34 (page 5, paragraph [0041])); and a storage controller configured to (…memory controller 30 (page 5, paragraph [0041])): receive a module from outside the storage device (…a firmware download command may initiate a transfer of data of the firmware image 58 from the client device 12 to the first buffer of the volatile memory device 34 (page 5, paragraph [0041]). The firmware image activation operation… in response to a firmware image activation command generated to update… an activation time of the firmware image 58 (e.g., a time duration between transmission of an update command to runtime of the updated firmware image 58) may be reduced (page 4, paragraph [0039]). Generally, the process 80 includes a memory controller receiving a firmware commit request (block 82), transmitting an updated image from a host image buffer to a volatile memory device (block 84)… (page 5, paragraph [0044])), load the module to the volatile memory device based on a result of verifying a signature (After verification of the signature of the firmware image 58, the memory controller 30 may use a file system storage area (FSA) to store the firmware image 58 in execution memory 54 of the volatile memory device 34 (page 5, paragraph [0041])). Agrawal discloses transmitting an updated firmware image (paragraphs [0039], [0044], and [0046]), which would be distinct from the previously existing firmware image. However, Agrawal does not specifically describe wherein the module includes additional codes, the additional codes comprising at least one of debugging codes configured to correct errors, test codes configured to test the storage device, or user-specified operation codes. Agrawal discloses that the memory controller 30, to verify written firmware image 58, may compare the memory slot 52 storing the firmware image 58 to a memory slot parameter of the firmware commit request. If the memory slot parameter matches the memory slot 52 that stores the firmware image 58, the memory controller 30 may continue on a verify the image header and signature of the firmware image 58, cryptographic hash or a digital signature (page 5, paragraph [0047]). However, Agrawal does not explicitly suggest manufacturer signature and a user signature, nor modify a code corresponding to a target address included in the module among the main codes based on operation mode information included in the module.
Rudraprakash describes a processor environment architecture agnostic firmware update management operation. Specifically, a system, method, and computer-readable medium are disclosed for performing a firmware management operation. Various aspects of the invention reflect an appreciation that it is not uncommon for certain firmware components of a Basic Input/Output System (BIOS) associated with an information handling system (IHS) to be added, deleted, updated, revised, replaced, or restored over time. Likewise, various aspects of the invention reflect an appreciation that such BIOS firmware components are often added, deleted, updated, revised, replaced, or restored to provide security updates, fix known software bugs, improve performance, add new features and functionalities, and so forth (page 1, paragraph [0015]). Rudraprakash further discloses in step 850, the processor environment agnostic platform firmware update management operation 800 provides and installs a new firmware update package to the information handling system and execution completes at step 835. In certain embodiments, the new firmware update is provided via a latest fixed firmware package. In certain embodiments, the latest fixed firmware package includes a fully interpolated firmware module update array (page 11, paragraph [0095]). Rudraprakash suggests specific types of changes to the firmware including, providing security updates, fixing known software bugs, and adding new features and functionalities.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Rudraprakash teachings in the Agrawal system. Skilled artisan would have been motivated to incorporate the specific types of firmware changes provided by an update as taught by Rudraprakash in the Agrawal system for effectively providing security updates, fixing known software bugs, and adding new features and functionalities (Rudraprakash, page 1, paragraph [0015]). In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware update. This close relation between both of the references highly suggests an expectation of success.
Chandra discloses a programmable logic device capable of authentication a configuration image. Specifically, in various embodiments, an authentication engine may be implemented by and/or within the configuration engine 440, the security engine 420, and/or a combination of those and/or including other IC modules 480. An authentication engine may be configured to authenticate the configuration image, such as where the configuration image is signed using a private key associated with the secure PLD customer 510 for the secure PLD 410 or secure PLD manufacturer 520 of the secure PLD 410, a corresponding public key is stored in the NVM 450, and where the authenticating includes using the public key to verify that the configuration image is signed using the private key associated with the secure PLD customer 510 or secure PLD manufacturer 520. An authentication engine may be configured to determine the configuration image includes a complete configuration image for the secure PLD 410, such as by comparing a size of the configuration image to a corresponding expected size or checksum, for example. An authentication engine may be configured to validate the configuration image with respect to the secure PLD 410, which may include design version comparisons to rollback protection rulesets and/or other configuration images, functionality comparisons, serial number, device ID, and/or other comparisons, for example. In such embodiments, the authentication engine may be configured to provide a pass result when all such checks are passed, for example, and to provide a fail result when any of such checks fail. In general, such design version comparisons and/or validation may be performed by an authentication engine or may be performed as part of a pre-authentication process (page 13, paragraph [0100])).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Chandra teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of using manufacturer or customer private/public key pairs as taught by Chandra in the Agrawal in view of Rudraprakash system for effectively authenticating configuration information. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Xie discloses a secure firmware update patch release process. Specifically, a method is disclosed for performing hardware verification testing of a firmware update patch. The method includes receiving the firmware update patch. The firmware update patch includes code for modifying firmware and a platform signature. The platform signature was generated using a platform private key. The firmware includes a standard mode and a test mode. The method further includes enabling the test mode of the firmware in a setup menu of the firmware. The method further includes authenticating, while the firmware operates in the test mode, the firmware update patch using a platform public key and the platform signature. The platform signature is not sufficient to authenticate the firmware update patch when the firmware operates in the standard mode. The method further includes modifying the firmware based on the firmware update patch to generate modified firmware. The method further includes performing the hardware verification testing on the modified firmware (page 1, paragraph [0018]). A variety of methods exist for a computing device to authenticate code before allowing the code to execute on the computing device. One way to protect the computing device from unauthorized code is through signing. Signing is a method for verifying that a package is authentic (i.e., is what it purports to be or comes from a trusted source) and has integrity (i.e., has not been changed). Signing may involve the use of two keys or certificates. The first key may be a private key that is not shared publicly. Access to the private key may be limited and strictly controlled. The private key may be used to generate a signature that is added to a firmware update patch. In some cases, a developer of the firmware update patch may possess the private key and may sign the firmware update patch using the private key. In other cases, an operator of a system on which the firmware update patch is to be installed may possess the private key and sign the firmware update patch using the private key. In other cases, a manufacturer of hardware managed by firmware that is to be updated with the firmware update patch may possess the private key and sign the firmware update patch using the private key (page 3, paragraph [0040]). The patch 320 may be a firmware update patch (such as the test patch 120 or the test capsule 220). The patch 320 may include code (which may be included in a payload such as the payload 206b) for modifying the firmware 316. A developer (such as the developer 102) may have created the code and built the code for inclusion in the patch 320. The patch 320 may include a platform public key 310a and a platform signature 322a. A computing system operator (such as the computing system operator 150) may have added the platform public key 310a and the platform signature 322a to the patch 320 without re-building or modifying the code (page 7, paragraph [0082]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Xie teachings in the Agrawal in view of Rudraprakash and Chandra system. Skilled artisan would have been motivated to incorporate the method of providing a firmware update patch signed by a private key as taught by Xie in the Agrawal in view of Rudraprakash and Chandra system for effectively authenticating a firmware patch for modifying existing firmware. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 13, Agrawal in view of Rudraprakash, Chandra and Xie describe the storage device of claim 12 (see above), wherein the storage controller is configured to verify the manufacturer signature based on a result of comparing data obtained from decoding the manufacturer signature with a public key of a manufacturer with module data included in the module (An authentication engine may be configured to authenticate the configuration image, such as where the configuration image is signed using a private key associated with the secure PLD customer 510 for the secure PLD 410 or secure PLD manufacturer 520 of the secure PLD 410, a corresponding public key is stored in the NVM 450, and where the authenticating includes using the public key to verify that the configuration image is signed using the private key associated with the secure PLD customer 510 or secure PLD manufacturer 520 (Chandra, page 13, paragraph [0100])).
Regarding claim 14, Agrawal in view of Rudraprakash, Chandra and Xie describe the storage device of claim 12 (see above), wherein the storage controller is configured to verify the user signature based on a result of comparing data obtained from decoding the user signature with a public key of a user with module data included in the module (An authentication engine may be configured to authenticate the configuration image, such as where the configuration image is signed using a private key associated with the secure PLD customer 510 for the secure PLD 410 or secure PLD manufacturer 520 of the secure PLD 410, a corresponding public key is stored in the NVM 450, and where the authenticating includes using the public key to verify that the configuration image is signed using the private key associated with the secure PLD customer 510 or secure PLD manufacturer 520 (Chandra, page 13, paragraph [0100])).
Regarding claim 15, Agrawal in view of Rudraprakash, Chandra and Xie describe the storage device of claim 12 (see above), wherein the operation mode information includes patch mode information, and the storage controller is configured to modify a code corresponding to the target address to a code executing a patch code included in the module (The patch 320 may be a firmware update patch (such as the test patch 120 or the test capsule 220). The patch 320 may include code (which may be included in a payload such as the payload 206b) for modifying the firmware 316. A developer (such as the developer 102) may have created the code and built the code for inclusion in the patch 320. The patch 320 may include a platform public key 310a and a platform signature 322a. A computing system operator (such as the computing system operator 150) may have added the platform public key 310a and the platform signature 322a to the patch 320 without re-building or modifying the code (Xie, page 7, paragraph [0082]). Data, such as the firmware data, is conventionally stored at addresses of the memory devices in which they are stored).
Regarding claim 16, Agrawal in view of Rudraprakash, Chandra and Xie describe the storage device of claim 15 (see above), further comprising: a non-volatile memory device including a firmware patch block, wherein the storage controller is configured to control the non-volatile memory device to store patch data including the target address, a loading address where the patch code is loaded, and the patch code into the firmware patch block (The patch 320 may be a firmware update patch (such as the test patch 120 or the test capsule 220). The patch 320 may include code (which may be included in a payload such as the payload 206b) for modifying the firmware 316. A developer (such as the developer 102) may have created the code and built the code for inclusion in the patch 320. The patch 320 may include a platform public key 310a and a platform signature 322a. A computing system operator (such as the computing system operator 150) may have added the platform public key 310a and the platform signature 322a to the patch 320 without re-building or modifying the code (Xie, page 7, paragraph [0082]). Data, such as the firmware data, is conventionally stored at addresses of the memory devices in which they are stored).
Claims 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, Luciani, Chandra, NPL1, and Xie.
Regarding claim 17, Agrawal describes a storage controller comprising: a processor configured to execute main firmware and configured to (…memory controller 30 (page 5, paragraph [0041])), verify a signature in which module data included in an externally received module are signed (A firmware commit (e.g., activation) command instructs the memory controller 30 to verify a signature of the firmware image 58 stored in the volatile memory device 34 (e.g., a buffer of the volatile memory 34) (page 5, paragraph [0041]). The firmware image activation operation… in response to a firmware image activation command generated to update… an activation time of the firmware image 58 (e.g., a time duration between transmission of an update command to runtime of the updated firmware image 58) may be reduced (page 4, paragraph [0039]). Generally, the process 80 includes a memory controller receiving a firmware commit request (block 82), transmitting an updated image from a host image buffer to a volatile memory device (block 84)… (page 5, paragraph [0044])), and execute the module based on a result of verifying a signature (After verification of the signature of the firmware image 58, the memory controller 30 may use a file system storage area (FSA) to store the firmware image 58 in execution memory 54 of the volatile memory device 34 (page 5, paragraph [0041]). The firmware image is executed from the execution memory (page 2, paragraph [0014])). Agrawal discloses transmitting an updated firmware image (paragraphs [0039], [0044], and [0046]), which would be distinct from the previously existing firmware image. However, Agrawal does not specifically describe wherein the module includes additional codes, the additional codes comprising at least one of debugging codes configured to correct errors, test codes configured to test the storage device, or user-specified operation codes. Agrawal does not explicitly suggest a first and second processor, a manufacturer signature signed with a private key of said manufacturer, execute the module based on a result of verifying a user signature signed with a private key of said user, nor a symbol resolution module configured to perform a code patch operation modifying a code corresponding to a target address included in the module among main codes included in the main firmware based on the target address.
Rudraprakash describes a processor environment architecture agnostic firmware update management operation. Specifically, a system, method, and computer-readable medium are disclosed for performing a firmware management operation. Various aspects of the invention reflect an appreciation that it is not uncommon for certain firmware components of a Basic Input/Output System (BIOS) associated with an information handling system (IHS) to be added, deleted, updated, revised, replaced, or restored over time. Likewise, various aspects of the invention reflect an appreciation that such BIOS firmware components are often added, deleted, updated, revised, replaced, or restored to provide security updates, fix known software bugs, improve performance, add new features and functionalities, and so forth (page 1, paragraph [0015]). Rudraprakash further discloses in step 850, the processor environment agnostic platform firmware update management operation 800 provides and installs a new firmware update package to the information handling system and execution completes at step 835. In certain embodiments, the new firmware update is provided via a latest fixed firmware package. In certain embodiments, the latest fixed firmware package includes a fully interpolated firmware module update array (page 11, paragraph [0095]). Rudraprakash suggests specific types of changes to the firmware including, providing security updates, fixing known software bugs, and adding new features and functionalities.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Rudraprakash teachings in the Agrawal system. Skilled artisan would have been motivated to incorporate the specific types of firmware changes provided by an update as taught by Rudraprakash in the Agrawal system for effectively providing security updates, fixing known software bugs, and adding new features and functionalities (Rudraprakash, page 1, paragraph [0015]). In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware update. This close relation between both of the references highly suggests an expectation of success.
Luciani discloses a system of security dominion of a computing device. Specifically, the use of tokens is described. In one example, the tokens can include an “Owner token.” As used herein, an owner token is a token that is based on a physical owner’s private key. The private key is used to encrypt the grantee’s public key and a NONCE. The physical owner’s transfer token can be stored in a secure storage of the computing device. The secure storage may be implemented inside of the management controller (e.g., via an internal secure storage or secure enclave) or as part of an external secure storage (page 1, paragraph [0015]). In some examples, the management controller 106 can load a boot loader for the management controller 106 that can self verify using its keys (page 3, paragraph [0029]). The firmware update package can come from a network device connected via a management network associated with the management controller 106 or another source, such as an operating system executing on a host processor 102 communicatively coupled to the management controller (page 3, paragraph [0032]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Luciani teachings in the Agrawal in view of Rudraprakash system. Skilled artisan would have been motivated to incorporate the method of providing separate controller/processor hardware as taught by Luciani in the Agrawal in view of Rudraprakash system for effectively providing dedicated hardware to verify signatures. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Chandra discloses a programmable logic device capable of authentication a configuration image. Specifically, in various embodiments, an authentication engine may be implemented by and/or within the configuration engine 440, the security engine 420, and/or a combination of those and/or including other IC modules 480. An authentication engine may be configured to authenticate the configuration image, such as where the configuration image is signed using a private key associated with the secure PLD customer 510 for the secure PLD 410 or secure PLD manufacturer 520 of the secure PLD 410, a corresponding public key is stored in the NVM 450, and where the authenticating includes using the public key to verify that the configuration image is signed using the private key associated with the secure PLD customer 510 or secure PLD manufacturer 520. An authentication engine may be configured to determine the configuration image includes a complete configuration image for the secure PLD 410, such as by comparing a size of the configuration image to a corresponding expected size or checksum, for example. An authentication engine may be configured to validate the configuration image with respect to the secure PLD 410, which may include design version comparisons to rollback protection rulesets and/or other configuration images, functionality comparisons, serial number, device ID, and/or other comparisons, for example. In such embodiments, the authentication engine may be configured to provide a pass result when all such checks are passed, for example, and to provide a fail result when any of such checks fail. In general, such design version comparisons and/or validation may be performed by an authentication engine or may be performed as part of a pre-authentication process (page 13, paragraph [0100])).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Chandra teachings in the Agrawal in view of Rudraprakash and Luciani system. Skilled artisan would have been motivated to incorporate the method of using manufacturer or customer private/public key pairs as taught by Chandra in the Agrawal in view of Rudraprakash and Luciani system for effectively authenticating configuration information. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
NPL1 proposes a system that attempts to accurately identify vulnerabilities in embedded firmware. Specifically, it discloses that due to limited write cycles on primary storage device, many firmware images mount a temporary memory-backed filesystem at boot for volatile data. This filesystem is mounted and generated dynamically. As a result, the directories /dev/ and /etc/ may be symbolic links to subdirectories within the temporary filesystem, thus appearing broken when examined statically (page marked 4, left column, lines 17 – 20). Fortunately, ELF dynamic loaders for Linux systems support lazy linking, which allows the resolution of external function symbols to be delayed until usage (page marked 7, left column, lines 10 – 12). Since the ELF loader uses a global symbol lookup scope during resolution, we were able to compile our NVRAM library with the -nostdlib compiler flag, delaying resolution of external symbols until after the calling process had already loaded the system C runtime library (page marked 7, left column, lines 17 – 21). Symbol resolution is the process of converting symbolic names for functions and variables into the actual memory addresses where they are located.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the NPL1 teachings in the Agrawal in view of Rudraprakash, Luciani and Chandra system. Skilled artisan would have been motivated to incorporate the method of symbol resolution as taught by NPL1 in the Agrawal in view of Rudraprakash, Luciani and Chandra system for effectively converting human readable code into computer readable addresses and code. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Xie discloses a secure firmware update patch release process. Specifically, a method is disclosed for performing hardware verification testing of a firmware update patch. The method includes receiving the firmware update patch. The firmware update patch includes code for modifying firmware and a platform signature. The platform signature was generated using a platform private key. The firmware includes a standard mode and a test mode. The method further includes enabling the test mode of the firmware in a setup menu of the firmware. The method further includes authenticating, while the firmware operates in the test mode, the firmware update patch using a platform public key and the platform signature. The platform signature is not sufficient to authenticate the firmware update patch when the firmware operates in the standard mode. The method further includes modifying the firmware based on the firmware update patch to generate modified firmware. The method further includes performing the hardware verification testing on the modified firmware (page 1, paragraph [0018]). A variety of methods exist for a computing device to authenticate code before allowing the code to execute on the computing device. One way to protect the computing device from unauthorized code is through signing. Signing is a method for verifying that a package is authentic (i.e., is what it purports to be or comes from a trusted source) and has integrity (i.e., has not been changed). Signing may involve the use of two keys or certificates. The first key may be a private key that is not shared publicly. Access to the private key may be limited and strictly controlled. The private key may be used to generate a signature that is added to a firmware update patch. In some cases, a developer of the firmware update patch may possess the private key and may sign the firmware update patch using the private key. In other cases, an operator of a system on which the firmware update patch is to be installed may possess the private key and sign the firmware update patch using the private key. In other cases, a manufacturer of hardware managed by firmware that is to be updated with the firmware update patch may possess the private key and sign the firmware update patch using the private key (page 3, paragraph [0040]). The patch 320 may be a firmware update patch (such as the test patch 120 or the test capsule 220). The patch 320 may include code (which may be included in a payload such as the payload 206b) for modifying the firmware 316. A developer (such as the developer 102) may have created the code and built the code for inclusion in the patch 320. The patch 320 may include a platform public key 310a and a platform signature 322a. A computing system operator (such as the computing system operator 150) may have added the platform public key 310a and the platform signature 322a to the patch 320 without re-building or modifying the code (page 7, paragraph [0082]). Data, such as the firmware data, is conventionally stored at addresses of the memory devices in which they are stored.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Xie teachings in the Agrawal in view of Rudraprakash, Luciani, Chandra, and NPL1 system. Skilled artisan would have been motivated to incorporate the method of providing a firmware update patch signed by a private key as taught by Xie in the Agrawal in view of Rudraprakash, Luciani, Chandra, and NPL1 system for effectively authenticating a firmware patch for modifying existing firmware. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as firmware authentication. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 20, Agrawal in view of Rudraprakash, Luciani, Chandra, NPL1, and Xie describe the storage controller of claim 17 (see above), wherein the second processor is configured to execute a patch code included in the module according to the code corresponding to the target address in response to the code patch operation being performed (The patch 320 may be a firmware update patch (such as the test patch 120 or the test capsule 220). The patch 320 may include code (which may be included in a payload such as the payload 206b) for modifying the firmware 316. A developer (such as the developer 102) may have created the code and built the code for inclusion in the patch 320. The patch 320 may include a platform public key 310a and a platform signature 322a. A computing system operator (such as the computing system operator 150) may have added the platform public key 310a and the platform signature 322a to the patch 320 without re-building or modifying the code (Xie, page 7, paragraph [0082]). Data, such as the firmware data, is conventionally stored at addresses of the memory devices in which they are stored).
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal in view of Rudraprakash, Luciani, Chandra, NPL1, and Xie, further in view of Henry et al. US Patent Application Publication No. 2015/0067369 (herein after referred to as Henry).
Regarding claim 18, Agrawal in view of Rudraprakash, Luciani, Chandra, NPL1, and Xie describe the storage controller of claim 17 (see above). Xie discloses the patch 320 may include code (which may be included in a payload such as the payload 206b) for modifying the firmware 316 (Xie, page 7, paragraph [0082]). NPL1 describe that since the ELF loader uses a global symbol lookup scope during resolution, we were able to compile our NVRAM library with the -nostdlib compiler flag, delaying resolution of external symbols until after the calling process had already loaded the system C runtime library (NPL1, page marked 7, left column, lines 17 – 21). Symbol resolution is the process of converting symbolic names for functions and variables into the actual memory addresses where they are located. They do not explicitly disclose wherein the symbol resolution module is configured to set a patch flag indicating that a patch operation is being performed.
Henry describes that portions of a microcode patch 2500 are loaded from system memory and/or from a non-volatile system, such as from a ROM or FLASH memory that holds a system BIOS or extensible firmware, for example. The header 2502 describes each portion of the patch 2500, such as its size, the location in its respective patch-related memory to which the patch portion is to be loaded, and a valid flag that indicates whether or not the portion contains a valid patch that should be applied to the microprocessor 100 (page 26, paragraph [0296]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Henry teachings in the Agrawal in view of Rudraprakash, Luciani, Chandra, NPL1, and Xie system. Skilled artisan would have been motivated to incorporate the method of a flag for indicating whether or not a portion contains a valid patch as taught by NPL1 in the Agrawal in view of Rudraprakash, Luciani, Chandra, NPL1, and Xie system for effectively indicating the existence of a code patch. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as code updates. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 19, Agrawal in view of Rudraprakash, Luciani, Chandra, NPL1, Xie, and Henry describe the storage controller of claim 18 (see above), further comprising: an interrupt controller configured to transmit an interrupt signal to the first processor and the second processor based on the patch flag (…the single core 102 that encounters the apply microcode patch instruction sends messages to and interrupts the other cores 102 to invoke instances of the portion of their microcode that applies the patch… (Henry, page 23, paragraph [0280])).
Response to Arguments
Applicant argues, with respect to the independent claims 1, 12, and 17, that Agrawal does not teach or suggest the newly amended limitations. Specifically, that Agrawal only suggested one element, firmware image 58, that could not teach or suggest the now presented “main firmware” element and “module… wherein the module includes additional codes…” as claimed. Examiner starts by pointing out that the “firmware image” of Agrawal is referred to as an “updated image” (see paragraphs [0039], [0044], and [0046]). This phrasing would lead one of ordinary skill in the art to the conclusion that there is an existing firmware that is being replaced by the updated firmware image. Therefore the existing firmware can suggest the claimed “main firmware” while the updated firmware image may suggest the claimed “module”. Examiner has added the reference Rudraprakash which is believed to more specifically suggest that a firmware update may relate to removing software bugs, adding new features, etc.
The remaining claims depend from the argued independent claims. Examiner refers to rejections and responses above as to why these claims are not currently allowable.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RALPH A VERDERAMO III whose telephone number is (571)270-1174. The examiner can normally be reached Monday through Friday 8:30 AM - 5:00 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, Reginald Bragdon can be reached at (571) 272-4204. 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.
/RALPH A VERDERAMO III/Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
rv
April 30, 2026
Prosecution Insights