Non-Final Office Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 21 and 23-25 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 2 of U.S. Patent No. 11,816,007 B1. (hereinafter ‘007). Although the claims at issue are not identical, they are not patentably distinct from each other because of the following.
Referring to claim 21:
Claim 1 of ‘007 discloses a method, comprising: creating a secondary node on-demand; generating an on-demand volume accessible to the secondary node. However, claim 1 of ‘007 does not explicitly disclose creating a virtual machine within a cloud computing environment and making the on-demand volume accessible to the virtual machine. In col. 7, lines 63-65, ‘007 discloses the nodes may be implemented as hardware, software (e.g., a storage virtual machine) or combination thereof. In Figure 1 and in col. 6, lines 57-63, ‘007 discloses the cloud computing environment comprises servers, processors, memory, storage devices, and/or other resources that can be used by various types of environments for hosting instances of the restore process, such as a container orchestration platform, a virtual machine hypervisor, a serverless thread architecture, etc. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the node of claim 1 of ‘007 as a virtual machine within a cloud computing environment and make the on-demand volume accessible to the virtual machine. A person of ordinary skill in the art would have been motivated to make the modification because a node is a broad term that includes the virtual machine within a cloud disclosed in the specification of ‘007. Benefits of using a virtual machine are that it can be used on different physical devices, and a single physical device can host multiple virtual machines.
Claim 1 of ‘007 discloses copying data from a snapshot stored within objects of an object store to the on-demand volume (a restore process is initiated to restore the on-demand volume to a state of the primary volume captured by a snapshot stored within an object store).
Claim 2 of ‘007 discloses in response to receiving a request from a requestor for a block of data not yet copied from the snapshot to the on-demand volume, retrieving the block from the snapshot in the object store (in response to receiving a first request from a client (requestor) for a block of data not yet restored from the snapshot to the on-demand volume, retrieving the block from the snapshot in the object store).
Claim 2 of ‘007 discloses caching the block within a cloud block map as a cached block accessible to the requestor, wherein the cloud block map maps a cloud block number of the block to the cached block (caching the block within a cloud block map as a cached block accessible to the client (requestor), wherein the cloud block map maps a cloud block number of the block to a physical volume block number of the cached block).
Referring to claim 23, claim 1 of ‘007 discloses in response to restoring metadata of a file system captured by the snapshot, providing the requestor with access to the on-demand volume during the copying of the data to the on-demand volume (in response to copying metadata in the snapshot to the secondary node, providing clients (requestors) with read and write access to the on-demand volume through the secondary node during the restore process).
Referring to claim 24, claim 2 of ‘007 discloses utilizing the cloud block map to cache blocks, not yet copied to the on-demand volume, for access by the requestor while the data is being copied to the on-demand volume hosted by the virtual machine (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)) as part of performing disaster recovery within the cloud computing environment (claim 1 of ‘007 discloses the restore is performed in response to a failure of a first node).
Referring to claim 25, claim 2 of ‘007 discloses provide the requestor access to cached blocks through the cloud block map while the data is being copied to the on-demand volume (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)). However, claim 2 of ‘007 does not explicitly disclose providing the requestor with local access. In col. 17, lines 14-17, ‘007 discloses the cloud block map may be stored within local storage. It would have been obvious to one of ordinary skill at the time of filing of the invention to make the cloud block map accessible to the client locally accessible. A person of ordinary skill in the art would have been motivated to make the modification because the cloud block map may be stored within the local storage of the device so that the client can be provided with low latency access to cached blocks within the local storage (‘007: col. 17, lines 14-17).
Claims 28, 30-32, 35, and 37-39 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 2 of U.S. Patent No. 11,816,007 B1, in view of the well-known practice of using an apparatus, device, computer system, or software to perform a method.
Referring to claim 28:
Claim 1 of ‘007 discloses a method. However, claim 1 of ‘007 does not explicitly disclose a computing device comprising: a memory comprising machine executable code; and a processor coupled to the memory, the processor configured to execute the machine executable code. The Examiner takes Official Notice that it is well-known to implement a method with a computing device or software. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the method of claim 1 of ‘007 with a computing device. A person of ordinary skill in the art would have been motivated to make the modification because using an apparatus, device, computer system, or software to perform a method puts into practice the method and gives it a real world application.
Claim 1 of ‘007 discloses creating a secondary node on-demand; generating an on-demand volume accessible to the secondary node. However, claim 1 of ‘007 does not explicitly disclose creating a virtual machine within a cloud computing environment and making the on-demand volume accessible to the virtual machine. In col. 7, lines 63-65, ‘007 discloses the nodes may be implemented as hardware, software (e.g., a storage virtual machine) or combination thereof. In Figure 1 and in col. 6, lines 57-63, ‘007 discloses the cloud computing environment comprises servers, processors, memory, storage devices, and/or other resources that can be used by various types of environments for hosting instances of the restore process, such as a container orchestration platform, a virtual machine hypervisor, a serverless thread architecture, etc. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the node of claim 1 of ‘007 as a virtual machine within a cloud computing environment and make the on-demand volume accessible to the virtual machine. A person of ordinary skill in the art would have been motivated to make the modification because a node is a broad term that includes the virtual machine within a cloud disclosed in the specification of ‘007. Benefits of using a virtual machine are that it can be used on various different physical devices, and a single physical device can host multiple virtual machines.
Claim 1 of ‘007 discloses copying data from a snapshot stored within objects of an object store to the on-demand volume (a restore process is initiated to restore the on-demand volume to a state of the primary volume captured by a snapshot stored within an object store).
Claim 2 of ‘007 discloses in response to receiving a request from a requestor for a block of data not yet copied from the snapshot to the on-demand volume, retrieving the block from the snapshot in the object store (in response to receiving a first request from a client (requestor) for a block of data not yet restored from the snapshot to the on-demand volume, retrieving the block from the snapshot in the object store).
Claim 2 of ‘007 discloses caching the block within a cloud block map as a cached block accessible to the requestor, wherein the cloud block map maps a cloud block number of the block to the cached block (caching the block within a cloud block map as a cached block accessible to the client (requestor), wherein the cloud block map maps a cloud block number of the block to a physical volume block number of the cached block).
Referring to claims 30 and 37, claim 1 of ‘007 discloses in response to restoring metadata of a file system captured by the snapshot, providing the requestor with access to the on-demand volume during the copying of the data to the on-demand volume (in response to copying metadata in the snapshot to the secondary node, providing clients (requestors) with read and write access to the on-demand volume through the secondary node during the restore process).
Referring to claims 31 and 38, claim 2 of ‘007 discloses utilizing the cloud block map to cache blocks, not yet copied to the on-demand volume, for access by the requestor while the data is being copied to the on-demand volume hosted by the virtual machine (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)) as part of performing disaster recovery within the cloud computing environment (claim 1 of ‘007 discloses the restore is performed in response to a failure of a first node).
Referring to claims 32 and 39, claim 2 of ‘007 discloses provide the requestor access to cached blocks through the cloud block map while the data is being copied to the on-demand volume (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)). However, claim 2 of ‘007 does not explicitly disclose providing the requestor with local access. In col. 17, lines 14-17, ‘007 discloses the cloud block map may be stored within local storage. It would have been obvious to one of ordinary skill at the time of filing of the invention to make the cloud block map accessible to the client locally accessible. A person of ordinary skill in the art would have been motivated to make the modification because the cloud block map may be stored within the local storage of the device so that the client can be provided with low latency access to cached blocks within the local storage (‘007: col. 17, lines 14-17).
Referring to claim 35:
Claim 1 of ‘007 discloses a method. However, claim 1 of ‘007 does not explicitly disclose a non-transitory machine readable medium comprising instructions for performing a method, which when executed by a machine, causes the machine to perform operations. The Examiner takes Official Notice that it is well-known to implement a method with a computing device or software. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the method of claim 1 of ‘007 with a non-transitory machine readable medium comprising instructions for performing a method. A person of ordinary skill in the art would have been motivated to make the modification because using an apparatus, device, computer system, or software to perform a method puts into practice the method and gives it a real world application.
Claim 1 of ‘007 discloses creating a secondary node on-demand; generating an on-demand volume accessible to the secondary node. However, claim 1 of ‘007 does not explicitly disclose creating a virtual machine within a cloud computing environment and making the on-demand volume accessible to the virtual machine. In col. 7, lines 63-65, ‘007 discloses the nodes may be implemented as hardware, software (e.g., a storage virtual machine) or combination thereof. In Figure 1 and in col. 6, lines 57-63, ‘007 discloses the cloud computing environment comprises servers, processors, memory, storage devices, and/or other resources that can be used by various types of environments for hosting instances of the restore process, such as a container orchestration platform, a virtual machine hypervisor, a serverless thread architecture, etc. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the node of claim 1 of ‘007 as a virtual machine within a cloud computing environment and make the on-demand volume accessible to the virtual machine. A person of ordinary skill in the art would have been motivated to make the modification because a node is a broad term that includes the virtual machine within a cloud disclosed in the specification of ‘007. Benefits of using a virtual machine are that it can be used on various different physical devices, and a single physical device can host multiple virtual machines.
Claim 1 of ‘007 discloses copying data from a snapshot stored within objects of an object store to the on-demand volume (a restore process is initiated to restore the on-demand volume to a state of the primary volume captured by a snapshot stored within an object store).
Claims 21, 23-25, 28, 30-32, 35, and 37-39 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4, 9, 12, 15, and 18 of U.S. Patent No. 12,298,870 B2. (hereinafter ‘870). Although the claims at issue are not identical, they are not patentably distinct from each other because of the following.
Referring to claim 21:
Claim 1 of ‘870 discloses a method, comprising: creating a secondary node on-demand; generating an on-demand volume accessible to the secondary node. However, claim 1 of ‘870 does not explicitly disclose creating a virtual machine within a cloud computing environment and making the on-demand volume accessible to the virtual machine. In col. 8, lines 3-5, ‘870 discloses the nodes may be implemented as hardware, software (e.g., a storage virtual machine) or combination thereof. In Figure 1 and in col. 6, lines 64-67 continued in col. 7, lines 1-3, ‘870 discloses the cloud computing environment comprises servers, processors, memory, storage devices, and/or other resources that can be used by various types of environments for hosting instances of the restore process, such as a container orchestration platform, a virtual machine hypervisor, a serverless thread architecture, etc. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the node of claim 1 of ‘870 as a virtual machine within a cloud computing environment and make the on-demand volume accessible to the virtual machine. A person of ordinary skill in the art would have been motivated to make the modification because a node is a broad term that includes the virtual machine within a cloud disclosed in the specification of ‘870. Benefits of using a virtual machine are that it can be used on various different physical devices, and a single physical device can host multiple virtual machines.
Claim 1 of ‘870 discloses copying data from a snapshot stored within objects of an object store to the on-demand volume (a restore process is initiated to restore the on-demand volume to a state of the primary volume captured by a snapshot stored within an object store).
Claim 4 of ‘870 discloses in response to receiving a request from a requestor for a block of data not yet copied from the snapshot to the on-demand volume, retrieving the block from the snapshot in the object store (retrieving a block of data from the snapshot in the object store based upon a request from a client (requestor) for the block of data not yet restored to the on-demand volume).
Claim 4 of ‘870 discloses caching the block within a cloud block map as a cached block accessible to the requestor, wherein the cloud block map maps a cloud block number of the block to the cached block (caching the block within a cloud block map as a cached block accessible to the client (requestor), wherein the cloud block map maps a cloud block number of the block to a physical volume block number of the cached block).
Referring to claim 23, claim 1 of ‘870 discloses in response to restoring metadata of a file system captured by the snapshot, providing the requestor with access to the on-demand volume during the copying of the data to the on-demand volume (in response to copying metadata in the snapshot to the secondary node, providing clients (requestors) with read and write access to the on-demand volume through the secondary node during the restore process).
Referring to claim 24, claim 4 of ‘870 discloses utilizing the cloud block map to cache blocks, not yet copied to the on-demand volume, for access by the requestor while the data is being copied to the on-demand volume hosted by the virtual machine (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)) as part of performing disaster recovery within the cloud computing environment (claim 1 of ‘870 discloses the restore is performed in response to a failure of a first node).
Referring to claim 25, claim 4 of ‘870 discloses provide the requestor access to cached blocks through the cloud block map while the data is being copied to the on-demand volume (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)). However, claim 4 of ‘870 does not explicitly disclose providing the requestor with local access. In col. 17, lines 20-23, ‘870 discloses the cloud block map may be stored within local storage. It would have been obvious to one of ordinary skill at the time of filing of the invention to make the cloud block map accessible to the client locally accessible. A person of ordinary skill in the art would have been motivated to make the modification because the cloud block map may be stored within the local storage of the device so that the client can be provided with low latency access to cached blocks within the local storage (‘870: col. 17, lines 20-23).
Referring to claim 28:
Claim 9 of ‘870 discloses a computing device comprising: a memory comprising machine executable code; and a processor coupled to the memory, the processor configured to execute the machine executable code.
Claim 9 of ‘870 discloses creating a secondary node on-demand; generating an on-demand volume accessible to the secondary node. However, claim 9 of ‘870 does not explicitly disclose creating a virtual machine within a cloud computing environment and making the on-demand volume accessible to the virtual machine. In col. 8, lines 3-5, ‘870 discloses the nodes may be implemented as hardware, software (e.g., a storage virtual machine) or combination thereof. In Figure 1 and in col. 6, lines 64-67 continued in col. 7, lines 1-3, ‘870 discloses the cloud computing environment comprises servers, processors, memory, storage devices, and/or other resources that can be used by various types of environments for hosting instances of the restore process, such as a container orchestration platform, a virtual machine hypervisor, a serverless thread architecture, etc. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the node of claim 9 of ‘870 as a virtual machine within a cloud computing environment and make the on-demand volume accessible to the virtual machine. A person of ordinary skill in the art would have been motivated to make the modification because a node is a broad term that includes the virtual machine within a cloud disclosed in the specification of ‘870. Benefits of using a virtual machine are that it can be used on various different physical devices, and a single physical device can host multiple virtual machines.
Claim 9 of ‘870 discloses copying data from a snapshot stored within objects of an object store to the on-demand volume (a restore process is initiated to restore the on-demand volume to a state of the primary volume captured by a snapshot stored within an object store).
Claim 12 of ‘870 discloses in response to receiving a request from a requestor for a block of data not yet copied from the snapshot to the on-demand volume, retrieving the block from the snapshot in the object store (retrieve a block of data from the snapshot in the object store based upon a request from a client (requestor) for the block of data not yet restored to the on-demand volume).
Claim 12 of ‘870 discloses caching the block within a cloud block map as a cached block accessible to the requestor, wherein the cloud block map maps a cloud block number of the block to the cached block (cache the block within a cloud block map as a cached block accessible to the client (requestor), wherein the cloud block map maps a cloud block number of the block to a physical volume block number of the cached block).
Referring to claim 30, claim 9 of ‘870 discloses in response to restoring metadata of a file system captured by the snapshot, providing the requestor with access to the on-demand volume during the copying of the data to the on-demand volume (in response to copying metadata in the snapshot to the secondary node, providing clients (requestors) with read and write access to the on-demand volume through the secondary node during the restore process).
Referring to claim 31, claim 12 of ‘870 discloses utilizing the cloud block map to cache blocks, not yet copied to the on-demand volume, for access by the requestor while the data is being copied to the on-demand volume hosted by the virtual machine (cache the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)) as part of performing disaster recovery within the cloud computing environment (claim 9 of ‘870 discloses the restore is performed in response to a failure of a first node).
Referring to claim 32, claim 12 of ‘870 discloses provide the requestor access to cached blocks through the cloud block map while the data is being copied to the on-demand volume (cache the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)). However, claim 12 of ‘870 does not explicitly disclose providing the requestor with local access. In col. 17, lines 20-23, ‘870 discloses the cloud block map may be stored within local storage. It would have been obvious to one of ordinary skill at the time of filing of the invention to make the cloud block map accessible to the client locally accessible. A person of ordinary skill in the art would have been motivated to make the modification because the cloud block map may be stored within the local storage of the device so that the client can be provided with low latency access to cached blocks within the local storage (‘870: col. 17, lines 20-23).
Referring to claim 35:
Claim 15 of ‘870 discloses a non-transitory machine readable medium comprising instructions for performing a method, which when executed by a machine, causes the machine to perform operations.
Claim 15 of ‘870 discloses creating a secondary node on-demand; generating an on-demand volume accessible to the secondary node. However, claim 15 of ‘870 does not explicitly disclose creating a virtual machine within a cloud computing environment and making the on-demand volume accessible to the virtual machine. In col. 8, lines 3-5, ‘870 discloses the nodes may be implemented as hardware, software (e.g., a storage virtual machine) or combination thereof. In Figure 1 and in col. 6, lines 64-67 continued in col. 7, lines 1-3, ‘870 discloses the cloud computing environment comprises servers, processors, memory, storage devices, and/or other resources that can be used by various types of environments for hosting instances of the restore process, such as a container orchestration platform, a virtual machine hypervisor, a serverless thread architecture, etc. It would have been obvious to one of ordinary skill at the time of filing of the invention to implement the node of claim 15 of ‘870 as a virtual machine within a cloud computing environment and make the on-demand volume accessible to the virtual machine. A person of ordinary skill in the art would have been motivated to make the modification because a node is a broad term that includes the virtual machine within a cloud disclosed in the specification of ‘870. Benefits of using a virtual machine are that it can be used on various different physical devices, and a single physical device can host multiple virtual machines.
Claim 15 of ‘870 discloses copying data from a snapshot stored within objects of an object store to the on-demand volume (a restore process is initiated to restore the on-demand volume to a state of the primary volume captured by a snapshot stored within an object store).
Claim 18 of ‘870 discloses in response to receiving a request from a requestor for a block of data not yet copied from the snapshot to the on-demand volume, retrieving the block from the snapshot in the object store (retrieve a block of data from the snapshot in the object store based upon a request from a client (requestor) for the block of data not yet restored to the on-demand volume).
Claim 18 of ‘870 discloses caching the block within a cloud block map as a cached block accessible to the requestor, wherein the cloud block map maps a cloud block number of the block to the cached block (cache the block within a cloud block map as a cached block accessible to the client (requestor), wherein the cloud block map maps a cloud block number of the block to a physical volume block number of the cached block).
Referring to claim 37, claim 15 of ‘870 discloses in response to restoring metadata of a file system captured by the snapshot, providing the requestor with access to the on-demand volume during the copying of the data to the on-demand volume (in response to copying metadata in the snapshot to the secondary node, providing clients (requestors) with read and write access to the on-demand volume through the secondary node during the restore process).
Referring to claim 38, claim 18 of ‘870 discloses utilizing the cloud block map to cache blocks, not yet copied to the on-demand volume, for access by the requestor while the data is being copied to the on-demand volume hosted by the virtual machine (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)) as part of performing disaster recovery within the cloud computing environment (claim 15 of ‘870 discloses the restore is performed in response to a failure of a first node).
Referring to claim 39, claim 18 of ‘870 discloses provide the requestor access to cached blocks through the cloud block map while the data is being copied to the on-demand volume (caching the block, not yet restored from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the client (requestor)). However, claim 18 of ‘870 does not explicitly disclose providing the requestor with local access. In col. 17, lines 20-23, ‘870 discloses the cloud block map may be stored within local storage. It would have been obvious to one of ordinary skill at the time of filing of the invention to make the cloud block map accessible to the client locally accessible. A person of ordinary skill in the art would have been motivated to make the modification because the cloud block map may be stored within the local storage of the device so that the client can be provided with low latency access to cached blocks within the local storage (‘870: col. 17, lines 20-23).
Allowable Subject Matter
Claims 22, 26, 27, 29, 33, 34, 36, and 40 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.
Claims 21, 23-25, 28, 30-32, 35, and 37-39 would be allowable if the non-statutory double patenting rejection was overcome.
The following is a statement of reasons for the indication of allowable subject matter. US 11,726,696 B2 discloses a cloud block map for caching data during an on-demand restore.
With respect to claims 21, 28, and 35, the prior art does not teach or reasonably suggest, in combination with the remaining limitations, in response to creating a virtual machine within a cloud computing environment, creating an on-demand volume accessible to the virtual machine; copying data from a snapshot stored within objects of an object store to the on-demand volume; and caching a block of data, not yet copied from the snapshot to the on-demand volume, within a cloud block map as a cached block accessible to the requestor, wherein the cloud block map maps a cloud block number of the block to the cached block.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL C MASKULINSKI whose telephone number is (571)272-3649. The examiner can normally be reached Monday-Friday 8:00 am-5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bryce Bonzo can be reached at (571) 272-3655. 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.
/MICHAEL MASKULINSKI/Primary Examiner, Art Unit 2113
Prosecution Insights