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 .
This Final Office Action is in response to the application 18/679,803 filed on 04/29/2026.
Status of claims:
Claim 1, 10, 12, and 21 are amended in this Office Action.
Claims 1-22 are pending in this Office Action.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 21-22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 21 recite the limitation " the set of two or more different types of network protocols". There is insufficient antecedent basis for this limitation in the claim.
Claim 22 is rejected because they inherit the deficiencies of claim 21, from which they depend, with respect to 35 U.S.C. 112(b).
Response to Arguments
CLAIM REJECTIONS UNDER 35 U.S.C. § 103
Applicant’s arguments filed on 04/29/2026 (pages 10-12) regarding claim rejections under 35 U.S.C 103 have been fully considered. However, after further examination, the Examiner respectfully submits that the arguments are not persuasive.
The applicant argues that the cited references do not teach or suggest “selecting, by the one or more processors leveraging neuro-symbolic artificial intelligence (Al), a normalized network protocol for inclusion in the normalized protocol model”.
The examiner respectfully disagrees with the Applicant; the Examiner respectfully submits that Treat discloses “[0017]: The interoperability node 102 may include a virtual or physical network node that communicates with DLT networks, e.g., DLT networks 104 and 106. In general, a DLT network may refer to a group of distributed computing nodes that communicate to maintain information on one or more blockchains according a DLT. The DLT networks 104 and 106 may each include corresponding nodes that run on different DLT platforms (e.g. Quorum, Hyperledger, etc.)…[0051] The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks…”. The system of Treat is directed to an interoperability node that is constructed based on agreed protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks. Thus, Treat at least teaches “selecting, by the one or more processors, a normalized network protocol for inclusion in the normalized protocol model”.
Padmanabhan 1 is relied to teach the deficiency of Treat that “selecting,…” is “leveraging neuro-symbolic artificial intelligence (AI)”. Padmanabhan 1 discloses “[0119] This machine learning-based software agent may be built into the blockchain platform, blockchain platform host, cloud computing environment platform, an application server or cluster of servers in a cloud computing services platform, for example, as a layer of artificial intelligence that delivers predictions and recommendations based on various selected factors, such as business processes and consortium data. This layer of artificial intelligence may use insights to automate selection of one of a number of consensus protocol types to use in committing the block or transaction therein to the blockchain based on the specified transaction type.”. The system of Padmanabhan 1 uses a layer of artificial intelligence in a blockchain network specifically to automate selection of one of a number of consensus protocol types to use in committing the block or transaction. Thus, an AI technology is incorporated in the system to perform a protocol selecting process. Therefore, Treat in view of Padmanabhan 1 at least teaches “selecting, by the one or more processors leveraging neuro-symbolic artificial intelligence (Al), a normalized network protocol for inclusion in the normalized protocol model”.
The applicant also amended the independent claims to include “ wherein: the normalized network protocol comprises a set of two or more different types of network protocols, the different types of network protocols including a transport layer protocol, an application layer protocol, a routing protocol, an internet layer protocol, a network security protocol, a wireless protocol, a network management protocol, or a voice over IP protocol”. The examiner respectfully submits that Treat discloses “[0017] The system 100 may include an interoperability node 102. The interoperability node 102 may include a virtual or physical network node that communicates with DLT networks, e.g., DLT networks 104 and 106… [0025]: The origin portal interface 118 may provide a communications interface with the interoperability node 102 from the origin DLT network 104. The target portal interface 120 may provide a communications interface with the interoperability node 102 from the target DLT network 106… [0051]: The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks…”. The system of Treat teaches an interoperability node storing protocols for synchronizing DLT objects between DLT networks and include a virtual or physical network node that communicates with DLT networks. Also, the exchange nodes communicate with the interoperability node to perform synchronization between DLT networks. The specification of the application does not define or limit what each of a transport layer protocol, an application layer protocol, a routing protocol, an internet layer protocol, a network security protocol, a wireless protocol, a network management protocol, or a voice over IP protocol can be. The interoperability node that corresponds to the normalized network protocol communicates with the portal interfaces of other DLT network which under BRI, can be equivalent to an internet layer protocol, a network security protocol, a wireless protocol, a network management protocol, transport layer protocol or routing protocol. Also, the interoperability node can also have at least two or more protocols by storing agreement that include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks. Therefore, Treat at least teaches “ wherein: the normalized network protocol comprises a set of two or more different types of network protocols, the different types of network protocols including a transport layer protocol, an application layer protocol, a routing protocol, an internet layer protocol, a network security protocol, a wireless protocol, a network management protocol, or a voice over IP protocol”.
The applicant also amended the independent claims to include “a first type of network protocol in the set of two or more different types of network protocols is selected for inclusion in the normalized network protocol based on a first group of one or more network protocols of the different types of network protocols used at a first of the plurality of different blockchain networks and a second type of network protocol in the set of two or more different types of network protocols is selected for inclusion in the normalized network protocol based on a second group of one or more network protocols of the different types of network protocols used at a second of the plurality of different blockchain networks” in claims 1 and 21. The examiner respectfully submits that Treat discloses “[0031]: FIG. 2 illustrates an example of the interoperability node 102. The interoperability 102 may be a full or partial node associated with multiple DLT networks and synchronize information between the DLT networks. For example, the interoperability node 102 may be a full node of the origin DLT network 104 and the target DLT network 106. The interoperability node 102 may include the origin blockchain 108, which may be compliant with the origin DLT network 104 and the target blockchain 110, which is compliant with the target DLT network 106. The interoperability node 102 may respectively follow the protocols of each respective DLT network for adding, updating, accessing, deleting and/or modifying information stored on each corresponding blockchain”. The system of Treat is directed to generating an interoperability node that follows protocols of each DLT network of the plurality of DLT networks for adding, updating, accessing, deleting and/or modifying information stored on each corresponding blockchain thus it can have protocols collected from each of the plurality of different blockchain networks. Therefore, Treat at least teaches “a first type of network protocol in the set of two or more different types of network protocols is selected for inclusion in the normalized network protocol based on a first group of one or more network protocols of the different types of network protocols used at a first of the plurality of different blockchain networks and a second type of network protocol in the set of two or more different types of network protocols is selected for inclusion in the normalized network protocol based on a second group of one or more network protocols of the different types of network protocols used at a second of the plurality of different blockchain networks”.
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 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.
Claims 1-8, 10-14, 16, and 19-22 are rejected under 35 U.S.C. 103 as being unpatentable over Treat et al. (US PGPUB 20190905950) “Treat” in view of Padmanabhan et al. (US PGPUB 20190238525) “Padmanabhan 1” and Williams et al. (US PGPUB 20210133700) “Williams”.
Regarding claim 1, Treat teaches one or more non-transitory computer-readable medium storing computer-executable instructions ([0080]), which, when executed on one or more processors on a computer system, perform a method for generating a normalized protocol model that leverages distributed ledger technology and is interoperable across a plurality of different blockchain networks, each of the plurality of different blockchain networks using different network protocols (Fig. 1 & [0013]: One example of a technical advancement achieved by the systems and methods described below may be common interfaces to an interoperability node may maximize cohesive communications between DLT while minimizing coupling between the DLTs.), the method comprising: selecting, by the one or more processors, a normalized network protocol for inclusion in the normalized protocol model, the selecting being configured to enable electronic transactions to be performed, and data and communications to be exchanged between the plurality of different blockchain networks ([0017]: The interoperability node 102 may include a virtual or physical network node that communicates with DLT networks, e.g., DLT networks 104 and 106. In general, a DLT network may refer to a group of distributed computing nodes that communicate to maintain information on one or more blockchains according a DLT. The DLT networks 104 and 106 may each include corresponding nodes that run on different DLT platforms (e.g. Quorum, Hyperledger, etc.)…[0051] The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks… Alternatively or in addition, synchronization occur only after a trusted entity agreement is established… Examiner’s note: An interoperability node with virtual/physical network and agreed rules, protocols, criteria, parameters is equivalent to a normalized network protocol for inclusion in the normalized protocol model wherein communications between different blockchain networks can be exchanged using the interoperability node); requesting, by the one or more processors, electronic consent from the plurality of different blockchain networks to implement the normalized network protocol at the plurality of different blockchain networks ([0043]: The exchange nodes 114, 116 may communicate with the interoperability node 102 to establish a trusted entity agreement. The trusted entity agreement may be stored on and/or managed by the interoperability node 102. The trusted entity agreement may indicate that the interoperability node 102 is a mutually trusted node between two or more DLT networks…[0045]: The trust proposal may designate the origin exchange node 114, the target exchange node 116, the interoperability node 102, the client portal interface, and/or the target portal interface. For example, the trust proposal may include IP addresses, ports, network identifiers, and/or other identifying information to uniquely identify one or more nodes… [0048] In general, the interoperability node 102 may receive trusted entity agreements from multiple DLT exchange nodes and/or portal interfaces. The trusted entity agreement stored on the interoperability node may be flagged as “unconfirmed” until the portals or exchange nodes from each participating DLT network have communicated a proposal for a trusted entity agreement… Examiner’s note: The interoperability node requires all of blockchain networks to communicate a proposal for a trusted entity agreement wherein an agreement includes information such as network identifiers, rules, protocols, criteria, parameters.); in response to receipt of the electronic consent from each of the plurality of different blockchain networks that indicates a consensus to implement the normalized protocol model, triggering implementation, by the one or more processors of the normalized protocol model to be used by transmitting electronic notifications, by the one or more processors, to each of the plurality of different blockchain networks ([0048]: After the interoperability node 102 receives a proposal for a trusted entity agreement message from all relevant portal interfaces, the interoperability node 102 may reflag the trusted entity agreement as “confirmed”. Once the trusted entity agreement is flagged as “confirmed”, the origin DLT network 104 and the target DLT network 106 may begin performing interoperability communications. For example, the interoperability node 102 may be permitted to synchronize information between the origin DLT network 104 and the target DLT network 106... [0051] The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks…Examiner’s note: The interoperability node with particular rules, protocols, criteria, parameters is utilized for interoperability communications between blockchain networks when proposal for a trusted entity agreement message is received from all relevant networks); and enforcing the implementation of the normalized protocol model at the different blockchain networks ([0051] The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks); wherein: the normalized network protocol comprises a set of two or more different types of network protocols, the different types of network protocols including a transport layer protocol, an application layer protocol, a routing protocol, an internet layer protocol, a network security protocol, a wireless protocol, a network management protocol, or a voice over IP protocol ([0017] The system 100 may include an interoperability node 102. The interoperability node 102 may include a virtual or physical network node that communicates with DLT networks, e.g., DLT networks 104 and 106… [0025]: The origin portal interface 118 may provide a communications interface with the interoperability node 102 from the origin DLT network 104. The target portal interface 120 may provide a communications interface with the interoperability node 102 from the target DLT network 106… [0051]: The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks… Examiner’s note: The interoperability node that corresponds to the normalized network protocol communicates with the portal interfaces of other DLT network which can be equivalent to an internet layer protocol, a network security protocol, a wireless protocol, a network management protocol, transport layer protocol or routing protocol. Thus, the interoperability node can also have at least two or more protocols by storing agreement that include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks); and a first type of network protocol in the set of two or more different types of network protocols is selected for inclusion in the normalized network protocol based on a first group of one or more network protocols of the different types of network protocols used at a first of the plurality of different blockchain networks and a second type of network protocol in the set of two or more different types of network protocols is selected for inclusion in the normalized network protocol based on a second group of one or more network protocols of the different types of network protocols used at a second of the plurality of different blockchain networks ([0031]: FIG. 2 illustrates an example of the interoperability node 102. The interoperability 102 may be a full or partial node associated with multiple DLT networks and synchronize information between the DLT networks. For example, the interoperability node 102 may be a full node of the origin DLT network 104 and the target DLT network 106. The interoperability node 102 may include the origin blockchain 108, which may be compliant with the origin DLT network 104 and the target blockchain 110, which is compliant with the target DLT network 106. The interoperability node 102 may respectively follow the protocols of each respective DLT network for adding, updating, accessing, deleting and/or modifying information stored on each corresponding blockchain... Examiner’s note: The interoperability node follows protocols of each DLT network thus it can have protocols collected from each of the plurality of different blockchain networks).
Treat does not explicitly teach the one or more processors leveraging neuro-symbolic artificial intelligence (AI) and the selecting being based on the different network protocols.
Padmanabhan 1 teaches the one or more processors leveraging neuro-symbolic artificial intelligence (AI) ([0119] This machine learning-based software agent may be built into the blockchain platform, blockchain platform host, cloud computing environment platform, an application server or cluster of servers in a cloud computing services platform, for example, as a layer of artificial intelligence that delivers predictions and recommendations based on various selected factors, such as business processes and consortium data. This layer of artificial intelligence may use insights to automate selection of one of a number of consensus protocol types to use in committing the block or transaction therein to the blockchain based on the specified transaction type. In one embodiment, this layer of artificial intelligence may be provided by Salesforce.com's Einstein, an artificial intelligence (AI) layer embedded in Salesforce's cloud computing services architecture.) It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Padmanabhan 1teachings in the Treat system. Skilled artisan would have been motivated to incorporate artificial intelligence as a layer of the blockchain platform taught by Padmanabhan 1 in the Treat system to improve the automation of selecting protocol types in committing transactions, thus can reduce the cost of the system. This close relation between both of the references highly suggests an expectation of success.
Treat in view of Padmanabhan 1 does not explicitly teach the selecting being based on the different network protocols.
Williams teaches the selecting being based on the different network protocols ([0037] The cross-chain communications network 112 may be based on at least one of a Polkadot, Cosmos, International Blockchain Consulting (IBC), or Interledger network; however, it should be understood that an example embodiment may employ any suitable network and protocol that enables different blockchains to interoperate.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Williams teachings in the Treat and Padmanabhan 1 system. Skilled artisan would have been motivated to incorporate selecting a cross-chain network from different networks taught by Williams in the Treat and Padmanabhan 1 system to optimize the communications between the blockchain networks thus improves the performance of the system. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 2, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches wherein the implementation of the normalized protocol model at the plurality of different blockchain networks facilitates seamless electronic transactions, data exchanges, and communications across the plurality of different blockchain networks ([0051] The exchange nodes may communicate with the interoperability node to perform synchronization between DLT networks… [0055]: In examples where the target portal interface receives the synch proposal request, the target portal interface may communicate the synch proposal created by the origin exchange node , or details related to the synch proposal, to the target exchange node. The target portal interface may reformat the synch proposal to a format that complies with an API, protocols, and/or communications standards implemented by the interoperability node… Examiner’s note: Transactions, data exchanges, and communications across the plurality of different blockchain networks can be done with the interoperability node).
Regarding claim 3, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 2. Treat further teaches recording data related to the electronic transactions, data exchanges, and communications in a heterogeneous distributed ledger that maintains records across the plurality of different blockchain networks ([0018]: The interoperability node 102 may be a full, or partial, node of the DLT networks 104, 106. For example, the interoperability node 102 may include a local copy of blockchain(s) for the target DLT network 106 and the origin DLT network 104. In other examples, the interoperability node 102 may communicate with one or more nodes that store have blockchains configured on the DLT networks 104, 106.).
Regarding claim 4, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches wherein the one or more processors are configured to convert between network protocols at the plurality of different blockchain networks ([0018] The interoperability node 102 may serve as an intermediary for data transfer and/or data synchronization between the multiple DLT networks 104, 106. The DLT networks 104, 106 may include an origin DLT network 104 and a target DLT network 106… [0019] The origin DLT network 104 may be different from the target DLT network 106. In other words, the origin DLT network 104 may include a group of full or partial nodes that participates in the origin DLT network and not the target DLT platform. For example, nodes of the origin DLT network may store and maintain a first blockchain and nodes of the target DLT network may store and maintain a second blockchain… Examiner’s note: Networks with different protocols can communicate with one another through the interoperability node, thus the interoperability node can convert between network protocols at the plurality of different blockchain networks for data exchange and communications).
Regarding claim 5, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches wherein the one or more processors are configured to cause a change to one or more of the different network protocols in use at the plurality of different blockchain networks to conform to the normalized protocol model ([0020]: For example, the interoperability node 102 may access an origin blockchain 108 and a target blockchain 110...Alternatively, the origin blockchain may include a distributed ledger according to a first DLT technology, such as Quorum, and the target blockchain 110 may include a distributed ledger according to a distributed ledger according to a second DLT technology, such as Hyperledger…[0040] To translate information between the origin DLT and the target DLT, the DOS 112 may access translation logic. The transition logic may include predetermined logic that accepts the origin instance of the DLT object and formats the information into a form compliant with the target DLT 106…The translation logic may be provided to the interoperability node to enable interoperability with one or more additional DLT networks… Examiner’s note: The interoperability node contains translation logic that can be used to cause a change to network protocols of one network to another network).
Regarding claim 6, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches wherein the implementation of the normalized protocol model at the plurality of different blockchain networks by the one or more processors facilitates transferring of assets between different digital wallets or payment systems ([0018] The interoperability node 102 may serve as an intermediary for data transfer and/or data synchronization between the multiple DLT networks 104, 106… [0026]: The portal interface may provide a logical or physical endpoint for information synchronization and/or asset transfer between two or more DLT networks.).
Regarding claim 7, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches recording the electronic consent by the plurality of different blockchain networks in one or more smart contracts; and saving a copy of the one or more smart contracts at each of the plurality of different blockchain networks ([0042] In some examples, the synchronization repository 206 may also store trust proposals and trust agreements established between DLTs. For example, the DLT repository may store associations between one or more portal interfaces, one or more exchange nodes, one or more trust proposals, one or more trust confirmations, and/or one or more trust agreements.).
Regarding claim 8, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches deriving, by the one or more processors, an electronic consent protocol for requesting the electronic consent from the plurality of different blockchain networks ([0048]: The interoperability node 102 may receive the trusted entity agreement message from origin portal interface 118 and store the trusted entity agreement. The trusted entity agreement may be flagged as “unconfirmed” until the target exchange node 116 communicates a proposal for the trusted entity agreement. After the interoperability node 102 receives a proposal for a trusted entity agreement message from all relevant portal interfaces, the interoperability node 102 may reflag the trusted entity agreement as “confirmed”... Examiner’s note: The interoperability node flags the agreement as “unconfirmed” until all agreements are received. This can be equivalent to a form of consent protocol for requesting the electronic consent from the plurality of different blockchain networks).
Regarding claim 10, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches determining, by the one or more processors, the different network protocols that are initially used at the plurality of different blockchain networks before the selection of the normalized network protocol ([0037] The origin blockchain 108 may include an origin instance 202 of a DLT object and the target blockchain 110 may include a target instance 204 of the DLT object. In general, an instance of the DLT object may refer to a stored representation of the DLT object in a blockchain according to a particular DLT. The instance of the DLT object may be stored in one or more datablocks, depending on the rules, protocols, and standards of the particular DLT network… [0051] The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks… Examiner’s note: Blockchain networks are identified by the interoperability node and synchronization agreement include rules, protocols, criteria, parameters are stored in the node for synchronizing DLT objects between the particular networks ); wherein the neuro-symbolic AI is configured to identify which of the different network protocols at the different blockchain networks correspond to one another and are to be included in the normalized network protocol. ([0072]: The interoperability node may format origin data from the origin instance for compliance with the target DLT (508). For example, the origin data may follow a specific format, data structure, or protocol prescribed by the DLT platform of the origin DLT network 104. The interoperability node may access rules and/or logic that specify how to translate the origin data for compliance with the target DLT platform of the target DLT network… Examiner’s note: The system can identify the origin DLT and format corresponding data of the origin for compliance with the target DLT).
Regarding claim 11, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches detecting, by the one or more processors, one or more changes to one or more of the different network protocols implemented at the plurality of different blockchain networks after implementation of the normalized protocol model ([0031]: For example, the interoperability node 102 may be a full node of the origin DLT network 104 and the target DLT network 106. The interoperability node 102 may include the origin blockchain 108, which may be compliant with the origin DLT network 104 and the target blockchain 110, which is compliant with the target DLT network 106. The interoperability node 102 may respectively follow the protocols of each respective DLT network for adding, updating, accessing, deleting and/or modifying information stored on each corresponding blockchain… Examiner’s note: The interoperability node can include blockchain, that is compliant with other blockchain networks and follow their respective protocols and able to determine adding, updating, accessing, deleting and/or modifying information stored on each blockchain. The adding, updating, accessing, deleting and/or modifying can correspond to changes to network protocol of the blockchain network.); updating, by the one or more processors using the neuro-symbolic AI, the normalized protocol model to account for the one or more changes ([0031]: The interoperability node may respectively follow the protocols of each respective DLT network for adding, updating, accessing, deleting and/or modifying information stored on each corresponding blockchain… Examiner’s note: The interoperability node with normalized protocol can be updated with changes of other blockchain networks); and requesting, by the one or more processors, an updated electronic consent from the plurality of different blockchain networks before implementing the updated normalized protocol model ([0043]: The exchange nodes 114, 116 may communicate with the interoperability node 102 to establish a trusted entity agreement. The trusted entity agreement may be stored on and/or managed by the interoperability node 102. The trusted entity agreement may indicate that the interoperability node 102 is a mutually trusted node between two or more DLT networks. In some examples, the trusted entity agreement may permit the interoperability node 102 to modify a corresponding blockchain of a particular DLT network... Examiner’s note: The interoperability node stores trusted entity agreement to ensure that the node is trusted between blockchain networks and before the node makes any modification between the networks).
Regarding claim 12, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 13, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches the different network protocols implemented at the plurality of different blockchain networks comprise security protocols ([0037] The origin blockchain 108 may include an origin instance 202 of a DLT object and the target blockchain 110 may include a target instance 204 of the DLT object. In general, an instance of the DLT object may refer to a stored representation of the DLT object in a blockchain according to a particular DLT. The instance of the DLT object may be stored in one or more datablocks, depending on the rules, protocols, and standards of the particular DLT network… Examiner’s note: Rules, protocols, and standards of particular DLT network can correspond to security protocols); and the method includes normalizing the security protocols among the plurality of different blockchain networks ([0051] The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks.).
Regarding claim 14, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches securely tracking sales or transfers of goods or services executed across two or more of the plurality of different blockchain networks using the normalized protocol model ([0026] The portal interface may provide a logical or physical endpoint for information synchronization and/or asset transfer between two or more DLT networks…[0041] The interoperability node 102 may include a synchronization repository 206. The synchronization repository 206 may include a memory space, such as a database, for storing and maintaining the active state of DLT objects between DLTs. The synchronization repository 206 may store state information, synchronization proposals and/or synchronization agreements between participants of respective DLTs. The state information may be associated with identifiers of DLT objects, portal interfaces, exchange nodes, and/or blockchains between respective nodes. In some examples, the synchronization repository 206 may include a log of state transitions for DLT objects.).
Regarding claim 16, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches enabling resource sharing, by the one or more processors using the normalized protocol model, across the plurality of different blockchain networks to deploy one or more decentralized applications (DApps) by leveraging resources at two or more of the plurality of different blockchain networks ([0028] The interoperability node 102 may receive messages containing instructions communicated via the portal interfaces 118, 120. In some examples, DLT objects may be synchronized between the origin DLT network 104 and the target DLT network 106. Updates to DLT objects, related description information, and/or meta-information may be shared across the DLT networks and the unicity of the DLT object may be preserved such that all interoperable blockchains provide a truthful source for the DLT object. Synchronization information related to the synchronized state of DLT object may be maintained by the interoperability node 102. For example, the synchronization information may indicate that the DLT object is in-synch with one or more blockchains. Alternatively or in addition, the synchronization information may indicate that the DLT object is out-of-synch in one or more blockchains.).
Regarding claim 19, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches wherein the normalized protocol model is implemented on a cloud network comprising one or more network or Internet routers (Fig. 1 & 6 & [0017] The system 100 may include an interoperability node 102. The interoperability node 102 may include a virtual or physical network node that communicates with DLT networks, e.g., DLT networks 104 and 106).
Regarding claim 20, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches wherein each of the plurality of different blockchain networks comprises one or more virtual networks ([0017] The system 100 may include an interoperability node 102. The interoperability node 102 may include a virtual or physical network node that communicates with DLT networks, e.g., DLT networks 104 and 106. )
Regarding claim 21, note the rejections of claim 1 and 10. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 22, note the rejections of claim 2 and 3. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Claims 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Treat et al. (US PGPUB 20190905950) “Treat” in view of Williams et al. (US PGPUB 20210133700) “Williams” and Padmanabhan et al. (US PGPUB 20190238525) “Padmanabhan 1” and Padmanabhan et al. (US PGPUB 20200349564) “Padmanabhan 2”.
Regarding claim 9, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 8. Treat further teaches determining, by the one or more processors, the different network protocols that are in use at the plurality of different blockchain networks before selecting the normalized network protocol ([0037] The origin blockchain 108 may include an origin instance 202 of a DLT object and the target blockchain 110 may include a target instance 204 of the DLT object. In general, an instance of the DLT object may refer to a stored representation of the DLT object in a blockchain according to a particular DLT. The instance of the DLT object may be stored in one or more datablocks, depending on the rules, protocols, and standards of the particular DLT network… [0051] The exchange nodes 114, 116 may communicate with the interoperability node 102 to perform synchronization between DLT networks. For example, the interoperability node 102 may store a synchronization agreement. The synchronization agreement may include proposed or agreed upon rules, protocols, criteria, parameters, etc. for synchronizing DLT objects between DLT networks… Examiner’s note: Blockchain networks are identified by the interoperability node and synchronization agreement include rules, protocols, criteria, parameters are stored in the node for synchronizing DLT objects between the particular networks ); determining, by the one or more processors, the types of electronic transactions, data exchanges, and communications based on a heterogeneous distributed ledger that maintains records across the plurality of different blockchain networks ([0033] As described herein, a DLT object may refer to a group of tokenized or non-tokenized asset data stored on a blockchain. DLT objects may have various types. For example, DLT objects may include programmed assets, dataset, order-dependent data sets and assets, and/or other objects…[0051]: For example, the synchronization agreement may include an identifier, a data set, programmed assets, or any other type of DLT object).
Treat in view of Williams and Padmanabhan 1 does not explicitly teach selecting, by the one or more processors, the electronic consent protocol to be used based on the different network protocols that are in use at the plurality of different blockchain networks and based on the heterogeneous distributed ledger such that the electronic consent protocol is compatible with the normalized network protocol and the electronic transactions, data exchanges, and communications that are recorded in the heterogenous distributed ledger.
Padmanabhan 2 teaches selecting, by the one or more processors, the electronic consent protocol to be used based on the different network protocols that are in use at the plurality of different blockchain networks and based on the heterogeneous distributed ledger such that the electronic consent protocol is compatible with the normalized network protocol and the electronic transactions, data exchanges, and communications that are recorded in the heterogenous distributed ledger ([0021]: The blockchain network A 101 and blockchain network B 102 can implement any blockchain protocols including any blockchain block and transaction format and any consensus algorithm… [0024]: The blockchain network A 101 includes a set of participant nodes A1-A3. Similarly, the blockchain network B 102 includes a set of participant nodes B1-B3. These nodes implement the respective blockchain consensus algorithm of each blockchain network (e.g., a proof of stake, proof of work or similar consensus algorithm)…[0025]: The interoperability network 103 can include any number of participating nodes that either participate in the consensus protocol, mine blocks, and/or provide storage for the blockchain of the interoperability network 103…[0036]: The mapper of the interoperability network can then await receipt of a result of the consensus algorithm of the second blockchain network. Upon receipt of the consensus of the second blockchain network either in the form of a rejected transaction or committed transaction, the mapper determines consensus (i.e., a form of consensus on consensus) for the interoperability network (Block 214)… Examiner’s note: Consensus algorithms are determined across the blockchain networks and the interoperability network and the networks can be communicated with one another via valid consensus algorithms). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Padmanabhan 2 teachings in the Treat and Padmanabhan 1and Williams system. Skilled artisan would have been motivated to incorporate utilizing proper consensus algorithms across blockchain networks taught by Padmanabhan 2 in the Treat and Padmanabhan 1 and Williams system to ensure data consistency, security, and reliability. This close relation between the references highly suggests an expectation of success.
Regarding claim 15, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat in view of Padmanabhan 1 and Williams does explicitly not teach securely exchanging patient data and medical records across the plurality of different blockchain networks using the normalized protocol model.
Padmanabhan 2 teaches securely exchanging patient data and medical records across the plurality of different blockchain networks using the normalized protocol model ( Fig. 1 & [0025] The embodiments provide an interoperability network 103 to enable each blockchain network to interact with the data in the blockchain of the other blockchain networks connected to the interoperability network 103…[0051]: A physical object of the tenant system 302.sub.1 may correspond to a medical lab report. In this example implementation, the records in the physical object may include a lab report identifier field, a patient name field, a lab network identifier field, a lab test identifier field, a patient identifier field, and a social security number field… Examiner’s note: The system provides a interoperability network that enable each blockchain network to interact with the data in the blockchain of the other blockchain networks wherein blockchain can be related to medical and patient records). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Padmanabhan 2 teachings in the Treat and Padmanabhan 1and Williams system. Skilled artisan would have been motivated to incorporate utilizing blockchain interoperability in medical fields taught by Padmanabhan 2 in the Treat and Padmanabhan 1 and Williams system to improve data security and privacy and to improve data interoperability across different medical agencies. This close relation between the references highly suggests an expectation of success.
Claims 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Treat et al. (US PGPUB 20190305950) “Treat” in view of Padmanabhan et al. (US PGPUB 20190238525) “Padmanabhan 1”, Williams et al. (US PGPUB 20210133700) “Williams” and Chan et al. (US PGPUB 20230073337) “Chan”.
Regarding claim 17, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat in view of Padmanabhan 1 and Williams does explicitly not teach auditing, by the one or more processors using the normalized protocol model, processes performed at the plurality of different blockchain networks to authenticate users of the plurality of different blockchain networks.
Chan teaches auditing, by the one or more processors using the normalized protocol model, processes performed at the plurality of different blockchain networks to authenticate users of the plurality of different blockchain networks ([0054]: The node may also validate the transaction based on establishing user authenticity and transaction data integrity. User authenticity may be established by determining whether the sender indicated by the transaction 502 is in fact the actual originator of the transaction 502. User authenticity may be proven via cryptography, for example, asymmetric-key cryptography using a pair of keys, such as a public key and a private key. Additional factors may be considered when establishing user authenticity, such as user reputation, market conditions, history, transaction speed, etc.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Chan teachings in the Treat and Padmanabhan 1and Williams system. Skilled artisan would have been motivated to incorporate establishing user authenticity in blockchain network taught by Chan in the Treat and Padmanabhan 1 and Williams system to improve security of the system and avoid any potential frauds. This close relation between the references highly suggests an expectation of success.
Regarding claim 18, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat in view of Padmanabhan 1 and Williams does explicitly not teach encrypting, by the one or more processors, electronic data transmitted between the plurality of different blockchain networks based on the normalized protocol model.
Chan teaches encrypting, by the one or more processors, electronic data transmitted between the plurality of different blockchain networks based on the normalized protocol model ([0151] Blockchain bridges enable interoperability between different blockchain networks and between parent blockchains and child blockchains (e.g., sidechains), which may operate under different protocols such as consensus algorithms, cryptographic suites (e.g., cryptographic hash functions), digital signature protocols, private-and-public key encryption protocols, etc…[0157]: The first blockchain network 1300A may format the message, using trading logic 1203, into a format that is readable/understandable by the second blockchain network 1300B. For example, the trading logic 1203 may access secure code repository 1310 to determine the proper format (e.g., structure, syntax, parameters, encryption, etc.) for the second blockchain network 1300B to decrypt and understand the message. For example, the second blockchain network 1300B may be registered with the trusted registration authority 1322 (e.g., a public key infrastructure) so that other networks may be informed on how to send encrypted messages to the second blockchain network 1300B which can then be decrypted and read/understood by the second blockchain network 1300B. ). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Chan teachings in the Treat and Padmanabhan 1 and Williams system. Skilled artisan would have been motivated to incorporate encrypting data transferred between blockchain networks taught by Chan in the Treat and Padmanabhan 1 and Williams system to improve security and integrity of the data . This close relation between the references highly suggests an expectation of success.
Prior Art
The prior arts made of record and not relied upon is considered pertinent to applicant's disclosure.
Schiatti et al. (US Patent 10298395) is directed to data exchange interoperation, an interoperability node is in communication with a furnisher participant node of a furnisher distributed ledger technology (DLT) network and a receiver participant node of a receiver DLT network. The interoperability node may communicate with a furnisher DLT network and a receiver DLT network. The furnisher DLT network may include a furnisher participant node. The furnisher participant node may include a furnisher DLT platform and/or a furnisher blockchain. The receiver participant network may include a receiver participant node. The receiver participant node may include a receiver DLT platform and/or a receiver blockchain. The interoperability node may facilitate a private token exchange between the furnisher participant of the furnisher DLT network and the receiver participant of the receiver DLT network.
Young (US PGPUB 20240144257) is directed to omni-chain interoperability protocol in omni-chain network is disclosed. The method includes receiving by a first node, an event data from a first blockchain. The method includes attesting the event data based on a Threshold Signature Schemes (TSS) process. The method includes transmitting the attested event data to time nodes on a timechain. Upon receiving the attested event data, the time nodes validate the attested event data. The validated event data is available for a second node on a second blockchain to access. The second node is configured to access the validated event data from timechain, attest the validated event data along with other nodes on the second blockchain, and deploy a second smart contract on the second blockchain.
Klianev (US PGPUB 20190251199) is directed to asynchronous public network, synchronous leaderless Byzantine consensus protocol operating with guaranteed safety and time-bound termination of individual protocol rounds is enabled with nodes having clustered architecture and highly available data transactions, and implemented with algorithm that defuses the effect of stop-faulty processes and bypasses the partitioned network links. Utilizing the time-bound consensus, a protocol and architecture for cross-chain transactions accomplish safe interoperability across blockchain networks. Multiple cross-chain transacting networks interconnected in a federation overcome the limitations of blockchain networks with monolithic ledgers in regard to transaction latency, scalability of throughput, volume of managed data, and openness for further interoperability.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAO DANG VUONG whose telephone number is (571)272-1812. The examiner can normally be reached on M-F 7:30-5 EST.
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, Kavita Stanley can be reached at (571) 272-8352. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/C.D.V./ Examiner, Art Unit 2153 06/30/2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153
Prosecution Insights