DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been presented for examination and are rejected.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on11/08/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 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 of this title, 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.
Claims1-3, 5, 9-11, 13 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Grube et al. (US 20110161680 hereinafter Grube) in view of Patiejunas et al. (US 20140046906 hereinafter Patiejunas).
With respect to claims 1, 9 and 17, Grube teaches a method for execution by one or more processing modules of a storage network, the method comprising:
receiving a store data request including a data object and a data identifier (Grube, see paragraph [0067] storing data, the gateway module 78 receives an incoming data object that includes a user ID field 86, an object name field 88, and the data field 40 and may also receive corresponding information that includes a process identifier (e.g., an internal process/application ID), metadata, a file system directory, a block number, a transaction message, a user device identity (ID), a data object identifier,…);
generating a source name for the data object (Grube, see paragraph [0069] assign a source name 35 to the data. For instance, the gateway module 60 determines the source name 35 of the data object 40 based on the vault identifier and the data object. For example, the source name may contain a file identifier (ID));
determining whether the data object is already stored in memory of the storage network (Grube, see paragraph [0091] a determination may be based on one or more of the contents of the store data object message, a vault lookup, a command, a predetermination, a table lookup, a DSN records lookup, information about previously stored data objects…); and
Grube yet fails to explicitly disclose in response to determining that the data object is already stored in the memory of the storage network:
identifying location information for the data object;
storing the location information using the source name; and
updating metadata for the data object to indicate that an additional copy of the
data object is stored in the memory of the storage network.
However, Patiejunas discloses in response to determining that the data object is already stored in the memory of the storage network (Patiejunas, see paragraph [0119] determining 616 one or more data decoding schemes that may be used to decode retrieved data. Typically, such decoding schemes correspond to the encoding schemes applied to the original data when the original data is previously stored):
identifying location information for the data object (Patiejunas, see paragraph [0020] the storage location information encoded in the data object identifier may be used to locate the stored data object. FIG. 9 and paragraph [0166] further discloses process 900 includes 918 retrieving data using at least the storage location information that is extracted from the data object identifier);
storing the location information using the source name (Patiejunas, see paragraph [0017] data object identifier (i.e., equivalent to source name) may encode storage location information that may be used to locate a data object stored in an archival data storage system. For example, the storage location information may encode a reference to a hierarchical data structure in which the data object is stored (i.e., equivalent storing the location information utilizing data object identifier ). Such an embodiment may reduce or eliminate the cost to store a namespace map or similar data structure to map data object identifiers to storage locations of the corresponding data objects); and
updating metadata for the data object to indicate that an additional copy of the data object is stored in the memory of the storage network (Patiejunas, see paragraph [0107] updating 526 metadata information including, metadata maintained by data plane 214 (such as index and storage space information for a storage device, mapping information stored at storage node registrar store 250 and the like)… metadata information may be updated via batch processing and/or on a periodic basis to reduce performance and cost impact. For example, in data plane 214, information maintained by storage node registrar store 250 may be updated to provide additional mapping of the volume identifier of the newly stored data and the storage nodes 246 on which the data components are stored).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching Grube with the teaching Patiejunas to provide the method for identifying and managing location information through source naming and metadata offers foundational advantages for modern data storage, particularly in scalable, distributed environments.
With respect to claims 2, 10 and 18, Grube-Patiejunas teaches the method, further comprising:
in response to determining that the data object is not already stored in the memory of the storage network (Patiejunas, see paragraph [0107] if such a mapping (i.e., mapping of the volume identifier of the newly stored data and the storage nodes ) is not already there, volume index on storage devices may be updated to reflect newly added data components):
storing the data object in the memory of the storage network using the source name (Patiejunas, see paragraph [0020] the storage location information encoded in the data object identifier may be used to locate the stored data object); and
establishing metadata for the data object, the metadata indicating that one copy of the data object is stored in the memory of the storage network (Patiejunas, see paragraph [0109] In metadata plane 216, metadata may be updated to reflect the newly stored data. For example, completed jobs may be pulled from job result queue 242 into metadata manager job store 258 and batch-processed by metadata manager 260 to generate an updated index such as stored in cold index store 262).
With respect to claims 3, 11 and 19, Grube-Patiejunas teaches the method, further comprising:
receiving a request to delete the data object (Patiejunas, see paragraph [0038] Such events may include the completion of a data retrieval job request, the completion of metadata request, deletion of data objects or logical data containers and the like. Paragraph [0054] a deletion job for the same data object where the deletion job comes after the storage job ); and
updating the metadata to indicate that one less copy of the data object is stored in the memory of the storage network (Patiejunas, see paragraph [0135] storage nodes executing the deletion operation may update storage information including index, free space information and the like. Storage nodes may provide updates to storage node registrar or storage node registrar store).
With respect to claims 5 and 13, Grube-Patiejunas teaches the method, further comprising:
receiving a request to delete the data object (Patiejunas, see paragraph [0038] Such events may include the completion of a data retrieval job request, the completion of metadata request, deletion of data objects or logical data containers and the like. Paragraph [0054] a deletion job for the same data object where the deletion job comes after the storage job);
regenerating a corresponding source name for the data object (Grube, see paragraph [0069] assign a source name 35 to the data. For instance, the gateway module 60 determines the source name 35 of the data object 40 based on the vault identifier and the data object. For example, the source name may contain a file identifier (ID));
retrieving the metadata for the data object (Patiejunas, see paragraph [0032] a job may include retrieving metadata);
determining, based on the metadata, that one copy of the data object is currently stored in the memory of the storage network (Patiejunas, see paragraph [0107] updating 526 metadata information including, metadata maintained by data plane 214 (such as index and storage space information for a storage device, mapping information stored at storage node registrar store 250 and the like)… metadata information may be updated via batch processing and/or on a periodic basis to reduce performance and cost impact); and
deleting the data object and the metadata for the data object from the memory of the storage network (Patiejunas, see paragraph [0032] a job may include retrieving, storing and deleting data, retrieving metadata and the like. A job may be identified by a job identifier that may be unique …).
Claims 4, 6-7, 12, 14-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Grube et al. (US 20110161680 hereinafter Grube) in view of Patiejunas et al. (US 20140046906 hereinafter Patiejunas) further in view of Volvovski et al. (US 20110225209 hereinafter Volvovski ).
With respect to claims 4, 12 and 20, Grube-Patiejunas teaches the method, yet fails to expertly disclose wherein the request to delete the data object includes a second data identifier, the method further comprising:
regenerating a corresponding source name for the data object based on the second data identifier; and
determining that the corresponding source name corresponds to a link-object.
However, Volvovski discloses wherein the request to delete the data object includes a second data identifier, the method further comprising:
regenerating a corresponding source name for the data object based on the second data identifier(Volvovski, see paragraph [0144] the DS processing unit may retrieve the EC data slices, recreate the data object, determine secondary dispersal parameters, code and slice the data object in accordance with the secondary dispersal parameters, and send the slices to the other entity. The determination of the secondary dispersal parameters may be based on one or more of a vault lookup for the other entity, a vault lookup for the vault user, a command, and/or a common system wide parameter lookup. Col. 15, Claim 1, further discloses create a file identifier based on a result of the data compression function; create a source name for the data object using the file identifier; and link the user file name to the source name in a file system directory ); and
determining that the corresponding source name corresponds to a link-object (Volvovski, see paragraph [0147] It should be noted that linking two or more different user file names in the directory to the same set of EC data slices (common source name) in the DSN memory may serve to improve the efficiency of the computing system by reducing the amount of duplicate stored data); and
deleting the link-object(Volvovski, see paragraph [0150] It should further be noted that the processing module decrements the reference counter when a delete data object request is received from the user for a file name linked to the same source name).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching Grube-Patiejunas with the teaching Volvovski to provide the method for regenerating a source name based on a second data identifier, and verifying it corresponds to a link-object, allows systems to resolve dynamic object locations and explicit network relationships. This process ensures resilience, graph-traversal capability, and system harmony between disparate datasets.
With respect to claims 6 and 14, Grube-Patiejunas teaches the method, wherein updating metadata for the data object to indicate that an additional copy of the data object is stored in the memory of the storage network includes:
retrieving the metadata (Patiejunas, see paragraph [0032] job may include: retrieving metadata);
Grube-Patiejunas yet fails to expertly disclose incrementing a copy count of the metadata by one to produce updated metadata; and storing the updated metadata in the memory of the storage network.
However, Volvovski discloses incrementing a copy count of the metadata by one to produce updated metadata; and storing the updated metadata in the memory of the storage network (Volvovski, see paragraph [0150] the processing module then increments a reference counter for this source name 121 in the directory, at 350, to signify the number of user file names for this data object/source name pair. Col. 15, claim 3, further discloses wherein the processing module is further operable to: receive, via the interface, the data object to be stored and a new user file name of the data object; increment the reference counter for the source name of the data object; and link the new user file name to the source name in the file system directory).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching Grube-Patiejunas with the teaching Volvovski to provide the method for in storage and distributed file systems, incrementing a copy count (or reference count) and storing updated metadata enables space efficiency and instantaneous snapshots through Copy-on-Write (CoW). Instead of duplicating the actual data payload across the network, the system duplicates and updates only the metadata pointers. Thus, massive space savings, because actual data isn't duplicated and zero-copy cloning by multiple users or virtual machines can simultaneously point to the exact same dataset.
With respect to claims 7 and 15, Grube-Patiejunas-Volvovski teaches the method, wherein storing the updated metadata in the memory of the storage network includes:
encoding the updated metadata to produce a set of encoded data slices (Grube, see paragraph [0058] the device 12 encodes and slices the data file and/or data block it has to store. The device then transmits the slices 11 to the DSN memory via its DSN interface 32 and the network 24. Paragraph [0081] further discloses The encoder 77 determines which forward error correction algorithm to use based on a predetermination associated with the user's vault, a time based algorithm, user direction, DS managing unit direction, control unit direction, as a function of the data type, as a function of the data segment 92 metadata, and/or any other factor to determine algorithm type ); and
facilitating storage of the set of encoded data slices in the memory of the storage network (Grube, see paragraph [0128] The processing module dispersed storage error encodes at least a portion of the data from one of the plurality of data storage requests (e.g., the selected one) to produce a set of encoded data slices. The processing module sends the set of encoded data slices to the DSN memory for storage therein).
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Grube et al. (US 20110161680 hereinafter Grube) in view of Patiejunas et al. (US 20140046906 hereinafter Patiejunas) further in view of (Park et al. (US 20060208860 hereinafter Park).
With respect to claims 8 and 16, Grube-Patiejunas teaches the method,
wherein determining whether the data object is already stored in memory of the storage network (Grube, see paragraph [0091]) yet fails to expertly disclose includes: generating a data tag for the data object; and comparing the data tag to a list of data tags for stored data objects.
However, Park discloses includes: generating a data tag for the data object Park, see paragraph [0014] If the tag data list comprises data coinciding with the read tag data according to a result of comparing the tag data with the tag data list, the controller extracts corresponding address information from the tag data list and generates the address information request signal using the extracted address information); and
comparing the data tag to a list of data tags for stored data objects (Park, see paragraph [0021] If the tag data list comprises data coinciding with the read tag data according to a result of comparing the tag data with the tag data list, corresponding address information is extracted from the tag data list and the additional information request signal is generated using the extracted address information).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching Grube-Patiejunas with the teaching Park to provide the method for generating a data tag and comparing it against a list of stored tags offers lightning fast lookups by comparing short, fixed-length strings takes a fraction of the time takes to compare large, complex data objects.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
PG. Pub. US 20110125771 Method for storing data object in computer, involves generating unique retrieval, so as to identify sub-set of encoded data slices of set of encoded data slices.
PG. Pub. US 20110314346 Method for identifying slice name information error in dispersed storage network (DSN), involves requesting portion of slice name information lists when inconsistency between list digest responses is determined.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH KASSA whose telephone number is (571)270-0567. The examiner can normally be reached Monday -Friday 9 AM -6 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ario Etienne can be reached on 517-272-4001. 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.
07/11/2026
/ELIZABETH KASSA/Examiner, Art Unit 2457
/ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights