Detailed Action
Claims 1-20 are pending.
Claims 1-20 are rejected.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Caldwell et al (Pub. No.: US 2020/0409368 A1).
As per claim 1, Caldwell discloses a system, comprising: - a vehicle having a network comprising a plurality of end points (Caldwell, Fig 8, paragraph 0126-0128, wherein the system 800 may include a vehicle 802, such as vehicle 102. The vehicle 802 may include one or more vehicle computing devices 804, one or more sensor systems 806, one or more emitters 808, one or more communication connections 810, at least one direct connection 812, and one or more drive systems 814.);- a controller (Caldwell, Fig 8, paragraph 0128, 0134, 0137, wherein the vehicle 802 is an autonomous vehicle; however, the vehicle 802 could be any other type of vehicle, such as a semi-autonomous vehicle, or any other system having at least an image capture device (e.g., a camera enabled smartphone). In the illustrated example, the memory 818 of the vehicle computing device(s) 804 stores a localization component 820, a perception component 822, a planning component 824, one or more system controllers 826, and one or more maps 828.), comprising: - an automation management circuit structured to provide an automated action plan (Caldwell, paragraph 0131, wherein the planning component 824 may determine a path, such as planned route 104 (e.g., initial route, planned path, etc.), for the vehicle 802 to follow to traverse through an environment. For example, the planning component 624 may determine various routes and trajectories and various levels of detail. For example, the planning component 824 may determine a route to travel from a first location (e.g., a current location) to a second location (e.g., a target location). In some examples, the planning component 824 may generate an instruction for guiding the autonomous vehicle 802 along at least a portion of the route from a first location to the second location) that includes adaptive logic for modifying operations based on availability of required sensor data of the vehicle for subsequent triggers or actions (Caldwell, paragraph 0093, wherein the vehicle computing system may be configured to cause the vehicle to stop responsive to not receiving further guidance (e.g., subsequent waypoints, completion signal, etc.). paragraph 0098-0099, wherein the vehicle may continue to move operating normal planner guidance (e.g., autonomous control provided by the vehicle computing system) until data associated with a waypoint is received from the service computing device. Responsive to the operator adding a waypoint, the vehicle, at operation 514, may satisfy one or more waypoints received (e.g., drive to each waypoint). In some examples, responsive to receiving a waypoint, the vehicle computing system may validate the waypoint to ensure the waypoint satisfies a safety protocol and/or a remote guidance protocol of the vehicle. In various examples, responsive to receiving a waypoint, the vehicle may generate one or more trajectories to control the vehicle to the waypoint. The vehicle computing system may continually generate trajectories and control the vehicle between subsequent waypoints based on the trajectories.In addition, paragraph 0034, wherein “the vehicle computing system may detect the remote guidance scenario 106 based on sensor data from one or more sensors. The sensor(s) may include cameras, motion detectors, lidar, radar, time of flight, and/or other sensors mounted on the vehicle 102. As will be discussed in greater detail below with respect to FIG. 8, a planner component of the vehicle computing system may be configured to navigate the vehicle 102 along the planned route 104. The planner component may receive processed sensor data from a perception component of the vehicle computing system and may determine one or more trajectories for the vehicle to travel along the planned route 104 based on the sensor data. The trajectories may include a direction, orientation, and/or speed the vehicle may travel through the environment”); - an automation execution circuit structured to provide an automation command in response to the automated action plan (Caldwell, Fig 5, paragraph 0094-0095, wherein the operator may connect to the vehicle computing system responsive to receiving a request (command) for remote guidance. In some examples, the vehicle may be stopped based on an instruction to hold (command), such as that received from a service computing device via a graphical user interface. Alternatively, Caldwell, Fig 7, paragraph 0119-0120, wherein responsive to determining that the vehicle has not encountered a remote guidance scenario (“No” at operation 704), the process may include, at operation 706, the vehicle computing system autonomously controlling the vehicle, such as in a normal planner mode. Responsive to determining that the vehicle has encountered a remote guidance scenario (“Yes” at operation 704), the process may include, at operation 708, sending a request (command) for guidance to a service computing device) and to dynamically adjust execution timing or sequencing based on the availability of required sensor data (Caldwell, Fig 5, paragraph 0020, wherein the safety protocol may include a pre-determined set of conditions for ensuring vehicle safety. The safety protocol may include one or more threshold distances for the vehicle to maintain away from dynamic and/or static objects, maximum yaw rates and/or other criteria associated with safe navigation of the vehicle through the remote guidance scenario. Paragraph 0021, response to dynamic object detection (e.g., yield to agents predicted to enter a path corresponding to the waypoints), follow dynamic objects moving in the same direction as the vehicle (e.g., in the path corresponding to the waypoints), yield as appropriate for right of way at intersections (e.g., four way stops, traffic lights, roundabouts, etc.), stop forward motion if no further guidance received (e.g., another waypoint, instruction to resume navigation, etc.), or the like. Paragraph 0031, wherein the vehicle computing system may connect to the service computing device for guidance input based on a determination that further movement may violate an operations protocol. To ensure a maximum degree of safety, the vehicle computing system may request guidance from a remote operator that may be configured to evaluate a situation and determine a safe route forward. Further, the vehicle computing system may receive the input and may verify that the guidance input results in a safe operation of the vehicle prior to controlling the vehicle according to the input. Paragraph 0073, wherein waypoint 206 and/or orientation 208 validation may include a verification that the vehicle 210 will not violate (e.g., pass) a safety protocol and/or a remote guidance protocol associated with the vehicle 210 navigating according to the waypoint 206 and/or orientation 208. In some instances, such validation may comprise a kinematics/dynamics check (validation) which ensures that the vehicle would be capable of performing such a waypoint transition); and - an automation continuity circuit structured to determine whether an automation interruption event has occurred (Caldwell, Fig 6, paragraph 0116, wherein for example, the process may include determining whether one or more conditions are satisfied. The conditions may include a vehicle velocity below a threshold, a threshold number and/or type of sensors are available, a threshold bandwidth associated with the network connection, a threshold latency associated with the network connection, absence of a vehicle health related fault, or the like), and to provide an automation continuity command in response to the automation interruption event (Caldwell, Fig 5-6, paragraph 0097, 0101, 0108, wherein at operation 510, the vehicle may be stopped in hold. In some examples, the guidance mode 508 may be active while the vehicle is holding. In such examples, the operator may input waypoints and/or orientations for guidance around an obstacle (e.g., navigating a remote guidance scenario); however, due to the hold, the vehicle may not control the vehicle to traverse the environment according to the waypoints. At operation 516, the vehicle may stop and await additional guidance. In some examples, the vehicle may stop at operation 516 based on a determination that it has not yet received follow-on guidance (a subsequent waypoint). In such examples, responsive to receiving a waypoint, the vehicle may start moving again (operation 514). The process may include, at operation 608, receiving input corresponding to a waypoint. The input may be received from an operator associated with the GUI, such as via an input/output device associated with the service computing device. In various examples, the input may include a position and/or orientation (e.g., yaw) of a waypoint. In such examples, the position and/or orientation of the waypoint may represent a location the vehicle will pass while operating in a guidance mode, and a direction the vehicle will face at the location), wherein the automation continuity command includes instructions to delay, modify, or reschedule operations until the required sensor data becomes available (Caldwell, paragraph 0095, wherein the vehicle may be stopped in a Go (e.g., movement authorized) or a NoGo (e.g., movement not authorized) mode. The Go mode may represent a mode in which a temporary delay is necessary prior to forward progress. In some examples, the temporary delay may be based on a time necessary to input and/or validate a waypoint. In some examples, the temporary delay may be based on a satisfaction of a safety protocol and/or remote guidance protocol. For example, the vehicle computing device may detect another vehicle in front of the vehicle has stopped. To maintain a safe distance behind the other vehicle, the vehicle computing device may stop the vehicle in Go mode);
Examiner Note: The components labeled as the ‘automation continuity circuit,’ ‘automation management circuit,’ and ‘automation execution circuit’ are asserted to form integral parts of a unified controller. Caldwell 's system, as depicted in Fig 8, paragraph 0128 as an example, accomplishes the described functions through an ‘vehicle/service computing device ' Consequently, it is to be inferred that the computing device inherently encompasses all essential circuits required to execute the aforementioned functions.
As pre claim 2, claim 1 is incorporated and Caldwell further discloses wherein the automation continuity circuit is further structured to provide the automation continuity command as a cancel command (Caldwell, Fig 5-6, paragraph 0017, wherein the operator may be able to provide guidance to the vehicle to navigate through the remote guidance scenario, such as around obstacle(s) associated therewith. The input may include one or more waypoints. The waypoint(s) may include locations over which the vehicle will travel. In various examples, the waypoint(s) may each include stopping points. In such examples, the vehicle may be configured to stop at each of the waypoint(s), such as absent receipt or verification of a subsequent waypoint. The command to stop the vehicle is considered to be the cancel command. Alternatively, paragraph 0023 teaches the vehicle computing system may determine that a waypoint is less than a threshold distance from a cement barrier. Based on the determination, the vehicle computing system may reject the waypoint and send a message to the service computing device indicating that the distance is less than the threshold distance; wherein the rejecting of the waypoint can be the cancel command. Alliteratively, paragraph 0036 teaches a cancel command that cause the vehicle to come to stop);
As pre claim 3, claim 1 is incorporated and Caldwell discloses wherein the automation continuity circuit is further structured to provide the automation continuity command as a restart command (Caldwell, paragraph 0027, wherein the service computing device may determine that a scenario is complete (e.g., vehicle passes obstacle, can resume normal operations) and may release the vehicle from the remote guidance; wherein the releasing of the vehicle and/or the resuming of the vehicle to normal operations can be the restart command);
As pre claim 4, claim 1 is incorporated and Caldwell discloses wherein the automation continuity circuit is further structured to provide the automation continuity command as a stage command comprising a stage of the automated action plan at which the automated action plan is to be resumed (Caldwell, paragraph 0027, wherein the service computing device may determine that a scenario is complete (e.g., vehicle passes obstacle, can resume normal operations) and may release the vehicle from the remote guidance; wherein the releasing of the vehicle and/or the resuming of the vehicle to normal operations can be the resume command);
As pre claim 5, claim 1 is incorporated and Caldwell discloses wherein the automation continuity circuit is further structured to provide the automation continuity command as a continuation command (Caldwell, paragraph 0027, wherein the service computing device may determine that a scenario is complete (e.g., vehicle passes obstacle, can resume normal operations) and may release the vehicle from the remote guidance; wherein the releasing of the vehicle and/or the resuming of the vehicle to normal operations can be the continuity command);
As pre claim 6, claim 1 is incorporated and Caldwell further discloses wherein the automation interruption event comprises a vehicle shutdown event (Caldwell, Fig 6, paragraph 0116, wherein for example, the process may include determining whether one or more conditions are satisfied. The conditions may include a vehicle velocity below a threshold, a threshold number and/or type of sensors are available, a threshold bandwidth associated with the network connection, a threshold latency associated with the network connection, absence of a vehicle health related fault, or the like; wherein a vehicle velocity below 1 mile/hour as an example can be a vehicle shutdown event);
As pre claim 7, claim 1 is incorporated and Caldwell discloses wherein the automation interruption event comprises a trigger event interruption for a trigger event associated with the automated action plan (Caldwell, Fig 6, paragraph 0116, wherein for example, the process may include determining whether one or more conditions are satisfied. The conditions may include a vehicle velocity below a threshold, a threshold number and/or type of sensors are available, a threshold bandwidth associated with the network connection, a threshold latency associated with the network connection, absence of a vehicle health related fault, or the like);
As pre claim 8, claim 1 is incorporated and Caldwell discloses wherein the automation interruption event comprises an operational interruption event comprising an indication of at least one of: a determination that a vehicle operating condition precludes completion of the automated action plan, a determination that a vehicle operating condition precludes continuation of the automated action plan, or a determination that a vehicle operating condition precludes execution of at least one aspect of the automated action plan (Caldwell, Fig 6, paragraph 0116, wherein for example, the process may include determining whether one or more conditions are satisfied. The conditions may include a vehicle velocity below a threshold, a threshold number and/or type of sensors are available, a threshold bandwidth associated with the network connection, a threshold latency associated with the network connection, absence of a vehicle health related fault, or the like);
As pre claim 9, claim 1 is incorporated and Caldwell discloses wherein the automated action plan comprises a portion of a policy, wherein the policy comprises a continuity description, and wherein the automation continuity circuit is further structured to determine whether the automation interruption event has occurred in response to the continuity description (Caldwell, paragraph 0030, wherein a remote guidance system may determine a deviation from a planned route 104 (e.g., initial route, planned path, etc.) based on a detection of a remote guidance scenario 106 (e.g., an obstruction on the planned route 104 around which the vehicle may not be configured to determine a viable path). The remote guidance scenario 106 may include a scenario in which a vehicle computing system is not programmed to perform and/or a scenario that appears to violate an operations protocol (e.g., a trajectory required to navigate the scenario would violate the operations protocol (e.g., control policy)). The operations protocol may include one or more rules governing actions the vehicle may or may not take such as not crossing a double yellow line, not driving into oncoming traffic lanes, not exceeding the bounds of a drivable surface of a road, or the like);
As pre claim 10, claim 1 is incorporated and Caldwell discloses wherein the automated action plan comprises a portion of a policy, wherein the policy comprises a continuity description, and wherein the automation continuity circuit is further structured to provide the automation continuity command in response to the continuity description (Caldwell, paragraph 0030, wherein a remote guidance system may determine a deviation from a planned route 104 (e.g., initial route, planned path, etc.) based on a detection of a remote guidance scenario 106 (e.g., an obstruction on the planned route 104 around which the vehicle may not be configured to determine a viable path). The remote guidance scenario 106 may include a scenario in which a vehicle computing system is not programmed to perform and/or a scenario that appears to violate an operations protocol (e.g., a trajectory required to navigate the scenario would violate the operations protocol (e.g., control policy)). The operations protocol may include one or more rules governing actions the vehicle may or may not take such as not crossing a double yellow line, not driving into oncoming traffic lanes, not exceeding the bounds of a drivable surface of a road, or the like);
Claims 11-20 are rejected under the same rationale as claims 1-10.
Response to Arguments
Applicant's arguments filed on 02/27/2026 have been fully considered but they are not persuasive. Applicant argues in remarks:
(1) Caldwell's described behavior that the Examiner relies upon is keyed to the presence or absence of remote guidance information. For example, Caldwell explains that "the vehicle computing system may be configured to cause the vehicle to stop responsive to not receiving further guidance (e.g., subsequent waypoints, completion signal, etc.). Caldwell likewise states that the vehicle may continue operating "until data associated with a waypoint is received from the service computing device" (paragraph 98), and may "stop and await additional guidance" when follow-on guidance (e.g., a subsequent waypoint) has not been received (see, for example, paragraph 101 of Caldwell). These disclosures concern receipt or non-receipt of waypoint/guidance data from a remote service computing device, not the availability of required on-vehicle sensor data.
(1) Examiner respectively disagrees.
Although, the waypoint/guidance data are received from a remote service computing device, the waypoint/guidance data are generated based on on-vehicle sensor data. Thus, availability of on-vehicle sensor data causes the generation of a waypoint which causes this waypoint to be available to the vehicle computing system which then modifies the operation of vehicle (for example causes the vehicle to stop). Fig 3, and paragraph 0082-0083 states “At operation 302, a service computing device may receive a request for guidance from a vehicle computing system. The vehicle computing system may send the request for guidance based on a detection of a remote guidance scenario 106 in an operating environment. The remote guidance scenario 106 may include an obstacle, road blockage, construction zone in the road, or the like. The remote guidance scenario 106 may include a scenario in which the vehicle computing system is not programmed to perform and/or a scenario that appears to violate an operations protocol and/or a safety protocol associated with the vehicle 102. As above, such a scenario may be detected in anticipation of the vehicle approaching the scenario such that guidance can be relayed prior to stopping so that the vehicle does not have to stop at all.Responsive to receiving the request for guidance, the service computing device may process the request and launch a graphical user interface (GUI). The GUI may include an interface through which an operator may provide guidance input to the vehicle. The GUI may be configured to receive input corresponding to a first waypoint 112(1) (e.g. first position) for the vehicle to navigate the remote guidance scenario 106 (e.g., around an obstacle)”
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
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, Wing Chan can be reached at (571) 272-7493. 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.
/HAMZA N ALGIBHAH/ Primary Examiner, Art Unit 2441
Prosecution Insights