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 .
Status of Claims
Claims 1-20 are pending of which claims 1, 9, 16 and 20 are in independent form.
Claim 20 is objected to.
Claims 1-19 are rejected under 35 U.S.C. 103.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding 35 USC 112(f)/sixth paragraph (claim interpretation) and 35 USC 101 (abstract idea):
Applicant’s arguments/amendments, filed on 5/29/2026, with respect to 1-20 have been fully considered and are persuasive. Therefore, 35 USC 112(f)/sixth paragraph (claim interpretation) and 35 USC 101 (abstract idea), have been withdrawn.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent 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.
Claim(s) 1-3, 9, 10, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kashi Visvanathan; Satish Kumar et al. (US 20240086417 A1) [Kashi] in view of Hankins; Richard A. et al. (US 20200401316 A1) [Hankins] in view of Igelka; Or et al. (US 20230315515 A1) [Igelka].
Regarding claims 1 and 9, Kashi discloses, a computer-implement system for migrating data from a first object storage service to a second object storage service (computer implemented system for performing cross-region replication of data between a source (primary) file system and target (secondary) file system in a could infrastructure ¶ [0002], [0004], [0050], [0091]), the system comprising: at least one computing device having a processor (see Fig. 21, and ¶ [0218], [0229], [0245]);
a management module operating on the processor configured to receive a migration request from a user (a computer system implementing resource management and task management that receives and enqueues replication job in a job queue ¶ [005], [0044], [0046], the replication job corresponds to migration request) and identify migration parameters based on data metrics collected from the first object storage service and the second object storage service (identifying parameters associated with replication jobs, including priority, weights, processing capacity, and throughput requirement ¶ [0010], [0209], [0225], [0237]. Examiner further specifies that, these parameters are used to determine how replication jobs are selected and processed, and therefore corresponds to migration of parameters based on data related metrics); and
a plurality of engines configured to receive tasks from the management module (a plurality of replicators (replicator fleet) that operate to process replication jobs ¶ [0046], [0225], [0217]. Examiner specifies that the replicators obtain jobs from a job queue maintained by the management system, thereby receiving tasks from the management module) and migrate data from the first object storage service to the second object storage service (performing cross region replication in which data is transferred from a source file system to a target file system ¶ [0002], [0050] and [0091]);
and deploy the plurality of engines based on the migration parameters (FIG. 13 is a simplified diagram of a distributed environment illustrating techniques for replication-aware resource and task management in a cloud infrastructure for cross-region replication, according to certain embodiments ¶ [0033]-[0036], [0044]; At step 1422, replication jobs are selected from the job queue for execution. For example, each replicator in the replicator fleet 1320 may select a replication job from the job queue 1314 based on the set of information, including the requested processing capacity and parameters, associated with the particular job and processing capacity each replicator has. For example, a replicator has 8 threads processing capacity. When the replicator checks the parameters of a first job in the job queue, which requires a total throughput of 10 threads, the replicator may skip the first job and continue to check the second job in the queue until the replicator finds a job with the requested total throughput within its processing capacity ¶ [0225], [0237]. Also see ¶ [0005], [0010], [0194], [0202], [0212], [0217]-[0218], [0235]);
wherein each engine is configured to independently list objects stored in the first object storage service (In some embodiments, before a replicator in a fleet picks up a replication job, the replicator may scan all jobs in the job queue (e.g., 1314) to check their priority and weightage, calculate the aggregated throughput requirement based on parameters of each job, and then determine if the replicator is capable of handling the job. Further details about the job selection are described below in FIGS. 14 and 15 and the accompanying description ¶ [0212], [0217], [0225], [0227]; these sections teach replications operating independently);
without requiring inter-engine communication during migration (In certain embodiments, all replicators in the fleet 1320 may run independently, in parallel, and concurrently. Replicators may not communicate with each other. However, each replicator in the fleet may follow certain configurations by checking and reading a configuration file, sending reports (e.g., performance metrics) to the central monitor service 1322 for monitoring, and be independently scaled while sharing the processing thread pool 1324 with other replicators. Such replicator fleet architecture does not need a central manager to actively track resource allocation needs for each replicator, the number of jobs being executed, etc. Instead, the monitoring service responds to each replicator in the fleet independently, while having the full picture of the fleet and maintaining available resources. Thus, such architecture can avoid unnecessary communication traffic among replicators, and is more fault tolerant and highly scalable ¶ [0217]; also see ¶ [0045], [0049], [0070])
However, Kashi does not explicitly facilitate wherein the management module is further configured to determine a number of migration slots; assign a unique migration slot identifier to each engine of the plurality of engines.
Igelka discloses, wherein the management module is further configured to determine a number of migration slots (For instance, if the migration system 100 can only migrate ten virtual machines in parallel out of one hundred virtual machines total, then if a cut-over operation is requested for twenty virtual machines at once, the ten slots available to the migration system 100 will be used first for twenty cut-over cycles, before performing other types of migration cycles ¶ [0079]; In one example, in migrating a group of virtual machines, some virtual machines may have multiple disks. The migration system 100 may have a limited amount of disk slots for handling disk migrations. The migration system can implement a load-balancing scheme, in addition to a schedule generated, for example, based on constraints, assigned weights, priorities, available computing resources, etc. ¶ [0098]; also see ¶ [0054], [0085], [0103], [0106], [0109]);
assign a unique migration slot identifier to each engine of the plurality of engines (The migration system 100 can identify groups of interdependent virtual machines, for example virtual machines 135C of data center 125 implementing a service 145 ¶ [0040]. FIG. 4 is a block diagram showing the migration system 100 load-balancing and scaling computing resources, according to aspects of the disclosure. In FIG. 4, the migration system 100 includes two processor virtual machines 415A, 415B with corresponding disk slots 420A, 420B ¶ [0103], [0106]. Also see ¶ [0092], [0112]-[0113]).
It would have been obvious to one ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Igelka’s system would have allowed Kashi to facilitate wherein the management module is further configured to determine a number of migration slots; assign a unique migration slot identifier to each engine of the plurality of engines. The motivation to combine is apparent in Kashi’s reference, because there is a need to improve ordering and scheduling operations for migrating virtual machines in parallel.
However, Kashi does not explicitly facilitate calculate, for each listed object, a hash value of an object key; determine whether the object belongs to the assigned migration slot based on a modulo operation using the hash value and the number of migration slots; and migrate only objects assigned to the migration slot from the first object storage service to the second object storage service; wherein migration objects are distributed across the plurality of engines on a pseudo- random basis.
Hankins discloses, calculate, for each listed object, a hash value of an object key (One of the goals of object mapping 416 is to be able to use the same object identifier to find an object 410 in the source storage array 402, or find the replicated object 410 in the target storage array 404. To do so, the object mapping 416 uses a deterministic statistically evenly distributed mapping function, e.g., a hash functionon the object identifier, which may also be referred to as a translation of the identifier, as described below. The transformation or translation operates in a statistically evenly distributed manner, so that the transformation or translation is repeatable or reproducible for any object identifier, which the object retains in both systems ¶ [0205]-[0207], [0210]-[0211], [0215], [0220]-[0221]. Also see ¶ [0168], [0199]-[0200]);
determine whether the object belongs to the assigned migration slot based on a modulo operation using the hash value and the number of migration slots ( In order to maintain consistency across multiple copies of an entity, the storage nodes agree implicitly on two things through calculations: (1) the authority that contains the entity, and (2) the storage node that contains the authority. The assignment of entities to authorities can be done by pseudo randomly assigning entities to authorities, by splitting entities into ranges based upon an externally produced key, or by placing a single entity into each authority. Examples of pseudorandom schemes are linear hashing and the Replication Under Scalable Hashing (‘RUSH’) family of hashes, including Controlled Replication Under Scalable Hashing (‘CRUSH’). In some embodiments, pseudo-random assignment is utilized only for assigning authorities to nodes because the set of nodes can change. The set of authorities cannot change so any subjective function may be applied in these embodiments. Some placement schemes automatically place authorities on storage nodes, while other placement schemes rely on an explicit mapping of authorities to storage nodes. In some embodiments, a pseudorandom scheme is utilized to map from each authority to a set of candidate authority owners. A pseudorandom data distribution function related to CRUSH may assign authorities to storage nodes and create a list of where the authorities are assigned. Each storage node has a copy of the pseudorandom data distribution function, and can arrive at the same calculation for distributing, and later finding or locating an authority. Each of the pseudorandom schemes requires the reachable set of storage nodes as input in some embodiments in order to conclude the same target nodes. Once an entity has been placed in an authority, the entity may be stored on physical devices so that no expected failure will lead to unexpected data loss. In some embodiments, rebalancing algorithms attempt to store the copies of all entities within an authority in the same layout and on the same set of machines ¶ [0085]; A network attached storage, storage area network, or a storage cluster, or other storage memory, could include one or more storage clusters 161, each having one or more storage nodes 150, in a flexible and reconfigurable arrangement of both the physical components and the amount of storage memory provided thereby. The storage cluster 161 is designed to fit in a rack, and one or more racks can be set up and populated as desired for the storage memory. The storage cluster 161 has a chassis 138 having multiple slots 142. It should be appreciated that chassis 138 may be referred to as a housing, enclosure, or rack unit. In one embodiment, the chassis 138 has fourteen slots 142, although other numbers of slots are readily devised. For example, some embodiments have four slots, eight slots, sixteen slots, thirty-two slots, or other suitable number of slots. Each slot 142 can accommodate one storage node 150 in some embodiments. Chassis 138 includes flaps 148 that can be utilized to mount the chassis 138 on a rack. Fans 144 provide air circulation for cooling of the storage nodes 150 and components thereof, although other cooling components could be used, or an embodiment could be devised without cooling components. A switch fabric 146 couples storage nodes 150 within chassis 138 together and to a network for communication to the memory. In an embodiment depicted in herein, the slots 142 to the left of the switch fabric 146 and fans 144 are shown occupied by storage nodes 150, while the slots 142 to the right of the switch fabric 146 and fans 144 are empty and available for insertion of storage node 150 for illustrative purposes. This configuration is one example, and one or more storage nodes 150 could occupy the slots 142 in various further arrangements. The storage node arrangements need not be sequential or adjacent in some embodiments. Storage nodes 150 are hot pluggable, meaning that a storage node 150 can be inserted into a slot 142 in the chassis 138, or removed from a slot 142, without stopping or powering down the system. Upon insertion or removal of storage node 150 from slot 142, the system automatically reconfigures in order to recognize and adapt to the change. Reconfiguration, in some embodiments, includes restoring redundancy and/or rebalancing data or load ¶ [0074]; also see ¶ [0079], [0205]-[0207], [0210]-[0215]-[0216], [0220]-[0221], these section clearly teaches hash based/pseudorandom mapping of an object identifier into one of multiple destinations/partitions, including module based distribution);
and migrate only objects assigned to the migration slot from the first object storage service to the second object storage service (One of the goals of object mapping 416 is to be able to use the same object identifier to find an object 410 in the source storage array 402, or find the replicated object 410 in the target storage array 404. To do so, the object mapping 416 uses a deterministic statistically evenly distributed mapping function, e.g., a hash functionon the object identifier, which may also be referred to as a translation of the identifier, as described below. The transformation or translation operates in a statistically evenly distributed manner, so that the transformation or translation is repeatable or reproducible for any object identifier, which the object retains in both systems ¶ [0205]-[0207], [0220]-[0221]; these sections teach mapping replicated object according to the hash-derived destination/partition and then sends the replicated data to the second storage system according to that mapping);
wherein migration objects are distributed across the plurality of engines on a pseudo- random basis (In order to maintain consistency across multiple copies of an entity, the storage nodes agree implicitly on two things through calculations: (1) the authority that contains the entity, and (2) the storage node that contains the authority. The assignment of entities to authorities can be done by pseudo randomly assigning entities to authorities, by splitting entities into ranges based upon an externally produced key, or by placing a single entity into each authority. Examples of pseudorandom schemes are linear hashing and the Replication Under Scalable Hashing (‘RUSH’) family of hashes, including Controlled Replication Under Scalable Hashing (‘CRUSH’). In some embodiments, pseudo-random assignment is utilized only for assigning authorities to nodes because the set of nodes can change ¶ [0085]; also see ¶ [0018]-[0020] [0079], [0199]-[0202], [0205]-[0207], [0210]-[0211], [0215]);
It would have been obvious to one ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Hankins’ system would have allowed Kashi and Igelka to facilitate calculate, for each listed object, a hash value of an object key; determine whether the object belongs to the assigned migration slot based on a modulo operation using the hash value and the number of migration slots; and migrate only objects assigned to the migration slot from the first object storage service to the second object storage service; wherein migration objects are distributed across the plurality of engines on a pseudo- random basis. The motivation to combine is apparent in Kashi and Igelka’s reference, because there is a need to improve distributions of objects, portions of objects or shards of objects in the target storage array relative to the number of partitions, creating processing or data bandwidth bottlenecks or storage imbalance.
Regarding claims 2 and 15, the combination of Kashi, Hankins and Igelka discloses, wherein the first object storage service and/or the second object storage service are cloud-native object storage services (Kashi: cloud infrastructure… cross-region replication [Abstract], ¶ [0002], [0004], [0033], [0034], [0043], [0044], [0050]. Object storage ¶ [0091]).
Regarding claim 3 and 10, the combination of Kashi, Hankins and Igelka discloses, wherein the management module comprises: a migration manger that creates the tasks in tasks manger and is configured to deploy the plurality of engines via an engine deployer based on the migration parameters (Kashi: system enqueues/queuing replication jobs (task intake) ¶ [0005], [0045], [0046], [0211]; resource management and task management ¶ [0044], [0046]; jobs selected and processed based on parameters ¶ [0225], [0237]; replicator fleet dynamically operates and scales ¶ [0217]);
the migration parameters comprise at least one of a source storage region, a destination storage region, a total number of objects, a total size of objects, a number of migration streams, and a number of migration slots (Kashi: identifying parameters associated with replication jobs, including priority, weights, processing capacity, and throughput requirement ¶ [0010], [0209], [0225], [0237]. Examiner further specifies that, these parameters are used to determine how replication jobs are selected and processed, and therefore corresponds to migration of parameters based on data related metrics);
a report processor configured to receive the migration status reports from the plurality of engines and provide status reports to the task manager (Kashi: performance monitoring and reporting ¶ [0047], [0048], [0214], [0217]); and
a task describer configured to retrieve tasks requests from the plurality of engines, identify tasks parameters via the tasks manger and return the task descriptions to each engine (Kashi: replicators retrieve jobs from queue ¶ [0225]; replicators scan job queue and evaluate parameters [0237]; parameters define job characteristics ¶ [0010], [0209]).
Regarding claim 17, the combination of Kashi, Hankins and Igelka clearly show a method for performing the process for the method in claims 1 and 3. Therefore, the rejections of claims 1 and 3 applies to claim 16.
Claim(s) 4-8, 11-14, 16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kashi in view of Hankins in view Igelka in view of of D'Halluin; Carl et al. (US 20210165767 A1) [D’Halluin].
Regarding claims 4 and 11, the combination of Kashi, Hankins and Igelka discloses, wherein each engine of the plurality of engines comprises: a first lister that lists objects from the first object storage service and a second lister that lists the objects from the second object storage service (Kashi: interaction with object storage endpoints, managing objects, buckets, namespaces ¶ [0091], examiner specifies that, replication requires identifying objects at source and target. Additionally, examiner has interpreted listing source objects as first lister and identifying target objects and second lister);
a migrator configured to read the objects from the first object storage service and write the objects in the second object storage service (Kashi: transferring data between source and target ¶ [0091]; cross region replication ¶ [0002], [0050] and [0091]);
a comparator configured to compare the objects from the first object storage service and the second object storage service to verify whether the object is to be migrated to the second object storage service and feed lists of objects to be migrated to the migrator, wherein the comparator compares the objects page-by-page; and
a slotter configured to receive the migration parameters from the management module (Kashi: job selection based on parameters ¶ [0225], [0237]; evaluation jobs against capacity/parameters ¶ [0212]; examiner specifies that, this corresponds to, assigning a job to replicators and verifying whether job fits engine capacity), calculate a slot assignment for an object using a hash of an object key and a modulo operation, and verify whether the object is assigned to the migration slot of the engine of plurality of engines (Igelka: For instance, if the migration system 100 can only migrate ten virtual machines in parallel out of one hundred virtual machines total, then if a cut-over operation is requested for twenty virtual machines at once, the ten slots available to the migration system 100 will be used first for twenty cut-over cycles, before performing other types of migration cycles ¶ [0079]; In one example, in migrating a group of virtual machines, some virtual machines may have multiple disks. The migration system 100 may have a limited amount of disk slots for handling disk migrations. The migration system can implement a load-balancing scheme, in addition to a schedule generated, for example, based on constraints, assigned weights, priorities, available computing resources, etc. ¶ [0098]; also see ¶ [0054], [0085], [0103], [0106], [0109]) thereby allowing to distribute objects between the engines to horizontally increase the speed of the migration (Kashi: parallel and concurrent execution ¶ [0217]; improve performance and scalability ¶ [0048]).
However, neither one of Kashi, Hankins or Igelka explicitly facilitate a comparator configured to compare the objects from the first object storage service and the second object storage service to verify whether the object is to be migrated to the second object storage service and feed lists of objects to be migrated to the migrator, wherein the comparator compares the objects page-by-page.
D’Halluin discloses, a comparator configured to compare the objects from the first object storage service and the second object storage service (functions for comparing the progress values for a giver dependent data object; barrier objects being compared across shards ¶ [0078]) to verify whether the object is to be migrated to the second object storage service (comparison used to evaluate replication state/progress ¶ [0078]; replication depends on dependency satisfaction and verification of successful replication ¶ [0056], [0072], [0083]) and feed lists of objects to be migrated to the migrator, wherein the comparator compares the objects page-by-page (dada objects added to replication queue…objects are identified for replication to destination data store ¶ [0070]; replication queue may include entries for each pending replication ¶ [0072]; replication manager includes replication queue ¶ [0069]; replication manager adding data objects to replication queues ¶ [0076], parallel replication ¶ [0099]).
It would have been obvious to one ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because D’Halluin’s system would have allowed Kashi, Hankins and Igelka to facilitate a comparator configured to compare the objects from the first object storage service and the second object storage service to verify whether the object is to be migrated to the second object storage service and feed lists of objects to be migrated to the migrator, wherein the comparator compares the objects page-by-page. The motivation to combine is apparent in Kashi, Hankins and Igelka’s reference, because there is a need for a reliable and efficient implementation for managing dependent data objects.
Regarding claim 5, 12 and 18, the combination of Kashi, Hankins and D’Halluin discloses, wherein the management module selects a number of the migration slots based on formula I:
N>K
where N is a number of the migration slots and K is a number of the engines of plurality of engines (Kashi: multiple jobs, multiple replicators, capacity based allocation ¶ [0225], [0237]; scalable fleet of replicators ¶ [0217]).
Regarding claims 6 and 13, the combination of Kashi, Hankins and D’Halluin discloses, wherein the slotter determines the migration slot (Hankins: object ID is mapped to target authority/location ¶ [0206]-[0207]; mapping to a partition in the second storage system ¶ [0221]; examiner specifies that this teaches assigning an object to specific location/destination) based on formula II:
hash(objectkey) % N (Hankins: computing hash value from data segment/identifier ¶ [0079], a hash function is applied to bits of the identifier…transformation based on target number or range partition ¶ [0215], hash applied to object ID and data chunk ID ¶ [0220], hash output used to select one of multiple authorities (partitions) ¶ [0207]. Selection one partition out of N using a hash = %N, and hash applied to object identifier = hash(object_key))
wherein hash is a hash function, % is modulo operation that returns the reminder of a division (Hankins: transformation based on target number or range partition ¶ [0215], hash output used to select one of multiple authorities (partitions)…, a modulo operation can be applied to the result to distribute between a number of targets that is not a power of two. Alternately, the object ID 502 and authority 168 can be XOR'd together in their entirety and a modulo can be applied. ¶ [0207].) and object key is a unique object identifier (Hankins: identifier may be: object ID, file ID, chunk ID ¶ [0220]).
Regarding claims 7, 14 and 19, the combination of Kashi, Hankins and D’Halluin discloses, wherein the slotter determines the migration slot based on formula III:
Hash (key and seed)%slot_based ==slot
wherein hash is a hash function, % is modulo operation that returns the reminder of a division, slot_base is the selected number of the migration slots (N), == denotes equality relation, and slot is an integer number from 0 to N-1 that identifies the migration slot N (Hankins: applying hash function to an object identifier, including combining portions of the identifier and/or additional parameters, and mapping the result to one of a finite set of partitions in a destination storage system, thereby determining a specific partition for the object ¶ [0207], [0215], [0221], hash, bounded space and picking slot are taught by Hankins).
Regarding claims 8 and 16, the combination of Kashi, Hankins and D’Halluin discloses, further comprising a prober configured to verify each object individually using an object key when the comparator cannot compare the object page by page (Kashi: object level operations using object identifiers…replication system verify data and operate at object/file level ¶ [0091]).
Allowable Subject Matter
Claim 20 objected to as being allowable. Examiner specifies, that neither one of the prior are included in this rejection alone or in combination teaches all the limitation of claim 20. Further search was conducted and no additional prior art was found to teach all the limitations of claim 20, therefore claim 20 is considered allowable.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD S ROSTAMI whose telephone number is (571)270-1980. The examiner can normally be reached Mon-Fri From 9 a.m. to 5 p.m..
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, Boris Gorney can be reached at (571)270-5626. 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.
8/19/2026
/MOHAMMAD S ROSTAMI/Primary Examiner, Art Unit 2154
Prosecution Insights