DETAILED ACTION
This Office action is in response to original application filed on 05/05/2025.
Claims 1-20 are pending.
Claims 1-5, 8-18, and 20 are rejected under 35 U.S.C. 103.
Claims 6-7 and 19 are rejected via double patenting.
Notice of 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 .
Priority
This application is a continuation of 17/526,288 issued 05/13/2025 as U.S. Patent No. 12,298,862, claiming priority to IN202141043689 filed 09/27/2021.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 06/11/2025 was filed prior to this Office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Statutory Review under 35 USC § 101
Claims 1-15 are directed towards a method and have been reviewed.
Claims 1-15 initially appear to be statutory as the method is directed to patent-eligible subject matter based on Step 2A, Prong Two of the subject matter eligibility determination, comprising an abstract idea (detecting an end of a backup) integrated into a practical application.
Claims 16-19 are directed toward a system and have been reviewed.
Claims 16-19 initially appear to be statutory, as the system includes hardware (one or more computer processors) as disclosed in ¶ 0028 (referring to processors as hardware) of the applicant’s specification. See also relevant ¶ 0136 of the applicant’s specification referring to “computer processors” specifically.
Claims 16-19 also appear to be statutory as the claims perform a method directed to patent-eligible subject matter based on Step 2A, Prong Two of the subject matter eligibility determination, comprising an abstract idea (detecting an end of a backup) integrated into a practical application.
Claim 20 is directed toward an article of manufacture and have been reviewed.
Claim 20 initially appears to be statutory, as the article of manufacture excludes transitory signals (claim says non-transitory).
Claim 20 also appears to be statutory as the claim performs a method directed to patent-eligible subject matter based on Step 2A, Prong Two of the subject matter eligibility determination, comprising an abstract idea (detecting an end of a backup) integrated into a practical application.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 6-7 and 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2 and 11 of U.S. Patent No. 12,298,862. Although the claims at issue are not identical, they are not patentably distinct from each other because U.S. Patent No. 12,298,862 recites a minor detecting step, detecting a request, which is not explicitly tied to subsequent steps in the method (see that the subsequent “sending a request … to initiate a backup” features no language tied to the initial “detecting” step) and further would serve as a mental process in an analysis of the subject matter eligibility of the claims.
Instant application 19/199,113
U.S. Patent No. 12,298,862
A computer-implemented method comprising:
sending a request, from a distributed backup system to a backup agent executing at a host, to initiate a backup of data at the host:
[from claim 6]
wherein the request to initiate the backup indicates for the backup agent to:
mount the first network file share endpoint at the host for writing to the distributed backup system and execute a first script to write the first portion of the data for the backup to the first network file share endpoint; and
mount the second network file share endpoint at the host for writing to the distributed backup system and execute a second script to write the second portion of the data for the backup to the second network file share endpoint.
creating, based at least in part on sending the request to initiate the backup:
a first file system stack at a first node of the distributed backup system that provides a first path to a first network file share endpoint at the host via a network file share client at the distributed backup system, wherein the first network file share client is at the first node; and
a second file system stack at a second node of the distributed backup system that provides a second path to a second network file share endpoint at the host via a second network file share client at the distributed backup system, wherein the second network file share client is at the second node,
storing data received by the first file system stack and the second file system stack at the distributed backup system,
wherein a first portion of the data for the backup is received by the first file system stack at the first node via the first network file share endpoint and based at least in part on sending the request to the backup agent,
and wherein a second portion of the data for the backup is received by the second file system stack at the second node via the second network file share endpoint and based at least in part on sending the request to the backup agent;
detecting, by the distributed backup system, an end of the backup;
sending a command, in response to detecting the end of the backup and from the distributed backup system to the backup agent executing at the host, to end the backup; and
terminating the first file system stack and the second file system stack at the distributed backup system in response to detecting the end of the backup.
A computer-implemented method comprising:
detecting, by a distributed backup system, a request for backing up data from a host to the distributed backup system;
sending a request, from the distributed backup system to a backup agent executing at the host, to initiate a backup,
wherein, based on the request to initiate the backup, the backup agent:
mounts a first network file share endpoint at the host for writing to the distributed backup system and executes a first script that writes a first portion of the data for the backup to the first network file share endpoint; and
mounts a second network file share endpoint at the host for writing to the distributed backup system and executes a second script that writes a second portion of the data for backup to the second network file share endpoint;
creating, based at least in part on sending the request to initiate the backup:
a first file system stack at a first node of the distributed backup system that provides a first path to the first network file share endpoint at the host via a first network file share client at the distributed backup system, wherein the first network file share client is at the first node; and
a second file system stack at a second node of the distributed backup system that provides a second path to the second network file share endpoint at the host via a second network file share client at the distributed backup system, wherein the second network file share client is at the second node,
storing data received by the first file system stack and the second file system stack at the distributed backup system,
wherein the first portion of the data for the backup is received by the first file system stack at the first node,
and wherein the second portion of the data for the backup is received by the second file system stack at the second node;
detecting, by the distributed backup system, an end of the backup;
sending a command, in response to detecting the end of the backup and from the distributed backup system to the backup agent executing at the host, to end the backup; and
terminating the first file system stack and the second file system stack at the distributed backup system in response to detecting the end of the backup.
Claim 7 corresponds to claim 2 of U.S. Patent No. 12,298,862.
Claim 19 corresponds to claim 11 of U.S. Patent No. 12,298,862.
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, 5, 10, 14-15; 16; and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Venetsanopoulos et al., U.S. Patent Application Publication No. 2018/0239560 (hereinafter Venetsanopoulos) in view of Abbott et al., U.S. Patent Application Publication No. 2003/0033344 (hereinafter Abbott).
Regarding claim 1, Venetsanopoulos teaches:
A computer-implemented method comprising: sending a request, from a distributed backup system to a backup agent executing at a host, to initiate a backup of data at the host: (Venetsanopoulos FIG. 20A, ¶ 0156-0157: The virtual disk snapshot process 2000 can begin with a decision 2002. The decision 2002 can determine whether a new virtual disk snapshot request has been received … Once the decision 2002 determines that a new virtual disk snapshot request has been received, a virtual disk snapshot command can be formed 2004. Next, the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see Venetsanopoulos ¶ 0199, "users can fill the buckets with virtual storage resources (e.g., snaphots). A file can be a snapshot that is managed by the SMML")
creating, based at least in part on sending the request to initiate the backup: a first file system stack at a first node of the distributed backup system that provides a first path to a first network file share endpoint at the host via a network file share client at the distributed backup system, wherein the first network file share client is at the first node; and (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a first stack contemplated in FIGs. 6-9, ¶ 0077-0079: Rok runs as a software-only solution on the commodity hardware that the compute platform also runs; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
a second file system stack at a second node of the distributed backup system that provides a second path to a second network file share endpoint at the host via a second network file share client at the distributed backup system, wherein the second network file share client is at the second node, (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a second stack contemplated in the Rok installations of FIGs. 6-8; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
storing data received by the first file system stack and the second file system stack at the distributed backup system, (Venetsanopoulos FIG. 20A, ¶ 0157-0159: The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) ... a decision 2010 can determine whether a compute platform snapshot completion response has been received)
wherein a first portion of the data for the backup is received by the first file system stack at the first node via the first network file share endpoint and based at least in part on sending the request to the backup agent, (Venetsanopoulos FIG. 20A, ¶ 0157-0159: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see contextually ¶ 0255: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations); see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows the first stack receiving data for backup]; see ¶ 0239-0240: the bucket service makes a request to the SMML 2314 (e.g., a composition service of the SMML) to make a snapshot of the virtual storage resource (VSR). The composition service of the SMML, upon receiving the request to make the snapshot, can create 2316 the snapshot of the VSR; see FIG. 9, ¶ 0093: The actual data distribution across the network is done by Service 905 [first network file share endpoint]; FIG. 20A, ¶ 0156-0157: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) [shows request sent to backup agent])
and wherein a second portion of the data for the backup is received by the second file system stack at the second node via the second network file share endpoint and based at least in part on sending the request to the backup agent; (Venetsanopoulos FIG. 20A, ¶ 0157-0159: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see contextually ¶ 0255: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations); see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows a stack receiving data for backup]; see a second stack contemplated in the Rok installations of FIGs. 6-8; see ¶ 0239-0240: the bucket service makes a request to the SMML 2314 (e.g., a composition service of the SMML) to make a snapshot of the virtual storage resource (VSR). The composition service of the SMML, upon receiving the request to make the snapshot, can create 2316 the snapshot of the VSR; see FIGs. 6-9, ¶ 0093: The actual data distribution across the network is done by Service 905 [second network file share endpoint]; FIG. 20A, ¶ 0156-0157: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) [shows request sent to backup agent])
detecting, by the distributed backup system, an end of the backup; (Venetsanopoulos FIG. 20A, ¶ 0158-0159: a decision 2010 can determine whether a compute platform snapshot completion response has been received … when the decision 2010 determines that a compute platform snapshot completion response has been received, virtual disk status and data at the compute platform can be updated 2014 based on the compute platform snapshot completion response)
sending a command … from the distributed backup system to the backup agent executing at the host, to end the backup; and (Venetsanopoulos FIGs. 21, ¶ 0176-0180: the virtual disk deletion command can be translated 2106 to a virtual storage resource deletion command. The virtual storage resource deletion command can then be transmitted 2108 to the storage mobility and management layer (SMML))
…the first file system stack and the second file system stack at the distributed backup system… (Venetsanopoulos ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see FIGs. 6-9, ¶ 0077-0079: Rok runs as a software-only solution on the commodity hardware that the compute platform also runs)
Venetsanopoulos does not expressly disclose:
creating, based at least in part on sending the request to initiate the backup:
sending a command, in response to detecting the end of the backup … to end the backup; and
terminating the first file system stack and the second file system stack … in response to detecting the end of the backup.
However, Abbott addresses this by teaching the following:
detecting, by the distributed backup system, an end of the backup; (Abbott ¶ 0131: the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
Abbott further newly teaches:
creating, based at least in part on sending the request to initiate the backup: (Abbott FIG. 4, ¶ 0075-0078: the main operations associated with saving the state of an application … the method commences with the start of the Java application whose state is to be saved (step 410), which in turn leads in standard fashion to the initialization of the Java VM classes (step 420))
sending a command, in response to detecting the end of the backup … to end the backup; and (Abbott ¶ 0131: Finally the method concludes with calling the JVM system components to perform their individual save operations (step 745), before the save routine eventually terminates (step 750) with the completed snapshot. Note that in the preferred embodiment, the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
terminating the first file system stack and the second file system stack … in response to detecting the end of the backup. (Abbott ¶ 0062: Another component of the Java VM is the stack area 195, which is used for storing the stacks 196, 198 associated with the execution of different threads on the Java VM; Abbott ¶ 0131: Finally the method concludes with calling the JVM system components to perform their individual save operations (step 745), before the save routine eventually terminates (step 750) with the completed snapshot. Note that in the preferred embodiment, the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the data storage system of Venetsanopoulos with the data storage system of Abbott.
Motivation to do so would be to improve the functioning of Venetsanopoulos executing backup requests with the ability in similar reference Abbott to execute save requests but with the improvement of user-determined actions.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement improved run-time performance as seen in Abbott ¶ 0061.
Regarding claim 16, Venetsanopoulos teaches:
A system comprising: a memory comprising instructions; and one or more computer processors individually or collectively operable to execute the instructions to cause the system to: (Venetsanopoulos ¶ 0300: The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system)
send a request, from a distributed backup system to a backup agent executing at a host, to initiate a backup of data at the host: (Venetsanopoulos FIG. 20A, ¶ 0156-0157: The virtual disk snapshot process 2000 can begin with a decision 2002. The decision 2002 can determine whether a new virtual disk snapshot request has been received … Once the decision 2002 determines that a new virtual disk snapshot request has been received, a virtual disk snapshot command can be formed 2004. Next, the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see Venetsanopoulos ¶ 0199, "users can fill the buckets with virtual storage resources (e.g., snaphots). A file can be a snapshot that is managed by the SMML")
create, based at least in part on sending the request to initiate the backup: a first file system stack at a first node of the distributed backup system that provides a first path to a first network file share endpoint at the host via a network file share client at the distributed backup system, wherein the first network file share client is at the first node; and (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a first stack contemplated in FIGs. 6-9, ¶ 0077-0079: Rok runs as a software-only solution on the commodity hardware that the compute platform also runs; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
a second file system stack at a second node of the distributed backup system that provides a second path to a second network file share endpoint at the host via a second network file share client at the distributed backup system, wherein the second network file share client is at the second node, (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a second stack contemplated in the Rok installations of FIGs. 6-8; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
store data received by the first file system stack and the second file system stack at the distributed backup system, (Venetsanopoulos FIG. 20A, ¶ 0157-0159: The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) ... a decision 2010 can determine whether a compute platform snapshot completion response has been received)
wherein a first portion of the data for the backup is received by the first file system stack at the first node via the first network file share endpoint and based at least in part on sending the request to the backup agent, (Venetsanopoulos FIG. 20A, ¶ 0157-0159: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see contextually ¶ 0255: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations); see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows the first stack receiving data for backup]; see ¶ 0239-0240: the bucket service makes a request to the SMML 2314 (e.g., a composition service of the SMML) to make a snapshot of the virtual storage resource (VSR). The composition service of the SMML, upon receiving the request to make the snapshot, can create 2316 the snapshot of the VSR; see FIG. 9, ¶ 0093: The actual data distribution across the network is done by Service 905 [first network file share endpoint]; FIG. 20A, ¶ 0156-0157: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) [shows request sent to backup agent])
and wherein a second portion of the data for the backup is received by the second file system stack at the second node via the second network file share endpoint and based at least in part on sending the request to the backup agent; (Venetsanopoulos FIG. 20A, ¶ 0157-0159: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see contextually ¶ 0255: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations); see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows a stack receiving data for backup]; see a second stack contemplated in the Rok installations of FIGs. 6-8; see ¶ 0239-0240: the bucket service makes a request to the SMML 2314 (e.g., a composition service of the SMML) to make a snapshot of the virtual storage resource (VSR). The composition service of the SMML, upon receiving the request to make the snapshot, can create 2316 the snapshot of the VSR; see FIGs. 6-9, ¶ 0093: The actual data distribution across the network is done by Service 905 [second network file share endpoint]; FIG. 20A, ¶ 0156-0157: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) [shows request sent to backup agent])
detect, by the distributed backup system, an end of the backup; (Venetsanopoulos FIG. 20A, ¶ 0158-0159: a decision 2010 can determine whether a compute platform snapshot completion response has been received … when the decision 2010 determines that a compute platform snapshot completion response has been received, virtual disk status and data at the compute platform can be updated 2014 based on the compute platform snapshot completion response)
send a command … from the distributed backup system to the backup agent executing at the host, to end the backup; and (Venetsanopoulos FIGs. 21, ¶ 0176-0180: the virtual disk deletion command can be translated 2106 to a virtual storage resource deletion command. The virtual storage resource deletion command can then be transmitted 2108 to the storage mobility and management layer (SMML))
…the first file system stack and the second file system stack at the distributed backup system… (Venetsanopoulos ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see FIGs. 6-9, ¶ 0077-0079: Rok runs as a software-only solution on the commodity hardware that the compute platform also runs)
Venetsanopoulos does not expressly disclose:
create, based at least in part on sending the request to initiate the backup:
send a command, in response to detecting the end of the backup … to end the backup; and
terminate the first file system stack and the second file system stack … in response to detecting the end of the backup.
However, Abbott addresses this by teaching the following:
detect, by the distributed backup system, an end of the backup; (Abbott ¶ 0131: the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
Abbott further newly teaches:
create, based at least in part on sending the request to initiate the backup: (Abbott FIG. 4, ¶ 0075-0078: the main operations associated with saving the state of an application … the method commences with the start of the Java application whose state is to be saved (step 410), which in turn leads in standard fashion to the initialisation of the Java VM classes (step 420))
send a command, in response to detecting the end of the backup … to end the backup; and (Abbott ¶ 0131: Finally the method concludes with calling the JVM system components to perform their individual save operations (step 745), before the save routine eventually terminates (step 750) with the completed snapshot. Note that in the preferred embodiment, the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
terminate the first file system stack and the second file system stack … in response to detecting the end of the backup. (Abbott ¶ 0062: Another component of the Java VM is the stack area 195, which is used for storing the stacks 196, 198 associated with the execution of different threads on the Java VM; Abbott ¶ 0131: Finally the method concludes with calling the JVM system components to perform their individual save operations (step 745), before the save routine eventually terminates (step 750) with the completed snapshot. Note that in the preferred embodiment, the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the data storage system of Venetsanopoulos with the data storage system of Abbott.
Motivation to do so would be to improve the functioning of Venetsanopoulos executing backup requests with the ability in similar reference Abbott to execute save requests but with the improvement of user-determined actions.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement improved run-time performance as seen in Abbott ¶ 0061.
Regarding claim 20, Venetsanopoulos teaches:
A non-transitory machine-readable storage medium including instructions executable by one or more processors to: (Venetsanopoulos ¶ 0300: The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system)
send a request, from a distributed backup system to a backup agent executing at a host, to initiate a backup of data at the host: (Venetsanopoulos FIG. 20A, ¶ 0156-0157: The virtual disk snapshot process 2000 can begin with a decision 2002. The decision 2002 can determine whether a new virtual disk snapshot request has been received … Once the decision 2002 determines that a new virtual disk snapshot request has been received, a virtual disk snapshot command can be formed 2004. Next, the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see Venetsanopoulos ¶ 0199, "users can fill the buckets with virtual storage resources (e.g., snaphots). A file can be a snapshot that is managed by the SMML")
create, based at least in part on sending the request to initiate the backup: a first file system stack at a first node of the distributed backup system that provides a first path to a first network file share endpoint at the host via a network file share client at the distributed backup system, wherein the first network file share client is at the first node; and (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a first stack contemplated in FIGs. 6-9, ¶ 0077-0079: Rok runs as a software-only solution on the commodity hardware that the compute platform also runs; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
a second file system stack at a second node of the distributed backup system that provides a second path to a second network file share endpoint at the host via a second network file share client at the distributed backup system, wherein the second network file share client is at the second node, (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a second stack contemplated in the Rok installations of FIGs. 6-8; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
store data received by the first file system stack and the second file system stack at the distributed backup system, (Venetsanopoulos FIG. 20A, ¶ 0157-0159: The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) ... a decision 2010 can determine whether a compute platform snapshot completion response has been received)
wherein a first portion of the data for the backup is received by the first file system stack at the first node via the first network file share endpoint and based at least in part on sending the request to the backup agent, (Venetsanopoulos FIG. 20A, ¶ 0157-0159: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see contextually ¶ 0255: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations); see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows the first stack receiving data for backup]; see ¶ 0239-0240: the bucket service makes a request to the SMML 2314 (e.g., a composition service of the SMML) to make a snapshot of the virtual storage resource (VSR). The composition service of the SMML, upon receiving the request to make the snapshot, can create 2316 the snapshot of the VSR; see FIG. 9, ¶ 0093: The actual data distribution across the network is done by Service 905 [first network file share endpoint]; FIG. 20A, ¶ 0156-0157: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) [shows request sent to backup agent])
and wherein a second portion of the data for the backup is received by the second file system stack at the second node via the second network file share endpoint and based at least in part on sending the request to the backup agent; (Venetsanopoulos FIG. 20A, ¶ 0157-0159: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see contextually ¶ 0255: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations); see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows a stack receiving data for backup]; see a second stack contemplated in the Rok installations of FIGs. 6-8; see ¶ 0239-0240: the bucket service makes a request to the SMML 2314 (e.g., a composition service of the SMML) to make a snapshot of the virtual storage resource (VSR). The composition service of the SMML, upon receiving the request to make the snapshot, can create 2316 the snapshot of the VSR; see FIGs. 6-9, ¶ 0093: The actual data distribution across the network is done by Service 905 [second network file share endpoint]; FIG. 20A, ¶ 0156-0157: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) [shows request sent to backup agent])
detect, by the distributed backup system, an end of the backup; (Venetsanopoulos FIG. 20A, ¶ 0158-0159: a decision 2010 can determine whether a compute platform snapshot completion response has been received … when the decision 2010 determines that a compute platform snapshot completion response has been received, virtual disk status and data at the compute platform can be updated 2014 based on the compute platform snapshot completion response)
send a command … from the distributed backup system to the backup agent executing at the host, to end the backup; and (Venetsanopoulos FIGs. 21, ¶ 0176-0180: the virtual disk deletion command can be translated 2106 to a virtual storage resource deletion command. The virtual storage resource deletion command can then be transmitted 2108 to the storage mobility and management layer (SMML))
…the first file system stack and the second file system stack at the distributed backup system… (Venetsanopoulos ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see FIGs. 6-9, ¶ 0077-0079: Rok runs as a software-only solution on the commodity hardware that the compute platform also runs)
Venetsanopoulos does not expressly disclose:
create, based at least in part on sending the request to initiate the backup:
send a command, in response to detecting the end of the backup … to end the backup; and
terminate the first file system stack and the second file system stack … in response to detecting the end of the backup.
However, Abbott addresses this by teaching the following:
detect, by the distributed backup system, an end of the backup; (Abbott ¶ 0131: the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
Abbott further newly teaches:
create, based at least in part on sending the request to initiate the backup: (Abbott FIG. 4, ¶ 0075-0078: the main operations associated with saving the state of an application … the method commences with the start of the Java application whose state is to be saved (step 410), which in turn leads in standard fashion to the initialisation of the Java VM classes (step 420))
send a command, in response to detecting the end of the backup … to end the backup; and (Abbott ¶ 0131: Finally the method concludes with calling the JVM system components to perform their individual save operations (step 745), before the save routine eventually terminates (step 750) with the completed snapshot. Note that in the preferred embodiment, the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
terminate the first file system stack and the second file system stack … in response to detecting the end of the backup. (Abbott ¶ 0062: Another component of the Java VM is the stack area 195, which is used for storing the stacks 196, 198 associated with the execution of different threads on the Java VM; Abbott ¶ 0131: Finally the method concludes with calling the JVM system components to perform their individual save operations (step 745), before the save routine eventually terminates (step 750) with the completed snapshot. Note that in the preferred embodiment, the user can determine what action occurs upon termination of the snapshot routine by setting a parameter in the initial save call. The two available options are either to return control back to the application for continued processing, or else to terminate Java VM, so that the snapshot routine is effectively the end of the application)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the data storage system of Venetsanopoulos with the data storage system of Abbott.
Motivation to do so would be to improve the functioning of Venetsanopoulos executing backup requests with the ability in similar reference Abbott to execute save requests but with the improvement of user-determined actions.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement improved run-time performance as seen in Abbott ¶ 0061.
Regarding claim 5, Venetsanopoulos in view of Abbott teaches:
receiving a user-triggered request to ingest data from the host, wherein sending the request to initiate the backup is in response to reception of the user-triggered request. (Venetsanopoulos FIG. 20A, ¶ 0156-0157: The virtual disk snapshot process 2000 can begin with a decision 2002. The decision 2002 can determine whether a new virtual disk snapshot request has been received … Once the decision 2002 determines that a new virtual disk snapshot request has been received, a virtual disk snapshot command can be formed 2004. Next, the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see Venetsanopoulos ¶ 0189, "the system installation is active, and VMs and containers are running. Assume that the user snapshots a VM" and ¶ 0199, "Users can login to the bucket service via the GUI and create new, empty buckets, and thereafter users can fill the buckets with virtual storage resources (e.g., snaphots)")
Regarding claim 10, Venetsanopoulos in view of Abbott teaches:
providing a plurality of endpoints at the distributed backup system, the plurality of endpoints being in communication with the file system stack for backing up data. (Venetsanopoulos ¶ 0019-0023: Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; FIGs. 6-8, ¶ 0077-0079: On the hyperconverged setup, Rok runs as a software-only solution on the commodity hardware that the compute and storage stacks are also running. Rok interacts with the storage software stack, and the compute platform interacts with Rok; Venetsanopoulos ¶ 0093-0094: the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
Regarding claim 14, Venetsanopoulos in view of Abbott teaches:
creating, prior to creation of the first file system stack and based at least in part on sending the request to initiate the backup, a third file system stack at a third node of the distributed backup system that provides a third path to a third network file share endpoint at the host via a third network file share client at the third node, (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a third stack contemplated in the Rok installations of FIGs. 6-8; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to third network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
wherein a third portion of the data for the backup is received by the third file system stack at the third node via the third network file share endpoint and based at least in part on the sending the request to the backup agent. (Venetsanopoulos FIG. 20A, ¶ 0157-0159: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML); see contextually ¶ 0255: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations); see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows a stack receiving data for backup]; see a third stack contemplated in the Rok installations of FIGs. 6-8; see ¶ 0239-0240: the bucket service makes a request to the SMML 2314 (e.g., a composition service of the SMML) to make a snapshot of the virtual storage resource (VSR). The composition service of the SMML, upon receiving the request to make the snapshot, can create 2316 the snapshot of the VSR; see FIGs. 6-9, ¶ 0093: The actual data distribution across the network is done by Service 905 [third network file share endpoint]; FIG. 20A, ¶ 0156-0157: the virtual disk snapshot command can be translated 2006 to a virtual storage resource snapshot command. The virtual storage resource snapshot command can then be transmitted 2008 to the storage mobility and management layer (SMML) [shows request sent to backup agent])
Regarding claim 15, Venetsanopoulos in view of Abbott teaches:
wherein at least part of the third portion of the data is received in parallel with reception of the first portion of the data or the second portion of the data. (Venetsanopoulos ¶ 0255-0259: Another aspect of the invention pertains to sharing of buckets between SMMLs (e.g., Rok installations). Here, buckets containing one or more files can be shared over one or more networks. In one embodiment, different SMMLs can share buckets between one another in a peer-to-peer manner; see ¶ 0199: A file can be a snapshot that is managed by the SMML. The snapshots can pertain to files that originated from a virtualization platform like VMware, vSphere, or from a container platform like Docker, but which are backed by a virtual storage resource managed by the SMML [shows a stack receiving data for backup]; see a third stack contemplated in the Rok installations of FIGs. 6-8; see Venetsanopoulos ¶ 0199, "Users can login to the bucket service via the GUI and create new, empty buckets, and thereafter users can fill the buckets with virtual storage resources (e.g., snaphots)")
Claims 2-3 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Venetsanopoulos in view of Abbott in further view of Akirav et al., U.S. Patent Application Publication No. 2015/0286423 (hereinafter Akirav).
Regarding claims 2 and 17, Venetsanopoulos in view of Abbott teaches all the features with respect to claims 1 and 16 above including:
creating, prior to creation of the first file system stack and based at least in part on sending the request to initiate the backup, a third file system stack at a third node of the distributed backup system that provides a third path to a third network file share endpoint at the host via a third network file share client at the third node, wherein the first file system stack is created at the first node of the distributed backup system… (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path [shows path to endpoint] ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see a third stack contemplated in the Rok installations of FIGs. 6-8; see also FIG. 9, ¶ 0093-0094: The actual data distribution across the network is done by Service 905 [relevant to third network file share client] ... the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
Venetsanopoulos in view of Abbott does not expressly disclose being created “based at least in part on a failure condition or a traffic condition at the third node.”
However, Akirav addresses this by teaching being created “based at least in part on a failure condition or a traffic condition at the third node.” (Akirav FIG. 27, ¶ 0153: If the at least one attempt to reuse the existing FlashCopy target volume does fail, the method 2700 dynamically allocates a new Flashcopy target volume for the Flashcopy backup (step 2710); Akirav FIG. 29, ¶ 0155: If the at least one attempt to reuse the existing FlashCopy target volume does fail, the method dynamically allocates a new Flashcopy target volume for the Flashcopy backup from a global pool of Flashcopy backup target volumes shared by a plurality of device classes (step 2910))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the data storage system of Venetsanopoulos with the data storage system of Abbott.
Motivation to do so would be to improve the functioning of Venetsanopoulos initializing virtual disks with the ability in similar reference Akirav also initializing virtual disks but with the improvement of failover techniques.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement improved data storage utilization and recycling as seen in Akirav ¶ 0004.
Regarding claims 3 and 18, Venetsanopoulos in view of Abbott teaches all the features with respect to claims 1 and 16 above but does not expressly disclose:
determining that a scheduled time for an ingest of data from the host is satisfied, wherein sending the request to initiate the backup is in response to determining that the scheduled time for the ingest of data from the host is satisfied.
However, Akirav addresses this by teaching:
determining that a scheduled time for an ingest of data from the host is satisfied, wherein sending the request to initiate the backup is in response to determining that the scheduled time for the ingest of data from the host is satisfied. (Akirav ¶ 0090-0091: Flashcopy backups of the production volume P (e.g., a source 402) are scheduled periodically. When a Flashcopy backup of P (e.g., the source 402) is initiated at time T0 within the SVC, a space efficient FlashCopy target volume T0 is created; Akirav FIG. 25, ¶ 0147: the method 2500 ingests the Flashcopy backup according to the per Flashcopy backup basis as previously scheduled/planned (step 2510))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the data storage system of Venetsanopoulos with the data storage system of Abbott.
Motivation to do so would be to improve the functioning of Venetsanopoulos initializing virtual disks with the ability in similar reference Akirav also initializing virtual disks but with the improvement of scheduling techniques.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement improved data storage utilization and recycling as seen in Akirav ¶ 0004.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Venetsanopoulos in view of Abbott in further view of Akirav in further view of Prabhakar et al., U.S. Patent Application Publication No. 2018/0095915 (provided in the IDS due to use in the parent application; hereinafter Prabhakar).
Regarding claim 4, Venetsanopoulos in view of Abbott and Akirav teaches all the features with respect to claim 3 above including:
wherein determining that the scheduled time for an ingest of data from the host is satisfied is in accordance with … one or more of frequency of full backups, frequency of incremental backups, and amount of time to retain the full backups and the incremental backups. (Akirav ¶ 0004: data, data files, and/or data records are also required to be stored, retained, and/or saved for various periods of time for subsequent retrieval and/or use [in light of the 'one or more of' language]; see also Akirav ¶ 0090: Flashcopy backups of the production volume P (e.g., a source 402) are scheduled periodically. When a Flashcopy backup of P (e.g., the source 402) is initiated at time T0 within the SVC, a space efficient FlashCopy target volume T0 is created; Akirav FIG. 25, ¶ 0147: The method 2500 determines from the parameter whether or not to keep the Flashcopy backup (e.g., point-in-time backup) (step 2508). If yes, the method 2500 ingests the Flashcopy backup according to the per Flashcopy backup basis as previously scheduled/planned (step 2510))
Venetsanopoulos in view of Abbott and Akirav does not expressly disclose a service level agreement that defines one or more of frequency of full backups, frequency of incremental backups, and amount of time to retain the full backups and the incremental backups.
However, Prabhakar addresses this by teaching a service level agreement that defines one or more of frequency of full backups, frequency of incremental backups, and amount of time to retain the full backups and the incremental backups. (Prabhakar ¶ 0209: A Linux file system may provide various preferences (primarily SLA) during a session of a file (opened file), such as priority between file sessions, the amount of buffering of blocks, the retention/life time preferences for various blocks, alerts for resource thresholds and contentions, and performance statistics [in light of the 'one or more of' language]) (Prabhakar ¶ 0209: A Linux file system may provide various preferences (primarily SLA) during a session of a file (opened file), such as priority between file sessions, the amount of buffering of blocks, the retention/life time preferences for various blocks, alerts for resource thresholds and contentions, and performance statistics [in light of the 'one or more of' language])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the networked data storage system of Venetsanopoulos with the networked data storage system of Prabhakar.
Motivation to do so would be to improve the functioning of Venetsanopoulos as modified scheduling backups with the ability in similar reference Prabhakar also scheduling backups but with the improvement of provided preferences.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement improved contextual integrity of searchable content within a resource as seen in Prabhakar ¶ 0374.
Claims 8 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Venetsanopoulos in view of Abbott in further view of Prabhu et al., U.S. Patent Application Publication No. 2017/0315872 (provided in the IDS due to use in the parent application; hereinafter Prabhu).
Regarding claim 8, Venetsanopoulos in view of Abbott teaches all the features with respect to claim 1 above including:
wherein the distributed backup system comprises a plurality of nodes, wherein the file system stack is created at one from the plurality of nodes, (Venetsanopoulos shows file system stacks in ¶ 0019-0023: Rok is a storage framework that allows one to create arbitrary Storage Processing Units (SPUs) in user-space and interconnect them dynamically, creating dynamic I/O pipelines … By interconnecting different SPUs, one can dynamically stack different data services and inject/remove new services on-the-fly, in a live I/O data path ... Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; see nodes in FIGs. 6-8, ¶ 0077-0079: On the hyperconverged setup, Rok runs as a software-only solution on the commodity hardware that the compute and storage stacks are also running. Rok interacts with the storage software stack, and the compute platform interacts with Rok; see nodes also in Venetsanopoulos ¶ 0093-0094: the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
Venetsanopoulos in view of Abbott does not expressly disclose:
wherein an internet protocol (IP) address of the node with the file system stack is provided to the backup agent.
However, Prabhu addresses this by teaching:
wherein an internet protocol (IP) address of the node with the file system stack is provided to the backup agent. (Prabhu ¶ 0183-0187: FIG. 7D depicts an example of a clone-from-backup activity. A clone-from-backup activity may be implemented by performing a get host info operation 730 … and a build host stack operation 734; 1. SMCore obtains the host details such as IP address/initiators through SCU [shows providing an IP address]; 5. Build the host side stack which includes importing disk group, activating host volumes and mounting file systems on the cloned LUNs [shows the node having the file system stack]; elements relevant to the claimed backup agent are shown in ¶ 0143-0146, ¶ 0143 showing an 'agent': Examples of activities are discussed in more detail below with respect to FIGS. 7A-7E. In addition to operations implemented in the implementation module, other activities may be performed by the management component (including the storage abstraction layer, or SAL); ¶ 0146 showing backup capabilities: FIG. 7A depicts an example of a backup activity)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the networked data storage system of Venetsanopoulos as modified with the mounted file system environment of Prabhu.
In addition, both of the references (Venetsanopoulos as modified and Prabhu) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as networked management of backups.
Motivation to do so would be the teaching, suggestion, or motivation for a person of ordinary skill in the art to import desired host information in a manner that renders the need for a human operator unnecessary as seen in Prabhu (¶ 0214).
Regarding claim 12, Venetsanopoulos in view of Abbott teaches all the features with respect to claim 1 above but does not expressly disclose the following, addressed by Prabhu:
wherein an availability of a managed volume for backing up the data comprises a plurality of states comprising export requested, exported, resize requested, unexport requested, and destroyed. (Prabhu FIG. 3, ¶ 0032: The operation module 206 includes logic or instructions for carrying out different types of operations (e.g., a discover operation 310, a quiesce operation 318, etc.). The operations may be combined to perform various data management activities (e.g., backup, restore, clone, etc.) [Prabhu's quiesce operation 318 would be 'export requested'; unquiesce operation 320 would be 'exported'; deport operation 328 would be 'unexport requested']; FIG. 6, ¶ 0139: performing a deletion of a clone of the file system [shows a 'destroyed' state]; ¶ 0063, "validate operation 324 and the build operation 326" are relevant to 'resize requested')
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the networked data storage system of Venetsanopoulos as modified with the mounted file system environment of Prabhu.
In addition, both of the references (Venetsanopoulos as modified and Prabhu) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as networked management of backups.
Motivation to do so would be the teaching, suggestion, or motivation for a person of ordinary skill in the art to import desired host information in a manner that renders the need for a human operator unnecessary as seen in Prabhu (¶ 0214).
Regarding claim 13, Venetsanopoulos in view of Abbott and Prabhu teaches all the features with respect to claim 12 above including:
wherein the managed volume comprises an endpoint at the host, and wherein at least a portion of the data received by the first file system stack and the second file system stack is stored at the managed volume. (Venetsanopoulos ¶ 0019-0023: Rok creates an independent layer of data services that sits between the compute software stack, and the storage software stack ... Rok is then responsible for handling and manipulating the I/O requests, exposing and implementing the data services needed by the compute part, and finally interacting with the storage software stack, if needed, to persist the data; first and second file system stacks are shown in FIGs. 6-8, ¶ 0077-0079: On the hyperconverged setup, Rok runs as a software-only solution on the commodity hardware that the compute and storage stacks are also running. Rok interacts with the storage software stack, and the compute platform interacts with Rok; Venetsanopoulos shows data receipt in at least ¶ 0093-0094: the Data Service 905 implements a protocol heavily inspired by the peer-to-peer BitTorrent protocol. Partly acting as a torrent client, it enables each Rok installation to become one edge (or peer) of a peer-to-peer network)
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Venetsanopoulos in view of Abbott in further view of Akirav in further view of Prabhu.
Regarding claim 9, Venetsanopoulos in view of Abbott and Akirav teaches all the features with respect to claim 3 above but does not expressly disclose:
providing, to the backup agent, a first internet protocol address associated with the first node and a second internet protocol address associated with the second node.
However, Prabhu addresses this by teaching:
providing, to the backup agent, a first internet protocol address associated with the first node and a second internet protocol address associated with the second node. (Prabhu ¶ 0183-0187: FIG. 7D depicts an example of a clone-from-backup activity. A clone-from-backup activity may be implemented by performing a get host info operation 730 … and a build host stack operation 734; 1. SMCore obtains the host details such as IP address/initiators through SCU [shows providing an IP address]; 5. Build the host side stack which includes importing disk group, activating host volumes and mounting file systems on the cloned LUNs; Prabhu ¶ 0143-0146, ¶ 0143 contemplate an 'agent': Examples of activities are discussed in more detail below with respect to FIGS. 7A-7E. In addition to operations implemented in the implementation module, other activities may be performed by the management component (including the storage abstraction layer, or SAL); ¶ 0146 showing backup capabilities: FIG. 7A depicts an example of a backup activity)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the networked data storage system of Venetsanopoulos as modified with the mounted file system environment of Prabhu.
In addition, both of the references (Venetsanopoulos as modified and Prabhu) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as networked management of backups.
Motivation to do so would be the teaching, suggestion, or motivation for a person of ordinary skill in the art to import desired host information in a manner that renders the need for a human operator unnecessary as seen in Prabhu (¶ 0214).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Venetsanopoulos in view of Abbott in further view of Littlefield et al., U.S. Patent Application Publication No. 2008/0147997 (provided in the IDS due to use in the parent application; hereinafter Littlefield).
Regarding claim 11, Venetsanopoulos in view of Abbott teaches all the features with respect to claim 10 above but does not expressly disclose:
wherein the plurality of endpoints comprises the network file share endpoint and a Server Message Block (SMB) endpoint.
However, Littlefield addresses this by teaching:
wherein the plurality of endpoints comprises the network file share endpoint and a Server Message Block (SMB) endpoint. (Littlefield ¶ 0011: A NAS device often contains a reduced capacity or minimized operating and file management system (e.g., a microkernel) and normally processes input/output (I/O) requests by supporting common file sharing protocols such as the Unix network file system (NFS), DOS/Windows, and server message block/common Internet file system (SMB/CIFS))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the backup management of Venetsanopoulos as modified with the backup management and messaging of Littlefield.
In addition, both of the references (Venetsanopoulos as modified and Littlefield) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of backups.
Motivation to do so also would be the teaching, suggestion, or motivation for one of ordinary skill in the art to utilize data agents to handle different types of data for operations including archiving, migrating, and restoring data as seen in Littlefield (¶ 0047-0048).
Allowable Subject Matter
Claims 6-7 and 19 are 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kivity et al., U.S. Patent Application Publication No. 2013/0132968; see Kivity FIGs. 2-3 describing main stacks and alternate stacks to address a received I/O request, relevant to at least the independent claim limitations involving a request to initiate a backup and utilizing a first file system stack and a second file system stack.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEDIDIAH P FERRER whose telephone number is (571)270-7695. The examiner can normally be reached Monday, Tuesday, Friday, 12:00pm-9:00pm.
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, Kavita Stanley can be reached at (571)272-8352. 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.
/J.P.F/Examiner, Art Unit 2153 May 28, 2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153
Prosecution Insights