DETAILED CORRESPONDENCE
This is a non-final office action on merits in response to the arguments and/or amendments filed on 12/19/2025 and the request for continued examination filed on 12/19/2025.
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 claims
Amendments to claims 1, 6, 10, 13, 17, and 19 are acknowledged and have been carefully considered. Claims 1-20 are pending and considered below.
Continued Examination Under 37 CFR 1.114
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/19/2025 has been entered.
Claim Objections
The objection to claim 19 is withdrawn. Applicant has amended claim 19 to correct the typographical error by replacing “The system of claim 10” with “The method of claim 10” with resolves the objection.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 1-9, and 17-18 are drawn to a system and claims 10-16, and 19-20 are drawn to a method. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claim 1 recites as a whole a method of organizing human activity (i.e., managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions)) because the claim recites a method that allows users to process a referral though a plurality of stages with defined advancement criteria, including screening, assessment, authorization, and acceptance or rejection, and enforcing rules governing progression between those stages. This is a method of managing a referral intake and admission workflow, including evaluating information, applying criteria, and determining whether a referral is accepted or rejected. The mere nominal recitation of a generic at least one processor does not take the claim out of the methods of certain methods of human activity. Thus, the claim recites an abstract idea.
Claim 10 recites as a whole a method of organizing human activity (i.e., managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions)) because the claim recites a method that allows users to process a referral through a plurality of stages with defined advancement criteria, including associating the referral with a record, screening, processing, and accepting or rejecting the referral, while enforcing rules governing progression between stages. This is a method of managing referral intake and admission workflow, including evaluating information and applying criteria to determine outcomes. The mere nominal recitation of a generic processor does not take the claim out of the methods of certain methods of organizing human activity. Thus, the claim recites an abstract idea.
Under Step 2A Prong Two
The claimed limitations, as per claim 1, include:
at least one processor; and memory storing instructions that, when executed by the at least one processor, cause the system to:
guide one or more users to process a referral through two or more of a plurality of stages,
wherein at least two of the stages includes one or more advancement criteria relating to documentation unique to the stage and wherein the stages include:
a new stage wherein, at the new stage, the referral is associated with a patient record;
a screening stage wherein, at the screening stage, the referral is asked a plurality of screening questions;
an assessment stage wherein, at the assessment stage, a diagnostic assessment of the referral is made;
a tour stage wherein, at the tour stage the referral is given a tour;
an authorization stage wherein, at the authorization stage, the referral is accepted or rejected; and a queue in which a referral is placed if accepted;
display, on a graphical user interface, an active referrals graph wherein the active referrals graph provides a visual representation of the number of referrals in each stage;
verify identifying credentials of a least one user of the one or more users to progress a referral from one stage to a next stage;
assess whether the advancement criteria for each stage having advancement criteria are satisfied; and
prevent a referral from advancing from the authorization stage to the queue unless all advancement criteria of all stages are satisfied, even with verified identifying credentials.
The claimed limitations, as per method claim 10, include the steps of:
receiving patient health information relating to a referral;
inputting the patient health information into a referral management system, the referral management system having a new stage, a screening stage, and an intake stage, wherein each stage includes one or more advancement criteria relating to documentation of patient health information unique to the stage;
wherein the referral management system includes at least one processor; a graphical user interface, and a memory storing instructions that, when executed by the at least one processor, cause the system to
(i) verify identifying credentials of a user to progress a referral from one stage to a next stage,
(ii) assess whether the advancement criteria for each stage having advancement criteria are satisfied; and
prevent the referral from advancing from one stage to a next stage until at least all advancement criteria of the one stage are satisfied met;
associating, using the referral management system, the referral with a record during the new stage;
screening, using the referral management system, the referral during the screening stage;
processing, using the referral management system, the referral through the intake stage;
accepting or rejecting, using the referral management system, the referral; and
displaying, using the graphical user interface, a visual representation of the stage the referral is in.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of managing a referral intake and admission workflow through staged processing and rule-based progression in a computer environment. The claimed computer components (i.e., at least one processor; and memory storing instructions that, when executed by the at least one processor, cause the system to) are recited at a high level of generality and are merely invoked as tools to perform an existing process of organizing and managing referral intake activities, including screening, evaluating and accepting or rejecting referrals based on defined criteria. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 10 is not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of managing referral intake and admission workflow through staged processing and rule based progression in a computer environment. The claimed computer components (i.e., wherein the referral management system includes at least one processor; a graphical user interface, and a memory storing instructions that, when executed by the at least one processor, cause the system to; and using the referral management system) are recited at a high level of generality and are merely invoked as tools to perform an existing process of organizing and managing referral intake activities, including collecting information, evaluating criteria, and determining whether to accept or reject a referral. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim recites the additional element of displaying, on a graphical user interface, an active referrals graph wherein the active referrals graph provides a visual representation of the number of referrals in each stage. This limitation is recited at a high level of generality (i.e., as a general means of presenting information), and amounts to merely displaying results, which is a form of insignificant extra-solution activity. Accordingly, even in combination, this additional element does not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
The judicial exception expressed in claim 10 is not integrated into a practical application. The claim recites the additional elements of receiving patient health information relating to a referral; and displaying, using the graphical user interface, a visual representation of the stage the referral is in. These limitations are recited at a high level of generality (i.e., as a general means of collecting information and presenting information), and amounts to merely data gathering and displaying results, which are forms of insignificant extra-solution activities. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claims 1 and 10 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concept of managing a referral intake and admission workflow through staged processing and rule-based progression in a computer environment. Thus, even when viewed as a whole, nothing in the claims add significantly more (i.e., an inventive concept) to the abstract idea.
For claim 1, under step 2B, the additional element of display, on a graphical user interface, an active referrals graph wherein the active referrals graph provides a visual representation of the number of referrals in each stage has been evaluated. As noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely analyzing data and displaying a result without a technological improvement does not add significantly more to an abstract idea. The use of the system is no more outputting a result after evaluating referral data through the intake workflow and does not integrate the abstract idea into a practical application. Therefore, the claim does not recite an inventive concept and is not patent eligible.
For claim 10, under step 2B, the additional elements of receiving patient health information relating to a referral; and displaying, using the graphical user interface, a visual representation of the stage the referral is in have been evaluated. The method comprising at least one processor performs a general function of receiving patient data for input into the referral management workflow, which represents a well-understood, routine, and conventional activity in the field of data processing and information management. The specification discloses that the processor is used in its ordinary capacity as a data input device and does not describe any improvement to the computer itself or to the functioning of the overall computer system (see [0109]). Also noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely collecting information for analysis and displaying the result without a technological improvement does not add significantly more to an abstract idea. The use of the method is no more than collecting information before evaluating and determining whether to accept or reject a referral and outputting a result after evaluating referral data through the intake workflow, and does not integrate the abstract idea into a practical application. Therefore, the claim does not recite an inventive concept and is not patent eligible.
Claims 2-3, 6, 9, 11, 13-16 recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above. Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Claims 4-5, 7, 8, 12, 17-20 recite the additional element of the system (claims 4, 5, 7, 8, and 18), artificial intelligence (claim 8), and the referral management system (claim 12 and 19), to display, using the graphical user interface, missing data relating to the advancement criteria when a user attempts to progress to the next stage when any advancement criteria are not yet satisfied (claim 17), synchronizing data between the referral management system and the EHR system (claim 20). However, these additional elements amount to implementing an abstract idea on a generic computing device, mere linking to a particular environment, or mere data gathering (i.e., an insignificant extra-solution activity). As such, these additional elements, when considered individually or in combination with the prior devices, do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claim is rejected under 35 U.S.C. 101 for lacking eligible subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-9, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Easterhaus et al. (U.S. Patent Publication 2013/0282397 A1), referred to hereinafter as Easterhaus, in view of Malecha et al. (U.S. Patent Publication 2013/0060235 A1), referred to hereinafter as Malecha, Lee et al. (U.S. Patent 11037676 B2), referred to hereinafter as Lee, and Webster et al. (U.S. Patent Publication 2020/0133711 A1), referred to hereinafter as Webster.
Regarding claim 1, Easterhaus teaches a system for referral management, the system comprising (Easterhaus [0007] “In brief, and at a high level, the present invention is directed to methods, systems, and computer-readable storage media for creating, among other things, a unified patient referral worklist that helps a provider to manage incoming and outgoing referrals”):
at least one processor; and memory storing instructions that, when executed by the at least one processor, cause the system to (Easterhaus [0028] “With continued reference to FIG. 1, the computing environment 100 comprises a computing device in the form of a control server 102. Exemplary components of the control server 102 comprise a processing unit, internal system memory, and a suitable system bus for coupling various system components, including data store 104, with the control server 102.”):
to process a referral (Easterhaus [0007] “In brief, and at a high level, the present invention is directed to methods, systems, and computer-readable storage media for creating, among other things, a unified patient referral worklist that helps a provider to manage incoming and outgoing referrals”);
the referral is associated with a patient record (Easterhaus, [0094] “FIG. 9 depicts a flow diagram illustrating an exemplary method 900 of generating a unified patient referral worklist for a provider. At a step 910, a first referral order associated with a first patient is received from a first medical organization. The first referral order may be stored in an electronic medical record system associated with the organization and may have been created by a provider associated with the first medical organization.”);
a screening wherein, at the screening, the referral is asked a plurality of screening questions (Easterhaus, [0085] “The GUI 1300 further includes an action area 1322. The patient can select the checkmark in the action area 1322 for example and access one or more input fields or selectable actions. The selectable actions may include actions related to the referral order(s) such as completed or re-scheduled. Another selectable action is a pre-visit questionnaire. The patient can utilize the pre-visit questionnaire to input needed information such as demographic information, payment information, a patient-supplied medical history and review of symptoms, and a patient-supplied history of the current problem. The pre-visit questionnaire is provided to the referring provider and/or the referral provider via, for example, email, text, mail, fax, presentation on a user interface, and the like.”);
an assessment wherein, at the assessment, a diagnostic assessment of the referral is made (Easterhaus [0051] “The referral orders may also include attachments such as test results, procedure results, and other types of medical documentation.” and Easterhaus [0060] “The medical documentation area 420 also includes an attachment area 421 where the referring provider can attach pertinent clinical documentation (lab results, procedure results, patient history, a pre-visit questionnaire completed by the patient, radiographic images, EKGs, etc.) to further assist the referral provider.”);
an authorization wherein, at the authorization, the referral is accepted or rejected; and a queue in which a referral is placed if accepted (Easterhaus [0056] “The GUI 300 also includes a filtering area 316 that enables a provider or employees in the provider's office to filter the incoming and outgoing referrals. As seen, filtering options may include referrals for review, requested referrals, rejected referrals, outbound referrals, referrals in progress, and/or referrals for assessment. Additionally, the provider or employees in the provider's office may select multiple filtering options to create a custom worklist which can be subsequently saved. For example, a custom worklist may be generated for a provider especially if the provider is a member of a multi-provider group (i.e., “Dr. Bob's Family Practice”). Any and all such variations are contemplated as being within the scope of the invention.”); and
display, on a graphical user interface, an active referrals graph wherein the active referrals graph provides a visual representation of the number of referrals in each stage (Easterhaus [0058] “Upon selection of an incoming or outgoing referral such as, for example, referral 321, the provider is navigated to a detail screen comprising detailed information about the referral 321. FIG. 4 illustrates this aspect of the invention. FIG. 4 depicts an exemplary graphical user interface (GUI) 400. The GUI 400 includes a patient identification area 412 that provides information concerning the patient who is the subject of the referral order. The information includes, for example, name, age, sex, weight, height, date of birth, patient number, payment information, primary care provider, date of last visit, and the like. The GUI 400 also includes a selectable active referral tab 414. Selection of the tab 414 displays all incoming and outgoing active referrals associated with the patient; this information is shown in the active referral area 418.”).
Easterhaus fails to explicitly teach guide one or more users through two or more of a plurality of stages;
wherein at least two of the stages includes one or more advancement criteria relating to documentation unique to the stage and wherein the stages include;
a tour stage wherein, at the tour stage the referral is given a tour;
verify identifying credentials of a least one user of the one or more users to progress a referral from one stage to a next stage;
assess whether the advancement criteria for each stage having advancement criteria are satisfied; and
prevent a referral from advancing from the authorization stage to the queue unless all advancement criteria of all stages are satisfied, even with verified identifying credentials.
Malecha teaches guide one or more users through two or more of a plurality of stages (Malecha [0104] “At 214, the management engine 102 may configure and/or execute one or more workflows, for example, by executing the actions defined by the workflow elements. For example, if no more workflow elements are selected (e.g., as determined at 212), the management engine 102 may configure or logically connect workflow steps, determine which internal or external systems (e.g., components in the system 100 a) to use or communicate with to detect triggers and perform actions, etc. For example, if a practitioner indicates that a workflow for a given patient includes ordering a set of labs, taking a supplement on certain days of the week, and following up in two weeks, the management engine 102 may configure a workflow automation that orders the lab test (or transmits an order to a laboratory server 108, automatically provides a display to a practitioner for ordering the lab test, etc.), orders supplements, and/or schedules a follow-up meeting on the practitioner's and patient's calendars, etc.”);
wherein at least two of the stages includes one or more advancement criteria relating to documentation unique to the stage and wherein the stages include (Malecha [0101] “At 210, the management engine 102 may connect one or more workflow elements, triggers, data points, patients, or other elements. For example, as a practitioner provides or indicates a workflow or protocol step or stage, the management engine 102 may logically connect the elements or steps to create an automated workflow.”, Malecha [0104] “At 214, the management engine 102 may configure and/or execute one or more workflows, for example, by executing the actions defined by the workflow elements. For example, if no more workflow elements are selected (e.g., as determined at 212), the management engine 102 may configure or logically connect workflow steps, determine which internal or external systems (e.g., components in the system 100 a) to use or communicate with to detect triggers and perform actions, etc. For example, if a practitioner indicates that a workflow for a given patient includes ordering a set of labs, taking a supplement on certain days of the week, and following up in two weeks, the management engine 102 may configure a workflow automation that orders the lab test (or transmits an order to a laboratory server 108, automatically provides a display to a practitioner for ordering the lab test, etc.), orders supplements, and/or schedules a follow-up meeting on the practitioner's and patient's calendars, etc.” and Malecha [0125] “At 316, the management engine 102 may receive lab result(s), for example, using the exported data, such as the lab order or result after completion of the lab test. For example, a workflow or protocol may include one or multiple steps, one of which may include automation to receive lab results for an ordered lab (e.g., via communication with the lab server 108) and/or provides order fulfillment data, such as lab results, which may be formatted in a PDF document.”):
verify identifying credentials of a least one user of the one or more users to progress a referral from one stage to a next stage (Malecha [0071] “The database 110 may include one or more information sources for storing and providing access to data, such as the data storage device 158. The database 110 may store and provide access to various data, as described in further detail elsewhere herein. For instance, the database 110 may store files for a practitioner or patient, such as resource or informational files that may be shared with a practitioner or patient, individual files, logos or images, lab report files, patient or practitioner attributes, login credentials, etc.” and Malecha [0102] “At 212, the management engine 102 may determine whether there are additional workflow elements, actions, or workflows, for example, which may be connected together sequentially or in parallel. If the additional workflow elements are selected or may be selected, the operations from 206 may be repeated, for example. In some implementations, an output of a first workflow may serve as a trigger or input into a second workflow or stage of the workflow.”); and
assess whether the advancement criteria for each stage having advancement criteria are satisfied (Malecha [0102] “At 212, the management engine 102 may determine whether there are additional workflow elements, actions, or workflows, for example, which may be connected together sequentially or in parallel. If the additional workflow elements are selected or may be selected, the operations from 206 may be repeated, for example. In some implementations, an output of a first workflow may serve as a trigger or input into a second workflow or stage of the workflow.” and Malecha [0103] “As an illustrative example, the management engine 102 may receive a second input selecting a second workflow element that defines a second action. The workflow may be automatically executed based on the second data or trigger. For example, a first action may include transmitting a request for status information (e.g., indicating a status associated with the accessed data) to a client device 104 of a patient. For instance, the second action may include transmitting a recommendation to the patent's client device including a patient survey. The workflow element or stage may also include, for example, receiving survey responses. Additional or fewer actions may be performed.”).
Lee teaches a tour wherein, at the tour the referral is given a tour (Lee, Col. 1, lines 53-58, “In one or more embodiments described herein, systems, computer-implemented methods, apparatus and/or computer program products that facilitate managing and optimizing the experience of patients and visitors in association with visiting a medical facility.”).
Webster teaches prevent a referral from advancing from the authorization stage to the queue unless all advancement criteria of all stages are satisfied, even with verified identifying credentials (Webster [0200] “The rules 650 can define workflow process segment model threshold conditions for determining whether a software development workflow process model execution is advanced to a next workflow process segment model or terminated. For example, a workflow process segment model threshold condition can be a qualitative condition (e.g., “pass,” or “fail”) and/or a quantitative condition, such as greater or less than a predetermined value (e.g., 100%). Accordingly, a workflow process segment model threshold condition may be satisfied if 100% of the events and/or tasks within a particular workflow process segment model execution are passed.”, Webster [0201] “The rules 650 can define workflow process segment model gate conditions for determining whether a software development workflow process model execution is advanced to a next workflow process segment model, terminated, or held. The gate condition can be in addition to, or instead of, other conditions (e.g., workflow process segment model threshold conditions). For example, a gate condition may require an administrator, or other user with sufficient privileges, to approve a workflow process advancement prior to actually advancing an execution of the software development workflow process model. For example, a PROD segment model may require an administrator to approve application deployment prior to deploying the application to a production system.”, and Webster [0202] “A workflow process segment can include one or more quality gate conditions, and/or quality gate conditions can include different condition types. For example, a workflow process segment can include one or more quality gate conditions, and the condition types can include critical conditions, non-critical conditions, and/or the like. Each condition type can be associated with a threshold value and/or value range (collectively, “value”). For example, critical condition types may be associated with a 100% pass rate in order for the software development workflow process model to advance to the next workflow process segment, while a non-critical condition type may be associated with a 90% pass rate in order for the software development workflow process model to advance to the next workflow process segment.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the referral management system of Easterhaus to incorporate Malecha’s workflow processing and Webster’s rule threshold and gate condition mechanisms. Easterhaus teaches managing referrals and associated patient data within a system, but does not enforce structured progression through defined stages. Malecha teaches configuring and executing multi-step workflows in which actions are logically connected and performed based on defined workflow elements and triggers. Webster further teaches applying threshold conditions and gate conditions to determine whether a workflow may advance to a subsequent stage, including preventing advancement or holding progression until defined criteria are satisfied. A person of ordinary skill would have recognized that integrating such workflow control techniques into a referral management system would improve the organization and reliability of referral processing by ensuring that required steps and information are completed before progression.
It would have been further obvious to apply Webster’s gate and threshold condition logic to Easterhaus’ referral workflow as implemented with Malecha’s workflow engine to enforce advancement criteria relating to documentation and process completion. Enforcing such criteria ensures that referrals are not prematurely advanced without necessary information, thereby improving data completeness, reducing errors, and enhancing decision making accuracy. These are well known design considerations in workflow and case management systems, where progression control is routinely used to maintain process integrity. The modification would have amounted to the predictable use of prior art elements according to their established functions, specifically using workflow automation and rule gating to control progression through a multi-stage process.
Additionally, incorporating user credential verification as part of advancing a referral between stages would have been an obvious implementation detail, as verifying user identity and permissions prior to performing system actions is a well-understood, routine, and conventional practice in computer systems. A person of ordinary skill would have been motivated to include such verification to ensure accountability and proper authorization within the referral workflow. Accordingly, the combined teachings of Easterhaus, Malecha, Webster, and Lee represent no more than the predictable combination of known elements to yield expected results, rendering the claimed invention obvious under 35 U.S.C. § 103.
Regarding claim 2, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein the active referrals graph further provides a visual representation of the status of each referral in each stage (Easterhaus [0058] “Upon selection of an incoming or outgoing referral such as, for example, referral 321, the provider is navigated to a detail screen comprising detailed information about the referral 321. FIG. 4 illustrates this aspect of the invention. FIG. 4 depicts an exemplary graphical user interface (GUI) 400. The GUI 400 includes a patient identification area 412 that provides information concerning the patient who is the subject of the referral order. The information includes, for example, name, age, sex, weight, height, date of birth, patient number, payment information, primary care provider, date of last visit, and the like. The GUI 400 also includes a selectable active referral tab 414. Selection of the tab 414 displays all incoming and outgoing active referrals associated with the patient; this information is shown in the active referral area 418.” and Easterhaus [0060] “Selection of one of the active referrals, such as referral 417, in the active referral area 418, initiates a display of details associated with the referral 417. The details are displayed in a referral comments section 419 and/or a medical documentation area 420. The referral comments section 419 presents comments pertaining to the referral; the comments may have been inputted by the referring provider. The referral comments section 419 may also include a priority indicator (urgent versus routine), status of the referral (currently pending, cancelled, completed, created, and/or draft), date and time when the appointment is scheduled, and diagnosis. The medical documentation area 420 may present medical notes or documentation to better assist the referral provider; the medical note may have been inputted by the referring provider.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Easterhaus to include a visual representation of the status of each referral within a graphical overview of referrals across stages. Easterhaus teaches presenting referral information in a graphical user interface, including an active referrals display and detailed views showing the status of each referral (pending, cancelled, completed, created, draft). A person of ordinary skill in the art would have recognized that incorporating such known status indicators into a consolidated graphical representation (an active referrals graph) would improve usability by allowing users to more efficiently monitor referral progress across stages, rather than requiring navigation into individual referral records. This modification represents no more than the predictable use of prior art elements according to their established functions, displaying known referral status information in a summarized visual format to enhance workflow visibility and management, and would have yielded predictable benefits in improving user interface clarity and efficiency.
Regarding claim 3, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein the visual representation is via color coding (Malecha [0150] “The example graphical user interface 1602 illustrated in FIG. 16 may illustrate an expansion or portion of the graphical user interface 1502. In the illustrated example, a tooltip, popup, overlay, or display window 1604 is provided with additional data or a subset of the lab report data related to the underlying display interface element. For example, data extracted and reformatted from the received lab report may be provided in the display window 1604. For instance, a user may interact with (e.g., hover over, select, etc.) a displayed data field in the dashboard (e.g., an H. pylori indicator), which itself may be color coded by the management engine 102 based on analysis of the lab report and may be provided with not only the general indication mapped by the management engine 102 (e.g., “HIGH”), but may also be provided with additional data from a lab report”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement color coding within the visual representation of referral information as taught by Easterhaus using the known technique of color-coded indicators as taught by Malecha. Malecha discloses that graphical user interface elements may be color coded to convey status or condition of displayed data, thereby improving user interpretation and facilitating rapid assessment of information. A person of ordinary skill in the art would have recognized that applying such color coding to referral status or stage information in Easterhaus would have been a predictable variation to enhance visual clarity and usability, allowing users to distinguish between different referral states within the workflow. This modification applies a well-known user interface technique to an existing system to improve information presentation and does not require more than ordinary skill in the art, yielding predictable results in improved workflow monitoring.
Regarding claim 4, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein the instructions further cause the system to associate the referral with a patient record, and wherein associating the referral with a patient record comprises associating the referral with an existing client record (Easterhaus [0070] “Again turning back to FIG. 2, the referral order option component 230 is configured to determine and generate a plurality of referral order options for a patient. For instance, the referral order option component 230 may determine recommended referral options based on a patient's medical record and medical standards of care; the standards of care may be stored in association with, for example, the data store 223. By way of illustrative example, the patient's medical record may indicate that the patient is 55-years-old and has not had a screening colonoscopy. Medical standards of care recommend that a person of average risk should have a screening colonoscopy every ten years starting at the age of 50. The referral order option component 230 may generate a referral order option directed toward this recommendation.” and Easterhaus [0061] “The GUI 400 further includes a historical referral tab 416. Selection of the historical referral tab 416 presents all past referrals associated with the patient. The historical referrals are presented similar to the active referrals in the active referral area 418. Selection of one or more of the historical referrals initiates the presentation of details associated with the historical referral order (i.e., referral comments and medical documentation) in the referral comments section 419 and the medical documentation area 420.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to associate a referral with an existing patient record as part of the referral management system of Easterhaus. Easterhaus teaches generating and managing referrals based on a patient’s medical record and further teaches maintaining and displaying historical referrals associated with that same patient. A person of ordinary skill in the art would have understood that such functionality necessarily requires associating new referral information with an existing patient record in order to maintain continuity of care, avoid duplication, and enable retrieval of prior referral data. Incorporating association with an existing client record represents no more than the use of known data management practices within electronic medical record systems, and would have been a predictable and routine implementation to improve data organization.
Regarding claim 5, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein asking the referral a plurality of screening questions is done via a questionnaire and wherein the questionnaire is customizable by an organization using the system (Easterhaus, [0086] “The GUI 1300 further includes an action area 1322. The patient can select the checkmark in the action area 1322 for example and access one or more input fields or selectable actions. The selectable actions may include actions related to the referral order(s) such as completed or re-scheduled. Another selectable action is a pre-visit questionnaire. The patient can utilize the pre-visit questionnaire to input needed information such as demographic information, payment information, a patient-supplied medical history and review of symptoms, and a patient-supplied history of the current problem. The pre-visit questionnaire is provided to the referring provider and/or the referral provider via, for example, email, text, mail, fax, presentation on a user interface, and the like.” and Easterhaus, [0077] “Additionally, the GUI 500 includes a customized template area 518. The area 518 may include templates customized by a healthcare organization to which the provider is affiliated as well as blank templates. The customized area 518 also includes a search template box 519 by which the provider can search for templates that have been created but are not displayed.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement the questionnaire of Easterhaus as a customizable questionnaire. Easterhaus teaches presenting a pre-visit questionnaire to collect referral-related information from a patient and further teaches that healthcare organizations can create and use customized templates for structuring information within the system. A person of ordinary skill in the art would have recognized that questionnaires are a type of structured data collection template and that allowing such questionnaires to be customized by an organization would improve flexibility and adaptability to different clinical workflows and intake requirements. Modifying the questionnaire to be customizable represents no more than the predictable use of prior art elements according to their established functions and would have yielded the predictable benefit of tailoring intake processes to organizational needs.
Regarding claim 6, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein a first advancement criterion is associated with the screening stage, and a second advancement criterion is associated with the assessment, tour, or authorization stages (Malecha [0101] “At 210, the management engine 102 may connect one or more workflow elements, triggers, data points, patients, or other elements. For example, as a practitioner provides or indicates a workflow or protocol step or stage, the management engine 102 may logically connect the elements or steps to create an automated workflow.”, Malecha [0104] “At 214, the management engine 102 may configure and/or execute one or more workflows, for example, by executing the actions defined by the workflow elements. For example, if no more workflow elements are selected (e.g., as determined at 212), the management engine 102 may configure or logically connect workflow steps, determine which internal or external systems (e.g., components in the system 100 a) to use or communicate with to detect triggers and perform actions, etc. For example, if a practitioner indicates that a workflow for a given patient includes ordering a set of labs, taking a supplement on certain days of the week, and following up in two weeks, the management engine 102 may configure a workflow automation that orders the lab test (or transmits an order to a laboratory server 108, automatically provides a display to a practitioner for ordering the lab test, etc.), orders supplements, and/or schedules a follow-up meeting on the practitioner's and patient's calendars, etc.” and Malecha [0125] “At 316, the management engine 102 may receive lab result(s), for example, using the exported data, such as the lab order or result after completion of the lab test. For example, a workflow or protocol may include one or multiple steps, one of which may include automation to receive lab results for an ordered lab (e.g., via communication with the lab server 108) and/or provides order fulfillment data, such as lab results, which may be formatted in a PDF document.” and
Easterhaus, [0085] “The GUI 1300 further includes an action area 1322. The patient can select the checkmark in the action area 1322 for example and access one or more input fields or selectable actions. The selectable actions may include actions related to the referral order(s) such as completed or re-scheduled. Another selectable action is a pre-visit questionnaire. The patient can utilize the pre-visit questionnaire to input needed information such as demographic information, payment information, a patient-supplied medical history and review of symptoms, and a patient-supplied history of the current problem. The pre-visit questionnaire is provided to the referring provider and/or the referral provider via, for example, email, text, mail, fax, presentation on a user interface, and the like.” and Easterhaus [0056] “The GUI 300 also includes a filtering area 316 that enables a provider or employees in the provider's office to filter the incoming and outgoing referrals. As seen, filtering options may include referrals for review, requested referrals, rejected referrals, outbound referrals, referrals in progress, and/or referrals for assessment. Additionally, the provider or employees in the provider's office may select multiple filtering options to create a custom worklist which can be subsequently saved. For example, a custom worklist may be generated for a provider especially if the provider is a member of a multi-provider group (i.e., “Dr. Bob's Family Practice”). Any and all such variations are contemplated as being within the scope of the invention.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to associate different advancement criteria with different stages of a referral workflow as claimed. Malecha teaches configuring and executing workflows composed of multiple stages or steps, where each stage may include distinct actions, triggers, or data requirements, and where workflow elements are logically connected and executed based on defined conditions or inputs. This indicates that different stages implicitly involve different criteria or requirements for progression. Easterhaus further teaches collecting specific information at different points in the referral process, such as via a pre-visit questionnaire during an initial stage and managing referrals through various statuses such as review, in progress, or assessment. A person of ordinary skill in the art would have recognized that associating different advancement criteria (required documentation or actions) with different stages, such as screening versus later stages like assessment, tour, or authorization, would be a predictable implementation of staged workflow management to ensure appropriate data collection and process control at each phase. This modification represents no more than the application of known workflow design principles, where stage specific requirements are used to govern progression, and would have yielded predictable benefits in improving process accuracy, and completeness.
Regarding claim 7, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein the instructions further cause the system to track an amount of time taken for a referral to progress from one stage to a next stage (Malecha [0104] “At 214, the management engine 102 may configure and/or execute one or more workflows, for example, by executing the actions defined by the workflow elements. For example, if no more workflow elements are selected (e.g., as determined at 212), the management engine 102 may configure or logically connect workflow steps, determine which internal or external systems (e.g., components in the system 100 a) to use or communicate with to detect triggers and perform actions, etc. For example, if a practitioner indicates that a workflow for a given patient includes ordering a set of labs, taking a supplement on certain days of the week, and following up in two weeks, the management engine 102 may configure a workflow automation that orders the lab test (or transmits an order to a laboratory server 108, automatically provides a display to a practitioner for ordering the lab test, etc.), orders supplements, and/or schedules a follow-up meeting on the practitioner's and patient's calendars, etc.” and Webster [0177] Timestamps: time/date information for the stored results. For example, timestamp information can indicate when a software development workflow process model execution started, when a software development workflow process model execution ended, as well as timestamp data for event results, segment model results, and task results.
It would have been obvious to one of ordinary skill in the art at the time of the invention to track an amount of time taken for a referral to progress between stages in the workflow. Webster teaches recording timestamp information associated with workflow executions, including start and end times as well as timestamps for individual events, tasks, and workflow segments. A person of ordinary skill in the art would have recognized that the elapsed time between workflow stages can be readily determined from such timestamp data, and that tracking such timing information is a well-known technique for monitoring workflow performance and efficiency. Malecha further teaches executing multi-stage workflows with defined steps and sequencing, providing a context in which such timing measurements would be applied. Combining these teachings to track the time between stages represents no more than the predictable use of known data tracking and analysis techniques to improve workflow monitoring, yielding predictable benefits such as identifying delays and optimizing process efficiency.
Regarding claim 8, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein the instructions further cause the system to screen the referral using artificial intelligence during the screening stage (Easterhaus, [0085] “The GUI 1300 further includes an action area 1322. The patient can select the checkmark in the action area 1322 for example and access one or more input fields or selectable actions. The selectable actions may include actions related to the referral order(s) such as completed or re-scheduled. Another selectable action is a pre-visit questionnaire. The patient can utilize the pre-visit questionnaire to input needed information such as demographic information, payment information, a patient-supplied medical history and review of symptoms, and a patient-supplied history of the current problem. The pre-visit questionnaire is provided to the referring provider and/or the referral provider via, for example, email, text, mail, fax, presentation on a user interface, and the like.” and Lee, Col. 29, lines 56-60, “FIG. 5 illustrates an additional artificial intelligence component 502 that can be employed by the POEM server 134 to facilitate managing and optimizing the user experience at the medical facility in accordance with various aspects and embodiments described herein.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to employ artificial intelligence to perform screening of referral information within the referral management workflow of Easterhaus. Easterhaus teaches collecting detailed patient and referral information during an intake or screening stage, including demographic data, medical history, and other inputs via a questionnaire. Lee further teaches incorporating an artificial intelligence component within a medical system to facilitate managing and optimizing processes related to patient interactions and experiences. A person of ordinary skill in the art would have recognized that applying known artificial intelligence techniques to analyze and evaluate the collected screening information in Easterhaus would improve efficiency, consistency, and decision-making during the screening stage, for example by automating evaluation of patient data or identifying appropriate next steps. This modification represents no more than the predictable use of prior art elements according to their established functions, applying AI analysis to existing data collection processes, and would have yielded predictable benefits in enhancing screening accuracy and reducing manual workload.
Regarding claim 9, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach further comprising a referrals list associated with the active referrals graph, wherein the referrals list displays detail about each referral (Easterhaus [0058] “Upon selection of an incoming or outgoing referral such as, for example, referral 321, the provider is navigated to a detail screen comprising detailed information about the referral 321. FIG. 4 illustrates this aspect of the invention. FIG. 4 depicts an exemplary graphical user interface (GUI) 400. The GUI 400 includes a patient identification area 412 that provides information concerning the patient who is the subject of the referral order. The information includes, for example, name, age, sex, weight, height, date of birth, patient number, payment information, primary care provider, date of last visit, and the like. The GUI 400 also includes a selectable active referral tab 414. Selection of the tab 414 displays all incoming and outgoing active referrals associated with the patient; this information is shown in the active referral area 418.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to include a referrals list associated with a graphical representation of referrals that displays details about each referral. Easterhaus teaches presenting referral information within a graphical user interface, including an active referral area that lists multiple referrals and enables a user to select a referral to view detailed information such as patient data and referral-related attributes. A person of ordinary skill in the art would have recognized that providing a list of referrals alongside or in association with a graphical overview (an active referrals graph) is a common and predictable user interface design pattern that improves usability by allowing both high-level visualization and detailed inspection of individual items. Modifying Easterhaus to present a referrals list associated with a graphical representation of referrals, where the list displays details for each referral, represents no more than the predictable use of known interface techniques for organizing and presenting information, and would have yielded predictable benefits in improving user visibility and workflow management.
Regarding claim 17, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein the instructions further cause the system to display, using the graphical user interface, missing data relating to the advancement criteria when a user attempts to progress to the next stage when any advancement criteria are not yet satisfied (Easterhaus [0058] “Upon selection of an incoming or outgoing referral such as, for example, referral 321, the provider is navigated to a detail screen comprising detailed information about the referral 321. FIG. 4 illustrates this aspect of the invention. FIG. 4 depicts an exemplary graphical user interface (GUI) 400.” and Easterhaus [0089] “The alert/notification component 238 of the referral service 210 is configured to generate alerts and/or reminders and communicate the alerts and/or reminders to providers, patients, and/or members of the patient's family. Alerts may be generated and communicated to a provider. For instance, a referral provider may be sent an alert if a high-priority referral order has been entered. Alerts may also be generated when there is a change in referral status such as "scheduled" to "patient seen," or "scheduled" to "cancelled." Additionally, alerts may be generated when additional documentation is received for a pending referral order. The alert(s) may be in the form of an email, a text message, a phone call, or a visual indicator (e.g, an exclamation point) on a user interface such as the GUI 300 of FIG. 3.”),
Webster [0200] “The rules 650 can define workflow process segment model threshold conditions for determining whether a software development workflow process model execution is advanced to a next workflow process segment model or terminated. For example, a workflow process segment model threshold condition can be a qualitative condition (e.g., “pass,” or “fail”) and/or a quantitative condition, such as greater or less than a predetermined value (e.g., 100%). Accordingly, a workflow process segment model threshold condition may be satisfied if 100% of the events and/or tasks within a particular workflow process segment model execution are passed.”, Webster [0201] “The rules 650 can define workflow process segment model gate conditions for determining whether a software development workflow process model execution is advanced to a next workflow process segment model, terminated, or held. The gate condition can be in addition to, or instead of, other conditions (e.g., workflow process segment model threshold conditions). For example, a gate condition may require an administrator, or other user with sufficient privileges, to approve a workflow process advancement prior to actually advancing an execution of the software development workflow process model. For example, a PROD segment model may require an administrator to approve application deployment prior to deploying the application to a production system.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the referral management system of Easterhaus to display missing data relating to advancement criteria when a user attempts to progress to a next stage and required criteria are not satisfied, in view of Webster. Webster teaches enforcing workflow progression using threshold and gate conditions that prevent advancement when required conditions are unmet. Easterhaus teaches providing graphical user interfaces and generating alerts or visual indicators to notify users of relevant referral status information, including when additional documentation is needed or when referral status changes. A person of ordinary skill in the art would have been motivated to combine these teachings so that, when advancement is blocked due to unmet criteria as in Webster, the system would provide user feedback via the GUI as taught by Easterhaus, including identifying what information or documentation is missing. This combination represents a predictable use of known workflow gating and user notification techniques to improve usability and ensure completion of required steps, thereby guiding users to resolve deficiencies before progression, and would have yielded no more than expected results.
Regarding claim 18, Easterhaus, Malecha, Lee, and Webster teach the invention in claim 1, as discussed above, and further teach wherein the instructions further cause the system to require, in order to progress from the one stage to the next stage, a user to input authenticated credentials (Malecha [0071] “The database 110 may include one or more information sources for storing and providing access to data, such as the data storage device 158. The database 110 may store and provide access to various data, as described in further detail elsewhere herein. For instance, the database 110 may store files for a practitioner or patient, such as resource or informational files that may be shared with a practitioner or patient, individual files, logos or images, lab report files, patient or practitioner attributes, login credentials, etc.” and Malecha [0102] “At 212, the management engine 102 may determine whether there are additional workflow elements, actions, or workflows, for example, which may be connected together sequentially or in parallel. If the additional workflow elements are selected or may be selected, the operations from 206 may be repeated, for example. In some implementations, an output of a first workflow may serve as a trigger or input into a second workflow or stage of the workflow.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the staged referral workflow of Easterhaus to require a user to input authenticated credentials prior to progressing from one stage to the next, as taught by Malecha. Malecha discloses the use of login credentials associated with users and workflow systems in which progression between stages is controlled based on defined conditions and inputs. A person of ordinary skill would have been motivated to incorporate credential verification as a prerequisite to stage advancement in order to ensure that only authorized users can perform workflow actions, particularly in systems involving sensitive patient information. This modification represents the application of a well-known authentication mechanism to a known staged workflow process to improve security and accountability, and would have yielded predictable results consistent with established access control practices.
Claims 10, 12-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Easterhaus et al. (U.S. Patent Publication 2013/0282397 A1), referred to hereinafter as Easterhaus, in view of Malecha et al. (U.S. Patent Publication 2013/0060235 A1), referred to hereinafter as Malecha, and Webster et al. (U.S. Patent Publication 2020/0133711 A1), referred to hereinafter as Webster.
Regarding claim 10, Easterhaus teaches a method for referral management, the method comprising (Easterhaus [0007] “In brief, and at a high level, the present invention is directed to methods, systems, and computer-readable storage media for creating, among other things, a unified patient referral worklist that helps a provider to manage incoming and outgoing referrals”):
receiving patient health information relating to a referral (Easterhaus, [0049] “The receiving component 224 is configured to receive patient-related medical information such as referral orders and medical information stored in association with, for example, the native data stores 214 and 218.”);
inputting the patient health information into a referral management system, the referral management system, a screening, and an intake (Easterhaus, [0094] “FIG. 9 depicts a flow diagram illustrating an exemplary method 900 of generating a unified patient referral worklist for a provider. At a step 910, a first referral order associated with a first patient is received from a first medical organization. The first referral order may be stored in an electronic medical record system associated with the organization and may have been created by a provider associated with the first medical organization.”, Easterhaus, [0085] “The GUI 1300 further includes an action area 1322. The patient can select the checkmark in the action area 1322 for example and access one or more input fields or selectable actions. The selectable actions may include actions related to the referral order(s) such as completed or re-scheduled. Another selectable action is a pre-visit questionnaire. The patient can utilize the pre-visit questionnaire to input needed information such as demographic information, payment information, a patient-supplied medical history and review of symptoms, and a patient-supplied history of the current problem. The pre-visit questionnaire is provided to the referring provider and/or the referral provider via, for example, email, text, mail, fax, presentation on a user interface, and the like.”);
wherein the referral management system includes at least one processor; a graphical user interface, and a memory storing instructions that, when executed by the at least one processor, cause the system to (Easterhaus [0028] “With continued reference to FIG. 1, the computing environment 100 comprises a computing device in the form of a control server 102. Exemplary components of the control server 102 comprise a processing unit, internal system memory, and a suitable system bus for coupling various system components, including data store 104, with the control server 102.”, Easterhaus [0058] “Upon selection of an incoming or outgoing referral such as, for example, referral 321, the provider is navigated to a detail screen comprising detailed information about the referral 321. FIG. 4 illustrates this aspect of the invention. FIG. 4 depicts an exemplary graphical user interface (GUI) 400. The GUI 400 includes a patient identification area 412 that provides information concerning the patient who is the subject of the referral order. The information includes, for example, name, age, sex, weight, height, date of birth, patient number, payment information, primary care provider, date of last visit, and the like. The GUI 400 also includes a selectable active referral tab 414. Selection of the tab 414 displays all incoming and outgoing active referrals associated with the patient; this information is shown in the active referral area 418.”)
associating, using the referral management system, the referral with a record (Easterhaus, [0094] “FIG. 9 depicts a flow diagram illustrating an exemplary method 900 of generating a unified patient referral worklist for a provider. At a step 910, a first referral order associated with a first patient is received from a first medical organization. The first referral order may be stored in an electronic medical record system associated with the organization and may have been created by a provider associated with the first medical organization.”);
screening, using the referral management system, the referral during the screening (Easterhaus, [0085] “The GUI 1300 further includes an action area 1322. The patient can select the checkmark in the action area 1322 for example and access one or more input fields or selectable actions. The selectable actions may include actions related to the referral order(s) such as completed or re-scheduled. Another selectable action is a pre-visit questionnaire. The patient can utilize the pre-visit questionnaire to input needed information such as demographic information, payment information, a patient-supplied medical history and review of symptoms, and a patient-supplied history of the current problem. The pre-visit questionnaire is provided to the referring provider and/or the referral provider via, for example, email, text, mail, fax, presentation on a user interface, and the like.”);
processing, using the referral management system, the referral through the intake (Easterhaus, [0070] “Again turning back to FIG. 2, the referral order option component 230 is configured to determine and generate a plurality of referral order options for a patient. For instance, the referral order option component 230 may determine recommended referral options based on a patient's medical record and medical standards of care; the standards of care may be stored in association with, for example, the data store 223.”);
accepting or rejecting, using the referral management system, the referral (Easterhaus [0056] “The GUI 300 also includes a filtering area 316 that enables a provider or employees in the provider's office to filter the incoming and outgoing referrals. As seen, filtering options may include referrals for review, requested referrals, rejected referrals, outbound referrals, referrals in progress, and/or referrals for assessment. Additionally, the provider or employees in the provider's office may select multiple filtering options to create a custom worklist which can be subsequently saved. For example, a custom worklist may be generated for a provider especially if the provider is a member of a multi-provider group (i.e., “Dr. Bob's Family Practice”). Any and all such variations are contemplated as being within the scope of the invention.”); and
displaying, using the graphical user interface, a visual representation of the stage the referral is in (Easterhaus [0058] “Upon selection of an incoming or outgoing referral such as, for example, referral 321, the provider is navigated to a detail screen comprising detailed information about the referral 321. FIG. 4 illustrates this aspect of the invention. FIG. 4 depicts an exemplary graphical user interface (GUI) 400. The GUI 400 includes a patient identification area 412 that provides information concerning the patient who is the subject of the referral order. The information includes, for example, name, age, sex, weight, height, date of birth, patient number, payment information, primary care provider, date of last visit, and the like. The GUI 400 also includes a selectable active referral tab 414. Selection of the tab 414 displays all incoming and outgoing active referrals associated with the patient; this information is shown in the active referral area 418.”).
Easterhaus fails to explicitly teach having a new stage, wherein each stage includes one or more advancement criteria relating to documentation of patient health information unique to the stage;
(i) verify identifying credentials of a user to progress a referral from one stage to a next stage;
(ii) assess whether the advancement criteria for each stage having advancement criteria are satisfied;
and prevent the referral from advancing from one stage to a next stage until at least all advancement criteria of the one stage are satisfied met.
Malecha teaches having a new stage, wherein each stage includes one or more advancement criteria relating to documentation of patient health information unique to the stage (Malecha [0101] “At 210, the management engine 102 may connect one or more workflow elements, triggers, data points, patients, or other elements. For example, as a practitioner provides or indicates a workflow or protocol step or stage, the management engine 102 may logically connect the elements or steps to create an automated workflow.”, Malecha [0104] “At 214, the management engine 102 may configure and/or execute one or more workflows, for example, by executing the actions defined by the workflow elements. For example, if no more workflow elements are selected (e.g., as determined at 212), the management engine 102 may configure or logically connect workflow steps, determine which internal or external systems (e.g., components in the system 100 a) to use or communicate with to detect triggers and perform actions, etc. For example, if a practitioner indicates that a workflow for a given patient includes ordering a set of labs, taking a supplement on certain days of the week, and following up in two weeks, the management engine 102 may configure a workflow automation that orders the lab test (or transmits an order to a laboratory server 108, automatically provides a display to a practitioner for ordering the lab test, etc.), orders supplements, and/or schedules a follow-up meeting on the practitioner's and patient's calendars, etc.” and Malecha [0125] “At 316, the management engine 102 may receive lab result(s), for example, using the exported data, such as the lab order or result after completion of the lab test. For example, a workflow or protocol may include one or multiple steps, one of which may include automation to receive lab results for an ordered lab (e.g., via communication with the lab server 108) and/or provides order fulfillment data, such as lab results, which may be formatted in a PDF document.”);
(i) verify identifying credentials of a user to progress a referral from one stage to a next stage (Malecha [0071] “The database 110 may include one or more information sources for storing and providing access to data, such as the data storage device 158. The database 110 may store and provide access to various data, as described in further detail elsewhere herein. For instance, the database 110 may store files for a practitioner or patient, such as resource or informational files that may be shared with a practitioner or patient, individual files, logos or images, lab report files, patient or practitioner attributes, login credentials, etc.” and Malecha [0102] “At 212, the management engine 102 may determine whether there are additional workflow elements, actions, or workflows, for example, which may be connected together sequentially or in parallel. If the additional workflow elements are selected or may be selected, the operations from 206 may be repeated, for example. In some implementations, an output of a first workflow may serve as a trigger or input into a second workflow or stage of the workflow.”);
(ii) assess whether the advancement criteria for each stage having advancement criteria are satisfied (Malecha [0102] “At 212, the management engine 102 may determine whether there are additional workflow elements, actions, or workflows, for example, which may be connected together sequentially or in parallel. If the additional workflow elements are selected or may be selected, the operations from 206 may be repeated, for example. In some implementations, an output of a first workflow may serve as a trigger or input into a second workflow or stage of the workflow.” and Malecha [0103] “As an illustrative example, the management engine 102 may receive a second input selecting a second workflow element that defines a second action. The workflow may be automatically executed based on the second data or trigger. For example, a first action may include transmitting a request for status information (e.g., indicating a status associated with the accessed data) to a client device 104 of a patient. For instance, the second action may include transmitting a recommendation to the patent's client device including a patient survey. The workflow element or stage may also include, for example, receiving survey responses. Additional or fewer actions may be performed.”);
Webster teaches prevent the referral from advancing from one stage to a next stage until at least all advancement criteria of the one stage are satisfied met (Webster [0200] “The rules 650 can define workflow process segment model threshold conditions for determining whether a software development workflow process model execution is advanced to a next workflow process segment model or terminated. For example, a workflow process segment model threshold condition can be a qualitative condition (e.g., “pass,” or “fail”) and/or a quantitative condition, such as greater or less than a predetermined value (e.g., 100%). Accordingly, a workflow process segment model threshold condition may be satisfied if 100% of the events and/or tasks within a particular workflow process segment model execution are passed.”, Webster [0201] “The rules 650 can define workflow process segment model gate conditions for determining whether a software development workflow process model execution is advanced to a next workflow process segment model, terminated, or held. The gate condition can be in addition to, or instead of, other conditions (e.g., workflow process segment model threshold conditions). For example, a gate condition may require an administrator, or other user with sufficient privileges, to approve a workflow process advancement prior to actually advancing an execution of the software development workflow process model. For example, a PROD segment model may require an administrator to approve application deployment prior to deploying the application to a production system.”, and Webster [0202] “A workflow process segment can include one or more quality gate conditions, and/or quality gate conditions can include different condition types. For example, a workflow process segment can include one or more quality gate conditions, and the condition types can include critical conditions, non-critical conditions, and/or the like. Each condition type can be associated with a threshold value and/or value range (collectively, “value”). For example, critical condition types may be associated with a 100% pass rate in order for the software development workflow process model to advance to the next workflow process segment, while a non-critical condition type may be associated with a 90% pass rate in order for the software development workflow process model to advance to the next workflow process segment.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the referral management method of Easterhaus to incorporate Malecha’s workflow-based processing and Webster’s rule-based threshold and gate condition mechanisms. Easterhaus teaches receiving and managing referral patient information within a system, while Malecha teaches organizing operations into structured, multi-step workflows in which actions and data are processed through defined stages. Webster further teaches applying threshold conditions and gate conditions to determine whether a workflow is permitted to advance to a subsequent stage, including preventing advancement or holding progression until specified criteria are satisfied. A person of ordinary skill would have recognized that integrating such workflow control techniques into a referral management process would improve the reliability of referral intake by ensuring that required information and steps are satisfied prior to progression.
It would have been further obvious to apply Webster’s gate and threshold condition logic to the staged workflow of Malecha within Easterhaus’ referral system to enforce advancement criteria relating to patient information and documentation. Enforcing such criteria ensures that referrals are not advanced prematurely without necessary data, thereby improving data integrity, reducing processing errors, and supporting more accurate intake decisions. These are well-known design considerations in workflow and case management systems, where controlling progression based on satisfaction of defined conditions is a routine and predictable technique. The modification therefore represents no more than the predictable use of prior art elements according to their established functions.
Additionally, incorporating verification of user credentials prior to progressing a referral between stages would have been an obvious implementation detail, as verifying user identity and permissions before performing system actions is a well-understood, routine, and conventional practice in computer systems and access-controlled workflows. A person of ordinary skill would have been motivated to include such verification to ensure accountability and authorization within the referral management process. Accordingly, the combined teachings of Easterhaus, Malecha, and Webster render the claimed method obvious under 35 U.S.C. § 103.
Regarding claim 12, Easterhaus, Malecha, and Webster teach the invention in claim 10, as discussed above, and further teach wherein screening is done based by asking a series of questions and wherein the questions are customizable, using the referral management system, for an organization using the method (Easterhaus, [0086] “The GUI 1300 further includes an action area 1322. The patient can select the checkmark in the action area 1322 for example and access one or more input fields or selectable actions. The selectable actions may include actions related to the referral order(s) such as completed or re-scheduled. Another selectable action is a pre-visit questionnaire. The patient can utilize the pre-visit questionnaire to input needed information such as demographic information, payment information, a patient-supplied medical history and review of symptoms, and a patient-supplied history of the current problem. The pre-visit questionnaire is provided to the referring provider and/or the referral provider via, for example, email, text, mail, fax, presentation on a user interface, and the like.” and Easterhaus, [0077] “Additionally, the GUI 500 includes a customized template area 518. The area 518 may include templates customized by a healthcare organization to which the provider is affiliated as well as blank templates. The customized area 518 also includes a search template box 519 by which the provider can search for templates that have been created but are not displayed.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to perform screening by asking a series of customizable questions using the referral management system. Easterhaus teaches collecting referral information through a pre-visit questionnaire that includes a series of questions directed to patient demographics, medical history, and other relevant inputs used during screening. Easterhaus further teaches that templates within the system may be customized by a healthcare organization to tailor the information collected and presented within the system. A person of ordinary skill in the art would have recognized that questionnaires are a form of structured template for data collection, and that allowing such questionnaires to be customized by an organization would improve flexibility and adaptability to different clinical workflows and intake requirements. Modifying the questionnaire of Easterhaus to be customizable therefore represents no more than the predictable use of known data collection and user interface techniques to tailor screening processes to organizational needs, yielding predictable benefits such as improved relevance of collected information and increased efficiency in referral evaluation.
Regarding claim 13, Easterhaus, Malecha, and Webster teach the invention in claim 10, as discussed above, and further teach wherein a user inputs the identifying credentials when progressing a referral from one stage to a next stage (Malecha [0071] “The database 110 may include one or more information sources for storing and providing access to data, such as the data storage device 158. The database 110 may store and provide access to various data, as described in further detail elsewhere herein. For instance, the database 110 may store files for a practitioner or patient, such as resource or informational files that may be shared with a practitioner or patient, individual files, logos or images, lab report files, patient or practitioner attributes, login credentials, etc.” and Malecha [0102] “At 212, the management engine 102 may determine whether there are additional workflow elements, actions, or workflows, for example, which may be connected together sequentially or in parallel. If the additional workflow elements are selected or may be selected, the operations from 206 may be repeated, for example. In some implementations, an output of a first workflow may serve as a trigger or input into a second workflow or stage of the workflow.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to require a user to input identifying credentials when progressing a referral from one stage to a next stage within a workflow system. Malecha teaches maintaining and utilizing user data, including login credentials, within a system that manages workflows and interactions. Malecha further teaches executing workflows composed of sequential stages, where progression between stages is based on defined inputs, triggers, or actions. A person of ordinary skill in the art would have recognized that requiring user authentication (input of identifying credentials) at points of workflow progression is a well-known technique for ensuring proper access control, accountability, and data integrity within systems handling sensitive information, particularly in healthcare environments. Incorporating credential input at stage transitions therefore represents no more than the predictable application of known authentication mechanisms to an existing staged workflow system, yielding predictable benefits such as user accountability and controlled progression through the referral process.
Claim 14 is analogous to claim 7, thus claim 14 is similarly analyzed and rejected in a manner consistent with the rejection of claim 7.
Regarding claim 15, Easterhaus, Malecha, and Webster teach the invention in claim 10, as discussed above, and further teach wherein the visual representation is a bar graph (Easterhaus [0058] “Upon selection of an incoming or outgoing referral such as, for example, referral 321, the provider is navigated to a detail screen comprising detailed information about the referral 321. FIG. 4 illustrates this aspect of the invention. FIG. 4 depicts an exemplary graphical user interface (GUI) 400. The GUI 400 includes a patient identification area 412 that provides information concerning the patient who is the subject of the referral order. The information includes, for example, name, age, sex, weight, height, date of birth, patient number, payment information, primary care provider, date of last visit, and the like. The GUI 400 also includes a selectable active referral tab 414. Selection of the tab 414 displays all incoming and outgoing active referrals associated with the patient; this information is shown in the active referral area 418.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement the visual representation of referral information as a bar graph. Easterhaus teaches presenting referral data in a graphical user interface, including displaying multiple referrals and associated information in a structured visual format. A person of ordinary skill in the art would have recognized that selecting a particular type of graphical visualization, such as a bar graph, to represent counts or distributions of referrals across stages is a well-known and routine design choice for improving readability and comparative analysis of data. Bar graphs are commonly used to visually convey quantities across categories, and applying such a known visualization technique to the referral data of Easterhaus would have been a predictable variation yielding the benefit of enhanced clarity and ease of interpretation. This modification represents no more than the predictable use of prior art elements according to their established functions and would have been within the ordinary skill in the art.
Claim 16 is analogous to claim 3, thus claim 16 is similarly analyzed and rejected in a manner consistent with the rejection of claim 3.
Regarding claim 19, Easterhaus, Malecha, Webster teach the invention in claim 10, as discussed above, and further teach wherein processing the referral through the intake stage further comprising connecting, through the referral management system, to an electronic health record (EHR) system including a database of health records (Easterhaus [0038] “As shown in FIG. 2, the referral service 210 is capable of communicating with the first medical organization 212 and the second medical organization 216 in order to obtain patient medical information. The medical organizations 212 and 216 may include hospitals, clinics, providers' offices, and the like. Patient information collected from the first medical organization 212 and the second medical organization 216 may include, but is not limited to, information that is stored in association with a patient's electronic medical record (EMR). Information in the EMR describes various aspects of the patient state, including patient vitals, lab results, medication orders, referral orders, diagnosis codes, condition codes, clinical orders, indexed values from clinical notes or other text documents, patient demographic information, patient history, patient images, and a variety of other patient information.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to connect a referral management system to an electronic health record (HER) system when processing a referral through an intake stage. Easterhaus teaches that the referral service communicates with medical organizations to obtain patient medical information that is stored in association with a patient’s electronic medical record, including a wide range of clinical and demographic data. A person of ordinary skill in the art would have recognized that integrating or connecting the referral management workflow with an EHR system is a well-known and routine practice in healthcare information systems, enabling efficient access to patient data, reducing duplication of data entry, and improving continuity of care. Modifying the referral processing of Easterhaus to explicitly include a connection to an EHR system comprising a database of health records therefore represents no more than the predictable use of known system integration techniques to enhance data availability and workflow efficiency, yielding predictable benefits in improving accuracy and completeness of referral processing.
Regarding claim 20, Easterhaus, Malecha, and Webster teach the invention in claim 19, as discussed above, and further teach and further comprising at least one of (a) extracting data from the EHR system; and (b) synchronizing data between the referral management system and the EHR system (Easterhaus [0038] “As shown in FIG. 2, the referral service 210 is capable of communicating with the first medical organization 212 and the second medical organization 216 in order to obtain patient medical information. The medical organizations 212 and 216 may include hospitals, clinics, providers' offices, and the like. Patient information collected from the first medical organization 212 and the second medical organization 216 may include, but is not limited to, information that is stored in association with a patient's electronic medical record (EMR). Information in the EMR describes various aspects of the patient state, including patient vitals, lab results, medication orders, referral orders, diagnosis codes, condition codes, clinical orders, indexed values from clinical notes or other text documents, patient demographic information, patient history, patient images, and a variety of other patient information.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to extract data from, and/or synchronize data between, a referral management system and an electronic health record (EHR) system. Easterhaus teaches that the referral service communicates with external medical organization systems to obtain patient medical information stored in electronic medical records, including a wide range of clinical, demographic, and referral data. A person of ordinary skill in the art would have recognized that such communication necessarily involves extracting relevant data from the EHR system for use in the referral workflow, and that maintaining consistency between systems through data synchronization is a well-known and routine practice in healthcare information systems to ensure data accuracy, reduce redundancy, and support coordinated care. Modifying Easterhaus to explicitly include data extraction and/or synchronization between the referral management system and the EHR system therefore represents no more than the predictable application of known data integration techniques, yielding predictable benefits such as improved data consistency and workflow efficiency.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Easterhaus et al. (U.S. Patent Publication 2013/0282397 A1), referred to hereinafter as Easterhaus, in view of Malecha et al. (U.S. Patent Publication 2013/0060235 A1), referred to hereinafter as Malecha, and Webster et al. (U.S. Patent Publication 2020/0133711 A1), referred to hereinafter as Webster, in further view of Lee et al. (U.S. Patent 11037676 B2), referred to hereinafter as Lee.
Easterhaus, Malecha, and Webster teach the invention in claim 10, as discussed above, and further teach wherein the intake stage comprises an assessment stage (Easterhaus [0051] “The referral orders may also include attachments such as test results, procedure results, and other types of medical documentation.” and Easterhaus [0060] “The medical documentation area 420 also includes an attachment area 421 where the referring provider can attach pertinent clinical documentation (lab results, procedure results, patient history, a pre-visit questionnaire completed by the patient, radiographic images, EKGs, etc.) to further assist the referral provider.”, and
Malecha [0104] “At 214, the management engine 102 may configure and/or execute one or more workflows, for example, by executing the actions defined by the workflow elements. For example, if no more workflow elements are selected (e.g., as determined at 212), the management engine 102 may configure or logically connect workflow steps, determine which internal or external systems (e.g., components in the system 100 a) to use or communicate with to detect triggers and perform actions, etc. For example, if a practitioner indicates that a workflow for a given patient includes ordering a set of labs, taking a supplement on certain days of the week, and following up in two weeks, the management engine 102 may configure a workflow automation that orders the lab test (or transmits an order to a laboratory server 108, automatically provides a display to a practitioner for ordering the lab test, etc.), orders supplements, and/or schedules a follow-up meeting on the practitioner's and patient's calendars, etc.”).
Easterhaus, Malecha, and Webster fail to explicitly teach a tour.
Lee teaches a tour (Lee, Col. 1, lines 53-58, “In one or more embodiments described herein, systems, computer-implemented methods, apparatus and/or computer program products that facilitate managing and optimizing the experience of patients and visitors in association with visiting a medical facility.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement an intake stage that includes multiple sub-stages such as an assessment stage and a tour stage. Easterhaus teaches collecting and utilizing clinical and diagnostic information, including test results, medical documentation, and patient history, which are implicitly associated with assessment activities performed during referral processing. Malecha further teaches configuring workflows composed of multiple sequential or logically connected steps, where different actions (ordering tests, receiving results, scheduling follow-ups) are performed at different stages of a workflow. Lee additionally teaches incorporating patient visit or facility experience components, such as managing and optimizing visits to a medical facility, which would reasonably include tours or similar pre-admission interactions. A person of ordinary skill in the art would have recognized that structuring an intake process into distinct sub-stages, such as assessment (clinical evaluation) and tour (facility interaction), within a broader intake stage is a predictable implementation of known workflow design principles, enabling improved organization, and enhanced patient experience. This modification represents no more than the predictable use of prior art elements according to their established functions and would have yielded predictable benefits in improving intake process efficiency.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted 12/19/2025 with respect to the rejection of claims 1-20 have been carefully considered and are addressed below.
Claim objections
The objection to claim 19 is withdrawn. Applicant has amended claim 19 to correct the typographical error by replacing “The system of claim 10” with “The method of claim 10” with resolves the objection.
Claim Rejections - 35 USC § 101
Applicant’s arguments and claim amendments have been fully considered but are not persuasive. Applicant states that the amended claims integrate any alleged abstract idea into a practical application by reciting advancement criteria relating to stage specific documentation, credential verification, and enforced progression constraints, and further states that these features provide a technical improvement over existing systems. The Examiner respectfully disagrees. As amended, the claims continue to recite limitations that define rules governing the execution of a referral intake workflow, including verifying user credentials, assessing whether advancement criteria are satisfied, and preventing progression between stages unless the criteria are met. These limitations are directed to managing and enforcing a sequence of steps in a business or administrative process (referral intake and acceptance), and do not reflect any improvement to the functioning of a computer or to any other technology. Instead, the processor is used as a tool to implement and enforce the abstract idea.
Applicant’s reliance on the recitation of “advancement criteria relating to documentation of patient health information unique to the stage” and the requirement that a referral cannot advance even with verified identifying credentials is also not persuasive. These limitations establish conditions on when a referral may proceed within the workflow, ensuring that required information is collected and validated prior to progression. These constraints represent business rules or policies governing intake procedures, rather than a technological solution to a technological problem. The claims do not recite any specific improvement in processing techniques nor do they provide any particularized implementation of credential verification or criteria evaluation beyond generic computer functionality.
Applicant further states that the claims recite a particular way of achieving a desired outcome. However, the recited particular way amounts to specifying conditions and requirements for progressing through stages of a referral intake process, which is itself part of the abstract idea. Limiting an abstract idea to a particular sequence of steps or rules does not integrate the exception into a practical application where those steps organize certain methods of human activity. The alleged improvements relate to improved completeness or accuracy of referral intake decisions, which constitute improvements to a business process rather than to computer technology.
With respect to the additional elements, including the processor, memory, and graphical user interface, these elements are recited at a high level of generality and are invoked as tools to perform and existing process of organizing and managing referral intake activities. The graphical user interface is used to display information (an active referrals graph), which constitutes mere presentation of information and does not impose a meaningful limit on the abstract idea. These elements, whether considered individually or in combination, do not integrate the abstract idea into a practical application.
Lastly, Applicant’s arguments under Step 2B are not persuasive because the amended claims do not include additional elements that amount to significantly more than the abstract idea. The specification describes the system as being implemented using generic computing components and standard data processing operations, without any indication of unconventional hardware or software techniques. The added limitations relating to advancement criteria and enforced progression further emphasize the use of rule-based workflow management, which uses a general computer for an administrative process. Accordingly, the claims do not include an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter, and the rejection under 35 U.S.C. § 101 is maintained.
Claim Rejections - 35 USC § 103
Applicant’s arguments traversing the prior art rejection in the previous Office Action have been fully considered. However, those arguments are rendered moot because the present rejection under 35 U.S.C. §103 relies on a different set of prior art references (Easterhaus, Malecha, Lee, and Webster), which teach or suggest the limitations of the claims. Accordingly, Applicant’s prior arguments are not responsive to the current grounds of rejection. The rejection of claims 1-20 under 35 U.S.C. §103 is therefore maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Snell et al. (U.S. Publication 2016/0125070) teaches techniques that involve evaluating request a workflow against exceptions and generating at least one action item based on the query result and workflow evaluation.
Lamb et al. (International Publication WO 2005/055207 A2) teaches methods and systems that enable digital communications and referral management between healthcare referrers and providers, tracking referrals from initiation to completion.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYRA R LAGOY whose telephone number is (703)756-1773. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kambiz Abdi can be reached at (571)272-6702. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.R.L./Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685