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 .
Status of the Claims
2. Applicant filed the Request for Continued Examination on 08/06/2026. Claims 1-8 and 10-20 are pending. Claims 1, 10-11, and 16 are amended.
Claim Rejections - 35 USC §101
3. 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.
4. Claims 1-8 and 10-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.
5. 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”.
6. Claim 1 recites “moving assets between accounts”. Specifically, claim recites (abstract ideas emphasized in bold) “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;
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;
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;
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, wherein generating the one or more corresponding sub movement event messages comprises splitting an asset movement of the one or more asset movements into at least two sub movement event messages corresponding to at least two of the one or more legs, at least one of the at least two legs routing assets through an intermediate account defined in the configuration to transform an otherwise impermissible asset movement into permissible asset movements; 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”. 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)).
7. 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” and “transmitting, by the assets interface, at least one of the one or more corresponding sub movement event messages to a liquidity engine” 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.
8. 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)).
9. Hence, claim 1 is not patent eligible.
10. 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)).
11. 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” 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” 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.
12. 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)).
13. Hence, claims 11 and 16 are not patent eligible.
14. The following dependent claims recent additional elements not addressed above:
claims 2, 12, and 17 recite “a feasibility engine”;
claims 5, 15, and 20 recite “an exchange platform”;
claim 6 recites “an API endpoint”; and
claim 8 recites “a data store of the assets interface” and “a hydration system”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the feasibility engine, the exchange platform, the API endpoint, the data store of the assets interface, and the hydration system.
Dependent claims 2-8, 10, 12-15, and 17-20 merely expand upon the abstract ideas of the independent claims, and are therefore rejected under the same rationale as claims 1, 11, and 16 respectively.
Conclusion of 35 USC §101
15. 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.
16. 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
17. 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.
18. 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.
19. 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.
20. Claims 1-8 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20230214832A1 to Hu et al. in view of US20170193512A1 to Sheard et al. and US20090083181A1 to Bishop et al.
21. As per claim 1:
Hu et al. discloses the following limitations:
A method for providing an interface to a plurality of services, the method comprising: ([0024] “…The 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.”, [0111] “…These include a load service 608, an update service 610, and an unload service 612…”)
receiving, by an assets interface of a distributed assets management platform, an event message ([0121] “…In one implementation, a payment smart contract on the blockchain interacts with the main workflow by picking up the payment instruction and performing authentication and authorization…”, [0160] “…the payment transaction is triggered in response to the main workflow (e.g. the digital asset transaction of FIG. 1 ) reaching a particular defined state…”, [0271] “A blockchain as used herein may include a set of cryptographically linked data blocks, stored in a distributed storage medium/platform…”) … the event message having a plurality of data fields corresponding to the asset movement ([0189] “Functionality to verify the transfer request smart contract on the chain which can induce a transfer proposal of funds with the corresponding details like bank accounts, currency and amount involved.”) and a first identifier ([0228] “requestRef: an end to end ID to reference the transaction in the blockchain network and also the core banking system.”)
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 ([0158] “… This single reference is further broken down into three reference numbers for the Load, Update and Unload operations.”, [0147] “…In response, in step 1312 a request is issued to the payer bank 1350 to transfer the specified amount of funds from the payer …”)
generating, by the assets interface, one or more corresponding sub movement event messages for the one or more legs ([0134] “…These operations call the respective microservices in the core banking system via an API…”), wherein the one or more corresponding sub movement event messages are split from the one or more asset movements ([0158] “…This single reference is further broken down into three reference numbers for the Load, Update and Unload operations.”), wherein generating the one or more corresponding sub movement event messages comprises splitting an asset movement of the one or more asset movements into at least two sub movement event messages corresponding to at least two of the one or more legs ([0137] “…in step 1222 a load operation loads the mirror value and transfers the payment amount from the payer to a holding account as depicted in FIG. 12A…”, [0140] “…This causes the mirror value to be moved from the receiver identity on the blockchain to the global mirror account and the payment amount to be transferred from the logical holding account associated with the receiver to the receiver account…”), at least one of the at least two legs routing assets through an intermediate account defined in the configuration ([0119] “The real-money transaction occurs between sender account 1202, receiver account 1206, and an intermediary entity, in the form of bank holding account 1204…The holding account 1204 may include logical sub-accounts for sender (1208) and receiver (1210) for temporarily holding funds during transactions…”) to transform an otherwise impermissible asset movement into permissible asset movements ([0017] “…the third operation is performed only in response to successful completion of the digital asset transfer and the second operation…”, [0119] “…and is typically ring fenced to keep the monies used in the blockchain ecosystem…”, [0141] “…For interbank transfers or transfers via a third-party bank, the operations may vary. For example, where a settlement bank is involved, additional bank transfer steps are involved which may be reflected by additional load/update/unload operations.”, [0137] “…This preparatory step ensures that the funds are available and reserved (in the holding account) to ensure that the transaction can be completed.”)
transmitting, by the assets interface, at least one of the one or more corresponding sub movement event messages to a liquidity engine ([0121] “…It then triggers a call to the load smart contract 408 b (FIG. 4 ) which in turn invokes an API call to the load service 608 at the bank application 516…”, [0134] “…The core banking microservices take instructions from the load, update and unload smart contracts to implement the corresponding real-money movements for each distinct stage of the payment processing transaction…”), 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.
Hu et al. does not disclose, however, Sheard et al., as shown, teaches the following limitations:
[receiving] … associated with an operation requesting an asset movement between accounts of a commerce platform ([0052] “…Some embodiments of the website may support an electronic marketplace…”, [0057] “…to purchase a good from the vendor 116, the buyer 102 may transfer funds from one of the accounts 144 held by the buyer 102 to another of the accounts 144 held by the vendor 116…”, [0063] “… Examples of the financial service entity 123 may include an online money transfer system (e.g., PAYPAL®)…”, [0077] “…The transaction input 209 may be used to indicate conditional execution of the multi-leg transaction including the coupled group 205A…”)
[transmitting]… 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 ([0061] “… In response to authorization of each of the sub-transactions, the financial transaction module 121 may execute or enable execution of the multi-leg transaction…”, [0056] “…The financial server 128 may transfer funds between accounts 144, which may be stored or accessed by the financial server 128.”, [0063] “…Examples of the financial service entity 123 may include an online money transfer system (e.g., PAYPAL®)…”)
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 multi-leg transaction processing of Sheard et al. (‘512, [0001]) with the teaching of Hu et al. for performing transactions involving both blockchain operations and operations at traditional centralized processing systems (‘832, [0001]) for enhancing the method for performing transactions of Hu et al. with features of that requesting transaction input requests for the multi-leg transaction on the electronic marketplace and performing by the financial server (e.g., the liquidity engine) sub-transactions by moving funds between accounts on the payment service platform (e.g., a commerce platform) (‘512, [0052], [0056], [0061], [0077]).
Neither Hu et al. nor Sheard et al. disclose, however, Bishop et al., as shown, teaches the following limitations:
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 ([0128] “The allocation rule may also be, for example, stored on a transaction device, stored on a personal digital assistant, acquired from an employer or third party, generated at the point of sale, associated with a transaction account, stored at the merchant, stored on a server which serves a group of merchants, and/or stored at a payment processor.”, [0139] “…American Express may recognize the primary authorization request as associated with a transaction that involves a charge allocation…”), the configuration defining one or more legs for execution of the asset movement ([0129] “…the system may allocate the charge by charging $500 to the American Express Corporate account, $200 to the Citibank account, $200 to the Bank of America account, $50 to the Visa account, and $50 to the American Express Blue card account…”)
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 multi-leg transaction processing of Sheard et al. (‘512, [0001]) and a method for facilitating of transactions between two accounts of Bishop et al. (‘181, [0002]) with the teaching of Hu et al. for performing transactions involving both blockchain operations and operations at traditional centralized processing systems (‘832, [0001]) for enhancing the method for performing transactions of Hu et al. with features of accessing to the transaction account that identified from the request stored on the transaction device, and setting by the allocation rule performing portions of charge to each account (e.g., legs) (‘181, [0128], [0129], [0139]).
Claims 11 and 16 are rejected using the same rationale that was used for the rejection of claim 1.
22. As per claim 2:
Hu et al. discloses the following limitations:
prior to receiving the event massage: ([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 ([0121] “…a payment smart contract on the blockchain interacts with the main workflow by picking up the payment instruction and performing authentication and authorization…”), and based on one or more blocking conditions ([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.”), whether the asset movement between the accounts is permissible ([0148] “In step 1318 it is determined whether the load request has been successfully completed…”)
in response to determining that the asset movement is not permissible ([0125] “… In the event of failure, the entire transaction may be aborted and the operations carried out so far may be reversed.”), transmitting, by the assets interface, a response message that indicates to a service requesting the operation that the asset movement is not feasible ([0125] “The load operation generates an ACK (acknowledgement) or NAK (non-acknowledgement) to confirm the success or failure of the transaction…”, [0148] “…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 ([0148] “…If the load was successful, the relevant funds are now in the holding account and a corresponding mirror value has been allocated to the sender on the blockchain…”), generating, by the assets interface, a second identifier based on data in at least a subset of the plurality of data fields ([0158] “…To maintain coordination, the system generates a DVP reference which is shared by the digital asset transaction 122 and the real money transaction 114…”), and transmitting, by the assets interface, the response message to the service indicating that the asset movement is permissible ([0171] “Step 3) The payment processor replies to the Load Request with a Load Acceptance as an acknowledgement to the sender…”)
Hu et al. does not disclose, however, Bishop et al., as shown, teaches the following limitations:
receiving, by the assets interface, a feasibility message ([0123] “…establishing a pre-authorization record associated with the selected limited use account identifier, the pre-authorization record including one or more use restrictions based on the transaction information…”)
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 multi-leg transaction processing of Sheard et al. (‘512, [0001]) and a method for facilitating of transactions between two accounts of Bishop et al. (‘181, [0002]) with the teaching of Hu et al. for performing transactions involving both blockchain operations and operations at traditional centralized processing systems (‘832, [0001]) for enhancing the method for performing transactions of Hu et al. with features of establishing pre-authorization request (e.g. a feasibility message) that includes restrictions based on the transaction information (‘181, [0123]).
Neither Hu et al. nor Bishop et al. disclose, however, Sheard et al., as shown, teaches the following limitations:
[receiving] … the feasibility message associated with the operation requesting the asset movement between the accounts of the commerce platform ([0077] “…The transaction input 209 may be used to indicate conditional execution of the multi-leg transaction including the coupled group 205A…”, [0057] “…to purchase a good from the vendor 116, the buyer 102 may transfer funds from one of the accounts 144 held by the buyer 102 to another of the accounts 144 held by the vendor 116…”)
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 multi-leg transaction processing of Sheard et al. (‘512, [0001]) and a method for facilitating of transactions between two accounts of Bishop et al. (‘181, [0002]) with the teaching of Hu et al. for performing transactions involving both blockchain operations and operations at traditional centralized processing systems (‘832, [0001]) for enhancing the method for performing transactions of Hu et al. with features of associating the multi-leg transaction, which moves funds between accounts, with the financial service platform (‘512, [0057], [0077]).
Claims 12 and 17 are rejected using the same rationale that was used for the rejection of claim 2.
23. As per claim 3:
Hu et al. discloses the following limitations:
regenerating, by the assets interface, the second identifier from the plurality of data fields received in the event message ([0170] “Step 2) The sender submits a Load Request with signature of the payment processor to top up the mirror value account.”, [0125] “…The system may additionally calculate control sums between accounts to ensure they are synchronized at the end of each transaction…”)
in response to detecting that the regenerated second identifier matches the second identifier received with the event message ([0158] “…This reference number ensures the matching of digital asset transfer and real money transfer…”), processing, by the assets interface, the event message by performing the accessing, the transforming, the generating, and the transmitting ([0174] “Step 6) The platform operator consolidates the pending movement together with the trading smart contract and the reference of the traded asset to compose the DvP blockchain transaction…”)
Claims 13 and 18 are rejected using the same rationale that was used for the rejection of claim 3.
24. As per claim 4:
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: ([0121] “…It then triggers a call to the load smart contract 408 b (FIG. 4 ) which in turn invokes an API call to the load service 608 at the bank application 516…”)
a source identifier ([0209] “Move(Source=“Alice”, Destination=“Bob”, Amount=2 SGD).”), a destination account identifier ([0209] “Move(Source=“Alice”, Destination=“Bob”, Amount=2 SGD).”) … a source amount to be debited from the source account … ([0123] “The sender's real money account 1202 is also debited and the holding account 1204 is credited in the amount of the transaction value…”)
Neither Hu et al. nor Sheard et al. disclose, however, Bishop et al., as shown, teaches the following limitations:
[a source] … a departed data field indicative of when assets can leave a source account ([0075] “…For example, the transaction information can include a date and time at which the transfer of funds should take place…”), an arrival data field indicative of when assets are available at a destination account … ([0090] “…a datafield 1404 indicating a final date for the acceptable transfer of funds to the seller…”) and an amount to be credited to the destination account ([0094] “…a total amount 1540, net of fees, owed to the seller at the completion of the transaction…”)
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 multi-leg transaction processing of Sheard et al. (‘512, [0001]) and a method for facilitating of transactions between two accounts of Bishop et al. (‘181, [0002]) with the teaching of Hu et al. for performing transactions involving both blockchain operations and operations at traditional centralized processing systems (‘832, [0001]) for enhancing the method for performing transactions of Hu et al. with features of presenting when funds may move out of the source account, a deadline for transfer to the seller is given, and a separate credit amount for the destination (‘181, [0075], [0090], [0091]).
Claims 14 and 19 are rejected using the same rationale that was used for the rejection of claim 4.
25. As per claim 5:
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 ([0147] “…Currency conversion may be performed as needed in step 1317.”, [0149] “…releases the funds to the receiver bank account in step 1340 (performing any necessary currency conversion in step 1342).” )
generating and transmitting, by the assets interface, the sub movement event message to an exchange platform ([0174] “Step 6) The platform operator consolidates the pending movement together with the trading smart contract and the reference of the traded asset to compose the DvP blockchain transaction…”) for which the exchange exposure has occurred ([0147] “…Currency conversion may be performed as needed in step 1317.”)
Claims 15 and 20 are rejected using the same rationale that was used for the rejection of claim 5.
26. As per claim 6:
Hu et al. discloses the following limitations:
receiving, at an API endpoint, the API message ([0024] “…The 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.”), wherein the API message is exposed by the assets interface to a plurality of services ([0110] “The blockchain adapter layer 602 provides node interfaces for communicating with bridge nodes ( e.g. nodes 512, 514 of FIG. 5 ) of respective blockchain frameworks…”)
27. As per claim 7:
Hu et al. discloses the following limitations:
wherein a first data field of the plurality of data fields comprises a placeholder value ([0172] “Step 4) The sender then issues an Update Request with signature of the payment processor to produce a Pending Movement for the DvP process.”), the placeholder value indicating a data value for the first data field is unknown at a time of receipt of the event message ([0175] “…if the Pending Movement cannot be finalized within a certain period, the Pending Movement is consumed by the payment processor in order to surrender the current trade…”)
28. 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 ([0255] “…For example, mirror value updates (e.g. creation of new mirror value tokens) may be recorded immediately in the database 412, but writing to the blockchain may be deferred…”), wherein the processing of the event message is delayed ([0255] “…Mirror value updates are collected until a predetermined criterion for batch processing is met…”)
generating and transmitting, from the assets interface to a hydration system, a registration request associated with the event message ([0105] “…The operations include a load operation 408 b, an update operation 408 c and an unload operation 408 d. These operations interface with corresponding services at the payment processing system (112) to control the different stages of the payment transaction at the payment processing system…”, [0121] “…It then triggers a call to the load smart contract 408 b (FIG. 4 ) which in turn invokes an API call to the load service 608 at the bank application 516…”, [0134] “…The core banking microservices take instructions from the load, update and unload smart contracts to implement the corresponding real-money movements for each distinct stage of the payment processing transaction, and return acknowledgements to confirm whether or not the money transfers were successfully completed.”, [0229] “settlementBankRef: the reference code generated by the core banking system.”), the registration request comprising the first identifier and a third identifier that identifies the first data field ([0101] “…On receipt (step 322) of a transaction enquiry request specific to a client ID (here “Client ID 1”) transaction data is read from transaction database 304 and filtered by client ID (step 320)…”, [0100] “…Processing of a regular account balance enquiry is depicted in step 312 (receipt of balance enquiry request) and step 314 (retrieval of account balance for the account from the account balance database 302)…”)
receiving, from the hydration system, a value for the first data field identified by the third identifier ([0175] “Step 7) The payment processor keeps monitoring the blockchain; once the Movement is finalized on the blockchain, the status of the money in the mirror value account is unlocked…”)
updating, by the assets interface, the first data field, wherein the updated first data field includes the value received from the hydration system ([0174] “…the Pending Movement is consumed to produce the Movement for both sender and receiver.”), and the processing of the event message is resumed, by the assets interface, after updating the first data field ([0175] “…once the Movement is finalized on the blockchain, the status of the money in the mirror value account is unlocked…”)
29. As per claim 10:
Hu et al. discloses the following limitations:
generating, by the assets interface, a first sub movement event message ([0121] “…It then triggers a call to the load smart contract 408 b (FIG. 4 ) which in turn invokes an API call to the load service 608 at the bank application 516), wherein the first sub movement is configured to transfer a first set of assets from a source account to the intermediate account ([0123] “The sender's real money account 1202 is also debited and the holding account 1204 is credited in the amount of the transaction value…”), the source account identified within the plurality of data fields defining the asset movement ([0189] “…a transfer proposal of funds with the corresponding details like bank accounts, currency and amount involved.”)
generating, by the assets interface, a second sub movement event message ([0140] “…this step involves a call to the unload smart contract 408 d which performs the mirror value unload operation and in turn invokes the unload service 612 at the payment processing system to initiate the funds transfer.”), wherein the second sub movement event message is configured to transfer a second set of assets from the intermediate account to a destination account ([0130] “…At the banking system, the transaction value is debited from the receiver subaccount 1210 of the holding account 1204 and credited to the receiver account 1206.”), the destination account identified within the plurality of data fields defining the asset movement ([0189] “…a transfer proposal of funds with the corresponding details like bank accounts, currency and amount involved.”)
Response to Arguments
30. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 1-8 and 10-20 are rejected.
Rejection under 35 USC § 101
31. 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.
32. Applicant is of the opinion that the claims are not directed to an abstract idea. Applicant argues “generating… wherein generating the one or more corresponding sub movement event messages comprises splitting an asset movement of the one or more asset movements into at least two sub movement event messages corresponding to at least two of the one or more legs, at least one of the at least two legs routing assets through an intermediate account defined in the configuration to transform an otherwise impermissible asset movement into permissible asset movements… limitations (underlined) “above are not directed to a generalized concept of moving assets between accounts…”.
Examiner respectfully disagrees.
Claims as a whole are directed to moving assets between accounts which is grouped under “Certain methods of organizing human activity (e.g., commercial or legal interactions)”.
33. Applicant is of the opinion that Step 2A, Prong One analysis is inconsistent with Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016) and McRO, Inc. v. Bandai Namco Games Am. Inc. (Fed. Cir. 2016)
Examiner respectfully disagrees.
Mentioned by Applicant cases: Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016),[1] is related to a patent–eligibility of software patent claims, wherein the claims were directed to a specific improvement to the way computers operate, embodied in the claimed "self-referential table" for a database; and In McRO, Inc. v. Bandai Namco Games Am. Inc. (Fed. Cir. 2016), the court established that automating a manual process is patentable if the claims use specific rules to achieve an improved technological result, wherein automating process by using specific, computer-implemented rules to evaluate phonemes (sounds of speech) and automatically calculate the correct timings and transitions. Therefore, those cases analogy does not apply to the current case.
34. 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 … 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… the one or more corresponding sub movement event messages to a liquidity engine, wherein the liquidity engine … executes one or more asset movements.’”. And argues that this is a technological improvement rooted in computer networks/payment systems, analogous to Enfish, LLC V. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016).
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)).
Examiner reiterates again that Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016),[1] is related to a patent–eligibility of software patent claims, wherein the claims were directed to a specific improvement to the way computers operate, embodied in the claimed “self-referential table” for a database.
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.
35. 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.
Rejection under 35 USC § 103
36. Applicant argues that prior art references Hu et al. in view of Bishop et al. do not teach and suggest amended claims limitations “splitting an asset movement of the one or more asset movements into at least two sub movement event messages corresponding to at least two of the one or more legs, at least one of the at least two legs routing assets through an intermediate account defined in the configuration to transform an otherwise impermissible asset movement into permissible asset movements”.
Applicant arguments are no longer applicable because they are moot in light of the revised rejection.
Conclusion
37. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20230021606A1 – Zhang et al. – Discloses a method and apparatus for managing liquidity when processing transactions, wherein the method is implemented by a computing device and comprises: receiving data for a plurality of transactions; continuously reading in and aggregating, with an aggregator implemented at least partially in hardware of the computing device.
US20140074709A1 – Green et al. – Discloses a transfer management system receives a request to transfer an amount of funds from a transferring account maintained by a transferring bank to a receiving account maintained by a receiving bank, wherein the transfer management system determines whether the transferring bank maintains an intermediate transferring account, and whether the receiving bank maintains an intermediate receiving account.
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.
38. 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
October 6, 2026
