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
Claims 1-20 are presented for examination.
Claim 21 is new.
This is a Final Action.
Response to Arguments
Applicant's arguments filed 02/05/2026 have been fully considered but they are not persuasive.
Applicant makes the following arguments:
1. Applicant asserts that the Office failed to show that every element of the claims is disclosed in Mao-Cai, and therefore the rejection under 102 is improper.
Examiner respectfully disagrees with the applicant because the Office Action explicitly identified where each limitation of claim 1 is taught by Mao-Cai. As set forth in the rejection, Mao-Cai discloses determining the block type, generating the block based on the type and operation of blockchain nodes within a blockchain network. Accordingly, Mao-Cai discloses each limitation of claim 1 either explicitly or inherently.
Applicant argues that Mao-Cai fails to disclose: “sending, by the first blockchain node, the first block to a second blockchain node”. Applicant asserts the cited passage only discloses data transmission of service request information and not transmission of the generated block.
Examiner respectfully disagrees with the applicant. Mao-Cai describes a blockchain network multiple node devices that communicate with each other and exchange data through network connections. In blockchain system, blocks containing transaction information are propagated between nodes to maintain the shared ledger. Therefore, the transmission of blockchain data between node device inherently includes transmission of generated blocks. Further, Mao-Cai teaches that each node device maintains the same blockchain and processes service request information received across the network. Such operation necessarily requires that blocks generated by one node be transmitted to other nodes for storage and validation.
Furthermore, Mao-Cai explicitly discloses a blockchain network comprising multiple node devices that maintain the same blockchain ledger. In such systems, blocks generated by one node must be transmitted to another nodes so that each node stores the same blockchain. This fact is taught by Mao-Cai at Page 6: paragraph 5 – teaches “each node device in the block chain stores a same block chain, the block chain is composed of a plurality of blocks…” Therefore, the transmission of generated blocks between node devices is inherently required for the operations of the blockchain network described and taught in Mao-Cai.
Applicant argues that Mao-Cai does not disclose: “the first blockchain node and the second blockchain node are configured to maintain a first blockchain comprising at least one first-type block and at least one second-type block.” Applicant contends Mao-Cai only describes detecting block types and actions taken when blocks are of certain type.
Examiner respectfully disagrees with the applicant. Mao-Cai explicitly discloses: 1. Blockchain nodes maintain a shared blockchain and 2. Blocks in the blockchain include first-type blocks and second-type blocks. Because each node stores the same blockchain ledger containing those block types, the nodes necessarily maintain a blockchain comprising both first-type and second-type blocks.
Accordingly, Mao-Cai discloses that multiple blockchain nodes maintain a blockchain that includes both types of blocks as recited in claim 1.
Applicant argues that because claim 1 is not anticipated, independent claims 6, 11 and 16 are also not anticipated.
Examiner respectfully disagrees with the applicant, Specifically, claims 6, 11 and 16 recite limitations substantially similar to claim 1. Since Mao-Cai teaches the limitations of claim 1 as discussed above, the reference likewise teaches the corresponding limitations of claims 6, 11 and 16.
Applicant argues that dependent claims 2-5, 7-10, 12-15 and 17-20 are allowable because they dependent from an allowable independent claim.
Examiner respectfully disagrees with the applicant. Since claims 1, 6, 11 and 16 are properly rejected under 102, the dependent claims likewise remain unpatentable.
Applicants arguments have been fully considered but are not persuasive. Mao-Cai discloses blockchain nodes that communicate with each other, determine block types, generate blocks based on block type, and maintain a shared blockchain comprising blocks of different types. Accordingly, Mao-Cai teaches each limitation of claim 1. Therefore, the rejection of claims 1-20 under 35 USC 102(a)(1) is maintained. Furthermore, Applicant is improperly attacking Mao-Cai by focusing on individual passages rather than the disclosure as a whole. A reference must be considered for all that it teaches to one of ordinary skill in the art (In re Merch, 800 F.2d 1091 (Fed. Cir. 1986)).
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-21 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mao-Cai et al. (CN 111541756A (IDS).
1. Mao-cai teaches A blockchain generation method, comprising:
determining, by a first blockchain node, a block type of a first block, wherein the block type is a first type or a second type (Page 4: mid page – “detecting whether the target block belongs to a first type block, wherein the trigger instruction comprises at least one service request message if the target block belongs to the first type block – disclose determine first-type or second-type block));
determining, by the first blockchain node, the first block based on the block type of the first block (Page 4: mid page – “if the target block belongs to a first type block, determining whether an associated block group… exists… and generating a target block based on the block head hash value of each associated block and at least one service request information); and
sending, by the first blockchain node, the first block to a second blockchain node ( page 6: paragraph 4 – teaches node device 103,… receive the service request information… and data transmission is performed between the node devices”; Page 6: paragraph 5 – teaches “each node device in the block chain stores a same block chain, the block chain is composed of a plurality of blocks…”), wherein the first blockchain node and the second blockchain node are configured to maintain a first blockchain comprising at least one first-type block and at least one second-type block (Page 5: 2nd paragraph & Page 9: paragraph 6, Fig 1b – teaches each node device stores a same block chain, the blocks are divided into … a first type and second type blocks).
2. Mao-cai teaches, The method according to claim 1, further comprising:
determining, by the first blockchain node, first information comprising one or more of the following information: preposition block information of the first block, second-type block reference information, block confirmation information, transaction information, or a block confirmation period (Page 7: Paragraphs 4-5 – teaches determining whether an associated block group exists… obtaining the block head hash value of each associated block and generating a target block based on the block head hash value and service request information); and
obtaining, by the first blockchain node, a block header of the first block based on the first information (Page 7: Paragraph 5 – teaches generating a hash value of a target block based on… service request message… verifying a block header based on a block header hash value… storing the block head hash value of each associated block and the hash value of the target block in the block head).
3. Mao-cai teaches, The method according to claim 2, wherein the obtaining, by the first blockchain node, a block header of the first block based on the first information comprises:
performing, by the first blockchain node, one or more of the following processing on the first information: generating a first Merkle tree based on the transaction information or generating a second Merkle tree based on the second-type block reference information; performing, by the first blockchain node, a hash operation on at least one of the first Merkle tree, the preposition block information, or the second Merkle tree, to obtain a third Merkle tree; and obtaining, by the first blockchain node, the block header of the first block based on a root of the third Merkle tree (Page 7: Paragraph 5 – teaches generating a hash value of a target block based on… service request message… verifying a block header based on a block header hash value… storing the block head hash value of each associated block and the hash value of the target block in the block head – discloses a first or second merkel tree further teaching separate hash aggregates of transaction and reference-block data).
4. Mao-cai teaches, The method according to claim 2, wherein the determining, by a first blockchain node, a block type of a first block comprises: performing, by the first blockchain node, a hash operation on the block header of the first block; and determining, by the first blockchain node, the block type of the first block based on a result of the hash operation (Page 10: last paragraph, page 11: 1st and 2nd paragraph – teaches acquiring verification parameters and verifying the target block head… carrying out multiple hash operations until the hash operation result is smaller than a threshold value, determining that the target block head is a valid block head and detecting whether the target block belongs to a first type block).
5. Mao-cai teaches, The method according to claim 4, wherein the determining, by the first blockchain node, the block type of the first block based on a result of the hash operation comprises: when the result of the hash operation is less than or equal to a first threshold, determining, by the first blockchain node, that the block type of the first block is the first type; or when the result of the hash operation is greater than a first threshold, and the result of the hash operation is less than a second threshold, determining, by the first blockchain node, that the block type of the first block is the second type, wherein the first threshold is less than the second threshold (Page 10: last paragraph, page 11: 1st and 2nd paragraph – teaches acquiring verification parameters and verifying the target block head… carrying out multiple hash operations until the hash operation result is smaller than a threshold value, determining that the target block head is a valid block head and detecting whether the target block belongs to a first type block).
6. Mao-cai teaches, A blockchain generation method, comprising:
receiving, by a second blockchain node, a first block from a first blockchain node (page 6: paragraph 4 – teaches node device 103,… maintain shared data… data transmission is performed between the node device through the connection”);
determining, by the second blockchain node, a block type of the first block, wherein the block type is a first type or a second type (Page 4: mid page – “if the target block belongs to a first type block, determining whether an associated block group… exists… and generating a target block based on the block head hash value of each associated block and at least one service request information”);
performing, by the second blockchain node, block verification on the first block based on the block type of the first block (Page 10: last paragraph, page 11: 1st and 2nd paragraph – teaches acquiring verification parameters and verifying the target block head… carrying out multiple hash operations until the hash operation result is smaller than a threshold value, determining that the target block head is a valid block head and detecting whether the target block belongs to a first type block); and
after block verification succeeds, updating, by the second blockchain node, a first blockchain, wherein the first blockchain node and the second blockchain node are configured to maintain the first blockchain, and the first blockchain comprises at least one first-type block and at least one second-type block (Page 13: paragraph 3 – teaches after the verification is passed, storing the block head hash value and connecting the target block to the blockchain based on the block height value).
7. The method according to claim 6, wherein the determining, by the second blockchain node, a block type of the first block comprises:
determining, by the second blockchain node, a hash value of the first block (Abstract – determining the target block head by hash operation… acquiring hash value of the target block); and
when the hash value of the first block is less than or equal to a first threshold, determining, by the second blockchain node, that the block type of the first block is the first type; or when the hash value of the first block is greater than a first threshold, and a first hash value is less than a second threshold, determining, by the second blockchain node, that the block type of the first block is the second type, wherein the first threshold is less than the second threshold (Page 10: last paragraph, page 11: 1st and 2nd paragraph – teaches acquiring verification parameters and verifying the target block head… carrying out multiple hash operations until the hash operation result is smaller than a threshold value, determining that the target block head is a valid block head and detecting whether the target block belongs to a first type block).
8. Mao-cai teaches, The method according to claim 6, wherein the determining, by the second blockchain node, a block type of the first block comprises:
receiving, by the second blockchain node, the block type of the first block from the first blockchain node ( page 6: paragraph 4 – teaches node device 103,… receive the service request information… and data transmission is performed between the node devices”).
9. Mao-cai teaches, The method according to claim 6, wherein when the block type of the first block is the second type, the performing, by the second blockchain node, block verification on the first block based on the block type of the first block comprises one or more of the following:
verifying whether a proof of membership of transaction information in the first block is correct (Page 10: Paragraph 5 – teaches the verification parameters for verifying the target block header may include version, timestamp, difficulty);
verifying whether a transaction in the first block is valid;
verifying whether a first Merkle tree in the first block is correct; or
verifying whether a hash value of a block header of the first block is correct.
10. Mao-cai teaches, The method according to claim 6, wherein when the block type of the first block is the first type, the performing, by the second blockchain node, block verification on the first block based on the block type of the first block comprises one or more of the following:
verifying whether a proof of membership of second-type block reference information in the first block is correct (Page 13: paragraph 3 after the verification is passed, storing the block header hash value of each associated block, the hash value of the target block and block verification information in the block head…);
verifying whether a proof of membership of block confirmation information in the first block is correct;
verifying whether a proof of membership of a preposition block of the first block is correct; or verifying whether a hash value of a block header of the first block is correct.
Claims 11-20 are similar to claims 1-10 hence rejected similarly.
Claim 21 is similar to claim 9 hence rejected similarly.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gundavelli et al. (US 11,652,604) - teaches blockchain data compression and storage, further explicitly reciting a Merkle tree of the blockchain (Abstract, Fig 7)
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMRESH SINGH whose telephone number is (571)270-3560. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Ann J. Lo can be reached at (571) 272-9767. 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.
/AMRESH SINGH/Primary Examiner, Art Unit 2159