DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/16/2026 has been entered.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on June 3, 2026 is being considered by the examiner.
Status of the Claims
This is a non-final Office Action rejection prepared in response to applicant’s amendment filed on 04/02/2026.
Claims 1, 8 and 15 are amended.
Claims 2, 4, 6-7, 9, 11, 13-14, 17 and 19-20 are cancelled.
Overall, claims 1, 3, 5, 8, 10, 12, 15-16 and 18 are pending and have been considered below.
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, 3, 5, 8, 10, 12, 15-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kumaraswamy (US 20200074518 A1), in view of Bosch (PE2E translation of WO 2021/245244 A2 published on 12/09/2021), in further view of Winklevoss (US 10269009 B1).
Regarding Claim 1, 8 and 15, Kumaraswamy discloses:
receiving, by a digital asset marketplace system, a first instruction from a buyer system to exchange a selected amount of a cryptocurrency from a buyer account for a digital asset from a seller account; (¶0055, The potential buyer may request to buy digital asset 110(1) and transmit that request through network 150 (e.g., requests 142). In one example request, the buyer may indicate account information for purchasing digital asset 110(1) and the number of copies the buyer is requesting. ¶0077, As illustrated in FIG. 2, user device 204, and more specifically digital wallet 208 may transmit a request to buy 214 to marketplace program 108. ¶0078, In various embodiments, request to buy 214 may include a request identifying the digital asset 110(2) and an indication that a user would like to purchase the digital asset, an identifier of the digital wallet 208 (e.g., an address of digital wallet 208), and a source of funds to purchase digital asset 110(2). ¶0097, At step 416, user device 404 transmits a request to buy the digital asset.)
generating, by the digital asset marketplace system, a smart contract within a blockchain network associated with the cryptocurrency based on the second instruction to transfer the digital asset and the third instruction to transfer the selected amount of cryptocurrency; (¶0056, Upon receiving the buyer request, the marketplace program 108 may access the terms of the offer for sale associated with digital asset 110(1) and construct a smart contract 124(1) that reflects the terms of offer for sale. The marketplace program 108 may deploy smart contract 124(1) (e.g., transaction 138) to the distributed ledger 120 (i.e., deploy the smart contract 124(1) to the distributed network 114). ¶0078, In response to receiving the request to buy 214, the marketplace program 108 may deploy a smart contract (e.g., smart contract 124(X)) to distributed network 114, to facilitate the exchange between buyer and seller in a manner described in FIG. 1. ¶0097, At step 418, marketplace 108 may deploy a smart contract to distributed network 134, where it is implemented as smart contract 124.)
in response to generating the smart contract, transferring, by the digital asset marketplace system, the selected amount of the cryptocurrency from the buyer account and the digital asset from the seller account to the smart contract; and (¶0050, In some embodiments, one or more additional smart contracts may be implemented as part of the digital data management system 122, as escrow 126. Executable code associated with escrow 126 may be added to the distributed ledger 120. During execution of a smart contract 124(1), 124(2), etc. in the digital data management system 122, escrow 126 may serve as a location at which a digital asset and funds are stored. In various embodiments, funds may represent one or more forms of agreed upon medium of exchange, such as currency. For example, funds may be an amount of dollars, Euro, ether, yen, bitcoins, etc. ¶0058, In response to deploying smart contract 124(1), marketplace program 108 may transfer digital asset 110(1) to escrow 126. Additionally, marketplace program 108 may transfer an amount of funds to escrow 126 (an amount of funds provided by the buyer). ¶0079, In particular, when marketplace program 108 transmits digital asset 110(2) to escrow 126, marketplace program 108 may access key management service 222 to retrieve one or more of the following: the digital asset (secured or locked), a private key (associated with buyer's digital wallet), and an encrypted key. In one example, the marketplace program 108 may receive a public key and address. Thus, during the example transaction, in response to receiving the request to buy 214, the marketplace program 108 may transmit the digital asset 110(2) to escrow (shown as digital asset 110(2)(a)) in an encrypted format that is also digitally signed in a secure manner using a seller's private key (e.g., private key 224).) ¶0098, At step 422, items including the digital asset and funds may be placed in escrow, such as escrow 126. The digital asset and funds may be transferred from a user device or the marketplace. ¶0107, In relation to a particular transaction, the escrow account may receive a digital asset (block 702). The digital asset may be transferred from the digital data marketplace or from a user device. The escrow account may also receive funds (block 704). The funds may be transferred from an account holding currency to the escrow account.)
in response to transferring the selected amount of cryptocurrency and the digital asset to the smart contract, executing, by the blockchain network, the smart contract, wherein executing the smart contract causes the blockchain network to perform: (abstract, facilitating the purchase of the digital asset at least in part by executing a smart contract on a distributed ledger. ¶0045, In various embodiments, the executable code may enable smart contract functionality within distributed network 114. Smart contract functionality may include a computer protocol intended to facilitate a transaction between two or more parties. The smart contract may play a role in digitally facilitating negotiations, verifying that individual parties to the smart contract fulfill respective ends of their contract, and enforcing performance of the contract.)
transferring, the selected amount of the cryptocurrency from the smart contract to the seller account; (¶0051, Escrow 126 may release the digital asset and the funds to respective parties in a transaction after particular conditions are met. For example, escrow 126 may release the digital asset and funds after a predetermined time period. As another example, escrow 126 may release the digital asset and funds after receiving or confirming that individual parties to a particular smart contract have fulfilled their respective obligations under the smart contract. ¶0059, In various embodiments, the digital asset 110(1) and the funds may remain in escrow 126 until smart contract 124(1) is able to verify that the terms defined in smart contract 124(1) have been fulfilled. ¶0062, Escrow 126 may make a determination to release both digital asset 110(1) and funds to the buyer and seller respectively based on one or more several factors. For example, escrow 126 may release the digital asset 110(1) to user device 112(1) based on, a determination that a predetermined amount of time has passed since digital asset 110(1) was placed in escrow 126. Escrow 126 may release the digital asset 110(1) in response to receiving a confirmation that all terms of the smart contract 124(1) have been fulfilled. In some embodiments, escrow 126 may release the digital asset 110(1) after confirming that the transaction has been recorded in distributed ledger 120. ¶0068, In other embodiments, marketplace program 108 may utilize smart contract 124(1) to complete the transaction, where variable storage 128(1) is updated with an address of the buyer, an address of the seller (e.g., digital wallet 118(1)), proof of ownership, and proof of purchase. ¶0081, In the event that both parties fulfill respective obligations, escrow 126 releases digital asset 110(2) (A) to digital wallet 208 (e.g., digital asset 110(2) (B)), and funds 220 to digital wallet 118(1). ¶0099, The escrow account (e.g., escrow 126) may check the distributed ledger 120 and in response to detecting that the transaction has been recorded in distributed ledger 120, at steps 428 and 430, escrow 126 releases the items in escrow to respective parties. For example, escrow may deliver the digital asset to user device 404 and escrow may deliver funds to user device 402. In another example, as discussed in FIG. 2, the escrow account may release the digital asset and funds after a predetermined time period. At step 432, smart contract 124 may record final states in distributed ledger 120 after the transaction is complete.)
Kumaraswamy does not disclose however Bosch teaches:
generating a non-retrievable address; wherein the non-retrievable address comprises a public address associated with the first blockchain network, and wherein generating the non-retrievable address comprises: generating the public address and a private key associated with the public address; and automatically discarding the private key to prevent provable ownership of the digital asset after transfer of the digital asset to the non-retrievable address (Bosch Page2¶4, For transferring money from the blockchain, special block chaining addresses could be provided, for example, to which payments can only be sent and of which it is not possible to send payments. For example, this could be blockchain addresses created by the central bank, which are assigned, for example, to the central bank. The corresponding blockchain addresses could also be associated with other legal or natural persons. For example, the central bank creates the corresponding blockchain addresses, destroys or deletes the respective private cryptographic keys, the signatures of which would be necessary for transactions from the corresponding blockchain addresses.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Kumaraswamy’s invention by incorporating Bosch’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to incorporate the use of a non-retrievable address achieved by deleting the private key which is a technique use to avoid the reuse of digital assets or tokens.
The combination of Kumaraswamy and Bosch do not disclose, however Winklevoss teaches:
in response to receiving the first instruction, transmitting, by the digital asset marketplace system, a second instruction to a seller system to transfer the digital asset from the seller account; (col 32 lines 8-17, In a step S3160, the exchange computer system may provide to a digital asset seller, an instruction to transfer digital assets to a digital wallet associated with the seller in an amount based at least in part upon the accepted digital asset quantity. In embodiments, the digital asset seller may transfer digital assets to a digital wallet associated with (e.g., owned by and/or operated by) the exchange. The exchange may hold such funds in escrow until the buyer's payment is received, e.g. into a bank account (for fiat currencies) or into a digital wallet (for other digital assets).)
in response to receiving the first instruction, transmitting, by the digital asset marketplace system, a third instruction to the buyer system to transfer the selected amount of the cryptocurrency from the buyer account; (col 25 lines 27-42, In a step S4856, the exchange computer system can provide to a customer user device a fiat funding interface. In a step S4858, the exchange computer system can receive from the customer user device, user selections for a funding source and/or funding method. The funding method may be a customer-initiated method, such as a wire transfer. In a step S4860, the exchange computer system can receive a funding amount value to transfer to an exchange account associated with the user. In a step S4862, the exchange computer system can provide to the customer user device fund transfer instruction, e.g., wire instructions. In a step S4864, the exchange computer system may receive an electronic indication of a customer-initiated fund transfer from a customer fiat bank account a customer bank to an exchange fiat account at an exchange partner bank according to the fund transfer instructions.)
generating confirmation message indicating that the digital asset was transferred to the non-retrievable address; and transmitting the confirmation message to the buyer system. (col 24 lines 8-16, In a step S4736, the exchange computer system can receive a confirmation of clearance of the digital asset transfer. In a step S4738, the exchange computer system can update an exchange customer account with the received digital assets. Updating an exchange customer account can include making an electronic entry in an exchange digital asset electronic ledger and/or providing a notification that the digital assets are received. Col 26 lines 67-69 & col 27 lines 1-7, In a step S4920, the exchange computer system may update the digital asset electronic ledger, e.g., by debiting the withdrawal amount from the customer's exchange account, to reflect confirmation of the withdrawal transaction. In a step S4922, the exchange computer system may provide to one or more customer user devices an electronic notification of the withdrawal. Such a notification can include at least the customer's new digital asset balance.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Kumaraswamy and Bosch combination by incorporating Winklevoss’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to request and ensure that both parties provide the corresponding assets and currency required as agreed to perform the transaction before proceeding with the completion of the transaction as well as to provide the user of a confirmation and a record that their transaction was processed successfully.
Regarding claim 5, 12 and 18, Kumaraswamy, Bosch and Winklevoss disclose each and every element of claim 1. Kumaraswamy further teaches:
wherein the smart contract is associated with a target time period, the target time period comprising a duration of time from a first time that the smart contract is generated to a second time that the smart contract is executed. (¶0051, For example, escrow 126 may release the digital asset and funds after a predetermined time period. ¶0066, In response to receiving one or more requests 142, the marketplace program 108 may reference previously deployed smart contract 124(1) to determine the terms of offer for sale as originally specified by the composer of digital asset 110(1). For example, the composer may have specified the maximum number of times that digital asset 110(1) is allowed to be resold, or the composer may have specified the number of copies that may be sold of digital asset 110(1). ¶0067, The marketplace program 108 or the digital data management system 112 may review the data stored in distributed ledger 120 to determine a number times a digital asset 110(1) has been resold, or the number of copies sold Smart contract 124(1) may validate that a transaction request may proceed.)
Claim(s) 3, 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kumaraswamy, Bosch and Winklevoss as applied to claim 1, 8 and 15 above, in further view of Khalil (US 20190139037 A1).
Regarding claim 3, 10 and 16, Kumaraswamy, Bosch, Winklevoss and Khalil disclose each and every element of claim 1. Khalil further teaches:
wherein transferring the selected amount of the cryptocurrency from the smart contract to the seller account comprises: determining that the smart contract has a sufficient amount of the cryptocurrency to transfer to the seller account; and transferring a portion of the selected amount of the cryptocurrency from the smart contract to the seller at each recurring period of a plurality of recurring periods within a duration. (¶0062, At the end of the periodic eon, the online server SH broadcasts a checkpoint CHeon 313, 309, 310 which aggregates all of the account balances of all of the users which have transacted over the payment hub's online server SH The smart contract SCH receives, validates and applies checkpoint CHeon to the user balances on-chain. A periodic eon is a repeating time interval at which the payment hub operates.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Kumaraswamy, Bosch and Winklevoss combination by incorporating Khalil’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to reduce transaction failures and mitigate loss risks.
Response to Arguments
Claim Rejections – 35 U.S.C. § 103
Applicant's arguments filed 04/02/2026 have been fully considered but they are not persuasive.
First, as noted during the interview the prior art continues to read on the claims and the instructions sequence claimed is disclosed by the cited prior art. Further, even if a single reference does not explicitly disclose a specific sequence, such sequence may be suggested by a secondary art, and the examiner may rely on a combination of references to establish obviousness.
Second, the applicant argues that “a person skilled in the art at the time of the invention was made would not have been motivated or otherwise have an apparent reason to combine Bosch with Kumaraswamy or Winklevoss to arrive at the claimed subject matter as suggested by the Office Action. See, e.g., M.P.E.P. § 2143.01. Rather, Bosch describes transferring money from the blockchain by providing "special blockchain addresses.. to which payments can only be sent and from which it is not possible to send payments." Bosch, Page 2. In contrast, Kumaraswamy states that "the digital asset and the funds" may be released "to respective parties in a transaction after particular conditions are met." Kumaraswamy, para. [0051]. Similarly, Winklevoss states that "a digital asset seller transfers digital assets to the buyer," and explains "effectively transferring ownership of the seller's traded digital math-based assets to the buyer." Winklevoss, col. 19, I. 25; col. 29; II. 28-29. Thus, both Kumaraswamy and Winklevoss explicitly describe transferring the digital asset to the buyer. Combining Bosch with Kumaraswamy or Winklevoss as suggested in the Office Action would render Kumaraswamy or Winklevoss unsatisfactory for its intended purpose because such combination would prevent the buyer from receiving the digital asset and having ownership the digital asset.” The examiner respectfully disagrees with the applicant’s argument. The applicant’s argument that the combination is improper because the references are used for different purposes is not persuasive. An obviousness analysis does not require that a reference disclose an entire transaction process or architecture. It is sufficient that the references teach a known feature that can be reasonably combined with other references to achieve the claim invention. Further, the applicant is improperly characterizing the examiner’s reliance on the cited reference. The examiner relies on Kumaraswamy for “the main smart contact based transaction workflow”, in Bosch for the teaching of the “non retrievable address” and in Winklevoss for the “ transmitting the first and second instructions to the seller and buyer”. These teachings are applied to specific claim limitations and not as a substitution for an entire system. Therefore, the cited prior art combination continue to read on the amended claims and the 103 rejection from the prior final rejection is maintained.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
US 12047512 B1 to Kurani et al. discloses: Systems, methods, and computer-readable storage media of wrapping digital assets. One method includes receiving, from a central provider system, a digital asset signed by a central private key associated with a digital asset on a central ledger, and verifying the digital asset based on a central public key. The method further includes updating the digital asset including an assignee field, and receiving an attribute for a second assignee of the digital asset. The method further includes wrapping utilizing the private key of the public and private key pair, the digital asset with the attribute and receiving environmental data. The method further includes determining the at least one condition of the attribute is satisfied, and updating the assignee field.
US 20200044831 A1 to Soundararajan et al. discloses: receiving an encrypted message from an entity, the encrypted message including a request to determine if a claimant of a distributed attestation is a holder of the distributed attestation; decrypting the encrypted message; using at least a public key of the entity to determine whether the entity is authorized to obtain information about the distributed attestation; and if the entity is authorized to obtain information about the distributed attestation, transmitting a response message to the entity indicating if the claimant of the distributed attestation is the holder of the distributed attestation. Authorization of the entity to obtain information about the distributed attestation may be based on role based access control rights to obtain information about the distributed attestation.
US 20180189730 A1 to Wilkinson et al. discloses: In some embodiments, apparatuses and methods are provided herein useful to manage reservations and deliveries for a docking station. More specifically, the various embodiments described herein track spaces on a docking station to determine whether one or more spaces are available when requested by a delivery device. Each space on the docking station has a corresponding capacity unit for each location on the docking station. The transactions for the capacity units are tracked in a ledger, with available capacity units indicating an open location on the docking station or contracted out capacity units indicating that either the location has a locker secured thereto or that the location is reserved for a future delivery.
US 20240261692 A1 to Sliwka discloses: The disclosure relates in part to systems and methods that facilitate interactions between video game environments and blockchain environments. In embodiments, a method may be performed by a game application. The method includes detecting a user action involving an in-game item associated with a token stored on a blockchain; calling a wallet connection function of a blockchain SDK that connects the user' in-game account to a digital wallet that manages the user's blockchain account; retrieving a public address for the blockchain account; calling a transaction function of the SDK that generates a blockchain transaction signature request requesting a digital signature using credentials of the user's blockchain account; transmitting the signature request to the wallet application; receiving indication from the integrated blockchain SDK that the blockchain transaction has been added to the blockchain; and in response to the indication, performing the user action involving the in-game item within the gaming application.
US-20230036852-A1 to A computer-implemented method of using blockchain transactions to issue one or more single-uses tokens for use by one or more respective token redeemers, wherein the method is performed by a token issuer and comprises: generating a token transaction, wherein the token transaction comprises: one or more token outputs, wherein each token output comprises token data representing a respective single-use token, wherein each single-use token is associated with a respective spendable output of the token transaction, and wherein a respective validity of each single-use token is conditional on the respective spendable output being present in an unspent transaction output set of a blockchain; and one or more inputs, wherein at least a first one of the inputs comprises a signature linked to a first public key of the token issuer; and transmitting the token transaction to one or more nodes of a blockchain network to be recorded in the blockchain.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached on (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 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.
/J.L./Examiner, Art Unit 3698 /STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights