Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the claim recites “and discard messages, which reference portions of the data no longer required by the file system” the examiner is unsure if “discard messages” is a noun referring to the type of messages or a verb to discard the messages that refer to unrequired data. Examiner respectfully interprets the language as a noun.
Regarding claim 1, the claim recites “determine that a capacity of the allocated block storage is excessive.” The term “excessive” is a relative term which renders the claim indefinite. The term “excessive” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claims 2-20 inherit the same rejections as claim 1 considering their dependency or for reciting similar claim limitations.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 2, 6, 10, 12, 17 and 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dippenaar et al. (US 20160127200 A1).
Regarding claim 1, Dippenaar teaches a computer software product for use with at least one remote storage device,(Storage nodes 224 of block storage service 220) the computer software product comprising a tangible non-transitory computer-readable medium in which program instructions are stored, which instructions, when read by a processor of a local device, (storage client 300) cause the processor to: (0062; The method may be implemented by a computer system that includes one or more processors executing program instructions stored on a computer-readable storage medium coupled to the processors.)
intercept messages from a file system running on the local device (I/O requests from storage clients to the storage volume flow through system manager which is local to the storage client) and directed to the remote storage device (storage volume part of the block storage service), (0017 teach I/O storage requests); file system manager 150 at storage client(s) 140 may send various I/O requests to storage volume 130 as part of utilizing storage volume for the file system implemented at storage client(s) 140;
[0034] Storage client 300, which may be clients 210, virtual compute instances 232, or internal client discussed above, may communicate over network 360 (similar to network 260 above) with block-based service 370. Block-based storage service 370 may be similar to block-based storage service 220 in some embodiments. Storage client 300 may mount a storage volume 372 maintained in block-based storage system 370 for a file system implemented at storage client 300.
[0035] file system manager manages and directs I/O requests between components of the storage client and other file systems.
[0046] teaches the storage nodes are distributed network based storage; Storage client 510 may then initiate file system I/O to the storage volume maintained at storage node(s) 530, in some embodiments. File system I/O may be performed according to a network-based storage protocol 582, such as iSCSI.)
the messages including write messages, which specify data to be written (0042; The I/O requests include write requests received from the clients of the storage volume; A master storage node may, in various embodiments, receive and process requests (e.g., I/O requests) from clients of the storage volume. Thus, a master storage node may then coordinate replication of I/O requests, such as write requests, or any other changes or modifications to a storage volume ... Thus, when a write request is received for a storage volume at a storage node, the storage node may forward the write request to another storage node and wait until storage node acknowledges the write request as complete before completing the write.)
to block storage (block storage volume) on the remote storage device (network storage service) allocated to a user account (mapped to the client, which is mapped to the user accounts) associated with the local device, (mapping above + 0026; teaches block storage in a network based block storage service, provided through storage volumes mapped to particular clients;
[0016] storage clients 140 may provision a storage volume in network based data store … the storage clients may mount the storage volume
[0029] Block-based storage service control plane 222 may provide a variety of services related to providing block level storage functionality, including the management of user accounts (e.g., creation, deletion, billing, collection of payment, etc.). Block-based storage service control plane 222 may further provide services related to the creation, usage and deletion of storage volumes and scaling policies in response to configuration requests)
and discard messages, (deleted command message) which reference portions of the data no longer required by the file system (data that is requested to be deleted), (0073; For example, a network-based service implemented according to a RESTful technique may be invoked through parameters included within an HTTP method such as PUT, GET, or DELETE, rather than encapsulated within a SOAP message.; [0046] . For example, various copy, move, allocate, delete, or defrag commands may be sent to storage node(s) 530.)
based on the messages, (I/O requests) track a size of the data stored in the block storage (amount of storage used based on available storage and capacity) and required by the file system (data that was previously requested to be stored and not deleted) (0035; collect metrics and performance information including access and I/O patterns and storage capacity which is used for scaling.
[0018 + See 0017-0019] A scaling policy may include on or more conditions that trigger various control plane actions to scale the storage volume 130. For example, storage volume 130 may be scaled to increase in size, decrease in size, redistribute storage resources for the storage volume differently, and/or provision different throughput performance (e.g., input/output operations per second (IOPs)) for the storage volume 130. Various different thresholds or conditions may be evaluated with respect to volume performance metrics and storage capacity to detect scaling events (e.g., too much or too little storage capacity or bandwidth));
[0029] Block-based storage service control plane 222 may further provide services related to the creation, usage and deletion of storage volumes and scaling policies in response to configuration requests. Block-based storage service control plane 222 may also provide services related to the creation, usage and deletion of volume snapshots on backup storage service 240.
[0050] A scaling policy may include one or more multiple conditions. For instance, the scaling policy may define different thresholds or alarms as well as the resulting scaling actions if met or triggered. For example, the amount of available storage capacity at the storage volume may have floor and/or ceiling thresholds which, if exceeded cause the amount of storage capacity in the storage volume to be increased or reduced accordingly.
based on the tracking, determine that a capacity of the allocated block storage is excessive, relative to the size of the data (too much storage capacity), (Same mapping as limitation directly above; The system tracks the usage and remaining resources which is inherent in scaling based on availability. Furthermore [0018] clearly teaches scaling based on “too much or too little storage capacity”, 0029 teaches the use of thresholds for determining scaling and configuration (equivalent to excessive))
and in response to the capacity being excessive, reduce the capacity. (mapping above; 0017-0019; if too much storage capacity decreasing the storage capacity; 0058 teaches a scaling event that reduces/shrinks the storage capacity of the storage volume)
Regarding claim 2, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar further teaches wherein the remote storage device belongs to a cloud-computing platform. (0022; Provider network 200 may be set up … to provide one or more services (such as various types of cloud-based computing or storage) accessible via the Internet and/or other networks to clients 210.)
Regarding claim 6, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar teach wherein the instructions further cause the processor to:
based on the tracking, determine that the capacity is insufficient, relative to the size of the data, (Claim 1 Mapping + [0018] Various different thresholds or conditions may be evaluated with respect to volume performance metrics and storage capacity to detect scaling events (e.g., too much or too little storage capacity or bandwidth). [0050] For instance, the scaling policy may define different thresholds or alarms as well as the resulting scaling actions if met or triggered. For example, the amount of available storage capacity at the storage volume may have floor and/or ceiling thresholds which, if exceeded cause the amount of storage capacity in the storage volume to be increased or reduced accordingly.)
and in response to the capacity being insufficient, increase the capacity. ([0056] The indication may provide the increase amount, in various embodiments. For instance, the indication may provide the number of additional data blocks or pages of storage space allocated to the scaled storage volume. In some embodiments, mapping information, such as particular logical blocks assigned to the storage volume may be indicated, or such determinations may be left to/reserved for the file system at the storage client.
[0057]; creating additional storage capacity based on a scaling event.
[0019] data store control plane 120 also dynamically scales the storage volume.)
Regarding claim 10, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar teaches wherein the instructions cause the processor to determine that the capacity is excessive in response to a difference between the capacity and the size of the data (available storage capacity is the overall capacity minus the utilized capacity) exceeding a predefined threshold (ceiling threshold) (Claim 1 Mapping + [0018] Various different thresholds or conditions may be evaluated with respect to volume performance metrics and storage capacity to detect scaling events (e.g., too much or too little storage capacity or bandwidth). [0050] For instance, the scaling policy may define different thresholds or alarms as well as the resulting scaling actions if met or triggered. For example, the amount of available storage capacity at the storage volume may have floor and/or ceiling thresholds which, if exceeded cause the amount of storage capacity in the storage volume to be increased or reduced accordingly. ([0056] The indication may provide the increase amount, in various embodiments. For instance, the indication may provide the number of additional data blocks or pages of storage space allocated to the scaled storage volume. In some embodiments, mapping information, such as particular logical blocks assigned to the storage volume may be indicated, or such determinations may be left to/reserved for the file system at the storage client. [0057]; creating additional/reducing storage capacity based on a scaling event. [0019] data store control plane 120 also dynamically scales the storage volume.)
Regarding claim 12, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dipenaar further teaches wherein the instructions further cause the processor to refrain from reducing the capacity to less than a predefined threshold (capacity floor). (0050: For instance, the scaling policy may define different thresholds or alarms as well as the resulting scaling actions if met or triggered. For example, the amount of available storage capacity at the storage volume may have floor and/or ceiling thresholds which, if exceeded cause the amount of storage capacity in the storage volume to be increased or reduced accordingly.)
Regarding claim 17, the claim inherits the same rejection as claim 1 for reciting similar limitations in the form of an method claim. (0066; 0068; methods for performing the invention)
Regarding claim 20, the claim inherits the same rejection as claim 1 for reciting similar limitations in the form of an apparatus claim. (0064-0071; computer system with nodes, computers, processors and memory storing instructions executed by a processor)
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 35 U.S.C. 103 which forms the basis for all obviousness 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, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 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.
Claim(s) 3-5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dippenaar et al. (US 20160127200 A1) in view of Vilayannur et al. (US 20120167080 A1).
Regarding claim 3, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar does not explicitly teach wherein the program instructions include a driver.
In an analogous art Vilayannur teaches wherein the program instructions include a driver. (0023; For example, while FIG. 2 depicts disk monitor application 207 as a user-level application (e.g., running in the background), alternative embodiments may implement such functionality within the guest operating system 208 (e.g., such as a device driver level component, etc.) or within the various layers of the 10 stack of hypervisor 214. [0023] also teaches disk monitor application 207 may detect and intercept (e.g., via a file system filter driver or other similar methods) disk operations transmitted by applications 206 or guest operating system 208 to an HBA driver)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [implementing operations through the use of a driver] as is taught by [Vilayannur].
The suggestion/motivation for doing so is to [improve computing platform virtualization storage operations [Background].
Regarding claim 4, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar does not explicitly teach wherein the instructions cause the processor to intercept the messages by interposing between the file system and a block device driver of the remote storage device.
In an analogous art Vilayannur teaches wherein the instructions cause the processor to intercept the messages by interposing (Fig 1; storage system manager which sits between elements server 100 and file system 115) between the file system (server 100) and a block device driver ( virtual machine file system (VMFS) driver 216 that manages access to files (e.g., virtual disks, etc.) stored in data storage systems (such as data storage system 125) that may be accessed by any of the virtual machines 203) of the remote storage device (data storage system)(0017; shows the interaction with data storage system 125 and the servers 100 through a network)
0019; Fig 1 and Fig 2; [0019] FIG. 2 illustrates a virtual machine based computer system 200, according to an embodiment. A computer system 201, generally corresponding to one of the servers 100;
[0020]; the guest file system may utilize a host bus adapter driver in guest operating system 208 to interact with a host bus emulator 213 in VMM component of the hypervisor 214;
[0022]; File system calls for performing data transfer and control operations generated, for example, by one of applications 206 are translated and passed to a virtual machine file system (VMFS) driver 216 that manages access to files (e.g., virtual disks, etc.) stored in data storage systems (such as data storage system 125) that may be accessed by any of the virtual machines 203.
[0023]; References to data blocks in instructions issued or transmitted by guest operating system 208 to virtual disk 220 are sometimes referred to herein as "logical" data blocks since virtual disk 220 is itself a logical conception (as opposed to physical) that is implemented as a file stored in a remote storage system … disk monitor application 207 may detect and intercept (e.g., via a file system filter driver or other similar methods) disk operations transmitted by applications 206 or guest operating system 208 to an HBA driver in guest operating system 208)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [implementing operations through an intermediary sitting between the remote data storage system and the VM on a local host] as is taught by [Vilayannur].
The suggestion/motivation for doing so is to [improve computing platform virtualization storage operations [Background].
Regarding claim 5, Dippenaar in view of Vilayannur teach the computer software product according to claim 4, and is disclosed above, Dippenaar does not explicitly teach but Vilayannur teaches to intercept the messages by interposing (storage system manager) between a block device application program interface of the local device (Server 100 and its interface through the storage network) and the block device driver. (Storage system 125 and VMM driver or HBA drivers)( 0017; While DSU 120 is exposed to operating systems 110.sub.A to 110.sub.B by system storage manager 130 (e.g., disk controller) as a contiguous logical storage space, the actual physical data blocks upon which shared file system 115 may be stored is dispersed across the various physical disk drives 135.sub.X to 135.sub.Z of data storage system 125; (0017; shows the interaction with data storage system 125 and the servers 100 through a network)
0019; Fig 1 and Fig 2; [0019] FIG. 2 illustrates a virtual machine based computer system 200, according to an embodiment. A computer system 201, generally corresponding to one of the servers 100;
[0020]; the guest file system may utilize a host bus adapter driver in guest operating system 208 to interact with a host bus emulator 213 in VMM component of the hypervisor 214;
[0022]; File system calls for performing data transfer and control operations generated, for example, by one of applications 206 are translated and passed to a virtual machine file system (VMFS) driver 216 that manages access to files (e.g., virtual disks, etc.) stored in data storage systems (such as data storage system 125) that may be accessed by any of the virtual machines 203.
[0023]; References to data blocks in instructions issued or transmitted by guest operating system 208 to virtual disk 220 are sometimes referred to herein as "logical" data blocks since virtual disk 220 is itself a logical conception (as opposed to physical) that is implemented as a file stored in a remote storage system … disk monitor application 207 may detect and intercept (e.g., via a file system filter driver or other similar methods) disk operations transmitted by applications 206 or guest operating system 208 to an HBA driver in guest operating system 208)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [implementing operations through an intermediary sitting between the remote data storage system and the VM on a local host] as is taught by [Vilayannur].
The suggestion/motivation for doing so is to [improve computing platform virtualization storage operations [Background].
Claim(s) 7 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dippenaar et al. (US 20160127200 A1) in view of Vajravel (US 20180210648 A1)
Regarding claim 7, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar does not explicitly teach wherein the remote storage device does not support the discard messages, and wherein the instructions further cause the processor to instruct the file system to issue the discard messages even though the remote storage device does not support the discard messages.
In an analogous art Vajravel teaches wherein the remote storage device does not support the discard messages, and wherein the instructions further cause the processor to instruct the file system to issue the discard messages even though the remote storage device does not support the discard messages. ([0038] As with any other command bound for mass storage device 240, virtual disk enumerator 260 can route the “unsupported” commands (or, more specifically, sufficient information to allow a corresponding IRP to implement the command to be created on client terminal 102) to proxy 310 via agent 250. However, at this point, proxy 310 will not be able to pass the unsupported commands onto disk driver 220a (or, if it did, disk driver 220a would reject the commands). To address this issue, proxy 310 can be configured to selectively route unsupported commands directly to mass storage device 240 rather than passing them onto disk driver 220a. [0037] commands include unmap and trim commands)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [to send unsupported commands regardless of being unsupported] as is taught by [Vajravel].
The suggestion/motivation for doing so is to [improve redirection in a VDI environment [Background]].
Regarding claim 18, the claim inherits the same rejection as claim 7 for reciting similar limitations in the form of an method claim. (0066; 0068; methods for performing the invention)
Claim(s) 8 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dippenaar et al. (US 20160127200 A1) in view of Shatsky et al. (US 20220414102 A1)
Regarding claim 8, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar does not explicitly teach wherein the instructions further cause the processor to provision physical addresses in the remote storage device and to map logical addresses provided by the file system to the provisioned physical addresses, such that the block storage is thin provisioned.
In an analogous art Shatsky teaches to provision physical addresses (physical addresses) in the remote storage device (storage devices) and to map logical addresses provided by the file system (Fily system allocates and defines the addressable units) to the provisioned physical addresses, (0032; In embodiments where the storage data server 220 abstracts the physical media (e.g., storage devices 280) and presents logical (virtualized) addresses to users in the form of LUNs, the storage data server 220 generates and manages metadata to provide mapping between logical addresses and physical addresses. In addition, the storage control system 210 generates and manages metadata which is utilized for managing snapshots, change tracking for remote replication, managing deduplication pointers, managing data compression (0045; The allocation units are fixed-size addressable units having a fixed “allocation unit size” or “cluster size” which is defined by the file system or operating system kernel when formatting a storage device. An allocation unit represents the smallest logical block size of storage space that can be used to hold data and which is addressed as one logical unit by the operating system)
such that the block storage is thin provisioned. (0032; The storage virtualization management module 222 implements any suitable logical volume management (LVM) system which is configured to create and manage the storage volumes 282 by aggregating the capacity of the storage devices 280 into one or more virtual storage pools that are thin-provisioned for maximum capacity, and logically dividing each storage pool into one or more storage volumes that are exposed as block devices (e.g., LUNs) to the applications or host systems 110 (FIG. 1) which consume the data. )
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [mapping physical and logical addresses as part of thin provisioning process] as is taught by [Shatsky].
The suggestion/motivation for doing so is to [improve thin provisioning and mapping mechanism in storage systems [Background]].
Regarding claim 19, the claim inherits the same rejection as claim 8 for reciting similar limitations in the form of an method claim. (0066; 0068; methods for performing the invention)
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dippenaar et al. (US 20160127200 A1) in view of Vincent (US 20180039449 A1)
Regarding claim 9, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar further teaches wherein the remote storage device includes a solid state drive, (0042; Volume storage 426 may persist their respective data volumes in one or more block-based storage devices (e.g., hard disk drives, solid state drives, etc.) that may be directly attached to a computing system or device implementing the respective storage node 420.)
Dippenaar does not explicitly teach and wherein the discard messages include TRIM instructions.
In an analogous art Vincent teaches and wherein the discard messages include TRIM instructions ([0016] In some embodiments, deletion notifications may correspond to “Data Set Management” commands, as defined within the ATA/ATAPI command set. For example, deletion notifications may be generated as part of a TRIM function of a “Data Set Management” command, which may hereafter be generally referred to as “TRIM commands.” TRIM commands are generally implemented in order to facilitate communication between a computing device and a solid state drive (SSD).)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [discard commands including trim instructions] as is taught by [Vincent].
The suggestion/motivation for doing so is to [utilize thin provisioning in data storage services [Background]].
Claim(s) 13 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dippenaar et al. (US 20160127200 A1) in view of Doh et al. (US 20190163621 A1).
Regarding claim 13, Dippenaar teaches the computer software product according to claim 1, and is disclosed above, Dippenaar does not explicitly teach wherein, prior to the reduction of the capacity, a first range of physical addresses in the remote storage device are allocated to the user account, wherein the instructions further cause the processor to identify, based on the messages, those of the physical addresses at which the data required by the file system is stored, and wherein the instructions cause the processor to reduce the capacity by: allocating a second range of physical addresses, which is smaller than the first range, to the user account, and copying the data required by the file system from any of the identified physical addresses not in the second range to the second range.
In an analogous art Doh teaches wherein, prior to the reduction of the capacity, (Trim after copy) a first range of physical addresses (physical addresses) in the remote storage device (storage device) are allocated to the user account (0029; User operating host storing and deleting files. The storage includes logical and physical addresses which create a mapping table and bit map)
wherein the instructions further cause the processor to
identify, based on the messages, (0027; trim after copy message provided by the host) those of the physical addresses (logical to physical mapping of valid data) at which the data required by the file system (data not deemed invalid) is stored, (0027; The TRIM-after-COPY command may represent a single command in which a data read command, a data write command and a TRIM command are combined or integrated with each other, and will be described in detail with reference to FIG. 4.; [0028] Valid data stored in the first storage region are internally copied into a second storage region based on the TRIM-after-COPY command (step S200). An operation of internally copying the valid data (e.g., an internal data copy operation or simply a data copy operation) may represent an operation in which the valid data are directly copied from the first storage region into the second storage region in the storage device; See 0039-0040 for translating requests to physical addresses)
and wherein the instructions cause the processor to reduce the capacity by:
allocating a second range of physical addresses,(Second storage region logically and physically different from the first) which is smaller than the first range, (all data minus invalid data = valid data which would be smaller than all data see compaction operation - 0027) to the user account (User operating the host that stored the data), (0028; An operation of internally copying the valid data (e.g., an internal data copy operation or simply a data copy operation) may represent an operation in which the valid data are directly copied from the first storage region into the second storage region in the storage device without going through the external host. For example, the first storage region and the second storage region may be logically and physically different from each other; 0029] A TRIM (now bene, while this term is usually capitalized, it is not an abbreviation or acronym.) operation is performed based on the TRIM-after-COPY command to update a logical-to-physical address mapping table and a valid page bitmap (step S300).)
and copying the data required by the file system from any of the identified physical addresses not in the second range to the second range. (0028; An operation of internally copying the valid data (e.g., an internal data copy operation or simply a data copy operation) may represent an operation in which the valid data are directly copied from the first storage region into the second storage region in the storage device without going through the external host. For example, the first storage region and the second storage region may be logically and physically different from each other; 0029] A TRIM (now bene, while this term is usually capitalized, it is not an abbreviation or acronym.) operation is performed based on the TRIM-after-COPY command to update a logical-to-physical address mapping table and a valid page bitmap (step S300); See 0030 for mapping table and bitmap updating)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [a trim after copy function for moving data as part of a compaction operation] as is taught by [Doh].
The suggestion/motivation for doing so is to [data management methods performed in storage devices [Background]].
Regarding claim 16, Dippenaar in view of Doh teach the computer software product according to claim 13, and is disclosed above, Dippenaar wherein the at least one remote storage device includes a storage disk including the first range of physical addresses,
and wherein a portion of the storage disk includes the second range of physical addresses, such that the copying includes copying the data from outside the portion of the storage disk to the portion of the storage disk. (0028; An operation of internally copying the valid data (e.g., an internal data copy operation or simply a data copy operation) may represent an operation in which the valid data are directly copied from the first storage region into the second storage region in the storage device without going through the external host. For example, the first storage region and the second storage region may be logically and physically different from each other; 0029] A TRIM (now bene, while this term is usually capitalized, it is not an abbreviation or acronym.) operation is performed based on the TRIM-after-COPY command to update a logical-to-physical address mapping table and a valid page bitmap (step S300); See 0030 for mapping table and bitmap updating)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar] to include [a trim after copy function for moving data as part of a compaction operation] as is taught by [Doh].
The suggestion/motivation for doing so is to [data management methods performed in storage devices [Background]].
Claim(s) 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dippenaar et al. (US 20160127200 A1) in view of Doh et al. (US 20190163621 A1) in view of Berke et al. (US 20180356994 A1).
Regarding claim 14, Dippenaar in view of Doh teach the computer software product according to claim 13, and is disclosed above, Dippenaar in view of Doh do not explicitly teach wherein the at least one remote storage device includes a first storage disk including the first range of physical addresses and a second storage disk including the second range of physical addresses, such that the copying includes copying the data from the first storage disk to the second storage disk.
In an analogous art Berke teaches wherein the at least one remote storage device includes a first storage disk including the first range of physical addresses and a second storage disk including the second range of physical addresses, ((0029; For instance, in a RAID level 1 system, data redundancy is implemented using disk mirroring, which replicates a complete disk of data to be preserved. For instance, a first disk may be used to store received data, while a second disk is used to store an exact copy of the data stored on the first disk.; 0041; a first address range of the first memory and second address range of the second memory)
such that the copying includes copying the data from the first storage disk to the second storage disk. (0029; For instance, in a RAID level 1 system, data redundancy is implemented using disk mirroring, which replicates a complete disk of data to be preserved. For instance, a first disk may be used to store received data, while a second disk is used to store an exact copy of the data stored on the first disk.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar in view of Doh] to include [copying data from one disk to another] as is taught by [Berke].
The suggestion/motivation for doing so is to [improve speed and configurability of memory operations [0001]]
Regarding claim 15, Dippenaar in view of Doh teach the computer software product according to claim 13, and is disclosed above, Dippenaar in view of Doh do not explicitly teach wherein the at least one remote storage device includes multiple storage disks including the first range of physical addresses, And wherein a subset of the storage disks includes the second range of physical addresses, such that the copying includes copying the data from those of the storage disks not in the subset to the subset.
In an analogous art Berke teaches wherein the at least one remote storage device includes multiple storage disks including the first range of physical addresses, ([0029; 0041; two disks and one includes a first address range) And wherein a subset (a subset of 2 disks can be one disk) of the storage disks includes the second range of physical addresses, such that the copying includes copying the data from those of the storage disks not in the subset to the subset (copying data from a first disk to a second disk). ((0029; For instance, in a RAID level 1 system, data redundancy is implemented using disk mirroring, which replicates a complete disk of data to be preserved. For instance, a first disk may be used to store received data, while a second disk is used to store an exact copy of the data stored on the first disk.; 0041; a first address range of the first memory and second address range of the second memory)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Dippenaar in view of Doh] to include [copying data from one disk to another] as is taught by [Berke].
The suggestion/motivation for doing so is to [improve speed and configurability of memory operations [0001]]
Conclusion
Claim 11 is not rejected under any prior art rejections.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDERRAHMEN H CHOUAT whose telephone number is (571)431-0695. The examiner can normally be reached on Mon-Fri from 9AM to 5PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
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.
Abderrahmen Chouat
Examiner
Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights