Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 11-13, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Keidar-Barner (US 8,683,441 B2) in view of Li (US 8,595,701 B2), and further in view of Keller (US 7,792,117 B1).
Regarding Claim 1, Keidar-Barner (US 8,683,441) teaches
A computer program product for verifying functionality of a hardware pipeline, the computer program product comprising a computer readable storage medium having computer readable program code embodied therein that is executable to perform operations, the operations comprising:
performing symbolic execution of a software model comprising executable code to produce first symbolic output (Abstract, “Two programs are checked for equivalence. Based on concrete states, a control path in each program is determined. A symbolic representation of the output is determined for each program and verified that for every input that would execute the programs on the determined control paths, the outputs are the same.”) Examiner Comments: Keidar-Barner teaches performing symbolic execution of a first program (software model comprising executable code) to produce a symbolic representation of output (first symbolic output) on control paths (execution paths).
performing symbolic execution of a reference software implementation of processing rules implemented in the hardware pipeline to produce second symbolic output (Col. 1, ln 35-50, “The original and modified versions of the program may be checked for equivalence. In some cases, such as in case of code styling, the programs should be completely equivalent (i.e., for every input provide the same output and intermediate values). In other cases, on most inputs the two programs should provide the same outputs.”) Examiner Comments: Keidar-Barner teaches performing symbolic execution of a second program (reference software implementation) that implements the same processing functionality to produce a second symbolic output for comparison.
comparing the first symbolic output and the second symbolic output to determine a discrepancy between the first and the second symbolic outputs (Abstract, “Two programs are checked for equivalence. Based on concrete states, a control path in each program is determined. A symbolic representation of the output is determined for each program and verified that for every input that would execute the programs on the determined control paths, the outputs are the same.”) Examiner Comments: Keidar-Barner explicitly teaches comparing symbolic outputs from both programs to determine whether they produce the same outputs, which reads on comparing to determine a discrepancy.
reporting the discrepancy including report information on a cause of the discrepancy (Col. 1, ln 35-50, “Identifying inputs for which different outputs are produced may be useful in determining whether bugs were introduced to the program when the program was modified.”) Examiner Comments: Keidar-Barner teaches that when discrepancies are found, the system identifies the specific inputs and control paths that caused the differing outputs, which constitutes reporting discrepancy information including cause information.
Keidar-Barner did not specifically teach
that the software model comprises executable code defining logic of the hardware pipeline
wherein the hardware pipeline is defined according to a hardware description language describing how the hardware pipeline is configured and programmed.
However, Li (US 8,595,701) teaches
performing symbolic execution of a software model comprising executable code defining logic of the hardware pipeline to produce first symbolic output (Col. 1, ln 30-37, “Particular embodiments provide a symbolic execution methodology for GPU programs. Instrumentation-based runtime tools cannot accept open inputs and generate test cases, and static-analysis-based tools suffer from false alarms and inefficiency. In contrast, particular embodiments use symbolic execution to implement a more accurate, efficient, and user-friendly validation tool and test generator for GPU programs.”; Col. 1, ln 63-67, “a GPU program along with a driver, is compiled into Low Level Virtual Machine (LLVM) bytecode, which CKLEE interprets for symbolic execution.”) Examiner Comments: Li teaches converting a hardware-targeted program (GPU program, which defines logic of a hardware pipeline) into an executable software model (LLVM bytecode) and performing symbolic execution of it to produce symbolic output, directly reading on the limitation of symbolically executing a software model of a hardware pipeline.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Keidar-Barner’s teaching of symbolic equivalence checking between two programs into Li’s teaching of symbolic execution of hardware-targeted programs in order to verify that a software model of a hardware pipeline correctly implements the same processing rules as a reference software implementation, since Li teaches that symbolic execution is particularly effective for validating hardware-targeted software including detecting bugs and generating test cases (Li, Col. 1, ln 30-67), and the combination would yield the predictable result of extending symbolic equivalence checking to the hardware pipeline verification domain.
Keidar-Barner and Li did not specifically teach
wherein the hardware pipeline is defined according to a hardware description language describing how the hardware pipeline is configured and programmed.
However, Keller (US 7,792,117) teaches
wherein the hardware pipeline is defined according to a hardware description language describing how the hardware pipeline is configured and programmed (Col. 6, ln 31-36, “The network packet processor is a pipeline 400 that includes a look-ahead stage 402, an operation stage 404, an insert/remove stage 406, and an interleave stage 408. Stages 402, 404, 406, and 408 of the pipeline 400 are configured by a textual language specification of the processing by the network packet processor.”; Col. 10, ln 12-18, “The processing of network packets by the pipeline may be specified in a textual language specification, and this specification may be analyzed to generate a specification of the pipeline in a hardware description language. Synthesis tools may generate a hardware implementation of the pipeline from the generated specification.”; Col. 11, ln 54-56, “At step 514, a specification of the look-ahead, operation, insert/remove, and interleave stages may be generated in a hardware description language.”) Examiner Comments: Keller teaches a network packet processor implemented as a hardware pipeline (pipeline 400) whose stages are configured and programmed according to a defining specification of the packet processing, and the pipeline is defined in a hardware description language specification of the pipeline stages, from which synthesis tools generate the hardware implementation. Under the broadest reasonable interpretation consistent with the instant specification (see instant published specification at [0015], describing “a hardware description language (HDL) or other technique for describing how hardware is configured and programmed”), Keller’s pipeline-defining specification and the hardware description language specification generated therefrom describe how the hardware pipeline is configured and programmed, directly reading on the claimed limitation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Keidar-Barner and Li’s teaching of symbolic equivalence checking and symbolic execution of software models of hardware pipelines into Keller’s teaching of a network packet processing hardware pipeline that is defined according to a hardware description language specification generated from a specification describing how the pipeline stages are configured and programmed, and that is translated into an executable software simulator of the pipeline, in order to verify, before hardware synthesis, that a hardware pipeline defined in a hardware description language correctly implements its packet processing rules, since Keller teaches that generating the pipeline implementation and its executable simulator from the same defining specification permits deficiencies discovered in an initial implementation to be addressed by modifying the specification and generating an improved implementation (Keller, Col. 1, ln 35-42).
Regarding Claim 2, Keidar-Barner, Li, and Keller teach
The computer program product of Claim 1.
Keidar-Barner further teaches
wherein the report information includes information on an execution path that resulted in the discrepancy (Col. 1, ln 35-50, “Identifying inputs for which different outputs are produced may be useful in determining whether bugs were introduced to the program when the program was modified.”; Col. 6, ln 48-58: the system identifies the specific pair of control paths on which the two programs produce different outputs) Examiner Comments: Keidar-Barner teaches identifying the specific control paths (execution paths) where the discrepancy occurred, reading on reporting execution path information.
Li further teaches visually highlights execution paths at which the discrepancy occurred in a computer user interface (Col. 2, ln 1-17, “Another output is the test cases, which may be replayed to produce coverage information... CKLEE may in particular embodiments detect bugs, such as data races, incorrectly synchronized barriers, and property violation for open inputs, as well as produce high-quality inputs that can be used to test the kernels in real settings.”) Examiner Comments: Li teaches outputting coverage information and bug detection results in a manner that identifies where bugs occur, and it would have been obvious to visually highlight discrepant execution paths in a user interface since this is a standard debugging visualization technique well-known in the art.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Keidar-Barner’s teaching of symbolic equivalence checking between two programs into Li’s teaching of symbolic execution of hardware-targeted programs in order to verify that a software model of a hardware pipeline correctly implements the same processing rules as a reference software implementation, since Li teaches that symbolic execution is particularly effective for validating hardware-targeted software including detecting bugs and generating test cases (Li, Col. 1, ln 30-67), and the combination would yield the predictable result of extending symbolic equivalence checking to the hardware pipeline verification domain.
Regarding Claim 3, Keidar-Barner, Li, and Keller teach
The computer program product of Claim 1.
Keidar-Barner and Li did not specifically teach converting a coding of the hardware pipeline in the hardware description language into the software model comprising executable code defining logic of the hardware pipeline.
However, Keller further teaches
converting a coding of the hardware pipeline in the hardware description language into the software model comprising executable code defining logic of the hardware pipeline (Col. 3, ln 26-30, “Execution of the instructions of the optional software module 112 may cause processor 102 to translate the specification of the network packet processor into a simulator in a general purpose programming language and to simulate the network packet processor using the simulator.”; Col. 12, ln 2-3, “At step 604, the specification is translated into a simulator of the network packet processor.”) Examiner Comments: Keller teaches translating the specification that defines the hardware pipeline and describes how its stages are configured and programmed (the coding of the hardware pipeline in the hardware description language, under the broadest reasonable interpretation set forth in the rejection of Claim 1) into a simulator in a general-purpose programming language, i.e., an executable software model that defines and simulates the logic of the hardware pipeline, directly reading on the claimed conversion step.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Keidar-Barner and Li’s teaching of symbolic equivalence checking and symbolic execution of software models of hardware pipelines into Keller’s teaching of a network packet processing hardware pipeline that is defined according to a hardware description language specification generated from a specification describing how the pipeline stages are configured and programmed, and that is translated into an executable software simulator of the pipeline, in order to verify, before hardware synthesis, that a hardware pipeline defined in a hardware description language correctly implements its packet processing rules, since Keller teaches that generating the pipeline implementation and its executable simulator from the same defining specification permits deficiencies discovered in an initial implementation to be addressed by modifying the specification and generating an improved implementation (Keller, Col. 1, ln 35-42), and the combination would yield the predictable result of applying symbolic equivalence checking to software models of hardware pipelines defined according to a hardware description language.
Regarding Claim 4, Keidar-Barner, Li, and Keller teach
The computer program product of Claim 1.
Keidar-Barner further teaches
wherein the performing the symbolic execution of the software model comprises providing symbolic input information to the software model, and wherein the performing the symbolic execution of the reference software implementation of the processing rules comprises providing the symbolic input information to the reference software implementation (Abstract, “Two programs are checked for equivalence. Based on concrete states, a control path in each program is determined. A symbolic representation of the output is determined for each program and verified that for every input that would execute the programs on the determined control paths, the outputs are the same.”; Col. 6, ln 48-58: the system uses a representative input to determine control paths in both programs for equivalence comparison) Examiner Comments: Keidar-Barner teaches providing the same input (symbolic input information) to both programs (the software model and the reference implementation) and comparing symbolic outputs on the resulting execution paths, directly satisfying this limitation.
Regarding Claim 5, Keidar-Barner, Li, and Keller teach
The computer program product of Claim 1.
Keidar-Barner further teaches
generating test input comprising values in response to determining the discrepancy (Col. 5, ln 30-45, “the representative generator 215 may try to determine a satisfying assignment to a formula defined by the symbolic formula definer 220. A satisfying solution may be determined by a solver, such as a SAT solver 215.”) Examiner Comments: Keidar-Barner teaches generating concrete representative inputs (test input with values) using a SAT solver based on the symbolic formulas that identified the discrepancy.
inputting the test input to the software model to produce first test output (Col. 6, ln 48-58: Keidar-Barner discloses executing the first program with the concrete representative input to produce output for comparison) Examiner Comments: Keidar-Barner teaches running the first program with concrete test values to produce a first concrete output.
inputting the test input to the reference software implementation of the processing rules to produce second test output (Col. 6, ln 48-58: Keidar-Barner discloses executing the second program with the same concrete representative input to produce corresponding output) Examiner Comments: Keidar-Barner teaches running the second program with the same concrete test values to produce a second concrete output.
generating output indicating a test discrepancy between the first test output and the second test output and information on an execution path which resulted in the test discrepancy (Col. 1, ln 35-50, “Identifying inputs for which different outputs are produced may be useful in determining whether bugs were introduced to the program when the program was modified.”) Examiner Comments: Keidar-Barner teaches comparing the concrete test outputs of both programs and identifying discrepancies along with the specific control paths (execution paths) where the discrepancy occurred.
Regarding Claim 11, Claim 11 recites a system claim that is substantially similar in scope to the computer program product of Claim 1.
Regarding Claim 12, Claim 12 is substantially similar in scope to Claim 4 and is rejected for the same reasons.
Regarding Claim 13, Claim 13 is substantially similar in scope to Claim 5 and is rejected for the same reasons.
Regarding Claim 16, Claim 16 recites a method claim that is substantially similar in scope to the computer program product of Claim 1.
Regarding Claim 17, Claim 17 is substantially similar in scope to Claim 4 and is rejected for the same reasons.
Regarding Claim 18, Claim 18 is substantially similar in scope to Claim 5 and is rejected for the same reasons.
Claims 6-10, 14, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Keidar-Barner (US 8,683,441 B2) in view of Li (US 8,595,701 B2) and Keller (US 7,792,117 B1), and further in view of Zuo (US 2013/0254766 A1).
Regarding Claim 6, Keidar-Barner, Li, and Keller teach
The computer program product of Claim 1.
Keidar-Barner, Li, and Keller did not specifically teach
wherein the hardware pipeline is implemented in a network interface card and implements network packet processing rules to process network packets, and wherein the reference software implementation implements the network packet processing rules.
However, Zuo (US 2013/0254766) teaches
wherein the hardware pipeline is implemented in a network interface card and implements network packet processing rules to process network packets (Abstract, “A host maintains rule set(s) for a virtual machine, and a physical network interface card (NIC) maintains flow table(s) for the virtual machine. The physical NIC receives and processes a network packet associated with the virtual machine. Processing the network packet includes the physical NIC comparing the network packet with the flow table(s) at the physical NIC. When the network packet matches with a flow in the flow table(s) at the physical NIC, the physical NIC performs an action on the network packet based on the matching flow.”) Examiner Comments: Zuo teaches a hardware pipeline implemented in a physical network interface card (NIC) that maintains flow tables (packet processing rules) and processes network packets by matching them against the flow tables and performing actions, directly reading on a hardware pipeline in a NIC implementing network packet processing rules.
wherein the reference software implementation implements the network packet processing rules (Abstract, “Alternatively, when the network packet does not match with a flow in the flow table(s) at the physical NIC, the physical NIC passes the network packet to the host partition for processing against the rule set(s).”; [0009], “a method for processing network packets for a virtual machine executing at the computer system includes a virtual switch maintaining one or more rule sets for a virtual machine and also maintaining one or more flow table tables for the virtual machine. The virtual switch offloads at least a portion of the one or more flow tables to the physical NIC. The virtual switch processes a network packet for the virtual machine. Processing the network packet includes the virtual switch receiving the network packet from one of the virtual machine or the physical NIC, and the virtual switch matching the network packet with a rule in the one or more rule sets. Based on matching the network packet with the rule, the virtual switch creates a flow in the one or more flow tables and offloads the flow to the physical NIC.”) Examiner Comments: Zuo teaches that the host partition maintains and processes packets against the same rule sets (reference software implementation of the network packet processing rules) that are also implemented in the NIC hardware, reading on a reference software implementation that implements the network packet processing rules.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Keidar-Barner, Li, and Keller’s teaching of symbolic equivalence checking and verification of hardware pipelines defined according to a hardware description language into Zuo’s teaching of a NIC hardware pipeline implementing packet processing rules with a corresponding host software implementation of the same rules, in order to apply the symbolic verification framework to the specific and practical domain of network interface card hardware pipelines, since Zuo teaches that both hardware (NIC flow tables) and software (host rule sets) implementations of the same packet processing rules coexist and must produce consistent results (Zuo, Abstract; [0009]), and using symbolic equivalence checking to verify consistency between these two implementations would yield the predictable benefit of ensuring correctness of NIC packet processing behavior.
Regarding Claim 7, Keidar-Barner, Li, Keller, and Zuo teach
The computer program product of Claim 6.
Zuo further teaches
wherein the performing the symbolic execution of the reference software implementation comprises performing symbolic execution of a software router that calls the reference software implementation of the network packet processing rules to apply the network packet processing rules ([0009], “a method for processing network packets for a virtual machine executing at the computer system includes a virtual switch maintaining one or more rule sets for a virtual machine and also maintaining one or more flow table tables for the virtual machine. The virtual switch offloads at least a portion of the one or more flow tables to the physical NIC. The virtual switch processes a network packet for the virtual machine. Processing the network packet includes the virtual switch receiving the network packet from one of the virtual machine or the physical NIC, and the virtual switch matching the network packet with a rule in the one or more rule sets. Based on matching the network packet with the rule, the virtual switch creates a flow in the one or more flow tables and offloads the flow to the physical NIC.”) Examiner Comments: Zuo teaches a virtual switch (software router) running on the host that routes network packets and applies (calls) the rule sets (reference software implementation of the network packet processing rules) to process the packets, directly reading on a software router that calls the reference software implementation to apply the network packet processing rules.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Keidar-Barner, Li, and Keller’s teaching of symbolic equivalence checking and verification of hardware pipelines defined according to a hardware description language into Zuo’s teaching of a NIC hardware pipeline implementing packet processing rules with a corresponding host software implementation of the same rules, in order to apply the symbolic verification framework to the specific and practical domain of network interface card hardware pipelines, since Zuo teaches that both hardware (NIC flow tables) and software (host rule sets) implementations of the same packet processing rules coexist and must produce consistent results (Zuo, Abstract; [0009]), and using symbolic equivalence checking to verify consistency between these two implementations would yield the predictable benefit of ensuring correctness of NIC packet processing behavior.
Regarding Claim 8, Keidar-Barner, Li, Keller, and Zuo teach The computer program product of Claim 6. Keidar-Barner further teaches
wherein the first symbolic output comprises first output symbolic packet information on output paths and the second symbolic output comprises second output symbolic packet information on the output paths (Abstract, “Two programs are checked for equivalence. Based on concrete states, a control path in each program is determined. A symbolic representation of the output is determined for each program and verified that for every input that would execute the programs on the determined control paths, the outputs are the same.”) Examiner Comments: Keidar-Barner teaches producing symbolic output representations on execution paths (output paths) for both programs; when applied to the network packet processing domain as taught by the combination, these symbolic outputs correspond to symbolic packet information on output paths.
Regarding Claim 9, Keidar-Barner, Li, Keller, and Zuo teach
The computer program product of Claim 8.
Keidar-Barner teaches
wherein the comparing the first symbolic output and the second symbolic output further comprises comparing information associated with the first output symbolic packet information and the second output symbolic packet information to determine the discrepancy (Abstract, “Two programs are checked for equivalence. Based on concrete states, a control path in each program is determined. A symbolic representation of the output is determined for each program and verified that for every input that would execute the programs on the determined control paths, the outputs are the same.”) Examiner Comments: Keidar-Barner teaches comparing all symbolic output variables produced by both programs on the determined paths to determine whether the outputs are the same, reading on comparing information associated with the first and second output symbolic packet information to determine the discrepancy.
Keidar-Barner did not specifically teach
that the compared information comprises routing decisions associated with the packet information.
However, Zuo further teaches
routing decisions associated with the first output symbolic packet information and the second output symbolic packet information (Abstract, “When the network packet matches with a flow in the flow table(s) at the physical NIC, the physical NIC performs an action on the network packet based on the matching flow.”) Examiner Comments: Zuo teaches that the processing of each network packet produces an action performed on the packet based on the matching flow (e.g., forwarding the packet or passing it to the host), which constitutes a routing decision associated with the packet information. In the combination, the symbolic outputs of the software model of the NIC hardware pipeline and of the reference software implementation each include the actions/routing decisions taken on the symbolic packets, such that Keidar-Barner’s comparison of the symbolic outputs compares the routing decisions associated with the first and the second output symbolic packet information to determine the discrepancy.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Keidar-Barner, Li, and Keller’s teaching of symbolic equivalence checking and verification of hardware pipelines defined according to a hardware description language into Zuo’s teaching of a NIC hardware pipeline implementing packet processing rules with a corresponding host software implementation of the same rules, in order to apply the symbolic verification framework to the specific and practical domain of network interface card hardware pipelines, since Zuo teaches that both hardware (NIC flow tables) and software (host rule sets) implementations of the same packet processing rules coexist and must produce consistent results (Zuo, Abstract; [0009]), and using symbolic equivalence checking to verify consistency between these two implementations would yield the predictable benefit of ensuring correctness of NIC packet processing behavior.
Regarding Claim 10, Keidar-Barner, Li, Keller, and Zuo teach The computer program product of Claim 8.
Keidar-Barner further teaches
providing symbolic network packet information having symbolic values as input information to the software model and the reference software implementation of the network packet processing rules, and wherein the first and the second output symbolic packet information comprises symbolic information resulting from possible execution paths in the network packet processing rules (Col. 5, ln 20-40: Keidar-Barner discloses providing the same symbolic input to both programs and iteratively processing pairs of control paths to verify equivalence for all possible inputs; Col. 4, ln 5-20: the system explores multiple control path pairs to ensure comprehensive coverage) Examiner Comments: Keidar-Barner teaches providing symbolic input to both programs and producing symbolic output across all explored execution paths; in the packet processing context of the combination, this reads on providing symbolic packet information as input and producing symbolic packet output from possible execution paths.
Regarding Claim 14, Claim 14 recites a system claim that is substantially similar in scope to Claim 6. Keidar-Barner, Li, Keller, and Zuo teach the limitations of Claim 14 for the same reasons as set forth in the rejection of Claim 6.
Regarding Claim 15, Claim 15 recites a system claim that is substantially similar in scope to Claim 8. Keidar-Barner, Li, Keller, and Zuo teach the limitations of Claim 15 for the same reasons as set forth in the rejection of Claim 8.
Regarding Claim 19, Claim 19 recites a method claim that is substantially similar in scope to Claim 6. Keidar-Barner, Li, Keller, and Zuo teach the limitations of Claim 19 for the same reasons as set forth in the rejection of Claim 6.
Regarding Claim 20, Claim 20 recites a method claim that is substantially similar in scope to Claim 8. Keidar-Barner, Li, Keller, and Zuo teach the limitations of Claim 20 for the same reasons as set forth in the rejection of Claim 8.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights