DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/24/2026 has been entered.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 10, 12, 14-20 are amended.
Claims 1, 10, and 17 are independent claims.
Claims 1-20 are pending in this application.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-11, 14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Verbitski et al., US Patent No. 12,292,881 (hereinafter as “Verbitski”) in view of Danilov et al., US Pub. No. 2022/0374417 A1 (hereinafter as “Danilov”) and Shilane et al., US Pub. No. 2020/0019629 A1 (hereinafter as “Shilane”), and further in view of Colenbrander, US Pub. No. 2022/0001279 A1 (hereinafter as “Colenbrander”),.
Regarding independent claim 1, Verbitski teaches: a method, comprising:
based on first application data (col. 15, lines 47-51, e.g., “the API calls” and “APIs 521-529” which are interpreted as the application data), initiating, by a system comprising at least one processor, a multipart cloud storage transaction (col. 21, lines 58-62: e.g., “Query engine 1312 may receive start transaction 1342 indication and then begin receiving transaction statements 1342. Query engine 1312 may obtain a transaction start time 1344 from time sync service agent 1314”, wherein the “start transaction” is interpreted as the initiating transaction; and col. 4, line 29, e.g., “provide one or more services (such as various types of cloud-based storage)”) with a data lake implemented on cloud storage server that enables services associated with a cloud service provider (col. 4, lines 41-43, e.g., “provider network can be formed as a number of regions, where a region is a separate geographical area in which the cloud provider clusters data centers…”, and col. 24, lines 16-19, e.g., “an object-based storage service, data-lake storage service, or other type of storage that may be implemented on one of other service(s) 230”).
Vebitski teaches loading the table slice=chunk/segment/block to the table slice group, then to the volume slice group, and shard into the database storage (see Fig. 10; and col. 18, lines 49-67 to col. 19, lines 1-67), and the commit transaction based on the initiated transaction (see Fig. 13).
However, Vebitski does not explicitly teach: “wherein the multipart cloud storage transaction comprises a chunk of data comprising a stream-oriented storage abstraction that facilitates append, read, and truncate operations and interfaces with object storage resources;” and “based on the first application data, facilitating, by the system, communicating a first data part of the chunk to the cloud storage server; and based on second application data, facilitating, by the system, communicating a second data part of the chunk to the cloud storage server” and “wherein the first data part and the second data part are, as generated, stored in a commit buffer, and wherein a first chunk offset of the first data part and a second chunk offset of the second data part are stored in metadata;” and “based on a size of the chunk, facilitating, by the system, communicating a commit signal to commit the cloud storage transaction.”
In the same field of endeavor (i.e., data processing in the cloud storage), Danilov teaches the amended limitations:
“wherein the multipart cloud storage transaction comprises a chunk of data comprising a stream-oriented storage abstraction that facilitates append, read, and truncate operations and interfaces with object storage resources.” (see par. [0001] e.g., “storage abstraction referred to as a data stream, or more simply, a stream… a stream comprises a durable, elastic, append-only, sequence of stored events….”; par. [0128] e.g., “the cloud storage systems and the storage interface”; see further in Fig. 1 and, Figs. 5-6 via append, read/access, truncate (or delete/remove) operations, par. [0070] e.g., “truncates” the segment(s)/chunk(s)), and pars. [0022], [0023] “a streaming application program sends data writes comprising events 110 into the streaming data storage system 100 via an application programming interface (API) of a client component 112 in one implementation. As described herein, an event 110 comprises a routing key and the event data (payload). Also shown in FIG. 1 is a reader 114 or reader group (organized multiple readers that coordinate reading a data stream's segments) that consume and process the stored events in some way”, [0033] teaches/discloses “stream truncation”, [0054] teaches “each chunk of stream data stored to Tier-2, …”; and pars. [0092] “Part of the source segments can be maintained in a data chunk, and further operations can comprise determining a data chunk expiration time, evaluating the data chunk expiration time relative to a current time, and in response to determining that the data chunk expiration time is prior to the current time, determining that the data chunk contains no unexpired log events, and deleting the chunk as part of deleting the source segments. Determining the data chunk expiration time can comprise obtaining system metadata corresponding to a most recent creation time among log events in the data chunk, and determining a longest expiration period among the log events in the data chunk. Determining the longest expiration period among the log events in the data chunk can comprise maintaining a dataset comprising distinct logging levels of the log events in the chunk”, [0093-95], and [0102]); and
“wherein a first chunk offset of the first data part and a second chunk offset of the second data part are stored in metadata” (see pars. [0070] e.g., “truncated at offset Ci+1.StartOffset; this means “delete the chunk Ci”…”, [0072] “the remaining chunks that are part of the currently selected segment Si, which is part of the data stream S, operation 902 creates a new destination chunk corresponding to the currently selected chunk, that is, the currently selected chunk is the “source” chunk (note that the current chunk is already selected, e.g., via operation 812 of FIG. 8). Via operations 904, 914, and 916, for each event E in the source chunk Cj (with E.OldSegmentOffset being the event E's current segment offset)…”; and pars. [0059] “the segment’s metadata”, [0063] “the segment store also updates the chunk C's metadata at operations 610 and 612. Operations 608, 610 and 612 can be atomic operations. This metadata updating includes maintaining, via operation 610, the chunk's most recent time as the maximum of the existing most recent time for chunk or the segment's most recent time”, [0065] e.g., “the data stream metadata”, and [0092] “Determining the data chunk expiration time can comprise obtaining system metadata corresponding to a most recent creation time among log events in the data chunk, and determining a longest expiration period among the log events in the data chunk…”)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Danilov would have provided Verbitski with the above amended limitation allowing a skill artisan in motivation to facilitate the chunk of data (par. [0054, 70]) comprising a stream-oriented storage abstract for append, read, and truncate operations (pars. [0001, 33, 54, 70, 92-95, and 102]) and interface (pars. [0023, and 128]) to store streaming data chunks with the updated metadata in a cloud storage system.
Vebitski clearly teaches loading/storing the table slice=chunk/segment/block to the table slice group, then to the volume slice group, and shard into the database storage (see Fig. 10; and col. 18, lines 49-67 to col. 19, lines 1-67), and the commit transaction based on the initiated transaction (see Fig. 13). Danilov teaches the streaming data cloud storage system with the chunks/segments, storage abstraction that facilitate append, read/write, and truncate operations and interfaces, e.g., API, storage interface(s) (pars. [0001, 23, 33, 54, 70, 92-95, 102, 128]).
However, Vebitski and Danilov do not explicitly teach: “based on the first application data, facilitating, by the system, communicating a first data part of the chunk to the cloud storage server; and based on second application data, facilitating, by the system, communicating a second data part of the chunk to the cloud storage server”, “wherein the first data part and the second data part are, as generated, stored in a commit buffer;” and “based on a size of the chunk, facilitating, by the system, communicating a commit signal to commit the cloud storage transaction.”
In the same field of endeavor (i.e., data processing), Shilane teaches:
based on the first application data (Fig. 1, element 202 via Apps), facilitating, by the system, communicating a first data part of the chunk to the cloud storage server (Fig. 1, and pars. [0070-72] such that the slice identifiers are interpreted as the data parts of the chunks specify one or more slice recipes stored in the persistent storage in the cloud server; and pars. [0050] “ the frontend micro-services 316 may be micro-services executing on a cloud platform. The frontend micro-services 316 may also obtain requests for data stored in the persistent storage 350” and [0119] “… non-transitory storage media also embraces cloud-based storage systems and structures, although the scope of the invention is not limited to these examples of non-transitory storage media”).
based on second application data (Fig. 1, element 202 via Apps), facilitating, by the system, communicating a second data part of the chunk to the cloud storage server (Fig. 1, and Figs. 2C and 3A-3C should contain plurality data part of slices/chunks; and also in pars. [0070-72])
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Shilane would have provided Verbitski and Danilov with the above indicated limitation allowing a skill artisan in motivation to perform loading/communicating/transmitting the data parts of chunks to the storage at cloud server/system (Shilane: Figs. 1-2, and pars. [0042 and 49-50]).
Verbitski, Danilov, and Shilane do not explicitly teach: “wherein the first data part and the second data part are, as generated, stored in a commit buffer”, and “based on a size of the chunk, facilitating, by the system, communicating a commit signal to commit the cloud storage transaction.”
In the same field of endeavor (i.e., data processing and archiving), Colenbrander teaches:
wherein the first data part and the second data part are, as generated, stored in a commit buffer (par. [0041] e.g., “when the cloud gaming server 103-1 to 103-N calls the commit API, the cloud gaming server 103-1 to 103-N allows the management server 105-1 to 105-X to also commit its buffer changes back to the cloud storage server 109”, and par. [0047] “split data into multiple data chunks for placement into respective locations in a computer memory 337 of the cloud gaming server 103-1”), and
based on a size of the chunk (par. [0040] e.g., “a transaction data buffer can be provided by either the video game or the cloud gaming system 103-1 to 103-N. In some embodiments, the transaction data buffer is in RAM. In some embodiments, the cloud gaming system 103-1 to 103-N has the video game provide the transaction buffer because the transaction buffer is small in size”, and par. [0047] e.g., multiple data chunks), facilitating, by the system, communicating a commit signal to commit the multipart cloud storage transaction (par. [0041] e.g., “when the cloud gaming server 103-1 to 103-N calls the commit API, the cloud gaming server 103-1 to 103-N allows the management server 105-1 to 105-X to also commit its buffer changes back to the cloud storage server 109” which teaches commit signal communication; and par. [0042] “the cloud storage server 109 is configured to support transactions. In these embodiments, upon mount by the management server 105-1 to 105-X, the cloud server 109 tracks data changes.”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Colenbrander would have provided Verbitski, Danilov, and Shilane with the above indicated limitation allowing a skill artisan in motivation to perform storing data parts of chunk based on the chunk size in the committed buffer in the local storage (Colenbrander: Figs. 1-2, and pars. [0039-42]).
Regarding claim 2, Colenbrander teaches: “wherein the commit buffer is comprised in local, volatile storage.” (par. [0033] e.g., “RAM” as known as the local, volatile memory/storage, par. [0039] “write to RAM only”, and par. [0041] e.g., “commit of buffer”)
Regarding claim 3, Danilov and Colenbrander, in combination, teach: wherein the commit signal is communicated to result in (Colenbrander: par. [0041] e.g., “when the cloud gaming server 103-1 to 103-N calls the commit API, the cloud gaming server 103-1 to 103-N allows the management server 105-1 to 105-X to also commit its buffer changes back to the cloud storage server 109” which teaches commit signal): the first data part and the second data part being combined, resulting in combined data parts (Danilov: Fig. 5, element 512 via “Union” technique is interpreted as combined data parts; par [0066] “Operation 702 evaluates whether it is time to run the expiration logic on the stream, e.g., if the S.LastRun time metadata plus the S.RunFrequency value in policy/metadata is greater than the current time, abort (do not do anything). Otherwise, the expiration logic runs, using the data stream's logging levels (S.LoggingLevels) as defined for the stream”), and the combined data parts being stored as a data object in the cloud storage server, resulting in a stored data object (Danilov: pars. [0022] “a streaming data storage system 100 that includes a segment store 102 that maintains and manages segments 104(1)-104(n) of at least part of a data stream 106. Note that the segments 104(1)-104(n) can be distributed among segment store instances, such as distributed among different nodes of a node cluster”, wherein the cluster is interpreted as the data object, and [0024 and 27]).
Regarding claim 4, Shilane, Danilov, and Colenbrander, in combination, teach:
after the commit signal is communicated, facilitating, by the system, receiving a request to retrieve the second application data (Colenbrander: par. [0032] such that the ““mount” API call” interpreted as the request to retrieve technique; and Abstract);
based on the metadata (Danilov: see pars. [0063] “the segment store also updates the chunk C's metadata at operations 610 and 612. Operations 608, 610, and 612 can be atomic operations. This metadata updating includes maintaining, via operation 610, the chunk's most recent time as the maximum of the existing most recent time for chunk or the segment's most recent time”, [0065] e.g., “the data stream metadata”, and [0092] “Determining the data chunk expiration time can comprise obtaining system metadata corresponding to a most recent creation time among log events in the data chunk”; and Colenbrander: par [0045] disclosed “metadata”):
identifying, by the system, that the stored data object contains the second application data (Shilane: Fig. 1, element 202, Figs. 12A-2D, par. [0064] e.g. “identifies a group of slices that each include similar but unique data or include identical data”), and based on the second chunk offset, identifying, by the system, an object offset corresponding to the second application data stored in the stored data object (Danilov: pars. [0070] e.g., “truncated at offset Ci+1.StartOffset; this means “delete the chunk Ci”…”, [0072] “the remaining chunks that are part of the currently selected segment Si, which is part of the data stream S, operation 902 creates a new destination chunk corresponding to the currently selected chunk, that is, the currently selected chunk is the “source” chunk (note that the current chunk is already selected, e.g., via operation 812 of FIG. 8). Via operations 904, 914, and 916, for each event E in the source chunk Cj (with E.OldSegmentOffset being the event E's current segment offset)…”); and
retrieving the second application data from the stored data object, wherein the second application data was identified for retrieval based on the object offset of the second application data (Shilane: Fig. 1, element 202, Figs. 12A-2D, par. [0064] e.g. “identifies a group of slices that each include similar but unique data or include identical data”, and pars. [0070-72]; and Danilov: pars. [0070] e.g., “truncated at offset Ci+1.StartOffset; this means “delete the chunk Ci”…”, [0072] “the remaining chunks that are part of the currently selected segment Si, which is part of the data stream S, operation 902 creates a new destination chunk corresponding to the currently selected chunk, that is, the currently selected chunk is the “source” chunk (note that the current chunk is already selected, e.g., via operation 812 of FIG. 8). Via operations 904, 914, and 916, for each event E in the source chunk Cj (with E.OldSegmentOffset being the event E's current segment offset)…”).
Regarding claim 5, Shilane teaches: “wherein the stored data object is immutable” (Fig. 1, element 350, Persistent Storage which is used to store data object that is immutable, see in par. [0034] “Once the first version is stored in a persistent storage, the versions of the large word document subsequently stored will be deduplicated before being stored in the persistent storage resulting in much less storage space of the persistent storage being required to store the subsequently stored versions when compared to the amount of storage space of the persistent storage required to store the first stored version”, and par. [0043]).
Regarding claim 6, Shilane and Danilov, in combination, teach: “wherein the size of the chunk was selected based on a data retrieval constraint of an application that generated the first application data and the second application data.” (Shilane: par. [0035] e.g., “a size of about 20 bytes”, “segments may be about 8KB in size”; and Danilov: par. [0049] e.g., “A segment's event data 440 is moved from Tier-1 storage to Tier-2 storage, e.g., based on size-based and/or time-based policy”; and par. [0056] implemented in “a resultant segment 452d (where “d” represents destination) after scanning; there can be different resultant segments based routing keys. One or more chunks can be eliminated as described above without reading the data, whereby the number of Tier-2 destination chunks 461 is often less than the number of Tier-2 source chunks 441.” and “the size of the resultant”)
Regarding claim 7, Shilane teaches: “wherein the first data part and the second data part are communicated as generated without implicating local non-volatile storage.” (Fig. 1, and pars. [0042-44])
Regarding claim 8, Colenbrander teaches:
before the commit signal is communicated, facilitating, by the system, receiving a request to retrieve the second application data (pars. [0039], and [0041]), and [0052] teaches “requested data being retrieved from a data storage device and …”); and
in response to receiving the request, retrieving, by the system, the second application data from the second data part stored in the commit buffer (pars. [0039] such that retrieving data stored in commit buffer of RAM, par. [0033] e.g., “RAM” as known as the local, volatile memory/storage, par. [0041] e.g., “commit of buffer”).
Regarding claim 9, Shilane teaches: wherein the first data part and the second data part comprise a stream of application data (Fig. 1, element 202; and par. [0032] “data stream segmentation processes, data chunks, data blocks, atomic data, emails, objects of any type, files, contacts, directories, sub-directories, volumes, and any group of one or more of the foregoing”).
Regarding independent claim 10, in the same endeavor (i.e., data processing), Verbitski, Danilov, Shilane, Colenbrander, in combination, teach:
cloud storage equipment (Verbitski: col. 4, lines 22-67 via the cloud provider clusters data centers and different types of cloud-based storage=cloud storage equipment; and Shilane: see pars. [0027 and 33] disclosed at least one cloud storage equipment), comprising:
at least one processing unit (Verbitski: see Fig. 22; and Shilane: see Fig. 4); and
at least one memory coupled to the at least one processing unit (Verbitski: see again in Fig. 22, element 3010a-n, and element 3020; and Shilane: again Fig. 4) and storing instructions configured to be executed by the at least one processing unit, wherein the instructions, when executed by the at least one processing unit (Shilane: par. [0048] “The non-transitory storage may include instructions which, when executed by the one or more processors, enable the physical device to perform the functions”), cause the cloud storage equipment to perform actions comprising:
based on a request from stream storage equipment implementing a data lake (Verbitski: col. 24, line 15-18: “Backup storage 1610 may be a separate storage service, in some embodiments, such as an object-based storage service, data-lake storage service, or other type of storage that may be implemented on one of other service(s) 230”), generating a multipart transaction (Verbitski: see Fig. 7, element 344, and Fig. 18, element 1810; and Shilane: pars. [0083] “the object name when generating an object recipe name”, par. [0093-94], e.g., “transaction ID” in object storage),
receiving, from the stream storage equipment, a first data chunk and a second data chunk allocated to the multipart transaction (Verbitski: Figs. 7 and 10 such that the slices=chunks; and Shilane: see Figs. 3A-3C, par. [0032] “data segments such as may be produced by data stream segmentation processes, data chunks, data blocks, atomic data, emails, objects of any type, files, contacts, directories, sub-directories, volumes, and any group of one or more of the foregoing”, and pars. [0093-94] via “transaction ID”), wherein the stream storage equipment has retained a copy of the first data chunk and the second data chunk in volatile storage (Shilane: see pars. [0032-33] via “data stream segmentation processes”, and “clones, snapshots, any other type of copies of data”, Fig. 4 discloses the volatile storage), wherein the first data chunk comprising a stream-oriented storage abstraction that facilitates append, read, and truncate operations and interfaces with object storage resources.” (Danilov: par. [0001] e.g., “storage abstraction referred to as a data stream, or more simply, a stream… a stream comprises a durable, elastic, append-only, sequence of stored events….”; par. [0128] e.g., “the cloud storage systems and the storage interface”; see further in Fig. 1 and, Figs. 5-6 via append, read/access, truncate (or delete/remove) operations, par. [0070] e.g., “truncates” the segment(s)/chunk(s)), and pars. [0022], [0023] “a streaming application program sends data writes comprising events 110 into the streaming data storage system 100 via an application programming interface (API) of a client component 112 in one implementation. As described herein, an event 110 comprises a routing key and the event data (payload). Also shown in FIG. 1 is a reader 114 or reader group (organized multiple readers that coordinate reading a data stream's segments) that consume and process the stored events in some way”, [0033] teaches/discloses “stream truncation”, [0054] teaches “each chunk of stream data stored to Tier-2, …”; and pars. [0092] “Part of the source segments can be maintained in a data chunk, and further operations can comprise determining a data chunk expiration time, evaluating the data chunk expiration time relative to a current time, and in response to determining that the data chunk expiration time is prior to the current time, determining that the data chunk contains no unexpired log events, and deleting the chunk as part of deleting the source segments. Determining the data chunk expiration time can comprise obtaining system metadata corresponding to a most recent creation time among log events in the data chunk, and determining a longest expiration period among the log events in the data chunk. Determining the longest expiration period among the log events in the data chunk can comprise maintaining a dataset comprising distinct logging levels of the log events in the chunk”, [0093-95], and [0102]);
based on an instruction from the stream storage equipment to commit the multipart transaction, aggregating the first data chunk and the second data chunk into a data object of the data object storage resources (Danilov: pars. [0022, 24, and 27] via “node cluster” = data object comprises the group of data chunks; and Verbitski: see Fig. 10 via slices groups, volume groups and shards and cloud database storages, which teaches the technique of “aggregating”; and Colenbrander: pars. [0065] “the particular grouping of data is a data object, a data file, or a data block.”, [0066] via “a commit API call” functionality, and [0069-70]), wherein the stream storage equipment stored, as metadata, offset information describing placement of the first data chunk and the second data chunk within the data object storage resources (Danilov: Fig. 8, elements 806, 808, 810, and 812 for replacing the existing chunk having expiration metadata with the current/new chunk via truncate operation; pars [0059, 63 and 65] e.g., metadata of chunk(s);, and [0070, and 72] e.g., “Offset” of segments/chunks; and Verbitski: Fig. 11 at element 345 as the placement management, and col. 29, lines 1-35 teaches placement of the table slices=blocks within the database objects, see Fig. 10; and Danilov: pars. [0028] “…The storage location metadata maintained by the chunkstore module can include any or some combination of the following: an offset, a storage address, a block number, and so forth”, [0049] e.g., “the given data object is subsequently modified (e.g., overwritten, replaced, etc.), subsequent version(s) of the given data object is (are) generated…, and [0050-51]).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of Verbitski, Danilov, Shilane, and Colenbrander, as explained the above indicated limitations which allow a skill artisan in motivation to perform the streaming the data segments/chunks/slices to store in cloud storage(s) server/system for future accessing purpose.
Regarding claim 11, Verbitski, Danilov, Shilane, and Colenbrander, in combination, teach: “storing the data object, resulting in a stored data object” (Verbitski: see Figs. 10-11; and Shilane: pars. [0091-92]; Danilov: fig. 16; and Colenbrander: par. [0065] “the particular grouping of data is a data object, a data file, or a data block. In some embodiments, the particular grouping of data is a save data disk image for the video game that includes save data for the user's play of the video game”).
Regarding claim 14, Verbitski, Danilov, Shilane, and Colenbrander, in combination, teach:
wherein the first data chunk and the second data chunk were grouped into a storage group that corresponds to the multipart transaction (Verbitski: see again in Fig. 10 in the groups of slices, volumes; Danilov: Fig. 1 and pars. [0022, 24, and 27] via “node cluster”; and Shilane: see in Figs. 2A-D, and pars. [0021-22] via “a similarity group” storing in object storage including “transaction ID”, and [0090-92]; and Colenbrander: par. [0065] “the particular grouping of data is a data object, a data file, or a data block. In some embodiments, the particular grouping of data is a save data disk image for the video game that includes save data for the user's play of the video game”)
wherein the metadata comprises group offset information that corresponds to group offset data for the first data chunk and the second data chunk allocated to the multipart transaction (Danilov: Figs. 8-9, and pars. [0070 and 72] via “offset” of segments/chunks; and Shilane: par. [0068] e.g., “an offset” from the “region, a bit sequence, a name or other types of data”; and Colenbrander: par. [0065] “the particular grouping of data is a data object, a data file, or a data block. In some embodiments, the particular grouping of data is a save data disk image for the video game that includes save data for the user's play of the video game”).
Regarding claim 16, Danilov, and Shilane teach: “wherein the first data chunk and the second data chunk comprise a stream of application data.” (Danilov: see Fig. 1, wherein the automated program(s) is/are equal to application data, and element 102, 106, and pars. [0055-56] via a chunk of stream (segment); and Shilane: Fig. 1, element 202; par. [0028] “data stream segmentation processes, data chunks, data blocks, atomic data, emails, objects of any type, files, contacts, directories, sub-directories, volumes, and any group of one or more of the foregoing”)
Regarding independent claim 17, the claim is rejected by the same reasons set forth above to claim 1. Furthermore, Verbitski, Danilov, Shilane, and Colenbrander, in combination, teach: a computer program product, tangibly stored on a non-transitory computer-readable medium and comprising machine-executable instructions, wherein the machine-executable instructions, when executed, cause a data chunk stream storage device to perform operations (Verbitski: see col. 35, lines 1-25; and Shilane: see par. [0119]), comprising:
receiving a part of a data chunk stream linked to a multipart cloud storage transaction with a data lake implemented on cloud storage server corresponding to a cloud service provider (Verbitski: Fig. 10, Fig. 13, and col. 4, lines 41-67 via the cloud provider clusters in data centers/data lake(s), and col. 24, lines 17-19; and Shilane: see Abstract: “receiving a write request that includes a data structure version to be written, wherein the data structure version is associated with a unique identifier, storing the data structure version in association with the unique identifier, receiving a read request for a most recent version of the data structure…”, pars. [0020-22], and [0028] discloses at least “a cloud provider”), wherein a data chunk comprising a stream-oriented storage abstraction that facilitates append, read, and truncate operations and interfaces with object storage resources.” (Danilov: par. [0001] e.g., “storage abstraction referred to as a data stream, or more simply, a stream… a stream comprises a durable, elastic, append-only, sequence of stored events….”; par. [0128] e.g., “the cloud storage systems and the storage interface”; see further in Fig. 1 and, Figs. 5-6 via append, read/access, truncate (or delete/remove) operations, par. [0070] e.g., “truncates” the segment(s)/chunk(s)), and pars. [0022], [0023] “a streaming application program sends data writes comprising events 110 into the streaming data storage system 100 via an application programming interface (API) of a client component 112 in one implementation. As described herein, an event 110 comprises a routing key and the event data (payload). Also shown in FIG. 1 is a reader 114 or reader group (organized multiple readers that coordinate reading a data stream's segments) that consume and process the stored events in some way”, [0033] teaches/discloses “stream truncation”, [0054] teaches “each chunk of stream data stored to Tier-2, …”; and pars. [0092] “Part of the source segments can be maintained in a data chunk, and further operations can comprise determining a data chunk expiration time, evaluating the data chunk expiration time relative to a current time, and in response to determining that the data chunk expiration time is prior to the current time, determining that the data chunk contains no unexpired log events, and deleting the chunk as part of deleting the source segments. Determining the data chunk expiration time can comprise obtaining system metadata corresponding to a most recent creation time among log events in the data chunk, and determining a longest expiration period among the log events in the data chunk. Determining the longest expiration period among the log events in the data chunk can comprise maintaining a dataset comprising distinct logging levels of the log events in the chunk”, [0093-95], and [0102]);
storing, in a part buffer, the part of data chunk stream received (Colenbrander: pars. [0004] “The data access request identifies requested data stored in the data storage device within the cloud storage server.”, [0039] “ the cloud storage server 109 are collectively configured to handle use of transactions for storage access”, and [0040] via a transaction data buffer);
identifying that the multipart cloud storage transaction is not committed, and comprises another part of the data chunk stream, other than the part of the data chunk stream, that was previously included in the multipart cloud storage transaction (Colenbrander: pars. [0039] teaches that the “transactions” and “The unmount API is an “implicit commit””, which is interpreted as the “not committed”, [0040] via “a transaction data buffer” is interpreted as another part of stream, and [0060] “With use of transactions, the commit API will flush any changes in data back to the cloud storage system 390 from the management server 105-1 to 105-X”);
appending the part of the data chunk stream to an end of the other part of the stream (Verbitski: see Figs. 10 and 13; and Shilane: see Fig. 3A-3C and par. [0054-55] via “queues” including “queue slices of data”, e.g.,”… first in first out queues. The queues of the request queues 320 may be other types of queues without departing from the invention. For example, the queues may be configured to prioritize certain slices for processing by the backend micro-services 314 over other slices. For example, certain slices may be moved to the front of the queue based on a type, quality, or meta-data associated with the slices” teaches the appending part of request queue/stream); and
storing metadata comprising an offset value corresponding to an offset of the part of the data chunk stream, from a beginning of the cloud storage transaction (Devadas: par. [0028] e.g., “A data object can be divided into a collection of data chunks (a single data chunk or multiple data chunks). Each data chunk has a specified size (a static size or a size that can dynamically change). The storage locations of the data chunks are storage locations in the shared storage system 104. The storage location metadata maintained by the chunkstore module can include any or some combination of the following: an offset, a storage address, a block number, and so forth.”)
Accordingly, in the same field of endeavor (i.e., data processing), it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of Verbitski, Shilane, Colenbrander, and Devadas with the above indicated limitations for allowing a skill artisan in motivation to perform storing the chunks in location metadata of the cloud storage efficient for future data access purpose.
Regarding claim 18, Shilane, Colenbrander, and Devadas, in combination, teach: “based on a total size of the part of the data chunk stream and the other part of the data chunk stream, committing the cloud storage transaction to be stored via storage equipment corresponding to the cloud service provider” (Shilane: pars. [0028] discloses “a cloud provider”, [0035] “The slices, in turn, are subdivided into segments. In at least one implementation, these segments are approximately 8 KB, with the segment boundary selected in a content-defined manner that tends to produce consistent segments”, and [0055]; Colenbrander: see pars. [0016-17] via stream data, [0030] via “a few megabytes (MB) in size”, [0040] “the cloud gaming system 103-1 to 103-N has the video game provide the transaction buffer because the transaction buffer is small in size”, and [0066-67] via complete/commit transaction to the cloud storage server (as shown in Fig. 1, wherein the cloud storage server is interpreted as the cloud service provider)).
Regarding claim 19, Colenbrander and Devadas, in combination, teach: wherein the instructions further comprise:
receiving, by the system, a request to retrieve the other part of the data chunk stream (Devadas: par. [0090] e.g., “a data read to retrieve the subject data object. If the response information from the data virtual processor 114-N includes the list of storage locations, then the chunkstore module 118-1 of the source virtual processor 114-1 can read the data chunks from the storage locations of the shared storage system 104”, wherein the information of data chunks are shown in Fig. 2A-2B. Since the claim does not require any particular “other part of the stream”; thus, the information of data chunks, e.g., key/value, storage location information, chunk ID, etc. should be matched as broadest reasonable interpretation. See MPEP 2111);
responsive to the request, retrieving, by the system, the other part of the data chunk stream from the other part of the data chunk stream stored in the part buffer (Colenbrander: par. [0040-41] teaches buffer; Devadas: par. [0018] “a read request (e.g., a get request to retrieve a data object from the shared storage system)”, and par. [0090] “a data read to retrieve the subject data object. If the response information from the data virtual processor 114-N includes the list of storage locations, then the chunkstore module 118-1 of the source virtual processor 114-1 can read the data chunks from the storage locations of the shared storage system 104”); and
after the retrieving, sending a commit signal to commit the cloud storage transaction (Colenbrander: pars. [0039-41] teaches complete/commit data indicates for transaction flush data into the cloud storage).
Regarding claim 20, Colenbrander teaches: wherein the part buffer is comprised in volatile storage that is local to the stream storage device (see par. [0040] e.g., “the transaction data buffer is in RAM”).
Claims 12-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Verbitski, Danilov, Shilane, Colenbrander, and further in view of Paduroiu et al., US Pub. No. 2022/0113871 A1 (hereinafter as “Paduroiu”).
Regarding claim 12, the claim rejected by the same reasons set forth above to claim 10. However, Verbitski, Danilov, Shilane, Colenbrander do not explicitly teach: “identifying a data object offset value” after the multipart transaction is committed.
In the same field of endeavor (i.e., data processing), Paduroiu teaches:
after the multipart transaction is committed, identifying a data object offset value that corresponds to the second block of data stored in the data object (see par. [0006] teaches the distributed transactions that applied to the segments, and the transaction only become available=after for reading/accessing once the transaction is “committed”; par. [0060] e.g., “obtaining a stream cut comprising identifiers for respective segments of the data stream and offset values representing lengths of the respective segments”); and
based on the data object offset value, determining a storage location of the second block of data within the data object (pars. [0038] via “the target offset location”, and [0060] via “offset value” and “in response to determining that the current lengths of the replicated segments are greater than or equal to the offset values in the stream cut, updating target offset data of the replicated segments to match the offset values in the stream cut, resulting in updated target offset data (operation 1110), and allowing reading of the streamed data from the replicated segments up to locations in the replicated segments represented by the updated target offset data”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Paduroiu would have provided Verbitski, Danilov, Shilane, Colenbrander with the above indicated limitation allowing a skill artisan in motivation to perform storing data stream based on offset values to allocate the chunks/segments storage efficiently (Paduroiu: Figs. 6-10, and pars. [0006, 24-26, and 60]).
Regarding claim 13, the claim is rejected by the same reasons set forth above to claims 10 and 12. Furthermore, Paduroiu teaches: wherein identifying the data object offset value comprises: receiving the metadata stored by the stream storage equipment that implicates the data object offset value (pars. [0007] and [0056] “a read request based on the corresponding segment length metadata in the target segment data store”); and based on the metadata, identifying the data object offset value (see pars. [0038], [0056] and [0060]).
Regarding claim 15, the claim is rejected by the same reasons set forth above to claim 10-14. However, Verbitski, Danilov, Shilane, and Colenbrander do not explicitly teach: “wherein identifying the data object offset value based on the metadata comprises mapping the group offset data corresponding to the second data chunk to the data object offset value.”
In the same field of endeavor (i.e., data processing), Paduroiu teaches: wherein identifying the data object offset value based on the metadata comprises mapping the group offset data corresponding to the second data chunk to the data object offset value (see pars. [0050-52] teach the groups of segments, and [0060] teaches matching offset values in segments, e.g., “…, updating target offset data of the replicated segments to match the offset values in the stream cut, resulting in updated target offset data (operation 1110), and allowing reading of the streamed data from the replicated segments up to locations in the replicated segments represented by the updated target offset data (operation 1112)”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Paduroiu would have provided Verbitski, Danilov, Shilane, and Colenbrander with the above indicated limitation allowing a skill artisan in motivation to perform updating offset length of the segments corresponding target offset data in the obtained stream (Paduroiu: Figs. 6-10, and pars. [0006, 24-26, and 60]).
Response to Arguments
Referring to claim rejections under 35 U.S.C. §103, Applicant’s arguments to the newly amended limitations/features in claim 1 (see Remarks, pages 8-10) have been considered but are moot in view of the new grounds of rejection necessitated by applicant's amendment to the claims. Applicant's newly amended features are taught implicitly, expressly, or impliedly by the prior art of record.
Prior Arts
The prior art made of record on form PTO-892 and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
It is noted that any citation to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275,277 (CCPA 1968)); Merck & Co. v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert. denied, 493 U.S. 975 (1989).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jessica N. Le whose telephone number is (571)270-1009. The examiner can normally be reached M-F 9:30 am - 5:30 pm (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHERIEF BADAWI can be reached at (571) 272-9782. 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.
/Jessica N Le/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169
Prosecution Insights