DETAILED ACTION
In response to communication filed on 15 September 2025, this is the first Office Action of the merits. Claims 1-20 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation
Claims 1, 8 and 15 recite “tracking object identifiers used to write the object”. The claims do not recite functionality, but instead recites what the object identifiers are used for. Examiner suggests amending the claim to recite the functionality performed by the claimed method, instead of reciting what the claim elements are used for.
Claims 2, 9 and 16 recite “tracking write path used to write the object”. The claims do not recite functionality, but instead recites what the write path is used for. Examiner suggests amending the claim to recite the functionality performed by the claimed method, instead of reciting what the claim elements are used for.
Double Patenting
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.
Claims 1-6, 8-13 and 15-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 3 of U.S. Patent No. 12417150. Although the claims at issue are not identical, they are not patentably distinct from each other. The claims of patent application teach the limitations of the claims as shown by comparison below in bold
Current Application
(Application# 19329294)
US Patent Application#
12,417,150 B2
Difference
Claim 1: A method comprising:
Claim 1: A method comprising:
storing, within a first object store of a first cloud provider that supports a first data layout requirement, an object according to a fixed offset format where data is stored within slots of the object in an uncompressed format at fixed offsets and boundaries;
storing, within a first object store of a first cloud provider that supports a first data layout requirement, an object according to a fixed offset format where data is stored within slots of the object in an uncompressed format at
fixed offsets and boundaries;
executing a mirroring operation across the first cloud provider and a second cloud provider to mirror the object from the first object store of the first cloud provider as a mirror object to a second object store of the second cloud provider that supports a second data layout requirement supporting a compressed format with non-fixed offsets and boundaries;
executing a mirroring operation across the first cloud
provider and a second cloud provider to mirror the
object from the first object store of the first cloud provider to a second object store of the second cloud provider that supports a second data layout requirement, supporting a compressed format with non-fixed offsets and boundaries,
This is basically referencing to the same information since mirroring an object will create a mirror object.
tracking object identifiers used to write the object to the first object store and the mirrored object to the second object store; and
tracking object identifiers…
to write the object to the first object store and the mirrored object to the second object store; and
utilizing the object identifiers to ensure that the first object store and the second object store refrain from storing multiple objects with a same name but different sizes.
utilizing the object identifiers… to ensure that the first object store and the second object store are refrained from storing multiple objects with a same
name but different sizes
Claim 2: tracking write path used to write the object to the first object store and the mirrored object to the second object store; and
Claim 1: tracking… and identifying write paths that are utilized to write the object to the first object store and the mirrored object to the second object store; and
The claim limitations “used” and “utilized” are referring to the same information.
utilizing the write path to ensure that the first object store and the second object store refrain from storing multiple objects with the same name but different sizes.
Claim 1: utilizing the… write paths to ensure that the first object store and the second object store are refrained from storing multiple objects with a same name but different sizes
Claim 3: executing a retry mechanism to mirror the object to the second object store as a second mirrored object having a same name as the mirrored object, wherein the mirroring operation is unknown to the retry mechanism
Claim 3: executing a retry mechanism to mirror the object to the second object store as a second mirrored object having
a same name as the mirrored object, wherein the mirroring operation is unknown to the retry mechanism;
Claim 4: enforcing an invariant that any data written to the second cloud provider with a same name is to have the exact same data.
Claim 3: enforcing an invariant that any data written to the second cloud provider with a same name is to have the exact
same data,
Claim 5: refraining from storing the second mirrored object to the second object store based upon data within the second mirrored object not matching data within the mirrored object.
Claim 3: refraining from storing the second mirrored object to the second object store based upon data within the second mirrored object not matching data within the mirrored object
Claim 6: wherein the data is not a match where slot header metadata of the second mirrored object does not match the slot header metadata of the mirrored object.
Claim 3: wherein the data is not a match where slot header metadata of the second mirrored object does not match the slot header metadata of the mirrored object.
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of US Patent Application# 12,417,150 B2. The claims of US Patent Application No. 12,417,150 B2 mentions steps on mirroring objects. Although the claims at issue are not identical, they are not patentably distinct from each other because instant application recites as mirror objects and US Patent Application# 12,417,150 B2 does not recite this claim limitation. Based on the analysis above, these terms are referring to the same information respectively. Also, the instant application recites as used and US Patent Application# 12,417,150 B2 recites utilized. Based on the analysis above, these terms are referring to the same information respectively. Therefore, it would have been obvious that the claim limitations in both the current application and US Patent Application# 12,417,150 B2 are referring to the same information. As a result, claim 1 of the current application falls entirely within the scope of claim 1 of US Patent Application# 12,417,150 B2.
Claims 2-6 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 3 of US Patent Application# 12,417,150 B2 as explained in the table above. Thus claims 2-6 of instant application falls entirely within the scope of claims 1 and 3 or in other words, claims 2-6 are anticipated by claims 1 and 3 of US Patent Application# 12,417,150 B2.
Claims 8-13 and 15-20 incorporate substantively all the limitations of claims 1-6 respectively in a computing device and computer-readable medium form and are rejected under the same rationale.
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.
Claims 1, 7-8 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Karmarkar et al. (US 2019/0243688 A1, hereinafter “Karmarkar”) in view of Yang et al. (US 2010/0325094 A1, hereinafter “Yang”) further in view of Huang (US 2005/0193188 A1, hereinafter “Huang”).
Regarding claim 1, Karmarkar teaches
A method comprising: (see Karmarkar, [0038] “methods and systems for distributed object replication”).
storing, within a first object store of a first cloud provider (see Karmarkar, Fig. 1A – element 120A; [0039] “there is a source site that may include a source cloud 105… The source cloud includes one or more node clusters 115A and persistent object storage 120A connected to node cluster 115A”; [0053] “A cloud storage service may be a logical storage that includes any number of physical storage devices operable connected and/or unified to form a logical storage… the object storage is provided by a third-party cloud services provider. Some examples of cloud-based object storage include Amazon S3 as provided by Amazon, IBM Cloud Object Storage by IBM, Google Cloud Storage by Google, Azure Blob Storage by Microsoft, and others. Cloud-based object storage may be referred to as blog storage” – there are plurality of cloud providers; [0069] “The source side, destination side, or both may include a cloud computing site in which compute and storage resources may be dynamically provided. Examples of clouds include Azure as provided by Microsoft, Amazon Web Service (AWS) as provided by Amazon, Google Cloud as provided by Google, and Pivotal Cloud Foundry as provided by the Cloud Foundry Foundation, among many others. The source side may include a source cloud site where the repository begins and the destination side may include a destination cloud site where the repository is copied to during replication” – AWS can be interpreted as first cloud provider and 120A has been interpreted as first object store) that supports a first data layout requirement, (see Karmarkar, [0236] “The data may be any type of data in any format and of any length” – there are plurality of formats and lengths of data that has been interpreted as layout requirement) an object according to… (see Karmarkar, Fig. 1A – element 120A; [0039] “there is a source site that may include a source cloud 105… The source cloud includes one or more node clusters 115A and persistent object storage 120A connected to node cluster 115A”).
executing a mirroring operation across the first cloud provider and a second cloud provider to mirror the object from the first object store of the first cloud provider as a mirror object to a second object store of the second cloud provider (see Karmarkar, [0040] “The set of services include a replication service 130. The replication service is responsible for replicating objects and changes from source object storage 120A to destination object storage 120B. A replication operation may include copying an object or portion of an object from source object storage to destination object storage”; [0053] “A cloud storage service may be a logical storage that includes any number of physical storage devices operable connected and/or unified to form a logical storage… the object storage is provided by a third-party cloud services provider. Some examples of cloud-based object storage include Amazon S3 as provided by Amazon, IBM Cloud Object Storage by IBM, Google Cloud Storage by Google, Azure Blob Storage by Microsoft, and others. Cloud-based object storage may be referred to as blog storage” – there are plurality of cloud providers; [0069] “The source side, destination side, or both may include a cloud computing site in which compute and storage resources may be dynamically provided. Examples of clouds include Azure as provided by Microsoft, Amazon Web Service (AWS) as provided by Amazon, Google Cloud as provided by Google, and Pivotal Cloud Foundry as provided by the Cloud Foundry Foundation, among many others. The source side may include a source cloud site where the repository begins and the destination side may include a destination cloud site where the repository is copied to during replication” – AWS can be interpreted as first cloud provider and Google cloud can be interpreted as second cloud provider, 120A has been interpreted as first object store and 120B has been interpreted as second object store) that supports a second data layout requirement (see Karmarkar, [0236] “The data may be any type of data in any format and of any length” – there are plurality of formats and lengths of data that has been interpreted as layout requirement) supporting a compressed format… (see Karmarkar, [0056] “The actual segments that have been determined to be unique according to the deduplication service may be stored in in a compressed format in the compression regions”; [0041] “Nonduplicate objects (or nonduplicate portions of objects) may be compressed prior to be being copied over and saved to destination object storage”).
tracking object identifiers used to write the object (see Karmarkar, [0054] “an object storage is a data storage architecture that manages data as objects. Each object of the object storage may include data, meta-data, and/or a globally unique identifier of the object”) to the first object store and the mirrored object to the second object store; and (see Karmarkar, [0152]-[0153] “for processing a task to replicate an object. In a step 905, a source worker node issues a call to a destination worker node paired to the source worker node to check whether an object to replicate already exists at the destination object storage… the destination worker node checks whether or not the object already exists…the source worker node identifies the object to be replicated by providing the destination worker node with a unique key or identifier identifying the object… The destination worker node scans the destination object storage to determine whether there already exists an object having the matching key and other meta-data information”).
utilizing the object identifiers to ensure that the first object store and the second object store refrain from storing multiple objects that already exist… (see Karmarkar, [0153] “The destination worker node scans the destination object storage to determine whether there already exists an object having the matching key and other meta-data information. If a determination is made that the object already exists at the destination object storage, the destination worker node returns a reply to the source worker node with an indication that the object already exists… This preliminary check helps to ensure that network bandwidth and compute resources are not expended replicating an object that already exists at the destination object storage”).
Karmarkar does not explicitly teach a fixed offset format where data is stored within slots of the object in an uncompressed format at fixed offsets and boundaries; compressed format with non-fixed offsets and boundaries; multiple objects with a same name but different sizes.
However, Yang discloses data compression for reducing storage requirements and teaches
a fixed offset format where data is stored within slots of the object in an uncompressed format at fixed offsets and boundaries; (see Yang, [0042] “The process includes identifying at least one data candidate of fixed length data type in at least one row of database data for compression based upon a predetermined threshold level and a boundary of compression”; [0047] “follow the uncompressed fixed columns… Padding is included as needed in the offset bitmap to make the row align with a byte boundary”).
compressed data with non-fixed offsets and boundaries; (see Yang, [0047] “the variable length columns that may also be compressed… The end columns of the row format provide the "offset bitmap" which indicates the length of each of the compressed columns… Padding is included as needed in the offset bitmap to make the row align with a byte boundary”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the functionality of fixed offset, boundaries, non-fixed offset, populate header, uncompressed data into fixed offsets and boundaries, variable objects and tuple as being disclosed and taught by Yang in the system taught by Karmarkar to yield the predictable results of providing improved compression techniques (see Yang, [0004] “As regular database and table size has grown tremendously in recent years, data compression becomes increasing important even for databases. While row level compression and page level compression for databases have been introduced, a need remains for improved compression techniques to overcome deficiencies in these approaches without introducing new overhead”).
The proposed combination of Karmarkar and Yang does not explicitly teach multiple objects with a same name but different sizes.
However, Huang discloses and teaches
files with a same name but different sizes (see Huang, [0056] “will list files with the same path and name in both systems with different file size and/or modified time”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the functionality of same name and different size objects as being disclosed and taught by Huang in the system taught by the proposed combination of Karmarkar and Yang to yield the predictable results of effectively providing a synchronization process between two systems (see Huang, [0056] “illustrates a method to synchronize two systems… A similar procedure 1116 can be also applied to files in system 1108 but not in system 1106. A procedure for synchronizing modified files in the file level 1118 will list files with the same path and name in both systems with different file size and/or modified time. The user can update one system by importing files with later modified time from the other system. A procedure for synchronizing modified files in the content level 1120 will list files with the same path and name in both systems with different file content”).
Claims 8 and 15 incorporate substantively all the limitations of claim 1 in a computing device form (see Karmarkar, [0040] “The physical device may be other types of computing devices. The non-transitory storage may include instructions which, when executed by the one or more processors, enable the physical device to perform the functions described herein”) and computer-readable medium form (see Karmarkar, [0040] “The non-transitory storage may include instructions which, when executed by the one or more processors, enable the physical device to perform the functions described herein”) and are rejected under the same rationale.
Regarding claim 7, the proposed combination of Karmarkar, Yang and Huang teaches
comprising: in response to detecting that the mirroring operation failed (see Karmarkar, [0174] “the controller itself may fail during a replication job”) to mirror the object from the first object store to the second object store, (see Karmarkar, [0040] “The set of services include a replication service 130. The replication service is responsible for replicating objects and changes from source object storage 120A to destination object storage 120B. A replication operation may include copying an object or portion of an object from source object storage to destination object storage”) trigger a retry mechanism, wherein an invariant is enforced upon the retry mechanism to cause the retry mechanism (see Karmarkar, [0163] “Status messages include: object replication has begun, the number of slices transferred, replication complete.. If an error has occurred, the controller may, after a number of retry attempts, alert an administrator. If replication of a large object fails in the middle, the controller can restart it from the last logged position”; Fig. 1 - 120B has been interpreted as second object store; [0163] “If replication of a large object fails in the middle, the controller can restart it from the last logged position. If a controller fails and restarts can recalculate the snapshot delta and check which tasks have completed in the key-value store to determine how to continue”; [0171] “the replication job can then be restarted to process the tasks not successfully processed”) to refrain from storing a new mirrored object into the second object store that already exist (see Karmarkar, [0153] “The destination worker node scans the destination object storage to determine whether there already exists an object having the matching key and other meta-data information. If a determination is made that the object already exists at the destination object storage, the destination worker node returns a reply to the source worker node with an indication that the object already exists… This preliminary check helps to ensure that network bandwidth and compute resources are not expended replicating an object that already exists at the destination object storage”; [0096] “to beginning replication over again for all objects in the new snapshot.”) based upon the retry mechanism (see Karmarkar, [0163] “Status messages include: object replication has begun, the number of slices transferred, replication complete.. If an error has occurred, the controller may, after a number of retry attempts, alert an administrator. If replication of a large object fails in the middle, the controller can restart it from the last logged position”; Fig. 1 - 120B has been interpreted as second object store; [0163] “If replication of a large object fails in the middle, the controller can restart it from the last logged position. If a controller fails and restarts can recalculate the snapshot delta and check which tasks have completed in the key-value store to determine how to continue”; [0171] “the replication job can then be restarted to process the tasks not successfully processed”) determining that slot header metadata of the new mirrored object does not match slot header metadata of the mirrored object (see Karmarkar, [0267]-[0269] “a new similarity group meta-data entry is generated and stored in the object storage if the sketch of the slice does not match a sketch of any similarity group meta-data that is already stored in object storage… the backend micro-service compares each fingerprint of each segment of the slice to each fingerprint obtained in step 1730. For each fingerprint that does not match any of the obtained fingerprints, the segment that corresponds to the fingerprint may be added to a compression region and the matched similarity group meta-data of step 1720 may be updated”).
Claim 14 incorporates substantively all the limitations of claim 7 in a computing device form and is rejected under the same rationale.
Claims 2-6, 9-13 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Karmarkar, Yang and Huang in view of Lewis et al. (US 2013/0073519 A1, hereinafter “Lewis”).
Regarding claim 2, the proposed combination of Karmarkar, Yang and Huang teaches
… write the object to the first object store and the mirrored object to the second object store; and (see Karmarkar, [0055] “when a client writes an object to the microservice, the microservice performs a deduplication and generates a number of pieces of data and metadata that are stored in object storage... These pieces of data and metadata facilitate the overall management and organization of the customer objects including processes for replication, deduplication, retrieval, and parallelism”; [0075] “in order to mimic a directory or folder structure in object storage, users may form object names in a hierarchical manner such that a prefix corresponds to a directory path ( e.g. "backup/<username>/< foldername>")”).
… to ensure that the first object store and the second object store refrain from storing multiple objects that already exist (see Karmarkar, [0153] “The destination worker node scans the destination object storage to determine whether there already exists an object having the matching key and other meta-data information. If a determination is made that the object already exists at the destination object storage, the destination worker node returns a reply to the source worker node with an indication that the object already exists… This preliminary check helps to ensure that network bandwidth and compute resources are not expended replicating an object that already exists at the destination object storage”) with the same name but different sizes (see Huang, [0056] “will list files with the same path and name in both systems with different file size and/or modified time”).
The proposed combination of Karmarkar, Yang and Huang does not explicitly teach comprising: tracking write path used to; utilizing the write path.
However, Lewis discloses replication in a storage system and teaches
comprising: tracking write path used to (see Lewis, [0119] “The destination receives the data stream… the destination writes the contents of the received data extents (from the data stream) to data extents in its local storage subsystem 4B and creates a mapping (in the data warehouse) between the source names and local extent addresses (destination names) of the local data extents… the destination updates the data warehouse by adding each <source name, destination name> pair”; [claim 25] “mapping two or more of the source extent identifiers, corresponding respectively to two or more of the plurality of data extents, to a single data extent identifier corresponding to a destination data extent at the destination storage system”).
utilizing the write path (see Lewis, [0119] “The destination receives the data stream… the destination writes the contents of the received data extents (from the data stream) to data extents in its local storage subsystem 4B and creates a mapping (in the data warehouse) between the source names and local extent addresses (destination names) of the local data extents… the destination updates the data warehouse by adding each <source name, destination name> pair”; [claim 25] “mapping two or more of the source extent identifiers, corresponding respectively to two or more of the plurality of data extents, to a single data extent identifier corresponding to a destination data extent at the destination storage system”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the functionality of tracking write path and utilizing write path as being disclosed and taught by Lewis in the system taught by the proposed combination of Karmarkar, Yang and Huang to yield the predictable results of enabling replication while preserving storage efficiency (see Lewis, [0010] “the techniques introduced here enable a replication system to accommodate different extent sizes between replication source and destination (i.e., extent size asymmetry) while preserving storage efficiency. This allows the source and the destination to run different types or versions of file systems or storage operating systems. It also can enable additional space savings to be achieved on the destination, such as where the source deduplicates data that is uncompressed and the destination preserves the deduplication and compresses the data”).
Claims 9 and 16 incorporate substantively all the limitations of claim 2 in a computing device and computer-readable medium form and are rejected under the same rationale.
Regarding claim 3, the proposed combination of Karmarkar, Yang, Huang and Lewis teaches
comprising: executing a retry mechanism to (see Karmarkar, [0163] “Status messages include: object replication has begun, the number of slices transferred, replication complete.. If an error has occurred, the controller may, after a number of retry attempts, alert an administrator. If replication of a large object fails in the middle, the controller can restart it from the last logged position”; Fig. 1 - 120B has been interpreted as second object store; [0163] “If replication of a large object fails in the middle, the controller can restart it from the last logged position. If a controller fails and restarts can recalculate the snapshot delta and check which tasks have completed in the key-value store to determine how to continue”) mirror the object to the second object store as a second mirrored object (see Karmarkar, [0040] “The set of services include a replication service 130. The replication service is responsible for replicating objects and changes from source object storage 120A to destination object storage 120B. A replication operation may include copying an object or portion of an object from source object storage to destination object storage”) having a same name as the mirrored object, (see Karmarkar, [0125] “The first snapshot lists an object recipe having a name that includes the user-generated object name "Obj A," reserved symbols "##," and a corresponding timestamp of "Time 5." The second snapshot also lists an object recipe having a name that includes the user-generated object name "Obj A," reserved symbols "##," and a same corresponding timestamp of "Time 5”) wherein the mirroring operation (see Karmarkar, [0163] “Status messages include: object replication has begun, the number of slices transferred, replication complete.. If an error has occurred, the controller may, after a number of retry attempts, alert an administrator. If replication of a large object fails in the middle, the controller can restart it from the last logged position”; [0040] “The set of services include a replication service 130. The replication service is responsible for replicating objects and changes from source object storage 120A to destination object storage 120B. A replication operation may include copying an object or portion of an object from source object storage to destination object storage”) is unknown to the retry mechanism (see Karmarkar, [0170] “The threshold number of times to retry can be a user-configurable value” – after the threshold number of retries, the retry no longer takes place and hence it is unknown).
Claims 10 and 17 incorporate substantively all the limitations of claim 3 in a computing device and computer-readable medium form and are rejected under the same rationale.
Regarding claim 4, the proposed combination of Karmarkar, Yang, Huang and Lewis teaches
comprising: enforcing an invariant that any data written to the second cloud provider with a same name is to have the exact same data (see Karmarkar, [0125] “The first snapshot lists an object recipe having a name that includes the user-generated object name "Obj A," reserved symbols "##," and a corresponding timestamp of "Time 5." The second snapshot also lists an object recipe having a name that includes the user-generated object name "Obj A," reserved symbols "##," and a same corresponding timestamp of "Time 5”. Thus, in this example, "Obj A" does not need to be replicated or deleted because there have been no changes to the object as indicated by the timestamp”; [0069] “The source side, destination side, or both may include a cloud computing site in which compute and storage resources may be dynamically provided. Examples of clouds include Azure as provided by Microsoft, Amazon Web Service (AWS) as provided by Amazon, Google Cloud as provided by Google, and Pivotal Cloud Foundry as provided by the Cloud Foundry Foundation, among many others. The source side may include a source cloud site where the repository begins and the destination side may include a destination cloud site where the repository is copied to during replication” – Google cloud can be interpreted as second cloud provider).
Claims 11 and 18 incorporate substantively all the limitations of claim 4 in a computing device and computer-readable medium form and are rejected under the same rationale.
Regarding claim 5, the proposed combination of Karmarkar, Yang, Huang and Lewis teaches
wherein the enforcing comprises: refraining from storing the second mirrored object to the second object store based upon data within the second mirrored object not matching data within the mirrored object (see Karmarkar, [0126] “The first snapshot further lists an object recipe having a name that includes the user-generated object name "Obj B," reserved symbols "##," and a corresponding timestamp of "Time 3." The second snapshot does not include a corresponding object recipe listing for object B. Thus, a determination is made that object B was deleted from the source object storage since the first snapshot and a task is generated to likewise delete object B from the destination object storage” – obj B is not being stored but instead deleted; Fig. 1 - 120B has been interpreted as second object store).
Claims 12 and 19 incorporate substantively all the limitations of claim 5 in a computing device and computer-readable medium form and are rejected under the same rationale.
Regarding claim 6, the proposed combination of Karmarkar, Yang, Huang and Lewis teaches
wherein the data is not a match where slot header metadata of the second mirrored object does not match the slot header metadata of the mirrored object (see Karmarkar, [0267]-[0269] “a new similarity group meta-data entry is generated and stored in the object storage if the sketch of the slice does not match a sketch of any similarity group meta-data that is already stored in object storage… the backend micro-service compares each fingerprint of each segment of the slice to each fingerprint obtained in step 1730. For each fingerprint that does not match any of the obtained fingerprints, the segment that corresponds to the fingerprint may be added to a compression region and the matched similarity group meta-data of step 1720 may be updated”).
Claims 13 and 20 incorporate substantively all the limitations of claim 6 in a computing device and computer-readable medium form and are rejected under the same rationale
Citation of Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent No. 9,933,956 B2 (Ramachandran et al.) teaches the replication process that will then involve replication of the data for the objects to be replicated to the destination datastore.
US Publication No. 2009/0303160 A1 (Chew et al.) teaches the replication process that hat there are files sharing the same name but have different size.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VAISHALI SHAH whose telephone number is (571)272-8532. The examiner can normally be reached Monday - Friday (7:30 AM to 4:00 PM).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, AJAY BHATIA can be reached at (571)272-3906. 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.
/VAISHALI SHAH/Primary Examiner, Art Unit 2156
Prosecution Insights