DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Clams 1-20 are presented for examination (filed on 09 July 2025).
Priority
It is acknowledged that the pending application claims priority to provisional application 61/769595 filed on 26 February 2013. Priority date of 26 February 2013 is given.
Claim Rejections - 35 USC § 103
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-10 and 13-20, are rejected under 35 U.S.C. 103(a) as being unpatentable over of Gladwin et al. (U.S. Pub. No.: US 20110125771, hereinafter Gladwin), in view of Grube et al. (U.S. Pub. No.: US 20110078512, hereinafter Grube).
For claim 1, Gladwin discloses a method comprising:
storing a plurality of encrypted data, wherein each encrypted data of the plurality of encrypted data is generated based on encrypting corresponding underlying data (Gladwin: paragraphs [0038], “The DS managing unit 18 performs distributed network data storage management functions, which include establishing distributed data storage parameters, performing network operations, performing network administration, and/or performing network maintenance. The DS managing unit 18 establishes the distributed data storage parameters (e.g., allocation of virtual DSN memory space, distributed storage parameters, security parameters, billing information, user profile information, etc.) for one or more of the user devices 12-14 (e.g., established for individual devices, established for a user group of devices, established for public access by the user devices, etc.). For example, the DS managing unit 18 coordinates the creation of a vault (e.g., a virtual memory block) within the DSN memory 22 for a user device (for a group of devices, or for public access). The DS managing unit 18 also determines the distributed data storage parameters for the vault. In particular, the DS managing unit 18 determines a number of slices (e.g., the number that a data segment of a data file and/or data block is partitioned into for distributed storage) and a read threshold value (e.g., the minimum number of slices required to reconstruct the data segment)”
paragraphs [0063], “The grid module 82 receives the data segments and may manipulate (e.g., compression, encryption, cyclic redundancy check (CRC), etc.) each of the data segments before performing an error coding function of the error coding dispersal storage function to produce a pre-manipulated data segment. After manipulating a data segment, if applicable, the grid module 82 error encodes (e.g., Reed-Solomon, Convolution encoding, Trellis encoding, etc.) the data segment or manipulated data segment into X error coded data slices 42-44”);
storing a plurality of data tags corresponding to the plurality of encrypted data (Gladwin: paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”
WHERE “tag” is broadly interpreted as “data identifier,” “data object names,” “data type” and “a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator”);
receiving, from a client device: first data (Gladwin: paragraphs [0091], “The method continues at step 104 where the processing module determines whether substantially identical data is currently stored in a dispersed storage network (DSN) memory. For instance, the processing module determines whether another user device has already stored the data object (or a very similar version of the data object) in the DSN memory. Such a determination includes at least one of determining whether a data identifier associated with the data substantially matches a data identifier associated with the substantially identical data, determining whether a calculated hash of the data substantially matches a stored hash of the substantially identical data, and comparing the data to substantially identical data. The determination may be further based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, the user ID, the identity of the requesting device, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator.” paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”); and
a first data tag corresponding to the first underlying data of the first data (Gladwin: paragraphs [0091], “The method continues at step 104 where the processing module determines whether substantially identical data is currently stored in a dispersed storage network (DSN) memory. For instance, the processing module determines whether another user device has already stored the data object (or a very similar version of the data object) in the DSN memory. Such a determination includes at least one of determining whether a data identifier associated with the data substantially matches a data identifier associated with the substantially identical data, determining whether a calculated hash of the data substantially matches a stored hash of the substantially identical data, and comparing the data to substantially identical data. The determination may be further based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, the user ID, the identity of the requesting device, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator.” paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”);
processing the first data tag to determine whether the first underlying data is already stored as the corresponding underlying data of any of the plurality of encrypted data (Gladwin: paragraphs [0091], “The method continues at step 104 where the processing module determines whether substantially identical data is currently stored in a dispersed storage network (DSN) memory. For instance, the processing module determines whether another user device has already stored the data object (or a very similar version of the data object) in the DSN memory. Such a determination includes at least one of determining whether a data identifier associated with the data substantially matches a data identifier associated with the substantially identical data, determining whether a calculated hash of the data substantially matches a stored hash of the substantially identical data, and comparing the data to substantially identical data. The determination may be further based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, the user ID, the identity of the requesting device, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator.” paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”
paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”);
storing the first data based on determining the first underlying data is not already stored as other underlying data of the any of the plurality of encrypted data via processing the first data tag (Gladwin: paragraph [0091], paragraphs [0104]-[0106], “The method continues to step 142 when the processing module determines that the data object is substantially not already stored in the DSN memory…At step 142, the processing module determines write operational parameters and saves the parameters (e.g., so that the processing module has a way to retrieve the data object). Such a determination may be based on one or more of an estimation of a number of common users that may store this same data object, a user ID, a store request, a vault lookup, a predetermination, a command, the data object name, a data size, a data type, the hash of the data object, a priority indicator, a security indicator, and a performance indicator. For example, the processing module determines the write operational parameters to include a pillar width of n=32 and a read threshold of 24 when the estimation of the number of common users that may store this same data object is 5 million. Note that there are over 10 million ways to choose 24 read pillars from the 32 pillars. The processing module saves the write operational parameters, hash of the data object, and data object name in a vault, the list of hash values of previously stored data objects, and/or in the DSN memory for reference when subsequently determining if the data object is already stored in the DSN memory”);
receiving a read data request from the client device for the first encrypted data (Gladwin: paragraph [0097], “FIG. 8 is a flowchart illustrating an example of retrieving a data object. The method begins at step 118 where a processing module receives, from a requesting device, a read request for data stored as a plurality of sets of encoded data slices in a dispersed storage network (DSN) memory. Note that the read request may include one or more of a read request command, a user ID, a data object name, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and a performance indicator”); and
sending a read data response to the client device that includes the first encrypted data, wherein the client device accesses the first underlying data based on decrypting the first encrypted data. (Gladwin: paragraph [0091], “The method continues”)
(Gladwin: paragraphs [0091], “The method continues at step 104 where the processing module determines whether substantially identical data is currently stored in a dispersed storage network (DSN) memory. For instance, the processing module determines whether another user device has already stored the data object (or a very similar version of the data object) in the DSN memory. Such a determination includes at least one of determining whether a data identifier associated with the data substantially matches a data identifier associated with the substantially identical data, determining whether a calculated hash of the data substantially matches a stored hash of the substantially identical data, and comparing the data to substantially identical data. The determination may be further based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, the user ID, the identity of the requesting device, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator.”
paragraphs [0100], “If a favorable number of encoded data slices are received, the method continues at step 128 where the processing module decodes the received encoded data slices to produce a decoded data segment…Alternatively to steps 128 and 130, the processing module sends the sub-set of encoded data slices to the requesting device, which decodes them to recapture the data segment.…”)
However, Gladwin does not explicitly receiving, from a client device: first encrypted data, wherein the first encrypted data is generated based on encrypting first underlying data.
Grube discloses receiving, from a client device: first encrypted data, wherein the first encrypted data is generated based on encrypting first underlying data (Grube: paragraph [0097], “[0097] In an example of a write operation, the DS processing of the DS unit receives an encoded slice to store. For example, the DS unit may receive an encoded slice from a user device for storage in the DS unit. The method begins with the step where the DS processing determines if the DS unit operating system is running. The method branches to the step where the DS processing selects one of the plurality of memory devices for storing the encoded slice when the DS processing determines that the DS unit operating system is running. The DS processing may retrieve slices of at least a portion of the operating system from one or more of the memories when the DS processing determines that the operating system is not running. The DS processing may decode the retrieved slices of the at least a portion of the operating system in preparation for execution as required.”)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to improve upon “DATA DE-DUPLICATION IN A DISPERSED STORAGE NETWORK UTILIZING DATA CHARACTERIZATION” as taught by Gladwin by implementing “METHOD AND APPARATUS FOR DISPERSED STORAGE MEMORY DEVICE UTILIZATION” as taught by Grube, because it would provide Gladwin’s method with the enhanced capability of “…supports three primary functions: distributed network data storage management, distributed data storage and retrieval, and data storage integrity verification. In accordance with these three primary functions, data can be distributedly stored in a plurality of physically different locations and subsequently retrieved in a reliable and secure manner regardless of failures of individual storage devices, failures of network equipment, the duration of storage, the amount of data being stored, attempts at hacking the data, etc.” (Grube: paragraph [0030]).
For claim 2, Gladwin and Grube disclose the method of claim 1, further comprising:
receiving, from the client device: second data, and a second data tag corresponding to the second underlying data of the second encrypted data; and processing the second data tag to determine whether the second underlying data is already stored as the corresponding underlying data of the any of the plurality of encrypted data, wherein the second encrypted data is not stored based on determining the second underlying data is already stored as corresponding underlying data of one of the plurality of encrypted data (Gladwin: paragraphs [0091], “The method continues at step 104 where the processing module determines whether substantially identical data is currently stored in a dispersed storage network (DSN) memory. For instance, the processing module determines whether another user device has already stored the data object (or a very similar version of the data object) in the DSN memory. Such a determination includes at least one of determining whether a data identifier associated with the data substantially matches a data identifier associated with the substantially identical data, determining whether a calculated hash of the data substantially matches a stored hash of the substantially identical data, and comparing the data to substantially identical data. The determination may be further based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, the user ID, the identity of the requesting device, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator.” paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”).
However, Gladwin does not explicitly receiving, from the client device: second encrypted data, wherein the second encrypted data is generated based on encrypting second underlying data.
Grube discloses receiving, from the client device: second encrypted data, wherein the second encrypted data is generated based on encrypting second underlying data (Grube: paragraph [0097], “[0097] In an example of a write operation, the DS processing of the DS unit receives an encoded slice to store. For example, the DS unit may receive an encoded slice from a user device for storage in the DS unit. The method begins with the step where the DS processing determines if the DS unit operating system is running. The method branches to the step where the DS processing selects one of the plurality of memory devices for storing the encoded slice when the DS processing determines that the DS unit operating system is running. The DS processing may retrieve slices of at least a portion of the operating system from one or more of the memories when the DS processing determines that the operating system is not running. The DS processing may decode the retrieved slices of the at least a portion of the operating system in preparation for execution as required.”)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to improve upon “DATA DE-DUPLICATION IN A DISPERSED STORAGE NETWORK UTILIZING DATA CHARACTERIZATION” as taught by Gladwin by implementing “METHOD AND APPARATUS FOR DISPERSED STORAGE MEMORY DEVICE UTILIZATION” as taught by Grube, because it would provide Gladwin’s method with the enhanced capability of “…supports three primary functions: distributed network data storage management, distributed data storage and retrieval, and data storage integrity verification. In accordance with these three primary functions, data can be distributedly stored in a plurality of physically different locations and subsequently retrieved in a reliable and secure manner regardless of failures of individual storage devices, failures of network equipment, the duration of storage, the amount of data being stored, attempts at hacking the data, etc.” (Grube: paragraph [0030]).
For claim 3, Gladwin and Grube disclose the method of claim 2, wherein the one of the plurality of encrypted data is different from the second encrypted data, despite the corresponding underlying data of the one of the plurality of encrypted data matching the second underlying data, based on the one of the plurality of encrypted data being generated via applying a first key and based on the second encrypted data being generated via applying a second key different from the first key (Gladwin: paragraph [0073], “The encoder 77 encodes the pre-manipulated data segment 92 using a forward error correction (FEC) encoder (and/or other type of erasure coding and/or error coding) to produce an encoded data segment 94…Note that the encoder 77 may use a different encoding algorithm for each data segment 92, the same encoding algorithm for the data segments 92 of a data object, or a combination thereof.” paragraph [0091], paragraphs [0104]-[0106], “The method continues to step 142 when the processing module determines that the data object is substantially not already stored in the DSN memory…At step 142, the processing module determines write operational parameters and saves the parameters (e.g., so that the processing module has a way to retrieve the data object). Such a determination may be based on one or more of an estimation of a number of common users that may store this same data object, a user ID, a store request, a vault lookup, a predetermination, a command, the data object name, a data size, a data type, the hash of the data object, a priority indicator, a security indicator, and a performance indicator. For example, the processing module determines the write operational parameters to include a pillar width of n=32 and a read threshold of 24 when the estimation of the number of common users that may store this same data object is 5 million. Note that there are over 10 million ways to choose 24 read pillars from the 32 pillars. The processing module saves the write operational parameters, hash of the data object, and data object name in a vault, the list of hash values of previously stored data objects, and/or in the DSN memory for reference when subsequently determining if the data object is already stored in the DSN memory”
paragraph [0114], “For example, the processing module determines the write operational parameters to include a pillar width of n=32 and a read threshold of 24 when the estimation of the number of common users that may store this same data object is 5 million. Note that there are over 10 million ways to choose 24 read pillars from the 32 pillars. Note that the processing module may determine a DS unit storage set that is the same as a previous storage set for the same data object but with different slice names. The processing module saves the write operational parameters, hash of the data object, and data object name in a vault, the list of hash values of previously stored data objects, and/or in the DSN memory for reference when subsequently determining if the data object is already stored in the DSN memory. At step 158, the processing module creates EC data slices of the data object in accordance with the write operational parameters and sends the slices to the DSN memory with a store command for storage therein”).
For claim 4, Gladwin and Grube disclose the method of claim 1, wherein the first data tag is generated based on performing a hash function upon the first underlying data (Gladwin: paragraphs [0092], “For example, the processing module determines that the data object is already stored in the DSN memory when a hash of the data object of the current storage request is the same as a hash of a previously stored data object. Note that the hash of the data object may be received from the requesting device or calculated by the processing module. In another example, the processing module determines whether the data object is stored in the DSN memory based on a comparison of a security indicator of the data object to a threshold.”
paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”).
For claim 5, Gladwin and Grube disclose the method of claim 1, further comprising: storing a plurality of data tags for the plurality of encrypted data, wherein processing the first data tag to determine whether the first underlying data is already stored as the corresponding underlying data of the any of the plurality of encrypted data is based on comparing the first data tag to the plurality of data tags (Gladwin: paragraphs [0092], “For example, the processing module determines that the data object is already stored in the DSN memory when a hash of the data object of the current storage request is the same as a hash of a previously stored data object. Note that the hash of the data object may be received from the requesting device or calculated by the processing module. In another example, the processing module determines whether the data object is stored in the DSN memory based on a comparison of a security indicator of the data object to a threshold.”
paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”).
For claim 6, Gladwin and Grube disclose the method of claim 5, wherein storing the plurality of data tags is based on storing an index structure that includes the plurality of data tags, and wherein processing the first data tag includes accessing the index structure (Gladwin: paragraphs [0104], “FIG. 9 is another flowchart illustrating another example of storing a data object in a de-duplication manner. The method begins with step 138 where a processing module (e.g., of a user device, a DS processing unit, a storage integrity processing unit, and/or a DS managing unit) receiving a store request message (e.g., from a user device). Note that the store request message may include one or more of a store request command, a user ID, a data object name, a data object, a hash of the data object, a data size, a data type, a priority indicator, a security indicator, and/or a performance indicator. At step 140, the processing module determines if a substantially identical version of the data object is already stored in the DSN memory. Such a determination may be based on one or more of comparing the data object with stored data objects, comparing the data object name with data object names of stored data objects, comparing the hash of the data object with hashes of stored data objects, the user ID, the data object name, the data size, the data type, the priority indicator, the security indicator, and the performance indicator…”
paragraphs [0140], “The method continues at step 228 where the processing module generates a key reference based on the first encryption key, which includes storage location information of the first encryption key. The generation of the key reference may be based on one or more of the first encryption key, a transformation of the first encryption key, a hash of the first encryption key, the data segment, a key table (e.g., a list of previous keys indexed by key references)…”
paragraphs [0161], “…a determination may be based on one or more of the slice key, a transformation of the slice key, a hash of the slice key, the data segment, the slice, a slice key table (e.g., a list of previous keys indexed by key references)…”).
For claim 7, Gladwin and Grube disclose the method of claim 5, further comprising: receiving a plurality of storage requests that collectively include the plurality of encrypted data and the plurality of data tags, wherein the plurality of encrypted data and the plurality of data tags are stored based on processing the plurality of storage requests (Gladwin: paragraphs [0083], “When another user device requests storage of the data object 1, the DS processing unit recognizes that it is already stored and assigns the other user device its own unique pillar combination. In the above example of over ten million unique pillar combinations, the system can accommodate over ten million user devices storing the data object 1 by storing one complete (or substantially complete) copy of the data object 1 and up to ten million unique pillar combinations such that each user device has its own unique copy of the data object 1 and its own unique retrieval sequence for subsequent private display. Alternatively, the DS processing unit 16 may assign a group of unique pillar combinations to a single user device such that if one combination does not yield a read threshold of encoded data slices due to a system error (e.g., a link is down, a site is down, a storage device failure, etc.), a different combination can be used to retrieve a read threshold of encoded data slices. While this alternative reduces the number of user devices that the system can support for de-duplication of the data object 1, it improves the reliability of data retrieval. Note that one or more methods to create and utilize unique read pillar combinations are discussed in greater detail with reference to FIGS. 7-11.”
paragraphs [0084], “In an encrypt and compress scheme, the DS processing unit 16 generates an encryption key from the data object 1 for the first storage instance of the data object. For example, the encryption key may be substantially equal to the data object 1, may be substantially equal to a representation of the data object 1 (e.g., a function has been performed on the data object 1), and/or a result of a mathematical function performed on the data object 1…”).
For claim 8, Gladwin and Grube disclose the method of claim 1, wherein storing the first encrypted data includes:
generating a set of encoded data slices based on performing a dispersed error encoding function upon the first encrypted data (Gladwin: paragraph [0094], “The method continues at step 108 where the processing module encodes at least a portion of the data using an error coding dispersal storage function in accordance with the write operational parameters to produce a set of encoded data slices. The processing module then sends the set of encoded data slices to the DSN memory for storage therein. The method continues at step 110 where the processing module generates a unique retrieval matrix for the requesting device, wherein the unique retrieval matrix identifies a sub-set of encoded data slices of the set of encoded data slices for subsequent retrieval of the at least a portion of the data. Note that the unique retrieval matrix includes at least one of a pillars list, a segmenting protocol, a pre-slice data manipulation function, a forward error correction encoding function, a slicing pillar width, a post-slice data manipulation function, a write threshold, and a read threshold. Alternatively, or in addition to, the unique retrieval matrix includes identity of one or more unique sub-sets of the encoded data slices, where a sub-set includes a number of encoded data slices that includes and between a read threshold of the error coding dispersal storage function and a pillar width of the error coding dispersal storage function”); and
storing the set of encoded data slices via a set of storage units (Gladwin: paragraph [0094], “The method continues at step 108 where the processing module encodes at least a portion of the data using an error coding dispersal storage function in accordance with the write operational parameters to produce a set of encoded data slices. The processing module then sends the set of encoded data slices to the DSN memory for storage therein.”).
For claim 9, Gladwin and Grube disclose the method of claim 1, wherein the first encrypted data is generated by the client device based on the client device encrypting the first underlying data (Grube: paragraph [0044], “The first type of user device 12 performs a similar function to store data in the DSN memory 22 with the exception that it includes the DS processing. As such, the device 12 encodes and slices the data file and/or data block it has to store.” paragraph [0097], “[0097] In an example of a write operation, the DS processing of the DS unit receives an encoded slice to store. For example, the DS unit may receive an encoded slice from a user device for storage in the DS unit. The method begins with the step where the DS processing determines if the DS unit operating system is running. The method branches to the step where the DS processing selects one of the plurality of memory devices for storing the encoded slice when the DS processing determines that the DS unit operating system is running. The DS processing may retrieve slices of at least a portion of the operating system from one or more of the memories when the DS processing determines that the operating system is not running. The DS processing may decode the retrieved slices of the at least a portion of the operating system in preparation for execution as required.”)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to improve upon “DATA DE-DUPLICATION IN A DISPERSED STORAGE NETWORK UTILIZING DATA CHARACTERIZATION” as taught by Gladwin by implementing “METHOD AND APPARATUS FOR DISPERSED STORAGE MEMORY DEVICE UTILIZATION” as taught by Grube, because it would provide Gladwin’s method with the enhanced capability of “…supports three primary functions: distributed network data storage management, distributed data storage and retrieval, and data storage integrity verification. In accordance with these three primary functions, data can be distributedly stored in a plurality of physically different locations and subsequently retrieved in a reliable and secure manner regardless of failures of individual storage devices, failures of network equipment, the duration of storage, the amount of data being stored, attempts at hacking the data, etc.” (Grube: paragraph [0030]).
For claim 10, Gladwin and Grube disclose the method of claim 1, wherein the first encrypted data is generated via applying a key to the first underlying data (Gladwin: paragraph [0039], “…the DS managing module 18 creates and stores, locally or within the DSN memory 22, user profile information. The user profile information includes one or more of authentication information, permissions, and/or the security parameters. The security parameters may include one or more of encryption/decryption scheme, one or more encryption keys, key generation scheme, and data encoding/decoding scheme”
paragraph [0084], “…In an encrypt and compress scheme, the DS processing unit 16 generates an encryption key from the data object 1 for the first storage instance of the data object.”)
For claim 13, Gladwin and Grube disclose the method of claim 1, further comprising:
receiving a first storage request from the client device indicating the first data tag, wherein the first data tag is processed in response to receiving the first storage request (Gladwin: paragraph [0091], paragraphs [0104]-[0106], “The method continues to step 142 when the processing module determines that the data object is substantially not already stored in the DSN memory…At step 142, the processing module determines write operational parameters and saves the parameters (e.g., so that the processing module has a way to retrieve the data object). Such a determination may be based on one or more of an estimation of a number of common users that may store this same data object, a user ID, a store request, a vault lookup, a predetermination, a command, the data object name, a data size, a data type, the hash of the data object, a priority indicator, a security indicator, and a performance indicator. For example, the processing module determines the write operational parameters to include a pillar width of n=32 and a read threshold of 24 when the estimation of the number of common users that may store this same data object is 5 million. Note that there are over 10 million ways to choose 24 read pillars from the 32 pillars. The processing module saves the write operational parameters, hash of the data object, and data object name in a vault, the list of hash values of previously stored data objects, and/or in the DSN memory for reference when subsequently determining if the data object is already stored in the DSN memory…” Also see Figs. 7 and 9);
in response to determining the first underlying data is not already stored as other underlying data of the any of the plurality of encrypted data, sending a first storage response to the client device indicating the first underlying data is not already stored as other underlying data of the any of the plurality of encrypted data (Gladwin: paragraph [0091], paragraphs [0104]-[0106], “The method continues to step 142 when the processing module determines that the data object is substantially not already stored in the DSN memory…At step 142, the processing module determines write operational parameters and saves the parameters (e.g., so that the processing module has a way to retrieve the data object). Such a determination may be based on one or more of an estimation of a number of common users that may store this same data object, a user ID, a store request, a vault lookup, a predetermination, a command, the data object name, a data size, a data type, the hash of the data object, a priority indicator, a security indicator, and a performance indicator. For example, the processing module determines the write operational parameters to include a pillar width of n=32 and a read threshold of 24 when the estimation of the number of common users that may store this same data object is 5 million. Note that there are over 10 million ways to choose 24 read pillars from the 32 pillars. The processing module saves the write operational parameters, hash of the data object, and data object name in a vault, the list of hash values of previously stored data objects, and/or in the DSN memory for reference when subsequently determining if the data object is already stored in the DSN memory…”
paragraphs [0108], “…At step 148, the processing module sends the read operational parameters to the user device such that the processing module of user device may retrieve slices from the DSN memory to recreate the data object. Alternatively, or in addition to, the processing module stores the read operational parameters in the DSN memory as encoded data slices” Also see Figs. 7 and 9); and
receiving a second storage request from the client device that includes the first encrypted data based on the client device processing the first storage request, wherein the first encrypted data is stored in response to receiving the second storage request (Gladwin: paragraphs [0108], “…At step 148, the processing module sends the read operational parameters to the user device such that the processing module of user device may retrieve slices from the DSN memory to recreate the data object. Alternatively, or in addition to, the processing module stores the read operational parameters in the DSN memory as encoded data slices”
paragraphs [0114], “…For example, the processing module determines the write operational parameters to include a pillar width of n=32 and a read threshold of 24 when the estimation of the number of common users that may store this same data object is 5 million. Note that there are over 10 million ways to choose 24 read pillars from the 32 pillars. Note that the processing module may determine a DS unit storage set that is the same as a previous storage set for the same data object but with different slice names. The processing module saves the write operational parameters, hash of the data object, and data object name in a vault, the list of hash values of previously stored data objects, and/or in the DSN memory for reference when subsequently determining if the data object is already stored in the DSN memory. At step 158, the processing module creates EC data slices of the data object in accordance with the write operational parameters and sends the slices to the DSN memory with a store command for storage therein…” Also see Figs. 7 and 9).
For claim 14, it is a device (a computer) claim having similar limitations as recited in claim 1. Thus, claim 14 is also rejected under the same rationale as cited in the rejection of rejected claim 1.
For claim 15, it is a device (a computer) claim having similar limitations as recited in claim 2. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of rejected claim 2.
For claim 16, it is a device (a computer) claim having similar limitations as recited in claim 4. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of rejected claim 4.
For claim 17, it is a device (a computer) claim having similar limitations as recited in claim 5. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of rejected claim 5.
For claim 18, it is a device (a computer) claim having similar limitations as recited in claim 8. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of rejected claim 8.
For claim 19, it is a device (a computer) claim having similar limitations as recited in claim 9. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of rejected claim 9.
For claim 20, it is a system claim having similar limitations as recited in claim 1. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of rejected claim 1.
Allowable Subject Matter
Claims 11-12 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YU ZHAO whose telephone number is (571)270-3427. The examiner can normally be reached Monday-Friday 9AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sherief Badawi can be reached at (571) 272-9782. 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.
/YU ZHAO/Primary Examiner, Art Unit 2169
Prosecution Insights