DETAILED ACTION
Claims 1-7 and 9-14 are pending.
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 .
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-7 and 9-14 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al. (US 2019/0146827 A1) in view of Zhang et al. (US 2013/0125120 A1), in further view of Wu et al. (US 2018/0131621 A1).
Yu, Zhang, and Wu were cited in the previous Office Action. However, mapping has been updated into new grounds of rejection.
Regarding claim 1, Yu teaches the invention as claimed including a virtualized network function (VNF) lifecycle management method being performed by a virtualized network function manager (VNFM) (Abstract; [0089] A virtualized network function manager (VNFM) is configured to implement life cycle management of the VNF), comprising:
generating a pre-notification indicating that a VNF is to enter a target stage of a lifecycle (Abstract: sending, by a virtual network function manager (VNFM) device, a preprocessing request message to an element manager (EM) device, where the preprocessing request message is used to request the EM device to perform a resource pre-scaling-in on a virtual network function (VNF) instance (i.e., target stage of a lifecycle); [0015]), wherein the generating a pre-notification comprises at least one of the following:
generating a scale-out pre-notification as the pre-notification, the scale-out pre- notification indicating that the VNF is going to enter a scale-out stage (Abstract; [0089] A virtualized network function manager (VNFM) is configured to implement life cycle management of the VNF, including management and processing of the VNFD, initialization of the VNF instance, scaling-out or scaling-in of the VNF, and termination of the VNF instance.); and
generating a scale-in pre-notification as the pre-notification, the scale-in pre- notification indicating that the VNF is going to enter a scale-in stage (Abstract: sending, by a virtual network function manager (VNFM) device, a preprocessing request message to an element manager (EM) device, where the preprocessing request message is used to request the EM device to perform a resource pre-scaling-in on a virtual network function (VNF) instance); and
generating a management instruction for instructing a container-as-a-service (CaaS) manager to manage a container cluster carrying the VNF to control the VNF to enter the target stage of the lifecycle, wherein the management instruction contains an identifier of the container cluster carrying the VNF (Abstract; Fig. 6, S604; [0110] group of containers (i.e., cluster); [0012] In one embodiment, the preprocessing request message includes an identifier list of the virtualization container on which the resource pre-scaling-in needs to be performed, and the identifier list is used to identify the virtualization container on which the resource pre-scaling-in needs to be performed.; [0152] In operation S604, after receiving the granting response message, the VNFM device determines a first virtualization container (that is, one or more virtualization containers on which the resource pre-scaling-in needs to be performed). A method for determining the first virtualization container is the same as a method for determining the first virtualization container by the EM device in the method 200. [0028] the VNFM device requests the EM device to perform the resource pre-scaling-in on the virtualization container in the identifier list; wherein the Element Manager (EM) device corresponds to the CaaS Manager as they both manage containers, Yu reasonably teaches the amended limitation); and
sending the management instruction to the CaaS manager ([0153] In operation S605, the VNFM device sends a resource pre-scaling-in request message (e.g., a VNF pre-scaling-in request) to the EM device (CaaS Manager). The resource pre-scaling-in request message includes an identifier list (IdList) of the first virtualization container.).
While Yu teaches generating a scale-in preprocessing request message that is received by an Element Manager that prepares the VNF instance for pre-scaling-in which reasonably teaches the VNF receiving the preprocessing message but Yu does not explicitly teach sending the pre-notification to the VNF;
receiving, from the VNF, a pre-notification response in response to the pre-notification.
However, Zhang teaches middleboxes for providing network services such as source network address translation (SNAT), Intrusion detection system (IDS) and WAN optimization. See at least [0033-36]. Further, Zhang teaches comprising
sending the pre-notification to the [middlebox] VNF, receiving, from the [middlebox] VNF, a pre-notification response in response to the pre-notification, and controlling the [middlebox] VNF to enter the target stage of the lifecycle ([0047] However, when a VM migrates from a source host to a destination host, the middlebox state related to the VM needs to be brought into the destination host in order for the migrated VM to resume its function at the destination host. [0050] At the first stage 205, the VM migration manager 235 of the host 155 pre-notifies the middlebox element 225 that VM 1 that is currently running in the host 155 is going to be migrated to another host (generating pre-notification and sending pre-notification to middlebox (i.e., VNF)). In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of VM migration. Configuring a middlebox element will be described in detail further below by reference to FIGS. 7 and 8. In this example, the middlebox element 225 is configured to register for a callback from the VM migration manager 235 and thus the VM migration manager 235 sends a pre-notification to the middlebox element 225. [0052] The middlebox element of some embodiments sends the gathered state for the VM and sends the state to the VM migration manager. Also, as the VM continues to function in the source host, the state related to the VM may also change. The middlebox element identifies these changes and sends the changes to the VM migration manager (a pre-notification response in response to the pre-notification) until the VM migration manager stuns the VM to move the VM to the destination host. [0053] The third stage 215 shows that the VM migration manager 235 has stunned the VM 250 and is sending the middlebox state of the VM 250 and the VM 250 (e.g., the VM's state) to the host 165, which is the destination host to which the VM 250 is migrating in this example. In some embodiments, the VM migration manager of the source host sends the middlebox state and the VM state to the VM migration manager of the destination host. The VM migration manager at the destination host provisions the migrating VM in the destination host and provides the middlebox state to the middlebox element running in the destination host.; wherein the middlebox corresponds to a VNF and migration correspond to a lifecycle target state).
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 Zhang with the teachings of Yu to prenotify a middlebox of a change in operation. The modification would have been motivated by the desire of ensuring the state is available to be transferred prior to the migration.
While Zhang defines the middlebox as a service that provides several network functions (e.g., firewalls, load balancers, network address translators, intrusion detection systems (IDS), wide area network (WAN) optimizers, etc.) See at least [0005], Yu and Zhang does not explicitly teach wherein a middlebox is a VNF.
However, Wu teaches a middlebox is a VNF ([0013] Specifically, FIG. 1 includes a middlebox 150 that includes at least a virtualized network function, such as, load balancer 120, and a plurality of hardware networking devices, such as server 1 130 and server 2 140. In this disclosure, middlebox (e.g., middlebox 150 in FIG. 1) is used interchangeably with the term virtualized network function (VNF), which generally refers to a software implementation to handle specific network functions that run in at least one virtual machine on top of the hardware networking infrastructure, which can include routers, switches, servers, cloud computing systems, etc.).
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 Wu with the teachings of Yu and Zhang to define a middlebox as a VNF as it is well known in the art that a software implemented network service is a VNF.
Regarding claim 2, Yu teaches wherein the VNF comprises a first virtualized network function component (VNFC) ([0086] A virtualized network function (VNF) may also be referred to as a virtualized network element, and corresponds to a physical network function in a conventional non-virtualized network. A functional behavior and a status of a network function are unrelated to virtualization of the network function. The VNF may include a plurality of lower-level components. Optionally, one VNF may be deployed on a plurality of VMs, and each VM hosts one VNF component (VNFC).).
In addition, Zhang teaches wherein the step of generating the pre-notification generates the pre-notification based on the first virtualized network function component (VNFC), and the pre-notification indicates that the first VNFC is to enter the target stage of the lifecycle; and
wherein the step of controlling the VNF to enter the target stage of the lifecycle comprises:
controlling, based on the pre-notification response, the first VNFC to enter the target stage of the lifecycle, wherein the pre-notification response indicates that the VNF allows the first VNFC to enter the target stage of the lifecycle;
controlling, based on the pre-notification response, a third VNFC of the VNF to enter the target stage of the lifecycle, wherein the pre-notification response indicates that the third VNFC is to enter the target stage of the lifecycle ([0050] At the first stage 205, the VM migration manager 235 of the host 155 pre-notifies the middlebox element 225 that VM 1 that is currently running in the host 155 is going to be migrated to another host. In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of VM migration. Configuring a middlebox element will be described in detail further below by reference to FIGS. 7 and 8. In this example, the middlebox element 225 is configured to register for a callback from the VM migration manager 235 and thus the VM migration manager 235 sends a pre-notification to the middlebox element 225. [0052] The middlebox element of some embodiments sends the gathered state for the VM and sends the state to the VM migration manager. Also, as the VM continues to function in the source host, the state related to the VM may also change. The middlebox element identifies these changes and sends the changes to the VM migration manager until the VM migration manager stuns the VM to move the VM to the destination host. [0053] The third stage 215 shows that the VM migration manager 235 has stunned the VM 250 and is sending the middlebox state of the VM 250 and the VM 250 (e.g., the VM's state) to the host 165, which is the destination host to which the VM 250 is migrating in this example. In some embodiments, the VM migration manager of the source host sends the middlebox state and the VM state to the VM migration manager of the destination host. The VM migration manager at the destination host provisions the migrating VM in the destination host and provides the middlebox state to the middlebox element running in the destination host.); or
controlling, based on the pre-notification response, a fifth VNFC to enter the target stage of the lifecycle, wherein the pre-notification response indicates that the VNF rejects the first VNFC to enter the target stage of the lifecycle or indicates a reason why the VNF rejects the first VNFC to enter the target stage of the lifecycle, and the fifth VNFC is one or more VNFCs other than the first VNFC in the VNF.
Regarding claim 3, Zhang teaches wherein the step of generating the pre-notification comprises:
generating a virtualized network function component (VNFC) onboarding pre-notification as the pre-notification, the VNFC onboarding pre-notification indicating that the VNF is going to enter a VNFC onboarding stage ([0051-53]; [0054] The fourth stage 220 shows that the VM migration manager 240 of the host 165 has received the state from the VM migration manager 235 of the host 155 and has sent the middlebox state to the middlebox element 230 of the host 165. In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of a new VM being provisioned in the host. In this example, the middlebox element 230 is configured to register for such a callback from the VM migration manager 240 and thus the VM migration manager 240 sends a pre-notification to the middlebox element 230. Also, the VM migration manager 240 sends the middlebox state of the migrating VM 250 along with the pre-notification. The VM migration manager 240 also starts the VM 250 in the host 165.); or
generating a VNFC termination pre-notification as the pre-notification, the VNFC termination pre-notification indicating that the VNF is going to enter a VNFC termination stage.
Regarding claim 4, Zhang teaches wherein the step of generating the pre-notification as the scale-in pre-notification comprises:
generating the scale-in pre-notification based on a first application instance in a second VNFC of the VNF, wherein the scale-in pre-notification indicates to the VNF that the first application instance is to be deleted ([0050] At the first stage 205, the VM migration manager 235 of the host 155 pre-notifies the middlebox element 225 that VM 1 that is currently running in the host 155 is going to be migrated to another host. In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of VM migration. Configuring a middlebox element will be described in detail further below by reference to FIGS. 7 and 8. In this example, the middlebox element 225 is configured to register for a callback from the VM migration manager 235 and thus the VM migration manager 235 sends a pre-notification to the middlebox element 225.); and
the step of controlling the VNF to enter the target stage of the lifecycle comprises:
deleting the first application instance based on the pre-notification response, wherein the pre-notification response is a scale-in pre-notification response indicating that the VNF allows to delete the first application instance ([0055] The fourth stage 220 also shows that the VM 250 is not in the host 155 and the middlebox element 225 does not have the middlebox state for the VM 250. In some embodiments, the middlebox element of the source host explicitly deletes the middlebox state related to the VM migrated out of the source host. Alternatively or conjunctively, the middlebox element of the source host lets the middlebox state of the migrated VM expire (e.g., by garbage-collecting the middlebox states that have an expired time to live (TTL)).);
deleting a second application instance of the VNF based on the pre-notification response, wherein the pre-notification response is a scale-in pre-notification response indicating to delete the second application instance, the second application instance comprised in a fourth VNFC in the VNF; or
deleting a third application instance of the VNF based on the pre-notification response, wherein the pre-notification response is a scale-in pre-notification response indicating that the VNF refuses to delete the first application instance or indicating a reason why the VNF refuses to delete the first application instance, the third application instance is not the first application instance of the second VNFC.
Regarding claim 5, Zhang teaches wherein the step of generating the scale-out pre- notification as the pre-notification comprises:
generating the scale-out pre-notification based on a first quantity, wherein the scale-out pre-notification indicates to the VNF that application instances of the first quantity are to be started, and the first quantity is a positive integer ([0050] At the first stage 205, the VM migration manager 235 of the host 155 pre-notifies the middlebox element 225 that VM 1 that is currently running in the host 155 is going to be migrated to another host. In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of VM migration. Configuring a middlebox element will be described in detail further below by reference to FIGS. 7 and 8. In this example, the middlebox element 225 is configured to register for a callback from the VM migration manager 235 and thus the VM migration manager 235 sends a pre-notification to the middlebox element 225.; [0054] In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of a new VM being provisioned in the host.); and
the step of controlling the VNF to enter the target stage of the lifecycle comprises:
starting the application instances of the first quantity based on the pre-notification response, wherein the pre-notification response is a scale-out pre-notification response indicating that the VNF allows starting of the application instances of the first quantity ([0054] The fourth stage 220 shows that the VM migration manager 240 of the host 165 has received the state from the VM migration manager 235 of the host 155 and has sent the middlebox state to the middlebox element 230 of the host 165. In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of a new VM being provisioned in the host. In this example, the middlebox element 230 is configured to register for such a callback from the VM migration manager 240 and thus the VM migration manager 240 sends a pre-notification to the middlebox element 230. Also, the VM migration manager 240 sends the middlebox state of the migrating VM 250 along with the pre-notification. The VM migration manager 240 also starts the VM 250 in the host 165. The middlebox element 230 of some embodiments creates a middlebox slice for VM 250 (if there is not a slice of the middlebox element for the logical network that the VM 250 belongs to) and uses the middlebox state received from the VM migration manager 240 to resume the middlebox service to the VM 250.);
starting application instances of a third quantity based on the pre-notification response, wherein the pre-notification response is a scale-out pre-notification response indicating to start the application instances of the third quantity, and the third quantity is a positive integer; or
starting application instances of a fifth quantity based on the pre-notification response, wherein the pre-notification response is a scale-out pre-notification response indicating that the VNF refuses to start the application instances of the first quantity or indicating a reason why the VNF refuses to start the application instances of the first quantity, and the fifth quantity is a positive integer less than the first quantity.
Regarding claim 6, Zhang teaches wherein the step of generating the scale-in pre- notification generates the scale-in pre-notification based on a second quantity, wherein the scale- in pre-notification indicates to the VNF that application instances of the second quantity are to be deleted, and the second quantity is a positive integer ([0050] At the first stage 205, the VM migration manager 235 of the host 155 pre-notifies the middlebox element 225 that VM 1 that is currently running in the host 155 is going to be migrated to another host. In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of VM migration. Configuring a middlebox element will be described in detail further below by reference to FIGS. 7 and 8. In this example, the middlebox element 225 is configured to register for a callback from the VM migration manager 235 and thus the VM migration manager 235 sends a pre-notification to the middlebox element 225.); and
the step of controlling the VNF to enter the target stage of the lifecycle comprises:
deleting the application instances of the second quantity based on the pre-notification response, wherein the pre-notification response is a scale-in pre-notification response indicating that the VNF allows deletion of the application instances of the second quantity ([0055] The fourth stage 220 also shows that the VM 250 is not in the host 155 and the middlebox element 225 does not have the middlebox state for the VM 250. In some embodiments, the middlebox element of the source host explicitly deletes the middlebox state related to the VM migrated out of the source host. Alternatively or conjunctively, the middlebox element of the source host lets the middlebox state of the migrated VM expire (e.g., by garbage-collecting the middlebox states that have an expired time to live (TTL)).);
deleting application instances of a fourth quantity based on the pre-notification response, wherein the pre-notification response is a scale-in pre-notification response indicating to delete the application instances of the fourth quantity, and the fourth quantity is a positive integer; or
deleting application instances of a sixth quantity based on the pre-notification response, wherein the pre-notification response is a scale-in pre-notification response indicating that the VNF refuses to delete the application instances of the second quantity or indicating a reason why the VNF refuses to delete the application instances of the second quantity, and the sixth quantity is a positive integer less than the second quantity.
Regarding claim 7, Zhang teaches wherein the step of generating a pre-notification generates the pre-notification based on a first time point, wherein the pre-notification indicates that the VNF is to enter the target stage of the lifecycle at the first time point, and the step of controlling the VNF to enter the target stage of the lifecycle comprises:
controlling, based on the pre-notification response, the VNF to enter the target stage of the lifecycle at the first time point, wherein the pre-notification response indicates that the VNF is allowed to enter the target stage of the lifecycle at the first time point;
controlling, based on the pre-notification response, the VNF to enter the target stage of the lifecycle at a second time point, wherein the pre-notification response indicates to control, at the second time point, the VNF to enter the target stage of the lifecycle ([0047] However, when a VM migrates from a source host to a destination host, the middlebox state related to the VM needs to be brought into the destination host in order for the migrated VM to resume its function at the destination host. [0050] At the first stage 205, the VM migration manager 235 of the host 155 pre-notifies the middlebox element 225 that VM 1 that is currently running in the host 155 is going to be migrated to another host. In some embodiments, the network control system configures the middlebox element running in a host in such a way that the middlebox registers for a callback from the VM migration manager in the event of VM migration. Configuring a middlebox element will be described in detail further below by reference to FIGS. 7 and 8. In this example, the middlebox element 225 is configured to register for a callback from the VM migration manager 235 and thus the VM migration manager 235 sends a pre-notification to the middlebox element 225. [0052] The middlebox element of some embodiments sends the gathered state for the VM and sends the state to the VM migration manager. Also, as the VM continues to function in the source host, the state related to the VM may also change. The middlebox element identifies these changes and sends the changes to the VM migration manager until the VM migration manager stuns the VM to move the VM to the destination host. [0053] The third stage 215 shows that the VM migration manager 235 has stunned the VM 250 and is sending the middlebox state of the VM 250 and the VM 250 (e.g., the VM's state) to the host 165, which is the destination host to which the VM 250 is migrating in this example. In some embodiments, the VM migration manager of the source host sends the middlebox state and the VM state to the VM migration manager of the destination host. The VM migration manager at the destination host provisions the migrating VM in the destination host and provides the middlebox state to the middlebox element running in the destination host.; or
controlling, based on the pre-notification response, the VNF to enter the target stage of the lifecycle at a third time point, wherein the pre-notification response indicates that the VNF refuses to enter the target stage of the lifecycle at the first time point or indicates a reason why the VNF refuses to enter the target stage of the lifecycle at the first time point, and the third time point is later than the first time point.
Regarding claim 9, Yu teaches wherein the step of generating the management instruction comprises:
generating a creation instruction based on a to-be-scaled-out VNFC, wherein the creation instruction instructs the CaaS manager to create a container instance of a container in the container cluster, and the container instance is for carrying a to-be-added application instance of the to-be-scaled-out VNFC ([0089] A virtualized network function manager (VNFM) is configured to implement life cycle management of the VNF, including management and processing of the VNFD, initialization of the VNF instance, scaling-out or scaling-in of the VNF, and termination of the VNF instance. The VNFM is further configured to receive and execute a elastic scaling policy delivered by a higher layer, to implement elastic scaling of the VNF.; [0092-93]);
generating a deletion instruction based on a to-be-scaled-in VNFC, wherein the deletion instruction instructs the CaaS manager to delete from the container cluster a container instance of a container carrying a to-be-deleted application instance of the to-be-scaled-in VNFC ([0089] A virtualized network function manager (VNFM) is configured to implement life cycle management of the VNF, including management and processing of the VNFD, initialization of the VNF instance, scaling-out or scaling-in of the VNF, and termination of the VNF instance. The VNFM is further configured to receive and execute a elastic scaling policy delivered by a higher layer, to implement elastic scaling of the VNF.; [0092-93]);
generating a creation instruction based on a to-be-onboarded VNFC, wherein the creation instruction instructs the CaaS manager to create a container in the container cluster, and the container is for carrying the to-be-onboarded VNFC ([0089] A virtualized network function manager (VNFM) is configured to implement life cycle management of the VNF, including management and processing of the VNFD, initialization of the VNF instance, scaling-out or scaling-in of the VNF, and termination of the VNF instance. The VNFM is further configured to receive and execute a elastic scaling policy delivered by a higher layer, to implement elastic scaling of the VNF.); or
generating a deletion instruction based on a to-be-terminated VNFC, wherein the deletion instruction instructs the CaaS manager to delete from the container cluster a container carrying the to-be-terminated VNFC ([0089] A virtualized network function manager (VNFM) is configured to implement life cycle management of the VNF, including management and processing of the VNFD, initialization of the VNF instance, scaling-out or scaling-in of the VNF, and termination of the VNF instance. The VNFM is further configured to receive and execute a elastic scaling policy delivered by a higher layer, to implement elastic scaling of the VNF.).
Regarding claim 10, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 11, it is a system type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 12, it is a system type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 13, it is a system type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Regarding claim 14, it is a system type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Response to Arguments
Applicant’s arguments with respect to claims 1-7 and 9-14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195