DETAILED ACTION
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-18 are presented for examination based on the application filed on August 21, 2023.
Claims 7-12 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1-18 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by US 2013/0179142 A1 Kim, Nam Do et al. [herein “Kim”].
This action is made non-Final.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) filed on September 30, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) filed on August 21, 2023 fails to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. It has been placed in the application file, but the information referred to therein has not been considered. Specifically, U.S. Patent Application Publications Cited No. 1-3 are not the correct format. Further, Non-Patent Literature Documents Cited No. 2, 3, 5, and 6 have not been provided.
Specification
The disclosure is objected to because of the following informalities:
Para. 0034, which cites “As indicated in Figure 2, hybrid DUT model 208”, should be “As indicated in Figure 2, hybrid DUT model 206”.
The use of the terms “DVD” and “Wi-Fi”, which are trade names or marks used in commerce, has been noted in this application. Each term should be accompanied by the generic terminology; furthermore, the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term. Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Appropriate correction is required.
Claim Objections
Claims 4-5, 10-11, and 16-17 are objected to because of the following informality: recitations of elements with no previous recitations. For example, claim 4, “the first process or the second process” in Ln. 3, is improper because there has been no previous recitation of “the first process or the second process”. For the purpose of examination, “the first process or the second process” will be interpreted as “a first process or a second process”. Claims 10 and 16, having similar limitations of claim 4, are also objected. Claims 5, 11, and 17 are also objected to for incorporating the deficiency of its dependent claim 4, 10, and 16, respectively.
Appropriate correction is required.
Claim Rejections - 35 U.S.C. § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 7-12 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because the broadest reasonable interpretation of the “program product” encompasses a computer program product, which is merely software per se. A claim whose BRI covers both statutory and non-statutory embodiments embraces subject matter that is not eligible for patent protection and therefore is directed to non-statutory subject matter. See MPEP 2106.03(II). Therefore, the claim does not fall within at least one of the four categories of patent eligible subject matter recited in 35 U.S.C. § 101 (process, machine, manufacture, or composition of matter). The examiner’s recommends that the claim be amended to “A non-transitory program product”, or similar, as supported by the specification to overcome this rejection.
Claim Rejections - 35 U.S.C. § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and 103 (or as subject to pre-AIA 35 U.S.C. § 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-18 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by US 2013/0179142 A1 Kim, Nam Do et al. [herein “Kim”].
As per claim 1, Kim teaches “A method of data processing in a data processing system, the method comprising: a processor of the data processing system initiating a restart of a co-simulation of an integrated circuit design from a co-simulation snapshot, wherein the initiating includes initiating a respective co-simulation communicator (CC) process for each of a main co-simulation unit, a first client co-simulation unit, and a second client co-simulation unit”. (Para. 0003-0004, “Semiconductor design verification simulation includes a process of building a computer-executable model including a design under verification (DUV) or at least one design object within the DUV and test bench (TB), which drives the design object in software, translating the computer-executable model into a sequence of machine instructions of a through a simulation compilation process, and executing the sequence on the computer. Therefore, a simulation is carried out by the sequential execution of machine instructions of a computer. There are many simulation techniques such as event-driven simulation, cycle-based simulation, compiled simulation, interpreted simulation, and co-simulation” [A method of data processing in a data processing system, and a co-simulation of an integrated circuit design]. Para. 0154, “Referring to FIG. 1, the design verification apparatus 10A may be a computer, a CPU core, or a processor. The design verification apparatus 10A can include a simulator 20, verification S/W 30, and a DUV 40, some or all of which is stored at a memory device or the like, and executed by the computer, CPU, or processor of the verification apparatus 10A. The simulator 20, the verification S/W 30, and the DUV 40 may be stored in one memory device all together” [i.e., the method comprising: a processor of the data processing system]. Para. 0210-0211, “The rollback may be carried out using simulation save/restart feature… to make the simulation save/restart feature possible, a process of saving a simulation state or a design state periodically or at one or more specific time points or periods is needed. This process is referred to as a checkpoint process or "checkpointing." Here, a checkpoint is generated through the process. Checkpoints can include one or more specific time points or periods at which a simulation state or a design state is saved and at which re-simulation is started” [initiating a restart of a co-simulation of an integrated circuit design from a co-simulation snapshot]. Para. 0165, “When at least two simulators include an event-driven simulator and a cycle-based simulator, distributed parallel simulation may be carried out in a co-simulation mode” and Para. 0112-0113, “Verification software (S/W) 30 according to some embodiments of the inventive concept, a simulator 343 executing a local simulation in a distributed parallel simulation environment, and a specific design object 380-1 (e.g., a specific design object in an RTL model) are executed at the first computer 100-1. A simulation of an on-chip bus design object 420 including a bus arbiter and an address decoder in a specific model, e.g., an RTL model, is executed in the simulator 343. The other computers 100-2 through 100-I can each run a verification S/W 30, and a simulator 343. A specific design object 380-2 through 380-I is executed on a corresponding one of the computers 100-2 through 1004. For convenience' sake in the description, the verification S/W 30 is installed in each of the computers 100-2 through 100-I in the embodiments illustrated in FIG. 7. However, the verification S/W 30 may not installed in the computers 100-2 through 100-I apart from the first computer 100-1” [i.e., wherein the initiating includes initiating a respective co-simulation communicator (CC) process for each of a main co-simulation unit, a first client co-simulation unit, and a second client co-simulation unit]. Further see Para. 0003-004, 0030, 0066-0075, 0164, 0164-0165, and 0210-0211. The examiner has interpreted that performing a semiconductor design verification simulation for a design under verification using a processor to save the simulation state and time to restart a checkpoint of the simulation of two simulators being an event-driven simulator and a cycle-based simulator that carrying out a distributed parallel simulation in a co-simulation mode where only the verification is run on a first computer but the simulators are executed on first and other computers as a method of data processing in a data processing system, the method comprising: a processor of the data processing system initiating a restart of a co-simulation of an integrated circuit design from a co-simulation snapshot, wherein the initiating includes initiating a respective co-simulation communicator (CC) process for each of a main co-simulation unit, a first client co-simulation unit.)
Kim teaches “the processor forking a first child process of the CC process of the first client co-simulation unit and forking a second child process of the CC process of the second client co-simulation unit”. (Para. 0322, “A current simulation time is set to 0 in operation S398. When a checkpoint should be generated at the current simulation time of a local simulation and there is no checkpoint generated earlier, a checkpoint is generated at the current simulation time and other local simulations is examined on rollback possibility after the generation of the checkpoint in operation S402” [for co-simulation, i.e., the processor forking a first child process of the CC process of the first client co-simulation unit and forking a second child process of the CC process of the second client co-simulation unit]. Further see Para. 0003-004, 0030, 0066-0075, 0164, 0164-0165, 0210-0211, and 0322. The examiner has interpreted that for co-simulation that generating a checkpoint for the local simulations to examine rollback possibilities as the processor forking a first child process of the CC process of the first client co-simulation unit and forking a second child process of the CC process of the second client co-simulation unit.)
Kim teaches “the processor, via inter-process communication from the CC process of the main co-simulation unit to the respective CC process of each of the first and second client co-simulation units, restarting coordinated execution of a cycle-based simulator by the first child process and execution of an event-based simulator by the second child process, wherein execution of the cycle-based simulator is restarted from a cycle-based simulation checkpoint and execution of the event-based simulator is restarted from an event-based simulation snapshot.” (Para. 0109, “event-driven simulators and cycle-based simulators can be provided. A simulator in accordance with the inventive concept may include any of the above-described simulators. Accordingly, when two or more simulators are used, each of the simulators can include but not be limited to any of the simulators mentioned above” [cycle-based simulator by the first child process and an event-based simulator by the second child process]. Para. 0323, “The simulation is stopped temporarily, information indicating there is a rollback possibility and the current simulation time, i.e., a possible rollback time, is transmitted to other local simulations in operation S408, and the method proceeds to operation S410. In operation S410, a current simulation time, or possible rollback time, of each local simulation having rollback possibility is obtained and the necessity of rollback/roll-forward and a rollback/roll-forward time is determined for the local simulation based on the possible rollback times of the local simulations” [ for co-simulation, i.e., the processor restarting coordinated execution]. Para. 0197, “When simulation using HDL simulators is event-driven, it is important to ensure that there is no event loss even if a simulation for DUV or at least one design object in the DUV is restarted at the specific simulation time Ta other than the simulation time 0 using a t-DCP like the state information of the DUV or the at least one design object. It is also important than the simulation is executed from the simulation time 0 to the specific simulation time Ta and then continued after being restarted at the specific simulation time Ta. It is also important that a simulation result obtained after the specific simulation time Ta is constant” [execution of the event-based simulator is restarted from an event-based simulation snapshot]. Para. 0198, “To ensure the restart of simulation at the specific simulation time Ta, instead of saving the state information of a previous simulation only at the specific simulation time Ta, the state information of the previous simulation for a predetermined time section "d" including the specific simulation time Ta is saved and the restart of the simulation begins with the predetermined time section "d" using the state information corresponding to the predetermined time section "d"” [wherein execution of the cycle-based simulator is restarted from a cycle-based simulation checkpoint]. Para. 0278, “the communication/synchronization module 64 can include a communication and synchronization module necessary for distributed parallel simulation” [i.e., for a co-simulation, via inter-process communication from the CC process of the main co-simulation unit to the respective CC process of each of the first and second client co-simulation units]. Further see Para. 0109, 0197-0202, 0270, 0278, and 0323. The examiner has interpreted that transmitting rollback possibility and simulation time for local simulation at the rollback and restarting the event-driven simulation at the specific simulation time and restarting the simulation with the predetermine time section included at the specific simulation time using a communication model for the distributed parallel simulation as the processor, via inter-process communication from the CC process of the main co-simulation unit to the respective CC process of each of the first and second client co-simulation units, restarting coordinated execution of a cycle-based simulator by the first child process and execution of an event-based simulator by the second child process, wherein execution of the cycle-based simulator is restarted from a cycle-based simulation checkpoint and execution of the event-based simulator is restarted from an event-based simulation snapshot.)
As per claim 2, Kim teaches “the processor determining a co-simulation interval from the co-simulation snapshot; wherein the restarting coordinated execution includes restarting the cycle-based simulator prior to the determined co-simulation interval and restarting the event-based simulator from the determined co-simulation interval.”(Para. 0197, “When simulation using HDL simulators is event-driven, it is important to ensure that there is no event loss even if a simulation for DUV or at least one design object in the DUV is restarted at the specific simulation time Ta other than the simulation time 0 using a t-DCP like the state information of the DUV or the at least one design object. It is also important than the simulation is executed from the simulation time 0 to the specific simulation time Ta and then continued after being restarted at the specific simulation time Ta. It is also important that a simulation result obtained after the specific simulation time Ta is constant” [the processor determining a co-simulation interval from the co-simulation snapshot and restarting the event-based simulator from the determined co-simulation interval]. Para. 0198, “To ensure the restart of simulation at the specific simulation time Ta, instead of saving the state information of a previous simulation only at the specific simulation time Ta, the state information of the previous simulation for a predetermined time section "d" including the specific simulation time Ta is saved and the restart of the simulation begins with the predetermined time section "d" using the state information corresponding to the predetermined time section "d"” [wherein the restarting coordinated execution includes restarting the cycle-based simulator prior to the determined co-simulation interval]. Further see Para. 0003-004, 0030, 0066-0075, 0109, 0164, 0164-0165, 0197-0202, 0210-0211, 0270, 0278, 0322, and 0323. The examiner has interpreted that restarting the event-driven simulation at the specific simulation time and restarting the simulation with the predetermine time section included at the specific simulation time as the processor determining a co-simulation interval from the co-simulation snapshot; wherein the restarting coordinated execution includes restarting the cycle-based simulator prior to the determined co-simulation interval and restarting the event-based simulator from the determined co-simulation interval.)
As per claim 3, Kim teaches “the CC process of the first client co-simulation unit communicating with the first child process via shared memory.” (Para. 0154, “Referring to FIG. 1, the design verification apparatus 10A may be a computer, a CPU core, or a processor. The design verification apparatus 10A can include a simulator 20, verification S/W 30, and a DUV 40, some or all of which is stored at a memory device or the like, and executed by the computer, CPU, or processor of the verification apparatus 10A. The simulator 20, the verification S/W 30, and the DUV 40 may be stored in one memory device all together” [i.e., communicating via shared memory]. Further see Para. 0003-004, 0030, 0066-0075, 0109, 0154. 0164, 0164-0165, 0197-0202, 0210-0211, 0270, 0278, 0322, and 0323.)
As per claim 4, Kim teaches “the processor saving the co-simulation snapshot based on a request from the first process or the second process.” (Para. 0210-0211, “The rollback may be carried out using simulation save/restart feature… to make the simulation save/restart feature possible, a process of saving a simulation state or a design state periodically or at one or more specific time points or periods is needed. This process is referred to as a checkpoint process or "checkpointing." Here, a checkpoint is generated through the process. Checkpoints can include one or more specific time points or periods at which a simulation state or a design state is saved and at which re-simulation is started” [i.e. the processor saving the co-simulation snapshot based on a request from the first process or the second process]. Further see Para. 0003-004, 0030, 0066-0075, 0109, 0154. 0164, 0164-0165, 0197-0202, 0210-0211, 0270, 0278, 0322, and 0323.)
As per claim 5, Kim teaches “based on the request, the processor causing the main co-simulation unit to issue a save command to the first process and the second process; and based on the save command, the first process saving the cycle-based simulation checkpoint and the second process saving the event-based simulation snapshot.” (Para. 0210-0211, “The rollback may be carried out using simulation save/restart feature… to make the simulation save/restart feature possible, a process of saving a simulation state or a design state periodically or at one or more specific time points or periods is needed. This process is referred to as a checkpoint process or "checkpointing." Here, a checkpoint is generated through the process. Checkpoints can include one or more specific time points or periods at which a simulation state or a design state is saved and at which re-simulation is started” [i.e. based on the request, the processor causing the main co-simulation unit to issue a save command to the first process and the second process]. Para. 0197, “When simulation using HDL simulators is event-driven, it is important to ensure that there is no event loss even if a simulation for DUV or at least one design object in the DUV is restarted at the specific simulation time Ta other than the simulation time 0 using a t-DCP like the state information of the DUV or the at least one design object. It is also important than the simulation is executed from the simulation time 0 to the specific simulation time Ta and then continued after being restarted at the specific simulation time Ta. It is also important that a simulation result obtained after the specific simulation time Ta is constant” [based on the save command, the second process saving the event-based simulation snapshot]. Para. 0198, “To ensure the restart of simulation at the specific simulation time Ta, instead of saving the state information of a previous simulation only at the specific simulation time Ta, the state information of the previous simulation for a predetermined time section "d" including the specific simulation time Ta is saved and the restart of the simulation begins with the predetermined time section "d" using the state information corresponding to the predetermined time section "d"” [based on the save command, the first process saving the cycle-based simulation checkpoint]. Further see Para. 0003-004, 0030, 0066-0075, 0109, 0154. 0164, 0164-0165, 0197-0202, 0210-0211, 0270, 0278, 0322, and 0323. The examiner has interpreted that restarting the event-driven simulation at the specific simulation time and restarting the simulation with the predetermine time section included at the specific simulation time based on the generated checkpoint generated from the save and restart feature as based on the request, the processor causing the main co-simulation unit to issue a save command to the first process and the second process; and based on the save command, the first process saving the cycle-based simulation checkpoint and the second process saving the event-based simulation snapshot.)
As per claim 6, Kim teaches “wherein the processor initiates inter-process communication between the CC processes prior to initiating execution of the cycle-based simulator by the first child process and execution of the event-based simulator by the second child process.” (Para. 0278, “the communication/synchronization module 64 can include a communication and synchronization module necessary for distributed parallel simulation” [communicate in order to run the distributed parallel simulation, i.e., for a co-simulation, wherein the processor initiates inter-process communication between the CC processes prior to initiating execution of the cycle-based simulator by the first child process and execution of the event-based simulator by the second child process]. Further see Para. 0003-004, 0030, 0066-0075, 0109, 0154. 0164, 0164-0165, 0197-0202, 0210-0211, 0270, 0278, 0322, and 0323.)
Re Claim 7, it is an articles of manufacture claim, having similar limitations of claim 1. Thus, claim 7 is also rejected under the similar rationale as cited in the rejection of claim 1.
Furthermore, regarding claim 7, Kim teaches “A program product, comprising: a storage device; and program code within the storage device that, when executed by a processor of a data processing system, causes the processor to perform”. (Para. 0154, “Referring to FIG. 1, the design verification apparatus 10A may be a computer, a CPU core, or a processor. The design verification apparatus 10A can include a simulator 20, verification S/W 30, and a DUV 40, some or all of which is stored at a memory device or the like, and executed by the computer, CPU, or processor of the verification apparatus 10A. The simulator 20, the verification S/W 30, and the DUV 40 may be stored in one memory device all together” [i.e., a program product, comprising: a storage device; and program code within the storage device that, when executed by a processor of a data processing system, causes the processor to perform]. Further see Para. 0003-004, 0030, 0066-0075, 0109, 0154. 0164, 0164-0165, 0197-0202, 0210-0211, 0270, 0278, 0322, and 0323.)
Re Claim 8, it is an articles of manufacture claim, having similar limitations of claim 2. Thus, claim 8 is also rejected under the similar rationale as cited in the rejection of claim 2.
Re Claim 9, it is an articles of manufacture claim, having similar limitations of claim 3. Thus, claim 9 is also rejected under the similar rationale as cited in the rejection of claim 3.
Re Claim 10, it is an articles of manufacture claim, having similar limitations of claim 4. Thus, claim 10 is also rejected under the similar rationale as cited in the rejection of claim 4.
Re Claim 11, it is an articles of manufacture claim, having similar limitations of claim 5. Thus, claim 11 is also rejected under the similar rationale as cited in the rejection of claim 5.
Re Claim 12, it is an articles of manufacture claim, having similar limitations of claim 6. Thus, claim 12 is also rejected under the similar rationale as cited in the rejection of claim 6.
Re Claim 13, it is a machine claim, having similar limitations of claim 1. Thus, claim 13 is also rejected under the similar rationale as cited in the rejection of claim 1.
Furthermore, regarding claim 13, Kim teaches “A data processing system, comprising: processing circuitry; a storage device coupled to the processing circuitry; and program code within the storage device that, when executed by the processing circuitry, causes the processing circuitry to perform”. (Para. 0154, “Referring to FIG. 1, the design verification apparatus 10A may be a computer, a CPU core, or a processor. The design verification apparatus 10A can include a simulator 20, verification S/W 30, and a DUV 40, some or all of which is stored at a memory device or the like, and executed by the computer, CPU, or processor of the verification apparatus 10A. The simulator 20, the verification S/W 30, and the DUV 40 may be stored in one memory device all together” [i.e., a data processing system, comprising: processing circuitry; a storage device coupled to the processing circuitry; and program code within the storage device that, when executed by the processing circuitry, causes the processing circuitry to perform]. Further see Para. 0003-004, 0030, 0066-0075, 0109, 0154. 0164, 0164-0165, 0197-0202, 0210-0211, 0270, 0278, 0322, and 0323.)
Re Claim 14, it is a machine claim, having similar limitations of claim 2. Thus, claim 14 is also rejected under the similar rationale as cited in the rejection of claim 2.
Re Claim 15, it is a machine claim, having similar limitations of claim 3. Thus, claim 15 is also rejected under the similar rationale as cited in the rejection of claim 3.
Re Claim 16, it is a machine claim, having similar limitations of claim 4. Thus, claim 16 is also rejected under the similar rationale as cited in the rejection of claim 4.
Re Claim 17, it is a machine claim, having similar limitations of claim 5. Thus, claim 17 is also rejected under the similar rationale as cited in the rejection of claim 5.
Re Claim 18, it is a machine claim, having similar limitations of claim 6. Thus, claim 18 is also rejected under the similar rationale as cited in the rejection of claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2023/0409788 A1 Biswas, Parijat et al. teaches a method for performing a distributed simulation of a circuit design using two client devices to generate simulation data regarding event and cycle data starting and ending at various times.
Banerjee, Somnath, and Tushar Gupta. "Fast and scalable hybrid functional verification and debug with dynamically reconfigurable co-simulation." In Proceedings of the International Conference on Computer-Aided Design, pp. 115-122. 2012 teaches performing a co-simulation of a system-on-chip design based on saved snapshots during the simulation to debug the design.
Gomes, Cláudio, Casper Thule, David Broman, Peter Gorm Larsen, and Hans Vangheluwe. "Co-simulation: State of the art." arXiv preprint arXiv:1702.00686 (2017) teaches a hybrid co-simulation for a discrete even based and continuous time based co-simulation on a system.
Examiner’s Note: The examiner has cited particular columns and line numbers in the reference that applied to the claims above for the convenience of the applicant. Although the specified citations are representative 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, to fully consider the references in their 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. In the case of amending the claimed invention, the applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for the proper interpretation and also to verify and ascertain the metes and bound of the claimed invention.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Simeon P Drapeau whose telephone number is (571)-272-1173. The examiner can normally be reached Monday - Friday, 8 a.m. - 5 p.m. 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, Ryan Pitaro can be reached on (571) 272-4071. 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.
/SIMEON P DRAPEAU/Examiner, Art Unit 2188
/RYAN F PITARO/Supervisory Patent Examiner, Art Unit 2188
Prosecution Insights