DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 7-12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Sutaria; Saheel et al. (US 20240099624 A1) in view of Ghosh; Abin et al. (US 20260108173 A1) in view of Rock; Eric (US 20140297301 A1).
Regarding claim 1, Sutaria discloses a urinary catheter system (¶ [0013], a Foley type catheter for sensing physiologic data from the bladder and/or urinary tract of a patient; ¶ [0025] A Sensing Foley catheter system; ¶ [0121] FIG. 1 shows an embodiment of a sensing Foley catheter; ¶ [0122], catheter 102);
comprising: a catheter with a urinary catheter tube with a lumen, a proximal end; a distal end (¶ [0122], catheter 102 … A urine drainage lumen has a distal opening or openings 106 that resides in the bladder portion of the catheter; ¶ [0148] FIG. 10A shows an embodiment of the sensing Foley catheter; ¶ [0149] Sensing Foley catheter 1000 is similar to the sensing Foley catheter shown in FIG. 1 … Urine drainage tube 1001); and
a balloon coupled to proximal end, the balloon configured to be positioned in an interior of a bladder (¶ [0122], bladder retention balloon 104);
the catheter tube configured to provide flow of urine from bladder through the catheter lumen (¶ [0122], an opening at the proximal end 114 of the catheter);
a drainage bag configured for collecting urine from the bladder through the catheter lumen (¶ [0149], fluid collection bag 1020);
the drainage bag having an inlet port for receiving urine (¶ [0152], Active pinch valve 1132 is designed to connect to the outflow tubing of the cassette);
the urinary catheter tube including the proximal end, having a plurality of urine draining holes that receive urine from bladder and allow urine to be transported though the urinary catheter tube to the drainage bag; one or more sensors positioned in an interior of the catheter tube and positioned to be in contact with patient’s urine (¶ [0122], A urine drainage lumen has a distal opening or openings 106 that resides in the bladder portion of the catheter, and has an opening at the proximal end 114 of the catheter);
the one or more sensors providing sensor data relative to a health of a patient (¶ [0247] FIG. 26 shows an embodiment of a loop controller in a patient environment. In this example, the loop controller is receiving patient parameter input from sensing Foley catheter 2602 … the sensing Foley catheter may include other sensors as disclosed herein; ¶ [0316] Pulse oximetry elements … may be disposed anywhere along the urethral length of the catheter. In some embodiments, the sensor or sensors are disposed within the tubing of the device; ¶ [0487] Some embodiments of the sensing Foley system may incorporate comprehensive “smart” sensing; ¶ [0491] Capacitance of tissue and/or urine, via electrodes in contact with the urethra, bladder; ¶ [0492] Conductivity of tissue and/or urine, via electrodes in contact with the urethra, bladder, skin, or placed within the reservoir/cassette in contact with urine; ¶ [0493] Chemical analysis of urine, via sensors within the catheter and/or drainage tube, or within the monitor/cassette. Some examples include Albumen, Bilirubin, Red Cells, Hemogolbin, Myoglobin, Hemolosis, PH of urine, Bile, Urea, Sodium, Potassium, Calcium, Creatinine);
the sensor data containing one or more of missing values, duplicate records, and formatting errors (¶ [0336] Some embodiments of the sensing Foley catheter system include the controller filtering the urine output data to compensate for increased urine output immediately following the administering of a diuretic. Urine output generally increases immediately following the administration of a diuretic. However in certain situations it is beneficial to essentially ignore the increased urine output data associated with administration of a diuretic. The controller of the sensing Foley catheter system can automatically ignore the urine output data associated with the administration of a diuretic by identifying the shape of the urine output curve associated with the administration of a diuretic, and subtracting and/or ignoring the data associated with this increase; ¶ [0383] In some embodiments, a sensor on the bed, patient, within the sensing Foley catheter system or elsewhere senses when the patient is supine or not supine. Pressure measured within the bladder will increase when the patient is not supine and may adversely affect the data for analysis by the controller. As a result, the controller may ignore pressure data collected while the patient is not supine, or stop collecting pressure data during this time. Alternatively, the pressure measurements themselves may be used to sense when a patient is not supine);
an artificial intelligence system including an AI system with an AI engine, a plurality of machine learning algorithms used with a machine learning model (¶ [0258] FIG. 30 … Loop controller 2628 can receive one or more patient parameter inputs … This analysis may be performed in loop controller 2628 or in a separate controller; ¶ [0282], By utilizing real time multivariate (point value) and times series (trending) analyses of these high frequency data streams to inform our machine learning-powered model, a highly sensitive physiologic signature for early sepsis onset … may be developed … The signatures relating to the data relating to the physiologic changes that occur prior to and/or during the onset of certain medical conditions can be continuously improved using machine learning via artificial neural networks to strengthen the relevant parameters, weaken the less relevant parameters and build or destroy connections; ¶ [0323] FIG. 33 is a block diagram of a data processing system, which may be used with any embodiment of the invention. For example, the system 3300 may be used as part of a controller as shown in several embodiments herein; ¶ [0422] In addition, the sensing Foley catheter system can use different algorithms, or improve upon existing algorithms to predict or identify patient conditions; ¶ [0424] FIGS. 55B-55E show additional examples of possible methods of predicting risk of kidney injury earlier than the RIFLE criteria);
the machine learning model processing the sensor data to distinguish between clean and noisy data of the sensor data, allowing for the removal of one or more noisy data points from a sensor data dataset, the clean sensor data having with a reduction of one or more of missing values, duplicate records, and formatting errors (¶ [0167], one or more algorithms performed by the analyte monitoring system 1 … may have one or more of an improved calibration algorithm, improved accuracy, an improved denoise algorithm, and improved prediction. In some embodiments, the analyte monitoring system 1 may additionally or alternatively may be configured for improved handling of missing values, which the analyte monitoring system 1 (e.g., the transmitter 101 of the analyte monitoring system 1) may save as NaN (Not A Number); ¶ [0169] Some embodiments may be applied to an analyte monitoring system 1 having one or more of CGM data that noisy and/or contains a large number of missing values (identified as NaN) (e.g., due to transmitter 101 charging); ¶ [0170] In some embodiments, the analyte monitoring system 1 may use one or more digital filtering techniques (e.g., Kalman Filter) to enhance the quality of the signal and reduce the random noise component of the error. In some non-limiting embodiments, to reduce the noise and compensate for the presence of missing values, the analyte monitoring system 1 may apply an on-line Kalman Filter (KF); ¶ [0181] The data contains a large number of missing values, identified as NaN, due to transmitter 101 charging. In some embodiments, to reduce the noise and to compensate the presence of missing values, the analyte monitoring system 1 may use an approach developed within a Bayesian estimation embedding for the online denoising of CGM signals; ¶ [0191] In some embodiments, with respect to missing values, the analyte monitoring system 1 may take care to evaluate the parameters in a time window without NaN); and
in response to the analysis of the clean sensor data by the machine learning algorithms make recommendations relative to a health of a patient (¶ [0218], For example, sensor(s) to detect Magnesium in the urine may be used to diagnose preeclampsia or eclampsia. Lactate sensors … The identification of lactate in urine may be an early indicator of sepsis; ¶ [0258] FIG. 30 … Loop controller 2628 can receive one or more patient parameter inputs from a sensing Foley catheter or other device … Pressure profile info from the bladder can be further analyzed to determine IAP, respiratory rate, heart rate, stroke volume, sepsis index, acute kidney injury (AKI) index and other patient parameters; ¶ [0282] The sensing Foley catheter system provides real-time, automatic, precise physiological parameter monitoring for the early detection of various medical conditions. By utilizing real time multivariate (point value) and times series (trending) analyses of these high frequency data streams to inform our machine learning-powered model, a highly sensitive physiologic signature for early sepsis onset … may be developed; ¶ [0291] In addition to detecting AKI, the present invention is capable of detecting urinary tract infections (UTIs), as indicated by decreasing oxygen tension, carbon dioxide levels, increasing specific gravity, and relatively stable urine output and conductance; ¶ [0309], In predicting sepsis, embodiments of the invention may be capable of receiving white blood cell count information to better predict sepsis; ¶ [0320], For example, certain trends in temperature alone, or in combination with other parameters, may be a predictor of infection, the onset of sepsis, ARDS and/or AKI. FIG. 31 shows some known examples; ¶ [0424] FIGS. 55B-55E show additional examples of possible methods of predicting risk of kidney injury earlier than the RIFLE criteria; ¶ [0470] FIGS. 65A-D … ability to measure osmolality of urine, which can be used to diagnose or predict or monitor certain health conditions);
the AI system splitting the sensor data into a training set and a testing set with the training used to train and the testing set for analysis of the sensor data (¶ [0246], In the ideal scenario these parameters may be used by the loop controller to monitor and control therapies in a manner that is informed by machine learning and algorithmic tuning; ¶ [0282], The signatures relating to the data relating to the physiologic changes that occur prior to and/or during the onset of certain medical conditions can be continuously improved using machine learning via artificial neural networks to strengthen the relevant parameters, weaken the less relevant parameters and build or destroy connections; ¶ [0518] FIG. 74 shows an embodiment of the sensing Foley system which includes the ability to monitor IAP non-invasively ¶ [0519], this way, controller 1018 “learns” how to interpret the data from sensors 7402 and correlate it with actual IAP.; ¶ [0522] FIG. 75 shows a system similar to that shown in FIG. 74 …. Controller 1018 receives the image signal 7504 from camera 7502 and analyzes the signal … This is done over a training period, similar to the system shown in FIG. 74, and after the training period, the sensing Foley catheter may be removed and IAP may continue to be monitored via camera 7502 and patches 7503);
the AI system including cryptography algorithms (¶ [0446] The various connected devices may be automatically sensed via Bluetooth); and
a remote patient monitoring system coupled to the sensors, and including one or more dashboards with interfaces for a care provider to monitor multiple patients with multiple patient data simultaneously while maintaining a separateness of the multiple patient data (¶ [0225], A display may show information relating to an individual patient, and/or it may show information relating to more than one patient, for example, at a nurses station. The display may show several patients' data separately, or may show aggregate data from more than one patient; ¶ [0527] FIGS. 77A-77H show icons which represent a patient's status or health in various areas. The icon, or graphic, may be shown on the display of the monitor/controller, and/or may be shown on a smartphone, table, remote or local computer screen etc.); and
a centralized data repository coupled to the remote patient monitoring system configured to receive the multiple patient data (¶ [0160], The patient data may be transferred wirelessly or by wired connection to another storage device, such as a server on the internet or an intranet); and
one or more remote access tools coupled to the remote patient monitoring system providing secure remote access to patient data and systems (¶ [0225], However, the display, or components of the display, or an aggregate display may additionally or alternatively be shown on a computer, mobile computer, mobile phone, tablet, separate monitor/screen etc.; ¶ [0439] The screen shown in FIG. 57A is for a particular patient … This screen shows 3 viewing options: fluid balance, vitals and risk index. These viewing options may be chosen by clicking tab 5702, tab 5704 or 5706 respectively … Also shown on this screen is the various state and some settings for the different types of devices which may or may not be connected to the patient; ¶ [0449] The risk area of the display may show risk of various medical conditions based on some or all of the data collected from the sensing Foley catheter system and/or other devices. For example, AKI risk, sepsis risk, and other risk may be assessed by the controller and displayed here; ¶ [0527] FIGS. 77A-77H show icons which represent a patient's status or health in various areas. The icon, or graphic, may be shown on the display of the monitor/controller, and/or may be shown on a smartphone, table, remote or local computer screen etc.).
Regarding the AI system splitting the sensor data into training and testing sets, Sutaria discloses a machine learning model (¶ [0282], machine learning via artificial neural networks). This implies that the system undergoes a training phase where it reviews a labeled testing set. For example, during a training phase for a neural network model, the model reviews a training set and updates its internal parameters or weights such that a loss function is minimized.
Sutaria does not explicitly disclose that:
the machine learning model uses constructive learning to train the machine learning model with labeled data;
the AI system includes cryptography algorithms that encrypt data and allow for secure communication during transit; or
the centralized data repository is accessible by each of a health care provider.
Ghosh discloses a method and system for assessing cardiorespiratory health (¶ [0003], [0006], [0035]);
comprising one or more sensors providing sensor data relative to a health of a patient (¶ [0035], FIG. 1, at step 102, mechanical movement data associated with a torso of a subject's body is generated using a plurality of ballistocardiography (BCG) sensors; ¶ [0036], The plurality of BCG sensors may include (not limited to) force-sensitive resistors, accelerometers, piezoelectric sensors, strain gauges, or pressure-sensitive transducers);
the sensor data containing one or more of missing values, duplicate records, and formatting errors (¶ [0107], In this regard, the term “noise data segments” refers to portions of the mechanical movement data that contain signal artifacts … primarily caused by large-scale non-breathing movements, including shifting positions during sleep, limb movements, bed exits, or external vibrations affecting the plurality of BCG sensors. For instance, if the subject momentarily shifts their body position or adjusts their posture);
an artificial intelligence system including a machine learning algorithm used with a machine learning model (¶ [0095] employing a machine learning model; ¶ [0107], employing an unsupervised learning model or employing a supervised learning model; ¶ [0130] In an embodiment, the processing unit processor is configured to employ a machine learning model);
the machine learning model processing the sensor data using constructive learning to train the machine learning model to distinguish between clean and noisy data of the sensor data, and uses labeled data with a known noise level to classify the sensor data as either clean or noisy, allowing for the removal of one or more noisy data points from a sensor data dataset, the clean sensor data having with a reduction of one or more of missing values, duplicate records, and formatting errors (¶ [0108], Alternatively, the method can employ the supervised learning model, such as a neural network or a binary classifier (e.g., support vector machines (SVM) or decision trees) trained on labelled datasets of clean and noisy mechanical movement data. The supervised models use pre-existing data annotations to differentiate between valid respiratory and cardiac signals and noise data, ensuring that only meaningful physiological signals are retained for analysis by removing the noise data segments from the mechanical movement data); and
in response to the analysis of the clean sensor data by the machine learning algorithms make recommendations relative to a health of a patient (¶ [0112], In this regard, the term “alert” refers to an automated notification … The user interacts with the system through alerts, reports, and real-time respiratory insights, enabling self-monitoring and early awareness of potential breathing abnormalities; ¶ [0114] Further, providing detailed reports to the medical professional to assist in diagnosis and treatment planning … comprehensive respiratory data for clinical review);
the AI system splitting the sensor data into a training set and a testing set with the training used to train and the testing set for analysis of the sensor data (¶ [0130] In an embodiment, the processing unit processor is configured to employ a machine learning model trained on labelled datasets of breathing patterns to classify normal and abnormal breathing patterns … the processor 204 is configured to employ a machine learning model);
the AI system including cryptography algorithms that encrypt at least a portion of one or more of the sensor data, and the clean sensor data, making it unreadable to unauthorized users and allowing for secure communication of the at least a portion of the sensor data, and the clean sensor data during transit (¶ [0119], The secure platform may be a cloud-based portal, encrypted local server, or mobile application … The secure platform incorporates access controls, encryption protocols, authentication mechanisms, and compliance with medical data protection standards (e.g., HIPAA, GDPR) to prevent unauthorized access or data breaches); and
a remote patient monitoring system coupled to the sensors, and including one or more dashboards with interfaces for a care provider to monitor a patient (¶ [0128], The user interface 206 is at least one of: a smartphone application, a tablet, a desktop dashboard, or an integrated hospital monitoring system, allowing both the subject 202A and the medical professionals to access real-time respiratory insights).
Ghosh explains details of how to train a machine learning model, and also describes how to securely transmit healthcare data with known algorithms. One would be motivated to modify Sutaria with Ghosh’s labeled training data and encrypted transmission algorithms since Sutaria calls for machine learning algorithms (¶ [0246], [0282], [0323], [0422] [0519], [0522]); and also calls for transmitting sensitive data (¶ [0225], A display may show information relating to an individual patient, and/or it may show information relating to more than one patient, for example, at a nurses station). A skilled artisan would have been able to modify Sutaria with Ghosh’s labeled training data and encrypted transmission algorithms by training Sutaria’s model with a labeled training data set, and by encrypting data before transmitting it. Therefore, it would have been obvious to modify Sutaria with Ghosh’s labeled training data and encrypted transmission algorithms in order to train a machine learning model and safeguard patients’ data.
Sutaria and Ghosh do not explicitly disclose that the centralized data repository is accessible by each of a health care provider for a patient being monitored by the remote patient monitoring system. Rock discloses a system and method for integrating healthcare delivery (¶ [0006], [0042], [0117] The present invention may be summarized as depicted in the system block diagram of FIG. 3 (0300));
comprising: a device including one or more sensors, the one or more sensors providing sensor data relative to a health of a patient (¶ [0118], real-time patient information collected from remote monitoring devices (RMD); ¶ [0125] (3) Integrating remote patient monitoring (RPM) data from mobile patient monitoring devices; ¶ [0194] (11) Collecting medical instrument device (MID) data … under direction of the PHP (1411); ¶ [0201], As depicted in FIG. 17 (1700), the healthcare web server (1710) … maintains a patient PHP database in which healthcare plans for a variety of patients are maintained … The PHP scripting engine (1722) interacts with medical instrumentation devices (MID) (1723); ¶ [0219], a MUD healthcare delivery foreground method as depicted in FIG. 19 (1900) that services data and alert transfers to the HWS from the medical instrument devices (MID); ¶ [0245] The data structure as depicted in FIG. 21 (2100)-FIG. 24 (2400) … may include (but are not limited to) items such as … medical instrumentation device monitoring (2350); ¶ [0249] The PHP anticipates that a variety of medical instrumentation device data may be collected including but not limited to weight (2351), blood pressure (2352), pulse oximeter (2353), glucometer (2354), or other medical instrumentation (EKG, etc.) (2355));
an electronic system including cryptography algorithms that encrypt at least a portion of one or more of the sensor data, making it unreadable to unauthorized users and allowing for secure communication of the at least a portion of the sensor data during transit (¶ [0135] Healthcare Web Server (HWS) (0550). This coordinating computer interface (also termed a healthcare computing device (HCD)) provides for a protected interface to secure transaction services (STS) (0551) that acts to coordinate data transfers between the various other system components to permit seamless integration of real-time patient medical data (0520) and healthcare plans among the healthcare providers (0530) and hospitals (0540) … Healthcare providers (0531) interact with the HWS (0550) through a secure communication channel (0556) using one or more web applications (0557) that access SQL reporting processes (0558)); and
a remote patient monitoring system coupled to the sensors, and including one or more dashboards with interfaces for a care provider to monitor multiple patients with multiple patient data simultaneously while maintaining a separateness of the multiple patient data (¶ [0118] A core concept in this architecture is that the PHP (0350) is configurable by healthcare providers from the hospital (0310) or other medical facility care management team members to continually drive real-time healthcare dashboard status information to authorized healthcare provider recipients; ¶ [0279] Examples of MID device configuration and MID alert definition dialogs used to create alerts within the PHP-driven healthcare plan are depicted in FIG. 45 (4500)-FIG. 50 (5000) and depict weight scale, pulse oximeter, blood pressure, and glucometer dialog configuration menus respectively);
a centralized data repository coupled to the remote patient monitoring system configured to receive the multiple patient data (¶ [0117], healthcare web server (HWS) (0340); ¶ [0151], a healthcare web server (0730) responsible for integrating in-patient and out-patient healthcare delivery to the patient (0703); ¶ [0163], the system data flow depicted in FIG. 9 (0900). Here the healthcare web server (HWS) (0910) interacts with the mobile user device (0920) to collect medical data (0921) from a patient (0922); ¶ [0201], As depicted in FIG. 17 (1700), the healthcare web server (1710));
the centralized data repository being accessible by each of a health care provider for a patient being monitored by the remote patient monitoring system (¶ [0118], By providing a healthcare web server (HWS) (0340) incorporating web portals accessible by the authorized healthcare providers, the system as depicted permits a unified patient healthcare plan (PHP) (0350) to act as the driver for the delivery of healthcare to the patient as well as the hub for reporting patient status to all interested and authorized healthcare professionals servicing the patient; ¶ [[0163], Here the healthcare web server (HWS) (0910) interacts with the mobile user device (0920) … This data is continuously collected and monitored by the HWS (0910) in a patient healthcare monitoring process (0911) that updates patient medical records (0912) that are distributed to various healthcare providers/hospitals as directed by the patient healthcare plan (PHP));
one or more remote access tools coupled to the remote patient monitoring system providing secure remote access to patient data and systems (¶ [0119], This permits the care management team or other healthcare providers to have a real-time risk stratification dashboard (0316); ¶ [0127] (5) Displaying risk stratification dashboards in real-time to trigger healthcare provider activity on specific patients (0405); ¶ [0150], enable the care management team (0701, 0702) to view on dashboards a real-time status of the medical state of the patient (0703); ¶ [0199] (16) Displaying a real-time status dashboard prioritizing at-risk patients and indicating alerts associated with high-risk patients (this may occur in the context of a HIS dashboard display, a web page presented using a conventional web browser, and/or other electronic communication methodologies) (1416); ¶ [0261] A screenshot of an exemplary HWS main browser interface is depicted in FIG. 27 (2700); ¶ [0262] FIG. 28 (2800)-FIG. 32 (3200) provide additional detail on exemplary patient definition dialogs that may be employed by the HWS to permit health caregivers the ability to both define patients in the system and define alerts associated with the patient; ¶ [0267] As depicted in FIG. 41 (4100), the PHP may be constructed by the healthcare provider using a graphical user interface (GUI) as a hierarchy of patient dialogs that are triggered at certain times of the day).
Rock demonstrates how to configure a patient monitoring system so that multiple caregivers can access the patient’s data. Rock demonstrates a combination of sensor-equipped devices (Figs. 23, 45; weight scale, pulse oximeter, blood pressure, and glucometer and other devices); that generate and send data to a centralized database (Fig. 5, SQL server 0555; Fig. 7, Healthcare Web Server HWS 0730; Fig. 17, HWS 1710). Rock further enables multiple caregivers from remote locations to access the patient’s data via dashboards (Fig. 26, HWS Main Web Browser Interface 2601; Figs. 27, 30, 32, 35-51 show screenshots).
Rock coordinates care among team members (¶ [0037] (5) Provide for a healthcare delivery system and method that coordinates patient data between outside healthcare providers and the hospital HIS/EMR systems; ¶ [0124] (2) Allowing definition of a patient healthcare plan (PHP) that coordinates delivery of healthcare to a patient (0402); ¶ [0133] Caregiver Portal(s) (0530). This interface permits a healthcare provider (0531) (healthcare specialist, doctor, nurse, etc.) to interact with a computer system (0532) … This information also permits a coordinated patient healthcare plan (PHP) to be coordinated among a number of different independently operating healthcare providers (0531)). One would be motivated to modify Sutaria and Ghosh with Rock’s centralized data repository and remote access tools since Sutaria calls for integrating the catheter with an Electronic Health Records or Electronic Medical Records system (¶ [0162] Port 1108 is for downloads, uploads, software upgrades, connecting to other devices etc., such as integration with an EMR (Electronic Medical Record) system; ¶ [0262], Loop controller 2628 may also provide output to other systems for system integration, such as outputting information to an Electronic Health Record (EHR) or other data archiving system, or other systems; ¶ [0321] Data collected by the sensing Foley catheter system may be integrated with Electronic Health Records (EHRs) or Electronic Medical Records (EMRs) and/or other systems; ¶ [0421], The patient's weight and/or other patient data may be received by the system controller via manual user input, integration with other hardware, such as a scale, integration with electronic health or medical records, transmitted wirelessly, or by other means).
A skilled artisan would have been able to modify Sutaria and Ghosh with Rock’s accessible, centralized data repository by configuring Sutaria’s remote patient monitoring system to deliver data to multiple users according to Rock’s example. Therefore, it would have been obvious to modify and Ghosh with Rock’s accessible, centralized data repository and remote access tools in order to more effectively coordinate care among caregivers.
Regarding claims 2-3, 7-12 and 14, Sutaria discloses a system wherein the remote patient monitoring system is configured to receive clean sensor data from the multiple patients (¶ [0225], A display may show information relating to an individual patient, and/or it may show information relating to more than one patient, for example, at a nurses station. The display may show several patients' data separately, or may show aggregate data from more than one patient; ¶ [0320], For example, data may be collected from several patients and aggregated anonymously to be used to better treat, monitor, or predict the behavior of future patients);
wherein maintaining a separateness of incoming patient data for the multiple patients is separated, organized, and managed (¶ [0320], For example, data may be collected from several patients and aggregated anonymously to be used to better treat, monitor, or predict the behavior of future patients);
wherein patient data is communicated to the remote patient monitoring system through one or more wireless communications (¶ [0258], This analysis may be performed in loop controller 2628 or in a separate controller which is connected to loop controller either by a wired or wireless connection. The connection may be via an internet, intranet, WAN, LAN or other network, or it may be local via Bluetooth, Wi-Fi, etc.);
further including a data repository coupled to or included with the remote patient monitoring system (¶ [0320] Data collected by the sensing Foley catheter system may be stored in a database and analyzed for trending or other uses; ¶ [0326] While FIG. 33 shows that the non-volatile memory is a local device coupled directly to the rest of the components in the data processing system );
wherein at a least a portion of the multiple patient data is coupled to a local data storage system (¶ [0325], The non-volatile memory 3306 is typically a magnetic hard drive, a magnetic optical drive, an optical drive, or a DVD RAM or other type of memory system which maintains data even after power is removed from the system; ¶ [0326] While FIG. 33 shows that the non-volatile memory is a local device coupled directly to the rest of the components in the data processing system);
where the remote patient monitoring system is coupled to a healthcare infrastructure (¶ [0225], A display may show information … for example, at a nurses station);
wherein the remote patient monitoring system is coupled to or includes diagnostic application software (¶ [0218], For example, sensor(s) to detect Magnesium in the urine may be used to diagnose preeclampsia or eclampsia. Lactate sensors may be used to test for lactate … lactate in urine may be an early indicator of sepsis; ¶ [0264] Further medical diagnoses may also be performed based on the results of the sensing Foley catheter system);
wherein the remote patient monitoring system provides alerts in response to the multiple patient data (¶ [0246], This IAP, tissue oxygenation and/or respiratory rate may be used to alert the provider to a worsening of the patient's condition; ¶ [0260], fluid infusion can be tailored based on intraabdominal pressure to prevent abdominal compartment syndrome by sounding an alert and slowing infusion rates as the intraabdominal pressure rises; ¶ [0262] In addition to directly controlling medical treatment device(s), loop controller 2628 may also sound alarms, including audible alarms, emailed alarms, texted alarms, pager alarms, etc.; ¶ [0291] In addition to detecting AKI, the present invention is capable of detecting urinary tract infections (UTIs) … The UTI fingerprint can alert clinicians to the presence of UTI; ¶ [0301] The present invention can be used in a variety of hospital settings … Its algorithms work to alert clinicians to a newly developed case of AKI or to a change in the status of AKI);
wherein accesses control to the remote patient monitoring system uses one of more of: role-based attribute-attribute based access control (ABAC), multi-factor authentication (MFA) and a remote access tool (¶ [0225], A tablet, phone or other device may be synched with a controller by proximity, using RFID, etc. A display may show information … for example, at a nurses station).
Claims 4-6, 13 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sutaria, Ghosh and Rock in view of Aunger; Charles Edward George Keith et al. (US 20230377740 A1).
Regarding claims 4-6 and 13, Sutaria, Ghosh and Rock do not explicitly disclose a PIM process or unique identifiers for each patient or an API. Aunger discloses graphical user interfaces (GUIs) for a digital healthcare platform (¶ [0003], [0018], [0030] FIG. 2 … digital healthcare framework 200);
comprising one or more sensors providing sensor data relative to a health of a patient (¶ [0035] Physiological data is measured (via one or more sensors on device 202) at the client-side (i.e., the patient side));
a dashboard (¶ [0050] FIG. 3 depicts examples of custom interfaces that are presented to a physician … Accordingly, it is beneficial for a physician to see the dashboard as depicted in FIG. 3);
wherein incoming patient data for multiple patients is separated, organized, and managed through one or more patient identity management (PIM) processes; wherein the remote patient monitoring system includes or is coupled to one or more data management systems that assigns unique identifiers to each of a patient; wherein the remote patient monitoring system includes or is coupled to one or more data management systems that assigns unique identifiers to each of a patient, and provides that information from multiple patients not integrated together but is maintained separately (¶ [0035] Physiological data is measured (via one or more sensors on device 202) at the client-side (i.e., the patient side), and context information such as unique device ID 210 and unique user ID 208 are added to such physiological data, where collected data is enhanced with context information; ¶ [0038], For example, sensor data transmitted from a smartwatch device (which falls under the category of a device that is not clinically validated) may still provide additional context for the patient; ¶ [0072], each datum in the plurality of annotated physiological sensor data comprising a unique device identifier (UDI) identifying a medical device component associated with the annotated physiological sensor data, and a unique user identifier (UUI) uniquely identifying a user of the medical device component);
wherein each of the one or more dashboards includes an application programming interface (¶ [0043] The data distribution gateway 206 one or more APIs 232, logging component 238, and an event logs storage 234 … The APIs 232 allow for appropriate external parties to access the event logs storage 234).
To clarify, Aunger’s various identifiers are interpreted as analogous to both the PIM process and unique identifiers, because claims 4-6 depend in parallel on claim 1.
Aunger reliably distinguishes multiple patients in an electronic healthcare records system in order to organize the patients’ data and also to control access to the data (¶ [0046], For example, if the user is a patient, a set of custom interfaces may be provided by the user-specific literacy interpretation component 240 of the data distribution gateway 206, and if the user is a physician, another set of custom interfaces may be provided by the user-specific literacy interpretation component 240 of the data distribution gateway 206; ¶ [0050], FIG. 3 shows a view of the entire population of patients associated with the physician that is authorized to view this data). One would be motivated to modify Sutaria, Ghosh and Rock with Aunger’s unique patient identifiers since Sutaria calls for a dashboard that displays multiple patients’ data (¶ [0225]). Therefore, it would have been obvious to modify Sutaria, Ghosh and Rock with Aunger’s unique patient identifiers in order to organize and safeguard data from multiple patients.
Aunger’s API allows remote access through a widely recognized format (¶ [0043], The APIs 232 allow for appropriate external parties to access the event logs storage 234). One would be motivated to modify Sutaria, Ghosh and Rock with Aunger’s API in order for users to conveniently access the data.
Regarding claims 15-17 and 20, Sutaria, Ghosh and Rock do not explicitly disclose that the system enters billing-related information. Aunger discloses a system wherein the remote patient monitoring system is used for entering patient monitoring billing; wherein the patient billing information is used for charging one or more of insurance carriers, government agencies and patients (¶ [0049] A myriad of users may access data distribution gateway component 206 … patients, providers, clearinghouses, payors, digital payment systems, healthcare regulators, health surveillance personnel and systems);
wherein the patient monitoring billing used one or more CMS codes (¶ [0009], Accordingly, the time the clinician spends reviewing the data and/or talking with the patient is billable through a central location such as the Centers for Medicare and Medicaid Services (CMS); ¶ [0012] Another important code is the International Classification of Diseases (ICD©) code … Such ICD-11© codes may be stored in an ICD-11© codes database 114; ¶ [0070] Additionally, the summary portion of the patient dashboard includes … It may also show, under different CPT® codes (e.g., 99454, 99457), how much time the doctor has spent with the patient (e.g., it may note that the physician has reached 18 minutes));
wherein the remote patient monitoring system is updated though a cloud platform (¶ [0041] It should be noted that the dynamic nature of the coordination gateway component 204 allows for a real-time check on a device's clinical validation status or regulatory compliance status as such a real-time check is just a service call to another website or remote server).
Aunger’s billing-related interface and CMS codes allow caregivers to more conveniently enter data associated with each patient. One would be motivated to modify Sutaria, Ghosh and Rock with Aunger’s billing-related interface and CMS codes in order for caregivers to enter all of a patient’s data through a single interface.
Therefore, it would have been obvious to modify Sutaria, Ghosh and Rock with Aunger’s billing-related interface and CMS codes in order for caregivers to more conveniently enter data for each patient.
Regarding claims 18 and 19, Sutaria, Ghosh, Rock and Aunger do not explicitly disclose that patient monitoring billing is entered to a computer at the remote monitoring system or that the remote patient monitoring system is used for registering the multiple patients. However, Sutaria discloses a mobile application (¶ [0225]); and Aunger discloses a system that handles billing information (¶ [0009], [0012], [0049], [0070]). In order for the system to accommodate new patients, it must create a new entry for each new patient with details such as their name, address and phone number along with notes and billing information. Aunger depicts a dashboard that lists patients and their information (Fig. 5), along with a dashboard for an individual patient (Fig. 6). This implies that each patient must have been added or registered as a new entry.
Response to Arguments
The objections to claims 4, 5, 6, 12, 14 and 17 for minor informalities and the rejection of claim 1 under 35 USC § 112 are withdrawn in view of the amendments filed 08 September 2026.
Applicant’s arguments filed 08 September 2026 regarding the rejection of claims 1-20 as amended, under 35 USC § 103 over Sutaria, Ghosh and Aunger, have been fully considered and are persuasive. After further consideration, the amended claims are rejected on new grounds under 35 USC § 103 over Sutaria, Ghosh, Rock and Aunger (see above).
Applicant submits that unlike the present invention, Sutaria fails to disclose a remote patient monitoring system coupled to sensors, and including one or more dashboards with interfaces for a care provider to monitor multiple patients with multiple patient data simultaneously while maintaining a separateness of the multiple patient data; a centralized data repository coupled to the remote patient monitoring system configured to receive the multiple patient data; the centralized data repository being accessible by each of a health care provider for a patient being monitored by the remote patient monitoring system; and one or more remote access tools coupled to the remote patient monitoring system providing secure remote access to patient data and systems (remarks p. 7). Examiner responds that Sutaria explicitly discloses a dashboard for monitoring patients (¶ [0438] FIGS. 57A-57C show example screenshots for embodiments disclosed herein; ¶ [0439] The screen shown in FIG. 57A is for a particular patient). Sutaria further discloses a centralized data repository (¶ [0160], The patient data may be transferred wirelessly or by wired connection to another storage device, such as a server on the internet or an intranet; ¶ [0464], As with any of the embodiments disclosed herein, the data from the weight controller may be transmitted remotely and aggregated, analyzed, etc on a computer server, and/or communicated to various users).
Examiner responds that Sutaria is deficient only by not explicitly disclosing the following features:
the machine learning model uses constructive learning to train the machine learning model with labeled data;
the AI system includes cryptography algorithms that encrypt data and allow for secure communication during transit; and
the centralized data repository being accessible by each of a health care provider.
Applicant asserts that Ghosh and Aunger fail to remedy the deficiencies of Sutaria (remarks p. 8-9). Examiner notes that Rock is cited in the new grounds of rejection as teaching a centralized data repository that can be accessed by multiple health care providers, along with tools, dashboards and interfaces for accessing the repository.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Durrell; Deborah J. et al. US 20070187478 A1
Higgins; Michael S. et al. US 20090054735 A1
Spivey; John M. et al. US 20090132287 A1
Stein; Jason et al. US 20120029932 A1
Killen; Roger et al. US 20120136221 A1
Ryan; Hugh H. et al. US 20150227717 A1
Barkol; Omer et al. US 20190355447 A1
Wilkerson; Benjamin David et al. US 20200265362 A1
Winlo; Michael et al. US 11302426 B1
Subramanian; Sanjay et al. US 20220199267 A1
Kayser; Susan et al. US 20220323715 A1
Toleti; Raj et al. US 20230045394 A1
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to:
Tel 571-272-2590
Fax 571-273-2590
Email Adam.Marcetich@uspto.gov
The Examiner can be reached 8am-4pm Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rebecca Eisenberg can be reached at 571-270-5879. The fax phone number for the organization where this application is assigned is 571-273-8300.
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.
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.
/Adam Marcetich/
Primary Examiner, Art Unit 3781
