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 .
This office action is in response to Applicant’s Amendment filed 03/12/2026. Claims 1-2 and 5-20 are pending. Claims 1, 9, 11, 15-16, and 18 have been amended. Claims 3 and 4 have previously been cancelled. Any examiner’s note, objection, or rejection not repeated is withdrawn due to Applicant’s amendment.
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 03/12/2026 has been entered.
Priority
Applicant’s claim for priority from application no. 63/261827 filed 09/29/2021 is acknowledged.
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.
Claims 1-2, 5-8, 15-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fozard et al. (US 20210109796 A1) in view of Zhou et al. (US 20190056972 A1), hereinafter referred to as Fozard and Zhou, respectively.
Regarding Claim 1, Fozard discloses A system ([0004] the computer system) comprising: one or more processing units to perform operations ([0004] the method comprising operating the CPU) comprising: executing a plurality of runnables across a plurality of compute engines of a runtime system as part of one or more navigation, control, or localization operations performed by a machine ([0124] Applications 108 may operate on data 106 to safely navigate the autonomous vehicle (e.g., prevent collisions) […] In various cases, operating on data 106 may involve, by way of non-limiting examples, processing the data using one or more neural network models. Please note that the applications 108 operating on data 106 to safely navigate the autonomous vehicle corresponds to the execution being part of navigation operations performed by a machine. Since the operations can be processed using neural network models described below by Fozard, this corresponds to a executing a plurality of runnables across a plurality of compute engines of a runtime system. As Applicant states “one or more of” the operations, this is interpreted as fulfilling the requirement of the limitation.) ;
maintaining compliance of one or more safety parameters corresponding to the navigation, control, or localization operations ([0139] execution of workloads (e.g., neural networks) is performed in a deterministic, and time- and space-bounded manner, the NNM may receive a Healthy Case Execution Time (HCET) value from each application in respect of a submitted workload.; [0140] The concept of HCET is important to a deterministic system so as to ensure that workload tasks, including neural net-based computations, are executed in a time-bounded manner, and that applications (e.g., safety-critical applications) receive output responses within expected time frames. This feature finds significant importance in safety-critical applications, where timely execution of workloads (e.g., neural network computations) may be required for safe operation of a system. Please note that the NNM corresponds to the monitoring system, and ensuring that the workloads comply with HCETs for safety-critical applications corresponds to maintaining compliance of safety parameters.) based at least on monitoring execution of the plurality of runnables ([0031] monitor a workload execution level of each of the plurality of compute resource units. Please note that monitoring a workload execution level of each of the plurality of compute resource units corresponds to Applicant’s monitoring execution of a plurality of runnables), the executing being based at least on a schedule ([0035] scheduling execution of the workload requests. Please note that scheduling execution of the workload requests corresponds to Applicant’s execution being based on a schedule.);
wherein: a set of runnables of the plurality of runnables is fully executed during individual time frames of multiple time frames, as dictated by the schedule ([0139] execution of workloads (e.g., neural networks) is performed in a deterministic, and time- and space-bounded manner, the NNM may receive a Healthy Case Execution Time (HCET) value from each application in respect of a submitted workload.; [0140] The concept of HCET is important to a deterministic system so as to ensure that workload tasks, including neural net-based computations, are executed in a time-bounded manner, and that applications (e.g., safety-critical applications) receive output responses within expected time frames. This feature finds significant importance in safety-critical applications, where timely execution of workloads (e.g., neural network computations) may be required for safe operation of a system. Please note that each application in respect of a submitted workload having a HCET and having expected time frames to receive output responses of applications as part of timely execution of workloads corresponds to a set of runnables of the plurality of runnables being fully executed during individual time frames of multiple time frames as dictated by the schedule, as each application, corresponding to runnable of the plurality of runnables, has to be fully executed during individual time frames of multiple time frames, as dictated by the schedule, i.e., HCET and the timely execution of workload.;
and determining whether the execution of the runnable satisfies a timing constraint based at least on the second timestamp and the schedule ([0019] In some embodiments, the general processing unit is further configured to: monitor an execution time of the high-priority workload on the at least one processing unit; and determine if the execution time has exceeded a Healthy Case Execution Time (HCET).; [0020] In some embodiments, the HCET comprises a pre-determined range of expected execution time. Please note that determining if the high-priority workload execution time has exceeded a HCET that is a predetermined range corresponds to Applicant’s determining whether the execution of the runnable satisfies a timing constraint based at least on the second timestamp and the schedule, as the upper bound of the HCET that is not to be exceeded corresponds to Applicant’s second timestamp and schedule that is the basis of the timing constraint to be satisfied.).
Fozard does not explicitly disclose the monitoring comprising: determining a mapping between a first clock associated with the runtime system and a second clock associated with the runtime system, wherein: and the mapping is updated, during execution of the plurality of runnables, based at least on initialization of one or more time frames of the multiple time frames; receiving a first timestamp corresponding to execution of a runnable of the plurality of runnables, the first timestamp being based at least on the first clock; determining a second timestamp based at least on the first timestamp and the mapping between the first clock and the second clock;
However, Zhou discloses the monitoring comprising: determining a mapping between a first clock associated with the runtime system and a second clock associated with the runtime system ([0040] In response to determining that the multiple TSCs are synchronized, the time stamp generating module 112g may use base ticks of a master core as a common time reference point for all other cores in multicore platform. If the time stamp generating module 112g determines that the multiple TSC are not synchronized, the timestamp generating module 112g, may calculate, for each core, clock offset ticks between the master core and a particular non-master core. Please note that the TSC (TimeStamp Counter) of the master core corresponds to Applicant’s first clock associated with the runtime system, the TSC of a particular non-master core corresponds to Applicant’s second clock associated with the runtime system, and using clock offset ticks to synchronize them corresponds to Applicant’s determining the mapping between them, as Applicant states in [00262] that mappings can be determined by comparing clock counts to achieve a normalized clock.),
and the mapping is updated, during execution of the plurality of runnables, based at least on initialization of one or more time frames of the multiple time frames ([0040] upon startup, at 202, the time stamp generating module 112g may determine local base ticks on each core […] In one embodiment, step 202 may involve the time stamp generating module 112g first determining whether the multiple TSCs are synchronized. In response to determining that the multiple TSCs are synchronized, the time stamp generating module 112g may use base ticks of a master core as a common time reference point for all other cores in multicore platform.; [0053] As noted above, the time adjusting module 112h is configured and operable to periodically adjust base time utilized by the time stamp generating module 112g based on the correct external time. Referring now to FIG. 6, there is shown a flow diagram of operational steps of the time adjusting module of FIG. 1 in accordance with an illustrative embodiment of the present invention. At 602, the time adjusting module 112h may periodically retrieve system time from the OS 112b. In turn, the OS 112b may periodically synchronize its clock with an external network time source.; [0054] Next, at 604, the time adjusting module 112h determines whether the base time utilized by the time stamp generating module 112g should be adjusted. The time adjusting module 112h should keep the adjustment period substantially consistent with the adjusting cycle time of the external time synchronization service (i.e., NTP). In one embodiment, the time adjusting module 112h may determine whether the base time should be adjusted. Please note that determining the local base ticks on each upon startup for the time stamp generating module 112g corresponds to Applicant’s initialization of a time frame of the multiple time frames, as it initializes the start time of the timestamp generating module 112g which is used to generate times for a schedule. Furthermore, using the base tick of a master core as a common time reference point for all other cores upon first determining the TSCs are synchronized corresponds to Applicant’s updating the mapping being based on an initialization of the timing frame of the schedule, as Applicant states in [00262] that mappings can be determined by comparing clock counts to achieve a normalized clock, i.e., synchronizing the clocks, which occurs at a time that is based on the local base ticks initialized at startup. Furthermore, as the time adjusting module 112h periodically adjusts the base time utilized by the time stamp generating module 112g corresponds to Applicant’s updating the mapping during the execution of the plurality of runnables, as it periodically, i.e., during execution, adjusts the base time that is used to generate times for the schedule.);
receiving a first timestamp corresponding to execution of a runnable of the plurality of runnables, the first timestamp being based at least on the first clock ([0034] the monitoring applications 112e may include one or more modules that implement soft clock which can be used for packet timestamping purposes; [0037] Generally, there are a few different clock sources that can be utilized in a virtual environment. Please note that having a clock source of multiple clock sources that can be utilized in a virtual environment corresponds to Applicant’s first clock associated with a compute engine of the plurality of compute engines associated with the execution of the runnable, and implementing the clock for packet timestamping purposes in the monitoring applications 112e corresponds to Applicant’s receiving a first timestamp corresponding to execution of a runnable of the plurality of runnables that is based on the first clock.);
determining a second timestamp based at least on the first timestamp and the mapping between the first clock and the second clock ([0040] In response to determining that the multiple TSCs are synchronized, the time stamp generating module 112g may use base ticks of a master core as a common time reference point for all other cores in multicore platform. If the time stamp generating module 112g determines that the multiple TSC are not synchronized, the timestamp generating module 112g, may calculate, for each core, clock offset ticks between the master core and a particular non-master core. Please note that the TSC (TimeStamp Counter) of the master core corresponds to Applicant’s first clock, the TSC of a particular non-master core corresponds to Applicant’s second clock, and using clock offset ticks to synchronize them corresponds to Applicant’s mapping them, as Applicant states in [00262] that mappings can be determined by comparing clock counts to achieve a normalized clock. Furthermore, as the second TSC that is synchronized is used by the timestamp generating module 112g, it corresponds to Applicant’s determining a second timestamp, which, since it is being synchronized with relation to the first TSC being used for the first timestamp, corresponds to Applicant’s being based on the first timestamp.);
Fozard and Zhou are both considered to be analogous to the claimed invention because they are in the same field of computer application execution monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Fozard to incorporate the teachings of Zhou to modify the schedule-based timing constrained execution monitoring system to receive first and second timestamps corresponding to the execution of runnables that are based on mapped first and second clocks, allowing for precise time-based monitoring of execution as described in Zhou.
Regarding Claim 2, Fozard- Zhou as described in Claim 1, Fozard further discloses one or more of: causing a modification of the schedule in response to determining that completion of the runnable does not satisfy the timing constraint; or executing a safety protocol in response to determining that completion of the runnable does not satisfy the timing constraint ([0019] Healthy Case Execution Time (HCET); [0022] if the execution time has exceeded the HCET, the general processing unit is further configured to: modify an execution profile configuration. Please note that modifying the execution profile configuration in response to the execution time exceeding the HCET corresponds to Applicant’s modifying the schedule in response to determining that the completion of the runnable does not satisfy the timing constraint, as the execution profile configuration corresponds to Applicant’s schedule, the execution time corresponds to Applicant’s completion of the runnable, and the HCET corresponds to Applicant’s timing constraint. As Applicant states “one or more of” the actions, this is interpreted as fulfilling the requirement of the limitation.)
Regarding Claim 5, as described in Claim 1 , Zhou further discloses the first timestamp corresponds to a third clock of a system task manager, and further wherein the mapping includes a first mapping between the first clock and the third clock and a second mapping between the second clock and the third clock ([0040] After the clock rate for the processor 112 has been calculated as described above, for example, In response to determining that the multiple TSCs are synchronized, the time stamp generating module 112g may use base ticks of a master core as a common time reference point for all other cores in multicore platform. If the time stamp generating module 112g determines that the multiple TSC are not synchronized, the timestamp generating module 112g, may calculate, for each core, clock offset ticks between the master core and a particular non-master core. Please note that since the TSCs will be synchronized across all cores for the processor 112 and the TSC is being used in the time stamp generating module 112g, this corresponds to Applicant’s first timestamp corresponding to a third clock of a system task manager as it will be synchronized. Furthermore, Applicant’s first mapping between the first and third clock and a second mapping between the second clock and third clock is fulfilled by setting offset ticks between the first (master) core and the subsequent second and third non-master cores to synchronize them, as Applicant states in [00262] that mappings can be determined by comparing clock counts to achieve a normalized clock. Therefore, it would be possible for a person of ordinary skill in the art to map the first clock to the third clock with one offset, and to map the second and third clock with another, resulting in 2 distinct mappings, as each core requires a different offset to synchronize to the next.).
Regarding Claim 6, as described in Claim 1, Fozard further discloses wherein the determining whether the execution of the runnable satisfies the timing constraint includes determining one or more of: whether completion of the runnable occurred after a scheduled finish time of the runnable as indicated by the schedule; whether initialization of the runnable occurred before a scheduled start time of the runnable as indicated by the schedule; whether a duration of the execution of the runnable was greater than a scheduled execution time of the runnable as indicated by the schedule; whether the duration of the execution of the runnable was less than the scheduled execution time of the runnable as indicated by the schedule; or whether the duration of the execution of the runnable was substantially equal to the scheduled execution time of the runnable as indicated by the schedule ([0183] determine whether the execution time has exceeded the HCET specified at 302. Please note that determining whether the execution time has exceeded the Healthy Case Execution Time corresponds to Applicant’s determining whether a duration of the execution of the runnable was greater than a scheduled execution time of the runnable as indicated by the schedule, as the HCET corresponds to Applicant’s scheduled execution time and the execution time corresponds to Applicant’s duration of the execution of the runnable. As Applicant states determining “one or more of” the options by which the execution of the runnable can satisfy the timing constraint, this is interpreted as fulfilling the requirement of the limitation.)
Regarding Claim 7, as described in Claim 1, Fozard further discloses determining that a frame that corresponds to the execution of the runnable satisfies a corresponding frame timing constraint in an instance in which the runnable fails to satisfy the timing constraint ([0020] In some embodiments, the HCET comprises a pre-determined range of expected execution time; [0183] determine whether the time difference between the current lapsed execution time, and the time stamp generated at 304, has exceeded the HCET. Please note that the time difference between the current lapsed execution time and time stamp generated at 304 corresponds to Applicant’s frame corresponding to the execution of the runnable, and the HCET range corresponds to Applicant’s corresponding frame timing constraint; thus, the frame exceeding the HCET range corresponds to determining that the frame satisfies the timing constraint in an instance in which the runnable fails to satisfy the timing constraint, i.e., exceeds it.).
Regarding Claim 8, as described in Claim 1, Fozard further discloses wherein the system is comprised in at least one of: a perception system for an autonomous machine ([0124] host computer system 100a may be deployed in an autonomous vehicle, and applications 108 may provide safe autonomous operation of the vehicle […] data 106 can be acquired from one or more sensors mounted to the autonomous vehicles, and which are used for monitoring the vehicle's surrounding environment. Please note that the host computer system 100a being deployed in an autonomous vehicle, providing safe autonomous operation of the vehicle and monitoring the vehicle’s surrounding environment using sensors corresponds to Applicant’s system being comprised in a perception system for an autonomous machine.)
Regarding Claim 15, Fozard discloses A system ([0004] the computer system) comprising: a runtime system comprising: one or more compute engines to execute a plurality of runnables as part of one or more control, navigation, or localization operations performed by a machine ([0124] Applications 108 may operate on data 106 to safely navigate the autonomous vehicle (e.g., prevent collisions) […] In various cases, operating on data 106 may involve, by way of non-limiting examples, processing the data using one or more neural network models. Please note that the applications 108 operating on data 106 to safely navigate the autonomous vehicle corresponds to the execution being part of navigation operations performed by a machine. Since the operations can be processed using neural network models described below by Fozard, this corresponds to a runtime system comprising one or more compute engines to execute a plurality of runnables. As Applicant states “one or more of” the operations, this is interpreted as fulfilling the requirement of the limitation.);
and a task management system to manage execution of the plurality of runnables by the one or more compute engines based at least on a deterministic execution schedule that dictates a timing and order of execution of the plurality of runnables by the one or more compute engines ([0139] execution of workloads (e.g., neural networks) is performed in a deterministic, and time- and space-bounded manner, the NNM may receive a Healthy Case Execution Time (HCET) value from each application in respect of a submitted workload.; [0140] workload tasks, including neural net-based computations, are executed in a time-bounded manner, and that applications (e.g., safety-critical applications) receive output responses within expected time frames. Please note that the NNM performing execution of workloads in a deterministic, time bounded manner, where each application has a HCET value in respect of a submitted workload corresponds to Applicant’s task management system to manage execution of the plurality of runnables by the one or more compute engines based at least on a deterministic execution schedule that dictates a timing and order of execution of the plurality of runnables by the one or more compute engines. Since they are time bounded where each output response is within expected time frames, this corresponds to the timing and order of execution of the plurality of runnables being dictated.);
and a monitoring system to help maintain compliance of one or more safety parameters corresponding to the one or more control, navigation, or localization operations ([0139] execution of workloads (e.g., neural networks) is performed in a deterministic, and time- and space-bounded manner, the NNM may receive a Healthy Case Execution Time (HCET) value from each application in respect of a submitted workload.; [0140] The concept of HCET is important to a deterministic system so as to ensure that workload tasks, including neural net-based computations, are executed in a time-bounded manner, and that applications (e.g., safety-critical applications) receive output responses within expected time frames. This feature finds significant importance in safety-critical applications, where timely execution of workloads (e.g., neural network computations) may be required for safe operation of a system. Please note that the NNM corresponds to the monitoring system, and ensuring that the workloads comply with HCETs for safety-critical applications corresponds to maintaining compliance of safety parameters.) based at least on operations comprising:
tracking, by the monitoring system, an amount of time that has passed from when the communication was received by the monitoring system from the task management system ([0181] the NNM 226 can timestamp the workload request, which is received from the application; [0182] The NNM 226 may then monitor the execution time of the inference engine, or otherwise, execution time of the workload by a processor. Please note that the NNM 226 monitoring the execution time of the workload, where the NNM 226 has timestamp the workload request received from the application corresponds to Applicant’s monitoring system tracking an amount of time that has passed from when the communication was received by the monitoring system from the task management system);
and determining, by the monitoring system, that the runtime system has an execution issue based at least on: the monitoring system determining that the amount of time that has passed exceeds a duration threshold amount of time ([0184] If the application is “blocking” (e.g., the inference engine allocated to the application is failing to complete execution within the time budget, and therefore is not available for use by other applications), the NNM 226 can return an error code indicating that the HCET has been exceeded. In other cases, if the application is awaiting a “notification”, the NNM 26 can notify the application with an error code indicating that the HCET has been exceeded. Please note that the NNM returning an error code indicating the HCET has been exceeded when awaiting a notification corresponds to Applicant’s determining, by the monitoring system, that the runtime system has an execution issue based on the monitoring system determining that the amount of time that has passed exceeds a duration threshold amount of time, as returning an error code from the NNM corresponds to Applicant’s monitoring system determining that the runtime system has an execution issue, and doing so based on the HCET being exceeded while waiting for a notification corresponds to Applicant’s amount of time before a subsequent communication being received by the monitoring system exceeding a duration threshold amount of time.);
and a subsequent communication not being received by the monitoring system before the amount of time that has passed exceeds the duration threshold amount of time ([0177] A HCET refers to a time allocated for a specific neural network to return a response in order for execution of that neural network to be considered “healthy.” If a response is not received within the HCET timeframe, the neural network may be determined as being in an “unhealthy” state.; [0184] If the application is “blocking” (e.g., the inference engine allocated to the application is failing to complete execution within the time budget, and therefore is not available for use by other applications), the NNM 226 can return an error code indicating that the HCET has been exceeded. In other cases, if the application is awaiting a “notification”, the NNM 26 can notify the application with an error code indicating that the HCET has been exceeded. Please note that, since the HCET is a time allocated to wait for a response to be returned for an execution, this corresponds to Applicant’s subsequent communication not being received by the monitoring system before the amount of time that has passed exceeds the duration threshold amount of time, i.e., the NNM determining it is “unhealthy” after the HCET timeframe is passed, since the response was not received before the amount of time that has passed exceeds the duration threshold amount of time.)
Fozard does not explicitly disclose receiving, by the monitoring system from the task management system, a communication related to execution of one or more runnables of the plurality of runnables using the one or more compute engines of the runtime system;
However, Zhou discloses receiving, by the monitoring system from the task management system, a communication related to execution of one or more runnables of the plurality of runnables using the one or more compute engines of the runtime system ([0034] the monitoring applications 112e may include one or more modules that implement soft clock which can be used for packet timestamping purposes; [0036] virtual machines without accurate time keeping may experience issues with network applications and processes. Please note that receiving timestamped packets to allow accurate time keeping in monitoring applications corresponds to Applicant’s receiving a communication from the task management system by the monitoring system related to execution of one or more runnables of the plurality of runnables using one or more compute engines of a runtime system, as the virtual machines which correspond to Applicant’s compute engines of a runtime system run the monitoring applications corresponding to Applicant’s runnables and send timestamped packets corresponding to Applicant’s communications.);
Fozard and Zhou are both considered to be analogous to the claimed invention because they are in the same field of computer application execution monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Fozard to incorporate the teachings of Zhou to modify the schedule-based timing constrained execution monitoring system that tracks an amount of time that has passed from when the communication was received by the monitoring system from the task management system and identifies execution issues based on subsequent communication time exceeding a duration threshold to receive communications related to the execution of the runnables, allowing for precise time-based monitoring of execution as described in Zhou.
Regarding Claim 16, Fozard-Zhou as described in Claim 15, Fozard further discloses wherein the duration threshold amount of time is based at least on an expected duration between communications received from the runtime system ([0184] If the application is “blocking” (e.g., the inference engine allocated to the application is failing to complete execution within the time budget, and therefore is not available for use by other applications), the NNM 226 can return an error code indicating that the HCET has been exceeded. In other cases, if the application is awaiting a “notification”, the NNM 26 can notify the application with an error code indicating that the HCET has been exceeded. Please note that the HCET designating the “healthy case” execution time corresponds to Applicant’s duration threshold amount of time based on an expected duration, and the HCET applying to the time spent waiting for a notification corresponds to Applicant’s expected duration between communications received from the runtime system, as the inference engine corresponds to Applicant’s runtime system.).
Regarding Claim 17, Fozard-Zhou as described in Claim 16, Fozard further discloses wherein the expected duration is based at least on one or more of: a schedule related to the execution of the one or more runnables; a timing frame of the execution schedule; or a scheduled runtime of a runnable that is scheduled to occur subsequent to the one or more runnables that correspond to the communication ([0183] determine whether the execution time has exceeded the HCET specified at 302. Please note that the Healthy Case Execution Time corresponds to Applicant’s expected duration being based on a timing frame of the execution schedule, as the HCET is a timing frame of the execution schedule that has an expected duration. As Applicant states “one or more of” the bases of the excepted duration, this is interpreted as fulfilling the requirement of the limitation.)
Regarding Claim 18, Fozard-Zhou as described in Claim 15, Fozard further discloses wherein the duration threshold amount of time is based at least on an expected propagation time of communications from the runtime system to the monitoring system ([0135] a neural network manager (NNM) which can be used for executing workloads; [0184] If the application is “blocking” (e.g., the inference engine allocated to the application is failing to complete execution within the time budget, and therefore is not available for use by other applications), the NNM 226 can return an error code indicating that the HCET has been exceeded. In other cases, if the application is awaiting a “notification”, the NNM 26 can notify the application with an error code indicating that the HCET has been exceeded. Please note that the NNM corresponds to Applicant’s monitoring system, the inference engine allocated to the application to complete execution corresponds to Applicant’s runtime system, the HCET corresponds to Applicant’s duration threshold amount of time based on an expected propagation time, and the application awaiting a notification within the HCET corresponds to Applicant’s expected propagation time of communications from the runtime system to the monitoring system.).
Regarding Claim 20, Fozard-Zhou as described in Claim 15, Fozard further discloses wherein the system is comprised in at least one of: a perception system for an autonomous machine ([0124] host computer system 100a may be deployed in an autonomous vehicle, and applications 108 may provide safe autonomous operation of the vehicle […] data 106 can be acquired from one or more sensors mounted to the autonomous vehicles, and which are used for monitoring the vehicle's surrounding environment. Please note that the host computer system 100a being deployed in an autonomous vehicle, providing safe autonomous operation of the vehicle and monitoring the vehicle’s surrounding environment using sensors corresponds to Applicant’s system being comprised in a perception system for an autonomous machine.)
Claims 9 and 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Fozard et al. (US 20210109796 A1) in view of Zebchuk et al. (US 20210064421 A1), and further in view of Niranjayan (US 10477355 B1), hereinafter referred to as Fozard, Zebchuk, and Niranjayan, respectively.
Regarding Claim 9, Fozard discloses A system ([0004] the computer system) comprising: one or more processing units to perform operations ([0004] the method comprising operating the CPU) comprising: executing, using a runtime system, a plurality of runnables as part of one or more autonomous operations performed by a machine ([0124] Applications 108 may operate on data 106 to safely navigate the autonomous vehicle (e.g., prevent collisions) […] In various cases, operating on data 106 may involve, by way of non-limiting examples, processing the data using one or more neural network models. Please note that the applications 108 operating on data 106 to safely navigate the autonomous vehicle corresponds to the execution being part of autonomous operations performed by a machine. Since the operations can be processed using neural network models described below by Fozard, this corresponds to executing, using a runtime system, a plurality of runnables.);
maintaining compliance of one or more safety parameters corresponding to the one or more autonomous operations parameters ([0139] execution of workloads (e.g., neural networks) is performed in a deterministic, and time- and space-bounded manner, the NNM may receive a Healthy Case Execution Time (HCET) value from each application in respect of a submitted workload.; [0140] The concept of HCET is important to a deterministic system so as to ensure that workload tasks, including neural net-based computations, are executed in a time-bounded manner, and that applications (e.g., safety-critical applications) receive output responses within expected time frames. This feature finds significant importance in safety-critical applications, where timely execution of workloads (e.g., neural network computations) may be required for safe operation of a system. Please note that the NNM corresponds to the monitoring system, and ensuring that the workloads comply with HCETs for safety-critical applications corresponds to maintaining compliance of safety parameters corresponding to the autonomous operations parameters.) based at least on monitoring execution of a plurality of runnables ([0031] monitor a workload execution level of each of the plurality of compute resource units. Please note that monitoring a workload execution level of each of the plurality of compute resource units corresponds to Applicant’s monitoring execution of a plurality of runnables), the executing being based at least on a schedule ([0035] scheduling execution of the workload requests. Please note that scheduling execution of the workload requests corresponds to Applicant’s execution being based on a schedule.),
Fozard does not explicitly disclose the monitoring comprising: obtaining a hash value corresponding to execution of a runnable of the plurality of runnables; and determining whether the execution of the runnable satisfies a corresponding execution order according to the schedule based at least on the hash value and the schedule
However, Zebchuk discloses the monitoring comprising: obtaining a hash value corresponding to execution of a runnable of the plurality of runnables([0125] the tag value 564 can be a hash […] defining a unique work “flow.” Please note that a hash defining a unique work flow corresponds to Applicant’s hash value correspond to execution of a runnable of the plurality of runnables, as it is a unique flow among other flows.); and determining whether the execution of the runnable satisfies a corresponding execution order according to the schedule based at least on the hash value and the schedule ([0125] The tag value 564 allows the virtualized scheduler 102, disclosed above, to scheduler work for a same flow (from a source to a destination) to be ordered and synchronized. Please note that ordering work for a same flow using the tag value 564 and the virtualized scheduler 102 corresponds to Applicant’s determining whether the execution of the runnable satisfies a corresponding execution order based on the hash value (tag value 564) and the schedule (set by the virtualized scheduler 102).).
Fozard and Zebchuk are both considered to be analogous to the claimed invention because they are in the same field of computer application execution monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Fozard to incorporate the teachings of Zebchuk to modify the schedule-based timing constrained execution monitoring system to obtain hash values corresponding to execution of a runnable and determining whether it satisfies a corresponding execution order according to the schedule, allowing for uniquely identifiable runnable monitoring in order, as described in Zebchuk.
Fozard-Zebchuk does not explicitly disclose the hash value being generated upon completion of execution of the runnable.
However, Niranjayan discloses the hash value being generated upon completion of execution of the runnable (Col. 26, Lines 29-44- the EMS 106 may encode data. The receiver 530 or the hardware processor 522 may decode, decrypt, or otherwise demodulate and process the demodulated signal to determine the characteristic data 128. For example, the receiver 530 may provide as output the digital representation of a signal that incorporates binary phase shift keying (BPSK) or other techniques. […] For example, a hash function may be applied to the characteristic data 128 to generate hash output. A comparison of the hash output may be made to determine if an error is present. Please note that the hash function being applied to the characteristic data 128 to generate hash output, after the demodulated signal has been processed to determine the characteristic data, corresponds to Applicant’s hash value being generated upon completion of execution of the runnable, as the hash function is applied once the demodulation process is executed.)
Fozard-Zebchuk and Niranjayan are both considered to be analogous to the claimed invention because they are in the same field of using hashing to identify data in computer systems. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Fozard-Zebchuk to incorporate the teachings of Niranjayan to modify the schedule-based timing constrained execution monitoring system that obtains hash values corresponding to execution of a runnable and determining whether it satisfies a corresponding execution order according to the schedule to have the hash value being generated upon completion of the execution of the runnable, allowing for the preservation of sequence in the hashing and the identification of a particular output, as described in Niranjayan.
Regarding Claim 11, Fozard-Zebchuk-Niranjayan as described in Claim 9, Zebchuk further discloses wherein the hash value is based at least on an identifier of a frame corresponding to the runnable ([0125] the tag value 564 can be a hash […] defining a unique work “flow.” […] The same flow has the same tag value, so it can be ordered and synchronized. Please note that the same flow having the same tag value that is a hash used for ordering and synchronization corresponds to Applicant’s hash value being based at least on an identifier of a frame corresponding to the runnable. As Applicant states in [00260] of the Specification, “the timestamps may correspond to frames of the schedule 604. For example, a timestamp that corresponds to a start of a particular frame may be considered as a reference time or time zero "t0" with respect to the particular frame and subsequent timestamps that correspond to runnables executed during the particular frame may be considered subsequent times "tl . . . tn" associated with the particular frame.” Therefore, the “identifier of a frame corresponding to the runnable” is used to track the order of execution and synchronize it, since the start of a frame is a reference time, and thus the hash value that identifies a unique work flow for ordering and synchronizing corresponds to Applicant’s hash value based on an identifier of a frame correspond to the runnable.).
Regarding Claim 12, Fozard-Zebchuk-Niranjayan as described in Claim 9, Zebchuk further discloses wherein a time of the determining whether the completion of the runnable satisfies the execution order is based at least on one or more of an ending of a timing frame of the schedule or a start of the timing frame ([0138] A Schedule/Sync and Order (SSO) module 602 queues and schedules work for the processor cores 640a-k. According to an example embodiment, the SSO module 602 is the virtualized scheduler 102, disclosed above with regard to FIG. 1A. The network service processor 650 includes a timer unit 649 that may be used by the SSO module 602 to schedule work for the processor cores 640a-k. Please note that a timer unit being used by the SSO unit to queue and schedule work corresponds to Applicant’s time of determining whether the completion of the runnable satisfies the execution order being based on an ending of a timing frame of the schedule, as it is known in the art that a queue that schedules work (corresponding to Applicant’s runnable) moves on to the next work to be done in the execution order once the previous work in the queue is completed, i.e., after an ending of the timing frame of the previously scheduled work. As Applicant states “one or more of” the ways to determine whether the completion of the runnable satisfies the execution order, this is interpreted as fulfilling the requirement of the limitation.).
Regarding Claim 13, Fozard-Zebchuk-Niranjayan as described in Claim 9, Zebchuk further discloses wherein the determining whether the completion of the runnable satisfies the execution order includes determining one or more of: whether initiation of the runnable occurred prior to completion of one or more parent runnables on which the runnable depends; whether completion of the runnable occurred outside of the execution order; or identifying one or more skipped runnables that were scheduled to execute before the runnable but that did not execute before the runnable. ([0094] Work scheduled to a given work processing entity may be descheduled by the given work processing entity in an event the given work processing entity is unable to complete the work at the time of scheduling. Such descheduled work may be re-scheduled at a later time in order to be completed by the given work processing entity or another work processing entity. Please note that descheduling work scheduled to a given work processing entity in the event the given work processing entity is unable to complete the work at the time of scheduling corresponds to Applicant’s determining whether the completion of the runnable satisfies the execution order by identifying one or more skipped runnables that were scheduled to execute before the runnable but that did not execute before the runnable, as the given work processing entity would have been scheduled to execute in the queue but as it would be unable to complete the work at the time of scheduling, it was skipped and can be re-scheduled later, i.e., identified as an runnable that was scheduled to execute before the runnable but did not. As Applicant states “one or more of” the ways to determine whether the completion of the runnable satisfies the execution order, this is interpreted as fulfilling the requirement of the limitation.).
Regarding Claim 14, Fozard-Zebchuk-Niranjayan as described in Claim 9, Fozard further discloses wherein the system is comprised in at least one of: a perception system for an autonomous machine ([0124] host computer system 100a may be deployed in an autonomous vehicle, and applications 108 may provide safe autonomous operation of the vehicle […] data 106 can be acquired from one or more sensors mounted to the autonomous vehicles, and which are used for monitoring the vehicle's surrounding environment. Please note that the host computer system 100a being deployed in an autonomous vehicle, providing safe autonomous operation of the vehicle and monitoring the vehicle’s surrounding environment using sensors corresponds to Applicant’s system being comprised in a perception system for an autonomous machine.)
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Fozard et al. (US 20210109796 A1) in view of Zebchuk et al. (US 20210064421 A1) further in view of Niranjayan (US 10477355 B1) as applied to Claim 9 above, and further in view of Vezier et al. (US 20200334081 A1), hereinafter referred to as Fozard, Zebchuk, Niranjayan, and Vezier, respectively.
Regarding Claim 10, Fozard-Zebchuk- Niranjayan as described in Claim 9 does not explicitly disclose executing a safety protocol in response to determining that completion of the runnable does not satisfy the execution order.
However, Vezier discloses executing a safety protocol in response to determining that completion of the runnable does not satisfy the execution order ([0246] a functional safety solution called time-sliced and compare approach. It is a particular implementation of a lock-step mechanism. [0250] And, the outputs of both instances are compared at any clock cycle. In normal condition, the comparison should never fail [0251] If the comparison fails, this means that one of the two instances has a problem. Then a safety error is raised to the safety manager module to enter fault reaction scenario. Please note that the lock-step mechanism comparing outputs of instances in clock cycles corresponds to Applicant’s completion of the runnable satisfying an execution order, as it is known in the art that a lock-step mechanism requires a particular sequence of execution. Furthermore, a safety error being raised if the comparison fails and entering a fault reaction scenario corresponds to Applicant’s executing a safety protocol in response to determining the completion of the runnable does not satisfy the execution order.).
Fozard-Zebchuk-Niranjayan and Vezier are both considered to be analogous to the claimed invention because they are in the same field of time-based computer application monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Fozard-Zebchuk-Niranjayan to incorporate the teachings of Vezier to modify the schedule-based timing constrained execution monitoring system to raise a safety error in the case that the completion of the runnable does not satisfy the execution order, allowing for better error handling and failover, as described in Vezier.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Fozard et al. (US 20210109796 A1) in view of Zhou et al. (US 20190056972 A1) as applied to Claim 15 above, and further in view of Vezier et al. (US 20200334081 A1), hereinafter referred to as Fozard, Zhou, and Vezier, respectively.
Regarding Claim 19, Fozard-Zhou as described in Claim 15 does not explicitly disclose wherein a safety protocol is executed in response to a determination that the runtime system has the execution issue.
However, Vezier discloses wherein a safety protocol is executed in response to a determination that the runtime system has the execution issue ([0246] a functional safety solution called time-sliced and compare approach. It is a particular implementation of a lock-step mechanism. [0250] And, the outputs of both instances are compared at any clock cycle. In normal condition, the comparison should never fail [0251] If the comparison fails, this means that one of the two instances has a problem. Then a safety error is raised to the safety manager module to enter fault reaction scenario. Please note that a safety error being raised if the comparison fails and entering a fault reaction scenario corresponds to Applicant’s executing a safety protocol in response to a determination that the runtime system has the execution issue, as the fault reaction scenario corresponds to Applicant’s safety protocol and the failed clock comparison corresponds to Applicant’s execution issue in the runtime system.).
Fozard-Zhou and Vezier are both considered to be analogous to the claimed invention because they are in the same field of time-based computer application monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Fozard-Zhou to incorporate the teachings of Vezier to modify the schedule-based timing constrained execution monitoring system to raise a safety error in the case that the completion of the runnable does not satisfy the execution order, allowing for better error handling and failover, as described in Vezier.
Response to Arguments
Applicant's arguments filed 03/12/2026 have been fully considered but they are not persuasive.
Applicant’s arguments are summarized as follows:
Regarding the rejections of independent Claim 1 and its dependent Claims 2 and 5-8 under 35 U.S.C. 103, the cited references, alone or in combination, do not disclose that the mapping between clocks also occurs after startup, i.e., during execution of the runnables, as disclosed in amended Claim 1. Therefore, the rejections of Claim 1 and its dependent Claims 2 and 5-8 under 35 U.S.C. 103 should be withdrawn.
Regarding the rejections of independent Claim 9 and its dependent Claims 11-14 under 35 U.S.C. 103, the cited references, alone or in combination, do not disclose that the hash value is generated upon completion of execution of a runnable, as disclosed in amended Claim 9. Therefore, the rejections of Claim 9 and its dependent Claims 11-14 under 35 U.S.C. 103 should be withdrawn.
Regarding the rejections of independent Claim 15 and its dependent Claims 16-18 and 20 under 35 U.S.C. 103, the cited references, alone or in combination, do not disclose the monitoring system performing the tracking operations and determining that the runtime system has an execution issue based on the factors mentioned in the amended Claim, as disclosed in amended Claim 15. Therefore, the rejections of Claim 15 and its dependent Claims 16-18 and 20 under 35 U.S.C. 103 should be withdrawn.
Regarding A, the examiner respectfully disagrees. As stated above, the combination of Fozard and Zhou discloses from Zhou in [0053-0054] that the time adjusting module 112h periodically adjusts the base time utilized by the time stamp generating module 112g, corresponding to Applicant’s updating the mapping during the execution of the plurality of runnables, as it periodically, i.e., during execution and after startup, adjusts the base time that is used to generate times for the schedule.
Therefore, the recited features can be found in the cited combination of references, and independent Claim 1 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. As a result, contrary to Applicant’s arguments, because the dependent claims 2 and 5-8 depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise remain rejected, and the application is not in condition for allowance. The rejections under 35 U.S.C. 103 are maintained.
Regarding B, the examiner respectfully disagrees. The Applicant’s arguments are moot, as the rejections of the Claims now rely on a new grounds of rejection, Fozard-Zebchuk-Niranjayan, which discloses the limitations stated by the Applicant via the combination of references, as stated above. Therefore, the recited features can be found in the cited combination of references, and independent Claim 9 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. As a result, contrary to Applicant’s arguments, because the dependent claims 11-14 depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise remain rejected, and the application is not in condition for allowance. The rejections under 35 U.S.C. 103 are maintained.
Regarding C, the examiner respectfully disagrees. As stated above, the combination of Fozard and Zhou discloses from Fozard in [0181-0184] that the NNM 226 monitoring the execution time of the workload, where the NNM 226 has timestamp the workload request received from the application corresponds to Applicant’s monitoring system tracking an amount of time that has passed from when the communication was received by the monitoring system from the task management system. Additionally, the NNM returning an error code indicating the HCET has been exceeded when awaiting a notification corresponds to Applicant’s determining, by the monitoring system, that the runtime system has an execution issue based on the monitoring system determining that the amount of time that has passed exceeds a duration threshold amount of time, as returning an error code from the NNM corresponds to Applicant’s monitoring system determining that the runtime system has an execution issue, and doing so based on the HCET being exceeded while waiting for a notification corresponds to Applicant’s amount of time before a subsequent communication being received by the monitoring system exceeding a duration threshold amount of time. Additionally, as stated in [0177], since the HCET is a time allocated to wait for a response to be returned for an execution, this corresponds to Applicant’s subsequent communication not being received by the monitoring system before the amount of time that has passed exceeds the duration threshold amount of time, i.e., the NNM determining it is “unhealthy” after the HCET timeframe is passed, since the response was not received before the amount of time that has passed exceeds the duration threshold amount of time.
Therefore, the recited features can be found in the cited combination of references, and independent Claim 15 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. As a result, contrary to Applicant’s arguments, because the dependent claims 16-18 and 20 depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise remain rejected, and the application is not in condition for allowance. The rejections under 35 U.S.C. 103 are maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Doshi et al. (US 20200127861 A1) discloses utilizing timestamps to data, validating hashes, synchronizing clocks, and using timestamps to ensure ordering (see [0106, 0110, 0114, 0136-139])
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARAZ T AKBARI whose telephone number is (571)272-4166. The examiner can normally be reached Monday-Thursday 9:30am-7:30pm ET.
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, April Blair can be reached at (571)270-1014. 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.
/FARAZ T AKBARI/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights