DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114 was filed in this application after a decision by the Patent Trial and Appeal Board, but before the filing of a Notice of Appeal to the Court of Appeals for the Federal Circuit or the commencement of a civil action. Since this application is eligible for continued examination under 37 CFR 1.114 and the fee set forth in 37 CFR 1.17(e) has been timely paid, the appeal has been withdrawn pursuant to 37 CFR 1.114 and prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant’s submission filed on July 28, 2026 has been entered.
Response to Amendment
Applicant’s arguments, filed July 28, 2026 have been entered. Claims 1, 7, 8, and 14 have been amended, and claims 1-18 are currently pending.
Response to Arguments
Applicant’s arguments, see Remarks pp. 8-14, filed July 28, 2026, with respect to the rejections of claims 1-18 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Matsushige (WO 2010/073291 A1, hereinafter “Matsushige”).
Claim Rejections - 35 USC § 112
Claims 1-18 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 claims 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 “determining, by the storage network processing module, whether a timestamp associated with a contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold” (emphasis added), however Applicant’s Specification [0058] recites “For example, the processing module determines that the comparison is favorable when a difference between the timestamp associated with the signature contribution request and a timestamp associated with a previous signature contribution request is greater than a time threshold of the timing template” (emphasis added). The written description does not support that the contribution request falls within the time threshold, as recited in claim 1.
Independent claim 8 recites “determining, by the storage network processing module, whether a timestamp associated with a contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold” (emphasis added), however Applicant’s Specification [0058] recites “For example, the processing module determines that the comparison is favorable when a difference between the timestamp associated with the signature contribution request and a timestamp associated with a previous signature contribution request is greater than a time threshold of the timing template” (emphasis added). The written description does not support that the contribution request falls within the time threshold, as recited in claim 8.
Independent claim 14 recites “determining, by the storage unit, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold” (emphasis added), however Applicant’s Specification [0058] recites “For example, the processing module determines that the comparison is favorable when a difference between the timestamp associated with the signature contribution request and a timestamp associated with a previous signature contribution request is greater than a time threshold of the timing template” (emphasis added). The written description does not support that the contribution request fall within the time threshold, as recited in claim 14.
Claims 2-7 depend from claim 1 and are rejected accordingly. Claims 9-13 depend from claim 8 and are rejected accordingly. Claims 15-18 depend from claim 14 and are rejected accordingly.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, 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 negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claims 1, 2, 4, 6, 8, 9 and 12 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Grube et al. (Pub. No. US 2011/0265143 A1, hereinafter “Grube”) in view of Matsushige in view of Syrgabekov et al. (Pub. No. US 2013/0073901 A1, hereinafter “Syrgabekov”).
Regarding claim 1, Grube teaches:
receiving, by a storage network processing module, a contribution request for an encoded data slice of a set of encoded data slices, wherein data is dispersed error encoded in accordance with dispersed error encoding parameters to produce a set of encoded data slices (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. contribution request). Such a store data object message may include one or more of data, a user ID, a request, a data ID, a data object hash, a vault ID, and a performance indicator. At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091-0092]. A vault identifier identifies a vault, which is a virtual memory space that maps to a set of DS storage units [0072] (see Applicant’s Specification, where a contribution request may include one or more of a share set ID, a storage node group ID, the message to sign, and at least one parameter of the sharing function parameters).)
generating, by the storage network processing module, parity data for the encoded data slice (Grube – at step 108, the processing module determines integrity information (i.e. parity data) for the plurality of sets of slice names. Such a determination may be in accordance with one or more integrity methods. The individual integrity information may be generated by performing one or more of a hash function and a parity check on a slice name [0093].)
sending, by the storage network processing module, the encoded data slice to a first storage unit of a set of storage units (Grube – at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information to a DSN memory for storage therein [0099].)
and sending, by the storage network processing module, the parity data for the encoded data slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube does not appear to teach:
determining, by the storage network processing module, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold,
to a second storage unit of the set of storage units
However, Matsushige teaches:
determining, by the storage network processing module, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold, (Matsushige – the storage apparatus of the present invention performs generation of the second error detecting code and comparison between the first error detecting code and the second error detecting code only when the response time required for write processing exceeds the threshold value. Accordingly, as long as the response time required for write processing does not exceed the threshold value, overhead for write processing is little affected by processing for verifying write data. Moreover, when the response time required for write processing (i.e. contribution request) exceeds the threshold value, generation of the second error detecting code and comparison between the first error detecting code and the second error detecting code are performed so that reliability of data writing can be improved [0008-0009].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube and Matsushige before them, to modify the system of Grube with the teachings of Matsushige, as indicated above. One would have been motivated to make such a modification to provide a storage apparatus capable of improving reliability of data in a storage apparatus without increasing overhead (Matsushige [0006]).
Grube modified by Matsushige does not appear to teach:
to a second storage unit of the set of storage units
However, Syrgabekov teaches:
to a second storage unit of the set of storage units (Syrgabekov – data may be divided into subsets of data or data elements. Parity data may be generated from the subsets of data in such a way that if one or more of the data subsets is destroyed or lost then any missing subset may be recreated from the remaining subsets and parity data. Once the parity data has been calculated all of the data subsets and parity data may be stored in separate or remote file locations [0114]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036]. Preferably, the separate storage locations are accessible over a network. This network may be the Internet, for example (i.e. geographically different locations) [0042]. The data may be stored on may be different types of storage medium such as hard disks, FLASH RAM, web servers, FTP servers and network file servers or a mixture of these [0175].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Regarding claim 2, Grube teaches:
receiving, by a storage network processing module, a write update request for the encoded data slice (Grube – Fig. 12A represents the computing system where the DS processing unit 188 sends slices for storage to DS units 1-4 of DS unit storage set 190. Note that DS unit 5 is not part of the DS unit storage set 190 [0125]. Fig. 12B represents the computing system where DS processing unit 194 considers a participation solicitation message 192 (i.e. write update request) from DS unit 5. The DS processing unit determines whether to utilize the DS unit based on one or more of several factors, including the information in the solicitation message. For example, the DS processing unit may determine to utilize DS unit 5 to replace DS unit 1 [0126].)
updating, by the storage network processing module, the encoded data slice to produce an updated encoded data slice (Grube – the DS processing unit sends a participation solicitation response to DS unit 5, wherein the response includes an assignment to DS unit storage set to store pillar slices when the DS processing unit determines to utilize DS unit 5 in favor of DS unit 1. Next, the DS processing unit facilitates moving pillar 1 slices from DS unit 1 over to DS unit 5. The DS processing unit updates a virtual dispersed storage network (DSN) address to physical location table to indicate that the pillar 1 slices are now stored at DS unit 5 [0127].)
generating, by the storage network processing module, parity data for the updated encoded data slice (Grube - at step 108, the processing module determines integrity information (i.e. parity data) for the plurality of sets of slice names. Such a determination may be in accordance with one or more integrity methods. The individual integrity information may be generated by performing one or more of a hash function and a parity check on a slice name [0093]. At step 114, the processing module sends the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099]. Examiner interprets that parity data is generated for the new slice when slices are moved from one unit to another as in step 114.)
and sending, by the storage network processing module, the parity data for the updated encoded data slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube modified by Matsushige does not appear to teach:
to a third storage unit of a set of storage units
However, Syrgabekov teaches:
to a third storage unit of a set of storage units (Syrgabekov – in Fig. 1, step 50, the two data subsets A and B and parity set P may be stored in memory or a hard drive, for instance. The method 10 may loop at this point. It is determined whether or not there are any further storage locations available or required (i.e. further storage units) at step 60. If there are then the method loops back to step 30 where any or each of the data subsets A, B and/or parity data P are further split into new subsets and a further parity data set. The loop continues each data subset and parity data being divided and generated until there are no further storage locations available or preset and the method stops at step 70 [0119]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Regarding claim 4, Grube teaches:
receiving, by the storage network processing module, a write request for another encoded data slice of the set of encoded data slices (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
generating, by the storage network processing module, parity data for the another encoded data slice (Grube – at step 108, the processing module determines integrity information (i.e. parity data) for the plurality of sets of slice names. Such a determination may be in accordance with one or more integrity methods. The individual integrity information may be generated by performing one or more of a hash function and a parity check on a slice name [0093].)
transmitting, by the storage network processing module, the another encoded data slice to a third storage unit of the set of storage units (Grube – at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information to a DSN memory for storage therein [0099].)
and transmitting, by the storage network processing module, the parity data for the another encoded data slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube modified by Matsushige does not appear to teach:
to a fourth storage unit of the set of storage units
However, Syrgabekov teaches:
to a fourth storage unit of the set of storage units (Syrgabekov – in Fig. 1, step 50, the two data subsets A and B and parity set P may be stored in memory or a hard drive, for instance. The method 10 may loop at this point. It is determined whether or not there are any further storage locations available or required (i.e. further storage units) at step 60. If there are then the method loops back to step 30 where any or each of the data subsets A, B and/or parity data P are further split into new subsets and a further parity data set. The loop continues each data subset and parity data being divided and generated until there are no further storage locations available or preset and the method stops at step 70 [0119]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Regarding claim 6, Grube teaches:
wherein data is segmented into a plurality of data segments before the data is dispersed error encoded, wherein each data segment of the plurality of data segments is dispersed error encoded in accordance with dispersed error encoding parameters to produce a set of encoded data slices (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091]. The access module receives the data object and creates a series of data segments in accordance with a data storage protocol [0074].)
Regarding claim 8, Grube teaches:
receiving, by a storage network processing module, a write contribution request for an encoded data slice of a set of encoded data slices, wherein data is encoded in accordance with a dispersed storage error coding function to produce a set of encoded data slices (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
generating, by the storage network processing module, a parity slice for each encoded data slice of the set of encoded data slices to produce a plurality of parity slices (Grube – at step 108, the processing module determines integrity information (i.e. parity slice) for the plurality of sets of slice names. Such a determination may be in accordance with one or more integrity methods. The individual integrity information may be generated by performing one or more of a hash function and a parity check on a slice name [0093].)
transmitting, by the storage network processing module, a write threshold number of encoded data slices of the set of encoded data slices to a first set of storage units (Grube - at step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded) including one or more of a pillar width and a write threshold [0091]. At step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information to a DSN memory for storage therein [0099].)
and transmitting, by the storage network processing module, the plurality of parity slices (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube does not appear to teach:
determining, by the storage network processing module, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold,
to a second set of storage units
However, Matsushige teaches:
determining, by the storage network processing module, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold, (Matsushige – the storage apparatus of the present invention performs generation of the second error detecting code and comparison between the first error detecting code and the second error detecting code only when the response time required for write processing exceeds the threshold value. Accordingly, as long as the response time required for write processing does not exceed the threshold value, overhead for write processing is little affected by processing for verifying write data. Moreover, when the response time required for write processing (i.e. contribution request) exceeds the threshold value, generation of the second error detecting code and comparison between the first error detecting code and the second error detecting code are performed so that reliability of data writing can be improved [0008-0009].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Matsushige, as indicated above. One would have been motivated to make such a modification to provide a storage apparatus capable of improving reliability of data in a storage apparatus without increasing overhead (Matsushige [0006]).
Grube modified by Matsushige does not appear to teach:
to a second storage unit of the set of storage units
However, Syrgabekov teaches:
to a second set of storage units (Syrgabekov – data may be divided into subsets of data or data elements. Parity data may be generated from the subsets of data in such a way that if one or more of the data subsets is destroyed or lost then any missing subset may be recreated from the remaining subsets and parity data. Once the parity data has been calculated all of the data subsets and parity data may be stored in separate or remote file locations [0114]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036]. Preferably, the separate storage locations are accessible over a network. This network may be the Internet, for example (i.e. geographically different locations) [0042]. The data may be stored on may be different types of storage medium such as hard disks, FLASH RAM, web servers, FTP servers and network file servers or a mixture of these [0175].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Regarding claim 9, Grube teaches:
receiving, by the storage network processing module, a write update request for an encoded data slice of the set of encoded data slices (Grube – Fig. 12A represents the computing system where the DS processing unit 188 sends slices for storage to DS units 1-4 of DS unit storage set 190. Note that DS unit 5 is not part of the DS unit storage set 190 [0125]. Fig. 12B represents the computing system where DS processing unit 194 considers a participation solicitation message 192 (i.e. write update request) from DS unit 5. The DS processing unit determines whether to utilize the DS unit based on one or more of several factors, including the information in the solicitation message. For example, the DS processing unit may determine to utilize DS unit 5 to replace DS unit 1 [0126].)
updating, by the storage network processing module, the encoded data slice to produce an updated encoded data slice (Grube – the DS processing unit sends a participation solicitation response to DS unit 5, wherein the response includes an assignment to DS unit storage set to store pillar slices when the DS processing unit determines to utilize DS unit 5 in favor of DS unit 1. Next, the DS processing unit facilitates moving pillar 1 slices from DS unit 1 over to DS unit 5. The DS processing unit updates a virtual dispersed storage network (DSN) address to physical location table to indicate that the pillar 1 slices are now stored at DS unit 5 [0127].)
generating, by the storage network processing module, an parity slice for the updated encoded data slice (Grube - at step 108, the processing module determines integrity information (i.e. parity data) for the plurality of sets of slice names. Such a determination may be in accordance with one or more integrity methods. The individual integrity information may be generated by performing one or more of a hash function and a parity check on a slice name [0093]. At step 114, the processing module sends the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099]. Examiner interprets that parity data is generated for the new slice when slices are moved from one unit to another as in step 114.)
and sending, by the storage network processing module, the parity slice for the updated encoded data slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube modified by Matsushige does not appear to teach:
to a third set of storage units
However, Syrgabekov teaches:
to a third set of storage units (Syrgabekov – in Fig. 1, step 50, the two data subsets A and B and parity set P may be stored in memory or a hard drive, for instance. The method 10 may loop at this point. It is determined whether or not there are any further storage locations available or required (i.e. further storage units) at step 60. If there are then the method loops back to step 30 where any or each of the data subsets A, B and/or parity data P are further split into new subsets and a further parity data set. The loop continues each data subset and parity data being divided and generated until there are no further storage locations available or preset and the method stops at step 70 [0119]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Regarding claim 12, Grube teaches:
wherein data is segmented into a plurality of data segments before the data is dispersed error encoded, wherein each data segment of the plurality of data segments is dispersed error encoded in accordance with dispersed error encoding parameters to produce a set of encoded data slices (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091]. The access module receives the data object and creates a series of data segments in accordance with a data storage protocol [0074].)
Claims 3, 5, 7, 10, 11, 13, 14-18 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Grube in view of Matsushige in view of Syrgabekov further in view of Forhan et al. (Pub. No. US 2006/0123269 A1, hereinafter “Forhan”).
Regarding claim 3, Grube teaches:
receiving, by a storage network processing module, a write update request for the encoded data slice (Grube – Fig. 12A represents the computing system where the DS processing unit 188 sends slices for storage to DS units 1-4 of DS unit storage set 190. Note that DS unit 5 is not part of the DS unit storage set 190 [0125]. Fig. 12B represents the computing system where DS processing unit 194 considers a participation solicitation message 192 (i.e. write update request) from DS unit 5. The DS processing unit determines whether to utilize the DS unit based on one or more of several factors, including the information in the solicitation message. For example, the DS processing unit may determine to utilize DS unit 5 to replace DS unit 1 [0126].)
updating, by the storage network processing module, the encoded data slice to produce an updated encoded data slice (Grube – the DS processing unit sends a participation solicitation response to DS unit 5, wherein the response includes an assignment to DS unit storage set to store pillar slices when the DS processing unit determines to utilize DS unit 5 in favor of DS unit 1. Next, the DS processing unit facilitates moving pillar 1 slices from DS unit 1 over to DS unit 5. The DS processing unit updates a virtual dispersed storage network (DSN) address to physical location table to indicate that the pillar 1 slices are now stored at DS unit 5 [0127].)
generating, by the storage network processing module, [delta] parity data for the updated encoded data slice (Grube – the DS processing unit sends a participation solicitation response to DS unit 5, wherein the response includes an assignment to DS unit storage set to store pillar slices when the DS processing unit determines to utilize DS unit 5 in favor of DS unit 1. Next, the DS processing unit facilitates moving pillar 1 slices from DS unit 1 over to DS unit 5. The DS processing unit updates a virtual dispersed storage network (DSN) address to physical location table to indicate that the pillar 1 slices are now stored at DS unit 5 [0127].)
and sending, by the storage network processing module, the parity data for the updated encoded data slice to a third storage unit of a set of storage units (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube modified by Matsushige does not appear to teach:
delta parity data
to a third storage unit of a set of storage units
However, Syrgabekov teaches:
to a third storage unit of a set of storage units (Syrgabekov – in Fig. 1, step 50, the two data subsets A and B and parity set P may be stored in memory or a hard drive, for instance. The method 10 may loop at this point. It is determined whether or not there are any further storage locations available or required (i.e. further storage units) at step 60. If there are then the method loops back to step 30 where any or each of the data subsets A, B and/or parity data P are further split into new subsets and a further parity data set. The loop continues each data subset and parity data being divided and generated until there are no further storage locations available or preset and the method stops at step 70 [0119]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Grube modified by Matsushige and Syrgabekov does not appear to teach:
delta parity data
However, Forhan teaches:
delta parity data (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, Syrgabekov, and Forhan before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 5, Grube teaches:
encoded data slice (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
Grube modified by Matsushige and Syrgabekov does not appear to teach:
updating, by the storage network processing module, parity information of an [encoded] data slice of at least one other [encoded data] slice of the set of [encoded] data slices, wherein the updating is based on a corresponding one parity data to produce an [encoded] data slice that includes updated parity data
However, Forhan teaches:
updating, by the storage network processing module, parity information of an [encoded] data slice of at least one other [encoded data] slice of the set of [encoded] data slices, wherein the updating is based on a corresponding one parity data to produce an [encoded] data slice that includes updated parity data (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity (i.e. updated parity data) back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, Syrgabekov, and Forhan before them, to modify the system of Grube and Matsushige, Syrgabekov, and Forhan with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 7, Grube teaches:
encoded data slice (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
and sending, by the storage network processing module, the updated parity data (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube modified by Matsushige does not appear to teach:
receiving, by a storage network processing module, delta parity data for the [encoded] data slice; retrieving, by the storage network processing module, the parity data for the [encoded] data slice; generating, by the storage network processing module, based on the delta parity data and the parity data, updated parity data for the [encoded] data slice
to a third storage unit of a set of storage units
However, Syrgabekov teaches:
to a third storage unit of a set of storage units (Syrgabekov – in Fig. 1, step 50, the two data subsets A and B and parity set P may be stored in memory or a hard drive, for instance. The method 10 may loop at this point. It is determined whether or not there are any further storage locations available or required (i.e. further storage units) at step 60. If there are then the method loops back to step 30 where any or each of the data subsets A, B and/or parity data P are further split into new subsets and a further parity data set. The loop continues each data subset and parity data being divided and generated until there are no further storage locations available or preset and the method stops at step 70 [0119]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Grube modified by Matsushige and Syrgabekov does not appear to teach:
receiving, by a storage network processing module, delta parity data for the [encoded] data slice; retrieving, by the storage network processing module, the parity data for the [encoded] data slice; generating, by the storage network processing module, based on the delta parity data and the parity data, updated parity data for the [encoded] data slice
However, Forhan teaches:
receiving, by a storage network processing module, delta parity data for the [encoded] data slice; retrieving, by the storage network processing module, the parity data for the [encoded] data slice; generating, by the storage network processing module, based on the delta parity data and the parity data, updated parity data for the [encoded] data slice (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, Syrgabekov, and Forhan before them, to modify the system of Grube and Matsushige, Syrgabekov, and Forhan with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 10, Grube teaches:
receiving, by the storage network processing module, a write update request for an encoded data slice of the set of encoded data slices (Grube – Fig. 12A represents the computing system where the DS processing unit 188 sends slices for storage to DS units 1-4 of DS unit storage set 190. Note that DS unit 5 is not part of the DS unit storage set 190 [0125]. Fig. 12B represents the computing system where DS processing unit 194 considers a participation solicitation message 192 (i.e. write update request) from DS unit 5. The DS processing unit determines whether to utilize the DS unit based on one or more of several factors, including the information in the solicitation message. For example, the DS processing unit may determine to utilize DS unit 5 to replace DS unit 1 [0126].)
updating, by the storage network processing module, the encoded data slice to produce an updated encoded data slice (Grube – the DS processing unit sends a participation solicitation response to DS unit 5, wherein the response includes an assignment to DS unit storage set to store pillar slices when the DS processing unit determines to utilize DS unit 5 in favor of DS unit 1. Next, the DS processing unit facilitates moving pillar 1 slices from DS unit 1 over to DS unit 5. The DS processing unit updates a virtual dispersed storage network (DSN) address to physical location table to indicate that the pillar 1 slices are now stored at DS unit 5 [0127].)
generating, by the storage network processing module, a [delta] parity slice for the updated encoded data slice (Grube – the DS processing unit sends a participation solicitation response to DS unit 5, wherein the response includes an assignment to DS unit storage set to store pillar slices when the DS processing unit determines to utilize DS unit 5 in favor of DS unit 1. Next, the DS processing unit facilitates moving pillar 1 slices from DS unit 1 over to DS unit 5. The DS processing unit updates a virtual dispersed storage network (DSN) address to physical location table to indicate that the pillar 1 slices are now stored at DS unit 5 [0127].)
and sending, by the storage network processing module, the delta parity slice for the updated encoded data slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube modified by Matsushige does not appear to teach:
delta parity slice
to a third set of storage units
However, Syrgabekov teaches:
to a third set of storage units (Syrgabekov – in Fig. 1, step 50, the two data subsets A and B and parity set P may be stored in memory or a hard drive, for instance. The method 10 may loop at this point. It is determined whether or not there are any further storage locations available or required (i.e. further storage units) at step 60. If there are then the method loops back to step 30 where any or each of the data subsets A, B and/or parity data P are further split into new subsets and a further parity data set. The loop continues each data subset and parity data being divided and generated until there are no further storage locations available or preset and the method stops at step 70 [0119]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Grube modified by Matsushige and Syrgabekov does not appear to teach:
delta parity slice
However, Forhan teaches:
delta parity slice (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, Syrgabekov, and Forhan before them, to modify the system of Grube, Matsushige, and Syrgabekov with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 11, Grube teaches:
encoded data slice (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
Grube modified by Matsushige and Syrgabekov does not appear to teach:
updating, by the storage network processing module, a parity slice of an associated [encoded] data slice of at least one other [encoded] data slice of the set of [encoded] data slices, wherein the updating is based on a corresponding one parity slice to produce an [encoded] data slice that includes updated parity data
However, Forhan teaches:
updating, by the storage network processing module, a parity slice of an associated [encoded] data slice of at least one other [encoded] data slice of the set of [encoded] data slices, wherein the updating is based on a corresponding one parity slice to produce an [encoded] data slice that includes updated parity data (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity (i.e. updated parity data) back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, Syrgabekov, and Forhan before them, to modify the system of Grube, Matsushige, and Syrgabekov with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 13, Grube teaches:
encoded data slices (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
and sending, by the storage network processing module, the updated parity slice for the updated encoded data slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube modified by Matsushige does not appear to teach:
receiving, by a storage network processing module, delta parity data for an encoded data slice of the set of encoded data slices; retrieving, by the storage network processing module, the parity slice associated with the encoded data slice; generating, by the storage network processing module, based on the delta parity data and the parity slice, an updated parity slice for the encoded data slice
to a third set of storage units
However, Syrgabekov teaches:
to a third set of storage units (Syrgabekov – in Fig. 1, step 50, the two data subsets A and B and parity set P may be stored in memory or a hard drive, for instance. The method 10 may loop at this point. It is determined whether or not there are any further storage locations available or required (i.e. further storage units) at step 60. If there are then the method loops back to step 30 where any or each of the data subsets A, B and/or parity data P are further split into new subsets and a further parity data set. The loop continues each data subset and parity data being divided and generated until there are no further storage locations available or preset and the method stops at step 70 [0119]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, and Syrgabekov before them, to modify the system of Grube, Matsushige, and Syrgabekov with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Grube modified by Syrgabekov does not appear to teach:
receiving, by a storage network processing module, delta parity data for an encoded data slice of the set of encoded data slices; retrieving, by the storage network processing module, the parity slice associated with the encoded data slice; generating, by the storage network processing module, based on the delta parity data and the parity slice, an updated parity slice for the encoded data slice
However, Forhan teaches:
receiving, by a storage network processing module, delta parity data for an encoded data slice of the set of encoded data slices; retrieving, by the storage network processing module, the parity slice associated with the encoded data slice; generating, by the storage network processing module, based on the delta parity data and the parity slice, an updated parity slice for the encoded data slice (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Matsushige, Syrgabekov, and Forhan before them, to modify the system of Grube and Matsushige, and Syrgabekov with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 14, Grube teaches:
receiving, by a storage unit of a storage network, a contribution request for a parity slice of a plurality of parity slices, wherein data is encoded in accordance with a dispersed storage error coding function to produce a set of encoded data slices, wherein a plurality of parity slices are generated from the set of encoded data slices and wherein the parity slice is stored in the storage unit (Grube – at step 108, the processing module determines integrity information (i.e. parity data) for the plurality of sets of slice names. Such a determination may be in accordance with one or more integrity methods. The individual integrity information may be generated by performing one or more of a hash function and a parity check on a slice name [0093]. At step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
storing, by the storage unit, the parity slice in a memory unit associated with the storage unit, (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
encoded data slice (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
Grube does not appear to teach:
wherein the memory unit is geographically separated from the storage unit
determining, by the storage unit, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold,
receiving, by the storage unit, an updated parity slice for the [encoded] data parity slice
and facilitating, by the storage unit, replacing the parity slice in the memory unit with the updated encoded data parity slice
However, Syrgabekov teaches:
wherein the memory unit is geographically separated from the storage unit (Syrgabekov – data may be divided into subsets of data or data elements. Parity data may be generated from the subsets of data in such a way that if one or more of the data subsets is destroyed or lost then any missing subset may be recreated from the remaining subsets and parity data. Once the parity data has been calculated all of the data subsets and parity data may be stored in separate or remote file locations [0114]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036]. Preferably, the separate storage locations are accessible over a network. This network may be the Internet, for example (i.e. geographically different locations) [0042]. The data may be stored on may be different types of storage medium such as hard disks, FLASH RAM, web servers, FTP servers and network file servers or a mixture of these [0175].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube and Syrgabekov before them, to modify the system of Grube with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Grube modified by Syrgabekov does not appear to teach:
determining, by the storage unit, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold,
receiving, by the storage unit, an updated parity slice for the [encoded] data parity slice
and facilitating, by the storage unit, replacing the parity slice in the memory unit with the updated encoded data parity slice
However, Matsushige teaches:
determining, by the storage unit, whether a timestamp associated with the contribution request falls within a time threshold; in response to a determination that the contribution request falls within the time threshold, (Matsushige – the storage apparatus of the present invention performs generation of the second error detecting code and comparison between the first error detecting code and the second error detecting code only when the response time required for write processing exceeds the threshold value. Accordingly, as long as the response time required for write processing does not exceed the threshold value, overhead for write processing is little affected by processing for verifying write data. Moreover, when the response time required for write processing (i.e. contribution request) exceeds the threshold value, generation of the second error detecting code and comparison between the first error detecting code and the second error detecting code are performed so that reliability of data writing can be improved [0008-0009].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Syrgabekov, and Matsushige before them, to modify the system of Grube and Syrgabekov with the teachings of Matsushige, as indicated above. One would have been motivated to make such a modification to provide a storage apparatus capable of improving reliability of data in a storage apparatus without increasing overhead (Matsushige [0006]).
Grube modified by Syrgabekov and Matsushige does not appear to teach:
receiving, by the storage unit, an updated parity slice for the [encoded] data parity slice
and facilitating, by the storage unit, replacing the parity slice in the memory unit with the updated encoded data parity slice
However, Forhan teaches:
receiving, by the storage unit, an updated parity slice for the [encoded] data parity slice (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity (i.e. updated parity data) back onto the same two drives (i.e. replacing), which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
and facilitating, by the storage unit, replacing the parity slice in the memory unit with the updated encoded data parity slice (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity (i.e. updated parity data) back onto the same two drives (i.e. replacing), which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Syrgabekov, Matsushige, and Forhan before them, to modify the system of Grube, Syrgabekov, and Matsushige with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 15, Grube teaches:
encoded data slice (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091].)
and storing, by the storage unit, the parity slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube does not appear to teach:
receiving, by the storage unit, delta parity data for the parity slice; retrieving, by the storage unit, the parity slice; generating, by the storage unit, based on the delta parity data and the parity slice, an updated parity slice for the [encoded] data slice
in another memory unit associated with the storage unit
However, Syrgabekov teaches:
in another memory unit associated with the storage unit (Syrgabekov – data may be divided into subsets of data or data elements. Parity data may be generated from the subsets of data in such a way that if one or more of the data subsets is destroyed or lost then any missing subset may be recreated from the remaining subsets and parity data. Once the parity data has been calculated all of the data subsets and parity data may be stored in separate or remote file locations [0114]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036]. Preferably, the separate storage locations are accessible over a network. This network may be the Internet, for example (i.e. geographically different locations) [0042]. The data may be stored on may be different types of storage medium such as hard disks, FLASH RAM, web servers, FTP servers and network file servers or a mixture of these [0175].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Syrgabekov, Matsushige, and Forhan before them, to modify the system of Grube, Syrgabekov, Matsushige, and Forhan with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Grube modified by Syrgabekov and Matsushige does not appear to teach:
receiving, by the storage unit, delta parity data for the parity slice; retrieving, by the storage unit, the parity slice; generating, by the storage unit, based on the delta parity data and the parity slice, an updated parity slice for the [encoded] data slice
However, Forhan teaches:
receiving, by the storage unit, delta parity data for the parity slice; retrieving, by the storage unit, the parity slice; generating, by the storage unit, based on the delta parity data and the parity slice, an updated parity slice for the [encoded] data slice (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Syrgabekov, Matsushige, and Forhan before them, to modify the system of Grube, Syrgabekov, and Matsushige with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 16, Grube teaches:
receiving, by the storage unit, a write update request for an encoded data slice associated with the parity slice (Grube – Fig. 12A represents the computing system where the DS processing unit 188 sends slices for storage to DS units 1-4 of DS unit storage set 190. Note that DS unit 5 is not part of the DS unit storage set 190 [0125]. Fig. 12B represents the computing system where DS processing unit 194 considers a participation solicitation message 192 (i.e. write update request) from DS unit 5. The DS processing unit determines whether to utilize the DS unit based on one or more of several factors, including the information in the solicitation message. For example, the DS processing unit may determine to utilize DS unit 5 to replace DS unit 1 [0126].)
generating, by the storage unit, an updated parity slice for the updated encoded data slice (Grube - at step 108, the processing module determines integrity information (i.e. parity data) for the plurality of sets of slice names. Such a determination may be in accordance with one or more integrity methods. The individual integrity information may be generated by performing one or more of a hash function and a parity check on a slice name [0093]. At step 114, the processing module sends the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099]. Examiner interprets that parity data is generated for the new slice when slices are moved from one unit to another as in step 114.)
and storing, by the storage unit, the updated parity slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube does not appear to teach:
in another memory unit associated with the storage unit
However, Syrgabekov teaches:
in another memory unit associated with the storage unit (Syrgabekov – data may be divided into subsets of data or data elements. Parity data may be generated from the subsets of data in such a way that if one or more of the data subsets is destroyed or lost then any missing subset may be recreated from the remaining subsets and parity data. Once the parity data has been calculated all of the data subsets and parity data may be stored in separate or remote file locations [0114]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036]. Preferably, the separate storage locations are accessible over a network. This network may be the Internet, for example (i.e. geographically different locations) [0042]. The data may be stored on may be different types of storage medium such as hard disks, FLASH RAM, web servers, FTP servers and network file servers or a mixture of these [0175].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Syrgabekov, Matsushige, and Forhan before them, to modify the system of Grube, Syrgabekov, Matsushige, and Forhan with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Regarding claim 17, Grube teaches:
and storing, by the storage unit, the updated parity slice (Grube - at step 114, the processing module send the plurality of sets of encoded data slices, the plurality of sets of slice names, and the integrity information (i.e. parity data) to a DSN memory for storage therein [0099].)
Grube does not appear to teach:
receiving, by the storage unit, delta parity data for the parity slice; retrieving the parity slice; generating, by the storage unit, based on the delta parity data and the parity slice, an updated parity slice
in another memory unit associated with the storage unit
However, Syrgabekov teaches:
in another memory unit associated with the storage unit (Syrgabekov – data may be divided into subsets of data or data elements. Parity data may be generated from the subsets of data in such a way that if one or more of the data subsets is destroyed or lost then any missing subset may be recreated from the remaining subsets and parity data. Once the parity data has been calculated all of the data subsets and parity data may be stored in separate or remote file locations [0114]. Preferably, each of the storage locations are separate physical devices [0034]. The separate storage locations may be selected from the group consisted of hard disk drive, optical disk, FLASH RAM, web server, FTP server and network file server [0036]. Preferably, the separate storage locations are accessible over a network. This network may be the Internet, for example (i.e. geographically different locations) [0042]. The data may be stored on may be different types of storage medium such as hard disks, FLASH RAM, web servers, FTP servers and network file servers or a mixture of these [0175].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Syrgabekov, Matsushige, and Forhan before them, to modify the system of Grube, Syrgabekov, Matsushige, and Forhan with the teachings of Syrgabekov, as indicated above. One would have been motivated to make such a modification to overcome problems such as data corruption (Syrgabekov - [Col. 2 lines 4-25]).
Grube modified by Syrgabekov and Matsushige does not appear to teach:
receiving, by the storage unit, delta parity data for the parity slice; retrieving the parity slice; generating, by the storage unit, based on the delta parity data and the parity slice, an updated parity slice
However, Forhan teaches:
receiving, by the storage unit, delta parity data for the parity slice; retrieving the parity slice; generating, by the storage unit, based on the delta parity data and the parity slice, an updated parity slice (Forhan – one aspect of RAID-4 and higher is that, once parity data for a parity stripe is initially generated, later writes performed on the array typically require the parity to be updated by combining new data with old data and existing parity data to produce the new parity data. In RAID-4 and RAID-5 implementations, these update operations, often referred to as delta updates, require each RAID write to include a read from two drive (old data, old parity), the calculation of the difference between the new and old data, the application of that difference to the old parity to obtain the new parity, and the writing of the new data and parity back onto the same two drives, which typically requires four I/O operations to be performed. In RAID-6 implementations, a delta update typically takes six I/O operations, give the need to update two parity drives [0011].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Grube, Syrgabekov, Matsushige, and Forhan before them, to modify the system of Grube, Syrgabekov, and Matsushige with the teachings of Forhan, as indicated above. One would have been motivated to make such a modification to keep parity information up to date with later writes (Forhan - [0011]).
Regarding claim 18, Grube teaches:
wherein data is segmented into a plurality of data segments before the data is dispersed error encoded, wherein each data segment of the plurality of data segments is dispersed error encoded in accordance with dispersed error encoding parameters to produce a set of encoded data slices (Grube – the method begins at step 102 where a processing module receives a store data object message (i.e. write request). At step 104 the processing module determines dispersed storage error coding parameters (i.e. dispersed error encoded). At step 106, the processing module dispersed storage error encodes data to produce a plurality of sets of encoded data slices in accordance with the dispersed storage error coding parameters [0091]. The access module receives the data object and creates a series of data segments in accordance with a data storage protocol [0074].)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANJIT P DORAISWAMY whose telephone number is (571)270-5759. The examiner can normally be reached Monday-Friday 9:00 AM - 5:00 PM.
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, Sanjiv Shah can be reached at (571) 272-4098. 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.
/RANJIT P DORAISWAMY/Examiner, Art Unit 2166
/SANJIV SHAH/Supervisory Patent Examiner, Art Unit 2166
Prosecution Insights