DETAILED ACTION
1. This Office Action is taken in response to Applicants’ Pre-Appeal request filed on 6/26/2026 regarding application 18/086,429 filed on 12/21/2022.
Claims 1-20 are pending for consideration.
2. Response to Amendments and Remarks
Applicants’ Remarks have been fully and carefully considered, with the Examiner’s response set forth below.
(1) In response to the Applicants’ pre-appeal request, an updated claim analysis has been made. Refer to the corresponding sections of the following Office Action for details.
3. Examiner’s Note
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
(2) Examiner has cited particular columns/paragraph and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
4. Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor regards as the invention.
Claim 1 recites “wherein the one or more asynchronous reduction operations ... at least in part, uses manual transaction accounting comprising one or more functions that track when a count of the performed one or more asynchronous reduction operations equals an expected count of the one or more asynchronous reduction operations to determine when the one or more asynchronous reduction operations are complete.” This limitation raises the following issues:
First, the limitation recites “the one or more asynchronous reduction operations.” Thus, it allows the cases where there is only one single asynchronous reduction operation.
Second, the limitation also recites “track when a count of the performed one or more asynchronous reduction operations equals an expected count of the one or more asynchronous reduction operations to determine when the one or more asynchronous reduction operations are complete.” It is noticed that the “count” associated with “the performed one or more asynchronous reduction operations” may be interpreted in at least two differ manners.
The first interpretation of the “count” is related to the total number of asynchronous reduction operations. However, since the claim recites “the one or more asynchronous reduction operations” and does not exclude the cases of “a single asynchronous reduction operation,” the “count” becomes degenerated and meaningless, at least for those cases where there is only on single asynchronous reduction operation.
The second interpretation of the “count” is related to the total number of data objects associated with the single asynchronous reduction operation. For example, as presented in details in Section 5 of this Office Action, the asynchronous reduction operation disclosed by the Sun reference tracks a count of the multiple data objects that are to be combined into a single data object.
If Applicant’s intention is to track the total number of asynchronous reduction operation, then the limitation ““one or more asynchronous reduction operations” must be further restricted into “a plurality of asynchronous reduction operations” in order to avoid the ambiguity explained above.
Clarifications/corrections are needed.
Claims 2-7 are rejected by virtue of their dependency from claim 1.
Claim 8 suffers from the same deficiency as in claim 1.
Claims 9-13 are rejected by virtue of their dependency from claim 8.
Claim 14 suffers from the same deficiency as in claim 1.
Claims 15-20 are rejected by virtue of their dependency from claim 14.
Claim Rejections - 35 USC § 102
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
5. Claims 1, 8, and 14 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Sun et al. (US Patent Application Publication 2024/0143323, hereinafter Sun)
As to claim 1, Sun teaches One or more processors [processor, figure 7, 702] comprising:
circuitry to [as shown in figure 7], in response to an application programming interface (API) call [API operations for asynchronous reduction operations as shown in figures 1A, 1B, 1C, 4, and 6; Example microservice API architectures are described herein. In some examples, the architecture includes a distributed cluster of gateway nodes that jointly provide access to the APIs for external clients. In some examples, the APIs are provided by providing a plurality of plugins that implement the APIs. As a result of a distributed architecture, the task of API management can be distributed across a cluster of gateway nodes or even web services ... FIG. 1A illustrates an example implementation with multiple APIs having functionalities common to one another. As shown in FIG. 1A, a client 102 is associated with APIs 104A, 104B, 104C, 104D, and 104E. Each API has a standard set of features or functionalities associated with it ... (¶ 0022-0027)] cause one or more asynchronous reduction operations [Sun teaches at least one asynchronous reduction operation that combines and reduces the number of data objects -- For example, if multiple routing data objects result in the same service and plug-in config being used, the multiple routing data objects are combinable into a single routing data object. In particular, respective match expressions included in each of the multiple routing data objects are combinable by a logical OR operator to form a single match expression for a single routing data object. In some embodiments, the API gateway 400 is configured to identify combinable routing data objects and to recommend and/or automatically cause combination of the combinable routing data objects. As such, a number of routing data objects that are evaluated by the gateway is minimized, which improves matching performance at runtime (¶ 0082); The method of claim 1, further comprising reducing a number of routing data objects included in the plurality of routing data objects based on: determining that two routing data objects of the plurality of routing data objects are combinable, and defining a combined routing data object to replace the two routing data objects, wherein the combined routing data object includes a combined match expression that includes a logical combination, via an OR Boolean operator, of respective match expressions of the two routing data objects (claim 7)] based at least in part, on one or more input parameters to the API indicating a reduction operation to be performed [Sun teaches that the API request includes a matching expression to identify those data objects of the same attributes are to be combined into one single data object to reduce the number of data objects to be routed -- A method for routing application programming interface (API) requests within a microservices architecture, the method comprising: receiving an API request that includes a plurality of message attributes; accessing a plurality of routing data objects, each routing data object being associated with an upstream API of the microservices architecture and including a match expression, wherein the match expression includes a logical combination of one or more attribute condition statements, wherein each attribute condition statement is specific to a message attribute and is defined by a data value and a relational operator by which the message attribute is compared to the data value; performing at least one matching operation between the API request and the plurality of routing data objects, wherein each matching operation for a given one of the plurality of routing data objects includes: evaluating, with the plurality of message attributes of the API request, the one or more attribute condition statements of the match expression of the given one of the plurality of routing data objects, and determining whether the match expression is logically true according to the logical combination of the one or more attribute condition statements; based on performing the at least one matching operation, identifying a particular routing data object that matches the API request based on the match expression of the particular routing data object being logically true with the plurality of message attributes of the API request; and routing the API request to a particular upstream API according to the particular routing data object (claim 1); The method of claim 1, further comprising reducing a number of routing data objects included in the plurality of routing data objects based on: determining that two routing data objects of the plurality of routing data objects are combinable, and defining a combined routing data object to replace the two routing data objects, wherein the combined routing data object includes a combined match expression that includes a logical combination, via an OR Boolean operator, of respective match expressions of the two routing data objects (claim 7)], wherein the one or more asynchronous reduction operations combine multiple data to fewer data [Sun teaches at least one asynchronous reduction operation that tracks and counts the number of data objects with the same attributes, and combines and reduces the number of data objects into a single data object to be routed – API operations for asynchronous reduction operations as shown in figures 1A, 1B, 1C, 4, and 6; For example, if multiple routing data objects result in the same service and plug-in config being used, the multiple routing data objects are combinable into a single routing data object. In particular, respective match expressions included in each of the multiple routing data objects are combinable by a logical OR operator to form a single match expression for a single routing data object. In some embodiments, the API gateway 400 is configured to identify combinable routing data objects and to recommend and/or automatically cause combination of the combinable routing data objects. As such, a number of routing data objects that are evaluated by the gateway is minimized, which improves matching performance at runtime (¶ 0082); A method for routing application programming interface (API) requests within a microservices architecture, the method comprising: receiving an API request that includes a plurality of message attributes; accessing a plurality of routing data objects, each routing data object being associated with an upstream API of the microservices architecture and including a match expression … (claim 1); The method of claim 1, further comprising reducing a number of routing data objects included in the plurality of routing data objects based on: determining that two routing data objects of the plurality of routing data objects are combinable, and defining a combined routing data object to replace the two routing data objects, wherein the combined routing data object includes a combined match expression that includes a logical combination, via an OR Boolean operator, of respective match expressions of the two routing data objects (claim 7)], and wherein the circuitry, at least in part, uses manual transaction accounting comprising one or more functions [API operations for asynchronous reduction operations as shown in figures 1A, 1B, 1C, 4, and 6; Example microservice API architectures are described herein. In some examples, the architecture includes a distributed cluster of gateway nodes that jointly provide access to the APIs for external clients. In some examples, the APIs are provided by providing a plurality of plugins that implement the APIs. As a result of a distributed architecture, the task of API management can be distributed across a cluster of gateway nodes or even web services ... FIG. 1A illustrates an example implementation with multiple APIs having functionalities common to one another. As shown in FIG. 1A, a client 102 is associated with APIs 104A, 104B, 104C, 104D, and 104E. Each API has a standard set of features or functionalities associated with it ... (¶ 0022-0027); The method of claim 1, further comprising reducing a number of routing data objects included in the plurality of routing data objects based on: determining that two routing data objects of the plurality of routing data objects are combinable, and defining a combined routing data object to replace the two routing data objects, wherein the combined routing data object includes a combined match expression that includes a logical combination, via an OR Boolean operator, of respective match expressions of the two routing data objects (claim 7)] that track when a count of the performed one or more asynchronous reduction operations equals an expected count of the one or more asynchronous reduction operations to determine when the one or more asynchronous reduction operations are complete [Sun teaches at least one asynchronous reduction operation that tracks and counts the number of data objects with the same attributes, and combines and reduces the number of data objects into a single data object to be routed – The method of claim 1, further comprising reducing a number of routing data objects included in the plurality of routing data objects based on: determining that two routing data objects of the plurality of routing data objects are combinable, and defining a combined routing data object to replace the two routing data objects, wherein the combined routing data object includes a combined match expression that includes a logical combination, via an OR Boolean operator, of respective match expressions of the two routing data objects (claim 7)].
As to claim 8, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details.
As to claim 14, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details.
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.
6. Claims 2-7, 9-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al. (US Patent Application Publication 2024/0143323, hereinafter Sun), and in view of Kerr et al. (US Patent Application Publication 2021/0124582, hereinafter Kerr).
Regarding claim 2, Sun teaches performing at least one asynchronous reduction operation, but does teach the asynchronous reduction operation is performed by a graphics processing unit (GPU).
However, performing asynchronous reduction operations by a graphics processing unit (GPU) is well known and a common practice in the art.
For example, Kerr specifically teaches performing asynchronous reduction operations by a graphics processing unit (GPU) through an API call [Kerr teaches asynchronous reduction operations by avoiding conflicts during accessing a shared memory – As shown in FIG. 5, the shared memory is divided into a plurality of banks (e.g., 32 banks with 32 or 64 bits per clock cycle bandwidth), each including a read port and a write port from which writes and reads can be processed simultaneously in multiple banks ... For example, if the read request is made for data at B0, A1 and C0, then there is a bank conflict and the read request for B0, A1, and C0 will be serialized into three reads ... As shown in FIG. 6, a row of A's is spread out across the width of the shared memory. This allows for any one of the sub-blocks from a same block to be accessed in a conflict free-way. If all of the data from block A were vertically stacked in the shared memory, they could be read only serially. By spreading them out, access to all of the A blocks can be made without conflict ... (¶ 0092-0095); In an embodiment, the PPU 300 comprises a graphics processing unit (GPU). The PPU 300 is configured to receive commands that specify shader programs for processing graphics data … An application writes model data for a scene (e.g., a collection of vertices and attributes) to a memory such as a system memory or memory 304. The model data defines each of the objects that may be visible on a display. The application then makes an API call to the driver kernel that requests the model data to be rendered and displayed … (¶ 0146-0147); ... The API provides an abstraction for a programmer that lets a programmer utilize specialized graphics hardware, such as the PPU 300, to generate the graphical data without requiring the programmer to utilize the specific instruction set for the PPU 300. The application may include an API call that is routed to the device driver for the PPU 300. The device driver interprets the API call and performs various operations to respond to the API call ... (¶ 0161-0162)].
Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to perform asynchronous reduction operations by a graphics processing unit (GPU), as specifically demonstrated by Kerr, and to incorporate it into the existing scheme disclosed by Sun, because Kerr teaches doing so allows API calls to take advantage of the special hardware features offered by a GPU [(¶ 0146-0147)].
As to claim 3, Sun in view of Kerr teaches The one or more processors of claim 2, wherein the asynchronous reduction operations are performed on information that includes data from a first memory of the GPU and a second memory of the GPU [Kerr -- Modern processing chip(s) such as GPUs typically contain significant amounts of memory near the parallel processors—reducing memory access latency. For example, as of this filing, some NVIDIA GPUs contain on the order of 12 GB or more of local on-chip high bandwidth memory (including e.g., 4 GB of cache/shared memory) to serve over 5000 cores operating in parallel (¶ 0005); FIGS. 1A-3B illustrates an example non-limiting parallel processing architecture showing software controlled transfer of data from the global memory 511 to shared memory 574 accessible by a plurality of functional units 512.sub.0-512.sub.N … (¶ 0050); In an embodiment, the PPU 300 comprises a graphics processing unit (GPU). The PPU 300 is configured to receive commands that specify shader programs for processing graphics data … An application writes model data for a scene (e.g., a collection of vertices and attributes) to a memory such as a system memory or memory 304. The model data defines each of the objects that may be visible on a display. The application then makes an API call to the driver kernel that requests the model data to be rendered and displayed … (¶ 0146-0147)].
As to claim 4, Sun in view of Kerr teaches The one or more processors of claim 1, wherein the one or more asynchronous reduction operations are to move information between shared memory of a graphics processing unit (GPU) and global memory of the GPU [Kerr -- A technique for block data transfer is disclosed that reduces data transfer and memory access overheads and significantly reduces multiprocessor activity and energy consumption. Threads executing on a multiprocessor needing data stored in global memory can request and store the needed data in on-chip shared memory, which can be accessed by the threads multiple times. The data can be loaded from global memory and stored in shared memory using an instruction which directs the data into the shared memory without storing the data in registers and/or cache memory of the multiprocessor during the data transfer (abstract)].
As to claim 5, Sun in view of Kerr teaches The one or more processors of claim 1, wherein the API is to receive one or more inputs indicating a source memory location and a destination memory location of the one or more asynchronous reduction operations [Kerr -- Example non-limiting embodiments provide a fused load and store instruction (LDGSTS) which can load data from the global memory (LDG) and store the data into the shared memory (STS) bypasses the processor core register … The LDGSTS.ACCESS and LDGSTS.BYPASS instructions may include two address operands, a destination shared memory address and a source global address … (¶ 0040); To optimize loading data into shared memory, example non-limiting embodiments eliminate the need to stage data through SM's register file. In example non-limiting embodiments, this is implemented as a single LDGSTS.ACCESS instruction, with two address operands, a destination shared memory address and a source global address (¶ 0064)].
As to claim 6, Sun in view of Kerr teaches The one or more processors of claim 1, wherein the API is to receive information indicating a shape of information corresponding to the one or more asynchronous reduction operations [Kerr -- … In an embodiment, the PPU 300 is a graphics processing unit (GPU) configured to implement a graphics rendering pipeline for processing three-dimensional (3D) graphics data in order to generate two-dimensional (2D) image data for display on a display device such as a liquid crystal display (LCD) device … (¶ 0130); In an embodiment, a host processor executes a driver kernel that implements an application programming interface (API) that enables one or more applications executing on the host processor to schedule operations for execution on the PPU 300 … (¶ 0141)].
As to claim 7, Sun in view of Kerr teaches The one or more processors of claim 1, wherein the API is to provide an indication of whether a type of hardware unit is used to perform the one or more asynchronous reduction operations [Kerr -- An application writes model data for a scene (e.g., a collection of vertices and attributes) to a memory such as a system memory or memory 304. The model data defines each of the objects that may be visible on a display. The application then makes an API call to the driver kernel that requests the model data to be rendered and displayed … In an embodiment, the graphics processing pipeline 600 may represent a graphics processing pipeline defined by the OpenGL® API. As an option, the graphics processing pipeline 600 may be implemented in the context of the functionality and architecture of the previous Figures and/or any subsequent Figure(s) (¶ 0147-0148); … The API provides an abstraction for a programmer that lets a programmer utilize specialized graphics hardware, such as the PPU 300, to generate the graphical data without requiring the programmer to utilize the specific instruction set for the PPU 300 … (¶ 0161)].
As to claim 9, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 10, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 11, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to “As to claim 3” presented earlier in this Office Action for details.
As to claim 12, Sun in view of Kerr teaches The system of claim 8, wherein the API is to receive as input an identifier of a synchronization object [Kerr -- Cooperative Groups is a programming model for organizing groups of communicating threads that allows developers to express the granularity at which threads are communicating, enabling the expression of richer, more efficient parallel decompositions. Cooperative launch APIs support synchronization amongst thread blocks for the execution of parallel algorithms. Conventional programming models provide a single, simple construct for synchronizing cooperating threads: a barrier across all threads of a thread block (e.g., the syncthreads( ) function). However, programmers would often like to define groups of threads at smaller than thread block granularities and synchronize within the defined groups to enable greater performance, design flexibility, and software reuse in the form of collective group-wide function interfaces … (¶ 0175-0176);
Sun -- Beyond user creation of routing data objects, the API gateway 400 provides other administrative functionality relating to routes and routing data objects. In some embodiments, the API gateway 400 enables an authorized user (e.g., an administrator) to view a specific routing data object. When created, routing data objects are assigned with a unique identifier (e.g., an incrementing number, a globally unique identifier, a universally unique identifier, a universal resource identifier or locator, a name string). As such, an authorized user is able to make a request that include the unique identifier for a specific routing data object to view the routing data object. In some examples, the authorized user makes a HTTP GET request to the URL of a specific routing data object, and the API gateway 400 indicates (e.g., causes display at the user client) the match expression of the specific routing data object (¶ 0074)].
As to claim 13, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 15, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 16, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 17, it recites substantially the same limitations as in claim 7, and is rejected for the same reasons set forth in the analysis of claim 7. Refer to “As to claim 7” presented earlier in this Office Action for details.
As to claim 18, it recites substantially the same limitations as in claim 12, and is rejected for the same reasons set forth in the analysis of claim 12. Refer to “As to claim 12” presented earlier in this Office Action for details.
As to claim 19, Sun in view of Kerr teaches The method of claim 14, wherein the API is to receive as input information indicating a plurality of characteristics of data to be transformed [Kerr -- An application writes model data for a scene (e.g., a collection of vertices and attributes) to a memory such as a system memory or memory 304. The model data defines each of the objects that may be visible on a display. The application then makes an API call to the driver kernel that requests the model data to be rendered and displayed … In an embodiment, the graphics processing pipeline 600 may represent a graphics processing pipeline defined by the OpenGL® API. As an option, the graphics processing pipeline 600 may be implemented in the context of the functionality and architecture of the previous Figures and/or any subsequent Figure(s) (¶ 0147-0148); … The API provides an abstraction for a programmer that lets a programmer utilize specialized graphics hardware, such as the PPU 300, to generate the graphical data without requiring the programmer to utilize the specific instruction set for the PPU 300 … (¶ 0161);
Sun -- … For example, the routing data objects include match expressions that include a logical combination of one or more attribute condition statements. Each routing data object is associated with an upstream API and includes a match expression. The match expression includes a logical combination of one or more attribute condition statements … (¶ 0104); A method for routing application programming interface (API) requests within a microservices architecture, the method comprising: receiving an API request that includes a plurality of message attributes; accessing a plurality of routing data objects, each routing data object being associated with an upstream API of the microservices architecture and including a match expression, wherein the match expression includes a logical combination of one or more attribute condition statements, wherein each attribute condition statement is specific to a message attribute and is defined by a data value and a relational operator by which the message attribute is compared to the data value; performing at least one matching operation between the API request and the plurality of routing data objects, wherein each matching operation for a given one of the plurality of routing data objects includes: evaluating, with the plurality of message attributes of the API request, the one or more attribute condition statements of the match expression of the given one of the plurality of routing data objects, and determining whether the match expression is logically true according to the logical combination of the one or more attribute condition statements; based on performing the at least one matching operation, identifying a particular routing data object that matches the API request based on the match expression of the particular routing data object being logically true with the plurality of message attributes of the API request; and routing the API request to a particular upstream API according to the particular routing data object (claim 1)].
As to claim 20, Sun in view of Kerr teaches A non-transitory computer-readable medium having stored thereon a set of instructions, which if performed by one or more processors, cause the one or more processors to at least perform the method of claim 14 [Kerr -- Computer programs, or computer control logic algorithms, may be stored in the main memory 540 and/or the secondary storage. Such computer programs, when executed, enable the system 565 to perform various functions. The memory 540, the storage, and/or any other storage are possible examples of computer-readable media (¶ 0203);
Sun – processor, figure 7, 702].
Conclusion
7. Claims 1-20 are rejected as explained above.
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHENG JEN TSAI whose telephone number is 571-272-4244. The examiner can normally be reached on Monday-Friday, 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached on 571-272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/SHENG JEN TSAI/Primary Examiner, Art Unit 2136
Prosecution Insights