CTNF 18/537,278 CTNF 98979 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claims 1-20 are currently pending for examination. Claim Objections 07-29-01 AIA Claim 18 is objected to because of the following informalities: Claim 18 recites “executing the operations that cause the preemptible node to be associated with the label further comprises associated each preemptible node of the pool of preemptible nodes with the label” . The underlined portion appears to contain a typographical error; i.e., “associated…” should be “associating…” . Appropriate correction is required. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claims 1-2 , 6, 9, and 15-16 are rejected under 35 U.S.C. 103 as being unpa tentable over Azaria (US 20220147380 A1) in view of Eppstein ( US 7703102 B1) . As per claim 1, Azaria discloses: A computer-implemented method, comprising: executing a cluster management service configured to manage a cluster comprising a plurality of nodes that are individually configured to execute one or more containerized applications; receiving, by the cluster management service, a request for a preemptible node; executing operations that cause the preemptible node to be generated and associated with a label that indicates a preemptible capacity type ("A system according to the present techniques can generally comprise a VM spot manager and a cloud spot manager .", 0024 ; "A VM spot manager can connect to a cloud spot manager and allow the cloud spot manager to deploy resource consumer customer VMs on available computing resources of a resource producing customer's hardware. ", 0025 ; "Process flow 400 begins with 402, and moves to operation 404. Operation 404 depicts collecting metrics for multiple nodes. An on-premises system can comprise multiple computing nodes on which VMs can be executed .", 0060 ; "Operation 304 depicts receiving a request to deploy a spot VM . Using the example of system architecture 100 of FIG. 1, this can be a request received by cloud spot manager 102 and from VM spot manager 108a of customer system 110a via communications network 104.", 0053 ; "FIG. 3 illustrates an example process flow for deploying a spot virtual machine (VM) to facilitate optimizing hybrid cloud usage, in accordance with certain embodiments of this disclosure", 0006 ; Examiner Note: the cloud spot manager equates to a cluster management service, and a spot VM equates to a preemptible node executing a containerized application.) Azaria discloses the above limitations of claim 1, but does not disclose associating a preemptible node with a label that indicates preemptible capacity type. However, Eppstein discloses: executing operations that cause the preemptible node to be generated and associated with a label that indicates a preemptible capacity type ("Although not included in the example FML of Table 15, the optional server could be specified as either suspendable or preemptable (e.g., by using a "SUSPENDABLE" or "PREEMPTABLE" tag following the "<OPTIONAL>" tag). With the use of one of these two tags, if a server is allocated to the virtual server farm, the allocated server could be suspended or preempted by the service provider, if necessary. ", col.107, lines 3-9 ; Examiner Note: ) responsive to detecting that the preemptible node is associated with the label, deploying, by the cluster management service, a containerized application to the preemptible node, (“Additional alternatives for increasing the likelihood that an IDC will be successfully implemented include the use of optional resource requirements, alternative resource requirements, suspendable resource requirements, and preemptable resource requirements , all of which as described in detail below.”, col.52-53, lines 66-4 ; "When a service provider processes the request for the IDC, the service provider can itself determine the manner in which to satisfy the user's requirements specified in the request", col.50, lines 40-43 ; Examiner Note: the service provider equates to a cluster management service) the containerized application being configured to detect preemption of the preemptible node ("the resource allocator can provide a notification, such as an alert message, to the user of the other apparatus that includes the resource requirement that is characterized in that the resources that currently satisfy that resource requirement may be de-allocated will in fact be de-allocated.", col.94, lines 44-48 ; Examiner Note: the user of the other apparatus equates to the user of, or the container application itself) trigger the cluster management service to execute a set of shutdown operations corresponding to the preemptible node. ("The user that specified the resource requirement for the apparatus can indicate that the resource requirement can, under certain conditions specified by the user, be de-allocated from the apparatus. As a result, the service provider can determine if the conditions are met, and if so, de-allocate the resource from the apparatus to perform the maintenance.", col.77, lines 18-23 ; “FIG. 19 is a flow diagram illustrating de-allocation of resources from an apparatus based on suspendable resource requirements, according to an embodiment.”, col.80, lines 32-34 ; see fig.19- steps 1930, 1940, and 1950 are shutdown operations) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria with those of Eppstein to provide the system with a more sophisticated approach for improved reliability in the context of resource allocation (Eppstein, [col.51, lines 59-62]). As per claim 2, Azaria in view of Eppstein fully discloses the limitations of claim 1. Furthermore, Eppstein discloses: implementing, by the cluster management service, a deployment controller that is configured to deploy the containerized application to preemptible nodes that are individually associated with the label indicating the preemptible capacity type ("An approach for allocating resources to an apparatus based on preemptable resource requirements generally involves a resource allocator determining that a resource that satisfies a resource requirement for one apparatus is not available but that another resource that currently satisfies another resource requirement for another apparatus does satisfy the resource requirement. The resource allocator determines that the other resource requirement for the other apparatus is characterized in that resources that currently satisfy the other resource requirement may be de-allocated from the other apparatus, such as a preemptable resource requirement. The resource allocator de-allocates the resource from the other apparatus and allocates the resource to the one apparatus.", col.2, lines 34-47; "Although not included in the example FML of Table 15, the optional server could be specified as either suspendable or preemptable (e.g., by using a "SUSPENDABLE" or "PREEMPTABLE" tag following the "<OPTIONAL>" tag). With the use of one of these two tags, if a server is allocated to the virtual server farm, the allocated server could be suspended or preempted by the service provider, if necessary. ", col.107, lines 3-9 ; Examiner Note: the resource allocator equates to a deployment controller) As per claim 6, Azaria in view of Eppstein fully discloses the limitations of claim 1. Furthermore, Azaria discloses: responsive to receiving a preemption message from the containerized application, removing one or more containers executing on the preemptible node from a list of candidate containers to which new workloads are assignable. ("Operation 712 depicts reporting the action to the cloud spot manager In some examples, this comprises VM spot manager 108a sending a communication to cloud spot manager 102 an identification of which VM was terminated. ", 0079 ; " In some examples, VM spot manager 108a can maintain a list of VMs running on on-premises nodes 106a , along with an indication of what entity owns that VM instance.", 0076 ; Examiner Note: it is implicit that upon receipt of the identification of a terminated Spot VM from the VM spot manager (equating to a preemption message from the containerized application) the Spot VM is removed from the list of VMs running on on-premises nodes) As per claim 9, it is a system claim ( cloud computing system, comprising: one or more processors; and one or more memories storing computer-executable instructions (“An on-premises cloud computing solution can provide for a flexible pricing model that is subscription based.”, 0035; “…the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers”, 0121 ; “those skilled in the art will appreciate that the various methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems”, 0122)) with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons. As per claim 15, it is a non-transitory computer readable medium claim ( A non-transitory computer-readable medium comprising computer- executable instructions (“Computer-readable storage media can include, but are not limited to… other tangible and/or non-transitory media which can be used to store desired information. In this regard, the terms “tangible” or “non-transitory” herein as applied to storage, memory or computer-readable media, are to be understood to exclude only propagating transitory signals per se as modifiers and do not relinquish rights to all standard storage, memory or computer-readable media that are not only propagating transitory signals per se.”, 0125)) with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons. As per claim 16, Azaria in view of Eppstein fully discloses the limitations of claim 15. Furthermore, Eppstein discloses: the preemption of the preemptible node is triggered based at least in part on a second request for an on- demand node that is unavailable due to current on-demand capacity of the cloud computing system ("receiving a second request that specifies a second plurality of resource requirements for said second apparatus, wherein said second plurality of resource requirements includes said second resource requirement; and after determining that said first resource is not available, identifying, based on said second request, that said second resource requirement is preemptable.", clm.10) 07-21-aia AIA Claims 3 a nd 4 are rejected under 35 U.S.C. 103 as being unpatentab le over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Sinha (US 20230168912 A1) in further view of Andersen (US 20200133 733 A1) . As per claim 3, Azaria in view of Eppstein fully discloses the limitations of claim 1, but does not disclose the transmission of instructions to generate a preemptible node according to a preemptible node configuration, or associating the preemptible node with preemptible metadata. However, Sinha discloses: transmitting, to a compute service, instructions to generate the preemptible node according to a preemptible node configuration, ("At the start of the HA initialize workflow, an instruction to deploy the target VCM VM with the HA preemptible configuration, which sets the HA preemptive VM flag as true for the target VCM VM, is sent to the source cluster service by the source LCM service, as indicated by the arrow 602. In an embodiment, the HA preemptive VM flag for the target VCM VM may be stored in shared datastore in the cluster 102 by the HA system.", 0060 ; “At block 504, an operation is executed by the source LCM service to deploy the target VCM VM with a preemptible configuration in response to a stage API from the requesting entity.”, 0051) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria in view of Eppstein with those of Sinha in order to protect the system from node/VM failures by using preemptible VMs as failover VMs (Sinha, [0060]). Azaria in view of Eppstein in further view of Sinha discloses transmitting instructions to generate a preemptible node according to a preemptable node configuration, but does not disclose associating a preemptible node with preemptible metadata. However, Andersen discloses: generating the preemptible node causes the compute service to associate the preemptible node with preemptible metadata defined by the preemptible node configuration . ("The method 300 begins at block 302 where a manager system identifies a first ephemeral workload. In an embodiment, at block 302, the metadata manager system 210 in the HCI cluster 202 may identify a first ephemeral workload.", 0028 ; Examiner Note: an ephemeral workload corresponds to a preemptible node, identifying a preemptible node in the metadata manager equates to associating a preemptible node with preemptible metadata.) The combination of Azaria in view of Eppstein in further view of Sinha in further view of Andersen would provide a system capable of associating a preemptible node with preemptible metadata defined by the preemptible node configuration. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, Sinha, and Andersen in order to increase the overall performance of HCI (hyper-converged infrastructure) clusters while also improving {ephemeral/ preemptive} workload processing times for workloads performed via HCI systems (Andersen, [0027]). As per claim 4, Azaria in view of Eppstein in further view of Sinha in further view of Andersen fully discloses the limitations of claim 3. Furthermore, Andersen discloses: generating the preemptible node causes a script to be executed that 1) identifies the preemptible node as being of the preemptible capacity type based at least in part on the preemptible metadata associated with the preemptible node (see Fig.3-step 306 generates a preemptible node/ ephemeral workload, and step 312 identifies a workload as being ephemeral/preemptible ; “"In an embodiment, at block 302, the metadata manager system 210 in the HCI cluster 202 may identify a first ephemeral workload.", 0028) Furthermore, Eppstein discloses: 2) associates the preemptible node with the label that indicates the preemptible capacity type. (“Although not included in the example FML of Table 15, the optional server could be specified as either suspendable or preemptable (e.g., by using a SUSPENDABLE" or "PREEMPTABLE" tag following the "<OPTIONAL>" tag). With the use of one of these two tags, if a server is allocated to the virtual server farm, the allocated server could be suspended or preempted by the service provider, if necessary.", col.105, lines 36-46) 07-21-aia AIA Claim s 5 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Virtuoso (US 11128701 B1) . As per claim 5, Azaria in view of Eppstein fully discloses the limitations of claim 1, but does not disclose triggering the service to execute shutdown operations- nor that these operations be triggered by the transmission of a preemption message. However, Virtuoso discloses: triggering the cluster management service to execute the set of shut down operations comprises transmitting, by the containerized application to the cluster management service, a preemption message that indicates that a preemption event corresponding to the preemptible node has occurred. ("… the preemption execution agent 202A may itself monitor the remaining tasks in the task queue to determine when the worker node has completed execution of all its tasks in the task queue. When the preemption execution agent 202A determines that the worker node has completed execution of all tasks in the task queue it causes that worker node to be made available in a resource pool in the provider network, e.g., by sending a message at (5) indicating that the worker node is ready to be removed from the QPG .", col.11, lines 34-44 ; Examiner Note: the message sent by the preemption agent equates to a preemption message indicating that a preemption event has occured) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, and Virtuoso in order to improve the utilization of computing resources in the resource pool via the preemption of resources (Virtuoso, [col.10, lines 28-32]). As per claim 10, Azaria in view of Eppstein fully discloses the limitations of claim 9, but does not disclose the transmission of a shutdown signal to one or more workloads. However, Virtuoso discloses: responsive to receiving a preemption message from the containerized application, transmit a shutdown signal to one or more workloads being executed by the preemptible node. ("At (3), the resource controller 112 transmits a request to preempt the one or more identified computing nodes to the query execution engine 120 . For instance, the resource controller 112 may identify that a particular worker node (worker node 138M) in a first group of nodes (QPG 122A) is a candidate to be preempted and then transmit a request to the coordinator node 124A in the QPG 122A to preempt the worker node 138M that includes an identifier of a particular node, or an identifier of a number of nodes from the group that need to be preempted (which may be the case if all worker nodes have similar resource configurations/amounts).", col.8-9, lines 60-3 ; "At (6), the coordinator node 124A causes the preemption of the worker node 138M by releasing the worker node 138M into the resource pool 140.", col.9, lines 38-48 ; Examiner Note: causing the preemption of the worker node equates to transmitting a shutdown signal) 07-21-aia AIA Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Andersen (US 20200133733 A1) . As per claim 7, Azaria in view of Eppstein fully discloses the limitations of claim 1, but does not disclose obtaining data from a node metadata service component. However, Andersen discloses: the containerized application is configured to detect the preemption of the preemptible node based at least in part on obtaining data from a node metadata service component executing at a device associated with the preemptible node ("The method 300 begins at block 302 where a manager system identifies a first ephemeral workload. In an embodiment, at block 302, the metadata manager system 210 in the HCI cluster 202 may identify a first ephemeral workload.", 0028) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, and Andersen in order to increase the overall performance of HCI (hyper-converged infrastructure) clusters while also improving {ephemeral/ preemptive} workload processing times for workloads performed via HCI systems (Andersen, [0027]) . 07-21-aia AIA Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Andersen (US 20200133733 A1) in further view of Payne (US 20230281313 A1) . As per claim 8, Azaria in view of Eppstein in further view of Andersen fully discloses the limitations of claim 7, but does not disclose a metadata service component executing at a smart network interface card. However, Payne discloses: the device executing the node metadata service component executes at a smart network interface card that is communicatively connected to a host device on which the preemptible node executes. ("A second exemplary embodiment relates to a cloud infrastructure node. The cloud infrastructure can include a processor and a non-transitory computer-readable medium. The non-transitory computer-readable medium can include instructions that, when executed by the processor, cause the processor to transmit a first request to a smart network interface card (SmartNIC). The first request requests a pre-boot execution environment executable. The SmartNIC is associated with a metadata management service that manages secure boot metadata operable for verifying a boot loader.", 0005) 07-21-aia AIA Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Ahlvin (US 20240176637 A1) . As per claim 11, Azaria in view of Eppstein fully discloses the limitations of claim 9, but does not disclose the preemptible capacity type identifying the preemptible node as being reclaimable and lacking a time guarantee. However, Ahlvin discloses: the preemptible capacity type identifies the preemptible node as being reclaimable capacity that lacks a time guarantee. (a preemptible allocation type that utilizes a preemptible pricing model, or spot model, that enables spot VMs to be purchased at a significant discount relative to other pricing models with the provision that spot VMs can be taken away from the service at any time with minimal warning.", 0007 ; Examiner Note: being taken away equates to being reclaimed) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, and Ahlvin in order to improve user satisfaction through the creation and provisioning of optimal allocation plans based on multiple allocation types with different pricing models (Ahlvin, [0031-0033]) . 07-21-aia AIA Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Lakshman (US 20170344274 A1) . As per claim 12, Azaria in view of Eppstein fully discloses the limitations of claim 9, but does not disclose monitoring the metadata to detect initiation of preemption. However, Lakshman discloses: the containerized application monitors node metadata provided by a node metadata service, wherein the node metadata indicates that the preemption of the preemptible node has been initiated. ("Accordingly, in step 808 a second virtual machine (such as virtual machine 172) begins the preempt process by first performing a read reservation command by providing the name of the virtual disk. This command is passed from its CVM 170 to a metadata module on any storage node within platform 20 which reads the reservation field 866 from the storage node corresponding to the virtual disk and returns it to the virtual machine.", 0056 ; Examiner Note: returning the reservation field to the virtual machine equates to an indication that preemption has been initiated) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, and Lakshman in order to provide a system which only needs to add metadata concerning a new virtual disk in order to provision the disk, thereby conserving physical storage (Lakshman, [0026]) . 07-21-aia AIA Claims 13, 17, an d 18 are rejected under 35 U.S.C. 103 as being unpatentab le over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Hildebrand (US 20200285 502 A1). As per claim 13, Azaria in view of Eppstein fully discloses the limitations of claim 9, but does not disclose the assigning of low priority workloads to preemptible nodes. However, Hildebrand discloses: assign low priority workloads to the preemptible node (“a secondary job may be thought of as a preemptible job and comprises services or jobs that are lower priority than the service or job on the primary resource", 0013) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, and Hildebrand in order to provide the system with a preemptible allocation system which leads to more efficient use of network resources and potentially mitigates having to otherwise grow potentially under-utilized networks, which results in reductions in high availability (“HA”) costs (Hildebrand, [0003]). As per claim 17, Azaria in view of Eppstein fully discloses the limitations of claim 15, but does not disclose a request for the addition of a pool of preemptible nodes. However, Hildebrand discloses: the request for the preemptible node requests addition of a pool of preemptible nodes ("As such, preemptible job requests may be satisfied and continue to launch until the maximum threshold for computing resources is consumed and no, or insufficient, computing resources set aside for preemptive jobs are available. At this point, no failover jobs will be launched in the secondary or preemptive pool.", 0018) As per claim 18, Azaria in view of Eppstein fully discloses the limitations of claim 15. Furthermore, Eppstein discloses: executing the operations that cause the preemptible node to be associated with the label further comprises associated each preemptible node of the pool of preemptible nodes with the label (" Although not included in the example FML of Table 15, the optional server could be specified as either suspendable or preemptable (e.g., by using a "SUSPENDABLE" or "PREEMPTABLE" tag following the "<OPTIONAL>" tag). With the use of one of these two tags, if a server is allocated to the virtual server farm, the allocated server could be suspended or preempted by the service provider, if necessary. ", col.107, lines 3-9) Although Eppstein only discloses the tagging of servers/nodes as preemptible, the combination of Eppstein in view of Hildebrand (see Hildebrand, [0018]) would provide a system capable of associating each preemptible node of a pool of preemptible nodes with the preemptive label/tag . 07-21-aia AIA Claim s 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Giladi (US 20230010330 A1) . As per claim 14, Azaria in view of Eppstein fully discloses the limitations of claim 9, but does not disclose monitoring messages issued by a node metadata service. However, Giladi discloses: the containerized application is configured to detect the preemption of the preemptible node based at least in part on monitoring messages issued by a node metadata service ("At 440, a computing device (e.g., the computing device 104) may determine a potential termination of access or use of the computing device 108a-b (e.g., the preemptible instance computing device 108a-b). For example, the computing device 104 may receive a message 303 or other indication from the preemptible instance computing device 108a-b and/ or from the third-party provider of the preemptible instance computing device 108a-b that the temporary access to the preemptible instance computing device 104 will be terminated . For example, the message 303 may include an indication of when the temporary access to the preemptible instance computing device will be terminated or expire (e.g., a particular time of day (e.g., 3:20 p.m.), or in a particular or approximate amount of time (e.g., in two minutes or in about two minutes). ", 0077 ; Examiner Note: the third-party provider corresponds to a node metadata service) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, and Giladi in order to provide the system with a means for efficiently communicating the preemption of a preemptible node to that node (Giladi, [0133]). As per claim 20, Azaria in view of Eppstein fully discloses the limitations of claim 15, but does not disclose the transmission of one or more requests for a replacement preemptible node corresponding to the preemptible node. However, Giladi discloses: transmit one or more requests for a replacement preemptible node corresponding to the preemptible node. ("At 450, a computing device (e.g., the computing device 104) may send a second request for a replacement computing device (e.g., a replacement preemptible instance computing device) to replace the current computing device (e.g., the current preemptible instance computing device 108a-b).", 0081) 07-21-aia AIA Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Azaria (US 20220147380 A1) in view of Eppstein (US 7703102 B1) in further view of Kapoor (US 20220035626 A1) . As per claim 19, Azaria in view of Eppstein fully discloses the limitations of claim 15, but does not disclose drain and cordon operations provided by a Kubernetes engine. However, Kapoor discloses: the set of shutdown operations comprise cordon and drain operations provided by a Kubernetes engine ("In some aspects, the container nodes may be Kubernetes worker nodes", 0021 ; " In some aspects, the drain process 230 triggers a cordon and drain upgrade process. For example, the cordon and drain upgrade process is configured to mark a given container node unschedulable (so that the container node cannot be scheduled to execute a containerized application via its container deployment unit), drain the container node, and mark the container node for termination (step 238)", 0031) It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Azaria, Eppstein, and Kapoor in order to provide the system with a container deployment unit which is configured to act as a wrapper for launching/executing containers, thus allowing for the decoupling of a containerized application from a specific instance of a container deployment unit (Kapoor, [0024]) Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure : Iyer (US 20160358249 A1) – discloses a method for providing automatic scaling pure-spot clusters wherein clusters may be dynamically rebalanced for further cost savings. Eppstein (US 8234650 B1) – discloses a method for allocating resources to an apparatus wherein a request specifies one or more characteristics for the apparatus and a resource allocator determines the logical devices to be included in the apparatus. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM. 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, April Blair can be reached at (571) 270-1014. 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. /R.M.V./ Examiner, Art Unit 2196 /APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196 Application/Control Number: 18/537,278 Page 2 Art Unit: 2196 Application/Control Number: 18/537,278 Page 3 Art Unit: 2196 Application/Control Number: 18/537,278 Page 4 Art Unit: 2196 Application/Control Number: 18/537,278 Page 5 Art Unit: 2196 Application/Control Number: 18/537,278 Page 6 Art Unit: 2196 Application/Control Number: 18/537,278 Page 7 Art Unit: 2196 Application/Control Number: 18/537,278 Page 8 Art Unit: 2196 Application/Control Number: 18/537,278 Page 9 Art Unit: 2196 Application/Control Number: 18/537,278 Page 10 Art Unit: 2196 Application/Control Number: 18/537,278 Page 11 Art Unit: 2196 Application/Control Number: 18/537,278 Page 12 Art Unit: 2196 Application/Control Number: 18/537,278 Page 13 Art Unit: 2196 Application/Control Number: 18/537,278 Page 14 Art Unit: 2196 Application/Control Number: 18/537,278 Page 15 Art Unit: 2196 Application/Control Number: 18/537,278 Page 16 Art Unit: 2196 Application/Control Number: 18/537,278 Page 17 Art Unit: 2196 Application/Control Number: 18/537,278 Page 18 Art Unit: 2196 Application/Control Number: 18/537,278 Page 19 Art Unit: 2196
Prosecution Insights