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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Specification
The disclosure is objected to because of the following informalities:
In paragraph [0070] line 3, reference to E1 and E2 should be deleted because these reference characters are not in FIG. 7.
In paragraphs [0072]-[0073], “chip data E3” should read “chip data D3” and “internal variable data E4” should read “internal variable data D4” because FIG. 7 labels them as such.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3, 10, and 17 contain the trademark/trade name V2LVS. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe Mentor Graphic’s Verilog netlist translation tool and, accordingly, the identification/description is indefinite.
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.
Claim(s) 1-2, 4-9, 11-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Integrating Design Information For IC Diagnosis” (1987-Concina) in view of “Exploiting Parallelism In VLSI CAD” (1986-Marantz)
With respect to claim 1, Concina teaches A method of verifying an integrated circuit, the method comprising (see FIG. 7, [page 256]):
obtaining first data defining elements in the integrated circuit, and second data defining positions and connection relationships of the elements (in FIG. 7, first data is the technology table and second data is the layout geometry, [page 256]);
generating chip data by merging the first data and the second data in background (in FIG. 7, see the two data sources being merged in the extractor, generating "extracted nets and devices", and teaching “in background” by "based on network isomorphisms alone", [page 256 col 1 paragraph 4 line 2], meaning not requiring additional user input, see (Specification [0029] lines 7-11) for interpretation of “in background”); ... and
generating output data, based on results of at least one of the physical verifications ("matched nets" and "matching errors" are output data of the comparator which is a physical verification),
wherein the performing of the plurality of physical verifications in parallel includes, extracting verification input data used for physical verification, based on the chip data (the output of the extractor step is "extracted nets and devices", which is used as input to the comparator step, and the comparator step is "layout-versus-schematic comparison", [page 256 col 1 paragraph 3 line 1]).
Concina does not specifically teach performing a plurality of physical verifications in parallel.
However, Marantz teaches performing a plurality of physical verifications in parallel (see Appendix A: EPIC/Dracula User Manual, “Parallel DRC is a method for running the ECAD's VLSI design rule checker (DRACULA). By dividing the run into portions to be run on several computers, Parallel separate DRC reduces the amount of time required for a DRC run, [page 77 paragraph 1 lines 1-3]).
It would have been obvious to one skilled in the art before the effective filing date to combine Concina with Marantz because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Concina discloses a system and method that teaches all of the claimed features except for executing physical verification tasks (such as DRC and LVS) in parallel. For physical verification, Concina describes using a “commercial package for design verification”, and then cites [14] and [15], (Concina [page 256 col 1 paragraphs 5-6]), which are Block NCC and Dracula III, (see Concina citations, [page 257]). Marantz teaches “parallelism is a cost-effective strategy for accelerating VLSI CAD tools” and then provides a list of criteria necessary to exploit parallelism:
The program must be partitioned into discrete tasks
Each task must be individually callable from the operating system
All communication between tasks must be done through disk files.
Unless different computers can share the same file system, the time it takes to execute an individual task must be greater than the time it takes to transfer the files that it reads and writes
(Marantz, [page 18 paragraph 3 bullets 1-4]). The rest of the thesis describes a method of accelerating the commercial design verification software package Dracula by exploiting said parallelism, showing that EPIC/parallel Dracula “offers a significant performance enhancement over serial DRACULA”, (Marantz [page 64 paragraph 5 lines 1-2]). A person having skill in the art would have a reasonable expectation of successfully accelerating design verification software of Concina by modifying Concina with the Epic/Parallel Dracula System of Marantz. Therefore, it would have been obvious to combine Concina with Marantz to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 2, Concina in view of Marantz teaches all of the limitations of claim 1, as noted above. Concina further teaches wherein each of the at least one of the physical verifications is based on at least one of design rule check (DRC), design for manufacturability (DFM), layout versus layout (LVL), layout versus schematic (LVS), and Verilog to LVS (V2LVS) (layout-versus-schematic comparison, [page 256 col 1 paragraph 3 line 1]).
With respect to claim 4, Concina in view of Marantz teaches all of the limitations of claim 1, as noted above. Concina does not teach receiving selection information; and selecting the at least one physical verification, based on the selection information.
However, Marantz teaches receiving selection information (externally divided into a finite set of tasks, [page 29 paragraph 2 lines 3]; and explicitly specify the tasks, [page 29 paragraph 2 line 6]- [page 30 paragraph 1 line 1]; see also FIG. 3.1 showing an example explicitly specified task list of DRC tasks, [page 30]); and selecting the at least one physical verification, based on the selection information (see FIG. 3.4, lines 4-5 of the example code, “read task description” and “append task description to task_list”), [page 35]; note these tasks could be an form of dependency execution, but in the context of this paper, they are specifically for running physical verification, “Digital Equipment Corporation's primary motivation for supporting this project was to produce a system that runs parallel ECAD DRCs, [page 24 paragraph 3 lines 1-2]).
It would have been obvious to one skilled in the art before the effective filing date to combine Concina with Marantz because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Concina discloses a system and method that teaches all of the claimed features except for executing physical verification tasks (such as DRC and LVS) in parallel. For physical verification, Concina describes using a “commercial package for design verification”, and then cites [14] and [15], (Concina [page 256 col 1 paragraphs 5-6]), which are Block NCC and Dracula III, (see Concina citations, [page 257]). Marantz teaches “parallelism is a cost-effective strategy for accelerating VLSI CAD tools” and then provides a list of criteria necessary to exploit parallelism:
The program must be partitioned into discrete tasks
Each task must be individually callable from the operating system
All communication between tasks must be done through disk files.
Unless different computers can share the same file system, the time it takes to execute an individual task must be greater than the time it takes to transfer the files that it reads and writes
(Marantz, [page 18 paragraph 3 bullets 1-4]). The rest of the thesis describes a method of accelerating the commercial design verification software package Dracula by exploiting said parallelism, showing that EPIC/parallel Dracula “offers a significant performance enhancement over serial DRACULA”, (Marantz [page 64 paragraph 5 lines 1-2]). A person having skill in the art would have a reasonable expectation of successfully accelerating design verification software of Concina by modifying Concina with the Epic/Parallel Dracula System of Marantz. Therefore, it would have been obvious to combine Concina with Marantz to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 5, Concina in view of Marantz teaches all of the limitations of claim 1, as noted above. Concina does not teach identifying at least one internal variable used for the at least one physical verification; and assigning the at least one internal variable to the at least one physical verification.
However, Marantz teaches identifying at least one internal variable used for the at least one physical verification; and assigning the at least one internal variable to the at least one physical verification (identifying the parameters in the DRC file and assigning them to the execution control file and the command file, [page 80 paragraph 4]; as an example see FIG. 4.1, where two rules “figure out gate area” and “check gate width >= 4u”, are split and assigned to separate tasks and commands in the execution control file and command file, respectively, [page 59]).
It would have been obvious to one skilled in the art before the effective filing date to combine Concina with Marantz because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Concina discloses a system and method that teaches all of the claimed features except for executing physical verification tasks (such as DRC and LVS) in parallel. For physical verification, Concina describes using a “commercial package for design verification”, and then cites [14] and [15], (Concina [page 256 col 1 paragraphs 5-6]), which are Block NCC and Dracula III, (see Concina citations, [page 257]). Marantz teaches “parallelism is a cost-effective strategy for accelerating VLSI CAD tools” and then provides a list of criteria necessary to exploit parallelism:
The program must be partitioned into discrete tasks
Each task must be individually callable from the operating system
All communication between tasks must be done through disk files.
Unless different computers can share the same file system, the time it takes to execute an individual task must be greater than the time it takes to transfer the files that it reads and writes
(Marantz, [page 18 paragraph 3 bullets 1-4]). The rest of the thesis describes a method of accelerating the commercial design verification software package Dracula by exploiting said parallelism, showing that EPIC/parallel Dracula “offers a significant performance enhancement over serial DRACULA”, (Marantz [page 64 paragraph 5 lines 1-2]). A person having skill in the art would have a reasonable expectation of successfully accelerating design verification software of Concina by modifying Concina with the Epic/Parallel Dracula System of Marantz. Therefore, it would have been obvious to combine Concina with Marantz to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 6, Concina in view of Marantz teaches all of the limitations of claim 1, as noted above. Concina does not teach identifying editing rights; providing information about a process of execution of the at least one physical verification, based on the editing rights; receiving an administrator input; and modifying the execution process, based on the administrator input.
However, Marantz teaches identifying editing rights; providing information about a process of execution of the at least one physical verification, based on the editing rights; receiving an administrator input; and modifying the execution process, based on the administrator input (passing data between master and slave in order to execute DRC tasks requires username and password for each device, which uses standard access control methods, see section 3.5.3 on Data Communications, [pages 44-46], specifically, the example script:
$COPY node1”username1password1”::device1:[directory1]file1.ext1 -
$ node2”username2 password2”::device2:[directory2]file2. ext2
[page 45 paragraph 2]).
It would have been obvious to one skilled in the art before the effective filing date to combine Concina with Marantz because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Concina discloses a system and method that teaches all of the claimed features except for executing physical verification tasks (such as DRC and LVS) in parallel. For physical verification, Concina describes using a “commercial package for design verification”, and then cites [14] and [15], (Concina [page 256 col 1 paragraphs 5-6]), which are Block NCC and Dracula III, (see Concina citations, [page 257]). Marantz teaches “parallelism is a cost-effective strategy for accelerating VLSI CAD tools” and then provides a list of criteria necessary to exploit parallelism:
The program must be partitioned into discrete tasks
Each task must be individually callable from the operating system
All communication between tasks must be done through disk files.
Unless different computers can share the same file system, the time it takes to execute an individual task must be greater than the time it takes to transfer the files that it reads and writes
(Marantz, [page 18 paragraph 3 bullets 1-4]). The rest of the thesis describes a method of accelerating the commercial design verification software package Dracula by exploiting said parallelism, showing that EPIC/parallel Dracula “offers a significant performance enhancement over serial DRACULA”, (Marantz [page 64 paragraph 5 lines 1-2]). A person having skill in the art would have a reasonable expectation of successfully accelerating design verification software of Concina by modifying Concina with the Epic/Parallel Dracula System of Marantz. Therefore, it would have been obvious to combine Concina with Marantz to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 7, Concina in view of Marantz teaches all of the limitations of claim 1, as noted above. Concina does not teach displaying a progress status of the physical verifications performed in parallel.
However, Marantz teaches displaying a progress status of the physical verifications performed in parallel (Each slave is responsible for keeping track of its own performance statistics, [page 52 paragraph 3 line 1]; Periodically, the slave sends the mast a one line summary of its progress. The master then relays this information to the monitor, which displays the information on the user's screen, [page 53 paragraph 1 lines 1-3]).
It would have been obvious to one skilled in the art before the effective filing date to combine Concina with Marantz because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Concina discloses a system and method that teaches all of the claimed features except for executing physical verification tasks (such as DRC and LVS) in parallel. For physical verification, Concina describes using a “commercial package for design verification”, and then cites [14] and [15], (Concina [page 256 col 1 paragraphs 5-6]), which are Block NCC and Dracula III, (see Concina citations, [page 257]). Marantz teaches “parallelism is a cost-effective strategy for accelerating VLSI CAD tools” and then provides a list of criteria necessary to exploit parallelism:
The program must be partitioned into discrete tasks
Each task must be individually callable from the operating system
All communication between tasks must be done through disk files.
Unless different computers can share the same file system, the time it takes to execute an individual task must be greater than the time it takes to transfer the files that it reads and writes
(Marantz, [page 18 paragraph 3 bullets 1-4]). The rest of the thesis describes a method of accelerating the commercial design verification software package Dracula by exploiting said parallelism, showing that EPIC/parallel Dracula “offers a significant performance enhancement over serial DRACULA”, (Marantz [page 64 paragraph 5 lines 1-2]). A person having skill in the art would have a reasonable expectation of successfully accelerating design verification software of Concina by modifying Concina with the Epic/Parallel Dracula System of Marantz. Therefore, it would have been obvious to combine Concina with Marantz to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 8, Concina teaches a system for verifying an integrated circuit, the system comprising (data structures and algorithms used in an integrated electron-beam probing system for IC diagnosis, [Abstract] lines 1-3): at least one processor; and a non-transitory storage medium storing instructions which, when executed by the at least one processor, cause the system to execute a process of verifying the integrated circuit, wherein the at least one processor is configured to (For verifying see FIG. 7, [page 257]; where these algorithms achieve O(log N) efficiency while requiring little memory overhead, [page 252 col 2 paragraph 3 lines 3-4], where O() notation refers to the efficiency of the processor executing the algorithm and memory refers to the storage medium; note “our software”, [page 252 col 2 paragraph 2 line 1], shown in FIG. 1, [page 251], running in a Unix environment, [page 257 col 1 paragraph 3 line 2]).
Regarding the rest of claim 8, incorporating the rejection of claim 1, claim 8 is rejected for substantially similar rationale.
With respect to claim 9, incorporating the rejection of claim 2 and claim 8, claim 9 is rejected for a substantially similar rationale.
With respect to claim 11, incorporating the rejection of claim 4 and claim 8, claim 11 is rejected for a substantially similar rationale.
With respect to claim 12, incorporating the rejection of claim 5 and claim 8, claim 12 is rejected for a substantially similar rationale.
With respect to claim 13, incorporating the rejection of claim 6 and claim 8, claim 13 is rejected for a substantially similar rationale.
With respect to claim 14, incorporating the rejection of claim 7 and claim 8, claim 15 is rejected for a substantially similar rationale.
With respect to claim 15, Concina teaches A non-transitory storage medium for storing instructions which, when executed by at least one processor, cause the at least one processor to execute a process of verifying an integrated circuit, wherein the process of verifying the integrated circuit comprises (For verifying see FIG. 7, [page 257]; where these algorithms achieve O(log N) efficiency while requiring little memory overhead, [page 252 col 2 paragraph 3 lines 3-4], where O() notation refers to the efficiency of the processor executing the algorithm and memory refers to the storage medium; note “our software”, [page 252 col 2 paragraph 2 line 1], shown in FIG. 1, [page 251], running in a Unix environment, [page 257 col 1 paragraph 3 line 2]).
Regarding the rest of claim 15, incorporating the rejection of claim 1, claim 15 is rejected for substantially similar rationale.
With respect to claim 16, incorporating the rejection of claim 2 and claim 15, claim 16 is rejected for a substantially similar rationale.
With respect to claim 18, incorporating the rejection of claim 4 and claim 15, claim 18 is rejected for a substantially similar rationale.
With respect to claim 19, incorporating the rejection of claim 5 and claim 15, claim 19 is rejected for a substantially similar rationale.
With respect to claim 20, incorporating the rejection of claim 6 and claim 15, claim 20 is rejected for a substantially similar rationale.
Claim(s) 3, 10, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Integrating Design Information For IC Diagnosis” (1987-Concina) in view of “Exploiting Parallelism In VLSI CAD” (1986-Marantz) in further view of “Design and characterization of a standard cell library for The freepdk45 Process” (2008-Anne)
With respect to claim 3, Concina in view of Marantz teaches all of the limitations of claim 1, as noted above. Concina and Marants do not teach wherein at least one of the physical verification includes LVS verification and V2LVS verification, and a verification input data of the LVS verification includes a verification result of the V2LVS verification.
However, Anne teaches wherein at least one of the physical verification includes LVS verification and V2LVS verification, and a verification input data of the LVS verification includes a verification result of the V2LVS verification (The tool Calibre from MGC has been used to complete the physical verification. DRC and LVS rules have been provided with the PDK. The design rule check could be completed with a few errors that were corrected manually. But for doing the layout vs. schematic, there were a few problems. First, the structural Verilog netlist has to be converted into a SPICE netlist using the Calibre tool. The command to do this is: v2lvs -v final.v -o source.net -s cells.sp -s0 gnd -s1 vdd, [page 56 paragraphs 2-3]).
It would have been obvious to one skilled in the art before the effective filing date to combine Concina in view of Marantz with Anne because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Concina in view of Marantz discloses a system and method that teaches all of the claimed features except for V2LVS. Concina teaches the LVS comparator taking a netlist as input (see FIG 7 of Concina [page 256]), where “schematic connectivity is usually acquired from a netlist description (e.g. SPICE)” (Concina [page 256 col 1 paragraph 3 lines 3-4]).
Anne teaches the problem and solution:
The tool Calibre from MGC has been used to complete the physical verification. DRC and LVS rules have been provided with the PDK. The design rule check could be completed with a few errors that were corrected manually. But for doing the layout vs. schematic, there were a few problems. First, the structural Verilog netlist has to be converted into a SPICE netlist using the Calibre tool. The command to do this is: v2lvs -v final.v -o source.net -s cells.sp -s0 gnd -s1 vdd.
(Anne [page 56 paragraphs 2-3]). Essentially, if the input starts as a Verilog netlist, and the program requires a Spice netlist, then a tool such as V2LVS is required to translate from one format to the other.
A person having skill in the art would have a reasonable expectation of successfully translating Verilog netlists into SPICE netlists so they can be input into the system and method of Concina in view of Marantz by modifying Concina in view of Marantz with the V2LVS tool of Anne. Therefore, it would have been obvious to combine Concina in view of Marantz with Anne to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 10, incorporating the rejection of claim 3 and claim 8, claim 10 is rejected for a substantially similar rationale.
With respect to claim 17, incorporating the rejection of claim 3 and claim 15, claim 17 is rejected for a substantially similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20010052107 A1 (Rittman) - The system consists of two (2) major components. Component #1 is the internet server and component #2 is the verification check server. The internet server is a powerful computer to route all verification checks requests according to priority and queue to the executing server. The verification check remote server is a powerful super computer that distributes all verification checks information for parallel processing execution on other computer systems at a main location. The main computer program is running on the verification check remote server and can handle multi-user, multi-technology verification checks execution. All technology files, design rule run sets and other necessary setup files are encrypted before sent to the main check server. This information then is decrypted at the main verification check server and executed. A separate computer program that is synchronized with the verification check program and is running on the internet server to manage verification checks requests traffic, priority and queue. When each verification check is complete all results are automatically available on the main verification check remote server. The verification check remote server informs the internet server about the verification check completion, which inform the user about the run completion and the availability of the result files, [0029].
US 2002/0078422 A1 (Bradley) - In a parallel program execution mode, the designer submits the exemplary four layout design jobs (e.g., DRC, LVS, Integration and Yield are executed concurrently) in parallel. If any one of the jobs fails, the designer has two options. The first option is to cancel the remaining incomplete jobs so the designer may fix the problems associated with one design program at a time. A second option is to let the remaining uncompleted jobs run to completion. The designer then may analyze the results of the completed jobs and attempt to fix errors in all the jobs at the same time. In either option, the process repeats itself until all jobs are error free, [0020].
US 2004/0049747 A1 (Yamasaki) - Cross reference information is generated when comparing between a logic circuit and a layout in order to facilitate retrieval of optimum corresponding information of logic circuit and layout. A design verification apparatus includes a storage unit which stores logic circuit data and layout data on its layout pattern; an element recognition unit which recognizes the connection relation of elements, and a comparative verification unit. The comparative verification unit compares and verifies the correspondence between the connection relation of logic circuit and connection relation of layout based on the logic circuit data to merge elements of the logic circuit, and compares and verifies the correspondence of the connection relation of the merged elements. Further, the apparatus generates a cross reference information file specifying the corresponding relation of the elements and their wiring in first and second function units depending on the connection relation of the logic circuit, [Abstract].
“Innovative Verification Strategy Reduces Design Cycle Time For High-End Sparc Processor” (Popescu) - Verification is a theme that runs through the lifecycle of the
Thunder SPARC processor [Figure 3]. Every verification tool was used more or less continuously once the design reached a stage where the tool was applicable. Thus Verilog simulation was a constant throughout the cycle. Later, accelerated simulation using the Zycad Paradigm XP began, and then continued. Likewise, the Quickturn system launched into action when it was time to begin in-circuit emulation, and it continued as well. Several modes of verification were always running in parallel, [page 2 col 2 paragraph 5]-[page 3 col 1 paragraph 1]; see also FIG. 5 showing LVS and DRC running independently after GDSII is created, [page 3].
“Developing a Distributed Architecture for Design Rule Checking” (2001-Pais) - This paper describes the design and implementation of a distributed object-oriented Design Rule Checker (DRC). The main focus is on the methodology employed to implement this distributed application. Code reusability is achieved rising an OO approach, making objects available for other tools, such as circuit extractor. The paper also addresses the application of design patterns, which produce loosely coupled elements, facilitating the integration of system modules, [Abstract].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL MILLER whose telephone number is (408) 918-7548. The examiner can normally be reached on Monday-Friday from 11am to 5pm (PT). If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jack Chiang, can be reached at telephone number 571-272-7483. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/D.M./Examiner, Art Unit 2851
/JACK CHIANG/Supervisory Patent Examiner, Art Unit 2851
Prosecution Insights