Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This is a reply to the application filed on 07/27/2025, in which, claim(s) 1-20 are pending. Claim(s) 1, 10 and 17 are independent.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/27/2025, has been reviewed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the examiner is considering the information disclosure statement.
Drawings
The drawings filed on 07/27/2025 are accepted by The Examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claim 9 recites “computer-readable storage medium”. As recited in the claim, the claimed medium lacks a structural component because the computer-readable storage medium can be implemented as software only (please see the specification, [0142], “as a computer-readable storage medium, the memory 1005 may include an operating system, a network communication module, a user interface module, and a device control application program”). Therefore, claim 9 is directed to non-statutory subject matter for lack of a hardware component. The Examiner respectfully suggests that the claim be further amended to positively recite at least one hardware element within the body of the claim to make the claim statutory subject matter under 35 U.S.C. 101 such as “A non-transitory computer-readable storage medium”.
Claim Rejections - 35 USC § 103
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 of this title, 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-3, 8-10, 12, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 2021/0103581 A1) in view of Jayachandran et al. (US 2019/0278852 A1).
Regarding Claims 1, 9 and 17, Lee discloses
transmitting an original reading request about target transaction data to a node device in a blockchain network to cause the node device to invoke a business function in a cross-chain communication protocol according to the original reading request, the original reading request carrying transaction attribute information of the target transaction data ([0012-0014], “The data management system comprises a blockchain node configured to store on-chain data on blockchain a service server, upon receiving a service request associated with the original data from a client”, “The first request may be a read request or a download request of the original data”, [0099], “when a service request including identification information of a read target file as reference data is received (S401), the service server 100 generates transaction contents using the reference data (S403). The reference data may further include identification information on a file read request subject”);
receiving an off-chain reading request transmitted by the node device, the off-chain reading request being generated by the node device through the business function and according to the transaction attribute information and device attribute information of a target network device, the device attribute information being obtained by the node device querying the cross-chain communication protocol when determining, through the business function, that the target transaction data is off-chain data of the blockchain network, and the target network device being configured to read the off-chain data of the blockchain network ([0101], “the service server 100 queries address information of each of the off-chain data corresponding to the identification information of the read target file in the blockchain network 300”);
reading a transaction data packet from the target network device according to the off-chain reading request, the transaction data packet being read by the target network device from an external device associated with the blockchain network ([0101], “the service server 100 queries address information of each of the off-chain data corresponding to the identification information of the read target file in the blockchain network 300, and reads each of the off chain data from the storage node 400”);
Lee does not explicitly teach but Jayachandran teaches
forwarding the transaction data packet to the node device, for the node device to verify validity of the transaction data packet based on a data verification function associated with the cross-chain communication protocol, to obtain a verification result ([0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”); and
receiving, in response to the verification result indicating that the transaction data packet is valid, the target transaction data returned by the node device, the target transaction data being obtained by the node device parsing the transaction data packet ([0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”, “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set”, “the set of these values, along with the determination by the endorsing peer node 281 and the endorsing peer node's 281 signature is passed back as a proposal response to the SDK of the client 201 which parses the payload for the application to consume”).
Lee and Jayachandran are analogous art as they are in the same field of endeavor of information security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jayachandran with the disclosure of Lee. The motivation/suggestion would have been to implement customized endorsement logic when determining whether a transaction is valid (Jayachandran, [0001]).
Regarding Claims 2 and 18, the combined teaching of Lee and Jayachandran teaches
wherein: the off-chain reading request is a first off-chain reading request (Lee, ([0101], “the service server 100 queries address information of each of the off-chain data”); and reading the transaction data packet includes:
generating a second off-chain reading request adapted to the target network device according to the first off-chain reading request (Lee, ([0101], “the service server 100 queries address information of each of the off-chain data”);
transmitting the second off-chain reading request to the target network device, for the target network device to generate a request response message according to the second off-chain reading request; receiving the request response message returned by the target network device; and obtaining, in response to the request response message being a response success message, the transaction data packet from the request response message (Jayachandran, [0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”, “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set”, “the set of these values, along with the determination by the endorsing peer node 281 and the endorsing peer node's 281 signature is passed back as a proposal response to the SDK of the client 201 which parses the payload for the application to consume”).
Regarding Claims 3 and 19, the combined teaching of Lee and Jayachandran teaches
wherein: the first off-chain reading request includes a protocol address of the cross-chain communication protocol, a request generation template in the cross-chain communication protocol, and callback data, the request generation template is adapted to the target network device, and the protocol address and the callback data are jointly configured to instruct the target network device to read the target transaction data from the external device (Jayachandran, [0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”, “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set”, “the set of these values, along with the determination by the endorsing peer node 281 and the endorsing peer node's 281 signature is passed back as a proposal response to the SDK of the client 201 which parses the payload for the application to consume”); and
generating the second off-chain reading request includes:
in response to the request generation template including a data field and a sender field, replacing the sender field with the protocol address and replacing the data field with the callback data, to obtain an obtaining request about the target transaction data; and determining the obtaining request as the second off-chain reading request (Jayachandran, [0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”, “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set”, “the set of these values, along with the determination by the endorsing peer node 281 and the endorsing peer node's 281 signature is passed back as a proposal response to the SDK of the client 201 which parses the payload for the application to consume”).
Regarding Claim 8, the combined teaching of Lee and Jayachandran teaches
wherein: the off-chain reading request includes an initial verification function in the cross-chain communication protocol and extra data configured for verifying the transaction data packet (Jayachandran, [0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”); and forwarding the transaction data packet to the node device includes:
adding the transaction data packet and the extra data to the initial verification function to obtain the data verification function; and transmitting the data verification function to the node device, for the node device to verify the validity of the transaction data packet in the data verification function by executing the data verification function to obtain the verification result (Jayachandran, [0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”, “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set”, “the set of these values, along with the determination by the endorsing peer node 281 and the endorsing peer node's 281 signature is passed back as a proposal response to the SDK of the client 201 which parses the payload for the application to consume”).
Regarding Claims 10 and 15-16, Lee discloses
receiving an original reading request about target transaction data, the original reading request being transmitted by a terminal device and carrying transaction attribute information of the target transaction data ([0012-0014], “The data management system comprises a blockchain node configured to store on-chain data on blockchain a service server, upon receiving a service request associated with the original data from a client”, “The first request may be a read request or a download request of the original data”, [0099], “when a service request including identification information of a read target file as reference data is received (S401), the service server 100 generates transaction contents using the reference data (S403). The reference data may further include identification information on a file read request subject”);
invoking a business function in a cross-chain communication protocol according to the original reading request, and querying, in response to the business function indicating that the target transaction data is off-chain data of a blockchain network, the cross-chain communication protocol of the blockchain network for device attribute information of a target network device configured to read the off-chain data of the blockchain network ([0101], “the service server 100 queries address information of each of the off-chain data corresponding to the identification information of the read target file in the blockchain network 300, and reads each of the off chain data from the storage node 400”);
generating an off-chain reading request in the business function according to the transaction attribute information and the device attribute information, and transmitting the off-chain reading request to the terminal device, for the terminal device to read a transaction data packet from the target network device according to the off-chain reading request, the transaction data packet being read by the target network device from an external device associated with a node device in the blockchain network ([0101], “the service server 100 queries address information of each of the off-chain data corresponding to the identification information of the read target file in the blockchain network 300”);
Lee does not explicitly teach but Jayachandran teaches
receiving the transaction data packet transmitted by the terminal device, and verifying validity of the transaction data packet according to a data verification function associated with the cross-chain communication protocol to obtain a verification result ([0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”); and
parsing, in response to the verification result indicating that the transaction data packet is valid, the transaction data packet to obtain the target transaction data, and returning the target transaction data obtained through parsing to the terminal device ([0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”, “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set”, “the set of these values, along with the determination by the endorsing peer node 281 and the endorsing peer node's 281 signature is passed back as a proposal response to the SDK of the client 201 which parses the payload for the application to consume”).
Lee and Jayachandran are analogous art as they are in the same field of endeavor of information security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jayachandran with the disclosure of Lee. The motivation/suggestion would have been to implement customized endorsement logic when determining whether a transaction is valid (Jayachandran, [0001]).
Regarding Claim 12, the combined teaching of Lee and Jayachandran teaches
wherein: querying the cross-chain communication protocol includes:
querying the cross-chain communication protocol for device attribute information corresponding to a plurality candidate network devices configured to read the off-chain data of the blockchain network, the plurality of candidate network devices including the target network device; and generating the off-chain reading request includes: generating the off-chain reading request according to the transaction attribute information and the device attribute information corresponding to the plurality of candidate network devices (Jayachandran, [0044-0045], “The transactions within the block are validated to ensure endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution”, “The transaction can be a deploy, invoke or query, and may be issued through a client-side application leveraging an SDK, directly through a REST API, or the like”).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 2021/0103581 A1) in view of Jayachandran et al. (US 2019/0278852 A1) further in view of Liu et al. (US 2022/0229577 A1, cited by the applicant in the 07/27/2025 IDS).
Regarding Claim 11, the combined teaching of Lee and Jayachandran teaches
wherein: the transaction data packet further includes signature information of an institution to which the target network device belongs; the data verification function includes a data verification rule, and the data verification rule is configured for instructing to verify the signature information (Jayachandran, [0041], “the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 201, in the example) is properly authorized to perform the proposed operation on that channel”, “The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set”, “the set of these values, along with the determination by the endorsing peer node 281 and the endorsing peer node's 281 signature is passed back as a proposal response to the SDK of the client 201 which parses the payload for the application to consume”); and
The combined teaching of Lee and Jayachandran does not explicitly teach but Liu teaches
verifying the validity of the transaction data packet includes:
performing a hash operation on the transaction data packet to obtain a hash value of the transaction data packet; performing signature verification on the signature information according to the public key of the institution, to obtain signature verification data; and generating, in response to the hash value of the transaction data packet matching the signature verification data, the verification result indicating that the transaction data packet is valid ([0072-0075], “the first node may perform a hash operation on the first service data information according to a hash algorithm to obtain a first hash value… the second node may pack the second service data information into a block 20C (i.e., a to-be-verified block), perform a consensus check on the block 20C”, “the first node may encrypt the second service data information based on the public key of the second node to obtain encrypted data information. In this case, the first node may migrate the encrypted data information to a second node in the second blockchain network based on the hash mapping relationship”),
Lee, Jayachandran and Liu are analogous art as they are in the same field of endeavor of information security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Liu with the combined teaching of Lee and Jayachandran. The motivation/suggestion would have been to improve data migration efficiency and increase the security of migrated data (Liu, [0005]).
Allowable Subject Matter
Claims 4, 5 and 13, 20 are objected to as being dependent upon rejected base claims 1, 10 and 17, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims (i.e., including claims 1 and 2 in claim 4 or in claim 5 and including claims 10 and 12 in claim 13 and including claims 17 and 18 in claim 20) since the prior arts taken individually or in combination fails to particular discloses, fairly suggest or render obvious the limitations of the claims 4, 5 and 13.
Claims 6, 7 and 14 are allowable in view of their dependencies on claim 5 and claim 13.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENG-FENG HUANG whose telephone number is (571)272-6186. The examiner can normally be reached Monday-Friday: 9 am - 5 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, Eleni A Shiferaw can be reached at (571) 272-3867. 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.
/CHENG-FENG HUANG/Primary Examiner, Art Unit 2497
Prosecution Insights