DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
2. The information disclosure statements (IDS) submitted on 09/17/2025 and 10/07/2025. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
3. Applicant filed the amendment on 12/29/2025. Claims 1-20 are pending. Claims 1-6, 8, are 10-20 amended. Claims 1-20 are rejected. After careful consideration of applicant arguments, the examiner finds them to be not persuasive.
Rejection under 35 USC § 101
4. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claims do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
5. Applicant is of the opinion that the claims are not directed to an abstract idea. Applicant argues that the amended limitation [underlined] “generating… wherein the one or more corresponding sub movement event messages are split from the one or more asset movements; and …” “removes the claim from any potential allegation of human activity, as managing complex and high-volume asset movement requests in a distributed commerce platform certainly qualifies as non-human activity.”
Examiner respectfully disagrees.
According to MPEP 2106.04(a)(2) II “The Supreme Court has identified a number of concepts falling within the "certain methods of organizing human activity" grouping as abstract ideas…The term "certain" qualifies the "certain methods of organizing human activity" grouping as a reminder of several important points… this grouping is limited to activity that falls within the enumerated sub-groupings of fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior and relationships or interactions between people, and is not to be expanded beyond these enumerated sub-groupings except in rare circumstances as explained in MPEP § 2106.04(a)(3). Finally, the sub-groupings encompass both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the "certain methods of organizing human activity" grouping. It is noted that the number of people involved in the activity is not dispositive as to whether a claim limitation falls within this grouping. Instead, the determination should be based on whether the activity itself falls within one of the sub-groupings”.
6. Applicant is of the opinion that the amended claim 1 integrate the abstract idea into a practical application and as evidence of the integration recites “generating, by the assets interface, one or more corresponding sub movement event messages for the one or more legs, wherein the one or more corresponding sub movement event messages are split from the one or more asset movements”.
Examiner respectfully disagrees.
Mentioned above the claim features performed by using the computer components. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)).
Therefore, the amended claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to the abstract idea.
7. Applicant is of the opinion that the amended claims amount to “significantly more” than the judicial exception “because the claims recite ‘additional elements’ that are not well-understood, routine, or conventional”.
Examiner respectfully disagrees.
The rejection was not based on conventional elements. To the contrary, the claim is directed to the abstract idea of moving assets between accounts (e.g., (claim 1) “transmitting, … the liquidity engine…executes one or more asset movements between the accounts of the commerce platform.”; (PGPub, para 9) “…An example method of managing data by a distributed assets management platform includes receiving, at an assets interface of the distributed assets management platform, a stream of event messages, wherein each event message of the stream of event messages is associated with at least one asset movement between accounts of a commerce platform”) and does not improve functioning of a computer or computer technology.
The claims are not patent eligible.
Rejections under 35 U.S.C. § 112(a)
8. Rejections of claims 5, 8, 15, and 20 due to amendments are withdrawn.
Rejections under 35 U.S.C. § 112(b)
9. Rejections of claims 2-5, 8, and 10-20 due to amendments claims 2-5, 8, 10-12, 14-17, and 19-20 are withdrawn.
Rejections under 35 U.S.C. § 102
10. Due to Applicant’s argument that the prior art reference Prakash fails to teach limitations of claim 1 and its dependent claims, rejections under 35 USC § 102 are withdrawn and rejections under 35 U.S.C. § 103 are maintained.
Claim Rejections - 35 USC §101
11. 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.
12. 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.
13. In the instant case, claims 1, 11, and 16 are directed to a “method, non-transitory machine readable medium, and system for providing an interface to a plurality of services”.
14. Claim 1 recites “moving assets between accounts”. Specifically, claim recites “receiving … an event message associated with an operation requesting an asset movement between accounts … the event message having a plurality of data fields corresponding to the asset movement and a first identifier; accessing … a configuration for the asset movement based on account identifiers for the accounts as defined in the plurality of data fields, the configuration defining one or more legs for execution of the asset movement; transforming … the event message to one or more asset movements corresponding to the one or more legs defined in the configuration; generating … one or more corresponding sub movement event messages for the one or more legs, wherein the one or more corresponding sub movement event messages are split from the one or more asset movements; and transmitting … at least one of the one or more corresponding sub movement event messages … wherein … in response to receiving the sub movement event message, executes one or more asset movements between the accounts …”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
15. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “an assets interface of a distributed assets management platform”, “a commerce platform”, and “a liquidity engine” do no more than represent the use of a computer as a tool to perform an abstract idea. With respect to “receiving, by an assets interface of a distributed assets management platform, an event message associated with an operation requesting an asset movement between accounts of a commerce platform, the event message having a plurality of data fields corresponding to the asset movement and a first identifier” and “transmitting, by the assets interface, at least one of the one or more corresponding sub movement event messages to a liquidity engine, wherein the liquidity engine, in response to receiving the sub movement event message, executes one or more asset movements between the accounts of the commerce platform” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)). The additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of moving assets between accounts.
16. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of moving assets between accounts using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
17. Hence, claim 1 is not patent eligible.
18. Claims 11 and 16 also recite “moving assets between accounts”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
19. As in the case of claim 1, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of the claims 11 and 16 such as “a non-transitory machine readable medium”, “a processing system”, “a distributed assets management platform”, “an assets interface of a distributed assets management platform”, “a commerce platform”, “a liquidity engine”, “a non-transitory memory”, and “a memory” do no more than represent the use of a computer as a tool to perform an abstract idea. With respect to “receiving, by the processing system and an assets interface of a distributed assets management platform, an event message associated with an operation requesting an asset movement between accounts of a commerce platform, the event message having a plurality of data fields corresponding to the asset movement and a first identifier” and “transmitting, by the processing system and the assets interface, at least one of the one or more corresponding sub movement event messages to a liquidity engine, wherein the liquidity engine, in response to receiving the sub movement event message, executes one or more asset movements between the accounts of the commerce platform” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)). The additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of moving assets between accounts.
20. When analyzed under step 2B (MPEP 2106.04 II), the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describes the concept of moving assets between accounts using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
21. Hence, claims 11 and 16 are not patent eligible.
22. Dependent claim 2 further describes the abstract idea of moving assets between accounts, as recites “prior to receiving the event message: receiving … a feasibility message, the feasibility message associated with the operation requesting the asset movement between the accounts …; determining …and based on one or more blocking conditions, whether the asset movement between the accounts is permissible; in response to determining that the asset movement is not permissible, transmitting … a response message that indicates to a service requesting the operation that the asset movement is not feasible; and in response to determining that the asset movement is permissible, generating … a second identifier based on data in at least a subset of the plurality of data fields, and transmitting … the response message to the service indicating that the asset movement is permissible”. The additional elements such as “the assets interface”, “the commerce platform”, and “a feasibility engine” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 3 further describe the abstract idea of moving assets between accounts, as recites “regenerating … the second identifier from the plurality of data fields received in the event message; in response to detecting that the regenerated second identifier matches the second identifier received with the event message, processing … the event message by performing the accessing, the transforming, the generating, and the transmitting”. The additional element such as “the assets interface” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claims 4, 14, and 19 further describe the abstract idea of moving assets between accounts, as each recites “wherein the plurality of data fields defining the asset movement requested by the event message comprise an application programming interface (API) data fields of an API message, and the plurality of data fields comprise: a source account identifier, a destination account identifier, a departed data field indicative of when assets can leave a source account, an arrival data field indicative of when assets are available at a destination account, a source amount to be debited from the source account, and an amount to be credited to the destination account”.
Dependent claim 5 further describes the abstract idea of moving assets between accounts, as recites “detecting … and for each of the one or more corresponding sub movement event messages, whether an exchange exposure has occurred; and generating and transmitting… the sub movement event message … for which the exchange exposure has occurred”. The additional elements such as “the assets interface” and “an exchange platform” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 6 further describes the abstract idea of moving assets between accounts, as recites “receiving … the API message, wherein the API message is exposed … to a plurality of services”. The additional element such as “an API endpoint” and “the assets interface” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 7 further describes the abstract idea of moving assets between accounts, as recites “wherein a first data field of the plurality of data fields comprises a placeholder value, the placeholder value indicating a data value for the first data field is unknown at a time of receipt of the event message”.
Dependent claim 8 further describes the abstract idea of moving assets between accounts, as recites “storing the event message in … wherein the processing of the event message is delayed; generating and transmitting … a registration request associated with the event message, the registration request comprising the first identifier and a third identifier that identifies the first data field; receiving … a value for the first data field identified by the third identifier; updating … the first data field, wherein the updated first data field includes the value received … and the processing of the event message is resumed … after updating the first data field”. The additional elements such as “a data store of the assets interface”, “the assets interface”, and “a hydration system” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 9 further describes the abstract idea of moving assets between accounts, as recites “wherein generating … the one or more corresponding sub movement event messages for the one or more legs comprises generating at least two sub movement event messages defined in the configuration”. The additional element such as “the assets interface” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 10 further describes the abstract idea of moving assets between accounts, as recites “generating … a first sub movement event message, wherein the first sub movement is configured to transfer of a first set of assets from a source account to an intermediate account, the source account identified within the plurality of data fields defining the asset movement, and the intermediate account identified in the configuration; and generating … a second sub movement event message, wherein the second sub movement event message is configured to transfer of a second set of assets from the intermediate account to a destination account, the destination account identified within the plurality of data fields defining the asset movement”. The additional element such as “the assets interface” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 12 further describes the abstract idea of moving assets between accounts, as recites “prior to receiving the event message: receiving … a feasibility message, the feasibility message associated with the operation requesting the asset movement between the accounts …; determining … and based on one or more blocking conditions, whether the asset movement between the accounts is permissible; in response to determining that the asset movement is not permissible, transmitting a response message that indicates to a service requesting the operation that the asset movement is not feasible; and in response to determining … that the asset movement is permissible, generating a second identifier based on data in at least a subset of the plurality of data fields, and transmitting the response message to the service indicating that the asset movement is permissible”. The additional elements such as “the assets interface”, “the commerce platform”, and “a feasibility engine” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claims 13 and 18 further describe the abstract idea of moving assets between accounts, as each recites “regenerating … the second identifier from the plurality of data fields received in the event message; in response to detecting that the regenerated second identifier matches the second identifier received with the event message, processing … the event message by performing the accessing, the transforming, the generating, and the transmitting”. The additional elements such as “processing system” and “the assets interface” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claims 15 and 20 further describe the abstract idea of moving assets between accounts, as each recites “detecting, for each of the one or more corresponding sub movement event messages, whether an exchange exposure has occurred; and generating and transmitting … the sub movement event message for which the exchange exposure has occurred”. The additional element such as “an exchange platform” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 17 further describes the abstract idea of moving assets between accounts, as recites “prior to receiving the event message: receiving … a feasibility message, the feasibility message associated with the operation requesting the asset movement between the accounts …; determining …and based on one or more blocking conditions, whether the asset movement between the accounts is permissible; in response to determining … that an asset movement is not permissible, transmitting a response message that indicates to a service requesting the operation that the asset movement is not feasible; and in response to determining that an asset movement is permissible, generating a second identifier based on data in at least a subset of the plurality of data fields, and transmitting the response message to the service indicating that the asset movement is permissible”. The additional elements such as “the assets interface”, “the commerce platform”, and “a feasibility engine” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Conclusion
23. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
24. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
25. 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.
26. 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.
27. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
28. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20230214832A1 to Hu et al. in view of US20090083181A1 to Bishop et al. and
29. As per claims 1, 11, and 16:
Hu et al. discloses the following limitations:
receiving, by an assets interface of a distributed assets management platform, an event message associated with an operation requesting an asset movement between accounts of a commerce platform, the event message having a plurality of data fields corresponding to the asset movement and a first identifier ([0007]-[0008] “a plurality of interface operations adapted to be invokable by the main workflow process, wherein each operation is arranged to: communicate via the interface with the payment processing system…”, [0018] “… the workflow process is configured to: execute a call to the load operation to transfer payment funds from a sender account to an intermediate account entity associated with the sender… transaction data to track the movement of funds by transferring a mirror value allocation from the sender identity to the receiver identity…”, [0093] “… Buyer (agent) and seller (agent) interact with the system … to implement the buyer and seller parts of the transaction.”, [0098] “… the client IDs identify sub-accounts which maintain an audit trail of transactions…”, [0121] “…a payment smart contract on the blockchain interacts with the main workflow by picking up the payment instruction…”, [claim 1] “…a blockchain subsystem arranged to interface with the blockchain and to execute a main workflow process including the digital asset transaction; an interface to the payment processing system…”)
accessing, by the assets interface, a configuration for the asset movement based on account identifiers for the accounts as defined in the plurality of data fields, the configuration defining one or more legs for execution of the asset movement ([0015] “…a second operation arranged to: communicate … [0018] “…the workflow process is configured to: execute a call to the load operation … execute one or more calls to the update operation to move payment funds from the intermediate account entity associated with the payment sender to an intermediate account entity associated with the payment receiver, optionally via one or more further intermediate account entities… update mirror transaction data to track the movement of funds by transferring a mirror value allocation from the sender identity to the receiver identity, optionally via one or more intermediary identities… execute a call to the unload operation… [0086]-[0090] “…A variety of transaction flows can be implemented, such as: Direct Buyer to Seller Buyer->Buyer Agent->Seller Agent->Seller Buyer->Buyer Agent->Seller Buyer->Seller Agent->Seller”, [claim 7] “…transfer the mirror value from the sender identity to a further identity in the mirror transaction data, the further identity optionally comprising a receiver identity associated with the payment receiver or an intermediary identity.”, [claim 13] “…the workflow process is configured to: execute a call to the load operation… following the load operation, execute one or more calls to the update operation… execute a call to the unload operation…”)
transforming, by the assets interface, the event message to one or more asset movements corresponding to the one or more legs defined in the configuration ([0018] “… the workflow process is configured to: execute a call to the load operation to transfer payment funds from a sender account to an intermediate account entity … execute one or more calls to the update operation to move payment funds from the intermediate account entity associated with the payment sender to an intermediate account entity associated with the payment receiver, optionally via one or more further intermediate account entities… execute a call to the unload operation to transfer the payment funds…”, (Fig.1, items 114, 122, 124, 128, 130; [0096] “In order to enable integration of the two parts of the transaction into a single coordinated atomic transaction, embodiments of the invention provide for synchronization interactions 128, 130 between transaction 114 and transaction 122 via a mirror value transaction 124…”, [0121 “… a payment smart contract on the blockchain interacts with the main workflow by picking up the payment instruction and performing authentication and authorization. It then triggers a call to the load smart contract…”)
generating, by the assets interface, one or more corresponding sub movement event messages for the one or more legs, wherein the one or more corresponding sub movement event messages are split from the one or more asset movements ([0024] “… each of the first, second and third interface operations are associated with and configured to invoke a respective operation at the payment processing system, the operations at the payment processing system for performing respective stages of the payment transaction…”, [0121] “…It then triggers a call to the load smart contract … which in turn invokes an API call to the load service…”, [0134] “… the load, update and unload operations … call the respective microservices in the core banking system via an API. The core banking microservices take instructions from the load, update and unload smart contracts…”, [claim 4] “…a first operation to: communicate via the interface with the payment processing system … a second operation arranged to: communicate via the interface with the payment processing system … a third operation arranged to: communicate via the interface with the payment processing system…”, [claim 21] “… each of the first, second and third interface operations are associated with and configured to invoke a respective operation at the payment processing system, the operations at the payment processing system for performing respective stages of the payment transaction…”)
Hu et al. does not explicitly disclose, however, Bishop et al., as shown, teaches the following limitations:
transmitting, by the assets interface, at least one of the one or more corresponding sub movement event messages to a liquidity engine, wherein the liquidity engine, in response to receiving the sub movement event message, executes one or more asset movements between the accounts of the commerce platform ([0053] “… the transaction mechanism 202 communicates with at least one of a seller's financial institution 208 … and a purchaser's financial institution 210…”, Fig.6, items 616, 622; [0078] “… the transaction mechanism suitably completes the transaction by debiting the purchaser's financial account, as represented by step 616… [0068] “… and crediting the funds to a seller's financial account (step 622)”, [0139] “…the authorization request is sent to American Express, another secondary authorization request for at least a portion of the amount (e.g., 50%) may also be sent to Visa…”, [0141] “… American Express settles with the merchant, then American Express seeks reimbursement from the other account issuers… the merchant sends multiple settlement requests … to the respective acquirers …”, [0152] “The Financial Transaction Submission Daemon 2118 … submits each transaction's financial transaction record … to a VPOS Acceptance System…”, [claim 1] “… facilitating debiting, by the first financial account issuer … a first portion of the amount from the first financial account…” [executing debit (liquidity decrease)], [0012] “…facilitating crediting …at least a portion of the first amount to the second financial account…” [executing credit (liquidity increase)])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for commercial transactions involving the exchange of monetary value for goods, services, or other value between remote individuals, such as users of a distributed computer network or Internet users of Bishop et al. (‘181, [0010]) with teaching of Hu et al. for performing the digital asset transaction and a given one of the interface operations as a group of sub-operations that are performed in a coordinated fashion only completes successfully if the sub-operations all complete successfully (‘832, [0013]) for transmitting debit and credit requests to financial institutions that manage moving funds (liquidity) between accounts (‘181, [0053],[0068]).
30. As per claims 2, 12, and 17:
Hu et al. discloses the following limitations:
receiving, by the assets interface, a feasibility message, the feasibility message associated with the operation requesting the asset movement between the accounts of the commerce platform ([0093] “…Buyer (agent) and seller (agent) interact with the system via respective buyer/ seller systems … to implement the buyer and seller parts of the transaction”, [0121] “…payment smart contract … interacts with the main workflow by picking up the payment instruction and performing authentication and authorization …”, [0137] “…Prior to step 1220, various preparatory steps may have been carried out by the main workflow, such as user authentication, verifying ownership of the digital asset etc.…”)
determining, by a feasibility engine, based on one or more blocking conditions, whether the asset movement between the accounts is permissible ([0178]-[0179] “… the transaction steps for a transaction in which an asset “asset1” is traded from seller A to buyer B: 1. Ensure asset1 belongs to A and is ready to be traded…”)
in response to determining that the asset movement is not permissible, transmitting, by the assets interface, a response message that indicates to a service requesting the operation that the asset movement is not feasible (Fig.13, items 1318, 1320; [0148] “In step 1318 it is determined whether the load request has been successfully completed. If not, an error message or report is generated in step 1320 and transmitted to relevant parties, e.g. the buyer (agent) and/or seller (agent) systems…)
in response to determining that the asset movement is permissible, generating, by the assets interface, a second identifier based on data in at least a subset of the plurality of data fields, and transmitting, by the assets interface, the response message to the service indicating that the asset movement is permissible ([0125] “The load operation generates an ACK (acknowledgement) or NAK (non-acknowledgement) to confirm the success or failure of the transaction.…”, [0128] “The operations issues an ACK/NAK response indicating success … and control sums may be calculated after completion of both sub-operations…”, [0171] “… After the Load Acceptance is issued, the mirror value top up process is completed…”, [0246] “…The core banking system is responsible for verifying that Alice has a sufficient balance in her bank account and validates that no double spending has occurred”)
31. As per claims 3, 13, and 18:
Hu et al. does not explicitly disclose, however, Bishop et al., as shown, teaches the following limitations:
regenerating, by the assets interface, the second identifier from the plurality of data fields received in the event message ([0104] “…Each issuer's transaction account numbers comply with that company's standardized format such that the company using a fifteen-digit format will generally use three-spaced sets of numbers, as represented by the number “0000 000000 00000”. The first five to seven digits are reserved for processing purposes and identify the issuing bank, card type, etc. In this example, the last (fifteenth) digit is used as a sum check for the fifteen digit number… A merchant account code or an account number for any party discussed herein may be, for example, any number or alpha-numeric characters that identify a particular merchant…”
in response to detecting that the regenerated second identifier matches the second identifier received with the event message, processing, by the assets interface, the event message by performing the accessing, the transforming, the generating, and the transmitting ([0076] “… represented by step 612, the transaction mechanism may suitably determine whether the transaction is acceptable… the risk management module of the transaction mechanism … perform a fraud analysis … to determine whether the current transaction… is indicative of fraud… to determine whether the purchaser is actually the proper cardholder…”, [0077] “… a comparison of the user identifiers of either/both the purchaser and the seller with the user identifiers … to determine whether the transaction is acceptable… the transaction mechanism may suitably analyze whether the transaction is acceptable based upon additional criteria…”, [0114] “…generating a secondary transaction number and issuing this number to the cardholder, where the cardholder presents this number to another party or intermediary (e.g., to complete a transaction); the transaction mechanism processes this secondary transaction number, similar to any other credit card number, where the number is typically presented to the credit card provider for authorization…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for commercial transactions involving the exchange of monetary value for goods, services, or other value between remote individuals, such as users of a distributed computer network or Internet users of Bishop et al. (‘181, [0010]) with teaching of Hu et al. for performing the digital asset transaction and a given one of the interface operations as a group of sub-operations that are performed in a coordinated fashion only completes successfully if the sub-operations all complete successfully (‘832, [0013]) for validating of account numbers, transaction processing, account number formats/structures, and whether the transaction is acceptable or not based on fraud analysis (‘181, [0077],[0114]).
32. As per claims 4, 14, and 19:
Hu et al. discloses the following limitations:
wherein the plurality of data fields defining the asset movement requested by the event message comprise an application programming interface (API) data fields of an API message, and the plurality of data fields comprise: a source account identifier, a destination account identifier, a departed data field indicative of when assets can leave a source account, an arrival data field indicative of when assets are available at a destination account, a source amount to be debited from the source account, and an amount to be credited to the destination account ([0018] “… transfer payment funds from a sender account to an intermediate account entity … to move payment funds from the intermediate account entity … to an intermediate account entity associated with the payment receiver…”, [0024] “… operations at the payment processing system … invoked via an application programming interface (API) of the payment processing system”, [0098] “…client IDs identify sub-accounts …”, [0121] “…triggers a call to the load smart contract which in turn invokes an API call to the load service…”, [0122]-[0123] “… mirror value operation… debits the transaction value from the global mirror account 1216 and credits that same transaction value to the sender mirror account 1212. The sender's real money account 1202 is also debited and the holding account 1204 is credited…”, [0134] “…the load, update and unload operations … call the respective microservices in the core banking system via an API…”, [claim 21] “… operations at the payment processing system are preferably implemented as a set of services running at the payment processing system that are invoked via an application programming interface (API) of the payment processing system”)
33. As per claims 5, 15, and 20:
Hu et al. discloses the following limitations:
detecting, by the assets interface and for each of the one or more corresponding sub movement event messages, whether an exchange exposure has occurred (Fig.13, items 1314, 1316, 1317; [0147] “… in step 1312 a request … to transfer the specified amount of funds from the payer… a load operation 1314 to load a mirror value corresponding to the transaction value … and obtain the corresponding quantity of real funds from the payer's account in step 1316… Currency conversion may be performed as needed in step 1317”).
generating and transmitting, by the assets interface, the sub movement event message to an exchange platform for which the exchange exposure has occurred (Fig.13, items 1338, 1340, 1342; [0149] “…The payee bank then performs an unload operation 1338 to unload the mirror value… releases the funds to the receiver bank account in step 1340 (performing any necessary currency conversion in step 1342).”, [0224] “instructed MVCurrency: the currency of the transferred money (e.g. USD, SGD, HKD)”)
34. As per claim 6:
Hu et al. discloses the following limitations:
receiving, at an API endpoint, the API message, wherein the API message is exposed by the assets interface to a plurality of services ([0024] “…a set of services running at the payment processing system that are invoked via an application programming interface (API) of the payment processing system”, [0102] “… an application interface 404 for communicating with components and applications of the core banking system…”, [0111] “The microservices layer 606 includes … a load service 608, an update service 610, and an unload service 612…”)
35. As per claim 7:
Hu et al. does not explicitly disclose, however, Bishop et al., as shown, teaches the following limitations:
wherein a first data field of the plurality of data fields comprises a placeholder value, the placeholder value indicating a data value for the first data field is unknown at a time of receipt of the event message ([0126] “The allocation may be based upon one or more of …a dynamic allocation rule (e.g., which changes based upon any of the other factors) …”, [0135] “The allocation may be implemented using a pre-defined rule; selecting or entering a rule via a webpage, online or otherwise submitting a request…”, [0137] “The system may also suggest an allocation. The system may suggest the allocation prior to, during or after a transaction…”, [0138] “… if the manager does not reply within a certain time period, then the system may allocate the charge based upon a “no reply” allocation rule.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for commercial transactions involving the exchange of monetary value for goods, services, or other value between remote individuals, such as users of a distributed computer network or Internet users of Bishop et al. (‘181, [0010]) with teaching of Hu et al. for performing the digital asset transaction and a given one of the interface operations as a group of sub-operations that are performed in a coordinated fashion only completes successfully if the sub-operations all complete successfully (‘832, [0013]) for indicating determined data and that acquired after initial transaction request (‘181, [0135], [0138]).
36. As per claim 8:
Hu et al. does not explicitly disclose, however, Bishop et al., as shown, teaches the following limitations:
storing the event message in a data store of the assets interface, wherein the processing of the event message is delayed ([0067] “…the storage device 522 and, therefore, customer transaction records 524 and customer information records 526 may be co-located…”, [0078] “…the transaction mechanism then transfers the funds to a suitable escrow account and holds the funds in the escrow account until a suitable escrow release event has transpired…”, [0137] “…The system may suggest the allocation prior to, during or after a transaction…”, [0138] “… if the manager does not reply within a certain time period, then the system may allocate the charge based upon a “no reply” allocation rule.”)
generating and transmitting, from the assets interface to a hydration system, a registration request associated with the event message, the registration request comprising the first identifier and a third identifier that identifies the first data field ([0083] “…the transaction mechanism receives information indicating that the escrow release event has transpired…”, [0138] “… generate a notification to the manager (e.g., Blackberry device)… current charge request.…”, [0148] “The Express Net Interface Manager 2110 communicates with the Express Net … acquires any suitable user data which may be desired to process a particular pending transaction. Preferably, the Express Net Interface Manager 2110 acquires a list of the Internet user's registered cards and/or DDAs…”, [claim 1] “… acquiring an allocation rule associated with the first identifier…”)
receiving, from the hydration system, a value for the first data field identified by the third identifier ([0080] “…the transaction mechanism may receive an indication that a transaction between a purchaser and a seller has been initiated…”, [0138] “… The manager can then analyze how much the employee already spent … then the manager can indicate an allocation of the charge among the employee's personal and business charge accounts…”, [0148] “…Express Net Interface Manager 2110 acquires a list of the Internet user's registered cards and/or DDAs as well as other unique data pertaining to the Internet user…”, [claim 11] “…receiving the allocation rule from a consumer associated with the first financial account”)
updating, by the assets interface, the first data field, wherein the updated first data field includes the value received from the hydration system, and the processing of the event message is resumed, by the assets interface, after updating the first data field ([0083] “…the funds are then released from the escrow account and disbursed to the seller's financial account…”, [0138] “… the manager can indicate an allocation of the charge…if the manager does not reply within a certain time period, then the system may allocate the charge based upon a “no reply” allocation rule.”, [0144] “The Transaction Manager 2106 performs a variety of processes which facilitate a transaction … creating transaction invoices and managing them, including updating a particular transaction invoice at the various stages of the transaction process…”, [claim 1] “…transforming an allocation instruction based on the allocation rule…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for commercial transactions involving the exchange of monetary value for goods, services, or other value between remote individuals, such as users of a distributed computer network or Internet users of Bishop et al. (‘181, [0010]) with teaching of Hu et al. for performing the digital asset transaction and a given one of the interface operations as a group of sub-operations that are performed in a coordinated fashion only completes successfully if the sub-operations all complete successfully (‘832, [0013]) for storing transaction information and conditional/delayed processing, requesting information from external systems to complete transaction data, receiving values and data from external systems to populate transaction fields, and updating transaction data with received values and continuing processing (‘181, [0067], [0080], [0138], [0144], [0148]).
37. As per claim 9:
Hu et al. discloses the following limitations:
wherein generating, by the assets interface, the one or more corresponding sub movement event messages for the one or more legs comprises generating at least two sub movement event messages defined in the configuration ([0158] “…This single reference is further broken down into three reference numbers for the Load, Update and Unload operations”, [0160] “…coordinated transaction involves as a first step the initial load operation (FIG. 12A)… then occurs as an atomic operation together with the update operation (FIG. 12B)… funds are released to the payee via the unload operation (FIG. 12C)…”, [0142] “… sequence 1248 of load, update and unload operations includes two update operations in this example…”)
38. As per claim 10:
Hu et al. discloses the following limitations:
generating, by the assets interface, a first sub movement event message, wherein the first sub movement is configured to transfer of a first set of assets from a source account to an intermediate account, the source account identified within the plurality of data fields defining the asset movement, and the intermediate account identified in the configuration (Fig.12E, items 1202, 1240, 1242, 1244, 1206; [0098] “…Physical accounts represent conventional accounts, with each physical account potentially holding data and transactions for multiple logical accounts associated with different clients, each logical account associated with a client identifier…Account 1 contains logical sub-accounts for clients with identifiers Client-ID-1 through Client-ID-Q…”, [0099] “… Account balances and transactions for physical accounts are stored using a general ledger account balance database and a transaction database…”, [0137] “…a load operation … transfers the payment amount from the payer to a holding account…”, [0140] “… causes … the payment amount to be transferred from the logical holding account associated with the receiver to the receiver account…”)
generating, by the assets interface, a second sub movement event message, wherein the second sub movement event message is configured to transfer of a second set of assets from the intermediate account to a destination account, the destination account identified within the plurality of data fields defining the asset movement ((Fig.12E, items 1216, 1212, 1246, 1214, 1216; [0138] “…transfers the payment amount from the logical holding account 1208 associated with the sender to the logical holding account 1210 associated with the receiver…”, [0142] “… payment intermediary 1242 is reflected by a corresponding mirror identity/account 1246. The sequence 1248 of load, update and unload operations includes two update operations in this example to mirror the real-world money movement… real money transfer may occur via a holding account 1240 at a first bank, the intermediary entity 1242, and a holding account 1244 at a second bank…”)
Conclusion
39. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20180330342A1 – Prakash et al. – Discloses systems and methods related to cryptocurrency system that enables transactions to be performed using digital assets corresponding to an amount of fiat currency.
US20180068389A1 – Pessin – Discloses a method conducting financial transactions over a computerized network, where a plurality of client computers and servers, which are connected to one another, over a network.
US20070100748A1 – Dheer et al. – Discloses a system for providing an integrated financial system to facilitate the transfer of funds among accounts held at different financial institutions and over different networks.
40. 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.
41. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/ Supervisory Patent Examiner, Art Unit 3692