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 .
DETAILED ACTION
The instant application having Application No. 19/022,085 is presented for examination by the examiner. Claims 1-20 have been examined.
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.
Claims 1-3, 6-8, 11-13, 16-17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Guo (US 20200382326 A1), in view of Smith (US 20170317997 A1), and in further view of Hennebert (US 2019/0207757 A1).
Regarding Claim 1
Guo discloses:
A computer-implemented method of verifying a digital certificate, comprising:
receiving a digital certificate for a first entity, the digital certificate including a public key for the first entity and a certification transaction identifier generated from a hash of a certification transaction, where the certification transaction includes a digital signature from a certificate authority, a first output to an address based on a second public key, and a second output having an information field that contains a first public key (Guo ¶¶0025, 0028-0032, 0047-0049, 0059-0061: Teaches receiving a verification request for verifying a target digital certificate, where the verification request carries the target digital certificate and a transaction identifier corresponding to the target digital certificate. Guo further teaches that the target digital certificate is generated by an authentication center/certificate authority, includes public key information of the certificate application node, includes signature information of the authentication center, and is written into the blockchain as a certificate transaction record. Guo also teaches generating a transaction identifier corresponding to the certificate transaction record and transmitting the transaction identifier to the certificate application node so that the certificate and transaction identifier may be used for later verification.);
obtaining a copy of the certification transaction from a blockchain network based on the certification transaction identifier in the digital certificate (Guo ¶¶0030-0032, 0049, 0072, 0098-0103: Teaches obtaining a target transaction record corresponding to the target digital certificate from a blockchain, where the verification request carries a transaction identifier corresponding to the target digital certificate. Guo further teaches that a node communicating with the certificate application node may obtain the transaction identifier and target digital certificate, and obtain, from the blockchain according to the transaction identifier, the transaction record stored in the blockchain for the target digital certificate to perform certificate verification.);
in response to the determination that the first output is an unspent transaction output and to the determination that the first public key matches the public key in the digital certificate, verifying the digital certificate as valid (Guo ¶¶0033-0038, 0094, 0101-0103: Guo teaches verifying a digital certificate as valid based on the certificate’s blockchain transaction state by determining a verification result according to a target account type in the latest transaction record, where a certificate issuing account type indicates that the certificate is valid and verification succeeds, while a certificate recovery account type indicates that the certificate has been revoked and verification fails. However, Guo does not expressly disclose determining that the first output is an unspent transaction output and determining that the first public key matches the public key in the digital certificate.).
Guo teaches a blockchain based digital certificate verification system that receives a verification request carrying a target digital certificate and transaction identifier, obtains a corresponding transaction record from the blockchain, and determines whether the target digital certificate is valid based on certificate operation state information in the blockchain transaction record. However, Guo is silent in explicitly teaching that a first output of the certification transaction is an unspent transaction output by verifying that the first output is present in an unspent transaction output pool of the blockchain network and thus has not been used in any subsequent transaction. On the other hand, Smith teaches an attestation protocol in which blockchain stored attestation data remains valid if the corresponding transaction/output is still present in the unspent transaction output cache. Smith teaches that storing information in an attestation transaction allows a party to check whether the transaction is still valid by looking in the UTXO cache, and that if the transaction can be found there, then the transaction, i.e., the attestation, is still valid (Smith ¶0149). Smith further teaches that revoking or updating attested data is performed by creating a new transaction and spending the old dust/output to a new address, which effectively revokes the old data because the old output has now been spent (Smith ¶0146). Smith also teaches that verifying that an attestation transaction has not been revoked may comprise checking to see if the attestation transaction exists in the UTXO cache (Smith ¶0232).
It would have been obvious to one of ordinary skill in the art to modify Guo’s blockchain based digital certificate verification system to incorporate Smith’s UTXO cache validity check, such that the verifier determines whether the certification transaction remains valid by checking whether the corresponding transaction output is still present in the UTXO pool/cache. Both Guo and Smith are directed to using blockchain records to verify trusted identity/certificate/attestation information and to determine whether such information remains valid or has been revoked. The combination merely applies Smith’s known UTXO based revocation/validity mechanism to Guo’s blockchain certificate verification framework to provide a tamper resistant and efficiently searchable way to determine whether the digital certificate remains valid, yielding predictable results.
Guo and Smith collectively teach a blockchain digital certificate verification system in which a verifier retrieves a certificate transaction record from a blockchain and verifies that the certificate remains valid by determining that the corresponding transaction/output has not been revoked. However, Guo and Smith do not explicitly teach that the first public key contained in the second output in the certification transaction matches the public key in the digital certificate. Hennebert teaches a Bitcoin transaction having multiple outputs, including a first output that creates a UTXO at a recipient wallet address and another output including an OP_RETURN script for recording data in the blockchain. Hennebert further teaches that the data recorded by the OP_RETURN script corresponds to a public key, and that a user scans the blockchain, accesses the transaction, and reads the public key from the transaction output (Hennebert ¶¶0030-0032, 0042-0043, 0053-0060).
It would have been obvious to one of ordinary skill in the art to modify the blockchain based certificate verification system of Guo and Smith to include Hennebert’s technique of recording a public key in a blockchain transaction output and reading that public key from the output, so that the verifier compares the public key stored in the certification transaction with the public key contained in the digital certificate. The combination would have predictably confirmed that the blockchain transaction being used for certificate verification corresponds to the same public key identified in the digital certificate, thereby improving the reliability of Guo and Smith’s blockchain-based certificate validation process.
Regarding Claim 2
Hennebert further discloses that an additional output, corresponding to the claimed second output, includes an OP_RETURN field that contains at least the first public key. Specifically, Hennebert teaches that the first blockchain transaction includes an output that creates a UTXO in the wallet of the second user, and that the output of the first transaction further comprises a script for recording the first ephemeral public key Pa in the blockchain (Hennebert: [0028]). Hennebert further teaches that the blockchain is typically Bitcoin and that the script for recording the first and second transactions contains an OP_RETURN operation, with the first and second ephemeral public keys being stored by the recording script in compressed form in the blockchain (Hennebert: [0042]). Hennebert also teaches that the transaction includes, on another output, at least one script for recording data in the blockchain, OP_RETURN <data>, where the data of the OP_RETURN script corresponds to the ephemeral public key Pa in compressed or complete form (Hennebert: [0056]-[0057]).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to incorporate Hennebert’s OP_RETURN field containing a public key into the combined Guo-Smith system. Hennebert expressly teaches that OP_RETURN may be used in a Bitcoin transaction output to record public-key data in the blockchain, and that a user may later scan the blockchain, access the transaction, and read the public key from the transaction output. A person of ordinary skill in the art would have recognized the desirability of using Hennebert’s OP_RETURN public-key storage technique in the combined system because Guo and Smith already verify certificate/attestation validity using blockchain transaction records, and storing the certificate public key in an OP_RETURN output would provide a predictable and publicly readable location for confirming that the blockchain transaction corresponds to the public key in the digital certificate.
Regarding Claim 3
Smith further discloses that the first output includes a pay-to-public-key-hash (P2PKH) operation referencing an address obtained as a hash of the second public key. Specifically, Smith teaches that an attestation address for a single signature transaction is generated by applying a second hash function to the public attest key, and that the second hash function may include the P2PKH algorithm (Smith: [0011], [0018]). Smith further teaches that the public attest key combines hashed attestation information with a public key, and that the attestation address is the address at which the transaction can be found on the distributed ledger, where for a single signature transaction, a hash function such as the P2PKH algorithm is applied to the public attest key to generate the attestation address (Smith: [0136]-[0138]).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to incorporate Smith’s P2PKH attestation address generation into the combined Guo-Hennebert system. Smith expressly teaches that a blockchain attestation address may be generated by applying a P2PKH hash function to a public attest key, thereby creating an address derived from public key information for locating and validating the attestation transaction on the distributed ledger. A person of ordinary skill in the art would have recognized the desirability of using Smith’s P2PKH address generation technique for the first output in the combined system because Guo and Smith already verify certificate/attestation validity using blockchain transaction records, and using a P2PKH address derived from public key information was a known and predictable Bitcoin mechanism for associating a spendable transaction output with the holder of the corresponding private key.
Regarding Claim 6
Smith further discloses revoking the digital certificate by generating a revocation transaction that includes, as an input, the first output of the certification transaction, and propagating the revocation transaction on the blockchain network. Specifically, Smith teaches a method of revoking a previously attested transaction by generating a signed revocation transaction and sending the signed revocation transaction to a centralized or distributed ledger, where the previously attested information was stored in an attestation transaction at an attestation address, and where revocation is performed by spending cryptocurrency associated with the attestation transaction (Smith: [0039]). Smith further teaches that a participant may revoke an attestation made in the past by signing a new transaction and spending the dust corresponding to the original attestation, and that the attestor may revoke the attestation by signing a transaction that spends the dust of the attestation using the attestor’s private key (Smith: [0189]). Smith also teaches that a new signed transaction is generated to revoke the previously attested information, the new signed transaction is sent over the network to the centralized or distributed ledger, and the revocation transaction revokes the attestation transaction by spending cryptocurrency associated with the attestation transaction (Smith: [0197]-[0198]).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to incorporate Smith’s signed revocation transaction into the combined Guo-Hennebert system, such that revoking the digital certificate includes generating a revocation transaction that spends the first output of the certification transaction and propagating the revocation transaction on the blockchain network. Smith expressly teaches that revocation of blockchain attested information is performed by generating and sending a signed revocation transaction to the ledger, where the revocation transaction spends the cryptocurrency/dust associated with the original attestation transaction. A person of ordinary skill in the art would have recognized the desirability of using Smith’s UTXO spending revocation mechanism in the combined system because Guo already teaches blockchain digital certificate verification and revocation, and Smith provides a known Bitcoin compatible way to revoke the prior certificate/attestation record by spending the prior transaction output, thereby causing the prior record to no longer remain valid.
Regarding Claim 7
Smith further discloses replacing the digital certificate with a new digital certificate for a new public key by creating a new certification transaction that includes, wherein the new certification transaction includes as an input the first output of the certification transaction. Specifically, Smith teaches that previously attested information may be removed or changed by generating a new attestation transaction that spends the cryptocurrency or dust associated with the existing attestation transaction, thereby revoking the previous attestation, and that if new information is to be attested, a new public attest key, new attestation address, and new signed attestation transaction are generated and broadcast to the ledger (Smith: [0199]). Smith further teaches that the new signed transaction is sent to the centralized or distributed ledger, thereby spending the cryptocurrency associated with the previous attestation transaction, and that if there is new information to attest to, a new public attest key is created using a hash of the new information combined with the user’s public key, a new attestation address is created, and a signed attestation transaction is broadcast to the centralized or distribution ledger.
Hennebert further discloses that the new certification transaction includes a first new output to a new address based on a third public key, and a second new output having the information field, wherein the information field contains a new public key. Specifically, Hennebert teaches that a blockchain transaction includes a first output comprising a recipient wallet address, an amount transferred to the recipient, and a locking script where the recipient can unlock the UTXO created by this output by presenting cryptographic elements required by the locking script including the recipient’s public key and signature (Hennebert: [0054]). Hennebert further teaches another output having an OP_RETURN script for recording data in the blockchain, where the OP_RETURN data may correspond to a public key (Hennebert: [0056]-[0057]).
Guo further teaches determining a new certification transaction identifier from hashing the new certification transaction. Specifically, Guo teaches generating a certificate transaction record corresponding to an operation request, writing the certificate transaction record into the blockchain, and generating a transaction identifier corresponding to the certificate transaction record (Guo: [0047], [0067]-[0072]). Guo and Smith further disclose propagating the new certification transaction on the blockchain network, wherein the new digital certificate includes the new public key and the new certification transaction identifiers. Specifically, Guo teaches writing the certificate transaction record into the blockchain and teaches that the target digital certificate incudes public key information, and that a node may obtain the transaction identifier and the target digital certificate to obtain the corresponding transaction record from the blockchain for certificate verification (Guo: [0059-0061], [0072]). Smith further teaches that the signed attestation transaction is broadcast to the centralized or distribution ledger when there is new information to attest to (Smith [199]).
It would have been obvious to one of ordinary skill in the art to modify Guo’s blockchain digital certificate system with Smith’s UTXO replacement technique and Hennebert’s transaction output structure. Guo teaches blockchain certificate transaction records and transaction identifiers, Smith teaches replacing previously attested information by spending the prior attestation transaction and creating a new attestation transaction for new information, and Hennebert teaches storing public-key data in an OP_RETURN transaction output. A person of ordinary skill in the art would have made the combination to provide a predictable blockchain-based certificate update mechanism in which the prior certificate transaction is invalidated by spending its output and the replacement transaction records the new public key and new transaction identifier for later verification.
Regarding Claim 8
Hennebert further discloses that the information field is an OP_RETURN output. Specifically, Hennebert teaches that the blockchain is typically Bitcoin and that the script for recording the first and second transactions contains an OP_RETURN operation, with the first and second ephemeral public keys being stored by the recording script in compressed form in the blockchain (Hennebert: [0042]). Hennebert further teaches that, alternatively, the first and second transactions comprise in output a second recording script, where the recording script and the second recording script contain OP_RETURN operations, with the first and second ephemeral public keys being stored by the recording scripts in complete form in the blockchain (Hennebert: [0043]). Hennebert also teaches that, on a third output, the transaction TA comprises at least one script for recording data in the blockchain, OP_RETURN , and that the OP_RETURN operation creates a provably unspendable entity which is not stored with the UTXO and cannot later be spent by means of an unlocking script (Hennebert: [0056]). Thus, Hennebert teaches an additional transaction output, corresponding to the claimed information field, implemented as an OP_RETURN output.
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to incorporate Hennebert’s OP_RETURN output into the combined Guo-Smith system. Hennebert expressly teaches that OP_RETURN may be used in a Bitcoin transaction output to record data in the blockchain, and that the OP_RETURN output creates a provably unspendable entity for storing data on-chain. A person of ordinary skill in the art would have recognized the desirability of using Hennebert’s OP_RETURN output in the combined system because Guo and Smith already verify certificate/attestation validity using blockchain transaction records, and using an OP_RETURN output would provide a known Bitcoin-compatible mechanism for storing publicly readable certificate-related information in the blockchain transaction without creating an additional spendable UTXO.
Regarding Claim 11 Claim 11 is directed to a computing device corresponding to the computer implemented method in claim 1. Claim 11 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 12 Claim 12 is directed to a computing device corresponding to the computer implemented method in claim 2. Claim 12 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 13 Claim 13 is directed to a computing device corresponding to the computer implemented method in claim 3. Claim 13 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 16 Claim 16 is directed to a computing device corresponding to the computer implemented method in claim 6. Claim 16 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 17 Claim 17 is directed to a computing device corresponding to the computer implemented method in claim 7. Claim 17 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 20 Claim 20 is directed to computer readable media instructions corresponding to the computer implemented method in claim 1. Claim 20 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Claims 4 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Guo (US 20200382326 A1), in view of Smith (US 20170317997 A1), in view of Hennebert (US 2019/0207757 A1) as applied to claims 1 and 11 above, and in further view of Jutla (US 20180048461 A1).
Regarding Claim 4
Regarding Claim 4, Guo, Smith, and Hennebert collectively teach blockchain certificate verification using a transaction identifier, UTXO validity, and transaction inputs/outputs containing public keys and signatures. However, Guo, Smith, and Hennebert do not expressly disclose wherein the certificate authority holds a second private key corresponding to the second public key. Jutla further discloses wherein the certificate authority holds a private key corresponding to a certificate authority public key. Specifically, Jutla teaches that a user registration service requests a PKI certificate associated with the user from a certificate authority (Jutla: [0121]). Jutla further teaches that the certificate is digitally signed with the certificate authority’s private key, and that, to confirm that the certificate is valid, has not been tampered with, and was issued by a valid certificate authority, the certificate authority’s published public key is used to verify the certificate authority certificate’s digital signature (Jutla: [0122]). Thus, Jutla teaches that the certificate authority holds/uses a private key corresponding to its published public key.
It would have been obvious to one of ordinary skill in the art to modify the combined Guo-Smith-Hennebert system to include Jutla’s certificate authority keypair arrangement, such that the certificate authority holds a second private key corresponding to the second public key. Guo already teaches blockchain-based digital certificate verification involving a certificate authority/authentication center, and Jutla provides the PKI technique of having a certificate authority sign certificates with its private key while verifiers use the corresponding certificate authority public key to verify the certificate authority signature. A person of ordinary skill in the art would have incorporated Jutla’s certificate authority keypair technique to confirm that the digital certificate was issued by a trusted certificate authority, thereby improving authenticity and trust in the blockchain certificate verification process.
Regarding Claim 14 Claim 14 is directed to a computing device corresponding to the computer implemented method in claim 4. Claim 14 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Guo (US 20200382326 A1), in view of Smith (US 20170317997 A1), and in view of Hennebert (US 2019/0207757 A1) as applied to claims 1 and 11 above, and in further view of Ebrahimi (US20180227130A1).
Regarding Claim 5
Guo, Smith, and Hennebert collectively teach blockchain certificate verification using a transaction identifier, UTXO validity, and transaction inputs/outputs containing public keys and signatures. However, Guo, Smith, and Hennebert do not expressly disclose wherein an input to the certification transaction further includes a certificate authority public key, and wherein verifying the digital certificate further includes determining that the certification transaction is signed by the certificate authority based on the certificate authority public key. Ebrahimi further discloses verifying a blockchain certification using a certifying entity public key. Specifically, Ebrahimi teaches signing generated hashed data using a private key of a certifying entity to create a signed certification, transmitting the signed certification to a blockchain, and receiving a certification transaction identifier (Ebrahimi: [0007]). Ebrahimi further teaches that a certifier creates a certification record with its own private key, where the certified data may be a digital signature of a hash signed with the private key of the certifier (Ebrahimi: [0043]). Ebrahimi also teaches that the certification record may include the transaction identifier, certification signature, and public key of the certifier, and that the certification record is signed using the private key of the certifier (Ebrahimi: [0056], [0081]-[0083]). Ebrahimi further teaches verifying the certification record by retrieving the signed certification record and the certifier’s public key and verifying that the digital signature was created with the certifier’s private key using the certifier’s public key (Ebrahimi: [0087]). Thus, Ebrahimi teaches a blockchain certification record that includes certifier public key information and is verified as being signed by the certifying entity based on the certifier public key,
It would have been obvious to one of ordinary skill in the art to modify the combined Guo-Smith-Hennebert system to include Ebrahimi’s certifier public key verification technique, such that the certification transaction includes the certificate authority public key and verification determines that the certification transaction was signed by the certificate authority based on that public key. Guo teaches blockchain based certificate verification using a certificate authority and blockchain transaction record, Smith teaches UTXO based validity, and Hennebert teaches transaction input/output structures containing public keys and digital signatures. Ebrahimi further teaches signing a blockchain certification record with a certifier’s private key and verifying the signed certification using the certifier’s public key. A person of ordinary skill in the art would have incorporated Ebrahimi’s technique to confirm that the certification transaction was authorized by the certificate authority, thereby improving authenticity and trust in the blockchain certificate verification process.
Regarding Claim 15 Claim 15 is directed to a computing device corresponding to the computer implemented method in claim 5. Claim 15 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Claims 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Guo (US 20200382326 A1), in view of Smith (US 20170317997 A1), and in view of Hennebert (US 2019/0207757 A1) as applied to claims 1 and 11 above, and in further view of Wright (US 20200005254 A1) and Ebrahimi (US20180227130A1).
Regarding Claim 9
Guo, Smith, and Hennebert collectively teach blockchain certificate verification using a transaction identifier, UTXO validity, and transaction inputs/outputs containing public keys and signatures. However, Guo, Smith, and Hennebert do not expressly disclose wherein the certification transaction includes an input referencing an unspent transaction outpoint address obtained from a hash of a certificate authority public key, wherein the certification transaction includes an unlocking script for the unspent transaction outpoint address that includes the certificate authority public key and the digital signature, and wherein the digital signature is generated based on a private key corresponding to the certificate authority public key. On the other hand, Wright discloses a UTXO transaction input referencing a prior transaction outpoint, an address/script obtained from a hash of public key information, and an unlocking script including digital signature and public key information. Specifically, Wright teaches that in a P2SH system, a common address may be based on public keys corresponding to the private keys used for signing (Wright: [0104]). Wright further teaches a first transaction having an input referencing a previous blockchain transaction and output index, and an output script of OP_HASH160 <hash160(redeem script)> OP_EQUAL, where the redeem script includes Alice’s public key and Bob’s public key and redeeming the output requires signatures corresponding to their private keys (Wright: [0106]-[0107]). Wright also teaches a payment transaction having an input referencing a previous hash and output index, a signature script including Alice’s signature, Bob’s signature, and a redeem script, and output scripts including OP_HASH160 <hash160(redeem script)> OP_EQUAL and OP_DUP OP_HASH160 <hash160(Alice’s public key)> OP_EQUALVERIFY OP_CHECKSIG (Wright: [0127]-[0130]). Wright further teaches that the payment transaction is signed with the first private key and requires the signature of the second private key because the payment transaction spends from the common address (Wright: [0121], [0126]-[0128]). Thus, Wright teaches the claimed UTXO input/outpoint, public-key-hash address/script, unlocking script, public key, and corresponding private-key signature mechanics.
Ebrahimi further discloses that the public/private key pair may be that of a certifying entity. Specifically, Ebrahimi teaches signing generated hashed data using a private key of the certifying entity to create a signed certification, transmitting the signed certification to a blockchain for storage, and receiving a certification transaction identifier (Ebrahimi: [0007]). Ebrahimi further teaches that a seal, such as a transaction identifier or blockchain pointer, along with the public key of the certifier, may be signed using the private key of the certifier to generate a certification signature, and that the certification record may include the certification signature and the public key of the certifier and be sealed in a blockchain (Ebrahimi: [0056]). Ebrahimi also teaches retrieving the signed certification record and the certifier’s public key from the public storage facility and verifying that the digital signature was created with the certifier’s private key (Ebrahimi: [0087]). Thus, Ebrahimi teaches using a certifier public key and corresponding certifier private key to sign and verify a blockchain certification record.
It would have been obvious to one of ordinary skill in the art to modify the combined Guo-Smith-Hennebert system to include Wright’s known UTXO unlocking script structure with Ebrahimi’s certifier public/private keypair. Guo, Smith, and Hennebert collectively teach blockchain certificate verification using transaction records, UTXO based validity, and transaction inputs/outputs containing public keys and signatures. Wright further teaches proving authority to spend a prior UTXO using public-key/signature information, and Ebrahimi teaches signing and verifying blockchain certification records using a certifier’s private key and corresponding public key. A person of ordinary skill in the art would have made the combination to ensure that the certification transaction was cryptographically authorized by the trusted certificate authority, thereby improving authenticity and preventing unauthorized transactions.
Regarding Claim 18
Claim 18 is directed to a computing device corresponding to the computer implemented method in claim 9. Claim 18 is similar in scope to claim 9 and is therefore rejected under similar rationale.
Claims 10 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Guo (US 20200382326 A1), in view of Smith (US 20170317997 A1), and in view of Hennebert (US 2019/0207757 A1) as applied to claims 1 and 11 above, and in further view of TREVETHAN (US 20200145231 A1).
Regarding Claim 10
Guo, Smith, and Hennebert collectively teach blockchain certificate verification using a certification transaction having transaction outputs and UTXO validity. However, Guo, Smith, and Hennebert do not expressly disclose wherein the first output includes a multi-sig locking script enabling any one of two or more private keys to utilize the first output. On the other hand, Trevethan discloses a multi-signature locking script for controlling access to a UTXO. Specifically, Trevethan teaches that blockchain validation may be performed by executing a transaction’s locking and unlocking scripts, and that a transaction is valid if the locking and unlocking scripts evaluate to TRUE (Trevethan: [0004]). Trevethan further teaches that Bitcoin’s multisig feature may set a condition in which N public keys are recorded in a locking script and at least M private keys, each associated with a respective one of the N public keys, must provide signatures to unlock the UTXO (Trevethan: [0005]). Thus, Trevethan teaches a multi-sig locking script for a UTXO that can be configured such that any one of two or more corresponding private keys may utilize the output.
It would have been obvious to one of ordinary skill in the art to modify the combined Guo-Smith-Hennebert system to include Trevethan’s known multi-signature locking script for the first output. Guo, Smith, and Hennebert collectively teach blockchain certificate verification using transaction outputs and UTXO validity, and Trevethan teaches using an M-of-N
multi-signature locking script to control access to a UTXO. A person of ordinary skill in the art would have made the combination to allow the certificate validity output to be controlled by any one of multiple authorized private keys, thereby improving flexibility and fault tolerance in managing certificate validity or revocation.
Regarding Claim 19 Claim 19 is directed to a computing device corresponding to the computer implemented method in claim 10. Claim 19 is similar in scope to claim 10 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD ABDULLAH whose telephone number is 571-272-1531. The examiner can normally be reached on Monday-Friday 9am-5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, LYNN FIELD can be reached on 571-272-2092.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights