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 .
Status of Claims
Claims 1-5, 7-9, 11, 15, 20-30, 34-35, 38-39 are pending. Claims 6, 10, 12-14, 16-19, 31-33, 36-37 are cancelled.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/26/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 10/17/2025 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 8/12/2025 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, 7-9, 11, 15, 20, 23-29, 34-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).
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).
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.
Regarding Claim 2:
Cambou in view of Hinh 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 7:
Cambou in view of Hinh 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 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 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 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 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 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 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 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 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 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 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 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 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 34:
Cambou in view of Hinh teaches the method of claim 1. In addition, Cambou teaches wherein the target computer equipment is one of a plurality of pieces of computer equipment involved in a distributed computing system performing distributed computing, said computation being part of the distributed computing ([0043] distributed P2P architecture).
Regarding Claim 35:
Cambou in view of Hinh teaches the method of claim 34. 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).
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.
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).
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.
Claim(s) 3-5, 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cambou in view of Hinh, and further in view of Rule et al (PGPUB 2021/0390549).
Regarding Claim 3:
Cambou in view of Hinh teaches the method of claim 1. In addition, Cambou teaches 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).
Neither Cambou nor Hinh explicitly teaches, verifying party 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 causing a verifying party to verify a signature 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).
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 4:
Cambou in view of Hinh and Rule teaches the method of claim 3. 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 5:
Cambou in view of Hinh and Rule teaches the method of claim 3. In addition, Cambou teaches wherein the 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).
Regarding Claim 30:
Cambou in view of Hinh teaches the method of claim 1.
Neither Cambou nor Hinh explicitly teaches wherein the receiving of the computation request comprises accessing an electronic advertisement medium to retrieve the computation request, wherein the electronic advertisement medium is a blockchain or other peer-to-peer publication medium.
However, Rule teaches the concept wherein the receiving of a 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).
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 blockchain advertisement teachings of Rule with the PUF-based cryptographic key generation teachings of Cambou in view of Hinh, with the benefit of allowing a blockchain to fulfill multiple purposes, including providing cryptographically signed transaction requests for interested target parties to carry out in exchange for compensation, thereby providing an efficiency benefit to sellers and a monetary benefit to target parties, incentivizing use.
Claim(s) 21, 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cambou in view of Hinh, and further in view of Todd et al (PGPUB 2021/0124817).
Regarding Claim 21:
Cambou in view of Delsuc teaches the method of claim 20.
Neither Cambou nor Hinh 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, 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 teaches the method of claim 20.
Neither Cambou nor Hinh 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, 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 11/11/2025 have been fully considered but they are not persuasive.
Regarding the rejection under 35 USC 103:
Examiner’s response to applicant’s arguments, page 9 paragraph 5-page 10 paragraph 2: Applicant misconstrues the rejection; Examiner is not implying that the signature is the “requested computation”. Rather, it is the transaction itself which is the requested computation. Alice’s equipment “generates” (i.e. “computes”) a requested transaction, and then cryptographically signs it (separate step) (e.g. [0046]). Examiner notes that the BRI of “computation” can be seen to include any function performed by a computer, such as Alice’s equipment. Further, Cambou uses the language wherein “Alice” (i.e. the user, see [0048]) “generates the transaction”; it is clear that it is actually the client device of Alice which generates the transaction; therefore the request clearly comes from Alice herself. The only missing element is an indication of a separate issuing party which requested the computation.
Examiner’s response to applicant’s arguments, page 10 paragraph 3-page 11 paragraph 1: Alice does teach 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; her client device, comprising software (i.e. “applications”) (e.g. [0020]) performs the computation (i.e. “generating the transaction”), which is therefore “application-level”, and cryptographically signs the transaction record added to the blockchain (e.g. [0037]). Therefore, the only element(s) missing from Cambou are those of, “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”, as in claim 1 as amended. However, a new ground(s) for rejection is provided above which does teach this additional subject matter, as added by amendment.
Applicant’s arguments with regard to Delsuc are moot, as Delsuc is no longer part of the rejection of the claims.
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.
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 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