DETAILED ACTION
Response to Amendment
This office action regarding application number 18/473,576, filed September 25, 2023, is in response to the applicants arguments and amendments filed February 4, 2026. Claims 1, 3, 8, 10, 18, and 19 have been amended. Claims 1-20 are currently pending and are addressed below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
The applicants arguments and amendments to the application have overcome some of the objections and rejections previously set forth in the Non-Final action mailed November 12, 2025. Applicants amendments to the specification have been deemed sufficient to overcome the previous objections, therefore the objections are withdrawn. Applicants amendments to claims 1 and 8 have been deemed sufficient to overcome the previous objections through the correction of minor typographical errors, therefore the objections are withdrawn.
However Applicants amendments and arguments with regards to claims 1, 8, and 18 have NOT been deemed sufficient to overcome the previous 35 USC 102 rejections therefore the rejections are maintained with changes to reflect amendments. Additionally the applicants arguments have been fully considered but are not fully persuasive for the reasons seen below.
On pages 11 the applicant argues “First, Yen does not disclose features offering determining, using a VCS (or otherwise), a criticality level of an issue on a vehicle. Second, Yen does not disclose features offering determining, using the VCS (or otherwise), at least one action to perform with respect to the vehicle where the at least one action is associated with the criticality level. These features are provided for in independent claim 1. Applicant has reviewed Yen and found nothing that would be relevant to these features. On page 5 of the Office Action, the Examiner argues that Yen discloses "determining, using the VCS, a criticality level of the issue," and cites paragraph [0076] of Yen in support of his position. It is respectfully submitted that Yen appears to disclose fault characteristic, but does not disclose a criticality level of an issue. As disclosed in Yen, a fault characteristic appears to be a type of fault, e.g., whether a fault is transient or permanent. At paragraph [0075], Yen discloses that a transient fault may be a "fault that lasts for a particular period of time" or may be a "temporary error," while a permanent fault may be a "fault that remains permanently." A type of a fault or a characteristic of a fault are not equivalent to a criticality level of a fault or an issue. A characteristic of a fault does is not equivalent to a criticality level of a fault, and Yen does not disclose any sort of criticality level associated with a fault.”, the examiner respectfully disagrees.
MPEP 2142-2144 discusses the requirements for a case of obviousness using 35 USC 103 and provides examples of such cases. MPEP 2111 discusses Broadest Reasonable Interpretation and the interpretation of claims.
As discussed in the rejections below Yen teaches determining a criticality level of the issue (Paragraph [0076], "Determining a fault characteristic (e.g., transient v. permanent) may include suspending trajectory actions of the autonomous vehicle and retaining output values at different modules of the system while repeating the analysis of or calculation based on the sensor output," here the system is determining a characteristic/criticality level of the detected fault); here while Yen is not explicitly using the term criticality level, the fault characteristic taught by Yen is performing the same function as a criticality level.
A criticality level a fault indicates the severity level or level of importance of a fault in terms of vehicle operations. Yen teaches determining the difference between a transient and a permanent fault, the permanent fault being more serious and requiring more drastic safety measures, Yen even goes so far as to differentiate between minor errors/transient not requiring major responses such as those required by permanent faults (Paragraph [0026], “Some of the advantages of these techniques include improving the determination and handling of transient faults. A determination of a transient fault, and the subsequent lack of a fault upon reprocessing, can advantageously lead to an avoidance of drastic safety measures (e.g., ceasing operation of the autonomous vehicle or causing the vehicle to pull over), and improve operation of an autonomous vehicle. Further, the techniques can allow for the handling of minor errors without taking major responses by the autonomous vehicle. An additional advantage of these techniques includes improving the efficiency of confirming and isolating permanent faults.”). Therefore while Yen does not use the explicit language “criticality level” the fault characteristic indicating a permanent or transient fault is performing the same function and is analogous.
Therefore Yen teaches determining a criticality level of the issue, and the rejections under 35 USC 102 are maintained.
On pages 11-12 the applicant argues “The Examiner also argues that Yen discloses the claimed feature of "determining, using the VCS, at least one action to perform with respect to the vehicle, the at least one action being associated with the criticality level, wherein determining the at least one action to perform includes determining whether to accept a first trajectory update generated by the trajectory generation system." The cited passages of Yen appear to disclose performing an action based on a parameter that is indicative of a fault being present ("in response to determining that the fault parameter 512 is indicative of a fault being present, the processor performs operations...."), which is not equivalent to determining an action that is associated with a criticality level. Claim 1 recites performing an action associated with a criticality level, whereas Yen discloses performing an operation (action) based on a fault being present with no consideration of a criticality level. Further, Yen does not disclose that determining at least one action to perform (based on a criticality level) includes determining whether to accept a first trajectory update. It is respectfully submitted that although the Examiner argues on pages 5 and 6 of the Office Action that Yen discloses that determining a fault characteristic may include suspending trajectory actions, suspending trajectory actions is not equivalent to determining whether to accept a trajectory update. Determining a fault characteristic is not equivalent to determining at least one action to perform based on a criticality level, and suspending trajectory actions is not equivalent to determining whether to accept a first trajectory update.”, the examiner respectfully disagrees.
MPEP 2142-2144 discusses the requirements for a case of obviousness using 35 USC 103 and provides examples of such cases. MPEP 2111 discusses Broadest Reasonable Interpretation and the interpretation of claims.
As discussed in the rejections below Yen teaches determining, using the VCS, a least one action to perform with respect to the vehicle, the at least one action being associated with the criticality level (Paragraph [0085], "in response to determining that the fault parameter 512 is indicative of a fault being present, the processor performs operations including applying or executing an initial fault scheme. The initial fault scheme may be selected or performed based at least in part on the fault parameter 512," here the system can take actions in the form of implementing a fault response scheme depending on the fault characteristic/criticality level) (Paragraph [0100], "Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here the system can take actions depending on the fault scheme including stopping, slowing, or pulling over); here the system is determining that fault is present and the system can further tailor the response depending on the specific criticality level/fault parameter (as discussed above) (Paragraph [0026], “A determination of a transient fault, and the subsequent lack of a fault upon reprocessing, can advantageously lead to an avoidance of drastic safety measures (e.g., ceasing operation of the autonomous vehicle or causing the vehicle to pull over)”); here for example a permanent fault has a specific set of operations for the vehicle to take (Paragraph [0075], “A permanent fault may require the autonomous vehicle to stope operating, to operate at reduced capability, to attempt to safely pull over, or to otherwise be addressed before continuing operation or operation within normal operating parameters.”).
Therefore Yen teaches determining, using the VCS, a least one action to perform with respect to the vehicle, the at least one action being associated with the criticality level, and the rejections under 35 USC 102 are maintained.
On pages 12-14 the applicant argues “Yen does not disclose features offering an issue determination arrangement configured to identify an issue associated with the trajectory generation system. Applicant has reviewed Yen and found nothing that would be relevant to this feature. The Examiner argues, on pages 12 and 13 of the Office Action, that paragraph [0085] of Yen discloses the claimed feature of "wherein the vehicle control system further includes an issue determination arrangement configured to identify an issue associated with the trajectory generation system." The cited paragraph of Yen is provided below for the Examiner's convenience: … It is respectfully submitted that although the cited paragraph discloses the existence of trajectory parameters, there is no disclosure in the cited paragraph of any system which is configured to identify an issue associated with the trajectory generation system. Yen appears to disclose a fault parameter that indicates a fault is present, but does not disclose that the fault parameter is associated with a trajectory generation system, or that a fault is an issue associated with the trajectory generation system.”, the examiner respectfully disagrees.
MPEP 2142-2144 discusses the requirements for a case of obviousness using 35 USC 103 and provides examples of such cases. MPEP 2111 discusses Broadest Reasonable Interpretation and the interpretation of claims.
As discussed in the rejections below Yen teaches identifying an fault/issue associated with a vehicle (Abstract, "Provided are methods for robust fault tolerant architecture, which can include methods for determining transient faults and permanent faults,"); that vehicle including a trajectory generation system (Paragraph [0071], "In some embodiments, control system 408 receives data associated with at least one trajectory from planning system 404 and control system 408 controls operation of the vehicle.").
Yen further teaches that determining whether a processor is associated with the fault (Paragraph [0157], “At decision step 806, the method 800 includes determining whether the first primary processor 716 is associated with a fault. Determining whether the first primary processor 716 is associated with a fault may include determining whether an out of the first primary processor 716 satisfies an expected output and/or whether the output is within a threshold range of an expected output. In some cases, determining whether the first primary processor 716 is associated with a fault may include determining whether an error or error code has been generated.”); further as can be seen in figure 7A the trajectory data 714 is output from the AV computer 740 which includes the first primary processor and the secondary processor. Therefore the system is making a fault determination for a processor that is generating a trajectory, identifying an issue associated with the trajectory generation system.
Therefore Yen teaches identifying an issue associated with the trajectory generation system, and the rejections under 35 USC 102 are maintained.
On pages 14 the applicant argues “By way of example, dependent claim 20, which depends directly from independent claim 15, recites that a vehicle further includes a local issue manager arranged to provide information about an issue to an issue determination arrangement. In other words, a manager provides information about an issue to a determination arrangement. The Examiner argues that Yen discloses this feature. Applicant respectfully submits that the cited paragraph of Yen, and the cited figures, appears to disclose that either a processor, a control system, a fault manager, or a controller detects a fault (issue), but does not disclose any of the processor, control system, fault manager, or controller providing information about the fault to any other system. Accordingly, claim 20 is also believed to be allowable over the cited art for at least this additional reason as well.”, the examiner respectfully disagrees.
MPEP 2142-2144 discusses the requirements for a case of obviousness using 35 USC 103 and provides examples of such cases. MPEP 2111 discusses Broadest Reasonable Interpretation and the interpretation of claims.
As discussed in the rejections below Yen teaches wherein the vehicle further includes a local issue manager arranged to provide information about the issue to the issue determination arrangement (Paragraph [0092], “For example, if the fault is associated with the processor 516A, one or more of the processors 516B or 516C may detect the fault. In some embodiments, the control system 508 or the fault manager 520 (illustrated in FIG. 5E) may detect the presence of the fault or that the fault parameter 512 indicates a fault. In some cases, the processor 516 that generates the fault may also detect the presence of the fault. In some embodiments, the fault may be detected by a controller, such as the controller 750 illustrated in FIG. 7B.”); here the system is reciting a plurality of processors and controllers and the system for example may detect the fault using a fault manager which receives the fault parameter from 516A, this fault parameter indicating a fault.
Yen further provides other details about the fault manager (Paragraph [0102], “As an example, the system 500 provides one or more of the fault parameter 512, the trajectory parameter 514, the secondary trajectory parameter 514, or the output 518A, 518B, 518C of any of the processors 516A, 5168, 516C to a fault manager 520, such as shown in FIG. 5E.”) (See entirety of Paragraph [0102]).
Therefore Yen teaches a vehicle further includes a local issue manager arranged to provide information about an issue to an issue determination arrangement, and the rejections under 35 USC 102 are maintained.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 7-8, 14-15, and 20 is/are rejected under 35 U.S.C. 102(a)(2) and as being anticipated by Yen (US-20230339480).
Regarding claim 1, Yen teaches a method comprising identifying, using a vehicle control system (VCS) of a vehicle, an issue associated with the vehicle (Abstract, "Provided are methods for robust fault tolerant architecture, which can include methods for determining transient faults and permanent faults,")
the vehicle including a trajectory generation system (Paragraph [0068], "In some embodiments, planning system 404 receives data associated with a destination and generates data associated with at least one route (e.g., routes 106) along which a vehicle (e.g., vehicles 102) can travel along toward a destination," here the planning system is generating trajectories)
the vehicle being configured to follow a trajectory generated by the trajectory generation system (Paragraph [0071], "In some embodiments, control system 408 receives data associated with at least one trajectory from planning system 404 and control system 408 controls operation of the vehicle.")
determining, using the VCS, a criticality level of the issue (Paragraph [0076], "Determining a fault characteristic (e.g., transient v. permanent) may include suspending trajectory actions of the autonomous vehicle and retaining output values at different modules of the system while repeating the analysis of or calculation based on the sensor output," here the system is determining a characteristic/criticality level of the detected fault)
determining, using the VCS, a least one action to perform with respect to the vehicle, the at least one action being associated with the criticality level (Paragraph [0085], "in response to determining that the fault parameter 512 is indicative of a fault being present, the processor performs operations including applying or executing an initial fault scheme. The initial fault scheme may be selected or performed based at least in part on the fault parameter 512," here the system can take actions in the form of implementing a fault response scheme depending on the fault characteristic/criticality level) (Paragraph [0100], "Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here the system can take actions depending on the fault scheme including stopping, slowing, or pulling over)
wherein determining the at least one action to perform includes determining whether to accept a first trajectory update generated by the trajectory generation system (Paragraph [0076], "Determining a fault characteristic (e.g., transient v. permanent) may include suspending trajectory actions of the autonomous vehicle and retaining output values at different modules of the system while repeating the analysis of or calculation based on the sensor output,” here depending on the fault characteristic/level the system can suspending/not accept trajectory actions)
and performing the at least one action (Paragraph [0100], "Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here the system can take actions depending on the fault scheme including stopping, slowing, or pulling over)
wherein performing the at least one action includes updating the trajectory using the first trajectory update when it is determined that the first trajectory updated is accepted (Paragraph [0099], "In one or more embodiments or examples, providing the operating data to cause operation of the autonomous vehicle includes, in response to determining that the secondary trajectory parameter 514A meets the trajectory criterion, providing, based on the secondary trajectory parameter 514A, the operating data to cause operation of the autonomous vehicle," here the system can analyze the detected fault to determine a transient or permanent fault, if the system determines that the fault is transient the system accept/implement the secondary trajectory parameter/update)
and wherein performing the at least one action further includes declining the first trajectory update when it is determined that the first trajectory update is not to be accepted (Paragraph [0100], "In one or more embodiments or examples, the system 500, based on the permanent fault scheme, enters a safe state where the system 500 can deploy safety countermeasures, such as minimum risk maneuvers. For example, the system 500 does not operate the autonomous vehicle along the trajectory parameter 514 or secondary trajectory parameter 514A as they can have been affected by the permanent fault. Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here if the system determines that the fault is permanent and not transient, the system will enter a safe state and will not operate the vehicle along/delcine the first trajectory or the trajectory update).
Regarding claim 7, Yen teaches the method as discussed above in claim 1, Yen further teaches wherein the issue is one selected from a group including a fault, a failure, an error, an exception, and a performance degradation associated with the trajectory generation system (Paragraph [0025], “The methods may include determining, using the at least one processor, during the processing, whether a fault parameter or a value for the fault parameter indicative of a fault is present. In response to determining that the fault parameter indicative of a fault is present, the methods may include using the at least one processor to apply an initial fault scheme based on the fault parameter.”).
Regarding claim 8, Yen teaches a vehicle including logic encoded in one or more tangible non-transitory computer-readable media for execution and when executed operable to
generate a trajectory to be followed by the vehicle (Paragraph [0061], “Device 300 performs these processes based on processor 304 executing software instructions stored by a computer-readable medium, such as memory 305 and/or storage component 308. A computer-readable medium (e.g., a non-transitory computer readable medium) is defined herein as a non-transitory memory device. A non-transitory memory device includes memory space located inside a single physical storage device or memory space spread across multiple physical storage devices.”)
wherein the logic operable to generate the trajectory is further operable to generate at least a first trajectory update and to use the first trajectory update to update the trajectory (Paragraph [0068], "In some embodiments, planning system 404 receives data associated with a destination and generates data associated with at least one route (e.g., routes 106) along which a vehicle (e.g., vehicles 102) can travel along toward a destination," here the planning system is generating trajectories) (Paragraph [0068], “planning system 404 periodically or continuously receives data from perception system 402 (e.g., data associated with the classification of physical objects, described above) and planning system 404 updates the at least one trajectory or generates at least one different trajectory based on the data generated by perception system 402”)
identify an issue associated with the vehicle (Abstract, "Provided are methods for robust fault tolerant architecture, which can include methods for determining transient faults and permanent faults,")
determine a criticality level of the issue determining, using the VCS, a criticality level of the issue (Paragraph [0076], "Determining a fault characteristic (e.g., transient v. permanent) may include suspending trajectory actions of the autonomous vehicle and retaining output values at different modules of the system while repeating the analysis of or calculation based on the sensor output," here the system is determining a characteristic/criticality level of the detected fault)
determine at least one action to perform with respect to the vehicle, the at least one action being associated with the criticality level (Paragraph [0085], "in response to determining that the fault parameter 512 is indicative of a fault being present, the processor performs operations including applying or executing an initial fault scheme. The initial fault scheme may be selected or performed based at least in part on the fault parameter 512," here the system can take actions in the form of implementing a fault response scheme depending on the fault characteristic/criticality level) (Paragraph [0100], "Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here the system can take actions depending on the fault scheme including stopping, slowing, or pulling over)
wherein the logic operable to determine the at least one action to perform is operable to determine whether to accept the first trajectory update (Paragraph [0076], "Determining a fault characteristic (e.g., transient v. permanent) may include suspending trajectory actions of the autonomous vehicle and retaining output values at different modules of the system while repeating the analysis of or calculation based on the sensor output,” here depending on the fault characteristic/level the system can suspending/not accept trajectory actions)
and perform the at least one action (Paragraph [0100], "Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here the system can take actions depending on the fault scheme including stopping, slowing, or pulling over)
wherein the logic operable to perform the at least one action includes logic operable to update the trajectory using the first trajectory update when it is determined that the first trajectory update is accepted (Paragraph [0099], "In one or more embodiments or examples, providing the operating data to cause operation of the autonomous vehicle includes, in response to determining that the secondary trajectory parameter 514A meets the trajectory criterion, providing, based on the secondary trajectory parameter 514A, the operating data to cause operation of the autonomous vehicle," here the system can analyze the detected fault to determine a transient or permanent fault, if the system determines that the fault is transient the system accept/implement the secondary trajectory parameter/update)
and wherein the logic operable to perform the at least one action is further operable to decline the first trajectory update when it is determined that the first trajectory update is not to be accepted (Paragraph [0100], "In one or more embodiments or examples, the system 500, based on the permanent fault scheme, enters a safe state where the system 500 can deploy safety countermeasures, such as minimum risk maneuvers. For example, the system 500 does not operate the autonomous vehicle along the trajectory parameter 514 or secondary trajectory parameter 514A as they can have been affected by the permanent fault. Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here if the system determines that the fault is permanent and not transient, the system will enter a safe state and will not operate the vehicle along/delcine the first trajectory or the trajectory update).
Regarding claim 14, claim 14 is similar in scope to claim 7 and therefore is rejected under similar rationale.
Regarding claim 15, Yen teaches a vehicle comprising: a chassis; a propulsion system configured to propel the chassis (Paragraph [0041], “Referring now to FIG. 2, vehicle 200 (which can be the same as, or similar to vehicle 102 of FIG. 1) includes or is associated with autonomous system 202, powertrain control system 204, steering control system 206, and brake system 208. In some embodiments, vehicle 200 is the same as or similar to vehicle 102 (see FIG. 1).”)
a trajectory generation system (Paragraph [0068], "In some embodiments, planning system 404 receives data associated with a destination and generates data associated with at least one route (e.g., routes 106) along which a vehicle (e.g., vehicles 102) can travel along toward a destination," here the planning system is generating trajectories)
the trajectory generation system configured to generate at least one trajectory update, the trajectory generation system further configured to generate a trajectory to be followed by the vehicle (Paragraph [0068], "In some embodiments, planning system 404 receives data associated with a destination and generates data associated with at least one route (e.g., routes 106) along which a vehicle (e.g., vehicles 102) can travel along toward a destination," here the planning system is generating trajectories) (Paragraph [0068], “planning system 404 periodically or continuously receives data from perception system 402 (e.g., data associated with the classification of physical objects, described above) and planning system 404 updates the at least one trajectory or generates at least one different trajectory based on the data generated by perception system 402”)
and a vehicle control system (Paragraph [0041], “Referring now to FIG. 2, vehicle 200 (which can be the same as, or similar to vehicle 102 of FIG. 1) includes or is associated with autonomous system 202, powertrain control system 204, steering control system 206, and brake system 208. In some embodiments, vehicle 200 is the same as or similar to vehicle 102 (see FIG. 1).”)
the vehicle control system includes a trajectory execution arrangement configured to execute the trajectory (Paragraph [0041], “In some embodiments, autonomous system 202 is configured to confer vehicle 200 autonomous driving capability (e.g., implement at least one driving automation or maneuver-based function, feature, device, and/or the like that enable vehicle 200 to be partially or fully operated without human intervention including, without limitation, fully autonomous vehicles (e.g., vehicles that forego reliance on human intervention such as Level 5 ADS-operated vehicles)”)
wherein the vehicle control system further includes an issue determination arrangement configured to identify an issue associated with the trajectory generation system (Paragraph [0085], "in response to determining that the fault parameter 512 is indicative of a fault being present, the processor performs operations including applying or executing an initial fault scheme. The initial fault scheme may be selected or performed based at least in part on the fault parameter 512," here the system can take actions in the form of implementing a fault response scheme depending on the fault characteristic/criticality level)
to identify a category for the issue (Paragraph [0076], "Determining a fault characteristic (e.g., transient v. permanent) may include suspending trajectory actions of the autonomous vehicle and retaining output values at different modules of the system while repeating the analysis of or calculation based on the sensor output," here the system is determining a characteristic/criticality level of the detected fault)
and to perform at least one action based on the category (Paragraph [0100], "Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here the system can take actions depending on the fault scheme including stopping, slowing, or pulling over).
Regarding claim 20, Yen teaches the system as discussed above in claim 15, Yen further teaches wherein the issue is one selected from a group including a fault, a failure, an error, an exception, and a performance degradation associated with the trajectory generation system (Paragraph [0025], “The methods may include determining, using the at least one processor, during the processing, whether a fault parameter or a value for the fault parameter indicative of a fault is present. In response to determining that the fault parameter indicative of a fault is present, the methods may include using the at least one processor to apply an initial fault scheme based on the fault parameter.”)
and wherein the vehicle further includes a local issue manager arranged to provide information about the issue to the issue determination arrangement (Paragraph [0092], “For example, if the fault is associated with the processor 516A, one or more of the processors 516B or 516C may detect the fault. In some embodiments, the control system 508 or the fault manager 520 (illustrated in FIG. 5E) may detect the presence of the fault or that the fault parameter 512 indicates a fault. In some cases, the processor 516 that generates the fault may also detect the presence of the fault. In some embodiments, the fault may be detected by a controller, such as the controller 750 illustrated in FIG. 7B.”).
Claim Rejections - 35 USC § 103
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.
Claim 2-6, 9-13, and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yen (US-20230339480) in view of Poeppel (US-20210343092).
Regarding claim 2, Yen teaches the method as discussed above in claim 1, however Yen while Yen teaches a plurality of fault levels, and further teaches wherein when the criticality level is the critical level, performing the at least one action includes declining the first trajectory update (Paragraph [0076], "Determining a fault characteristic (e.g., transient v. permanent) may include suspending trajectory actions of the autonomous vehicle and retaining output values at different modules of the system while repeating the analysis of or calculation based on the sensor output,” here depending on the fault characteristic/level the system can suspending/not accept trajectory actions).
Yen does not explicitly teach wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level.
Poeppel teaches one or more of the actions to take an autonomous vehicle out-of-service based at least in part on a fault including
wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level (Paragraph [0070], “The computing device(s) 110 can be configured to determine an operational state 142 of the vehicle 102 based, at least in part, on the level of severity of the fault 140. The operational state 142 can be indicative of whether the vehicle 102 is in condition to provide a vehicle service to the one or more user(s) 136. For example, the operational state 142 can indicate that the vehicle 102 is in condition to provide the vehicle service to one or more user(s) 136 of the vehicle 102 (e.g., for a minor fault, a stuck window). In some implementations, the operational state 142 can indicate that the vehicle 102 can provide a vehicle service to a current user 136 of the vehicle 102 (e.g., transport the rider to a destination location). In some implementations, the operational state 142 can indicate that the vehicle 102 can selectively provide vehicle services to a user of the vehicle 102. For example, the vehicle 102 can provide a transportation service to a user travelling in the direction of a maintenance location and/or can deny providing a transportation service to a user travelling away from the direction of a maintenance location. In some implementations, the operational state 142 can indicate that the vehicle 102 is not in condition to provide the vehicle service to the one or more user(s) 136 (e.g., for more severe faults),” here the system is outlining different severity levels for faults including indicating a first level where a vehicle can remain in service/non-critical, a level where a vehicle can selectively provide service/intermediate, and a level where a vehicle is not in condition to provide service/critical).
Yen and Poeppel are analogous art as they are both generally related to handling faults in vehicles.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level of Poeppel in the method of handling faults of Yen with a reasonable expectation of success in order to determine a severity of a fault and improve the vehicles ability to appropriately handle the fault based on a plurality of severity levels to tailor vehicle operation (Paragraph [0069], “In another example, the computing device(s) 110 can determine that the level of severity 140 of a fault, such a fire in the vehicle's interior, is higher given the type of fault (e.g., smoke, fire), its associated location (e.g., the vehicle's interior), and/or other characteristics. In this way, the vehicle computing system 108 can improve its ability to take suitable measures to address the fault, given its level of severity.”).
Regarding claim 3, the combination of Yen and Poeppel teaches the method as discussed above in claim 2, Yen further teaches wherein when the criticality level is the critical level, performing the at least one action further includes causing the vehicle to come to a stop (Paragraph [0100], "Safety countermeasures, for example, include the system 500 providing operation data to cause operation of the autonomous vehicle to one or more of: not start, slow down, stop, and pull over," here the system can take actions depending on the fault scheme including stopping, slowing, or pulling over)
and wherein when the criticality level is the non-critical level, performing the at least one action further includes processing the first trajectory update (Paragraph [0099], "In one or more embodiments or examples, providing the operating data to cause operation of the autonomous vehicle includes, in response to determining that the secondary trajectory parameter 514A meets the trajectory criterion, providing, based on the secondary trajectory parameter 514A, the operating data to cause operation of the autonomous vehicle," here the system can analyze the detected fault to determine a transient or permanent fault, if the system determines that the fault is transient/non-critical the system accept/implement the secondary trajectory parameter/update).
However Yen does not explicitly teach wherein when the criticality level is the intermediate level, performing the at least one action further includes causing the vehicle to operate for a predetermined amount of time before causing the vehicle to come to a stop.
Poeppel further teaches wherein when the criticality level is the intermediate level (Paragraph [0070], “The computing device(s) 110 can be configured to determine an operational state 142 of the vehicle 102 based, at least in part, on the level of severity of the fault 140. The operational state 142 can be indicative of whether the vehicle 102 is in condition to provide a vehicle service to the one or more user(s) 136. For example, the operational state 142 can indicate that the vehicle 102 is in condition to provide the vehicle service to one or more user(s) 136 of the vehicle 102 (e.g., for a minor fault, a stuck window). In some implementations, the operational state 142 can indicate that the vehicle 102 can provide a vehicle service to a current user 136 of the vehicle 102 (e.g., transport the rider to a destination location). In some implementations, the operational state 142 can indicate that the vehicle 102 can selectively provide vehicle services to a user of the vehicle 102. For example, the vehicle 102 can provide a transportation service to a user travelling in the direction of a maintenance location and/or can deny providing a transportation service to a user travelling away from the direction of a maintenance location. In some implementations, the operational state 142 can indicate that the vehicle 102 is not in condition to provide the vehicle service to the one or more user(s) 136 (e.g., for more severe faults),” here the system is outlining different severity levels for faults including indicating a first level where a vehicle can remain in service/non-critical, a level where a vehicle can selectively provide service/intermediate, and a level where a vehicle is not in condition to provide service/critical)
performing the at least one action further includes causing the vehicle to operate for a predetermined amount of time before causing the vehicle to come to a stop (Paragraph [0028], “For example, the operational state can indicate that the vehicle is in condition to continue to provide a vehicle service to one or more current user(s). Thus, the vehicle can finish providing the vehicle services (e.g., transporting current riders to their destination location) before taking itself out-of-service, travelling to a maintenance location, etc,” here the system, in response to a operational state indicating an intermediate fault, is permitted to continue performing at least one action including permitting the vehicle to finish the current service which is a predetermined amount of time, before stopping at a maintenance location).
Yen and Poeppel are analogous art as they are both generally related to handling faults in vehicles.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include wherein when the criticality level is the intermediate level, performing the at least one action further includes causing the vehicle to operate for a predetermined amount of time before causing the vehicle to come to a stop of Poeppel in the method of handling faults of Yen with a reasonable expectation of success in order to determine a severity of a fault and improve the vehicles ability to appropriately handle the fault based on a plurality of severity levels to tailor vehicle operation (Paragraph [0069], “In another example, the computing device(s) 110 can determine that the level of severity 140 of a fault, such a fire in the vehicle's interior, is higher given the type of fault (e.g., smoke, fire), its associated location (e.g., the vehicle's interior), and/or other characteristics. In this way, the vehicle computing system 108 can improve its ability to take suitable measures to address the fault, given its level of severity.”).
Regarding claim 4, the combination of Yen and Poeppel teaches the method as discussed above in claim 2, Yen further teaches wherein when the criticality level is one selected from a group including the intermediate level and the non-critical level, performing the at least one action includes updating the trajectory using the first trajectory updated (Paragraph [0099], "In one or more embodiments or examples, providing the operating data to cause operation of the autonomous vehicle includes, in response to determining that the secondary trajectory parameter 514A meets the trajectory criterion, providing, based on the secondary trajectory parameter 514A, the operating data to cause operation of the autonomous vehicle," here the system can analyze the detected fault to determine a transient or permanent fault, if the system determines that the fault is transient/non-critical the system accept/implement the secondary trajectory parameter/update).
Yen does not explicitly teach wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level.
Poeppel teaches one or more of the actions to take an autonomous vehicle out-of-service based at least in part on a fault including
wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level (Paragraph [0070], “The computing device(s) 110 can be configured to determine an operational state 142 of the vehicle 102 based, at least in part, on the level of severity of the fault 140. The operational state 142 can be indicative of whether the vehicle 102 is in condition to provide a vehicle service to the one or more user(s) 136. For example, the operational state 142 can indicate that the vehicle 102 is in condition to provide the vehicle service to one or more user(s) 136 of the vehicle 102 (e.g., for a minor fault, a stuck window). In some implementations, the operational state 142 can indicate that the vehicle 102 can provide a vehicle service to a current user 136 of the vehicle 102 (e.g., transport the rider to a destination location). In some implementations, the operational state 142 can indicate that the vehicle 102 can selectively provide vehicle services to a user of the vehicle 102. For example, the vehicle 102 can provide a transportation service to a user travelling in the direction of a maintenance location and/or can deny providing a transportation service to a user travelling away from the direction of a maintenance location. In some implementations, the operational state 142 can indicate that the vehicle 102 is not in condition to provide the vehicle service to the one or more user(s) 136 (e.g., for more severe faults),” here the system is outlining different severity levels for faults including indicating a first level where a vehicle can remain in service/non-critical, a level where a vehicle can selectively provide service/intermediate, and a level where a vehicle is not in condition to provide service/critical).
Yen and Poeppel are analogous art as they are both generally related to handling faults in vehicles.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level of Poeppel in the method of handling faults of Yen with a reasonable expectation of success in order to determine a severity of a fault and improve the vehicles ability to appropriately handle the fault based on a plurality of severity levels to tailor vehicle operation (Paragraph [0069], “In another example, the computing device(s) 110 can determine that the level of severity 140 of a fault, such a fire in the vehicle's interior, is higher given the type of fault (e.g., smoke, fire), its associated location (e.g., the vehicle's interior), and/or other characteristics. In this way, the vehicle computing system 108 can improve its ability to take suitable measures to address the fault, given its level of severity.”).
Regarding claim 5, the combination of Yen and Poeppel teaches method as discussed above in claim 4, Yen further teaches wherein when the criticality level is the non-critical level, performing the at least one action further includes obtaining at least one instruction in response to the issue and performing the at least one instruction (Paragraph [0097], “This is shown in FIG. 5C. In other words, as the system 500 determines that the fault parameter 512 indicative of a fault is not present during reprocessing, it can be determined that the previous fault is or is likely a transient fault. In some such cases, the system 500 can be configured to discard this transient fault and provide operating data to the control system 508 to cause operation of the autonomous vehicle. Further, as an example, the system 500 un-suspends or resumes the control system 508 from operating the autonomous vehicle, thereby allow for operation to resume.”).
Regarding claim 6, the combination of Yen and Poeppel teaches method as discussed above in claim 4, Yen further teaches wherein when the criticality level is the intermediate level, performing the at least one action further includes
determining a time interval during which the vehicle is to be stopped (Paragraph [0093], “In some such cases, the AV may continue operating or driving at its current trajectory for a particular amount of time, which may correspond to a particular number of frames of sensor data. For example, the AV may continue to operate for an amount of time corresponding to up to 5, 10, 15, frames of data or any amount in between, lesser, or greater than the preceding examples. If it is determined that the fault continues or is likely to continue for longer than the permitted operating time, the AV may take execute additional fault procedures, such as causing the AV to attempt to safely pull over to the side of the road. It should be understood that the amount of time the AV is permitted to continue travelling along a trajectory or operate may depend on context, such as speed of operation, location, type of fault, and the like,” here the system is determining a particular amount of time/time interval that the vehicle needs to stop if the fault is not resolved)
determining at least one performance limit associated with stopping the vehicle during the time interval (Paragraph [0113], “In one or more embodiments or examples, in response to determining that the fault parameter indicative of a fault is not present during the reprocessing, the method includes providing, based on the trajectory parameter or the secondary trajectory parameter, operating data to cause operation of the autonomous vehicle based on the trajectory parameter or second trajectory parameter,” here the system is reprocessing the data indicating the fault to determine if the fault is still present, if the fault remains the system will treat the fault in a critical manner and stop) (Paragraph [0104], “the fault manager 520 may cause the autonomous vehicle to adjust operation (e.g., by causing the vehicle to slow down,” here the system is analyzing the output of the processor to determine the fault and based on the result of the determination the system implements performance limits such as slowing down the vehicle)
providing the time interval and the least one performance limit to the trajectory generation system (Paragraph [0093], “In some such cases, the AV may continue operating or driving at its current trajectory for a particular amount of time, which may correspond to a particular number of frames of sensor data. For example, the AV may continue to operate for an amount of time corresponding to up to 5, 10, 15, frames of data or any amount in between, lesser, or greater than the preceding examples. If it is determined that the fault continues or is likely to continue for longer than the permitted operating time, the AV may take execute additional fault procedures, such as causing the AV to attempt to safely pull over to the side of the road. It should be understood that the amount of time the AV is permitted to continue travelling along a trajectory or operate may depend on context, such as speed of operation, location, type of fault, and the like.”) (Paragraph [0094], “In one or more embodiments or examples, applying the initial fault scheme includes storing output data of the at least one processor performing the processing and reprocessing. Accordingly, the autonomous vehicle will not operate along the trajectory parameter until the suspension is lifted. This can advantageously prevent the autonomous vehicle from operating along a trajectory that was made in error due to the fault … In some cases, the autonomous vehicle may continue to operate along the trajectory or using the trajectory parameter associated with the most recent non-fault based determination.,” here the system is using the time interval and the evaluation of the data to determine if the fault is permanent or transient in order to control the vehicle during the time interval)
generating at least a second trajectory update based on at least the time interval and the at least one performance limit using the trajectory generation system and updating the trajectory based on the at least second trajectory update using the trajectory generation system (Paragraph [0104], “In some embodiments, the actions or operations of the fault manager 520 or the processors 516 may depend on an amount of time to switch processors, to confirm a cause of the fault, or the safety of the trajectory, and the like. For example, if the autonomous vehicle can safely drive for a period of time (e.g., 100 ms, 500 ms, 2 second, etc) that is greater than an amount of time to determine a fault and route around the fault, then the autonomous vehicle may continue operating as if there were no fault while the fault manager 520 identifies the fault and takes measures to address the fault. IF on the other hand the amount of time to identify and respond to the fault is longer than a determined safe period of time, the fault manager 520 may cause the autonomous vehicle to adjust operation (e.g., by causing the vehicle to slow down and/or pull over),” here based on the amount of time to evaluate the fault and the result the system can update and execute an updated trajectory using the determined fault and time period).
Regarding claim 9, claim 9 is similar in scope to claim 2 and therefore is rejected under similar rationale.
Regarding claim 10, claim 10 is similar in scope to claim 3 and therefore is rejected under similar rationale.
Regarding claim 11, claim 11 is similar in scope to claim 4 and therefore is rejected under similar rationale.
Regarding claim 12, claim 12 is similar in scope to claim 5 and therefore is rejected under similar rationale.
Regarding claim 13, claim 13 is similar in scope to claim 6 and therefore is rejected under similar rationale.
Regarding claim 16, claim 16 is similar in scope to claims 2 and 3 and therefore is rejected under similar rationale.
Regarding claim 17, claim 17 is similar in scope to claims 4 and 5 and therefore is rejected under similar rationale.
Regarding claim 18, Yen teaches the method as discussed above in claim 15, Yen further teaches wherein the vehicle control system includes a timer arrangement and wherein when the category is the intermediate level, the timer arrangement determines a time interval during which the vehicle is to be stopped (Paragraph [0093], “In some such cases, the AV may continue operating or driving at its current trajectory for a particular amount of time, which may correspond to a particular number of frames of sensor data. For example, the AV may continue to operate for an amount of time corresponding to up to 5, 10, 15, frames of data or any amount in between, lesser, or greater than the preceding examples. If it is determined that the fault continues or is likely to continue for longer than the permitted operating time, the AV may take execute additional fault procedures, such as causing the AV to attempt to safely pull over to the side of the road. It should be understood that the amount of time the AV is permitted to continue travelling along a trajectory or operate may depend on context, such as speed of operation, location, type of fault, and the like,” here the system is determining a particular amount of time/time interval that the vehicle needs to stop if the fault is not resolved)
and the vehicle control system determines at least one performance limit associated with stopping the vehicle during the time limit (Paragraph [0113], “In one or more embodiments or examples, in response to determining that the fault parameter indicative of a fault is not present during the reprocessing, the method includes providing, based on the trajectory parameter or the secondary trajectory parameter, operating data to cause operation of the autonomous vehicle based on the trajectory parameter or second trajectory parameter,” here the system is reprocessing the data indicating the fault to determine if the fault is still present, if the fault remains the system will treat the fault in a critical manner and stop) (Paragraph [0104], “the fault manager 520 may cause the autonomous vehicle to adjust operation (e.g., by causing the vehicle to slow down,” here the system is analyzing the output of the processor to determine the fault and based on the result of the determination the system implements performance limits such as slowing down the vehicle).
Yen does not explicitly teach wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level.
Poeppel teaches one or more of the actions to take an autonomous vehicle out-of-service based at least in part on a fault including
wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level (Paragraph [0070], “The computing device(s) 110 can be configured to determine an operational state 142 of the vehicle 102 based, at least in part, on the level of severity of the fault 140. The operational state 142 can be indicative of whether the vehicle 102 is in condition to provide a vehicle service to the one or more user(s) 136. For example, the operational state 142 can indicate that the vehicle 102 is in condition to provide the vehicle service to one or more user(s) 136 of the vehicle 102 (e.g., for a minor fault, a stuck window). In some implementations, the operational state 142 can indicate that the vehicle 102 can provide a vehicle service to a current user 136 of the vehicle 102 (e.g., transport the rider to a destination location). In some implementations, the operational state 142 can indicate that the vehicle 102 can selectively provide vehicle services to a user of the vehicle 102. For example, the vehicle 102 can provide a transportation service to a user travelling in the direction of a maintenance location and/or can deny providing a transportation service to a user travelling away from the direction of a maintenance location. In some implementations, the operational state 142 can indicate that the vehicle 102 is not in condition to provide the vehicle service to the one or more user(s) 136 (e.g., for more severe faults),” here the system is outlining different severity levels for faults including indicating a first level where a vehicle can remain in service/non-critical, a level where a vehicle can selectively provide service/intermediate, and a level where a vehicle is not in condition to provide service/critical).
Yen and Poeppel are analogous art as they are both generally related to handling faults in vehicles.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include wherein the criticality level includes at least a critical level, an intermediate level, and a non-critical level of Poeppel in the method of handling faults of Yen with a reasonable expectation of success in order to determine a severity of a fault and improve the vehicles ability to appropriately handle the fault based on a plurality of severity levels to tailor vehicle operation (Paragraph [0069], “In another example, the computing device(s) 110 can determine that the level of severity 140 of a fault, such a fire in the vehicle's interior, is higher given the type of fault (e.g., smoke, fire), its associated location (e.g., the vehicle's interior), and/or other characteristics. In this way, the vehicle computing system 108 can improve its ability to take suitable measures to address the fault, given its level of severity.”).
Regarding claim 19, the combination of Yen and Poeppel teaches the system as discussed above in claim 18, Yen further teaches wherein the vehicle control system is configured to provide the time interval and the at least one performance limit to the trajectory generation system (Paragraph [0093], “In some such cases, the AV may continue operating or driving at its current trajectory for a particular amount of time, which may correspond to a particular number of frames of sensor data. For example, the AV may continue to operate for an amount of time corresponding to up to 5, 10, 15, frames of data or any amount in between, lesser, or greater than the preceding examples. If it is determined that the fault continues or is likely to continue for longer than the permitted operating time, the AV may take execute additional fault procedures, such as causing the AV to attempt to safely pull over to the side of the road. It should be understood that the amount of time the AV is permitted to continue travelling along a trajectory or operate may depend on context, such as speed of operation, location, type of fault, and the like.”) (Paragraph [0108], “In one or more embodiments or examples, the method 600 includes, in response to determining that the fault parameter is indicative of a fault being present, applying, at step 608, based on the fault parameter, an initial fault scheme. In some cases, the initial fault scheme may include rerouting communication to exclude a processor, slowing the vehicle, causing the vehicle to stop, causing the vehicle to move to the side of the road and stop, or any other type of fault scheme to reduce or eliminate negative consequences associated with a fault,” here the system is analyzing the output of the processor to determine the fault and based on the result of the determination the system implements performance limits such as slowing down the vehicle) (Paragraph [0094], “In one or more embodiments or examples, applying the initial fault scheme includes storing output data of the at least one processor performing the processing and reprocessing. Accordingly, the autonomous vehicle will not operate along the trajectory parameter until the suspension is lifted. This can advantageously prevent the autonomous vehicle from operating along a trajectory that was made in error due to the fault … In some cases, the autonomous vehicle may continue to operate along the trajectory or using the trajectory parameter associated with the most recent non-fault based determination.,” here the system is using the time interval and the evaluation of the data to determine if the fault is permanent or transient in order to control the vehicle during the time interval)
and the trajectory generation system is configured to generate at least a second trajectory update based on at least the time interval and the at least one performance limit (Paragraph [0104], “In some embodiments, the actions or operations of the fault manager 520 or the processors 516 may depend on an amount of time to switch processors, to confirm a cause of the fault, or the safety of the trajectory, and the like. For example, if the autonomous vehicle can safely drive for a period of time (e.g., 100 ms, 500 ms, 2 second, etc) that is greater than an amount of time to determine a fault and route around the fault, then the autonomous vehicle may continue operating as if there were no fault while the fault manager 520 identifies the fault and takes measures to address the fault. IF on the other hand the amount of time to identify and respond to the fault is longer than a determined safe period of time, the fault manager 520 may cause the autonomous vehicle to adjust operation (e.g., by causing the vehicle to slow down and/or pull over),” here based on the amount of time to evaluate the fault and the result the system can update and execute an updated trajectory using the determined fault and time period)
the vehicle further including an arbitration arrangement configured to arbitrate between the at least one trajectory update and the at least one second trajectory update to determine whether to use the at least one trajectory update or the at least one second trajectory update to update the trajectory (Paragraph [0104], “In some embodiments, the actions or operations of the fault manager 520 or the processors 516 may depend on an amount of time to switch processors, to confirm a cause of the fault, or the safety of the trajectory, and the like. For example, if the autonomous vehicle can safely drive for a period of time (e.g., 100 ms, 500 ms, 2 second, etc) that is greater than an amount of time to determine a fault and route around the fault, then the autonomous vehicle may continue operating as if there were no fault while the fault manager 520 identifies the fault and takes measures to address the fault. IF on the other hand the amount of time to identify and respond to the fault is longer than a determined safe period of time, the fault manager 520 may cause the autonomous vehicle to adjust operation (e.g., by causing the vehicle to slow down and/or pull over),” here based on the amount of time to evaluate the fault and the result the system can update and execute an updated trajectory using the determined fault and time period, this process of temporary operation for a period of time while the system addresses the fault is arbitration arrangement, the system will attempt the address the fault for a specified period of time and if the system fails it will implement the second trajectory update).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Huberman (US-11801860) teaches determining autonomous vehicle road navigation information including the determination of the presence of a fault. Rastoll (US-20200192351) teaches identifying impediments to the operation of the autonomous vehicle and implementing trajectory updates. Benmimoun (US-20220144294) teaches detecting, on the onboard vehicle communication network, a fault condition included in the set of fault conditions, the fault condition is then identified as one of transient or persistent. Lopez (US-20210179121) teaches coordinating and managing faults of systems of a vehicle, such as an autonomous vehicle, to enable the vehicle to respond safely and appropriately to the faults.
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 CHRISTOPHER FEES whose telephone number is (303)297-4343. The examiner can normally be reached Monday-Thursday 7:30 - 5:30 MT.
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, Aniss Chad can be reached at (571) 270-3832. 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.
/CHRISTOPHER GEORGE FEES/Primary Examiner, Art Unit 3662
Prosecution Insights