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 .
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.
Claim 4 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.
Claim 4 states “and following the at least one communication means, at least one triggered internal trigger and/or at least one external communication means until all distinct sets of telegrams are created in the given context.”. It is unclear what is being done after or during the following as no action is told. Examiner will be interpreting the claim as following the communication means to map input and outputs in the technical components as data.
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 (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 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-7 and 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20120066550 A1 (hereinafter referred to as Keum), Shin, KW., Lim, DJ. Model-based automatic test case generation for automotive embedded software testing. Int.J Automot. Technol. 19, 107–119 (2018). https://doi.org/10.1007/s12239-018-0011-6 (hereinafter referred to as Shin), US 20220236712 A1 (Büttner) and US 20220269593 A1 (Hereinafter referred to as Vos).
Regarding claim 1, Keum teaches:
A computer-implemented method for generating an integration test model, comprising: a. providing at least one communication means, wherein the at least one communication means is used for communication between a plurality of technical components of a technical system ((Para. [47], Keum shows an application integrated testing system 3 provides a testing architecture showing the interoperation of an application apparatus 34 and component service providing apparatuses 35 and 36, to perform a web service message transmission/reception. Examiner notes that the communication means correlates to the component service providing apparatuses message transmission/reception););
c. providing at least one system configuration as at least one test environment for testing an integration scenario, wherein the plurality of technical components are connected in a defined system configuration (Para. [48-50], Keum shows "The testing architecture includes information about an operating environment where the application integrated testing is performed. The operating environment information may include the type and number of testing apparatuses and the position information about the testing apparatus and the testing monitor. The operating environment information may be input by a user or may be automatically generated according to an algorithm that is programmed based on the analysis of the scenario specification. The component service providing apparatuses 35 and 36 provide the application apparatus 34 with component services including a first component service 350 and a N.sup.th component service 360. A service based application 340 composes the component services 350 and 360 into the service based application 340. The application apparatus 34 provides a user with the application 34 that is composed of the component services 350 and 360. The component service providing apparatus 35 and 36 interoperate with the application apparatus 34. A testing apparatus 31 executes the test case to test whether a web service message between the testing apparatus 31 and the application apparatus 34 satisfies a messaging procedure and input/output values that are described in the test case.);
d. providing a test data model (Para. [12], Keum shows a test model converting unit converts a scenario specification between at least one component service apparatus and a service based application apparatus to a test model, which represents an activity flow between the component service apparatus and the service based application apparatus);
e. generating the integration test model based on the at least one communication means, the at least test environment and the test data model; wherein information of the respective control logic chart is considered with regard to the at least one communication means (Para. [35,37], Keum recites “the execution functions are configured to test whether the application and the component services operate according to a message transmission/reception sequence, which is defined in the scenario specification. The test model conversion unit 100 converts the scenario specification 1000 to the test model 1100 by use of an activity diagram of an unified modeling language (UML). The UML activity diagram shows a system interaction, work flow, message transfer between objects, system architecture and component relationship by use of UML. The configuration and process for converting the scenario specification 1000 to the test model 1100 in the test model conversion unit 100 will be described later with reference to FIGS. 2, 4 and 5.” Para. [48], Keum shows ”the testing architecture includes information about an operating environment where the application integrated testing is performed.” Examiner notes the communication means relate to the component services which operate according to message transmission/reception, which is defined in the scenario specification. They are considered in regard to the control logic chart as the UML diagram converts the scenario specification into the test model. The test environment is included within the testing architecture. The paragraphs cited above relate directly to the application integrated testing apparatus which will be considered to be the integration test model in this case. Keum shows the configuration of the application integrated testing apparatus within Para. [33-51])); and
f. providing the integration test model in order to generate integration test cases and executable test scripts for automated testing (Fig. 1; Para. [35-39], Keum shows " the test model conversion unit 100 converts the scenario specification 1000 to the test model 1100 by use of an activity diagram of an unified modeling language (UML). The UML activity diagram shows a system interaction, work flow, message transfer between objects, system architecture and component relationship by use of UML. The configuration and process for converting the scenario specification 1000 to the test model 1100 in the test model conversion unit 100 will be described later with reference to FIGS. 2, 4 and 5. The test case generating unit 110 generates a test case 1200 from the test model 1100. The test case 1200 is used to test whether the component service and the application are normally provided. The test case 1200 is configured to detect errors in the control flow of message transfer and the data flow between the application and the service component. The test case execution unit 120 performs a test on the service based application and the component services in an integrated manner. The test case execution unit 120 inputs a value of a parameter to the test case 1200, and tests whether the application operates according to a message transmission/reception sequence, which is defined in the scenario specification 1000, through the value.").
Keum does not disclose:
wherein the plurality of technical components communicate information with each other by means of telegrams, and the telegrams are sent and received by the technical component at defined ports;
b. assigning at least one respective technical component of the plurality of technical components to the at least one communication means by at least one respective control logic chart;
wherein the at least one respective control logic chart describes a behavior of the plurality of technical components comprising a reaction that a received telegram will trigger within the technical component, which other telegrams are sent as a result and whether the telegram is stopped or forwarded at a defined port;
However, in the analogous art of transmitting data in an automation network, Büttner teaches:
wherein the plurality of technical components communicate information with each other by means of telegrams, and the telegrams are sent and received by the technical component at defined ports (Para. [15], Buttner shows "The automation network comprises a plurality of network subscribers comprising at least a master subscriber, at least a switch, and at least a slave subscriber. The master subscriber comprises master ports, the switch comprises switching ports, and the slave subscriber comprises slave ports, each of which comprises a transmitter for transmitting telegrams and a receiver for receiving telegrams.");
Additionally, in the analogous art of automotive embedded testing, Shin teaches:
b. assigning at least one respective technical component of the plurality of technical components to the at least one communication means by at least one respective control logic chart (Table 3. Sec. 3.3 pg. 114, Shin shows to do the hardware testing, it is necessary to convert the software variables to the appropriate hardware signals. For example, the hardware target can be tested via digital/ analog IO devices and several communication interfaces. In this process, unlike the software variables, hardware signal delays can occur when passed through other internal circuits. ... As shown in Table 3, hardware mapping tables are used to store the hardware and software mapping information and make it possible to keep changes in hardware test cases to a minimum when the hardware test environment is altered. In other words, such tables are used to convert software integration test cases into hardware test cases. In addition, they contain information such as the type of test instruments that can be connected to the hardware, and the type of input and output signals (e.g., digital, analog, and pulse-width modulation). This information is changed according to the target and test instruments used when the test environment is changed. If the change in hardware environment occurs frequently without the need to convert the software test cases in advance, it can be more efficient to convert into a hardware test case at runtime, because it is better to modify the table rather than all of the hardware test cases whenever the environment changes. Sec. 4, pg. 117-118, then we used our method to generate hardware test cases. To this end, irrelevant variables must be eliminated from the test cases and then the cases must be converted into hardware test cases composed of actual hardware signals, such as digital and analog signals. These are mainly eliminated during the integration process. At the end of this process, the final remaining variables are converted into input and output signals needed for hardware testing. ... .A hardware mapping table is created so such commands can be automatically added during the conversion process. Sec. 5, pg. 118, Shin shows the UML model is first converted into XMI format to generate test cases, and then state diagram specifications are converted into an abstract syntax tree using a custom parser generator. The unit test cases taken from the AST and state diagrams are generated based on breadth-first searching. ... .Next, we integrate the unit test cases, using a new divide-and-conquer approach based on the bottom-up relationships of each module. Because this approach reuses the path and input/output information from each unit test case it reduces the time required to generate an integration test case compared to random input generation. Finally, integration test cases are converted back into hardware test cases);
Additionally, in the analogous art of automated generation of integrated tests, Vos teaches:
wherein the at least one respective control logic chart describes a behavior of the plurality of technical components comprising a reaction that a received telegram will trigger within the technical component, which other telegrams are sent as a result and whether the telegram is stopped or forwarded at a defined port (Fig. 6-7; Para. [11], Vos shows "the method and set of functions further include receiving the plurality of system models. Each system model is configured to electronically simulate a certain function or a group of functions that the system is configured to perform." Para. [13], Vos shows "the method and set of functions wherein each system model is configured to generate one or more expected outputs in response to one or more inputs based on the certain logic circuit associated with a particular system model." Examiner notes Fig. 6-7 show logic charts displaying the flow of inputs/outputs between systems (technical components). Fig. 7 further shows in details logic triggered based on what is 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 incorporate the teachings of Büttner into the teachings of Keum to implement “wherein the plurality of technical components communicate information with each other by means of telegrams, and the telegrams are sent and received by the technical component at defined ports”. The modification would have been obvious as one of ordinary skill in the art would be motivated as telegrams can work on data lines when other forms of communication fail (Buttner, .
In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Shin into the teachings of Keum to implement “assigning at least one respective technical component of the plurality of technical components to the at least one communication means by at least one respective control logic chart”. The modification would have been obvious as one of ordinary skill in the art would be motivated to use model based testing in order to reduce time and effort needed from developers to test all possible combinations of software inputs (Shin, Sec. 5, Pg. 107).
In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Vos into the teachings of Keum to implement “wherein the at least one respective control logic chart describes a behavior of the plurality of technical components comprising a reaction that a received telegram will trigger within the technical component, which other telegrams are sent as a result and whether the telegram is stopped or forwarded at a defined port”. The modification would have been obvious as one of ordinary skill in the art would be motivated to analyze the inputs and outputs of each technical component to determine the group of critical inputs for the purpose of integrated testing (Vos, Para. [6]).
Regarding claim 2, Keum as modified teaches claim 1 as cited above, but does not explicitly teach:
wherein providing the at least one system configuration as at least one test environment comprises: providing a plurality of test environments by generating a respective test environment for each system configuration of a plurality of system configurations; providing one test environment for a plurality of system configurations; or providing at least one configured test environment considering at least one requirement.
However in the analogous art of automated generation of integrated tests, Vos teaches:
wherein providing the at least one system configuration as at least one test environment comprises: providing a plurality of test environments by generating a respective test environment for each system configuration of a plurality of system configurations (Para. [50], Vos shows automatically running the system test case 112 using a system test procedure 115 for each system model 104. System test procedures 115 include at least step-by-step instructions for how each test case 112 is to be set up and executed, how the test results are evaluated, and the test environment to be used); providing one test environment for a plurality of system configurations; or providing at least one configured test environment considering at least one requirement (Para. [15], Vos shows testing a particular system model separate from an environment of the particular system model so that the particular system model is tested independently from other system models that provide inputs to the particular system model).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Vos into the teachings of Keum as modified to implement “wherein providing the at least one system configuration as at least one test environment comprises: providing a plurality of test environments by generating a respective test environment for each system configuration of a plurality of system configurations; providing one test environment for a plurality of system configurations; or providing at least one configured test environment considering at least one requirement”. The modification would have been obvious as one of ordinary skill in the art would be motivated to provide early and automated system integration testing resulting in early discovery of integration issues which lead to cost savings (Vos, Para. [43]).
Regarding claim 3, Keum as modified teaches claim 1 as cited above and teaches:
wherein the information is information of a control flow (Para. [35-36], Keum shows the test model conversion unit 100 converts the scenario specification 1000 to the test model 1100 by use of an activity diagram of an unified modeling language (UML). The UML activity diagram shows a system interaction, work flow, message transfer between objects, system architecture and component relationship by use of UML. The test case generating unit 110 generates a test case 1200 from the test model 1100. The test case 1200 is used to test whether the component service and the application are normally provided. The test case 1200 is configured to detect errors in the control flow of message transfer and the data flow between the application and the service component).
Regarding claim 4, Keum as modified teaches claim 1 as cited above, but does not explicitly teach:
wherein considering information of the respective control logic chart, comprises: starting with the at least one communication means communicated by the at least one technical component; and following the at least one communication means, at least one triggered internal trigger and/or at least one external communication means until all distinct sets of telegrams are created in the given context
However in the analogous art of automated generation of integrated tests, Vos teaches:
wherein considering information of the respective control logic chart, comprises: starting with the at least one communication means communicated by the at least one technical component; and following the at least one communication means, at least one triggered internal trigger and/or at least one external communication means until all distinct sets of telegrams are created in the given context (Para. [53-54], Vos shows in block 118, the method 100 includes performing input/output (I/O) management to generate input/output (I/O) data 120. Performing input/output management includes analyzing inputs and outputs of the system models 104 and automatically determining integration of interacting system models 104 based on analysis of the inputs and outputs. Analyzing the inputs and outputs of the system models 104 includes correlating different expected output values of an output or outputs of a first system model 104 to an input or inputs of at least a second system model 104. Output values and corresponding input values are embodied in signals between interacting system models 104. In block 118, the method 100 further includes analyzing the signals between interacting system models in terms of data type, dimension, range of values, units, etc. to generate the input/output data (I/O) 120. In block 122, the method 100 includes automatically generating, by the processor circuit, e.g., processor circuit 1002 in FIG. 10, one or more integrated test harnesses 124. Each integrated test harness 124 includes a group of interacting system models 104 of the plurality of system models 104. Referring also to FIG. 5, FIG. 5 is an example of an automatically generated integrated test harness 124 for systems A and B in accordance with an example of the present disclosure. The integrated test harness 124 includes the system test harness 108a for system A and the system test harness 108b for system B integrated together. An output signal 304 from one or more of the interacting system models 104a and 104b is an input signal 406a to one or more other interacting system models 104. An integrated test harness 124 is automatically generated for each group of different interacting system models 104 in response to there being more than one group of different interacting system models)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Vos into the teachings of Keum as modified to implement “wherein considering information of the respective control logic chart, comprises: starting with the at least one communication means communicated by the at least one technical component; and following the at least one communication means, at least one triggered internal trigger and/or at least one external communication means until all distinct sets of telegrams are created in the given context”. The modification would have been obvious as one of ordinary skill in the art would be motivated to determine critical inputs (Vos, Para. [56]).
Regarding claim 5, Keum as modified teaches claim 1 as cited above, but does not explicitly teach:
analyzing the integration test model; and/or adapting the integration test model.
However in the analogous art of automated generation of integrated tests, Vos teaches:
analyzing the integration test model; and/or adapting the integration test model (Para. [58], Vos shows the method 100 includes performing analysis of the integrated test procedure coverage report 132 and generating an integrated systems analysis report 136 in response to performing analysis of the integrated test procedure coverage report 132. Performing analysis of the integrated test procedure coverage report 132 includes analyzing of the parts of the integrated test case).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Vos into the teachings of Keum as modified to implement “analyzing the integration test model; and/or adapting the integration test model”. The modification would have been obvious as one of ordinary skill in the art would be motivated how to obtain substantially one hundred percent (100%) coverage (Vos, Para. [58]).
Regarding claim 6, Keum as modified teaches claim 1 as cited above and teaches:
generating at least one executable test according to at least one test goal based on the integration test model (Para. [36], Keum shows the test case generating unit 110 generates a test case 1200 from the test model 1100. The test case 1200 is used to test whether the component service and the application are normally provided. The test case 1200 is configured to detect errors in the control flow of message transfer and the data flow between the application and the service component).
Regarding claim 7, Keum as modified teaches claim 6 as cited above and teaches:
executing the at least one executable test (Para. [39-40], Keum shows the test case execution unit 120 performs a test on the service based application and the component services in an integrated manner. The test case execution unit 120 inputs a value of a parameter to the test case 1200, and tests whether the application operates according to a message transmission/reception sequence, which is defined in the scenario specification 1000, through the value. If a message parameter value is input to the test case 1200, a set of executable test cases is generated, and the test case execution unit 120 performs an integrated test by use of the test cases. For example, when SOAP messages are sent having parameters, the test case execution unit 120 specifies a predetermined parameter value in the test case to test whether the application is provided according to the scenario specification 1000. The test case execution unit 120 may store results of the test, such as success, failure and deferred determination or may be output results of the test in a test result sheet 1300) in the at least one test environment to generate at least one test result (Para. [48], Keum shows the testing architecture includes information about an operating environment where the application integrated testing is performed).
Regarding claim 9, it is a computer program product claim having similar limitations as cited in claim 1. Thus, claim 9 is also rejected under the same rationale as cited in claim 1.
Regarding claim 10, it is a system claim having similar limitations as cited in claim 1. Thus, claim 10 is also rejected under the same rationale as cited in claim 1.
Claim(s) 1-7 and 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20120066550 A1 (hereinafter referred to as Keum), Shin, KW., Lim, DJ. Model-based automatic test case generation for automotive embedded software testing. Int.J Automot. Technol. 19, 107–119 (2018). https://doi.org/10.1007/s12239-018-0011-6 (hereinafter referred to as Shin), US 20220236712 A1 (Büttner) and US 20220269593 A1 (Hereinafter referred to as Vos) in further view of US 20040173413 A1 (Hereinafter referred to as Angst).
Regarding claim 8, Keum as modified teaches claim 7 as cited above and teaches:
storing the at least one test result in a storage unit; and/or transmitting the at least one test result and/or any other related notification to a computing unit
Keum as modified does not disclose:
triggering at least one measure depending on the at least one test result to reach a safe state;
However, in the analogous art of safety critical systems, Angst teaches:
triggering at least one measure depending on the at least one test result to reach a safe state (Para. [35], Angst shows if a system test device integrated in the elevator control 15 does not signal any relevant errors, the elevator can continue its travel as programmed. After a defined short period, measured from the moment of the activation of the first braking measure, the speed monitoring device 24.1 checks whether the speed limit value graph 28 is still being exceeded and activates, where applicable, (at point 31) a second braking measure (the mechanical drive brake 10 on drive motor 9 in FIG. 1A or the clasp brake 58 acting on piston rod 52 in FIG. 1B), as a result of which the elevator is braked according to the drive braking graph 34. Where the speed monitoring device 24.1 detects, after a brief further waiting period, that the speed limit value graph 28 is still being exceeded, it triggers (at graph point 32) a last braking measure, according to this embodiment, i.e. it activates the electro-magnetically activatable safety catch 18 that stops the elevator);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Angst into the teachings of Keum as modified to implement “triggering at least one measure depending on the at least one test result to reach a safe state”. The modification would have been obvious as one of ordinary skill in the art would be motivated in case of any occurring differences, [that] suitable safety measures are triggered (Angst, Para. [20]).
Response to Arguments
Applicant's arguments regarding 35 U.S.C. 112(b) filed 6/25/2026 have been fully considered but they are not persuasive.
Applicant argues on Pg. 6, that the amended claim 1 establishes sufficient antecedent basis for “all distinct sets of telegrams” in claim 4 . While this is true, the other portion of the rejection to claim 4 still is maintained as no amendment fixes the indefiniteness of claim 4. Claim 4 recites “and following the at least one communication means, at least one triggered internal trigger and/or at least one external communication means until all distinct sets of telegrams are created in the given context.”. It is still unclear what is being done after or during the following as no action is told.
Applicant's arguments regarding 35 U.S.C. 101 filed 6/25/2026 have been fully considered and they are persuasive.
Applicant's arguments regarding 35 U.S.C. 103 filed 6/25/2026 have been fully considered but they are not persuasive.
Applicant argues on Pg. 11, that “Keum does not disclose telegrams sent and received at defined ports, nor control logic charts that describe the specific behavior recited in amended claim 1. Keum's UML activity diagrams show system interaction, workflow, and message transfer between objects, but do not define which reaction a received telegram will trigger within a technical component, which other telegrams are sent as a result, or whether the telegram is stopped or forwarded at a defined port.”. However, Buttner shows "The automation network comprises a plurality of network subscribers comprising at least a master subscriber, at least a switch, and at least a slave subscriber. The master subscriber comprises master ports, the switch comprises switching ports, and the slave subscriber comprises slave ports, each of which comprises a transmitter for transmitting telegrams and a receiver for receiving telegrams. (Para. [15])". When in view of Keum it becomes obvious to use telegrams as a means of communication between technical components and all other uses for telegrams recited are common for data transmitted between components in a system. As shown by Vos, Fig. 6-7; Para. [11], Vos shows "the method and set of functions further include receiving the plurality of system models. Each system model is configured to electronically simulate a certain function or a group of functions that the system is configured to perform." Para. [13], Vos shows "the method and set of functions wherein each system model is configured to generate one or more expected outputs in response to one or more inputs based on the certain logic circuit associated with a particular system model." Examiner notes Fig. 6-7 show logic charts displaying the flow of inputs/outputs between systems (technical components). Fig. 7 further shows in details logic triggered based on what is input.
In response to applicant’s argument on Pg. 12 that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Shin shows on Pg. 11, all combinations of input values for software should be tested, however time required and computational restraints continue to increase, motivating users to use automated test generation where model based testing excels at functional testing.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CN 110990292 A – This prior art teaches integration testing using UML models and diagrams
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZEERICK A MALIK whose telephone number is (571)272-8110. The examiner can normally be reached Mon-Thurs, 7-5.
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, Chat Do can be reached at (571) 272-3721. 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.
/Z.A.M./Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights