DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-5 are pending.
Claim Objections
Claims 2-5 are objected to because of the following informalities:
-- claim 2 is dependent on non-claimed claim 7 --
-- claim 3 is dependent on non-claimed claim 8 --
-- claim 4 is dependent on non-claimed claim 9 --
-- claim 5 is dependent on non-claimed claim 11 --
-- VM -- is abbreviated without reciting full form in claim 1 --
-- memory dump or Random Access Memory (RAM) -- should be -- memory dump [[or]] of Random Access Memory -- in claim 1 line 11.
-- service)_based -- service)[[ _ ]] based -- in claim 3 line 2.
Appropriate correction is required.
Specification
The disclosure is objected to because of the following informalities:
-- RAM RAM -- should be -- RAM [.
Appropriate correction is required.
Drawing
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description:
-- DB 228 -- in [0044] missing from fig. 2.
-- DB deployed on five Nodes -- in [0044] while fig 2 only shows database on nodes 4-5 only i.e. only two nodes.
-- 200 A-N -- of fig. 6 is missing from the description
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description:
-- reference character 280 in fig. 2 is missing from description.
-- reference character 702 of fig. 7 is missing from description.
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-5 are rejected under 35 U.S.C. 112 (b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or joint inventor regards as the invention.
The following terms lack proper antecedent basis:
-- the virtual machine metadata information -- in claim 1 line 31.
-- the set of steps -- in claim 1 line 25
The following claim language is not clearly understood:
Claim 1 line 9 recites “VM storage image location”, and a VM memory image location”. It is unclear if the location for storing the VM image or for storing the storage image of VM or memory image. It is also unclear what, If any, is the difference between the storage image and memory image of VM.
Claim 1 line 5 recites “central orchestrator communicates with a plurality of virtual machines”. It is unclear if the orchestrator directly communicates with plurality of virtual machine or communicates with plurality of virtual machine indirectly e.g. via hypervisor.
Claim 1 lines 7-10 recites “passes a set of information”. It is unclear which component is passing the set of information to which component.
Claim 1 lines 13-14 recites “suspend operation dumps a memory of the virtual machine into a disk of hypervisor” and later in lines 16-17 recites “uploading virtual machine disk and the memory data into a virtual machine storage repository”. It is unclear if the memory dump of the virtual machine is stored in disk of hypervisor or in the repository or both.
Claim 1 in lines 24-25 recites “resuming the virtual machine…the set of step comprises:…creating a virtual machine using metadata (cl. 1 lines 37-38 ) … and performing resume functionality (cl. 1 lines 44 ). It is unclear if the virtual machine is created or resumed or both created/resumed under different conditions. In case it is being both created /resumed or either, pleas recite the respective conditions under which VM is created and/or resumed.
Claim 1 line 14 recites “disk of the hypervisor”. It is unclear what is being referred by disk of the hypervisor i.e. if the hypervisor has a disk or hypervisor is saved in a disk.
Claim 1 lines 16-18 recites “uploading both the virtual machine disk and the memory data into a virtual machine storage repository, and memory data into a memory storage repository”. It is unclear if the memory data is stored in one location or both virtual machine storage repository as well as memory storage repository. It is also unclear what is the memory data contains and if the virtual machine disk also contains memory data.
Claim 1 lines 19-20 recites “removing an entry of the virtual machine from the hypervisor”. It is unclear if the entry is present in which component of hypervisor and the entry contains what information.
Claim 1 line 24 recites “resuming the virtual machine in a saved state”. It is unclear if the virtual machine is resumed in the saved state or resumed from the saved state.
Claim 1 line 33-35 recites “downloading the virtual machine’s disk from virtual machine’s storage image location, and the virtual machine memory image from the memory image location”. It is unclear what is the difference between virtual machine’s disk and virtual machine memory image.
Remaining dependent claims 2-5 are also rejected due to deficiency inherited from the rejected independent claims.
* Applicant is advised to at least indicate support present in the specification for further defining/clarifying the claim language in case Applicant believe amendments would unduly narrow the scope of the claim.
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 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brunn et al. (US 2016/0335111 A1, hereafter Brunn) in view of Keagy et al. (US 8,656,018 B1, hereafter Keagy), and further in view of Uriel (US 2016/0378348 A1).
As per claim 1, Brunn teaches the invention substantially as claimed including a computerized method useful for saving a virtual machine comprising ([0027] hibernated VM, saving, run-time image):
creating a virtual machine on a hypervisor ([0016] hypervisor, create, VM );
issuing a request to a central orchestrator to save the virtual machine (fig. 3 virtual infrastructural manager VIM 254 NFV M&O 206 NFV orchestrator 250 [0026] turning off the VM, memory image of the VM is saved [0027] saving the run-time image), wherein the central orchestrator is accessed via a monitor interface ([0018] user interface [0054] NFV Orchestrator 250, user-interface, automated decision), and wherein the central orchestrator communicates with a plurality of virtual machines that includes the virtual machine ([0041] NFV Orchestrator 250, in other examples, can communicate and interact with Hypervisors [0016] VM, host, managed by Hypervisor [0039] [0017] VM can communicate with other entities);
with the central orchestrator, connecting to a hypervisor manager located on the hypervisor ([0041] NFV Orchestrator 250, in other examples, can communicate and interact with Hypervisors [0052] NFV Orchestrator 250, via VIM 254, instructs Hypervisor 219) where the virtual machine is located on the hypervisor (fig. 3 VMs 230 virtualization layer 222 hypervisor 219 ) and passes a set of information comprising a VM storage image location, and a VM memory image location, and wherein a VM memory image comprises a memory dump or Random Access Memory (RAM) of the VM ([0026] full runtime memory image of the VM );
with the hypervisor, performing a suspend operation on the virtual machine ( [0039] hypervisor, to stop, hibernate VMs), wherein the suspend operation dumps a memory of the virtual machine into a disk of the hypervisor ([0026] hibernating, VM, turn off VM, full run-time memory image , VM, saved, hibernation files on persistent storage);
shutting down the virtual machine ([0026] hibernating VM, turn off VM);
with the hypervisor manager, uploading both the virtual machine disk and the memory data into a virtual machine storage repository ([0046] deactivated virtual machines are stored on a persistent storage; fig. 3 DVM 272 Pool 274 persistent storage 220), and the memory data into a memory storage repository ([0026] runtime memory image of the VM is saved to one or more hibernation files on persistent storage), with the hypervisor manager, removing an entry of the virtual machine from the hypervisor;
with the hypervisor manager, sending a location information and the virtual machine's information to the central orchestrator for storage of the virtual machine's information;
resuming the virtual machine in a saved state with the central orchestrator (fig. 4 activate deactivated VMs from pool 312), wherein the set of steps comprises:
with the central orchestrator (fig. 3 virtual infrastructural manager VIM 254 NFV M&O 206 NFV orchestrator 250):
determining that there are sufficient resources to provision the virtual machine in a specified computing system ([0044] VIM 254, tracks and manages all VMs, hosted on a given set of hardware resource, tracks the hardware resources assigned to the each VM and hardware resources available i.e. determine the sufficiency of resources [0051] hardware resources which are available for assignment, whether there are hardware resources available for scale-out), and
connecting the central orchestrator to the hypervisor manager and passing the information containing the virtual machine's storage image location, the memory image location, and the virtual machine metadata information;
with the hypervisor manager:
downloading the virtual machine's disk from the virtual machine's storage image location (fig. 3 persistent storage 220 image file 270 deactivated virtual machine DVM 274 ), and the virtual machine memory image from the memory image location ([0016] use virtual machine image stored on persistent storage media), connecting to the hypervisor and creating a virtual machine using the virtual machine's metadata ([0016] hypervisor, create VM, use an image file stored on persistent storage media), and placing the virtual machine's memory image and the virtual machine's storage image in a specified location; and
with the hypervisor ([0016] Hypervisor, perform operations, activate, VM):
determining that the virtual machine's disk image and the virtual machine's memory image are present, and performing the resume functionality in the hypervisor (fig. 2 activate deactivated virtual machines 108 [0026] restarting hibernated VM, activating the run-time image, restored).
Brunn doesn’t specifically teach issuing a request to a central orchestrator to save the virtual machine; with the central orchestrator, connecting to a hypervisor manager located on the hypervisor; passes a set of information comprising a VM storage image location, and a VM memory image location; with the hypervisor manager, uploading; with the hypervisor manager, removing an entry of the virtual machine from the hypervisor; connecting the central orchestrator to the hypervisor manager and passing the information containing the virtual machine's storage image location, the memory image location, and the virtual machine metadata information; with the hypervisor manager: downloading the virtual machine's disk; connecting to the hypervisor; placing the virtual machine’s memory image and the virtual machine’s storage image in a specified location; and with the hypervisor: determining that the virtual machine’s disk image and te virtual machine’s memory image are present.
Keagy, however, teaches issuing a request to a central orchestrator to save the virtual machine (fig. 6 hypervisor management module 610 VM controller 635 proxy manager Hypervisor 640 640 Hypervisors; col 3 lines 63-67 hypervisor managers, interactions with hypervisors; col 5 lines 50-55 hypervisor management module, issues control messages to the various hypervisors in order to save an image, take a snapshot);
with the central orchestrator, connecting to a hypervisor manager located on the hypervisor (col 3 lines 63-67 hypervisor managers, interactions with hypervisors; fig. 4 Hypervisor 430 manager for Hypervisor 410 fig. 6 hypervisor management module 610 controller 635 proxy manager Hypervisor 640 640 Hypervisors);
passes a set of information comprising a VM storage image location, and a VM memory image location (fig. 9 image store 963 data storage 950 col 24 lines 10-20 provisioning messages, sent, identified hypervisor manager i.e. combining the provisioning message with the storage information);
with the hypervisor manager, uploading (fig. 6 hypervisor management module 610 VM controller 635 proxy manager Hypervisor 640 640 Hypervisors; col 5 lines 50-55 hypervisor management module, control message, hypervisor, snapshot, save an image i.e. uploading);
with the hypervisor manager, removing an entry of the virtual machine from the hypervisor (col 7 lines 20-28 management module, delete virtual machine configurations, delete the data, file system i.e. deleting the entry);
connecting the central orchestrator to the hypervisor manager (fig. 6 VM controller 635 proxy manager hypervisor 640 hypervisors ) and passing the information containing the virtual machine's storage image location, the memory image location, and the virtual machine metadata information ( fig. 9 image store 963 data storage 950 col 24 lines 10-20 provisioning messages, sent, identified hypervisor manager i.e. combining the provisioning message with the storage information; fig. 12 provisioning message 1205 col 28 lines 37-55 provisioning message, parameters i.e. VM metadata);
with the hypervisor manager (fig. 6 hypervisor management module 610 VM controller 635 proxy manager Hypervisor 640 640 Hypervisors):
downloading the virtual machine's disk (col 11 lines 48-64 hypervisor management module, control message, restore to a snapshot i.e. retrieving the snapshot to restore col 4 lines 40-50 retrieves the image 520 from image store 580);
connecting to the hypervisor (fig. 6 hypervisor management module 610 VM controller 635 proxy manager Hypervisor 640 640 Hypervisors);
placing the virtual machine’s memory image and the virtual machine’s storage image in a specified location (fig. 9 data storage 950 image storage 963 col 5 lines 50-55 hypervisor management module, control message, hypervisor, snapshot, save an image).
It would have been obvious to one of ordinary skills in the art before the effective filing date of the invention was made to combine the teachings of Brunn with the teachings of Keagy of hypervisor management module interacting with and issuing control message to the hypervisors to save image/take snapshot, provisioning message, storage information, saving image/take snapshot, deleting virtual machine configuration, data and file system; virtual machine controller connecting to the hypervisor; provisioning message including various parameters to improve efficiency and allow issuing a request to a central orchestrator to save the virtual machine / restore snapshot by retrieving snapshot; with the central orchestrator, connecting to a hypervisor manager located on the hypervisor; passes a set of information comprising a VM storage image location, and a VM memory image location; with the hypervisor manager, uploading ; hypervisor manager, removing an entry of the virtual machine from the hypervisor ; connecting the central orchestrator to the hypervisor manager and passing the information containing the virtual machine's storage image location, the memory image location, and the virtual machine metadata information; with the hypervisor manager: downloading the virtual machine's disk; connecting to the hypervisor; placing the virtual machine’s memory image and the virtual machine’s storage image in a specified location to the method of Brunn as in the instant invention. The combination of cited analogous prior art would have been obvious because applying the known method of managing virtual machine image management as taught by Keagy to the known method of virtual network function management taught by Brunn to yield predictable results with improved efficiency.
Brunn and Keagy in combination do not specifically teach with the hypervisor: determining that the virtual machine’s disk image and the virtual machine’s memory image are present.
Uriel, however, teaches with the hypervisor: determining that the virtual machine’s disk image and the virtual machine’s memory image are present ([0123] hypervisor determine whether the alternate path location has been created and/or exists, may not have been provisioned, hypervisor provisions a VHD corresponding to location [0140] determine that the VHD does not exist, facilitate provisioning of new VHD [0033] VHD, stores set of folders and /or files [0037] VHD, VMDK, VMware virtualization [0048] VHDs, operating system, images, all parts of one logical entity).
It would have been obvious to one of ordinary skills in the art before the effective filing date if the invention was made to combine the teachings of Brunn and Keagy with the teachings of Uriel of hypervisor determining if the VHD corresponding to the VM exist to improve efficiency and allow hypervisor determining that the virtual machine’s disk image and the virtual machine’s memory image are present to the method and Keagy as in the instant invention. The combination of cited analogous prior arts would have been obvious because supplementing the known method of virtual disk management taught by Uriel with the teachings of virtual machine management taught by the combination of Brunn and Keagy to yield predictable results and efficiency.
As per claim 2, Keagy teaches wherein the virtual machine has information associated in the virtual machine's hard disk (col 16 lines 57-67 disk storage of nide allocated to the virtual machine, col 22 lines 15-20 memory, disk space, logically split) and also a running configuration of the VM in the RAM (col 49 lines 62-67 system memory, RAM, store operating system files that are required at runtime ).
As per claim 3, Brunn teaches wherein the central orchestrator is implemented in a SAAS (Software as a Service)_based Platform that provides a DevOPS enabled framework to implement an end to end orchestration of a complex multi-vendor network solution on cloud-computing infrastructure ([0012] VNF, IT cloud computing infrastructure [0013] VNF, avoid complexities, NFV, enables network adapt, frequently changing requirements, vendors, installations [0019] provide new services ).
As per claim 4, Brunn teaches wherein a resume option comprises loading the virtual machine's memory image into the RAM and then launching the virtual machine ([0016] hypervisor, perform, state, VM, use an image file, operating system, application software, started, creates a VM from image file [0026] clean boot).
Keagy teaches remaining claim elements of load the image into the RAM (col 49 lines 62-67 system memory, RAM, store operating system files that are required at runtime ).
As per claim 5, Brunn teaches starting the virtual machine from a same time that the virtual machine had been suspended with all the services in a running state such that a user does not need to do any configuration on the virtual machine and resume his work ([0026] hibernating VM, full time memory image is saved, files, when restarting the hibernated VM, run-time image is restored such that the VM continues from the same running state as prior to being hibernated without having to go through the boot sequence ).
Examiners Note
Applicant is further reminded of that the cited paragraphs and in the references as applied to the claims above for the convenience of the applicant(s) and although the specified citations are representative of the teachings of the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider all of the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Conclusion
Authorization for Internet Communication
Applicant is encouraged to submit an authorization to communicate with the Examiner via the internet by making the following statement (MPEP 502.03)
“Recognizing that internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only by submitted via Central Fax (not Examiner’s Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU ZAR GHAFFARI whose telephone number is (571)270-3799. The examiner can normally be reached on Monday-Thursday 9:00 - 17:00 Hrs.
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, Aimee Lee can be reached on 571-272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABU ZAR GHAFFARI/Primary Examiner, Art Unit 2195