Detailed Action
1. This communication is in response to application 18/356,665 filed on March 10, 2026 in which claims 1-20 are pending in this application. Claims 1, 9, and 15 are independent claims.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
3. This Final Office Action is in response to the applicant’s remarks and arguments filed on March 10, 2026.
Claims 1, 8-9, and 15 are amended. No claims have been cancelled. No claims are new. Claims 1-20 remain pending in the application. Claims 2-7, 10-14, and 16-20 filed on July 21, 2023 are being considered on the merits along with amended claims 1, 8-9, and 15.
Response to Arguments
4. Applicant’s arguments, see Remarks pages 8-13, filed March 10, 2026, with respect to the rejections of claims 1-20 under 35 U.S.C. 112 and 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new grounds of rejection are made over Lehmann in view of Brown and Mandal under 35 U.S.C. 103 regarding claims 1-20.
On page 8 of the Remarks, the Applicant states under the Interview Summary section that the Examiner “agreed that the proposed amendment would overcome the art of record, but an updated search would be needed. No agreement as to allowability was reached.”
The Examiner agrees with the Applicant and since the Interview has completed an updated search. In this search and review of prior art documents, the Examiner has updated the 103 rejection for the independent claims to include Mandal which discloses the amendment of “determining if the first contents and the second contents of the memory differ based on comparing the first contents and the second contents read from the memory allocated to the WebAssembly instance.”
On page 8 of the Remarks, the Applicant states under the Specification Objections section that the Applicant has amended the Abstract to have a total length of 150 words.
The Examiner agrees with the Applicant’s assertion that the amendment no longer places the Abstract in an improper state. The Examiner has withdrawn the Specification Objection.
On pages 8-9 of the Remarks, the Applicant states under the 112 Rejection of the Claims section that “absence of a specific entity recited in claim 1 that performs the recited elements thus does not render the metes and bounds of the claim unclear” regarding claim 1.
The Examiner agrees with the Applicant’s assertion that the 112 rejection regarding claim 1 should be withdrawn and has done so.
On pages 8-9 of the Remarks, the Applicant states under the 112 Rejection of the Claims section that claim 8’s amendment should overcome the 112 rejection previously submitted by the Examiner.
The Examiner agrees with the Applicant’s assertion that the 112 rejection regarding claim 8 should be withdrawn and has done so. The amendment to include “injecting one or more code units into a process associated with the web browser” has clarified what is injected into the process.
On pages 9-12 of the Remarks, the Applicant states under the 103 Rejection of the Claims section that “Lehmann/Brown fails to disclose or imply determining if first and second contents read from memory allocated to a WebAssembly instance differ based on comparing the first and second contents.” The Applicant also suggests that the Examiner must provide obviousness authority under 35 U.S.C. 103.
The Examiner agrees with the Applicant’s assertion that the 103 rejection of the independent claims via Lehmann in view of Brown fails to disclose or imply determining if first and second contents read from memory allocated to a WebAssembly instance differ based on comparing the first and second contents. Thus, the Examiner has withdrawn the rejection via Lehmann in view of Brown and has introduced Mandal. Mandal discloses determining if the first contents and the second contents of the memory differ based on comparing the first contents and the second contents read from the memory allocated to the WebAssembly instance via the citation to paragraph ([0080] “In block 412, the web exploit detection engine performs exploit detection. This may include, for example, observing the behavior of the hooked API calls, and in some examples, logging that behavior. When the behavior of the API calls is hooked and logged, it can then be compared to known malware models. For example, the logged actions may be compared to a standard malware model that performs standard malware processes such as deobfuscation, preparing the memory layout, triggering the browser vulnerability, and transferring program control. If one or more of these behaviors is observed, then the executing JavaScript code may be detected as malicious.” The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the logged behavior saved in memory can be compared to the standard behavior saved in memory to determine if the contents differ and thus that exploitative behavior is determined. As such, Mandal discloses the amendment to the independent claims. Also, the Examiner in section 5 below describes the obviousness behind the combination of references Lehmann, Brown, and Mandal. Specifically, Mandal’s combination with Lehmann to disclose determining if the first contents and the second contents of the memory differ based on comparing the first contents and the second contents read from the memory allocated to the WebAssembly instance is based on the use of a known technique to improve similar devices in the same way such that WebAssembly instances that are monitoring exploits are able to compare memory contents between what they should be and what their result is so that they can determine exploits are occurring. As such, independent claims 1, 9, and 15 remain rejected despite their amendments and finally, this Office Action is final, so claims 1-20 remain rejected under 35 U.S.C. 103.
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.
5. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lehmann et al. (Wasabi: A Framework for Dynamically Analyzing WebAssembly NPL) – hereinafter “Lehmann”, in view of Brown et al. (U.S. Pub. No. 2018/0018460) – hereinafter “Brown” and Mandal (U.S. Pub. No. 2021/0097174).
Regarding independent claim 1, Lehmann discloses:
A method comprising:
installing a plurality of code hooks for a corresponding plurality of functions of an application programming interface (API) of a WebAssembly engine for a web browser; (Section 2.3 Analysis API “Wasabi offers analysis authors an API with hooks to be implemented by the analysis. The API is both powerful enough to enable arbitrary dynamic analyses and high-level enough to spare the analysis author dealing with irrelevant details. Table 2 shows the hooks, along with their arguments and types. The hooks can be roughly clustered into six groups: Instructions related to stack manipulation (const, drop, select), operations (unary, binary), accesses and management of variables and memory (local, global, load, store, memory grow), function calls (call_pre, call_post, return), control flow (br, br_if, br_table), and blocks (begin, end). Each hook implementation receives details about the respective instruction, e.g., its inputs and outputs, as well as the code location of the instruction.” and Table 2) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, Wasabi is a general-purpose framework for dynamically analyzing WebAssembly and as such, has hooks installed via an API for functions.
based on invocation of a first function of the plurality of functions, determining an address of memory allocated for a WebAssembly instance and recording first contents read from the memory … (Section 2.3 Analysis API “The API gives analysis authors the power to implement sophisticated dynamic analyses with little effort. In particular, it is straightforward to implement memory shadowing [34, 53], a feature useful, e.g.,. for tracking the origin of undesired values or for taint analysis. To associate some meta-information with a memory value, all an analysis must do is to maintain a map of memory locations to meta-information, and to update the meta-information on memory-related instructions. One of our example analyses (Section 4.2) is a taint analysis that implements memory shadowing in this way.” and Section 4.2 Ease of Implementing Analyses “Memory Access Tracing - The analysis tracks all memory accesses and stores them for a later off-line analysis, e.g., to detect cache-unfriendly access patterns.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the memory accesses are tracked and maintains meta-information regarding the memory address and its contents.
based on invocation of a second function of the plurality of functions, reading second contents from the memory allocated to the WebAssembly instance; (Table 3 and Section 2.4.1 Instrumentation of Instructions “To keep track of all instructions that occur during the execution, Wasabi inserts for each instruction a call to an analysis hook. Table 3 illustrates the instrumentation for a subset of all instructions. Row 1 shows the simplest case: a const instruction that pushes an immediate value on the stack. The instrumentation adds a call to the corresponding hook. Since the hook receives the value produced by the const instruction as an argument, the value is pushed once more on the stack prior to the call. After the call to the hook, the stack will be the same as in the original, uninstrumented program. Row 2 of Table 3 shows an instruction that takes inputs and produces results. To pass both to the inserted hook call, we need to duplicate values on the stack. For this purpose, Wasabi generates a fresh local of the appropriate type and writes the current stack top to this local with tee_local. Before the hook call, the inserted code retrieves the stored input and its result with get_local.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the next function triggers reading contents from memory.
based on determining that the first contents and the second contents differ, determining that the web browser has been exploited. (Section 4.2 Ease of Implementing Analyses “Taint Analysis - The analysis associates a taint with every value and tracks how taints propagate through instructions, function calls, and memory accesses, to detect illegal flows from sources to sinks.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the taint analysis tracks how taints propagate through instructions, function calls, and memory accesses to detect web browser exploits.
Lehmann does not explicitly disclose:
… wherein the memory has read-write-execute permissions;
determining if the first contents and the second contents of the memory differ based on comparing the first contents and the second contents read from the memory allocated to the WebAssembly instance;
However, Brown discloses:
… wherein the memory has read-write-execute permissions; ([0086] “D. A method as any one of paragraphs A-C recites, the determining that the AoI includes the security exploit is based at least in part on one or more of: determining that the return address is outside memory previously allocated for an object; determining that the object identifier is associated with a vulnerable object; determining that permissions of the memory region include two or more of read, write, and execute; or determining that the memory region is one page in length.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the memory of the security exploit has read-write-execute permissions.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the memory has read-write-execute permissions as seen in Brown's invention into Lehmann's invention because these modifications allow simple substitution of one known element for another to obtain the predictable results of memory having full permissions rather than potentially limited abilities in the context of read-write-execute.
Additionally, Mandal discloses:
determining if the first contents and the second contents of the memory differ based on comparing the first contents and the second contents read from the memory allocated to the WebAssembly instance; ([0080] “In block 412, the web exploit detection engine performs exploit detection. This may include, for example, observing the behavior of the hooked API calls, and in some examples, logging that behavior. When the behavior of the API calls is hooked and logged, it can then be compared to known malware models. For example, the logged actions may be compared to a standard malware model that performs standard malware processes such as deobfuscation, preparing the memory layout, triggering the browser vulnerability, and transferring program control. If one or more of these behaviors is observed, then the executing JavaScript code may be detected as malicious.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the logged behavior saved in memory can be compared to the standard behavior saved in memory to determine if the contents differ and thus that exploitative behavior is determined.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add determining if the first contents and the second contents of the memory differ based on comparing the first contents and the second contents read from the memory allocated to the WebAssembly instance as seen in Mandal’s invention into Lehmann's invention because these modifications allow the use of a known technique to improve similar devices in the same way such that WebAssembly instances that are monitoring exploits are able to compare memory contents between what they should be and what their result is so that they can determine exploits are occurring.
Regarding claim 2, Lehmann discloses the method of claim 2, wherein the first function is a function of the API for creating WebAssembly instances, wherein installing the plurality of code hooks comprises installing a first of the plurality of code hooks into the first function of the API. (Section 2.3 Analysis API “The API gives analysis authors the power to implement sophisticated dynamic analyses with little effort. In particular, it is straightforward to implement memory shadowing [34, 53], a feature useful, e.g.,. for tracking the origin of undesired values or for taint analysis. To associate some meta-information with a memory value, all an analysis must do is to maintain a map of memory locations to meta-information, and to update the meta-information on memory-related instructions. One of our example analyses (Section 4.2) is a taint analysis that implements memory shadowing in this way.” and Section 4.2 Ease of Implementing Analyses “Memory Access Tracing - The analysis tracks all memory accesses and stores them for a later off-line analysis, e.g., to detect cache-unfriendly access patterns.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, Wasabi is a general-purpose framework for dynamically analyzing WebAssembly and as such, has hooks installed via an API for functions.
Regarding claim 3, Lehmann discloses the method of claim 2, wherein determining the address of memory comprises determining the address of memory based on a return value of the first function. (Section 2.2 Mini-Wasm “Many WebAssembly instructions are polymorphic in the sense that the input and result types vary depending on the context in which the instruction is executed. For example, call and return pop and push different types depending on the function type of the called and current function, respectively. Similarly, the instruction types for accesses to locals and globals depend on the referenced local and global variable.” and Section 4.2 Ease of Implementing Analyses “Memory Access Tracing - The analysis tracks all memory accesses and stores them for a later off-line analysis, e.g., to detect cache-unfriendly access patterns.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the memory accesses from return instructions include the address of the memory with which the instruction/function is executed.
Regarding claim 4, Lehmann discloses the method of claim 1, wherein the second function is a function of the API invoked based on calling exported functions of WebAssembly instances, wherein installing the plurality of code hooks comprises installing a second of the plurality of code hooks into the second function of the API. (Section 2.2 Mini-Wasm “For a self-contained and concise presentation, we now introduce Mini-Wasm, a simplified core of WebAssembly. The Wasabi implementation supports the entire WebAssembly language. Figure 3 shows the grammar of Mini-Wasm modules. A module corresponds to a single binary file and contains functions, global variables, an optional start function, and at most one table and memory. Each of these have a name only when they are imported or exported, and otherwise are referenced by integer indices.” and Section 2.3 Analysis API “Wasabi offers analysis authors an API with hooks to be implemented by the analysis. The API is both powerful enough to enable arbitrary dynamic analyses and high-level enough to spare the analysis author dealing with irrelevant details. Table 2 shows the hooks, along with their arguments and types. The hooks can be roughly clustered into six groups: Instructions related to stack manipulation (const, drop, select), operations (unary, binary), accesses and management of variables and memory (local, global, load, store, memory grow), function calls (call_pre, call_post, return), control flow (br, br_if, br_table), and blocks (begin, end). Each hook implementation receives details about the respective instruction, e.g., its inputs and outputs, as well as the code location of the instruction.” and Table 2) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the second function triggers code hooks installed via the API based on functions being called that are outbound.
Regarding claim 5, Lehmann discloses the method of claim 1, wherein installing the plurality of code hooks comprises installing a third of the plurality of code hooks into a third function of the API, wherein the third function is a function of the API for permissibly modifying contents of the memory. (Section 2.3 Analysis API “Wasabi offers analysis authors an API with hooks to be implemented by the analysis. The API is both powerful enough to enable arbitrary dynamic analyses and high-level enough to spare the analysis author dealing with irrelevant details. Table 2 shows the hooks, along with their arguments and types. The hooks can be roughly clustered into six groups: Instructions related to stack manipulation (const, drop, select), operations (unary, binary), accesses and management of variables and memory (local, global, load, store, memory grow), function calls (call_pre, call_post, return), control flow (br, br_if, br_table), and blocks (begin, end). Each hook implementation receives details about the respective instruction, e.g., its inputs and outputs, as well as the code location of the instruction.” and Table 2 and Section 4.2 Ease of Implementing Analyses “Memory Access Tracing - The analysis tracks all memory accesses and stores them for a later off-line analysis, e.g., to detect cache-unfriendly access patterns.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, Wasabi is a general-purpose framework for dynamically analyzing WebAssembly and as such, has hooks installed via an API for functions such as memory functions that access and manage variables/memory.
Regarding claim 6, Lehmann discloses the method of claim 5, further comprising based on invocation of the third function, reading third contents from the memory and updating the first contents recorded for the memory based on the third contents. (Section 2.3 Analysis API “Wasabi offers analysis authors an API with hooks to be implemented by the analysis. The API is both powerful enough to enable arbitrary dynamic analyses and high-level enough to spare the analysis author dealing with irrelevant details. Table 2 shows the hooks, along with their arguments and types. The hooks can be roughly clustered into six groups: Instructions related to stack manipulation (const, drop, select), operations (unary, binary), accesses and management of variables and memory (local, global, load, store, memory grow), function calls (call_pre, call_post, return), control flow (br, br_if, br_table), and blocks (begin, end). Each hook implementation receives details about the respective instruction, e.g., its inputs and outputs, as well as the code location of the instruction.” and Table 2 and Section 4.2 Ease of Implementing Analyses “Memory Access Tracing - The analysis tracks all memory accesses and stores them for a later off-line analysis, e.g., to detect cache-unfriendly access patterns.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the memory accesses are tracked and maintains meta-information regarding the memory address and its contents. Additionally, the memory content can be updated based on hooks with accesses and management of variables/memory in mind.
Regarding claim 7, Lehmann discloses the method of claim 1, wherein recording the first contents read from memory comprises storing an association between the address of the memory and the first contents in a data structure. (Section 2.3 Analysis API “The API gives analysis authors the power to implement sophisticated dynamic analyses with little effort. In particular, it is straightforward to implement memory shadowing [34, 53], a feature useful, e.g., for tracking the origin of undesired values or for taint analysis. To associate some meta-information with a memory value, all an analysis must do is to maintain a map of memory locations to meta-information, and to update the meta-information on memory-related instructions. One of our example analyses (Section 4.2) is a taint analysis that implements memory shadowing in this way.” and Section 4.2 Ease of Implementing Analyses “Memory Access Tracing - The analysis tracks all memory accesses and stores them for a later off-line analysis, e.g., to detect cache-unfriendly access patterns.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the memory locations are mapped to meta-information and updated based on memory-related instructions so the content of the memory and its address are associated in the mapping.
Regarding claim 8, Lehmann discloses the method of claim 1, but does not explicitly disclose:
further comprising injecting one or more code units into a process associated with the web browser, wherein installing the plurality of code hooks is based on injecting the one or more code units into the process.
However, Mandal discloses:
further comprising injecting one or more code units into a process associated with the web browser, wherein installing the plurality of code hooks is based on injecting the one or more code units into the process. ([0077-0078] “FIG. 4 is a flowchart of a method 400 of performing browser exploit mitigation. The method of FIG. 4 may be performed, for example, by a web exploit detection engine, such as exploit detection plugin 324 of FIG. 3, or via JavaScript injected by exploit detection engine 224 of FIG. 2. Starting at block 404, the exploit detection engine installs built-in JavaScript API hooks. This may be done, for example, by installing the JavaScript code at the top or near the top of the webpage, to ensure that the API calls are hooked in other JavaScript code.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the JavaScript injection installs built-in JavaScript API hooks associated with the web browser.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add further comprising injecting one or more code units into a process associated with the web browser, wherein installing the plurality of code hooks is based on injecting the one or more code units into the process as seen in Mandal’s invention into Lehmann's invention because these modifications allow use of a known technique to improve a similar method in the same way such that the installation of code hooks via injection into the process allows another option for code hooks to be installed.
Regarding claim 9, it is a non-transitory machine-readable media claim having the same limitations as cited in method claim 1. Thus, claim 9 is also rejected under the same rationale as addressed in the rejection of claim 1 above.
Regarding claim 10, it is a non-transitory machine-readable media claim having the same limitations as cited in method claim 7. Thus, claim 10 is also rejected under the same rationale as addressed in the rejection of claim 7 above.
Regarding claim 11, it is a non-transitory machine-readable media claim having the same limitations as cited in method claim 5. Thus, claim 11 is also rejected under the same rationale as addressed in the rejection of claim 5 above.
Regarding claim 12, it is a non-transitory machine-readable media claim having the same limitations as cited in method claim 6. Thus, claim 12 is also rejected under the same rationale as addressed in the rejection of claim 6 above.
Regarding claim 13, it is a non-transitory machine-readable media claim having the same limitations as cited in method claims 2 and 3. Thus, claim 13 is also rejected under the same rationale as addressed in the rejection of claims 2 and 3 above.
Regarding claim 14, it is a non-transitory machine-readable media claim having the same limitations as cited in method claim 4. Thus, claim 14 is also rejected under the same rationale as addressed in the rejection of claim 4 above.
Regarding claim 15, it is an apparatus claim having the same limitations as cited in method claim 1. Thus, claim 15 is also rejected under the same rationale as addressed in the rejection of claim 1 above.
Regarding claim 16, it is an apparatus claim having the same limitations as cited in method claim 5. Thus, claim 16 is also rejected under the same rationale as addressed in the rejection of claim 5 above.
Regarding claim 17, it is an apparatus claim having the same limitations as cited in method claim 7. Thus, claim 17 is also rejected under the same rationale as addressed in the rejection of claim 7 above.
Regarding claim 18, it is an apparatus claim having the same limitations as cited in method claims 2 and 3. Thus, claim 18 is also rejected under the same rationale as addressed in the rejection of claims 2 and 3 above.
Regarding claim 19, it is an apparatus claim having the same limitations as cited in method claim 4. Thus, claim 19 is also rejected under the same rationale as addressed in the rejection of claim 4 above.
Regarding claim 20, it is an apparatus claim having the same limitations as cited in method claim 8. Thus, claim 20 is also rejected under the same rationale as addressed in the rejection of claim 8 above.
Conclusion
6. 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art includes Giuliani et al. (U.S. Patent No. 10,284,591) and Qu et al. (U.S. Pub. No. 2018/0285564) and Muttik (WO 2015094189). Giuliani discloses monitoring a memory space for exploits based on function execution such as executing non-executable memory and invalid return addresses. Qu discloses an exploit for a memory allocation vulnerability such that memory and its contents are tracked to determine the success of the exploit. Muttik discloses comparing the memory address of conflicting data with the memory addresses of the monitored memory regions to determine whether the monitored memory regions have been accessed, and thus potentially exploited.
Qu specifically is a useful piece of prior art for the amendment to the independent claims such that it teaches “determining if the first contents and the second contents of the memory differ based on comparing the first contents and the second contents read from the memory allocated to the WebAssembly instance” in combination with Lehmann similar to Mandel.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety 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.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B TRAINOR whose telephone number is (571)272-3710. The examiner can normally be reached Monday-Friday 9AM-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, Pierre Vital can be reached at (571) 272-4215. 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.
/D.T./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights