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 Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites, “wherein the encoded blocks are encrypted as a group via a hashing function to prevent hacking and satisfy a chained input process; receiving, at the storage units of the distributed computer system, a transaction request associated with the data; and verifying the transaction request, via the hashing function and based on a decryption of the encoded data blocks stored in the storage units of the distributed computer system at the physically different sites.” Although the specification supports dispersed storage encoding, storage units at physically different sites, indefinite storage, and resource selection using a decentralized agreement protocol, the specification does not reasonably describe or enable the claimed combination of:
encrypting encoded blocks “as a group via a hashing function,”
using such hashing to “prevent hacking and satisfy a chained input process,”
receiving a “transaction request” associated with the data, and
verifying that transaction request based on a decryption of the encoded data blocks.
The specification describes encoded data slices, error coding parameters, data access requests, read/write/delete requests, decentralized agreement ranking, and slice migration, but it does not describe a hashing-based encryption scheme for a group of encoded blocks, nor does it describe a chained input process or a transaction-request verification workflow of the type recited in claim 1. Accordingly, the specification does not reasonably disclose the scope of claim 1.
Claim 2 depends from claim 1 and recites “determining, an association between the transaction request and an imposter encoded block; and deleting the imposter encoded block responsive to the transaction request.” The specification does not describe or support an “imposter encoded block” or any operation of determining an association between a transaction request and such an encoded block. The specification teaches identifying corrupted, missing, or bad encoded slices and rebuilding such slices, however does not provide written description support for the claimed “imposter encoded block” limitation. Accordingly, the specification does not reasonably disclose the scope of claim 2.
Claims 3-20 inherit the same rejection as claim 1-2 above for reciting similar limitations, or in light of their dependency.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Claim 1:
Regarding claim 1, the claim recites “encrypted as a group via a hashing function” and further recites “verifying the transaction request, via the hashing function and based on a decryption of the encoded data blocks.” Examiner respectfully notes that the specification fails to disclose how (1) encryption is being performed via a hashing function (2) verifying the transaction by decryption of a hash function output, with sufficient detail to enable one of ordinary skill in the art to practice the claimed invention without undue experimentation. The specification describes dispersed storage encoding, and resource selection using a decentralized agreement, it does not adequately teach how to implement the claimed combination of encryption via a hashing function, a chained input process, or verification of a transaction request based on decryption of the encoded data blocks. The specification discloses hashing functions in the context of decentralized agreement ranking, and encoding/decoding of data slices in a dispersed storage network, but it does not provide sufficient detail regarding the claimed security and verification workflow to enable one of ordinary skill in the art to practice the scope of claim 1 without undue experimentation.
Claim 2:
Claim 2 depends from claim 1 and further recites “determining, an association between the transaction request and an imposter encoded block; and deleting the imposter encoded block responsive to the transaction request.” The specification does not describe an “imposter encoded block” or teach how such a block would be detected, associated with a transaction request, or deleted in response to the transaction request. The specification instead discusses bad, corrupt, or missing encoded slices and rebuilding such slices, which is different from the claimed subject matter. Accordingly, the specification does not enable the full scope of claim 2 without undue experimentation.
Examiner respectfully enters the following references to show that hashing functions are one way and cannot be decrypted.
encryption - Can SHA or MD5 results be decrypted? - Cryptography Stack Exchange
“MD5, SHA-1, SHA-256, etc. are one-way functions: given the hash of an input, nobody knows how to find the input better than by guessing, and the best cryptographers in the world have tried. But guessing is always a possibility. You just try a lot of inputs until you find one with the desired hash value. If the input is a member of a small set, for example if you know it's a dictionary word, this can be done very quickly. On the other hand, if the input includes enough unknown bits, it's unfeasible. For example, if the input includes 128 random bits, then it would take a billion PCs about the age of the universe¹ to get a decent chance of finding the right input.”
“To add to Gilles and mentallurg answers: Hash functions can not be decrypted also in sense that there are infinitively (or nearly infinitively) many inputs that give the same output (since the size of input is arbitrary or nearly arbitrary and length of output is fixed), so you'll never know which one is the "right" one.”
Cryptography: Encryption and Hashing – Information Technology
“Hashing is a one-way (non-reversible) conversion of plaintext into an unreadable format often called hexadecimal notation. Hexadecimal or hex for short, is a base-16 numbering system (multiples of 16) combination of numbers (0-9) and letters (A-F) that represent bigger numbers. The main objective of hashing is to verify the integrity of data (that it hasn’t changed). This process happens by data, inputting that into a hashing function (mathematical formula) that outputs a fixed-length string of hex characters.”
Examiner notes that there are implementations that improve the odds or side step the issues for lengthy computations, all of which would require some form of undue experimentation.
some non-exhaustive examples:
One would be the use of a look-up table to reproduce the original data input into the hashing function. But that raises other issues (1) the specification is silent on any such operations, and (2) the specification is silent on what decryption means and therefore adopting the basic definition in the art, reversing the process of encryption, the claims would conflict with the basic definition. Using lookup tables and decryption are different processes. (3) these definitions and interpretations as also absent from the parents cases as well.
Another possible avenue is using quantum computing, which also is neither discussed in the specifications, claims, drawings, nor the parent applications.
Making the input very small, which also is neither discussed in the specifications, claims, drawings, nor the parent applications.
Therefore the specification fails to comply with the enablement requirement for how the applicant is decrypting the output of hashing function.
Claims 3-20 inherit the same rejection as claim 1-2 above for reciting similar limitations, or in light of their dependency.
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-20 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.
Regarding claim 1, the claim recites “encrypted as a group via a hashing function,” examiner respectfully points to the 112(a) rejections and notes that it is unclear if this is an encryption process or a hashing process as one is decryptable (reversible) and hash codes are not decryptable (non-reversible).
Regarding claim 1, the claim recites “storing data as encoded blocks in storage units of a distributed computer system at physically different sites and for an indefinite period of time.” The term “indefinite period of time” does not define any meaningful boundary. A review of the specification provides no explanation/definition of what “an indefinite period of time” means in context. Therefore, the term is indefinite.
Regarding claim 2, the claim recites “determining, an association …” should recite “determining an association” as the comma makes the limitation syntactically incomplete, and in turn makes the scope unclear.
Claims 3-20 inherit the same rejection as claim 1-2 above for reciting similar limitations, or in light of their dependency.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zhuo et al. (US 20210119805 A1):
[0045] Before storing in a block, the transaction data is hashed. Hashing is a process of transforming the transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is not possible to un-hash the hash value to obtain the transaction data. Hashing ensures that even a slight change in the transaction data results in a completely different hash value. Further, and as noted above, the hash value is of fixed length. That is, no matter the size of the transaction data the length of the hash value is fixed. Hashing includes processing the transaction data through a hash function to generate the hash value. An example of a hash function includes, without limitation, the secure hash algorithm (SHA)-256, which outputs 256-bit hash values.
[0052] Asymmetric encryption uses keys pairs that each include a private key, and a public key, the private key being known only to a respective node, and the public key being known to any or all other nodes in the blockchain network. A node can use the public key of another node to encrypt data, and the encrypted data can be decrypted using other node's private key. For example, and referring again to FIG. 2, Participant A can use Participant B′s public key to encrypt data, and send the encrypted data to Participant B. Participant B can use its private key to decrypt the encrypted data (ciphertext) and extract the original data (plaintext). Messages encrypted with a node's public key can only be decrypted using the node's private key.
[0058] By using ECC, each of the blockchain nodes can store a portion of the encoded block data and retrieve the rest of the encoded block data from other blockchain nodes when needed. In some embodiments, the ECC can be performed when utilization rate of computational resource of the blockchain node 302 is lower than a predetermined value (e.g., 40%). As such, the interference with other computational operations on the blockchain node 302 can be reduced. In some embodiments, ECC can be performed when the usage of storage space of the blockchain node 302 is greater than or equal to a predetermined percentage, such that after ECC, some portions of the encoded block data can be deleted to free up storage space.
[0091] In some cases, the NVN further performs: receiving a request from the client node for verifying a transaction included in the one or more blocks; retrieving, based on the index, datasets associated with the one or more blocks from the remainder of the plurality of NVNs; decoding the one or more blocks based on the datasets; and verifying that the transaction exists if the transaction is included in the one or more blocks.
Adams, III et al. (US 20220191034 A1):
Technologies for trust protocol execution include a network of servers in communication with client devices. A client device splits a request into input data blocks, connects to a server, and sends an input data block to the server. The server encodes the input data block with an encoding pad to generate an encoded data block, generates a hash value as a function of the encoded data block, and modifies the encoding pad as a function of the hash value to generate a modified encoding pad. The server adds the encoded data block to a blockchain and returns an indication of the input data block stored on the blockchain. The server may add a verification puzzle based on a timestamp to the encoded data block. The server may request a security certificate from a certificate authority for a web address based on the hash value. Other embodiments are described and claimed.
[0054] The block encoder 206 is configured to encode the input data block with an encoding pad 216 to generate an encoded data block. The encoding pad 216 may comprise an array of byte values having a length equal to a maximum byte value (e.g., 256). The encoding pad 216 may be initialized with a predetermined pad value, such as an identity mapping. Encoding the input data block with the encoding pad 216 may include, for each input byte of the input data block to index the encoding pad 216 with the input byte to retrieve an output byte. The block encoder 206 is further configured to generate a hash value as a function of the encoded data block with a cryptographic hash function, and to modify the encoding pad 216 as a function of the hash value to generate a modified encoding pad 216. Modifying the encoding pad as a function of the hash value may include converting the hash value to a sequence of pairs of bytes, and for each pair of bytes, indexing the encoding pad 216 at a first byte index of the pair of bytes and at a second index of the pair of bytes, and swapping encoding pad 216 values at the first byte index and at the second byte index.
[0055] The chain manager 208 is configured to add the encoded data block to a blockchain. The encoded data block may be stored in blockchain data 218, which may be localized at the server device 102 or distributed among multiple locations. In some embodiments, adding the encoded data block to the blockchain may include determining a timestamp at microsecond resolution, adding the timestamp as a header to the encoded data block, generating a verification puzzle based on the timestamp and the encoding pad 216, and adding the verification puzzle to the encoded data block.
[0075] In block 508, the client device 104 sends the input data block to the server 102. The server 102 encodes the input data block and then stores the encoded data block to a blockchain, using the method described above in connection with FIG. 3. After the block is stored on the chain, in block 510 the client device 104 receives an indication of the block stored on the chain. The indication may be embodied as or otherwise include a hash value, a block number, a web address or other block identifier associated with the encoded data block stored on the blockchain.
[0103] In block 816, the client device 104 may encrypt message data associated with the request message using the client key 260 or otherwise protect the message data. The client device 104 may use any private key, session key, symmetric key, or other encryption technique to encrypt the message data. As described above, the server 102 may not need to access the plaintext contents of the input data in order to generate an encoded data block and store an immutable record of the input data on the blockchain. Accordingly, the message data (e.g., data files or other data) may be encrypted and thus protected from access by the server 102. As described above, the client device 104 may use any client key 260 for encrypting the message data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDERRAHMEN H CHOUAT whose telephone number is (571)431-0695. The examiner can normally be reached on Mon-Fri from 9AM to 5PM PST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
Abderrahmen Chouat
Examiner
Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights