DETAILED ACTION
Continued Examination Under 37 CFR 1.114
1. 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 03/02/2026 has been entered.
2. This office action is in response to applicant’s communication filed on 03/02/206 in response to PTO Office Action mailed on 12/05/2025. The Applicant’s remarks and amendments to the claims and/or the specification were considered with the results as follows.
3. In response to the last Office Action, claims 1, 8-14, 16-20 are amended. No claims are added or canceled. As a result, claims 1-20 are pending in this office action.
Response to Arguments
4. Applicant's arguments with respect to 35 USC 103 have been fully considered but are moot in view of new ground(s) of rejection:
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 8, 11, 13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable by Aizman (US 2017/0123931 A1) and in view of Sealing (US 2022/0197529 A1).
Referring to claims 1, 11 and 20, Aizman discloses a system comprising:
a network interface configured for network communication with a plurality of host systems (See para. [0051] and Figure 1, the storage system comprises communication interface 130 configured for network communication with storage server 150a…150j);
a storage interface […] configured for storage interface bus communication with a plurality of data storge devices (See para. [0051], the storage system comprises communication interface 140 for access storage servers 150a, 150b…150j).
at least one memory; and at least one processor (See para. [0051], para. [0053] and Figures 1 and 2 a storage system comprises clients 110a, 110b, 110i, each of the storage servers 150a, 150b, 150j is coupled to a plurality of storage devices 160a, 160b…160j) configured to, alone or in combination, execute instructions to:
determine, in the plurality of data storage devices, a plurality of host namespaces configured to store host data for the plurality of host systems (See para. [0024], para. [0055] and Figure 2, each storage server utilizing a namespace manifest, each shard can be replicated to multiple servers, note in para [0026] and Figure 3B, one types of entry [data] that can stored in a namespace manifest shard);
create, on each data storage device among the plurality of data storage devices, a snapshot namespace configured to store snapshots of host data stored in the plurality of host namespaces (See para. [0161]-[0164] and Figure 14, at time T, snapshot manifest 1313 is created from namespace manifest 210 or a portion thereof, then at time U, snapshot manifest 1314 is created from namespace manifest 210’ or a portion thereof) […];
capture, for each host namespace, an initial snapshot to determine a set of initial snapshots for the plurality of host namespaces (See para. [0199], capture snapshot manifests for transactions that are added to various namespace manifest shards);
store the set of initial snapshots to the snapshot namespace distributed among the plurality of data storage devices (See para. [0024], para. [0055], para. [0199] and Figures 2 and 14, store the snapshot manifests to the namespace manifest shards which are stored in storage servers, note each shard can be replicated to multiple servers); and
store a snapshot management data structure (See para. [0024], para. [0055] and para. [0199] and Figures 2, 14, store metadata 801 contains a change to entry 301) comprising: namespace metadata for the plurality of host namespaces; and snapshot metadata for the set of initial snapshots (See para. [0024], para. [0055] and para. [0199] and Figures 2, 14, the change of the transactions from transaction logs 220e and 220i will be added to various namespace manifest shards, the snapshot is taken at time T, entries 301 and 302 are captured in snapshot manifest 1313, but metadata 801 also must be captured in snapshot manifest 1313. In addition, if metadata 801 contains a change to Entry 301 [for example, indicating a new version of an object], then that change will be reflected in Record 1401 in snapshot manifest 1313, either by modifying the data before it is stored as Record 1401, or by updating Entry 301 in namespace manifest shard 210a before it is copied as Record 1401 in snapshot manifest 1313).
Arizman does not explicitly a storage enclosure for a plurality of data storage devices and a private namespace for storing objects from namespace manifests.
Sealing discloses a storage enclosure for a plurality of data storage devices (See para. [0077], the system comprises multiple enclosures that separately house the components of the data processing device system), wherein the storage enclosure comprises: a network configured for network communication with a plurality of host systems (See para. [0077] and para. [0080] and Figures 3); a storage interface bus configured for communication with the plurality of data storage devices (See para. [0118], the system comprises one or more processors, such as processor 610, the processor 610 communicatively coupled with a communication interface 605 [e.g., a communication bus]); a plurally of storage bus ports configured to receive the plurality of data storage device (See para. [0034], two or more clients, access to a shared portion of the memory storage, the clients may access the memory storage device via respective ports of the memory storage device, each port of the memory storage device may be controlled by a corresponding controller of the memory storage device); at least one processor configure to create a snapshot namespace comprises a private namespace inaccessible to a plurality of host systems (See para. [0054], the client 140 may read and write data in a private namespace associated with a port 120, a private namespace may be a namespace that may only be accessed via a corresponding port 120. For example, the dual-port memory storage 110 may provide read-write access to a first private namespace associated with the read-only port 120 to the client 140 that is communicatively coupled with the read-only port 120).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the namespace of Aizman to a private namespace, as taught by Sealing. Skilled artisan would have been motivated to protect each domain or network to prevent unauthorized access to respective networks (See Sealing, para. [0002]). In addition, all of the references (Sealing and Aizman) teach features that are directed to analogous art, and they are directed to the same field of endeavor such as sharing data securely across network systems. This close relation between all of the references highly suggests an expectation of success.
As to claims 3 and 13, Aizman disclose responsive to determining the set of initial snapshots for the plurality of host namespaces: monitor the plurality of host namespaces to determine host data changes in at least one host namespace of the plurality of host namespaces; capture, for each host namespace of the at least one host namespace having the host data changes, an updated snapshot to determine a set of update snapshots for the plurality of host namespaces; store the set of update snapshots to the snapshot namespace distributed among the plurality of data storage devices; and update the snapshot management data structure with changes to: the namespace metadata for the plurality of host namespaces; and the snapshot metadata for the set of initial snapshots (See para. [0024], para. [0055] and para. [0199] and Figures 2, 14, the change of the transactions from transaction logs 220e and 220i will be added to various namespace manifest shards, the snapshot is taken at time T, entries 301 and 302 are captured in snapshot manifest 1313, but metadata 801 also must be captured in snapshot manifest 1313. In addition, if metadata 801 contains a change to Entry 301 [for example, indicating a new version of an object], then that change will be reflected in Record 1401 in snapshot manifest 1313, either by modifying the data before it is stored as Record 1401, or by updating Entry 301 in namespace manifest shard 210a before it is copied as Record 1401 in snapshot manifest 1313).
As to claims 8 and 18, Aizman discloses replicate the snapshot management data structure across multiple storage locations selected from: non-volatile memory in each data storage device of the plurality of data storage devices (See para. [0055] and Figure 2, each namespace manifest shard is replicated to multiple servers).
Sealing discloses non-volatile memory in each storage enclosure of a plurality of storage enclosures (See para. [0077], the system comprises multiple enclosures that separately house the components of the data processing device system).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the namespace of Aizman to a private namespace, as taught by Sealing. Skilled artisan would have been motivated to protect each domain or network to prevent unauthorized access to respective networks (See Sealing, para. [0002]). In addition, all of the references (Sealing and Aizman) teach features that are directed to analogous art, and they are directed to the same field of endeavor such as sharing data securely across network systems. This close relation between all of the references highly suggests an expectation of success.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Aizman (US 2017/0123931 A1) and in view of Sealing (US 2022/0197529 A1) and further in view of Ramarz (US 2019/0384694 A1).
As to claims 2 and 12, Aizman discloses capturing the initial snapshots for the set of initial snapshots for the plurality of host namespaces (See para. [0199], capture snapshot manifests for transactions that are added to various namespace manifest shards) but does not explicitly disclose monitor the plurality of data storage devices for at least one failure condition; detect the at least one failure condition; and automatically initiate, responsive to detecting the at least one failure condition, capture a snapshot.
Ramraz discloses monitor the plurality of data storage devices for at least one failure condition; detect the at least one failure condition; and automatically initiate, responsive to detecting the at least one failure condition, capture a snapshot (See para. [0043] and Figure 5, At action 504, in response to detecting the failure, a snapshot is generated while the test is running, the snapshot specifying a stage of the plurality of stages and a state of the application at which the failure occurred. At action 506, the snapshot is uploaded to a repository. At action 508, the snapshot is restored to a computing device. The restored snapshot specifies the stage of the plurality of stages and the state of the application at which the failure occurred).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Aizman to monitor at last one failure condition and capture a snapshot responsive to detecting the at least one failure condition, as taught by Ramraz. Skilled artisan would have been motivated to generate a snapshot to save the current system state when a failure is detected in order to reproduce the issue later when desired, without affecting the continuous integration flow (See Ramraz, para. [0016]-para. [0018]). In addition, all of the references (Sealing, Ramarz and Aizman) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as accessing file system. This close relation between all of the references highly suggests an expectation of success.
Claims 4, 5, 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Aizman (US 2017/0123931 A1) in view of Sealing (US 2022/0197529 A1) and further in view of Purandare “Append is Near: Log-based Data Management on ZNS SSDs”, 2022.
As to claims 4 and 14, Ramraz discloses a host namespace and a snapshot namespace but does not explicitly convert, prior to storing the host data from the at least one host namespace having the host namespace type that is different from the snapshot namespace type to the set of initial snapshots.
Purandare discloses determine, for each host namespace, a host namespace type for that host namespace; determine, for a namespace, a namespace type that is different from the host namespace type of at least one host namespace of the plurality of host namespaces (See Section 5.1, subsection 5.1.4 determining there are several namespace types including write namespace, zoned namespace and block namespace); and convert, prior to storing the host data from the at least one host namespace having the host namespace type that is different from the namespace type […], host data mapping for that host namespace type to host data mapping for the namespace type (See Section 5.1, subsection 5.1.4, convert the metadata of the zoned namespace to conventional namespaces [e.g., write namespace or block namespace] for heterogeneous data storage).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Aizman to determine different types of namespaces, as taught by Purandare. Skilled artisan would have been motivated to allow users to store metadata in different ways including the write namespaces and zoned namespaces to support heterogenous data storage (See Purandare, Section 5.14). In addition, all of the references (Sealing, Purandare and Aizman) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as storing data in namespaces. This close relation between all of the references highly suggests an expectation of success.
As to claims 5 and 15, Purandare discloses the host namespace type for the at least one host namespace having the host namespace type that is different from the namespace type is a block storage namespace type (See Section 5.1, subsection 5.1.4 determining there are several namespace types including write namespace, zoned namespace and block namespace); and the namespace type is a sequential write namespace type selected from: a zoned namespace type; and a key-value namespace type (See Section 5.1, subsection 5.1.4, convert the metadata of the zoned namespace to conventional namespaces [e.g., write namespace or block namespace] for heterogeneous data storage).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Aizman to determine different types of namespaces, as taught by Purandare. Skilled artisan would have been motivated to allow users to store metadata in different ways including the write namespaces and zoned namespaces to support heterogenous data storage (See Purandare, Section 5.14). In addition, all of the references (Sealing, Purandare and Aizman) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as storing data in namespaces. This close relation between all of the references highly suggests an expectation of success.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Aizman (US 2017/0123931 A1) in view of Sealing (US 2022/0197529 A1) and further in view of DeKoning (US 2019/0034092 A1).
As to claims 7 and 17, Aizman does not explicitly disclose determine a snapshot allocation value for each data storage device of the plurality of data storage devices.
DeKoning discloses determine a snapshot allocation value for each data storage device of the plurality of data storage devices (See para. [0023], para. [0028], para. [0041], determining a snapshot allocation capacity for one or more logical units); and the namespace comprises, for each data storage device of the plurality of data storage devices, a portion of a capacity of that data storage device based on the snapshot allocation value (See para. [0028], para. [0041], a persistent hierarchical namespace of files and directories for the one or more logical units comprises a snapshot allocated capacity region).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Aizman to determine a snapshot allocation value for each storage device, as taught by DeKoning. Skilled artisan would have been motivated to delete the snapshot that was stored in the snapshot allocated capacity of the logical units to free up the snapshot allocated capacity in the logical units and with this technology, normal snapshot processing can be accelerated by using low latency logical units (See DeKoning, para. [0041]-para. [0043]). In addition, all of the references (Sealng, DeKoning and Aizman) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as accessing file system. This close relation between all of the references highly suggests an expectation of success.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Aizman (US 2017/0123931 A1) in view of Sealing (US 2022/0197529 A1) and further in view of Potashnik (US 2022/0398018 A1).
As to claims 9 and 19, Aizman does not explicitly disclose a network interface in communication with a cloud-based storage system configured to store offloaded snapshot data.
Potashnik discloses a storage enclosure comprising: a network interface in communication with a cloud-based storage system configured to store offloaded snapshot data; the plurality of data storage devices (See para. [0158] and Figure 4A, offloading the snapshot to a cloud storage system); the at least one memory; and the at least one processor, wherein the at least one processor is further configured to, alone or in combination, execute instructions to: determine a set of credentials for the cloud-based storage system; embed the snapshot management data structure with the set of initial snapshots; and store the snapshot management data structure and the set of initial snapshots to the cloud-based storage system (See para. [0248], determining user credentials associated with one or more snapshots that are stored in a cloud computing environment is utilized during a recovery or migration process, to access the dataset, migrate the dataset to faster storage in the cloud computing environment).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the network interface of Aizman to include a cloud-based storage system configured to store offloaded snapshot data, as taught by Potashnik. Skilled artisan would have been motivated to maintain recorded after loss of power efficiently (See Potashnik, para. [0034]). In addition, all of the references (Potashnik, Goyal and Aizman) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as accessing file system. This close relation between all of the references highly suggests an expectation of success.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Aizman (US 2017/0123931 A1) in view of Sealing (US 2022/0197529 A1) and Potashnik (US 2022/0398018 A1) and further in view of Ramarz (US 2019/0384694 A1).
As to claim 10, Aizman discloses capturing initial snapshots for a set of initial snapshots for a plurality of host namespaces (See para. [0199], capture snapshot manifests for transactions that are added to various namespace manifest shards) but Aizman does not explicitly disclose monitor a plurality of failure conditions including power connection to at least one data storage device through the at least one power interface.
Potashnik also discloses wherein: each data storage device of the plurality of data storage devices is a solid-state drive (See para. [0034] and para. [0095], the storage drive includes one or more solid-state drives) comprising: a non-volatile storage medium; a device controller configured to control storage operations to the non-volatile storage medium; and a storage interface port configured to connect to a storage interface bus of the storage enclosure (See para. [0072] and para. [0078] and Figure 2B; each storage node has a power distribution bus and a communication bus that enables communication between the storage nodes) and the storage enclosure further comprises: at least one power interface configured to provide power to the plurality of data storage devices (See para. [0057], para. [0059], the storage node comprises a power source stores energy to power the storage device controller); at least one fan configured to cool the plurality of data storage devices (See para. [0075] and Figure 2, fans 144 provides air circulation for cooling of the storage nodes 150); and an enclosure manager stored in the at least one memory for execution by the at least one processor, alone or in combination, to monitor for a plurality of failure conditions selected from: failure of at least one data storage device of the plurality of data storage devices; failure of at least one port connected to the storage interface bus; failure of at least one power connection to at least one data storage device through the at least one power interface; and failure of the at least one fan (See para. [0033] and para. [0057], In response to a power loss, the NVRAIVI device may be configured to write the contents of the RAM to a persistent storage, such as the storage drives 171A-F).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Aizman to monitor a plurality of failure conditions, as taught by Potashnik. Skilled artisan would have been motivated to maintain recorded persistently (See Potashnik, para. [0034]). In addition, all of the references (Sealing, Potashnik and Aizman) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as accessing filing system. This close relation between all of the references highly suggests an expectation of success.
Aizman in view of Potashnik does not explicitly disclose monitor the plurality of data storage devices for at least one failure condition; detect the at least one failure condition; and automatically initiate, responsive to detecting the at least one failure condition, capture a snapshot.
Ramraz discloses monitor the plurality of data storage devices for at least one failure condition; detect the at least one failure condition; and automatically initiate, responsive to detecting the at least one failure condition, capture a snapshot (See para. [0043] and Figure 5, At action 504, in response to detecting the failure, a snapshot is generated while the test is running, the snapshot specifying a stage of the plurality of stages and a state of the application at which the failure occurred. At action 506, the snapshot is uploaded to a repository. At action 508, the snapshot is restored to a computing device. The restored snapshot specifies the stage of the plurality of stages and the state of the application at which the failure occurred).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Aizman to monitor at last one failure condition and capture a snapshot responsive to detecting the at least one failure condition, as taught by Ramraz. Skilled artisan would have been motivated to generate a snapshot to save the current system state when a failure is detected in order to reproduce the issue later when desired, without affecting the continuous integration flow (See Ramraz, para. [0016]-para. [0018]). In addition, all of the references (Sealing, Ramarz, Potashnik and Aizman) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as accessing file system. This close relation between all of the references highly suggests an expectation of success.
Allowable Subject Matter
Claims 6 and 16 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YUK TING CHOI whose telephone number is (571)270-1637. The examiner can normally be reached Monday-Friday 9am-6pm.
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, AMY NG can be reached at 5712701698. 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.
/YUK TING CHOI/Primary Examiner, Art Unit 2164
Prosecution Insights