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 .
Response to Amendment
This Office action is in response to Applicant's amendment filed on 11/20/2025.
Claim 1-20 are pending. Claim 1, 8 and 15 are amended. Claim 1-20 are rejected.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Chen, Tian et al (PGPUB Document No. 20210119807), hereafter referred as to “Chen”, in view of Olson, Timothy et al (PGPUB Document No. 20230036439), hereafter, referred to as “Olson”.
Regarding Claim 1 (Previously Presented), Chen teaches A system comprising: a memory; and a processing device, operatively coupled to a memory(Chen, Fig. 25 discloses system for cross-blockchain exchange with processors, memory and storages), to perform operations comprising: receiving a request to send a data item from a source node associated with a source blockchain having a first type to a destination node associated with a destination blockchain having a second type different from the first type by using a communication protocol supporting transmission of the data item from the source blockchain to the destination blockchain(Chen, Fig. 14 and para 0159 disclose first type of blockchain (source blockchain) is getting transferred to a second type of blockchain (destination blockchain) “User A 1402 may have control of Token A 1416 (e.g., an illustrative example of a digital asset) on the first blockchain network 1408 and User B may have control of Token B on a second blockchain network and the users may jointly execute a protocol to exchange those tokens. Tokens described in this context may refer to digital assets which may be controlled by a party, and control of which may be transferred to other entities through blockchain transactions.”; para 0042 discloses protocols are being used for two different type of blockchains (cross-blockchain) communication/transmission “A cross-chain transaction may refer to an exchange of a digital asset or token on a first blockchain for a digital asset or token on a second blockchain. In at least some embodiments, a protocol that implements cross-chain transaction is robust to failure, which can include the refusal of any party of a cross-chain transaction to operate according to the protocol”);
and in response to receiving the request, causing the data item to be sent to the destination node via a set of off-chain entities, selected for both the source blockchain and the destination blockchain(Chen, Fig. 17 and para 0185 disclose token (data item) of two different type of blockchains (cross-chain) can be transferred on off-chain network “User A 1702 and User B 1704 may connect to each other (e.g., on or off of a blockchain network) and jointly agree to make an exchange of Token A for Token B. A cross-chain transaction may be initiated based on communications between User A and User B”), to implement a validation task to enable the transmission of the data item from the source blockchain to the destination blockchain in accordance with a set of communication protocol settings(Chen, para 0239 discloses cross-chain transaction validation using consensus protocol “In some cases, a condition for the coordinator approving withdrawal of a tether is that the sender User A signed a cross-chain exchange blockchain transaction 2412 on a remote blockchain network—accordingly, resolving this type of dispute case may involve validating the execution status of the cross-chain exchange blockchain transaction 2412 that was purported to have occurred on blockchain network 2404 (e.g., the remote blockchain). The validation may be performed by voting (e.g., public voting to reach consensus)”),
But Chen does not explicitly teach wherein the set of communication protocol settings comprises: a validation library that defines the validation task to enable the transmission of the data item from the source blockchain to the destination blockchain, wherein the validation library is selected based on at least one of a trust characteristic or a cost characteristic, and wherein the source blockchain and the destination blockchain are each configured with the validation library; and a selection of the set of off-chain entities.
However, in the same field of endeavor of blockchain management Olson teaches wherein the set of communication protocol settings comprises: a validation library that defines the validation task to enable the transmission of the data item from the source blockchain to the destination blockchain, wherein the validation library is selected based on at least one of a trust characteristic or a cost characteristic, and wherein the source blockchain and the destination blockchain are each configured with the validation library; and a selection of the set of off-chain entities(Olson, para 0088 and para 0103 disclose enabling transmission of data block from one domain to another over an off-chain network by validating on both sides using cross-domain endorsing peer or consensus protocol (trust characteristics) “upon receiving a block from the ordering service which includes the validated on-chain content, the same side cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side. Here, the cross-domain content controller may digitally sign and provides the off-chain content to the other side, via the traditional cross-domain solution, and notify the cross-domain endorsing peer who logs it to the shared ledger”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of transaction validation of data content on off-chain transmission of Olsen into off-chain transmission of cross-domain transaction of data item of Chen to produce an expected result of optimizing the blockchain ledger performance during transmission. The modification would be obvious because one of ordinary skill in the art would be motivated to optimize the blockchain ledger performance and storage optimized by storing only a hash or digital signature of a file in the ledger and keeping the file itself off-ledger (Olsen, para 0035).
Regarding Claim 8 (Previously Presented), Chen A method comprising: receiving, by a processing device, a request to send a data item from a source node associated with a source blockchain having a first type to a destination node associated with a destination blockchain having a second type different from the first type by using a communication protocol supporting transmission of the data item from the source blockchain to the destination blockchain (Chen, Fig. 14 and para 0159 disclose first type of blockchain (source blockchain) is getting transferred to a second type of blockchain (destination blockchain) “User A 1402 may have control of Token A 1416 (e.g., an illustrative example of a digital asset) on the first blockchain network 1408 and User B may have control of Token B on a second blockchain network and the users may jointly execute a protocol to exchange those tokens. Tokens described in this context may refer to digital assets which may be controlled by a party, and control of which may be transferred to other entities through blockchain transactions.”; para 0042 discloses protocols are being used for two different type of blockchains (cross-blockchain) communication/transmission “A cross-chain transaction may refer to an exchange of a digital asset or token on a first blockchain for a digital asset or token on a second blockchain. In at least some embodiments, a protocol that implements cross-chain transaction is robust to failure, which can include the refusal of any party of a cross-chain transaction to operate according to the protocol”);
and in response to receiving the request, causing, by the processing device, the data item to be sent to the destination node via a set of off-chain entities, selected for both the source blockchain and the destination blockchain (Chen, Fig. 17 and para 0185 disclose token (data item) of two different type of blockchains (cross-chain) can be transferred on off-chain network “User A 1702 and User B 1704 may connect to each other (e.g., on or off of a blockchain network) and jointly agree to make an exchange of Token A for Token B. A cross-chain transaction may be initiated based on communications between User A and User B”), to implement a validation task to enable the transmission of the data item from the source blockchain to the destination blockchain in accordance with a set of communication protocol settings(Chen, para 0239 discloses cross-chain transaction validation using consensus protocol “In some cases, a condition for the coordinator approving withdrawal of a tether is that the sender User A signed a cross-chain exchange blockchain transaction 2412 on a remote blockchain network—accordingly, resolving this type of dispute case may involve validating the execution status of the cross-chain exchange blockchain transaction 2412 that was purported to have occurred on blockchain network 2404 (e.g., the remote blockchain). The validation may be performed by voting (e.g., public voting to reach consensus)”),
But Chen does not explicitly teach wherein the set of communication protocol settings comprises a validation library that defines the validation task to enable the transmission of the data item from the source blockchain to the destination blockchain, wherein the validation library is selected based on at least one of a trust characteristic or a cost characteristic, and wherein for both the source blockchain and the destination blockchain that defines the validation task, are each configured with the validation library; and a selection of the set of off-chain entities.
However, in the same field of endeavor of blockchain management Olson teaches wherein the set of communication protocol settings comprises a validation library that defines the validation task to enable the transmission of the data item from the source blockchain to the destination blockchain, wherein the validation library is selected based on at least one of a trust characteristic or a cost characteristic, and wherein for both the source blockchain and the destination blockchain that defines the validation task, are each configured with the validation library; and a selection of the set of off-chain entities (Olson, para 0088 and para 0103 disclose enabling transmission of data block from one domain to another over an off-chain network by validating on both sides using cross-domain endorsing peer or consensus protocol (trust characteristics) “upon receiving a block from the ordering service which includes the validated on-chain content, the same side cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side. Here, the cross-domain content controller may digitally sign and provides the off-chain content to the other side, via the traditional cross-domain solution, and notify the cross-domain endorsing peer who logs it to the shared ledger”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of transaction validation of data content on off-chain transmission of Olsen into off-chain transmission of cross-domain transaction of data item of Chen to produce an expected result of optimizing the blockchain ledger performance during transmission. The modification would be obvious because one of ordinary skill in the art would be motivated to optimize the blockchain ledger performance and storage optimized by storing only a hash or digital signature of a file in the ledger and keeping the file itself off-ledger (Olsen, para 0035).
Regarding Claim 15 (Previously Presented), Chen A system comprising (Chen, Fig. 25 discloses system for cross-blockchain exchange with processors, memory and storages): a source node associated with a source blockchain having a first endpoint (Chen, para 0087 discloses association of nodes with endpoints (addressable communication network) for communication “the network includes the Internet and/or other publicly-addressable communications network, as the environment includes a node 606 for receiving requests and serving content in response…..”) of a communication protocol configured in accordance with a set of communication protocol settings, wherein the source blockchain has a first type; a destination node associated with a destination blockchain having a second endpoint (Chen, Fig. 14 and para 0159 disclose first type of blockchain (source blockchain) is getting transferred to a second type of blockchain (destination blockchain) “User A 1402 may have control of Token A 1416 (e.g., an illustrative example of a digital asset) on the first blockchain network 1408 and User B may have control of Token B on a second blockchain network and the users may jointly execute a protocol to exchange those tokens. Tokens described in this context may refer to digital assets which may be controlled by a party, and control of which may be transferred to other entities through blockchain transactions.”; para 0042 discloses protocols are being used for two different type of blockchains (cross-blockchain) communication/transmission “A cross-chain transaction may refer to an exchange of a digital asset or token on a first blockchain for a digital asset or token on a second blockchain. In at least some embodiments, a protocol that implements cross-chain transaction is robust to failure, which can include the refusal of any party of a cross-chain transaction to operate according to the protocol”) of the communication protocol configured in accordance with the set of communication protocol settings, wherein the destination blockchain has a second type different from the first type(Chen, para 0159 further discloses transferring token between two different type of blockchains by jointly executing protocol “User A 1402 may have control of Token A 1416 (e.g., an illustrative example of a digital asset) on the first blockchain network 1408 and User B may have control of Token B on a second blockchain network and the users may jointly execute a protocol to exchange those tokens”),
and wherein the source node comprises a processing device, operatively coupled to a memory, to perform operations comprising: receiving a request to send a data item from the source node to the destination node associated with a destination blockchain using the communication protocol(Chen, para 0107 discloses request for blockchain transaction “The migrate account blockchain transaction may be broadcasted to nodes of a blockchain network that validate the account migrate blockchain transaction, execute the requested migration”; para 0042 further discloses transaction is being performed according to protocol from source to destination “A cross-chain transaction may refer to an exchange of a digital asset or token on a first blockchain for a digital asset or token on a second blockchain. In at least some embodiments, a protocol that implements cross-chain transaction is robust to failure, which can include the refusal of any party of a cross-chain transaction to operate according to the protocol””);
and in response to receiving the request, causing the data item to be sent to the destination node via the set of off-chain entities (Chen, Fig. 17 and para 0185 disclose token (data item) of two different type of blockchains (cross-chain) can be transferred on off-chain network “User A 1702 and User B 1704 may connect to each other (e.g., on or off of a blockchain network) and jointly agree to make an exchange of Token A for Token B. A cross-chain transaction may be initiated based on communications between User A and User B”) to implement a validation task defined by the validation library to enable transmission of the data item from the source blockchain to the destination blockchain in accordance with the set of communication protocol settings (Chen, para 0239 discloses cross-chain transaction validation using consensus protocol “In some cases, a condition for the coordinator approving withdrawal of a tether is that the sender User A signed a cross-chain exchange blockchain transaction 2412 on a remote blockchain network—accordingly, resolving this type of dispute case may involve validating the execution status of the cross-chain exchange blockchain transaction 2412 that was purported to have occurred on blockchain network 2404 (e.g., the remote blockchain). The validation may be performed by voting (e.g., public voting to reach consensus)”).
But Chen does not explicitly teach wherein the set of communication protocol settings comprises a validation library selected for both based on at least one of a trust characteristic or a cost characteristic, and wherein the source blockchain and the destination blockchain each are configured with the validation library; and a set of off-chain entities, communicably coupled between the source node and the destination node, selected for both the source blockchain and the destination blockchain, wherein the set of communication protocol settings further comprises a selection of the set of off-chain entities;
However, in the same field of endeavor of blockchain management Olson teaches wherein the set of communication protocol settings comprises a validation library selected for both based on at least one of a trust characteristic or a cost characteristic, and wherein the source blockchain and the destination blockchain each are configured with the validation library; and a set of off-chain entities, communicably coupled between the source node and the destination node, selected for both the source blockchain and the destination blockchain, wherein the set of communication protocol settings further comprises a selection of the set of off-chain entities (Olson, para 0088 and para 0103 disclose enabling transmission of data block from one domain to another over an off-chain network by validating on both sides using cross-domain endorsing peer or consensus protocol (trust characteristics) “upon receiving a block from the ordering service which includes the validated on-chain content, the same side cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side. Here, the cross-domain content controller may digitally sign and provides the off-chain content to the other side, via the traditional cross-domain solution, and notify the cross-domain endorsing peer who logs it to the shared ledger”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of transaction validation of data content on off-chain transmission of Olsen into off-chain transmission of cross-domain transaction of data item of Chen to produce an expected result of optimizing the blockchain ledger performance during transmission. The modification would be obvious because one of ordinary skill in the art would be motivated to optimize the blockchain ledger performance and storage optimized by storing only a hash or digital signature of a file in the ledger and keeping the file itself off-ledger (Olsen, para 0035).
Claim 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Chen, Tian et al (PGPUB Document No. 20210119807), hereafter referred as to “Chen”, in view of Olson, Timothy et al (PGPUB Document No. 20230036439), hereafter, referred to as “Olson”, in further view of Thapar, Singh et al(PGPUB Document No. 20200142884), hereafter, referred to as “Thapar”.
Regarding, claim 2(Original), Chen and Olsen teach all the limitations of claim 1 and Olsen further teaches wherein the set of off-chain entities comprises a set of trust entities selected for both the source blockchain and the destination blockchain to implement the validation task(Olson, para 0088 and para 0103 disclose enabling transmission of data block from one domain to another over an off-chain network by validating on both sides using cross-domain endorsing peer or consensus protocol (trust characteristics) “upon receiving a block from the ordering service which includes the validated on-chain content, the same side cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side. Here, the cross-domain content controller may digitally sign and provides the off-chain content to the other side, via the traditional cross-domain solution, and notify the cross-domain endorsing peer who logs it to the shared ledger”),
But Chen and Olsen don’t explicitly teach and a set of executors selected for both the source blockchain and the destination blockchain to implement a set of non-validation tasks separate from the validation task.
However, in the same field of endeavor of block chain transaction Thapar teaches and a set of executors selected for both the source blockchain and the destination blockchain to implement a set of non-validation tasks separate from the validation task (Thapar, para 0021 discloses processing of non-validating task differently than validating tasks for trust entities “The technique also provides an ability for trusted recall including retrieving candidate information from trusted storage (e.g., a cryptographically encrypted data repository) and for displaying cryptographically-authenticated information in a special way that separates it from non-verified, non-blockchain”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of separating the non-validating tasks form validation tasks of Thapar into off-chain transaction of blockchain of Chen and Olsen to produce an expected result of separating validation tasks. The modification would be obvious because one of ordinary skill in the art would be motivated to cut down costs of verifying users’ information by preserving users’ information in a trusted way using blockchain(Thapar, para 0002-003).
Regarding, claim 9(Original), Chen and Olsen teach all the limitations of claim 8 and Olsen further teaches wherein the set of off-chain entities comprises a set of trust entities selected for both the source blockchain and the destination blockchain to implement the validation task(Olson, para 0088 and para 0103 disclose enabling transmission of data block from one domain to another over an off-chain network by validating on both sides using cross-domain endorsing peer or consensus protocol (trust characteristics) “upon receiving a block from the ordering service which includes the validated on-chain content, the same side cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side. Here, the cross-domain content controller may digitally sign and provides the off-chain content to the other side, via the traditional cross-domain solution, and notify the cross-domain endorsing peer who logs it to the shared ledger”),
But Chen and Olsen don’t explicitly teach and a set of executors selected for both the source blockchain and the destination blockchain to implement a set of non-validation tasks separate from the validation task.
However, in the same field of endeavor of block chain transaction Thapar teaches and a set of executors selected for both the source blockchain and the destination blockchain to implement a set of non-validation tasks separate from the validation task (Thapar, para 0021 discloses processing of non-validating task differently than validating tasks for trust entities “The technique also provides an ability for trusted recall including retrieving candidate information from trusted storage (e.g., a cryptographically encrypted data repository) and for displaying cryptographically-authenticated information in a special way that separates it from non-verified, non-blockchain”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of separating the non-validating tasks form validation tasks of Thapar into off-chain transaction of blockchain of Chen and Olsen to produce an expected result of separating validation tasks. The modification would be obvious because one of ordinary skill in the art would be motivated to cut down costs of verifying users’ information by preserving users’ information in a trusted way using blockchain(Thapar, para 0002-003).
Regarding, claim 16(Original), Chen and Olsen teach all the limitations of claim 15 and Olsen further teaches wherein the set of off-chain entities comprises a set of trust entities selected for both the source blockchain and the destination blockchain to implement the validation task(Olson, para 0088 and para 0103 disclose enabling transmission of data block from one domain to another over an off-chain network by validating on both sides using cross-domain endorsing peer or consensus protocol (trust characteristics) “upon receiving a block from the ordering service which includes the validated on-chain content, the same side cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side. Here, the cross-domain content controller may digitally sign and provides the off-chain content to the other side, via the traditional cross-domain solution, and notify the cross-domain endorsing peer who logs it to the shared ledger”),
But Chen and Olsen don’t explicitly teach and a set of executors selected for both the source blockchain and the destination blockchain to implement a set of non-validation tasks separate from the validation task.
However, in the same field of endeavor of block chain transaction Thapar teaches and a set of executors selected for both the source blockchain and the destination blockchain to implement a set of non-validation tasks separate from the validation task (Thapar, para 0021 discloses processing of non-validating task differently than validating tasks for trust entities “The technique also provides an ability for trusted recall including retrieving candidate information from trusted storage (e.g., a cryptographically encrypted data repository) and for displaying cryptographically-authenticated information in a special way that separates it from non-verified, non-blockchain”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of separating the non-validating tasks form validation tasks of Thapar into off-chain transaction of blockchain of Chen and Olsen to produce an expected result of separating validation tasks. The modification would be obvious because one of ordinary skill in the art would be motivated to cut down costs of verifying users’ information by preserving users’ information in a trusted way using blockchain(Thapar, para 0002-003).
Claim 3-4, 10-12 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Chen, Tian et al (PGPUB Document No. 20210119807), hereafter referred as to “Chen”, in view of Olson, Timothy et al (PGPUB Document No. 20230036439), hereafter, referred to as “Olson”, in further view of Gaur, Nitin et al (PGPUB Document No. 20210350343), hereafter, referred to as “Gaur”.
Regarding Claim 3 (Original), Chen and Olson teach all the limitations of claim 1 But don’t explicitly teach wherein the request comprises a set of parameters comprising a transaction identifier corresponding to the transaction, a global identifier corresponding to the destination blockchain, and a user payload obtaining a packet and auxiliary information.
However, in the same field of endeavor of blockchain management Gaur teaches wherein the request comprises a set of parameters comprising a transaction identifier corresponding to the transaction, a global identifier corresponding to the destination blockchain, and a user payload obtaining a packet and auxiliary information(Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; para 0071 further discloses user payload such as users’ identifier, account ids, transfer value etc. “The message data may include values for country of origin, destination, account IDs, sender ID, receiver ID, and the like, of the off-chain transfer of value” and auxiliary information such as validation to compliance information “the RFI 140 may perform a compliance verification on the data within the compliance request from the OFI 130” ).
Using the broadest reasonable interpretation consistent with the specification (paragraph 0045) as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “user payload obtaining a packet” to mean users’ related data to be sent and, “auxiliary information” to mean validation information.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of transaction validation of Gour into transaction between different type of source and destination nodes of Chen and Olsen to produce an expected result of falsified information and hacks by using immutable blockchain. The modification would be obvious because one of ordinary skill in the art would be motivated to provide distributed and decentralized access to the immutable ledger through non-trusting participants by establishing consensus requirement among non-trusting participants(Gour, para 001).
Regarding claim 4(Original), Chen, Olsen and Gaur teach all the limitations of claim 3 and Olsen further teaches wherein: the set of off-chain entities comprises a transaction proof entity and a block header entity the set of parameters further comprises a set of transaction proof entity arguments(Olsen, para 0083 discloses transaction proof-of-work derived from header “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”; where para 0088 discloses validation for off-chain transaction “cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side”);
Gour further teaches and the operations further comprise obtaining a packet comprising the global identifier and the user payload, and auxiliary information comprising the transaction identifier (Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; para 0071 further discloses user payload such as users’ identifier, account ids, transfer value etc. “The message data may include values for country of origin, destination, account IDs, sender ID, receiver ID, and the like, of the off-chain transfer of value” and auxiliary information such as validation to compliance information “the RFI 140 may perform a compliance verification on the data within the compliance request from the OFI 130” ) and the set of transaction proof entity arguments(Gour, para 0088 further discloses transaction containing transaction arguments “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function….” ).
Regarding Claim 10 (Original), Chen and Olson teach all the limitations of claim 8 But don’t explicitly teach wherein the request comprises a set of parameters comprising a transaction identifier corresponding to the transaction, a global identifier corresponding to the destination blockchain, and a user payload obtaining a packet and auxiliary information.
However, in the same field of endeavor of blockchain management Gaur teaches wherein the request comprises a set of parameters comprising a transaction identifier corresponding to the transaction, a global identifier corresponding to the destination blockchain, and a user payload obtaining a packet and auxiliary information (Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; para 0071 further discloses user payload such as users’ identifier, account ids, transfer value etc. “The message data may include values for country of origin, destination, account IDs, sender ID, receiver ID, and the like, of the off-chain transfer of value” and auxiliary information such as validation to compliance information “the RFI 140 may perform a compliance verification on the data within the compliance request from the OFI 130” ).
Using the broadest reasonable interpretation consistent with the specification (paragraph 0045) as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “user payload obtaining a packet” to mean users’ related data to be sent and, “auxiliary information” to mean validation information.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of transaction validation of Gour into transaction between different type of source and destination nodes of Chen and Olsen to produce an expected result of falsified information and hacks by using immutable blockchain. The modification would be obvious because one of ordinary skill in the art would be motivated to provide distributed and decentralized access to the immutable ledger through non-trusting participants by establishing consensus requirement among non-trusting participants(Gour, para 001).
Regarding claim 11(Original), Chen, Olsen and Gaur teach all the limitations of claim 10 and Olsen further teaches wherein: the set of off-chain entities comprises a transaction proof entity and a block header entity; the set of parameters further comprises a set of transaction proof entity arguments (Olsen, para 0083 discloses transaction proof-of-work derived from header “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”; where para 0088 discloses validation for off-chain transaction “cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side”);
Gour further teaches and the method further comprises obtaining, by the processing device, a packet comprising the global identifier and the user payload, and auxiliary information comprising the transaction identifier and the set of transaction proof entity arguments (Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; para 0071 further discloses user payload such as users’ identifier, account ids, transfer value etc. “The message data may include values for country of origin, destination, account IDs, sender ID, receiver ID, and the like, of the off-chain transfer of value” and auxiliary information such as validation to compliance information “the RFI 140 may perform a compliance verification on the data within the compliance request from the OFI 130” ) and the set of transaction proof entity arguments(Gour, para 0088 further discloses transaction containing transaction arguments “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function….” ).
Regarding, claim 12(Original), Chen, Olsen and Gaur teach all the limitations of claim 10 Chen further teaches the set of off-chain entities comprises a transaction proof entity and a block header entity, and wherein causing the data item to be sent to the destination node via the set of off-chain entities further comprises (Chen, Fig. 17 and para 0185 disclose token (data item) of two different type of blockchains (cross-chain) can be transferred on off-chain network “User A 1702 and User B 1704 may connect to each other (e.g., on or off of a blockchain network) and jointly agree to make an exchange of Token A for Token B. A cross-chain transaction may be initiated based on communications between User A and User B”):
Olsen further teaches causing the transaction proof entity to obtain a transaction proof for the transaction, and causing the block header entity to obtain a block header for a current block on the source blockchain to be sent to the destination node (Olsen, and para 0083 further discloses transaction proof-of-work derived from header of the concerned block (current) “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”).
Regarding Claim 17 (Original), Chen and Olson teach all the limitations of claim 15 but don’t explicitly teach wherein the request comprises a set of parameters comprising a transaction identifier corresponding to the transaction, a global identifier corresponding to the destination blockchain, and a user payload obtaining a packet and auxiliary information.
However, in the same field of endeavor of blockchain management Gaur teaches wherein the request comprises a set of parameters comprising a transaction identifier corresponding to the transaction, a global identifier corresponding to the destination blockchain, and a user payload obtaining a packet and auxiliary information (Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; para 0071 further discloses user payload such as users’ identifier, account ids, transfer value etc. “The message data may include values for country of origin, destination, account IDs, sender ID, receiver ID, and the like, of the off-chain transfer of value” and auxiliary information such as validation to compliance information “the RFI 140 may perform a compliance verification on the data within the compliance request from the OFI 130” ).
Using the broadest reasonable interpretation consistent with the specification (paragraph 0045) as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “user payload obtaining a packet” to mean users’ related data to be sent and, “auxiliary information” to mean validation information.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of transaction validation of Gour into transaction between different type of source and destination nodes of Chen and Olsen to produce an expected result of falsified information and hacks by using immutable blockchain. The modification would be obvious because one of ordinary skill in the art would be motivated to provide distributed and decentralized access to the immutable ledger through non-trusting participants by establishing consensus requirement among non-trusting participants(Gour, para 001).
Regarding claim 18(Original), Chen, Olsen and Gaur teach all the limitations of claim 17 and Olsen further teaches wherein: the set of off-chain entities comprises a transaction proof entity and a block header entity; the set of parameters further comprises a set of transaction proof entity arguments (Olsen, para 0083 discloses transaction proof-of-work derived from header “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”; where para 0088 discloses validation for off-chain transaction “cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side”);
Gour further teaches and the operations further comprise obtaining a packet comprising the global identifier and the user payload, and auxiliary information comprising the transaction identifier(Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; para 0071 further discloses user payload such as users’ identifier, account ids, transfer value etc. “The message data may include values for country of origin, destination, account IDs, sender ID, receiver ID, and the like, of the off-chain transfer of value” and auxiliary information such as validation to compliance information “the RFI 140 may perform a compliance verification on the data within the compliance request from the OFI 130” ) and the set of transaction proof entity arguments (Gour, para 0088 further discloses transaction containing transaction arguments “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function….” );
Chen further teaches and causing the data item to be sent to the destination node via the set of off-chain entities further comprises (Chen, Fig. 17 and para 0185 disclose token (data item) of two different type of blockchains (cross-chain) can be sent/transferred on off-chain network “User A 1702 and User B 1704 may connect to each other (e.g., on or off of a blockchain network) and jointly agree to make an exchange of Token A for Token B. A cross-chain transaction may be initiated based on communications between User A and User B”)
Olsen further teaches causing the transaction proof entity to obtain a transaction proof for the transaction, and causing the block header entity to obtain a block header for a current block on the source blockchain to be sent to the destination node(Olsen, and para 0083 further discloses transaction proof-of-work derived from header of the concerned block (current) “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”).
Claim 5-6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Chen, Tian et al (PGPUB Document No. 20210119807), hereafter referred as to “Chen”, in view of Olson, Timothy et al (PGPUB Document No. 20230036439), hereafter, referred to as “Olson”, in further view of Gaur, Nitin et al (PGPUB Document No. 20210350343), hereafter, referred to as “Gaur”, in further view of Feng, Haoming et al(PGPUB Document No. 20230090296), hereafter, referred to as “Feng”.
Regarding, claim 5(Original), Chen, Olsen and Gaur teach all the limitations of claim 3 Olsen further teaches wherein the set of off-chain entities comprises a transaction proof entity and a block header entity, and wherein causing the data item to be sent to the destination node via the set of off-chain entities further comprises (Olson, para 0088 and para 0103 disclose enabling transmission of data block from one domain to another over an off-chain network by validating on both sides using cross-domain endorsing peer or consensus protocol (trust characteristics) “upon receiving a block from the ordering service which includes the validated on-chain content, the same side cross-domain endorsing peer signals the cross-domain content controller to release the validated off-chain content to the cross-domain content controller on the other side. Here, the cross-domain content controller may digitally sign and provides the off-chain content to the other side, via the traditional cross-domain solution, and notify the cross-domain endorsing peer who logs it to the shared ledger”; and para 0083 further discloses transaction proof-of-work derived from header “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”): and causing the transaction proof entity to obtain a transaction proof for the transaction, and causing the block header entity to obtain a block header for a current block on the source blockchain to be sent to the destination node(Olsen, and para 0083 further discloses transaction proof-of-work derived from header of the concerned block (current) “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”).
But Chen, Olsen and Gaur don’t explicitly teach determining that the block header is to be sent;
However, in the same field of endeavor of block chain transaction Feng teaches determining that the block header is to be sent (Feng, para 0037 discloses identifying block header for verification which is later getting sent for transaction execution “the block generation node 20C may search the block header chain 2 b shown in FIG. 2 for a block header (e.g., block header 100 in the block header chain 2 b ) matching the block identifier in the first block header ……. when the first check result indicates a successful check, the block generation node 20C may determine that the transaction service corresponding to the transaction 2 x can be executed”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of identifying block header in blockchain of Feng into off-chain transaction of blockchain of Chen, Olsen and Gaur to send identified block header for blockchain transaction. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the efficiency of legitimacy check by checking the first state snapshot of the second block header’s transaction verification information(Feng, para 0010).
Regarding claim 6(Original), Chen, Olsen, Gaur and Feng teach all the limitation of claim 5 and Gaur further teaches wherein the operations further comprise a notification comprising the transaction identifier and the global identifier, and wherein causing the data item to be sent to the destination node via the set of off-chain entities further comprises (Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; Fig. 1B and para 0063 receiving a request to send from originator (130) to receiver (140) for off-chain transaction of value settlement via blockchain “The send service 121 may capture custom messages that are dedicated to performing the settlement of an off-chain transaction on the blockchain ledger 126” )
Feng further teaches determining that the block header is to be sent to the destination blockchain in response to receiving the notification(Feng, Fig.2 and para 0037 discloses identifying block header in response to receiving notification of transaction (2x) “the block generation node 20C may search the block header chain 2 b shown in FIG. 2 for a block header (e.g., block header 100 in the block header chain 2 b ) matching the block identifier in the first block header ……. when the first check result indicates a successful check, the block generation node 20C may determine that the transaction service corresponding to the transaction 2 x can be executed”).
Regarding claim 13(Original), Chen, Olsen and Gaur teach all the limitation of claim 12 and Gaur further teaches further comprising receiving, by the processing device, a notification comprising the transaction identifier and the global identifier, wherein causing the data item to be sent to the destination node via the set of off-chain entities further comprises (Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; Fig. 1B and para 0063 receiving a request to send from originator (130) to receiver (140) for off-chain transaction of value settlement via blockchain “The send service 121 may capture custom messages that are dedicated to performing the settlement of an off-chain transaction on the blockchain ledger 126” ).
But Chen, Olsen and Gaur don’t explicitly teach determining that the block header is to be sent to the destination blockchain in response to receiving the notification.
However, in the same field of endeavor of block chain transaction Feng teaches
determining that the block header is to be sent to the destination blockchain in response to receiving the notification(Feng, Fig.2 and para 0037 discloses identifying block header in response to receiving notification of transaction (2x) “the block generation node 20C may search the block header chain 2 b shown in FIG. 2 for a block header (e.g., block header 100 in the block header chain 2 b ) matching the block identifier in the first block header ……. when the first check result indicates a successful check, the block generation node 20C may determine that the transaction service corresponding to the transaction 2 x can be executed”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of identifying block header in blockchain of Feng into off-chain transaction of blockchain of Chen, Olsen and Gaur to send identified block header for blockchain transaction. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the efficiency of legitimacy check by checking the first state snapshot of the second block header’s transaction verification information(Feng, para 0010).
Regarding claim 19(Original), Chen, Olsen and Gaur teach all the limitation of claim 18 and Gaur further teaches wherein the operations further comprise a notification comprising the transaction identifier and the global identifier, and wherein causing the data item to be sent to the destination node via the set of off-chain entities further comprises(Gaur, para 0067 teaches message containing source and destination transaction identifiers “the anchor service 125 may store messages that pass through the host system 120 between the OFI 130 and the RFI 140 on the blockchain ledger 126. For example, the anchor service 125 may extract data such as transaction details of the off-chain transaction, identifiers of the users/PANs involved in the off-chain transaction, identifiers of the OFI 130 and the RFI 140, wallet identifiers, county of origin, country of destination, exchange rates, timestamps, and the like”; Fig. 1B and para 0063 receiving a request to send from originator (130) to receiver (140) for off-chain transaction of value settlement via blockchain “The send service 121 may capture custom messages that are dedicated to performing the settlement of an off-chain transaction on the blockchain ledger 126” ).
But Chen, Olsen and Gaur don’t explicitly teach determining that the block header is to be sent to the destination blockchain in response to receiving the notification.
However, in the same field of endeavor of block chain transaction Feng teaches
determining that the block header is to be sent to the destination blockchain in response to receiving the notification (Feng, Fig.2 and para 0037 discloses identifying block header in response to receiving notification of transaction (2x) “the block generation node 20C may search the block header chain 2 b shown in FIG. 2 for a block header (e.g., block header 100 in the block header chain 2 b ) matching the block identifier in the first block header ……. when the first check result indicates a successful check, the block generation node 20C may determine that the transaction service corresponding to the transaction 2 x can be executed”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of identifying block header in blockchain of Feng into off-chain transaction of blockchain of Chen, Olsen and Gaur to send identified block header for blockchain transaction. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the efficiency of legitimacy check by checking the first state snapshot of the second block header’s transaction verification information(Feng, para 0010).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Chen, Tian et al (PGPUB Document No. 20210119807), hereafter referred as to “Chen”, in view of Olson, Timothy et al (PGPUB Document No. 20230036439), hereafter, referred to as “Olson”, in further view of Gaur, Nitin et al (PGPUB Document No. 20210350343), hereafter, referred to as “Gaur”, in view of Feng, Haoming et al(PGPUB Document No. 20230090296), hereafter, referred to as “Feng”, in further view of Makrides, Frank(PGPUB Document No. 20220141021), hereafter, referred to as “Makrides”.
Regarding claim 7(Original), Chen, Olson, Gour and Feng teach all the limitation of claim 5 and Olson further teaches wherein causing the block header entity to obtain the block header and the transaction proof entity to obtain the transaction proof for the transaction comprises(Olson, para 0083 discloses transaction proof-of-work derived from header “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”).
But Chen, Olson, Gour and Feng don’t explicitly teach sending the global identifier and a block identifier to the block header entity and sending the packet and the auxiliary information to the transaction proof entity.
However, in the same field of endeavor of blockchain transaction Makrides teaches sending the global identifier and a block identifier to the block header entity and sending the packet and the auxiliary information to the transaction proof entity (Makrides, para 0012-0013 discloses sending transaction with block header identifier, with transaction information (packet/message) and auxiliary or validation information “the ledger may be further configured for a validation of the transaction by at least one of the sender or the receiver using a method including (1) receiving, over the network, the first and second zero knowledge proofs…sending the transaction blinding and the transacted amount to the third party. The third party may then verify that the first and second new commitments correspond to the transaction blinding and the transacted amount; while the first and second account balances are concealed from the third party. In certain embodiments, the third party may provide payment dispute resolution”; where Gaur in para 0067 teaches message containing source and destination identifiers).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of sending block and validation information for proof/validation of Makrides into off-chain transaction of blockchain of Chen, Olson, Gour and Feng to send identified block header for blockchain transaction. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the transaction security in blockchain by concealing account balances using multi-chain directed acrylic graph (Makrides, para 0007).
Claim 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chen, Tian et al (PGPUB Document No. 20210119807), hereafter referred as to “Chen”, in view of Olson, Timothy et al (PGPUB Document No. 20230036439), hereafter, referred to as “Olson”, in further view of Gaur, Nitin et al (PGPUB Document No. 20210350343), hereafter, referred to as “Gaur”, in further view of Makrides, Frank(PGPUB Document No. 20220141021), hereafter, referred to as “Makrides”.
Regarding claim 14(Original), Chen, Olsen and Gaur teaches all the limitation of claim 12 and Gaur further teaches wherein causing the block header entity to obtain the block header and the transaction proof entity to obtain the transaction proof for the transaction comprises (Olsen, para 0083 discloses transaction proof-of-work derived from header “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”).
But Chen, Olsen and Gaur don’t explicitly teach sending the global identifier and a block identifier to the block header entity and sending the packet and the auxiliary information to the transaction proof entity.
However, in the same field of endeavor of blockchain transaction Makrides teaches sending the global identifier and a block identifier to the block header entity and sending the packet and the auxiliary information to the transaction proof entity (Makrides, para 0012-0013 discloses sending transaction with block header identifier, with transaction information (packet/message) and auxiliary or validation information “the ledger may be further configured for a validation of the transaction by at least one of the sender or the receiver using a method including (1) receiving, over the network, the first and second zero knowledge proofs…sending the transaction blinding and the transacted amount to the third party. The third party may then verify that the first and second new commitments correspond to the transaction blinding and the transacted amount; while the first and second account balances are concealed from the third party. In certain embodiments, the third party may provide payment dispute resolution”; where Gaur in para 0067 teaches message containing source and destination identifiers).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of sending block and validation information for proof/validation of Makrides into off-chain transaction of blockchain of Chen, Olsen and Gaur to send identified block header for blockchain transaction. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the transaction security in blockchain by concealing account balances using multi-chain directed acrylic graph (Makrides, para 0007).
Regarding claim 20 (Original), Chen, Olsen and Gaur teaches all the limitation of claim 18 and Olsen further teaches wherein causing the block header entity to obtain the block header and the transaction proof entity to obtain the transaction proof for the transaction comprises(Olsen, para 0083 further discloses transaction proof-of-work derived from header “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header”).
But Chen, Olsen and Gaur don’t explicitly teach sending the global identifier and a block identifier to the block header entity and sending the packet and the auxiliary information to the transaction proof entity.
However, in the same field of endeavor of blockchain transaction Makrides teaches sending the global identifier and a block identifier to the block header entity and sending the packet and the auxiliary information to the transaction proof entity(Makrides, para 0012-0013 discloses sending transaction with block header identifier, with transaction information (packet/message) and auxiliary or validation information “the ledger may be further configured for a validation of the transaction by at least one of the sender or the receiver using a method including (1) receiving, over the network, the first and second zero knowledge proofs…sending the transaction blinding and the transacted amount to the third party. The third party may then verify that the first and second new commitments correspond to the transaction blinding and the transacted amount; while the first and second account balances are concealed from the third party. In certain embodiments, the third party may provide payment dispute resolution”; where Gaur in para 0067 teaches message containing source and destination identifiers).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of sending block and validation information for proof/validation of Makrides into off-chain transaction of blockchain of Chen, Olsen and Gaur to send identified block header for blockchain transaction. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the transaction security in blockchain by concealing account balances using multi-chain directed acrylic graph(Makrides, para 0007).
Response to Arguments
I. 35 U.S.C §103
The crux of the applicant argument presented through page 9-14 of REMARKS is “it is clear from the other above-cited portions of Olson that its validation tasks are performed to verify that on-chain or off-chain content satisfies a cross-domain security policy between different security domains defined for a single blockchain network, or a single blockchain. The security domains of Olson are not different blockchains or blockchain networks. There is no notion in Olson of a cross-chain transaction of a data item (e.g., its on-chain or off-chain content) between two different blockchains, such as the source blockchain and the destination blockchain recited in claim 1. To that end, any validation tasks of Olson are not being performed "to enable the transmission of the
data item from the source blockchain to the destination blockchain" as recited in claim 1, at least because Olson's security domains are not blockchains or blockchain networks”.
Applicant above mentioned arguments have been fully considered but the examiner respecify disagrees for following reasons;
Firstly, Olsen in paragraph 0059 explicitly discloses that cross-domain endorsement or validation policy can be used to check cross-chain (i.e. different blockchain network) endorsing peer and, where it checks off-chain or on-chain data file or transaction as following “the cross-domain endorsement policy 122 executed by the ordering service 120 may be used to check that the trusted cross-chain endorsing peer (111 for a high-to-low flow and 131 for a low-to-high flow) has endorsed the on-chain and off-chain data file and any other cross-domain specific requirements”.
Secondly, paragraph 0059 further discloses consensus protocol for endorsement is based on trust. Therefore, Olsen in view of Chen teaches the argued limitations.
Regarding claims dependent on independent claim 1, 8 and 16, no additional arguments are presented other than discussed above. Therefore, the examiner maintains the rejection mailed on 11/20/2025.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULLAH A DAUD whose telephone number is (469)295-9283. The examiner can normally be reached M~F: 9:30 am~6:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amy Ng can be reached at 571-270-1698. 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.
/ABDULLAH A DAUD/Examiner, Art Unit 2164
/AMY NG/Supervisory Patent Examiner, Art Unit 2164