Prosecution Insights
Last updated: April 19, 2026
Application No. 18/653,406

SYSTEM, METHOD, AND MOBILE APPLICATION FOR LOCATING MEDICAL CARE CENTERS

Non-Final OA §101
Filed
May 02, 2024
Examiner
RUIZ, JOSHUA DAMIAN
Art Unit
3684
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Carecompass
OA Round
3 (Non-Final)
0%
Grant Probability
At Risk
3-4
OA Rounds
3y 0m
To Grant
0%
With Interview

Examiner Intelligence

Grants only 0% of cases
0%
Career Allow Rate
0 granted / 7 resolved
-52.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
41 currently pending
Career history
48
Total Applications
across all art units

Statute-Specific Performance

§101
32.5%
-7.5% vs TC avg
§103
33.3%
-6.7% vs TC avg
§102
16.0%
-24.0% vs TC avg
§112
12.3%
-27.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 7 resolved cases

Office Action

§101
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 . Status of the Claims The status of the claims as of the response filed December 29, 2025, is as follows: Claims 1, 3, 4, 5, 10, 13, 15, 16, 17, 19, and 21 pending, while Claims 2, 6, 7, 8, 9, 11, 12, 14, 18, and 20 have been canceled. Although no claims were explicitly marked as amended in the provided text, Claim 21 is newly added and is addressed in the analysis below. Request for Continued Examination A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/29/2025 has been entered. Response to Arguments Applicant's arguments, see pages 12-16 filed 12/29/2025, with respect to amended Claims 1, 13, and new Claim 21 have been fully considered and are not persuasive. Pending Claims 1, 3, 4, 5, 10, 13, 15, 16, 17, 19, and 21 and are addressed below. 35 USC § 101 Applicant argues the Office Action “fails to provide a prima facie case” because the “human replication” example includes physical actions (calling clinics/patient), and therefore the claims allegedly do not recite a “mental process” under MPEP § 2106.04(a)(2)(III)(A). The examiner disagrees: Even when the example uses physical actions (making a phone call) between human interaction (the method of organizing human activities), it does not negate the mental process. Because prong one ask whether the claim limitations recite abstract idea and Claims 1 and 13 expressly recite results of “conducting… triage,” “analyzing… estimated wait time,” “determining… combined drive and wait time,” and “determining… low/best/high/medium match” which are assessments and categorizations of information and therefore fall within mental processes as described in MPEP § 2106.04(a)(2)(III) and prong one evaluation below provided identify of the abstract idea (mental + human activities) each one with their rationales based on fact applicant language and the rule of MPEP 2106, and further explain how a human could mirror the abstract idea recited in the independent claims, that constitutes a complete prima face, further in prong two/step 2B identify additional elements and provided rational to explain why and how do not overcome prong two and step 2b. Refer to prong one below for further details. Applicant Argument, MPEP § 2106.04(a)(2)(III)(A) states claims do not recite a mental process when they do not contain limitations that can practically be performed in the human mind. Examiner respectfully disagrees. The Applicant cites the correct legal standard but does not identify any specific claim limitation where "the human mind is not equipped to perform" it the cases escaping the mental process grouping involve limitations inherently beyond human cognition, such as calculating absolute GPS positions from satellite signals (SRI Int'l v. Cisco Systems, 930 F.3d 1295, 1304 (Fed. Cir. 2019)) or analyzing network packets for suspicious activity, not acts of triage, comparison, and ranking that a medical referral agent performs daily. Moreover, the Applicant does not address the independent rejection basis under "certain methods of organizing human activity" (MPEP § 2106.04(a)(2)(II)), which the subject matter rejection below establishes through the claims' structured patient-routing workflow that manages personal behavior and interactions between the patient and healthcare options (Spec., [0002]). Applicant argues, additional analysis of the claimed elements further confirms that the invention as claimed cannot practically be performed in the human mind and thus the claimed elements do not recite mental processes. Examiner respectfully disagrees. Each limitation the Applicant recites, AI chatbot triage, severity-based facility filtering, wait-time analysis, route determination, and four-tier match labeling, claims a functional result (e.g., "best match… optimal… based on compatibility") without specifying the technical means that produce it, and the specification confirms these are straightforward evaluative judgments "merely selecting information, by content or source, for collection, analysis, and display does nothing significant to differentiate a process from ordinary mental processes" enumerating many steps and data types does not transform individually performable judgments into something beyond human cognition. The Applicant conflates complexity (many steps) with impracticability (human mind not equipped), and the MPEP draws no such equivalence. Applicant argues that Claims 1 and 13 are not directed to abstract ideas. Examiner respectfully disagrees. The updated rejection explains that the focus of the claims is coordinating and recommending care options based on collected information, which fits within abstract-idea groupings, including mental processes and organizing human activity by managing interactions between people. The applicant argues that because a human is too slow to provide healthcare matching results before the data changes or the patient's condition worsens, the process is technically "impossible" for a human and thus cannot be a mental process. The Examiner is not agreed and sustains the rejection because the applicant’s argument relies on the speed of execution rather than a technical improvement to computer functionality. Under MPEP § 2106.05(f), merely adding a generic computer... to perform generic computer functions (like processing data faster than a human).. claiming the improved speed or efficiency inherent with applying the abstract idea on a computer does not automatically overcome an eligibility rejection." The claims recite a managed workflow of triage and facility ranking which, as noted in the subject matter eligibility rejection below, is substantively replicable by a human referral agent using ordinary judgment, and the "timeliness" requirement described in the remarks is not a recited technical limitation that changes the abstract nature of the "evaluative judgments" (MPEP § 2106.04(a)(2)(III)), since courts do not treat the analysis differently merely because it is performed using a computer to be “timeliness” for example, that just represent an improvement to the abstract idea itself not to the technology or computer, as is recite functional without provided the technology improvement mechanism. Consequently, the 35 U.S.C. § 101 rejection is sustained as the claims fail to integrate the abstract idea into a practical application or provide an inventive concept beyond "apply it" computer automation. Applicant argues Claim 21 has been added to further establish that a human mind cannot practically achieve the invention… during a severe emergency… claim 21 is not directed to an abstract idea. Examiner respectfully disagrees. Narrowing an abstract idea to a specific context, such as a "severe emergency," constitutes a "field of use" limitation that does not render the claim eligible (MPEP § 2106.04(a)(2)). The underlying rule ("If Severe, then ER") is a functional application of a mental rule used to organize healthcare options, which remains abstract regardless of the urgency of the situation. 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, 3–5, 10, 13, 15–17, 19, and 21 are rejected under 35 U.S.C. § 101 on the grounds that the claimed invention is directed to an abstract idea and does not include additional elements that amount to significantly more than the abstract idea itself. Step 1 Step 1 assesses whether the claims fall within one of the four statutory categories of patentable subject matter. The claims at issue fall within the statutory category of process. Having confirmed that Claims 1, 3–5, 10, 13, 15–17, 19, and 21 are directed to statutory subject matter as processes, the analysis proceeds to Step 2A to determine whether these claims are directed to a judicial exception under the Alice/Mayo framework. Step 2A: Prong One Analysis Prong One is the initial inquiry of the 2019 Revised Patent Subject Matter Eligibility Guidance (MPEP 2106.04), which requires the Examiner to determine if a claim recites a judicial exception. A claim "recites" a judicial exception when the judicial exception is "set forth" or "described" in the claim. The specification frames the invention as helping a patient choose an appropriate medical care center by (i) finding nearby centers, (ii) determining whether they fit the patient’s needs, and (iii) providing estimated wait time and drive time so the patient can select a center that “best accommodates” needs and schedule. See, e.g., [0001]–[0006] and the workflow in [0030]–[0042] (collect patient info → request → server recommends centers → wait-time estimation → combined drive + wait → match labeling such as low/best/high/medium). Claims 1, 3, 4, 5, 10, 13, 15, 16, 17, 19, and 21 describe a workflow that collects patient information, analyzes estimated and predicted wait times, calculates a combined drive-and-wait time, and ranks medical facilities by compatibility and prior usage. The claims establish a hierarchy of match levels, such as low, medium, high, or best, based on patient needs and timing metrics. Dependent claims mainly specify the source of patient data, while additional limitations refine but do not fundamentally alter the decision-making process. The invention automates evaluation and triage tasks that were historically performed by humans, using mathematical calculations to organize healthcare options. Claim 21 narrows the workflow to "severe" ratings and "hospital emergency rooms," yet this remains a functional application of a mental rule ("If Severe, then ER") used to organize healthcare options ([0036]). Under MPEP 2106.04(a)(2), the narrowing of an abstract idea to a specific context (severe emergencies) or a limited set of choices (hospital ERs) does not change the fundamental nature of the underlying concept. Accordingly, the claims recite mental processes and methods of organizing human activity. Implementing these steps on a computer does not alter their abstract nature under patent law. Recitation of representative Independent Claim 1. Claim 1. A computer-implemented method for locating a medical care center for a patient, the computer-implemented method comprising: providing a patient software application for execution on a mobile electronic device operated by the patient, the patient software application being configured to; generate an alert for regular medical checkups and preventative care, obtain name, age, and sex of the patient during first use by the patient of the patient software application, obtain insurance information from a patient insurance card via image recognition, obtain known prior medical issues and family health conditions, obtain patient information from a wearable electronic device, obtain patient location information, receive a request for locations of medical care centers and interpret the request via natural language processing, receive a description of current medical needs of the patient and a severity rating of the current medical needs via a prompt, and transmit data representative of the patient location information and the request for locations of medical care centers; obtaining, via a remote server, at least one of insurance records and doctor records of the patient; obtaining, via the remote server, information about prior uses of the patient software application; receiving at the remote server the data representative of the patient location information and the request for locations of medical care centers; conducting, via an artificial intelligence powered chatbot, preliminary triage based on symptoms provided in the description of current medical needs; determining, via the remote server, locations of a plurality of medical care centers within a predetermined distance of the patient location wherein the plurality of medical care centers are only hospital emergency rooms if the severity rating of the current medical needs is severe, and wherein the plurality of medical care centers includes previously-visited medical care centers if the severity rating is non- emergency and the current medical needs is routine; analyzing, via the remote server, data representative of an estimated wait time for each of the medical care centers within the predetermined distance of the patient location, determining, via the remote server, a combined drive and wait time for each of the medical care centers based on the patient location, the locations of the medical care centers, and the estimated wait time for the medical care centers, wherein the estimated wait time is determined according to: data obtained directly from the medical care centers, if data direct from the medical care centers is not available, artificial intelligence analysis of historical wait times at the medical care centers and a current number of patients currently checked in to the medical care centers; determining, via the remote server, fastest routes to the plurality of medical care centers via real-time traffic and route optimization: determining, via the remote server, a low match medical care center from the plurality of medical care centers, wherein the low match medical care center is incompatible with the current medical needs; determining, via the remote server, a best match medical care center from the plurality of medical care centers, wherein the best match medical care center is an optimal medical care center based on compatibility with the current medical needs and previous usage by the patient of the best match medical care center; determining, via the remote server, a high match medical care center from the plurality of medical care centers, wherein the high match medical care center is an optimal medical care center based on compatibility with the current medical needs and the combined drive and wait time for the high match medical care center but is not an optimal medical care center based on previous usage by the patient of the best match medical care center; determining, via the remote server, a medium match medical care center from the plurality of medical care centers, wherein the medium match medical care center is compatible with the current medical needs but has a greater combined drive and wait time than the combined drive and wait time of the best match medical care center and the combined drive and wait time of the high match medical care center; transmitting, from the remote server to the mobile electronic device operated by the patient, information representative of the combined drive and wait time for at least one of the plurality of medical care centers; transmitting, from the remote server to the mobile electronic device operated by the patient, indications of the low match medical care center, the best match medical care center, the high match medical care center, and the medium match medical care center. Mental Process (MPEP § 2106.04(a)(2)(III)) A mental process includes observations, evaluations, judgments, and opinions, i.e., steps that, as claimed at the level of results, amount to assessing information and deciding among options. The independent claims 1, 13, and 21 recite cognitive decisioning steps such as “conducting… preliminary triage,” “analyzing… an estimated wait time,” “determining… a combined drive and wait time,” and “determining… [match] medical care center” (e.g., “low match… incompatible,” “best match… optimal… based on compatibility,” and comparative placement of “high/medium” match). Read under MPEP § 2111, these limitations claim the results of judgment, triage, ranking, and labeling, without reciting the technical means that produce those judgments. Certain Methods of Organizing Human Activity (MPEP § 2106.04(a)(2)(II)) Sub-category selected: Managing personal behavior or relationships or interactions between people.This sub-category applies when a claim recites a managed workflow that guides or controls individual behavior or decision-making in real-world interactions, such as determining where to seek medical care and how to proceed. The independent claims 1, 13, and 21 recite interactive/organizational steps such as “receive a request for locations of medical care centers,” “receive a description of current medical needs… [and] a severity rating,” “determining… locations of a plurality of medical care centers… only hospital emergency rooms if… severe,” and “transmitting… information representative of the combined drive and wait time… [and] indications of… [match] medical care center.” Under BRI (MPEP § 2111), these limitations collectively define a structured patient-routing workflow: collect a patient’s request/needs, select candidate providers based on severity/proximity, and deliver categorized options to drive the patient’s next action (where to go). The “match level” outputs (low/best/high/medium) operate as decision labels that organize how the patient is expected to choose among providers, i.e., a managed interaction between the patient and healthcare options. The specification supports this organizational framing by stating the system provides wait times/directions “so the patient can select and easily navigate to a medical care center that best accommodates the patient’s needs and schedule” (Spec., para. [0002]). This passage is directly relevant because it describes the claimed workflow in terms of guiding patient selection and navigation—the claim output is not merely data, but structured guidance that manages a patient’s care-seeking behavior and interaction with available care centers. When read as a whole under the broadest reasonable interpretation (MPEP § 2111), the independent workflow recited in Claims 1, 13, and 21 is substantively replicable by humans. The process of patient intake, triage, and facility ranking can be performed using ordinary recordkeeping and judgment. While computer implementation may increase speed, this does not constitute a different type of step. MPEP § 2106 clarifies that courts do not consider a mental-process concept to be non-abstract solely because it is performed on a computer rather than by humans, even when physical aids are used. The following step-by-step analogy mirrors the functional limitations of independent claims 1, 13, and 21 to demonstrate that the process is a series of evaluative judgments and organizational acts practically performable by a human. A referral agent interviews a patient to record their demographics and medical history while cross-referencing a physical ledger of insurance records and prior visit logs. The agent assesses the described symptoms to triage the patient, narrowing down provider options to emergency rooms for severe cases or familiar clinics for routine care. By calling facilities for current wait times and consulting a street map for travel duration, the agent manually calculates the total time required for each location. The agent then ranks these facilities based on suitability, labeling a center as the "best match" for previous usage, "low match" for incompatibility, or "high/medium match" depending on a comparison of total drive-and-wait times or patient experience. Finally, the agent presents the patient with these ranked options and estimated times to help them choose a healthcare facility. Dependent Claims Analysis The dependent claims 3-5, 10, 15-17, and 19 are also directed to an abstract idea as they merely refine the types of data gathered or the specific parameters used in the evaluative logic. Claims 3-5 and 15-17: These claims recite under BRI that patient information is “received from a patient profile,” “entered by the patient,” or “derived at least partially from previous requests” (Spec., para. [0030]), which is a Certain Method of Organizing Human Activity (Managing Personal Behavior or Interactions). These limitations describe the administrative source of the data used to manage the patient’s movement within the healthcare system, failing to shift the character of the claim away from the organizational workflow of selecting a provider. Claims 10 and 19: These claims recite under BRI that wait times are “determined... based partly on the insurance information” or via “historical wait times... and current patient check-ins” (Spec., para. [0034]), which is a Mental Process. These limitations specify the analytical inputs—such as historical observation and administrative data—for the evaluative judgment of predicting capacity, which are acts of forecasting and evaluation that can be practically performed in the human mind. Because the independent and dependent claims, as a whole, recite judicial exceptions, the analysis must proceed to Step 2A, Prong Two, to determine whether the additional elements integrate the abstract ideas into a practical application. Step 2A, Prong Two: Integration into a Practical Application Prong Two asks whether the additional elements beyond the judicial exception, when evaluated “as a whole,” integrate the exception into a practical application (i.e., impose a meaningful limit so the claim is more than drafting around the exception).MPEP recognizes integration where the claim reflects, for example, an improvement to computer/technology or another meaningful application beyond merely placing the exception in a tech environment; and it identifies non-integration where the claim is effectively “apply it” on a computer, adds data gathering/output, or merely ties the idea to a field of use. Additional elements For independent Claims 1, 13, and 21, the additional elements evaluated in Step 2B are the same elements identified in Step 2A, Prong Two, including: A “patient software application” executing on a “mobile electronic device” with user prompts and intake features (e.g., obtain info; receive request; transmit data). A “remote server” and network exchange (e.g., “transmitting… receiving…”). “image recognition,” “natural language processing,” and an “artificial intelligence powered chatbot” (recited by result, e.g., interpret/triage). “real-time traffic and route optimization” to determine “fastest routes.” “Patient software application” on a “mobile electronic device” (UI intake + prompts) Because these elements frame the interaction and collect inputs that feed the abstract evaluations (triage/ranking/compatibility labeling), rather than reciting a technical mechanism that changes how the computer operates, they are not overcoming step 2A prong two. This is the kind of presolution data gathering and workflow scaffolding that, by itself, does not impose a meaningful limit on the abstract decisioning. “Remote server” + network exchange (“transmitting… receiving…”) Because the server/network is used as the execution venue for the same abstract steps, i.e., it is a computer implementation that amounts to “implement… on a computer” rather than integrating the exception into a technological improvement, they are not overcoming step 2A prong two. “Artificial intelligence powered chatbot” triage + “natural language processing” interpretation + “image recognition” extraction The above additional elements do not satisfy prong two because they are described only in terms of functional results, such as triage, interpretation, or extraction, without reciting any specific technical mechanism that improves computer functionality or another technology. The MPEP explains that “apply it” style claims, which merely state an outcome without explaining how it is achieved, do not integrate an abstract idea into a practical application. When an “improvement” is asserted, the MPEP requires a technical explanation and that the claims themselves reflect that technical improvement, not just a general promise of better performance. Although the claims reference high-level timing features such as “estimated wait time” and “real-time traffic,” the underlying claim mechanics remain unchanged. The process consists of gathering inputs, evaluating or comparing data, and then labeling or routing the data. This reflects the classic “apply it” pattern, in which human decision logic is implemented on a computer for increased speed, rather than representing a genuine technological advance. “real-time traffic and route optimization” / “fastest routes” The above additional elements do not overcome prong two because this limitation serves as another input/constraint on the ranking/selection (drive time), rather than a claimed improvement to routing technology itself. It supplies data used by the abstract evaluation (combined drive + wait), and does not recite a specific routing technique that changes how the computer/traffic system operates. MPEP treats this kind of add-on activity as potentially extra-solution relative to the judicial exception when it serves the abstract process rather than imposing a meaningful technical limit. Evaluated “as an ordered combination,” the additional elements collectively host the abstract workflow (triage + compatibility ranking + time-based comparison + recommendation labels) on generic client/server components in a healthcare setting.MPEP explicitly states that, generally, linking an exception to a technological environment/field of use does not integrate it into a practical application.Accordingly, independent claims 1, 13, and 21 do not integrate the recited judicial exception into a practical application under Step 2A, Prong Two → proceed to Step 2B. The pending dependent claims narrow inputs, data sources, or output conditions used by the same abstract decision workflow; they do not add a technical mechanism that meaningfully limits the judicial exception. Claims 3, 4, 5, 15, 16, and 17 focus on the source and method of obtaining patient information. These details describe data gathering, which is an insignificant extra-solution activity that does not meaningfully limit the abstract idea. MPEP § 2106.05(g) explains that insignificant extra-solution activity, such as data gathering, does not amount to an inventive concept. Claim 19 details how estimated wait times are obtained or determined. While adding specificity to the data analysis, these limitations still represent generic data collection and processing steps, which are ancillary to the abstract idea and do not integrate it into a practical application. MPEP § 2106.05(g) highlights that necessary data gathering for an abstract idea is insignificant extra-solution activity. Because neither the independent-claim additional elements nor the dependent-claim refinements imposes a meaningful technological limit that integrates the exception into a practical application, the analysis moves to Step 2B (inventive concept). Step 2B: Inventive Concept Analysis Step 2B determines whether the additional elements, considered individually and as an ordered combination, transform the nature of the claim into a patent-eligible application by reciting an "inventive concept" that is significantly more than the judicial exception. This inquiry seeks to identify whether the claim does more than simply state an abstract idea and add the words "apply it with a computer." The claims fail to provide an inventive concept because the additional elements, both alone and in combination, consist of generic computer implementation and functional results that are ancillary to the underlying triage and categorization logic. Additional elements For independent Claims 1, 13, and 21, the additional elements evaluated in Step 2B are the same elements identified in Step 2A, Prong Two, including: A “patient software application” executing on a “mobile electronic device” A “remote server” “image recognition,” “natural language processing,” and an “artificial intelligence powered chatbot” “real-time traffic and route optimization” Mobile/Wearable Device and Remote Server The recitation of these hardware components fails to provide an inventive concept because they are used in a conventional manner to execute the abstract logic. According to MPEP 2106.05(f), “merely adding a generic computer... to perform generic computer functions does not automatically overcome an eligibility rejection.” The specification characterizes these as standard equipment: “The personal computing devices... are preferably mobile phones such as those provided by Apple but may also be smart watches... [including] a processor or processing elements 30, memory or memory elements 32, a transceiver... and a communications network” (Spec., para. [0022], [0024]). These elements perform only the ministerial tasks of receiving and transmitting data, providing nothing more than a generic technological environment for the abstract triage. “AI powered chatbot,” “NLP,” “image recognition” (result-oriented tool language) These limitations do not supply significantly more because they describe functional results rather than a technical mechanism. MPEP 2106.05(a) identifies a lack of inventive concept when the claim “fails to recite details of how a solution... is accomplished but instead merely recites the solution itself or a favorable result.” The specification confirms the "apply-it" nature of these tools: “The patient software application may employ or access natural language processing (NLP) so that requests and queries can be made... [and] may also employ image recognition for scanning and managing information from a patient’s insurance card” (Spec., para. [0031], [0043]). These elements automate data entry and interpretation steps without reciting any unconventional technical improvements to the software's architecture. “real-time traffic and route optimization” (field-of-use / extra-solution input) The “real-time traffic”/“route optimization” limitation is recited as a contextual tool/input to carry out the claimed process in a healthcare-routing environment. MPEP explains that generally linking a judicial exception to a particular field of use or technological environment does not provide significantly more. And to the extent it functions as obtaining and using travel-time information, it tracks the kind of data-gathering activity treated as extra-solution activity rather than an inventive concept. The specification notes the system accesses a “source of real-time traffic and route optimization to determine and suggest the fastest routes” (Spec., para. [0033]). This is a post-solution output used to refine the abstract decision-making process; w hitch does not result in a technical transformation of the computer’s functionality. Viewed together, the additional elements amount to: (i) collect inputs via an app, (ii) perform the process on a server, and (iii) output results, implemented in a healthcare setting. MPEP lists these patterns as not enough for “significantly more,” including “apply it” computer implementation, extra-solution data gathering/output, and field-of-use linkage. Accordingly, Claims 1, 13, and 21 do not recite an inventive concept under Step 2B because the additional elements do not add significantly more than the judicial exception identified in Step 2A. Dependent Claims (3–5, 10, 15–17, 19) Claims 3–5 and 15–17 (data-source narrowing) These claims further specify the source of patient information (e.g., profile/entries/prior requests/records). Under Step 2B, this is data gathering / selecting data sources, the type of “mere data gathering” or ancillary input selection treated as an insignificant extra-solution activity rather than an inventive concept. Claim 10 and Claim 19 These claims refine which data is used to generate the evaluated results (e.g., insurance-based factors; historical wait times/current check-ins). They do not add a new technical mechanism beyond the already-identified additional elements (app/server/network/tool labels). As such, they do not provide a separate inventive concept in Step 2B; they narrow the same framework using additional input constraints and data selection. In combination, the dependent-claim limitations add input sourcing and input selection layered onto the same additional elements already analyzed (app/server/network/AI-label/traffic context). MPEP treats these additions as the kinds of “apply it,” extra-solution, and field-of-use limitations that do not supply significantly more. Therefore, Claims 1, 3–5, 10, 13, 15–17, 19, and 21 remain rejected under 35 U.S.C. § 101 because the claims recite a judicial exception and lack an inventive concept in their additional elements. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA DAMIAN RUIZ whose telephone number is (571)272-0409. The examiner can normally be reached 0800-1800. 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, Shahid Merchant can be reached at (571) 270-1360. 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. /JOSHUA DAMIAN RUIZ/Examiner, Art Unit 3684 /Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Read full office action

Prosecution Timeline

May 02, 2024
Application Filed
Jul 10, 2025
Non-Final Rejection — §101
Sep 22, 2025
Response Filed
Nov 13, 2025
Final Rejection — §101
Dec 29, 2025
Request for Continued Examination
Feb 04, 2026
Response after Non-Final Action
Feb 20, 2026
Non-Final Rejection — §101 (current)

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
0%
Grant Probability
0%
With Interview (+0.0%)
3y 0m
Median Time to Grant
High
PTA Risk
Based on 7 resolved cases by this examiner. Grant probability derived from career allow 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