DETAILED ACTION
This is office action on the merits in response to the application filed on 02/26/2026.
Claims 1-24 have been filed by the applicant.
Claims 13-24 are currently amended.
Claims 1-24 are currently pending and have been examined.
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 .
Response to Argument
Double Patenting:
The applicant argues that Filter lacks “pulling digital assets from the source computing entity”. The examiner respectfully disagrees. Filter’s claim recites “initiating, by a user computing device of a digital asset payment network, a digital asset-based payment to a merchant computing entity of the digital asset payment network, wherein the user computing device pays with a digital asset, wherein the merchant computing entity accepts a desired asset, and wherein the digital asset-based payment includes a real-time digital asset-based payment process to provide the desired asset to the merchant computing entity”. In order for user computing device to pay a digital asset and process the payment, it has to pull assets from the user (i.e., source computing entity). Therefore, Filter does not lack the limitation.
The applicant further argues that Filter lacks “a transformer pool associated with a digital asset distributed ledger technology (DLT) network of the digital assets.” The examiner mistakenly miss the limitation. However, James still teach the limitation [Col6: 44-53, Col 8: 14-22].
The applicant argues that James does not teach “generating, by the digital asset-based interaction computing entity, a digital asset-based interaction request having instructions for pulling the digital assets based on a set of digital asset-based interaction inputs, wherein the set of digital asset-based interaction inputs includes at least some of the set of source inputs”. The examiner respectfully disagrees. James discloses generating a transaction request for digital asset transaction (Col 8: 5-14), which is the same as the limitation. In addition, as stated above, when the transaction is performed, the assets is pulled from one entity to another.
Rejection under 101:
101 rejection has been withdrawn based on amendment.
Rejection under 103:
The applicant argues that Deutscher discloses a traditional payment method instead of digital asset-based interactions as recited in the claim. The examiner respectfully disagrees. Deutscher discloses a process to making transaction and disclose similar steps of performing the transaction. Deutscher also discloses transaction may involve digital goods [0015]. Therefore, Deutscher discloses digital asset-based interactions. A reference is analogous art to the claimed invention if the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem) (MPEP 2141.01(a)).
The applicant argues that James does not teach “execute the digital asset-based interaction using a real-time process”. The applicant argues that James settles transaction in real-time (with any corresponding confirmation period), because “corresponding confirmation period” takes time. The examiner respectfully disagrees. In considering the disclosure of a reference, it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom (MPEP § 2144.01). Every transactions require confirmation at certain level, that does not make the process not real-time. A network delay could also result waiting which would still considered as a real-time transaction. In order to distinguish the claim from prior art, the applicant may provide evidence showing how the real-time in the claim is different from the real-time of James.
The applicant further argues that James does not teach “locking, by the digital asset-based interaction computing entity, an amount of system digital asset as collateral”. The examiner respectfully disagrees. James discloses the “lock identifier” is used to unlock the supply of tokens [Col 8: 14-22]. Therefore, James teaches the limitation.
The applicant argues that James does not teach “a transformer pool”. The examiner respectfully disagrees. In light of specification, “The transformer pool 26 is a smart contract (e.g., an Ethereum smart contract) that stores system digital assets” [0067]. James discloses sending transaction request to contract address [Col 8: 5-14]. James further discloses digital asset tokens are returned to smart contract [Col 10: 58-61]. James also discloses smart contract associated with assets in the transaction [Col6: 44-53]. Therefore, James teaches the limitation.
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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claim 1, 9, 11-13, 21 and 23-24 rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-2, 4, 11-12 and 14 of U.S. Patent No. 12141790 in view of James (US 10540654 B1).
Claim 1 of U.S. Patent No. 12141790 recites limitations of claim 1 of present application. Claim 1 of U.S. Patent No. 12141790 lacks “generating, by the digital asset-based interaction computing entity, a digital asset-based interaction request having instructions for pulling the digital assets based on a set of digital asset-based interaction inputs, wherein the set of digital asset-based interaction inputs includes at least some of the set of source inputs”. James (US 10540654) teaches “generating, by the digital asset-based interaction computing entity, a digital asset-based interaction request having instructions for pulling the digital assets based on a set of digital asset-based interaction inputs, wherein the set of digital asset-based interaction inputs includes at least some of the set of source inputs”. It would have been obvious to one of ordinary skill in the art, at the time of invention, to have modified the method to generate request, as taught by James (US 10540654) to prevent double-spending as James suggests [Col 40: 1-5].
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 6, 8-15, 18 and 20-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Deutscher (US 20200279237 A1), and further in view of James (US 10540654 B1).
With respect to claim 1 and 13:
Deutscher teaches (in italic):
accessing, by a source computing entity, a destination computing entity-presented user interface to initiate a digital asset-based interaction, wherein the digital asset-based interaction involves a digital asset-based interaction computing entity of a digital asset-based interaction system pulling digital assets from the source computing entity and a destination computing entity of the digital asset-based interaction system accepting desired assets. (In FIG. 2A, the merchant has implemented an “Express Checkout” option through the payment provider on the merchant site. Payment provider server 370 may be maintained, for example, by an online payment service provider which may provide payment between user 305 and the operator of merchant server 340. Advantageously, payment application 375 may be configured to interact with merchant server 340 on behalf of user 305 during a transaction with checkout application 355 to track and manage payment requests and purchases made by users using the rapid checkout option. [0028-0029 0045-0046])
providing, by the source computing entity, a set of source inputs to the digital asset-based interaction computing entity, via the destination computing entity-presented user interface. (If the user is paying with a payment provider, such as PayPal Inc. of San Jose, the user selects an appropriate button or link on the merchant page. The user is then presented with a login screen, either as a new page or a pop-up screen on the same page, requesting login information, such as a user identifier (e.g., user name, email address) and a password or PIN. [0016])
sending, by the digital asset-based interaction computing entity, the destination computing entity a notification of a successful digital asset-based interaction based on the generation of the digital asset-based interaction request. (If the payment can be approved, a notification is sent to the user and/or the merchant that the payment is approved or completed. A transaction number or identifier may accompany the notification. [0018])
Deutscher does not explicitly teach the following limitations. However,
James teaches:
wherein the digital asset-based interaction computing entity is operable to execute the digital asset- based interaction using a real-time process to provide the desired assets to the destination computing entity. (Transactions may be settled via the digital asset network in real-time (with any corresponding confirmation period) as they occur [Col 118: 32-34])
a nonreal-time process to verify the digital assets pulled from the source computing entity. (For example, the exchange bank account may hold a digital asset buyer's fiat currency until a digital asset seller transfers digital assets to a buyer, to an exchange, or to an authorized third party. Upon receipt by the appropriate recipient of the requisite amount of digital assets, the exchange may authorize the release of the fiat currency to the digital asset seller. [Col 108:20-42])
generating, by the digital asset-based interaction computing entity, a digital asset-based interaction request having instructions for pulling the digital assets based on a set of digital asset-based interaction inputs, wherein the set of digital asset-based interaction inputs includes at least some of the set of source inputs. ((A) generating, by the digital asset exchange computer system, a first transaction request including a first message comprising a first request to increase the total supply of the digital asset token to the third amount of digital asset tokens; (B) sending, by the digital asset exchange computer system, the first transaction request from the first designated public address to the fifth contract address; (C) sending, by the digital asset exchange computer system, the first transaction request from the fifth contract address to the second contract address. [Col 8: 5-14])
locking, by the digital asset-based interaction computing entity, an amount of system digital assets as collateral for the digital assets, wherein the amount of system digital assets is stored in a transformer pool associated with a digital asset distributed ledger technology (DLT) network of the digital assets. (obtaining, by the digital asset exchange computer system, a first unique lock identifier, based on reference to the blockchain [Col 8: 14-22])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as disclosed by Deutscher with the technique as disclosed by James to prevent double-spending as James suggests [Col 40: 1-5].
Claim 13, a computer readable memory with the same scope as claim 1, is rejected.
With respect to claim 2 and 14:
Deutscher further teaches wherein the destination computing entity-presented user interface is hosted by the digital asset-based interaction computing entity on the destination computing entity. (In FIG. 2A, the merchant has implemented an “Express Checkout” option through the payment provider on the merchant site. Payment provider server 370 may be maintained, for example, by an online payment service provider which may provide payment between user 305 and the operator of merchant server 340. Advantageously, payment application 375 may be configured to interact with merchant server 340 on behalf of user 305 during a transaction with checkout application 355 to track and manage payment requests and purchases made by users using the rapid checkout option. [0028-0029 0045-0046])
Claim 14, a computer product with the same scope as claim 2, is rejected.
With respect to claim 3 and 15:
Deutscher further wherein the destination computing entity-presented user interface is integrated into the destination computing entity. (In FIG. 2A, the merchant has implemented an “Express Checkout” option through the payment provider on the merchant site. Payment provider server 370 may be maintained, for example, by an online payment service provider which may provide payment between user 305 and the operator of merchant server 340. Advantageously, payment application 375 may be configured to interact with merchant server 340 on behalf of user 305 during a transaction with checkout application 355 to track and manage payment requests and purchases made by users using the rapid checkout option. [0028-0029 0045-0046])
Claim 15, a computer product with the same scope as claim 4, is rejected.
With respect to claim 6 and 18:
Deutscher further teaches wherein the accessing the destination computing entity-presented user interface comprises: accessing, by the source computing entity, the destination User device 310 may include one or more browser applications 315 which may be used, for example, to provide a convenient interface to permit user 305 to browse information available over network 360. [0041])
Claim 18, a computer product with the same scope as claim 6, is rejected.
With respect to claim 8 and 20:
Deutscher further teaches wherein the accessing the destination computing entity-presented user interface comprises: connecting, by the source computing entity, via an interface, to the destination computing entity, wherein the destination computing entity provides the destination computing entity-presented user interface via the interface. (In FIG. 2A, the merchant has implemented an “Express Checkout” option through the payment provider on the merchant site. Payment provider server 370 may be maintained, for example, by an online payment service provider which may provide payment between user 305 and the operator of merchant server 340. Advantageously, payment application 375 may be configured to interact with merchant server 340 on behalf of user 305 during a transaction with checkout application 355 to track and manage payment requests and purchases made by users using the rapid checkout option. [0028-0029 0045-0046])
Claim 20, a computer product with the same scope as claim 8, is rejected.
With respect to claim 9 and 21:
James further teaches wherein the set of digital asset-based interaction inputs includes a source identifier (ID) associated with the source computing entity, a digital asset-based interaction intention, and an amount of the digital asset-based interaction. (In embodiments, a method of increasing a total supply of digital asset tokens comprises the steps of: (a) providing a first designated key pair, comprising a first designated public key and a corresponding first designated private key, wherein the first designated public key also corresponds to a first designated public address associated with an underlying digital asset; wherein the underlying digital asset is maintained on a distributed public transaction ledger maintained in the form of a blockchain by a plurality of geographically distributed computer systems in a peer-to-peer network in the form of a blockchain network, and wherein the first designated private key is stored on a first computer system which is connected to the distributed public transaction ledger through the Internet [Col 6:24-36])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method with the technique as disclosed by James to prevent double-spending as James suggests [Col 40: 1-5].
Claim 21, a computer product with the same scope as claim 9, is rejected.
With respect to claim 10 and 22:
James further teaches wherein the generating the digital asset-based interaction request comprises: interpreting, by the digital asset-based interaction computing entity, the set of digital asset-based interaction inputs to produce an address associated with the source computing entity for accessing the digital assets. ((c) providing first smart contract instructions associated with a first smart contract associated with a digital asset token associated with a first contract address associated with the blockchain associated with the underlying digital asset, wherein the first smart contract instructions are saved as part of the blockchain for the underlying digital assets and include: (1) first delegation instructions to delegate one or more first functions associated with the digital asset token to one or more delegated contract addresses associated with the blockchain associated with the underlying digital asset [Col6: 44-53])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method with the technique as disclosed by James to prevent double-spending as James suggests [Col 40: 1-5].
Claim 22, a computer product with the same scope as claim 10, is rejected.
With respect to claim 11 and 23:
James further teaches:
wherein the real-time process comprises: obtaining, by the digital asset-based interaction computing entity, an amount of the digital assets from an address associated with the source computing entity. (obtaining, by a digital asset exchange computer system associated with a digital asset exchange, a list of designated public addresses and for each designated public address, a respective amount of the digital asset token. [Col 6: 24-67, Col 7: 1-67, and Col 8: 1-52])
exchanging, by the digital asset-based interaction computing entity, the amount of the digital assets to a substantially equivalent amount of the desired assets. (increasing the total supply of the digital asset token, by the digital asset exchange computer system, from a second amount to a third amount, wherein the difference between the third amount and the second amount is a fourth amount of digital asset tokens, wherein the fourth amount is either greater than the first amount or equal to the first amount [Col 7: 58-64])
providing, by the digital asset-based interaction computing entity, the amount of the desired assets to the destination computing entity. (assigning, by the digital asset exchange computer system in accordance with the list of designated public addresses and respective amount of digital asset token, each respective amount of digital asset token to each respective designated public address [Col 8:45-49])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method with the technique as disclosed by James to prevent double-spending as James suggests [Col 40: 1-5].
Claim 23, a computer product with the same scope as claim 11, is rejected.
With respect to claim 12 and 24:
James further teaches:
wherein the nonreal-time process comprises: connecting, by the digital asset-based interaction computing entity, to the digital asset DLT network to verify the obtaining the amount of the digital assets; when the amount of the digital assets is verified: releasing, by the digital asset-based interaction computing entity, the amount of system digital assets. (For example, the exchange bank account may hold a digital asset buyer's fiat currency until a digital asset seller transfers digital assets to a buyer, to an exchange, or to an authorized third party. Upon receipt by the appropriate recipient of the requisite amount of digital assets, the exchange may authorize the release of the fiat currency to the digital asset seller. [Col 108:20-42])
when the amount of the digital assets is not verified: consuming, by the digital asset-based interaction computing entity, at least a portion of the amount of system digital assets. (The exchange bank account may hold money in escrow while an exchange transaction is pending. [Col 108:20-42])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method with the technique as disclosed by James to prevent double-spending as James suggests [Col 40: 1-5].
Claim 24, a computer product with the same scope as claim 12, is rejected.
Claim(s) 4-5, 7, 16-17 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Deutscher" and "James" as applied to claim 1 and 11 above, and further in view of Stade (US 20160132869 A1).
With respect to claim 4 and 16:
Deutscher in view of James does not teach wherein the accessing the destination computing entity-presented user interface comprises: obtaining, by the source computing entity, a link from the destination computing entity via an interface, wherein the link provides the source computing entity access to the destination computing entity-presented user interface. However,
Stade teaches wherein the accessing the destination computing entity-presented user interface comprises: obtaining, by the source computing entity, a link from the destination computing entity via an interface, wherein the link provides the source computing entity access to the destination computing entity-presented user interface. (In another example embodiment, the user 101 scans a QR code or bar code or clicks a URL link on the user device 120, which temporarily associates the user device 120 to the online merchant system 110. [0022])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Deutscher in view of James to provide a link to user with the technique as disclosed by Stade to provide convenience.
Claim 16, a computer product with the same scope as claim 4, is rejected.
With respect to claim 5 and 17:
Deutscher further teaches wherein the link is a repeatable link usable by a plurality of source computing entities. (For example, the user may access a merchant site, seller site, marketplace site, or other site or mobile app that enables a user to shop and make a purchase. [0015])
Claim 17, a computer product with the same scope as claim 5, is rejected.
With respect to claim 7 and 19:
Deutscher in view of James does not teach wherein the accessing the destination computing entity-presented user interface comprises: accessing, by the source computing entity, the destination computing entity-presented user interface via a mobile application of the source computing entity associated with the destination computing entity. However,
Stade teaches wherein the accessing the destination computing entity-presented user interface comprises: accessing, by the source computing entity, the destination computing entity-presented user interface via a mobile application of the source computing entity associated with the destination computing entity. (For example, the user accesses a shopping application on an authorized user device and requests to “check out” [0013])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Deutscher in view of James to use merchant application with the technique as disclosed by Stade to provide convenience.
Claim 19 a computer product with the same scope as claim 7, is rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20210065156 A1: Embodiments provide methods, and server systems for enhancing online payment transaction experience. A method includes receiving, by a server system associated with a payment network, a tokenization request based on selecting a payment card of a plurality of payment cards of a user from a payment application running on a user device for processing an online payment transaction using the selected payment card at a merchant payment interface on the user device. The tokenization request includes a card information of the selected payment card. The method includes facilitating generation of a digital token. The digital token includes a tokenized card information of the selected payment card. The method includes provisioning the digital token in a floating widget at the merchant payment interface on the user device. The floating widget enables the user to enter the digital token at the merchant payment interface for processing the online payment transaction.
US 20180204195 A1: A system for a customer initiated payment transaction includes a mobile device of a customer, a merchant including merchant information and payment information, a multi-payment gateway, and a network. The mobile device includes a digital wallet, on which a customer may register one or more of a plurality of payment methods. Payment methods include credit card, debit card, virtual cards, cryptocurrency, and loyalty points.
US 20170193517 A1: Generally, embodiments of the invention are directed to methods, computer readable medium, servers and systems for enabling merchants to use hosted order pages (HOPs) and/or silent order posts (SOPs) and thereby avoid handling payment information and the costs associated Payment Card Industry (PCI) compliance, while at the same time utilize third-party fraud detection screens and thereby avoid costs associated with fraudulent transactions.
THIS ACTION IS MADE FINAL. 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 ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 8:30-5 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, 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.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights