DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on January 13, 2025 is being considered by the examiner.
Specification
This application does not contain an abstract of the disclosure as required by 37 CFR 1.72(b). An abstract on a separate sheet is required.
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-8, 10 and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "a first persistent sequence of first ones of the data blocks” is vague and unclear. For example, the antecedence of the data blocks is not defined. Similarly, “a second persistent sequence of second ones of the data blocks” is vague and unclear, because “the second data blocks” lacks antecedent basis. There is insufficient antecedent basis for this limitation in the claim. The dependent claims are rejected for the same reasons as the independent claims.
Claim Rejections - 35 USC § 102
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.
(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.
Claims 1-8, 10 and 12 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Irazabal (U.S. Publication No. 2020/0349123 A1, hereinafter referred to as “Irazabal”).
Regarding claim 1, Irazabal discloses a method for timing data blocks, wherein the method comprises: (method)(e.g., paragraph [0029])
- storing a first data structure containing a first persistent sequence of first ones of the data blocks by appending each of the first data blocks to a last one of the first data blocks of the first persistent sequence; (“The blockchain node or peer 104 generates a merge request 124 to a block generator 108, which in permissioned blockchain networks 100 may be an orderer node or peer. The merge request 124 instructs the block generator 108 to combine or more two or more source ledgers 116A through 116N. The merge request 124 may include identifiers for each source ledger 116 to merge 136 and necessary approvals (signatures) that make up a merge policy. Although two source ledgers 116 are illustrated, any number of source ledgers 116 may be merged by the methods disclosed herein. In response to receiving the merge request 124, the block generator 108 identifies specific source ledgers 116 from the merge request 124, and accesses modified block headers 128 of the identified source ledgers 116A, 116N.”) – source ledger 116A)(e.g., figure 1A and paragraph [0044])
- storing a second data structure containing a second persistent sequence of second ones of the data blocks by appending each of the second data blocks to a last one of the second data blocks of the second persistent sequence, (“The blockchain node or peer 104 generates a merge request 124 to a block generator 108, which in permissioned blockchain networks 100 may be an orderer node or peer. The merge request 124 instructs the block generator 108 to combine or more two or more source ledgers 116A through 116N. The merge request 124 may include identifiers for each source ledger 116 to merge 136 and necessary approvals (signatures) that make up a merge policy. Although two source ledgers 116 are illustrated, any number of source ledgers 116 may be merged by the methods disclosed herein. In response to receiving the merge request 124, the block generator 108 identifies specific source ledgers 116 from the merge request 124, and accesses modified block headers 128 of the identified source ledgers 116A, 116N.”) – a different source ledger other than 116A, such as 116N)(e.g., figure 1A and paragraph [0044])
wherein, for a pair of a selected one of the first data blocks and a selected one of the second data blocks, the method comprises:
- generating the selected second data block including a second data content; (“The present application addresses merged ledgers 120 without having to re-generate and transfer all the content”)(e.g., figure 1A and paragraph [0043])
- generating the selected first data block by including a first data content and a digest of the selected one of the second data blocks, and (“The hash of the previous block generated 148 is a new parameter included within modified block headers 128. The block generator 108 generates blocks for all blockchains and source ledgers 116 of the blockchain network 100. The block generator 108 generates new blocks (modified blocks 140 in the order received, without regard to which source ledger 116 the previous block(s) were generated for. Thus, the immediately previous generated block may have been to the same source ledger 116 (block 3 ledger 3 following block 2 ledger 3, for example), or a different source ledger (block 3 ledger 3 following block 5 ledger 1, for example).”)(e.g., figures 1A and 1B and paragraph [0048])
-appending the selected first data block thereby defining a time order relationship in which the generation of the second data blocks up the selected second data block temporally precedes the generation of the selected first data block, and (“This second hash 148 allows the block generator 108 to determine the proper block order within the genesis block 132 by providing the hash of whatever the previous block is—and therefore a link to perhaps a different source ledger 116.”)(e.g., figures 1A, 1B and 2 and paragraph [0048])
wherein, for a further selected one of the second data blocks following the selected second data block in the second persistent sequence, the method further comprises: - generating the further selected second data block by including a third data content and a further digest of the selected first data block, and (“The hash of the previous block generated 148 is a new parameter included within modified block headers 128. The block generator 108 generates blocks for all blockchains and source ledgers 116 of the blockchain network 100. The block generator 108 generates new blocks (modified blocks 140 in the order received, without regard to which source ledger 116 the previous block(s) were generated for. Thus, the immediately previous generated block may have been to the same source ledger 116 (block 3 ledger 3 following block 2 ledger 3, for example), or a different source ledger (block 3 ledger 3 following block 5 ledger 1, for example).”)(e.g., figures 1A and 1B and paragraph [0048])
- appending the further selected second data block thereby defining a further time order relationship in which the generation of the second data blocks starting from the further selected second data block temporally follows the generation of the selected first data block. (“This second hash 148 allows the block generator 108 to determine the proper block order within the genesis block 132 by providing the hash of whatever the previous block is—and therefore a link to perhaps a different source ledger 116.”)(e.g., figures 1A, 1B and 2 and paragraph [0048])
Regarding claim 2, Irazabal discloses the method of claim 1. Irazabal further discloses comprising: - searching the first data structure for the selected first data block including the digest of the selected second data block; (“The source ledger identifier 142, block number 144, and the hash of the previous block of the same source ledger 146 are common to conventional (i.e. unmodified) block headers 128 for conventional blocks. The source ledger identifier 142 uniquely identifies which source ledger 116 the identifier 142 applies to. The block number 144 uniquely identifies a position the corresponding block is located at within the corresponding blockchain in the corresponding source ledger 116. The combination of the source ledger identifier 142 and block number 144 are used to prevent any modified blocks 140 from being omitted during the merging process.” “This second hash 148 allows the block generator 108 to determine the proper block order within the genesis block 132 by providing the hash of whatever the previous block is—and therefore a link to perhaps a different source ledger 116.”)(e.g., figures 1A-1C, 2A-2B and paragraphs [0047]-[0048] and [0053])
- in response to a finding of the selected first data block, determining that the second data blocks of the second persistent sequence up to the selected second data block have been generated before the selected first data block. (“Linked timestamping uses hash values in the modified block headers 128 to verify the proper block order, since hashes are based on previous blocks and hash generation may be verified by a sequence of hashes.” “It is possible that the hash 148 may indicate a different source ledger 116 not identified within the merge request 124 (i.e. a different source ledger 116 that is not to be merged). In that case, the different source ledger 116 may be ignored, but linked back through hashes 148 until an identified source ledger 116 is found. The blocks corresponding to ignored source ledgers 116 are not to be included in the merged ledger 120, but the genesis block 132 would “link around” the ignored blocks. For example, if a linked series of hashes reflected a sequence of block 1 ledger 3->block 2 ledger 2->block 4 ledger 1, and ledger 2 was not to be included in a merge request 124 but ledgers 1 and 3 were, the genesis block 132 may include a linked series of hashes of block 1 ledger 3->block 4 ledger 1. In this way, the hashes 146 and 148 provide a cross-linking between the source ledgers 116A-116N in order to provide a reliable order of modified block 140 creation without relying on conventional timestamps.”)(e.g., figures 1A-1C, 2A-2B and paragraphs [0046], [0049] and [0051]-[0053]).
Regarding claim 3, Irazabal discloses the method of claim 1. Irazabal further discloses comprising: - searching the second data structure for the further selected second data block including the further digest of the selected first data block; (“The source ledger identifier 142, block number 144, and the hash of the previous block of the same source ledger 146 are common to conventional (i.e. unmodified) block headers 128 for conventional blocks. The source ledger identifier 142 uniquely identifies which source ledger 116 the identifier 142 applies to. The block number 144 uniquely identifies a position the corresponding block is located at within the corresponding blockchain in the corresponding source ledger 116. The combination of the source ledger identifier 142 and block number 144 are used to prevent any modified blocks 140 from being omitted during the merging process.” “This second hash 148 allows the block generator 108 to determine the proper block order within the genesis block 132 by providing the hash of whatever the previous block is—and therefore a link to perhaps a different source ledger 116.”)(e.g., figures 1A-1C, 2A-2B and paragraphs [0047]-[0048] and [0053])
- in response to a finding of the further selected second data block, further determining that the second data blocks of the second persistent sequence starting from the further selected second data block have been generated after the selected first data block. (“Linked timestamping uses hash values in the modified block headers 128 to verify the proper block order, since hashes are based on previous blocks and hash generation may be verified by a sequence of hashes.” “It is possible that the hash 148 may indicate a different source ledger 116 not identified within the merge request 124 (i.e. a different source ledger 116 that is not to be merged). In that case, the different source ledger 116 may be ignored, but linked back through hashes 148 until an identified source ledger 116 is found. The blocks corresponding to ignored source ledgers 116 are not to be included in the merged ledger 120, but the genesis block 132 would “link around” the ignored blocks. For example, if a linked series of hashes reflected a sequence of block 1 ledger 3->block 2 ledger 2->block 4 ledger 1, and ledger 2 was not to be included in a merge request 124 but ledgers 1 and 3 were, the genesis block 132 may include a linked series of hashes of block 1 ledger 3->block 4 ledger 1. In this way, the hashes 146 and 148 provide a cross-linking between the source ledgers 116A-116N in order to provide a reliable order of modified block 140 creation without relying on conventional timestamps.”)(e.g., figures 1A-1C, 2A-2B and paragraphs [0046], [0049] and [0051]-[0053]).
Regarding claim 4, Irazabal discloses the method of claim 1. Irazabal further discloses wherein said generating the selected first data block further comprises timestamping said first data block with a corresponding timestamp. (“New data is included in the disclosed modified block headers (i.e. a shared linked timestamp/hash and tuple (blockchain identifier, and a block number). When blockchains or source ledgers are merged, a genesis block for the resulting blockchain is generated and cryptographic proofs are included to demonstrate the interleaving of blocks (how blocks of source blockchains get ordered) is included into the genesis block of the resulting blockchain. In such a way, peers are able to validate such ordering. The disclosed methods are most useful when block generators (ordering service in Hyperledger Fabric) generate blocks for multiple blockchains. Thus they can implement the method can enable the merging of blockchains/source ledgers.”)(e.g., paragraph [0041])
Regarding claim 5, Irazabal discloses the method of claim 4. Irazabal further discloses comprising: - determining that the second data blocks of the second persistent sequence up to the selected second data block have been generated at a time occurring before a time corresponding to the timestamp. (“It is possible that the hash 148 may indicate a different source ledger 116 not identified within the merge request 124 (i.e. a different source ledger 116 that is not to be merged). In that case, the different source ledger 116 may be ignored, but linked back through hashes 148 until an identified source ledger 116 is found. The blocks corresponding to ignored source ledgers 116 are not to be included in the merged ledger 120, but the genesis block 132 would “link around” the ignored blocks. For example, if a linked series of hashes reflected a sequence of block 1 ledger 3->block 2 ledger 2->block 4 ledger 1, and ledger 2 was not to be included in a merge request 124 but ledgers 1 and 3 were, the genesis block 132 may include a linked series of hashes of block 1 ledger 3->block 4 ledger 1. In this way, the hashes 146 and 148 provide a cross-linking between the source ledgers 116A-116N in order to provide a reliable order of modified block 140 creation without relying on conventional timestamps.”)(e.g., paragraphs [0049], [0051]-[0053]).
Regarding claim 6, Irazabal discloses the method of claim 4. Irazabal further discloses comprising: -determining that the second data blocks of the second persistent sequence starting from the further selected second data block have been generated at a time occurring after a time corresponding to the timestamp. (“Linked timestamping uses hash values in the modified block headers 128 to verify the proper block order, since hashes are based on previous blocks and hash generation may be verified by a sequence of hashes.” “It is possible that the hash 148 may indicate a different source ledger 116 not identified within the merge request 124 (i.e. a different source ledger 116 that is not to be merged). In that case, the different source ledger 116 may be ignored, but linked back through hashes 148 until an identified source ledger 116 is found. The blocks corresponding to ignored source ledgers 116 are not to be included in the merged ledger 120, but the genesis block 132 would “link around” the ignored blocks. For example, if a linked series of hashes reflected a sequence of block 1 ledger 3->block 2 ledger 2->block 4 ledger 1, and ledger 2 was not to be included in a merge request 124 but ledgers 1 and 3 were, the genesis block 132 may include a linked series of hashes of block 1 ledger 3->block 4 ledger 1. In this way, the hashes 146 and 148 provide a cross-linking between the source ledgers 116A-116N in order to provide a reliable order of modified block 140 creation without relying on conventional timestamps.”)(e.g., figures 1A-1C, 2A-2B and paragraphs [0046], [0049] and [0051]-[0053]).
Regarding claim 7, Irazabal discloses the method of claim 1. Irazabal further discloses wherein: - each first data block of the first persistent sequence different from an initial first data block of the first persistent sequence comprises a digest of the previous first data block in the first persistent sequence; (“Linked timestamping uses hash values in the modified block headers 128 to verify the proper block order, since hashes are based on previous blocks and hash generation may be verified by a sequence of hashes.” “It is possible that the hash 148 may indicate a different source ledger 116 not identified within the merge request 124 (i.e. a different source ledger 116 that is not to be merged). In that case, the different source ledger 116 may be ignored, but linked back through hashes 148 until an identified source ledger 116 is found. The blocks corresponding to ignored source ledgers 116 are not to be included in the merged ledger 120, but the genesis block 132 would “link around” the ignored blocks. For example, if a linked series of hashes reflected a sequence of block 1 ledger 3->block 2 ledger 2->block 4 ledger 1, and ledger 2 was not to be included in a merge request 124 but ledgers 1 and 3 were, the genesis block 132 may include a linked series of hashes of block 1 ledger 3->block 4 ledger 1. In this way, the hashes 146 and 148 provide a cross-linking between the source ledgers 116A-116N in order to provide a reliable order of modified block 140 creation without relying on conventional timestamps.”)(e.g., figures 1A-1C, 2A-2B and paragraphs [0046], [0049] and [0051]-[0053]).
- each second data block of the second persistent sequence different from an initial second data block of the second persistent sequence comprises a digest of the previous second data block in the second persistent sequence. (“Linked timestamping uses hash values in the modified block headers 128 to verify the proper block order, since hashes are based on previous blocks and hash generation may be verified by a sequence of hashes.” “It is possible that the hash 148 may indicate a different source ledger 116 not identified within the merge request 124 (i.e. a different source ledger 116 that is not to be merged). In that case, the different source ledger 116 may be ignored, but linked back through hashes 148 until an identified source ledger 116 is found. The blocks corresponding to ignored source ledgers 116 are not to be included in the merged ledger 120, but the genesis block 132 would “link around” the ignored blocks. For example, if a linked series of hashes reflected a sequence of block 1 ledger 3->block 2 ledger 2->block 4 ledger 1, and ledger 2 was not to be included in a merge request 124 but ledgers 1 and 3 were, the genesis block 132 may include a linked series of hashes of block 1 ledger 3->block 4 ledger 1. In this way, the hashes 146 and 148 provide a cross-linking between the source ledgers 116A-116N in order to provide a reliable order of modified block 140 creation without relying on conventional timestamps.”)(e.g., figures 1A-1C, 2A-2B and paragraphs [0046], [0049] and [0051]-[0053]).
Regarding claim 8, Irazabal discloses the method of claim 1. Irazabal further discloses further comprising generating said digest of a data block and/or generating said further digest of a data block by applying a cryptographic hash function to said data block. (“When blockchains or source ledgers are merged, a genesis block for the resulting blockchain is generated and cryptographic proofs are included to demonstrate the interleaving of blocks (how blocks of source blockchains get ordered) is included into the genesis block of the resulting blockchain.”)(e.g., paragraphs [0039], [0041], [0099] and [0113]).
Regarding claim 10, Irazabal further discloses a computer program product comprising one or more computer readable storage media having program instructions collectively stored on the readable storage media, the program instructions being readable by a computing system to cause the computing system to perform the method according to claim 1. (e.g., paragraphs [0096]-[0097]).
Regarding claim 12, Irazabal further discloses a computing system comprising a circuitry for performing each step of the method according to claim 1. (“The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above.”)(e.g., paragraph [0096]).
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD L BOWEN whose telephone number is (571)270-5982. The examiner can normally be reached Monday through Friday 7:30AM - 4:00PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aleksandr Kerzhner can be reached at (571)270-1760. 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.
/RICHARD L BOWEN/ Primary Examiner, Art Unit 2165