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 .
Response to Amendment
Applicant's response filed 05 May 2026 has been considered and entered. Accordingly, claims 1, 3-14, 16-22 are pending in this application. Claims 1, 4-11, 13-14, and 16-20 are currently amended; claims 3 and 21 are previously presented; claim 12 is original; claims 2 and 15 are cancelled; and claim 22 is newly added.
Double Patenting
3. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
4. Claims 1, 3-14 and 16-22 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 5-14, 16, and 19-20 of copending Application No. 17/487,778. The subject matter claimed in the instant application is fully disclosed in the copending Application No. 17/487,778 and is covered by the copending Application No. 17/487,778 and the application are claiming common subject matter, as follows:
Copending Application - 17/487,778
Instant Application - 17/487,208
1. (Currently Amended) A method comprising: initiating a migration of a dataset from a source storage system to a target storage system, wherein at least one of the source storage system and the target storage system is a cloud-based storage system, by mapping a volume in the target storage system to portions of data in the source storage system through metadata associated with the volume and providing a logical path to access portions of data in the source storage system; and providing, by the target storage system, read/write access to the dataset before completing migration of the dataset from the source storage system to the target storage system by using metadata associated with the volume to navigate the logical path to access the portions of data in the source storage system.
9. (Previously Presented) The method of claim 1, further comprising: migrating a portion of the dataset from the source storage system to the target storage system; and updating a mapping of the target storage system to the dataset to point to a location of the migrated portion in the target storage system.
1. (Currently Amended) A method comprising: initiating, by a storage system controller of a target storage system, a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies unmigrated data blocks of the dataset in the source storage system and migrated data blocks of the dataset in the target storage system; and during migration of the dataset from the source storage system to the target storage system, updating the metadata representation of the volume to include a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system, and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.
6. (Previously Presented) The method of claim 1, wherein the volume is created in response to a request to migrate the dataset from the source storage system to the target storage system.
3. (Previously Presented) The method of claim 1, wherein the volume is created in response to a request to migrate the dataset from the source storage system to the target storage system.
7. (Original) The method of claim 1, wherein the read/write access is provided before any portion of the dataset is copied from the source storage system to the target storage system.
4. (Currently Amended) The method of claim 1, wherein data services are provided before a portion of the dataset is copied from the source storage system to the target storage system.
8. (Previously Presented) The method of claim 1, further comprising: providing, by the target storage system, data services for the dataset before completing migration of the dataset from the source storage system to the target storage system, wherein the data services include at least one of snapshotting, cloning, data reduction, virtual copy, or replication.
5. (Currently Amended) The method of claim 1, wherein data services are provided during migration including at least one of snapshotting, cloning, data reduction, virtual copy, and replication.
9. (Previously Presented) The method of claim 1, further comprising: migrating a portion of the dataset from the source storage system to the target storage system; and updating a mapping of the target storage system to the dataset to point to a location of the migrated portion in the target storage system.
6. (Previously Presented) The method of claim 1, further comprising: migrating a portion of the dataset from the source storage system to the target storage system; and updating a mapping of the target storage system to the dataset to point to a storage location of the migrated portion in the target storage system.
10. (Original) The method of claim 6, wherein the dataset is copied from the source storage system to the target storage system without participation by a host.
7. (Original) The method of claim 1, wherein the dataset is copied from the source storage system to the target storage system without participation by a host.
11. (Original) The method of claim 6, wherein the dataset is encrypted, and wherein the target storage system includes one or more encryption keys for reading the dataset.
8. (Original) The method of claim 1, wherein the dataset is encrypted, and wherein the target storage system includes one or more encryption keys for reading the dataset.
12. (Previously Presented) The method of claim 1, further comprising: receiving, by the target storage system from a host, a request directed at least in part to an unmigrated portion of the dataset; and servicing, by the target storage system, the request.
9. (Previously Presented) The method of claim 1, further comprising: receiving, from a host, a request directed to an unmigrated portion of the dataset; and servicing, the request using the first set of metadata objects.
13. (Original) The method of claim 9, wherein an update to the dataset is propagated to the source storage system.
10. (Original) The method of claim 1, wherein an update to the dataset is propagated to the source storage system.
14. (Original) The method of claim 9, wherein an update to the dataset is not propagated to the source storage system.
11. (Original) The method of claim 1, wherein an update to the dataset is not propagated to the source storage system.
12. (Original) The method of claim 1, further comprising: replicating migrated portions of the dataset to a cloud-based storage system.
13. (Original) The method of claim 1, wherein the target storage system and the source storage system are collocated, and wherein one of the target storage system or the source storage system is an on-premises storage system that implements a cloud infrastructure.
1. (Currently Amended) A method comprising: initiating a migration of a dataset from a source storage system to a target storage system, wherein at least one of the source storage system and the target storage system is a cloud-based storage system, by mapping a volume in the target storage system to portions of data in the source storage system through metadata associated with the volume and providing a logical path to access portions of data in the source storage system; and providing, by the target storage system, read/write access to the dataset before completing migration of the dataset from the source storage system to the target storage system by using metadata associated with the volume to navigate the logical path to access the portions of data in the source storage system.
9. (Previously Presented) The method of claim 1, further comprising: migrating a portion of the dataset from the source storage system to the target storage system; and updating a mapping of the target storage system to the dataset to point to a location of the migrated portion in the target storage system.
14. (Currently Amended) An apparatus comprising: a memory; and a storage system controller of a target storage system, operatively coupled to the memory, configured to: initiate a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies data objects in the source storage system; and during migration of the dataset from the source storage system to the target storage system, update the metadata representation of the volume to include a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system, and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.
19. (Original) The apparatus of claim 16, wherein the read/write access is provided before any portion of the dataset is copied from the source storage system to the target storage system.
16. (Currently Amended) The apparatus of claim 14, wherein data services are provided before a portion of the dataset is copied from the source storage system to the target storage system.
8. (Previously Presented) The method of claim 1, further comprising: providing, by the target storage system, data services for the dataset before completing migration of the dataset from the source storage system to the target storage system, wherein the data services include at least one of snapshotting, cloning, data reduction, virtual copy, or replication.
17. (Currently Amended) The apparatus of claim 14, wherein data services are provided during migration include one or more features including at least one of snapshotting, cloning, data reduction, virtual copy, or replication.
9. (Previously Presented) The method of claim 1, further comprising: migrating a portion of the dataset from the source storage system to the target storage system; and updating a mapping of the target storage system to the dataset to point to a location of the migrated portion in the target storage system.
18. (Previously Presented) The apparatus of claim 14, the storage system controller further configured to: migrate a portion of the dataset from the source storage system to the target storage system; and update a mapping of the target storage system to the dataset to point to a location of the migrated portion in the target storage system.
12. (Previously Presented) The method of claim 1, further comprising: receiving, by the target storage system from a host, a request directed at least in part to an unmigrated portion of the dataset; and servicing, by the target storage system, the request.
19. (Previously Presented) The apparatus of claim 14, the storage system controller further configured to: receive, from a host, a request directed to an unmigrated portion of the dataset; and service the request using the first set of metadata objects.
1. (Currently Amended) A method comprising: initiating a migration of a dataset from a source storage system to a target storage system, wherein at least one of the source storage system and the target storage system is a cloud-based storage system, by mapping a volume in the target storage system to portions of data in the source storage system through metadata associated with the volume and providing a logical path to access portions of data in the source storage system; and providing, by the target storage system, read/write access to the dataset before completing migration of the dataset from the source storage system to the target storage system by using metadata associated with the volume to navigate the logical path to access the portions of data in the source storage system.
9. (Previously Presented) The method of claim 1, further comprising: migrating a portion of the dataset from the source storage system to the target storage system; and updating a mapping of the target storage system to the dataset to point to a location of the migrated portion in the target storage system.
20. (Currently Amended) A non-transitory computer readable storage medium storing instructions, which when executed, cause a storage system controller to: initiate, by the storage system controller of a target storage system, a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies data objects in the source storage system; and during migration of the dataset from the source storage system to the target storage system, update the metadata representation of the volume to include a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system, and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.
1. (Currently Amended) A method comprising: initiating a migration of a dataset from a source storage system to a target storage system, wherein at least one of the source storage system and the target storage system is a cloud-based storage system, by mapping a volume in the target storage system to portions of data in the source storage system through metadata associated with the volume and providing a logical path to access portions of data in the source storage system; and providing, by the target storage system, read/write access to the dataset before completing migration of the dataset from the source storage system to the target storage system by using metadata associated with the volume to navigate the logical path to access the portions of data in the source storage system.
9. (Previously Presented) The method of claim 1, further comprising: migrating a portion of the dataset from the source storage system to the target storage system; and updating a mapping of the target storage system to the dataset to point to a location of the migrated portion in the target storage system.
21. (New) The method of claim 1, wherein the metadata representation for the volume refers to unmigrated data blocks of the dataset in the source storage system and to migrated data blocks of the dataset in the target storage system.
Noted, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims 1, 5-14, 16, and 19-20 of the copending Application No. 17/487,778 to arrive at the claims 1, 3-11, 14, and 16-21 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
The remaining claims are rejected for fully incorporating the deficiencies of the base claim(s) from which they depend. This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 103
5. 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 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.
6. Claims 1, 14 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Butterworth et al. (previously presented) (US 2016/0092119 A1) hereinafter Butterworth, in view of Sawhney et al. (US 2018/0121129 A1) hereinafter Sawhney.
As to claim 1, Butterworth discloses a method comprising: initiating, by a storage system controller of a target storage system, a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies unmigrated data blocks of the dataset in the source storage system and migrated data blocks of the dataset in the target storage system (Fig. 8-9, Para. 79, the progress of data migration may further be recorded so as to learn which data blocks in source storage system 410 have been migrated, which ones are being migrated and which ones have not been migrated. Specifically, in one embodiment of the present invention, the migrating data blocks in the source storage system to the target storage system via the virtual file system, i.e., a metadata representation, comprises: with respect to data blocks in the source storage system, on the basis of the progress of copying the data blocks from the source storage system to the target storage system, setting metadata that describes migration status of the data blocks, the metadata comprising at least one of "unmigrated," "under migration" and "migrated". Para. 61, “a virtual file system for reading data blocks in the source storage system may be built. Specifically, in this embodiment, virtual file system 526 is built in a target storage system 520 to directly read data blocks from source storage system 410, rather than data being delivered via a third-party migration controller.”. Para. 69, “In the virtual file system, each file/folder has it unique virtual path. The virtual file system achieves a mapping relationship from actual storage locations of files/folders to virtual paths, so that the target storage system may read data blocks in the source storage system.”. Thus, initiating, by a storage system controller of a target storage system, a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies unmigrated data blocks of the dataset in the source storage system and migrated data blocks of the dataset in the target storage system.).
Butterworth does not explicitly disclose during migration of the dataset from the source storage system to the target storage system, updating the metadata representation of the volume to include a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system, and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.
However, in the same field of endeavor, Sawhney discloses during migration of the dataset from the source storage system to the target storage system, updating the metadata representation of the volume to include a first set of metadata objects (Para. 25; 42; 74) that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system (Para. 79, a single logical object pointer may be mapped to a particular volume identifier and offset. The layout representation, i.e., the metadata representation, may be used to determine the underlying physical storage location for the offset. Para. 26, logical object pointer is maintained within a metadata tier of a storage system. A logical object pointer in this context points to a logical storage location of an object rather than a physical storage location. In the event that the data object is migrated from a source, i.e., the source storage system, to a destination storage component, i.e., the target storage system, the logical object pointer may remain unchanged. Before migration, the logical storage location is mapped to a physical storage location in the source storage component. During migration, the logical object pointer may be mapped to both a physical storage location in the source storage component and a physical storage location in the destination storage component. After migration is complete, the logical object pointer is mapped to the physical storage location in the destination storage component. Para. 44, metadata records 132a-k each include a respective logical object pointer (logical object pointers 138a-k), i.e., a first set of logical addresses. A logical object pointer in this context identifies a logical storage location within data tier 120 where a corresponding object record is stored. For instance, logical object pointer 138a identifiers a logical storage location for object record 124, and logical object pointer 138k points to object record 126. Thus, a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system.), and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system (Fig. 4, Para. 70, “A unique identifier assigned to a version of an object may be used by any tier within storage system 100 to interface with storage pools 122a-j and access the corresponding object data. For example, front-end tier 110 may use logical object pointer 138a to read, write, or otherwise access object record 124. Metadata tier 130 may also use logical object pointer 138a to interface with storage pool 122a and access object record 124.”. Para. 118, “During a read operation, transaction services 112 determines the layout representation of the selected storage components or set of storage components (Operation 414). For example, if the destination layout is selected, then transaction services 112 may read layout table 328 to determine that layout "L2" is mapped to cartridges "C1" and "C10" within tape library "TL1". If the source layout is selected, then transaction services 112 may determine, from layout table 328, that layout "L1" is mapped to extent "E1" on HDD storage server "SS1", extent "E4" on storage server "SS2", and extent "E9" on storage server "SS5".”. Para. 119, “Based on the layout representation, transaction services 112 performs a read of the data object from the selected storage component (Operation 416). For example, transaction services 112 may transmit a request to a physical storage device, such as a HDD server or tape library, to retrieve volume data from a physical storage location identified by the layout representation. In response to receiving the data from the physical storage component, transaction services 112 may then return the object data to the requesting client.”. Thus, access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Butterworth by using the layout representation such as the metadata representation to determine the physical storage location of the data object by mapping the logical object pointer to the physical storage location in the source storage component and the physical storage location in the destination storage component as disclosed by Sawhney (Para. 26). Before migration, the logical storage location is mapped to a physical storage location in the source storage component. During migration, the logical object pointer may be mapped to both a physical storage location in the source storage component and a physical storage location in the destination storage component. After migration is complete, the logical object pointer is mapped to the physical storage location in the destination storage component (Sawhney, Para. 26). One of the ordinary skills in the art would have motivated to make this modification in order to ensure migration can be achieved with minimal or no updates to the logical pointer stored within the metadata tier which reduced the processing load on metadata tier as suggested by Sawhney (Para. 26; 46).
As to claim 14, Butterworth discloses an apparatus comprising: a memory; and a storage system controller of a target storage system, operatively coupled to the memory (Para. 44-45), configured to: initiate a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies data obiects in the source storage system (Fig. 8-9, Para. 79, the progress of data migration may further be recorded so as to learn which data blocks in source storage system 410 have been migrated, which ones are being migrated and which ones have not been migrated. Specifically, in one embodiment of the present invention, the migrating data blocks in the source storage system to the target storage system via the virtual file system, i.e., a metadata representation, comprises: with respect to data blocks in the source storage system, on the basis of the progress of copying the data blocks from the source storage system to the target storage system, setting metadata that describes migration status of the data blocks, the metadata comprising at least one of "unmigrated," "under migration" and "migrated". Para. 61, “a virtual file system for reading data blocks in the source storage system may be built. Specifically, in this embodiment, virtual file system 526 is built in a target storage system 520 to directly read data blocks from source storage system 410, rather than data being delivered via a third-party migration controller.”. Para. 69, “In the virtual file system, each file/folder has it unique virtual path. The virtual file system achieves a mapping relationship from actual storage locations of files/folders to virtual paths, so that the target storage system may read data blocks in the source storage system.”. Thus, initiate, by a storage system controller of a target storage system, a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies data obiects in the source storage system.).
Butterworth does not explicitly disclose during migration of the dataset from the source storage system to the target storage system, update the metadata representation of the volume to include a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system, and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.
However, in the same field of endeavor, Sawhney discloses during migration of the dataset from the source storage system to the target storage system, update the metadata representation of the volume to include a first set of metadata objects (Para. 25; 42; 74) that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system (Para. 79, a single logical object pointer may be mapped to a particular volume identifier and offset. The layout representation, i.e., the metadata representation, may be used to determine the underlying physical storage location for the offset. Para. 26, logical object pointer is maintained within a metadata tier of a storage system. A logical object pointer in this context points to a logical storage location of an object rather than a physical storage location. In the event that the data object is migrated from a source, i.e., the source storage system, to a destination storage component, i.e., the target storage system, the logical object pointer may remain unchanged. Before migration, the logical storage location is mapped to a physical storage location in the source storage component. During migration, the logical object pointer may be mapped to both a physical storage location in the source storage component and a physical storage location in the destination storage component. After migration is complete, the logical object pointer is mapped to the physical storage location in the destination storage component. Para. 44, metadata records 132a-k each include a respective logical object pointer (logical object pointers 138a-k), i.e., a first set of logical addresses. A logical object pointer in this context identifies a logical storage location within data tier 120 where a corresponding object record is stored. For instance, logical object pointer 138a identifiers a logical storage location for object record 124, and logical object pointer 138k points to object record 126. Thus, a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system.), and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system (Fig. 4, Para. 70, “A unique identifier assigned to a version of an object may be used by any tier within storage system 100 to interface with storage pools 122a-j and access the corresponding object data. For example, front-end tier 110 may use logical object pointer 138a to read, write, or otherwise access object record 124. Metadata tier 130 may also use logical object pointer 138a to interface with storage pool 122a and access object record 124.”. Para. 118, “During a read operation, transaction services 112 determines the layout representation of the selected storage components or set of storage components (Operation 414). For example, if the destination layout is selected, then transaction services 112 may read layout table 328 to determine that layout "L2" is mapped to cartridges "C1" and "C10" within tape library "TL1". If the source layout is selected, then transaction services 112 may determine, from layout table 328, that layout "L1" is mapped to extent "E1" on HDD storage server "SS1", extent "E4" on storage server "SS2", and extent "E9" on storage server "SS5".”. Para. 119, “Based on the layout representation, transaction services 112 performs a read of the data object from the selected storage component (Operation 416). For example, transaction services 112 may transmit a request to a physical storage device, such as a HDD server or tape library, to retrieve volume data from a physical storage location identified by the layout representation. In response to receiving the data from the physical storage component, transaction services 112 may then return the object data to the requesting client.”. Thus, access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Butterworth by using the layout representation such as the metadata representation to determine the physical storage location of the data object by mapping the logical object pointer to the physical storage location in the source storage component and the physical storage location in the destination storage component as disclosed by Sawhney (Para. 26). Before migration, the logical storage location is mapped to a physical storage location in the source storage component. During migration, the logical object pointer may be mapped to both a physical storage location in the source storage component and a physical storage location in the destination storage component. After migration is complete, the logical object pointer is mapped to the physical storage location in the destination storage component (Sawhney, Para. 26). One of the ordinary skills in the art would have motivated to make this modification in order to ensure migration can be achieved with minimal or no updates to the logical pointer stored within the metadata tier which reduced the processing load on metadata tier as suggested by Sawhney (Para. 26; 46).
As to claim 20, Butterworth discloses a non-transitory computer readable storage medium storing instructions, which when executed (Para. 44-45), cause a storage system controller to: initiate, by the storage system controller of a target storage system, a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies data objects in the source storage system (Fig. 8-9, Para. 79, the progress of data migration may further be recorded so as to learn which data blocks in source storage system 410 have been migrated, which ones are being migrated and which ones have not been migrated. Specifically, in one embodiment of the present invention, the migrating data blocks in the source storage system to the target storage system via the virtual file system, i.e., a metadata representation, comprises: with respect to data blocks in the source storage system, on the basis of the progress of copying the data blocks from the source storage system to the target storage system, setting metadata that describes migration status of the data blocks, the metadata comprising at least one of "unmigrated," "under migration" and "migrated". Para. 61, “a virtual file system for reading data blocks in the source storage system may be built. Specifically, in this embodiment, virtual file system 526 is built in a target storage system 520 to directly read data blocks from source storage system 410, rather than data being delivered via a third-party migration controller.”. Para. 69, “In the virtual file system, each file/folder has it unique virtual path. The virtual file system achieves a mapping relationship from actual storage locations of files/folders to virtual paths, so that the target storage system may read data blocks in the source storage system.”. Thus, initiate, by a storage system controller of a target storage system, a migration of a dataset from a source storage system to the target storage system by mapping a volume in the target storage system to the dataset stored in the source storage system using a metadata representation that identifies data objects in the source storage system.).
Butterworth does not explicitly disclose during migration of the dataset from the source storage system to the target storage system, update the metadata representation of the volume to include a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system, and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.
However, in the same field of endeavor, Sawhney discloses during migration of the dataset from the source storage system to the target storage system, update the metadata representation of the volume to include a first set of metadata objects (Para. 25; 42; 74) that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system (Para. 79, a single logical object pointer may be mapped to a particular volume identifier and offset. The layout representation, i.e., the metadata representation, may be used to determine the underlying physical storage location for the offset. Para. 26, logical object pointer is maintained within a metadata tier of a storage system. A logical object pointer in this context points to a logical storage location of an object rather than a physical storage location. In the event that the data object is migrated from a source, i.e., the source storage system, to a destination storage component, i.e., the target storage system, the logical object pointer may remain unchanged. Before migration, the logical storage location is mapped to a physical storage location in the source storage component. During migration, the logical object pointer may be mapped to both a physical storage location in the source storage component and a physical storage location in the destination storage component. After migration is complete, the logical object pointer is mapped to the physical storage location in the destination storage component. Para. 44, metadata records 132a-k each include a respective logical object pointer (logical object pointers 138a-k), i.e., a first set of logical addresses. A logical object pointer in this context identifies a logical storage location within data tier 120 where a corresponding object record is stored. For instance, logical object pointer 138a identifiers a logical storage location for object record 124, and logical object pointer 138k points to object record 126. Thus, a first set of metadata objects that map a first set of logical addresses to a first set of storage locations in the source storage system and a second set of metadata objects that map a second set of logical addresses to a second set of storage locations in the target storage system.), and access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system (Fig. 4, Para. 70, “A unique identifier assigned to a version of an object may be used by any tier within storage system 100 to interface with storage pools 122a-j and access the corresponding object data. For example, front-end tier 110 may use logical object pointer 138a to read, write, or otherwise access object record 124. Metadata tier 130 may also use logical object pointer 138a to interface with storage pool 122a and access object record 124.”. Para. 118, “During a read operation, transaction services 112 determines the layout representation of the selected storage components or set of storage components (Operation 414). For example, if the destination layout is selected, then transaction services 112 may read layout table 328 to determine that layout "L2" is mapped to cartridges "C1" and "C10" within tape library "TL1". If the source layout is selected, then transaction services 112 may determine, from layout table 328, that layout "L1" is mapped to extent "E1" on HDD storage server "SS1", extent "E4" on storage server "SS2", and extent "E9" on storage server "SS5".”. Para. 119, “Based on the layout representation, transaction services 112 performs a read of the data object from the selected storage component (Operation 416). For example, transaction services 112 may transmit a request to a physical storage device, such as a HDD server or tape library, to retrieve volume data from a physical storage location identified by the layout representation. In response to receiving the data from the physical storage component, transaction services 112 may then return the object data to the requesting client.”. Thus, access requests for portions of the dataset are serviced using the first set of metadata objects to access unmigrated portions of the dataset on the source storage system and the second set of metadata objects to access migrated portions of the dataset on the target storage system.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Butterworth by using the layout representation such as the metadata representation to determine the physical storage location of the data object by mapping the logical object pointer to the physical storage location in the source storage component and the physical storage location in the destination storage component as disclosed by Sawhney (Para. 26). Before migration, the logical storage location is mapped to a physical storage location in the source storage component. During migration, the logical object pointer may be mapped to both a physical storage location in the source storage component and a physical storage location in the destination storage component. After migration is complete, the logical object pointer is mapped to the physical storage location in the destination storage component (Sawhney, Para. 26). One of the ordinary skills in the art would have motivated to make this modification in order to ensure migration can be achieved with minimal or no updates to the logical pointer stored within the metadata tier which reduced the processing load on metadata tier as suggested by Sawhney (Para. 26; 46).
As to claim 21, the claim is rejected for the same reasons as claim 1 above. In addition, Butterworth discloses wherein the metadata representation for the volume refers to unmigrated data blocks of the dataset in the source storage system and to migrated data blocks of the dataset in the target storage system (Fig. 8-9, Para. 79, “the progress of data migration may further be recorded so as to learn which data blocks in source storage system 410 have been migrated, which ones are being migrated and which ones have not been migrated. Specifically, in one embodiment of the present invention, the migrating data blocks in the source storage system to the target storage system via the virtual file system comprises: with respect to data blocks in the source storage system, on the basis of the progress of copying the data blocks from the source storage system to the target storage system, setting metadata that describes migration status of the data blocks, the metadata comprising at least one of "unmigrated," "under migration" and "migrated."”. Thus, the metadata representation for the volume refers to unmigrated data blocks of the dataset in the source storage system and to migrated data blocks of the dataset in the target storage system.).
7. Claims 4-5, 9, 11, 13, 16-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Butterworth and Sawhney as applied above, and further in view of ZHAO et al. (previously presented) (US 2016/0269488 A1) hereinafter ZHAO.
As to claims 4 and 16, the claims are rejected for the same reasons as claims 1 and 14 above. Combination of Butterworth and Sawhney do not explicitly disclose wherein data services are provided before a portion of the dataset is copied from the source storage system to the target storage system.
However, in the same field of endeavor, ZHAO discloses wherein data services are provided before any portion of the dataset is copied from the source storage system to the target storage system (Para. 61, The target device 104 can be an offsite device, such as a device that is included in, or associated with, an external computing environment. For example, the target device 104 can be maintained by a commercial data source that is configured to provide various services and/or applications, i.e. data services are provided, by application of a cloud computing environment. Para. 64, When a decision is made to transfer data from the source device 102 to the target device 104, a link 112 is established between the source device 102 and the target device 104. For example, an operator (e.g., information technology personnel or someone with the proper authority) of the enterprise can contract with a third party entity, wherein the third party entity provides the cloud computing services, i.e. data services. Therefore, the target device such as the target storage system provides data services including read/write access for the dataset before completing migration of the dataset from the source storage system to the target storage system. Thus, the data services are provided before any portion of the dataset is copied from the source storage system to the target storage system.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of ZHAO into the combined method of Butterworth and Sawhney by providing the cloud computing services for transferring data from the source device to the target device as suggested by ZHAO (Para. 64). The target device may function as a client of the source device during the process of migration. The target device may keep its services running during migration and, therefore, requests from at least one client-side device may be processed (ZHAO, Para. 72). One of the ordinary skills in the art would have motivated to make this modification in order to provide a transparent and responsive data migration experience by utilizing program data that include data transfer status and location information of the data segment as suggested by ZHAO (Para. 150).
As to claims 5 and 17, the claims are rejected for the same reasons as claims 1 and 14 above. In addition, ZHAO discloses wherein data services are provided during migration including at least one of snapshotting, cloning, data reduction, virtual copy, or replication (Para. 61, The target device 104 can be an offsite device, such as a device that is included in, or associated with, an external computing environment. For example, the target device 104 can be maintained by a commercial data source that is configured to provide various services and/or applications, i.e. providing, by the storage controller on the target storage system, data services, by application of a cloud computing environment. Para. 27, “a cloud service can be replicated without shutdown and, thus, during the replication, the user will not notice the change of server. The disclosed aspects provide a one-time migration and copies data from the old system (e.g., source) to the new system (e.g., target).”. Thus, data services are provided during migration that include one or more features including at least one of snapshotting, cloning, data reduction, virtual copy, and replication.).
As to claims 9 and 19, the claims are rejected for the same reasons as claims 1 and 14 above. In addition, ZHAO discloses further comprising: receiving, from a host, a request directed to an unmigrated portion of the dataset (Para. 86, Through the session 416 established with the client device 402 and the link 420 with the host service 408, the target device 406 may function as an intermediary for the client device 402 and the host service 408. Thus, the target device 406 may receive requests from the client device 402, i.e. a host, and may process such requests, while data is being migrated from the source device 404. Para. 72, during the process of migration, the target device 304 may function as a client of the source device 302. The target device 304 may keep its services running during migration and, therefore, requests from at least one client-side device 306 may be processed. For example, if a response to the request includes data not yet migrated, i.e. an unmigrated portion of the dataset, to the target device 304, at least a portion of the requested data may be obtained from the source device 302.); and
servicing, the request using the first set of metadata objects (Para. 26, “During the process of migration, source machines may function as background devices of target machines. Further, during the data migration process, the target machines may function as clients of the source machines. For example, the target machines may keep their services running during migration and, if requested, data may be obtained from the source machines to service the client request.”. Para. 72, “during the process of migration, the target device 304 may function as a client of the source device 302. The target device 304 may keep its services running during migration and, therefore, requests from at least one client-side device 306 may be processed. For example, if a response to the request includes data not yet migrated to the target device 304, at least a portion of the requested data may be obtained from the source device 302.”. Thus, the request being serviced by the target storage system.).
As to claim 11, the claim is rejected for the same reasons as claim 1 above. In addition, ZHAO discloses wherein an update to the dataset is not propagated to the source storage system (Para. 27, “The disclosed aspects provide a one-time migration and copies data from the old system (e.g., source) to the new system (e.g., target). In such a manner, the disclosed aspects operate similar to a "do not migrate" process, however, there is no synchronization back to the old system with the aspects disclosed herein.”. Thus, an update to the dataset is not propagated to the source storage system.).
As to claim 13, the claim is rejected for the same reasons as claim 1 above. In addition, ZHAO discloses wherein the target storage system and the source storage system are collocated (Para. 60, “FIG. 1 illustrates a system 100 for data migration from a source device 102 to a target device 104 according to an example conventional system. The source device is the device from which data is to be transferred and the target device is the device to which the data is transferred.”.), and wherein one of the target storage system or the source storage system is an on-premises storage system that implements a cloud infrastructure (Para. 61, “The target device 104 can be an offsite device, such as a device that is included in, or associated with, an external computing environment. For example, the target device 104 can be maintained by a commercial data source that is configured to provide various services and/or applications by application of a cloud computing environment. Thus, the target device 104 can be controlled and maintained by a third party, wherein the data is maintained and provided in a secured configuration. As illustrated, the target device 104 can be included, at least partially in a cloud computing environment 108.”. Para. 78, “the source device 404 may contain at least some of the data, applications, and/or services that are used by the client device 402. The source device 404 may be located on-site or within the premises or control of an enterprise (e.g., company, network, and so on).”. Para. 104, “The source device may be, for example a server of an enterprise (e.g., a company). The target device may be located offsite, or "in the cloud".”. Thus, one of the target storage system and the source storage system is an on-premises storage system that implements a cloud infrastructure.).
8. Claims 3, 6-7, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Butterworth and Sawhney as applied above, and further in view of Hardy et al. (previously presented) (US 2020/0073955 A1) hereinafter Hardy.
As to claim 3, the claim is rejected for the same reasons as claim 1 above. Butterworth and Sawhney do not explicitly disclose wherein the volume is created in response to a request to migrate the dataset from the source storage system to the target storage system.
However, in the same field of endeavor, Hardy discloses wherein the volume is created in response to a request to migrate the dataset from the source storage system to the target storage system (Para. 31, “identifying a request to migrate data associated with a volume from a source storage pool to a destination storage pool. Additionally, the method includes allocating one or more rank extents within the destination storage pool. Further, the method includes populating empty volume extents of the volume with corresponding offset locations within the allocated one or more rank extents within the destination storage pool. Also, the method includes transferring the data associated with the volume from one or more rank extents within the source storage pool to one or more offset locations within the allocated one or more rank extents of the destination storage pool.”. Para. 58, “FIG. 5, method 500 may initiate with operation 502, where a request to migrate data associated with a volume from a source storage pool to a destination storage pool is identified. In one embodiment, the volume includes a storage volume that organizes and presents a logical representation of the data in a contiguous manner to one or more hosts.”. Thus, the volume is created in response to a request to migrate the dataset from the source storage system to the target storage system.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Hardy into the combined method of Butterworth and Sawhney by mapping a volume in the destination storage system to the dataset in the source storage system for migrating the dataset of Butterworth in response to a request as suggested by Hardy (Para. 84). Data is migrating from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, according to the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the destination storage pool. One of the ordinary skills in the art would have motivated to make this modification in order to reduce an amount of time and resources of one or more systems performing the data migration, which improves a performance of the one or more systems as suggested by Hardy (Para. 27).
As to claims 6 and 18, the claims are rejected for the same reasons as claims 1 and 14 above. In addition, Hardy discloses further comprising: migrating a portion of the dataset from the source storage system to the target storage system (Para. 26, “the method includes migrating data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, according to the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the destination storage pool.”.); and updating a mapping of the target storage system to the dataset to point to a storage location of the migrated portion in the target storage system (Para. 76, the previously allocated volume extent is updated to identify the offset location, i.e., updating a mapping, within the allocated rank extent of the destination storage pool where the data associated with the previously allocated volume extent was migrated. In yet another example, the stored data is migrated from the rank extent in the source storage pool to an offset location within an allocated rank extent of the destination storage pool.).
As to claim 7, the claim is rejected for the same reasons as claim 1 above. In addition, ZHAO discloses wherein the dataset is copied from the source storage system to the target storage system without participation by a host (Para. 147, during the process of migration, source machines may function as background devices of target machines. Further, during the data migration process, the target machines may function as clients of the source machines. For example, the target machines may keep their services running during migration and, if necessary, data can be obtained from the source machines to service a client request. Therefore, client devices, i.e., a host, are not aware that data migration is occurring or that data migration has occurred. Thus, the dataset is copied from the source storage system to the target storage system without participation by a host.).
9. Claims 8, 10, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Butterworth, Sawhney and Hardy as applied above, and further in view of Murali et al. (previously presented) (US 9,582,524 B1) hereinafter Muralli.
As to claim 8, the claim is rejected for the same reasons as claim 1 above. Combination of Butterworth, Sawhney and Hardy do not explicitly disclose wherein the dataset is encrypted, and wherein the target storage system includes one or more encryption keys for reading the dataset.
However, in the same field of endeavor, Murali discloses wherein the dataset is encrypted, and wherein the target storage system includes one or more encryption keys for reading the dataset (Col. 1 line 54-62, “the data may be data that is stored in an encrypted form, for example through use of a Hardware Security Module (HSM). Such embodiments may enable a rotation (e.g., change) of an encryption key or algorithm such that the original data in Table A is encrypted using a first encryption key, a first set of encryption keys, and/or a first encryption algorithm, and the migrated data in Table B is encrypted using a second encryption key, second set of encryption keys, and/or second encryption algorithm.”. Thus, the dataset is encrypted, and wherein the target storage system includes one or more encryption keys for reading the dataset.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Murali into the combined method of Butterworth, Sawhney and Hardy by including the encryption key for the dataset of ZHAO for reading the data using the provided encryption key as disclosed by Murali (Col. 1 line 55-62). The data services of Murali used in the environment of ZHAO in order to migrate data safely form source system to target system in the encrypted form. One of the ordinary skills in the art would have motivated to make this modification in order to protect sensitive data such as the financial transaction data by providing the data in the encrypted form as suggested by Murali (Col. 1 line 55-67; Col. 2 line 1-7).
As to claim 10, the claim is rejected for the same reasons as claim 1 above. In addition, Murali discloses wherein an update to the dataset is propagated to the source storage system (Col. 10 line 24-31, “After migration of the first data portion is completed, at 414 one or more other indices (e.g., other than the primary key index) may be created for the second table, in one or more regions. At 416 replication between regions may be enabled for the second table, such that changes (e.g., row inserts, deletes, and/or updates) may be propagated in the corresponding second table in one or more other regions for which replication is enabled.”. Col. 10 line 35-44, “the status table may be updated to indicate that one or more data writing processes are to write to both the first and second tables, and that one or more data reading processes are to read from the first table (but not the second table). By having writing processes write to both the first and second table, embodiments may ensure that the first table continues to store up-to-date data in case the migration fails and the system is to be rolled back (e.g., revert to using the original, unmigrated first table).”. Thus, an update to the dataset is propagated to the source storage system.).
As to claim 12, the claim is rejected for the same reasons as claim 1 above. In addition, Murali discloses further comprising: replicating migrated portions of the dataset to a cloud-based storage system (Col. 2 line 55-58, “migration may include an infrastructure transformation such as migrating data stored on a local database to storage on a cloud service.”. Col. 6 line 56-63, “cloud service 222 may host one or more of data migration server device(s) 204, data replication server device(s) 206, and/or data warehouses 208, 210, and 212. In such cases, the data migration and/or data replication services described herein may be provided to processes and/or users as a service in the cloud, via an Application Programming Interface (API) 224 or other intermediary software or hardware.”. Thus, replicating migrated portions of the dataset to a cloud-based storage system.).
10. Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Butterworth and Sawhney as applied above, and further in view of Nunez et al. (US 2012/0030424 A1) hereinafter Nunez.
As to claim 22, the claim is rejected for the same reasons as claim 1 above. Combination of Butterworth and Sawhney do not explicitly disclose wherein the storage system controller services access requests for the dataset while remaining agnostic to a migration status of the dataset by navigating the metadata representation of the volume to locate data corresponding to each access request.
However, in the same field of endeavor, Nunez discloses wherein the storage system controller services access requests for the dataset while remaining agnostic to a migration status of the dataset by navigating the metadata representation of the volume to locate data corresponding to each access request (Fig. 4, Para. 7, The computing node includes a multi-pathing module that permits the computing node to communicate data operations to the first storage system and the second storage system via a primary communication path and a secondary communication path, respectively. The computing environment further includes a migration communication path between the first storage system and the second storage system, such that the migration communication path is utilized to transparently perform data migration between the first storage system and the second storage system while the computing node is unaware of the data migration. The data migration is enabled by discovering a logical storage structure, i.e., the metadata representation of the volume, of the existing storage system and establishing the logical storage structure on the second storage system. Para. 32, when I/0 operations, such as the data read operations, are requested by the computing node 110, the data request is made via the multi-pathing module 210 to the new storage system 130, passing through a buffer 324 to the image mode volume 322. Since the data is not stored in the new storage system 322, the I/0 operation proceeds to the existing storage system 120, where the data resides. By passing- through the data read operation from the new storage system 130 to the existing storage system, the realtime data request can be fulfilled without the computing node 110 being aware of where the data actually resides. Moreover, the new storage system can be added to the computing environment in a non-disruptive process. Thus, the storage system controller services access requests for the dataset while remaining agnostic to a migration status of the dataset by navigating the metadata representation of the volume to locate data corresponding to each access request.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Nunez into the combined method of Butterworth and Sawhney by using the migration communication path between the first storage system and the second storage system, such that the migration communication path is utilized to transparently perform data migration between the first storage system and the second storage system while the computing node is unaware of the data migration as disclosed by Nunez (Para. 0007). The migration path between the existing storage system and the new storage system permits communication during the migration process of transferring data from the existing storage system to the new storage system (Nunez, Para. 27). One of the ordinary skills in the art would have motivated to make this modification in order to migrate data transparently between storage systems of a computing environment without disrupting realtime access to the stored data of the storage systems as suggested by Nunez (Para. 19).
Response to Arguments
11. Applicant’s arguments filed on 05/05/2026, with respect to claims 1, 3-14 and 16-22 have been considered but are moot because of the new ground of rejection necessitated by the amendment to the claims. For Examiner's response, see discussion below:
Applicant arguments, regarding 101 rejections, examiner withdraws the 101 rejections since applicant amended the independent claim 14.
Applicant's arguments, see pages 8-12, with respect to the rejections of claims 1, 3-14 and 16-22 under 35 USC §103 have been considered but are moot in view of the new ground(s) of rejection necessitated by applicant's amendments as set forth in the respective rejections of claims 1, 3-14 and 16-22 under 35 USC §103 above in view of the newly found references.
Conclusion
12. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Colbert et al. (US 2009/0037680 A1) teaches online virtual machine disk migration.
13. 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 extension fee 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 MOHAMMAD SOLAIMAN BHUYAN whose telephone number is (571)272-7843. The examiner can normally be reached on Monday - Friday 9:00am-5:00pm EST.
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, 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.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published 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. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohammad S Bhuyan/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
Prosecution Insights