DETAILED CORRESPONDENCE
This is a non-final office action on merits in response to the arguments and/or amendments filed on 03/18/2026 and the request for continued examination filed on 03/18/2026.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of claims
Claims 1-88 are cancelled. Claims 89-108 are new. Claims 89-108 are pending and considered below.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/18/2026 has been entered.
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 89-108 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 89-100 are drawn to a method, claims 101-107 are drawn to a network server, and claim 108 is drawn to at least one non-transitory processor-readable storage medium. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claim 89 recites the limitations of monitoring over time, communication to and from the communication device, wherein the monitoring includes, (ii) monitoring, response time for the communication device responding to the communications; detecting, based on the monitoring over time of the communication to and from the communication device, a trending increase in response time for the communication device responding to communications sent to the communication device; and determining that a plurality of overload factors, including the trending increase in response time for the communication device responding to the communications sent to the communication device, meets an overload condition. These limitations, as drafted, are processes that, under their broadest reasonable interpretations, cover performance of the limitations in the mind or by using a pen and paper. Even when considering the “by the network server” language, the claim encompasses a user observing communications and response times, evaluating whether response times are trending upward, and determining whether the observed information indicates an overload condition in their mind or by using a pen and paper. The mere nominal recitation of by the network server does not take the claim limitation out of the mental processes grouping. Thus, the claim recites a mental process which is an abstract idea.
Independent claims 101 and 108 recite identical or nearly identical steps with respect to claim 89 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and these claims are therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per claim 89, include:
monitoring over time, by a network server remote from the communication device, communication to and from the communication device, wherein the monitoring includes (i) receiving, at a processor of the network server, a plurality of generated communications destined to the communication device, and (ii) monitoring, by the network server, response time for the communication device responding to the communications;
detecting by the network server, based on the monitoring over time of the communication to and from the communication device, a trending increase in response time for the communication device responding to communications sent to the communication device;
based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device, reducing, by the network server, a frequency of transmission of further communications to the communication device,
wherein reducing by the network server the frequency of transmission of further communications to the communication device based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device includes executing by the network server a trained machine- learning model to determine that a plurality of overload factors, including the trending increase in response time for the communication device responding to the communications sent to the communication device, meets an overload condition, wherein the reducing of the frequency of transmission of further communications to the communication device is based on the network server determining that the plurality of overload factors meets the overload condition.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claim 89 is not integrated into a practical application. The claim further recites the additional elements: i) receiving a plurality of generated communications destined to the communication device; by a network server remote from the communication device, a processor of the network server, by the network server, and executing by the network server a trained machine- learning model; and based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device, reducing, by the network server, a frequency of transmission of further communications to the communication device, wherein reducing by the network server the frequency of transmission of further communications to the communication device based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device includes, wherein the reducing of the frequency of transmission of further communications to the communication device is based on the network server determining that the plurality of overload factors meets the overload condition. The limitation of i) receiving a plurality of generated communications destined to the communication device is recited at a high level of generality (i.e., as a general means of collecting or receiving information for use in the abstract idea), and amounts to mere data gathering, which constitutes insignificant extra-solution activity. The limitations of by a network server remote from the communication device, a processor of the network server, by the network server, and executing by the network server a trained machine- learning model merely applies the abstract idea using generic computer components performing their ordinary functions of monitoring communications, executing software instructions, analyzing information, and producing a determination. Further, the limitations of based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device, reducing, by the network server, a frequency of transmission of further communications to the communication device, wherein reducing by the network server the frequency of transmission of further communications to the communication device based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device includes, wherein the reducing of the frequency of transmission of further communications to the communication device is based on the network server determining that the plurality of overload factors meets the overload condition merely recites the desired result of reducing the frequency of future communications in response to determining that an overload condition exists, without reciting any particular technological mechanism for achieving that result or any improvement to computer or communication network technology. Accordingly, these additional elements amount to no more than instructions to apply the abstract idea using generic computer components, and individually and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 89 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A Prong Two, the additional elements comprise generic computing components (i.e., by a network server remote from the communication device, a processor of the network server, by the network server, and executing by the network server a trained machine- learning model) performing well-understood functions of monitoring communications, executing software instructions, analyzing information, and producing a determination. Also noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely collecting information for analysis without a technological improvement does not add significantly more to an abstract idea. The use of the method is no more than collecting information before evaluating the information to determine whether an overload condition exist and does not integrate the abstract idea into a practical application. Additionally, the limitations of based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device, reducing, by the network server, a frequency of transmission of further communications to the communication device, wherein reducing by the network server the frequency of transmission of further communications to the communication device based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device includes, wherein the reducing of the frequency of transmission of further communications to the communication device is based on the network server determining that the plurality of overload factors meets the overload condition merely implement the results of the abstract idea and recites only the desired outcome of reducing the frequency of future communications after determining that an overload condition exists without specifying any particular technological manner or improvement for accomplishing that result. Thus, the claim merely applies the abstract idea using generic computer technology and is drafted in a result-oriented manner that effectively covers any mechanism capable of performing the claimed limitation. Viewed individually and as an ordered combination, the additional elements do not provide an inventive concept sufficient to transform the judicial exception into patent eligible subject matter because they amount to no more than instructions to implement the abstract idea on generic computer components. See Alice Corp. v. CLS Bank Int'l, 573 U.S. 208 (2014); Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016); Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017). The claim is not patent eligible.
Claims 90-94, 103-105, recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above.
Claims 95-100, 102, and 106-107 recite the additional elements of wherein reducing the frequency of transmission of further communications to the communication device comprises reducing a frequency of generation of further communications to be sent to the communication device (claims 95 and 102), wherein reducing the frequency of transmission of further communications to the communication device comprises causing an entity that generates at least some of the communications to reduce frequency of generation of the communications (claim 96), by the network server (claim 97), by the network server the trained machine-learning model (claims 98 and 107), wherein reducing the frequency of transmission of further communications to the communication device comprises reducing to zero the frequency of transmission of further communications to the communication device (claim 99), wherein reducing the frequency of transmission of further communications to the communication device comprises reducing the frequency of transmission of further communications to the communication device for a period of time or until a specified time (claim 100), and outputting for presentation on a display a prompt indicating the overload condition and receiving a response to the presented prompt (claim 106). However, these additional element amount to implementing an abstract idea on a generic computing device, displaying a result, or results based apply it (i.e., insignificant extra-solution activities). As such, these additional elements, when considered individually or in combination with the previously identified additional elements, do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claims are rejected under 35 U.S.C. 101 for lacking eligible subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 89-108 are rejected under 35 U.S.C. 103 as being unpatentable over Rajasenan (U.S. Patent Publication 2015/0248532 A1), referred to hereinafter as Rajasenan, in view of Sampath et al. (U.S. Patent Publication 2019/0304601 A1), referred to hereinafter as Sampath, Deluca et al. (U.S. Patent Publication 2011/0087743 A1), referred to hereinafter as Deluca, and Yang et al. (U.S. Patent Publication 2020/0152332 A1), referred to hereinafter as Yang.
Regarding claim 89, Rajasenan teaches a method for controlling communication to a communication device, the method comprising (Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”):
communication to and from the communication device; (i) receiving a plurality of generated communications destined to the communication device (Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”);
reducing, a frequency of transmission of further communications to the communication device (Rajasenan [0099] “In step 508, fungible tasks are determined to identify tasks that can provide relief an overloaded healthcare provider who reaches a tipping points. Fungible tasks are tasks that can be effectively transferred away from the person exceeding their tipping point, whether from the dimension of another person doing it, other tasks of the overloaded person, the same overloaded person doing the task at another time, the person reaching the tipping point doing the task faster and easier from another place (e.g. from home via telemedicine), or another person rescuing the task via tele-health remotely. These determinations of fungibility can be from persons stating the rules of what they can, and are willing to, transfer to others experiencing overload, or can be determined from historical data analysis that shows past transfer of certain tasks, and to whom, thus enabling us to determine how likely a task can be transferred, and to what type of role (based on the persons, like nurses, clerical staff, etc.) or specific persons.”,
Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”);
wherein reducing server the frequency of transmission of further communications to the communication; to determine that a plurality of overload factors meets an overload condition, wherein the reducing of the frequency of transmission of further communications to the communication device is determining that the plurality of overload factors meets the overload condition (Rajasenan [0099] “In step 508, fungible tasks are determined to identify tasks that can provide relief an overloaded healthcare provider who reaches a tipping points. Fungible tasks are tasks that can be effectively transferred away from the person exceeding their tipping point, whether from the dimension of another person doing it, other tasks of the overloaded person, the same overloaded person doing the task at another time, the person reaching the tipping point doing the task faster and easier from another place (e.g. from home via telemedicine), or another person rescuing the task via tele-health remotely. These determinations of fungibility can be from persons stating the rules of what they can, and are willing to, transfer to others experiencing overload, or can be determined from historical data analysis that shows past transfer of certain tasks, and to whom, thus enabling us to determine how likely a task can be transferred, and to what type of role (based on the persons, like nurses, clerical staff, etc.) or specific persons.”,
Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”,
Rajasenan [0068] “FIG. 1A illustrates a storage structure 102 for storing the results of process mining to determine tipping points for an exemplary Dr. A. Graph 104 graphically presents the information in storage structure 104. Storage structure 102 stores the number of tasks for each item (case type that can be handled by a healthcare provider), the completion rate for those tasks, and the load at which the completion rate is achieved. As can be seen in FIG. 1A, process mining revealed that Dr. A that for CHF cases, Dr. A is able to complete all 10 tasks required for a CHF case when her cognitive load is 50% or less of her cognitive capacity. Thus, Dr. A can complete 100% of the tasks associated with a CHF case so long as her cognitive bandwidth is 50% or greater. However, Dr. A's efficiency drops to 85% when her cognitive load increases to 75% of her cognitive capacity, or put another way, her cognitive bandwidth is reduced to 25%. Using process mining and data analysis, similar analyses can be performed for all healthcare providers in a healthcare facility and a storage structure 102 can be created for each such healthcare provider.”
Rajasenan [0069] “As resources are assigned to a healthcare provider to perform particular tasks, their cognitive bandwidth is reduced and stored as described above with respect to FIG. 1A. That is, if Dr. A is assigned another task, Dr. A's available bandwidth is reduced to account for that additional assignment, and stored. In that way, an assessment of Dr. A's tipping point can be made to (1) identify tasks at risk where Dr. A is responsible for performing those tasks, (2) determine whether Dr. A can be assigned additional tasks, and (3) determine the complexity of tasks that can be assigned to Dr. A. Different data can be stored in particular embodiments dependent on the needs of that particular embodiment.”
Rajasenan [0070] “FIG. 1B illustrates an exemplary performance versus cognitive bandwidth curve 106 that can be created from process mining healthcare provider performance. As shown in curve 106 once a tipping point 108 is reached, task errors increase disproportionately as cognitive consumption increases because cognitive consumption reduces the healthcare provider's cognitive bandwidth. In an embodiment, the tipping point information from curves such as curve 106 is used to provide the information in storage structure 102. Using the information in storage structure 102 for each healthcare provider in a healthcare facility, a task at risk can be reallocated to prevent tipping points. Or other tasks can be offloaded to reduce the tasks at risk of the team member that has exceeded their tipping point. Additional details for tipping point analysis can be found in U.S. Pat. No. 8,515,777, filed Oct. 12, 2011, which is hereby incorporated by reference in its entirety.”).
Rajasenan fails to explicitly teach monitoring over time, by a network server remote from the communication device, wherein the monitoring includes, at a processor of the network server, and (ii) monitoring, by the network server, response time for the communication device responding to the communications; detecting by the network server, based on the monitoring over time of the communication to and from the communication device, a trending increase in response time for the communication device responding to communications sent to the communication device; based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device, by the network server; and by the network server, based at least on the detecting of the trending increase in response time for the communication device responding to the communications sent to the communication device includes executing by the network server a trained machine- learning model, including the trending increase in response time for the communication device responding to the communications sent to the communication device.
Sampath teaches monitoring over time, by a network server remote from the communication device, wherein the monitoring includes, at a processor of the network server, and (ii) monitoring, by the network server, response time for the communication device responding to the communications (Sampath [0091] “In some implementations, a server 136 may optionally be included in the physiological monitoring system 100. The server 136 in these implementations is generally a computing device such as a blade server or the like. In certain embodiments, the server 136 is an appliance server housed in a data closet. In other embodiments, the server 136 is a server located at a central nurses' station, such as a workstation server.”
Sampath [0092] “The server 136 receives contextual data packages from a plurality of network interface modules 106 and stores the contextual data package in a storage device 138. In certain embodiments, this storage device 138 therefore archives long-term patient data. This patient data may be maintained even after the patient is discharged. In storing patient data, the server 136 may act as an interface between the shared network and an external electronic medical record (EMR) system.”
Sampath [0093] “The server 136 may also store data concerning user interactions with the system and system performance metrics. Integrated into the server 136 of certain embodiments is a journal database that stores every alert and alarm or a subset of the alerts and alarms as well as human interaction in much the same way as an aviation “black box” records cockpit activity. The journal is not normally accessible to the clinical end user and, without technical authorization, cannot be tampered with. In addition, the server 136 may perform internal journaling of system performance metrics such as overall system uptime.”
Sampath [0094] “In one embodiment, the journaling function of the server 136 constitutes a transaction-based architecture. Certain transactions of the physiological monitoring system 100 are journaled such that a timeline of recorded events may later be re-constructed to evaluate the quality of healthcare given. These transactions include state changes relating to physiological information from the patient monitoring devices 100, to the patient monitoring devices 110, to the hospital WLAN 126 connection, to user operation, and to system behavior. Journaling related to the physiological information received from a physiological monitor in one embodiment includes recording the physiological information itself, recording changes in the physiological information, or both.
Sampath [0095] “The server 136 in certain embodiments provides logic and management tools to maintain connectivity between network interface modules 106, clinician notification devices such as PDAs and pagers, and external systems such as EMRs. The server 136 of certain embodiments also provides a web based interface to allow installation (provisioning) of software rated to the physiological monitoring system 100, adding new devices to the system, assigning notifiers (e.g., PDAs, pagers, and the like) to individual clinicians for alarm notification at beginning and end of shift, escalation algorithms in cases where a primary caregiver does not respond to an alarm, interfaces to provide management reporting on the alarm occurrence and response time, location management, and internal journaling of system performance metrics such as overall system uptime (see, e.g., FIG. 5 and accompanying description)”
Sampath [0243] “In some embodiments, the patient monitoring device 1400 responds to detection of a clinician's presence by changing the language in which textual information is displayed by the monitoring device in accordance with language preferences of the clinician. In some embodiments, the patient monitoring device identifies and executes on-device confirmations that may be required for risk management based upon the detected clinician(s) in proximity to the monitoring device. In some embodiments, the patient monitoring device logs the number of clinician visits to a patient's bedside, the time of presence of each visit, the length of each clinician visit, the response time of clinicians to alarms, etc. A clinician may be permitted to chart parameters measured by the monitoring device to, for example, an electronic medical record with credentials based upon detection of clinician identity. Many other types of actions and/or configuration changes, or combinations of those described herein, can also be caused to automatically be initiated based upon the fact that a clinician has been detected in proximity to the patient monitoring device 1400.”);
detecting by the network server, based on the monitoring over time of the communication to and from the communication device, a response time for the communication device responding to communications sent to the communication device (Sampath [0175] “The journal management module 725, in certain implementations, receives medical event data from the monitor 740 and the nurses' station system 730 and stores this data in the journal database 724. In an embodiment, the journal database 724 is a relational database; however, other structures may be used. Each entry of event data may have a corresponding time stamp that indicates when an event occurred. This time stamp may be provided by the journal modules 746 or 736 or by the journal management module 725. The journal management module 725 may also store event counters in the journal database 724 that reflect a number of times medical events occurred. For example, counters could be stored that count how many alarms occurred within a period of time or how many times a clinician logged on or logged off of a network device.”
Sampath [0176] “Advantageously, the journal management module 725 may, in certain embodiments, analyze the medical data in the journal database 724 to determine statistics or metrics of clinician and/or hospital performance. The journal management module 725 may provide an interface to users of the nurses' station system 730 or another computing device to access these statistics. In one example embodiment, journal management module 725 can analyze alarm events and alarm deactivation events to determine clinician response times to alarms. The journal management module 725 may further determine the clinician response times in nurses' day and night shifts. The journal management module 725 may generate reports of these statistics so that hospital administrators, for example, may determine which shifts perform better than others.”
Sampath [0180] “At block 802, medical events are journaled in a journal database. In response to requests for report from a user (e.g., a clinician), at block 804 statistics about the medical events are obtained from the journal database. The statistics may include the type, frequency, and duration of medical events, the identity of clinicians or patients associated with the events, alarm response times, combinations of the same, and the like.”, and
Sampath [0243] “In some embodiments, the patient monitoring device 1400 responds to detection of a clinician's presence by changing the language in which textual information is displayed by the monitoring device in accordance with language preferences of the clinician. In some embodiments, the patient monitoring device identifies and executes on-device confirmations that may be required for risk management based upon the detected clinician(s) in proximity to the monitoring device. In some embodiments, the patient monitoring device logs the number of clinician visits to a patient's bedside, the time of presence of each visit, the length of each clinician visit, the response time of clinicians to alarms, etc. A clinician may be permitted to chart parameters measured by the monitoring device to, for example, an electronic medical record with credentials based upon detection of clinician identity. Many other types of actions and/or configuration changes, or combinations of those described herein, can also be caused to automatically be initiated based upon the fact that a clinician has been detected in proximity to the patient monitoring device 1400.”);
based at least on the detecting of the response time for the communication device responding to the communications sent to the communication device, by the network server (Sampath [0175] “The journal management module 725, in certain implementations, receives medical event data from the monitor 740 and the nurses' station system 730 and stores this data in the journal database 724. In an embodiment, the journal database 724 is a relational database; however, other structures may be used. Each entry of event data may have a corresponding time stamp that indicates when an event occurred. This time stamp may be provided by the journal modules 746 or 736 or by the journal management module 725. The journal management module 725 may also store event counters in the journal database 724 that reflect a number of times medical events occurred. For example, counters could be stored that count how many alarms occurred within a period of time or how many times a clinician logged on or logged off of a network device.”
Sampath [0176] “Advantageously, the journal management module 725 may, in certain embodiments, analyze the medical data in the journal database 724 to determine statistics or metrics of clinician and/or hospital performance. The journal management module 725 may provide an interface to users of the nurses' station system 730 or another computing device to access these statistics. In one example embodiment, journal management module 725 can analyze alarm events and alarm deactivation events to determine clinician response times to alarms. The journal management module 725 may further determine the clinician response times in nurses' day and night shifts. The journal management module 725 may generate reports of these statistics so that hospital administrators, for example, may determine which shifts perform better than others.”
Sampath [0180] “At block 802, medical events are journaled in a journal database. In response to requests for report from a user (e.g., a clinician), at block 804 statistics about the medical events are obtained from the journal database. The statistics may include the type, frequency, and duration of medical events, the identity of clinicians or patients associated with the events, alarm response times, combinations of the same, and the like.”, and
Sampath [0243] “In some embodiments, the patient monitoring device 1400 responds to detection of a clinician's presence by changing the language in which textual information is displayed by the monitoring device in accordance with language preferences of the clinician. In some embodiments, the patient monitoring device identifies and executes on-device confirmations that may be required for risk management based upon the detected clinician(s) in proximity to the monitoring device. In some embodiments, the patient monitoring device logs the number of clinician visits to a patient's bedside, the time of presence of each visit, the length of each clinician visit, the response time of clinicians to alarms, etc. A clinician may be permitted to chart parameters measured by the monitoring device to, for example, an electronic medical record with credentials based upon detection of clinician identity. Many other types of actions and/or configuration changes, or combinations of those described herein, can also be caused to automatically be initiated based upon the fact that a clinician has been detected in proximity to the patient monitoring device 1400.”);
by the network server; based at least on the detecting of the response time for the communication device responding to the communications sent to the communication device includes executing by the network server including the trending increase in response time for the communication device responding to the communications sent to the communication device (Sampath [0175] “The journal management module 725, in certain implementations, receives medical event data from the monitor 740 and the nurses' station system 730 and stores this data in the journal database 724. In an embodiment, the journal database 724 is a relational database; however, other structures may be used. Each entry of event data may have a corresponding time stamp that indicates when an event occurred. This time stamp may be provided by the journal modules 746 or 736 or by the journal management module 725. The journal management module 725 may also store event counters in the journal database 724 that reflect a number of times medical events occurred. For example, counters could be stored that count how many alarms occurred within a period of time or how many times a clinician logged on or logged off of a network device.”
Sampath [0176] “Advantageously, the journal management module 725 may, in certain embodiments, analyze the medical data in the journal database 724 to determine statistics or metrics of clinician and/or hospital performance. The journal management module 725 may provide an interface to users of the nurses' station system 730 or another computing device to access these statistics. In one example embodiment, journal management module 725 can analyze alarm events and alarm deactivation events to determine clinician response times to alarms. The journal management module 725 may further determine the clinician response times in nurses' day and night shifts. The journal management module 725 may generate reports of these statistics so that hospital administrators, for example, may determine which shifts perform better than others.”
Sampath [0180] “At block 802, medical events are journaled in a journal database. In response to requests for report from a user (e.g., a clinician), at block 804 statistics about the medical events are obtained from the journal database. The statistics may include the type, frequency, and duration of medical events, the identity of clinicians or patients associated with the events, alarm response times, combinations of the same, and the like.”, and
Sampath [0243] “In some embodiments, the patient monitoring device 1400 responds to detection of a clinician's presence by changing the language in which textual information is displayed by the monitoring device in accordance with language preferences of the clinician. In some embodiments, the patient monitoring device identifies and executes on-device confirmations that may be required for risk management based upon the detected clinician(s) in proximity to the monitoring device. In some embodiments, the patient monitoring device logs the number of clinician visits to a patient's bedside, the time of presence of each visit, the length of each clinician visit, the response time of clinicians to alarms, etc. A clinician may be permitted to chart parameters measured by the monitoring device to, for example, an electronic medical record with credentials based upon detection of clinician identity. Many other types of actions and/or configuration changes, or combinations of those described herein, can also be caused to automatically be initiated based upon the fact that a clinician has been detected in proximity to the patient monitoring device 1400.”).
Deluca teaches a trending increase (Deluca [0051] “In one embodiment, the response time trend module 108 determines response time trends for the one or more recipients 104. As used herein, recipient refers to either a single recipient or a group of recipients sharing a common attribute (i.e. all recipients of the marketing group). The response time trend module 108 may be integrated with, installed on, or otherwise in communication with the user computing device 106 and/or the email server 116. In one embodiment, the response time trend module 108 is integrated with the email client application that is installed on or accessible from the user computing device 106. The response time trend module 108 may determine response time trends of the one or more recipients 104 specifically for the user 102, or, in another embodiment, may determine response time trends of the one or more recipients 104 relative to a plurality of users 102. In one embodiment, the response time trend module 108 is local to the user computing device 106, and determines response time trends for the one or more recipients 104 relative to the user 102 based on email messages accessible to the user 102. In this manner, the response time trend module 108 can determine response time trends for the user 102 without extra interactions with or privacy intrusions on the one or more recipients 104.”);
Yang teaches a trained machine- learning model (Yang [0049] “In turn, at step 256, an (i)th generation model is trained using the extracted features and outcomes of step 254. It should be understood that various machine learning or predictive analysis algorithms can be used to train the (i)th generation model, including a Bayesian survival analysis algorithm, online survival LASSO algorithm, and online random survival forest algorithms, as well as other predictive analysis algorithms known to those of skill in the art.”)
Yang [0050] “Although training the model can be performed in many ways known to those of skill in the art, in some example embodiments, to train the (i=1)th generation model, the importance of features is determined and/or weights are assigned to one or more of the identified features based on their apparent impact on outcomes within that particular (i)th window W(i). That is, for each of the outcomes of the (i)th set of extracted outcomes, the system 101 analyzes the features of the (i)th set of extracted features to identify patterns. These patterns may be, for example, patterns showing that certain features (or certain values for certain types of features) are commonly associated with a given outcome. For instance, the system 101 can analyze the features and determine that a large number of patients residing in a particular neighborhood suffered respiratory issues. This is interpreted by the system as the outcome of respiratory-related visits, or the like, being largely impacted by the feature of a patient's residence or address. Moreover, for instance, if an outcome is a hospital admission for depression, then all instances of that outcome in the (i)th set of extracted features and outcomes are analyzed to determine which features are most common. For example, if 90% of the instances of hospital admission for depression occur to males between the ages of 50 and 60, then the demographic features of age and gender are deemed to be of higher importance for prediction. Thus, for each specific window and corresponding model, features that are associated with an outcome and that are determined to have an impact on an outcome are deemed to be important variables and treated as predictive variables. For each predictive variable corresponding to the (i)th window W(i), a respective weight is calculated based on the extracted data, and the weight is assigned,based on the predictive variables' calculated impact on an outcome within the the (i)th window W(i). Predictive values from the (i)the window that are given a higher weight in the (i)th generation model are those that frequently appear in connection with a particular outcome in the (i)th window, whereas those features or predictive values that are not frequently associated with the outcome are given a lower weight. It should be understood that, in some embodiments, the importance or weight of variables in one window does not necessarily impact or change the importance or weight of those same variables in other windows.”;
Yang [0031] “The example embodiments presented herein are directed to systems and methods for dynamically monitoring patient conditions and predicting adverse events. More specifically, the systems and methods provided herein describe the collection and storage of data by healthcare provider entities. Examples of such data include historical claim feed data, which is information relating to patients' medical claims. The data is used to dynamically monitor patient conditions by predicting the occurrence of events, including adverse events. To predict the occurrence of events, a model is trained using the historical claim feed data. The training of the model is performed using a sliding-window approach or algorithm, in which one window or a set of windows from the historical claim feed data are sequentially analyzed. That is, features and outcomes are extracted from the existing defined windows and a model is trained based on these. The existing model is updated using the extracted features and outcomes of the next coming window. Each window of data is sequentially used to update the model. The most up-to-date model is used to predict the occurrence of events at a future time.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the communication management system of Rajasenan with the server based communication monitoring and response-time analysis techniques of Sampath, the response time trend determination of DeLuca, and the trained machine learning techniques of Yang. Rajasenan teaches determining healthcare provider overload based on multiple workload factors, identifying tipping points, and reducing communications by offloading tasks and notifying healthcare providers when overload conditions exist. Sampath teaches collecting timestamped communication events, monitoring clinician response times over time, and maintaining response time statistics, while DeLuca teaches determining response time trends from monitored communications. Yang teaches employing trained machine learning models that analyze multiple extracted features, assign feature importance and weights, identify predictive patterns, and determine outcomes based on those weighted features.
A person of ordinary skill in the art would have been motivated to incorporate the response time monitoring of Sampath, the response time trend analysis of DeLuca, and Yang's machine learning techniques into Rajasenan's overload determination framework because response time trends represent an additional measurable indicator of provider workload and communication responsiveness, and machine learning analysis of multiple workload factors provides a known technique for improving prediction of overload conditions from historical and real time operational data. This combination would have predictably enabled the communication management system to more accurately identify providers approaching overload and proactively reduce subsequent communications directed to those providers, thereby improving workload distribution, reducing communication burden, and achieving the predictable result of more effective communication management using known techniques applied according to their established functions.
Regarding claim 90, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein the monitoring over time of the communications to and from the communication device comprises monitoring the communications using a sliding window algorithm (Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”,
Yang [0044] “At step 252, an (i)th data chunk referred to as a “window” is identified and prepared for analysis by the healthcare analytics system using a sliding window-based algorithm or approach. This window is also referred to as a current window from among a set of n windows that make up the historical claim feed data. It should be understood that a window refers to a subset of the historical claim feed data that corresponds to a sub-period of time among the period of time covered by the historical claim feed data. The length of the sub-period of time can be any period of time (e.g., one month, six months, one year) deemed optimal or selected by the healthcare analytics system 101.”,
Yang [0045] “For instance, as shown in exemplary FIG. 4, the historical claim feed data covers the four and a half year period of Jan. 1, 2012 to Jun. 30, 2016. In an exemplary embodiment in which the selected length of each sub-period covered by a window in the sliding window approach is one year, the first window (i=1) in a first iteration covers or corresponds to the sub-period of Jan. 1, 2012 to Dec. 31, 2012. FIG. 4 illustrates, among other windows, the (i)th window W(i), which in an exemplary first iteration in which i=1 is the W(i=1)th window which covers the Jan. 1, 2012 to Dec. 31, 2012 sub-period and its historical claim feed data.”,
Yang [0046] “In turn, once the window W(i) has been identified at step 252, an (i)th set of features and outcomes are extracted at step 254. FIG. 5A graphically illustrates the extraction of the (i)th set of features and outcomes from the historical claim feed data. It should be understood that the extracted features can be any data from among the stored or received healthcare data, as selected by the healthcare provider entity or entities associated with the healthcare analytics system 101. In other words, each healthcare analytics system 101 can be configured to extract certain features and not others. This can be based on prior knowledge of features that can have an impact versus features previously deemed impactful on an outcome. For instance, the extracted features can include patient demographic information (e.g., age, gender, weight, height, ethnicity, residence, distance from hospital, etc.) and hospital information (e.g., location, doctors, staff, machinery) during the time period of window W(i) (e.g., Jan. 1, 2012 to Dec. 31, 2012, in an embodiment in which i=1).”, and
Yang [0047] “Outcomes are also extracted at step 254. The extracted outcomes can include the occurrence of events (e.g., remission, readmission, etc.), healthcare delivery entity visits (e.g., hospital visits, physician visits), or prescriptions provided. However, it should be understood that the outcomes that are extracted can be configured for each system 101 as deemed appropriate, optimal, or necessary. In some embodiments, outcomes are extracted for a period of time of a predetermined length subsequent to the current, (i)th window W(i). For instance, if the desired or optimal period of time for which to extract outcomes is determined to be six months, then, at step 254, the historical claim feed data is analyzed to identify outcomes that occurred in the six month period following W(i). In an exemplary first iteration in which i=1, the sixth month period following the window W(i=1) from which outcomes are extracted is Jan. 1, 2013 to Jun. 30, 2013. The extracted (i)th set of outcomes are graphically represented in the temporal data representation of FIG. 5A for the current, (i)th window.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the communication monitoring system of Rajasenan, as further modified by Sampath and DeLuca, to monitor communications using the sliding window-based algorithm taught by Yang. Yang teaches analyzing temporal data using a sliding window-based algorithm in which successive time windows of data are identified and analyzed to continuously evaluate changing conditions over time. A person of ordinary skill in the art would have recognized that applying Yang's known sliding window monitoring technique to the communication and response time monitoring of Rajasenan, Sampath, and DeLuca would have been a predictable use of a known data analysis technique to process continuously changing communication events and response times. This modification would have enabled more current and continuously updated monitoring of communication activity and response time trends while naturally discarding stale data, which provide a more responsive basis for detecting overload conditions and managing subsequent communications. The combination applies a known temporal analysis technique to a known communication monitoring system according to its established function and yields no more than the predictable result of improved time monitoring.
Regarding claim 91, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 90, as discussed above, and further teach wherein monitoring the communications using the sliding window algorithm comprises maintaining a weighted score per sample window time period, thereby establishing a timeline of weighted score from oldest to newest (Yang [0044] “At step 252, an (i)th data chunk referred to as a “window” is identified and prepared for analysis by the healthcare analytics system using a sliding window-based algorithm or approach. This window is also referred to as a current window from among a set of n windows that make up the historical claim feed data. It should be understood that a window refers to a subset of the historical claim feed data that corresponds to a sub-period of time among the period of time covered by the historical claim feed data. The length of the sub-period of time can be any period of time (e.g., one month, six months, one year) deemed optimal or selected by the healthcare analytics system 101.”,
Yang [0045] “For instance, as shown in exemplary FIG. 4, the historical claim feed data covers the four and a half year period of Jan. 1, 2012 to Jun. 30, 2016. In an exemplary embodiment in which the selected length of each sub-period covered by a window in the sliding window approach is one year, the first window (i=1) in a first iteration covers or corresponds to the sub-period of Jan. 1, 2012 to Dec. 31, 2012. FIG. 4 illustrates, among other windows, the (i)th window W(i), which in an exemplary first iteration in which i=1 is the W(i=1)th window which covers the Jan. 1, 2012 to Dec. 31, 2012 sub-period and its historical claim feed data.”,
Yang [0046] “In turn, once the window W(i) has been identified at step 252, an (i)th set of features and outcomes are extracted at step 254. FIG. 5A graphically illustrates the extraction of the (i)th set of features and outcomes from the historical claim feed data. It should be understood that the extracted features can be any data from among the stored or received healthcare data, as selected by the healthcare provider entity or entities associated with the healthcare analytics system 101. In other words, each healthcare analytics system 101 can be configured to extract certain features and not others. This can be based on prior knowledge of features that can have an impact versus features previously deemed impactful on an outcome. For instance, the extracted features can include patient demographic information (e.g., age, gender, weight, height, ethnicity, residence, distance from hospital, etc.) and hospital information (e.g., location, doctors, staff, machinery) during the time period of window W(i) (e.g., Jan. 1, 2012 to Dec. 31, 2012, in an embodiment in which i=1).”,
Yang [0047] “Outcomes are also extracted at step 254. The extracted outcomes can include the occurrence of events (e.g., remission, readmission, etc.), healthcare delivery entity visits (e.g., hospital visits, physician visits), or prescriptions provided. However, it should be understood that the outcomes that are extracted can be configured for each system 101 as deemed appropriate, optimal, or necessary. In some embodiments, outcomes are extracted for a period of time of a predetermined length subsequent to the current, (i)th window W(i). For instance, if the desired or optimal period of time for which to extract outcomes is determined to be six months, then, at step 254, the historical claim feed data is analyzed to identify outcomes that occurred in the six month period following W(i). In an exemplary first iteration in which i=1, the sixth month period following the window W(i=1) from which outcomes are extracted is Jan. 1, 2013 to Jun. 30, 2013. The extracted (i)th set of outcomes are graphically represented in the temporal data representation of FIG. 5A for the current, (i)th window.”, and
Yang [0050] “Although training the model can be performed in many ways known to those of skill in the art, in some example embodiments, to train the (i=1)th generation model, the importance of features is determined and/or weights are assigned to one or more of the identified features based on their apparent impact on outcomes within that particular (i)th window W(i). That is, for each of the outcomes of the (i)th set of extracted outcomes, the system 101 analyzes the features of the (i)th set of extracted features to identify patterns. These patterns may be, for example, patterns showing that certain features (or certain values for certain types of features) are commonly associated with a given outcome. For instance, the system 101 can analyze the features and determine that a large number of patients residing in a particular neighborhood suffered respiratory issues. This is interpreted by the system as the outcome of respiratory-related visits, or the like, being largely impacted by the feature of a patient's residence or address. Moreover, for instance, if an outcome is a hospital admission for depression, then all instances of that outcome in the (i)th set of extracted features and outcomes are analyzed to determine which features are most common. For example, if 90% of the instances of hospital admission for depression occur to males between the ages of 50 and 60, then the demographic features of age and gender are deemed to be of higher importance for prediction. Thus, for each specific window and corresponding model, features that are associated with an outcome and that are determined to have an impact on an outcome are deemed to be important variables and treated as predictive variables. For each predictive variable corresponding to the (i)th window W(i), a respective weight is calculated based on the extracted data, and the weight is assigned,based on the predictive variables' calculated impact on an outcome within the the (i)th window W(i). Predictive values from the (i)the window that are given a higher weight in the (i)th generation model are those that frequently appear in connection with a particular outcome in the (i)th window, whereas those features or predictive values that are not frequently associated with the outcome are given a lower weight. It should be understood that, in some embodiments, the importance or weight of variables in one window does not necessarily impact or change the importance or weight of those same variables in other windows.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the communication monitoring system of Rajasenan, as further modified by Sampath and DeLuca, to employ the weighted sliding window based analysis taught by Yang. Yang teaches monitoring temporal data using a sliding window based algorithm in which successive time windows are analyzed and feature importance is determined by assigning weights to extracted features based on their predictive significance. A person of ordinary skill in the art would have recognized that applying Yang's weighted sliding window analysis to the monitored communication and response time information of Rajasenan, Sampath, and DeLuca would have been a predictable use of a known temporal data analysis technique to continuously evaluate communication behavior over successive time periods. This modification would have predictably enabled the system to maintain weighted analytical values for successive monitoring windows, thereby establishing a chronological timeline of weighted information from older windows to newer windows for use in determining overload conditions and managing subsequent communications. The combination applies a known analytical technique to a known communication monitoring system according to its established function and yields the predictable result of improved temporal evaluation of communication and response time data.
Regarding claim 92, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein the monitoring over time of the communications to and from the communication device comprises comparing timestamps of communications sent to the communication device and timestamps of responses received from the communication device (Sampath [0175] “The journal management module 725, in certain implementations, receives medical event data from the monitor 740 and the nurses' station system 730 and stores this data in the journal database 724. In an embodiment, the journal database 724 is a relational database; however, other structures may be used. Each entry of event data may have a corresponding time stamp that indicates when an event occurred. This time stamp may be provided by the journal modules 746 or 736 or by the journal management module 725. The journal management module 725 may also store event counters in the journal database 724 that reflect a number of times medical events occurred. For example, counters could be stored that count how many alarms occurred within a period of time or how many times a clinician logged on or logged off of a network device.”
Sampath [0176] “Advantageously, the journal management module 725 may, in certain embodiments, analyze the medical data in the journal database 724 to determine statistics or metrics of clinician and/or hospital performance. The journal management module 725 may provide an interface to users of the nurses' station system 730 or another computing device to access these statistics. In one example embodiment, journal management module 725 can analyze alarm events and alarm deactivation events to determine clinician response times to alarms. The journal management module 725 may further determine the clinician response times in nurses' day and night shifts. The journal management module 725 may generate reports of these statistics so that hospital administrators, for example, may determine which shifts perform better than others.”, and
Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”).
It would have been obvious to one of ordinary skill in the art to determine clinician response times in the communication management system of Rajasenan by employing the timestamped event monitoring taught by Sampath. Sampath teaches storing timestamped medical events and analyzing alarm events and corresponding alarm deactivation events to determine clinician response times. A person of ordinary skill would have recognized that determining elapsed response time necessarily requires comparing the timestamp of a transmitted communication or alarm with the timestamp of the corresponding clinician response. Applying Sampath's timestamp comparison techniques to Rajasenan's communication management system would have predictably enabled accurate monitoring of communication response latency for overload determination while using each reference according to its established function.
Regarding claim 93, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein the communications comprise at least one of messages, calls, alerts, pages, or public announcements (Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement the communications of the communication management system of Rajasenan as messages, alerts, or pages because Rajasenan teaches transmitting managed alerts and messages to healthcare providers using personal communication devices, including pagers, to communicate task assignments and overload notifications. A person of ordinary skill in the art would have recognized that messages, alerts, and pages are well known and interchangeable forms of electronic communication used to notify users in healthcare communication systems. Employing these known communication types would have represented nothing more than the predictable use of known communication techniques for their established purpose of conveying information to intended recipients.
Regarding claim 94, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein the communication device comprises a voice communications badge (Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”
Sampath [0195] “In some embodiments, the patient monitoring devices described herein are capable of transmitting patient information to one or more remote devices for review by a clinician. For example, such remote devices can include remote computers, smart phones, PDAs, etc. This is useful because it enhances the ability of a clinician to monitor a patient's condition remotely. For example, the clinician need not be at the patient's bedside or even at a hospital or other patient care facility in order to effectively monitor the patient's condition.”, and
Sampath [0197] “The transmission of patient information (e.g., medical parameter data, video/audio of the patient, etc.) can be made using, for example, one or more communication networks (e.g., computer networks such as LANs, WLANs, the Internet, etc., telephone networks, etc.). In some embodiments, one or more communication networks that are entirely or partially physically located in a hospital or other patient care center can be used. In some embodiments, external communication networks can be used to reach remote devices throughout the world. Thus, clinicians can remotely obtain a vast amount of information regarding the condition of their patients regardless of the clinician's location. In some embodiments, the clinician may also have the capability to directly communicate with the patient. For example, a patient monitoring device could include a speaker for broadcasting audio from the clinician's remote device to the patient. Similarly, a patient monitoring device could include a display for showing video from the clinician's remote device (e.g., video teleconferencing). In this way, the exchange of information can be bidirectional to allow the clinician to directly interact with the patient.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement the personal communication device of Rajasenan as a voice capable clinician communication device in view of Sampath. Rajasenan teaches communicating managed alerts and messages to healthcare providers using portable personal communication devices to facilitate task assignments and overload notifications, while Sampath teaches portable clinician communication devices, such as smartphones and PDAs, and further teaches bidirectional voice communications between clinicians and patients through such communication devices. A person of ordinary skill in the art would have recognized that selecting a voice capable wearable communication device, such as a voice communication badge, for use as the clinician's personal communication device would have been nothing more than the predictable substitution of one known portable communication device for another to obtain the expected benefit of hands free voice communications while maintaining the same communication functionality. This substitution employs known communication devices according to their established functions and would have yielded predictable results.
Regarding claim 95, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein reducing the frequency of transmission of further communications to the communication device comprises reducing a frequency of generation of further communications to be sent to the communication device (Rajasenan [0098] “In step 506, steps 502 and 504 are repeated for each healthcare provider that might be tasked with supporting the current healthcare provider team (flexible resources). The support team comes in to save tasks at risk. But, support healthcare providers must have sufficient cognitive bandwidth to succeed in the rescue as well, so hence the need for getting their tipping point.”
Rajasenan [0099] “In step 508, fungible tasks are determined to identify tasks that can provide relief an overloaded healthcare provider who reaches a tipping points. Fungible tasks are tasks that can be effectively transferred away from the person exceeding their tipping point, whether from the dimension of another person doing it, other tasks of the overloaded person, the same overloaded person doing the task at another time, the person reaching the tipping point doing the task faster and easier from another place (e.g. from home via telemedicine), or another person rescuing the task via tele-health remotely. These determinations of fungibility can be from persons stating the rules of what they can, and are willing to, transfer to others experiencing overload, or can be determined from historical data analysis that shows past transfer of certain tasks, and to whom, thus enabling us to determine how likely a task can be transferred, and to what type of role (based on the persons, like nurses, clerical staff, etc.) or specific persons.”, and
Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to reduce the frequency of generation of further communications directed to an overloaded healthcare provider in the communication management system of Rajasenan. Rajasenan teaches determining when a healthcare provider has reached or is approaching a tipping point, identifying fungible tasks that can be transferred away from the overloaded provider, and offloading those tasks to other healthcare providers. Rajasenan further teaches that task assignments are communicated through managed alerts or messages sent to the healthcare provider's personal communication device. A person of ordinary skill in the art would have recognized that, once tasks are no longer assigned to the overloaded provider, the system would correspondingly generate fewer task assignment communications directed to that provider because there would be fewer tasks requiring notification. Modifying the communication management system in this manner represents the predictable use of known workload redistribution techniques to reduce unnecessary communications to overloaded personnel while improving communication efficiency and workload management.
Regarding claim 96, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein reducing the frequency of transmission of further communications to the communication device comprises causing an entity that generates at least some of the communications to reduce frequency of generation of the communications (Rajasenan [0098] “In step 506, steps 502 and 504 are repeated for each healthcare provider that might be tasked with supporting the current healthcare provider team (flexible resources). The support team comes in to save tasks at risk. But, support healthcare providers must have sufficient cognitive bandwidth to succeed in the rescue as well, so hence the need for getting their tipping point.”
Rajasenan [0099] “In step 508, fungible tasks are determined to identify tasks that can provide relief an overloaded healthcare provider who reaches a tipping points. Fungible tasks are tasks that can be effectively transferred away from the person exceeding their tipping point, whether from the dimension of another person doing it, other tasks of the overloaded person, the same overloaded person doing the task at another time, the person reaching the tipping point doing the task faster and easier from another place (e.g. from home via telemedicine), or another person rescuing the task via tele-health remotely. These determinations of fungibility can be from persons stating the rules of what they can, and are willing to, transfer to others experiencing overload, or can be determined from historical data analysis that shows past transfer of certain tasks, and to whom, thus enabling us to determine how likely a task can be transferred, and to what type of role (based on the persons, like nurses, clerical staff, etc.) or specific persons.”, and
Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to cause the entity responsible for generating task assignment communications in the communication management system of Rajasenan to reduce the generation of communications directed to an overloaded healthcare provider. Rajasenan teaches determining when a healthcare provider has reached or is approaching a tipping point, identifying fungible tasks, transferring those tasks to other healthcare providers, and communicating task assignments through managed alerts or messages. A person of ordinary skill in the art would have recognized that, once the task assignment system determines that tasks should be reassigned away from an overloaded healthcare provider, the entity responsible for generating those task assignment communications would correspondingly generate fewer communications directed to that provider because additional task assignments would instead be directed to other providers. Implementing such communication management represents the predictable application of Rajasenan's workload redistribution techniques to reduce unnecessary communications to overloaded personnel while improving communication efficiency and workload distribution.
Regarding claim 97, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach further comprising applying by the network server an overload verification operation to verify that the plurality of overload factors meets the overload condition, wherein the overload verification operation comprises outputting for presentation on a display a prompt indicating the overload condition and receiving a response to the presented prompt (Rajasenan [0068] “FIG. 1A illustrates a storage structure 102 for storing the results of process mining to determine tipping points for an exemplary Dr. A. Graph 104 graphically presents the information in storage structure 104. Storage structure 102 stores the number of tasks for each item (case type that can be handled by a healthcare provider), the completion rate for those tasks, and the load at which the completion rate is achieved. As can be seen in FIG. 1A, process mining revealed that Dr. A that for CHF cases, Dr. A is able to complete all 10 tasks required for a CHF case when her cognitive load is 50% or less of her cognitive capacity. Thus, Dr. A can complete 100% of the tasks associated with a CHF case so long as her cognitive bandwidth is 50% or greater. However, Dr. A's efficiency drops to 85% when her cognitive load increases to 75% of her cognitive capacity, or put another way, her cognitive bandwidth is reduced to 25%. Using process mining and data analysis, similar analyses can be performed for all healthcare providers in a healthcare facility and a storage structure 102 can be created for each such healthcare provider.”,
Rajasenan [0069] “As resources are assigned to a healthcare provider to perform particular tasks, their cognitive bandwidth is reduced and stored as described above with respect to FIG. 1A. That is, if Dr. A is assigned another task, Dr. A's available bandwidth is reduced to account for that additional assignment, and stored. In that way, an assessment of Dr. A's tipping point can be made to (1) identify tasks at risk where Dr. A is responsible for performing those tasks, (2) determine whether Dr. A can be assigned additional tasks, and (3) determine the complexity of tasks that can be assigned to Dr. A. Different data can be stored in particular embodiments dependent on the needs of that particular embodiment.”,
Rajasenan [0070] “FIG. 1B illustrates an exemplary performance versus cognitive bandwidth curve 106 that can be created from process mining healthcare provider performance. As shown in curve 106 once a tipping point 108 is reached, task errors increase disproportionately as cognitive consumption increases because cognitive consumption reduces the healthcare provider's cognitive bandwidth. In an embodiment, the tipping point information from curves such as curve 106 is used to provide the information in storage structure 102. Using the information in storage structure 102 for each healthcare provider in a healthcare facility, a task at risk can be reallocated to prevent tipping points. Or other tasks can be offloaded to reduce the tasks at risk of the team member that has exceeded their tipping point. Additional details for tipping point analysis can be found in U.S. Pat. No. 8,515,777, filed Oct. 12, 2011, which is hereby incorporated by reference in its entirety.”,
Rajasenan [0108] “Referring back to FIG. 6A, in step 606, factors used to determine whether a task at risk has likely failed are determined. In embodiment, these factors include average task value, current healthcare team's saturation (cognitive overload level), cognitive bandwidth needed, and support team saturation (cognitive overload level).”,
Rajasenan [0133] “FIG. 7 illustrates an embodiment for interconnectivity between healthcare facilities HF1, HF2, HF3, and HF4 in a healthcare system 701 to allow distributed fungible resources (i.e., flexible resources) for offloading tasks at risk throughout healthcare system 701. Healthcare facilities HF1, HF2, HF3, and HF4 can be in the same healthcare system or in different healthcare systems. In the configurations illustrated in FIGS. 7 and 8, healthcare facilities HF1, HF2, HF3, and HF4 can communicate with one another as to their cognitive levels. For example, if a healthcare facility such as healthcare facility HF2 experiences a cognitive overload by one or more of its team members that would jeopardize a set of tasks and create many more tasks at risk, the PIC module can broadcast a message to healthcare facilities HF1, HF3, and HF4 to advise them of its current situation. Any or all of healthcare facilities HF1, HF3, and HF4 can respond (via their PIC module) as to whether they have sufficient cognitive capacity to handle offloaded tasks from healthcare facility HF2. Healthcare facility HF2 can offload tasks to one or more of healthcare facilities HF1, HF3, and HF4 that indicate they have cognitive capacity to handle the offloaded tasks. Healthcare facilities HF1, HF3, and HF4 can coordinate how much cognitive capacity they have available, and whether they can handle the offloaded tasks alone, or require additional cognitive capacity from one of the remaining healthcare facilities.”,
Sampath [0095] “The server 136 in certain embodiments provides logic and management tools to maintain connectivity between network interface modules 106, clinician notification devices such as PDAs and pagers, and external systems such as EMRs. The server 136 of certain embodiments also provides a web based interface to allow installation (provisioning) of software rated to the physiological monitoring system 100, adding new devices to the system, assigning notifiers (e.g., PDAs, pagers, and the like) to individual clinicians for alarm notification at beginning and end of shift, escalation algorithms in cases where a primary caregiver does not respond to an alarm, interfaces to provide management reporting on the alarm occurrence and response time, location management, and internal journaling of system performance metrics such as overall system uptime (see, e.g., FIG. 5 and accompanying description)”, and
Sampath [0412] “FIGS. 36A-B illustrate displays having layout zones including zones for parameters 3610, a plethysmograph 3620, a prompt window 3630, patient information 3640, monitor settings 3650, monitor status 3660, user profiles 3670, a parameter well 3680, pulse-to-pulse signal quality bars 3690 and soft key menus 3695. Advantageously, each zone dynamically scales information for readability of parameters most important to the proximate user. Also, the prompt window 3630 utilizes layered messaging that temporarily overwrites a less critical portion of the display. Further, the parameter well 3680 contains parameters that the proximate user has chosen to minimize until they alarm. These and other display efficiency features are described below.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement the overload determination system of Rajasenan using the server management interface and display prompt functionality taught by Sampath. Rajasenan teaches determining overload conditions using multiple workload-related factors to identify tipping points and verify whether a task is at risk, and further teaches communicating overload conditions and receiving responses from other healthcare facilities regarding available cognitive capacity before offloading tasks. Sampath teaches a server providing a web management interface and further teaches presenting prompts to users through a display including a prompt window utilizing layered messaging. A person of ordinary skill in the art would have found it obvious to present the detected overload condition through Sampath's display prompt and receive a corresponding response before implementing workload redistribution because presenting system generated determinations for user review and confirmation through graphical prompts was a well known user-interface technique for improving the reliability and usability of computerized management systems. Combining these known interface techniques with Rajasenan's overload determination framework would have predictably allowed users to verify overload conditions prior to reallocating tasks while using each reference according to its established function.
Regarding claim 98, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 97, as discussed above, and further teach further comprising adjusting by the network server the trained machine-learning model based on the received response to the presented prompt (Sampath [0095] “The server 136 in certain embodiments provides logic and management tools to maintain connectivity between network interface modules 106, clinician notification devices such as PDAs and pagers, and external systems such as EMRs. The server 136 of certain embodiments also provides a web based interface to allow installation (provisioning) of software rated to the physiological monitoring system 100, adding new devices to the system, assigning notifiers (e.g., PDAs, pagers, and the like) to individual clinicians for alarm notification at beginning and end of shift, escalation algorithms in cases where a primary caregiver does not respond to an alarm, interfaces to provide management reporting on the alarm occurrence and response time, location management, and internal journaling of system performance metrics such as overall system uptime (see, e.g., FIG. 5 and accompanying description)”,
Sampath [0412] “FIGS. 36A-B illustrate displays having layout zones including zones for parameters 3610, a plethysmograph 3620, a prompt window 3630, patient information 3640, monitor settings 3650, monitor status 3660, user profiles 3670, a parameter well 3680, pulse-to-pulse signal quality bars 3690 and soft key menus 3695. Advantageously, each zone dynamically scales information for readability of parameters most important to the proximate user. Also, the prompt window 3630 utilizes layered messaging that temporarily overwrites a less critical portion of the display. Further, the parameter well 3680 contains parameters that the proximate user has chosen to minimize until they alarm. These and other display efficiency features are described below.”).
Yang [0049] “In turn, at step 256, an (i)th generation model is trained using the extracted features and outcomes of step 254. It should be understood that various machine learning or predictive analysis algorithms can be used to train the (i)th generation model, including a Bayesian survival analysis algorithm, online survival LASSO algorithm, and online random survival forest algorithms, as well as other predictive analysis algorithms known to those of skill in the art.”,
Yang [0031] “The example embodiments presented herein are directed to systems and methods for dynamically monitoring patient conditions and predicting adverse events. More specifically, the systems and methods provided herein describe the collection and storage of data by healthcare provider entities. Examples of such data include historical claim feed data, which is information relating to patients' medical claims. The data is used to dynamically monitor patient conditions by predicting the occurrence of events, including adverse events. To predict the occurrence of events, a model is trained using the historical claim feed data. The training of the model is performed using a sliding-window approach or algorithm, in which one window or a set of windows from the historical claim feed data are sequentially analyzed. That is, features and outcomes are extracted from the existing defined windows and a model is trained based on these. The existing model is updated using the extracted features and outcomes of the next coming window. Each window of data is sequentially used to update the model. The most up-to-date model is used to predict the occurrence of events at a future time.”, and
Rajasenan [0133] “FIG. 7 illustrates an embodiment for interconnectivity between healthcare facilities HF1, HF2, HF3, and HF4 in a healthcare system 701 to allow distributed fungible resources (i.e., flexible resources) for offloading tasks at risk throughout healthcare system 701. Healthcare facilities HF1, HF2, HF3, and HF4 can be in the same healthcare system or in different healthcare systems. In the configurations illustrated in FIGS. 7 and 8, healthcare facilities HF1, HF2, HF3, and HF4 can communicate with one another as to their cognitive levels. For example, if a healthcare facility such as healthcare facility HF2 experiences a cognitive overload by one or more of its team members that would jeopardize a set of tasks and create many more tasks at risk, the PIC module can broadcast a message to healthcare facilities HF1, HF3, and HF4 to advise them of its current situation. Any or all of healthcare facilities HF1, HF3, and HF4 can respond (via their PIC module) as to whether they have sufficient cognitive capacity to handle offloaded tasks from healthcare facility HF2. Healthcare facility HF2 can offload tasks to one or more of healthcare facilities HF1, HF3, and HF4 that indicate they have cognitive capacity to handle the offloaded tasks. Healthcare facilities HF1, HF3, and HF4 can coordinate how much cognitive capacity they have available, and whether they can handle the offloaded tasks alone, or require additional cognitive capacity from one of the remaining healthcare facilities.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the overload management system of Rajasenan and Sampath to update the trained machine-learning model of Yang based on responses received through the server interface. Yang teaches training a machine learning model using extracted features and outcomes and further teaches that the existing model is sequentially updated as additional data becomes available using a sliding-window approach. Rajasenan teaches communicating overload conditions and receiving responses regarding available cognitive capacity before task redistribution, while Sampath teaches presenting prompts to users through a server display interface supported by server management functionality. A person of ordinary skill in the art would have recognized that the responses received through Sampath's prompt interface regarding Rajasenan's overload determination constitute additional outcome information that could be incorporated into Yang's iterative model updating process to refine the predictive model over time. Doing this would have represented the predictable use of known machine learning model updating techniques to improve the accuracy of future overload determinations while using each reference according to its established purpose.
Regarding claim 99, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein reducing the frequency of transmission of further communications to the communication device comprises reducing to zero the frequency of transmission of further communications to the communication device (Rajasenan [0099] “In step 508, fungible tasks are determined to identify tasks that can provide relief an overloaded healthcare provider who reaches a tipping points. Fungible tasks are tasks that can be effectively transferred away from the person exceeding their tipping point, whether from the dimension of another person doing it, other tasks of the overloaded person, the same overloaded person doing the task at another time, the person reaching the tipping point doing the task faster and easier from another place (e.g. from home via telemedicine), or another person rescuing the task via tele-health remotely. These determinations of fungibility can be from persons stating the rules of what they can, and are willing to, transfer to others experiencing overload, or can be determined from historical data analysis that shows past transfer of certain tasks, and to whom, thus enabling us to determine how likely a task can be transferred, and to what type of role (based on the persons, like nurses, clerical staff, etc.) or specific persons.”, and
Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”, and
Rajasenan [0155] “As shown in FIG. 12C, this reallocation of tasks has the effect of fully loading provider A and bringing both provider C and provider E to within their 5-task tipping point. Moreover, the task reallocation frees provider D to perform other tasks, or to reduce staffing requirements. That is, provider A, B, C, and E each have been allocated 5 tasks, and provider D was allocated zero tasks as shown by task loads 1210, 1212, 1214, 1216, and 1218 in FIG. 12C.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the overload management system of Rajasenan such that, once an overloaded healthcare provider's tasks have been completely offloaded, the transmission of further task communications to that provider is reduced to zero. Rajasenan teaches identifying overloaded healthcare providers, determining fungible tasks for transfer to relieve overload, notifying the provider that one or more tasks have been removed following tipping point analysis), and reallocating tasks such that a provider may ultimately be assigned zero tasks. A person of ordinary skill in the art would have recognized that once a provider has no remaining assigned tasks, continuing to transmit task assignment communications would serve no useful purpose. It therefore would have been an obvious matter of design choice and system efficiency to cease transmitting further task-related communications to that provider until new tasks are assigned, thereby predictably reducing the frequency of such communications to zero while conserving communication and processing resources.
Regarding claim 100, Rajasenan, Sampath, Deluca, and Yang teach the invention in claim 89, as discussed above, and further teach wherein reducing the frequency of transmission of further communications to the communication device comprises reducing the frequency of transmission of further communications to the communication device for a period of time or until a specified time (Rajasenan [0098] “In step 506, steps 502 and 504 are repeated for each healthcare provider that might be tasked with supporting the current healthcare provider team (flexible resources). The support team comes in to save tasks at risk. But, support healthcare providers must have sufficient cognitive bandwidth to succeed in the rescue as well, so hence the need for getting their tipping point.”
Rajasenan [0099] “In step 508, fungible tasks are determined to identify tasks that can provide relief an overloaded healthcare provider who reaches a tipping points. Fungible tasks are tasks that can be effectively transferred away from the person exceeding their tipping point, whether from the dimension of another person doing it, other tasks of the overloaded person, the same overloaded person doing the task at another time, the person reaching the tipping point doing the task faster and easier from another place (e.g. from home via telemedicine), or another person rescuing the task via tele-health remotely. These determinations of fungibility can be from persons stating the rules of what they can, and are willing to, transfer to others experiencing overload, or can be determined from historical data analysis that shows past transfer of certain tasks, and to whom, thus enabling us to determine how likely a task can be transferred, and to what type of role (based on the persons, like nurses, clerical staff, etc.) or specific persons.”,
Rajasenan [0127] “Managed alerts (or messages) can be sent to healthcare providers using personal communication devices, such as smart phones, tablets, pagers, and any other personal communication device to allocate tasks in a real-time or near real-time basis to avoid tipping points. Thus, when a system according to an embodiment determines that a particular healthcare provider is to be assigned to complete a new task, a message (or alert) is sent to a personal communication device associated with the particular healthcare provider to advise him or her of the new task to be performed. Similarly, if tipping point analysis reveals that a healthcare provider has, or is about to, reach a tipping point, the system may offload one or more tasks from the healthcare provider, and notify the healthcare provider that he or she no longer has to perform those tasks via a message (or alert) sent to the personal communication device associated with the healthcare provider.”, and
Rajasenan [0136] “The system of FIGS. 7 and 8 works as healthcare facilities tend to experience cognitive overload at different times, and therefore one or more tend to have excess cognitive capacity when another is experiencing cognitive overload. Therefore, during such periods of cognitive overload, tasks can be reassigned for completion by resources in healthcare facilities having available cognitive capacity. For example, if healthcare facility HF2 experiences a period of cognitive overload, tasks being performed by HF2 resources can be reassigned to one or more healthcare facilities that have excess cognitive bandwidth, such as healthcare facility HF1. Reassigning tasks in this manner reduces the cognitive bandwidth of healthcare facility HF2 to alleviate overload, and does not require additional staff at healthcare facility HF1 that may otherwise be idle to some extent at certain times. This excess capacity can complement the other facilities that may be experiencing team member cognitive overload at that time.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the overload management system of Rajasenan such that communications directed to an overloaded healthcare provider are reduced for the duration of the overload condition or until the provider is again capable of receiving additional tasks. Rajasenan teaches identifying overloaded healthcare providers and determining fungible tasks for transfer to relieve overload, notifying providers that tasks have been offloaded following tipping point analysis), and further teaches that, during periods of cognitive overload, tasks are reassigned to other healthcare facilities having available cognitive capacity until the overload condition is alleviated. A person of ordinary skill in the art would have recognized that because communications are generated in connection with task assignments, temporarily reducing task assignments during the period of overload would predictably reduce corresponding communications until the overload condition no longer exists. Implementing such a temporary reduction would have represented a predictable use of known workload management techniques to avoid overloading communication recipients while allowing normal communications to resume once the overload condition had passed.
Claim 101 is analogous to claim 89, thus claim 101 is similarly analyzed and rejected in a manner consistent with the rejection of claim 89.
Claim 102 is analogous to claim 95, thus claim 102 is similarly analyzed and rejected in a manner consistent with the rejection of claim 95.
Claims 103-105 are analogous to claims 90-92, thus claims 103-105 are similarly analyzed and rejected in a manner consistent with the rejection of claims 90-92.
Claims 106-107 are analogous to claims 97-98, thus claims 106-107 are similarly analyzed and rejected in a manner consistent with the rejection of claims 97-98.
Claim 108 is analogous to claim 89, thus claim 108 is similarly analyzed and rejected in a manner consistent with the rejection of claim 89.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted 03/18/2026 with respect to the rejection of claims 89-108 have been carefully considered and are addressed below.
Claim Rejections - 35 USC § 101
Applicant's arguments have been fully considered but are not persuasive. Applicant states that the amended claims are analogous to those found eligible in SRI International, Inc. v. Cisco Systems, Inc., because the recited network server allegedly functions as an intermediary in the communication process or path, which improve computer network technology by monitoring communications and controlling future communication frequency. The Examiner disagrees. Unlike the claims in SRI, which were directed to a specific improvement in computer network technology through a particular network monitoring architecture and hierarchical monitoring arrangement that altered the conventional operation of the network itself, the present claims do not recite any particular communication architecture, communication protocol, or other technological implementation that improves the operation of the network or another computer technology. Instead, the independent claim broadly recites receiving communications, monitoring response times, determining whether overload factors meet an overload condition using a trained machine learning model, and reducing the frequency of future communications. These limitations are recited in functional terms and describe the result of evaluating communication responsiveness and controlling subsequent communications, without reciting a specific technological mechanism for accomplishing that result. Accordingly, the claims use generic computing components as tools to implement the abstract idea and are distinguishable from the claims found eligible in SRI.
Applicant further states that the amended claims cannot practically be performed in the human mind because the processor of the remote network server receives communications destined for the communication device and therefore functions as an intermediary in the communication process. However, the Examiner's identification of the abstract idea is not relied on the generic receipt of communications by the network server, but instead on the claimed concepts of monitoring communications and response times, evaluating whether response times exhibit a trending increase, determining whether overload factors meet an overload condition, and deciding to reduce the frequency of future communications based on that determination. These concepts constitute observations, evaluations, and judgments that, under their broadest reasonable interpretation, can practically be performed mentally or with the aid of pen and paper, while the recited network server merely automates those mental processes using generic computer components. Additionally, the recited trained machine learning model is invoked as a tool for performing the claimed evaluation and determining whether an overload condition exists. The claims do not recite any particular machine learning architecture, improvement to machine learning technology, or improvement to the functioning of the computer or communication network itself. Accordingly, the additional elements do not integrate the judicial exception into a practical application and do not amount to significantly more than the abstract idea for the reasons set forth in the rejection.
Claim Rejections - 35 USC § 103
Applicant’s arguments traversing the prior art rejection in the previous Office Action have been fully considered. However, those arguments are rendered moot because the present rejection under 35 U.S.C. §103 relies on a different set of prior art references (Rajasenan, Sampath, Deluca, and Yang), which teach or suggest the limitations of the claims. Accordingly, Applicant’s prior arguments are not responsive to the current grounds of rejection. The rejection of claims 89-108 under 35 U.S.C. §103 is therefore maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Barijough et al. (U.S. Patent Publication 2019/0044907 A1) teaches a system that dynamically selects and delivers a prioritized group of messages to a user based on the user’s cognitive load, readiness, and a cognitive load threshold to avoid overloading the user.
Gumbel et al. (U.S. Patent Publication US 2022/0084663 A1) teaches methods for managing care provider coverage in a medical communication system by enabling a first user to request coverage for a defined period, obtaining acceptance from a second user, and automatically routing messages intended for the first user to the second user during the coverage period.
Arena et al. (U.S. Patent Publication US 2018/0150604 A1) teaches a system and method for assigning nursing scores to patient related tasks based on healthcare needs to optimize patient distribution and workload among care workers.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYRA R LAGOY whose telephone number is (703)756-1773. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kambiz Abdi can be reached at (571)272-6702. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.R.L./Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685
Prosecution Insights