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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09 June 2026 has been entered.
Response to Amendment
Applicant’s amendment filed 09 June 2026 amends claims 1 and 11. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on page 9 of the response, “It is submitted that none of the applied publications teaches or suggest the combination of features recited in amended claim 1, including generating a first signature based on a private key and a data set that comprises physical unclonable function (PUF) data that is unique to the semiconductor die.” This argument has been fully considered and is persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Sachdev, U.S. Publication No. 2019/0044739.
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.
Claims 1-4, 6, 8-14, 16-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Landman, U.S. Publication No. 2022/0164452, in view of Sachdev, U.S. Publication No. 2019/0044739, in view of Cossel, WO 2021/145872, and further in view of Sanders, U.S. Patent No. 9,165,143. Referring to claim 1, Landman discloses a software validation system that includes a server with a memory 210/314 ([0055]), which meets the limitation of [a semiconductor die] comprising non-volatile memory. The server includes a processor 250 implemented by one or more modules ([0061]) that can be hardware circuits/semiconductors ([0030]), which meets the limitation of self-authenticating circuitry. The server generates a public key 326 and private key 328 ([0082]), which meets the limitation of generate a public-private key pair comprising a public key and a private key. The server digitally signs a data component using private key 328 ([0083]: data component reads on the claimed data set) wherein the data component includes information from software development operations performed on the server ([0039] & [0059]: data component would be considered to be unique to the server since the development process is performed on the server), which meets the limitation of generate a first signature based on the private key and a data set that is unique [to the semiconductor die]. The server stores the generated digital signatures in a data structure 332 ([0086]) of memory (Figure 3), which meets the limitation of store [the first hash code] and the first signature in the non-volatile memory [of the semiconductor die]. The data component, the digital signature is stored in secure data structure 332 ([0087]) and externally transferred, along with the public key, to a public database ([0089]: public database could read on the claimed external device) and a node device 470 ([0124]: node device 470 also read on the claimed external device), which meets the limitation of export the data set, the first signature, and the public key to an external storage device.
Landman discloses that the data component is stored in memory 314 ([0073]), but Landman does not disclose that the processor 312 and memory 314 are implemented on the same semiconductor die with a physical unclonable function (PUF). Sachdev discloses a processor and memory implemented on the same semiconductor die (Figure 9, element 178 & [0044]-[0045]: semiconductor die 178 includes processor 170 and IO module 176 that communicates with non-volatile memory 168; IO module 176 includes logic to implement a strong PUF; data retrieved by the IO module 176 from non-volatile memory 168 would be considered PUF data as claimed), which meets the limitation of a semiconductor die comprising primary circuitry configured to perform a primary function and self-authenticating circuitry, a data set that comprises physical unclonable function (PUF) data that is unique to the semiconductor die, non-volatile memory of the semiconductor die. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have been implemented such that processor 312 and memory 314 are included on a single semiconductor die because Sachdev discloses that such an implementation is one of a finite number of possible embodiments that could have been implemented by one of ordinary skill in the art with a reasonable expectation of success. Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for this semiconductor die to include a PUF as shown in Sachdev in order to provide authentication benefits as discussed in Sachdev ([0020]).
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210 that created the signature. Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of semiconductor die comprises self-authenticating circuitry configured to import the data set, the first signature, and the public key from the external storage device, and to authenticate the imported data set, on the semiconductor die, based on the imported public key imported from the external storage device, [the first hash code stored in the non-volatile memory] of the semiconductor die, and the first signature stored in the non-volatile memory of the semiconductor die. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a public key hash stored in local memory (Col. 18, lines 30-44), which meets the limitation of the self-authenticating circuitry is configured to generate a first hash code based on the public key, store the first hash code in the non-volatile memory, authenticate…based on...the first hash code stored in the non-volatile memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Referring to claim 2, Landman discloses that the server includes a processor 250 implemented by one or more modules ([0061]) that can be hardware circuits/semiconductors ([0030]). The server digitally signs a data component using private key 328 ([0083]), which meets the limitation of signature generating logic. Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a public key hash stored in local memory (Col. 18, lines 30-44), which meets the limitation of the hash logic. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman does not specify that the processor 312 and memory 314 are implemented on the same semiconductor die. Sachdev discloses a processor and memory implemented on the same semiconductor die (Figure 9, element 178 & [0044]-[0045], which meets the limitation wherein the self-authenticating circuit comprises export circuitry and import circuitry configured to share hash logic and signature generating logic of the semiconductor die. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have been implemented such that processor 312 and memory 314 are included on a single semiconductor die because Sachdev discloses that such an implementation is one of a finite number of possible embodiments that could have been implemented by one of ordinary skill in the art with a reasonable expectation of success.
Referring to claims 3, 4, Landman discloses that the generation of validation signatures using the public key ([0093]) and comparing the generated validation signatures with the stored signatures ([0092]), which meets the limitation of generate a second signature based on the imported data set and the imported public key, compare the second signature to the first signature stored in the non-volatile memory, authenticate the imported data set if [the first and second hash codes match and] the first and second signature match.
Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a public key hash stored in local memory (Col. 18, lines 30-44), which meets the limitation of generate a second hash code based on the imported public key, compare the second hash code to the first code stored in the non-volatile memory, authenticate the imported data set if the first and second hash codes match, invalidate the imported data set if the second hash code does not match the first hash code stored in the non-volatile memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210 that created the signature. Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of wherein the self-authenticating circuitry is further configured to. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Referring to claim 6, Landman discloses that the digital signature is stored in secure data structure ([0087]) and the server encrypts the secure data structure, the data components, and the public key for transmission to the database ([0089]) and node device 360/470 ([0124]), which meets the limitation of wherein the self-authenticating circuitry is further configured to encrypt the data set to provide an encrypted data set, and export the encrypted data set, the first signature, and the public key to the external device.
Referring to claim 8, Landman discloses that the server digitally signs a data component using private key 328 ([0083]), which meets the limitation of the self-authenticating circuitry is further configured to generate the first signature based on a cryptographic signing method.
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210 that created the signature. Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of the self-authenticating circuitry is further configured to authenticate the imported data set based on a validation process of the cryptographic signing method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel: [0025]).
Referring to claim 9, Landman discloses that the data components are utilized to validate the files of a software release ([0100]-[0102]: data components are part of the software release and would the data components usage for validating that software release would be considered a built-in self-test), which meets the limitation of wherein the primary circuitry is further configured to use the authenticated imported data set for a built-in self-test.
Referring to claim 10, Landman discloses that node 360 can access the database and retrieves validation information 352 that includes the data components, public key 326 and secure data structure 332 ([0089]: secure data structure 332 includes the signatures [0087]). Validator 363 of node 360 validates the digital signatures of the data components in the secure data structure 332 by signing each piece of data using public key 326 to create validation signatures 366 and comparing the generated validation signatures 366 to the signatures stored in the secure data structure ([0092]-[0094]), which meets the limitation of [the self-authenticating circuitry is further configured to] validate the first signature based on the public key to provide validated first signature. The digital signature is stored in secure data structure ([0087]) and the server encrypts the secure data structure, the data components, and the public key for transmission to the node device 470 ([0124]), which meets the limitation of wherein the self-authenticating circuitry is further configured to export the data set, the [validated] first signature, and the public key to the external device
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210. Cossel discloses that the server can verify software package signatures for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of the self-authenticating circuitry is configured to validate the first signature based on public key to provide a validated first signature, the validated first signature. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Referring to claim 11, Landman discloses a software validation system that includes a server with a memory 210/314 ([0055]). The server includes a processor 250 implemented by one or more modules ([0061]) that can be hardware circuits/semiconductors ([0030]), which meets the limitation of export circuitry [and import circuitry]. The server generates a public key 326 and private key 328 ([0082]), which meets the limitation of generating a public-private key pair comprising a public key and a private key, by the export circuitry. The server digitally signs a data component using private key 328 ([0083]: data component reads on the claimed data set) wherein the data component includes information from software development operations performed on the server ([0039] & [0059]: data component would be considered to be unique to the server since the development process is performed on the server), which meets the limitation of generating a first signature based on the private key and a data set that is unique to [the semiconductor device]. The server stores the generated digital signatures in a data structure 332 ([0086]) of memory (Figure 3), which meets the limitation of storing [the first hash code] and the first signature in the non-volatile memory [of the semiconductor die]. The data component, the digital signature is stored in secure data structure 332 ([0087]) and externally transferred, along with the public key, to a public database ([0089]: public database could read on the claimed external device) and a node device 360/470 ([0090] & [0124] node device 470 also read on the claimed external device), which meets the limitation of exporting the data set, the first signature, and the public key to an external storage device, by the export circuitry.
Landman discloses that the data component is stored in memory 314 ([0073]), but Landman does not disclose that the processor 312 and memory 314 are implemented on the same semiconductor die with a physical unclonable function (PUF). Sachdev discloses a processor and memory implemented on the same semiconductor die (Figure 9, element 178 & [0044]-[0045]: semiconductor die 178 includes processor 170 and IO module 176 that communicates with non-volatile memory 168; IO module 176 includes logic to implement a strong PUF; data retrieved by the IO module 176 from non-volatile memory 168 would be considered PUF data as claimed), which meets the limitation of export self-authenticating circuitry of a semiconductor die, non-volatile memory of the semiconductor die, a data set that comprises physical unclonable function (PUF) data that is unique to the semiconductor device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have been implemented such that processor 250 and memory 210 are included on a single semiconductor die because Sachdev discloses that such an implementation is one of a finite number of possible embodiments that could have been implemented by one of ordinary skill in the art with a reasonable expectation of success. Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for this semiconductor die to include a PUF as shown in Sachdev in order to provide authentication benefits as discussed in Sachdev ([0020]).
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210 that created the signature. Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of import circuitry of the semiconductor die, importing the data set, the first signature, and the public key from the external storage device, by the import circuitry of the semiconductor die, and authenticating the imported data set on the semiconductor die, based on the imported public key, [the first hash code stored in the non-volatile memory] of the semiconductor die, and the first signature stored in the non-volatile memory of the semiconductor die. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a public key hash stored in local memory (Col. 18, lines 30-44), which meets the limitation of the generating a first hash code based on the public key, by the export circuitry, storing the first hash code in the non-volatile memory, authenticating…based on...the first hash code stored in the non-volatile memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Referring to claim 12, Landman discloses that the server includes a processor 250 implemented by one or more modules ([0061]) that can be hardware circuits/semiconductors ([0030]). The server digitally signs a data component using private key 328 ([0083]), which meets the limitation of signature generating logic. Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a public key hash stored in local memory (Col. 18, lines 30-44), which meets the limitation of the hash logic. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman discloses that the data component is stored in memory 314 ([0073]), but Landman does not disclose that the processor 312 and memory 314 are implemented on the same semiconductor die with a physical unclonable function (PUF). Sachdev discloses a processor and memory implemented on the same semiconductor die (Figure 9, element 178 & [0044]-[0045]), which meets the limitation of sharing hash logic and signature generating logic of the semiconductor die by the export circuitry and the import circuitry. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have been implemented such that processor 250 and memory 210 are included on a single semiconductor die because Sachdev discloses that such an implementation is one of a finite number of possible embodiments that could have been implemented by one of ordinary skill in the art with a reasonable expectation of success.
Referring to claim 13, Landman discloses that the generation of validation signatures using the public key ([0093]) and comparing the generated validation signatures with the stored signatures ([0092]), which meets the limitation of generating a second signature based on the imported data set and the imported public key, comparing the second signature to the first signature stored in the non-volatile memory, authenticating the imported data set if [the first and second hash codes match and] the first and second signature match.
Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a public key hash stored in local memory (Col. 18, lines 30-44), which meets the limitation of generating a second hash code based on the imported public key, comparing the second hash code to the first code stored in the non-volatile memory, authenticating the imported data set if the first and second hash codes match, invalidating the imported data set if the second hash code does not match the first hash code stored in the non-volatile memory, [by the import circuitry]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210 that created the signature. Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of invalidating by the import circuitry. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Referring to claim 14, Landman discloses that the data components are utilized to validate the files of a software release ([0100]-[0102]: data components are part of the software release and would the data components usage for validating that software release would be considered a built-in self-test), which meets the limitation of using the authenticated imported data set for a built-in self-test.
Referring to claim 16, Landman discloses that the digital signature is stored in secure data structure ([0087]) and the server encrypts the secure data structure, the data components, and the public key for transmission to the database ([0089]) and node device 360/470 ([0124]), which meets the limitation of encrypting the data set, by the export circuitry, to provide an encrypted data set, wherein the exporting comprises exporting the encrypted data set, the first signature, and the public key to the external device.
Referring to claim 17, Sanders discloses hashing a received public key and comparing the hash to a public key hash stored in local memory (Col. 18, lines 30-44), which meets the limitation of invalidating the imported data set, [by the import circuitry], if the second hash code does not match the first hash code stored in the non-volatile memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210 that created the signature. Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of by the import circuitry. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Referring to claim 18, Landman discloses that the server digitally signs a data component using private key 328 ([0083]), which meets the limitation of generating the signature by the export circuitry based on a cryptographic signing method.
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210 that created the signature. Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of the authenticating comprises authenticating the imported data set based on a validation process of the cryptographic signing method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Referring to claim 20, Landman discloses that node 360 can access the database and retrieves validation information 352 that includes the data components, public key 326 and secure data structure 332 ([0089]: secure data structure 332 includes the signatures [0087]). Validator 363 of node 360 validates the digital signatures of the data components in the secure data structure 332 by signing each piece of data using public key 326 to create validation signatures 366 and comparing the generated validation signatures 366 to the signatures stored in the secure data structure ([0092]-[0094]), which meets the limitation of validating the first signature based on the public key to provide validated first signature, [by the export circuitry]. The digital signature is stored in secure data structure ([0087]) and the server encrypts the secure data structure, the data components, and the public key for transmission to the node device 470 ([0124]), which meets the limitation of wherein the exporting comprises exporting the data set, the [validated] first signature, and the public key to the external device
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210. Cossel discloses that the server can verify software package signatures for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of validating the first signature based on public key to provide a validated first signature, by the export circuitry, the validated first signature. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Claims 5, 7, 15, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Landman, U.S. Publication No. 2022/0164452, in view of Sachdev, U.S. Publication No. 2019/0044739, in view of Cossel, WO 2021/145872, in view of Sanders, U.S. Patent No. 9,165,143, and further in view of Yang, U.S. Publication No. 2004/0109567. Referring to claim 5, Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a locally stored public key hash (Col. 18, lines 30-44 & Col. 29, lines 59-67), which meets the limitation of wherein the self-authenticating circuitry is further configured to indicate in the non-volatile memory whether the first hash code stored in the non-volatile memory is valid or invalid. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman, in view of Sanders, does not suggest generating a new public/private key pair when the public key is determined to be invalid. Yang discloses the generation of a new public/private key pair when a public key has been determined to be invalid ([0070]), which meets the limitation of generate a new public-private key pair if the first hash code stored in the non-volatile memory is indicated as invalid in the non-volatile memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the software validation system of Landman to have generated new public/private key pairs when the public key is determined to be invalid in order to ensure that the system utilizes valid keys as suggested by Yang ([0070]).
Referring to claim 7, Sanders discloses hashing a received public key and comparing the hash to a locally stored public key hash (Col. 18, lines 30-44 & Col. 29, lines 59-67), which meets the limitation of [the self-authenticating circuitry is further configured to] invalidate the imported data set if the second hash code does not match the first hash code stored in the non-volatile memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman does not suggest generating a new public/private key pair when the public key is determined to be invalid. Yang discloses the generation of a new public/private key pair when a public key has been determined to be invalid ([0070]: replacing invalid keys with new keys shows an “indication” of validity), which meets the limitation of [the self-authenticating circuitry is further configured to] indicate in the non-volatile memory whether the first hash code stored in the non-volatile memory is valid or invalid. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the software validation system of Landman to have generated new public/private key pairs when the public key is determined to be invalid in order to ensure that the system utilizes valid keys as suggested by Yang ([0070]).
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210. Cossel discloses that the server can verify software package signatures for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of the self-authenticating circuitry is further configured to indicate in the non-volatile memory whether the first hash code stored in the non-volatile memory is valid or invalid, the self-authenticating circuitry is further configured to invalidate the imported data set. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Referring to claim 15, Landman discloses that the server stores the public key 326 in the memory ([0082]). However, Landman does not disclose that the verification procedure includes a verification of the public key prior to generating the validation signatures 366.
Sanders discloses hashing a received public key and comparing the hash to a locally stored public key hash (Col. 18, lines 30-44 & Col. 29, lines 59-67), which meets the limitation of indicating in the non-volatile memory whether the first hash code stored in the non-volatile memory is valid or invalid, by the export circuitry. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server of Landman to have additionally stored public key hashes in memory and compared the stored public key hash to the hash of a received public key in order to provide a means of verifying the public keys as suggested by Sanders (Col. 29, lines 59-67).
Landman, in view of Sanders, does not suggest generating a new public/private key pair when the public key is determined to be invalid. Yang discloses the generation of a new public/private key pair when a public key has been determined to be invalid ([0070]), which meets the limitation of generating a new public-private key pair by the export circuitry if the first hash code stored in the non-volatile memory is indicated as invalid in the non-volatile memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the software validation system of Landman to have generated new public/private key pairs when the public key is determined to be invalid in order to ensure that the system utilizes valid keys as suggested by Yang ([0070]).
Referring to claim 19, Landman discloses that node 360 can access the database and retrieves validation information 352 that includes the data components, public key 326 and secure data structure 332 ([0089]: secure data structure 332 includes the signatures [0087]). Validator 363 of node 360 validates the digital signatures of the data components in the secure data structure 332 by signing each piece of data using public key 326 to create validation signatures 366 and comparing the generated validation signatures 366 to the signatures stored in the secure data structure ([0092]-[0094]). If validation fails, a notification is transmitted ([0096]), which meets the limitation of signaling that the imported data set is invalid, [by the import circuitry, if the first hash code stored in the non-volatile memory] is indicated as an invalid in the non-volatile memory.
Landman does not suggest generating a new public/private key pair when the public key is determined to be invalid. Yang discloses the generation of a new public/private key pair when a public key has been determined to be invalid ([0070]: replacing invalid keys with new keys shows an “indication” of validity), which meets the limitation of indicating in the non-volatile memory whether the first hash code stored in the non-volatile memory is valid or invalid. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the software validation system of Landman to have generated new public/private key pairs when the public key is determined to be invalid in order to ensure that the system utilizes valid keys as suggested by Yang ([0070]).
Landman discloses that the verification procedure is performed in node 360 and Landman does not specify that the verification procedures are performed in server 210. Cossel discloses that the server can verify software package signatures for another device ([0025]: as applied to Landman, if software verification is performed on server 210, the validator element would be implemented on server 210 and would be part of the semiconductor die since the validator element is described as being part of the processor as shown in figure 3, element 363), which meets the limitation of indicating in the non-volatile memory whether the first hash code stored in the non-volatile memory is valid or invalid, by the export circuitry, signaling that the imported data set is invalid, by the import circuitry. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the server 210 of Landman to have performed software release validation procedures of behalf of node device 360 because Cossel suggests that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented by one of ordinary skill in the art to perform the validation with a reasonable expectation of success (Cossel ([0025]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 5:30-4:00.
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, Alexander Lagor can be reached at 5712705143. 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.
/BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437
Prosecution Insights