DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed on 3/26/2026 has been entered. Claims 1-20 remain pending in this application. The amendment to claim 1 has overcome the 35 U.S.C. 112(b) rejection previously set forth in the Non-Final Office Action. Therefore, Examiner withdraws the 35 U.S.C. 112(b) rejection of claims 1-8.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3 and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (US Pub. No. 2023/0020191 A1 hereinafter Kim) in view of Gunter et al. (US Pub. No. 2022/0326988 A1 hereinafter Gunter) in view of Paltashev et al. (US Pub. No. 2010/0110083 A1 hereinafter Paltashev) in view of Franke et al. (US Pub. No. 2016/0147710 A1 hereinafter Franke) in view of Mitsutani (US Pub. No. 2022/0144288 A1).
As per claim 1, Kim teaches a method comprising: loading a plurality of execution schedules upon initialization of a runtime system that includes a plurality of compute engines (¶ [0040]-[0041], “Referring to FIG. 1, an SoC 100 includes four central processing units (hereinafter, collectively referred to as ‘CPU’) 101, 103, 105, and 107. The SoC 100 includes a CPU_1 101, a CPU_2 103, a CPU_3 105, and a CPU_4 107. At this time, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 are CPUs of different types and execute respective software programs performing independent tasks.”), wherein: the plurality of execution schedules includes a first execution schedule and a second execution schedule (¶ [0047], “As such, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 execute software programs independent of each other. Therefore, for example, the software program of the CPU_1 101 can use all four core processors. Specifically, when the software program of the CPU_1 101 is the system OS, the CPU_1 101 can occupy all four core processors, thereby improving a performance of the whole SoC 100.”); the first execution schedule includes a first set of commands executed by one or more first compute engines of the plurality of compute engines, of a first plurality of runnables corresponding to a first computing application (¶ [0042]-[0044], “Here, the CPU_1 101 can execute a system operating system (OS). The system OS executes general-purpose tasks including interaction with a user, and may be, for example, an Android OS. The CPU_2 103 can execute a software program that processes a special task requiring fast processing without user interaction. For example, the CPU_2 103 may execute a Linux kernel. The CPU_3 105 can execute a software program that processes a task requiring real-time processing. For example, the CPU_3 105 may execute a real time operating system (RTOS).”); the second execution schedule includes a second set of commands executed by one or more second compute engines of the plurality of compute engines, of a second plurality of runnables corresponding to a second computing application (¶ [0042]-[0044], “Here, the CPU_1 101 can execute a system operating system (OS). The system OS executes general-purpose tasks including interaction with a user, and may be, for example, an Android OS. The CPU_2 103 can execute a software program that processes a special task requiring fast processing without user interaction. For example, the CPU_2 103 may execute a Linux kernel. The CPU_3 105 can execute a software program that processes a task requiring real-time processing. For example, the CPU_3 105 may execute a real time operating system (RTOS).”), wherein the one or more first compute engines and the one or more second compute engines have at least one device in common (¶ [0048], “The CPU_1 101 and CPU_2 103 are connected to a synchronous dynamic random access memory (SDRAM) 111, a dedicated device 113, and a plurality of shared devices 115 via a bus 109. Here, the dedicated device 113 and the plurality of shared devices 115 may include a universal asynchronous receiver/transmitter (UART), an inter-integrated circuit (I2C), a GPSB, an embedded multi-media card (eMMC), and the like.” ¶ [0072], “Four heterogeneous CPUs 101, 103, 105, and 107 on an SoC 100 operate independent software programs and perform tasks of different purposes, respectively. As described above, each of the CPUs 101, 103, 105, and 107 owns its own physical resource, and shares and uses the resource with other CPUs 101, 103, 105, and 107.”); executing the first execution schedule, as previously loaded, using the one or more first compute engines (¶ [0042], “Here, the CPU_1 101 can execute a system operating system (OS). The system OS executes general-purpose tasks including interaction with a user, and may be, for example, an Android OS.” ¶ [0072], “Four heterogeneous CPUs 101, 103, 105, and 107 on an SoC 100 operate independent software programs and perform tasks of different purposes, respectively. As described above, each of the CPUs 101, 103, 105, and 107 owns its own physical resource, and shares and uses the resource with other CPUs 101, 103, 105, and 107.”), and prior to completion of the execution of the first execution schedule, initiating execution of the second execution schedule, as previously loaded, by the one or more second compute engines (¶ [0081], “As such, the four heterogeneous CPUs 101, 103, 105, and 107 operate in parallel at the time point of power-on. The heterogeneous CPUs 101, 103, 105, and 107 are driven successively in an order of CPU_3 105.fwdarw.CPU_1 101.fwdarw.CPU_2 103.fwdarw.CPU_4 107, and then independently execute respective software programs.”).
Kim fails to teach the execution schedules being deterministic.
However, Gunter teaches the plurality of execution schedules were previously determined prior to initialization of the runtime system and are deterministic (¶ [0054], “The individualized operation schedules 18 may be particularly useful for applications that are computationally intense, highly repetitive, or both, such as neural network and graphic processing computations. For example, the use of explicitly defined schedules for individual hardware blocks 12 on a chip 10 can be conducive to deterministic operations in which scheduled operations are each executed in a predefined number of clock cycles.”).
Kim and Gunter are considered to be analogous to the claimed invention because they are in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kim with the schedule generation functionality of Gunter to arrive at the claimed invention. The motivation to modify Kim with the teachings of Gunter is that having knowledge of the exact execution schedule prior to processing the execution schedule allows the system to optimize how it handles the processing of the execution schedule (See Gunter para. 0035-0037.).
Kim and Gunter fail to explicitly teach the execution schedules including commands that dictate timing and order of execution.
However, Paltashev teaches the first execution schedule includes a first set of commands dictating timing and order of execution and the second execution schedule includes a second set of commands dictating timing and order of execution (¶ [0110]-[0112], “Semaphore P and semaphore V are metacommands that can be configured to provide a capability to manage context execution on software events versus astronomical time in case of time slice counter based management. Both the CPU and the GPU can send these metacommands to the context and manage execution and/or suspension of the context.” Examiner Note: There are a number of metacommands that control the order and timing of execution of the processes during processing.).
Kim, Gunter, and Paltashev are all considered to be analogous to the claimed invention because they are in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kim and Gunter with the timing and order commands of Paltashev to arrive at the claimed invention. The motivation to modify Kim and Gunter with the teachings of Paltashev is that it becomes easier to control and/or manipulate the execution schedules through the use of timing and order commands (See Paltashev para. 0110.).
Paltashev also teaches the plurality of compute engines include at least two compute engines of different types (¶ [0049], “More specifically, the nonlimiting example of FIG. 2 illustrates a multiprocessor system that includes a master CPU with one or more slave CPUs connected with a plurality of GPUs. More specifically, in the nonlimiting example of FIG. 2, master CPU 202 is coupled to local memory 204, as well as bus 206. Slave CPU 208 is also coupled to bus 106, as well as local memory 210.”).
Although Kim, Gunter, and Paltashev teach the one or more first compute engines and the one or more second compute engines having at least one device in common, they fail to teach that the device is a compute engine.
Accordingly, Franke teaches a known configuration wherein compute engines having at least one compute engine in common (¶ [0070], “Processors 104 may transmit resource requests to shared devices. The shared devices may comprise a plurality of resources and may respond to such resource requests. For example, a shared device may comprise process accelerators such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGA), graphics processing units (GPUs), digital signal processors (DSPs), etc.”).
Kim, Gunter, Paltashev, and Franke are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kim, Gunter, and Paltashev with Franke to show that a shared device can include a compute engine.
Kim, Gunter, Paltashev, and Franke fail to teach the execution schedules corresponding to modalities of a machine and that switching execution schedules is in response to the machine switching modalities.
However, Mitsutani teaches the first execution schedule corresponds to a first modality of a machine and the second execution schedule corresponds to a second modality of the machine (¶ [0039]-[0040], “An information processing device of the present disclosure provides functions of a control platform by a vehicle integrated electronic control unit (ECU) (central ECU) alone, an external cloud alone, or a combination of the vehicle integrated ECU and the external cloud. The control platform operates as a central brain configured to control overall operation and behavior of a vehicle…The information processing device 20 includes a command library 21, a mobility system controller 22, an information sharing portal 23, and an integrated manager 24. The vehicle control system may be mounted on a vehicle such as an automobile.” ¶ [0043]-[0045], “In other words, the command library 21 converts a request received from the service application 10 into a request for the integrated manager 24 or the mobility system controller 22. For example, the command library 21 includes a library of various commands for implementing the following functions in association. (1) Function of implementing a single or complex operation command for the vehicle device 30 (such as an actuator). This operation command is a command for fulfilling a request received from the service application 10. (2) Function of outputting (issuing) a switching trigger for a vehicle control mode. The vehicle control mode defines behavior of the vehicle (usage of the vehicle as a product).” ¶ [0051]-[0052], “For example, the command library 21 outputs a trigger for an instruction to switch the vehicle control mode, transmits an operation schedule, and reports scheduling to the mobility system controller 22. The command library 21 outputs a control request or a service request to the integrated manager 24. The command library 21 receives various service requests from the service application 10. The command library 21 can provide the information sharing portal 23 with application modification information to be open to the public. The command library 21 refers to shared information open to the public at the information sharing portal 23. The command library 21 can exchange information with the plant library 40. The mobility system controller 22 is a functional block (determiner and status transitioner) configured to, for example, centrally manage a control condition related to behavior of the vehicle (usage or operation), manage progress of a series of tasks based on an operation schedule, and manage schedules.”). Mitsutani also teaches in response to the machine switching from the first modality to the second modality, initiating execution of the second execution schedule (¶ [0051]-[0052], “For example, the command library 21 outputs a trigger for an instruction to switch the vehicle control mode, transmits an operation schedule, and reports scheduling to the mobility system controller 22. The command library 21 outputs a control request or a service request to the integrated manager 24. The command library 21 receives various service requests from the service application 10. The command library 21 can provide the information sharing portal 23 with application modification information to be open to the public. The command library 21 refers to shared information open to the public at the information sharing portal 23. The command library 21 can exchange information with the plant library 40. The mobility system controller 22 is a functional block (determiner and status transitioner) configured to, for example, centrally manage a control condition related to behavior of the vehicle (usage or operation), manage progress of a series of tasks based on an operation schedule, and manage schedules.” ¶ [0054]-[0060], “The mobility system controller 22 manages overall control on the vehicle by using the following elements (plurality of modes and states). The mobility system controller 22 controls components of the vehicle device 30 and behavior of the system, and adjusts UX requests depending on situations of the vehicle (time, place, and occasion: TPO).
States: manage transition of vehicle statuses along with sequential control phases.
<traveling state/motion state/transportation state/electric power infrastructure cooperation state>
Sub-modes: limit purposes and means of control under one or more modes.
<driving sub-mode/charging sub-mode/equipment power supply sub-mode/auxiliary-device supplementation sub-mode/AC power supply sub-mode>” See also para. 0067.).
Kim, Gunter, Paltashev, Franke, and Mitsutani are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the method of switching execution schedules of Kim, Gunter, Paltashev, and Franke to be in response to a modality switch of a machine as taught by Mitsutani to arrive at the claimed invention. The motivation to modify Kim, Gunter, Paltashev, and Franke with the teachings of Mitsutani is that correctly switching execution schedules that corresponds to various modalities of a machine ensures appropriate control of the machine and avoids causing inconsistencies among the various operations associated with the various modalities of the machine (See Mitsutani para. 0039.).
As per claim 2, Kim, Gunter, Paltashev, Franke, and Mitsutani teach the method of claim 1. Gunter teaches wherein at least one runnable of the first plurality of runnables is included in the second plurality of runnables (¶ [0047], “For example, operations of a first schedule for a first hardware block are coordinated with operations of a second schedule for a second hardware block such that an operation in the first schedule for the first hardware block to send data to the second hardware block is timed to correspond with operations in the second schedule that requires the second hardware block to read the data from an input buffer and operate on the data. In other words, operations of the individual schedules are coordinated such that data transfers between hardware blocks can be performed independent of traditional flow control logic.”).
Refer to claim 1 for reason to combine.
As per claim 3, Kim, Gunter, Paltashev, Franke, and Mitsutani teach the method of claim 1. Kim teaches wherein at least a portion of the first execution schedule continues to be executed after the initiating of execution of the second execution schedule (¶ [0081], “As such, the four heterogeneous CPUs 101, 103, 105, and 107 operate in parallel at the time point of power-on. The heterogeneous CPUs 101, 103, 105, and 107 are driven successively in an order of CPU_3 105.fwdarw.CPU_1 101.fwdarw.CPU_2 103.fwdarw.CPU_4 107, and then independently execute respective software programs.”).
As per claim 6, Kim, Gunter, Paltashev, Franke, and Mitsutani teach the method of claim 1. Kim teaches wherein an initialization process corresponding to the second execution schedule is performed prior to execution of the first execution schedule (¶ [0040]-[0041], “Referring to FIG. 1, an SoC 100 includes four central processing units (hereinafter, collectively referred to as ‘CPU’) 101, 103, 105, and 107. The SoC 100 includes a CPU_1 101, a CPU_2 103, a CPU_3 105, and a CPU_4 107. At this time, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 are CPUs of different types and execute respective software programs performing independent tasks.”).
As per claim 7, Kim, Gunter, Paltashev, Franke, and Mitsutani teach the method of claim 1. Kim teaches wherein a third execution schedule that is executed using at least one compute engine of the plurality of compute engines during the execution of the first execution schedule continues after the initiating of the execution of the second execution schedule (¶ [0041]-[0044], “The SoC 100 includes a CPU_1 101, a CPU_2 103, a CPU_3 105, and a CPU_4 107. At this time, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 are CPUs of different types and execute respective software programs performing independent tasks. Here, the CPU_1 101 can execute a system operating system (OS). The system OS executes general-purpose tasks including interaction with a user, and may be, for example, an Android OS. The CPU_2 103 can execute a software program that processes a special task requiring fast processing without user interaction. For example, the CPU_2 103 may execute a Linux kernel. The CPU_3 105 can execute a software program that processes a task requiring real-time processing. For example, the CPU_3 105 may execute a real time operating system (RTOS).”).
Claim(s) 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Kim, Gunter, Paltashev, Franke, and Mitsutani as applied to claim 1 above, and further in view of Aoyama (US Patent No. 10,162,675 B2).
As per claim 4, Kim, Gunter, Paltashev, Franke, and Mitsutani teach the method of claim. Kim teaches the first execution schedule and the second execution schedule (¶ [0047], “As such, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 execute software programs independent of each other. Therefore, for example, the software program of the CPU_1 101 can use all four core processors. Specifically, when the software program of the CPU_1 101 is the system OS, the CPU_1 101 can occupy all four core processors, thereby improving a performance of the whole SoC 100.”).
Kim, Gunter, Paltashev, Franke, and Mitsutani fail to teach the first execution schedule being completely terminated prior to completion and prior to execution of the second schedule beginning.
However, Aoyama teaches wherein the execution of the first execution schedule is completely terminated prior to completion of the first execution schedule and prior to the execution of the second execution schedule beginning (Col. 9, lines 27-50, “Meanwhile, the main processor process scheduler 12 may simultaneously receive, from the coprocessor process scheduler 14, status notification information showing that a process has transitioned to the standby state and status notification information showing that a process has been dispatched. Subsequently, the main processor process scheduler 12 refers to the status information 1251 of the process structure 125. Thus, the main processor process scheduler 12 checks whether or not a process on the main processor node 1 associated with the process switched by the coprocessor process scheduler 14 is in the waiting state (step S202). In a case where the associated process is not in the waiting state (step S202, no), the main processor process scheduler 12 ends the processing.”).
Kim, Gunter, Paltashev, Franke, Mitsutani, and Aoyama are considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kim, Gunter, Paltashev, Franke, and Mitsutani with the known technique of task preemption of Aoyama to arrive at the claimed invention. This modification would have been reasonable under MPEP § 2143 as Aoyama teaches task execution preemption and switching.
As per claim 5, Kim, Gunter, Paltashev, Franke, and Mitsutani teach the method of claim 1. Kim teaches the first execution schedule and the second execution schedule (¶ [0047], “As such, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 execute software programs independent of each other. Therefore, for example, the software program of the CPU_1 101 can use all four core processors. Specifically, when the software program of the CPU_1 101 is the system OS, the CPU_1 101 can occupy all four core processors, thereby improving a performance of the whole SoC 100.”).
Kim, Gunter, Paltashev, Franke, and Mitsutani fail to teach an initialization process for initiating execution of the second execution schedule.
However, Aoyama teaches wherein an initialization process corresponding to the second execution schedule begins in response to an instruction, corresponding to the initiating of execution of the second execution schedule, for termination of at least a portion of the first execution schedule (Col. 8, lines 16-30, “After that, by using the status notification means 13, the main processor process scheduler 12 notifies status notification information showing that the process has transitioned to the standby state and status notification information
showing that a process has been dispatched, to the other process scheduler 14 (the
coprocessor process scheduler 14) (step S103).”).
Refer to claim 4 for reason to combine.
Claim(s) 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kim, Gunter, Paltashev, Franke, and Mitsutani as applied to claim 1 above, and further in view of Herbert et al. (US Patent No. 10,235,207 B2 hereinafter Herbert).
As per claim 8, Kim, Gunter, Paltashev, Franke, and Mitsutani teach the method of claim 1. Kim teaches the first execution schedule and the second execution schedule (¶ [0047], “As such, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 execute software programs independent of each other. Therefore, for example, the software program of the CPU_1 101 can use all four core processors. Specifically, when the software program of the CPU_1 101 is the system OS, the CPU_1 101 can occupy all four core processors, thereby improving a performance of the whole SoC 100.”).
Kim, Gunter, Paltashev, Franke, and Mitsutani fail to teach that the currently executing frame of the first execution schedule is completed prior to the execution of the second execution schedule.
However, Herbert teaches wherein a currently executing frame of the first
execution schedule is completed prior to the switching to the execution of the
second execution schedule (Col. 14, lines 3-22, “In response to the receipt of this
interrupt request, the preemptible resource ceases execution of the currently executing
compute job sub-task (970). Execution of the currently executing compute job sub-task
having been preempted (either gracefully or immediately)…” One of ordinary skill in the art will understand that graceful preempting allows the currently executing task to
complete before switching.).
Kim, Gunter, Paltashev, Franke, Mitsutani, and Herbert are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the scheduling method of Kim, Gunter, Paltashev, Franke, and Mitsutani with the graceful preemption functionality of Herbert to arrive at the claimed invention. The motivation to modify Aoyama, Gunter, Paltashev, Franke, and Mitsutani with the teachings of Herbert is that allowing the currently executing frame to complete before switching execution schedules avoids any critical portions of the first execution schedule from being prematurely terminated leading to unwanted problems (See Herbert Col. 14, lines 3-22.).
Claim(s) 9-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kim in view of Aoyama in view of Paltashev in view of Franke in view of Mitsutani.
As per claim 9, Kim teaches a system comprising: one or more processors to perform operations comprising: directing execution of a first execution schedule by one or more first compute engines of a plurality of compute engines, of a first plurality of runnables (¶ [0042]-[0044], “Here, the CPU_1 101 can execute a system operating system (OS). The system OS executes general-purpose tasks including interaction with a user, and may be, for example, an Android OS. The CPU_2 103 can execute a software program that processes a special task requiring fast processing without user interaction. For example, the CPU_2 103 may execute a Linux kernel. The CPU_3 105 can execute a software program that processes a task requiring real-time processing. For example, the CPU_3 105 may execute a real time operating system (RTOS).”) and execution of a second execution schedule by one or more compute engines of a plurality of compute engines, of a second plurality of runnables (¶ [0042]-[0044], “Here, the CPU_1 101 can execute a system operating system (OS). The system OS executes general-purpose tasks including interaction with a user, and may be, for example, an Android OS. The CPU_2 103 can execute a software program that processes a special task requiring fast processing without user interaction. For example, the CPU_2 103 may execute a Linux kernel. The CPU_3 105 can execute a software program that processes a task requiring real-time processing. For example, the CPU_3 105 may execute a real time operating system (RTOS).”), wherein the one or more first compute engines and the one or more second compute engines have at least one device in common (¶ [0048], “The CPU_1 101 and CPU_2 103 are connected to a synchronous dynamic random access memory (SDRAM) 111, a dedicated device 113, and a plurality of shared devices 115 via a bus 109. Here, the dedicated device 113 and the plurality of shared devices 115 may include a universal asynchronous receiver/transmitter (UART), an inter-integrated circuit (I2C), a GPSB, an embedded multi-media card (eMMC), and the like.” ¶ [0072], “Four heterogeneous CPUs 101, 103, 105, and 107 on an SoC 100 operate independent software programs and perform tasks of different purposes, respectively. As described above, each of the CPUs 101, 103, 105, and 107 owns its own physical resource, and shares and uses the resource with other CPUs 101, 103, 105, and 107.”).
Kim fails to teach switching to execution of the second schedule prior to completion of the first.
However, Aoyama teaches prior to completion of execution of the first execution schedule and in response to a switching instruction (Col. 6, lines 5-13, “Thus, the main processor process scheduler 12 is configured to detect the processing status of a process executed by the processor core 111 (detect the switching of a process) and transmit status notification information to the other process scheduler.”), directing that a switch be made to execution of a second execution schedule (Col. 5, lines 23-32, “For example, the main processor process scheduler 12 executes a context switch on the basis of a scheduling policy 122 to be described later. That is to say, the main processor process scheduler 12 switches a process executed by the processor core 111.” Col. 5 & 6, lines 48-67 & 1-4, “To be specific, for example, the main processor process scheduler 12 receives status notification information representing that the process has transitioned to the standby state from the coprocessor process scheduler 14…Meanwhile, for example, the main processor process scheduler 12 receives status notification information representing that the process has been dispatched from the coprocessor process scheduler 14.”).
Kim and Aoyama are considered to be analogous to the claimed invention because they are in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kim with the known technique of task preemption of Aoyama to arrive at the claimed invention. This modification would have been reasonable under MPEP § 2143 as Aoyama teaches task execution preemption and switching.
Kim and Aoyama fail to explicitly teach the execution schedules dictating timing and order of execution.
However, Paltashev teaches execution schedules that dictates timing and order of execution (¶ [0110]-[0112], “Semaphore P and semaphore V are metacommands that can be configured to provide a capability to manage context execution on software events versus astronomical time in case of time slice counter based management. Both the CPU and the GPU can send these metacommands to the context and manage execution and/or suspension of the context.” Examiner Note: There are a number of metacommands that control the order and timing of execution of the processes during processing.).
Kim, Aoyama, and Paltashev are all considered to be analogous to the claimed invention because they are in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kim and Aoyama with the timing and order commands of Paltashev to arrive at the claimed invention. The motivation to modify Kim and Aoyama with the teachings of Paltashev is that it becomes easier to control and/or manipulate the execution schedules through the use of timing and order commands (See Paltashev para. 0110.).
Although Kim, Aoyama, and Paltashev teach the one or more first compute engines and the one or more second compute engines having at least one device in common. They fail to teach that the device is a compute engine.
Accordingly, Franke teaches compute engines having at least one compute engine in common (¶ [0070], “Processors 104 may transmit resource requests to shared devices. The shared devices may comprise a plurality of resources and may respond to such resource requests. For example, a shared device may comprise process accelerators such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGA), graphics processing units (GPUs), digital signal processors (DSPs), etc.”).
Kim, Aoyama, Paltashev, and Franke are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kim, Aoyama, and Paltashev with Franke to show that a shared device can include a compute engine.
Kim, Aoyama, Paltashev, and Franke fail to teach the execution schedules corresponding to modalities of a machine and that switching execution schedules is in response to the machine switching modalities.
However, Mitsutani teaches the first execution schedule that corresponds to a first modality of a machine and the second execution schedule that corresponds to a second modality of the machine (¶ [0039]-[0040], “An information processing device of the present disclosure provides functions of a control platform by a vehicle integrated electronic control unit (ECU) (central ECU) alone, an external cloud alone, or a combination of the vehicle integrated ECU and the external cloud. The control platform operates as a central brain configured to control overall operation and behavior of a vehicle…The information processing device 20 includes a command library 21, a mobility system controller 22, an information sharing portal 23, and an integrated manager 24. The vehicle control system may be mounted on a vehicle such as an automobile.” ¶ [0043]-[0045], “In other words, the command library 21 converts a request received from the service application 10 into a request for the integrated manager 24 or the mobility system controller 22. For example, the command library 21 includes a library of various commands for implementing the following functions in association. (1) Function of implementing a single or complex operation command for the vehicle device 30 (such as an actuator). This operation command is a command for fulfilling a request received from the service application 10. (2) Function of outputting (issuing) a switching trigger for a vehicle control mode. The vehicle control mode defines behavior of the vehicle (usage of the vehicle as a product).” ¶ [0051]-[0052], “For example, the command library 21 outputs a trigger for an instruction to switch the vehicle control mode, transmits an operation schedule, and reports scheduling to the mobility system controller 22. The command library 21 outputs a control request or a service request to the integrated manager 24. The command library 21 receives various service requests from the service application 10. The command library 21 can provide the information sharing portal 23 with application modification information to be open to the public. The command library 21 refers to shared information open to the public at the information sharing portal 23. The command library 21 can exchange information with the plant library 40. The mobility system controller 22 is a functional block (determiner and status transitioner) configured to, for example, centrally manage a control condition related to behavior of the vehicle (usage or operation), manage progress of a series of tasks based on an operation schedule, and manage schedules.”). Mitsutani also teaches in response to a switching instruction in response to a modality switch of the machine from the first modality to the second modality, directing that a switch be made to execution of a second execution schedule (¶ [0051]-[0052], “For example, the command library 21 outputs a trigger for an instruction to switch the vehicle control mode, transmits an operation schedule, and reports scheduling to the mobility system controller 22. The command library 21 outputs a control request or a service request to the integrated manager 24. The command library 21 receives various service requests from the service application 10. The command library 21 can provide the information sharing portal 23 with application modification information to be open to the public. The command library 21 refers to shared information open to the public at the information sharing portal 23. The command library 21 can exchange information with the plant library 40. The mobility system controller 22 is a functional block (determiner and status transitioner) configured to, for example, centrally manage a control condition related to behavior of the vehicle (usage or operation), manage progress of a series of tasks based on an operation schedule, and manage schedules.” ¶ [0054]-[0060], “The mobility system controller 22 manages overall control on the vehicle by using the following elements (plurality of modes and states). The mobility system controller 22 controls components of the vehicle device 30 and behavior of the system, and adjusts UX requests depending on situations of the vehicle (time, place, and occasion: TPO).
States: manage transition of vehicle statuses along with sequential control phases.
<traveling state/motion state/transportation state/electric power infrastructure cooperation state>
Sub-modes: limit purposes and means of control under one or more modes.
<driving sub-mode/charging sub-mode/equipment power supply sub-mode/auxiliary-device supplementation sub-mode/AC power supply sub-mode>” See also para. 0067.).
Kim, Aoyama, Paltashev, Franke, and Mitsutani are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the method of switching execution schedules of Kim, Aoyama, Paltashev, and Franke to be in response to a modality switch of a machine as taught by Mitsutani to arrive at the claimed invention. The motivation to modify Kim, Aoyama, Paltashev, and Franke with the teachings of Mitsutani is that correctly switching execution schedules that corresponds to various modalities of a machine ensures appropriate control of the machine and avoids causing inconsistencies among the various operations associated with the various modalities of the machine (See Mitsutani para. 0039.).
As per claim 10, Kim, Aoyama, Paltashev, Franke, and Mitsutani teach the system of claim 9. Kim teaches wherein the operations further comprise directing that at least a portion of the first execution schedule continue to be executed after the switching to execution of the second execution schedule (¶ [0081], “As such, the four heterogeneous CPUs 101, 103, 105, and 107 operate in parallel at the time point of power-on. The heterogeneous CPUs 101, 103, 105, and 107 are driven successively in an order of CPU_3 105.fwdarw.CPU_1 101.fwdarw.CPU_2 103.fwdarw.CPU_4 107, and then independently execute respective software programs.”).
As per claim 11, Kim, Aoyama, Paltashev, Franke, and Mitsutani teach the system of claim 9. Aoyama teaches wherein the operations further comprise directing that the execution of the first execution schedule be completely terminated prior to completion of the first execution schedule and prior to the execution of the second execution schedule beginning (Col. 9, lines 27-50, “Meanwhile, the main processor process scheduler 12 may simultaneously receive, from the coprocessor process scheduler 14, status notification information showing that a process has transitioned to the standby state and status notification information showing that a process has been dispatched…Thus, the main processor process scheduler 12 checks whether or not a process on the main processor node 1 associated with the process switched by the coprocessor process scheduler 14 is in the waiting state (step S202). In a case where the associated process is not in the waiting state (step S202, no), the main processor process scheduler 12 ends the processing.”).
Refer to claim 9 for reason to combine.
As per claim 12, Kim, Aoyama, Paltashev, Franke, and Mitsutani teach the system of claim 9. Aoyama teaches wherein the operations further comprise reporting to a schedule monitoring system that the switching to execution of the second execution schedule has occurred (Col. 8, lines 24-51, “After that, by using the status notification means 13, the main processor process scheduler 12 notifies status notification information showing that the process has transitioned to the standby state and status notification information showing that a process has been dispatched, to the other process scheduler 14 (the coprocessor process scheduler 14) (step S103)…For example, the main processor process scheduler 12 can transmit, at different timings, status notification information showing that a process has transitioned to the standby state and status notification information showing that a process has been dispatched.”).
Refer to claim 9 for reason to combine.
As per claim 13, Kim, Aoyama, Paltashev, Franke, and Mitsutani teach the system of claim 9. Mitsutani teaches wherein the modality switch includes a change in an operational movement of the machine (¶ [0054]-[0060], “The mobility system controller 22 manages overall control on the vehicle by using the following elements (plurality of modes and states). The mobility system controller 22 controls components of the vehicle device 30 and behavior of the system, and adjusts UX requests depending on situations of the vehicle (time, place, and occasion: TPO).
States: manage transition of vehicle statuses along with sequential control phases.
<traveling state/motion state/transportation state/electric power infrastructure cooperation state>
Sub-modes: limit purposes and means of control under one or more modes.
<driving sub-mode/charging sub-mode/equipment power supply sub-mode/auxiliary-device supplementation sub-mode/AC power supply sub-mode>” ¶ [0067], “The mobility system controller 22 outputs a trigger for an instruction to activate an application to the service application 10. For example, the mobility system controller 22 acquires a trigger for an instruction to switch the vehicle control mode, an operation schedule, and scheduling from the command library 21. The mobility system controller 22 can provide the information sharing portal 23 with mobility system information (such as a control mode, an operation condition, and a UX adjustment result) to be open to the public.” ¶ [0088]-[0097], “Referring to FIG. 2 to FIG. 12, detailed description is given of the vehicle control mode management that is one type of control to be executed by the mobility system controller 22 to implement various services in the vehicle control system of the present disclosure. The vehicle control mode management is control related to behavior of the vehicle (usage or operation). In the vehicle control mode management, the mobility system controller 22 controls the behavior of the vehicle (usage or operation) by using the following control modes and control states.
(1) Main modes (vehicle control modes)
1-1: Automobile mode
1-2: Electric mode (stationary electric mode)
1-3: Generator mode (emergency generator mode)
1-4: Stop mode
(2) States
2-1: Traveling state (standby, start, travel, end)
2-2: Motion state (hold, stop, startability determination, drive, stopping necessity determination)
2-3: Transportation state (standby, stop, depart, move)
2-4: Electric power infrastructure cooperation state (standby, ready, charge, supply)”).
Refer to claim 9 for reason to combine.
As per claim 15, Kim, Aoyama, Paltashev, Franke, and Mitsutani teach the system of claim 9. Mitsutani teaches wherein the system is comprised in at least one of:
a control system for an autonomous or semi-autonomous machine (¶ [0085], “Among the applications installed in the vehicle, the driving application 50 is dedicated to driving of the vehicle and assistance of the driving, and is not included in the service application 10. Examples of the driving application 50 include remote driving such as autonomous parking, autonomous driving (AD), autonomous driving in MaaS (Autono-MaaS), and an advanced driver assistance system (ADAS).”);
a perception system for an autonomous or semi-autonomous machine;
a system for performing simulation operations;
a system for performing digital twin operations;
a system for performing light transport simulation;
a system for performing collaborative content creation for 3D assets;
a system for performing deep learning operations;
a system for presenting at least one of augmented reality content, virtual reality content, or mixed reality content;
a system for hosting one or more real-time streaming applications;
a system implemented using an edge device;
a system implemented using a robot;
a system for performing conversational AI operations;
a system for generating synthetic data;
a system incorporating one or more virtual machines (VMs);
a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources.
Refer to claim 9 for reason to combine.
Claim(s) 14 is rejected under 35 U.S.C. 103 as being unpatentable over Kim, Aoyama, Paltashev, Franke, and Mitsutani as applied to claim 9 above, and further in view of Herbert.
As per claim 14, Kim, Aoyama, Paltashev, Franke, and Mitsutani teach the system of claim 9. Kim teaches the first execution schedule and the second execution schedule (¶ [0047], “As such, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 execute software programs independent of each other. Therefore, for example, the software program of the CPU_1 101 can use all four core processors. Specifically, when the software program of the CPU_1 101 is the system OS, the CPU_1 101 can occupy all four core processors, thereby improving a performance of the whole SoC 100.”).
Kim, Aoyama, Paltashev, Franke, and Mitsutani fail to teach reconfiguring some of the processing clients upon switching from the first to the second execution schedule.
However, Herbert teaches wherein one or more processing clients corresponding to execution of the first execution schedule and the second execution schedule are reconfigured for the switching to execution to the second execution schedule (Col. 12, lines 1-25, “Alternatively, if one or more of the resources needed for the execution of the given compute job or a subtask thereof cannot be assigned (e.g., due to failure, use by another unit of execution of either the same compute job or that of another compute job, or the like) (650), a determination is made as to whether the one or more resources are preemptible (e.g., the one or more resources are now in use by another compute job, but that use can be migrated elsewhere or otherwise preempted) (660).”).
Kim, Aoyama, Paltashev, Franke, Mitsutani, and Herbert are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the scheduling system of Kim, Aoyama, Paltashev, Franke, and Mitsutani with the processing resource allocation functionality of Herbert to arrive at the claimed invention. The motivation to modify Kim, Aoyama, Paltashev, Franke, and Mitsutani with the teachings of Herbert is that the ability to reconfigure processing clients gives the system the ability to execute any execution schedule regardless of processing needs (See Herbert Col. 8, lines 19-56.).
Claim(s) 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Aoyama in view of Kim in view of Gunter in view of Mitsutani.
As per claim 16, Aoyama teaches one or more processors comprising: processing circuitry (Col. 4, lines 15-21, “With reference to FIG. 1, the parallel computer 4 in this exemplary embodiment includes one main processor node 1 (a first node) and one or more coprocessor nodes 2 (a second node).”) to cause performance of operations comprising: prior to completion of execution of a first execution schedule using a plurality of compute engines, as managed by a task managing system, directing the task managing system to cause an initiation of execution of a second execution schedule by the plurality of compute engines (Col. 6, lines 19-38, “FIG. 4 shows an example of a configuration used when the main processor process scheduler 12 executes a context switch. With reference to FIG. 4, the main processor process scheduler 12 includes the scheduling policy 122, a process switch means 123…The process switch means 123 is a means for switching a process executed by the processor core 111. For example, the process switch means 123 saves, as the process context 124, the context of the process core 111 on which a process as the target of switching in a context switch is running. Then, the process switch means 123 restores the process context 124 of a dispatch target to the target processor core 111.”).
Aoyama fails to teach the execution schedules being executed by respective subsets of the plurality of compute engines.
However, Kim teaches execution of a first execution schedule using one or more first compute engines of a plurality of compute engines, execution of a second execution schedule using one or more second compute engines of the plurality of compute engines (¶ [0042]-[0044], “Here, the CPU_1 101 can execute a system operating system (OS). The system OS executes general-purpose tasks including interaction with a user, and may be, for example, an Android OS. The CPU_2 103 can execute a software program that processes a special task requiring fast processing without user interaction. For example, the CPU_2 103 may execute a Linux kernel. The CPU_3 105 can execute a software program that processes a task requiring real-time processing. For example, the CPU_3 105 may execute a real time operating system (RTOS).”).
Aoyama and Kim are considered to be analogous to the claimed invention because they are in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aoyama with the teachings of Kim to arrive at the claimed invention. The motivation to modify Aoyama with the teachings of Kim is that giving each execution schedule their own subset of the available compute engines avoids any resource contention scenarios or race conditions that may arise from the execution schedules competing for compute engines (See Kim para. 0012.).
Aoyama and Kim fail to teach the execution schedules being deterministic and unchanging across different execution iterations.
However, Gunter teaches the first execution schedule and the second execution schedule are deterministic and static such that the first execution schedule and the second execution schedule are unchanged during different execution iterations (¶ [0054], “The individualized operation schedules 18 may be particularly useful for applications that are computationally intense, highly repetitive, or both, such as neural network and graphic processing computations. For example, the use of explicitly defined schedules for individual hardware blocks 12 on a chip 10 can be conducive to deterministic operations in which scheduled operations are each executed in a predefined number of clock cycles.” See also Fig. 2A.).
Aoyama, Kim, and Gunter are considered to be analogous to the claimed invention because they are in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the scheduling system of Aoyama and Kim with the schedule generation functionality of Gunter to arrive at the claimed invention. The motivation to modify Aoyama and Kim with the teachings of Gunter is that having knowledge of the exact execution schedule prior to processing the execution schedule allows the system to optimize how it handles the processing of the execution schedule (See Gunter para. 0035-0037.).
Aoyama, Kim, and Gunter fail to teach the execution schedules corresponding to movement modalities of a machine.
However, Mitsutani teaches the first execution schedule corresponds to a first movement modality of a machine and the second execution schedule corresponds to a second movement modality of the machine (¶ [0039]-[0040], “An information processing device of the present disclosure provides functions of a control platform by a vehicle integrated electronic control unit (ECU) (central ECU) alone, an external cloud alone, or a combination of the vehicle integrated ECU and the external cloud. The control platform operates as a central brain configured to control overall operation and behavior of a vehicle…The information processing device 20 includes a command library 21, a mobility system controller 22, an information sharing portal 23, and an integrated manager 24. The vehicle control system may be mounted on a vehicle such as an automobile.” ¶ [0043]-[0045], “In other words, the command library 21 converts a request received from the service application 10 into a request for the integrated manager 24 or the mobility system controller 22. For example, the command library 21 includes a library of various commands for implementing the following functions in association. (1) Function of implementing a single or complex operation command for the vehicle device 30 (such as an actuator). This operation command is a command for fulfilling a request received from the service application 10. (2) Function of outputting (issuing) a switching trigger for a vehicle control mode. The vehicle control mode defines behavior of the vehicle (usage of the vehicle as a product).” ¶ [0051]-[0052], “For example, the command library 21 outputs a trigger for an instruction to switch the vehicle control mode, transmits an operation schedule, and reports scheduling to the mobility system controller 22. The command library 21 outputs a control request or a service request to the integrated manager 24. The command library 21 receives various service requests from the service application 10. The command library 21 can provide the information sharing portal 23 with application modification information to be open to the public. The command library 21 refers to shared information open to the public at the information sharing portal 23. The command library 21 can exchange information with the plant library 40. The mobility system controller 22 is a functional block (determiner and status transitioner) configured to, for example, centrally manage a control condition related to behavior of the vehicle (usage or operation), manage progress of a series of tasks based on an operation schedule, and manage schedules.” See also para. 0067.).
Aoyama, Kim, Gunter, and Mitsutani are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the method of switching execution schedules of Aoyama, Kim, and Gunter to be in response to a modality switch of a machine as taught by Mitsutani to arrive at the claimed invention. The motivation to modify Aoyama, Kim, and Gunter with the teachings of Mitsutani is that correctly switching execution schedules that corresponds to various modalities of a machine ensures appropriate control of the machine and avoids causing inconsistencies among the various operations associated with the various modalities of the machine (See Mitsutani para. 0039.).
As per claim 17, Aoyama, Kim, Gunter, and Mitsutani teach the one or more processors of claim 16. Kim teaches wherein the operations further comprise directing the task managing system to cause at least a portion of the first execution schedule continue to be executed after the initiating of the execution of the second execution schedule (¶ [0081], “As such, the four heterogeneous CPUs 101, 103, 105, and 107 operate in parallel at the time point of power-on. The heterogeneous CPUs 101, 103, 105, and 107 are driven successively in an order of CPU_3 105.fwdarw.CPU_1 101.fwdarw.CPU_2 103.fwdarw.CPU_4 107, and then independently execute respective software programs.”).
Refer to claim 16 for reason to combine.
As per claim 18, Aoyama, Kim, Gunter, and Mitsutani teach the one or more processors of claim 16. Aoyama teaches wherein the operations further comprise directing the task managing system (Col. 4, lines 28-37, “Process schedulers which manage processes executed by the main processor 11 and a coprocessor 21 to be described later operate on the operating system of the main processor node 1.”) to cause the execution of the first execution schedule to be completely terminated prior to completion of the first execution schedule and prior to causing the execution of the second execution schedule to start (Col. 9, lines 27-50, “Meanwhile, the main processor process scheduler 12 may simultaneously receive, from the coprocessor process scheduler 14, status notification information showing that a process has transitioned to the standby state and status notification information showing that a process has been dispatched…Thus, the main processor process scheduler 12 checks whether or not a process on the main processor node 1 associated with the process switched by the coprocessor process scheduler 14 is in the waiting state (step S202). In a case where the associated process is not in the waiting state (step S202, no), the main processor process scheduler 12 ends the processing.”).
As per claim 19, Aoyama, Kim, Gunter, and Mitsutani teach the one or more processors of claim 16. Aoyama teaches wherein the directing to switch to execution of the second execution schedule is communicated to the task managing system in response to receiving an indication from the task managing system that execution of at least a portion of the first execution schedule has been terminated (Col. 8 & 9, lines 55-67 & 1-22, “That is to say, the coprocessor process scheduler 14 determines a process to switch in a context switch in accordance with a scheduling policy included by the coprocessor process scheduler 14 (step S101; see FIG. 5)…After that, by using the status notification means 13, the coprocessor process scheduler 14 notifies status notification information showing that the process has transitioned to the standby state and status notification information showing that a process has been dispatched, to the other process scheduler (the main processor process scheduler 12 and the other coprocessor process scheduler 14) (step S103; see FIG. 5).”).
Claim(s) 20 is rejected under 35 U.S.C. 103 as being unpatentable over Aoyama, Kim, Gunter, and Mitsutani as applied to claim 16 above, and further in view of Herbert.
As per claim 20, Aoyama, Kim, Gunter, and Mitsutani teach the system of claim 9. Kim teaches the first execution schedule and the second execution schedule (¶ [0047], “As such, the CPU_1 101, the CPU_2 103, the CPU_3 105, and the CPU_4 107 execute software programs independent of each other. Therefore, for example, the software program of the CPU_1 101 can use all four core processors. Specifically, when the software program of the CPU_1 101 is the system OS, the CPU_1 101 can occupy all four core processors, thereby improving a performance of the whole SoC 100.”).
Aoyama, Kim, Gunter, and Mitsutani fail to teach reconfiguring some of the processing clients upon switching from the first to the second execution schedule.
However, Herbert teaches wherein the operations further comprise directing that one or more processing clients corresponding to execution of the first execution schedule and the second execution schedule are reconfigured for the initiating of the execution to the second execution schedule (Col. 12, lines 1-25, “Alternatively, if one or more of the resources needed for the execution of the given compute job or a subtask thereof cannot be assigned (e.g., due to failure, use by another unit of execution of either the same compute job or that of another compute job, or the like) (650), a determination is made as to whether the one or more resources are preemptible (e.g., the one or more resources are now in use by another compute job, but that use can be migrated elsewhere or otherwise preempted) (660).”).
Aoyama, Kim, Gunter, Mitsutani, and Herbert are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the scheduling system of Aoyama, Kim, Gunter, and Mitsutani with the processing resource allocation functionality of Herbert to arrive at the claimed invention. The motivation to modify Aoyama, Kim, Gunter, and Mitsutani with the teachings of Herbert is that the ability to reconfigure processing clients gives the system the ability to execute any execution schedule regardless of processing needs (See Herbert Col. 8, lines 19-56.).
Response to Arguments
Applicant’s arguments, filed 3/26/2026, with respect to the 35 U.S.C. 112(b) rejection of claim 4 has been fully considered and is persuasive. The 35 U.S.C. 112(b) rejection of claim 4 has been withdrawn. Applicant’s arguments with respect to the 35 U.S.C. 103 rejection of claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Applicant has amended the claims with new limitations that change the scope of the claimed invention. Therefore, the amended claims necessitate new rejections, as addressed above. The amended claims are not allowable over prior art previously cited along with an additional reference, necessitated by amendment, for reasons indicated above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 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, Lewis Bullock can be reached at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights