Prosecution Insights
Last updated: October 02, 2026
Application No. 18/098,397

SYSTEMS AND METHODS FOR INTEGRATION OF MACHINE LEARNING MODELS WITH CLIENT APPLICATIONS

Non-Final OA §102§103§112
Filed
Jan 18, 2023
Priority
Jan 18, 2022 — provisional 63/300,457
Examiner
LAU, KAITLYN RENEE
Art Unit
2148
Tech Center
2100 — Computer Architecture & Software
Assignee
Fmr LLC
OA Round
3 (Non-Final)
60%
Grant Probability
Moderate
3-4
OA Rounds
3m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 60% of resolved cases
60%
Career Allowance Rate
6 granted / 10 resolved
+5.0% vs TC avg
Strong +67% interview lift
Without
With
+66.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 11m
Avg Prosecution
27 currently pending
Career history
40
Total Applications
across all art units

Statute-Specific Performance

§101
28.8%
-11.2% vs TC avg
§103
34.3%
-5.7% vs TC avg
§102
14.3%
-25.7% vs TC avg
§112
21.9%
-18.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 10 resolved cases

Office Action

§102 §103 §112
DETAILED ACTION This action is in response to the application filed 05/12/2026. Claims 1-9, 12-20, and 27-30 are pending and have been examined. 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 . Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1-9, 12-20, and 27-30 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Regarding claim 1, claim 1 recites “using the protocol buffer profile as a sole integration point between the client application and the machine learning model.” The closest paragraph in the specification states “the RPC server-client interface is the sole integration point between the client application 103 and the ML model 110a-110n” (Specification, page 12). The specification provides support for a sole integration point, but does not support using the protocol buffer profile as the sole integration point between the client application and the machine learning model. Regarding claims 2-9 and 27-28, claims 2-9 and 27-28 are rejected for at least the same reasons as claim 1 since claims 2-9 and 27-28 depends on claim 1. Regarding claim 27, claim 27 recites “wherein the protocol buffer profile exposes functions of the machine learning model for inputs and outputs and maps the functions to the client application via the RPC client module.” The closest paragraph in the specification states “in some embodiments protocol buffer profile 109a exposes functions to ML model 110a for inputs and outputs and maps these functions to client application 103.” (Specification, page 10). The specification provides support for a exposing functions of the machine learning model for inputs and outputs and maps the functions to the client application, but does not support mapping the functions via the RPC client module. Regarding claim 12, claim 12 recites “using the protocol buffer profile as a sole integration point between the client application and the machine learning model.” The closest paragraph in the specification states “the RPC server-client interface is the sole integration point between the client application 103 and the ML model 110a-110n” (Specification, page 12). The specification provides support for a sole integration point, but does not support using the protocol buffer profile as the sole integration point between the client application and the machine learning model. Regarding claims 13-20 and 29-30, claims 13-20 and 29-30 are rejected for at least the same reasons as claim 1 since claims 13-20 and 29-30 depends on claim 1. Regarding claim 29, claim 29 recites “wherein the protocol buffer profile exposes functions of the machine learning model for inputs and outputs and maps the functions to the client application via the RPC client module.” The closest paragraph in the specification states “in some embodiments protocol buffer profile 109a exposes functions to ML model 110a for inputs and outputs and maps these functions to client application 103.” (Specification, page 10). The specification provides support for a exposing functions of the machine learning model for inputs and outputs and maps the functions to the client application, but does not support mapping the functions via the RPC client module. 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. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 3-5 and 14-16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Regarding claim 3, claim 3 recites “an RPC server module” in the third line. It is unclear as to whether this is the same RPC server module as recited in claim 1, or if this is another RPC server module. For the purposes of examination, Examiner has interpreted this RPC server module to be the same RPC server module as recited in claim 1. Regarding claim 3, claim 3 recites “an RPC client module” in the 4th-5th line. It is unclear as to whether this is the same RPC client module as recited in claim 1, or if this is another RPC client module. For the purposes of examination, Examiner has interpreted this RPC client module to be the same RPC client module as recited in claim 1. Regarding claims 4-5, claims 4-5 are rejected for at least the same reasons as claim 3 since claims 4-5 depend on claim 1. Regarding claim 14, claim 14 recites “an RPC server module” in the third line. It is unclear as to whether this is the same RPC server module as recited in claim 12, or if this is another RPC server module. For the purposes of examination, Examiner has interpreted this RPC server module to be the same RPC server module as recited in claim 12. Regarding claim 14, claim 14 recites “an RPC client module” in the 4th-5th line. It is unclear as to whether this is the same RPC client module as recited in claim 12, or if this is another RPC client module. For the purposes of examination, Examiner has interpreted this RPC client module to be the same RPC client module as recited in claim 12. Regarding claims 15-16, claims 15-16 are rejected for at least the same reasons as claim 14 since claims 15-16 depend on claim 12. Claim Rejections - 35 USC § 102 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (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. Claim(s) 1-5, 11-16, 27, and 29 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Sanapo et al. (US 2024/0256313 A1) (hereafter referred to as Sanapo). Regarding claim 1, Sanapo teaches A computerized method of integrating one or more machine learning models with a client application using Remote Procedure Calls (RPCs), (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that the representation of the Protobuf-based remote procedure calls is the protocol buffer profile.) the method comprising: deploying, by a server computing device, a software container associated with a client application, the software container comprising executable code corresponding to a machine learning model of a plurality of machine learning models, a plurality of inputs to the machine learning model, and a plurality of outputs of the machine learning model (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “The service container 2 is then arranged to receive interrogation requests 10 for any one of the machine-learning models hosted by the execution platform 1 and to return interrogation requests 16 with the corresponding outputs of the machine-learning models 4 to the requesting clients 8” (Sanapo, page 11, paragraph 0039) and where “a set of computer-executable instructions embodying any one, or all, of the methodologies described herein, resides completely, or at least partially, in or on a machine-readable storage medium, e.g., in the static memory 45 or, when loaded and being executed, in the main memory 46. For example, the instructions may include software processes implementing the database request processing functionality of the execution platform 1” (Sanapo, page 11, paragraph 0044). Examiner notes that the plurality of inputs are the interrogation requests. ); upon deployment of the software container, automatically generating, by the server computing device, a protocol buffer profile from a model container image of the software container using the inputs of the machine learning model and the outputs of the machine learning model, the protocol buffer profile defining one or more executable RPC functions for interactions between the machine learning model and the client application using an RPC server module and an RPC client module (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that the representation of the Protobuf-based remote procedure calls is the protocol buffer profile. ); converting, by the RPC server module of the server computing device, RPC request function parameters to corresponding input parameters for the machine learning model using the protocol buffer profile, and encoding data to ensure standardization of information between the machine learning model and the client application (Sanapo, page 10, paragraph 0036, “The example of FIG. 5 provides a streaming microservice to the one or more clients 8, as already mentioned above. Accordingly, the get module 30 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. Kafka messages requesting predictions from machine-learning model 4, the prepare prediction module 31 is arranged to serialize the payload of the Kafka messages to a Protobuf representation, and the response module 33 is arranged to de-serialize the Protobuf representation of the call responses 14 to form Kafka response messages and to send the interrogation responses 16 in form of the Kafka response messages back to the client 8. In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard streaming clients, while remaining to run on and in its native programming and training environment.”); receiving, by the server computing device from the client application, a request invoking a first one of the RPC functions to access the machine learning model (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that the client queries the model server container to access the machine learning model.); executing, by the server computing device, the machine learning model within the software container using the protocol buffer profile as a sole integration point between the client application and the machine learning model, to generate a classification value for input provided in the request (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that prediction is the classification value. ); and transmitting, by the server computing device, the classification value to the client application using a second one of the executable RPC functions (Sanapo, page 10, paragraph 0034, “Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4. The model server container 3 further includes a machine-learning model predictor 25 which is arranged to obtain the output (prediction) of the machine-learning model 4. Furthermore, the model server container 3 includes an output component 26 which is arranged to receive the output of the machine-learning model 4 from the machine-learning model predictor 25, to re-convert the output to a Protobuf representation and to return the Protobuf-based call response to the gateway” where “The service container 2 is then arranged to receive interrogation requests 10 for any one of the machine-learning models hosted by the execution platform 1 and to return interrogation requests 16 with the corresponding outputs of the machine-learning models 4 to the requesting clients 8” (Sanapo, page 11, paragraph 0039). Examiner notes that the prediction is the classification value.). Regarding claim 2, Sanapo teaches The method of claim 1, wherein the first RPC function comprises an RPC request function for providing input to the machine learning model in accordance with the protocol buffer profile generated from the model container image (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024). Examiner notes that the RPC function is the indicating one or more input parameters which are expected by the machine-learning model.). Regarding claim 3, Sanapo teaches The method of claim 2, wherein receiving a request invoking the first RPC function to access the machine learning model comprises: receiving, by an RPC server module of the server computing device, the request invoking the first RPC function to access the machine learning model from an RPC client module of the client application (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that the client queries the model server container which is invoking the first RPC function to access the machine learning model. Examiner further notes that the RPC server module is the model server container and the RPC client module is the client.); and mapping, by the RPC server module, the input provided in the request to one or more input parameters for the machine learning model based on the protocol buffer profile (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and where “In response to receiving the interrogation request 10, the service container 2 converts 11 the interrogation request to a call 12 to the model server container in order to inquire the machine-learning model. The call 12 includes the one or more input parameters to inquire the machine learning model 4, typically in a different representation ( e.g. data format) than in the interrogation request 10, such as a data format utilized by the machine-learning model 4 according to the first programming language. The service container sends the call 12 to the model server container 3. The model server container 3 receives the call and determines 13 a corresponding response of the machine-learning model 4 to the interrogation request, i.e. the model output.” (Sanapo, page 9, paragraph 0025) Examiner notes that the input provided in the request is the interrogation request and the one or more input parameters are the one or more input parameters. Examiner further notes that converting the request to a call maps the request to the parameters.). Regarding claim 4, Sanapo teaches The method of claim 3, wherein the second RPC function comprises an RPC response function for providing the classification value from the machine learning model using output parameters defined by the protocol buffer profile (Sanapo, page 10, paragraph 0034, “Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4. The model server container 3 further includes a machine-learning model predictor 25 which is arranged to obtain the output (prediction) of the machine-learning model 4. Furthermore, the model server container 3 includes an output component 26 which is arranged to receive the output of the machine-learning model 4 from the machine-learning model predictor 25, to re-convert the output to a Protobuf representation and to return the Protobuf-based call response to the gateway” where “The service container 2 is then arranged to receive interrogation requests 10 for any one of the machine-learning models hosted by the execution platform 1 and to return interrogation requests 16 with the corresponding outputs of the machine-learning models 4 to the requesting clients 8” (Sanapo, page 11, paragraph 0039). Examiner notes that the prediction is the classification value. Examiner further notes that the second RPC function is returning the call response to the client.). Regarding claim 5, Sanapo teaches The method of claim 4, wherein transmitting the classification value to the client application comprises: mapping, by the RPC server module, the classification value provided by the machine learning model to an output parameter of the second RPC function defined by the protocol buffer profile (Sanapo, page 10, paragraph 0034, “Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4. The model server container 3 further includes a machine-learning model predictor 25 which is arranged to obtain the output (prediction) of the machine-learning model 4. Furthermore, the model server container 3 includes an output component 26 which is arranged to receive the output of the machine-learning model 4 from the machine-learning model predictor 25, to re-convert the output to a Protobuf representation and to return the Protobuf-based call response to the gateway” where “The model server container 3 receives the call and determines 13 a corresponding response of the machine-learning model 4 to the interrogation request, i.e. the model output.” (Sanapo, page 9, paragraph 0025) Examiner notes that the classification value is the prediction. Examiner further notes that the output parameter is the Protobuf-based call response. Examiner notes that re-converting the output to a Protobuf representation is mapping the classification value to an output parameter and the second RPC function is returning the call response to the client. ); and executing, by the RPC server module, the second RPC function to transmit the output parameter to the RPC client module of the client application (Sanapo, page 10, paragraph 0034, “Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4. The model server container 3 further includes a machine-learning model predictor 25 which is arranged to obtain the output (prediction) of the machine-learning model 4. Furthermore, the model server container 3 includes an output component 26 which is arranged to receive the output of the machine-learning model 4 from the machine-learning model predictor 25, to re-convert the output to a Protobuf representation and to return the Protobuf-based call response to the gateway” where “The model server container 3 receives the call and determines 13 a corresponding response of the machine-learning model 4 to the interrogation request, i.e. the model output.” (Sanapo, page 9, paragraph 0025) Examiner notes that the output parameter is the Protobuf-based call response. Examiner further notes that the second RPC function is returning the call response to the client. ). Regarding claim 12, Sanapo teaches A system for integrating one or more machine learning models with a client application using Remote Procedure Calls (RPCs), the system comprising a server computing device having a memory for storing computer executable instructions and a processor that executes the computer executable instructions to (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035) and where “a set of computer-executable instructions embodying any one, or all, of the methodologies described herein, resides completely, or at least partially, in or on a machine-readable storage medium, e.g., in the static memory 45 or, when loaded and being executed, in the main memory 46. For example, the instructions may include software processes implementing the database request processing functionality of the execution platform 1.” (Sanapo, page 11, paragraph 0044). Examiner notes that the representation of the Protobuf-based remote procedure calls is the protocol buffer profile.): Deploy a software container associated with a client application, the software container comprising executable code corresponding to a machine learning model of a plurality of machine learning models, a plurality of inputs to the machine learning model, and a plurality of outputs of the machine learning model (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “The service container 2 is then arranged to receive interrogation requests 10 for any one of the machine-learning models hosted by the execution platform 1 and to return interrogation requests 16 with the corresponding outputs of the machine-learning models 4 to the requesting clients 8” (Sanapo, page 11, paragraph 0039) and where “a set of computer-executable instructions embodying any one, or all, of the methodologies described herein, resides completely, or at least partially, in or on a machine-readable storage medium, e.g., in the static memory 45 or, when loaded and being executed, in the main memory 46. For example, the instructions may include software processes implementing the database request processing functionality of the execution platform 1” (Sanapo, page 11, paragraph 0044). Examiner notes that the plurality of inputs are the interrogation requests. ); upon deployment of the software container, automatically generate a protocol buffer profile from a model container image of the software container using the inputs of the machine learning model and the outputs of the machine learning model, the protocol buffer profile defining one or more executable RPC functions for interactions between the machine learning model and the client application using an RPC server module and an RPC client module (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that the representation of the Protobuf-based remote procedure calls is the protocol buffer profile. ); convert, by the RPC server module, RPC request function parameters to corresponding input parameters for the machine learning model using the protocol buffer profile, and encoding data to ensure standardization of information between the machine learning model and the client application (Sanapo, page 10, paragraph 0036, “The example of FIG. 5 provides a streaming microservice to the one or more clients 8, as already mentioned above. Accordingly, the get module 30 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. Kafka messages requesting predictions from machine-learning model 4, the prepare prediction module 31 is arranged to serialize the payload of the Kafka messages to a Protobuf representation, and the response module 33 is arranged to de-serialize the Protobuf representation of the call responses 14 to form Kafka response messages and to send the interrogation responses 16 in form of the Kafka response messages back to the client 8. In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard streaming clients, while remaining to run on and in its native programming and training environment.”); receive, from the client application, a request invoking a first one of the RPC functions to access the machine learning model (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that the client queries the model server container to access the machine learning model.); execute the machine learning model within the software container using the protocol buffer profile as a sole integration point between the client application and the machine learning model, to generate a classification value for input provided in the request (Sanapo, page 10, paragraph 0033-0034, “in the examples of FIGS. 4 and 5, converting 11 the interrogation requests comprises a serialization and re-converting the call responses comprises a de-serialization. [0034] Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4” where “The interrogation request 10 indicates one or more input parameters which are expected by the machine-learning model 4 to generate an output such as a prediction” (Sanapo, page 9, paragraph 0024) and “the get module 20 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. http get requests from the client 8….In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard webclients, while remaining to run on and in its native programming and training environment” (Sanapo, page 10, paragraph 0035). Examiner notes that prediction is the classification value. ); and transmit the classification value to the client application using a second one of the executable RPC functions (Sanapo, page 10, paragraph 0034, “Moreover, in both examples of FIGS 4 and 5, the model server container 3 includes a number of components, such as a conversion component 24 which is arranged to convert the ProtoBuf-based remote procedure calls to a representation and format that is utilized and expected by the machine-learning model 4. The model server container 3 further includes a machine-learning model predictor 25 which is arranged to obtain the output (prediction) of the machine-learning model 4. Furthermore, the model server container 3 includes an output component 26 which is arranged to receive the output of the machine-learning model 4 from the machine-learning model predictor 25, to re-convert the output to a Protobuf representation and to return the Protobuf-based call response to the gateway” where “The service container 2 is then arranged to receive interrogation requests 10 for any one of the machine-learning models hosted by the execution platform 1 and to return interrogation requests 16 with the corresponding outputs of the machine-learning models 4 to the requesting clients 8” (Sanapo, page 11, paragraph 0039). Examiner notes that the prediction is the classification value.). Regarding claim 13, claim 13 recites substantially similar limitations to claim 2, and is therefore rejected under the same analysis. Regarding claim 14, claim 14 recites substantially similar limitations to claim 3, and is therefore rejected under the same analysis. Regarding claim 15, claim 15 recites substantially similar limitations to claim 4, and is therefore rejected under the same analysis. Regarding claim 16, claim 16 recites substantially similar limitations to claim 5, and is therefore rejected under the same analysis. Regarding claim 27, Sanapo teaches The method of claim 1, wherein the protocol buffer profile exposes functions of the machine learning model for inputs and outputs and maps the functions to the client application via the RPC client module (Sanapo, page 10, paragraph 0036, “The example of FIG. 5 provides a streaming microservice to the one or more clients 8, as already mentioned above. Accordingly, the get module 30 of the controller 6 is arranged to receive the interrogation requests 10 by way of e.g. Kafka messages requesting predictions from machine-learning model 4, the prepare prediction module 31 is arranged to serialize the payload of the Kafka messages to a Protobuf representation, and the response module 33 is arranged to de-serialize the Protobuf representation of the call responses 14 to form Kafka response messages and to send the interrogation responses 16 in form of the Kafka response messages back to the client 8. In this way, the machine-learning model 4 hosted by the model server container 3 can be queried by standard streaming clients, while remaining to run on and in its native programming and training environment.” Examiner notes that the RPC client module is the client, the inputs and outputs are the payloads and the responses, and the functions are the messages.) Regarding claim 29, claim 29 recites substantially similar limitations to claim 27, and is therefore rejected under the same analysis. 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. 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. 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) 6-10 and 17-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanapo in view of Kearney et al. (US 10,891,539 B1) (hereafter referred to as Kearney). Regarding claim 6, Sanapo teaches the method of claim 1. Sanapo does not teach, but Kearney does teach wherein the input provided in the request comprises a corpus of unstructured text (Kearney, page 26, column 11, lines 26-33, “During training, a word vector space is populated that represents word-word co-occurrence statistics within a corpus. This step is conducted on large corpus of words, typically ranging in the billions” and “A social media feed 610 may provide a feed 620 including communications 112 that been or are to be disseminated over the social network. The feed 620 may optionally include only communications 112 that relate to keywords, geolocations, and/or people of interest 624, which may be provided by one or more users 640 via one or more servers 630” (Kearney, page 25, column10, lines 38-42). Examiner notes that the input provided in the request are the keywords which are within a large corpus of words.). Sanapo and Kearney are considered analogous to the claimed invention because they both use remote procedure calls in machine learning. It would have been obvious to one having ordinary skill in the art prior to the effective filing date to have modified Sanapo to use text as input data like in Kearney. Doing so is advantageous because Kearney creates a “streamlined user involvement, requiring less time and effort to evaluate content, resulting in cost savings” (Kearney, page 22, column, 3, lines 44-45). Regarding claim 7, Sanapo in view of Kearney teaches the method of claim 6. Sanapo in view of Kearney further teaches wherein the classification value provided by the machine learning model comprises indicia of whether the unstructured text complies with one or more rulesets (Kearney, page 26, column 11, lines 34-37, “In a second step, the resulting word vector space is used to embed all words prior to training or predicting. Classifications of each embedded sentence are found using a supervised learning routine” where “the automated evaluation 113 may include, for each of the communications 112 in the keyword list view 300, a classification type 320 and a confidence level 330, which may be a probability that the communication 112 has the classification type 320 indicated” (Kearney, page 25, column 9, lines 38-43) and “an ‘automated evaluation’ is a computer-generated evaluation of adherence of a communication to one or more criteria. An automated evaluation may include a binary indication of the content in the communication (i.e., the communication is or is not in compliance with a policy, or the communication does or does not relate to particular subject matter of interest)” (Kearney, page 22, column 4, lines 11-17). Examiner notes that the classification type is the classification value and the policy is the one or more rulesets.). Sanapo and Kearney are considered analogous to the claimed invention because they both use remote procedure calls in machine learning. It would have been obvious to one having ordinary skill in the art prior to the effective filing date to have modified Sanapo to have the classification value indicate whether the text complies with the rulesets like in Kearney. Doing so is advantageous because Kearney creates “increased accuracy in terms of determining which content does and does not meet predetermined criteria or policies” (Kearney, page 22, column, 3, lines 38-40). Regarding claim 8, Sanapo in view of Kearney teaches the method of claim 7. Sanapo in view of Kearney further teaches wherein the machine learning model generates one or more labels each associated with a portion of the unstructured text, each label designating a compliance type for the corresponding portion of text (Kearney, page 26, column 11, lines 34-37, “In a second step, the resulting word vector space is used to embed all words prior to training or predicting. Classifications of each embedded sentence are found using a supervised learning routine” where “the automated evaluation 113 may include, for each of the communications 112 in the keyword list view 300, a classification type 320 and a confidence level 330, which may be a probability that the communication 112 has the classification type 320 indicated” (Kearney, page 25, column 9, lines 38-43) and “an ‘automated evaluation’ is a computer-generated evaluation of adherence of a communication to one or more criteria. An automated evaluation may include a binary indication of the content in the communication (i.e., the communication is or is not in compliance with a policy, or the communication does or does not relate to particular subject matter of interest)” (Kearney, page 22, column 4, lines 11-17). Examiner notes that the classification type is the label and the compliance type.). Sanapo and Kearney are considered analogous to the claimed invention because they both use remote procedure calls in machine learning. It would have been obvious to one having ordinary skill in the art prior to the effective filing date to have modified Sanapo to have the labels designate the compliance type like in Kearney. Doing so is advantageous because Kearney creates “increased accuracy in terms of determining which content does and does not meet predetermined criteria or policies” (Kearney, page 22, column, 3, lines 38-40). Regarding claim 9, Sanapo in view of Kearney teaches the method of claim 8. Sanapo in view of Kearney further teaches wherein the machine learning model further generates a confidence level associated with the classification value, the confidence level designating a certainty with which the machine learning model considers the classification value as accurate or inaccurate (Kearney, page 25, column 9, lines 38-43, “the automated evaluation 113 may include, for each of the communications 112 in the keyword list view 300, a classification type 320 and a confidence level 330, which may be a probability that the communication 112 has the classification type 320 indicated.” Examiner notes that the classification type is the classification value.). Sanapo and Kearney are considered analogous to the claimed invention because they both use remote procedure calls in machine learning. It would have been obvious to one having ordinary skill in the art prior to the effective filing date to have modified Sanapo to have the labels designate the compliance type like in Kearney. Doing so is advantageous because Kearney creates “increased accuracy in terms of determining which content does and does not meet predetermined criteria or policies” (Kearney, page 22, column, 3, lines 38-40). Regarding claim 17, claim 17 recites substantially similar limitations to claim 6, and is therefore rejected under the same analysis. Regarding claim 18, claim 18 recites substantially similar limitations to claim 7, and is therefore rejected under the same analysis. Regarding claim 19, claim 19 recites substantially similar limitations to claim 8, and is therefore rejected under the same analysis. Regarding claim 20, claim 20 recites substantially similar limitations to claim 9, and is therefore rejected under the same analysis. Claim(s) 28 and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanapo in view of Kearney in further view of Lin (US 7,680,890 B1). Regarding claim 28, Sanapo teaches the method of claim 1. Sanapo further teaches wherein the client application is configured to communicate with a plurality of different model containers and corresponding machine learning models (Sanapo, page 11, paragraph 0039, “In embodiments, the execution platform 1 may also host more than one machine-learning model 4. For example, to this end, the execution platform 1 include multiple model server containers 3, each hosting a respective machine-learning model 4. In other variants, one model server container 4 may hosts multiple machine-learning models 4. The service container 2 is then arranged to receive interrogation requests 10 for any one of the machine-learning models hosted by the execution platform 1 and to return interrogation requests 16 with the corresponding outputs of the machine-learning models 4 to the requesting clients.”), Sanapo does not teach, but Kearney does teach and wherein the client application sends a same document to multiple machine learning models for classification … to generate an overall classification value (Kearny, page 28, column 15, line 54 – column 16, line 7, “The convolutional language classification model 1110 may process input text 1140 through word embeddings 1142 o LSTM layers 1144, and through convolutional layers 1152 to LSTM layers 1154. The image classification model 1120 may process images 1160 through convolutional layers 1162 to fully connected layers 1164. The structured data classification model 1130 may process structured information 1170 through fully connected layers 1172 to fully connected layers 1174. The structured information 1170 may include geographical, temporal, demographic, user background information, and/or custom user input information. The LSTM layers 1144, the LSTM layers 1154, the fully connected layers 1164, and the fully connected layers 1174 may be connected to define fully connected layers 1180. The fully connected layers 1180 may thus incorporate text, images, and/or structured information to provide a prediction 1190 of greater accuracy than could be obtained by operation of the convolutional language classification model 1110, the image classification model 1120, or the structured data classification model 1130, alone”) Sanapo and Kearney are considered analogous to the claimed invention because they both use remote procedure calls in machine learning. It would have been obvious to one having ordinary skill in the art prior to the effective filing date to have modified Sanapo to have the client application send a same document to multiple machine learning models to generate an overall classification value. Doing so is advantageous because Kearney creates “increased accuracy in terms of determining which content does and does not meet predetermined criteria or policies” (Kearney, page 22, column, 3, lines 38-40). Sanapo in view of Kearney does not explicitly teach aggregating classification values. Lin however discloses and wherein the client application sends a same document to multiple machine learning models for classification and aggregates classification values returned by each model to generate an overall classification value (Lin, page 11, column 7, lines 30-36, “As will become clear, according to one embodiment, the e-mail handling system 120 is adapted to distinguish between the spam and non-spam messages 104, 108 by combining results or outputs of two or more e-mail classification tools 140 that are standardized and combined by a voting mechanism 144 to produce a single classification output for use by a spam classifier 146” and Lin, page 6, Figure 3, PNG media_image1.png 809 522 media_image1.png Greyscale Examiner notes that the classifiers/classification tools are the machine learning models. Examiner further notes that the outputs are the classification values.) Sanapo in view of Kearney and Lin are considered analogous to the claimed invention because they use both classification techniques in machine learning. It would have been obvious to one having ordinary skill in the art prior to the effective filing date to have modified Sanapo in view of Kearny to aggregate classification values to generate an overall classification value. Doing so is advantageous because “a benefit of the voting formula 244 is that no one tool 212, 214,216 determines its output 250, which makes the system 200 much more difficult to beat or fool by spam distributors or spammers” (Kearney, page 22, column, 3, lines 38-40). Regarding claim 30, claim 30 recites substantially similar limitations to claim 28, and is therefore rejected under the same analysis. Response to Arguments The previous 112(a) rejections have been overcome in light of the instant amendments. Examiner notes that new 112 rejections have been made in light of the instant amendments. On page 3, Applicant argues: Applicant thanks Examiner Haefner for the indication of allowable subject matter in claims 1-9, 12-20, and 23-26. (Office Action at p. 10-13.) Applicant submits that the Section 112(a) rejection has been overcome with the present amendment, and the amendments do not alter the allowability of the claims over the art of record. Regarding the Applicant’s argument that the amendments do not alter the allowability of the claims over the art of record, Examiner respectfully disagrees. Specifically, Examiner notes that the limitations on which the previous claim set was allowable have since been amended out of the claims. Thus, the allowability of the claims over the art of record has been altered and further search and consideration was required. Since the claims have been amended, Examiner has determined, as discussed above, that a combination of Sanapo, Kearny, and Lin teach all the claims under 35 U.S.C. 102 and 103. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Zhang et al. (US 2019/0034937 A1) also discuss using remote procedure calls in machine learning. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAITLYN R LAU whose telephone number is (571)272-1429. The examiner can normally be reached Monday - Thursday: 8:00 am - 6:00 pm EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michelle Bechtold can be reached at (571) 431-0762. 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. /K.R.L./Examiner, Art Unit 2148 /MICHELLE T BECHTOLD/Supervisory Patent Examiner, Art Unit 2148
Read full office action

Prosecution Timeline

Jan 18, 2023
Application Filed
Nov 03, 2025
Non-Final Rejection mailed — §102, §103, §112
Feb 03, 2026
Response Filed
Apr 02, 2026
Final Rejection mailed — §102, §103, §112
May 12, 2026
Request for Continued Examination
May 16, 2026
Response after Non-Final Action
Aug 11, 2026
Non-Final Rejection mailed — §102, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12688298
FEATURE SELECTION FOR CYBERSECURITY THREAT DISPOSITION
4y 7m to grant Granted Jul 21, 2026
Patent 12602431
METHODS FOR PERFORMING INPUT-OUTPUT OPERATIONS IN A STORAGE SYSTEM USING ARTIFICIAL INTELLIGENCE AND DEVICES THEREOF
3y 10m to grant Granted Apr 14, 2026
Patent 12572828
METHOD FOR INDUSTRY TEXT INCREMENT AND ELECTRONIC DEVICE
4y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 3 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
60%
Grant Probability
99%
With Interview (+66.7%)
3y 11m (~3m remaining)
Median Time to Grant
High
PTA Risk
Based on 10 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month