DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 9, 2026 has been entered.
Claim Rejections - 35 USC § 103
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 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 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.
Claims 1-4, 7, 9-12, 15, 17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Katz et al. (US PGPUB 2013/0311164; hereinafter “Katz”) in view of Wiechowski et al. (US PGPUB 2018/0101472; hereinafter “Wiechowski”), Cleaveland et al. (US PGUB 2005/0160321; hereinafter “Cleaveland”), Cardoza et al. (US Patent 5,630,049; hereinafter “Cardoza”), Heit et al. (US PGPUB 2019/0155291; hereinafter “Heit”) and Goldberg (US PGPUB 2019/0129831; hereinafter “Goldberg”).
Claim 1: (Currently Amended)
Katz teaches a data processing apparatus for verifying a software system, the data processing apparatus comprising:
at least one processing unit (Fig. 2: Processor 202); and
at least one memory unit communicatively coupled to the processing unit, wherein the at least one memory unit comprises ([0099] “the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.” [0100] “examples (a non-exhaustive list) of the computer-readable medium would include the following: … a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory) …”):
a simulation module configured to:
perform simulation of the software system for a first set of steps based on a first set of input values ([0028] “test generator 120 may comprise a simulator 125. Simulator 125 may simulate a state of target computerized system 105. Simulator 125 may simulate an execution of test 130, or a portion of test 130, by target computerized system 105. Test generator 120 may utilize simulator 125 to determine a state of target computerized system 105 after executing a generated portion of test 130. The state of target computerized system 105 may be utilized in generating additional portion of test 130,” wherein “a portion of test 130” is “a first set of steps” and further wherein the “portion of test 130” is known to comprise a "first set of input values”. [0071] “State simulator 230 may be configured to initially simulate an initial state of the target computerized system upon booting, loading a test or the like.”); and
determine a set of states associated with the software system during the first set of steps performed by the software system ([0028] “test generator 120 may comprise a simulator 125. Simulator 125 may simulate a state of target computerized system 105. Simulator 125 may simulate an execution of test 130, or a portion of test 130, by target computerized system 105. Test generator 120 may utilize simulator 125 to determine a state of target computerized system 105 after executing a generated portion of test 130. The state of target computerized system 105 may be utilized in generating additional portion of test 130.”); and
a display unit ([0099] “As will be appreciated by one skilled in the art, the disclosed subject matter may be embodied as a system, method or computer program product.” [0101] “Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages… The program code may execute entirely on the user's computer,” wherein a “user’s computer” is well-known to include some form of a “display unit”.).
With further regard to Claim 1, Katz in does not teach the following, however, Wiechowski teaches wherein the simulation module is configured to:
perform simulation of the software system using a model that represents an environment outside of the software system ([0005] “One exemplary scenario, can take a form in which, by actuating the accelerator pedal, a vehicle is accelerated up to a predetermined speed, and the accelerator pedal is released after reaching this speed. A simulation model can be used to describe the vehicle with corresponding interfaces for influencing the accelerator pedal,” wherein the “simulation model” represents a “vehicle” and an “accelerator pedal” which are an “environment outside of the software system”.); and
wherein the simulation of the software system is performed until a predefined condition is met, the predefined condition being related to the environment outside of the software system ([0004] “In the automobile field, embedded software applications are frequently developed as a function of, or on the basis of, physical and logical signal values (e.g., accelerator pedal positions and other information signals). To test the respective software applications, meaningful sequences for these signals should be defined to execute the software application while using the signals concerned, and to evaluate or to assess the output values generated.” [0009] “In a simulation process, a predetermined scenario is simulated on a test platform in a test scenario. The test platform, in this simulation process, generates output values based on input stimuli.” [0035] “As soon as predetermined conditions are satisfied, the execution is halted if necessary, the current status of the software variables is sent to the test tool.” [0038] “Any logical expression able to be evaluated can be used as a condition, for example, signal>5.” See also Cl. 14 of Wiechowski, “ending the simulation process when a predetermined condition is met,” wherein the “predefined condition” in Wiechowski is when the “signal>5”, wherein the “signal” can be representative of an “accelerator pedal position” which is a condition “related to the environment outside of the software system”.) and
being related to a condition of a vehicle system ([0004] “In the automobile field, embedded software applications are frequently developed as a function of, or on the basis of, physical and logical signal values (e.g., accelerator pedal positions and other information signals). To test the respective software applications, meaningful sequences for these signals should be defined to execute the software application while using the signals concerned, and to evaluate or to assess the output values generated.” [0005] “One exemplary scenario, can take a form in which, by actuating the accelerator pedal, a vehicle is accelerated up to a predetermined speed, and the accelerator pedal is released after reaching this speed. A simulation model can be used to describe the vehicle with corresponding interfaces for influencing the accelerator pedal,” wherein the “condition” in Wiechowski is disclosed as including a predetermined signal value, i.e. “signal>5” as discussed above, and further wherein Wiechowski discloses that the “accelerator pedal positions” is one “condition of a vehicle system” that is expressed as “signal value”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Katz with the simulation ending in response to a predefined condition as taught by Wiechowski as this “makes it possible, in particular, to interact with the respective test platform during a simulation process, or to enter into data exchange with It, and thus to react to events during the simulation” (Wiechowski [0010]).
With further regard to Claim 1, Katz in view of Wiechowski does not teach the following, however, Cleaveland teaches:
a verification module configured to ([0038] “The Guided Simulation engine 10 is responsible for constructing a set of tests… the outputs produced by the SUT 22 are required to match those stored in the test.”):
determine a state of the software system in which verification of the software system is to be initiated ([0040] “During the initialization procedure the Simulator 8 reads in the software artifact 2, constructs internal data structures for storing the current (initial 34) state of the SUT”),
the determination of the state of the software system in which the verification of the software system is to be initiated comprising instantaneous determination of the state from the set of states ([0037] “The simulator 8 is responsible…for restarting simulation in a previously recorded input state contained in such a data structure (see FIG. 4).” [0046] “When a user-specified limit on the length of randomly generated tests is reached, the Engine 10 resets the SUT to its initial state 34 and begins building the next test.”);
initiate the verification of the software system in the determined state ([0025] “The invention utilizes a simulator to drive the SUT from one input state to another, beginning in the initial input state.”);
perform the verification of the software system for a second set of steps based on a second set of input values ([0025] “The term simulator is used to refer to a system tool that permits the step-by-step execution of a piece of software… In each step of simulation, input data generated by the invention is fed into the SUT, which may execute several constructs in the SUT until either the SUT terminates or another input state is reached.” [0038] “when the sequence of inputs 18 is applied to the SUT, starting from the SUT's initial state 34, the outputs produced by the SUT 22 are required to match those stored in the test.”); and
output results of the verification of the software system on the display unit ([0004] “To test a piece of software a developer devises inputs to be fed into the software under test (SUT), runs the SUT on the inputs, and then checks that the resulting outputs conform to expectations,” wherein the “developer…checks… the resulting outputs” using the “display unit” made obvious in light of teachings of Katz discussed above. [0025] “In the course of this single simulation step, which consists of a sequence of execution steps, the SUT may produce outputs.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski with the verification module as taught by Cleaveland as this “relieves the developer of the burden of having to manually manipulate the state of the SUT before a test vector can be applied” (Cleaveland [0022]).
With further regard to Claim 1, Katz in view of Wiechowski and Cleaveland does not teach the following, however, Cardoza teaches:
instantaneous determination of the state, in which the software system starts operating in a particular operation mode, from the set of states (Col. 10 Ln. 56: “The target computer system may be in one of two modes: ‘polling mode’, or ‘interrupt-driven mode’.” Col. 11 Ln. 12: “FIG. 4 is a state transition diagram that represents the two states or modes of the target computer system during remote debugging and the transitions which cause the target computer system to change modes.” Col. 13 Ln. 10: “A mode of the target computer system may comprise a particular software state of the operating system and a corresponding hardware state of a network device.” Col. 15 Ln. 61: “Depending on the message type of the message to be processed, the target computer system may remain in polling mode or transition into interrupt-driven mode.” Col. 16 Ln. 39: “the number and type of hardware registers used to reflect the state of the target computer system may vary and therefore, so will the information that is saved and restored upon a state change.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski and Cleaveland with the determination of the state in which the software system starts operating in a particular operation mode as taught by Cardoza in order to “provide a more efficient means of remote software testing, and save software development time and resources” (Cardoza Col. 2 Ln. 30).
With further regard to Claim 1, Katz in view of Wiechowski, Cleaveland and Cardoza does not teach the following, however, Heit teaches:
wherein the software system is a software system of the vehicle system ([0019] “simulating an autonomous and/or semi-autonomous vehicle in one or more scenarios (e.g., traffic scenarios, weather scenarios, etc.)… scenarios include scenario parameters which can describe the environment of an autonomous vehicle system and can vary incrementally between consecutive scenarios (e.g., scenario parameters can describe objects and their locations in the vehicle's environment, weather conditions in the vehicle's environment, etc.). Vehicle performance can be evaluated, or quality of the autonomous vehicle system can be tested,” wherein the “autonomous vehicle system” is the “software system” being simulated and tested. [0023] “FIG. 1 illustrates an exemplary system block diagram 100 for simulation and verification of an autonomous vehicle system.”), and
wherein the predefined condition is related to the environment outside of the vehicle system ([0025] “scenario parameters 110 may describe a wide variety of scenarios, and may include one or more of: a distance between the autonomous vehicle system and an object entering its path (e.g., a pedestrian entering the vehicle's path at a distance of 500 meters, 400 meters, 250 meters, 100 meters, or 50 meters, among other possibilities), a type of object present in the scenario (e.g., a cyclist, another vehicle, a pedestrian, an animal, debris, etc.), roads and transportation infrastructure generally (e.g., a winding mountain road, a straight flat road, a four way stoplight intersection, a stop sign intersection, a roundabout, a road under construction, bridges, tunnels, and the like), weather and other environmental data (e.g., precipitation, ambient temperature, humidity, cloud cover, time of day, ambient luminosity or strength of sunlight, wind speed, etc.), traffic conditions (e.g., heavy traffic, light traffic, substantially no other vehicles, large number of pedestrians such as in a crowded parking lot, emergency vehicles driving atypically to arrive at an emergency, among other types of traffic conditions),” wherein the test scenario which executed until the “predefined condition” is met, i.e. as taught above in Wiechowski, is modified to include the “scenario parameters” as taught by Heit, wherein the “scenario parameters” define the “environment outside of the vehicle system” as it relates to evaluating the “predefined condition”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski, Cleaveland and Cardoza with the vehicle software system and simulated vehicle testing environment parameters as taught by Heit in order to “reduce the amount of resources required to test an autonomously operating vehicle's reliability by triggering system faults before failures are observed in real-world operation” (Heit [0007]).
With further regard to Claim 1, Katz in view of Wiechowski, Cleaveland, Cardoza and Heit does not teach the following, however, Goldberg teaches:
wherein the simulation module is further configured to store values of state variables associated with each state of the software system in a verification database, the state variables being related to the vehicle system ([0022] “The simulated object can be a simulated actor such as, for example, a simulated vehicle.” [0029] “state data indicative of one or more states of the simulated object at one or more times. The state(s) can be indicative of the position(s), heading(s), speed(s), etc. of the simulated object within the simulated environment at these one or more times.” [0030] “the state(s) can be parameterized into parameter data (e.g., indicative one or more parameters) within the context of the simulated environment.” [0031] “The simulation system can store the state data (e.g., in raw or parameterized form) and/or the motion trajectory associated with a simulated object in an accessible memory… The memory can be a library database that includes state data and/or motion trajectories of a plurality of simulated objects (e.g., generated based on user input)”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski, Cleaveland, Cardoza and Heit with the vehicle software system and simulated vehicle testing environment parameters as taught by Goldberg in order “to improved testing of a (partially or fully) autonomous vehicle computing system” (Goldberg [0019]).
Claim 2:
Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg teaches the data processing apparatus of claim 1. Katz in view of Wiechowski, Cardoza, Heit and Goldberg does not teach the following, however, Cleaveland teaches:
wherein the verification module is further configured to generate a plurality of test vectors for testing the software system ([0025] “The invention is a novel multi-step technique generating sequences of test vectors… The method also records the sequence of test vectors generated during a simulation run and uses these to construct the suite of test sequences the method produces upon completion.” [0046] “the test vectors that drive the simulation from one input state to another are generated semi-randomly by the Guided Simulation Engine 10.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski, Cardoza, Heit and Goldberg with generation of test vectors by the verification module as taught by Cleaveland since “the inputs prescribed by the test vector can be applied to ensure the coverage of another element, or target, in the coverage criterion” (Cleaveland [0015]).
Claim 3:
Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg teaches the data processing apparatus of claim 1, and Katz further teaches:
wherein the simulation module is further configured to perform the simulation of the software system using a closed-loop simulation technique (See the “closed-loop simulation” shown in Fig. 3 of Katz. Further, [0028] “Test generator 120 may utilize simulator 125 to determine a state of target computerized system 105 after executing a generated portion of test 130. The state of target computerized system 105 may be utilized in generating additional portion of test 130, such as a ‘next’ instruction about to be executed by target computerized system 105 according to the state determined by simulator 125.”).
Claim 4:
Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg teaches the data processing apparatus of claim 1. Katz in view of Wiechowski, Cardoza, Heit and Goldberg does not teach the following, however, Cleaveland teaches:
wherein the verification module is further configured to perform the verification of the software system using a bounded-model checking technique ([0046] “When a user-specified bound on the number of randomly generated tests is reached, the test-data-generation component of this phase terminates.” [0051] “In the second method to generate test vectors for bridge states 12, probes are launched from a bridge state to see if uncovered targets may become covered. A probe is a bounded sequence of simulation steps 20, each of which corresponds to the application of a randomly generated input vector 18, and each of which either causes a new target to be covered or leaves the SUT in a bridge state.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski, Cardoza, Heit and Goldberg with bounded-model checking technique as taught by Cleaveland in order “to limit the computer resources required to generate test cases while testing software” (Cleaveland [0055]).
Claim 7: (Currently Amended)
Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg teaches the data processing apparatus of claim 1. Katz in view of Wiechowski, Cardoza, Heit and Goldberg does not teach the following, however, Cleaveland teaches wherein the verification module is further configured to:
initialize the software system in the determined state using the values of the state variables associated with the determined state ([0037] “The simulator 8 is responsible…for restarting simulation in a previously recorded input state contained in such a data structure (see FIG. 4).” [0040] “During the initialization procedure the Simulator 8 reads in the software artifact 2, constructs internal data structures for storing the current (initial 34) state of the SUT”); and
initiate verification of the initialized software system in the determined state ([0025] “The invention utilizes a simulator to drive the SUT from one input state to another, beginning in the initial input state.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski, Cardoza, Heit and Goldberg with the verification module as taught by Cleaveland as this “relieves the developer of the burden of having to manually manipulate the state of the SUT before a test vector can be applied” (Cleaveland [0022]).
Claims 9-12 and 15:
With regard to Claims 9-12 and 15, these claims are equivalent in scope to Claims 1-4 and 7 rejected above, merely having a different independent claim type, and as such Claims 9-12 and 15 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1-4 and 7.
Claims 17-18 and 20:
With regard to Claims 17-18, these claims are equivalent in scope to Claims 1-2 and rejected above, merely having a different independent claim type, and as such Claims 17-18 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1-2.
With regard to Claim 20, this claim is equivalent in scope to a combination of Claims 3-4 rejected above, merely having a different independent claim type, and as such Claim 20 is rejected under the same grounds and for the same reasons as discussed above with regard to Claims 3-4.
With further regard to Claim 17, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Katz reference also anticipates these additional elements of Claim 17, for example, Katz teaches:
a non-transitory computer-readable storage medium that stores machine-readable instructions executable by a processing unit to verify a software system (Fig. 2: Processor 202. [0099] “the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.” [0100] “examples (a non-exhaustive list) of the computer-readable medium would include the following: … a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory)…”).
Claims 8, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg as applied to Claims 1, 9 and 17 above, and further in view of Murthy et al. (US PGPUB 2013/0055210; hereinafter “Murthy”).
Claim 8:
Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg teaches all the limitations of claim 1 as described above. Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg does not teach the following, however, Murthy teaches wherein the verification module is further configured to:
parse programming language statements associated with the software system ([0021] “Given a software program written in JavaScript, particular embodiments may parse the source code of the software program using a suitable JavaScript parser, as illustrated in STEP 301.”);
generate a control flow graph based on the parsed programming language statements (See Fig. 3 showing ‘Parsing’ Step 301 leading to ‘CFG Creation’ Step 309. [0029] “analyze the execution paths in the CPS model of the software program and construct a CFG for the software program, as illustrated in STEP 309… Each path through CFG 200 (e.g., formed by nodes and directed edges) corresponds to an execution path of the software program represented by CFG 200. The nodes correspond to the operations (e.g., ‘let’, ‘if’, ‘app’, ‘lambda’) found in the software program.”); and
determine whether any of the second set of input values lead to violation of a specification of the software system ([0032] “Typically, there are design specification or requirements for the software program, which may indicate the proper behavior or the correct input or output of the software program. Such specification or requirements may be used during the flow analysis of the software program to help determine whether a specific behavior or response of the software program is correct. Particular embodiments may access the design specification or requirements of the software program, as illustrated in STEP 403.” [0033] “Particular embodiments may perform flow analysis on the software program using the CFG of the software program and optionally, in reference to the specification of the software program, to catch problems (e.g., bugs), if any, in the source code of the software program, as illustrated in STEP 405.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg with the specification violation evaluation as taught by Murthy in order “to catch problems (e.g., bugs), if any, in the source code of the software program” (Murthy [0033]).
Claims 16 and 19:
With regard to Claims 16 and 19, these claims are equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claims 16 and 19 are rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg as applied to Claim 1 above, and further in view of Kubota (US PGPUB 2004/0061626; hereinafter “Kubota”).
Claim 23: (New)
Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg teaches all the limitations of claim 1 as described above. Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg does not teach the following, however, Kubota teaches wherein the verification module is further configured to:
wherein the state variables related to the vehicle system include mode of adaptive cruise control (ACC), minimum distance to keep from a vehicle in front, health status of ACC, history of distance to next vehicle, or any combination thereof ([0065] “control section 30 determines whether or not ACC (adaptive cruise control) is set in an operative state (ACC ON ?),” wherein “ACC ON” is a “mode of adaptive cruise control (ACC).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the apparatus as disclosed by Katz in view of Wiechowski, Cleaveland, Cardoza, Heit and Goldberg with the cruise control related state variable as taught by Kubota in order to “[determine] whether or not ACC (adaptive cruise control) is set in an operative condition” (Kubota [0089]).
Response to Arguments
Applicant's arguments, see Pages 10-15 of the Remarks filed March 9, 2026, with respect to the rejections under 35 U.S.C. 103 of Claims 1-4, 7-12, 15-20 and 23 have been fully considered but they are not persuasive. With respect to the Applicant’s argument that the newly amended language of Claims 1, 9 and 17 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Goldberg (US PGPUB 2019/0129831) reference as discussed above in the respective rejections. With respect to the Applicant’s argument that newly added Claim 23 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Kubota (US PGPUB 2004/0061626) reference as discussed above in the respective rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Morita et al. (US PGPUB 2015/0046133) discloses methods and systems for checking the operation of electrical systems of a vehicle, including the use of a communication simulating system which is able to obtain and use vehicle state information from a vehicle condition database.
Son et al. (“A simulation-based testing and validation framework for ADAS development,” April 2018) discusses a virtual validation and testing framework for ADAS (Advanced Driver Assistant System) planning and control development based on a co-simulation platform of vehicle dynamics and traffic environment tools.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/JOANNE G MACASIANO/ Examiner, Art Unit 2197