DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant filed a response dated September 2, 2025 in which claims 1, 12, and 19 have been amended. Therefore, claims 1-20 are currently pending in the application.
Priority
Application 18/101,017 was filed on January 24, 2023.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
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., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method and system which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A system to maintain the state of disparate data structures, the system comprising: a communication network interface to interface with a communication network; a memory to store: a ledger data structure storing a set of exchanges of a capacity plan; a plurality of container data structures of the capacity plan, each container data structure of the plurality of container data structures linked to a plurality of exchanges of the set of exchanges of the capacity plan of the ledger data structure, and each container data structure of the plurality of container data structures having container parameters specifying one or more aspects of the capacity plan in relation to the plurality of exchanges linked to the container data structure; and
a parameter adjustment data structure to store parameter adjustment information for exchanges corresponding to each of the plurality of container data structures, the parameter adjustment data structure including: a plurality of segments, each segment physically distinct from each other and corresponding to a different exchange of the set of exchanges and
including: an exchange identifier of the exchange of the segment; and a container identifier of a container data structure of the plurality of container data structures linked to the exchange, wherein the container identifier is stored in the segment for the exchange in the parameter adjustment data structure to enable subsequent updates to the exchange without reprocessing unrelated configuration parameters; and
one or more processors to: receive, via the communication network interface, a set of exchange data for the plurality of exchanges of a container data structure of the plurality of container data structures,
the set of exchange data comprising the identifier of the container data structure;
identify each segment corresponding to an exchange of the plurality of segments that contains the identifier of the container data structure from the received set of exchange data;
generate, using the set of exchange data and container parameters for the container data structure, parameter adjustment information for each exchange of the plurality of exchanges based on the links between the plurality of exchanges and the container data structure, the parameter adjustment information indicating a first current state of an adjustment to a container parameter of the container data structure corresponding to each exchange;
dynamically insert, into each of the identified segments of the parameter adjustment data structure,
an indication of the first current state of the adjustment to the container parameter in the segment for the exchange corresponding to the segment and
linked to the container data structure by the identifier of the exchange in the segment;
detect an end to a defined time interval beginning at a time of the insertion into the parameter adjustment data structure;
responsive to the detection, update the indication of the first current state of the adjustment to the container parameter
in the segment for each exchange of the plurality of exchanges based on the links between the plurality of exchanges and the container data structure to a second current state of the adjustment to the container parameter; and
generate a record based on the second current state of the adjustment to the container parameter
in the segment for each exchange of the plurality of exchanges of the container data structure without identifying any prior states of the adjustment to the container parameter of the exchange.
The claim as a whole recites a method that, under its broadest reasonable interpretation covers collecting, analyzing, and transmitting data to facilitate a system for managing a line of credit and loan with related abatement information and parameters and generating a result. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting “A system to maintain the state of disparate data structures, the system comprising: a communication network interface to interface with a communication network; a memory to store:”, and “one or more processors to: receive, via the communication network interface”, to perform the steps of “identifying”, “generating”, “updating”, and “detecting” nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. The claim as a whole does not integrate the exception into a practical application. The claim merely describes how to generally “apply” the concept collecting, analyzing, and transmitting data to facilitate a system for managing a line of credit and loan with related abatement information and parameters and generating a result in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification at [0076]-[0077] discloses “The user device140 (sometimes referred to herein as a "computing system") may be a mobile computing device, desktop computer, smartphone, tablet, smart watch, smart sensor or any other device configured to facilitate receiving, displaying and interacting with content (e.g., webpages, mobile applications, etc.). The user device140 may include an application142 to receive and display content and to receive user interactions with the content. For example, an application142 may be a web browser. Additionally, or alternatively, the application142 may be a mobile application. User device140 may also include an input/output circuit for communicating data over network130 (e.g., receive and transmit to provider system110 and/or third-party systems150).”
Additionally, the claimed “containers” are merely adding extra-solution activity to the judicial exception, as merely data gathering and storing means of the user’s access to manipulate the data, and the “containers” are generally linking the judicial exception to a particular technological environment. The specification says no more than, “in some implementations, users of the application142 may have various levels of access to perform operations and review information (e.g., restricted access, access containers121, review containers121, submit claims, modify containers121, initiate containers121, authorize payment). Using a unique credentials (e.g., username, password, security code) (generally referred to herein as an "account"), a user (e.g., internal, or external) may gain access to perform various operations and review various information”. This is merely a generic means of interaction with the “containers”. (See Spec. [0082]).
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “A system to maintain the state of disparate data structures, the system comprising: a communication network interface to interface with a communication network; a memory to store:”, and “one or more processors to: receive, via the communication network interface”, to perform the steps of “identifying”, “generating”, “updating”, and “detecting”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a system for managing a line of credit and loan with related abatement information and parameters and generating a result in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Dependent claims 2-11, 13-18, and 20 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Claims 12 and 19 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 12 recites the additional elements of “A computer-implemented method maintain the state of disparate data structures, the computer- implemented method comprising:”.
Claim 19 recites the additional elements of “One or more non-transitory computer-readable storage media having instructions stored thereon that, when executed by at least one processing circuit, cause the at least one processing circuit to:”.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Therefore, claims 1-20 are not patent-eligible.
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 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Brock, U.S. Patent Application Publication Number 2021/0133868; in view of Sood, U.S. Patent Application Publication Number 2020/0118137; in view of Black, WIPO Patent Application Publication Number 2000/054200; in view of Huang, U.S. Patent Application Publication Number 2020/119298; in view of Grassadonia, WIPO Patent Application Publication Number 2018/0005229.
As per claim 1,
Brock explicitly teaches:
A system to maintain the state of disparate data structures, the system comprising: a communication network interface to interface with a communication network; a memory to store: a ledger data structure storing a set of exchanges of a capacity plan; a plurality of container data structures of the capacity plan, each container data structure of the plurality of container data structures linked to a plurality of exchanges of the set of exchanges of the capacity plan of the ledger data structure, and each container data structure of the plurality of container data structures having container parameters specifying one or more aspects of the capacity plan in relation to the plurality of exchanges linked to the container data structure; and
(Brock US20210133868 at Figs. 1A, 1B, and 2 and paras. 30-36, 58-61) ("[0059] FIG. 2 illustrates an example system architecture for a payment service system 108. In particular embodiments, the payment service system 108 may store customer profile 132 for each of a plurality of customers. Customer profile 132 may include customer data 201 that may include customer-identifying information (name, contact information, demographical data, etc.), a transaction log 202 including records of past transactions involving payment service system 108 by customer 104, information regarding linked accounts (credit card information, bank account information, etc.), information regarding services utilized by customer profile 132 (e.g., a mobile wallet application). The customer data 201 may further comprise information associated with one or more social or peer-to-peer contacts of a user (e.g., friends, family members, online network connections). The information may comprise at least part of the profile information of such contacts.")
one or more processors to: receive, via the communication network interface, a set of exchange data for the plurality of exchanges of a container data structure of the plurality of container data structures,
(Brock US20210133868 at paras. 21-23) ("As an example and not by way of limitation, a user may swipe a payment card associated with the user's account and the request may be automatically generated and sent to the payment service system. In particular embodiments, the user may access a user interface to request access to a debt instrument. As an example and not by way of limitation, a user may interact with a mobile application associated with a payment service system or other entity to access a user interface associated with a line of credit or on a webpage displayed by a browser installed on a computing device. The user may interact with one or more elements in a user interface to select to pull (e.g., cash advance) from the line of credit by requesting to transfer a portion of the line of credit to the user's balance. As an example and not by way of limitation, if a user has a balance of $400 on a financial account and wishes to maintain a balance of $300 (e.g., possibly for rent) the user may want to access a line of credit for any purchase greater than $100 to prevent the balance from falling below that amount. As such, the user may pull from a line of credit associated with the financial account (e.g., a line of credit of $200) to transfer a portion of the line of credit for a transaction. The user may input, through one or more elements of a user interface, a value to pull from the line of credit and send a request to the payment service system to transfer the portion of the line of credit to the user's balance.")
dynamically insert, into each of the identified segments of the parameter adjustment data structure,
(Brock US20210133868 at paras. 21-23) ("Once the user approves the pull from the line of credit for $25 the payment service system at the identified terms, the transaction may be authorized and the payment service system may update the user account to include the pull from the line of credit at the default or modified repayment terms.")
detect an end to a defined time interval beginning at a time of the insertion into the parameter adjustment data structure;
(Brock US20210133868 at paras. 26-28) ([0027] "In particular embodiments, the payment service system may determine a time period before a user is charged interest for a transaction using a debt instrument and present that to a user through a user interface within a mobile application associated with the payment application. If the user fails to pay off debt associated with a transaction before the time period, the payment service system may apply an interest rate to the remainder of the debt based on the repayment terms of the transaction. The payment service system may update the user account with any changes.")
responsive to the detection, update the indication of the first current state of the adjustment to the container parameter
(Brock US20210133868 at paras. 26-28) ([0027] "In particular embodiments, the payment service system may determine a time period before a user is charged interest for a transaction using a debt instrument and present that to a user through a user interface within a mobile application associated with the payment application. If the user fails to pay off debt associated with a transaction before the time period, the payment service system may apply an interest rate to the remainder of the debt based on the repayment terms of the transaction. The payment service system may update the user account with any changes.")
generate a record based on the second current state of the adjustment to the container parameter
(Brock US20210133868 at paras. 26-28) ([0027] "In particular embodiments, the payment service system may determine a time period before a user is charged interest for a transaction using a debt instrument and present that to a user through a user interface within a mobile application associated with the payment application. If the user fails to pay off debt associated with a transaction before the time period, the payment service system may apply an interest rate to the remainder of the debt based on the repayment terms of the transaction. The payment service system may update the user account with any changes.")
Brock does not explicitly teach, however, Sood teaches:
an indication of the first current state of the adjustment to the container parameter in the segment for the exchange corresponding to the segment and
(Sood US20200118137 at paras. 207-224) ("[0207] FIG. 3A depicts a data structure 300 according to an embodiment. The data structure, which can be stored in memory 202 of the transaction monitor 101 and/or the database 120 stores transaction data 304 and budget data 308 associated with a transaction. Transaction data 304 comprises attribute data 312, which includes transaction ID, user ID (e.g., who initiated the transaction), instrument ID (e.g., credit card number), company ID (e.g., employer), vendor ID, original amount, settled amount, related transaction(s), approval data generated as a result of applying rule sets for approving transactions (e.g., approval chain—who approved the transaction/item, modifications to the transaction data 304 made during the approval process, timestamp of approval event, approved amount for the transaction/item, etc.), receipt data, state ID (e.g., provisional approval of transaction/item, final approval of transaction/item, approval pending, transaction/item submitted for approval, approval denied for the transaction/item, transaction/item settled, timestamp associated with each event, etc.), and data entry type (e.g., inherited, automatic, or manual). The proceeding fields are provided for illustrative purposes only and are not meant to limit the fields that may be included the attribute data. [0208] FIG. 3B depicts a data structure 300 according to an embodiment. The data structure, which can be stored in memory 202 of the transaction monitor 101 and/or the database 120 stores context information, and includes context IDs 1-N (e.g., cost center, project, department, client), past behavior data, project ID, cost center ID, meeting ID, conference ID, etc. The proceeding fields are provided for illustrative purposes only and are not meant to limit the fields that may be included in the context.")
in the segment for each exchange of the plurality of exchanges of the container data structure without identifying any prior states of the adjustment to the container parameter of the exchange.
(Sood US20200118137 at paras. 207-224) ("[0207] FIG. 3A depicts a data structure 300 according to an embodiment. The data structure, which can be stored in memory 202 of the transaction monitor 101 and/or the database 120 stores transaction data 304 and budget data 308 associated with a transaction. Transaction data 304 comprises attribute data 312, which includes transaction ID, user ID (e.g., who initiated the transaction), instrument ID (e.g., credit card number), company ID (e.g., employer), vendor ID, original amount, settled amount, related transaction(s), approval data generated as a result of applying rule sets for approving transactions (e.g., approval chain—who approved the transaction/item, modifications to the transaction data 304 made during the approval process, timestamp of approval event, approved amount for the transaction/item, etc.), receipt data, state ID (e.g., provisional approval of transaction/item, final approval of transaction/item, approval pending, transaction/item submitted for approval, approval denied for the transaction/item, transaction/item settled, timestamp associated with each event, etc.), and data entry type (e.g., inherited, automatic, or manual). The proceeding fields are provided for illustrative purposes only and are not meant to limit the fields that may be included the attribute data. [0208] FIG. 3B depicts a data structure 300 according to an embodiment. The data structure, which can be stored in memory 202 of the transaction monitor 101 and/or the database 120 stores context information, and includes context IDs 1-N (e.g., cost center, project, department, client), past behavior data, project ID, cost center ID, meeting ID, conference ID, etc. The proceeding fields are provided for illustrative purposes only and are not meant to limit the fields that may be included in the context.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brock and Sood, because it allows for an improved transaction management service utilizing context-based authorization that can streamline transaction tracking and budget management. (Sood at Abstract and paras. 2-14).
Brock and Sood do not explicitly teach, however, Black teaches:
the set of exchange data comprising the identifier of the container data structure;
(Black WO2000/054200 at pp. 27-28) ("B. Transaction contents For purposes of the posting algorithm, a transaction preferably includes at least the following fields: transaction ID (Txn ID), posted date (DT), effective DT, Txn type, adjustment type, reference transaction, status, rule ID, source currency, destination currency, and amount. The Txn ID is a system- wide unique identifier of the transaction. This id applies to transactions that are stored in the archive and transactions that are stored with each account. The posted DT is the date/time the transaction was posted. The effective DT is the date/time the transaction is effective. For example, a paper-based purchase may be effective days prior to posting. The Txn type is the type of transaction and is one of an extensible table of types. There are both monetary and non-monetary transactions. Any kind of change of state (e.g., new interest rate) is also stored as a transaction. Generated transactions are distinguished from non-generated ones. The adjustment type controls how adjustments to this transaction are to be handled. The code is normally set when the transaction is generated and not later altered. There is a flag that says whether this transaction has been adjusted. The reference transaction is the Txn ID of the transaction to which this transaction is related. Normal use is when this transaction is derived from the reference transaction. A reversal has the ID of what it is reversing, and a reversing transaction has the ID of what reversed it. There is also a flag on a transaction that says whether derived transactions are related to it. For status, a transaction is "new" when just inserted, "posted" when it has been projected successfully, "reversed" when another transaction has reversed it, "statemented" when it has appeared on a statement, or "non-statemented" when it was considered for a statement but rejected. These last two status values may be combined with the previous ones. The rule ID is an identifier of the rule (if any) that caused this transaction to be generated. The source currency type and amount relate to the type and amount of the transaction in the currency in which it took place. The destination currency type and amount relate to the type and amount of the transaction in the currency of this account. A main use of having the rule ID in the transaction is to be able to explain the origin of the transaction. The rule has a multi-lingual explanation field in it, which is used to generate text explaining the transaction for the statement. Sometimes a transaction is generated by the posting algorithm itself; this happens when there is a mix- match between a calculation and a re-calculation (see below), and an adjustment transaction is generated. In order to provide an explanation for such a case, "system" rules exist whose only purpose is to provide the explanation. The "system" rule is not actually executed, but it provides a unique identifier and text. Changes of system state are only recorded as transactions if they are "direct" (not in tables) parameters to the account, whether set explicitly for that account or inherited. The controls that most often change in a system are contained in temporal look-up tables, which provide the same information in a different format.")
identify each segment corresponding to an exchange of the plurality of segments that contains the identifier of the container data structure from the received set of exchange data;
(Black WO2000/054200 at pp. 27-28) ("B. Transaction contents For purposes of the posting algorithm, a transaction preferably includes at least the following fields: transaction ID (Txn ID), posted date (DT), effective DT, Txn type, adjustment type, reference transaction, status, rule ID, source currency, destination currency, and amount. The Txn ID is a system- wide unique identifier of the transaction. This id applies to transactions that are stored in the archive and transactions that are stored with each account. The posted DT is the date/time the transaction was posted. The effective DT is the date/time the transaction is effective. For example, a paper-based purchase may be effective days prior to posting. The Txn type is the type of transaction and is one of an extensible table of types. There are both monetary and non-monetary transactions. Any kind of change of state (e.g., new interest rate) is also stored as a transaction. Generated transactions are distinguished from non-generated ones. The adjustment type controls how adjustments to this transaction are to be handled. The code is normally set when the transaction is generated and not later altered. There is a flag that says whether this transaction has been adjusted. The reference transaction is the Txn ID of the transaction to which this transaction is related. Normal use is when this transaction is derived from the reference transaction. A reversal has the ID of what it is reversing, and a reversing transaction has the ID of what reversed it. There is also a flag on a transaction that says whether derived transactions are related to it. For status, a transaction is "new" when just inserted, "posted" when it has been projected successfully, "reversed" when another transaction has reversed it, "statemented" when it has appeared on a statement, or "non-statemented" when it was considered for a statement but rejected. These last two status values may be combined with the previous ones. The rule ID is an identifier of the rule (if any) that caused this transaction to be generated. The source currency type and amount relate to the type and amount of the transaction in the currency in which it took place. The destination currency type and amount relate to the type and amount of the transaction in the currency of this account. A main use of having the rule ID in the transaction is to be able to explain the origin of the transaction. The rule has a multi-lingual explanation field in it, which is used to generate text explaining the transaction for the statement. Sometimes a transaction is generated by the posting algorithm itself; this happens when there is a mix- match between a calculation and a re-calculation (see below), and an adjustment transaction is generated. In order to provide an explanation for such a case, "system" rules exist whose only purpose is to provide the explanation. The "system" rule is not actually executed, but it provides a unique identifier and text. Changes of system state are only recorded as transactions if they are "direct" (not in tables) parameters to the account, whether set explicitly for that account or inherited. The controls that most often change in a system are contained in temporal look-up tables, which provide the same information in a different format.")
linked to the container data structure by the identifier of the exchange in the segment;
(Black WO2000/054200 at pp. 27-28) ("B. Transaction contents For purposes of the posting algorithm, a transaction preferably includes at least the following fields: transaction ID (Txn ID), posted date (DT), effective DT, Txn type, adjustment type, reference transaction, status, rule ID, source currency, destination currency, and amount. The Txn ID is a system- wide unique identifier of the transaction. This id applies to transactions that are stored in the archive and transactions that are stored with each account. The posted DT is the date/time the transaction was posted. The effective DT is the date/time the transaction is effective. For example, a paper-based purchase may be effective days prior to posting. The Txn type is the type of transaction and is one of an extensible table of types. There are both monetary and non-monetary transactions. Any kind of change of state (e.g., new interest rate) is also stored as a transaction. Generated transactions are distinguished from non-generated ones. The adjustment type controls how adjustments to this transaction are to be handled. The code is normally set when the transaction is generated and not later altered. There is a flag that says whether this transaction has been adjusted. The reference transaction is the Txn ID of the transaction to which this transaction is related. Normal use is when this transaction is derived from the reference transaction. A reversal has the ID of what it is reversing, and a reversing transaction has the ID of what reversed it. There is also a flag on a transaction that says whether derived transactions are related to it. For status, a transaction is "new" when just inserted, "posted" when it has been projected successfully, "reversed" when another transaction has reversed it, "statemented" when it has appeared on a statement, or "non-statemented" when it was considered for a statement but rejected. These last two status values may be combined with the previous ones. The rule ID is an identifier of the rule (if any) that caused this transaction to be generated. The source currency type and amount relate to the type and amount of the transaction in the currency in which it took place. The destination currency type and amount relate to the type and amount of the transaction in the currency of this account. A main use of having the rule ID in the transaction is to be able to explain the origin of the transaction. The rule has a multi-lingual explanation field in it, which is used to generate text explaining the transaction for the statement. Sometimes a transaction is generated by the posting algorithm itself; this happens when there is a mix- match between a calculation and a re-calculation (see below), and an adjustment transaction is generated. In order to provide an explanation for such a case, "system" rules exist whose only purpose is to provide the explanation. The "system" rule is not actually executed, but it provides a unique identifier and text. Changes of system state are only recorded as transactions if they are "direct" (not in tables) parameters to the account, whether set explicitly for that account or inherited. The controls that most often change in a system are contained in temporal look-up tables, which provide the same information in a different format.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brock, Sood, and Black, because it allows for improved systems and methods for providing real-time account information, managing accounts with improved efficiency, managing accounts that can be updated more easily, providing parameter-based approaches to managing accounts. (Black at Abstract and pp. 4-6).
Brock, Sood, and Black do not explicitly teach, however, Huang teaches:
including: an exchange identifier of the exchange of the segment; and a container identifier of a container data structure of the plurality of container data structures linked to the exchange, wherein the container identifier is stored in the segment for the exchange in the parameter adjustment data structure to enable subsequent updates to the exchange without reprocessing unrelated configuration parameters; and
(Huang WO2020119298A1 at pp. 10-11 and 24-25) ("In an embodiment, the above “corresponding events are all used to reduce the value of the state parameter of multiple alternative sub-transactions” may be just adjacent to each other, and no special sorting process is implemented, which makes In some cases, multiple eligible alternative sub-transactions may not be set adjacent to each other, resulting in the inability to use this manual to generate unified certification information. It may also prevent multiple eligible alternative sub-transactions from being arranged completely continuously. Split into multiple groups, then each group can still generate unified certification information separately, but it is impossible to generate a unified certification information for multiple eligible sub-transactions. In an embodiment, when several candidate sub-transactions are selected for aggregation into the set transaction, the manner in which the value of the state parameter is adjusted by the event corresponding to each selected candidate sub-transaction can be identified; When the events corresponding to at least two alternative sub-transactions are used to reduce the value of the state parameter, the at least two alternative sub-transactions may be arranged adjacently in the set transaction. In other words, when aggregated to form a set of transactions, you can actively sort each alternative sub-transaction, and try to arrange the alternative sub-transactions used to reduce the value of the state parameter adjacently, so that these alternative sub-transactions can be Only generating one piece of unified certification information can minimize the quantity of certification information. In an embodiment, when a ciphertext value or a commitment value is used, for multiple alternative sub-transactions that individually exist in the set transaction and the corresponding events are used to reduce the value of the state parameter, the participant may Proof information is separately generated for it to prove that the value of the state parameter after the multiple alternative sub-transactions is in the correct value interval." "Optional, also includes: The third acquiring unit 1005, when the event corresponding to any candidate sub-transaction in the collective transaction is used to increase the value of the state parameter, acquires the candidate sub-transaction corresponding to the optional sub-transaction in the collective transaction Independent certification information of the transaction; The first triggering unit 1006 triggers execution of any alternative sub-transaction when the independent certification information corresponding to the alternative sub-transaction passes verification. Optionally, the candidate sub-transaction corresponding to the event includes unilateral trigger information of the participant on the event; the device further includes: The second triggering unit 1007 triggers the execution of the alternative sub-transaction corresponding to the event when all the parties involved in the event submit the single-party trigger information for the event to the blockchain and the verification is passed. Optional, also includes: The identifying unit 1008 identifies the serial number corresponding to the collective transaction, and the serial number is added in the order in which each collective transaction is generated to sequentially process each collective transaction submitted by the participant according to the corresponding serial number size."
generate, using the set of exchange data and container parameters for the container data structure, parameter adjustment information for each exchange of the plurality of exchanges based on the links between the plurality of exchanges and the container data structure, the parameter adjustment information indicating a first current state of an adjustment to a container parameter of the container data structure corresponding to each exchange;
(Huang WO2020119298A1 at pp. 10-11 and 24-25) ("In an embodiment, when several candidate sub-transactions are selected for aggregation into the set transaction, the manner in which the value of the state parameter is adjusted by the event corresponding to each selected candidate sub-transaction can be identified ; When the events corresponding to at least two alternative sub-transactions are used to reduce the value of the state parameter, the at least two alternative sub-transactions may be arranged adjacently in the set transaction. In other words, when aggregated to form a set of transactions, you can actively sort each alternative sub-transaction, and try to arrange the alternative sub-transactions used to reduce the value of the state parameter adjacently, so that these alternative sub-transactions can be Only generating one piece of unified certification information can minimize the quantity of certification information. In an embodiment, when a ciphertext value or a commitment value is used, for multiple alternative sub-transactions that individually exist in the set transaction and the corresponding events are used to reduce the value of the state parameter, the participant may Proof information is separately generated for it to prove that the value of the state parameter after the multiple alternative sub-transactions is in the correct value interval. In an embodiment, the value of the state parameter corresponding to each participant and the state change amount are respectively a ciphertext value calculated based on a homomorphic encryption algorithm or a promise value calculated based on a homomorphic commitment algorithm. For the homomorphic encryption algorithm, any type of homomorphic encryption algorithm can be used, as long as the homomorphic encryption algorithm can satisfy the addition homomorphism, so that even in the ciphertext state, the value of the state parameter can still be increased or decreased The amount of change in the state; for this homomorphic encryption algorithm is an additive homomorphic encryption algorithm or a fully homomorphic encryption algorithm, this specification does not limit this. For the homomorphic commitment algorithm, when using the Pedersen commitment mechanism in the related art, a random number can be determined for the unencrypted data, and the corresponding commitment value can be calculated based on the random number and the unencrypted data.")
in the segment for each exchange of the plurality of exchanges based on the links between the plurality of exchanges and the container data structure to a second current state of the adjustment to the container parameter; and
(Huang WO2020119298A1 at pp. 10-11 and 24-25) ("In an embodiment, when several candidate sub-transactions are selected for aggregation into the set transaction, the manner in which the value of the state parameter is adjusted by the event corresponding to each selected candidate sub-transaction can be identified ; When the events corresponding to at least two alternative sub-transactions are used to reduce the value of the state parameter, the at least two alternative sub-transactions may be arranged adjacently in the set transaction. In other words, when aggregated to form a set of transactions, you can actively sort each alternative sub-transaction, and try to arrange the alternative sub-transactions used to reduce the value of the state parameter adjacently, so that these alternative sub-transactions can be Only generating one piece of unified certification information can minimize the quantity of certification information. In an embodiment, when a ciphertext value or a commitment value is used, for multiple alternative sub-transactions that individually exist in the set transaction and the corresponding events are used to reduce the value of the state parameter, the participant may Proof information is separately generated for it to prove that the value of the state parameter after the multiple alternative sub-transactions is in the correct value interval. In an embodiment, the value of the state parameter corresponding to each participant and the state change amount are respectively a ciphertext value calculated based on a homomorphic encryption algorithm or a promise value calculated based on a homomorphic commitment algorithm. For the homomorphic encryption algorithm, any type of homomorphic encryption algorithm can be used, as long as the homomorphic encryption algorithm can satisfy the addition homomorphism, so that even in the ciphertext state, the value of the state parameter can still be increased or decreased The amount of change in the state; for this homomorphic encryption algorithm is an additive homomorphic encryption algorithm or a fully homomorphic encryption algorithm, this specification does not limit this. For the homomorphic commitment algorithm, when using the Pedersen commitment mechanism in the related art, a random number can be determined for the unencrypted data, and the corresponding commitment value can be calculated based on the random number and the unencrypted data.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brock, Sood, Black, and Huang, because it allows for processing method and apparatus that helps reduce resource consumption and improve processing efficiency and significantly improves data security. (Huang at Abstract and pp. 4, 9).
Brock, Sood, Black, and Huang do not explicitly teach, however, Grassadonia teaches:
a parameter adjustment data structure to store parameter adjustment information for exchanges corresponding to each of the plurality of container data structures, the parameter adjustment data structure including: a plurality of segments, each segment physically distinct from each other and corresponding to a different exchange of the set of exchanges and
(Grassadonia US20180005229 at paras. 40-44) ("[0042] The system can allow funds in an account to be physically and logically separated using a single account maintained at a bank 116 using database 110 and system of record server 105. Previously, users wanting to maintain separate accounts would have to open separate accounts at one or more banks 116. Embodiments of this disclosure described herein can rely on a single account, but physically and logically separate that account, maintained at system of record server 105, by maintaining a separate record in server 104, using databases 107a-n. For example, one of the databases 107a-n could be configured as a database for storing user profile information. This profile information can include a username, password, account number, routing/transit number, and one or more pointers to sub-accounts and ledgers for the sub-accounts. Each sub-account can have a balance that is an allocated amount less than or equal to the balance of the associated account. However, the total of all of the balances of the sub-accounts can be equal to balance of the account. In one embodiment, the sub-account totals can also differ from the account balance.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brock, Sood, Black, Huang, and Grassadonia, because it allows for improved systems providing physical, logical separation of balances of funds. Various embodiments of this improved system architecture provide several improvements over system architectures; for example, they can allow for more accurate, real-time accounting information by logically separated subaccounts at a server that has increased visibility of financial transactions. (Grassadonia at Abstract and pp. 1-21).
As per claim 2,
Brock explicitly teaches:
wherein the one or more processors update the parameter adjustment data structure to include the first current state of the adjustment to the parameter adjustment information for each exchange of the plurality of exchanges corresponding to the container data structure by: identifying, using the set of exchange data, exchange identifiers for each exchange of the plurality of exchanges corresponding to the container data structure;
(Brock US20210133868 at paras. 21-23) ([0022] "In particular embodiments, the payment service system may receive the request to pull a portion from the line of credit, and automatically send a request to a computing device associated with the financial account (e.g., a smartphone the user has signed into the financial account) for authorization for the pull from the line of credit. The request may be automatically generated for an amount for a transaction. As an example and not by way of limitation, if a user has a limit set for $300, has a balance of $400, and is looking to purchase groceries for $125, a request to pull $25 from a line of credit associated with the user's financial account may be generated." "The modified repayment terms can differ from the default repayment terms associated with the debt instrument (e.g., line o