DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The following FINAL office action is in response to Applicant communication filed on 11/25/2025 regarding application 18/648,702. Claims 1-6, 8-12, 14, 16 and 18-20 have been amended. Claims 7 and 17 have been canceled. Claims 1-6, 8-16 and 18-20 are currently pending have been rejected.
Response to Amendments
2. Applicant’s amendment filed on 11/25/2025 necessitated new grounds of rejection in this office action.
Information Disclosure Statements (IDS)
3. The 1 Information Disclosure Statement (IDS) filed on 11/25/2025 complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and is considered by the Examiner.
Response to Arguments
4. Applicant’s arguments, see page 1 filed on 11/25/2025, with respect to the Claim Objections for Claims 1-2, 4, 6, 11-12, 14 and 16 have been fully considered and is found to be persuasive. Therefore, the Claim Objections for Claims 1-2, 4, 6, 11-12, 14 and 16 have been withdrawn.
5. Applicant’s arguments, see pages 5-6 filed on 11/25/2025, with respect to the 35 U.S.C. § 103 Claim Rejections for Claims 1-20 have been fully considered and are found to be persuasive. Therefore, the 35 U.S.C. § 103 Claim Rejections for Claims 1-20 have been withdrawn. See Examining Claims with Respect to Prior Art Section shown below.
Response to 35 U.S.C. § 101 Arguments
6. Applicant’s 35 U.S.C. § 101 arguments, filed with respect to Claims 1-6, 8-16 and 18-20 have been fully considered, but they are found not persuasive (see Applicant Remarks, Pages 1-5, dated 11/25/2025). Examiner respectfully disagrees.
Argument #1:
(A). Applicant argues that Claims 1-6, 8-16 and 18-20 recite additional elements that integrate the judicial exception into a practical application under revised step 2a prong two of the 35 U.S.C. § 101 analysis (see Applicant Remarks, 2nd ¶ of Page 3, dated 11/25/2025). Examiner respectfully disagrees.
Specifically, Applicant argues that amended claim 1 recites specific structural and functional limitations that integrate the abstract idea into a practical application by improving computer functionality. In response to Applicant’s arguments here, Examiner points out that the limitations describe “business-as-usual” result-oriented functional requirements rather than a technical improvement to computer technology. The “segregated database architecture” and “vector-based organization” are described in terms of their functional result (enabling processing and reordering) rather than a specific technical improvement to the database software itself. These claims do not explain how the vector allows for faster processing or less memory usage; it simply asserts that it does so to serve a business goal (liquidity optimization). Terms like “corpus”, “database” and “vector” represent data structures used in computer science. Merely using a vector to store data – even if that data represents financial transactions – does not improve the computer’s ability to store or retrieve data; it merely uses the computer as a tool to organize business records. The “real-time liquidity optimization” is a business objective, not a technical one. The USPTO and courts (e.g., Electric Power Group) have held that colleting data, analyzing it, and displaying the results (or reordering them) to solve a commercial problem does not constitute an improvement to computer functionality. The “problem” being solved is a lack of cash flow, not a bottleneck in computer’s CPU or bus architecture. These claims lack the technical details or “how-to” that would move it beyond an abstract idea. It does not recite a specific algorithm for the dynamic growth/shrinkage of the vectors or a specific network protocol for linking ledgers. Without these specificities, these claims are seen as “preempting” the use of database tools for a specific business purpose. The use of “segregated database structures” is essentially a requirement for any organized database (which must distinguish between different types of data, such as payables and receivables). This is considered mere field of use restrictions that do not transform the abstract idea into a practical application.
In conclusion, Claims 1-6, 8-16 and 18-20 are not integrated into a practical application because the “improvement” is directed to the business outcome (liquidity management) rather than a technical capability of the computer system itself. The hardware and software structures mentioned are used in their expected capacities to execute a non-technical process.
Argument #2:
(B). Applicant argues that amended claim 1 further recites that the payable rack and the receivables rack are stored as vectors that dynamically grow and shrink based on ongoing transaction activity. This dynamic vector-based structure is not merely conventional data storage, but rather represents a specific technical architecture that enables the system to constantly update and reorder transactions to provide desired liquidity (see Applicant Remarks, 3rd ¶ of Page 3, dated 11/25/2025). Examiner respectfully disagrees.
In response to Applicant’s arguments, these claims limitations shown in Independent Claims 1 and 11 describe the computer’s standard operation rather than a technical breakthrough in data science. Dynamic sizing is an inherent feature of modern vectors. In computer science, a “vector” is by definition a dynamic array. The ability of a vector to “grow and shrink” is a standard, built in property of the data structure (as seen in common programming libraries like C++ or Java). Claiming that a vector grows when data is added is not a “technical architecture” created by the inventor; it is simply a description of how the data structure is designed to function. The argument that this stricture “enables the system to constantly update and reorder” describes the desired business result, not a technical solution. These claims do not recite a new method for reindexing or a new algorithm for memory allocation. It merely states that because the data structure is flexible (dynamic), the business logic (reordering for liquidity) can be performed. This is considered “functional claiming” of a business process. To satisfy Prong 2, the improvement must be to the computer, not the business. The “dynamic vector” does not make the database faster, use less RAM, or improve security compared to other conventional data structures. Instead, the “efficiency” being claimed is the efficiency of the liquidity management process, which is a non-technical, economic benefit. Using a database to store transaction records and a vector to list them is conventional activity. High-level descriptions of data organization (segregating payables and receivables) are merely field-of-use restrictions. They do not change the fact that the computer is simply acting as a tool to perform a task that a human accountant would do with different folders or ledgers. Preemption of the Abstract Idea: Allowing these claims would effectively grant a monopoly on using standard dynamic data structures for the purpose of cash-flow management. Since these claims do not provide a specific, technical “how-to” for the growth/shrinkage logic that differs from standard computing, it remains an abstract idea.
In summary, these use of dynamic vectors to store and reorder transactions is an insignificant extra-solution activity. It uses the computers inherent capabilities to execute a business strategy (liquidity optimization) without providing a specific technical improvement to the way the computer manages data or memory. In conclusion, Claims 1-6, 8-16 and 18-20 are not integrated into a practical application.
Argument #3:
(C). Applicant argues that the hyperplane limitations of amended Independent Claims 1 and 11 provide additional technical specificity by defining a computational construct from the top rows of the payables vector and the receivables vector to identify which transactions must be executed before other transactions. The micro-batch transaction functionality further integrates the claims into a practical application by linking ledgers associated with a subset of transactions to create optimized transaction batches (see Applicant Remarks, 4th ¶ of Page 3, dated 11/25/2025). Examiner respectfully disagrees.
Examiner notes that these terms are merely sophisticated labels for business logic and mathematical sorting. Mathematical concepts are not technical mechanisms. While Independent Claims 1 and 11 uses the term “hyperplane”, this is a mathematical construct used to describe a decision boundary. Using a mathematical formula or geometric model to “identify” or “prioritize” data is a classic example of an abstract idea. Manipulating a mathematical boundary to reach a business goal (liquidity) does not improve the computer’s internal operations; it simply refines the calculation being performed by the computer. Micro-batching” as a business practice. The concept of “micro-batching” and “linking ledgers” is a digital version of batch processing, which has been a staple of computing for decades. Grouping specific transactions together to optimize cash flow is a commercial strategy (like a “bulk payment” or “clearinghouse” function). These claims do not recite a specific technical protocol or a new networking API for “linking” these ledgers; it describes the process at a high level of generality. To be integrated into a practical application, the “technical mechanism” must solve a technical problem. Here, the “desired liquidity” is a financial state, not a technical one. The hyperplane is used as a tool to solve a business problem (which bills to pay). Under USPTO Guidance, using a computer (even with fancy math like hyperplanes) to perform a business task more efficiently is not an “improvement to computer functionality”. The claim “manipulate the hyperplane to provide desired liquidity” is purely functional. It describes what the system does (reaches a liquidity goal) but not how the computer’s underlying architecture is technically modified to do so. This is a “black box” limitation that fails to provide the specific “how-to” required to move the abstract idea. Furthermore, linking ledgers and batching transactions are seen as post-solution activity. Once the “hyperplane” (the math) has determined which transactions are priority, the act of “linking” them or “executing” them is just the routine follow-through of any financial software. It does not add “significantly more” to the abstract idea because it is simply the way a computer carries out a financial transaction.
In summary, the limitations of Independent Claims 1 and 11 regarding the “hyperplane” and “micro-batching” are mathematical applications of business logic. They provide no specific technical improvement to the computer’s hardware, operating system, or database management system. Instead, they use the computer as a “passive tool” to execute a complex financial prioritization scheme.
Argument #4:
(D). Applicant argues that amended claim 1 does not merely recite using a standard computer to implement an abstract idea. The combination of segregated database corpora, dynamically adjusting vectors, hyperplane-based transaction prioritization, and micro-batch ledger linking represents a specific technical solution that improves the functioning of the computer system itself by enabling real-time transactional data management and optimization that would not be possible with conventional database structures (see Applicant Remarks, last ¶ of Page 3 thru 1st ¶ of Page 4, dated 11/25/2025). Examiner respectfully disagrees.
The architecture mentioned is actually a business process map dressed in technical jargon. The argument that this “would not be possible with conventional data structures” is a conclusory statement. There is no evidence in the claim that a “segregated corpus” or “dynamic vector” is a new invention. In fact, “segregating data (e.g., “Accounts Payable” vs. “Accounts Receivable”) and using dynamic arrays (vectors) are database principles. Using them to manage “liquidity” – a financial concept – confirms that the innovation is in the business rule, not the computer’s capability. The “technical problem” is a mischaracterization. Applicant argues that the claims solve a technical problem of “structuring data”, but the structure is dictated entirely by financial requirements. If the “problem” being solved is how to pay bills faster to save money, it is a business problem. A true technical problem would be something like “reducing database latency” or “preventing memory leaks in distributed ledgers”, regardless of whether the data is about liquidity. These claims fail to recite the technical constraints that make this a “technical solution”. It does not explain how the hyperplane is manipulated at the machine level or how data integrity is maintained across the “segregated corpora” differently than standard relational database management system (RDBMS). Without specific algorithms or protocols, these claims merely say “do it on a computer” using math. “Real-time transaction prioritization” is a functional goal. The USPTO and courts (e.g., Electric Power Group, LLC v. Alstom S.A.) have ruled that collecting, analyzing, and displaying information in real-time is not a technical improvement. The “hyperplane” is just a mathematical filter for that data; it doesn’t change how the computer’s CPU or memory functions. The “segregated database structure” are digital analogs to physical file folders. The “hyperplane” is a digital analog to a manager’s “cutoff line” for spending. Linking ledgers is the digital equivalent of a “stapled packet” of invoices. Under MPEP § 2106.04 (a) (2) simply using a computer to perform these business tasks more efficiently is not an integration into a practical application.
In summary, the combination of limitations for Independent Claims 1 and 11 for example; does not create a “new computer”, but rather a “new business method” that uses a computer. The technical elements (vectors, corpora, batching) are used in their ordinary and expected manner to solve a non-technical problem (liquidity). Consequently, the abstract idea remains “directed to” an exception without being integrated into a practical application.
Argument #5:
(E). Applicant argues that that amended claim 1 recites significantly more than any judicial exception wherein the specific configuration of segregated database corpora specifically designed to enable processing of distinct transaction types through vector-based racks represents WURC (see Applicant Remarks, 2nd ¶ of Page 4, dated 11/25/2025).
Examiner points out that the components of the “specific configuration” – namely databases, corpora, and vectors – are the building blocks of modern computing. Merely using a “vector” to store a “rack” of data is a textbook use of a data structure. According to Berkheimer v. HP Inc., while the combination can be inventive, it is not so if the combination simply follows the natural flow of the abstract idea. Here, segregated payables and receivables is the standard way financial data is organized; doing so in a database is “routine” for any financial software. The argument that the corpora are “specifically designed” for transaction types is a field-of-use restriction. Limiting an abstract idea (liquidity management) to a specific environment (segregated database corpora) does not provide an inventive concept. Under Alice Corp., v. CLS Bank, “the mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention.” To provide “significantly more”, the element must transform the nature of the claim. Here, the computer is not transformed; it is simply automating a mental process or a fundamental economic practice. Reordering a vector (sorting) and batching transactions (grouping) are “generic computer functions” that the USPTO 2019 Guidance identifies as failing to provide an inventive concept. The applicant’s argument that the architecture is “specifically designed” misses the mark. Even if the configuration is “new”, it is not inventive for 101 purposes if it is just a “technological implementation” of an abstract business concept. The “problem” being solved (real-time liquidity) is a business problem, and the “solution” uses computers as they are meant to be used – to process and sort data. Allowing these elements to satisfy step 2B would effectively preempt any use of standard vector-based database management in the field of liquidity optimization. This is exactly what the Alice test is designed to prevent: the monopolization of basic tools (like vectors and hyperplanes) for a specific abstract application. The combination of limitations does not amount to an inventive concept because each element (vectors, databases, batching) performs its expected function within the system. The “specific configuration” is simply a digital map of a financial process and does not represent a technical breakthrough that is “significantly more” than the abstract idea itself.
Argument #6:
(F). Applicant argues that for Independent Claims 1 and 11 the dynamic vector structure wherein the payable vector and receivables vector dynamically grow and shrink based on transaction activity provide a specific technical mechanism that is not conventional. The suggestion that vectors are conventional data structures does not address the specific implementation of dynamically adjusting vectors within segregated database corpora to enable real-time transaction prioritization under revised step 2B of the 35 U.S.C. § 101 analysis (see Applicant Remarks, 3rd ¶ of Page 4, dated 11/25/2025). Examiner respectfully disagrees.
Examiner argues that the Applicant is conflating a software property with a patentable technical innovation. The argument that “dynamically grow and shrink” is a specific technical mechanism is misplaced. In modern computing, dynamic memory allocation for data structures like vectors is a foundational and conventional feature of virtually all programming languages (e.g. C++, Python, Java). Simply applying this inherent property of a standard data structure to a specific type of data (financial transactions) does not transform the conventional into the unconventional. Moreover, Independent Claims 1 and 11 fails to recite a specific algorithm or a novel memory management technique that achieves this growth and shrinkage. Without a specific technical improvement – such as a new way to reallocate memory blocks or reduce fragmentation – the system is merely performing the task of adding or removing items from a list. Business Necessity vs. Technical Invention. The “dynamic” nature of the vector is dictated by the nature of the data (the business activity), not a technical breakthrough. Because transactions occur at unpredictable intervals, any computer-readable medium must be able to adjust to the data volume. Using a computer to do what it is designed to do – scale data storage based on input – is the definition of a generic computer implementation under Alice Corp. v. CLS Bank. Field-of Use Restriction: The “segregated database corpora” serves only to limit the abstract idea to the field of accounting. MPEP 2106.05 (h) clarifies that limiting the use of an abstract idea to a particular technological environment or industry does not constitute an inventive concept. Segregating data into “payables” and “receivables” is an old accounting practice; doing so in a “dynamic vector” is just the modern digital equivalent. Reordering transactions for liquidity is a ask historically performed by accountants using ledgers. The “real-time” aspect and the “dynamic” updates are simply the result of using a generic computer instead of a human. Under OIP Techs., Inc. v. Amazon.com, Inc., relying on a computer’s ability to process data faster than a human does not provide an inventive concept. The combination of “dynamic vectors” and “segregated corpora” does not add “significantly more” because it relies on the standard features of generic computer components toe execute a fundamental economic practice. The implementation lacks any “non-conventional” step that improves the computer’s own technical performance.
Argument #7:
(G). Applicant argues that for Independent Claims 1 and 11 the hyperplane limitation adds further technical specificity by providing a computational construct for identifying and manipulating transaction priorities. This is not a conventional database storing operation, but rather a specific technical mechanism for defining execution priority across multiple dynamically adjusting vectors within segregated database structures. The micro-batch transaction functionality, which links ledgers associated with a subset of transactions, provides additional technical specificity by enabling optimized transaction batching based on the hyperplane-defined priorities under revised step 2B of the 35 U.S.C. § 101 analysis (see Applicant Remarks, 4th ¶ of Page 4, dated 11/25/2025). Examiner respectfully disagrees.
Examiner notes the terms are simply mathematical and labels for data storing and grouping applied to a business problem. A “hyperplane” is a mathematical concept. Using a mathematical construct to “identify and manipulate” priorities is a digital version of a “ranking formula.” According to Parker v. Flook, a mathematical formula – even if limited to a specific use case – cannot be the “inventive concept” that makes a claim patent-eligible. “Sophisticated Sorting” is still sorting. The argument that that is not a “conventional database storing operation” is unsupported. Sorting data based on multiple variables (e.g., payables vs. receivables) is a WURC function of any database. Whether the logic is called a “sort”, “a filter” or a “hyperplane manipulation”, the computer is simply reordering records based on a provided rule. Functional Claiming of “Desired Liquidity”: The limitation that the hyperplane is “manipulated to provide desired liquidity” is a result-oriented requirement. It does not specify the technical steps the computer takes to perform the manipulation. Under SAP America, Inc. v. InvestPic, LLC, “the claim must be more than a “black box” that provides a result.” Without a specific algorithm, this is merely an instruction to “use math to fix the cash flow.” “Linking ledgers” to create “micro-batches” is a standard batch processing technique. Grouping transactions (a “subset”) for efficiency is a basic data-handling task. The claims do not recite a technical protocol that improves ledger interoperability or reduces network latency; it simply groups them based on the earlier mathematical prioritization. To satisfy Step 2B, the “combination” must improve the functioning of the computer. Here, the “optimization” is of the business outcome (liquidity), not the computer’s hardware utilization or operating system. The computer is acting as a passive tool to perform the calculations required by the business model. The “hyperplane” and “micro-batch” limitations are merely mathematical and administrative refinements of the abstract idea. They do not involve an unconventional technical implementation that transforms the computer’s operation. Therefore, they fail to provide “significantly more” than the judicial exception.
Argument #8:
(H). Applicant argues that the ordered combination of these elements provides significantly more than any abstract idea by reciting a specific technical architecture that improves computer functionality. The segregated database corpora enable parallel processing of distinct transaction types, the dynamically adjusting vectors enable real-time transaction management, the hyperplane provides a computational mechanism for multi-vector prioritization, and the micro-batch transaction functionality enables optimized execution. This ordered combination solves the technical problem of how to structure and manipulate data within a computer system to enable real-time liquidity optimization while maintaining data integrity across segregated structures. It is respectfully suggested that the claimed combination of segregated database corpora with dynamically adjusting vector-based racks, hyperplane-based prioritization, and micro-batch ledger linking is not WURC (see Applicant Remarks, Page 5, dated 11/25/2025). Examiner respectfully disagrees.
These elements, even in combination, do not amount to "significantly more" under 35 U.S.C. § 101 Step 2B. Segregating data into different databases or tables for optimized access is known as partitioning or sharding. This is a conventional, foundational technique for managing large datasets and improving query efficiency, rather than a specialized improvement to computer functionality itself. Using parallel processing on these partitioned databases is simply using a generic computer to do what it is designed to do, which is insufficient to provide an inventive concept. Vector-based data management, especially with dynamic adjustment, is a well-established concept in AI and database systems, often used for improving AI search. Furthermore, using dynamic priority scheduling—where priorities change based on system state—is a standard operating system algorithm for improving data handling. Implementing a known analytical method ("vectors") on a computer does not transform it into a patentable invention. A hyperplane is a mathematical concept used in support vector machines (SVM) to separate and classify data. Utilizing a hyperplane for prioritization is an application of a mathematical algorithm. Simply mapping a mathematical concept onto a computer, without specifying a unique, non-generic hardware configuration, remains an abstract idea. "Batching" or "micro-batching" is a staple technique in computer science to optimize input/output (I/O) efficiency. Applying standard batching techniques to a specific data-processing scenario (transactional ledgering) is a well-known, conventional, and Routine ("well-understood, routine, and conventional") method of improving throughput. The combination of these elements—sharding (segregated data), SVMs (hyperplanes), and batch processing—amounts to nothing more than a conventional "combination of known elements to optimize performance," which is what computer programmers do routinely. The Federal Circuit has frequently held that "increased speed and efficiency" resulting from using generic computer components in a conventional way is not "significantly more".
In conclusion, for Independent Claims 1 and 11, the claimed elements, both individually and in combination, do not offer an "inventive concept" (significantly more) that transforms the underlying abstract idea. The limitations merely describe "steps, specified at a high level of generality" (e.g., using a vector to categorize and a database to store).
Argument #9:
(I). Applicant argues that Claims 1-6, 8-16 and 18-20 recite additional elements that amount to significantly more than the recited judicial exceptions under revised step 2B of the 35 U.S.C. § 101 analysis (see Applicant Remarks, Pages 4-5, dated 11/25/2025). Examiner respectfully disagrees.
In response, Examiner refers Applicant to Examiner’s 35 U.S.C. 101 analysis section (e.g., Claim Rejections - 35 U.S.C. § 101 section shown below) shown for step 2B particularly for Independent Claims 1 and 11. The claims do not recite additional elements that amount to significantly more than the recited judicial exceptions, because they are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exceptions. The limitations are directed to limitations referenced in MPEP § 2106.05I.A. that are not enough to qualify as significantly more when recited in these claims with the abstract idea which include: (1) adding the words “apply it” (or an equivalent) with the judicial exception, (2) or mere instructions to implement an abstract idea on a computer and providing the results to the user on a computer, and (3) generally linking the use of the judicial exception to a particular technological environment or field of use.
Moreover, Examiner refers Applicant to BSG Tech LLC v. Buyseasons Inc. decision (Aug. 15, 2018) court case noting that: “But the relevant inquiry is not whether the claimed invention as a whole is unconventional or non-routine. At Step two, we “search for an ‘inventive concept’… that is sufficient to ensure that the patent in practice amounts to significantly more than a patent upon the [ineligible concept] itself.” Alice, 134 S. Ct. at 2355 (internal quotation marks omitted) (quoting Mayo, 566 U.S. at 72-73). But this simply restates what we have already determined is an abstract idea. At Alice step two, it is irrelevant whether considering historical usage information while inputting data may have been non-routine or unconventional as a factual matter. As a matter of law, narrowing or reformulating an abstract idea does not add “significantly more” to it. See SAP Am., Inc. v. InvestPic, LLC. No. 2017-2081, slip op. at 14 (Fed. Cir. 2018). Applicant’s suggestion that specific limitations (or the claimed invention as a whole) must be shown to be well-understood, routine, and conventional to support the conclusion of subject matter ineligibility is not persuasive.
Independent Claims 1 and 11: With respect to the additional elements of (e.g., “payables rack” & “receivables rack” & “data structures” & “ledgers”) when considered with the recited claim limitations both individually and as an ordered combination (as a whole), these additional elements do not amount to significantly more than the judicial exceptions under step 2B due to: (1) reciting mere instructions to implement an abstract idea on a computer or using a computer as a tool to “apply” the recited judicial exceptions (see MPEP § 2106.05(f)) or (2) the claims as a whole are limited to a particular field of use or technological environment for managing financial obligations and cash flow for predicting liquidity requirements in order to prioritizing financial transactions in a business enterprise environment (see MPEP § 2106.05(h)).
Moreover, with respect to Independent Claims 1 and 11, certain/particular limitations shown recite (1) mere data gathering (e.g., “receive requests from an organization to conduct one or more transactions, wherein the one or more transactions include the receivable transactions and the payable transactions”) in which each of these claim limitations reflects mere insignificant extra-solution activities (see MPEP § 2106.05 (g)). Furthermore, these certain/particular claim limitations as demonstrated above for Independent Claims 1 and 11 reflects Well-Understood, Routine and Conventional Activities (WURC) under MPEP § 2106.05 (d) ii: See Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec,838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359,1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network). With respect to Independent Claims 1 and 11, certain/particular limitations shown recite sorting information such as (e.g., “prioritize the one or more transactions based upon the liquidity requirement by reordering the payables rack and the receivables rack to provide desired liquidity”) reflects Well-Understood, Routine and Conventional Activities (WURC) under MPEP § 2106.05 (d) ii: vii. Arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331,115 USPQ2d 1681, 1699 (Fed. Cir. 2015).
The ordered combination of elements in the Dependent Claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself. Therefore, under Step 2B, Claims 1-6, 8-16 and 18-20 do not include additional elements that are sufficient to amount to significantly more than the recited judicial exceptions. Thus, Claims 1-6, 8-16 and 18-20 are ineligible with respect to the 35 U.S.C. § 101 analysis.
Claim Rejections - 35 USC § 101
7. 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.
8. Claims 1-6, 8-16 and 18-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-6, 8-16 and 18-20 are focused to a statutory category namely, a “system” or an “apparatus” (Claims 1-6 and 8-10) and a “method” or a “process” (Claims 11-16 and 18-20).
Step 2A Prong One: Independent Claims 1 and 11 recites limitations that set forth the abstract idea(s), namely (see in bold except where strikethrough):
“” (see Independent Claim 1);
“” (see Independent Claim 1);
“ a payables corpus and a receivables corpus, wherein the payables corpus and the receivables corpus are segregated configured to enable processing of payable transactions and receivable transactions” (see Independent Claim 1);
“ a payables corpus and a receivables corpus, wherein the payables corpus and the receivables corpus are segregated configured to enable processing of payable transactions and receivable transactions” (see Independent Claim 11);
“receiving requests from an organization to conduct one or more transactions, wherein the one or more transactions include the receivable transactions and the payable transactions” (see Independent Claims 1 and 11);
“create a payables stored as a payables vector within the payables corpus , the payables listing the payable transactions associated with the organization, wherein the payables vector dynamically grows and shrinks” (see Independent Claims 1 and 11);
“create a receivables stored as a receivables vector within the receivables corpus , the receivables listing the receivable transactions associated with the organization, wherein the receivables vector dynamically grows and shrinks” (see Independent Claims 1 and 11);
“identifying a current liquidity status and one or more business activities associated with the organization” (see Independent Claims 1 and 11);
“predicting a liquidity requirement of the organization based upon the receivable transactions, the payable transactions, the current liquidity status and the one or more business activities” (see Independent Claims 1 and 11);
“prioritizing the one or more transactions based upon the liquidity requirement by reordering the payables and the receivables to provide desired liquidity” (see Independent Claims 1 and 11);
“including: defining a hyperplane from top rows of the payables vector and the receivables vector, wherein the hyperplane identifies transactions to be executed before other transactions” (see Independent Claims 1 and 11);
“manipulate the hyperplane to provide the desired liquidity” (see Independent Claims 1 and 11);
“determine a subset of the one or more transactions to be executed as a micro-batch transaction” (see Independent Claims 1 and 11);
“link associated with the subset of the one or more transactions to create the micro-batch transaction” (see Independent Claims 1 and 11).
Here, for Independent Claims 1 and 11, the steps describe receiving transaction requests, organizing them into “payables” and “receivables” data structures, predicting liquidity needs, and reordering (prioritizing) those transactions. This is a digital implementation of managing financial obligations and cash flow. The abstract idea is directed to managing liquidity by prioritizing financial transactions. These limitations fall under “Certain Methods of Organizing Human Activities”, specifically Fundamental Economic Practices. Managing liquidity, prioritizing payments (payables), and tracking income (receivables) are core commercial interactions that have long existed in business, regardless of the technology used to track them. The steps of “determine a subset… to be executed as a micro-batch” and “link ledgers… to create micro-batch transactions” are directed to the administration of financial transactions and ledger management. Even with the technical-sounding “micro-batch” and “linking ledgers” terminology, these steps describe the organization and grouping of financial obligations, which is a fundamental economic practice. Additionally, some elements, such as “predicting a liquidity requirement” and “prioritizing…by reordering,” could also be characterized as “Mental Processes” because they involve evaluations and judgments that could technically be performed in the human mind, even if a computer does them faster or with more data. Identifying transactions to be executed “before other transactions” and “determining a subset” are evaluations and judgments that can be performed in the human mind or with pen and paper, particularly if the criteria for the “subset” are not tied to a specific computer-centric constraint. The steps of “define a hyperplane from top rows of the payables vector and the receivables vector” and “manipulate the hyperplane” recite mathematical relationships and calculations under the “Mathematical Concepts” grouping. A hyperplane is a mathematical construct used here to partition or classify data. Reciting the manipulation of such a mathematical boundary is a direct recitation of a mathematical concept. While these claims use geometric and data-science terminology (e.g., “hyperplane”, “vectors” and “micro-batch”), these concepts reflect a mathematical model for a business task; deciding which bills to pay and which payments to collect in what groups (batches) to ensure enough cash is on hand. These claims also use technical terms like “vectors”, “segregated data structures” and “dynamically grows and shrinks”, at its core, it is a method for deciding which bills to pay first based on expected income – a fundamental business task.
Therefore, these abstract idea limitations (as identified above in bold), under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as “Mental Processes” which pertains to (1) concepts performed in the human mind (including observations or evaluations or judgments) or (2) using pen and paper as a physical aid, which in order to help perform these mental steps does not negate the mental nature of these limitations. The use of "physical aids" in implementing the abstract mental process, does not preclude the claim from reciting an abstract idea. See MPEP § 2106.04(a) III C.
Additionally, or alternatively, these abstract idea limitations (as identified above in bold), under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as “Certain Methods of Organizing Human Activities” which pertains to (3) commercial interactions (including sales activities or behaviors or business relations) or (4) fundamental economic principles or practices and additionally or alternatively cover performance of their limitations as “Mathematical Concepts” which pertains to (5) mathematical relationships or (6) mathematical calculations.
That is, other than reciting (e.g., “one or more processors” & “non-transitory computer readable medium” & “computer system” & “racks” & “ledgers” & “a database” & “data structures”), nothing in the claim elements precludes the steps from being performed as “Mental Processes” which pertains to (1) concepts performed in the human mind (including observations or evaluations or judgments) or (2) using pen and paper as a physical aid and additionally or alternatively as “Certain Methods of Organizing Human Activities” which pertains to (3) commercial interactions (including sales activities or behaviors or business relations) or (4) fundamental economic principles or practices and additionally or alternatively as “Mathematical Concepts” which pertains to (5) mathematical relationships or (6) mathematical calculations.
Therefore, at step 2a prong 1, Yes, Claims 1-6, 8-16 and 18-20 recites an abstract idea. We proceed onto analyzing the claims at step 2a prong 2.
Step 2A Prong Two: With respect to Step 2A Prong Two of the eligibility inquiry (as explained in MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. Independent Claim 1 recites additional elements directed to: (e.g., “one or more processors” & “a database” & “non-transitory computer readable medium” & “computer system”). Independent Claim 11 recites additional elements directed to: (e.g., “a database”). These additional elements have been considered individually and in combination, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment. See MPEP § 2106.05(f) and MPEP § 2106.05(h).
Independent Claims 1 and 11: With respect to the additional elements of (e.g., “payables rack” & “receivables rack” & “data structures” & “ledgers”) when considered with the recited claim limitations both individually and as an ordered combination (as a whole), these additional elements do not integrate the abstract idea into a practical application under step 2a prong 2 according to the following: (1) reciting mere instructions to implement an abstract idea on a computer or using a computer as a tool to “apply” the recited judicial exceptions (see MPEP § 2106.05(f)) or (2) the claims as a whole are limited to a particular field of use or technological environment for managing financial obligations and cash flow for predicting liquidity requirements in order to prioritizing financial transactions in a business enterprise environment (see MPEP § 2106.05(h)).
Moreover, with respect to Independent Claims 1 and 11, certain/particular limitations shown recite (1) mere data gathering (e.g., “receive requests from an organization to conduct one or more transactions, wherein the one or more transactions include the receivable transactions and the payable transactions”) in which each of these claim limitations reflects mere insignificant extra-solution activities (see MPEP § 2106.05 (g)).
In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception. Therefore, at step 2a prong 2, Claims 1-6, 8-16 and 18-20 are directed to the abstract idea and do not recite additional elements that integrate into a practical application.
Step 2B: (As explained in MPEP § 2106.05), it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Independent Claim 1 recites additional elements directed to: (e.g., “one or more processors” & “non-transitory computer readable medium” & “computer system”). Independent Claim 11 recites additional elements directed to: (e.g., “a database”). These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (computing environment) and does not amount to significantly more than the abstract idea itself. See MPEP § 2106.05 (f) and MPEP § 2106.05 (h). Notably, Applicant’s Specification suggests that the claimed invention relies on nothing more than a general-purpose computer executing the instructions to implement the invention (e.g., see at Applicant’s Specification ¶ [0013-0014]: “The client devices 102, 104 and the third-party device 106 can communicate with the server device 112 through a network 110 to accomplish the functionality described herein. Each of the devices may be implemented as one or more computing devices with at least one processor and memory. Example computing devices include a mobile computer, a desktop computer, a server computer, or other computing device or devices such as a server farm or cloud computing used to generate or receive data.”).
Independent Claims 1 and 11: With respect to the additional elements of (e.g., “payables rack” & “receivables rack” & “data structures” & “ledgers”) when considered with the recited claim limitations both individually and as an ordered combination (as a whole), these additional elements do not amount to significantly more than the judicial exceptions under step 2B due to: (1) reciting mere instructions to implement an abstract idea on a computer or using a computer as a tool to “apply” the recited judicial exceptions (see MPEP § 2106.05(f)) or (2) the claims as a whole are limited to a particular field of use or technological environment for managing financial obligations and cash flow for predicting liquidity requirements in order to prioritizing financial transactions in a business enterprise environment (see MPEP § 2106.05(h)).
Moreover, with respect to Independent Claims 1 and 11, certain/particular limitations shown recite (1) mere data gathering (e.g., “receive requests from an organization to conduct one or more transactions, wherein the one or more transactions include the receivable transactions and the payable transactions”) in which each of these claim limitations reflects mere insignificant extra-solution activities (see MPEP § 2106.05 (g)). Furthermore, these certain/particular claim limitations as demonstrated above for Independent Claims 1 and 11 reflects Well-Understood, Routine and Conventional Activities (WURC) under MPEP § 2106.05 (d) ii: See Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec,838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359,1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network). With respect to Independent Claims 1 and 11, certain/particular limitations shown recite sorting information such as (e.g., “prioritize the one or more transactions based upon the liquidity requirement by reordering the payables rack and the receivables rack to provide desired liquidity”) reflects Well-Understood, Routine and Conventional Activities (WURC) under MPEP § 2106.05 (d) ii: vii. Arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331,115 USPQ2d 1681, 1699 (Fed. Cir. 2015).
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent Claims 2-6, 8-10, 12-16 and 18-20 recite substantially the same or similar additional elements as addressed above and when considered individually and as an ordered combination (as a whole) with these limitations recite the same abstract idea(s) as shown in Independent Claims 1 and 11 along with further steps/details pertaining to “Mental Processes” Grouping which pertains to (1) concepts that could be performed in the human mind (including observations or evaluations or judgments) or (2) using pen to paper as a “physical aid” or additionally or alternatively as “Certain Methods of Organizing Human Activities” Grouping which pertains to (3) commercial interactions (including sales activities or behaviors or business relations) or (4) fundamental economic principles or practices and additionally or alternatively as “Mathematical Concepts” which pertains to (5) mathematical relationships or (6) mathematical calculations. Dependent Claims 2-6, 8-10, 12-16 and 18-20 further narrow the abstract ideas, and are therefore still ineligible for the reasons previously provided in Steps 2A Prong 2 and Step 2B for Independent Claims 1 and 11.
The ordered combination of elements in the Dependent Claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself. Therefore, under Step 2B, Claims 1-6, 8-16 and 18-20 does not include additional elements that are sufficient to amount to significantly more than the recited judicial exceptions. Thus, Claims 1-6, 8-16 and 18-20 are ineligible with respect to the 35 U.S.C. § 101 analysis.
Examining Claims with Respect to Prior Art
9. Independent Claims 1 and 11 have overcome the prior art rejection (see Applicant’s Remarks, Pages 5-6 filed on 11/25/2025), have been fully considered and are found to be persuasive. Therefore Claims 1-20 are withdrawn over the 35 U.S.C. § 103 prior art rejections.
However, Claims 1-6, 8-16 and 18-20 remain still rejected over 35 U.S.C. § 101.
For Independent Claims 1 and 11, there is no disclosure in the existing prior art or any new art that either teaches and/or discloses the sequence operation of each of these features either individually or in combination relating to:
- create a payables rack stored as a payables vector within the payables corpus of the database, the payables rack listing the payable transactions associated with the organization, wherein the payables vector dynamically grows and shrinks;
- create a receivables rack stored as a receivables vector within the receivables corpus of the database, the receivables rack listing the receivable transactions associated with the organization, wherein the receivables vector dynamically grows and shrinks;
- define a hyperplane from top rows of the payables vector and the receivables vector, wherein the hyperplane identifies transactions to be executed before other transactions;
- manipulate the hyperplane to provide the desired liquidity;
- determine a subset of the one or more transactions to be executed as a micro-batch transaction;
- link ledgers associated with the subset of the one or more transactions to create the micro-batch transaction.
The closest prior arts are as follows:
(1) US PG Pub (US 2007/0156550 A1) hereinafter Der Emde, et. al., (2) US PG Pub (US 2024/0112157 A1) hereinafter Sun, et. al, and (3) US PG Pub (US 2024/0232831 A1) hereinafter Soramaki, et. al and (4) US PG Pub (US 2013/0103554 A1) hereinafter Agarwal, et. al.
Regarding the Der Emde, et. al. reference, Der Emde, et. al teaches or suggests the sequence of operations comprising the following:
- receive requests from an organization to conduct one or more transactions (see at least Der Emde: ¶ [0022] & ¶ [0068] & ¶ [0107-0108]. Der Emde notes that the Settlement Processing at Clearing House process component 504 is used to handle all incoming settlement requests from various process components. The Due Payment business object 614 represents payment requests for payment processing. This can be done manually or automatically. In contrast to payment requests from Human Capital Management solution, or Treasury, Due Payment is responsible for the payment and clearing of payables and receivables from goods and services. See also Der Emde at ¶ [0022]: The Financial Accounting deployment unit 102 contains an accounting process component 108 that records all relevant business transactions. See also Der Emde at ¶ [0107-0108]: The Due Payment business object 916 represents payment requests for payment processing. The Payment Allocation business object 906 initiates clearing requests within the Payment Processing process component 902.), where the transactions include receivable transactions and payable transactions (see at least Der Emde: ¶ [0059] & (Claim 1 of Der Emde). Der Emde notes that the plurality of process components including: an Accounting process component that records relevant business transactions; a Due Item Processing process component that manages payables and receivables from service and supply. The Liquidity Status In interface 418 includes a synchronous Get Liquidity Status operation 426. Here, the operation 426 can receive the Liquidity Status Query message 414 requesting trade and tax status on receivables and payables.)
- identify a current liquidity status and one or more business activities associated with the organization (see at least Der Emde: Fig. 4 & ¶ [0059]. Der Emde notes that the Get Liquidity Status operation 426 sends a request to the Sync Get Liquidity Status from Due Item Processing inbound process agent 420. Upon completion of the request, the Get Liquidity Status operation 426 provides the result of the query in the Liquidity Status Response message 416 for use by the process component that originated the query. Here, to process the query, the process agent 420 invokes at least one included business object, such as a Trade Receivables Payables Register business object 422 or a Tax Receivables Payables Register business object 424. The Tax Receivables Payables Register business object may represent all tax due for the corresponding receivables and payables such as: delivered goods and rendered services between buyers and sellers, the consumption of goods, the transfer of goods, or vendor payments withheld. Examiner Note: Examiner interprets that the one or more business activities in Der Emde is the “delivery/deployment of products”.)
However, Der Emde, et. al. specifically, does not teach or suggest the sequence of operations comprising:
- create a payables rack stored as a payables vector within the payables corpus of the database, the payables rack listing the payable transactions associated with the organization, wherein the payables vector dynamically grows and shrinks;
- create a receivables rack stored as a receivables vector within the receivables corpus of the database, the receivables rack listing the receivable transactions associated with the organization, wherein the receivables vector dynamically grows and shrinks;
- define a hyperplane from top rows of the payables vector and the receivables vector, wherein the hyperplane identifies transactions to be executed before other transactions;
- manipulate the hyperplane to provide the desired liquidity;
- determine a subset of the one or more transactions to be executed as a micro-batch transaction;
- link ledgers associated with the subset of the one or more transactions to create the micro-batch transaction.
Regarding the Sun reference, Sun teaches or suggests the sequence of operations comprising the following:
- predict a liquidity requirement of the organization based upon the receivable transactions (see at least Sun: ¶ [0018-0019] & ¶ [0035] & ¶ [0053]. Sun teaches that the determination of whether the low liquidity threshold has been met for an upcoming time interval can take into account current amounts of a corresponding target liquidity asset, a forecast of target liquidity asset which may be received by the transaction entity (e.g., receipt of account receivables, through expected or planned exchanges of other types of assets, etc.), as well as the current and/or forecasted demand on the transaction entity for a corresponding target liquidity asset. The computing system can process historical consumption data of the transaction entity combined with the transaction entity rules to make periodically or dynamically updated predictions of the transaction entity's liquidity requirements to establish and update the low liquidity threshold for the transaction entity's digital wallet.), the payable transactions (see at least Sun: ¶ [0035] & ¶ [0045] & ¶ [0075]. Sun notes that the forecasting can be based on historical activities of the transaction entity with respect to the digital wallet and/or one or more financial accounts (e.g., payables account) associated with the digital wallet. The forecasting can identify the number and/or amount (e.g., in terms of source fiat) of cross-border transactions the particular transaction entity will perform, as well as the time when such payments are needed. The liquidity management engine 135 can implement liquidity evaluation operations by determining liquidity metrics for each transaction entity 170. The liquidity metrics can reflect a current or forecasted availability of an asset of a particular type that matches to a liquidity need, also referenced herein as a “target liquidity asset”. In many cases, the target liquidity asset for a transaction entity 170 is a fiat (e.g., USD), which are most typically used to meet liquidity demands for working capital (e.g., daily accounts payable, periodic accounts payable such as payroll, etc.). See also Sun at ¶ [0075]: The liquidity demands can correspond to, for example, withdrawals (e.g., for accounts payables) from the monitored digital wallet(s) and/or financial accounts of the user.), the current liquidity status (see at least Sun: ¶ [0036] & ¶ [0045-0046] & ¶ [0049-0050]. Sun teaches that the transactions can, for example, be performed as part of the working capital workflow of the transaction entity 170. In such examples, the liquidity data can reflect the working capital requirements of the transaction entity 170, including payment or transaction information of the transaction entity 170 over a given time frame (e.g., cross-border, foreign exchange transactions and trades, commodity conversions or trades, etc.).) and the one or more business activities (see at least Sun: ¶ [0045] & ¶ [0049] & ¶ [0079]. Sun teaches that at the automated rebalancing function provided by the liquidity management engine 135 can comprise a loan or advance of digital currency to the transaction entity 170. The transaction entity 170 may hold the advanced amount in the digital wallet until the advancement is utilized (e.g., for a payment or other transaction). At the point of utilization, the transaction entity 170 can be provided with a payment request from the computing system 100 at a current or guaranteed exchange rate to cover the advanced funds. See also Sun at ¶ [0045]: Transaction entities 170 can also have liquidity demands for non-fiat assets, such as contractual demand for particular types of digital assets (e.g., XRP, Bitcoin), or internal (entity-specific) rules or preferences for maintaining certain types of assets for investment and/or balance sheet purposes (e.g., periodic contribution of Bitcoin or other digital asset as inflation hedge). See also Sun at ¶ [0035]: The liquidity management engine 135 forecasts transaction activities of the transfer entity 170 where funding of digital currency is to occur (e.g., such as for cross-border payments). The forecasting can be based on historical activities of the transaction entity with respect to the digital wallet and/or one or more financial accounts (e.g., payables account) associated with the digital wallet. Examiner Note: Examiner interprets that the one or more business activities in the Sun reference are based on “investing and financing” for example.).
However, Sun specifically, does not teach or suggest the sequence of operations comprising:
- create a payables rack stored as a payables vector within the payables corpus of the database, the payables rack listing the payable transactions associated with the organization, wherein the payables vector dynamically grows and shrinks;
- create a receivables rack stored as a receivables vector within the receivables corpus of the database, the receivables rack listing the receivable transactions associated with the organization, wherein the receivables vector dynamically grows and shrinks;
- define a hyperplane from top rows of the payables vector and the receivables vector, wherein the hyperplane identifies transactions to be executed before other transactions;
- manipulate the hyperplane to provide the desired liquidity;
- determine a subset of the one or more transactions to be executed as a micro-batch transaction;
- link ledgers associated with the subset of the one or more transactions to create the micro-batch transaction.
Regarding the Soramaki reference, Soramaki teaches or suggests the sequence of operations comprising the following:
- prioritize the one or more transactions based upon the liquidity requirement (see at least Soramaki: ¶ [0015] & ¶ [0032] & ¶ [0038] & ¶ [0084]. Soramaki notes that the plurality of transactions received in the first order are re-arranged in such a manner as the liquidity requirements for settling the plurality of transactions is significantly reduced. See also Soramaki at ¶ [0015]: The “liquidity requirements” relate to an overall amount of liquidity needed by the payment system to facilitate settlement of the plurality of transactions, in the payment system. The plurality of transactions in the payment system are managed to minimize the liquidity requirements for settling the plurality of transactions. For example, the reordering of the plurality of transactions yields liquidity requirements similar or near similar to the liquidity requirements obtained from multilateral netting. The liquidity requirements are managed to ensure uninterrupted settlement of the plurality of transactions in the payment system and to increase efficiency and stability in the payment system. See also Soramaki at ¶ [0038]: The plurality of transactions (arranged in the first order) are selected one by one starting from the first transaction to the last transaction. The feasibility of the given transaction is determined by comparing values of the available liquidity of the sender associated with the given transaction with the value of the given transaction. See also Soramaki at ¶ [0084]: The liquidity requirements for settling the transactions X1 and X2 using the second order are also determined as a sum of negative balances at the end of all transactions, which in this case, is equal to −10. Thus, the liquidity requirements for settling the transactions X1 and X2 using the second order are 50% lesser than the liquidity requirements for settling the transactions X1 and X2 using the first order. See also Soramaki at ¶ Figs. 3A & Fig. 3B.).
However, Soramaki specifically, does not teach or suggest the sequence of operations comprising:
- create a payables rack stored as a payables vector within the payables corpus of the database, the payables rack listing the payable transactions associated with the organization, wherein the payables vector dynamically grows and shrinks;
- create a receivables rack stored as a receivables vector within the receivables corpus of the database, the receivables rack listing the receivable transactions associated with the organization, wherein the receivables vector dynamically grows and shrinks;
- define a hyperplane from top rows of the payables vector and the receivables vector, wherein the hyperplane identifies transactions to be executed before other transactions;
- manipulate the hyperplane to provide the desired liquidity;
- determine a subset of the one or more transactions to be executed as a micro-batch transaction;
- link ledgers associated with the subset of the one or more transactions to create the micro-batch transaction.
Regarding the Agarwal reference, Agarwal teaches or suggests the sequence of operations comprising the following:
- create a payables rack, with the payables rack listing the payable transactions associated with the organization (see at least Agarwal: Fig. 3 & ¶ [0029-0031] & (Table 1 of Agarwal). Agarwal teaches that the classified payables and receivables are arranged adjacently in an integrated view by a display module (not shown in the figure). Such integrated view may be in the form of a table, a spreadsheet, etc. Further, a position mapping module 110 enables the user to operate upon the integrated view by linking the positions and receivables with each other. In other words, as the user observes the columns of payables and receivables in a table like format, the user is provided with an option to match or link a payable with one or more receivables and vice versa. The integrated view of the payables and receivables associated with company A, B, C and D as presented by the display module will be of a following form. The payable worth 20 million and the receivable worth 20 million are part of the same transaction. Accordingly, the user can link the payable with the receivable, thereby linking one position with another. See also Agarwal at ¶ [0040]: The display module 214 presents an integrated view of the payables and receivable by showcasing the payables and the receivables in the form a table or a spreadsheet. Further, the integrated view as presented by the display module 214 may be seen by a user in different forms, depending upon selection of any one characteristic out of the three characteristics. Such characteristics are related to each of the positions and include transaction related parameters of the corresponding positions. See also Table 1 of Agarwal noting the payables rack and receivables rack linking transactions.)
- creating a receivables rack, with the receivables rack listing the receivable transactions associated with the organization (see at least Agarwal: Fig. 3 & ¶ [0029-0031] & (Table 1 of Agarwal). Agarwal teaches that the classified payables and receivables are arranged adjacently in an integrated view by a display module (not shown in the figure). Such integrated view may be in the form of a table, a spreadsheet, etc. Further, a position mapping module 110 enables the user to operate upon the integrated view by linking the positions and receivables with each other. In other words, as the user observes the columns of payables and receivables in a table like format, the user is provided with an option to match or link a payable with one or more receivables and vice versa. The integrated view of the payables and receivables associated with company A, B, C and D as presented by the display module will be of a following form. The payable worth 20 million and the receivable worth 20 million are part of the same transaction. Accordingly, the user can link the payable with the receivable, thereby linking one position with another. See also Agarwal at ¶ [0040]: The display module 214 presents an integrated view of the payables and receivable by showcasing the payables and the receivables in the form a table or a spreadsheet. Further, the integrated view as presented by the display module 214 may be seen by a user in different forms, depending upon selection of any one characteristic out of the three characteristics. Such characteristics are related to each of the positions and include transaction related parameters of the corresponding positions. See also Table 1 of Agarwal noting the payables rack and receivables rack linking transactions.).
However, Agarwal specifically, does not teach or suggest the sequence of operations comprising:
- create a payables rack stored as a payables vector within the payables corpus of the database, the payables rack listing the payable transactions associated with the organization, wherein the payables vector dynamically grows and shrinks;
- create a receivables rack stored as a receivables vector within the receivables corpus of the database, the receivables rack listing the receivable transactions associated with the organization, wherein the receivables vector dynamically grows and shrinks;
- define a hyperplane from top rows of the payables vector and the receivables vector, wherein the hyperplane identifies transactions to be executed before other transactions;
- manipulate the hyperplane to provide the desired liquidity;
- determine a subset of the one or more transactions to be executed as a micro-batch transaction;
- link ledgers associated with the subset of the one or more transactions to create the micro-batch transaction.
Therefore, when taken as a whole, the claims are not rendered obvious as the available prior art does not suggest or otherwise render obvious the noted features nor do the available art suggest or otherwise render obvious further modification of the evidence at hand. Such modification would require substantial reconstruction relying solely on improper hindsight bias, and thus would not be obvious.
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 DERICK HOLZMACHER whose telephone number is (571) 270-7853. The examiner can normally be reached on Monday-Friday 9:00 AM – 6:30 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, Brian Epstein can be reached on 571-270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-270-8853.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DERICK J HOLZMACHER/Patent Examiner, Art Unit 3625A
/BRIAN M EPSTEIN/Supervisory Patent Examiner, Art Unit 3625