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 .
DETAILED ACTION
2. This action is in response to the Preliminary Amendment filed March 26, 2025.
3. Claims 1-20 have been cancelled and new claims 21-40 have been added.
4. Claims 21-40 have been examined and are pending with this action.
5. The Information Disclosure Statements filed April 11, 2025 and September 11, 2025 have been considered.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
6. Claims 21-40 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Xie et al. (US 2020/0120157 A1).
INDEPENDENT:
As per claim 21, Xie teaches a method, wherein the method is applied to a ledger anchor function (LAF), and comprises:
sending a first message to at least one first node, wherein the first message is for configuring a first node of the at least one first node to be a blockchain node, wherein a type of the first node comprises at least one of: a terminal device, an access network device, a core network element, an independent node, an application function node, or an edge network node, and wherein the terminal device, the access network device, the core network element, the independent node, the application function node, and the edge network node are nodes having a blockchain capability in a communication network (see Xie, FIG. 1; [0003]: “Network nodes in a transmission network may perform data authentication and storage based on a chain-like data structure, and perform data generation and update based on a distributed consensus algorithm.”; [0006]: “obtaining, by a current consensus node of the blockchain network, a first transaction comprising a first request for adding the node as a new consensus node of the blockchain network… In some embodiments, node to be added may not be a part of the blockchain network prior to the node addition, and by the node addition, the node joins the blockchain network to become an activated consensus node.”; and [0101]: “the first request to add node X as the new consensus node of the blockchain network comprises: a request to change node X from an inactivated consensus node of the blockchain network to an activated consensus node of the blockchain network, or a request to include node X in the blockchain network as the new consensus node.”); and
receiving a first indication message from the at least one first node, wherein the first indication message indicates whether the first node is successfully configured as the blockchain node (see Xie, Abstract: “in response to that consensus verification of the first transaction succeeds”; and [0076]: “After receiving the pre-prepare message, if nodes 1, 2, and 3 successfully validate the message m, each of the nodes 1, 2, and 3 will re-broadcast the message m… Each node may add the prepare message broadcast by itself (the prepare message indicating endorsement by itself) and the received prepare messages (the prepare messages indicating endorsement by other nodes) to a local log.”).
As per claim 29, Xie teaches an apparatus, comprising:
at least one processor, coupled with at least one memory storing computer program, which when executed by the at least one processor (see Xie, [0029]: “a system for adding a node in a blockchain network is implemented in a current consensus node of the blockchain network and comprises one or more processors and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform operations”), cause the apparatus to perform:
receiving a first message, wherein the first message is for configuring the apparatus to be a blockchain node, wherein a type of the apparatus comprises at least one of: a terminal device, an access network device, a core network element, an independent node, an application function node, or an edge network node, and wherein the terminal device, the access network device, the core network element, the independent node, the application function node, and the edge network node are nodes having a blockchain capability in a communication network (see Xie, FIG. 1; [0003]: “Network nodes in a transmission network may perform data authentication and storage based on a chain-like data structure, and perform data generation and update based on a distributed consensus algorithm.”; [0006]: “obtaining, by a current consensus node of the blockchain network, a first transaction comprising a first request for adding the node as a new consensus node of the blockchain network… In some embodiments, node to be added may not be a part of the blockchain network prior to the node addition, and by the node addition, the node joins the blockchain network to become an activated consensus node.”; and [0101]: “the first request to add node X as the new consensus node of the blockchain network comprises: a request to change node X from an inactivated consensus node of the blockchain network to an activated consensus node of the blockchain network, or a request to include node X in the blockchain network as the new consensus node.”); and
sending, a first indication message, wherein the first indication message indicates whether the apparatus is successfully configured as the blockchain node (Abstract: “in response to that consensus verification of the first transaction succeeds”; and [0076]: “After receiving the pre-prepare message, if nodes 1, 2, and 3 successfully validate the message m, each of the nodes 1, 2, and 3 will re-broadcast the message m… Each node may add the prepare message broadcast by itself (the prepare message indicating endorsement by itself) and the received prepare messages (the prepare messages indicating endorsement by other nodes) to a local log.”).
As per claim 33, Xie teaches an apparatus (see Xie, [0020]: “According to yet other embodiments, an apparatus for adding a node in a blockchain network is implemented in a current consensus node of the blockchain network and comprises”), comprising:
at least one processor, coupled with at least one memory storing computer program, which when executed by the at least one processor, cause the apparatus to perform:
sending a first message to at least one first node, wherein the first message is for configuring a first node of the at least one first node to be a blockchain node, wherein a type of the first node comprises at least one of: a terminal device, an access network device, a core network element, an independent node, an application function node, or an edge network node, and wherein the terminal device, the access network device, the core network element, the independent node, the application function node, and the edge network node are nodes having a blockchain capability in a communication network (see Claim 21 rejection above); and
receiving a first indication message from the at least one first node, wherein the first indication message indicates whether the first node is successfully configured as the blockchain node (see Claim 21 rejection above).
DEPENDENT:
As per claims 22 and 34, which respectively depend on claims 21 and 33, Xie further teaches wherein the method further comprises:
receiving blockchain establishment requirement information from a second node (see Xie, Abstract: “obtaining, by a current consensus node of the blockchain network, a first transaction comprising a first request for adding the node as a new consensus node of the blockchain network”; [0009]: “obtaining the first transaction from a client-side device or a command console of a controller.”; and [0092]: “Also, in the genesis contract/system contract, method and parameter configurations for consensus nodes may be added. Thus, based on the genesis contract/system contract, each node can accomplish the operation of node addition by changing the nodes in the local node list.”), and
wherein the sending the first message to the at least one first node comprises: sending the first message to the at least one first node based on the blockchain establishment requirement information (see Xie, [0003]: “Network nodes in a transmission network may perform data authentication and storage based on a chain-like data structure, and perform data generation and update based on a distributed consensus algorithm. In some cases, such nodes of the blockchain network may need to be added”; [0054]: “Each node of the Consortium Blockchain may correspond to an entity or organization. Participants may join the Consortium Blockchain network through authorization, forming the consortium with shared interests and collectively maintaining the blockchain network's operation. For any of the various types of blockchain described above, there may be a need for dynamically adding a node in a blockchain network.”; and [0067]: “When the primary node becomes faulty, a view change protocol needs to be triggered for making adjustment to change the primary node when the system is faulty.”).
As per claims 23 and 35, which respectively depend on claims 22 and 34, Xie further teaches wherein the blockchain establishment requirement information indicates one or more of following requirements:
a blockchain structure, a block structure, a consensus mechanism, a throughput requirement, whether a blockchain supports an editing function, an access control policy for the blockchain, a quantity of first nodes, policy information, identification information of the first node, a capability of the first node, the type of the first node, a mode supported by the first node, configuration information corresponding to the first node, or whether the first node is capable of providing a trusted execution environment for running of the blockchain (see Xie, Abstract: “in response to that consensus verification of the first transaction succeeds”).
As per claims 24 and 36, which respectively depend on claims 23 and 35, Xie further teaches wherein the blockchain establishment requirement information indicates the policy information (see Xie, [0037]: “a node to be added in a blockchain network and is configured with instructions executable by one or more processors to cause the one or more processors to perform operations comprising: synchronizing with a blockchain to obtain a first local blockchain copy, wherein the blockchain network maintains the blockchain and comprises a plurality of current consensus nodes”; and [0088]-[0091]: “Selection rules for the set of pre-prepare messages include… ”), and
wherein the sending the first message to the at least one first node based on the blockchain establishment requirement information comprises:
obtaining identification information of a network element in which the first node is located, address information of the first node, or identification information of the first node based on the policy information (see Xie, [0010]: “In some embodiments, the current consensus node locally maintains the node list, the node list comprising one or more of the following: consensus node identifier, consensus node IP address, and consensus node port number; and the plurality of consensus nodes are numbered sequentially in the node list.”; and [0012]: “In some embodiments, the numbering the node in a node list based on numbers of a plurality of current consensus nodes of the blockchain network comprises: adding an identifier of the node to an end of the node list and sequentially numbering the node based on the numbers of the plurality of consensus nodes in the node list; or reordering the plurality of consensus nodes and the node in the node list according to a node attribute.”); and
sending the first message to the at least one first node based on the identification information of the network element in which the first node is located, the address information of the first node, or the identification information of the first node (see Xie, [0010]: “In some embodiments, the current consensus node locally maintains the node list, the node list comprising one or more of the following: consensus node identifier, consensus node IP address, and consensus node port number; and the plurality of consensus nodes are numbered sequentially in the node list.”; and [0092]: “In the example of Consortium Blockchain, in a Consortium Blockchain scenario, a node may correspond to one or more accounts.”; and [0147]: “In some embodiments, the transaction request for node activation will form a new block after passing the consensus verification (the block may also include transactions other than the transaction for node activation). The newly generated block exists on at least a Quorum number of current consensus nodes after the consensus verification, and does not exist in the newly activated node (i.e., the just added node). This is because the node that was just activated did not participate in the consensus verification before its activation. Thus, the node to be added may continue to send a synchronization request to some or all of the current nodes after S801, thereby acquiring the block from the current nodes. In this way, the node to be added can acquire the block containing the transaction request for node activation.”).
As per claims 25 and 37, which respectively depend on claims 24 and 36, Xie further teaches wherein the blockchain establishment requirement information indicates the identification information of the first node (see Claim 24 rejection above), and
wherein the sending the first message to the at least one first node based on the blockchain establishment requirement information comprises: sending the first message to the at least one first node based on the identification information of the first node (see Xie, [0021]: “in response to determining that the first local blockchain copy comprises a first request to add the node as a new consensus node of the blockchain network, transmitting to one or more of the plurality of current consensus nodes a second transaction comprising a second request to activate the node”; and [0039]: “Therefore, adding a node in the blockchain network improves the robustness and reliability of the blockchain network. In some embodiments, by dynamically executing a first transaction for adding a node and a second transaction for activating the node, the node can be added as a new consensus node to the pool of existing consensus nodes without having to disrupt the operation of the blockchain network. In one embodiment, system down time is avoided during the node addition process, and the blockchain network sustains its normal operation.”).
As per claims 26 and 38, which respectively depend on claims 21 and 33, Xie further teaches wherein the method further comprises: receiving blockchain capability information of a plurality of nodes, wherein the plurality of nodes comprises the at least one first node (see Xie, [0121]: “Moreover, if the content of the message in the transaction request for adding the node together with other messages form a consensus result, the message content in the transaction request for adding the node has the same message sequence on different nodes, that is, at least a Quorum number of consensus nodes have reached a consensus with respect to the content of and an order associated with the message in the node addition request.”).
As per claims 27 and 39, which respectively depend on claims 26 and 38, Xie further teaches wherein the method further comprises: storing the blockchain capability information of the plurality of nodes; or sending the blockchain capability information of the plurality of nodes to a fourth node (see Xie, [0059]: “Behaviors of the smart contract are controlled by the contract code, and the contract account stores the status of the smart contract.”; and [0061]: “Smart contracts may be independently executed in each blockchain node of the blockchain network according to a prescribed manner. All execution records and data may be stored in the blockchain.”).
As per claims 28 and 40, which respectively depend on claims 21 and 33, Xie further teaches wherein the method further comprises:
sending a second message to a third node, wherein the third node is a successfully configured node in the at least one first node, and the second message is for canceling the third node serving as the blockchain node (see Xie, [0205]: “The examples of systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed embodiments.”); and
receiving a second indication message from the third node, wherein the second indication message indicates whether the third node is successfully canceled (see Xie, Abstract: “in response to that consensus verification of the first transaction succeeds”; [0076]: “After receiving the pre-prepare message, if nodes 1, 2, and 3 successfully validate the message m, each of the nodes 1, 2, and 3 will re-broadcast the message m… Each node may add the prepare message broadcast by itself (the prepare message indicating endorsement by itself) and the received prepare messages (the prepare messages indicating endorsement by other nodes) to a local log.”; and [0205]: “The examples of systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed embodiments.”).
As per claim 30, which depends on claim 29, Xie further teaches wherein when the computer program is executed by the at least one processor, further cause the apparatus to perform: sending blockchain capability information (see Xie, Abstract: “in response to that consensus verification of the first transaction succeeds”; [0067]: “Further, all replicas move through a succession of configurations called views. In a view, one replica is the primary node and the others are backup nodes.”; and [0121]: “Moreover, if the content of the message in the transaction request for adding the node together with other messages form a consensus result, the message content in the transaction request for adding the node has the same message sequence on different nodes, that is, at least a Quorum number of consensus nodes have reached a consensus with respect to the content of and an order associated with the message in the node addition request.”).
As per claim 31, which depends on claim 30, Xie further teaches wherein the blockchain capability information indicates a mode supported by a node, and the mode comprises one or more of:
a client mode, a micronode mode, a light-node mode, or a full-node mode (see Xie, [0077]: “the node adds the commit messages to the local log (with the commit message broadcast by itself and the Quorum-1 commit messages, the local log will have a Quorum number of commit messages) and transitions to a committed state.”), wherein:
a node in the client mode is configured to generate a transaction or a transaction proposal (see Xie, [0055]: “The newly generated block may comprise one or more transactions that are consensus verified by the consensus nodes.”; and [0084]: “Thus, different nodes are in different states.”);
a node in the micronode mode is configured to preprocess the transaction or the transaction proposal, wherein the preprocessing the transaction or the transaction proposal comprises one or more of: verifying the transaction or the transaction proposal, executing the transaction proposal to generate the transaction, or generating a microblock based on the transaction (see Xie, [0055]: “consensus nodes may assume the responsibility of performing consensus verification of blockchain transactions (or transactions for short). By contrast, inactivated nodes (which may or may not be a part of the blockchain network) do not participate in such consensus verification. Through consensus verification, consensus nodes may come to a consensus (agreement) for a newly generated block to add to the blockchain. The newly generated block may comprise one or more transactions that are consensus verified by the consensus nodes. The consensus nodes may also make other consensus decisions for the blockchain, for example, setting service fees for the blockchain.”);
a node in the light-node mode is configured to perform processing the transaction, the transaction proposal, or the microblock, and the processing the transaction, the transaction proposal, or the microblock comprises one or more of: verifying the transaction or the transaction proposal, executing the transaction proposal to generate the transaction, reaching a consensus on the transaction or the microblock, or generating a complete block based on the transaction or the microblock (see Xie, [0055]: “consensus nodes may assume the responsibility of performing consensus verification of blockchain transactions (or transactions for short). By contrast, inactivated nodes (which may or may not be a part of the blockchain network) do not participate in such consensus verification. Through consensus verification, consensus nodes may come to a consensus (agreement) for a newly generated block to add to the blockchain. The newly generated block may comprise one or more transactions that are consensus verified by the consensus nodes. The consensus nodes may also make other consensus decisions for the blockchain, for example, setting service fees for the blockchain.”); and
a node in the full-node mode comprises a function of the node in the light-node mode, and is configured to store the complete block (see Xie, [0059]: “Behaviors of the smart contract are controlled by the contract code, and the contract account stores the status of the smart contract.”; and [0061]: “Smart contracts may be independently executed in each blockchain node of the blockchain network according to a prescribed manner. All execution records and data may be stored in the blockchain.”).
As per claim 32, which depends on claim 30, Xie further teaches wherein the blockchain capability information indicates at least one of: a smart-contract deployment, invoking, or execution capability, a transaction reporting, querying, or execution capability, a block querying capability, a computing capability, a storage capability, a network capability, a security algorithm capability, a trusted-execution-environment provision capability, or a consensus capability (see Xie, [0057]: “Each of Public Blockchain, Private Blockchain, and Consortium Blockchain may provide smart contract. A smart contract can be deployed in a blockchain through a blockchain transaction and later invoked by another blockchain transactions.”).
Conclusion
7. For the reasons above, claims 21-40 have been rejected and remain pending.
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 PST.
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, Nicholas R Taylor can be reached on 571-272-3889. 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.
/Michael Won/Primary Examiner, Art Unit 2443
Prosecution Insights