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 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 Objections
Claims 1, 9, and 17 are objected to because of the following informalities: An article is missing – claim 1 is interpreted as “in an event that the asynchronous callback function . . . .” Appropriate correction is required.
Claim 18 is objected to because of the following informalities: An article is missing – claim 18 is interpreted as “wherein a hardware accelerator library operation is asynchronous with the API function.” Appropriate correction is required.
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 Gibbs (US 9,424,089) and further in view of Pryor (US 8,339,404) and further in view of Chew (US 2017/0329729).
Regarding claim 1, Gibbs 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 (col. 4:6-8, “the OpenCL standard is leveraged by using a JavaScript API for interacting between a web application and OpenCL”) using an application programming interface (API) function (col. 4:16-21, “a single namespace is utilized, where there is a single JavaScript object used to access hardware acceleration through OpenCL” and “Direct access is provided to the OpenCL initialization APIs”);
registering a callback function within the software application to be invoked upon completion of a hardware accelerator library operation (col. 4:29-31, “a clFinish( ) command in accordance with this embodiment of the present invention takes a callback function provided by the use,” user provided callback function handles completion of OpenCL kernel operation); and
accessing hardware functionality of a computing system using the hardware accelerator library (col. 4:16-18, “there is a single JavaScript object used to access hardware acceleration through OpenCL”).
Gibbs does not explicitly teach; however, Pryor discloses: 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 Gibbs. 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).
Gibbs and Pryor do not teach; however, Chew discloses: the callback function is configurable to comprise an asynchronous callback function to be registered within the software application (¶ 179, “Transaction sequence 1800 begins with issuing of a GPU task at 1801 by CPU thread 1851 associated with a CPU in communication with GPU 1514 of a computing device,” “a graphics driver API is invoked with a thread ID and/or a callback function pointer associated with the CPU thread and/or the task,” and “CPU thread 1851 may be used to perform other tasks that may not need GPU computation results at 1805”); and
in event that the asynchronous callback function is registered within the software application, the software application is to perform one or more other functionalities (¶ 179, “CPU thread 1851 may be used to perform other tasks that may not need GPU computation results at 1805”) until (1) notification of the completion of the hardware accelerator library operation (¶ 180, “At 1829, one or more GPU tasks, including the requested GPU task, are done and, in one embodiment, an MSI interrupt with data to the CPU is emulated and any GPU interrupts are disabled at 1831”) and (2) generation of result data of the hardware accelerator library operation (¶ 180, “an interrupt data field of MSI interrupt with data contains a thread ID, such as thread IDs 1 1903, N 1913 of FIG. 19A, associated with the completed task, and a memory pointer referencing a memory address location where computation results of the completed task is stored”).
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 callback function is configurable to comprise an asynchronous callback function to be registered within the software application; and in event that the asynchronous callback function is registered within the software application, the software application is to perform one or more other functionalities until (1) notification of the completion of the hardware accelerator library operation and (2) generation of result data of the hardware accelerator library operation, as taught by Chew, in the same way to the invocation, as taught by Gibbs and Pryor. Both inventions are in the field of implementing hardware acceleration, and combining them would have predictably resulted in “facilitating callback interrupt handling for multi-threaded applications in computing environments,” as indicated by Chew (¶ 1).
Regarding claim 4, Pryor 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 (col. 6:53-57, “upon receiving an input from the graphical user interface 122, the host computer 100 translates the input into a computer command to cause either the CPU 110 or GPU 112 to execute a predetermined action responsive to the computer command”).
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, Pryor teaches: The at least one non-transitory machine-readable medium of claim 1, further comprising batching a plurality of invocations (col. 7:24-30, “In one embodiment, the runtime system queues a series of requests until a result is required by first CPU-based program. Only when a result is required will the runtime system execute the commands. In addition to queuing commands, the runtime system transforms commands from MATLAB.RTM. to commands which are more efficient to be performed on GPU 30”).
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 Gibbs, Pryor, and Chew, 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”).
Gibbs, Pryor, and Chew 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 Gibbs, Pryor, and Chew. 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 Gibbs, Pryor, Chew, and Maeda, as applied above, and further in view of Balbi (US 2023/0092752).
Regarding claim 3, Gibbs, Pryor, Chew, 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 Gibbs, Pryor, Chew, 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 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gibbs, Pryor, and Chew, as applied above, and further in view of Daly (US 2017/0180273).
Regarding claim 6, Gibbs, Pryor, and Chew 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 Gibbs, Pryor, and Chew. 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 Gibbs, Pryor, and Chew, as applied above, and further in view of Cai (US 2021/0152659).
Regarding claim 19, Gibbs, Pryor, and Chew 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 Gibbs, Pryor, and Chew. 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
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 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