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 .
Status of Amendments
Claims 1-9 and 21-24 are currently pending in this case and have been examined and addressed below. This communication is a Final Rejection in response to the Amendment to the Claims and Remarks filed on 12/10/2025.
Claim 1 and 23-24 is an amended claim.
Claims 2-3 and 9 are original claims.
Claims 4-8 and 21- 22 are previously presented.
Claims 10-20 have been cancelled and will not be considered at this time.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1, 3-6, 8-9, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazar (US 20150302539 A1) in view of Yu (US 20110112862 A1) in view of Banet (US 20110066062 A1).
As per Claim 1, Mazar teaches a computer system for securing vital sign measurement data and configuring the vital sign measurement data for accessibility by a remote system to enable remote monitoring of one or more patient vital signs, the computer system being communicatively coupled to one or more wearable vital sign monitoring devices, wherein the one or more wearable vital sign monitoring devices comprise a chest device and a limb device each having one or more position sensors, the computer system comprising: ([Para. 0009] Patient worn sensors can track vital sign information such as blood pressure, body temperature, respiratory rate, blood oxygenation, heart rhythm (via ECG), heart rate, blood glucose level, and hydration levels. The sensors can also track and record additional information about patients, including patient movement (i.e. position sensor), activity, and sleep patterns. [Para. 0033] The chest sensor 102 can also include sensors for detecting bio-impedance in order to monitor hydration levels, body fat levels, or other fluid levels for the patient 104. [Para. 0035] The chest sensor 102 includes one or more accelerometers (i.e. position sensor) for detecting and recording patient motion, activity, position, and posture. [Para. 0042] Patient worn sensors included as part of the system 100 can include the wrist sensor 106.)
one or more processors; ([Para. 0252] execution by a programmable processor)
one or more hardware storage devices having stored thereon computer-executable instructions that, when executed by the one or more processors, cause the computer system to ([Para. 0252] a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by a programmable processor)
generate a unique patient identifier relating to a patient to which one or more wearable vital sign monitoring devices are associated; ([Para. 0085] one or more patient worn sensors (such as the chest sensor 102 and wrist sensor 106) (i.e. wearable vial sign monitoring devices) can be associated with the patient 104. The patient 104 can be associated with a unique patient identifier (“ID”). The patient ID can be as simple as the patient 104's name, a unique number assigned to the patient 104, a unique combination of numbers, letters, and other characters, or any other unique identifier associated with the patient 104. [Para. 0186] If the patient 104 has not previously interacted with system 100 or a related system, a new unique ID (i.e. unique patient identifier) can be assigned to the patient. [Para. 0087] When the patient worn monitors (such as the chest sensor 102 and wrist sensor 106) are initially provided to the patient 104, the patient worn sensors can be associated with the patient 104 by associating the patient worn sensors with the unique ID for the patient 104.)
receive, from the user-associated computer device, vital sign measurement data indicative of one or more vital signs of the patient as measured by the one or more wearable vital sign monitoring devices; ([Para. 0043] The chest sensor 102 can communicate with a bedside monitor 108 to convey information collected by the chest sensor 102 and/or other patient worn sensors (e.g., patient vital signs, patient activity, patient location) to the bedside monitor 108. [Para. 0044] The wrist sensor 106 also communicates with the bedside monitor 108 (e.g., through a wireless Bluetooth connection, other wireless connection, or through a wired connection). [Para. 0045] The bedside monitor 108 can allow a caregiver 110 (e.g., a nurse, doctor, orderly, physical therapist, or other caregiver) to view real-time vital signs for the patient 104, past vital signs for the patient 104, other information provided by the chest sensor 102, wrist sensor 106, and/or other patient worn sensors, or other information associated with the patient 104. For example, the bedside monitor 108 can display an ECG waveform for the patient 104 while also listing a current blood oxygenation level, blood pressure, hydration level, heart rate, respiration rate, and body temperature for the patient 104. )
and send vital sign measurement data from the vital sign measurement database to one or more remote computer systems to thereby enable remote monitoring of the one or more vital signs ([Para. 0051] Information collected by the central server (i.e. vital sign measurement database)113 can be accessed at a central server station 114. For example, a caregiver 116 or other hospital personnel can use the central server station 114 to access information for the patient 104, other patients, or other hospital or healthcare administrative functions. [Para. 0052] The central server station 114 can allow the caregiver 116 to monitor vital signs, activities, and other information for the patient 104 from a remote location. The central server station 114 can additionally allow the caregiver 116 to observe information for multiple patients within a healthcare facility or system simultaneously. All information collected by the patient worn sensors (e.g., the chest sensor 102 and the wrist sensor 106) and all information entered using the bedside monitor 108 is stored by the central server 113 and is accessible through the central server station 114. [Para. 0072] Information for the patient 104 (such as vital signs, alarm states, treatment information, biographical information, etc.) can be accessed using other devices (i.e. remote computer systems) in communication with the central server 113 and/or bedside monitor 108. )
Mazar does not explicitly teach, however Yu teaches
receive, from a user-associated computer device, patient personal information relating to the patient; ([Para.0062] The user (patient) of the network system can access the network 210 through their own client computer 202, which runs a web browser 212. Through this web interface, the healthcare user can contact the physician or provider website 214 to obtain specific health information, to appoint a doctor, or request healthcare services being offered by a particular institution, or to transmit personal health information (PHD/I) to care providers and so on.)
based on the received patient personal information, and based on the unique patient identifier, generate a patient protected information database unique to the patient to store the patient personal information, and the patient protected information database being generated at the computer system; ([Para.0062] The user (patient) of the network system can access the network 210 through their own client computer 202, which runs a web browser 212. Through this web interface, the healthcare user can contact the physician or provider website 214 to obtain specific health information, to appoint a doctor, or request healthcare services being offered by a particular institution, or to transmit personal health information (PHD/I) to care providers and so on. [Para. 0069] Providing an access identifier (i.e. unique patient identifier) and password to the authorized service provider to access the user account; generating an alliance-based identification key specifically for the user and the website. [Para. 0047] The EHR server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database that is separate from the patient PHR database 304. [Para. 0069] The user individual identification information comprises user identification, name, birthdate, home address, telephone number, photographic data, and optionally user social security number and family relationship information, and the service provider identification information comprises a provider identification code, a nationality code, a location code, and an institutional affiliation code. [Para. 0072] A patient identification datastore that is separate from the electronic health record database and storing individual identification information for the one or more patients in a physician's personal computer or portable memory device)
based on the received vital sign measurement data, and based on the unique patient identifier, generate a vital sign measurements database unique to the patient to store the vital sign measurement data, the vital sign measurements database being separate from the patient protected information database, and the vital sign measurements database being generated at the computer system, ([Para. 0008] In order to protect the privacy of patients through securing identifiable information within the database, efforts are also often made to de-identify protected identity information received or created in the course of business. De-identified records are data/information, alone or in combination with other information, that cannot readily or potentially be used to identify an individual. [Para. 0031] A dual-portal web-based system is implemented that provides healthcare related information to healthcare users through a first website, and registry/management tools to care providers through a second website. No identifiable fields relating to the user, such as name, birth date, address, e-mail address, telephone/fax number, Social Security ID, relatives and employers, is stored or accessible in the database of the first website (i.e. vital sign measurement data). All user information is de-identified by total exclusion from the database, rather than by merely stripping-out true identity information from database prior to exchange or usage. [Para. 0037] The system of FIG. 2 constitutes a dual-portal alliance system architecture in which a relationship is established between the user 202 and service provider 204 to enable storage of de-identified user information in the PHR database (i.e. vital sign measurement data). [Para. 0049] FIG. 8 illustrates the database structure 800 for a PHR web server storing de-identified patient health records. For the example of FIG. 8, the health records 808 for each patient are denoted HR-1 to HR-9, and list various items of medical information for each patient, such as medical background, medical history, diet records, lab test results (i.e. vital sign measurement data), and so on. [Para. 0047] The Electronic Health Record (EHR) server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database (i.e. patient information database) that is separate from the patient PHR database (i.e. vital sign measurement database) 304. [Para. 0051] The health record information is thus totally de-identified while it is stored on the PHR system, and cannot be associated with any particular individual patient in the event of exposure, theft, or data corruption.)
and the patient protected information database having greater security than the vital sign measurements database; ([Para. 0050] The individual identifying information (III) for each patient of a particular doctor is stored on a computer managed by that doctor. Thus, in the example of FIG. 8, the computer of Dr. A (812) stores the III objects 818 for his patients, Pt. 1 to Pt. 3. The III objects consist of information sufficient to identify each particular patient, such as name, address, telephone, birthdate, and so on. The III objects are referenced by the ABID key for each patient. [Para. 0056] For security reasons, the PHR database 228 provides only de-identified information, and the physician will need to obtain the patient's III information from a separate source else (i.e. second database). [Para. 0065] The substantive health record information is stored in a second database (i.e. patient protected information database) that is separate from the first database (i.e. vital sign measurement database). Only authorized care providers specified by the healthcare user is allowed to view and manage the patient's health data/information with corresponding III data/information.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar and incorporate the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, with the motivation of storing a user's information on a website without any individually identifiable data/information (de-identified in nature), and that still allows an authorized care provider to be able to access the users' data/information on that website individually and in a contextually identifiable manner (Yu Para. 0009).
Mazar/ Yu do not explicitly teach, however Banet teaches
wherein the one or more position sensors are configured to enable a determination of a spatial position data of the chest device relative to the limb device. ([Para. 0012] The body-worn monitor measures IP, PPG, ECG, and ACC waveforms with a series of sensors integrated into a comfortable, low-profile system. The system typically features three accelerometers, each configured to measure a unique signal along its x, y, and z axes, to yield a total of nine ACC waveforms (i.e. spatial data). The accelerometers are deployed on the patient's torso (i.e. chest device), upper arm (i.e. limb device), and lower arm (limb device). Each ACC waveform can be additionally processed to determine the patient's posture (i.e. spatial position data), degree of motion, and activity level. [Para. 0123] FIG. 25 indicates how the body-worn monitor can determine motion-related parameters (e.g. degree of motion, posture, and activity level) (i.e. spatial position data) from a patient 110 using time-dependent ACC waveforms continuously generated from the three accelerometers 112, 113, 114 worn, respectively, on the patient's chest, bicep, and wrist. Arm height can be determined using DC signals from the accelerometers 113, 114 disposed, respectively, on the patient's bicep and wrist. Posture, in contrast, can be exclusively determined by the accelerometer 112 worn on the patient's chest. An algorithm operating on the wrist-worn transceiver extracts DC values from waveforms measured from this accelerometer and processes them with an algorithm described below to determine posture. [Para. 0124] Torso posture is determined for a patient 110 using angles determined between the measured gravitational vector and the axes of a torso coordinate space 111. The axes of this space 111 are defined in a three-dimensional Euclidean space where {right arrow over (R)}.sub.CV is the vertical axis, {right arrow over (R)}.sub.CH is the horizontal axis, and {right arrow over (R)}.sub.CN is the normal axis. These axes must be identified relative to a `chest accelerometer coordinate space` before the patient's posture can be determined. [Para. 0125] The first step in determining a patient's posture is to identify alignment of {right arrow over (R)}.sub.CV in the chest accelerometer coordinate space. The algorithm then calculates {right arrow over (R)}.sub.CV (horizonal axis) from DC values corresponding to the x, y, and z axes of the chest accelerometer while the patient is in a known position with respect to gravity (e.g., standing upright with arms pointed straight down). This case, however, still requires knowledge of which arm (left or right) the monitor (i.e. limb device) is worn on, as the chest accelerometer coordinate space can be rotated by 180 degrees depending on this orientation. The process is repeated to calculate values for the horizontal and normal axis. Examiner interprets this to be indicative of determining of a spatial position data of the chest device relative to the limb device. [Para. 0145] Multiple ACC waveforms, such as those measured along axes (e.g. the x or y-axes) orthogonal to the vector normal to the patient's chest (i.e. the z-axis), can be processed with or without adaptive filtering to determine respiratory rate (RR)(i.e. vital sign measurement data).)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, and incorporate a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, with the motivation of improving methods for measuring respiratory rate of an ambulatory patient (Banet Para. 0010).
As per Claim 3, Mazar/ Yu/ Banet teach the computer system of claim 2, Mazar further teaches wherein the computer-executable instructions are further configured to cause the computer system to, for each vital sign measurement stored within the vital sign measurements database, generate a relative time stamp representing a relative time at which the vital sign was measured with respect to the start time.([Para. 0134] The user interface 385 includes a panel 388 that displays historic heart rate information for the patient. The panel 388 displays a date at which the heart rate readings were measured, and a list of time stamps indicating times at which the heart rate readings were measured, and heart rate values that were measured at the indicated times. [Para. 0140] The user interface 385 can include additional information for the patient, such as for example, historic respiratory rate readings, historic location information, historic motion information or other patient related information along with time stamps indicating dates and times at which the information was recorded.)
As per Claim 4, Mazar/ Yu/ Banet teach the computer system of claim 1, Mazar further teaches wherein vital sign measurement data is received at pre-determined intervals. ([Para. 0128] The bedside monitor 304 can display heart rate measurements for the patient taken at regular 15-minute intervals for the past several hours. [Para. 0156] For example, heart rate information for the patient recorded at regular intervals for a specified time period can be displayed.)
As per Claim 5, Mazar/ Yu/ Banet teach the computer system of claim 1, Mazar further teaches wherein the vital sign measurement data includes data associated with one or more vital signs selected from the group consisting of; temperature, pulse rate, respiration rate, blood pressure, and body part position. ([Para. 0009] The patient worn sensors can track vital sign information such as blood pressure, body temperature, respiratory rate, blood oxygenation, heart rhythm (via ECG), heart rate, blood glucose level, and hydration levels. The sensors can also track and record additional information about patients, including patient movement, activity, and sleep patterns.)
As per Claim 6, Mazar/ Yu/ Banet teach the computer system of claim 1, Mazar further teaches wherein the one or more remote computer systems includes a computer system associated with a healthcare facility and/or a healthcare practitioner. ([Para. 0072] Information for the patient 104 (such as vital signs, alarm states, treatment information, biographical information, etc.) can be accessed using other devices in communication with the central server 113 and/or bedside monitor 108. For example, patient information can be sent to a mobile device (such as a smart phone, tablet or laptop) owned by the caregiver 110 or another caregiver associated with the patient 104. [Para. 0045] A caregiver 110 (e.g., a nurse, doctor, orderly, physical therapist, or other caregiver).)
As per Claim 8, Mazar/ Yu/ Banet teach the computer system of claim 1, Mazar further teaches wherein the computer-executable instructions are further configured to cause the computer system to:
receive, from the remote computer system, a vital sign measurement data request; ([Para. 0085] The system 100, or a related system, the caregiver 110 can look up the unique identifier for the patient. [Para. 0052] The central server station 114 can allow the caregiver 116 to monitor vital signs, activities, and other information for the patient 104 from a remote location. [Para. 0173] One way in which the caregiver can link to other profiles is by searching for patients or other caregivers by name, patient ID, caregiver ID, or another unique identifier.)
receive, from the remote computer system, the unique patient identifier; ([Para. 0072] Information for the patient 104 (such as vital signs) can be accessed using other devices in communication with the central server 113 and/or bedside monitor 108.The caregiver 110 can access the central server 113 (e.g., by using the bedside monitor 108 or another computing device) and indicate that the caregiver 110 wishes to receive updates for the patient 104. The caregiver 110 can then be associated with the patient 104 (for example, by linking a caregiver profile for the caregiver 110 to a patient profile for the patient 104). [Para. 0173] The system can verify that the caregiver has proper permissions to access some or all of the information included in the patient profile for Brandon LaPlante. [Para. 0156] The user can select the panel 510 to cause the mobile device 500 to display a user interface containing additional information on tracked heart rate information for the patient. For example, heart rate information for the patient recorded at regular intervals for a specified time period can be displayed.)
and based on the received vital sign measurement data request and the received unique patient identifier, send corresponding vital sign measurement data to the remote computer system. ([Para. 0173] One way in which the caregiver can link to other profiles is by searching for patients or other caregivers by name, patient ID, caregiver ID, or another unique identifier. The system can verify that the caregiver has proper permissions to access some or all of the information included in the patient profile for Brandon LaPlante. If the system determines that the caregiver is permitted to access the patient profile for Brandon LaPlante, the system can display information from the patient profile that the caregiver is permitted to access. The caregiver can then link the patient profile for Brandon LaPlante to the caregiver's caregiver profile.)
As per Claim 9, Mazar/ Yu/ Banet teach the computer system of claim 8, Yu further teaches wherein the computer-executable instructions are further configured to cause the computer system to limit or block the sending of patient personal information from the patient protected information database to the remote computer system to a greater degree than the vital sign measurement data from the vital sign measurement database. ([Para. 0047] The Electronic Health Record (EHR) server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database (i.e. patient information database) that is separate from the patient PHR database (i.e. vital sign measurement database) 304. [Para. 0051] The health record information is thus totally de-identified while it is stored on the PHR system, and cannot be associated with any particular individual patient in the event of exposure, theft, or data corruption (i.e. quarantine the patient information data). [Para. 0050] The individual identifying information (III) for each patient of a particular doctor is stored on a computer managed by that doctor. Thus, in the example of FIG. 8, the computer of Dr. A (812) stores the III objects 818 for his patients, Pt. 1 to Pt. 3. The III objects consist of information sufficient to identify each particular patient, such as name, address, telephone, birthdate, and so on. The III objects are referenced by the ABID key for each patient. [Para. 0056] For security reasons, the PHR database 228 provides only de-identified information, and the physician will need to obtain the patient's III information from a separate source else (i.e. second database). [Para. 0065] The substantive health record information is stored in a second database (i.e. patient protected information database) that is separate from the first database (i.e. vital sign measurement database). Only authorized care providers specified by the healthcare user is allowed to view and manage the patient's health data/information with corresponding III data/information.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar and incorporate the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, with the motivation of storing a user's information on a website without any individually identifiable data/information (de-identified in nature), and that still allows an authorized care provider to be able to access the users' data/information on that website individually and in a contextually identifiable manner (Yu Para. 0009).
As per Claim 21, Mazar/ Yu/ Banet teach the computer system of claim 1, Banet further teaches wherein the computer system uses the spatial position data to calibrate a measurement of vital sign measurement data. ([Para. 0012] The body-worn monitor measures IP, PPG, ECG, and ACC waveforms with a series of sensors integrated into a comfortable, low-profile system. The system typically features three accelerometers, each configured to measure a unique signal along its x, y, and z axes, to yield a total of nine ACC waveforms (i.e. spatial data). The accelerometers are deployed on the patient's torso (i.e. chest device), upper arm (i.e. limb device), and lower arm (limb device). Each ACC waveform can be additionally processed to determine the patient's posture (i.e. spatial position data), degree of motion, and activity level. [Para. 0123] FIG. 25 indicates how the body-worn monitor can determine motion-related parameters (e.g. degree of motion, posture, and activity level) (i.e. spatial position data) from a patient 110 using time-dependent ACC waveforms continuously generated from the three accelerometers 112, 113, 114 worn, respectively, on the patient's chest, bicep, and wrist. Arm height can be determined using DC signals from the accelerometers 113, 114 disposed, respectively, on the patient's bicep and wrist. Posture, in contrast, can be exclusively determined by the accelerometer 112 worn on the patient's chest. An algorithm operating on the wrist-worn transceiver extracts DC values from waveforms measured from this accelerometer and processes them with an algorithm described below to determine posture. [Para. 0124] Torso posture is determined for a patient 110 using angles determined between the measured gravitational vector and the axes of a torso coordinate space 111. The axes of this space 111 are defined in a three-dimensional Euclidean space where {right arrow over (R)}.sub.CV is the vertical axis, {right arrow over (R)}.sub.CH is the horizontal axis, and {right arrow over (R)}.sub.CN is the normal axis. These axes must be identified relative to a `chest accelerometer coordinate space` before the patient's posture can be determined. [Para. 0125] The first step in determining a patient's posture is to identify alignment of {right arrow over (R)}.sub.CV in the chest accelerometer coordinate space. The algorithm then calculates {right arrow over (R)}.sub.CV (horizonal axis) from DC values corresponding to the x, y, and z axes of the chest accelerometer while the patient is in a known position with respect to gravity (e.g., standing upright with arms pointed straight down). This case, however, still requires knowledge of which arm (left or right) the monitor (i.e. limb device) is worn on, as the chest accelerometer coordinate space can be rotated by 180 degrees depending on this orientation. The process is repeated to calculate values for the horizontal and normal axis. Examiner interprets this to be indicative of determining of a spatial position data of the chest device relative to the limb device. [Para. 0145] Multiple ACC waveforms, such as those measured along axes (e.g. the x or y-axes) orthogonal to the vector normal to the patient's chest (i.e. the z-axis), can be processed with or without adaptive filtering to determine respiratory rate (RR) (i.e. vital sign measurement data).)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, and incorporate a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, with the motivation of improving methods for measuring respiratory rate of an ambulatory patient (Banet Para. 0010).
Claim(s) 2 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazar (US 20150302539 A1) in view of Yu (US 20110112862 A1) in view of Banet (US 20110066062 A1) in view of Carlberg (US 20120310669 A1).
As per Claim 2, Mazar/ Yu/ Banet teach the computer system of claim 1, however Carlberg teaches wherein the computer-executable instructions are further configured to cause the computer system to generate a time stamp representing a start time when the unique patient identifier is generated. ([Para. 0016] A set of identification data items and one or more identification time stamps, wherein each identification time stamp is associated with at least one of the identification data items, and the set of identification data items comprises a patient identification data item identifying a patient. [Para. 0029] Received patient-related data may be associated with a patient identifier that has been received in a set of identification data items.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, and incorporate identification time stamp is associated with at least one of the patient identification data items as taught by Carlberg, with the motivation of reducing the risk of patient mix-up and to ensure that correct data is registered in a patient database (Carlberg Para. 0009).
As per Claim 7, Mazar/ Yu/ Banet teach the computer system of claim 1, however Carlberg teaches wherein the computer-executable instructions are further configured to cause the computer system to: receive, from the user-associated computer device, an initiation or stop command for collecting patient vital sign measurement data, and based on the initiation or stop command, initiate or stop receiving vital sign measurement data from the user-associated computer device. ([Para. 0033] The start and/or end of the data acquisition time interval may be determined by a predetermined trigger event that include the receipt of a message (initiation/ stop command) by the registration device (i.e. user-associated computer device) from an external system. [Para. 0045] Each of the registration devices may be a suitable portable or stationary computer or other computing device, such as a laptop computer, a desktop computer, a handheld computer such as a PDA, a Smartphone, a tablet computer, etc.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, and incorporate the start and/or end of the data acquisition time interval may be determined by the registration device as taught by Carlberg, with the motivation of reducing the risk of patient mix-up and to ensure that correct data is registered in a patient database (Carlberg Para. 0009).
Claim(s) 22 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazar (US 20150302539 A1) in view of Yu (US 20110112862 A1) in view of Banet (US 20110066062 A1) in view of York (US 20190192011 A1) in view of Lane (US 20060155589 A1).
As per Claim 22, Mazar/ Yu/ Banet teach the computer system of claim 1, however York teaches wherein before the user-associated computer device receives the vital sign measurement data, ([Abstract] Sensor data may be periodically collected from a sensor array. The sensor data may be stored in a local database of the wearable health monitor device. The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0013] A software architecture platform in the wearable health monitor device which may allow for flexibility in developing services and applications to run on the wearable health monitor device. The platform may include a data service that may capture and transmit sensor data to a cloud computing platform (e.g., an internet connected cluster of computing devices (i.e. user-associated computer device), etc.).)
a controller locally stores the vital sign measurement data, ([Abstract] The sensor data may be stored in a local database of the wearable health monitor device. [Para. 0020] The service layer 120 may include a capture data service that first captures sensor data from the wearable health monitor device. This would include data such as battery level, heart rate readings, step count reading and GPS location readings. This capture data service would capture the information and manage the local storage of the data.)
a connectivity determiner determines a connectivity status to the user-associated computer device, ([Abstract] The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0018] The wearable device 100 may include communication hardware such as, for example, a cellular network transceiver. The wearable operating system 125 may facilitate communication between components of the system 105 and the communication hardware. [Para. 0033] If the connection is strong (e.g., as determined at decision 410), it may be determined in a recent record for the sensor collection item in a local database (e.g., at decision 420). If there is not a recent record in the local database, the sensor reading may be collected and transmitted (e.g., at operation 425). If there is a recent record in the local database, the sensor reading may be package and transmitted (e.g., at operation 430). [Para. 0034] The machine 500 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge)
a vital sign data router prompts the controllers to send the vital measurement data to the user-associated computer device when sufficient connectivity is established, as determined by the connectivity determiner, ([Abstract] The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0013] The platform may include a data service that may capture and transmit sensor data to a cloud computing platform (e.g., an internet connected cluster of computing devices, etc.). [Para. 0033] If currently detected bandwidth is below fifty percent of an expected available bandwidth value the connect may not be determined as strong while current available bandwidth above fifty percent of the expected bandwidth value may be determined to be a strong connection. If the connection is strong (e.g., as determined at decision 410), it may be determined in a recent record for the sensor collection item in a local database (e.g., at decision 420). If there is not a recent record in the local database, the sensor reading may be collected and transmitted (e.g., at operation 425). If there is a recent record in the local database, the sensor reading may be package and transmitted (e.g., at operation 430).)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, and incorporate the wearable health monitoring data service as taught by York, with the motivation of provide the wearer of a wearable device or another individual with information regarding the performance of the wearer (York Para. 0003).
York does not explicitly teach, however Lane teaches
and the controller flags the vital sign measurement data for deletion from local storage. ([Para. 0145] When the portable vital signs measurement instruments 902 receives an acknowledgement that the information it sent has been received and recorded by the server 910, the portable vital signs measurement instruments 902 can delete the locally stored information and reclaim the memory space so free for use in another patient encounter.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, the wearable health monitoring data service as taught by York, and incorporate the data management system of Lane, with the motivation of providing an automated, convenient, and ubiquitous availability of a readily used instrument that assists the practitioner in obtaining and recording patient information in an accurate and expeditious manner (Lane Para. 0005).
As per Claim 24, Mazar teaches a computer system for remotely securing a vital sign measurement data and configuring the vital sign measurement data for accessibility by a healthcare provider to enable remote monitoring of one or more patient vital signs, the computer system comprising:
one or more wearable vital sign monitoring devices, the one or more wearable vital sign monitoring devices comprising: ([Para. 0009] Patient worn sensors can track vital sign information such as blood pressure, body temperature, respiratory rate, blood oxygenation, heart rhythm (via ECG), heart rate, blood glucose level, and hydration levels.)
a chest device and a limb device, ([Para. 0009] Patient worn sensors can track vital sign information such as blood pressure, body temperature, respiratory rate, blood oxygenation, heart rhythm (via ECG), heart rate, blood glucose level, and hydration levels. The sensors can also track and record additional information about patients, including patient movement (i.e. position sensor), activity, and sleep patterns. [Para. 0033] The chest sensor 102 can also include sensors for detecting bio-impedance in order to monitor hydration levels, body fat levels, or other fluid levels for the patient 104. [Para. 0035] The chest sensor 102 includes one or more accelerometers (i.e. position sensor) for detecting and recording patient motion, activity, position, and posture. [Para. 0042] Patient worn sensors included as part of the system 100 can include the wrist sensor 106.)
one or more processors; ([Para. 0252] execution by a programmable processor)
and one or more hardware storage devices having stored thereon computer-executable instructions that, when executed by the one or more processors, cause the computer system to generate a unique patient identifier relating to a patient to which one or more wearable vital sign monitoring devices are associated; ([Para. 0085] one or more patient worn sensors (such as the chest sensor 102 and wrist sensor 106) (i.e. wearable vial sign monitoring devices) can be associated with the patient 104. The patient 104 can be associated with a unique patient identifier (“ID”). The patient ID can be as simple as the patient 104's name, a unique number assigned to the patient 104, a unique combination of numbers, letters, and other characters, or any other unique identifier associated with the patient 104. [Para. 0186] If the patient 104 has not previously interacted with system 100 or a related system, a new unique ID (i.e. unique patient identifier) can be assigned to the patient. [Para. 0087] When the patient worn monitors (such as the chest sensor 102 and wrist sensor 106) are initially provided to the patient 104, the patient worn sensors can be associated with the patient 104 by associating the patient worn sensors with the unique ID for the patient 104. [Para. 0252] a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by a programmable processor.)
receive, from the user-associated computer device, vital sign measurement data indicative of one or more vital signs of the patient as measured by the one or more wearable vital sign monitoring devices; ([Para. 0043] The chest sensor 102 can communicate with a bedside monitor 108 to convey information collected by the chest sensor 102 and/or other patient worn sensors (e.g., patient vital signs, patient activity, patient location) to the bedside monitor 108. [Para. 0044] The wrist sensor 106 also communicates with the bedside monitor 108 (e.g., through a wireless Bluetooth connection, other wireless connection, or through a wired connection). [Para. 0045] The bedside monitor 108 can allow a caregiver 110 (e.g., a nurse, doctor, orderly, physical therapist, or other caregiver) to view real-time vital signs for the patient 104, past vital signs for the patient 104, other information provided by the chest sensor 102, wrist sensor 106, and/or other patient worn sensors, or other information associated with the patient 104. For example, the bedside monitor 108 can display an ECG waveform for the patient 104 while also listing a current blood oxygenation level, blood pressure, hydration level, heart rate, respiration rate, and body temperature for the patient 104. )
and send vital sign measurement data from the vital sign measurement database to one or more remote computer systems to thereby enable remote monitoring of the one or more vital signs; ([Para. 0051] Information collected by the central server (i.e. vital sign measurement database)113 can be accessed at a central server station 114. For example, a caregiver 116 or other hospital personnel can use the central server station 114 to access information for the patient 104, other patients, or other hospital or healthcare administrative functions. [Para. 0052] The central server station 114 can allow the caregiver 116 to monitor vital signs, activities, and other information for the patient 104 from a remote location. The central server station 114 can additionally allow the caregiver 116 to observe information for multiple patients within a healthcare facility or system simultaneously. All information collected by the patient worn sensors (e.g., the chest sensor 102 and the wrist sensor 106) and all information entered using the bedside monitor 108 is stored by the central server 113 and is accessible through the central server station 114. [Para. 0072] Information for the patient 104 (such as vital signs, alarm states, treatment information, biographical information, etc.) can be accessed using other devices (i.e. remote computer systems) in communication with the central server 113 and/or bedside monitor 108. )
Mazar does not explicitly teach, however Yu teaches
receive, from a user-associated computer device, patient personal information relating to the patient; ([Para.0062] The user (patient) of the network system can access the network 210 through their own client computer 202, which runs a web browser 212. Through this web interface, the healthcare user can contact the physician or provider website 214 to obtain specific health information, to appoint a doctor, or request healthcare services being offered by a particular institution, or to transmit personal health information (PHD/I) to care providers and so on.)
based on the received patient personal information, and based on the unique patient identifier, generate a patient protected information database unique to the patient to store the patient personal information, and the patient protected information database being generated at the computer system; ([Para.0062] The user (patient) of the network system can access the network 210 through their own client computer 202, which runs a web browser 212. Through this web interface, the healthcare user can contact the physician or provider website 214 to obtain specific health information, to appoint a doctor, or request healthcare services being offered by a particular institution, or to transmit personal health information (PHD/I) to care providers and so on. [Para. 0069] Providing an access identifier (i.e. unique patient identifier) and password to the authorized service provider to access the user account; generating an alliance-based identification key specifically for the user and the website. [Para. 0047] The EHR server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database that is separate from the patient PHR database 304. [Para. 0069] The user individual identification information comprises user identification, name, birthdate, home address, telephone number, photographic data, and optionally user social security number and family relationship information, and the service provider identification information comprises a provider identification code, a nationality code, a location code, and an institutional affiliation code. [Para. 0072] A patient identification datastore that is separate from the electronic health record database and storing individual identification information for the one or more patients in a physician's personal computer or portable memory device)
based on the received vital sign measurement data, and based on the unique patient identifier, generate a vital sign measurements database unique to the patient to store the vital sign measurement data, the vital sign measurements database being separate from the patient protected information database, and the vital sign measurements database being generated at the computer system, ([Para. 0008] In order to protect the privacy of patients through securing identifiable information within the database, efforts are also often made to de-identify protected identity information received or created in the course of business. De-identified records are data/information, alone or in combination with other information, that cannot readily or potentially be used to identify an individual. [Para. 0031] A dual-portal web-based system is implemented that provides healthcare related information to healthcare users through a first website, and registry/management tools to care providers through a second website. No identifiable fields relating to the user, such as name, birth date, address, e-mail address, telephone/fax number, Social Security ID, relatives and employers, is stored or accessible in the database of the first website (i.e. vital sign measurement data). All user information is de-identified by total exclusion from the database, rather than by merely stripping-out true identity information from database prior to exchange or usage. [Para. 0037] The system of FIG. 2 constitutes a dual-portal alliance system architecture in which a relationship is established between the user 202 and service provider 204 to enable storage of de-identified user information in the PHR database (i.e. vital sign measurement data). [Para. 0049] FIG. 8 illustrates the database structure 800 for a PHR web server storing de-identified patient health records. For the example of FIG. 8, the health records 808 for each patient are denoted HR-1 to HR-9, and list various items of medical information for each patient, such as medical background, medical history, diet records, lab test results (i.e. vital sign measurement data), and so on. [Para. 0047] The Electronic Health Record (EHR) server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database (i.e. patient information database) that is separate from the patient PHR database (i.e. vital sign measurement database) 304. [Para. 0051] The health record information is thus totally de-identified while it is stored on the PHR system, and cannot be associated with any particular individual patient in the event of exposure, theft, or data corruption (i.e. quarantine the patient information data).)
and the patient protected information database having greater security than the vital sign measurements database; ([Para. 0050] The individual identifying information (III) for each patient of a particular doctor is stored on a computer managed by that doctor. Thus, in the example of FIG. 8, the computer of Dr. A (812) stores the III objects 818 for his patients, Pt. 1 to Pt. 3. The III objects consist of information sufficient to identify each particular patient, such as name, address, telephone, birthdate, and so on. The III objects are referenced by the ABID key for each patient. [Para. 0056] For security reasons, the PHR database 228 provides only de-identified information, and the physician will need to obtain the patient's III information from a separate source else (i.e. second database). [Para. 0065] The substantive health record information is stored in a second database (i.e. patient protected information database) that is separate from the first database (i.e. vital sign measurement database). Only authorized care providers specified by the healthcare user is allowed to view and manage the patient's health data/information with corresponding III data/information.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar and incorporate the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, with the motivation of storing a user's information on a website without any individually identifiable data/information (de-identified in nature), and that still allows an authorized care provider to be able to access the users' data/information on that website individually and in a contextually identifiable manner (Yu Para. 0009).
Mazar/ Yu do not explicitly teach, however Banet teaches
the one or more position sensors configured to enable a determination of a spatial position data of the chest device relative to the limb device; ([Para. 0012] The body-worn monitor measures IP, PPG, ECG, and ACC waveforms with a series of sensors integrated into a comfortable, low-profile system. The system typically features three accelerometers, each configured to measure a unique signal along its x, y, and z axes, to yield a total of nine ACC waveforms. The accelerometers are deployed on the patient's torso (i.e. chest device), upper arm (i.e. limb device), and lower arm (limb device). Each ACC waveform can be additionally processed to determine the patient's posture (i.e. spatial position data), degree of motion, and activity level. [Para. 0123] FIG. 25 indicates how the body-worn monitor can determine motion-related parameters (e.g. degree of motion, posture, and activity level) (i.e. spatial position data) from a patient 110 using time-dependent ACC waveforms continuously generated from the three accelerometers 112, 113, 114 worn, respectively, on the patient's chest, bicep, and wrist. Arm height can be determined using DC signals from the accelerometers 113, 114 disposed, respectively, on the patient's bicep and wrist. Posture, in contrast, can be exclusively determined by the accelerometer 112 worn on the patient's chest. An algorithm operating on the wrist-worn transceiver extracts DC values from waveforms measured from this accelerometer and processes them with an algorithm described below to determine posture. [Para. 0124] Torso posture is determined for a patient 110 using angles determined between the measured gravitational vector and the axes of a torso coordinate space 111. The axes of this space 111 are defined in a three-dimensional Euclidean space where {right arrow over (R)}.sub.CV is the vertical axis, {right arrow over (R)}.sub.CH is the horizontal axis, and {right arrow over (R)}.sub.CN is the normal axis. These axes must be identified relative to a `chest accelerometer coordinate space` before the patient's posture can be determined. [Para. 0125] The first step in determining a patient's posture is to identify alignment of the vertical axis in the chest accelerometer coordinate space. The algorithm then calculates {right arrow over (R)}.sub.CV (vertical axis) from DC values corresponding to the x, y, and z axes of the chest accelerometer while the patient is in a known position with respect to gravity (e.g., standing upright with arms pointed straight down). This case, however, still requires knowledge of which arm (left or right) the monitor (i.e. limb device) is worn on, as the chest accelerometer coordinate space can be rotated by 180 degrees depending on this orientation. The process is repeated to calculate values for the horizontal and normal axis. Examiner interprets this to be indicative of determining of a spatial position data of the chest device relative to the limb device. [Para. 0145] Multiple ACC waveforms, such as those measured along axes (e.g. the x or y-axes) orthogonal to the vector normal to the patient's chest (i.e. the z-axis), can be processed with or without adaptive filtering to determine respiratory rate (RR) (i.e. vital sign measurement data).)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, and incorporate a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, with the motivation of improving methods for measuring respiratory rate of an ambulatory patient (Banet Para. 0010).
Mazar/ Yu/ Banet do not explicitly teach, however York teaches
wherein the one or more wearable vital sign monitoring devices have, one or more position sensors, and a controller, the controller comprising a connectivity determiner and a vital sign data router; ([Para. 0018-0019] The wearable device 100 may include communication hardware such as, for example, a cellular network transceiver. The wearable operating system 125 may facilitate communication between components of the system 105 and the communication hardware. The service layer 120 may work in conjunction with the wearable operating system 125 to manage data capture and data transmission functions of the wearable heath monitor device 100.)
wherein, before the user-associated computer device receives the vital sign measurement data, the controllers locally store the vital sign measurement data, ([Abstract] Sensor data may be periodically collected from a sensor array. The sensor data may be stored in a local database of the wearable health monitor device. The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0013] A software architecture platform in the wearable health monitor device which may allow for flexibility in developing services and applications to run on the wearable health monitor device. The platform may include a data service that may capture and transmit sensor data to a cloud computing platform (e.g., an internet connected cluster of computing devices (i.e. user-associated computer device), etc.). [Para. 0020] The service layer 120 may include a capture data service that first captures sensor data from the wearable health monitor device. This would include data such as battery level, heart rate readings, step count reading and GPS location readings. This capture data service would capture the information and manage the local storage of the data.)
the connectivity determiner determines a connectivity status to the user- associated computer device, ([Abstract] The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0018] The wearable device 100 may include communication hardware such as, for example, a cellular network transceiver. The wearable operating system 125 may facilitate communication between components of the system 105 and the communication hardware. [Para. 0033] If the connection is strong (e.g., as determined at decision 410), it may be determined in a recent record for the sensor collection item in a local database (e.g., at decision 420). If there is not a recent record in the local database, the sensor reading may be collected and transmitted (e.g., at operation 425). If there is a recent record in the local database, the sensor reading may be package and transmitted (e.g., at operation 430). [Para. 0034] The machine 500 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge)
the vital sign data router prompts the controllers to send the vital measurement data to the user-associated computer device when sufficient connectivity is established, as determined by the connectivity determiner, ([Abstract] The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0013] The platform may include a data service that may capture and transmit sensor data to a cloud computing platform (e.g., an internet connected cluster of computing devices, etc.). [Para. 0033] If currently detected bandwidth is below fifty percent of an expected available bandwidth value the connect may not be determined as strong while current available bandwidth above fifty percent of the expected bandwidth value may be determined to be a strong connection. If the connection is strong (e.g., as determined at decision 410), it may be determined in a recent record for the sensor collection item in a local database (e.g., at decision 420). If there is not a recent record in the local database, the sensor reading may be collected and transmitted (e.g., at operation 425). If there is a recent record in the local database, the sensor reading may be package and transmitted (e.g., at operation 430).)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, and incorporate the wearable health monitoring data service as taught by York, with the motivation of provide the wearer of a wearable device or another individual with information regarding the performance of the wearer (York Para. 0003).
Mazar/ Yu/ York do not explicitly teach, however Lane teaches
and the controller flags the vital sign measurement data for deletion from local storage. ([Para. 0145] When the portable vital signs measurement instruments 902 receives an acknowledgement that the information it sent has been received and recorded by the server 910, the portable vital signs measurement instruments 902 can delete the locally stored information and reclaim the memory space so free for use in another patient encounter.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, the wearable health monitoring data service as taught by York, and incorporate the data management system of Lane, with the motivation of providing an automated, convenient, and ubiquitous availability of a readily used instrument that assists the practitioner in obtaining and recording patient information in an accurate and expeditious manner (Lane Para. 0005).
Claim(s) 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazar (US 20150302539 A1) in view of Yu (US 20110112862 A1) in view of York (US 20190192011 A1) in view of Lane (US 20060155589 A1).
As per Claim 23, Mazar teaches a computer system for remotely securing a vital sign measurement data and configuring the vital sign measurement data for accessibility by a healthcare provider to enable remote monitoring of one or more patient vital signs, the computer system comprising:
one or more wearable vital sign monitoring devices, the one or more wearable vital sign monitoring devices comprising:
a chest device and a limb device; ([Para. 0009] Patient worn sensors can track vital sign information such as blood pressure, body temperature, respiratory rate, blood oxygenation, heart rhythm (via ECG), heart rate, blood glucose level, and hydration levels. The sensors can also track and record additional information about patients, including patient movement (i.e. position sensor), activity, and sleep patterns. [Para. 0033] The chest sensor 102 can also include sensors for detecting bio-impedance in order to monitor hydration levels, body fat levels, or other fluid levels for the patient 104. [Para. 0035] The chest sensor 102 includes one or more accelerometers (i.e. position sensor) for detecting and recording patient motion, activity, position, and posture. [Para. 0042] Patient worn sensors included as part of the system 100 can include the wrist sensor 106.)
one or more processors; ([Para. 0252] execution by a programmable processor)
and one or more hardware storage devices having stored thereon computer-executable instructions that, when executed by the one or more processors, cause the computer system to generate a unique patient identifier relating to a patient to which one or more wearable vital sign monitoring devices are associated; ([Para. 0085] one or more patient worn sensors (such as the chest sensor 102 and wrist sensor 106) (i.e. wearable vial sign monitoring devices) can be associated with the patient 104. The patient 104 can be associated with a unique patient identifier (“ID”). The patient ID can be as simple as the patient 104's name, a unique number assigned to the patient 104, a unique combination of numbers, letters, and other characters, or any other unique identifier associated with the patient 104. [Para. 0186] If the patient 104 has not previously interacted with system 100 or a related system, a new unique ID (i.e. unique patient identifier) can be assigned to the patient. [Para. 0087] When the patient worn monitors (such as the chest sensor 102 and wrist sensor 106) are initially provided to the patient 104, the patient worn sensors can be associated with the patient 104 by associating the patient worn sensors with the unique ID for the patient 104. [Para. 0252] a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by a programmable processor.)
receive, from the user-associated computer device, vital sign measurement data indicative of one or more vital signs of the patient as measured by the one or more wearable vital sign monitoring devices; ([Para. 0043] The chest sensor 102 can communicate with a bedside monitor 108 to convey information collected by the chest sensor 102 and/or other patient worn sensors (e.g., patient vital signs, patient activity, patient location) to the bedside monitor 108. [Para. 0044] The wrist sensor 106 also communicates with the bedside monitor 108 (e.g., through a wireless Bluetooth connection, other wireless connection, or through a wired connection). [Para. 0045] The bedside monitor 108 can allow a caregiver 110 (e.g., a nurse, doctor, orderly, physical therapist, or other caregiver) to view real-time vital signs for the patient 104, past vital signs for the patient 104, other information provided by the chest sensor 102, wrist sensor 106, and/or other patient worn sensors, or other information associated with the patient 104. For example, the bedside monitor 108 can display an ECG waveform for the patient 104 while also listing a current blood oxygenation level, blood pressure, hydration level, heart rate, respiration rate, and body temperature for the patient 104.)
and send vital sign measurement data from the vital sign measurement database to one or more remote computer systems to thereby enable remote monitoring of the one or more vital signs; ([Para. 0051] Information collected by the central server (i.e. vital sign measurement database)113 can be accessed at a central server station 114. For example, a caregiver 116 or other hospital personnel can use the central server station 114 to access information for the patient 104, other patients, or other hospital or healthcare administrative functions. [Para. 0052] The central server station 114 can allow the caregiver 116 to monitor vital signs, activities, and other information for the patient 104 from a remote location. The central server station 114 can additionally allow the caregiver 116 to observe information for multiple patients within a healthcare facility or system simultaneously. All information collected by the patient worn sensors (e.g., the chest sensor 102 and the wrist sensor 106) and all information entered using the bedside monitor 108 is stored by the central server 113 and is accessible through the central server station 114. [Para. 0072] Information for the patient 104 (such as vital signs, alarm states, treatment information, biographical information, etc.) can be accessed using other devices (i.e. remote computer systems) in communication with the central server 113 and/or bedside monitor 108. )
Mazar does not explicitly teach, however Yu teaches
receive, from a user-associated computer device, patient personal information relating to the patient; ([Para.0062] The user (patient) of the network system can access the network 210 through their own client computer 202, which runs a web browser 212. Through this web interface, the healthcare user can contact the physician or provider website 214 to obtain specific health information, to appoint a doctor, or request healthcare services being offered by a particular institution, or to transmit personal health information (PHD/I) to care providers and so on.)
based on the received patient personal information, and based on the unique patient identifier, generate a patient protected information database unique to the patient to store the patient personal information, and the patient protected information database being generated at the computer system; ([Para.0062] The user (patient) of the network system can access the network 210 through their own client computer 202, which runs a web browser 212. Through this web interface, the healthcare user can contact the physician or provider website 214 to obtain specific health information, to appoint a doctor, or request healthcare services being offered by a particular institution, or to transmit personal health information (PHD/I) to care providers and so on. [Para. 0069] Providing an access identifier (i.e. unique patient identifier) and password to the authorized service provider to access the user account; generating an alliance-based identification key specifically for the user and the website. [Para. 0047] The EHR server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database that is separate from the patient PHR database 304. [Para. 0069] The user individual identification information comprises user identification, name, birthdate, home address, telephone number, photographic data, and optionally user social security number and family relationship information, and the service provider identification information comprises a provider identification code, a nationality code, a location code, and an institutional affiliation code. [Para. 0072] A patient identification datastore that is separate from the electronic health record database and storing individual identification information for the one or more patients in a physician's personal computer or portable memory device.)
based on the received vital sign measurement data, and based on the unique patient identifier, generate a vital sign measurements database unique to the patient to store the vital sign measurement data, the vital sign measurements database being
separate from the patient protected information database, and the patient protected information database having greater security than the vital sign measurements database, and the vital sign measurements database being generated at the computer system; ([Para. 0008] In order to protect the privacy of patients through securing identifiable information within the database, efforts are also often made to de-identify protected identity information received or created in the course of business. De-identified records are data/information, alone or in combination with other information, that cannot readily or potentially be used to identify an individual. [Para. 0031] A dual-portal web-based system is implemented that provides healthcare related information to healthcare users through a first website, and registry/management tools to care providers through a second website. No identifiable fields relating to the user, such as name, birth date, address, e-mail address, telephone/fax number, Social Security ID, relatives and employers, is stored or accessible in the database of the first website (i.e. vital sign measurement data). All user information is de-identified by total exclusion from the database, rather than by merely stripping-out true identity information from database prior to exchange or usage. [Para. 0037] The system of FIG. 2 constitutes a dual-portal alliance system architecture in which a relationship is established between the user 202 and service provider 204 to enable storage of de-identified user information in the PHR database (i.e. vital sign measurement data). [Para. 0049] FIG. 8 illustrates the database structure 800 for a PHR web server storing de-identified patient health records. For the example of FIG. 8, the health records 808 for each patient are denoted HR-1 to HR-9, and list various items of medical information for each patient, such as medical background, medical history, diet records, lab test results (i.e. vital sign measurement data), and so on. [Para. 0047] The Electronic Health Record (EHR) server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database (i.e. patient information database) that is separate from the patient PHR database (i.e. vital sign measurement database) 304. [Para. 0051] The health record information is thus totally de-identified while it is stored on the PHR system, and cannot be associated with any particular individual patient in the event of exposure, theft, or data corruption (i.e. quarantine the patient information data).)
Mazar/ Yu do not explicitly teach, however York teaches
wherein the one or more wearable vital sign monitoring devices have, one or more position sensors, and a controller, the controller comprising a connectivity determiner and a vital sign data router; ([Para. 0014] The wearable health monitor device 100 may be a smartwatch, wristband, smart clothing, or other device including sensors capable of capturing user activity data and vital sign data (e.g., gyroscope, accelerometer, magnetometer, infrared sensor, camera, microphone, gas sensor, photodetector, etc.).)
wherein, before the user-associated computer device receives the vital sign measurement data, the controllers locally store the vital sign measurement data, ( [Abstract] Sensor data may be periodically collected from a sensor array. The sensor data may be stored in a local database of the wearable health monitor device. The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0013] A software architecture platform in the wearable health monitor device which may allow for flexibility in developing services and applications to run on the wearable health monitor device. The platform may include a data service that may capture and transmit sensor data to a cloud computing platform (e.g., an internet connected cluster of computing devices (i.e. user-associated computer device), etc.).) [Para. 0020] The service layer 120 may include a capture data service that first captures sensor data from the wearable health monitor device. This would include data such as battery level, heart rate readings, step count reading and GPS location readings. This capture data service would capture the information and manage the local storage of the data.)
the connectivity determiner determines a connectivity status to the user- associated computer device, ([Abstract] The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0018] The wearable device 100 may include communication hardware such as, for example, a cellular network transceiver. The wearable operating system 125 may facilitate communication between components of the system 105 and the communication hardware. [Para. 0033] If the connection is strong (e.g., as determined at decision 410), it may be determined in a recent record for the sensor collection item in a local database (e.g., at decision 420). If there is not a recent record in the local database, the sensor reading may be collected and transmitted (e.g., at operation 425). If there is a recent record in the local database, the sensor reading may be package and transmitted (e.g., at operation 430). [Para. 0034] The machine 500 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge)
the vital sign data router prompts the controllers to send the vital measurement data to the user-associated computer device when sufficient connectivity is established, as determined by the connectivity determiner, ([Abstract] The sensor data may be transmitted to a cloud-based platform upon detection of a strong network connection. [Para. 0013] The platform may include a data service that may capture and transmit sensor data to a cloud computing platform (e.g., an internet connected cluster of computing devices, etc.). [Para. 0033] If currently detected bandwidth is below fifty percent of an expected available bandwidth value the connect may not be determined as strong while current available bandwidth above fifty percent of the expected bandwidth value may be determined to be a strong connection. If the connection is strong (e.g., as determined at decision 410), it may be determined in a recent record for the sensor collection item in a local database (e.g., at decision 420). If there is not a recent record in the local database, the sensor reading may be collected and transmitted (e.g., at operation 425). If there is a recent record in the local database, the sensor reading may be package and transmitted (e.g., at operation 430).)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, and incorporate the wearable health monitoring data service as taught by York, with the motivation of provide the wearer of a wearable device or another individual with information regarding the performance of the wearer (York Para. 0003).
Mazar/ Yu/ York do not explicitly teach, however Lane teaches
and the controller flags the vital sign measurement data for deletion from local storage. ([Para. 0145] When the portable vital signs measurement instruments 902 receives an acknowledgement that the information it sent has been received and recorded by the server 910, the portable vital signs measurement instruments 902 can delete the locally stored information and reclaim the memory space so free for use in another patient encounter.)
Therefore, it would be prima facie obvious to one of ordinary skill in the art, at the time of filing, to modify the method of patient care and health information management system for collecting patient data through patient worn sensors as taught by Mazar, the de-identified database structure and restricted access patient database that protect patient data as taught by Yu, a multi-sensor system that uses an algorithm to monitor a patient’s respiratory rate as taught by Banet, the wearable health monitoring data service as taught by York, and incorporate the data management system of Lane, with the motivation of providing an automated, convenient, and ubiquitous availability of a readily used instrument that assists the practitioner in obtaining and recording patient information in an accurate and expeditious manner (Lane Para. 0005).
Response to Arguments
Applicant's arguments, see pgs. 9-10 “35 U.S.C. 103” filed 12/10/2025 have been fully considered but they are not persuasive.
Applicant submits that the cited prior art does not teach "the patient protected information database being generated at the computer system" and "the vital sign measurements database being generated at the computer system". Examiner respectfully disagrees.
Yu teaches at Para.0062 the user (patient) of the network system can access the network 210 through their own client computer 202, which runs a web browser 212. Through this web interface, the healthcare user can contact the physician or provider website 214 to obtain specific health information, to appoint a doctor, or request healthcare services being offered by a particular institution, or to transmit personal health information (PHD/I) to care providers and so on. Para. 0069 further teaches providing an access identifier (i.e. unique patient identifier) and password to the authorized service provider to access the user account; generating an alliance-based identification key specifically for the user and the website. Para. 0047 teaches the EHR server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database that is separate from the patient PHR database 304. Para. 0069 teaches the user individual identification information comprises user identification, name, birthdate, home address, telephone number, photographic data, and optionally user social security number and family relationship information, and the service provider identification information comprises a provider identification code, a nationality code, a location code, and an institutional affiliation code. Para. 0072 further teaches a patient identification datastore that is separate from the electronic health record database and storing individual identification information for the one or more patients in a physician's personal computer or portable memory device. This is indicative of the patient protected information database being generated at the computer system.
Yu teaches at Para. 0008 teaches that in order to protect the privacy of patients through securing identifiable information within the database, efforts are also often made to de-identify protected identity information received or created in the course of business. De-identified records are data/information, alone or in combination with other information, that cannot readily or potentially be used to identify an individual. [Para. 0031] A dual-portal web-based system is implemented that provides healthcare related information to healthcare users through a first website, and registry/management tools to care providers through a second website. No identifiable fields relating to the user, such as name, birth date, address, e-mail address, telephone/fax number, Social Security ID, relatives and employers, is stored or accessible in the database of the first website (i.e. vital sign measurement data). All user information is de-identified by total exclusion from the database, rather than by merely stripping-out true identity information from database prior to exchange or usage. Para. 0037 teaches the system of FIG. 2 constitutes a dual-portal alliance system architecture in which a relationship is established between the user 202 and service provider 204 to enable storage of de-identified user information in the PHR database (i.e. vital sign measurement data). Para. 0049 further teaches FIG. 8 illustrates the database structure 800 for a PHR web server storing de-identified patient health records. For the example of FIG. 8, the health records 808 for each patient are denoted HR-1 to HR-9, and list various items of medical information for each patient, such as medical background, medical history, diet records, lab test results (i.e. vital sign measurement data), and so on. Para. 0047 further teaches the Electronic Health Record (EHR) server is generally maintained by a trusted entity and stores the Identifiable Individual Information (III) of the patient in a database (i.e. patient information database) that is separate from the patient PHR database (i.e. vital sign measurement database) 304. Para. 0051 teaches the health record information is thus totally de-identified while it is stored on the PHR system, and cannot be associated with any particular individual patient in the event of exposure, theft, or data corruption (i.e. quarantine the patient information data).This is indicative of the vital sign measurements database being generated at the computer system.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Patricia K Edouard whose telephone number is (571)272-6084. The examiner can normally be reached Monday - Friday 7:30 AM - 5:00 PM.
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, Peter H Choi can be reached at 469-295-9171. 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.
/P.K.E./Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
Prosecution Insights