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 .
Response to Amendment
Applicant’s amendment filed 17 February 2026 amends claims 1, 7, 9, 11, 14, and 19. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on page 9 of the response, “The Office Action mistakenly asserts that the data components of Landman are unique to a semiconductor die. In fact, the data components of Landman are based on development stages of the software and are thus not unique to a semiconductor die or to the server of Landman. This argument is not persuasive because Landman discloses that the data component would be considered to be unique to the server since the development process is performed on the server ([0039] & [0059]).
Applicant argues on page 10 of the response, “The Office Action provides no reasons why one skill in the art would be motivated to combine the applied references to provide a server that validates ‘that a software release has been successfully completed multiple development stages of a development process without alteration”…on behalf of nodes.” This argument is not persuasive because page 9 of the Non-Final rejection mailed 14 November 2026 (“Non-Final”) specified that “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]).”
Applicant argues on page 10 of the response, “Cossel, paragraph [0025], clearly does not support the assertion ‘that the server performing the software validation procedures represents one of a finite number of possible devices that could have implemented.’” This argument is not persuasive because Cossel discloses that a server that generates cryptographic signature ([0023]) and that the same server can verify the signature for another device ([0025]). This disclosure clearly shows that 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]), where the finite number of possible devices is representative of all device having access to the public key used to validate the digital signature.
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 Sharma, U.S. Publication No. 2023/0418604, 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 that comprising export circuitry [and import 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 server can delete private key 328 upon completion of all development stages ([0088]), which meets the limitation of destroy the private key subsequent to generating [the first hash code and] the first signature. 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 does not specify that the processor 250 and memory 210 are implemented on the same semiconductor die. Sharma discloses a processor and memory implemented on the same semiconductor die ([0054]), which meets the limitation of non-volatile memory disposed on a semiconductor die, data set that is unique to the semiconductor die, 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 of Landman to have been implemented such that processor 250 and memory 210 are included on a single semiconductor die because Sharma 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.
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 import circuitry, wherein the import circuitry is 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, [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 export 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 250 and memory 210 are implemented on the same semiconductor die. Sharma discloses a processor and memory implemented on the same semiconductor die ([0054]), which meets the limitation wherein the export and the import circuitry 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 250 and memory 210 are included on a single semiconductor die because Sharma 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 import 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 export 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 export 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 import 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 component includes information from software development operations performed on the server ([0039] & [0059]: names of the data would be considered to be non-functional descriptive material that is not given patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of wherein the data set comprises one or more of physically unclonable function helper data, built-in self-test data, built-in self-repair data, TRIM command data, an advanced encryption standard key, and a certificate.
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 export 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 export 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 export 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 server can delete private key 328 upon completion of all development stages ([0088]), which meets the limitation of destroying the private key subsequent to the generating [the first hash code and] the first signature, by the export circuitry. 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 does not specify that the processor 250 and memory 210 are implemented on the same semiconductor die. Sharma discloses a processor and memory implemented on the same semiconductor die ([0054]), which meets the limitation of export circuitry of a semiconductor die, non-volatile memory of the semiconductor die, a data set 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 Sharma 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.
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 does not specify that the processor 250 and memory 210 are implemented on the same semiconductor die. Sharma discloses a processor and memory implemented on the same semiconductor die ([0054]), 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 Sharma 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 component includes information from software development operations performed on the server ([0039] & [0059]: names of the data would be considered to be non-functional descriptive material that is not given patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of wherein the data set comprises one or more of physically unclonable function helper data, built-in self-test data, built-in self-repair data, TRIM command data, an advanced encryption standard key, and a certificate.
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 Sharma, U.S. Publication No. 2023/0418604, 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 export 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 import 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 export 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 export 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 import 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
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 BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 6:20-4:50.
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