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 5/12/2026 has been entered.
Status of Claims
Claims 1-2, 4, 7-9, 11, 15, 20-30, 35, 38-39 are pending. Claims 3, 5-6, 10, 12-14, 16-19, 31-34, 36-37 are cancelled.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/11/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) submitted on 4/17/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 4, 7-9, 11, 15, 20, 23-30, 35, 38-39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cambou (PGPUB 2020/0076624), and further in view of Hinh (PGPUB 2022/0086127) and Rule et al (PGPUB 2021/0390549).
Regarding Claim 1:
Cambou teaches a computer-implemented method of performing a computation, the method comprising, by target computer equipment of a target party, being the computer equipment which is to perform the computation (abstract, systems and methods for securing blockchain and other cryptographically signed ledgers are disclosed; [0006] a system comprises a processor):
obtaining a cryptographic key derived from a response generated by PUF module comprising a physically unclonable function, PUF ([0008] system comprises a processor, a physical-unclonable-function (“PUF”) array of PUF devices an asymmetric public key generator (APKG), and memory coupled to the processor; [0037] after an APG 210 generates the corrected responses 232, the corrected responses 232 are used as a private-key input to an asymmetric public key generator (APKG 240) which produces a cryptographic public key 242 as an output; the corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; the APKG 240 may implement any acceptable asymmetric key generation algorithm for producing public keys from a private key according to any chosen asymmetric cryptography scheme), the response having been generated by the PUF module based on the PUF in response to a corresponding challenge input to the PUF module ([0031] in the Handshaking stage an objective is for the server 202 to transmit the information needed to identify a particular portion of the PUF array 260 of the client 205; both the server 202 and the client 205 can independently produce a response to the challenge: the server can lookup information about the PUF array 260 obtained during enrollment (or otherwise supplied to the server 202) and the client 205 can retrieve the same information by using the APG 210 to access the PUF array 260), wherein key information comprising the cryptographic key or a corresponding public key is also made available to a verifying party ([0042] each block contains a digest of previous blocks signed (encrypted) with a private key generated by the associated client 205 as well as a copy of the corresponding cryptographic public key 242, which may be used by anyone to verify (decrypt) the digest using the associate cryptographic public key 242);
in response to a computation request, performing the computation in order to generate a computation result ([0046] Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B);
signing a message comprising the computation result with the cryptographic key ([0046] Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B); and
making the signed message available to the verifying party by sending the signed message to be recorded in the payload of a transaction on a blockchain ([0037] corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data), wherein said computation is an application-level computation performed in addition to the signing of the message and recordal of the message on the blockchain ([0020] references to “users” refer generally to individuals accessing a particular computing device or resource, to an external computing device accessing a particular computing device or resource, or to various processes executing in any combination of hardware, software, or firmware that access a particular computing device or resource, i.e. “application-level”; [0037] corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; [0047] Bob receives the transaction 320 from Alice (or obtains it from the blockchain 380) and validates the transaction 320 to ensure that it represents a valid block);
wherein the sending of the signed message comprises:
the target party formulating a template blockchain transaction comprising the signed message ([0044]-[0046] process 300 of adding a new transaction to a blockchain 380; Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B); and
the target party sending the template transaction to the verifying party, thereby causing the verifying party to verify a signature on the message ([0047] Bob receives the transaction 320 from Alice (or obtains it from the blockchain 380) and validates the transaction 320 to ensure that it represents a valid block; Bob validates the block by using the public key PUB.k3A associated with the transaction 320 to decrypt the encrypted digest of the previous state of the blockchain 380 (e.g., a hash of the blockchain 380 prior to insertion of the transaction 320) and confirming that the decrypted digest agrees with the previous state of the blockchain 380 or an unencrypted hash thereof included in the transaction 320);
wherein a completed transaction pays the target party for the computation once recorded on the blockchain ([0046] the transaction 320 includes information effectuating the transfer of $100 to Bob as indicated by the plaintext gloss depicted in the FIG. 3).
Cambou does not explicitly teach, from an issuing party, receiving a computation request specifying the computation to be performed, the computation being part of a distributed grid computing application outsourced by the issuing party, wherein the target computer equipment is one of a plurality of pieces of computer equipment to which the issuing party outsources parts of the distributed grid computing application in a distributed computing system.
However, Hinh teaches the concept of, from an issuing party, receiving a computation request specifying the computation to be performed (abstract, techniques for vehicle distributed computing for on-demand computational capacity; systems and techniques described herein enable distribution of discrete computational work requests to other vehicle systems through generation and awarding of smart contracts to locally positioned other vehicle systems bidding for the smart contracts), the computation being part of a distributed grid computing application outsourced by the issuing party, wherein a target computer equipment is one of a plurality of pieces of computer equipment to which the issuing party outsources parts of the distributed grid computing application in a distributed computing system (abstract, techniques for vehicle distributed computing for on-demand computational capacity; systems and techniques described herein enable distribution of discrete computational work requests to other vehicle systems through generation and awarding of smart contracts to locally positioned other vehicle systems bidding for the smart contracts; [0030] for the purposes of this disclosure, any of the engines 224-232 may be any set of computer executable instructions installed upon, and executed from, a computing system of the first vehicle 202, second vehicle 204, or computing system 206; [0055] a computing device of a first vehicle generates a smart contract including a request to perform a computation for distribution to one or more vehicles via a public blockchain, the smart contract including task data, expiration of the smart contract, and deadline for completion of the request; the computing device may generate the smart contract in response to receiving a request for processing data at the computing device and determining that the available processing capacity of the computing device is insufficient to perform the request computations; the smart contract may be validated on the public network, for example on the public blockchain to ensure the first vehicle has value in a stored value account to compensate a second vehicle for performing the request under the smart contract).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the issuer distributed computing request teachings of Hinh with the PUF-based cryptographic key generation teachings of Cambou, with the benefit of incorporating the advantages of distributed computing, such as allowing multiple available devices to perform a computation of behalf of an originating computer, thereby accommodating any shortages or deficiencies in computing power affecting the originating computer (Hinh, [0001]), and doing so in such a way that provides verifiable accountability, e.g. through the use of PKI based blockchains, thus improving the security environment.
Neither Cambou nor Hinh explicitly teaches the template transaction being an incomplete transaction not yet recorded on the blockchain; and
the verifying party to verify a signature on the message, and in dependence thereon to complete the template transaction at least by signing with a signature of the verifying party, and forward the completed transaction to be recorded on the blockchain.
However, Rule teaches the concept of a template transaction being an incomplete transaction not yet recorded on a blockchain ([0008] each verifier has a private key; each verifier is capable of verifying the verifiable characteristic of the asset and signing a new block with the private key; each miner is capable of cryptographically verifying the new block using a public key in return for a reward and adding the new block to the blockchain; EXAMINER’S NOTE: new block therefore can be considered an incomplete “template transaction” not yet recorded on the blockchain, until verifier signs it, thereby “completing” it); and
a verifying party to verify a [verifiable characteristic] on a message, and in dependence thereon to complete the template transaction at least by signing with a signature of the verifying party, and forward the completed transaction to be recorded on the blockchain ([0008] each verifier has a private key; each verifier is capable of verifying the verifiable characteristic of the asset and signing a new block with the private key; each miner is capable of cryptographically verifying the new block using a public key in return for a reward and adding the new block to the blockchain); and
Cambou teaches wherein the [verifiable characteristic] is a signature ([0047]).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the verifying party signature teachings of Rule with the PUF-based cryptographic key generation teachings of Cambou in view of Hinh, with the benefit of publicly recording proof of agreement not only by the calculating party but also the verifying party, thereby eliminating any dispute that both parties had agreed to the transaction.
Regarding Claim 2:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Hinh teaches wherein the issuing party is the verifying party ([0051] at 336, the first vehicle 302 receives the encrypted completed work message digest and encrypted signature from the second vehicle; the first vehicle 302 subsequently decrypts the completed work message digest and the signature using the private key of the first vehicle 302 at 338; [0052] At 340, the first vehicle 302 validates the signature using the public key of the second vehicle 304).
The rationale to combine Cambou and Hinh is the same as provided for claim 1 due to the overlapping subject matter between claims 1 and 2.
Regarding Claim 4:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Cambou teaches wherein the message comprises at least part of the template transaction ([0047] Bob receives the transaction 320 from Alice (or obtains it from the blockchain 380) and validates the transaction 320 to ensure that it represents a valid block).
Regarding Claim 7:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Cambou teaches wherein the obtaining of the cryptographic key is performed, and the key information made available to the verifying party, in a set-up phase prior to the target party receiving the computation request ([0044]-[0045] before generating and signing the transaction 320 (i.e., a transaction block), Alice contacts the server 302 to initiate the process and receives a challenge similar to the challenge 222 of FIG. 2A from the server 302 (not shown); as described above in connection with FIG. 2, the client 305a (Alice) generates a public key PUB.k3A using a response to the challenge; the process 300 begins at step 372 after the public key PUB.3kA has been generated; at step 372, Alice transmits the public key PUB.3kA to the server 302 and is authenticated by the server 302; the server 302 stores the public key PUB.3kA in the public ledger 390 and associates the public key PUB.3kA with Alice in the ledger 390, along with public keys previously used by Alice (public keys PUB.1kA and PUB.2kA); the ledger 390 may also store keys for other clients 305 such as Bob (client 305b) and others through client 305n; storing the keys in the public ledger prior to generating the transaction therefore makes the keys “available” to the verifying party).
Regarding Claim 8:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Cambou teaches wherein said obtaining comprises:
receiving the response from the issuing party, verifying party or a trusted third party, the challenge having been input into the PUF module to generate the response by the issuing party, verifying party or trusted third party on behalf of the target party, and generating of the cryptographic key being based on the received response ([0031] in the Handshaking stage an objective is for the server 202 to transmit the information needed to identify a particular portion of the PUF array 260 of the client 205; both the server 202 and the client 205 can independently produce a response to the challenge: the server can lookup information about the PUF array 260 obtained during enrollment (or otherwise supplied to the server 202) and the client 205 can retrieve the same information by using the APG 210 to access the PUF array 260; [0035] server 202 can authenticate a client 205 by issuing the challenge 222 to the client 205 and then comparing the corrected challenge response 232 generated by APG 210 with the initial response to that challenge stored by the server 202 for that client 205 (e.g., initial challenge responses 230) or determine that the corrected challenge response 232 is consistent with the initial challenge response 230 by comparing information derived from the corrected challenge responses 232 with information derived similarly by the server 202 from one of the initial challenge responses 230 corresponding to the challenge 232 issued by the server; [0037] the server 202 may instruct a client 205 not to cryptographically sign the blockchain 280 or other message unless the client 205 has been successfully authenticated by the server 202; in other embodiments, the server 202 may provide confirmation to a client 205 of successful authentication, indicating that the blockchain 280 or other message may be cryptographically signed by the client 205).
Regarding Claim 9:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Cambou teaches wherein said obtaining comprises:
receiving the public key from the issuing party, verifying party or a trusted third party, the challenge having been input into the PUF by the issuing party, verifying party or trusted third party to generate the response and derive the cryptographic key on behalf of the target party ([0037] after an APG 210 generates the corrected responses 232, the corrected responses 232 are used as a private-key input to an asymmetric public key generator (APKG 240) which produces a cryptographic public key 242 as an output; the corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; the APKG 240 may implement any acceptable asymmetric key generation algorithm for producing public keys from a private key according to any chosen asymmetric cryptography scheme).
Regarding Claim 11:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Cambou teaches wherein said obtaining comprises: the target party performing the inputting of the challenge to the PUF module to generate the response and derive the cryptographic key by the target party ([0037] after an APG 210 generates the corrected responses 232, the corrected responses 232 are used as a private-key input to an asymmetric public key generator (APKG 240) which produces a cryptographic public key 242 as an output; the corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; the APKG 240 may implement any acceptable asymmetric key generation algorithm for producing public keys from a private key according to any chosen asymmetric cryptography scheme).
Regarding Claim 15:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Cambou teaches wherein:
the making available of the key information to the verifying party comprises: storing the key information linked to an identity of the target party or target computer equipment, in a key information storage medium accessible to the verifying party ([0043] in addition to authenticating the clients 205, the server maintains a ledger of the cryptographic public keys 242 used by each client 205 to sign the blockchain(s) 280; the embodiments disclosed herein may be applied equally to applications with a single centralized blockchain, distributed P2P architectures, and other systems where the each client may maintain one or more blockchains unique to that client; the server 202 tracks the public keys 242 used by each client 205 after being authenticated by the server 202 as described above; the server 202 maintains a ledger 290 containing all public keys 242 used by authenticated clients 205 and makes the ledger 290 available to other clients 205 or other parties who wish to verify signed transactions);
the key information storage medium is implemented in third party server equipment comprising one or more server units at one or more physical sites ([0043] server maintains a ledger); and
the key information storage medium is a blockchain or other peer-to-peer publication medium ([0043] ledger).
Regarding Claim 20:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Cambou teaches the method, comprising encrypting the computation result so as to require a decryption key to decrypt ([0042] clients 205 sign associated blockchain blocks 280 (blocks {280a, . . . , 280j, . . . , 280n}, respectively); each block contains a digest of previous blocks signed (encrypted) with a private key generated by the associated client 205 as well as a copy of the corresponding cryptographic public key 242, which may be used by anyone to verify (decrypt) the digest using the associate cryptographic public key 242), wherein the computation result is made available able to the verifying party only in encrypted form, and the decryption key is made available to the verifying party and/or issuing party ([0042] each block contains a digest of previous blocks signed (encrypted) with a private key generated by the associated client 205 as well as a copy of the corresponding cryptographic public key 242, which may be used by anyone to verify (decrypt) the digest using the associate cryptographic public key 242).
Regarding Claim 23:
Cambou in view of Hinh and Rule teaches the method of claim 20. In addition, Cambou teaches wherein the decryption key is derived from another response generated by the PUF module, or another PUF module, in response to another challenge input to the PUF module by the target party, verifying party, issuing party or a trusted third party ([0030] during the Enrollment stage, the server 202 may obtain the initial responses 230 for each client 205 by generating all possible challenges 222 and storing responses 230 to those challenges 222 generated by each APG 210 in a database 204; [0031] after the clients 205 are enrolled with the server 202, embodiments disclosed herein may be utilized to generate private/public key pairs to sign transactions; first, the sever 202 and a client 205 (such as “Client j” shown in FIG. 2A) enter the Handshaking stage; in the Handshaking stage an objective is for the server 202 to transmit the information needed to identify a particular portion of the PUF array 260 of the client 205; both the server 202 and the client 205 can independently produce a response to the challenge: the server can lookup information about the PUF array 260 obtained during enrollment (or otherwise supplied to the server 202) and the client 205 can retrieve the same information by using the APG 210 to access the PUF array 260).
Regarding Claim 24:
Cambou in view of Hinh and Rule teaches the method of claim 23. In addition, Cambou teaches wherein the method comprises the target party inputting said another response to generate the another challenge, and deriving the decryption key ([0033] the ability to generate the challenge response 230 may be protected by a password 223. In such embodiments, the address 225 specifying which device(s) in the PUF array 260 to access is produced by inputting the challenge 222 combined with the password 223 to a hashing function 221; as an example, if the PUF array 260 is represented as a two-dimensional array containing 256 rows and 256 columns, 8 bits of the message digest can be used to find the first coordinate X in the PUF array 260; the following 8 bits can be used to find the second coordinate Y; [0036] if the Hamming distance between the corrected challenge response 232 and the expected response is greater than the predetermined distance, the server 202 may issue the client 205 a new challenge 222 and authenticate the client based on the corrected challenge response 232 to the new challenge 222; [0037] after an APG 210 generates the corrected responses 232, the corrected responses 232 are used as a private-key input to an asymmetric public key generator (APKG 240) which produces a cryptographic public key 242 as an output).
Regarding Claim 25:
Cambou in view of Hinh and Rule teaches the method of claim 20. In addition, Cambou teaches the method, comprising the target party making the decryption key available to the verifying party and/or issuing party ([0043] the server maintains a ledger of the cryptographic public keys 242 used by each client 205 to sign the blockchain(s) 280; the embodiments disclosed herein may be applied equally to applications with a single centralized blockchain, distributed P2P architectures, and other systems where the each client may maintain one or more blockchains unique to that client; the server 202 tracks the public keys 242 used by each client 205 after being authenticated by the server 202 as described above; the server 202 maintains a ledger 290 containing all public keys 242 used by authenticated clients 205 and makes the ledger 290 available to other clients 205 or other parties who wish to verify signed transactions).
Regarding Claim 26:
Cambou in view of Hinh and Rule teaches the method of claim 20. In addition, Cambou teaches wherein the making available of the decryption key to the verifying party and/or issuing party comprises:
sending the decryption key to the verifying party and/or issuing party ([0043] the server maintains a ledger of the cryptographic public keys 242 used by each client 205 to sign the blockchain(s) 280; the embodiments disclosed herein may be applied equally to applications with a single centralized blockchain, distributed P2P architectures, and other systems where the each client may maintain one or more blockchains unique to that client; the server 202 tracks the public keys 242 used by each client 205 after being authenticated by the server 202 as described above; the server 202 maintains a ledger 290 containing all public keys 242 used by authenticated clients 205 and makes the ledger 290 available to other clients 205 or other parties who wish to verify signed transactions).
Regarding Claim 27:
Cambou in view of Hinh and Rule teaches the method of claim 20. In addition, Cambou teaches wherein the making available of the decryption key to the verifying party and/or issuing party comprises:
storing the decryption key in a decryption key storage medium accessible to the verifying and/or issuing party ([0043] the server maintains a ledger of the cryptographic public keys 242 used by each client 205 to sign the blockchain(s) 280; the embodiments disclosed herein may be applied equally to applications with a single centralized blockchain, distributed P2P architectures, and other systems where the each client may maintain one or more blockchains unique to that client; the server 202 tracks the public keys 242 used by each client 205 after being authenticated by the server 202 as described above; the server 202 maintains a ledger 290 containing all public keys 242 used by authenticated clients 205 and makes the ledger 290 available to other clients 205 or other parties who wish to verify signed transactions).
Regarding Claim 28:
Cambou in view of Hinh and Rule teaches the method of claim 27. In addition, Cambou teaches wherein the decryption key storage medium is implemented in third party server equipment comprising one or more server units at one or more physical sites ([0043] the server maintains a ledger of the cryptographic public keys 242 used by each client 205 to sign the blockchain(s) 280; the embodiments disclosed herein may be applied equally to applications with a single centralized blockchain, distributed P2P architectures, and other systems where the each client may maintain one or more blockchains unique to that client; the server 202 tracks the public keys 242 used by each client 205 after being authenticated by the server 202 as described above; the server 202 maintains a ledger 290 containing all public keys 242 used by authenticated clients 205 and makes the ledger 290 available to other clients 205 or other parties who wish to verify signed transactions).
Regarding Claim 29:
Cambou in view of Hinh and Rule teaches the method of claim 27. In addition, Cambou teaches wherein the decryption key storage medium is a blockchain or other peer-to-peer publication medium ([0043] the server maintains a ledger of the cryptographic public keys 242 used by each client 205 to sign the blockchain(s) 280; the embodiments disclosed herein may be applied equally to applications with a single centralized blockchain, distributed P2P architectures, and other systems where the each client may maintain one or more blockchains unique to that client; the server 202 tracks the public keys 242 used by each client 205 after being authenticated by the server 202 as described above; the server 202 maintains a ledger 290 containing all public keys 242 used by authenticated clients 205 and makes the ledger 290 available to other clients 205 or other parties who wish to verify signed transactions).
Regarding Claim 30:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Rule teaches wherein the receiving of the computation request comprises accessing an electronic advertisement medium to retrieve the computation request ([0020] System 100 can include a network-enabled computer having a memory 102 that holds a blockchain 104; the memory can have a block 106 data structure representing a transaction 108 for an asset having an identifier 110 and one or more verifiable asset characteristics 112; blockchain 104 can be in memory 102 and link one or more blocks 106 having the block data structure; as shown in FIG. 1, the block data structure may comprise one or more transactions 108, each of which may include an asset identifier 110, one or more asset characteristics 112, and other data; [0022] Transaction 108 may reflect the state of the asset associated with blockchain 104, an event associated with the asset, or any other data related to the asset; for example, transaction 108 may be a request for a home mortgage verification from a banker, a description of a designer purse for sale in an auction, or a notice that a car needs an emissions inspection by a certain date; [0038] each verifier 302 is capable of verifying the verifiable characteristic 320 of the asset in a transaction 316 in an old block 314 and signing a new block 322 with the private key 310 for the blockchain 312), wherein the electronic advertisement medium is a blockchain or other peer-to-peer publication medium ([0020] blockchain).
Regarding Claim 35:
Cambou in view of Hinh and Rule teaches the method of claim 1. In addition, Hinh teaches wherein the distributed computing is performed on a pay per computation basis, wherein the target party receives a payment for performing the computation on condition that the verifying party verifies a signature of the target party based on the key information ([0021] the winning vehicle 104 decrypts and performs the processing requests before returning the completed requests to the vehicle 102; the completed requests are validated at the vehicle 102 using an encrypted signature including the message digest between the vehicle 102 and the winning vehicle 104; upon validation of the completed request, funds or value are transferred from a stored value account 112 of the vehicle 102 to a stored value account 114 of the winning vehicle 104).
The rationale to combine Cambou and Hinh is the same as provided for claim 1 due to the overlapping subject matter between claims 1 and 35.
Regarding Claim 38:
Cambou teaches target computer equipment of a target party, the target computer equipment comprising (abstract, systems and methods for securing blockchain and other cryptographically signed ledgers are disclosed; [0008] a system comprises a processor):
memory comprising one or more memory units ([0008] memory); and
processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when run on the processing apparatus, the processing apparatus performs a method comprising ([0008] memory storing instructions, executed by a processor):
obtaining a cryptographic key derived from a response generated by PUF module comprising a physically unclonable function, PUF ([0008] system comprises a processor, a physical-unclonable-function (“PUF”) array of PUF devices an asymmetric public key generator (APKG), and memory coupled to the processor; [0037] after an APG 210 generates the corrected responses 232, the corrected responses 232 are used as a private-key input to an asymmetric public key generator (APKG 240) which produces a cryptographic public key 242 as an output; the corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; the APKG 240 may implement any acceptable asymmetric key generation algorithm for producing public keys from a private key according to any chosen asymmetric cryptography scheme), the response having been generated by the PUF module based on the PUF in response to a corresponding challenge input to the PUF module ([0031] in the Handshaking stage an objective is for the server 202 to transmit the information needed to identify a particular portion of the PUF array 260 of the client 205; both the server 202 and the client 205 can independently produce a response to the challenge: the server can lookup information about the PUF array 260 obtained during enrollment (or otherwise supplied to the server 202) and the client 205 can retrieve the same information by using the APG 210 to access the PUF array 260), wherein key information comprising the cryptographic key or a corresponding public key is also made available to a verifying party ([0042] each block contains a digest of previous blocks signed (encrypted) with a private key generated by the associated client 205 as well as a copy of the corresponding cryptographic public key 242, which may be used by anyone to verify (decrypt) the digest using the associate cryptographic public key 242);
in response to the computation request, performing the computation in order to generate a computation result ([0046] Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B);
signing a message comprising the computation result with the cryptographic key ([0046] Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B); and
making the signed message available to the verifying party by sending the signed message to be recorded on a blockchain ([0037] corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data), wherein said computation is an application-level computation performed in addition to the signing of the message and recordal of the message on the blockchain ([0020] references to “users” refer generally to individuals accessing a particular computing device or resource, to an external computing device accessing a particular computing device or resource, or to various processes executing in any combination of hardware, software, or firmware that access a particular computing device or resource, i.e. “application-level”; [0037] corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; [0047] Bob receives the transaction 320 from Alice (or obtains it from the blockchain 380) and validates the transaction 320 to ensure that it represents a valid block);
wherein the sending of the signed message comprises:
the target party formulating a template blockchain transaction comprising the signed message ([0044]-[0046] process 300 of adding a new transaction to a blockchain 380; Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B); and
the target party sending the template transaction to the verifying party, thereby causing the verifying party to verify a signature on the message ([0047] Bob receives the transaction 320 from Alice (or obtains it from the blockchain 380) and validates the transaction 320 to ensure that it represents a valid block; Bob validates the block by using the public key PUB.k3A associated with the transaction 320 to decrypt the encrypted digest of the previous state of the blockchain 380 (e.g., a hash of the blockchain 380 prior to insertion of the transaction 320) and confirming that the decrypted digest agrees with the previous state of the blockchain 380 or an unencrypted hash thereof included in the transaction 320);
wherein a completed transaction pays the target party for the computation once recorded on the blockchain ([0046] the transaction 320 includes information effectuating the transfer of $100 to Bob as indicated by the plaintext gloss depicted in the FIG. 3).
Cambou does not explicitly teach, from an issuing party, receiving a computation request specifying the computation to be performed, the computation being part of a distributed grid computing application outsourced by the issuing party, wherein the target computer equipment is one of a plurality of pieces of computer equipment to which the issuing party outsources parts of the distributed grid computing application in a distributed computing system.
However, Hinh teaches the concept of, from an issuing party, receiving a computation request specifying the computation to be performed (abstract, techniques for vehicle distributed computing for on-demand computational capacity; systems and techniques described herein enable distribution of discrete computational work requests to other vehicle systems through generation and awarding of smart contracts to locally positioned other vehicle systems bidding for the smart contracts), the computation being part of a distributed grid computing application outsourced by the issuing party, wherein a target computer equipment is one of a plurality of pieces of computer equipment to which the issuing party outsources parts of the distributed grid computing application in a distributed computing system (abstract, techniques for vehicle distributed computing for on-demand computational capacity; systems and techniques described herein enable distribution of discrete computational work requests to other vehicle systems through generation and awarding of smart contracts to locally positioned other vehicle systems bidding for the smart contracts; [0030] for the purposes of this disclosure, any of the engines 224-232 may be any set of computer executable instructions installed upon, and executed from, a computing system of the first vehicle 202, second vehicle 204, or computing system 206; [0055] a computing device of a first vehicle generates a smart contract including a request to perform a computation for distribution to one or more vehicles via a public blockchain, the smart contract including task data, expiration of the smart contract, and deadline for completion of the request; the computing device may generate the smart contract in response to receiving a request for processing data at the computing device and determining that the available processing capacity of the computing device is insufficient to perform the request computations; the smart contract may be validated on the public network, for example on the public blockchain to ensure the first vehicle has value in a stored value account to compensate a second vehicle for performing the request under the smart contract).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the issuer distributed computing request teachings of Hinh with the PUF-based cryptographic key generation teachings of Cambou, with the benefit of incorporating the advantages of distributed computing, such as allowing multiple available devices to perform a computation of behalf of an originating computer, thereby accommodating any shortages or deficiencies in computing power affecting the originating computer (Hinh, [0001]), and doing so in such a way that provides verifiable accountability, e.g. through the use of PKI based blockchains, thus improving the security environment.
Neither Cambou nor Hinh explicitly teaches the template transaction being an incomplete transaction not yet recorded on the blockchain; and
the verifying party to verify a signature on the message, and in dependence thereon to complete the template transaction at least by signing with a signature of the verifying party, and forward the completed transaction to be recorded on the blockchain.
However, Rule teaches the concept of a template transaction being an incomplete transaction not yet recorded on a blockchain ([0008] each verifier has a private key; each verifier is capable of verifying the verifiable characteristic of the asset and signing a new block with the private key; each miner is capable of cryptographically verifying the new block using a public key in return for a reward and adding the new block to the blockchain; EXAMINER’S NOTE: new block therefore can be considered an incomplete “template transaction” not yet recorded on the blockchain, until verifier signs it, thereby “completing” it); and
a verifying party to verify a [verifiable characteristic] on a message, and in dependence thereon to complete the template transaction at least by signing with a signature of the verifying party, and forward the completed transaction to be recorded on the blockchain ([0008] each verifier has a private key; each verifier is capable of verifying the verifiable characteristic of the asset and signing a new block with the private key; each miner is capable of cryptographically verifying the new block using a public key in return for a reward and adding the new block to the blockchain); and
Cambou teaches wherein the [verifiable characteristic] is a signature ([0047]).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the verifying party signature teachings of Rule with the PUF-based cryptographic key generation teachings of Cambou in view of Hinh, with the benefit of publicly recording proof of agreement not only by the calculating party but also the verifying party, thereby eliminating any dispute that both parties had agreed to the transaction.
Regarding Claim 39:
Cambou teaches a computer program embodied on a non-transitory computer-readable medium and configured so as, when run on one or more processors of target computer equipment of a target party, the one or more processors perform a method comprising (abstract, systems and methods for securing blockchain and other cryptographically signed ledgers are disclosed; [0008] a system comprises a processor; ([0008] memory storing instructions, executed by a processor)):
obtaining a cryptographic key derived from a response generated by PUF module comprising a physically unclonable function, PUF ([0008] system comprises a processor, a physical-unclonable-function (“PUF”) array of PUF devices an asymmetric public key generator (APKG), and memory coupled to the processor; [0037] after an APG 210 generates the corrected responses 232, the corrected responses 232 are used as a private-key input to an asymmetric public key generator (APKG 240) which produces a cryptographic public key 242 as an output; the corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; the APKG 240 may implement any acceptable asymmetric key generation algorithm for producing public keys from a private key according to any chosen asymmetric cryptography scheme), the response having been generated by the PUF module based on the PUF in response to a corresponding challenge input to the PUF module ([0031] in the Handshaking stage an objective is for the server 202 to transmit the information needed to identify a particular portion of the PUF array 260 of the client 205; both the server 202 and the client 205 can independently produce a response to the challenge: the server can lookup information about the PUF array 260 obtained during enrollment (or otherwise supplied to the server 202) and the client 205 can retrieve the same information by using the APG 210 to access the PUF array 260), wherein key information comprising the cryptographic key or a corresponding public key is also made available to a verifying party ([0042] each block contains a digest of previous blocks signed (encrypted) with a private key generated by the associated client 205 as well as a copy of the corresponding cryptographic public key 242, which may be used by anyone to verify (decrypt) the digest using the associate cryptographic public key 242);
in response to the computation request, performing the computation in order to generate a computation result ([0046] Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B);
signing a message comprising the computation result with the cryptographic key ([0046] Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B); and
making the signed message available to the verifying party by sending the signed message to be recorded on a blockchain ([0037] corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data), wherein said computation is an application-level computation performed in addition to the signing of the message and recordal of the message on the blockchain ([0020] references to “users” refer generally to individuals accessing a particular computing device or resource, to an external computing device accessing a particular computing device or resource, or to various processes executing in any combination of hardware, software, or firmware that access a particular computing device or resource, i.e. “application-level”; [0037] corrected responses 232 may then be used as a cryptographic private key which the client 205 may use to cryptographically sign a transaction record added to the blockchain 280 or other data; [0047] Bob receives the transaction 320 from Alice (or obtains it from the blockchain 380) and validates the transaction 320 to ensure that it represents a valid block);
wherein the sending of the signed message comprises:
the target party formulating a template blockchain transaction comprising the signed message ([0044]-[0046] process 300 of adding a new transaction to a blockchain 380; Alice generates the transaction 320 and cryptographically signs it using a private key used to generate the public key PUB.k3A using methods similar to those described previously in connection with FIGS. 2A and 2B); and
the target party sending the template transaction to the verifying party, thereby causing the verifying party to verify a signature on the message ([0047] Bob receives the transaction 320 from Alice (or obtains it from the blockchain 380) and validates the transaction 320 to ensure that it represents a valid block; Bob validates the block by using the public key PUB.k3A associated with the transaction 320 to decrypt the encrypted digest of the previous state of the blockchain 380 (e.g., a hash of the blockchain 380 prior to insertion of the transaction 320) and confirming that the decrypted digest agrees with the previous state of the blockchain 380 or an unencrypted hash thereof included in the transaction 320);
wherein a completed transaction pays the target party for the computation once recorded on the blockchain ([0046] the transaction 320 includes information effectuating the transfer of $100 to Bob as indicated by the plaintext gloss depicted in the FIG. 3).
Cambou does not explicitly teach, from an issuing party, receiving a computation request specifying the computation to be performed, the computation being part of a distributed grid computing application outsourced by the issuing party, wherein the target computer equipment is one of a plurality of pieces of computer equipment to which the issuing party outsources parts of the distributed grid computing application in a distributed computing system.
However, Hinh teaches the concept of, from an issuing party, receiving a computation request specifying the computation to be performed (abstract, techniques for vehicle distributed computing for on-demand computational capacity; systems and techniques described herein enable distribution of discrete computational work requests to other vehicle systems through generation and awarding of smart contracts to locally positioned other vehicle systems bidding for the smart contracts), the computation being part of a distributed grid computing application outsourced by the issuing party, wherein a target computer equipment is one of a plurality of pieces of computer equipment to which the issuing party outsources parts of the distributed grid computing application in a distributed computing system (abstract, techniques for vehicle distributed computing for on-demand computational capacity; systems and techniques described herein enable distribution of discrete computational work requests to other vehicle systems through generation and awarding of smart contracts to locally positioned other vehicle systems bidding for the smart contracts; [0030] for the purposes of this disclosure, any of the engines 224-232 may be any set of computer executable instructions installed upon, and executed from, a computing system of the first vehicle 202, second vehicle 204, or computing system 206; [0055] a computing device of a first vehicle generates a smart contract including a request to perform a computation for distribution to one or more vehicles via a public blockchain, the smart contract including task data, expiration of the smart contract, and deadline for completion of the request; the computing device may generate the smart contract in response to receiving a request for processing data at the computing device and determining that the available processing capacity of the computing device is insufficient to perform the request computations; the smart contract may be validated on the public network, for example on the public blockchain to ensure the first vehicle has value in a stored value account to compensate a second vehicle for performing the request under the smart contract).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the issuer distributed computing request teachings of Hinh with the PUF-based cryptographic key generation teachings of Cambou, with the benefit of incorporating the advantages of distributed computing, such as allowing multiple available devices to perform a computation of behalf of an originating computer, thereby accommodating any shortages or deficiencies in computing power affecting the originating computer (Hinh, [0001]), and doing so in such a way that provides verifiable accountability, e.g. through the use of PKI based blockchains, thus improving the security environment.
Neither Cambou nor Hinh explicitly teaches the template transaction being an incomplete transaction not yet recorded on the blockchain; and
the verifying party to verify a signature on the message, and in dependence thereon to complete the template transaction at least by signing with a signature of the verifying party, and forward the completed transaction to be recorded on the blockchain.
However, Rule teaches the concept of a template transaction being an incomplete transaction not yet recorded on a blockchain ([0008] each verifier has a private key; each verifier is capable of verifying the verifiable characteristic of the asset and signing a new block with the private key; each miner is capable of cryptographically verifying the new block using a public key in return for a reward and adding the new block to the blockchain; EXAMINER’S NOTE: new block therefore can be considered an incomplete “template transaction” not yet recorded on the blockchain, until verifier signs it, thereby “completing” it); and
a verifying party to verify a [verifiable characteristic] on a message, and in dependence thereon to complete the template transaction at least by signing with a signature of the verifying party, and forward the completed transaction to be recorded on the blockchain ([0008] each verifier has a private key; each verifier is capable of verifying the verifiable characteristic of the asset and signing a new block with the private key; each miner is capable of cryptographically verifying the new block using a public key in return for a reward and adding the new block to the blockchain); and
Cambou teaches wherein the [verifiable characteristic] is a signature ([0047]).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the verifying party signature teachings of Rule with the PUF-based cryptographic key generation teachings of Cambou in view of Hinh, with the benefit of publicly recording proof of agreement not only by the calculating party but also the verifying party, thereby eliminating any dispute that both parties had agreed to the transaction.
Claim(s) 21, 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cambou in view of Hinh and Rule, and further in view of Todd et al (PGPUB 2021/0124817).
Regarding Claim 21:
Cambou in view of Hinh and Rule teaches the method of claim 20.
Neither Cambou nor Hinh nor Rule explicitly teaches wherein the encryption comprises encrypting the computation result before signing with the cryptographic key.
However, Todd teaches the concept wherein encryption comprises encrypting a computation result before signing with a cryptographic key ([0048] example approach to identity schemes and authentication that may be employed in embodiments of the invention employs distributed ledgers, or blockchains; [0059] permission 404 may be digitally signed by the user using a private key that is unique to J-Doe; the permission 404 may be encrypted before, or after, signing by J-Doe).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the encryption/decryption teachings of Todd with the PUF-based cryptographic key generation teachings of Cambou in view of Hinh and Rule, with the benefit of providing additional security over asymmetric digital signature based teachings (which typically only encrypt the digest of a message/computation) by further encrypting the entire message/computation content, thereby allowing only intended parties to decrypt the information who possess the necessary decryption key.
Regarding Claim 22:
Cambou in view of Hinh and Rule teaches the method of claim 20.
Neither Cambou nor Hinh nor Rule explicitly teaches wherein the encryption comprises encrypting the message after signing with the cryptographic key.
However, Todd teaches the concept wherein encryption comprises encrypting a message after signing with a cryptographic key ([0048] example approach to identity schemes and authentication that may be employed in embodiments of the invention employs distributed ledgers, or blockchains; [0059] permission 404 may be digitally signed by the user using a private key that is unique to J-Doe; the permission 404 may be encrypted before, or after, signing by J-Doe).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the encryption/decryption teachings of Todd with the PUF-based cryptographic key generation teachings of Cambou in view of Hinh and Rule, with the benefit of providing additional security over asymmetric digital signature based teachings (which typically only encrypt the digest of a message/computation) by further encrypting the entire message/computation content, thereby allowing only intended parties to decrypt the information who possess the necessary decryption key.
Response to Arguments
Applicant's arguments filed 5/12/2026 have been fully considered but they are not persuasive.
Regarding the rejection under 35 USC 103:
Examiner’s response to applicant’s arguments, page 11 paragraph 5-page 12 paragraph 1: Applicant is arguing elements of the claim which Hinh was not cited as teaching. Hinh was cited as teaching elements related to receiving the computation request, as part of a distributed grid computing application. It was Cambou which was cited as teaching the argued elements; it is not necessary for Hinh to teach them also. Further, while Hinh teaches returning a signed message comprising the computation result to the issuer/verifier, Hinh is silent on other aspects of the signed message; one could certainly envision a person of ordinary skill in the art seeing recording of the transaction result (which could be viewed as a separate “template transaction” not yet recorded on the blockchain) in the blockchain as a permanent, non-repudiable record, as particularly advantageous in terms of securing a transaction.
Examiner’s response to applicant’s arguments, page 12 paragraph 4: The only element(s) apparently missing from Cambou are those of the template transaction being an incomplete transaction not yet recorded on the blockchain. However, a new ground(s) for rejection is provided above which does teach this additional subject matter, as added by amendment.
Examiner’s response to applicant’s arguments, page 13 paragraph 3-4: Examiner disagrees. If a block contains transactions, as it does in Rule by applicant’s own admission, then the block itself, prior to being added to the blockchain, can be seen as a “template transaction, not yet recorded on the blockchain”. Further, Rule teaches that the verifier creates a new block (i.e. “template transaction”) in [0008], and signs it. Applicant’s own specification is very clear that signing a block by a verifier completes it; therefore, until the verifier signs the block, it is incomplete (see e.g. specification, page 93, paragraph 3). Therefore, the new block, or even the asset information being recorded into the new block, is an incomplete transaction not yet recorded on the blockchain.
With regard to Rule not “verifying the identity of a party”, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “verifying the identity of a party”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). While the claim recites “signing of the message”, digital signatures can be calculated in many different ways, and not necessarily using identifying information of a particular party.
Applicant’s arguments with regard to independent claims 38-39 are similar to those regarding claim 1 and are therefore responded to in a similar way.
Applicant further argues that the dependent claims are allowable due to depending on an allowable independent claim. However, as shown above, the independent claims are not allowable.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights