DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
1. Claims 1, 4-7, 9, and 17-19 are currently amended.
2. Claim 11 is cancelled.
3. Claims 1-10 and 12-20 are pending.
4. Claims 1-10 and 12-20 are rejected.
Response to Arguments
5. Regarding 35 U.S.C. 112b Rejections:
Applicant’s amendments and arguments with respect to the objections to the 35 U.S.C. 112b rejections of the invention have been fully considered and are persuasive. The 35 U.S.C. 112b rejections have been withdrawn.
6. Regarding Prior Art Rejections:
Applicant’s amendments and arguments to claims 1, 9, and 17 have been considered and are not persuasive. The rejections under 35 U.S.C. 103 are maintained. Additionally, applicant’s arguments are rejected under a new ground of rejection necessitated by the amendment.
7. Applicant argues in remarks:
While Applicant respectfully disagrees with the rejection, and solely in order to expedite prosecution, claim 1 has been amended to further differentiate the claim from the cited references.
Support for this amendment is found, inter alia, in paragraph(s) 0030, 0032, 0062 of the present application. In sharp contrast, none of the art of record in any combination teaches or suggests the unique combination of features claimed. Accordingly, the rejection must be withdrawn. Applicant respectfully requests reconsideration and allowance of claim 1.
Claims depending from claim 1 are also believed to be allowable based on their dependence. If an independent claim is nonobvious under 35 U.S.C. section 103, then any claim depending therefrom is nonobvious. In re Fine, 837 F.2d 1071, (Fed. Cir. 1988). Moreover, Applicant does not concede or assent to the Examiner's arguments as applied to claim 1 and any claim depending from claim 1 in the previous communication(s). Rather, the rejection of claim 1 and any claim depending from claim 1 is deemed improper at least by virtue of the reasons set forth herein and/or claim dependency, and Applicant reserves the right to further address the grounds of rejection in this or future actions and/or applications.
Applicant does not concede that the subject matter encompassed by claim 1 and its dependents as originally presented is unpatentable over the art cited in the rejection. Rather, claim 1 was amended solely to facilitate expeditious prosecution thereof, and the right to pursue additional claims, including the subject matter originally encompassed by claim 1 and its dependents, in this or future applications, is reserved.
8. Regarding Claim 1, Examiner respectfully disagrees with applicant. Jain et al. US 11483205 B1 teaches of migrating dedicated hosts and their associated virtual machines from one physical server to another. Additionally, new art was added to better cover the scope of the amended claims. Pershin et al. US 20150378759 A1 also teaches of migrating hosts and their associated VMs and using a migration object to keep track of migration status in order to facilitate this process. Lastly, Brouwer teaches of provisioning a new VM during migration when requested by a user and provisioning the new VM on a destination host computing system, or clone dedicated host. Therefore, Jain, Pershin, and Brouwer teach the newly added limitations of the amended claims. The full rejection can be found in the 35 U.S.C. 103 rejection below.
9. Additionally, the same argument was established for claims 9 and 17 and their respective dependent claims. Applicant argues in remarks:
Applicant does not concede that the subject matter encompassed by claims 9 and 17 and their dependents as originally presented is unpatentable over the art cited in the rejection. Rather, claims 9 and 17 were amended solely to facilitate expeditious prosecution thereof, and the right to pursue additional claims, including the subject matter originally encompassed by claims 9 and 17 and its dependents, in this or future applications, is reserved.
Examiner respectfully disagrees and asserts that claims 9 and 17, are rejected under the same reasoning as claims 1, 2, 3, and 4. Their respective rejections can be found below.
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.
10. Claims 1, 3-5, 9, 12-13, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jain et al. US 11483205 B1, in view of Pershin et al. US 20150378759 A1, and in further view of Brouwer et al. US 20160378546 A1.
Jain et al. US 11483205 B1 was cited in IDS filed on June 9, 2023.
11. With regard to claim 1, Jain teaches:
A computer-implemented method, comprising:
receiving a request to migrate a logical dedicated host from a first physical server (Col. 2, lines 36-42, Many servers (“hosts”) in a cloud computing environment are virtualized, such that their compute capacity can be shared among different customers who each have access to a portion of the capacity. In contrast, a dedicated host refers to a physical server (in the cloud computing environment) that has its entire capacity dedicated to a single customer; Col. 14, lines 59-67, The described movement of the resource instances within hosts or between hosts in may take one of several forms of migration, where one or multiple of these forms may be available for use in a deployment. Generally, “migration” refers to moving virtual machine instances (and/or other associated resources) between hosts in a cloud computing network, to different locations within hosts in the cloud network, or even between hosts outside of the cloud computing network and hosts within the cloud network; Col. 15, lines 12-28, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host with the inactive domain; Col. 16, lines 16-24, The user may also use one or more UI elements 310 to provide settings used by the LMS 105 to automatically manage dedicated hosts of a host resource group according to the user's preferences. For example, the user may use a UI element (e.g., a checkbox) to indicate whether the LMS 105 should allocate hosts automatically—e.g., whether LMS 105 can allocate a new host on the user's behalf when there is not enough capacity available on an existing host (of the group) to launch a requested instance; Col. 16, lines 45-52, For example, when the user selects the UI input element (e.g., checkbox) to defragment hosts automatically, the LMS 105 may perform techniques disclosed herein for determining that defragmentation is to be performed, selecting destination locations (e.g., hosts, and/or specific slots) for instances to be moved, and causing these instances to be moved to new locations without significant service disruption; Examiner’s Note: A dedicated host begins migration, and an inactive domain associated with the instance is created. The inactive domain is a copy, since memory, storage, and network connectivity of the VM is transferred from the original host with the active domain to the destination host with the inactive domain. The migration can be done based on a user request, which is indicated by the checkbox that a user clicks to indicate that the LMS should automatically select destinations for instances to be moved (migration).),
identifying a second physical server (Col. 2, lines 36-42, Many servers (“hosts”) in a cloud computing environment are virtualized, such that their compute capacity can be shared among different customers who each have access to a portion of the capacity. In contrast, a dedicated host refers to a physical server (in the cloud computing environment) that has its entire capacity dedicated to a single customer; Col. 15, lines 24-28, Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain; Col. 15, lines 32-36, The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Col. 18, lines 27-29, In this example, the dedicated hosts 406 include physical servers 430A-430N, where each server is shown as executing one or more instances 402; Examiner’s Note: The inactive domain becomes the new active domain on the destination host. The destination host has a second physical server since dedicated hosts include physical servers.);
acting on the migration object to create a clone dedicated host on the second physical server (Col. 15, lines 20-24, When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain; Col. 16, lines 16-24, The user may also use one or more UI elements 310 to provide settings used by the LMS 105 to automatically manage dedicated hosts of a host resource group according to the user's preferences. For example, the user may use a UI element (e.g., a checkbox) to indicate whether the LMS 105 should allocate hosts automatically—e.g., whether LMS 105 can allocate a new host on the user's behalf when there is not enough capacity available on an existing host (of the group) to launch a requested instance; Examiner’s Note: The new inactive domain is the clone dedicated host on the second physical server. The migration object, UI element, helps determine whether the LMS should allocate a new host on the user’s behalf.);
migrating virtual machines from the logical dedicated host to the clone dedicated host, wherein user operations being performed on the virtual machines continue uninterrupted during the migration of the virtual machines (Col. 15, lines 12-36, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain. The virtual machine may be briefly paused to prevent state changes while transferring memory contents (e.g., a delta set of changes to memory made between a full memory copy and the pausing of the virtual machine) to the destination host location. The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: Using live migration, the process of migrating VMs from a dedicated host to another minimizes disrupting the availability of the VM so that the down time of the VM is not noticed by the user.);
in response to completion of the migrating of the virtual machines, causing the logical dedicated host to be de-provisioned (Col. 15, lines 32-36, The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: The original active domain becomes the inactive domain and is discarded, which is de-provisioning it.).
Jain teaches migrating dedicated hosts and their associated VMs from one dedicated host to another, but fails to explicitly teach in response to receiving the request, creating a migration object that is used to track the migration of the logical dedicated host; acting on the migration object to create a clone dedicated host on the second physical server; and receiving a request to provision a new virtual machine from a user during the migrating of the virtual machines, and in response to the request to provision the new virtual machine, provisioning the new virtual machine on the clone dedicated host during the migrating.
However, in analogous art, Pershin teaches:
in response to receiving the request, creating a migration object that is used to track the migration of the logical dedicated host ([0009] This document generally describes techniques for determining the status of virtual machines (VMs) that are being migrated from a source host to a destination host. The status for a VM can indicate, for example, that the VM has been migrated successfully, that the VM is in the process of being migrated, or that migration of the VM has not started; [0020] For example, the source VM manager 116 may receive a request from the source SRM 112 to migrate VMs executing at the source site 110 to the destination site 130; [0022] The destination site 130 also includes an SRM migration data storage system 142 and a host migration data storage system 144 that each stores data regarding the status of VMs being migrated to, or that are planned to be migrated to, the destination site 130; [0054] If the migration of the VM is not successful (324), the destination host adjusts data stored at the destination site to reflect that the VM has not been successfully migrated (326); [0055] If the migration of the VM is successful, the destination host adjusts data stored at the destination site to reflect that the VM has been successfully migrated (328); Examiner’s Note: The status of the VMs that are being migrated is analogous with the migration object.);
acting on the migration object to create a clone dedicated host on the second physical server ([0024] Similarly, the depiction of the destination SRM 132, the destination host 134, and the destination VM manager 136 as separate physical machines, e.g., separate servers, is merely for illustrative purposes; [0043] The destination SRM sends a request to a source site server to migrate the VM (306). For example, the destination SRM may send the request to a source SRM located at the source site. The request may specify the VM to be transferred, e.g., using a unique identifier for the VM, and the destination host to which the VM is to be migrated; [0045] The source VM manager instructs the source host to migrate the VM from the source host to the destination host (310). In response, the source host interacts with the destination host to initiate the migration of the VM (312). For example, a migration engine executing on the source host may establish communication with the destination host and provide data to the destination host that identifies the VM that is to be migrated; [0046] The destination host stores a migration in progress record (314). For example, the destination host may store the migration in progress record in a host migration data storage system prior to the VM being migrated from the source host to the destination host. The migration in progress record is a record that indicates that the hosts are in the process of migrating the VM; [0047] The destination host creates a placeholder VM for the VM that is to be migrated (316). The placeholder VM may have the same unique identifier as the VM that is to be migrated. In some implementations, the destination host may store data identifying the placeholder VM, e.g., the unique identifier of the placeholder VM, in the VM inventory of the destination VM manager. In this way, the destination VM manager has a record of the VMs that are executing or being migrated to the destination site; Examiner’s Note: When the VM status is marked as in progress, migration is occurring and a placeholder VM (copy) is created by the destination host (second physical server).);
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 teachings of Jain with the teachings of Pershin where in response to receiving the request, creating a migration object that is used to track the migration of the logical dedicated host, and acting on the migration object to create a clone dedicated host on the second physical server. Jain teaches of migrating dedicated hosts and their associated virtual machines from a first physical server to a second physical server. Similarly, Pershin teaches of migrating virtual machines from a source host to a destination host. The status of the migrating virtual machines is documented in order to keep track of whether the virtual machine has been fully migrated from the source host to the destination host (Abstract). By keeping track of the status of the VMs, it can help determine whether a fault has occurred during the migration of one or more virtual machines. The stored data to determine the status of the migration of the VMs, for example, in response to a fault or disaster occurring at the source site or to the source host during the migration. For example, if the destination VM has a migration started record but no migration completed record for a particular VM, the SRM may determine that the VM is in the process of being migrated, as discussed in Pershin ([0013]).
Both Jain and Pershin fail to teach receiving a request to provision a new virtual machine from a user during the migrating of the virtual machines, and in response to the request to provision the new virtual machine, provisioning the new virtual machine on the clone dedicated host during the migrating.
However, in analogous art, Brouwer teaches:
receiving a request to provision a new virtual machine from a user during the migrating of the virtual machines, and in response to the request to provision the new virtual machine, provisioning the new virtual machine on the clone dedicated host during the migrating ([0018] A virtual machine migration typically may proceed in phases. As a result of determining that a running virtual machine instance is a candidate for migration from a source host computer system to a suitable target host computer system, the target host computer system may first be prepared for the migration. The target location may be selected from a set of possible candidate locations based at least in part on the configuration of the running virtual machine instance. A new instance of the virtual machine may then be created on the target with the same configuration as the original virtual machine instance and memory and state information from the original virtual machine instance may be copied to the new virtual machine instance while the original virtual machine instance continues to run; [0025] When migrating the original VM instance 114 from the source location 110 to the target location, a number of systems, services, processes, and resources may be communicating with the original VM instance 114. These systems, services, processes, and resources cannot generally be guaranteed to change their behavior simultaneously so that their communications switch from the original VM instance 114 at the source location 110 to a new VM instance 116 at the target location 112. The migration manager 104 may be configured to communicate with each of the plurality of systems, services, processes, and resources in order to manage the migration. The migration manager 104 may be configured to manage (or orchestrate) the migration by performing actions including, but not limited to, determining the proper order for migration, managing a workflow for migration, issue commands to the systems, services, processes, and resources associated with the migration, determining whether the migration is successful, starting and stopping virtual machine instances, determining whether the migration has failed, determining whether the migration should be cancelled, and managing rollback if errors occur; [0029] The one or more commands 106 that may be sent from the migration manager 104 to the system manager 108 in response to the request to migrate may include commands to configure the target location to instantiate a new virtual machine instance, commands to instantiate a new virtual machine instance at the target location 112, commands to copy the memory and/or state from the original VM instance 114 to a new VM instance 116 [...]);
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 teachings of Jain and Pershin with the teachings of Brouwer where receiving a request to provision a new virtual machine from a user during the migrating of the virtual machines, and in response to the request to provision the new virtual machine, provisioning the new virtual machine on the clone dedicated host during the migrating. Together Jain and Pershin teach of migrating dedicated hosts and their associated virtual machines from a first physical server to a second physical server and using a migrating object to help facilitate this process. Similarly, Brouwer teaches of migrating VMs to a different host computer system. Moreover, Brouwer teaches of instantiating a new VM on a target location. This helps mitigate the process of migrating a VM to a new host. The new VM that is created on the target has the same configuration as the original VM. As discussed in Brouwer, this allows the memory and state information from the original VM to be copied to the new VM instance while the original VM is still running, which reduces both the length and impact of a critical migration phase (e.g., a phase in the migration where changes to the virtual machine instance can adversely affect the migration). In the examples described herein, access to block storage devices provided by a block-level storage service is managed during migration of the virtual machine instance so that the state of the virtual machine instance and the state of the block storage devices is not impacted by the migration ([0017]; [0018]).
12. With regard to claim 3, Jain further teaches:
wherein the virtual machines running on the clone dedicated host are presented to a user as running on the logical dedicated host during and after the migrating of the virtual machines, wherein the clone dedicated host is presented to the user as the logical dedicated host after completion of the migration of the logical dedicated host (Col. 2, lines 39-50, In contrast, a dedicated host refers to a physical server (in the cloud computing environment) that has its entire capacity dedicated to a single customer. Other customer's compute resources cannot be placed on a dedicated host, regardless of whether the customer to which it is dedicated fully utilizes its capacity. One example use case for such dedicated hosts is for hosting instances that run software which requires a host-bound license (e.g., the customer cannot move the software to a different host under the terms of their software license, and/or the customer licenses the entire host and can run as many copies of the software on that host as they are able); Col. 14, lines 59-67, The described movement of the resource instances within hosts or between hosts in may take one of several forms of migration, where one or multiple of these forms may be available for use in a deployment. Generally, “migration” refers to moving virtual machine instances (and/or other associated resources) between hosts in a cloud computing network, to different locations within hosts in the cloud network, or even between hosts outside of the cloud computing network and hosts within the cloud network; Col. 15, lines 12-36, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain. The virtual machine may be briefly paused to prevent state changes while transferring memory contents (e.g., a delta set of changes to memory made between a full memory copy and the pausing of the virtual machine) to the destination host location. The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: Following the migration, the inactive (clone) domain has become the active new active domain. The user is now running the VMs on the new destination host. Additionally, during migration, VMs are being copied over from the active domain to the inactive domain without disrupting user activity. The user is still seeing the VMs running as usual.).
13. With regard to claim 4, Jain further teaches:
wherein the same type of resources allocated to the logical dedicated host on the first physical server are allocated to the clone dedicated host on the second physical server, the resources including data storage capacity and memory allocation (Col. 21, lines 10-14, Memory (including in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host with the inactive domain.).
14. With regard to claim 5, Jain further teaches:
wherein causing the logical dedicated host to be de-provisioned includes deleting a logical dedicated host object, thereby prompting a scheduler microservice to de-provision the logical dedicated host (Col. 15, lines 20-26, When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain. The virtual machine may be briefly paused to prevent state changes while transferring memory contents (e.g., a delta set of changes to memory made between a full memory copy and the pausing of the virtual machine) to the destination host location. The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: After migration, the original active domain that is associated with the initial host is demoted to the inactive domain and discarded.); and
Although Jain teaches of deleting a logical dedicated host object and de-provisioning the logical dedicated host, Jain fails to explicitly teach comprising updating the migration object to a completed state.
However, in analogous art, Pershin further teaches:
comprising updating the migration object to a completed state ([0022] The destination site 130 also includes an SRM migration data storage system 142 and a host migration data storage system 144 that each stores data regarding the status of VMs being migrated to, or that are planned to be migrated to, the destination site 130; [0055] If the migration of the VM is successful, the destination host adjusts data stored at the destination site to reflect that the VM has been successfully migrated (328).).
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 teachings of Jain with the teachings of Pershin where in response to receiving the request, creating a migration object that is used to track the migration of the logical dedicated host, and acting on the migration object to create a clone dedicated host on the second physical server. Jain teaches of migrating dedicated hosts and their associated virtual machines from a first physical server to a second physical server. Similarly, Pershin teaches of migrating virtual machines from a source host to a destination host. The status of the migrating virtual machines is documented in order to keep track of whether the virtual machine has been fully migrated from the source host to the destination host (Abstract). By keeping track of the status of the VMs, it can help determine whether a fault has occurred during the migration of one or more virtual machines. The stored data to determine the status of the migration of the VMs, for example, in response to a fault or disaster occurring at the source site or to the source host during the migration. For example, if the destination VM has a migration started record but no migration completed record for a particular VM, the SRM may determine that the VM is in the process of being migrated, as discussed in Pershin ([0013]). If the migration status is updated to completed, it lets the system know that the migration of VMs was successful.
15. With regard to claim 9, Jain further teaches:
A computer program product for live migration of a logical dedicated host and virtual machines running thereon from a first physical server to a second physical server, the computer program product comprising:
one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media (Col. 25, lines 22-36, Some or all of the operations 700 (or other processes described herein, or variations, and/or combinations thereof) are performed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware or combinations thereof. The code is stored on a computer-readable storage medium, for example, in the form of a computer program comprising instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of the operations 700 are performed by LMS 105 (e.g., the defragmentation service 140 component thereof) shown in the other figures.), the program instructions comprising:
program instructions to, in response to receiving a request to migrate a logical dedicated host from a first physical server, create a clone of the logical dedicated host as a clone dedicated host on a second physical server (Col. 14, lines 59-67, The described movement of the resource instances within hosts or between hosts in may take one of several forms of migration, where one or multiple of these forms may be available for use in a deployment. Generally, “migration” refers to moving virtual machine instances (and/or other associated resources) between hosts in a cloud computing network, to different locations within hosts in the cloud network, or even between hosts outside of the cloud computing network and hosts within the cloud network; Col. 15, lines 12-28, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host with the inactive domain; Col. 2, lines 36-42, Many servers (“hosts”) in a cloud computing environment are virtualized, such that their compute capacity can be shared among different customers who each have access to a portion of the capacity. In contrast, a dedicated host refers to a physical server (in the cloud computing environment) that has its entire capacity dedicated to a single customer; Col. 15, lines 24-28, Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain; Col. 15, lines 32-36, The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Col. 18, lines 27-29, In this example, the dedicated hosts 406 include physical servers 430A-430N, where each server is shown as executing one or more instances 402; Examiner’s Note: A dedicated host begins migration, and an inactive domain associated with the instance is created. The inactive domain is a copy, since memory, storage, and network connectivity of the VM is transferred from the original host with the active domain to the destination host with the inactive domain. The inactive domain becomes the new active domain on the destination host. The destination host has a second physical server since dedicated hosts include physical servers.);
program instructions to migrate virtual machines from the logical dedicated host to the clone dedicated host, wherein user operations being performed on the virtual machines continue uninterrupted during the migration of the virtual machines (Col. 15, lines 12-36, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain. The virtual machine may be briefly paused to prevent state changes while transferring memory contents (e.g., a delta set of changes to memory made between a full memory copy and the pausing of the virtual machine) to the destination host location. The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: Using live migration, the process of migrating VMs from a dedicated host to another minimizes disrupting the availability of the VM so that the down time of the VM is not noticed by the user.); and
program instructions to, in response to completion of the migrating of the virtual machines, cause the logical dedicated host to be de-provisioned (Col. 15, lines 32-36, The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: The original active domain becomes the inactive domain and is discarded, which is de-provisioning it.),
program instructions to present the virtual machines running on the clone dedicated host to a user as running on the logical dedicated host during and after the migrating of the virtual machines, wherein the clone dedicated host is presented to the user as the logical dedicated host after completion of the migration of the logical dedicated host and de- provisioning of the logical dedicated host (Col. 2, lines 39-50, In contrast, a dedicated host refers to a physical server (in the cloud computing environment) that has its entire capacity dedicated to a single customer. Other customer's compute resources cannot be placed on a dedicated host, regardless of whether the customer to which it is dedicated fully utilizes its capacity. One example use case for such dedicated hosts is for hosting instances that run software which requires a host-bound license (e.g., the customer cannot move the software to a different host under the terms of their software license, and/or the customer licenses the entire host and can run as many copies of the software on that host as they are able); Col. 14, lines 59-67, The described movement of the resource instances within hosts or between hosts in may take one of several forms of migration, where one or multiple of these forms may be available for use in a deployment. Generally, “migration” refers to moving virtual machine instances (and/or other associated resources) between hosts in a cloud computing network, to different locations within hosts in the cloud network, or even between hosts outside of the cloud computing network and hosts within the cloud network; Col. 15, lines 12-36, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain. The virtual machine may be briefly paused to prevent state changes while transferring memory contents (e.g., a delta set of changes to memory made between a full memory copy and the pausing of the virtual machine) to the destination host location. The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: Following the migration, the inactive (clone) domain has become the active new active domain. The user is now running the VMs on the new destination host. Additionally, during migration, VMs are being copied over from the active domain to the inactive domain without disrupting user activity. The user is still seeing the VMs running as usual.).
16. Regarding claim 12, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
17. Regarding claim 13, it is rejected under the same reasoning as claim 5 above. Therefore, it is rejected under the same rationale.
18. Regarding claim 19, it is rejected under the same reasoning as claim 3 above. Therefore, it is rejected under the same rationale.
19. Regarding claim 20, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
20. Claims 2, 10, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Jain et al. US 11483205 B1; Pershin et al. US 20150378759 A1; and Brouwer et al. US 20160378546 A1, as applied in claim 1, and in further view of Buli et al. US 20180032362 A1.
21. With regard to claim 2, Jain, Pershin, and Brouwer teach the computer-implemented method of claim 1 but fail to explicitly teach wherein a resource configuration of the second physical server substantially matches the resource configuration of the first physical server.
However, in analogous art, Buli et al. US 20180032362 A1 teaches:
wherein a resource configuration of the second physical server substantially matches the resource configuration of the first physical server ([0011] When a virtual machine is migrated from one host node to another, existing migration mechanisms assure the compatibility of the destination host node with respect to available network resources or storage resources in use by the virtual machine on the target host. If the virtual machine is running on a computer cluster and the cluster manager service triggers the migration, the CPU and the memory in the new destination host will be verified. If everything is correct, the virtual machine is migrated.).
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 teachings of Jain, Pershin, and Brouwer with the teachings of Buli wherein a resource configuration of the second physical server substantially matches the resource configuration of the first physical server. Buli also teaches of VM migration from one host node to another. Buli emphasizes the important of assuring that the resource configuration of the second server matches the resource configuration of the first server. This ensures that there are available network resources or storage resources in use by the virtual machine on the target host, as discussed in Buli ([0011]).
22. Regarding claim 10, it is rejected under the same reasoning as claim 2 above. Therefore, it is rejected under the same rationale.
23. With regard to claim 17, Jain further teaches:
A system, comprising:
a processor (Col. 19, lines 19-22, In various embodiments, computer system 1000 may be a uniprocessor system including one processor 1010, or a multiprocessor system including several processors 1010 (e.g., two, four, eight, or another suitable number). ); and
logic integrated with the processor, executable by the processor, or integrated with and executable by the processor (Col. 19, lines 19-30, In various embodiments, computer system 1000 may be a uniprocessor system including one processor 1010, or a multiprocessor system including several processors 1010 (e.g., two, four, eight, or another suitable number). Processors 1010 may be any suitable processors capable of executing instructions. For example, in various embodiments, processors 1010 may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, ARM, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of processors 1010 may commonly, but not necessarily, implement the same ISA.), the logic being configured to:
in response to receiving a request to migrate a logical dedicated host from a first physical server, provision a clone of the logical dedicated host thereby creating as a clone dedicated host on a second physical server (Col. 14, lines 59-67, The described movement of the resource instances within hosts or between hosts in may take one of several forms of migration, where one or multiple of these forms may be available for use in a deployment. Generally, “migration” refers to moving virtual machine instances (and/or other associated resources) between hosts in a cloud computing network, to different locations within hosts in the cloud network, or even between hosts outside of the cloud computing network and hosts within the cloud network; Col. 15, lines 12-28, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host with the inactive domain; Col. 2, lines 36-42, Many servers (“hosts”) in a cloud computing environment are virtualized, such that their compute capacity can be shared among different customers who each have access to a portion of the capacity. In contrast, a dedicated host refers to a physical server (in the cloud computing environment) that has its entire capacity dedicated to a single customer; Col. 15, lines 24-28, Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain; Col. 15, lines 32-36, The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Col. 18, lines 27-29, In this example, the dedicated hosts 406 include physical servers 430A-430N, where each server is shown as executing one or more instances 402; Examiner’s Note: A dedicated host begins migration, and an inactive domain associated with the instance is created. The inactive domain is a copy, since memory, storage, and network connectivity of the VM is transferred from the original host with the active domain to the destination host with the inactive domain. The inactive domain becomes the new active domain on the destination host. The destination host has a second physical server since dedicated hosts include physical servers.);
migrate virtual machines from the logical dedicated host to the clone dedicated host, wherein user operations being performed on the virtual machines continue uninterrupted during the migration of the virtual machines (Col. 15, lines 12-36, In some embodiments, the LMS 105 may utilize live migration to move resource instances, which refers to the process of moving a running virtual machine or application between different physical machines (or different slots/locations within a same physical computing device) without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user, or only noticeable as an extremely brief disruption of service). When the control plane executes a live migration workflow it can create a new “inactive” domain associated with the instance, while the original domain for the instance continues to run as the “active” domain. Memory (including any in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host (or location) with the inactive domain. The virtual machine may be briefly paused to prevent state changes while transferring memory contents (e.g., a delta set of changes to memory made between a full memory copy and the pausing of the virtual machine) to the destination host location. The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: Using live migration, the process of migrating VMs from a dedicated host to another minimizes disrupting the availability of the VM so that the down time of the VM is not noticed by the user.); and
in response to completion of the migrating of the virtual machines, cause the logical dedicated host to be de-provisioned (Col. 15, lines 32-36, The control plane can transition the inactive domain to become the active domain and demote the original active domain to become the inactive domain (sometimes referred to as a “flip”), after which the inactive domain can be discarded; Examiner’s Note: The original active domain becomes the inactive domain and is discarded, which is de-provisioning it.),
wherein the same type of resources allocated to the logical dedicated host on the first physical server are allocated to the clone dedicated host on the second physical server, the resources including data storage capacity and memory allocation (Col. 21, lines 10-14, Memory (including in-memory state of running applications), storage, and network connectivity of the virtual machine are transferred from the original host with the active domain to the destination host with the inactive domain.).
Jain teaches migrating VMs from one dedicated host to another, but fails to explicitly teach wherein a resource configuration of the second physical server substantially matches the resource configuration of the first physical server.
However, in analogous art, Buli teaches:
wherein a resource configuration of the second physical server substantially matches the resource configuration of the first physical server ([0011] When a virtual machine is migrated from one host node to another, existing migration mechanisms assure the compatibility of the destination host node with respect to available network resources or storage resources in use by the virtual machine on the target host. If the virtual machine is running on a computer cluster and the cluster manager service triggers the migration, the CPU and the memory in the new destination host will be verified. If everything is correct, the virtual machine is migrated.),
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 teachings of Jain with the teachings of Buli wherein a resource configuration of the second physical server substantially matches the resource configuration of the first physical server. Buli also teaches of VM migration from one host node to another. Buli emphasizes the important of assuring that the resource configuration of the second server matches the resource configuration of the first server. This ensures that there are available network resources or storage resources in use by the virtual machine on the target host, as discussed in Buli ([0011]).
24. Regarding claim 18, it is rejected under the same reasoning as claim 2 above. Therefore, it is rejected under the same rationale.
25. Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable Jain et al. US 11483205 B1; Pershin et al. US 20150378759 A1; Brouwer et al. US 20160378546 A1; and Dippenaar et al. US 9870268 B2, as applied in claim 7, in further view of Takahashi US 20100023939 A1.
26. With regard to claim 6, Jain, Pershin, and Brouwer teach the computer-implemented method of claim 7 but fail to explicitly teach comprising: adding the new virtual machine to a list of the virtual machines running on the clone dedicated host; updating an amount of available resources of the clone dedicated host.
However, in analogous art, Takahashi teaches:
comprising:
adding the new virtual machine to a list of the virtual machines running on the clone dedicated host ([0064] For example, the virtual-machine generating apparatus 10 stores in the virtual-machine identifier storage unit 21 a UUID and a MAC address that uniquely identify a virtual machine in association with each other. Also, in association with "machine name", which is unique information of a virtual machine, the virtual-machine generating apparatus 10 stores in the configuration-information storage unit 22 resources indicative of resource information of the virtual machine including "the number of CPUs", "memory amount", and "disk capacity", "install flag" indicative of whether introduction is performed through duplication of a virtual machine corresponding to "machine name", "copy-source virtual-machine name" indicative of unique information of a copy-source virtual machine from which unique information, hardware resources, and configuration information are copied, and configuration information containing various information for operating the OS of the virtual machine. Then, when a new virtual machine is generated, the virtual-machine generating apparatus 10 accepts inputs of unique information of the virtual machine to be generated, "VM3", the number of CPUs of "2", a memory amount of "1024", and a disk capacity of "20480".); and
updating an amount of available resources of the clone dedicated host ([0064] For example, the virtual-machine generating apparatus 10 stores in the virtual-machine identifier storage unit 21 a UUID and a MAC address that uniquely identify a virtual machine in association with each other. Also, in association with "machine name", which is unique information of a virtual machine, the virtual-machine generating apparatus 10 stores in the configuration-information storage unit 22 resources indicative of resource information of the virtual machine including "the number of CPUs", "memory amount", and "disk capacity", "install flag" indicative of whether introduction is performed through duplication of a virtual machine corresponding to "machine name", "copy-source virtual-machine name" indicative of unique information of a copy-source virtual machine from which unique information, hardware resources, and configuration information are copied, and configuration information containing various information for operating the OS of the virtual machine. Then, when a new virtual machine is generated, the virtual-machine generating apparatus 10 accepts inputs of unique information of the virtual machine to be generated, "VM3", the number of CPUs of "2", a memory amount of "1024", and a disk capacity of "20480".).
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 teachings of Jain, Pershin, and Brouwer with the teachings of Takahashi comprising: adding the new virtual machine to a list of the virtual machines running on the clone dedicated host; updating an amount of available resources of the clone dedicated host. Jain, Pershin, and Brouwer teach of migrating a dedicated host and its associated VMs from one server to another, using a migration object to track VM status, and provisioning a new VM instance if requested during the migration process. Similarly, Takahashi teaches of a virtual machine generating apparatus. Additionally a virtual-machine generating apparatus includes a configuration-information storage unit that stores resources indicative of hardware resource information of a virtual machine and hardware configuration information indicative of information configuring the virtual machine in association with unique information of the virtual machine; a configuration-information checking unit that, when a new virtual machine is introduced, accepts unique information and hardware resources of the new virtual machine and determines whether the hardware resources identical to the accepted resources are stored in the configuration-information storage unit; and a basic-software introducing unit that, when it is determined by the configuration-information checking unit that the hardware resources identical to the accepted resources are stored in the configuration-information storage unit, duplicates basic software of the virtual machine having the identical hardware resources and introduces the basic software of the new virtual machine. This remedies the problem where the same operation is manually performed as many times as the number of machines to be introduced, and a setting file required at the time of installing a guest OS is manually changed and copied, and a determination as to whether the machines have different specifications is manually made. As such, in any of the technologies of installing an OS of virtual machines, it takes time to generate virtual machines, and the reliability of the generated virtual machines is low, as discussed in Takahashi ([0009]; [0010]).
27. Regarding claim 14, it is rejected under the same reasoning as claim 6 above. Therefore, it is rejected under the same rationale.
28. Claims 7-8 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable Jain et al. US 11483205 B1; Pershin et al. US 20150378759 A1; and Brouwer et al. US 20160378546 A1, as applied in claim 1, and in further view of Dippenaar et al. US 9870268 B2.
Dippenaar et al. US 9870268 B2 was cited in IDS filed on June 9, 2023.
29. With regard to claim 7, Jain, Pershin, and Brouwer teach the computer-implemented method of claim 1 but fail to explicitly teach wherein provisioning the new virtual machine on the clone dedicated host includes: determining an aggregate amount of available resources of the logical dedicated host and the clone dedicated host; determining whether the aggregate amount of available resources is sufficient to fulfill the request to provision the new virtual machine by comparing an amount of resources required by the new virtual machine to the aggregate amount of available resources; and in response to determining that the aggregate amount of available resources is sufficient to fulfill the request for provisioning the new virtual machine, scheduling provisioning of the new virtual machine on the clone dedicated host.
However, in analogous art, Dippenaar teaches:
wherein provisioning the new virtual machine on the clone dedicated host includes:
determining an aggregate amount of available resources of the logical dedicated host and the clone dedicated host (Abstract, The virtual computer system service may be configured to evaluate the specifications of the available physical host computer systems to determine whether any of the available physical host computer systems conform to the set of preferences.);
determining whether the aggregate amount of available resources is sufficient to fulfill the request to provision the new virtual machine by comparing an amount of resources required by the new virtual machine to the aggregate amount of available resources (Col. 2, lines 62 – Col. 3, lines 17, Accordingly, the virtual computer system service may determine whether a physical host with the requested hardware specifications is available for allocation. If a physical host with the requested hardware specifications is available, the virtual computer system service may allocate the virtual machine instance to the available physical host. If the requested hardware is not available, the virtual computer system service may determine whether the request for specific hardware is a preference or a requirement set forth by the customer. The virtual computer system service may allocate the instance to a non-conforming physical host if a physical host with the requested hardware specifications is not available and the customer request is a preference for certain hardware specifications to support and instantiate the virtual machine instance. However, if a physical host with the requested hardware specifications is not available and the request is a firm requirement set forth by the customer, the virtual computer system service may refrain from allocating the instance to a non-conforming physical host and instead display an error message that may include, for example, an estimated time until an appropriate physical host is available and other available options available to the customer for the requested virtual machine instance; Examiner’s Note: The computer system checks to see if there are any physical hosts that have the request hardware specifications available.); and
in response to determining that the aggregate amount of available resources is sufficient to fulfill the request for provisioning the new virtual machine, scheduling provisioning of the new virtual machine on the clone dedicated host (Col. 3, lines 21-35, When the virtual computer system service detects that one or more slots within a physical host have become available, the virtual computer system service may query the metadata of any existing virtual machine instances to determine whether a customer has requested that the instance be migrated to a physical host with hardware specifications matching the specifications included in the customer request. If the metadata associated with multiple virtual machine instances indicates a request for migration to a physical host with particular hardware specifications, and the now available physical host includes matching hardware specifications for these virtual machine instances, the virtual computer system service may apply one or more criteria to determine which virtual machine instance may be migrated to the physical host; Examiner’s Note: When a host that has sufficient resources is detected, the VM is migrated to it.).
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 teachings of Jain, Pershin, and Brouwer with the teachings of Dippenaar wherein provisioning the new virtual machine on the clone dedicated host includes: determining an aggregate amount of available resources of the logical dedicated host and the clone dedicated host; determining whether the aggregate amount of available resources is sufficient to fulfill the request to provision the new virtual machine by comparing an amount of resources required by the new virtual machine to the aggregate amount of available resources; and in response to determining that the aggregate amount of available resources is sufficient to fulfill the request for provisioning the new virtual machine, scheduling provisioning of the new virtual machine on the clone dedicated host. By determining resource availability of a host and migrating a newly created VM when a compatible host becomes available, this prevents a customer from provisioning a virtual machine instance and immediately terminate the instance if the allocated physical host does not meet desired hardware requirements. A customer may repeat this process until an instance is created that is implemented on a physical host that includes the desired hardware configuration. This may result in a less than ideal customer experience and other adverse consequences. Some manners of addressing these issues, such as through the purchasing and provisioning of additional server systems with varying configurations to satisfy customer needs, may present significant additional costs and administrative burden, as discussed in Dippenaar (Col. 1, lines 34-44).
30. With regard to claim 8, Dippenaar further teaches:
comprising receiving a request to delete one of the virtual machines from a user during the migrating of the virtual machines (Col. 56-60, Additionally, the management sub-system may routinely inspect the physical host computer systems to detect 802 slot availability, such as described above or in an instance where a customer has requested the deletion of a virtual machine instance.); and
deleting the one of the virtual machines during the migrating of the virtual machines in response to the request to delete the one of the virtual machines (Col. 56-60, Additionally, the management sub-system may routinely inspect the physical host computer systems to detect 802 slot availability, such as described above or in an instance where a customer has requested the deletion of a virtual machine instance.).
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 teachings of Jain, Pershin, and Brouwer with the teachings of Dippenaar comprising receiving a request to delete one of the virtual machines from a user during the migrating of the virtual machines; and deleting the one of the virtual machines during the migrating of the virtual machines in response to the request to delete the one of the virtual machines. By allowing the management sub-system to delete VMs per user request, it provides newly opened slots on a physical host computer system. The management sub-system may again detect 802 this availability and query 804 the metadata service to locate any other instances for migration, as discussed in Dippenaar (Col. 15, lines 51-60).
31. Regarding claim 15, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
32. Regarding claim 16, it is rejected under the same reasoning as claim 8 above. Therefore, it is rejected under the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AN-AN N NGUYEN whose telephone number is (571)272-6147. The examiner can normally be reached Monday-Friday 8:00-5:00 ET.
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 LI can be reached at (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 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.
/AN-AN NGOC NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195