DETAILED ACTION
This application has been examined. Claims 1-20 are pending.
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 .
Response to Arguments
Applicant's arguments filed 8/3/2026 have been fully considered but they are moot in view of the new grounds for rejection.
Trampus-Manamohan disclosed (re. Claim 1) node freeze proposal indicating to freeze the first slave node by restricting data interaction of the first slave node with other nodes unless a block height of blockchains recorded by the other nodes reaches a frozen block height (Trampus-Paragraph 202, enforceAtHeight field indicates the block height at which the transaction outpoints are to be added to the consensus blacklist in order to start implementation of the freeze/unfreeze. The enforceAtHeight value for an unfreeze order must be greater than the enforceAtHeight value in the associated freeze order.)
performing data interaction with the slave nodes other than the first slave node unless the block height of the recorded blockchains reaches the frozen block height. (Trampus-Paragraph 202, enforceAtHeight field indicates the block height at which the transaction outpoints are to be added to the consensus blacklist in order to start implementation of the freeze/unfreeze. The enforceAtHeight value for an unfreeze order must be greater than the enforceAtHeight value in the associated freeze order.)
Priority
This application claims benefits of priority from Foreign Application CN2023100420257 (China) filed January 12,2023.
The effective date of the claims described in this application is January 12,2023
Allowable Subject Matter
Claims 3-4,11-12,18-19 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and all of the limitations of any intervening claims.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1,6-9,13-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Trampus (USPGPUB 20250350477) further in view of Manamohan (USPGPUB 2020/0311583)
Regarding Claim 1
Trampus Figure 6,Paragraph 27 disclosed transmitting the freeze request message to a plurality of the mining nodes; receiving and validating acceptance messages in reply to the freeze request message from a set of the plurality of the mining nodes, each acceptance message being associated with one mining node in the set of the plurality of mining nodes; determining that the set of the plurality of the mining nodes represent more than a consensus threshold quantity of hash power in the blockchain network; and in response, generating and sending a freeze order to the plurality of mining nodes
Trampus disclosed (re. Claim 1) a data processing method, applied to a service node in a plurality of nodes comprised in a blockchain system,(Trampus-Paragraph 110, freeze administration service 552 is configured to communicate with mining nodes and, in particular, with a blacklist manager 554 implemented at each of the mining nodes) the plurality of nodes further comprising a plurality of slave nodes associated with the service node, and the data processing method comprising:
While Trampus substantially disclosed the claimed invention Trampus does not disclose (re. Claim 1) a master node obtaining status information of each of the slave nodes, the status information comprising a communication connection status of the corresponding slave node and a status of a blockchain recorded by the slave node in the blockchain system;
While Trampus substantially disclosed the claimed invention Trampus does not disclose (re. Claim 1) a first slave node among the slave nodes meeting a freeze condition
Manamohan Paragraph 18 disclosed wherein node 10g can become aware of the fault experienced by node 10e, and thus exclude node 10g from the population during model building. It should be appreciated that a connectivity outage is described as a fault scenario for purposes of illustration, and other forms or node related faults, or failures, can also cause node 10g to initiate fault tolerance techniques.
Manamohan Paragraph 34 disclosed wherein the distributed ledger allows at least a master node 10g to be aware that node 10e may be experiencing a fault that is preventing the node 10e from communication via the blockchain network 110.
Manamohan disclosed (re. Claim 1) a master node obtaining status information of each of the slave nodes, the status information comprising a communication connection status of the corresponding slave node.( Manamohan-Paragraph 34,the distributed ledger allows at least a master node 10g to be aware that node 10e may be experiencing a fault that is preventing the node 10e from communication via the blockchain network 110,Paragraph 36 , distributed ledger 42 can be used to enable state-awareness capabilities for the nodes 10a-10g on the blockchain network 200) and a status of a blockchain recorded by the slave node in the blockchain system; (Manamohan-Paragraph 38, the node 10e may have crashed, causing it to lose all of the dynamic content that has been communicated to the blockchain 200.)
Manamohan disclosed (re. Claim 1) a first slave node among the slave nodes meeting a freeze condition.(Manamohan-Paragraph 71, the master node may determine whether any of the participant nodes are currently “out-of-sync.”… a node that may be self-healing after experiencing a fault can be out-of-sync,Paragraph 72, the master node similarly excludes the node from the participant node population at operation 506)
Trampus and Manamohan are analogous art because they present concepts and practices regarding freeze proposals and consensus mechanisms. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Manamohan into Trampus. The motivation for the said combination would have been to enable determining the “ready” participant node population (Manamohan-Paragraph 72)
Trampus-Manamohan disclosed (re. Claim 1) in response to the status information of a first slave node among the slave nodes meeting a freeze condition, (Manamohan-Paragraph 71, the master node may determine whether any of the participant nodes are currently “out-of-sync.”… a node that may be self-healing after experiencing a fault can be out-of-sync,Paragraph 72, the master node similarly excludes the node from the participant node population at operation 506) generating and broadcasting a node freeze proposal, the node freeze proposal being for representing a node freeze transaction of the first slave node, (Trampus-Paragraph 114, the freeze administration service 552 may generate a freeze request 572 based on the court order or other instructions. The freeze request 572 specifies the transaction outpoints implicated in the order, for example as may have been identified by the address indexer 553. Freeze requests 572 may be referred to as pending freeze orders or prospective freeze orders. The freeze request 572 may be sent to the blacklist managers 554.) and the node freeze transaction indicating to restrict data interaction of the first slave node with other nodes before blockchains recorded by the other nodes reach a frozen block height; (Trampus-Paragraph 131, The freeze order may also indicate the block height at which the freeze order is to go into effect ) and
in response to the master node reaching a consensus on the node freeze proposal with the slave nodes based on a consensus algorithm, performing data interaction with the slave nodes other than the first slave node before the recorded blockchains reach the frozen block height.(Trampus-Paragraph 27, determining that the set of the plurality of the mining nodes represent more than a consensus threshold quantity of hash power in the blockchain network; and in response, generating and sending a freeze order to the plurality of mining nodes, Paragraph 131, Once a consensus threshold is reached in terms of mining node acceptance of the freeze request, then in operation 610 the computing device generates and sends a freeze order to the mining nodes.)
Trampus-Manamohan disclosed (re. Claim 1) node freeze proposal indicating to freeze the first slave node by restricting data interaction of the first slave node with other nodes unless a block height of blockchains recorded by the other nodes reaches a frozen block height (Trampus-Paragraph 202, enforceAtHeight field indicates the block height at which the transaction outpoints are to be added to the consensus blacklist in order to start implementation of the freeze/unfreeze. The enforceAtHeight value for an unfreeze order must be greater than the enforceAtHeight value in the associated freeze order.)
performing data interaction with the slave nodes other than the first slave node unless the block height of the recorded blockchains reaches the frozen block height. (Trampus-Paragraph 202, enforceAtHeight field indicates the block height at which the transaction outpoints are to be added to the consensus blacklist in order to start implementation of the freeze/unfreeze. The enforceAtHeight value for an unfreeze order must be greater than the enforceAtHeight value in the associated freeze order.)
Regarding Claim 7
Claim 7 (re. method) recites substantially similar limitations as Claim 1. Claim 7 is rejected on the same basis as Claim 1.
Regarding Claim 16
Claim 16 (re. apparatus) recites substantially similar limitations as Claim 1. Claim 16 is rejected on the same basis as Claim 1.
Regarding Claim 6,13
Trampus-Manamohan disclosed (re. Claim 6,13) wherein a slave node is associated with a freeze status, and the freeze status is frozen or unfrozen, (Manamohan-Paragraph 71, the master node may determine whether any of the participant nodes are currently “out-of-sync.”… a node that may be self-healing after experiencing a fault can be out-of-sync,Paragraph 72, the master node similarly excludes the node from the participant node population at operation 506) the method further comprises: in response to the freeze status of a second slave node being frozen and the status information of the second slave node meeting an unfreeze condition,
generating and broadcasting a node unfreeze proposal, (Trampus-Paragraph 25, Paragraph 122, validating an unfreeze request message from the freeze administration service, the unfreeze request message identifying the freeze request message and, responsive thereto, removing the one or more digital asset identifiers from the pending blacklist ) the node unfreeze proposal being for representing a node unfreeze transaction of the second slave node, and the node unfreeze transaction being indicating to allow data interaction of the second slave with other nodes when blockchains recorded by the other nodes reach an unfrozen block height; and in response to a consensus being reached on the node unfreeze proposal with the slave nodes other than the second slave node based on the consensus algorithm, performing data interaction with the slave nodes including the second slave node when the recorded blockchains reach the unfrozen block height.
Regarding Claim 8,14
Trampus-Manamohan disclosed (re. Claim 8,14) wherein the master node and the slave nodes each are associated with a freeze status, and the freeze status is frozen or unfrozen, and the method further comprises: obtaining status information of the master node and the status information of each of the slave nodes; (Manamohan-Paragraph 71, the master node may determine whether any of the participant nodes are currently “out-of-sync.”… a node that may be self-healing after experiencing a fault can be out-of-sync,Paragraph 72, the master node similarly excludes the node from the participant node population at operation 506) in response to a freeze status of the first slave node being unfrozen and the status information of the first slave node meeting the freeze condition, determining a target block height for restricting data interaction with the first slave node based on a preset freeze policy; (Trampus-Paragraph 131, The freeze order may also indicate the block height at which the freeze order is to go into effect ) and determining, based on the target block height, that the master node reaches the consensus on the node freeze proposal with the slave nodes.
Regarding Claim 9
Trampus-Manamohan disclosed (re. Claim 9) wherein the method further comprises: in response to a freeze status of the first slave node being frozen and the recorded blockchains reach a historical block height, determining a target block height for restricting data interaction with the first slave node based on a preset freeze policy, the historical block height being for representing a block height range that is indicated by a historical freeze proposal, (Trampus-Paragraph 131, The freeze order may also indicate the block height at which the freeze order is to go into effect ) and the historical freeze proposal being a proposal generated for the first slave node before the node freeze proposal; and determining, based on the target block height, that the master node reaches the consensus on the node freeze proposal with the slave nodes.
Regarding Claim 15
Trampus-Manamohan disclosed (re. Claim 15) wherein the master node and the slave nodes each are associated with a freeze status, and the freeze status is frozen or unfrozen, (Manamohan-Paragraph 71, the master node may determine whether any of the participant nodes are currently “out-of-sync.”… a node that may be self-healing after experiencing a fault can be out-of-sync,Paragraph 72, the master node similarly excludes the node from the participant node population at operation 506) the method further comprises: in response to a freeze status of the second slave node being unfrozen, (Trampus-Paragraph 25, Paragraph 122, validating an unfreeze request message from the freeze administration service, the unfreeze request message identifying the freeze request message and, responsive thereto, removing the one or more digital asset identifiers from the pending blacklist ) determining, based on the consensus algorithm, that the consensus is reached on the node unfreeze proposal with the master node and the slave nodes other than the second slave node. (Trampus-Paragraph 131, Once a consensus threshold is reached in terms of mining node acceptance of the freeze request, then in operation 610 the computing device generates and sends a freeze order to the mining nodes.)
Claim(s) 2,5,10,17,20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Trampus (USPGPUB 20250350477) further in view of Manamohan (USPGPUB 2020/0311583) further in view of Li (USPGPUB 2022/0012702)
Regarding Claim 2,17
Trampus-Manamohan disclosed (re. Claim 2,17) wherein the method further comprises: generating a master feedback result for the node freeze proposal, and broadcasting the master feedback result to the slave nodes, the master feedback result being for representing that the master node agrees to execute the node freeze proposal; (Trampus-Paragraph 128, The signed freeze request order is distributed to mining nodes that form part of the blockchain network. The distribution may, in some cases, be based on active push transmission of the signed freeze request order to a set of mining nodes known to the freeze administration service.)
While Trampus-Manamohan substantially disclosed the claimed invention Trampus-Manamohan does not disclose (re. Claim 2,17) receiving slave feedback results broadcast by the slave nodes, the slave feedback result being for representing whether the corresponding slave node agrees to execute the node freeze proposal; and
Li Figure 4, Paragraph 83 wherein after receiving the acceptance opinion of the transaction participant node, the third-party settlement node forwards the acceptance opinion to another transaction participant node, that is, “broadcasts” an acceptance opinion of each transaction participant node.
Li Paragraph 94 disclosed wherein after receiving acceptance opinions of the transaction participant nodes, the third-party settlement node synthesizes the acceptance opinions of all the participant nodes to determine transaction consensus information and forms the transaction consensus information.
Li disclosed (Claim 2,17) receiving slave feedback results broadcast by the slave nodes, the slave feedback result being for representing whether the corresponding slave node agrees to execute the node freeze proposal.( Li-Figure 4, Paragraph 83,Paragraph 94,after receiving the acceptance opinion of the transaction participant node, the third-party settlement node forwards the acceptance opinion to another transaction participant node, that is, “broadcasts” an acceptance opinion of each transaction participant node)
Trampus,Manamohan and Li are analogous art because they present concepts and practices regarding freeze proposals and consensus mechanisms. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Li into Trampus-Manamohan. The motivation for the said combination would have been to determine that the transaction consensus information is a transaction failure when the acceptance opinion of the another transaction participant node is received and an acceptance opinion of at least one transaction participant node is disallowing a transaction.(Li-Paragraph 259)
Trampus-Manamohan-Li disclosed (re. Claim 2,17) determining, based on the master feedback result (Trampus-Paragraph 128, The signed freeze request order is distributed to mining nodes that form part of the blockchain network. The distribution may, in some cases, be based on active push transmission of the signed freeze request order to a set of mining nodes known to the freeze administration service.) and the received slave feedback results, ( Li-Figure 4, Paragraph 83,Paragraph 94,after receiving the acceptance opinion of the transaction participant node, the third-party settlement node forwards the acceptance opinion to another transaction participant node, that is, “broadcasts” an acceptance opinion of each transaction participant node) that the consensus is reached on the node freeze proposal with the slave nodes.(Trampus- Paragraph 131, Once a consensus threshold is reached in terms of mining node acceptance of the freeze request, then in operation 610 the computing device generates and sends a freeze order to the mining nodes.)
Regarding Claim 5,20
Trampus-Manamohan-Li disclosed (re. Claim 5,20) wherein the communication connection status comprises a historical communication moment, wherein the historical communication moment is a moment with a smallest time difference from a current moment among moments at which the corresponding slave node communicates with the master node; (Li-Paragraph 74, third-party settlement node periodically initiates, for any transaction participant node, a query to the transaction participant node when the third-party settlement node does not receive, within a first preset duration, an acceptance opinion transmitted by the transaction participant node, until the acceptance opinion transmitted by the transaction participant node is received or a quantity of queries reaches a first preset threshold.) and
the status of the blockchain comprises a slave node block height, the slave node block height is a block height of the blockchain recorded by the corresponding slave node; (Trampus-Paragraph 131, The freeze order may also indicate the block height at which the freeze order is to go into effect ) the generating and broadcasting a node freeze proposal comprises:
identifying, according to the historical communication moment and the slave node block height, the first slave node meeting the freeze condition from the slave nodes, a time difference between the historical communication moment of the first slave node and the current moment being greater than a preset duration threshold, (Li-Paragraph 74, third-party settlement node periodically initiates, for any transaction participant node, a query to the transaction participant node when the third-party settlement node does not receive, within a first preset duration, an acceptance opinion transmitted by the transaction participant node, until the acceptance opinion transmitted by the transaction participant node is received or a quantity of queries reaches a first preset threshold.) and a height difference between the slave node block height of the first slave node and a master node block height being greater than a preset height difference threshold, (Trampus-Paragraph 131, The freeze order may also indicate the block height at which the freeze order is to go into effect ) the master node block height being a block height of a blockchain recorded by the master node; and creating the node freeze transaction for the first slave node, and generating and broadcasting the node freeze proposal based on the node freeze transaction. (Trampus-Paragraph 131, The freeze order may also indicate the block height at which the freeze order is to go into effect )
Regarding Claim 10
Trampus-Manamohan-Li disclosed (re. Claim 10) wherein the determining that the master node reaches the consensus on the node freeze proposal with the slave nodes comprises: matching the target block height with the frozen block height indicated by the node freeze transaction, (Trampus-Paragraph 131, The freeze order may also indicate the block height at which the freeze order is to go into effect ) and generating and broadcasting a slave feedback result, the slave feedback result being for representing whether the corresponding slave node agrees to execute the node freeze proposal; ( Li-Figure 4, Paragraph 83,Paragraph 94,after receiving the acceptance opinion of the transaction participant node, the third-party settlement node forwards the acceptance opinion to another transaction participant node, that is, “broadcasts” an acceptance opinion of each transaction participant node) receiving a master feedback result broadcast by the master node, and receiving slave feedback results broadcast by other slave nodes, the master feedback result being for representing that the master node agrees to execute the node freeze proposal; and determining, based on the master feedback result and slave feedback results, that the master node reaches the consensus on the node freeze proposal with the slave nodes.
Conclusion
Examiner’s Note: In the case of amending the claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREG C BENGZON whose telephone number is (571)272-3944. The examiner can normally be reached on Monday - Friday 8 AM - 4: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, John Follansbee can be reached on (571) 272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GREG C BENGZON/ Primary Examiner, Art Unit 2444
Prosecution Insights