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 .
Drawings
The drawings submitted on July 14, 2025 are acceptable.
Election/Restrictions
Restriction to one of the following inventions is required under 35 U.S.C. 121:
Invention I. Claims 1-18 and 25, is drawn to a method, system and medium that receives gas sponsorship for an operation, determines operation should be sponsored, generates a cryptographic signature and validates the signature, classified G06Q 20/401.
Invention II. Claim 19-24 and 26, is drawn to a method, system and medium that provides user interface, receives inputs, configures spending control parameters, address control parameters, determines temporal control parameters, validates a policy configuration, stores and associates the policy, implements API mechanisms and provides policy management tools, classified G06F 9/547.
The inventions are independent or distinct, each from the other because:
Inventions I and II are related as subcombinations disclosed as usable together in a single combination. The subcombinations are distinct if they do not overlap in scope and are not obvious variants, and if it is shown that at least one subcombination is separately usable. In the instant case, invention I has separate utility such as receives gas sponsorship for an operation, determines operation should be sponsored, generates a cryptographic signature and validates the signature. Invention II has separate utility such as provides user interface, receives inputs, configures spending control parameters, address control parameters, determines temporal control parameters, validates a policy configuration, stores and associates the policy, implements API mechanisms and provides policy management tools. See MPEP § 806.05(d).
The examiner has required restriction between subcombinations usable together. Where applicant elects a subcombination and claims thereto are subsequently found allowable, any claim(s) depending from or otherwise requiring all the limitations of the allowable subcombination will be examined for patentability in accordance with 37 CFR 1.104. See MPEP § 821.04(a). Applicant is advised that if any claim presented in a divisional application is anticipated by, or includes all the limitations of, a claim that is allowable in the present application, such claim may be subject to provisional statutory and/or nonstatutory double patenting rejections over the claims of the instant application.
Restriction for examination purposes as indicated is proper because all the inventions listed in this action are independent or distinct for the reasons given above and there would be a serious search and/or examination burden if restriction were not required because one or more of the following reasons apply:
the inventions have acquired a separate status in the art in view of their different classification;
the inventions have acquired a separate status in the art due to their recognized divergent subject matter; and/or
the inventions require a different field of search (e.g., searching different classes/subclasses or electronic resources, or employing different search strategies or search queries).
Applicant is reminded that upon the cancelation of claims to a non-elected invention, the inventorship must be corrected in compliance with 37 CFR 1.48(a) if one or more of the currently named inventors is no longer an inventor of at least one claim remaining in the application. A request to correct inventorship under 37 CFR 1.48(a) must be accompanied by an application data sheet in accordance with 37 CFR 1.76 that identifies each inventor by his or her legal name and by the processing fee required under 37 CFR 1.17(i).
A telephone call was made to Attorney of record Myrna Schelling on February 3, 2026 to request an oral election to the above restriction requirement. Applicant elected group I, comprising claims 1-18 and 25 without traverse. Claims 19-24 and 26 are withdrawn from consideration pursuant to 37 CFR 1.142(b) as being drawn to nonelected inventions, there being no allowable generic linking claim.
Claim Interpretation
Contingent Limitations:
Regarding claim 1: The portion which recites “generating, when the transactions or user operations is determined to qualify for sponsorship, a cryptographic authentication signature that authorizes gas fee coverage for the transaction or user operation; ”, is conditional language that not necessarily will happen since in these claims, the generating is only required when “…the transactions or user operations is determined to qualify for sponsorship”. MPEP 2111.04 II
Regarding claim 3: The portion which recites “updating the off-chain gas sponsorship policy status from pending to finalized upon detection of successful transaction inclusion in confirmed blockchain blocks.” is conditional language that is only required upon “upon detection of successful transaction inclusion in confirmed blockchain blocks. MPEP 2111.04 II
Regarding claim 8: The portion which recites “determining that the transaction or user operation qualifies for sponsorship when the confidence score meets or exceeds the configurable confidence threshold for the identified operation type.” is conditional language that is only required when “the confidence score meets or exceeds the configurable confidence threshold for the identified operation type”. MPEP 2111.04 II
See MPEP 2111.04 II. “[t]he broadest reasonable interpretation of a system claim having structure that performs a function, which only needs to occur if a condition precedent is met, still requires structure for performing the function should the condition occur." Schulhauser at 14. Therefore "[t]he Examiner did not need to present evidence of the obviousness of the [ ] method steps of claim 1 that are not required to be performed under a broadest reasonable interpretation of the claim (e.g., instances in which the electrocardiac signal data is not within the threshold electrocardiac criteria such that the condition precedent for the determining step and the remaining steps of claim 1 has not been met);" however to render the claimed system obvious, the prior art must teach the structure that performs the function of the contingent step along with the other recited claim limitations. Schulhauser at 9, 14.”
Non-Functional Language:
Regarding claims 1, 12 and 25:
The phrase "…that authorizes gas fee coverage for the transaction or user operation;” is non- functional descriptive material as it only describes the cryptographic authentication signature.
Regarding claims 2 and 13:
The phrase “…that routes sponsorship requests from external applications;” is non-functional descriptive material as it only describes, at least in part, the API gateway. The claim merely describes what the API gateway could be used for. This phrase does not affect how the positively recited steps are performed nor does it provide an operational connection to the rest of the claim.
Regarding claim 6: The phrase “…that receives incoming sponsorship requests and validates the requests through the API gateway;” is non-functional descriptive material as it only describes the initial request processing phase.
The phrase “…that enforces business rules and generates cryptographic commitments;” is non-functional descriptive material as it only describes the policy evaluation and authorization phase.
The phrase “…that tracks transaction or user operation confirmations and manages final billing.” is non-functional descriptive material as it only describes the blockchain monitoring and settlement phase.
Regarding claim 14: The phrase “…that receives incoming sponsorship requests and validates the requests through the API gateway;” is non-functional descriptive material as it only describes the initial request processing phase.
The phrase “…that assign dynamic spending limits corresponding to each user's revenue category,” is non-functional descriptive material of the automated fund allocation systems. For example, claim merely describes what the automated fund allocation systems is capable to do.
Regarding claim 15: The phrase “…that detect malicious activity patterns and implement automated safeguards to protect sponsored funds” is non-functional descriptive material as it only describes the adaptive learning modules. For example, claim merely describes what the adaptive learning module is capable to do.
Regarding claim 17: The phrase “…that serves multiple developers to minimize purchase costs and ensure continuous availability for covering the gas fees” is non-functional descriptive material, as it only describes the ETH pool.
It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Examiner has provided prior art, where available, for these intended use and/or non-functional phrases/limitations, however, these phrases/limitations will not distinguish the invention from the prior art in terms of patentability. Accordingly, the prior art is only provided in the interest of compact prosecution.
Intended use/ Result Language:
Regarding claim 3: The phrase “… such that only requests from the designated application API key are
accepted;” is the intended use of associating the off-chain gas sponsorship policy with a designated application key.
Regarding claim 7: The phrase “…for inclusion in the transactions or the user operations” is intended use/result of providing paymaster and data fields.
Regarding claim 8: The phrase “…to identify an operation type;” is intended use/result of providing analyzing blockchain transaction data of the transactions or user operations using machine learning algorithms.
Regarding claim 9: The phrase “…to predict optimal timing for purchasing ETH;” is intended use/result of analyzing historical spend rates and market conditions using machine learning algorithms. For example, applicant does not positively recite the step of predicting optimal timing.
The phrase “…to minimize purchase costs and ensure continuous availability for covering the gas fees is intended use/result of maintaining a shared ETH pool.
Regarding claims 10 and 18: The phrase “…to predict when funds available for covering gas fees will be depleted;” is intended use/result of analyzing sponsorship usage patterns using adaptive learning algorithms. For example, applicant does not positively recite the steps of predicting funds available.
Regarding claim 11: The phrase “…to establish normal behavior baselines using adaptive learning modules;” is intended use/result of analyzing sponsorship usage patterns using adaptive learning algorithms. For example, applicant does not positively recite the steps of predicting funds available.
Regarding claim 14: The phrase “…for dynamic fund allocation based on user revenue potential, the machine learning algorithms comprising” is intended use of implementing machine learning algorithms. The claim merely describes what the machine learning algorithms could be used for.
The phrase “…to predict each user's future revenue generation capability, classification algorithms that categorize users into revenue potential tiers based on their predicted value to the application;” is the intended use of analyzing user behavioral patterns, transaction and historical revenue contributions. The claim merely describes what the adaptive learning module could be used for.
Regarding claim 15: The phrase “…to establish normal behavior baselines; detect anomalies in spending velocity, transaction or user operation frequency, and usage amounts;” is the intended use/result of monitor user spending patterns.
Regarding claim 16: The phrase “…to identify a transaction or user operation type;” is the intended use/result of analyze transaction data.
These portions are given no patentable weight because the limitations, or portions thereof, do not claim the functions as being positively recited actions or functions, and/or they do not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being "for ... [performing a specific functionality]", etc. does not mean that the functions are required to be performed, or are actually performed.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1-18 and 25 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In claim 14, is not clear whether this term “the application” refers to the previously recited term “a developer application” in claim 12.
Antecedent Basis Issues:
Regarding claim 1:
The term “the transactions or user operations” lacks of antecedent basis.
The term “the requested transactions or user operations” lacks of antecedent basis.
The term “the off-chain gas sponsorship policy” lacks of antecedent basis.
The term “the transaction or user operation;” lacks of antecedent basis.
The term “the authentication signature” lacks of antecedent basis.
The term “the authorized transactions or user operations” lacks of antecedent basis.
Regarding claim 2:
The term “the transactions or user operations” lacks of antecedent basis.
The term “the off-chain gas sponsorship policy” lacks of antecedent basis.
Regarding claim 3:
The term “the off-chain gas sponsorship policy” lacks of antecedent basis.
Regarding claim 7:
The term “the transactions or user operations” lacks of antecedent basis.
Regarding claim 8:
The term “the identified transaction or user operation” lacks of antecedent basis.
The term “the transactions or user operations” lacks of antecedent basis.
Regarding claim 12:
The term “the off-chain gas management policy” lacks of antecedent basis.
Regarding claim 13:
The term “the off-chain gas management policy” lacks of antecedent basis.
Regarding claim 17:
The term “the native token of the blockchain” lacks of antecedent basis.
Dependent claims 2-11 and 13-18 are also rejected under 35 USC 112(b) at least for their dependency to claims 1 and 12.
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-18 and 25 are rejected under 35 U.S.C. 101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., an abstract idea) and does not provide an integration of the recited abstract idea into a practical application nor include an inventive concept that is “significantly more” than the recited abstract idea to which the claim is directed. MPEP §2106.
In determining subject matter eligibility in an Alice rejection under 35 U.S.C. §101, it is first determined as Step 1 whether the claims are directed to one of the four statutory categories of an invention (i.e., a process, a machine, a manufacture, or a composition of matter). MPEP §2106.03.
Here, the claims are directed to the statutory category of a method/process (Claims 1-11), a machine (claims 12-18) and a manufacture (claim 25). Therefore, we proceed to Step 2A, Prong 1. MPEP §2106.
Under a Step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more enumerated categories of patent ineligible subject matter that amounts to a judicial exception to patentability. MPEP §2106.04. Independent Claim 1 is selected as being representative of the independent claims in the instant application. Claim 1 recites:
A method, comprising:
receiving, via a sponsorship API, a gas sponsorship request for a user operation from a developer application;
determining, by evaluating the transactions or user operations against a developer's off-chain gas transaction management policy, whether the requested transactions or user operations should be sponsored, the off-chain gas sponsorship policy comprising configurable rules including spending limits, address controls, and temporal parameters;
generating, when the transactions or user operations is determined to qualify for sponsorship, a cryptographic authentication signature that authorizes gas fee coverage for the transaction or user operation;
and
validating, via an ERC-4337 verifying paymaster contract, the authentication signature prior to covering gas fees for the authorized transactions or user operations.
Here, the claims recite an abstract idea, or combination of abstract ideas of determine, based on policies, whether to sponsor a user operation and generate a signature that authorizes the sponsorship. This concept/abstract idea, which is identified in the bolded sections seen above, falls within the Certain Methods of Organizing Human Activity grouping because it describes a commercial or legal interactions (e.g., determine whether to sponsor a transaction).
Accordingly, it is determined that the claims recite an abstract idea since they fall within one or more of the three enumerated categories of patent ineligible subject matter. MPEP §2106.04.
Since it is determined that the claim(s) contain a judicial exception, it must then be determined, under Step 2A, Prong 2, whether the judicial exception is integrated into a practical application of the exception. MPEP §2106.04. In order to make this determination, the additional element(s) are analyzed to determine if the claim as a whole integrates the recited judicial exception into a practical application of that exception.
As indicated in the “Claim Interpretation” section seen above, the portion which recites “generating, when the transactions or user operations is determined to qualify for sponsorship, a cryptographic authentication signature that authorizes gas fee coverage for the transaction or user operation; ”, is conditional language that not necessarily will happen since in these claims, the generating is only required when “…the transactions or user operations is determined to qualify for sponsorship”. MPEP 2111.04 II. Furthermore, the phrase "…that authorizes gas fee coverage for the transaction or user operation;” is non- functional descriptive material as it only describes the cryptographic authentication signature. Accordingly, these phrases are not required in the claims. However, for the purposes of compact prosecution, examiner will evaluate the claim including these phrases.
Beyond these conditional limitation and non-functional phrases, claim 1 recites the additional elements of a sponsorship API, a developer application and an ERC-4337 paymaster contract. Independent claim 12 recites the additional elements of a system, a processor, a memory a sponsorship API, a developer application and an ERC-4337 paymaster contract. Independent claim 25 recites the additional elements of a non-transitory computer-readable storage medium, one or more processors, a sponsorship API, a developer application and an ERC-4337 paymaster contract. These additional elements are all recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception, or a portion thereof, using a generic computer component. See MPEP 2106.05(f). Additionally, Examiner finds no indication in the Specification, that the operations recited in the independent claims require any specialized computer hardware or other inventive computer components, i.e., a particular machine, invoke any allegedly inventive programming, or that the claimed invention is implemented using other than generic computer components to perform generic computer functions. Furthermore, there is no indication in the claim(s) that the use of non-transitory computer-readable medium, a system, a processor, a memory a sponsorship API, a developer application and an ERC-4337 paymaster contract in combination with the abstract idea leads to an improvement of the processor, memory, another technology, or to a technical field. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Looking at the elements as a combination does not add anything more than the elements analyzed individually. Examiner further notes that even though the claims may not preempt all forms of the abstraction, this alone, does not make them any less abstract.
When analyzed under step 2B, the claim(s) does/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 element of using a generic computing component (e.g., non-transitory computer-readable medium, a system, a processor, a memory a sponsorship API, a developer application and an ERC-4337 paymaster contract) to implement the abstract idea amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept or significantly more than the judicial exception. Considered as an ordered combination, the additional elements recited in the claim(s) add nothing that is not already present when the steps are considered separately.
Therefore, claim 1, 12 and 25 are rejected under 35 U.S.C. §101 and are not patent eligible. Dependent claims 2-1, and 13-18 when analyzed are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea.
Dependent claims 2 and 13 further refine the abstract idea by receiving requests through an API gateway, retrieving the off-chain gas sponsorship policy from a policy database, generating the cryptographic authentication signature using a key manager and coordinating the receiving, determining, and generating through a sponsorship service. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 3 further refines the abstract idea by associating the off-chain gas sponsorship policy with a designated application API key such that only requests from the designated application API key are accepted; maintaining the off-chain gas sponsorship policy in a pending status until corresponding blockchain transactions achieve on-chain confirmation; and updating the off-chain gas sponsorship policy status from pending to finalized upon detection of successful transaction inclusion in confirmed blockchain blocks. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 4 further refines the abstract idea by indicating where policies are stores and indicating that sponsorships commitments are tracked. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 5 further refines the abstract idea by indicating that blockchain is monitored and calculating billing. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 6 further refines the abstract idea by describing a request processing phase, a policy evaluation phase and a blockchain and settlement phase. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 7 further refines the abstract idea by describing the sponsorship API (e.g., receives requests, evaluates transaction, generates authentication signatures and provides paymaster and data fields. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 8 and 16 recites an additional abstract idea (i.e., identify and scoring transaction, comparing confidence scores and determining whether a transaction qualifies based on the confidence score). The machine learning is recited at a high level, being used to implement the abstract idea. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claims 9 and 17 recites an additional abstract idea (i.e., predict optimal timing for purchasing ETH, purchase transactions based on the predicted optimal timing; and maintaining a shared ETH pool that serves). The machine learning algorithms is recited at a high level, being used to implement the abstract idea. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claims 10 and 18 recites an additional abstract idea (i.e., the intended use of a learning algorithm, such as predict when funds available for covering gas fees will be depleted and generating severity-based alerts for developer intervention based on the predicted fund depletion timing. The adaptive learning algorithm are recited at a high level and to implement the abstract idea. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 11 recites an additional abstract idea (i.e., analyzing user financial behavior to detect suspicious activity and applying security rules). The adaptive learning modules are recited at a high level to perform the abstract idea. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 14 recites an additional abstract idea (i.e., analyze and categorize users and allocate funds based on their predicted financial value. The machine learning algorithms are recited at a high level to perform the abstract idea. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 15 recites an additional abstract idea (i.e., analyzing user behavior, detecting user activity and enforce protective measures). The adaptive learning modules are recited at a high level to perform the abstract idea. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract ideas itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the dependent claims are also not patent eligible.
Accordingly, it is determined that all claims are directed to non-statutory subject matter under 35 U.S.C. 101 and are ineligible.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-7, 12 and 25 is/are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Bhashin et al. “Bhashin” (US 2025/0371537 A1).
Regarding claims 1, 12 and 25: Bhashin disclose:
Claim 1: A method, comprising:
Claim 12: A system, comprising: a processor; and a memory for storing instructions, the instructions being executed by the processor to:
Claim 25: A non-transitory computer-readable storage medium storing instructions that, when
executed by one or more processors, cause the processors to perform operations comprising:
receiving, via a sponsorship API, a gas sponsorship request for a user operation from a developer application; (See at least Bhashin, Abs.; Fig. 4; [0017]; [0027]; [0038]; Bhashin discloses receiving, via a sponsorship API (i.e., a trusted signing servicer e.g., a sponsored paymaster, using API call) a gas sponsorship request for a user operation (i.e., user operation) operation from a developer application (i.e., developers (e.g., of programmable wallets).)
determining, by evaluating the transactions or user operations against a developer's off-chain gas transaction management policy, whether the requested transactions or user operations should be sponsored, the off-chain gas sponsorship policy comprising configurable rules including spending limits, address controls, and temporal parameters; (See at least Bhashin, [0043]; [0046]; [0048]; Bhashin discloses determining (e.g., agreeing), by evaluating the transaction or user operations (i.e., user operation) against developer’s off-chain gas transaction management policy (i.e., paymaster policy), whether the requested transactions or user operations should be sponsored (i.e., agreeing to sponsor under what conditions) the off-chain gas sponsorship policy comprising configurable rules including spending limits, address controls, and temporal parameters (e.g., limit a total amount of transaction fees that can be sponsored for a period (e.g., hourly, daily, weekly, monthly).)
generating, when the transactions or user operations is determined to qualify for sponsorship, a cryptographic authentication signature that authorizes gas fee coverage for the transaction or user operation; (See at least Bhashin, [0007]; [0048-0049]; [0066]; generating a cryptographic authentication signature (i.e., cryptographic signature signature) that authorizes gas fee coverage for the transaction or user operation (i.e., to indicate that the user operation is sponsored for payment of transaction fees) when the transactions or user operations is determined to qualify for sponsorship (i.e., If the user operation conforms to the policy).)
and
validating, via an ERC-4337 verifying paymaster contract, the authentication signature prior to covering gas fees for the authorized transactions or user operations. (See at least Bhashin, Fig. 4; [0054]; [0067]; the authentication signature (i.e., cryptographic signature) is validated (i.e., valid Fig. 4 step 418) prior to covering gas fees for the authorized transactions or user operations (e.g., prior execute transaction and prior receiving native cryptocurrency).)
Regarding claims 2 and 13: Bhashin disclose the method of claim 1 and the system of claim 12. Bhashin further disclose:
receiving the sponsorship request through an API gateway that routes sponsorship requests from external applications; (See at least Bhashin, [0044] In some examples, the paymaster gas station 114 can provide external APis to verify which user operations transaction fees are to be sponsored by the paymaster 108.)
determining whether the transactions or user operations should be sponsored using a policy engine that retrieves the off-chain gas sponsorship policy from a policy database and enforces the configurable rules; (See at least Bhashin, [0046-0047]; In response to receiving the user operation, the policy management module 208 processes the request; In some examples, each policy is associated with an entity (sponsor), a chain network (indicating the particular chain network that the policy is applicable to, and a target ( e.g., types of user accounts that are to be sponsored for transaction fees); In some examples, each policy can be provided as a data object that includes a set of fields and values.)
generating the cryptographic authentication signature using a key manager; and (See at least Bhashin, [0007]; [0039]; signing the user operation includes calling a key management service that provides the signature).
coordinating the receiving, determining, and generating through a sponsorship service that orchestrates interactions between the API gateway, policy engine, and key manager. (See at least Bhashin, Fig. 2; Paymaster Gas Station.)
Regarding claim 3: Bhashin disclose the method according to claim 1. Bhashin further disclose:
associating the off-chain gas sponsorship policy with a designated application API key such that only requests from the designated application API key are accepted; (See at least Bhashin, [0026-0027]; [0031]; In some examples, the paymaster gas station enables developers (e.g., of programmable wallets) to sponsor transaction fees for users, which enables the developer to account for transaction fees on behalf of its users.)
maintaining the off-chain gas sponsorship policy in a pending status until corresponding blockchain transactions achieve on-chain confirmation; and (See at least Bhashin, [0046] In some examples, a policy, also referred to as a paymaster policy, can be described as a set of rules defined at an entity-level that govern how and when transaction fees are to be sponsored for user operations. Here, entity-level refers to sponsors ( e.g., developers of programmable wallets) that are agreeing to sponsor transaction fees for users and under what conditions.)
updating the off-chain gas sponsorship policy status from pending to finalized upon detection of successful transaction inclusion in confirmed blockchain blocks. (See at least Bhashin, [0048]; 102. If the user operation conforms to the policy, the paymaster gas station 114 can sign the user operation and return the (signed) user operation (e.g., the user operation 130 of FIG. 1) to the user account 102.)
Regarding claim 4: Bhashin disclose the method according to claim 1. Bhashin further disclose:
storing, in a policy database, the configurable rules including spending limits, transaction value thresholds, and rate limiting parameters; and (See at least Bhashin, [0044-0046]; Example tables can include, but are not limited to, a policies table, a paymasters table, an entity table, and a terminal operations table, discussed in further detail herein. In some examples, a policy can limit an amount of transaction fees that are to be sponsored per user operation. In some examples, a policy can limit a total amount of transaction fees that can be sponsored for a period (e.g., hourly, daily, weekly, monthly). In some examples, a policy can limit a frequency of transaction fee sponsorship for a period (e.g., hourly, daily, weekly, monthly). In some examples, a UI can be provided in a development console that enables developers to create and configure policies that can be recorded in the policies table.)
tracking, in a sponsorship database, sponsorship commitments from initial authorization through final settlement. (See at least Bhashin, [0048]; For example, the information can include the entity ID, a chain ID, and a target ID, which can be used to query the policy table to determine whether any policy is applicable to the user operation.)
Regarding claim 5: Bhashin disclose the method according to claim 1. Bhashin further disclose:
continuously monitoring, by a sponsorship indexing module, blockchain networks for events corresponding to pending sponsorships; and (See at least Bhasin, [0055] For example, the transaction reconciliation worker can receive state notices from a block monitor service, which can be provided as a blockchain indexer that indexes transactions and provides notification for transactions reaching terminal state (CONFIRMED, COMPLETED) based on blockchain finality. The paymaster gas station 114 records the user operation in the terminal operations table. In this manner, the terminal operations table can be used to enforce, for example, frequency and/or spending limits on entities (sponsors) by referencing the records for a given period.)
processing, by a billing service, billing events and calculating actual gas costs incurred for successfully completed transactions or user operations. (See at least Bhashin, [0039] In further detail, in response to receiving the unsigned user operation 132, the paymaster gas station 114 verifies the request for sponsorship, executes sanction checks, estimates an amount of computational effort (e.g., gas) that would be required to process the user operation ( e.g., using a gas estimation service).
Regarding claim 6: Bhashin disclose the method according to claim 1. Bhashin further disclose:
wherein the coordinating through the sponsorship service comprises operating through three distinct phases comprising:
an initial request processing phase that receives incoming sponsorship requests and validates the requests through the API gateway; (See at least Bhashin, Abs.; Fig. 4; [0017]; [0027]; [0038-0039]; Bhashin disclose an initial requesting processing phase that receives incoming sponsorship requests (e.g., request for sponsoring) and validates the requests through the API gateway (i.e., API call).)
a policy evaluation and authorization phase that enforces business rules and generates cryptographic commitments; and (See at least Bhashin, [0043]; [0046]; [0048]; a policy evaluation and authorization phase (e.g., determine whether any policies in a set of policies is to be applied to the user operation; that enforces business rules and generates cryptographic commitments.)
a blockchain monitoring and settlement phase that tracks transaction or user operation confirmations and manages final billing. (See at least Bhashin, Fig. 4; [0018]; In general, a digital asset can be described as a virtual store of value that leverages a distributed ledger (e.g., blockchain) to store, record and validate transactions.).
Regarding claim 7: Bhashin disclose the method according to claim 1. Bhashin further disclose:
wherein the sponsorship API:
receives requests for gas sponsorship authentication signatures; (See at least Bhashin, [0006]; [0051]; receives requests for gas sponsorship authentication signatures (i.e., the signature of the signed user operation);
evaluates transactions or user operations against developer-defined policies (See at least Bhashin, [0046]; In some examples, a policy, also referred to as a paymaster policy, can be described as a set of rules defined at an entity-level that govern how and when transaction fees are to be sponsored for user operations);
generates authentication signatures for approved operations; and (See at least Bhashin, [0049]; a signature (cryptographic signature) to the user operation.)
provides paymaster and data fields for inclusion in the transactions or the user operations. (See at least Bhashin, Fig. 1; [0017]; a paymaster that is executed in a chain network, a call to verify, the call including at least a signature of the signed user operation, and in response to determining that the signature of the signed user operation is valid, providing, by the paymaster and to an entry point that is executed in the chain network, a response to the call indicating that the paymaster is verified, the user operation being executed in the chain network at least partially in response to determining that the signature of the signed user operation is valid.)
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.
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.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin as applied to claim 1 above, further in view of Ammatanda et al. “Ammatanda” (US 20230360049 A1).
Regarding claims 8 and 16: Bhashin disclose the method according to claim 1. Bhashin does not explicitly disclose, however Ammatanda teaches:
analyzing blockchain transaction data of the transactions or user operations using machine learning algorithms to identify an operation type; (See at least Ammatanda, Abs.; [0012]; [0022]; [0038]; analyze an incoming transaction request. The machine-learning algorithms utilize features 202 for analyzing the data to generate an assessment.)
assigning a confidence score to the identified transaction or user operation type using classification algorithms; (See at least Ammatanda, Abs.; [0012]; [0022]; [0034]; [0038]; At operation 306, the fraud detection server 118 generates a weight score for each data source of the one or more historical data sources. For example, the weight score may be a value between 0 and 1. The weight score is dependent on the quality of data in the one or more historical data sources. The quality of data may be dependent on the amount of available data.)
comparing the confidence score to a configurable confidence threshold associated with the identified transaction or user operation type; and (See at least Ammatanda, [0037]; At operation 310, the fraud detection server 118 determines that the fraud score surpasses a threshold score.)
determining that the transaction or user operation qualifies for sponsorship when the confidence score meets or exceeds the configurable confidence threshold for the identified operation type. (See at least Ammatanda, Abs.; [0012]; [0022]; [0034]; [0038]; At operation 312, in response to determining that the fraud score surpasses the threshold score, the fraud detection server 118 voids the transaction request. The generated fraud score may be value between zero and one. The threshold score may be 0.6. Thus, if the fraud score is at or above 0.6, the fraud detection server 118 may void the transaction. If the fraud score is between 0 and 0.5, the fraud detection server 118 may validate and process the transaction.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhashin and include Ammatanda’s teachings in order to improve transaction decision-making process.
Claim(s) 9 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin as applied to claim 1 above, and further in view of Cella et al. “Cella” (US 2023/0206329 A1), in view of Harms et al. “Harms” (US 20200264688 A1).
Regarding claims 9 and 17: Bhashin disclose the method according to claim 1. Bhashin does not explicitly disclose, however, Cella teaches:
analyzing historical spend rates and market conditions using machine learning algorithms to predict optimal timing for purchasing ETH (claim17: the native token of the blockchain); (See at least Cella, [0378]; [0383] Referring still to FIGS. 2A and 2B, the platform 100 may include a set of intelligent forecasting engines 192 that forecast one or more attributes, parameters, variables, or other factors, such as for use as inputs by the set of forward purchase and sale machines, the intelligent transaction engines 126 (such as for intelligent cryptocurrency execution) or for other purposes.)
executing ETH purchase transactions through cryptocurrency exchange APIs based on the predicted optimal timing; and (See at least Cella, [0378]; [0383] Purchasing of compute resources may be configured and managed by an expert system operating on any of the external data sources 182 or on data aggregated by the set of data aggregation systems 144 for the platform. Compute resources may be purchased by an automated system using an expert system, including machine learning or other artificial intelligence, such as where resources are purchased with favorable timing, such as based on an understanding of supply and demand, that is determined by processing inputs from the various data sources.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhashin and include teachings of Cella in order to improve the system stability and provide better allocation of funds.
The combination of Bhashin and Cella do not explicitly disclose, however Harms teaches:
maintaining a shared ETH pool that serves multiple developers to minimize purchase costs and ensure continuous availability for covering the gas fees. (See at least Harms, [0093-0095] For example, as shown in FIG. 1D, a solution (header/nonce combination) can only be used once. If the same solution is repeated (e.g., in a playback type attack), then the P2P node will reject the new solution. Since the DAG is shared by all of the Ethereum miners and the DAG is regenerated at 30,000 blocks, there are 30,000 unique solutions that the miners of the Ethereum mining community are in a race to find. More directly, a miners' profitability depends on their ability to generate valid header/nonce combinations and the amount of computing power they devote to the process in outputting valid blocks before other miners. As a related corollary, the fact that a blockchain accumulates entropy means that the rate at which entropy is being added to a community is a “proof of cooperation” without any central organizer.)
Therefore, 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 above combination and include Harms teachings in order to improve adaptability and better financial controls.
Claim(s) 10 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin as applied to claim 1 above, and further in view of Desai et al. “Desai” (US 2020/0311573 A1), in view of Malviya et al. “Malviya” (US 20250272482 A1).
Regarding claims 10 and 18: Bhashin disclose the method according to claim 1. Bhashin does not explicitly disclose, however Desai teaches:
analyzing sponsorship usage patterns using adaptive learning algorithms to predict when funds available for covering gas fees will be depleted; (See at least Desai, [0019]; , [0012]; [0034]; [0036]; Some implementations described herein provide a cloud resource prediction platform that utilizes a machine learning model to predict a quantity of cloud resources to allocate to a customer (e.g., an organization).)
generating severity-based alerts for developer intervention based on the predicted fund depletion timing; and (See at least Desai, [0012]; [0034]; [0036]; In this way, the cloud resource prediction platform may alert individuals responsible for managing resource usage, and the individuals may allocate resources for the customer and conserve resources in the future.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhashin and include Desai’s teachings in order to improve proactive management of sponsorship funds and prevent depletion of resources.
The combination of Bhashin and Desai does not explicitly disclose, however, Malviya teaches reducing false positive alerts by incorporating developer feedback into the adaptive learning algorithms. (See at least Malviya, [0021]; [0025]; For example, a matching algorithm may be updated and/or a machine learning model may be re-trained or fine-tuned based on such user feedback in order to reduce false positives and improve the functioning of the system on an ongoing basis.)
Therefore, 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 above combination and include Malviya’s teachings in order to improve accuracy of predictions.
Claim(s) 11 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin as applied to claim 1 and 12 above, and further in view of Bhatnagar et al “Bhatnagar” (WO 2025052430 A1).
Regarding claim 11: Bhashin disclose the method according to claim 1. Bhashin does not explicitly disclose, however Bhatnagar teaches:
monitoring user spending patterns to establish normal behavior baselines using adaptive learning modules; (See at least Bhatnagar, [0055]; The API key, derived from the token, is a unique identifier used to authenticate and authorize the API call request. By monitoring its sage patterns and implementing rate limits, the user of the system (108) can detect anomalies and potential security threats effectively.)
detecting anomalies in spending velocity, transaction or user operation frequency, and usage amounts; (See at least Bhatnagar, [0055]; The API key, derived from the token, is a unique identifier used to authenticate and authorize the API call request. By monitoring its sage patterns and implementing rate limits, the user of the system (108) can detect anomalies and potential security threats effectively.)
automatically implementing protective measures including spending restrictions and account limitations when suspicious activity is identified; and (See at least Bhatnagar, [0055]; The API key, derived from the token, is a unique identifier used to authenticate and authorize the API call request. By monitoring its sage patterns and implementing rate limits, the user of the system (108) can detect anomalies and potential security threats effectively.)
providing configurable alert and blocking mechanisms based on developer-defined security preferences. (See at least Bhatnagar, [0075]; connected modules at pre-defined intervals by using the AI/ML module. The health check process continuously monitors all microservices and analyzes a health report. If the threshold (for example, 60%) is breached, it notifies the users using alerts and suggests possible solutions for the problem based on previous knowledge. The threshold is set by the CAPIF (404) or the API provider (412).)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhashin and include Bhatnagar’s teachings in order to improve security, fraud detection and protection against malicious use of sponsored transactions.
Regarding claim 15: The system according to claim 12, wherein the processor is further configured to:
implement adaptive learning modules that detect malicious activity patterns and implement automated safeguards to protect sponsored funds, wherein the adaptive learning
modules: (See at least Bhatnagar, [0055]; The API key, derived from the token, is a unique identifier used to authenticate and authorize the API call request. By monitoring its sage patterns and implementing rate limits, the user of the system (108) can detect anomalies and potential security threats effectively.)
monitor user spending patterns to establish normal behavior baselines; detect anomalies in spending velocity, transaction or user operation frequency, and usage amounts; (See at least Bhatnagar, [0055]; The API key, derived from the token, is a unique identifier used to authenticate and authorize the API call request. By monitoring its sage patterns and implementing rate limits, the user of the system (108) can detect anomalies and potential security threats effectively.)
automatically implement protective measures including spending restrictions and account limitations when suspicious activity is identified; and (See at least Bhatnagar, [0055]; The API key, derived from the token, is a unique identifier used to authenticate and authorize the API call request. By monitoring its sage patterns and implementing rate limits, the user of the system (108) can detect anomalies and potential security threats effectively.)
provide configurable alert and blocking mechanisms based on developer-defined security preferences. . (See at least Bhatnagar, [0075]; connected modules at pre-defined intervals by using the AI/ML module. The health check process continuously monitors all microservices and analyzes a health report. If the threshold (for example, 60%) is breached, it notifies the users using alerts and suggests possible solutions for the problem based on previous knowledge. The threshold is set by the CAPIF (404) or the API provider (412).)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhashin and include Bhatnagar’s teachings in order to improve security, fraud detection and protection against malicious use of sponsored transactions.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin as applied to claim 1 above, and further in view of Manohara et al “Manoharan” (US20160247173A1), in view of Khmelev et al. “Khmelev” (US 12380445 B1).
Regarding claim 14: Bhashin disclose the system according to claim 12. Bhashin does not explicitly disclose, however Manoharan teaches wherein the processor is further configured to:
implement for dynamic fund allocation based on user revenue potential, (See at least Manoharan, [0003]; The CLV can also be separately estimated for different classes of customers, such as, based on demographics, age, expected lifetime in years and income of the customers. Such class based estimation enables the organization to determine strategies that are customized according to the requirements and behavior of a particular class of customers and thus improves profitability of the organization.) comprising:
analyzes user behavioral patterns, transaction or user operation frequency, and historical revenue contributions to predict each user's future revenue generation capability, (See at least Manoharan, [0015]; [0046] In an implementation of the present subject matter, the prediction module 216 may predict the CLV for each customer of each segment based on whether a customer has an expected lifetime greater than the predetermined threshold. If the expected lifetime in years is lesser than the threshold then a first computation technique leveraging predicted lifetime in years is utilized. For the first computation technique, calculated margin value, interest rate for discounted cash flow is used to predict the CLV. For customers with expected lifetime in years greater than the predetermined threshold a second computation technique leveraging calculated margin, retention rate and interest rate for discounted cash flow is used for predicting the CLV. For the second computation technique, the expected customer lifetime in years is considered to be infinity Additionally, the described technique perform data analysis of the large volume of data to gather information about customer's buying behavior and expected lifetime.)
classification algorithms that categorize users into revenue potential tiers based on their predicted value to the application; (See at least Manoharan, [0043] The analysis module 108 may then segment the customers into multiple segments based on the weighted RFM scores. The segmenting is performed in a manner that customers with close or similar weighted RFM scores are retained in a common segment, whereas customers with different weighted RFM scores are retained in separate segments.)
automated fund allocation systems that assign dynamic spending limits corresponding to each user's revenue category, wherein users with higher predicted revenue potential receive larger fund allocations. (See at least Manoharan, [0047]; In an implementation, the prediction module 216 may predict the CLV and store the CLV in the database 110. In another implementation, the CLV stored in database 110 may be later used by DAS 104 for the purpose of providing promotional offers to the customers in order to retain the high value customers.)
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhashin and include Manohara’s teachings in order to improve efficiency and maximize return on investment.
The combination of Bhashin and Manohara does not explicitly disclose, however Khmelev teaches; a implement machine learning algorithms for dynamic fund allocation.
Khmelev, on the other hand teaches machine learning algorithms and an adaptive learning module for dynamic fund allocation and analyzes user behavioral patterns. (See at least Khmelev, Col. 10 lines 10-18; Emergency fund allocation system can comprise any suitable machine learning models or algorithms for calculating an allocation amount based on a set of input parameters. In some cases, a linear model could be used in which each input is weighted and a sum of the weighted inputs provides the output allocation amount. In other cases, nonlinear models, including neural networks, could be used to predict appropriate allocation amounts based on input parameters.)
Therefore, 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 above combination and include Khmelev’s teachings in order to improve predictive accuracy adaptability and dynamic allocation of sponsorship resources.
Applicant is reminded that the phrase “…that receives incoming sponsorship requests and validates the requests through the API gateway;” is non-functional descriptive material as it only describes the initial request processing phase.
Furthermore, the phrase “…that assign dynamic spending limits corresponding to each user's revenue category,” is non-functional descriptive material of the automated fund allocation systems. For example, claim merely describes what the automated fund allocation systems is capable to do.
Additionally, the phrase “…for dynamic fund allocation based on user revenue potential, the machine learning algorithms comprising” is intended use of implementing machine learning algorithms. The claim merely describes what the machine learning algorithms could be used for.
Finally, the phrase “…to predict each user's future revenue generation capability, classification algorithms that categorize users into revenue potential tiers based on their predicted value to the application;” is the intended use of analyzing user behavioral patterns, transaction and historical revenue contributions. The claim merely describes what the adaptive learning module could be used for.
It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Examiner has provided prior art, where available, for these intended use and/or non-functional phrases/limitations, however, these phrases/limitations will not distinguish the invention from the prior art in terms of patentability. Accordingly, the prior art is only provided in the interest of compact prosecution.
These portions are given no patentable weight because the limitations, or portions thereof, do not claim the functions as being positively recited actions or functions, and/or they do not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being "for ... [performing a specific functionality]", etc. does not mean that the functions are required to be performed, or are actually performed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kassis et al (US 2025/0238787 A1) Disclose: Off-chain verification service 138 may validate, for example, verifiable presentations. For example, off-chain verification service 138 may check digital signatures to ensure that it was issued by a trusted authority, may validate digital signatures against the verifiable data registry to confirm that they are current and not revoked, and verifies the chain of trusts to ensure the digital signatures was issued through a legitimate and trusted path. [0047].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARLYANNIE M GARCIA whose telephone number is (571)272-6950. The examiner can normally be reached Monday - Friday 7:30am - 4:30-pm.
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 at (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.
/K.G.M/Examiner, Art Unit 3698
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698