Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 and 10 and 20 are rejected under 35 U.S.C. sec. 103 as being unpatentable as obvious in view of United States Patent No.: US8965621B1 to Urmson et al. and in view of United States Patent Application Pub. No.: US20200042013A1 to Kelkar.
In regard to claim 1, and claim 10 and 20, URMSON discloses “....1. A method comprising:
obtaining first feature parameters of a vehicle at a first time, wherein the first feature parameters comprise structured semantic information and a road attribute; (see claims 1-14 where the vehicle is monitored in terms of a number of lane changes and as a frequency of lane changes and speed of changing lanes and number of times the vehicle is operated dangerously or safely and if the vehicle is operated within safe parameters)
selecting a first driving scenario class in a scenario feature library based on the first feature parameters; (see FIG. 2-4 where the vehicle will understand that the vehicle ahead of it will turn and therefore, the present vehicle must slow down in the intersection to anticipated the vehicle ahead is going to turn or make some unexpected maneuver; The computer may cause the vehicle to take particular actions in response to the predicted actions of the surrounding objects. For example, if the computer 110 determines that another car approaching the vehicle is turning, for example based on the car's turn signal or in which lane the car is, at the next intersection as noted above, the computer may slow the vehicle down as it approaches the intersection. In this regard, the predicted behavior of other objects is based not only on the type of object and its current trajectory, but also based on some likelihood that the object may or may not obey traffic rules or pre-determined behaviors. This may allow the vehicle not only to respond to legal and predictable behaviors, but also correct for unexpected behaviors by other drivers, such as illegal u-turns or lane changes, running red lights, etc.)
URMSON is silent but KELKAR teaches “...displaying a first prompt prompting a driver that a first driving scenario of the vehicle at the first time is switched to the first driving scenario class; (see paragraph 76 where the vehicle has a display 250; and see paragraph 145 where the second vehicle is traveling too fast and where the first and the second vehicle can include a display prompt that the vehicle is moving too fast and the first or the second vehicle can through negotiation modulate and lower the speed of the second vehicle )
receiving a first instruction corresponding to the first prompt, wherein the first instruction instructs switching from the first driving scenario to the first driving scenario class; and
controlling a driving status of the vehicle based on the first driving scenario class”. (see paragraph 147 to 153 where the first vehicle can indicate a dangerous movement pattern and then provide a scenario to the second vehicle and the second vehicle can then change it’s status to stop the cooperation and then sever the connection between the two vehicles and end the cooperation; ]
Counter parameters may be based on cooperating vehicle profile, historical data in a similar scenario, the type of vehicle that the cooperating vehicle (e.g., recreational vehicle, sedan, truck, all-terrain vehicle, etc., type of roadway (e.g., state highway, residential street, off-road area, etc.). The counter parameter may be used to tailor the cooperating proposal to the cooperative scenario based on past and current data. For example, the negotiation module 226 may determine that the desired traveling speed in the cooperating parameter of the subordinate vehicle 508, exceeds a safety threshold based on historical data for a given roadway on the planned route. Accordingly, the negotiation module 226 may calculate the counter parameter with a lower traveling speed and send the calculated counter parameter to the subordinate vehicle 508.
[0148]
In some embodiments, a counter parameter may not be able to be generated at block 326. For example, a cooperating vehicle may not be able to calculate counter parameters based on other cooperating parameters or safety guidelines. Alternatively, the counter parameter may not be generated due to another cooperating vehicle indicating that it is unwilling to negotiate. If a counter parameter cannot be generated, the method 300 continues to block 328.
[0149]
At block 328, the shared autonomy mode established in the rendezvous stage is terminated. Terminating the shared autonomy mode severs the cooperative pairing between the cooperating vehicles for a current instance. However, it may not a bar to future cooperative pairings between the cooperating vehicles. In some embodiments, terminating the shared autonomy mode may cause a cooperating vehicle to reenter the rendezvous stage in an attempt to identify other cooperating vehicles. So that the cooperating vehicles do not enter into a loop of initiating and terminating a shared autonomy mode, once a shared autonomy mode is terminated, the cooperating vehicles involved may be temporarily barred from re-initiating the shared autonomy mode for a predetermined amount of time and/or mileage. )
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of KELKAR with a reasonable expectation of success since KELKAR teaches that a first and a second vehicle can undergo a cooperation relationship. The two vehicles can provide an autonomous function and a cooperation and relative positioning of the two vehicles. The first vehicle can provide instructions that the second vehicle is operating too fast and can command the second vehicle with a slow down function. The second vehicle can abide by this command for increased safety or can terminate the relationship between the two vehicles by a rejection prompt. This can provide an improved safe operation as the two vehicles can be controlled as a group and maintain the positioning between the two vehicles.
Claims 2-4 and 11-13 are rejected under 35 U.S.C. sec. 103 as being unpatentable as obvious in view of United States Patent No.: US8965621B1 to Urmson et al. and in view of United States Patent Application Pub. No.: US20200042013A1 to Kelkar and in view of United States Patent Application Pub. No.: US20240132060A1 to Newman filed in 2016.
In regard to claim 2 and claim 11, URMSON is silent but KELKAR teaches “...2. The method of claim 1, wherein selecting the first driving scenario class comprises performing a first comparison of the first feature parameters with standard feature parameters of a standard scenario in the scenario feature library, wherein the scenario feature library comprises N driving scenario classes, wherein each of the N driving scenario classes comprises M standard scenarios, wherein both N and M are positive integers, wherein a total similarity of each driving scenario class in the scenario feature library to a current driving scenario of the vehicle at a current moment is based on the first comparison, (see paragraph 147 to 153 where the first vehicle can indicate a dangerous movement pattern and then provide a scenario to the second vehicle and the second vehicle can then change it’s status to stop the cooperation and then sever the connection between the two vehicles and end the cooperation; ]
Counter parameters may be based on cooperating vehicle profile, historical data in a similar scenario, the type of vehicle that the cooperating vehicle (e.g., recreational vehicle, sedan, truck, all-terrain vehicle, etc., type of roadway (e.g., state highway, residential street, off-road area, etc.). The counter parameter may be used to tailor the cooperating proposal to the cooperative scenario based on past and current data. For example, the negotiation module 226 may determine that the desired traveling speed in the cooperating parameter of the subordinate vehicle 508, exceeds a safety threshold based on historical data for a given roadway on the planned route. Accordingly, the negotiation module 226 may calculate the counter parameter with a lower traveling speed and send the calculated counter parameter to the subordinate vehicle 508.
[0148]
In some embodiments, a counter parameter may not be able to be generated at block 326. For example, a cooperating vehicle may not be able to calculate counter parameters based on other cooperating parameters or safety guidelines. Alternatively, the counter parameter may not be generated due to another cooperating vehicle indicating that it is unwilling to negotiate. If a counter parameter cannot be generated, the method 300 continues to block 328.
[0149]
At block 328, the shared autonomy mode established in the rendezvous stage is terminated. Terminating the shared autonomy mode severs the cooperative pairing between the cooperating vehicles for a current instance. However, it may not a bar to future cooperative pairings between the cooperating vehicles. In some embodiments, terminating the shared autonomy mode may cause a cooperating vehicle to reenter the rendezvous stage in an attempt to identify other cooperating vehicles. So that the cooperating vehicles do not enter into a loop of initiating and terminating a shared autonomy mode, once a shared autonomy mode is terminated, the cooperating vehicles involved may be temporarily barred from re-initiating the shared autonomy mode for a predetermined amount of time and/or mileage. )
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of KELKAR with a reasonable expectation of success since KELKAR teaches that a first and a second vehicle can undergo a cooperation relationship. The two vehicles can provide an autonomous function and a cooperation and relative positioning of the two vehicles. The first vehicle can provide instructions that the second vehicle is operating too fast and can command the second vehicle with a slow down function. The second vehicle can abide by this command for increased safety or can terminate the relationship between the two vehicles by a rejection prompt. This can provide an improved safe operation as the two vehicles can be controlled as a group and maintain the positioning between the two vehicles.
The primary reference is silent but Newman teaches “...and wherein the first driving scenario class with a highest total similarity in the N driving scenario classes is as the first driving scenario at the first time”. (see paragraph 21-26 where a predetermined sequence from a number of different trajectories that best fits this instance is used and then from that similar one it is fine turned to as provide a trajectory that is best to avoid the vehicle and object for collision avoidance)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of NEWMAN with a reasonable expectation of success since NEWMAN teaches that a first and a second vehicle can be predicted to crash at some future time. The second vehicle can access a sequence of operations of steering, acceleration and braking to avoid the crash and if the crash cannot be avoided will allow the crash with a sequence to avoid personal injury or property damage. See abstract.
In regard to claim 3 and 12, the primary reference is silent but Newman teaches “...3. The method of claim 2, further comprising obtaining a future road attribute of a future driving scenario of the vehicle in a preset future time period after the first time, wherein selecting the first driving scenario class further comprises performing a second comparison of the future road attribute with a standard road attribute of the standard scenario, and wherein the total similarity of each driving scenario class is based on the first comparison and the second comparison”. (see paragraph 175-180 where the standard sequence to avoid a collision is applied in the future however none of them can avoid the collision and a collision is imminent based on the road traffic being too close together and instead an accident with the least harm is the scenario that is selected so little property damage occurs and no injuries; Turning now to FIG. 8 , a flowchart shows a method according to present principles, in minimal form. Using data from the external sensors, a second vehicle is detected (801). Future positions of the second vehicle are projected forward in time. Future positions of the subject vehicle are also projected forward in time, assuming that a specific collision-avoidance sequence of actions is implemented on the subject vehicle, thereby causing the subject vehicle to accelerate in various ways (802). If the vehicles are projected (803) to avoid a collision according the sequence of actions, then that sequence of actions is implemented as the “collision-avoidance actions” (805). If however the vehicles are projected to collide for every specified collision-avoidance sequence of actions, then a minimum-harm sequence of actions is selected (804), by choosing the already-analyzed sequence with the least predicted harm, and possibly by analyzing further sequences. Then, the selected “minimum-harm actions” are implemented (806). These steps are repeated as further sensor data becomes available, thereby adapting to the changing scenario in real time.
[0177]
In most cases, in regular driving, the second vehicle is found not to be on a collision course with the subject vehicle, and therefore no collision-avoidance actions are needed. Preferably, then, the first sequence to be tested (802) is to simply do nothing (the “null sequence”). In that case there is no projected collision if the subject vehicle is driven according to the null sequence, and so the null sequence becomes the collision-avoidance sequence (805), with no further searching. The task is finished.
[0178]
Of more interest is a case where the second vehicle is on a collision course with the subject vehicle. The null sequence would result in a collision, so evasive action is needed. Although not detailed in the flowchart, the method includes testing multiple sequences of actions comprising different types, magnitudes, durations, and timing of various accelerations of the subject vehicle. For each such sequence, the position of the subject vehicle is again projected forward in time to determine if the collision can be avoided thereby. If so, the successful sequence becomes the collision-avoidance sequence which is then implemented (805). If all of the sequences fail to avoid the collision, then a sequence that results in a collision with the least harm is selected as the minimum-harm sequence (804), and it is implemented (806).
[0179]
Optionally, selection of the minimum-harm sequence (804) may include reanalyzing the various sequences considered during the collision-avoidance stage (802) as well as other sequences not previously analyzed, and calculating the harm expected based on the collision parameters (such as the relative velocities and point of contact of the two vehicles). This obtains the minimum-harm sequence of actions (804), but it takes extra time for the harm minimization projections and analyses (803). Alternatively, the system may store in memory the collision parameters that are derived for each sequence analyzed during the collision-avoidance analysis stage (802), so that these results can easily be recalled if they are needed to select the minimum-harm sequence (804). The stored collision parameters for each of the unsuccessful collision-avoidance sequences would be used to estimate the harm for that sequence, and the sequence with the least harm would be implemented (806). This is much faster than reconstructing the vehicle trajectories again if the collision turns out to be unavoidable, and may be useful in addition when like situations are encountered. As a further time-saving option, the harm associated with each of the sequences may be calculated during the collision-avoidance stage (802), and the estimated harm value may be stored along with the sequence. Then the least harm sequence may be selected (804) almost instantly when needed, by selecting the stored sequence that has the least harm. The collision analysis and harm calculations are preferably carried out using separate processors or separate cores of a processor, so as not to slow down the parallel tasks.)”.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of NEWMAN with a reasonable expectation of success since NEWMAN teaches that a first and a second vehicle can be predicted to crash at some future time. The second vehicle can access a sequence of operations of steering, acceleration and braking to avoid the crash and if the crash cannot be avoided will allow the crash with a sequence to avoid personal injury or property damage. See abstract.
In regard to claim 4 and 13, Newman teaches “...4. The method of claim 1, further comprising:
selecting a second driving scenario class in the scenario feature library as a second driving scenario at a second time; and(see paragraph 175-180 where the standard sequence to avoid a collision is applied in the future however none of them can avoid the collision and a collision is imminent based on the road traffic being too close together and instead an accident with the least harm is the scenario that is selected so little property damage occurs and no injuries; Turning now to FIG. 8 , a flowchart shows a method according to present principles, in minimal form. Using data from the external sensors, a second vehicle is detected (801). Future positions of the second vehicle are projected forward in time. Future positions of the subject vehicle are also projected forward in time, assuming that a specific collision-avoidance sequence of actions is implemented on the subject vehicle, thereby causing the subject vehicle to accelerate in various ways (802). If the vehicles are projected (803) to avoid a collision according the sequence of actions, then that sequence of actions is implemented as the “collision-avoidance actions” (805). If however the vehicles are projected to collide for every specified collision-avoidance sequence of actions, then a minimum-harm sequence of actions is selected (804), by choosing the already-analyzed sequence with the least predicted harm, and possibly by analyzing further sequences. Then, the selected “minimum-harm actions” are implemented (806). These steps are repeated as further sensor data becomes available, thereby adapting to the changing scenario in real time.
[0177]
In most cases, in regular driving, the second vehicle is found not to be on a collision course with the subject vehicle, and therefore no collision-avoidance actions are needed. Preferably, then, the first sequence to be tested (802) is to simply do nothing (the “null sequence”). In that case there is no projected collision if the subject vehicle is driven according to the null sequence, and so the null sequence becomes the collision-avoidance sequence (805), with no further searching. The task is finished.
[0178]
Of more interest is a case where the second vehicle is on a collision course with the subject vehicle. The null sequence would result in a collision, so evasive action is needed. Although not detailed in the flowchart, the method includes testing multiple sequences of actions comprising different types, magnitudes, durations, and timing of various accelerations of the subject vehicle. For each such sequence, the position of the subject vehicle is again projected forward in time to determine if the collision can be avoided thereby. If so, the successful sequence becomes the collision-avoidance sequence which is then implemented (805). If all of the sequences fail to avoid the collision, then a sequence that results in a collision with the least harm is selected as the minimum-harm sequence (804), and it is implemented (806).
[0179]
Optionally, selection of the minimum-harm sequence (804) may include reanalyzing the various sequences considered during the collision-avoidance stage (802) as well as other sequences not previously analyzed, and calculating the harm expected based on the collision parameters (such as the relative velocities and point of contact of the two vehicles). This obtains the minimum-harm sequence of actions (804), but it takes extra time for the harm minimization projections and analyses (803). Alternatively, the system may store in memory the collision parameters that are derived for each sequence analyzed during the collision-avoidance analysis stage (802), so that these results can easily be recalled if they are needed to select the minimum-harm sequence (804). The stored collision parameters for each of the unsuccessful collision-avoidance sequences would be used to estimate the harm for that sequence, and the sequence with the least harm would be implemented (806). This is much faster than reconstructing the vehicle trajectories again if the collision turns out to be unavoidable, and may be useful in addition when like situations are encountered. As a further time-saving option, the harm associated with each of the sequences may be calculated during the collision-avoidance stage (802), and the estimated harm value may be stored along with the sequence. Then the least harm sequence may be selected (804) almost instantly when needed, by selecting the stored sequence that has the least harm. The collision analysis and harm calculations are preferably carried out using separate processors or separate cores of a processor, so as not to slow down the parallel tasks.)”.
displaying a second prompt requesting to switch to the second driving scenario class” (see paragraph 207 where the user can select a preference for the machine to avoid accidents where the user input is largely ignored and in favor of the autonomous vehicle setting providing the corrections to a second preference where the user’s inputs control the prompts and have a higher priority than the output of the machine learning module) .
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of NEWMAN with a reasonable expectation of success since NEWMAN teaches that a first and a second vehicle can be predicted to crash at some future time. The second vehicle can access a sequence of operations of steering, acceleration and braking to avoid the crash and if the crash cannot be avoided will allow the crash with a sequence to avoid personal injury or property damage. See abstract.
Claims 5-9 and 14-18 are rejected under 35 U.S.C. sec. 103 as being unpatentable as obvious in view of United States Patent No.: US8965621B1 to Urmson et al. and in view of United States Patent Application Pub. No.: US20200042013A1 to Kelkar and in view of United States Patent Application Pub. No.: US20240132060A1 to Newman filed in 2016 and in view of United States Patent Application Pub. No.: US20230176577A1 to DITTY filed in 2018.
In regard to claim 5 and claim 14, DITTY teaches “...5. The method of claim 4, further comprising keep controlling, based on the first driving scenario class, the driving status when a system does not receive a second instruction within a preset time, wherein the second instruction corresponds to the second prompt and instructs to switch from a current driving scenario of the vehicle to the second driving scenario class.” (see paragraph 287-291, 333-334 and 462 where the processor in the vehicle fails and cannot respond further and then the vehicle offloads the scenario selection to a second different scenario but based on the offloaded GPUS and the serve system to pilot the autonomous vehicle)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of DITTY with a reasonable expectation of success since DITTY teaches that a processor can include a strange behavior. In this manner, the processor can be monitored and then a second server device or GPU can take control of the vehicle to control the vehicle to avoid an accident. The server or autonomous vehicle can include a safety monitor (watchdog) server 4010(10) that monitors all of the other functions running on the CPU cores 4006 and reports status to on-chip hardware or other resources. This can prevent a malfunction and a crash. See paragraph 333-338.
In regard to claim 6 and 15, DITTY teaches “..6. The method of claim 4, further comprising switching the vehicle from a current driving status to a second driving status corresponding to the second driving scenario class when the second driving scenario class is different from a previous driving scenario class at a previous moment and when a current designed operation range of the vehicle matches a first designed operation range corresponding to the second driving scenario class. (see paragraph 463-487 where the software includes a scenario that is different and has a possible software fault and this is reported to the watchdog that the vehicle is operating differently and there is a fault and then a challenge can be provided to the vehicle and then if the vehicle responds correctly the fault is lifted and the scenario is deemed to be acceptable)”.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of DITTY with a reasonable expectation of success since DITTY teaches that a processor can include a strange behavior. In this manner, the processor can be monitored and then a second server device or GPU can take control of the vehicle to control the vehicle to avoid an accident. The server or autonomous vehicle can include a safety monitor (watchdog) server 4010(10) that monitors all of the other functions running on the CPU cores 4006 and reports status to on-chip hardware or other resources. This can prevent a malfunction and a crash. See paragraph 333-338.
In regard to claim 7 and 16, Ditty teaches “..7. The method of claim 6, further comprising maintaining the current driving status when the current designed operation range matches a second designed operation range corresponding to the previous driving scenario class. (see paragraph 463-487 where the software includes a scenario that is different and has a possible software fault and this is reported to the watchdog that the vehicle is operating differently and there is a fault and then a challenge can be provided to the vehicle and then if the vehicle responds correctly the fault is lifted and the scenario is deemed to be acceptable)”.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of DITTY with a reasonable expectation of success since DITTY teaches that a processor can include a strange behavior. In this manner, the processor can be monitored and then a second server device or GPU can take control of the vehicle to control the vehicle to avoid an accident. The server or autonomous vehicle can include a safety monitor (watchdog) server 4010(10) that monitors all of the other functions running on the CPU cores 4006 and reports status to on-chip hardware or other resources. This can prevent a malfunction and a crash. See paragraph 333-338.
In regard to claim 8 and 17, DITTY teaches “...8. The method of claim 4, further comprising sending fault alert information or manual takeover request information when a designed operation range of the vehicle at the second time does not match a designed operation range corresponding to the first driving scenario class or the second driving scenario class. (see paragraph 333 where if the vehicle is not braking correctly then a human can take over the operation of the vehicle as the range of braking parameter does not make sense and is dangerous and see paragraph 463-487 where the software includes a scenario that is different and has a possible software fault and this is reported to the watchdog that the vehicle is operating differently and there is a fault and then a challenge can be provided to the vehicle and then if the vehicle responds correctly the fault is lifted and the scenario is deemed to be acceptable)”.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of DITTY with a reasonable expectation of success since DITTY teaches that a processor can include a strange behavior. In this manner, the processor can be monitored and then a second server device or GPU can take control of the vehicle to control the vehicle to avoid an accident. The server or autonomous vehicle can include a safety monitor (watchdog) server 4010(10) that monitors all of the other functions running on the CPU cores 4006 and reports status to on-chip hardware or other resources. This can prevent a malfunction and a crash. See paragraph 333-338.
In regard to claim 9 and 18, DITTY teaches “...9. The method of claim 1, further comprising:
sending an operation instruction for indicating driving right release and sending a release notification to the driver when the driver has taken over the vehicle; or (see paragraph 333 where if the vehicle is not braking correctly then a human can take over the operation of the vehicle as the range of braking parameter does not make sense and is dangerous and see paragraph 463-487 where the software includes a scenario that is different and has a possible software fault and this is reported to the watchdog that the vehicle is operating differently and there is a fault and then a challenge can be provided to the vehicle and then if the vehicle responds correctly the fault is lifted and the scenario is deemed to be acceptable)”.
sending an operation instruction for indicating safe pullover when the driver has not taken over the vehicle”. (see paragraph 11 where if the driver does not take control then the vehicle will pull over)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of DITTY with a reasonable expectation of success since DITTY teaches that a processor can include a strange behavior. In this manner, the processor can be monitored and then a second server device or GPU can take control of the vehicle to control the vehicle to avoid an accident. The server or autonomous vehicle can include a safety monitor (watchdog) server 4010(10) that monitors all of the other functions running on the CPU cores 4006 and reports status to on-chip hardware or other resources. This can prevent a malfunction and a crash. See paragraph 333-338.
Claim 19 is rejected under 35 U.S.C. sec. 103 as being unpatentable as obvious in view of United States Patent No.: US8965621B1 to Urmson et al. and in view of United States Patent Application Pub. No.: US20200042013A1 to Kelkar and in view of United States Patent Application Pub. No.: US20230176577A1 to DITTY filed in 2018.
DITTY teaches “...19. The system of claim 10, wherein the one or more processors are further configured to:
obtain an instruction instructing the vehicle to terminate intelligent driving of the vehicle; and send a release notification to the driver. (see paragraph 333-4 where a warning that the vehicle is not working correctly and that the server and processor indicate a poor confidence level with the decisions and then a prompt is provided and then a driver can take manual control of the vehicle)”
It would have been obvious for one of ordinary skill in the art before the effective filing date of the present disclosure to combine the disclosure of URMSON with the teachings of DITTY with a reasonable expectation of success since DITTY teaches that a processor can include a strange behavior. In this manner, the processor can be monitored and then a second server device or GPU can take control of the vehicle to control the vehicle to avoid an accident. The server or autonomous vehicle can include a safety monitor (watchdog) server 4010(10) that monitors all of the other functions running on the CPU cores 4006 and reports status to on-chip hardware or other resources. This can prevent a malfunction and a crash. See paragraph 333-338.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected under obviousness double patenting in view of claim 1-5 of U.S. Patent No 12179767 that recites “ [a] system comprising:
a processor configured to:
obtain first feature parameters of a vehicle at a first time and a future road attribute of a future driving scenario of the vehicle in a preset future time period after the first time, wherein the first feature parameters comprise structured semantic information, a road attribute, and a traffic status spectrum; and
select a first driving scenario class in a scenario feature library based on the first feature parameters and the future road attribute;
a display device coupled to the processor and configured to:
display a first prompt prompting a driver that a first driving scenario of the vehicle at the first time is switched to the first driving scenario class; and
receive a first instruction corresponding to the first prompt, wherein the first instruction instructs switching from the first driving scenario to the first driving scenario class; and
a controller coupled to the processor and configured to control a driving status of the vehicle based on the first driving scenario class.”.
The present claims it recites a selection of a scenario in a library.
The claims are otherwise identical. It would have been obvious to provide a watch type device and a music device to trail behind the boat for a pleasure craft to provide a prompt and switching to a class to control the vehicle as claimed as per the cited art above.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEAN PAUL CASS whose telephone number is (571)270-1934. The examiner can normally be reached Monday to Friday 7 am to 7 pm; Saturday 10 am to 12 noon.
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, Scott A. Browne can be reached at 571-270-0151. 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.
/JEAN PAUL CASS/Primary Examiner, Art Unit 3666
Prosecution Insights