DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 04/10/2026.
Claims 1 and 9 have been amended.
Claims 5, 6, 8, 13, 14, and 16-23 have been cancelled.
Claims 1-4, 7, 9-12, 15 and 24-30 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments filed 04/10/2026 have been considered but are not persuasive and/or moot in view of the new grounds of rejection as described below.
On pg. 2 of the Remarks, Applicant summarizes the prior rejection:
“As an initial matter, Applicant notes what Applicant understands the Examiner to assert that Isaacson teaches, particularly as asserted relative to claim 1. Applicant does not concede to the Examiner's assertion but notes this solely for clarity of the record. … If any of Applicant's understanding of what the Examiner asserts Isaacson teaches is incorrect, Applicant respectfully requests that the Examiner clearly identify and correct what is misunderstood.”
Applicant’s summary appears substantially correct. For clarity regarding beginning a first/second task specific note is made of exemplary task triggering events in Isaacson including external interrupt(s) and timer tick(s), "For example, consider a system with three tasks, A, B and C. Task A reads data from an input port, and passes that information to Task B with a queue. Task A knows new data is ready via an interrupt set externally. (pg. 9)...For example, if a task were to only run every millisecond, the dependence is the millisecond tick; the task must wait for the tick in order to execute" (pg. 25).
On pg. 5 of the Remarks, Applicant essentially argues:
“Removing the task from the ready queue seems to terminate execution of the task on the RTP rather than "pause" the task on the RTP. In any event, neither Isaacson nor the Office Action clearly indicates that blocking in Isaacson is "pausing" or "pause", as understood by a person of ordinary skill in the art, as recited in claims 1 and 9. Accordingly, the Office Action fails to provide a prima facie case of unpatentability of claims 1 and 9.
If the Examiner maintains in a subsequent rejection that the blocking in Isaacson is "pausing" or "pause" as recited in claims 1 and 9, Applicant respectfully requests specific explanation of how blocking in Isaacson would be understood by a person of ordinary skill in the art to be "pausing" or "pause" as recited in claims 1 and 9, with specific corroborating citations to Isaacson or other evidence.
A blocked task is not running; its execution state does not make forward progress while it is “blocked” because it is waiting for something it needs to continue its execution (e.g. release of a resource); its program counter is not being incremented but still points to the instruction where it blocked. Examiner maintains a task in this “blocked” state is reasonably construed as being “paused”. From Isaacson:
"The resource node keeps track of pending requests and grants for a resource. The TRM provides important hardware assistance to the RTOS by keeping track of the tasks that are waiting for specific resources. This new circuit provides information to the scheduler about what tasks are “blocked” waiting for any un-granted resources (pg. 4)...lock r: Attempt to reserve system resource r. If unsuccessful, the task is blocked until the resource becomes available (pg. 37)...A task sends a signal to the TRM to lock or reserve a resource for exclusive use. If the resource lock is granted, the task may continue executing and use the resource. If the lock is not granted, the TRM signals the scheduler to block that task from executing (pg. 38)...On a lock, the request flag is set. The task will be blocked until the lock is granted (i.e. the request flag is reset and the grant flag is set)" (pg. 44).
Examiner additionally notes that AppSpec does not ascribe any specific meaning to the term “pause”, to the contrary the term does not appear anywhere in the detailed description in AppSpec. It is unclear what Applicant is suggesting functionally distinguishes a task that “paused” from one that is “blocked”.
Furthermore, the terms used by Issacson have well-understood meanings and are part of the standard nomenclature of the art; and a person of ordinary sill in the art would recognize a “blocked” task not executing while waiting/pending for something. Citations are provided below and in the conclusion section of this Action as evidence demonstrating the meaning of various terms in the art.
“Embedded Systems A Contemporary Design Tool”, pg. 546:
“A task’s context comprises the important information about the state of the task, such as the values of any variables (held in the CPU’s registers), the value of the program counter, and so forth. Each time that a running task is stopped – preempted or blocked – and the CPU is given to another task that is ready, a switch to a new context is executed. A context switch first requires that the state of the currently active task be saved. If the task that is scheduled to get the CPU next had been running previously, its state is restored and it continues where it had left off. Otherwise, the new task starts from its initial state”)”
From “Blocking (computing)” (Wikipedia)
“In computing, a process that is blocked is waiting for some event, such as a resource becoming available or the completion of an I/O operation. Once the event occurs for which the process is waiting ("is blocked on"), the process is advanced from blocked state to an imminent one, such as runnable...When one task is using a resource, it is generally not possible, or desirable, for another task to access it. The techniques of mutual exclusion are used to prevent this concurrent use. When the other task is blocked, it is unable to execute until the first task has finished using the shared resource.”
“In computing, preemption is the act performed by an external scheduler — without assistance or cooperation from the task — of temporarily interrupting an executing task, with the intention of resuming it at a later time...Such changes to the currently executing task of a processor are known as context switching…In early systems, processes would often "poll" or "busy-wait" while waiting for requested input (such as disk, keyboard or network input). During this time, the process was not performing useful work, but still maintained complete control of the CPU. With the advent of interrupts and preemptive multitasking, these I/O bound processes could be "blocked", or put on hold, pending the arrival of the necessary data, allowing other processes to utilize the CPU. As the arrival of the requested data would generate an interrupt, blocked processes could be guaranteed a timely return to execution.”
From US 20050240924 A1 ¶0018:
“Because conventional schedulers do not account for all the resources that a task may need to fully execute, a dispatched task becomes blocked when a required resource is unavailable. Once blocked, the task must revert to a "pending state" and give up the processor which it had-been granted. Note that the task is not reset, it is just paused (having yielded the CPU) and waiting for the resource to become available. When a task becomes blocked, the scheduler must run again and dispatch another task that is in a "ready queue" of other potentially dispatchable tasks. Note that tasks that appear to require no other resources except the processor to run are known as being in the "ready state" and are placed in the ready queue. However, even the newly dispatched task may become blocked, because tasks in the ready state may eventually need a resource that is not available. Eventually, the first blocked task may become unblocked when the required resource becomes available. For example, one of the tasks that was dispatched while the first task was in the pending state may have created the resource needed by the first task.”
On pg. 5 of the Remarks, Applicant requests clarification:
“Applicant requests explanation of what specifically occurs at the scheduler and at the RTP when a task is blocked without any intervening task preempting that task. What is not controvertible is that the scheduler blocks the task from executing, see Isaacson at 39 ("[T]he TRM signals the scheduler to block that task from executing."), and that the only output signal from the scheduler to the RTP is the task ID, see id at 27 ("The only output of the scheduler is the task ID of the highest priority ready task").
In this case the scheduler switches to the idle task, or to be technically specific, the described scenario where “a task is blocked without any intervening task preempting that task” can never occur in Isaacson because “task 0 is a special case as task 0 is the idle task, which is always ready, and always has a priority of 0” (pg. 29, emphasis added) and the scheduler ensures “any ready task is automatically given higher priority than any non-ready task” (pg. 29).
On pg. 5 of the Remarks, Applicant continues:
“What happens at the scheduler when the requested resource becomes available again such that task is not blocked by the scheduler? Apparently, the scheduler would output the task ID again once the resource becomes available. Would the RTP interpret this task ID as the beginning of a new task? If not, how would the RTP discern that the task is the same as the task that began execution and was blocked? If it is asserted that the RTP can discern that the task is the same as the task that began execution and was blocked, how would the RTP discern that the scheduler would intend a new instance of the task to be executed rather than resuming execution of the previously blocked execution of the task?”
It is not necessary for Isaacson to make the distinction. In Isaacson each task (task_ID) has its own corresponding HW context including most notably the program counter (PC). The task_ID output by the scheduler connects the identified task’s PC to the processor’s instruction pipeline and the task’s instructions to feed into the pipeline. The system operates uniformly regardless of whether the task’s instructions are fetched from the beginning of the task’s functional block or some intermediate point. From Isaacson:
“The processor was divided into only 3 pipe stages...The first stage is instruction fetch. In this stage the appropriate program counter is accessed, the address is latched in the instruction memory and the program counter is incremented (pg. 11)...context switching only takes 1 cycle in the RTP system. This is accomplished by the fact that no registers or flag sets have to be saved when switching context. Each task has its own program counter (PC), register set, and flag set...Each task must be able to maintain where it is in execution. The program counter must then either be saved into the data memory or have a specialized register to save itself during a context switch. Figure 2-2 shows the block diagram for the program counter (pg. 13)...As already mentioned, in order to make context switching times fast, each task has its own register set…The address to the register set is derived from the concatenation of the task ID with the register address.”
On pg. 6 of the Remarks, Applicant essentially argues:
“Regarding the scenario "if the second processor task is still being performed," as described above, Applicant understands that the Examiner interprets Isaacson as teaching that the resource is immediately and automatically granted to the blocked task even if a higher priority task is executing on the RTP. Hence, based on this understanding, the RTP in Isaacson would not "not acquir[e] use of' the asserted shared resource that was requested by the blocked task. Neither Isaacson nor Dice teaches or suggests this feature of claim 1.”
Examiner notes the distinction being drawn Is essentially the same that recited in claim 1 (prior claim 23) and claim 27 phrased in a different manner and accordingly stands rejected under the same essential rationale as shown in the rejections below.
On pg. 6-7 of the Remarks, Applicant essentially argues:
“the Office Action asserts a modification that would render Isaacson unsatisfactory for its
intended purpose. See MPEP § 2143.01(V). Applicant understands that the Office Action
attempts to modify Isaacson such that a task that has a resource locked and is releasing the resource communicates to a blocked task that the resource that the blocked task requested has been released and that the blocked task then requests the resource again. See Office Action at 11 (quoting Dice: "In competitive handoff, when a thread unlocks an object, it marks the object as available and then makes a potential successor thread (sometimes called the heir apparent) ready. The successor, upon waking up, must compete for the object like other threads."). Isaacson expressly teaches that the TRM "is an innovative feature of this architecture that controls the sharing of the resources in a unified way," "provides important hardware assistance to the RTOS by keeping track of the tasks that are waiting for specific resources," and "provides information to the scheduler about what tasks are 'blocked' waiting for any un-granted resources." Isaacson at 4. The asserted modification obviates these features of lsaacson's TRM and renders the TRM unsatisfactory for its intended purpose.”
Examiner respectfully disagrees the modification to change Isaacson’s lock release protocol for some single acquisition resources (e.g. mutex) would obviate the identified features and/or renders the TRM unsatisfactory for its intended purpose.
The TRM “controls the sharing of the resources in a unified way” but still permits variation:
“Not all of the connections are used with every resource; some of the signals may not have meaning (pg. 40)...The resource modules and resource nodes vary for each type of resource. However, the interconnections between them are standard. The task modules also interface with the resource nodes in a standard fashion, although some of the connections may not be used. The goal of standard connections is to simplify system generation” (46-47).
The TRM’s ability to provide “important hardware assistance to the RTOS by keeping track of the tasks that are waiting for specific resources" and provide “information to the scheduler about what tasks are 'blocked' waiting for any un-granted resources" would be wholly unaffected by the proposed modification.
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.
Claims 1-4, 7, 9-12, 15, and 24-30 are rejected under 35 U.S.C. 103 as being unpatentable over Isaacson (“Hardware Support for a Configurable Architecture for Real-Time Embedded Systems on a Programmable Chip”, 2007) in view of Dice (“Implementing Fast Java Monitors with Relaxed-Locks”, 2001).
Claims 1 and 24:
Isaacson discloses the limitations as shown in the following rejections:
A method comprising: beginning, using a processor, a first processor task that uses a first shared resource (pg. 3-5; pg. 8-9, § 2.1).
sending a first notice (resource control instruction) from a task manager circuit (scheduler + Real Time Processor (RTP) Interface) of the processor to a spinlock circuit (Task-Resource Matrix (TRM)), wherein the spinlock circuit is configured to determine and communicate availability of a plurality of shared resources that includes the first shared resource, and wherein the first notice indicates to the spinlock circuit that the processor is requesting use of the first shared resource; (pg. 4; pg. 5, Fig. 1-1; pg. 10, para. 2; pg. 37, para. 1-2) disclosing tasks request use of resources by executing “resource-specific control instructions in this new architecture include…lock r: Attempt to reserve system resource r.” (pg. 37) which causes the RTP interface to send a request signal to the TRM.
using the spinlock circuit to determine whether the first shared resource is available (free/available or inUse) in response to determining the first shared resource is unavailable (inUse), sending a second notice from the spinlock circuit to the task manager circuit, the second notice indicating the first shared resource is unavailable (pg. 38-40; pg. 43) disclosing in response to the request the TRM determines whether the resource is free/available or inUse, and signals that the task is blocked waiting for the resource when it is not available.
in response to receiving the second notice, pausing (blocking) the first processor task on the processor (pg. 4, para. 3; pg. 38, last para; pg. 44) last para: “If the resource lock is granted, the task may continue executing and use the resource. If the lock is not granted, the TRM signals the scheduler to block that task from executing” (pg. 38, last para).
receiving, at the spinlock circuit, a third notice (release signal) indicating the first shared resource has become available (freed/released); sending a fourth notice from the spinlock circuit to the task manager circuit, the fourth notice (grant/ready) indicating the first resource has become available; (pg. 38, para. 1; pg. 43-45), “A release signal releases the lock held by the task by resetting the grant flag” (pg. 45, para. 1); “The ready signal alerts the task module and subsequently the scheduler that there are no outstanding resource requests that block execution” (pg. 43, para. 1).
after the first processor task is paused, using the processor to begin (e.g. responsive to an external interrupt (pg. 9) or timer tick (pg. 25)) a second processor task associated with a second shared resource [Claim 24]…wherein the second processor task has a higher priority level than the first processor task (highest priority ready task) (pg. 9; pg. 25-27; pg. 29, para. 2; pg. 33; and pg. 47) disclosing each processor of the RTP system can be associated with up to 16 tasks with respective priorities, and accordingly teaches that while a given task (first task) is blocked waiting for a resource (first shared resource) a different higher priority task (second task) can be made ready (e.g. responsive to an external interrupt (pg. 9, second para.) or timer tick (pg. 25)) and begin executing.
Issacson further discloses (pg. 9; pg. 25-27; pg. 29, para. 2; pg. 33; pg. 47) in response to receiving the signal readying the task (first task) that whose resource request was blocked the task will not be resumed if a higher priority second task is still being performed, and subsequently upon determining the higher priority task (second processor task) has completed (i.e. returned to waiting for its triggering event such as an interrupt or timer), resuming the first processor task on the first processor. But Isaacson does not disclose in response to the fourth notice [indicating the first resource has become available]…not acquiring use of the first shared resource by the first task because the TRM (pg. 43-44), in response to a locked resource being freed, hands-off ownership to the waiting task and notifies the scheduler (task manager) that the task’s lock request has been granted, and for the same reason does not disclose sending the fifth notice [requesting use of the first shared resource] from the task manager circuit to the spinlock circuit when the task resumes because it already owns the resource and does not need to re-issue the request for the resource when the task resumes.
Dice, however, describes various alternative implementations of locking protocols such as different “policies used to activate a successor thread when a thread unlocks an object” (pg. 8-9, § 3.3) including a “directed handoff” embodiment analogous to Isaacson’s implementation: “In directed handoff the unlocking thread explicitly picks a successor from the list of blocked threads, marks that thread as the owner of the object and then wakes it. The distinguished successor, by virtue of waking, knows that it owns the object” and further discloses a “competitive handoff” embodiment that teaches in response to a notice that an awaited shared resource has become available, readying/waking the waiting task without granting/acquiring use of the first shared resource and subsequently (re)requesting use of the first shared resource when the readied task resumes execution: “In competitive handoff, when a thread unlocks an object, it marks the object as available and then makes a potential successor thread (sometimes called the heir apparent) ready. The successor, upon waking up, must compete for the object like other threads.”; see also pg. 5, col. 2: “Consider a thread blocked trying to lock a monitor. After waking, the thread must recontend for a monitor…Waking up doesn’t imply ownership of a lock, but rather grants that thread an opportunity to compete for the lock. Blocking and waking threads is simply a way to avoid spinning.”
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Isaacson to employ Dice’s competitive handoff succession policy and make the waiting task (first task) ready, without granting the lock (not acquiring use of the first shared resource by the processor), upon the lock’s release and recontend/reattempt the resource lock request (fifth notice requesting use of the first shared resource) when it becomes the highest priority task and runs (resuming the first processor task on the first processor) as it represents the substitution of one known succession policy with a known alternative yielding predictable results (e.g. reduced HW logic complexity of the TRM and increased throughput in exchange for reduced fairness and determinism in relation to resource acquisition order and wait times) (Dice pg. 8-9, § 3.3).
Claims 2-4:
The combination of Isaacson/Dice discloses the limitations as shown in the rejections above. Isaacson further discloses the first processor task includes a first operation; the pausing (blocking) of the first processor task occurs at the first operation...wherein the resuming of the first processor task include changing a program counter of the processor to an address associated with the first operation in at least pg. 12-14, § 2.3-2.3.1; pg. 47; pg. 37-39, § 4; pg. 38, last para. – pg. 39, first para.
Claim 7:
The combination of Isaacson/Dice discloses the limitations as shown in the rejections above. Isaacson further discloses the processor is a first processor; the device further comprises a second processor; and the spinlock circuit is configured to determine whether the first shared resource is available based on whether the first shared resource is currently being used by the second processor (pg. 3; pg. 5; and pg. 42).
Claim 9, 27, and 28:
Isaacson discloses the limitations as shown in the following rejections:
A device comprising: a processor; a task manager circuit (scheduler + Real Time Processor (RTP) Interface) coupled to the processor; and a [spinlock circuit] (Task-Resource Matrix (TRM)) coupled to the task manager circuit (pg. 3-5; and pg. 11, Fig. 2-1).
the processor is configured to begin a first processor task associated with a first shared resource (pg. 8-9, § 2.1).
the task manager circuit is configured to send a first notice (resource control instruction) to the spinlock circuit indicating the processor is requesting use of the first shared resource; the spinlock circuit is configured to determine and communicate availability of a plurality of shared resources that includes the first shared resource and, in response to receiving the first notice, to send to the task manager circuit a second notice indicating the first shared resource is unavailable (pg. 4; pg. 5, Fig. 1-1; pg. 10, para. 2; pg. 37, para. 1-2) disclosing tasks request use of resources by executing “resource-specific control instructions in this new architecture include…lock r: Attempt to reserve system resource r.” (pg. 37) which causes the RTP interface to send a request signal to the TRM, which in turn determines whether the resource is free/available or inUse, and signals that the task is blocked from resource when it is not available (pg. 38-40; pg. 43; pg. 5, Fig. 1-1).
the task manager circuit is further configured to, in response to receiving the second notice, cause the processor to pause (block) the first processor task (pg. 4, para. 3; pg. 38, last para; pg. 44) last para: “If the resource lock is granted, the task may continue executing and use the resource. If the lock is not granted, the TRM signals the scheduler to block that task from executing” (pg. 38, last para).
the spinlock circuit is further configured to…receive a third notice (release signal) indicating the first shared resource has become available (freed/released) and send to the task manager circuit a fourth notice (grant/ready) indicating the first shared resource has become available; (pg. 38, para. 1; pg. 43-45), “A release signal releases the lock held by the task by resetting the grant flag” (pg. 45, para. 1); “The ready signal alerts the task module and subsequently the scheduler that there are no outstanding resource requests that block execution” (pg. 43, para. 1).
the processor is further configured to, after pausing the first processor task, begin (e.g. responsive to an external interrupt (pg. 9) or timer tick (pg. 25)) a second processor task associated with a second shared resource [Claim 28]…wherein the second processor task has a higher priority level than the first processor task (highest priority ready task) (pg. 9; pg. 25-27; pg. 29, para. 2; pg. 33; and pg. 47) disclosing each processor of the RTP system can be associated with up to 16 tasks with respective priorities, and accordingly teaches that while a given task (first task) is blocked waiting for a resource (first shared resource) a different higher priority task (second task) can be made ready (e.g. responsive to an external interrupt (pg. 9, second para.) or timer tick (pg. 25)) and begin executing.
Issacson further discloses (pg. 9; pg. 25-27; pg. 29, para. 2; pg. 33; pg. 47) in response to receiving the signal readying the task (first task) that whose resource request was blocked the task will not be resumed if a higher priority second task is still being performed, and subsequently upon determining the higher priority task (second processor task) has completed (i.e. returned to waiting for its triggering event such as an interrupt or timer), resuming the first processor task on the first processor. But Isaacson does not disclose in response to the fourth notice the processor is configured to not acquire use of the first shared resource because the TRM (pg. 43-44), in response to a locked resource being freed, hands-off ownership to the waiting task and notifies the scheduler (task manager) that the task’s lock request has been granted, and for the same reason does not disclose [claim 28] sending the fifth notice requesting use of the first shared resource to the spinlock circuit when the task resumes because it already owns the resource and does not need to re-issue the request for the resource when the task resumes.
Dice, however, describes various alternative implementations of locking protocols such as different “policies used to activate a successor thread when a thread unlocks an object” (pg. 8-9, § 3.3) including a “directed handoff” embodiment analogous to Isaacson’s implementation: “In directed handoff the unlocking thread explicitly picks a successor from the list of blocked threads, marks that thread as the owner of the object and then wakes it. The distinguished successor, by virtue of waking, knows that it owns the object” and further discloses a “competitive handoff” embodiment that teaches in response to a notice that an awaited shared resource has become available, readying/waking the waiting task without granting/acquiring use of the first shared resource and subsequently (re)requesting use of the first shared resource when the readied task resumes execution: “In competitive handoff, when a thread unlocks an object, it marks the object as available and then makes a potential successor thread (sometimes called the heir apparent) ready. The successor, upon waking up, must compete for the object like other threads.”; see also pg. 5, col. 2: “Consider a thread blocked trying to lock a monitor. After waking, the thread must recontend for a monitor…Waking up doesn’t imply ownership of a lock, but rather grants that thread an opportunity to compete for the lock. Blocking and waking threads is simply a way to avoid spinning.”
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Isaacson to employ Dice’s competitive handoff succession policy and make the waiting task (first task) ready, without granting the lock (not acquiring use of the first shared resource by the processor), upon the lock’s release and recontend/reattempt the resource lock request (fifth notice requesting use of the first shared resource) when it becomes the highest priority task and runs (resuming the first processor task on the first processor) as it represents the substitution of one known succession policy with a known alternative yielding predictable results (e.g. reduced HW logic complexity of the TRM and increased throughput in exchange for reduced fairness and determinism in relation to resource acquisition order and wait times) (Dice pg. 8-9, § 3.3).
Claims 10-12:
The combination of Isaacson/Dice discloses the limitations as shown in the rejections above. Isaacson further discloses the limitations of claims 10-12 under the same rationale described in the rejection(s) to claims 2-4 above.
Claims 15:
The combination of Isaacson/Dice discloses the limitations as shown in the rejections above. Isaacson further discloses the limitations of claim 15 under the same rationale described in the rejection(s) to claim 7 above.
Claims 25-26 and 29-30:
The combination of Isaacson/Dice discloses the limitations as shown in the rejections above. Regarding the limitations of claims 25-26 and 29-30 reciting wherein the processor is a first processor, and the third notice is sent to the spinlock circuit by a task manager circuit of a second processor that was performing a third processor task using the first shared resource when the first shared resource was determined to be unavailable responsive to the first notice…wherein the third notice is received after the processor begins the second processor task; as shown in the rejections above, Isaacson discloses all the individual actions recited in the limitations. Isaacson further discloses (pg. 3-5) the system is a multi-processor system that supports up to 16 processors with up to 16 tasks per processor, and the TRM controls sharing of resources between both tasks executing on the same processor and tasks on different processors “Peripherals that can be shared by two or more tasks, whether they are on a single processor or on different processors, need to be synchronized among the competing tasks. This is done using system “resources” in this architecture.” While Isaacson does not explicitly describe the specific sequence of task activations and resource releases between tasks on different processors recited in the claims, the particular sequence involving three tasks on two processors (i.e. [Processor2 – Task3 (P2-T3): Lock R1] -> [P1-T1: TryLock R1] -> [P1-T2 Run] -> [P2-T3 Release R1] represents a species that a person of ordinary skill in the art reading Isaacson would “at once envisage” being performed on Isaacson’s multiprocessor system; “a reference may still anticipate if that reference teaches that the disclosed components or functionalities may be combined and one of skill in the art would be able to implement the combination.” Blue Calypso, LLC v. Groupon, Inc., 815 F.3d 1331, 1344 (Fed. Cir. 2016) (citing Kennametal, Inc. v. Ingersoll Cutting Tool Co., 780 F.3d 1376, 1381, 1383 (Fed. Cir. 2015) (“a reference can anticipate a claim even if it ‘d[oes] not expressly spell out’ all the limitations arranged or combined as in the claim, if a person of skill in the art, reading the reference, would ‘at once envisage’ the claimed arrangement or combination”). See MPEP 2131.02; 2123.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Each of “Embedded Systems A Contemporary Design Tool”, US 20050240924 A1, and “Context Switching in OS Explained: How it Works and Unveiling its Hidden Costs”, “Blocking (computing)”, “Preemption (computing)”, US 6757897 B1, were referenced above regarding terminology used in the art.
“Compilation and Generation of Multi-Processor on a Chip Real-Time Embedded Systems” is related to reference Isaacson.
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
06/19/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights