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 .
DETAILED ACTION
Response to Amendment
Applicant’s amendment, filed 10/23/2025, has been entered and carefully considered. Claims 1, 12 and 20 are amended. Claims 1-20 are currently pending.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 12 and 20 regarding limitation “capture or monitor live network data in real-time” have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments filed 10/23/2025 regarding “"retrieving source code from code repositories”, "determining that the data traffic and the source code are associated with application programming interface (API) traffic" and "determining a first API associated with the API traffic" have been fully considered but they are not persuasive.
Applicant argued that Caudill at col. 10, 11. 10-11, as allegedly teaching or suggesting "retrieving source code from code repositories," relying on its disclosure of "API code" stored in repositories, Caudill does not retrieve general application source code, nor does it determine which code generates API traffic”.
Examiner respectfully disagrees.
Caudill discloses in published patent (US 11467887 B1), (Col. 10, lines 5-50), the API system 134 may examine published code to find these definitions and use them to generate the set of existing APIs, descriptions, and parameters. As an example, prior to providing the user interface with API selection menu in block 302, API system 134 may automatically generate from one or more codebases (and/or other API database servers) a set of existing APIs, which may include the full set of existing APIs contained therein or a partial set thereof. Additionally, API system 134 may automatically generate or retrieve the full or partial set of descriptions and parameters associated with each generated API.
Further (Col. 10, lines 5-50), disclose the system may generate a set of existing APIs and descriptions relating to one or more APIs and/or parameters associated with one or more APIs. Accordingly, the system may examine code published to a public or private database to identify API endpoint definitions that are, for example, in compliance with one or more standardized formats. The system may then use these definitions to generate the set of existing APIs, descriptions, and parameters. Further the API system 134 may include (and/or may provide access to) a code generator system that provides an interface, object definition language, and/or code generator capabilities that define API contracts. For example, a code generator system may act as a code generator for APIs, such as to define API contracts for HTTP services. In addition, the system may generate clean interfaces and code for both servers and clients in one or more code-based languages.
Examiner noted that applicant’s claim language does not recite “determines which of the source codes generate API traffic" (see remarks page 2). Further claim does not disclose the association of retrieving source codes with API traffic, as the determining step does not clarify the mechanism of determine that the data traffic and the source code are associated with application programming interface (API) traffic as basis of determining is not in claim 1.
Thus, Caudill discloses the mechanism of retrieving source code from code repositories.
Applicant further argued that Caudill does not discloses “determining that the data traffic and the source code are associated with application programming interface (API) traffic”.
Examiner respectfully disagrees.
Caudill in (Col. 10, lines 5-50), disclose the API system 134 may automatically generate a full (or partial) set of existing APIs based on code repositories that each define their own API endpoints in certain standardized formats. Thus, in this embodiment, the API system 134 may examine published code to find these definitions and use them to generate the set of existing APIs, descriptions, and parameters. As an example, prior to providing the user interface with API selection menu in block 302, API system 134 may automatically generate from one or more codebases (and/or other API database servers) a set of existing APIs, which may include the full set of existing APIs contained therein or a partial set thereof. Additionally, API system 134 may automatically generate or retrieve the full or partial set of descriptions and parameters associated with each generated API. Alternatively, the same mechanics may also be conducted concurrently and/or after providing the user interface to a user at block 302.
Thus, in some embodiments, blocks 302 or 304 may include functionality whereby an API system may extract, preliminarily or concurrently, information from one or more databases containing API information (e.g., a codebase, such as API database server 108, serving as a code repository). In some embodiments, each code repository, for example, may define API endpoints associated with the API code in the code repository.
Argued claim limitation does not disclose the association of retrieving source codes with API traffic, as the determining step does not clarify the mechanism of determine that the data traffic and the source code are associated with application programming interface (API) traffic as basis of determining is not in claim 1. Examiner recommend to clarify the mechanism of determining step.
Applicant further argued that Caudill does not disclose determine a first API associated with the API traffic.
Examiner respectfully disagrees.
Caudill discloses the information regarding each API may include the name of a service provided by the API, an API endpoint (e.g., an endpoint path, name, etc.), Caudill: Col. 13 lines 52-55).
Further discloses the API systems disclosed herein allow users to interact and analyze electronic data in a more analytically useful way. execution of the plurality of APIs in accordance with the execution structure, Caudill: Col. 7 lines 33-52, Col. 22 lines 5-19), and (the system determine what parameters, body, type, name, etc. are associated with the selected API For example, system may analyze the inputs and outputs for the selected API. In some embodiments, system analyzes the metadata associated with an API using, for example, a Java reflections protocol, Caudill: Col. 11 lines 1-29.
Thus, rejection of claim 1 is maintained.
Similar arguments applied to claims 12 and 20.
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-7, 11-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Caudill et al. (US 11467887 B1, hereinafter “Caudill”) in view of Roy et al. (US 10740164 B1, hereinafter “Roy”) and further in view of Zhang et al. (US 2016/0381070 A1).
Regarding claim 1, Caudill discloses a system for network traffic discovery and analysis, the system comprising (various aspects of an API database system and network environment, Caudill: Col. 3 lines 44-47): a non-transitory storage device (computer readable storage medium, Caudill: Col. 4 lines 30-31); and a processor coupled to the non-transitory storage device, wherein the processor is configured to (processor may retrieve and execute the instructions, Caudill: Col. 17 lines 36):
retrieve source code from code repositories (API endpoints associated with the API code in the code repository, Caudill: Col. 10 lines 10-11);
determine that the data traffic and the source code are associated with application programming interface (API) traffic (information regarding each API may include a description associated with an API, Caudill: Col. 6 lines 49-52);
determine a first API associated with the API traffic (information regarding each API may include the name of a service provided by the API, an API endpoint (e.g., an endpoint path, name, etc.), Caudill: Col. 13 lines 52-55)
Caudill does not explicitly disclose capture in real time, data traffic across network ports in a computing environment; determine, using a machine learning (ML) subsystem, whether the first API meets supervisory requirements; invoke a remediation protocol in an instance when the first API does not meet supervisory requirements.
In an analogous art, Roy teaches determine, using a machine learning (ML) subsystem, whether the first API meets supervisory requirements (performing security assessment for API using ML, Roy: Col. 5 lines 1-67); invoke a remediation protocol in an instance when the first API does not meet supervisory requirements (initiating remediation of API to resolve security assessment requirement automatically including remediation actions such as shut down API, auto-correct API, and increase rate limit blacklist IP for API call, Roy: Col. 17 lines 15-67, Col. 18 lines 1-6, Col. 19 lines 20-33, Col. 28 lines 1-33).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Caudill in view of Roy in order to further modify the method of using machine learning to initiate remediation of API based on security assessment requirement result by using machine learning from the teachings of Roy to improve the security, design, and performance of the API's (Roy: Col. 18 lines 34-36).
The combination of Caudill and Roy does not explicitly disclose capture, in real time, data traffic across network ports in a computing environment.
In an analogous art, Zhang discloses capture, in real time, data traffic across network ports in a computing environment (Paragraph 0036 discloses network security device 112 can be configured to process network traffic that has been captured and stored to a file or network security device 112 may be configured to receive and process traffic flowing through the network in real-time. According to one embodiment, network security device 112 can be configured to receive traffic files or logs representing network traffic that has been captured and saved by a network traffic capture system, for example. The traffic files or logs may include all traffic observed within an enterprise network)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Zhang to the modified system of Cauldill and Roy to provide the mechanism of network security by identifying suspicious network traffic based on the characteristics of the traffic (Paragraph 0003, Zhang).
Regarding claim 12, claim 12 comprises substantially similar limitations as claimed above in claim 1, a computer program product for network traffic discovery and analysis, the computer program product comprising a non-transitory computer-readable medium comprising code causing an apparatus to perform the steps as recited above in claim 1 (computer program product include a computer readable storage medium having computer readable program instructions, Caudill: Col. 15 lines 29-33).
Regarding claim 20, claim 20 comprises substantially similar limitations as claimed above in claim 1, Caudill discloses a method for network traffic discovery and analysis, the method comprising to perform the steps as claimed above in claim 1 (computer program product include a computer readable storage medium having computer readable program instructions, Caudill: Col. 15 lines 29-33).
Regarding claims 2 and 13, Caudill and Roy teach all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill discloses: wherein, in determining the first API associated with the API traffic, the processor is further configured to (receive input indicating a first API, Caudill: Col. 11 lines 1-3): determine a destination IP address from the API traffic (endpoint may include a network address of an API, Caudill: Col. 6 lines 65-67); map the destination IP address to a first end-point device (receives input from client device indicating a first API, Caudill: Col. 11 lines 1-3); and determine that the first end-point device is associated with the first API (client device indicating a first API, Caudill: Col. 11 lines 1-3).
Regarding claims 3 and 14, Caudill and Roy teach all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill discloses wherein the processor is further configured to: receive API-related data traffic associated with the one or more APIs, one or more supervisory requirements for the one or more APIs (communications with one or more API's may be encrypted and/or authenticated, Caudill: Col. 14 lines 61-63) generate a first feature set using the API-related data traffic associated with the one or more APIs (information may be generated by a machine learning algorithm, Caudill: Col. 7 lines 45-49) and train, using the ML subsystem, a first ML model using the first feature set (information may be generated by a machine learning algorithm, Caudill: Col. 7 lines 45-49).
Caudill does not explicitly disclose one or more indications of whether the one or more APIs meet the one or more supervisory requirements for the one or more APIs; the one or more supervisory requirements for the one or more APIs, and the one or more indications of whether the one or more APIs meet the one or more supervisory requirements for the one or more APIs.
In an analogous art, Roy discloses one or more indications of whether the one or more APIs meet the one or more supervisory requirements for the one or more APIs (performing security assessment for API using ML, Roy: Col. 5 lines 1-67); the one or more supervisory requirements for the one or more APIs, and the one or more indications of whether the one or more APIs meet the one or more supervisory requirements for the one or more APIs (initiating remediation of API to resolve security assessment requirement automatically including remediation actions such as shut down API, auto-correct API, and increase rate limit blacklist IP for API call, Roy: Col. 17 lines 15-67, Col. 18 lines 1-6, Col. 19 lines 20-33, Col. 28 lines 1-33).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Caudill in view of Roy in order to further modify the method of using machine learning to initiate remediation of API based on security assessment requirement result by using machine learning from the teachings of Roy to improve the security, design, and performance of the API's (Roy: Col. 18 lines 34-36).
Regarding claims 4 and 15, Caudill and Roy teach all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill discloses monitor API-related data traffic associated with the first API for a first time period (information regarding each API may include a description associated with an API, Caudill: Col. 6 lines 49-52, information regarding each API may include the name of a service provided by the API, an API endpoint (e.g., an endpoint path, name, etc.), Caudill: Col. 13 lines 52-55); and capture data metrics from with the API-related data traffic associated with the first API (stores a plurality of preconfigured APIs through the network, Caudill: Col. 5 lines 65-66)
Regarding claims 5 and 16, Caudill and Roy teach all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill discloses deploy, via the ML subsystem, a first trained ML model on the data metrics captured from with the API-related data traffic and the supervisory requirements associated with the first API (API system may be equipped with machine learning, Caudill: Col. 9 lines 32-35); determine, via the first trained ML model, a likelihood of adherence of the first API to the supervisory requirements (APIs may be filtered and presented based on a selection of one or more APIs, Caudill: Col. 9 lines 32-37).
Caudill does not explicitly disclose determine that the first API meets the supervisory requirements in an instance in which the likelihood of adherence of the first API to the supervisory requirements satisfies a security threshold.
In an analogous art, Roy discloses determine that the first API meets the supervisory requirements in an instance in which the likelihood of adherence of the first API to the supervisory requirements satisfies a security threshold (The risk profiler 150 may implement a second cognitive learning operation to identify a plurality of risk parameters associated with the security assessment requirement from the assessment data. The criteria may include identification of a threshold for each of the plurality of risk parameters to determine a probability of a risk occurrence, acceptability, and unacceptability of a risk parameter, a trigger event for a risk parameter, and the like. Roy: Col. 8 lines 36-60. Further discloses initiating remediation of API to resolve security assessment requirement automatically including remediation actions such as shut down API, auto-correct API, and increase rate limit blacklist IP for API call, Roy: Col. 17 lines 15-67, Col. 18 lines 1-6, Col. 19 lines 20-33, Col. 28 lines 1-33).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Caudill in view of Roy in order to further modify the method of using machine learning to initiate remediation of API based on security assessment requirement result by using machine learning from the teachings of Roy to improve the security, design, and performance of the API's (Roy: Col. 18 lines 34-36).
Regarding claims 6 and 17, Caudill and Roy teach all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill does not explicitly disclose determine that the first API does not meet the supervisory requirements in an instance in which the likelihood of adherence of the first API to the supervisory requirements does not satisfy the security threshold.
In an analogous art, Roy discloses determine that the first API does not meet the supervisory requirements in an instance in which the likelihood of adherence of the first API to the supervisory requirements does not satisfy the security threshold (The risk profiler 150 may implement a second cognitive learning operation to identify a plurality of risk parameters associated with the security assessment requirement from the assessment data. The criteria may include identification of a threshold for each of the plurality of risk parameters to determine a probability of a risk occurrence, acceptability, and unacceptability of a risk parameter, a trigger event for a risk parameter, and the like. Roy: Col. 8 lines 36-60. Further discloses initiating remediation of API to resolve security assessment requirement automatically including remediation actions such as shut down API, auto-correct API, and increase rate limit blacklist IP for API call, Roy: Col. 17 lines 15-67, Col. 18 lines 1-6, Col. 19 lines 20-33, Col. 28 lines 1-33).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Caudill in view of Roy in order to further modify the method of using machine learning to initiate remediation of API based on security assessment requirement result by using machine learning from the teachings of Roy to improve the security, design, and performance of the API's (Roy: Col. 18 lines 34-36).
Regarding claims 7 and 18, Caudill and Roy teach all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill discloses wherein, in invoking the remediation protocol, the processor is further configured to execute a first set of remediation actions on the first API, wherein the first set of remediation actions (API system may require a uniquely encrypted token or identifier for authenticating a user's access to use or view certain APIs, Caudill: Col. 15 lines 2-5).
Caudill does not explicitly disclose when executed, ensure that the likelihood of adherence of the first API to the supervisory requirements satisfies the security threshold.
In an analogous art, Roy discloses when executed, ensure that the likelihood of adherence of the first API to the supervisory requirements satisfies the security threshold (The risk profiler 150 may implement a second cognitive learning operation to identify a plurality of risk parameters associated with the security assessment requirement from the assessment data. The criteria may include identification of a threshold for each of the plurality of risk parameters to determine a probability of a risk occurrence, acceptability, and unacceptability of a risk parameter, a trigger event for a risk parameter, and the like. Roy: Col. 8 lines 36-60. Further discloses initiating remediation of API to resolve security assessment requirement automatically including remediation actions such as shut down API, auto-correct API, and increase rate limit blacklist IP for API call, Roy: Col. 17 lines 15-67, Col. 18 lines 1-6, Col. 19 lines 20-33, Col. 28 lines 1-33).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Caudill in view of Roy in order to further modify the method of using machine learning to initiate remediation of API based on security assessment requirement result by using machine learning from the teachings of Roy to improve the security, design, and performance of the API's (Roy: Col. 18 lines 34-36).
Regarding claim 11, Caudill-Roy teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill discloses determine a second API associated with the API traffic; determine one or more end-point devices associated with the second API (determination that a user is not authorized to call a specific API or set of APIs may be made at an earlier stage, Caudill: Col. 15 lines 13-17); and transmit a notification to the one or more end-point devices, wherein the notification comprises a recommendation to use the first API instead of the second API (user may need to provide a token when selecting APIs to be included as part of the chained API composition, Caudill: Col. 15 lines 18-20).
Claims 8-10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Caudill et al. (US 11467887 B1, hereinafter “Caudill”) in view of Roy et al. (US 10740164 B1, hereinafter “Roy”) and further in view of Zhang et al. (US 2016/0381070 A1) and further in view of Ngo et al. (US 2020/0137103 A1).
Regarding claims 8 and 19, Caudill, Roy and Zhang teach all the claimed limitations as set forth in the rejection of claim 1 above.
Caudill discloses deploy, via the ML subsystem, a second trained ML model on the data metrics captured from with the API-related data traffic associated with the first API (API system may be equipped with machine learning, Caudill: Col. 9 lines 32-35. API system may access the mapping between the first and second APIs to determine inputs for the next API, Caudill: Col. 12 lines 52-56); determine, via the second trained ML model, a likelihood that the first API is affected (APIs may be filtered and presented based on a selection of one or more APIs, Caudill: Col. 9 lines 32-37).
Caudill and Roy do not explicitly disclose via the second trained ML model, a likelihood that the first API is affected by a first exposure vector; and determine that the first API is affected by the first exposure vector in an instance in which the likelihood that the first API is affected by a first exposure vector satisfies an exposure threshold.
In an analogous art, Ngo discloses via the second trained ML model, a likelihood that the first API is affected by a first exposure vector; and determine that the first API is affected by the first exposure vector in an instance in which the likelihood that the first API is affected by a first exposure vector satisfies an exposure threshold (Paragraphs 0038, 0042 disclose protect customer environments between the time a CVE is released and the time that the vendor is able to provide a patch to close the vulnerability. It does this by an intermediate measure that is derived by applying policy enforcement changes based on CVE data that is collected in near real time. The solution involves the use of natural language processing of CVE databases to evaluate the risk, scope and exploit vector of the CVE. This information is then used to automate changes inside a customer's computer resources to protect them (in an intermediate manner) from the exposure that this vulnerability presents. a combination of Common Vulnerability Exposure (CVE) data, Common Weakness Enumeration (CWE) data, Natural Language Processing (NLP), and/or customer profiles to quickly identify the potential security risk. The present invention then compiles a policy modification based on taxonomy suitable for the particular device model and version that is vulnerable to a malicious attack, and automatically enforces a protection rule on behalf of the customer. This remediation is then rolled back after fully-vetted (tested) patching has been applied and the exposure is no longer present).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Ngo to the modified system of Caudill, Roy and Zhang to provide invention relates to the field of identifying vulnerabilities to computer resources and providing an intermediate measure against potential malicious attacks until the vulnerabilities are resolved (Abstract, Ngo).
Regarding claim 9, Caudill, Roy and Zhang do not disclose invoke the remediation protocol in an instance when the first API is affected by the first exposure vector.
In an analogous art, Ngo discloses invoke the remediation protocol in an instance when the first API is affected by the first exposure vector (Paragraphs 0038, 0042 disclose the vulnerability of the computer system to the malicious attack is from a set of newly-identified vulnerabilities, and wherein the set of newly-identified vulnerabilities are identified in a Common Vulnerability Exposure (CVE) listing that is generated by a third party that monitors vulnerabilities for multiple computer systems).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Ngo to the modified system of Caudill, Roy and Zhang to provide invention relates to the field of identifying vulnerabilities to computer resources and providing an intermediate measure against potential malicious attacks until the vulnerabilities are resolved (Abstract, Ngo).
Regarding claim 10, Caudill, Roy and Zhang do not disclose wherein, in invoking the remediation protocol, the processor is further configured to execute a second set of remediation actions on the first API, wherein the second set of remediation actions, when executed, ensure that the likelihood that the first API is affected by a first exposure vector does not satisfy the exposure threshold.
In an analogous art, Ngo discloses wherein, in invoking the remediation protocol, the processor is further configured to execute a second set of remediation actions on the first API, wherein the second set of remediation actions, when executed, ensure that the likelihood that the first API is affected by a first exposure vector does not satisfy the exposure threshold. (Paragraphs 0038, 0042 disclose protect customer environments between the time a CVE is released and the time that the vendor is able to provide a patch to close the vulnerability. It does this by an intermediate measure that is derived by applying policy enforcement changes based on CVE data that is collected in near real time. The solution involves the use of natural language processing of CVE databases to evaluate the risk, scope and exploit vector of the CVE. This information is then used to automate changes inside a customer's computer resources to protect them (in an intermediate manner) from the exposure that this vulnerability presents. a combination of Common Vulnerability Exposure (CVE) data, Common Weakness Enumeration (CWE) data, Natural Language Processing (NLP), and/or customer profiles to quickly identify the potential security risk. The present invention then compiles a policy modification based on taxonomy suitable for the particular device model and version that is vulnerable to a malicious attack, and automatically enforces a protection rule on behalf of the customer. This remediation is then rolled back after fully-vetted (tested) patching has been applied and the exposure is no longer present).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Ngo to the modified system of Caudill, Roy and Zhang to provide invention relates to the field of identifying vulnerabilities to computer resources and providing an intermediate measure against potential malicious attacks until the vulnerabilities are resolved (Abstract, Ngo).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Banerjee (US 10810065 B1, hereinafter “Banerjee”) discloses automatically healing API including API version updates and modifications to message sequence, schema, payload extension, timeout value, etc., Banerjee: Col. 4 lines 41-67, Col. 5 lines 1-19.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROMANI OHRI whose telephone number is (571)272-5420. The examiner can normally be reached 8: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, UN C CHO can be reached at 5712727919. 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.
/ROMANI OHRI/Primary Examiner, Art Unit 2413