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.
Response to Amendment
The amendment filed on May 29, 2026 has been entered. Applicant has amended claims 1-3, 6-18, and 25. Claims 19-24 and 26 have been withdrawn. Claims 1-18, 25, and 27-28 are now pending, have been examined and currently stand rejected.
Claim Interpretation
Intended use/ Result Language:
Regarding claim 7: The phrase “…for inclusion in the transactions or the blockchain transaction or the user operation” is intended use/result of providing paymaster and data fields.
Regarding claim 14: 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.
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 § 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 1-2, 4-7, 12-13 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin et al. “Bhashin” (US 2025/0371537 A1), in view of Wang et al (US 2018/0183798 A1), “Wang”.
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 that is managed by a blockchain infrastructure provider, a gas sponsorship request for blockchain transaction or 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 blockchain transaction or the user operation against a developer's off-chain gas sponsorship policy, that the blockchain transaction or user operation should be sponsored by the developer application according to the off-chain gas sponsorship policy, 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 blockchain transaction or user operation (i.e., user operation) against developer’s off-chain gas sponsorship 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).)
confirming compliance to the configurable rules of the off-chain gas sponsorship policy; (See at least Bhashin, [0046] determine whether any policies in a set of policies is to be applied to the user operation and, if so, whether the user operation conforms to the polic-y/-ies.).
in response to the confirmation of compliance and the determination that the [user operation confirms the policy], generating a cryptographic authentication signatureBhashin, [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) in response to the confirmation of compliance and the determination that the [user operation conforms the policy] (i.e., If the user operation conforms to the policy).)
and
validating, a verifying paymaster smart contract, the cryptographic authentication signature (See at least Bhashin, Fig. 4; [0054]; [0067]; the authentication signature (i.e., cryptographic signature) is validated (i.e., valid Fig. 4 step 418).
receiving, via the sponsorship API a user submission that incorporates the cryptographic authentication signature into the blockchain transaction or the user operation; and (See at least Bhashin, [0038]; [0049]; To achieve this, the paymaster gas station 114 (the paymaster gas station 114 (e.g., using an application programming interface (API) call),) applies a signature (cryptographic signature) to the user operation).)
covering the gas fee payment for the blockchain transaction or the user operation, via the verifying paymaster smart contract. (See at least Bhashin, [0040-0041] the paymaster 108 can determine whether the user operation 130 is signed by the paymaster gas station 114 indicating that the user operation 130 is authenticated for sponsorship of transaction fees by the paymaster 108. If both the paymaster verification and the user operation verification succeed, the execute sub-function includes an execute function (execute) 156 of the entrypoint 106 calls the execute user operation function (executeOp( )) 166 of the SCA 110 to execute the transaction within the on-chain network.
Bhashin disclose 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). Bhashin does not explicitly disclose, however, Wang teaches; the address controls comprising: (i) an address allowlist that restricts usage of the off-chain gas sponsorship policy to predetermined authorized smart contract wallet addresses, or (ii) an address blacklist that excludes predetermined prohibited smart contract wallet addresses from the off-chain gas sponsorship policy; (See at least Wang, Fig. 7;the address controls (e.g., appropriate rule) comprising: (i) an address allowlist that restricts usage of the off-chain gas sponsorship policy to predetermined authorized smart contract wallet addresses, (e.g., whitelist rules) or (ii) an address blacklist that excludes predetermined prohibited smart contract wallet addresses from the off-chain gas sponsorship policy (e.g., blacklist rules);
determining that a wallet address associated with the blockchain transaction or the user operation is on the address allow list, or that the wallet address is not on the address blacklist (See at least Wang, [0028]; determining that a wallet address associated with the blockchain transaction (i.e., determine whether the network request is to be allowed based on whether the at least one non-IP key and/or the at least one IP key satisfy at least one of the whitelist rules) or the user operation is on the address allow list, or that the wallet address is not on the address blacklist (i.e., determine whether a network request is to be denied based on whether the at least one non-IP key and/or the at least one IP key satisfy at least one of the blacklist rules.)
a determination that the wallet address is on the address allowlist or is not on the address blacklist, (See at least Wang, [0028] determine whether a network request is to be denied based on whether the at least one non-IP key and/or the at least one IP key satisfy at least one of the blacklist rules.)
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 Wang’s teachings in order to effectively protecting real-time Internet traffic. Wang, [0028].
Regarding claims 2 and 13: The combination of Bhashin and Wang disclose the method of claim 1 and the system of claim 12. The combination further disclose:
receiving the sponsorship request through an API gateway.(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 that the blockchain transaction or user operation 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, the policy engine, and the key manager. (See at least Bhashin, Fig. 2; Paymaster Gas Station.)
Regarding claim 4: The combination of Bhashin and Wang disclose the method of claim 1. The combination 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: The combination of Bhashin and Wang disclose the method of claim 1. The combination 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: The combination of Bhashin and Wang disclose the method of claim 1. The combination further disclose:
wherein the coordinating through the sponsorship service further comprises:
receiving incoming sponsorship requests and validating the requests through the API gateway during an initial request processing phase;(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).)
commitments during a policy evaluation and authorization phase; and (See at least Bhashin, [0043]; [0046]; [0048]; commitments 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.)
tracking transaction or user operation confirmations and managing final billing during a blockchain monitoring and settlement phase. (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: The combination of Bhashin and Wang disclose the method of claim 1. The combination 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 the blockchain transactions or user operation 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 blockchain transaction or the user operation. (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.)
Claims 3 is rejected under 35 U.S.C. 103 as being unpatentable over Bhashin and Wang as applied to claim 1 above, further in view of Kuai et al. (US 20210143998 A1).
Regarding claim 3: The combination of Bhashin and Wang disclose the method of claim 1. The combination further disclose:
associating the off-chain gas sponsorship policy with a designated application API key
accepting only requests from the designated application API key; (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. (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.)
Bhashin does not explicitly disclose, however Kuai teaches detecting a successful transaction inclusion in confirmed blockchain blocks; and (See at least Kuai, [0011] In some embodiments, the method further includes, prior to performing the blockchain transaction, validating the user by: submitting a signed transaction to the blockchain using a smart contract and the reconstructed private key; determining whether the signed transaction is successfully recorded to the blockchain; and performing the blockchain transaction only if the signed transaction is successfully recorded in the blockchain.)
It would have been obvious to one of ordinary still in the art to include in the banking system of the above combination the ability to confirm successful inclusion of the blockchain transaction as taught by Kuai since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable..
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin and Wang as applied to claim 1 above, further in view of Ammatanda et al. “Ammatanda” (US 20230360049 A1).
Regarding claims 8 and 16: The combination of Bhashin and Wang disclose the method according to claim 1. The combination do not explicitly disclose, however Ammatanda teaches:
analyzing blockchain transaction data of the transactions or user operations using machine learning algorithms and identifying a transaction type or 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 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 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 confidence score meets or exceeds the configurable confidence threshold for the identified transaction type or the identified 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 (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 and Wang 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: The combination of Bhashin and Wang disclose the method according to claim 1 and the system of claim 12. The combination do not explicitly disclose, however, Cella teaches:
analyzing historical spend rates and market conditions using machine learning algorithms ); (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.)
predicting 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 the above combination and include teachings of Cella in order to improve the system stability and provide better allocation of funds.
The combination of Bhashin, Wang and Cella do not explicitly disclose, however Harms teaches:
minimizing purchase costs and ensuring continuous availability for covering the gas fees by maintaining a shared ETH pool that serves multiple developers. (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 and Wang as applied to claim 1 and 12 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: The combination of Bhashin and Wang disclose the method according to claim 1 and the system of claim 12. The combination do not explicitly disclose, however Desai teaches:
analyzing sponsorship usage patterns using adaptive learning algorithms; (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).)
predicting 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 the above combination and include Desai’s teachings in order to improve proactive management of sponsorship funds and prevent depletion of resources.
The combination of Bhashin, Wang 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 and Wang as applied to claim 1 and 12 above, and further in view of Bhatnagar et al “Bhatnagar” (WO 2025052430 A1).
Regarding claim 11: The combination of Bhashin and Wang disclose the method according to claim 1. The combination do not explicitly disclose; however Bhatnagar teaches:
monitoring user spending patterns and establishing 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 the above combination and include Bhatnagar’s teachings in order to improve security, fraud detection and protection against malicious use of sponsored transactions.
Regarding claim 15: The combination of Bhashin and Wang disclose the system according to claim 12. The combination do not explicitly disclose; however, Bhatnagar teaches; 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 the above combination 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 and Wang as applied to claim 12 above, and further in view of Manohara et al “Manoharan” (US20160247173A1), in view of Khmelev et al. “Khmelev” (US 12380445 B1).
Regarding claim 14: The combination of Bhashin and Wang disclose the system according to claim 12. The combination do 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, Wang 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.
Finally, the phrase “…to predict each user's future revenue generation capability” 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.
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(s) 27 and 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhashin and Wang as applied to claims 1 and 12 above, and further in view of Lee at al. (US 20200073629 A1).
Regarding claims 27 and 28: The combination of Bhashin and Wang disclose the method of claim 1 and the system of claim 12. The combination do not explicitly disclose; however, Lee teaches:
further comprising maintaining the allowlist in a policy database that is associated with the off-chain gas sponsorship policy. (See at least Lee, [0149]; The policy manager 1563 may store a whitelist in a policy database.)
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 Lee’s teachings in order to ensure that only authorized users trigger the backed to pay transaction fees.
Response to Arguments
Claim Interpretation
Examiner appreciates Applicant’s efforts in amending the claim language to positively recite certain claims elements. However, claims 7 and 14 still recite intended use/result language that has not patentable weight. Applicant is reminded that this comment pertains to claim interpretation and in provided to clarify that such language would not distinguish the claims invention from prior art.
Rejections under 35 U.S.C. § 112
Applicant amendments has corrected the previous identified issues. Accordingly, the rejections under 35 U.S.C. § 112 has been withdrawn.
Rejections under 35 U.S.C. § 101
Applicant’s arguments with respect to the 101 rejection have been considered and were found to be persuasive. Amendment pp. 22-25. Examiner contends that the claims still could be considered to be reciting one or more abstract ideas (e.g., to cover gas fee payments based on rules). However, as indicated in applicant’s remarks (Amendment, pp. 25), the additional elements recited in amended claim 1 integrate any alleged abstract idea into a practical application. In view of applicant’s arguments and the current claim amendments, the 35 U.S.C. 101 rejection is withdrawn.
Rejections under 35 U.S.C. § 102
Applicant asserts that Bhasin fails to teach that a gas sponsorship request for a blockchain transaction or a user operation is received from a developer application, via a sponsorship API that is managed by a blockchain infrastructure provider. (Remarks. P. 26). Examiner respectfully disagrees. (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).)
Applicant asserts that Bhasin fails to teach an off-chain gas sponsorship policy comprising configurable rules including spending limits, address controls, and temporal parameters, where the address controls include: (i) an address allow list that restricts usage of the off-chain gas sponsorship policy to predetermined authorized smart contract wallet addresses, or (ii) an address blacklist that excludes predetermined prohibited smart contract wallet addresses from the off-chain gas sponsorship policy (Remarks, p. 27). Examiner agrees, in part. Bhashin disclose 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).) Bhashin, , [0043]; [0046]; [0048]. However, with respect to the address controls comprising: (i) an address allowlist that restricts usage of the off-chain gas sponsorship policy to predetermined authorized smart contract wallet addresses, or (ii) an address blacklist that excludes predetermined prohibited smart contract wallet addresses from the off-chain gas sponsorship policy. Examiner agrees. However, upon further consideration of the newly introduced language, a new ground(s) of rejection is made in view of Bhashin and Wang. Examiner notes this feature is disclosed by “Wang”.
Applicant asserts that Bhasin fails to teach that, in response to the confirmation of compliance and the determination that the wallet address is on the address allowlist or is not on the address blacklist, a cryptographic authentication signature is generated by the sponsorship API that is supported and managed by the blockchain infrastructure. Examiner agrees in part. Bhashin disclose in response to the confirmation of compliance and the determination that the [user operation conforms the policy], generating a cryptographic authentication signatureBhashin, [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) in response to the confirmation of compliance and the determination that the [user operation conforms the policy] (i.e., If the user operation conforms to the policy).) Bhashin does not explicitly disclose, however Wang teaches a determination that the wallet address is on the address allowlist or is not on the address blacklist, (See at least Wang, [0028] determine whether a network request is to be denied based on whether the at least one non-IP key and/or the at least one IP key satisfy at least one of the blacklist rules.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Knowles (US 20100088219 A1) wherein the purchase authorization request phase is processed by a first communication channel and the clearing and settlement phase is processed by a second communication channel, the first communication channel having a higher throughput than the second communication channel. Claim 3.
(Brady Werkheiser) What are paymasters? What are the rules that define paymaster sponsorship policies? Sender allowlists - rules to define the accounts that have access to the paymaster
Sender blocklists - rules to define the accounts that do not have access to the paymaster. Page 3.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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
Prosecution Insights