DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Claims 1, 13, and 20 are amended and claims 5, 7, and 16 are cancelled. Claims 1-4, 6, 8-15, and 17-20 are pending.
Response to Arguments
Applicant's arguments filed 2/16/2026 have been fully considered.
Regarding the objection of claim 7, and as noted by Applicant on page 8 of the response, claim 7 is cancelled and the relevant portion of claim 7 into claim 1 is corrected to overcome the objection, which is withdrawn.
Regarding the rejections of independent claims 1, 13, and 20 under 101, Examiner respectfully disagrees with Applicant’s arguments on pages 9-12 for the following reasons.
On page 9 of the response, Applicant contends that the one or more features of amended claim 1 cannot be performed mentally. In support, Applicant asserts that “… the amended claim expressly requires machine-implemented natural-language processing (NLP, machine-maintained weighting values, machine-executed threshold comparisons, and automated initiation of remote maintenance actions via network-transmitted commands,” which are “inextricably tied to a machine and require specialized computational operations that cannot be carried out by a human with pen and paper.”
Examiner acknowledges that amended claim 1 (and similarly for claims 13 and 20) recites “additional elements” such as “automatically initiating at least a portion of a remotely-performable maintenance action … by transmitting …”, and furthermore expressly recites that the processing steps are machine-implemented. However, Examiner submits that the processing functions including NLP processing, using “weighting values,” and threshold comparisons may be performed individually or in combination via mental processes despite the fact that the claim recites these functions as being implemented by a machine. In other words, even the express recitation of machine implementation does not preclude these elements as falling within the judicial exception. The step of “automatically initiating at least a portion of a remotely-performable maintenance action … by transmitting …” represents computer processing (outputting and communication) activity having no particularized functional relation except as a outputting function to the key processing steps of determining a data value indicating that a service recommendation is remotely performable and determining a corresponding remotely performable maintenance suggestion such that this element constitutes insignificant extra solution activity.
Applicant further contends on pages 9-10 of the response that amended claim 1 cannot be performed by “generic” or “off-the-shelf” computers performing routing functions. In support, Applicant asserts that “[t]he recited processing requires a “… specialized configuration including (i) an intelligence machine learning model trained to output a remote-performability likelihood specifically from NLP-derived features of service case recommendation text together with maintained recommendation-specific weighting values; (ii) stored threshold logic used to classify remote performability in memory as part of a decision pipeline that drives actuation; and (iii) a network-command execution stack that formats and transmits remote-execution commands compatible with device/asset control interfaces.”
Examiner submits that application of machine learning to determine remote-performability likelihood using NLP-derived features does not appear to entail a form of specialized computer/processing configuration but rather conventional computer processing with the application-specialization substantially confined to the underlying algorithm that embodies the judicial exception. The high-level function behind machine implemented NLP itself constitutes a function that is routinely implemented via mental processes (recognizing and understanding text) and the claim does not appear configured to implement such NLP processing in a manner having a specialized function other than providing input data to the ML model. Similarly, the “weighting values” and “stored threshold logic” as claimed do not appear to amount to a specialized configuration representing a specialized use computer platform but instead represent ordinary storage and processing of data used to implement the judicial exception in an ordinary manner.
Examiner further notes that Applicant’s characterization of the network-transmitted commands includes features (execution stack, formats, control interfaces) that are not recited in the claim. On page 10 of the response, Applicant’s arguments also appear to incorporate inferences regarding the elements that are not recited in the claims. For example, Applicant characterizes the “weighting values” as being “persistently stored” and “dynamically updated” the NLP extraction as entailing NLP tokenization and embedding, and the comparing as being implemented for stored threshold “in memory.”
On page 10 of the response, Applicant further contends that amended claim 1 does not recite collecting, analyzing, and displaying information, and instead provides an end-to-end technological workflow that applies machine learning using stored weighting values and NLP extracted features, generates a numerical data value indicating likelihood of remote-performability, applies stored threshold logic to classify the recommendation, notifies a remote user, and automatically initiates a remote maintenance action by sending executable commands to the asset across a network.
Examiner submits that the foregoing features, as characterized in the amended independent claims, represent a substantially non-particularized computer system (storage, processor and input/output functions) for executing program instructions in the form of machine learning and otherwise that implement the functions falling within the judicial exception with the user notification and initiation of remote maintenance action, which providing an arguably useful result, failing to integrate the judicial exception into a practical application due to the lack of meaningful functional relation between the notifying and initiating steps and the steps for determining the data value indicating a likelihood of remote performability (i.e., the notifying and initiating maintenance steps would be broadly applicable in any sequence for determining maintenance actions). Therefore, these additional elements have no significant function relation to the elements falling within the judicial exception even in combination.
Regarding Step 2A Prong 2, Applicant contends on page 11 of the response that the steps of using NLP-derived features and machine-maintained weighting values to compute a likelihood metric, using stored thresholds to determine remote feasibility, outputting actionable maintenance suggestions, and automatically initiating remote maintenance actions by transmitting network commands modifies operation of the asset and produce a real-world effect in terms of its operation being automatically modified based on the maintenance determination.
Examiner submits, that while the operations set forth in the amended claims may result in modifications via maintenance to the asset (a real world result), claim 1 is “directed to” an abstract idea because the claim does not appear to include any combination of elements that integrate the judicial exception into a practical application. The effectuation of maintenance actions per the claims (initiating the maintenance actions by transmitting commands over a network) is standard procedure for implementing maintenance remotely such that the elements falling within the judicial exception (manner of determining which maintenance actions to ultimately select) themselves are not integrated into a practical application in a meaningful way in terms for example of the factors set forth for ascertaining such meaningful integration in MPEP 2106.05(a), (b), and (c).
Regarding Step 2B, Applicant contends on pages 11-12 of the response that amended claim 1 considered as a whole amounts to significantly more than the judicial exception because it provides an inventive concept.
Examiner submits, as set forth in further detail in the grounds for rejecting independent claims 1, 13, and 20 under 102 below, that the combination of elements recited by amended claim 1 are taught by Farahat (US 2020/0258057 A1), such that inventive concept as a potential avenue for determining that the claims amount to “significantly more” is not applicable.
Regarding the rejections of independent claims 1, 13, and 20 under 102, Applicant contends on pages 13-14 of the response that Farahat describes processing complaint test to build features generally for repair-action prediction, not to maintain per-recommendation weighting values for such classification, and that Farahat’s “probability of success” is tied to repair-action outcomes overall, not to a classification of remote vs. non-remote performability derived from maintaining weighting values for a service case recommendation and NLP-derived features from the recommendation text.
Examiner submits, as set forth in the current grounds of rejection that Farahat teaches maintaining weighting values that are used for determining the “values” (i.e., for classification) ([0080] features, which per FIG. 2 blocks 236, 219, and 238 are processed by the ML model in determining repair actions, are multiplied by weights indicating likelihood of success; [0091] service requests may include content (e.g., text) that may be weighted). As further set forth in the current grounds of rejection, Farahat teaches determining a data value indicating that a service case is remotely performable ([0016] ML model processes repair request data to determine repair actions/plan data, in which some of the actions may be non-remote or may be implemented remotely; [0038]-[0041] ML model determines repair plan/solution that may include remotely and non-remotely performed tasks in association with likelihood of success of repair actions (i.e., likelihood of success is a measure of performability of prospective remotely-implemented tasks); [0083]-[0085]).
On page 14 of the response, Applicant contends that Farahat does not teach maintaining recommendation-specific weighting values that are applied to compute a remote-performability likelihood. In support, Applicant asserts that “… Farahat speaks generally about ML features and probabilities of repair success across repair option but does not disclose per-recommendation weighting scores (persistent, maintained weight values tied to a specific “service case recommendation”) nor using such weights specifically to compute remote performability.
Examiner notes that Applicant’s arguments appear to extend beyond the language of the claims (e.g., “persistent,” “tied to a specific service case recommendation”). Furthermore, Examiner submits that Farahat teaches “the data value being generated using weighting values ([0080] features, which per FIG. 2 blocks 236, 219, and 238 are processed by the ML model in determining repair actions, are multiplied by weights indicating likelihood of success; [0091] service requests may include content (e.g., text) that may be weighted) maintained for the service case recommendation (storing the weight values is inherently required in order to implement the weighting of features such that the weights are maintained for service case processing).”
On page 14 of the response, Applicant contends that Farahat processes complaint text and other unstructured inputs to support general repair-action prediction and associated probability of success, not to derive a likelihood that a particular service case recommendation is remotely performable, and that Farahat fails to teach computing a remote-performability classifier using NLP-extracted features from the text of the service case recommendation itself together with maintained weighting values.
Examiner submits that as explained with reference to the disclosure of Farahat including [0038]-[0041] and [0083]-[0085], Farahat teaches deriving a likelihood of success for service case recommendations including recommendations for prospective servicing to be performed remotely. Furthermore, as set forth in the current grounds of rejection Farahat teaches using weighting values and NLP-extracted features for determining the “data value” - “the data value being generated using weighting values ([0080] features, which per FIG. 2 blocks 236, 219, and 238 are processed by the ML model in determining repair actions, are multiplied by weights indicating likelihood of success; [0091] service requests may include content (e.g., text) that may be weighted) maintained for the service case recommendation (storing the weight values is inherently required in order to implement the weighting of features such that the weights are maintained for service case processing) and at least in part on natural-language-processing-derived features extracted from text of the service case recommendation ([0091] service requests, per FIG. 2 block 230 are input to be processed by the ML model, may include free text features/variables that are recognized and extracted such that the processing includes natural-language-processing).”
On pages 14-15 of the response, Applicant contends that amended claim 1 “requires a stored threshold that, when satisfied, classifies the service case recommendation as remotely performable,” and contrasts Farahat’s thresholding as relating to whether the model’s overall probability of success exceeds a confidence level and therefore is not a threshold for “remote performability” of a service case recommendation and not described as a stored, memory-resident threshold expressly used to label a recommendation as remote per se.
Examiner submits, as set forth in the current grounds of rejection, that Farahat teaches using a stored threshold that when satisfied effectuates an indication that the service case recommendation is remotely performable – “determining, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one remotely performable maintenance suggestion from the at least one service case recommendation ([0016], [0041], and [0085] repair plan determined by ML model may include a remotely performable task that is associated with the original repair request data (e.g., per the processing of the ML model using historical repair data); FIG. 8 blocks 810 and 814) including comparing the data value to at least one stored threshold ([0038] and [0098] confidence in result ascertained (likelihood of success) as to whether below a threshold (threshold inherently required to be stored in order to be applied by the processing system); FIG. 8 block 806, [0128]) indicating that the service case recommendation is remotely performable (FIG. 8 blocks 806 and 810, [0128] and [0130] determination that likelihood of success exceeds threshold (determination that repair action is performable), in which per [0038]-[0041] the repair plan/solution may include remotely and non-remotely performed tasks; FIG. 8 depicting that the result of blocks 806 and 810 indicate at block 814 that the repair is remotely performable).”
On page 15 of the response, Applicant contends that while Farahat “mentions initiating a remote operation (e.g., firmware update), Farahat does not disclose that such remote operation is selected/triggered because the system computed a remote-performable likelihood for a service case recommendation using per-recommendation weights and NLP features and confirmed it against a stored threshold.
Examiner submits that Farahat discloses such relation between the remote-performable likelihood for a service case recommendation, in which as explained above entails use of weights and NLP features and is compared with a threshold, and the performance of the remote operation via Farahat’s teaching of “automatically initiating at least a portion of a remotely-performable maintenance action associated with the remotely-performable maintenance suggestion (FIG. 2 block 242 and [0085] execute and/or send repair plan that per [0040]-[0041] may be remotely performable (via the overall algorithm and hence automatic); [0040]-[0041]) by transmitting remote-execution commands to the asset (FIG. 2 block 242 and [0085] executable repair plan is executed and/or sent (overall execution/initiation of repair entails sending and executing) and such sending/executing may entail remote firmware update, which entails sending to and updating a remote asset (asset containing firmware)).
Claim Objections
Claims 1 and 13 objected to because of the following informalities:
In lines 7-9 of claim 1 and lines 10-12 of claim 13, “generated using weighting values maintained for the service case recommendation and at least in part on” should read “generated using weighting values maintained for the service case recommendation and based at least in part on”.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, 6, 8-15, and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention in each of these claims is directed to the abstract idea judicial exception without significantly more.
Independent claim 13, substantially representative also of independent claims 1 and 20, recites:
“[a]n apparatus comprising:
at least one processor; and
at least one memory storing computer-coded instructions that, when executed by the at least one processor, cause the apparatus to:
receive at least one service case recommendation associated with an asset;
apply the at least one service case recommendation to an intelligence machine learning model,
wherein the intelligence machine learning model is configured to determine a data value indicating a likelihood that each service case recommendation of the at least one service case recommendation is remotely performable, the data value being generated using weighting values maintained for the service case recommendation and at least in part on natural-language-processing-derived features extracted from text of the service case recommendation;
determine, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one remotely performable maintenance suggestion from the at least one service case recommendation including comparing the data value to at least one stored threshold indicating that the service case recommendation is remotely performable;
output at least one notification associated with the at least one remotely performable maintenance suggestion to a user associated with remote access of the asset; and
automatically initiate at least a portion of a remotely-performable maintenance action associated with the remotely-performable maintenance suggestion by transmitting remote-execution commands to the asset via a communications network.”
The claim limitations considered to fall within the abstract idea are highlighted in bold font above and the remaining features are “additional elements.”
Step 1 of the subject matter eligibility analysis entails determining whether the claimed subject matter falls within one of the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: process, machine, manufacture, or composition of matter. Claim 13 recites an apparatus, claim 1 recites a method, and claim 20 recites as apparatus and each therefore falls within a statutory category.
Step 2A, Prong One of the analysis entails determining whether the claim recites a judicial exception such as an abstract idea. Under a broadest reasonable interpretation, the highlighted portions of claim 13 fall within the abstract idea judicial exception. Specifically, under the 2019 Revised Patent Subject matter Eligibility Guidance, the highlighted subject matter falls within the mental processes category (including an observation, evaluation, judgment, opinion). MPEP § 2106.04(a)(2).
The recited functions:
“receive at least one service case recommendation associated with an asset,” and
“determine a data value indicating a likelihood that each service case recommendation of the at least one service case recommendation is remotely performable, the data value being generated using weighting values maintained for the service case recommendation and at least in part on natural-language-processing-derived features extracted from text of the service case recommendation,” and
“determine, via the data value output via the intelligent machine learning model for the at least one service case recommendation, at least one remotely performable maintenance suggestion from the at least one service case recommendation including comparing the data value to at least one stored threshold indicating that the service case recommendation is remotely performable,”
may be performed individually and/or in combination as mental processes.
Receiving at least one service case recommendation associated with an asset may be performed via mental processes (e.g., observation of service case recommendation data such as may be displayed on a computer display). Determining a data value indicating a likelihood that each service case recommendation of the at least one service case recommendation is remotely performable may be performed via mental processes (e.g., evaluation of service case recommendation data and judgement to determine likelihood that recommendation may be performed remotely (e.g., determine whether a recommendation that includes remote performance is likely to succeed)). Generating the data value using weighting values maintained for the service case recommendation and at least in part on natural-language-processing-derived features extracted from text of the service case recommendation may be performed via mental processes (e.g., evaluation of the service case recommendation data in view of factors influencing likelihood of success (weighting factors) that may be derived from evaluation of particular portions of explanatory text associated with service case recommendation to formulate, via judgement, a determination of performability of the service case recommendation). Determining, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one remotely performable maintenance suggestion from the at least one service case recommendation may also be performed via mental processes (e.g., evaluation of modeled output (or equivalent mentally derived determinations of service case recommendations being remotely performable) and judgement to determine a remotely performable maintenance suggestion) including comparing the data value to at least one stored threshold indicating that the service case recommendation is remotely performable (e.g., comparative evaluation of data value to stored threshold).
Step 2A, Prong Two of the analysis entails determining whether the claim includes additional elements that integrate the recited judicial exception into a practical application. “A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception” (MPEP § 2106.04(d)).
MPEP § 2106.04(d) sets forth considerations to be applied in Step 2A, Prong Two for determining whether or not a claim integrates a judicial exception into a practical application. Based on the individual and collective limitations of claim 13 and applying a broadest reasonable interpretation, the most applicable of such considerations appear to include: improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)); applying the judicial exception with, or by use of, a particular machine (MPEP 2106.05(b)); and effecting a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)).
Regarding improvements to the functioning of a computer or other technology, none of the “additional elements” including “at least one processor,” “at least one memory storing computer-coded instructions that, when executed by the at least one processor, cause the apparatus to” perform the method steps via an “intelligent machine learning model,” “apply the at least one service case recommendation to an intelligence machine learning model,” and “output at least one notification associated with the at least one remotely performable maintenance suggestion to a user associated with remote access of the asset,” and “automatically initiate at least a portion of a remotely-performable maintenance action associated with the remotely-performable maintenance suggestion by transmitting remote-execution commands to the asset via a communications network” in any combination appear to integrate the abstract idea in a manner that technologically improves any aspect of a device or system that may be used to implement the highlighted step or a device for implementing the highlighted step such as a signal processing device or a generic computer.
Instead, “at least one processor,” “at least one memory storing computer-coded instructions that, when executed by the at least one processor, cause the apparatus to” perform the method steps including via machine learning represent conventional, routine computer processing components/functions for implementing the method steps falling within the judicial exception and therefore constitute extra solution activity that fails to integrate the judicial exception into a practical application. The step “apply the at least one service case recommendation to an intelligence machine learning model,” represents conventional, routine instruction-based computer processing (machine learning modeling) at a high level for implementing the functions of the steps falling within the judicial exception and therefore constitutes extra solution activity that fails to integrate the judicial exception into a practical application. The use of an “intelligent machine learning model” to perform the determining of the data value represents routine, conventional program instructions (machine learning) for implementing the underlying function that may be performed via mental processes and therefore constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception. The step “output at least one notification associated with the at least one remotely performable maintenance suggestion to a user associated with remote access of the asset,” represents conventional, routing computer processing (outputting data results) at a high level of generality having no particularized functional relation to the method steps falling within the judicial exception and therefore constitutes insignificant post-solution activity that fails to integrate the judicial exception into a practical application. Automatically initiating a remotely performable maintenance action associated with the remotely performable maintenance suggestion by transmitting remote-execution commands to the asset via a communication network,” represents computer-implemented control of a repair/maintenance control system in terms of outputting data derived from the processing steps and having no particularized functional relation to the method steps falling within the judicial exception and therefore constitutes insignificant post-solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception. Regarding the electronic aspect of “weighting” per characterization in Applicant’s specification in [0055], this aspect to the extent it may be relevant in determining the scope of “weighting values,” represents computer implementation of “using weighting values,” which as explained above falls within the mental processes exception, and therefore constitutes insignificant extra solution activity.
Regarding application of the judicial exception with, or by use of, a particular machine, the additional elements are configured and implemented in a conventional rather than a particularized manner of implementing equipment maintenance planning.
Regarding a transformation or reduction of a particular article to a different state or thing, claim 13 does not include any such transformation or reduction. Instead, claim 13 as a whole entails receiving input information (service case recommendation), applying standard processing techniques (e.g., machine learning type modeling) to the information to determine conceptual maintenance/repair recommendation/suggestion information with the additional elements failing to provide a meaningful integration of the abstract idea (determining likelihood that recommendation may be performed remotely and determining/identifying a remotely performable maintenance suggestion) in an application that transforms an article to a different state. Instead, the additional elements represent insignificant extra-solution activity that does not integrate the judicial exception into a practical application. In view of the various considerations encompassed by the Step 2A, Prong Two analysis, claim 13 does not include additional elements that integrate the recited abstract idea into a practical application.
Therefore, claim 13 is directed to a judicial exception and requires further analysis under Step 2B.
Regarding Step 2B, and as explained in the Step 2A Prong Two analysis, the additional elements constitute insignificant extra solution activity and therefore, in addition to failing to integrate the judicial exception into a practical application, also fail to result in the claim as a whole amounting to significantly more than the judicial exception. Furthermore, the additional elements in claim 13 appear to be generic and well understood as evidenced by the disclosures of Farahat (US 2020/0258057 A1) and Gosh (US 2020/0097921 A1), each of which teach substantially similar computer processing and data modeling functions for processing repair requests.
As explained in the grounds for rejecting claim 13 under 102, Farahat teaches “at least one processor,” “at least one memory storing computer-coded instructions that, when executed by the at least one processor, cause the apparatus to” perform the method steps, “apply the at least one service case recommendation to an intelligence machine learning model,” and “output at least one notification associated with the at least one remotely performable maintenance suggestion to a user associated with remote access of the asset,” and “automatically initiate at least a portion of a remotely-performable maintenance action associated with the remotely-performable maintenance suggestion by transmitting remote-execution commands to the asset via a communications network,” as does Gosh (see FIG. 1 computer system 100 and client computing devices 115 with repair requests 150 processed by service computing device 102 including machine learning models 140 and with service computing device 102 outputting notifications in the form of repair instructions 162; FIG. 1 network 106 for communicating repair actions/plans from service computing device 102 to assets).
The Examiner notes that even if “receive at least one service case recommendation associated with an asset” is interpreted more narrowly so as to fall outside the mental processes judicial exception, this element represents high-level data collection that fails to integrate the judicial exception into a practical application or result in the claim as a whole amounting to significantly more than the judicial exception.
Therefore, the additional elements are insufficient to amount to significantly more than the judicial exception.
Independent claim 13 is therefore not patent eligible under 101.
Independent claims 1 and 20 include substantially the same elements falling within the judicial exception as claim 13 and include nor further significant additional elements that either integrate the judicial exception into a practical application or result in the claim as a whole amounting to significantly more than the judicial exception.
Therefore, claims 1 and 20 are also not patent eligible under 101.
Claims 2-4, 6, and 8-12 depending from claim 1, and claims 14-15 and 17-19 depending from claim 13 provide additional features/steps which are part of an expanded algorithm that includes the abstract idea of the respective independent claim (Step 2A, Prong One). None of dependent claims 2-4, 6, 8-12, 14-15 and 17-19 recite additional elements that integrate the abstract idea into practical application (Step 2A, Prong Two), and all fail the “significantly more” test under the step 2B for substantially similar reasons as discussed with regards to the independent claims.
For example, claim 2, substantially representative also of claim 14 further recites “determining, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one non-remotely performable maintenance suggestion,” which falls within the mental processes judicial exception because it may be performed via mental processes (e.g., evaluation of data output from machine learning model and judgement to determine a non-remotely performable maintenance suggestion). Claim 2 further recites the additional element “outputting at least one additional notification associated with the non-remotely performable maintenance suggestion to the user,” which represents conventional, routing computer processing (outputting data results) at a high level of generality having no particularized functional relation to the method steps falling within the judicial exception and therefore constitutes insignificant post-solution activity that fails to integrate the judicial exception into a practical application.
Claim 3, substantially representative also of claim 15, further recites the additional element “outputting at least one additional notification associated with a non-remotely performable maintenance suggestion to a second user associated with performing a non-remotely performable maintenance action of the asset,” which represents conventional, routing computer processing (outputting data results) at a high level of generality having no particularized functional relation to the method steps falling within the judicial exception and therefore constitutes insignificant post-solution activity that fails to integrate the judicial exception into a practical application.
Claim 4 further recites “wherein the at least one service case recommendation is determined based at least in part on an alert generation rule for the asset,” which falls within the mental processes judicial exception because it may be performed via mental processes (e.g., evaluation of alert generation information and judgement in determining a service case recommendation).
Claim 6, substantially representative also of claim 17, further recites “updating the intelligence machine learning model based at least in part on user review data indicating whether a particular service case recommendation of the at least one service case recommendation is accurately characterized as remotely performable or not remotely performable,” which represents routine, conventional computer processing for generating program instructions (updating/re-training a machine learning model using data relevant to service case recommendation processing) for implementing the method steps falling within the judicial exception and therefore constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 8 (substantially representative also of claim 18) and claim 10 recite elements that may be performed via mental processes and therefore fall within the mental processes judicial exception.
Claims 9 and 11 each recite using natural language processing as part of “determining at least a first service case recommendation of the at least one service case recommendation is always remotely performable” in claim 8 and “determining at least a first service case recommendation of the at least one service case recommendation is always not remotely performable” in claim 10. This additional element represents conventional, routine computer-implemented data processing for preparing/collecting input data at a high-level and having no particularized functional relation to the method steps falling within the judicial exception such that this element constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 12, substantially representative also of claim 19, further recites “determine the data value indicating the likelihood that each service case recommendation of the at least one service case recommendation is remotely performable based at least in part on the user configuration data,” which falls within the mental processes judicial exception because it can be performed via mental processes (e.g., evaluation of user configuration data and judgement to determine data indicative of likelihood that service case recommendation is remotely performable). The application of user configuration data to a machine learning model and use of the model to perform the determination represents routine, conventional data processing functions (inputting of data to a model and use of program instructions (model) to compute a determination) that constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6, 8-15, and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Farahat (US 2020/0258057 A1).
As to claim 1, Farahat teaches “[a] computer-implemented method (Abstract; method implemented by service computing device 102 and computing devices 116, 112, and 114; FIG. 2) comprising:
receiving at least one service case recommendation associated with an asset (FIG. 1 repair request 150 received by service computing device 102 via network 106; FIG. 2 block 230; [0037] equipment may be manufacturing equipment; [0037]-[0038] repair request includes information relating to the corresponding equipment for which repair action is being requested (i.e., repair request characterizes an action for repair in terms of the equipment in response to (incidental to) a sender of the request being made aware (alerted to) a need for repair); [0078] repair request is accompanied by (effectively includes) historical repair data for the equipment; [0016]-[0017], [0027], [0030]-[0031], and [0081] historical repair data used in ML training and ML application to determine repair actions (i.e., historical repair data indicates repair actions associated with the equipment). In sum, the repair request constitutes a recommendation for repair action that includes particular instances of repair activities.);
applying the at least one service case recommendation to an intelligence machine learning model (FIG. 1 machine learning model(s) 140 configured to receive/process data repair request 150; FIG. 2 blocks 230, 219, 236, and 238; [0016], [0031] machine learning (ML) model receives the repair request data),
wherein the intelligence machine learning model is configured to determine a data value indicating a likelihood that each service case recommendation of the at least one service case recommendation is remotely performable ([0016] ML model processes repair request data to determine repair actions/plan data, in which some of the actions may be non-remote or may be implemented remotely; [0038]-[0041] ML model determines repair plan/solution that may include remotely and non-remotely performed tasks in association with likelihood of success of repair actions; [0083]-[0085]), the data value being generated using weighting values ([0080] features, which per FIG. 2 blocks 236, 219, and 238 are processed by the ML model in determining repair actions, are multiplied by weights indicating likelihood of success; [0091] service requests may include content (e.g., text) that may be weighted) maintained for the service case recommendation (storing the weight values is inherently required in order to implement the weighting of features such that the weights are maintained for service case processing) and at least in part on natural-language-processing-derived features extracted from text of the service case recommendation ([0091] service requests, per FIG. 2 block 230 are input to be processed by the ML model, may include free text features/variables that are recognized and extracted such that the processing includes natural-language-processing);
determining, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one remotely performable maintenance suggestion from the at least one service case recommendation ([0016], [0041], and [0085] repair plan determined by ML model may include a remotely performable task that is associated with the original repair request data (e.g., per the processing of the ML model using historical repair data); FIG. 8 blocks 810 and 814) including comparing the data value to at least one stored threshold ([0038] and [0098] confidence in result ascertained (likelihood of success) as to whether below a threshold (threshold inherently required to be stored in order to be applied by the processing system); FIG. 8 block 806, [0128]) indicating that the service case recommendation is remotely performable (FIG. 8 blocks 806 and 810, [0128] and [0130] determination that likelihood of success exceeds threshold (determination that repair action is performable), in which per [0038]-[0041] the repair plan/solution may include remotely and non-remotely performed tasks; FIG. 8 depicting that the result of blocks 806 and 810 indicate at block 814 that the repair is remotely performable);
outputting at least one notification associated with the at least one remotely performable maintenance suggestion (FIG. 1 machine learning model(s) 140 configured to output repair plan/actions for processing by repair plan execution program 136 (entails effective notification) and repair plan execution program 136 configured to output repair instructions to equipment and repairer computing devices 116, 112, and 114; FIG. 2 block 242; FIG. 8 block 814 initiating remote repair inherently entails instructions that effectively notify the remote entity; [0016], [0040]-[0041] repair plan execution unit 136 executes (and therefore has received) some portion of the repair plan) to a user associated with remote access of the asset (FIG. 1 repair plan execution program 136 (intelligent entity that interacts with (uses) representations of maintenance suggestions) has remote access to equipment via network 106 such as via sending repair instructions, [0040]-[0041]); and
automatically initiating at least a portion of a remotely-performable maintenance action associated with the remotely-performable maintenance suggestion (FIG. 2 block 242 and [0085] execute and/or send repair plan that per [0040]-[0041] may be remotely performable (via the overall algorithm and hence automatic); [0040]-[0041]) by transmitting remote-execution commands to the asset (FIG. 2 block 242 and [0085] executable repair plan is executed and/or sent (overall execution/initiation of repair entails sending and executing) and such sending/executing may entail remote firmware update, which entails sending to and updating a remote asset (asset containing firmware)) via a communications network (FIG. 1 computing system 100 includes network 106 across which repair plans generated by repair management program 126, repair plan execution program 136, machine learning models, etc. (functions implemented via real time repair processing 204 per [0044]) are sent to assets, [0021] and [0035]).”
As to claim 2, Farahat teaches “[t]he computer-implemented method of claim 1, further comprising:
determining, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one non-remotely performable maintenance suggestion ([0016] ML model determines repair plan that may include instructions to a repairer (FIG. 1 depicting repairers 154 performing on-site equipment repair (requiring physical interaction with equipment)), FIG. 1 repair plans/instructions 156, 162 send to repairers 154, [0039]-[0040]; FIG. 4 repair action “Replace Temperature Sensor”; FIG. 8 blocks 810 and 816); and
outputting at least one additional notification associated with the non-remotely performable maintenance suggestion ([0016], [0027] repair plan execution unit 136 configured to send repair plans to on-site repairer; [0040] a portion of the repair plan may be implemented remotely (i.e., the plan may include remote and non-remote actions with corresponding output notifications); [0085] FIG. 8 block 816, [0133]) to the user (“user” may be repairers 154 (FIG. 1) and/or repair plan execution program 136 that receives the repair plans including instructions for performing remote and/or non-remote repair actions).
As to claim 3, Farahat teaches “[t]he computer-implemented method of claim 1, further comprising:
outputting at least one additional notification associated with a non-remotely performable maintenance suggestion (FIG. 1 repair plans/instructions 156, 162 send to repairers 154, [0039]-[0040]; FIG. 4 repair action “Replace Temperature Sensor”; FIG. 8 blocks 810 and 816; [0016], [0027] repair plan execution unit 136 configured to send repair plans to on-site repairer; [0040] a portion of the repair plan may be implemented remotely (i.e., the plan may include remote and non-remote actions with corresponding output notifications); [0085] FIG. 8 block 816, [0133]) to a second user associated with performing a non-remotely performable maintenance action of the asset (second user may be repairers 154 (FIG. 1) and/or repair plan execution program 136 that receives the repair plans including instructions for performing remote and/or non-remote repair actions).”
As to claim 4, Farahat teaches “[t]he computer-implemented method of claim 1, wherein the at least one service case recommendation is determined based at least in part on an alert generation rule for the asset ([0016] system input (repair request) may include complaints or other information indicating a failure (e.g., user applied judgement (rule) based on observation); [0051] complaints or analogous alerts such as error/fault codes; [0061], [0088]).”
As to claim 6, Farahat teaches “[t]he computer-implemented method of claim 1, further comprising:
updating the intelligence machine learning model based at least in part on user review data indicating whether a particular service case recommendation of the at least one service case recommendation is accurately characterized as remotely performable or not remotely performable (FIG. 8 blocks 820 and 824, [0135]-[0137] ML model re-trained based on computing device (user configured/applied device) determining whether the repair solution, which as explained in the grounds for rejecting claim 1 may include remote repair actions, was successful).”
As to claim 8, Farahat teaches “[t]he computer-implemented method of claim 1,” and further teaches a determining a likelihood/probability of a service case recommendation being remotely performable in terms of a likelihood/probability which inherently is a range from 0-100% ([0038]-[0041] and [0074] and [0083] ML model determines repair plan/solution that may include remotely and non-remotely performed tasks in association with likelihood of success of repair actions. Examiner notes that a likelihood is a probability that ranges from 0-100%). The application of such probability/likelihood processing would incidentally result in some instances in which the probability/likelihood is at or near 100% indicating substantial certainty of the service case recommendation (which as set forth in the grounds for rejecting claim 1 may include actions to be performed remotely) may always be performed successfully such that the method includes “determining at least a first service case recommendation of the at least one service case recommendation is always remotely performable.”
As to claim 9, Farahat teaches “[t]he computer-implemented method of claim 8, wherein determining at least the first service case recommendation of the at least one service case recommendation is always remotely performable comprising:
processing text data associated with the at least the first service case recommendation utilizing at least one natural language processing model ([0016] system input (repair request) to be processed includes natural language complaints; [0017] historical repair data may include free-form text; [0060] language processing via optical character recognition (OCR) modeling (machine learning), [0088], [0091] processing of input text (requires some form of modeling/processing) for eventual processing by ML model).”
As to claim 10, Farahat teaches “[t]he computer-implemented method of claim 1,” and further teaches a determining a likelihood/probability of a service case recommendation being remotely performable in terms of a likelihood/probability which inherently is a range from 0-100% ([0038]-[0041] and [0074] and [0083] ML model determines repair plan/solution that may include remotely and non-remotely performed tasks in association with likelihood of success of repair actions. Examiner notes that a likelihood is a probability that ranges from 0-100%). The application of such probability/likelihood processing would incidentally result in some instances in which the probability/likelihood is at or near 0% indicating substantial certainty of the service case recommendation (which as set forth in the grounds for rejecting claim 1 may include actions to be performed remotely) not being able to be performed remotely such that the method includes “determining at least a first service case recommendation of the at least one service case recommendation is always not remotely performable.”
As to claim 11, Farahat teaches “[t]he computer-implemented method of claim 10, wherein determining at least the first service case recommendation of the at least one service case recommendation is not always performable comprises:
processing text data associated with the first service case recommendation utilizing at least one natural language processing model ([0016] system input (repair request) to be processed includes natural language complaints; [0017] historical repair data may include free-form text; [0060] language processing via optical character recognition (OCR) modeling (machine learning), [0088], [0091] processing of input text (requires some form of modeling/processing) for eventual processing by ML model).
As to claim 12, Farahat teaches “[t]he computer-implemented method of claim 1, further comprising:
applying user configuration data to the intelligence machine learning model (FIG. 8 block 822 feedback from repair result determination (data representative of user-implemented repair processing and entailing data indicative of probability/likelihood of success) used as part of new repair request (applied to ML model) and block 824 ML model re-trained using repair result),
wherein the intelligence machine learning model is configured to determine the data value indicating the likelihood that each service case recommendation of the at least one service case recommendation is remotely performable based at least in part on the user configuration data (FIG. 8 modelling determinations at blocks 804 and 806 are based, at least in part on inputs from block 822 or block 824).
As to claim 13, Farahat teaches “[a]n apparatus (FIG. 1 computing system 100 and client computing devices 110) comprising:
at least one processor (FIG. 1 processors 120); and
at least one memory storing computer-coded instructions that, when executed by the at least one processor (FIG. 1 computer-readable media 124 configured cooperatively with processors 120 for implementing program/instruction execution), cause the apparatus to:
receive at least one service case recommendation associated with an asset (FIG. 1 repair request 150 received by service computing device 102 via network 106; FIG. 2 block 230; [0037] equipment may be manufacturing equipment; [0037]-[0038] repair request includes information relating to the corresponding equipment for which repair action is being requested (i.e., repair request characterizes an action for repair in terms of the equipment in response to (incidental to) a sender of the request being made aware (alerted to) a need for repair); [0078] repair request is accompanied by (effectively includes) historical repair data for the equipment; [0016]-[0017], [0027], [0030]-[0031], and [0081] historical repair data used in ML training and ML application to determine repair actions (i.e., historical repair data indicates repair actions associated with the equipment). In sum, the repair request constitutes a recommendation for repair action that includes particular instances of repair activities.);
apply the at least one service case recommendation to an intelligence machine learning model (FIG. 1 machine learning model(s) 140 configured to receive/process data repair request 150; FIG. 2 blocks 230, 219, 236, and 238; [0016], [0031] machine learning (ML) model receives the repair request data),
wherein the intelligence machine learning model is configured to determine a data value indicating a likelihood that each service case recommendation of the at least one service case recommendation is remotely performable ([0016] ML model processes repair request data to determine repair actions/plan data, in which some of the actions may be non-remote or may be implemented remotely; [0038]-[0041] ML model determines repair plan/solution that may include remotely and non-remotely performed tasks in association with likelihood of success of repair actions; [0083]-[0085]) ]), the data value being generated using weighting values ([0080] features, which per FIG. 2 blocks 236, 219, and 238 are processed by the ML model in determining repair actions, are multiplied by weights indicating likelihood of success; [0091] service requests may include content (e.g., text) that may be weighted) maintained for the service case recommendation (storing the weight values is inherently required in order to implement the weighting of features such that the weights are maintained for service case processing) and at least in part on natural-language-processing-derived features extracted from text of the service case recommendation ([0091] service requests, per FIG. 2 block 230 are input to be processed by the ML model, may include free text features/variables that are recognized and extracted such that the processing includes natural-language-processing);
determine, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one remotely performable maintenance suggestion from the at least one service case recommendation ([0016], [0041], and [0085] repair plan determined by ML model may include a remotely performable task that is associated with the original repair request data (e.g., per the processing of the ML model using historical repair data); FIG. 8 blocks 810 and 814) including comparing the data value to at least one stored threshold ([0038] and [0098] confidence in result ascertained (likelihood of success) as to whether below a threshold (threshold inherently required to be stored in order to be applied by the processing system); FIG. 8 block 806, [0128]) indicating that the service case recommendation is remotely performable (FIG. 8 blocks 806 and 810, [0128] and [0130] determination that likelihood of success exceeds threshold (determination that repair action is performable), in which per [0038]-[0041] the repair plan/solution may include remotely and non-remotely performed tasks; FIG. 8 depicting that the result of blocks 806 and 810 indicate at block 814 that the repair is remotely performable);
output at least one notification associated with the at least one remotely performable maintenance suggestion (FIG. 1 machine learning model(s) 140 configured to output repair plan/actions for processing by repair plan execution program 136 (entails effective notification) and repair plan execution program 136 configured to output repair instructions to equipment and repairer computing devices 116, 112, and 114; FIG. 2 block 242; FIG. 8 block 814 initiating remote repair inherently entails instructions that effectively notify the remote entity; [0016], [0040]-[0041] repair plan execution unit 136 executes (and therefore has received) some portion of the repair plan) to a user associated with remote access of the asset (FIG. 1 repair plan execution program 136 (intelligent entity that interacts with (uses) representations of maintenance suggestions) has remote access to equipment via network 106 such as via sending repair instructions, [0040]-[0041]); and
automatically initiate at least a portion of a remotely-performable maintenance action associated with the remotely-performable maintenance suggestion (FIG. 2 block 242 and [0085] execute and/or send repair plan that per [0040]-[0041] may be remotely performable (via the overall algorithm and hence automatic); [0040]-[0041]) by transmitting remote-execution commands to the asset (FIG. 2 block 242 and [0085] executable repair plan is executed and/or sent (overall execution/initiation of repair entails sending and executing) and such sending/executing may entail remote firmware update, which entails sending to and updating a remote asset (asset containing firmware)) via a communications network (FIG. 1 computing system 100 includes network 106 across which repair plans generated by repair management program 126, repair plan execution program 136, machine learning models, etc. (functions implemented via real time repair processing 204 per [0044]) are sent to assets, [0021] and [0035]).”
As to claim 14, Farahat teaches “[t]he apparatus of claim 13, wherein the instructions further cause the apparatus to:
determine, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one non-remotely performable maintenance suggestion ([0016] ML model determines repair plan that may include instructions to a repairer (FIG. 1 depicting repairers 154 performing on-site equipment repair (requiring physical interaction with equipment)), FIG. 1 repair plans/instructions 156, 162 send to repairers 154, [0039]-[0040]; FIG. 4 repair action “Replace Temperature Sensor”; FIG. 8 blocks 810 and 816); and
output at least one additional notification associated with the non-remotely performable maintenance suggestion ([0016], [0027] repair plan execution unit 136 configured to send repair plans to on-site repairer; [0040] a portion of the repair plan may be implemented remotely (i.e., the plan may include remote and non-remote actions with corresponding output notifications); [0085] FIG. 8 block 816, [0133]) to the user (“user” may be repairers 154 (FIG. 1) and/or repair plan execution program 136 that receives the repair plans including instructions for performing remote and/or non-remote repair actions).”
As to claim 15, Farahat teaches “[t]he apparatus of claim 13, wherein the instructions further cause the apparatus to:
output at least one additional notification associated with a non-remotely performable maintenance suggestion (FIG. 1 repair plans/instructions 156, 162 send to repairers 154, [0039]-[0040]; FIG. 4 repair action “Replace Temperature Sensor”; FIG. 8 blocks 810 and 816; [0016], [0027] repair plan execution unit 136 configured to send repair plans to on-site repairer; [0040] a portion of the repair plan may be implemented remotely (i.e., the plan may include remote and non-remote actions with corresponding output notifications); [0085] FIG. 8 block 816, [0133]) to a second user associated with performing a non-remotely performable maintenance action of the asset (second user may be repairers 154 (FIG. 1) and/or repair plan execution program 136 that receives the repair plans including instructions for performing remote and/or non-remote repair actions).”
As to claim 17, Farahat teaches “[t]he apparatus of claim 13, wherein the instructions further cause the apparatus to:
update the intelligence machine learning model based at least in part on user review data indicating whether a particular service case recommendation of the at least one service case recommendation is accurately characterized as remotely performable or not remotely performable (FIG. 8 blocks 820 and 824, [0135]-[0137] ML model re-trained based on computing device (user configured/applied device) determining whether the repair solution, which as explained in the grounds for rejecting claim 1 may include remote repair actions, was successful).”
As to claim 18, Farahat teaches “[t]he apparatus of claim 13,” and further teaches a determining a likelihood/probability of a service case recommendation being remotely performable in terms of a likelihood/probability which inherently is a range from 0-100% ([0038]-[0041] and [0074] and [0083] ML model determines repair plan/solution that may include remotely and non-remotely performed tasks in association with likelihood of success of repair actions. Examiner notes that a likelihood is a probability that ranges from 0-100%). The application of such probability/likelihood processing would incidentally result in some instances in which the probability/likelihood is at or near 100% indicating substantial certainty of the service case recommendation (which as set forth in the grounds for rejecting claim 1 may include actions to be performed remotely) may always be performed successfully such that the instructions cause the apparatus to “determine at least a first service case recommendation of the at least one service case recommendation is always remotely performable.”
As to claim 19, Farahat teaches “[t]he apparatus of claim 13, wherein the instructions further cause the apparatus to:
apply user configuration data to the intelligence machine learning model (FIG. 8 block 822 feedback from repair result determination (data representative of user-implemented repair processing and entailing data indicative of probability/likelihood of success) used as part of new repair request (applied to ML model) and block 824 ML model re-trained using repair result),
wherein the intelligence machine learning model is configured to determine the data value indicating the likelihood that each service case recommendation of the at least one service case recommendation is remotely performable based at least in part on the user configuration data (FIG. 8 modelling determinations at blocks 804 and 806 are based, at least in part on inputs from block 822 or block 824).”
As to claim 20, Farahat teaches “[a] computer program product comprising at least one non-transitory computer-readable storage medium, the at least one non-transitory computer-readable storage medium including computer program code that when executed by at least one processor (FIG. 1 computer-readable media 124 configured cooperatively with processors 120 for implementing program/instruction execution), configures the at least one processor to:
receive at least one service case recommendation associated with an asset (FIG. 1 repair request 150 received by service computing device 102 via network 106; FIG. 2 block 230; [0037] equipment may be manufacturing equipment; [0037]-[0038] repair request includes information relating to the corresponding equipment for which repair action is being requested (i.e., repair request characterizes an action for repair in terms of the equipment in response to (incidental to) a sender of the request being made aware (alerted to) a need for repair); [0078] repair request is accompanied by (effectively includes) historical repair data for the equipment; [0016]-[0017], [0027], [0030]-[0031], and [0081] historical repair data used in ML training and ML application to determine repair actions (i.e., historical repair data indicates repair actions associated with the equipment). In sum, the repair request constitutes a recommendation for repair action that includes particular instances of repair activities.);
apply the at least one service case recommendation to an intelligence machine learning model (FIG. 1 machine learning model(s) 140 configured to receive/process data repair request 150; FIG. 2 blocks 230, 219, 236, and 238; [0016], [0031] machine learning (ML) model receives the repair request data),
wherein the intelligence machine learning model is configured to determine a data value indicating a likelihood that each service case recommendation of the at least one service case recommendation is remotely performable ([0016] ML model processes repair request data to determine repair actions/plan data, in which some of the actions may be non-remote or may be implemented remotely; [0038]-[0041] ML model determines repair plan/solution that may include remotely and non-remotely performed tasks in association with likelihood of success of repair actions; [0083]-[0085]), the data value being generated using weighting values ([0080] features, which per FIG. 2 blocks 236, 219, and 238 are processed by the ML model in determining repair actions, are multiplied by weights indicating likelihood of success; [0091] service requests may include content (e.g., text) that may be weighted) maintained for the service case recommendation (storing the weight values is inherently required in order to implement the weighting of features such that the weights are maintained for service case processing) and at least in part on natural-language-processing-derived features extracted from text of the service case recommendation ([0091] service requests, per FIG. 2 block 230 are input to be processed by the ML model, may include free text features/variables that are recognized and extracted such that the processing includes natural-language-processing);
determine, via the data value output via the intelligence machine learning model for the at least one service case recommendation, at least one remotely performable maintenance suggestion from the at least one service case recommendation ([0016], [0041], and [0085] repair plan determined by ML model may include a remotely performable task that is associated with the original repair request data (e.g., per the processing of the ML model using historical repair data); FIG. 8 blocks 810 and 814) including comparing the data value to at least one stored threshold ([0038] and [0098] confidence in result ascertained (likelihood of success) as to whether below a threshold (threshold inherently required to be stored in order to be applied by the processing system); FIG. 8 block 806, [0128]) indicating that the service case recommendation is remotely performable (FIG. 8 blocks 806 and 810, [0128] and [0130] determination that likelihood of success exceeds threshold (determination that repair action is performable), in which per [0038]-[0041] the repair plan/solution may include remotely and non-remotely performed tasks; FIG. 8 depicting that the result of blocks 806 and 810 indicate at block 814 that the repair is remotely performable);
output at least one notification associated with the at least one remotely performable maintenance suggestion (FIG. 1 machine learning model(s) 140 configured to output repair plan/actions for processing by repair plan execution program 136 (entails effective notification) and repair plan execution program 136 configured to output repair instructions to equipment and repairer computing devices 116, 112, and 114; FIG. 2 block 242; FIG. 8 block 814 initiating remote repair inherently entails instructions that effectively notify the remote entity; [0016], [0040]-[0041] repair plan execution unit 136 executes (and therefore has received) some portion of the repair plan) to a user associated with remote access of the asset (FIG. 1 repair plan execution program 136 (intelligent entity that interacts with (uses) representations of maintenance suggestions) has remote access to equipment via network 106 such as via sending repair instructions, [0040]-[0041]); and
automatically initiate at least a portion of a remotely-performable maintenance action associated with the remotely-performable maintenance suggestion (FIG. 2 block 242 and [0085] execute and/or send repair plan that per [0040]-[0041] may be remotely performable (via the overall algorithm and hence automatic); [0040]-[0041]) by transmitting remote-execution commands to the asset (FIG. 2 block 242 and [0085] executable repair plan is executed and/or sent (overall execution/initiation of repair entails sending and executing) and such sending/executing may entail remote firmware update, which entails sending to and updating a remote asset (asset containing firmware)) via a communications network (FIG. 1 computing system 100 includes network 106 across which repair plans generated by repair management program 126, repair plan execution program 136, machine learning models, etc. (functions implemented via real time repair processing 204 per [0044]) are sent to assets, [0021] and [0035]).”
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW W BACA whose telephone number is (571)272-2507. The examiner can normally be reached Monday - Friday 8:00 am - 5:30 pm.
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, Andrew Schechter can be reached at (571) 272-2302. 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.
/MATTHEW W. BACA/Examiner, Art Unit 2857
/ANDREW SCHECHTER/Supervisory Patent Examiner, Art Unit 2857
Prosecution Insights