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 .
Response to Amendment
The amendment filed June 9, 2026 has been entered. Claims 1-20 remain pending in the application.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under the Step 1 of the Section 101 analysis, Claims 1-10 are drawn to a method which is within the four statutory categories (i.e., a process), Claims 11-19 are drawn to a system which is within the four statutory categories (i.e. a machine), and Claim 20 is drawn to a non-transitory computer-readable medium which is within the four statutory categories (i.e., a manufacture).
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). Based on consideration of all of the relevant factors with respect to the claim as a whole, claims 1-20 are determined to be directed to an abstract idea. The rationale for this determination is explained below:
Regarding Claims 1, 11, and 20:
Claims 1, 11, and 20 are drawn to an abstract idea without significantly more. The claims recite “receiving, at a relay service, a request to execute a transaction on a blockchain, wherein the request comprises a request to transfer a quantity of non-native tokens on the blockchain from a transmitter wallet to a receiver wallet identified in the request and incurs a transaction overhead on the blockchain in native tokens, and wherein the transaction overhead in native tokens increases a computational expense involved in executing the transaction; modifying the request based on the quantity of non-native tokens, the transaction overhead in native tokens, and a policy defining a wallet from which the transaction overhead is to be retrieved; and executing the transaction on the blockchain based on the modified request without transferring native tokens from the transmitter wallet to satisfy the transaction overhead.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “relay service”, “blockchain”, “non-native tokens”, “wallet”, “native tokens”, and “computational expense” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical sales activities or behaviors, because the entities including the relay service, transmitter, and receiver interact with one another and execute a transaction according a policy.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A computer-implemented method, comprising:”, “A system, comprising: a memory having executable instructions stored thereon; and a processor configured to execute the executable instructions to cause the system to:”, “A computer-readable medium having instructions stored thereon which, when executed by a processor, performs an operation comprising:”, “relay service”, “blockchain”, “non-native tokens”, “wallet”, “native tokens”, and “computational expense”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claims 2-10 and 12-19:
Dependent claims 2-10, and 12-19 include additional limitations, for example, “non-native tokens”, “blockchain”, “native tokens” (Claims 2 and 12); “wallet”, “non-native tokens”, “native tokens”, and “blockchain” (Claims 3 and 13); “wallet” (Claim 4); “non-native tokens”, “blockchain”, “wallet”, and “native tokens” (Claims 5 and 14); “wallet” (Claims 6 and 15); “blockchain”, “non-native tokens”, “wallet”, and “native tokens” (Claims 7 and 16); “native tokens” and “wallet” (Claims 8 and 17); “native tokens” and “wallet” (Claims 9 and 18); “wallet” (Claims 10 and 19), but none of these limitations are deemed significantly more than the abstract idea because, as stated above, they require no more than generic computer structures or signals to be executed, and do not recite any Improvements to the functioning of a computer, or Improvements to any other technology or technical field.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation or implementing the judicial exception on a generic computer.
Therefore, whether taken individually or as an ordered combination, claims 2-10 and 12-19 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gonsalves (US 20240095721 A1) in view of Saraf (US 20230351353 A1).
Regarding Claims 1, 11, and 20, Gonsalves teaches A computer-implemented method, comprising (Gonsalves: Abstract): A system, comprising: a memory having executable instructions stored thereon; and a processor configured to execute the executable instructions to cause the system to (Gonsalves: Paragraph(s) 0022): A computer-readable medium having instructions stored thereon which, when executed by a processor, performs an operation comprising (Gonsalves: Paragraph(s) 0022):
receiving, at a relay service, a request to execute a transaction on a blockchain, wherein the request comprises a request to transfer a quantity of non-native tokens on the blockchain from a transmitter wallet to a receiver wallet identified in the request and incurs a transaction overhead on the blockchain in native tokens (Gonsalves: Paragraph(s) 0040, 0012, 0020; Abstract teach(es) the facility alters the smart contract by linking the smart contract to a gas station network, such as OpenGSN. A gas station network is a network of relayers that are used to sign and send cryptocurrency transactions. A relayer receives, signs, and submits transactions to the blockchain along with the gas fees required to execute the transaction; The facility applies the cryptocurrency wallet to the smart contract to associate the user with the smart contract and Web3 application. The facility generates one or more cryptocurrency transaction to facilitate the user's interaction with the Web3 application), and wherein the transaction overhead in native tokens increases a computational expense involved in executing the transaction (Gonsalves: Paragraph(s) 0020, 0040, 0012 teach(es) by using meta-transactions, such as those used on the Ethereum blockchain, the facility is able to significantly reduce gas fees and the time and computing resources necessary to obtain native tokens used for interacting with Web3 applications);
modifying the request based on the quantity of non-native tokens, the transaction overhead in native tokens, and a … defining a wallet from which the transaction overhead is to be retrieved (Gonsalves: Paragraph(s) 0040, 0042, 0012, 0019-0020 teach(es) the smart contract is altered such that a relayer associated with the gas station network deducts gas fees from the paymaster contract instead of from a user's cryptocurrency wallet; the cryptocurrency distribution entity is a “paymaster” that is able to alter and validate cryptocurrency transactions generated based on the smart contract; the cryptocurrency distribution entity has access to a plurality of native tokens that can be used for gas fees; the facility receives an indication from the user that a different wallet should be used to claim the cryptocurrency in the pool, and the facility causes the cryptocurrency in the pool to be transferred to the different wallet); and
executing the transaction on the blockchain based on the modified request without transferring native tokens from the transmitter wallet to satisfy the transaction overhead (Gonsalves: Paragraph(s) 0040, 0042, as stated above).
However, Gonsalves does not explicitly teach a policy defining a source from which the transaction overhead is to be retrieved.
Saraf from same or similar field of endeavor teaches a policy defining a source from which the transaction overhead is to be retrieved (Saraf: Paragraph(s) 0048, 0054, 0064, 0067-0068, 0039 teach(es) Merchant bot may receive preferences from merchant, such as currency preference (e.g. whether to receive payment in fiat currency, cryptocurrency, etc.), gas fee preferences, etc. and may implement those preferences).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Gonsalves to incorporate the teachings of Saraf for a policy defining a source from which the transaction overhead is to be retrieved.
There is motivation to combine Saraf into Gonsalves because Saraf’s teachings of gas fee preferences would facilitate a gas fee optimization (Saraf: Paragraph(s) 0039, 0048, 0054, 0068).
Regarding Claims 2 and 12, the combination of Gonsalves and Saraf teaches all the limitations of claims 1 and 11 above; and Gonsalves further teaches wherein modifying the request comprises modifying the quantity of non-native tokens to be transferred on the blockchain based on a quantity of non-native tokens that is determined to be equivalent to the transaction overhead in native tokens (Gonsalves: Paragraph(s) 0012 teach(es) users must obtain and use native tokens in order to interact with Web3 applications, or must convert existing tokens in their wallet into native tokens in order to use them to interact with Web3 applications. Conversion of native tokens, as well as regular interactions with Web3 applications, typically require the payment of “gas fees” in order to facilitate the transactions and interactions).
Regarding Claims 3 and 13, the combination of Gonsalves and Saraf teaches all the limitations of claims 1 and 11 above; and Gonsalves further teaches wherein executing the transaction comprises: identifying a first wallet from which the quantity of non-native tokens is to be retrieved; identifying a second wallet from which a quantity of non-native tokens that is determined to be equivalent to the transaction overhead in native tokens is to be retrieved; and performing the transaction on the blockchain based on the identified first wallet and the identified second wallet (Gonsalves: Paragraph(s) 0012, 0041, 0018-0019, 0040).
Regarding Claim 4, the combination of Gonsalves and Saraf teaches all the limitations of claim 3 above; and Gonsalves further teaches wherein the second wallet comprises a third-party wallet associated with neither the transmitter wallet nor the receiver wallet (Gonsalves: Paragraph(s) 0031, 0040-0041).
Regarding Claims 5 and 14, the combination of Gonsalves and Saraf teaches all the limitations of claims 4 and 13 and the policy above; and Gonsalves further teaches further comprising: incrementing a running total of non-native tokens used to satisfy transaction overheads on the blockchain for a party associated with the receiver wallet based on the quantity of non-native tokens that is determined to be equivalent to the transaction overhead in native tokens; determining a difference between the running total and an amount covered by the third-party wallet according to the …; and transferring the difference from the receiver wallet to the third-party wallet (Gonsalves: Paragraph(s) 0021, 0041, 0020, 0040 teach(es) Such computing resources include the processing, memory, and other computing resources which would ordinarily be required for the additional transactions needed to obtain native tokens, either by purchasing the tokens or by converting other cryptocurrency into the native tokens. Additionally, by using cryptocurrency pools, the facility is able to reduce the total number of cryptocurrency transactions needed to distribute cryptocurrency to users, thus reducing the processing power and fees required to generate and execute the cryptocurrency transactions).
Regarding Claims 6 and 15, the combination of Gonsalves and Saraf teaches all the limitations of claims 3 and 13 above; and Gonsalves further teaches wherein the second wallet comprises a same wallet as the first wallet (Gonsalves: Paragraph(s) 0019, 0041).
Regarding Claims 7 and 16, the combination of Gonsalves and Saraf teaches all the limitations of claims 6 and 15 above; and Gonsalves further teaches wherein executing the transaction on the blockchain comprises: transferring the quantity of non-native tokens from the transmitter wallet to the receiver wallet; transferring the quantity of non-native tokens that is determined to be equivalent to the transaction overhead in native tokens from the transmitter wallet to a third-party wallet that is neither the transmitter wallet nor the receiver wallet (Gonsalves: Paragraph(s) 0061-0062 teach(es) the facility receives an indication of multiple crypto currency wallets associated with the user. In such embodiments, the facility may receive an indication of which cryptocurrency rewards are to be transferred to each of the indicated wallets); and using a quantity of native tokens from the third-party wallet to cover the transaction overhead (Gonsalves: Paragraph(s) 0040-0041, 0031).
Regarding Claims 8 and 17, the combination of Gonsalves and Saraf teaches all the limitations of claims 1 and 11 and the policy above; and Gonsalves further teaches wherein the … specifies a proportion of the transaction overhead covered by transferring native tokens from the receiver wallet (Gonsalves: Paragraph(s) 0041, 0061-0062).
Regarding Claims 9 and 18, the combination of Gonsalves and Saraf teaches all the limitations of claims 1 and 11 above; however the combination does not explicitly teach wherein the policy specifies a maximum cumulative amount of transaction overheads covered over a defined time period by transferring native tokens from the receiver wallet.
Saraf further teaches wherein the policy specifies a maximum cumulative amount of transaction overheads covered over a defined time period by transferring native tokens from the receiver wallet (Saraf: Paragraph(s) 0039 teach(es) if the buyer opts in to gas fee optimization, the transaction may not occur if the gas fee is above a buyer-defined threshold, an average for a certain period of time, etc.).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Gonsalves and Saraf to incorporate the teachings of Saraf for wherein the policy specifies a maximum cumulative amount of transaction overheads covered over a defined time period by transferring the second type of token from the receiver wallet.
There is motivation to combine Saraf into the combination of Gonsalves and Saraf because Saraf’s teachings of gas fee preferences would facilitate a gas fee optimization (Saraf: Paragraph(s) 0039, 0048, 0054, 0068).
Regarding Claims 10 and 19, the combination of Gonsalves and Saraf teaches all the limitations of claims 1 and 11 and the policy above; however the combination does not explicitly teach wherein the policy comprises a policy defined for a party associated with the receiver wallet.
Saraf further teaches wherein the policy comprises a policy defined for a party associated with the receiver wallet (Saraf: Paragraph(s) 0048, 0054, 0064, 0067-0068, 0039 teach(es) Merchant bot may receive preferences from merchant, such as currency preference (e.g. whether to receive payment in fiat currency, cryptocurrency, etc.), gas fee preferences, etc. and may implement those preferences).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Gonsalves and Saraf to incorporate the teachings of Saraf for wherein the policy comprises a policy defined for a party associated with the receiver wallet.
There is motivation to combine Saraf into the combination of Gonsalves and Saraf because Saraf’s teachings of gas fee preferences would facilitate a gas fee optimization (Saraf: Paragraph(s) 0039, 0048, 0054, 0068).
Response to Arguments
Applicant's arguments filed June 9, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 101 that “The claimed methods and systems provide a solution to these problems, for example by modifying transaction requests involving native and non-native tokens such that non-native tokens need not be transferred from a transmitter wallet to satisfy the overhead” and “the claimed features are an improvement to computer functionality (e.g., by modifying transaction requests to coordinate coverage of the overhead in blockchain transactions such that non-native tokens need not be transferred from a transmitter wallet), and not merely commercial or legal interactions”, examiner respectfully argues that, as stated in the previous action, modifying a transaction request according to policy and executing the transaction without transferring certain type of tokens, as recited in the claims, can be performed manually and thus do not provide any improvements of the functioning of the computer or any other technology or technical field. The claims do not recite any technical details and contexts of how the non-native tokens, native tokens, blockchain, etc. solve any technical problems, let alone how they are defined with technical details and contexts. It is recommended for the applicant to amend the claims further with more technical details and contexts of additional elements such as native/non-native tokens, interaction of the service and users in a detailed real or more tangible transactions, etc., using the Specification ([0017]-[0018], for example).
Regarding applicant’s argument under Claim Rejections - 35 USC § 103 that “Gonsalves describes a “paymaster” smart contract that holds funds used to pay gas fees. Gonsalves [0040]v But a smart contract is not a wallet—rather, it is a program or protocol that manage transactions,” examiner respectfully argues that Gonsalves teaches that the cryptocurrency wallet is applied to the smart contract to associate the user with the smart contract and Web3 application (Gonsalves: Abstract). It is recommended for the applicant to amend the claims further with more technical details and contexts of policy, wallet, etc., for differentiating the features from the cited references.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sibbach (US 20240070316 A1) teaches Techniques For Providing A Privacy-Based Data Sharing Protocol, including gas fees, native, and conversion.
Gutierrez-Sheris (WO 2020252479 A1) teaches Systems And Methods Using Goodness-of-Fitness-Slope Blockchain Consensus, including fee tokens, sufficient native tokens, i.e. “gas” tokens, credits from unrelated third parties, or to acquire tokens from third-party sources using sender cash, using token fees known as “gas”, and smart contracts implementing non-terminating logic, “maximum fee” and/or “maximum gas” may be specified according to a pattern-connected record.
Sliwka (WO 2023172729 A1) teaches Configuration Of Game Smart Contracts Using Digital Tokens, Deferred Settlement Of Digital Tokens, And Lending Of Digital Tokens, including smart contract and gas fee.
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 CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
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, Neha Patel can be reached on (571)270-1492. 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699
Prosecution Insights