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 .
Response to Amendment
This communication is in response to the amendment filed 11/28/2025. The amendment has been entered and considered.
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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-4, 7-11, 14-17 and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. Patent No. 11,553,363. Although the claims at issue are not identical, they are not patentably distinct from each other because they put forth sending an instruction to a vehicle to cause it to execute instructions to perform a diagnostic test so as to measure and report the timing results.
Continuation US 11,553,363
1. A computer system for evaluating data transmission capabilities of a vehicle, the vehicle having a plurality of sub-systems for operating the vehicle and a vehicle controller, the vehicle controller including at least one processor in communication with at least one memory device, the at least one processor configured to: receive wirelessly from a standard data transmission location network device located along a route of a trip traveled by the vehicle, an evaluation data packet containing instructions for at least one of the plurality of sub-systems, wherein the instructions include computer-executable code for a simulation model; initiate, while traveling along the route, a diagnostic test using the instructions for the simulation model, wherein the executed instructions cause the at least one processor to initiate a simulation that triggers the at least one sub-system to perform an action; measure a response time associated with the at least one sub-system to execute the diagnostic test; and record the response time of the at least one sub-system for completing the diagnostic test, wherein the response time includes a time period between the initiation of the diagnostic test and the completion of the diagnostic test.
2. The computer system of claim 1, wherein the at least one processor is further configured to: decode the evaluation data packet to identify the at least one sub-system and the instructions; and determine the diagnostic test to conduct on the vehicle based on the decoded evaluation data packet.
3. The computer system of claim 1, wherein the instructions further include activating the at least one sub-system.
4. The computer system of claim 1, wherein the at least one processor is further configured to initiate the diagnostic test by transmitting an operating command to the at least one sub-system in response to executing the received instructions.
7. The computer system of claim 1, wherein the evaluation data packet instructions further cause the at least one processor to simulate an obstacle proximate to the vehicle¸ wherein the obstacle is one of a virtual pedestrian and a virtual vehicle.
All other claims 8 thru 20 are same similar as above (unless discusseed below).
1. A computer system for evaluating data transmission capabilities of an autonomous vehicle, the vehicle having a plurality of sub-systems for operating the vehicle and a vehicle controller, the vehicle controller including at least one processor in communication with at least one memory device, the at least one processor programmed to: embark the vehicle upon a trip defined by a route; receive, subsequent to embarking upon the trip, wirelessly from a standard data transmission location network device located along the route, an evaluation data packet containing instructions for at least one of the plurality of sub-systems; decode the evaluation data packet to identify the at least one sub-system and the instructions, wherein the instructions include computer-executable code for a simulation model; determine a type of diagnostic test to conduct on the vehicle based on the decoded evaluation data packet; initiate, while traveling along the route, the type of diagnostic test based on the instructions, including (i) activating the identified at least one sub-system and (ii) executing the simulation model, wherein the executed simulation model causes the at least one processor to simulate a situation that triggers the at least one sub-system to perform an action; in response to the simulated situation, transmit an operating command to the at least one sub-system; measure a response time required by the at least one sub-system to complete execution of the operating command; transmit the measured response time to the standard data transmission location network device, wherein transmitting the measured response time to the standard data transmission location network device causes the standard data transmission location network device to transmit the measured response time to a central server, wherein the central server is configured to determine if the measured response time exceeds a threshold, and transmit further instructions to the vehicle to alter operation of the vehicle; and record measurements of a communication system of the vehicle during activation of the communication system, wherein recording the measurements includes measuring a time period between initiation of the type of diagnostic test and completion of the type of diagnostic test.
2. The computer system of claim 1, wherein the evaluation data packet includes computer instructions to test the communication system of the vehicle, and the at least one processor is further programmed to initiate a further diagnostic test of the communication system of the vehicle.
3. The computer system of claim 2, wherein the further diagnostic test of the communication system includes activating the communication system.
4. The computer system of claim 1, wherein the at least one processor is further programmed to transform the evaluation data packet into a transformed evaluation data packet based upon the evaluation data packet and the measurements.
5. The computer system of claim 1, wherein the simulation model further causes the at least one processor to simulate the situation as an obstacle, wherein the obstacle is one of a virtual pedestrian and a virtual other vehicle.
Claims 5, 12 and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. Patent No. 11,553,363 and further in view of {Nygaard et al. US 9,836,895 or Kong et al. US 2018/0088576 or Zhu et al. US 2018/0143632}.
The ‘363 patent teaches the entire claim but is silent on wherein the at least one processor is further configured to transmit the response time to the standard data transmission location network device for further evaluation; and receive further instructions from the standard data transmission location network in response to the further evaluation, the further instructions configured to alter the operation of the vehicle, wherein transmitting the response time to the standard data transmission location network device causes the standard data transmission location network device to transmit the response time to a central server, and wherein the central server is configured to determine when the response time exceeds a threshold and then transmit the further instructions to the vehicle to alter operation of the vehicle.
Chou teaches determining if the test data is within limits/thresholds (C9, L13-21) AND Nygaard or Kong or Zhu (see rejection below) teach a test can be remotely initiated and monitored and information is sent for evaluation.
It would have been obvious to one skilled in the art at the time of the invention's filing date, to modify the ‘363 patent, such that wherein the at least one processor is further configured to transmit the response time to the standard data transmission location network device for further evaluation; and receive further instructions from the standard data transmission location network in response to the further evaluation, the further instructions configured to alter the operation of the vehicle, wherein transmitting the response time to the standard data transmission location network device causes the standard data transmission location network device to transmit the response time to a central server, and wherein the central server is configured to determine when the response time exceeds a threshold and then transmit the further instructions to the vehicle to alter operation of the vehicle, to provide the ability to monitor/test that vehicle sub-systems are operating within normal thresholds (for safety purposes, maintenance, etc.).
Claims 6, 13 and 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. Patent No. 11,553,363 and further in view of Chou et al. US 6,330,499.
The ‘363 patent teaches the entire claim but is silent on wherein the plurality of sub-systems include mechanical sub-systems and navigation sub-systems.
At least Chou teaches the ability to teach literally ANY sub-system since he does not limit his disclosure to specific sub-systems, hence mechanical and navigational sub-systems would be able to be tested:
(5) Motor vehicles contain complex mechanical systems that are monitored and regulated by computer systems such as electronic control units (ECUs) and the like.
(6) Such ECUs monitor various components of the vehicle including engine performance, carburation, speed/acceleration control, transmission, exhaust gas recirculation (EGR), braking systems, etc. (C1, L10-17)
(79) While the invention has been described in terms of several preferred embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims. (C10, L12-15)
It would have been obvious to one skilled in the art at the time of the invention's filing date, to modify the ‘363 patent, such that wherein the plurality of sub-systems include mechanical sub-systems and navigation sub-systems, to provide the ability to monitor any/all vehicle sub-systems (for safety purposes, maintenance, etc.).
NOTE: See also Odinak or Breed, pertinent but not cited.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chou et al. US 6,330,499 and further in view of Nou US 2006/0122748 and {Nygaard et al. US 9,836,895 or Kong et al. US 2018/0088576 or Zhu et al. US 2018/0143632} and Pitt et al. US 2018/0276910.
As per claim 1, Chou et al. US 6,330,499 teaches a computer system for evaluating data transmission capabilities of a vehicle, the vehicle having a plurality of sub-systems for operating the vehicle and a vehicle controller, the vehicle controller including at least one processor in communication with at least one memory device, the at least one processor configured to and in response to the vehicle traveling in an “area” that includes communications (i.e. a data transmission area/location): (See figures 1-3 which show the overall system and the vehicle/diagnostic center which communicate status/evaluation information):
receive an evaluation data packet containing instructions for at least one of the plurality of sub-systems AND wherein the instructions include computer-executable code for a “health checkup” (e.g. simulation model) AND, a diagnostic test using the instructions for the health checkup (simulation model), wherein the executed instructions cause the at least one processor to initiate a health checkup (simulation) that triggers the at least one sub-system to perform an action AND wherein the evaluation data packet/trigger is configured to cause the vehicle to perform a diagnostic test of the vehicle (Chou teaches that the driver can initiate a health checkup and the results are wirelessly sent to a service center, which reads on the limitation of an evaluation packet/signal/trigger to cause diagnostic testing of the vehicle to commence):
(23) Further, the client computer device may initiate a remote health checkup upon a user request. The driver or user may request a comprehensive, remote health checkup if the driver or user feels that the vehicle is behaving abnormally, is alerted by the application of potential trouble, or simply wants to get a checkup before a long trip. (C4, L62-67)
(24) The in-vehicle system establishes a data connection, using a cellular phone 102, with a diagnostic server 201 at the service center 200, collects diagnostic data using the diagnostic data service 120A, and uploads a snapshot of the vehicle data (e.g. VIN, test data with time-stamp) to the diagnostic server 201. The in-vehicle system may need to interact with the server 201 throughout a diagnosis or health checkup session, collecting and providing additional vehicle information as requested by the server 201. The result from the server 201 indicates either that the vehicle is in good health with no urgent action required, or that one or more problems requiring immediate attention are detected. (C5, L1-11)
measure a “diagnostic data” associated with the at least one sub-system to execute the diagnostic test AND record the “diagnostic data” of the at least one sub-system for completing the diagnostic test (See above, C4, L62-67 and C5, L1-11 that teach performing the remote health checkup and reporting the diagnostic data to the service center). Also see:
“...Then, the diagnostic client 421 initiates a diagnosis session with the diagnostic server 201 (step 6). The diagnostic client 421 passes the fault codes, vehicle identification and other relevant information to the server 201”. From C8, L14-22
In step 7, the diagnostic server requests additional information (e.g. vehicle parametric data) from the diagnostic client 421. Then, in step 8, the diagnostic client requests the data from the diagnostic data service 120A. C8, L22-25
Then, in step 10, the ECUs 103 provides the requested data. In step 11, the data is returned to the diagnostic client 421, and thereafter, in step 12, the data is in turn transmitted to the diagnostic server 201. Steps 7 through 12 may be repeated to obtain all of the relevant vehicle data. C8, L25-33
But is silent on
(The SDTL) network device, which is selected, detecting the vehicle in the evaluation area, initiate a diagnostic test of the vehicle,
While traveling in the evaluation area, cause the diagnostic test of the vehicle to be run by executing the simulation model,
(receive) wirelessly from a standard data transmission location (SDTL) network device located in an evaluation area (to initiate the simulation/test),
measure a response time (for the test) AND record the response time for completing the diagnostic teaches, wherein the response time includes a time period between the initiation of the diagnostic test and the completion of the diagnostic test.
It appears that Chou does not have the remote site “initiate” a test so that measurements can be collected/sent (which would be more akin to actively triggering the diagnostics). Chou appears to be more passive where the data had already been collected and it is merely uploaded when requested by the remote service center. That said, note that Chou teaches “…In step 18, the service representative may use this newly provided information and reinvoke the diagnostic server 201 to investigate the problem further” [C8, L33-64] which can be broadly interpreted as the remote center triggering further (or real-time) diagnostic testing/reporting. Also see (See Chou’s Figure 3 where there is a Diagnostic Client #421 and a Fault Detector #1208 which gather/report diagnostic data regarding various systems/sub-systems on the vehicle) .
Chou teaches: The in-vehicle system establishes a data connection, using a cellular phone 102, with a diagnostic server 201 at the service center 200, collects diagnostic data using the diagnostic data service 120A, and uploads a snapshot of the vehicle data (e.g. VIN, test data with time-stamp) to the diagnostic server 201. The in-vehicle system may need to interact with the server 201 throughout a diagnosis or health checkup session, collecting and providing additional vehicle information as requested by the server 201. The result from the server 201 indicates either that the vehicle is in good health with no urgent action required, or that one or more problems requiring immediate attention are detected. C5, L1-11
With regard to “…(receive) wirelessly from a standard data transmission location network device located in an evaluation area (to initiate the simulation/test)..”, at least Nou US 2006/0122748 teaches the initiation of a diagnostic test and recording of the measurements of the device/vehicle during the diagnostic test (See figure 3 which shows remote requesting for a diagnostic of vehicle/telematics information #313 and the transmitting of the vehicle diagnostic information #315 which is sent to the service providing center/communication terminal and reads on an active step of the vehicle receiving a request for diagnostic testing and then performing/recording/sending of the results to the remote center/rep while travelling in an (evaluation) area or route, etc.), which reads on the evaluation packet containing instructions to initiate testing for a sub-system(s) and identification of a sub-system(s) and transmitting an operating command to the sub-system(s) at or in a specific area or location. Regarding the selection of the SDTL device, there is only one device thus the “Selection” carries no weight because there is nothing to select from.
It would have been obvious to one skilled in the art at the time of the invention's filing date, to modify Chou, such that it receives wirelessly from a standard data transmission location network device located in an evaluation to initiate the simulation/test, to provide the ability for a remote service center to trigger monitoring/collecting/sending of vehicle health/test data to the remote service center for processing (and fixing of any identified problems) while the vehicle is in an area, along a route, etc..
The prior art above is silent on “…measure a response time (for the test) AND record the response time for completing the diagnostic teaches, wherein the response time includes a time period between the initiation of the diagnostic test and the completion of the diagnostic test..”. The examiner interprets this to mean the time it takes for the the command to be sent plus the time it takes to perform the operation/test and then the time to send that information back. Several references teach sending a command to an autonomous vehicle and determining a response time – adding this concept to the above references leads one skilled to arrive at the applicant’s limitation of a diagnostic test command that can be measured for response time.
See Nygaard or Kong or Zhu below:
Nygaard et al. US 9,836,895 teaches testing the behavior, dynamics and RESPONSE TIME of an autonomous vehicle in various scenarios – which can be likened to a diagnostic test, ie. to see how one/more sub-systems operate (as based on command(s) sent to the vehicle to make it perform operations/tests):
The technology relates to testing the behavior, dynamics and response time of autonomous vehicles in various scenarios. When testing autonomous vehicles, it can be difficult, expensive and even dangerous to set up certain real-life scenarios. For example, it would be inherently dangerous to test the situation of a jaywalker using a real person and could be expensive (and even dangerous) to use a dummy or other object. Typical simulations may involve offline testing of an autonomous vehicle's computers in a lab setting, but these simulations may rely too much of computer estimates of how the vehicle would drive on a physical road, thus lacking some aspects of unpredictability in the response of an actual physical vehicle. In this regard, it can very helpful to test an autonomous vehicle in various scenarios on actual roadways using virtual objects. (C2, L40-58)
Kong et al. US 2018/0088576 teaches issusing a command (ie. steering, etc.) and determining the delay from the time it was sent to the time a response is received (which could be merely a test and not when the car is actually moving). Kong also teaches the ability to program/define a route (from start to destination) that the vehicle will drive (See Para’s 33-35 and opening remarks in this Office Action):
[0019] In one embodiment, a steering control delay is measured, where the steering delay represents the delay between the time of issuing a steering control command and the time of a response received from one or more wheels of an autonomous vehicle. A speed control delay is measured between the time of issuing a speed control command and the time of a response received from one or more wheels of the autonomous vehicle or the time of supplying a pressure to the gas pedal or brake pedal. In response to a given route subsequently, an overall system delay is determined based on the steering control delay and the speed control delay using a predetermined algorithm. Planning and control data is generated in view of the system delay for operating the autonomous vehicle.
Zhu et al. US 2018/0143632 teaches a command delay that refers to the time delay beween issuing a driving command and the time it takes for a response from the vehicle, which is the same/simliar. Zhu also teaches the ability to program/define a route (start to destination) that the vehicle will drive:
[0042] In one embodiment, machine learning engine 411 generates command delay predictive model or command delay determination algorithm 432. Command delay predictive model or algorithm 432 can be utilized by command delay determination module 413 to predict or determine a command delay for a particular type of autonomous vehicles. A command delay refers the time delay between the time of issuing a driving command (e.g., throttle, brake, steering commands) and the time of a response of the vehicle. A delay for a different command may be different. For example, a delay for a throttle command may be different than a delay for a brake command or a steering command. In one embodiment, command delay determination module 413 includes throttle delay determination module 421, brake delay determination module 422, a steering delay determination module (not shown) to determine the delays for a throttle command, a brake command, or a steering command, respectively.
It would have been obvious to one skilled in the art at the time of the invention's filing date, to modify the prior art, such that it measures a response time (for the test) AND records the response time for completing the diagnostic teaches, wherein the response time includes a time period between the initiation of the diagnostic test and the completion of the diagnostic test, to provide the ability to understand how quickly the subsystems respond to vehicle tests to ensure the vehicle can be operated safely in actual (or simulated) driving conditions.
With regard to “..(The SDTL) network device detecting the vehicle in the evaluation area, initiate a diagnostic test of the vehicle AND while traveling in the evaluation area, cause the diagnostic test of the vehicle to be run by executing the simulation model..”, Pitt et al. US 2018/0276910 teaches detecting that a vehicle has entered an evaluation area and performing diagnostic tests as per a test plan/simulation model, etc., which reads on the limitations. (NOTE that Pitt teaches “as the vehicle travels within the controlled environment test facility” – Abstract)
[0060] In some embodiments, as the vehicle 12 enters the test area 200, communication between the controller 22 of the vehicle 12, the remote access center 78, and/or the control system 250 of the test area 200 establish the test sequence to be performed. The selected test sequence may be based on vehicle identification (VIN), vehicle mileage, or sensor error codes logged by the controller 22, as discussed in greater detail below. Based on the selected test sequence, in some embodiments, the control system 250 activates and deactivates the arms 203, 205, 207 and the displays 217, 227, 238. In some embodiments, activation of the arms 203, 205, 207 and the displays 217, 227, 238, is based on detection of the location of the vehicle 12 along the tracks 202, 204. In some embodiments, activation of the sensors 26 is based on the location of the vehicle 12 along the tracks 202, 204, the selected test sequence, or the sensors 26 are activated to simulate normal operation of the vehicle 12 (that is, when the vehicle 12 is traveling along a road or highway under normal operating conditions).
It would have been obvious to one skilled in the art at the time of the invention’s filing date, to modify the combo, such that (The SDTL) network device detecting the vehicle in the evaluation area, initiate a diagnostic test of the vehicle AND while traveling in the evaluation area, cause the diagnostic test of the vehicle to be run by executing the simulation model, to provide the ability to have specific location areas that can perform testing of the vehicle when the vehicle enters those areas.
EXAMINER’s NOTE: If the examiner gives highly detailed technical meaning to the word “simulation” AND “the response time is based on the simulation”, Nygaard, Kong or Zhu also teach the ability to test/monitor for a real or simulated situation (eg. pedestrian, vechicle, etc.) whereupon the vehicle can perform a response, such as using sub-systems to stop, steer around, etc.:
Nygaard states that it can be both expensive and dangerous to use REAL obstacles (such as a person/jaywalker) to test the vehicle’s response time, hence one skilled would use a simulated person/vehicle to test response times:
(14) The technology relates to testing the behavior, dynamics and response time of autonomous vehicles in various scenarios. When testing autonomous vehicles, it can be difficult, expensive and even dangerous to set up certain real-life scenarios. For example, it would be inherently dangerous to test the situation of a jaywalker using a real person and could be expensive (and even dangerous) to use a dummy or other object. Typical simulations may involve offline testing of an autonomous vehicle's computers in a lab setting, but these simulations may rely too much of computer estimates of how the vehicle would drive on a physical road, thus lacking some aspects of unpredictability in the response of an actual physical vehicle. In this regard, it can very helpful to test an autonomous vehicle in various scenarios on actual roadways using virtual objects. (C2, L43-57)
Zhu teaches the vehicle having computer vision that can capture various objects such as roadway obstacles, pedestrians, other vehicles, etc.. Applying Zhu’s teaching to an autonomous vehicle, one skilled sees that response times to avoid the object can be tested/simulated:
[0034] Perception module 302 may include a computer vision system or functionalities of a computer vision system to process and analyze images captured by one or more cameras in order to identify objects and/or features in the environment of autonomous vehicle. The objects can include traffic signals, road way boundaries, other vehicles, pedestrians, and/or obstacles, etc. The computer vision system may use an object recognition algorithm, video tracking, and other computer vision techniques. In some embodiments, the computer vision system can map an environment, track objects, and estimate the speed of objects, etc. Perception module 302 can also detect objects based on other sensors data provided by other sensors such as a radar and/or LIDAR.
Kong teaches similar computer vision concepts and one skilled sees the ability to test response times for objects in the roadway:
[0029] Computer vision unit or system 204 is to process and analyze images captured by one or more cameras 211 in order to identify objects and/or features in the environment of autonomous vehicle. The objects can include traffic signals, road way boundaries, other vehicles, pedestrians, and/or obstacles, etc. Computer vision system 204 may use an object recognition algorithm, video tracking, and other computer vision techniques. In some embodiments, computer vision system 204 can map an environment, track objects, and estimate the speed of objects, etc.
Also note that Nygaard can “send” simulation data to the vehicle so that simulation scenarios can be run whereupon the autonomous vehicle’s computers can respond to the virtual objects (these scenarios would either be pre-stored or transmitted – Figures 8/9 show at least a pedestrian/vehicle simulation):
(19) As the autonomous vehicle is driving along a roadway in an autonomous driving mode as shown in FIG. 7, the fictitious sensor data may be provided to the autonomous vehicle's computer at the appropriate time in order to run the scenario as shown in FIGS. 8 and 9. By doing so, the autonomous vehicle's computers may respond as if the virtual objects were real objects. (C3, L32-39)
For example, the perception system may detect and identify virtual pedestrian 850 in the crosswalk 630, and virtual car 860 entering the intersection 602 from the lane 672. The virtual pedestrian 850 and the virtual car 860 may be executing a behavior plan as part of a predefined scenario. (C9, L15-21)
Thusly, taken in total, one skilled sees that different vehicle subsystems can be tested (on a defined route) by running different virtual scenarios that simulate real-world conditions, ie. such as testing the braking by having a pedestrian walk out in front of the car’s path OR testing the steering by having the vehicle avoid debris in the vehicle’s path OR even testing the navigation system by putting up a virtual roadblock and causing a re-route, etc.. All scenarios can be either pre-stored OR sent from the monitoring facility (Chou teaches sending packets to the vehicle (ie. to test), as does Nou and Nygaard teaches perhaps a more “pre-stored” method. Clearly a choice in design exists as to how the scenario gets to the vehicle (transmitted or pre-stored) which are obvious to try modifications with predicted results being the outcome.
As per claims 2, 9 and 16, the combo teaches claim 1/8/15,
wherein the at least one processor is further configured to:
decode the evaluation data packet to identify the at least one sub-system and the instructions; and
determine the diagnostic test to conduct on the vehicle based on the decoded evaluation data packet (Chou teaches a test of the vehicle whereby the results are sent to the remote service center. The “test” initiated by the user (or remote service center if more data is to be gathered) would include a command/evaluation packet that identifies WHAT is to be tested and then the specific test is conducted on the vehicle based on said command/evaluation packet).
As per claims 3 and 10, the combo teaches claim 1/8, wherein the instructions further include activating the at least one sub-system (See above, Chou teaches performing tests on the vehicle which requires the activation/operation/monitoring of at least one sub-system).
As per claims 4, 11 and 17, the combo teaches claim 1/8/15, wherein the at least one processor is further configured to initiate the diagnostic test by transmitting an operating command to the at least one sub-system in response to executing the
As per claims 5, 12 and 18, the combo teaches claim 1/8/15, wherein the at least one processor is further configured to “generically” perform the following steps:
Transmit test result data to a remote service center whereupon said remote service center evaluates the data and there can be further testing of the vehicle if deemed necessary by said remote service center’s central server/technical personnel (i.e. if the initial test results are not inline with normal operating thresholds/limits) – See Chou above/previous:
(68) The diagnostics server 201 retrieves vehicle information from the data repository 203 and compares the data from the vehicle with the repository data. Then, the diagnostic server 201 prepares a report listing any out-of-range parameters and actions required (e.g., "coolant level is low"). Trend analysis on the parameters may also be performed, based on the present and historical data collected from the vehicle, to detect any drifting of the performance characteristics and to provide early guidance for preventive maintenance (e.g., "change oil in 1500 miles") (C9, L13-21)
but is silent on
transmit the response time to the standard data transmission location SDTL network device for further evaluation; and
receive further instructions from the standard data transmission location SDTL network in response to the further evaluation, the further instructions configured to alter the operation of the vehicle,
wherein transmitting the response time to the standard data transmission location SDTL network device causes the standard data transmission location network device to transmit the response time to a central server, and
wherein the central server is configured to determine when the response time exceeds a threshold and then transmit the further instructions to the vehicle to alter operation of the vehicle.
Note that Nygaard, Kong or Zhu teach a remote site/server initiating the test and response times are sent to the remote site/server for evaluation and understanding if the response is within (or exceeds) operational thresholds/limits (see previous/above that put forth the specifics for the tests to include “response times” AND alter the vehicle operation, e.g. avoid obstacles, brake, steer, stop, increase/decrease speed, etc.).
It would have been obvious to one skilled in the art at the time of the invention's filing date, to modify the combo, such that it transmits the response time to the standard data transmission location network device for further evaluation AND receives further instructions from the standard data transmission location network in response to the further evaluation, the further instructions configured to alter the operation of the vehicle AND wherein transmitting the response time to the standard data transmission location network device causes the standard data transmission location network device to transmit the response time to a central server AND wherein the central server is configured to determine when the response time exceeds a threshold and then transmit the further instructions to the vehicle to alter operation of the vehicle, to provide the ability to evaluate the test results as being normal or outside operating limits/thresholds.
As per claims 6, 13 and 19, the combo teaches claim 1/8/15, wherein the plurality of sub-systems includes mechanical sub-systems and navigation sub-systems (Chou teaches the ability to teach literally ANY sub-system since he does not limit his disclosure to specific sub-systems, hence mechanical and navigational sub-systems would be able to be tested).
(5) Motor vehicles contain complex mechanical systems that are monitored and regulated by computer systems such as electronic control units (ECUs) and the like.
(6) Such ECUs monitor various components of the vehicle including engine performance, carburation, speed/acceleration control, transmission, exhaust gas recirculation (EGR), braking systems, etc. (C1, L10-17)
(79) While the invention has been described in terms of several preferred embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims. (C10, L12-15)
Odinak US 2005/0065779, pertinent but not cited, also teaches monitoring of generic sub-systems on a vehicle, which would include a navigation sub-system as well, which reads on mechanical, navigational, etc..:
[0243] The communication controller 210 also receives information from a monitoring device 250. The monitoring device 250 can be in one of any number of forms depending on the nature of the remote station. For example, if the remote station is an automobile, the monitoring device 250 may be an automobile monitoring computer. The automobile monitoring computer can be configured to monitor the operation of the automobile's systems. If the automobile monitoring system detects that a fault is about to occur or has occurred, the automobile monitoring computer can relay that information to the communication controller 210.
Breed US 2005/0125177 pertinent but not cited, also teaches monitoring of any/all vehicle sub-systems, e.g. mechanical, navigational, etc.:
[0083] The diagnostic module may derive diagnostic data from data about the monitored components provided by the sensors of the vehicle monitoring system, e.g., an indication of a potential failure of one of the components of the vehicle. A user interactive device, such as a display, may be coupled to and controlled by the diagnostic module such that a message about the component failure may be provided to the driver or other vehicle occupant.
[0087] A method for information management and monitoring of a plurality of vehicles in accordance with the invention is designed for manufacturers and other parties interested in statistical failure of vehicle components and includes arranging a vehicle monitoring system including a plurality of sensors on each vehicle to monitor components of the vehicle, arranging a diagnostic module on each vehicle, directing data about the monitored components from the vehicle monitoring system to the diagnostic module for analysis and processing thereby, coupling a communication system on each vehicle to the diagnostic module, establishing communications between the diagnostic module and a data gathering facility which accumulates information about the failure rate of the components to enable transmission of data between the diagnostic module and the data gathering facility such that the data gathering facility receives data about the monitored components of the vehicle, and accumulating date from the vehicle at the data gathering facility to enable calculation of statistics about failure rate of the components.
As per claims 7, 14 and 20, the combo teaches claim 1/8/15, but is silent on wherein the evaluation data packet instructions further cause the at least one processor to simulate an obstacle proximate to the vehicle¸ wherein the obstacle is one of a virtual pedestrian and a virtual vehicle.
Nygaard states that it can be both expensive and dangerous to use REAL obstacles (such as a person/jaywalker) to test the vehicle’s response time, hence one skilled would use a simulated person/vehicle to test response times:
(14) The technology relates to testing the behavior, dynamics and response time of autonomous vehicles in various scenarios. When testing autonomous vehicles, it can be difficult, expensive and even dangerous to set up certain real-life scenarios. For example, it would be inherently dangerous to test the situation of a jaywalker using a real person and could be expensive (and even dangerous) to use a dummy or other object. Typical simulations may involve offline testing of an autonomous vehicle's computers in a lab setting, but these simulations may rely too much of computer estimates of how the vehicle would drive on a physical road, thus lacking some aspects of unpredictability in the response of an actual physical vehicle. In this regard, it can very helpful to test an autonomous vehicle in various scenarios on actual roadways using virtual objects. (C2, L43-57)
Zhu teaches the vehicle having computer vision that can capture various objects such as roadway obstacles, pedestrians, other vehicles, etc.. Applying Zhu’s teaching to an autonomous vehicle, one skilled sees that response times to avoid the object can be tested/simulated:
[0034] Perception module 302 may include a computer vision system or functionalities of a computer vision system to process and analyze images captured by one or more cameras in order to identify objects and/or features in the environment of autonomous vehicle. The objects can include traffic signals, road way boundaries, other vehicles, pedestrians, and/or obstacles, etc. The computer vision system may use an object recognition algorithm, video tracking, and other computer vision techniques. In some embodiments, the computer vision system can map an environment, track objects, and estimate the speed of objects, etc. Perception module 302 can also detect objects based on other sensors data provided by other sensors such as a radar and/or LIDAR.
Kong teaches similar computer vision concepts and one skilled sees the ability to test response times for objects in the roadway:
[0029] Computer vision unit or system 204 is to process and analyze images captured by one or more cameras 211 in order to identify objects and/or features in the environment of autonomous vehicle. The objects can include traffic signals, road way boundaries, other vehicles, pedestrians, and/or obstacles, etc. Computer vision system 204 may use an object recognition algorithm, video tracking, and other computer vision techniques. In some embodiments, computer vision system 204 can map an environment, track objects, and estimate the speed of objects, etc.
Also note that Nygaard can “send” simulation data to the vehicle so that simulation scenarios can be run whereupon the autonomous vehicle’s computers can respond to the virtual objects (these scenarios would either be pre-stored or transmitted – Figures 8/9 show at least a pedestrian/vehicle simulation):
(19) As the autonomous vehicle is driving along a roadway in an autonomous driving mode as shown in FIG. 7, the fictitious sensor data may be provided to the autonomous vehicle's computer at the appropriate time in order to run the scenario as shown in FIGS. 8 and 9. By doing so, the autonomous vehicle's computers may respond as if the virtual objects were real objects. (C3, L32-39)
For example, the perception system may detect and identify virtual pedestrian 850 in the crosswalk 630, and virtual car 860 entering the intersection 602 from the lane 672. The virtual pedestrian 850 and the virtual car 860 may be executing a behavior plan as part of a predefined scenario. (C9, L15-21)
Thusly, taken in total, one skilled sees that different vehicle subsystems can be tested (on a defined route) by running different virtual scenarios that simulate real-world conditions, ie. such as testing the braking by having a pedestrian walk out in front of the car’s path OR testing the steering by having the vehicle avoid debris in the vehicle’s path OR even testing the navigation system by putting up a virtual roadblock and causing a re-route, etc.. All scenarios can be either pre-stored OR sent from the monitoring facility (Chou teaches sending packets to the vehicle (ie. to test), as does Nou and Nygaard teaches perhaps a more “pre-stored” method.
It would have been obvious to one skilled in the art at the time of the invention's filing date, to modify the combo, such that wherein the evaluation data packet instructions further cause the at least one processor to simulate an obstacle proximate to the vehicle¸ wherein the obstacle is one of a virtual pedestrian and a virtual vehicle, to provide the ability for the simulations to verify the vehicle’s operation in real-world situations, such as with pedestrians, obtacles, etc..
As per claim 8, this claim is rejected in its entirety as based on the rejection of claim 1. Furthermore, Chou teaches a computer-implemented method for evaluating data transmission capabilities of a vehicle, the method implemented using a vehicle controller including at least one processor in communication with at least one memory device, the method comprising the steps performed in the claim (See Figure 1 showing the system components, Figure 2 showing the in-vehicle hardware – processor #300 performs the method steps and memory #350 can store the instructions, test results, etc.).
As per claim 15, this claim is rejected in its entirety as based on the rejection of claim 1. Furthermore, Chou teaches at least one non-transitory computer-readable storage media having computer-executable instructions embodied thereon, wherein when executed by at least one processor associated with a vehicle that is in communication with at least one memory device, the computer-executable instructions cause the at least one processor to perform the steps performed in the claim (See Figure 1 showing the system components, Figure 2 showing the in-vehicle hardware – processor #300 performs the method steps and memory/CRM #350 can store the instructions, test results, etc.).
Response to Arguments
Applicant's arguments filed 11/28/2025 have been fully considered but they are not persuasive.
Regarding the ind. claims, applicant argues the combination of references fails to teach the independent claims because the health checkup of Chou (or any other reference) is not a simulation model being executed by a diagnostic test of a vehicle.
The Examiner respectfully disagrees. Regarding the amended limitation, the Examiner suggests better defining the selection of the SDTL from the central server. The Examiner suggest defining there to be a plurality of SDTL and then define the criteria that causes the central server to select a specific SDTL. In the event there is only one SDTL, the selection step has no weight because there is only one SDTL, thus that SDTL is the one performing the functions. Regarding the simulation, it is not Chou that is relied upon actually performing the simulation. As shown in the rejection, it is Pitt that discusses the actual simulation of the vehicle based on received information when the vehicle enters the test area; Paragraph 60. Paragraphs 68 and 70 also disclose simulations being performed with respect to road hazards. Therefore, the combination of references is proper.
As noted in the arguments, further details regarding the selection of the SDTL, by the centralized server, would overcome the cited art of record.
Conclusion
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 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 BRANDON M RENNER whose telephone number is (571)270-3621. The examiner can normally be reached Monday-Friday 7am-5pm EST.
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, Derrick Ferris can be reached at (571)-272-3123. 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.
/BRANDON M RENNER/Primary Examiner, Art Unit 2411
Prosecution Insights