CTNF 18/290,916 CTNF 95806 DETAILED ACTION 07-03-aia AIA 15-10-aia 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-7 are pending in this application. Information Disclosure Statement The IDS filed on 01/22/2024 has been considered. 07-30-03-h AIA Claim Interpretation 07-30-03 AIA The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. 07-30-05 The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: OS jitter statistical information acquisition unit, input value acquisition unit, bare metal necessity determination unit, bare metal building unit, computation application generation unit, bare metal loader unit, bare metal cooperation unit, cache statistical information acquisition unit, computational load learning unit, computational load estimation unit in claims 1-7. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. As per claim 1: Lines 1-4 recite “an information processing apparatus that executes an application, the information processing apparatus comprising…an operating system”, line 14 recites “a processing block constituting the application”, and lines 16-18 recite “determine whether or not the processing block needs to be executed in a bare metal environment in which the operating system is not executed”. Therefore, it is unclear if the processing block constituting the application is able to be executed on the bare metal environment since the application executes on the information processing apparatus comprising an operating system. As per claim 2: Line 3 recites “table setting I/F” but it is unclear what this means. As per claim 4: Lines 8-11 recite “wherein a starting notification or a completion notification is transmitted and received between the processing blocks being included in the executable binary data for the operating system environment and the executable binary data for the bare metal environment and having dependence on each other” and it is unclear which executable binary data is transmitting the starting notification or transmitting the completion notification and which executable binary data is receiving the starting notification or receiving the completion notification. Additionally it is unclear what “the processing blocks” refers to. Claims 2-7 are dependent claims of claim 1, and fail to resolve the deficiencies of claim 1, so they are rejected for the same reasons. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more. As per claim 1, in step 1 of the 101 analysis, the examiner has determined that the claim is directed to an information processing apparatus. Therefore, the claim is directed to one of the four statutory categories of invention. In step 2A prong 1 of the 101 analysis, the examiner has determined that the claim recites a judicial exception. Specifically, the limitation “configured to determine whether or not the processing block needs to be executed in a bare metal environment in which the operating system is not executed, based on the OS jitter level and the computational load level" is a mental process since humans can mentally evaluate OS jitter level and computational load level to determine if a processing block should be executed in a bare metal environment. In step 2A prong 2 of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not integrate the judicial exceptions into a practical application for the following rationale: The limitations "configured to acquire OS jitter statistical information being statistical information of OS jitter occurring in processing of the operating system, an OS jitter statistical information table defining an OS jitter level being a level of OS jitter, the OS jitter level being associated with the OS jitter statistical information…configured to acquire an input value of the application, a computational load table defining a computational load level being a level of a computational load of a processing block constituting the application, the computational load level being associated with the input value” represent insignificant, extra-solution activities. The term "extra-solution activity" can be understood as "activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim" (MPEP 2106.05(g)). The examiner has determined that the limitations "configured to acquire OS jitter statistical information being statistical information of OS jitter occurring in processing of the operating system, an OS jitter statistical information table defining an OS jitter level being a level of OS jitter, the OS jitter level being associated with the OS jitter statistical information…configured to acquire an input value of the application, a computational load table defining a computational load level being a level of a computational load of a processing block constituting the application, the computational load level being associated with the input value” are directed to mere data gathering activities which is a category of insignificant extra-solution activities (MPEP 2106.05(g)). The limitations "an information processing apparatus that executes an application, the information processing apparatus comprising: a computation apparatus including a plurality of processor cores; and an operating system to be executed in the computation apparatus, wherein the operating system includes an OS jitter statistical information acquisition unit", "an input value acquisition unit ", and “a bare metal necessity determination unit” apply judicial exceptions on a generic computer. "Alappat 's rationale that an otherwise ineligible algorithm or software could be made patent-eligible by merely adding a generic computer to the claim was superseded by the Supreme Court's Bilski and Alice Corp. decisions" so therefore applying judicial exceptions an information processing apparatus, an application, a plurality of processor cores, an operation system, an OS jitter statistical information acquisition unit, an input value acquisition unit, and a bare metal necessity determination unit which are generic computing components or software does not integrate the judicial exceptions into a practical application (MPEP 2106.05(b)). In step 2B of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not recite significantly more than the abstract ideas identified above for the following rationale: The limitations "configured to acquire OS jitter statistical information being statistical information of OS jitter occurring in processing of the operating system, an OS jitter statistical information table defining an OS jitter level being a level of OS jitter, the OS jitter level being associated with the OS jitter statistical information…configured to acquire an input value of the application, a computational load table defining a computational load level being a level of a computational load of a processing block constituting the application, the computational load level being associated with the input value” represent insignificant, extra-solution activities. The limitations "configured to acquire OS jitter statistical information being statistical information of OS jitter occurring in processing of the operating system, an OS jitter statistical information table defining an OS jitter level being a level of OS jitter, the OS jitter level being associated with the OS jitter statistical information…configured to acquire an input value of the application, a computational load table defining a computational load level being a level of a computational load of a processing block constituting the application, the computational load level being associated with the input value” are well-understood, routine, or conventional because they are directed to "receiving or transmitting data" or “storing and retrieving information in memory” (MPEP 2106.05(d)). These are additional elements that the courts have recognized as well understood, routine, or conventional (MPEP 2106.05(d)). The citation of court cases in the MPEP meets the Berkheimer evidentiary burden since citation of a court case in the MPEP is one of the 4 types of evidentiary support that can be used to prove that the additional elements are well-understood, routine, or conventional (see 125 USPQ2d 1649 Berkheimer v. HP, Inc.). Thus, the limitations do not amount to significantly more than the abstract idea. The limitations "an information processing apparatus that executes an application, the information processing apparatus comprising: a computation apparatus including a plurality of processor cores; and an operating system to be executed in the computation apparatus, wherein the operating system includes an OS jitter statistical information acquisition unit", "an input value acquisition unit ", and “a bare metal necessity determination unit” apply judicial exceptions on a generic computer and therefore do not provide significantly more. As per claim 2, it recites mental processes, generic computing components, mere instructions to apply the judicial exception, and insignificant extra solution activities that are well understood, routine, or conventional because they are directed to "receiving or transmitting data" or “storing and retrieving information in memory” (MPEP 2106.05(d)). Therefore, the additional elements fail to integrate the judicial exceptions into a practical application and fail to recite significantly more. As per claim 3, it recites generic computing components, mere instructions to apply the judicial exception, and insignificant extra solution activities that are well understood, routine, or conventional because they are directed to “storing and retrieving information in memory” (MPEP 2106.05(d)). Therefore, the additional elements fail to integrate the judicial exceptions into a practical application and fail to recite significantly more. As per claim 4, it recites a mental process, generic computing components, and insignificant extra solution activities that are well understood, routine, or conventional because they are directed to "receiving or transmitting data" (MPEP 2106.05(d)). Therefore, the additional elements fail to integrate the judicial exceptions into a practical application and fail to recite significantly more. As per claim 5, it recites mental processes, generic computing components, mere instructions to apply the judicial exception, and insignificant extra solution activities that are well understood, routine, or conventional because they are directed to "receiving or transmitting data" (MPEP 2106.05(d)). Therefore, the additional elements fail to integrate the judicial exceptions into a practical application and fail to recite significantly more. As per claim 6, it recites mental processes, generic computing components, and insignificant extra solution activities that are well understood, routine, or conventional because they are directed to "receiving or transmitting data" or “storing and retrieving information in memory” (MPEP 2106.05(d)). Therefore, the additional elements fail to integrate the judicial exceptions into a practical application and fail to recite significantly more. As per claim 7, it recites mental processes, generic computing components, and an insignificant extra solution activity that is well understood, routine, or conventional because it is directed to "receiving or transmitting data" (MPEP 2106.05(d)). Therefore, the additional elements fail to integrate the judicial exceptions into a practical application and fail to recite significantly more. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-4 and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Wassen (Suppressing Jitter by Isolating Bare-Metal Tasks within a General-Purpose OS on x86 NUMA Systems) in view of Belikovetsky et al. (US 20200057666 A1 hereinafter Belikovetsky) . As per claim 1, Wassen teaches the invention substantially as claimed including an information processing apparatus that executes an application, the information processing apparatus comprising (page 4 paragraph 2 This can be realized on a single x86 multi-processor system with various tasks from digital control up to command and control. This work targets complex time-sensitive applications that include multiple levels of the automation pyramid, for instance hard real-time tasks with a time-frame below 10 μs as well as multiple compute-intensive jobs.) : a computation apparatus including a plurality of processor cores (page 160 paragraph 2 In Fig. 7.2, a simplified multi-core processor is illustrated; page 29 paragraph 4 implement their x86 processors with RISC cores) ; and an operating system to be executed in the computation apparatus, wherein the operating system includes an OS jitter statistical information acquisition unit configured to acquire OS jitter statistical information being statistical information of OS jitter occurring in processing of the operating system (page 68 Listing 2.1; page 22 paragraph 3 The x86 processors support four privilege levels, but most GPOSs only use two of them; page 19 paragraph 3 General-Purpose Operating System (GPOS); page 54 paragraph 3 For the analysis of jitter sources, more sophisticated statistics or histograms are helpful; page 188 To support the evaluation of user-defined control functions, the isolated tasks generate a statistic of their execution times. This statistic must influence the execution times as little as possible. Therefore it is kept light-weight with regard to memory foot-print and calculation overhead. The simplest solution is the tracking of only maximum and minimum execution times, possibly adjoined with the average. A viable compromise of overhead and informative value is a histogram; page 54 paragraphs 1-2 The terms process and thread are defined in OSs as is task to be either of them (Section 2.2.1). The smallest entity of work (e. g. query a sensor, set an actor) is a job [Liu00], of which multiple can be in the responsibility of a task. An application is a collection of tasks that jointly serve a purpose (e. g. control a plant). The measurements latency and jitter were already defined (Section 2.1.8) as time between a stimulus and the triggered event and difference between minimum and maximum thereof, respectively…The jitter is a measure for the absolute variability, hence the difference of minimum and maximum latency; page 67 paragraph 6-page 68 paragraph 1 An important benchmark used repeatedly in this work is the Hourglass benchmark [Reg02]. It was introduced to analyze the time slices assigned by the operating-system to multiple processes. In this work, the concept was used to analyze gaps in the execution time caused mainly by interrupts. The example code in Listing 2.1 presents the basic principle. The minimum loop is short enough to detect a variance in the range of a few CPU cycles of the mean execution time…The function store_timestamp() must be implemented as efficiently as possible to avoid a measurable impact that would corrupt the results. The most simple implementation only records the minimum and maximum values (Listing 2.2). More meaningful is the collection of a histogram to understand the distribution of gaps; page 167 PNG media_image1.png 261 548 media_image1.png Greyscale ; page 6 paragraph 5 Unpredictable timing stems from macroscopic causes like scheduling, interrupts, operating system jitter; page 160 paragraph 1 an Hourglass benchmark was executed on a micro-kernel; page 43 paragraph 2 The architecture of an OS is divided into the classes monolithic and micro-kernel.), an OS jitter statistical information table defining an OS jitter level being a level of OS jitter, the OS jitter level being associated with the OS jitter statistical information (page 158 PNG media_image2.png 299 565 media_image2.png Greyscale ; page 157 paragraph 3 To practically evaluate the execution time jitter of a small task on an idle system, the following benchmark was executed on an isolated Central Processing Unit (CPU) of the test system haixagon; page 67 Table 2.6 PNG media_image3.png 133 361 media_image3.png Greyscale ; page 67 paragraph 6-page 68 paragraph 1 An important benchmark used repeatedly in this work is the Hourglass benchmark [Reg02]. It was introduced to analyze the time slices assigned by the operating-system to multiple processes. In this work, the concept was used to analyze gaps in the execution time caused mainly by interrupts. The example code in Listing 2.1 presents the basic principle. The minimum loop is short enough to detect a variance in the range of a few CPU cycles of the mean execution time…The function store_timestamp() must be implemented as efficiently as possible to avoid a measurable impact that would corrupt the results. The most simple implementation only records the minimum and maximum values (Listing 2.2). More meaningful is the collection of a histogram to understand the distribution of gaps. The impact of logging histogram data can be seen in Table 2.6.; page 54 paragraph 2 The jitter is a measure for the absolute variability, hence the difference of minimum and maximum latency; page 160 paragraph 1 an Hourglass benchmark was executed on a micro-kernel; page 43 paragraph 2 The architecture of an OS is divided into the classes monolithic and micro-kernel), an input value acquisition unit configured to acquire an input value of the application (page 55 paragraph 8 In signal processing, applications stream data with real-time constraints, e. g. for digital filtering, video and voice (de)compression, and radar signal processing; page 5 paragraph 1 Include compute-intensive jobs, e. g. the analysis of a video stream (soft realtime, but best-effort); page 103 paragraph 5 The load scenario consists of four CPU intensive processes, a memory intensive process using a 256 MiB array, two processes doing file I/O (with read/write and memory-mapping), and a heavily forking process to engage the Kernel; page 189 paragraph 5 Processor 4 accesses only the Input and can communicate with processor 3. It could serve as hard real-time input stream processing; page 190 paragraph 1 The hardware queues are realized as wait-free ring buffers in the IPC memory section. The tasks handling I/O can also provide the data via additional message queues or shared variables to the other tasks; page 66 paragraph 2 Benchmarking real-time applications, OSs, and hardware is difficult, and easily results in misdirections [DM04]. To obtain the WCET experimentally, the worst-case must be observed. The probability to provoke events causing the worst-case (or a delay close to it) increases if the test system is loaded with more work than realistically present in the final system [Fog13b, Sect. 16.2]. It is advisable to warm up the tested routine by executing some iterations before recording a statistic. This avoids including cache effects that will not be present in the running application. To create a more than realistic load, the following measures can be taken [Fog13b, Sect. 16.2]: Executing the whole application with all dynamic link libraries. If using the network or a server, loading them too. For files and databases, using large data-sets; page 175 paragraph 1 The system load was varied with different generators beginning with a memory transferring routine, a forking process and a timer signal benchmark loading the OS, and a file writing routine to generate I/O load.), a computational load table defining a computational load level being a level of a computational load of a processing block constituting the application, the computational load level being associated with the input value (page 108 PNG media_image4.png 334 603 media_image4.png Greyscale ; page 108 paragraph 2 a load with a varying memory access range is executed on another CPU; page 175 PNG media_image5.png 286 629 media_image5.png Greyscale page 146 paragraph 2 Memory-mapped I/O uses configuration registers mapped to the physical address space. A process with root privileges can map this address region into its virtual address space with the mmap() function. After this assignment has been installed, an application can access the device with common load and store instructions (e. g. MOV) or pointer assignment in the C programming language; page 67 paragraph 6-page 68 paragraph 1 An important benchmark used repeatedly in this work is the Hourglass benchmark [Reg02]. It was introduced to analyze the time slices assigned by the operating-system to multiple processes. In this work, the concept was used to analyze gaps in the execution time caused mainly by interrupts. The example code in Listing 2.1 presents the basic principle. The minimum loop is short enough to detect a variance in the range of a few CPU cycles of the mean execution time…The function store_timestamp() must be implemented as efficiently as possible to avoid a measurable impact that would corrupt the results. The most simple implementation only records the minimum and maximum values (Listing 2.2). More meaningful is the collection of a histogram to understand the distribution of gaps. The impact of logging histogram data can be seen in Table 2.6.; page 160 paragraph 1 an Hourglass benchmark was executed on a micro-kernel; page 43 paragraph 2 The architecture of an OS is divided into the classes monolithic and micro-kernel; page 175 paragraph 1 The system load was varied with different generators beginning with a memory transferring routine, a forking process and a timer signal benchmark loading the OS, and a file writing routine to generate I/O load) ; a bare metal necessity determination unit configured to determine whether or not the processing block needs to be executed in a bare metal environment in which the operating system is not executed, based on the OS jitter level and the computational load level (page 195 lines 5-7 it is shown how memory and I/O accesses can be regarded in the partition design to realize hard real-time tasks in isolated bare-metal tasks with minimum jitter and high predictability; page 9 paragraph 3 The concept of isolated CPUs executing bare-metal code addresses the macroscopic cause of jitter from OS and interrupts and proposes a method to execute tasks with a predictable timing; page 9 line 30-page 10 line 1 This work now presents detailed evaluation and advice how to realize bare-metal tasks with minimum hardware jitter; page 88 4.1 paragraph 3 The isolated process runs bare-metal on its processor, which means it is not under the control of the operating-system; page 8 paragraph 1 Interrupt handlers on current Linux systems interrupt the running task for 2 to 40 μs and even more with applied RT-Patch. If the hard real-time task requires less jitter than that, even a single interrupt will cause a violation of the timing; page 87 paragraph 1 The isolated task is executed bare-metal without operating system (OS) support. This concept can freely be adapted to the application’s requirements of timeliness and compute power; Page 2 paragraph 4 On such a multi-processor system, reserve a (or some) processor(s) for hard real-time work, leaving other processors fully usable for soft real-time and compute-intensive tasks to exploit the power of the Linux system (with all services and libraries). Wassen teaches a bare metal necessity determination unit, but fails to teach that the operating system includes a bare metal necessity determination unit. However, Belikovetsky teaches the operating system includes a bare metal necessity determination unit ([0025] where the hypervisor 114 operates as a kernel hypervisor with a LINUX kernel due to the operating system 112 being associated with a LINUX operating system, the hypervisor 114 can effectively convert the operating system 112 into a type-1 hypervisor that functions as a bare-metal hypervisor; [0025] the hypervisor 114 can be configured as a “type-1” native or bare-metal hypervisor that can control and/or run directly on the hardware resources of the host device 106 and can host virtual machines without an operating system operating). It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Wassen with the teachings of Belikovetsky so that applications can execute on an operating system or on bare metal (see Belikovetsky [0025] the hypervisor 114 can effectively convert the operating system 112 into a type-1 hypervisor that functions as a bare-metal hypervisor, while also still allowing for other applications to use the operating system 112). As per claim 2, Wassen and Belikovetsky teach the information processing apparatus according to claim 1. Wassen teaches wherein the operating system further includes a table setting I/F (page 112 paragraph 5 Further, the start and end of the real-time application (including the isolated tasks) should be monitored with time-stamps to match recorded events with the start, ongoing execution, or shutdown of isolated tasks. A viable solution to record the state of the real-time system is to monitor it from a second system via network. A shell script was used to connect to the system under test with Secure Shell (SSH) and record all required information together with its own wall clock time. It is advisable to process this massive amount of data automatically and create a report including graphics to quickly detect anomalies in the execution; page 163 paragraph 2 To investigate the effects of different memory ranges accessed from different settings, a small benchmark mimics two isolated tasks by placing them on dedicated CPUs and using the Interrupt Flag (IF) to avoid all other influences on the run-time; page 157 paragraph 3 To practically evaluate the execution time jitter of a small task on an idle system, the following benchmark was executed on an isolated Central Processing Unit (CPU) of the test system haixagon…The result for up to a million memory accesses shows a very low jitter of only 4 cycles (Table 7.1).) , a bare metal necessity determination table defining a bare metal execution condition being a condition necessary for executing the processing block in the bare metal environment using the OS jitter level and the computational load level (page 104 Table 4.1.; page 195 lines 5-7 it is shown how memory and I/O accesses can be regarded in the partition design to realize hard real-time tasks in isolated bare-metal tasks with minimum jitter and high predictability; page 8 paragraph 1 Interrupt handlers on current Linux systems interrupt the running task for 2 to 40 μs and even more with applied RT-Patch. If the hard real-time task requires less jitter than that, even a single interrupt will cause a violation of the timing; page 88 4.1 paragraph 3 The isolated process runs bare-metal on its processor, which means it is not under the control of the operating-system; page 2 paragraph 4 On such a multi-processor system, reserve a (or some) processor(s) for hard real-time work, leaving other processors fully usable for soft real-time and compute-intensive tasks to exploit the power of the Linux system (with all services and libraries); page 103 paragraph 5- page 104 paragraph 1 The idle system was running a graphical user interface, but left without further interaction. The load scenario consists of four CPU intensive processes, a memory intensive process using a 256 MiB array, two processes doing file I/O (with read/write and memory-mapping), and a heavily forking process to engage the Kernel. The benchmark was executed for 60 Minutes each with fair scheduling without further real-time programming measures, partitioning to execute solely on a CPU, and full isolation by additionally clearing the Interrupt Flag (Table 4.1).) , and a bare metal building unit configured to build the bare metal environment for one of the plurality of processor cores for which the bare metal environment is not built, the bare metal execution condition is set by a user via the table setting I/F (page 9 paragraph 2 this work examines how to partition a multi-processor system into a general-purpose partition and one or more hard real-time partitions (called bare-metal tasks) that are isolated from the OS; page 9 paragraph 4 The main contribution are several bare-metal tasks executed directly on dedicated processors so that they become isolated from the system partition and their performance is not influenced. They control their assigned devices and can communicate with other bare-metal tasks and applications in the system partition without use of the OS; page 97 paragraph 2 Since the isolated task are not allowed to use OS interfaces (system calls), all allocations and initializations must be done before the application enters its time critical part. The isolated tasks are separated into a setup phase and real-time execution; page 94 paragraph 5 Thus, configuring on which CPUs a task is allowed to run requires using an interface of the OS. Restricting the running processes to the CPUs of the system partition and moving processes or threads dedicated for isolation to their CPUs can be accomplished in Linux systems with the means of CPU Affinity or CPU-Sets; page 95 paragraph 5 Both interfaces can be accessed from the shell to set up the system in a script or from within the application. The shell interface for CPU-Sets is the previously described pseudo directory hierarchy described above. This can also be used from arbitrary programming languages by creating directories and writing to files. The CPU Affinity can be changed from the command line with help of the program taskset.) , and when the OS jitter level and the computational load level meet the bare metal execution condition, the bare metal necessity determination unit determines that the processing block needs to be executed in the bare metal environment (page 195 lines 5-7 it is shown how memory and I/O accesses can be regarded in the partition design to realize hard real-time tasks in isolated bare-metal tasks with minimum jitter and high predictability; page 8 paragraph 1 Interrupt handlers on current Linux systems interrupt the running task for 2 to 40 μs and even more with applied RT-Patch. If the hard real-time task requires less jitter than that, even a single interrupt will cause a violation of the timing; page 88 4.1 paragraph 3 The isolated process runs bare-metal on its processor, which means it is not under the control of the operating-system; page 2 paragraph 4 On such a multi-processor system, reserve a (or some) processor(s) for hard real-time work, leaving other processors fully usable for soft real-time and compute-intensive tasks to exploit the power of the Linux system (with all services and libraries)) . As per claim 3, Wassen and Belikovetsky teach the information processing apparatus according to claim 1. Wassen teaches wherein the operating system further includes a bare metal building unit configured to build the bare metal environment for one of the plurality of processor cores for which the bare metal environment is not built, and a bare metal building latency table storing an overhead time required for building of the bare metal environment (Page 186 Fig. 8.2; Page 185 paragraph 5 The timing diagram of the setup, warm-up, experiment and shut-down phases is shown in Fig. 8.2. When the application is started, it moves itself to the application partition, sets up itself and starts the Manager task. (1) After user interaction to start the experiment, the GUI notifies the Manager. (2) That creates the isolated threads successively and moves them to their partitions. They initialize themselves and then go into warm-up mode. The Manager starts also all other tasks. (3) When all is set up, the Manager activates the experiment phase and notifies the GUI that displays the new state to the user; page 93 paragraph 2 Having more than 10 processors in recent x86 systems allows to partition the system into some CPUs dedicated for the least latency while the remaining CPUs can build a partition that utilizes the included CPUs as usual at the cost of only the generally available soft real-time latencies. The System Partition (Fig. 4.2) comprehends one or multiple processors and executes the basic system services (called remaining system in the context of this work). An optional soft real-time partition can include additional CPUs for prioritized work. The isolated partitions include always a single CPU and will execute a single process or thread; page 93 paragraph 2 Having more than 10 processors in recent x86 systems allows to partition the system into some CPUs dedicated for the least latency while the remaining CPUs can build a partition that utilizes the included CPUs as usual at the cost of only the generally available soft real-time latencies; page 94 paragraph 5 Thus, configuring on which CPUs a task is allowed to run requires using an interface of the OS. Restricting the running processes to the CPUs of the system partition and moving processes or threads dedicated for isolation to their CPUs can be accomplished in Linux systems with the means of CPU Affinity or CPU-Sets.) , and when the overhead time is before start time of the processing block, the bare metal building unit builds the bare metal environment, based on the overhead time (Page 186 Fig. 8.2; Page 185 paragraph 5 The timing diagram of the setup, warm-up, experiment and shut-down phases is shown in Fig. 8.2. When the application is started, it moves itself to the application partition, sets up itself and starts the Manager task. (1) After user interaction to start the experiment, the GUI notifies the Manager. (2) That creates the isolated threads successively and moves them to their partitions. They initialize themselves and then go into warm-up mode. The Manager starts also all other tasks. (3) When all is set up, the Manager activates the experiment phase and notifies the GUI that displays the new state to the user; page 97 paragraph 2 Since the isolated task are not allowed to use OS interfaces (system calls), all allocations and initializations must be done before the application enters its time critical part. The isolated tasks are separated into a setup phase and real-time execution.) . As per claim 4, Wassen and Belikovetsky teach the information processing apparatus according to claim 1. Wassen teaches further comprising a computation application generation unit configured to generate executable binary data for an operating system environment that is executable in the operating system environment in which the operating system is executed and executable binary data for the bare metal environment that is executable in the bare metal environment, based on a computation application body code being a body code of the application and a function table (page 118 Fig. 5.2; page 119 Table 5.2; page 42 paragraph 5 General-Purpose Operating Systems (GPOSs) are known from PCs: They are installed on a persistent storage (e. g. a hard disk); page 42 paragraph 6 A GPOS is usually installed on the bare hardware, and consists of the kernel, libraries and tools. The kernel is the supervisor running with highest privileges. Libraries are collections of functions that can be used by programs. Tools are programs accompanying the OS to provide essential services, for instance compile code to object files (Assembler, Compiler), handle object and executable files (Linker), load a program to execute (Loader); page 117 paragraph 4 The implementation of the x86 architecture branch of Linux 3.12 is displayed in Fig. 5.2. The apic structure in apic.h2 contains pointers to low-level sending functions; page 119 paragraph 1 The lowest-level functions in Fig. 5.2 use physical localAPIC IDs that can not easily be converted back to the CPU IDs used by the isolation bit mask. Therefore, the Patch modifies the three functions of the level above (marked “low level” in Table 5.2). These three functions block sending IPIs to the isolated CPUs on the lowest level. Even the Non-Maskable Inter-Processor Interrupt (NM-IPI) used for debugging Kernel problems is prevented from being asserted to an isolated CPU; Page 10 paragraph 2 Isolated bare-metal tasks are UNIX processes (or threads) executed in userspace; Page 57 paragraph 3 The possible implementations range from single-processor μC running only the application without OS (i. e. bare-metal); page 4 paragraph 2 This can be realized on a single x86 multi-processor system with various tasks from digital control up to command and control. This work targets complex time-sensitive applications that include multiple levels of the automation pyramid, for instance hard real-time tasks with a time-frame below 10 μs as well as multiple compute-intensive jobs; A kernel is executable binary data. UNIX processes executed in userspace are executable binary data. ) , wherein a starting notification or a completion notification is transmitted and received between the processing blocks being included in the executable binary data for the operating system environment and the executable binary data for the bare metal environment and having dependence on each other (page 142 paragraph 2 The manager then notifies all isolated tasks in a short timespan to enter their real-time state and start working; page 185 paragraph 5 The isolated tasks and calculation threads are notified to terminate; page 109 paragraph 3 The Kernel may restore the Interrupt Flag implicitly after returning to the user-mode. This would involuntarily terminate the isolated state of the task; page 111 paragraph 2 The sender can not notice the masking of its IPI but will wait for the acknowledge by spinning on the flag until the masking of interrupts is undone. This will not happen until the bare-metal task terminates its isolated state; page 51 paragraph 1 The OS handles remaining processes by moving them to other CPUs and shuts down the processor; page 124 paragraph 2 The procedure of activating the isolation is in large parts imitating the Hotplugging system. Consequently, an alternative method to unregister isolated CPUs from the Kernel would be in fact switching it off with the Hotplugging system. To execute the isolated real-time task, the halted processor could be waked up again without using the functions of the Linux kernel. This would result in a CPU that executes some code but without the Kernel registering this CPU as available. The waking-up of a shut-off CPU; Page 10 paragraph 2 Isolated bare-metal tasks are UNIX processes (or threads) executed in userspace;) . As per claim 6, Wassen and Belikovetsky teach the information processing apparatus according to claim 2. Wassen teaches wherein the computation apparatus further includes cache memory (page 17 paragraph 2 Current x86 processors include up to three levels of caches named from L1 (near to the processor, very fast, in the range of 32 to 64 KiB) to L3 (far, slower, 8 to 16 MiB).) , the operating system further includes a cache statistical information acquisition unit configured to acquire cache statistical information being statistical information related to the cache memory, and a cache statistical information table defining a cache performance level being a level of cache performance, the cache performance level being associated with the cache statistical information (page 108 PNG media_image4.png 334 603 media_image4.png Greyscale ; page 108 paragraph 2 The results (Table 4.2) of Write-Back caching clearly show, that a load using less than 2 MiB of the shared Last-Level Cache has no impact on the benchmark. However, if the range of the load increases above half of the Last-Level Cache size, the benchmark experiences occasional gaps above 1000 cycles similar to the previous test series with an isolated task on a Linux system; page 159 PNG media_image6.png 371 260 media_image6.png Greyscale ; page 160 paragraph 1 This experiment was executed on the test system x axis (Appendix A.2.1) with an Intel Nehalem QuadCore processor with a single shared Third Level Cache (L3$). The results (Table 7.2) indicate in fact an influence of a load that uses a fair amount of the shared Last-Level Cache onto the private cache of a different processor. Minimum and average do not depend on the load, and are very close together which indicates that the maximum values are detected only rarely. The occasional outliers cause a steep increase of the maximum execution time if the load uses a large portion of the 8 MiB shared Last-Level Cache.) , in the bare metal necessity determination table, the bare metal execution condition is defined using the OS jitter level, the computational load level, and the cache performance, and when the OS jitter level, the computational load level, and the cache performance level meet the bare metal execution condition, the bare metal necessity determination unit determines that the processing block needs to be executed in the bare metal environment. (page 104 Table 4.1.; page 195 lines 5-7 it is shown how memory and I/O accesses can be regarded in the partition design to realize hard real-time tasks in isolated bare-metal tasks with minimum jitter and high predictability; page 8 paragraph 1 Interrupt handlers on current Linux systems interrupt the running task for 2 to 40 μs and even more with applied RT-Patch. If the hard real-time task requires less jitter than that, even a single interrupt will cause a violation of the timing; page 2 paragraph 4 On such a multi-processor system, reserve a (or some) processor(s) for hard real-time work, leaving other processors fully usable for soft real-time and compute-intensive tasks to exploit the power of the Linux system (with all services and libraries); page 162 paragraph 1 A hard real-time task executes with the lowest latency and jitter if it uses as few memory accesses as possible, hence if it may keep most of its working data-set in its private caches. Since sharing the Last-Level Cache with other processes will increase its jitter especially when using inclusive caches, the other processors should be employed carefully. The requirement of having compute-intensive tasks leads to the use of multi-socket systems with multiple Last-Level Cache that are investigated in the following Section; page 157 The test routine repeatedly accessed variables in a buffer of 4 KiB size. Both code and data are small enough to fit in the First Level Cache (L1$). Before the measurement, some warm-up iterations were executed to load all required cache lines and train the branch-predictors [CP00]. The result for up to a million memory accesses shows a very low jitter of only 4 cycles (Table 7.1). This demonstrates, that the x86 architecture is in fact capable for hard real-time execution with low jitter if the influences of other processors on the caches can be ruled out.). As per claim 7, Wassen and Belikovetsky teach the information processing apparatus according to claim 1. Wassen teaches wherein the operating system further includes a computational load learning unit configured to learn the computational load of the processing block with respect to the input value acquired by the input value acquisition unit and generate a computational load model (page 39 paragraph 4 But for the evaluation of applications, an exact model of their working is required; page 39 paragraph 5 Several collections of application benchmarks for the single-processor performance are available that measure typical algorithms; page 40 paragraph 3 there exist specialized benchmarks to evaluate the power usage or graphics processing performance; page 175 paragraph 1 The system load was varied with different generators beginning with a memory transferring routine, a forking process and a timer signal benchmark loading the OS, and a file writing routine to generate I/O load; page 156 paragraph 2 the system load can also be modeled according to the real application) , and a computational load estimation unit configured to estimate the computational load of the processing block, based on the input value acquired by the input value acquisition unit and the computational load model (page 156 paragraph 2 the system load can also be modeled according to the real application; page 175 paragraph 1 The system load was varied with different generators beginning with a memory transferring routine, a forking process and a timer signal benchmark loading the OS, and a file writing routine to generate I/O load) . 07-21-aia AIA Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Wassen and Belikovetsky, as applied to claim 4 above, in view of Pöppe et al. (US 20210025938 A1 hereinafter Pöppe) . As per claim 5, Wassen and Belikovetsky teach the information processing apparatus according to claim 4. Wassen teaches further comprising: a main storage apparatus (page 42 paragraph 5 a persistent storage (e. g. a hard disk)) ; a bare metal loader unit configured to deploy the executable binary data for the bare metal environment in a predetermined virtual address of the main storage apparatus (page 97 paragraph 5-page 98 paragraph 1 for the setup of isolated tasks, a means of synchronization is required. This method must work without relying on the OS after its initialization. Shared memory is suited as it is a hardware feature which works by referencing the same physical memory page from the virtual address space of different processes. Threads of the same process can share global variables naturally. For different processes, the UNIX standards System V and POSIX provide their variant of shared memory; page 95 paragraphs 2-3 The interface is a virtual filesystem mounted at /cpusets/ or /sys/fs/cgroup/cpuset/5. New sets can be generated by creating a directory. The configuration is handled by writing to the virtual files within the set directories. Each CPU-Set can be assigned CPUs by writing to cpuset.cpus. Then, processes and threads can be moved to a CPU-Set by writing their TIDs (Task-IDs) to the file cpuset.procs. For a process with multiple threads, the threads can be assigned to different CPU-Sets. Child processes and threads created by tasks in a CPU-Sets remain in their parent’s set. The list of tasks in a set can be checked by reading cpuset.procs. For the isolation concept, multiple CPU-Sets are created, one for each partition. The sets for isolated tasks each contain only a single CPU to run on. At least one system partition containing CPU #0 must be created. All running processes must be moved to that CPU-Set; page 87 paragraph 1 The isolated task is executed bare-metal without operating system (OS) support.) , a bare metal cooperation unit configured to perform control so that the processing block is not to be executed in the operating system based on the starting notification transmitted from the executable binary data for the operating system environment to the executable binary data for the bare metal environment (page 142 paragraph 2 The manager then notifies all isolated tasks in a short timespan to enter their real-time state and start working; page 57 paragraph 3 The possible implementations range from single-processor μC running only the application without OS (i. e. bare-metal); page 124 paragraph 2 The procedure of activating the isolation is in large parts imitating the Hotplugging system. Consequently, an alternative method to unregister isolated CPUs from the Kernel would be in fact switching it off with the Hotplugging system. To execute the isolated real-time task, the halted processor could be waked up again without using the functions of the Linux kernel. This would result in a CPU that executes some code but without the Kernel registering this CPU as available. The waking-up of a shut-off CPU; Page 10 paragraph 2 Isolated bare-metal tasks are UNIX processes (or threads) executed in userspace; page 94 paragraph 5 Processes and threads (or generalized “tasks”) are a concept of the operating system and managed in its data structures. Thus, configuring on which CPUs a task is allowed to run requires using an interface of the OS. Restricting the running processes to the CPUs of the system partition and moving processes or threads dedicated for isolation to their CPUs can be accomplished in Linux systems with the means of CPU Affinity or CPU-Sets.) , and perform control so that a processing block to be executed after the processing block is to be executed in the operating system, based on the completion notification transmitted from the executable binary data for the bare metal environment to the executable binary data for the operating system environment (page 99 paragraph 4 The basic structure of an isolated task is an initialization phase before the activation of the full isolation and an endless loop repeating its work until notified to exit. In the initialization, the task is moved to its CPU and initializes its memory (locking and pre-faulting). The transition to the hard real-time execution can be managed by a task of the application using shared flags; page 99 paragraph 7 When notified to terminate the real-time execution phase, the loop is left and all resources should be gracefully returned; page 125 paragraph 2 To revert the state of a CPU executing without being registered by the Linux kernel, the isolated task must shut down the CPU to a halted state. Then, Linux can re-initialize the CPU with the Hotplugging system; page 140 paragraph 4 all isolated tasks must be started, initialized, and isolated in lockstep. Similarly, they must be shut down in a synchronized fashion; page 145 paragraph 3 Since the isolation concept executes tasks that can not simply be terminated by the OS, these signals must be handled to initiate an emergency shutdown and keep the system responsive.) . Wassen and Belikovetsky fail to teach set an entry point of the processing block as an execution target included in the executable binary data for the bare metal environment to a program counter of one of the plurality of processor cores in the bare metal environment. However, Pöppe teaches set an entry point of the processing block as an execution target included in the executable binary data for the bare metal environment to a program counter of one of the plurality of processor cores in the bare metal environment ([0256] the on-chip-system test controller may also instruct the CPU core to execute the bare metal program which has been stored into the SRAM, for example, by setting a program counter of the CPU core to an appropriate memory address of the SRAM). It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Wassen and Belikovetsky with the teachings of Pöppe to produce better results (see Pöppe [0256-0257] Moreover, the on-chip-system test controller may also instruct the CPU core to execute the bare metal program which has been stored into the SRAM, for example, by setting a program counter of the CPU core to an appropriate memory address of the SRAM via the debug port. Such a concept may be advantageous because the possibly non-deterministic behavior of the operating system, which may not be well-documented, is avoided. Rather, a bare metal program is provided, which may be understood in more detail by the software engineer, and which may therefore provide better- reproducible test results in some cases. Also, the usage of a bare metal program may have the advantage that the program is more “slim” such that the usage of external DRAM may not be necessary.). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-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, Aimee Li can be reached at (571) 272-4169. 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. /H.L./ Examiner, Art Unit 2195 /Aimee Li/Supervisory Patent Examiner, Art Unit 2195 Application/Control Number: 18/290,916 Page 2 Art Unit: 2195 Application/Control Number: 18/290,916 Page 3 Art Unit: 2195 Application/Control Number: 18/290,916 Page 4 Art Unit: 2195 Application/Control Number: 18/290,916 Page 5 Art Unit: 2195 Application/Control Number: 18/290,916 Page 6 Art Unit: 2195 Application/Control Number: 18/290,916 Page 7 Art Unit: 2195 Application/Control Number: 18/290,916 Page 8 Art Unit: 2195 Application/Control Number: 18/290,916 Page 9 Art Unit: 2195 Application/Control Number: 18/290,916 Page 10 Art Unit: 2195 Application/Control Number: 18/290,916 Page 11 Art Unit: 2195 Application/Control Number: 18/290,916 Page 12 Art Unit: 2195 Application/Control Number: 18/290,916 Page 13 Art Unit: 2195 Application/Control Number: 18/290,916 Page 14 Art Unit: 2195 Application/Control Number: 18/290,916 Page 15 Art Unit: 2195 Application/Control Number: 18/290,916 Page 16 Art Unit: 2195 Application/Control Number: 18/290,916 Page 17 Art Unit: 2195 Application/Control Number: 18/290,916 Page 18 Art Unit: 2195 Application/Control Number: 18/290,916 Page 19 Art Unit: 2195 Application/Control Number: 18/290,916 Page 20 Art Unit: 2195 Application/Control Number: 18/290,916 Page 21 Art Unit: 2195 Application/Control Number: 18/290,916 Page 22 Art Unit: 2195 Application/Control Number: 18/290,916 Page 23 Art Unit: 2195 Application/Control Number: 18/290,916 Page 24 Art Unit: 2195 Application/Control Number: 18/290,916 Page 26 Art Unit: 2195 Application/Control Number: 18/290,916 Page 27 Art Unit: 2195 Application/Control Number: 18/290,916 Page 28 Art Unit: 2195 Application/Control Number: 18/290,916 Page 29 Art Unit: 2195 Application/Control Number: 18/290,916 Page 30 Art Unit: 2195 Application/Control Number: 18/290,916 Page 31 Art Unit: 2195
Prosecution Insights