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 Non-Final Office Action is in response to the application 18/679,803 filed on 05/31/2024.
Status of claims:
Claims 1-22 are pending in this Office Action.
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).
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 normalized ([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, Treat in view of Padmanabhan 1 and Williams teaches all of the limitations of claim 1. Treat further teaches wherein the normalized network protocol includes one or more 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 ([0025]: One or more of the exchange nodes 114, 116 may communicate with the interoperability node 102 via portal interfaces 118, 120. For example, the portal interfaces 118, 120 may include an origin portal interface 118 and a target portal interface 120. 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… Examiner’s note: The portal interfaces can be equivalent to transport layer protocol or routing protocol).
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, 10 and 12. 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.
Kaplan et al. (US PGPUB 20230026873) is directed to systems and methods for providing the secure transfer of assets between blockchain networks. The system can include a storage device that can store a bridge program that is programmed to perform (i) lock operations that lock native assets from a first blockchain network and mint synthetic assets representing the native assets in a second blockchain network, and (ii) unlock operations that unlock the native assets by transferring the native assets to an address in the first blockchain network in response to the synthetic assets being returned or destroyed. The system can include a computer system that loads and executes the bridge program in a secure computing enclave that provides a trusted execution environment. The computer system can then perform the lock operations and the unlock operations to provide a bridge between the first blockchain network and the second blockchain network.
Conclusion
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 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 published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.D.V./Examiner, Art Unit 2153 01/22/2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153