DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/29/2026 has been entered.
Status of Claims
This action is in response to the amendments filed on 05/29/2026, in which claims 1 and 5 are amended, claims 2-4 and 18 are cancelled, and claim 19 is new. Claims 1 and 5-17 and 19 are rejected.
Response to Arguments
Applicant's amendments and arguments, see REMARKS filed 05/29/2026, with respect to the rejections under 35 USC § 103, have been fully considered and are persuasive. Therefore, the previous rejections, under 35 USC § 103, are withdrawn.
With respect to independent claim 1, the Applicant argues:
B. Poledna does not disclose two verification platforms having the same architecture.
The Office Action maps Poledna's Verification Modules VM1-VM4 - residing within the Safe Trajectory Selection (STS) of Poledna's selected-trajectory-generating device - onto the claimed verification region, and maps two of those VMs (VM1 and VM2) onto the claimed main and fallback platforms. OA at pages 11-12. But Poledna does not describe its VMs as architecturally identical, and a proper §103 rejection, itself, cannot supply a feature on which the cited reference is silent.
Poledna's description of the VMs focuses on the tests each VM may implement and on the Quality Assessments each VM returns. Poledna ¶¶ 0023, 0063, and 0064. Poledna does not describe whether VM1, VM2, VM3, or VM4 share a common architecture, nor does Poledna describe any structural correspondence between any two VMs. Nor does Poledna describe a main/fallback relationship between any two VMs - the STS is a parallel collection of verification modules whose outputs feed a ranking scheme, not an arrangement in which one designated module operates as a primary actor and another as a fallback. The Office Action's relabeling of VM1 and VM2 as "main" and "fallback" is not a proper source of the missing disclosure.
Accordingly, Poledna does not disclose verification platforms that have the same architecture, as amended claim 1 requires.
While Poledna shows (Fig. 2) the modules as equivalent, i.e., have the same architecture, to further prosecution a new rejection is presented below in view of Mehdizade et al.
Therefore, the previous rejections, under 35 USC § 103, have been withdrawn and a new rejection is presented below.
C. Poledna does not disclose a main platform and a fallback platform that execute the same monitoring in parallel.
Poledna expressly describes verification modules that implement different tests: "each Verification Module implements a different test on the trajectories T1 -T3." Poledna 1 0064. The Office Action acknowledges this disclosure but reads the qualifier "preferably" appearing in Poledna ¶¶ 0040 and 0064 as also encompassing a non-preferred embodiment in which the VMs implement the same test. OA at pages 5-6. Respectfully, that reading attempts to extract more from "preferably" than Poledna discloses.
The bare word "preferably" does not by itself constitute an enabling disclosure of a same-test embodiment under §103. See MPEP § 2123 (a reference may be relied upon for both preferred and non-preferred embodiments, but the non-preferred embodiment must still be sufficiently disclosed to enable a person of ordinary skill in the art to practice it). Poledna nowhere describes how a same-test embodiment would operate, what Quality Assessments such an embodiment would produce, or how Poledna's ranking-from-Quality-Assessments mechanism would function when each VM produces essentially the same assessment.
To the contrary, Poledna's ranking architecture presupposes diverse tests. Poledna teaches that "[t]he Verification Modules VM1-VM4 are configured to implement tests on the trajectories T1-T3. Said tests on said trajectories T1-T3 return Quality Assessments Q11-Q43, wherein said Quality Assessments Q11-Q43 are indicating the quality of each of the trajectories T1-T3 in terms of said tests." Poledna ¶ 0063. Poledna further provides examples of the VM checks: "analysis whether the probability of collision with an obstacle is sufficiently low, an analysis whether the trajectory is drivable by the vehicle according to the vehicle dynamics, or an analysis whether the trajectory is in line with legal regulations." Poledna ¶ 0023. These checks are directed to fundamentally distinct subject matter - collision avoidance, drivability, and regulatory compliance-and Poledna's ranking scheme depends on aggregating the diverse Quality Assessments those distinct checks produce. A same-test embodiment, in which every VM produced essentially the same Quality Assessment, would empty Poledna's ranking-from-diverse-Quality-Assessments mechanism of any function it could perform.
A person of ordinary skill in the art reading Poledna in light of its disclosure would not understand the bare qualifier "preferably" to disclose, much less enable, an embodiment that is functionally incompatible with the remainder of Poledna's architecture. Accordingly, Poledna does not disclose verification platforms that execute the same monitoring in parallel.
As referenced above, ¶ [0063] of Poledna discloses “The Safe Trajectory Selection STS further implements one or more Verification Modules, in this example four Verification Modules VM1-VM4. The Verification Modules VM1-VM4 are configured to implement tests on the trajectories T1-T3. Said tests on said trajectories T1-T3 return Quality Assessments Q11-Q43, wherein said Quality Assessments Q11-Q43 are indicating the quality of each of the trajectories T1-T3 in terms of said tests.” Here, Poledna is setting up the structure of the system and explains that each Verification Module needs to perform a test on each the trajectories to determine a Quality Assessment of the trajectories themselves. This sets forth that the modules may use a test in general. Following this paragraph, Poledna provides a preferred embodiment wherein “each Verification Module implements a different test on one, two, or preferably all trajectories.”
By providing for a general quality test in ¶ [0063], then a preferred embodiment where each Verification Module implements a different test in ¶ [0064], Poledna is making a distinction between the general quality test for the Verification Modules of ¶ [0063] and the different quality test of ¶ [0064].
Therefore the Examiner respectfully disagrees with the above argument that “a person of ordinary skill in the art reading Poledna in light of its disclosure would not understand the bare qualifier "preferably" to disclose, much less enable, an embodiment that is functionally incompatible with the remainder of Poledna's architecture.”
With the above understanding and in reference to Fig. 2, which shows VM1-VM4 operating parallel, the Examiner also disagrees with the argument that “accordingly, Poledna does not disclose verification platforms that execute the same monitoring in parallel.”
D. Yousuf does not cure the deficiencies of Poledna.
The Office Action relies on Yousuf only for the limitation that "the calculation region is configured to calculate trajectories and to output driving commands." OA at pages 12- 13. Yousuf is not cited for, and does not disclose, verification platforms - much less verification platforms that have the same architecture or that execute the same monitoring in parallel. Yousuf accordingly cannot supply the features missing from Poledna.
Applicant’s arguments with respect to Yousef have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
B. The Ruiz passage cited by the Office Action does not disclose this feature.
The Office Action cites Ruiz at page 165 for the limitation of claim 6. OA at page 17. The cited Ruiz passage states: "Based on this, a backup core node will work in standby mode and only take over the critical functions of the primary core node after that core node fails. As a matter of fact, each core node must hold a set of hardware and software safety mechanisms to support ASIL D applications and to guarantee fail-silent behavior at component level." Ruiz at 165.
That passage describes a one-directional, reactive arrangement: a primary core node operates, and a backup core node, kept in standby mode, takes over only after the primary fails. Ruiz's "standby mode" expressly excludes the active bidirectional status exchange between security units that claim 6 requires. The further phrase "each core node must hold a set of hardware and software safety mechanisms" is a generic statement that does not disclose any specific status-exchange architecture.
Examiner cordially disagrees that the phrase “‘each core node must hold a set of hardware and software safety mechanisms’ is a generic statement that does not disclose any specific status-exchange architecture. The phrase is explicitly stating that each core node, i.e., the primary and backup core nodes, requires the safety mechanisms to guarantee fail-silent behavior. Looking further at Fig. 2, it shows that each core node is in communication with each other.
Therefore, the Examiner finds this argument unpersuasive.
C. Ruiz's Extended Heartbeat is exchanged between core nodes generally, not via discrete security units, and is not an equivalent of the §112(f) corresponding structure.
For completeness, Applicant acknowledges that Ruiz separately describes an "Extended Heartbeat" signal exchanged between core nodes generally, periodically transmitted in a time-triggered manner. Ruiz at 165-166. The Office Action did not cite the Extended Heartbeat in support of the claim 6 rejection. Ruiz's Extended Heartbeat is implemented by Ruiz's "communication module" within a Generic Adaptation Mechanism (GAM) at the core-node level-not by a discrete security unit within each verification platform.
Under the §112(f) construction the Office Action has applied to "security unit," claim 6's status-exchange limitation requires the exchange to be implemented by the security unit 19 corresponding structure described in the specification at ¶ 0044. Ruiz's core-node-level Extended Heartbeat does not perform that function in substantially the same way or with substantially the same structure and is, therefore, not an equivalent of the security unit 19 under §112(f).
For these additional reasons, claim 6 is patentable over the prior art of record.
Cited ¶ [0044] of the instant specification does not provide any structure beyond the security unit being some part of the platform. Reviewing Fig. 4 and ¶ [0043], provides that the security unit is some part of the input monitor 15a. However, there is no structure provided which requires the security unit to be a discrete unit. The structure in the specification only provides that the platform consists of a generic processor and may operate using any combination of hardware and/or software. (¶ [0038]-[0043]) Thus the communication module within the GAM is interpreted to cover the security unit of claim 6.
Therefore, the Examiner finds the above argument unpersuasive.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are:
“…calculation region…configured to calculate trajectories and output commands…” in claims 1, 9, 12, 14, and 15;
“…verification region…for monitoring…” in claims 1, and 15;
“…verification platforms comprising a driving command and input monitor for monitoring…” in claims 1, 5, and 7;
“…a driving command and input monitor for monitoring the calculated trajectories…” in claims 1, 7, and 8;
“…a security unit for recognizing errors…” in claims 5, 6, and 7
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
These limitations will be interpreted as:
…the calculation region comprises multiple, in particular three, independent computer platforms. (¶ [0015])
…The verification region 11 verifies the integrity of the input data received from the external control units and sensors of the vehicle and makes the checked input data available to the calculation region 10. The realization can be effected by a SoC (single chip) or a MCM (multi-chip module) having multiple chips or chiplets. As a general rule, an MCM comprises multiple individual (micro)chips (or "dies"), which are accommodated next to one another (i.e., in a planar manner) in a common housing. (¶ [0035])
…The verification region 11 comprises two verification platforms which are separate from one another, a main platform 13 and a fallback platform 14 which are preferably logically and/or functionally identical. Each verification platform comprises a driving command and input monitor 15a, 15b and a communication controller 16a, 16b (e.g., Ethernet, FlexRay, CAN or the like) as well as, likewise, a communication device (e.g., NoC, as depicted in FIG. 3) in order to connect the components to one another and to the calculation region 10. [0041] Each driving command and input monitor 15a, 15b comprises hardware and software for verifying the integrity of the input data received from sensors (e.g., checksums, time stamp, message ID or the like) and providing verified data for calculating the domain in a buffer memory, for comparing the roadway with the driving command and for adding safety-relevant ancillary information (e.g., checksums, time stamp, message number or the like) for data which can be transmitted to an external control unit or ECU. (¶ [0038])
If applicant does not intend to have these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Poledna et al. (US 2021/0001881 A1, “Poledna”) in view of Yousuf et al. (US 2018/0370540 A1, “Yousuf”) and in further view of Mehdizade et al (US 2019/0180526 A1, “Mehdizade”).
Regarding claim 1, Poledna discloses safe trajectory selection for autonomous vehicles and teaches:
A control device for a vehicle, the control device comprising; (The Selected-Trajectory generating-device (STG), i.e., a control device, is contained within a vehicle – See at least ¶ [0057] and Fig. 1)
a calculation region; and (The STG contains three Trajectory Generators (TG), i.e., calculation regions – See at least ¶ [0057] and Fig. 1)
a verification region, (The STG further contains a Safe Trajectory Selection (STS) which selects a trajectory based on a ranking scheme. The STS contains multiple Verification Modules (VM) – See at least ¶ [0057], [0063], and Fig. 2)
wherein the calculation region is configured to calculate trajectories [], (The TG generate trajectories T1-T3 – See at least ¶ [0057])
wherein the verification region comprises two verification platforms which are separate from one another, and (As shown in Fig. 2 VM1 and VM2 are separate from one another.)
wherein the verification platforms each comprise a monitor for monitoring the calculated trajectories and a communication device for connecting the verification platforms to one another and to the calculation region; (FIG. 2 depicts an example of an inner structure of a Safe Trajectory Selection STS. The Safe Trajectory Selection STS receives as an input trajectories, for examples the trajectories T1-T3 from the Trajectory Generators TG1-TG3 according to FIG.1, and preferably other inputs IN, as for example: Vehicle State information (velocity and/or acceleration and/or direction and/or tire friction and/or steering angle, etc.), and/or Map Data, and/or Trajectory Generator Diagnostics – See at least ¶ [0058-[0061])
Poledna does not explicitly teach wherein the calculation region is configured to calculate trajectories and to output driving commands. However, Yousuf discloses a method for using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system and teaches:
wherein the calculation region is configured to calculate trajectories and to output driving commands, (processor 206 typically performs vehicle dynamics/vehicle path calculation 144 including projected vehicle path calculation 158, actual vehicle path calculation 160, and plausibility check 162 – See at least ¶ [0111]; FIGS . 8 and 9A - 9D show that processor 206 performs algorithms that execute under normal operating conditions and are dominant/active and may potentially run on the LS core 324, namely: Vehicle dynamics and controls, Controls, Rationality checks, Decision-making, and send actuation commands – See at least ¶ [0140]-[0146])
In summary, Poledna discloses a system that creates trajectories for self-driving cars. Poledna further teaches that the vehicle state data, i.e., information relating to the control commands of the vehicles, is used with the calculation of the trajectories and is also used as input for the verification modules. Poledna does not explicitly teach that the calculation region is configured to calculate trajectories and to output driving commands. However, Yousuf discloses a method for using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system and teaches that the trajectory calculating processor, e.g., processor 206, can also perform the function of determining vehicle controls and then sends those controls to their proper actuators and systems.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna to provide for the method for using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system, as taught in Yousuf, to provide added redundancy and fault tolerance without adding more controllers or other controller hardware to the vehicle. (At Yousuf ¶ [0005])
The combination of Poledna and Yousuf does not explicitly teach wherein the verification platforms comprise a main platform and a fallback platform and wherein the verification platforms are logically and functionally identical and have the same architecture; and wherein the main platform and the fallback platform execute the same monitoring in parallel on the calculated trajectories. However, Mehdizade discloses systems, methods, and apparatuses for diagnostic fault detections by parameter data using a redundant processor architecture and teaches:
wherein the verification platforms comprise a main platform and a fallback platform (For example, as shown in more detail with regard to FIG. 4 , and with continued reference to FIGS. 1 to 3, the computer diagnostic system 200 includes a primary compute platform 210 and a backup compute platform 220, each compute platform receives input parameter data from one or more of the sensor devices 225 – See at least ¶ [0060]) and wherein the verification platforms are logically and functionally identical and have the same architecture; (As shown in Fig. 4 the primary and backup compute platforms perform the same functions and have the same architecture – See at least ¶ [0060]-[0065])
and wherein the main platform and the fallback platform execute the same monitoring in parallel on the calculated trajectories. (Referring back to FIG. 4, in an exemplary embodiment, the parameter data is processed, via a dual path arrangement of the parameter flow, by a primary hardware accelerator 212 and by a backup hardware accelerator 222. The processing by the primary hardware accelerator 212 and the backup hardware accelerator 222 in a normal operation would occur within a relatively same or similar time frame or cycle time. That is, the primary hardware accelerator 212 and the backup hardware accelerator 222 would receive the data with the parameter data within a processor cycle, or prescribed window or range. Further, the timing cycles may be changed or modified by design; that is a normal operation may be considered in a single period or within multiple periods. Latency times may be designed, changed and updated depending on operational needs and processing capabilities in the pipeline. Likewise, as the dual path parameter data flow continues at the output 216 and input 217 on path 1 (or trajectory calculated by internal solutions in the CPU) to the primary processor 214 the parameter data flow may be within sync, nearly within sync, or within a time period range of the redundant path in path 2 of parameter flow at the output 226 and the input 227 to the backup processor 224. The parameter flow continues, in a dual bypass path of the primary processor 214 via a first environment in path 1 shown by 218, and of the backup processor 224 via a second environment in a redundant bypass path in a path 2 shown by 228 – See at least ¶ [0061])
In summary, Poledna discloses similar modules that may perform the same or different functions as one another in order to determine a potential fault pertaining to trajectories. The combination of Poledna and Yousuf does not explicitly teach wherein the verification platforms comprise a main platform and a fallback platform and wherein the verification platforms are logically and functionally identical and have the same architecture; and wherein the main platform and the fallback platform execute the same monitoring in parallel on the calculated trajectories. However, Mehdizade discloses systems, methods, and apparatuses for diagnostic fault detections by parameter data using a redundant processor architecture and teaches a primary compute system and a backup compute system wherein the systems contain the same logic, function, and architecture, and process trajectory monitoring data in parallel.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna and Yousuf to provide for the systems, methods, and apparatuses for diagnostic fault detection by parameter data using redundant processor architecture, as taught in Mehdizade, to provide systems, methods, and apparatuses with improved tolerances such that false results are minimized for detecting and isolating faults that occur specifically in processors of vehicle systems. (At Mehdizade ¶ [0003])
Regarding claim 19, the combination of Poledna and Yousuf does not explicitly teach, but Mehdizade further teaches:
wherein the monitor of the main platform and the monitor of the fallback platform perform the same monitoring tests in parallel on the calculated trajectories. (Referring back to FIG. 4, in an exemplary embodiment, the parameter data is processed, via a dual path arrangement of the parameter flow, by a primary hardware accelerator 212 and by a backup hardware accelerator 222. The processing by the primary hardware accelerator 212 and the backup hardware accelerator 222 in a normal operation would occur within a relatively same or similar time frame or cycle time. That is, the primary hardware accelerator 212 and the backup hardware accelerator 222 would receive the data with the parameter data within a processor cycle, or prescribed window or range. Further, the timing cycles may be changed or modified by design; that is a normal operation may be considered in a single period or within multiple periods. Latency times may be designed, changed and updated depending on operational needs and processing capabilities in the pipeline. Likewise, as the dual path parameter data flow continues at the output 216 and input 217 on path 1 (or trajectory calculated by internal solutions in the CPU) to the primary processor 214 the parameter data flow may be within sync, nearly within sync, or within a time period range of the redundant path in path 2 of parameter flow at the output 226 and the input 227 to the backup processor 224. The parameter flow continues, in a dual bypass path of the primary processor 214 via a first environment in path 1 shown by 218, and of the backup processor 224 via a second environment in a redundant bypass path in a path 2 shown by 228 – See at least ¶ [0061])
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna and Yousuf to provide for the systems, methods, and apparatuses for diagnostic fault detection by parameter data using redundant processor architecture, as taught in Mehdizade, to provide systems, methods, and apparatuses with improved tolerances such that false results are minimized for detecting and isolating faults that occur specifically in processors of vehicle systems. (At Mehdizade ¶ [0003])
Claim(s) 5-17 are rejected under 35 U.S.C. 103 as being unpatentable over Poledna in view of Yousuf and Mehdizade, as applied to claim 1, and in further view of Ruiz et al. (A safe generic adaptation mechanism for smart cars, “Ruiz”).
Regarding claim 5, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach wherein the verification platform has at least one security unit for recognizing errors, and wherein a verification platform is brought into a fail-silent state by the security unit as soon as the security unit recognizes an error in this verification platform. However, Ruiz discloses a safe generic adaptation mechanism for smart cars and teaches:
wherein each of the verification platform has at least one security unit for recognizing errors, and (Based on these properties, a globally consistent state is provided, which is enforced through an adaptation mechanism on every device. More specifically, the software architecture of this adaptation mechanism is composed from multiple software artefacts, each providing a distinct functionality. At the architecture’s core, an adaptation logic module is responsible for reacting to local hardware faults and changes within the system’s global state – See at least pg. 163)
wherein a verification platform is brought into a fail-silent state by the security unit as soon as the security unit recognizes an error in this verification platform. (In case of unsalvageable local faults, the adaptation logic is further capable of discontinuing operations through a fail-silent mechanism, thus preventing incorrect system behavior from occurring – See at least pg. 163)
In summary, Yousuf discloses the use of a fault-silent state when determining a fault within a processor. Yousuf does not explicitly teach a security unit for recognizing the error. However, Ruiz discloses an adaptation logic module of a processor that is specifically used to identify an error and react with a fail-silent mechanism when the faults are unsalvageable.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 6, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach, but Ruiz further teaches:
wherein the security unit of the main platform sends information about its internal status to the fallback platform and vice versa. (Based on this, a backup core node will work in standby mode and only take over the critical functions of the primary core node after that core node fails. As a matter of fact, each core node must hold a set of hardware and software safety mechanisms to support ASIL D applications and to guarantee fail-silent behavior at component level – See at least pg. 165)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 7, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach, but Ruiz further teaches:
wherein the monitor comprises a security unit which receives error messages from the verification platform and places the corresponding verification platform in a fail- silent state when an error has been notified to the security unit. (In case of unsalvageable local faults, the adaptation logic is further capable of discontinuing operations through a fail-silent mechanism, thus preventing incorrect system behavior from occurring – See at least pg. 163)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 8, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach, but Ruiz further teaches:
wherein the monitor has a central computing unit which is implemented in the hardware lockstep. (As such, the system must consist of at least two processing units that are connected through two physically independent channels and powered by two independent power sources, thus excluding communication link and power failures from a fault cause analysis. Moreover, each computing platform must meet minimal diagnostic capabilities in form of lockstepped processing units to detect deviations in the calculations and thereby infer a local hardware fault – See at least Pg. 163)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 9, Poledna further teaches:
wherein the calculation region comprises multiple, in particular three, independent computer platforms. (The system contains TG1-TG3 and it may be provided that all Trajectory Generators are diverse , in particular in that each of the Trajectory Generators uses different algorithms for generating trajectories then the other Trajectory Generators and/or each Trajectory Generator is implemented on different hardware – See at least ¶ [0021], Claim 18, and Fig. 1)
Regarding claim 10, the combination of Poledna, Mehdizade, and Ruiz does not explicitly teach, but Yousuf further teaches:
wherein the computer platform has a processing unit for data processing, (An example non-limiting embodiment solving this problem has three or more processors, or in some cases exactly three processors, as part of the architecture of the main controller. Additional processors may be distributed throughout the vehicle to perform additional, specialized functions – See at least ¶ [0025]) a memory, for storing programs and/or data of the processing unit, (FIG . 7B shows a more detailed hardware configuration diagram of the FIG. 7A architecture. This diagram reveals that each of GPUs 208, 210 is supported by DDR and flash memory 209A, 209B (211A, 211B). Similarly, each of the processors 202, 204 are supported by associated flash memory 203A, 203B (205A, 205B) and DDR memory 203, 205. Each of processors 202, 204, 206 executes program instructions including operating systems such as Linux from computer instructions stored in non-transitory memory such as flash memory 203, 205 and/or DDR memory – See at least ¶ [0121]) as well as a communication device, for communicating units of the calculation region and/or units of the verification region. (The processors 202, 204, 206 may communicate with one another via SPI buses 356 – See at least ¶ [0122])
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Mehdizade, and Ruiz to provide for the method for using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system, as taught in Yousuf, to provide added redundancy and fault tolerance without adding more controllers or other controller hardware to the vehicle. (At Yousuf ¶ [0005])
Regarding claim 11, Poledna further teaches:
wherein each computer platform runs the calculation of the trajectories [] independently of other computer platforms. (TG1-TG3 generate the trajectories independently – See at least ¶ [0053] and Fig. 2)
The combination of Poledna, Mehdizade, and Ruiz does not explicitly teach, but Yousuf further teaches:
wherein each computer platform runs the calculation of the trajectories and the respective driving command [] (processor 206 typically performs vehicle dynamics/vehicle path calculation 144 including projected vehicle path calculation 158, actual vehicle path calculation 160, and plausibility check 162 – See at least ¶ [0111]; FIGS . 8 and 9A - 9D show that processor 206 performs algorithms that execute under normal operating conditions and are dominant/active and may potentially run on the LS core 324, namely: Vehicle dynamics and controls, Controls, Rationality checks, Decision-making, and send actuation commands – See at least ¶ [0140]-[0146])
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Mehdizade, and Ruiz to provide for the method for using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system, as taught in Yousuf, to provide added redundancy and fault tolerance without adding more controllers or other controller hardware to the vehicle. (At Yousuf ¶ [0005])
Regarding claim 12, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach, but Ruiz further teaches:
wherein each computer platform of the calculation region is supplied via a separate supply voltage. (As such, the system must consist of at least two processing units that are connected through two physically independent channels and powered by two independent power sources, thus excluding communication link and power failures from a fault cause analysis. Moreover, each computing platform must meet minimal diagnostic capabilities in form of lockstepped processing units to detect deviations in the calculations and thereby infer a local hardware fault – See at least Pg. 163)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 13, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach, but Ruiz further teaches:
wherein the supply voltages are provided by at least two independent supply networks. (Because the processing units are each powered by independent power sources, then they would require their own circuitry, i.e., supply networks, to distribute the power – See at least pg. 163)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 14, Regarding claim 13, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach, but Ruiz further teaches:
wherein each computer platform of the calculation region has a separate clock generation system. (In detail, reconfiguration relies heavily on the cyclic exchange of heartbeats between processing units. As such, the system must consist of at least two processing units that are connected through two physically independent channels and powered by two independent power sources, thus excluding communication link and power failures from a fault cause analysis – See at least pg. 163)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 15, the combination of Poledna, Yousuf, and Mehdizade does not explicitly teach, but Ruiz further teaches:
wherein the communication between and within the calculation region and the verification region is protected by means of EC codes and/or end-to-end ECC/EDC codes. (The Data Validation (Integrity Check) is responsible to provide checks on the input data and the system itself during the execution of the derived algorithm. A cyclic redundancy check (CRC) is included for that purpose. Range checks or correctness checks are carried on basis of functioning parity or CRC checks. Likewise, a rolling counter is added to guarantee that the current message has been updated since the last computation cycle. This is used to detect stale and omitted transitions – See at least pg. 166; Examiner notes that CRC is an ECC)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Yousuf, and Mehdizade to provide for the safe generic adaptation mechanism for smart cars, as taught in Ruiz, to allow individual non-critical applications to be passivated in order to free enough resources for scheduling critical tasks after failure situation, as part of a graceful degradation strategy. (At Ruiz pg. 164)
Regarding claim 16, the combination of Poledna, Mehdizade, and Ruiz does not explicitly teach, but Yousuf further teaches:
wherein the communication device is configured as a network-on-chip (NoC). (Each of processors 202, 204, 206 includes internal multiple independent bus interfaces 354 ( preferably there are at least two independent CAN bus interfaces 354 to provide independent interfaces to different CAN buses to provide fault tolerance in case a bus fails) – See at least ¶ [0123]; Examiner notes that the presence of individual internal bus interfaces within the processors is a network-on-chip.)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to have modified the safe trajectory selection for autonomous vehicles of Poledna, Mehdizade, and Ruiz to provide for the method for using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system, as taught in Yousuf, to provide added redundancy and fault tolerance without adding more controllers or other controller hardware to the vehicle. (At Yousuf ¶ [0005])
Regarding claim 17, Poledna further teaches:
wherein the verification of the calculated trajectory and of the respective driving command is carried out by a comparison test. (TG1-TG3 each generate a trajectory; these trajectories are passed to VM1-VM4. VM1-VM4 each determine a ranking for the trajectories and the trajectory with the highest ranking is selected. This provides an method that is comparing the trajectories, via a rank, to one another prior to selection – See at least ¶ [0089])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHASE L COOLEY whose telephone number is (303)297-4355. The examiner can normally be reached Monday-Thursday 7-5MT.
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.
/CHASE L COOLEY/Examiner, Art Unit 3662
Prosecution Insights