DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for examination.
The claims and only the claims form the metes and bounds of the invention. “Office personnel are to give claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in the specification but not recited in the claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969)” (MPEP p 2100-8, c 2, I 45-48; p 2100-9, c 1, l 1-4). The Examiner has full latitude to interpret each claim in the broadest reasonable sense. The Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning.
Response to Arguments
Applicant’s remarks/amendment was filed on 06 November 2025.
Applicant’s arguments have been considered but they are not persuasive. However, the Examiner welcomes any suggestion(s) Applicants may have on moving prosecution forward. The Examiner’s contact information is in the Conclusion of this office action.
Applicant argues:
With respect to the newly-added "employ" features, the undersigned has attempted to
clarify that the "zoned checksum scheme" is employed for a set of one or more storage devices used by the virtual storage system. The undersigned notes "zoned checksum scheme" is a defined term in the context of the above-captioned patent application that refers to "a checksum scheme in which checksums for a group of data blocks are stored within a designated data block (which may be referred to as a "checksum block") of the group of data blocks." See Specification at ¶[0025]. A non-limiting example of a zoned checksum scheme is the advanced zoned checksum (AZCS). For the Examiner's benefit of understanding, the undersigned notes,
in the context of the above-captioned patent application, when compression (e.g., AZCS compression) is enabled for a zone (e.g., zone 150), both the data and the checksum may fit within the same data block (e.g., data block 151a) as shown in FIG. 2. As such, it should be clear that in the context of the claims, a zoned checksum scheme does not relate to how data is stored within a "data container" (e.g., an internal component of a deduplication file system that contains file data segments in compressed form) such as those described in Bhutani (e.g., data containers A-N 141 of FIG. 1 of Bhutani), but rather relates to how data and corresponding checksums are stored within data blocks persisted to a storage device (e.g., a hyperscale disk)
within a compressed or uncompressed zone of a volume. Neither Bhutani nor Sporri are understood to teach or reasonably suggest the use of a "zoned checksum scheme" in the manner recited. For at least this reason, independent claim 1 (as amended) and its dependent claims, which add further features, are thought to be clearly distinguishable over the Examiner's proposed combination of Bhutani and Sporri.
In response, the Examiner submits:
Applicant’s disclosure discloses [0025] “as used herein a "zoned checksum scheme" generally refers to a checksum scheme in which checksums for a group of data blocks are stored within a designated data block (which may be referred to as a "checksum block") of the group of data blocks. A non- limiting example of a zoned checksum scheme is the AZCS checksum scheme”.
“Generally” (adv) can mean “in most cases; usually”. While “zoned checksum scheme” generally refers to “a checksum scheme in which checksums for a group of data blocks are stored within a designated data block (which may be referred to as a "checksum block") of the group of data blocks”, it is not defined as “a checksum scheme in which checksums for a group of data blocks are stored within a designated data block of the group of data blocks”.
It is clear that the independent claims do not recite limitation(s) that require zoned checksum scheme that is “a checksum scheme in which checksums for a group of data blocks are stored within a designated data block of the group of data blocks”.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
However, Applicant can surely amend the independent claims to recite, for example, zoned checksum scheme “that is a checksum scheme in which checksums for a group of data blocks are stored within a designated data block of the group of data blocks”.
While Claim 1 recites “… selectively enabling or disabling performance of fast path read operations”, the claim clearly does not recite limitation(s) that require the specific feature of “… when compression is enabled for a zone, both the data and the checksum may fit within the same data block”.
Additionally, it is clear from Claim 1 that there is no limitation(s) that require “corresponding checksums” that are “stored within data blocks persisted to a storage device”.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Contrary to Applicant’s allegation above, Bhutani does teach the added limitation of employ a zoned checksum scheme for a set of one or more storage devices to which data is persisted (Bhutani: at least Col. 6 Lines 26-27; “segments may be compressed into one or more compression regions of the container”; Col. 6 Lines 23-26 & 33-36; “metadata section stores fingerprints. The data section stores segments corresponding to the fingerprints stored in the metadata section” and “metadata container may include references, pointers, fingerprints, identifiers, or other information that can be used to locate a corresponding data container residing at a cloud storage service”; Col. 4 Lines 46-48 & Col. 5 Lines 26-31 further disclose “data may be stored in object storage provided by the cloud storage providers (e.g., AWS S3 bucket, or Azure blob)” and “examples of cloud storage providers include Amazon Web Services S3 (AWS) as provided by Amazon of Seattle, Wash.; Azure as provided by Microsoft Corporation of Redmond, Wash.; Dell EMC Elastic Cloud Storage S3 (ECS) as provided by Dell EMC of Hopkinton, Mass.; and others”; note: fingerprint as checksum and Col. 5 Lines 64-65 discloses “Secure Hash Algorithm 1 (SHA-1)” as checksum scheme) by the virtual storage system (Bhutani: at least Col. 20 Lines 1-4 & 8-14; “the particular processing platform 1400 shown in the figure is presented by way of example only, and system 100 may include additional or alternative processing platforms” and “for example, other processing platforms used to implement illustrative embodiments can comprise different types of virtualization infrastructure, in place of or in addition to virtualization infrastructure comprising virtual machines. Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of LXCs”).
Applicant further argues:
With respect to the above-quoted "maintain heuristic data" features, which recite "as read requests associated with a volume of a virtual storage system are processed by a file system of the virtual storage system, maintain heuristic data for the volume predicting odds that data within a plurality of data blocks stored on the volume within one or more compressible zones of the zoned checksum scheme is stored in compressed form," the Examiner relied on Col. 6, Lines 3-5; Col. 7, Lines 62-64; Col. 8, Lines 2-6; Col. 6, Lines 26-27; Col. 6, Lines 23-26 and 33-36; and Col. 5, Lines 64-65 of Bhutani. Based on its usage in the above-captioned patent application, those skilled in the art would appreciate "heuristic data" generally refers to "information used in or enabling problem-solving or decision making." In the context of the claims, heuristic data is maintained as read requests are processed by a file system of the virtual storage system in which the heuristic data predicts the odds that data within a plurality of data blocks stored on the volume within one or more compressible zones of the zoned checksum scheme is stored in compressed form. No such heuristic data is contemplated by either of Bhutani or Sporri.
In response, the Examiner submits:
Bhutani is not relied upon for the teaching of “heuristic data for the volume predicting odds that data within a plurality of data blocks stored on the volume is stored in compressed form”.
One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Bhutani does not explicitly disclose, but Sporri discloses said heuristic data for the volume predicting odds that data within a plurality of data blocks stored on the volume is stored in compressed form (Sporri: at least ¶0040; “… compare the size of a data segment (or an aggregated total of the size of the data segments up to the checkpoint that have been transmitted to the second machine), to the same segment(s) stored on disk. If the size of the transmitted data segments exceeds the size of the data segments stored on disk, there is a good chance that the data is already compressed”).
Applicant further argues:
With respect to the "reduce read amplification" features, which recite "reduce read
amplification by selectively enabling or disabling performance of fast path read operations for the volume based on a current state of the heuristic data," the Examiner relied on Col. 9, Lines 9-15; Col. 9, Lines 45-47 and 50-60; and Col. 13, Lines 50-53 of Bhutani. For the Examiner's benefit of understanding, the undersigned points out the terms "fast path read" and "fast path read operation" are defined terms in the context of the above-captioned patent application referring to "a read operation that avoids use of a data storage virtualization layer (e.g., a RAID layer) of a virtual storage system for retrieval of data and/or an associated checksum of the data associated with a client read request." As such, it is improper for the Examiner to equate Bhutani' s directing of read request to the source or destination cloud while migration is underway depending on whether the data associated with read request remains within the source cloud or has been migrated to the destination cloud with the recited "fast path read operations" which are selectively enabled or disabled based on a current state of the heuristic data (which was shown above not to be properly equated with Bhutani's fingerprint index). For at least these additional reasons, independent claim 1 (as amended) and its dependent claims, which add further features, are thought to be further distinguishable over the Examiner's proposed combination of Bhutani and Sporri.
In response, the Examiner submits:
Applicant’s disclosure discloses [0023] “as used herein a “fast path read” or a “fast path read operation” generally refers to a read operation that avoids use of a data storage virtualization layer (e.g., a RAID layer) of a virtual storage system for retrieval of data and/or an associated checksum of the data associated with a client read request”.
“Generally” (adv) can mean “in most cases; usually”. While a “fast path read” or a “fast path read operation” generally refers to “a read operation that avoids use of a data storage virtualization layer (e.g., a RAID layer) of a virtual storage system for retrieval of data and/or an associated checksum of the data associated with a client read request”, “fast path read” or “fast path read operation” are not defined as “a read operation that avoids use of a data storage virtualization layer of a virtual storage system for retrieval of data and/or an associated checksum of the data associated with a client read request”.
The independent claims clearly do not recite limitation(s) that require the specific feature of fast path read operation that is “a read operation that avoids use of a data storage virtualization layer of a virtual storage system for retrieval of data and/or an associated checksum of the data associated with a client read request”.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
However, Applicant can surely amend the independent claims to recite, for example, fast path read operation that is “a read operation that avoids use of a data storage virtualization layer of a virtual storage system for retrieval of data and/or an associated checksum of the data associated with a client read request”.
Applicant further argues:
Regarding dependent claim 6, the Examiner relied on the compression regions of
Bhutani's data container and the fingerprint output by the hashing algorithm as described in Col. 6, Lines 26-27 and Col. 5, Lines 63-67. Neither Bhutani nor Sporri teach or reasonably suggest the use of a "zoned checksum scheme" as defined "for a set of one or more storage devices to which data is persisted by the virtual storage system" (as noted above), let alone the advanced zone checksum (AZCS). As the Examiner should appreciate, the mere use of the terms "checksum," "compression," and/or "regions" is clearly insufficient to meet the limitations at issue. Especially, considering Bhutani is referring to how data is stored in its "data containers." For at least these additional reasons, dependent claim 6 is further distinguishable over the Examiner's proposed combination of Bhutani and Sporri.
In response, the Examiner submits:
Contrary to Applicant’s allegation above, the Bhutani reference does teach employ a zoned checksum scheme for a set of one or more storage devices to which data is persisted (Bhutani: at least Col. 6 Lines 26-27; “segments may be compressed into one or more compression regions of the container”; Col. 6 Lines 23-26 & 33-36; “metadata section stores fingerprints. The data section stores segments corresponding to the fingerprints stored in the metadata section” and “metadata container may include references, pointers, fingerprints, identifiers, or other information that can be used to locate a corresponding data container residing at a cloud storage service”; Col. 4 Lines 46-48 & Col. 5 Lines 26-31 further disclose “data may be stored in object storage provided by the cloud storage providers (e.g., AWS S3 bucket, or Azure blob)” and “examples of cloud storage providers include Amazon Web Services S3 (AWS) as provided by Amazon of Seattle, Wash.; Azure as provided by Microsoft Corporation of Redmond, Wash.; Dell EMC Elastic Cloud Storage S3 (ECS) as provided by Dell EMC of Hopkinton, Mass.; and others”) where fingerprint reads on checksum and Col. 5 Lines 64-65 of discloses Bhutani teach “Secure Hash Algorithm 1 (SHA-1)” that reads on checksum scheme.
Claim 6 recites “wherein the zoned checksum scheme comprises advanced zone checksum (AZCS)”. One of ordinary skill in the art would recognize that Bhutani “Secure Hash Algorithm 1 (SHA-1)” is an advanced checksum scheme employed for a set one or more storage devices.
Abstract
According to the MPEP, “the abstract should be in narrative form and generally limited to a single paragraph on a separate sheet preferably within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," "The disclosure defined by this invention," "The disclosure describes," etc. In addition, the form and legal phraseology often used in patent claims, such as "means" and "said," should be avoided."
The abstract of the disclosure is objected to because it includes “embodiment” at line 2 on page 1 of the disclosure. “Embodiment” is a legal phraseology and should be changed/removed.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Double Patenting
The rejections raised in the Office Action mailed on 06 August 2025 have been overcome by the applicant’s submission of a Terminal Disclaimer on 06 November 2025.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for allobviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6-8, 13-14 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent 11,093,442 by Bhutani et al. (“Bhutani”) in view of US PGPUB 2016/0173399 by Sporri.
As to Claim 1, Bhutani teaches a virtual storage system (Bhutani: at least Col. 19 Lines 19-21; “FIG. 14 shows an example of a processing platform 1400 that may be used with the information processing system shown in FIG. 1”; Col. 20 Lines 8-14 further discloses “for example, other processing platforms used to implement illustrative embodiments can comprise different types of virtualization infrastructure, in place of or in addition to virtualization infrastructure comprising virtual machines. Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of LXCs”) comprising: one or more processing resources (Bhutani: at least Col. 19 Lines 34-35; “processing device 1402-1 in the processing platform 1400 comprises a processor 1410 coupled to a memory 1412”); and
a non-transitory computer-readable medium, coupled to the one or more processing resources (Bhutani: at least Col. 19 Lines 34-35; “ … a processor 1410 coupled to a memory 1412”), having stored therein instructions that when executed by the one or more processing resources (Bhutani: at least Col. 19 Lines 44-48; “memory 1412 and other memories disclosed herein should be viewed as illustrative examples of what are more generally referred to as “processor-readable storage media” storing executable program code of one or more software programs”) cause the virtual storage system to:
employ a zoned checksum scheme for a set of one or more storage devices to which data is persisted (Bhutani: at least Col. 6 Lines 26-27; “segments may be compressed into one or more compression regions of the container”; Col. 6 Lines 23-26 & 33-36; “metadata section stores fingerprints. The data section stores segments corresponding to the fingerprints stored in the metadata section” and “metadata container may include references, pointers, fingerprints, identifiers, or other information that can be used to locate a corresponding data container residing at a cloud storage service”; Col. 4 Lines 46-48 & Col. 5 Lines 26-31 further disclose “data may be stored in object storage provided by the cloud storage providers (e.g., AWS S3 bucket, or Azure blob)” and “examples of cloud storage providers include Amazon Web Services S3 (AWS) as provided by Amazon of Seattle, Wash.; Azure as provided by Microsoft Corporation of Redmond, Wash.; Dell EMC Elastic Cloud Storage S3 (ECS) as provided by Dell EMC of Hopkinton, Mass.; and others”; note: fingerprint as checksum and Col. 5 Lines 64-65 discloses “Secure Hash Algorithm 1 (SHA-1)” as checksum scheme) by the virtual storage system (Bhutani: at least Col. 20 Lines 1-4 & 8-14; “the particular processing platform 1400 shown in the figure is presented by way of example only, and system 100 may include additional or alternative processing platforms” and “for example, other processing platforms used to implement illustrative embodiments can comprise different types of virtualization infrastructure, in place of or in addition to virtualization infrastructure comprising virtual machines. Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of LXCs”);
as read requests associated with a volume of a virtual storage system are processed by a file system of the virtual storage system, maintain heuristic data for the volume (Bhutani: at least Col. 6 Lines 3-5; “newly arriving segments are filtered out against duplicates using the existing fingerprints in the index and then the new segments are packed into a container along with fingerprints and appended as a log”; Col. 7 Lines 62-64; “entry in the index may be formatted as “fp,cid” where “fp” refers to the fingerprint and “cid” refers to the container ID”; Col. 8 Lines 2-6 further disclose “segments may be placed into containers and written (e.g., written to disk or other persistent storage). An index maintains a mapping between fingerprints of the segments and the containers in which the segments are stored”) within one or more compressible zones of the zoned checksum scheme (Bhutani: at least Col. 6 Lines 26-27; “segments may be compressed into one or more compression regions of the container”; Col. 6 Lines 23-26 & 33-36; “metadata section stores fingerprints. The data section stores segments corresponding to the fingerprints stored in the metadata section” and “metadata container may include references, pointers, fingerprints, identifiers, or other information that can be used to locate a corresponding data container residing at a cloud storage service”; note: fingerprint as checksum and Col. 5 Lines 64-65 discloses “Secure Hash Algorithm 1 (SHA-1)” as checksum scheme); and
reduce read amplification by selectively enabling or disabling performance of fast path read operations for the volume based on a current state of the heuristic data (Bhutani: at least Col. 9 Lines 9-15; “data responsive to the read request may still be residing at the source cloud. In this case, the application read/write director directs the read request to the source cloud” and “the data responsive to the read request may have already been migrated to the destination cloud. In this case, the application read/write director directs the read request to the destination cloud”; Col. 9 Lines 45-47 & 50-60 further disclose “read requests occurring during the migration result in querying 445 the fingerprint index to determine whether the read should be serviced by the source cloud or the destination cloud” and “read path 510. In a step 515, there is an incoming read request. In a step 520, the index is queried for metadata for a given fingerprint associated with the read request. In a step 525, based on the fingerprint to container ID mapping in the index, a determination is made as to whether to redirect the read request to the source (SRC) or destination (DST) cloud bucket. If the read request is directed to the source cloud bucket, a region is read from the source cloud bucket (step 530). If the read request is directed to the destination cloud bucket, a region is read from the destination cloud bucket (step 535)”; Col. 13 Lines 50-53 further disclose “all read requests may be split into two types. Read requests coming for data residing on the source storage tier versus read requests coming for data residing on the destination storage tier”).
Bhutani does not explicitly disclose, but Sporri teaches said heuristic data for the volume predicting odds that data within a plurality of data blocks stored on the volume is stored in compressed form (Sporri: at least ¶0040; “… compare the size of a data segment (or an aggregated total of the size of the data segments up to the checkpoint that have been transmitted to the second machine), to the same segment(s) stored on disk. If the size of the transmitted data segments exceeds the size of the data segments stored on disk, there is a good chance that the data is already compressed”).
It would have been obvious to one of ordinary skill in the art before the effectivefiling date of the claimed invention to incorporate Sporri’s feature of heuristic data for the volume predicting odds that data within a plurality of data blocks stored on the volume is stored in compressed form (Sporri: at least ¶0040) with the volume within one or more compressible zones of a zoned checksum scheme in Bhutani’s virtual storage system.
The suggestion/motivation for doing so would have been to avoid wasting computing resources on data that do not need to be compressed and/or identify effectiveness of a particular compression scheme (Sporri: at least ¶¶0023, 0033; “it is possible that the requested data stored in the storage 110 is already compressed. If this is the case, then compressing the file again is not likely to make the size of the requested data smaller. Rather, the size of the requested data may actually increase due to the nature of the compression routine. As such, the first machine 102 may be wasting CPU cycles compressing data that does not need to be compressed. Moreover, the first machine 102 may ultimately waste even more CPU cycles transmitting the data where the overall size of the data increases due to the compression applied before transmitting. This can lead to large amounts of unnecessary cost incurred to process the request for data” and “… one or more rules that are evaluated to test the effectiveness of the identified compression algorithm”).
Claim 8 (a method claim) corresponds in scope to Claim 1, and are similarly rejected.
Claim 14 (a machine readable medium claim) corresponds in scope to Claim 1, and are similarly rejected.
As to Claim 6, Bhutani and Sporri teach the virtual storage system of claim 1, wherein the zoned checksum scheme comprises advanced zone checksum (AZCS) (Bhutani: at least Col. 6 Lines 26-27; “segments may be compressed into one or more compression regions of the container”; Col. 5 Lines 63-67; “segment of data is hashed using a cryptographic hash for example Secure Hash Algorithm 1 (SHA-1). The output of the hashing algorithm is the fingerprint which uniquely describes that segment of data in the storage system”; SHA-1 as checksum for the regions or zones).
Claim 13 (a method claim) corresponds in scope to Claim 6, and are similarly rejected.
Claim 19 (a machine readable medium claim) corresponds in scope to Claim 6, and are similarly rejected.
As to Claim 7, Bhutani and Sporri teach the virtual storage system of claim 1, wherein the heuristic data is maintained in-memory (Bhutani: at least Col. 6 Lines 1-2; “index 138 of all the fingerprints is maintained in the system”; Col. 8 Lines 7-8 also discloses “fingerprint of the segment is maintained in the index”; Col. 9 Lines 19-21 further discloses “fingerprint index 415 and container log 420 is maintained at the storage server”).
Claim 20 (a machine readable medium claim) corresponds in scope to Claim 7, and are similarly rejected.
Claims 2, 9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent 11,093,442 by Bhutani et al. (“Bhutani”) in view of US PGPUB 2016/0173399 by Sporri, and further in view of US PGPUB 2020/0210586 by Cariello et al. (“Cariello”).
As to Claim 2, Bhutani and Sporri teach the virtual storage system of claim 1.
Bhutani and Sporri do not explicitly disclose, but Cariello discloses, wherein the heuristic data further includes a retry counter indicative of a number of times a retrieved data block of the plurality of data blocks does not contain a checksum for the data contained within the retrieved data block (Cariello: at least ¶0073; “read-retry options that specify options on how to retry reading for firmware at a particular location” and “failures may be caused by … checksum mismatches, and the like”; ¶0081 further discloses “determines if the number of read retries attempted exceeds a maximum number of read retry loops at operation 622”) and wherein the instructions further cause the virtual storage system to, after the retry counter meets or exceeds a maximum retry threshold, disable the fast path read operations for subsequent read requests associated with the volume (Cariello: at least ¶0091; “determine whether the number of times the system has tried each location exceeds a maximum number of read retry loops at operation 820. If the answer is yes, then processing terminates”; note: when read process terminated/disabled and thus disabling paths for further read requests; ¶0073 discloses “when the controller reads the location in NAND” – NAND memory is typically fast and reads on fast path).
It would have been obvious to one of ordinary skill in the art before the effectivefiling date of the claimed invention to incorporate Cariello’s features of wherein the heuristic data further includes a retry counter indicative of a number of times a retrieved data block of the plurality of data blocks does not contain a checksum for the data contained within the retrieved data block (Cariello: at least ¶¶0073, 0081) and wherein the instructions further cause the virtual storage system to, after the retry counter meets or exceeds a maximum retry threshold, disable the fast path read operations for subsequent read requests associated with the volume (Cariello: at least ¶¶0073, 0091) with Bhutani’s virtual storage system.
The suggestion/motivation for doing so would have been to make attempt to retrieve data in case of a read failure caused by “Uncorrectable Error Correction Codes (UECC), checksum mismatches, and the like” (Cariello: at least ¶0073).
Claim 9 (a method claim) corresponds in scope to Claim 2, and are similarly rejected.
Claim 15 (a machine readable medium claim) corresponds in scope to Claim 2, and are similarly rejected.
Claims 3-5, 10-12 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent 11,093,442 by Bhutani et al. (“Bhutani”) in view of US PGPUB 2016/0173399 by Sporri, and further in view of US PGPUB 2017/0185296 by Dong et al. (“Dong”).
As to Claim 3, Bhutani and Sporri teach the virtual storage system of claim 1.
Bhutani and Sporri do not explicitly disclose, but Dong discloses wherein the heuristic data further includes a read counter indicative of a total number of read requests received by the file system involving one or more of the plurality of data blocks (Dong: at least ¶0046; “receiving or distributing two consecutive read requests by the storage system”; ¶0023 also discloses “… to record, for each of the plurality of storage devices, the number of currently outstanding read requests and the number of completed read requests within a predefined time period”) during an active window of read requests (Dong: at least ¶0046; “a period for obtaining the number of completed read requests” and “number of read requests completed within a period”; ¶0079 also discloses “number of currently outstanding read requests and the number of completed read requests within a predefined time period”).
It would have been obvious to one of ordinary skill in the art before the effectivefiling date of the claimed invention to incorporate Dong’s features of wherein the heuristic data further includes a read counter indicative of a total number of read requests received by the file system involving one or more of the plurality of data blocks (Dong: at least ¶¶0023, 0046) during an active window of read requests (Dong: at least ¶¶0046, 0079) with Bhutani’s virtual storage system.
The suggestion/motivation for doing so would have been to control data reading from a storage system (Dong: at least ¶0006; “present disclosure provide methods and apparatus for controlling data reading from the storage system”; ¶0051 also discloses “more suitable disk may be selected to serve the next read request”) such that better performance is achieved (Dong: at least ¶0026; “shorten I/O response time, enhance I/O performance, and/or achieve load balance of I/O reading among a plurality of storage devices”; ¶0047 also discloses “next I/O read request will be sent to disk 1 to obtain better performance”).
Claim 10 (a method claim) corresponds in scope to Claim 3, and are similarly rejected.
Claim 16 (a machine readable medium claim) corresponds in scope to Claim 3, and are similarly rejected.
As to Claim 4, Bhutani, Sporri and Dong xxx teach the virtual storage system of claim 3.
Bhutani and Sporri do not explicitly disclose, but Dong discloses wherein the heuristic data further includes a success rate calculated based on a number of read requests of the total number of read requests for which the heuristic data successfully predicted results of the read requests (Dong: at least ¶0023; “… to record, for each of the plurality of storage devices, … the number of completed read requests within a predefined time period”; ¶0049 further discloses “from a group of storage devices with the smallest number of outstanding read requests in the plurality of storage devices, a storage device with the number of completed read requests exceeding a predefined threshold may be determined as the target storage device”; ¶0050 further discloses “storage device with the largest number of completed read requests in the group of storage devices with the smallest number of outstanding read requests of the plurality of storage devices may be determined as the target storage device”; note: smallest number of outstanding read and largest number of completed read or completed read above a threshold as high success rate; completed read request as successful) and wherein the instructions further cause the virtual storage system to, after the success rate meets or exceeds predetermined or configurable success rate threshold, enable the fast path read operations for subsequent read requests associated with the volume (Dong: at least ¶0061; “Step 6: determining whether the number of completed read requests of the storage device exceeds a predefined threshold; and if the number of completed read requests for the storage device exceeds a predefined threshold, going to Step 7, otherwise going to Step 8”) in order to control data reading from a storage system (Dong: at least ¶0006; “present disclosure provide methods and apparatus for controlling data reading from the storage system”; ¶0051 also discloses “more suitable disk may be selected to serve the next read request”) such that better performance is achieved (Dong: at least ¶0026; “shorten I/O response time, enhance I/O performance, and/or achieve load balance of I/O reading among a plurality of storage devices”; ¶0047 also discloses “next I/O read request will be sent to disk 1 to obtain better performance”).
Claim 11 (a method claim) corresponds in scope to Claim 4, and are similarly rejected.
Claim 17 (a machine readable medium claim) corresponds in scope to Claim 4, and are similarly rejected.
As to Claim 5, Bhutani, Sporri and Dong teach the virtual storage system of claim 3, wherein the instructions further cause the virtual storage system to, after the read counter meets or exceeds a threshold, reset the heuristic data (Dong: at least ¶0020; “determining whether the number of completed read requests of the storage device exceeds a predefined threshold” and “if the number of completed read requests of the storage device exceeds a predefined threshold, going to Step 7”; ¶0021 further discloses “Step 7: … resetting the number of completed read requests as zero”).
Claim 12 (a method claim) corresponds in scope to Claim 5, and are similarly rejected.
Claim 18 (a machine readable medium claim) corresponds in scope to Claim 5, and are similarly rejected.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Huen Wong whose telephone number is (571) 270-3426. The examiner can normally be reached on Monday - Friday (10:30AM EST - 6:30PM EST). If attempts to reach the examiner by telephone are unsuccessful, the Examiner's supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300 for regular communications and after final communications.
Information regarding the status of an application may be obtained from thePatent Application Information Retrieval (PAIR) system. Status information forpublished applications may be obtained from either Private PAIR or Public PAIR.Status information for unpublished applications is available through Private PAIR only.For more information about the PAIR system, see http://pair-direct.uspto.gov. Shouldyou have questions on access to the Private PAIR system, contact the ElectronicBusiness Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from aUSPTO Customer Service Representative or access to the automated informationsystem, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H .W./
Examiner, AU 2168
02 February 2026
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168