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 .
Status of Claims
This is first office action on the merits in response to application filed on 03/14/2025.
Claims 1-20 are currently pending and have been examined.
Priority
Applicant's claim for the benefit of PCT Application No. PCT/CN2023/121057 filed on 09/25/2023 is acknowledged. Acknowledgment is made of applicant's claim for foreign priority based on an application filed in PEOPLE'S REPUBLIC OF CHINA on 01/06/2023. It is noted, however, that applicant has not filed a certified copy of the CN202310019954.6 application as required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/14/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 102(a)(2)
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 1-3 and 18-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Qiu (WO 2024103854).
Regarding Claims 1, 18, and 20, Qui teaches acquiring a cross-blockchain transaction processing request from the source blockchain network by the first interface node, and distributing the cross-blockchain transaction processing request to the first number of relays (Paragraphs 0071, 0074-0075, 0081, and 0083 teach receiving a signature request sent by a first cross-chain gateway, and determining a cross-chain transaction request corresponding to the signature request; the second cross-chain gateway is used to receive the cross-chain transaction request and transmit the cross-chain transaction request to the relay chain through a preset cross-chain transmission protocol; the relay chain is used to send the cross-chain transaction request to the first cross-chain gateway corresponding to the cross-chain transaction request; receive a signature request sent by a first cross-chain gateway, and determine a cross-chain transaction request corresponding to the signature request; start the relay chain in the cross-chain transaction system; the administrator of the relay chain initiates a proposal to replace the threshold signature; after the administrator votes to pass the proposal, the relay chain is marked as using the threshold signature; after each threshold node in the relay chain is started, the threshold key is generated to obtain the private key share held by each threshold node and the threshold public key that can be calculated from each private key share; the private key share information held by each threshold node is persistently stored in the background database of the cross-chain transaction system); performing a first verification and a signature on the cross-blockchain transaction processing request by the relays to generate sub-signatures (Paragraphs 0076, 0084, 0008, and 0087 teach when receiving a signature request based on the cross-chain transaction request sent by the first cross-chain gateway, performing secure multi-party computation according to the private key share held by the target node in the relay chain, obtaining a target signature; perform secure multi-party computation according to the private key share held by the target node in the relay chain corresponding to the signature request to obtain the target signature; the target signature refers to the signature generated after threshold signature processing; the electronic device can request threshold information from the threshold node in the relay chain after returning the signature request to the local node of the relay chain, generate a target request for starting the signature process of the threshold signature based on the obtained threshold information, and broadcast the target request to each target threshold signature node to obtain the target signature generated after the secure multi-party calculation; when broadcasting, T can be randomly selected from the threshold nodes included in the relay chain as the target node, and the signature request can be sent to the target node, where T can refer to the preset threshold signature threshold value, that is, the consensus node threshold Quorum; then, secure multi-party calculation is performed according to the private key share held by the target node, and the processed signature is verified according to the above threshold public key to obtain the verified target signature; among them, the above threshold information includes the address information of all threshold nodes and the common threshold public key held by each threshold node); generating a first signature of the relay system by the signature aggregation node after obtaining a second number of sub-signatures (Paragraphs 0071, 0089-0091, and 0094 teach performing secure multi-party computation according to the private key share held by the target node in the relay chain corresponding to the signature request to obtain a target signature; according to a preset threshold value, a target threshold node is obtained from the threshold node set included in the relay chain, and a target request corresponding to the signature request is broadcast to the target threshold node, so as to obtain a request result returned by the target threshold node based on the target request; the preset threshold value refers to the threshold signature threshold value mentioned above, which is also the consensus node threshold Quorum (Quorum Size); the target threshold node may refer to a non-local node in the threshold node set, that is, a non-local threshold node (hereinafter referred to as a non-local node; the electronic device first obtains the threshold node set in the relay chain, then randomly selects T as the target threshold nodes, and broadcasts the target notification to the T target threshold nodes, where T refers to the threshold value; the reason for selecting T as the target threshold nodes is to make the number of target threshold nodes meet the minimum consensus requirement); and transmitting the cross-blockchain transaction processing request and the first signature to the target blockchain network such that the target blockchain network performs second verification on the first signature and processes the cross-blockchain transaction processing request, the second number being an integer greater than 1 and smaller than or equal to the first number (Paragraphs 0071, 0077-0078, 0109, and 0112 teach sending the target signature to the destination chain corresponding to the first cross-chain gateway; the first cross-chain gateway is used to send the signature request to the relay chain when receiving the cross-chain transaction request, and when receiving the target signature, sending the target signature to the destination chain; send the target signature to the destination chain corresponding to the first cross-chain gateway, and verify the target signature through the destination chain to obtain a verification result; receive a cross-chain transaction request sent by an application chain, and send the cross-chain transaction request to a first cross-chain gateway through a second cross-chain gateway associated with the application chain, wherein the first cross-chain gateway is associated with a destination chain of the cross-chain transaction request, and the cross-chain transmission protocol corresponding to the first cross-chain gateway is the same as the cross-chain transmission protocol corresponding to the second cross-chain gateway).
Regarding Claim 1, Qiu teaches a method for processing cross-blockchain transactions, applied to a relay system between a source blockchain network and a target blockchain network, the relay system comprising a first interface node, a first number of relays, and a signature aggregation node, the first number being an integer greater than 1 (Paragraph 0080 teaches referring to Figure 3, Figure 3 is a flow chart of a cross-chain transaction method provided in an embodiment of the present application; the cross-chain transaction method may specifically include the following steps 301-304).
Regarding Claim 18, Qiu teaches an electronic device, comprising: a memory operable to store computer-readable instructions; and a processor circuitry operable to read the computer-readable instructions, the processor circuitry when executing the computer-readable instructions is configured to perform operations (Paragraphs 0175-0176 teach an embodiment of the present application further provides an electronic device; Figure 7 shows a structural schematic diagram of the electronic device of the embodiment of the present application; specifically, the electronic device provided by the embodiment of the present application includes a processor 701, and the processor 701 is used to execute the computer program stored in the memory 702 to implement the steps of the cross-chain transaction method in any embodiment; or the processor 701 is used to execute the computer program stored in the memory 702 to implement the functions of each unit in the corresponding embodiment of Figure 6; exemplarily, the computer program may be divided into one or more modules/units, one or more modules/units are stored in the memory 702, and executed by the processor 701 to complete the embodiment of the present application; one or more modules/units may be a series of computer program instruction segments that can complete specific functions, and the instruction segments are used to describe the execution process of the computer program in the computer device).
Regarding Claim 20, Qiu teaches a non-transitory machine-readable media, having instructions stored on the machine-readable media, the instructions configured to, when executed, cause a machine to perform operations (Paragraph 0182 teaches an embodiment of the present application provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the cross-chain transaction method in any embodiment of the present application are executed).
Regarding Claims 2 and 19, Qiu teaches all the limitations of claims 1 and 18 above; and Qiu further teaches wherein the performing the first verification and the signature on the cross-blockchain transaction processing request comprises: performing the first verification on the cross-blockchain transaction processing request by the relays (Paragraphs 0071, 0079, and 0112 teach verifying the target signature through the destination chain to obtain a verification result; if the verification result is verification passed, executing the cross-chain transaction request through the destination chain; the destination chain is used to verify the target signature when receiving it, and execute the transaction request if the verification passes; receive a cross-chain transaction request sent by an application chain, and send the cross-chain transaction request to a first cross-chain gateway through a second cross-chain gateway associated with the application chain, wherein the first cross-chain gateway is associated with a destination chain of the cross-chain transaction request, and the cross-chain transmission protocol corresponding to the first cross-chain gateway is the same as the cross-chain transmission protocol corresponding to the second cross-chain gateway); performing the signature on the cross-blockchain transaction processing request using private key fragments held by the relays to generate the sub-signatures, a quantity of the private key fragments being the first number, the first number of private key fragments being respectively held by the first number of relays, and the first number of private key fragments corresponding to a unique first public key (Paragraph 0114 teaches the electronic device can package the target signature and the cross-chain transaction request and send them to the first cross-chain gateway, and then send them to the destination chain through the first cross-chain gateway; the destination chain verifies the received target signature and cross-chain transaction request through the preset cross-chain proxy contract to obtain the verification result); and the operation that the target blockchain network performs the second verification on the first signature comprises: performing, by the target blockchain network, the second verification on the first signature using the first public key (Paragraphs 0114-0115 teach the destination chain verifies the received target signature and cross-chain transaction request through the preset cross-chain proxy contract to obtain the verification result; if the verification result is passed, the cross-chain transaction request is executed through the destination chain).
Regarding Claim 3, Qiu teaches all the limitations of claim 2 above; and Qiu further teaches wherein the distributing the cross-blockchain transaction processing request to the first number of relays comprises: generating a first private key; generating the first number of private key fragments and the first public key based on the first private key; transmitting the cross-blockchain transaction processing request and the first number of private key fragments to the first number of relays; and publishing the first public key (Paragraph 0083 teaches before executing step 301, the method may further include the following steps: 1. Start the relay chain in the cross-chain transaction system; the administrator of the relay chain initiates a proposal to replace the threshold signature; after the administrator votes to pass the proposal, the relay chain is marked as using the threshold signature; after each threshold node in the relay chain is started, the threshold key is generated to obtain the private key share held by each threshold node and the threshold public key that can be calculated from each private key share; the private key share information held by each threshold node is persistently stored in the background database of the cross-chain transaction system; 2. Deploy the cross-chain proxy contract in the application chain of the cross-chain transaction system, and update the threshold public key in the contract through the threshold public key in step (1.1)).
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 4 is rejected under 35 U.S.C. 103 as being unpatentable over Qiu (WO 2024103854) in view of Mandal (US 20230006835).
Regarding Claims 4, Qiu teaches all the limitations of claim 1 above; however, Qiu does not explicitly teach wherein the cross-blockchain transaction processing request comprises a first identifier of a first service node in the source blockchain network and a second signature of the first service node, and the second signature is generated using a second private key of the first service node; the performing the first verification on the cross-blockchain transaction processing request comprises: acquiring a second public key corresponding to the first identifier; and performing first verification on the second signature using the second public key.
Mandal from same or similar field of endeavor teaches wherein the cross-blockchain transaction processing request comprises a first identifier of a first service node in the source blockchain network and a second signature of the first service node, and the second signature is generated using a second private key of the first service node; the performing the first verification on the cross-blockchain transaction processing request comprises: acquiring a second public key corresponding to the first identifier; and performing first verification on the second signature using the second public key (Paragraphs 0071-0074 teach FIG. 3 illustrates a method of signature verification; obtain a message and a signature; the signature may be generated using a secret key associated with a user; obtain an identifier of the user and a string; the identifier of the user and the string may be obtained from a block of a blockchain; the block of the blockchain may be signed using the secret key; obtain a master public key associated with a master private key; the secret key may be generated based on the master private key. In some embodiments, the secret key may be generated based on signatures generated from a plurality of shares of the master private key and the identifier; one of the plurality of shares of the master private key may be associated with the blockchain; verify the signature using the master public key, the identifier, and the string. In some embodiments, verifying the signature may include determining if the identifier is indicated as invalid).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Qiu to incorporate the teachings of Mandal for the cross-blockchain transaction processing request to comprise a first identifier of a first service node in the source blockchain network and a second signature of the first service node, and the second signature is generated using a second private key of the first service node; the performing the first verification on the cross-blockchain transaction processing request comprises: acquiring a second public key corresponding to the first identifier; and performing first verification on the second signature using the second public key.
There is motivation to combine Mandal into Qiu because the setup procedure may generate a master public key associated with the master secret key such that the master public key and the master secret key may be configured to be used in an asymmetric key encryption scheme. The master public key may be available to all elements in the environment and/or posted on the blockchains of the blockchain networks (Mandal Paragraph 0034).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Qiu (WO 2024103854) in view of Mandal (US 20230006835) in further view of Qu (CN 115250179).
Regarding Claims 5, the combination of Qiu and Mandal teaches all the limitations of claim 4 above; however, the combination not explicitly teach acquiring a verification rule corresponding to the cross-blockchain transaction type; and performing a third verification on the cross-blockchain transaction processing request according to the verification rule.
Qu from same or similar field of endeavor teaches acquiring a verification rule corresponding to the cross-blockchain transaction type; and performing a third verification on the cross-blockchain transaction processing request according to the verification rule (Paragraphs 0078 and 0110-0111 teach the authority module is used for authority management of the cross-chain service, and verifying whether the execution authority of the cross-chain transaction is legal; the relay device may receive a request from the cross-chain transaction client to verify the cross-chain transaction; accordingly, the relay device extracts information such as identification, transaction type and cross-chain transaction version number of the transaction parties from the request, and then based on the information, the operation authority level of the cross-chain transaction parties and whether the cross-chain transaction is legal or not are obtained; verification of the privilege level may be related to the intelligent contract involved in the cross-chain transaction; for example, privilege module may determine the smart contract involved in the cross-chain transaction and the associated privilege requirements based on the cross-chain transaction version and transaction type, and verify whether both parties to the transaction have corresponding privileges; it should be appreciated that the validation of the cross-chain transaction by privilege module may not be limited to validation using the identification of the parties to the transaction, the transaction type, the cross-chain transaction version number, etc., but may be any suitable content; the relay device determines whether the permissions of the first client and the second client meet the requirements of the transaction type; the relay device may determine the level of authority required for the cross-chain transaction, in particular, the operating authority of the business intelligence contract related to the cross-chain transaction, from the transaction type field in the transaction header data; the relay device may verify the cross-chain transaction by comparing the operational rights of the business intelligence contract with the rights of the clients; when the permissions of both parties to the transaction satisfy the permission requirement indicated by the transaction type, it is determined that the transaction verification request was successfully verified; it is determined that the transaction verification request is not verified; further, if either of the first client and the second client is not registered at the relay device 130, the transaction verification request is not verified).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu and Mandal to incorporate the teachings of Qu to acquire a verification rule corresponding to the cross-blockchain transaction type; and perform a third verification on the cross-blockchain transaction processing request according to the verification rule.
There is motivation to combine Qu into the combination of Qiu and Mandal because third-party devices can verify whether the cross-chain transaction is legal by using the content included in the transaction header data (Qu Paragraph 0015).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Qiu (WO 2024103854) in view of Zhang (WO2023088136).
Regarding Claims 6, Qiu teaches all the limitations of claim 1 above; however, Qiu does not explicitly teach wherein the acquiring the cross-blockchain transaction processing request from the source blockchain network comprises: checking a source blockchain of the source blockchain network; and in response to the cross-blockchain transaction processing request block being discovered on the source blockchain, extracting the cross-blockchain transaction processing request from a cross-blockchain transaction processing request block, the cross-blockchain transaction processing request block comprising a second identifier of the relay system and the cross-blockchain transaction processing request.
Zhang from same or similar field of endeavor teaches wherein the acquiring the cross-blockchain transaction processing request from the source blockchain network comprises: checking a source blockchain of the source blockchain network; and in response to the cross-blockchain transaction processing request block being discovered on the source blockchain, extracting the cross-blockchain transaction processing request from a cross-blockchain transaction processing request block, the cross-blockchain transaction processing request block comprising a second identifier of the relay system and the cross-blockchain transaction processing request (Paragraphs 0037 and 0047 teach the resource transfer request information carries the identity of the notary, so that the destination chain can determine the identity of the relay chain according to the identity of the notary, so as to realize the identity trust between the relay chain and the destination chain; therefore, through the embodiment of this application, it can realize the identity trust and intercommunication between the source blockchain, the relay chain and the destination chain, that is, realize the identity trust and intercommunication between the various application chains; in addition, by verifying the cross-chain request information, and passing the verification In the case of the cross-chain request information and the preset threshold ring signature policy, the target resource transfer request information can be obtained, which can prevent the nodes of the relay chain from performing malicious behaviors and cause asset losses, thereby improving security; each cross-chain identity information is provided with a corresponding cross-chain identity identifier (Cross Chain Identity Identifier, CCIID), and the relay chain can locate the storage location of the cross-chain identity information according to the cross-chain identity identifier to obtain Cross-chain identity information).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Qiu to incorporate the teachings of Zhang for the acquiring the cross-blockchain transaction processing request from the source blockchain network to comprise: checking a source blockchain of the source blockchain network; and in response to the cross-blockchain transaction processing request block being discovered on the source blockchain, extracting the cross-blockchain transaction processing request from a cross-blockchain transaction processing request block, the cross-blockchain transaction processing request block comprising a second identifier of the relay system and the cross-blockchain transaction processing request.
There is motivation to combine Zhang into Qiu because the implementation of this application can realize the identity trust and intercommunication between different blockchains so that digital assets can be directly transferred safely between different blockchains (Zhang Paragraph 0037).
Claims 7-14 are rejected under 35 U.S.C. 103 as being unpatentable over Qiu (WO 2024103854) in view of Zhang (WO2023088136) in further view of Beller (US 20230334470).
Regarding Claims 7, the combination of Qiu and Zhang teaches all the limitations of claim 6 above; however, the combination not explicitly teach wherein the source blockchain network comprises a first terminal, an oracle machine, a first service node, and a second interface node, and the cross-blockchain transaction processing request block is recorded to the source blockchain by: receiving the cross-blockchain transaction processing request by the first terminal; estimating, by the oracle machine, resources consumed for processing the cross-blockchain transaction processing request; writing an estimated resource value to the cross-blockchain transaction processing request; generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node; and recording the cross-blockchain transaction processing request block onto the source blockchain by the second interface node.
Beller from same or similar field of endeavor teaches wherein the source blockchain network comprises a first terminal, an oracle machine, a first service node, and a second interface node, and the cross-blockchain transaction processing request block is recorded to the source blockchain by: receiving the cross-blockchain transaction processing request by the first terminal; estimating, by the oracle machine, resources consumed for processing the cross-blockchain transaction processing request; writing an estimated resource value to the cross-blockchain transaction processing request; generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node; and recording the cross-blockchain transaction processing request block onto the source blockchain by the second interface node (Paragraphs 0020 and 0024-0026 teach when the user wants to purchase a good or service or otherwise transact via another blockchain, such as the target chain, he may use an application programming interface (API) or may otherwise transmit a message via network(s) to the delegate on the originating chain to request a transaction on the target chain; determining that the target chain has sufficient gas token liquidity, the delegate may transmit to the delegate a message initiating the transaction on the target chain; an internal relay network comprising the target chain may be configured to determine gas token liquidity. In one example, each node of the target blockchain nodes may communicate a status message (e.g., a heartbeat message) indicating its constituent gas token liquidity upstream and also receive a similar downstream message; in another example, one or more of the target blockchain nodes may be configured to estimate the target chain's gas token liquidity based on previous transactions; the gas token liquidity data may then be communicated over the network to the originating chain; in some other cases, the target chain's gas token liquidity may be determined using an external oracle network; the external oracle network may be a decentralized set of validators that must come to consensus on the target chain's gas token liquidity before providing that data back to the originating chain; based at least in part on receiving the message, the delegate may cause the transaction to occur on the target chain, which may include initiating a new transaction on the target chain and/or creating a blockchain asset associated with the target chain; as part of verifying the transaction, one or more of the originating blockchain node(s) may be mining computing devices that may generate a proof of work, proof of stake, or other consensus (blockchain protocols may specify different consensus means) by finding a solution to a problem or completing a task of some kind first (e.g., typically a complex mathematical function or, in the case of proof of stake, consensus may be reached using validation by those having a largest stake in a cryptocurrency); once a proof of work or proof of stake has been found, other node(s) of the originating blockchain node(s) may add the transaction to the originating chain by verifying that a hash of the new transaction concatenated to the former ledger matches a hash posted by the node that posted the proof of work or proof of stake).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu and Zhang to incorporate the teachings of Beller to acquire a verification rule corresponding to the cross-blockchain transaction type; and perform a third verification on the cross-blockchain transaction processing request according to the verification rule.
There is motivation to combine Beller into the combination of Qiu and Zhang because the security and functionality of assets transferred between blockchains is improved by introducing a novel network of delegates comprising contract-to-contract interfaces instantiated on and between host blockchains. A delegate may be deployed as a smart contract on a blockchain and may include a unique protocol that includes a ruleset and operable functionality. In some cases, the unique protocol may enable the delegate to directly reference a user or asset owner on another (e.g., a target) blockchain. In this way, the delegate may be configured to facilitate inter-blockchain transactions or other communications. Thus, for example, the delegate's functionality may include transferring assets from one user to another. In some cases, such an asset transfer may comprise updating an ownership field (Beller Paragraph 0012).
Regarding Claims 8, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 7 above; and Qiu further teaches wherein the first service node has a first service contract and a first cross-blockchain contract, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request comprises: invoking the first cross-blockchain contract through the first service contract; and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request through the first cross-blockchain contract (Paragraphs 0081-0083 teach start the relay chain in the cross-chain transaction system. The administrator of the relay chain initiates a proposal to replace the threshold signature; after the administrator votes to pass the proposal, the relay chain is marked as using the threshold signature; after each threshold node in the relay chain is started, the threshold key is generated to obtain the private key share held by each threshold node and the threshold public key that can be calculated from each private key share; the private key share information held by each threshold node is persistently stored in the background database of the cross-chain transaction system; deploy the cross-chain proxy contract in the application chain of the cross-chain transaction system, and update the threshold public key in the contract through the threshold public key in step (1.1); receive a signature request sent by a first cross-chain gateway, and determine a cross-chain transaction request corresponding to the signature request; the first cross-chain gateway refers to the cross-chain gateway between the relay chain and the destination chain in the cross-chain transaction system; when the first cross-chain gateway receives the cross-chain transaction request sent by the application chain through the second cross-chain gateway and the relay chain in turn, in order to determine the authenticity of the cross-chain transaction request, it needs to be verified; the first cross-chain gateway can send a signature request to the relay chain and request a signature from the node of the relay chain).
Regarding Claims 9, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 7 above; however, the combination does not explicitly teach wherein the target blockchain network comprises a first verification node and a second service node, and the operation that the target blockchain network performs the second verification on the first signature and processes the cross-blockchain transaction processing request comprises: performing the second verification on the first signature by the first verification node, and notifying the second service node of the cross-blockchain transaction processing request in response to the verification being successful; and processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request.
Beller further teaches wherein the target blockchain network comprises a first verification node and a second service node, and the operation that the target blockchain network performs the second verification on the first signature and processes the cross-blockchain transaction processing request comprises: performing the second verification on the first signature by the first verification node, and notifying the second service node of the cross-blockchain transaction processing request in response to the verification being successful; and processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request (Paragraphs 0049-0052 teach based at least in part on determining that the target chain has sufficient gas token liquidity, the delegate may transmit a message to the delegate associated with the target chain and/or node(s) participating in a delegate network blockchain; the message may be a new transaction on the delegate network blockchain and may be readable by the delegate, such as when the target chain implements a virtual machine that is supported by the delegate interoperability network; the message may identify the transaction that the user wants to cause, such as a value of assets that the user wants to transact in on the target chain, functions the user wants to call on the target chain, etc.; the delegate 102 may receive, from the delegate 106, a second spanning message; the second spanning message may be a verification that the user's requested transaction is complete, in that it shows an association between the user's spanning address and an asset balance of an asset associated with the target chain as a result of the user's requested transaction; the delegate 102 may generate one or more consensus proofs associated with the user's transaction; these consensus mechanisms may include, for example, one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time associated with the user's requested transaction; based at least in part on verifying the one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time, the delegate 102 may add the user's transaction to the originating chain).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, and Beller to incorporate the further teachings of Beller for the target blockchain network to comprise a first verification node and a second service node, and the operation that the target blockchain network performs the second verification on the first signature and processes the cross-blockchain transaction processing request comprises: performing the second verification on the first signature by the first verification node, and notifying the second service node of the cross-blockchain transaction processing request in response to the verification being successful; and processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request.
There is motivation to further combine Beller into the combination of Qiu, Zhang, and Beller because of the same reasons listed above for claim 7.
Regarding Claims 10, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 9 above; however, the combination does not explicitly teach wherein the second service node has a second cross-blockchain contract and a second service contract, and the processing the cross-blockchain transaction processing request by the second service node comprises: processing the cross-blockchain transaction processing request through the second cross-blockchain contract to obtain a cross-blockchain transaction processing result; generating a cross-blockchain transaction result block based on the cross-blockchain transaction processing result; recording the cross-blockchain transaction result block to a target blockchain of the target blockchain network, the cross-blockchain transaction processing result comprising a second terminal associated with the cross-blockchain transaction processing result; acquiring the cross-blockchain transaction processing result in the cross-blockchain transaction result block on the target blockchain by the second service contract; and notifying the second terminal of the cross-blockchain transaction processing result.
Beller further teaches wherein the second service node has a second cross-blockchain contract and a second service contract, and the processing the cross-blockchain transaction processing request by the second service node comprises: processing the cross-blockchain transaction processing request through the second cross-blockchain contract to obtain a cross-blockchain transaction processing result; generating a cross-blockchain transaction result block based on the cross-blockchain transaction processing result; recording the cross-blockchain transaction result block to a target blockchain of the target blockchain network, the cross-blockchain transaction processing result comprising a second terminal associated with the cross-blockchain transaction processing result; acquiring the cross-blockchain transaction processing result in the cross-blockchain transaction result block on the target blockchain by the second service contract; and notifying the second terminal of the cross-blockchain transaction processing result (Paragraphs 0054-0057 teach based at least in part on receiving the message, the delegate may cause the user's requested transaction to occur on the target chain, which may include creating a new transaction on the target chain; the delegate may store an association of the user's spanning address with the target blockchain asset; the delegate may be configured to act as or otherwise interact with a crypto wallet on the user's behalf; further, the target blockchain node(s) may receive the new transaction request and, depending on the type of transaction requested, the target blockchain node(s) may create the target blockchain asset, create and spend the target blockchain asset; the delegate may determine, based at least in part on causing the user's requested transaction to occur on the target chain, an asset balance for an asset associated with the target chain; protocols for determining the asset balance for the asset associated with the target chain include but are not limited to UTXO (such as is employed in the Bitcoin blockchain) and accounting (such as is employed in the Ethereum blockchain) protocols; the delegate may transmit a second spanning message to the delegate associated with the originating chain that verifies completion of the transaction; the spanning message may associate the spanning address associated with the user and the asset balance calculated above; the delegate may also store verification that the transaction completed such as according to the target chain's protocols; the delegate may identify a payee address associated with the target chain; the delegate may retrieve the payee address from a memory associated with the target blockchain node(s); for example, the payee address may be an address associated with frequent transactions from the user's spanning address).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, and Beller to incorporate the further teachings of Beller for the second service node to have a second cross-blockchain contract and a second service contract, and the processing the cross-blockchain transaction processing request by the second service node comprises: processing the cross-blockchain transaction processing request through the second cross-blockchain contract to obtain a cross-blockchain transaction processing result; generating a cross-blockchain transaction result block based on the cross-blockchain transaction processing result; recording the cross-blockchain transaction result block to a target blockchain of the target blockchain network, the cross-blockchain transaction processing result comprising a second terminal associated with the cross-blockchain transaction processing result; acquiring the cross-blockchain transaction processing result in the cross-blockchain transaction result block on the target blockchain by the second service contract; and notifying the second terminal of the cross-blockchain transaction processing result.
There is motivation to further combine Beller into the combination of Qiu, Zhang, and Beller because of the same reasons listed above for claim 7.
Regarding Claims 11, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 9 above; however, the combination does not explicitly teach wherein the cross-blockchain transaction processing request is a request to exchange first virtual resources of a first object on the source blockchain network for second virtual resources of a second object on the target blockchain network, the source blockchain network has a first virtual resource account of the first object and a first virtual resource account of the second object, the target blockchain network has a second virtual resource account of the first object and a second virtual resource account of the second object, the cross-blockchain transaction processing request comprises a first virtual resource value to be exchanged and a converted second virtual resource value written by the oracle machine corresponding to the first virtual resource value to be exchanged, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking a summed resource value of the estimated resource value and the first virtual resource value to be exchanged from the first virtual resource account of the first object by the first service node; and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request.
Beller further teaches wherein the cross-blockchain transaction processing request is a request to exchange first virtual resources of a first object on the source blockchain network for second virtual resources of a second object on the target blockchain network, the source blockchain network has a first virtual resource account of the first object and a first virtual resource account of the second object, the target blockchain network has a second virtual resource account of the first object and a second virtual resource account of the second object, the cross-blockchain transaction processing request comprises a first virtual resource value to be exchanged and a converted second virtual resource value written by the oracle machine corresponding to the first virtual resource value to be exchanged, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking a summed resource value of the estimated resource value and the first virtual resource value to be exchanged from the first virtual resource account of the first object by the first service node; and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request (Paragraphs 0017, 0045, and 0049 teach the first blockchain may be an “originating” blockchain according to a first use case where our example user possesses proof of ownership of an asset associated with the first blockchain, and wants to transact over a second blockchain—the “target chain;” the originating chain and the target chain may be different blockchains, by virtue of being different forks of a same parent blockchain (e.g., Bitcoin Classic versus Bitcoin Cash or Bitcoin Gold) and/or by virtue of being completely different blockchains (e.g., Bitcoin Classic versus Ethereum or ETH 2.0); user may transmit a message to the delegate on the originating chain to request a transaction on the target chain; the user may use an application programming interface (API) to transmit the message; the message may include the user's originating address and may identify the originating blockchain asset as well as prove the user's ownership by signing the originating blockchain asset using the originating key; the message may be a new transaction/request for a new transaction to be entered on the originating chain that makes a call to the delegate as an input to the new transaction on the originating chain; the message or new transaction may identify the target chain as the chain that the user would like to interact with or transact on; based at least in part on determining that the target chain has sufficient gas token liquidity, the delegate may transmit a message to the delegate associated with the target chain and/or node(s) participating in a delegate network blockchain; the message may be a new transaction on the delegate network blockchain and may be readable by the delegate, such as when the target chain implements a virtual machine that is supported by the delegate interoperability network; the message may be a newly requested transaction on the target chain that calls functionality of the delegate; the message may identify the transaction that the user wants to cause, such as a value of assets that the user wants to transact in on the target chain, functions the user wants to call on the target chain).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, and Beller to incorporate the further teachings of Beller for the cross-blockchain transaction processing request to be a request to exchange first virtual resources of a first object on the source blockchain network for second virtual resources of a second object on the target blockchain network, the source blockchain network has a first virtual resource account of the first object and a first virtual resource account of the second object, the target blockchain network has a second virtual resource account of the first object and a second virtual resource account of the second object, the cross-blockchain transaction processing request comprises a first virtual resource value to be exchanged and a converted second virtual resource value written by the oracle machine corresponding to the first virtual resource value to be exchanged, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking a summed resource value of the estimated resource value and the first virtual resource value to be exchanged from the first virtual resource account of the first object by the first service node; and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request.
There is motivation to further combine Beller into the combination of Qiu, Zhang, and Beller because of the same reasons listed above for claim 7.
Regarding Claims 12, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 11 above; however, the combination does not explicitly teach the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of the actual resource consumption value for processing the cross-blockchain transaction processing request comprises: adding the converted second virtual resource value to the second virtual resource account of the first object by the second service node; subtracting the converted second virtual resource value from the second virtual resource account of the second object; calculating the actual resource consumption value, and notifying the source blockchain network of the actual resource consumption value through the relay system such that the source blockchain network deducts the first virtual resource value to be exchanged and the actual resource consumption value from the locked summed resource value, returns the remaining part of the summed resource value to the first virtual resource account of the first object, and adds the first virtual resource value to be exchanged to the first virtual resource account of the second object.
Beller further teaches the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of the actual resource consumption value for processing the cross-blockchain transaction processing request comprises: adding the converted second virtual resource value to the second virtual resource account of the first object by the second service node; subtracting the converted second virtual resource value from the second virtual resource account of the second object; calculating the actual resource consumption value, and notifying the source blockchain network of the actual resource consumption value through the relay system such that the source blockchain network deducts the first virtual resource value to be exchanged and the actual resource consumption value from the locked summed resource value, returns the remaining part of the summed resource value to the first virtual resource account of the first object, and adds the first virtual resource value to be exchanged to the first virtual resource account of the second object (Paragraphs 0049-0052 teach based at least in part on determining that the target chain has sufficient gas token liquidity, the delegate may transmit a message to the delegate associated with the target chain and/or node(s) participating in a delegate network blockchain; the message may be a new transaction on the delegate network blockchain and may be readable by the delegate, such as when the target chain implements a virtual machine that is supported by the delegate interoperability network; the message may identify the transaction that the user wants to cause, such as a value of assets that the user wants to transact in on the target chain, functions the user wants to call on the target chain, etc.; the delegate 102 may receive, from the delegate 106, a second spanning message; the second spanning message may be a verification that the user's requested transaction is complete, in that it shows an association between the user's spanning address and an asset balance of an asset associated with the target chain as a result of the user's requested transaction; the delegate 102 may generate one or more consensus proofs associated with the user's transaction; these consensus mechanisms may include, for example, one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time associated with the user's requested transaction; based at least in part on verifying the one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time, the delegate 102 may add the user's transaction to the originating chain).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, and Beller to incorporate the further teachings of Beller for the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of the actual resource consumption value for processing the cross-blockchain transaction processing request to comprise: adding the converted second virtual resource value to the second virtual resource account of the first object by the second service node; subtracting the converted second virtual resource value from the second virtual resource account of the second object; calculating the actual resource consumption value, and notifying the source blockchain network of the actual resource consumption value through the relay system such that the source blockchain network deducts the first virtual resource value to be exchanged and the actual resource consumption value from the locked summed resource value, returns the remaining part of the summed resource value to the first virtual resource account of the first object, and adds the first virtual resource value to be exchanged to the first virtual resource account of the second object.
There is motivation to further combine Beller into the combination of Qiu, Zhang, and Beller because of the same reasons listed above for claim 7.
Regarding Claims 13, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 9 above; however, the combination does not explicitly teach wherein the cross-blockchain transaction processing request is a cross-blockchain function invoking request when a service of a first object is executed on the source blockchain network, and the source blockchain network has a first virtual resource account of the first object, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking an estimated resource value from the first virtual resource account of the first object by the first service node; and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request.
Beller further teaches wherein the cross-blockchain transaction processing request is a cross-blockchain function invoking request when a service of a first object is executed on the source blockchain network, and the source blockchain network has a first virtual resource account of the first object, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking an estimated resource value from the first virtual resource account of the first object by the first service node; and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request (Paragraphs 0009, 0045, and 0047 teach the user would transmit a Bitcoin to the bridge, which would lock-up the value associated with that Bitcoin, and the bridge would mint a new Ethereum asset (e.g., a token) on the Ethereum chain that essentially states that the newly minted Ethereum asset is backed by a Bitcoin of commensurate value (plus a transaction fee to the bridge creator); the bridge is supposed to track whether the value is still locked up at the bridge and the newly minted Ethereum asset can be used like other Ethereum assets; our example user may transmit a message to the delegate on the originating chain to request a transaction on the target chain; the user may use an application programming interface (API) to transmit the message; the message may include the user's originating address and may identify the originating blockchain asset as well as prove the user's ownership by signing the originating blockchain asset using the originating key; the message may be a new transaction/request for a new transaction to be entered on the originating chain that makes a call to the delegate as an input to the new transaction on the originating chain; the message or new transaction may identify the target chain as the chain that the user would like to interact with or transact on; the message may additionally or alternatively identify a type of transaction that the user wants to conduct, a value associated therewith, and/or any functions that the user wants to call on the target chain; the delegate may generate a spanning address associated with the user; a spanning address may include a bytes32 that contains both the local address and a domain identifier, although additional or alternate addresses are considered and may be longer; the domain identifier is unique to each deployed delegate and thus is unique to each network).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, and Beller to incorporate the further teachings of Beller for the cross-blockchain transaction processing request to be a cross-blockchain function invoking request when a service of a first object is executed on the source blockchain network, and the source blockchain network has a first virtual resource account of the first object, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking an estimated resource value from the first virtual resource account of the first object by the first service node; and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request.
There is motivation to further combine Beller into the combination of Qiu, Zhang, and Beller because of the same reasons listed above for claim 7.
Regarding Claims 14, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 13 above; however, the combination does not explicitly teach wherein the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request comprises: acquiring a cross-blockchain function requested by the cross-blockchain function invoking request from the target blockchain by the second service node; calculating the actual resource consumption value, and notifying the source blockchain network of the cross-blockchain function and the actual resource consumption value by the relay system such that the source blockchain network deducts the actual resource consumption value from the locked estimated resource value and returns the remaining part of the estimated resource value to the first virtual resource account of the first object.
Beller further teaches wherein the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request comprises: acquiring a cross-blockchain function requested by the cross-blockchain function invoking request from the target blockchain by the second service node; calculating the actual resource consumption value, and notifying the source blockchain network of the cross-blockchain function and the actual resource consumption value by the relay system such that the source blockchain network deducts the actual resource consumption value from the locked estimated resource value and returns the remaining part of the estimated resource value to the first virtual resource account of the first object (Paragraphs 0049-0052 teach based at least in part on determining that the target chain has sufficient gas token liquidity, the delegate may transmit a message to the delegate associated with the target chain and/or node(s) participating in a delegate network blockchain; the message may be a new transaction on the delegate network blockchain and may be readable by the delegate, such as when the target chain implements a virtual machine that is supported by the delegate interoperability network; the message may identify the transaction that the user wants to cause, such as a value of assets that the user wants to transact in on the target chain, functions the user wants to call on the target chain, etc.; the delegate 102 may receive, from the delegate 106, a second spanning message; the second spanning message may be a verification that the user's requested transaction is complete, in that it shows an association between the user's spanning address and an asset balance of an asset associated with the target chain as a result of the user's requested transaction; the delegate 102 may generate one or more consensus proofs associated with the user's transaction; these consensus mechanisms may include, for example, one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time associated with the user's requested transaction; based at least in part on verifying the one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time, the delegate 102 may add the user's transaction to the originating chain).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, and Beller to incorporate the further teachings of Beller for the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request to comprise: acquiring a cross-blockchain function requested by the cross-blockchain function invoking request from the target blockchain by the second service node; calculating the actual resource consumption value, and notifying the source blockchain network of the cross-blockchain function and the actual resource consumption value by the relay system such that the source blockchain network deducts the actual resource consumption value from the locked estimated resource value and returns the remaining part of the estimated resource value to the first virtual resource account of the first object.
There is motivation to further combine Beller into the combination of Qiu, Zhang, and Beller because of the same reasons listed above for claim 7.
Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Qiu (WO 2024103854) in view of Zhang (WO2023088136) in further view of Beller (US 20230334470) in further view of Mussallem (US 20230260037).
Regarding Claims 15, the combination of Qiu, Zhang, and Beller teaches all the limitations of claim 9 above; however, the combination does not explicitly teach wherein the cross-blockchain transaction processing request is a request from a first object on the source blockchain network to statistically collect resources on the source blockchain network and the target blockchain network, the source blockchain network has a first virtual resource account of the first object, and the target blockchain network has a second virtual resource account of the first object, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking an estimated resource value from the first virtual resource account of the first object through the first service node, and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request.
Mussallem from same or similar field of endeavor teaches wherein the cross-blockchain transaction processing request is a request from a first object on the source blockchain network to statistically collect resources on the source blockchain network and the target blockchain network, the source blockchain network has a first virtual resource account of the first object, and the target blockchain network has a second virtual resource account of the first object, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking an estimated resource value from the first virtual resource account of the first object through the first service node, and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request (Paragraphs 0038 and 0071-0074 teaches statistics tool performs statistical analysis and charts associated with blockchain transactions and may determine a value associated with a given blockchain asset, based on an aggregated transaction over network; wallet module enables crypto-to-crypto swaps integrated with a third-party service to offer a gateway to their service; some of these third-party services act as an aggregator of decentralized exchanges; the wallet displays a proposed swap rate (e.g., 100 PNG for 1 AVAX, to name any two exemplary blockchain assets), which may be provided by the third-party service.; the blockchain engine may include instructions from a statistics tool, a wallet tool, and an encryption tool, the portfolio management engine may include instructions from an aggregator tool and a smart contract tool, and the account management engine may include instructions in an address book tool and an account switch tool, as disclosed herein (cf. statistics tool); providing, via an application interface, to a client device with a first user, a list of multiple assets in a first blockchain to which the first user is subscribed, which includes receiving a request for sending, receiving, buying, or swapping one or more user assets in the first blockchain; receiving a request from the client device to bridge the first blockchain with a second blockchain to which the first user is subscribed; receiving a request for sending, receiving, buying, or swapping one or more user assets between the first user and a second user; receiving, via the application interface, a request from the first user to perform a transaction involving one or more of the assets in the first blockchain; determining a value for the transaction; applying the value for the transaction to an account for the first user, and providing, via the application interface, a display of the account to a wallet tool in an application running in the client device).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, and Beller to incorporate the teachings of Mussallem for the cross-blockchain transaction processing request to be a request from a first object on the source blockchain network to statistically collect resources on the source blockchain network and the target blockchain network, the source blockchain network has a first virtual resource account of the first object, and the target blockchain network has a second virtual resource account of the first object, and the generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request by the first service node comprises: locking an estimated resource value from the first virtual resource account of the first object through the first service node, and generating the cross-blockchain transaction processing request block according to the cross-blockchain transaction processing request.
There is motivation to combine Mussallem into the combination of Qiu, Zhang, and Beller because the exchange rate may be updated at a pre-selected rate (e.g., every 45 s, or so) based on market conditions (e.g., bids/asks, liquidity, routing, cf. statistics tool 240) (Mussallem Paragraph 0047).
Regarding Claims 16, the combination of Qiu, Zhang, Beller, and Mussallem teaches all the limitations of claim 15 above; however, the combination does not explicitly teach wherein the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request comprises: acquiring a balance of the second virtual resource account of the first object by the second service node; calculating the actual resource consumption value, and notifying the source blockchain network of the balance of the second virtual resource account and the actual resource consumption value by the relay system such that the source blockchain network deducts the actual resource consumption value from the locked estimated resource value, returns the remaining part of the estimated resource value to the first virtual resource account of the first object, converts the balance of the second virtual resource account into converted first virtual resources according to an exchange rate between the first virtual resources and the second virtual resources acquired from the oracle machine, and adds the converted first virtual resources and the balance of the first virtual resource account of the first object to obtain a resource statistics result.
Beller further teaches wherein the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request comprises: acquiring a balance of the second virtual resource account of the first object by the second service node; calculating the actual resource consumption value, and notifying the source blockchain network of the balance of the second virtual resource account and the actual resource consumption value by the relay system such that the source blockchain network deducts the actual resource consumption value from the locked estimated resource value, returns the remaining part of the estimated resource value to the first virtual resource account of the first object, converts the balance of the second virtual resource account into converted first virtual resources according to an exchange rate between the first virtual resources and the second virtual resources acquired from the oracle machine, and adds the converted first virtual resources and the balance of the first virtual resource account of the first object to obtain a resource statistics result (Paragraphs 0049-0052 teach based at least in part on determining that the target chain has sufficient gas token liquidity, the delegate may transmit a message to the delegate associated with the target chain and/or node(s) participating in a delegate network blockchain; the message may be a new transaction on the delegate network blockchain and may be readable by the delegate, such as when the target chain implements a virtual machine that is supported by the delegate interoperability network; the message may identify the transaction that the user wants to cause, such as a value of assets that the user wants to transact in on the target chain, functions the user wants to call on the target chain, etc.; the delegate 102 may receive, from the delegate 106, a second spanning message; the second spanning message may be a verification that the user's requested transaction is complete, in that it shows an association between the user's spanning address and an asset balance of an asset associated with the target chain as a result of the user's requested transaction; the delegate 102 may generate one or more consensus proofs associated with the user's transaction; these consensus mechanisms may include, for example, one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time associated with the user's requested transaction; based at least in part on verifying the one or more of a proof of work, a proof of stake, a proof of capacity, a proof of burn, or a proof of elapsed time, the delegate 102 may add the user's transaction to the originating chain).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Qiu, Zhang, Beller, and Mussallem to incorporate the further teachings of Beller for the processing the cross-blockchain transaction processing request by the second service node, and notifying, by the relay system, the source blockchain network of an actual resource consumption value for processing the cross-blockchain transaction processing request to comprise: acquiring a balance of the second virtual resource account of the first object by the second service node; calculating the actual resource consumption value, and notifying the source blockchain network of the balance of the second virtual resource account and the actual resource consumption value by the relay system such that the source blockchain network deducts the actual resource consumption value from the locked estimated resource value, returns the remaining part of the estimated resource value to the first virtual resource account of the first object, converts the balance of the second virtual resource account into converted first virtual resources according to an exchange rate between the first virtual resources and the second virtual resources acquired from the oracle machine, and adds the converted first virtual resources and the balance of the first virtual resource account of the first object to obtain a resource statistics result.
There is motivation to further combine Beller into the combination of Qiu, Zhang, Beller, and Mussallem because of the same reasons listed above for claim 15.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Qiu (WO 2024103854) in view of Beller (US 20230334470).
Regarding Claims 17, Qiu teaches all the limitations of claim 1 above; however, Qiu does not explicitly teach wherein the cross-blockchain transaction processing request further comprises a cross-blockchain transaction type, and the second number is determined by: acquiring the cross-blockchain transaction type in the cross-blockchain transaction processing request; and looking up in a correspondence table between cross-blockchain transaction types and second numbers according to the cross-blockchain transaction type to determine the second number.
Beller from same or similar field of endeavor teaches wherein the cross-blockchain transaction processing request further comprises a cross-blockchain transaction type, and the second number is determined by: acquiring the cross-blockchain transaction type in the cross-blockchain transaction processing request; and looking up in a correspondence table between cross-blockchain transaction types and second numbers according to the cross-blockchain transaction type to determine the second number (Paragraphs 0024-0025 and 0047-0048 teach the target chain's gas token liquidity may be determined using an external oracle network; the external oracle network may be a decentralized set of validators that must come to consensus on the target chain's gas token liquidity before providing that data back to the originating chain; the message may comprise the spanning address associated with our example user; to facilitate the transaction, the delegate may store an association of the user's spanning address with the target chain and/or the target blockchain asset; based at least in part on receiving the message, the delegate may cause the transaction to occur on the target chain, which may include initiating a new transaction on the target chain and/or creating a blockchain asset associated with the target chain; for example, any of the target blockchain node(s) may receive the new transaction request and, depending on the type of transaction requested, create the target blockchain asset, create and spend the target blockchain asset (by identifying a payee address on the target chain), or the like; the delegate may store verification that the transaction is completed; the delegate may transmit a spanning message to the delegate that identifies the spanning address associated with the user and an asset balance for the user associated with the target chain; the delegate may generate a spanning address associated with the user; a spanning address may include a bytes32 that contains both the local address and a domain identifier, although additional or alternate addresses are considered and may be longer; the domain identifier is unique to each deployed delegate and thus is unique to each network; a single network may also support multiple delegates and domains for application-specific delegates or future updated network versions; the delegate may determine whether the target chain has sufficient gas token liquidity to complete the user's requested transaction; this determination may further include determining whether the target chain is a deployable blockchain or a read-only blockchain; determining whether the target chain is a deployable blockchain or a read-only blockchain, in some cases, may occur via regular status updates (e.g., via heartbeat messages or the like) of an internal relayer network or an external oracle network; such status updates may be simultaneously transmitted to each delegate of a given network).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Qiu to incorporate the teachings of Beller for the cross-blockchain transaction processing request further comprises a cross-blockchain transaction type, and the second number to be determined by: acquiring the cross-blockchain transaction type in the cross-blockchain transaction processing request; and looking up in a correspondence table between cross-blockchain transaction types and second numbers according to the cross-blockchain transaction type to determine the second number.
There is motivation to combine Mandal into Beller because of the same reasons listed above for claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Fang et al. (US 20210326869) teaches computer-implemented methods, non-transitory computer-readable media, and systems for managing transactions in blockchain networks. One computer-implemented method includes identifying a first Hash Time Locked Contract (HTLC) transaction in a first blockchain network that is associated with a second HTLC transaction in a second blockchain network different from the first blockchain network, identifying a third HTLC transaction in the second blockchain network that is associated with the second HTLC transaction, identifying a fourth HTLC transaction in the first blockchain network that is associated with the first, second, and third HTLC transactions, the first, second, third, and fourth HTLC transactions being related to a cross-chain transaction across the first and second blockchain networks, and deriving hidden information of the cross-chain transaction from information of the first, second, third, and fourth HTLC transactions based on associations of the first, second, third and fourth HTLC transactions.
Traweek (US 20230109125) teaches a user operating an endpoint app chooses to obtain a blockchain-based asset on a target blockchain. The user does not have blockchain transaction credentials for the target blockchain, but does have blockchain transaction credentials for a source blockchain. The endpoint app hierarchically creates target blockchain transaction credentials for the user, using an initial seed of entropy that was used to create the user’s source blockchain transaction credentials. A backend component automatically obtains an amount of target blockchain cryptocurrency sufficient to obtain the blockchain-based asset on the target blockchain, in exchange for source blockchain cryptocurrency of the user. The obtained target blockchain cryptocurrency and the hierarchically created target blockchain transaction credentials are used to automatically obtain the blockchain-based asset on the target blockchain, such that once the transaction is completed, the obtained blockchain-based asset is registered to the address of the user’s hierarchically created target blockchain transaction credentials.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469) 295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights