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
Status of Claims
Claims 1-20, are originally filed.
Claims 1-20, are cancelled
Claims 21-35, are newly added, therefore
Claims 21-35, are hereby examined.
Examiner’s Response
Drawing
The replacement drawings of figure 1-9 is acknowledged and hereby entered.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-33 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,223,501 (Craig Steven Wright), respectively. The claims at issue are not patentably distinct from each other as shown in bold in the table below. Dependent claims 22-35 are also rejected because they depend from independent claim 21.
Patent. No 12,223,501
Present Application:
19/005,476
Examiner’s Notes
1 and 16. A computer-based system operative to use Simplified Payment Verification to facilitate a blockchain transfer of an asset over a blockchain network between a transferor and a transferee, comprising:
i) a plurality of verification resources; and
ii) a coordination component operative to communicate with at least one verification resource and select the at least one verification resource from the plurality of verification resources; and wherein the at least one verification resource is arranged to:
a) receive using an off-chain communication that does not involve the blockchain or blockchain network:1) complete transaction data relating to at least one input blockchain transaction (Tx1) that comprises at least one output that spends to an input of a transfer transaction (Tx3); and
2) a Merkle path for the at least one input blockchain transaction (Tx1);
b) perform a Simplified Payment Verification check on the at least one input blockchain transaction (Tx1) using the complete transaction data and the Merkle path to prove that the input transaction (Tx1) that comprises the at least one output that spends to the input of the transfer transaction (Tx3) is valid and in the blockchain, and wherein the Simplified Payment verification check is performed locally on the at least one verification resource and does not go through the blockchain network; and
c) determine that the Simplified Payment Verification check proves that the input transaction is valid and in the blockchain; and
d) responsive to determining that the Simplified Payment Verification check proves that the input transaction (Tx1) is valid and in the blockchain, transmit the transfer transaction (Tx3) to the blockchain network for mining into a block on the blockchain to transfer the asset from the transferor to the transferee over the blockchain.
2, 8 and 17. wherein at least one verification resource in the plurality of verification resources comprises at least one public key that is associated with a private key, and wherein the private key is provided:
in the at least one verification resource; or in the coordination component.
11. wherein at least one of the providing resource or the verification resource is or comprises at least one of: a digital wallet, a cryptocurrency wallet, a Simplified Payment Verification Wallet or a smart card.
3 and 18. wherein the verification resource is operative to at least one of: verify whether a specified transaction is stored on a blockchain; or facilitate or enable a transfer from one address to another using a blockchain transaction.
4 and 19. wherein the coordination component is operative to cause the at least one verification resource to at least one of: verify whether a specified transaction is stored on a blockchain; or facilitate or enable a transfer from one address to another using a blockchain transaction.
5 and 20. wherein the coordination component is operative to send and receive transaction related data to and from a blockchain network.
6. wherein the coordination component is operative to: send and receive at least one of at least one public key or transaction ID (TXID) to and from the at least one verification resource.
7. wherein the private key is a seed.
9. wherein the at least one verification resource is operative to: i) use the Merkle path to verify a Merkle proof for the at least one transaction; or ii) store, receive and/or request at least one block header of a blockchain transaction.
10. wherein the complete transaction data or Merkle path are received and/or requested from a providing resource which is the transferor of the asset and is operative to store and/or send: i) complete transaction data relating to the at least one blockchain transaction; and ii) the Merkle path of the at least one blockchain transaction.
11. wherein at least one of the providing resource or the verification resource is or comprises at least one of: a digital wallet, a cryptocurrency wallet, a Simplified Payment Verification Wallet or a smart card.
12. wherein the computer- based system is operative to receive transfer data from a providing resource which is the transferor of the asset, the transfer data comprising at least one of: data relating to at least one unspent transaction output (UTXO) stored on a blockchain; a transaction ID (TXID) for a transaction containing the at least one unspent blockchain transaction output (UTXO); a signature for spending the at least one unspent blockchain transaction output (UTXO); a Merkle path for a transaction containing the at least one unspent blockchain transaction output (UTXO); or a public key address.
13. wherein the system is operative to at least one of:
i) send at least one of a transfer value or an output address to a providing resource; ii) receive at least one of a transfer value or an output address from a providing resource which is the transferor of the asset; or iii) submit a transaction to the blockchain network upon successful verification of the Merkle proof for the at least one blockchain transaction.
14. wherein the system is operative to send, to a providing resource which is the transferor of the asset, a request for transfer data comprising at least one of: data relating to at least one unspent transaction output (UTXO) stored on a blockchain; a transaction ID (TXID) for a transaction containing the at least one unspent blockchain transaction output (UTXO); a signature for spending at the at least one unspent blockchain transaction output (UTXO); a Merkle path for a transaction containing the at least one unspent blockchain transaction output (UTXO); or a public key address.
15. wherein the transfer data is requested by the system, and/or received from the providing resource, using a blockchain transaction template.
21. A system configured to facilitate a transfer of an asset between a transferor and a transferee over a blockchain maintained by a blockchain network, the system comprising:
at least one digital wallet in a plurality of digital wallets comprising at least one public key address of the transferee, and arranged to:
i) receive and/or request, from the transferor:
complete transaction data relating to at least one blockchain transaction (Tx1) comprising at least one unspent blockchain transaction output that spends to an input of a payment transaction (Tx3) that is arranged to transfer the asset to the payment address of the transferee; and
a Merkle path for the at least one blockchain transaction; and ii) use the complete transaction data and the Merkle path to perform a Simplified Payment Verification of the at least one blockchain transaction (Tx1);and
a coordination wallet operative to:
i) communicate with at least one verification resource; and
ii) store a private key associated with the at least one public key address of the transferee
(Moved down for mapping)
21…. at least one digital wallet in a plurality of digital wallets comprising at least one public key address of the transferee, and arranged to:
21... a coordination wallet operative to: i) communicate with at least one verification resource; and ii) store a private key associated with the at least one public key address of the transferee
22. wherein the at least one digital wallet is operative to: verify whether a specified transaction is stored on the blockchain; and/or facilitate or enable a transfer from one address to another using a blockchain transaction.
23. wherein the coordination wallet is operative to select one digital wallet from the plurality of digital wallets and cause it to: verify whether a specified transaction is stored on the blockchain; and/or facilitate or enable a transfer from one address to another using a blockchain transaction.
24. wherein the coordination wallet is operative to send and receive transaction related data to and from the blockchain network.
25., wherein the coordination wallet is operative to: send and receive at least one public key and/or transaction ID (TXID) to and from the at least one digital wallet.
26. wherein the private key is a seed.
27. wherein the at least one digital wallet is operative to: i) use the Merkle path to verify a Merkle proof for the at least one blockchain transaction; or ii) store, receive and/or request at least one block header of a blockchain transaction.
28. wherein the complete transaction data or Merkle path are received and/or requested from a providing resource which is the transferor of the asset and is operative to store and/or send: i) complete transaction data relating to the at least one blockchain transaction; and ii) the Merkle path of the at least one blockchain transaction.
29. wherein the coordination wallet or the at least one digital wallet is or comprises: a cryptocurrency wallet, a Simplified Payment Verification Wallet and/or a smart card.
30. wherein the system is configured to receive transfer data from a providing resource which is the transferor of the asset, the transfer data comprising: data relating to the at least one unspent blockchain transaction output (UTXO);a transaction ID (TXID) for a blockchain transaction containing the at least one unspent blockchain transaction output (UTXO);a signature for spending the at least one unspent blockchain transaction output (UTXO);a Merkle path for the transaction containing the at least one unspent blockchain transaction output (UTXO); or a public key address.
31. wherein the system is operative to: i) send a transfer value and/or an output address to a providing resource; and/or ii) receive a transfer value and/or an output address from a providing resource which is the transferor of the asset; and/or iii) submit a transaction to the blockchain network upon successful verification of the Merkle proof for the at least one blockchain transaction.
32. wherein the system is configured to send, to a providing resource which is the transferor of the asset, a request for transfer data comprising at least one of: data relating to the at least one unspent blockchain transaction output (UTXO);a transaction ID (TXID) for the transaction containing the at least one unspent blockchain transaction output (UTXO);a signature for spending at the at least one unspent blockchain transaction output (UTXO);a Merkle path for the transaction containing the at least one unspent blockchain transaction output (UTXO); and/or a public key address.
33. wherein the transfer data is requested by the system, and/or received from the providing resource, using a blockchain transaction template.
34. (New) The system of claim 21, wherein the coordination wallet maintains a mempool of unconfirmed blockchain transactions of the blockchain.
35. (New) The system of claim 21, wherein the at least one digital wallet is arranged to broadcast the payment transaction (Tx3) to the blockchain network if the Simplified Payment Verification of the at least one blockchain transaction (Tx1) is successful.
This preamble is essentially the same.
Moved down for mapping.
This limitation is essentially the same.
This limitation is essentially the same.
This limitation is essentially the same in reference to claims 2 and 11 of the parent application.
This limitation is essentially the same, the digital wallet is a verification resource.
This limitation is essentially the same.
This limitation is essentially the same.
This limitation is essentially the same.
This limitation is the same.
This limitation is essentially the same.
This limitation is the same.
This limitation is essentially the same.
This limitation is essentially the same.
This limitation is essentially the same.
This limitation is essentially the same.
This limitation is essentially the same.
This limitation is broader than the specification, as there is no support for this limitation in the specification, therefore has no patentable weight.
This limitation, though not claimed, but is supported by the specification of the parent patent application, see page 3 paragraphs 18-28.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL-The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 34 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Broader than the Specification
Claim 34 recites “The system of claim 21, wherein the coordination wallet maintains a mempool of unconfirmed blockchain transactions of the blockchain”. The Applicant’s specification does not provide support for these limitations. The mempool in the specification is in respect of having Master wallet to keep a local copy of the mempool, and the mempool was not defined for unconfirmed blockchain transactions, {see at least page 26 lines 21-33, “…SPV is replaced with a more powerful type of master wallet which also keeps its own copy of the mempool. The split-wallet architecture equipped with such a master wallet does not need to query the network to check if a customer's UTXOs are part of the current UTXO set. A master wallet with its own copy of the mempool functions similarly to a classical non- mining 'full node' client but, advantageously, it does not need to keep a full copy of the blockchain. Instead, this type of master wallet keeps only the block headers and its own local copy of the mempool. The copy of the mempool can either be constructed locally by synchronising with the network or sourced from a trusted third party or service. The implementation of the split-wallet using a master SPV wallet with its own copy of the menpool changes the merchant-customer interaction from the perspective of the merchant”}. Therefore, these limitation is broader that the specification as the mempool is not defined for storing unconfirmed blockchain transactions. (See LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1343-46, 76 USPQ2d 1724, 1730-33 (Fed. Cir. 2005) ("...it must describe the invention sufficiently to convey to a person of skill in the art that the patentee had possession of the claimed invention at the time of the application, i.e., that the patentee invented what is claimed.")).
Allowable Subject Matter
This application contains Allowable subject matter based on the similar claim limitation that are not patentably distinct from the Allowed parent patent application 12,223,501. Independent claim 21, recites Allowable limitation “use the complete transaction data and the Merkle path to perform a Simplified Payment Verification of the at least one blockchain transaction (Tx1);” Upon further search, Examiner is unable to find prior art that teaches this limitations.
Conclusion
The prior art made of record and not relied upon:
(US 20200126075 A1) – Fisch et al., Confidential Transaction Auditing
using an Authenticated Data Structure - relates to a system may automatically enforce policies on transactions by the asset manager, without relying on trusted managers and third-party auditing services. The system also preserves the confidentiality of information associated with users and fund managers (such as proprietary capital management strategies) beyond the fact that the fund is compliant with specified policies, and/or the non-existence of certain types of fraud.
2) (US 20200304518 A1) – Thekadath et al., Network Topology – relates to a method comprises creating, by the first data center computer, a first block for a first blockchain. The first block includes a first block header and first block body. The method also includes sending a message to a second data center computer indicating that the first block was created for the first blockchain. The message includes the first block header but not the first block body.
3) (US 20160191243 A1) – William Manning, Out-of-Band Validation of Domain Name System Records – relates to the field of information security, and in particular to techniques for out-of-band techniques for securing domain name information.
4) (US 2020/0014531 A1) Falco et al., Methods, Apparatus, and Systems for Controlling Internet-Connected Devices Having Embedded systems with Dedicated Functions – relates to controlling internet-connected devices having embedded systems with dedicated functions. A lightweight software that protects the internet - connected devices from security breaches and security threat is installed on the internet - connected devices. The lightweight software sends network traffic data to a management server via one or more rendezvous servers. The management server analyzes the network traffic data and generates a security update. The security update is posted on a blockchain. The lightweight software obtains the security update in the form of a blockchain transaction.
25. Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698