DETAILED ACTION
This Office Action is in response to claims filed on 02/09/2026.
Claims 1-21 are pending.
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, see page 8 of applicant's remarks, filed 02/09/2026, with respect to the 112(b) rejection of claims 1-21 have been fully considered and are persuasive. The rejection of 12/17/2025 has been withdrawn.
Applicant’s arguments with respect to claims 1 and 21 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.
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, 10-12, 15-17, 19, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Waskiewicz et al. Pub. No. US 2020/0274952 A1 (hereinafter Waskiewicz) in view of Shajit et al. Patent No. US 9,880,953 B2 (hereinafter Shajit) in view of Dutu et al. Pub. No. US 2020/0004586 A1 (hereinafter Dutu).
With regard to claim 1, Waskiewicz teaches a network device ([0017], Referring now to FIG. 1, a system 100 for processing programming flexible accelerated network packet processing includes multiple computing devices 102 in communication over a network 104), comprising:
a network interface to receive first packets from a network and send packets over the network ([0017], Each computing device 102 includes network interface controller (NIC) that may perform accelerated offloads for certain network packet processing tasks … The NIC 132 performs accelerated processing (i.e., performs one or more hardware offloads) on incoming network packets and returns the results of that processing as metadata); and
packet processing hardware to ([0017], In use, as described further below, the computing device 102 may compile a packet processing program, such as an eBPF, into a binary executable or loadable file):
process a packet ([0017], The NIC 132 performs accelerated processing (i.e., performs one or more hardware offloads) on incoming network packets, and returns the results of that processing as metadata);
accelerate activation, including wakeup, of a software program in hardware by performing at least one activation task of the software program ([0017], The binary file includes a section that defines one or more requested offload hints that were specified in the eBPF program source. An offload hint is a requested hardware offload of one or more operations … The computing device 102 loads the binary file reads the section with the requested offload hints, and provides those requested offload hints to a NIC driver. The NIC driver translates those requested hints into a hardware configuration specific to the NIC 132 and programs the NIC 132 accordingly) …;
generate an interrupt to [provide offload hints to] request a processing unit to execute the software program to perform processing associated with the packet ([0043], The requested offload hints may be provided using any appropriate application programming interface (API), kernel interface, or other technique for passing information from the operating system 208 (e.g., an operating system kernel) to the NIC driver 216); and
the processing unit to execute the software program and perform processing associated with the packet, responsively to the at least one activation task performed by the packet processing hardware ([0044], the computing device 102 processes a network packet buffer with the eBPF program 215 using one or more offload hints provided by the NIC 132 … the computing device 102 may just-in-time (JIT) compile, interpreter, otherwise execute the eBPF program 214 with the packet processing virtual machine 212).
However, Waskiewicz does not explicitly teach generation of an interrupt to request a processing unit to execute a software program associated with performing processing of a particular packet.
Shajit teaches generate an interrupt to request a processing unit (Col. 6, In the example illustrated in FIG. 2 processor 202 includes processing cores 204A-204N. Each of cores 204A-204N may be an independent central processing unit (CPU) capable of retrieving and processing instructions, code, and/or data structures. In one example, a processor may include two or up to 64 cores. As described in detail below, a core may receive an interrupt when data is received from or sent to a network. Each of the cores 204A-204N may be configured to handle interrupts according the techniques described below)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Shajit with the teachings of Waskiewicz in order to provide a device that teaches generation of an interrupt request to a processing unit. The motivation for applying Shajit teaching with Waskiewicz teaching is to provide a device that applies the known methods of interrupt requests processor signaling with the known method of requesting execution of software program associated with a packet through a communication interface in order to yield the predictable result. Waskiewicz and Shajit are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Shajit with Waskiewicz to teach the claimed invention in order to provide interrupt requesting to initiate execution of a software program.
However, Waskiewicz and Shajit do not explicitly teach performance of memory and scheduling setup for executing the software program by a processing unit.
In a similar field of endeavor, Dutu teaches accelerate activation ([0015], FIGS. 1-9 disclose embodiments of techniques for reducing the latency incurred by workgroup preemption by prefetching contexts of workgroups into registers of processor cores based on hints received in wait instructions from preempted workgroups.), including wakeup ([0015], Some embodiments of the hint also indicate whether a single waiting workgroup is to be woken up in response to the signal having the value indicated in the wait instruction or multiple waiting workgroups are to be woken up.), of a software program in hardware by performing at least one activation task of the software program ([0026], A workgroup 325 (Examiner notes: software program) has been preempted from execution on the SIMD unit 305 and is waiting to resume execution on the SIMD unit 305. The workgroup 325 resumes execution in response to a signal acquiring a value.), the at least one activation task including at least one of (i) memory setup for executing the software program by a processing unit ([0026], Prior to the workgroup 325 resuming execution, a context for the workgroup 325 is prefetched from system memory 340 into another portion 345 of the set of registers 320 (Examiner notes: Hardware-based cache prefetching). The prefetched context is therefore available in the registers 320 prior to workgroup 325 resuming execution, which reduces the latency required to preempt the workgroup 310 and resume execution of the workgroup 325.), and (ii) scheduling for executing the software program by the processing unit ([0027], Execution of the waiting workgroup 325 has therefore been resumed on the SIMD unit 305 based on the context stored in the portion 345 of the set of registers 320. The scheduler 330 scheduled the workgroup 325 for execution of the SIMD unit 305 in response to detecting that the signal acquired the value associated with the waiting workgroup 325.)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Dutu with the teachings of Waskiewicz and Shajit in order to provide a system that teaches accelerate activation of a software program by performing memory and scheduling setup. The motivation for applying Dutu teaching with Waskiewicz and Shajit teaching is to provide a system that allows for proactive restoration of saved workloads such that enables reduces the overhead latency incurred by switching workload contexts and increase the throughput of compute resources (Dutu, [0014]). Waskiewicz, Shajit, and Dutu are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Dutu with Waskiewicz and Shajit to teach the claimed invention in order to provide software activation acceleration by proactively preparing memory and processing resources for software execution.
With regard to claim 2, Waskiewicz teaches wherein:
the software program has a predetermined runtime ([0017], The NIC performs accelerated processing (i.e., performs one or more hardware offloads) on incoming network packets and returns the results of that processing as metadata (Examiner notes: The performance of a packet processing algorithm results in the return of an object upon program completion such that it would be understood that the program maintains a deterministic and bounded execution flow such that the program must terminate at a known point);
the processing unit is to execute the software program until completion of the software program and return control of processing the packet to the packet processing hardware ([0029], The NIC 132 is configured to process a network packet in response to being programmed with hardware configuration associated with the requested offload hints. The NIC 132 is further configured to return metadata based on the requested offload hints and generated in response to processing the network packet to the processor 120 (e.g., to the NIC driver 216, the operating system 208, and/or other components of the computing device 102); and
the packet processing hardware is to continue to processing the packet responsively to the completion of the execution of the software program ([0030], The packet processing program 214 is configured to perform a packet processing action based on the metadata returned from the NIC; [0046], After performing the packet processing action, the method 600 loops back to block 608 to continue processing packet buffers).
With regard to claim 3, Waskiewicz teaches wherein:
the packet processing hardware is to match data associated with the packet to an action responsively to at least one match-and-action table ([0030], The packet processing program 214 is configured to perform a packet processing action based on the metadata returned from the NIC 132. The packet processing action may include dropping a packet, forwarding a packet to a device or interface, modifying a packet (e.g., encapsulating, de-encapsulating the packet), or performing another packet processing action. For example, in an embodiment in which the metadata includes a match rule identifier provided by the NIC 132, performing the packet processing action may include selecting the packet processing action as a function of the match rule identifier;); and
the action indicates details about execution of the software program ([0038], In some embodiments, in block 406 the requested offload hints may include one or more packet classification offloads … For packet matching, the retuned hint may include a software-defined identifier associated with each matching rule. In some embodiments, in block 408 the requested offload hints may include one or more hashing offloads. For example, hashing offloads may include calculating a hash value over certain fields of the network packet and a key. The requested offload hints may specify the input fields, the hash function, the key, or other parameters of the hashing offload. In some embodiments, in block 410, the requested offload hints may include one or more checksum/CRC offloads. For example, checksum offloads may include calculating a whole-packet checksum or CRC value).
With regard to claim 4, Waskiewicz teaches wherein the details about the software program include any one or more of the following ([0035], the eBPF program 214 performs a packet processing function acting based on the hints received from the NIC 12): a program identifier of the software; control parameters for use in executing the software program; address space information for use in executing the software program; and a stack identifier of a stack region for use in executing the software program ([0035], Actions performed by the eBPF program 214 may include forwarding or dropping packets, modifying packets, rate limiting or other QoS actions, load balancing, or other network packet processing actions. For example, the eBPF program 214, executed in connection with the eBPF virtual machine 212 of the operating system 208, may use metadata provided by the NIC 132 as a parameter of an action, select an action as a function of metadata provided by the NIC 132, or otherwise perform a packet processing action based on metadata returned by the NIC 132).
With regard to claim 7, Waskiewicz teaches wherein the packet processing hardware includes activation context builder hardware to translate data in the action to data readable by the processing unit ([0048], In block 706, the computing device 102 translates the requested offload hints into hardware configuration appropriate for the NIC 132. The hardware configuration may be embodied as hardware instructions, register settings, or any other hardware configuration that instructs the NIC 132 to perform the requested hardware offloads).
With regard to claim 10, Shajit teaches wherein the packet processing hardware includes scheduler hardware to (Col. 1, the techniques described herein may utilize a dynamic scheduler function that can be applied to any emerging heterogenous multi-core processor system which employs an interrupt driven I/O mechanism):
track use of the processing unit including finding a free hardware thread of the processing unit (Col. 14, As described above, application identifier module 602 may constantly monitor and update the status of applications. In a similar manner, in order to adapt to ever changing characteristics of a network, IO steering module 604 may continually monitor parameters, (e.g., CPU.sub.usr, CPU.sub.irq, CPU.sub.sys, CPU.sub.sirq, and/or CPU.sub.idle) to dynamically adapt its steering strategy. A steering algorithm may ensure that during the steering process, the I/O interrupts and tasks do not overload a new CPU subset which it is newly assigned to);
maintain a list of pending software program execution requests (Col. 3, It should be noted that the Linux operating system includes mechanisms called Receive Packet Steering (RPS) and Transmit Packet Steering (XPS). Each of RPS and XPS forward network packets to individual CPU queues for processing);
provide activation data for the software program to the processing unit (Col. 10, After a frame has been written to the host buffer a software interrupt (e.g., a Linux Soft IRQ) may be scheduled and a frame may be processed at a host level. That is, upper layer frame processing may be performed. A software interrupt may cause the kernel to process packets included in a frame … In the example illustrated in FIG. 4, a socket reads a frame from the host buffer, processes a frame, and provides the data (Examiner notes: activation data) from the frame to an application.); and
generate the interrupt to request the processing unit to execute the software program on the free hardware thread based on activation data provided by the scheduler hardware to the processing unit (Col. 13, In one example, in order to determine which core or subset of cores should handle interrupts, an interrupt steering algorithm determines the total resources in use for a core. As described above, in one example, the total resources in use for a core may be determined by calculating the total CPU cycles consumed by all the tasks currently utilizing the CPU resources. The algorithm may then steer interrupts and/or tasks to a single or subset of cores, e.g., if the resource utilization is less than the utilization of the core that the process is currently residing on).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Shajit with the teachings of Waskiewicz and Dutu in order to provide a device that teaches packet processing hardware comprising a software program scheduler. The motivation for applying Shajit teaching with Waskiewicz and Dutu teaching is to provide a device that allows for a scheduler to steer I/O request to proper CPU paths in order to obtain the benefit of increasing processing efficiency (Col. 3, Shajit). Waskiewicz, Dutu, and Shajit are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Shajit with Waskiewicz and Dutu to teach the claimed invention in order to provide scheduling for packet processing.
With regard to claim 11, Waskiewicz teaches wherein the activation data includes any one or more of the following: a program identifier of the software program; a stack identifier of a stack region for use in executing the software program; address space information for use in executing the software program; control parameters for use in executing the software program; and a pointer to data of at least part of the packet being processed by the packet processing hardware ([0035], Actions performed by the eBPF program 214 may include forwarding or dropping packets, modifying packets, rate limiting or other QoS actions, load balancing, or other network packet processing actions. For example, the eBPF program 214, executed in connection with the eBPF virtual machine 212 of the operating system 208, may use metadata provided by the NIC 132 as a parameter of an action, select an action as a function of metadata provided by the NIC 132, or otherwise perform a packet processing action based on metadata returned by the NIC 132).
With regard to claim 12, Waskiewicz teaches wherein:
the processing unit comprises multiple processing cores ([0019], The processor 120 may be embodied as any type of processor capable of performing the functions described herein. The processor 120 is illustratively a multi-core processor, however, in other embodiments the processor 120 may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit)
However, Waskiewicz does not explicitly teach a scheduler tracking use of processing cores and generating interrupts to such processing cores.
Shajit teaches the scheduler hardware is to (Col. 1, the techniques described herein may utilize a dynamic scheduler function that can be applied to any emerging heterogenous multi-core processor system which employs an interrupt driven I/O mechanism):
track use of the processing cores (FIG. 6, Workload Profiling Module 606 performs processing core tracking; Col. 12, lines 25-27, As illustrated in FIG. 7, IO steering module 604 includes workload profiling module 606 and network IO steering module 608; Col. 12, lines 48-55, In the example illustrated in FIG. 6, each of these types of profiling information are used to determine the total resources in use for a core (e.g, CoreA 95% and CoreN 40%). Further, as illustrated in FIG. 6, the total resources in use due to network processing may be determined); and
generate the interrupt to a one of the processing cores having the free hardware thread (Col. 9-Col. 10, FIG. 4 illustrates an example where a frame is received by computing device 200 or routing device 300. As illustrated in FIG. 4, network interface controller receives a frame (e.g., an Ethernet frame on a wire). Network interface controller writes the frame to network interface controller buffer. Network interface controller then asserts a hardware interrupt (e.g., a Linux Hard IRQ) to indicate the presence of a frame; Col. 13, lines 34-40, As illustrated in FIG. 8, hardware interrupts are disabled on core A. Thus, when a hardware interrupt is generated due to a frame being received by NIC, the hardware interrupts core N and not core A. In this manner, as illustrated in FIG. 8, core A may resume task processing, uninterrupted, while hardware interrupts are handled by core N (Examiner notes: such that an interrupt is directed to an available processor).
Rationale to claim 10 applied here.
With regard to claim 15, it is a computing network device having similar limitations to claim 10. Thus, claim 15 is rejected for the same rationale as applied to claim 10.
With regard to claim 16, it is a computing network device having similar limitations to claim 4. Thus, claim 16 is rejected for the same rationale as applied to claim 4.
With regard to claim 17, it is a computing network device having similar limitations to claim 12. Thus, claim 17 is rejected for the same rationale as applied to claim 12.
With regard to claim 18, Waskiewicz teaches the packet processing hardware is to invoke the processing unit successively multiple times for the packet to execute at least one software program to perform processing associated with the packet (Fig. 6, 608 Process Packet buffer with eBPF program using offload hints can be repeated; [0046], After performing the packet processing action, the method 600 loops back to block 608 to continue processing packet buffers. In some embodiments, the method 600 may restart at block 602 to reload the ELF binary file 206 and reconfigure the NIC); and
the processing unit is to successively execute the at least one software program and perform processing associated with the packet (Fig. 7, 710 Copy metadata received from NIC into packet buffer can be repeated; In those embodiments, the NIC driver 216 may prepend the metadata to received network packet data inside of a packet buffer that is processed by the eBPF program 214. After copying the metadata, the method 700 may loop back to block 710 to continue copying metadata for subsequent packets).
With regard to claim 19, Shajit teaches wherein processing unit is to execute a kernel on which to execute the software program (Col. 8, As illustrated in FIG. 3, system memory 306 includes kernel 308, host buffer 314, and applications 316 stored thereon. Kernel 308 may be configured to facilitate the processing of instructions by processor; Col. 10, A software interrupt may cause a kernel to process packets included in a frame).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Shajit with the teachings of Waskiewicz and Dutu in order to provide a device that teaches execution of a software program occurring on a kernel. The motivation for applying Shajit teaching with Waskiewicz and Dutu teaching is to provide a device that allows for an interface to distinguish user and system resource spaces and facilitates instruction processing (Col. 8 and Col. 10, Shajit). Waskiewicz, Dutu, and Shajit are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Shajit with Waskiewicz and Dutu to teach the claimed invention in order to provide a kernel to execute a software program.
With regard to claim 21, Waskiewicz teaches a networking method ([0031], Referring now to FIG. 3, in use, the computing device 102 may execute a method 300 for programming accelerated network packet processing)
Claim 21 is a computer networking method having similar limitations to claim 1. Thus, claim 21 is rejected for the same rationale as applied to claim 1.
Claims 5-6, 8-9, and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Waskiewicz in view of Shajit as applied to claim 1, 3, 4 above, and further in view of Rozas et al. Patent No. US 8,522,253 B1 (hereinafter Rozas).
With regard to claim 5, Rozas teaches wherein the address space information indicates a global virtual machine identifier (GVMI) region of the given software program (Col. 5, Embodiments of the present invention allows a single bit of global-page indicator to be multiplexed along multiple machine images or virtual machines, so that each machine image has its own set of ‘global pages’ with hardware support for fast context switching. In the FIG. 3, embodiment, the TLB or cache entries and page table entries each comprise a virtual address tag, a payload, a global indicator, a context identifier, and a validity indicator, as shown in FIG. 2 and FIG. 3, and the global indicator comprises a global bit).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Rozas with the teachings of Waskiewicz, Shajit, and Dutu in order to provide a device that teaches global virtual machine memory region associated with a software program. The motivation for applying Rozas teaching with Waskiewicz, Shajit, and Dutu teaching is to provide a device that allows for a region in address space to ensure consistent access to virtual machine states across multiple software programs and supports context isolation (Col. 1, Rozas). Waskiewicz, Shajit, Dutu and Rozas are analogous art directed towards allocation of computer resources. Therefore, it would have been obvious for one of ordinary skill in the art to combine Rozas with Waskiewicz, Shajit, and Dutu to teach the claimed invention in order to provide global virtual machine address-space regions for application execution.
With regard to claim 6, Rozas teaches wherein GVMI region is shared by multiple software programs and the GVMI region is sub-divided among the software programs (Col. 5, As the logic depicted in FIG. 3 shows, a match 310 occurs only when the virtual address tags match and the TLB or cache entry is valid. If the TLB or cache entry has the global bit clear (e.g., marked not global), the entry’s context-ID field must match the per-process application context-ID field 301 of the context-ID register. If the TLB or cache entry has the global bit set (E.g., marked global), the entry’s context-ID field 311 must match the machine-instantiation virtual machine ID field 302).
Rationale to claim 5 applied here.
With regard to claim 8, Rozas teaches wherein the packet processing hardware includes memory setup hardware to configure a translation lookaside buffer (TLB) based on address space information indicated in the action (Col. 6, As described above, in one embodiment, TLB or cache entries can be marked as global across multiple virtual machines. In such an embodiment, an additional indicator/bit can be incorporated (e.g., the cross-machine global indicator, or CM global) that would mark a TLB or cache entry as being global across multiple virtual machines.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Rozas with the teachings of Waskiewicz, Shajit, and Dutu in order to provide a device that teaches translation lookaside buffer associated with an address space. The motivation for applying Rozas teaching with Waskiewicz, Shajit, and Dutu teaching is to provide a device that allows for a TLB to maintain relevant entries across a plurality of different applications executing within different contexts thereby improving operation performance and reducing TLB flushes (Col. 4, Rozas). Waskiewicz, Shajit, Dutu and Rozas are analogous art directed towards allocation of computer resources. Therefore, it would have been obvious for one of ordinary skill in the art to combine Rozas with Waskiewicz, Shajit, and Dutu to teach the claimed invention in order to provide a translation lookaside buffer configured for application execution.
With regard to claim 9, Rozas teaches wherein the packet processing hardware includes memory setup hardware to configure memory access permissions based on control parameters and address space information indicated in the action (Col. 7, In step 603, virtual address to physical address translation is provided for each of the applications and for the operating system using host machine hardware support. In step 604, a plurality of cache entries are stored for each of the applications and for the operating system using host machine hardware support. One or more of these entries are tagged as such that they are global across the applications and across the operating system and one or more of these entries are tagged such that they are local, specific to one of the applications).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Rozas with the teachings of Waskiewicz, Shajit, and Dutu in order to provide a device that teaches memory access permissions associated with an address space. The motivation for applying Rozas teaching with Waskiewicz, Shajit, and Dutu teaching is to provide a device that allows for memory regions ensure access permissions to ensure a predictable isolated execution environment and prevent cross-context interference (Col. 5, Rozas). Waskiewicz, Shajit, Dutu and Rozas are analogous art directed towards allocation of computer resources. Therefore, it would have been obvious for one of ordinary skill in the art to combine Rozas with Waskiewicz, Shajit, and Dutu to teach the claimed invention in order to provide memory access permission regions configured for application execution.
With regard to claim 13, it is a computing network device having similar limitations to claim 8. Thus, claim 13 is rejected for the same rationale as applied to claim 8.
With regard to claim 14, it is a computing network device having similar limitations to claim 9. Thus, claim 14 is rejected for the same rationale as applied to claim 9.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Waskiewicz in view of Shajit in view of Dutu as applied to claim 1 above, and further in view of Gokam et al. Patent No. US 10,353,714 B1 (hereinafter Gokam).
With regard to claim 20, Gokam teaches wherein processing unit is to execute the given software program without an underlying kernel (Col. 3, The applications 115 may comprise different types of applications such as bare metal applications, container applications, virtual machine application which execute on virtual machines, or any combination of different types of applications).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Gokam with the teachings of Waskiewicz, Shajit, and Dutu in order to provide a device that teaches a processing unit capable of executing bare metal applications. The motivation for applying Gokam teaching with Waskiewicz, Shajit, and Dutu teaching is to illustrate that software applications include bare-metal applications that are known to execute directly on processing hardware and therefore represent a simple substitution of processing hardware executing a software program without an underlying kernel, yielding predictable results. Waskiewicz and Shajit and Gokam are analogous art directed towards software program arrangement. Therefore, it would have been obvious for one of ordinary skill in the art to combine Gokam with Waskiewicz and Shajit to teach the claimed invention in order to provide a processing unit capable of executing bare metal applications.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Context-Aware TLB Preloading for Interference Reduction in Embedded Multi-Tasked Systems
teaches
Abstract, We present a methodology for task-aware D-TLB interference reduction and preloading through an application-specific task’s state introspection at context-switch time for embedded multitasking. The proposed technique addresses the problem through a synergistic cooperation between the compiler, for an application-specific analysis of the task’s context, and the OS for a run-time introspection of the context and efficient identification of TLB entries of current (live) and of “near-future” usage.
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 IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights