DETAILED ACTION
Applicant's Remarks, filed 08/19/2025, have been fully considered. The following rejections and/or objections are either reiterated or newly applied in view of instant application amendments. They constitute the complete set presently being applied to the instant application. Herein, "the previous Office action" refers to the Non-Final rejection of 05/19/2025.
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 .
Claim Examination Status
Claims 1-2 and 5-10 are currently pending and under exam herein.
Claim 4 is newly cancelled, and claims 3 and 11-20 are previously canceled.
Claims 1-2 and 5-10 are rejected.
Withdrawn Rejections/Objections
Rejections and/or objections not reiterated from previous office actions are hereby withdrawn in view of the 08/19/2025 amendments and Applicant’s remarks.
All rejections of claim 4 is hereby withdrawn; its cancellation moots the rejections.
Upon further consideration, newly applied rejections/portions are necessitated by the instant amendments, as discussed below.
Priority
As previously discussed, no priority was claimed; therefore, all claims 1-2 and 4-10 were examined for an effective filing date of 01/22/2021, the filing date of the instant application.
Terminal Disclaimer
The terminal disclaimer filed on 03/03/2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of U.S. Patent No. 12,040,055 (Vishwakarma) was reviewed and recorded on 03/04/2025.
Remarks regarding 35 USC § 101
As previously discussed, claims 1-2 and 4-10 are free from rejection under 35 U.S.C. 101 as discussed in the 12/04/2024 Office Action. Independent claim 1 is a method of storing digital data in DNA storage using blockchain technology which incorporate practical integration in both storing metadata in the blockchain (a technology composed of particular machine/system architecture with necessary hardware components), and steps which culminate in the tangible and active step of synthesizing the deduplicated nucleotides for storage in the DNA storage as actual data. Therefore, claims 1-2 and 4-10 are patent-eligible.
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 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.
Note on formatting: citations from the instant application are italicized in the following section.
A. Claims 1-2 and 5-10, are rejected under 35 U.S.C. 103 as being unpatentable over Limbachiya et al. (2015: Natural data storage: A review on sending information from now to then via nature. arXiv preprint arXiv:1505.04890, 17 pages; PTO-892 document, herein Limbachiya), in view of Chen et al. (2019: Gencore: an efficient tool to generate consensus reads for error suppressing and duplicate removing of NGS data; PTO-892 document, herein Chen) and Cogo, et al. (2020: GenoDedup: Similarity-Based Deduplication and Delta-Encoding for Genome Sequencing Data; PTO-892 document, herein Cogo); and in further view of Ozercan et al (2018: Realizing the potential of blockchain technologies in genomics; PTO-892 document, herein Ozercan). Any newly applied rejection/portion is necessitated by instant application amendment.
Regarding instant claim 1, the instant application recites a method of storing digital data in DNA storage comprising:…
receiving the digital data from a user; first deduplicating the digital data in a deduplication system of the user to form source deduplicated data to reduce an amount of the digital data to be stored; encoding the deduplicated data into a DNA string comprising nucleotide sequences formatted in a Binary Aligned Map (BAM) file format for storage of the metadata;
second deduplicating the nucleotide sequences using a hybrid process comprising similarity-based deduplication with delta-encoding to reduce a number of nucleotides to represent the digital data by parsing the BAM file to create metadata and actual data, and compressing the metadata to create compressed metadata and hashing the actual data to create hashed data;
selecting, as part of the similarity-based deduplication, a nearest base chunk for each sequence in the BAM file using a selected data structure of first a Key-Value Store (KVS) index and then a Locality-Sensitive Hashing (LSH) index to retrieve deduplication candidates using content hashes of the candidates as keys;
deploying a smart contract for the second deduplicating the nucleotide sequences; selecting candidates for the second deduplicating using the smart contract to further reduce the digital data from the first deduplicating; encoding the second deduplicate as the metadata on a blockchain;
performing an edit operation to the delta-encoding at a destination for the storage to compress the metadata for writing as an entry to the blockchain;
determining whether or not the next block in the blockchain agrees with the smart contract; storing the metadata as a next block in the blockchain when the next block agrees with the smart contract;
synthesizing the deduplicated nucleotides for storage in the DNA storage as the actual data, wherein the metadata in the blockchain references corresponding actual data stored in the DNA storage; and storing the actual data in the DNA storage using deduplication processes of the deduplication system.
The prior art to Limbachiya teaches methods for storing data in DNA (Abstract). DNA can be used to store any kind of data, including metadata for the input data that refers to actual data stored in the DNA with backup (pg. 4 par 1), so that input data can be text data converted to binary data (pg. 6 par 1), then oligonucleotide sequence (trinucleotide Base_3, oligonucleotide technology) (encoding the deduplicated data into a DNA string comprising nucleotide sequences), and ultimately, converted to DNA sequences of synthesized nucleotide sequences (pg. 6 section 2.1.4 par 1, and Fig 5) containing primers to uniquely identify DNA segments where certain data is encoded (section 2.1.4 par 1) (synthesizing the deduplicated nucleotides for storage in the DNA storage as actual data).
However, Limbachiya does not teach deduplicating data, using hybrid similarity- based deduplication with delta-encoding, by parsing the BAM file to create metadata and actual data; compressing the metadata to create compressed metadata and hashing the actual data to create hashed data; selecting, as part of the similarity-based deduplication, a nearest base chunk for each sequence in the BAM file using a selected data structure of first a Key-Value Store (KVS) index and then a Locality-Sensitive Hashing (LSH) index to retrieve deduplication candidates using content hashes of the candidates as keys; selecting candidates for the second deduplicating using the smart contract to further reduce the digital data from the first deduplicating; encoding the second deduplicate as the metadata on a blockchain; performing an edit operation to the delta-encoding at a destination for the storage to compress the metadata for writing as an entry to the blockchain; determining whether or not the next block in the blockchain agrees with the smart contract; and storing the metadata as a next block in the blockchain when the next block agrees with the smart contract.
The prior art to Chen teaches a method for deduplicating data (Abstract), thereby producing deduplicated data (first deduplicating the digital data in a deduplication system of the user to form source deduplicated data).
Neither Limbachiya nor Chen teaches using similarity- based deduplication with delta-encoding. However, Cogo teaches a second deduplicating the nucleotide sequences using a hybrid process comprising similarity-based deduplication with delta-encoding to reduce a number of nucleotides to represent the digital data; selecting, as part of the similarity-based deduplication, a nearest base chunk for each sequence in the BAM file using a selected data structure of first a Key-Value Store (KVS) index and then a Locality-Sensitive Hashing (LSH) index to retrieve deduplication candidates using content hashes of the candidates as keys; and performing an edit operation to the delta-encoding at a destination for the storage to compress the metadata for writing as an entry to the blockchain.
The prior art to Cogo teaches a data storage method for genome sequencing data that integrates locality sensitive hashing and delta encoding for similarity-based deduplication (Abstract, pg. 670 col 1 par 5using key-value pairs for locality sensitive hashing/LSH (pg. 674 section 5.1) (second deduplicating the nucleotide sequences using a hybrid process comprising similarity-based deduplication). Cogo further describes similarity-based deduplication with delta encoding: “stores (1) a pointer to the most similar entry together with (2) the minimal list of modifications to restore the original object from this entry. This most similar entry is known as the base chunk…” based on distance metrics (such as Hamming, Levenshtein). These distance metrics use a list of edit operations to restore the original data from the base chunk (pg. 673: 4.2 Col 1-2) (performing an edit operation to the delta-encoding at a destination for the storage to compress the metadata for writing as an entry to the blockchain). Cogo’s GenoDedup architecture (FIG 2) also uses two auxiliary data structures: LSH to reduce the number of candidate comparisons in deduplication to optimize searches and KVS to index unique entries and to retrieve the deduplication candidate value using their content hashes as keys and returns the list of candidates with their content. With the best candidate/smallest edit distance determined by the deduplication algorithm, the edit operation calculated from the FASTQ file and the best candidate converts the edit operations to the delta-encoding and in parallel the deduplication component compresses the comment line. At the end, the component is joined with the deduplicated, and compressed version of the comment, DNA, and QS lines, then sent as a reduced entry to storage and writes the entry in the deduplicated file. Further details on restoring the entry are on pg. 675 and stored in FASTQ files on disk (pg. 674: 5.1 Col 1 para 1 and Col 2 para 1-2) (selecting, as part of the similarity-based deduplication, a nearest base chunk for each sequence in the BAM file using a selected data structure of first a Key-Value Store (KVS) index and then a Locality-Sensitive Hashing (LSH) index to retrieve deduplication candidates using content hashes of the candidates as keys).
Limbachiya’s data storage with DNA, Chen’s first deduplicating data process, nor Cogo’s second similarity- based deduplication with delta-encoding teach smart contract data filtering and storage. However, Ozercan teaches (BAM) file format…storing the metadata as a next block in the blockchain when the next block agrees with the smart contract.
The prior art to Ozercan teaches storing genetic data formatted in a Binary Aligned Map (BAM) file format for storage of the metadata for inserting into blocks of a blockchain (Abstract; pg. 1261 col 1 par 3). Genetic data storage with a decentralized blockchain and analysis, such as CrypDist and CGT, can separate and store data based on the type of data [p1261 Col 1 para 3-4: “summary data such as somatic cancer variation data are kept and distributed in a blockchain. Genomic privacy is achieved through information hiding by sharing only somatic variation and hiding the germline variation… inserting only public data (metadata) to the blockchain and concealing all identifiable information of the patients (actual data). CrypDist, on the other hand, also includes mechanisms to share large underlying data (such as BAM files or full-genome VCF files)] (by parsing the BAM file to create metadata and actual data). Note that inserting terabytes or petabytes of additional data to the blockchain is infeasible; instead, CrypDist only keeps links to the large files. Additionally, CrypDist proposes to make use of content delivery networks (CDN) to store and backup these large files (method of compressing data) to prevent their loss. If the security of these files is of concern, it is possible to further encrypt the files (compressing the metadata to create compressed metadata).
Ozercan teaches smart contracts are sets of instructions that are enforced when certain conditions are met (deploying a smart contract for the second deduplicating the nucleotide sequences) and whose authenticity, conditions, and necessities can be observed and approved by everyone. A smart contract operates as an autonomous account on the blockchain. It has a dedicated storage to keep details, objects, and information related to its application. Transactions that are addressed to a smart contract cause an activation and the contract updates the records depending upon its predefined instructions (p1257 Box 2) (selecting candidates for the second deduplicating using the smart contract to further reduce the digital data from the first deduplicating; encoding the second deduplicated nucleotide sequence
PNG
media_image1.png
3
2
media_image1.png
Greyscale
s into a format for storage as the metadata on a blockchain). Ozercan teaches blockchain application, including the example of the Coinami project in genomic high-throughput sequence read mapping which reanalyzes existing data as well as newly generated data with tools and reference databases to check for validity of alignments (p1259 Col 1 and FIG 2 (determining whether or not the next block in the blockchain agrees with the smart contract; storing the metadata as a next block in the blockchain when the next block agrees with the smart contract).
Therefore, it would have been prima facie obvious to someone of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified or combined Limbachiya’s DNA pool data storage, to incorporate Chen’s first deduplicating data process and Cogo’s second similarity- based deduplication with delta-encoding, according to smart contracts Ozercan’s BAM file data analysis and blockchain storage, to achieve the claimed invention, because Chen’s deduplicated data saves memory while suppressing errors (Chen, Abstract), Cogo’s deduplicating similarity based delta encoding hashed data reduces genomic storage requirements using LSH and KSV data structures, which allows for faster retrievals from FASTQ files (Cogo, Abstract), and Ozercan’s smart contract analysis of BAM file genomic data stores filtered data in secure blockchains (Ozercan, Abstract). There is a reasonable expectation of success because said prior art are analogously applicable to optimizing nonredundant digital data storage with DNA libraries and blockchain technology. Therefore, the invention is prima facie obvious.
Regarding instant claim 2, the instant application recites:
wherein the DNA storage comprises DNA pools for storage of synthesized genetic data as the actual data.
The prior art to Limbachiya teaches DNA can be used to store any kind of data, including metadata from the input data that refers to actual data stored in the DNA (Pg. 4 par 1), and synthesis of DNA for storage (pg. 6 par 1, pg. 13 section 6). Synthesized DNA sequences (pg. 6 section 2.1.4 par 1, and Fig 5) can contain primers to uniquely identify DNA segments where certain data (actual data) is encoded (section 2.1.4 par 1).
Regarding instant claim 5, the instant application recites:
further comprising calculating a hash of data in each sequence of the nucleotide sequences in the BAM file.
The prior art to Limbachiya teaches DNA can be used to store any kind of data, including metadata from the input data that refers to actual data stored in the DNA (Pg. 4 par 1), and synthesis of DNA for storage (pg. 6 par 1, pg. 13 section 6).
However, Limbachiya does not teach hashing sequence data with blockchain technology.
The prior art to Cogo teaches a data storage method for genome sequencing data that integrates locality sensitive hashing and delta encoding for similarity-based deduplication (Abstract, pg. 670 col 1 par 5) using key-value pairs for locality sensitive hashing (pg. 674 section 5.1).
The prior art to Ozercan teaches storing genetic data formatted as BAM files for inserting into blocks of a blockchain (Abstract; pg. 1261 col 1 par 3).
Regarding instant claim 6, the instant application recites:
further comprising: sending the hash to the LSH; obtaining an internal LSH key from the hash; querying a respective LSH hash index; and appending a list of pointers to candidates in a list.
The prior art to Limbachiya teaches DNA can be used to store any kind of data (Pg. 4 par 1), and synthesis of DNA for storage (pg. 6 par 1, pg. 13 section 6).
However, Limbachiya does not teach including using key/value pairs for locality similarity hashing and querying hash data.
The prior art to Ozercan teaches storing genetic data formatted as BAM files for indexing in blocks of a blockchain (Abstract; pg. 1261 col 1 par 3).
The prior art to Cogo teaches a data storage method for genome sequencing data that integrates locality sensitive hashing and delta encoding for similarity-based deduplication (Abstract, pg. 670 col 1 par 5) using key-value pairs for locality sensitive hashing (pg. 674 section 5.1).
Regarding instant claim 7, the instant application recites:
wherein the KVS indexing uses unique entries in a similarity search and retrieves values of candidates for deduplication using respective content hashes as keys.
The prior art to Limbachiya teaches DNA can be used to store any kind of data, including metadata from the input data that refers to actual data stored in the DNA (Pg. 4 par 1), and synthesis of DNA for storage (pg. 6 par 1, pg. 13 section 6).
However, Limbachiya does not teach including using key/value pairs for locality similarity hashing and querying hash data.
The prior art to Ozercan teaches storing genetic data formatted as BAM files for indexing in blocks of a blockchain (Abstract; pg. 1261 col 1 par 3).
The prior art to Cogo teaches a data storage method for genome sequencing data that integrates locality sensitive hashing and delta encoding for similarity-based deduplication (Abstract, pg. 670 col 1 par 5) using key-value pairs for locality sensitive hashing (pg. 674 section 5.1).
Regarding instant claim 8, the instant application recites:
further comprising calculating an edit distance between each candidate of the candidates using the delta encoding process.
The prior art to Limbachiya teaches DNA can be used to store any kind of data, including metadata from the input data that refers to actual data stored in the DNA (Pg. 4 par 1), and synthesis of DNA for storage (pg. 6 par 1, pg. 13 section 6).
However, Limbachiya does not teach hashing sequence data with blockchain technology.
The prior art to Ozercan teaches storing genetic data formatted as BAM files for inserting into blocks of a blockchain (Abstract; pg. 1261 col 1 par 3).
The prior art to Cogo teaches a data storage method for genome sequencing data that integrates locality sensitive hashing and delta encoding for similarity-based (edit-distance) deduplication (Abstract, pg. 670 col 1 par 5) using key-value pairs for locality sensitive hashing (pg. 674 section 5.1).
Regarding instant claim 9, the instant application recites:
combining metadata with the data hashed by the LSH to form reduced data; sending the reduced data to the DNA storage; and writing an entry for the reduced data as the next block in the blockchain.
The prior art to Limbachiya teaches DNA can be used to store any kind of data, including metadata from the input data that refers to actual data stored in the DNA (Pg. 4 par 1), and synthesis of DNA for storage (pg. 6 par 1, pg. 13 section 6).
However, Limbachiya does not teach hashing sequence data/metadata with blockchain technology, inserted as reduced data.
The prior art to Cogo teaches a data storage method for genome sequencing data that integrates locality sensitive hashing, key-value pairs (pg. 674 section 5.1), and delta encoding for similarity-based deduplication (reduced data) (Abstract, pg. 670 col 1 par 5).
The prior art to Ozercan teaches inserting genetic data into blocks of a blockchain (Abstract; pg. 1261 col 1 par 3),
Regarding instant claim 10, the instant application recites: wherein the data comprises Apocalypse Day Data (ADD) and the DNA storage comprises DNA storage pools.
The prior art to Limbachiya teaches DNA can be used to store any kind of data (including data that meet the specification’s definition of apocalypse day data; pg. 4 par 1), and synthesis of DNA for storage (pg. 6 par 1, pg. 13 section 6) and that DNA (synthetic or otherwise) can be embedded in non-coding DNA, protein coding DNA, or synthetic DNA (pg. 2 sec 2.1). This DNA data can be long term, secured, and stable under extreme conditions (Table II pg. 15). Further, Limbachiya teaches storing data in a bacteria genome as a benefit, due to ability of bacteria to survive nuclear radiation, high temperature, deep under soil and water and in any other hazardous condition (pg. 11 par 1).
Response to 102/103 Remarks
The Applicant's Remarks [p.5-6], filed 08/19/2025, have been fully considered regarding the previous Office Action. The Applicant’s assertions, regarding independent claim 1, and their dependent claims, that the prior art to Limbachiya in view of Chen, Cogo, and Ozercan did not “does not describe with enough detail a hybrid compression process as currently claimed. It further does not teach or suggest ‘using a selected data structure of first a Key-Value Store (KVS) index and then a Locality-Sensitive Hashing (LSH) index to retrieve deduplication candidates using content hashes of the candidates as keys”, were not persuasive as set forth in above rejection. The prior art to Limbachiya teaches methods for storing data in p (pg. 4 par 1), so that input data can be text data converted to binary data (pg. 6 par 1), then oligonucleotide sequence (trinucleotide Base_3; oligonucleotide technology). Chen teaches a first deduplication, Cogo similarity based deduplication with edit operations in LSH/KSV structures with smart contracts in Ozercan.
Any newly recited portions or rejections, as set forth above, are necessitated by instant application amendments.
Conclusion
No claims are allowed.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
E-mail Communications Authorization
Per updated USPTO Internet usage policies, Applicant and/or applicant’s representative is encouraged to authorize the USPTO examiner to discuss any subject matter concerning the above application via Internet e-mail communications. See MPEP 502.03. To approve such communications, Applicant must provide written authorization for e-mail communication by submitting following form via EFS-Web or Central Fax (571-273-8300): PTO/SB/439. Applicant is encouraged to do so as early in prosecution as possible, so as to facilitate communication during examination.
Written authorizations submitted to the Examiner via e-mail are NOT proper. Written authorizations must be submitted via EFS-Web or Central Fax (571-273-8300). A paper copy of e-mail correspondence will be placed in the patent application when appropriate. E-mails from the USPTO are for the sole use of the intended recipient, and may contain information subject to the confidentiality requirement set forth in 35 USC § 122. See also MPEP 502.03.
Inquiries
Papers related to this application may be submitted to Technical Center 1600 by facsimile transmission. Papers should be faxed to Technical Center 1600 via the PTO Fax Center. The faxing of such papers must conform to the notices published in the Official Gazette, 1096 OG 30 (November 15, 1988), 1156 OG 61 (November 16, 1993), and 1157 OG 94 (December 28, 1993) (See 37 CFR § 1.6(d)). The Central Fax Center Number is (571) 273-8300.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Vy Rossi, whose telephone number is (703) 756-4649. The examiner can normally be reached on Monday-Friday from 8:30AM to 5:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Olivia Wise can be reached on (571) 272-2249. Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to (571) 272-0547.
Patent applicants with problems or questions regarding electronic images that can be viewed in the Patent Application Information Retrieval system (PAIR) can now contact the USPTO’s Patent Electronic Business Center (Patent EBC) for assistance. Representatives are available to answer your questions daily from 6 am to midnight (EST). The toll free number is (866) 217-9197. When calling please have your application serial or patent number, the type of document you are having an image problem with, the number of pages and the specific nature of the problem. The Patent Electronic Business Center will notify applicants of the resolution of the problem within 5-7 business days. Applicants can also check PAIR to confirm that the problem has been corrected. The USPTO’s Patent Electronic Business Center is a complete service center supporting all patent business on the Internet. The USPTO’s PAIR system provides Internet-based access to patent application status and history information. It also enables applicants to view the scanned images of their own application file folder(s) as well as general patent information available to the public.
/VR/
Examiner
Art Unit 1685
/MARY K ZEMAN/Primary Examiner, Art Unit 1686