DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 06/05/2026 has been entered.
Response to Arguments
Rejection Under 101
Applicant's arguments filed 06/05/2026 have been fully considered.
Applicant argues the claims go beyond mere organization of human activity and recite an improvement to the function of a computer. The claims are directed to a technical improvement as discussed in the specification at [0005] about difficulties for patients to search for providers. The claims recite specific algorithms and techniques for considering patient feedback in the matching process such that the claims recite improvements to the operation of the computer system itself.
In response to Applicant’s argument, the additional elements are addressed in step 2A prong 2 of the analysis below, where the additional elements are bolded. As addressed below, the additional elements merely invoke existing computers or computer components (e.g., database, interface, processor, machine learning routine, etc.) as tools to perform the abstract idea rather than improve the computer or existing technology. The patient’s difficulties with finding providers is not a technical problem. Therefore, the additional elements were found to invoke a computer environment and do not amount to a practical application. See the rejection below for further clarification.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4-10, 13-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Step 1 of the Alice/Mayo Test
Claims 1, 4-10, 13-19 are drawn to an apparatus, which is within the four statutory categories (i.e. apparatus).
Step 2A of the Alice/Mayo Test - Prong One
The independent claim 1 recites:
A healthcare profile card indexing apparatus comprising:
a patient database including patient profile records for a plurality of patients, each patient profile record including patient information provided by a respective patient including individually weighted properties comprising at least a desired healthcare provider type and a medical condition, wherein different weights are assigned to each property;
a healthcare provider database including healthcare provider profile records for a plurality of healthcare providers, each healthcare provider profile record including healthcare provider information provided by a respective healthcare provider including properties comprising at least a healthcare provider type, a medical specialization, medical treatments provided, and a medical practice field, wherein different weights are assigned to each property;
at least one application programming interface; and
a processor communicatively coupled to the patient database, the healthcare provider database, and the at least one application programming interface, the processor configured to:
receive, from a patient terminal, a request message,
responsive to the request message, determine a patient profile record in the patient database that is associated with a patient of the patient terminal,
compare the determined patient profile record to the healthcare provider profile records in the healthcare provider database,
determine a healthcare provider index that is indicative of a degree of matching between the patient profile record and potentially matching healthcare provider profile records based at least in part on matching the individually weighted properties of the patient profile record to the individually weighted properties of the potential matching healthcare provider profile records,
create a healthcare provider profile card for each of the potentially matching healthcare providers, each healthcare provider profile card comprising a digital graphical page that displays information from the corresponding healthcare provider profile record, the information including a healthcare provider name, a geographic location, the healthcare provider type, the medical specialization, the medical treatments provided, and the medical practice,
adjust properties of the healthcare provider profile card based on a classification process by determining, for the patient profile record, patient information that does not match comparable healthcare provider information of a potentially matching healthcare provider, wherein at least some of the patient information that does not match the comparable healthcare provider information correspond to a category or field that is classified as being non-critical, and removing the non-matching healthcare provider information form the healthcare provider profile card of the potential matching healthcare provider before making the healthcare provider profile card available for display to the patient,
determine an order for the healthcare provider profile cards based on the degree of matching with the patient profile record, with healthcare provider profile cards having a higher degree of matching being placed first in the order,
cause the at least one application programming interface to sequentially provide the ordered healthcare provider profile cards for displayed at the patient terminal of the patient,
receive, via the at least one application programming interface, a patient input in relation to one of the ordered healthcare provider profile cards,
queue healthcare provider profile cards in the healthcare provider index responsive to the patient input, by performing the steps of:
(a) determining a patient selection, either being indicative of an acceptance or rejection of the healthcare provider profile;
(b) computing a first set of correlations determined by at least one of an algorithm, machine learning routine, conditional filter(s), and process between patient and healthcare provider profile records;
(c) refining the weights assigned to the properties of patient profile record using the patient selection and correlations that exceed a threshold of sufficient matching;
(d) computing a separate second set of correlations determined by at least one of an algorithm, machine learning routine, conditional filter(s), and process based between the patient record with refined weights and healthcare provider profile record
(e) automatically reordering the healthcare provider index indicative of the second set of correlations; and
(f) displaying a next ordered healthcare provider profile card from the healthcare provider index via the at least one application programming interface,
responsive to the patient input being indicative of an acceptance of the healthcare provider profile card, determine if the healthcare provider has already accepted the patient by accessing a linkage database,
responsive to the healthcare provider having not accepted the patient, transmit, via the at least one application programming interface, a message to a healthcare provider terminal of the healthcare provider indicative of a pending request from the patient, and
responsive to the healthcare provider having already accepted the patient before the patient acceptance of the healthcare provider profile card, cause a linkage record to be created indicative of a pairing between the patient and the healthcare provider and enable via the at least one application programming interface, the patient to communicate with the healthcare provider.
These underlined elements recite an abstract idea that can be categorized, under its broadest reasonable interpretation, to cover the management of personal relationships or interactions between people (e.g., following rules to facilitate matching of a provider and patient). For example, but for the multiple databases, processor, interface, digital graphical page, application programming interface, machine learning routine, and patient terminal, the limitations in the context of this claim encompass an automation of organizing medical information to determine the degree of matching for the best provider and patient, matching and presenting provider profile cards to the patient, and linking the patient and provider for communication after acceptance. If a claim limitation, under its broadest reasonable interpretation, covers management of management of personal relationships or interactions but for the recitation of generic computer components, then the limitations fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. See MPEP § 2106.04(a).
Dependent claims recite additional subject matter which further narrows or defines the abstract idea embodied in the claims (such as claims 4-10, 13-19 reciting particular aspects of the abstract idea).
Step 2A of the Alice/Mayo Test - Prong Two
For example, the independent claim 1 recites:
A healthcare profile card indexing apparatus comprising: (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f))
a patient database including patient profile records for a plurality of patients, each patient profile record including patient information provided by a respective patient including individually weighted properties comprising at least a desired healthcare provider type and a medical condition, (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)) wherein different weights are assigned to each property;
a healthcare provider database including healthcare provider profile records for a plurality of healthcare providers, each healthcare provider profile record including healthcare provider information provided by a respective healthcare provider including properties comprising at least a healthcare provider type, a medical specialization, medical treatments provided, and a medical practice field, (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)) wherein different weights are assigned to each property;
at least one application programming interface; and (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f))
a processor communicatively coupled to the patient database, the healthcare provider database, and the at least one application programming interface, the processor configured to: (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f))
receive, from a patient terminal, (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)) a request message,
responsive to the request message, determine a patient profile record in the patient database that is associated with a patient of the patient terminal,
compare the determined patient profile record to the healthcare provider profile records in the healthcare provider database,
determine a healthcare provider index that is indicative of a degree of matching between the patient profile record and potentially matching healthcare provider profile records based at least in part on matching the individually weighted properties of the patient profile record to the individually weighted properties of the potential matching healthcare provider profile records,
create a healthcare provider profile card for each of the potentially matching healthcare providers, each healthcare provider profile card comprising a digital graphical page (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)) that displays information from the corresponding healthcare provider profile record, the information including a healthcare provider name, a geographic location, the healthcare provider type, the medical specialization, the medical treatments provided, and the medical practice,
adjust properties of the healthcare provider profile card based on a classification process by determining, for the patient profile record, patient information that does not match comparable healthcare provider information of a potentially matching healthcare provider, wherein at least some of the patient information that does not match the comparable healthcare provider information correspond to a category or field that is classified as being non-critical, and removing the non-matching healthcare provider information form the healthcare provider profile card of the potential matching healthcare provider before making the healthcare provider profile card available for display to the patient,
determine an order for the healthcare provider profile cards based on the degree of matching with the patient profile record, with healthcare provider profile cards having a higher degree of matching being placed first in the order,
cause the at least one application programming interface to (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)) sequentially provide the ordered healthcare provider profile cards for displayed at the patient terminal of the patient, (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f))
receive, via the at least one application programming interface (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)), a patient input in relation to one of the ordered healthcare provider profile cards,
queue healthcare provider profile cards in the healthcare provider index responsive to the patient input, by performing the steps of:
(a) determining a patient selection, either being indicative of an acceptance or rejection of the healthcare provider profile;
(b) computing a first set of correlations determined by at least one of an algorithm, machine learning routine (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)), conditional filter(s), and process between patient and healthcare provider profile records;
(c) refining the weights assigned to the properties of patient profile record using the patient selection and correlations that exceed a threshold of sufficient matching;
(d) computing a separate second set of correlations determined by at least one of an algorithm, machine learning routine (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)), conditional filter(s), and process based between the patient record with refined weights and healthcare provider profile record
(e) automatically reordering the healthcare provider index indicative of the second set of correlations; and
(f) displaying a next ordered healthcare provider profile card from the healthcare provider index via the at least one application programming interface, (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f))
responsive to the patient input being indicative of an acceptance of the healthcare provider profile card, determine if the healthcare provider has already accepted the patient by accessing a linkage database, (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f))
responsive to the healthcare provider having not accepted the patient, transmit, via the at least one application programming interface, a message to a healthcare provider terminal of the healthcare provider indicative of a pending request from the patient, and (merely insignificant extrasolution activity steps as noted below, see MPEP 2106.05(g))
responsive to the healthcare provider having already accepted the patient before the patient acceptance of the healthcare provider profile card, cause a linkage record to be created indicative of a pairing between the patient and the healthcare provider and enable via the at least one application programming interface, (merely invokes use of computer and other machinery as a tool as noted below, see MPEP 2106.05(f)) the patient to communicate with the healthcare provider.
The judicial exception is not integrated into a practical application. In particular, the additional elements do not integrate the abstract idea into a practical application, other than the abstract idea per se, because the additional elements amount to no more than limitations, which:
amount to mere instructions to apply an exception (such as recitations of the multiple databases, processor, interface, digital graphical page, application programming interface, machine learning routine, and patient terminal, thereby invoking computers as a tool to perform the abstract idea, see applicant’s specification [0053]-[0063], [0124], see MPEP 2106.05(f))
add insignificant extra-solution activity to the abstract idea (such as recitation of transmitting messages to providers indicative of patient requests amounts to insignificant extrasolution activity, see MPEP 2106.05(g))
Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 4-10, 13-19 recite additional limitations which amount to invoking computers as a tool to perform the abstract idea, and claims 4-10, 13-19 additional limitations which generally link the abstract idea to a particular technological environment or field of use). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation and do not impose a meaningful limit to integrate the abstract idea into a practical application.
Step 2B of the Alice/Mayo Test for Claims
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception and add insignificant extra-solution activity to the abstract idea. Additionally, the additional elements, other than the abstract idea per se, amount to no more than elements which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields (such as using the multiple databases, processor, interface, digital graphical page, application programming interface, machine learning routine, and patient terminal, e.g., Applicant’s spec describes the computer system with it being well-understood, routine, and conventional because it describes in a manner that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such elements to satisfy 112a. (See Applicant’s Spec. [0053]-[0063], [0082], [0124]); using a processor, databases, interface, application programming interface, machine learning routine, etc., e.g., merely adding a generic computer, generic computer components, or a programmed computer to perform generic computer functions, Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 134 S. Ct. 2347, 2358-59, 110 USPQ2d 1976, 1983-84 (2014)
adding insignificant extrasolution activity to the abstract idea, for example mere data gathering, selecting a particular data source or type of data to be manipulated, and/or insignificant application. The following represent examples that courts have identified as insignificant extrasolution activities (e.g. see MPEP 2106.05(g)): transmitting messages to providers indicative of patient requests, e.g., receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i)
Dependent claims recite additional subject matter which, as discussed above with respect to integration of the abstract idea into a practical application, amount to invoking computers as a tool to perform the abstract idea and are generally linking the abstract idea to a particular field of environment. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Therefore, the claims are not patent eligible, and are rejected under 35 U.S.C. § 101.
Subject Matter Free of Prior Art
Claims 1, 4-10, 13-19 are free of prior art over Amino, Inc. (WO 2017/039755) in view of Salazar et al. (US 2016/0371439) and Kisnisci et al. (US 2016/0154974).The prior art references, or reasonable combination thereof, could not be found to disclose, or suggest all of the limitations found in the independent claims. The closest prior art is Amino, Inc. (WO 2017/039755), which teaches generating and displaying ranked lists of healthcare providers and their provider information. Salazar et al. (US 2016/0371439) teaches determining matches between patients and providers once a patient makes a match request. Kisnisci et al. (US 2016/0154974) teaches creating and searching for cards of interest to the user as well as sorting relevant cards. The claims do not teach, in combination with the other recited limitations, receiving patient input relating to the ordered provider profile cards and responsive to a rejection, updating the weighted properties based on the rejection, reorder the provider cards based on the weighted properties, and display the next ordered provider card to be displayed to the patient terminal. The references taken solely, or in combination, fail to provide the required limitations, and modification of any complementary combination of the references of record would be impermissible hindsight and not provide any advantages over their present application. The dependent claims are also free of prior art due to their corresponding dependency of the independent claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANDA R COVINGTON whose telephone number is (303)297-4604. The examiner can normally be reached Monday - Friday, 10 - 5 MT.
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, Jason B. Dunham can be reached on (571) 272-8109. 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.
/AMANDA R. COVINGTON/Examiner, Art Unit 3686
/RACHELLE L REICHERT/Primary Examiner, Art Unit 3686
Prosecution Insights