Prosecution Insights
Last updated: April 19, 2026
Application No. 16/684,546

SYSTEM AND METHOD FOR CROSS-BORDER BLOCKCHAIN PLATFORM

Final Rejection §101§103
Filed
Nov 14, 2019
Examiner
ALI, JAHED
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Royal Bank Of Canada
OA Round
6 (Final)
60%
Grant Probability
Moderate
7-8
OA Rounds
3y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 60% of resolved cases
60%
Career Allow Rate
85 granted / 141 resolved
+8.3% vs TC avg
Strong +60% interview lift
Without
With
+59.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
29 currently pending
Career history
170
Total Applications
across all art units

Statute-Specific Performance

§101
30.2%
-9.8% vs TC avg
§103
37.1%
-2.9% vs TC avg
§102
5.0%
-35.0% vs TC avg
§112
20.1%
-19.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 141 resolved cases

Office Action

§101 §103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Status of Claims This office action is in response to the claim amendments filed on September 08, 2025. Claims 1-23 are pending. Claims 1-23 have been examined. Response to Arguments With respect to Claim Rejections - 35 USC § 101 Applicant argues, see Applicant’s Arguments pages (10-11). The Examiner, however, respectfully disagrees. As a preliminary matter, the Examiner follows the 2019 Patent Eligibility Guidance (“2019 PEG”) which is a synthesis of the case law of Alice and its progeny. Additionally, the reasoning for this rejection is the same as was laid out in the Non-Final Rejection Office Action, dated 03/07/2025 (hereinafter, “Office Action”). Furthermore, while Applicant has amended the claim to recite additional subject matter, for example, the amended claim limitation recites, “invoking a chaincode to monitor a data processing state of the data process, the monitoring including updating the data processing state of the electronic transfer when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger”, further describe the abstract idea of receiving a data set, generating entries for storing the data set, generating signals to propagation of the entries; communicating data messages, updating a data processing state and generating more event entries and categorized as a part of organizing human activity. Applicant further argues that, [n]ot withstanding the above, the Applicant notes that the claims as a whole integrate any purported judicial exception into a practical application. Rather than a simple process of a purported commercial interaction as suggested by the Office Action, representative claim 1 involves the invocation of a chaincode to monitor a data processing state of a data process which can include a series of point-to-point electronic events between a series of computer systems. Applicant’s Arguments pages at p. 11. The Examiner however, respectfully disagrees, the claims also fail to recite a practical application of the abstract ideas. According to the 2019 PEG, the additional claim elements are considered when determining whether the claim recites a practical application, such as a technological improvement, of the abstract idea. The amendments introduced additional element of chaincode, also fails to recite a practical application. The chaincode merely use(s) a computer as a tool to perform an abstract idea. 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. Therefore, this analysis is the same as the Office Action. The claims also fail to recite significantly more than the abstract idea. According to the 2019 PEG, the additional elements, when considered individually and as a combination, are analyzed to determine whether the claims recite significantly more than the abstract idea. The additional element(s) of using a chaincode to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, this analysis is the same as the Office Action. Accordingly, this ground of rejection is maintained. With respect to Claim Rejections - 35 USC § 103 Applicant’s arguments with respect to claims 1-23 have been considered but are moot in view of new grounds of rejection initiated by applicant’s amendment to the claims. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. In the instant case, claims 1-11 are directed to a system comprising a memory device, and at least one processor, claims 12-22 are directed to a method, and claims 23 is directed to a non-transitory computer-readable storage medium. Therefore, these claims fall within the four statutory categories of invention. (Step 1: YES). The claims recite an abstract idea of receiving a data set, generating entries for storing the data set, generating signals to propagation of the entries; communicating data messages, updating a data processing state and generating more event entries. Specifically, the claims recite: “receiving an originating data set including parameters for a data process executed over a network between a first centralized ledger system and a second centralized ledger system, the data process for an electronic transfer from an originator account on the first centralized ledger system and associated with a first entity, to a beneficiary account on the second centralized ledger system and associated with a second entity; generating one or more first entries for storing the originating data set on a distributed ledger of the monitoring system and generating signals to initiate propagation of the one or more first entries to the plurality of nodes; communicating data messages between the first centralized ledger system and an intermediary centralized ledger system to execute a first hop of the data process, wherein the first hop is a first of in a series of intermediate point-to-point centralized ledger transactions between the first centralized ledger system, and the second centralized ledger system; and upon receipt of one or more event messages associated with the data process being executed via the intermediary centralized ledger system, generating one or more event entries for storing in association with the one or more first entries on the distributed ledger of the monitoring system and propagating the one or more event entries to the plurality of nodes; and invoking a chaincode to monitor a data processing state of the data process, the monitoring including updating the data processing state of the electronic transfer when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger, the pair of event entries comprising, a transmission event entry including information from an event message received from one of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a first point in the particular hop of the data process in the series of intermediate centralized ledger point-to-point transactions, and a corresponding receipt event entry including information from an event message received from another of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a corresponding second point in the particular hop”, which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106.04(a)) because it describes a process for carrying out a commercial interaction between parties that involves communicating data needed to complete a transaction to the parties. Additionally, the memory device, and at least one processor do not necessarily restrict the claim from reciting an abstract idea. Accordingly, the claims recite an abstract idea (See MPEP 2106.04). (Step 2A-Prong 1: YES). This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(a or d)), the additional element(s) of the claim(s) such as a memory device, and at least one processor merely use(s) a computer as a tool to perform an abstract idea. Specifically, the memory device, and at least one processor perform(s) the steps or functions of: “receiving an originating data set including parameters for a data process executed over a network between a first centralized ledger system and a second centralized ledger system, the data process for an electronic transfer from an originator account on the first centralized ledger system and associated with a first entity, to a beneficiary account on the second centralized ledger system and associated with a second entity; generating one or more first entries for storing the originating data set on a distributed ledger of the monitoring system and generating signals to initiate propagation of the one or more first entries to the plurality of nodes; communicating data messages between the first centralized ledger system and an intermediary centralized ledger system to execute a first hop of the data process, wherein the first hop is a first of in a series of intermediate point-to-point centralized ledger transactions between the first centralized ledger system, and the second centralized ledger system; and upon receipt of one or more event messages associated with the data process being executed via the intermediary centralized ledger system, generating one or more event entries for storing in association with the one or more first entries on the distributed ledger of the monitoring system and propagating the one or more event entries to the plurality of nodes; and invoking a chaincode to monitor a data processing state of the data process, the monitoring including updating the data processing state of the electronic transfer when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger, the pair of event entries comprising, a transmission event entry including information from an event message received from one of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a first point in the particular hop of the data process in the series of intermediate centralized ledger point-to-point transactions, and a corresponding receipt event entry including information from an event message received from another of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a corresponding second point in the particular hop”. 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 (See MPEP 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (See MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (See MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the 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 an abstract idea. Thus, claim 1 does not integrate the abstract idea into a practical application. (Step 2A-Prong 2: NO). The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional element(s) of using a memory device, and at least one processor to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of receiving a data set, generating entries for storing the data set, generating signals to propagation of the entries; communicating data messages, updating a data processing state and generating more event entries. As discussed above, taking the claim elements separately, the memory device, and at least one processor perform(s) the steps or functions of: “receiving an originating data set including parameters for a data process executed over a network between a first centralized ledger system and a second centralized ledger system, the data process for an electronic transfer from an originator account on the first centralized ledger system and associated with a first entity, to a beneficiary account on the second centralized ledger system and associated with a second entity; generating one or more first entries for storing the originating data set on a distributed ledger of the monitoring system and generating signals to initiate propagation of the one or more first entries to the plurality of nodes; communicating data messages between the first centralized ledger system and an intermediary centralized ledger system to execute a first hop of the data process, wherein the first hop is a first of in a series of intermediate point-to-point centralized ledger transactions between the first centralized ledger system, and the second centralized ledger system; and upon receipt of one or more event messages associated with the data process being executed via the intermediary centralized ledger system, generating one or more event entries for storing in association with the one or more first entries on the distributed ledger of the monitoring system and propagating the one or more event entries to the plurality of nodes; and invoking a chaincode to monitor a data processing state of the data process, the monitoring including updating the data processing state of the electronic transfer when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger, the pair of event entries comprising, a transmission event entry including information from an event message received from one of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a first point in the particular hop of the data process in the series of intermediate centralized ledger point-to-point transactions, and a corresponding receipt event entry including information from an event message received from another of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a corresponding second point in the particular hop.” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of receiving a data set, generating entries for storing the data set, generating signals to propagation of the entries; communicating data messages, updating a data processing state and generating more event entries. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible. (Step 2B: NO). Regarding dependent claims Claims 2 and 13 recite: identifying event message associated with the one or more first entries based on at least one key field in the corresponding event entry and at least one key field in the one or more first entries. Claims 3 and 14 recite: generating an orphan event entry for storing in an orphan list on the distributed ledger when at least one key field in the associated one or more event messages do not correspond to any first entries stored on the distributed ledger. Claims 4 and 15 recite: generating an orphan event entry for storing one or more orphan event entries in an orphan list on the distributed ledger when the one or more event messages are inconsistent with a state of the corresponding data process for the electronic transfer; wherein the state of the corresponding data process for the electronic transfer is based on the one or more first entries and any associated event messages on the distributed ledger. Claims 5 and 16 recite: upon generating one or more additional event entries for storing in association with the one or more first entries on the distributed ledger, storing one or more orphan event entries from the orphan list in association with the one or more first entries when the one or more orphan event entries are consistent with the state of the corresponding data process based on the one or more additional event entries. Claims 6 and 17 recite: upon determining that at least one key field in the one or more event messages or in a new originating data set are indicative of a duplicate event, generating signals for processing the one or more event messages or in a new originating data set without storing corresponding data in the distributed ledger. Claims 7 and 18 recite: cryptographically signing the originating data set with a first certificate associated with the originator account, the first certificate stored in a keystore of the first entity; submitting the signed originating data set to one or more peer endorsers associated with the first entity; and upon receipt of an endorsement response including a cryptographic signature generated with a private key of the one or more peer endorsers, generating the one or more first entries including the endorsement response. Claims 8 and 19 recite: when the originating data set is received, generating signals for storing a credit entry for a mirror originator-intermediary account, the mirror originator account mirroring an originator account managed by the intermediary centralized ledger system; and generating signals for storing a debit entry for the mirror originator-intermediary account based on the signals to initiate the data process for execution via the intermediary centralized ledger system. Claims 9 and 20 recite: wherein when the intermediary centralized ledger_system generates signals for execution of the data process via a third centralized ledger system associated with a third entity; the at least one processor of one or more of the plurality of nodes is configured for generating one or more event entries based on event messages associated with the data process being executed via the third centralized ledger system. Claims 10 and 21 recite: upon receipt of a request for data regarding at least one data process for an electronic transfer from a requesting device, invoking a smart contract to access one or more entries on the distributed ledger based on a cryptographic key associated with a requestor associated with the requesting device; and generating signals for communicating data based on the accessible one or more entries. Claims 11 and 22 recite: responsive to a determination that the one or more transaction events has occurred, trigger an alert or sending control signals to modify an amount of reserve funds held for maintaining liquidity to account for foreign exchange fluctuations. Dependent claims 2-11 and 13-22 further describe the abstract idea of receiving a data set, generating entries for storing the data set, generating signals to propagation of the entries; communicating data messages, updating a data processing state and generating more event entries. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible. Claim Rejections - 35 USC § 103 This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 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. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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. Claims 1, 2, 7-12, 13 and 18-23 are rejected under 35 U.S.C. 103 as being unpatentable over Jayaram et al. (US 20180322485 A1, “Jayaram”), in view of Jacobs et al. (US 20200099518 A1, “Jacobs”), in view of Kim et al. (US 20190080284 A1, “Kim”), and alternatively, further in view of CHIDAMBARAM et al. (US 20200099531 A1, “CHIDAMBARAM”). Regarding claims 1, 12 and 23: Jayaram discloses: A monitoring system for monitoring a series of point-to-point centralized ledger electronic transactions between a series of centralized ledger systems, the monitoring system managing data processing states utilizing distributed ledgers on a plurality of nodes, the system comprising (see paragraphs [0028]-[0030], [0040]-[0041] and [0161]-[0163] and Figs. 1, 2 and 14): a memory device for storing distributed ledger data (see paragraphs [0028]-[0030], [0040]-[0041] and [0161]-[0163] and Figs. 1, 2 and 14), and at least one processor of one or more of the plurality of nodes configured for (see paragraphs [0028]-[0030], [0040]-[0041] and [0161]-[0163] and Figs. 1, 2 and 14): receiving an originating data set including parameters for a data process executed over a network between a first centralized ledger system and a second centralized ledger system, the data process for an electronic transfer from an originator account on the first centralized ledger system and associated with a first entity, to a beneficiary account on the second centralized ledger system and associated with a second entity (Jayaram [0050]: a financial management system receives 402 a request to transfer funds from an account at Bank A to an account at Bank B. The request may be received by Bank A, Bank B, or another financial institution, system, device, and the like. Using the example of FIG. 3, financial management system 302 receives a request to transfer funds from account 312 at bank 304 to account 320 at bank 306), (see Figs. 3 and 4); Examiner’s Note: with respect to “a data process executed over a network between a first centralized ledger system and a second centralized ledger system”. This limitation does not limit the functionality of the claimed monitoring system comprising a memory device, and at least one processor because this limitation is outside the scope of the claimed monitoring system. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed monitoring system. Therefore, this limitation has limited patentable weight since step of the data process executed over a network between a first centralized ledger system and a second centralized ledger system is not positively tied with any structure element of the claimed monitoring system. And with respect to the method claim 12, this limitation is not positively recited functional step and hence receive limited patentable weight. generating one or more first entries for storing the originating data set on a distributed ledger of the monitoring system and generating signals to initiate propagation of the one or more first entries to the plurality of nodes (Jayaram [0050]: Financial management system 102 also includes a ledger manager 212 that manages a ledger (e.g., ledger 118 in FIG. 1; ) as discussed herein; A blockchain module 216 provides interoperability with blockchains for settlement of assets on a blockchain; [0138]: configuration 1000 of multiple nodes and a distributed transaction store. As shown in FIG. 10, two nodes 1002 and 1004 are coupled to a distributed transaction store 1006. Nodes 1002 and 1004 may represent organizations, companies, participants, regulators, individuals, and the like; [0149]: the adaptor is listening for updates happening in the underlying system and the same gets propagated into the financial management ecosystem discussed herein. In the latter case, the adaptor pulls the necessary details and pushes them into the node.), (see Figs. 2, 10 and 11); communicating data messages between the first centralized ledger system and generating signals that initiate the data process for execution via an intermediary centralized ledger system to execute a first hop of the data process, wherein the first hop is a first of in a series of intermediate point-to-point centralized ledger transactions between the first centralized ledger system, the intermediary system, and the second centralized ledger system (Jayaram [0046]: financial management system 302 is in communication with a first bank 304 and a second bank 306. In this example, funds are being transferred from an account at bank 304 to an account at bank 306, as indicated by broken line 308. Bank 304 maintains a ledger 310 that identifies all transactions and data associated with transactions that involve bank 304. Similarly, bank 306 maintains a ledger 318 that identifies all transactions and data associated with transactions that involve bank 306), (see paragraph [0134] and Figs. 3 and 4). Examiner’s Note: with respect to “initiate the data process for execution via an intermediary centralized ledger system to execute a first hop of the data process”. This limitation does not limit the functionality of the claimed monitoring system comprising a memory device, and at least one processor because this limitation is outside the scope of the claimed monitoring system. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed monitoring system. Therefore, this limitation has limited patentable weight since step of “execute a first hop of the data process” is not positively tied with any structure element of the claimed monitoring system. And with respect to the method claim 12, this limitation is not positively recited functional step and hence receive limited patentable weight. upon receipt of one or more event messages associated with the data process being executed via the intermediary centralized ledger system, generating one or more event entries for storing in association with the one or more first entries on the distributed ledger of the monitoring system and propagating the one or more event entries to the plurality of nodes (Jayaram [0149]: the adaptor is listening for updates happening in the underlying system and the same gets propagated into the financial management ecosystem discussed herein), (see paragraphs [0154] and [0156]); and […] As indicated above, Jayaram discloses updating transaction data and propagation of the one or more event entries to the plurality of nodes. However, for compact persecution and clarity purpose, the Examiner cites Jacobs to specifically disclose: upon receipt of one or more event messages associated with the data process being executed via the [intermediary ledger system], generating one or more event entries for storing in association with the one or more first entries on the distributed ledger of the monitoring system and propagating the one or more event entries to the plurality of nodes (Jacobs [0171]: At step S516, the administrative node computer 550 may provide the digital asset and second digital signature back to the issuer node computer 565. The issuer node computer 565 may thus be informed that the digital asset is validated and ready for use; [0119]: the update ledger module 165K may contain logic that causes the processor 165A to record information by updating a ledger of transactions based on a new digital asset or other transaction. Such a ledger may be stored at the ledger database 165C. The update ledger module 165K may include instructions for adding a block to a blockchain, the new block including information about one or more transactions; [0027]: transferred digital asset may be announced to one or more nodes in the network, and the one or more nodes each maintain add information about new digital assets to their own ledger. Then, the different nodes can compare their ledgers in order to determine which digital assets are authentic, thereby agreeing on a common updated ledger (e.g., a new block in a blockchain); [0175]: The nodes in the network may use Simplified Byzantine Fault Tolerance (SBFT), or any other suitable method, to reach consensus on how blocks are added to the blockchain at each step. In SBFT, one designated block generator (e.g., an administrative node computer 550) collects and validates proposed transactions, periodically batching them together into a new-block proposal. Other designated block signers (e.g., administrative node computers 550) ratify the proposed block with their signatures. All network members may know the identities of the block signers and accept blocks only if signed by a sufficient number of signers. This ensures that competing transactions can be resolved, transactions can be final, and history cannot be rewritten), (see paragraphs [0168], [0175]-[0176], [0027] and [0047] and Fig. 5). […] updating the data processing state of the electronic transfer based on [receive a payment instruction] (see paragraphs [0006], [0097], [0112]-[0113] and [0119]). Alternatively, Jacobs further discloses: receiving an originating data set including parameters for a data process executed over a network between a [first ledger system] and a [second ledger system], the data process for an electronic transfer from an originator account on the first centralized ledger system and associated with a first entity, to a beneficiary account on the second centralized ledger system and associated with a second entity (Jacobs [0161]: At step S506, the sending institution computer 560 may send a transaction request to the issuer node computer 565 (e.g., via the interaction platform). The request may include information for providing a payment to the resource provider, such as information about the originating currency, the destination currency, the amount, the fees and exchange rate, a resource provider enterprise ID, a user enterprise ID, and sending institution computer 560 enterprise ID, and any other suitable information; [0058]: In such a transaction system, the user can provide a payment to the resource provider. To do so, the user computer 110 may instruct the sending institution computer 160 to transfer value from a user account at the sending institution computer 160; [0061]: An example of a sending institution may be an issuer, which may typically refer to a business entity (e.g., a bank) that issues and maintains an account (e.g., a bank account) for a user; [0069]: the financial institutions (e.g., the sending institution computer 160 and the recipient institution computer 140).”), (see paragraph(s) [0161], [0058], [0061], [0067], [0069] and [0194] and Fig. 1 and Fig. 5); Examiner’s Note: With respect to “…on a first centralized ledger system and associated with a first entity, to a beneficiary account on a second centralized ledger system and associated with a second entity”. This limitation does not limit the functionality of the system for managing data processing states because this limitation is outside the scope of the claimed system. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation (e.g., data being stored on a first centralized ledger system and associated with a first entity and on a second centralized ledger system and associated with a second entity) not performed by the system. Therefor this claim element does not receive any patentable weight. generating one or more first entries for storing the originating data set on a distributed ledger of the monitoring system and generating signals to initiate propagation of the one or more first entries to the plurality of nodes (Jacobs [0163]: “At step S508, the issuer node computer 565 may generate a digital asset for the requested transaction. The digital asset may include any suitable information (e.g., remittance information) for communicating that a value is being transferred from the user account to a resource provider account. For example, the digital asset can include a digital asset identifier, the originating currency type, the destination currency type, the sending currency amount...The digital asset identifier may be an identifier generated by issuer node computer 565 that uniquely identifies the digital asset. For example, the digital asset identifier may be a string of alphanumeric characters or a scannable image (e.g., QR code). A transaction identifier may be used as a digital asset identifier; [0119]: The update ledger module 165K may comprise code that causes the processor 165A to record information related to the creation and/or distribution of a digital asset for a transaction. For example, the update ledger module 165K may contain logic that causes the processor 165A to record information by updating a ledger of transactions based on a new digital asset or other transaction. Such a ledger may be stored at the ledger database 165C. The update ledger module 165K may include instructions for adding a block to a blockchain, the new block including information about one or more transactions; [0167]: At step S510, the issuer node computer 565 may provide the digital asset and any other suitable information to an administrative node computer 550; [0144]: An example transfer is shown, where an issuer node computer 165 is providing a digital asset to a recipient node computer 145. While a direct arrow is shown, the issuer node computer 165 may actually broadcast the digital asset information to several or all of the nodes in the network), (see paragraphs [0163], [0119], [0167], [0127], [0144] and [0176] and Fig. 4 and Fig. 5); Examiner’s Note: the language “generating signals to initiate propagation” has been considered and determined to be an intended use language. Therefore, it fails to provide a patentable distinction over the prior art. However, for compact prosecution purposes, citation is provided above. See MPEP § 2114. communicating data messages between the [first ledger system] and an [intermediary ledger system] to execute a first hop of the data process, wherein the first hop is a first of a series of intermediate point-to-point centralized ledger transactions between the first centralized ledger system (Jacobs [0168]: At step S512, the administrative node computer 550 may validate the digital asset. For example, the administrative node computer 550 may identify each involved entity based on the enterprise IDs, and may ensure that each entity is enrolled and in good standing; [0173]; In some embodiments, the administrative node computer 550 may also distribute information about the digital asset or updated ledger to other administrative node computers 550. Also, when the ledger is updated, the transaction (e.g., transfer of value from the user to the resource provider) may be considered official and guaranteed), (see paragraphs [0006], [0168]-[0171], [0173], [0175], [0090] and [209] and Figs. 2, 5 and 6); Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Jayaram with Jacobs to include a well-known ledger/database function, such as monitoring and updating transaction records/data to enhance transaction process. Jayaram does not specifically disclose: invoking a chaincode to monitor a data processing state of the data process, the monitoring including updating the data processing state of the electronic transfer. However, Kim, an analogous art of blockchain technology, discloses: invoking a chaincode to monitor a data processing state of the data process, the monitoring including updating the data processing state of the electronic transfer when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger, the pair of event entries comprising (Kim [0085]: As information is stored on the blockchain 114, the smart contract 116 and/or other logic in the system 100 may detect events, perform calculations, and/or generate additional data. For example, as discussed in reference to FIG. 1, the tracking device 107 may communicate tracking updates. The tracking updates and/or information related to the tracking updates may be stored as one or more datablocks on the blockchain 114. Alternatively or in addition, the executable logic 304 of the smart contract 116 may be executed to monitor the tracking updates for events identified in by the smart contract 116. Alternatively or in addition, the executable logic 304 may create information that is stored in the datablocks 401; [0079]: The datablocks 401 (portions respectively shown in FIG. 4A, FIG. 4B, and FIG. 4C) may include transaction information 402. The transaction information 402 may include a log descriptive of an event. The event may include, for example, creation of a rate contract, approval of the rate contract, creation of a freight order, acceptance of the freight order, receipt of the tracking update 109, loading, delivery, creation of an invoice, acceptance of an invoice, payment of an invoice, check in, check out, goods issued, goods, receipt, idle time, miles driven, proof of delivery, and/or receipt of any other type of information related to the shipment 108. Alternatively or in addition, the transaction information 402 may include identifying information of an account, a time the transaction occurred, and/or any other information related to the transaction; [0081]: the blockchain 114 may include a first set of datablocks 401A-D. The first set of datablocks 401A-D may include a first datablock 401A. The first datablock 401A may include an example of the contract block 202 previously described in reference to FIG. 2. The transaction information 402 of the first datablock 401A may indicate that a freight contract was created on the blockchain 114. The transaction information 402 include an identifier of an account and/or user associated with the freight contract. For example, the transaction information 402 information may include the identifier of a user and/or account that caused the contract block 202 to be created), (see paragraphs [0060]-[0061]); Examiner’s Note: With respect to claim language “updating the data processing state of the electronic transfer when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger”. This is conditional language limitation. The updating the data processing state of the electronic transfer only gets performed when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger, but is not performed otherwise. Accordingly, once the positively recited steps are satisfied, the method as a whole is satisfied -- regardless of whether or not other steps are conditionally performed under certain other hypothetical scenarios. See MPEP § 2103 I C. a transmission event entry including information from an event message received from one of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a first point in the particular hop of the data process in the series of intermediate centralized ledger point-to-point transactions (Kim [0106]: a first example of flow logic for the system 100. The logistics control stack 110 may receive the tracking update 109 (602). The tracking update 109 may be created by the tracking device 107. The logistics control stack 110 may identify the smart contract 116. The smart contract 116 may include executable logic and/or instructions configured to calculate one or more tracking metrics (604)), (see paragraphs [0106]-[0107] and Fig. 6) and a corresponding receipt event entry including information from an event message received from another of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a corresponding second point in the particular hop (Kim [0109]: The logistics control stack 110 may determine that the shipment 108 associated with the tracking device 107 has reached the destination 120 (610). The logistics control stack 110 may determine that one or more conditions identified in the smart contract 116 are fulfilled and/or satisfied), (see paragraphs [0109]-[0110] and [0112] and Fig. 6). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Jayaram and Jacobs with Kim to include a well-known function of blockchain such as a smart contract to monitor and track stages of a transaction to enhance transaction process. Alternatively, CHIDAMBARAM also discloses: […] updating the data processing state of the electronic transfer when traversal of the distributed ledger of the monitoring system indicates that a pair of related event entries for a particular hop of the data process are on the ledger, the pair of event entries comprising (CHIDAMBARAM [abstract]: Based on the validations' results, events are emitted to an event bus monitored by a management system. These events selectively trigger the management system to automatically implement modeled tasks in dependence on the validations' results; [0031]: According to certain example embodiments, events may have associated event types, e.g., with the event types being mapped to triggers associated with different modeled tasks in the modeled process; [0033]: According to certain example embodiments, events may have associated event types, e.g., with the event types being mapped to triggers associated with different modeled tasks in the modeled process; [0102]: devices 918a-918b belong to a first device group 1002′, and devices 918c-918d belong to a second device group 1002″. The first and second device groups 1002′ and 1002″ send IoT data to IoT platform 914), (see paragraphs [0031]-[0033] and Fig. 10): a transmission event entry (e.g., sensor data from 102e) including information from an event message received from one of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a first point in the particular hop of the data process in the series of intermediate centralized ledger point-to-point transactions (CHIDAMBARAM [0070]: the supply chain related contract involves parties or entities sending event-related data. The event related data provides notifications with the entity's address, date/time, temperature reading, location from which and to which the associated package is being shipped, and a status value; [0071]: To make this happen, temperature readouts from the IoT-enabled package are provided to the blockchain 104 in step S404, and the blockchain smart contract 302 may be consulted; [0074]: the goods are transported from the manufacturer with IoT-enabled package, the IoT-enabled package sends sensor data to the blockchain cloud 104 via the blockchain component 506 of the integration server 502. The product is tracked through the various touch points, and the blockchain cloud 104 is updated accordingly; [0102]: devices 918a-918b belong to a first device group 1002′, and devices 918c-918d belong to a second device group 1002″. The first and second device groups 1002′ and 1002″ send IoT data to IoT platform 914. The IoT platform 914 associates 1602 the smart contract identifier with the IoT data, based on the device group and smart contract identifier mapping performed by the dynamic smart contract component 902. The blockchain IoT component 904 receives the IoT data, and it triggers its related smart contract in blockchain 920); (see paragraphs [0070]-[0071] and [0073]-[0074] and Figs. 4-6 and 16), and a corresponding receipt event entry (e.g., sensor data from 102d) including information from an event message received from another of the first centralized ledger system, the intermediary centralized ledger system, or the second centralized ledger system which is a corresponding second point in the particular point-to-point transaction (CHIDAMBARAM [0070]: the supply chain related contract involves parties or entities sending event-related data. The event related data provides notifications with the entity's address, date/time, temperature reading, location from which and to which the associated package is being shipped, and a status value; [0071]: To make this happen, temperature readouts from the IoT-enabled package are provided to the blockchain 104 in step S404, and the blockchain smart contract 302 may be consulted; [0074]: the goods are transported from the manufacturer with IoT-enabled package, the IoT-enabled package sends sensor data to the blockchain cloud 104 via the blockchain component 506 of the integration server 502. The product is tracked through the various touch points, and the blockchain cloud 104 is updated accordingly; [0102]: devices 918a-918b belong to a first device group 1002′, and devices 918c-918d belong to a second device group 1002″. The first and second device groups 1002′ and 1002″ send IoT data to IoT platform 914. The IoT platform 914 associates 1602 the smart contract identifier with the IoT data, based on the device group and smart contract identifier mapping performed by the dynamic smart contract component 902. The blockchain IoT component 904 receives the IoT data, and it triggers its related smart contract in blockchain 920.); (see paragraphs [0070]-[0071], [0073]-[0074] and [0102] and Figs. 4-6 and 16). Alternatively, CHIDAMBARAM further discloses: A monitoring system for monitoring a series of point-to-point centralized ledger electronic transactions between a series of centralized ledger systems (CHIDAMBARAM [0020]: This component in certain example embodiments is configured to automatically identify the IoT parameters from the IoT platform that are required to be monitored, and apply configurable validation rules on the IoT parameters and/or other parameters that are defined or obtained by calling an external system, etc.; [0060]: Thus, certain example embodiments use IoT sensor information and send it to blockchain smart contracts to make and/or enforce automated business process-related decisions. Advantageously, certain example embodiments help provide for monitoring and governance of processes via tracking and/or tracing with IoT and/or other enabled devices.), (see abstract and paragraphs [0020], [0023] and [0060] and Figs. 4-6) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Jayaram and Jacobs with CHIDAMBARAM to include a well-known function of monitoring and tracking stages of a transaction to enhance transaction process. Regarding claims 2 and 13: Jayaram, Jacobs, Kim and CHIDAMBARAM, discloses the limitations of claim 1 above. Jayaram does not specifically disclose, however, Jacobs discloses: The system of claim 1, wherein the at least one processor of the one or more of the plurality of nodes are configured for: identifying event message associated with the one or more first entries based on at least one key field in the corresponding event entry and at least one key field in the one or more first entries (Jacobs [0168], “At step S512, the administrative node computer 550 may val
Read full office action

Prosecution Timeline

Nov 14, 2019
Application Filed
Apr 23, 2022
Non-Final Rejection — §101, §103
Sep 29, 2022
Response Filed
Jan 13, 2023
Final Rejection — §101, §103
Jun 23, 2023
Request for Continued Examination
Jun 28, 2023
Response after Non-Final Action
Aug 26, 2023
Non-Final Rejection — §101, §103
Feb 06, 2024
Response Filed
Jun 01, 2024
Final Rejection — §101, §103
Dec 16, 2024
Request for Continued Examination
Dec 18, 2024
Response after Non-Final Action
Mar 03, 2025
Non-Final Rejection — §101, §103
Sep 08, 2025
Response Filed
Dec 13, 2025
Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12579532
AUTOMATED DEVICE PAIRING
2y 5m to grant Granted Mar 17, 2026
Patent 12572927
SYSTEMS AND METHODS FOR GENERATING AND TRANSMITTING ELECTRONIC TRANSACTION ACCOUNT INFORMATION MESSAGES
2y 5m to grant Granted Mar 10, 2026
Patent 12547993
System, Method, and Computer Program Product for Managing Operation of a Remote Terminal
2y 5m to grant Granted Feb 10, 2026
Patent 12511643
USER ASSUMPTION OF IDENTITY OF NFT IN CRYPTO WALLET
2y 5m to grant Granted Dec 30, 2025
Patent 12499436
DETERMINING AN OPTIMUM QUANTITY OF FRACTIONAL NON-FUNGIBLE TOKENS TO GENERATE FOR CONTENT AND A CONTENT EXCHANGE
2y 5m to grant Granted Dec 16, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

7-8
Expected OA Rounds
60%
Grant Probability
99%
With Interview (+59.6%)
3y 6m
Median Time to Grant
High
PTA Risk
Based on 141 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month