CTNF 18/172,369 CTNF 87732 DETAILED ACTION 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. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claim(s) 5, 7, 12, 14 and 19 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 5 (similarly claims 12 and 19) recites the limitation "the received service level objectives". There is insufficient antecedent basis for this limitation in the claim. It is unclear if the received service level objectives are referring to the set of service level objectives or some other service level objectives. Claim 7 (similarly claim 14) recites “the detected violation”. There is insufficient antecedent basis for this limitation in the claim. It is unclear which violation “the detected violation” is referring to, since claim 1 which claim 7 depends on recites plural violations (“detecting violations”). Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 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 Claim (s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Browne et al. (Pub 20240235959) (hereafter Browne) in view of Aygar et al. (Pub 20240039804) (hereafter Aygar) . As per claim 1, Browne teaches: A computer-based method of maintaining service level objectives in container orchestration platforms using constraint propagation comprising: ([Paragraph 7], In an orchestrated environment where an application's execution may be distributed over a data center, cloud, fog, edge, or other devices, monitoring the execution of an application's flow is essential to optimizing orchestration of resources among nodes.) receiving a set of service level objectives associated with deployment of an application; ([Paragraph 29], It is important that as hardware platforms become more heterogenous (e.g., using multiple XPUs instead of a single CPU), the user should be abstracted from needing to define the multitude of contextual details in an orchestration request, and instead be able to focus on what it wants to achieve a certain set of objectives for the services at play. An intent-driven model provides this abstraction for the user and results in good performance for the service owner as well as good return on investment for the resource owner. Thus, what is needed is a way to map intents (defined as service level objectives) across a set of systems and their resources to achieve required levels of quality of service. [Paragraph 31], Service level objectives (SLOs) provide precise numerical targets for various system capabilities. Typical SLOs are oriented around service availability or uptime, service latency, service bandwidth provisioning, etc. SLOs are often expressed as percentages, such as requiring “99.9% uptime over a 30-day period,” or “Response time of less than 100 ms on at least 95% of the requests received.” [Paragraph 38], In production deployments a common pattern is to deploy new instances of an application on a portion of the environment and test with a small subset of the user base before rolling out to the wider population (i.e., Canary roll-out). Acknowledging that the SLA mapping to lower and lower levels of Service Level Objectives requires an iterative approach (for both optimization and remediation purposes), the new workflow for this SLA decomposition also includes the potential to partially deploy in either a limited end-to-end fashion or as sub-components of the E2E solution to determine impact on SLA adherence. [Paragraph 163], At 1204, the SLO is mapped to a plurality of policies. The mapping may be based on a static map. Alternatively, the mapping may be performed using heuristics or other intelligent mechanisms. ) determining a series of resource dependencies corresponding to the received set of service level objectives for the application; ([Paragraph 60], In further examples, an Edge computing system is extended to provide for orchestration of multiple applications through the use of containers (a contained, deployable unit of software that provides code and needed dependencies) in a multi-owner, multi-tenant environment. [Paragraph 160], Further, when an application is split into components, which are separately orchestrated, they may have ordering dependencies that affect the overall orchestration. Where such ordering dependencies are present, they may be described in abstract terms. For example, in a use case of a producer-consumer flow, the producing component may be specified as desirably staying X units of data, events, frames, etc. ahead of the consuming component. Accordingly, the sub-orchestrators for each component may have conditional responsibilities for allocation of resources (consumer needing fewer resources at time T0 than at time T0+delta, while the producer needing more resources at time T0−delta than at time T0). These “resource flows” become tightly coordinated among the sub-orchestrators so that the producer and consumer in our example collectively get an X-fraction of the CPU, cache, memory bandwidth, etc., but where the resources flow seamlessly according to the choreographed sharing between them. [Paragraph 163], At 1204, the SLO is mapped to a plurality of policies. The mapping may be based on a static map. Alternatively, the mapping may be performed using heuristics or other intelligent mechanisms.) generating a first set of constraints corresponding to service requirements for the received set of service level objectives; ([Paragraph 117], For example, consider an application requirement that there is certain percentage that something completes in a time window, referred to herein as “P50 Latency.” Other terms may also be used, which may be similar, such as “P50 Target” or “P50 Completions” to indicate that tasks, projects, requests, or the like, need to complete on time at least 50% of the time, or that there is at least a 50% probability that the task will complete on time. This intent is mapped to lower-level settings, such as to indicate a thread-level priority and from there to a CPU cache way/profile assignment/resource allocation. On the input/output (I/O) side, the intent may be mapped to network settings to ensure sufficient communication resources are available to transmit and receive the request and response. [Paragraph 128], FIG. 9 is a block diagram illustrating an operating environment 900 with multiple hardware systems 902A and 902B, according to an embodiment. The operating environment 900 may be considered a “system of systems” that stretches north-south (e.g., the full stack) and east-west (e.g., E2E). At each layer in a system 902A or 902B, different kinds of intent may be mapped north-to-south or east-to-west to SLOs. SLOs at various layers in the stack may be described in frames per second (FPS), latency, instructions per cycle (IPC), etc. SLOs between enterprises or systems may be described in terms of how individual applications making up the service need to interact to achieve the overall intent goals. For instance, the E2E SLOs may include a P99 latency <100 ms requirement, frontend max 10 ms, backend 5 ms, caching max 10 ms, etc. To achieve the goals of full-stack SLOs and E2E SLOs, the system enforces policies from higher layers to lower layers, and coordinates or negotiates between components within a layer across systems.) generating a second set of constraints corresponding to relationships within a target cluster between the target cluster resources and the series of resource dependencies corresponding to the received set of service level objectives for the application; ([Paragraph 160], Further, when an application is split into components, which are separately orchestrated, they may have ordering dependencies that affect the overall orchestration. Where such ordering dependencies are present, they may be described in abstract terms. For example, in a use case of a producer-consumer flow, the producing component may be specified as desirably staying X units of data, events, frames, etc. ahead of the consuming component. Accordingly, the sub-orchestrators for each component may have conditional responsibilities for allocation of resources (consumer needing fewer resources at time T0 than at time T0+delta, while the producer needing more resources at time T0−delta than at time T0). These “resource flows” become tightly coordinated among the sub-orchestrators so that the producer and consumer in our example collectively get an X-fraction of the CPU, cache, memory bandwidth, etc., but where the resources flow seamlessly according to the choreographed sharing between them. [Paragraph 163], At 1204, the SLO is mapped to a plurality of policies. The mapping may be based on a static map. Alternatively, the mapping may be performed using heuristics or other intelligent mechanisms. [Paragraph 164], At 1206, the plurality of policies are distributed to a plurality of sub-orchestrators, where each of the plurality of sub-orchestrators manage execution of a portion of the task. Policies may be grouped or separated by type, by resource, or by other factors. The sub-orchestrators may be responsible for a group of resources, a type of resource, a particular node or set of nodes, or the like. [Paragraph 125], The system may implement a new model for driving Kubernetes' life-cycle management (LCM) to reflect the needs of the application rather than the assumptions of the Kubernetes administrator. The application is deployed temporarily (to support fast start) and subsequently a new instance of Kubernetes is deployed with the cluster and node level policies that better reflects the needs of the application. The workload is subsequently moved to the new cluster. [Paragraph 156], The intent-based orchestrator may even subdivide the task to additional sub-orchestrators, so that multiple clusters of nodes are used to achieve the intent (or perhaps to enable an additional intent of high availability at a cluster level).) detecting violations of the first set of constraints; in response to detecting violations of the first set of constraints, determining one or more remediation measures to restore the received set of service level objectives based on the second set of constraints; and ([Paragraph 234], In an embodiment, the method 1700 includes generating remediation policies to be used when a task of the plurality of tasks violates an SLO associated with the task and configuring the analytics system with the allowable remediation policies. In a further embodiment, the method 1700 includes detecting a deviation from the SLO associated with the task and applying a remediation based on the remediation policies. In a further embodiment, applying the remediation includes applying a local remediation. In a related embodiment, applying the remediation includes applying a cluster-based remediation. [Paragraph 181], The SLO intent monitoring rules database 1304 contains rules for mapping SLO intents to various features, including but not limited to: monitor types, domain types, KPIs, required contexts, valid KPI ranges, KPI violation ranges, and allowable temporary excursions. Domain types may include infra, virtual, service mesh, Extended Berkeley Packet Filter (eBPF), Top-down Microarchitecture Analysis Method (TMAM), resource (e.g., cache, Intel® Speed Select Technology (SST)), and the like. KPI violation ranges may be used to establish guardrails of the system. Rules in the SLO intent monitoring rules database 1304 may have interrelationships, dependencies, or be hierarchical. [Paragraph 204], At block 1504, allowable remediation policies are generated. The policies may be based on guardrail rules that are stored in an SLO guardrail rule database 1506. The allowable remediations are automatically generated based on guardrail rules for the specific policy, target platforms, and networking to achieve a policy-specific remediation goal, target, or SLA. Remediation policies may be specific to service availability SLAs related to hardware availability SLAs, network availability SLAs, storage, acceleration, service mesh reliability SLAs, load balancer SLAs, and the like. The policies that are generated are stored in a SLO remediation policy database 1508, which is used in later operations to apply remediations.) outputting the one or more remediation measures to an end user . ([Paragraph 204], At block 1504, allowable remediation policies are generated. The policies may be based on guardrail rules that are stored in an SLO guardrail rule database 1506. [Paragraph 104], For instance, a first operating system corresponding to a first Edge compute node includes a real-time operating system having particular performance expectations of responsivity to dynamic input conditions, and a second operating system corresponding to a second Edge compute node includes graphical user interface capabilities to facilitate end-user I/O. [Paragraph 110], In some examples, distributed software causes display of one or more user interfaces (UIs) and/or graphical user interfaces (GUIs)…) Although Browne discloses storing and outputting remediation policies to a database and providing a user interface for displaying along with a recommendation to enable human guidance. [Paragraph 119] Browne does not explicitly disclose outputting the one or more remediation measures to an end user. Aygar teaches outputting the one or more remediation measures to an end user. Aygar also teaches remediation scenarios, resource requirements, dependencies, service level objective and etc. ([Paragraph 25], At 108, a user, for example, edge operator 102, assigns the available resource quotas for the compute infrastructure on edge device 106 via a user interface (UI) of a remote manager, such as orchestrator 104. [Paragraph 39], In some implementations, the meta scheduling of containerized workloads are based on one or more context elements. These context elements can be associated with applications in different domains such as retail, healthcare, government, manufacturing, and telecommunication, and they can be tuned by a user of the containerized workloads. [Paragraph 102], In some implementations, utilization triggered defragmentation includes two components: a) based on the telemetry data, the orchestrator identifies edge devices that are consistently under-utilized, and b) the orchestrator shows to the user through the orchestrator UI the possible resource savings, operating expense reduction, and sustainability improvements on defragmenting the containerized workload. [Paragraph 102], Based on analysis of the collected metrics if the orchestrator detects that some edges have been continually underutilized, it can trigger a defragmentation analysis on these edges. During the analysis stage, the orchestrator develops scenarios to gauge resource savings and in-turn expense reduction if the current workloads scheduled on a target node are migrated to a neighboring node and the target node is decommissioned. These scenarios are then presented to the user via the orchestrator UI. [Paragraph 103], In some implementations, context triggered defragmentation includes three components: a) based on the telemetry data, the orchestrator identifies workloads with interdependencies including trigger dependency and data dependency, b) the orchestrator then calculates performance improvement in defragmenting these workloads and co-locating them, and c) the performance improvement data are made available to the user through the orchestrator UI. [Paragraph 119], The second element is dynamic context of the workload and its dependent components, which can include the telemetry used to determine their performance, cost, and availably status on the current node and how far they are meeting their respective service level objective (SLO) (e.g., cost, performance, security, and availability) needs.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Browne wherein container orchestration platform receives service level objectives (SLOs) associated with application deployment, resource dependencies are determined to achieve the SLOs, constraints are generated for target cluster and corresponding resources associated with the SLOs, constraint violation(s) is/are detected, remediations are determined to achieve the SLOs and outputted into a database, into teachings of Aygar wherein a user interface is provided to a user to visually display various scenarios (i.e. remediation) associated with SLOs, because this would enhance the teachings of Browne wherein by displaying various remediations to the user, it allows the user to visually see various information including cost and performance, thus allowing the user to pick an optimal remediation based on cost benefit analysis based on needs. [Aygar paragraph 119] As per claim 2, rejection of claim 1 is incorporated: Browne teaches further comprising: automatically assigning scores to each of the one or more remediation measures; and ([Paragraph 205], The remediation policies in the SLO remediation policy database 1508 may be automatically updated. In an embodiment, training or use of re-enforcement learning uses application characteristics, SLAs, intents, profile description, current telemetry as inputs and generates remediation policy as output. At scale, the remediations can be scored and improved remediations can be generated/re-generated.) Aygar teaches outputting the assigned scores to the end user. ([Paragraph 25], At 108, a user, for example, edge operator 102, assigns the available resource quotas for the compute infrastructure on edge device 106 via a user interface (UI) of a remote manager, such as orchestrator 104. [Paragraph 39], In some implementations, the meta scheduling of containerized workloads are based on one or more context elements. These context elements can be associated with applications in different domains such as retail, healthcare, government, manufacturing, and telecommunication, and they can be tuned by a user of the containerized workloads. [Paragraph 102], In some implementations, utilization triggered defragmentation includes two components: a) based on the telemetry data, the orchestrator identifies edge devices that are consistently under-utilized, and b) the orchestrator shows to the user through the orchestrator UI the possible resource savings, operating expense reduction, and sustainability improvements on defragmenting the containerized workload. [Paragraph 102], Based on analysis of the collected metrics if the orchestrator detects that some edges have been continually underutilized, it can trigger a defragmentation analysis on these edges. During the analysis stage, the orchestrator develops scenarios to gauge resource savings and in-turn expense reduction if the current workloads scheduled on a target node are migrated to a neighboring node and the target node is decommissioned. These scenarios are then presented to the user via the orchestrator UI. [Paragraph 103], In some implementations, context triggered defragmentation includes three components: a) based on the telemetry data, the orchestrator identifies workloads with interdependencies including trigger dependency and data dependency, b) the orchestrator then calculates performance improvement in defragmenting these workloads and co-locating them, and c) the performance improvement data are made available to the user through the orchestrator UI. [Paragraph 119], The second element is dynamic context of the workload and its dependent components, which can include the telemetry used to determine their performance, cost, and availably status on the current node and how far they are meeting their respective service level objective (SLO) (e.g., cost, performance, security, and availability) needs.) As per claim 3, rejection of claim 2 is incorporated: Browne teaches wherein the assigned scores are based on resource distribution changes required or expected changes to a preconfigured prioritized resource. ([Paragraph 206], The types of remediations may vary. For instance, remediations may include quantitative or qualitative remediation at the node or cluster level. With a threshold applied to SLOs (e.g., x % of SLO reached), some local (e.g., node level, CPU level, server level) quantitative allocations can be applied to help avoid SLOs being breached (subject to policy). Allocating qualitative resources may require a cluster-level insight that may necessitate a microservice restart event to pick up on the new capability. [Paragraph 205], The remediation policies in the SLO remediation policy database 1508 may be automatically updated. In an embodiment, training or use of re-enforcement learning uses application characteristics, SLAs, intents, profile description, current telemetry as inputs and generates remediation policy as output. At scale, the remediations can be scored and improved remediations can be generated/re-generated.) As per claim 4, rejection of claim 1 is incorporated: Browne teaches wherein semantics of the generated second set of constraints are defined explicitly. ([Paragraph 204], At block 1504, allowable remediation policies are generated. The policies may be based on guardrail rules that are stored in an SLO guardrail rule database 1506. The allowable remediations are automatically generated based on guardrail rules for the specific policy, target platforms, and networking to achieve a policy-specific remediation goal, target, or SLA. Remediation policies may be specific to service availability SLAs related to hardware availability SLAs, network availability SLAs, storage, acceleration, service mesh reliability SLAs, load balancer SLAs, and the like. The policies that are generated are stored in a SLO remediation policy database 1508, which is used in later operations to apply remediations.) As per claim 5, rejection of claim 1 is incorporated: Browne teaches wherein semantics of the generated second set of constraints are continuously updated by employing regression models built by monitoring the series of resource dependencies corresponding to the received service level objectives. ([Paragraph 204], At block 1504, allowable remediation policies are generated. The policies may be based on guardrail rules that are stored in an SLO guardrail rule database 1506. The allowable remediations are automatically generated based on guardrail rules for the specific policy, target platforms, and networking to achieve a policy-specific remediation goal, target, or SLA. Remediation policies may be specific to service availability SLAs related to hardware availability SLAs, network availability SLAs, storage, acceleration, service mesh reliability SLAs, load balancer SLAs, and the like. The policies that are generated are stored in a SLO remediation policy database 1508, which is used in later operations to apply remediations. [Paragraph 205], The remediation policies in the SLO remediation policy database 1508 may be automatically updated. In an embodiment, training or use of re-enforcement learning uses application characteristics, SLAs, intents, profile description, current telemetry as inputs and generates remediation policy as output. At scale, the remediations can be scored and improved remediations can be generated/re-generated. [Paragraph 207], The SLO guardrail rule database 1506 contains rules to map intent-based SLOs to: hardware availability SLAs; network availability SLAs; storage, acceleration, or service mesh reliability SLAs; load balancer SLAs; canary roll-out of remediations to test in part of the system; or the like. [Paragraph 213], The data and control flow of FIG. 16 may be an implementation of, an instance of, or an extension to the operations for the analytics system to provide updates to rules based on continuous learning, as generally described in FIG. 13. As described in the discussion of Section 3, guardrails allow for some deviation from an SLO target. [Paragraph 120], Additionally, a plan's temporal aspect can also be useful from a continuous improvement point of view. A plan that satisfies all SLOs in the system-of-systems might be replaced by another plan which also satisfies all SLOs but triggers a different setup, configuration, or set of policies. For instance, to prepare for maintenance, an SLO may use resource more efficiently, make room for incoming workloads/services, or the like. [Paragraph 143], To provide continuous improvement, multiple control loops may be implemented. FIG. 11 is a block diagram illustrating data and control flow in an orchestration system, according to an embodiment. Intent-based SLOs are received at an SLO translator 1102, which feeds the translated SLOs to a service monitor 1104. The SLO translator 1102 may be an instance of, a component of, or include the planner 1012. The service monitor 1104 may be an instance of, a component of, or include the monitor 1014.) As per claim 6, rejection of claim 1 is incorporated: Browne teaches further comprising: automatically selecting and applying a highest-scoring remediation measure to the target cluster. ([Paragraph 170], Stage One is to automatically measure the achievement of the SLO outlined in the intent-based policy. Stage Two is to automatically monitor the SLO outlined in the intent-based policy when mapped to microservices and physical infrastructure platforms. Stage Three is to automatically apply SLO-specific remediations to ensure intent-based policies are achieved. Stage Four is to automatically evaluate remediations to ensure that remediations do not negatively impact the intent-based policies. [Paragraph 174], Section 3 focuses on methodologies to achieve automatic SLA remediation. This may be accomplished by forming a part of a control loop that takes steps to resolve application execution that is not meeting SLO requirements. [Paragraph 222], Once remediations are properly mapped into categories, the system operator can use a mapping of what remediation rules are best for specific situations or a specific status, and how they may impact the other services.) As per claim 7, rejection of claim 1 is incorporated: Browne teaches further comprising: determining that additional resources are required to address the detected violation; and outputting a secondary remediation measure including a recommendation to allocate additional resources from another cluster. ([Paragraph 170], Stage One is to automatically measure the achievement of the SLO outlined in the intent-based policy. Stage Two is to automatically monitor the SLO outlined in the intent-based policy when mapped to microservices and physical infrastructure platforms. Stage Three is to automatically apply SLO-specific remediations to ensure intent-based policies are achieved. Stage Four is to automatically evaluate remediations to ensure that remediations do not negatively impact the intent-based policies. [Paragraph 174], Section 3 focuses on methodologies to achieve automatic SLA remediation. This may be accomplished by forming a part of a control loop that takes steps to resolve application execution that is not meeting SLO requirements. [Paragraph 222], Once remediations are properly mapped into categories, the system operator can use a mapping of what remediation rules are best for specific situations or a specific status, and how they may impact the other services. [Paragraph 41], Thus, Edge computing attempts to reduce the amount of resources needed for network services, through the distribution of more resources which are located closer both geographically and in network access time. [Paragraph 37], As opposed to Hierarchical Service Level Agreements, the systems and methods described here introduce SLAs that are both nested and graduated. Instead of relying on classic thresholding, and instead of having hard set “single” clause rules to check, a nested sub-clause of the SLA can be evaluated in combination with other sub-clauses to evaluate the overall SLA. This allows more complex rules. Also, “parsing” of the sub-clauses allows results of each clause to create sharing of unused resources. This approach allows more flexibility in the SLA rules and better use of cluster resources. The flexibility can be introduced as an “intent” not a resource specification, which then is mapped to nested/graduated SLA rules which are then monitored and enforced. [Paragraph 125], The system may implement a new model for driving Kubernetes' life-cycle management (LCM) to reflect the needs of the application rather than the assumptions of the Kubernetes administrator. The application is deployed temporarily (to support fast start) and subsequently a new instance of Kubernetes is deployed with the cluster and node level policies that better reflects the needs of the application. The workload is subsequently moved to the new cluster. [Paragraph 212], At block 1516, the KPIs are monitored using the monitors. Telemetry is transmitted to the analytics system 1512. When an alert excursion from SLO is detected, the SLO remediation policy database 1508 defines the specific remediations to be applied at platform and cluster level. [Paragraph 119], The plan can be either automatically triggered or be partially manually triggered, for instance by first sending the plan as a recommendation to a human operator to enable human-guidance.) As per claims 8-14, these are system claims corresponding to the method claims 1-7. Therefore, rejected based on similar rationale. As per claims 15-20, these are computer-readable tangible storage medium claims corresponding to the method claims 1-6. Therefore, rejected based on similar rationale. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9: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, Bradley Teets can be reached at 5712723338. 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. /DONG U KIM/Primary Examiner, Art Unit 2197 Application/Control Number: 18/172,369 Page 2 Art Unit: 2197 Application/Control Number: 18/172,369 Page 4 Art Unit: 2197 Application/Control Number: 18/172,369 Page 5 Art Unit: 2197 Application/Control Number: 18/172,369 Page 6 Art Unit: 2197 Application/Control Number: 18/172,369 Page 7 Art Unit: 2197 Application/Control Number: 18/172,369 Page 8 Art Unit: 2197 Application/Control Number: 18/172,369 Page 9 Art Unit: 2197 Application/Control Number: 18/172,369 Page 10 Art Unit: 2197 Application/Control Number: 18/172,369 Page 11 Art Unit: 2197 Application/Control Number: 18/172,369 Page 12 Art Unit: 2197 Application/Control Number: 18/172,369 Page 13 Art Unit: 2197 Application/Control Number: 18/172,369 Page 14 Art Unit: 2197 Application/Control Number: 18/172,369 Page 15 Art Unit: 2197 Application/Control Number: 18/172,369 Page 16 Art Unit: 2197 Application/Control Number: 18/172,369 Page 17 Art Unit: 2197 Application/Control Number: 18/172,369 Page 18 Art Unit: 2197 Application/Control Number: 18/172,369 Page 19 Art Unit: 2197 Application/Control Number: 18/172,369 Page 20 Art Unit: 2197
Prosecution Insights