DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Claims 1-4, 6-13, & 15-20 were previously pending in this application. The amendment filed on 17 February 2026 has been entered and the following has occurred: Claims 1, 11, & 20 have been amended. No claims have been cancelled or added.
Claims 1-4, 6-13, & 15-20 remain pending in the application.
Claim Rejections - 35 USC §101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, 6-13, & 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
The claims recite subject matter within a statutory category as a process (claims 1-4 & 6-10), machine (claims 11-13 & 15-19), and manufacture (claim 20) (Subject Matter Eligibility (SME) Test Step 1: Yes) which recite steps of:
identifying, at an event response recommendation system, an event affecting a healthcare facility;
identifying, by the event response recommendation system, at least one patient within the healthcare facility needing transferred due to the event, wherein the identifying comprises identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effects of the event with needs of the patients within the healthcare facility, wherein
the identifying is at least in part based upon the event response recommendation system communicating, using at least one network device, with at least one other system of the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient and pulling the information from the at least one other system; and
generating, by the event response recommendation system, a recommendation for transferring the at least one patient, wherein the generating a recommendation comprises identifying at least one transferee healthcare for the at least one patient that can supply a resource needed by the at least one patient that can receive the at least one patient and that can supply a resource needed by the at least one patient as identified from the characteristics of the patient and based upon a level of care needed by the patient, wherein
the identifying the at least one transferee healthcare facility comprises accessing a status transmission of the at least one transferee healthcare facility that is provided the at least one transferee healthcare facility, wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event.
These steps of identifying an event affecting a healthcare facility, identifying at least one patient within the healthcare facility needing transferred due to the event, and generating a recommendation for transferring the at least one patient, as drafted, under the broadest reasonable interpretation, includes performance of the limitation in the mind but for recitation of generic computer components. That is, other than reciting steps as performed by the generic computer components, nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the identifying an event affecting a healthcare facility language, identifying an event and patients that could be affected by the effects of the event in the context of this claim encompasses a mental process of a user or person within the healthcare facility determining that there is an event or emergency that may affect one or more patients within the facility. Similarly, the limitation of identifying at least one patient within the healthcare facility needing transferred due to the event based on characteristics of the patient, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, such as a user or person within the healthcare facility identifying the one or more patients that may be affected by the ongoing event and needing to transfer or move said patient. For example, but for the generating a recommendation for transferring the at least one patient and identifying at least one healthcare facility for receiving the patient language based on recommendations for other patients to optimize said recommendation generation, generating a recommendation in the context of this claim encompasses a mental process of the user or person in the healthcare facility recommending the one or more affected patients be transferred to a different location and which patients require more urgent attention or transfer. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, such as by use of the generic event response recommendation system, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
These steps of identifying an event affecting a healthcare facility, identifying one or more patients that need to be transferred to a different location because of the event, and producing a recommendation for transferring the patient, including determination of resources needed for transferring the patient to another facility, as drafted, under the broadest reasonable interpretation, includes methods of organizing human activity. MPEP 2106.04(a)(2)(II) defines certain methods of organizing human activity, including fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations), and/or managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions). The steps recited above include aspects of managing personal behavior or interactions between people. In particular, the steps including identifying an event affecting a healthcare facility, identifying one or more patients that need to be transferred to a different location because of the event, and producing a recommendation for transferring the patient based on characteristics of the patient and recommendations for other patients needing transferred amounts to managing personal behavior, at least by generating rules and/or recommendation for a healthcare facility or entities within the healthcare facility to follow regarding transferring one patient in response to one or more events. Accordingly, the claim recites an abstract idea.
Dependent claims recite additional subject matter which further narrows or defines the abstract idea embodied in the claims (such as claims 2-4, 6-10, 12-13 & 15-19, reciting particular aspects of how enacting certain actions/orders based on recommendations, identifying transferee healthcare facilities, and/or generating recommendations may be performed in the mind but for recitation of generic computer components) (SME Test Step 2A, Prong 1: Yes).
This 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 recitation of an event response recommendation system, a processor/processing device, a memory device, and a computer readable storage device, amounts to invoking computers as a tool to perform the abstract idea, see Applicant’s Specification [0021]-[0022] for an event response recommendation system, [0066] for a processor/processing device, [0066]/[0070] for a memory device, and [0066]/[0070] for a computer readable storage device, see MPEP 2106.05(f));
add insignificant extra-solution activity to the abstract idea (such as recitation of identifying, i.e. receiving data of, an event affecting a healthcare facility, identifying, i.e. receiving data of, at least one patient within the healthcare facility needing transferred due to the event, accessing a status transmission of the at least one transferee healthcare facility that is provided the at least one transferee healthcare facility, communicating with at least one other system of the healthcare facility that stores information related to the patients and pulling the information from the at least one other system amounts to mere data gathering; recitation of determining patients in the facility that will be affected by the effects of the identified event, generating a recommendation for transferring the at least one patient based on characteristics of the patient, such as identifying at least one healthcare facility that will receive the patient based on recommendations for other patients needing transferred, such as by determining urgency for transferring of the one or more patients amounts to selecting a particular data source or type of data to be manipulated, recitation of identifying varying aspects, e.g. an event/at least one patient within the healthcare facility, from received data, such as characteristics of the patient amounts to insignificant application, see MPEP 2106.05(g));
generally link the abstract idea to a particular technological environment or field of use (such as recitation of a recommendation system within a healthcare facility, see MPEP 2106.05(h)).
Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 2-4, 6-10, 12-13 & 15-19, which recite limitations relating to an event response recommendation system or computerized steps to be performed at an event response recommendation system, additional limitations which amount to invoking computers as a tool to perform the abstract idea, see Applicant’s Specification [0021]-[0022] for an event response recommendation system, see MPEP 2106.05(f); claims 9-10 & 18-19, which recite limitations relating to receiving a status of other healthcare facilities via a status transmission, monitoring the at least one patient after being transferred, and providing notifications to the healthcare facility regarding a status of the at least one patient identified from the monitoring, additional limitations which add insignificant extra-solution activity to the abstract idea which amounts to mere data gathering; claims 2-4, 6-8, 12-13, & 15-17, which recite limitations relating to initiating a transfer for the at least one patient, such as responsive to a user approving the recommendation, initiating comprises generating orders for transferring the at least one patient, identifying a transferee healthcare facility for transferring the at least one patient, identifying at least one characteristics of the patient, matching at least one characteristics to at least one healthcare facility based upon facility attributes, identifying a plurality of healthcare facility for transferring the patient based on geographical proximity, additional limitations which add insignificant extra-solution activity to the abstract idea by selecting a particular data source or type of data to be manipulated; claims 2-4, 6-10, 12-13 & 15-19, which recite limitations relating to a healthcare facility or generally implementing the steps in a hospital recommendation system, 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 (SME Test Step 2A, Prong 2: No).
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, add insignificant extra-solution activity to the abstract idea, and generally link the abstract idea to a particular technological environment or field of use. Additionally, the additional limitations, other than the abstract idea per se, amount to no more than limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields (such identifying, i.e. receiving data of, an event affecting a healthcare facility, identifying, i.e. receiving data of, at least one patient within the healthcare facility needing transferred due to the event, accessing a status transmission of the at least one transferee healthcare facility that is provided the at least one transferee healthcare facility, communicating with at least one other system of the healthcare facility that stores information related to the patients and pulling the information from the at least one other system, e.g., receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i); generating a recommendation for transferring the at least one patient based on recommendations for other patients needing transferred, such as by determining urgency for transferring of the one or more patients, identifying varying aspects, e.g. an event/at least one patient that will be affected by the event within the healthcare facility/a healthcare facility that can receive the patient being transferred, from received data, such as characteristics of the patient, e.g., performing repetitive calculations, Flook, MPEP 2106.05(d)(II)(ii); maintaining one or more records/statuses of patients relative to transferring of patients within the healthcare facility, e.g., electronic recordkeeping, Alice Corp., MPEP 2106.05(d)(II)(iii); storing computerized instructions/executable code for performing the steps recited, e.g., storing and retrieving information in memory, Versata Dev. Group, MPEP 2106.05(d)(II)(iv)).
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. Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 2-4, 6-10, 12-13 & 15-19, additional limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, e.g. claims 9-10 & 18-19, which recite limitations relating to receiving a status of other healthcare facilities via a status transmission, monitoring the at least one patient after being transferred, and providing notifications to the healthcare facility regarding a status of the at least one patient identified from the monitoring, e.g., receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i); claims 2-4, 6-8, 12-13, & 15-17, which recite limitations relating to initiating a transfer for the at least one patient, such as responsive to a user approving the recommendation, initiating comprises generating orders for transferring the at least one patient, identifying a transferee healthcare facility for transferring the at least one patient, identifying at least one characteristics of the patient, matching at least one characteristics to at least one healthcare facility based upon facility attributes, identifying a plurality of healthcare facility for transferring the patient based on geographical proximity, e.g., performing repetitive calculations, Flook, MPEP 2106.05(d)(II)(ii); claims 9-10 & 18-19, which recite limitations relating to receiving/maintaining a continual a status for other healthcare facilities via a status transmission, monitoring the at least one patient after transferring to another healthcare facility and providing notifications, i.e. electronic notifications, regarding the status of the patient, e.g., electronic recordkeeping, Alice Corp., MPEP 2106.05(d)(II)(iii); claims 2-4, 6-10, 12-13, & 15-19, storing computerized instructions/executable code for performing the steps recited, e.g., storing and retrieving information in memory, Versata Dev. Group, MPEP 2106.05(d)(II)(iv)). 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 (SME Test Step 2B: No).
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-4, 6-13, & 15-20 are rejected under 35 U.S.C. 103 as being unpatentable by Glidewell et al. (U.S. Patent Publication No. 2022/0132291), hereinafter “Glidewell”, in view of Forehand et al. (U.S. Patent No. 11,908,573), hereinafter “Forehand”.
Claim 1 –
Regarding Claim 1, Glidewell discloses a method, the method comprising:
identifying, by the event response recommendation system, an event affecting a healthcare facility (See Glidewell Par [0032] which discloses sensors for determining or detecting one or more events; See Glidewell Par [0063] which discloses the facility being affected by the event specifically being a long-term care facility, clinic, hospital, etc.);
identifying, using the event response recommendation system, at least one patient within the healthcare facility needing transferred due to the event (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0056] which discloses one or more LTC residents specifically being identified and assigned to one or more different or receiving LTC facilities), wherein
the identifying is at least in part based upon the event response recommendation system communicating, using at least one network device, with at least one other system of the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient and pulling the information from the at least one other system (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0056] which discloses one or more LTC residents specifically being identified and assigned to one or more different or receiving LTC facilities; Glidewell Par [0063]-[0064] also specifically discusses enabling LTC facilities to indicate openings and/or accept residents for transfer, and further includes capabilities regarding medical records associated with a transferring resident being stored and transferred from one system to another; See Glidewell Par [0101] which discloses determinations of priority (e.g. time, location, need, etc.) albeit not explicitly described as needs for the patient, per se, versus needs for a resident or user assigning a resident);
generating, by the event response recommendation system, a recommendation for transferring the at least one patient (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]), wherein
the generating a recommendation comprises identifying at least one transferee healthcare facility for the at least one patient that can receive the at least one patient and that can supply a resource needed by the at least one patient as identified from the characteristics of the patient and based upon a level of care needed by the patient (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, i.e. transferee healthcare facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0101] which discloses determinations of priority (e.g. time, location, need, etc.) albeit not explicitly described as needs for the patient, per se, versus needs for a resident or user assigning a resident), wherein
the identifying at least one transferee health facility comprises accessing a status transmission of the at least one transferee healthcare facility that is provided the at least one transferee healthcare facility, wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system, i.e. matching the one or more receiving facilities with the displacing facility, based on location; See Glidewell Par [0105] which discloses the system monitoring, on a continuous or near-continuous basis, all facility devices within the system and/or receiving/accessing a status of various aspects of the facility, such as regarding outages of the one or more facilities, thereby reading on a “status transmission of the at least one transferee healthcare facility”; however, Glidewell does not explicitly mention generating the recommendation by optimizing in view of recommendations for other patients, per se).
While Glidewell discloses transferring a patient or entity in view of an event affecting a healthcare facility, Glidewell is relatively silent on correlating resources that will be affected by the effect of the event with needs of identified patients affected by the event or optimizing the recommendation in view of recommendations for other patients as given by the following limitation:
the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient;
the identifying comprises identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility;
wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event.
However, Forehand discloses the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient (See Forehand Col. 7, ll. 40-50 which discloses customized recommendations being provided for each user regarding assigning a user to a service unit of a service facility, such that the recommendation is based on stored characteristics (e.g. special needs) of each user; See Forehand Col. 18, ll. 21 – Col. 19, ll. 12 which discloses the use of an aggregation engine and interoperability engine that stores data including rules for reading and writing data from said data stores, such that the data stored in said data stores includes a characteristic of an entity/patient, location of facility, characteristic of facility, etc.) identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility (See Forehand Col. 43, ll. 37-47 which discloses receiving data from transformative processing engine and utilizing data to generate one or more predictions regarding a user condition, a user service status, a service resource status, i.e. recommending a particular service for a user; See Forehand Col. 63, ll. 53-63 which discloses a classification for one or more users, i.e. patients, based at least in part on user data, such that the classification may be associated with a condition or service status of the user for which specialized service for the user is beneficial during an emergency, for example, a user that is disable or otherwise immobilized, or needs to be connected to an IV drip, may require assistance if needed to be transported during an event, i.e. affected by the effects of the event and therefore will need resources such as assistance; See Forehand Col. 63, ll. 64 – Col. 64, ll. 22 which discloses the specialized service may be associated with a resource for treating the user during the emergency event, such that a recommendation for providing the specialized service, i.e. correlating resources, for the user may be based at least in part on the assigned user group/classification of the user; See Forehand Col. 64, ll. 23-54 which discloses the SV system may provide recommendations for coordinating required user/special service and implementing said recommendations/services in the occurrence of a triggering; See Forehand Col. 9, ll. 50 – Col. 10, ll. 21 which discloses connecting, i.e. correlating, a specialized service in the event of an emergency with a user, i.e. patient, such as an intravenous (IV) drip, such that a recommendation for assigning specialized service for the user can be given during an emergency event (e.g. a wheelchair, a specialized service bed, a helicopter, ambulance, medication, etc.), including but not limited to an active crime situation, a natural disaster, or a service emergency) wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event (See Forehand Col. 7, ll. 40-50 which discloses recommendations being provided for each user of the user group (depending on the characteristics, e.g. special needs, of each user) and the recommendation being provided for presentation by a user device, i.e. generating the recommendation, for identifying which users are candidates for being reassigned to another service unit, i.e. the recommendation is optimized in view of each of the candidates to be reassigned). The disclosure of Forehand is directly applicable to the disclosure of Glidewell, because both disclosures share limitations and capabilities, such as being directed towards emergency preparedness and evacuation of medical facilities.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Glidewell which discloses transferring a patient or entity in view of an event affecting a healthcare facility to further specifically include identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility, as disclosed by Forehand, because this allows for a recommendation for assigning specialized service for the user can be given during an emergency event (e.g. a wheelchair, a specialized service bed, a helicopter, ambulance, medication, etc.), including but not limited to an active crime situation, a natural disaster, or a service emergency (See Forehand Col. 9, ll. 50 – Col. 10, ll. 21). It would be furthermore obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the disclosure of Glidewell regarding optimizing the recommendation in view of recommendations for other patients, because this allows for determinations of more appropriate service units earlier on in multiple user’s journeys and determining which patients require certain services and to what amount of urgency (See Forehand Col. 7, ll. 40-50 & Col. 18, ll. 21 – Col. 19, ll. 12).
Claim 2 –
Regarding Claim 2, Glidewell and Forehand disclose the method of Claim 1 in its entirety. Glidewell further discloses a method, further comprising:
initiating, using the event response recommendation system, a transfer for the at least one patient based upon the recommendation (See Glidewell Par [0074] which discloses generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]).
Claim 3 –
Regarding Claim 3, Glidewell and Forehand disclose the method of Claim 2 in its entirety. Glidewell further discloses a method, wherein:
the initiating is responsive to a user approving the recommendation (See Glidewell Par [0063] which discloses the system enabling the receiving facility, i.e. users at the receiving facility, to accept, i.e. approve, one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063], for transfer to said receiving facility).
Claim 4 –
Regarding Claim 4, Glidewell and Forehand disclose the method of Claim 2 in its entirety. Glidewell further discloses a method, wherein:
the initiating comprises generating orders for transferring the at least one patient (See Glidewell Par [0074] which discloses generating a request, i.e. interpreted as “order”, for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]).
Claim 6 –
Regarding Claim 6, Glidewell and Forehand disclose the method of Claim 1 in its entirety. Glidewell further discloses a method, wherein:
the identifying the at least one patient comprises identifying at least one characteristic of the at least one patient (See Glidewell Par [0082]-[0083] which discloses the system identifying one or more resident profiles which contain characteristics and/or information about an associated resident, e.g. including the name, age, date of birth, and/or allergies of the resident).
Claim 7 –
Regarding Claim 7, Glidewell and Forehand disclose the method of Claim 6 in its entirety. Glidewell further discloses a method, wherein:
the generating the recommendation comprises matching the at least one characteristic to at least one healthcare facility based upon attributes of the at least one healthcare facility (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system, i.e. matching the one or more receiving facilities with the displacing facility, based on location; See further Glidewell Par [0074] which separately mentions a characteristic of bed types or facility types, such as male beds, female beds, life support system equipped beds, dementia ward beds, ICU beds, which is understood to constitute a characteristic of both the facility the bed is in, and the bed itself).
Claim 8 –
Regarding Claim 8, Glidewell and Forehand disclose the method of Claim 1 in its entirety. Glidewell further discloses a method, wherein:
the generating a recommendation comprises identifying a plurality of healthcare facilities for transferring the at least one patient (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system) and wherein
the recommendation comprises one of the plurality of healthcare facilities located in closest geographical proximity to the healthcare facility (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system).
Claim 9 –
Regarding Claim 9, Glidewell and Forehand disclose the method of Claim 1 in its entirety. Glidewell further discloses a method, wherein:
the generating a recommendation comprises receiving, at the event response recommendation system, a status of other healthcare facilities via the status transmission (See Glidewell Par [0007] which discloses managing a patient population for a disaster or other event, from one or more displacing facilities to a receiving facility, such as soliciting an indication of number of unoccupied beds, i.e. interpreted as a “status”, associated with each of the one or more receiving facilities; See Glidewell Par [0105] which discloses monitoring, on a continuous or near-continuous basis, all facility devices and/or user devices within the system such that a health check report may be sent to a facility on a periodic that indicates the status of the one or more devices).
Claim 10 –
Regarding Claim 10, Glidewell and Forehand disclose the method of Claim 1 in its entirety. Glidewell further discloses a method, further comprising:
monitoring, using the event response recommendation system, the at least one patient after the at least one patient is transferred to another healthcare facility (See Glidewell Par [0056] which discloses tracking and managing a location of one or more individuals associated with a LTC facility such that the system manages the relocation of LTC residents during an emergency and/or natural disaster and assigning the individuals to receiving, i.e. second LTC, facility; See Glidewell Par [0030] which discloses uninterrupted access to electronic medical records, such that medical records associated with the one or more LTC residents can still be maintained or continually charted; See Glidewell Par [0087] which discloses EMR associated with the one or more residents being displayed, and particularly displaying live, up-to-date medical records) and providing notifications to the healthcare facility regarding a status of the at least one patient identified from the monitoring (See Glidewell Par [0030] which discloses uninterrupted access to electronic medical records, such that medical records associated with the one or more LTC residents can still be maintained or continually charted; See Glidewell Par [0099] which discloses notifying a user of an update of one or more resident profiles, which as disclosed in Glidewell Par [0087] resident profile may contain EMR associated with the one or more residents and the EMR displayed, and particularly displaying live, up-to-date medical records, thereby constituting when an EMR is updated, one or more users, such as at the displacing or receiving facility may receive a notification).
Claim 11 –
Regarding Claim 11, Glidewell discloses a system, the system comprising:
a processor (See Glidewell Par [0037]-[0038] which discloses one or more processing circuits or processors for performing the methods recited throughout Glidewell);
a memory device that stores instructions that, when executed by the processor, causes the system to (See Glidewell Par [0039] which discloses one or more memories coupled to a processor via processing circuit for executing computer code):
identify, at an event response recommendation system, an event affecting a healthcare facility (See Glidewell Par [0032] which discloses sensors for determining or detecting one or more events; See Glidewell Par [0063] which discloses the facility being affected by the event specifically being a long-term care facility, clinic, hospital, etc.);
identify, by the event response recommendation system, at least one patient within the healthcare facility needing transferred due to the event (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0056] which discloses one or more LTC residents specifically being identified and assigned to one or more different or receiving LTC facilities), wherein
the identifying is at least in part based upon the event response recommendation system communicating, using at least one network device, with at least one other system of the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient and pulling the information from the at least one other system (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0056] which discloses one or more LTC residents specifically being identified and assigned to one or more different or receiving LTC facilities; Glidewell Par [0063]-[0064] also specifically discusses enabling LTC facilities to indicate openings and/or accept residents for transfer, and further includes capabilities regarding medical records associated with a transferring resident being stored and transferred from one system to another; See Glidewell Par [0101] which discloses determinations of priority (e.g. time, location, need, etc.) albeit not explicitly described as needs for the patient, per se, versus needs for a resident or user assigning a resident); and
generate, using the event response recommendation system, a recommendation for transferring the at least one patient (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]), wherein
the generating a recommendation comprises identifying at least one transferee healthcare facility for the at least one patient that can supply a resource needed by the at least one patient that can receive the at least one patient (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, i.e. transferee healthcare facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0101] which discloses determinations of priority (e.g. time, location, need, etc.) albeit not explicitly described as needs for the patient, per se, versus needs for a resident or user assigning a resident), wherein
the identifying the at least one transferee healthcare facility comprises accessing a status transmission of the at least one transferee healthcare facility that is provided the at least one transferee healthcare facility, wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system, i.e. matching the one or more receiving facilities with the displacing facility, based on location; See Glidewell Par [0105] which discloses the system monitoring, on a continuous or near-continuous basis, all facility devices within the system and/or receiving/accessing a status of various aspects of the facility, such as regarding outages of the one or more facilities, thereby reading on a “status transmission of the at least one transferee healthcare facility”; however, Glidewell does not explicitly mention generating the recommendation by optimizing in view of recommendations for other patients, per se).
While Glidewell discloses transferring a patient or entity in view of an event affecting a healthcare facility, Glidewell is relatively silent on correlating resources that will be affected by the effect of the event with needs of identified patients affected by the event or optimizing the recommendation in view of recommendations for other patients as given by the following limitation:
the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient;
the identifying comprises identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility;
wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event.
However, Forehand discloses the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient (See Forehand Col. 7, ll. 40-50 which discloses customized recommendations being provided for each user regarding assigning a user to a service unit of a service facility, such that the recommendation is based on stored characteristics (e.g. special needs) of each user; See Forehand Col. 18, ll. 21 – Col. 19, ll. 12 which discloses the use of an aggregation engine and interoperability engine that stores data including rules for reading and writing data from said data stores, such that the data stored in said data stores includes a characteristic of an entity/patient, location of facility, characteristic of facility, etc.) identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility (See Forehand Col. 43, ll. 37-47 which discloses receiving data from transformative processing engine and utilizing data to generate one or more predictions regarding a user condition, a user service status, a service resource status, i.e. recommending a particular service for a user; See Forehand Col. 63, ll. 53-63 which discloses a classification for one or more users, i.e. patients, based at least in part on user data, such that the classification may be associated with a condition or service status of the user for which specialized service for the user is beneficial during an emergency, for example, a user that is disable or otherwise immobilized, or needs to be connected to an IV drip, may require assistance if needed to be transported during an event, i.e. affected by the effects of the event and therefore will need resources such as assistance; See Forehand Col. 63, ll. 64 – Col. 64, ll. 22 which discloses the specialized service may be associated with a resource for treating the user during the emergency event, such that a recommendation for providing the specialized service, i.e. correlating resources, for the user may be based at least in part on the assigned user group/classification of the user; See Forehand Col. 64, ll. 23-54 which discloses the SV system may provide recommendations for coordinating required user/special service and implementing said recommendations/services in the occurrence of a triggering; See Forehand Col. 9, ll. 50 – Col. 10, ll. 21 which discloses connecting, i.e. correlating, a specialized service in the event of an emergency with a user, i.e. patient, such as an intravenous (IV) drip, such that a recommendation for assigning specialized service for the user can be given during an emergency event (e.g. a wheelchair, a specialized service bed, a helicopter, ambulance, medication, etc.), including but not limited to an active crime situation, a natural disaster, or a service emergency) wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event (See Forehand Col. 7, ll. 40-50 which discloses recommendations being provided for each user of the user group (depending on the characteristics, e.g. special needs, of each user) and the recommendation being provided for presentation by a user device, i.e. generating the recommendation, for identifying which users are candidates for being reassigned to another service unit, i.e. the recommendation is optimized in view of each of the candidates to be reassigned).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Glidewell which discloses transferring a patient or entity in view of an event affecting a healthcare facility to further specifically include identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility, as disclosed by Forehand, because this allows for a recommendation for assigning specialized service for the user can be given during an emergency event (e.g. a wheelchair, a specialized service bed, a helicopter, ambulance, medication, etc.), including but not limited to an active crime situation, a natural disaster, or a service emergency (See Forehand Col. 9, ll. 50 – Col. 10, ll. 21). It would be furthermore obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the disclosure of Glidewell regarding optimizing the recommendation in view of recommendations for other patients, because this allows for determinations of more appropriate service units earlier on in multiple user’s journeys and determining which patients require certain services and to what amount of urgency (See Forehand Col. 7, ll. 40-50 & Col. 18, ll. 21 – Col. 19, ll. 12).
Claim 12 –
Regarding Claim 12, Glidewell and Forehand disclose the system of Claim 11 in its entirety. Glidewell further discloses a system, further comprising:
initiating, using the event response recommendation system, a transfer for the at least one patient based upon the recommendation (See Glidewell Par [0074] which discloses generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]).
Claim 13 –
Regarding Claim 13, Glidewell and Forehand disclose the system of Claim 12 in its entirety. Glidewell further discloses a system, wherein:
the initiating is responsive to a user approving the recommendation (See Glidewell Par [0063] which discloses the system enabling the receiving facility, i.e. users at the receiving facility, to accept, i.e. approve, one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063], for transfer to said receiving facility).
Claim 15 –
Regarding Claim 15, Glidewell and Forehand disclose the system of Claim 11 in its entirety. Glidewell further discloses a system, wherein:
the identifying the at least one patient comprises identifying at least one characteristic of the at least one patient (See Glidewell Par [0082]-[0083] which discloses the system identifying one or more resident profiles which contain characteristics and/or information about an associated resident, e.g. including the name, age, date of birth, and/or allergies of the resident).
Claim 16 –
Regarding Claim 16, Glidewell and Forehand disclose the system of Claim 15 in its entirety. Glidewell further discloses a system, wherein:
the generating the recommendation comprises matching the at least one characteristic to at least one healthcare facility based upon attributes of the at least one healthcare facility (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system, i.e. matching the one or more receiving facilities with the displacing facility, based on location; See further Glidewell Par [0074] which separately mentions a characteristic of bed types or facility types, such as male beds, female beds, life support system equipped beds, dementia ward beds, ICU beds, which is understood to constitute a characteristic of both the facility the bed is in, and the bed itself).
Claim 17 –
Regarding Claim 17, Glidewell and Forehand disclose the system of Claim 11 in its entirety. Glidewell further discloses a system, wherein:
the generating a recommendation comprises identifying a plurality of healthcare facilities for transferring the at least one patient See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system) and wherein
the recommendation comprises one of the plurality of healthcare facilities located in closest geographical proximity to the healthcare facility (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system).
Claim 18 –
Regarding Claim 18, Glidewell and Forehand disclose the system of Claim 11 in its entirety. Glidewell further discloses a system, wherein:
the generating a recommendation comprises receiving, at the event response recommendation system, a status of other healthcare facilities via the status transmission (See Glidewell Par [0007] which discloses managing a patient population for a disaster or other event, from one or more displacing facilities to a receiving facility, such as soliciting an indication of number of unoccupied beds, i.e. interpreted as a “status”, associated with each of the one or more receiving facilities; See Glidewell Par [0105] which discloses monitoring, on a continuous or near-continuous basis, all facility devices and/or user devices within the system such that a health check report may be sent to a facility on a periodic that indicates the status of the one or more devices).
Claim 19 –
Regarding Claim 19, Glidewell and Forehand disclose the system of Claim 11 in its entirety. Glidewell further discloses a system, further comprising:
monitoring, using the event response recommendation system, the at least one patient after the at least one patient is transferred to another healthcare facility (See Glidewell Par [0056] which discloses tracking and managing a location of one or more individuals associated with a LTC facility such that the system manages the relocation of LTC residents during an emergency and/or natural disaster and assigning the individuals to receiving, i.e. second LTC, facility; See Glidewell Par [0030] which discloses uninterrupted access to electronic medical records, such that medical records associated with the one or more LTC residents can still be maintained or continually charted; See Glidewell Par [0087] which discloses EMR associated with the one or more residents being displayed, and particularly displaying live, up-to-date medical records) and providing notifications to the healthcare facility regarding a status of the at least one patient identified from the monitoring (See Glidewell Par [0030] which discloses uninterrupted access to electronic medical records, such that medical records associated with the one or more LTC residents can still be maintained or continually charted; See Glidewell Par [0099] which discloses notifying a user of an update of one or more resident profiles, which as disclosed in Glidewell Par [0087] resident profile may contain EMR associated with the one or more residents and the EMR displayed, and particularly displaying live, up-to-date medical records, thereby constituting when an EMR is updated, one or more users, such as at the displacing or receiving facility may receive a notification).
Claim 20 –
Regarding Claim 20, Glidewell discloses a product, the product comprising:
a computer-readable storage device that stores executable code that, when executed by a processor, causes the product to (See Glidewell Par [0039] which discloses one or more memories coupled to a processor via processing circuit for executing computer code; See Glidewell Par [0111] which discloses a memory device in the form of a non-transitory storage media for storing code):
identify, at an event response recommendation system, an event affecting a healthcare facility (See Glidewell Par [0032] which discloses sensors for determining or detecting one or more events; See Glidewell Par [0063] which discloses the facility being affected by the event specifically being a long-term care facility, clinic, hospital, etc.);
identify, by the event response recommendation system, at least one patient within the healthcare facility needing transferred due to the event (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0056] which discloses one or more LTC residents specifically being identified and assigned to one or more different or receiving LTC facilities), wherein
the identifying is at least in part based upon the event response recommendation system communicating, using at least one network device, with at least one other system of the healthcare facility that stores information related to the patients that identifies characteristics fo the patient indicating a need of the patient and pulling the information from the at least one other system (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0056] which discloses one or more LTC residents specifically being identified and assigned to one or more different or receiving LTC facilities; Glidewell Par [0063]-[0064] also specifically discusses enabling LTC facilities to indicate openings and/or accept residents for transfer, and further includes capabilities regarding medical records associated with a transferring resident being stored and transferred from one system to another; See Glidewell Par [0101] which discloses determinations of priority (e.g. time, location, need, etc.) albeit not explicitly described as needs for the patient, per se, versus needs for a resident or user assigning a resident);
generate, by the event response recommendation system, a recommendation for transferring the at least one patient (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]), wherein
the generating a recommendation comprises identifying at least one transferee healthcare facility for the at least one patient that can receive the at least one patient and that can supply a resource needed by the at least one patient as identified from the characteristics of the patient and based upon a level of care needed by the patient (See Glidewell Par [0074] which discloses the system generating a request for an indication of a number of available beds from one or more receiving facilities for a displacing facility, i.e. transferee healthcare facility, such as for transferring one or more residents of an LTC facility, hospital, etc., as seen in Glidewell Par [0063]; See Glidewell Par [0101] which discloses determinations of priority (e.g. time, location, need, etc.) albeit not explicitly described as needs for the patient, per se, versus needs for a resident or user assigning a resident), wherein
the identifying the at least one transferee healthcare facility comprises accessing a status transmission of the least one transferee healthcare facility that is provided the at least one transferee healthcare facility, wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event (See Glidewell Par [0007] which discloses soliciting, from one or more receiving facilities, an indication of a number of unoccupied beds associated with the one or more receiving facilities; See Glidewell Par [0006] & [0073] which discloses the system specifically determining and displaying beds, i.e. at one or more facilities, within a threshold distance of the displaying system, i.e. matching the one or more receiving facilities with the displacing facility, based on location; See Glidewell Par [0105] which discloses the system monitoring, on a continuous or near-continuous basis, all facility devices within the system and/or receiving/accessing a status of various aspects of the facility, such as regarding outages of the one or more facilities, thereby reading on a “status transmission of the at least one transferee healthcare facility”; however, Glidewell does not explicitly mention generating the recommendation by optimizing in view of recommendations for other patients, per se).
While Glidewell discloses transferring a patient or entity in view of an event affecting a healthcare facility, Glidewell is relatively silent on correlating resources that will be affected by the effect of the event with needs of identified patients affected by the event or optimizing the recommendation in view of recommendations for other patients as given by the following limitation:
the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient;
the identifying comprises identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility;
wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event.
However, Forehand discloses the healthcare facility that stores information related to the patients that identifies characteristics of the patient indicating a need of the patient (See Forehand Col. 7, ll. 40-50 which discloses customized recommendations being provided for each user regarding assigning a user to a service unit of a service facility, such that the recommendation is based on stored characteristics (e.g. special needs) of each user; See Forehand Col. 18, ll. 21 – Col. 19, ll. 12 which discloses the use of an aggregation engine and interoperability engine that stores data including rules for reading and writing data from said data stores, such that the data stored in said data stores includes a characteristic of an entity/patient, location of facility, characteristic of facility, etc.) identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility (See Forehand Col. 43, ll. 37-47 which discloses receiving data from transformative processing engine and utilizing data to generate one or more predictions regarding a user condition, a user service status, a service resource status, i.e. recommending a particular service for a user; See Forehand Col. 63, ll. 53-63 which discloses a classification for one or more users, i.e. patients, based at least in part on user data, such that the classification may be associated with a condition or service status of the user for which specialized service for the user is beneficial during an emergency, for example, a user that is disable or otherwise immobilized, or needs to be connected to an IV drip, may require assistance if needed to be transported during an event, i.e. affected by the effects of the event and therefore will need resources such as assistance; See Forehand Col. 63, ll. 64 – Col. 64, ll. 22 which discloses the specialized service may be associated with a resource for treating the user during the emergency event, such that a recommendation for providing the specialized service, i.e. correlating resources, for the user may be based at least in part on the assigned user group/classification of the user; See Forehand Col. 64, ll. 23-54 which discloses the SV system may provide recommendations for coordinating required user/special service and implementing said recommendations/services in the occurrence of a triggering; See Forehand Col. 9, ll. 50 – Col. 10, ll. 21 which discloses connecting, i.e. correlating, a specialized service in the event of an emergency with a user, i.e. patient, such as an intravenous (IV) drip, such that a recommendation for assigning specialized service for the user can be given during an emergency event (e.g. a wheelchair, a specialized service bed, a helicopter, ambulance, medication, etc.), including but not limited to an active crime situation, a natural disaster, or a service emergency) wherein the generating of the recommendation comprises optimizing the recommendation in view of recommendations for other patients needing transferred due to the event (See Forehand Col. 7, ll. 40-50 which discloses recommendations being provided for each user of the user group (depending on the characteristics, e.g. special needs, of each user) and the recommendation being provided for presentation by a user device, i.e. generating the recommendation, for identifying which users are candidates for being reassigned to another service unit, i.e. the recommendation is optimized in view of each of the candidates to be reassigned).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Glidewell which discloses transferring a patient or entity in view of an event affecting a healthcare facility to further specifically include identifying patients within the healthcare facility that will be affected by effects of the event by correlating resources of the healthcare facility that will be affected by the effect of the event with needs of the patients within the healthcare facility, as disclosed by Forehand, because this allows for a recommendation for assigning specialized service for the user can be given during an emergency event (e.g. a wheelchair, a specialized service bed, a helicopter, ambulance, medication, etc.), including but not limited to an active crime situation, a natural disaster, or a service emergency (See Forehand Col. 9, ll. 50 – Col. 10, ll. 21). It would be furthermore obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the disclosure of Glidewell regarding optimizing the recommendation in view of recommendations for other patients, because this allows for determinations of more appropriate service units earlier on in multiple user’s journeys and determining which patients require certain services and to what amount of urgency (See Forehand Col. 7, ll. 40-50 & Col. 18, ll. 21 – Col. 19, ll. 12).
Response to Arguments
Applicant's arguments filed 17 February 2026 have been fully considered but they are not persuasive:
Regarding 35 U.S.C. 101 rejections of claims 1-20, Applicant argues on p. 8-11 of Arguments/Remarks that the claims are not directed to a judicial exception, particularly methods of organizing human activity, because the claims are not directed toward “managing personal behavior or interactions between people”. Rather, the claims “are directed toward a system for transferring patients from a healthcare facility experiencing an event to another healthcare facility”, and therefore do not constitute efforts of “managing personal behavior or interactions between people”. Examiner respectfully disagrees with Applicant’s arguments. Identifying one or more patients that need to be transferred to a different location because of the event, and producing a recommendation for transferring the patient, including determination of resources needed for transferring the patient to another facility, as drafted, under the broadest reasonable interpretation, includes methods of organizing human activity. MPEP 2106.04(a)(2)(II) defines certain methods of organizing human activity, including fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations), and/or managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions). The steps recited above include aspects of managing personal behavior or interactions between people. In particular, the system effectively generates rules and/or recommendations for a healthcare facility or entities within the healthcare facility to follow regarding transferring one patient in response to one or more events, including provision of resources for said patient, based upon certain patient attributes. Therefore, by aspects of rule-following or policy-following for the one or more healthcare facility entities, the system effectively manages human behavior or interactions between people. At a much broader level, “a system for transferring patients from a healthcare facility experiencing an event to another healthcare facility” is inherently a system that is directed towards organization of a human activity. That is, transferring a patient, i.e. human, from one location to another is a human activity. Further, efforts to generate recommendations for said transferring of a human is effectively efforts of organization of said human activity. Therefore, at least by aspects of simply moving a patient from one healthcare facility to another, the system is effectively directed towards organizing a “human activity”. As such, pending claims 1-4, 6-13, & 15-20 remain rejected under 35 U.S.C. 101.
Regarding 35 U.S.C. 101 rejections of claims 1-20, Applicant argues on p. 11-12 of Arguments/Remarks that the claims are not directed to a judicial exception, particularly a mental process. Rather, the claims “require the use of event response recommendations system to actually perform the steps… this system has specific computing components that are not mental components” and therefore could not represent a mental process. Examiner respectfully disagrees with Applicant’s arguments. Examiner points to MPEP 2106.04(a)(2)(III)(C) which states that a claim that requires a computer may still recite a mental process if the mental process is merely being performed on a generic computer, computer environment, or the computer is being used as a tool to perform a mental process. Applicant’s own arguments regarding “the use of event response recommendations system to perform the steps” reads as efforts to merely apply a generic computer system that is coded or programmed for performance of the steps recited. That is, the steps recited of identifying one or more patients that need to be transferred to a different location because of the event, and producing a recommendation for transferring the patient, including determination of resources needed for transferring the patient to another facility all amount to steps that can reasonably be performed in the human mind, but for mere recitation or application of a generic computer system. Therefore, in view of MPEP 2106.04(a)(2)(III)(C), the claim effectively still constitutes a mental process, under BRI, even though various computing components are recited. As such, pending claims 1-4, 6-13, & 15-20 remain rejected under 35 U.S.C. 101.
Regarding 35 U.S.C. 101 rejections of claims 1-20, Applicant argues on p. 12-16 of Arguments/Remarks that even if the claims recite a judicial exception, any recited judicial exception is integrated a practical application, i.e. an application of transferring patients from a healthcare facility affected by an event to another healthcare facility. Applicant also argues that the claims improve the relevant existing technology by “transferring of patients from healthcare facilities based upon events and correlations between the resources needed by the patients and those affected by an event” because conventional techniques rely on manual steps, which is inefficient and inaccurate. Applicant further argues in view of the claims specifying how the system is actually able to identify the patient for transfer and how the system determines to which transferee healthcare facility the patient should be transferred amounting to an improvement to existing systems. Examiner respectfully disagrees with Applicant’s arguments. While Examiner is not arguing against Applicant’s assertion that the claims are directed towards “an application of transferring patients from a healthcare facility affected by an event to another healthcare facility”, Examiner does argue that this does not constitute a “practical application” as defined by the Alice/Mayo framework. That is, a practical application is defined in MPEP 2106.04(d)(I) as an improvement in the functioning of a computer, or an improvement to other technology or technical field, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a); applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, as discussed in MPEP § 2106.04(d)(2); implementing a judicial exception with, or using a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, as discussed in MPEP § 2106.05(b); effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP § 2106.05(c); and/or applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception, as discussed in MPEP § 2106.05(e). And instead, efforts of merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f); adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g); and generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h) typically do not integrate a judicial exception into a practical application. Therefore, the claims being directed towards “an application of transferring patients from a healthcare facility affected by an event to another healthcare facility” merely reads as generally linking the use of a judicial exception to a particular technological environment or field of use. That is, the abstract idea of identifying one or more entities that need to be transferred to a different location because of an event, producing a recommendation for transferring the entity, and determining resources needed for transferring the patient to another facility to be successful is being generally linked to the field of healthcare and patient admission, discharge, and transfer (ADT). Furthermore, well Applicant argues that “transferring of patients from healthcare facilities based upon events and correlations between the resources needed by the patients and those affected by an event” results in an improvement of relevant existing technology, this seems to read as efforts to improve the already-identified abstraction(s) at hand. That is, improving efforts of transferring patients from healthcare facilities and correlation of resources does not represent an improvement to the technological components that are performing those efforts. Instead, this would reflect an improvement to the already-characterized abstraction(s), which would still represent an abstract idea, under broadest reasonable interpretation. Additionally, MPEP 2106.05(a)(I) states that “mere automation of manual processes”, such as to merely solve human inefficiency or inaccuracy, does not necessarily reflect an improvement in computer-functionality. Therefore, these efforts do not seem to achieve or wholly represent any of the enumerated “practical applications” found in MPEP 2106.04(d)(I). While Applicant further argues in view of the claims specifying how the system is actually able to identify the patient for transfer and how the system determines to which transferee healthcare facility the patient should be transferred amounting to an improvement to existing systems, Examiner points to existing systems supporting or having substantially similar aspects of identifying patients for transfer and which facilities will accept said transfers. Therefore, said aspects do not amount to an improvement on prior art systems As such, the claims do not seem to represent a practical application of the recited judicial exceptions, and therefore, pending claims 1-4, 6-13, & 15-20 remain rejected under 35 U.S.C. 101.
Regarding 35 U.S.C. 101 rejections of claims 1-20, Applicant argues on p. 16-20 of Arguments/Remarks that the claims represent an inventive concept, as the claims when analyzed in combination and as a whole, adds a specific limitation or combination of limitations that are not well-understood, routine, and/or conventional without further substantiation. Examiner respectfully disagrees with Applicant’s arguments. As reasoned above in the “Claim Rejections – 35 U.S.C. 101” section of this Office Action, each of the claims and steps recited therein were determined to represent well-understood, routine, and/or conventional activity as identified by the MPEP and/or prior art systems. Furthermore, while Applicant argues against prior art systems as such, the claims do not seem to represent a practical application or significantly more than the recited judicial exceptions, and therefore, pending claims 1-4, 6-13, & 15-20 remain rejected under 35 U.S.C. 101.
Regarding 35 U.S.C. 103 rejections of claims 1-20, Applicant argues on p. 20-22 of Arguments/Remarks that the Office has not articulated a reason why a person skilled in the art would combine the prior art references. More specifically, Applicant’s argues that the teachings of Glidewell are largely independent of any automatic identification of patients that need to be transferred, whereas Forehand addresses a different problem altogether, namely the coordinate of services for a user assigned to a service unit of a service facility. Examiner respectfully disagrees with Applicant’s arguments. A motivation state combining the references was provided by Examiner regarding Glidewell and Forehand, i.e. “the disclosure of Forehand is directly applicable to the disclosure of Glidewell, because both disclosures share limitations and capabilities, such as being directed towards emergency preparedness and evacuation of medical facilities.” That is, while Forehand may be directed moreso towards emergency preparedness on a provider/nurse/medical personnel level, and Glidewell is moreso directed towards emergency preparedness on a patient level, both disclosures relate to emergency preparedness for one or more medical facilities and one or more entities residing in said medical facilities. That is, the disclosures substantially relate to each other. Therefore, claims 1, 11, & 20 are effectively met by Glidewell and Forehand as reasoned above in the “Claim Rejections – 35 U.S.C. 103” section of this Office Action. As such, pending claims 1-4, 6-13, & 15-20 remain rejected under 35 U.S.C. 103.
Regarding 35 U.S.C. 103 rejections of claims 1-20, Applicant argues on p. 22-25 of Arguments/Remarks that the amendments to independent claims 1, 11, & 20 overcome previous 35 U.S.C. 103 rejections made in view of Glidewell in view of Forehand, because Glidewell and Forehand do not effectively disclose the newly amended limitations found in independent claims 1, 11, & 20 and therefore overcome previous 35 U.S.C. 103 rejections. Examiner agrees with Applicant’s arguments. Therefore, the rejections have been withdrawn. However, a new ground of rejection is made under 35 U.S.C. 103 over newly cited/reasoned portions of Glidewell in view of Forehand for claims 1, 11, & 20. This new ground of rejection relies on newly cited/reasoned portions of Glidewell (i.e. Glidewell Par [0101] which discloses determinations of priority (e.g. time, location, need, etc.) albeit not explicitly described as needs for the patient, per se, versus needs for a resident or user assigning a resident) and newly cited portions of Forehand (See Forehand Col. 7, ll. 40-50 which discloses customized recommendations being provided for each user regarding assigning a user to a service unit of a service facility, such that the recommendation is based on stored characteristics (e.g. special needs) of each user; See Forehand Col. 18, ll. 21 – Col. 19, ll. 12 which discloses the use of an aggregation engine and interoperability engine that stores data including rules for reading and writing data from said data stores, such that the data stored in said data stores includes a characteristic of an entity/patient, location of facility, characteristic of facility, etc.) to specifically read on the newly amended limitations found in independent claims 1, 11, & 20. While Applicant additionally argues in view of Glidewell not disclosing “identifying, by the event response recommendation system, at least one patient within the healthcare facility needing transferred due to the event, and generating using the event response recommendation system, a recommendation for transferring the at least one patient”, Examiner respectfully disagrees with this particular limitation not being disclosed by Glidewell. While Applicant argues that Glidewell does not disclose this limitation because the actual selection of patients to be transferred to a receiving facility is performed manually by a user, Examiner contends that nothing in the above-mentioned claim limitation requires this aspect to be automated by the system itself. While Applicant may be referring to the “by the event response recommendation system” language, this does not necessarily entail the event response recommendation system performing/automating the actual limitation recited. Rather, a user can use the event response recommendation system or perform actions “by” said system to select patients to be transferred to a receiving facility and this would also constitute “by the event response recommendation system” as required by the limitation. While the system claim (claim 11) and product claim (claim 20) do make mention of a memory device storing instructions that performs said actions, this could also simply include the interpretation of performing computerized instructions that are required when the event response recommendation system is being used by a user, i.e. performing the system performing instructions when used by the user to allow the user to perform selection of patients to be transferred to a receiving facility. Furthermore, assuming arguendo that the “by the event response recommendation system” language does necessarily entail the event response recommendation system performing/automating the limitation recited, Glidewell Par [0064] specifically states that the resident displacement manager of Par [0056] & [0063] simplifies the resident transfer process by automating many tasks associated with transfer and improving the transfer process, such as regarding available beds and transfer of residents, e.g. identification of residents to be transferred. Therefore, while not currently required by the current claim language, as explained above, it is understood that Glidewell would more than likely also read on the system itself automatically performing selection of patients to be transferred to a receiving facility. If Applicant intends to preclude said aspects of a person manually using a system to perform said aspects, then explicit processing means may need to be actively recited as performing the limitations versus allowing use of or performance by a system such as by control from a user. Therefore, claims 1, 11, & 20 are effectively met by newly cited portions of Glidewell and Forehand as reasoned above in the “Claim Rejections – 35 U.S.C. 103” section of this Office Action. As such, pending claims 1-4, 6-13, & 15-20 remain rejected under 35 U.S.C. 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
IQ.com (NPL – “Blockchain Enhanced Record Tracking for Hospital Evacuation” – April 2021) discloses a system that provides secure access and patient-data consistency across an evacuation cycle’s multiple stages (e.g., shelter check-on, transportation check-in, hospital repopulation, etc.) and further managing patient records through various stages of the hospital evacuation/re-evacuation cycles;
Zak et al. (U.S. Patent Publication No. 2025/0046436) discloses a system for optimizing human resource management within emergency medical services;
Rosow et al. (U.S. Patent Publication No. 2003/0074222) discloses a bed management system that interfaces with ADT systems for an easy-to-use business intelligence application that is designed to allow administrators, clinicians and managers to easily access, analyze and display real-time patient and bed availability information from ancillary information systems, databases and spreadsheets.
Applicant's amendment necessitated the new ground of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUNTER J RASNIC whose telephone number is (571)270-5801. The examiner can normally be reached M-F 8am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shahid Merchant can be reached on (571) 270-1360. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.R./Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights