DETAILED ACTION
Status of Claims
This action is in reply to the application filed on 12/02/2024.
Claims 1-20 have been cancelled.
Claims 21-40 have been newly added.
Claims 21-40 are currently pending and have been examined.
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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21, 25-29, 31-32 and 34-40 are rejected under the judicially created doctrine of obviousness-type double patenting as being unpatentable over claim 1-2, 8-12 and 16-20 of U.S. Patent No. 12,159,698 B2 to Pait et al (“Patent Document”).
Although the conflicting claims are not identical, they are not patentably distinct from each other. Claim 1 of the Patent Document recites all the limitations of claim 1 of the instant application; however, claim 1 of the Patent Document differs since it further recites additional claim limitations including: 1)“generating, in the internal messaging format of the interface system, from the transformed first and second messages, a plurality of patient data objects corresponding to a plurality of patients, each of the plurality of patient data objects comprising patient identifying information and being generated based on combining at least one clinical data item received from the healthcare data system and at least one healthcare device data item received from a respective healthcare device,” and 2) “generating one or more first graphical user interfaces for a first third party organization and one or more second graphical user interfaces for a second third party organization, outside the healthcare organization.”
However, it would have been obvious to a person of ordinary skill in the art to modify claim 1 of the Patent Document by removing the additional limitations (1-2), resulting generally in the claims of the present application, since the claims of the present application and the claim recited in the Patent Document actually perform a similar function. It is well settled that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karison, 136 USPQ 184 (CCPA 1963). Also, note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Thus, omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
Claims 21, 25-29, 31-32 and 34-40 are rejected under the judicially created doctrine of obviousness-type double patenting as being unpatentable over claim 1-2, 8-12 and 16-20 of U.S. Patent No. 12,159,698 B2 to Pait et al (“Patent Document”).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 21-40 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 21-30 are directed to a method (i.e., a process), claims 31-39 are directed to a system (i.e., a machine) and claim 40 is directed to non-transitory computer readable medium (i.e., a manufacture). Accordingly, claims 21-40 are all within at least one of the four statutory categories.
Step 2A - Prong One:
An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Representative independent claim 31 includes limitations that recite an abstract idea. Note that independent claim 31 is the system claim, while claim 1 covers a method claim and claim 40 covers the matching computer readable medium.
Specifically, independent claim 31 recites:
A system, comprising:
one or more processors; and
a memory including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving, via an interface system in a healthcare organization, one or more messages in a first message format and comprising at least one clinical data item received from a healthcare data system or a healthcare device, wherein the healthcare data system includes a pharmacy information system or a laboratory information system, and the healthcare device includes an infusion device, ventilator, drug disposal device, or an automated medication dispensing machine;
transforming the one or more messages into an internal messaging format based on one or more predetermined transformation rules;
generating, from the transformed one or more messages, at least one patient data object;
providing, over a network by a server, a first graphical user interface to a first device associated with a first user, and a second graphical user interface to a second device associated with a second user;
receiving, via the first graphical user interface, a user instruction to create a patient specific marker threshold for the at least one clinical data item, and to configure the server to designate a recipient to receive notifications pertaining to the patient specific marker threshold;
creating the patient specific marker threshold responsive to the user instruction, and associating the patient specific marker threshold with the recipient in a database;
automatically determining that a respective patient data object of the at least one patient data object includes a value for the at least one clinical data item that satisfies the patient specific marker threshold; and
in response to the value satisfying the patient specific marker threshold:
providing a representation of the respective patient data object for display at the first device via the first graphical user interface; and
automatically causing a notification to the recipient regarding the value, and pertaining to the patient data object, to be displayed at the first device via a dialog box or a popup window.
The Examiner submits that the foregoing underlined limitations constitute: (a) “certain methods of organizing human activity” because using formatting and transforming protocol to sending messages in a healthcare organization, designating a recipient to receive notifications pertaining to a patient specific marker threshold, determining a value for clinical data item that satisfies the patient specific marker threshold, presenting a respective patient data object that notifies a recipient are parts of a medical workflow and ways of getting health care providers’ attention to patient medical matters, which relate to managing human behavior/interactions between people. Furthermore, these limitations constitute (b) “a mental process” because determining that a respective patient data object of one patient data object includes a value for the at least one clinical data item that satisfies the patient specific marker threshold is an observation/evaluation/analysis that can be performed in the human mind or with a pen and paper. The foregoing underlined limitations also relate to claims 21 and 40 (similarly to claim 31).
Accordingly, the claim describes at least one abstract idea.
In relation to claims 24-25 and 33-34, these claims merely recite specific kinds of computing devices and input data, such as: claim 24 & 33 - the first device comprises a mobile device associated with a clinician of the healthcare organization, and the first graphical user interface comprises a web application or mobile application operating on the mobile device, and claims 25 & 34 - receiving the one or more messages via an adapter module that interfaces the interface system with the healthcare data system or the healthcare device.
In relation to claims 23, 26-30, 32-33 and 35-39, these claims merely recite determining steps such as: claims 23 & 32 - enables the recipient to filter respective patient data objects based on rules created by the recipient via the first graphical user interface, claims 26 & 35- generating, in the internal messaging format of the interface system, a plurality of patient data objects corresponding to a plurality of patients, each of the plurality of patient data objects comprising patient information and being generated based on combining at least one clinical data item received from the healthcare data system and at least one healthcare device data item received from a respective healthcare device, wherein the plurality of patient data objects comprises the at least one patient data object, claims 27 & 36 - generating, in the internal messaging format of the interface system, a plurality of patient data objects corresponding to a plurality of patients, each of the plurality of patient data objects comprising patient information and being generated based on combining at least one clinical data item received from the healthcare data system and at least one healthcare device data item received from a respective healthcare device, wherein the plurality of patient data objects comprises the at least one patient data object, claims 28 & 37 - filtering the plurality of patient data objects based on first access privileges of the first user to generate first filtered patient data objects for the first user; filtering the plurality of patient data objects based on second access privileges of the second user to generate second filtered patient data objects for the second user, the second access privileges and the second filtered patient data objects being different than the first access privileges and the first filtered patient data objects, respectively; providing the first filtered patient data objects; and providing the second filtered patient data objects, claims 29 & 38 - filtering the plurality of patient data objects based on first access privileges comprising filtering the plurality of patient data objects based on the received first mapping rule, wherein at least one data field of the plurality of patient data objects is mapped to at least one different data field associated with the first user; and wherein filtering the plurality of patient data objects based on second access privileges comprising filtering the plurality of patient data objects based on the received second mapping rule, wherein at least one data field of the plurality of patient data objects is mapped to at least one different data field associated with the second user and claims 30 & 39 - identifying a data function associated with the first user, the data function configured to be applied to the plurality of patient data objects to identify patients having one or more predetermined characteristics or to identify a trend in a characteristic associated with the plurality of patient data objects, wherein filtering the plurality of patient data objects based on first access privileges comprises: applying the data function to the plurality of patient data objects to identify patients having one or more predetermined characteristics or to identify a trend in a characteristic associated with the plurality of patient data objects; and providing to the first user, an indication of the identified patients having one or more predetermined characteristics or an indication of the identified trend in the characteristic associated with the plurality of patient data objects.
Step 2A - Prong Two:
Regarding Prong Two of Step 2A, it must be determined whether the claim as a whole integrates the abstract idea into a practical application. As noted, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The limitations of claims 1, 8 and 12, as drafted is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the human mind but for the recitation of generic computer components. That is, other than reciting a system, one or more processors, a memory, a first device, a first computing device, a second device, a database, an interface system, a server, a display, a first graphical user interface, and non-transitory machine-readable medium embodying instructions that, when executed by a machine to perform the limitations, nothing in the claim elements precludes the steps from practically being performed in the human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation within a health care environment in the human mind but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” and “Mental Process” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
The judicial exception is not integrated into a practical application. In particular, the system, one or more processors, a memory, a first device, a first computing device, a second device, a database, an interface system, a server, a display, a first graphical user interface, and non-transitory machine-readable medium embodying instructions that, when executed by a machine are recited at high levels of generality (i.e., as generic computer components performing generic computer functions of receiving data/inputs, determining and providing data) such that it amounts no more than mere instructions to apply the exception using the generic computer components.
Regarding the additional limitations “machine learning”, “machine learning algorithm”, and “a machine learning model” the Examiner submits that this additional limitation amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)). Regarding the additional limitation “input a plurality of variables ……” the Examiner submits that this additional limitation merely adds insignificant pre-solution activity (data gathering; selecting data to be manipulated) to the at least one abstract idea (see MPEP § 2106.05(g)).
Thus, taken alone, the additional elements do not amount to significantly more than the above identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvements in the functioning of a computer or an improvement to another technology or technical field, apply or us the above-noted implement/use to above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (see 2019 PEG and MPEP §2106.05). Their collective functions merely provide conventional computer implementation.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer component provide an inventive concept. The claims are not patent eligible.
Step 2B:
Regarding Step 2B, in representative independent claim 31, regarding the additional limitations of the system, one or more processors, a memory, a first device, a first computing device, a second device, a database, an interface system, a server, a display, a first graphical user interface, and non-transitory machine-readable medium embodying instructions that, when executed by a machine, the Examiner submits that these limitations amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)).
Thus, representative independent claim 31 and analogous independent claims 21 and 40 do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
The dependent claims no not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reason discussed above with respect to determining that the dependent claims do not integrate the at least abstract idea into a practical application.
Therefore, claims 21-40 are ineligible under 35 USC §101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 21-25, 31-34 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Amundson (US 2012/0278093 A1) in view of Moore (US 10,217,527 B2).
Claim 21:
Amundson discloses A computer-implemented method, comprising:
receiving, via an interface system in a healthcare organization, one or more messages in a first message format and comprising at least one clinical data item received from a healthcare data system or a healthcare device, wherein the healthcare data system includes a pharmacy information system or a laboratory information system, and the healthcare device includes an infusion device, ventilator, drug disposal device, or an automated medication dispensing machine (See computing device and GUI shown in Fig. 30, mentioned in P0107, P0153-P0154, transmitting subsets of medical information, entered and converted data into worksheets for medication in [P0017-P0018] transmitted to one or more designated entities, such as, but not limited to downstream providers (i.e., pharmacies), medical insurers, attorneys, and other third parties. Also, see Fig. 2, P0038 collected medical data used when messaging from various sources with laboratory test results and prescriptions for the individual, P0054-P0055 the worksheet information converted in to medical records.);
transforming the one or more messages into an internal messaging format based on one or more predetermined transformation rules (Taught in Abstract, P0100, P0111 as encrypting transmitted data.); and
generating, from the transformed one or more messages, at least one patient data object (See P0015 special access password feature, P0050, P0052 tagged unique identifier construe patient data object. Also, see P0104-P0105 registered patient identified by a unique user ID such as a photo.).
Although Amundson discloses a method, system and software for formatting, using transformation rules and generating messages in a healthcare organization mentioned above, Amundson does not explicitly teach a network server providing a notification when a patient specific, marker threshold is satisfying among a network of users. Moore teaches:
providing, over a network by a server, a first graphical user interface to a first device associated with a first user, and a second graphical user interface to a second device associated with a second user (See Fig. 1- 2, column 4, lines 33-53, column 5, lines 1-14 and 32-45 where each system 142 provided servers per patient user 150. Also, see user interfaces in column 3, lines 15-22, column 16, lines 17-25.);
receiving, via the first graphical user interface, a user instruction to create a patient specific marker threshold for the at least one clinical data item, and to configure the server to designate a recipient to receive notifications pertaining to the patient specific marker threshold (See Fig. 12A-B, column 28, lines 17-30, column 28, line 45 to column 29, line 6 where alarm from pre-defined thresholds construe designating a recipient to receive notifications pertaining to the patient specific marker threshold.);
creating the patient specific marker threshold responsive to the user instruction, and associating the patient specific marker threshold with the recipient in a database (See Fig. 1-2, databases in column 5, lines 32-44, column 6, lines where collecting and patient monitoring include pre-defined thresholds mentioned in column 28, lines 17-30, column 28, line 45 to column 29, line 6.);
automatically determining that a respective patient data object of the at least one patient data object includes a value for the at least one clinical data item that satisfies the patient specific marker threshold (With a value as compared values determining whether the patient specific marker threshold, see monitored patient physiological parameters in column 28, line 18 to column 29, line 6.); and
in response to the value satisfying the patient specific marker threshold:
providing a representation of the respective patient data object for display at the first device via the first graphical user interface; and
automatically causing a notification to the recipient regarding the value, and pertaining to the patient data object, to be displayed at the first device via a dialog box or a popup window (See column 28, line 45 to column 29, line 6 when physiological parameter thresholds are exceeded, event summaries including exemplary priority indicating high (H), medium (M) and low (L) are displayed. Also, see Fig. 14A-B, comment section for editing and adding data mentioned in column 31, line 50 to column 32, line 9).
Therefore, it would have been obvious to one of ordinary skill in the art of unifying patient data across multiple a healthcare continuums before the effective filing date of the claimed invention to modify the method, system and software of Amundson to include a network server providing a notification when a patient specific, marker threshold is satisfying among a network of users as taught by Moore to enable timely and collaborative clinical decision-making as mentioned in Moore’s column 3, lines 1-7.
Claim 31:
Amundson discloses A system, comprising:
one or more processors; and
a memory including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations (See Fig. 30, P0039-P0040, P0112, P0153-P0155 processors and memory.) comprising:
receiving, via an interface system in a healthcare organization, one or more messages in a first message format and comprising at least one clinical data item received from a healthcare data system or a healthcare device, wherein the healthcare data system includes a pharmacy information system or a laboratory information system, and the healthcare device includes an infusion device, ventilator, drug disposal device, or an automated medication dispensing machine (See computing device and GUI shown in Fig. 30, mentioned in P0107, P0153-P0154, transmitting subsets of medical information, entered and converted data into worksheets for medication in [P0017-P0018] transmitted to one or more designated entities, such as, but not limited to downstream providers (i.e., pharmacies), medical insurers, attorneys, and other third parties. Also, see Fig. 2, P0038 collected medical data used when messaging from various sources with laboratory test results and prescriptions for the individual, P0054-P0055 the worksheet information converted in to medical records.);
transforming the one or more messages into an internal messaging format based on one or more predetermined transformation rules (Taught in Abstract, P0100, P0111 as encrypting transmitted data.); and
generating, from the transformed one or more messages, at least one patient data object (See P0015 special access password feature, P0050, P0052 tagged unique identifier construe patient data object. Also, see P0104-P0105 registered patient identified by a unique user ID such as a photo.).
Although Amundson discloses a method, system and software for formatting, using transformation rules and generating messages in a healthcare organization mentioned above, Amundson does not explicitly teach a network server providing a notification when a patient specific, marker threshold is satisfying among a network of users. Moore teaches:
providing, over a network by a server, a first graphical user interface to a first device associated with a first user, and a second graphical user interface to a second device associated with a second user (See Fig. 1- 2, column 4, lines 33-53, column 5, lines 1-14 and 32-45 where each system 142 provided servers per patient user 150. Also, see user interfaces in column 3, lines 15-22, column 16, lines 17-25.);
receiving, via the first graphical user interface, a user instruction to create a patient specific marker threshold for the at least one clinical data item, and to configure the server to designate a recipient to receive notifications pertaining to the patient specific marker threshold (See Fig. 12A-B, column 28, lines 17-30, column 28, line 45 to column 29, line 6 where alarm from pre-defined thresholds construe designating a recipient to receive notifications pertaining to the patient specific marker threshold.);
creating the patient specific marker threshold responsive to the user instruction, and associating the patient specific marker threshold with the recipient in a database (See Fig. 1-2, databases in column 5, lines 32-44, column 6, lines where collecting and patient monitoring include pre-defined thresholds mentioned in column 28, lines 17-30, column 28, line 45 to column 29, line 6.);
automatically determining that a respective patient data object of the at least one patient data object includes a value for the at least one clinical data item that satisfies the patient specific marker threshold (With a value as compared values determining whether the patient specific marker threshold, see monitored patient physiological parameters in column 28, line 18 to column 29, line 6.); and
in response to the value satisfying the patient specific marker threshold:
providing a representation of the respective patient data object for display at the first device via the first graphical user interface; and
automatically causing a notification to the recipient regarding the value, and pertaining to the patient data object, to be displayed at the first device via a dialog box or a popup window (See column 28, line 45 to column 29, line 6 when physiological parameter thresholds are exceeded, event summaries including exemplary priority indicating high (H), medium (M) and low (L) are displayed. Also, see Fig. 14A-B, comment section for editing and adding data mentioned in column 31, line 50 to column 32, line 9).
Therefore, it would have been obvious to one of ordinary skill in the art of unifying patient data across multiple a healthcare continuums before the effective filing date of the claimed invention to modify the method, system and software of Amundson to include a network server providing a notification when a patient specific, marker threshold is satisfying among a network of users as taught by Moore to enable timely and collaborative clinical decision-making as mentioned in Moore’s column 3, lines 1-7.
Claim 40:
Amundson discloses A non-transitory machine-readable medium embodying instructions that, when executed by a machine, allow the machine to perform a method for providing aggregated patient-specific data (See Fig. 30, P0042-P0043 and P0106-P0107 and computer system implemented as computer-readable code in P0153.), the method comprising:
receiving, via an interface system in a healthcare organization, one or more messages in a first message format and comprising at least one clinical data item received from a healthcare data system or a healthcare device, wherein the healthcare data system includes a pharmacy information system or a laboratory information system, and the healthcare device includes an infusion device, ventilator, drug disposal device, or an automated medication dispensing machine (See computing device and GUI shown in Fig. 30, mentioned in P0107, P0153-P0154, transmitting subsets of medical information, entered and converted data into worksheets for medication in [P0017-P0018] transmitted to one or more designated entities, such as, but not limited to downstream providers (i.e., pharmacies), medical insurers, attorneys, and other third parties. Also, see Fig. 2, P0038 collected medical data used when messaging from various sources with laboratory test results and prescriptions for the individual, P0054-P0055 the worksheet information converted in to medical records.);
transforming the one or more messages into an internal messaging format based on one or more predetermined transformation rules (Taught in Abstract, P0100, P0111 as encrypting transmitted data.); and
generating, from the transformed one or more messages, at least one patient data object (See P0015 special access password feature, P0050, P0052 tagged unique identifier construe patient data object. Also, see P0104-P0105 registered patient identified by a unique user ID such as a photo.).
Although Amundson discloses a method, system and software for formatting, using transformation rules and generating messages in a healthcare organization mentioned above, Amundson does not explicitly teach a network server providing a notification when a patient specific, marker threshold is satisfying among a network of users. Moore teaches:
providing, over a network by a server, a first graphical user interface to a first device associated with a first user, and a second graphical user interface to a second device associated with a second user (See Fig. 1- 2, column 4, lines 33-53, column 5, lines 1-14 and 32-45 where each system 142 provided servers per patient user 150. Also, see user interfaces in column 3, lines 15-22, column 16, lines 17-25.);
receiving, via the first graphical user interface, a user instruction to create a patient specific marker threshold for the at least one clinical data item, and to configure the server to designate a recipient to receive notifications pertaining to the patient specific marker threshold (See Fig. 12A-B, column 28, lines 17-30, column 28, line 45 to column 29, line 6 where alarm from pre-defined thresholds construe designating a recipient to receive notifications pertaining to the patient specific marker threshold.);
creating the patient specific marker threshold responsive to the user instruction, and associating the patient specific marker threshold with the recipient in a database (See Fig. 1-2, databases in column 5, lines 32-44, column 6, lines where collecting and patient monitoring include pre-defined thresholds mentioned in column 28, lines 17-30, column 28, line 45 to column 29, line 6.);
automatically determining that a respective patient data object of the at least one patient data object includes a value for the at least one clinical data item that satisfies the patient specific marker threshold (With a value as compared values determining whether the patient specific marker threshold, see monitored patient physiological parameters in column 28, line 18 to column 29, line 6.); and
in response to the value satisfying the patient specific marker threshold:
providing a representation of the respective patient data object for display at the first device via the first graphical user interface; and
automatically causing a notification to the recipient regarding the value, and pertaining to the patient data object, to be displayed at the first device via a dialog box or a popup window (See column 28, line 45 to column 29, line 6 when physiological parameter thresholds are exceeded, event summaries including exemplary priority indicating high (H), medium (M) and low (L) are displayed. Also, see Fig. 14A-B, comment section for editing and adding data mentioned in column 31, line 50 to column 32, line 9).
Therefore, it would have been obvious to one of ordinary skill in the art of unifying patient data across multiple a healthcare continuums before the effective filing date of the claimed invention to modify the method, system and software of Amundson to include a network server providing a notification when a patient specific, marker threshold is satisfying among a network of users as taught by Moore to enable timely and collaborative clinical decision-making as mentioned in Moore’s column 3, lines 1-7.
Regarding claim 22, Amundson and Moore teach the computer-implemented method of Claim 21 mentioned above, and Amundson discloses wherein each patient data object comprises information that identifies a patient and at least one of: a setting of the healthcare device, monitoring information from a device configured to monitor a vital sign or physiological response, and billing information for the patient (See exam data fields and a provider navigating vital signs interface mentioned in P0143-P0144 shown in Fig. 18-19. Also, see billing reports in P0059, P0067.).
Regarding claims 23 and 32, although Amundson and Moore teach the computer-implemented method of Claim 21 and the system claim of 31 mentioned above, Moore teaches wherein the first graphical user interface enables the recipient to filter respective patient data objects based on rules created by the recipient via the first graphical user interface (See Fig. 15A exemplary filtered medication screen mentioned in column 32, line 55 to column 33, line 5.).
Therefore, it would have been obvious to one of ordinary skill in the art of unifying patient data across multiple a healthcare continuums before the effective filing date of the claimed invention to modify the method, system and software of Amundson to include a graphical user interface enabling the recipient to filter respective patient data objects based on rules created by the recipient as taught by Moore to enable timely and collaborative clinical decision-making as mentioned in Moore’s column 3, lines 1-7.
Regarding claims 24 and 33, Amundson and Moore teach the computer-implemented method of claim 21 and the system of claim 31 mentioned above, Amundson discloses wherein the first device comprises a mobile device associated with a clinician of the healthcare organization, and the first graphical user interface comprises a web application or mobile application operating on the mobile device (See mobile client device in P0016, P0042-P0043 and GUI in P0012, P0053.).
Regarding claims 25 and 34, Amundson and Moore teach the computer-implemented method of claim 21 and the system of claim 31 mentioned above, Amundson discloses further comprising: receiving the one or more messages via an adapter module that interfaces the interface system with the healthcare data system or the healthcare device (See sending messages in P0038, P0046.).
Claims 26-30 and 35-39 are rejected under 35 U.S.C. 103 as being unpatentable over Amundson (US 2012/0278093 A1) in view of Moore (US 10,217,527 B2) further in view of Fotsch (US 2005/0165627 A1).
Regarding claims 26 and 35, although Amundson and Moore teach the computer-implemented method of Claim 21 and the system of claim 31 mentioned above, Amundson and Moore do not explicitly teach generating internal messages corresponding to patient data objectives based on combining clinical data items. Fotsch teaches:
further comprising: receiving clinical data items from the healthcare data system and healthcare device data items from a respective healthcare device (See implantable devices and special clinical information related to the patient's health in P0047.); and generating, in the internal messaging format of the interface system, a plurality of patient data objects corresponding to a plurality of patients, each of the plurality of patient data objects comprising patient information and being generated based on combining at least one clinical data item received from the healthcare data system and at least one healthcare device data item received from a respective healthcare device, wherein the plurality of patient data objects comprises the at least one patient data object (See Fig. 9, links to secure received messages in P0047-P0049 and attaching documentation such as lab or x-ray results in P0101.).
Therefore, it would have been obvious to one of ordinary skill in the art of managing personal health records before the effective filing date of the claimed invention to modify the method and system of Amundson and Moore to include generating internal messages corresponding to patient data objectives based on combining clinical data items as taught by Fotsch for integrating patient information into a single repository and helping patients do a better job of managing conditions/diseases as mentioned in Fotsch’s P0011-P0012.
Regarding claims 27 and 36, Amundson, Moore and Fotsch teach the computer-implemented method of Claim 26 and the system of claim 35 mentioned above, and Amundson discloses further comprising: receiving from the first device a user request for aggregated patient data; responsive to the user request: determining predetermined access privileges of the first user (See P0054, P0064 requesting patient data and [P0109] The web program may initiate a terminal reception routine wherein the routine requests user to enter the encryption key and identification information (i.e., a unique user ID 120).); generating, based on the predetermined access privileges, from the plurality of patient data objects, patient deidentified data objects based on removing patient identifiable information from the plurality of patient data objects and replacing the patient identifiable information with patient unidentifiable information; providing, over a network, the patient deidentified data objects to the first device for display by the first graphical user interface (Taught in P0015, P0073 as encryption routines, P0052, P0100, P0107 and accessing patient data using HIPAA compliant encryption.).
Regarding claims 28 and 37, Amundson, Moore and Fotsch teach the computer-implemented method of Claim 26 and the system of claim 35 mentioned above, and Amundson discloses further comprising: filtering the plurality of patient data objects based on first access privileges of the first user to generate first filtered patient data objects for the first user; filtering the plurality of patient data objects based on second access privileges of the second user to generate second filtered patient data objects for the second user, the second access privileges and the second filtered patient data objects being different than the first access privileges and the first filtered patient data objects, respectively; providing the first filtered patient data objects to the first device for display via the first graphical user interface; and providing the second filtered patient data objects to the second device for display via the second graphical user interface (Taught as filtering by provider’s privileges distinguished from an administrator in P0100-P0103 as administrator privileges 1030 and super administrator privileges 1040 shown in Fig. 10 Sign In Authorization Levels.).
Regarding claims 29 and 38, Amundson and Moore teach the computer-implemented method of Claim 28 and the system of claim 37 mentioned above, and Amundson discloses further comprising: receiving a first mapping rule selected by the first user; receiving a second mapping rule selected by the second user; wherein filtering the plurality of patient data objects based on first access privileges comprising filtering the plurality of patient data objects based on the received first mapping rule, wherein at least one data field of the plurality of patient data objects is mapped to at least one different data field associated with the first user; and wherein filtering the plurality of patient data objects based on second access privileges comprising filtering the plurality of patient data objects based on the received second mapping rule, wherein at least one data field of the plurality of patient data objects is mapped to at least one different data field associated with the second user (See P0058 mapping conversion of worksheet data fields and elements into a medical record 232 shown in Fig. 2.).
Regarding claims 30 and 39, although Amundson and Moore teach the computer-implemented method of Claim 28 and the system claim of 37 mentioned above, Moore teaches further comprising: identifying a data function associated with the first user, the data function configured to be applied to the plurality of patient data objects to identify patients having one or more predetermined characteristics or to identify a trend in a characteristic associated with the plurality of patient data objects (See an access control sub-module when using trend graphs in column 7, line 65 to column 8, lines 23, trend visualization of identifiers in column 13, lines 20-34 and analytical and trended data in See column 23, lines 47.), wherein filtering the plurality of patient data objects based on first access privileges comprises: applying the data function to the plurality of patient data objects to identify patients having one or more predetermined characteristics or to identify a trend in a characteristic associated with the plurality of patient data objects (See user selecting higher level trend graphs and tables column 26, line 61 to column 27, line 6, column 27, lines 33-43. Also, see physiological characteristics in column 5, lines 1-16 and waveform micro-characteristics viewing patterns in column 15, lines 8-18.); and providing, to the first device for display to the first user, an indication of the identified patients having one or more predetermined characteristics or an indication of the identified trend in the characteristic associated with the plurality of patient data objects (See alerting when patients require immediate attention in column 21, lines 56-63. Also, see column 28, line 45 to column 29, line 6 when physiological parameter thresholds are exceeded, event summaries including exemplary priority indicating high (H), medium (M) and low (L) are displayed, Fig. 15A exemplary filtered medication screen mentioned in column 32, line 55 to column 33, line 5.).
Therefore, it would have been obvious to one of ordinary skill in the art of unifying patient data across multiple a healthcare continuums before the effective filing date of the claimed invention to modify the method, system and software of Amundson to include applying patient data objects to identifying patients having predetermined characteristics or to identify a trend in a characteristic associated with the patient data objects as taught by Moore to enable timely and collaborative clinical decision-making as mentioned in Moore’s column 3, lines 1-7.
Regarding claim 35, although Amundson and Moore teach the computer-implemented system of Claim 31 mentioned above, Amundson and Moore do not explicitly teach generating internal messages corresponding to patient data objectives based on combining clinical data items. Fotsch teaches:
the operations further comprising: receiving clinical data items from the healthcare data system and healthcare device data items from a respective healthcare device (See implantable devices and special clinical information related to the patient's health in P0047.); and generating, in the internal messaging format of the interface system, a plurality of patient data objects corresponding to a plurality of patients, each of the plurality of patient data objects comprising patient information and being generated based on combining at least one clinical data item received from the healthcare data system and at least one healthcare device data item received from a respective healthcare device, wherein the plurality of patient data objects comprises the at least one patient data object (See Fig. 9, links to secure received messages in P0047-P0049 and attaching documentation such as lab or x-ray results in P0101.).
Therefore, it would have been obvious to one of ordinary skill in the art of managing personal health records before the effective filing date of the claimed invention to modify the method and system of Amundson and Moore to include generating internal messages corresponding to patient data objectives based on combining clinical data items as taught by Fotsch for integrating patient information into a single repository and helping patients do a better job of managing conditions/diseases as mentioned in Fotsch’s P0011-P0012.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Goldberg (US 2013/0018668 A1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TERESA S WILLIAMS whose telephone number is (571)270-5509. The examiner can normally be reached Mon-Fri, 8:30 am -6:30 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, Mamon Obeid can be reached at (571) 270-1813. 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.
/T.S.W./Examiner, Art Unit 3687 06/20/2026
/MAMON OBEID/Supervisory Patent Examiner, Art Unit 3687
Prosecution Insights