The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
Claim(s) 1-20 has/have been examined.
Claim(s) 16-20 are objected to as containing novel subject matter while having informal issues.Claim(s) 1-15 have been rejected.
Novel Subject Matter
Claim(s) 16-20 is/are objected to as reciting novel subject matter having informal issues. The novel subject matter is as described in the office action of September 30, 2025.
Response to Arguments
The arguments filed January 9, 2026 have been fully considered but are not persuasive. Applicant argues that the references do not teach selecting a first OS that is compatible with a first device type and a second OS that is compatible with the second device type, and issuing commands for test programs to a device of the first type using the first OS and to a device the second type using the second OS. The examiner respectfully disagrees. Chinnadurai teaches: the vehicle diagnostic OS may include one of a variety of RTOS to serve requests including diagnostic routines (paragraph 27). Different types of vehicles may require different programs (paragraph 28). The diagnostic tool may determine it is running the correct software for a particular vehicle by comparing the vehicle type with the vehicle diagnostic OS currently running (paragraph 28). Chinnadurai thus envisions multiple possible diagnostic OSes, and testing of multiple possible types of vehicles, and only particular vehicles types may be compatible with a currently running diagnostic OS. Chinnadurai renders obvious testing of multiple types of vehicles, and testing by using a compatible RTOS for each, which may be a different RTOS.
While Chinnadurai does not describe simultaneously running multiple diagnostic OSes or simultaneously testing multiple devices; Parsons renders obvious a simultaneous testing.
Claim Objections
Claim 4 line 9 should read “selected from a group consisting of”.
Claim 11 line 7 should read “wherein the first test program is associated”.
Claim 11 line 8 should read “and the second test program”.Claim 15 line 3 should read “by a processor of the computing unit”.Claim 16 line 4 should read “coupled to the testing system”.
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-7, 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai (PG-PUB 2014/0277922) in view of Grobler (PG-PUB 2018/0151003) and Parsons (PG-PUB 2017/0279945).
Regarding claim 1, Chinnadurai discloses a method executed by a computing unit in a test assembly, the method comprising:
receiving, from an external system operable for communication with the computing unit, a plurality of test programs for testing a plurality of devices communicatively coupled to the computing unit and to one or more test interface boards of the test assembly (paragraphs 27 and 28, various RTOS may be implemented, each capable of executing diagnostic routines for connected and compatible vehicles);
determining a first device type and a second device type for the plurality of devices (paragraphs 27 and 28, a vehicle diagnostic operating system is based on a variety of possible RTOSes; different vehicle manufacturers may require different programs and communication protocols to be run by the testing; the system must determine which type of vehicle, and then a RTOS and diagnostic routines within the RTOS to execute);
selecting a first operating system that is compatible with the first device type and a second operating system that is compatible with the second device type, wherein the computing unit is configured to execute a plurality of different operating systems (paragraph 28, a vehicle diagnostic operating system Is run for testing; the different manufacturers may require different programs and communication protocols, the tool determines whether it is running the correct software by comparing the vehicle type with the vehicle diagnostic operation system being run; use of a first and second RTOS is obvious because different RTOS may execute diagnostic routines (paragraph 27) and different vehicle manufacturers may require the diagnostic tool to operate using different programs for a particular vehicle (paragraph 28);
issuing commands for executing a first test program of the plurality of test programs to said each device of said first device type using the first operating system that is selected (paragraph 27, the vehicle diagnostic operating system includes diagnostic routines);
issuing commands for executing a second test program of the plurality of test programs to each device of said second device type using the second operating system (similar to above. Paragraphs 27 and 28, the reference envisions a variety of vehicle device types, each tested by a compatible vehicle diagnostic OS possibly including a different RTOS).
Chinnadurai does not expressly disclose the method wherein the test program is received from an external system operable for communication with the computing unit; and wherein the method comprises: receiving results of the testing of the plurality of devices; and transmitting the results of the testing to the external system.
Grobler teaches a system for performing vehicle testing using a diagnostic server that is remotely connected to a diagnostic interface (paragraph 24). The diagnostic server supplies hardware parameters (ECU parameters) to a diagnostic tool which communicates with a ECU of a vehicle to perform testing (paragraph 4). The diagnostic server also receives error codes sent by an OBD system (paragraph 47).Prior to the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the testing system disclosed by Chinnadurai such that a remotely located diagnostic server provides ECU parameters for a vehicle test and receives error codes, as taught by Grobler. This modification would have been obvious because remotely accessing a diagnostic server allows it be located remote from a diagnostic interface device and a vehicle, such as in a different country (Grobler paragraph 93). Use of the diagnostic server to supply ECU parameters allows the diagnostic interface device to have minimal processing, limited cost, and does not need to be maintained up to date (Grobler paragraph 136).Chinnadurai does not expressly disclose the method wherein the test program is for testing a plurality of devices communicatively coupled to the computing unit and the method comprises determining a respective location, in the one or more test interface boards, of each device of the plurality of devices.
Parsons teaches a system that simultaneously performs testing on multiple mobile devices (paragraph 3). The devices are each associated with slots in a test frame (paragraph 22). The test system installs a test mobile device application and obtains audio and video from connectors associated with a particular mobile device (paragraph 75).Prior to the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the testing system disclosed by Chinnadurai such that multiple devices are tested simultaneously, and the testing method includes identifying a location of a device under test, as taught by Parsons. This modification would have been obvious because simultaneous testing can increase test efficiency and save time (Parsons paragraph 133), and determining a device location allows receiving information from connectors to the device (Parsons paragraphs 75 and 76).
Chinnadurai in view of Grobler and Parsons also discloses:
2. The method of Claim 1, wherein the one or more test interface boards are configured for connectivity to different types of devices having different form factors (Parsons paragraph 27, the system accommodates a wide range of mobile device sizes).
3. The method of Claim 1, further comprising providing context for executing at least one of: the first test program (Chinnadurai paragraph 28, the diagnostic OS operates the computer device to perform various diagnostic tests, the OS provides a context or software environment for the testing) and the second test program.
4. The method of Claim 1, wherein:
the computing unit comprises:
a single board computer comprising a processor and memory (Chinnadurai Figure 1 and paragraph 15 describe a tablet or PDA device; Figure 2 shows its block diagram having a processor and memory), and operable for using different communication protocols (Chinnadurai paragraph 28, compatible communication protocols are utilized for many possible protocols);
a first communications interface (paragraph 26, the user interface operating system may communicate with external servers of an OS developer to receive updates) that receives the plurality of test programs from the external system and that transmits the results of the testing to the external system (Grobler paragraphs 4 and 47, a diagnostic server supplies ECU parameters and receives testing error codes); and
a second communications interface that transmits the commands to said each device and that receives the results of the testing (Chinnadurai Figure 2, interface 211 connects to the vehicle to send tests and receive results); and
the external system is a computer system selected from the group consisting of: a proxy server (Grobler paragraph 93, the diagnostic server can be located remotely outside of the Wi-Fi network; while not specifically described in the reference, the examiner takes official notice that use of a proxy server is well-known, and it would have been obvious to a person of ordinary skill in the art to utilize such a function because it provides privacy and network security; see, for example, attached NPL documents related to proxy servers) and a client system.
5. The method of Claim 4, further comprising:
generating a data package comprising a compilation of the results of the testing of said each device (Parsons paragraph 78, test results are sent to a user computer and Grobler paragraph 17, an error message is transmitted to the diagnostic interface device; an error code from OBD can also be transmitted to a diagnostic server for a user (paragraph 126); while a data package is not specifically recited, it would be obvious to one of ordinary skill in the art to utilize a data package because the standardized data transmission allows the receiver to know what data transmission to expect and to how to handle the data transmission); and
sending the data package to the external system via the first communications interface (Grobler paragraphs 4 and 47, a diagnostic server supplies ECU parameters and receives testing error codes).
6. The method of Claim 1, further comprising storing the results of the testing of said each device in a memory of the computing unit (Chinnadurai paragraph 27, a real-time OS operates to server real-time application requests; these may perform diagnostic routines, diagnostic interpretation, and failure mode explanation; failure mode explanation in particular alludes to storing test results for explanation and the examiner takes official notice that it is well known in the art to store results so that they can be explained to a user).
7. The method of Claim 1, further comprising processing the results of the testing of said each device (Chinnadurai paragraph 27, a real-time OS operates to serve real-time application requests; these may perform diagnostic routines, diagnostic interpretation, and failure mode explanation).
9. The method of Claim 1, further comprising:
analyzing the test results while the testing is being performed (Chinnadurai paragraph 27, a real-time OS operates to server real-time application requests; these may perform diagnostic routines, diagnostic interpretation, and failure mode explanation); and
using the results of said analyzing as feedback for a next stage of the testing (Chinnadurai paragraph 27, diagnostic interpretation and failure mode explanation are performed; these are based on the test results and are a next stage of the testing process).
10. The method of Claim 1, further comprising integrating a third-party framework into the testing (Chinnadurai paragraph 28, different vehicle manufacturers may require the diagnostic tool to operate using different programs and communication protocols; the third-party manufacturer’s programs and protocols are considered a third-party framework).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai in view of Grobler, Parsons and Chang (PG-PUB 2017/0115370).
Chinnadurai in view of Grobler and Parsons discloses the method of claim 1. Chinnadurai in view of Grobler and Parsons does not expressly disclose the method further comprising setting a respective voltage level and a respective current level for testing components of said each device.
Chang teaches a vehicle diagnosing system in which a high voltage battery is diagnosed by determining whether a voltage variation in the battery exceeds a threshold value for a threshold period of time, and that a current sensor failure is determined by detecting that a current exceeds a threshold value when the load is not operating (paragraph 10).
Prior to the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the testing system disclosed by Chinnadurai in view of Grobler and Parsons such that vehicle battery is tested using diagnostic threshold voltage levels and current levels, as taught by Chang. This modification would have been obvious because batteries are used in vehicles (Chang paragraph 3) and, as would be clear to one of ordinary skill in the art, detecting a battery failure or a current sensor failure during testing will help prevent failure of the vehicle.
Claims 11-15 are rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai in view of Parsons and Gunter (PG-PUB 2024/0193059).
Regarding claim 11, Chinnadurai discloses a method executed by a computing unit in a test assembly (Figure 2, the diagnostic tool is part of a test system), the method comprising:
accessing a first test program and a second test program from a memory of the computing unit, wherein the first test program is associated with a first set of DUTs of the plurality of DUTs (Figure 2 and paragraph 27, a diagnostic tool run diagnostic routines to test a connected vehicle device) and the second test program is associated with a second set of DUTs of the plurality of DUTs;
selecting first and second operating systems of a plurality of operating systems residing in the memory of the computing unit, wherein the first operating system is compatible with a first type of device in the set of DUTs (paragraph 28, a vehicle diagnostic operating system Is run; the different manufacturers may require different programs and communication protocols, the tool determines whether it is running the correct software by comparing the vehicle type with the vehicle diagnostic operation system being run) and wherein the second operating system is compatible with a second type of device in the set of DUTs (paragraphs 27 and 28, the vehicle type must be compatible with the vehicle diagnostic operating system; since testing of multiple vehicle types is envisioned, the second type may require a second vehicle diagnostic operating systems);
executing the first test program on said each DUT in the first set of DUTs using the first operating system (paragraph 27, the vehicle diagnostic operating system includes diagnostic routines); and executing the second test program on said each DUT in the second set of DUTs using the second operating system (paragraphs 27 and 28, multiple types of vehicles are tested by compatible vehicle diagnostic operating systems, which may require a different vehicle diagnostic OS).
Chinnadurai does not expressly disclose the method wherein the computing unit is connected to a power distribution board in a test assembly; and the method comprising detecting connections between a plurality of devices under test (DUTs) and one or more test interface boards that are in a test rack and are communicatively coupled to the computing unit.
Parsons teaches a system that simultaneously performs testing on multiple mobile devices (paragraph 3). The devices are each associated with slots in a test frame (paragraph 22). The test system installs a test mobile device application on a particular mobile device under test (paragraphs 72-74) and obtains audio and video from connectors associated with a particular mobile device (paragraph 75).Prior to the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the testing system disclosed by Chinnadurai such that multiple devices are tested, and the testing method includes identifying a location of a device under test. This modification would have been obvious because simultaneous testing can increase test efficiency and save time (Parsons paragraph 133), and determining a device location allows receiving information from connected audio and video connectors (Parsons paragraphs 75 and 76).
Chinnadurai does not expressly disclose the method comprising mapping the test program to locations in the test rack of each DUT of the set of DUTs and mapping the second test program to locations in the test rack of DUTs of the second set of DUTs.
Gunter teaches a cabinet housing devices under test (see abstract). A testing computing device maintains a DUT table that maps each computing device to a USB port (paragraph 33) and a network address (paragraphs 20 and 36).Prior to the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the test system disclosed by Chinnadurai in view of Parsons such that a mapping structure is employed to identify devices associated with network address and USB port, as taught by Gunter. This modification would have been obvious because use of such a mapping allows each device under test to be recognized by a testing computing device based on its network address identified within the table (Gunter paragraph 20).
Chinnadurai in view of Parsons and Gunter also discloses:
12. The method of Claim 11, wherein the plurality of DUTs in the test rack comprises different types of devices having different form factors (Gunter paragraph 19, devices under test can be Apple computers, Windows computers, Mac laptops, Windows laptops, or any type of tablet), and wherein the method further comprises determining the type of device in the set of DUTs (Chinnadurai paragraph 28, vehicle type is determined; the vehicle type determines which diagnostic operating system to load and diagnostic test routines to run).
13. The method of Claim 11, further comprising providing context for said executing at least one of: the first test program (Chinnadurai paragraph 28, the diagnostic OS operates the computer device to perform various diagnostic tests, the OS provides a context or software environment for the testing) and the second test program.
14. The method of Claim 11, further comprising:
receiving results of testing the first and second sets of DUTs; and storing the results in the memory of the computing unit (Chinnadurai paragraph 27, a real-time OS operates to server real-time application requests; these may perform diagnostic routines, diagnostic interpretation, and failure mode explanation; failure mode explanation in particular alludes to storing test results for explanation and the examiner takes official notice that it is well known in the art to store results so that they can be explained to a user).
15. The method of Claim 11, further comprising:
receiving results of testing the first and second sets of DUTs; and processing, by a processor of the computer unit, the results (Chinnadurai paragraph 27, a real-time OS operates to server real-time application requests; these may perform diagnostic routines, diagnostic interpretation, and failure mode explanation).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Tung teaches testing electronic devices using test scripts specific to a specification of a CPU and a version of an operating system.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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.
This action is a final rejection and closes the prosecution of this application. Applicant’s reply under 37 CFR 1.113 to this action is limited to an appeal to the Patent Trial and Appeal Board, an amendment complying with the requirements set forth below, or a request for continued examination (RCE) to reopen prosecution where permitted. Please note that the Office also offers initiatives that are available to applicants after the close of prosecution. See https://www.uspto.gov/patents/initiatives/uspto-patent-applications-iniatives-timeline for more information.
General information on the Patent Trial and Appeal Board is available at: www.uspto.gov/patents/patent-trialand-appeal-board/about-ptab/new-ptab. The information at this page includes guidance on time limited options that may assist the applicant contemplating appealing an examiner’s rejection. It also includes information on pro bono (free) legal services and advice available for those who are under-resourced and considering an appeal at: https://www.uspto.gov/patents/patent-trial-and-appeal-board/patent-trial-and-appeal-board-pro-bono-programindependent.
The page is best reviewed promptly after applicant has received a final rejection or the claims have been twice rejected because some of the noted assistance must be requested within one month from the date of the latest rejection. See MPEP § 1204 for more information on filing a notice of appeal.
If applicant should desire to appeal any rejection made by the examiner, a Notice of Appeal must be filed within the period for reply. The Notice of Appeal must be accompanied by the fee required by 37 CFR 41.20(b)(1). The current fee amount is available at: www.uspto.gov/Fees.
If applicant should desire to file an after-final amendment, entry of the proposed amendment cannot be made as a matter of right unless it merely cancels claims or complies with a formal requirement made in a previous Office action. Amendments touching the merits of the application which otherwise might not be proper may be admitted upon a showing of good and sufficient reasons why they are necessary and why they were not presented earlier.
A reply under 37 CFR 1.113 to a final rejection must include cancellation of or appeal from the rejection of, each rejected claim. The filing of an amendment after final rejection, whether or not it is entered, does not stop the running of the statutory period for reply to the final rejection unless the examiner holds all of the claims to be in condition for allowance.
If applicant should desire to continue prosecution in a utility or plant application filed on or after May 29, 2000 and have the finality of this Office action withdrawn, an RCE under 37 CFR 1.114 may be filed within the period for reply. See MPEP § 706.07(h) for more information on the requirements for filing an RCE.
The application will become abandoned unless a Notice of Appeal, an after final reply that places the application in condition for allowance, or an RCE has been filed properly within the period for reply, or any extension of this period obtained under either 37 CFR 1.136(a) or (b).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH SCHELL whose telephone number is (571) 272-8186. The examiner can normally be reached on Monday through Friday 9AM-5:00PM (Pacific 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. Please note that all agendas or related documents that Applicant would like reviewed should be sent at least one full business day (i.e. 24 hours not including weekends or holidays) before the interview.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ashish Thomas can be reached at (571) 272-0631. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. The fax phone number for the examiner is 571-273-8186. The examiner may be e-mailed at joseph.schell@uspto.gov though communications via e-mail are not permitted without a written authorization form (see MPEP 502.03).
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JS/JOSEPH O SCHELL/Primary Examiner, Art Unit 2114