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 .
Status
This action is in response to applicant’s response to applicant’s amendments dated 12/01/2025. Claims 1-11, 19-20 are pending. Claims 1, 19 are amended. No claims are added. Claims 12-18 were previously cancelled. Claims 1-11, 19-20 are currently examined.
Response to Arguments
Applicant's arguments filed 12/01/2025 have been fully considered but they are not persuasive. The applicant has argued “The Claims Are Not Directed to Mental Processes: The claims recite active technical steps that cannot be performed in the human mind: "pooling together funds for customer of the FI into a custodial FI wallet maintained by a cloud-hosted service" "maintaining ledgers identifying balances of the customer for the FI that maps to specific accounts of the customer with the FT "creating a custodial customer wallet for the customer with the cloud-hosted service" ""moving corresponding funds from the custodial FI wallet to the custodial customer wallet" "updating the ledgers associated with the custodial FI wallet and the custodial customer wallet to reflect fund transfers" "processing the blockchain APIs to interact with the decentralized network service." The examiner respectfully disagrees. Pooling funds is a fundamental, centuries-old banking concept. The mere recitation of a "custodial FI wallet" as the vessel for pooling doesn't transform an abstract financial practice into a technical invention. The claim does not specify how the wallet is technically implemented it's a functional result, not a technical method. Under Alice, appending a generic computer (or "cloud-hosted service") to a longstanding financial practice does not confer eligibility. Maintaining a ledger of account balances is the quintessential abstract idea in finance it predates computers by millennia. The claim simply moves a traditional double-entry bookkeeping function to a computer without describing any new or inventive technical implementation. Alice explicitly warns against this. The word "ledger" itself signals that this is a fundamental financial concept being claimed in computerized form. Creating a wallet for a customer is functionally equivalent to opening an account. The claim provides no technical detail about how the wallet is created, what cryptographic or data structure methods are used, or what distinguishes this from simply allocating a record in a database. It is purely a result-oriented functional claim on an abstract concept. Transferring funds between accounts is a known process in the world of finance. The use of the word "wallet" instead of "account" does not change the underlying abstract nature of the step. The claim does not describe any novel technical mechanism for how this transfer is accomplished it simply states that it happens. This is precisely the kind of "apply it" claim that Alice and Bilski hold ineligible. Updating ledgers to reflect fund transfers is purely a bookkeeping step recording that a transaction occurred. It is entirely functional and result-oriented, describing what happens (ledgers are updated) without describing how in any technically meaningful way. Any generic computer system performing routine data updates would satisfy this limitation. There is no inventive technical concept here beyond conventional database write operations. Although the applicant is processing blockchain APIs to interact with the decentralized network service as claimed an external API is a routine, conventional computer operation. The claim doesn't describe any novel API design, any new blockchain protocol, or any inventive interaction method it simply recites using existing blockchain APIs. The Federal Circuit has consistently held that invoking a generic technological tool to execute an abstract process is insufficient.
The applicant has argued “The Claims Are Not Directed to Methods of Organizing Human Activity: The claims recite specific technological solutions for blockchain integration, not fundamental economic practices. Like DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 113 U.S.P.Q.2d 1097 (Fed. Cir. 2014), the claims solve a technology-specific problem through specific technical architecture.” The examiner respectfully disagrees. In DDR Holdings, the claims were eligible because they overrode the default operation of the internet itself solved a specific, technical problem unique to the internet retaining website visitors rather than merely implementing a known business practice on a computer. The claimed invention, a composite web page, was deemed to be rooted in computer technology. The Federal Circuit emphasized that the claims didn't merely use the internet to carry out a conventional business practice, but instead changed how the internet functioned in a specific, technical way. Here, the claims do no such thing. The blockchain, the APIs, the cloud wallets, and the SSI/DID connections all operate exactly as they were designed to operate. Nothing about the claimed method alters or overrides the underlying technological environment. The cloud calls blockchain APIs as intended. The SSI system verifies identity as designed. The applicant is simply orchestrating existing technologies toward a financial end which is precisely what DDR said was insufficient. The stated problem is that FIs face KYC compliance requirements and regulatory prohibitions on holding cryptocurrency. These are legal and economic constraints, not technical ones. The using SSI to generate an audit trail proving KYC was satisfied is a response to a regulatory problem. The applicant argues the claims provide a "specific technical solution." But specificity alone does not equal eligibility Alice itself involved highly specific steps for executing financial transactions using escrow. The question is not whether the claims are specific, but whether they are directed to something more than an abstract idea. Specificity in describing how to apply an abstract idea using conventional technology does not transform the abstract idea into patent-eligible subject matter under Mayo. In applicant’s invention the underlying problem is regulatory, not technical, the claimed architecture uses all components in their conventional, expected manner, the technical environment is not altered or improved by the invention, the focus of the claims remains financial intermediation and identity verification, with technology as mere implementation, and every component existed and functioned identically before the filing date.
The applicant has argued “Under the analysis required by Enfish and McRO, the claims as a whole are directed to improvements in blockchain integration technology, not to judicial exceptions. Therefore, the claims are eligible at Step 2A Prong 1.” The examiner respectfully disagrees. Enfish involved claims directed to a self-referential table that fundamentally improved how a database was structured and operated, the invention was the technical improvement. McRO involved claims that automated a specific, previously-manual animation process through a rules-based technical method that produced results computers couldn't previously achieve. The critical distinction in both cases was that the claims were directed to improving the technology itself. Here, the applicant makes no improvement to blockchain technology. Applicant’s claims do not propose a new consensus mechanism, improve throughput or latency of blockchain transactions, solve a known technical limitation of blockchain protocols, introduce a new cryptographic type method. The blockchain in this applicant is a pre-existing utility being called via API. Claiming to use a tool is not the same as improving it. Applicant’s specification does not describe a technical improvement to blockchain. Applicant’s specification includes a cloud intermediary managing wallets and ledgers, SSI/DID connections for identity verification,
APIs calling existing DeFi protocols. The specification does not describe a technical problem with blockchain integration that the invention solves. The problems identified are explicitly regulatory (KYC compliance) and financial (FI risk exposure to cryptocurrency).
Further, in McRO, eligibility turned on the fact that the specific rules recited in the claims were themselves the source of the technical improvement the claims captured how the automation worked at a technically meaningful level. The claims here recite results wallets are created, ledgers are updated, APIs are processed, KYC is verified without specifying the technical mechanisms that make any of this an improvement over prior systems. This is not a narrow technical solution to a specific problem it is a broad claim over an entire category of financial technology architecture. Enfish and McRO involved claims carefully tailored to specific technical implementations. The specification never identifies a technical problem with blockchain only regulatory and financial ones. The invention uses blockchain and SSI in their conventional, unmodified forms "Integration" is not improvement. The claims recite results not technical mechanisms.
The applicant has argued “Our Claims Similarly Improve Technology: The amended claims improve blockchain integration technology through: 1. Custodial Wallet Bridge Architecture: The claims recite "pooling together funds for customer of the FI into a custodial FI wallet maintained by a cloud-hosted service" and "maintaining ledgers identifying balances of the customer for the FI that maps to specific accounts of the customer with the Fl." Specification paragraph [0017] explains: "The cloud pools together funds for customers of a given FI into a custodial FI wallet and maintains a ledger identifying the balances of each customer for the FI, which maps to specific accounts of the customers with the FI." Technology Improvement: This creates a technical translation layer bridging incompatible ledger architectures (centralized banking databases vs. distributed blockchain ledgers), similar to how Enfish's self-referential structure improved database architecture.” The examiner respectfully disagrees. In Enfish, the self-referential table was itself the invention the specification described in technical detail how the new data structure worked, why it was faster, and what specific limitation of prior database architecture it overcame. The Federal Circuit pointed to concrete performance improvements (speed, flexibility, reduced need for schema changes) that were disclosed in the specification. The "custodial wallet bridge architecture" here discloses none of that. The specification at paragraph [0017] simply describes what happens — funds are pooled, ledgers are maintained, balances are mapped. It does not: describe how incompatible ledger architectures are technically reconciled, identify a specific technical limitation of either centralized or blockchain ledger systems being overcome, disclose any new data structure, algorithm, or protocol for achieving the translation, demonstrate any performance improvement over prior bridging approaches. The examiner could not locate the concept of "bridging incompatible architectures" in the Specification. Applicant cannot bootstrap eligibility by characterizing claims in argument as solving a technical problem that the specification never identifies or addresses. If paragraph [0017] is the best description of this limitation, it describes a cloud service maintaining a ledger which is a functional description of conventional database bookkeeping, not a technical architectural innovation. The translation layer is just a database with two reference points that hold funds in a cloud-managed account (custodial FI wallet) and maintain a database record (ledger) mapping those funds to customer accounts at the FI. This is functionally identical to how any correspondent banking system, clearinghouse, or payment processor has operated for decades. The fact that one side of the ledger maps to a blockchain wallet rather than another bank account does not transform conventional account reconciliation into a technical invention. Under Alice itself, which involved a computerized escrow intermediary reconciling accounts between parties, this precise architecture was held abstract. If the "technical improvement" being claimed was already the standard operating architecture of cryptocurrency custodians, it cannot constitute an inventive concept under Step 2B. The claims recite the result of the pooling funds, maintaining ledgers, and mapping. None of these limitations describe how the translation is technically achieved. The claims appear to recite only the result of an alleged technical improvement, without capturing the specific technical means of achieving it. Enfish requires disclosed technical detail while applicant’s paragraph [0017] offers only functional description, not technical innovation. The underlying architecture is pooled custodial accounts with mapped ledgers and is decades-old banking practice and pre-existing cryptocurrency exchange infrastructure.
The applicant has argued “Active Fund Movement System: The claims recite "creating a custodial customer wallet for the customer with the cloud-hosted service" and "moving corresponding funds from the custodial EI wallet to the custodial customer wallet." Specification paragraph [0018] explains: "The cloud creates a custodial customer wallet for the customer with the cloud, the corresponding funds from the custodial FI wallet are moved by the cloud to the customer's custodial cryptocurrency wallet and ledgers are updated to reflect the withdrawal..." Technology Improvement: This enables dynamic bridging between incompatible system layers while maintaining synchronized state.” The examiner respectfully disagrees. The argued dynamic bridging between incompatible system Layers is not claimed nor is it in the specification. Just as with the previous argument, this characterization appears nowhere in the specification. Paragraph [0018] describes only what happens is a wallet is created, funds are moved, ledgers are updated. It does not describe any technical mechanism for achieving "dynamic bridging", identify what makes the system layers "incompatible" at a technical level, disclose any protocol, algorithm, or data structure that enables the bridging, or explain how "synchronized state" is technically maintained across disparate systems. The language of maintains synchronized state between incompatible systems is a description of what any distributed database system does by design. Synchronization across distributed data stores is a foundational computer science problem with well-established solutions (two-phase commit, eventual consistency models, distributed transaction protocols) that long predate this application. The claims do not recite any of these mechanisms they simply assert that ledgers are updated to reflect transfers, which is the most basic possible description of a database write operation.
The applicant has argued “The claims recite "updating the ledgers associated with the custodial EI wallet and the custodial customer wallet to reflect fund transfers between the centralized network services and decentralized network services." Technology Improvement: This solves the technical problem of maintaining consistency across fundamentally incompatible ledger architectures in real-time.”” The examiner respectfully disagrees. Creating a custodial customer wallet and moving funds is merely opening a sub-account for a customer within a pooled fund, transferring a balance from a master account to a sub-account, and recording the transfer in a ledger. This is how money market funds, brokerage accounts, and correspondent banking have operated for decades. The substitution of "wallet" for "account" does not transform conventional account management into a technical invention. Automating the management of life insurance accounts even with complex computational steps are abstract because it was fundamentally an administrative financial function. Wallet creation and fund movement were already conventional operations in the custodial cryptocurrency space. Real-time database synchronization is not an invention it is a standard capability of modern distributed systems. The Federal Circuit addressed nearly identical language in Electric Power Group, where claims involving real-time monitoring, integration, and updating of data across incompatible power grid systems were held abstract precisely because real-time data collection and updating is a generic computer function, the claims described the result of synchronization, not a technical method for achieving it, the underlying problem was operational, not a technical limitation of the computing systems themselves.
Despite their different labels Active Fund Movement System and Synchronized Multi-Ledger Update System both arguments describe the same fundamental abstract concept: an intermediary that moves money between accounts and keeps accurate records of those movements. This is the precise abstract idea at the heart of Alice Corp. v. CLS Bank, where the Supreme Court held that using a computer to manage escrow accounts, move funds between parties, and maintain synchronized ledger records was patent-ineligible. The technical vocabulary has been updated (wallets, blockchains, DeFi), but the underlying concept is similar. The specification discloses only functional results, not the technical mechanisms allegedly constituting the improvement, custodial wallet creation, fund movement, and ledger synchronization were all conventional operations in the cryptocurrency custody industry, real-time synchronization is a generic computing capability, not an inventive concept, the claims recite results, not technical mechanisms, failing the Enfish/McRO standard on its own terms.
The applicant has argued “Blockchain API Processing Layer: The claims recite "processing the blockchain APIs to interact with the decentralized network service for the interactions and the transactions." Specification paragraph [0019] explains:" The cloud processes the BC APIs to perform the interactions with the DeFi services for transactions and various customer interactions." Technology Improvement: This creates a protocol translation layer enabling FIs to offer blockchain services without implementing blockchain protocol handling, similar to how Visual Memory enabled flexible memory configuration.” The examiner respectfully disagrees. The argued protocol translation layer is not claimed or disclosed by the originally filed disclosure. Paragraph [0019] states only that "the cloud processes the BC APIs to perform interactions with DeFi services." This is a one-sentence functional description that discloses that the cloud calls blockchain APIs. However, there is nothing about how a translation layer is technically implemented, about what protocol incompatibilities are resolved, or about what makes this processing technically distinct from any other API call. Calling an external API is the most routine operation in modern software development. The Federal Circuit addressed this directly in Amdocs (Israel) Ltd. v. Openet Telecom, noting that merely invoking an API to connect systems does not constitute a technical improvement to either system. The "protocol translation layer" characterization is entirely a post-hoc litigation construct with no basis in the specification. The API processing is explicitly conventional in the specification. As can be seen in at least the originally filed specification paragraph [0017] describes the cloud using "an Application Programming Interface (API) to interact with the protocols associated with other APIs of the DeFi services." This language shows that the DeFi services already have their own APIs, the cloud uses standard API-to-API communication, no new protocol, translation mechanism, or technical bridge is invented. When a specification describes technology in terms that confirm its conventionality, that confirmation cannot be ignored in favor of eligibility arguments made in prosecution. A specification that affirmatively describes conventional API usage cannot support a claim of technical improvement.
The applicant has argued “Analogous to Visual Memory: In Visual Memory LLC v. Nvidia Corp., 867 F.3d 1253, 123 U.S.P.Q.2d 1712 (Fed. Cir. 2017), the Court held that claims reciting programmable operational characteristics for computer memory improved computer technology by enabling one memory system to work efficiently with multiple different processors. Our Claims: The custodial wallet architecture with ledger mapping enables one cloud- hosted service to bridge multiple customer accounts between centralized and decentralized systems, improving blockchain integration efficiency.” The examiner respectfully disagrees. In Visual Memory, the claims recited a specific memory architecture with programmable operational characteristics that allowed a single memory system to adapt its caching behavior to different processor types therefore solving a concrete technical problem (memory inefficiency across processor architectures) through a specific technical mechanism (programmable cache characteristics) disclosed in detail in the specification. As opposed to Visual Memory, the blockchain API processing layer as claimed in applicant’s invention is not a specific identified technical problem in existing memory systems, specific technical mechanism for solving it (programmable operational characteristics), or a concrete performance improvements demonstrated in the specification. The specification identifies no specific technical problem with existing blockchain API architectures, discloses no specific mechanism for processing those APIs differently than they were designed to be processed, and demonstrates no performance improvement over conventional API integration. The applicant argues that "one cloud-hosted service bridging multiple customer accounts between centralized and decentralized systems" is analogous to "one memory system working efficiently with multiple processors." The examiner respectfully disagrees. Visual Memory's claims improved how the memory system itself operated. The current claims don't improve how the blockchain operates, how the APIs function, or how the cloud infrastructure processes requests. It simply uses all of these systems as-is to achieve a financial intermediation goal.
The applicant has argued “Analogous to Ancora Technologies: In Ancora Tech, Inc. v. HTCAmerica, Inc., 908 F.3d 1343, 128 U.S.P.Q.2d 1565 (Fed. Cir. 2018), the Court held that claims using BIOS-based verification to improve computer security were directed to technological improvements, not abstract ideas. Our Claims: The custodial wallet architecture improves financial system security by creating an isolation barrier between FI systems and cryptocurrency exposure while enabling service delivery. Specification paragraph [0012] states: "CeFi institutions do not hold nor are they exposed to the risks associated with DeFi services offered by the techniques presented herein and integrated within their CeFi applications." The examiner respectfully disagrees. In Ancora, the Federal Circuit held claims eligible because they used the BIOS which is a component not conventionally used for software licensing verification in an unconventional way to solve a concrete security vulnerability. The court emphasized that the claims recited a specific, non-generic technical implementation that improved computer security in a way that was neither routine nor conventional. Ancora specified exactly how the BIOS was used and why that particular approach improved security at a technical level. Applicant’s invention recites only that the FI is "isolated" from cryptocurrency risk which is a financial/regulatory benefit, not a technical security improvement. The custodial wallet architecture uses cloud servers, APIs, and ledgers exactly as they are conventionally designed to be used. There is no Ancora type repurposing of a component beyond its conventional function. The "Isolation Barrier" as argued is a financial concept, not a technical one. Paragraph [0012]'s statement that "CeFi institutions do not hold nor are they exposed to the risks associated with DeFi services" describes a financial risk management outcome, not a technical security improvement. The "isolation barrier" is achieved through legal and contractual arrangements. The FI simply doesn't own the cryptocurrency at least not through any technical mechanism that improves system security in the way Ancora's BIOS-based verification did. Ancora improved the technical security of computer systems. Applicant invention reduces the financial and regulatory exposure of banks. These are categorically different things from what is claimed in Ancora.
The applicant has argued “Analogous to SRI International: In SRI Int'lInc. v. Cisco Systems Inc., 930 F.3d 1295 (Fed. Cir. 2019), the Court held that claims using hierarchical network monitoring with activity graphs to improve network security were eligible as improvements to computer network technology. The Court emphasized that "the claims were directed to using a specific technique-generating and using a network activity graph-to solve a technological problem arising in computer networks." Our Claims: The claims use a specific technique-custodial wallet pooling with dual ledger mapping and synchronized updates-to solve a technological problem arising in blockchain integration (incompatible system architectures).” The examiner respectfully disagrees. In SRI International, the claims were eligible because they recited a specific, novel technique of generating network activity graphs from network monitors and using those graphs to detect intrusions. This solved a problem arising within computer networks themselves (intrusion detection). The court emphasized that the technique was specific enough that it didn't preempt all approaches to network security, and that it represented a genuine technical advance in how network monitoring was performed. The problem in SRI arose within the technology specifically intrusion detection is a problem of computer network security, not a business or regulatory problem that happens to involve computers. The problem identified is KYC compliance and FI risk exposure that arises outside the technology, in regulation and finance. SRI's network activity graph technique was genuinely novel. The custodial wallet pooling with dual ledger mapping was, as established above, already the standard architecture of custodial cryptocurrency exchanges before the priority date. SRI's claims were narrowly tailored to the specific technique, preventing preemption of the broader field of network security. The applicant attempts to frame its architecture as a "specific technique" analogous to SRI's network activity graph. But there is a fundamental difference between: A specific algorithmic technique (generating and analyzing network activity graphs) that constitutes a new way of solving a technical problem and a system architecture description (pool funds, maintain ledgers, map accounts, call APIs) that describes the functional organization of conventional components. System architecture descriptions that organize conventional components toward a functional goal without specifying the technical mechanisms that make the architecture novel do not constitute "specific techniques" under SRI's framework. Applicant’s “problems” arise in regulation and finance and are merely addressed using technology.All three cases involved claims narrowly tailored to specific technical implementations. These claims broadly preempt an entire category of blockchain financial services architecture. A technical improvement does not occur through technology that was already conventional in the relevant field.
The applicant has argued “Analogous to Finjan: In Finjan, Inc. v. Blue Coat Systems, Inc., 879 F.3d 1299, 125 U.S.P.Q.2d 1282 (Fed. Cir. 2017), the Court held that claims generating security profiles for downloadable files improved computer functionality by enabling virus scanning while maintaining file safety. Our Claims: The custodial wallet architecture with ledger mapping improves blockchain integration functionality by enabling DeFi participation while maintaining FI isolation from cryptocurrency risk.” The examiner respectfully disagrees. Finjan's technical improvement was to the security scanning process Itself. In Finjan, the claims were eligible because they recited a new way of performing virus scanning, instead of scanning based on known virus signatures, the claims generated behavior-based security profiles that analyzed what downloadable code would do when executed. This was a technical improvement in how security scanning functioned, representing a departure from the approach that the specification described in technical detail. The applicant argues that just as Finjan improved virus scanning while maintaining file safety, this application improves blockchain integration while maintaining FI isolation. Finjan's "improvement" was technical specifically a new method of analyzing code behavior. Applicant “improvement” is financial and regulatory. Finjan improved how the technology worked. The claimed invention merely improves how banks manage regulatory exposure. Using technology to achieve a business or regulatory outcome does not constitute a technical improvement to the technology. Finjan's claims were narrowly drawn to the specific behavior-based profiling technique, limiting their preemptive scope to that particular approach. These claims, by contrast, broadly cover any custodial wallet architecture that pools funds, maintains ledgers, and uses SSI for KYC verification, covering an entire category of financial technology infrastructure regardless of how it is technically implemented.
The applicant has argued “Analogous to PEG Example 1: PEG Example 1 recites "Claims a computer readable medium storing software that analyzes email messages, identifies malicious code, and removes the malicious code. This improves computer technology by protecting against viruses and worms." Our Claims: Recite specific custodial wallet architecture that pools funds, maintains mapped ledgers, creates customer wallets, moves funds, and processes blockchain APIs. This improves blockchain integration technology by bridging incompatible system architectures.” The examiner respectfully disagrees. For the PEG Example 1 analogy to hold, the claims would need to recite specific technical operations that improve blockchain technology the way malicious code removal improves computer security. Instead they recite pool funds which is a financial operation, maintain ledgers which is a bookkeeping operation, create wallets which is an account management operation, move funds which is a financial transfer operation, and process APIs which is a generic software operation. None of these are technical improvements to blockchain, cloud, or API technology. They are financial and administrative operations performed using those technologies.
The applicant has argued “Analogous to PEG Example 2 (DDR Holdings): PEG Example 2 states: “Claims recite steps for generating a composite web page by combining visual elements of a host website and content of a third-party merchant. This provides a specific solution rooted in computer technology that overcomes a problem specifically arising in the realm of computer networks." Our Claims: Recite steps for integrating DeFi services by pooling funds in custodial wallets, maintaining mapped ledgers, creating customer wallets, moving funds, and processing blockchain APIs. This provides a specific solution rooted in blockchain technology that overcomes a problem specifically arising in financial system integration.” The examiner respectfully disagrees. In DDR, the problem was native to how the internet worked clicking a hyperlink inherently redirected users away from the host website, creating a technical behavior that was detrimental to merchants. The claims solved this by overriding the internet's default technical behavior. The application characterizes its problem as "specifically arising in financial system integration." But the financial system integration is not a technological domain in the way computer networks are. The problem is not that blockchain technology fails to work properly, or that APIs malfunction, or that cloud systems behave incorrectly. The problem is that banks face regulatory constraints on cryptocurrency exposure. That problem arises in law, not in technology. DDR's eligibility turned on the fact that the claims changed how the internet itself behaved in a specific context. Pages that would normally redirect users away instead retained them through a specific technical mechanism. This applicant's claims change nothing about how blockchain, APIs, SSI, or cloud infrastructure behave. All underlying technologies operate exactly as designed. The only thing "overridden" is the bank's conventional reluctance to offer DeFi services which is a business decision, not a technological default. The applicant argues its solution is "rooted in blockchain technology" but merely because it uses technology. Under DDR itself, the solution must be rooted in technology in the sense that it addresses a problem that arises from how the technology works. Using blockchain APIs, custodial wallets, and ledger mapping to solve a KYC compliance problem is no more "rooted in blockchain technology" than using email to solve a postal delivery problem is "rooted in internet technology."
The applicant has argued “Analogous to PEG Example 23: PEG Example 23 states: "Claims recite steps for automatically relocating obscured text in a computer display. Mathematical calculations are integrated into an improved user interface technology." Our Claims: Recite steps for integrating blockchain services through custodial wallet architecture. Fund pooling and ledger mapping are integrated into improved blockchain integration technology. ” The examiner respectfully disagrees. PEG Example 23 is eligible because mathematical calculations are integrated into an improved user interface technology, the UI itself is technically improved by the integration of the mathematical operations. The display technology works better because of how the mathematical relocation algorithm operates within it. The applicant has argued that "fund pooling and ledger mapping are integrated into improved blockchain integration technology" but this incorrectly applies the Example 23's framework. Fund pooling and ledger mapping are not mathematical operations integrated into a technical system they are financial and bookkeeping operations performed alongside a technical system. The mathematical calculations in Example 23 were part of the technical mechanism by which the UI improvement was achieved. The financial operations here are not part of any technical mechanism they are the purpose for which conventional technology is being used. Blockchain technology is not improved by this integration. Example 23's UI was improved as it displayed content better. Blockchain technology after this applicant operates identically to blockchain technology before it. The DeFi protocols function the same way. The APIs work the same way. The SSI system behaves the same way. Nothing in the technical substrate is improved. The key principle from Example 23 is that the technology itself must be improved because the UI works better. The applicant's claimed "improvement" benefits banks and their customers by enabling regulatory-compliant DeFi access. That is a user benefit achieved through technology, not a technical improvement to the technology. Under Enfish, McRO, and Example 23's own framework, the technology must be the beneficiary of the improvement, not merely the instrument through which a business benefit is achieved.
The applicant has argued “Particular Machine Implementation (MPEP § 2106.05(b)) The claims require implementation with particular machines integral to the claims: " Cloud-hosted service maintaining custodial FI wallet and custodial customer wallet. Blockchain for DID resolution through blockchain APIs" SSI provider for identity verification and credential issuance" Dual ledger system mapping customer balances to specific bank accounts. API processing system executing blockchain APIs for DeFi interaction. These are not generic computers but specific technical components working together in combination to create the custodial wallet bridge architecture.” The examiner respectfully disagrees. The listed components are generic specifically the cloud-hosted service, blockchain for DID resolution, SSI provider, Dual ledger system, API processing system. A "particular machine" under MPEP § 2106.05(b) requires more than naming categories of technology. The Federal Circuit established in Ultramercial v. Hulu and buySAFE v. Google that reciting generic computing infrastructure even with specific functional label does not satisfy the particular machine requirement. The cloud-hosted service is a generic computing environment. Every modern software application runs on cloud infrastructure. Reciting a "cloud-hosted service" is no more particular than reciting "a computer." The claims don't specify which blockchain, what consensus mechanism, what data structure, or how DID resolution technically operates. Any blockchain would satisfy this limitation. An entirely functional label for a third-party service. The claims impose no technical requirements on how the SSI provider operates. Two databases. The claims specify nothing about their technical implementation, synchronization mechanism, or data architecture. Any system that can call an API — which describes virtually every networked computing system in existence.
The applicant has argued "Working Together in Combination" Does Not Create Particularity The applicant argues these components work together "in combination to create the custodial wallet bridge architecture." But the Federal Circuit squarely rejected this argument in Internet Patents Corp. v. Active Network, holding that combining multiple generic computer components does not create a particular machine even if their combination achieves a novel functional result. The question is not whether the components work together, but whether each component is itself a particular, specialized machine — and none of these are. The Supreme Court addressed the same argument in Alice itself, where CLS Bank's system involved multiple specific components — a supervisory institution, shadow accounts, end-of-day settlement mechanisms — all working together. The Court held these were generic financial system components, not particular machines, regardless of how they were combined.” The examiner respectfully disagrees. The applicant argues these components work together "in combination to create the custodial wallet bridge architecture." But the Federal Circuit squarely rejected this argument in Internet Patents Corp. v. Active Network, holding that combining multiple generic computer components does not create a particular machine even if their combination achieves a novel functional result. The Supreme Court addressed the same argument in Alice itself, where CLS Bank's system involved multiple specific components a supervisory institution, shadow accounts, end-of-day settlement mechanisms all working together. The Court held these were generic financial system components, not particular machines, regardless of how they were combined.
The applicant has argued “Analogous to SiRF Technology: In SiRF Tech. Inc. v. Int'l Trade Commission, 601 F.3d 1319, 94 U.S.P.Q.2d 1607 (Fed. Cir. 2010), the Court held that claims integrating mathematical techniques into a GPS receiver system with mobile device and display were eligible because the mathematical techniques were applied using specific machines. Our Claims: Integrate custodial wallet management and ledger mapping into a cloud-hosted service with blockchain API processing, custodial wallets, and synchronized ledger systems.” The examiner respectfully disagrees. In SiRF Technology, the GPS receiver was a physically specific, specialized hardware device not a general-purpose computer performing financial calculations. The mobile device and display were integral to the GPS functionality in a way that couldn't be separated from the technical method. The mathematical techniques in SiRF were inseparable from the physical GPS hardware. SiRF utilizes GPS receivers are specialized hardware with specific physical components antennas, signal processors, satellite communication systems that constitute genuinely particular machines. Cloud servers, blockchains, SSI providers, and API systems are general-purpose computing infrastructure that can perform any number of unrelated functions. In SiRF the mathematical techniques were only useful in the context of that specific machine GPS coordinate calculation has no meaning outside a GPS receiver. The custodial wallet architecture could theoretically be implemented without blockchain, without SSI, or without cloud infrastructure, using conventional banking systems with minor modifications. The claimed machines are not integral in the SiRF sense. MPEP § 2106.05(b) requires that the particular machine be integral to the claim in the sense that it imposes meaningful technical limits on the claimed method. The Federal Circuit clarified in Dealertrack v. Huber that a machine is not "integral" merely because the method couldn't be performed without it the machine must impose technical constraints that limit the claim to a specific technical implementation. Here, the cloud service, blockchain, SSI provider, and API system are integral to delivering the financial service but they impose no meaningful technical constraints on the claims. The claims would read on any cloud infrastructure, any blockchain, any SSI system, and any API architecture. This breadth confirms these are environmental recitations, not particular machine limitations.
The applicant has argued “Applies Exception in Meaningful Way Beyond Technological Environment (MPEP §2106.05(e)) The claims apply any abstract concepts in a meaningful way that goes far beyond merely implementing them in a generic technological environment. Comparison to DDR Holdings: In DDR Holdings, 773 F.3d at 1259, the Court held that claims generating composite web pages "do not merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet." Instead, the claims were "necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks."” The examiner respectfully disagrees. DDR's claims solved a problem arising from how the internet itself worked, while this applicant solves a problem arising from banking regulation and financial risk management. The DDR court held that eligible claims must do more than perform a pre-internet business practice using internet technology. The pre-internet business practice is a financial intermediary pools customer funds, maintains individual account ledgers, moves money between accounts, verifies customer identity before granting access to services, and connects customers to investment opportunities. The internet/blockchain implementation is the same intermediary does all of this using cloud infrastructure, blockchain APIs, SSI-based identity verification, and custodial cryptocurrency wallets. This is precisely the pattern DDR said was insufficient taking a known business practice (financial intermediation with KYC verification) and implementing it in a new technological environment (blockchain/DeFi ecosystem). The technological environment has changed; the underlying business practice has not. Under DDR's own test, these claims fail. DDR required that the problem overcome be one "specifically arising in the realm of computer networks" could specifically not exist outside that technological context. The Federal Circuit emphasized this because it demonstrated the claims were genuinely technological rather than merely technological implementations of business practices. The claimed FIs needing KYC compliance while offering new financial services — does not specifically arise in blockchain technology. KYC compliance requirements apply to banks regardless of what technology underlies the services being offered. The problem is regulatory, and it would persist even if blockchain technology ceased to exist. This directly contradicts DDR's requirement that the problem specifically arise in the technological realm. The abstract idea is merely applied using generic computer components (cloud, APIs, blockchain). The technological environment is merely identified without technical specificity ("a blockchain," "an SSI provider"). The claims are result-oriented without specifying technical means (funds move, ledgers update, APIs are processed). The abstract idea could be performed without the recited technology (financial intermediation with KYC predates all of this). The recited technology is used conventionally (APIs, cloud services, and blockchain operate as designed).
The applicant has argued “The claims do not merely recite performance of financial transactions with the requirement to use blockchain. Instead, the claims are necessarily rooted in blockchain technology to overcome a problem specifically arising in financial system integration: Technology Problem Solved (from Specification): ""CeFi FIs are excluded from participating in DeFi arrangements due to government regulations (which prohibit direct cryptocurrency involvement by the FIs) and their own risk tolerances." FIs have KYC requirements which require that the FI verify the identity of their customer with PII each time that customer is onboarded and each time a customer is offered or uses a service provided by the FI." Specific Technical Solution: 1. Pool funds into cloud-hosted custodial FI wallet (aggregation interface) 2. Maintain ledgers mapping to specific bank accounts (translation layer) 3. Create custodial customer wallet with cloud-hosted service (DeFi interface) 4. Move funds between custodial wallets (dynamic bridging) 5. Update synchronized ledgers (consistency maintenance) 6. Process blockchain APIs (protocol translation) This specific sequence creates a technical bridge enabling incompatible systems to interoperate, similar to how DDR Holdings' composite web page solved the Internet-specific problem of site navigation.” The examiner respectfully disagrees. "Technology Problem" as argued is not a technology problem. "CeFi FIs are excluded from participating in DeFi arrangements due to government regulations (which prohibit direct cryptocurrency involvement by the FIs) and their own risk tolerances" and "FIs have KYC requirements which require that the FI verify the identity of their customer with PII each time that customer is onboarded..." are not technological problems. They describe regulatory prohibitions (government regulations prohibiting cryptocurrency involvement), legal compliance requirements (KYC mandates), business risk management (FI risk tolerances). By quoting these passages as the source of the "technology problem," the applicant has affirmatively confirmed that the problem is regulatory and financial, not technological. No amount of technical solution framing can convert a regulatory compliance problem into a technological one under DDR's framework. None of these problems arise because of how blockchain technology works. They would exist equally if DeFi services ran on conventional distributed databases rather than blockchains. The problems arise in law and institutional policy blockchain is merely the current technological context in which those pre-existing problems manifest. Comparing to DDR, where the problem involves how users are being redirected away from host websites when clicking hyperlinks could not exist without the internet. Hyperlink redirection is a behavior native to how the internet operates. There is no analogous behavior here that is native to blockchain technology causing the regulatory and KYC problems the applicant identifies. Enabling banks to offer DeFi services while maintaining KYC compliance is a financial and regulatory problem. Implementing the solution using blockchain APIs, custodial wallets, and SSI does not transform the nature of the problem. The applicant argues that the specific sequence creates a technical bridge. But sequences of conventional steps do not become technical inventions merely through their combination. The Federal Circuit addressed this in Mortgage Grader v. First Choice Loan Services, holding that a sequence of steps for enabling anonymous mortgage shopping — each individually conventional — remained abstract when combined because the combination produced only a functional financial outcome, not a technical one. Here, the sequence produces a functional financial outcome: banks can offer DeFi services to customers while maintaining regulatory compliance. That outcome is valuable. It is not, however, a technical improvement to any underlying technology. The applicant invokes "technical bridge" or "bridging incompatible systems" as its core technical contribution. However, the same response applies: this characterization appears nowhere in the specification. A specification that describes financial operations in functional terms cannot support an eligibility argument built on technical architecture characterizations invented during prosecution. The gap between what the specification discloses and what counsel argues is itself evidence that no genuine technical improvement was made. DDR's composite web page solved a problem that was structurally impossible to solve outside internet technology — you cannot prevent hyperlink redirection without controlling how web pages are served. The solution was inseparable from the technical environment. The applicant's solution using a cloud intermediary to hold cryptocurrency on behalf of banks is entirely separable from blockchain technology. The fact that the functional outcome can be achieved without blockchain confirms the solution is not rooted in blockchain technology in the way DDR's solution was rooted in internet technology. DDR eligibility requires that the technology be essential to the solution, not merely one of several possible implementation choices.
The applicant has argued “Analogous to Amdocs: In Amdocs (Israel) Ltd.v. Openet Telecom, Inc., 841 F.3d 1288, 120 U.S.P.Q.2d 1527 (Fed. Cir. 2016), the Court held that claims reciting generating account records, correlating records, enhancing records, aggregating enhanced records, and enabling generation of reports were eligible because they "entailed an unconventional technological solution to a technological problem" and "did more than simply 'provide reports' or perform fundamental economic practices. Our Claims: Recite pooling funds, maintaining mapped ledgers, creating custodial wallets, moving funds, updating synchronized ledgers, and processing blockchain APIs. These entail an unconventional technological solution to a technological problem (blockchain integration) and do more than simply "process transactions" or perform fundamental economic practices." The examiner respectfully disagrees. In Amdocs, the Federal Circuit found eligibility because the claims recited a specific, unconventional distributed architecture network devices that collected and enhanced records at the network edge rather than in a central server. The court emphasized that this distributed enhancement approach was technically unconventional, solving a concrete scalability problem in network data processing that the specification identified and described in technical detail. Three elements made Amdocs eligible are an unconventional architecture, the distributed edge-processing approach in Amdocs departed from the conventional centralized processing architecture. This applicant's custodial wallet architecture follows exactly the conventional centralized intermediary model already used by every major cryptocurrency custodian. Amdocs identified a specific technical scalability problem with centralized record processing. This applicant identifies regulatory and compliance problems, not technical ones. Amdocs' claims recited specific technical relationships between network components that reflected the unconventional architecture. These claims recite functional financial operations without specifying technical mechanisms. The Amdocs court's holding that eligible claims must present an "unconventional technological solution to a technological problem." In contrast in applicant’s application the problems are regulatory (KYC compliance) and financial (cryptocurrency risk exposure), not technological. The custodial wallet architecture with pooled funds, mapped ledgers, and API-based DeFi interaction was the industry standard among cryptocurrency custodians before the priority date. An architecture that was already conventional in the relevant industry cannot constitute an "unconventional technological solution" under Amdocs. The Amdocs court noted that the specific sequence of generating, correlating, enhancing, and aggregating records reflected a technically specific implementation of the unconventional distributed architecture the sequence itself captured how the technical improvement worked at a meaningful level of detail. This applicant's sequence to pool, maintain, create, move, update, process describes what a financial intermediary does, not how a technical system works. The Amdocs sequence was technically specific because each step reflected a technically unconventional operation in the distributed architecture. This applicant's sequence is functionally specific because each step reflects a conventional financial intermediation operation. Functional specificity is not technical specificity under Amdocs.
The applicant has argued “Additional Elements Not Well-Understood, Routine, or Conventional (MPEP § 2106.05(d)) Per Berkheimer v. HPInc., 881 F.3d 1360 (Fed. Cir. 2018), whether claim elements are well-understood, routine, or conventional is a question of fact requiring evidence. The Examiner Has Provided No Evidence That:" Custodial wallet architecture pooling customer funds while maintaining individual ledger mapping to specific bank accounts was well-understood, routine, or conventional in 2017" Creating custodial customer wallets with cloud-hosted service for blockchain integration was routine. Moving funds between custodial FI wallets and custodial customer wallets for DeFi access was conventional. Maintaining synchronized ledgers across incompatible centralized and decentralized architectures was well-understood. Processing blockchain APIs on behalf of FIs to enable DeFi participation while maintaining isolation was routine. The specific combination of these elements was conventional Without such factual evidence, the claims must be found eligible.” The examiner respectfully disagrees. It is noted that the Examiner did not find any additional element or combination of elements in the rejected claims that are recognized as well-understood, routine, and conventional activities. However, Berkheimer does not require the Examiner make a factual finding that all claim elements are well-understood, routine or conventional. Rather, a Berkheimer factual is required for additional elements or a combination of additional elements outside of the identified abstract idea. See Berkheimer Memo. P. 2. Further, Berkheimer established that whether claim elements are well-understood, routine, or conventional is a question of fact but this holding has important limitations: Berkheimer applies at Alice Step 2B, after the court has already determined at Step 1 that the claims are directed to an abstract idea. The applicant cannot use Berkheimer to avoid Step 1 analysis. As established throughout these arguments, these claims are directed to the abstract idea of regulated financial intermediation a Step 1 determination that Berkheimer does not affect. Second, the Federal Circuit clarified in Berkheimer v. HP Inc. on remand and in Aatrix Software v. Green Shades Software that the factual question Berkheimer identifies is narrow it concerns whether the specific combination of elements as claimed was conventional, not whether each element individually was known. The applicant misapplies Berkheimer by fragmenting the claims into individual elements and demanding evidence of conventionality for each separately. Third, and most critically, Berkheimer does not prevent the examiner from relying on the specification itself as evidence of conventionality. The Federal Circuit confirmed in Berkheimer that when a specification describes claim elements as performing "generic computer functions" or operating in conventional ways, that admission suffices to establish conventionality without additional evidence. The applicant’s own specification describes its technical components in terms that confirm their conventionality: APIs: Described as standard interfaces — "uses an Application Programming Interface (API) to interact with the protocols associated with other APIs" — no novelty claimed. Blockchain: Used as existing infrastructure "BC APIs" called as designed no modification described. Cloud: Generic cloud infrastructure "cloud-hosted service" with no technical specificity. SSI/DID: Existing SSI provider used as-is "An SSI service permits DID-based connections" describing existing capability, not inventing new one. Ledgers: Standard database records" maintains a ledger identifying balances" conventional bookkeeping description. Custodial wallets: Described functionally without any novel technical implementation detail. Under Berkheimer itself, when a specification describes additional elements in a way that demonstrates they are well-understood, routine, and conventional, the examiner can rely on that specification language as evidence.
The applicant has argued “Analogous to Ex Parte Berkheimer (PTAB): The PTAB held that "Dependent claims 4-7 recite unconventional storage of object structures without redundancy, improving system efficiency. This provides an inventive concept." Our Claims: Recite unconventional custodial wallet architecture with dual ledger mapping, fund movement between wallet types, and synchronized updates, improving blockchain integration efficiency. This provides a practical application.” The examiner respectfully disagrees. In Ex Parte Berkheimer, the PTAB found dependent claims 4-7 eligible because they recited "unconventional storage of object structures without redundancy" a specific technical departure from how object structures were conventionally stored that improved system efficiency in a technically demonstrable way. The specification described in technical detail why this storage approach was unconventional and how it improved efficiency. The applicant attempts to map "unconventional custodial wallet architecture with dual ledger mapping" onto this holding. However, in Berkheimer the PTAB claims specified a technically unconventional data storage approach the unconventionality was in how data was technically organized and stored. This applicant’s "unconventional architecture" is a functionally described financial arrangement the unconventionality claimed is in how financial services are organizationally structured, not in any technical data or processing innovation. The Berkheimer PTAB specification provided technical evidence of why the storage was unconventional it explained the technical problem with redundant storage and how the claimed approach solved it technically. Applicant’s specification provides no technical evidence of why custodial wallet architecture with dual ledger mapping is unconventional it simply describes what the architecture does. “Improving system efficiency" in Berkheimer referred to computer system efficiency a technical metric. "Improving blockchain integration efficiency" here refers to financial system efficiency enabling banks to offer more services which is a business metric, not a technical one.
The applicant has argued “Analogous to BASCOM: In Bascom Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 119 U.S.P.Q.2d 1236 (Fed Cir. 2016), the Court held that claims reciting content filtering at specific network locations in an unconventional arrangement integrated abstract ideas into practical application. Our Claims: Recite custodial wallet pooling, ledger mapping, fund movement, and blockchain API processing in an unconventional arrangement that integrates any abstract ideas into practical application.” The examiner respectfully disagrees. In BASCOM, the Federal Circuit found eligibility because the claims recited content filtering at a specific, unconventional network location the ISP level rather than the end-user device or server in a way that the specification demonstrated was technically non-obvious and provided specific technical advantages unavailable from conventional filtering locations. The unconventionality was filtering at ISP level, not device or server level, the specification explained why ISP-level filtering provided technical advantages. This is not present here. BASCOM's eligibility turned on where in the network architecture the filtering occurred a specific, technically meaningful structural choice that enabled capabilities unavailable from other locations. The applicant’s custodial wallet architecture has no analogous structural the "cloud-hosted service" could be located anywhere, the custodial wallets could use any blockchain, the ledgers could use any database architecture, the APIs could interface with any DeFi protocol. The claims impose no structural constraints that reflect a technically unconventional arrangement in the way BASCOM's ISP-level filtering did. Any cloud service connecting banking applications to DeFi protocols via custodial wallets would satisfy the claims confirming the architecture is defined by functional outcome, not by any specific unconventional structural arrangement. The Federal Circuit in BASCOM emphasized that while individual elements (filtering, customization, ISP networks) were each known, their specific combination at a specific network location was unconventional and produced technical advantages. The court looked for evidence in the specification that this combination was non-obvious and technically advantageous in a way that individual elements were not. The combination of custodial wallet pooling, ledger mapping, wallet creation, fund movement, ledger synchronization, and API processing was not unconventional it was the standard architecture of custodial cryptocurrency exchanges before the priority date. Under BASCOM's own framework, a combination that was already conventional in the relevant industry cannot supply the inventive concept required for eligibility.
The applicant has argued “Effecting a Transformation (MPEP § 2106.05(c)) The claims effect transformation of funds between different system architectures: " Centralized bank account balances --Pooled custodial FI wallet --Individual custodial customer wallet ->DeFi transaction capability This transformation enables a different state (FI-backed DeFi participation) than previously possible. Conclusion on Step 2A Prong 2: The claims integrate any recited abstract ideas into practical applications through: Improving blockchain integration technology itself. Implementation with particular machines integral to claims. Applying concepts in meaningful way solving technology-specific problems. Reciting additional elements not shown to be conventional. Effecting transformation of funds between system architectures. Therefore, the claims are applicant eligible at Step 2A Prong 2.” The examiner respectfully disagrees. The claimed "Transformation" Is not physical transformation. The transformation prong requires transformation of an article into a different state or thing a standard rooted in physical, chemical, or data transformation that produces a fundamentally different object or dataset. The applicant's claimed transformation sequence is: Centralized bank account → Pooled custodial FI wallet → Individual custodial customer wallet → DeFi transaction capability. This is not a physical or technical transformation it is a financial state change. Money moving between accounts does not transform anything in the §101 sense any more than writing a check transforms the underlying currency. The Supreme Court addressed this directly in Bilski v. Kappos itself, holding that transformations of legal or financial relationships — including transformations of how money is held, allocated, or accessible — do not satisfy the transformation prong. The applicant argues this transformation "enables a different state (FI-backed DeFi participation) than previously possible." But "different state" in the transformation test refers to a different physical or technical state of an article not a different financial or legal status of a customer relationship or account arrangement. The Federal Circuit clarified this in CyberSource Corp. v. Retail Decisions, holding that the manipulation of "public and private financial information" and the movement of funds between accounts does not constitute transformation of an article under Bilski. Financial state changes even complex, multi-step ones remain abstract regardless of how many technical systems intermediate the change. The "state" the applicant identifies "FI-backed DeFi participation" is a legal and financial status, not a technical state of any article. A customer's ability to participate in DeFi through their bank is a contractual and regulatory outcome, not a transformation of data, hardware, or any physical article. Even accepting that financial data could theoretically constitute an "article" subject to transformation, moving account balances between database records from a bank account record to a custodial wallet record to a customer wallet record does not transform that data into something fundamentally different. The underlying value represented remains identical throughout. Under Cybersource and Bancorp Services, recording the same financial value in different database fields across different systems does not constitute the kind of transformation that satisfies Bilski's transformation prong. At most this is a financial application valuable, useful, and commercially significant but not a technical practical application of the kind that satisfies Step 2A Prong 2.
The applicant has argued “Step 2B: Claims Provide Inventive Concept. Even if the analysis proceeds to Step 2B, the claims recite significantly more than any abstract idea by providing an inventive concept. 1. Unconventional Combination Constitutes Inventive Concept Analogous to BASCOM: In BASCOM, 827 F.3d at 1350, the Court held that claims reciting "a combination of filtering Internet content steps in a non-conventional arrangement that constitutes an inventive concept" were eligible under Step 2B. The court emphasized that the "inventive concept inquiry requires more than recognizing that each claim element, by itself, was known in the art." The examiner respectfully disagrees. BASCOM held that an unconventional combination of known elements can supply an inventive concept even when each element is individually known. But this principle cuts both ways. The Federal Circuit in BASCOM immediately followed that statement by identifying specific technical evidence in the specification demonstrating why the combination was unconventional. The court did not simply accept the applicant’s assertion of unconventionality it required specification-grounded technical justification. Here, the applicant invokes the BASCOM principle without providing what BASCOM required: specific technical disclosure explaining why this combination of known elements is non-conventional and what technical advantages the combination provides that individual elements do not. Without that disclosure, the BASCOM principle cannot be applied. The BASCOM inventive concept argument requires that the combination be unconventional. When the combination was already implemented by multiple industry players before the priority date, there is no unconventional combination to supply an inventive concept — there is only a conventional combination applied in a new regulatory context. Applicant’s claimed "inventive concept" connecting banks to DeFi services through a custodial intermediary while satisfying KYC requirements is the same concept as the abstract idea the claims are directed to. The Federal Circuit established in BSG Tech v. BuySeasons that the inventive concept cannot be the abstract idea itself or a trivial implementation of it. Generic computing infrastructure (cloud, APIs, blockchain) used in its conventional manner to implement a conventional financial intermediation architecture for a new regulatory compliance purpose. Under Alice, that answer is insufficient. It was insufficient in 2014 when Alice was decided. It remains insufficient today. And no amount of technical vocabulary, case analogy, or burden-shifting argument changes what these claims are fundamentally directed to.
The applicant has argued “Our Claims Recite Unconventional Combination: The claims recite a combination of: 1. Blockchain DID connections resolved through blockchain APIs 2. KYC verification through SSI provider 3. Pooling funds in cloud-hosted custodial FI wallet 4. Maintaining ledgers mapping to specific customer bank accounts 5. Creating custodial customer wallet with cloud-hosted service 6. Moving funds between custodial wallets 7. Updating synchronized ledgers 8. Processing blockchain APIs for DeFi interaction 9. Managing DeFi services while FI provides CeFi services. This specific combination in this arrangement creates a technical bridge enabling incompatible systems to interoperate-an unconventional solution not shown to exist in the prior art.” The examiner respectfully disagrees. The claims recite the results of the interoperability specifically moving funds between wallets, rather than the technical mechanism specific code, specific data structures that allows a CeFi database to trust a DeFi smart contract. The invention does not improve the speed, security, or efficiency of the blockchain network itself. Instead, it uses blockchain as a tool to implement a business model. Even if the invention has no prior art, it still must not be an abstract idea or a mere routine/conventional method. The lack of prior art does not make an abstract idea eligible.
The applicant has argued “Analogous to PEG Example 34 (BASCOM): PEG Example 34 states: "Claims recite a combination of filtering Internet content steps in a non-conventional arrangement that constitutes an inventive concept." Our Claims: Recite a combination of custodial wallet pooling, ledger mapping, fund movement, synchronized updates, and blockchain API processing steps in a non-conventional arrangement that constitutes an inventive concept for blockchain integration.” The examiner respectfully disagrees. BASCOM required a technically unconventional arrangement demonstrated in the specification, and this applicant's specification demonstrates only conventional financial intermediation operations. PEG Example 34 specifically states that the filtering steps are arranged in a "non-conventional" way. The word "non-conventional" in that example is not a conclusion to be asserted it is a finding grounded in technical evidence from the specification. Simply labeling the applicant's arrangement "non-conventional" in argument, without the specification evidence that PEG Example 34 presupposes, does not satisfy the example's requirements. The specific arrangement the applicant claims SSI verification → custodial wallet creation → fund pooling → ledger mapping → fund movement → synchronized updates → blockchain API processing — follows the exact operational sequence of any custodial cryptocurrency platform onboarding an institutional client. There is nothing about the order, combination, or architecture of these steps that departs from conventional cryptocurrency custody practice. PEG Example 34 cannot be satisfied by a conventional arrangement simply labeled unconventional.
The applicant has argued “Analogous to PEG Example 36: PEG Example 36 states: "Claims recite a specific system involving a video camera array and reconstruction of object coordinates that provides an unconventional technical solution for tracking inventory." Our Claims: Recite a specific system involving custodial wallet architecture with ledger mapping and blockchain API processing that provides an unconventional technical solution for blockchain integration. ” The examiner respectfully disagrees. Example 36 Involves Specific Hardware With Specific Technical Functions. PEG Example 36 recites a video camera array specific physical hardware with defined spatial relationships combined with a specific algorithm for reconstructing three-dimensional object coordinates from camera data. Every element of what makes Example 36 eligible is absent here. The application has no specific hardware: generic cloud, blockchain, and API infrastructure, no specific algorithm: functional descriptions of financial operations, no technically transformed output: account balances in different database fields, no technical improvement: conventional financial intermediation in a new regulatory context. Example 36 is eligible because the technical means the camera array configuration and coordinate reconstruction algorithm are themselves the invention. The technical means here cloud servers, blockchain APIs, SSI providers are not the invention they are merely the infrastructure through which a financial service is delivered. The applicant’s analogy to Example 36 would be valid if the claims recited a specific novel algorithm for reconciling CeFi and DeFi ledger data, a specific new protocol for SSI-based KYC verification, or a specific new method for blockchain API processing. The claims recite none of these things. They recite that these operations happen, not how they happen in any technically inventive way.
The applicant has argued “Specific Technical Implementation Improves Technology Analogous to McRO: In McRO, 837 F.3d at 1314, the Court held that the "specific structure of claimed animation rules improves lip synchronization and prevents preempting all automation. Not merely automating process." The Court emphasized that the claims went "beyond merely using a computer as a tool to automate conventional activity." Our Claims: The specific structure of the custodial wallet bridge architecture improves blockchain integration and prevents preempting all bridging solutions. The claims go beyond merely using computers to automate financial transactions. Specific Technical Rules: Funds must be pooled in cloud-hosted custodial FI wallet . Ledgers must map to specific customer bank accounts " Custodial customer wallet must be created with cloud-hosted service . Funds must be moved between specific wallet types . Both ledgers must be updated synchronously . Blockchain APIs must be processed for DeFi interaction This specific technical implementation improves how blockchain integration technology works.” The examiner respectfully disagrees. McRO's animation rules specified mathematical relationships between phonemes, mouth shapes, and timing parameters genuinely technical constraints on how the animation algorithm operated that produced results computers couldn't previously achieve. They were rules about how the technology performed its function. The rules as claimed in the current application are operational constraints on a financial system they specify what must happen in what order to deliver a financial service. They are rules about what the business process requires, not about how technology performs a technical function. McRO Required That the Rules Themselves Be the Improvement. In McRO, the specific rules were the source of the technical improvement the rules defined a new way of performing lip synchronization that was technically superior to prior methods. The Federal Circuit emphasized that the rules prevented preemption because they were specific enough to leave room for other approaches to lip synchronization. Applicant’s invention is not a source of a technical improvement to blockchain integration. The current application is not defining a new way of performing blockchain integration that is technically superior to prior methods. They describe the operational steps a financial intermediary takes to connect banking customers to DeFi services. Any developer implementing the same financial service would follow the same operational sequence which is precisely why these "rules" don't prevent preemption of the broader blockchain financial integration space. McRO held that eligible claims go "beyond merely using a computer as a tool to automate conventional activity." This test directly defeats the applicant's argument. Every one of these is a conventional financial and operational activity being automated using generic computing infrastructure. This is precisely what McRO said was insufficient and the test McRO established, properly applied, condemns rather than saves these claims.
The applicant has argued “Analogous to Trading Technologies: In Trading Technologies Int'lv. CQG Inc., 675 Fed. Appx. 1001 (Fed. Cir. 2017), the Court held that structured GUI/functionality enabling faster, more accurate trades by displaying market information in a specific way improves trading technology. Our Claims: The structured custodial wallet architecture enabling FI participation in DeFi by pooling funds, mapping ledgers, and processing blockchain APIs in a specific way improves blockchain integration technology.” The examiner respectfully disagrees. In Trading Technologies, the claims were eligible because they recited a specific graphical user interface design a static price axis combined with dynamic quantity display that solved a concrete problem through a specific visual arrangement that traders found more accurate and efficient. The Federal Circuit found the GUI design itself was a technical innovation in how trading interfaces displayed and processed information.Applicant’s invention does not involve a static price axis was a specific, identifiable design departure from conventional dynamic price displays. The applicant has no analogous specific departure from conventional custodial wallet architecture. The applicant's "problem" is regulatory compliance a legal requirement, not a technical deficiency of prior systems. The applicant's improvement is to what financial services are made available a business service enhancement. The Federal Circuit subsequently clarified in Trading Technologies Int'l v. IBG LLC that Trading Technologies applies narrowly to GUI innovations that solve specific technical problems arising from how interfaces display and process information. Courts have consistently refused to extend it to claims that merely use technology to deliver financial services more efficiently. The applicant’s attempt to analogize custodial wallet architecture to a trading interface GUI stretches Trading Technologies is incorrect.
The applicant has argued “Analogous to PEG Example 35: PEG Example 35 states: "Claims add unconventional sequence of steps for ATM authentication such as generating random codes that amount to an inventive concept." Our Claims: Add unconventional sequence of steps for blockchain integration such as pooling funds into custodial FI wallet, maintaining mapped ledgers, creating custodial customer wallet, moving funds, and synchronizing updates that amount to an inventive concept.” The examiner respectfully disagrees. PEG Example 35 involves an unconventional sequence of authentication steps generating random codes that improves the security of the authentication technology itself. The unconventionality is technical: a specific departure from conventional authentication methods that makes the authentication mechanism more secure in a technically demonstrable way. Applicant’s claims are not analogous. Specifically Example 35's sequence improves authentication technology security a technical system benefit. The applicant’s sequence at most improves financial service delivery a business/regulatory benefit. The applicant's sequence of pooling, mapping, creating, moving, synchronizing, and processing does not make any technology more secure, faster, or more reliable. It makes a financial service more compliant with banking regulations. These are different outcomes under 101.
The applicant has argued “ Solves Technology-Specific Problem Not Business Problem The claims solve the technology-specific problem of integrating architecturally incompatible systems (centralized banking vs. decentralized blockchain), not a business problem of conducting financial transactions. Analogous to SRI International: In SRI International, 930 F.3d at 1304, the Court emphasized that "the claims were directed to using a specific technique-generating and using a network activity graph-to solve a technological problem arising in computer networks." Our Claims: Are directed to using a specific technique-custodial wallet pooling with dual ledger mapping and synchronized updates-to solve a technological problem arising in blockchain integration (incompatible system architectures).” In SRI International, the claims were eligible because they recited a specific, novel technique of generating network activity graphs from network monitors and using those graphs to detect intrusions. This solved a problem arising within computer networks themselves (intrusion detection). The court emphasized that the technique was specific enough that it didn't preempt all approaches to network security, and that it represented a genuine technical advance in how network monitoring was performed. The problem in SRI arose within the technology specifically intrusion detection is a problem of computer network security, not a business or regulatory problem that happens to involve computers. The problem identified is KYC compliance and FI risk exposure that arises outside the technology, in regulation and finance. SRI's network activity graph technique was genuinely novel. The custodial wallet pooling with dual ledger mapping was, as established above, already the standard architecture of custodial cryptocurrency exchanges before the priority date. SRI's claims were narrowly tailored to the specific technique, preventing preemption of the broader field of network security. The applicant attempts to frame its architecture as a "specific technique" analogous to SRI's network activity graph. But there is a fundamental difference between: A specific algorithmic technique (generating and analyzing network activity graphs) that constitutes a new way of solving a technical problem and a system architecture description (pool funds, maintain ledgers, map accounts, call APIs) that describes the functional organization of conventional components. System architecture descriptions that organize conventional components toward a functional goal without specifying the technical mechanisms that make the architecture novel do not constitute "specific techniques" under SRI's framework. Applicant’s “problems” arise in regulation and finance and are merely addressed using technology.
The applicant has argued “Technology Problem (Not Business Problem): From Specification paragraph [0011]:"CeFi FIs are excluded from participating in DeFi arrangements due to government regulations (which prohibit direct cryptocurrency involvement by the FIs) and their own risk tolerances." This is a technology integration problem: How to enable centralized systems to interact with decentralized systems when they use incompatible ledger structures, different protocols, and different security models. Technology Solution: The custodial wallet bridge architecture with: . Aggregation layer (pooled FI wallet) . Translation layer (ledger mapping to accounts) . Interface layer (customer wallets). Dynamic bridging (fund movement) " Consistency mechanism (synchronized updates) . Protocol translation (blockchain API processing).” The examiner respectfully disagrees.
According to applicant’s paragraph [0011]'s statement about regulatory exclusion is not a business problem it is a "technology integration problem: How to enable centralized systems to interact with decentralized systems when they use incompatible ledger structures, different protocols, and different security models." This reframing fails immediately because it contradicts the specification's own language. Paragraph [0011] states the problem is exclusion "due to government regulations... and their own risk tolerances." These are explicitly regulatory and institutional constraints. The applicant cannot in prosecution recharacterize its own specification's problem statement as a technology integration problem when the specification itself identifies it as a regulatory compliance problem. Even accepting the reframing, the "technology integration problem" of connecting centralized and decentralized systems was a solved engineering problem. The "incompatible architectures" problem was not this applicant’s problem to solve. An applicant cannot claim credit for solving a problem that was already solved. The Six-Layer Architecture Framework Is not found in the originally filed disclosure. This sophisticated architectural framing appears nowhere in the specification. The specification describes a cloud service that pools funds, maintains ledgers, and calls APIs. The six-layer framework that appears to be designed to make conventional operations sound like sophisticated systems architecture.
The applicant has argued “Analogous to Thales Visionix: In Thales Visionix Inc. v.U.S., 850 F.3d 1343, 121 U.S.P.Q.2d 1898 (Fed. Cir. 2017), the Court held that claims using an unconventional arrangement and calibration of inertial sensors to determine position and orientation of an object on a moving platform were eligible because they "eliminated complications involved in previous solutions" and provided "a technological solution to a technological problem." Our Claims: Use unconventional arrangement of custodial wallets with ledger mapping to enable FI participation in blockchain services. This eliminates complications involved in previous solutions (FIs unable to participate due to regulatory and architectural barriers) and provides a technological solution to a technological problem (integrating incompatible system architectures).” The examiner respectfully disagrees. In Thales Visionix, the claims were eligible because they recited a specific unconventional arrangement of inertial sensors placing sensors on both the moving platform and the tracked object that eliminated mathematical complications in prior position-tracking solutions. The unconventionality was in the defined sensor placement on specific physical objects, the specification showed exactly how the arrangement eliminated prior mathematical complications, and in the prior systems used sensors differently, creating the complications the invention solved. Applicant’s invention "unconventional arrangement of custodial wallets" has no physical analog. Custodial wallets are software constructs, and their "arrangement" pooled FI wallet connected to customer sub-wallets via a cloud ledger is the standard architecture of every custodial exchange. Applicant’s invention does not demonstrate technical elimination of complications. The applicant's specification never identifies specific technical complications of prior blockchain integration that its architecture eliminates only regulatory complications. The custodial wallet arrangement here is exactly how cryptocurrency custody was conventionally implemented. The applicant argues its architecture "eliminates complications involved in previous solutions (FIs unable to participate due to regulatory and architectural barriers)." But Thales' "eliminating complications" referred to mathematical and computational complications in the tracking algorithm technical problems with how the technology performed its function.
The applicant has argued “Analogous to Packet Intelligence: In Packet Intel, the Court held that "Claims recite specific packet manipulation steps to yield useful network traffic data. Improves monitoring tech itself." Our Claims: Recite specific fund pooling, ledger mapping, wallet creation, fund movement, and blockchain API processing steps to yield integrated blockchain participation. Improves blockchain integration tech itself.” The examiner respectfully disagrees. Packet Intelligence involved claims that manipulated specific packet-level data examining packet contents, flow signatures, and protocol identifiers in ways that improved network monitoring technology at a technical level. The improvement was to how network monitoring itself functioned packets were analyzed more accurately, yielding better traffic classification. The parallel the applicant draws "specific fund pooling, ledger mapping, wallet creation, fund movement, and blockchain API processing steps to yield integrated blockchain participation" fails the analogy on every point. Examining and classifying network packets involves direct manipulation of data structures at a protocol level. Moving account balances between database records is a financial operation. The "data" being manipulated is financial value, not network protocol data. Under CyberSource, financial data manipulation does not constitute technical article transformation or technical data processing improvement. The Packet Intelligence claims made network monitoring technology work better. The applicant’s claims make financial services more available a business outcome, not a technical monitoring improvement. Under Packet Intelligence's own framework, the improvement must be to how the technology performs its monitoring/processing function. The applicant’s specification never describes any improvement to how blockchain processes transactions, how APIs function, or how any underlying technology performs its technical function.
The applicant has argued “Analogous to PEG Example 38: PEG Example 38 states: "Claims recite using a digital computer to simulate circuit component variances by incorporating random factors into an emulation algorithm, providing a specific simulation technique." Our Claims: Recite using cloud-hosted service to bridge incompatible systems by incorporating custodial wallet architecture with dual ledger mapping into blockchain integration, providing a specific bridging technique.” The examiner respectfully disagrees. PEG Example 38 involves using a digital computer to simulate circuit components by incorporating random factors into an emulation algorithm. The eligibility derives from the specific algorithm random factor incorporation into emulation that constitutes a genuine technical contribution to simulation technology. The applicant's analog "incorporating custodial wallet architecture with dual ledger mapping into blockchain integration" fails because Example 38's random factor algorithm is a specific mathematical/technical contribution to simulation. Custodial wallet architecture is a financial organizational structure, not a mathematical or technical algorithm Example 38's algorithm improves how simulation technology performs.
The applicant has argued “Analogous to PEG Example 40: PEG Example 40 states: "Claims recite monitoring network traffic data integrated into improved data collection by selectively filtering packets based on traffic analysis." Our Claims: Recite pooling funds and maintaining ledgers integrated into improved blockchain integration by selectively moving funds between custodial wallets based on customer transactions.” The examiner respectfully disagrees. PEG Example 40 involves selectively filtering packets based on traffic analysis a specific technical operation on network data that improves data collection technology. The selective filtering is a technical process operating on technical artifacts (network packets). The applicant’s analog "selectively moving funds between custodial wallets based on customer transactions" substitutes a financial operation (moving money) for a technical operation (filtering packets). Moving funds between accounts based on customer requests is the most conventional banking operation imaginable. It bears no technical relationship to selective packet filtering based on algorithmic traffic analysis.
The applicant has argued “Analogous to PEG Example 41: PEG Example 41 states: "Claims integrate mathematical encryption algorithms into improved communications security by encrypting messages between computer terminals over a network. Our Claims: Integrate custodial wallet management and ledger mapping into improved financial system integration by bridging communications between centralized and decentralized systems through cloud-hosted architecture." The examiner respectfully disagrees. PEG Example 41 involves mathematical encryption algorithms integrated into communications security a specific mathematical transformation of data that protects information technically. The encryption algorithm is the invention; it transforms data in a mathematically specific, technically unconventional way. The applicant’s analog "integrating custodial wallet management and ledger mapping into improved financial system integration" substitutes financial management operations for mathematical encryption algorithms. There is no mathematical transformation, no data encryption, and no technical security improvement in the applicant's claims. The analogy requires a mathematical/algorithmic core that simply does not exist in these claims.
The applicant has argued “Specific Evidence Required Under Berkheimer Per Berkheimer, 881 F.3d 1360, whether elements are well-understood, routine, or conventional requires factual findings supported by evidence. The Examiner has not met this burden. The Examiner Must Provide: . Prior art showing custodial wallet pooling with ledger mapping to specific accounts . Technical documentation showing this combination was conventional in 2017 " Industry standards showing synchronized multi-ledger updates were routine. Evidence that blockchain API processing for FI isolation was well-understood. No such evidence has been provided.” The examiner respectfully disagrees. It is noted that the Examiner did not find any additional element or combination of elements in the rejected claims that are recognized as well-understood, routine, and conventional activities. However, Berkheimer does not require the Examiner make a factual finding that all claim elements are well-understood, routine or conventional. Rather, a Berkheimer factual is required for additional elements or a combination of additional elements outside of the identified abstract idea. See Berkheimer Memo. P. 2. Therefore the previous 101 is maintained and updated below in view of applicant’s amendments. Even if the invention has no prior art it still must not be an abstract idea or a mere routine/conventional method. The lack of prior art does not make an abstract idea eligible.
The applicant has argued “Analogous to Exergen: In Exergen Corp. v. Kaz USA, Inc., 725 Fed. Appx. 959 (Fed. Cir. 2018), the Court held that "Unconventional measurement technique with time sequences & constants constitutes inventive concept and improvement in temperature detection tech." Our Claims: Unconventional custodial wallet architecture with ledger mapping and synchronized updates constitutes inventive concept and improvement in blockchain integration tech.” The examiner respectfully disagrees. Exergen Involved a Specific Unconventional Physical Measurement Technique In Exergen, the claims recited a specific, unconventional technique for measuring body temperature using a temporal artery scanning method with specific mathematical constants that accounted for heat dissipation in a technically precise way. The Federal Circuit found this eligible because: The measurement technique was physically and mathematically specific It was genuinely unconventional prior thermometers measured differently. The specification disclosed why the constants and time sequences were unconventional. The improvement was to temperature detection technology itself None of these elements exist here. The applicant’s custodial wallet architecture is not physically specific, not genuinely unconventional relative to prior cryptocurrency custody systems, not disclosed in the specification as unconventional with supporting technical reasoning, and does not improve any measurement or detection technology.
The applicant has argued “II. EXAMINER FAILED TO PROVIDE PROPER CLAIM-BY-CLAIM ANALYSIS Per MPEP §2106.07(a), examiners must provide individualized analysis for each claim. If the rejection improperly grouped claims together, applicant respectfully requests claim-by-claim analysis showing how each dependent claim is ineligible.” The examiner respectfully disagrees. The examiner has rejected each claim on its merits. As can be seen in the 101 rejection below, the additional elements of the dependent claims, when considered both individually and in the context of the independent claims were analyzed for both practical application and significantly more. Although the applicant included a chart at the end, each Case and PEG example in the chart was addressed previously in the arguments.
In conclusion the applicant argued “For the foregoing reasons, amended claims 1 and 19 (and their dependent claims) are patent eligible under 35 U.S.C. § 101. The claims: 1. Do not recite judicial exceptions when analyzed as a whole under Enfish and McRO 2. Integrate any recited exceptions into practical applications through multiple independent bases 3. Provide inventive concepts through unconventional combinations and specific technical implementations 4. Improve blockchain integration technology itself, not merely business practices 5. Solve technology-specific problems through specific technical architectures 6. Are directly analogous to numerous Federal Circuit and PTAB decisions finding eligibility.” The examiner respectfully disagrees.
1) "Do not recite judicial exceptions when analyzed as a whole under Enfish and McRO.” Both cases require that the claims be directed to improvements in technology itself not improvements in how technology is used to deliver financial services. Analyzed as a whole under Enfish and McRO, the claims are directed to the abstract idea of regulated financial intermediation. The technical components blockchain, SSI, APIs, cloud infrastructure are instruments of that financial intermediation, not subjects of technical improvement. Enfish and McRO have been distinguished on this basis, and that distinction applies with full force to the conclusion.
2) "Integrate exceptions into practical applications through multiple independent bases"
The applicant has advanced five independent bases for practical application integration: technical improvement, particular machines, meaningful application, transformation, and unconventional combination. Each has been independently defeated. The multiplicity of theories does not create eligibility it reflects the absence of a single compelling theory.
3) "Provide inventive concepts through unconventional combinations and specific technical implementations" The unconventional combination argument has been defeated by independent lines of evidence: the specification's own functional descriptions admitting conventionality and the legal standard requiring technical unconventionality demonstrated in the specification rather than asserted in prosecution. The "specific technical implementation" argument has been defeated by the consistent Federal Circuit standard requiring that claims recite technical mechanisms rather than functional results a standard these claims fail throughout.
4) "Improve blockchain integration technology itself, not merely business practices". The application does not improve blockchain technology, API architecture, SSI protocols, cloud infrastructure, or any other technology it uses. Every component operates exactly as designed. The improvement the application achieves enabling banks to offer DeFi services while maintaining KYC compliance is a business and regulatory improvement delivered through technology, not a technical improvement to technology. This distinction is the Alice line, and this application falls on the wrong side of it.
5) "Solve technology-specific problems through specific technical architectures". The problems identified in the specification government regulations prohibiting FI cryptocurrency involvement and KYC compliance requirements are regulatory and institutional problems, not technology-specific problems. They are identified as such in the applicant's own specification. No amount of technical vocabulary in prosecution arguments can change what the specification says. The "specific technical architectures" presented the six-layer framework of aggregation, translation, interface, bridging, consistency, and protocol layers appear nowhere in the specification.
6) "Directly analogous to numerous Federal Circuit and PTAB decisions finding eligibility" The applicant has invoked eighteen cases and USPTO examples in support of eligibility. Every single one has been distinguished on the same ground. Each of the argued examples/cases involve genuine technical improvements to underlying technology, disclosed in the specification with technical specificity, solving problems arising within the technology. This claimed invention has none of these characteristics. The volume of cases invoked is not evidence of analogical strength. Among the applicant's case citations is what is absent from them as no case in which a financial intermediation architecture however technically implemented was held eligible under 101. Alice itself, the Supreme Court's most recent 101 decision involving financial technology was held as an ineligible a system remarkably similar in functional conception to this one. The applicant has not distinguished Alice merely attempted to characterize its claims using the vocabulary of cases that distinguished Alice in technically specific ways that this current application cannot replicate. Although the claims include blockchain ledgers and cloud hosted services, the claims do not disclose doing anything specific, or any different than a general purpose computer.
Although the applicant has presented an overabundance of arguments with regards to the 101 rejection, the arguments are not found persuasive and the previous 101 rejection is withheld and updated in view of applicant’s amendments.
Applicant’s arguments, see the previous 112(a), first paragraph and 112(b), second paragraph rejection of claims 1-11, 19-20 have been fully considered. The applicant has amended claims 1-11, 19-20 to overcome the previous 112(a), first paragraph and 112(b), second paragraph rejections.
The applicant has argued the previous 103 rejection in view of amendments. Applicant’s arguments, see pg. 8-11, filed 5/25/2025 with respect to the previous 103 rejections have been fully considered and are persuasive. The prior art references separately and in combination do not specifically teach all the limitations of claims 1 and 19, specifically, managing interactions and transactions between the customer operating the application and the decentralized network service based on the notification, creating a custodial customer wallet and moving funds, wherein the managing comprises hosting decentralized finance (DeFi) services through a cloud-hosted service while the FI provides centralized finance (CeFi) services with the FI through the application, with cryptocurrency services held by the cloud- hosted service. The previous 103 rejection of claims 1-11 and 19-20 had previously been withdrawn.
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-11, 19-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter because the claim(s) as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea. The claim(s) is/are directed to the abstract idea of managing interactions and transactions between an application and a decentralized network service. The claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-11 are directed to a method, claims 19-20 are directed to a system. Therefore, claims 1-11, 19-20 are directed to patent eligible categories of invention.
Step 2A Prong 1: The claim(s) recite(s) (mathematical relationships/formulas, mental process or certain methods of organizing human activity). Specifically the independent claims recite:
(a) mental process: as drafted, the claim recites the limitations of detecting a connection attempt, facilitating a connection, receiving a notification, pooling together funds, maintaining ledgers, creating a custodial customer wallet, moving funds, updating ledgers, processing the blockchain, integrating services, obtaining a relation, passing the relation, permitting access, and managing interactions and transactions, which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting generic processing devices nothing in the claims precludes the receiving steps from practically being performed in the human mind. For example, but for the network, the claim encompasses the user manually detecting a connection, facilitating the connection, receiving information, pooling, maintaining, creating, moving, updating, processing, integrating, obtaining, passing, permitting, and managing the interactions and transactions. The mere nominal recitation of a generic interface does not take the claim limitation out of the mental processes grouping. The claims provide no insight to improvements in computer functionality beyond what one would expect from using a generic computer as a tool in performing the scheme as claimed. This limitation is a mental process.
(c) certain methods of organizing human activity: The claim as a whole recites a method of organizing human activity. The claimed invention is a method that allows for users to manage transactions and interactions, which is a method of commercial and legal interactions. The claim also involves the creating of financial wallets and the moving of money around which would be a fundamental economic practice. Thus, the claim recites an abstract idea. “Commercial or Legal Interactions” According to the 2019 PEG, “commercial interactions” or “legal interactions” include subject matter relating to agreements in the form of contracts. Managing Personal Behavior or Relationships or Interactions Between People The sub-grouping “managing personal behavior or relationships or interactions between people” include social activities, teaching, and following rules or instructions.
Step 2A, Prong 2: Independent claims 1, 19, do not integrate the judicial exception into a practical application. Claim 1 is a method comprising “decentralized network service from an application that provides centralized network services… decentralized identifier (DID) connection … financial institution (FI) wallet … using a Self-Sovereign Identity (SSI) provider… a blockchain using blockchain application programming interfaces (APIs)… a custodial FI wallet… cloud-hosted service… a custodial customer wallet… the application and the decentralized network service based on the notification, … decentralized finance (DeFi) services through a cloud-hosted service while the FI provides centralized finance (CeFi) services with the FI through the application, with cryptocurrency services strictly controlled and held by the cloud- hosted service.” Claim 19 is a system comprising “a cloud comprising a plurality of servers; each server comprising at least one processor and a non-transitory computer-readable storage medium; each non-transitory computer-readable storage medium comprising executable instructions; the executable instructions when provided to or obtained by a corresponding processor from a corresponding non-transitory computer-readable storage medium cause the corresponding processor to perform operations, comprising: decentralized network services into an application associated with centralized network services… wherein the centralized network services and the application… decentralized network service… a Decentralized Identifier (DID) associated with a customer wallet of the customer… establish a DID connection to the customer wallet using a Self-Sovereign Identity (SSI) provider that pre-registered Personal Identifiable Information (PII) of the customer and provided the customer wallet a credential, wherein the DID connection comprises an anonymous, encrypted, and peer-to-peer connection resolved through a blockchain using blockchain application programming interfaces (APIs)…the SSI provider … DID connection, the FI retaining a verification in account records associated with the customer to satisfy Know Your Customer (KYC) requirements adhered to by the FI … a custodial FI wallet… cloud-hosted service… a custodial customer wallet…decentralized network service for a transaction through the application… hosting decentralized finance (DeFi) services through a cloud-hosted service while the FI provides centralized finance (CeFi) services through the application, …the cloud-hosted service.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f). The claim employs generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment. This type of generally linking is not sufficient to prove integration into a practical application. See MPEP 2106.05(h).
Therefore, the additional elements of the independent claims, when considered both individually and in combination, are not sufficient to prove integration into a practical application.
Dependent claims 5, 8, 9, further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which does not integrate the judicial exception into a practical application.
Dependent claims 2, 4, 6, 20, introduces the further additional elements of “decentralized network.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f). This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 3 introduces the further the additional elements of “centralized network services.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f). This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 7 introduces the additional element of “using a credential issued by an SSI.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 10, 11 introduces the additional element of “a blockchain,” and a “non-blockchain.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Therefore, the additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not sufficient to prove integration into a practical application.
Step 2B: Independent claims 1, 19, do not comprise anything significantly more than the judicial exception. As can be seen above with respect to Step 2A, Prong 2, Claim 1 is a method comprising “decentralized network service from an application that provides centralized network services… decentralized identifier (DID) connection … financial institution (FI) wallet … using a Self-Sovereign Identity (SSI) provider… a blockchain using blockchain application programming interfaces (APIs)… a custodial FI wallet… cloud-hosted service… a custodial customer wallet… the application and the decentralized network service based on the notification, … decentralized finance (DeFi) services through a cloud-hosted service while the FI provides centralized finance (CeFi) services with the FI through the application, with cryptocurrency services strictly controlled and held by the cloud- hosted service.” Claim 19 is a system comprising “a cloud comprising a plurality of servers; each server comprising at least one processor and a non-transitory computer-readable storage medium; each non-transitory computer-readable storage medium comprising executable instructions; the executable instructions when provided to or obtained by a corresponding processor from a corresponding non-transitory computer-readable storage medium cause the corresponding processor to perform operations, comprising: decentralized network services into an application associated with centralized network services… wherein the centralized network services and the application… decentralized network service… a Decentralized Identifier (DID) associated with a customer wallet of the customer… establish a DID connection to the customer wallet using a Self-Sovereign Identity (SSI) provider that pre-registered Personal Identifiable Information (PII) of the customer and provided the customer wallet a credential, wherein the DID connection comprises an anonymous, encrypted, and peer-to-peer connection resolved through a blockchain using blockchain application programming interfaces (APIs)…the SSI provider … DID connection, the FI retaining a verification in account records associated with the customer to satisfy Know Your Customer (KYC) requirements adhered to by the FI … a custodial FI wallet… cloud-hosted service… a custodial customer wallet…decentralized network service for a transaction through the application… hosting decentralized finance (DeFi) services through a cloud-hosted service while the FI provides centralized finance (CeFi) services through the application, …the cloud-hosted service.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f). The claim employs generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment. This type of generally linking is not anything significantly more than the judicial exception. See MPEP 2106.05(h).
The additional elements of the independent claims, when considered both individually and in combination, do not comprise anything significantly more than the judicial exception.
Dependent claims 5, 8, 9, further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which is not anything significantly more than the judicial exception.
Dependent claims 2, 4, 6, 20, introduces the further additional elements of “decentralized network.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f). This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 3 introduces the further the additional elements of “centralized network services.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f). This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 7 introduces the additional element of “using a credential issued by an SSI.” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 10, 11 introduces the additional element of “a blockchain,” and a “non-blockchain.” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
The additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not anything significantly more than the judicial exception.
Accordingly, claims 1-11, 19-20 are rejected under 35 USC 101.
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 3 is 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.
Regarding claims 3 phrase "a custodial wallet for the FI" renders the claim indefinite because it is unclear in the claim if this is the same custodial wallet claimed previously in claim 1.
Pertinent prior art
Pertinent prior art includes Lemieux et al. (US 20230315904 A1) discloses transferring personal data with a granularity established by the owner of the personal data. Kravitz et al. (US 20220385477 A1) discloses the preservation of privacy. Mayblum et al. (US 20200042996 A1) discloses transaction between a first entity and a second entity using a digital currency. Bernardi (US 11914684 B2) which discloses private blockchain and secure group node segmentation for sensitive data. Ryan et al. (US 20210366586 A1) discloses data that is generated at a point of sale (POS) and/or retail store server and the data is stored, at least in part, on a blockchain database or other secure database. Vigier et al. (US 20130110678 A1) discloses purchasing of a product in a store using a mobile device. Murdoch et al. (US 20200336483 A1) discloses a DID owner controlling a DID that represents an identity of a DID owner. Lougheed et al. (US 20200220726 A1) which discloses recurring presentation of a credential includes sending a credential presentation subscription request from a subscriber to a holder. Toth (US 20190097812 A1) which discloses user authentication, cryptographic methods, and hashing, with identity specification, virtualization, proofing, and attestation.
Conclusion
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 JAMIE H AUSTIN whose telephone number is (571)272-7363. The examiner can normally be reached Monday, Tuesday, Thursday, Friday 7am-2pm.
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, Brian Epstein can be reached at (571) 270 5389. 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.
JAMIE H. AUSTIN
Examiner
Art Unit 3625
/JAMIE H AUSTIN/Primary Examiner, Art Unit 3625