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 .
This action is responding to application papers dated 7/25/2023.
Claims 1-20 are pending in the application.
The information disclosure statement filed on 8/14/2023 has been considered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Specifically, claims 1-20 are directed to an abstract idea.
Per claim 1, the claim is directed to an idea of itself, mental processes that can be performed in the human mind, or by a human using a pen and paper. The steps of identifying, conducting testing, selecting a particular endpoint and steering as drafted can be pure mental processes under the broadest reasonable interpretation. The limitations encompass a human mind carrying out the function through observation, evaluation, judgement and/or option, or even with the aid of pen and paper. The steps can be mentally performed by a developer with the aid of pen and paper reviewing the new code. Conducting testing of a plurality of endpoints can be done mentally as part of exploratory testing, design reviews or during an initial development phase. A human can simulate the request and response cycle mentally to identify potential logic flaws. Steering an API call within the new code to a particular endpoint by examining the code can be done mentally as a part of static code analysis or mental tracing even without running the application (a developer can analyze the code structure, control flow to determine which URL, headers, and request body will be sent). The additional limitation, the device is described at a high level of generality for applying or performing the abstract idea and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with a generic computing component(s). See MPEP see MPEP 2106.05(f) /2106.05(h)/2106.05(g). It is noted that employing generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not add significantly more, similar to how limiting the abstract idea in Flook to petrochemical and oil-refining industries was insufficient. Therefore, the additional limitations do not integrate the abstract idea into a practical application. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components or insignificant extra solution activities (e.g. processors, devices, program instructions), then it falls within the "Mental Processes" grouping of abstract ideas (2019 PEG step 2A, Prong 1: Abstract idea grouping? Yes, Mental Process). Under step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Viewing the limitations individually and as a combination, the additional element merely performs the mental steps using a generic computing component as tools without integrating the abstract idea into a practical application. For at least these reasons, claim 1 is not patent eligible.
Per claims 2-10, these claims are directed to the same idea itself as in claim 1, reciting details of data and the mental steps (identifying, requesting, selecting, intercepting, returning steps), without adding any other additional element that is significantly more. Therefore, the claims are rejected for the same reasons as in claim 1.
Per claims 11-19, these claims are directed to the same idea itself as in claims 1-10, reciting the network interfaces, processor and memory as additional limitations which are described at a high level of generality for applying or performing the abstract idea and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with generic computing component(s) without adding any other additional element that is significantly more. Therefore, the claims are rejected for the same reasons as in claims 11-19.
Per claim 20, it is directed to the same idea itself as in claim 1, reciting the medium at the preamble described at a high level of generality for applying or performing the abstract idea and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with generic computing component(s) without adding any other additional element that is significantly more. Therefore, the claim is rejected for the same reasons as in claim 1.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 4, 11, 12, 14 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Joyce et al. (US 20210042207, hereafter Joyce).
1. A method comprising:
identifying, by a device, an application programming interface call within new code for an application (Joyce, see at least [0043] When a given test class is found to exist for a given endpoint… allow the introspection process to identify what endpoint path is being tested by the API security test; [0051] the SIT tool 310 detects changes to master code in the continuous integration environment, e.g., when new code is merged or promoted into the master code. ... performing API security test validation procedures and other common code testing and validation methods; Note that the SIT tool identifies an API call in the master code);
conducting, by the device, testing of a plurality of endpoints associated with the application programming interface call (Joyce, see at least [0006], the SIT tool continues the automated API security test validation process to: (i) determine whether each API security test file for each API endpoint specifies a validation test for each parameter of the API endpoint, … perform a test procedure on a given API endpoint to determine whether the given API is behaving properly; [0038] automatically perform internal API security validation testing to ensure that requisite API security tests have been created and implemented to test all API endpoints that are exposed by the plurality of microservices 182 of the application platform; Note that the SIT tool performs testing of endpoints);
selecting, by the device and based on results of the testing, a particular endpoint from among the plurality of endpoints (Joyce, see at least [0042]; [0046] a test procedure can be applied to each API endpoint to ensure that the API endpoint does not blindly pass invalid parameters or invalid parameter values. In particular, parameter security validation test procedures can be applied to the API endpoints … If the API request is accepted and processed, then it can be determined that the API endpoint is operating incorrectly; [0027], the whitelisting validation service performs a whitelisting validation operation which comprises comparing an API endpoint of the client API request to the whitelist of permitted API endpoints of registered microservices 182 of the application 180 to determine whether the API endpoint of the client API request comprises a permitted API endpoint in the whitelist. The whitelisting validation service of the API gateway 150 can be configured to validate one or more portions of a client request; - Note that every exposed endpoint in the whitelist should have a corresponding class (e.g., java class) to test the endpoint, therefore, the endpoints to be tested are selected for testing).
steering, by the device, the application programming interface call made by the application towards the particular endpoint (Joyce, see at least [022] the API gateway 150 comprises a plurality of gateway services, each configured to interface with a different type of client application. In all instances, the API gateway 150 performs various functions. For example, the API gateway 150 functions as a reverse proxy to redirect or route requests from client applications to target endpoints of the microservices 182. In this instance, the API gateway 150 provides a single endpoint or Uniform Resource Locator (URL) to receive requests from client applications for access to services of the application platform 180, and internally maps client requests to one or more of the microservices 182; Note that API calls are steered/redirected from an application to a different endpoint for API testing).
2. The method of claim 1, wherein the device identifies the application programming interface call in response to the new code being checked into a code repository (Joyce, see at least [0051], The process begins by launching the SIT tool 310 in a continuous integration environment which is configured to allow developers to develop, test, and integrate code into a shared repository, and which facilities continuous delivery and deployment of, e.g., constituent microservices of an application platform (block 400) … the SIT tool 310 detects changes to master code in the continuous integration environment, e.g., when new code is merged or promoted into the master code. When a change is code is detected (affirmative determination in block 401), the SIT tool 310 begins to execute automation tests which include, e.g., performing API security test validation procedures and other common code testing and validation methods; Note that the tool performs API validation test for the new code).
4. The method of claim 1, further comprising: selecting, by the device, a different endpoint from among the plurality of endpoints, based on additional test results (Joyce, see at least [0042]; [0046] a test procedure can be applied to each API endpoint to ensure that the API endpoint does not blindly pass invalid parameters or invalid parameter values. In particular, parameter security validation test procedures can be applied to the API endpoints … If the API request is accepted and processed, then it can be determined that the API endpoint is operating incorrectly; [0027], the whitelisting validation service performs a whitelisting validation operation which comprises comparing an API endpoint of the client API request to the whitelist of permitted API endpoints of registered microservices 182 of the application 180 to determine whether the API endpoint of the client API request comprises a permitted API endpoint in the whitelist. The whitelisting validation service of the API gateway 150 can be configured to validate one or more portions of a client request; - Note that every exposed endpoint in the whitelist should have a corresponding class (e.g., java class) to test the endpoint, therefore, the endpoints to be tested are selected for testing).
Per claims 11, 12, and 14, they are the apparatus versions of claims 1, 2, and 4 respectively, and are rejected for the same reasons set forth in connection with the rejection of claims 1, 2, and 4 above.
Per claim 20, it is the medium version of claim 1, and is rejected for the same reasons set forth in connection with the rejection of claim 1 above.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Joyce in view of O’Dell et al. (US11734153, hereafter O’Dell).
Per claims 3:
Joyce further teaches wherein conducting testing of the plurality of endpoints comprises:
(Joyce, see at least [0006], the SIT tool continues the automated API security test validation process to: (i) determine whether each API security test file for each API endpoint specifies a validation test for each parameter of the API endpoint, … perform a test procedure on a given API endpoint to determine whether the given API is behaving properly; [0038] automatically perform internal API security validation testing to ensure that requisite API security tests have been created and implemented to test all API endpoints that are exposed by the plurality of microservices 182 of the application platform; Note that the SIT tool performs testing of endpoints).
Joyce does not explicitly teach requesting that one or more probing agents send probe packets via a network towards the plurality of endpoints. O'Dell teaches requesting that one or more probing agents send probe packets via a network towards the plurality of endpoints (O’Dell, see at least fig.1 and associated texts, presenting that systems like Istio or Kubernetes can probe the API via the health check endpoint to determine whether the API is working or not. The generated health check(s) 108 can then be provided as a unit test 110 (and modified as needed) for testing the API by probing the health check endpoints). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined O’Dell’s probing agents with Joyce’s API testing to modify Joyce’s system to combine the probing function as taught by O’Dell, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development and/or testing. Combining O’Dell’s functionality with that of Joyce results in a system that allows probing packets. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to gather information about a network, devices etc. for testing or validation (O’Dell, see at least fig.1 and associated texts, presenting that systems like Istio or Kubernetes can probe the API via the health check endpoint to determine whether the API is working or not. The generated health check(s) 108 can then be provided as a unit test 110 (and modified as needed) for testing the API by probing the health check endpoints).
Per claim 13, it is the apparatus version of claim 3, and is rejected for the same reasons set forth in connection with the rejection of claim 3 above.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Joyce in view of Lemon et al. (US20150365441, hereafter Lemon).
Per claim 5:
Joyce does not explicitly teach wherein steering the application programming interface call comprises: intercepting a Domain Name System request from the application associated with the application programming interface call; and returning a Domain Name System response to the application with an address of the particular endpoint. O'Dell teaches wherein steering the application programming interface call comprises: intercepting a Domain Name System request from the application associated with the application programming interface call; and returning a Domain Name System response to the application with an address of the particular endpoint.
(Lemon, see at least [0037] block the DNS query 118 from the DNS engine 112 and return its own response to the individual device 102, or block the DNS query 118 from the DNS engine 112 and return no response to the individual device 112. If the dynamic policy enforcement engine 110 passes the original DNS query 118 or a modified DNS query to the DNS engine 112, it may return the DNS engine 112's response, return a modified version of the DNS engine 112's response, block the response and send its own response, or block the response and send no response; abstract, A dynamic policy enforcement engine in front of the DNS engine intercepts the DNS query, identifies the initiating device, and selects a policy that applies to the device. The dynamic policy enforcement engine may provide parental control and security service to the individual device by blocking the DNS query or passing it to the DNS engine according to the policy. A component that intercepts DNS queries). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Lemon’s DNS interception and returning a DNS response with Joyce’s API testing to modify Joyce’s system to combine the intercepting and returning a DNS response as taught by Lemon with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to data processing. Combining Lemon’s functionality with that of Joyce results in a system that allows a DNS intercepting and returning a response. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to redirect users to unintended address for network management and filtering (Lemon, see at least [0037] block the DNS query 118 from the DNS engine 112 and return its own response to the individual device 102, or block the DNS query 118 from the DNS engine 112 and return no response to the individual device 112. If the dynamic policy enforcement engine 110 passes the original DNS query 118 or a modified DNS query to the DNS engine 112, it may return the DNS engine 112's response, return a modified version of the DNS engine 112's response, block the response and send its own response, or block the response and send no response; abstract, A dynamic policy enforcement engine in front of the DNS engine intercepts the DNS query, identifies the initiating device, and selects a policy that applies to the device. The dynamic policy enforcement engine may provide parental control and security service to the individual device by blocking the DNS query or passing it to the DNS engine according to the policy. A component that intercepts DNS queries).
Per claim 15, it is the apparatus version of claim 5, and is rejected for the same reasons set forth in connection with the rejection of claim 5 above.
Claims 6, 7, 9, 10, 16, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Joyce in view of Guim et al. (US20210328886, hereafter Guim).
Per claim 6:
Joyce teaches the testing of the plurality of endpoints is performed by the SIT tool associated with a microservice of the application (Joyce, see at least [0005], a system integration testing (SIT) tool detects a change in master code associated with an application comprising a plurality of microservices and an application programming interface (API) gateway to route client API requests to the microservices of the application; [0022] the API gateway 150 functions as a reverse proxy to redirect or route requests from client applications to target endpoints of the microservices 182). Joyce does not explicitly teach, a sidecar proxy. Guim teaches a sidecar proxy (Guim, see at least [0025] execution of the sidecar based proxies. Because edge environments are resource constrained and require low response times, low and predictable latency is highly valued on the edge. Additionally, complex overhead of load balancing, other run-time variations, and telemetry collection add dilation of response time, jitter, high hysteresis, and cost. Additionally, across one or more chains of microservices, application response times can easily exceed the few milliseconds that are required to function according to service quality metrics (e.g., latency, response time, efficiency, etc.)… Load-balancing includes splitting a service (e.g., service instances) between multiple endpoints; [0075] logic that acts as a global sidecar proxy that obtains information from the IPUs 710a-710d across the platforms 702-702d corresponding to the capability and/or capacity of the edge appliances 704a-704d.). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Guim’s sidecar proxy with Joyce’s API testing to modify Joyce’s system to combine the sidecar proxy as taught by Guim with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to data processing. Combining Guim’s functionality with that of Joyce results in a system that allows to use a sidecar proxy. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to ensure security, extending service capabilities transparently (Guim, see at least [0025] execution of the sidecar based proxies. Because edge environments are resource constrained and require low response times, low and predictable latency is highly valued on the edge. Additionally, complex overhead of load balancing, other run-time variations, and telemetry collection add dilation of response time, jitter, high hysteresis, and cost. Additionally, across one or more chains of microservices, application response times can easily exceed the few milliseconds that are required to function according to service quality metrics (e.g., latency, response time, efficiency, etc.)… Load-balancing includes splitting a service (e.g., service instances) between multiple endpoints; [0075] logic that acts as a global sidecar proxy that obtains information from the IPUs 710a-710d across the platforms 702-702d corresponding to the capability and/or capacity of the edge appliances 704a-704d.).
7. The method of claim 6, wherein the sidecar proxy performs application response time testing based on the application making the application programming interface call (Guim, see at least [0025] execution of the sidecar based proxies. Because edge environments are resource constrained and require low response times, low and predictable latency is highly valued on the edge. Additionally, complex overhead of load balancing, other run-time variations, and telemetry collection add dilation of response time, jitter, high hysteresis, and cost. Additionally, across one or more chains of microservices, application response times can easily exceed the few milliseconds that are required to function according to service quality metrics (e.g., latency, response time, efficiency, etc.)… Load-balancing includes splitting a service (e.g., service instances) between multiple endpoints; [0075] logic that acts as a global sidecar proxy that obtains information from the IPUs 710a-710d across the platforms 702-702d corresponding to the capability and/or capacity of the edge appliances 704a-704d; -Note that the sidecar proxy performs telemetry collection including response time).
Per claim 9:
Joyce does not explicitly teach wherein the results of the testing are indicative of response times associated with the plurality of endpoints. Guim teaches wherein the results of the testing are indicative of response times associated with the plurality of endpoints (Guim, see at least [0025] execution of the sidecar based proxies. Because edge environments are resource constrained and require low response times, low and predictable latency is highly valued on the edge. Additionally, complex overhead of load balancing, other run-time variations, and telemetry collection add dilation of response time, jitter, high hysteresis, and cost. Additionally, across one or more chains of microservices, application response times can easily exceed the few milliseconds that are required to function according to service quality metrics (e.g., latency, response time, efficiency, etc.)… Load-balancing includes splitting a service (e.g., service instances) between multiple endpoints; [0075] logic that acts as a global sidecar proxy that obtains information from the IPUs 710a-710d across the platforms 702-702d corresponding to the capability and/or capacity of the edge appliances 704a-704d.). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Guim’s telemetry data on response times with Joyce’s API testing to modify Joyce’s system to combine the response times data as taught by Guim with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to data processing. Combining Guim’s functionality with that of Joyce results in a system that allows to gather response times of endpoints. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to obtain quality metrics to assess response time associated with endpoints (Guim, see at least [0025] execution of the sidecar based proxies. Because edge environments are resource constrained and require low response times, low and predictable latency is highly valued on the edge. Additionally, complex overhead of load balancing, other run-time variations, and telemetry collection add dilation of response time, jitter, high hysteresis, and cost. Additionally, across one or more chains of microservices, application response times can easily exceed the few milliseconds that are required to function according to service quality metrics (e.g., latency, response time, efficiency, etc.)… Load-balancing includes splitting a service (e.g., service instances) between multiple endpoints; [0075] logic that acts as a global sidecar proxy that obtains information from the IPUs 710a-710d across the platforms 702-702d corresponding to the capability and/or capacity of the edge appliances 704a-704d.).
Per claim 10:
Joyce does not explicitly teach wherein the results of the testing are indicative of reliability metrics for the plurality of endpoints. Guim teaches wherein the results of the testing are indicative of reliability metrics for the plurality of endpoints (Guim, see at least [0033] (b) Reliability and Resiliency (e.g., some input streams need to be acted upon and the traffic routed with mission-critical reliability, where as some other input streams may be tolerate an occasional failure, depending on the application); [0025] according to service quality metrics (e.g., latency, response time, efficiency, etc.)… Load-balancing includes splitting a service (e.g., service instances) between multiple endpoints; [0075] logic that acts as a global sidecar proxy that obtains information from the IPUs 710a-710d across the platforms 702-702d corresponding to the capability and/or capacity of the edge appliances 704a-704d.). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Guim’s telemetry data including reliability with Joyce’s API testing to modify Joyce’s system to combine the response times data as taught by Guim with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to data processing. Combining Guim’s functionality with that of Joyce results in a system that allows to obtain reliability metrics. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to obtain quality metrics to assess reliability associated with endpoints (Guim, see at least [0033] (b) Reliability and Resiliency (e.g., some input streams need to be acted upon and the traffic routed with mission-critical reliability, where as some other input streams may be tolerate an occasional failure, depending on the application); [0025] according to service quality metrics (e.g., latency, response time, efficiency, etc.)… Load-balancing includes splitting a service (e.g., service instances) between multiple endpoints; [0075] logic that acts as a global sidecar proxy that obtains information from the IPUs 710a-710d across the platforms 702-702d corresponding to the capability and/or capacity of the edge appliances 704a-704d).
Per claims 16, 17, and 19, they are the apparatus versions of claims 6, 7 and 9, and is rejected for the same reasons set forth in connection with the rejection of claims 6, 7, and 9 above.
Claims 8 and 18are rejected under 35 U.S.C. 103 as being unpatentable over Joyce in view of Talluri et al. (US10635566, hereafter Talluri).
Per claim 8:
Joyce further teaches wherein the device identifies the application programming interface call based on an indication sent to the device via a development platform (Joyce, see at least [0043] When a given test class is found to exist for a given endpoint… allow the introspection process to identify what endpoint path is being tested by the API security test; [0051] the SIT tool 310 detects changes to master code in the continuous integration environment, e.g., when new code is merged or promoted into the master code. ... performing API security test validation procedures and other common code testing and validation methods; Note that the SIT tool identifies an API call in the master code). Joyce does not explicitly teach a plugin to a development platform. Talluri teaches a plugin to a development platform (Talluri, see at least abstract, The IDE (or IDE plugin) prepares user-understandable indications of the performance impact of the one or more code changes, and displays the user-understandable indications of the performance impact in a graphical user interface (GUI) when a respective code change is displayed in the GUI). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Talluri’s plugin with Joyce’s API testing to modify Joyce’s system to combine the plugin as taught by Talluri with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to data processing. Combining Talluri’s functionality with that of Joyce results in a system that allows to use a development platform plugin. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to allow to integrate plugin tools directly into a development environment for extending IDE functionalities (Talluri, see at least abstract, The IDE (or IDE plugin) prepares user-understandable indications of the performance impact of the one or more code changes, and displays the user-understandable indications of the performance impact in a graphical user interface (GUI) when a respective code change is displayed in the GUI).
Per claim 18, it is the apparatus version of claim 8, and is rejected for the same reasons set forth in connection with the rejection of claim 8 above.
Examiner’s Note
The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20200401506 is related to ad-hoc batch testing of APIs;
US20150220376 is related to detecting irregularities of application programmer interface (API) entities;
US20230027880 is related to testing application programming interfaces (APIs) by utilizing at least one of API endpoint modeling data entities and workflow design user interfaces;
US20250004926 is related to API validation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INSUN KANG whose telephone number is (571)272-3724. The examiner can normally be reached M-TR 8 -5pm; week 2: Tu-F 8-5pm.
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, Chat Do can be reached at 571-272-3721. 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.
/INSUN KANG/Primary Examiner, Art Unit 2193