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 .
Claims 1-3, 5, 7- 10, 12, 14- 17, and 19-23 are presented for examination.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
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.
Claim 23 is rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding Claim 23, the claim recites “identifying, from the source code, at least one environment variable usage or a file required at runtime for the container” and subsequently recites “determining that the at least one environment variable or the file is missing from the set of resources” and “until the at least one environment variable or the file is included in the set of resources”. The later recitations of “the at least one environment variable” lack proper antecedent basis because the claim earlier introduces “at least one environment variable usage”, not “at least one environment variable”. It is therefore unclear whether “the at least one environment variable” refers to the previously recited “environment variable usage” or to a separate, differently claimed “environment variable”. This ambiguity renders the metes and bounds of the claim unclear.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 -3, 5, 7 -10, 12, 14- 17, and 19 -23 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2016/0350081 A1), in view of Wang (US 2022/0012030 A1), further in view of Agarwal (US 10,268,837 B2), and Gajananan (US 2021/0397712 A1).
Regarding Claim 1, Kumar teaches
A system comprising: a processor; and a memory device storing program code that is executable by the processor for causing the processor to perform operations including:
receiving a request for a deployment of a container, [a specification associated with the deployment of the container including a set of resources for running the container] and an indicator for a repository storing source code associated with the container (Para. [0029], “the container configuration module 110 receives source elements 132 of an application 130… the container configuration module 110 inspects each of the source elements 132 for indications of other elements that are needed to execute the application 130.”) (Para. [0028], “the continuous development platform 150 also includes multiple containers, container images, and/or container configurations 152 within a container repository 154 maintained by the continuous development platform 150.”) Examiner Comments: Kumar teaches receiving source elements for a container application from a container repository and inspecting them to determine what is needed for execution, which maps to receiving a request for a deployment of a container with an indicator for a repository storing source code associated with the container.
prior to running the container: accessing the repository to determine a set of configuration requirements for running the container based on performing static analysis of the source code (Para. [0015], “the container configuration module may determine, from inspecting a source code file (a source element), that the source application requires a particular compiler or framework application (e.g., a dependency component not already included in the source elements). As such, the container configuration module includes the dependency component in the container configuration”) (Para. [0025], “multiple dependency models are provided, each of which is specifically configured for a particular type of source element (e.g., models specific to a particular programming language or framework or application component).”) Examiner Comments: Kumar inspects a source code file, without executing the source code, using language-specific and framework-specific dependency models to determine required components prior to building and running the container, which is a static analysis of the source code and which maps to accessing the repository to determine a set of configuration requirements for running the container based on performing static analysis of the source code.
Kumar did not specifically teach
a specification associated with the deployment of the container including a set of resources for running the container
determining a match or a mismatch between the set of resources and the set of configuration requirements
creating a validation web hook for the deployment to prevent the container from running until the set of resources is validated against the set of configuration requirements; and controlling the deployment of the container based on the match or the mismatch by, in response to determining the mismatch, returning an error for the validation web hook to prevent execution of the container, or, in response to determining the match, causing the deployment of the container.
However, Wang teaches
a specification associated with the deployment of the container including a set of resources for running the container (Para. [0023], “a workspace custom resource definition (CRD) is generated to define a workspace schema for the workspace. The workspace schema represents one or more modules that model the workspace, where each module is a collection of configurations to manage infrastructure resources provisioned for the workspace, and include one or more variables for operating the infrastructure resources.”) (Abstract, “An infrastructure controller (IC) operator is provided to the ADP to extend the API for communication with an infrastructure controller (IC), which has a set of IC definitions that define the infrastructure resources for the workspace.”) Examiner Comments: Wang’s workspace custom resource definition that defines a collection of configurations and variables for infrastructure resources, combined with the IC operator that defines infrastructure resources, teaches a deployment specification including a set of resources for running the container.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar’s teaching with Wang’s in order to leverage the Kubernetes operator pattern and custom resource definitions to define deployment specifications with resource sets, because Wang’s framework provides a well-known mechanism for specifying infrastructure resources needed for container deployments (Wang, [0005]-[0006]), and incorporating this into Kumar’s source-code-aware dependency analysis would enable a comprehensive pre-deployment configuration validation system.
Kumar and Wang did not specifically teach
determining a match or a mismatch between the set of resources and the set of configuration requirements
creating a validation web hook for the deployment to prevent the container from running until the set of resources is validated against the set of configuration requirements; and controlling the deployment of the container based on the match or the mismatch by, in response to determining the mismatch, returning an error for the validation web hook to prevent execution of the container, or, in response to determining the match, causing the deployment of the container.
However, Agarwal teaches
determining a match or a mismatch between the set of resources and the set of configuration requirements (Abstract, “A container validation procedure is determined for the container using a plurality of container validation routines. The container validation routines may reflect the role various validation entities have in validating the container and approving it for deployment.”) (Col. 5, ln. 57-67, “Build validation routines are validation routines performed on the source code as part of compiling and debugging the application and as such include but are not limited to criteria related to whether the source code for an application can be compiled, whether the source code is acceptable under unit test standards.”) Examiner Comments: Agarwal’s container validation routines that evaluate whether a container meets specified criteria before deployment teach determining a match, when the container passes validation, or a mismatch, when the container fails validation, between the set of resources and the set of configuration requirements.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar and Wang’s teaching with Agarwal’s in order to validate container configurations against determined requirements before deployment, because Agarwal teaches a comprehensive container validation framework that determines whether containers meet validation criteria before deployment and can prevent deployment of non-compliant containers (Agarwal, Summary), which would reduce runtime errors caused by missing configurations and improve overall deployment reliability.
Kumar, Wang, and Agarwal did not specifically teach
creating a validation web hook for the deployment to prevent the container from running until the set of resources is validated against the set of configuration requirements; and controlling the deployment of the container based on the match or the mismatch by, in response to determining the mismatch, returning an error for the validation web hook to prevent execution of the container, or, in response to determining the match, causing the deployment of the container.
However, Gajananan teaches
creating a validation web hook for the deployment to prevent the container from running until the set of resources is validated against the set of configuration requirements (Para 0075, “The method is executed by an admission control webhook in a cluster.”) (Para 0045, “A custom admission webhook may process the incoming request sent by the k8s API server 214 and returns its verdict (allow or deny etc.) to the k8s API based on its logic.”) Para 0066, “the present invention intercepts incoming creation requests to k8s API server. Then, the present invention enforces integrity on resources in requests by allowing or rejecting them to be created.”) Examiner Comments: Gajananan creates and registers an admission control webhook that intercepts each incoming deployment/resource creation request at the Kubernetes API server prior to persistence of the object, and holds the request until the webhook processes and validates it, which maps to creating a validation web hook for the deployment to prevent the container from running until the set of resources is validated against the set of configuration requirements.
in response to determining the mismatch, returning an error for the validation web hook to prevent execution of the container (Para 0136, “It processes each incoming request and determine its verdict (Allow or Reject) based on the logic…”), Para 0154, “an output is a decision: “ALLOW” or “REJECT”… For rejections, it would include a reason in a response.”) (Para 0068, “In case of an integrity violation, the admission controller 443 prevents both deployment of unauthorized workloads as well as resource changes.”) Examiner Comments: Gajananan, upon a negative validation verdict of Reject, returns a rejection decision with a reason in the webhook response to the API server and prevents deployment of the workload, which teaches, in response to determining the mismatch, returning an error for the validation web hook to prevent execution of the container.
or in response to determining the match, causing the deployment of the container (Para 0006, “responsive to the resource creation request corresponding to a deployment of the object and the release secret being present in the cluster, creating a resource requested by the resource creation request in the cluster.”) Examiner Comments: Gajananan, upon a positive validation verdict of Allow, causes the requested resource to be created in the cluster, which teaches, in response to determining the match, causing the deployment of the container.
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 Kumar, Wang, and Agarwal with Gajananan in order to enforce the determined configuration requirements at deployment time using a Kubernetes admission webhook that intercepts the deployment request before the object is persisted and returns an Allow or Reject verdict, because Gajananan teaches that such an admission webhook provides a common gate at the cluster through which all deployments must pass and can reject non-compliant deployments before the workload is created (Gajananan, FIGS. 2, 4, and 6), which would provide a reliable, platform-native mechanism for preventing execution of a container whose resources do not satisfy the source-code-derived configuration requirements, thereby reducing runtime errors caused by missing configurations and improving deployment reliability.
Regarding Claim 2, Kumar, Wang, Agarwal, and Gajananan teach
The system of Claim 1.
Wang further teaches
wherein the operations further comprise: monitoring a plurality of specifications to determine a subset of the plurality of specifications that include the indicator, the subset of the plurality of specifications including the specification (Para. [0010], “An infrastructure controller (IC) operator is provided to the ADP to extend the API for communication with an infrastructure controller (IC). … The workspace is built with the infrastructure resources defined by a workspace custom resource, and the CRD is deployed to the ADP via the IC operator to create the workspace custom resource based on the collection of configurations and the one or more variables.”) Examiner Comments: Wang’s Kubernetes operator continuously monitors workspace resource definitions and responds to those that reference the infrastructure controller, which teaches monitoring a plurality of specifications to determine a subset of the plurality of specifications that include the indicator.
in response to determining the specification includes the indicator, generating a custom resource associated with the deployment of the container, wherein the custom resource indicates the set of configuration requirements (Para. [0023], “a workspace custom resource definition (CRD) is generated to define a workspace schema for the workspace. The workspace schema represents one or more modules that model the workspace, where each module is a collection of configurations to manage infrastructure resources provisioned for the workspace, and include one or more variables for operating the infrastructure resources.”) Examiner Comments: Wang’s generation of a workspace custom resource definition that defines the configurations and variables for the deployment teaches generating a custom resource associated with the deployment that indicates the set of configuration requirements.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar’s teaching with Wang’s in order to leverage the Kubernetes operator pattern and custom resource definitions to define deployment specifications with resource sets, because Wang’s framework provides a well-known mechanism for specifying infrastructure resources needed for container deployments (Wang, [0005]-[0006]), and incorporating this into Kumar’s source-code-aware dependency analysis would enable a comprehensive pre-deployment configuration validation system.
Regarding Claim 3, Kumar, Wang, Agarwal, and Gajananan teach
The system of Claim 2.
Wang and Agarwal further teach
wherein controlling the deployment further comprises: updating the custom resource to indicate a missing configuration requirement of the set of configuration requirements based on determining the mismatch (Wang, Para. [0010], “the CRD is deployed to the ADP via the IC operator to create the workspace custom resource based on the collection of configurations and the one or more variables.”) (Agarwal, Abstract, “The container validation routines may reflect the role various validation entities have in validating the container and approving it for deployment.”) Examiner Comments: The Kubernetes operator pattern of Wang inherently updates custom resource status to reflect the current state of the managed resource, and combined with Agarwal’s validation result tracking, this teaches updating the custom resource to indicate a missing configuration requirement based on determining the mismatch.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar and Wang’s teaching with Agarwal’s in order to validate container configurations against determined requirements before deployment, because Agarwal teaches a comprehensive container validation framework that determines whether containers meet validation criteria before deployment and can prevent deployment of non-compliant containers (Agarwal, Summary), which would reduce runtime errors caused by missing configurations and improve overall deployment reliability.
Regarding Claim 5, Kumar, Wang, Agarwal, and Gajananan teach
The system of Claim 1.
Agarwal further teaches
wherein controlling the deployment further comprises: causing a notification indicating the mismatch to be presented at a user interface of a client device (Col. 8, ln. 12-47, “the validation entities 110 are entities that may input container validation routines or provide validation information to modify or approve validation routines or both. These validation entities 110 have a role in validating the container by determining, for example, which criteria to apply to the container.”) Examiner Comments: Agarwal’s validation reporting to validation entities, combined with Wang’s Kubernetes platform that inherently provides status and event notifications to users, teaches causing a notification indicating the mismatch to be presented at a user interface of a client device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar and Wang’s teaching with Agarwal’s in order to validate container configurations against determined requirements before deployment, because Agarwal teaches a comprehensive container validation framework that determines whether containers meet validation criteria before deployment and can prevent deployment of non-compliant containers (Agarwal, Summary), which would reduce runtime errors caused by missing configurations and improve overall deployment reliability.
Regarding Claim 7, Kumar, Wang, Agarwal, and Gajananan teach
The system of Claim 1.
Wang further teaches
wherein the set of configuration requirements includes a resource that is configurable subsequent to a startup of the container (Para. [0021], “IC operator 112 encodes the information for the IC using the workspace custom resource defined by the workspace CRD 110. The infrastructure configuration is not directly encoded in the IC operator 112; instead it is pre-configured as an IC 108 module… There are specific parts of the infrastructure configuration that the operator specifies as “variables”, which do get passed to the IC module.”) Examiner Comments: Wang teaches dynamically configurable variables that can be passed to infrastructure modules after initial deployment, which maps to a resource that is configurable subsequent to a startup of the container.
Kumar further teaches
determining the mismatch between the set of configuration requirements and the set of resources based on the resource being missing from the set of resources (Para. [0015], “the container configuration module may determine, from inspecting a source code file (a source element), that the source application requires a particular compiler or framework application (e.g., a dependency component not already included in the source elements). As such, the container configuration module includes the dependency component in the container configuration.”)Examiner Comments: Kumar’s identification of a required dependency component that is not already included in the source elements teaches determining a mismatch based on a resource being missing from the set of resources.
causing the deployment of the container in response to the mismatch (Wang, Para. [0010]-[0012], “the CRD is deployed to the ADP via the IC operator to create the workspace custom resource based on the collection of configurations and the one or more variables.”) Examiner Comments: Wang deploys workspaces where certain variables are dynamically configurable after startup, so that because the missing resource is configurable subsequent to startup and is thus not mandatory at startup time, the system causes the deployment even when there is a mismatch.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar’s teaching with Wang’s in order to leverage the Kubernetes operator pattern and custom resource definitions to define deployment specifications with resource sets that include post-startup configurable variables, because Wang’s framework provides a well-known mechanism for specifying infrastructure resources needed for container deployments (Wang, [0005]-[0006]), and incorporating this into Kumar’s source-code-aware dependency analysis would enable a comprehensive pre-deployment configuration validation system.
Regarding Claim 8, is a method claim corresponding to the system claim above (Claim 1) and, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 9, the claim is a method claim corresponding to the system of Claim 2 and is rejected for the same reasons set forth in the rejection of Claim 2.
Regarding Claim 10, the claim is a method claim corresponding to the system of Claim 3 and is rejected for the same reasons set forth in the rejection of Claim 3.
Regarding Claim 12, the claim is a method claim corresponding to the system of Claim 5 and is rejected for the same reasons set forth in the rejection of Claim 5.
Regarding Claim 14, the claim is a method claim corresponding to the system of Claim 7 and is rejected for the same reasons set forth in the rejection of Claim 7.
Regarding Claim 15, the claim is a non-transitory computer-readable medium claim corresponding to the system of Claim 1 and is rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 16, the claim is a non-transitory computer-readable medium claim corresponding to the system of Claim 2 and is rejected for the same reasons set forth in the rejection of Claim 2.
Regarding Claim 17, the claim is a non-transitory computer-readable medium claim corresponding to the system of Claim 3 and is rejected for the same reasons set forth in the rejection of Claim 3.
Regarding Claim 19, the claim is a non-transitory computer-readable medium claim corresponding to the system of Claim 5 and is rejected for the same reasons set forth in the rejection of Claim 5.
Regarding Claim 20, the claim is a non-transitory computer-readable medium claim corresponding to the system of Claim 7 and is rejected for the same reasons set forth in the rejection of Claim 7.
Regarding Claim 21, Kumar, Wang, Agarwal, and Gajananan teach
The system of Claim 1.
Wang further teaches
wherein the operations further comprise: continuously monitoring the deployment (Para. [0010], “the CRD is deployed to the ADP via the IC operator to create the workspace custom resource based on the collection of configurations and the one or more variables.”) Examiner Comments: Wang’s IC operator implements the Kubernetes operator reconciliation pattern that continuously monitors the deployed workspace custom resource, which teaches continuously monitoring the deployment.
Gajananan further teaches
in response to a change to the set of resources or the set of configuration requirements, reevaluating the match or the mismatch and controlling the deployment of the container based on the reevaluation (Para 0132, “after the initial deployment, the mechanism enforces integrity over the configuration changes to a deployed application package or an individual resource.”), Para 0069, “A controller manager … is essentially a reconciliation loop that drives actual cluster state toward the desired cluster state, communicating with the API server to create, update, and delete the resources it manages (pods, service endpoints, etc.).”) Examiner Comments: Gajananan, after the initial deployment, re-enforces its validation verdict over configuration changes to a deployed resource through a reconciliation loop, which combined with Agarwal’s match or mismatch determination teaches, in response to a change to the set of resources or the set of configuration requirements, reevaluating the match or the mismatch and controlling the deployment of the container based on the reevaluation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar, Wang, and Agarwal with Gajananan so that the validation web hook and reconciliation loop re-validate the deployment whenever the resources or configuration requirements change, because Gajananan teaches enforcing integrity over configuration changes to a deployed resource for the entire lifetime of the deployment (Gajananan, describing FIGS. 4 and 11-12), which would ensure that a container that becomes non-compliant after a change is again controlled based on the reevaluated validation result, thereby maintaining deployment reliability over time.
Regarding Claim 22, Kumar, Wang, Agarwal, and Gajananan teach
The system of Claim 1.
Kumar further teaches
wherein performing static analysis of the source code includes at least one of parsing configuration files, identifying environment variable usages, or identifying code patterns that indicate required configurations (Para. [0029], “the container configuration module 110 inspects each of the source elements 132 for indications of other elements that are needed to execute the application 130.”) (Para. [0025], “multiple dependency models are provided, each of which is specifically configured for a particular type of source element (e.g., models specific to a particular programming language or framework or application component).”) Examiner Comments: Kumar’s inspection of source elements for indications of other elements needed to execute the application, using models specific to a particular programming language or framework, teaches identifying code patterns that indicate required configurations, which satisfies at least one of the claimed alternatives of the static analysis.
Regarding Claim 23, Kumar, Wang, Agarwal, and Gajananan teach
The system of Claim 1.
Kumar further teaches
wherein performing static analysis of the source code comprises identifying, from the source code, at least one environment variable usage or a file required at runtime for the container (Para. [0015], “the container configuration module may determine, from inspecting a source code file (a source element), that the source application requires a particular compiler or framework application (e.g., a dependency component not already included in the source elements).”) Examiner Comments: Kumar identifies, from inspecting a source code file, a component such as a compiler, framework, or file that the source application requires at runtime, which teaches identifying, from the source code, at least one environment variable usage or a file required at runtime for the container.
Agarwal further teaches
and wherein determining the mismatch comprises determining that the at least one environment variable or the file is missing from the set of resources (Abstract, “A container validation procedure is determined for the container using a plurality of container validation routines.”) Examiner Comments: Agarwal’s container validation procedure that evaluates whether the container satisfies the required criteria, combined with Kumar’s determination that a required component is not already included in the source elements, teaches determining that the at least one environment variable or the file is missing from the set of resources.
Gajananan further teaches
and wherein returning the error for the validation web hook prevents startup of the container until the at least one environment variable or the file is included in the set of resources (Para 0136, “It processes each incoming request and determine its verdict (Allow or Reject) based on the logic…”; Para 0068, “In case of an integrity violation, the admission controller 443 prevents both deployment of unauthorized workloads as well as resource changes.”) Examiner Comments: Gajananan rejects and thereby blocks a deployment request that fails validation until a compliant request is submitted, which teaches that returning the error for the validation web hook prevents startup of the container until the at least one environment variable or the file is included in the set of resources.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kumar, Wang, and Agarwal with Gajananan so that the validation web hook blocks startup of the container until the missing required resource identified by the static analysis is included, because Gajananan teaches that the admission webhook is a common gate through which every deployment must pass and that rejects non-compliant deployments before the workload is created (Gajananan, describing FIGS. 2, 4, and 6), which would prevent runtime errors caused by a container being started without a required environment variable or file.
Response to Arguments
Applicant’s arguments with respect to claims 1-3, 5, 7- 10, 12, 14- 17, and 19- 23 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations.
Conclusion
THIS ACTION IS MADE FINAL. 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 AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights