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 .
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.
Claim(s) 1, 3-5, 7-19 are rejected under 35 U.S.C. 103 as being unpatentable over KIM et al. (United States Patent Application Publication US 2023/0056827), hereinafter KIM, in view of Batcher et al. (United States Patent Application Publication US 2024/0104520), hereinafter Batcher.
Regarding claim 1, KIM teaches a method for a client device, the method comprising: determining, on a blockchain, a non-fungible token (NFT) specifying a software for the client device, with the client device being set as an owner of the NFT ([0063] “the NFT-based software trading system 300 may include a store server 310, a creator device 301, an owner device 302, and a purchaser device 303.” [0065] “A creator of NFT-based software may be a user to whom ownership of the NFT-based software initially belongs.” [0066] “A purchaser of NFT based software may obtain ownership of the NFT-based software by purchasing the NFT-based software.” [0067] “The owner device 302 may sell the NFT-based software through the store server 310, and the ownership of the NFT-based software may be transferred to a purchaser through the sale and the ownership device 302 may thus be changed.” An NFT of the software is specified for the software. As ownership of the software is transferred, the NFT is used to determine the owner of the software. Thus, the NFT specifies the software being owned by the owner device.).
However, KIM does not explicitly teach a firmware; and verifying an integrity of the firmware based on information included in the NFT.
Batcher further teaches a firmware; and verifying an integrity of the firmware based on information included in the NFT ([0047] “a manufacturing entity or other entity can generate a firmware update for a product produced using industrial automation equipment herein…if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).” When the firmware update, which is interpreted as a firmware, is verified, the condition or quality of the firmware update, which is the integrity of the firmware, is verified. Since, the integrity of the firmware is verified based on the corresponding NFT, the integrity is verified based on the NFT.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teaching of KIM by incorporating the teaching of Batcher of a firmware; and verifying an integrity of the firmware based on information included in the NFT. They are all directed toward security using the blockchain and the NFT. The firmware is well-known in the art before the effective filing date of the claimed invention. Furthermore, the firmware is known to be stable and efficient as the firmware is designed specifically for a component that it runs on. Also, by verifying an integrity of the firmware, the security of the system can be improved. Therefore, it would be advantageous to incorporate the teaching of Batcher of a firmware; and verifying an integrity of the firmware based on information included in the NFT. They are all directed toward security using the blockchain and the NFT in order to improve efficiency and security.
Regarding claim 3, KIM in view of Batcher teaches all the limitation of the method according to claim 1, as discussed above.
KIM, as modified above, further teaches wherein the NFT comprises a hash value or a cryptographic signature of the software ([0085] “Operation 540 may include packaging the NFT-based software by adding a digital signature to the encoded data received from the server. As described above, the digital signature may refer to a signature for authenticating the genuineness of software and may include, for example, a signature of information associated with software encrypted based on a private key of a creator of the NFT-based software.”).
Batcher teaches the firmware and the integrity of the firmware is verified based on the hash value or cryptographic signature in the NFT ([0044] “the NFT 232 can comprise various verification elements herein, associated with the product 242.” [0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element.”).
Regarding claim 4, KIM in view of Batcher teaches all the limitation of the method according to claim 1, as discussed above.
Batcher further teaches wherein the NFT comprises information on a software management device having minted the NFT ([0039] “the minting component 210 can mint an NFT (e.g., NFT 234) associated with a product 244 that is generated using industrial automation equipment herein (e.g., industrial device(s) 120), such as industrial robots, automation devices, conveyors, coating application machines, etc.”) and the integrity of the firmware is verified by verifying an integrity of the firmware management having minted the NFT using the block chain ([0047] “a manufacturing entity or other entity can generate a firmware update for a product produced using industrial automation equipment herein…the firmware component 220 can block installation of a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a non-match of the first aspect of the product 244 to the first verification element and/or a non-match of the second aspect of the product to the second verification element.”).
Regarding claim 5, KIM in view of Batcher teaches all the limitation of the method according to claim 1, as discussed above.
Batcher further teaches wherein the NFT specifies a firmware update, and an integrity of the firmware update is verified prior to installing the firmware update on the client device ([0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element…if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).”).
Regarding claim 7, KIM in view of Batcher teaches all the limitations of the method according to claim 1, as discussed above.
Batcher further requesting the firmware from a firmware management device, wherein the NFT is minted by the firmware management device in response to the request ([0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element…if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).”).
Regarding claim 8, KIM in view of Batcher teaches all the limitations of the method according to claim 7, as discussed above.
KIM, as modified above, further teaches wherein the act of requesting the software update comprises attesting a software management device identification NFT of the software management device using the block chain and providing a client device identification NFT of the client device to the software management device ([0074] “NFT metadata or identification information (e.g., CID) indicating the NFT metadata may be implemented as a block to be stored in a blockchain network along with details of trading NFT-based software.” [0083] “the NFT metadata may include NFT-based software-related and/or owner-related information, such as, identification information indicating the NFT-based software and identification information indicating an owner of the NFT-based software.”).
Batcher teaches the firmware ([0044] “the NFT 232 can comprise various verification elements herein, associated with the product 242.” [0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element.”).
Regarding claim 9, KIM in view of Batcher teaches all the limitations of the method according to claim 1, as discussed above.
Batcher further teaches wherein the NFT specifies a firmware update, the method comprising obtaining the firmware update specified by the NFT and installing the firmware update on the client device ([0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element…if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).” The firmware download for the firmware update is based on the NFT. Furthermore, the firmware update is installed.).
Regarding claim 10, KIM in view of Batcher teaches all the limitations of the method according to claim 9, as discussed above.
Batcher further teaches a first level firmware for managing at least one of a blockchain-based firmware update process ([0044] “the blockchain component 212 can store the NFT 232 to an industrial blockchain 226” [0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element.” A firmware component installs a firmware update, which is interpreted as managing the firmware update process. The firmware update is based on the NFT, which is stored in the industrial blockchain.) and
a blockchain-based firmware verification process, with the firmware update being installed as a second level firmware in addition to the first-level firmware ([0044] “the blockchain component 212 can store the NFT 232 to an industrial blockchain 226. In other embodiments, the minting component 210 can directly store the NFT 232 to the industrial blockchain 226.” [0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element…if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).” The firmware update is verified by the verification component based on the NFT stored in the blockchain.).
Regarding claim 11, Kim in view of Batcher teaches all the limitations of the processor circuitry to execute the machine-readable instructions to perform the method according to claim 1.
KIM further teaches the apparatus comprising: an interface for communicating with a blockchain ([0062] “The NFT-based software trading system 300 may issue the NFT corresponding to the software and enable anyone to verify an owner of the software through a blockchain or the like.”); machine-readable instructions ([0049] “Various example embodiments set forth herein may be implemented as software (e.g., the program 140) including one or more instructions that are stored in a storage medium”).
Regarding claim 12, KIM in view of Batcher teaches all the limitations of a non-transitory machine-readable storage medium including program code, when executed, to cause a machine to perform the method according to claim 1 or the method according to claim 11, as discussed above. KIM further teaches an interface for communicating with a blockchain ([0062] “The NFT-based software trading system 300 may issue the NFT corresponding to the software and enable anyone to verify an owner of the software through a blockchain or the like.”); machine-readable instructions ([0049] “Various example embodiments set forth herein may be implemented as software (e.g., the program 140) including one or more instructions that are stored in a storage medium”).
Regarding claim 13, KIM teaches obtaining one or more client device identification Non-Fungible Tokens (NFTs) of one or more client devices; and transferring ownership of the one or more NFTs specifying a software to the one or more client devices based on an identity of the one or more client devices included in the one or more client device identification NFTs ([0062] “an NFT based software trading system 300 may verify ownership of software to which an NFT is issued (hereinafter simply referred to as an NFT-based software or NFT-based SW), and enable trading between consumers. The NFT-based software trading system 300 may issue the NFT corresponding to the software and enable anyone to verify an owner of the software through a blockchain or the like.” [0086] “The NFT-based software packaged in operation 540 may be transmitted to the server, and the server may publish the received NFT-based software on a store platform for trading the NFT-based software. A user using the store platform of the server may purchase the NFT-based software published on the platform through a device (e.g., the purchaser device 303 of FIG. 3), and the device of such a purchaser may store and run the NFT-based software.” A NFT is to verify an ownership of a software through a blockchain. Then, the software is packaged, generated, and transmitted to a server and other devices, which are steps of managing the software. Furthermore, as discussed above, the software, which is managed, is based on the NFT.).
Batcher teaches a firmware and minting one or more NFTs specifying the firmware on a blockchain ([0039] “the minting component 210 can mint a unique instance of the NFT 234 for a unique instance of the product 244. In various embodiments, the NFT 232 can comprise a plurality of verification elements such as a first verification element (e.g., verification element 238) and a second verification element (e.g., verification element 240), different from the first verification element.” [0044] “the blockchain component 212 can store the NFT 232 to an industrial blockchain 226. In other embodiments, the minting component 210 can directly store the NFT 232 to the industrial blockchain 226.” [0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element.” The NFTs are minted and stored in the blockchain, which is used for the firmware updates.).
Regarding claim 14, KIM in view of Batcher teaches all the limitations of the method according to claim 13, as discussed above.
Batcher further teaches wherein a separate NFT is minted for each of the one or more client devices ([0047] “if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).” The NFT is minted for a unique instance of the NFT for verification in [0039]. Also, as the NFT is minted for a legitimate customer, KIM suggests that the NFT is minted to identify and authenticate a particular user. Thus, KIM suggests that a separate NFT is minted for each or the legitimate customer.).
Regarding claim 15, KIM in view of Batcher teaches all the limitations of the method according to claim 13, as discussed above.
Batcher teaches wherein at least one of a hash value of the firmware, a crypto graphic signature of the firmware or information on the firmware management device having minted the NFT is included in the one or more NFTs specifying the firmware ([0047] “if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).” [0047] “the firmware component 220 can block installation of a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a non-match of the first aspect of the product 244 to the first verification element and/or a non-match of the second aspect of the product to the second verification element…if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).”).
Regarding claim 16, KIM in view of Batcher teaches all the limitations of the method according to claim 13, as discussed above.
Batcher further teaches obtaining one or more requests for the firmware from the one or more client devices, wherein the one or more NFTs are minted in response to the one or more requests ([0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element…if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).”).
Regarding claim 17, KIM in view of Batcher teaches all the limitations of the method according to claim 13, as discussed above.
Batcher further teaches wherein the method comprises, for provisioning a client device for future firmware updates, obtaining information on a first-level firmware from the client device to be provisioned, minting a client device identification NFT for the client device to be provisioned based on the information on the first-level firmware, the client device to be provisioned being set as owner of the client device identification NFT, and providing the client device identification NFT to the client device to be provisioned ([0047] “the firmware component 220 can install a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a match of the first aspect of the product 244 to the first verification element and/or the second aspect of the product 244 to the second verification element. Further, the firmware component 220 can block installation of a firmware update to the product 244 in response to the comparison by the verification component 216 resulting in a non-match of the first aspect of the product 244 to the first verification element and/or a non-match of the second aspect of the product to the second verification element...if a user is a legitimate customer, the user can be issued a customer-based token (e.g., an NFT minted by the minting component 210) that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT).” For the firmware update, the verification component perform verification process based on the NFT. Furthermore, the user is also verified during the verification process. Then, after the verification, the NFT is minted by the minting component, which is utilized to authenticate a firmware download subsequent to the generation of the corresponding NFT.).
Regarding claim 18, KIM in view of Batcher teaches all the limitations of an apparatus for a firmware management device, the apparatus comprising: processor circuitry to execute the machine-readable instructions to perform the method according to claim 13, as discussed above. KIM further teaches an interface for communicating with a blockchain; machine-readable instructions. KIM further teaches an interface for communicating with a blockchain ([0062] “The NFT-based software trading system 300 may issue the NFT corresponding to the software and enable anyone to verify an owner of the software through a blockchain or the like.”); machine-readable instructions ([0049] “Various example embodiments set forth herein may be implemented as software (e.g., the program 140) including one or more instructions that are stored in a storage medium”).
Regarding claim 19, KIM in view of Batcher teaches all the limitations of a non-transitory machine-readable storage medium including program code, when executed, to cause a machine to perform the method according to claim 13, as discussed above.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of Batcher as applied to claim 2 above, and further in view of Grover et al. (United States Patent Application Publication US 2022/0417026), hereinafter Grover.
Regarding claim 6, KIM in view of Batcher teaches all the limitations of the method according to claim 1, as discussed above.
However, KIM in view of Batcher does not teach wherein the integrity of the firmware is verified as part of a boot process of the client device.
Grover teaches wherein the integrity of the firmware is verified as part of a boot process of the client device ([0032] “The loader 106 can be any software/firmware that can load the operating system 105, the application(s) 107, the libraries 108, the container(s) 109, and/or the virtual machines 110.” [0069] “When the system boots up with the boot firmware 103, the boot firmware 103 goes to the blockchain 121 (the genesis block 200) and verifies that the hashes of the blockchain 121 are valid. If valid, the loader 106 is loaded into the memory 104 and is then executed.” A loader is verified by a hash of a blockchain when the system boots up. The loader includes firmware.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teaching of KIM in view of Batcher by incorporating the teaching of Grover of verifying the integrity of the firmware as part of a boot process. They are all directed toward security using a blockchain. As recognized by Grover, malware attacks/security breaches can occur when the software/configuration information is changed by malicious code ([0002]). Thus, by ensuring that a software system that is being loaded has not been comprised or damaged, including a booting process to load various software and firmware, the security of the system can be improved. Therefore, it would be advantageous to incorporate teaching of Grover of verifying the integrity of the firmware as part of a boot process in order to improve the security of the system.
Allowable Subject Matter
Claim 20 is allowed.
The following is an examiner’s statement of reasons for allowance:
KIM teaches a store server that relays a generation and sale of NFT-based software and issue an NFT corresponding to software. KIM further teaches, using the NFT, transfer of ownership of the NFT-based software from a creator to a purchaser. However, KIM does not teach “load a first level firmware for managing at least one of a blockchain-based firmware update process and a blockchain-based firmware verification process, wherein the first level firmware is unmodifiable and used as part of an identification of the client device” and “wherein a non-fungible token (NFT) is minted for the first level firmware and used to represent the client device, and a separate NFT is minted for the second level firmware.”
Batcher teaches to authenticate a firmware update generated by a manufacturing entity or other entity using an NFT. However, Batcher does not teach “load a first level firmware for managing at least one of a blockchain-based firmware update process and a blockchain-based firmware verification process, wherein the first level firmware is unmodifiable and used as part of an identification of the client device” and “wherein a non-fungible token (NFT) is minted for the first level firmware and used to represent the client device, and a separate NFT is minted for the second level firmware.”
Smith et al. (United States Patent Application Publication US 2024/0319979) teaches enabling derivation and distribution of an attestation manifest for a software update image. However, Smith does not teach “load a first level firmware for managing at least one of a blockchain-based firmware update process and a blockchain-based firmware verification process, wherein the first level firmware is unmodifiable and used as part of an identification of the client device” and “wherein a non-fungible token (NFT) is minted for the first level firmware and used to represent the client device, and a separate NFT is minted for the second level firmware.”
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Response to Arguments
Applicant’s arguments, see Remarks, filed 8/26/2026, with respect to “Claim Rejections – 35 USC §112” have been fully considered and are persuasive. The rejection of claims 1-19 under 35 U.S.C. § 112(b) and 35 U.S.C. § 112(d) has been withdrawn.
Applicant’s arguments, see Remarks, filed 8/26/2026, with respect to “Claim Rejections – 35 USC §102” have been fully considered and are persuasive. The rejection of claim 20 under 35 U.S.C. § 102 has been withdrawn.
Applicant’s arguments, see Remarks, filed 8/26/2026, with respect to the rejection(s) of claim(s) 1, 3-5, 7-19 under 35 U.S.C. § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Batcher. Batcher teaches that “a manufacturing entity or other entity can generate a firmware update for a product produced using industrial automation equipment herein” in [0047]. Batcher further teaches verification of the firmware update using an NFT minted by the minting component that can be utilized to authenticate a firmware download (e.g., a future firmware download, subsequent to the generation of the corresponding NFT) in [0047].
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 HYUN SOO KIM whose telephone number is (571)270-1768. The examiner can normally be reached Monday - Friday 8:30 am - 5:30 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, Jaweed Abbaszadeh can be reached at (571)270-1640. 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.
/HYUN SOO KIM/Examiner, Art Unit 2176
