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 .
Claims 1-20 have been examined.
P = paragraph e.g. P[0001] = paragraph[0001]
Examiner’s Note:
The rejections under 35 U.S.C. 112(a) and 112(b) have been withdrawn, as it has been determined that the claims and specification recite sufficient structure to perform the claimed functions.
Response to Arguments
Applicant's arguments filed 12/30/2025 regarding the rejections under 35 U.S.C. 102 and 103 have been fully considered but they are not persuasive.
Regarding the rejections under 35 U.S.C. 102 and 103, the Applicant argues
“Claim 1 has been amended to recite run time application use case context information for an ADAS and/or autonomous driving SoC. As discussed during the interview, Patki does not teach or suggest at least this feature. Claim 1 provides the advantage of limiting diagnostic testing to avoid impacting system functional behavior and performance. In contrast, Patki is directed to investigating root causes of potential system issues. See paragraph 3. The other applied references do not supply the deficiencies of Patki. Accordingly, withdrawal of the rejections is respectfully requested. The other rejected independent claims recite elements similar to those discussed above with respect to claim 1 and are believed to be allowable for reasons similar to those presented for claim 1. Finally, the rejected dependent claims are allowable at least by virtue of their dependence on an allowable base claim, in addition to reasons related to their own recitations”.
However, referring to amended Claim 1, the amended limitation “run time”, of the limitation “receiving run time application use case context information for context-aware safety management for an advanced driver-assistance system (ADAS) and/or an autonomous driving system-on-a-chip (SoC)”, encompasses a “run time” event of simply an execution of a process to perform the claimed “receiving”. In addition, regarding the advantage mentioned by the Applicant of “limiting diagnostic testing to avoid impacting system functional behavior and performance”, no steps are claimed regarding “limiting” are claimed. In view of this interpretation of the scope of “run time”, Patki et al. teaches performing steps of receiving event information when trace operations are being performed (“…the event information may include one or more events generated by the functional logic 150 when the trace operation(s) is/are being performed”, see P[0075] and “…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] of Patki et al.), which is encompassed by the claimed “run time”, as communicating and receiving the event information is performed at “run time” or upon execution of the trace operations and of the diagnostic interconnect communication process. Therefore, it is determined that Claim 1 and all independent claims encompass the teachings of Patki et al., and the arguments are not persuasive.
All other arguments including “Finally, the rejected dependent claims are allowable at least by virtue of their dependence on an allowable base claim, in addition to reasons related to their own recitations” are not persuasive for the reasons given above.
All claims are rejected. See the new grounds of rejection.
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 (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 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.
Claims 1-4, 6, 9-14, 17 and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Patki et al. (2023/0273873).
Regarding Claim 1, Patki et al. teaches the claimed method, comprising: receiving run time application use case context information (“…the event information may include one or more events generated by the functional logic 150 when the trace operation(s) is/are being performed”, see P[0075] and “…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077]) for context-aware safety management for an advanced driver-assistance system (ADAS) and/or an autonomous driving system-on-a-chip (SoC) (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “Controller(s) 836, which may include one or more CPU(s), system on chips (SoCs) 804 (FIG. 8C) and/or GPU(s), may provide signals (e.g., representative of commands) to one or more components and/or systems of the vehicle 800…The controller(s) 836 may include one or more onboard (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals, and output operation commands (e.g., signals representing commands) to enable autonomous driving and/or to assist a human driver in driving the vehicle 800. The controller(s) 836 may include a first controller 836 for autonomous driving functions”, see P[0119]);
selecting a group of components of the ADAS and/or autonomous driving SoC for running the application use case context information (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042] and “The processing block 120 is a circuit that may be implemented as a System on a Chip (“SoC”). The processing block 120 includes functional logic 150, which is a portion of the processing block 120 upon which the computing device (via the adapter 110) may perform diagnostic operations”, see P[0022] and “The SoC(s) 804 may include one or more processor(s) 810 (e.g., embedded processors). The processor(s) 810 may include a boot and power management processor that may be a dedicated processor and subsystem to handle boot power and management functions and related security enforcement”, see P[0163]);
identifying [[the]] a selected subset of diagnostic procedures based on the group of components of the ADAS and/or autonomous driving SoC associated with the use case context information, the selected subset of diagnostic procedures being a subset of stored diagnostic procedures (“The scan island 520 isolates the functional logic 150 to be analyzed from the diagnostic logic (of the functional diagnostic cluster 528) that will perform the scan operation(s)”, see P[0081] and “…the diagnostic mode signal may be transmitted to the mode signal conductor 510 (e.g., a pin) or otherwise conducted to other components of the processing block 120 (e.g., an SoC)”, see P[0103]);
triggering the selected subset of diagnostic procedures (“The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042] and “…when the mode signal is the diagnostic mode signal, the access port 216 communicates with the computing device 140 (see FIGS. 1 and 4) via the target DP and DN contacts 240 and 242 and the adapter 110 (see FIGS. 1, 3A, 3B, and 4)”, see P[0072] and “The scan island 520, the trace engine 220, and the event interconnect 526 may be characterized as being components a functional diagnostic cluster 528 within the processing block 120 (e.g., SoC) that includes and/or implements diagnostic logic)”, see P[0073]); and
performing the selected subset of diagnostic procedures based on the triggering (“In block 714, the access port 216 receives one or more instructions from the computing device 140. The instruction(s) instruct the target system 112 to perform at least one diagnostic operation, such as a trace operation or a scan operation”, see P[0104] and “…the computer device 140 (see FIGS. 1 and 4) may instruct the target system 112 (see FIGS. 1, 2, and 4) to perform scan operations via the access port 216”, see P[0081]).
Regarding Claim 2, Patki et al. teaches the claimed method of claim 1, in which the triggering the selected subset of diagnostic procedures is via a dedicated diagnostics trigger pin (“The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]).
Regarding Claim 3, Patki et al. teaches the claimed method of claim 1, in which the application use case context information is received from the ADAS and/or autonomous driving SoC and the triggering the selected subset of diagnostic procedures is via a global safety monitor (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]).
Regarding Claim 4, Patki et al. teaches the claimed method of claim 3, in which the SoC comprises a group of functional blocks (“…portions of the functional logic 150…”, see P[0094]) and a local safety monitor, the local safety monitor performing the selected subset of diagnostic procedures based on the triggering (“…trace engine 220…”, see P[0042]).
Regarding Claim 6, Patki et al. teaches the claimed method of claim 1, further comprising triggering periodic baseline tests in addition to the selected subset of diagnostic procedures (“The boot power and management processor may provide clock and voltage programming, assistance in system low power state transitions, management of SoC(s) 804 thermals and temperature sensors, and/or management of the SoC(s) 804 power states. Each temperature sensor may be implemented as a ring-oscillator whose output frequency is proportional to temperature, and the SoC(s) 804 may use the ring-oscillators to detect temperatures of the CPU(s) 806, GPU(s) 808, and/or accelerator(s) 814. If temperatures are determined to exceed a threshold, the boot and power management processor may enter a temperature fault routine and put the SoC(s) 804 into a lower power state and/or put the vehicle 800 into a chauffeur to safe-stop mode (e.g., bring the vehicle 800 to a safe stop)”, see P[0163]).
Regarding Claim 9, Patki et al. teaches the claimed apparatus, comprising:
an advanced driver-assistance system (ADAS) and/or an autonomous driving system-on- a-chip (SoC) configured to perform a selected subset of diagnostic procedures based on a triggering (“Controller(s) 836, which may include one or more CPU(s), system on chips (SoCs) 804 (FIG. 8C) and/or GPU(s), may provide signals (e.g., representative of commands) to one or more components and/or systems of the vehicle 800…The controller(s) 836 may include one or more onboard (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals, and output operation commands (e.g., signals representing commands) to enable autonomous driving and/or to assist a human driver in driving the vehicle 800. The controller(s) 836 may include a first controller 836 for autonomous driving functions”, see P[0119] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]); and
a controller (“The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042] and “Controller(s) 836, which may include one or more CPU(s), system on chips (SoCs) 804 (FIG. 8C) and/or GPU(s), may provide signals (e.g., representative of commands) to one or more components and/or systems of the vehicle 800…The controller(s) 836 may include one or more onboard (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals, and output operation commands (e.g., signals representing commands) to enable autonomous driving and/or to assist a human driver in driving the vehicle 800. The controller(s) 836 may include a first controller 836 for autonomous driving functions”, see P[0119]) configured:
to select a group of components of the ADAS and/or autonomous driving SoC for running run time (“…the event information may include one or more events generated by the functional logic 150 when the trace operation(s) is/are being performed”, see P[0075] and “…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077]) application use case context information (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042] and “The processing block 120 is a circuit that may be implemented as a System on a Chip (“SoC”). The processing block 120 includes functional logic 150, which is a portion of the processing block 120 upon which the computing device (via the adapter 110) may perform diagnostic operations”, see P[0022] and “The SoC(s) 804 may include one or more processor(s) 810 (e.g., embedded processors). The processor(s) 810 may include a boot and power management processor that may be a dedicated processor and subsystem to handle boot power and management functions and related security enforcement”, see P[0163]);
to identify [[the]] a selected subset of diagnostic procedures based on the group of components of the ADAS and/or autonomous driving SoC associated with the use case context information (“The scan island 520 isolates the functional logic 150 to be analyzed from the diagnostic logic (of the functional diagnostic cluster 528) that will perform the scan operation(s)”, see P[0081] and “…the diagnostic mode signal may be transmitted to the mode signal conductor 510 (e.g., a pin) or otherwise conducted to other components of the processing block 120 (e.g., an SoC)”, see P[0103]); and
to trigger the selected subset of diagnostic procedures (“The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042] and “…when the mode signal is the diagnostic mode signal, the access port 216 communicates with the computing device 140 (see FIGS. 1 and 4) via the target DP and DN contacts 240 and 242 and the adapter 110 (see FIGS. 1, 3A, 3B, and 4)”, see P[0072] and “The scan island 520, the trace engine 220, and the event interconnect 526 may be characterized as being components a functional diagnostic cluster 528 within the processing block 120 (e.g., SoC) that includes and/or implements diagnostic logic)”, see P[0073]).
Regarding Claim 10, Patki et al. teaches the claimed apparatus of claim 9, in which the controller is external to the ADAS and/or autonomous driving SoC (see FIG. 1).
Regarding Claim 11, Patki et al. teaches the claimed apparatus of claim 10, in which the controller further comprises a global safety monitor that triggers the selected subset of diagnostic procedures (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]).
Regarding Claim 12, Patki et al. teaches the claimed apparatus of claim 9, in which the controller is internal to the ADAS and/or autonomous driving SoC (“Controller(s) 836, which may include one or more CPU(s), system on chips (SoCs) 804 (FIG. 8C) and/or GPU(s), may provide signals (e.g., representative of commands) to one or more components and/or systems of the vehicle 800…The controller(s) 836 may include one or more onboard (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals, and output operation commands (e.g., signals representing commands) to enable autonomous driving and/or to assist a human driver in driving the vehicle 800. The controller(s) 836 may include a first controller 836 for autonomous driving functions”, see P[0119]).
Regarding Claim 13, Patki et al. teaches the claimed apparatus of claim 9, in which the controller further comprises a dedicated diagnostics trigger pin that is coupled to the ADAS and/or autonomous driving SoC (“The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]).
Regarding Claim 14, Patki et al. teaches the claimed apparatus of claim 9, in which the ADAS and/or autonomous driving SoC further comprises a group of functional blocks (“…portions of the functional logic 150…”, see P[0094]) and a local safety monitor, the local safety monitor Currently Amended the selected subset of diagnostic procedures based on the triggering (“…trace engine 220…”, see P[0042]).
Regarding Claim 17, Patki et al. teaches the claimed apparatus, comprising:
means for receiving run time application use case context information (“…the event information may include one or more events generated by the functional logic 150 when the trace operation(s) is/are being performed”, see P[0075] and “…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077]) for context-aware safety management for an advanced driver-assistance system (ADAS) and/or an autonomous driving system-on-a-chip (SoC) (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “Controller(s) 836, which may include one or more CPU(s), system on chips (SoCs) 804 (FIG. 8C) and/or GPU(s), may provide signals (e.g., representative of commands) to one or more components and/or systems of the vehicle 800…The controller(s) 836 may include one or more onboard (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals, and output operation commands (e.g., signals representing commands) to enable autonomous driving and/or to assist a human driver in driving the vehicle 800. The controller(s) 836 may include a first controller 836 for autonomous driving functions”, see P[0119]);
means for selecting a group of components of the ADAS and/or autonomous driving SoC for running the application use case context information (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042] and “The processing block 120 is a circuit that may be implemented as a System on a Chip (“SoC”). The processing block 120 includes functional logic 150, which is a portion of the processing block 120 upon which the computing device (via the adapter 110) may perform diagnostic operations”, see P[0022] and “The SoC(s) 804 may include one or more processor(s) 810 (e.g., embedded processors). The processor(s) 810 may include a boot and power management processor that may be a dedicated processor and subsystem to handle boot power and management functions and related security enforcement”, see P[0163]);
means for identifying [[the]] a selected subset of diagnostic procedures based on the group of components of the ADAS and/or autonomous driving SoC associated with the use case context information, the selected subset of diagnostic procedures being a subset of stored diagnostic procedures (“The scan island 520 isolates the functional logic 150 to be analyzed from the diagnostic logic (of the functional diagnostic cluster 528) that will perform the scan operation(s)”, see P[0081] and “…the diagnostic mode signal may be transmitted to the mode signal conductor 510 (e.g., a pin) or otherwise conducted to other components of the processing block 120 (e.g., an SoC)”, see P[0103]);
means for triggering the selected subset of diagnostic procedures (“The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042] and “…when the mode signal is the diagnostic mode signal, the access port 216 communicates with the computing device 140 (see FIGS. 1 and 4) via the target DP and DN contacts 240 and 242 and the adapter 110 (see FIGS. 1, 3A, 3B, and 4)”, see P[0072] and “The scan island 520, the trace engine 220, and the event interconnect 526 may be characterized as being components a functional diagnostic cluster 528 within the processing block 120 (e.g., SoC) that includes and/or implements diagnostic logic)”, see P[0073]); and
means for performing the selected subset of diagnostic procedures based on the triggering (“In block 714, the access port 216 receives one or more instructions from the computing device 140. The instruction(s) instruct the target system 112 to perform at least one diagnostic operation, such as a trace operation or a scan operation”, see P[0104] and “…the computer device 140 (see FIGS. 1 and 4) may instruct the target system 112 (see FIGS. 1, 2, and 4) to perform scan operations via the access port 216”, see P[0081]).
Regarding Claim 19, Patki et al. teaches the claimed apparatus of claim 17, in which:
the application use case context information is received from the ADAS and/or autonomous driving SoC (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]);
the means for triggering the selected subset of diagnostic procedures is a global safety monitor (“…when one or more particular events occur in the target system 112, the diagnostic interconnect 514 may communicate the particular event(s) to the access port 216, which informs the computing device 140 of the occurrence of the particular event(s)”, see P[0077] and “The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]); and
the ADAS and/or autonomous driving SoC comprises a group of functional blocks (“…portions of the functional logic 150…”, see P[0094]) and a local safety monitor, the local safety monitor being the means for performing the selected subset of diagnostic procedures based on the triggering (“…trace engine 220…”, see P[0042]).
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.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Patki et al. (2023/0273873) in view of Hukerikar et al. (2024/0402250).
Regarding Claim 5, Patki et al. does not expressly recite the claimed method of claim 1, in which the triggering the selected subset of diagnostic procedures occurs once every fault tolerant time interval (FTTI).
However, Hukerikar et al. (2024/0402250) teaches scheduling tests “at a frequency that satisfies a fault-tolerant time interval (“FTTI”)” (Hukerikar et al.; see P[0002] and P[0017]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patki et al. with the teachings of Hukerikar et al., and the method of claim 1, in which the triggering the selected subset of diagnostic procedures occurs once every fault tolerant time interval (FTTI), as rendered obvious by Hukerikar et al., in order to “detect and/or identify one or more permanent hardware faults within one or more hardware components” (Hukerikar et al.; see P[0017]).
Claims 7, 8, 15, 16, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Patki et al. (2023/0273873) in view of Sakarda (8,161,482).
Regarding Claim 7, Patki et al. does not expressly recite the claimed method of claim 1, in which the application use case context information is received from a system scheduler, the system scheduler configured to collect application use case context information.
However, Sakarda (8,161,482) teaches a scheduler that maps context to each core of a system, where the system may be a System on a Chip (SoC) (Sakarda; see col.6, particularly lines 57-67 and col.7, particularly lines 1-4, see col.10, particularly lines 4-21).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patki et al. with the teachings of Sakarda, and the method of claim 1, in which the application use case context information is received from a system scheduler, the system scheduler configured to collect application use case context information, as rendered obvious by Sakarda, in order to “execute threads at a lower power consumption” (Sakarda; see col.7, particularly lines 54-63).
Regarding Claim 8, Patki et al. does not expressly recite the claimed method of claim 1, in which the application use case context information is received from a set of schedulers, each scheduler of the set of schedulers configured to collect application use case context information from respective subsystems in the ADAS and/or autonomous driving SoC.
However, Sakarda (8,161,482) teaches receiving a context from a scheduler (Sakarda; see Claim 15), and teaches a first scheduler for a first operating system core and a second scheduler for a second operating system core, where context information may be provided by each scheduler (Sakarda; see col.3, particularly lines 57-67 and col.4, particularly lines 1-18, also see col.5, particularly lines 32-67 and col.6, particularly lines 1-28 and 57-67 and col.7, particularly lines 1-4).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patki et al. with the teachings of Sakarda, and the method of claim 1, in which the application use case context information is received from a set of schedulers, each scheduler of the set of schedulers configured to collect application use case context information from respective subsystems in the ADAS and/or autonomous driving SoC, as rendered obvious by Sakarda, in order to “execute threads at a lower power consumption” (Sakarda; see col.7, particularly lines 54-63).
Regarding Claim 15, Patki et al. does not expressly recite the claimed apparatus of claim 9, in which the ADAS and/or autonomous driving SoC further comprises a system scheduler configured to collect application use case context information.
However, Sakarda (8,161,482) teaches a scheduler that maps context to each core of a system, where the system may be a System on a Chip (SoC) (Sakarda; see col.6, particularly lines 57-67 and col.7, particularly lines 1-4, see col.10, particularly lines 4-21).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patki et al. with the teachings of Sakarda, and the apparatus of claim 9, in which the ADAS and/or autonomous driving SoC further comprises a system scheduler configured to collect application use case context information, as rendered obvious by Sakarda, in order to “execute threads at a lower power consumption” (Sakarda; see col.7, particularly lines 54-63).
Regarding Claim 16, Patki et al. does not expressly recite the claimed apparatus of claim 9, in which the application use case context information is received from a set of schedulers, each scheduler of the set of schedulers configured to collect application use case context information from respective subsystems in the ADAS and/or autonomous driving SoC.
However, Sakarda (8,161,482) teaches receiving a context from a scheduler (Sakarda; see Claim 15), and teaches a first scheduler for a first operating system core and a second scheduler for a second operating system core, where context information may be provided by each scheduler (Sakarda; see col.3, particularly lines 57-67 and col.4, particularly lines 1-18, also see col.5, particularly lines 32-67 and col.6, particularly lines 1-28 and 57-67 and col.7, particularly lines 1-4).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patki et al. with the teachings of Sakarda, and the apparatus of claim 9, in which the application use case context information is received from a set of schedulers, each scheduler of the set of schedulers configured to collect application use case context information from respective subsystems in the ADAS and/or autonomous driving SoC, as rendered obvious by Sakarda, in order to “execute threads at a lower power consumption” (Sakarda; see col.7, particularly lines 54-63).
Regarding Claim 18, Patki et al. teaches the claimed apparatus of claim 17, in which the means for triggering the selected subset of diagnostic procedures is a dedicated diagnostics trigger pin (“The computing device 140 (see FIGS. 1 and 4) may configure the trace engine 220 (e.g., apply any platform specific configuration) via the target DP and DN contacts 240 and 242, the access port 216, and the connection 284”, see P[0042]).
Patki et al. does not expressly recite the claimed
and the application use case context information is received from a system scheduler, the system scheduler configured to collect application use case context information.
However, Sakarda (8,161,482) teaches a scheduler that maps context to each core of a system, where the system may be a System on a Chip (SoC) (Sakarda; see col.6, particularly lines 57-67 and col.7, particularly lines 1-4, see col.10, particularly lines 4-21).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patki et al. with the teachings of Sakarda, and the application use case context information is received from a system scheduler, the system scheduler configured to collect application use case context information, as rendered obvious by Sakarda, in order to “execute threads at a lower power consumption” (Sakarda; see col.7, particularly lines 54-63).
Regarding Claim 20, Patki et al. does not expressly recite the claimed apparatus of claim 17, in which the application use case context information is received from a set of schedulers, each scheduler of the set of schedulers configured to collect application use case context information from respective subsystems in the ADAS and/or autonomous driving SoC.
However, Sakarda (8,161,482) teaches receiving a context from a scheduler (Sakarda; see Claim 15), and teaches a first scheduler for a first operating system core and a second scheduler for a second operating system core, where context information may be provided by each scheduler (Sakarda; see col.3, particularly lines 57-67 and col.4, particularly lines 1-18, also see col.5, particularly lines 32-67 and col.6, particularly lines 1-28 and 57-67 and col.7, particularly lines 1-4).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patki et al. with the teachings of Sakarda, and the apparatus of claim 17, in which the application use case context information is received from a set of schedulers, each scheduler of the set of schedulers configured to collect application use case context information from respective subsystems in the ADAS and/or autonomous driving SoC, as rendered obvious by Sakarda, in order to “execute threads at a lower power consumption” (Sakarda; see col.7, particularly lines 54-63).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ISAAC G SMITH whose telephone number is (571)272-9593. The examiner can normally be reached Monday-Thursday, 8AM-5PM.
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.
/ISAAC G SMITH/ Primary Examiner, Art Unit 3662