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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 15 May 2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 4, 5, 7-9, 15-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chew (US 2017/0329729) and further in view of Pryor (US 8,339,404) and further in view of Huo (US 2023/0070224).
Regarding claim 1, Chew teaches: At least one non-transitory machine-readable medium storing instructions that, when executed by at least one machine, results in performance of operations comprising:
invoking, from a software application, a hardware accelerator library using an application programming interface (API) function (¶ 29, “issuing of a task may include invoking an application programming interface (API) of a graphics driver such that the API includes a thread identification (ID) referencing a thread”);
registering a callback function within the software application to be invoked upon completion of a hardware accelerator library operation (¶ 152, “the API call may include this additional information, such as a thread ID, a pointer to a callback function, etc” and ¶ 155, “interrupt handler 1530 may signal (or wake up) the CPU thread associated with the thread ID and passes the callback function pointer associated with the thread ID to the CPU thread”); and
accessing hardware functionality of a computing system using the hardware accelerator library (¶ 161, “when CPU 1512 needs to issue a task to GPU 1514, a CPU thread associated with CPU 1512 may invoke an API call of graphics driver 1516 to issue the task to be performed by GPU 1514”);
wherein:
the callback function is configurable to comprise an asynchronous callback function to be registered within the software application (¶ 151, “Embodiments provides for interrupt mechanism 1510 to emulate GPU callback interrupts that enable multiple CPU threads to asynchronously issue tasks to GPU 1514”);
in an event that the asynchronous callback function is registered within the software application, the software application is to perform one or more other functionalities (¶ 152, “Once the task is sent, the CPU thread may continue with performing other tasks while waiting on a signal at a point when it needs any computation results from GPU 1512 to proceed”) until (1) notification of the completion of the hardware accelerator library operation (¶ 181, “CPU thread 1851 receiving the signal and consequently, waking up at 1809, which, in turn, invokes the callback function with the memory pointer as input to callback at 1811”) and (2) generation of result data of the hardware accelerator library operation (¶ 166, “one or more CPU threads, including the CPU thread, may receive a signal, as facilitated by interrupt handler facilitation logic 1607 using interrupt handler 1530, and invoke, as facilitated by detection/invocation logic 1601, a callback function to process their respective GPU computation results”).
Chew does not teach as clearly as Pryor teaches: a hardware accelerator library (col. 2:63-67 and col. 3:1, “a programmer unfamiliar with CUDA can create a C or C++ code which interfaces with OpenGL and CG. Open GL, short for Open Graphics Library, is a lower level API, which stands for application-programmer interface which is used for creating applications that produce both two dimensional and three dimensional computer graphics”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of a hardware accelerator library, as taught by Pryor, in the same way to the invocation, as taught by Chew. Both inventions are in the field of implementing hardware acceleration, and combining them would have predictably resulted in “a processing system that directs central processing unit instructions to be executed on a graphics processing unit,” as indicated by Pryor (col. 1:16-18).
Chew and Pryor do not teach; however, Huo discloses: an agent executed by multiple nodes is to perform node registration with an API service using a hostname or a flag (¶ 35, “The kubelet is the primary “node agent” that runs on each worker node. The kubelet can register the node with the apiserver using any one or more of the hostname, a flag to override the hostname, and/or specific logic for a cloud provider”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of an agent executed by multiple nodes is to perform node registration with an API service using a hostname or a flag, as taught by Huo, in the same way to the performance operations, as taught by Chew and Pryor. Both inventions are in the field of hardware accelerators in distributed computing environments, and combining them would have predictably resulted in “automating deployment, scaling, and operations of application containers across clusters of hosts,” as indicated by Huo (¶ 2).
Regarding claim 4, Chew teaches: The at least one non-transitory machine-readable medium of claim 1, wherein the API function invokes a function of a low-level accelerator library and the low-level accelerator library invokes a corresponding hardware accelerator (¶ 128, “In some embodiments, kernel mode graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions”).
Regarding claim 5, Pryor teaches: The at least one non-transitory machine-readable medium of claim 4, wherein the low-level accelerator library is written in one of C, C++, or assembly computing language (col. 3:3-6, “CG is based roughly on the C programming language which allows a programmer to create complex graphics without having to learn a GPU assembly language”).
Regarding claim 7, Pryor teaches: The at least one non-transitory machine-readable medium of claim 1, wherein the API comprises a high-level API and high-level abstraction functions separate from the high-level API (col. 8:5-7, “a MATLAB.RTM. interface. The interface consists of a series of MATLAB.RTM. functions, known as supplemental functions,”), the high-level abstraction functions invoked by the high-level API to invoke hardware accelerator functions (col. 8:47-49, “The supplemental functions then either manipulates or returns a state associated with the GPU”).
Regarding claim 8, Chew teaches: The at least one non-transitory machine-readable medium of claim 1, further comprising batching a plurality of invocations (¶ 56, “the ring buffer can additionally include batch command buffers storing batches of multiple commands”).
Claims 9, 15-17, and 20 recite commensurate subject matter as claims 1, 5, 7, and 8. Therefore, they are rejected for the same reasons.
Claim(s) 2, 10, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chew, Pryor, and Huo, as applied above, and further in view of Maeda (US 2023/0259411).
Regarding claim 2, Pryor teaches: The at least one non-transitory machine-readable medium of claim 1, wherein the API function is to provide for auto-switching among different accelerated devices and/or central processing unit (CPU) usages (col. 7:54-57, “The system will also determine if the system has a GPU function corresponding to the CPU function about to be executed and, if so, the function is executed on the GPU 216. Otherwise, it will be executed on the CPU”).
Chew, Pryor, and Huo do not teach; however, Maeda discloses: the software application is a cloud native (CN) application and wherein the hardware accelerator library operation is asynchronous (¶ 2, “Considering the current increase in Cloud Native application development, the publication and reuse of Web APIs that utilize light RESTful web services are becoming more prevalent. In such cases, one business use case is achieved by making multiple asynchronous calls to an API”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the software application is a cloud native (CN) application and wherein the hardware accelerator library operation is asynchronous, as taught by Maeda, in the same way to the software application, as taught by Chew, Pryor, and Huo. Both inventions are in the field of making API calls, and combining them would have predictably resulted in “preventing deadlocks in application programming interface (API) calls,” as indicated by Maeda (¶ 1).
Claims 10 and 18 recite commensurate subject matter as claim 2. Therefore, they are rejected for the same reasons.
Claim(s) 3 and 11-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chew, Pryor, Huo, and Maeda, as applied above, and further in view of Balbi (US 2023/0092752).
Regarding claim 3, Chew, Pryor, Huo, and Maeda do not teach; however, Balbi discloses: the CN application source code is written in one of a high-level programming language including one of a Rust computer language or a GO computer language (¶ 28, “the compiler 230 is pre-configured to support at least the RUST and GO languages, as these languages are highly popular among API developers and managers”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the CN application source code is written in one of a high-level programming language including one of a Rust computer language or a GO computer language, as taught by Maeda, in the same way to the software application, as taught by Chew, Pryor, Huo, and Maeda. Both inventions are in the field of making API calls, and combining them would have predictably resulted in “a policy development kit for development of gateway policies,” as indicated by Balbi (¶ 1).
Claims 11-13 recite commensurate subject matter as claims 3-5. Therefore, they are rejected for the same reasons.
Claim(s) 6 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chew, Pryor, and Huo, as applied above, and further in view of Daly (US 2017/0180273).
Regarding claim 6, Chew, Pryor, and Huo do not teach; however, Daly discloses: the operations further comprise providing a data plane library corresponding to at least one hardware accelerator (¶ 15, “Data plane components can include, by way of non-limiting example, Data Plane Development Kit (DPDK) components, field programmable gate array (FPGA) components, and Red Rock Canyon (RRC)/FM10K switch components available from Intel of Santa Clara, Calif. among other components”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the operations further comprise providing a data plane library corresponding to at least one hardware accelerator, as taught by Daly, in the same way to the software application, as taught by Chew, Pryor, and Huo. Both inventions are in the field of hardware acceleration, and combining them would have predictably resulted in “hardware acceleration of data packet processing,” as indicated by Daly (¶ 1).
Claim 14 recites commensurate subject matter as claim 6. Therefore, it is rejected for the same reasons.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chew, Pryor, and Huo, as applied above, and further in view of Cai (US 2021/0152659).
Regarding claim 19, Chew, Pryor, and Huo do not teach; however, Cai discloses: the hardware functionality includes a cryptographic operation (¶ 26, “For example, the hardware accelerators can include: . . . cryptographic and/or compression functionality (e.g., secure sockets layer (SSL) acceleration);”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the hardware functionality includes a cryptographic operation, as taught by Cai, in the same way to the hardware functionality, as taught by Chew, Pryor, and Huo. Both inventions are in the field of making API calls, and combining them would have predictably resulted in “cryptographic engines,” as indicated by Cai (¶ 28).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/Primary Examiner, Art Unit 2198
Prosecution Insights