DETAILED ACTION
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.
This Office Action is in response to the amendment filed on 01/07/2026.
Claims 1-27 have been canceled.
Claims 41-50 have been added.
Claims 28-29 have been allowed.
Claims 28-50 are pending for consideration.
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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Response to Arguments
Applicant's arguments filed on 1/7/2026 have been fully considered but they are not persuasive.
Applicant alleges on pages 12-15 of the Remarks that Applicant submits that non-statutory (obviousness-type) double patenting does not apply to first-inventor-to-file AIA patents and patent applications (e.g., “All the case law cited in the Office Action predates the AIA . No Federal Circuit decisions have extended the judicially created doctrine for first-to-invent pre-AIA patents and patent applications to first- inventor-to-file AIA patents and patent applications. Because the earliest effective filing date of the reference application (co-pending Application No. 19/043,352) is not earlier than the present application, the reference application is not prior art to the present application under AIA Section 102(a)(2). For all the reasons and arguments as set forth in the attached journal article by one of the named inventors of both these AIA applications, Applicant submits that non-statutory (obviousness-type) double patenting does not apply to these AIA applications. See, Pedersen, B. "How to Resolve Double Patenting," AIPLA Quarterly Journal, Winter 2025, pgs. 33-149, a copy of which is attached hereto, and the contents of which is fully incorporated by reference herein.”). Applicant further alleges that even if non-statutory (obviousness-type) double patenting was somehow applicable to these AIA applications, which it is not, the Office Action fails to establish a case that independent claim 30 of the present application and independent claim 1 of the reference application are "patentably indistinct."
Examiner respectfully disagrees with Applicant’s allegations. According to the MPEP 804 and CHART I-A (i.e., when examining an AIA application conflicting claims between two applications), included chart below, the non-statutory (obviousness-type) double patenting does apply between the instant application and co-pending application 19/043,352. Therefore, Applicant’s allegations are not persuasive.
PNG
media_image1.png
1357
1105
media_image1.png
Greyscale
Applicant further alleges that this DP rejection is improper. On page 14 of the Remarks, Applicant alleges that “there are no ranges of effective bits of security which are claimed or disclosed in independent claim 30 of the present application. Moreover, contrary to the requirements for examining range claims as set forth in MPEP 2144.05, the Office Action presents no prima facie case as to why independent claim 30 of the present application would make the claimed range of independent claim 1 of the reference application obvious”. Examiner respectfully disagrees. This nonstatutory double patenting rejection is appropriate where a claim in an application under examination claims subject matter that is different, but not patentably distinct, from the subject matter claimed in a prior patent or a copending application. The claim under examination is not patentably distinct from the reference claim(s) if the claim under examination is anticipated by the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 1052, 29 USPQ2d 2010, 2015-16 (Fed. Cir. 1993). This type of nonstatutory double patenting situation arises when the claim being examined is, for example, generic to a species or sub-genus claimed in a conflicting patent or application, i.e., the entire scope of the reference claim falls within the scope of the examined claim. In this situation, the entire scope of the reference claim 30 falls within the scope of the examined claim 1, see Claim comparison table below. Therefore, Applicant’s arguments have been considered but are not persuasive. The nonstatutory double patenting rejection has been maintained.
Claim 30:
A computer-implemented digital asset protection system configured to be executed by one or more computer systems to protect a set of original files of digital assets as incrypted data that is quantum cyber resilient, the digital asset protection system comprising:
a packager system operably configured to use a set of random seeds and a set of hybrid cryptography ciphers that includes at least one standard cipher and a plurality of non-standard ciphers to incrypt the set of original files as incrypted data in a set of ciphertexts with each ciphertext having a corresponding cryptex that includes information used to determine a dynamic cipher stack, a set of cipher keys, and a set of meta data unique to that ciphertext: and an unpackager system operably configured to dicrypt the incrypted data of each ciphertext in the set of ciphertexts using the corresponding cryptex to restore the set of original files.
Claim 1:
A computer-implemented digital asset protection system configured to be executed by one more computer systems to protect a set of original files of digital assets as incrypted data that is quantum cyber resilient, the digital asset protection system comprising:
a packager system operably configured to use a set of random seeds and a set of hybrid cryptography ciphers that includes at least one standard cipher and a plurality of non-standard ciphers to incrypt the set of original files as incrypted data in a set of ciphertexts with each ciphertext having a corresponding cryptex that includes information used to determine a dynamic cipher stack, a set of cipher keys, and a set of meta data unique to that ciphertext: and an unpackager system operably configured to dicrypt the incrypted data of each ciphertext in the set of ciphertexts using the corresponding cryptex to restore the set of original files,wherein the digital asset protection system provides more than 350 additional bits of security for data-in-transit products, and more than 500 additional bits of security for data-at-rest products beyond the 256 bits of security which AES-256 alone provides.
Applicant alleges on pages 16-17 of the Remarks that Srinivasan is about splitting data and teaches nothing about using a dynamic stack of multiple ciphers. There is no reference or discussion of the use of metadata as part of a cryptex.
In response to the above, Examiner respectfully disagrees. Paragraphs 0025 of Srinivasan reference teaches stream ciphers are implemented as RRSG functions. These ciphers are applied in sequence or interchangeable to protect data (stream ciphers, such as the Salsa stream cipher (e.g., the Salsa20 family of ciphers) and the ChaCha stream cipher (e.g., the ChaCha family of ciphers), can be implemented as RRSG functions. For example, these stream ciphers can be implemented with its initial states comprising of key, counter, and nonce derived from the Data Transformation Key. As another example, any symmetric encryption algorithm (such as AES) can be implemented as an RRSG function in counter mode by encrypting a known data-sequence. A known data sequence can simply be constant data (e.g., all bytes are 0x02) or could be hex digits of well-known data source such as PI, Log(2); Natural exponent; etc.; or it could be ever repeating sequence of some defined byte array of Size S. FIG. 3I illustrates an example of RRSG based on a Stream Cipher and how the counter can be changed to repeat ably generate random numbers based at any required offsets without having to start at the beginning. As another example, any symmetric encryption algorithm (such as AES) can be implemented as an RRSG function in counter mode by encrypting a known data-sequence. A known data sequence can simply be constant data (e.g., all bytes are 0x02) or could be hex digits of well-known data source such as PI, Log(2); Natural exponent; etc.; or it could be ever repeating sequence of some defined byte array of Size S. FIG. 3J shows an example of RRSG based on Symmetric Encryption (AES-256) of a constant data (all 0x02). Here the Key and Initialization vector (IV) are kept the same while the counter is incremented as we need more random bytes. Note we can directly generate any portion of the random byte sequence by simply incrementing the counter to the required levels.).
Regarding the argument about “there is no reference or discussion of the use of metadata as part of a cryptex” and “cryptex that includes information used to determine a dynamic cipher stack, a set of cipher keys, and a set of meta data unique to that ciphertext”, Examiner disagrees. Expanding from the previous citations, Srinivasan further teaches the split specification for reconstructing. Examiner broadly interprets it as the cryptex (See paragraphs 0023 and0034 and, “For example, an authenticated user may instruct a computing device to provide the identifier and parameters describing the split specification for reconstructing the file. In some embodiments, a simple split specification identifier can be used to identify (or determine) the parameters associated with the split specification.”… “a virtual volume specification and may contain various information. For example, in some embodiments, the split specification can include information describing a total number of splits to be generated for a file (n) and a minimum number of splits (m) required to reconstruct the file. In some embodiments, the split specification designates a minimum number of splits (m) to be greater than 1 and a total number of splits to be generated (n) to be greater than or equal to the minimum number of splits (m). … the split specification can include information describing a set of secret keys to be used with one or more transformation functions. In some embodiments, a transformation function can receive an identifier as input and can output an obfuscated identifier, as illustrated in the example of FIG. 3B. In such embodiments, the transformation function itself can have an internal key. …. In some embodiments, the split specification can include information describing corresponding secret keys associated with split stores. In some embodiments, an additional key can be associated at the split store level to further transform the identifier to provide additional obfuscation. … In some embodiments, the split specification can include information describing a Repeatable Random Sequence Generator (RRSG) parameter specification. An RRSG can be a function that produces a repeatable sequence of bytes when initialized with the same initial key and nonce. There are many ways to build an RRSG function and such RRSG functions can be included in the split specification. In an embodiment, an RRSG function is constructed using an initial key and nonce, as illustrated in the example of FIG. 3C. The initial key and nonce can be hashed using a standard hash function (e.g., SHA256) to produce a fixed amount of random bytes. The RRSG function can be adjusted to produce more random bytes by incrementing the nonce by one and then repeating the hashing process. In another embodiment, an RRSG function can be constructed by defining a set of PRNGs (Pseudo Random Number Generators) to be used. The defined PRNG can have a threshold randomness that satisfies some, or all, of the tests defined by Diehard or TestU01 random number test suites and have a long period. Some examples include XORShift, XORShiftStar, Mersenne Twister, and PCG family. In this embodiment, an initial key and nonce can be hashed to generate a different seed for each random number. Thus, given an initial key and a nonce, each random number is initialized with its own seed number. Further, random bytes can be generated from each random number and a bitwise XOR can be performed on the random number, as illustrated in the example of FIG. 3D. This can strengthen the random number while increasing the period. In addition, in some embodiments, the random numbers themselves can be transformed using well known transformation such as SBOX before or after combining the random numbers. These transformation provide defense against attacks to find the internal state of the random number generators.”).
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “There is no teaching or suggestion that these two independent examples of ciphers could be used as any kind of dynamically combined hybrid stack of ciphers used to "incrypt the set of original files as incrypted data" or "dicrypt the incrypted data of each ciphertext."”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant alleges that Srinivasan does not use either the term "decoy" or the term "noise". The citations to paras [0025, 0033 and 0038] of Srinvasan in Paragraph 15 of the Office Action do not explain how the split reconstruction module is "adding a set of decoy files to the set of original files."
Examiner respectfully disagrees. Since those citations discuss Figure 2 of Srinivasan reference, expanding from those citations, paragraph 0030 further teaches magic bytes. Based on these bytes, a module can automatically detect data errors that are malicious or tampered which is broadly mapped to the term "decoy" or the term "noise" as recited in the claims (paragraph 0030, “based on an RRSG function that is randomly seek-able, the data security module 202 can be configured to verify file streams using magic bytes. For example, a beginning of a file stream can be associated magic bytes. The file stream can end with a fixed byte sequence or a signature. The signature can be based on Cyclical Redundancy Check (CRC) methods, such as CRC32 or Adler32, or a digest, such as MD5, SHA1, SHA 256, etc. Based on these data security features, the data security module 202 can verify the integrity of data associated with the file stream as the data is streamed. That is, the data security module 202 can automatically detect data errors that are malicious, tampered, or otherwise. The data security module 202 can also detect a truncated file stream when processing valid, but incomplete data. This technique for verifying file streams based on magic bytes at the beginning followed by a signature at the end can be performed on both raw content prior to splitting and after splitting to the each of the split streams. This allows the system to automatically detect or isolate any errors to a specific split stream. For example, if a 3-out-5 threshold reconstruction scheme is being applied, knowing which stream is erroneous”).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
“means for packaging operably configured to use” and “means for unpackaging operably configured to decrypt…” in claim 41.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a package system”, “a quantum container unit” and “an unpackager system” in claim 28.
“a packager system”, “a quantum container unit” and “an unpackager system” in claim 29.
“a packager system” and “an unpackager system” in claim 30.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 30-39 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-13 of copending Application No. 19043352 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both applications disclose “a digital asset protection system configured to be executed by one or more computer systems to protect a set of original files of digital assets as incrypted data that is quantum cyber resilient”. For example, see the table below for a claim comparison between the instant application and copending application (bolded text indicates significant similarities of major feature in each invention).
Furthermore, Examiner notes that each and every limitation of the instant claims appear to be substantially anticipated by the corresponding claims of the copending application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application 18429369
Pending Application 19043352
Claim 30:
A computer-implemented digital asset protection system configured to be executed by one or more computer systems to protect a set of original files of digital assets as incrypted data that is quantum cyber resilient, the digital asset protection system comprising:
a packager system operably configured to use a set of random seeds and a set of hybrid cryptography ciphers that includes at least one standard cipher and a plurality of non-standard ciphers to incrypt the set of original files as incrypted data in a set of ciphertexts with each ciphertext having a corresponding cryptex that includes information used to determine a dynamic cipher stack, a set of cipher keys, and a set of meta data unique to that ciphertext: and
an unpackager system operably configured to dicrypt the incrypted data of each ciphertext in the set of ciphertexts using the corresponding cryptex to restore the set of original files.
Claim 1:
A computer-implemented digital asset protection system configured to be executed by one more computer systems to protect a set of original files of digital assets as incrypted data that is quantum cyber resilient, the digital asset protection system comprising:
a packager system operably configured to use a set of random seeds and a set of hybrid cryptography ciphers that includes at least one standard cipher and a plurality of non-standard ciphers to incrypt the set of original files as incrypted data in a set of ciphertexts with each ciphertext having a corresponding cryptex that includes information used to determine a dynamic cipher stack, a set of cipher keys, and a set of meta data unique to that ciphertext: and
an unpackager system operably configured to dicrypt the incrypted data of each ciphertext in the set of ciphertexts using the corresponding cryptex to restore the set of original files,wherein the digital asset protection system provides more than 350 additional bits of security for data-in-transit products, and more than 500 additional bits of security for data-at-rest products beyond the 256 bits of security which AES-256 alone provides.
The dependent claims 31-39 of the instant application recite language similar to the dependent claims 2-13 of the copending application and are covered by the copending application.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 30-31 and 40-42 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Srinivasan (US 20220103533) (hereinafter Srinivasan).
Regarding claim 30, Srinivasan a computer-implemented digital asset protection system configured to be executed by one or more computer systems to protect a set of original files of digital assets as incrypted data that is quantum cyber resilient (Srinivasan: paragraph 0017), the digital asset protection system comprising:
a packager system operably configured to use a set of random seeds and a set of hybrid cryptography ciphers that includes at least one standard cipher and a plurality of non-standard ciphers to incrypt the set of original files as incrypted data in a set of ciphertexts (Srinivasan: fig. 1; fig. 3A; paragraph 0025, “the ChaCha stream cipher (e.g., the ChaCha family of ciphers), can be implemented as RRSG functions. For example, these stream ciphers can be implemented with its initial states comprising of key, counter, and nonce derived from the Data Transformation Key. As another example, any symmetric encryption algorithm (such as AES) can be implemented as an RRSG function in counter mode by encrypting a known data-sequence”) with each ciphertext having a corresponding cryptex that includes information used to determine a dynamic cipher stack, a set of cipher keys, and a set of meta data unique to that ciphertext (Srinivasan: paragraphs 0034-0035, “the split reconstruction module 210 can use the file identifier to generate a split identifier by applying a transform function defined in the split specification using the file identifier as input as described above. This split identifier can then be used to initialize an RRSG function defined in the split specification as described above”): and
an unpackager system operably configured to dicrypt the incrypted data of each ciphertext in the set of ciphertexts using the corresponding cryptex to restore the set of original files (Srinivasan: paragraphs 0036-0038, “the split reconstruction module 210 can recover the Data Transformation key of size L as described above”… “for each byte (1 to L) in the Data Transformation key, the split reconstruction module 210 can recover only the polynomial coefficient a.sub.0. In such embodiments, the split reconstruction module 210 can perform some or all computations using GF(2.sup.8) using the prime polynomial generated using RRSG as described above”).
Regarding claim 41, claim 41 discloses a system claim that is substantially equivalent to the system of claim 30. Therefore, the arguments set forth above with respect to claim 30 are equally applicable to claim 41 and rejected for the same reasons.
Regarding claims 31 and 42, Srinivasan discloses wherein the packager system further includes a protocol of adding a set of decoy files to the set of original files, each decoy file formed of a random amount of random noise, and wherein the cryptex includes an indication for each file of the set of original files of whether the file is a decoy file (Srinivasan: paragraphs 0025, 0033 and 0038, “these stream ciphers can be implemented with its initial states comprising of key, counter, and nonce derived from the Data Transformation Key. As another example, any symmetric encryption algorithm (such as AES) can be implemented as an RRSG function in counter mode by encrypting a known data-sequence”… “the split reconstruction module 210 can use this Data Transformation key and nonce value 1 to reset the RRSG function. The split reconstruction module 210 can then reconstruct data (e.g., the file) from the m splits, as illustrated in the example of FIG. 3H. In some embodiments, for each byte of the m splits starting at offset L, the following computations are performed to recover the file.”)… paragraph 0030 further teaches magic bytes. Based on these bytes, a module can automatically detect data errors that are malicious or tampered which is broadly mapped to the term "decoy" or the term "noise" as recited in the claims (paragraph 0030, “based on an RRSG function that is randomly seek-able, the data security module 202 can be configured to verify file streams using magic bytes. For example, a beginning of a file stream can be associated magic bytes. The file stream can end with a fixed byte sequence or a signature. The signature can be based on Cyclical Redundancy Check (CRC) methods, such as CRC32 or Adler32, or a digest, such as MD5, SHA1, SHA 256, etc. Based on these data security features, the data security module 202 can verify the integrity of data associated with the file stream as the data is streamed. That is, the data security module 202 can automatically detect data errors that are malicious, tampered, or otherwise. The data security module 202 can also detect a truncated file stream when processing valid, but incomplete data. This technique for verifying file streams based on magic bytes at the beginning followed by a signature at the end can be performed on both raw content prior to splitting and after splitting to the each of the split streams. This allows the system to automatically detect or isolate any errors to a specific split stream. For example, if a 3-out-5 threshold reconstruction scheme is being applied, knowing which stream is erroneous”.
Regarding claim 40, Srinivasan discloses wherein the unpackager system is operably configured to be executed from a volatile memory and the set of original files is only restored into a volatile memory, and wherein the set of original digital assets includes one or more of data, code, databases, training sets, weighting sets, text, ciphertext that is hardware and/ or software encrypted data, digital content or digitally personal identifiable information, or any electronic or optical information in the form of a file, a record or an element as one of the set of digital assets that is at rest, in use or in transit (Srinivasan: paragraphs 0030-0035, "based on an RRSG function that is randomly seek-able, the data security module 202 can be configured to verify file streams using magic bytes. For example, a beginning of a file stream can be associated magic bytes. The file stream can end with a fixed byte sequence or a signature. The signature can be based on Cyclical Redundancy Check (CRC) methods, such as CRC32 or Adler32, or a digest, such as MD5, SHA1, SHA 256, etc. Based on these data security features, the data security module 202 can verify the integrity of data associated with the file stream as the data is streamed. That is, the data security module 202 can automatically detect data errors that are malicious, tampered, or otherwise. The data security module 202 can also detect a truncated file stream when processing valid, but incomplete data. This technique for verifying file streams based on magic bytes at the beginning followed by a signature at the end can be performed on both raw content prior to splitting and after splitting to the each of the split streams. This allows the system to automatically detect or isolate any errors to a specific split stream").
Reasons for Allowance
Claims 28-29 are allowed.
Claims 32-39 and 43-50 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: No art has been identified which reads on the claimed limitations of claims 32-39 and 43-50.
Conclusion
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 TRANG T DOAN whose telephone number is (571)272-0740. The examiner can normally be reached on Monday-Friday 7-4 ET.
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, Lynn D Feild can be reached on (571)272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TRANG T DOAN/Primary Examiner, Art Unit 2431
Prosecution Insights