DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 9-11 and 14 are objected to because of the following informalities:
Claims 9-11 and 14: The recitation of “wherein the operations further comprise”, should read ---wherein the set of operations further comprise---, to clear any antecedent basis issues.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-4 and 8-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1 and 8, the recitation of “current ventilator settings” and any other dependent claim(s) with the same recitation as such. It is unclear as to what the actual settings are that are current. Using broadest reasonable interpretation without sufficient description of the current ventilator settings, it is interpreted to be either settings, data, or information that can be transmitted or received by the ventilators.
Regarding claims 2 and 9, the recitation of “subset of current ventilator settings” and any other dependent claim(s) with the same recitation as such. It is unclear as to what the actual subset of the current ventilator settings are. Using broadest reasonable interpretation without sufficient description of the current ventilator settings, it is interpreted to be a subset of either settings, data, or information that can be transmitted or received by the ventilators.
Regarding claims 3 and 10, the recitation of “ventilator settings” and any other dependent claim(s) with the same recitation as such. It is unclear as to whether the ventilator settings here are different from the current ventilator settings. Using broadest reasonable interpretation without sufficient description of the ventilator settings, it is interpreted to be the same as the current ventilator settings: either settings, data, or information that can be transmitted or received by the ventilators.
Regarding claims 4 and 11, the recitation of “recommended ventilator settings” and any other dependent claim(s) with the same recitation as such. It is unclear as to what the actual recommended settings are. Using broadest reasonable interpretation without sufficient detail of the recommended ventilator settings, it is understood to be interpreted as any ventilator setting, data, information, that is generated, predicted, or suggested.
Regarding claim 8: Per MPEP 2173.05(p): A single claim which claims both an apparatus and the method steps of using the apparatus is indefinite under 35 U.S.C. 112(b). A product-by-process claim is proper when it is clear the claim is directed to the product and not the process. It is unclear as to whether the claim is directed towards a product or process. To avoid improperly reciting method steps in a device claim, the recitation of “memory storing instructions that, when executed by the processor, cause the medical ventilator to perform a set of operations comprising”, should be read as --- memory storing instructions that, when executed by the processor, are configured to cause the medical ventilator to perform a set of operations comprising---.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 and 8 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In accordance with MPEP 2106.04, each of Claims 1 and 8 have been analyzed to determine whether it is directed to any judicial exceptions.
Step 2A, Prong 1 per MPEP 2106.04(a)
Each of Claims 1 and 8 recites at least one step or instruction for an observation or judgement, which is grouped as a mental process in MPEP 2106.04(a)(2)(III).
List of abstract ideas in MPEP 2106.04(a)(2):
1) Mathematical concepts – mathematical relationships, mathematical formulas or equations, mathematical calculations (see MPEP 2106.04(a)(2)(I));
2) Certain methods of organizing human activity – fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) (see MPEP 2106.04(a)(2)(II)); and
3) Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP 2106.04(a)(2)(III))
Accordingly, each of Claims 1 and 8 recites an abstract idea.
Specifically, Claim 1 recites a method for transferring ventilator settings from one medical ventilator to another medical ventilator ((judgment or evaluation, which is grouped as a mental process in MPEP 2106.04(a)(2)(III)).), the method comprising (additional element): receiving a selection to initiate a transfer of current ventilator settings to a receiving ventilator ((judgment or evaluation, which is grouped as a mental process in MPEP 2106.04(a)(2)(III)).), the current ventilator settings corresponding to settings currently being used by the medical ventilator to provide ventilation to a patient (additional element); exchanging identification data with the receiving ventilator; based on the exchanged identification data, establishing communication with the receiving ventilator ((judgment or evaluation, which is grouped as a mental process in MPEP 2106.04(a)(2)(III)).); and prior to the patient being disconnected from the medical ventilator (additional element), transmitting the current ventilator settings to the receiving ventilator ((judgment or evaluation, which is grouped as a mental process in MPEP 2106.04(a)(2)(III)).).
Further, dependent Claims 2-7 merely include limitations that either further define the abstract idea (and thus don’t make the abstract idea any less abstract) or amount to no more than generally linking the use of the abstract idea to a particular technological environment or field of use because they’re merely incidental or token additions to the claims that do not alter or affect how the claimed functions/steps are performed.
Additionally, Claim 8 recites a medical ventilator for transferring ventilator settings, the ventilator comprising: a display; a processor; and memory storing instructions that, when executed by the processor, cause the medical ventilator to perform a set of operations comprising: delivering ventilation to a patient based on current ventilator settings (additional element); receiving a selection to initiate a transfer of the current ventilator settings to a receiving ventilator; exchanging identification data with the receiving ventilator; based on the exchanged identification data, establishing communication with the receiving ventilator ((judgment or evaluation, which is grouped as a mental process in MPEP 2106.04(a)(2)(III)).); and prior to the patient being disconnected from the medical ventilator (additional element), transmitting the current ventilator settings to the receiving ventilator ((judgment or evaluation, which is grouped as a mental process in MPEP 2106.04(a)(2)(III)).).
Further, dependent Claims 9-14 merely include limitations that either further define the abstract idea (and thus don’t make the abstract idea any less abstract) or amount to no more than generally linking the use of the abstract idea to a particular technological environment or field of use because they’re merely incidental or token additions to the claims that do not alter or affect how the claimed functions/steps are performed.
Accordingly, as indicated above, each of the above-identified claims recites an abstract idea as in MPEP 2106.04(a).
Step 2A, Prong 2 per MPEP 2106.04(d)
The above-identified abstract ideas in each of independent Claims 1 and 8 (and their respective dependent Claims 2-7, 9-14) are not integrated into a practical application under MPEP 2106.04(d) because the additional elements (identified above in independent Claims 1 and 8), either alone or in combination, generally link the use of the above-identified abstract ideas to a particular technological environment or field of use according to MPEP 2106.05(h) or represent insignificant extra-solution activity according to MPEP 2106.05(g). More specifically the independent claims require the additional elements of: the current ventilator settings corresponding to settings currently being used by the medical ventilator to provide ventilation to a patient, prior to the patient being disconnected from the medical ventilator, and a medical ventilator for transferring ventilator settings, the ventilator comprising: a display; a processor; and memory storing instructions that, when executed by the processor, cause the medical ventilator to perform a set of operations comprising: delivering ventilation to a patient based on current ventilator settings are generically recited data gathering steps are components in independent Claims 1 and 8 (and their respective dependent claims) which do not improve the functioning of a computer, or any other technology or technical field according to MPEP 2106.04(d)(1) and 2106.05(a). Nor do these above-identified additional elements serve to apply the above-identified abstract ideas with, or by use of, a particular machine according to MPEP 2106.05(b), effect a transformation according to MPEP 2106.05(c), provide a particular treatment or prophylaxis according to MPEP 2106.04(d)(2) or apply or use the above-identified abstract ideas in some other meaningful way beyond generally linking the use thereof to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception according to MPEP 2106.04(d)(2) and 2106.05(e). Furthermore, the above-identified additional elements do not add a meaningful limitation to the abstract ideas because they amount to simply implementing the abstract ideas on a computer in accordance with MPEP 2106.05(f). For at least these reasons, the abstract ideas identified above in independent Claims 1 and 8 (and their respective dependent claims) are not integrated into a practical application in accordance with MPEP 2106.04(d).
Moreover, the above-identified abstract ideas are not integrated into a practical application in accordance with MPEP 2106.04(d) because the claimed method and system merely implements the above-identified abstract ideas (e.g., mental process and certain method of organizing human activity) using rules (e.g., computer instructions) executed by a computer (processor as claimed). In other words, these claims are merely directed to abstract ideas with additional generic computer elements which do not add a meaningful limitation to the abstract ideas because they amount to simply implementing the abstract ideas on a computer according to MPEP 2106.05(f). Additionally, Applicant’s specification does not include any discussion of how the claimed invention provides a technical improvement realized by these claims over the prior art or any explanation of a technical problem having an unconventional technical solution that is expressed in these claims according to MPEP 2106.05(a). That is, like Affinity Labs of Tex. v. DirecTV, LLC, the specification fails to provide sufficient details regarding the manner in which the claimed invention accomplishes any technical improvement or solution. Thus, for these additional reasons, the abstract ideas identified above in independent Claims 1 and 8 (and their respective dependent claims) are not integrated into a practical application under MPEP 2106.04(d)(I).
Accordingly, independent Claims 1 and 8 (and their respective dependent claims) are each directed to an abstract idea according to MPEP 2106.04(d).
Step 2B per MPEP 2106.05
None of Claims 1 and 8 include additional elements that are sufficient to amount to significantly more than the abstract idea in accordance with MPEP 2106.05 for at least the following reasons.
Specifically the independent claims require the additional elements of: the current ventilator settings corresponding to settings currently being used by the medical ventilator to provide ventilation to a patient, prior to the patient being disconnected from the medical ventilator, and a medical ventilator for transferring ventilator settings, the ventilator comprising: a display; a processor; and memory storing instructions that, when executed by the processor, cause the medical ventilator to perform a set of operations comprising: delivering ventilation to a patient based on current ventilator settings.
The above-identified additional elements use generically claimed computer components which enable the above-identified abstract idea(s) to be conducted by performing the basic functions of automating mental tasks. The courts have recognized such computer functions as well understood, routine, and conventional functions when claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. See, MPEP 2106.05(d)(II) along with Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); and OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
In light of Applicant’s specification, the claimed terms “processor” and “memory” are reasonably construed as generic computing devices. Like SAP America vs Investpic, LLC (Federal Circuit 2018), it is clear, from the claims themselves and the specification, that these limitations require no improved computer resources, just already available technology, with their already available basic functions, to use as tools in executing the claimed process. See MPEP 2106.05(f).
The recitation of the above-identified additional limitations in Claims 1 and 8 amounts to mere instructions to implement the abstract idea on a computer. Simply using a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, exchange, or transmit data) or simply adding a general-purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not provide significantly more. See MPEP 2106.05(f) along with Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); and TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Moreover, implementing an abstract idea on a generic computer, does not add significantly more, similar to how the recitation of the computer in the claim in Alice amounted to mere instructions to apply the abstract idea of intermediated settlement on a generic computer.
A claim that purports to improve computer capabilities or to improve an existing technology may provide significantly more. See MPEP 2106.05(a) along with McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1314-15, 120 USPQ2d 1091, 1101-02 (Fed. Cir. 2016); and Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36, 118 USPQ2d 1684, 1688-89 (Fed. Cir. 2016). However, a technical explanation as to how to implement the invention should be present in the specification for any assertion that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes. That is, per MPEP 2106.05(a), the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. Here, Applicant’s specification does not include any discussion of how the claimed invention provides a technical improvement realized by these claims over the prior art or any explanation of a technical problem having an unconventional technical solution that is expressed in these claims. Instead, as in Affinity Labs of Tex. v. DirecTV, LLC 838 F.3d 1253, 1263-64, 120 USPQ2d 1201, 1207-08 (Fed. Cir. 2016), the specification fails to provide sufficient details regarding the manner in which the claimed invention accomplishes any technical improvement or solution.
For at least the above reasons, the method of Claims 1 and the device of Claim 8 are directed to applying an abstract idea as identified above on a general purpose computer without (i) improving the performance of the computer itself or providing a technical solution to a problem in a technical field according to MPEP 2106.05(a), or (ii) providing meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that these claims amount to significantly more than the abstract idea itself according to MPEP 2106.04(d)(2) and 2106.05(e).
Taking the additional elements individually and in combination, the additional elements do not provide significantly more. Specifically, when viewed individually, the above-identified additional elements in independent Claims 1 and 8 (and their dependent claims) do not add significantly more because they are simply an attempt to limit the abstract idea to a particular technological environment according to MPEP 2106.05(h). When viewed as a combination, these above-identified additional elements simply instruct the practitioner to implement the claimed functions with well-understood, routine and conventional activity specified at a high level of generality in a particular technological environment according to MPEP 2106.05(h). When viewed as whole, the above-identified additional elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself according to MPEP 2106.04(d)(2) and 2106.05(e). Moreover, neither the general computer elements nor any other additional element adds meaningful limitations to the abstract idea because these additional elements represent insignificant extra-solution activity according to MPEP 2106.05(g). As such, there is no inventive concept sufficient to transform the claimed subject matter into a patent-eligible application as required by MPEP 2106.05.
Therefore, for at least the above reasons, none of the Claims 1 and 8 amount to significantly more than the abstract idea itself. Accordingly, Claims 1 and 8 are not patent eligible and rejected under 35 U.S.C. 101.
Examiner note: It is suggested in order to help overcome the 101 rejections, that the Applicant amends the claims rejected under 101 to have an output to receiving, exchanging, establishing communication, and transmitting data (settings) - (abstract ideas listed above), similarly to claim 15 (independent claim without a 101 rejection).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 7-10, 14, 15, and 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Steinhauer (US 20130104893 A1).
Regarding claim 1, Steinhauer discloses:
a method for transferring ventilator settings from one medical ventilator to another medical ventilator (Steinhauer Figure 2; where the ventilators have bidirectional communication with each other);
the method comprising: receiving a selection to initiate a transfer of current ventilator settings to a receiving ventilator (Steinhauer [0109]; where the ventilator has user input, and the ventilator automatically implements the selected protocol, [0071]; where ventilator information is transmitted by the ventilator, Figure 2; where there is bidirectional communication, so the user input could be initiating the transfer of current settings (ventilator information));
the current ventilator settings corresponding to settings currently being used by the medical ventilator to provide ventilation to a patient (Steinhauer [0073]; where ventilator data can be any information generated by the ventilator or associated with functionality in regards to patient care – current ventilator settings corresponding to settings being used by ventilator);
exchanging identification data with the receiving ventilator (Steinhauer [0074]; context data is any information to provide context to the ventilator data, e.g. the ventilator ID, Figure 2; bidirectional communication of the ventilators, therefore any information can be transferred or received by the ventilators);
based on the exchanged identification data, establishing communication with the receiving ventilator (Steinhauer Figure 2; where the ventilator is in bidirectional communication with another ventilator (communication with receiving ventilator), Figure 6; where the ventilator can access the ventilator ID ‘624’, and then transmit the data ‘640’ (exchanging identification data), [0142]; where the transmitter establishes the communication/data to a ventilator (establishing communication with a ventilator));
and prior to the patient being disconnected from the medical ventilator, transmitting the current ventilator settings to the receiving ventilator (Steinhauer Figure 2; where the ventilator communicates with another ventilator, [0188]; during the use of the system, ventilators are in operation with the respective patient (prior to the patient being disconnected = still in operation), [0189]; ventilators are able to have bidirectional communication with the system (transmitting settings), [0187]; system can be directly coupled to ventilators or within the ventilators (transmitting settings to a receiving ventilator)).
Regarding claim 2, Steinhauer further discloses the method of claim 1, further comprising:
receiving a selection of a subset of the current ventilator settings for transfer to the receiving ventilator (Steinhauer [0090]; where a subset of data is accessed for a subset of ventilator actions (subset of current ventilator settings) – by accessing the data, it would have to be received, Figure 2; where the ventilators communicate with each other bidirectional to transmit settings);
and wherein transmitting the current ventilator settings includes transmitting the selected subset of the current ventilator settings (Steinhauer [0090]; where there is a subset of current ventilator settings as previously described, Figure 2; where the ventilators communicate bidirectionally to transmit settings – a caregiver can access this subset of settings and select it to be transmitted, [0090]; certain actions can be associated with a subset of ventilator actions (settings)).
Regarding claim 3, Steinhauer further discloses the method of claim 1, further comprising:
displaying a transfer settings interface including a setting-selection menu and a transfer activation element (Steinhauer [0099]; where the display screen ‘730’ is for displaying ventilator information, [0109]; a caregiver can select which ventilator protocol to implement via the display screen, Figure 9; where there is ventilator protocol accessor ‘915’ (setting-selection menu) and implementer ‘920’, Figure 27; the transfer settings interface, where there is a transmitter ‘2750’ button on the screen (transfer activation element));
receiving, via the setting-selection menu, a selection of a subset of ventilator settings for transfer to the receiving ventilator (Steinhauer; Figure 2 where the ventilators are in bidirectional communication, [0109]; where the caregiver can select the ventilator protocol to implement via the display screen [0071]; where the ventilator information is transmitted by the ventilator and is associated with the manipulation of ventilator functionality, Figure 27; the transmitter ‘2750’ sends the settings/ data);
receiving a selection of the transfer activation element (Steinhauer Figure 27; there the transmitter ‘2750’ is a button on the display screen that is the transfer activation element to transmit settings, when pressed, that is receiving the selectin of the transfer activation element);
and based on receiving the selection of the transfer activation element initiating the transmission, wherein transmitting the ventilator settings includes transmitting the selected subset of ventilator settings (Steinhauer Figure 27; where the transmitter ‘2750’ (transfer activation element on the screen), initiates the transmission of the settings of the ventilators, [0090]; where there is a subset of current ventilator settings as previously described, Figure 2; where the ventilators communicate bidirectionally to transmit settings – a caregiver can access this subset of settings and select it to be transmitted, [0090]; certain actions can be associated with a subset of ventilator actions (settings)).
Regarding claim 7, Steinhauer further discloses the method of claim 1, further comprising transmitting, to the receiving ventilator, patient data for the patient (Steinhauer Figure 2; where there is bidirectional communication of the ventilators (transmitting to the receiving ventilator), [0167]; where the patient ID (data) is pushed to the ventilator via transmission).
Regarding claim 8, Steinhauer further discloses a medical ventilator for transferring ventilator settings (Steinhauer Figure 2; bidirectional communication of the two ventilators for transferring settings) the ventilator comprising:
a display (Steinhauer Figure 7; ‘730’);
a processor (Steinhauer Figure 7; ‘720’);
and memory storing instructions that, when executed by the processor, cause the medical ventilator to perform a set of operations (Steinhauer [0098]; where the memory ‘725’ of Figure 7 is for storing ventilator information, [0113]; where the memory holds computer executable instructions);
comprising: delivering ventilation to a patient based on current ventilator settings (Steinhauer [0042]; where the ventilator delivers ventilation to a patient and [0047]; where communication of the ventilators is based on the ventilator settings (current ventilator settings), thereby when the settings are transferred, the patient gets ventilation delivered to them);
receiving a selection to initiate a transfer of current ventilator settings to a receiving ventilator (Steinhauer [0109]; where the ventilator has user input, and the ventilator automatically implements the selected protocol, [0071]; where ventilator information is transmitted by the ventilator, Figure 2; where there is bidirectional communication, so the user input could be initiating the transfer of current settings (ventilator information));
the current ventilator settings corresponding to settings currently being used by the medical ventilator to provide ventilation to a patient (Steinhauer [0073]; where ventilator data can be any information generated by the ventilator or associated with functionality in regards to patient care – current ventilator settings corresponding to settings being used by ventilator);
exchanging identification data with the receiving ventilator (Steinhauer [0074]; context data is any information to provide context to the ventilator data, e.g. the ventilator ID, Figure 2; bidirectional communication of the ventilators, therefore any information can be transferred or received by the ventilators);
based on the exchanged identification data, establishing communication with the receiving ventilator (Steinhauer Figure 2; where the ventilator is in bidirectional communication with another ventilator (communication with receiving ventilator), Figure 6; where the ventilator can access the ventilator ID ‘624’, and then transmit the data ‘640’ (exchanging identification data), [0142]; where the transmitter establishes the communication/data to a ventilator (establishing communication with a ventilator));
and prior to the patient being disconnected from the medical ventilator, transmitting the current ventilator settings to the receiving ventilator (Steinhauer Figure 2; where the ventilator communicates with another ventilator, [0188]; during the use of the system, ventilators are in operation with the respective patient (prior to the patient being disconnected = still in operation), [0189]; ventilators are able to have bidirectional communication with the system (transmitting settings), [0187]; system can be directly coupled to ventilators or within the ventilators (transmitting settings to a receiving ventilator)).
Regarding claim 9, Steinhauer further discloses the ventilator of claim 8, wherein the operations further comprise:
receiving a selection of a subset of the current ventilator settings for transfer to the receiving ventilator (Steinhauer [0090]; where a subset of data is accessed for a subset of ventilator actions (subset of current ventilator settings) – by accessing the data, it would have to be received, Figure 2; where the ventilators communicate with each other bidirectional to transmit settings);
and wherein transmitting the current ventilator settings includes transmitting the selected subset of the current ventilator settings (Steinhauer [0090]; where there is a subset of current ventilator settings as previously described, Figure 2; where the ventilators communicate bidirectionally to transmit settings – a caregiver can access this subset of settings and select it to be transmitted, [0090]; certain actions can be associated with a subset of ventilator actions (settings)).
Regarding claim 10, Steinhauer further discloses the ventilator of claim 8, wherein the operations further comprise:
displaying a transfer settings interface including a setting-selection menu and a transfer activation element (Steinhauer [0099]; where the display screen ‘730’ is for displaying ventilator information, [0109]; a caregiver can select which ventilator protocol to implement via the display screen, Figure 9; where there is ventilator protocol accessor ‘915’ (setting-selection menu) and implementer ‘920’, Figure 27; the transfer settings interface, where there is a transmitter ‘2750’ button on the screen (transfer activation element));
receiving, via the setting-selection menu, a selection of a subset of ventilator settings for transfer to the receiving ventilator (Steinhauer; Figure 2 where the ventilators are in bidirectional communication, [0109]; where the caregiver can select the ventilator protocol to implement via the display screen [0071]; where the ventilator information is transmitted by the ventilator and is associated with the manipulation of ventilator functionality, Figure 27; the transmitter ‘2750’ sends the settings/ data);
receiving a selection of the transfer activation element (Steinhauer Figure 27; there the transmitter ‘2750’ is a button on the display screen that is the transfer activation element to transmit settings, when pressed, that is receiving the selectin of the transfer activation element);
and based on receiving the selection of the transfer activation element initiating the transmission, wherein transmitting the ventilator settings includes transmitting the selected subset of ventilator settings (Steinhauer Figure 27; where the transmitter ‘2750’ (transfer activation element on the screen), initiates the transmission of the settings of the ventilators, [0090]; where there is a subset of current ventilator settings as previously described, Figure 2; where the ventilators communicate bidirectionally to transmit settings – a caregiver can access this subset of settings and select it to be transmitted, [0090]; certain actions can be associated with a subset of ventilator actions (settings)).
Regarding claim 14, Steinhauer further discloses, the ventilator of claim 8, wherein the operations further comprise:
transmitting, to the receiving ventilator, patient data for the patient (Steinhauer Figure 2; where there is bidirectional communication of the ventilators (transmitting to the receiving ventilator), [0167]; where the patient ID (data) is pushed to the ventilator via transmission).
Regarding claim 15, Steinhauer further discloses, a method for receiving ventilator settings from a transferring ventilator by a receiving ventilator (Steinhauer Figure 2; where the ventilators are in bidirectional communication with each other for transferring settings of the ventilators) the method comprising:
exchanging identification data with the transferring ventilator (Steinhauer [0074]; context data is any information to provide context to the ventilator data, e.g. the ventilator ID, Figure 2; bidirectional communication of the ventilators, therefore any information can be transferred or received by the ventilators);
based on the exchanged identification data, establishing communication with the transferring ventilator (Steinhauer Figure 2; where the ventilator is in bidirectional communication with another ventilator (communication with receiving ventilator), Figure 6; where the ventilator can access the ventilator ID ‘624’, and then transmit the data ‘640’ (exchanging identification data), [0142]; where the transmitter establishes the communication/data to a ventilator (establishing communication with a ventilator));
prior to a patient being connected to the receiving ventilator, receiving, by the receiving ventilator, ventilator settings from the transferring ventilator (Steinhauer Figure 2; where the ventilator communicates with another ventilator, [0188]; during the use of the system, ventilators are in operation with the respective patient (prior to the patient being disconnected = still in operation), [0189]; ventilators are able to have bidirectional communication with the system (transmitting settings), [0187]; system can be directly coupled to ventilators or within the ventilators (transmitting settings to a receiving ventilator));
and delivering ventilation to the patient, by the receiving ventilator, according to the received ventilator settings (Steinhauer [0042]; where the ventilator delivers ventilation to a patient and [0047]; where communication of the ventilators is based on the ventilator settings (received ventilator settings), thereby when the settings are transferred, the patient gets ventilation delivered to them).
Regarding claim 18, Steinhauer further discloses, the method of claim 15, further comprising:
receiving a selection to change the received ventilator settings (Steinhauer [0090]; where a selection to change certain ventilator settings can happen by accessing data and Figure 2 where the ventilators are in bidirectional communication with each other, allowing for the received settings to come in, then the clinician can change the settings by accessing the data on the interface);
displaying an interface to change the ventilator settings (Steinhauer Figure 27; where the data accessor is on the interface of the display ‘2730’ and allows you to change settings [0090]);
and receiving, via the interface, changes to the ventilator settings (Steinhauer Figure 27; where the data accessor is on the interface of the display ‘2730’ and allows you to change settings [0090]).
Regarding claim 19, Steinhauer further discloses, the method of claim 15, further comprising receiving, from the transferring ventilator, patient data for the patient being ventilated on the transferring ventilator (Steinhauer Figure 2; where the ventilators are in bidirectional communication with each other, [0099]; where the display screen ‘730’ can display the patient ID (what the patient ID entails [0086]), and the screen allows the clinician to access the data from other ventilators or devices, [0056]; where communication of ventilators includes the ventilator data (patient ID is part of the ventilator data)).
Regarding claim 20, Steinhauer further discloses, the method of claim 19, further comprising based on the received patient data, accessing previously stored ventilator settings for the patient (Steinhauer [0190]; data can be accessed over any time period, data can be stored in memory (accessing previously stored settings), [0056]; where communication of ventilators includes the ventilator data (patient ID is part of the ventilator data)- receiving patient data and Figure 2; where the ventilators are bidirectional communication with each other).
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.
Claims 4-6, 11-13, 16 and 17 are rejected under 35 U.S.C. 103 as being obvious over Steinhauer (US 20130104893 A1) in view of Dong (US 20210393902 A1).
Regarding claim 4, Steinhauer further discloses the method of claim 1, further comprising:
receiving an indication of a ventilator type of the receiving ventilator (Steinhauer [0087]; where the ventilator ID is accessed for contextualizing ventilator data, Figure 6; where the data is accessed then ultimately transmitted, Figure 2; where the ventilators are in bidirectional communication with each other);
based on the ventilator type of the receiving ventilator and the current ventilator settings (Steinhauer [0087]; where the ventilator ID is accessed to contextualize the ventilator data based on the ventilator ID (current ventilation settings)).
Steinhauer is silent to generating recommended ventilator settings and transmitting those settings, along with wherein the transmitted current ventilator settings are the recommended ventilator settings.
Dong discloses the one-touch ventilation mode comprising:
generating recommended ventilator settings ([0035]; ventilator settings may be automatically generated by the ventilator or entered by a clinician to generate settings);
and wherein the transmitted current ventilator settings are the recommended ventilator settings ([0035]; where the ventilation settings are for delivering a gas to a patient (current ventilator settings), settings may be entered by a clinician or generated by the ventilator).
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method for using the ventilator type of a receiving ventilator and current ventilator settings of Steinhauer to include using generated recommended ventilator settings as taught by Dong, since, this type of generation results in more efficient time spent by a clinician and reduces errors in mode selection for ventilators (Dong [0029]).
Regarding claim 5, Steinhauer further discloses the method of claim 4, wherein the indication of the ventilator type is based on input received via a user interface presented by the medical ventilator (Steinhauer [0125]; where there is a ventilator mode determiner, and depending on the mode selected rules can be displayed on a display screen of the ventilator).
Although Steinhauer does not explicitly disclose where the indication of ventilator type is based upon user input from a user interface, Steinhauer does disclose, a user interface [0099], user input [0109], and recognition of ventilator modes [0125] and IDs [0087]. It would have been readily understood by one of ordinary skill in the art that, that having ventilator modes would also include the ventilator type, because the modes are needed to tailor certain features of care and are there to prevent harm to patients based on incorrect ventilators (Steinhauer [0125]).
Regarding claim 6,- Steinhauer further discloses the method of claim 4, wherein the indication of the ventilator type is based on identification data received from the receiving ventilator (Steinhauer [0087]; where the ventilator ID is accessed for contextualizing ventilator data (identification data), Figure 6; where the data is accessed then ultimately transmitted, Figure 2; where the ventilators are in bidirectional communication with each other).
Regarding claim 11, Steinhauer further discloses, the ventilator of claim 8, wherein the operations further comprise:
receiving an indication of a ventilator type of the receiving ventilator (Steinhauer [0087]; where the ventilator ID is accessed for contextualizing ventilator data, Figure 6; where the data is accessed then ultimately transmitted, Figure 2; where the ventilators are in bidirectional communication with each other);
based on the ventilator type of the receiving ventilator and the current ventilator settings (Steinhauer [0087]; where the ventilator ID is accessed to contextualize the ventilator data based on the ventilator ID (current ventilation settings)).
Steinhauer is silent to generating recommended ventilator settings and transmitting those settings, along with wherein the transmitted current ventilator settings are the recommended ventilator settings.
Dong discloses the one-touch ventilation mode comprising:
generating recommended ventilator settings ([0035]; ventilator settings may be automatically generated by the ventilator or entered by a clinician to generate settings);
and wherein the transmitted current ventilator settings are the recommended ventilator settings ([0035]; where the ventilation settings are for delivering a gas to a patient (current ventilator settings), settings may be entered by a clinician or generated by the ventilator).
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method for using the ventilator type of a receiving ventilator and current ventilator settings of Steinhauer to include using generating recommended settings as taught by Dong, since, this type of generation results in more efficient time spent by a clinician and reduces errors in mode selection for ventilators (Dong [0029]).
Regarding claim 12, Steinhauer further discloses, the ventilator of claim 11, wherein the operations further comprise:
wherein the indication of the ventilator type is based on input received via a user interface presented by the medical ventilator (Steinhauer [0125]; where there is a ventilator mode determiner, and depending on the mode selected rules can be displayed on a display screen of the ventilator).
Although Steinhauer does not explicitly disclose where the indication of ventilator type is based upon user input from a user interface, Steinhauer does disclose, a user interface [0099], user input [0109], and recognition of ventilator modes [0125]. It would have been readily understood by one of ordinary skill in the art, that having ventilator modes would also include the ventilator type, because the modes are needed to tailor certain features of care and are there to prevent harm to patients based on incorrect ventilators (Steinhauer [0125]).
Regarding claim 13, Steinhauer further discloses, the ventilator of claim 11, wherein the operations further comprise:
wherein the indication of the ventilator type is based on identification data received from the receiving ventilator (Steinhauer [0087]; where the ventilator ID is accessed for contextualizing ventilator data (identification data), Figure 6; where the data is accessed then ultimately transmitted, Figure 2; where the ventilators are in bidirectional communication with each other).
Claims 16 and 17 are rejected under 35 U.S.C. 103 as being obvious over Steinhauer (US 20130104893 A1).
Regarding claim 16, Steinhauer further discloses, the method of claim 15, further comprising displaying, by the receiving ventilator prior to the patient being connected, the received ventilator settings (Steinhauer Figure 7 display screen ‘730’, [099]; display screen displays ventilator information can be a touch screen to access data, Figure 2; ventilators bidirectionally communicate to transmit/ receive settings from each other).
Although Steinhauer does not explicitly disclose prior to the patient being connected displaying the received ventilator settings, Steinhauer does disclose a display screen (Figure 7 ‘730’), [099]; displaying the ventilator information (settings) on the screen, and the ventilators in bidirectional communication to transmit/ receive the settings (Figure 2). It would have been readily understood by one of ordinary skill in the art that, that with the screen being able to display the settings and the transmitting/ receiving of the ventilators, the patient wouldn’t have to be connected and therefore could be displaying before the patient is connected. Furthermore, displaying the settings on the screen allows for patient harm to be prevented and would allow the clinician to customize the settings based on the patient’s needs as well before ventilation begins (Steinhauer [0125], [0129]).
Regarding claim 17, Steinhauer further discloses, the method of claim 16, further comprising:
receiving a confirmation approval of the received ventilator settings (Steinhauer [0275]; where the clinician reviews the data and makes sure it is correct for the ventilator, confirms by generating user input);
and wherein delivering ventilation is commenced based on receiving the confirmation approval (Steinhauer Figure 24; where the steps detail that a verification of the ventilator settings is required by a clinician before the implementation of the ventilator setting -the implementation would be the ventilation beginning and therefore delivering ventilation).
Conclusion
The following prior art were considered but not used on a 35 U.S.C. § 102 or 103 rejection:
Novkov (US 20220072263 A1): Systems and methods for active humidification in ventilatory support.
Dong (US 20220096781 A1): Synchronous control systems and methods for a ventilator.
Gleim (US 20210299376 A1): Remote viewing and control of a ventilator.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AISLINN MOIRA JONES whose telephone number is 571-272-3835. The examiner can normally be reached Monday-Friday 8am-5pm, EO Friday 8am-4pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brandy Lee can be reached at 571-270-7410. 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.
/AISLINN M JONES/Examiner, Art Unit 3785
/BRANDY S LEE/Supervisory Patent Examiner, Art Unit 3785