DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Responsive to the communication dated 12/08/2022
Claims 1-14 are presented for examination
Information Disclosure Statement
The IDS dated 12/08/2022 and 10/26/2023 has been reviewed. See attached.
Drawings
The drawings dated 12/08/2022 have been reviewed. They are accepted.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Abstract
The abstract dated 12/08/2022 has been reviewed. It has 81 words, and contains no legal phraseology. It is accepted
Claim Interpretation
Several claims recite phrases that make the scope of the claim indefinite, as it is unclear whether the limitations following these phrases are or are not included within the claim scope. For the purposes of this examination, the limitations following the phrases “preferably” and “for example” in claims 6, 9, and 11 are not given patentable weight.
Further, because of this, the scope of claim 10, which relies on the indefinite limitation of claim 9, is unclear. See the objections below. For the purposes of this examination, claim 10 is treated as if the “one or more handshake messages” are introduced for the first time within claim 10.
Claim Objections
Claims 1-14 objected to because of the following informalities:
Claims 1 and 13 recite “wherein the clinical parameters of the simulation signals is selected…” This should instead read “wherein the clinical parameters of the simulation signals are selected…”
Claims 1 and 13 recite “the monitoring device” without previously introducing this element. To avoid possible issues with antecedent basis, this should be amended to read “a monitoring device.”
Claims 4 and 5 recite “the simulation data…” As it is clear this is referring to the “reference simulation data” introduced in claim 3, the word “reference” should be added to each recitation of the “simulation data” in claims 4 and 5.
Claim 4 recites “one or more prior patients…” To avoid possible issues with antecedent basis, the word “prior” should be removed and this should simply read “one or more patients…”
Claim 10 attempts to further limit the limitation of claim 9 that was indefinite, particularly “preferably wherein the establishing communication comprises exchanging one or more handshake messages.” To avoid any potential issues with antecedent basis, it is recommended to remove the word “preferably” from claim 9. See the claim interpretation and 112 rejection sections above and below, respectively.
Claim 13 recites “interrupt the coupling…” As the word supply is used in claim 13 instead of “couple” to describe data being sent between the processor and sensors, this should be amended to read “interrupt the supply…”
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6-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 claim 6, the phrase "for example" renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
Claim 7 recites the limitation "the signal interruption.” There is insufficient antecedent basis for this limitation in the claim. It is unclear whether this is meant to refer to the interruption of the coupling of the sensor inputs to the processor, or the communication channel between the monitoring device and one or more components of a medical facility monitoring network in claim 1. For the purposes of this examination, it is treated as if it is referring to the interruption of the sensor inputs to the processor.
Regarding claim 9, the phrase "preferably" renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
Regarding claim 11, the phrases "preferably" and “for example” render the claim indefinite because it is unclear whether the limitation(s) following the phrases are part of the claimed invention. See MPEP § 2173.05(d).
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-14 are rejected under 35 U.S.C. 101 because they are directed to an abstract idea without significantly more.
Claim 1 (Statutory Category – Process)
Step 2A – Prong 1: Judicial Exception Recited?
Yes, the claim recites a mental process, specifically:
MPEP 2106.04(a)(2)(Ill): “Accordingly, the "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, Judgments, and opinions.”
Further, the MPEP recites “The courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation.”
A method for implementing a simulation mode on a medical device … the method comprising: detecting the set of sensor inputs connected at the communication interface; … coupling to the processor, in place of the sensor inputs, a set of one or more simulation signals, each configured to simulate a sensor input carrying a particular clinical parameter, wherein the clinical parameters of the simulation signals is selected based at least in part on the detected sensor inputs connected at the communication interface,
“Detecting” the set of connected sensor inputs is a mental process equivalent to observing the communication interface and judging which sensors are connected. For example, observing that a heartrate sensor is connected to the interface is equivalent to “detecting” it.
Generating simulated sensor input related to health data is a mental process equivalent to coming up with representations of such sensor input; for example a person could draw a waveform representative of a heartbeat detected by a heart monitor. Doing this based on the detected sensors is merely the act of simulating output representative of that sensor; for example if it is observed that the sensor connected to the interface is a blood oxidation sensor, this would mean generating simulated sensor data representative of a blood oxidation sensor.
Further, “coupling” this simulated data to the processor merely amounts to gathering that generated data into the processor, and therefore amounts to no more than mere data gathering.
The use of a processor and other generic computer components amounts to no more than mere instructions to apply.
Should it be found that this is not a mental process, it is also an example of mere data gathering and mere instructions to apply.
the processor configured to generate a user output at a user interface, based on the one or more sensor inputs
Generating a generic output based on the sensor data is a mental process equivalent to drawing a representation of a user interface including data related to the sensor data. For example, if the sensor data is reflective of a steady, healthy heartbeat, a person could draw, with a pen and paper, an example of a user interface showing that heartbeat waveform.
Doing this with a processor and a computerized user interface amounts to no more than mere instructions to apply.
Step 2A – Prong 2: Integrated into a Practical Solution?
Insignificant Extra-Solution Activity (MPEP 2106.05(g)) has found mere data gathering and
post solution activity to be insignificant extra-solution activity.
Data gathering:
the medical device being configured in a standard mode to receive a set of one or more sensor inputs at a communication interface, each carrying a signal representative of a clinical parameter, to couple the sensor inputs to a processor
Receiving sensor inputs and “coupling” those inputs to the processor without specificity as to how this coupling is performed or how the inputs are received is merely equivalent to gathering that sensor data into the processor in a generic manner, and therefore amounts to no more than mere data gathering.
Should it be found that this is not an example of mere data gathering, it is also an example of mere instructions to apply.
detecting the set of sensor inputs connected at the communication interface;
Detecting this set of inputs is merely equivalent to obtaining data representative of what sensors are connected, which amounts to no more than merely gathering that data.
coupling to the processor, in place of the sensor inputs, a set of one or more simulation signals, each configured to simulate a sensor input carrying a particular clinical parameter, wherein the clinical parameters of the simulation signals is selected based at least in part on the detected sensor inputs connected at the communication interface,
“Coupling” this simulated data to the processor, without any specificity as to how this coupling is actually performed or how the simulated signals are generated, merely amounts to gathering data representative of that simulated output into the processor.
Selecting the parameters “based on” the sensor inputs merely amounts to gathering data representative of that selection.
Should it be found that this is not mere data gathering, it is also an example of mere instructions to apply.
Mere Instructions to Apply (MPEP 2106.05(f)) has found that merely applying a judicial exception such as an abstract idea, as by performing it on a computer, does not integrate the claim into a practical solution.
Mere Instructions to Apply:
interrupting the coupling of the sensor inputs to the processor … wherein the method further comprises interrupting a communication channel between the monitoring device and one or more components of a medical facility monitoring network.
Applying a computer to perform a generic communication interruption at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that interruption, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the communication between the processor and the sensor inputs, as well as between the monitoring device and the network are “interrupted” without reciting how this interruption is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations.
coupling to the processor, in place of the sensor inputs, a set of one or more simulation signals, each configured to simulate a sensor input carrying a particular clinical parameter, wherein the clinical parameters of the simulation signals is selected based at least in part on the detected sensor inputs connected at the communication interface,
Applying a computer to perform a generic simulation at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that simulation, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the signals “simulated” and the inputs are “coupled” to the processor without reciting how this simulation or coupling is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations.
Moreover, Mere Instructions To Apply An Exception (MPEP 2106.05(f)) has found that 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 integrate a judicial exception into a practical application or provide significantly more. In light of this, the additional generic computer component elements of “a medical device, the medical device being configured in a standard mode to receive a set of one or more sensor inputs at a communication interface, each carrying a signal representative of a clinical parameter, to couple the sensor inputs to a processor, and the processor configured to generate a user output at a user interface, based on the one or more sensor inputs … a communication channel between the monitoring device and one or more components of a medical facility monitoring network.” are not sufficient to integrate a judicial exception into a practical application nor provide evidence of an inventive concept.
Step 2B: Claim provides an Inventive Concept?
No, as discussed with respect to Step 2A, the additional limitations are Insignificant Extra-Solution Activity (MPEP 2106.05(g)) or Mere Instructions to Apply and do not impose any meaningful limits on practicing the abstract idea and therefore the claim does not provide an inventive concept in Step 2B.
Insignificant Extra-Solution Activity (MPEP 2106.05(g)) has found mere data gathering and
post solution activity to be insignificant extra-solution activity.
Data gathering:
the medical device being configured in a standard mode to receive a set of one or more sensor inputs at a communication interface, each carrying a signal representative of a clinical parameter, to couple the sensor inputs to a processor
Receiving sensor inputs and “coupling” those inputs to the processor without specificity as to how this coupling is performed or how the inputs are received is merely equivalent to gathering that sensor data into the processor in a generic manner, and therefore amounts to no more than mere data gathering.
A claim element that amounts to merely gathering data is not indicative of integration into a
practical solution nor evidence that the claim provides an inventive concept or significantly more, as exemplified by ((MPEP 2106.05)(g)(Mere Data Gathering) i. Performing clinical tests on individuals to obtain input for an equation, In re Grams, 888 F.2d 835, 839-40; 12 USPQ2d 1824, 1827-28 (Fed. Cir. 1989); iv. Obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011);
Should it be found that this is not an example of mere data gathering, it is also an example of mere instructions to apply.
detecting the set of sensor inputs connected at the communication interface;
Detecting this set of inputs is merely equivalent to obtaining data representative of what sensors are connected, which amounts to no more than merely gathering that data.
coupling to the processor, in place of the sensor inputs, a set of one or more simulation signals, each configured to simulate a sensor input carrying a particular clinical parameter, wherein the clinical parameters of the simulation signals is selected based at least in part on the detected sensor inputs connected at the communication interface,
“Coupling” this simulated data to the processor, without any specificity as to how this coupling is actually performed or how the simulated signals are generated, merely amounts to gathering data representative of that simulated output into the processor.
Selecting the parameters “based on” the sensor inputs merely amounts to gathering data representative of that selection.
A claim element that amounts to merely gathering data is not indicative of integration into a
practical solution nor evidence that the claim provides an inventive concept or significantly more, as exemplified by ((MPEP 2106.05)(g)(Mere Data Gathering) i. Performing clinical tests on individuals to obtain input for an equation, In re Grams, 888 F.2d 835, 839-40; 12 USPQ2d 1824, 1827-28 (Fed. Cir. 1989); iv. Obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011);
Should it be found that this is not mere data gathering, it is also an example of mere instructions to apply.
Mere Instructions to Apply (MPEP 2106.05(f)) has found that merely applying a judicial exception such as an abstract idea, as by performing it on a computer, does not integrate the claim into a practical solution.
Mere Instructions to Apply:
interrupting the coupling of the sensor inputs to the processor … wherein the method further comprises interrupting a communication channel between the monitoring device and one or more components of a medical facility monitoring network.
Applying a computer to perform a generic communication interruption at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that interruption, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the communication between the processor and the sensor inputs, as well as between the monitoring device and the network are “interrupted” without reciting how this interruption is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations.
The courts have found that such mere instructions to apply are not indicative of integration into a practical application nor recitation of significantly more than the judicial exception (MPEP 2106.05(f) “Another consideration when determining whether a claim integrates a judicial exception into a practical application in Step 2A Prong Two or recites significantly more than a judicial exception in Step 2B is whether the additional elements amount to more than a recitation of the words "apply it" (or an equivalent) or are more than mere instructions to implement an abstract idea or other exception on a computer. As explained by the Supreme Court, in order to make a claim directed to a judicial exception patent-eligible, the additional element or combination of elements must do "‘more than simply stat[e] the [judicial exception] while adding the words ‘apply it’". Alice Corp. v. CLS Bank, 573 U.S. 208, 221, 110 USPQ2d 1976, 1982-83 (2014) (quoting Mayo Collaborative Servs. V. Prometheus Labs., Inc., 566 U.S. 66, 72, 101 USPQ2d 1961, 1965). Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 573 U.S. at 223, 110 USPQ2d at 1983”)
coupling to the processor, in place of the sensor inputs, a set of one or more simulation signals, each configured to simulate a sensor input carrying a particular clinical parameter, wherein the clinical parameters of the simulation signals is selected based at least in part on the detected sensor inputs connected at the communication interface,
Applying a computer to perform a generic simulation at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that simulation, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the signals “simulated” and the inputs are “coupled” to the processor without reciting how this simulation or coupling is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations.
The courts have found that such mere instructions to apply are not indicative of integration into a practical application nor recitation of significantly more than the judicial exception (MPEP 2106.05(f) “Another consideration when determining whether a claim integrates a judicial exception into a practical application in Step 2A Prong Two or recites significantly more than a judicial exception in Step 2B is whether the additional elements amount to more than a recitation of the words "apply it" (or an equivalent) or are more than mere instructions to implement an abstract idea or other exception on a computer. As explained by the Supreme Court, in order to make a claim directed to a judicial exception patent-eligible, the additional element or combination of elements must do "‘more than simply stat[e] the [judicial exception] while adding the words ‘apply it’". Alice Corp. v. CLS Bank, 573 U.S. 208, 221, 110 USPQ2d 1976, 1982-83 (2014) (quoting Mayo Collaborative Servs. V. Prometheus Labs., Inc., 566 U.S. 66, 72, 101 USPQ2d 1961, 1965). Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 573 U.S. at 223, 110 USPQ2d at 1983”)
Moreover, Mere Instructions To Apply An Exception (MPEP 2106.05(f)) has found that 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 integrate a judicial exception into a practical application or provide significantly more. In light of this, the additional generic computer component elements of “a medical device, the medical device being configured in a standard mode to receive a set of one or more sensor inputs at a communication interface, each carrying a signal representative of a clinical parameter, to couple the sensor inputs to a processor, and the processor configured to generate a user output at a user interface, based on the one or more sensor inputs … a communication channel between the monitoring device and one or more components of a medical facility monitoring network.” are not sufficient to integrate a judicial exception into a practical application nor provide evidence of an inventive concept.
The additional elements have been considered both individually and as an ordered combination in the consideration of whether they constitute significantly more, and have been determined not to constitute such.
The claim is ineligible.
Claim 13 The elements of claim 13 are substantially the same as those of claim 1. Therefore, the elements of claim 13 are rejected due to the same reasons as outlined above for claim 1.
Moreover, Mere Instructions To Apply An Exception (MPEP 2106.05(f)) has found that 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 integrate a judicial exception into a practical application or provide significantly more. In light of this, the additional generic computer component elements of claim 13, particularly “A controller, arranged for communicating with a medical device, for implementing a simulation mode on the medical device, the medical device configured in a normal operating mode to receive one or more sensor inputs at a communication interface, each carrying a signal representative of a clinical parameter, supply the sensor inputs to a processor, and to generate a user output using the processor, a communication channel between the monitoring device and one or more components of a medical facility monitoring network.” are not sufficient to integrate a judicial exception into a practical application nor provide evidence of an inventive concept.
Claim 2 recites “wherein the clinical parameters simulated by the simulation signals include at least each of the clinical parameters of the detected sensor inputs connected at the connection interface.”
This merely clarifies which clinical parameters are simulated and therefore is merely an extension of the mental process, mere data gathering, and mere instructions to apply.
Claim 3 recites “wherein supplying the simulation signals comprises communicating with a datastore, the datastore storing reference simulation data for a plurality of different simulation signals.”
Supplying data from a datastore in such a generic manner amounts to no more than gathering that data.
Further, transmitting and receiving data over a network is explicitly recognized by the courts as an example of mere instructions to apply. (MPEP 2106.05(f)(2): Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, 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 integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).)
Additionally, receiving and transmitting data over a network, as well as storing and retrieving data in memory, are also explicitly recognized by the courts as an example of well-understood, routine, conventional activity. See (MPEP 2106.05(d)(II) i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network) … iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;)
Claim 4 recites “wherein the simulation data includes historical sensor signal data recorded for one or more prior patients over a time window.”
This merely clarifies the form of the simulation data, and therefore is merely an extension of the mental process, mere data gathering, and mere instructions to apply.
Claim 5 recites “wherein the simulation data includes a plurality of simulation data subsets, each simulation data subset comprising simulation signal data for simulating a set of clinical parameters for a particular clinical scenario, over a time window for that clinical scenario.”
This merely clarifies the form of the simulation data, and therefore is merely an extension of the mental process, mere data gathering, and mere instructions to apply.
Claim 6 recites “wherein the medical device is a patient monitor device, for example a fetal monitor device.”
This merely clarifies the form of the medical device, and therefore is merely an extension of the mental process, mere data gathering, and mere instructions to apply.
Claim 7 recites “wherein the method comprises receiving a control input from an external device and configuring the signal interruption and simulation signal supply based on the control input.”
Receiving such control signals from an external device to configure the process amounts to no more than gathering data representative of said signals and configuration data, and therefore amounts to no more than mere data gathering.
Claim 8 recites “wherein the method further includes selectively implementing a further simulation mode responsive to detection of a pre-determined control signal from the external device, wherein, in the further simulation mode, the set of clinical parameters of the simulation signals is selected based on one or more control inputs received from the external device.”
Receiving such control signals from an external device amounts to no more than gathering data representative of said signals, and therefore amounts to no more than mere data gathering.
Basing a simulation on these signals is a mental process equivalent to drawing, with a pen and paper, a medical simulation, such as a waveform on a diagnostic monitor, based on the control input. For example, if the control input indicates that heartrate should be the parameter under inspection and a heartrate of 90bpm is desired, this would correspond to drawing a waveform representative of such a rhythm.
Performing this simulation on a computer amounts to no more than mere instructions to apply.
Should it be found that this is not a mental process, it is also an example of mere data gathering and mere instructions to apply.
Data gathering:
“Implementing” this further simulation mode, without any specificity as to how this simulation is actually performed or how the data therein is generated, merely amounts to gathering data representative of that simulated output.
A claim element that amounts to merely gathering data is not indicative of integration into a
practical solution nor evidence that the claim provides an inventive concept or significantly more, as exemplified by ((MPEP 2106.05)(g)(Mere Data Gathering) i. Performing clinical tests on individuals to obtain input for an equation, In re Grams, 888 F.2d 835, 839-40; 12 USPQ2d 1824, 1827-28 (Fed. Cir. 1989); iv. Obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011);
Mere Instructions to Apply:
Applying a computer to perform a generic simulation at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that simulation, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the further simulation is “implemented” without reciting how this simulation is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations.
The courts have found that such mere instructions to apply are not indicative of integration into a practical application nor recitation of significantly more than the judicial exception (MPEP 2106.05(f) “Another consideration when determining whether a claim integrates a judicial exception into a practical application in Step 2A Prong Two or recites significantly more than a judicial exception in Step 2B is whether the additional elements amount to more than a recitation of the words "apply it" (or an equivalent) or are more than mere instructions to implement an abstract idea or other exception on a computer. As explained by the Supreme Court, in order to make a claim directed to a judicial exception patent-eligible, the additional element or combination of elements must do "‘more than simply stat[e] the [judicial exception] while adding the words ‘apply it’". Alice Corp. v. CLS Bank, 573 U.S. 208, 221, 110 USPQ2d 1976, 1982-83 (2014) (quoting Mayo Collaborative Servs. V. Prometheus Labs., Inc., 566 U.S. 66, 72, 101 USPQ2d 1961, 1965). Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 573 U.S. at 223, 110 USPQ2d at 1983”)
Claim 9 recites “wherein the method comprises a step of establishing a communication channel with the external device via a further communication interface, and preferably wherein the establishing communication comprises exchanging one or more handshake messages.”
Establishing a communication channel, i.e. transmitting and receiving data over a generic computer network amounts to no more than mere instructions to apply.
Further, this is explicitly recognized by the courts as an example of mere instructions to apply. (MPEP 2106.05(f)(2): Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, 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 integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).)
Additionally, receiving and transmitting data over a network is also explicitly recognized by the courts as an example of well-understood, routine, conventional activity. See (MPEP 2106.05(d)(II) i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network))
Claim 10 recites “wherein the one or more handshake messages include authentication information for establishing a secure communication channel.”
Transmitting and receiving data over a generic computer network amounts to no more than mere instructions to apply.
Further, this is explicitly recognized by the courts as an example of mere instructions to apply. (MPEP 2106.05(f)(2): Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, 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 integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).)
Additionally, receiving and transmitting data over a network is also explicitly recognized by the courts as an example of well-understood, routine, conventional activity. See (MPEP 2106.05(d)(II) i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network))
Claim 11 recites “wherein the further communication interface includes a local wireless network interface, and preferably wherein the communication channel is facilitated by a local wireless network server, for example a Wi-Fi server.”
The use of a generic network interface to perform generic networking functions amounts to no more than mere instructions to apply.
Further, this is explicitly recognized by the courts as an example of mere instructions to apply. (MPEP 2106.05(f)(2): Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, 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 integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).)
Additionally, receiving and transmitting data over a network is also explicitly recognized by the courts as an example of well-understood, routine, conventional activity. See (MPEP 2106.05(d)(II) i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network))
Claim 12 recites “A computer program product comprising code means, configured when run on a processor, to cause the processor to perform the method according to claim 1.”
Regarding claim 12, the claim(s) are directed to a “system” or machine, but fails to disclose physical “things”. The elements of the claim are construed as software. Products that do not have a physical or tangible form, such as information (often referred to as "data per se") or a computer program per se (often referred to as "software per se") when claimed as a product without any structural recitations are not directed to any of the statutory categories (MPEP 2106.03).
Claim 14 recites “wherein the controller is integrated in a peripheral hardware module, the hardware module comprising a connection interface, and adapted to operatively couple to the medical device via the connection interface.”
This merely clarifies additional features of the generic computer components, and is therefore merely an extension of the mere instructions to apply.
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.
(1) Claims 1-4, 6-7, and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Duval-Arnould (US 10580324 B2) in view of Holcomb (US 20120274313 A1) in further view of Kiani (US 20110105854 A1)
Claim 1. Duval-Arnould teaches A method for implementing a simulation mode on a medical device, ([Abstract] “The present invention is directed to systems for interfacing between sensors and sensor simulators and clinical monitors and devices. The present invention is used to incorporate sensors and sensor simulators into training and clinical demonstrations.”) the medical device being configured in a standard mode to receive a set of one or more sensor inputs at a communication interface, each carrying a signal representative of a clinical parameter, to couple the sensor inputs to a processor, and the processor configured to generate a user output at a user interface, based on the one or more sensor inputs, ([Col 1 line 20-23] “Clinical monitors and smart defibrillators interact with patients, using a number of different sensors to collect necessary clinically relevant physiological findings and measurements of provider performance.”) the method comprising: sensor inputs connected at the communication interface;([Col 1 line 40- Col 2 line 3] “The foregoing needs are met, to a great extent, by the present invention which provides a system for interfacing with a clinical device during a simulated training including a non-transitory computer readable medium configured to generate an input signal configured to mimic an output signal from a clinical sensor and encode the input signal into a format recognized by the clinical device. The system also includes a hardware component configured to interface the non-transitory computer readable medium to the clinical device. The hardware component provides communication between the non-transitory computer readable medium and the clinical device. In accordance with an aspect of the present invention the clinical device can take the form of at least one selected from a group consisting of a clinical monitor and a defibrillator. The input signal takes the form of at least one selected from a group consisting of a simulator controller signal, a computer-generated waveform, a real patient waveform recorded by a clinical monitor or defibrillator, and a recorded waveform from an intercepted clinical sensor signal. The non-transitory computer readable medium can be configured to encode the input signal to follow sensor-receiver protocols. The non-transitory computer readable medium can also be configured to change or adapt the input signal in real-time. The non-transitory computer readable medium is configured to simulate the output signal from at least one of the sensors selected from a group consisting of end tidal CO2 (ETCO2), pulse oximetry (SPO2), thermometer, blood pressure, quality of CPR (QCPR), and near-infrared spectroscopy (NIRS) sensors. The system can also include an interface for a user to input parameters into the system and a patient simulator.” [Col 3 line 33-64] “FIG. 1 illustrates a schematic diagram of an exemplary system and method according to an embodiment of the present invention. As illustrated in FIG. 1, step 1 includes generating a signal to replace output from a typical clinical sensor. The typical clinical sensor output signal can be replaced in a variety of different ways with various simulated outputs. Examples of such simulated outputs include but are not limited to a simulator control signal, a computer-generated waveform, a real patient waveform recorded by a clinical monitor or defibrillator, and a recorded waveform from an intercepted clinical sensor signal. Also as illustrated in FIG. 1, Step 2 includes encoding the simulated signal output to follow sensor-receiver protocols, if necessary. The computing device or non-transitory computer readable medium can also be used to complete this step. In step 3, the simulated signal is sent to the monitor/device. The non-transitory computer readable medium can be used to export the signal to a hardware component configured to communicate with both the non-transitory computer readable medium and the clinical monitor, medical device or other device used in a clinical setting and known to one of skill in the art. The monitor or device receives the signal and can display it in accordance with the typical operation of that particular machine” ([Col 2 line 55-58] “FIG. 2 illustrates a circuit diagram for hardware for accessing clinical sensor output data and feeding the data to a computing device according to an embodiment of the present invention.” [Col 1 line 20-23] “Clinical monitors and smart defibrillators interact with patients, using a number of different sensors to collect necessary clinically relevant physiological findings and measurements of provider performance.”) wherein the clinical parameters of the simulation signals ([Col 1 line 55 -Col 2 line 3] “The input signal takes the form of at least one selected from a group consisting of a simulator controller signal, a computer-generated waveform, a real patient waveform recorded by a clinical monitor or defibrillator, and a recorded waveform from an intercepted clinical sensor signal. The non-transitory computer readable medium can be configured to encode the input signal to follow sensor-receiver protocols. The non-transitory computer readable medium can also be configured to change or adapt the input signal in real-time. The non-transitory computer readable medium is configured to simulate the output signal from at least one of the sensors selected from a group consisting of end tidal CO2 (ETCO2), pulse oximetry (SPO2), thermometer, blood pressure, quality of CPR (QCPR), and near-infrared spectroscopy (NIRS) sensors. The system can also include an interface for a user to input parameters into the system and a patient simulator.”) ([Col 2 line 55-58] “FIG. 2 illustrates a circuit diagram for hardware for accessing clinical sensor output data and feeding the data to a computing device according to an embodiment of the present invention.” [Col 1 line 20-23] “Clinical monitors and smart defibrillators interact with patients, using a number of different sensors to collect necessary clinically relevant physiological findings and measurements of provider performance.”) ([Col 3 line 57-64] “The non-transitory computer readable medium can be used to export the signal to a hardware component configured to communicate with both the non-transitory computer readable medium and the clinical monitor, medical device or other device used in a clinical setting and known to one of skill in the art. The monitor or device receives the signal and can display it in accordance with the typical operation of that particular machine.”)
Duval-Arnould does not explicitly teach detecting the set of sensor inputs connected at the communication interface; interrupting the coupling of the sensor inputs to the processor; wherein data is based at least in part on the detected sensor inputs; wherein the method further comprises interrupting a communication between one or more components of a medical facility monitoring network.
Holcomb makes obvious ([Par 20-21] “As further shown in FIG. 2, demonstration source multiplexor 209 selectively switches between the analog signal from digital-to-analog converter 205 and the serial demonstration patterns from serial demonstration generator 219, and provides the switched output to demonstration analog processor 213… The digital signals are connected from the MSO channel block 150 to MSO demonstration (demo) multiplexor 221 of demonstration processing circuit 200. MSO demonstration multiplexor 221 selectively switches between the stimulus signals provided from demonstration signal generators 201 and 203 and the digital signal from MSO channel block 150, and provides the switched output to acquisition memory and trigger circuit 121.”)
Holcomb is analogous art because it is within the field of enabling simulation/demonstration modes on monitoring devices. It would have been obvious to one of ordinary skill in the art to combine Holcomb with Duval-Arnould before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to enable simulation modes within the device without requiring additional hardware. As noted by Holcomb, simulation/demonstration modes for many devices require additional hardware and controllers, which can be expensive and cumbersome to operate ([Par 2-3] “To demonstrate the capabilities of an oscilloscope to a potential customer during a sales process, a separate demonstration (demo) board may be manually connected to the oscilloscope and used as a signal source to provide multiple signal types for display. For complex signal types, it may be necessary to connect various external cables from the demo board to the oscilloscope. The oscilloscope must also be properly configured. In some instances, the demo boards may be reconfigurable. Demo boards may be expensive, which can be cost prohibitive because the demo boards are usually distributed to sales staff. Also, because of the complexity of oscilloscopes, it can be difficult to properly train and inform customers of the various oscilloscope operational modes. Written manuals may be provided to walk customers through self-training steps which may include connecting signals from a separate demo board or signal source to the oscilloscope inputs. In either case of demonstration or training, additional equipment is typically needed, increasing cost, time and difficulty. There is thus a need to demonstrate an oscilloscope without the use of a separate demo board. There is also a need to provide customer training using a broad set of waveform types without the use of a separate demo board or signal source.”) To this end, Holcomb presents a system including an integrated selectable simulation/demonstration mode capable of generating simulated signals without the necessity of external hardware ([Abstract] “An oscilloscope includes at least one demonstration signal generator integrated as part of the oscilloscope. The demonstration signal generator generates stimulus signals that consist of digital samples of various different stored waveforms without the need of a separate demonstration board or signal source. The demonstration signal generator may loop through different sections of the stored waveforms to generate respective stimulus signals that include sequences of digital samples from the different waveforms in combination, to provide a broad range of stimulus signals. The stimulus signals may be displayed on the oscilloscope or output from the oscilloscope as demonstration mode stimulus signals to demonstrate the capabilities of the oscilloscope to customers or for training.” [Par 20] “As further shown in FIG. 2, demonstration source multiplexor 209 selectively switches between the analog signal from digital-to-analog converter 205 and the serial demonstration patterns from serial demonstration generator 219, and provides the switched output to demonstration analog processor 213.”) Although Holcomb describes these issues and the associated technical solution within the context of oscilloscopes, it would have been easily recognized by one of ordinary skill in the art that the same issues present in the field of medical simulation (requirement of external, sometimes expensive and cumbersome hardware to perform simulation) could be solved in an identical way through the system of Holcomb (i.e. a selectively enabled, integral simulation generator.) Overall, one of ordinary skill in the art would have recognized that combining Duval-Arnould with Holcomb would allow the simulated signals to be generated within the medical device itself, requiring less hardware to perform simulations and therefore making the system simpler to use.
The combination of Duval-Arnould and Holcomb does not explicitly teach detecting the set of sensor inputs connected at the communication interface; wherein data is based at least in part on the detected sensor inputs; wherein the method further comprises interrupting a communication between one or more components of a medical facility monitoring network.
Kiani makes obvious detecting the set of sensor inputs connected at the communication interface; wherein data is based at least in part on the detected sensor inputs; ([Par 160] “The patient monitor 740 also includes a journal module 746 in the depicted embodiment. The journal module 740 may record medical events related to the patient monitor 740. These medical events can include clinician-initiated events, such as changes to alarm settings (e.g., maximum and minimum permitted parameter values), types of parameters monitored/sensors connected to the patient monitor 740, and the like.” [Par 153] “The monitoring module 742 can monitor physiological signals generated by one or more sensors coupled with a patient. The monitoring module 742 may process the signals to determine any of a variety of physiological parameters” [Par 74] “ Example alerts include no communication with pulse oximeter, alarm silenced on pulse oximeter, instrument low battery (pulse oximeter), and transmitter low battery. Example alarms include SpO.sub.2 levels and alarms, high and low SpO.sub.2, high and low PR, HbCO level and alarms, HbMET level and alarms, pulse rate and alarms, no sensor, sensor off patient, sensor error, low perfusion index, low signal quality, HbCO, HbMET, PI trend alarm, and desat index alarm.”)wherein the method further comprises interrupting a communication between one or more components of a medical facility monitoring network. ([Par 89] “In another embodiment (not shown), end user devices 128, 152 include one way POCSAG Pagers having a 2 line display with audible and vibrate mode, of suitable size and durability for severe mechanical environments typical of hospital general floor settings. In yet another embodiment, the end user devices 128, 152 include two way paging systems, such as Motorola Flex and WLAN pagers. One advantage of two-way paging is the ability to confirm message receipt and the ability to remotely silence alarms.”)
Kiani is analogous art because it is within the field of medical systems, particularly the field of medical device and sensor interconnection. It would have been obvious to one of ordinary skill in the art to combine it with Duval-Arnould and Holcomb before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to make the system easier to use. Kiani notes that the graphical form of many patient monitoring systems can make them hard to read and further makes focusing on certain pieces of important extremely difficult. ([Par 183] “Currently available graphical user interfaces for nurses' station computers tend to show a plurality of wave forms or changing physiological parameter numbers for each patient. This method of displaying patient information can be cluttered, confusing, and even hypnotic in some situations. Nurses working on a night shift, for instance, may find it difficult to concentrate on an alarm when several other patients' indicators on the display have changing numbers, changing waveforms, or the like.”) To that end, Kiani presents a system that simplifies the monitoring GUI, allowing important information to be understood at a glance ([Par 84] “Moreover, the graphical status indicator 914 simplifies the first level of analysis that nurses tend to perform. In currently available devices, nurses often have to analyze waveforms at the nurses' station to determine the health status of a patient. However, using the screens 900, a nurse need not interpret any waveforms or changing parameters of the patient, but instead can rely on the graphical status indicator 914”) Overall, one of ordinary skill in the art would have recognized that combining Kiani with Duval-Arnould and Holcomb would make the system easier to use, particularly in longer simulations or simulations late at night when trainees may be fatigued.
Claim 2. Duval-Arnould teaches wherein the clinical parameters simulated by the simulation signals include at least each of the clinical parameters of the ([Col 3 line 33-64] “FIG. 1 illustrates a schematic diagram of an exemplary system and method according to an embodiment of the present invention. As illustrated in FIG. 1, step 1 includes generating a signal to replace output from a typical clinical sensor. The typical clinical sensor output signal can be replaced in a variety of different ways with various simulated outputs. Examples of such simulated outputs include but are not limited to a simulator control signal, a computer-generated waveform, a real patient waveform recorded by a clinical monitor or defibrillator, and a recorded waveform from an intercepted clinical sensor signal. Also as illustrated in FIG. 1, Step 2 includes encoding the simulated signal output to follow sensor-receiver protocols, if necessary. The computing device or non-transitory computer readable medium can also be used to complete this step. In step 3, the simulated signal is sent to the monitor/device. The non-transitory computer readable medium can be used to export the signal to a hardware component configured to communicate with both the non-transitory computer readable medium and the clinical monitor, medical device or other device used in a clinical setting and known to one of skill in the art. The monitor or device receives the signal and can display it in accordance with the typical operation of that particular machine” [Col 1 line 55 -Col 2 line 3] “The input signal takes the form of at least one selected from a group consisting of a simulator controller signal, a computer-generated waveform, a real patient waveform recorded by a clinical monitor or defibrillator, and a recorded waveform from an intercepted clinical sensor signal. The non-transitory computer readable medium can be configured to encode the input signal to follow sensor-receiver protocols. The non-transitory computer readable medium can also be configured to change or adapt the input signal in real-time. The non-transitory computer readable medium is configured to simulate the output signal from at least one of the sensors selected from a group consisting of end tidal CO2 (ETCO2), pulse oximetry (SPO2), thermometer, blood pressure, quality of CPR (QCPR), and near-infrared spectroscopy (NIRS) sensors. The system can also include an interface for a user to input parameters into the system and a patient simulator.”)
Kiani makes obvious detected sensor inputs ([Par 160] “The patient monitor 740 also includes a journal module 746 in the depicted embodiment. The journal module 740 may record medical events related to the patient monitor 740. These medical events can include clinician-initiated events, such as changes to alarm settings (e.g., maximum and minimum permitted parameter values), types of parameters monitored/sensors connected to the patient monitor 740, and the like.”)
Claim 3. Duval-Arnould teaches wherein supplying the simulation signals comprises communicating with a datastore, the datastore storing reference simulation data for ([Col 3 line 39-49] “Examples of such simulated outputs include but are not limited to a simulator control signal, a computer-generated waveform, a real patient waveform recorded by a clinical monitor or defibrillator, and a recorded waveform from an intercepted clinical sensor signal… The simulated signal can be produced or stored using a computing device or non-transitory computer readable medium associated with the system.” [Col 4 line 31-Col 5 line 3] “All inputs can be encoded and sent to a clinical monitor/defibrillator or can be saved in simple XML format for later use. Files saved in XML format can later be sent to a clinical monitor/defibrillator using a C# software application. Prototypes have been developed and successfully tested for all inputs described below… 2. User Input through Separate User Interface A simulated ETCO2 waveform can be generated via our C# waveform generator that creates a continuous waveform of interchanging exponential rise and decay based on set parameters. This simulated waveform can be sampled to retrieve a stream of ETCO2 waveform data points; these data points will be encoded using our encoding software. 3. Retrieval of ETCO2 Waveform from Zoll CodeNet Record Zoll R-Series defibrillators, which are currently used in all pediatric centers in the Johns Hopkins Hospital and are in the process of being phased into adult centers, generate a CodeNet report each time the defibrillator is powered on. These reports include the ETCO2 waveform for the entire event, which is logged from the CAPNOSTAT5 ETCO2 sensor that plugs into the Zoll R-Series defibrillator. The waveform and corresponding respiratory rates from the Zoll CodeNet report could be used as numeric input for the encoding software.”)
Kiani makes obvious a datastore storing a plurality of different signals. ([Par 133] “In certain embodiments, systems and methods are provided for rapidly storing and acquiring physiological trend data. For instance, physiological information obtained from a medical patient can be stored in a round-robin database. The round-robin database can store the physiological information in a series of records equally spaced in time. Parameter descriptors may be used to identify parameter values in the records. The parameter values can be dynamically updated by changing the parameter descriptors to provide for a flexible database. In addition, the size of files used in the database can be dynamically adjusted to account for patient condition.” [Par 377] “The bedside patient monitors may then output an indication of a physiological parameter value (e.g., SpO2, pulse rate, blood pressure, etc.) and its trending over time. Physiological information such as the raw physiological signals, processed physiological signals, and/or calculated physiological parameter values, for example, for each of the patients can then be transmitted to, and stored by, for example, a central repository. In some embodiments, this information is stored by a networked database such as, for example, the round-robin database 722 described herein. In some embodiments, the central repository can store medical monitoring information for the patients in a particular domain (e.g., a hospital ward) over a period of time such as a week, or a month, for example.”)
Claim 4. Duval-Arnould teaches wherein the simulation data includes historical sensor signal data recorded for one or more prior patients over a time window. ([Col 3 line 39-43] “Examples of such simulated outputs include but are not limited to … a real patient waveform recorded by a clinical monitor or defibrillator” [Col 4 line 31 – Col 5 line 35] “All inputs can be encoded and sent to a clinical monitor/defibrillator or can be saved in simple XML format for later use. Files saved in XML format can later be sent to a clinical monitor/defibrillator using a C# software application. Prototypes have been developed and successfully tested for all inputs described below… 3. Retrieval of ETCO2 Waveform from Zoll CodeNet Record Zoll R-Series defibrillators, which are currently used in all pediatric centers in the Johns Hopkins Hospital and are in the process of being phased into adult centers, generate a CodeNet report each time the defibrillator is powered on. These reports include the ETCO2 waveform for the entire event, which is logged from the CAPNOSTAT5 ETCO2 sensor that plugs into the Zoll R-Series defibrillator. The waveform and corresponding respiratory rates from the Zoll CodeNet report could be used as numeric input for the encoding software. … 6. Digitized Waveform Custom C# software has been developed to convert JPG and BMP images that contain a clinical waveform (ETCO2, pulse oximeter, ECG) to a digital stream of data points to be sent as an input to a clinical monitor or defibrillator. This digital stream of data points can be directly sent to encoding software and, then, to a clinical monitor/defibrillator, or the data points can be saved in a simple XML format. Using the waveform digitizer, inputs to the defibrillator/clinical monitor can now include hand-drawn waveforms and printed patient records.”)
Claim 6. Duval-Arnould teaches wherein the medical device is a patient monitor device, ([Col 1 line 52-54] “In accordance with an aspect of the present invention the clinical device can take the form of at least one selected from a group consisting of a clinical monitor and a defibrillator.”) for example a fetal monitor device.
Claim 7. Holcomb teaches wherein the method comprises receiving a control input based on the control input. ([Par 21] “The digital signals are connected from the MSO channel block 150 to MSO demonstration (demo) multiplexor 221 of demonstration processing circuit 200. MSO demonstration multiplexor 221 selectively switches between the stimulus signals provided from demonstration signal generators 201 and 203 and the digital signal from MSO channel block 150, and provides the switched output to acquisition memory and trigger circuit 121.” [Par 25-26] “Referring to FIG. 3, the demonstration signal generator, such as demonstration signal generators 201 and 203, includes counting circuit (counter) 302 and stimulus memory 304 that together may function effectively as a direct digital synthesis (DDS) generator. Stimulus memory 304 stores digitized values of various different waveforms, such as sine waves, square waves, ramps, DC, noise, glitches, runt pulses, modulated waveforms and serial data. Under control of computer 170, counting circuit 302 generates and provides addresses to stimulus memory 304. Computer 170 may operate in response to user selection. … For example, counting circuit 302 and stimulus memory 304 may be controlled to function in a ping-pong mode to generate a stimulus signal consisting of a sequence of digital samples that alternate between digitized values of different stored waveforms. That is, under control of computer 170, a pair of start-stop points of different stored waveforms may be designated along with a frame count. The ping-pong mode is useful for generating stimulus signals having narrow, low frequency pulses and for generating stimulus signals having infrequent events such as glitches. Computer 170 may be programmed by user selection to provide a sequence of instructions to counting circuit 302, such as the following: [0027] Start1=0 [0028] Stop1=1000 [0029] Frame1=10 [0030] Start2=2000 [0031] Stop2=3000 [0032] Frame2=1.” [Examiner’s note: this counting circuit controls how the simulated data is generated])
Kiani makes obvious input from an external device ([Par 270] “As disclosed herein, the clinician tokens 2022, 2024 may include an input module (e.g., 1416). One use for this input module is to remotely disable an alarm once the clinician has received notification of the alarm and is en route to the patient.”)
Claim 12. Duval-Arnould teaches A computer program product comprising code means, configured when run on a processor, to cause the processor to perform the method according to claim 1. ([Col 1 line 40-51] “ The foregoing needs are met, to a great extent, by the present invention which provides a system for interfacing with a clinical device during a simulated training including a non-transitory computer readable medium configured to generate an input signal configured to mimic an output signal from a clinical sensor and encode the input signal into a format recognized by the clinical device. The system also includes a hardware component configured to interface the non-transitory computer readable medium to the clinical device. The hardware component provides communication between the non-transitory computer readable medium and the clinical device.”)
Claim 13. The elements of claim 13 are substantially the same as those of claim 1. Therefore, the elements of claim 13 are rejected due to the same reasons as outlined above for claim 1. Further, Duval-Arnould makes obvious the additional elements of: A controller, arranged for communicating with a medical device, for implementing a simulation mode on the medical device, ([Abstract] “The present invention is directed to systems for interfacing between sensors and sensor simulators and clinical monitors and devices. The present invention is used to incorporate sensors and sensor simulators into training and clinical demonstrations.” [Col 1 line 40-51] “ The foregoing needs are met, to a great extent, by the present invention which provides a system for interfacing with a clinical device during a simulated training including a non-transitory computer readable medium configured to generate an input signal configured to mimic an output signal from a clinical sensor and encode the input signal into a format recognized by the clinical device. The system also includes a hardware component configured to interface the non-transitory computer readable medium to the clinical device. The hardware component provides communication between the non-transitory computer readable medium and the clinical device.”) the medical device configured in a normal operating mode to receive one or more sensor inputs at a communication interface, each carrying a signal representative of a clinical parameter, supply the sensor inputs to a processor, and to generate a user output using the processor,
([Col 1 line 20-23] “Clinical monitors and smart defibrillators interact with patients, using a number of different sensors to collect necessary clinically relevant physiological findings and measurements of provider performance.”) the controller configured to: communicate with the medical device to cause the medical device to … ([Abstract] “The present invention is directed to systems for interfacing between sensors and sensor simulators and clinical monitors and devices. The present invention is used to incorporate sensors and sensor simulators into training and clinical demonstrations.” [Col 1 line 40-51] “ The foregoing needs are met, to a great extent, by the present invention which provides a system for interfacing with a clinical device during a simulated training including a non-transitory computer readable medium configured to generate an input signal configured to mimic an output signal from a clinical sensor and encode the input signal into a format recognized by the clinical device. The system also includes a hardware component configured to interface the non-transitory computer readable medium to the clinical device. The hardware component provides communication between the non-transitory computer readable medium and the clinical device.”)
Claim 14. Duval-Arnould teaches wherein the controller is integrated in a peripheral hardware module, the hardware module comprising a connection interface, and adapted to operatively couple to the medical device via the connection interface. ([Col 1 line 40-51] “ The foregoing needs are met, to a great extent, by the present invention which provides a system for interfacing with a clinical device during a simulated training including a non-transitory computer readable medium configured to generate an input signal configured to mimic an output signal from a clinical sensor and encode the input signal into a format recognized by the clinical device. The system also includes a hardware component configured to interface the non-transitory computer readable medium to the clinical device. The hardware component provides communication between the non-transitory computer readable medium and the clinical device.”)
(2) Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Duval-Arnould (US 10580324 B2) in view of Holcomb (US 20120274313 A1) in further view of Kiani (US 20110105854 A1) as well as Cadwell (US 20200160741 A1)
Claim 5. Duval-Arnould teaches wherein the simulation data ([Col 3 line 39-43] “Examples of such simulated outputs include but are not limited to … a real patient waveform recorded by a clinical monitor or defibrillator” [Col 4 line 31 – Col 5 line 35] “All inputs can be encoded and sent to a clinical monitor/defibrillator or can be saved in simple XML format for later use. Files saved in XML format can later be sent to a clinical monitor/defibrillator using a C# software application. Prototypes have been developed and successfully tested for all inputs described below… 3. Retrieval of ETCO2 Waveform from Zoll CodeNet Record Zoll R-Series defibrillators, which are currently used in all pediatric centers in the Johns Hopkins Hospital and are in the process of being phased into adult centers, generate a CodeNet report each time the defibrillator is powered on. These reports include the ETCO2 waveform for the entire event, which is logged from the CAPNOSTAT5 ETCO2 sensor that plugs into the Zoll R-Series defibrillator. The waveform and corresponding respiratory rates from the Zoll CodeNet report could be used as numeric input for the encoding software. … 6. Digitized Waveform Custom C# software has been developed to convert JPG and BMP images that contain a clinical waveform (ETCO2, pulse oximeter, ECG) to a digital stream of data points to be sent as an input to a clinical monitor or defibrillator. This digital stream of data points can be directly sent to encoding software and, then, to a clinical monitor/defibrillator, or the data points can be saved in a simple XML format. Using the waveform digitizer, inputs to the defibrillator/clinical monitor can now include hand-drawn waveforms and printed patient records.”)
The combination of Duval-Arnould, Holcomb, and Kiani does not explicitly teach wherein simulation data includes a plurality of simulation data subsets, each simulation data subset including data
Cadwell makes obvious wherein simulation data includes a plurality of simulation data subsets, each simulation data subset including data ([Par 13] “generate simulation data indicative of the physiological responses at each channel in the first subset using predefined relationships between the plurality of channels and based on the one or more simulated stimuli; identify a second subset of the plurality of channels from the first subset, wherein each of the channels in the second subset has simulation data indicative of a physiological response that exceeds one or more predefined thresholds;”)
Cadwell is analogous art because it is within the field of medical simulation. It would have been obvious to one of ordinary skill in the art to combine it with Duval-Arnould, Holcomb, and Kiani before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to better train users for a wider array of potential medical operations, particularly neuromonitoring. As mentioned by Cadwell, for particular simulator uses, such as neurological simulations, current simulator systems require specialized hardware that can be difficult to obtain and cannot perform accurate simulation under a variety of scenarios ([Par 5-7] “Currently, there are some training simulators available in the market for providing training to neurodiagnostic and IONM trainees. Simulation is a powerful tool for learning about rare patient events, and about common technical and operational problems, as well as how to run an IONM instrument and perform monitoring effectively. Users requiring training include both technical and medically-trained professionals. However, these training simulators requires the use of hardware including their own IONM devices. The simulators can simulate plug-in errors, but cannot simulate the effects of anesthesia, positioning, temperature, interference from other devices, surgical events and/or comorbidities. Currently available IONM training simulators do not simulate realistic waveforms in their software applications and do not simulate the effect of likely events encountered in a clinical environment on recorded waveforms. For example, latency shifts and amplitude changes in a patient's monitoring data may be caused by environmental factors (and not surgery), such as limb positioning, temperature, and other machines hooked to a patient. Such environmental factors interfere with the currently available simulator's ability to accurately simulate patient data.” [Par 12] “Hence, there is need for a software-based medical training simulator for neurodiagnostic testing and IONM which does not require connection to any neurodiagnostic or IONM hardware, thereby reducing the barrier to access for training centers and individuals. There is also need for a training simulator that provides simulations of a wide range of technical, anesthetic and surgical events likely to be encountered during typical use of the simulator.”) To this end, Cadwell presents a method for accurate, accessible neuromonitoring simulation. ([Par 13] “The present specification discloses a system for simulating a patient's physiological responses to one or more stimuli over a simulation timeframe, wherein the system comprises programmatic instructions stored in a tangible, non-transitory computer readable medium, wherein the programmatic instructions define a plurality of channels, each of said channels being virtually representative of an anatomical site of the patient, and wherein, when executed, the programmatic instructions: identify at least one of the plurality of channels as a stimulation site; identify a first subset of the plurality of channels as reference sites; generate simulation data indicative of the physiological responses at each channel in the first subset using predefined relationships between the plurality of channels and based on the one or more simulated stimuli;” [Par 70] “The present specification provides a software-based medical training simulator for neurodiagnostic testing and intraoperative neurophysiological monitoring. This software simulator differentiates itself from currently available training tools because it does not require connection to any neurodiagnostic or IONM hardware, thereby reducing the barrier to access for training centers and individuals. The software simulator comprises simulations of a wide range of technical, anesthetic, and surgical events likely to be encountered during typical use of the simulator.”) Overall, one of ordinary skill in the art would have recognized that combining Cadwell with Duval-Arnould, Holcomb, and Kiani would result in a system that is capable of performing a wider array of simulations without the need for extensive additional hardware, allowing for a wider application of the system.
(3) Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Duval-Arnould (US 10580324 B2) in view of Holcomb (US 20120274313 A1) in further view of Kiani (US 20110105854 A1) as well as UNI® Control Software for Gaumard® Simulators (Hereinafter Gaumard)
Claim 8. Duval-Arnould teaches ([Col 1 line 40- Col 2 line 3] “The foregoing needs are met, to a great extent, by the present invention which provides a system for interfacing with a clinical device during a simulated training including a non-transitory computer readable medium configured to generate an input signal configured to mimic an output signal from a clinical sensor and encode the input signal into a format recognized by the clinical device. The system also includes a hardware component configured to interface the non-transitory computer readable medium to the clinical device. The hardware component provides communication between the non-transitory computer readable medium and the clinical device. In accordance with an aspect of the present invention the clinical device can take the form of at least one selected from a group consisting of a clinical monitor and a defibrillator. The input signal takes the form of at least one selected from a group consisting of a simulator controller signal, a computer-generated waveform, a real patient waveform recorded by a clinical monitor or defibrillator, and a recorded waveform from an intercepted clinical sensor signal. The non-transitory computer readable medium can be configured to encode the input signal to follow sensor-receiver protocols. The non-transitory computer readable medium can also be configured to change or adapt the input signal in real-time. The non-transitory computer readable medium is configured to simulate the output signal from at least one of the sensors selected from a group consisting of end tidal CO2 (ETCO2), pulse oximetry (SPO2), thermometer, blood pressure, quality of CPR (QCPR), and near-infrared spectroscopy (NIRS) sensors. The system can also include an interface for a user to input parameters into the system and a patient simulator.”)
Holcomb makes obvious wherein the method further includes selectively implementing a ([Par 21] “The digital signals are connected from the MSO channel block 150 to MSO demonstration (demo) multiplexor 221 of demonstration processing circuit 200. MSO demonstration multiplexor 221 selectively switches between the stimulus signals provided from demonstration signal generators 201 and 203 and the digital signal from MSO channel block 150, and provides the switched output to acquisition memory and trigger circuit 121.” [Par 25-26] “Referring to FIG. 3, the demonstration signal generator, such as demonstration signal generators 201 and 203, includes counting circuit (counter) 302 and stimulus memory 304 that together may function effectively as a direct digital synthesis (DDS) generator. Stimulus memory 304 stores digitized values of various different waveforms, such as sine waves, square waves, ramps, DC, noise, glitches, runt pulses, modulated waveforms and serial data. Under control of computer 170, counting circuit 302 generates and provides addresses to stimulus memory 304. Computer 170 may operate in response to user selection. … For example, counting circuit 302 and stimulus memory 304 may be controlled to function in a ping-pong mode to generate a stimulus signal consisting of a sequence of digital samples that alternate between digitized values of different stored waveforms. That is, under control of computer 170, a pair of start-stop points of different stored waveforms may be designated along with a frame count. The ping-pong mode is useful for generating stimulus signals having narrow, low frequency pulses and for generating stimulus signals having infrequent events such as glitches. Computer 170 may be programmed by user selection to provide a sequence of instructions to counting circuit 302, such as the following: [0027] Start1=0 [0028] Stop1=1000 [0029] Frame1=10 [0030] Start2=2000 [0031] Stop2=3000 [0032] Frame2=1.”)
Kiani makes obvious ([Par 270] “As disclosed herein, the clinician tokens 2022, 2024 may include an input module (e.g., 1416). One use for this input module is to remotely disable an alarm once the clinician has received notification of the alarm and is en route to the patient.”)
The combination of Duval-Arnould, Holcomb, and Kiani does not explicitly teach a further simulation mode; wherein in the further simulation mode simulation operations are performed based on input.
Gaumard makes obvious a further simulation mode; wherein in the further simulation mode simulation operations are performed based on input. ([Page 51 Col 1 Par 2 – Col 2 Par 6] “After the startup screen, the profile and operating mode selection menu is displayed. The UNI control software has two modes of operation: Manual and Automatic. Each mode includes a Quick Start profile with preprogrammed scenarios exercises created in conjunction with experienced healthcare instructors and working medical professionals. Continue to the next section to learn more about each operating mode and the profiles included. After selecting an operating mode and profile, click “Load” to continue. In the “Manual” operating mode, the facilitator fully controls the vital signs and physiologic responses. … When first starting out with the simulator, it is recommended that you use the Quick Start profile, which was created in conjunction with experienced healthcare instructors and working medical professionals. The Quick Start profile has applicable Palettes that are useful for simulating common medical emergencies. For many applications, it serves a convenient starting point that can be customized to it most simulation objectives. It Includes a library of predetermined scenarios. The Automatic mode assists the facilitator by automatically adjusting vital signs in response to caregiver participation, pharmacologic intervention, and manual input. For example, when facilitator increases the heart rate, the Auto mode will calculate the response and adjust the blood pressure automatically. To activate the operating mode as an upgrade option, go to “Menu” section”)
Gaumard is analogous art because it is within the field of medical simulation. It would have been obvious to one of ordinary skill in the art to combine it with Duval-Arnould, Holcomb, and Kiani before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to enable greater manual control over the response of the simulated signals. While systems like Duval-Arnould do teach some manual signal control, these methods can be tedious and require the generation of individual sensor waveforms one at a time ([Col 4 line 53-58] “A simulated ETCO2 waveform can be generated via our C# waveform generator that creates a continuous waveform of interchanging exponential rise and decay based on set parameters. This simulated waveform can be sampled to retrieve a stream of ETCO2 waveform data points; these data points will be encoded using our encoding software.” [Col 5 line 26-35] “Custom C# software has been developed to convert JPG and BMP images that contain a clinical waveform (ETCO2, pulse oximeter, ECG) to a digital stream of data points to be sent as an input to a clinical monitor or defibrillator. This digital stream of data points can be directly sent to encoding software and, then, to a clinical monitor/defibrillator, or the data points can be saved in a simple XML format. Using the waveform digitizer, inputs to the defibrillator/clinical monitor can now include hand-drawn waveforms and printed patient records”) To this end, Gaumard presents a system including a manual control mode that allows for the rapid, easy adjustment of vital signs and simulated signals from an easy integrated menu system ([Page 6 Figs. 1-4])
PNG
media_image1.png
742
650
media_image1.png
Greyscale
Further, Duval-Arnould notes the desirability of and easy integration with mannequin control systems such as Gaumard ([Col 4 line 39-51] “All high-technology simulator mannequins have a mannequin-specific software platform that is loaded on a PC or tablet. This software-based user interface can be used to control realistic and clinically measurable mannequin characteristics, such as heart rhythm, and to control non-measurable vital parameters that are projected on a simulator-specific monitor that acts as the bedside monitor in simulated events. The waveform and/or value set for a specific vital sign, such as ETCO2, on the simulator software could be used as an input into the encoding software. This transfer of simulated ETCO2 data from the simulation software to our encoding software is made possible via the use of the SimMan SDK.”) Overall, one of ordinary skill in the art would have recognized that combining Gaumard with Duval-Arnould, Holcomb, and Kiani would result in a system that allowed for a much greater level of user control in an easy and concise manner.
(4) Claims 9 -11 are rejected under 35 U.S.C. 103 as being unpatentable over Duval-Arnould (US 10580324 B2) in view of Holcomb (US 20120274313 A1) in further view of Kiani (US 20110105854 A1) as well as Krishnan (US 20150089590 A1)
Claim 9. Duval-Arnould teaches wherein the method comprises a step of establishing a communication channel w([Col 5 line 13-25] “A simulated ETCO2 waveform that directly reflects the actions of a provider's performance of manual patient ventilation can be generated via our C# waveform generator; the characteristics of this generated waveform, including visual and numeric respiratory rate and ETCO2 amplitude, are dependent upon the output of a ventilation detection sensor. The pressure sensor in this technology outputs to a microcontroller, which provides minimal analysis and wireless communication between the sensor and the waveform generator software on a computer. This input allows for the realistic, automated display of provider performance on the clinical monitor/defibrillator during simulation.”)
Kiani makes obvious establishing a communication channel with the external device, ([Par 212] “The clinician token 1410 can likewise include a communication module 1412, which can be, for example, a transmitter, a receiver, or a transceiver, though other types of communication modules may also be used. As is the case with the patient monitoring device 1400, the communication module 1412 included with the clinician token 1410 may be a short range transceiver, such as, for example, a Bluetooth transceiver. The patient monitoring device 1400 is capable of detecting the presence of a clinician based on, for example, recognition of one or more communication signals from a clinician token 1410. A communication signal from the clinician token 1410 may come, for example, in response to a communication initiated by the patient monitoring device 1400, or the communication signal from the clinician token 1410 may be initiated by the clinician token itself. Many different methods can be used for initiating, for example, wireless communication between remote devices.”)
The combination of Duval-Arnould, Holcomb, and Kiani does not explicitly teach wherein the process comprises exchanging one or more handshake messages.
Krishnan makes obvious wherein the system comprises exchanging one or more handshake messages. ([Par 110] “Another useful option is to use an unknown EP temporarily only until the session lasts. In this case, the secret code entered by the patient is called session secret or session secret code, as it lasts only for that session. Patient enters the same session secret in EP and the patient-Smartphone or other mobile device. Again, MD5 hash value of 128-bit is derived from the session secret and converted into AES standard key. The key is then saved into the device's corresponding database. As shown in FIG. 2, as soon as the session key is generated from the secret code, Smartphone or other mobile device sends out temporary key, K.sub.S for EP and K.sub.S for ICD inside the TicketICD, appended with Smartphone or other mobile device ID, a nonce, N1, encrypted with pre-shared secret key, K.sub.EP. The EP sends the TicketICD appended with a challenge timestamp T that is encrypted with, K.sub.S. The ICD extracts the key K.sub.S from the TicketICD and responds back to the EP with timestamp T+1, encrypted with the temporary session key, K.sub.S. The EP can request information from the ICD after this handshake.”)
[Examiner’s note: while the limitation of “preferably wherein the establishing communication comprises exchanging one or more handshake messages.” is mapped here for the sake of convenience, note that it does not require patentable weight due to the use of the word “preferably.” See the claim interpretation and 112 rejection sections at the beginning of this action.]
Krishnan is analogous art because it is within the field of medical data processing. It would have been obvious to one of ordinary skill in the art to combine it with Duval-Arnould, Holcomb, and Kiani One of ordinary skill in the art would have been motivated to make this combination in order to better secure data, particularly important patient data when basing simulations on such. As noted by Krishnan, providing security for healthcare operations has become more and more complex in recent years ([Par 2] “Information security in the field of health care has become an increasingly complex and important topic in recent years. There has been a thorough investigation regarding threats and vulnerabilities to patients with implantable medical devices, and new design solutions have been described. Information security in the field of healthcare has gained a new urgency and need, and there has been tremendous development in healthcare-related communication networking and information security.”) Logically, this increase in complexity can lead to an increase in the chance of security violations. To this end, Krishnan presents a method for secure communication between medical devices and other networked devices ([Par 34] “ This application describes a computer security protocol by introducing a Smartphone or other mobile device, which acts as a security management "hotspot" between External Programmer (EP) and Implantable Cardiac Defibrillator (ICD), using symmetric key cryptography. The Smartphone or other mobile device will only allow access to registered programmers or allow unregistered ones with the patient's consent. Several scenarios are described where Smartphone or other mobile device plays a central role in access control including the emergency case.”) While Krishnan envisions this security system in the context of connections with implantable devices such as pacemakers, one of ordinary skill in the art would have recognized that this security protocol would work identically between other devices, and that combining Krishnan with Duval-Arnould, Holcomb, and Kiani would result in a system that is significantly more secure.
Claim 10. Krishnan teaches wherein the one or more handshake messages include authentication information for establishing a secure communication channel. ([Par 110] “Another useful option is to use an unknown EP temporarily only until the session lasts. In this case, the secret code entered by the patient is called session secret or session secret code, as it lasts only for that session. Patient enters the same session secret in EP and the patient-Smartphone or other mobile device. Again, MD5 hash value of 128-bit is derived from the session secret and converted into AES standard key. The key is then saved into the device's corresponding database. As shown in FIG. 2, as soon as the session key is generated from the secret code, Smartphone or other mobile device sends out temporary key, K.sub.S for EP and K.sub.S for ICD inside the TicketICD, appended with Smartphone or other mobile device ID, a nonce, N1, encrypted with pre-shared secret key, K.sub.EP. The EP sends the TicketICD appended with a challenge timestamp T that is encrypted with, K.sub.S. The ICD extracts the key K.sub.S from the TicketICD and responds back to the EP with timestamp T+1, encrypted with the temporary session key, K.sub.S. The EP can request information from the ICD after this handshake.”)
Claim 11. Duval-Arnould teaches wherein the further communication interface includes a local wireless network interface, ([Col 5 line 13-25] “A simulated ETCO2 waveform that directly reflects the actions of a provider's performance of manual patient ventilation can be generated via our C# waveform generator; the characteristics of this generated waveform, including visual and numeric respiratory rate and ETCO2 amplitude, are dependent upon the output of a ventilation detection sensor. The pressure sensor in this technology outputs to a microcontroller, which provides minimal analysis and wireless communication between the sensor and the waveform generator software on a computer. This input allows for the realistic, automated display of provider performance on the clinical monitor/defibrillator during simulation.”) and preferably wherein the communication channel is facilitated by a local wireless network server, for example a Wi-Fi server.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michael P Mirabito whose telephone number is (703)756-1494. The examiner can normally be reached M-F 10: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, Emerson Puente can be reached at (571) 272-3652. 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.
/M.P.M./ Examiner, Art Unit 2187
/EMERSON C PUENTE/ Supervisory Patent Examiner, Art Unit 2187