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 .
RCE Acknowledgement
Applicant’s Request for Continued Examination (RCE) dated 01/22/2026 and supplemental amendment on 03/12/2026 under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office Action has been withdrawn pursuant to 37 CFR 1.114, and the Applicant's RCE submission filed on 22 JANUARY 2026 and supplemental RCE amendment of 03/13/2026 have been entered.
Status of Claims
Claims 1-2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-51 are pending in this instant application per RCE claim amendments and remarks filed on 01/22/2026 and 03/12/2026 (RCE supplemental). Claims 1-2, 10, 15, 20, 23, 34-36 and 40-43 have been amended, and new claims 44-51 have been added. Claims 3-9, 11-14, 16-19, 21-22, 24-33 and 37-39 have been cancelled. Claims 1 and 51 are the only independent claims reciting a computer-implemented compliance system and a computer-based system respectively. Claims 2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-50 are dependent claims of independent Claim 1 only.
This Office Action is a non-final rejection in response to the RCE claim amendments and supplemental amendments of 01/22/2026 and 03/12/2026 respectively with their accompanying remarks filed by the Applicant for its original application of 20 JULY 2023 that is titled: “System and Method for Compliance-Enabled Digitally Represented Assets”.
Accordingly, amended Claims 1-2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-51 are now being rejected herein.
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-2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-51 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more, wherein Claims 1 and 51 are two independent computer-implemented compliance system claim and computer-based system claim respectively.
(NOTE: Latest RCE ‘amendments to the claims’ filed on 01/22/2026 and 03/12/2026 (and supplemental) by the Applicant are shown as bold and underlined additions, and all deletions may not be shown, or may not be underlined when stricken through. Underlined amendments to the claims that are shown below are from previously submitted claim amendments by the Applicant.)
Exemplary Analysis.
Claim 1: Ineligible.
The claim recites a series of steps. The claim is directed to a compliance system reciting a series of steps, which is a statutory category of invention (Step 1 -- YES).
The claim is analyzed to determine whether it is directed to a judicial exception. The compliance system claim recites the limitations of: enforce rules governing recording transactions on a distributed ledger; receive a request, the request being associated with a transaction; determine that the transaction is in compliance with the compliance policy; generate encoded cryptographic enforcement data, the [[]] encoded cryptographic enforcement data including information configured to facilitate independent verification of the compliance; partially encrypt the [[]] encoded cryptographic enforcement data to facilitate verification thereof without revealing contents of the [[]] encoded cryptographic enforcement data, the verification including a zero-knowledge proof (ZKP), the ZKP preserving privacy contents of the contents of the [[]] encoded cryptographic enforcement data; identify transaction information stored on the public ledger, the transaction information associated with the transaction. In other words, the claim describes a compliance system configured to manage transactions (over a digital asset network) according to a compliance policy (see Abstract). These limitations, as drafted, are steps of a method that, under its broadest reasonable interpretation, covers performance of the limitations via a method of organizing human activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), &/or commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), and/or managing behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions), but for the recitation of generic computer/s and/or computer component/s, such as a computer-implemented system and a digital asset network. These limitations fall under the “certain methods of organizing human activity” group (Step 2A1 -- YES).
Next, the claim is analyzed to determine if it is integrated into a practical application. The claim recites additional elements of: a computer-implemented system and a digital asset network, the digital asset including multiple computing nodes, the digital asset network being configured to enforce rules governing recording transactions on a distributed ledger; the transaction relating to a digital asset associated with the digital asset network, the first computing node including at least one processor and a memory; construct a cryptographically sealed digital wallet executing as a smart contract on the first computing node, the smart contract including computer code instructions stored on the digital asset network; implement a data structure in the cryptographically sealed digital wallet, the data structure configured to computationally bind (i) identity credentials associated with the first computing node and (ii) at least one sealed digital asset associated with the first computing node; store the data structure in secure dedicated hardware-based data storage of the first computing node; store the identity credentials and cryptographic identifiers associated with the first computing node in the secure dedicated hardware-based data storage; control the at least one sealed digital asset via the stored cryptographic identifiers; computationally pair at least a portion of the [[]] encoded cryptographic enforcement data with the transaction information, (per mechanism/s recited in para [0184] onwards under sub-title “Enforcement of Policies”), encrypt the transaction information using a public key of the cryptographically sealed digital wallet, the public key controlled by the hardware security module (HSM); generate an attestation signature using the hardware security module (HSM), the attestation signature configured to validate the encrypted transaction information to a second computing node of the multiple computing nodes; store the computationally-paired [[]] encoded cryptographic enforcement data in a storage location accessible via the digital network; configure the cryptographically sealed digital wallet to invoke a remote server to synchronize the computationally-paired transaction information with the distributed ledger; and configure the cryptographically sealed digital wallet to use the computationally-paired [[]] encoded cryptographic enforcement data to determine if a requested transaction is in compliance with the compliance policy. These additional elements are considered extra-solution activities. The system and network in the steps are recited at a high level of generality, i.e., as generic processors performing generic computer/s functions of processing data. These generic processors are no more than mere instructions to apply the exception using generic computers and/or computer components. Accordingly, these 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. Thus, the claim is directed to the abstract idea (Step 2A2 -- NO).
Next, the claim is analyzed to determine if there are additional elements in this claim that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements in the claim amount to no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer and/or computer components over a network cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Because the additional elements described above were considered to be extra-solution activities in Step 2A, they are re-evaluated in Step 2B to determine if they are more than what is well-understood, routine and conventional in the field. The disclosure does not provide any indication that these additional elements (system and network) are anything other than generic processors and the Symantec, TLI, and OIP Techs. court decisions (MPEP 2106.05 (d) (II)) indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Also, paras [0093]-[0095] and [0114]-[0115] of the Applicant’s own Specification (PG Pub. No. US 2024/ 0104521 published on 03/28/2024) does not describe any specific details in paras [0093]-[0095] and [0114]-[0115]; e.g., AAS/asset-aware service as in “Presenting offers to potential customers and gathering statistics generated based on the testing about how potential customers responded to the offers; the statistics are then used to calculate an optimized price, OIP Technologies, 788 F.3d at 1363, 115 USPQ2d at 1092-93”; and e.g., CRAI/ compliance relevant auxiliary information and ZKP/zero knowledge proofs, as in “Testing a system for a response, the response being used to determine system malfunction, In re Meyers, 688 F.2d 789, 794; 215 USPQ 193, 196-97 (CCPA 1982)”; and e.g., blockchain platform supporting smart contracts as in “Obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011);” and thus, these elements don’t describe a “new technology solution”, but these elements are well-understood and conventional at least as described in exemplary paras [0093]-[0095] and [0114]-[0115] copied below ---
{“ [0093] An asset-aware service (AAS) is thus configured for processing (e.g., sending, receiving, and interacting with) one or more sealed assets in a more complex manner than is allowed by the asset's basic compliance policy. An AAS is permitted to send, receive, or even mix together currency from different end- users. The AAS is responsible for ensuring that CRAI information is correctly reflected on all assets exiting the service into a compliant pool. An AAS may also augment transactions' CRAI with additional information available to it, which may not be otherwise deducible from prior CRAI and transaction history. Accordingly, when assets in the exchange belong to the service's users, their CRAI may reflect this ownership status whenever they enter and leave the service, and whenever they are exchanged for other assets within the exchange. This may require logic that is specific to the application supported by the service. ….
………………………………………………………………………………………………………………………………………………..
[0094] Sealed assets' compliance policies may support AASs in various ways, all of which authorize some AAS to perform transactions or convey CRAI that may not be otherwise allowed by the compliance policy. For example:
1) Compliance policies may include an "allow-list" of AAS parties. These parties would be authorized, and hence trusted, to track users' CRAI for funds that flow internally, and convey it at outbound transactions.
2) Compliance policies may authorize specific protocols (i.e., distributed algorithms) to mechanically track CRAI as they flow within protocols. For example, a mixnet system may be augmented to cryptographically convey CRAI along with the mixed transactions, in a way that achieves the mixnet's privacy goals as observed by the general public including nefarious eavesdroppers, but enables forensic investigation by authorized law enforcement. Concretely, when applied to a blockchain platform that supports smart contracts, this may realized by creating a smart contract that implements the protocol (or pertinent portions thereof), performs CRAI tracking for the assets through it, and has been reviewed to ensure that its CRAI tracking is correct and sound. The smart contract's address may then be added to an AAS allow-list within the policy. Similarly, "Layer 2" asset transfer protocols for virtual assets, such as Bitcoin's Lightning Network, or Bolt Labs's zkChannels based on the Bolt protocol, can also be augmented at the protocol level to convey CRAI reflecting the true ownership of the assets rather than the mechanism that transfers them over the underlying ("Layer 1") distributed ledger. Likewise, rollups systems can be augmented to convey CRAI, for example as discussed below. …………………………………………………………………………………………………………………………………
3) The aforementioned AAS allow-lists may be directly embedded into the policy, and/or may be delegated to external parties such as regulatory bodies, using cryptographic means (e.g., digital signatures). For example, a policy may include the cryptographic identifier of some third-party service, which itself publishes a list of allowed AAS public keys in a well-defined location. This allows the list of authorized AASs to change over time. (This may be repeated. For example, a policy may cryptographically delegate authority to a party which in turn is authorized to delegate to another party or parties the authority for naming AASs. Similarly, such authority can be distributed among a group of multiple parties using well-understood techniques such as multisig or threshold cryptography.) The same mechanisms may allow the authority of an AAS to be revoked, for example in the event that a specific AAS is compromised or fails to correctly produce CRAI. ………………………………………………………………………………………….
4) An AAS may be authorized to act within specific behavioral boundaries. For example, a compliance policy may embed a specific set of parameters that define the types of activity that may be supported by an AAS. These parameters may specify restrictions on certain types of activity, e.g., restrictions on allowed transaction addresses, total funds exchanged, and types of assets supported. As a concrete example, an AAS may be authorized to act as a gateway service between some pools (e.g., compliant pools) but not between other pools. ….…………………………
………………………………………………………………………………………………………………………………………………
[0095] The compliance policy may grant the AAS the flexibility to override the default CRAI propagation, based on assets and wallets, in ways such as the following:
1) Identifying assets that are commingled within one wallet owned by the AAS operator, as being custodied on behalf of one or more other user wallets. Accordingly, propagate CRAI corresponding to the actual owners (such as their origin wallet and transaction history). Thus, when assets are withdrawn from the commingled wallet, they would carry the CRAI of the actual user's wallet, rather than merely that of the AAS operator that custodied the assets.
2) Identifying assets, denominated in one sealed asset, as originating from a trade or exchange of a prior, different sealed asset. Accordingly, propagate CRAI corresponding to the prior asset (such as its origin wallet and transaction history).
3) Extending the above to the case of fractional reserve, wherein the custodian wallet may hold less than the total funds put in custody with the custodian by its users. Thus, a custodian AAS may accept deposits from one or more users into its own custodian wallet, withdraw some of these assets for its own purposes (e.g., to make an interest-bearing loan), deposit back some assets into its custodian wallet, and finally allow users to withdraw their assets from the custodian wallets. The AAS may be configured to remove irrelevant assets in intermediate steps, and include in the CRAI only the economically pertinent transactions (in this case, the user's deposit and withdrawal). ………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………..
[0114] Two important conditions for the design of a compliance-enabled sealed asset are privacy (confidentiality) and soundness. The first requires that transactions should not leak confidential information to unauthorized participants, even when that information is needed in order to verify that a compliance policy is satisfied. This privacy requirement is particularly important in public consensus systems, where the task of validating the correctness of transactions on the ledger often falls to untrusted volunteers. Soundness means that the consensus system participants and third parties must be convinced that the transaction does indeed satisfy the compliance policy, even when they cannot see all of the inputs to the policy evaluation. ………………………………………………………………………………………………………………………….
[0115] The apparent contradiction in these requirements is resolved through the use of cryptography. In particular, this requires that the correct evaluation of compliance policies must be enforced using privacy- preserving techniques, such as zero-knowledge proofs and multi-party computation.”} ---
and indicate that the concept described by the extra-solution additional elements is conventional. Accordingly, a conclusion that the aforementioned extra-solution additional elements are well-understood, routine and conventional activity is supported under Berkheimer options 2 and 3, respectively.
Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional elements do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B -- NO), and the claim is not patent eligible.
The analysis above applies to all statutory categories of the invention including new independent computer-based system Claim 51, which performs the steps similar to those of the independent apparatus Claim 1. Furthermore, dependent system Claims 2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-50, further narrow the independent computer-implemented compliance system Claim 1 with additional steps and limitations (e.g., associate encrypted regulatory information with one or more of a user's transactions; defining one or more conditions constituting suspicious activity; defining one or more attributes of a forbidden transaction; defining one or more attributes of a transaction requiring a deduction; comprising a plurality of sealed wallets defined by the compliance policy; further comprising an identity provider configured to verify information corresponding to a user; configured to augment a native asset associated with the digital asset network by attaching CRAI thereto; configured to disassociate CRAI from a sealed asset, thereby extracting the native asset therefrom; further configured to define a compliant pool comprising sealed wallets and sealed assets defined by compatible compliance policies; said CRAI comprises a regulatory escrow access field configured to facilitate third-party verification of each transaction; further configured to attach to a transaction an encoded mathematical function related to the transaction; further configured to analyze one or more transactions for suspicious activity; wherein encryption of at least some of said CRAI facilitates verification thereof without revealing its contents; wherein encryption of at least some of said CRAI is irrecoverable; wherein said transaction information comprises one or more selected from a group consisting of a cryptographic identifier of a sender of the transaction, cryptographic identifier of a recipient of the transaction, and transaction details; wherein the transaction comprises transferring currency; wherein the smart contract is configured to implement a multi-signature digital wallet; wherein the compliance policy includes precompiled bytecode instructions, wherein the compliance system comprises a virtual machine (VM); wherein the compliance system data associated with the transaction, data associated with the sealed digital wallet, and data associated with the compliance policy; wherein, in determining that the transaction is in compliance with the compliance policy, the compliance system is configured to perform one or more multi-party computation (MPC) operations based on the confidentiality schema;
wherein the compliance system is further configured to verify that the at least one input value is used to execute the precompiled bytecode instructions via the virtual machine (VM); wherein the compliance system further comprises: an authorized gateway computing system configured as an asset-aware service (AAS) with a cryptographic identity determined by the compliance system, ……;
wherein the authorized gateway computing system is further configured to: identify an authorized cryptographically sealed digital wallet based on the compliance policy; wherein the authorized gateway computing system is further configured with a bypass certificate generated by the compliance system;
wherein the bypass certificate includes a cryptographic message signed by a cryptographic key of the authorized gateway computing system identified by the compliance system; wherein the bypass certificate is configured to allow a transaction to bypass the restrictions imposed by the compliance system; wherein the authorized gateway computing system is further configured to avoid acquiring custodial control over the sealed digital assets; etc.), and do not resolve the issues raised in rejection of the independent system Claim 1.
Therefore, said Claims 1-2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-51 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Response to Arguments
Applicant's supplemental RCE remarks (on pages 10-22) and claim amendments dated 12 March 2026 with respect to the rejection of amended Claims 1-2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-51 have been carefully considered, but they are not persuasive and do not put these amended claims in condition for Allowance. Thus, the rejection of amended Claims 1-2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-51, as described above, is being maintained herein with some modifications in this Office Action under 35 USC §101 only, where needed to provide clarification in response to the Applicant’s claim amendments and remarks.
Applicant’s arguments of 03/12/2026 about its claim amendments traversing 101 rejection meet both prongs (pages 14 and 15), and Examiner respectfully disagrees. Examiner notes that a significant majority of those amendments are extra-solution activities as described in para 7. above, and that their combination does not overcome 101 rejection as described in para 8. above.
Furthermore, with respect to the Applicant arguments of 03/12/2026 citing similarity to Example 35, Claim 2 (on pages 19-20) to overcome 101 rejection does not apply here, and Examiner clarifies that the method therein allows the ATM to receive user card data in a more secure and efficient manner. Customer card data entry begins before PIN entry and verification, so if the ATM user is not the authorized customer and does not have the appropriate verification software on their mobile device, the transaction is concluded before entry of the PIN. This method prevents skimming and other techniques to fraudulently obtain a customer’s PIN and even theft of the card since the downloaded software can authenticate the user and likewise authenticate the ATM before the PIN is produced. The combination of obtaining information from the mobile communication device (instead of the ATM keypad) and using the image (instead of a PIN) to verify the customer’s identity by matching identification information does not merely select information by content or source, in contrast to Electric Power, but instead describes a process that differs from the routine and conventional sequence of events normally conducted by ATM verification. The instant claims are not similar to the process claims described in Example 35, Claim 2. Applicant in the instant application has replaced the input data used to perform the fraud analysis in the claim from claims data to enforcement data. Applicant’s inventive concept replaces the data input into the fraud analysis system by using enforcement data instead of claims data. Examiner notes that an improvement to the method/system usually comes from an improvement to the abstract idea but the instant application is not a technological improvement, because it just uses the computer as a tool to carry out the steps of the abstract idea. Therefore, the instant claims amount to no more than performing the abstract idea (of a business solution) on a generic computer.
Applicant's arguments with respect to the rejection of Claims 1-2, 10, 15, 20, 23, 34-36, 40-43 and new Claims 44-51 under 35 USC 101 have been considered, but Examiner respectfully disagrees. Also, Examiner notes that the instant application is nothing more than an improvement of an abstract idea, wherein using technology/ computers to execute an abstract idea is at most an improvement to the abstract idea. Furthermore, Examiner notes that the technology of “sealed digital wallet” has been well-known for many years as shown in google search (attached as Appendix), and the instant application is not improving digital wallet.
Applicant has argued {“that the claimed invention clearly improves existing functionality for digital asset control”}, and {“that the claims include an inventive concept that is an unconventional and non-generic combination of known elements”}. Examiner respectfully disagrees. Examiner further notes that although the courts often evaluate considerations such as the conventionality of an additional element in the eligibility analysis, the search for an inventive concept should not be confused with a novelty or non-obviousness determination. See MPEP § 2106.05(I). Although the second step in the Alice/Mayo framework is termed a search for an “inventive concept,” the analysis is not an evaluation of novelty or non-obviousness, but rather, a search for an element or combination of elements that is sufficient to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself. Furthermore, tests for whether an element is conventional under Step 2B only applies to the additional elements recited and not to the abstract idea present within the claims. Improvement of technology by virtue of novelty or non-obviousness is not a test of eligibility. Examiner has also attached a google search for “digital asset control” as Appendix (2 pages), which shows that it is well-known for over a decade.
The focus of the claims in the present case is not on an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools. The claims here are not directed to a specific improvement to computer functionality. Rather, they are directed to the use of generic technology in a well-known environment, without any claim that the invention reflects an inventive solution to any computer specific problem.
The courts found that “… if a patent’s recitation of a computer amounts to a mere instruction to ‘implement[t]’ an abstract idea ‘on . . . a computer,’ that addition cannot impart patent eligibility.” Alice Corp., 134 S.Ct. at 2358. The claimed invention does not indicate that specialized computer hardware is necessary to implement the claimed systems, similar to the claims at issue in Alice Corp. See Alice Corp., 134 S.Ct. at 2360 (determining that the hardware recited in the claims was “purely functional and generic,” and did not “offer [] a meaningful limitation beyond generally linking the use of the [method] to a particular technological environment, that is, implementation via computers”).
A claim may be found to be eligible if it integrates a judicial exception into a practical application as cited by Applicant. However, examiner notes that "claiming the improved efficiency inherent with applying the abstract idea on a computer" does not provide an inventive concept (see MPEP §2106.05(f)(2).) Claiming improved data processing efficiency inherent with applying any improvement to the judicial exception itself on a computer does not provide an inventive concept. The claims do not integrate the judicial exception into a practical application.
Under the 2019 PEG, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. -see MPEP 2106.05(f). The instant claims do not attempt to solve an unconventional technological solution. Using the processor as a tool to implement the abstract idea and the way the information is processed and displayed does not make it less abstract. The claimed use of computer elements recited at a high level of generality is an attempt to limit the abstract idea to a particular technological environment. Accordingly, these 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.
The claims as a whole do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements are generic computer components claimed to perform their basic functions. The processor is a general-purpose processor that performs general-purpose functions. The recitation of the claimed limitations amounts to mere instructions to implement the abstract idea on a computer (using the processor as a tool to implement the abstract idea). Taking the additional elements individually and in combination, each step of the process performs purely generic computer functions. As such, there is no inventive concept sufficient to transform the claimed subject matter into a patent-eligible application. The claim does not amount to significantly more than the abstract idea itself. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements are simply a generic recitation of a computer processor performing its generic computer functions. Accordingly, claims are ineligible.
Examiner submits that under the current 35 USC 101 examining practice, the existence of such novel features would still not cure the deficiencies with respect to the abstract idea. See for example: Ultramercial, Inc. v. Hulu, LLC, 112 USPQ2d 1750, U.S. Court of Appeals Federal Circuit, No. 2010-1544, Decided November 14, 2014, 2014 BL 320546, 772 F.3d 709, Page 1754 last two ¶: “We do not agree with Ultramercial that the addition of merely novel or non-routine components to the claimed idea necessarily turns an abstraction into something concrete”. Indeed, in this in instant case, the limitations simply narrow or limit the abstract idea without providing anything significantly more than the abstract idea itself.
Dependent claims do not resolve the issues raised in the independent claims. The dependent claims do not add limitations that meaningfully limit the abstract idea. The dependent claims do not impart patent eligibility to the abstract idea of the independent claims. The claims merely amount to the application or instructions to apply the abstract idea on a processor, and is considered to amount to nothing more than requiring a generic processor to merely carry out the abstract idea itself. Therefore, none of the dependent claims alone or as an ordered combination add limitations that qualify as significantly more than the abstract idea.
For these reasons the rejection under 35 USC § 101 directed to non-statutory subject matter set forth in this office action is maintained.
Conclusion
The prior art made of record and not relied upon, listed in Form 892, that is considered pertinent to the Applicant's disclosure and review for not traversing already issued patents and/or claimed inventions by the claims of the current invention of the Applicant.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Sanjeev Malhotra whose telephone number is (571) 272-7292. The Examiner can normally be reached during Monday-Friday between 8:30-17:00 hours on a Flexible schedule.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to contact the Examiner directly.
If attempts to reach the Examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas, can be reached on (571) 270-1836. The facsimile/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 & 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.
Electronic Communications
Prior to initiating the first e-mail correspondence with an Examiner, Applicant is
responsible for filing a written statement with the USPTO in accordance with MPEP §502.03(II). All received e-mail messages including e-mail attachments shall be placed into this application’s record. The Examiner’s e-mail address is provided below at the end of this Office Action.
/S.M./
PSA Examiner, Art Unit 3691
sanjeev.malhotra@uspto.gov
16 APRIL 2026
/SANJEEV MALHOTRA/Examiner, Art Unit 3691
Prosecution Insights