DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s RCE filed October 2, 2025.
Claims 1, 5, 13, 17, 18, and 20 are currently amended.
Claims 1-20 are currently pending.
Claims 1-20 have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on October 2, 2025 has been entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1, 2, 7-14, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Luedtke et al. (US 11269859 B1) in view of Ecessa “Everything You Need to Know About Network Failover”.
Regarding claim 1
Luedtke teaches:
A transaction processing method, performed by an electronic device, the method comprising: {abstract “Systems and methods are described to correlate different types of data obtained from a distributed ledger system.”}
performing availability detection on blockchain nodes according to transaction data recorded in a blockchain network, and determining whether each of the blockchain nodes is a normal node or an abnormal node; and {column 88 row 33 “For example, the data intake and query system 108 can identify nodes with smaller or greater throughput, nodes with the most errors, etc.”}
Nodes with the most errors read on abnormal, while others read on normal.
a transaction request {column 59 line 20 “In some embodiments, the log data can be generated in response to one or more activities on a node, such as an error […] or in response to the node 1806 processing a transaction [transaction request] of the distributed ledger system”}
displaying the transaction processing result in an interaction interface of the abnormal node {column 88 line 40 “In certain embodiments, the visualization can include a display object for each node of the distributed ledger system 1802 with one more indicators that indicate a status of the node, such as the number of errors or faults at the node, the number of transactions processed or being processed, the number of channels associated with each node, etc.”}
for maintaining a non-interrupted user interaction
This is an intended result and is not given patentable weight.
Luedtke does not teach, however Ecessa teaches:
transmitting, when a transaction request is generated through an abnormal node, the transaction request to a normal node, and cooperatively processing the transaction request through the abnormal node and the normal node; {page 2 “Failover within a communications network is the process of transferring [transmitting] tasks [transaction] from a failed component [abnormal node] to a similar redundant component [normal node] to avoid disruption and maintain operations.”}
“When a transaction request is generated through the abnormal node” is interpreted as making the step contingent and therefore not required. See MPEP 2111.04 "Adapted to," "Adapted for," "Wherein," "Whereby," and Contingent Clauses. However, the step is taught by Ecessa.
transmitting a transaction processing result from the normal node to the abnormal node, {page 3 “when hardware is a ‘hot spare’ or ‘High Availability (HA) pair,’ the failover mechanisms run in the background, so the transfer takes place automatically. The data on both systems is automatically synchronized.”; page 3 “The most reliable failover scenario… where both network systems are permanently running in parallel — data on both systems is 100% synchronized at all times. Users will not be aware of any failures.”)
Ecessa teaches synchronizing (reads on transmitting) data between both systems (reads on abnormal and normal nodes) when using a failover mechanism.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply the failover and synchronizing of Ecessa to the distributed ledger system of Luedtke, and thus transfer transactions from nodes with the most errors to other nodes, in order to avoid disruption and maintain operations.
Luedtke in view of Ecessa does not teach:
wherein nothing related to the transaction processing result is displayed in an interaction interface of the normal node.
Luedtke in view of Ecessa does not contain any suggestion that a ‘hot spare’ (normal node) would not display a transaction processing result. However, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to not include any display at a ‘hot spare’ when such a feature is not desired or required, such as when a user is not present at the ‘hot spare’. See MPEP 2144.04 II A “Omission of an Element and Its Function Is Obvious if the Function of the Element Is Not Desired”.
Regarding claim 2
Luedtke teaches:
The transaction processing method according to claim 1, wherein performing availability detection comprises:
storing the transaction data generated through the blockchain network into a transaction cache pool;
packaging, when a preset block upload condition is met, the transaction data stored in the transaction cache pool, to generate a to-be-uploaded current block; and {column 71 line 49 “With reference to FIG. 21C, the ordering nodes 1806B, 1806E (4) communicate the generated blocks to the peer nodes 1806A, 1806C, 1806D, 1806F for validation and commitment to a blockchain. As described herein, each generated block can include one or more endorsed transactions in a body portion, a header portion, and/or metadata, etc.”}
The transactions not yet included in a block are the transaction cache pool.
When a preset block upload condition is met is interpreted as making the step contingent and therefore not required. See MPEP 2111.04 "Adapted to," "Adapted for," "Wherein," "Whereby," and Contingent Clauses. However, the step is taught by Luedtke.
performing availability detection on each of the blockchain nodes according to transaction data recorded in the current block. {Column 74 line 21 “To address this and other potential issues, a data intake and query system 108 can ingest and correlate the data generated by a distributed ledger system [data recorded in the current block]”; column 88 row 33 “For example, the data intake and query system 108 can identify nodes [perform availability detection] with smaller or greater throughput, nodes with the most errors, etc.”}
Regarding claim 7
Luedtke teaches:
The transaction processing method according to claim 2, wherein performing availability detection on blockchain nodes according to transaction data recorded in a blockchain network further comprises:
obtaining one or more historical blocks that are uploaded to a blockchain; and
performing availability detection on the blockchain nodes according to transaction data recorded in the historical blocks. {column 74 row 29 “Based on the collected data, the data intake and query system 108 can identify correlations between transactions that are included in a blockchain and corresponding log data and metrics data. This information can provide insight into the inner workings of the distributed ledger system 1802, identify performance issues, security issues, errors, etc. By identifying faults, errors, and issues with the different components of the distributed ledger system 1802, the data intake and query system 108 can improve the distributed ledger system 1802 as a whole. For example, based on the identified issues, system configurations can be adjusted, components can be fixed or reconfigured, etc.” column 88 row 33 “For example, the data intake and query system 108 can identify nodes with smaller or greater throughput, nodes with the most errors, etc.”}
Identifying nodes with the most errors reads on availability detection. The identification in Luedtke is based on collected data which is not limited to data in any particular block.
Regarding claim 8
Ecessa teaches:
The transaction processing method according to claim 1, wherein transmitting the transaction request to the normal node comprises:
selecting a target node that is currently in an idle state from normal nodes in the blockchain network; {page 2 “Failover within a communications network is the process of transferring [transmitting] tasks [transaction] from a failed component [abnormal node] to a similar redundant component [target node] to avoid disruption and maintain operations.”; page 7 “Capacity factors must be assessed to avoid failures or congestion caused by unanticipated high traffic volumes when a failover occurs.”}
The word “idle” is interpreted as meaning that a node has available capacity. Assessing capacity factors when a failover occurs implies selecting an idle node.
establishing a data channel for data communication between the abnormal node and the target node; and
transmitting the transaction request from the abnormal node to the target node based on the data channel. {page 2 “Failover within a communications network is the process of transferring [transmitting] tasks [transaction] from a failed component to a similar redundant component to avoid disruption and maintain operations.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the failover of Ecessa to the distributed ledger system of Luedtke for the same reasons given in regards to claim 1.
Regarding claim 9
The transaction processing method according to claim 8, wherein selecting a target node comprises:
selecting a blockchain node whose leisure degree is highest from the blockchain network as a miner node for packaging the current block; and
The above is not given patentable weight because it is purely a mental process and the selection of a miner node is not used.
selecting the target node that is currently in the idle state from the normal nodes in the blockchain network by the miner node.
See claim 8.
Regarding claim 10
The transaction processing method according to claim 9, wherein selecting a blockchain node whose leisure degree is highest from the blockchain network comprises:
calculating a quantity of transactions of each of the blockchain nodes in the blockchain network according to a preset time period;
screening the quantity of transactions of each of the blockchain nodes according to transaction data recorded in a preset quantity of blocks that are uploaded, to obtain a quantity of transactions of each of the blockchain nodes; and
selecting a blockchain node with a smallest quantity of transactions as the blockchain node whose leisure degree is highest.
The above steps are not given patentable weight. Selecting the miner node is purely mental process which has no functional relationship to the claimed method because the result of the mental process, a selected miner node, is not used.
Regarding claim 11
Luedtke teaches:
The transaction processing method according to claim 1, wherein cooperatively processing the transaction request through the abnormal node and the normal node comprises:
obtaining a behavior data stream associated with the transaction request through the abnormal node, and […], the behavior data stream comprising interaction behavior data acquired through an interaction interface of the abnormal node; {column 11 line 38 “Similar to the system of 38, each of the forwarders 204 may be configured to receive data from an input source and to forward the data to other components of the system 306 for further processing.”}
The behavior data stream comprising interaction behavior data acquired through an interaction interface of the abnormal node is not given patentable weight because it claims the content of data with no functional relationship to the claimed method.
processing the behavior data stream through a background processing thread {column 8 line 11 “As yet another example, client applications 110 may include background processes that perform various operations without direct interaction from a user.”}
displaying a transaction processing result corresponding to the transaction request in the interaction interface of the abnormal node based on the result data stream. {column 88 line 40 “In certain embodiments, the visualization can include a display object for each node of the distributed ledger system 1802 with one more indicators that indicate a status of the node, such as the number of errors or faults at the node, the number of transactions processed or being processed, the number of channels associated with each node, etc.”}
Luedtke does not teach, however Ecessa teaches:
transmitting the behavior data stream to the normal node {page 2 “Failover within a communications network is the process of transferring [transmitting] tasks from a failed component [abnormal node] to a similar redundant component [normal node] to avoid disruption and maintain operations.”}
processing the behavior data stream through a background processing thread on the normal node, to obtain a result data stream as response data of the behavior data stream, and
transmitting the result data stream to the abnormal node; and
{page 3 “when hardware is a ‘hot spare’ or ‘High Availability (HA) pair,’ the failover mechanisms run in the background, so the transfer takes place automatically. The data on both systems is automatically synchronized.”}
The data on both systems being synchronized reads on transmitting the result.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the failover of Ecessa to the distributed ledger system of Luedtke for the same reasons given in regards to claim 1.
Regarding claim 12
Luedtke teaches:
The transaction processing method according to claim 11, wherein when the behavior data stream is processed through the background processing thread on the normal node, the method further comprises:
processing, when a new transaction request is generated through the normal node, the new transaction request through a foreground processing thread on the normal node, to obtain a transaction processing result corresponding to the new transaction request, the foreground processing thread being a thread running with the background processing thread in parallel; and {column 2 line 24 “FIGS. 21A-21D are data flow diagrams illustrating an embodiment of a distributed ledger system processing a transaction;”
column 8 line 11 “As yet another example, client applications 110 may include background processes that perform various operations without direct interaction from a user.”}
displaying the transaction processing result corresponding to the new transaction request in an interaction interface of the normal node. {column 2 line 15 “FIG. 17D is an interface diagram of an example a user interface displaying both log data and performance data, in accordance with example embodiments;”}
Regarding claims 13-14, 18-19
Claims 13-14 and 18-19 are substantially similar to claims 1-2, respectively, and are treated the same with respect to prior art rejections.
Claims 3-6, 15-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Luedtke et al. (US 11269859 B1) in view of Ecessa “Everything You Need to Know About Network Failover”, further in view of Hearty et al. (US 20210250368 A1).
Regarding claim 3
Luedtke teaches:
The transaction processing method according to claim 2, wherein performing availability detection on each of the blockchain nodes comprises:
calculating a quantity of transaction failures […] of each of the blockchain nodes according to the transaction data recorded in the current block;
determining, when the quantity of transaction failures and the transaction failure rate of the blockchain node each reach a corresponding parameter threshold, that the blockchain node is an abnormal node with availability failure; and {column 88 row 33 “For example, the data intake and query system 108 can identify nodes with smaller or greater throughput, nodes with the most errors, etc.”}
Identifying the nodes with the most errors implies counting the quantity of failures.
determining, when at least one of the quantity of transaction failures or the transaction failure rate of the blockchain node does not reach the corresponding parameter threshold, that the blockchain node is an available normal node.
See claim 1 “determining…” step.
Luedtke does not teach, however Hearty teaches:
[…] and a transaction failure rate […] {[0049] “a calculated failure rate greater than a failure rate threshold can increase an anomaly score level for the certain time period”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the calculation of a failure rate of Hearty with the count of errors of Luedtke because it would provide an additional way of detecting anomalies/abnormalities.
Regarding claim 4
Luedtke teaches:
The transaction processing method according to claim 3, wherein calculating a quantity of transaction failures and a transaction failure rate of each of the blockchain nodes comprises:
calculating the quantity of transaction failures of each of the blockchain nodes according to the transaction data recorded in the current block; and
See claim 3 “calculating…” step.
calculating the transaction failure rate of the blockchain node when the quantity of transaction failures reaches a preset quantity-of-times threshold.
See claim 3. When the quantity of transaction failures reaches a preset quantity-of-times threshold is interpreted making the step contingent and therefore not required. However, this step is already required by claim 3. See MPEP 2111.04 "Adapted to," "Adapted for," "Wherein," "Whereby," and Contingent Clauses.
Regarding claim 5
Luedtke teaches:
The transaction processing method according to claim 3, wherein calculating a quantity of transaction failures of each of the blockchain nodes comprises:
performing a completeness check on the transaction data recorded in the current block, and determining whether a transaction process of the transaction data is complete;
determining that the transaction data is transaction failure data when the transaction process of the transaction data is incomplete;
{column 88 line 36 “the data intake and query system 108 can use the events [transaction data] to track the lifecycle of a transaction from when it is initially proposed to a node 1806, when it is endorsed, when it is ordered, and when it is finally validated and written to the ledger 1808. If the transaction stops [is incomplete] or slows down unacceptably at any point in the journey, the data intake and query system 108 can diagnose the reason for the slow down and generate an alert. Potential issues may include, errors…”}
obtaining a node identifier of a blockchain node for processing the transaction data; and {column 61 row 5 “Furthermore, the monitor 1804 and/or data intake and query system 108 can extract the transaction identifiers from the communications received from the monitor 1804 using one or more regex rules. In some such embodiments, the data intake and query system 108 can store the transaction identifiers in one or more inverted indexes that associate the transaction identifier with the event that includes it. In some cases, the monitor 1804 can extract additional information from the transaction notifications, such as, but not limited to channel information (e.g., the channel associated with the transaction and/or blockchain), node information (e.g., identification of the nodes that endorsed, ordered, and/or validated the transaction) [node identifier], etc.”}
counting the transaction failure data according to the node identifier for calculating the quantity of transaction failures of each of the blockchain nodes. {column 88 row 33 “For example, the data intake and query system 108 can identify nodes with smaller or greater throughput, nodes with the most errors, etc.”}
Identifying nodes with the most errors implies counting the transaction failure data according to the node identifier because identifying nodes with the most errors would generally involve counting how many errors each nodes has.
Regarding claim 6
Luedtke teaches:
The transaction processing method according to claim 5, wherein performing a completeness check on the transaction data recorded in the current block comprises:
performing, according to the transaction process, data screening on the transaction data recorded in the current block to obtain transaction starting data generated when a transaction is initiated; (Luedtke Column 86 line 47 “For a particular transaction at a particular ordering node 1806, an example order of log data may be: receipt from a client computing device/peer node 1806 [starting data], ordering, addition to a block, communication to peer node 1806/commitment to an ordering node blockchain [end data].”)
obtaining a process identifier used for representing a transaction process to which the transaction starting data belongs; (Luedtke Column 86 line 66 “As described herein, the log data can include transaction identifiers [process identifier].”)
performing, according to the process identifier, matching detection on the transaction starting data and another transaction data recorded in the current block to determine whether transaction end data belonging to the same transaction process as the transaction starting data exists in the current block, the transaction end data being data generated when the transaction is ended; (Luedtke Column 87 line 11 “The data intake and query system 108 can associate [matching detection] the events that share the same transaction identifier field value.”)
determining that the transaction process of the transaction data is complete when it is determined that the transaction end data belonging to the same transaction process as the transaction starting data exists in the current block; and
determining that the transaction process of the transaction data is incomplete when the transaction end data belonging to the same transaction process as the transaction starting data does not exist in the current block. (Luedtke column 88 line 36 “the data intake and query system 108 can use the events [transaction data] to track the lifecycle of a transaction from when it is initially proposed to a node 1806, when it is endorsed, when it is ordered, and when it is finally validated and written to the ledger 1808. If the transaction stops [is incomplete] or slows down unacceptably at any point in the journey, the data intake and query system 108 can diagnose the reason for the slow down and generate an alert. Potential issues may include, errors…”)
The above two steps are interpreted as alternatives because they have conditions which are mutually exclusive and cover all possibilities. “Determining that the transaction process is complete” is a purely mental step not entitled to patentable weight as it lacks a functional relationship to the other claim limitations. However, they are taught by Luedtke.
Regarding claims 15-17, and 20
Claims 15 and 20 are substantially similar to claim 3 and are rejected for the same reasons. Claims 16 and 17 are substantially similar to claims 4 and 5, respectively, and are rejected for the same reasons.
Response to Arguments
Specification
The previously given objections are withdrawn due to the amendments.
35 USC § 112
The previously given rejections are withdrawn due to the amendments.
35 USC § 103
Applicant has amended claim 1 and argues the additions to the claim distinguish it from the cited prior art. Specifically, Applicant argues “wherein nothing related to the transaction processing result is displayed in an interaction interface of the normal node” is not taught by the cited art and that, because Luedtke teaches a display object for each node of the system, it actually teaches away from the claimed method. However, Luedtke does not teach a display object being necessary for each and every node. Further, MPEP 2144.04 II “ELIMINATION OF A STEP OR AN ELEMENT AND ITS FUNCTION” states that it is not necessary for the prior art to specifically teach omitting a function where the function is not desired. Since a user would not necessarily be present at a failover node, it would be obvious to only display the transaction processing result at the node where the transaction is originated.
Applicant further argues “for maintaining a non-interrupted user interaction” is also not taught by the cited art. However, this is explicitly an intended result, and therefore is not given patentable weight. Additionally, it is noted that this result is taught by Ecessa (page 3 “The most reliable failover scenario, used for complete business continuity, is the use of a “Disaster Recovery (DR) site,” where both network systems are permanently running in parallel — data on both systems is 100% synchronized at all times. Users will not be aware of any failures.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lee (US 20190354967 A1) teaches:
[0136] “When the information on the fulfilled contract history or the fulfilled contract result is stored in the block chain by the node 110, the processor 250 accesses the information on the fulfilled contract history or the fulfilled contract result stored in the block chain of the node 110 through the decentralized application 120 to display the interface screen representing the information.”
Gadnis (US 20180285879 A1) teaches:
[0077] “In user interface 2000 of FIG. 20, blockchain tab 2002 is active. User interface 2000 includes a dashboard view that includes a current block number 2004 in the blockchain where the completed transaction is stored. The dashboard view also includes a browser session information 2006 that indicates how many browsers are currently directly accessing the blockchain at the current point in time and blockchain peer information 2008 that indicates how many blockchain nodes are being accessed in order to display the platform blockchain transactions. Pending view 2010 illustrates the data stored in the current block, including the transaction.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698