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 .
Status of claims
Claims 1-20 are pending
Claims 1, 2, 4, 6, 7, 8, 9, 11, 13-20 are amended
Response to Arguments
35 U.S.C.103 Rejection
To clarify arguments for rejection, the SAIGUSA reference within claims 1-20 has been replaced by the new WORMAN reference.
Regarding applicant’s arguments the GAO does not teach bail thresholds, the applicant respectfully disagrees. From the specification, the function of the bail threshold is described in ¶ 0003 as “based on headway or time-to-collision is satisfied, then the automated vehicle safely aborts to avoid a potential collision”. In the broadest reasonable interpretation of the given claims, a bail threshold could be an emergency abort of a test task based on the calculated time to collision as described in GAO ¶ 0036 (“When there is a high risk (e.g., the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the vehicle protection system 120 to brake the test vehicle 101. The vehicle protection system 120 brakes the test vehicle 101 in a timely manner, for example, to cause the test vehicle 101 to exit the autonomous driving state.”).
Regarding the argument that GAO “would not be suitable for use in a real-world, live driving session” due to GAO being intended for “fine-tuning a vehicle [...] before the vehicle is deployed in real-world”, the examiner respectfully disagrees. GAO is directed towards the automated testing of autonomous vehicles and the prevention of accidents during testing on a test track (GAO, ¶ 0030). A person of ordinary skill in the art would recognize that a test track setting would be a controlled “real-world” driving environment.
Please see 35 U.S.C. §103 rejection below.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 6, 7, 8, 13-15, and 28-20 are rejected under 35 U.S.C. 103 as being unpatentable over WORMAN (US 20230038486 A1)in view of GAO (CN 111323238 A).
Regarding claim 1:
WORMAN discloses:
A computer-implemented method comprising: executing, by a computer, a user-configurable test tool, the user-configurable test tool including a user interface configured to display test parameters corresponding to a testing scenario for testing of an autonomous vehicle; (see at least WORMAN, ¶ 0026, “The test configuration is received from a test facility gateway that is communicatively coupled to the test facility control system. In at least some embodiments, the test configuration specifies a plurality of states or operations of one or more test environment devices; however, in one embodiment, the test configuration specifies a single state or operation of one of the test environment devices. The test facility gateway is configured to receive test configuration information from a test facility user. In at least one embodiment, the test facility gateway, through use of one or more test facility gateway servers, provides an application programming interface (API) that enables the test facility user (through a client device) to readily specify the test configuration and this API is referred to as the test configuration API. In one embodiment, the test facility user uses a personal computer (e.g., laptop, smartphone, desktop computer) or other client device to input information specifying the test configuration, which is then sent to the test facility gateway using the test configuration API. In one embodiment, the client device of the test facility user includes a test configuration client application, which is a computer application that may be a web application accessible using an Internet browser or an application installed to the client device, for example. According to one embodiment, the test configuration client application includes a graphical user interface (GUI) that enables the test facility user to specify the test configuration through providing input into the GUI, such as through various graphical user input elements (e.g., checkboxes, text fields, text boxes, selectable graphics, drag and drop elements). The test configuration client application then generates one or more test facility configuration messages based on the test facility user input and sends these test facility configuration messages to the test facility gateway via the API. Thus, in such embodiments, the test configuration client application enables the test facility user to intelligibly specify a test configuration that will be automatically executed by the system through use of the test facility gateway and the test facility control system.”)
receiving, by the computer, location data of the autonomous vehicle and (see at least WORMAN, ¶ 0043, “The roadside unit (RSU) 30 is provided at the test facility and is used to obtain information concerning the test facility, such as the presence and/or status of vehicles. In at least one embodiment, the RSU 30 receives basic safety messages (BSMs) or other vehicle status messages from one or more vehicles at the test facility, such as the test vehicle 10. The vehicle status messages, which may be BSMs, specify certain vehicle status information, such as the location of the vehicle (e.g., a GPS location of the vehicle), the speed of the vehicle, the heading of the vehicle, and/or various other vehicle state information. The RSU 30 may also transmit traffic status messages to one or more vehicles or devices indicating a status of nearby traffic, such as the vehicle status information of other nearby vehicles. The RSU 30 may also be communicatively coupled to one or more traffic infrastructure sensors, which are sensors that capture information pertaining to traffic within the test facility. An example of a traffic infrastructure sensor is a camera that is positioned to face an intersection or road, and another example of a traffic infrastructure sensor is a radar detector that is configured to detect the speed of a vehicle. The RSU 30 is communicatively coupled to the test facility control system 24 via the local network 32 and, in some embodiments, is used to log information that is later sent to the test facility control system 24 and/or the test facility gateway 22. In at least one embodiment, the RSU 30 logs information concerning the vehicle status information that is received and/or sensor data that is obtained by the traffic infrastructure sensors. In another embodiment, the RSU 30 forwards the information concerning the vehicle status information to the test configuration client application 13 of the client device 12, which can then present the information to the test facility user, which can enable the test facility user to trigger certain events at the test facility based on the feedback provided by the information. Also, although only a single RSU is shown, the test facility infrastructure control system 20 may include a plurality of RSUs.”)
a traffic vehicle (see at least WORMAN, ¶ 0043)
the autonomous vehicle and the traffic vehicle operating within a testing environment associated with the testing scenario; (see at least WORMAN, ¶ 0043; ¶ 0045, “With reference to FIG. 2, there is shown another embodiment of a test facility infrastructure control system 120. The test facility infrastructure control system 120 includes a test facility gateway 122 having a plurality of test facility gateway servers 121, 123, a test facility control system 124 having a test facility control server 125, a plurality of test facility controllers (which is represented in FIG. 2 by a traffic controller 126, a streetlight controller 150, an IoT device 160, and a controller of a robotic platform 134), a plurality of test environment devices (which is represented in FIG. 2 by a first traffic signal 128, a second traffic signal 129, a first streetlight 152, a second streetlight 154, an electromechanical device of the robotic platform 134), and a roadside unit (RSU) 130. The discussion of the embodiment of FIG. 1 applies to the embodiment of FIG. 2 to the extent such discussion is not inconsistent with the discussion of the embodiment of FIG. 2. For example, the discussion of the test facility gateway 22 applies equally to the test facility gateway 122 to the extent such discussion of the test facility gateway 22 is not inconsistent with the discussion of the test facility gateway 122.”; ¶ 0051, “The robotic platform 134 represents any of a number of test environment devices that are robotic (i.e., capable of motion), such as an automated or autonomous passenger car (or other vehicle) or a robotic dummy that may be deployed to a portion of a road of the test facility (or other portion of the test facility) for purposes of testing and that may be used to simulate the presence of a deer or pedestrian in the road or other portion of the test facility. In particular, the robotic dummy is a test-anomaly device, which is a test environment device that is used to introduce the presence of anomalous conditions, such as the presence of an animal or pedestrian on the road at a non-designated area and/or at a non-designated time, such as at a portion of the road that is not a pedestrian crosswalk or at a time when the pedestrian crosswalk signal is red (or set to DO NOT CROSS). The robotic platform 134 includes a test environment controller that controls the functionality or operation of a test environment device, such as the deployable robotic dummy described above, according to the test configuration. The robotic platform 134 includes one or more electromechanical devices that are considered a test environment device and that are controllable by the test environment controller of the robotic platform 134. The robotic platform 134 is communicatively coupled to the test facility control system 124 via a reverse-engineered protocol.”)
determining, by the computer, a first location for the autonomous vehicle and a second location for the autonomous vehicle based upon the location data; (see at least WORMAN, ¶ 0043)
determining, by the computer, a position of the traffic vehicle relative to the autonomous vehicle using the location data; (see at least WORMAN,¶ 0043, “The roadside unit (RSU) 30 is provided at the test facility and is used to obtain information concerning the test facility, such as the presence and/or status of vehicles. In at least one embodiment, the RSU 30 receives basic safety messages (BSMs) or other vehicle status messages from one or more vehicles at the test facility, such as the test vehicle 10. The vehicle status messages, which may be BSMs, specify certain vehicle status information, such as the location of the vehicle (e.g., a GPS location of the vehicle), the speed of the vehicle, the heading of the vehicle, and/or various other vehicle state information. The RSU 30 may also transmit traffic status messages to one or more vehicles or devices indicating a status of nearby traffic, such as the vehicle status information of other nearby vehicles. The RSU 30 may also be communicatively coupled to one or more traffic infrastructure sensors, which are sensors that capture information pertaining to traffic within the test facility. An example of a traffic infrastructure sensor is a camera that is positioned to face an intersection or road, and another example of a traffic infrastructure sensor is a radar detector that is configured to detect the speed of a vehicle. The RSU 30 is communicatively coupled to the test facility control system 24 via the local network 32 and, in some embodiments, is used to log information that is later sent to the test facility control system 24 and/or the test facility gateway 22. In at least one embodiment, the RSU 30 logs information concerning the vehicle status information that is received and/or sensor data that is obtained by the traffic infrastructure sensors. In another embodiment, the RSU 30 forwards the information concerning the vehicle status information to the test configuration client application 13 of the client device 12, which can then present the information to the test facility user, which can enable the test facility user to trigger certain events at the test facility based on the feedback provided by the information. Also, although only a single RSU is shown, the test facility infrastructure control system 20 may include a plurality of RSUs.”)
generating, by the computer, kinematics data using the location data, the first location, the second location, and the position of the traffic vehicle; (see at least WORMAN,¶ 0043)
updating, by the computer, (see at least WORMAN, ¶ 0026, “The test configuration is received from a test facility gateway that is communicatively coupled to the test facility control system. In at least some embodiments, the test configuration specifies a plurality of states or operations of one or more test environment devices; however, in one embodiment, the test configuration specifies a single state or operation of one of the test environment devices. The test facility gateway is configured to receive test configuration information from a test facility user. In at least one embodiment, the test facility gateway, through use of one or more test facility gateway servers, provides an application programming interface (API) that enables the test facility user (through a client device) to readily specify the test configuration and this API is referred to as the test configuration API. In one embodiment, the test facility user uses a personal computer (e.g., laptop, smartphone, desktop computer) or other client device to input information specifying the test configuration, which is then sent to the test facility gateway using the test configuration API. In one embodiment, the client device of the test facility user includes a test configuration client application, which is a computer application that may be a web application accessible using an Internet browser or an application installed to the client device, for example. According to one embodiment, the test configuration client application includes a graphical user interface (GUI) that enables the test facility user to specify the test configuration through providing input into the GUI, such as through various graphical user input elements (e.g., checkboxes, text fields, text boxes, selectable graphics, drag and drop elements). The test configuration client application then generates one or more test facility configuration messages based on the test facility user input and sends these test facility configuration messages to the test facility gateway via the API. Thus, in such embodiments, the test configuration client application enables the test facility user to intelligibly specify a test configuration that will be automatically executed by the system through use of the test facility gateway and the test facility control system.”)
the user interface based on the location data and the kinematics data, (see at least WORMAN, ¶ 0053, “The method 200 begins with step 205, wherein a test configuration that is specified by a test facility user is received. In one embodiment, the test configuration specifies one or more state of one or more test environment devices and, in a particular embodiment, specifies a single state (or operation) for a single test environment device, which can be used to test individual functionality of the system 20. However, in other embodiments, the test environment device specifies a plurality of various states for a plurality of various test environment devices, and may be used to orchestrate a test that is used to test the test vehicle's responsiveness to a variety of different environmental conditions and traffic conditions, and which may simulate a real-world scenario. In one embodiment, the test facility user uses the test configuration client application 13 of the client device 12 to input information specifying a test configuration that is to be used for testing at the test facility. In such embodiments, the client device 12 can include one or more human-machine interfaces (HMIs), such as a touchscreen display or pushbuttons, which enable the test facility user to input the information specifying the test configuration. The client device 12 then sends one or more test facility configuration messages, which contain information specifying the test configuration, to the test facility gateway 22, which receives the one or more test facility configuration messages specifying the test configuration.”)
the user interface including one or more user-selectable options of (see at least WORMAN, ¶ 0025, “The system and method described herein enables control and configuration of one or more test environment devices of a test facility based on a test configuration. In at least some embodiments, the test facility is a facility used for testing vehicles and, in one embodiment, the test facility is a facility used for testing automobiles. A test facility infrastructure control system is used to control and configure a plurality of test environment devices that are located at the test facility. Each of the test environment devices is operable to change one or more vehicle traffic or environmental conditions used during the vehicle testing. For example, a first test environment device is a traffic signal that is operable to change a traffic light, such as from green to red. As another example, a second test environment device is a gate that is operable to change between a road-obstructing position (or closed position) and a non-road-obstructing position (or open position). The test environment devices are communicatively coupled to at least one test environment controller, each of which is used to control the operation of test environment device(s). Each test environment controller is communicatively coupled to a test facility control server of the test facility control system, which is configured to receive test facility configuration information that specifies a test configuration to be used in carrying out vehicle testing at the test facility. The test facility control system is used to send messages to the test environment controllers that then cause the test environment controllers to control the operation of the test environment devices according to the test configuration.”; ¶ 0026; ¶ 0053)
WORMAN does not disclose, but GAO teaches:
configuring one or more bail thresholds associated with the testing scenario of the autonomous vehicle; (see at least GAO, ¶ 0036, “As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which can come from the control system 102 or from the on-board safety protection system 120), and sensor information within the test site 130, and based on this information determines the possibility of risks occurring to the vehicle under test 101, including collision risk, lane departure risk, risk of driving out of a predetermined area, etc. When there is a higher risk (for example, the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the onboard protection system 120 to brake the vehicle 101 under test. The onboard protection system 120 brakes the vehicle under test 101 in a timely manner, for example, to make the vehicle under test 101 exit the automatic driving state.”)
receiving, by the computer, the one or more bail thresholds selected by a user via the user interface; (see at least GAO, ¶ 0036; ¶ 0066, “In some embodiments, the task termination judgment module 620 includes a task termination determination module configured to determine to terminate the test task in response to detecting that the vehicle under test is in a state of being braked by a safety protection system, and wherein the test operation execution module 630 includes a test result identification module configured to identify that the vehicle under test has failed the test task.”)
in response to the computer determining that a value of the kinematics data satisfies the one or more received bail thresholds associated with the testing scenario of theautonomous vehicle, (see at least GAO, ¶ 0036; ¶ 0064, “As shown in Figure 6, the device 600 includes a test status monitoring module 610, which is configured to monitor the test status associated with the test task during the execution of the test task for the vehicle under test. The test status includes at least one of the following: the status of the vehicle under test, the status of the safety protection system for the vehicle under test, and the status of the test equipment that provides the test environment related to the test task. The device 600 also includes a task termination judgment module 620, which is configured to determine whether to terminate the test task based on the test status. The apparatus 600 further includes a test operation execution module 630, configured to execute a test operation corresponding to the test state if the test task is determined to be aborted.”)
generating, by the computer, a bail notification containing machine-readable instructions causing the autonomous vehicle to halt operations; and (see at least GAO, ¶ 0036)
in response to the bail notification, causing the autonomous vehicle to abort the testing scenario. (see at least GAO, ¶ 0036; ¶ 0047, “When the safety protection system 103 determines that the vehicle under test 101 has a high safety risk and brakes the vehicle under test 101 , the vehicle under test 101 is in a nonautonomous braking state. For example, the site protection system 110 determines that the tested vehicle 101 has a high safety risk. While sending an instruction to brake the tested vehicle 101 to the onboard protection system 120 , it can also send a message to the control system 102 that the tested vehicle 101 will be braked. Based on this message, the control system 102 may determine that the vehicle under test 101 is in a state of being braked by the safety protection system, and thus terminate the test. Alternatively or additionally, the control system 102 may also determine the status of the vehicle under test 101 based on a message from the vehicle under test 101 .”; ¶ 0068, “In some embodiments, the apparatus 600 further includes: a test task terminating module configured to terminate the test task by causing the vehicle under test to maintain braking and causing the test equipment to stop providing a test environment.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs and control systems for evaluation of event-based situations of autonomous vehicles within WORMAN with the site protection systems for automatically stopping the vehicle within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
EXAMINERS NOTE: Although neither GAO or WORMAN explicitly disclose setting “bail thresholds”, GAO discloses the stopping of the test based on a threshold collision time (GAO, ¶ 0036) which would be understood by a person having ordinary skill in the art to be a threshold value to abort a test. Furthermore, given the variable is a threshold, its variability would be understood to be operator-settable.
Regarding claim 6:
WORMAN in view of GAO teaches the limitations within claim 1 and WORMAN further discloses:
receiving, by the computer, a configuration input instruction corresponding (see at least WORMAN, ¶ 0025, “The system and method described herein enables control and configuration of one or more test environment devices of a test facility based on a test configuration. In at least some embodiments, the test facility is a facility used for testing vehicles and, in one embodiment, the test facility is a facility used for testing automobiles. A test facility infrastructure control system is used to control and configure a plurality of test environment devices that are located at the test facility. Each of the test environment devices is operable to change one or more vehicle traffic or environmental conditions used during the vehicle testing. For example, a first test environment device is a traffic signal that is operable to change a traffic light, such as from green to red. As another example, a second test environment device is a gate that is operable to change between a road-obstructing position (or closed position) and a non-road-obstructing position (or open position). The test environment devices are communicatively coupled to at least one test environment controller, each of which is used to control the operation of test environment device(s). Each test environment controller is communicatively coupled to a test facility control server of the test facility control system, which is configured to receive test facility configuration information that specifies a test configuration to be used in carrying out vehicle testing at the test facility. The test facility control system is used to send messages to the test environment controllers that then cause the test environment controllers to control the operation of the test environment devices according to the test configuration.”)
selected by the user via the user interface. (see at least WORMAN, ¶ 0026, “The test configuration is received from a test facility gateway that is communicatively coupled to the test facility control system. In at least some embodiments, the test configuration specifies a plurality of states or operations of one or more test environment devices; however, in one embodiment, the test configuration specifies a single state or operation of one of the test environment devices. The test facility gateway is configured to receive test configuration information from a test facility user. In at least one embodiment, the test facility gateway, through use of one or more test facility gateway servers, provides an application programming interface (API) that enables the test facility user (through a client device) to readily specify the test configuration and this API is referred to as the test configuration API. In one embodiment, the test facility user uses a personal computer (e.g., laptop, smartphone, desktop computer) or other client device to input information specifying the test configuration, which is then sent to the test facility gateway using the test configuration API. In one embodiment, the client device of the test facility user includes a test configuration client application, which is a computer application that may be a web application accessible using an Internet browser or an application installed to the client device, for example. According to one embodiment, the test configuration client application includes a graphical user interface (GUI) that enables the test facility user to specify the test configuration through providing input into the GUI, such as through various graphical user input elements (e.g., checkboxes, text fields, text boxes, selectable graphics, drag and drop elements). The test configuration client application then generates one or more test facility configuration messages based on the test facility user input and sends these test facility configuration messages to the test facility gateway via the API. Thus, in such embodiments, the test configuration client application enables the test facility user to intelligibly specify a test configuration that will be automatically executed by the system through use of the test facility gateway and the test facility control system.”)
WORMAN does not disclose, but GAO teaches:
to the one or more bail thresholds (see at least GAO, ¶ 0036, "As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which can come from the control system 102 or from the on-board safety protection system 120), and sensor information within the test site 130, and based on this information determines the possibility of risks occurring to the vehicle under test 101, including collision risk, lane departure risk, risk of driving out of a predetermined area, etc. When there is a higher risk (for example, the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the onboard protection system 120 to brake the vehicle 101 under test. The onboard protection system 120 brakes the vehicle under test 101 in a timely manner, for example, to make the vehicle under test 101 exit the automatic driving state."; ¶ 0064, "FIG6 shows a schematic block diagram of an apparatus 600 for testing a vehicle according to some embodiments of the present disclosure. The apparatus 600 may be included in or implemented as the control system 102 of FIG. 1 . As shown in FIG6 , the apparatus 600 includes a test status monitoring module 610 configured to monitor a test status associated with a test task during execution of the test task on the vehicle under test. The test status includes at least one of the following: a status of the vehicle under test, a status of a safety protection system for the vehicle under test, and a status of a test device providing a test environment related to the test task. The apparatus 600 further includes a task termination determination module 620 configured to determine whether to terminate the test task based on the test status. The apparatus 600 further includes a test operation execution module 630 configured to execute a test operation corresponding to the test status according to determining that the test task is suspended. ")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
Regarding claim 7:
WORMAN in view of GAO teaches the limitations within claim 1 and WORMAN further discloses:
the computer receives the location data from a location sensor of the autonomous vehicle. (see at least WORMAN, ¶ 0043, “The roadside unit (RSU) 30 is provided at the test facility and is used to obtain information concerning the test facility, such as the presence and/or status of vehicles. In at least one embodiment, the RSU 30 receives basic safety messages (BSMs) or other vehicle status messages from one or more vehicles at the test facility, such as the test vehicle 10. The vehicle status messages, which may be BSMs, specify certain vehicle status information, such as the location of the vehicle (e.g., a GPS location of the vehicle), the speed of the vehicle, the heading of the vehicle, and/or various other vehicle state information. The RSU 30 may also transmit traffic status messages to one or more vehicles or devices indicating a status of nearby traffic, such as the vehicle status information of other nearby vehicles. The RSU 30 may also be communicatively coupled to one or more traffic infrastructure sensors, which are sensors that capture information pertaining to traffic within the test facility. An example of a traffic infrastructure sensor is a camera that is positioned to face an intersection or road, and another example of a traffic infrastructure sensor is a radar detector that is configured to detect the speed of a vehicle. The RSU 30 is communicatively coupled to the test facility control system 24 via the local network 32 and, in some embodiments, is used to log information that is later sent to the test facility control system 24 and/or the test facility gateway 22. In at least one embodiment, the RSU 30 logs information concerning the vehicle status information that is received and/or sensor data that is obtained by the traffic infrastructure sensors. In another embodiment, the RSU 30 forwards the information concerning the vehicle status information to the test configuration client application 13 of the client device 12, which can then present the information to the test facility user, which can enable the test facility user to trigger certain events at the test facility based on the feedback provided by the information. Also, although only a single RSU is shown, the test facility infrastructure control system 20 may include a plurality of RSUs.”)
Regarding claim 8:
With regards to claim 8, this claim is the system claim to method claim 1 and is substantially similar to claim 1 and is therefore rejected using the same references and rationale.
Regarding Claim 13:
With regards to claim 13, this claim is substantially similar to claim 6 and is therefore rejected using the same references and rationale.
Regarding claim 14:
With regards to claim 14, this claim is substantially similar to claim 7 and is therefore rejected using the same references and rationale.
Regarding claim 15:
WORMAN in view of GAO teaches the limitations within claim 8 and WORMAN further discloses:
the computer is further configured to track the testing scenario via the user-configurable test tool. (see at least WORMAN, ¶ 0026, “The test configuration is received from a test facility gateway that is communicatively coupled to the test facility control system. In at least some embodiments, the test configuration specifies a plurality of states or operations of one or more test environment devices; however, in one embodiment, the test configuration specifies a single state or operation of one of the test environment devices. The test facility gateway is configured to receive test configuration information from a test facility user. In at least one embodiment, the test facility gateway, through use of one or more test facility gateway servers, provides an application programming interface (API) that enables the test facility user (through a client device) to readily specify the test configuration and this API is referred to as the test configuration API. In one embodiment, the test facility user uses a personal computer (e.g., laptop, smartphone, desktop computer) or other client device to input information specifying the test configuration, which is then sent to the test facility gateway using the test configuration API. In one embodiment, the client device of the test facility user includes a test configuration client application, which is a computer application that may be a web application accessible using an Internet browser or an application installed to the client device, for example. According to one embodiment, the test configuration client application includes a graphical user interface (GUI) that enables the test facility user to specify the test configuration through providing input into the GUI, such as through various graphical user input elements (e.g., checkboxes, text fields, text boxes, selectable graphics, drag and drop elements). The test configuration client application then generates one or more test facility configuration messages based on the test facility user input and sends these test facility configuration messages to the test facility gateway via the API. Thus, in such embodiments, the test configuration client application enables the test facility user to intelligibly specify a test configuration that will be automatically executed by the system through use of the test facility gateway and the test facility control system.”; ¶ 0043, “The roadside unit (RSU) 30 is provided at the test facility and is used to obtain information concerning the test facility, such as the presence and/or status of vehicles. In at least one embodiment, the RSU 30 receives basic safety messages (BSMs) or other vehicle status messages from one or more vehicles at the test facility, such as the test vehicle 10. The vehicle status messages, which may be BSMs, specify certain vehicle status information, such as the location of the vehicle (e.g., a GPS location of the vehicle), the speed of the vehicle, the heading of the vehicle, and/or various other vehicle state information. The RSU 30 may also transmit traffic status messages to one or more vehicles or devices indicating a status of nearby traffic, such as the vehicle status information of other nearby vehicles. The RSU 30 may also be communicatively coupled to one or more traffic infrastructure sensors, which are sensors that capture information pertaining to traffic within the test facility. An example of a traffic infrastructure sensor is a camera that is positioned to face an intersection or road, and another example of a traffic infrastructure sensor is a radar detector that is configured to detect the speed of a vehicle. The RSU 30 is communicatively coupled to the test facility control system 24 via the local network 32 and, in some embodiments, is used to log information that is later sent to the test facility control system 24 and/or the test facility gateway 22. In at least one embodiment, the RSU 30 logs information concerning the vehicle status information that is received and/or sensor data that is obtained by the traffic infrastructure sensors. In another embodiment, the RSU 30 forwards the information concerning the vehicle status information to the test configuration client application 13 of the client device 12, which can then present the information to the test facility user, which can enable the test facility user to trigger certain events at the test facility based on the feedback provided by the information. Also, although only a single RSU is shown, the test facility infrastructure control system 20 may include a plurality of RSUs.”)
Regarding claim 18:
WORMAN in view of GAO teaches the limitations within claim 8 and WORMAN does not disclose, but GAO teaches:
the computer is further configured to transmit the bail notification containing the machine-readable software instructions to the autonomous vehicle, by autonomy software associated with the autonomous vehicle. (see at least GAO, ¶ 0036, "As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which can come from the control system 102 or from the on-board safety protection system 120), and sensor information within the test site 130, and based on this information determines the possibility of risks occurring to the vehicle under test 101, including collision risk, lane departure risk, risk of driving out of a predetermined area, etc. When there is a higher risk (for example, the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the onboard protection system 120 to brake the vehicle 101 under test. The onboard protection system 120 brakes the vehicle under test 101 in a timely manner, for example, to make the vehicle under test 101 exit the automatic driving state. "; ¶ 0047, "When the safety protection system 103 determines that the vehicle under test 101 has a high safety risk and brakes the vehicle under test 101 , the vehicle under test 101 is in a nonautonomous braking state. For example, the site protection system 110 determines that the tested vehicle 101 has a high safety risk. While sending an instruction to brake the tested vehicle 101 to the onboard protection system 120 , it can also send a message to the control system 102 that the tested vehicle 101 will be braked. Based on this message, the control system 102 may determine that the vehicle under test 101 is in a state of being braked by the safety protection system, and thus terminate the test. Alternatively or additionally, the control system 102 may also determine the status of the vehicle under test 101 based on a message from the vehicle under test 101 ."; ¶ 0068, "In some embodiments, the apparatus 600 further includes: a test task terminating module configured to terminate the test task by causing the vehicle under test to maintain braking and causing the test equipment to stop providing a test environment.")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
Regarding claim 19:
WORMAN in view of GAO teaches the limitations within claim 18 and WORMAN further discloses:
detect, via the user-configurable test tool, that the value of the kinematics data (see at least WORMAN, ¶ 0043, “The roadside unit (RSU) 30 is provided at the test facility and is used to obtain information concerning the test facility, such as the presence and/or status of vehicles. In at least one embodiment, the RSU 30 receives basic safety messages (BSMs) or other vehicle status messages from one or more vehicles at the test facility, such as the test vehicle 10. The vehicle status messages, which may be BSMs, specify certain vehicle status information, such as the location of the vehicle (e.g., a GPS location of the vehicle), the speed of the vehicle, the heading of the vehicle, and/or various other vehicle state information. The RSU 30 may also transmit traffic status messages to one or more vehicles or devices indicating a status of nearby traffic, such as the vehicle status information of other nearby vehicles. The RSU 30 may also be communicatively coupled to one or more traffic infrastructure sensors, which are sensors that capture information pertaining to traffic within the test facility. An example of a traffic infrastructure sensor is a camera that is positioned to face an intersection or road, and another example of a traffic infrastructure sensor is a radar detector that is configured to detect the speed of a vehicle. The RSU 30 is communicatively coupled to the test facility control system 24 via the local network 32 and, in some embodiments, is used to log information that is later sent to the test facility control system 24 and/or the test facility gateway 22. In at least one embodiment, the RSU 30 logs information concerning the vehicle status information that is received and/or sensor data that is obtained by the traffic infrastructure sensors. In another embodiment, the RSU 30 forwards the information concerning the vehicle status information to the test configuration client application 13 of the client device 12, which can then present the information to the test facility user, which can enable the test facility user to trigger certain events at the test facility based on the feedback provided by the information. Also, although only a single RSU is shown, the test facility infrastructure control system 20 may include a plurality of RSUs.”)
WORMAN does not disclose, but GAO teaches:
satisfies the one or more received bail thresholds and (see at least GAO, ¶ 0036, "As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which can come from the control system 102 or from the on-board safety protection system 120), and sensor information within the test site 130, and based on this information determines the possibility of risks occurring to the vehicle under test 101, including collision risk, lane departure risk, risk of driving out of a predetermined area, etc. When there is a higher risk (for example, the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the onboard protection system 120 to brake the vehicle 101 under test. The onboard protection system 120 brakes the vehicle under test 101 in a timely manner, for example, to make the vehicle under test 101 exit the automatic driving state."; ¶ 0064, "FIG6 shows a schematic block diagram of an apparatus 600 for testing a vehicle according to some embodiments of the present disclosure. The apparatus 600 may be included in or implemented as the control system 102 of FIG. 1 . As shown in FIG6 , the apparatus 600 includes a test status monitoring module 610 configured to monitor a test status associated with a test task during execution of the test task on the vehicle under test. The test status includes at least one of the following: a status of the vehicle under test, a status of a safety protection system for the vehicle under test, and a status of a test device providing a test environment related to the test task. The apparatus 600 further includes a task termination determination module 620 configured to determine whether to terminate the test task based on the test status. The apparatus 600 further includes a test operation execution module 630 configured to execute a test operation corresponding to the test status according to determining that the test task is suspended.")
push the bail notification including an abort instruction to the autonomy software of the autonomous vehicle to halt operations and abort the testing scenario. (see at least GAO, ¶ 0036; ¶ 0047, “When the safety protection system 103 determines that the vehicle under test 101 has a high safety risk and brakes the vehicle under test 101 , the vehicle under test 101 is in a nonautonomous braking state. For example, the site protection system 110 determines that the tested vehicle 101 has a high safety risk. While sending an instruction to brake the tested vehicle 101 to the onboard protection system 120 , it can also send a message to the control system 102 that the tested vehicle 101 will be braked. Based on this message, the control system 102 may determine that the vehicle under test 101 is in a state of being braked by the safety protection system, and thus terminate the test. Alternatively or additionally, the control system 102 may also determine the status of the vehicle under test 101 based on a message from the vehicle under test 101.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
Regarding claim 20:
WORMAN in view of GAO teaches the limitations within claim 8 and WORMAN further discloses:
with a pre-defined permissible relative distance between the autonomous vehicle and the traffic vehicle (see at least WORMAN,¶ 0043, “The roadside unit (RSU) 30 is provided at the test facility and is used to obtain information concerning the test facility, such as the presence and/or status of vehicles. In at least one embodiment, the RSU 30 receives basic safety messages (BSMs) or other vehicle status messages from one or more vehicles at the test facility, such as the test vehicle 10. The vehicle status messages, which may be BSMs, specify certain vehicle status information, such as the location of the vehicle (e.g., a GPS location of the vehicle), the speed of the vehicle, the heading of the vehicle, and/or various other vehicle state information. The RSU 30 may also transmit traffic status messages to one or more vehicles or devices indicating a status of nearby traffic, such as the vehicle status information of other nearby vehicles. The RSU 30 may also be communicatively coupled to one or more traffic infrastructure sensors, which are sensors that capture information pertaining to traffic within the test facility. An example of a traffic infrastructure sensor is a camera that is positioned to face an intersection or road, and another example of a traffic infrastructure sensor is a radar detector that is configured to detect the speed of a vehicle. The RSU 30 is communicatively coupled to the test facility control system 24 via the local network 32 and, in some embodiments, is used to log information that is later sent to the test facility control system 24 and/or the test facility gateway 22. In at least one embodiment, the RSU 30 logs information concerning the vehicle status information that is received and/or sensor data that is obtained by the traffic infrastructure sensors. In another embodiment, the RSU 30 forwards the information concerning the vehicle status information to the test configuration client application 13 of the client device 12, which can then present the information to the test facility user, which can enable the test facility user to trigger certain events at the test facility based on the feedback provided by the information. Also, although only a single RSU is shown, the test facility infrastructure control system 20 may include a plurality of RSUs.”)
during the testing scenario, and the computer is further configured to: (see at least WORMAN, ¶ 0053, “The method 200 begins with step 205, wherein a test configuration that is specified by a test facility user is received. In one embodiment, the test configuration specifies one or more state of one or more test environment devices and, in a particular embodiment, specifies a single state (or operation) for a single test environment device, which can be used to test individual functionality of the system 20. However, in other embodiments, the test environment device specifies a plurality of various states for a plurality of various test environment devices, and may be used to orchestrate a test that is used to test the test vehicle's responsiveness to a variety of different environmental conditions and traffic conditions, and which may simulate a real-world scenario. In one embodiment, the test facility user uses the test configuration client application 13 of the client device 12 to input information specifying a test configuration that is to be used for testing at the test facility. In such embodiments, the client device 12 can include one or more human-machine interfaces (HMIs), such as a touchscreen display or pushbuttons, which enable the test facility user to input the information specifying the test configuration. The client device 12 then sends one or more test facility configuration messages, which contain information specifying the test configuration, to the test facility gateway 22, which receives the one or more test facility configuration messages specifying the test configuration.”)
a relative distance satisfies the (see at least WORMAN, ¶ 0043)
the one or more received bail thresholds are associated (see at least GAO, ¶ 0036, "As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which can come from the control system 102 or from the on-board safety protection system 120), and sensor information within the test site 130, and based on this information determines the possibility of risks occurring to the vehicle under test 101, including collision risk, lane departure risk, risk of driving out of a predetermined area, etc. When there is a higher risk (for example, the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the onboard protection system 120 to brake the vehicle 101 under test. The onboard protection system 120 brakes the vehicle under test 101 in a timely manner, for example, to make the vehicle under test 101 exit the automatic driving state. ")
determine that at least one of the one or more bail thresholds is satisfied when (see at least GAO, ¶ 0033, “The safety protection system 103 may include a site protection system 110 (also referred to as a site-side protection system 110 ) and a vehicle-mounted protection system 120 (also referred to as a vehicle-side protection system 120 ). At least a portion of the site protection system 110 may be implemented at a suitable location in the test site 130 , such as a central control room, or may be implemented in the cloud. The site protection system 110 may be implemented at least in part by a computing device or a unit having computing capabilities. In some embodiments, the site protection system 110 may further include sensing devices, such as roadside sensors disposed within the test site 130 .”; ¶ 0036)
at least one of the one or more bail thresholds. (see at least GAO, ¶ 0036; ¶ 0066, "In some embodiments, the task termination judgment module 620 includes a task termination determination module configured to determine to terminate the test task in response to detecting that the vehicle under test is in a state of being braked by a safety protection system, and wherein the test operation execution module 630 includes a test result identification module configured to identify that the vehicle under test has failed the test task. ")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
Claims 2-5, 9-12, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over WORMAN (US 20230038486 A1)in view of GAO (CN 111323238 A) in further view of ALALAO (US20220075368A1).
Regarding claim 2:
WORMAN in view of GAO teaches the limitations within claim 1 and WORMAN does not disclose, but GAO teaches:
of when the one or more received bail thresholds are reached. (see at least GAO, ¶ 0036, "As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which may come from the control system 102 or the vehicle safety protection system 120), and sensor information within the test site 130. Based on this information, it determines the likelihood of the vehicle under test 101 encountering risks, including collision risk, lane departure risk, and risk of leaving the predetermined area. When there is a high risk (e.g., the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the vehicle protection system 120 to brake the test vehicle 101. The vehicle protection system 120 brakes the test vehicle 101 in a timely manner, for example, to cause the test vehicle 101 to exit the autonomous driving state. ")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
WORMAN in view of GAO does not disclose, but ALALAO teaches:
generating, by the computer, a visual representation on the user interface (see at least ALALAO, ¶ 0024, "In another aspect, a user interface is presented on a display device of an autonomous vehicle. The user interface includes a visual representation of an environment surrounding the autonomous vehicle, a first display element indicating a physical location of the autonomous vehicle with respect to the environment, and one or more second display elements. Each second display element indicates a respective operational property of the autonomous vehicle. A user input specifying an operation to be performed by the autonomous vehicle is received through the user interface. Responsive to receiving the user input, the specified operation is performed using the autonomous vehicle."))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify, with a reasonable expectation of success, the GUI for setting test parameters, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and the collection of data for preventing collisions within WORMAN in view of GAO to perform with the environmental display for visualizing vehicle telemetry of ALALAO to yield a more effective visualization of the nearby vehicles based on the vehicle and environment data collected within WORMAN and GAO.
Regarding claim 3:
WORMAN in view of GAO in further view of ALALAO teaches the limitations within claim 2 and WORMAN further discloses:
based upon the location data and the kinematics data. (see at lease WORMAN, ¶ 0053, “The method 200 begins with step 205, wherein a test configuration that is specified by a test facility user is received. In one embodiment, the test configuration specifies one or more state of one or more test environment devices and, in a particular embodiment, specifies a single state (or operation) for a single test environment device, which can be used to test individual functionality of the system 20. However, in other embodiments, the test environment device specifies a plurality of various states for a plurality of various test environment devices, and may be used to orchestrate a test that is used to test the test vehicle's responsiveness to a variety of different environmental conditions and traffic conditions, and which may simulate a real-world scenario. In one embodiment, the test facility user uses the test configuration client application 13 of the client device 12 to input information specifying a test configuration that is to be used for testing at the test facility. In such embodiments, the client device 12 can include one or more human-machine interfaces (HMIs), such as a touchscreen display or pushbuttons, which enable the test facility user to input the information specifying the test configuration. The client device 12 then sends one or more test facility configuration messages, which contain information specifying the test configuration, to the test facility gateway 22, which receives the one or more test facility configuration messages specifying the test configuration.”)
WORMAN does not disclose, but ALALAO teaches:
the user interface includes at least one of a graphical representation or data representation (see at lease ALALAO, ¶ 0041, “In some embodiments, the second display element includes a graphical representation of a plurality of regions surrounding the autonomous vehicle, and for at least one of the regions, a graphical indication that at least one of the one or more objects is positioned in that region. In some embodiments, presenting the user interface includes generating the second display element based on textual data indicating, for each object, a location of the object with respect to a plurality of two-dimension boxes of a graphical grid. In some embodiments, the textual data indicating the location of the object with respect to the plurality of boxes of the graphical grid comprises one or more data items in a JavaScript Object Notation (JSON) format.”; ¶ 0234, “The map portion 3002 can indicate the location and classification of objects using symbolic icons 3012 (e.g., simplified representations of the objects). Different icons can be used for different classes or types of objects. For instance, FIG. 31 shows several example symbolic icons 3012a-3012e that can be used to represent different classes or types of objects. For example, icons 3012a can be used to represent motor vehicles (e.g., cars, trucks, vans, etc., icons 3012b can be used to represent pedestrians, icons 3012c can be used to represent bicycles, icons 3012d can be used to represent unclassified objects, and icons 3012e can be used to identify construction barricades or traffic cones.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify, with a reasonable expectation of success, the GUI for setting test parameters, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and the collection of data for preventing collisions within WORMAN in view of GAO to perform with the environmental display for visualizing vehicle telemetry of ALALAO to yield a more effective visualization of the nearby vehicles based on the vehicle and environment data collected within WORMAN and GAO.
Regarding claim 4:
WORMAN in view of GAO in further view of ALALAO teaches the limitations within claim 1 and WORMAN does not disclose, but GAO teaches:
the computer generates the bail notification (see at least GAO, ¶ 0036, "As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which can come from the control system 102 or from the on-board safety protection system 120), and sensor information within the test site 130, and based on this information determines the possibility of risks occurring to the vehicle under test 101, including collision risk, lane departure risk, risk of driving out of a predetermined area, etc. When there is a higher risk (for example, the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the onboard protection system 120 to brake the vehicle 101 under test. The onboard protection system 120 brakes the vehicle under test 101 in a timely manner, for example, to make the vehicle under test 101 exit the automatic driving state. "; ¶ 0064, "FIG6 shows a schematic block diagram of an apparatus 600 for testing a vehicle according to some embodiments of the present disclosure. The apparatus 600 may be included in or implemented as the control system 102 of FIG. 1 . As shown in FIG6 , the apparatus 600 includes a test status monitoring module 610 configured to monitor a test status associated with a test task during execution of the test task on the vehicle under test. The test status includes at least one of the following: a status of the vehicle under test, a status of a safety protection system for the vehicle under test, and a status of a test device providing a test environment related to the test task. The apparatus 600 further includes a task termination determination module 620 configured to determine whether to terminate the test task based on the test status. The apparatus 600 further includes a test operation execution module 630 configured to execute a test operation corresponding to the test status according to determining that the test task is suspended. ")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
WORMAN in view of GAO does not disclose, but ALALAO teaches:
for display at the user interface. (see at lease ALALAO, ¶ 0041, “In some embodiments, the second display element includes a graphical representation of a plurality of regions surrounding the autonomous vehicle, and for at least one of the regions, a graphical indication that at least one of the one or more objects is positioned in that region. In some embodiments, presenting the user interface includes generating the second display element based on textual data indicating, for each object, a location of the object with respect to a plurality of two-dimension boxes of a graphical grid. In some embodiments, the textual data indicating the location of the object with respect to the plurality of boxes of the graphical grid comprises one or more data items in a JavaScript Object Notation (JSON) format.”; ¶ 0234, “The map portion 3002 can indicate the location and classification of objects using symbolic icons 3012 (e.g., simplified representations of the objects). Different icons can be used for different classes or types of objects. For instance, FIG. 31 shows several example symbolic icons 3012a-3012e that can be used to represent different classes or types of objects. For example, icons 3012a can be used to represent motor vehicles (e.g., cars, trucks, vans, etc., icons 3012b can be used to represent pedestrians, icons 3012c can be used to represent bicycles, icons 3012d can be used to represent unclassified objects, and icons 3012e can be used to identify construction barricades or traffic cones.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify, with a reasonable expectation of success, the GUI for setting test parameters, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and the collection of data for preventing collisions within WORMAN in view of GAO to perform with the environmental display for visualizing vehicle telemetry of ALALAO to yield a more effective visualization of the nearby vehicles based on the vehicle and environment data collected within WORMAN and GAO.
Regarding claim 5:
WORMAN in view of GAO in further view of ALALAO teaches the limitations within claim 4 and WORMAN does not disclose, but GAO teaches:
is configured to display a bail condition status. (see at least GAO, ¶ 0036, "As an example, the site protection system 110 receives test equipment information from the control system 102, information about the vehicle under test 101 (which can come from the control system 102 or from the on-board safety protection system 120), and sensor information within the test site 130, and based on this information determines the possibility of risks occurring to the vehicle under test 101, including collision risk, lane departure risk, risk of driving out of a predetermined area, etc. When there is a higher risk (for example, the estimated collision time is less than a threshold time), the site protection system 110 sends a braking instruction to the onboard protection system 120 to brake the vehicle 101 under test. The onboard protection system 120 brakes the vehicle under test 101 in a timely manner, for example, to make the vehicle under test 101 exit the automatic driving state. "; ¶ 0064, "FIG6 shows a schematic block diagram of an apparatus 600 for testing a vehicle according to some embodiments of the present disclosure. The apparatus 600 may be included in or implemented as the control system 102 of FIG. 1 . As shown in FIG6 , the apparatus 600 includes a test status monitoring module 610 configured to monitor a test status associated with a test task during execution of the test task on the vehicle under test. The test status includes at least one of the following: a status of the vehicle under test, a status of a safety protection system for the vehicle under test, and a status of a test device providing a test environment related to the test task. The apparatus 600 further includes a task termination determination module 620 configured to determine whether to terminate the test task based on the test status. The apparatus 600 further includes a test operation execution module 630 configured to execute a test operation corresponding to the test status according to determining that the test task is suspended. ")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
WORMAN in view of GAO does not disclose, but ALALAO teaches:
the user interface (see at lease ALALAO, ¶ 0041, “In some embodiments, the second display element includes a graphical representation of a plurality of regions surrounding the autonomous vehicle, and for at least one of the regions, a graphical indication that at least one of the one or more objects is positioned in that region. In some embodiments, presenting the user interface includes generating the second display element based on textual data indicating, for each object, a location of the object with respect to a plurality of two-dimension boxes of a graphical grid. In some embodiments, the textual data indicating the location of the object with respect to the plurality of boxes of the graphical grid comprises one or more data items in a JavaScript Object Notation (JSON) format.”; ¶ 0234, “The map portion 3002 can indicate the location and classification of objects using symbolic icons 3012 (e.g., simplified representations of the objects). Different icons can be used for different classes or types of objects. For instance, FIG. 31 shows several example symbolic icons 3012a-3012e that can be used to represent different classes or types of objects. For example, icons 3012a can be used to represent motor vehicles (e.g., cars, trucks, vans, etc., icons 3012b can be used to represent pedestrians, icons 3012c can be used to represent bicycles, icons 3012d can be used to represent unclassified objects, and icons 3012e can be used to identify construction barricades or traffic cones.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify, with a reasonable expectation of success, the GUI for setting test parameters, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and the collection of data for preventing collisions within WORMAN in view of GAO to perform with the environmental display for visualizing vehicle telemetry of ALALAO to yield a more effective visualization of the nearby vehicles based on the vehicle and environment data collected within WORMAN and GAO.
Regarding Claim 9:
With regards to claim 9, this claim is substantially similar to claim 2 and is therefore rejected using the same references and rationale.
Regarding Claim 10:
With regards to claim 10, this claim is substantially similar to claim 3 and is therefore rejected using the same references and rationale.
Regarding Claim 11:
With regards to claim 11, this claim is substantially similar to claim 4 and is therefore rejected using the same references and rationale.
Regarding Claim 12:
With regards to claim 12, this claim is substantially similar to claim 5 and is therefore rejected using the same references and rationale.
Regarding claim 16:
WORMAN in view of GAO in further view of ALALAO teaches the limitations within claim 15 and WORMAN does not disclose, but GAO teaches:
the autonomous vehicle, (see at least WORMAN, ¶ 0043, “The roadside unit (RSU) 30 is provided at the test facility and is used to obtain information concerning the test facility, such as the presence and/or status of vehicles. In at least one embodiment, the RSU 30 receives basic safety messages (BSMs) or other vehicle status messages from one or more vehicles at the test facility, such as the test vehicle 10. The vehicle status messages, which may be BSMs, specify certain vehicle status information, such as the location of the vehicle (e.g., a GPS location of the vehicle), the speed of the vehicle, the heading of the vehicle, and/or various other vehicle state information. The RSU 30 may also transmit traffic status messages to one or more vehicles or devices indicating a status of nearby traffic, such as the vehicle status information of other nearby vehicles. The RSU 30 may also be communicatively coupled to one or more traffic infrastructure sensors, which are sensors that capture information pertaining to traffic within the test facility. An example of a traffic infrastructure sensor is a camera that is positioned to face an intersection or road, and another example of a traffic infrastructure sensor is a radar detector that is configured to detect the speed of a vehicle. The RSU 30 is communicatively coupled to the test facility control system 24 via the local network 32 and, in some embodiments, is used to log information that is later sent to the test facility control system 24 and/or the test facility gateway 22. In at least one embodiment, the RSU 30 logs information concerning the vehicle status information that is received and/or sensor data that is obtained by the traffic infrastructure sensors. In another embodiment, the RSU 30 forwards the information concerning the vehicle status information to the test configuration client application 13 of the client device 12, which can then present the information to the test facility user, which can enable the test facility user to trigger certain events at the test facility based on the feedback provided by the information. Also, although only a single RSU is shown, the test facility infrastructure control system 20 may include a plurality of RSUs.”)
the traffic vehicle, and (see at least WORMAN, ¶ 0043; ¶ 0051, “The robotic platform 134 represents any of a number of test environment devices that are robotic (i.e., capable of motion), such as an automated or autonomous passenger car (or other vehicle) or a robotic dummy that may be deployed to a portion of a road of the test facility (or other portion of the test facility) for purposes of testing and that may be used to simulate the presence of a deer or pedestrian in the road or other portion of the test facility. In particular, the robotic dummy is a test-anomaly device, which is a test environment device that is used to introduce the presence of anomalous conditions, such as the presence of an animal or pedestrian on the road at a non-designated area and/or at a non-designated time, such as at a portion of the road that is not a pedestrian crosswalk or at a time when the pedestrian crosswalk signal is red (or set to DO NOT CROSS). The robotic platform 134 includes a test environment controller that controls the functionality or operation of a test environment device, such as the deployable robotic dummy described above, according to the test configuration. The robotic platform 134 includes one or more electromechanical devices that are considered a test environment device and that are controllable by the test environment controller of the robotic platform 134. The robotic platform 134 is communicatively coupled to the test facility control system 124 via a reverse-engineered protocol.”)
WORMAN does not disclose, but GAO teaches:
the one or more received bail thresholds. (see at least GAO, ¶ 0064, "FIG6 shows a schematic block diagram of an apparatus 600 for testing a vehicle according to some embodiments of the present disclosure. The apparatus 600 may be included in or implemented as the control system 102 of FIG. 1 . As shown in FIG6 , the apparatus 600 includes a test status monitoring module 610 configured to monitor a test status associated with a test task during execution of the test task on the vehicle under test. The test status includes at least one of the following: a status of the vehicle under test, a status of a safety protection system for the vehicle under test, and a status of a test device providing a test environment related to the test task. The apparatus 600 further includes a task termination determination module 620 configured to determine whether to terminate the test task based on the test status. The apparatus 600 further includes a test operation execution module 630 configured to execute a test operation corresponding to the test status according to determining that the test task is suspended. ")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
WORMAN in view of GAO does not disclose, but ALALAO teaches:
the user interface is configured to display, as part of the user interface, a graphical representation of (see at least ALALAO, ¶ 0041, “In some embodiments, the second display element includes a graphical representation of a plurality of regions surrounding the autonomous vehicle, and for at least one of the regions, a graphical indication that at least one of the one or more objects is positioned in that region. In some embodiments, presenting the user interface includes generating the second display element based on textual data indicating, for each object, a location of the object with respect to a plurality of two-dimension boxes of a graphical grid. In some embodiments, the textual data indicating the location of the object with respect to the plurality of boxes of the graphical grid comprises one or more data items in a JavaScript Object Notation (JSON) format.”; ¶ 0234, “The map portion 3002 can indicate the location and classification of objects using symbolic icons 3012 (e.g., simplified representations of the objects). Different icons can be used for different classes or types of objects. For instance, FIG. 31 shows several example symbolic icons 3012a-3012e that can be used to represent different classes or types of objects. For example, icons 3012a can be used to represent motor vehicles (e.g., cars, trucks, vans, etc., icons 3012b can be used to represent pedestrians, icons 3012c can be used to represent bicycles, icons 3012d can be used to represent unclassified objects, and icons 3012e can be used to identify construction barricades or traffic cones.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify, with a reasonable expectation of success, the GUI for setting test parameters, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and the collection of data for preventing collisions within WORMAN in view of GAO to perform with the environmental display for visualizing vehicle telemetry of ALALAO to yield a more effective visualization of the nearby vehicles based on the vehicle and environment data collected within WORMAN and GAO.
Regarding claim 17:
WORMAN in view of GAO in further view of ALALAO teaches the limitations within claim 15 and WORMAN does not disclose, but GAO teaches:
that the kinematics data (see at least WORMAN, ¶ 0053, “The method 200 begins with step 205, wherein a test configuration that is specified by a test facility user is received. In one embodiment, the test configuration specifies one or more state of one or more test environment devices and, in a particular embodiment, specifies a single state (or operation) for a single test environment device, which can be used to test individual functionality of the system 20. However, in other embodiments, the test environment device specifies a plurality of various states for a plurality of various test environment devices, and may be used to orchestrate a test that is used to test the test vehicle's responsiveness to a variety of different environmental conditions and traffic conditions, and which may simulate a real-world scenario. In one embodiment, the test facility user uses the test configuration client application 13 of the client device 12 to input information specifying a test configuration that is to be used for testing at the test facility. In such embodiments, the client device 12 can include one or more human-machine interfaces (HMIs), such as a touchscreen display or pushbuttons, which enable the test facility user to input the information specifying the test configuration. The client device 12 then sends one or more test facility configuration messages, which contain information specifying the test configuration, to the test facility gateway 22, which receives the one or more test facility configuration messages specifying the test configuration.”)
WORMAN does not disclose, but GAO teaches:
satisfies the one or more received bail thresholds. (see at least GAO, ¶ 0026, "According to an embodiment of the present disclosure, a solution for testing a vehicle is proposed. In this solution, the control system can coordinate between the vehicle under test, the test equipment that provides the test environment, and the safety protection system for the vehicle under test. During the execution of the test task for the vehicle under test, the control system monitors the test status associated with the test task, including monitoring the status of the vehicle under test, the status of the test equipment, and the status of the safety protection system. The control system then determines whether to terminate the test task based on the monitored test status. In the case where the test task is aborted, the control system may execute subsequent operations corresponding to the monitored test status. In other words, the control system can execute corresponding subsequent operations based on the triggering factor for the test task to be terminated. In this way, the artificial factors introduced into the testing process can be reduced. "; ¶ 0064, "FIG6 shows a schematic block diagram of an apparatus 600 for testing a vehicle according to some embodiments of the present disclosure. The apparatus 600 may be included in or implemented as the control system 102 of FIG. 1 . As shown in FIG6 , the apparatus 600 includes a test status monitoring module 610 configured to monitor a test status associated with a test task during execution of the test task on the vehicle under test. The test status includes at least one of the following: a status of the vehicle under test, a status of a safety protection system for the vehicle under test, and a status of a test device providing a test environment related to the test task. The apparatus 600 further includes a task termination determination module 620 configured to determine whether to terminate the test task based on the test status. The apparatus 600 further includes a test operation execution module 630 configured to execute a test operation corresponding to the test status according to determining that the test task is suspended. ")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine, with a reasonable expectation of success, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and a GUI to allow for configuration of the test environment within WORMAN with the site protection systems for automatically stopping the vehicle based on a collision time threshold within GAO to yield a safer test environment that preserves the test vehicle in the event the speed and heading can lead to a collision.
WORMAN in view of GAO does not disclose, but ALALAO teaches:
the user interface is configured to display a visual representation (see at least ALALAO, ¶ 0041, “In some embodiments, the second display element includes a graphical representation of a plurality of regions surrounding the autonomous vehicle, and for at least one of the regions, a graphical indication that at least one of the one or more objects is positioned in that region. In some embodiments, presenting the user interface includes generating the second display element based on textual data indicating, for each object, a location of the object with respect to a plurality of two-dimension boxes of a graphical grid. In some embodiments, the textual data indicating the location of the object with respect to the plurality of boxes of the graphical grid comprises one or more data items in a JavaScript Object Notation (JSON) format.”; ¶ 0234, “The map portion 3002 can indicate the location and classification of objects using symbolic icons 3012 (e.g., simplified representations of the objects). Different icons can be used for different classes or types of objects. For instance, FIG. 31 shows several example symbolic icons 3012a-3012e that can be used to represent different classes or types of objects. For example, icons 3012a can be used to represent motor vehicles (e.g., cars, trucks, vans, etc., icons 3012b can be used to represent pedestrians, icons 3012c can be used to represent bicycles, icons 3012d can be used to represent unclassified objects, and icons 3012e can be used to identify construction barricades or traffic cones.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify, with a reasonable expectation of success, the GUI for setting test parameters, the test environment data collection RSUs, control systems for evaluation of event-based situations of autonomous vehicles, and the collection of data for preventing collisions within WORMAN in view of GAO to perform with the environmental display for visualizing vehicle telemetry of ALALAO to yield a more effective visualization of the nearby vehicles based on the vehicle and environment data collected within WORMAN and GAO.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
SHANDONG (CN109781431A)
Abstract, “The invention discloses an automatic driving test method and system based on mixed reality. The method comprises the following steps: a virtual test vehicle transmits test data in a virtual environment to a vehicle terminal of a real test vehicle through a cloud server, so that the real test vehicle merges the virtual environment test data with the real environment data, and selects a driving plan according to the merged data; the real test vehicle synchronously uploads the real-time data of a vehicle sensor to the cloud server of a control center, a road surface sensor of a test field synchronously uploads the real-time data of a road surface to the cloud server of the control center, the cloud server sends the received data to a control center calculation platform, and the control center calculation platform updates the virtual environment according to the data provided by the cloud server and adjusts the driving speed and the driving route of the virtual test vehicle; and the control center calculation platform saves the driving parameters of the real test vehicle under the influence of the virtual test environment.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAFAEL VELASQUEZ VANEGAS whose telephone number is (571)272-6999. The examiner can normally be reached M-F 9 - 4.
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, RACHID BENDIDI can be reached at (571) 272-4896. 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.
/RAFAEL VELASQUEZ VANEGAS/Patent Examiner, Art Unit 3664
/JOAN T GOODBODY/Examiner, Art Unit 3664