DETAILED ACTION
Receipt of Applicant’s Amendment, filed July 30, 2026 is acknowledged.
Claims 1, 6, 12, 16, 21, and 26 were amended.
Claims 1-30 are pending in this office action.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 4-7, 9-13, 15-30 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Demoor [2020/0409566].
With regard to claim 1 Demoor taches A method comprising:
maintaining, by a storage system as the data store, e.g. key data store 102 (Demoor, ¶42, “Log entries 140 may be stored as a key entry in a key data store as described with regard to FIGS. lA-lC.”; ¶29 “key data store 102,”), a bucket as the group, e.g. bucket with specific ID (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) containing a plurality of objects as the clients object that are grouped together (Id), wherein each of the plurality of objects has one or more object versions (Demoor, ¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time, and allows for the archival of the different versions of the object as they occur over time ( e.g., due to modifications made over time to the object), retrieval of a prior version of the object, and/or recovery from unintended overwrites and/or deletions made to the object.”), wherein a given object as a data instance (¶30 “Further, as shown in FIG. 1A, each key (e.g., DA . . . DN, etc.) can correspond to a data instance (e.g., DA . .. DN).”) of the plurality of objects represents a fundamental unit of data storage as the actual data object stored (¶30 “The data instance may comprise a pointer to a location where the actual object data is stored (e.g., in a separate database, on a physical drive, etc.), or other suitable data values. Each key may correspond to a particular object.”) used by object storage as the shards that stores an ordered subset of object key entries (¶29 “FIG. 1A is a diagram illustrating an example key data store 102, which comprises a plurality of shards S1 ... SN. While two shards S1 and SN are shown, it should be understood that any suitable number of shards may be included. Each shard stores an ordered subset of object key entries.”; ¶34 “an object storage”), and wherein the bucket as the group, e.g. bucket with specific ID (Demoor, ¶33) represents an object-based as the identifier for a group of objects (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related”) storage resource as allocated storage space for the bucket (¶133 “For example, a write operation may allocate storage space to a data object, utilize processing, metadata, or other resources, relate to user, bucket, or system allocations, or have other system impacts that may be defined as properties of the operation”) or container as the logically related group of objects (¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related… In this way, a given client's object keys can be grouped together”) for storing objects (¶29; ¶34);
creating, by the storage system as the data store, e.g. key data store 102 (Demoor, ¶42, ¶29), a snapshot as creating the new entry in the set of object key entries (Demoor, ¶78 “the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp…. This advantageously allows for scalable and flexible versioning of a data object”; the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) of the bucket as the group, e.g. bucket (Demoor, ¶33) by adding a snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 “In the foregoing example, the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp”) including a snapshot identifier (ID) as the prefix 122, which is the bucket identifier (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) and a snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35 “The suffix 126 may comprise a ticket value for ordering different object keys associated with a particular object. The ticket value (also simply called ticket in some embodiments) may be an inverse timestamp.”) to a snapshot metafile as the ordered set of object entries, e.g. the log set of entries (Demoor, ¶29 “The subsets 106-1 through 106-N comprise the ordered set of object key entries 104”; ¶31 “In some embodiments, key entries 106-1, 106-N may include a log set of entries that define a log that may be traversed to determine the state of one or more data objects and their properties and/or determine one or more data storage parameters.”; Figure 1A, see 104 comprised of S1, 106-1, SN and 1060N) which may be defined based on one or more properties (¶75 “Entries storing property change values may define a log set of key entries for one or more properties, objects, or other logical grouping of log entries.”), wherein the snapshot represents a point-in-time reference point (¶30 “Each key may correspond to a particular object. Further, various subsets of object key entries may correspond to the same object at different points in time.”) that preserves a state (¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time”) of the bucket as the group, e.g. bucket (Demoor, ¶33) as of the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35); and
after creation of the snapshot as creating the new entry in the set of object key entries (Demoor, ¶78), protecting (Demoor, ¶104; ¶105 “protect against”), by the storage system as the data store, e.g. key data store 102 (Demoor, ¶42, ¶29), those of the one or more object versions (Demoor, ¶41) of respective objects as the objects to which the operation impacts (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users.”) of the plurality of objects as the objects in the group (Demoor, ¶33) existing at a specific point in time (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “For example, the previously described write operation on object A at A_S0_ W may be followed by a second write from a different client at 30 ms”) indicated by the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35).
With regard to claims Demoor further teaches 2, 7, and 13 wherein the snapshot comprises a manual snapshot as the user updating the document and saving a new version (Demoor, ¶57 “For example, a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) in which the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35) is specified by a requestor as determining the timestamp (Demoor, ¶76 “Responsive to receiving the storage instruction from storage service 322, key data store controller 320 computes an inverse timestamp using the key-related data, generates the key using the inverse timestamp, the object identifier, etc. (e.g., a prefix, an operation type, etc.),”) when the user clicking to save the updated version (Demoor, ¶57) of the snapshot (Demoor, ¶57).
With regard to claims 4, 10 and 15 Demoor further teaches wherein said protecting comprises one or more of:
prohibiting, by the storage system, deletion or modification as not immediately modifying the parameter (Demoor, ¶102 “Storage service 322 may immediately render the data object invisible to the user, but log operations 332 may not immediately modify related parameter calculations.”) of object index nodes (inodes) as metadata entry in the log entry, indexed by timestamp and other information (Demoor, ¶49 “the information is maintained in log entry metadata even when the log entry is migrated or replicated”; ¶84 “object data to be stored in the object storage 240 (e.g., comprising a new object, modification to the object, object metadata describing the object, updates, etc.”; ¶89 “indexed by timestamp values and/or key values including timestamp values or inverse timestamp values.”; Please note the term “inode” has been read in light of Paragraph [0045] as being a file data structure that stores metadata for data containers) and associated blocks as shards (Demoor, ¶28 “In some embodiments, the key data store may be sharded or distributed and the technology may include shard identifiers in the key data store to correct for timing differences in storage management processes across shards.”) for those of the one or more object versions (Demoor, ¶41) of the respective objects as the objects to which the operation impacts (Demoor, ¶104, ¶105);
prohibiting, by the storage system, deletion or modification as not immediately modifying the parameter (Demoor, ¶102 “Storage service 322 may immediately render the data object invisible to the user, but log operations 332 may not immediately modify related parameter calculations.”) of system metadata (Demoor, ¶49 “Original shard identifier 178 and original shard timestamp 180 may enable an accurate record of where and when the log entry originated that is maintained as the log entry is managed across sharded logs, such that the information is maintained in log entry metadata even when the log entry is migrated or replicated.”; ¶84) from object inodes as metadata entry in the log entry, indexed by timestamp and other information (Demoor, ¶49; ¶84; ¶89) for those of the one or more object versions (Demoor, ¶41) of the respective objects (Demoor, ¶104; ¶105); and
prohibiting, by the storage system, deletion or modification as not immediately modifying the parameter (Demoor, ¶102 “Storage service 322 may immediately render the data object invisible to the user, but log operations 332 may not immediately modify related parameter calculations.”) of index node (inode) labels as the delete key data entry remains (Demoor, ¶104 “The end result may be total storage capacity of OB and only the delete key data entries remaining in the key database.”) of object inodes as metadata entry in the log entry, indexed by timestamp and other information (Demoor, ¶49; ¶84; ¶89) for those of the one or more object versions (Demoor, ¶41) of the respective objects (Demoor, ¶104; ¶105).
With regard to claims 5 and 11 Demoor further teaches wherein a given object of the plurality of objects having a deletion timestamp set as the time 41 of the delete operations (Demoor, ¶104 “For example, two users may issue delete operations for data object A at times 40 and 41.”) is considered a hidden object as invisible for the user (Demoor, ¶104 “For example, two users may issue delete operations for data object A at times 40 and 41. As described above, the initial write would be logged at A_S0 W and the first delete would be logged at A_60_K. The second delete would be logged as: A_59 K; from: None.<0B>; to:<deleteOP>. Storage service 322 rendering the data object invisible for users and marking object A for garbage collection is not impacted by multiple instances.”) and wherein the method further comprises excluding as the entry from:None.<0B> for the second delete operation (Demoor, ¶104 “The second delete would be logged as: A_59 K; from: None.<0B>; to:<deleteOP>.”) from said protecting hidden objects as the second entry does not impact the garbage collection operation (Demoor, ¶104 “Storage service 322 rendering the data object invisible for users and marking object A for garbage collection is not impacted by multiple instances.”) in which the respective deletion timestamp as the inverted timestamp for the second delete is logged at A_59_K tied to time 41 (Demoor, ¶104 “For example, two users may issue delete operations for data object A at times 40 and 41. As described above, the initial write would be logged at A_S0 Wand the first delete would be logged at A_60_K. The second delete would be logged as: A_59 K; from: None.<0B>; to:<deleteOP>. Storage service 322 rendering the data object invisible for users and marking object A for garbage collection is not impacted by multiple instances.”) is earlier as 59 is ordered earlier than 60 (Demoor, ¶35) than the snapshot timestamp as the timestamp 41 for the first delete operation is logged as A_60_K (Demoor, ¶104 “For example, two users may issue delete operations for data object A at times 40 and 41. As described above, the initial write would be logged at A_S0 Wand the first delete would be logged at A_60_K.).
With regard to claim 6 Demoor teaches A non-transitory machine readable medium storing instructions, which when executed by one or more processors (¶160 “processors”) of a storage system as the data store, e.g. key data store 102 (Demoor, ¶42, “Log entries 140 may be stored as a key entry in a key data store as described with regard to FIGS. lA-lC.”; ¶29 “key data store 102,”), cause the storage system to:
Maintain a bucket as the group, e.g. bucket with specific ID (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) containing a plurality of objects as the clients object that are grouped together (Id), wherein each of the plurality of objects has one or more object versions (Demoor, ¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time, and allows for the archival of the different versions of the object as they occur over time ( e.g., due to modifications made over time to the object), retrieval of a prior version of the object, and/or recovery from unintended overwrites and/or deletions made to the object.”), wherein a given object as a data instance (¶30 “Further, as shown in FIG. 1A, each key (e.g., DA . . . DN, etc.) can correspond to a data instance (e.g., DA . .. DN).”) of the plurality of objects represents a fundamental unit of data storage as the actual data object stored (¶30 “The data instance may comprise a pointer to a location where the actual object data is stored (e.g., in a separate database, on a physical drive, etc.), or other suitable data values. Each key may correspond to a particular object.”) used by object storage as the shards that stores an ordered subset of object key entries (¶29 “FIG. 1A is a diagram illustrating an example key data store 102, which comprises a plurality of shards S1 ... SN. While two shards S1 and SN are shown, it should be understood that any suitable number of shards may be included. Each shard stores an ordered subset of object key entries.”; ¶34 “an object storage”), and wherein the bucket as the group, e.g. bucket with specific ID (Demoor, ¶33) represents an object-based as the identifier for a group of objects (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related”) storage resource as allocated storage space for the bucket (¶133 “For example, a write operation may allocate storage space to a data object, utilize processing, metadata, or other resources, relate to user, bucket, or system allocations, or have other system impacts that may be defined as properties of the operation”) or container as the logically related group of objects (¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related… In this way, a given client's object keys can be grouped together”) for storing objects (¶29; ¶34);
create a snapshot as creating the new entry in the set of object key entries (Demoor, ¶78 “the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp…. This advantageously allows for scalable and flexible versioning of a data object”; the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) of the bucket as the group, e.g. bucket (Demoor, ¶33) by adding a snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 “In the foregoing example, the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp”) including a snapshot identifier (ID) as the prefix 122, which is the bucket identifier (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) and a snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35 “The suffix 126 may comprise a ticket value for ordering different object keys associated with a particular object. The ticket value (also simply called ticket in some embodiments) may be an inverse timestamp.”) to a snapshot metafile as the ordered set of object entries, e.g. the log set of entries (Demoor, ¶29 “The subsets 106-1 through 106-N comprise the ordered set of object key entries 104”; ¶31 “In some embodiments, key entries 106-1, 106-N may include a log set of entries that define a log that may be traversed to determine the state of one or more data objects and their properties and/or determine one or more data storage parameters.”; Figure 1A, see 104 comprised of S1, 106-1, SN and 1060N) which may be defined based on one or more properties (¶75 “Entries storing property change values may define a log set of key entries for one or more properties, objects, or other logical grouping of log entries.”), wherein the snapshot represents a point-in-time reference point (¶30 “Each key may correspond to a particular object. Further, various subsets of object key entries may correspond to the same object at different points in time.”) that preserves a state (¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time”) of the bucket as the group, e.g. bucket (Demoor, ¶33) as of the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35); and
after creation of the snapshot as creating the new entry in the set of object key entries (Demoor, ¶78), protecting (Demoor, ¶104; ¶105 “protect against”) those of the one or more object versions (Demoor, ¶41) of respective objects as the objects to which the operation impacts (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users.”) of the plurality of objects as the objects in the group (Demoor, ¶33) existing at a specific point in time (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “For example, the previously described write operation on object A at A_S0_ W may be followed by a second write from a different client at 30 ms”) indicated by the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35).
With regard to claim 9 Demoor further teaches wherein the snapshot comprises a scheduled (Demoor, ¶113 “schedules various processes”; ¶114 “may include process scheduler 352”; ¶115) snapshot (Demoor, ¶41) that is automatically created by the storage system in accordance with a predefined or configurable schedule (Demoor, ¶115 “process scheduler 352 may include active scheduling of log post-processing and manage schedules, elapsed times, trigger conditions, and/or priority queues for one or more post-processing storage management processes”).
With regard to claim 12 Demoor further teaches A storage system as the data store, e.g. key data store 102 (Demoor, ¶42, “Log entries 140 may be stored as a key entry in a key data store as described with regard to FIGS. lA-lC.”; ¶29 “key data store 102,”) comprising:
one or more processing resources (Demoor, ¶160 “processor(s)); and
instructions that when executed by the one or more processor ((Demoor, ¶160 “The processor(s) 302 may execute software instructions by performing various input/output, logical, and/or mathematical operations”) cause the storage system to:
Maintain a bucket as the group, e.g. bucket with specific ID (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) containing a plurality of objects as the clients object that are grouped together (Id), wherein each of the plurality of objects has one or more object versions (Demoor, ¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time, and allows for the archival of the different versions of the object as they occur over time ( e.g., due to modifications made over time to the object), retrieval of a prior version of the object, and/or recovery from unintended overwrites and/or deletions made to the object.”) , wherein a given object as a data instance (¶30 “Further, as shown in FIG. 1A, each key (e.g., DA . . . DN, etc.) can correspond to a data instance (e.g., DA . .. DN).”) of the plurality of objects represents a fundamental unit of data storage as the actual data object stored (¶30 “The data instance may comprise a pointer to a location where the actual object data is stored (e.g., in a separate database, on a physical drive, etc.), or other suitable data values. Each key may correspond to a particular object.”) used by object storage as the shards that stores an ordered subset of object key entries (¶29 “FIG. 1A is a diagram illustrating an example key data store 102, which comprises a plurality of shards S1 ... SN. While two shards S1 and SN are shown, it should be understood that any suitable number of shards may be included. Each shard stores an ordered subset of object key entries.”; ¶34 “an object storage”), and wherein the bucket as the group, e.g. bucket with specific ID (Demoor, ¶33) represents an object-based as the identifier for a group of objects (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related”) storage resource as allocated storage space for the bucket (¶133 “For example, a write operation may allocate storage space to a data object, utilize processing, metadata, or other resources, relate to user, bucket, or system allocations, or have other system impacts that may be defined as properties of the operation”) or container as the logically related group of objects (¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related… In this way, a given client's object keys can be grouped together”) for storing objects (¶29; ¶34);
create a snapshot as creating the new entry in the set of object key entries (Demoor, ¶78 “the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp…. This advantageously allows for scalable and flexible versioning of a data object”; the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) of the bucket as the group, e.g. bucket (Demoor, ¶33) by adding a snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 “In the foregoing example, the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp”) including a snapshot identifier (ID) as the prefix 122, which is the bucket identifier (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) and a snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35 “The suffix 126 may comprise a ticket value for ordering different object keys associated with a particular object. The ticket value (also simply called ticket in some embodiments) may be an inverse timestamp.”) to a snapshot metafile as the ordered set of object entries, e.g. the log set of entries (Demoor, ¶29 “The subsets 106-1 through 106-N comprise the ordered set of object key entries 104”; ¶31 “In some embodiments, key entries 106-1, 106-N may include a log set of entries that define a log that may be traversed to determine the state of one or more data objects and their properties and/or determine one or more data storage parameters.”; Figure 1A, see 104 comprised of S1, 106-1, SN and 1060N) which may be defined based on one or more properties (¶75 “Entries storing property change values may define a log set of key entries for one or more properties, objects, or other logical grouping of log entries.”), wherein the snapshot represents a point-in-time reference point (¶30 “Each key may correspond to a particular object. Further, various subsets of object key entries may correspond to the same object at different points in time.”) that preserves a state (¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time”) of the bucket as the group, e.g. bucket (Demoor, ¶33) as of the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35); and
after creation of the snapshot as creating the new entry in the set of object key entries (Demoor, ¶78), protecting (Demoor, ¶104; ¶105 “protect against”) those of the one or more object versions (Demoor, ¶41) of respective objects as the objects to which the operation impacts (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users.”) of the plurality of objects as the objects in the group (Demoor, ¶33) existing at a specific point in time (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “For example, the previously described write operation on object A at A_S0_ W may be followed by a second write from a different client at 30 ms”) indicated by the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35).
With regard to claim 16 Demoor further teaches A method comprising:
maintaining, by a storage system as the data store, e.g. key data store 102 (Demoor, ¶42, “Log entries 140 may be stored as a key entry in a key data store as described with regard to FIGS. lA-lC.”; ¶29 “key data store 102,”), a bucket as the group, e.g. bucket with specific ID (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) containing a plurality of objects as the clients object that are grouped together (Id), wherein each of the plurality of objects has one or more object versions(Demoor, ¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time, and allows for the archival of the different versions of the object as they occur over time ( e.g., due to modifications made over time to the object), retrieval of a prior version of the object, and/or recovery from unintended overwrites and/or deletions made to the object.”), wherein a given object as a data instance (¶30 “Further, as shown in FIG. 1A, each key (e.g., DA . . . DN, etc.) can correspond to a data instance (e.g., DA . .. DN).”) of the plurality of objects represents a fundamental unit of data storage as the actual data object stored (¶30 “The data instance may comprise a pointer to a location where the actual object data is stored (e.g., in a separate database, on a physical drive, etc.), or other suitable data values. Each key may correspond to a particular object.”) used by object storage as the shards that stores an ordered subset of object key entries (¶29 “FIG. 1A is a diagram illustrating an example key data store 102, which comprises a plurality of shards S1 ... SN. While two shards S1 and SN are shown, it should be understood that any suitable number of shards may be included. Each shard stores an ordered subset of object key entries.”; ¶34 “an object storage”), and wherein the bucket as the group, e.g. bucket with specific ID (Demoor, ¶33) represents an object-based as the identifier for a group of objects (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related”) storage resource as allocated storage space for the bucket (¶133 “For example, a write operation may allocate storage space to a data object, utilize processing, metadata, or other resources, relate to user, bucket, or system allocations, or have other system impacts that may be defined as properties of the operation”) or container as the logically related group of objects (¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related… In this way, a given client's object keys can be grouped together”) for storing objects (¶29; ¶34);
maintaining, by the storage system as the data store, e.g. key data store 102 (Demoor, ¶42, ¶29), a snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 “In the foregoing example, the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp”); the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) within a snapshot metafile as the ordered set of object entries, e.g. the log set of entries (Demoor, ¶29 “The subsets 106-1 through 106-N comprise the ordered set of object key entries 104”; ¶31 “In some embodiments, key entries 106-1, 106-N may include a log set of entries that define a log that may be traversed to determine the state of one or more data objects and their properties and/or determine one or more data storage parameters.”; Figure 1A, see 104 comprised of S1, 106-1, SN and 1060N) which may be defined based on one or more properties (¶75 “Entries storing property change values may define a log set of key entries for one or more properties, objects, or other logical grouping of log entries.”) for each snapshot as creating the new entry in the set of object key entries (Demoor, ¶78 “the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp…. This advantageously allows for scalable and flexible versioning of a data object”; the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) of a plurality of snapshots of the bucket as the group, e.g. bucket (Demoor, ¶33), wherein the snapshot entry includes a snapshot identifier (ID) as the prefix 122, which is the bucket identifier (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) and a snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35 “The suffix 126 may comprise a ticket value for ordering different object keys associated with a particular object. The ticket value (also simply called ticket in some embodiments) may be an inverse timestamp.”), wherein a given snapshot of the plurality of snapshots represents a point-in-time reference point (¶30 “Each key may correspond to a particular object. Further, various subsets of object key entries may correspond to the same object at different points in time.”) that preserves a state (¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time”) of the bucket as the group, e.g. bucket (Demoor, ¶33) as of the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35) of the snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 ) for the given snapshot as the key for the particular object (¶30); and
after receiving, by the storage system, a request that would result in deletion (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users.”) of a particular version as data object A (Id, ¶41) of the one or more object versions (Demoor, ¶41) of a given object of the plurality of objects as the objects in the group (Demoor, ¶33), prior to deleting the particular version (Demoor, ¶152 “For example, garbage collection may be a dependent process that should allow one or more other prerequisite processes, such as a replication process, to complete”), determining whether as determining if Dependent condition is met (Figure 7, 710) the particular version is protected by one or more snapshots of the plurality of snapshots (Demoor, ¶104 “The foregoing process may protect against mishandling of multiple delete operations”; ¶105 “In some embodiments, the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users”) by comparing (Figure 7, 708; ¶154 “At block 708, the computer system may compare the original timestamp value to a last known progress value for the prerequisite process. For example, on a prior iteration through method 700 for a prior log entry, a progress value for the prerequisite process may have been queried and stored”) one or more time indicators of the particular version as original timestamp values (Id) to the respective snapshot time indicators as last known progress value (Id) of the one or more snapshot entries for the one or more snapshots (Demoor, ¶78).
With regard to claims 17, 22, and 27 Demoor further teaches permitting, by the storage system, deletion of the particular version to proceed as performing garbage collection once the dependent process is complete (Demoor, ¶152 “For example, garbage collection may be a dependent process that should allow one or more other prerequisite processes, such as a replication process, to complete”) based on a determination that the particular version is not protected (Demoor, ¶155 “If the next log entry is still before the stored progress value, the condition is met and successful verification may be returned at block 712.”).
With regard to claims 18, 23, and 28 Demoor further teaches marking the particular version as hidden externally but retaining the particular version internally (Demoor, ¶102 “Storage service 322 may immediately render the data object invisible to the user, but log operations 332”; ¶104 “Storage service 322 rendering the data object invisible for users and marking object A for garbage collection is not impacted by multiple instances.”) based on a determination that the particular version is protected (Demoor, ¶104 “The foregoing process may protect against mishandling of multiple delete operations”; ¶152 “For example, garbage collection may be a dependent process that should allow one or more other prerequisite processes, such as a replication process, to complete.”).
With regard to claims 19, 24, and 29 Demoor further teaches wherein the particular version is marked as hidden by setting a deletion timestamp of the particular version as the <deleteOP> tag (Demoor, ¶104 “As described above, the initial write would be logged at A_S0 Wand the first delete would be logged at A_60_K. The second delete would be logged as: A_59 K; from: None.<0B>; to:<deleteOP>. Storage service 322 rendering the data object invisible for users and marking object A for garbage collection is not impacted by multiple instances.”).
With regard to claims 20, 25 and 30 Demoor further teaches wherein the snapshot ID comprises a snapshot name as the prefix 122, which may be a domain identifier, bucket identifier, client identifier or any combination thereof (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”), wherein the snapshot time indicator comprises a snapshot timestamp as suffix 126, which may include the inverse timestamp (Demoor, ¶35 “The suffix 126 may comprise a ticket value for ordering different object keys associated with a particular object. The ticket value (also simply called ticket in some embodiments) may be an inverse timestamp.”), and wherein the snapshot metafile as the ordered set of object entries, e.g. the log set of entries (Demoor, ¶29 “The subsets 106-1 through 106-N comprise the ordered set of object key entries 104”; ¶31 “In some embodiments, key entries 106-1, 106-N may include a log set of entries that define a log that may be traversed to determine the state of one or more data objects and their properties and/or determine one or more data storage parameters.”; Figure 1A, see 104 comprised of S1, 106-1, SN and 1060N) is dual-indexed by snapshot names and snapshot timestamps (Demoor, ¶90 “progress through operation log 310 may be indexed by timestamp values and/or key values including timestamp values or inverse timestamp values.”; Figure 1B).
With regard to claim 21 Demoor teaches A non-transitory machine readable medium storing instructions(Demoor, ¶160 “The processor(s) 302 may execute software instructions by performing various input/output, logical, and/or mathematical operations”), which when executed by one or more processors (¶160) of a storage system, cause the storage system as the data store, e.g. key data store 102 (Demoor, ¶42, “Log entries 140 may be stored as a key entry in a key data store as described with regard to FIGS. lA-lC.”; ¶29 “key data store 102,”) to:
maintain a bucket as the group, e.g. bucket with specific ID (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) containing a plurality of objects as the clients object that are grouped together (Id), wherein each of the plurality of objects has one or more object versions(Demoor, ¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time, and allows for the archival of the different versions of the object as they occur over time ( e.g., due to modifications made over time to the object), retrieval of a prior version of the object, and/or recovery from unintended overwrites and/or deletions made to the object.”), wherein a given object as a data instance (¶30 “Further, as shown in FIG. 1A, each key (e.g., DA . . . DN, etc.) can correspond to a data instance (e.g., DA . .. DN).”) of the plurality of objects represents a fundamental unit of data storage as the actual data object stored (¶30 “The data instance may comprise a pointer to a location where the actual object data is stored (e.g., in a separate database, on a physical drive, etc.), or other suitable data values. Each key may correspond to a particular object.”) used by object storage as the shards that stores an ordered subset of object key entries (¶29 “FIG. 1A is a diagram illustrating an example key data store 102, which comprises a plurality of shards S1 ... SN. While two shards S1 and SN are shown, it should be understood that any suitable number of shards may be included. Each shard stores an ordered subset of object key entries.”; ¶34 “an object storage”), and wherein the bucket as the group, e.g. bucket with specific ID (Demoor, ¶33) represents an object-based as the identifier for a group of objects (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related”) storage resource as allocated storage space for the bucket (¶133 “For example, a write operation may allocate storage space to a data object, utilize processing, metadata, or other resources, relate to user, bucket, or system allocations, or have other system impacts that may be defined as properties of the operation”) or container as the logically related group of objects (¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related… In this way, a given client's object keys can be grouped together”) for storing objects (¶29; ¶34);
maintain a snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 “In the foregoing example, the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp”); the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) within a snapshot metafile as the ordered set of object entries, e.g. the log set of entries (Demoor, ¶29 “The subsets 106-1 through 106-N comprise the ordered set of object key entries 104”; ¶31 “In some embodiments, key entries 106-1, 106-N may include a log set of entries that define a log that may be traversed to determine the state of one or more data objects and their properties and/or determine one or more data storage parameters.”; Figure 1A, see 104 comprised of S1, 106-1, SN and 1060N) which may be defined based on one or more properties (¶75 “Entries storing property change values may define a log set of key entries for one or more properties, objects, or other logical grouping of log entries.”) for each snapshot as creating the new entry in the set of object key entries (Demoor, ¶78 “the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp…. This advantageously allows for scalable and flexible versioning of a data object”; the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) of a plurality of snapshots of the bucket as the group, e.g. bucket (Demoor, ¶33), wherein the snapshot entry includes a snapshot identifier (ID) as the prefix 122, which is the bucket identifier (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) and a snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35 “The suffix 126 may comprise a ticket value for ordering different object keys associated with a particular object. The ticket value (also simply called ticket in some embodiments) may be an inverse timestamp.”), wherein a given snapshot of the plurality of snapshots represents a point-in-time reference point (¶30 “Each key may correspond to a particular object. Further, various subsets of object key entries may correspond to the same object at different points in time.”) that preserves a state (¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time”) of the bucket as the group, e.g. bucket (Demoor, ¶33) as of the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35) of the snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 ) for the given snapshot as the key for the particular object (¶30); and
after receiving a request that would result in deletion (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users.”) of a particular version as data object A (Id, ¶41) of the one or more object versions (Demoor, ¶41) of a given object of the plurality of objects as the objects in the group (Demoor, ¶33), prior to deleting the particular version (Demoor, ¶152 “For example, garbage collection may be a dependent process that should allow one or more other prerequisite processes, such as a replication process, to complete”), determine whether as determining if Dependent condition is met (Figure 7, 710) the particular version is protected by one or more snapshots of the plurality of snapshots (Demoor, ¶104 “The foregoing process may protect against mishandling of multiple delete operations”; ¶105 “In some embodiments, the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users”) by comparing (Figure 7, 708; ¶154 “At block 708, the computer system may compare the original timestamp value to a last known progress value for the prerequisite process. For example, on a prior iteration through method 700 for a prior log entry, a progress value for the prerequisite process may have been queried and stored”) one or more time indicators of the particular version as original timestamp values (Id) to the respective snapshot time indicators as last known progress value (Id) of the one or more snapshot entries for the one or more snapshots (Demoor, ¶78).
With regard to claim 26 Demoor teaches A storage system as the data store, e.g. key data store 102 (Demoor, ¶42, “Log entries 140 may be stored as a key entry in a key data store as described with regard to FIGS. lA-lC.”; ¶29 “key data store 102”) comprising:
one or more processing resources(Demoor, ¶160 “processor(s)”); and
instructions that when executed by the one or more processing resources(Demoor, ¶160 “The processor(s) 302 may execute software instructions by performing various input/output, logical, and/or mathematical operations”) cause the storage system to:
maintain a bucket as the group, e.g. bucket with specific ID (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) containing a plurality of objects as the clients object that are grouped together (Id), wherein each of the plurality of objects has one or more object versions(Demoor, ¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time, and allows for the archival of the different versions of the object as they occur over time ( e.g., due to modifications made over time to the object), retrieval of a prior version of the object, and/or recovery from unintended overwrites and/or deletions made to the object.”), wherein a given object as a data instance (¶30 “Further, as shown in FIG. 1A, each key (e.g., DA . . . DN, etc.) can correspond to a data instance (e.g., DA . .. DN).”) of the plurality of objects represents a fundamental unit of data storage as the actual data object stored (¶30 “The data instance may comprise a pointer to a location where the actual object data is stored (e.g., in a separate database, on a physical drive, etc.), or other suitable data values. Each key may correspond to a particular object.”) used by object storage as the shards that stores an ordered subset of object key entries (¶29 “FIG. 1A is a diagram illustrating an example key data store 102, which comprises a plurality of shards S1 ... SN. While two shards S1 and SN are shown, it should be understood that any suitable number of shards may be included. Each shard stores an ordered subset of object key entries.”; ¶34 “an object storage”), and wherein the bucket as the group, e.g. bucket with specific ID (Demoor, ¶33) represents an object-based as the identifier for a group of objects (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related”) storage resource as allocated storage space for the bucket (¶133 “For example, a write operation may allocate storage space to a data object, utilize processing, metadata, or other resources, relate to user, bucket, or system allocations, or have other system impacts that may be defined as properties of the operation”) or container as the logically related group of objects (¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related… In this way, a given client's object keys can be grouped together”) for storing objects (¶29; ¶34);
maintain a snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 “In the foregoing example, the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp”); the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) within a snapshot metafile as the ordered set of object entries, e.g. the log set of entries (Demoor, ¶29 “The subsets 106-1 through 106-N comprise the ordered set of object key entries 104”; ¶31 “In some embodiments, key entries 106-1, 106-N may include a log set of entries that define a log that may be traversed to determine the state of one or more data objects and their properties and/or determine one or more data storage parameters.”; Figure 1A, see 104 comprised of S1, 106-1, SN and 1060N) which may be defined based on one or more properties (¶75 “Entries storing property change values may define a log set of key entries for one or more properties, objects, or other logical grouping of log entries.”) for each snapshot as creating the new entry in the set of object key entries (Demoor, ¶78 “the new entry is situated first for that object (relative to other existing entries) in the ordered set of object key entries since it is the most recent based on the inverse timestamp…. This advantageously allows for scalable and flexible versioning of a data object”; the user saving an updated version (Demoor, ¶57 “a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N,”) of a plurality of snapshots of the bucket as the group, e.g. bucket (Demoor, ¶33), wherein the snapshot entry includes a snapshot identifier (ID) as the prefix 122, which is the bucket identifier (Demoor, ¶33 “The prefix 122 may comprise an identifier for identifying a group of object key entries from the ordered set of object key entries that are logically related. For example, the prefix may include a domain identifier, a bucket identifier, a client identifier, or any suitable combination thereof. In this way, a given client's object keys can be grouped together”) and a snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35 “The suffix 126 may comprise a ticket value for ordering different object keys associated with a particular object. The ticket value (also simply called ticket in some embodiments) may be an inverse timestamp.”), wherein a given snapshot of the plurality of snapshots represents a point-in-time reference point (¶30 “Each key may correspond to a particular object. Further, various subsets of object key entries may correspond to the same object at different points in time.”) that preserves a state (¶41 “Versioning of an object includes the tracking and preservation of more than one version of the object as the object changes over time”) of the bucket as the group, e.g. bucket (Demoor, ¶33) as of the snapshot time indicator as suffix 126, which may include the inverse timestamp (Demoor, ¶35) of the snapshot entry as creating the new entry in the set of object key entries based on timestamp (Demoor, ¶78 ) for the given snapshot as the key for the particular object (¶30); and
after receiving a request that would result in deletion (Demoor, ¶104 “two users may issue delete operations for data object A at times 40 and 41.”; ¶105 “the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users.”) of a particular version as data object A (Id, ¶41) of the one or more object versions (Demoor, ¶41) of a given object of the plurality of objects as the objects in the group (Demoor, ¶33), prior to deleting the particular version (Demoor, ¶152 “For example, garbage collection may be a dependent process that should allow one or more other prerequisite processes, such as a replication process, to complete”), determine whether as determining if Dependent condition is met (Figure 7, 710) the particular version is protected by one or more snapshots of the plurality of snapshots (Demoor, ¶104 “The foregoing process may protect against mishandling of multiple delete operations”; ¶105 “In some embodiments, the foregoing process may also protect against multiple and conflicting write operations, such as write operations for the same object received from two different users”) by comparing (Figure 7, 708; ¶154 “At block 708, the computer system may compare the original timestamp value to a last known progress value for the prerequisite process. For example, on a prior iteration through method 700 for a prior log entry, a progress value for the prerequisite process may have been queried and stored”) one or more time indicators of the particular version as original timestamp values (Id) to the respective snapshot time indicators as last known progress value (Id) of the one or more snapshot entries for the one or more snapshots (Demoor, ¶78).
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 3, 5, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Demoor in view of Arur [2020/0382378].
With regard to claims 3, 5 and 14 Demoor further teaches wherein the snapshot time indicator comprises a timestamp as suffix 126, which may include the inverse timestamp (Demoor, ¶35) and wherein the manual snapshot as the user updating the document and saving a new version (Demoor, ¶57 “For example, a user 204 may update a document using a word processing application and may save the updated version to the server system 220-N, ”) comprises a [[ as suffix 126, which may include the inverse timestamp (Demoor, ¶35) is [[ as the operational timestamp (Demoor, ¶7 “The operation timestamp may be included in the instruction data or may be determined by key data store controller 320 ( e.g., using a clock of the local system, issuing a call to the operating system, etc.).”) of the storage system as the local system (Id).
Demoor does not explicitly teach where the snapshot is a retroactive snapshot in which the timestamp is earlier than a current system time.
Arur teaches wherein the manual snapshot comprises a retroactive snapshot in which the timestamp is earlier than a current system time (¶33 “in another example, the second snapshot may also be a retroactive snapshot of the past state of the network fabric. That is, rather than generating a snapshot representing the current state of the network fabric, the second snapshot can represent the fabric state ten seconds after the event completed (which may be in the past relative to the current time).”).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have used the stored event logs taught by Demoor to generate retroactive snapshots as taught by Aurur as it yields the predictable results of being able to detect events occurring with in the network, which may assist in reboots due to unexpected crashes (Aurur, ¶3).
Response to Arguments
With regard to the objection to the drawings, the objection is hereby withdrawn in view of the amendments to the drawings submitted July 30, 2026
With regard to the 112b rejection of claims 12 and 26 in view of the claim lacking support for 112f limitation. The claimed ‘processors’ have been identified as structural elements and therefore the claims no longer invoke 112f. The 112b rejection is hereby withdrawn.
Applicant's arguments filed July 30, 2026 have been fully considered but they are not persuasive. All the arguments regarding the newly added limitations are addressed in the above rejections.
With regard to Claim 1, applicant argues that Demoor does not teach creating a bucket-level snapshot by adding a snapshot entry to a snapshot metafile. Applicant argues there is no reference to a “snapshot” in Demoor.
In response, one of ordinary skill in the art would recognize the timestamp denotation added to the entries as taught by Demoor as a ‘snapshot’ of the entry. Please see the claim mapping above regarding the amended claim limitations.
With regard to claim 1, applicant argues that Demoor’s cited structures are operation-log structures for object key entries, not bucket-snapshot structures.
The ‘structures’ apparently being discussed are the claimed ‘snapshot time indicator’ and ‘snapshot metafile’. In response to the preceding argument is should be noted that the log set of entries (mapped to the snapshot metafile) are a list of key-entries, which are in and of themselves made up of the Prefix (identifying the bucket, see ¶33), the object ID that identifies the object (see ¶34) and the suffix which includes the timestamp (see, ¶35). As such, the log set of entries is build based on both the bucket ID and the timestamp for the particular entries. The particular log set may be defined based on any of the properties, See ¶75 (e.g. based on the Bucket ID and timestamp for example).
With regard to claim 1, applicant argues that Demoor’s operations are entry based, not bucket-snapshot structures.
In response, each entry has both a bucket ID and a timestamp associated with it as detailed in the claim mapping above. One the entry is added, it is not modified, and the status of the entry is preserved (See, ¶41). This means that the particular association of the entry with the particular prefix (e.g. bucket ID) and suffix (e.g. timestamp) is not changed. The listing of entities for that particular prefix/suffix combination remains in a preserved state such that when retrieval operations occur, based on the particular prefix/suffix the result remains the same. Once a particular point in time has changed, no new entries may be added to that particular bucket with that particular timestamp. Therefore, the state of the bucket as of the snapshot time is preserved.
The claims do not limit the bucket to only including a single snapshot. The claims define the bucket as a representing an object-based storage resource or container for storing object’. There is no description regarding how the objects are determined to be in a particular bucket (e.g. there is no requirement that all the object in a single bucket have a single timestamp). It is suggested that the claims be amended to clarify the relationship between the bucket and the snapshot/point-in-time reference point for the objects within the bucket.
With regard to claim 1, applicant argues that the protecting features taught by Demoor are operation-log safeguards. Specifically, applicant argues that the recited protection features depend on the snapshot construction, and protects the object versions that exist at the point in time indicated by the snapshot.
In response, the claim does not preclude operation-log safeguards. The claim language does not define what “protecting” includes. Merley that the system protects the one or more object versions at that particular point in time. It is suggested that the claim be amended to specify what protecting includes instead of only reciting what is being protected. The claims do not require preserving the contents of the bucket, only that the object versions of the respective objects at that point in time are ‘protected’.
With regard to claim 2, applicant argues that the user initiating a storage operation is not the same as the user specifying a snapshot time indicator for a manual snapshot.
In response, One of ordinary skill in the art would recognize data saved at a particular time is a snapshot of data at said particular time. Thus, when the user manually initiates to save a new version of data at a given time, the saved file is a ‘snapshot’ of that new version at that particular time. Within the instant specification, the ’time indicator’ are described as being the ‘creation time’ and ‘deletion time (See Paragraph [62], and are described as being absolute timestamps (¶65). Which one of ordinary skill in the art would recognize as the timestamp that the system logs for the operation, such as what is described above when the user manually saves a file. As detailed in Demoor 76 upon the execution of the operation, the system generates “a new key for a new log entry” to log the newly saved operation with its own timestamp entry.
Applicant asserts that Demoor’s suffix/inverse timestamp is a ticket value for ordering different object keys associated with a particular object, and does not disclose a snapshot time indicator. In response, one of ordinary skill in the art would recognize the entry log with the suffix/inverse timestamp is a snapshot time indicator for the operation.
With regard to claim 4, applicant argues that the ‘shards’ of Demoor are not inodes. Applicant argues that the term ‘inode’ is defined in the specification as “a file-system data structure that stores metadata for a data container, including an object”.
In response, The quotation for the ‘definition’ of the term inode appears to be from paragraph [0045] of the instant specification which recites in full: “As used herein, an "index node" or "inode" generally refers to a file data structure maintained by a file system that stores metadata for data containers (e.g., directories, subdirectories, files, objects, etc.).”. It should be noted that this is not an explicitly definition as it is recited as “generally refers to”. Which one of ordinary skill in the art may reasonable read as reciting examples, not an explicit definition. Furthermore, the ‘shards’ where not mapped to the claimed inodes as applicant argues. The claimed inodes were mapped to the metadata entry int eh log entry, indexed by timestamp and other information (See, ¶49; ¶84; ¶89). One of ordinary skill in the art would recognize the metadata log entries as “stored metadata” that is maintained by the file system for the “containers” (e.g. the information regarding the Prefix group ID). Based on the example of ‘inode’ described in Paragraph [0045] one of ordinary skill in the art would recognize the metadata entry in the log entry as being a ‘inode’.
Applicant argues that Demoor’s ‘shards’ are not metadata structures. This is agreed. The claim mapping for the inode is not to the ‘shards’ but is to the metadata log entries. Applicant’s arguments does not address the claim mapping put forth.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 AMANDA WILLIS whose telephone number is (571)270-7691. The examiner can normally be reached Monday-Friday 8am-2pm.
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.
/AMANDA L WILLIS/ Primary Examiner, Art Unit 2156
