DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Jul. 8, 2025, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when emailing the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on Jul. 8, 2026, was filed before the mailing of a first office action on the merits and therefore, is in compliance with the provisions of 37 CFR 1.97(b)(3). Accordingly, the IDS has been considered.
Claim Status
The status of claims is as follows:
Claims 1–20 are pending and examined with Claims 1, 14, and 20 in independent form.
This is a first action on the merits.
Claim Objections
Claims 1, 14, and 20 are objected to because of the following informalities. Appropriate correction is required.
Claims 1, 14, and 20: Independent Claims are objected to for grammar in the following limitation of Independent Claims: “an income stream recorded on a distributed ledger as a soulbound token deposited in a digital wallet of an owner of the income stream and configured to be non-transferable from the digital wallet.” The placement of the underlined element does not identify the noun modified by that phrase (i.e., what is configured to be non-transferable … the income stream? soulbound token? digital wallet?). Although Spec. ¶ 28 makes clear that the underlined element modifies the soulbound token, Claim 1 should be revised to identify that relationship. Examiner suggests: “an income stream recorded on a distributed ledger as a soulbound token, the soulbound token being deposited in a digital wallet of an owner of the income stream and configured to be non-transferable from the digital wallet.”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–20 are directed to a statutory category. Claims 1–13 recite a “system” and are therefore, directed to the statutory category of a “machine.” Claims 14–19 recite “method” and are therefore, directed to the statutory category of a “process.” Claim 20 recites a “non-transitory computer-readable medium storing processor-executable instructions” and is therefore, directed to the statutory category of an "article of manufacture.”
Representative Claim
Claim 1 is representative [“Rep. Claim 1”] of the subject matter under examination. Normal font is used for limitations that recite the judicial exception. Bold font is used to indicate additional elements evaluated under Step 2A, Prong Two (practical application) and Step 2B (significantly more). Italics font is used where necessary to identify intended use limitations1 and underline font is used, as needed, in further describing the judicial exception. Each limitation is identified by a letter designator for use as a shorthand notation when analyzing/referencing each limitation. Rep. Claim 1 recites:
[A] 1. A system for managing income streams using machine learning, the system comprising: one or more processors;
[B] one or more memories storing a machine learning model that is trained using historical financial data to manage an income stream recorded on a distributed ledger as a soulbound token deposited in a digital wallet of an owner of the income stream and configured to be non- transferable from the digital wallet;
[C] the one or more memories further storing a set of computer-executable instructions that, when executed, cause the system to:
[D] receive, from a computing device, distribution criteria including information for distributing at least a portion of income received from the income stream to one or more distribution recipients;
[E] obtain soulbound token information associated with the soulbound token and the income stream of the owner;
[F] analyze, by the machine learning model, the distribution criteria and the soulbound token information to generate one or more distribution insights associated with optimizing distribution of at least the portion of the income; and
[G] generate, by the machine learning model, one or more distribution schemes associated with distributing at least the portion of the income to the one or more distribution recipients, based upon the one or more distribution insights.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 1 recites “[A] … managing income streams using machine learning … [B] … manage an income stream … [D] receive … distribution criteria including information for distributing at least a portion of income received from the income stream to one or more distribution recipients; [E] obtain soulbound token information … and the income stream of the owner; [F] analyze … the distribution criteria and the soulbound token information to generate one or more distribution insights associated with optimizing distribution of at least the portion of the income; and [G] generate … one or more distribution schemes associated with distributing at least the portion of the income to the one or more distribution recipients, based upon the one or more distribution insights,” which recites a commercial interaction or fundamental economic practice under the organizing human activity exception because the claims recite management and distribution of income between two or more parties. MPEP § 2106.04(a)(2)(II)(A), (B).
Alternatively2, Limitations D–G, as drafted, recite the abstract idea exception of mental processes that under the broadest reasonable interpretation, cover performance in the human mind or with pen and paper, but for the recitation of the generic computer components indicated in bold. MPEP § 2106.04(a)(2)(III).
Claims recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include:
• a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
. . .
• a claim to collecting and comparing known information (claim 1), which are steps that can be practically performed in the human mind, Classen Immunotherapies, Inc. v. Biogen IDEC, 659 F.3d 1057, 1067, 100 USPQ2d 1492, 1500 (Fed. Cir. 2011).
MPEP § 2106.04(a)(2)(III)(A). For example, but for the generic computer components claim language, here, Limitations D–G, recite collecting information (Limitations D, E) and analyzing it (Limitations F, G), where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind. For example, Limitations F and G are mental processes that are practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” “analyze … the distribution criteria and the soulbound token information to generate one or more distribution insights associated with optimizing distribution of at least the portion of the income” and “generate … one or more distribution schemes associated with distributing at least the portion of the income to the one or more distribution recipients, based upon the one or more distribution insights in any possible way. A human financial advisor could review the owner’s income information, consider the owner’s criteria, determine an advantageous allocation (such as to keep taxes as low as reasonably achievable), and recommend a distribution plan, (exactly the type of advisory service the Specification itself describes Spec. ¶¶ 3, 4.), which are all “observation, evaluation, judgment, and/or opinion” falling in the mental process grouping under MPEP § 2106.04(a)(2)(III); Spec. ¶¶ 3, 4. The ML model does not prevent this conclusion. Claims can recite a mental process even when the claimed process is performed by a computer provided that the underlying analysis is the type of activity that humans can practically perform. Likewise, “[t]he use of a physical aid (e.g., pencil and paper or a slide rule) to help perform a mental step (e.g., a mathematical calculation) does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another” or a multi-step mental process. MPEP § 2106.04(a)(2)(III)(B).
If a claim limitation under BRI, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract idea exception. MPEP § 2106.04(a)(2)(III).
Accordingly, the pending claims recite abstract ideas falling within both the organizing human activity and mental process groupings.
Step 2A, Prong Two: The additional elements identified in Rep. Claim 1, considered individually and as an ordered combination, do not integrate the abstract idea exception into a practical application. MPEP § 2106.04(d).
The additional elements are indicated in bold font, supra. The additional elements are: A system comprising: one or more processors; [B] one or more memories storing a machine learning model that is trained using historical financial data; an income stream recorded on a distributed ledger as a soulbound token, [the soulbound token being] deposited in a digital wallet of an owner of the income stream and configured to be non-transferable from the digital wallet; [C] the one or more memories further storing a set of computer-executable instructions that, when executed, cause the system to [perform operation]; and a computing device.
The additional elements do not improve the functioning of a computer or other technology. MPEP § 2106.05(a).
A claim improves technology only when it recites a specific improvement to the way a computer itself operates, not merely the application of an existing process using a computer. MPEP § 2106.05(a) (citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016)). Here, the abstract idea exception was previously performed manually. Spec. ¶¶ 3, 4. The Specification confirms that individuals have historically managed “multiple income streams, such as pensions, social security benefits, personal investments, etc.” through traditional, human-administered income management, which is described as lacking only convenience and personalization. Spec. ¶¶ 3, 4. Because the process can be performed manually, the computer is not being improved and is merely being used as a tool to perform the pre-existing manual process. Applying a pre-existing manual process using generic computer components is not an improvement to computer technology.
The specification confirms this characterization by describing the advantages of the claimed system in terms of business and record-keeping outcomes (i.e., (1) “view and manage multiple income streams in one place” (Spec. ¶ 30); (2) “transparency and auditability [ ] for detection of fraud, data breaches, or other unauthorized access” (Spec. ¶ 30); and (3) reduced memory for “systems, devices, and/or platforms providing the income stream management via a single medium (the distributed ledger) when compared to “managing income streams via disparate systems” (Spec. ¶ 33); rather than in terms of any specific technical improvement to distributed ledger consensus algorithms, cryptographic techniques, machine learning model architecture, network protocols, or computer architecture. Spec. ¶¶ 30, 33. The Specification does not describe any specific technical improvement to validation/consensus algorithms (Spec. ¶ 61 (consensus algorithms described as interchangeable and merely an example and not intended to be limiting)); to the ERC-5484 token standard (Spec. ¶ 28); to encryption (Spec. ¶ 59 (“may include encryption”); or to any data structure, network protocol, or computer architecture. Spec. ¶¶ 28, 52, 57, 59, 61. Thus, any improvements described are improvements to business/record-keeping outcomes (centralized, auditable tracking of income distribution) and not technical improvements to the computers or machine learning technology themselves.
To the extent the claimed invention is asserted to provide a technical solution, that solution is not commensurate with the scope of the claims. The specification describes the alleged technical solution as a particular sequence of distributed ledger operations: For example only, (1) minting a soulbound token via blockchain transaction that is validated according to a consensus mechanism before a node adds it to a new block (Spec. ¶¶ 59, 129–131); (2) depositing the minted token into a digital wallet, which “may occur in a manner similar to that described with respect to minting the soulbound token (block 730)” (Spec. ¶ 133); and (3) generating an associated smart contract configured to automatically … distribut[e] income, based upon the occurrence of … a time-based trigger (e.g., a date to distribute income), an event-based trigger (e.g., an account balance exceeding a threshold, a stock market condition), or manual trigger” (Spec. ¶ 136). The claims, however, do not capture this solution. For example, only, Independent Claims 1, 14, and 20 do not recite validating the soulbound token or smart contract transaction according to any consensus mechanism and do not recite generating a smart contract or any particular trigger condition. Because Independent Claims 1, 14, and 20 omit the specific technical mechanics the Specification identifies as the technical solution and because Dependent Claims 7, 13, and 19 do not recite any particular consensus mechanism, trigger logic, or smart contract architecture, any purported technical solution is not commensurate with the scope of the claims. Under MPEP § 2106.05(a), the claims must recite the improvement with sufficient specificity to reflect how the improvement is achieved, rather than claiming the desired outcome using generic components.
The additional elements do not apply the abstract idea with a particular machine.
Although the claims recite specific hardware components (i.e., one or more processors, one or more memories, a distributed ledger, and a computing device), these components are recited at a high functional level and perform only their generic functions of receiving, transmitting, storing, and processing data. Spec. ¶¶ 35, 39, 40, 50. A machine is “particular” only when it imposes a meaningful limit on the claims scope. MPEP § 2106.05(b). Here, any general-purpose processor, memory, or computing device or network node would satisfy the claim’s hardware requirements, which confirms that the hardware components are generic rather than “particular.” MPEP § 2106.05(b). The specification describes each computer component using broad, open-ended language (e.g., the computing environment “may include, in some embodiments, a computing device 110, a user computing device 140, and network nodes 150, 160, which may be communicatively connected through a network 170 as described below. It will be understood that the example computing environment 100 may include additional, fewer, and/or alternate components.” Spec. ¶ 35) without restricting the claimed hardware to any particular design, configuration, or architecture. Spec. ¶ 35.
The additional elements are: (1) mere instructions to apply the abstract idea exception, MPEP § 2106.05(f); (2) generally link the judicial exception to a particular technological environment, MPEP § 2106.05(h); and/or (3) are insignificant extra solution activity; MPEP § 2106.05(g).
Regarding the additional elements, Applicant’s Specification does not otherwise describe them with specificity beyond exemplary language and instead describes them as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. Spec. ¶¶ 39, 40. The specification’s own broad, exemplary characterization confirms that these components are not described in a manner that would impose any specific technical limitation that would integrate the abstract idea into a practical application. The specification failure to describe these components in any detail beyond exemplary language is itself an admission that the components are so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). See, Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Myers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”).
The generic processor, here, performs calculations (functions) and executes instructions that are programmed by software directed to the abstract idea. Spec. ¶ 39. This is a computer doing what it is designed to do—performing directions it is given to follow, and whose directions are directed to the abstract idea.
Regarding the trained machine learning model, Applicant’s Specification explains it can be created in any known way using any known, AI, machine learning, or neural network technique, such that it could be almost anything. Spec. ¶ 34 (“artificial intelligence (AI) may refer to one or more technologies, such as but not limited to, machine learning (ML), (recurrent) neural networks, generative adversarial networks, and/or AI/ML models”); Spec. ¶ 43 (“machine learning model [ ] is trained to manage an income stream using training data including historical financial data … or other suitable training data.”); Spec. ¶ 47 (linear or logistic regression, instance based algorithms, regularization algorithms, decision trees, Bayesian networks, cluster analysis, association rule learning, artificial neural networks, deep learning, combined learning, reinforced learning, dimensionality reduction, and support vector machines. In various embodiments, the implemented machine learning methods and algorithms are directed toward at least one of a plurality of categorizations of machine learning, such as supervised learning, unsupervised learning, and reinforcement learning. In some aspects, the machine learning based algorithms may be included as a library or package executed on the server(s) 110. For example, libraries may include the TensorFlow based library, the PyTorch library, and/or the scikit-learn Python library.”). The trained model itself is created outside the scope of the claims and as claimed, receives inputs and provides an output, in this case an output of “one or more distribution schemes,” like any model. Therefore, the “trained machine learning” characterization of the “model” is merely a label describing its intended use and imparts no functional aspect to the claimed “model.” This describes a solution merely at the level of a “generic black box” for generating one or more distribution schemes and reads neatly on “use a computer” to do it in any way. MPEP § 2106.05(f); see also, Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205 (Fed. Cir. 2025) (holding “that patents that do no more than claim the application of generic machine learning to new data environments, without disclosing improvements to the machine learning models to be applied, are patent ineligible under § 101”).
Limitations A, B, and C further describes the processor executing instructions stored in at least one memory device to perform the steps of the claimed invention. This takes generic hardware and describes the functions of receiving, storing, and sending data (instructions) between the processor and memory device, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Limitations D–G describe the processor, memory device, and instructions, performing the steps of the claimed invention, which represents the abstract idea exception itself on a general-purpose computer. Performing the steps of the abstract idea exception using a computer, merely adds a general-purpose computer after the fact to an abstract idea exception without imposing any meaningful technical limitations. MPEP § 2106.05(f)(2). Alternatively, the claim generically recites an effect of the abstract idea without specifying how the computer achieves that effect in any technically meaningful way. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, considering the additional elements individually and as an ordered combination, amounts to no more than mere instructions to apply the abstract idea using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 1 is directed to an abstract idea.
Independent Claims 14 and 20 are not substantially different than Rep. Claim 1, recite the same abstract idea as Rep. Claim 1, and contain no additional elements not otherwise analyzed for Rep. Claim 1. Therefore, Independent Claims 14 and 20 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 1 fails Step 2B because the claim as a whole, even when considering the additional elements individually and in combination, does not amount to significantly more than the abstract idea. MPEP § 2106.05 . The additional elements (i.e., A system comprising: one or more processors; [B] one or more memories storing a machine learning model that is trained using historical financial data; an income stream recorded on a distributed ledger as a soulbound token, [the soulbound token being] deposited in a digital wallet of an owner of the income stream and configured to be non-transferable from the digital wallet; [C] the one or more memories further storing a set of computer-executable instructions that, when executed, cause the system to [perform operation]; and a computing device), are each well-understood, routine, and conventional (“WRC”) computer components and functions in the relevant field, as evidenced by Applicant’s own disclosure3. Further, Applicant’s Specification discloses that the recited method steps/operations may be performed in any order or concurrently, and that the recited components are implemented using generic, off the shelf computing technology. Spec. ¶ 189 (individual operations “may be performed concurrently, and nothing requires that the operations be performed in the order illustrated”); Spec. ¶¶ 39, 40, 47, 61 (describing the processor, memory, machine learning libraries, and distributed ledger consensus algorithms using exemplary language as generic or known computing equipment and techniques.)
(1) A system comprising: one or more processors, one or more memories further storing a set of computer-executable instructions that, when executed, cause the system to [perform operation]; and a computing device) is WRC in the financial technology field. Spec. ¶¶ 39, 40, 49.
(2) one or more memories storing a machine learning model that is trained using historical financial data to manage an income stream is WRC as to the recited model architecture because the Specification teaches that the recited model may be any supervised learning model trained on historical financial data using standard features vectors, loss functions, and off the shelf libraries, without specifying a particular novel architecture. Spec. ¶¶ 43, 47, 48. This finding establishes that the recited type of machine learning model is generic and interchangeable.
(3) Regarding the claimed distributed ledger, soulbound token, and digital wallet, are WRC. The Specification identifies an existing token standard and ordinary component functions. Spec. ¶ 28 (soulbound token defined by ERC-5484 standard); ¶ 61 (Distributed ledger consensus algorithms are interchangeable examples); Spec. ¶¶ ¶¶ 115, 140, 141 (The digital wallet is describes as performing only ordinary receipt, holding, and distribution functions.)
Regarding an income stream recorded on a distributed ledger as a soulbound token, [the soulbound token being] deposited in a digital wallet of an owner of the income stream and configured to be non-transferable from the digital wallet, the following prior art corroborate that these functions were established and WRC before the effective filing date of Oct. 28, 2024.
NPL ERC-5192: Minimal Soulbound NFTs, July 1, 2022, [“NPL ERC-5192”] defined a soulbound token as “a nonfungible token bound to a single account” (p. 1) and provided an “interface” through which a wallet could to “check for a token contract’s permanent (non-)transferability using EIP-165” (p. 1). (cited on PTO-892).
NPL ERC-5484: Consensual Soul bound Tokens, Aug. 17, 2022, [“NPL ERC-5484”] defined an ERC-721 extension under which issued SBT cannot be transferred (p. 1) and identified credentials, credit records, and loan histories as exemplary uses (p.2). (cited on PTO-892).
Lange, U.S. Pat. Pub. No. 2023/0410071 (Dec. 1, 2023) [“Lange”] describes soulbound tokens as nontransferable (¶ 35), blockchain created NFTs, delivers tokenized credentials to a user’s cryptowallet (¶ 47), and discusses education financing, and loans, fees (¶ 8). (cited on PTO-892)
Bieber et al., U.S. Pat. Pub. No. 2024/0177144 (May 30, 2024) [“Bieber”] describes generating or minting soulbound tokens, airdropping them into a wallet (¶ 5), using it in blockchain transaction processing, and blocking at attempted transfer (¶ 6).
Stone, U.S. Pat. Pub. No. 2024/0346522 (Oct. 17, 2024) [“Stone”] describes publicly verifiable non-transferrable SBTs permanently bound to wallets or accounts (¶¶ 6, 7) and usable for credit reports, debt, payment documentation (¶ 13), and compensation information (¶ 120).
These prior art publicly available documents establish the WRC of wallet-bound, ledger recorded, non-transferrable tokens, including tokens used for financial records and transaction processing.
The income recordation and distribution functions are likewise WRC.
Rose et al., U.S. Pat. Pub. No 2023/0080599 (Mar. 16, 2023) [“Rose”] describes minting a contract as an NFT, linking it to a crypto wallet (Abstract), treating possession as a right to collect payment (¶ 49), recording payment in a distributed ledger (¶ 50), and distributing smart contract funds to a payee (¶ 34).
Lyren, U.S. Pat. Pub. No. 2023/0351341 (Nov. 2, 2023) [“Lyren”] describes blockchain NFTs whose owners receive passive income generated by an associated lending pool (¶¶ 7, 8), smart contract code distributing that income to seller and buyer blockchain addresses (¶¶ 41, 42, 43), and code imposing a temporary holding period during which the NFT cannot be sold or transferred (¶ 70).
Jethmalani et al., U.S. Pat. Pub. No. 2023/0298001 (Sept. 21, 2023) [“Jethmalani”] describes an NFT representing an income earning asset, determining income, identifying digital wallets, and distributing income to those wallets (¶¶ 115, 116).
Doney et al., U.S. Pat. Pub. No. 2024/0220964 (Jul. 4, 2024) describes tokenized financial assets (¶ 4) and rights on distributed ledgers (¶ 132), wallet address associations (¶ 16), smart contract controls and restrictions on transfers (¶ 10).
The Specification further confirms that the functions of receiving, storing, transmitting, and processing data are normal, well-understood operations of generic computer systems, and the steps may be performed in any order or concurrently. See, e.g., Spec. ¶¶ 39, 40, 50, 189.
The trained machine learning model is well-understood and merely operates on the generic components. The specification teaches the model may employ any numerous known interchangeable ML architecture implemented using publicly available libraries. Spec. ¶¶ 34, 43, 47. This finding is corroborated by Leskovec, Jure, Anand Rajaraman, and Jeffrey David Ullman. "Mining of Massive Datasets." (2019) [“NPL Leskovec”] at 464–467, 535–538 (describing training sets, feature vectors, supervised learning, and loss functions as conventional ML techniques.). The Specification further describes financial model fine tuning as a generic technique. Spec. ¶¶ 45, 118–120. The claims do not recite an improvement to the model or model training. Thus, the machine learning element amounts to applying generic ML to a new data environment, rather than improving ML technology itself. Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205, 1216 (Fed. Cir. 2025) (holding “that patents that do no more than claim the application of generic machine learning to new data environments, without disclosing improvements to the machine learning models to be applied, are patent ineligible under § 101”)
The combination is also WRC at the high level of generality recited:
The combination of the additional elements is likewise WRC. A combination of individually well-understood, routine, and conventional elements does not provide an inventive concept unless the combination itself produces an unconventional result or is applied in an unconventional manner. MPEP § 2106.05(d)(2). Here, claims recite the additional elements in a generic functional sequence at a high level: receiving distribution criteria, obtaining token information, analyzing that information with a machine learning model, and generating a distribution scheme. The claims do not specify any unconventional component placement, arrangement, architecture, model design, consensus process, or smart contract mechanism. The known ERC standards and patent publications identified above corroborate that the soulbound token, ledger, wallet, transfer control, tokenized payment right, and income distribution functions were WRC and that each element performs its expected functions in the claimed functional sequence.
The ordered combination yields only the expected aggregate result of redoing a income related interest in a non-transferrable, wallet held token and using generic computing, ledger, and model functions to analyze and distribute income. Unlike BASCOM, Rep. Claim 1 does not recite a specific unconventional placement or architecture by which the result is achieved. The publications cited supra support a finding that the additional elements perform established functions and are not combined through a claimed unconventional technical interaction.
Unlike BASCOM, where the claims recited a specific non-conventional arrangement of installing a filtering tool at a specific network location (an ISP server) rather than on individual end-user devices, Rep. Claim 1 does not recite how the elements are combined in a non-conventional way. The claims recite each element at a high level of generality without specifying the particular arrangement or order that constitutes the alleged improvement. Spec. ¶ 189 (treating order and concurrency as immaterial to the claimed invention). Rep. Claim 1 recites abstract steps without incorporating specific technical details explaining how those steps are performed. A non-conventional arrangement that is described but not claimed cannot supply the inventive concept at Step 2B. Because the claims here recite only generic components performing generic functions at a high level of generality, and because the individual element and ordered combination findings rest on affirmative Specification admissions and corroborating pre-filing publications, the claim cannot be an improvement to the computer or another technology. MPEP § 2106.05(f). No inventive concept is present under Step 2B. MPEP § 2106.05(d).
Accordingly, the additional elements of Rep. Claim 1 have been recognized, based on Applicant’s own disclosure, as WRC activity in the field. MPEP § 2106.05(d). These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. See also Step 2A, Prong Two, supra.
Independent Claim 20 is a computer-readable medium claim whose instructions cause a system to perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claim 14 is a method claim reciting steps that perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claims 14 and 20 add no additional elements beyond those of Rep. Claim 1 that would amount to significantly more than the abstract idea. Therefore, Independent Claims 14 and 20 also do not recite an inventive concept under Step 2B.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination with the elements of the independent claims. Each dependent claim incorporates all the limitations of its parent Independent Claim and therefore recites the same abstract idea. The additional limitations recited in the dependent claims do not integrate the abstract idea exception into a practical application under Step 2A, Prong Two, and do not amount to significantly more than the abstract idea under Step 2B, for the following reasons:
Regarding Dependent Claims 2, 3, 4, 5, 7, 10, 11, 15, 16, 17, and 18, Dependent Claims 2, 3, 4, 5, 15, 16 and 17 merely narrow the field of use and data types operated on by the abstract idea of Independent Claims without adding any additional element and therefore, merely narrow the abstract idea recited by Independent Claims. MPEP § 2106.05(h). An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III). Dependent Claim 7 recites use of the digital wallet in its conventional way and is insignificant extra-solution activity. MPEP § 2106.05(g). Dependent Claims 10, 11, and 18 merely duplicate the same abstract idea and same generic machine learning black box across a second data set and do not integrate the exception into a practical application or add an inventive concept doe the same reason given for the ML limitations in Rep. Claim 1.
Dependent Claim 6 recites insignificant extra solution activity: outputting and receiving data. MPEP § 2106.05(g).
Dependent Claim 8 recites a generic output/display step. The Specification describes the user interface only functionally as being “accessible by the computing device” and configured to display income source information, distribution amounts, frequency, and analytics, without any specific improvement to UI technology, rendering, or display architecture. Spec. ¶¶ 108, 172. This is insignificant extra solution activity/generic display functionality. MPEP § 2106.05(g).
Dependent Claim 9 recites the ML model is a chatbot that receives a request, generates a response, and provide the response. The Specification teaches the chatbot is trained using generic publicly known techniques (i.e., supervised fine tuning of a pre-trained large language model followed by reinforcement learning from human feedback (RLHF) using a separately trained reward model). Spec. ¶¶ 90–107. The chatbot is app[lied to a new data environment of income stream management. NO improvement to chatbot or LLM architecture, training, or natural language processing is described. The Specification teaches the same three-step training process “applies equally to an artificial intelligence (AI) chatbot or an AI model, as terms such as artificial intelligence and machine learning may be used interchangeably herein.” Spec. ¶ 86. This confirms the generic off the shelf character of the chatbot. Under Recentive, this is a further application of generic machine learning (here, a generic conversational LLM) to a new data environment (income distribution management) without a disclosed improvement to the underlying model.
Dependent Claim 12 recites additional elements of retraining/fine-tuning that the Specification describes using generic, industry standard fine-tuning techniques (e.g., BERT models) and “using a plurality of training datasets associated with a plurality of financial domains,” Spec. ¶ 45, without disclosing any improvement to the fine-tuning methodology. Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205, 1216 (Fed. Cir. 2025) (holding “that patents that do no more than claim the application of generic machine learning to new data environments, without disclosing improvements to the machine learning models to be applied, are patent ineligible under § 101”).
Dependent Claims 13 and 19 recite the use of the distributed ledger’s validation/consensus functionality in its conventional capacity. Spec. ¶ 61. This is insignificant extra solution activity. MPEP § 2106.05(g).
Conclusion
Claims 1–20 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 1 otherwise styled as another statutory category is subject to the same analysis.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1–8, 10–12, 14–18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Plenet de Badts de Cugnac (U.S. Pat. Pub. No. 2024/0029155) [“Plenet”] in view of FOR Int. Pat. Pub. No. WO 2022/204425 [“FOR Cella”] and further in view of NPL ERC-5484: Consensual Soul bound Tokens (Aug. 17, 2022) [“NPL ERC-5484”].
Regarding Claim 1, Plenet discloses:
A system for managing income streams [revenue stream] using machine learning, the system comprising: one or more processors; one or more memories storing a machine learning model that is trained using historical financial data [historical financial information, such as accounting data] to manage an income stream recorded on a distributed ledger as a [stablecoin/NFT] deposited in a digital [crypto] wallet of an owner of the income stream [lender crypto wallet, ¶ 56] and […]; the one or more memories further storing a set of computer-executable instructions that, when executed, cause the system to:
(See at least Fig. 1 and associated text ¶ 23, “Referring to FIG. 1, a system 100 is shown … The system 100 includes a processing unit and memory.” ¶ 4, “computer systems … directly access a revenue stream and financial information about the revenue stream; a machine learning (ML) model trained to continuously process the financial information about the revenue stream to continuously analyze and score the revenue stream; and a smart contract factory, responsive to the scoring by the ML model, for generating at least one smart contract on a distributed, decentralized network. The smart contract is programmed to receive payments in stablecoins with respect to revenue stream.” ¶ 36, “the ML module 143 may be trained on the historical accounting data, billing data, metrics and analytics, and CRM data associated with a revenue stream.” ¶ 37, “The training may be based on historical data at both a macro-level and a micro-level.” Fig. 5A, step 520, “After Loan Payments to Lenders are Made, Record Final Payment Transactions on Blockchain”). ¶ 79, “The sum of$50 is retained for the loan payment, converted to an equivalent amount of stablecoins, and paid to the lender(s)” ¶ 80, “At step 450, loan payments in stable coins are sent to the lenders. Proceeds are distributed among lenders to their respective crypto wallets.” “Certain methods according to the various aspects of the invention may be performed by instructions that are stored upon a non-transitory computer readable medium.”
receive, from a computing device, distribution criteria including information for distributing at least a portion of income received from the income stream to one or more distribution recipients;
(See at least Fig. 4A and associated text ¶ 79, a payment is received by a payment gateway 123 from a borrower device where the payment is processed a particular way. “For example, a monthly loan payment of $50 is due, and a consumer purchases $200 worth of the borrower's goods, and a processing fee is $2. The sum of$50 is retained for the loan payment, converted to an equivalent amount of stablecoins, and paid to the lender(s), while and the sum of $148, (after the processing fee is deducted) is forwarded to the borrower's bank account. Another purchase of $100 is made while the payment due is $0, so the payment gateway 170 forwards $99 to the borrower's bank account and retains a processing fee of $1. [0080] At step 450, loan payments in stable coins are sent
to the lenders. Proceeds are distributed among lenders to their respective crypto wallets.” ¶ 24, “The front end system 190 also allows the borrower to provide authorization to access the revenue stream by an integrating payment gateway 123, and accept terms of use.”)
obtain […] and the income stream of the owner;
(See at least ¶ 26, “payment unit 120 includes a payment gateway 123 that the company can integrate in their own infrastructure, website, platform etc.; such that the cost of goods and services provided by the company to its users can be paid by the users via the payment gateway 123, thus providing the payment unit 120 with access to this revenue stream.” ¶ 24, “The front end system 190 also allows the borrower to provide authorization to access the revenue stream by an integrating payment gateway 123, and accept terms of use. The frontend system 190 also allows the lender to list, swap, buy, or sell their lending positions (i.e. their ownership of assetized revenue streams).” ¶ 44, “each lender has ownership over a percentage of the future revenue stream defined by the contract.”
analyze, by the machine learning model, the distribution criteria and […] to generate one or more distribution insights associated with optimizing distribution of at least the portion of the income; and
(See at least ¶ 4, “a machine learning (ML) model trained to continuously process the financial information about the revenue stream to continuously analyze and score the revenue stream;” See also, Fig. 6A, steps 610, 620, 630. ML generate scoring and ratings drive new loan terms, which are the claimed insights; ¶¶ 35, 36, 38.)
generate, by the machine learning model, one or more distribution schemes associated with distributing at least the portion of the income to the one or more distribution recipients, based upon the one or more distribution insights.
(As explained above, Plenet teaches a ML model that continuously analyzes and scores a borrower’s revenue stream and updates scoring, risk, and credit ratings. ¶¶ 2, 4, 35, 36; and Fig. 6A, Steps 610, 620. For borrowers whose scoring has changed, the system determines and communicates new loan terms (Fig. 6A, Step 630), rolls those new terms out to lenders (Fug. 6A< step 650), updates smart contracts (Fig. 6A, step 680), and mints new NFTs which are transferred to lender wallets (Fig. 6A, step 685). ¶¶ 38, 35, Fig. 6A, Steps 630–690. These ML scores and risk assessments (insights) are used by the system to define how a portion of the borrower’s revenue stream is allocated to lender recipients via updated loan terms and repayment schedules. The updated loan terms and repayment schedules are the claimed generating schemes for distributing a portion of the income to distribution recipients.)
Plenet discloses smart contracts on a “distributed decentralized ledger” that receive payments “in stablecoins with respect to [the] revenue stream.” ¶ 4. Plenet discloses sending stablecoin loan payments (revenue/income) to lender’ crypto wallets. ¶ 80. Thus, Plenet teaches “an income stream recorded on a distributed ledger as an [stablecoin/NFT] deposited in a digital [crypto] wallet of an owner of the income stream [lender crypto wallet, ¶ 56]. To the extent Plenet does not disclose, FOR Cella discloses:
an income stream recorded on a distributed ledger as a [token] deposited in a digital wallet of an owner of the income stream
(See at least ¶ 7, “asset-backed tokenization platform”. ¶ 80, a platform for enabling transactions wherein a set of tokens is generated and linked to an alternative asset class, such that the value of a token in the set represents a defined unit of the alternative asset class, wherein the alternative asset class is one or more of a data stream, a revenue stream, an energy stream, a future income stream.” Asset and tokens are linked through digital wallets. ¶ 50; Fig 6.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined an income stream recorded on a distributed ledger as a [token] deposited in a digital wallet of an owner of the income stream, as taught by FOR Cella, to the known invention of Plenet, in the same field of invention, with the motivation to gain the benefits that FOR Cella identifies: providing “tradeable tokens, such as ones that are linked to or backed by one or more other asset classes” (FOR Cella, ¶ 7), and “a robust platform that facilitates design, development, simulation, deployment, monitoring and analysis of new sets of tokens” (FOR Cella, ¶ 6), backed by revenue/income streams.
Plenet disclose token held in digital wallets. Plenet does not disclose “soulbound tokens” or their claimed functionality but NPL ERC-5484 discloses:
a soulbound token … configured to be non-transferable from the digital wallet;
(See at least pdf. p. 1, “After its issuance, a soulbound token can't be transferred.” See also, pdf. p. 3, “Non-Transferable”.)
obtain soulbound token information associated with the soulbound token; analyze … the soulbound token information
(See at least pdf. p. 2,” soulbound tokens as specialized NFTs that will play the roles of credentials, credit records, loan histories, memberships, and many more” with “token metadata” that the “issuer SHALL present … to the receiver” (pdf. p. 2, “Specification”). A person of ordinary skill in the art would understand that any system employing ERC-5484 compliant SBTs must retrieve (obtain) the token’s on-chain metadata to use it.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined NPL ERC-5484‘s non-transferrable soulbound tokens to the known system of Plenet, in which “a machine learning (ML) model [is] trained to continuously process the financial information about the revenue stream to continuously analyze and score the revenue stream (Plenet, ¶ 4), using “historical accounting data, billing data, metrics and analytics, and CRM data associated with a revenue stream” (Plenet, ¶ 36), and “update[ ] scoring, risk and credit rating” based on token and asset class attributed (Plenet, ¶ 86), in the same field of invention, with the motivation to implement Plenet’s income-linked tokens as ERC-5484 nontransferable soulbound tokens, need to make drastic changes to their existing [NFT] codebase, and to treat ERC-5484 soulbound token meta data as additional input features for the already disclosed ML models so that those existing models analyze both financial/token data and soulbound token information when generating risk scores, credit ratings, and income allocation insights.
Regarding Claim 2, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1 and the distribution criteria
Plenet further discloses
wherein the distribution criteria includes one or more of: a distribution condition, a distribution recipient, a distribution amount, or distribution timing.
(See at least ¶ 87, At step 630 for a borrower whose scoring been changed, new loan terms are determined and communicated to the borrower for any additional new loan. For instance, a determination is made that the loan amount may be increased as supported by the higher revenue stream. If the increase is approved, the borrower is notified.”)
Regarding Claim 3, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1, and the soulbound token information
Plenet does not disclose but ERC-5484 discloses:
wherein the soulbound token information includes one or more of: characteristics of the soulbound token, characteristics of the corresponding income stream, characteristics of a smart contract associated with the soulbound token, or external data used to trigger the smart contract.
(See at least pdf. p. 2,” soulbound tokens as specialized NFTs that will play the roles of credentials, credit records, loan histories, memberships, and many more” with “token metadata” that the “issuer SHALL present … to the receiver” and “The issuer SHALL NOT change metadata after issuance.” (pdf. p. 2, “Specification”).
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 1.
Regarding Claim 4, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 3 and the external data
Plenet does not disclose but FOR Cella discloses:
wherein the external data includes one or more or economic data, recipient health data, or recipient environmental data.
(See at least ¶ 8, “Backing or linking of a token with an alternative asset class or member thereof may be undertaken in a variety of ways, such as, without limitation: indexing the value of a token to a set of economic parameters of an asset class or particular asset or value stream within it (e.g., the amount of income generated by an asset, the valuation ascribed to the token in a secondary market, lending market, or insurance market, the value of an index on the underlying asset class or member, or many others).
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 1.
Regarding Claim 5, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1 and the one or more distribution insights
Plenet further discloses
the one or more distribution insights include at least one of: income analytics, income forecasting, financial goal modeling, financial advice, or an income distribution recommendation.
(See at least ¶ 35, “the ML module 143 is trained to process the financial information to generate a score for the revenue stream or forecast the future values of the financial data.”)
Regarding Claim 6, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1 and the one or more distribution insights
Plenet further discloses
further comprising instructions that, when executed, cause the system to: provide the one or more distribution insights to the computing device; and receive, from the computing device, feedback associated with the one or more distribution insights used to generate the one or more distribution schemes.
(See at least ¶ 24, “These dashboards 191, 192, 193 enable users to interface with the system 100, such as enabling a borrower to submit financial information about a revenue stream. The front end system 190 also allows the borrower to provide authorization to access the revenue stream by an integrating payment gateway 123, and accept terms of use. The front end system 190 also allows the lender to list, swap, buy, or sell their lending positions (i.e. their ownership of assetized revenue streams. ¶ 34, “the API of the system 142 can also take manual input, in the form of a file upload and/or answers to forms/questionnaires, and manual input from the risk management team.”)
Regarding Claim 7, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1 and one or more distribution schemes
Plenet further discloses
wherein the one or more distribution schemes include at least one of: automatically depositing the income from the income stream into a digital wallet; or automatically distributing at least the portion of the income from the digital wallet to the one or more distribution recipients.
(See at least ¶ 71, “Each lender will transfer their agreed loaned amount in stablecoin cryptocurrency from their crypto wallet to the borrower crypto wallet. This transaction is added to the blockchain.” ¶ 73, “At step 330, the marketplace system 150 mints a non-fungible token (NFT) for each selected lender. At step 340, NFT are sent to their respective lender crypto wallets.” ¶ 80, At step 450, loan payments in stable coins are sent to the lenders. Proceeds are distributed among lenders to their respective crypto wallets.”)
Regarding Claim 8, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1 and one or more distribution schemes
Plenet further discloses
further comprising instructions that, when executed, cause the system to: generate a user interface, accessible by the computing device, and configured to manage the income stream using the machine learning model.
(See at last ¶¶ 24, 25 (cited supra)).
Regarding Claim 10, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1 and the income stream, the distribution criteria, the machine learning model.
Plenet further discloses
wherein the income stream is a first income stream, the distribution criteria is a first distribution criteria, and the machine learning model is a first machine learning model, and the system further comprises instructions that, when executed, cause the system to: manage a second income stream based upon second distribution criteria using a second machine learning model.
(See at least ¶ 28, “the lending unit 130 can hold multiple contracts between a company and any number of lenders, which can be … different types of contracts (fixed-term, revenue-based, invoice based)” simultaneously for the same company. Thus, each contract corresponds to a different income stream. ¶ 35, “the ML module 143 might be trained for a particular industry. Therefore, the back end system 110 might store multiple trained ML models, and apply the appropriate model to a company generating the revenue stream.” A first income stream (first contract) with associated terms and ML model correspond to the first income stream, first distribution criteria, and first machine learning model. Additional income streams manages by the same system with potentially different terms and a potentially different ML model correspond to a second income stream, second distribution criteria, and second machine learning model.)
Regarding Claim 11, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 10 and the first machine learning model and the second machine learning model.
Plenet does not disclose but FOR Cella discloses
wherein the first machine learning model and the second machine learning model collaborate with one another to manage the first income stream and the second income stream.
(See at least ¶ 44, “a machine learning system 1904 that trains a set of machine-learned
models 1908 to output a determination 1918 related to a set of token design strategies.” ¶ 45, this includes analyzing “correlations among the asset classes (e.g., to indicate where selected tokens may have underlying economic relationships that tend to increase volatility and/or anticipated returns (e.g., due to reinforcing aspects of two asset classes or that have underlying relationships) or that tend to reduce volatility and/or returns (e.g., where the asset classes/tokens tend to be correlated in ways that hedge risk)” for “monitor[ing] and rebalance[ing] a set of tokens” (¶ 46). Thus, multiple machine learning models are used together within a strategy engine to manage sets of asset-linked tokens and income streams in a coordinated fashion. Each token represents a different asset class.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined the first machine learning model and the second machine learning model collaborate with one another to manage the first income stream and the second income stream, as taught by FOR Cella, to the known invention of Plenet, in the same field of invention, with the motivation to identify “underlying economic relationships that tend to increase volatility … or that tend to reduce volatility and/or returns.” NPL Cella, ¶ 45.
Regarding Claim 12, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1, the distribution criteria or the soulbound token information
Plenet discloses an ML module 143 that is “trained to process the financial information to generate a score for the revenue stream or forecast the future values of the financial data,” (¶ 35) where the score indicates financial health, risk assessments, and guidelines, (¶ 35) and further teaches that “the ML module 143 might be trained for a particular industry” (¶ 35) such that the back end system “might store multiple trained ML models, and apply the appropriate model to a company generating the revenue stream” (¶ 35). Plenet does not disclose the retraining process as a retailing of a base model, selecting models based upon at least one of the distribution criteria or the soulbound token information, and use the identified one or more retrained machine learning models as the machine learning model to generate the one or more distribution insights, wherein the one or more distribution insights include at least one of the one or more domain insights. Thus, Plenet does not disclose but FOR Cella discloses:
further comprising instructions that, when executed, cause the system to: retrain the machine learning model using a plurality of training datasets associated with a plurality of financial domains to generate a plurality of retrained machine learning models,
(See at least ¶ 44, In embodiments, the strategy engine 1902 includes a machine learning system 1904 that trains a set of machine-learned models 1908 to output a determination 1918 related to a set of token design strategies employed by a token designer, which is optionally trained using a training data set 1910 comprising at least one of asset class and/or token features, attributes, parameters, and outcomes.”
the retraining causing each of the plurality of retrained machine learning models to generate one or more domain insights associated with the respective plurality of financial domains;
(See at least ¶ 44, “In embodiments, the strategy engine includes an artificial intelligence system 1912 that receives a request 1914 for a determination 1918 of a set of asset class attributes that may be configured to support a strategy selected and/or configured by a user and generates a set of asset class recommendations (such as relating asset class types, specific bundles of assets, relative amounts, timing of recommended acquisition or disposition, or the like) regarding a set of asset classes (optionally including a recommended set of tokens. … Behavior of asset classes in relation to strategies may be simulated, and association of asset class recommendations and simulations with token attributes may include visual representations of historical performance, optionally presented in layers such that aggregate impacts of a set of tokens are represented, with historical and/or forecasted volatility /variance.” ¶ 45, “Each set of tokens may be represented in the analytic interfaces described herein, such as showing historical behavior of the underlying asset class, predicted or simulated behavior ( optionally using machine learning or AI operating on historical data sets to forecast behavior), correlations among the asset classes”)
store the plurality of retrained machine learning models in a memory;
(See at least ¶ 44, cited supra. Models are stored in the strategy engine 1902.
identify one or more retrained machine learning models, of the plurality of retrained machine learning models, based upon at least one of the distribution criteria or the soulbound token information; and
(See at least ¶ 44, “Parameters of the strategy may include specific goals sought by the strategy (e.g., preservation of capital, a desired risk/return profile, accumulation of a specified amount of value (e.g., to meet a defined goal), and the like. Behavior of asset classes in relation to strategies may be simulated.” ¶ 47, “a recommendation for a token designer and/or an algorithmically generated plan for token design may include a set of inputs generated by collaborative filtering, such as operating on a set of token designs of other designers and/or a set of token designs generated automatically for a similar strategy, a similar user, or the like. Selection of a cohort for collaborative filtering may be based on similarity attributes of a strategy (e.g., risk/reward profile, goals, timing, preferences for certain asset classes, geography, and many others), similarity attributes of users.”)
use the identified one or more retrained machine learning models as the machine learning model to generate the one or more distribution insights, wherein the one or more distribution insights include at least one of the one or more domain insights.
(See at least ¶ 46, “In embodiments, the strategy engine 1902 may be trained over time, such as on a training data set 1910 of token designers and outcomes of tokens on the platform, to take an input strategy, discover a set of asset classes that are candidates to satisfy the strategy, select a set of asset class-linked tokens, generate a plan for acquisition and/or disposition of tokens (and possibly other assets), to execute the strategy, and issue a set of instructions (executable over time) to execute the plan. In embodiments, the strategy engine may be trained, using similar inputs and feedback on outcomes, to monitor and rebalance a set of tokens, including based on market changes (e.g., changes in value of tokens or other assets), changes in strategy (including pre-planned changes and ones that emerge), and/or based on other factors.”)
It would have been obvious to one of ordinary skill in the art to implement Plenet’s multiple industry specific ML models within FOR Cella’s strategy engine by retraining or training separate models on different financial domains (industries, asset classes, or income stream types), storing those domain specific models, and selecting appropriate models based on the characteristics of the income stream and associated token information (FOR Cell’s strategy parameters and asset/token attributes) to generate distribution insights that incorporate domain level risk and performance insights. The
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 12.
Regarding Claim 14, Plenet discloses
A computer-implemented method for managing income streams using machine learning, the computer-implemented method comprising:
(See at least ¶ 4, cited supra).
The remaining limitations of Claim 14 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Plenet, NPL Cella, and NPL ERC-5484 for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 14.
Regarding Claims 15, 16, 17, and 18, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The computer-implemented method of claim 14
The remaining limitations of Claims 15, 16, 17, and 18 are not substantively different than those presented in Claims 2, 3, 5, and (10 and 11 combined), respectively, and are therefore, rejected, mutatis mutandis, based on Plenet, NPL Cella, and NPL ERC-5484 for the same rationale presented in Claims 2, 3, 5, and (10 and 11 combined), respectively, supra.
Regarding Claim 20, Plenet discloses
A non-transitory computer-readable medium storing processor-executable instructions that, when executed by one or more processors, cause the one or more processors to at least:
(See at least ¶ 118).
The remaining limitations of Claim 20 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Plenet, NPL Cella, and NPL ERC-5484 for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 20.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Plenet, FOR Cella, and ERC-5484 and further in view of Edwards et al. (U.S. Pat. Pub. No. 2021/0303973) [“Edwards”]
Regarding Claim 9, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1, the machine learning model, and manage the income stream from the computing device
Plenet does not disclose but Edwards discloses:
wherein the machine learning model is a chatbot; and
(See at least Fig. 4, disclosing an exemplary chatbot exchange)
further comprising instruction that, when executed, cause the system to: receive a request […] from the computing device; generate a response to the request via the chatbot; and provide the response to the computing device.
(See at least Fig. 4 and associated text col. 43:41–46, “a user interface 404 conversationally interfaces a chatbot, by way of at least a submission 412, from the user interface 408 to the chatbot, and a response 416, from the chatbot to the user interface 404. In many cases, one or both of submission 412 and response 416 are text-based communication.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML model of Plenet “trained to continuously process the financial information about the revenue stream to continuously analyze and score the revenue stream” (Plenet, ¶ 4) with a chatbot to receive a request, generate a response via the chatbot and provide the response to a computing device of Watkins, with the motivation to p[provide a natural language chatbot based interface for accessing Plenet’s ML generated revenue/income stream scores and recommendations, which improves usability in managing user income streams.
Claims 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Plenet, FOR Cella, and ERC-5484 and further in view of Molinari et al. (U.S. Pat. Pub. No. 2019/0080402) [“Molinari”]
Regarding Claim 13, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 1 and the soulbound token
Plenet further discloses:
further comprising instructions that, when executed, cause the system to:
[…]
provide the at least one transaction to a node of the distributed ledger for validation and recording of the at least one transaction on the distributed ledger.
(See at least ¶ 81, “At step 460, the transaction is recorded on blockchain. For instance, the transaction is broadcast to all computers participating in the specific blockchain network. The transaction is verified and stored into a block, and the block is added to the blockchain. The smart contract knows the amount and date of the loan payment.”)
Plenet does not disclose but Molinari discloses:
generate at least one transaction including data to generate at least one distribution smart contract […] on the distributed ledger, the at least one distribution smart contract configured to execute the one or more distribution schemes; and
(See at least ¶ 49, “The method further includes implementing a smart contract on a blockchain to manage distributions from the issuing entity to the token holder according to the unique token, wherein the smart contract includes a set of promises in digital form and defined protocols for managing value distribution from the issuing entity to the token holder (step 212). The method also includes receiving, via the smart contract, a revenue received by the issuing entity (step 214) and issuing, via the smart contract and based on the revenue, to the token holder, a disbursement (step 216).”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined generate at least one transaction including data to generate at least one distribution smart contract […] on the distributed ledger, the at least one distribution smart contract configured to execute the one or more distribution schemes, as taught by Molinari, to the known invention of Plenet, in the same field of invention, with the motivation to improve Plenet’s revenue stream smart contract so that they not only receive payments from the revenue stream but also manage the distribution of those payments to token holders according to predefine distribution parameters.
Regarding Claim 19, Plenet, FOR Cella, and NPL ERC-5484 disclose:
The system of claim 14 and the soulbound token
The remaining limitations of Claim 19 is not substantively different than that presented in Claim 13, and is therefore, rejected, mutatis mutandis, based on Plenet, NPL Cella, NPL ERC-5484, and Molinari for the same rationale presented in Claim 13, supra.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
2 “It should be noted that these groupings are not mutually exclusive, i.e., some claims recite limitations that fall within more than one grouping or sub-grouping. … Accordingly, examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible, if a claim limitation(s) is determined to fall within multiple groupings and proceed with the analysis in Step 2A Prong Two.” MPEP § 2106.04(a).
3 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights