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 .
Detailed Action
Office Action is in response to the reply filed by Applicant on 5/18/2026. Claims 4, 6, 12, 14 and 20. Claims 21-25 have been added as New. Claims 1-3, 5, 7-11, 13, 15-19 and 21-25 are pending. This Office Action is Non-Final.
Response to Arguments
A) Applicant argues the rejections under 35 USC 101 for an Abstract idea are improper. Examiner respectfully disagrees. Under the - prong analysis, Step 2A is that the claims as written could be a performed using mental steps. The simple steps of receiving input data, preparing output data, computing an idle time and returning output data, are all steps which can be performed mentally by a human or with generic computers. The steps being performed can be performed by any generic computing device, therefore there is no special hardware components which would be required to perform the mental steps.
Step 2B, is that the claims do not contain any improvement to the current technology. There is no practical application of the limitations. The limitations essentially take input data and creates an output, but the presented output is not applied in any form to improve a technology. As a result, the 35 USC 101 rejection for Abstract Idea stands.
B) Applicant’s arguments with respect to claim(s) 1, 9 and 15 have been considered but are moot because the new ground of rejection does not rely on the same combination of references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5, 7-11, 13, 15-19 and 21-25 are rejected under 35 USC 101 as being directed to an abstract idea without being integrated into a practical application or being significantly more.
Regarding claims 1, 9 and 17, the claim recites the limitations “receiving, …, input data...;” “preparing,…, corresponding output data…;” “computing,…, a simulated idle time…;” and “returning, …, the corresponding output data.” Broadly interpreted, the aforementioned steps are directed to mental processes as said steps could be performed in the human mind. Therefore, the claims recite an abstract idea.
Said abstract idea and/or judicial exception is not integrated into a practical application as the claim does not recite any other active steps that could be considered that the abstract idea is being integrated into a practical application. It’s noted that the claim recites the operations “receiving input data,” “preparing an output,” and “returning an output.”
However, said operations are not sufficient to consider that the abstract idea is being interpreted into a practical application. Said operations are recited at a high level of generality in gathering/processing/storing information, which are a form of insignificant extra-solution activity.
It’s also noted that the claims recite additional limitation/elements (i.e., system, processing circuitry, processor, memory, etc.,). However, said additional elements are recited at a high-level of generality (i.e., as a generic computing device performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception or abstract idea using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements/limitations/embodiments that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. As mentioned above, although the claims recite additional elements, said elements taken individually or as a combination, do not result in the claim amounting to significantly more than the abstract idea because as the additional elements perform generic computer content distributing functions routinely used in information technology field. As discussed above, the additional elements recited at a high-level of generality such that they amount no more than mere instructions to apply the exception using a generic computer component. Therefore, the claim is directed to non-statutory subject matter.
Regarding claims 2, 3, 5, 8-11, 13, 15, 16, 18, 19 and 21-25, Claims 2, 3, 5, 8-11, 13, 15, 16, 18, 19 and 21-25 are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter for the same reasons addressed above as the claims recite an abstract idea and the claims do not positively recite any other operations that could be considered as the abstract idea is being integrated into a practical application or significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 5, 7, 9, 12-15, 17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Windh et al. (US 11,507,493) in view of Altrichter et al. (US 2010/0010799).
As per claim 1, Windh teaches a computer-implemented method for simulating performance of a hardware offloading system, comprising: receiving, by a simulator that corresponds to a simulated architecture representing the hardware offloading system, input data from a user application for processing by the simulated architecture; preparing, by the simulator, corresponding output data for the input data without computing the corresponding output data by the simulated architecture (Windh, Col. 25 Lines 3-16 recites “At operation 1130, the state information may be used to configure a software simulator. For example, the state information, the set of instructions, and the like may be loaded into the software simulator. The software simulator is a cycle-accurate hardware simulator which uses a same application programming interface (API) as the hardware HTF. At operation 1135 the set of instructions may begin executing in the software simulator at the point of the stop condition. In some examples, the hardware HTF may also resume execution if the stop condition is a breakpoint, an assertion, or some exceptions. In some examples, some exceptions may not be recoverable and thus the thread execution may terminate permanently. To resume execution the host device may send a command to the HTF to continue.” And see Fig. 11).
But fails to teach computing, by the simulator and based on a throughput metric that represents a performance of the simulated architecture, a simulated idle time related to computing the corresponding output data by the simulated architecture; and returning, by the simulator and after waiting for the simulated idle time, the corresponding output data to the user application.
However, in an analogous art Alrichter teaches computing, by the simulator and based on a throughput metric that represents a performance of the simulated architecture, a simulated idle time related to computing the corresponding output data by the simulated architecture (Alrichter, Paragraph 0044 recites “FIG. 4 illustrates a flowchart describing an algorithm used by system 2 of FIG. 1 for simulating job schedules for input/output (I/O) devices, in accordance with embodiments of the present invention. In step 402, a simulation engine (e.g., simulation engine 125 in FIG. 2) in an interface (e.g., interface 97b in FIG. 2) located in a device driver (e.g., device driver 99b in FIG. 2) receives runtime behavior data associated with the device driver. In step 404, the simulation engine receives input simulation parameters data associated with a simulation process from a simulator software application (e.g., simulator 101 in FIG. 2). In step 408, the simulation engine receives device specific parameters data for a device (e.g., optical drive 103) associated with the device driver. In step 410, the simulation engine calculates (i.e., in response to receiving the input simulation parameters data and the device specific parameters data) a simulated scale down process time period for the device. The calculation for the simulated scale down process time period is based on the device specific parameters data, the input simulation parameters data, and the runtime behavior data.”);
and returning, by the simulator and after waiting for the simulated idle time, the corresponding output data to the user application (Alrichter, Paragraph 0044 recites “In step 412, the simulation engine disables communications between the simulation engine and the simulator software application. Step 412 is executed during the simulated scale down process time period. In optional step 414, a device response time for a specific operation associated with the device is calculated. In optional step 418, permission to perform a simulation is received by the simulation engine. The permission may be received from an administrator. In step 422, the simulation engine performs the simulation process. In optional step 425, the simulation receives data comprising historical information associated with past operations of the device. In step 428, simulation engine (i.e., during simulation process) calculates an overall runtime period for the device. The calculation for the overall runtime period is based on the simulated scale down process time period and optionally the historical information optionally received in step 425. In step 432, (i.e., after the simulated scale down process time period has expired) the simulation engine enables communications between the simulation engine and the simulator software application. In step 438, simulation engine transmits the overall runtime period to the simulator software application for generating an operating schedule for operating the device. In optional step 442, verification data (i.e., specifying that the simulator software application has received the overall runtime period) may be received by the simulation engine. The process may be repeated for different devices.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Altricher’s device simulation method and system with Windh’s Debugging Dataflow Computer Architectures because it offers the advantage of a more accurate process with flexibility for when preparing data.
As per claim 5, Windh in combination with Altrichter teaches the computer-implemented method of claim 1, Windh further discloses wherein the simulated idle time is a function of the throughput metric and a size of the input data (Windh, Col. 25 Lines 3-16 recites “At operation 1130, the state information may be used to configure a software simulator. For example, the state information, the set of instructions, and the like may be loaded into the software simulator. The software simulator is a cycle-accurate hardware simulator which uses a same application programming interface (API) as the hardware HTF. At operation 1135 the set of instructions may begin executing in the software simulator at the point of the stop condition. In some examples, the hardware HTF may also resume execution if the stop condition is a breakpoint, an assertion, or some exceptions. In some examples, some exceptions may not be recoverable and thus the thread execution may terminate permanently. To resume execution the host device may send a command to the HTF to continue.” An instruction set would be the size of the input. And see Fig. 11).
As per claim 7, Windh in combination with Altrichter teaches the computer-implemented method of claim 1, Windh further teaches wherein the simulator is executed by a first processor, and wherein the simulated architecture is associated with one or more second processors having a higher performance parameter than the first processor. (Windh, Col. 24 Lines 11-27 recites “FIG. 10 illustrates a logical diagram of obtaining state information of the tiles 1043 of an HTF 1042 according to some examples of the present disclosure. Memory device 1012 may be an example of a memory device 112 shown in FIG. 1; host 1008 may be an example of host system 108 of FIG. 1; HTF 1042 may be an example of HTF 142 of FIG. 1; and host processor 1022 may be an example of host processor 122 of FIG. 1. Tiles 1043 may execute one or more threads of instructions programmed by the host 1008. A control and status register (CSR) read request 1023 is sent by a memory interface processor 1011 of host 1008. This may be the result of a request from a simulator environment 1021, or may be sent automatically upon being notified of a stoppage of execution of one or more threads of instructions programmed by the host 1008.”).
Regarding claims 9 and 17, claims 9 and 17 are directed to an apparatus and a non-transitory computer-readable storage media associated with the method of claim 1. Claims 9 and 17 are of similar scope to claim 1, and are therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed to a similar apparatus associated with the method of claim 5 respectively. Claim 13 is similar in scope to claim 5, respectively, and are therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a similar apparatus associated with the method of claim 7 respectively. Claim 15 is similar in scope to claim 7, respectively, and are therefore rejected under similar rationale.
Claim(s) 2, 10 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Windh et al. (US 11,507,493) and Altrichter et al. (US 2010/0010799) and in further view of Gasser et al. (US 11,226,885).
As per claim 2, Windh in combination with Altrichter teaches the computer-implemented method of claim 1, but fails to teach wherein preparing the corresponding output data includes retrieving the corresponding output data from a memory, wherein the corresponding output data is computed during a previous run of the simulator and stored in the memory.
However, in an analogous art Gasser teaches wherein preparing the corresponding output data includes retrieving the corresponding output data from a memory, wherein the corresponding output data is computed during a previous run of the simulator and stored in the memory (Gasser, Col. 22 Lines 35-54 recites “At circle E, the distributions comparator 1010 transmits a request to the MCSS 130 to perform a simulation based on the new input distribution (e.g., via an API call as described above with reference to FIG. 4). In some embodiments, the request is to create a new template or a new version of a template specified with the template identifier(s) associated with the distributions comparator 1010 during configuration (e.g., via an API call as described above with reference to FIG. 2). In some embodiments, the MCSS 130 returns a new template identifier associated with the new or updated template. At circle F, the MCSS 130 creates a new template based on the existing template identified with the template identifier that has an updated location for the new input data distribution (e.g., either in the input distributions data store 315 or in the buffer data store 1005). The MCSS 130 then performs the Monte Carlo simulation as indicated by circles G and H-sampling, processing, and outputting an output data distribution to the output distributions data store 415 based in part on the new input distribution.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Gasser’s Monte Carlo Simulation Monitoring And Optimization with Windh’s Debugging Dataflow Computer Architectures because it offers the advantage of using history data to help compare new simulated data.
Regarding claims 10 and 18, claims 10 and 18 are directed to an apparatus and a non-transitory computer-readable storage media associated with the method of claim 2. Claims 10 and 18 are of similar scope to claim 2, and are therefore rejected under similar rationale.
Claim(s) 8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Windh et al. (US 11,507,493) and Altrichter et al. (US 2010/0010799) and in further view of Dubash (US 2023/0010063).
As per claim 8, Windh in combination with Altrichter teaches the computer-implemented method of claim 1, but fails to teach receiving a direct memory access (DMA) information from the user application, wherein returning the corresponding output data to the user application is by DMA to the user application.
However, in an analogous art Dubash teaches receiving a direct memory access (DMA) information from the user application, wherein returning the corresponding output data to the user application is by DMA to the user application (Dubash, Paragraph 0060 recites “Similarly, the second peripheral system 530 contains elements that are being controlled/tested, responsive to signals produced by the second peripheral component 528. The processor 504 of the main computing system 502 processes signal data that it reads from the first dedicated memory space 510, and uses that signal data to generate additional signal data that it writes into the second dedicated memory space 512. In particular, there are a plurality of output values produced by the simulation application program being executed by the processor 504, and each one of these is written to an assigned location in the second dedicated memory space 512. The local processor of the second peripheral component 528 operates a DMA engine 536 that can directly access the second dedicated memory space 512, and write data from the second dedicated memory space 512 into corresponding locations in the local memory 534 of the second peripheral component 528.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Dubash’s method and apparatus for cloning data among peripheral components and a main system with Windh’s Debugging Dataflow Computer Architectures because it offers the advantage of minimizing the CPU’s involvement in data transfers, which can lead to a more efficient use of processing resources.
Regarding claim 16, claim 16 is directed to a similar apparatus associated with the method of claim 8 respectively. Claim 16 is similar in scope to claim 8, respectively, and are therefore rejected under similar rationale.
Claim(s) 3, 11, 19, 21, 23 and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Windh et al. (US 11,507,493), Altrichter et al. (US 2010/0010799) and Gasser et al. (US 11,226,885) and in further view of Su et al. (US 2025/0077740).
As per claim 3, Windh in combination with Altrichter and Gasser teaches the computer-implemented method of claim 2, but fails to teach wherein the corresponding output data is mapped, in the memory, to the input data during the previous run of the simulator, and wherein preparing the corresponding output data includes retrieving the corresponding output data that is mapped to the input data.
However, in an analogous art Su teaches wherein the corresponding output data is mapped, in the memory, to the input data during the previous run of the simulator, and wherein preparing the corresponding output data includes retrieving the corresponding output data that is mapped to the input data (Su, Paragraph 0091 recites “The CLI model implemented in the CLI simulator 348 maps feature patterns of command inputs to corresponding CLI responses or outputs. Thus, the CLI simulator 348 simulates the response of the CLI interpreter in response to the command and options if any, and returns a result. In some cases, the command and options may not be supported by the particular OS and CLI interpreter, in which case the CLI simulator 348 may return a result indicating that the particular command and/or option(s) are not supported and providing additional assistance as to which commands and/or option(s) are supported, e.g., a listing of supported options.”)
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Su’s Artificial Intelligence Simulation Of Operating Systems And Command-Line-Interfaces For Operating Systems And Optimization with Windh’s Debugging Dataflow Computer Architectures because it offers the advantage of improved computing tool and improved computing tool operations/functionality for artificial intelligence simulation.
Regarding claims 11 and 19, claims 11 and 19 are directed to an apparatus and a non-transitory computer-readable storage media associated with the method of claim 3. Claims 11 and 19 are of similar scope to claim 3, and are therefore rejected under similar rationale.
As per claim 21, Windh in combination with Altrichter, Gasser and Su teaches the computer-implemented method of claim 3, but fails to teach further comprising, during the previous run of the simulator: generating, by the simulator, the corresponding output data based on the input data; and mapping the input data to the corresponding output data in a map structure, wherein retrieving the corresponding output data includes retrieving the corresponding output data that is mapped to the input data in the map structure (Su, Paragraph 0091 recites “The CLI model implemented in the CLI simulator 348 maps feature patterns of command inputs to corresponding CLI responses or outputs. Thus, the CLI simulator 348 simulates the response of the CLI interpreter in response to the command and options if any, and returns a result. In some cases, the command and options may not be supported by the particular OS and CLI interpreter, in which case the CLI simulator 348 may return a result indicating that the particular command and/or option(s) are not supported and providing additional assistance as to which commands and/or option(s) are supported, e.g., a listing of supported options.”)
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Su’s Artificial Intelligence Simulation Of Operating Systems And Command-Line-Interfaces For Operating Systems And Optimization with Windh’s Debugging Dataflow Computer Architectures because it offers the advantage of improved computing tool and improved computing tool operations/functionality for artificial intelligence simulation.
Regarding claims 23 and 25, claims 23 and 25 are directed to an apparatus and a non-transitory computer-readable storage media associated with the method of claim 21. Claims 23 and 25 are of similar scope to claim 21, and are therefore rejected under similar rationale.
Claim(s) 22 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Windh et al. (US 11,507,493) and Altrichter et al. (US 2010/0010799) and in further view of Mathur et al. (US 2019/0317589).
As per claim 22, Windh in combination with Altrichter teaches the computer-implemented method of claim 1, but fails to teach wherein the simulator
corresponds to a first architecture that is based on a central processing unit (CPU), and wherein the simulated architecture is based on one or more hardware-based accelerators.
However, in an analogous art Mathur teaches wherein the simulator
corresponds to a first architecture that is based on a central processing unit (CPU), and wherein the simulated architecture is based on one or more hardware-based accelerators (Mathur, Paragraph 0023 recites “FIG. 4 is an example embodiment 400 for a system simulator level application where the idle-loop execution optimization techniques described herein are employed in simulated user applications. A system simulator is a software program that emulates the behavior of a target system including processors, accelerators, peripherals, and/or other features to provide a tool for system architecture exploration, software development, and debug. For embodiment 400, simulated software instructions are executed by one or more simulated CPUs 406 to run one or more simulated applications 402 on top of a simulated operating system 404. The loop optimization 410 described herein is applied to the one or more simulated CPUs 406 to detect an idle loop 401 entered by a code segment within the simulated software instructions being executed by the one or more simulated CPUs 406. In addition to the one or more simulated CPUs 406, the system simulator 420 for the embodiment 400 includes a hardware accelerator model 412, a hardware peripheral model 408, an input-output port model (IO) 414, and a memory model 418 (e.g., random access memory (RAM)). These model components of the system simulator 420 communicate with each other through an interconnect bus model 416. In addition, software instructions are executed by one or more CPUs 426 to run the system simulator 420 on top of an operating system 422. The system hardware 440 for the embodiment 400 includes the one or more CPUs 426, hardware accelerators 432, hardware peripherals 428, input-output ports (IO) 434, and memory 438 (e.g., random access memory (RAM)). These components of the system hardware 440 communicate with each other through a system interconnect bus 436, which can include one or more different electrical bus connections among the various components of the system hardware 440.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Mathur’s Idle Loop Detection And Control For Processors with Windh’s Debugging Dataflow Computer Architectures because it offers the advantage of processing speed.
Regarding claim 24, claim 24 is directed to an apparatus associated with the method of claim 22. Claim 24 is of similar scope to claim 22, and are therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, Luu Pham can be reached at 571-270-5002. 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.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/Primary Examiner, Art Unit 2439
Prosecution Insights